lkml.org 
[lkml]   [2008]   [Feb]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2008-02-14 19:41    [W:0.142 / U:0.116 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site