unusual uefi call/mapping problem
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.
After extracting the physical address of the UEFI service we can't successfully map it or call it. I'm sure this is straightforward to somebody with experience in this area. Here's a few of the things I've tried unsuccessfully, any pointers here would be appreciated.
1) Call the physical addressefi_call_phys_prelog();efi_call_phys5(...);efi_call_phys_epilog();
This generates some nasty scheduling while atomic errors
2) Various methods to map in the physical address into virtual address space and then call the virtual address. All of these have failed.
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?
-Joel Schopp
Quoted 2 lines · Joel Schopp
I'm working on the Linux kernel implementation of an draft standard that has a uefi component.
What standard would that be?
Quoted 7 lines
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.After extracting the physical address of the UEFI service we can't successfully map it or call it.
You want to call it from the kernel? Why? Usually you get a "virtual" address to call UEFI things, and then use efi_call_virt?(), why can't you do that here as well?
Quoted 10 lines
I'm sure this is straightforward to
somebody with experience in this area. Here's a few of the things I've tried unsuccessfully, any pointers here would be appreciated.1) Call the physical address
efi_call_phys_prelog();efi_call_phys5(...);efi_call_phys_epilog();This generates some nasty scheduling while atomic errors
As it should :)
Quoted 3 lines
2) Various methods to map in the physical address into virtual address space and then call the virtual address. All of these have failed.
Why? What have you done that failed? Any pointers to code anywhere?
Are you trying to do this before we switch to virtual mode, or after?
thanks,
greg k-h
Thanks for the quick reply.
Quoted 4 lines
Quoted 2 lines
I'm working on the Linux kernel implementation of an draft standard that has a uefi component.
What standard would that be?
Trusted Computing Group Dynamic Root of Trust Management (D-RTM).
Quoted 6 lines
Quoted 2 lines
After extracting the physical address of the UEFI service we can't successfully map it or call it.
You want to call it from the kernel? Why? Usually you get a "virtual" address to call UEFI things, and then use efi_call_virt?(), why can't you do that here as well?
If I had a virtual address I would be a happy man. I have a physical address and my attempts to turn it into a virtual one that is callable have been unfruitful.
Quoted 5 lines
Quoted 3 lines
2) Various methods to map in the physical address into virtual address space and then call the virtual address. All of these have failed.
Why? What have you done that failed? Any pointers to code anywhere?
Unfortunately I can't release code until after the spec is public. I believe that will happen in a matter of weeks and not months. Then all work will be shared under gpl and we will work on getting it functional and acceptable for upstream inclusion. I realize not being able to post code now is very limiting.
Quoted 2 lines
Are you trying to do this before we switch to virtual mode, or after?
After. We are trying to do this well after all userspace has started.
Quoted 5 lines · Joel Schopp
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.
Quoted 3 lines
2) Various methods to map in the physical address into virtual address space and then call the virtual address. All of these have failed.
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.
Quoted 4 lines
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.
Signature · 1 line
Matthew Garrett | [email protected]
Quoted 11 lines · Matthew Garrett
Quoted 5 lines · Joel Schopp
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?
Quoted 4 lines
Quoted 4 lines
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.
Quoted 8 lines
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.
Quoted 6 lines
Quoted 4 lines
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.
Quoted 8 lines · Joel Schopp
Quoted 7 lines · Matthew Garrett
Quoted 5 lines · Joel Schopp
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.
Quoted 8 lines
Quoted 4 lines
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?
That's in the UEFI spec, but it wouldn't be appropriate to put it there. Instead, you can add another UEFI table with a different UUID and have a pointer to that from the ConfigurationTables pointer in the UEFI system table.
Quoted 7 lines
Quoted 4 lines
Quoted 4 lines
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.
Cool.
Signature · 1 line
Matthew Garrett | [email protected]