linux-kernel - Re: [Intel-gfx] Usage of _PAGE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <53F18FCE.7060005@suse.com>
Date:	Mon, 18 Aug 2014 07:31:58 +0200
From:	Juergen Gross <jgross@...e.com>
To:	Ville Syrjälä <ville.syrjala@...ux.intel.com>
CC:	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Daniel Vetter <daniel.vetter@...ll.ch>,
	intel-gfx <intel-gfx@...ts.freedesktop.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Ben Widawsky <benjamin.widawsky@...el.com>
Subject: Re: [Intel-gfx] Usage of _PAGE_PCD et al in i915 driver

On 08/15/2014 12:21 PM, Ville Syrjälä wrote:
> On Thu, Aug 14, 2014 at 05:55:11AM +0200, Juergen Gross wrote:
>> On 08/13/2014 05:07 PM, Jesse Barnes wrote:
>>> On Fri, 8 Aug 2014 15:14:15 +0200
>>> Daniel Vetter <daniel.vetter@...ll.ch> wrote:
>>>
>>>> Adding relevant mailing lists.
>>>>
>>>> On Fri, Aug 8, 2014 at 1:23 PM, Juergen Gross <jgross@...e.com> wrote:
>>>>> I'm just about to create a patch for full PAT support in the Linux
>>>>> kernel, including Xen. For this purpose I introduce a translation
>>>>> between cache modes and pte bits.
>>>>>
>>>>> Scanning the kernel sources for usage of the cache mode bits in the
>>>>> pte I discovered  drivers/gpu/drm/i915/i915_gem_gtt.h is using
>>>>> _PAGE_PCD, _PAGE_PWT and _PAGE_PAT. I think those defines are used
>>>>> to create ptes not for usage by the main processor, but for the
>>>>> graphics processor. Is this true? In this case I'd suggest to define
>>>>> i915-specific macros instead of using the x86 ones.
>>>>
>>>> Yeah, those are gpu specific PAT tables, but the hw engineers
>>>> specifically designed this to match, and we've tried to follow the cpu
>>>> side to match it. Especially in the future that will be somewhat
>>>> important, since we want to fully share the entire address space
>>>> between cpu and gpu on the next platform. Jesse is working on that.
>>>
>>> Right, we have an x86 compatible MMU in the GPU itself, so re-using the
>>> defines makes sense.  I suppose with your work you'll move them and
>>> make them a bit more opaque?  If so, we'll still want a way to get at
>>> them directly, or access your mapping functions for generating PTE bits
>>> for the GPU MMU.
>>
>> Using the mapping functions I'm introducing should work, if the MMU has
>> an x86 compatible MSR_IA32_CR_PAT which is configured the same way as
>> on the x86 processor (be aware that Xen is using another MSR_IA32_CR_PAT
>> setting as the Linux kernel).
>
> We have a PAT that is structured the same way as the x86 PAT. But the
> contents of the PAT entries are obviously specific to the GPU so it's
> not identical. But the pcd/pwt/pat bits index the PAT in exactly the
> same way as on x86.
>
> See bdw_setup_private_ppat() and chv_setup_private_ppat() for how we
> set up the PAT.
>

So you are using the PAT bit in the ptes, but the semantic for the GPU
will be different as for the x86 processor, because the GPU PAT is set
up differently from the x86 one.

In case you are sharing ptes between GPU and x86 processor in future,
this might lead to problems when the x86 processor will use ptes with
the PAT bit set.


Juergen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/