Re: [RFC 0/4] vfio-pci/zdev: Fixing s390 vfio-pci ISM support

[Cornelia Huck <cohuck@redhat.com>]

On Thu, 17 Dec 2020 11:04:48 -0500
Matthew Rosato <mjrosato@linux.ibm.com> wrote:

> On 12/17/20 7:59 AM, Cornelia Huck wrote:
> > The basic question I have is whether it makes sense to specialcase the
> > ISM device (can we even find out that we're dealing with an ISM device
> > here?) to force the non-MIO instructions, as it is just a device with  
> 
> Yes, with the addition of the CLP data passed from the host via vfio 
> capabilities, we can tell this is an ISM device specifically via the 
> 'pft' field in VFOI_DEVICE_INFO_CAP_ZPCI_BASE.  We don't actually 
> surface that field to the guest itself in the Q PCI FN clp rsponse (has 
> to do with Function Measurement Block requirements) but we can certainly 
> use that information in QEMU to restrict this behavior to only ISM devices.
> 
> > some special requirements, or tie non-MIO to relaxed alignment. (Could
> > relaxed alignment devices in theory be served by MIO instructions as
> > well?)  
> 
> In practice, I think there are none today, but per the architecture it 
> IS possible to have relaxed alignment devices served by MIO 
> instructions, so we shouldn't rely on that bit alone as I'm doing in 
> this RFC.  I think instead relying on the pft value as I mention above 
> is what we have to do.

From what you write this looks like the best way to me as well.

> 
> > 
> > Another thing that came to my mind is whether we consider the guest to
> > be using a pci device and needing weird instructions to do that because
> > it's on s390, or whether it is issuing instructions for a device that
> > happens to be a pci device (sorry if that sounds a bit meta :)
> >   
> 
> Typically, I'd classify things as the former but I think ISM seems more 
> like the latter -- To me, ISM seems like less a classic PCI device and 
> more a device that happens to be using s390 PCI interfaces to accomplish 
> its goal.  But it's probably more of a case of this particular device 
> (and it's driver) are s390-specific and therefore built with the unique 
> s390 interface in-mind (and in fact invokes it directly rather than 
> through the general PCI layer), rather than fitting the typical PCI 
> device architecture on top of the s390 interface.

Nod, it certainly feels like that.