Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1396575 > unrolled thread

Re: [RFC PATCH v2 07/10] efi: load SSTDs from EFI variables

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [RFC PATCH v2 07/10] efi: load SSTDs from EFI variables Jon Masters <jcm@redhat.com> - 2016-05-09 06:20 +0200
    Re: [RFC PATCH v2 07/10] efi: load SSTDs from EFI variables Octavian Purdila <octavian.purdila@intel.com> - 2016-05-09 12:00 +0200

#1396575 — Re: [RFC PATCH v2 07/10] efi: load SSTDs from EFI variables

Hi Octavian,

Apologies for missing this earlier, just catching up on this thread...

On 04/19/2016 06:39 PM, Octavian Purdila wrote:

> This patch allows SSDTs to be loaded from EFI variables. It works by
> specifying the EFI variable name containing the SSDT to be loaded. All
> variables with the same name (regardless of the vendor GUID) will be
> loaded.

This sounds very useful during development. However, and using EFI
variables isn't so terrible, but I am concerned that this should be
standardized through ASWG and at least involve certain other OS vendors
so that the variable (GUID) can be captured somewhere. If not in the
spec itself, then it should be captured as an external ACPI resource on
the UEFI website with a clear pointer to the exact IDs to be used.

Can you confirm that's the intention? i.e. that you're allowing a
command line option for specifying the ID now because you intend to go
ensure that there is a standard one that everyone will use later?

I should check (but maybe you know) if the kernel is automatically
tainted by this codepath as well?

Thanks,

Jon.

-- 
Computer Architect | Sent from my Fedora powered laptop

[toc] | [next] | [standalone]

#1396897

On Mon, May 9, 2016 at 7:13 AM, Jon Masters <jcm@redhat.com> wrote:
> Hi Octavian,
>
> Apologies for missing this earlier, just catching up on this thread...

Hi Jon,

>
> On 04/19/2016 06:39 PM, Octavian Purdila wrote:
>
>> This patch allows SSDTs to be loaded from EFI variables. It works by
>> specifying the EFI variable name containing the SSDT to be loaded. All
>> variables with the same name (regardless of the vendor GUID) will be
>> loaded.
>
> This sounds very useful during development. However, and using EFI
> variables isn't so terrible, but I am concerned that this should be
> standardized through ASWG and at least involve certain other OS vendors
> so that the variable (GUID) can be captured somewhere. If not in the
> spec itself, then it should be captured as an external ACPI resource on
> the UEFI website with a clear pointer to the exact IDs to be used.
>
> Can you confirm that's the intention? i.e. that you're allowing a
> command line option for specifying the ID now because you intend to go
> ensure that there is a standard one that everyone will use later?
>

Yes, that is the intention. As I mentioned in the commit the long term
plan is to do the loading at the FW level (before the OS boots) using
the same mechanisms. But since this is going to take some time, I
think its worth having the option to do the loading from software for
two reason:

a) to provide a way for using this mechanism on older boards that will
not have the option to do a firmware update to get this functionality

b) to implement the software support needed in advance and have a way to test it

> I should check (but maybe you know) if the kernel is automatically
> tainted by this codepath as well?

In this version of the patch the kernel is tainted. However, note that
in future versions I intend to remove it because it was already
removed part of the initrd ACPI table upgrade patch [1].

[1] http://lkml.iu.edu/hypermail/linux/kernel/1604.1/01488.html

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web