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 <abolo...@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
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
