[RFC PATCH 2/3] KVM: arm64: Fix handling of merging tables into a block entry
Marc Zyngier
maz at kernel.org
Tue Dec 1 09:35:02 EST 2020
Hi Yanan,
On 2020-12-01 14:11, wangyanan (Y) wrote:
> On 2020/12/1 21:46, Will Deacon wrote:
>> On Tue, Dec 01, 2020 at 10:30:41AM +0800, wangyanan (Y) wrote:
[...]
>>> The point is at b.iii where the TLBI is not enough. There are many
>>> page
>>> mappings that we need to merge into a block mapping.
>>>
>>> We invalidate the TLB for the input address without level hint at
>>> b.iii, but
>>> this operation just flush TLB for one page mapping, there
>>>
>>> are still some TLB entries for the other page mappings in the cache,
>>> the MMU
>>> hardware walker can still hit these entries next time.
>> Ah, yes, I see. Thanks. I hadn't considered the case where there are
>> table
>> entries beneath the anchor. So how about the diff below?
>>
>> Will
>>
>> --->8
>
> Hi, I think it's inappropriate to put the TLBI of all the leaf entries
> in function stage2_map_walk_table_post(),
>
> because the *ptep must be an upper table entry when we enter
> stage2_map_walk_table_post().
>
> We should make the TLBI for every leaf entry not table entry in the
> last lookup level, just as I am proposing
>
> to add the additional TLBI in function stage2_map_walk_leaf().
Could you make your concerns explicit? As far as I can tell, this should
address the bug you found, at least from a correctness perspective.
Are you worried about the impact of the full S2 invalidation? Or do you
see another correctness issue?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
More information about the linux-arm-kernel
mailing list