[lkml]   [2019]   [Sep]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC PATCH 2/4] iommu/vt-d: Add first level page table interfaces
Hi Kevin,

On 9/25/19 3:32 PM, Tian, Kevin wrote:
>> From: Lu Baolu []
>> Sent: Wednesday, September 25, 2019 2:52 PM
>> Hi Peter and Kevin,
>> On 9/25/19 1:24 PM, Peter Xu wrote:
>>> On Wed, Sep 25, 2019 at 04:38:31AM +0000, Tian, Kevin wrote:
>>>>> From: Peter Xu []
>>>>> Sent: Wednesday, September 25, 2019 12:31 PM
>>>>> On Tue, Sep 24, 2019 at 09:38:53AM +0800, Lu Baolu wrote:
>>>>>>>> intel_mmmap_range(domain, addr, end, phys_addr, prot)
>>>>>>> Maybe think of a different name..? mmmap seems a bit weird :-)
>>>>>> Yes. I don't like it either. I've thought about it and haven't
>>>>>> figured out a satisfied one. Do you have any suggestions?
>>>>> How about at least split the word using "_"? Like "mm_map", then
>>>>> apply it to all the "mmm*" prefixes. Otherwise it'll be easily
>>>>> misread as mmap() which is totally irrelevant to this...
>>>> what is the point of keeping 'mm' here? replace it with 'iommu'?
>>> I'm not sure of what Baolu thought, but to me "mm" makes sense itself
>>> to identify this from real IOMMU page tables (because IIUC these will
>>> be MMU page tables). We can come up with better names, but IMHO
>>> "iommu" can be a bit misleading to let people refer to the 2nd level
>>> page table.
>> "mm" represents a CPU (first level) page table;
>> vs.
>> "io" represents an IOMMU (second level) page table.
> IOMMU first level is not equivalent to CPU page table, though you can
> use the latter as the first level (e.g. in SVA). Especially here you are
> making IOVA->GPA as the first level, which is not CPU page table.
> btw both levels are for "io" i.e. DMA purposes from VT-d p.o.v. They
> are just hierarchical structures implemented by VT-d, with slightly
> different format. The specification doesn't limit how you use them for.
> In a hypothetical case, an IOMMU may implement exactly same CPU-page-
> table format and support page faults for both levels. Then you can even
> link the CPU page table to the 2nd level for sure.

Fair enough. A good conceptual gap fix.

> Maybe we just name it from VT-d context, e.g. intel_map_first_level_range,
> Intel_map_second_level_range, and then register them as dmar domain
> callback as you replied in another mail.

Yes. Make sense.

> Thanks
> Kevin

Best regards,

 \ /
  Last update: 2019-09-26 03:45    [W:0.085 / U:26.640 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site