Re: [RFC PATCH 04/12] vfio/pci: Allow MMIO regions to be exported through dma-buf

[Alexey Kardashevskiy <aik@amd.com>]

On 12/5/26 09:56, Jason Gunthorpe wrote:
> On Tue, May 12, 2026 at 09:42:01AM +1000, Alexey Kardashevskiy wrote:
> 
>>> 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,
> 
> Host crashing stuff is a different issue, I think the plan was to
> revoke the entire MMIO space from userspace and remove it from the
> kernel mapping. Entire because we don't want to parse the TDISP report
> to figure out something more narrow.
> 
> Therefore there is no way the host can crash.

Ah ok.

> When qemu constructs the VM memory map it already has a scheme to
> insert a hole for a SW emulated page for MSI. That will keep working
> exactly as it is.
>
> When the VM validates the MMIO the hole has to fall within a T=0 space
> of the TDISP report or the VM will reject it.
> 
> This means devices need to have a T=0 hole around their MSI-X/etc
> suitable for a 64K page size OS.

Since we are ditching mappings, the entire MSIX-containing 64K block will be ioctl()ed instead of directly accessed from QEMU via mmap (which is slower the VM direct access but still)?

> This is already the case, if a device mixes MSIx with other things
> qemu will work but it becomes horribly slow and a little broken.

Really only when MSIX is not system page size aligned but yeah, I had enough of that with PPC. Thanks,

> 
> Jason

-- 
Alexey