[PATCH umr] Skip ahead if PDE entry is actually a PTE entry. (v2)

Christian König christian.koenig at amd.com
Mon Nov 6 18:47:49 UTC 2017

Am 06.11.2017 um 19:39 schrieb Tom St Denis:
> On 06/11/17 01:34 PM, Christian König wrote:
>> Am 06.11.2017 um 19:28 schrieb Tom St Denis:
>>> On 06/11/17 05:01 AM, Christian König wrote:
>>>> Am 04.11.2017 um 18:15 schrieb Tom St Denis:
>>>>> Signed-off-by: Tom St Denis <tom.stdenis at amd.com>
>>>> Still not perfect, but good enough for now. Patch is Tested-by: 
>>>> Christian König <christian.koenig at amd.com>.
>>>> I think you need to rework the VM walking a bit, cause we need to 
>>>> support the T bit as well in the future and your code make a few 
>>>> assumptions which doesn't allow that.
>>> Doesn't the T bit imply V=0 which means the page isn't backed by 
>>> memory.  Not much umr could do about that other than to print out 
>>> the T bit.
>> No, the T bit means translate further. In other words it is the 
>> counter part of the P bit and means that a PTE should be handled as a 
>> PDE.
>> But for this to have meaning you also need to handle the fragment 
>> size as well (Now I have you totally confused, haven't I? :).
> Yes :-)
> I thought fragment size was more for hinting to the cache controller 
> and not actually part of the VM decoding.

Correct, our hardware devs are unfortunately using the same name for two 
different things.

The fragment size in the PTE means what you described above and controls 
the L1 TLB settings.

The fragment size in the PDE controls how big the PTE entries will be.

So with the default fragment size of zero in the PDE we have 512 PTEs 
resulting in a 4K page table.

> Also the PI docs say T => "Tiled (PRT)" and from what I gather that 
> just means the page is valid but might not be backed so instead of 
> raising a page fault you raise a new fault that the application (?) 
> handles accordingly.
> There's an 'F' bit that is labeled "translate further".
> Reading section 8 of said document seems to indicate you're confusing 
> bits F and T or my doc is wildly out of date (or we're talking about 
> different IP revisions)

Sorry my fault. I was just confusing the F and T bits.


> Tom

More information about the amd-gfx mailing list