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

On 08/09/2016 09:11 AM, Andrea Bolognani wrote: 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. 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. 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). 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. 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...) 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.