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" <m...@redhat.com> 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 <yamah...@valinux.co.jp> > > > > > > > > > > > > > > > > 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
