Re: [patch 01/12] [PATCH] kvm-s390: add parameter for KVM_CREATE_VM

2011-12-12 Thread Avi Kivity
On 12/10/2011 02:35 PM, Carsten Otte wrote:
 This patch introduces a new config option for user controlled kernel
 virtual machines. It introduces an optional parameter to
 KVM_CREATE_VM in order to create a user controlled virtual machine.
 The parameter is passed to kvm_arch_init_vm for all architectures.
 Valid values for the new parameter are KVM_VM_REGULAR (defined to 0
 for backward compatibility to old KVM_CREATE_VM) and
 KVM_VM_UCONTROL for s390 only.
 Note that the user controlled virtual machines require CAP_SYS_ADMIN
 privileges.

 @@ -103,6 +103,11 @@ will access the virtual machine's physic
  corresponds to guest physical address zero.  Use of mmap() on a VM fd
  is discouraged if userspace memory allocation (KVM_CAP_USER_MEMORY) is
  available.
 +You most certainly want to use KVM_VM_REGULAR as machine type.
 +
 +In order to create user controlled virtual machines on S390, check
 +KVM_CAP_UCONTROL and use KVM_VM_UCONTROL as machine type as
 +privileged user (CAP_SYS_ADMIN).

Old kernels don't expose KVM_VM_REGULAR, so if people follow the
recommendations, their userspace won't build.  Normal guests must be 0.

We can pretend we planned this all along by making the argument a flags
mask, and claiming bit 0 for UCONTROL.

  
  
 +config KVM_UCONTROL
 + bool Userspace controlled virtual machines
 + depends on KVM
 + ---help---
 +   Allow CAP_SYS_ADMIN users to create KVM virtual machines that are
 +   controlled by userspace.
 +

SYS_ADMIN is not really a good match for this, but no better idea.

-- 
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [patch 01/12] [PATCH] kvm-s390: add parameter for KVM_CREATE_VM

2011-12-12 Thread Carsten Otte

On 12.12.2011 10:13, Avi Kivity wrote:

Old kernels don't expose KVM_VM_REGULAR, so if people follow the
recommendations, their userspace won't build.  Normal guests must be 0.

We can pretend we planned this all along by making the argument a flags
mask, and claiming bit 0 for UCONTROL.

That's a smart idea, I like that. Will change it towards a bitmask.

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [patch 01/12] [PATCH] kvm-s390: add parameter for KVM_CREATE_VM

2011-12-09 Thread Alexander Graf

On 09.12.2011, at 12:23, Carsten Otte wrote:

 This patch introduces a new config option for user controlled kernel
 virtual machines. It introduces an optional parameter to
 KVM_CREATE_VM in order to create a user controlled virtual machine.
 The parameter is passed to kvm_arch_init_vm for all architectures.
 Valid values for the new parameter are KVM_VM_REGULAR (defined to 0
 for backward compatibility to old KVM_CREATE_VM) and
 KVM_VM_UCONTROL for s390 only.
 Note that the user controlled virtual machines require CAP_SYS_ADMIN
 privileges.
 
 Signed-off-by: Carsten Otte co...@de.ibm.com
 ---
 ---
 Documentation/virtual/kvm/api.txt |7 ++-
 arch/ia64/kvm/kvm-ia64.c  |5 -
 arch/powerpc/kvm/powerpc.c|5 -
 arch/s390/kvm/Kconfig |9 +
 arch/s390/kvm/kvm-s390.c  |   30 +-
 arch/s390/kvm/kvm-s390.h  |   10 ++
 arch/x86/kvm/x86.c|5 -
 include/linux/kvm.h   |3 +++
 include/linux/kvm_host.h  |2 +-
 virt/kvm/kvm_main.c   |   19 +--
 10 files changed, 79 insertions(+), 16 deletions(-)
 
 --- a/Documentation/virtual/kvm/api.txt
 +++ b/Documentation/virtual/kvm/api.txt
 @@ -95,7 +95,7 @@ described as 'basic' will be available.
 Capability: basic
 Architectures: all
 Type: system ioctl
 -Parameters: none
 +Parameters: machine type identifier (KVM_VM_*)
 Returns: a VM fd that can be used to control the new virtual machine.
 
 The new VM has no virtual cpus and no memory.  An mmap() of a VM fd
 @@ -103,6 +103,11 @@ will access the virtual machine's physic
 corresponds to guest physical address zero.  Use of mmap() on a VM fd
 is discouraged if userspace memory allocation (KVM_CAP_USER_MEMORY) is
 available.
 +You most certainly want to use KVM_VM_REGULAR as machine type.
 +
 +In order to create user controlled virtual machines on S390, check
 +KVM_CAP_UCONTROL

KVM_S390_CAP_UCONTROL

 and use KVM_VM_UCONTROL as machine type as
 +privileged user (CAP_SYS_ADMIN).

Why not

KVM_ENABLE_CAP(KVM_S390_CAP_UCONTROL)? It doesn't look like you can't switch 
from kernel-controlled to user controlled mode during runtime. All you need to 
do is remove the gmap again and you should be fine, no?

We do something similar on PPC where we just call ENABLE_CAP to switch to PAPR 
mode. If otherwise too difficult you can for example also define that the 
ENABLE_CAP has to happen before your first VCPU_RUN.

Alex

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [patch 01/12] [PATCH] kvm-s390: add parameter for KVM_CREATE_VM

2011-12-09 Thread Carsten Otte

On 09.12.2011 12:32, Alexander Graf wrote:

+KVM_CAP_UCONTROL

KVM_S390_CAP_UCONTROL
I'm happy either way. It seemed to me that the discussion between Avi 
and Sasha for V2 of the patch series on this naming has concluded to 
KVM_CAP_UCONTROL/KVM_VM_UCONTROL without _S390 in it.



KVM_ENABLE_CAP(KVM_S390_CAP_UCONTROL)? It doesn't look like you can't switch 
from kernel-controlled to user controlled mode during runtime. All you need to 
do is remove the gmap again and you should be fine, no?

This was the case via an ioctl KVM_S390_ENABLE_UCONTROL in version 1.
Avi pointed out some possible race conditions with that, and recommended 
to switch it via KVM_CREATE_VM. I'm happy either way, just let me know 
what's prefered.



We do something similar on PPC where we just call ENABLE_CAP to switch to PAPR 
mode. If otherwise too difficult you can for example also define that the 
ENABLE_CAP has to happen before your first VCPU_RUN.

Code looks to me like you do ENABLE_CAP per vcpu on ppc (chapter 4.37
of api.txt agrees with that). We need something per VM, we cannot switch 
individual CPUs between ucontrol/regular because with ucontrol the VM 
does not have a common address space.


--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html