From: "wangyanan (Y)" <wangyanan55@huawei.com>
To: Marc Zyngier <maz@kernel.org>
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: Wed, 2 Dec 2020 01:20:33 +0800 [thread overview]
Message-ID: <0a36f859-2666-e5e7-856d-47fa306a6f53@huawei.com> (raw)
In-Reply-To: <e9f00d1af54cf61c7469c7d905bff3e0@kernel.org>
On 2020/12/1 22:35, Marc Zyngier wrote:
> 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?
Hi Will, Marc,
After recheck of the diff, the full S2 invalidation in
stage2_map_walk_table_post() should be well enough to solve this problem.
But I was wondering if we can add the full S2 invalidation in
stage2_map_walk_table_pre(), where __kvm_tlb_flush_vmid() will be called
for only one time.
If we add the full TLBI in stage2_map_walk_table_post(),
__kvm_tlb_flush_vmid() might be called for many times in the loop and
lots of (unnecessary) CPU instructions will be wasted.
What I'm saying is something like below, please let me know what do you
think.
If this is OK, I can update the diff in v2 and send it with your SOB (is
it appropriate?) after some tests.
diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
index b232bdd142a6..f11fb2996080 100644
--- a/arch/arm64/kvm/hyp/pgtable.c
+++ b/arch/arm64/kvm/hyp/pgtable.c
@@ -496,7 +496,7 @@ static int stage2_map_walk_table_pre(u64 addr, u64
end, u32 level,
return 0;
kvm_set_invalid_pte(ptep);
- kvm_call_hyp(__kvm_tlb_flush_vmid_ipa, data->mmu, addr, 0);
+ kvm_call_hyp(__kvm_tlb_flush_vmid, data->mmu);
data->anchor = ptep;
return 0;
}
Thanks,
Yanan
next prev parent reply other threads:[~2020-12-01 17:21 UTC|newest]
Thread overview: 24+ 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 ` [RFC PATCH 1/3] KVM: arm64: Fix possible memory leak in kvm stage2 Yanan Wang
2020-11-30 13:21 ` Will Deacon
2020-12-01 7:21 ` wangyanan (Y)
2020-12-01 14:16 ` Will Deacon
2020-12-01 17:19 ` wangyanan (Y)
2020-12-01 18:15 ` Will Deacon
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 13:34 ` Will Deacon
2020-11-30 15:24 ` wangyanan (Y)
2020-11-30 16:01 ` Will Deacon
2020-12-01 2:30 ` wangyanan (Y)
2020-12-01 13:46 ` Will Deacon
2020-12-01 14:05 ` Marc Zyngier
2020-12-01 14:23 ` Will Deacon
2020-12-01 14:32 ` Marc Zyngier
2020-12-01 14:11 ` wangyanan (Y)
2020-12-01 14:35 ` Marc Zyngier
2020-12-01 17:20 ` wangyanan (Y) [this message]
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 13:49 ` Will Deacon
2020-12-01 6:04 ` wangyanan (Y)
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=0a36f859-2666-e5e7-856d-47fa306a6f53@huawei.com \
--to=wangyanan55@huawei.com \
--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=maz@kernel.org \
--cc=qperret@google.com \
--cc=suzuki.poulose@arm.com \
--cc=wanghaibin.wang@huawei.com \
--cc=wangjingyi11@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®