netdev - RE: [PATCH v12 vfio 4/7] vfio/pds: Add VFIO live migration support

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: <BN9PR11MB52762A02D14E3FAD064A74058C02A@BN9PR11MB5276.namprd11.prod.outlook.com>
Date: Mon, 24 Jul 2023 02:30:09 +0000
From: "Tian, Kevin" <kevin.tian@...el.com>
To: 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>, "alex.williamson@...hat.com"
	<alex.williamson@...hat.com>, "jgg@...dia.com" <jgg@...dia.com>,
	"yishaih@...dia.com" <yishaih@...dia.com>,
	"shameerali.kolothum.thodi@...wei.com" <shameerali.kolothum.thodi@...wei.com>
CC: "shannon.nelson@....com" <shannon.nelson@....com>
Subject: RE: [PATCH v12 vfio 4/7] vfio/pds: Add VFIO live migration support

> From: Brett Creeley <bcreeley@....com>
> Sent: Saturday, July 22, 2023 3:18 PM
> >> +
> >> +static struct pds_vfio_lm_file *
> >> +pds_vfio_get_lm_file(const struct file_operations *fops, int flags, u64
> size)
> >> +{
> >> +     struct pds_vfio_lm_file *lm_file = NULL;
> >> +     unsigned long long npages;
> >> +     struct page **pages;
> >> +     void *page_mem;
> >> +     const void *p;
> >> +
[...]
> >
> > I wonder whether the logic about migration file can be generalized.
> > It's not very maintainable to have every migration driver implementing
> > their own code for similar functions.
> >
> > Did I overlook any device specific setup required here?
> 
> There isn't device specific setup, but the other drivers were different
> enough that it wasn't a straight forward task. I think it might be
> possible to refactor the drivers to some common functionality here, but
> IMO this seems like a task that can be further explored once this series
> is merged.
> 

If there is no device specific setup I don't see a reason to further proliferate
the code duplication. At least it's an increasing review burden to me.

I'd like to hear opinions from other reviewers.