lkml.org 
[lkml]   [2020]   [Dec]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC 0/4] vfio-pci/zdev: Fixing s390 vfio-pci ISM support
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.

\
 
 \ /
  Last update: 2020-12-22 17:20    [W:0.064 / U:1.568 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site