On 01/19/2011 11:35 AM, Daniel P. Berrange wrote:
On Wed, Jan 19, 2011 at 10:53:30AM -0600, Anthony Liguori wrote:
On 01/19/2011 03:48 AM, Gerd Hoffmann wrote:
On 01/18/11 18:09, Anthony Liguori wrote:
On 01/18/2011 10:56 AM, Jan Kiszka wrote:
The device model topology is 100% a hidden architectural detail.
This is true for the sysbus, it is obviously not the case for PCI and
similarly discoverable buses. There we have a guest-explorable topology
that is currently equivalent to the the qdev layout.
But we also don't do PCI passthrough so we really haven't even explored
how that maps in qdev. I don't know if qemu-kvm has attempted to
qdev-ify it.
It is qdev-ified. It is a normal pci device from qdev's point of view.
BTW: is there any reason why (vfio-based) pci passthrough couldn't
work with tcg?
The -device interface is a stable interface. Right now, you don't
specify any type of identifier of the pci bus when you create a PCI
device. It's implied in the interface.
Wrong. You can specify the bus you want attach the device to via
bus=<name>. This is true for *every* device, including all pci
devices. If unspecified qdev uses the first bus it finds.
As long as there is a single pci bus only there is simply no need
to specify it, thats why nobody does that today.
Right. In terms of specifying bus=, what are we promising re:
compatibility? Will there always be a pci.0? If we add some
PCI-to-PCI bridges in order to support more devices, is libvirt
support to parse the hierarchy and figure out which bus to put the
device on?
The answer to your questions probably differ depending on
whether '-nodefconfig' and '-nodefaults' are set on the
command line. If they are set, then I'd expect to only
ever see one PCI bus with name pci.0 forever more, unless
i explicitly ask for more. If they are not set, then you
might expect to see multiple PCI buses by appear by magic
Yeah, we can't promise that. If you use -M pc, you aren't guaranteed a
stable PCI bus topology even with -nodefconfig/-nodefaults.
Regards,
Anthony Liguori
Daniel
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
