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] [day] [month] [year] [list]
Message-ID: <20260129163150.000059a2@linux.microsoft.com>
Date: Thu, 29 Jan 2026 16:31:50 -0800
From: Jacob Pan <jacob.pan@...ux.microsoft.com>
To: David Matlack <dmatlack@...gle.com>
Cc: Alex Williamson <alex@...zbot.org>, Adithya Jayachandran
 <ajayachandra@...dia.com>, Alexander Graf <graf@...zon.com>, Alex Mastro
 <amastro@...com>, Alistair Popple <apopple@...dia.com>, Andrew Morton
 <akpm@...ux-foundation.org>, Ankit Agrawal <ankita@...dia.com>, Bjorn
 Helgaas <bhelgaas@...gle.com>, Chris Li <chrisl@...nel.org>, David Rientjes
 <rientjes@...gle.com>, Jason Gunthorpe <jgg@...dia.com>, Jason Gunthorpe
 <jgg@...pe.ca>, Jonathan Corbet <corbet@....net>, Josh Hilke
 <jrhilke@...gle.com>, Kevin Tian <kevin.tian@...el.com>,
 kexec@...ts.infradead.org, kvm@...r.kernel.org, Leon Romanovsky
 <leon@...nel.org>, Leon Romanovsky <leonro@...dia.com>,
 linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-kselftest@...r.kernel.org, linux-mm@...ck.org,
 linux-pci@...r.kernel.org, Lukas Wunner <lukas@...ner.de>, Michał Winiarski <michal.winiarski@...el.com>, Mike Rapoport
 <rppt@...nel.org>, Parav Pandit <parav@...dia.com>, Pasha Tatashin
 <pasha.tatashin@...een.com>, Pranjal Shrivastava <praan@...gle.com>,
 Pratyush Yadav <pratyush@...nel.org>, Raghavendra Rao Ananta
 <rananta@...gle.com>, Rodrigo Vivi <rodrigo.vivi@...el.com>, Saeed Mahameed
 <saeedm@...dia.com>, Samiullah Khawaja <skhawaja@...gle.com>, Shuah Khan
 <skhan@...uxfoundation.org>, Thomas Hellström
 <thomas.hellstrom@...ux.intel.com>, Tomita Moeko <tomitamoeko@...il.com>,
 Vipin Sharma <vipinsh@...gle.com>, Vivek Kasireddy
 <vivek.kasireddy@...el.com>, William Tu <witu@...dia.com>, Yi Liu
 <yi.l.liu@...el.com>, Zhu Yanjun <yanjun.zhu@...ux.dev>
Subject: Re: [PATCH v2 10/22] vfio/pci: Skip reset of preserved device after
 Live Update

Hi David,

On Thu, 29 Jan 2026 22:33:13 +0000
David Matlack <dmatlack@...gle.com> wrote:

> On 2026-01-29 02:21 PM, Jacob Pan wrote:
> > On Thu, 29 Jan 2026 21:24:57 +0000 David Matlack
> > <dmatlack@...gle.com> wrote:  
> 
> > > diff --git a/drivers/vfio/pci/vfio_pci_core.c
> > > b/drivers/vfio/pci/vfio_pci_core.c index
> > > b01b94d81e28..c9f73f597797 100644 ---
> > > a/drivers/vfio/pci/vfio_pci_core.c +++
> > > b/drivers/vfio/pci/vfio_pci_core.c @@ -515,12 +515,24 @@ int
> > > vfio_pci_core_enable(struct vfio_pci_core_device *vdev) if (ret)
> > >  		goto out_power;
> > >  
> > > -	/* If reset fails because of the device lock, fail this
> > > path entirely */
> > > -	ret = pci_try_reset_function(pdev);
> > > -	if (ret == -EAGAIN)
> > > -		goto out_disable_device;
> > > +	if (vdev->liveupdate_incoming_state) {
> > > +		/*
> > > +		 * This device was preserved by the previous
> > > kernel across a
> > > +		 * Live Update, so it does not need to be reset.
> > > +		 */
> > > +		vdev->reset_works =
> > > vdev->liveupdate_incoming_state->reset_works;  
> >
> > Just wondering what happened to skipping the bus master clearing. I
> > understand this version does not preserve the device itself yet; I’m
> > just curious whether there were specific difficulties that led to
> > dropping the earlier patch which skipped clearing bus master.  
> 
> Hi Jacob,
> 
> There's several places where bus master gets cleared that we need to
> eventually eliminate to fully preserve the device.
> 
>  1. vfio_pci_liveupdate_freeze() clears it during shutdown when it
>     restores vdev->pci_saved_state.
>  2. pci_device_shutdown() clears it during shutdown.
>  3. vfio_pci_core_enable() clears it when the preserved device file
>     is bound to an iommufd after the Live Update (in
>     vfio_pci_core_enable()).
> 
> I think it would be safe to skip (3) in this series, since that's very
> similar to how this series skips resets during vfio_pci_core_enable()
> for preserved devices.
> 
> But I don't think it would be safe to skip (1) or (2) until the
> attached iommufd is fully preserved.
> 
> If you are just asking about (3) then I agree it could be skipped and
> I can include that in the next version.

I was just asking about (3) and trying to understand the asymmetric
handling compared to reset. I don’t have a strong preference since this
is temporary—thanks for the explanation.

I’ve been testing my noiommu cdev patches on top of yours, and so far
they behave the same as with a real IOMMU. As you noted, however, final
device preservation still depends on iommufd.


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ