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

[Christian Schoenebeck <qemu_oss@crudebyte.com>]

On Monday, 20 July 2026 13:23:37 CEST Igor Mammedov wrote:
> On Fri, 17 Jul 2026 15:16:14 +0100
> 
> Daniel P. Berrangé <berrange@redhat.com> wrote:
> > On Fri, Jul 17, 2026 at 04:05:42PM +0200, Christian Schoenebeck wrote:
> > > On Monday, 13 July 2026 09:49:35 CEST Igor Mammedov wrote:
[...]
> > > > 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.
> > 
> > Igor can correct me if I'm wrong, but IIUC there's no distinction
> > to those 2 scenarios from the guest POV.
> > 
> > A "device_del" in QMP does not actually delete a device from the
> > QEMU POV.  Rather it triggers an ACPI notification to the geust
> > OS, that the operator wants to unplug the device.  The guest OS
> > then honours (or not) that by initiating a guest side "eject".
> > IOW disabling guest initiated eject would break device_del too
> > AFAIK.
> 
> That's how it works.
> Sorry if I wasn't able to convey the message in my previous replies.

OK, I just realized I was wrong. The QMP device_del path also checks for
dc->hotpluggable early via qdev_hotplug_unplug_allowed_common() and would 
already abort there. And I can also see the flow that it just triggers ACPI 
and guest eventually completing device eject.
 
So yes, it would disable both guest *and* host side eject.

I already dropped this patch from v2 anyway.

Thanks!

/Christian