linux-kernel - Re: [PATCH] x86: create array based interface to change page attribute

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: <47FA8826.2060802@tungstengraphics.com>
Date:	Mon, 07 Apr 2008 22:46:30 +0200
From:	Thomas Hellström <thomas@...gstengraphics.com>
To:	Jesse Barnes <jbarnes@...tuousgeek.org>
CC:	Arjan van de Ven <arjan@...ux.intel.com>,
	Andi Kleen <andi@...stfloor.org>,
	Dave Airlie <airlied@...hat.com>, linux-kernel@...r.kernel.org,
	tglx@...utronix.de, mingo@...hat.com
Subject: Re: [PATCH] x86: create array based interface to change page attribute

Jesse Barnes wrote:
> On Monday, April 07, 2008 12:51 pm Thomas Hellström wrote:
>   
>>> Hopefully the WC stuff will be upstream right after 2.6.25 comes out. 
>>> Any reason why we shouldn't keep the pages mapped in the kernel as WC
>>> assuming the interface is there?
>>>       
>> If the pages are unmapped, we can get reasonable speed doing
>> unbind-read-bind operations, kernel accesses to the memory will need to
>> use an iomap_atomic_prot_pfn() type of operation.
>> No IPI global tlb flushes needed for kernel mapping changes during
>> unbind-read-bind and no cache flushes needed either if we write-protect
>> the user-space mappings properly, or very limited cache flushes if we
>> keep dirty-written-while-cached flags for each page.
>>
>> If the pages are wc-d we'll need two extra IPI global tlb flushes and a
>> buffer-size cache flush every time we do unbind-read-bind, but OTOH we
>> don't need the iomap_atomic_prot_pfn() to access single pages from the
>> kernel.
>>     
>
> Why would we need to flush at all at unbind-read-bind time?  We should be able 
> to leave pages in the WC state even when we unbind them, then when we need to 
> bind them back into the GTT they'll be ready, but maybe I'm misunderstanding 
> you here...
>
>   
We want to make the user-space mapping cache-coherent after unbind 
during read, to have any serious read-speed, and the linear kernel map 
has to follow, unless it's non-present. Even if it's non present, we 
need to flush whatever was written through the user-space mapping from 
the cache when rebinding. Having the user-space mapping read-only when 
possible will help avoid this.
>>> Also, to make the API readable, we'd probably want to split the function
>>> into kernel_map_pages(..., enum memory_type type) and
>>> kernel_unmap_pages(...) (though like I said I think we really should be
>>> mapping them WC not umapping them altogether, since we do want to hit the
>>> ring buffer from the kernel with the WC type for example).
>>>       
>> I think ring-buffers are using ioremap() or vmap() already today. We can
>> use these to get WC-type access also in the future. The only time we use
>> the linear kernel mapping today is for single page access while patching
>> up command buffers.
>>     
>
> Yeah, they're ioremapped now, but that's a problem since with the PAT patches 
> they'll be mapped hard UC (right now it just happens to work).
>   
Ouch, so we'll be needing an ioremap_wc(), I guess. We probably 
shouldn't use the linear kernel map for this anyway, since that would 
require a chipset flush for each ring commit.  We can actually use 
vmap() with a wc page protection for that, but an ioremap_wc() would 
certainly save us a lot of trouble.
> Thanks,
> Jesse
>   
/Thomas




--
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/