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? Can you refer me to the parts of the spec that describe that? > Also note that 64-bit EFI runtime support (the ability to execute EFI > code) is completely new - it got introduced 14 days ago. We only use > fixmaps on 64-bit EFI. On 32bit it is wrong too I think at least on non default __PAGE_OFFSET splits. > > 32-bit EFI is more common (but still not very common, compared to other > x86 platforms) and that is totally unaffected by secondary aliases. Of course it is affected. set_memory_uc() will not fix up the direct mapping in this case either. Given the overlap of PCI hole to direct mapping cases there are more seldom, but certainly exist (e.g. consider 1:3 split and a 2GB PCI hole) And while given that's a relatively obscure case it's a valid regression. -Andi -- 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/
