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

[Michael S. Tsirkin]

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

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