All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: "wangyanan (Y)" <wangyanan55@huawei.com>
Cc: jiangkunkun@huawei.com, Gavin Shan <gshan@redhat.com>,
	lushenming@huawei.com, Suzuki K Poulose <suzuki.poulose@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	zhukeqian1@huawei.com, Quentin Perret <qperret@google.com>,
	wangjingyi11@huawei.com, linux-kernel@vger.kernel.org,
	yezengruan@huawei.com, James Morse <james.morse@arm.com>,
	linux-arm-kernel@lists.infradead.org, yuzenghui@huawei.com,
	wanghaibin.wang@huawei.com, Will Deacon <will@kernel.org>,
	Julien Thierry <julien.thierry.kdev@gmail.com>
Subject: Re: [RFC PATCH 2/3] KVM: arm64: Fix handling of merging tables into a block entry
Date: Tue, 01 Dec 2020 14:35:02 +0000	[thread overview]
Message-ID: <e9f00d1af54cf61c7469c7d905bff3e0@kernel.org> (raw)
In-Reply-To: <2e92a511-496c-d446-95f4-6211ec8b4bb6@huawei.com>

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...

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: "wangyanan (Y)" <wangyanan55@huawei.com>
Cc: Will Deacon <will@kernel.org>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	Catalin Marinas <catalin.marinas@arm.com>,
	James Morse <james.morse@arm.com>,
	Julien Thierry <julien.thierry.kdev@gmail.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Gavin Shan <gshan@redhat.com>,
	Quentin Perret <qperret@google.com>,
	wanghaibin.wang@huawei.com, yezengruan@huawei.com,
	zhukeqian1@huawei.com, yuzenghui@huawei.com,
	jiangkunkun@huawei.com, wangjingyi11@huawei.com,
	lushenming@huawei.com
Subject: Re: [RFC PATCH 2/3] KVM: arm64: Fix handling of merging tables into a block entry
Date: Tue, 01 Dec 2020 14:35:02 +0000	[thread overview]
Message-ID: <e9f00d1af54cf61c7469c7d905bff3e0@kernel.org> (raw)
In-Reply-To: <2e92a511-496c-d446-95f4-6211ec8b4bb6@huawei.com>

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...

  reply	other threads:[~2020-12-01 14:36 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-30 12:18 [RFC PATCH 0/3] Fix several bugs in KVM stage 2 translation Yanan Wang
2020-11-30 12:18 ` Yanan Wang
2020-11-30 12:18 ` [RFC PATCH 1/3] KVM: arm64: Fix possible memory leak in kvm stage2 Yanan Wang
2020-11-30 12:18   ` Yanan Wang
2020-11-30 13:21   ` Will Deacon
2020-11-30 13:21     ` Will Deacon
2020-12-01  7:21     ` wangyanan (Y)
2020-12-01  7:21       ` wangyanan (Y)
2020-12-01 14:16       ` Will Deacon
2020-12-01 14:16         ` Will Deacon
2020-12-01 17:19         ` wangyanan (Y)
2020-12-01 17:19           ` wangyanan (Y)
2020-12-01 18:15           ` Will Deacon
2020-12-01 18:15             ` Will Deacon
2020-12-01 20:08             ` wangyanan (Y)
2020-12-01 20:08               ` wangyanan (Y)
2020-11-30 12:18 ` [RFC PATCH 2/3] KVM: arm64: Fix handling of merging tables into a block entry Yanan Wang
2020-11-30 12:18   ` Yanan Wang
2020-11-30 13:34   ` Will Deacon
2020-11-30 13:34     ` Will Deacon
2020-11-30 15:24     ` wangyanan (Y)
2020-11-30 15:24       ` wangyanan (Y)
2020-11-30 16:01       ` Will Deacon
2020-11-30 16:01         ` Will Deacon
2020-12-01  2:30         ` wangyanan (Y)
2020-12-01  2:30           ` wangyanan (Y)
2020-12-01 13:46           ` Will Deacon
2020-12-01 13:46             ` Will Deacon
2020-12-01 14:05             ` Marc Zyngier
2020-12-01 14:05               ` Marc Zyngier
2020-12-01 14:23               ` Will Deacon
2020-12-01 14:23                 ` Will Deacon
2020-12-01 14:32                 ` Marc Zyngier
2020-12-01 14:32                   ` Marc Zyngier
2020-12-01 14:11             ` wangyanan (Y)
2020-12-01 14:11               ` wangyanan (Y)
2020-12-01 14:35               ` Marc Zyngier [this message]
2020-12-01 14:35                 ` Marc Zyngier
2020-12-01 17:20                 ` wangyanan (Y)
2020-12-01 17:20                   ` wangyanan (Y)
2020-12-01 18:17                   ` Will Deacon
2020-12-01 18:17                     ` Will Deacon
2020-11-30 12:18 ` [RFC PATCH 3/3] KVM: arm64: Add usage of stage 2 fault lookup level in user_mem_abort() Yanan Wang
2020-11-30 12:18   ` Yanan Wang
2020-11-30 13:49   ` Will Deacon
2020-11-30 13:49     ` Will Deacon
2020-12-01  6:04     ` wangyanan (Y)
2020-12-01  6:04       ` wangyanan (Y)
2020-11-30 19:40   ` kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e9f00d1af54cf61c7469c7d905bff3e0@kernel.org \
    --to=maz@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=gshan@redhat.com \
    --cc=james.morse@arm.com \
    --cc=jiangkunkun@huawei.com \
    --cc=julien.thierry.kdev@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lushenming@huawei.com \
    --cc=qperret@google.com \
    --cc=suzuki.poulose@arm.com \
    --cc=wanghaibin.wang@huawei.com \
    --cc=wangjingyi11@huawei.com \
    --cc=wangyanan55@huawei.com \
    --cc=will@kernel.org \
    --cc=yezengruan@huawei.com \
    --cc=yuzenghui@huawei.com \
    --cc=zhukeqian1@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.