On Tue, Sep 15, 2026 at 05:36:16PM +0200, Cédric Le Goater wrote: > On 9/15/26 16:22, Michael S. Tsirkin wrote: > > On Tue, Sep 15, 2026 at 12:17:31PM +0100, David Vrabel wrote: > > > On 15/09/2026 11:01, Michael S. Tsirkin wrote: > > > > > > > > On Tue, Sep 15, 2026 at 09:25:05AM +0200, Cédric Le Goater wrote: > > > > > Hello, > > > > > > > > > > The xio3130-downstream and x3130-upstream devices lacks x-speed and > > > > > x-width device properties, making it impossible to configure PCIe link > > > > > speed/width when building PIX switch topologies for GPU/NIC > > > > > passthrough. > > > > > > > > > > Fix that and preserve migration compatibility with a 2.5GT/s x1 > > > > > default. > > > > > > > > > > Thanks, > > > > > > > > > > C. > > > > > > > > Given they are clearly intended for users, time to rename to width/speed > > > > everywhere? > > > > > > A more comprehensive series (hw/pci-bridge: Configurable apparent > > > bandwidth > > > for the PCIe topology) is here: > > > > > > https://patchew.org/QEMU/[email protected]/ > > > > > > This adds new upstream and switch port devices with configurable > > > speed/width > > > and renames the options so they are non-experimental (but do not the open > > > question about the usability of the speed option with the need to set 2.5 > > > GT/s as the string "2_5"). > > > > > > I did consider adding options to the XIO3130 device but since the real > > > hardware is Gen 1 only and does not support speeds/widths other > > > 2.5GT/s/1x I > > > didn't consider it appropriate to claim these emulated ports are more > > > capable than the real hardware. > > > > > > David > > > > Right that makes more sense to me. Cédric what do you think? > > I didn't know about it. > > Regarding HW accuracy, I agree XIO3130 being Gen 1, the new speed > and link are inaccurate and this could confuse some tools checking > vendor/device ID. > > Regarding the code size, user facing changes, existing topology, > migration, etc, boosting XIO3130 capabilities is safer. What is > worrisome is the downstream impact. backports will be a problem. > That said I didn't check. > > David's proposal is preferable, as the device doesn't pretend > to be real HW and should be pursued for upstream. Mine would be > more a fallback solution for downstream. Hopefully not, > > Cheers, > > C.
I don't know what the big deal is. new hardware is easy to add to libvirt. I just coded it up quickly it's like 30LOC, excluding tests. Pls check that option. -- MST
