| Message ID | 2f5cb93039ab90a7b267334dd5e2e94b7a550b9f.1287562197.git.yamahata@valinux.co.jp |
|---|---|
| State | New |
| Headers | show |
On Wed, Oct 20, 2010 at 05:18:56PM +0900, Isaku Yamahata wrote: > glue pcie_push_attention_button command. > > Signed-off-by: Isaku Yamahata <yamahata@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? As a low level command, this is not really useful unless there is an event on LED status change and a way to get info on LED status. Right? > --- > hw/pcie_port.c | 82 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ > qemu-monitor.hx | 14 +++++++++ > sysemu.h | 4 +++ > 3 files changed, 100 insertions(+), 0 deletions(-) > > diff --git a/hw/pcie_port.c b/hw/pcie_port.c > index 117de61..f43a1c7 100644 > --- a/hw/pcie_port.c > +++ b/hw/pcie_port.c > @@ -18,6 +18,10 @@ > * with this program; if not, see <http://www.gnu.org/licenses/>. > */ > > +#include "qemu-objects.h" > +#include "sysemu.h" > +#include "monitor.h" > +#include "pcie.h" > #include "pcie_port.h" > > void pcie_port_init_reg(PCIDevice *d) > @@ -114,3 +118,81 @@ void pcie_chassis_del_slot(PCIESlot *s) > { > QLIST_REMOVE(s, next); > } > + > +/************************************************************************** > + * glue for qemu monitor > + */ > + > +/* Parse [<chassis>.]<slot>, return -1 on error */ > +static int pcie_parse_slot_addr(const char* slot_addr, > + uint8_t *chassisp, uint16_t *slotp) > +{ > + const char *p; > + char *e; > + unsigned long val; > + unsigned long chassis = 0; > + unsigned long slot; > + > + p = slot_addr; > + val = strtoul(p, &e, 0); > + if (e == p) { > + return -1; > + } > + if (*e == '.') { > + chassis = val; > + p = e + 1; > + val = strtoul(p, &e, 0); > + if (e == p) { > + return -1; > + } > + } > + slot = val; > + > + if (*e) { > + return -1; > + } > + > + if (chassis > 0xff || slot > 0xffff) { > + return -1; > + } > + > + *chassisp = chassis; > + *slotp = slot; > + return 0; > +} > + > +void pcie_attention_button_push_print(Monitor *mon, const QObject *data) > +{ > + QDict *qdict; > + > + assert(qobject_type(data) == QTYPE_QDICT); > + qdict = qobject_to_qdict(data); > + > + monitor_printf(mon, "OK chassis %d, slot %d\n", > + (int) qdict_get_int(qdict, "chassis"), > + (int) qdict_get_int(qdict, "slot")); > +} > + > +int pcie_attention_button_push(Monitor *mon, const QDict *qdict, > + QObject **ret_data) > +{ > + const char* pcie_slot = qdict_get_str(qdict, "pcie_slot"); > + uint8_t chassis; > + uint16_t slot; > + PCIESlot *s; > + > + if (pcie_parse_slot_addr(pcie_slot, &chassis, &slot) < 0) { > + monitor_printf(mon, "invalid pcie slot address %s\n", pcie_slot); > + return -1; > + } > + s = pcie_chassis_find_slot(chassis, slot); > + if (!s) { > + monitor_printf(mon, "slot is not found. %s\n", pcie_slot); > + return -1; > + } > + pcie_cap_slot_push_attention_button(&s->port.br.dev); > + *ret_data = qobject_from_jsonf("{ 'chassis': %d, 'slot': %d}", > + chassis, slot); > + assert(*ret_data); > + return 0; > +} > diff --git a/qemu-monitor.hx b/qemu-monitor.hx > index 2af3de6..965c754 100644 > --- a/qemu-monitor.hx > +++ b/qemu-monitor.hx > @@ -1154,6 +1154,20 @@ Hot remove PCI device. > ETEXI > > { > + .name = "pcie_push_attention_button", > + .args_type = "pcie_slot:s", > + .params = "[<chassis>.]<slot>", > + .help = "push pci express attention button", > + .user_print = pcie_attention_button_push_print, > + .mhandler.cmd_new = pcie_attention_button_push, > + }, > + > +STEXI > +@item pcie_abp > +Push PCI express attention button > +ETEXI > + > + { > .name = "host_net_add", > .args_type = "device:s,opts:s?", > .params = "tap|user|socket|vde|dump [options]", > diff --git a/sysemu.h b/sysemu.h > index 9c988bb..cca411d 100644 > --- a/sysemu.h > +++ b/sysemu.h > @@ -150,6 +150,10 @@ extern unsigned int nb_prom_envs; > void pci_device_hot_add(Monitor *mon, const QDict *qdict); > void drive_hot_add(Monitor *mon, const QDict *qdict); > void do_pci_device_hot_remove(Monitor *mon, const QDict *qdict); > +/* pcie hotplug */ > +void pcie_attention_button_push_print(Monitor *mon, const QObject *data); > +int pcie_attention_button_push(Monitor *mon, const QDict *qdict, > + QObject **ret_data); > > /* serial ports */ > > -- > 1.7.1.1
On Wed, Oct 20, 2010 at 12:00:11PM +0200, Michael S. Tsirkin wrote: > On Wed, Oct 20, 2010 at 05:18:56PM +0900, Isaku Yamahata wrote: > > glue pcie_push_attention_button command. > > > > Signed-off-by: Isaku Yamahata <yamahata@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? Maybe or maybe not. I'm not sure it's a good idea to tie it to pci_add/pci_del in the first place. The specification says only that pushing the button is just to initiate the hot-plug operation. It means only a notification. The spec says nothing about the concrete action from OS when the button is pushed. It's up to OS. For example. OS may start to probe the slot. OS may start to quiescence the device. OS is allowed to ignore the notification. OS may propagate the notification to the management software, and it would pop up the dialog to the user for further operation. > As a low level command, this is not really useful unless > there is an event on LED status change and a way > to get info on LED status. > Right? No. Guest OS can provide users those infos, and Linux does via sysfs. So there already is a way to know LED status. This is the reason why LED status change event stuff has low priority in my TODO list.
On Thu, Oct 21, 2010 at 12:46:33PM +0900, Isaku Yamahata wrote: > On Wed, Oct 20, 2010 at 12:00:11PM +0200, Michael S. Tsirkin wrote: > > On Wed, Oct 20, 2010 at 05:18:56PM +0900, Isaku Yamahata wrote: > > > glue pcie_push_attention_button command. > > > > > > Signed-off-by: Isaku Yamahata <yamahata@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? > > Maybe or maybe not. > I'm not sure it's a good idea to tie it to pci_add/pci_del > in the first place. > The specification says only that pushing the button is just to > initiate the hot-plug operation. It means only a notification. > The spec says nothing about the concrete action from OS when > the button is pushed. It's up to OS. > > For example. > OS may start to probe the slot. > OS may start to quiescence the device. > OS is allowed to ignore the notification. > OS may propagate the notification to the management software, > and it would pop up the dialog to the user for further operation. > pci_add/pci_del really behave in the same way. There's no way to force the OS to respond. We only use ACPI for now, but for express I expect standard interfaces will work better long term. > > As a low level command, this is not really useful unless > > there is an event on LED status change and a way > > to get info on LED status. > > Right? > > No. Guest OS can provide users those infos, and Linux does > via sysfs. So there already is a way to know LED status. > This is the reason why LED status change event stuff has low > priority in my TODO list. But that's in the guest.
On Thu, Oct 21, 2010 at 10:02:37AM +0200, Michael S. Tsirkin wrote: > On Thu, Oct 21, 2010 at 12:46:33PM +0900, Isaku Yamahata wrote: > > On Wed, Oct 20, 2010 at 12:00:11PM +0200, Michael S. Tsirkin wrote: > > > On Wed, Oct 20, 2010 at 05:18:56PM +0900, Isaku Yamahata wrote: > > > > glue pcie_push_attention_button command. > > > > > > > > Signed-off-by: Isaku Yamahata <yamahata@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? > > > > Maybe or maybe not. > > I'm not sure it's a good idea to tie it to pci_add/pci_del > > in the first place. > > The specification says only that pushing the button is just to > > initiate the hot-plug operation. It means only a notification. > > The spec says nothing about the concrete action from OS when > > the button is pushed. It's up to OS. > > > > For example. > > OS may start to probe the slot. > > OS may start to quiescence the device. > > OS is allowed to ignore the notification. > > OS may propagate the notification to the management software, > > and it would pop up the dialog to the user for further operation. > > > > pci_add/pci_del really behave in the same way. There's no way to force > the OS to respond. We only use ACPI for now, but for express I expect > standard interfaces will work better long term. The current qemu pci hot plug requires guest OS intervention as you said. On the other hand, The express hot plug doesn't requires the intervention. pci_add/pci_del for express simply populates/deletes PCIDvice (+ interrupt). No guest OS intervention. It really corresponds to physical insertion/removal of the pcie card into/from the slot. Probably I don't understand what you mean by "tie it to pci_add/pci_del". The command shouldn't be express specific, but more generic? or something else?
"Michael S. Tsirkin" <mst@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 <yamahata@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?
On Fri, Oct 22, 2010 at 01:35:47PM +0200, Markus Armbruster wrote: > "Michael S. Tsirkin" <mst@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 <yamahata@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? 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.
On 10/22/2010 09:38 AM, Michael S. Tsirkin wrote: > On Fri, Oct 22, 2010 at 01:35:47PM +0200, Markus Armbruster wrote: > >> "Michael S. Tsirkin"<mst@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<yamahata@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 > Is it a guest ack? I thought it was actually an eject that can be initiated without the notification being sent to the guest. If so, polling doesn't really make much sense. Regards, Anthony Liguori > - way to poll status: did guest ack last command? > > 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. > > >
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" <mst@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 <yamahata@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. 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. - 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 >
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" <mst@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 <yamahata@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 What I am also saying is that the same command should be able to work for pci and express I think. > - 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
On Fri, Oct 22, 2010 at 09:52:19AM -0500, Anthony Liguori wrote: > On 10/22/2010 09:38 AM, Michael S. Tsirkin wrote: > >On Fri, Oct 22, 2010 at 01:35:47PM +0200, Markus Armbruster wrote: > >>"Michael S. Tsirkin"<mst@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<yamahata@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 > > Is it a guest ack? I thought it was actually an eject that can be > initiated without the notification being sent to the guest. Yes. > If so, polling doesn't really make much sense. Who said something about polling? > Regards, > > Anthony Liguori > > >- way to poll status: did guest ack last command? > > > >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. > > > >
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" <mst@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 <yamahata@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. - 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? > 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. 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, > > - 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 >
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" <mst@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 <yamahata@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. 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
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" <mst@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 <yamahata@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. > 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 >
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" <mst@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 <yamahata@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
On Mon, Oct 25, 2010 at 04:02:36PM +0900, Isaku Yamahata wrote: > > > > 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. When pushing the attention button, we are talking to the hot plug controller, not the device in the slot. The button can be pushed even when the slot is empty. In qemu pci hot plug case the button is used only for device ejection, so (segment, bus, device) triplet (or any address to specify the device in the slot) works. But such address doesn't work for pcie case. (nor for standard pci hot plug case) Address that will be used should be able to specify the slot itself without the device.
On Wed, Oct 27, 2010 at 10:47:11AM +0900, Isaku Yamahata wrote: > On Mon, Oct 25, 2010 at 04:02:36PM +0900, Isaku Yamahata wrote: > > > > > 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. > > When pushing the attention button, we are talking to the hot plug > controller, not the device in the slot. > The button can be pushed even when the slot is empty. > > In qemu pci hot plug case the button is used only for device > ejection, so (segment, bus, device) triplet (or any address to specify > the device in the slot) works. > But such address doesn't work for pcie case. (nor for standard pci hot > plug case) > Address that will be used should be able to specify the slot itself > without the device. Not sure I understand. The device number is the number of the slot on the bus anyway, isn't it? The only issue is that the bus must be specified by the topology used to reach it, not bus number since that is guest assigned expect for the root which is always 0. > -- > yamahata
diff --git a/hw/pcie_port.c b/hw/pcie_port.c index 117de61..f43a1c7 100644 --- a/hw/pcie_port.c +++ b/hw/pcie_port.c @@ -18,6 +18,10 @@ * with this program; if not, see <http://www.gnu.org/licenses/>. */ +#include "qemu-objects.h" +#include "sysemu.h" +#include "monitor.h" +#include "pcie.h" #include "pcie_port.h" void pcie_port_init_reg(PCIDevice *d) @@ -114,3 +118,81 @@ void pcie_chassis_del_slot(PCIESlot *s) { QLIST_REMOVE(s, next); } + +/************************************************************************** + * glue for qemu monitor + */ + +/* Parse [<chassis>.]<slot>, return -1 on error */ +static int pcie_parse_slot_addr(const char* slot_addr, + uint8_t *chassisp, uint16_t *slotp) +{ + const char *p; + char *e; + unsigned long val; + unsigned long chassis = 0; + unsigned long slot; + + p = slot_addr; + val = strtoul(p, &e, 0); + if (e == p) { + return -1; + } + if (*e == '.') { + chassis = val; + p = e + 1; + val = strtoul(p, &e, 0); + if (e == p) { + return -1; + } + } + slot = val; + + if (*e) { + return -1; + } + + if (chassis > 0xff || slot > 0xffff) { + return -1; + } + + *chassisp = chassis; + *slotp = slot; + return 0; +} + +void pcie_attention_button_push_print(Monitor *mon, const QObject *data) +{ + QDict *qdict; + + assert(qobject_type(data) == QTYPE_QDICT); + qdict = qobject_to_qdict(data); + + monitor_printf(mon, "OK chassis %d, slot %d\n", + (int) qdict_get_int(qdict, "chassis"), + (int) qdict_get_int(qdict, "slot")); +} + +int pcie_attention_button_push(Monitor *mon, const QDict *qdict, + QObject **ret_data) +{ + const char* pcie_slot = qdict_get_str(qdict, "pcie_slot"); + uint8_t chassis; + uint16_t slot; + PCIESlot *s; + + if (pcie_parse_slot_addr(pcie_slot, &chassis, &slot) < 0) { + monitor_printf(mon, "invalid pcie slot address %s\n", pcie_slot); + return -1; + } + s = pcie_chassis_find_slot(chassis, slot); + if (!s) { + monitor_printf(mon, "slot is not found. %s\n", pcie_slot); + return -1; + } + pcie_cap_slot_push_attention_button(&s->port.br.dev); + *ret_data = qobject_from_jsonf("{ 'chassis': %d, 'slot': %d}", + chassis, slot); + assert(*ret_data); + return 0; +} diff --git a/qemu-monitor.hx b/qemu-monitor.hx index 2af3de6..965c754 100644 --- a/qemu-monitor.hx +++ b/qemu-monitor.hx @@ -1154,6 +1154,20 @@ Hot remove PCI device. ETEXI { + .name = "pcie_push_attention_button", + .args_type = "pcie_slot:s", + .params = "[<chassis>.]<slot>", + .help = "push pci express attention button", + .user_print = pcie_attention_button_push_print, + .mhandler.cmd_new = pcie_attention_button_push, + }, + +STEXI +@item pcie_abp +Push PCI express attention button +ETEXI + + { .name = "host_net_add", .args_type = "device:s,opts:s?", .params = "tap|user|socket|vde|dump [options]", diff --git a/sysemu.h b/sysemu.h index 9c988bb..cca411d 100644 --- a/sysemu.h +++ b/sysemu.h @@ -150,6 +150,10 @@ extern unsigned int nb_prom_envs; void pci_device_hot_add(Monitor *mon, const QDict *qdict); void drive_hot_add(Monitor *mon, const QDict *qdict); void do_pci_device_hot_remove(Monitor *mon, const QDict *qdict); +/* pcie hotplug */ +void pcie_attention_button_push_print(Monitor *mon, const QObject *data); +int pcie_attention_button_push(Monitor *mon, const QDict *qdict, + QObject **ret_data); /* serial ports */
glue pcie_push_attention_button command. Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp> --- hw/pcie_port.c | 82 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ qemu-monitor.hx | 14 +++++++++ sysemu.h | 4 +++ 3 files changed, 100 insertions(+), 0 deletions(-)