On Mon, 2013-06-03 at 17:42 +0100, Matthew Garrett wrote: > On Mon, Jun 03, 2013 at 09:35:07AM -0700, James Bottomley wrote: > > On Mon, 2013-06-03 at 17:24 +0100, Matthew Garrett wrote: > > > That seems optimistic. Windows never calls QueryVariableInfo() during > > > boot services, so what makes you think doing so has ever been tested? > > > > It's used by the UEFI shell package ... every system which boots to the > > shell automatically tests this. I know no locked down UEFI system ships > > with a shell but almost every system in test has a Shell in some form, > > so I think its fairly safe to call it from boot services. > > Why do you persist in this belief that all system vendors are going to > have run a shell, let alone any kind of test suite? That runs counter to > everything we've learned about x86 firmware. People verify that it runs > Windows and then ship it. I don't, but I find it hard to believe no vendor ever runs an EFI shell on their systems. The feedback I got from a couple of OEMs is that they use the shell mostly for internal testing. > > However, what about a compromise: why don't we implement 1:1 mapping and > > then call SetVirtualAddressMap with the 1:1 map ... in theory the > > pointer chases should then be nops (it will be replacing the physical > > address with the same virtual address), so everything should just work > > and anything the UEFI vendor missed will still work because the physical > > address will work also in this scenario. > > The problem there is that you're saying "In theory". We know that > Windows doesn't behave this way, so we have no legitimate expectation > that it'll work. We know that it doesn't on some Apple hardware. Fine, you say we need to call SetVirtualAddressMap because windows does, I agree, I'm just saying we get additional safety from calling it with the 1:1 map ... I don't see what the problem is. James -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
