[libvirt] [PATCH 0/6] Use more PCIe, less legacy PCI slots

Wed Aug 10 04:32:59 UTC 2016

On 08/09/2016 09:11 AM, Andrea Bolognani wrote:
> On Mon, 2016-08-08 at 04:56 -0400, Laine Stump wrote:
>> These patches use three methods to get more of the PCI devices onto PCIe
>> slots on Q35 and aarch64/virt machinetypes:
>>   
>> 1) When virtio devices can present themselves as PCIe if they're
>>      plugged into a PCIe controller, do that. (This capability is
>>      detected by looking for presence of the "disable-modern" option on
>>      the virtio-net device. If you have a better idea for how to detect
>>      it, please let me know.)
> How does this play along with Ján's series[1] implementing a
> way to control the protocol revision for virtio devices?

It doesn't, because those patches haven't been pushed yet. But it 
doesn't conflict either (except that Jan and I are both checking for 
essentially the same epoch difference in virtio by looking at different 
options - he looks for "disable-legacy" in any virtio device, while I 
look for "disable-modern" in virtio-net).

Note that setting disable-modern/disable-legacy does *not* necessarily 
do what you think, and we don't want to always have to set virtio 
revision='1.0' in order to get a PCIe device, nor do we want all PCIe 
devices to be revision 1.0-only. There is a case for having 
disable-modern=off,disable-legacy=off even for a device installed on a 
PCIe slot (it's compatible with old guest drivers, but new guest drivers 
can take advantage of virtio 1.0, and it is legacy-PCI-free. On the 
other hand, it requires the PCIe controller to reserve IO port space, 
which we try to avoid.)

For example, I just tried every combination of:

disable-modern=off,disable-legacy=off (i.e. "all versions")
disable-modern=on,disable-legacy=off ("0.9")
disable-modern=off,disable-legacy=on ("1.0")

with these three types of slots:

    pcie-root  (PCIe root complex "integrated" device)
    pcie-root-port (pcie)
    pci-bridge  (legacy PCI)

I found that setting "1.0" doesn't force the device to be PCIe - if it's 
on either pci-bridge or pcie-root, it will still be properly advertised 
as a PCI device (the "Express Device" capability has been removed from 
the PCI capabilities data). The difference is that it will no longer 
request/require IO port space, and the device ID changes from 1af4:1000 
to 1af4:1041. So there is no problem with putting a device with 
revision='1.0' into a legacy PCI slot.

Setting 0.9 *does* force the device to be a PCI device even if it's 
plugged into a PCIe slot - the "Express is removed from the PCI 
capabilities. So definitely if 0.9 is set in order to disable 
virtio-1.0, we should not put it in a PCIe slot. This leads to the 
conclusion that any guest OS on Q35 that doesn't have virtio-1.0 drivers 
will require one of the following:

1) require that we can force both disables to OFF (that's the only way 
to get a true PCIe device that supports virtio-0.9) (NB: starting with 
qemu-2.7.0, the default for virtio devices plugged into a pcie-*-port 
slot will be "disable-legacy=on" (in order to conserve IO port space), 
and the only way for us to set disable-legacy=off will be to force 
virtio-0.9, i.e. there will be *no method* of getting a PCIe device that 
supports old virtio.)

2) live with having a dmi-to-pci-bridge and pci-bridge so that we'll 
have a proper place to plug in an 0.9-only device.

3) provide a simple way to force the 0.9-only virtio device onto 
pcie-root (pcie.0) (but of course that doesn't support hotplug...)

Anyway, back to the topic - we *don't* want to be using the virtio 
revision setting to force PCI vs. PCIe (or think that we have to set it 
in order to get one or the other); the only information we can take from 
that setting to aid us in the PCI/PCIe decision is that when 0.9 is set, 
we definitely can't put the device on a PCIe slot; otherwise, it can be 
put on either type of slot and it will work correctly.

>
> IIUC, you wouldn't set disable-modern=off or disable-legacy=on
> explicitly, but rely instead on the fact that a mixed-mode
> virtio device will present itself as PCIe if plugged into a
> PCIe slot. Is that right?

I don't set anything. I pay attention to the default behavior of a 
virtio device with no disable-* options set, because I'm working with 
code that has no way of setting those options.

>
> I think we should alter the connect flags for virtio devices
> based on the protocol revision, as decided by the user with
> either Ján's or a comparable approach, rather than using PCIe
> automatically if available.

See above. The only thing we can change in the connect flags based on 
virtio version is to turn off PCI_ENDPOINT if it's set to 0.9. And we 
certainly don't want to force anyone to set 1.0-only just to get their 
device on a PCIe slot (nor do we want to require PCIe for someone who 
does set 1.0-only).

> At the very least, the current approaches don't mix - if both
> your series and Ján's were to be merged now, a device that has
> been configured to use virtio 0.9 would end up assigned to a
> PCIe slot.

The only reason they don't appear to mix is because Jan's patches don't 
account for mine, and my patches don't account for his, because none of 
them are pushed yet. There's no intrinsic reason why they couldn't 
though. And as a matter of fact I applied my patches on top of his, and 
their logic doesn't conflict in any way (there were trivial merge 
problems due to both of us defining new qemu capabilities). As I've 
mentioned elsewhere (and you also suggest), the CONNECT setting should 
be modified to turn off PCIE_ENDPOINT and turn on PCI_ENDPOINT when 
0.9-only is selected.

>> 2) Any devices that aren't hotpluggable anyway will no longer request
>>      a hotplug-capable slot. This, along with a change to auto-assign
>>      legacy PCI devices to pcie-root (as long as they don't require
>>      hotplug) means the devices will now be assigned to pcie-root.
>>   
>> 3) Also using the fact that devices that won't be hotplugged can be
>>      assigned to pcie-root, the devices that *do* support hotplug have a
>>      new optional subelement "<hotplug require='no'/>" (it defaults to
>>      "yes" for historical reasons). If hotplug require is set to 'no',
>>      even a PCI device can be auto-assigned to pcie-root.
>>   
>> I haven't yet removed the dmi-to-pci-bridge that is added by default,
>> and we still will only auto-add pci-bridge (so if you're adding a
>> virtio device without <hostplug require='no'/> then you will also need
>> to add a <controller type='pci' model='pcie-root-port'/> to plug it
>> into).
> I don't get any dmi-to-pci-bridge on aarch64 virt guests,
> which is good because we don't want it at the moment :)

Yes, because you've already removed it, in the way that I want to remove 
it from Q35. (but because Q35 guests are more likely to need a PCI-only 
device than aarch64 guests, I can't really do that until I've updated 
the "auto-create more slots" code to create a dmi-to-pci-bridge when 
necessary.

(Hmm, but here's a problem - if there aren't currently any legacy PCI 
devices in a config (and thus no dmi-to-pci-bridge or pci-bridge), and 
someone decides to hotplug a legacy-PCI device, *then* what do you do? I 
don't want to have these legacy controllers in *every damn config in the 
world* just in case some moro... er "well meaning user" thinks they want 
to hotplug an rtl_8139 emulated ethernet...)

>
> But it doesn't get auto-added either, not even when it would
> be required because I'm trying to add a legacy PCI device. So
> yeah, more work needed there I guess.

Yep, the only kind of controller we know how to auto-add is pci-bridge.

Okay, I'm done. Finished. Kaput. Fini. Bittim, tükendim. Time for bed.