Messages in this thread | | | Date | Thu, 13 May 2021 10:47:28 -0300 | From | Jason Gunthorpe <> | Subject | Re: [PATCH V4 05/18] iommu/ioasid: Redefine IOASID set and allocation APIs |
| |
On Thu, May 13, 2021 at 04:01:20PM +1000, David Gibson wrote:
> But.. even if you're exposing page tables to userspace.. with hardware > that has explicit support for nesting you can probably expose the hw > tables directly which is great for the cases that works for. But > surely for older IOMMUs which don't do nesting you must have some way > of shadowing guest IO page tables to host IO page tables to translate > GPA to HPA at least?
I expect this would be in quemu and would be part of the expensive emulation I suggested. Converting the guest's page table structure into a sequence of map/unmaps to a non-nestable IOASID.
> If you're doing that, I don't see that converting page table format > is really any harder
It isn't, but it is a completely different flow and custom from the normal HW accelerated nesting.
> It might not be a theoretically complete emulation of the vIOMMU, but > it can support in-practice usage. In particular it works pretty well > if your backend has a nice big IOVA range (like x86 IOMMUS) but your > guest platform typically uses relatively small IOVA windows. PAPR on > x86 is exactly that... well.. possibly not the 64-bit window, but > because of old PAPR platforms that didn't support that, we can choose > not to advertise that and guests will cope.
So maybe this multi-window thing is generic API somehow. You'll have to check what Kevin comes up with to ensure it fits in
Jason
| |