On Mon, 16 May, at 05:58:40PM, Alex Thorlton wrote: > > I was simply re-using the efi_call implementation. Boris suggested that > I re-write this using the efi_call_virt macro, so I just went with that. > It all seems to work just fine, so I don't see much reason to stray away > from that implementation. That being said, I'm obviously not a huge fun > of the code duplication across the macros. I think there's probably a > way to minimize this, though I haven't quite worked out the best method > yet (ideas are welcome :) The reason I'm pressing for details is that we have a related issue with the EFI thunking code (CONFIG_EFI_MIXED), where the function pointer we want to call isn't accessible via the EFI System Table, see efi_thunk(). Well, technically it *is* accessible, you just can't dereference the services at runtime because the pointers in the tables are not 64-bit. But the same constraints exist for EFI thunk and UV code; given a function pointer to execute that isn't in efi.systab, setup the EFI runtime environment and call a custom ABI function. I haven't tested this (or thought through all the implications), but could you look at providing a table (or something) for mapping a function name to a ptr,func pair, e.g. thunk_get_time: runtime_services32(get_time), efi64_thunk thunk_set_time: runtime_services32(set_time), efi64_thunk ... uv_call_func: efi.uv_systab->function, uv_efi_call_virt which we could use in arch_efi_call_virt()? That should give us much less code duplication and hide all this inside arch/x86. -- 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
