On Monday, 20 July 2026 13:23:37 CEST Igor Mammedov wrote: > On Fri, 17 Jul 2026 15:16:14 +0100 > > Daniel P. Berrangé <[email protected]> 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
