Re: [Qemu-devel] [RFC] qmp: query-device-slots command

[Eduardo Habkost]

On Fri, Dec 16, 2016 at 11:37:00AM +0100, Markus Armbruster wrote:
> Eduardo Habkost  writes:
> 
> > On Wed, Dec 14, 2016 at 09:11:10PM +0100, Markus Armbruster wrote:
> >> Eduardo Habkost  writes:
> >> 
> >> > On Wed, Dec 14, 2016 at 04:34:04PM +0100, Markus Armbruster wrote:
> >> >> Eduardo Habkost  writes:
> >> >> 
> >> >> > On Tue, Dec 13, 2016 at 08:51:34PM +0100, Markus Armbruster wrote:
> >> >> >> Eduardo Habkost  writes:
> >> >> >> 
> >> >> >> > On Tue, Dec 13, 2016 at 12:04:17PM +0100, Markus Armbruster wrote:
> >> >> >> >> Quick interface review only:
> >> >> >> >> 
> >> >> >> >> Eduardo Habkost  writes:
> >> >> >> >> 
> >> >> >> >> > This adds a new command to QMP: query-device-slots. It will 
> >> >> >> >> > allow
> >> >> >> >> > management software to query possible slots where devices can be
> >> >> >> >> > plugged.
> >> >> >> >> >
> >> >> >> >> > This implementation of the command will return:
> >> >> >> >> >
> >> >> >> >> > * Multiple PCI slots per bus, in the case of PCI buses;
> >> >> >> >> > * One slot per bus in the case of the other buses;
> >> >> >> >> 
> >> >> >> >> Umm, that doesn't seem right.  For instance, a SCSI bus has 
> >> >> >> >> multiple
> >> >> >> >> slots.  The slot address is the SCSI ID.  An IDE bus may have one 
> >> >> >> >> (SATA)
> >> >> >> >> or two (PATA).  For more examples, see qdev-device-use.txt section
> >> >> >> >> "Specifying Bus and Address on Bus".
> >> >> >> >
> >> >> >> > Yes, I should have clarified that: this version changes only PCI
> >> >> >> > to expose multiple slots, but other buses also need be changed to
> >> >> >> > implement BusClass::enumerate_slots() properly, too.
> >> >> >> >
> >> >> >> >> 
> >> >> >> >> > * One slot for each entry from query-hotpluggable-cpus.
> >> >> >> >> > In the example below, I am not sure if the PCIe ports are all
> >> >> >> >> > supposed to report all slots, but I didn't find any existing
> >> >> >> >> > field in PCIBus that would help me figure out the actual number
> >> >> >> >> > of slots in a given PCI bus.
> >> >> >> >> >
> >> >> >> >> > Git tree
> >> >> >> >> > 
> >> >> >> >> >
> >> >> >> >> > This patch needs the previous query-machines series I am working
> >> >> >> >> > on. The full tree can be found on the git tree at:
> >> >> >> >> >
> >> >> >> >> >   git://github.com/ehabkost/qemu-hacks.git 
> >> >> >> >> > work/query-machines-bus-info
> >> >> >> >> >
> >> >> >> >> > Example output
> >> >> >> >> > --
> >> >> >> >> >
> >> >> >> >> > The following output was returned by QEMU when running it as:
> >> >> >> >> >
> >> >> >> >> >  $ qemu-system-x86_64 -machine q35 \
> >> >> >> >> >-readconfig docs/q35-chipset.cfg \
> >> >> >> >> >-smp 4,maxcpus=8,sockets=2,cores=2,threads=2
> >> >> >> >> >
> >> >> >> >> >  {
> >> >> >> >> > "return": [
> >> >> >> >> 
> >> >> >> >> Are you sure >3000 lines of example output make sense here?
> >> >> >> >
> >> >> >> > I'm not. :)
> >> >> >> >
> >> >> >> > That's why I need feedback from the PCI experts. I believe most
> >> >> >> > of the PCI ports on q35 accept only one device, but I see no code
> >> >> >> > implementing that restriction, and no obvious PCIBus or
> >> >> >> > PCIBusClass field indicating that.
> >> >> >> >
> >> >> >> >> 
> >> >> >> >> [...]
> >> >> >> >> > ]
> >> >> >> >> >   }
> >> >> >> >> >
> >> >> >> >> > Signed-off-by: Eduardo Habkost 
> >> >> >> >> > ---
> >> >> >> >> >  qapi-schema.json   | 114 
> >> >> >> >> > +
> >> >> >> >> >  include/hw/qdev-core.h |   6 +++
> >> >> >> >> >  hw/core/bus.c  |  49 +
> >> >> >> >> >  hw/pci/pci.c   | 106 
> >> >> >> >> > +
> >> >> >> >> >  qdev-monitor.c |  86 
> >> >> >> >> > ++---
> >> >> >> >> >  5 files changed, 328 insertions(+), 33 deletions(-)
> >> >> >> >> >
> >> >> >> >> > diff --git a/qapi-schema.json b/qapi-schema.json
> >> >> >> >> > index d48ff3f..484d91e 100644
> >> >> >> >> > --- a/qapi-schema.json
> >> >> >> >> > +++ b/qapi-schema.json
> >> >> >> >> > @@ -3166,6 +3166,120 @@
> >> >> >> >> >  { 'command': 'closefd', 'data': {'fdname': 'str'} }
> >> >> >> >> >  
> >> >> >> >> >  ##
> >> >> >> >> > +# @DeviceSlotType:
> >> >> >> >> > +#
> >> >> >> >> > +# Type of device slot
> >> >> >> >> > +#
> >> >> >> >> > +# @generic: Generic device slot, with no bus-specific 
> >> >> >> >> > information
> >> >> >> >> > +# @pci: PCI device slot
> >> >> >> >> > +# @cpu: CPU device slot
> >> >> >> >> > +##
> >> >> >> >> > +{ 'enum': 'DeviceSlotType',
> >> >> >> >> > +  'data': ['generic', 'pci', 'cpu'] }
> >> >> >> >> > +
> >> >> >> >> > +##
> >> >> >> >> > +# @DeviceSlotInfo:
> >> >> >> >> > +#
> >> >> >> >> > +# Information on a slot where devices can be plugged. Some 
> >> >> >> >> > buses

Re: [Qemu-devel] [RFC] qmp: query-device-slots command

[Markus Armbruster]

Eduardo Habkost  writes:

> On Wed, Dec 14, 2016 at 09:11:10PM +0100, Markus Armbruster wrote:
>> Eduardo Habkost  writes:
>> 
>> > On Wed, Dec 14, 2016 at 04:34:04PM +0100, Markus Armbruster wrote:
>> >> Eduardo Habkost  writes:
>> >> 
>> >> > On Tue, Dec 13, 2016 at 08:51:34PM +0100, Markus Armbruster wrote:
>> >> >> Eduardo Habkost  writes:
>> >> >> 
>> >> >> > On Tue, Dec 13, 2016 at 12:04:17PM +0100, Markus Armbruster wrote:
>> >> >> >> Quick interface review only:
>> >> >> >> 
>> >> >> >> Eduardo Habkost  writes:
>> >> >> >> 
>> >> >> >> > This adds a new command to QMP: query-device-slots. It will allow
>> >> >> >> > management software to query possible slots where devices can be
>> >> >> >> > plugged.
>> >> >> >> >
>> >> >> >> > This implementation of the command will return:
>> >> >> >> >
>> >> >> >> > * Multiple PCI slots per bus, in the case of PCI buses;
>> >> >> >> > * One slot per bus in the case of the other buses;
>> >> >> >> 
>> >> >> >> Umm, that doesn't seem right.  For instance, a SCSI bus has multiple
>> >> >> >> slots.  The slot address is the SCSI ID.  An IDE bus may have one 
>> >> >> >> (SATA)
>> >> >> >> or two (PATA).  For more examples, see qdev-device-use.txt section
>> >> >> >> "Specifying Bus and Address on Bus".
>> >> >> >
>> >> >> > Yes, I should have clarified that: this version changes only PCI
>> >> >> > to expose multiple slots, but other buses also need be changed to
>> >> >> > implement BusClass::enumerate_slots() properly, too.
>> >> >> >
>> >> >> >> 
>> >> >> >> > * One slot for each entry from query-hotpluggable-cpus.
>> >> >> >> > In the example below, I am not sure if the PCIe ports are all
>> >> >> >> > supposed to report all slots, but I didn't find any existing
>> >> >> >> > field in PCIBus that would help me figure out the actual number
>> >> >> >> > of slots in a given PCI bus.
>> >> >> >> >
>> >> >> >> > Git tree
>> >> >> >> > 
>> >> >> >> >
>> >> >> >> > This patch needs the previous query-machines series I am working
>> >> >> >> > on. The full tree can be found on the git tree at:
>> >> >> >> >
>> >> >> >> >   git://github.com/ehabkost/qemu-hacks.git 
>> >> >> >> > work/query-machines-bus-info
>> >> >> >> >
>> >> >> >> > Example output
>> >> >> >> > --
>> >> >> >> >
>> >> >> >> > The following output was returned by QEMU when running it as:
>> >> >> >> >
>> >> >> >> >  $ qemu-system-x86_64 -machine q35 \
>> >> >> >> >-readconfig docs/q35-chipset.cfg \
>> >> >> >> >-smp 4,maxcpus=8,sockets=2,cores=2,threads=2
>> >> >> >> >
>> >> >> >> >  {
>> >> >> >> > "return": [
>> >> >> >> 
>> >> >> >> Are you sure >3000 lines of example output make sense here?
>> >> >> >
>> >> >> > I'm not. :)
>> >> >> >
>> >> >> > That's why I need feedback from the PCI experts. I believe most
>> >> >> > of the PCI ports on q35 accept only one device, but I see no code
>> >> >> > implementing that restriction, and no obvious PCIBus or
>> >> >> > PCIBusClass field indicating that.
>> >> >> >
>> >> >> >> 
>> >> >> >> [...]
>> >> >> >> > ]
>> >> >> >> >   }
>> >> >> >> >
>> >> >> >> > Signed-off-by: Eduardo Habkost 
>> >> >> >> > ---
>> >> >> >> >  qapi-schema.json   | 114 
>> >> >> >> > +
>> >> >> >> >  include/hw/qdev-core.h |   6 +++
>> >> >> >> >  hw/core/bus.c  |  49 +
>> >> >> >> >  hw/pci/pci.c   | 106 
>> >> >> >> > +
>> >> >> >> >  qdev-monitor.c |  86 
>> >> >> >> > ++---
>> >> >> >> >  5 files changed, 328 insertions(+), 33 deletions(-)
>> >> >> >> >
>> >> >> >> > diff --git a/qapi-schema.json b/qapi-schema.json
>> >> >> >> > index d48ff3f..484d91e 100644
>> >> >> >> > --- a/qapi-schema.json
>> >> >> >> > +++ b/qapi-schema.json
>> >> >> >> > @@ -3166,6 +3166,120 @@
>> >> >> >> >  { 'command': 'closefd', 'data': {'fdname': 'str'} }
>> >> >> >> >  
>> >> >> >> >  ##
>> >> >> >> > +# @DeviceSlotType:
>> >> >> >> > +#
>> >> >> >> > +# Type of device slot
>> >> >> >> > +#
>> >> >> >> > +# @generic: Generic device slot, with no bus-specific information
>> >> >> >> > +# @pci: PCI device slot
>> >> >> >> > +# @cpu: CPU device slot
>> >> >> >> > +##
>> >> >> >> > +{ 'enum': 'DeviceSlotType',
>> >> >> >> > +  'data': ['generic', 'pci', 'cpu'] }
>> >> >> >> > +
>> >> >> >> > +##
>> >> >> >> > +# @DeviceSlotInfo:
>> >> >> >> > +#
>> >> >> >> > +# Information on a slot where devices can be plugged. Some buses
>> >> >> >> > +# are represented as a single slot that can support multiple 
>> >> >> >> > devices,
>> >> >> >> > +# and some buses have multiple slots that are identified by 
>> >> >> >> > arguments
>> >> >> >> > +# to @device_add.
>> >> >> >> 
>> >> >> >> Okay, let me try to wrap my poor, ignorant mind around this.
>> >> >> >> 
>> >> >> >> There are 

Re: [Qemu-devel] [RFC] qmp: query-device-slots command

[Markus Armbruster]

Laine Stump  writes:

> On 12/15/2016 05:12 AM, Marcel Apfelbaum wrote:
>> On 12/14/2016 10:10 PM, Laine Stump wrote:
>>> On 12/14/2016 12:17 PM, Marcel Apfelbaum wrote:
 Be aware that 1 slot doesn't necessarily refer to only one device,
 we can have a multi-function device.
>>>
>>> Is that a fixed thing? I mean, is it always possible to use all 8
>>> functions of a slot (assuming no hotplug of course)?
>>>
>>
>> Yes, you simply add to the function 0 on command line:  with -device
>> ...,multifunction=on.
>
> Yes, I know how the commandline works. my question is whether *all*
> PCI controllers in existence have 8 usable functions per slot, or if
> that might be another thing that is different from one controller to
> the next (and thus would have to be reported in these query
> responses).

Quote from PCI Express Base Specification Revision 3.0: "Each non-ARI
Device may contain up to eight Functions.  Each ARI Device may contain
up to 256 Functions."

The address format is defined by the PCI spec: bus number is 8 bits,
device number is 5, function number is 3.

However, a device may be an ARI device (ARI = Alternative Routing-ID
Interpretation), and then the device number bits are instead used for a
wider function number.  As far as I know, this is PCIe-only.  See PCI
Express Base Specification Revision 3.0, 6.13. Alternative Routing-ID
Interpretation (ARI).

Re: [Qemu-devel] [RFC] qmp: query-device-slots command

[Eduardo Habkost]

On Thu, Dec 15, 2016 at 02:15:51PM -0500, Laine Stump wrote:
> On 12/15/2016 05:12 AM, Marcel Apfelbaum wrote:
> > On 12/14/2016 10:10 PM, Laine Stump wrote:
> > > On 12/14/2016 12:17 PM, Marcel Apfelbaum wrote:
> > > > Be aware that 1 slot doesn't necessarily refer to only one device,
> > > > we can have a multi-function device.
> > > 
> > > Is that a fixed thing? I mean, is it always possible to use all 8
> > > functions of a slot (assuming no hotplug of course)?
> > > 
> > 
> > Yes, you simply add to the function 0 on command line:  with -device
> > ...,multifunction=on.
> 
> Yes, I know how the commandline works. my question is whether *all* PCI
> controllers in existence have 8 usable functions per slot, or if that might
> be another thing that is different from one controller to the next (and thus
> would have to be reported in these query responses).

That's a good question. From looking at the code, I was assuming
the 8 functions were always available. But if they might be not,
that's another reason to explicitly report PCI functions in the
new queries.

-- 
Eduardo

Re: [Qemu-devel] [RFC] qmp: query-device-slots command

[Laine Stump]

On 12/15/2016 05:12 AM, Marcel Apfelbaum wrote:

On 12/14/2016 10:10 PM, Laine Stump wrote:

On 12/14/2016 12:17 PM, Marcel Apfelbaum wrote:

Be aware that 1 slot doesn't necessarily refer to only one device,
we can have a multi-function device.


Is that a fixed thing? I mean, is it always possible to use all 8
functions of a slot (assuming no hotplug of course)?



Yes, you simply add to the function 0 on command line:  with -device
...,multifunction=on.


Yes, I know how the commandline works. my question is whether *all* PCI 
controllers in existence have 8 usable functions per slot, or if that 
might be another thing that is different from one controller to the next 
(and thus would have to be reported in these query responses).

Re: [Qemu-devel] [RFC] qmp: query-device-slots command

[Eduardo Habkost]

On Wed, Dec 14, 2016 at 09:11:10PM +0100, Markus Armbruster wrote:
> Eduardo Habkost  writes:
> 
> > On Wed, Dec 14, 2016 at 04:34:04PM +0100, Markus Armbruster wrote:
> >> Eduardo Habkost  writes:
> >> 
> >> > On Tue, Dec 13, 2016 at 08:51:34PM +0100, Markus Armbruster wrote:
> >> >> Eduardo Habkost  writes:
> >> >> 
> >> >> > On Tue, Dec 13, 2016 at 12:04:17PM +0100, Markus Armbruster wrote:
> >> >> >> Quick interface review only:
> >> >> >> 
> >> >> >> Eduardo Habkost  writes:
> >> >> >> 
> >> >> >> > This adds a new command to QMP: query-device-slots. It will allow
> >> >> >> > management software to query possible slots where devices can be
> >> >> >> > plugged.
> >> >> >> >
> >> >> >> > This implementation of the command will return:
> >> >> >> >
> >> >> >> > * Multiple PCI slots per bus, in the case of PCI buses;
> >> >> >> > * One slot per bus in the case of the other buses;
> >> >> >> 
> >> >> >> Umm, that doesn't seem right.  For instance, a SCSI bus has multiple
> >> >> >> slots.  The slot address is the SCSI ID.  An IDE bus may have one 
> >> >> >> (SATA)
> >> >> >> or two (PATA).  For more examples, see qdev-device-use.txt section
> >> >> >> "Specifying Bus and Address on Bus".
> >> >> >
> >> >> > Yes, I should have clarified that: this version changes only PCI
> >> >> > to expose multiple slots, but other buses also need be changed to
> >> >> > implement BusClass::enumerate_slots() properly, too.
> >> >> >
> >> >> >> 
> >> >> >> > * One slot for each entry from query-hotpluggable-cpus.
> >> >> >> > In the example below, I am not sure if the PCIe ports are all
> >> >> >> > supposed to report all slots, but I didn't find any existing
> >> >> >> > field in PCIBus that would help me figure out the actual number
> >> >> >> > of slots in a given PCI bus.
> >> >> >> >
> >> >> >> > Git tree
> >> >> >> > 
> >> >> >> >
> >> >> >> > This patch needs the previous query-machines series I am working
> >> >> >> > on. The full tree can be found on the git tree at:
> >> >> >> >
> >> >> >> >   git://github.com/ehabkost/qemu-hacks.git 
> >> >> >> > work/query-machines-bus-info
> >> >> >> >
> >> >> >> > Example output
> >> >> >> > --
> >> >> >> >
> >> >> >> > The following output was returned by QEMU when running it as:
> >> >> >> >
> >> >> >> >  $ qemu-system-x86_64 -machine q35 \
> >> >> >> >-readconfig docs/q35-chipset.cfg \
> >> >> >> >-smp 4,maxcpus=8,sockets=2,cores=2,threads=2
> >> >> >> >
> >> >> >> >  {
> >> >> >> > "return": [
> >> >> >> 
> >> >> >> Are you sure >3000 lines of example output make sense here?
> >> >> >
> >> >> > I'm not. :)
> >> >> >
> >> >> > That's why I need feedback from the PCI experts. I believe most
> >> >> > of the PCI ports on q35 accept only one device, but I see no code
> >> >> > implementing that restriction, and no obvious PCIBus or
> >> >> > PCIBusClass field indicating that.
> >> >> >
> >> >> >> 
> >> >> >> [...]
> >> >> >> > ]
> >> >> >> >   }
> >> >> >> >
> >> >> >> > Signed-off-by: Eduardo Habkost 
> >> >> >> > ---
> >> >> >> >  qapi-schema.json   | 114 
> >> >> >> > +
> >> >> >> >  include/hw/qdev-core.h |   6 +++
> >> >> >> >  hw/core/bus.c  |  49 +
> >> >> >> >  hw/pci/pci.c   | 106 
> >> >> >> > +
> >> >> >> >  qdev-monitor.c |  86 ++---
> >> >> >> >  5 files changed, 328 insertions(+), 33 deletions(-)
> >> >> >> >
> >> >> >> > diff --git a/qapi-schema.json b/qapi-schema.json
> >> >> >> > index d48ff3f..484d91e 100644
> >> >> >> > --- a/qapi-schema.json
> >> >> >> > +++ b/qapi-schema.json
> >> >> >> > @@ -3166,6 +3166,120 @@
> >> >> >> >  { 'command': 'closefd', 'data': {'fdname': 'str'} }
> >> >> >> >  
> >> >> >> >  ##
> >> >> >> > +# @DeviceSlotType:
> >> >> >> > +#
> >> >> >> > +# Type of device slot
> >> >> >> > +#
> >> >> >> > +# @generic: Generic device slot, with no bus-specific information
> >> >> >> > +# @pci: PCI device slot
> >> >> >> > +# @cpu: CPU device slot
> >> >> >> > +##
> >> >> >> > +{ 'enum': 'DeviceSlotType',
> >> >> >> > +  'data': ['generic', 'pci', 'cpu'] }
> >> >> >> > +
> >> >> >> > +##
> >> >> >> > +# @DeviceSlotInfo:
> >> >> >> > +#
> >> >> >> > +# Information on a slot where devices can be plugged. Some buses
> >> >> >> > +# are represented as a single slot that can support multiple 
> >> >> >> > devices,
> >> >> >> > +# and some buses have multiple slots that are identified by 
> >> >> >> > arguments
> >> >> >> > +# to @device_add.
> >> >> >> 
> >> >> >> Okay, let me try to wrap my poor, ignorant mind around this.
> >> >> >> 
> >> >> >> There are two kinds of buses: "single slot that can support multiple
> >> >> >> devices", and "multiple slots that are identified by arguments".
> >> >> >> 
> >> >> >> How are the two kinds 

Re: [Qemu-devel] [RFC] qmp: query-device-slots command

[Marcel Apfelbaum]

On 12/14/2016 10:10 PM, Laine Stump wrote:

On 12/14/2016 12:17 PM, Marcel Apfelbaum wrote:

On 12/13/2016 06:00 PM, Eduardo Habkost wrote:

On Tue, Dec 13, 2016 at 04:15:18PM +0200, Marcel Apfelbaum wrote:

On 12/13/2016 02:42 PM, Eduardo Habkost wrote:

On Tue, Dec 13, 2016 at 12:04:17PM +0100, Markus Armbruster wrote:

Quick interface review only:

Eduardo Habkost  writes:


This adds a new command to QMP: query-device-slots. It will allow
management software to query possible slots where devices can be
plugged.

This implementation of the command will return:

* Multiple PCI slots per bus, in the case of PCI buses;
* One slot per bus in the case of the other buses;


Umm, that doesn't seem right.  For instance, a SCSI bus has multiple
slots.  The slot address is the SCSI ID.  An IDE bus may have one
(SATA)
or two (PATA).  For more examples, see qdev-device-use.txt section
"Specifying Bus and Address on Bus".


Yes, I should have clarified that: this version changes only PCI
to expose multiple slots, but other buses also need be changed to
implement BusClass::enumerate_slots() properly, too.




* One slot for each entry from query-hotpluggable-cpus.
In the example below, I am not sure if the PCIe ports are all
supposed to report all slots, but I didn't find any existing
field in PCIBus that would help me figure out the actual number
of slots in a given PCI bus.

Git tree


This patch needs the previous query-machines series I am working
on. The full tree can be found on the git tree at:

  git://github.com/ehabkost/qemu-hacks.git
work/query-machines-bus-info

Example output
--

The following output was returned by QEMU when running it as:

 $ qemu-system-x86_64 -machine q35 \
   -readconfig docs/q35-chipset.cfg \
   -smp 4,maxcpus=8,sockets=2,cores=2,threads=2

 {
"return": [


Are you sure >3000 lines of example output make sense here?


I'm not. :)

That's why I need feedback from the PCI experts. I believe most
of the PCI ports on q35 accept only one device,


I don't think of it as "one device" but as "only slot 0 can be used" (since, as 
Marcel pointed out, a different device can be placed on each of the 8 functions of that slot).


but I see no code

implementing that restriction, and no obvious PCIBus or
PCIBusClass field indicating that.


Hi,

Sadly there is no such restriction today as far as I know.
We trust the user that he knows what he is doing :)
and we let libvirt implement the restriction.

I do agree we should fix that.


OK, this matches what I saw on the current code.

But I would like to understand what exactly should be the rules
if we fix that. Should we report only 1 slot if
pci_bus_has_pcie_upstream_port(bus)?



We should report 1 slot for a bus exposed by a PCIe Root Port
or PCIe Downstream Port.

Be aware that 1 slot doesn't necessarily refer to only one device,
we can have a multi-function device.




Hi Laine,


Is that a fixed thing? I mean, is it always possible to use all 8 functions of 
a slot (assuming no hotplug of course)?



Yes, you simply add to the function 0 on command line:  with -device 
...,multifunction=on.

Thanks,
Marcel




Thanks,
Marcel


(Note that pci_bus_has_pcie_upstream_port() doesn't exist in the
current code, it is added by my patch)

Re: [Qemu-devel] [RFC] qmp: query-device-slots command

[Markus Armbruster]

Eduardo Habkost  writes:

> On Wed, Dec 14, 2016 at 04:34:04PM +0100, Markus Armbruster wrote:
>> Eduardo Habkost  writes:
>> 
>> > On Tue, Dec 13, 2016 at 08:51:34PM +0100, Markus Armbruster wrote:
>> >> Eduardo Habkost  writes:
>> >> 
>> >> > On Tue, Dec 13, 2016 at 12:04:17PM +0100, Markus Armbruster wrote:
>> >> >> Quick interface review only:
>> >> >> 
>> >> >> Eduardo Habkost  writes:
>> >> >> 
>> >> >> > This adds a new command to QMP: query-device-slots. It will allow
>> >> >> > management software to query possible slots where devices can be
>> >> >> > plugged.
>> >> >> >
>> >> >> > This implementation of the command will return:
>> >> >> >
>> >> >> > * Multiple PCI slots per bus, in the case of PCI buses;
>> >> >> > * One slot per bus in the case of the other buses;
>> >> >> 
>> >> >> Umm, that doesn't seem right.  For instance, a SCSI bus has multiple
>> >> >> slots.  The slot address is the SCSI ID.  An IDE bus may have one 
>> >> >> (SATA)
>> >> >> or two (PATA).  For more examples, see qdev-device-use.txt section
>> >> >> "Specifying Bus and Address on Bus".
>> >> >
>> >> > Yes, I should have clarified that: this version changes only PCI
>> >> > to expose multiple slots, but other buses also need be changed to
>> >> > implement BusClass::enumerate_slots() properly, too.
>> >> >
>> >> >> 
>> >> >> > * One slot for each entry from query-hotpluggable-cpus.
>> >> >> > In the example below, I am not sure if the PCIe ports are all
>> >> >> > supposed to report all slots, but I didn't find any existing
>> >> >> > field in PCIBus that would help me figure out the actual number
>> >> >> > of slots in a given PCI bus.
>> >> >> >
>> >> >> > Git tree
>> >> >> > 
>> >> >> >
>> >> >> > This patch needs the previous query-machines series I am working
>> >> >> > on. The full tree can be found on the git tree at:
>> >> >> >
>> >> >> >   git://github.com/ehabkost/qemu-hacks.git 
>> >> >> > work/query-machines-bus-info
>> >> >> >
>> >> >> > Example output
>> >> >> > --
>> >> >> >
>> >> >> > The following output was returned by QEMU when running it as:
>> >> >> >
>> >> >> >  $ qemu-system-x86_64 -machine q35 \
>> >> >> >-readconfig docs/q35-chipset.cfg \
>> >> >> >-smp 4,maxcpus=8,sockets=2,cores=2,threads=2
>> >> >> >
>> >> >> >  {
>> >> >> > "return": [
>> >> >> 
>> >> >> Are you sure >3000 lines of example output make sense here?
>> >> >
>> >> > I'm not. :)
>> >> >
>> >> > That's why I need feedback from the PCI experts. I believe most
>> >> > of the PCI ports on q35 accept only one device, but I see no code
>> >> > implementing that restriction, and no obvious PCIBus or
>> >> > PCIBusClass field indicating that.
>> >> >
>> >> >> 
>> >> >> [...]
>> >> >> > ]
>> >> >> >   }
>> >> >> >
>> >> >> > Signed-off-by: Eduardo Habkost 
>> >> >> > ---
>> >> >> >  qapi-schema.json   | 114 
>> >> >> > +
>> >> >> >  include/hw/qdev-core.h |   6 +++
>> >> >> >  hw/core/bus.c  |  49 +
>> >> >> >  hw/pci/pci.c   | 106 
>> >> >> > +
>> >> >> >  qdev-monitor.c |  86 ++---
>> >> >> >  5 files changed, 328 insertions(+), 33 deletions(-)
>> >> >> >
>> >> >> > diff --git a/qapi-schema.json b/qapi-schema.json
>> >> >> > index d48ff3f..484d91e 100644
>> >> >> > --- a/qapi-schema.json
>> >> >> > +++ b/qapi-schema.json
>> >> >> > @@ -3166,6 +3166,120 @@
>> >> >> >  { 'command': 'closefd', 'data': {'fdname': 'str'} }
>> >> >> >  
>> >> >> >  ##
>> >> >> > +# @DeviceSlotType:
>> >> >> > +#
>> >> >> > +# Type of device slot
>> >> >> > +#
>> >> >> > +# @generic: Generic device slot, with no bus-specific information
>> >> >> > +# @pci: PCI device slot
>> >> >> > +# @cpu: CPU device slot
>> >> >> > +##
>> >> >> > +{ 'enum': 'DeviceSlotType',
>> >> >> > +  'data': ['generic', 'pci', 'cpu'] }
>> >> >> > +
>> >> >> > +##
>> >> >> > +# @DeviceSlotInfo:
>> >> >> > +#
>> >> >> > +# Information on a slot where devices can be plugged. Some buses
>> >> >> > +# are represented as a single slot that can support multiple 
>> >> >> > devices,
>> >> >> > +# and some buses have multiple slots that are identified by 
>> >> >> > arguments
>> >> >> > +# to @device_add.
>> >> >> 
>> >> >> Okay, let me try to wrap my poor, ignorant mind around this.
>> >> >> 
>> >> >> There are two kinds of buses: "single slot that can support multiple
>> >> >> devices", and "multiple slots that are identified by arguments".
>> >> >> 
>> >> >> How are the two kinds related to @type?
>> >> >
>> >> > They are related to @type indirectly because different bus types
>> >> > will return different data. But I don't want to make this part of
>> >> > the specification: clients should be prepared to handle both
>> >> > cases.
>> >> 
>> >> Well, color me confused :)
>> >> 
>> >> 

Re: [Qemu-devel] [RFC] qmp: query-device-slots command

[Laine Stump]

On 12/14/2016 12:17 PM, Marcel Apfelbaum wrote:

On 12/13/2016 06:00 PM, Eduardo Habkost wrote:

On Tue, Dec 13, 2016 at 04:15:18PM +0200, Marcel Apfelbaum wrote:

On 12/13/2016 02:42 PM, Eduardo Habkost wrote:

On Tue, Dec 13, 2016 at 12:04:17PM +0100, Markus Armbruster wrote:

Quick interface review only:

Eduardo Habkost  writes:


This adds a new command to QMP: query-device-slots. It will allow
management software to query possible slots where devices can be
plugged.

This implementation of the command will return:

* Multiple PCI slots per bus, in the case of PCI buses;
* One slot per bus in the case of the other buses;


Umm, that doesn't seem right.  For instance, a SCSI bus has multiple
slots.  The slot address is the SCSI ID.  An IDE bus may have one
(SATA)
or two (PATA).  For more examples, see qdev-device-use.txt section
"Specifying Bus and Address on Bus".


Yes, I should have clarified that: this version changes only PCI
to expose multiple slots, but other buses also need be changed to
implement BusClass::enumerate_slots() properly, too.




* One slot for each entry from query-hotpluggable-cpus.
In the example below, I am not sure if the PCIe ports are all
supposed to report all slots, but I didn't find any existing
field in PCIBus that would help me figure out the actual number
of slots in a given PCI bus.

Git tree


This patch needs the previous query-machines series I am working
on. The full tree can be found on the git tree at:

  git://github.com/ehabkost/qemu-hacks.git
work/query-machines-bus-info

Example output
--

The following output was returned by QEMU when running it as:

 $ qemu-system-x86_64 -machine q35 \
   -readconfig docs/q35-chipset.cfg \
   -smp 4,maxcpus=8,sockets=2,cores=2,threads=2

 {
"return": [


Are you sure >3000 lines of example output make sense here?


I'm not. :)

That's why I need feedback from the PCI experts. I believe most
of the PCI ports on q35 accept only one device,


I don't think of it as "one device" but as "only slot 0 can be used" 
(since, as Marcel pointed out, a different device can be placed on each 
of the 8 functions of that slot).



but I see no code

implementing that restriction, and no obvious PCIBus or
PCIBusClass field indicating that.


Hi,

Sadly there is no such restriction today as far as I know.
We trust the user that he knows what he is doing :)
and we let libvirt implement the restriction.

I do agree we should fix that.


OK, this matches what I saw on the current code.

But I would like to understand what exactly should be the rules
if we fix that. Should we report only 1 slot if
pci_bus_has_pcie_upstream_port(bus)?



We should report 1 slot for a bus exposed by a PCIe Root Port
or PCIe Downstream Port.

Be aware that 1 slot doesn't necessarily refer to only one device,
we can have a multi-function device.


Is that a fixed thing? I mean, is it always possible to use all 8 
functions of a slot (assuming no hotplug of course)?




Thanks,
Marcel


(Note that pci_bus_has_pcie_upstream_port() doesn't exist in the
current code, it is added by my patch)

Re: [Qemu-devel] [RFC] qmp: query-device-slots command

[Marcel Apfelbaum]

On 12/13/2016 06:00 PM, Eduardo Habkost wrote:

On Tue, Dec 13, 2016 at 04:15:18PM +0200, Marcel Apfelbaum wrote:

On 12/13/2016 02:42 PM, Eduardo Habkost wrote:

On Tue, Dec 13, 2016 at 12:04:17PM +0100, Markus Armbruster wrote:

Quick interface review only:

Eduardo Habkost  writes:


This adds a new command to QMP: query-device-slots. It will allow
management software to query possible slots where devices can be
plugged.

This implementation of the command will return:

* Multiple PCI slots per bus, in the case of PCI buses;
* One slot per bus in the case of the other buses;


Umm, that doesn't seem right.  For instance, a SCSI bus has multiple
slots.  The slot address is the SCSI ID.  An IDE bus may have one (SATA)
or two (PATA).  For more examples, see qdev-device-use.txt section
"Specifying Bus and Address on Bus".


Yes, I should have clarified that: this version changes only PCI
to expose multiple slots, but other buses also need be changed to
implement BusClass::enumerate_slots() properly, too.




* One slot for each entry from query-hotpluggable-cpus.
In the example below, I am not sure if the PCIe ports are all
supposed to report all slots, but I didn't find any existing
field in PCIBus that would help me figure out the actual number
of slots in a given PCI bus.

Git tree


This patch needs the previous query-machines series I am working
on. The full tree can be found on the git tree at:

  git://github.com/ehabkost/qemu-hacks.git work/query-machines-bus-info

Example output
--

The following output was returned by QEMU when running it as:

 $ qemu-system-x86_64 -machine q35 \
   -readconfig docs/q35-chipset.cfg \
   -smp 4,maxcpus=8,sockets=2,cores=2,threads=2

 {
"return": [


Are you sure >3000 lines of example output make sense here?


I'm not. :)

That's why I need feedback from the PCI experts. I believe most
of the PCI ports on q35 accept only one device, but I see no code
implementing that restriction, and no obvious PCIBus or
PCIBusClass field indicating that.


Hi,

Sadly there is no such restriction today as far as I know.
We trust the user that he knows what he is doing :)
and we let libvirt implement the restriction.

I do agree we should fix that.


OK, this matches what I saw on the current code.

But I would like to understand what exactly should be the rules
if we fix that. Should we report only 1 slot if
pci_bus_has_pcie_upstream_port(bus)?



We should report 1 slot for a bus exposed by a PCIe Root Port
or PCIe Downstream Port.

Be aware that 1 slot doesn't necessarily refer to only one device,
we can have a multi-function device.

Thanks,
Marcel


(Note that pci_bus_has_pcie_upstream_port() doesn't exist in the
current code, it is added by my patch)

Re: [Qemu-devel] [RFC] qmp: query-device-slots command

[Eduardo Habkost]

On Wed, Dec 14, 2016 at 04:34:04PM +0100, Markus Armbruster wrote:
> Eduardo Habkost  writes:
> 
> > On Tue, Dec 13, 2016 at 08:51:34PM +0100, Markus Armbruster wrote:
> >> Eduardo Habkost  writes:
> >> 
> >> > On Tue, Dec 13, 2016 at 12:04:17PM +0100, Markus Armbruster wrote:
> >> >> Quick interface review only:
> >> >> 
> >> >> Eduardo Habkost  writes:
> >> >> 
> >> >> > This adds a new command to QMP: query-device-slots. It will allow
> >> >> > management software to query possible slots where devices can be
> >> >> > plugged.
> >> >> >
> >> >> > This implementation of the command will return:
> >> >> >
> >> >> > * Multiple PCI slots per bus, in the case of PCI buses;
> >> >> > * One slot per bus in the case of the other buses;
> >> >> 
> >> >> Umm, that doesn't seem right.  For instance, a SCSI bus has multiple
> >> >> slots.  The slot address is the SCSI ID.  An IDE bus may have one (SATA)
> >> >> or two (PATA).  For more examples, see qdev-device-use.txt section
> >> >> "Specifying Bus and Address on Bus".
> >> >
> >> > Yes, I should have clarified that: this version changes only PCI
> >> > to expose multiple slots, but other buses also need be changed to
> >> > implement BusClass::enumerate_slots() properly, too.
> >> >
> >> >> 
> >> >> > * One slot for each entry from query-hotpluggable-cpus.
> >> >> > In the example below, I am not sure if the PCIe ports are all
> >> >> > supposed to report all slots, but I didn't find any existing
> >> >> > field in PCIBus that would help me figure out the actual number
> >> >> > of slots in a given PCI bus.
> >> >> >
> >> >> > Git tree
> >> >> > 
> >> >> >
> >> >> > This patch needs the previous query-machines series I am working
> >> >> > on. The full tree can be found on the git tree at:
> >> >> >
> >> >> >   git://github.com/ehabkost/qemu-hacks.git 
> >> >> > work/query-machines-bus-info
> >> >> >
> >> >> > Example output
> >> >> > --
> >> >> >
> >> >> > The following output was returned by QEMU when running it as:
> >> >> >
> >> >> >  $ qemu-system-x86_64 -machine q35 \
> >> >> >-readconfig docs/q35-chipset.cfg \
> >> >> >-smp 4,maxcpus=8,sockets=2,cores=2,threads=2
> >> >> >
> >> >> >  {
> >> >> > "return": [
> >> >> 
> >> >> Are you sure >3000 lines of example output make sense here?
> >> >
> >> > I'm not. :)
> >> >
> >> > That's why I need feedback from the PCI experts. I believe most
> >> > of the PCI ports on q35 accept only one device, but I see no code
> >> > implementing that restriction, and no obvious PCIBus or
> >> > PCIBusClass field indicating that.
> >> >
> >> >> 
> >> >> [...]
> >> >> > ]
> >> >> >   }
> >> >> >
> >> >> > Signed-off-by: Eduardo Habkost 
> >> >> > ---
> >> >> >  qapi-schema.json   | 114 
> >> >> > +
> >> >> >  include/hw/qdev-core.h |   6 +++
> >> >> >  hw/core/bus.c  |  49 +
> >> >> >  hw/pci/pci.c   | 106 
> >> >> > +
> >> >> >  qdev-monitor.c |  86 ++---
> >> >> >  5 files changed, 328 insertions(+), 33 deletions(-)
> >> >> >
> >> >> > diff --git a/qapi-schema.json b/qapi-schema.json
> >> >> > index d48ff3f..484d91e 100644
> >> >> > --- a/qapi-schema.json
> >> >> > +++ b/qapi-schema.json
> >> >> > @@ -3166,6 +3166,120 @@
> >> >> >  { 'command': 'closefd', 'data': {'fdname': 'str'} }
> >> >> >  
> >> >> >  ##
> >> >> > +# @DeviceSlotType:
> >> >> > +#
> >> >> > +# Type of device slot
> >> >> > +#
> >> >> > +# @generic: Generic device slot, with no bus-specific information
> >> >> > +# @pci: PCI device slot
> >> >> > +# @cpu: CPU device slot
> >> >> > +##
> >> >> > +{ 'enum': 'DeviceSlotType',
> >> >> > +  'data': ['generic', 'pci', 'cpu'] }
> >> >> > +
> >> >> > +##
> >> >> > +# @DeviceSlotInfo:
> >> >> > +#
> >> >> > +# Information on a slot where devices can be plugged. Some buses
> >> >> > +# are represented as a single slot that can support multiple devices,
> >> >> > +# and some buses have multiple slots that are identified by arguments
> >> >> > +# to @device_add.
> >> >> 
> >> >> Okay, let me try to wrap my poor, ignorant mind around this.
> >> >> 
> >> >> There are two kinds of buses: "single slot that can support multiple
> >> >> devices", and "multiple slots that are identified by arguments".
> >> >> 
> >> >> How are the two kinds related to @type?
> >> >
> >> > They are related to @type indirectly because different bus types
> >> > will return different data. But I don't want to make this part of
> >> > the specification: clients should be prepared to handle both
> >> > cases.
> >> 
> >> Well, color me confused :)
> >> 
> >> > e.g. a QEMU version might return a single generic catch-all
> >> > sysbus-device slot that support any number of devices. Future
> >> > versions may return more detailed information, and return slots
> >> 

Re: [Qemu-devel] [RFC] qmp: query-device-slots command

[Markus Armbruster]

Eduardo Habkost  writes:

> On Tue, Dec 13, 2016 at 08:51:34PM +0100, Markus Armbruster wrote:
>> Eduardo Habkost  writes:
>> 
>> > On Tue, Dec 13, 2016 at 12:04:17PM +0100, Markus Armbruster wrote:
>> >> Quick interface review only:
>> >> 
>> >> Eduardo Habkost  writes:
>> >> 
>> >> > This adds a new command to QMP: query-device-slots. It will allow
>> >> > management software to query possible slots where devices can be
>> >> > plugged.
>> >> >
>> >> > This implementation of the command will return:
>> >> >
>> >> > * Multiple PCI slots per bus, in the case of PCI buses;
>> >> > * One slot per bus in the case of the other buses;
>> >> 
>> >> Umm, that doesn't seem right.  For instance, a SCSI bus has multiple
>> >> slots.  The slot address is the SCSI ID.  An IDE bus may have one (SATA)
>> >> or two (PATA).  For more examples, see qdev-device-use.txt section
>> >> "Specifying Bus and Address on Bus".
>> >
>> > Yes, I should have clarified that: this version changes only PCI
>> > to expose multiple slots, but other buses also need be changed to
>> > implement BusClass::enumerate_slots() properly, too.
>> >
>> >> 
>> >> > * One slot for each entry from query-hotpluggable-cpus.
>> >> > In the example below, I am not sure if the PCIe ports are all
>> >> > supposed to report all slots, but I didn't find any existing
>> >> > field in PCIBus that would help me figure out the actual number
>> >> > of slots in a given PCI bus.
>> >> >
>> >> > Git tree
>> >> > 
>> >> >
>> >> > This patch needs the previous query-machines series I am working
>> >> > on. The full tree can be found on the git tree at:
>> >> >
>> >> >   git://github.com/ehabkost/qemu-hacks.git work/query-machines-bus-info
>> >> >
>> >> > Example output
>> >> > --
>> >> >
>> >> > The following output was returned by QEMU when running it as:
>> >> >
>> >> >  $ qemu-system-x86_64 -machine q35 \
>> >> >-readconfig docs/q35-chipset.cfg \
>> >> >-smp 4,maxcpus=8,sockets=2,cores=2,threads=2
>> >> >
>> >> >  {
>> >> > "return": [
>> >> 
>> >> Are you sure >3000 lines of example output make sense here?
>> >
>> > I'm not. :)
>> >
>> > That's why I need feedback from the PCI experts. I believe most
>> > of the PCI ports on q35 accept only one device, but I see no code
>> > implementing that restriction, and no obvious PCIBus or
>> > PCIBusClass field indicating that.
>> >
>> >> 
>> >> [...]
>> >> > ]
>> >> >   }
>> >> >
>> >> > Signed-off-by: Eduardo Habkost 
>> >> > ---
>> >> >  qapi-schema.json   | 114 
>> >> > +
>> >> >  include/hw/qdev-core.h |   6 +++
>> >> >  hw/core/bus.c  |  49 +
>> >> >  hw/pci/pci.c   | 106 
>> >> > +
>> >> >  qdev-monitor.c |  86 ++---
>> >> >  5 files changed, 328 insertions(+), 33 deletions(-)
>> >> >
>> >> > diff --git a/qapi-schema.json b/qapi-schema.json
>> >> > index d48ff3f..484d91e 100644
>> >> > --- a/qapi-schema.json
>> >> > +++ b/qapi-schema.json
>> >> > @@ -3166,6 +3166,120 @@
>> >> >  { 'command': 'closefd', 'data': {'fdname': 'str'} }
>> >> >  
>> >> >  ##
>> >> > +# @DeviceSlotType:
>> >> > +#
>> >> > +# Type of device slot
>> >> > +#
>> >> > +# @generic: Generic device slot, with no bus-specific information
>> >> > +# @pci: PCI device slot
>> >> > +# @cpu: CPU device slot
>> >> > +##
>> >> > +{ 'enum': 'DeviceSlotType',
>> >> > +  'data': ['generic', 'pci', 'cpu'] }
>> >> > +
>> >> > +##
>> >> > +# @DeviceSlotInfo:
>> >> > +#
>> >> > +# Information on a slot where devices can be plugged. Some buses
>> >> > +# are represented as a single slot that can support multiple devices,
>> >> > +# and some buses have multiple slots that are identified by arguments
>> >> > +# to @device_add.
>> >> 
>> >> Okay, let me try to wrap my poor, ignorant mind around this.
>> >> 
>> >> There are two kinds of buses: "single slot that can support multiple
>> >> devices", and "multiple slots that are identified by arguments".
>> >> 
>> >> How are the two kinds related to @type?
>> >
>> > They are related to @type indirectly because different bus types
>> > will return different data. But I don't want to make this part of
>> > the specification: clients should be prepared to handle both
>> > cases.
>> 
>> Well, color me confused :)
>> 
>> > e.g. a QEMU version might return a single generic catch-all
>> > sysbus-device slot that support any number of devices. Future
>> > versions may return more detailed information, and return slots
>> > only for the sysbus devices that really work with the machine.
>> 
>> Hmm.  See below.
>> 
>> >> 
>> >> Examples for "multiple slots that are identified by arguments":
>> >> 
>> >> -device edu,addr=06.0,bus=...
>> >> -device scsi-hd,scsi-hd=5,bus=...
>> >> -device ide-hd,unit=1,bus=...
>> >> -device 

Re: [Qemu-devel] [RFC] qmp: query-device-slots command

[Eduardo Habkost]

On Tue, Dec 13, 2016 at 08:51:34PM +0100, Markus Armbruster wrote:
> Eduardo Habkost  writes:
> 
> > On Tue, Dec 13, 2016 at 12:04:17PM +0100, Markus Armbruster wrote:
> >> Quick interface review only:
> >> 
> >> Eduardo Habkost  writes:
> >> 
> >> > This adds a new command to QMP: query-device-slots. It will allow
> >> > management software to query possible slots where devices can be
> >> > plugged.
> >> >
> >> > This implementation of the command will return:
> >> >
> >> > * Multiple PCI slots per bus, in the case of PCI buses;
> >> > * One slot per bus in the case of the other buses;
> >> 
> >> Umm, that doesn't seem right.  For instance, a SCSI bus has multiple
> >> slots.  The slot address is the SCSI ID.  An IDE bus may have one (SATA)
> >> or two (PATA).  For more examples, see qdev-device-use.txt section
> >> "Specifying Bus and Address on Bus".
> >
> > Yes, I should have clarified that: this version changes only PCI
> > to expose multiple slots, but other buses also need be changed to
> > implement BusClass::enumerate_slots() properly, too.
> >
> >> 
> >> > * One slot for each entry from query-hotpluggable-cpus.
> >> > In the example below, I am not sure if the PCIe ports are all
> >> > supposed to report all slots, but I didn't find any existing
> >> > field in PCIBus that would help me figure out the actual number
> >> > of slots in a given PCI bus.
> >> >
> >> > Git tree
> >> > 
> >> >
> >> > This patch needs the previous query-machines series I am working
> >> > on. The full tree can be found on the git tree at:
> >> >
> >> >   git://github.com/ehabkost/qemu-hacks.git work/query-machines-bus-info
> >> >
> >> > Example output
> >> > --
> >> >
> >> > The following output was returned by QEMU when running it as:
> >> >
> >> >  $ qemu-system-x86_64 -machine q35 \
> >> >-readconfig docs/q35-chipset.cfg \
> >> >-smp 4,maxcpus=8,sockets=2,cores=2,threads=2
> >> >
> >> >  {
> >> > "return": [
> >> 
> >> Are you sure >3000 lines of example output make sense here?
> >
> > I'm not. :)
> >
> > That's why I need feedback from the PCI experts. I believe most
> > of the PCI ports on q35 accept only one device, but I see no code
> > implementing that restriction, and no obvious PCIBus or
> > PCIBusClass field indicating that.
> >
> >> 
> >> [...]
> >> > ]
> >> >   }
> >> >
> >> > Signed-off-by: Eduardo Habkost 
> >> > ---
> >> >  qapi-schema.json   | 114 
> >> > +
> >> >  include/hw/qdev-core.h |   6 +++
> >> >  hw/core/bus.c  |  49 +
> >> >  hw/pci/pci.c   | 106 
> >> > +
> >> >  qdev-monitor.c |  86 ++---
> >> >  5 files changed, 328 insertions(+), 33 deletions(-)
> >> >
> >> > diff --git a/qapi-schema.json b/qapi-schema.json
> >> > index d48ff3f..484d91e 100644
> >> > --- a/qapi-schema.json
> >> > +++ b/qapi-schema.json
> >> > @@ -3166,6 +3166,120 @@
> >> >  { 'command': 'closefd', 'data': {'fdname': 'str'} }
> >> >  
> >> >  ##
> >> > +# @DeviceSlotType:
> >> > +#
> >> > +# Type of device slot
> >> > +#
> >> > +# @generic: Generic device slot, with no bus-specific information
> >> > +# @pci: PCI device slot
> >> > +# @cpu: CPU device slot
> >> > +##
> >> > +{ 'enum': 'DeviceSlotType',
> >> > +  'data': ['generic', 'pci', 'cpu'] }
> >> > +
> >> > +##
> >> > +# @DeviceSlotInfo:
> >> > +#
> >> > +# Information on a slot where devices can be plugged. Some buses
> >> > +# are represented as a single slot that can support multiple devices,
> >> > +# and some buses have multiple slots that are identified by arguments
> >> > +# to @device_add.
> >> 
> >> Okay, let me try to wrap my poor, ignorant mind around this.
> >> 
> >> There are two kinds of buses: "single slot that can support multiple
> >> devices", and "multiple slots that are identified by arguments".
> >> 
> >> How are the two kinds related to @type?
> >
> > They are related to @type indirectly because different bus types
> > will return different data. But I don't want to make this part of
> > the specification: clients should be prepared to handle both
> > cases.
> 
> Well, color me confused :)
> 
> > e.g. a QEMU version might return a single generic catch-all
> > sysbus-device slot that support any number of devices. Future
> > versions may return more detailed information, and return slots
> > only for the sysbus devices that really work with the machine.
> 
> Hmm.  See below.
> 
> >> 
> >> Examples for "multiple slots that are identified by arguments":
> >> 
> >> -device edu,addr=06.0,bus=...
> >> -device scsi-hd,scsi-hd=5,bus=...
> >> -device ide-hd,unit=1,bus=...
> >> -device virtserialport,nr=7,bus=...
> >> 
> >> Note that each of these buses has its own way to specify a slot address,
> >> namely a bus-specific option.
> >
> > Yes.
> >
> >> 
> >> Can you give 

Re: [Qemu-devel] [RFC] qmp: query-device-slots command

[Markus Armbruster]

Eduardo Habkost  writes:

> On Tue, Dec 13, 2016 at 12:04:17PM +0100, Markus Armbruster wrote:
>> Quick interface review only:
>> 
>> Eduardo Habkost  writes:
>> 
>> > This adds a new command to QMP: query-device-slots. It will allow
>> > management software to query possible slots where devices can be
>> > plugged.
>> >
>> > This implementation of the command will return:
>> >
>> > * Multiple PCI slots per bus, in the case of PCI buses;
>> > * One slot per bus in the case of the other buses;
>> 
>> Umm, that doesn't seem right.  For instance, a SCSI bus has multiple
>> slots.  The slot address is the SCSI ID.  An IDE bus may have one (SATA)
>> or two (PATA).  For more examples, see qdev-device-use.txt section
>> "Specifying Bus and Address on Bus".
>
> Yes, I should have clarified that: this version changes only PCI
> to expose multiple slots, but other buses also need be changed to
> implement BusClass::enumerate_slots() properly, too.
>
>> 
>> > * One slot for each entry from query-hotpluggable-cpus.
>> > In the example below, I am not sure if the PCIe ports are all
>> > supposed to report all slots, but I didn't find any existing
>> > field in PCIBus that would help me figure out the actual number
>> > of slots in a given PCI bus.
>> >
>> > Git tree
>> > 
>> >
>> > This patch needs the previous query-machines series I am working
>> > on. The full tree can be found on the git tree at:
>> >
>> >   git://github.com/ehabkost/qemu-hacks.git work/query-machines-bus-info
>> >
>> > Example output
>> > --
>> >
>> > The following output was returned by QEMU when running it as:
>> >
>> >  $ qemu-system-x86_64 -machine q35 \
>> >-readconfig docs/q35-chipset.cfg \
>> >-smp 4,maxcpus=8,sockets=2,cores=2,threads=2
>> >
>> >  {
>> > "return": [
>> 
>> Are you sure >3000 lines of example output make sense here?
>
> I'm not. :)
>
> That's why I need feedback from the PCI experts. I believe most
> of the PCI ports on q35 accept only one device, but I see no code
> implementing that restriction, and no obvious PCIBus or
> PCIBusClass field indicating that.
>
>> 
>> [...]
>> > ]
>> >   }
>> >
>> > Signed-off-by: Eduardo Habkost 
>> > ---
>> >  qapi-schema.json   | 114 
>> > +
>> >  include/hw/qdev-core.h |   6 +++
>> >  hw/core/bus.c  |  49 +
>> >  hw/pci/pci.c   | 106 +
>> >  qdev-monitor.c |  86 ++---
>> >  5 files changed, 328 insertions(+), 33 deletions(-)
>> >
>> > diff --git a/qapi-schema.json b/qapi-schema.json
>> > index d48ff3f..484d91e 100644
>> > --- a/qapi-schema.json
>> > +++ b/qapi-schema.json
>> > @@ -3166,6 +3166,120 @@
>> >  { 'command': 'closefd', 'data': {'fdname': 'str'} }
>> >  
>> >  ##
>> > +# @DeviceSlotType:
>> > +#
>> > +# Type of device slot
>> > +#
>> > +# @generic: Generic device slot, with no bus-specific information
>> > +# @pci: PCI device slot
>> > +# @cpu: CPU device slot
>> > +##
>> > +{ 'enum': 'DeviceSlotType',
>> > +  'data': ['generic', 'pci', 'cpu'] }
>> > +
>> > +##
>> > +# @DeviceSlotInfo:
>> > +#
>> > +# Information on a slot where devices can be plugged. Some buses
>> > +# are represented as a single slot that can support multiple devices,
>> > +# and some buses have multiple slots that are identified by arguments
>> > +# to @device_add.
>> 
>> Okay, let me try to wrap my poor, ignorant mind around this.
>> 
>> There are two kinds of buses: "single slot that can support multiple
>> devices", and "multiple slots that are identified by arguments".
>> 
>> How are the two kinds related to @type?
>
> They are related to @type indirectly because different bus types
> will return different data. But I don't want to make this part of
> the specification: clients should be prepared to handle both
> cases.

Well, color me confused :)

> e.g. a QEMU version might return a single generic catch-all
> sysbus-device slot that support any number of devices. Future
> versions may return more detailed information, and return slots
> only for the sysbus devices that really work with the machine.

Hmm.  See below.

>> 
>> Examples for "multiple slots that are identified by arguments":
>> 
>> -device edu,addr=06.0,bus=...
>> -device scsi-hd,scsi-hd=5,bus=...
>> -device ide-hd,unit=1,bus=...
>> -device virtserialport,nr=7,bus=...
>> 
>> Note that each of these buses has its own way to specify a slot address,
>> namely a bus-specific option.
>
> Yes.
>
>> 
>> Can you give examples for "single slot that can support multiple
>> devices"?
>
> I can't name any example except sysbus, right now.

Sysbus is a bad example, because it's a hack, not a bus.

Physical devices are wired up in some device-specific way.  An important
special wiring case is plugging into a standard socket provided by a
bus.  But not every device is 

Re: [Qemu-devel] [RFC] qmp: query-device-slots command

[Eduardo Habkost]

On Tue, Dec 13, 2016 at 04:15:18PM +0200, Marcel Apfelbaum wrote:
> On 12/13/2016 02:42 PM, Eduardo Habkost wrote:
> > On Tue, Dec 13, 2016 at 12:04:17PM +0100, Markus Armbruster wrote:
> > > Quick interface review only:
> > > 
> > > Eduardo Habkost  writes:
> > > 
> > > > This adds a new command to QMP: query-device-slots. It will allow
> > > > management software to query possible slots where devices can be
> > > > plugged.
> > > > 
> > > > This implementation of the command will return:
> > > > 
> > > > * Multiple PCI slots per bus, in the case of PCI buses;
> > > > * One slot per bus in the case of the other buses;
> > > 
> > > Umm, that doesn't seem right.  For instance, a SCSI bus has multiple
> > > slots.  The slot address is the SCSI ID.  An IDE bus may have one (SATA)
> > > or two (PATA).  For more examples, see qdev-device-use.txt section
> > > "Specifying Bus and Address on Bus".
> > 
> > Yes, I should have clarified that: this version changes only PCI
> > to expose multiple slots, but other buses also need be changed to
> > implement BusClass::enumerate_slots() properly, too.
> > 
> > > 
> > > > * One slot for each entry from query-hotpluggable-cpus.
> > > > In the example below, I am not sure if the PCIe ports are all
> > > > supposed to report all slots, but I didn't find any existing
> > > > field in PCIBus that would help me figure out the actual number
> > > > of slots in a given PCI bus.
> > > > 
> > > > Git tree
> > > > 
> > > > 
> > > > This patch needs the previous query-machines series I am working
> > > > on. The full tree can be found on the git tree at:
> > > > 
> > > >   git://github.com/ehabkost/qemu-hacks.git work/query-machines-bus-info
> > > > 
> > > > Example output
> > > > --
> > > > 
> > > > The following output was returned by QEMU when running it as:
> > > > 
> > > >  $ qemu-system-x86_64 -machine q35 \
> > > >-readconfig docs/q35-chipset.cfg \
> > > >-smp 4,maxcpus=8,sockets=2,cores=2,threads=2
> > > > 
> > > >  {
> > > > "return": [
> > > 
> > > Are you sure >3000 lines of example output make sense here?
> > 
> > I'm not. :)
> > 
> > That's why I need feedback from the PCI experts. I believe most
> > of the PCI ports on q35 accept only one device, but I see no code
> > implementing that restriction, and no obvious PCIBus or
> > PCIBusClass field indicating that.
> 
> Hi,
> 
> Sadly there is no such restriction today as far as I know.
> We trust the user that he knows what he is doing :)
> and we let libvirt implement the restriction.
> 
> I do agree we should fix that.

OK, this matches what I saw on the current code.

But I would like to understand what exactly should be the rules
if we fix that. Should we report only 1 slot if
pci_bus_has_pcie_upstream_port(bus)?

(Note that pci_bus_has_pcie_upstream_port() doesn't exist in the
current code, it is added by my patch)

-- 
Eduardo

Re: [Qemu-devel] [RFC] qmp: query-device-slots command

[Marcel Apfelbaum]

On 12/13/2016 02:42 PM, Eduardo Habkost wrote:

On Tue, Dec 13, 2016 at 12:04:17PM +0100, Markus Armbruster wrote:

Quick interface review only:

Eduardo Habkost  writes:


This adds a new command to QMP: query-device-slots. It will allow
management software to query possible slots where devices can be
plugged.

This implementation of the command will return:

* Multiple PCI slots per bus, in the case of PCI buses;
* One slot per bus in the case of the other buses;


Umm, that doesn't seem right.  For instance, a SCSI bus has multiple
slots.  The slot address is the SCSI ID.  An IDE bus may have one (SATA)
or two (PATA).  For more examples, see qdev-device-use.txt section
"Specifying Bus and Address on Bus".


Yes, I should have clarified that: this version changes only PCI
to expose multiple slots, but other buses also need be changed to
implement BusClass::enumerate_slots() properly, too.




* One slot for each entry from query-hotpluggable-cpus.
In the example below, I am not sure if the PCIe ports are all
supposed to report all slots, but I didn't find any existing
field in PCIBus that would help me figure out the actual number
of slots in a given PCI bus.

Git tree


This patch needs the previous query-machines series I am working
on. The full tree can be found on the git tree at:

  git://github.com/ehabkost/qemu-hacks.git work/query-machines-bus-info

Example output
--

The following output was returned by QEMU when running it as:

 $ qemu-system-x86_64 -machine q35 \
   -readconfig docs/q35-chipset.cfg \
   -smp 4,maxcpus=8,sockets=2,cores=2,threads=2

 {
"return": [


Are you sure >3000 lines of example output make sense here?


I'm not. :)

That's why I need feedback from the PCI experts. I believe most
of the PCI ports on q35 accept only one device, but I see no code
implementing that restriction, and no obvious PCIBus or
PCIBusClass field indicating that.


Hi,

Sadly there is no such restriction today as far as I know.
We trust the user that he knows what he is doing :)
and we let libvirt implement the restriction.

I do agree we should fix that.

Thanks,
Marcel





[...]


[...]

Re: [Qemu-devel] [RFC] qmp: query-device-slots command

[Eduardo Habkost]

On Tue, Dec 13, 2016 at 12:04:17PM +0100, Markus Armbruster wrote:
> Quick interface review only:
> 
> Eduardo Habkost  writes:
> 
> > This adds a new command to QMP: query-device-slots. It will allow
> > management software to query possible slots where devices can be
> > plugged.
> >
> > This implementation of the command will return:
> >
> > * Multiple PCI slots per bus, in the case of PCI buses;
> > * One slot per bus in the case of the other buses;
> 
> Umm, that doesn't seem right.  For instance, a SCSI bus has multiple
> slots.  The slot address is the SCSI ID.  An IDE bus may have one (SATA)
> or two (PATA).  For more examples, see qdev-device-use.txt section
> "Specifying Bus and Address on Bus".

Yes, I should have clarified that: this version changes only PCI
to expose multiple slots, but other buses also need be changed to
implement BusClass::enumerate_slots() properly, too.

> 
> > * One slot for each entry from query-hotpluggable-cpus.
> > In the example below, I am not sure if the PCIe ports are all
> > supposed to report all slots, but I didn't find any existing
> > field in PCIBus that would help me figure out the actual number
> > of slots in a given PCI bus.
> >
> > Git tree
> > 
> >
> > This patch needs the previous query-machines series I am working
> > on. The full tree can be found on the git tree at:
> >
> >   git://github.com/ehabkost/qemu-hacks.git work/query-machines-bus-info
> >
> > Example output
> > --
> >
> > The following output was returned by QEMU when running it as:
> >
> >  $ qemu-system-x86_64 -machine q35 \
> >-readconfig docs/q35-chipset.cfg \
> >-smp 4,maxcpus=8,sockets=2,cores=2,threads=2
> >
> >  {
> > "return": [
> 
> Are you sure >3000 lines of example output make sense here?

I'm not. :)

That's why I need feedback from the PCI experts. I believe most
of the PCI ports on q35 accept only one device, but I see no code
implementing that restriction, and no obvious PCIBus or
PCIBusClass field indicating that.

> 
> [...]
> > ]
> >   }
> >
> > Signed-off-by: Eduardo Habkost 
> > ---
> >  qapi-schema.json   | 114 
> > +
> >  include/hw/qdev-core.h |   6 +++
> >  hw/core/bus.c  |  49 +
> >  hw/pci/pci.c   | 106 +
> >  qdev-monitor.c |  86 ++---
> >  5 files changed, 328 insertions(+), 33 deletions(-)
> >
> > diff --git a/qapi-schema.json b/qapi-schema.json
> > index d48ff3f..484d91e 100644
> > --- a/qapi-schema.json
> > +++ b/qapi-schema.json
> > @@ -3166,6 +3166,120 @@
> >  { 'command': 'closefd', 'data': {'fdname': 'str'} }
> >  
> >  ##
> > +# @DeviceSlotType:
> > +#
> > +# Type of device slot
> > +#
> > +# @generic: Generic device slot, with no bus-specific information
> > +# @pci: PCI device slot
> > +# @cpu: CPU device slot
> > +##
> > +{ 'enum': 'DeviceSlotType',
> > +  'data': ['generic', 'pci', 'cpu'] }
> > +
> > +##
> > +# @DeviceSlotInfo:
> > +#
> > +# Information on a slot where devices can be plugged. Some buses
> > +# are represented as a single slot that can support multiple devices,
> > +# and some buses have multiple slots that are identified by arguments
> > +# to @device_add.
> 
> Okay, let me try to wrap my poor, ignorant mind around this.
> 
> There are two kinds of buses: "single slot that can support multiple
> devices", and "multiple slots that are identified by arguments".
> 
> How are the two kinds related to @type?

They are related to @type indirectly because different bus types
will return different data. But I don't want to make this part of
the specification: clients should be prepared to handle both
cases.

e.g. a QEMU version might return a single generic catch-all
sysbus-device slot that support any number of devices. Future
versions may return more detailed information, and return slots
only for the sysbus devices that really work with the machine.

> 
> Examples for "multiple slots that are identified by arguments":
> 
> -device edu,addr=06.0,bus=...
> -device scsi-hd,scsi-hd=5,bus=...
> -device ide-hd,unit=1,bus=...
> -device virtserialport,nr=7,bus=...
> 
> Note that each of these buses has its own way to specify a slot address,
> namely a bus-specific option.

Yes.

> 
> Can you give examples for "single slot that can support multiple
> devices"?

I can't name any example except sysbus, right now.

There are two cases that I tried to cover by reporting
multiple-device no-argument slots:

1) Buses that were not converted (yet) to implement
   enumerate_buses() (in the current version: everything except
   PCI)
2) Buses that really do not require any extra slot address
   argument (sysbus? others?)

I'm proposing this interface because I don't want (1) or (2) to
be missing from the returned data (otherwise management software
can't differentiate "this bus is not 

Re: [Qemu-devel] [RFC] qmp: query-device-slots command

[Markus Armbruster]

Quick interface review only:

Eduardo Habkost  writes:

> This adds a new command to QMP: query-device-slots. It will allow
> management software to query possible slots where devices can be
> plugged.
>
> This implementation of the command will return:
>
> * Multiple PCI slots per bus, in the case of PCI buses;
> * One slot per bus in the case of the other buses;

Umm, that doesn't seem right.  For instance, a SCSI bus has multiple
slots.  The slot address is the SCSI ID.  An IDE bus may have one (SATA)
or two (PATA).  For more examples, see qdev-device-use.txt section
"Specifying Bus and Address on Bus".

> * One slot for each entry from query-hotpluggable-cpus.
> In the example below, I am not sure if the PCIe ports are all
> supposed to report all slots, but I didn't find any existing
> field in PCIBus that would help me figure out the actual number
> of slots in a given PCI bus.
>
> Git tree
> 
>
> This patch needs the previous query-machines series I am working
> on. The full tree can be found on the git tree at:
>
>   git://github.com/ehabkost/qemu-hacks.git work/query-machines-bus-info
>
> Example output
> --
>
> The following output was returned by QEMU when running it as:
>
>  $ qemu-system-x86_64 -machine q35 \
>-readconfig docs/q35-chipset.cfg \
>-smp 4,maxcpus=8,sockets=2,cores=2,threads=2
>
>  {
> "return": [

Are you sure >3000 lines of example output make sense here?

[...]
> ]
>   }
>
> Signed-off-by: Eduardo Habkost 
> ---
>  qapi-schema.json   | 114 
> +
>  include/hw/qdev-core.h |   6 +++
>  hw/core/bus.c  |  49 +
>  hw/pci/pci.c   | 106 +
>  qdev-monitor.c |  86 ++---
>  5 files changed, 328 insertions(+), 33 deletions(-)
>
> diff --git a/qapi-schema.json b/qapi-schema.json
> index d48ff3f..484d91e 100644
> --- a/qapi-schema.json
> +++ b/qapi-schema.json
> @@ -3166,6 +3166,120 @@
>  { 'command': 'closefd', 'data': {'fdname': 'str'} }
>  
>  ##
> +# @DeviceSlotType:
> +#
> +# Type of device slot
> +#
> +# @generic: Generic device slot, with no bus-specific information
> +# @pci: PCI device slot
> +# @cpu: CPU device slot
> +##
> +{ 'enum': 'DeviceSlotType',
> +  'data': ['generic', 'pci', 'cpu'] }
> +
> +##
> +# @DeviceSlotInfo:
> +#
> +# Information on a slot where devices can be plugged. Some buses
> +# are represented as a single slot that can support multiple devices,
> +# and some buses have multiple slots that are identified by arguments
> +# to @device_add.

Okay, let me try to wrap my poor, ignorant mind around this.

There are two kinds of buses: "single slot that can support multiple
devices", and "multiple slots that are identified by arguments".

How are the two kinds related to @type?

Examples for "multiple slots that are identified by arguments":

-device edu,addr=06.0,bus=...
-device scsi-hd,scsi-hd=5,bus=...
-device ide-hd,unit=1,bus=...
-device virtserialport,nr=7,bus=...

Note that each of these buses has its own way to specify a slot address,
namely a bus-specific option.

Can you give examples for "single slot that can support multiple
devices"?

> +#
> +# @bus: ID of the bus object where the device can be plugged. Optional,
> +#   as some devices don't need a bus to be plugged (e.g. CPUs).
> +#   Can be copied to the "bus" argument to @device_add.

Suggest something like "Can be used as value for @device_add's bus
option".

Should we give similar information on the slot address?  The option name
is obvious.  What about acceptable values?

> +#
> +# @type: type of device slot.
> +#
> +# @accepted-device-types: List of device types accepted by the slot.
> +# Any device plugged to the slot should implement
> +# one of the accepted device types.
> +#
> +# @max-devices: #optional maximum number of devices that can be plugged
> +#   to the slot.

What does it mean when @max-devices isn't given?

> +#
> +# @devices: List of QOM paths for devices that are already plugged.
> +#
> +# @available: If false, the slot is not available for plugging any device.
> +# This value can change at runtime if condition changes
> +# (e.g. if the device becomes full, or if the machine
> +# was already initialized and the slot doesn't support
> +# hotplug).
> +#
> +# @hotpluggable: If true, the slot accepts hotplugged devices.
> +#
> +# DeviceSlotInfo structs always have a @props member, whose members
> +# can be directly copied to the arguments to @device_add.

Do you mean names of properties common to all @accepted-device-types?

> +##
> +{ 'union': 'DeviceSlotInfo',
> +  'base': { 'type': 'DeviceSlotType',
> +'accepted-device-types': [ 'str' ],
> +'*max-devices': 'int', 'devices': [ 'str' 

[Qemu-devel] [RFC] qmp: query-device-slots command

[Eduardo Habkost]

This adds a new command to QMP: query-device-slots. It will allow
management software to query possible slots where devices can be
plugged.

This implementation of the command will return:

* Multiple PCI slots per bus, in the case of PCI buses;
* One slot per bus in the case of the other buses;
* One slot for each entry from query-hotpluggable-cpus.

In the example below, I am not sure if the PCIe ports are all
supposed to report all slots, but I didn't find any existing
field in PCIBus that would help me figure out the actual number
of slots in a given PCI bus.

Git tree


This patch needs the previous query-machines series I am working
on. The full tree can be found on the git tree at:

  git://github.com/ehabkost/qemu-hacks.git work/query-machines-bus-info

Example output
--

The following output was returned by QEMU when running it as:

 $ qemu-system-x86_64 -machine q35 \
   -readconfig docs/q35-chipset.cfg \
   -smp 4,maxcpus=8,sockets=2,cores=2,threads=2

 {
"return": [
{
"available": false,
"devices": [
"/machine/unattached/device[30]",
"/machine/unattached/device[29]",
"/machine/unattached/device[28]",
"/machine/unattached/device[27]",
"/machine/unattached/device[26]",
"/machine/unattached/device[25]",
"/machine/unattached/device[24]",
"/machine/unattached/device[23]"
],
"accepted-device-types": [
"i2c-slave"
],
"props": {
"bus": "/machine/unattached/device[22]/i2c"
},
"hotpluggable": false,
"type": "generic"
},
{
"available": false,
"devices": [],
"accepted-device-types": [
"ide-device"
],
"props": {
"bus": "/machine/unattached/device[20]/ide.4"
},
"hotpluggable": false,
"type": "generic"
},
{
"available": false,
"devices": [],
"accepted-device-types": [
"ide-device"
],
"props": {
"bus": "/machine/unattached/device[20]/ide.5"
},
"hotpluggable": false,
"type": "generic"
},
{
"available": false,
"devices": [],
"accepted-device-types": [
"ide-device"
],
"props": {
"bus": "/machine/unattached/device[20]/ide.0"
},
"hotpluggable": false,
"type": "generic"
},
{
"available": false,
"devices": [],
"accepted-device-types": [
"ide-device"
],
"props": {
"bus": "/machine/unattached/device[20]/ide.1"
},
"hotpluggable": false,
"type": "generic"
},
{
"available": false,
"devices": [
"/machine/unattached/device[21]"
],
"accepted-device-types": [
"ide-device"
],
"props": {
"bus": "/machine/unattached/device[20]/ide.2"
},
"hotpluggable": false,
"type": "generic"
},
{
"available": false,
"devices": [],
"accepted-device-types": [
"ide-device"
],
"props": {
"bus": "/machine/unattached/device[20]/ide.3"
},
"hotpluggable": false,
"type": "generic"
},
{
"available": false,
"devices": [
"/machine/unattached/device[8]",
"/machine/q35/ioapic",
"/machine/q35",
"/machine/fw_cfg",
"/machine/unattached/device[1]"
],
"accepted-device-types": [
"sys-bus-device"
],
"props": {
"bus": "/machine/unattached/sysbus"
},
"hotpluggable": false,
"type": "generic"
},
{
"available": false,
"devices": [
"/machine/unattached/device[19]",
"/machine/unattached/device[18]",
"/machine/unattached/device[17]",
"/machine/unattached/device[16]",
"/machine/unattached/device[15]",
"/machine/unattached/device[14]",
"/machine/unattached/device[13]",
"/machine/unattached/device[12]",
"/machine/unattached/device[11]",
"/machine/unattached/device[10]",
"/machine/unattached/device[9]",
"/machine/unattached/device[7]",