On Thu, 2008-02-14 at 19:38 +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, > while correct for non-RAM 64-bit EFI images, is theoretical at the > moment and has no practical relevance.
On my test machine, there is EFI runtime memory area with EFI_MEMORY_UC attribute. The following is cut from the dmesg: EFI: mem75: type=4, attr=0xf, range=[0x000000007f4ff000-0x000000007f500000) (0MB) EFI: mem76: type=11, attr=0x8000000000000001, range=[0x00000000fed1c000-0x00000000fed20000) (0MB) EFI: mem77: type=11, attr=0x8000000000000001, range=[0x00000000fffb0000-0x00000000fffb4000) (0MB) Where: attr is md->attribute, #define EFI_MEMORY_RUNTIME 0x8000000000000000 #define EFI_MEMORY_UC 0x0000000000000001 But because end_pfn_map contains the above UC memory area, efi_ioremap() is not used on EFI 64. Best Regards, Huang Ying -- 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/
