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

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Wed, 2015-12-02 at 02:33 -0700, Jan Beulich wrote:
> > > > 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.

In an ideal world such specifications would indeed be worth the paper they
are written on. But the reality is that firmware implementations are often
complete rubbish and the Xen project has nowhere near the leverage needed
to actually get this fixed, even Linux lacks such leverage AFAICT.

In reality only Microsoft (and perhaps to a lesser extent Apple) have any
sort of ability to force things in this way (even so it is alleged in this
thread that even Windows avoids the GetTime call as too broken in the field
as well).

Given we have no leverage in this it seems to me that punishing our users
by ensuring that Xen won't work on the majority of EFI systems (based on
anecdotal evidence from both Andrew and yourself) is counter productive.
All it means is that at best we will get a continuous stream of bug reports
from such users, or worse those users will just silently disappear and use
something else which Just Works on their hardware and tell their friends
that Xen is broken on modern hardware.

There is only the smallest chance they will actually report a bug to their
firmware vendor and even if they do there is basically an infinitesimal
chance that the vendor will care in the slightest given that Windows
presumably boots and works on that system.

Realistically about all we can do is support efforts such as
    http://biosbits.org/
https://wiki.ubuntu.com/Kernel/Reference/fwts
https://01.org/linux-uefi-validation
and hope that they gain sufficient momentum, we certainly cannot effect any
kind of change in the x86 firmware world directly ourselves by holding
basic Xen functionality to ransom.

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

I don't think it is relevant to use why x86 UEFI implementations are broken
in this way, just that it seems that the reality is that they mostly are.

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

And based on what I'm reading in this thread about the reliability of the
time RS in the field it seems to me we should make it the default (on x86
at least) and provide efi=time to opt in.

Ian.

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