qemu-s390x
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Cornelia Huck
Subject: Re: [PATCH v2 1/1] virtio-ccw: auto-manage VIRTIO_F_IOMMU_PLATFORM if PV
Date: Tue, 9 Jun 2020 18:05:59 +0200

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.

Seems reasonable, if an incompatible device can crash the whole guest.
Better not even let it start. (And prevent hotplugging it into a
running guest.)

> 
> 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.

Yes, if that is not architected, and no other possible failure code can
map to that case.

> 
> do we really have that many incompatible devices?

Which devices are compatible in the end? It seems the only ones that
are known to be working are virtio-ccw devices with IOMMU_PLATFORM on.
virtio-pci devices and non-virtio ccw (vfio-ccw, 3270) seem to be out,
as far as I understand it. What about non-ccw? PCI in general, vfio-ap?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]