Dealing with SIOV/IMS

["Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>]

[-- Attachment #1: Type: text/plain, Size: 1396 bytes --]

Hi,

I've got yet another report[1] of device failing because (I assume) the
drivers reads MSI/MSI-X values (thinking it sees values actually set in
the HW) and then pass them to the device via some alternative means.
IIUC this is what IMS does.

I'm interested in two things:
1. Some plan for a long term solution - it was briefly discussed on
XenDevel matrix room in September, Roger said:

> urg, that's the spec that also defines IMS IIRC?  I think the only way
> to support anything like that is using vfio/mdev and re-using the
> drivers from Linux.  There's too much device-specific magic to
> implement any of this in Xen, or do our own Xen-specific drivers.

2. A short term workaround for few specific devices. If you look at the
linked threads, users resort to patching the domU driver and then
copying MSI values from dom0's lspci output manually... I think we can
do better than this short term, via some quirks in QEMU. Either let the
domU see the real HW values, or translate IMS writes at QEMU level
(assuming they can be identified). Disclaimer - I haven't looked yet at
this specific driver, nor the SIOV/IMS spec, so I'm not sure if that's
viable approach...

[1] https://forum.qubes-os.org/t/solved-qualcomm-qcnfa765-ath11k-wcn6855-wifi-working-on-thinkpad-p14s-gen4-amd/38192

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]