Re: [RFC PATCH 06/34] KVM: gunyah: Add initial Gunyah backend support

[David Woodhouse <dwmw2@infradead.org>]

[-- Attachment #1: Type: text/plain, Size: 1628 bytes --]

On Thu, 2025-04-24 at 15:13 +0100, Karim Manaouil wrote:
> 
> - Introduces a new Kconfig split: `CONFIG_KVM_ARM` for native support,
>   and a variant for Gunyah-backed virtualization.
> - Adds `gunyah.c`, a new arch backend file that implements the minimal
>   KVM architecture callbacks and stub interfaces required by the KVM
>   core to build and boot.
> - Refactors Makefile and build rules to support mutually exclusive
>   builds of `CONFIG_KVM_ARM` and `CONFIG_GUNYAH`.
> - Introduces a dummy implementation of required KVM stubs such as:
>   `kvm_arch_init_vm()`, `kvm_arch_vcpu_create()`, `kvm_age_gfn()`, etc.

I quite like this, conceptually. I do think it's important for the
kernel to provide a generic virtualization API regardless of the
underlying hardware/firmware — that is, after all, what an OS kernel is
*for*. So the answer "not in KVM" is just fundamentally not realistic.

I'd like to see fewer #ifdefs though. The model we have on x86 with
static_calls for the AMD vs. Intel back ends seems to work out OK.

We ought to be able to come up with a model inspired by x86 where we
allow certain methods to be provided by one of many sets of 'lowvisor'
ops or whatever we want to call them:

 • Native KVM (at EL2)
 • pKVM
 • Gunyah
 • CCA
 • ... and potentially one or two others.

Currently we have completely separate work on some of those; can we
combine at least the basic hooks/operations and come up with something
which is minimally intrusive where each one just plugs in its own
implementation but the KVM userspace API is as unified as possible?

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]