Re: [Xen-devel] [PATCH] x86/time: Don't use EFI's GetTime call by default

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 01/12/15 17:26, Jan Beulich wrote:
>>>> On 01.12.15 at 17:57, <ross.lagerwall@xxxxxxxxxx> wrote:
>> When EFI is used, don't use EFI's GetTime() to get the time, because it
>> is broken on many platforms. From Linux commit 7efe665903d0 ("rtc:
>> Disable EFI rtc for x86"):
>> "Disable it explicitly for x86 so that we don't give users false
>> hope that this driver will work - it won't, and your machine is likely
>> to crash."
>>
>> Signed-off-by: Ross Lagerwall <ross.lagerwall@xxxxxxxxxx>
> NAK, since being conceptually wrong (and both of my systems work
> fine). Vendors should get their firmware fixed, and by not using
> runtime service functions we would give them even less reason to
> do so. Until then we have "efi=no-rs".

This is completely unreasonable.

It is not conceptually wrong.  GetTime() is very well known completely
broken, especially after ExitBootServices(), to the point that every
other EFI implementation (including windows) completely avoids it.

The fact that your two systems don't crash immediately is curious, but
they are not a representative of systems in general.  Not a single
broadwell or skylake platform I have access to boots in EFI mode if
GetTime() is used (which include 4 different manufactures).

Vendors will not fix their firmware.  Disabling all runtime services is
not a reasonable alternative.

This is a firmware bug just like many others and needs to be worked
around by default like others.

Anything else is actively damaging to the Xen community.  People just
get frustrated when it doesn't work (especially if the problem has been
identify and a fix rejected upstream) and will move elsewhere instead.

Any situation where a command line override is required to make Xen boot
is a bug in Xen and should be fixed.  This is why we have __init time
quirks. it doesn't matter if we have some truly horrendous workarounds;
Xen needs to be able to boot by default wherever possible.

~Andrew

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