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

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

On Tue, 9 Jun 2020 17:47:47 +0200
Claudio Imbrenda <imbrenda@linux.ibm.com> wrote:

> On Tue, 9 Jun 2020 11:41:30 +0200
> Halil Pasic <pasic@linux.ibm.com> wrote:
> 
> [...]
> 
> > I don't know. Janosch could answer that, but he is on vacation. Adding
> > Claudio maybe he can answer. My understanding is, that while it might
> > be possible, it is ugly at best. The ability to do a transition is
> > indicated by a CPU model feature. Indicating the feature to the guest
> > and then failing the transition sounds wrong to me.
> 
> I agree. If the feature is advertised, then it has to work. I don't
> think we even have an architected way to fail the transition for that
> reason.
> 
> What __could__ be done is to prevent qemu from even starting if an
> incompatible device is specified together with PV.

AFAIU, the "specified together with PV" is the problem here. Currently
we don't "specify PV" but PV is just a capability that is managed by the
CPU model (like so many other). I.e. the fact that the
visualization environment is capable providing PV (unpack facility
available), and the fact, that the end user didn't fence the unpack
facility, does not mean, the user is dead set to use PV.

My understanding is, that we want PV to just work, without having to
put together a peculiar VM definition that says: this is going to be
used as a PV VM.

> 
> Another option is to disable PV at the qemu level if an incompatible
> device is present. This will have the effect that trying to boot a
> secure guest will fail mysteriously, which is IMHO also not too great.
> 

This would contradict with if feature is advertised, then it has to work
or?

> do we really have that many incompatible devices?
>