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

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Tue, Dec 08, 2015 at 11:02:16AM +0000, Ian Campbell wrote:
> 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).

We could confirm this right? We can run OVMF and instrument the 'GetTime' and
see what Windows does?
> 
> 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.

Plus I have had no luck actually finding a way to report this.
Take for example my Lenovo hardware which has EFI holes everywhere..

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

At least on Lenovo equipment they seem to assume a lot of things
after ExitBootServicers - especially as we don't follow the same mechanism
of switching to virtual addresses.

(And Lenovo EFI code will blindly use virtual addresses after ExitBootServices
which is why hack allows me to run Xen on Lenovo equipment).
> 
> > > 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

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