Re: [PATCH v9 14/15] docs: Add protvirt docs

[Janosch Frank]

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 <address@hidden>
> 

Thanks!

signature.asc
Description: OpenPGP digital signature