All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Raslan, KarimAllah" <karahmed@amazon.de>
To: "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: "marc.zyngier@arm.com" <marc.zyngier@arm.com>,
	"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>
Subject: Re: [PATCH] KVM: arm/arm64: Properly check for MMIO regions
Date: Fri, 12 Jul 2019 15:58:23 +0000	[thread overview]
Message-ID: <1562947103.19043.1.camel@amazon.de> (raw)
In-Reply-To: <1562919728-642-1-git-send-email-karahmed@amazon.de>

On Fri, 2019-07-12 at 10:22 +0200, KarimAllah Ahmed wrote:
> Valid RAM can live outside kernel control (e.g. using "mem=" command-line
> parameter). This memory can still be used as valid guest memory for KVM. So
> ensure that we validate that this memory is definitely not "RAM" before
> assuming that it is an MMIO region.

This patch actually suffers from the same problem pointed out here:
https://lkml.org/lkml/2019/7/12/760

.. so I will need to rework them together.

> 
> One way to use memory outside kernel control is:
> 
> 1- Pass 'mem=' in the kernel command-line to limit the amount of memory managed
>    by the kernel.
> 2- Map this physical memory you want to give to the guest with:
>    mmap("/dev/mem", physical_address_offset, ..)
> 3- Use the user-space virtual address as the "userspace_addr" field in
>    KVM_SET_USER_MEMORY_REGION ioctl.
> 
> One of the limitations of the current /dev/mem for ARM is that it would map
> this memory as uncached without this patch:
> https://lkml.org/lkml/2019/7/11/684
> 
> This work is similar to the work done on x86 here:
> https://lkml.org/lkml/2019/1/31/933
> 
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: James Morse <james.morse@arm.com>
> Cc: Julien Thierry <julien.thierry@arm.com>
> Cc: Suzuki K Pouloze <suzuki.poulose@arm.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: kvmarm@lists.cs.columbia.edu
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: KarimAllah Ahmed <karahmed@amazon.de>
> ---
>  virt/kvm/arm/mmu.c | 18 ++++++++++++------
>  1 file changed, 12 insertions(+), 6 deletions(-)
> 
> diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
> index 06180c9..2105134 100644
> --- a/virt/kvm/arm/mmu.c
> +++ b/virt/kvm/arm/mmu.c
> @@ -8,6 +8,7 @@
>  #include <linux/kvm_host.h>
>  #include <linux/io.h>
>  #include <linux/hugetlb.h>
> +#include <linux/memblock.h>
>  #include <linux/sched/signal.h>
>  #include <trace/events/kvm.h>
>  #include <asm/pgalloc.h>
> @@ -89,7 +90,7 @@ static void kvm_flush_dcache_pud(struct kvm *kvm,
>  
>  static bool kvm_is_device_pfn(unsigned long pfn)
>  {
> -	return !pfn_valid(pfn);
> +	return !memblock_is_memory(__pfn_to_phys(pfn));
>  }
>  
>  /**
> @@ -949,6 +950,7 @@ static void stage2_unmap_memslot(struct kvm *kvm,
>  	do {
>  		struct vm_area_struct *vma = find_vma(current->mm, hva);
>  		hva_t vm_start, vm_end;
> +		gpa_t gpa;
>  
>  		if (!vma || vma->vm_start >= reg_end)
>  			break;
> @@ -959,11 +961,14 @@ static void stage2_unmap_memslot(struct kvm *kvm,
>  		vm_start = max(hva, vma->vm_start);
>  		vm_end = min(reg_end, vma->vm_end);
>  
> -		if (!(vma->vm_flags & VM_PFNMAP)) {
> -			gpa_t gpa = addr + (vm_start - memslot->userspace_addr);
> -			unmap_stage2_range(kvm, gpa, vm_end - vm_start);
> -		}
>  		hva = vm_end;
> +
> +		if ((vma->vm_flags & VM_PFNMAP) &&
> +		    !memblock_is_memory(__pfn_to_phys(vma->vm_pgoff)))
> +			continue;
> +
> +		gpa = addr + (vm_start - memslot->userspace_addr);
> +		unmap_stage2_range(kvm, gpa, vm_end - vm_start);
>  	} while (hva < reg_end);
>  }
>  
> @@ -2329,7 +2334,8 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm,
>  		vm_start = max(hva, vma->vm_start);
>  		vm_end = min(reg_end, vma->vm_end);
>  
> -		if (vma->vm_flags & VM_PFNMAP) {
> +		if ((vma->vm_flags & VM_PFNMAP) &&
> +		    !memblock_is_memory(__pfn_to_phys(vma->vm_pgoff))) {
>  			gpa_t gpa = mem->guest_phys_addr +
>  				    (vm_start - mem->userspace_addr);
>  			phys_addr_t pa;



Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879


_______________________________________________
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: "Raslan, KarimAllah" <karahmed@amazon.de>
To: "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: "marc.zyngier@arm.com" <marc.zyngier@arm.com>,
	"suzuki.poulose@arm.com" <suzuki.poulose@arm.com>,
	"james.morse@arm.com" <james.morse@arm.com>,
	"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>,
	"julien.thierry@arm.com" <julien.thierry@arm.com>
Subject: Re: [PATCH] KVM: arm/arm64: Properly check for MMIO regions
Date: Fri, 12 Jul 2019 15:58:23 +0000	[thread overview]
Message-ID: <1562947103.19043.1.camel@amazon.de> (raw)
In-Reply-To: <1562919728-642-1-git-send-email-karahmed@amazon.de>

On Fri, 2019-07-12 at 10:22 +0200, KarimAllah Ahmed wrote:
> Valid RAM can live outside kernel control (e.g. using "mem=" command-line
> parameter). This memory can still be used as valid guest memory for KVM. So
> ensure that we validate that this memory is definitely not "RAM" before
> assuming that it is an MMIO region.

This patch actually suffers from the same problem pointed out here:
https://lkml.org/lkml/2019/7/12/760

.. so I will need to rework them together.

> 
> One way to use memory outside kernel control is:
> 
> 1- Pass 'mem=' in the kernel command-line to limit the amount of memory managed
>    by the kernel.
> 2- Map this physical memory you want to give to the guest with:
>    mmap("/dev/mem", physical_address_offset, ..)
> 3- Use the user-space virtual address as the "userspace_addr" field in
>    KVM_SET_USER_MEMORY_REGION ioctl.
> 
> One of the limitations of the current /dev/mem for ARM is that it would map
> this memory as uncached without this patch:
> https://lkml.org/lkml/2019/7/11/684
> 
> This work is similar to the work done on x86 here:
> https://lkml.org/lkml/2019/1/31/933
> 
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: James Morse <james.morse@arm.com>
> Cc: Julien Thierry <julien.thierry@arm.com>
> Cc: Suzuki K Pouloze <suzuki.poulose@arm.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: kvmarm@lists.cs.columbia.edu
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: KarimAllah Ahmed <karahmed@amazon.de>
> ---
>  virt/kvm/arm/mmu.c | 18 ++++++++++++------
>  1 file changed, 12 insertions(+), 6 deletions(-)
> 
> diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
> index 06180c9..2105134 100644
> --- a/virt/kvm/arm/mmu.c
> +++ b/virt/kvm/arm/mmu.c
> @@ -8,6 +8,7 @@
>  #include <linux/kvm_host.h>
>  #include <linux/io.h>
>  #include <linux/hugetlb.h>
> +#include <linux/memblock.h>
>  #include <linux/sched/signal.h>
>  #include <trace/events/kvm.h>
>  #include <asm/pgalloc.h>
> @@ -89,7 +90,7 @@ static void kvm_flush_dcache_pud(struct kvm *kvm,
>  
>  static bool kvm_is_device_pfn(unsigned long pfn)
>  {
> -	return !pfn_valid(pfn);
> +	return !memblock_is_memory(__pfn_to_phys(pfn));
>  }
>  
>  /**
> @@ -949,6 +950,7 @@ static void stage2_unmap_memslot(struct kvm *kvm,
>  	do {
>  		struct vm_area_struct *vma = find_vma(current->mm, hva);
>  		hva_t vm_start, vm_end;
> +		gpa_t gpa;
>  
>  		if (!vma || vma->vm_start >= reg_end)
>  			break;
> @@ -959,11 +961,14 @@ static void stage2_unmap_memslot(struct kvm *kvm,
>  		vm_start = max(hva, vma->vm_start);
>  		vm_end = min(reg_end, vma->vm_end);
>  
> -		if (!(vma->vm_flags & VM_PFNMAP)) {
> -			gpa_t gpa = addr + (vm_start - memslot->userspace_addr);
> -			unmap_stage2_range(kvm, gpa, vm_end - vm_start);
> -		}
>  		hva = vm_end;
> +
> +		if ((vma->vm_flags & VM_PFNMAP) &&
> +		    !memblock_is_memory(__pfn_to_phys(vma->vm_pgoff)))
> +			continue;
> +
> +		gpa = addr + (vm_start - memslot->userspace_addr);
> +		unmap_stage2_range(kvm, gpa, vm_end - vm_start);
>  	} while (hva < reg_end);
>  }
>  
> @@ -2329,7 +2334,8 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm,
>  		vm_start = max(hva, vma->vm_start);
>  		vm_end = min(reg_end, vma->vm_end);
>  
> -		if (vma->vm_flags & VM_PFNMAP) {
> +		if ((vma->vm_flags & VM_PFNMAP) &&
> +		    !memblock_is_memory(__pfn_to_phys(vma->vm_pgoff))) {
>  			gpa_t gpa = mem->guest_phys_addr +
>  				    (vm_start - mem->userspace_addr);
>  			phys_addr_t pa;



Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879


_______________________________________________
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: "Raslan, KarimAllah" <karahmed@amazon.de>
To: "linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: "marc.zyngier@arm.com" <marc.zyngier@arm.com>,
	"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>,
	"james.morse@arm.com" <james.morse@arm.com>,
	"julien.thierry@arm.com" <julien.thierry@arm.com>,
	"suzuki.poulose@arm.com" <suzuki.poulose@arm.com>
Subject: Re: [PATCH] KVM: arm/arm64: Properly check for MMIO regions
Date: Fri, 12 Jul 2019 15:58:23 +0000	[thread overview]
Message-ID: <1562947103.19043.1.camel@amazon.de> (raw)
In-Reply-To: <1562919728-642-1-git-send-email-karahmed@amazon.de>

On Fri, 2019-07-12 at 10:22 +0200, KarimAllah Ahmed wrote:
> Valid RAM can live outside kernel control (e.g. using "mem=" command-line
> parameter). This memory can still be used as valid guest memory for KVM. So
> ensure that we validate that this memory is definitely not "RAM" before
> assuming that it is an MMIO region.

This patch actually suffers from the same problem pointed out here:
https://lkml.org/lkml/2019/7/12/760

.. so I will need to rework them together.

> 
> One way to use memory outside kernel control is:
> 
> 1- Pass 'mem=' in the kernel command-line to limit the amount of memory managed
>    by the kernel.
> 2- Map this physical memory you want to give to the guest with:
>    mmap("/dev/mem", physical_address_offset, ..)
> 3- Use the user-space virtual address as the "userspace_addr" field in
>    KVM_SET_USER_MEMORY_REGION ioctl.
> 
> One of the limitations of the current /dev/mem for ARM is that it would map
> this memory as uncached without this patch:
> https://lkml.org/lkml/2019/7/11/684
> 
> This work is similar to the work done on x86 here:
> https://lkml.org/lkml/2019/1/31/933
> 
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: James Morse <james.morse@arm.com>
> Cc: Julien Thierry <julien.thierry@arm.com>
> Cc: Suzuki K Pouloze <suzuki.poulose@arm.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: kvmarm@lists.cs.columbia.edu
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: KarimAllah Ahmed <karahmed@amazon.de>
> ---
>  virt/kvm/arm/mmu.c | 18 ++++++++++++------
>  1 file changed, 12 insertions(+), 6 deletions(-)
> 
> diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
> index 06180c9..2105134 100644
> --- a/virt/kvm/arm/mmu.c
> +++ b/virt/kvm/arm/mmu.c
> @@ -8,6 +8,7 @@
>  #include <linux/kvm_host.h>
>  #include <linux/io.h>
>  #include <linux/hugetlb.h>
> +#include <linux/memblock.h>
>  #include <linux/sched/signal.h>
>  #include <trace/events/kvm.h>
>  #include <asm/pgalloc.h>
> @@ -89,7 +90,7 @@ static void kvm_flush_dcache_pud(struct kvm *kvm,
>  
>  static bool kvm_is_device_pfn(unsigned long pfn)
>  {
> -	return !pfn_valid(pfn);
> +	return !memblock_is_memory(__pfn_to_phys(pfn));
>  }
>  
>  /**
> @@ -949,6 +950,7 @@ static void stage2_unmap_memslot(struct kvm *kvm,
>  	do {
>  		struct vm_area_struct *vma = find_vma(current->mm, hva);
>  		hva_t vm_start, vm_end;
> +		gpa_t gpa;
>  
>  		if (!vma || vma->vm_start >= reg_end)
>  			break;
> @@ -959,11 +961,14 @@ static void stage2_unmap_memslot(struct kvm *kvm,
>  		vm_start = max(hva, vma->vm_start);
>  		vm_end = min(reg_end, vma->vm_end);
>  
> -		if (!(vma->vm_flags & VM_PFNMAP)) {
> -			gpa_t gpa = addr + (vm_start - memslot->userspace_addr);
> -			unmap_stage2_range(kvm, gpa, vm_end - vm_start);
> -		}
>  		hva = vm_end;
> +
> +		if ((vma->vm_flags & VM_PFNMAP) &&
> +		    !memblock_is_memory(__pfn_to_phys(vma->vm_pgoff)))
> +			continue;
> +
> +		gpa = addr + (vm_start - memslot->userspace_addr);
> +		unmap_stage2_range(kvm, gpa, vm_end - vm_start);
>  	} while (hva < reg_end);
>  }
>  
> @@ -2329,7 +2334,8 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm,
>  		vm_start = max(hva, vma->vm_start);
>  		vm_end = min(reg_end, vma->vm_end);
>  
> -		if (vma->vm_flags & VM_PFNMAP) {
> +		if ((vma->vm_flags & VM_PFNMAP) &&
> +		    !memblock_is_memory(__pfn_to_phys(vma->vm_pgoff))) {
>  			gpa_t gpa = mem->guest_phys_addr +
>  				    (vm_start - mem->userspace_addr);
>  			phys_addr_t pa;



Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879



  reply	other threads:[~2019-07-12 15:58 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-12  8:22 [PATCH] KVM: arm/arm64: Properly check for MMIO regions KarimAllah Ahmed
2019-07-12  8:22 ` KarimAllah Ahmed
2019-07-12  8:22 ` KarimAllah Ahmed
2019-07-12 15:58 ` Raslan, KarimAllah [this message]
2019-07-12 15:58   ` Raslan, KarimAllah
2019-07-12 15:58   ` Raslan, KarimAllah
2019-07-24 11:08 ` James Morse
2019-07-24 11:08   ` James Morse
2019-07-24 11:08   ` James Morse

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=1562947103.19043.1.camel@amazon.de \
    --to=karahmed@amazon.de \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marc.zyngier@arm.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.