[Bug 202055] Failed to PCI passthrough SSD with SMI SM2262 controller.

[bugzilla-daemon@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=202055

--- Comment #43 from LimeTech (tomm@lime-technology.com) ---
(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.