On 11/29/19 12:08 PM, Daniel P. Berrangé wrote:
> On Wed, Nov 20, 2019 at 06:43:19AM -0500, Janosch Frank wrote:
>> Most of the QEMU changes for PV are related to the new IPL type with
>> subcodes 8 - 10 and the execution of the necessary Ultravisor calls to
>> IPL secure guests. Note that we can only boot into secure mode from
>> normal mode, i.e. stfle 161 is not active in secure mode.
>>
>> The other changes related to data gathering for emulation and
>> disabling addressing checks in secure mode, as well as CPU resets.
>>
>> While working on this I sprinkled in some cleanups, as we sometimes
>> significantly increase line count of some functions and they got
>> unreadable.
> 
> Can you give some guidance on how management applications including
> libvirt & layers above (oVirt, OpenStack, etc) would/should use this
> feature ?  What new command line / monitor calls are needed, and
> what feature restrictions are there on its use ?
> 
> Regards,
> Daniel
> 

Hey Daniel,

management applications generally do not need to know about this
feature. Most of the magic is in the guest image, which boots up in a
certain way to become a protected machine.

The requirements for that to happen are:
* Machine/firmware support
* KVM & QEMU support
* IO only with iommu
* Guest needs to use IO bounce buffers
* A kernel image or a kernel on a disk that was prepared with special
tooling

Such VMs are started like any other VM and run a short "normal" stub
that will prepare some things and then requests to be protected.

Most of the restrictions are memory related and might be lifted in the
future:
* No paging
* No migration
* No huge page backings
* No collaborative memory management


There are no monitor changes or cmd additions currently.
We're trying to insert protected VMs into the normal VM flow as much as
possible. You can even do a memory dump without any segfault or
protection exception for QEMU, however the guest's memory content will
be unreadable because it's encrypted.