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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20201222171822.2d9b5962.cohuck@redhat.com>
Date:   Tue, 22 Dec 2020 17:18:22 +0100
From:   Cornelia Huck <cohuck@...hat.com>
To:     Matthew Rosato <mjrosato@...ux.ibm.com>
Cc:     alex.williamson@...hat.com, schnelle@...ux.ibm.com,
        pmorel@...ux.ibm.com, borntraeger@...ibm.com, hca@...ux.ibm.com,
        gor@...ux.ibm.com, gerald.schaefer@...ux.ibm.com,
        linux-s390@...r.kernel.org, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC 0/4] vfio-pci/zdev: Fixing s390 vfio-pci ISM support

On Thu, 17 Dec 2020 11:04:48 -0500
Matthew Rosato <mjrosato@...ux.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.