On 11/19/2018 6:49 PM, Alex_Gagniuc@xxxxxxxxxxxx wrote:
On 11/19/2018 02:33 PM, Sinan Kaya wrote:
However; table assumes governance about for which entities firmware first
should be enabled. There is no cross reference to _OSC or permission
negotiation like _OST.
Well, from an OSPM perspective, is FFS something that can be enabled or
disabled? FFS seems to be static to OSPM, which would change the sort of
assumptions we can reasonably make here.
IMO, it can be enabled/disabled in BIOS. I have seen this implementation before.
If the trigger is the presence of a statically compiled ACPI HEST table (as the
current code does); presence of FFS would be static from OSPM perspective.
BIOS could patch this table or hide it during boot.
If FFS were to be negotiated via _OSC as indirectly implied in this series, then
same BIOS could patch the ACPI table to return different values for the _OSC
return.
As I said in my previous email, the right place to talk about this is UEFI
forum.
The way I would present the problem to he spec writers is that, although
the spec appears to be consistent, we've seen firmware vendors that made
the wrong assumptions about HEST/_OSC. Instead of describing AER
ownership with _OSC, they attempted to do it with HEST. So we should add
an implementation note, or clarification about this.
I agree.
Cool. While the UEFI Secret Society debates, can we figure out if/how
[patch 1/2] breaks those systems, or is it only [patch 2/2] of this
series that we suspect?
I went back and looked at both patches. Both of them are removing references to
HEST table. I think both patches are impacted by this discussion.
Alex
