Re: [Qemu-devel] Re: [PATCH v6 07/12] pcie/hotplug: introduce pushing attention button command

[Michael S. Tsirkin]

On Mon, Oct 25, 2010 at 04:02:36PM +0900, Isaku Yamahata wrote:
> On Mon, Oct 25, 2010 at 07:55:57AM +0200, Michael S. Tsirkin wrote:
> > On Mon, Oct 25, 2010 at 02:53:16PM +0900, Isaku Yamahata wrote:
> > > On Mon, Oct 25, 2010 at 06:15:37AM +0200, Michael S. Tsirkin wrote:
> > > > On Mon, Oct 25, 2010 at 12:29:57PM +0900, Isaku Yamahata wrote:
> > > > > On Fri, Oct 22, 2010 at 04:38:49PM +0200, Michael S. Tsirkin wrote:
> > > > > > On Fri, Oct 22, 2010 at 01:35:47PM +0200, Markus Armbruster wrote:
> > > > > > > "Michael S. Tsirkin" <address@hidden> writes:
> > > > > > > 
> > > > > > > > On Wed, Oct 20, 2010 at 05:18:56PM +0900, Isaku Yamahata wrote:
> > > > > > > >> glue pcie_push_attention_button command.
> > > > > > > >> 
> > > > > > > >> Signed-off-by: Isaku Yamahata <address@hidden>
> > > > > > > >
> > > > > > > > So as a high level command, I think we need to
> > > > > > > > think about how to tie this into pci_add/pci_del.
> > > > > > > > Right?
> > > > > > > [...]
> > > > > > > 
> > > > > > > Do we have consensus how our set of commands for hot plug should 
> > > > > > > look
> > > > > > > like?  We talked about it, but did we reach consensus?  If yes, 
> > > > > > > did we
> > > > > > > write it down somewhere?
> > > > > > 
> > > > > > I think for simple things yes:
> > > > > > - command to send hotplug notification to the guest
> > > > > > - command to immediately add/remove the device
> > > > > > - event to notify about guest ack
> > > > > > - way to poll status: did guest ack last command?
> > > > > 
> > > > > I'm not sure about guest ack. Let me check my understanding.
> > > > 
> > > > 
> > > > Your understanding is correct.
> > > > 
> > > > > The current qemu pci hot plug has its own hot plug controler,
> > > > > PIIX4_PM, which relies on ACPI.
> > > > > 
> > > > > - command to add the device into the slot
> > > > >   This corresponds to physically inserting the device into the slot.
> > > > >   - qemu pci hot plug case: device_add/pci_add command.
> > > > >     The qemu pci hot plug controller, PIIX4_PM, detects the insertion,
> > > > >     then notify the guest OS of the event via ACPI, _L01.
> > > > >     The guest OS would start to probe the device.
> > > > > 
> > > > >   - pci express native hot plug case: device_add/pci_add command.
> > > > >     The pcie hot plug controller detects the the insertion,
> > > > >     then notify the guest OS of the event via interrupt.
> > > > >     The guest OS would start to probe the device.
> > > > > 
> > > > > - command to remove the device from the slot
> > > > >   This corresponds to physically removing the device from the slot.
> > > > >   - qemu pci hot plug case: No corresponding command.
> > > > >     There is no way to remove the pci card forcibly from the slot.
> > > > > 
> > > > >   - pci express native hot plug case: device_del/pci_del
> > > > >     After the removal of the card, the hot plug controller notifies
> > > > >     the guest OS via interrupt.
> > > > > 
> > > > > - command to send hotplug notification to the guest
> > > > >   command to push attention button.
> > > > >   This corresponds to pushing the button near the slot.
> > > > >   - qemu pci hot plug case: device_del/pci_del command
> > > > >     Maybe the button is called an eject button.
> > > > >     When the button is pushed, the hot plug controller notifies
> > > > >     the guest OS via ACPI, _L01.
> > > > >     Then, guest OS reacts the event by calling ACPI 
> > > > > \_SB.PCI0.S<n>._EJ0
> > > > >     method. It program the hot plug controller to eject the device
> > > > >     in the given slot. As a result, the device is removed from the 
> > > > > slot.
> > > > >     If the guest OS doesn't call _EJ0 (nor programs the controller 
> > > > > directly),
> > > > >     the device stays there.
> > > > >     There is no way to remove the pci card without the guest OS
> > > > >     intervention.
> > > > > 
> > > > >   - pci express native hot plug case:
> > > > >     pcie_push_attention_button command with my patch series.
> > > > >     The hot plug controller raise the interrupt to the guest OS.
> > > > >     There is no specified action from the OS.
> > > > 
> > > > Right. So what is suggested is that we have
> > > > A. a single command to push the attention button
> > > > B. a single command to remove pci card without guest OS interaction
> > > > C. a way to interact with the guest
> > > > management tools or human monitor will be able to tie A,B,C together
> > > > in various interesting ways
> > > > 
> > > Makes sense. How about the following?
> > > 
> > > For A. => pci_push_attention_button command
> > >       qemu pci hot plug case: device_del/pci_del is internally aliased to
> > >                               this command for compatibility.
> > >       pci express native hot plug case: this command is exposed to
> > >                                         the user as is.
> > > 
> > > For B. => pci_unplug command (or other better name?)
> > >       qemu pci hot plug case: -ENOSYS. (until someone implements it.)
> > >       pci express native hot plug case: device_del/pci_del is internally
> > >                                         aliased to this command.
> > > 
> > > For C. => I'm not sure what kind of command is wanted. Any comments?
> > >        - new QMP/HMP command
> > >          enhance info pci command? or info pci-slot command?
> > >          Probably we want to allow hot-plug controller specific infos.
> > 
> > Yes. It probably does not matter which command this is.
> > 
> > > 
> > >        - new QMP event
> > >          - LED change status
> > >            power led: on, off, blinking
> > >            attention led: on, off, blinking
> > >          - slot status change?
> > >            card: inserted, removed
> > >            electromechanical lock: engaged, un-engaged
> > >          Probably we want to allow events specific to the hot-plug 
> > > controller.
> > > 
> > >        - any other?
> > 
> > 
> > I am really interested in high level QMP event that
> > tells us guest ejected the device.
> > This should work for pci and for express.
> 
> Express doesn't have a way for OS to eject the device.
> Neither Standard pci hot plug.
> So ejecting the device would be a event specific to qemu pci hot plug.

Isn't this what LED is used for?

> > Low level stuff for led status etc is noce for a debugging,
> > not really sure about value for users.
> > 
> > > 
> > > 
> > > > What I am also saying is that the same command should be able
> > > > to work for pci and express I think.
> > > 
> > > I see. Then, I think that the slot numbering needs to be discussed.
> > 
> > Yes.
> > 
> > > More concretely, it's what type of argument is passed for push attention
> > > button command.
> > > Here the slot number in general means that the number that is printed near
> > > the physical slot. Not pci (segment, bus, device) triplets.
> > > 
> > > The current qemu pci hot plug abuses the triplets as the slot number
> > > with the assumption of (segment = 0, bus = 0, device = slot number).
> > > On the other hand, pcie hot plug has its own scheme to number the slots.
> > > The correspondence between the triplets and the slot is provided
> > > to the OS. (The standard pci hot plug has its own too which is different
> > > from the pcie one.)
> > > So users may want to operate with the slot number.
> > > User's opinions are needed. Any comments?
> > > 
> > > thanks,
> > 
> > Can we just use the topological address everywhere?
> > Bus numbers are guest assigned, so we can not always
> > rely on them. They are nice for human monitor
> > though and should be way to get from them to
> > topology and back.
> > And for bus 0 they are equivalent.
> 
> Yes, with some kind of conversion.
> We could go with whichever addressing with (slight?) effort
> to implement conversion.
> The point is what users(libvirt? virt-manager?) want.
> 
> thanks,
> 
> > > > > - a way to get the slot status
> > > > >   new command for QMP/HMP? or enhance info pci?
> > > > > 
> > > > > - QMP event for qemu to notify the slot status change
> > > > >   e.g. when LED status is changed, qmp event will be sent.
> > > > > 
> > > > > > Existing ones will keep function:
> > > > > > - send notification and when acked remove device
> > > > > > - add device and send notification
> > > > > > These are useful for human monitor but maybe not
> > > > > > for management.
> > > > > > 
> > > > > > 
> > > > > > -- 
> > > > > > MST
> > > > > > 
> > > > > 
> > > > > -- 
> > > > > yamahata
> > > > 
> > > 
> > > -- 
> > > yamahata
> > 
> 
> -- 
> yamahata