Re: [PATCH v1.1 2/2] x86/hpet: Don't enable legacy replacement mode unconditionally

[Ian Jackson <iwj@xxxxxxxxxxxxxx>]

Jan Beulich writes ("Re: [PATCH v1.1 2/2] x86/hpet: Don't enable legacy 
replacement mode unconditionally"):
> TBH delaying the release for this specific problem should be seriously
> considered imo. In principle I'm in favor of (3) of the above, if there
> weren't the downsides I did mention in prior mails.

Thanks for putting forward your opinion.  I am always happy to hear
what people say and this input is very valuable.  However:

I am not inclined to delay the release over this.  Delaying the
release might be appropriate if this problem was unforeseen and
recently discovered, late in the freeze.  But it was not.

That there was a significant regression caused by e1de4c196a2e
  x86/timer: Fix boot on Intel systems using ITSSPRC static PIT clock gating
was already known at least by the 24th of February[1].

Since then, that change has been at risk of being reverted if it went
unfixed.  Unfortunately the the first cut of patches to try fix this
something like properly were only posted yesterday.

It is up to everyone who wants something to make it into the release,
to make sure that the code is ready in time.  That includes sorting
out any regressions it introduces.  In the case of e1de4c196a2e that
has not occurred.

It doesn't seem to me that we will have sufficient confidence in the
more comphrenesive fix, for it to go into staging-4.15 today.

I think the appropriate course, therefore, is the conditional (based
on commaned line) revert proposed by Jan.

Sorry,
Ian.

[1] https://lists.xenproject.org/archives/html/xen-devel/2021-02/msg01533.html