Re: [Xen-devel] [PATCH] xen/efi: Add /mapres to map EfiReservedMemoryType for runtime services

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 17.06.15 at 15:46, <andrew.cooper3@xxxxxxxxxx> wrote:
> @@ -763,6 +764,8 @@ static int __init __maybe_unused set_color(u32 mask, int 
> bpp, u8 *pos, u8 *sz)
>                      base_video = 1;
>                  else if ( wstrcmp(ptr + 1, L"mapbs") == 0 )
>                      map_bs = 1;
> +                else if ( wstrcmp(ptr + 1, L"mapres") == 0 )
> +                    map_res = 1;

For one, this not being used in loader code, it should be a sub-option
to the regular efi= option instead of loader one.

> @@ -1216,7 +1219,9 @@ void __init efi_init_memory(void)
>               (!(desc->Attribute & EFI_MEMORY_RUNTIME) &&
>                (!map_bs ||
>                 (desc->Type != EfiBootServicesCode &&
> -                desc->Type != EfiBootServicesData))) )
> +                desc->Type != EfiBootServicesData)) &&
> +              (!map_res ||
> +               desc->Type != EfiReservedMemoryType)) )
>              continue;
>  
>          desc->VirtualStart = INVALID_VIRTUAL_ADDRESS;

And then I have severe reservations against adding mappings to
_all_ reserved regions: What if the cachability for them is given
incorrectly in the memory map, and we end up inserting a mapping
that the processor can speculate into? At the very least all such
mappings imo should be forced to be UC. But I think such mappings
should be added in much more fine grained manner, i.e. the
command line option should allow to specify page ranges (any
of which not being marked EfiReservedMemoryType would be
silently ignored).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel