Re: unusual uefi call/mapping problem

[Joel Schopp <jschopp-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>]

On 04/30/2013 07:52 AM, Matthew Garrett wrote:
> On Tue, Apr 16, 2013 at 04:31:17PM -0500, Joel Schopp wrote:
>> I'm working on the Linux kernel implementation of an draft standard
>> that has a uefi component.  The interesting part is that the uefi
>> component isn't in the uefi runtime table, but instead has a
>> physical address stored an ACPI table.  Other than not being in the
>> runtime table it behaves exactly like the other runtime services.
>
> Sigh. Is the spec final yet? Doing this in ACPI is inconvenient - ACPI
> isn't available at the stage where we do early UEFI setup, so it would
> have been much easier if this had been a UEFI table rather than an ACPI
> one.

The spec appears to currently be in purgatory, finished but not 
published.  Do you happen to know offhand what spec defines the UEFI 
runtime services table?

>
>> 2) Various methods to map in the physical address into virtual
>> address space and then call the virtual address.  All of these have
>> failed.

Turns out there was a bug in the UEFI implementation, I'm pretty sure we 
have a way to map it in and call it now.

>
> If the function pointer to the ACPI table is to a UEFI runtime region,
> the kernel should already have set up a virtual to physical mapping for
> the code. Does SetVirtualAddressMap() update the pointer in the ACPI
> table? If so, you're good to go - just pass it to the appropriate
> efi_call_virt*() wrapper. If not, and if the spec isn't final, go back
> and fix that.
>
>> 3) I've started looking at adding an entry to the efi struct and a
>> line to efi_enter_virtual_mode(...) with the new function name but
>> haven't found the right spot to add an extra entry on to the mmap
>> structure. Does this seem like a sane approach?
>
> You mean the memmap structure? No, you shouldn't need to do that.

Thanks. I won't then.