Re: Xen 4.16 development update; request for regression bug reports

[Jan Beulich <jbeulich@xxxxxxxx>]

On 27.09.2021 16:24, Ian Jackson wrote:
> The mainline development branch of Xen is has taken the first step
> towards stabilisation for 4.16: new features not yet submitted, at
> least in draft form, will now be deferred to the following release.
> 
> We aim to make each Xen release as good as possible, and that includes
> high quality and particularly an absence of serious regressions.
> To help deliver this as Release Manager for Xen 4.16, I need the help
> of the Xen developer and user community
> 
> In particular, please would users and developers make sure that I know
> about:
> 
>  * Regressions in the current development branch (xen-unstable)
>    compared to Xen 4.15;
> 
>  * Major or important work which is targeted for 4.16, but at risk
>    of missing the deadlines.

Effectively all of the series that have been stuck for a more or less
long periods of time were originally intended for 4.16:

- xvmalloc() / x86 xstate area / x86 CPUID / AMX+XFD
- x86: memcpy() / memset() (non-)ERMS flavors plus fallout
- x86/mm: large parts of P2M code and struct p2m_domain are HVM-only
- x86emul: a few small steps towards disintegration
- x86: more or less log-dirty related improvements
- IOMMU: superpage support when not sharing pagetables
- AMD/IOMMU: further work split from XSA-378
- gnttab: further work from XSA-380 / -382 context
- x86/mwait-idle: updates from Linux
- x86/boot: (mostly) video mode handling adjustments

There are further individual patches, which I've omitted. The only one
that I think (or should I say hope) is on track is "x86/PVH: Dom0
building adjustments".

It would of course also be nice for Anthony's "xen: Build system
improvements, now with out-of-tree build!" to go in, but it's hard to
predict whether the remaining almost 40 patches can get reviewed in
time. I've been meaning to get through with this (and others), but
other stuff keeps popping up.

Additionally there is Marek's "x86/xstate: reset cached register values
on resume", which Andrew has been meaning to supply a superset patch for.
He has hence been objecting to this patch going in, but seeing that 1.5
months have passed now I think this wants reconsidering.

Similarly there is Roger's even older "x86/viridian: EOI MSR should
always happen in affected vCPU context".

Jan