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.
--
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
