xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Jason Andryuk <jandryuk@gmail.com>
Cc: andrew.cooper3@citrix.com, aaron@ajanse.me,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [BUG] panic: "IO-APIC + timer doesn't work" - several people have reproduced
Date: Fri, 17 Apr 2020 11:31:38 +0200	[thread overview]
Message-ID: <7aca5da4-2ae5-8d3d-e7df-69eb7ffb743c@suse.com> (raw)
In-Reply-To: <20200317152310.114567-1-jandryuk@gmail.com>

On 17.03.2020 16:23, Jason Andryuk wrote:
> Below is the diff.  It was messier and I tidied it up some.

I've looked into this some more. I can see how what we currently
do is not in line with firmware handing off with LegacyReplacement
mode enabled. However, this case doesn't look to apply here:

> It's mainly the change to hpet_resume() to mimic Linux's legacy HPET
> setup on T0.  It turns on HPET_CFG_LEGACY to ensure the timer interrupt
> is running.  And it also includes the printing of the initial HPET
> config:
> HPET_CFG 00000001

While HPET_CFG_ENABLE is set, HPET_CFG_LEGACY is clear.

> HPET_T0_CFG 00008030
> HPET_T0_ROUTE 0000016c

And while firmware must have setup FSB routing for T0, its enable
bits (both HPET_TN_ENABLE and HPET_TN_FSB) are also clear.
Therefore we have, afaics, no indication whatsoever that we ought
to enable LegacyReplacement mode. Of course the spec also says
"Assuming platform does not have 8254/RTC hardware or does not
want to support this legacy timer hardware, for this case, System
BIOS should set the LegacyReplacement Route bit and report IRQ0 &
IRQ8 as being consumed by the HPET block in system name space:"
(followed by a table). What is referred to as "system name space"
is, I assume, ACPI DSDT/SSDTs, which we have no access to this
early (and Linux doesn't either, aiui), so also can't be used as
indicator.

Otoh I also don't think it is correct to blindly enable
LegacyReplacement mode, like - afaics - Linux does, the more with
our split brain model as far as affected devices go (Xen "owns"
the PIT [and of course also the HPET], while Linux "owns" the
RTC). This is because of the effect of this setting on what
actually drives IRQ8. In theory we might be able do so when
ACPI_FADT_NO_CMOS_RTC is set, but Linux may use the CMOS RTC
even when that flag is set.

So right now the only possible approach I see to address your
problem is to add yet another fallback mode to check_timer(),
forcing LegacyReplacement mode to be enabled. But between /
after which step(s) to put this there isn't at all obvious to me.

Jan


  parent reply	other threads:[~2020-04-17  9:32 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-31  7:52 [Xen-devel] [BUG] panic: "IO-APIC + timer doesn't work" - several people have reproduced Aaron Janse
2019-12-31  8:27 ` Andrew Cooper
2019-12-31  9:07   ` Aaron Janse
2020-02-17 19:19     ` Jason Andryuk
2020-02-17 19:46       ` Andrew Cooper
2020-02-17 20:41         ` Jason Andryuk
2020-02-18  1:21           ` Andrew Cooper
2020-02-18 18:43             ` Jason Andryuk
2020-02-18 21:45               ` Andrew Cooper
2020-02-19  8:25                 ` Jan Beulich
2020-03-04 16:06                   ` Jason Andryuk
2020-03-17 13:48                     ` Jason Andryuk
2020-03-17 14:08                       ` Jason Andryuk
2020-03-17 14:17                         ` Jan Beulich
2020-03-17 14:08                       ` Jan Beulich
2020-03-17 14:15                         ` Jan Beulich
2020-03-17 15:23                           ` Jason Andryuk
2020-03-17 16:31                             ` Jason Andryuk
2020-03-18 10:28                             ` Jan Beulich
2020-03-18 14:04                               ` Jason Andryuk
2020-03-18 17:34                                 ` Jason Andryuk
2020-04-17  9:31                             ` Jan Beulich [this message]
2020-04-28 20:59                               ` Jason Andryuk
2020-03-04 16:05               ` Jason Andryuk
2020-01-03 12:51 ` Jan Beulich
2020-01-06  0:35   ` Aaron Janse
2020-01-06  8:57     ` 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=7aca5da4-2ae5-8d3d-e7df-69eb7ffb743c@suse.com \
    --to=jbeulich@suse.com \
    --cc=aaron@ajanse.me \
    --cc=andrew.cooper3@citrix.com \
    --cc=jandryuk@gmail.com \
    --cc=xen-devel@lists.xenproject.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).