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

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Fri, Mar 26, 2021 at 01:15:42PM +0000, Ian Jackson wrote:
> Tamas K Lengyel writes ("Re: [PATCH v1.1 2/2] x86/hpet: Don't enable legacy 
> replacement mode unconditionally"):
> > 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. So that's not a realistic route
> > that can be taken. If Jan's patch is applied then the only thing I'll
> > be able to do is make all installations always-enable this option even
> > on systems that would have booted fine otherwise without it. It is
> > unclear if that has any downsides of its own and could very well just
> > kick the can down the road and lead to other issues.
> 
> Thanks for the clear explanation.
> 
> I think our options are:
> 
>  1. What is currently in xen.git#staging-4.15: some different set of
>     machines do not work (reliably? at all?), constituting a
>     regression on older hardware.
> 
>  2. Jan's patch, with the consequences you describe.  Constituing a
>     continued failure to properly support the newer hardware.
> 
>  3. Andy's patches which are not finished yet and are therefore high
>     risk.  Ie, delay the release.
> 
> Please let me know if you think this characterisation of the situation
> is inaccurate or misleading.
> 
> This is not a good set of options.
> 
> Of them, I still think I would choose (2).  But I would love it if
> someone were to come up with a better suggestion (perhaps a variant on
> one of the above).

As the FreeBSD Xen packager I would consider simply adding Andrew's
patches to the port under my own risk, and maybe do the same with the
vpt performance fix, but that one is riskier as an issue there could
lead to XSA-336 being re-introduced, so I need to carefully consider.
I've cherry picked patches before to fix other issues before they hit
the stable branches.

I'm still trying to go over all emails, but if 2. is the chosen route
could we describe in the release notes those issues and maybe provide
hashes for the alternative patches provided they are in unstable by
the time of the release?

That way packagers will get an option to cherry pick those fixes at
their own risk. It's not the best model, as we are just pushing a
decisions towards consumers which might not have good judgment about
the effect of those issues and the risk of the fixes, but seeing how
much controversy this has caused it's likely an option to be
considered so that we are not seen as hiding such patches from
downstreams.

Thanks, Roger.