linux-kernel - Re: [PATCH RFC v1 0/3] Introduce vfio-pci-core subsystem

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20210126172354.GH4147@nvidia.com>
Date:   Tue, 26 Jan 2021 13:23:54 -0400
From:   Jason Gunthorpe <jgg@...dia.com>
To:     Alex Williamson <alex.williamson@...hat.com>
CC:     Cornelia Huck <cohuck@...hat.com>,
        Max Gurtovoy <mgurtovoy@...dia.com>, <kvm@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <liranl@...dia.com>,
        <oren@...dia.com>, <tzahio@...dia.com>, <leonro@...dia.com>,
        <yarong@...dia.com>, <aviadye@...dia.com>, <shahafs@...dia.com>,
        <artemp@...dia.com>, <kwankhede@...dia.com>, <ACurrid@...dia.com>,
        <gmataev@...dia.com>, <cjia@...dia.com>
Subject: Re: [PATCH RFC v1 0/3] Introduce vfio-pci-core subsystem

On Mon, Jan 25, 2021 at 08:34:29PM -0700, Alex Williamson wrote:

> > someting like this was already tried in May and didn't go anywhere -
> > are you surprised that we are reluctant to commit alot of resources
> > doing a complete job just to have it go nowhere again?
> 
> That's not really what I'm getting from your feedback, indicating
> vfio-pci is essentially done, the mlx stub driver should be enough to
> see the direction, and additional concerns can be handled with TODO
> comments. 

I think we are looking at this RFC in different ways. I see it as
largely "done" showing the general design of few big ideas:

 - new vfio drivers will be creating treating VFIO PCI as a "VFIO bus
   driver" library
 - These new drivers are PCI devices bound via driver core as peers to
   vfio-pci, vs sub drivers of vfio-pci
 - It uses the subsystem -> driver -> library pattern for composing drivers
   instead of the subsystem -> midlayer -> driver pattern mdev/platform use
 - It will have some driver facing API from vfio-pci-core that is
   close to what is shown in the RFC
 - The drivers can "double bind" in the driver core to access the PF
   resources via aux devices from the VF VFIO driver.

The point of a RFC discussion is to try to come to some community
understanding on a general high level direction.

It is not a perfectly polished illustration of things that shouldn't
be contentious or technically hard. There are alot of things that can
be polished here, this illustration has lots of stuff in vfio-pci-core
that really should be in vfio-pci - it will take time and effort to
properly split things up and do a great job here.

> Sorry if this is not construed as actual feedback, I think both
> Connie and I are making an effort to understand this and being
> hampered by lack of a clear api or a vendor driver that's anything
> more than vfio-pci plus an aux bus interface.  Thanks,

I appreciate the effort, and there is a lot to understand here. Most
of this stuff is very new technology and not backed by industry
standards bodies.

I really do think this simplified RFC will help the process - I've
seen the internal prototype and it is a mass of opaque device specific
code. Max's V2 should flesh things out more.

Thanks,
Jason