On Fri, Aug 22, 2025 at 01:53:02PM +0000, Parav Pandit wrote:
>
>
> > From: Michael S. Tsirkin <m...@redhat.com>
> > Sent: 22 August 2025 06:35 PM
> >
> > On Fri, Aug 22, 2025 at 12:24:06PM +0000, Parav Pandit wrote:
> > >
> > > > From: Li,Rongqing <lirongq...@baidu.com>
> > > > Sent: 22 August 2025 03:57 PM
> > > >
> > > > > This reverts commit 43bb40c5b926 ("virtio_pci: Support surprise
> > > > > removal of virtio pci device").
> > > > >
> > > > > Virtio drivers and PCI devices have never fully supported true
> > > > > surprise (aka hot
> > > > > unplug) removal. Drivers historically continued processing and
> > > > > waiting for pending I/O and even continued synchronous device
> > > > > reset during surprise removal. Devices have also continued
> > > > > completing I/Os, doing DMA and allowing device reset after surprise
> > removal to support such drivers.
> > > > >
> > > > > Supporting it correctly would require a new device capability and
> > > > > driver negotiation in the virtio specification to safely stop I/O
> > > > > and free queue
> > > > memory.
> > > > > Failure to do so either breaks all the existing drivers with call
> > > > > trace listed in the commit or crashes the host on continuing the DMA.
> > > > > Hence, until such specification and devices are invented, restore
> > > > > the previous behavior of treating surprise removal as graceful
> > > > > removal to avoid regressions and maintain system stability same as
> > > > > before the commit 43bb40c5b926 ("virtio_pci: Support surprise
> > > > > removal of virtio pci
> > > > device").
> > > > >
> > > > > As explained above, previous analysis of solving this only in
> > > > > driver was incomplete and non-reliable at [1] and at [2]; Hence
> > > > > reverting commit
> > > > > 43bb40c5b926 ("virtio_pci: Support surprise removal of virtio pci
> > > > > device") is still the best stand to restore failures of virtio net
> > > > > and block
> > > > devices.
> > > > >
> > > > > [1]
> > > > >
> > > > https://lore.kernel.org/virtualization/CY8PR12MB719506CC5613EB100BC6
> > > > C6
> > > > > 38 dc...@cy8pr12mb7195.namprd12.prod.outlook.com/#t
> > > > > [2]
> > > > > https://lore.kernel.org/virtualization/20250602024358.57114-1-para
> > > > > v@nv
> > > > > idia.c
> > > > > om/
> > > > >
> > > > > Fixes: 43bb40c5b926 ("virtio_pci: Support surprise removal of
> > > > > virtio pci device")
> > > > > Cc: sta...@vger.kernel.org
> > > > > Reported-by: lirongq...@baidu.com
> > > > > Closes:
> > > > > https://lore.kernel.org/virtualization/c45dd68698cd47238c55fb73ca9
> > > > > b474
> > > > > 1@b
> > > > > aidu.com/
> > > > > Signed-off-by: Parav Pandit <pa...@nvidia.com>
> > > >
> > > >
> > > >
> > > > Tested-by: Li RongQing <lirongq...@baidu.com>
> > > >
> > > > Thanks
> > > >
> > > > -Li
> > > >
> > > Multiple users are blocked to have this fix in stable kernel.
> >
> > what are these users doing that is blocked by this fix?
> >
> Not sure I understand the question. Let me try to answer.
> They are unable to dynamically add/remove the virtio net, block, fs devices
> in their systems.
> Users have their networking applications running over NS network and database
> and file system through these devices.
> Some of them keep reverting the patch. Some are unable to.
> They are in search of stable kernel.
>
> Did I understand your question?
>
Not really, sorry.
Does the system or does it not have a mechanical interlock?
If it does, how does a user run into surprise removal issues without
the ability to remove the device?
If it does not, and a user pull out the working device, how does your
patch help?
--
MST
