netdev - Re: [PATCH v3 vfio 0/7] pds vfio driver

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: <Y/QaVdnL+URV7oAk@nvidia.com>
Date:   Mon, 20 Feb 2023 21:11:49 -0400
From:   Jason Gunthorpe <jgg@...dia.com>
To:     Brett Creeley <bcreeley@....com>
Cc:     Christoph Hellwig <hch@...radead.org>,
        Brett Creeley <brett.creeley@....com>, kvm@...r.kernel.org,
        netdev@...r.kernel.org, alex.williamson@...hat.com,
        cohuck@...hat.com, yishaih@...dia.com,
        shameerali.kolothum.thodi@...wei.com, kevin.tian@...el.com,
        shannon.nelson@....com, drivers@...sando.io
Subject: Re: [PATCH v3 vfio 0/7] pds vfio driver

On Mon, Feb 20, 2023 at 04:45:51PM -0800, Brett Creeley wrote:
> > On Sun, Feb 19, 2023 at 12:39:01AM -0800, Brett Creeley wrote:
> > > This is a draft patchset for a new vendor specific VFIO driver
> > > (pds_vfio) for use with the AMD/Pensando Distributed Services Card
> > > (DSC). This driver is device type agnostic and live migration is
> > > supported as long as the underlying SR-IOV VF supports live migration
> > > on the DSC. This driver is a client of the newly introduced pds_core
> > > driver, which the latest version can be referenced at:
> > 
> > Just as a broken clock:  non-standard nvme live migration is not
> > acceptable.  Please work with the NVMe technical workning group to
> > get this feature standardized.  Note that despite various interested
> > parties on linux lists I've seen exactly zero activity from the
> > (not so) smart nic vendors active there.
> 
> 
> You're right, we intend to work with the respective groups, and we removed
> any mention of NVMe from the series. However, this solution applies to our
> other PCI devices.

The first posting had a PCI ID that was literally only for NVMe and
now suddenly this very same driver supports "other devices" with nary
a mention of what those devices are? It strains credibility.

List the exact IDs of these other devices in your PCI ID table and
don't try to get away with a PCI_ANY_ID that just happens to match the
NVMe device ID too.

Keeping in mind that PCI IDs of the VF are not supposed to differ from
the PF so this looks like a spec violation to me too :\

You have to remove the aux bus stuff also if you want this taken
seriously. Either aux for all or aux for none, I don't want drivers
making up their own stuff here. Especially since this implementation
is wrongly locked and racy.

Jason