linux-kernel - RE: [PATCH] X86: fix typo PAT to X86

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] [day] [month] [year] [list]

Message-ID: <924EFEDD5F540B4284297C4DC59F3DEE62C219@orsmsx423.amr.corp.intel.com>
Date:	Tue, 22 Jan 2008 10:26:10 -0800
From:	"Pallipadi, Venkatesh" <venkatesh.pallipadi@...el.com>
To:	"Dave Jones" <davej@...hat.com>, "Ingo Molnar" <mingo@...e.hu>
Cc:	"Yinghai Lu" <Yinghai.Lu@....COM>,
	"LKML" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] X86: fix typo PAT to X86_PAT

 

>-----Original Message-----
>From: Dave Jones [mailto:davej@...hat.com] 
>Sent: Friday, January 18, 2008 7:29 PM
>To: Ingo Molnar
>Cc: Yinghai Lu; Pallipadi, Venkatesh; LKML
>Subject: Re: [PATCH] X86: fix typo PAT to X86_PAT
>
>On Fri, Jan 18, 2008 at 10:02:10PM +0100, Ingo Molnar wrote:
> > 
> > * Dave Jones <davej@...hat.com> wrote:
> > 
> > >  > you mean modifies MTRRs? Which code is that? (besides the 
> > >  > /proc/mtrr userspace API)
> > > 
> > > This exclusion is going to be a real pain in the ass for distro 
> > > kernels. It's impossible for example to build a kernel 
>that will now 
> > > support the MTRR-alike registers on the AMD K6/early 
>Cyrix etc and 
> > > also support PAT.
> > > 
> > > Additionally, given people tend to update their kernels a 
>lot more 
> > > often than they update to a whole new version of X, it 
>means until 
> > > userspace has caught up, we can't ship a kernel with PAT 
>supported, or 
> > > else X gets a lot slower due to the missing mtrr support.
> > 
> > there's no exclusion enforced right now, and if a CPU is 
>PAT-incapable 
> > (or if the kernel is booted nopat) then the MTRR bits 
>should be usable. 
> > But if we boot with PAT enabled, and Xorg gets /proc/mtrr 
>wrong, we'll 
> > see nasty crashes. If it gets them right, it should all 
>still work just 
> > fine. Is this ok? Then, in a year or two, distros can disable write 
> > support to /proc/mtrr. Hm?
>
>A crazy idea just occured to me..  We could make /proc/mtrr an 
>interface
>to set PAT on a range of memory.  This would make it transparently work
>without any changes in X or anything else that sets them in userspace.
>

Yes. We actually used this earlier while we were testing PAT
functionality internally :).

There are some issues though. 
1) Current X does /dev/mem mapping of the region followed by MTRR
setting for this region. For this to work with PAT based MTRR, either
the order has to change (so that there wont be any conflict due to WB
devmem mapping when we try to simulate mtrr) or we need a mechanism to
go and change devmem mapping to reflect the later PAT attribute changes.
2) We will have to fail mtrr setting when there are hard conflicts with
PAT requests.

We will look at this as a possible optimization for next round of PAT
patches. But, to work with existing X, we will have to have mechanism to
go and change existing mappings which is slightly more complicated than
what we already have with current PAT changes.

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