Re: [patch 01/12] [PATCH] kvm-s390: add parameter for KVM_CREATE_VM
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
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
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
Re: [patch 01/12] [PATCH] kvm-s390: add parameter for KVM_CREATE_VM
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 > --- > --- > 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