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
