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]
Date: Sat, 12 Aug 2023 12:49:51 +0200
From: Christoph Hellwig <hch@....de>
To: Jason Gunthorpe <jgg@...dia.com>
Cc: Alex Williamson <alex.williamson@...hat.com>,
	Christoph Hellwig <hch@....de>,
	"Tian, Kevin" <kevin.tian@...el.com>,
	Brett Creeley <bcreeley@....com>,
	Brett Creeley <brett.creeley@....com>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"yishaih@...dia.com" <yishaih@...dia.com>,
	"shameerali.kolothum.thodi@...wei.com" <shameerali.kolothum.thodi@...wei.com>,
	"horms@...nel.org" <horms@...nel.org>,
	"shannon.nelson@....com" <shannon.nelson@....com>
Subject: Re: [PATCH v14 vfio 6/8] vfio/pds: Add support for dirty page
 tracking

On Thu, Aug 10, 2023 at 02:19:40PM -0300, Jason Gunthorpe wrote:
> > It's somewhat a strange requirement since we have no expectation of
> > compatibility between vendors for any other device type, but how far
> > are we going to take it?  Is it enough that the device table here only
> > includes the Ethernet VF ID or do we want to actively prevent what
> > might be a trivial enabling of migration for another device type
> > because we envision it happening through an industry standard that
> > currently doesn't exist?  Sorry if I'm not familiar with the dynamics
> > of the NVMe working group or previous agreements.  Thanks,
> 
> I don't really have a solid answer. Christoph and others in the NVMe
> space are very firm that NVMe related things must go through
> standards, I think that is their right.

Yes, anything that uses a class code needs a standardized way of
being managed.  That is very different from say mlx5 which is obviously
controlled by Mellanox.

So I don't think any vfio driver except for the plain passthrough ones
should bind anything but very specific PCI IDs.

And AMD really needs to join the NVMe working group where the passthrough
work is happening right now.  If you need help finding the right persons
at AMD to work with NVMe send me a mail offline, I can point you to them.


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ