Re: how hotplug devices onto pcie-to-pci-bridge

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 11/6/22 3:28 AM, longguang.yue wrote:
Hi, Laine Stump and Oleg Vasilev:
1.  Laine, what is 'conventional PCI device'? in my case they are all virtio device.

A "conventional PCI" device is one that is designed to work with the original PCI spec, i.e. before PCI Express. Among other differences, they lack a PCIe capabilities section in their config data.

All virtio devices are PCI Express devices or conventional PCI, depending on the type of slot they are plugged into (that's my understanding of it anyway). Most other devices are always just one or the other.

On real hardware, a PCIe device could never be plugged into a conventional PCI slot, nor could a conventional PCI device be plugged into a PCIe slot. QEMU allows this though, and just kind of glosses over the rough spots. It can lead to problems though, e.g. the PCIe extended capabilities space is not visible and so things like bus width/speed are not communicated properly to the guest OS (and can't be changed).

2. Followed your guide,succeed in hotplug.  but there are lots of problems after hotplug. I think problems are more related to qemu.   2.1) disk devices(qcow2,virio) hotpluged onto pci-bridge can not alloc bar resource.

When you plug a virtio device into a conventional PCI slot, it uses the older (pre-virtio-1.0) method of host<->device communication, which memory-maps a region. However, if a pci-bridge has no devices plugged into it when the guest is started, then the BIOS won't reserve space for this memory-mapped region (or something like that - I never retain details). Because it's using the older conventional PCI virtio that requires this region to be mapped for proper operation, it fails.

  2.2) disk devices(qcow2,virio) are staticly pluged to pci-bridge can not be found by guest os.          those devices are on pci bus, but can not be recognized by guest os, no block device are probed.

No idea about that.

But in general it's correct that this isn't anything libvirt can easily fix.

Rather than trying to make hotplug to a pcie-to-pci-bridge work, the *proper* fix is to just allow the virtio devices to be hotplugged to pcie-root-ports, which is what libvirt would do by default. Then they will be recognized as virtio-1.0 devices and use a mode that doesn't require any memory to be mapped for them.


qemu qemu-6.2.0
-----hotplug error message--------
[ 1067.577384] pci 0000:06:02.0: [1af4:1001] type 00 class 0x010000
[ 1067.578312] pci 0000:06:02.0: reg 0x10: [io 0x0000-0x007f]
[ 1067.578794] pci 0000:06:02.0: reg 0x14: [mem 0x00000000-0x00000fff]
[ 1067.579419] pci 0000:06:02.0: reg 0x20: [mem 0x00000000-0x00003fff 64bit pref] [ 1067.581592] pci 0000:06:02.0: BAR 4: no space for [mem size 0x00004000 64bit pref] [ 1067.581942] pci 0000:06:02.0: BAR 4: failed to assign [mem size 0x00004000 64bit pref]
[ 1067.582264] pci 0000:06:02.0: BAR 1: no space for [mem size 0x00001000]
[ 1067.582625] pci 0000:06:02.0: BAR 1: failed to assign [mem size 0x00001000]
[ 1067.582942] pci 0000:06:02.0: BAR 0: no space for [io size 0x0080]
[ 1067.583253] pci 0000:06:02.0: BAR 0: failed to assign [io size 0x0080]
[ 1067.584019] PCI Interrupt Link [GSIE] enabled at IRQ 20
[ 1067.584749] virtio-pci 0000:06:02.0: virtio_pci: leaving for legacy driver
[ 1067.585296] virtio-pci: probe of 0000:06:02.0 failed with error -12

-------staticly plug------------
[ 0.680299] pci 0000:06:02.0: [1af4:1001] type 00 class 0x010000
[ 0.683035] pci 0000:06:02.0: reg 0x10: [io 0xc080-0xc0ff]
[ 0.688036] pci 0000:06:02.0: reg 0x14: [mem 0xfca01000-0xfca01fff]
[ 0.700040] pci 0000:06:02.0: reg 0x20: [mem 0xfb404000-0xfb407fff 64bit pref]

--------------------------------------



At 2022-11-04 05:28:47, "Laine Stump" <laine@xxxxxxxxx> wrote:
On 11/3/22 6:35 AM, longguang.yue wrote:
Hi, all
  I have add two pcie-to-pci-bridge controllers, how hotplug devices onto this two controllers?  and libvirt knows to plug onto pci-bridge when there are no pcie-ports.
defaultly libvirt plugs devices onto pcie-port.

Do you mean you want hotplugged devices to be placed on the pcie-to-pci-bridge even though there are unused pci-root-ports?

You can force a new device to be hotplugged to a particular slot of a particular controller by including the <address> element in the XML of the device you attach - whatever controller/slot/function you specify there is what libvirt will use (practically speaking the function must be 0).

My recollection is that, *if the device is a conventional PCI device (and not a PCIe device) then libvirt will anyway attempt to find a an open conventional PCI slot, which would be found only on the pcie-to-pci-bridge. However, very few devices are actually conventional PCI, so this will very rarely happen automatically (I haven't looked at that code in a long time, and retain no specific memory, but I think the only emulated device that is conventional PCI is a watchdog device or something)

So, if libvirt is selecting a pcie-root-port to plug in a device, that's because the device is a PCIe device. If you want to force it to do otherwise, you'll need to manually specify the address (just set "bus" of the address to the "index" of the controller, set "slot" to an unoccupied slot (1-31), and set domain and function to 0).





[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux