Re: [PATCH RFC] efi: By default use the BOOT_ACPI method instead of BOOT_EFI unless on reduced ACPI hardware.

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Fri, Jan 23, 2015 at 09:18:32AM +0000, Jan Beulich wrote:
> >>> On 23.01.15 at 03:37, <konrad.wilk@oracle.com> wrote:
> > On Thu, Jan 22, 2015 at 03:22:10PM +0000, Jan Beulich wrote:
> >> >>> On 22.01.15 at 16:01, <konrad.wilk@oracle.com> wrote:
> >> > On Thu, Jan 22, 2015 at 09:49:08AM +0000, Jan Beulich wrote:
> >> >> >>> On 21.01.15 at 22:53, <konrad.wilk@oracle.com> wrote:
> >> >> > This mimics the behavior of the Linux kernel in which the reboot
> >> >> > sequence by default under EFI booted kernels is first ACPI.
> >> >> 
> >> >> Which is contrary to the EFI spec. I.e. NAK.
> >> > 
> >> > I am failing to see that in the spec. I see that it says what
> >> > the ResetSystem() call does, but nothing about "MUST".
> >> > 
> >> > I see this at the start of the spec:
> >> > 
> >> > " Together, these provide a standard environment for booting an OS. This
> >> > specification is designed as a pure interface specification. As such,
> >> > the specification defines the set of interface s and structures that
> >> > platform firmware must implement. "
> >> > 
> >> > (which talks about 'booting an OS' - which this is not, and interestingly
> >> > enough - it does say implement, but not where it must implement it
> >> > correctly!).
> >> > 
> >> > But I have not dug that deep in the spec to find something
> >> > that says you MUST not use existing other specs? Perhaps you
> >> > remember where the contrary part is?
> >> 
> >> The whole spirit of EFI is to get the OS away from doing things
> >> some custom (and hence possibly fragile) way.
> > 
> > ACPI being 'custom'? I am not sure if there is a way on x86 to run
> > without ACPI at all. I can see it under ARM where you have the
> > Device Tree to complement it - but either way EFI is not an
> > full solution to manage the system.
> 
> >From a EFI pov, EFI runtime services are to be preferred over
> ACPI methods. While particularly relevant for cases where there's
> no ACPI (which you validly say is not an practical option on x86),
> it's a general conceptual thing to follow.
> 
> >> > Also, why do we want to be different that Windows and Linux when doing
> >> > EFI operations?
> >> 
> >> Because just because they do things a certain way doesn't mean
> >> they do it right. Linux having actively removed using the time
> >> related runtime services functions is something that I for example
> >> absolutely can't agree with. If there are firmware vendors not
> >> getting their act together, having ways to work around that is
> >> acceptable, but outright violation of the spec is wrong imo.
> > 
> > There is the spec and there is the implementation (Windows) that
> > every motherboard manufacturer follows and caters to. It does not
> > matter if the they (Microsoft) violate the spec - by them violating
> > it or not using certain things - it makes it an de-facto specification.
> > 
> > Now I don't know if Linux ignoring the time runtime services has
> > been due to bugs or just following what Windows did - but either way
> > having it done that way - makes the firmware vendors that care
> > about Linux - implement it to work under Linux (so expose the
> > legacy timers even in EFI mode).
> 
> Argumentation along those lines is what I hear all time long. But how
> do you envision firmware vendors to become aware of and fix their
> bugs if everyone blindly works around them? By not adding

That is a very good point. However my experience with hardware vendors
is that they have limited amount of resources and have hardly any
resources to even fix issues that occur when running with Linux.

Big vendors like IBM, Oracle, etc certainly have an incentive, but 
other less so.

> workarounds where it's not explicitly known they're needed, we at
> least can point out to them that they have issues. Making things
> more user friendly by making available (default-off) command line
> overrides (or, as you suggest in this case, detecting the need via
> DMI matching) is certainly desirable.

I would love to tell Lenovo engineers about their bugs on this
platform (EFI reboot not implemented, EHCI controller doing some wonky
reads in EFI_RSV - Elena seeing that) - but I have not had any luck
getting a contact person.

If you have a contact email I shall file them detailed logs of what
I see on this little workstation I have.
> 
> Jan
>