We want to configure several things in KVM that go beyond what ENABLE_CAP (we need payload) or ONE_REG (we need it for the VM and we need to do more complex actions) can provide. Instead of adding several s390 specific ioctls, lets provide a configuration and control device that encapsulates different commands into groups of the same area (MEMORY, CPU, ..) We also provide an initial nameless base group, with a simple first user to set the guest name. We need that name in the kernel for the emulation of STSI (which provides the guest name to the guest) but we need to implement the emulation in supervisor mode, as it also provides the underlying levels of hipervisors. Currently we have the following GROUPS and ATTRs pending, which configure some memory management related function or allow to set the guest facilities, cpuids etc: #define KVM_DEV_CONFIG_GROUP 0 #define KVM_DEV_CONFIG_NAME 0 #define KVM_DEV_CONFIG_GROUP_MEM 1 #define KVM_DEV_CONFIG_MEM_ENABLE_CMMA 0 #define KVM_DEV_CONFIG_MEM_CLR_CMMA 1 #define KVM_DEV_CONFIG_MEM_CLR_PAGES 2 #define KVM_DEV_CONFIG_GROUP_CPU 2 #define KVM_DEV_CONFIG_CPU_TYPE 0 #define KVM_DEV_CONFIG_CPU_FAC 1 #define KVM_DEV_CONFIG_CPU_FAC_MASK 2 #define KVM_DEV_CONFIG_CPU_IBC 3 #define KVM_DEV_CONFIG_CPU_IBC_RANGE 4 In addition other groups like #define KVM_DEV_CONFIG_GROUP_CRYPTO are under consideration to configure crypto acceleration. Unless there is a major concern, I will add this to the next s390 PULL requests for KVM. Christian -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
