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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 23.01.15 at 03:37, <konrad.wilk@xxxxxxxxxx> wrote:
> On Thu, Jan 22, 2015 at 03:22:10PM +0000, Jan Beulich wrote:
>> >>> On 22.01.15 at 16:01, <konrad.wilk@xxxxxxxxxx> wrote:
>> > On Thu, Jan 22, 2015 at 09:49:08AM +0000, Jan Beulich wrote:
>> >> >>> On 21.01.15 at 22:53, <konrad.wilk@xxxxxxxxxx> 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
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.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel