On Wed, 6 Nov 2019 22:02:41 +0100 Janosch Frank <frankja@xxxxxxxxxxxxx> wrote: > On 11/6/19 6:37 PM, Cornelia Huck wrote: > > On Wed, 6 Nov 2019 18:05:22 +0100 > > Janosch Frank <frankja@xxxxxxxxxxxxx> wrote: > > > >> On 11/6/19 5:48 PM, Cornelia Huck wrote: > >>> On Thu, 24 Oct 2019 07:40:52 -0400 > >>> Janosch Frank <frankja@xxxxxxxxxxxxx> wrote: > >>> > >>>> Description of changes that are necessary to move a KVM VM into > >>>> Protected Virtualization mode. > >>>> > >>>> Signed-off-by: Janosch Frank <frankja@xxxxxxxxxxxxx> > >>>> --- > >>>> Documentation/virtual/kvm/s390-pv-boot.txt | 62 ++++++++++++++++++++++ > >>>> 1 file changed, 62 insertions(+) > >>>> create mode 100644 Documentation/virtual/kvm/s390-pv-boot.txt > > > >>> So... what do we IPL from? Is there still a need for the bios? > >>> > >>> (Sorry, I'm a bit confused here.) > >>> > >> > >> We load a blob via the bios (all methods are supported) and that blob > >> moves itself into protected mode. I.e. it has a small unprotected stub, > >> the rest is an encrypted kernel. > >> > > > > Ok. The magic is in the loaded kernel, and we don't need modifications > > to the bios? > > > > Yes. > > The order is: > * We load a blob via the bios or direct kernel boot. > * That blob consists of a small stub, a header and an encrypted blob > glued together > * The small stub does the diag 308 subcode 8 and 10. > * Subcode 8 basically passes the header that describes the encrypted > blob to the Ultravisor (well rather registers it with qemu to pass on later) > * Subcode 10 tells QEMU to move the VM into protected mode > * A lot of APIs in KVM and the Ultravisor are called > * The protected VM starts > * A memory mover copies the now unencrypted, but protected kernel to its > intended place and jumps into the entry function > * Linux boots and detects, that it is protected and needs to use bounce > buffers > Thanks, this explanation makes things much clearer.
Attachment:
pgpC4nKQ9NRVW.pgp
Description: OpenPGP digital signature
