>-----Original Message----- >From: Dave Jones [mailto:[EMAIL PROTECTED] >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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
