On Thu, 28 May 2020 16:42:49 +0200 Janosch Frank <fran...@linux.ibm.com> wrote:
> On 5/28/20 1:21 PM, Cornelia Huck wrote: > >> I think we have "allow protected" already expressed via cpu models. I'm > >> also not sure how libvirt would react to the idea of a new machine > >> property for this. You did mean "allow protected" as machine property, > >> or? > > > > "Unpack facility in cpu model" means "guest may transition into pv > > mode", right? What does it look like when the guest actually has > > transitioned? > > Well, we don't sync the features that the protected guest has back into > QEMU. So basically the VM doesn't really change except for ms->pv now > being true. > The features as observed by the guest do change, some quite drastically, it is just that the CPU model maintained by QEMU does not change. That is the changes can not be inspected. Unfortunately I'm not very familiar with the details, but my guess is that a) the ultravisor does what needs to be done with regards to features that are obligatory or not prohibited in PV mode. b) either the initial CPU model determines the CPU model after the conversion fully, or we will need to express something more via the QEMU cpu model. But we will have to do a fair amount of work before we get migration, and I would hate to wait with this until then. Important for me is the following. 1) The user asks for a VM with certain characteristics including cpu features. E.g. AP and unpack facilities. 2) The specified VM is sane, and gets started. 3) The OS decides to go secure. 4) Certain characteristics of the VM get changed as observed by the OS (e.g. gains the ability to do uv calls, but also loses stuff). 5) The changes are not reflected via QEMU interfaces. Compared to this my patch introduces a very similar behavior, in a sense that the characteristics as observed by the guest change during the transition, and that in a sense, after the transition the user gets something different than she has asked for. The differences are that this change ain't enforced by the ultravisor, and can be inspected through the QEMU property 'iommu_platform'. We can IMHO clam that the user opted in for this weird override of featues with 'unpack' and with DIAG 308 subcode 10. That is what I mean by 'already expressed': the machine property would be redundant and add extra complexity. Conny do you agree? > > > > > >> > >> AFAIU "allow protected" would be required for the !PV to PV switch, and > >> we would have to reject paravirtualized devices with iommu_platform='off' > >> on VM construction or hotplug (iommu_platform='auto/on' would be fine). > >> > >> Could you please confirm that I understood this correctly? > >> > >> > >>> This will come handy for other things like migrating to hosts without > >>> protected memory support. > >>> > >> > >> This is already covered by cpu model AFAIK. > > > > I don't think we'd want to migrate between pv and non-pv anyway? > > What exactly do you mean by that? > I'd expect that the VM can either be migrated in PV or non-PV mode and > not in a transition phase. > I agree. I don't think migrating an in transition VM is practicable. Currently migration is inhibited. We would probably need to inhibit migration during transition, and make ms->pv conceptually a part of the migration state. Both the source and the target would need to do some things differently if the migration is requested while in PV mode. Regards, Halil
pgp6LjtPHaMr0.pgp
Description: OpenPGP digital signature