On 08.02.20 15:57, Thomas Huth wrote:
> On 07/02/2020 12.39, Christian Borntraeger wrote:
>> From: Janosch Frank <frankja@xxxxxxxxxxxxx>
>>
>> Add documentation for KVM_CAP_S390_PROTECTED capability and the
>> KVM_S390_PV_COMMAND and KVM_S390_PV_COMMAND_VCPU ioctls.
>>
>> Signed-off-by: Janosch Frank <frankja@xxxxxxxxxxxxx>
>> [borntraeger@xxxxxxxxxx: patch merging, splitting, fixing]
>> Signed-off-by: Christian Borntraeger <borntraeger@xxxxxxxxxx>
>> ---
>> Documentation/virt/kvm/api.txt | 61 ++++++++++++++++++++++++++++++++++
>> 1 file changed, 61 insertions(+)
>>
>> diff --git a/Documentation/virt/kvm/api.txt b/Documentation/virt/kvm/api.txt
>> index 73448764f544..4874d42286ca 100644
>> --- a/Documentation/virt/kvm/api.txt
>> +++ b/Documentation/virt/kvm/api.txt
>> @@ -4204,6 +4204,60 @@ the clear cpu reset definition in the POP. However, the cpu is not put
>> into ESA mode. This reset is a superset of the initial reset.
>>
>>
>> +4.125 KVM_S390_PV_COMMAND
>> +
>> +Capability: KVM_CAP_S390_PROTECTED
>> +Architectures: s390
>> +Type: vm ioctl
>> +Parameters: struct kvm_pv_cmd
>> +Returns: 0 on success, < 0 on error
>> +
>> +struct kvm_pv_cmd {
>> + __u32 cmd; /* Command to be executed */
>> + __u16 rc; /* Ultravisor return code */
>> + __u16 rrc; /* Ultravisor return reason code */
>> + __u64 data; /* Data or address */
>
> That remindes me ... do we maybe want a "reserved" field in here for
> future extensions? Or is the "data" pointer enough?
This is now:
struct kvm_pv_cmd {
__u32 cmd; /* Command to be executed */
__u32 flags; /* flags for future extensions. Must be 0 for now */
__u64 data; /* Data or address */
__u64 reserved[2];
};
