netdev - Re: [PATCH v14 vfio 6/8] vfio/pds: Add support for dirty page tracking

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 for Android: free password hash cracker in your pocket

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

Date: Mon, 14 Aug 2023 15:51:56 -0700
From: Brett Creeley <bcreeley@....com>
To: Christoph Hellwig <hch@....de>, Jason Gunthorpe <jgg@...dia.com>
Cc: Alex Williamson <alex.williamson@...hat.com>,
 "Tian, Kevin" <kevin.tian@...el.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 8/12/2023 3:49 AM, Christoph Hellwig wrote:
> Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
> 
> 
> 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.
> 

Hi Christoph,

We have folks at AMD participating in NVMe working groups and are aware 
of TPARs related to NVMe live migration. We’re checking to be sure they 
are up to speed on the discussions and will reach out to you if they 
need help getting further involved.

As I mentioned in another response, I've been out for a few days so 
apologies for the delayed response.

Thanks for your help,

Brett