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

[Igor Mammedov <imammedo@redhat.com>]

On Fri, 10 Jul 2026 12:49:06 +0200
Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:

> 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?

note: I'm looking from pov of hotpluggable PCI device and generic hotplug infra, only.

it's not guest users directly, it's how hotplug flow works for various guest OSes:

1. host plugs device in (-device or device_add)
2. guest OS get's notified one way or another and does what ever guest side
   init needed (incl. mounting share in 9pfs case)

opposite flow:
1. host does device_del (basically notify guest to remove device)
2. guest OS frees resources and tells qemu to delete device 
3. qemu process remove event (which incl. unrealize as part of destroying device)

Of cause guest if free to eject device without signal from host,
(I could imagine: get some file from share once and then guest releases
no longer need resource).
 
> 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.

I'd say it's a bug, and you are trying to fix it in patch #1

> Most probably because hotplugging is enabled by 
> default for all devices in QEMU

it is on by default for PCI devices but also heavily depends on used
configuration (where/what is plugged).

> 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).

well, hotplug is on by default for PCI devices. It is unlikely we would
flip default now.

It might make sense to disable hotplug in mmio frontend if such exists,
but then it's pointless as there is no way to trigger unplug for it
(both host or guest side)

> 
> > ---
> > 
> > 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.

one can use device_add to put it back into running machine.

given mention of ACPI eject, 9pfs flavor actually used is PCI variant =>
all PCI device features apply incl. hot(un)plug.
If hotplug is not desirable for particular device instance, one can disable
it on CLI.

that said,
if 9pfs maintainer deem that it shouldn't be hotpluggable and it's
safe to remove capability, I'm fine with that too, just fix commit message
section wrt QMP removal and perhaps move the flag into front-end impl of
the device.

BTW: always describe a way to reproduce problem (cover letter and/or patch)
so that reviewer could see whole flow. Otherwise one has to guess what/how it gets
broken based on context.
 
> 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.

no argument here

> /Christian
> 
> 
> 
>