Re: [PATCH v2 04/28] arm64: Provide arm64 UAPI for other host architectures

[Steffen Eiden <seiden@linux.ibm.com>]

On Tue, Apr 28, 2026 at 05:55:56PM +0200, Steffen Eiden wrote:
> Enable the ARM64 userspace API to be used on non-arm64 host
> architectures, with initial support for s390.
> 
> The arm64 KVM UAPI headers are relocated to include/uapi/arch/arm64/,
> allowing non‑arm64 hosts (such as s390) to use the arm64 KVM userspace API.
> 
> To achieve architecture independence, some type aliases are introduced,
> which conditionally resolve to native arm64 types when building on arm64
> or to fallback to ABI compatible inline struct definitions on other
> architectures.
> 
> The build system is updated to install the moved UAPI headers to their
> original location but in and conditionally export arm64 architecture
> headers for s390. This infrastructure enables s390 systems to host arm64
> virtual machines while maintaining full compatibility with the existing
> arm64 KVM-UAPI, requiring only minimal, compatible changes to the arm64
> UAPI-headers itself.

@Will @Marc

I think doing it the other way around for the UPAI here might be the better
approach with less churn (esp for arm)

1) keep arch/arm64/include/uapi/asm/{kvm.h, sve_context.h} where they are
2) mark them as shared in the include guard similar as in the symlink variant
3) for s390 (and any other arch that wants them) install the headers to
   include/uapi/arch/arm64/asm

The only thing I fear with this (and also the symlink) approach is that it is
easy for you to include a header that we do not have on s390. This was the
reason I moved all the headers that are shared to a different location - to
stress that those are shared between multiple arches. Marking them as shared
in the include guard may also do the job well enough.

What do you think about this variant?

	Steffen

<snip>