On Fri, 10 Jul 2026 15:40:04 +0100 Daniel P. Berrangé <[email protected]> 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 <[email protected]> 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. > > > > > Of cause guest if free to eject device without signal from host, > > > > 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. If unplug 'works', then we shouldn't disable it. If it's never worked to begin with, it should be safe to disable it. > > > (I could imagine: get some file from share once and then guest releases > > > no longer need resource). > > > > It's a pass-through file system. Ejecting the device does not really free a > > noteworthy amount of resources. > > > > > > 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). > > > > Exactly! And I was trying to explain, that for this particular use case > > (9pfs), I don't see any real-live use-case for allowing a guest to eject > > the > > 9p device at runtime. > > > > So why allowing it? Just for fun? > > I don't think it would be usual for a guest to unilaterally "eject" > a 9p device. A host initiated PCI hot-unplug request from QEMU > would ultimately trigger the guest eject code path though. IMHO > host initiated hotplug+unplug is a valid use for any device. For > 9p the use is to provide a time limited data share to some workload > in the guest. There are many other ways that can be done too, > USB MTP, or virtiofs, or in guest with SFTP or WebDAV, etc. > > > With regards, > Daniel
