[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.
> > 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).

> >> > EFI reboot is only tried if the user supplied it or if the hardware
> >> > is an ACPI 5.0 (or higher) reduced hardware board.
> >> > 
> >> > This fixes the EFI firmware crashing on Lenovo ThinkCentre M57
> >> 
> >> Buggy firmware should be worked around with "reboot="; I'd
> >> certainly accept a patch to bypass efi_reset_system() in that
> >> case.
> > 
> > Independent of the conversation above I will work the patch
> > that way.  Would you also be OK if I stuck the DMI data for the
> > ThinkCentre to make this automatic?
> Yes, as long as the match isn't too generic (i.e. wouldn't match all
> furure models too).

I've sent you two patches for this. I have no clue what the future
models of this particular hardware have for product id - but it looks
quite specific to be for just this hardware.
> Jan

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.