>-----Original Message-----
quoted text
>From: Dave Jones [mailto:davej@redhat.com] 
>Sent: Friday, January 18, 2008 10:25 AM
>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 01:31:40PM +0100, Ingo Molnar wrote:
> 
> > * Yinghai Lu <Yinghai.Lu@Sun.COM> wrote:
> >
> > > > thanks. But, i think we should rather do the following: 
>if X86_PAT
> > > > is eanbled then /proc/mtrr should be read-only. There's 
>no problem
> > > > _looking_ at MTRR contents, as long as we do not try to 
>modify them.
> > > > Hm?
> > >
> > > anyway
> > >
> > > depends on !PAT
> > >
> > > need to be removed.
> > >
> > > it seems when PAT is used, some code still touch MTRR.
> >
> > 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.
>

Actually, this exclusion will not work at all with the current code.
Infact it should be PAT selects MTRR, for the current code. As
pat_init() is called during mtrr init as the rules for how to change PAT
and how to change MTRR are same. Further, MTRR is always required on
SMP, as we read the MTRR setting from boot CPU and set it on Aps at boot
time. We should only remove the /proc/mtrr write permissions with
CONFIG_PAT. We need to deprecate it for a while before that...
Ingo, can you remove this PAT MTRR exclusion.

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