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

Ján Tomko jtomko at redhat.com
Thu Jul 23 13:24:20 UTC 2015


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.
> ---
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20150723/459492ab/attachment-0001.sig>


More information about the libvir-list mailing list