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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 07/23/2015 09:24 AM, Ján Tomko wrote:
> 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?

Sigh. Probably. virDomainControllerDefCheckABIStability() to be more
precise. (There are *so many* t's to cross...)

>
>> 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?

Yes, it is different. How is it different? I don't know, you'd have to
ask Alex.

>  We could use the same attribute for both.

I'd rather not take the risk of encountering some controller in the
future that used both. I got the impression from my discussions with
Alex that this was something we can't guarantee against. (This idea was
mentioned during the last round, and also it was one of the first things
I asked about when I was originally writing the patches)

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]