On 11/15/2016 12:44 PM, Alex Williamson wrote:
On Tue, 15 Nov 2016 13:21:21 +0100
Andrea Bolognani <abologna@xxxxxxxxxx> 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...
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list