| Message ID | 20200207113958.7320-10-borntraeger@de.ibm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | KVM: s390: Add support for protected VMs | expand |
On 07/02/2020 12.39, Christian Borntraeger wrote: > From: Janosch Frank <frankja@linux.ibm.com> > > 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@linux.ibm.com> > [borntraeger@de.ibm.com: patch merging, splitting, fixing] > Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> > --- > 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? > +}; > + > +cmd values: > +KVM_PV_VM_CREATE > +Allocate memory and register the VM with the Ultravisor, thereby > +donating memory to the Ultravisor making it inaccessible to KVM. > + > +KVM_PV_VM_DESTROY > +Deregisters the VM from the Ultravisor and frees memory that was > +donated, so the kernel can use it again. All registered VCPUs have to > +be unregistered beforehand and all memory has to be exported or > +shared. > + > +KVM_PV_VM_SET_SEC_PARMS > +Pass the image header from VM memory to the Ultravisor in preparation > +of image unpacking and verification. > + > +KVM_PV_VM_UNPACK > +Unpack (protect and decrypt) a page of the encrypted boot image. > + > +KVM_PV_VM_VERIFY > +Verify the integrity of the unpacked image. Only if this succeeds, KVM > +is allowed to start protected VCPUs. You also don't mention rc and rrc here ... yet another indication that it is unused? Thomas
On 08.02.20 15:57, Thomas Huth wrote: > On 07/02/2020 12.39, Christian Borntraeger wrote: >> From: Janosch Frank <frankja@linux.ibm.com> >> >> 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@linux.ibm.com> >> [borntraeger@de.ibm.com: patch merging, splitting, fixing] >> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> >> --- >> 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]; };
On Mon, 10 Feb 2020 13:26:35 +0100 Christian Borntraeger <borntraeger@de.ibm.com> wrote: > On 08.02.20 15:57, Thomas Huth wrote: > > On 07/02/2020 12.39, Christian Borntraeger wrote: > >> From: Janosch Frank <frankja@linux.ibm.com> > >> > >> 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@linux.ibm.com> > >> [borntraeger@de.ibm.com: patch merging, splitting, fixing] > >> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> > >> --- > >> 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?)
On 10.02.20 13:57, Cornelia Huck wrote: > On Mon, 10 Feb 2020 13:26:35 +0100 > Christian Borntraeger <borntraeger@de.ibm.com> wrote: > >> On 08.02.20 15:57, Thomas Huth wrote: >>> On 07/02/2020 12.39, Christian Borntraeger wrote: >>>> From: Janosch Frank <frankja@linux.ibm.com> >>>> >>>> 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@linux.ibm.com> >>>> [borntraeger@de.ibm.com: patch merging, splitting, fixing] >>>> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> >>>> --- >>>> 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? I will change the IOWR to make sure that we can have both directions. > > 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?) When you look at all the other examples we define those as reserved bytes The idea is to have no semantics at all. Whenever we add a new flag we will replace the reserved bytes with a new meaning. e.g. see struct kvm_s390_skeys { __u64 start_gfn; __u64 count; __u64 skeydata_addr; __u32 flags; __u32 reserved[9]; }; or /* for KVM_S390_MEM_OP and KVM_S390_SIDA_OP */ struct kvm_s390_mem_op { /* in */ __u64 gaddr; /* the guest address */ __u64 flags; /* flags */ __u32 size; /* amount of bytes */ __u32 op; /* type of operation */ __u64 buf; /* buffer in userspace */ __u8 ar; /* the access register number */ __u8 reserved21[3]; /* should be set to 0 */ __u32 offset; /* offset into the sida */ __u8 reserved28[24]; /* should be set to 0 */ };
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 */ +}; + +cmd values: +KVM_PV_VM_CREATE +Allocate memory and register the VM with the Ultravisor, thereby +donating memory to the Ultravisor making it inaccessible to KVM. + +KVM_PV_VM_DESTROY +Deregisters the VM from the Ultravisor and frees memory that was +donated, so the kernel can use it again. All registered VCPUs have to +be unregistered beforehand and all memory has to be exported or +shared. + +KVM_PV_VM_SET_SEC_PARMS +Pass the image header from VM memory to the Ultravisor in preparation +of image unpacking and verification. + +KVM_PV_VM_UNPACK +Unpack (protect and decrypt) a page of the encrypted boot image. + +KVM_PV_VM_VERIFY +Verify the integrity of the unpacked image. Only if this succeeds, KVM +is allowed to start protected VCPUs. + +4.126 KVM_S390_PV_COMMAND_VCPU + +Capability: KVM_CAP_S390_PROTECTED +Architectures: s390 +Type: vcpu ioctl +Parameters: struct kvm_pv_cmd +Returns: 0 on success, < 0 on error + +cmd values: +KVM_PV_VCPU_CREATE +Allocate memory and register a VCPU with the Ultravisor, thereby +donating memory to the Ultravisor making it inaccessible to KVM. + +KVM_PV_VCPU_DESTROY +Unregisters the VCPU from the Ultravisor and frees memory that was +donated, so the kernel can use it again. + 5. The kvm_run structure ------------------------ @@ -5439,3 +5493,10 @@ Architectures: s390 This capability indicates that the KVM_S390_NORMAL_RESET and KVM_S390_CLEAR_RESET ioctls are available. + +8.23 KVM_CAP_S390_PROTECTED + +Architecture: s390 + +This capability indicates that KVM can start protected VMs and the +Ultravisor has therefore been initialized.