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
signature.asc
Description: PGP signature
