https://bugzilla.kernel.org/show_bug.cgi?id=202055 --- Comment #42 from Alex Williamson (alex.williamson@xxxxxxxxxx) --- It seems there's a partial workaround available since QEMU v2.12 hiding under our noses. That version adds support for relocating the MSI-X vector table on vfio-pci devices, which recreates the MSI-X MMIO space elsewhere on the device. A side-effect of this is that the vector table and PBA are properly sized so as not to collide. The size of the tables remains wrong, but this only becomes a problem if the nvme code attempts to allocate >16 vectors, which requires >15 vCPU (or host CPUs if the device is returned to host drivers after being assigned)(nvme appears to allocate 1 admin queue, plus a queue per CPU, each making use of an IRQ vector). The QEMU vfio-pci device option is x-msix-relocation= which allows specifying the bar to use for the MSI-X tables, ex. bar0...bar5. Since this device uses a 64bit bar0, we can either extend that BAR or choose another, excluding bar1, which is consumed by the upper half of bar0. For instance, I tested with: <domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'> ... <hostdev mode='subsystem' type='pci' managed='yes'> <source> <address domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </source> <alias name='ua-sm2262'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/> </hostdev> ... <qemu:commandline> <qemu:arg value='-set'/> <qemu:arg value='device.ua-sm2262.x-msix-relocation=bar2'/> </qemu:commandline> (NB: "ua-" is a required prefix when specifying an alias) A new virtual BAR appears in the guest hosting the MSI-X table and QEMU starts normally so long as the guest doesn't exceed 15 vCPUs. The vCPU/pCPU count limitations are obviously not ideal, but hopefully this provides some degree of workaround for typical configurations. -- You are receiving this mail because: You are watching the assignee of the bug.
