Re: [PATCH 2/3] hw/9pfs/virtio: disable hotpluggable property of virtio-9p device

[Christian Schoenebeck <qemu_oss@crudebyte.com>]

On Friday, 10 July 2026 12:23:45 CEST Igor Mammedov wrote:
> On Fri, 10 Jul 2026 10:06:29 +0200
> 
> Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:
> > On Friday, 10 July 2026 09:37:37 CEST Igor Mammedov wrote:
> > > On Thu, 9 Jul 2026 15:50:36 +0200
> > > 
> > > Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:
> > > > Harden security by disabling hotpluggable property, to prevent
> > > > issues like fixed in the previous commit.
> > > > 
> > > > Virtio-9p is a pass-through file-sharing device that provides a
> > > > guest mount of a host filesystem tree. Unlike block or network
> > > > devices, guest-triggered hotplug of the 9p device has no practical
> > > > use case: the guest cannot recover from the device removal, and there
> > > > is no protocol-level device-loss scenario as with block or ethernet
> > > > devices.
> > > 
> > > hmh, I'm no maintainer of 9pfs, but to me it looks like any other
> > > storage device.
> > > One should be able to unmount/stop using it and unplug
> > > (it doesn't really matter if unplug is triggered by guest or host side).
> > 
> > Guest could still unmount and stop using the 9pfs device. But why should
> > guest be able to unrealize the 9pfs device at any time? What should be
> > the purpose for this particular device?
> 
> unrealize is part of unplug process, at the end of unplug no device should
> be left attached. You might not need/use it but others might be using it
> actively.

I got that, but my question was: why would they want to do that with an 9pfs 
device? Can you make up any real-life scenario why a guest might want to 
remove a 9p device, given there is no way for them to bring the device back?

Looking at the fixed issue (patch 1), my impression was that original 9p 
server developers were unaware that guest can actually trigger a device 
unrealize via ACPI eject. Most probably because hotplugging is enabled by 
default for all devices in QEMU

Independent of this patch here, I'm therefore currently investigating whether 
enabling hotplugging by default in QEMU actually make sense. To me, this 
should be an opt-in, not the other way around. Because device developers 
should make sure that ejecting a device a) makes sense for the device type in 
the first place and most importantly b) that ejecting the device works 
(without data loss and without negative security impact, as it was the case 
here).

> ---
> 
> In QEMU impl. it's cooperative process (we don't do surprise removal of PCI
> devices), where host triggers plug/unplug process and guest side completes
> it, by: 1. freeing resources on its side 1st (hopefully)
>   2. issuing eject/poweroff (either via ACPI or native PCIE-HP/SHPC
> interface)
> 
> If guest fails to do #1 it is able to abort process, or it might continue
> and do #2 with a risk of loosing data but it's guest's business/policy.
> 
> If you need to disable hotplug for a specific PCI device instance,
> use 'hotplug' CLI option on pcie bridge. If you use other than PCI variant
> of virtio device, then unplug as you describe it isn't reachable, and if it
> should be disabled in code, it's up to actual frontend device that exposes
> underlying virtio one.

What does that have to do with this issue here? The normal 9pfs live-cycle is 
to create the 9p device at QEMU startup, and unrealizing the 9p device at QEMU 
shutdown.

If guest does an ACPI eject, then the only way to bring the 9p device back is 
to restart QEMU with the required -virtfs / -fsdev -device CLI options.

The Linux 9p client (guest) does never trigger an ACPI reject on unmount. It 
just marks the virtio channel as unused. If client would eject it, it would 
not be possible for guest to re-mount it later on.

/Christian