Re: [PATCH][4.15] x86/HPET: don't enable legacy replacement mode unconditionally

[Jan Beulich <jbeulich@xxxxxxxx>]

On 24.03.2021 12:37, Tamas K Lengyel wrote:
> On Wed, Mar 24, 2021 at 6:34 AM Jan Beulich <jbeulich@xxxxxxxx> wrote:
>>
>> Commit e1de4c196a2e ("x86/timer: Fix boot on Intel systems using ITSSPRC
>> static PIT clock gating") was reported to cause boot failures on certain
>> AMD Ryzen systems. Until we can figure out what the actual issue there
>> is, skip this new part of HPET setup by default. Introduce a "hpet"
>> command line option to allow enabling this on hardware where it's really
>> needed for Xen to boot successfully (i.e. where the PIT doesn't drive
>> the timer interrupt).
>>
>> Since it makes little sense to introduce just "hpet=legacy-replacement",
>> also allow for a boolean argument as well as "broadcast" to replace the
>> separate "hpetbroadcast" option.
> 
> While having the command line option to control it is fine what would
> really be the best solution is if Xen could figure out when the
> legacy-replacement option is necessary to begin with and enable it on
> its own, even if it's done as a fallback route.

This was the original plan, but no patch has arrived by now. I can
imagine this being due to things being easier to state than to
actually carry out. Plus of course this fallback approach still
isn't ideal - even better would be if we could address the actual
failure. I for one lack sufficient technical data to at least try
to think of possible solutions.

> We'll have issues with
> telling users when the option is needed and when it isn't. I don't
> like the idea of users having to go through a route of "well, let's
> see if Xen boots and if you get this weird crash/reboot add this
> obscure boot option". It's just a bad user experience all around.

I can't see how it's worse than what we've had so far, crashing
during boot _without_ there being any option available.

Jan