On 01/04/14 16:47, Christian Borntraeger wrote:
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
@Alex,
regarding STSI, what about the following:
The kernel will fill in every part of STSI as of now, but we will provide a CAP
that qemu can enable which then tells the kernel to pass control to QEMU after
it has filled in the data. QEMU can then do nothing (e.g. for stsi 111) or
change
the information (e.g. for 322) and return to kernel. That would
a: cover the name aspect
b: will work with future enhancements for levels 1 and 2 since the kernel will
still pass that through to the HW or LPAR
c: allows QEMU to override everything if necessary
@Paolo, Alex,
I have several changes pending that will require new ioctls. I planned to use
the config device to avoid creating new ioctls. Some option:
a: define new ioctls for these things (might end up with ~10 new ioctls)
b: allow GET_ATTR/SET_ATTR on the vm fd. We would define those as architecture
specific attributes of the VM.
c: use a config device an anchor for GET_ATTR/SET_ATTR
d: any better idea
This question is really a bike shed color discussion (which interface for
specific thing between qemu/kvm is considered best), but it will be ABI. Paolo,
do you have any preference?
I dont care about which solution we choose, but I obviously need a decision to
rework pending patches.