On 7/5/26 17:16, Alexey Kardashevskiy wrote:
On 6/5/26 23:16, Jason Gunthorpe wrote:
On Wed, May 06, 2026 at 12:35:42PM +1000, Alexey Kardashevskiy wrote:
Hi!
Let's reignite this topic.
I've been using these patches + QEMU side hacks for 6+ months. And it's been
fine until I got a device where MSIX BAR is in a middle of another BAR marked
as TEE in the TDISP interface report. And no trusted MSIX yet.
Every time QEMU mmaps a BAR - I request a dmabuf fd from VFIO in QEMU. Since
mapping of an entire MSIX BAR is allowed by default, VFIORegion::nr_mmaps==1
and it is an entire BAR.
Problem: KVM memslot mismatches the dmabuf fd size
Huh? kvm does not care about dmabuf at all? Are you running other
patches to hook kvm and dmabuf?
yup, 06/12 of this patchset.
Putting a slice in a dmabuf is a well understood need for MSI, so I
expect whatever kvm dmabuf interface that gets merged to accomodate
this?
good to know.
Solution2: modify logic in VFIO dmabuf to allow multiple KVM memory
slots per dmabuf. Now it is kvm_memory_slot::dmabuf_attach with no
offset into the dmabuf and one kvm_vfio_dmabuf per dma_buf.
Yes, when kvm learns to take in a dmabuf it needs to take in a slice,
not the whole buf. Or you need to create multiple dmabufs with the
necessary slices from the VFIO. The upstream vfio dmabuf creation
allows creating it with a slice.
true but either way dmabuf slicing will be directed by QEMU's msix-table emulation MR and this slicing needs to match the TDISP report so I'll have to teach QEMU these reports, right?
Or TDISP devices are going to align MSIX BARs to 4K, and QEMU will do the same and it
should "just work", and if it does not - the host won't crash. Can this work?
Thanks,
I am worried if I miss something obvious, again. Thanks,
ps. I like nntp.lore.kernel.org very much for ability to dig out old stuff and
then just reply to it :)
Jason
--
Alexey
