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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 01.12.15 at 20:26, <andrew.cooper3@xxxxxxxxxx> wrote:
> 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.

I'm sorry, but no. Otherwise you mean to state that specifications
don't even need to be written, since if people don't play by them,
workarounds will get implemented anyway.

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

I'm not sure about the order of things. I started working with EFI on
IA64, where using runtime services is a must. Windows started
using EFI on IA64 too, so I'm pretty convinced they used GetTime()
there. Whether they didn't on x86 because x86 implementations
were broken, or whether x86 implementations end up broken
because Windows never used those functions is simply an unknown.

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

The original x86 implementation we used almost 15 years back
(on top of systems not even supporting EFI, since there simply were
none back then) didn't have this problem either.

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

Then we should see about adding support for "efi=no-time".

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

Except that you propose to work around it even when there is nothing
to be worked around. I wouldn't mind switching on the workaround
for known broken systems.

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

I'd leave specifying (or switching on by source patching) default
workarounds to distros then. They know what their customers need,
or what systems they expect their stuff to be run on.

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

But requiring command line overrides for other things that are
considered to not work by default is fine? I'm thinking of XenServer's
universal disabling of XSAVE here...

Jan


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