On 11/7/19 9:53 AM, Cornelia Huck wrote: > 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. NP We seem to assume that all of this is easily understandable, but we are obviously biased :-) I'll try to improve Documentation by adding Pierre to the discussion, as he wasn't involved in the project yet.
Attachment:
signature.asc
Description: OpenPGP digital signature
