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

[Christian Schoenebeck <qemu_oss@crudebyte.com>]

On Monday, 13 July 2026 09:49:35 CEST Igor Mammedov wrote:
> On Fri, 10 Jul 2026 15:40:04 +0100
> 
> Daniel P. Berrangé <berrange@redhat.com> wrote:
> > On Fri, Jul 10, 2026 at 04:31:51PM +0200, Christian Schoenebeck wrote:
> > > On Friday, 10 July 2026 14:51:49 CEST Igor Mammedov wrote:
> > > > 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:
> > > [...]
> > > 
> > > > note: I'm looking from pov of hotpluggable PCI device and generic
> > > > hotplug
> > > > infra, only.
> > > 
> > > That's okay, but so far I don't see the relevance for this particular 9p
> > > device.
> > > 
> > > > 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)
> > > 
> > > That's not affected by this patch, right?
> > > 
> > > > 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)
> > > 
> > > And that's not affected by this patch either, right?
> 
> the patch would break unplug flow by effectively removing 'eject' knob
> from guest side, which is part of unplug flow.

These are two different things: device_del would not be affected by this. 

1. Ejecting the device from host side e.g. via QMP would still work.

vs.

2. Ejecting from guest side OTOH would be disabled.

It is also different from regular block devices where you have convenient ways
to eject a block device on guest OSes. For a virtio-9p device it is not that
easy.

> > > OK, here is the point where we deviate: you are apparently seeing this
> > > from a purely theoretical PoV.
> > > 
> > > I am facing reality: for several years I'm the only person taking care
> > > about this piece of code at all (on a side channel, for free, next to
> > > my actual work). And for several months I get AI generated security
> > > reports thrown at me, where I have to a) filter legit ones, and b) fix
> > > those legit security issues.
> > > 
> > > For that reason, I am tightening security wherever I can, to prevent
> > > further flood.
> > > 
> > > So the question here is: are you concerned about a real-life issue being
> > > introduced by disabling hotplugging for 9pfs specifically?
> 
> my concern is that there might be users that use unplug despite present
> bug(s), and the patch would regress their usecase.

I already got that with your first message, and directly asked which use-case
that would be exactly.

Just saying there might be one theoretical unknown person on this planet who
might be using it, and nobody even being capable to imagine what for, does not
justify keeping an exotic feature (again: context 9pfs) that already had
negative impact on security for anybody else, especially for such a low man
power codebase like 9pfs.

This is similar to a discussion in the past about retaining support for older
macOS versions in QEMU:

https://lore.kernel.org/qemu-devel/CAFEAcA9VnQCG3r28BOLr_qXLRM2V68r3oK4ZfY9+bVz2j1oSyA@mail.gmail.com/

Anyway, I decided to drop this patch and retaining guest eject for now.

However if there is any other kind of bug, especially of security nature, then
I will definitely disable guest eject unless proven there are justified real-
world users or somebody willing to step-in and keeping care of.

/Christian