| Message ID | 1396363663-50450-2-git-send-email-borntraeger@de.ibm.com |
|---|---|
| State | New |
| Headers | show |
On 04/01/2014 04:47 PM, Christian Borntraeger wrote: > From: Ekaterina Tumanova <tumanova@linux.vnet.ibm.com> > > Add KVM_DEV_TYPE_S390_CONFIG kvm device that contains > configuration and control attributes of particular vm. > The device is created by KVM_CREATE_DEVICE ioctl. > The attributes may be retrieved and stored by calling > KVM_GET_DEVICE_ATTR and KVM_SET_DEVICE_ATTR ioctls. > > Signed-off-by: Ekaterina Tumanova <tumanova@linux.vnet.ibm.com> > Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> I don't think a device is particularly the best fit. A device can usually be instantiated multiple times. The configuration device can only be created once. A device also gets created by user space which enables it to receive the fd to drive it. Your device has to be created during VM creation. I think VM configuration is common enough to just make this a separate interface. Alex
On 01/04/14 16:58, Alexander Graf wrote: > On 04/01/2014 04:47 PM, Christian Borntraeger wrote: >> From: Ekaterina Tumanova <tumanova@linux.vnet.ibm.com> >> >> Add KVM_DEV_TYPE_S390_CONFIG kvm device that contains >> configuration and control attributes of particular vm. >> The device is created by KVM_CREATE_DEVICE ioctl. >> The attributes may be retrieved and stored by calling >> KVM_GET_DEVICE_ATTR and KVM_SET_DEVICE_ATTR ioctls. >> >> Signed-off-by: Ekaterina Tumanova <tumanova@linux.vnet.ibm.com> >> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> > > I don't think a device is particularly the best fit. A device can usually be instantiated multiple times. The configuration device can only be created once. A device also gets created by user space which enables it to receive the fd to drive it. Your device has to be created during VM creation. I remember some discussion a year or 2 ago, and IIRC a config device was actually your idea ;-) (The other idea that we had, was ONE_REG for the VM) > > I think VM configuration is common enough to just make this a separate interface. So you propose to define a new base ioctl (e.g. VM_REG) on the vm fd, instead? Seems like an easy enough change. Would you reuse the kvm_attr structure for that? > > > Alex >
On 04/01/2014 05:04 PM, Christian Borntraeger wrote: > On 01/04/14 16:58, Alexander Graf wrote: >> On 04/01/2014 04:47 PM, Christian Borntraeger wrote: >>> From: Ekaterina Tumanova <tumanova@linux.vnet.ibm.com> >>> >>> Add KVM_DEV_TYPE_S390_CONFIG kvm device that contains >>> configuration and control attributes of particular vm. >>> The device is created by KVM_CREATE_DEVICE ioctl. >>> The attributes may be retrieved and stored by calling >>> KVM_GET_DEVICE_ATTR and KVM_SET_DEVICE_ATTR ioctls. >>> >>> Signed-off-by: Ekaterina Tumanova <tumanova@linux.vnet.ibm.com> >>> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> >> I don't think a device is particularly the best fit. A device can usually be instantiated multiple times. The configuration device can only be created once. A device also gets created by user space which enables it to receive the fd to drive it. Your device has to be created during VM creation. > I remember some discussion a year or 2 ago, and IIRC a config device > was actually your idea ;-) (The other idea that we had, was ONE_REG for the VM) Omg, really? :o A device would make sense for a specific "system information" instruction trap that we handle in-kernel for whatever reason (usually because it's performance critical) and some mandatory say to make sure user space always creates it. And some checks to make sure it can't get created twice. Speaking of which, why don't we just forward STSI to user space with an ENABLE_CAP and handle all of this there? It's not performance critical at all, right? >> I think VM configuration is common enough to just make this a separate interface. > So you propose to define a new base ioctl (e.g. VM_REG) on the vm fd, instead? > Seems like an easy enough change. Would you reuse the kvm_attr structure for that? Yeah, reuse whatever we can. Basically just remove the device boilerplate - I don't think it's impressively useful for a non-device. Alex
On 01/04/14 17:12, Alexander Graf wrote: > On 04/01/2014 05:04 PM, Christian Borntraeger wrote: >> On 01/04/14 16:58, Alexander Graf wrote: >>> On 04/01/2014 04:47 PM, Christian Borntraeger wrote: >>>> From: Ekaterina Tumanova <tumanova@linux.vnet.ibm.com> >>>> >>>> Add KVM_DEV_TYPE_S390_CONFIG kvm device that contains >>>> configuration and control attributes of particular vm. >>>> The device is created by KVM_CREATE_DEVICE ioctl. >>>> The attributes may be retrieved and stored by calling >>>> KVM_GET_DEVICE_ATTR and KVM_SET_DEVICE_ATTR ioctls. >>>> >>>> Signed-off-by: Ekaterina Tumanova <tumanova@linux.vnet.ibm.com> >>>> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> >>> I don't think a device is particularly the best fit. A device can usually be instantiated multiple times. The configuration device can only be created once. A device also gets created by user space which enables it to receive the fd to drive it. Your device has to be created during VM creation. >> I remember some discussion a year or 2 ago, and IIRC a config device >> was actually your idea ;-) (The other idea that we had, was ONE_REG for the VM) > > Omg, really? :o > > A device would make sense for a specific "system information" instruction trap that we handle in-kernel for whatever reason (usually because it's performance critical) and some mandatory say to make sure user space always creates it. And some checks to make sure it can't get created twice. Well the device created twice problem is also true for all existing KVM devices. The only missing piece is the check in the config device, no? > > Speaking of which, why don't we just forward STSI to user space with an ENABLE_CAP and handle all of this there? It's not performance critical at all, right? No, performance is not critical. The thing is, that we definitely need the kernel to handle parts of STSI, as we have to provide information from the upper hipervisor (LPAR or zVM). This information is only available in kernel space. So in essence we could only forward a small subset of STSI, namely stsi3_2_2. But we still have to call stsi_3_2_2 in the kernel, as 3_2_2 does contain the list of hipervisors underneath us (KVM under z/VM). So then only thing that we could do is to forward STSI_3_2_2 to qemu when a capability is set and after the kernel has filled in the upper layers. QEMU then has to modify the page that the kernel touched and go back. Would work, but needs a capability and preferably an own exit. An new ioctl or a subcode of an ioctl (attr/group whatever) seems easier. > >>> I think VM configuration is common enough to just make this a separate interface. >> So you propose to define a new base ioctl (e.g. VM_REG) on the vm fd, instead? >> Seems like an easy enough change. Would you reuse the kvm_attr structure for that? > > Yeah, reuse whatever we can. Basically just remove the device boilerplate - I don't think it's impressively useful for a non-device. See above, name is just a simple first user. The thing is, that we have to have the ioctl either define a proper namespace (unique groups attrs) or to make it s390 specific. The device approach does help us here. I personally dont mind which way to go, as long as Paolo is fine with the approach, and nobody complains about the functions being non-QOM. Christian
On 01.04.2014, at 21:19, Christian Borntraeger <borntraeger@de.ibm.com> wrote: > On 01/04/14 17:12, Alexander Graf wrote: >> On 04/01/2014 05:04 PM, Christian Borntraeger wrote: >>> On 01/04/14 16:58, Alexander Graf wrote: >>>> On 04/01/2014 04:47 PM, Christian Borntraeger wrote: >>>>> From: Ekaterina Tumanova <tumanova@linux.vnet.ibm.com> >>>>> >>>>> Add KVM_DEV_TYPE_S390_CONFIG kvm device that contains >>>>> configuration and control attributes of particular vm. >>>>> The device is created by KVM_CREATE_DEVICE ioctl. >>>>> The attributes may be retrieved and stored by calling >>>>> KVM_GET_DEVICE_ATTR and KVM_SET_DEVICE_ATTR ioctls. >>>>> >>>>> Signed-off-by: Ekaterina Tumanova <tumanova@linux.vnet.ibm.com> >>>>> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> >>>> I don't think a device is particularly the best fit. A device can usually be instantiated multiple times. The configuration device can only be created once. A device also gets created by user space which enables it to receive the fd to drive it. Your device has to be created during VM creation. >>> I remember some discussion a year or 2 ago, and IIRC a config device >>> was actually your idea ;-) (The other idea that we had, was ONE_REG for the VM) >> >> Omg, really? :o >> >> A device would make sense for a specific "system information" instruction trap that we handle in-kernel for whatever reason (usually because it's performance critical) and some mandatory say to make sure user space always creates it. And some checks to make sure it can't get created twice. > > Well the device created twice problem is also true for all existing KVM devices. > The only missing piece is the check in the config device, no? > >> >> Speaking of which, why don't we just forward STSI to user space with an ENABLE_CAP and handle all of this there? It's not performance critical at all, right? > > No, performance is not critical. > The thing is, that we definitely need the kernel to handle parts of STSI, as we have to provide information from the upper hipervisor (LPAR or zVM). This information is only available in kernel space. So in essence we could only forward a small subset of STSI, namely stsi3_2_2. But we still have to call stsi_3_2_2 in the kernel, > as 3_2_2 does contain the list of hipervisors underneath us (KVM under z/VM). > > So then only thing that we could do is to forward STSI_3_2_2 to qemu when a capability is set and after the kernel has filled in the upper layers. > QEMU then has to modify the page that the kernel touched and go back. Would work, but needs a capability and preferably an own exit. An new ioctl or > a subcode of an ioctl (attr/group whatever) seems easier. I would consider these 2 orthogonal bits of information. User space wants to get information about its underlying hypervisors regardless of KVM, no? So we should have some interface to bubble STSI information of the current system to user space either way. QEMU could use that and add a few bits of its own. That way we could handle all of STSI in QEMU and get out of the business of defining complicated interfaces. > >> >>>> I think VM configuration is common enough to just make this a separate interface. >>> So you propose to define a new base ioctl (e.g. VM_REG) on the vm fd, instead? >>> Seems like an easy enough change. Would you reuse the kvm_attr structure for that? >> >> Yeah, reuse whatever we can. Basically just remove the device boilerplate - I don't think it's impressively useful for a non-device. > > See above, name is just a simple first user. > The thing is, that we have to have the ioctl either define a proper namespace (unique groups attrs) or to make it s390 specific. The device approach does help us here. If you like the device approach, make sure to create it on VM creation and only implement a specific ioctl to fetch its fd. We don't create the configuration information pseudo device after VM creation - it's always there :). > I personally dont mind which way to go, as long as Paolo is fine with the approach, and nobody complains about the functions being non-QOM. I think the most obvious and straight forward way would be to deal with all of STSI in user space. Make it a separate exit type similar to hypercalls and don't worry about QOM'ification of anything. This thing is on the same level as CPUID really - just VM wide :). Alex
On 01.04.2014, at 21:19, Christian Borntraeger <borntraeger@de.ibm.com> wrote: > On 01/04/14 17:12, Alexander Graf wrote: >> On 04/01/2014 05:04 PM, Christian Borntraeger wrote: >>> On 01/04/14 16:58, Alexander Graf wrote: >>>> On 04/01/2014 04:47 PM, Christian Borntraeger wrote: >>>>> From: Ekaterina Tumanova <tumanova@linux.vnet.ibm.com> >>>>> >>>>> Add KVM_DEV_TYPE_S390_CONFIG kvm device that contains >>>>> configuration and control attributes of particular vm. >>>>> The device is created by KVM_CREATE_DEVICE ioctl. >>>>> The attributes may be retrieved and stored by calling >>>>> KVM_GET_DEVICE_ATTR and KVM_SET_DEVICE_ATTR ioctls. >>>>> >>>>> Signed-off-by: Ekaterina Tumanova <tumanova@linux.vnet.ibm.com> >>>>> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> >>>> I don't think a device is particularly the best fit. A device can usually be instantiated multiple times. The configuration device can only be created once. A device also gets created by user space which enables it to receive the fd to drive it. Your device has to be created during VM creation. >>> I remember some discussion a year or 2 ago, and IIRC a config device >>> was actually your idea ;-) (The other idea that we had, was ONE_REG for the VM) >> >> Omg, really? :o >> >> A device would make sense for a specific "system information" instruction trap that we handle in-kernel for whatever reason (usually because it's performance critical) and some mandatory say to make sure user space always creates it. And some checks to make sure it can't get created twice. > > Well the device created twice problem is also true for all existing KVM devices. > The only missing piece is the check in the config device, no? > >> >> Speaking of which, why don't we just forward STSI to user space with an ENABLE_CAP and handle all of this there? It's not performance critical at all, right? > > No, performance is not critical. > The thing is, that we definitely need the kernel to handle parts of STSI, as we have to provide information from the upper hipervisor (LPAR or zVM). This information is only available in kernel space. So in essence we could only forward a small subset of STSI, namely stsi3_2_2. But we still have to call stsi_3_2_2 in the kernel, > as 3_2_2 does contain the list of hipervisors underneath us (KVM under z/VM). > > So then only thing that we could do is to forward STSI_3_2_2 to qemu when a capability is set and after the kernel has filled in the upper layers. > QEMU then has to modify the page that the kernel touched and go back. Would work, but needs a capability and preferably an own exit. An new ioctl or > a subcode of an ioctl (attr/group whatever) seems easier. I would consider these 2 orthogonal bits of information. User space wants to get information about its underlying hypervisors regardless of KVM, no? So we should have some interface to bubble STSI information of the current system to user space either way. QEMU could use that and add a few bits of its own. That way we could handle all of STSI in QEMU and get out of the business of defining complicated interfaces. > >> >>>> I think VM configuration is common enough to just make this a separate interface. >>> So you propose to define a new base ioctl (e.g. VM_REG) on the vm fd, instead? >>> Seems like an easy enough change. Would you reuse the kvm_attr structure for that? >> >> Yeah, reuse whatever we can. Basically just remove the device boilerplate - I don't think it's impressively useful for a non-device. > > See above, name is just a simple first user. > The thing is, that we have to have the ioctl either define a proper namespace (unique groups attrs) or to make it s390 specific. The device approach does help us here. If you like the device approach, make sure to create it on VM creation and only implement a specific ioctl to fetch its fd. We don't create the configuration information pseudo device after VM creation - it's always there :). > I personally dont mind which way to go, as long as Paolo is fine with the approach, and nobody complains about the functions being non-QOM. I think the most obvious and straight forward way would be to deal with all of STSI in user space. Make it a separate exit type similar to hypercalls and don't worry about QOM'ification of anything. This thing is on the same level as CPUID really - just VM wide :). Alex
On 01/04/14 21:36, Alexander Graf wrote: [...] >>> Speaking of which, why don't we just forward STSI to user space with an ENABLE_CAP and handle all of this there? It's not performance critical at all, right? >> >> No, performance is not critical. >> The thing is, that we definitely need the kernel to handle parts of STSI, as we have to provide information from the upper hipervisor (LPAR or zVM). This information is only available in kernel space. So in essence we could only forward a small subset of STSI, namely stsi3_2_2. But we still have to call stsi_3_2_2 in the kernel, >> as 3_2_2 does contain the list of hipervisors underneath us (KVM under z/VM). >> >> So then only thing that we could do is to forward STSI_3_2_2 to qemu when a capability is set and after the kernel has filled in the upper layers. >> QEMU then has to modify the page that the kernel touched and go back. Would work, but needs a capability and preferably an own exit. An new ioctl or >> a subcode of an ioctl (attr/group whatever) seems easier. > > I would consider these 2 orthogonal bits of information. User space wants to get information about its underlying hypervisors regardless of KVM, no? So we should have some interface to bubble STSI information of the current system to user space either way. There is /proc/sysinfo and it provides most (but not all) of the STSI information. But we dont want to go that path, really. Providing STSI as binary blob is also complex and error-prone. Think about it again: Instead of having a small qemu->kernel interface for specific subsets of stsi, you suggest a kernel->qemu interface for the complete set of STSI, so that qemu can then emulate it? (We talk about 20 pages in the principles of operation). T > QEMU could use that and add a few bits of its own. That way we could handle all of STSI in QEMU and get out of the business of defining complicated interfaces. This also misses my main point: The name is just the first user. I want to have some interface that allows me to do other things: enable CMMA, reset the CMMA memory usage state on reset, zap the page tables on clear reset, set the cpu facilities (some parts need to be in kernel so that we can block specific operations), enable s390 specific settings, whatever. The usual approach was create new KVM ioctls, each for one feature + capability. This sounded like overkill. So please dont focus on stsi, I need some interface that I can use for other pending patches. And if that interface is generic enough, we might also use that for name (or not depending on the stsi discussion). I am not married to the device idea, anything that works out fine is ok with me. >>>>> I think VM configuration is common enough to just make this a separate interface. >>>> So you propose to define a new base ioctl (e.g. VM_REG) on the vm fd, instead? >>>> Seems like an easy enough change. Would you reuse the kvm_attr structure for that? >>> >>> Yeah, reuse whatever we can. Basically just remove the device boilerplate - I don't think it's impressively useful for a non-device. >> >> See above, name is just a simple first user. >> The thing is, that we have to have the ioctl either define a proper namespace (unique groups attrs) or to make it s390 specific. The device approach does help us here. > > If you like the device approach, make sure to create it on VM creation and only implement a specific ioctl to fetch its fd. We don't create the configuration information pseudo device after VM creation - it's always there :). > >> I personally dont mind which way to go, as long as Paolo is fine with the approach, and nobody complains about the functions being non-QOM. > > I think the most obvious and straight forward way would be to deal with all of STSI in user space. Make it a separate exit type similar to hypercalls and don't worry about QOM'ification of anything. This thing is on the same level as CPUID really - just VM wide :). For 3_2_2 this might be possible solution, but not for the other codes. But as I said, the name is not my main problem here.
diff --git a/Documentation/virtual/kvm/devices/s390_config.txt b/Documentation/virtual/kvm/devices/s390_config.txt new file mode 100644 index 0000000..f9bc251 --- /dev/null +++ b/Documentation/virtual/kvm/devices/s390_config.txt @@ -0,0 +1,13 @@ +S390 Config Device +================== + +The s390 config device is used for storage and retrieval of various kinds +of configuration related information which should be shared between kvm +and userspace. + +Groups: +KVM_DEV_CONFIG_GROUP + +Attributes for KVM_DEV_CONFIG_GROUP: +KVM_DEV_CONFIG_NAME - The name for this vm instance. A string of at + most 128 characters. diff --git a/arch/s390/include/asm/kvm_host.h b/arch/s390/include/asm/kvm_host.h index 154b600..da93b6e 100644 --- a/arch/s390/include/asm/kvm_host.h +++ b/arch/s390/include/asm/kvm_host.h @@ -277,6 +277,11 @@ struct s390_io_adapter { #define MAX_S390_IO_ADAPTERS ((MAX_ISC + 1) * 8) #define MAX_S390_ADAPTER_MAPS 256 +struct kvm_s390_config { + struct mutex lock; + struct kvm_s390_attr_name name; +}; + struct kvm_arch{ struct sca_block *sca; debug_info_t *dbf; @@ -286,6 +291,7 @@ struct kvm_arch{ int css_support; int use_irqchip; struct s390_io_adapter *adapters[MAX_S390_IO_ADAPTERS]; + struct kvm_s390_config *cfg; }; #define KVM_HVA_ERR_BAD (-1UL) diff --git a/arch/s390/include/uapi/asm/kvm.h b/arch/s390/include/uapi/asm/kvm.h index c003c6a..d53dd45 100644 --- a/arch/s390/include/uapi/asm/kvm.h +++ b/arch/s390/include/uapi/asm/kvm.h @@ -79,6 +79,17 @@ struct kvm_debug_exit_arch { struct kvm_guest_debug_arch { }; + + +/* config device specific GROUPS */ + +#define KVM_DEV_CONFIG_GROUP 0 +#define KVM_DEV_CONFIG_NAME 0 + +struct kvm_s390_attr_name { + char name[128]; +}; + #define KVM_SYNC_PREFIX (1UL << 0) #define KVM_SYNC_GPRS (1UL << 1) #define KVM_SYNC_ACRS (1UL << 2) diff --git a/arch/s390/kvm/Makefile b/arch/s390/kvm/Makefile index d3adb37..79f130b 100644 --- a/arch/s390/kvm/Makefile +++ b/arch/s390/kvm/Makefile @@ -11,5 +11,5 @@ common-objs = $(KVM)/kvm_main.o $(KVM)/eventfd.o $(KVM)/async_pf.o $(KVM)/irqch ccflags-y := -Ivirt/kvm -Iarch/s390/kvm -kvm-objs := $(common-objs) kvm-s390.o intercept.o interrupt.o priv.o sigp.o diag.o +kvm-objs := $(common-objs) kvm-s390.o intercept.o interrupt.o priv.o sigp.o diag.o config.o obj-$(CONFIG_KVM) += kvm.o diff --git a/arch/s390/kvm/config.c b/arch/s390/kvm/config.c new file mode 100644 index 0000000..f887116 --- /dev/null +++ b/arch/s390/kvm/config.c @@ -0,0 +1,133 @@ +/* + * handling CONFIG kvm device + * + * Copyright IBM Corp. 2014 + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License (version 2 only) + * as published by the Free Software Foundation. + * + * Author(s): Ekaterina Tumanova <tumanova@linux.vnet.ibm.com> + * Christian Borntraeger <borntraeger@de.ibm.com> + */ +#include <linux/kvm.h> +#include <linux/kvm_host.h> +#include <asm/uaccess.h> +#include "kvm-s390.h" + +static const struct kvm_s390_config config_defaults = { + .name = { "KVMguest" }, +}; + +/* + * This is called from architecture code, since we access config even if + * userspace does not create a config device. + */ +struct kvm_s390_config *kvm_s390_config_init(void) +{ + struct kvm_s390_config *config; + + config = kmalloc(sizeof(struct kvm_s390_config), GFP_KERNEL); + if (config) { + memcpy(config, &config_defaults, sizeof(*config)); + mutex_init(&config->lock); + } + + return config; +} + +void kvm_s390_config_free(struct kvm_s390_config *config) +{ + kfree(config); +} + +/* + * kvm accesses the config datastructure even if userspace did not create a + * config kvm device. So we only do kvm device related cleanups in the + * create and destroy callbacks. + */ +static int config_create(struct kvm_device *dev, u32 attr) +{ + return 0; +} + +static void config_destroy(struct kvm_device *dev) +{ + kfree(dev); +} + +static int config_set(struct kvm_device *dev, struct kvm_device_attr *attr) +{ + struct kvm_s390_config *config = dev->kvm->arch.cfg; + int ret; + + switch (attr->attr) { + case KVM_DEV_CONFIG_NAME: + mutex_lock(&config->lock); + ret = copy_from_user(&config->name, (void __user *) attr->addr, + sizeof(config->name)); + mutex_unlock(&config->lock); + return ret; + + default: + return -EINVAL; + } +} + +static int config_get(struct kvm_device *dev, struct kvm_device_attr *attr) +{ + struct kvm_s390_config *config = dev->kvm->arch.cfg; + int ret; + + switch (attr->attr) { + case KVM_DEV_CONFIG_NAME: + mutex_lock(&config->lock); + ret = copy_to_user((void __user *) attr->addr, &config->name, + sizeof(config->name)); + mutex_unlock(&config->lock); + return ret; + default: + return -EINVAL; + } +} + +static int config_set_attr(struct kvm_device *dev, struct kvm_device_attr *attr) +{ + switch (attr->group) { + case KVM_DEV_CONFIG_GROUP: + return config_set(dev, attr); + default: + return -EINVAL; + } +} + +static int config_get_attr(struct kvm_device *dev, struct kvm_device_attr *attr) +{ + switch (attr->group) { + case KVM_DEV_CONFIG_GROUP: + return config_get(dev, attr); + default: + return -EINVAL; + } +} + +static int config_has_attr(struct kvm_device *dev, struct kvm_device_attr *attr) +{ + switch (attr->group) { + case KVM_DEV_CONFIG_GROUP: + switch (attr->attr) { + case KVM_DEV_CONFIG_NAME: + return 0; + } + } + return -EINVAL; +} + +struct kvm_device_ops kvm_s390_config_ops = { + .name = "kvm_s390_config", + .create = config_create, + .destroy = config_destroy, + .get_attr = config_get_attr, + .set_attr = config_set_attr, + .has_attr = config_has_attr, +}; diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c index b3ecb8f..4504015 100644 --- a/arch/s390/kvm/kvm-s390.c +++ b/arch/s390/kvm/kvm-s390.c @@ -307,8 +307,14 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type) kvm->arch.css_support = 0; kvm->arch.use_irqchip = 0; + kvm->arch.cfg = kvm_s390_config_init(); + if (!kvm->arch.cfg) + goto out_gmap; return 0; +out_gmap: + if (!kvm_is_ucontrol(kvm)) + gmap_free(kvm->arch.gmap); out_nogmap: debug_unregister(kvm->arch.dbf); out_nodbf: @@ -371,6 +377,7 @@ void kvm_arch_destroy_vm(struct kvm *kvm) if (!kvm_is_ucontrol(kvm)) gmap_free(kvm->arch.gmap); kvm_s390_destroy_adapters(kvm); + kvm_s390_config_free(kvm->arch.cfg); } /* Section: vcpu related */ diff --git a/arch/s390/kvm/kvm-s390.h b/arch/s390/kvm/kvm-s390.h index 3c1e227..50185a3 100644 --- a/arch/s390/kvm/kvm-s390.h +++ b/arch/s390/kvm/kvm-s390.h @@ -168,4 +168,8 @@ int kvm_cpu_has_interrupt(struct kvm_vcpu *vcpu); int psw_extint_disabled(struct kvm_vcpu *vcpu); void kvm_s390_destroy_adapters(struct kvm *kvm); +/* implemented in config.c */ +struct kvm_s390_config *kvm_s390_config_init(void); +void kvm_s390_config_free(struct kvm_s390_config *config); + #endif diff --git a/arch/s390/kvm/priv.c b/arch/s390/kvm/priv.c index 476e9e2..4e5fba5 100644 --- a/arch/s390/kvm/priv.c +++ b/arch/s390/kvm/priv.c @@ -12,6 +12,7 @@ */ #include <linux/kvm.h> +#include <linux/kvm_host.h> #include <linux/gfp.h> #include <linux/errno.h> #include <linux/compat.h> @@ -414,7 +415,10 @@ static void handle_stsi_3_2_2(struct kvm_vcpu *vcpu, struct sysinfo_3_2_2 *mem) mem->vm[0].cpus_standby = 0; mem->vm[0].cpus_reserved = 0; mem->vm[0].caf = 1000; - memcpy(mem->vm[0].name, "KVMguest", 8); + + mutex_lock(&vcpu->kvm->arch.cfg->lock); + memcpy(mem->vm[0].name, &vcpu->kvm->arch.cfg->name, 8); + mutex_unlock(&vcpu->kvm->arch.cfg->lock); ASCEBC(mem->vm[0].name, 8); memcpy(mem->vm[0].cpi, "KVM/Linux ", 16); ASCEBC(mem->vm[0].cpi, 16); diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h index 7d21cf9..5c5c39c 100644 --- a/include/linux/kvm_host.h +++ b/include/linux/kvm_host.h @@ -1080,6 +1080,7 @@ extern struct kvm_device_ops kvm_xics_ops; extern struct kvm_device_ops kvm_vfio_ops; extern struct kvm_device_ops kvm_arm_vgic_v2_ops; extern struct kvm_device_ops kvm_flic_ops; +extern struct kvm_device_ops kvm_s390_config_ops; #ifdef CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h index a8f4ee5..d0e738f 100644 --- a/include/uapi/linux/kvm.h +++ b/include/uapi/linux/kvm.h @@ -934,6 +934,7 @@ struct kvm_device_attr { #define KVM_DEV_VFIO_GROUP_DEL 2 #define KVM_DEV_TYPE_ARM_VGIC_V2 5 #define KVM_DEV_TYPE_FLIC 6 +#define KVM_DEV_TYPE_S390_CONFIG 7 /* * ioctls for VM fds diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index 5fd4cf8..a9f909a 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -2285,6 +2285,9 @@ static int kvm_ioctl_create_device(struct kvm *kvm, case KVM_DEV_TYPE_FLIC: ops = &kvm_flic_ops; break; + case KVM_DEV_TYPE_S390_CONFIG: + ops = &kvm_s390_config_ops; + break; #endif default: return -ENODEV;