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: Windows password security audit tool. GUI, reports in PDF.

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

Date: Thu, 10 Aug 2023 10:47:34 -0600
From: Alex Williamson <alex.williamson@...hat.com>
To: "Tian, Kevin" <kevin.tian@...el.com>
Cc: Jason Gunthorpe <jgg@...dia.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, 10 Aug 2023 02:47:15 +0000
"Tian, Kevin" <kevin.tian@...el.com> wrote:

> > From: Jason Gunthorpe <jgg@...dia.com>
> > Sent: Thursday, August 10, 2023 2:06 AM
> > 
> > On Wed, Aug 09, 2023 at 11:33:00AM -0600, Alex Williamson wrote:
> >   
> > > Shameer, Kevin, Jason, Yishai, I'm hoping one or more of you can
> > > approve this series as well.  Thanks,  
> > 
> > I've looked at it a few times now, I think it is OK, aside from the
> > nvme issue.
> >   
> 
> My only concern is the duplication of backing storage management
> of the migration file which I didn't take time to review.
> 
> If all others are fine to leave it as is then I will not insist.

There's leverage now if you feel strongly about it, but code
consolidation could certainly come later.

Are either of you willing to provide a R-b?

What are we looking for relative to NVMe?  AIUI, the first couple
revisions of this series specified an NVMe device ID, then switched to
a wildcard, then settled on an Ethernet device ID, all with no obvious
changes that would suggest support is limited to a specific device
type.  I think we're therefore concerned that migration of an NVMe VF
could be enabled by overriding/adding device IDs, whereas we'd like to
standardize NVMe migration to avoid avoid incompatible implementations.

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,

Alex