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

[Michael S. Tsirkin]

On Tue, Jun 09, 2020 at 06:28:39PM +0200, Halil Pasic wrote:
> 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).

So if we want to keep it user friendly, there could be
protection property with values on/off/auto, and auto
would poke at host capability to figure out whether
it's supported.

Both virtio and CPU would inherit from that.

This will allow other useful features such as ability
to hide PV from guest, which could in turn be handy e.g.
to allow migration to hosts without PV support,
or if host wants to force ability to read guest memory
e.g. for security.


-- 
MST