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
| ||
|
Date: Wed, 22 Feb 2023 23:01:33 -0800 From: Brett Creeley <bcreeley@....com> To: Jason Gunthorpe <jgg@...dia.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 2/20/2023 5:11 PM, Jason Gunthorpe wrote: > Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding. > > > 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. Okay, we'll look at revising/updating our VF device ID scheme for a specific VF and add that entry in the PCI ID table. > > 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 Can you please expand on the "aux for all or aux for none" comment? It's not clear what you mean here. > making up their own stuff here. Especially since this implementation > is wrongly locked and racy. Can you please provide more details on what's wrongly locked and racy? Thanks for the review. Brett > > Jason
Powered by blists - more mailing lists