On 5/18/20 5:15 AM, Christian Borntraeger wrote: > > > On 16.05.20 00:19, Collin Walling wrote: >> DIAGNOSE 0x318 (diag 318) sets information regarding the environment >> the VM is running in (Linux, z/VM, etc) and is observed via >> firmware/service events. >> >> This is a privileged s390x instruction that must be intercepted by >> SIE. Userspace handling is required, so let's introduce some functions >> to communicate between userspace and KVM via ioctls. These will be used >> to get/set the diag 318 related information. >> >> The Control Program Name Code (CPNC) is stored in the SIE block. The >> CPNC along with the Control Program Version Code (CPVC) are stored in >> the kvm_arch struct. >> >> Signed-off-by: Collin Walling <walling@xxxxxxxxxxxxx> >> --- >> Documentation/virt/kvm/devices/vm.rst | 21 +++++++ >> arch/s390/include/asm/kvm_host.h | 5 +- >> arch/s390/include/uapi/asm/kvm.h | 4 ++ >> arch/s390/kvm/kvm-s390.c | 82 +++++++++++++++++++++++++++ >> arch/s390/kvm/vsie.c | 2 + >> 5 files changed, 113 insertions(+), 1 deletion(-) >> >> diff --git a/Documentation/virt/kvm/devices/vm.rst b/Documentation/virt/kvm/devices/vm.rst >> index 0aa5b1cfd700..52cc906dd7bd 100644 >> --- a/Documentation/virt/kvm/devices/vm.rst >> +++ b/Documentation/virt/kvm/devices/vm.rst >> @@ -314,3 +314,24 @@ Allows userspace to query the status of migration mode. >> if it is enabled >> :Returns: -EFAULT if the given address is not accessible from kernel space; >> 0 in case of success. >> + >> +6. GROUP: KVM_S390_VM_MISC >> +========================== >> + >> +:Architectures: s390 >> + >> +6.1. KVM_S390_VM_MISC_DIAG_318 (r/w) >> +----------------------------------- >> + >> +Allows userspace to retrieve and set the DIAGNOSE 0x318 information, >> +which consists of a 1-byte "Control Program Name Code" and a 7-byte >> +"Control Program Version Code" (a 64 bit value all in all). This >> +information is set by the guest (usually during IPL). This interface is >> +intended to allow retrieving and setting it during migration; while no >> +real harm is done if the information is changed outside of migration, >> +it is strongly discouraged. >> + >> +:Parameters: address of a buffer in user space (u64), where the >> + information is read from or stored into >> +:Returns: -EFAULT if the given address is not accessible from kernel space; >> + 0 in case of success > > > An alternative would be a new sync_reg value + KVM capability. > > I did some investigation into this (new grounds for me) sync_reg would handle the migration part, and then we'd just need the ioctl so the diag instruction handler can set the data. Does that sound right? -- Regards, Collin Stay safe and stay healthy
