Re: [PATCH v4 0/7] Use 1st-level for IOVA translation

From: Lu Baolu
Date: Fri Dec 20 2019 - 21:52:53 EST


Hi Yi,

Thanks for the comments.

On 12/20/19 7:50 PM, Liu, Yi L wrote:
Hi Baolu,

In a brief, this version is pretty good to me. However, I still want
to have the following checks to see if anything missed. Wish it
helps.

1) would using IOVA over FLPT default on?
My opinion is that before we have got gIOVA nested translation
done for passthru devices, we should make this feature as off.

No worry.

IOVA over first level is a sub-feature of scalable mode. Currently,
scalable mode is default off and we won't switch it on until all
features are done.


2) the domain->agaw is somehow calculated according to the
capabilities related to second level page table. As we are moving
IOVA to FLPT, I'd suggest to calculate domain->agaw with the
translation modes FLPT supports (e.g. 4 level and 5 level)

We merged first level and second level, hence the domain->agaw should be
selected for both. The only shortcoming of this is that it doesn't
support a 3-only second level in scalable mode. But I don't think we
have any chances to see such hardware.


3) Per VT-d spec, FLPT has canonical requirement to the input
addresses. So I'd suggest to add some enhance regards to it.
Please refer to chapter 3.6 :-).

Yes. Good catch! We should manipulate the page table entry according to
this requirement.


3.6 First-Level Translation
First-level translation restricts the input-address to a canonical address (i.e., address bits 63:N have
the same value as address bit [N-1], where N is 48-bits with 4-level paging and 57-bits with 5-level
paging). Requests subject to first-level translation by remapping hardware are subject to canonical
address checking as a pre-condition for first-level translation, and a violation is treated as a
translation-fault.

Regards,
Yi Liu

Best regards,
baolu