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:
smime.p7s
Description: S/MIME cryptographic signature
