On Thu, 14 Feb 2008 22:42:41 +0100 Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Thu, Feb 14, 2008 at 07:38:19PM +0100, Ingo Molnar wrote: > > > > * Andi Kleen <[EMAIL PROTECTED]> wrote: > > > > > > this is indeed a bug (we change the attributes for a larger > > > > area than needed), but your fix is unclean. Find below a > > > > cleaner solution. > > > > > > You're still ignoring the other problem of set_memory_uc() not > > > handling fixmap and ioremap correctly. [...] > > > > No, we did not ignore it, and yes, you are wrong. > > > > One thing that you miss is that the 64-bit EFI runtime has to be > > marked uncacheable only if it the EFI image attribute signals an > > uncacheable area: > > > > if (!(md->attribute & EFI_MEMORY_WB)) > > set_memory_uc(md->virt_addr, md->num_pages); > > > > and Linux EFI does not support device EFI runtimes. So your > > observation, > > Sorry I didn't get that (you were a bit terse). > > You're saying the EFI BIOSes will never set that flag ? > > I'm reading page 123+ of UEFI 2.1 which describes GetMemoryMap() > and these flags and I see nothing to that effect. I admit I didn't > read the full EFI bible so far so there are certainly EFI > aspects I don't understand. > > Can you please clarify why EFI would not set that flag on Linux? because it will only normally get set on EFI code that lives in device memory. There's no reason to ever use non-cache for ram this way. Ever. Non-cached execution is a TOTAL pain for anything, and will be avoided if at all possible. -- If you want to reach me at my work email, use [EMAIL PROTECTED] For development, discussion and tips for power savings, visit http://www.lesswatts.org -- 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/
