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: <200804071404.28691.jbarnes@virtuousgeek.org>
Date:	Mon, 7 Apr 2008 14:04:28 -0700
From:	Jesse Barnes <jbarnes@...tuousgeek.org>
To:	Thomas Hellström <thomas@...gstengraphics.com>
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

On Monday, April 07, 2008 1:46 pm Thomas Hellström wrote:
> > 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.

Ah, you actually want to *read* from memory?  Yeah that would be really slow 
if we left it UC or WC.  But I thought that was really only necessary for 
relocation, and keithp dealt with that with the "presumed offset" stuff?  Are 
you seeing other cases where we need to read back frequently?

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

Yeah, ioremap_wc is probably the best thing to use in the DRM.  And in AGP 
we'll need to clarify things more, since some drivers can do cacheable 
memory, some want UC, etc.

Thanks,
Jesse
--
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/