From: eric.auger@linaro.org (Eric Auger)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: KVM: Handle IPA unmapping on memory region deletion
Date: Thu, 03 Apr 2014 18:32:16 +0200 [thread overview]
Message-ID: <533D8D10.7070909@linaro.org> (raw)
In-Reply-To: <533D7D8B.2030806@arm.com>
On 04/03/2014 05:26 PM, Marc Zyngier wrote:
> Hi Eric,
>
> On 03/04/14 16:17, Eric Auger wrote:
>> Currently when a KVM region is removed using
>> kvm_vm_ioctl_set_memory_region (with memory region size equal to 0), the
>> corresponding intermediate physical memory is not unmapped.
>>
>> This patch unmaps the region's IPA range in
>> kvm_arch_commit_memory_region using unmap_stage2_range.
>>
>> The patch was tested on QEMU VFIO based use case where RAM memory region
>> creation/deletion frequently happens for IRQ handling.
>>
>> Notes:
>> - the KVM_MR_MOVE case shall request some similar addition but I cannot test
>> this currently
>
> I think you should try to handle it anyway. I'm sure you could hack QEMU
> to do this test it, but even if you don't, better plug that hole right now.
Hi Marc,
OK I will proceed
>
>> Signed-off-by: Eric Auger <eric.auger@linaro.org>
>> ---
>> arch/arm/include/asm/kvm_mmu.h | 2 ++
>> arch/arm/kvm/arm.c | 8 ++++++++
>> arch/arm/kvm/mmu.c | 2 +-
>> 3 files changed, 11 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
>> index 2d122ad..a91c863 100644
>> --- a/arch/arm/include/asm/kvm_mmu.h
>> +++ b/arch/arm/include/asm/kvm_mmu.h
>> @@ -52,6 +52,8 @@ void kvm_free_stage2_pgd(struct kvm *kvm);
>> int kvm_phys_addr_ioremap(struct kvm *kvm, phys_addr_t guest_ipa,
>> phys_addr_t pa, unsigned long size);
>>
>> +void unmap_stage2_range(struct kvm *kvm, phys_addr_t guest_ipa, u64 size);
>> +
>> int kvm_handle_guest_abort(struct kvm_vcpu *vcpu, struct kvm_run *run);
>>
>> void kvm_mmu_free_memory_caches(struct kvm_vcpu *vcpu);
>> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
>> index bd18bb8..9a4bc10 100644
>> --- a/arch/arm/kvm/arm.c
>> +++ b/arch/arm/kvm/arm.c
>> @@ -241,6 +241,14 @@ void kvm_arch_commit_memory_region(struct kvm *kvm,
>> const struct kvm_memory_slot *old,
>> enum kvm_mr_change change)
>> {
>> + if (change == KVM_MR_DELETE) {
>> + gpa_t gpa = old->base_gfn << PAGE_SHIFT;
>> + u64 size = old->npages << PAGE_SHIFT;
>> +
>> + spin_lock(&kvm->mmu_lock);
>> + unmap_stage2_range(kvm, gpa, size);
>> + spin_unlock(&kvm->mmu_lock);
>> + }
>> }
>
> Just move the whole function to mmu.c, as it makes more sense to have it
> there. And while you're at it, how about moving the other
> memslot/memory_region stubs?
OK I will move:
kvm_arch_free_memslot,
kvm_arch_create_memslot,
kvm_arch_prepare_memory_region,
kvm_arch_commit_memory_region,
kvm_arch_shadow_all and
kvm_arch_shadow_memslot then.
Best Regards
Eric
>
>> void kvm_arch_flush_shadow_all(struct kvm *kvm)
>> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
>> index 7789857..e8580e2 100644
>> --- a/arch/arm/kvm/mmu.c
>> +++ b/arch/arm/kvm/mmu.c
>> @@ -443,7 +443,7 @@ int kvm_alloc_stage2_pgd(struct kvm *kvm)
>> * destroying the VM), otherwise another faulting VCPU may come in and mess
>> * with things behind our backs.
>> */
>> -static void unmap_stage2_range(struct kvm *kvm, phys_addr_t start, u64 size)
>> +void unmap_stage2_range(struct kvm *kvm, phys_addr_t start, u64 size)
>> {
>> unmap_range(kvm, kvm->arch.pgd, start, size);
>> }
>>
>
> Looks sensible otherwise.
>
> Thanks!
>
> M.
>
WARNING: multiple messages have this Message-ID (diff)
From: Eric Auger <eric.auger@linaro.org>
To: Marc Zyngier <marc.zyngier@arm.com>
Cc: "eric.auger@st.com" <eric.auger@st.com>,
"christoffer.dall@linaro.org" <christoffer.dall@linaro.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"patches@linaro.org" <patches@linaro.org>,
"christophe.barnichon@st.com" <christophe.barnichon@st.com>
Subject: Re: [PATCH] ARM: KVM: Handle IPA unmapping on memory region deletion
Date: Thu, 03 Apr 2014 18:32:16 +0200 [thread overview]
Message-ID: <533D8D10.7070909@linaro.org> (raw)
In-Reply-To: <533D7D8B.2030806@arm.com>
On 04/03/2014 05:26 PM, Marc Zyngier wrote:
> Hi Eric,
>
> On 03/04/14 16:17, Eric Auger wrote:
>> Currently when a KVM region is removed using
>> kvm_vm_ioctl_set_memory_region (with memory region size equal to 0), the
>> corresponding intermediate physical memory is not unmapped.
>>
>> This patch unmaps the region's IPA range in
>> kvm_arch_commit_memory_region using unmap_stage2_range.
>>
>> The patch was tested on QEMU VFIO based use case where RAM memory region
>> creation/deletion frequently happens for IRQ handling.
>>
>> Notes:
>> - the KVM_MR_MOVE case shall request some similar addition but I cannot test
>> this currently
>
> I think you should try to handle it anyway. I'm sure you could hack QEMU
> to do this test it, but even if you don't, better plug that hole right now.
Hi Marc,
OK I will proceed
>
>> Signed-off-by: Eric Auger <eric.auger@linaro.org>
>> ---
>> arch/arm/include/asm/kvm_mmu.h | 2 ++
>> arch/arm/kvm/arm.c | 8 ++++++++
>> arch/arm/kvm/mmu.c | 2 +-
>> 3 files changed, 11 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
>> index 2d122ad..a91c863 100644
>> --- a/arch/arm/include/asm/kvm_mmu.h
>> +++ b/arch/arm/include/asm/kvm_mmu.h
>> @@ -52,6 +52,8 @@ void kvm_free_stage2_pgd(struct kvm *kvm);
>> int kvm_phys_addr_ioremap(struct kvm *kvm, phys_addr_t guest_ipa,
>> phys_addr_t pa, unsigned long size);
>>
>> +void unmap_stage2_range(struct kvm *kvm, phys_addr_t guest_ipa, u64 size);
>> +
>> int kvm_handle_guest_abort(struct kvm_vcpu *vcpu, struct kvm_run *run);
>>
>> void kvm_mmu_free_memory_caches(struct kvm_vcpu *vcpu);
>> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
>> index bd18bb8..9a4bc10 100644
>> --- a/arch/arm/kvm/arm.c
>> +++ b/arch/arm/kvm/arm.c
>> @@ -241,6 +241,14 @@ void kvm_arch_commit_memory_region(struct kvm *kvm,
>> const struct kvm_memory_slot *old,
>> enum kvm_mr_change change)
>> {
>> + if (change == KVM_MR_DELETE) {
>> + gpa_t gpa = old->base_gfn << PAGE_SHIFT;
>> + u64 size = old->npages << PAGE_SHIFT;
>> +
>> + spin_lock(&kvm->mmu_lock);
>> + unmap_stage2_range(kvm, gpa, size);
>> + spin_unlock(&kvm->mmu_lock);
>> + }
>> }
>
> Just move the whole function to mmu.c, as it makes more sense to have it
> there. And while you're at it, how about moving the other
> memslot/memory_region stubs?
OK I will move:
kvm_arch_free_memslot,
kvm_arch_create_memslot,
kvm_arch_prepare_memory_region,
kvm_arch_commit_memory_region,
kvm_arch_shadow_all and
kvm_arch_shadow_memslot then.
Best Regards
Eric
>
>> void kvm_arch_flush_shadow_all(struct kvm *kvm)
>> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
>> index 7789857..e8580e2 100644
>> --- a/arch/arm/kvm/mmu.c
>> +++ b/arch/arm/kvm/mmu.c
>> @@ -443,7 +443,7 @@ int kvm_alloc_stage2_pgd(struct kvm *kvm)
>> * destroying the VM), otherwise another faulting VCPU may come in and mess
>> * with things behind our backs.
>> */
>> -static void unmap_stage2_range(struct kvm *kvm, phys_addr_t start, u64 size)
>> +void unmap_stage2_range(struct kvm *kvm, phys_addr_t start, u64 size)
>> {
>> unmap_range(kvm, kvm->arch.pgd, start, size);
>> }
>>
>
> Looks sensible otherwise.
>
> Thanks!
>
> M.
>
next prev parent reply other threads:[~2014-04-03 16:32 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-03 15:17 [PATCH] ARM: KVM: Handle IPA unmapping on memory region deletion Eric Auger
2014-04-03 15:17 ` Eric Auger
2014-04-03 15:26 ` Marc Zyngier
2014-04-03 15:26 ` Marc Zyngier
2014-04-03 16:32 ` Eric Auger [this message]
2014-04-03 16:32 ` Eric Auger
2014-04-03 17:07 ` Christoffer Dall
2014-04-03 17:07 ` Christoffer Dall
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=533D8D10.7070909@linaro.org \
--to=eric.auger@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
/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.