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@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>