Re: [PATCH v7 3/3] s390/kvm: diagnose 0x318 get/set handling

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 21.05.20 08:15, Collin Walling wrote:
> 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?

We would not even need the ioctl. We could just export/import this all the
time. See the sync_regs and store_regs functions.



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Kernel Development]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Info]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Linux Media]     [Device Mapper]

  Powered by Linux