Messages in this thread | | | Date | Thu, 14 Feb 2008 19:38:19 +0100 | From | Ingo Molnar <> | Subject | Re: [PATCH] Fix left over EFI cache mapping problems |
| |
* Andi Kleen <andi@firstfloor.org> 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.
Of course, as we've stated it numerous times, we want this all fixed up, and we _have_ fixed it up already, but we wanted to do it properly. Right now we've got the fixes lined up and we are waiting for a test report and an Ack from Ying Huang. (he reported that current -git worked just fine for him)
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.
32-bit EFI is more common (but still not very common, compared to other x86 platforms) and that is totally unaffected by secondary aliases. (which is a complication of the 64-bit kernel)
Thanks,
Ingo
| |