On Tue, 9 Jun 2020 17:47:47 +0200 Claudio Imbrenda <imbre...@linux.ibm.com> wrote:
> On Tue, 9 Jun 2020 11:41:30 +0200 > Halil Pasic <pa...@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?
