| Message ID | 20200311132151.172389-15-frankja@linux.ibm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | s390x: Protected Virtualization support | expand |
I don't have to warn you that I am not a native speaker ;) > +Prerequisites > +------------- > + > +To run PVMs a machine with the Protected Virtualization feature PVMs, a > +which is indicated by the Ultravisor Call facility (stfle bit , which ..., is required > +158) is required. The Ultravisor needs to be initialized at boot by > +setting `prot_virt=1` on the kernel command line. > + > +If those requirements are met, the capability `KVM_CAP_S390_PROTECTED` > +will indicate that KVM can support PVMs on that LPAR. > + > + > +QEMU Settings > +------------- > + > +To indicate to the VM that it can transition into protected mode, the > +`Unpack facility` (stfle bit 161 represented by the feature > +`S390_FEAT_UNPACK`) needs to be part of the cpu model of the VM. maybe mention the feature name instead of S390_FEAT_UNPACK ? "unpack" > + > +All I/O devices need to use the IOMMU. need to/have to ? > +Passthrough (vfio) devices are currently not supported. Does that have to be fenced or will they simply not be detected/not work? > + > +Host huge page backings are not supported. However guests can use huge > +pages as indicated by its facilities. Maybe mention what will happen if huge pages are used. > + > + > +Boot Process > +------------ > + > +A secure guest image can either be loaded from disk or supplied on the > +QEMU command line. Booting from disk is done by the unmodified > +s390-ccw BIOS. I.e., the bootmap is interpreted, multiple components > +are read into memory and control is transferred to one of the > +components (zipl stage3). Stag3 does some fixups and then transfers > +control to some program residing in guest memory, which is normally > +the OS kernel. The secure image has another component prepended > +(stage3a) that uses the new diag308 subcodes 8 and 10 to trigger the > +transition into secure mode. > + > +Booting from the image supplied via the QEMU command line requires via/on as above? > +that the file passed via -kernel has the same memory layout as would > +result from the disk boot. This memory layout includes the encrypted > +components (kernel, initrd, cmdline), the stage3a loader and > +metadata. In case this boot method is used, the command line > +options -initrd and -cmdline are ineffective. The preparation of a PVM Is there way we could warn if these would be set? > +image is done by genprotimg of the s390-tools package. > Acked-by: David Hildenbrand <david@redhat.com>
On 3/11/20 5:16 PM, David Hildenbrand wrote: > > I don't have to warn you that I am not a native speaker ;) > >> +Prerequisites >> +------------- >> + >> +To run PVMs a machine with the Protected Virtualization feature > > PVMs, a > >> +which is indicated by the Ultravisor Call facility (stfle bit > > , which ..., is required > >> +158) is required. The Ultravisor needs to be initialized at boot by >> +setting `prot_virt=1` on the kernel command line. >> + >> +If those requirements are met, the capability `KVM_CAP_S390_PROTECTED` >> +will indicate that KVM can support PVMs on that LPAR. >> + >> + >> +QEMU Settings >> +------------- >> + >> +To indicate to the VM that it can transition into protected mode, the >> +`Unpack facility` (stfle bit 161 represented by the feature >> +`S390_FEAT_UNPACK`) needs to be part of the cpu model of the VM. > > maybe mention the feature name instead of S390_FEAT_UNPACK ? "unpack" > >> + >> +All I/O devices need to use the IOMMU. > > need to/have to ? > >> +Passthrough (vfio) devices are currently not supported. > > Does that have to be fenced or will they simply not be detected/not work? I guess they will lead to the VM being killed by the kernel, since it can't access protected memory. I need to check that with Halil to confirm though. > >> + >> +Host huge page backings are not supported. However guests can use huge >> +pages as indicated by its facilities. > > Maybe mention what will happen if huge pages are used. Currently we would fail the unpack process, which I dislike because it would only log a cryptic error code. I will have a look if I can instead print an error when the subcode 10 is issued and return an error. > >> + >> + >> +Boot Process >> +------------ >> + >> +A secure guest image can either be loaded from disk or supplied on the >> +QEMU command line. Booting from disk is done by the unmodified >> +s390-ccw BIOS. I.e., the bootmap is interpreted, multiple components >> +are read into memory and control is transferred to one of the >> +components (zipl stage3). Stag3 does some fixups and then transfers >> +control to some program residing in guest memory, which is normally >> +the OS kernel. The secure image has another component prepended >> +(stage3a) that uses the new diag308 subcodes 8 and 10 to trigger the >> +transition into secure mode. >> + >> +Booting from the image supplied via the QEMU command line requires > > via/on as above? Sure > >> +that the file passed via -kernel has the same memory layout as would >> +result from the disk boot. This memory layout includes the encrypted >> +components (kernel, initrd, cmdline), the stage3a loader and >> +metadata. In case this boot method is used, the command line >> +options -initrd and -cmdline are ineffective. The preparation of a PVM > > Is there way we could warn if these would be set? I'll have a look, but I'm unsure where I'll need to hook into to make such a check and it the effort is worth it. > >> +image is done by genprotimg of the s390-tools package. >> > > > Acked-by: David Hildenbrand <david@redhat.com> > Thanks!
On Wed, 11 Mar 2020 09:21:50 -0400 Janosch Frank <frankja@linux.ibm.com> wrote: > Lets add some documentation for the Protected VM functionality. > > Signed-off-by: Janosch Frank <frankja@linux.ibm.com> > --- > docs/system/index.rst | 1 + > docs/system/protvirt.rst | 56 > ++++++++++++++++++++++++++++++++++++++++ 2 files changed, 57 > insertions(+) create mode 100644 docs/system/protvirt.rst > > diff --git a/docs/system/index.rst b/docs/system/index.rst > index 6e5f20fa1333ce23..74afbd7cc3fc0296 100644 > --- a/docs/system/index.rst > +++ b/docs/system/index.rst > @@ -34,3 +34,4 @@ Contents: > deprecated > build-platforms > license > + protvirt > diff --git a/docs/system/protvirt.rst b/docs/system/protvirt.rst > new file mode 100644 > index 0000000000000000..6c8cf0f7910eae86 > --- /dev/null > +++ b/docs/system/protvirt.rst > @@ -0,0 +1,56 @@ > +Protected Virtualization on s390x > +================================= > + > +The memory and most of the registers of Protected Virtual Machines > +(PVMs) are encrypted or inaccessible to the hypervisor, effectively > +prohibiting VM introspection when the VM is running. At rest, PVMs > are +encrypted and can only be decrypted by the firmware, represented > by an +entity called Ultravisor, of specific IBM Z machines. > + > + > +Prerequisites > +------------- > + > +To run PVMs a machine with the Protected Virtualization feature > +which is indicated by the Ultravisor Call facility (stfle bit > +158) is required. The Ultravisor needs to be initialized at boot by > +setting `prot_virt=1` on the kernel command line. I'd add "of the host" just to make it extra clear > + > +If those requirements are met, the capability > `KVM_CAP_S390_PROTECTED` +will indicate that KVM can support PVMs on > that LPAR. + > + > +QEMU Settings > +------------- > + > +To indicate to the VM that it can transition into protected mode, the > +`Unpack facility` (stfle bit 161 represented by the feature > +`S390_FEAT_UNPACK`) needs to be part of the cpu model of the VM. > + > +All I/O devices need to use the IOMMU. > +Passthrough (vfio) devices are currently not supported. > + > +Host huge page backings are not supported. However guests can use > huge +pages as indicated by its facilities. > + > + > +Boot Process > +------------ > + > +A secure guest image can either be loaded from disk or supplied on > the +QEMU command line. Booting from disk is done by the unmodified > +s390-ccw BIOS. I.e., the bootmap is interpreted, multiple components > +are read into memory and control is transferred to one of the > +components (zipl stage3). Stag3 does some fixups and then transfers > +control to some program residing in guest memory, which is normally > +the OS kernel. The secure image has another component prepended > +(stage3a) that uses the new diag308 subcodes 8 and 10 to trigger the > +transition into secure mode. > + > +Booting from the image supplied via the QEMU command line requires > +that the file passed via -kernel has the same memory layout as would > +result from the disk boot. This memory layout includes the encrypted > +components (kernel, initrd, cmdline), the stage3a loader and > +metadata. In case this boot method is used, the command line > +options -initrd and -cmdline are ineffective. The preparation of a > PVM +image is done by genprotimg of the s390-tools package. Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
On 3/13/20 2:00 PM, Claudio Imbrenda wrote: > On Wed, 11 Mar 2020 09:21:50 -0400 > Janosch Frank <frankja@linux.ibm.com> wrote: > >> Lets add some documentation for the Protected VM functionality. >> >> Signed-off-by: Janosch Frank <frankja@linux.ibm.com> >> --- >> docs/system/index.rst | 1 + >> docs/system/protvirt.rst | 56 >> ++++++++++++++++++++++++++++++++++++++++ 2 files changed, 57 >> insertions(+) create mode 100644 docs/system/protvirt.rst >> >> diff --git a/docs/system/index.rst b/docs/system/index.rst >> index 6e5f20fa1333ce23..74afbd7cc3fc0296 100644 >> --- a/docs/system/index.rst >> +++ b/docs/system/index.rst >> @@ -34,3 +34,4 @@ Contents: >> deprecated >> build-platforms >> license >> + protvirt >> diff --git a/docs/system/protvirt.rst b/docs/system/protvirt.rst >> new file mode 100644 >> index 0000000000000000..6c8cf0f7910eae86 >> --- /dev/null >> +++ b/docs/system/protvirt.rst >> @@ -0,0 +1,56 @@ >> +Protected Virtualization on s390x >> +================================= >> + >> +The memory and most of the registers of Protected Virtual Machines >> +(PVMs) are encrypted or inaccessible to the hypervisor, effectively >> +prohibiting VM introspection when the VM is running. At rest, PVMs >> are +encrypted and can only be decrypted by the firmware, represented >> by an +entity called Ultravisor, of specific IBM Z machines. >> + >> + >> +Prerequisites >> +------------- >> + >> +To run PVMs a machine with the Protected Virtualization feature >> +which is indicated by the Ultravisor Call facility (stfle bit >> +158) is required. The Ultravisor needs to be initialized at boot by >> +setting `prot_virt=1` on the kernel command line. > > I'd add "of the host" just to make it extra clear How about: ...on the host kernel command line > >> + >> +If those requirements are met, the capability >> `KVM_CAP_S390_PROTECTED` +will indicate that KVM can support PVMs on >> that LPAR. + >> + >> +QEMU Settings >> +------------- >> + >> +To indicate to the VM that it can transition into protected mode, the >> +`Unpack facility` (stfle bit 161 represented by the feature >> +`S390_FEAT_UNPACK`) needs to be part of the cpu model of the VM. >> + >> +All I/O devices need to use the IOMMU. >> +Passthrough (vfio) devices are currently not supported. >> + >> +Host huge page backings are not supported. However guests can use >> huge +pages as indicated by its facilities. >> + >> + >> +Boot Process >> +------------ >> + >> +A secure guest image can either be loaded from disk or supplied on >> the +QEMU command line. Booting from disk is done by the unmodified >> +s390-ccw BIOS. I.e., the bootmap is interpreted, multiple components >> +are read into memory and control is transferred to one of the >> +components (zipl stage3). Stag3 does some fixups and then transfers >> +control to some program residing in guest memory, which is normally >> +the OS kernel. The secure image has another component prepended >> +(stage3a) that uses the new diag308 subcodes 8 and 10 to trigger the >> +transition into secure mode. >> + >> +Booting from the image supplied via the QEMU command line requires >> +that the file passed via -kernel has the same memory layout as would >> +result from the disk boot. This memory layout includes the encrypted >> +components (kernel, initrd, cmdline), the stage3a loader and >> +metadata. In case this boot method is used, the command line >> +options -initrd and -cmdline are ineffective. The preparation of a >> PVM +image is done by genprotimg of the s390-tools package. > > Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Thanks!
On Wed, 11 Mar 2020 at 13:31, Janosch Frank <frankja@linux.ibm.com> wrote: > > Lets add some documentation for the Protected VM functionality. > > Signed-off-by: Janosch Frank <frankja@linux.ibm.com> > --- > docs/system/index.rst | 1 + > docs/system/protvirt.rst | 56 ++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 57 insertions(+) > create mode 100644 docs/system/protvirt.rst > > diff --git a/docs/system/index.rst b/docs/system/index.rst > index 6e5f20fa1333ce23..74afbd7cc3fc0296 100644 > --- a/docs/system/index.rst > +++ b/docs/system/index.rst > @@ -34,3 +34,4 @@ Contents: > deprecated > build-platforms > license > + protvirt The order of this list in index.rst determines the order of the table of contents in the manual. Could you put your new document at a reasonable place in the manual, not just at the bottom of the list, please? For something that is s390 specific, the ideal would be to create a new docs/system/target-s390x.rst which is then the place where all s390 docs can hang off of. This is how we're handling various other guest architecture docs. It doesn't all have to go in a single page -- eg target-arm.rst is an example of putting some sub-documents into docs/system/arm/ and referring to them from target-arm.rst. thanks -- PMM
On Fri, 13 Mar 2020 13:28:56 +0000 Peter Maydell <peter.maydell@linaro.org> wrote: > On Wed, 11 Mar 2020 at 13:31, Janosch Frank <frankja@linux.ibm.com> wrote: > > > > Lets add some documentation for the Protected VM functionality. > > > > Signed-off-by: Janosch Frank <frankja@linux.ibm.com> > > --- > > docs/system/index.rst | 1 + > > docs/system/protvirt.rst | 56 ++++++++++++++++++++++++++++++++++++++++ > > 2 files changed, 57 insertions(+) > > create mode 100644 docs/system/protvirt.rst > > > > diff --git a/docs/system/index.rst b/docs/system/index.rst > > index 6e5f20fa1333ce23..74afbd7cc3fc0296 100644 > > --- a/docs/system/index.rst > > +++ b/docs/system/index.rst > > @@ -34,3 +34,4 @@ Contents: > > deprecated > > build-platforms > > license > > + protvirt > > The order of this list in index.rst determines the order > of the table of contents in the manual. Could you put > your new document at a reasonable place in the manual, > not just at the bottom of the list, please? > > For something that is s390 specific, the ideal would > be to create a new docs/system/target-s390x.rst > which is then the place where all s390 docs can > hang off of. This is how we're handling various > other guest architecture docs. It doesn't all > have to go in a single page -- eg target-arm.rst > is an example of putting some sub-documents into > docs/system/arm/ and referring to them from > target-arm.rst. That sounds like a good idea; let me see whether I can come up with something that Janosch can base his change on. (There's already the vfio-ap documentation that's s390x specific; I'll also move it.)
On 3/17/20 7:23 PM, Cornelia Huck wrote: > On Fri, 13 Mar 2020 13:28:56 +0000 > Peter Maydell <peter.maydell@linaro.org> wrote: > >> On Wed, 11 Mar 2020 at 13:31, Janosch Frank <frankja@linux.ibm.com> wrote: >>> >>> Lets add some documentation for the Protected VM functionality. >>> >>> Signed-off-by: Janosch Frank <frankja@linux.ibm.com> >>> --- >>> docs/system/index.rst | 1 + >>> docs/system/protvirt.rst | 56 ++++++++++++++++++++++++++++++++++++++++ >>> 2 files changed, 57 insertions(+) >>> create mode 100644 docs/system/protvirt.rst >>> >>> diff --git a/docs/system/index.rst b/docs/system/index.rst >>> index 6e5f20fa1333ce23..74afbd7cc3fc0296 100644 >>> --- a/docs/system/index.rst >>> +++ b/docs/system/index.rst >>> @@ -34,3 +34,4 @@ Contents: >>> deprecated >>> build-platforms >>> license >>> + protvirt >> >> The order of this list in index.rst determines the order >> of the table of contents in the manual. Could you put >> your new document at a reasonable place in the manual, >> not just at the bottom of the list, please? >> >> For something that is s390 specific, the ideal would >> be to create a new docs/system/target-s390x.rst >> which is then the place where all s390 docs can >> hang off of. This is how we're handling various >> other guest architecture docs. It doesn't all >> have to go in a single page -- eg target-arm.rst >> is an example of putting some sub-documents into >> docs/system/arm/ and referring to them from >> target-arm.rst. > > That sounds like a good idea; let me see whether I can come up with > something that Janosch can base his change on. > > (There's already the vfio-ap documentation that's s390x specific; I'll > also move it.) > Oh great, I already tried moving the ap documentation but if I can rebase onto something usable I would be even happier as we save some mail round trips!
On Wed, 11 Mar 2020 09:21:50 -0400 Janosch Frank <frankja@linux.ibm.com> wrote: > Lets add some documentation for the Protected VM functionality. s/Lets/Let's/ :) > > Signed-off-by: Janosch Frank <frankja@linux.ibm.com> > --- > docs/system/index.rst | 1 + > docs/system/protvirt.rst | 56 ++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 57 insertions(+) > create mode 100644 docs/system/protvirt.rst > (...) > diff --git a/docs/system/protvirt.rst b/docs/system/protvirt.rst > new file mode 100644 > index 0000000000000000..6c8cf0f7910eae86 > --- /dev/null > +++ b/docs/system/protvirt.rst > @@ -0,0 +1,56 @@ > +Protected Virtualization on s390x > +================================= > + > +The memory and most of the registers of Protected Virtual Machines > +(PVMs) are encrypted or inaccessible to the hypervisor, effectively > +prohibiting VM introspection when the VM is running. At rest, PVMs are > +encrypted and can only be decrypted by the firmware, represented by an > +entity called Ultravisor, of specific IBM Z machines. Is that specific _generations_ or specific _machines_ (i.e. those with an appropriate key)? If the latter, maybe add a note that a specific image is bound to (a) specific machine(s)? > + > + > +Prerequisites > +------------- Also, maybe add "Running PVMs requires using the KVM hypervisor." ? > + > +To run PVMs a machine with the Protected Virtualization feature > +which is indicated by the Ultravisor Call facility (stfle bit maybe s/which is/as/ ? > +158) is required. The Ultravisor needs to be initialized at boot by > +setting `prot_virt=1` on the kernel command line. > + > +If those requirements are met, the capability `KVM_CAP_S390_PROTECTED` > +will indicate that KVM can support PVMs on that LPAR. > + > + > +QEMU Settings > +------------- > + > +To indicate to the VM that it can transition into protected mode, the > +`Unpack facility` (stfle bit 161 represented by the feature > +`S390_FEAT_UNPACK`) needs to be part of the cpu model of the VM. > + > +All I/O devices need to use the IOMMU. > +Passthrough (vfio) devices are currently not supported. > + > +Host huge page backings are not supported. However guests can use huge > +pages as indicated by its facilities. > + > + > +Boot Process > +------------ > + > +A secure guest image can either be loaded from disk or supplied on the > +QEMU command line. Booting from disk is done by the unmodified > +s390-ccw BIOS. I.e., the bootmap is interpreted, multiple components > +are read into memory and control is transferred to one of the > +components (zipl stage3). Stag3 does some fixups and then transfers s/Stag3/Stage3/ > +control to some program residing in guest memory, which is normally > +the OS kernel. The secure image has another component prepended > +(stage3a) that uses the new diag308 subcodes 8 and 10 to trigger the > +transition into secure mode. > + > +Booting from the image supplied via the QEMU command line requires > +that the file passed via -kernel has the same memory layout as would > +result from the disk boot. This memory layout includes the encrypted > +components (kernel, initrd, cmdline), the stage3a loader and > +metadata. In case this boot method is used, the command line > +options -initrd and -cmdline are ineffective. The preparation of a PVM > +image is done by genprotimg of the s390-tools package. "is done via the `genprotimg` tool from the s390-tools collection" ?
On 3/18/20 12:25 PM, Cornelia Huck wrote: > On Wed, 11 Mar 2020 09:21:50 -0400 > Janosch Frank <frankja@linux.ibm.com> wrote: > >> Lets add some documentation for the Protected VM functionality. > > s/Lets/Let's/ :) > >> >> Signed-off-by: Janosch Frank <frankja@linux.ibm.com> >> --- >> docs/system/index.rst | 1 + >> docs/system/protvirt.rst | 56 ++++++++++++++++++++++++++++++++++++++++ >> 2 files changed, 57 insertions(+) >> create mode 100644 docs/system/protvirt.rst >> > (...) >> diff --git a/docs/system/protvirt.rst b/docs/system/protvirt.rst >> new file mode 100644 >> index 0000000000000000..6c8cf0f7910eae86 >> --- /dev/null >> +++ b/docs/system/protvirt.rst >> @@ -0,0 +1,56 @@ >> +Protected Virtualization on s390x >> +================================= >> + >> +The memory and most of the registers of Protected Virtual Machines >> +(PVMs) are encrypted or inaccessible to the hypervisor, effectively >> +prohibiting VM introspection when the VM is running. At rest, PVMs are >> +encrypted and can only be decrypted by the firmware, represented by an >> +entity called Ultravisor, of specific IBM Z machines. > > Is that specific _generations_ or specific _machines_ (i.e. those with > an appropriate key)? If the latter, maybe add a note that a specific > image is bound to (a) specific machine(s)? > > >> + >> + >> +Prerequisites >> +------------- > > Also, maybe add > > "Running PVMs requires using the KVM hypervisor." > > ? > >> + >> +To run PVMs a machine with the Protected Virtualization feature >> +which is indicated by the Ultravisor Call facility (stfle bit > > maybe s/which is/as/ ? > >> +158) is required. The Ultravisor needs to be initialized at boot by >> +setting `prot_virt=1` on the kernel command line. >> + >> +If those requirements are met, the capability `KVM_CAP_S390_PROTECTED` >> +will indicate that KVM can support PVMs on that LPAR. >> + >> + >> +QEMU Settings >> +------------- >> + >> +To indicate to the VM that it can transition into protected mode, the >> +`Unpack facility` (stfle bit 161 represented by the feature >> +`S390_FEAT_UNPACK`) needs to be part of the cpu model of the VM. >> + >> +All I/O devices need to use the IOMMU. >> +Passthrough (vfio) devices are currently not supported. >> + >> +Host huge page backings are not supported. However guests can use huge >> +pages as indicated by its facilities. >> + >> + >> +Boot Process >> +------------ >> + >> +A secure guest image can either be loaded from disk or supplied on the >> +QEMU command line. Booting from disk is done by the unmodified >> +s390-ccw BIOS. I.e., the bootmap is interpreted, multiple components >> +are read into memory and control is transferred to one of the >> +components (zipl stage3). Stag3 does some fixups and then transfers > > s/Stag3/Stage3/ > >> +control to some program residing in guest memory, which is normally >> +the OS kernel. The secure image has another component prepended >> +(stage3a) that uses the new diag308 subcodes 8 and 10 to trigger the >> +transition into secure mode. >> + >> +Booting from the image supplied via the QEMU command line requires >> +that the file passed via -kernel has the same memory layout as would >> +result from the disk boot. This memory layout includes the encrypted >> +components (kernel, initrd, cmdline), the stage3a loader and >> +metadata. In case this boot method is used, the command line >> +options -initrd and -cmdline are ineffective. The preparation of a PVM >> +image is done by genprotimg of the s390-tools package. > > "is done via the `genprotimg` tool from the s390-tools collection" > > ? Too many cooks :) Ack to all
diff --git a/docs/system/index.rst b/docs/system/index.rst index 6e5f20fa1333ce23..74afbd7cc3fc0296 100644 --- a/docs/system/index.rst +++ b/docs/system/index.rst @@ -34,3 +34,4 @@ Contents: deprecated build-platforms license + protvirt diff --git a/docs/system/protvirt.rst b/docs/system/protvirt.rst new file mode 100644 index 0000000000000000..6c8cf0f7910eae86 --- /dev/null +++ b/docs/system/protvirt.rst @@ -0,0 +1,56 @@ +Protected Virtualization on s390x +================================= + +The memory and most of the registers of Protected Virtual Machines +(PVMs) are encrypted or inaccessible to the hypervisor, effectively +prohibiting VM introspection when the VM is running. At rest, PVMs are +encrypted and can only be decrypted by the firmware, represented by an +entity called Ultravisor, of specific IBM Z machines. + + +Prerequisites +------------- + +To run PVMs a machine with the Protected Virtualization feature +which is indicated by the Ultravisor Call facility (stfle bit +158) is required. The Ultravisor needs to be initialized at boot by +setting `prot_virt=1` on the kernel command line. + +If those requirements are met, the capability `KVM_CAP_S390_PROTECTED` +will indicate that KVM can support PVMs on that LPAR. + + +QEMU Settings +------------- + +To indicate to the VM that it can transition into protected mode, the +`Unpack facility` (stfle bit 161 represented by the feature +`S390_FEAT_UNPACK`) needs to be part of the cpu model of the VM. + +All I/O devices need to use the IOMMU. +Passthrough (vfio) devices are currently not supported. + +Host huge page backings are not supported. However guests can use huge +pages as indicated by its facilities. + + +Boot Process +------------ + +A secure guest image can either be loaded from disk or supplied on the +QEMU command line. Booting from disk is done by the unmodified +s390-ccw BIOS. I.e., the bootmap is interpreted, multiple components +are read into memory and control is transferred to one of the +components (zipl stage3). Stag3 does some fixups and then transfers +control to some program residing in guest memory, which is normally +the OS kernel. The secure image has another component prepended +(stage3a) that uses the new diag308 subcodes 8 and 10 to trigger the +transition into secure mode. + +Booting from the image supplied via the QEMU command line requires +that the file passed via -kernel has the same memory layout as would +result from the disk boot. This memory layout includes the encrypted +components (kernel, initrd, cmdline), the stage3a loader and +metadata. In case this boot method is used, the command line +options -initrd and -cmdline are ineffective. The preparation of a PVM +image is done by genprotimg of the s390-tools package.
Lets add some documentation for the Protected VM functionality. Signed-off-by: Janosch Frank <frankja@linux.ibm.com> --- docs/system/index.rst | 1 + docs/system/protvirt.rst | 56 ++++++++++++++++++++++++++++++++++++++++ 2 files changed, 57 insertions(+) create mode 100644 docs/system/protvirt.rst