On Fri, 2013-04-05 at 14:42 -0400, Laine Stump wrote:
On 04/05/2013 01:38 PM, Daniel P. Berrange wrote:
> On Fri, Apr 05, 2013 at 12:32:04PM -0400, Laine Stump wrote:
>> On 04/03/2013 11:50 AM, Ján Tomko wrote:
>>> From: liguang <lig.fnst(a)cn.fujitsu.com>
>>>
>>> add a new controller type, then one can
>>> define a pci-bridge controller like this:
>>> <controller type='pci-bridge' index='0'/>
>> In the next patch we're prohibiting exactly this config (index='0')
>> because the pre-existing pci bus on the "pc-*" machinetypes is
already
>> named pci.0. If we don't allow it, we shouldn't include it as an
example
>> in the commit log :-)
> NB, it isn't always named 'pci.0' - on many arches it is merely
'pci'.
Yeah, I'm just using that as a convenient shorthand. The final decision
on whether to use pci.0 or pci happens down in the qemuBuildCommandline().
>
>> More on this - one of the things this points out is that there is no
>> representation in the config of the pci.0 bus, it's just assumed to
>> always be there. That is the case for pc-* machinetypes (and probably
>> several others with PCI buses), but for q35, there is no pci.0 bus in
>> the basic machine, only a pcie.0; if you want a pci.0 on q35 (which
>> *will* be necessary in order to attach any pci devices, so I imagine we
>> will always want one), you have to attach a pcie->pci bridge, which is
>> the device "i82801b11-bridge", to pcie.0.
>> The reason I bring this up here, is I'm wondering:
>>
>> 1) should we have some representation of the default pci.0 bus in the
>> config, even though it is just "always there" for the pc machinetypes
>> and there is no way to disable it, and nothing on the commandline that
>> specifies its existence?
> Yep, we should be aiming for the XML to fully describe the machine
> hardware. So since we're adding the concept of PCI controllers/bridges
> etc to the XML, we should be auto-adding the default bus to the XML.
>
>> 2) For the q35 machinetype, should we just always add an
>> i82801b11-bridge device and name it pci.0? Or should that need to be
>> present in the xml?
> We've been burnt before auto-adding stuff that ought to have
> been optional. So I'd tend towards only having the minimal
> config that is required. If the users want this, let them
> explicitly ask for the bridge
>
> Also from the apps POV the QEMU device name is irrelevant. The
> XML config works off the PCI addresses. So there's no need
> to force/specialcase a i82801b11-bridge to use the name
> 'pci.0'.
Sure. I just mean "pci bus 0" (hmm, but actually this does point out a
problem with my logic - the same namespace (well, "numbering space") is
used for both pcie and pci buses, so on a q35 system, bus=0 is already
taken by pcie.0; that means that the first pci bus would need to use a
different bus number anyway, so it wouldn't be so easy to switch an
existing domain from pc to q35 - every PCI device would need to have its
bus number modified. I suppose that's reasonable to expect, though.
I would think you'd want to differentiate PCI from PCIe anyway. PCI is
a bus and you have 32 slots per bus to fill. PCIe is a point-to-point
link and you really only have slot 0 available. Perhaps that puts them
in different number spaces already.
>> 3) Most important - depending on the answers to (1) and (2),
should we
>> maybe name this device "pci", and use a different backend depending
on
>> index and machinetype? (or alternately explicitly specifiable with a
>> <driver> subelement). To be specific, we would have:
>>
>> <controller type='pci' index='0'/>
>>
>> which on pc machinetypes would just be a placeholder in the config (and
>> always inserted if it wasn't there, for machinetypes that have a pci
>> bus). On the q35 machinetype, that same line would equate to adding an
>> i82801b11-bridge device (with source defaulting to
>> bus=pcie.0,addr=1e.0). This would serve several purposes:
>>
>> a) on pc machinetypes, it would be a visual aid indicating that pci.0
>> exists, and that index='0' isn't available for a new pci
controller.
>>
>> b) it would make switching a domain config from pc to q35 simpler, since
>> pci.0 would always already be in place for attaching pci devices
>> (including pci.1, pci.2, etc)
>>
>> c) it would make the config a true complete description of the machine
>> being created.
>>
>> (I've suggested naming the controller "pci" rather than
"pci-bridge"
>> because in the case of a "root" bus like pci.0 it seems to not be a
>> "bridge", but maybe the name "pci-bridge" is always
appropriate, even
>> when it's a root bus. Maybe someone with better pci/pcie knowledge can
>> provide an opinion on this)
> I think "pci" is a little too generic - how about we call it
'pci-root'
Okay, so a separate "pci-root" device along with "pci-bridge"? What
I
was really hoping was to have all PCI buses represented in a common way
in the config. How about a controller called "pci" with different types,
"root" and "bridge"? And since they use the same numbering space as
pcie
buses, maybe the pcie controllers (including the root and the hubs and
???) would be different types of PCI controllers. That would make it
easier (i.e. *possible*) to avoid collisions in use of bus numbers.
Alex or mst, any advice/opinions on how to represent all the different
q35 devices that consume bus numbers in a succinct fashion?
Note that none of these are really bus numbers, they're just bus
identifiers. The BIOS and the guest running define the bus numbers.
"root" also has special meaning in PCI, so for instance I wouldn't name
a bus behind the i82801b11-bridge "pci-root". Somehow we also need to
deal with what can be attached where. For instance a pci-bridge is a
PCI device and can only go on a PCI bus. The equivalent structure on
PCIe is an upstream switch port with some number of downstream switch
ports. Each of those are specific to the bus type.
For PCIe, we create new buses for root ports (ioh3420), upstream switch
ports (xio3130-upstream), downstream switch ports (xio3130-downstream),
and the dmi-to-pci bridge (i82801b11-bridge). For PCI, PCI-to-PCI
bridges create new buses (pci-bridge and dec-21154).
One of my goals is to move us away from emulation of specific chips and
create more devices like pci-bridge that adhere to the standard, but
don't try to emulate a specific device. Then we might have "root-port",
"pcie-upstream-switch-port", "pcie-downstream-switch-port", and
"dmi-to-pci-bridge" (none of these names have been discussed). Thanks,
Alex