Re: [RFC PATCH 6/6] iommu/amd: Introduce nested translation support

From: Suthikulpanit, Suravee
Date: Mon Jan 08 2024 - 01:50:15 EST




On 1/5/2024 9:37 PM, Jason Gunthorpe wrote:
On Fri, Jan 05, 2024 at 08:39:52PM +0700, Suthikulpanit, Suravee wrote:
Hi Kevin,

On 12/15/2023 2:45 PM, Tian, Kevin wrote:
From: Suravee Suthikulpanit <suravee.suthikulpanit@xxxxxxx>
Sent: Wednesday, December 13, 2023 12:02 AM

To support nested translation on AMD IOMMU, the driver needs to
program DTE[GCR3 Table Root Pointer] with the address provided by
the guest via struct iommu_hwpt_amd_v2, which is passed as a parameter
of the struct iommu_ops.domain_alloc_user() with the flag
IOMMU_HWPT_ALLOC_NEST_PARENT.

Note that current implementation only support GCR3TRPMode for
nested translation, which uses GPA to program GCR3 Table Root Pointer.


means there is a plan to support another mode in the future or
actually the nested translation requires GCR3TRPMode as a
functional requirement? imho the point of GPA is assumed
in the nested configuration in concept...

On (older) system, which does not support GCR3TRPMode, the IOMMU driver
needs to program the device's DTE[GCR3 Table Root Pointer] field w/ SPA.

Meaning that on older systems the GCR3 Table Root Pointer is not
translated by the parent v1 page table?

Correct.

When QEMU presents an AMD vIOMMU device to a guest, the guest programs the
guest DTE[GCR3 Table Root Pointer] with GPA. Then we need to :
1. Traps the DTE write
2. Translate the GPA->SPA
3. Program DTE with SPA.

With the GCR3TRPMode, we can skip step 2 above and directly program step 3
with GPA.

Do you want to support this? It will be hard to do because it is not
just those three steps (which are easy) but that you have to somehow
maintain coherence with any changes to the parent page table, so you
have to hook the iommu_domain unmap as well...

I'm debating this. Let me get back on this part.

Thanks,
Suravee