Re: RMRR device on non-Intel platform

[Jason Gunthorpe <jgg@nvidia.com>]

On Wed, Apr 26, 2023 at 02:53:53PM +0100, Robin Murphy wrote:

> Give QEMU a way to tell IOMMUFD to associate that 0x08080000 address with a
> given device as an MSI target. IOMMUFD then ensures that the S2 mapping
> exists from that IPA to the device's real ITS (I vaguely remember Eric had a
> patch to pre-populate an MSI cookie with specific pages, which may have been
> heading along those lines). 

This isn't the main problem - already for most cases iommufd makes it
so the ITS page is at 0x8000000. We can fix qemu to also use
0x8000000 in the ACPI - it already hardwires this for the RMRR part.

We can even make the kernel return the value so it isn't hardwired,
easy stuff..

> QEMU will presumably also need a way to pass the VA down to IOMMUFD when it
> sees the guest programming the MSI (possibly it could pass the IPA at the
> same time so we don't need a distinct step to set up S2 beforehand?) - once
> the underlying physical MSI configuration comes back from the PCI layer,
> that VA just needs to be dropped in to replace the original msi_msg address.

This is the main problem. What ioctl passes the VA, and how does it plumb
down into the irq_chip..

This is where everyone gets scared, I think. There is a thick mass of
IRQ plumbing and locking between those two points

And then it only solves MSI, not the bigger picture..

> TBH at that point it may be easier to just not have a cookie in the S2
> domain at all when nesting is enabled, and just let IOMMUFD make the ITS
> mappings directly for itself.

Yes, I'd like to get there so replace can work.

Jason