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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 26.03.2021 14:03, Tamas K Lengyel wrote:
> On Fri, Mar 26, 2021 at 8:30 AM Ian Jackson <iwj@xxxxxxxxxxxxxx> wrote:
>>
>> I wrote:
>>> I'm sorry, but I think it is too late for 4.15 to do this.  I prefer
>>> Jan's patch which I have alread release-acked.
>>>
>>> Can someone qualified please provide a maintainer review for this,
>>> ideally today ?
>>
>> I asked Andrew on IRC:
>>
>> 12:08 <Diziet> andyhhp__: Are you prepared to maintainer-ack Jan's
>>                more-minimal hpet workaround approach ?
>> 12:16 <andyhhp__> Diziet: honestly, no.  I don't consider that
>>                   acceptable behaviour, and it is a fairly big "f you"
>>                   (this was literally feedback I got in private) to
>>                   the downstreams who've spent years trying to get us
>>                   to fix this bug, and have now backported the first
>>                   version.
>> 12:16 <andyhhp__> I'm looking into the feedback on my series
>> 12:17 <andyhhp__> one way or another, the moment we enter the fallback
>>                   path for interrupt routing, something is very broken
>>                   on the system
>> 12:19 <andyhhp__> so the tradeoff is an unspecified bug on one ancient
>>                   laptop which can't be tested now, vs 5 years of Atom
>>                   CPUs, 2 years of latop CPUs, and the forthcoming
>>                   Server line of Intel CPUs
>> 12:19 <andyhhp__> or whatever other compromise we can work on
>>
>> I'm sorry that this bug is going to continue to be not properly fixed.
>> As I understand it the practical impact is that users of those
>> affected systems (the newer ones you mention) will have to add a
>> command-line option.  That is, unfortunately, the downside of
>> time-based releases.  If we had been having this conversation two
>> weeks ago I would have very likely had a different answer.
> 
> The problem from my perspective is that the end-users have no way to
> determine when that boot option is needing to be set. Having an
> installation step of "check if things explode when you reboot" is just
> plain bad. Many times you don't even have access to a remote serial
> console to check why Xen didn't boot.

I guess I don't see the serial console aspect here: This sort of
boot issue can be seen on the normal screen as well. It occurs
neither too early nor too late to be visible. We could amend the
output by a hint towards this option.

Jan