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

> 
> With regards,
> Daniel


Reply via email to