From: "wangyanan (Y)" <wangyanan55@huawei.com>
To: Will Deacon <will@kernel.org>, Marc Zyngier <maz@kernel.org>
Cc: jiangkunkun@huawei.com, Gavin Shan <gshan@redhat.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
wangjingyi11@huawei.com, Quentin Perret <qperret@google.com>,
lushenming@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, zhukeqian1@huawei.com,
Julien Thierry <julien.thierry.kdev@gmail.com>
Subject: Re: [PATCH v2 0/3] Fix several bugs in KVM stage 2 translation
Date: Wed, 2 Dec 2020 20:00:12 +0800 [thread overview]
Message-ID: <74540986-6197-34bc-cd53-850472091ee3@huawei.com> (raw)
In-Reply-To: <20201201205948.GA28178@willie-the-truck>
Hi Will, Marc,
On 2020/12/2 4:59, Will Deacon wrote:
> On Wed, Dec 02, 2020 at 04:10:31AM +0800, Yanan Wang wrote:
>> When installing a new pte entry or updating an old valid entry in stage 2
>> translation, we use get_page()/put_page() to record page_count of the page-table
>> pages. PATCH 1/3 aims to fix incorrect use of get_page()/put_page() in stage 2,
>> which might make page-table pages unable to be freed when unmapping a range.
>>
>> When dirty logging of a guest with hugepages is finished, we should merge tables
>> back into a block entry if adjustment of huge mapping is found necessary.
>> In addition to installing the block entry, we should not only free the non-huge
>> page-table pages but also invalidate all the TLB entries of non-huge mappings for
>> the block. PATCH 2/3 adds enough TLBI when merging tables into a block entry.
>>
>> The rewrite of page-table code and fault handling add two different handlers
>> for "just relaxing permissions" and "map by stage2 page-table walk", that's
>> good improvement. Yet, in function user_mem_abort(), conditions where we choose
>> the above two fault handlers are not strictly distinguished. This will causes
>> guest errors such as infinite-loop (soft lockup will occur in result), because of
>> calling the inappropriate fault handler. So, a solution that can strictly
>> distinguish conditions is introduced in PATCH 3/3.
> For the series:
>
> Acked-by: Will Deacon <will@kernel.org>
>
> Thanks for reporting these, helping me to understand the issues and then
> spinning a v2 so promptly.
>
> Will
> .
Thanks for the help and suggestions.
BTW: there are two more things below that I want to talk about.
1. Recently, I have been focusing on the ARMv8.4-TTRem feature which is
aimed at changing block size in stage 2 mapping.
I have a plan to implement this feature for stage 2 translation when
splitting a block into tables or merging tables into a block.
This feature supports changing block size without performing
*break-before-make*, which might have some improvement on performance.
What do you think about this?
2. Given that the issues we discussed before were found in practice when
guest state changes from dirty logging to dirty logging canceled.
I could add a test file testing on this case to selftests/ or kvm unit
tests/, if it's necessary.
Yanan
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-12-02 12:02 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-01 20:10 [PATCH v2 0/3] Fix several bugs in KVM stage 2 translation Yanan Wang
2020-12-01 20:10 ` [PATCH v2 1/3] KVM: arm64: Fix possible memory leak in kvm stage2 Yanan Wang
2020-12-01 20:10 ` [PATCH v2 2/3] KVM: arm64: Fix handling of merging tables into a block entry Yanan Wang
2020-12-01 20:10 ` [PATCH v2 3/3] KVM: arm64: Add usage of stage 2 fault lookup level in user_mem_abort() Yanan Wang
2020-12-01 20:59 ` [PATCH v2 0/3] Fix several bugs in KVM stage 2 translation Will Deacon
2020-12-02 12:00 ` wangyanan (Y) [this message]
2020-12-02 12:23 ` Marc Zyngier
2020-12-02 12:50 ` wangyanan (Y)
2020-12-02 12:24 ` Marc Zyngier
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=74540986-6197-34bc-cd53-850472091ee3@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