All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>, Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [PATCH] x86: Don't honour ACPI indicating absence of CMOS RTC
Date: Tue, 17 Jun 2014 18:01:08 +0100	[thread overview]
Message-ID: <53A07454.10409@citrix.com> (raw)
In-Reply-To: <53A07700020000780001B26F@mail.emea.novell.com>

On 17/06/14 16:12, Jan Beulich wrote:
>>>> On 17.06.14 at 16:58, <andrew.cooper3@citrix.com> wrote:
>> This reverts f74556693 "x86: honor ACPI indicating absence of CMOS RTC"
>>
>> Certain HP Gen8 BIOSes have started setting this bit despite an RTC CMOS 
>> being present and working.
>>
>> Their reasonsing is to prevent EFI-booted OSes from playing with the CMOS,
>> combined with the erroneous assumption that the only OSes using legacy boot
>> are too old to know about ACPI v5 and therefore to understand this bit.
> Which implies you can boot from EFI on those systems,

Indeed you can

>  which is
> precisely what the panic message says you ought to do. Why do
> you not boot via EFI in the first place?

Inertia mostly.  The current state of play of needing experimental
patches against grub2 and pvops is suboptimal, and XenServer management
decided that our efforts were better spent elsewhere.

Fundamentally though, that patch caused a boot regression on HP DL580
Gen 8 systems, and an unknown number of other systems.

>
>> As a result, the change being reverted prevented modern Xen from booting on
>> modern HP hardware, despite older Xen working perfectly fine on the same
>> hardware.
> Still, the flag has a purpose, and HP assigning a slightly non-standard
> meaning to it doesn't mean we should outright revert that change.
> Options I could live with (short of them revisiting the bogus assumption)
> are
> - a command line option suppressing the mandated behavior,
> - a DMI quirk suppressing the mandated behavior,

I have no indication on the extent of the issue, but it could be as much
as all HP Gen8 and 9 systems.  I suspect this option wouldn't scale.

> - code probing for a functional CMOS RTC gating the panic()
>   invocation.

If the firmware claims no RTC, is it even safe to probe?  There is
nothing I am aware of preventing the IO port space being reused by
something else if the firmware has told the OS that there genuinely
isn't an RTC there.

~Andrew

  parent reply	other threads:[~2014-06-17 17:01 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-17 14:58 [PATCH] x86: Don't honour ACPI indicating absence of CMOS RTC Andrew Cooper
2014-06-17 15:12 ` Jan Beulich
2014-06-17 15:47   ` Konrad Rzeszutek Wilk
2014-06-17 16:01     ` Jan Beulich
2014-06-17 16:31       ` Konrad Rzeszutek Wilk
2014-06-18 12:00         ` Jan Beulich
2014-06-18 13:06           ` Konrad Rzeszutek Wilk
2014-06-18 13:40             ` Jan Beulich
2014-06-17 17:01   ` Andrew Cooper [this message]
2014-06-18 12:02     ` Jan Beulich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53A07454.10409@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=keir@xen.org \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.