[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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. 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.

Tamas



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.