From: Gavin Shan <gshan@redhat.com>
To: Keqian Zhu <zhukeqian1@huawei.com>, kvmarm@lists.cs.columbia.edu
Cc: maz@kernel.org, will@kernel.org, linux-kernel@vger.kernel.org,
shan.gavin@gmail.com
Subject: Re: [PATCH 4/4] KVM: arm64: Don't retrieve memory slot again in page fault handler
Date: Mon, 15 Mar 2021 20:56:17 +1100 [thread overview]
Message-ID: <7a29ac43-ef11-e990-e08c-c5e97ea7d78d@redhat.com> (raw)
In-Reply-To: <30073114-339f-33dd-0168-b4d6bfbe88bc@huawei.com>
Hi Keqian,
On 3/15/21 7:25 PM, Keqian Zhu wrote:
> On 2021/3/15 12:18, Gavin Shan wrote:
>> We needn't retrieve the memory slot again in user_mem_abort() because
>> the corresponding memory slot has been passed from the caller. This
> I think you are right, though fault_ipa will be adjusted when we try to use block mapping,
> the fault_supports_stage2_huge_mapping() makes sure we're not trying to map anything
> not covered by the memslot, so the adjusted fault_ipa still belongs to the memslot.
>
Yeah, it's correct. Besides, the @logging_active is determined
based on the passed memory slot. It means user_mem_abort() can't
support memory range which spans multiple memory slot.
>> would save some CPU cycles. For example, the time used to write 1GB
>> memory, which is backed by 2MB hugetlb pages and write-protected, is
>> dropped by 6.8% from 928ms to 864ms.
>>
>> Signed-off-by: Gavin Shan <gshan@redhat.com>
>> ---
>> arch/arm64/kvm/mmu.c | 5 +++--
>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
>> index a5a8ade9fde4..4a4abcccfafb 100644
>> --- a/arch/arm64/kvm/mmu.c
>> +++ b/arch/arm64/kvm/mmu.c
>> @@ -846,7 +846,8 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>> */
>> smp_rmb();
>>
>> - pfn = gfn_to_pfn_prot(kvm, gfn, write_fault, &writable);
>> + pfn = __gfn_to_pfn_memslot(memslot, gfn, false, NULL,
>> + write_fault, &writable, NULL);
> It's better to update the code comments at same time.
>
I guess you need some comments here? If so, I would add something
like below in v2:
/*
* gfn_to_pfn_prot() can be used either with unnecessary overhead
* introduced to locate the memory slot because the memory slot is
* always fixed even @gfn is adjusted for huge pages.
*/
>> if (pfn == KVM_PFN_ERR_HWPOISON) {
>> kvm_send_hwpoison_signal(hva, vma_shift);
>> return 0;
>> @@ -912,7 +913,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>> /* Mark the page dirty only if the fault is handled successfully */
>> if (writable && !ret) {
>> kvm_set_pfn_dirty(pfn);
>> - mark_page_dirty(kvm, gfn);
>> + mark_page_dirty_in_slot(kvm, memslot, gfn);
>> }
>>
>> out_unlock:
>>
Thanks,
Gavin
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
WARNING: multiple messages have this Message-ID (diff)
From: Gavin Shan <gshan@redhat.com>
To: Keqian Zhu <zhukeqian1@huawei.com>, kvmarm@lists.cs.columbia.edu
Cc: maz@kernel.org, will@kernel.org, linux-kernel@vger.kernel.org,
shan.gavin@gmail.com
Subject: Re: [PATCH 4/4] KVM: arm64: Don't retrieve memory slot again in page fault handler
Date: Mon, 15 Mar 2021 20:56:17 +1100 [thread overview]
Message-ID: <7a29ac43-ef11-e990-e08c-c5e97ea7d78d@redhat.com> (raw)
In-Reply-To: <30073114-339f-33dd-0168-b4d6bfbe88bc@huawei.com>
Hi Keqian,
On 3/15/21 7:25 PM, Keqian Zhu wrote:
> On 2021/3/15 12:18, Gavin Shan wrote:
>> We needn't retrieve the memory slot again in user_mem_abort() because
>> the corresponding memory slot has been passed from the caller. This
> I think you are right, though fault_ipa will be adjusted when we try to use block mapping,
> the fault_supports_stage2_huge_mapping() makes sure we're not trying to map anything
> not covered by the memslot, so the adjusted fault_ipa still belongs to the memslot.
>
Yeah, it's correct. Besides, the @logging_active is determined
based on the passed memory slot. It means user_mem_abort() can't
support memory range which spans multiple memory slot.
>> would save some CPU cycles. For example, the time used to write 1GB
>> memory, which is backed by 2MB hugetlb pages and write-protected, is
>> dropped by 6.8% from 928ms to 864ms.
>>
>> Signed-off-by: Gavin Shan <gshan@redhat.com>
>> ---
>> arch/arm64/kvm/mmu.c | 5 +++--
>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
>> index a5a8ade9fde4..4a4abcccfafb 100644
>> --- a/arch/arm64/kvm/mmu.c
>> +++ b/arch/arm64/kvm/mmu.c
>> @@ -846,7 +846,8 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>> */
>> smp_rmb();
>>
>> - pfn = gfn_to_pfn_prot(kvm, gfn, write_fault, &writable);
>> + pfn = __gfn_to_pfn_memslot(memslot, gfn, false, NULL,
>> + write_fault, &writable, NULL);
> It's better to update the code comments at same time.
>
I guess you need some comments here? If so, I would add something
like below in v2:
/*
* gfn_to_pfn_prot() can be used either with unnecessary overhead
* introduced to locate the memory slot because the memory slot is
* always fixed even @gfn is adjusted for huge pages.
*/
>> if (pfn == KVM_PFN_ERR_HWPOISON) {
>> kvm_send_hwpoison_signal(hva, vma_shift);
>> return 0;
>> @@ -912,7 +913,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>> /* Mark the page dirty only if the fault is handled successfully */
>> if (writable && !ret) {
>> kvm_set_pfn_dirty(pfn);
>> - mark_page_dirty(kvm, gfn);
>> + mark_page_dirty_in_slot(kvm, memslot, gfn);
>> }
>>
>> out_unlock:
>>
Thanks,
Gavin
next prev parent reply other threads:[~2021-03-15 9:56 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-15 4:18 [PATCH 0/4] KVM: arm64: Minor page fault handler improvement Gavin Shan
2021-03-15 4:18 ` Gavin Shan
2021-03-15 4:18 ` [PATCH 1/4] KVM: arm64: Hide kvm_mmu_wp_memory_region() Gavin Shan
2021-03-15 4:18 ` Gavin Shan
2021-03-15 7:49 ` Keqian Zhu
2021-03-15 7:49 ` Keqian Zhu
2021-03-15 4:18 ` [PATCH 2/4] KVM: arm64: Use find_vma_intersection() Gavin Shan
2021-03-15 4:18 ` Gavin Shan
2021-03-15 8:04 ` Keqian Zhu
2021-03-15 8:04 ` Keqian Zhu
2021-03-15 9:42 ` Gavin Shan
2021-03-15 9:42 ` Gavin Shan
2021-03-16 3:52 ` Gavin Shan
2021-03-16 3:52 ` Gavin Shan
2021-03-16 4:20 ` Keqian Zhu
2021-03-16 4:20 ` Keqian Zhu
2021-03-15 8:52 ` Marc Zyngier
2021-03-15 8:52 ` Marc Zyngier
2021-03-15 9:40 ` Gavin Shan
2021-03-15 9:40 ` Gavin Shan
2021-03-15 4:18 ` [PATCH 3/4] KVM: arm64: Fix address check for memory slot Gavin Shan
2021-03-15 4:18 ` Gavin Shan
2021-03-15 7:33 ` Keqian Zhu
2021-03-15 7:33 ` Keqian Zhu
2021-03-15 9:46 ` Gavin Shan
2021-03-15 9:46 ` Gavin Shan
2021-03-15 4:18 ` [PATCH 4/4] KVM: arm64: Don't retrieve memory slot again in page fault handler Gavin Shan
2021-03-15 4:18 ` Gavin Shan
2021-03-15 8:25 ` Keqian Zhu
2021-03-15 8:25 ` Keqian Zhu
2021-03-15 9:56 ` Gavin Shan [this message]
2021-03-15 9:56 ` Gavin Shan
2021-03-15 10:46 ` Keqian Zhu
2021-03-15 10:46 ` Keqian Zhu
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=7a29ac43-ef11-e990-e08c-c5e97ea7d78d@redhat.com \
--to=gshan@redhat.com \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@kernel.org \
--cc=shan.gavin@gmail.com \
--cc=will@kernel.org \
--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.