[libvirt] [PATCH 00/13] PCIe fixes + new PCI controllers w/RFC

Martin Kletzander mkletzan at redhat.com
Thu Jun 25 10:51:58 UTC 2015


On Thu, Jun 25, 2015 at 11:46:41AM +0200, Ján Tomko wrote:
>On Thu, Jun 25, 2015 at 08:44:17AM +0200, Martin Kletzander wrote:
>> On Wed, Jun 24, 2015 at 12:04:33PM -0400, Laine Stump wrote:
>> >At this point you can see that it all comes down to what name we want to
>> >give the subelement; within that, we give the exact name of the qemu
>> >device, and the exact name/value of any qemu options that we set to
>> >non-default values.
>> >
>> >Somebody *please* have an opinion on the name for this, because none of
>> >these strikes me as better or worse (well, I think I dislike <driver>
>> >
>>
>> To be honest, I kinds dislike all of them.  Not that they would be
>> chosen poorly, no, it's simply because the good sensible choice is
>> unavailable due to another poor decision in the past (this may be
>> another point for Michal's talk on KVM Forum).  Thinking about it I
>> must say I don't like how target (which is supposed to match a place
>> where the device appears for the guest) is used for the model
>> specification, on the other hand (ab)using 'model' element for the
>> specification of an "address" in guest (that's what I understand
>> chassis and port are) doesn't feel any better.  What if we go with two
>> of those elements?  Would that be too much pain?  E.g.:
>>
>>   <controller type='pci model='pci-root-port' index='3'>
>>     <address type='pci' bus='0' slot='4' function='1'>
>>     <model type='ioh3420'/>
>>     <target chassis='3' port='0x21'/>
>>   </controller>
>
>I like this, essentially a subModel without the camelCase.
>One small nit: <model name='ioh4320'/> would look nicer to me,
>but we're using <model type=/> in at least one other place,
>so I'm fine with both.
>

I didn't think about the 'type', I probably just typed it in there
because each line had a 'type' already in :)  I like 'name' better
too, but diving deeply into it, I have no strong opinions on that.

>Jan
>
>>
>> I understand this might look like an overkill, but I think it's better
>> safe then sorry, I guess I just see us not so far in the future
>> regretting any decision made now.
>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20150625/a42ccb56/attachment-0001.sig>


More information about the libvir-list mailing list