Re: [PATCH v2 1/1] virtio-ccw: auto-manage VIRTIO_F_IOMMU_PLATFORM if PV

[Halil Pasic <pasic@linux.ibm.com>]

[-- Attachment #1: Type: text/plain, Size: 3555 bytes --]

On Thu, 28 May 2020 16:42:49 +0200
Janosch Frank <frankja@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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]