All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <sean.j.christopherson@intel.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [PATCH] kvm: move KVM_CAP_NR_MEMSLOTS to common code
Date: Tue, 2 Apr 2019 07:51:09 -0700	[thread overview]
Message-ID: <20190402145109.GA29004@linux.intel.com> (raw)
In-Reply-To: <1553793000-53968-1-git-send-email-pbonzini@redhat.com>

On Thu, Mar 28, 2019 at 06:10:00PM +0100, Paolo Bonzini wrote:
> All architectures except MIPS were defining it in the same way,
> and memory slots are handled entirely by common code so there
> is no point in keeping the definition per-architecture.
> 
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
>  Documentation/virtual/kvm/api.txt | 5 ++---
>  arch/powerpc/kvm/powerpc.c        | 3 ---
>  arch/s390/kvm/kvm-s390.c          | 3 ---
>  arch/x86/kvm/x86.c                | 3 ---
>  virt/kvm/arm/arm.c                | 3 ---
>  virt/kvm/kvm_main.c               | 2 ++
>  6 files changed, 4 insertions(+), 15 deletions(-)
> 
> diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
> index 67068c47c591..b62ad0d94234 100644
> --- a/Documentation/virtual/kvm/api.txt
> +++ b/Documentation/virtual/kvm/api.txt
> @@ -1117,9 +1117,8 @@ struct kvm_userspace_memory_region {
>  This ioctl allows the user to create, modify or delete a guest physical
>  memory slot.  Bits 0-15 of "slot" specify the slot id and this value
>  should be less than the maximum number of user memory slots supported per
> -VM.  The maximum allowed slots can be queried using KVM_CAP_NR_MEMSLOTS,
> -if this capability is supported by the architecture.  Slots may not
> -overlap in guest physical address space.
> +VM.  The maximum allowed slots can be queried using KVM_CAP_NR_MEMSLOTS.
> +Slots may not overlap in guest physical address space.

Nit: s/may/must in that last sentence while you're at it?

Reviewed-by: Sean Christopherson <sean.j.christopherson@intel.com>

>  
>  If KVM_CAP_MULTI_ADDRESS_SPACE is available, bits 16-31 of "slot"
>  specifies the address space which is being modified.  They must be
> diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
> index 8885377ec3e0..92910b7c5bcc 100644
> --- a/arch/powerpc/kvm/powerpc.c
> +++ b/arch/powerpc/kvm/powerpc.c
> @@ -644,9 +644,6 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
>  		else
>  			r = num_online_cpus();
>  		break;
> -	case KVM_CAP_NR_MEMSLOTS:
> -		r = KVM_USER_MEM_SLOTS;
> -		break;
>  	case KVM_CAP_MAX_VCPUS:
>  		r = KVM_MAX_VCPUS;
>  		break;
> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
> index 4638303ba6a8..28f35d2b06cb 100644
> --- a/arch/s390/kvm/kvm-s390.c
> +++ b/arch/s390/kvm/kvm-s390.c
> @@ -513,9 +513,6 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
>  		else if (sclp.has_esca && sclp.has_64bscao)
>  			r = KVM_S390_ESCA_CPU_SLOTS;
>  		break;
> -	case KVM_CAP_NR_MEMSLOTS:
> -		r = KVM_USER_MEM_SLOTS;
> -		break;
>  	case KVM_CAP_S390_COW:
>  		r = MACHINE_HAS_ESOP;
>  		break;
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 099b851dabaf..9b64d3359c93 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -3073,9 +3073,6 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
>  	case KVM_CAP_MAX_VCPUS:
>  		r = KVM_MAX_VCPUS;
>  		break;
> -	case KVM_CAP_NR_MEMSLOTS:
> -		r = KVM_USER_MEM_SLOTS;
> -		break;
>  	case KVM_CAP_PV_MMU:	/* obsolete */
>  		r = 0;
>  		break;
> diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
> index 99c37384ba7b..be4ec5f3ba5f 100644
> --- a/virt/kvm/arm/arm.c
> +++ b/virt/kvm/arm/arm.c
> @@ -224,9 +224,6 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
>  	case KVM_CAP_MAX_VCPUS:
>  		r = KVM_MAX_VCPUS;
>  		break;
> -	case KVM_CAP_NR_MEMSLOTS:
> -		r = KVM_USER_MEM_SLOTS;
> -		break;
>  	case KVM_CAP_MSI_DEVID:
>  		if (!kvm)
>  			r = -EINVAL;
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 55fe8e20d8fd..31c28e0b067c 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -3061,6 +3061,8 @@ static long kvm_vm_ioctl_check_extension_generic(struct kvm *kvm, long arg)
>  #endif
>  	case KVM_CAP_MAX_VCPU_ID:
>  		return KVM_MAX_VCPU_ID;
> +	case KVM_CAP_NR_MEMSLOTS:
> +		return KVM_USER_MEM_SLOTS;
>  	default:
>  		break;
>  	}
> -- 
> 1.8.3.1
> 

      parent reply	other threads:[~2019-04-02 14:51 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-28 17:10 [PATCH] kvm: move KVM_CAP_NR_MEMSLOTS to common code Paolo Bonzini
2019-03-29  9:43 ` David Hildenbrand
2019-04-02 11:57 ` Cornelia Huck
2019-04-02 14:51 ` Sean Christopherson [this message]

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=20190402145109.GA29004@linux.intel.com \
    --to=sean.j.christopherson@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.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.