On Fri, Jul 17, 2015 at 02:43:34PM -0400, Laine Stump wrote: > There are some configuration options to some types of pci > controllers that are currently automatically derived from other parts > of the controller's configuration. For example, a pci-bridge > controller has an option that is called "chassis_nr" in qemu; libvirt > always sets chassis_nr to the index of the pci-bridge. So this: > > <controller type='pci' model='pci-bridge' index='2'/> > > will always result in: > > -device pci-bridge,chassis_nr=2,... > > on the qemu commandline. In the future we may decide there is a better > way to derive that option, but even in that case we will need for > existing domains to retain the same chassis_nr they were using in the > past - that is something that is visible to the guest so it is part of > the guest ABI and changing it would lead to problems for migrating > guests (or just guests with very picky OSes). > Should this be checked in virDomainDefCheckABIStability then? > The <target> subelement has been added as a place to put the new > "chassisNr" attribute that will be filled in by libvirt when it > auto-generates the chassisNr; it will be saved in the config, then > reused any time the domain is started: > > <controller type='pci' model='pci-bridge' index='2'> > <model type='pci-bridge'/> > <target chassisNr='2'/> > </controller> The 'Nr' seems redundant. Is this any different from the pcie-root-port's chasis? We could use the same attribute for both. Jan > > The one oddity of all this is that if the controller configuration > is changed (for example to change the index or the pci address > where the controller is plugged in), the items in <target> will > *not* be re-generated, which might lead to conflict. I can't > really see any way around this, but fortunately if there is a > material conflict qemu will let us know and we will pass that on > to the user. > ---
Attachment:
signature.asc
Description: Digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list