https://bugzilla.kernel.org/show_bug.cgi?id=202055 --- Comment #43 from LimeTech (tomm@xxxxxxxxxxxxxxxxxxx) --- (In reply to Alex Williamson from comment #42) > 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. Hi Alex, are you saying the above coding in the VM xml is all that is necessary (with noted vCPU/pCPU count limitations) to successfully pass-through sm2262-based controllers, without above kernel patch? Or is a kernel patch also necessary (if so, which one)? thx, -tom -- You are receiving this mail because: You are watching the assignee of the bug.
