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

[Laine Stump]

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.

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