Re: [PATCH v2 3/3] x86, efi: Add "efi_fake_mem_mirror" boot option

[Matt Fleming <matt@codeblueprint.co.uk>]

On Wed, 09 Sep, at 04:16:09PM, Ard Biesheuvel wrote:
> 
> Hello Taku,
> 
> To be honest, I think that the naming of this feature is poorly
> chosen. The UEFI spec gets it right by using 'MORE_RELIABLE'. Since
> one way to implement more reliable memory ranges is mirroring, the
> implementation detail of that has leaked into the generic naming,
> which is confusing. Not your fault though, just something I wanted to
> highlight.
 
Care to suggest an alternative option? efi_fake_mem_more_reliable ?

Maybe we should go further than this current design and generalise
things to allow an EFI_MEMORY_ATTRIBUTE value to be specified for
these memory ranges that supplements the ones actually provided by the
firmware?

Something like,

  efi_fake_mem=2G@4G:0x10000,2G@0x10a0000000:0x10000

Where 0x10000 is the EFI_MEMORY_MORE_RELIABLE attribute bit.

That would seem incredibly useful for testing the kernel side of the
EFI_PROPERTIES_TABLE changes, i.e. you wouldn't need support in the
firmware and could just "mock-up" an EFI memory map with EFI_MEMORY_XP
for the data regions (code regions and EFI_MEMORY_RO are a little
trickier as I understand it, because they may also contain data).

> So first of all, could you please update the example so that it only
> shows a single more reliable region (or two but of different sizes)?
> It took me a while to figure out that those 2 GB regions are not
> mirrors of each other in any way, they are simply two separate regions
> that are marked as more reliable than the remaining memory.
> 
> I do wonder if this functionality belongs in the kernel, though. I see
> how it could be useful, and you can keep it as a local hack, but
> generally, the firmware (OVMF?) is a better way to play around with
> code like this, I think?
 
I (partially) disagree. Using real life memory maps has its
advantages, since different layouts exercise the code in different
ways, and I'd really like to see this used on beefy machines with
multiple GB/TB or RAM. It also allows performance measurements to be
taken with bare metal accuracy. Plus there's precedent in the kernel
for creating fake memory/topology objects, e.g. see numa=fake.

Not everyone who touches the EFI memory mirror code is going to want
(or be able) to run firmware with EFI_MEMORY_MORE_RELIABLE support.

Having said that, I'd love to also see EFI_MEMORY_MORE_RELIABLE
support in OVMF! I think both options make sense for different
reasons.

-- 
Matt Fleming, Intel Open Source Technology Center

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>