Re: [libvirt] [PATCHv2 07/17] conf: add new <target> subelement with chassisNr attribute to <controller>

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.