Changes from v5 -> v6 Migration and DeviceObject Code: - load/save/needed functions now check if kvm_enabled before calling kvm_get/set and has_feat (respectively)
QEMU->KVM Code: - added kvm_s390_* stubs for get/set functions for TCG compilation VCPU Discussion: - calculate the maximum allowed cpu entries by taking the SCCB size, subtracting the offset where the CPU entries begin, then dividing by the size of a CPU Entry struct - if the number of CPU entries exceeds the maximum allowed entries, print a warning and break out of the loop - no longer imposing a reduced CPU max Last post: https://lists.gnu.org/archive/html/qemu-devel/2019-06/msg05535.html The data associated with DIAGNOSE 0x318 helps to identify the underlying hypervisor level (pre-determined by an internal set of codes), as well as the guest environment (such as Linux, z/VM, etc). These patches, in tandem with KVM, allow this instruction to be enabled at the guest level, and also to enable migration of this data. The DIAGNOSE 0x318 instruction is a privileged instruction that is executed by the Linux kernel once and only once during setup (IPL). This requires interception by KVM to handle the instruction call safely. The instruction sets an 8-byte value corresponding to the environment the control program (i.e. guest) is running with, as well as what hypervisor it is running on. An update to the analogous KVM patches associated with this patchset are forthcoming and I will provide a link to the post as a reply to this chain. Guest support for the diag 318 instruction is accomplished by implementing a device class, a cpu model feature, and adjusting the Read Info struct. The Read Info struct adjustment coincidentally reduces the maximum number of VCPUs we can have for a single guest by one. The instruction is determined by a Read Info byte 134 bit 0. This new byte expands into the space of the Read Info SCCB, which also contains CPU entries at the tail-end of this block of data. Due to this expansion, we lose space for one CPU entry. A guest can still run safely with the original 248 maximum CPUs, but will lose access to the 248th CPU entry, meaning that the hypervisor will be unable to retrieve any information regarding that CPU (weather this means the guest will actually run with 247 CPUs when 248 are specified is uncertain to me, but the guest operates just fine on my end). A device class is used for this instruction in order to streamline the migration and reset of the DIAG 318 related data. A CPU model feature is added for this instruction, appropriately named diag318, and is available starting with the zEC12 full model, though as long as KVM can support emulation of this instruction, we can theoretically enable it for _any_ CPU model. It is recommended to explicitly enable the feature via -cpu ...,diag318=on (or via libvirt feature XML). Collin L. Walling (2): s390/kvm: header sync for diag318 s390: diagnose 318 info reset and migration support hw/s390x/Makefile.objs | 1 + hw/s390x/diag318.c | 85 +++++++++++++++++++++++++++++++++++++ hw/s390x/diag318.h | 40 +++++++++++++++++ hw/s390x/s390-virtio-ccw.c | 17 ++++++++ hw/s390x/sclp.c | 13 ++++++ include/hw/s390x/sclp.h | 2 + linux-headers/asm-s390/kvm.h | 4 ++ target/s390x/cpu_features.h | 1 + target/s390x/cpu_features_def.inc.h | 3 ++ target/s390x/gen-features.c | 1 + target/s390x/kvm-stub.c | 10 +++++ target/s390x/kvm.c | 29 +++++++++++++ target/s390x/kvm_s390x.h | 2 + 13 files changed, 208 insertions(+) create mode 100644 hw/s390x/diag318.c create mode 100644 hw/s390x/diag318.h -- 2.7.4