[libvirt] [PATCH v3 11/18] qemu: assign virtio devices to PCIe slot when appropriate

Marcel Apfelbaum marcel at redhat.com
Wed Nov 16 09:05:33 UTC 2016


On 11/15/2016 09:58 PM, Laine Stump wrote:
> On 11/15/2016 12:44 PM, Alex Williamson wrote:
>> On Tue, 15 Nov 2016 13:21:21 +0100
>> Andrea Bolognani <abologna at redhat.com> wrote:
>>
>>> On Thu, 2016-10-06 at 10:34 -0400, Laine Stump wrote:
>>>>>> +    <video>
>>>>>> +      <model type='virtio' heads='1' primary='yes'/>
>>>>>> +      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/>
>>>>>   I was initially baffled by this, because I expected it to
>>>>> be assigned to one of the available pcie-root-ports just
>>>>> like all the other virtio devices.
>>>>>   However, according to qemuDomainValidateDevicePCISlotsQ35()
>>>>> this is intentional, so I guess we're good :)
>>>>   Actually, you bring up an interesting point in light of the "Should PCIe
>>>> devices ever be placed directly on pcie-root?" debate on qemu-devel (I
>>>> think it was in the thread about the PCI topology document that Marcel
>>>> is writing). We currently always put the primary video device at 00:1
>>>> just because "we always have", and it has the nice side effect of
>>>> eliminating the need for legacy-PCI controllers. But in this one case
>>>> the device is PCIe - to follow Marcel's recommendation of putting only
>>>> legacy devices on pcie-root, we should be putting the virtio video
>>>> device on a root-port.
>>>>   As I recall, Marcel and Alex were the most vocal on this subject, so I'm
>>>> Cc'ing them, with this bit of context - this patch auto-assigns the
>>>> addresses for virtio devices to be on Express ports rather than legacy
>>>> slots when appropriate, but there is a bit of Q35-specific code that
>>>> overrides any of that and always places the primary video device at
>>>> 00:01.0 - should we still do that for the primary video if it's virtio?
>>>> Or should we put it behind a root-port?
>>> I don't think we ever got a reply... Bump? :)
>> The primary reason you're putting the device under a pcie-root-port is
>> for hotplug, right?
>
> That, and to avoid having Express devices as integrated devices (which there was some discussion about on the qemu thread for Marcel's "PCIe devices placement guidelines" patch, and the conclusion was
> that we shouldn't put Express devices directly on the root complex (right?). On the other hand, as I pointed out in the mail I sent just before yours, I tried out a virtio-gpu device on the root
> complex, and it shows up as a legacy PCI device, not Express, so I guess that's not an issue.


Graphics card, sound cards are exceptions to the "rule".
Laszlo tried to make this point calling them "special purpose" devices
but was not clear enough.



>
>>    How many users care about hotplug of primary
>> video?  How many guest operating systems even support that?  I'd feel
>> pretty comfortable making the primary graphics non-hotpluggable by
>> default.  I actually lean towards making the user specify if they care
>> about hotplugging a device rather than assuming they do,
>
> I agree with that, but my patch to provide a means of specifying that in the XML was shot down, since it's seen as "libvirt dictating policy".
>
> And since it's less hostile to make hotplug a possibility (and then have it unused) than to make it impossible and then need it, when libvirt assigns addresses, we have to assume that the user *will*
> want it.
>
> There are a few exceptions, for various reasons:
>
> 1) devices that are unremovable (and unmovable) parts of the machinetype (for Q35 that's just the SATA controller)
> 2) primary and secondary USB2 controllers (because that's where the same device is on real Q35)
> 3) ich9 audio (again because that's where it is on real Q35, and because there is no Express audio device, so this is the only
>      way to have a "legacy-free" (i.e. no dmi-to-pci-bridge and no pci-bridge) guest with audio)
> 4) primary video (because... well, er, just *because*. Eat your vegetables!)
>
> Looking at it from afar, it all seems kind of arbitrary (or at least inconsistent) though...
>
>> seems like we
>> impose a lot of complexity on our configurations for something that
>> might actually be a niche feature.
>
> Yes. I keep saying "we're doing all this work to support hotplug by default for probably less than 1% of users", and yet we keep doing it...
>

My feelings got hurt :) - but I'll take 1% at any time!
Marcel




More information about the libvir-list mailing list