Messages in this thread |  | | Subject | Re: [PATCH v4 0/7] Use 1st-level for IOVA translation | | From | Lu Baolu <> | | Date | Sat, 21 Dec 2019 10:51:38 +0800 |
| |
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
|  |