On 01/19/2011 12:52 PM, Daniel P. Berrange wrote:
On Wed, Jan 19, 2011 at 11:51:58AM -0600, Anthony Liguori wrote:
On 01/19/2011 11:01 AM, Daniel P. Berrange wrote:
The reason we specify 'bus' is that we wanted to be flexible wrt
upgrades of libvirt, without needing restarts of QEMU instances
it manages. That way we can introduce new functionality into
libvirt that relies on it having previously set 'bus' on all
active QEMUs.
If QEMU adds PCI-to-PCI bridges, then I wouldn't expect QEMU to
be adding the extra bridges. I'd expect that QEMU provided just
the first bridge and then libvirt would specify how many more
bridges to create at boot or hotplug them later. So it wouldn't
ever need to parse topology.
Yeah, but replacing the main chipset will certainly change the PCI
topology such that if you're specifying bus=X and addr=X and then
also using -M pc, unless you're parsing the default topology to come
up with the addressing, it will break in the future.
We never use a bare '-M pc' though, we always canonicalize to
one of the versioned forms. So if we run '-M pc-0.12', then
neither the main PCI chipset nor topology would have changed
in newer QEMU. Of course if we deployed a new VM with
'-M pc-0.20' that might have new PCI chipset, so bus=pci.0
might have different meaning that it did when used with
'-M pc-0.12', but I don't think that's an immediate problem
Right, but you expose bus addressing via the XML, no? That means that
if a user specifies something like '1.0', and you translate that to
bus='pci.0',addr='1.0', then when pc-0.50 comes out and slot 1.0 is used
for the integrated 3D VGA graphics adapter, the guest creation will fail.
If you expose topological configuration to the user, the guest will not
continue working down the road unless you come up with a scheme where
you map addresses to a different address range for newer pcs.
Regards,
Anthony Liguori
Regards,
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
