Re: Xen 4.19 release status tracking list

[Jan Beulich <jbeulich@xxxxxxxx>]

On 05.02.2024 20:23, Oleksii Kurochko wrote:
> Hello everyone,
> 
> I would like to share with you a list for status tracking based on Xen ML:
> 
> Arm:
>   * [PATCH v5 00/13] Arm cache coloring [
> https://lore.kernel.org/xen-devel/20240102095138.17933-1-carlo.nonato@xxxxxxxxxxxxxxx/
> ]
>   * [PATCH v1 repost 0/4] xen/arm64: Rework the MMU-off code (idmap)
> so it is self-contained [
> https://lore.kernel.org/xen-devel/20240116143709.86584-1-julien@xxxxxxx/
> ]
>   * [PATCH v13 00/14] PCI devices passthrough on Arm, part 3 [
> https://lore.kernel.org/xen-devel/20240202213321.1920347-1-stewart.hildebrand@xxxxxxx/
> ]
> 
> PPC:
>   *  [PATCH v2 0/7] Early Boot Allocation on Power [
> https://lore.kernel.org/xen-devel/cover.1702607884.git.sanastasio@xxxxxxxxxxxxxxxxxxxxx/
> ]
> 
> RISC-V:
>   *  [PATCH v4 00/30]  Enable build of full Xen for RISC-V [
> https://lore.kernel.org/xen-devel/cover.1707146506.git.oleksii.kurochko@xxxxxxxxx/
> ]
> 
> x86:
>   * [PATCH 0/4] iommu/x86: fixes/improvements for unity range checks [
> https://lore.kernel.org/xen-devel/20240201170159.66330-1-roger.pau@xxxxxxxxxx/
> ]
>   * [PATCH 0/8] x86: support AVX10.1 [
> https://lore.kernel.org/xen-devel/298db76f-d0ee-4d47-931f-1baa1a7546cf@xxxxxxxx/
> ]
>   * [PATCH v13 00/35] x86: enable FRED for x86-64 [
> https://lore.kernel.org/xen-devel/20231205105030.8698-1-xin3.li@xxxxxxxxx/
> ]

This is a kernel series. I don't expect FRED support is in scope for
4.19.

>   * [PATCH v4 0/8] x86emul: misc additions
> https://lore.kernel.org/xen-devel/9dd23064-c79e-4a50-9c71-c0e73b189944@xxxxxxxx/
>   * [PATCH 0/7] VT-d: SATC handling and ATS tidying [
> https://lore.kernel.org/xen-devel/25506838-b818-4686-8c16-3a198338af44@xxxxxxxx/
> ]
>   * [XEN PATCH 0/9] x86: parallelize AP bring-up during boot [
> https://lore.kernel.org/xen-devel/cover.1699982111.git.krystian.hebel@xxxxxxxxx/
> ]
>   * [PATCH v2 00/12] x86: memcpy() / memset() (non-)ERMS flavors plus
> fallout [ 
> https://lore.kernel.org/xen-devel/8f56a8f4-0482-932f-96a9-c791bebb4610@xxxxxxxx/
> ]
> 
> common:
>   * annotate entry points with type and size" series [
> https://lore.kernel.org/xen-devel/5e74a501-2824-42af-804b-47b515aa9bcf@xxxxxxxx/
> ]

The bulk of this has gone in, but there'll want to be follow-ups.

>   * [PATCH v2 0/8] limit passing around of cpu_user_regs [
> https://lore.kernel.org/xen-devel/33db57a2-b569-4fa8-b0b0-36ea92528d7b@xxxxxxxx/
> ]
>   * [PATCH v2 (resend) 00/27] Remove the directmap [
> https://lore.kernel.org/xen-devel/20240116192611.41112-1-eliasely@xxxxxxxxxx/
> ]
>   * [PATCH v4 00/32] tools: enable xenstore-stubdom to use 9pfs [
> https://lore.kernel.org/xen-devel/20240205105001.24171-1-jgross@xxxxxxxx/
> ]
>   * [PATCH v7 0/7] Introduce generic headers [
> https://lore.kernel.org/xen-devel/cover.1706281994.git.oleksii.kurochko@xxxxxxxxx/
> ]
>   * [PATCH] move __read_mostly to xen/cache.h
> [https://lore.kernel.org/xen-devel/f25eb5c9-7c14-6e23-8535-2c66772b333e@xxxxxxxx/]
>   * [PATCH v2] NUMA: no need for asm/numa.h when !NUMA [
> https://lore.kernel.org/xen-devel/94cffa48-5e31-4557-827d-c6dec6031d05@xxxxxxxx/
> ]

This went in already.

>   * [XEN PATCH v2 1/3] xen: introduce STATIC_ASSERT_UNREACHABLE() [
> https://lore.kernel.org/xen-devel/42fc6ae8d3eb802429d29c774502ff232340dc84.1706259490.git.federico.serafini@xxxxxxxxxxx/
> ]
>   * [PATCH] xen: move BUG_ON(), WARN_ON(), ASSERT(),
> ASSERT_UNREACHABLE() to xen/bug.h [
> https://lore.kernel.org/xen-devel/4887b2d91a4bf2e8b4b66f03964259651981403b.1706897023.git.oleksii.kurochko@xxxxxxxxx/
> ]
>   * [PATCH] xen/lib: introduce generic find next bit operations [
> https://lore.kernel.org/xen-devel/52730e6314210ba4164a9934a720c4fda201447b.1706266854.git.oleksii.kurochko@xxxxxxxxx/
> ]
> 
> Please reply with items you would like to see in 4.19 so that people
> know what is happening and prioritize accordingly.

Beyond (on x86) AVX10 I'd like to see whether we can also make some
progress towards supporting APX. That'll be quite a bit of work, though,
including quite a bit of reviews that are likely to end up on the
backburner (as has been commonly happening for, especially, more
involved emulator changes).

Jan