Re: [PATCH] Fix left over EFI cache mapping problems

["Huang, Ying" <ying.huang@intel.com>]

On Thu, 2008-02-14 at 19:38 +0100, Ingo Molnar wrote:
> * 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.

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