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 <da...@redhat.com> > Thanks!
signature.asc
Description: OpenPGP digital signature
