On Mon, 10 Feb 2020 13:26:35 +0100
Christian Borntraeger <borntraeger@xxxxxxxxxx> wrote:
> 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(+)
> >> +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];
> };
Ok, that is where you add this... but still, the question: are those
fields only ever set by userspace, or could the kernel return things in
the reserved fields in the future?
Also, two 64 bit values seem a bit arbitrary... what about a data
address + length construct instead? (Length might be a fixed value per
flag?)
