linux-kernel - Re: [RFC PATCH 00/34] Running Qualcomm's Gunyah Guests via KVM in EL1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <b1db820e965996b4d236caf15736162f161223e6.camel@infradead.org>
Date: Thu, 19 Jun 2025 16:50:29 +0100
From: David Woodhouse <dwmw2@...radead.org>
To: Marc Zyngier <maz@...nel.org>, Karim Manaouil
 <karim.manaouil@...aro.org>,  Oliver Upton <oliver.upton@...ux.dev>
Cc: linux-kernel@...r.kernel.org, kvm@...r.kernel.org, 
 linux-arm-msm@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, 
 kvmarm@...ts.linux.dev, Alexander Graf <graf@...zon.com>, Alex Elder
 <elder@...nel.org>, Catalin Marinas <catalin.marinas@....com>, Fuad Tabba
 <tabba@...gle.com>, Joey Gouly <joey.gouly@....com>, Jonathan Corbet
 <corbet@....net>, Mark Brown <broonie@...nel.org>, Mark Rutland
 <mark.rutland@....com>, Paolo Bonzini <pbonzini@...hat.com>, Prakruthi
 Deepak Heragu <quic_pheragu@...cinc.com>, Quentin Perret
 <qperret@...gle.com>, Rob Herring <robh@...nel.org>,  Srinivas Kandagatla
 <srini@...nel.org>, Srivatsa Vaddagiri <quic_svaddagi@...cinc.com>, Will
 Deacon <will@...nel.org>, Haripranesh S <haripran@....qualcomm.com>, Carl
 van Schaik <cvanscha@....qualcomm.com>, Murali Nalajala
 <mnalajal@...cinc.com>,  Sreenivasulu Chalamcharla
 <sreeniva@....qualcomm.com>, Trilok Soni <tsoni@...cinc.com>, Stefan
 Schmidt <stefan.schmidt@...aro.org>
Subject: Re: [RFC PATCH 00/34] Running Qualcomm's Gunyah Guests via KVM in
 EL1

On Thu, 2025-04-24 at 17:57 +0100, Marc Zyngier wrote:
> On Thu, 24 Apr 2025 16:34:50 +0100,
> Oliver Upton <oliver.upton@...ux.dev> wrote:
> > 
> > On Thu, Apr 24, 2025 at 03:13:07PM +0100, Karim Manaouil wrote:
> > > This series introduces the capability of running Gunyah guests via KVM on
> > > Qualcomm SoCs shipped with Gunyah hypervisor [1] (e.g. RB3 Gen2).
> > > 
> > > The goal of this work is to port the existing Gunyah hypervisor support from a
> > > standalone driver interface [2] to KVM, with the aim of leveraging as much of the
> > > existing KVM infrastructure as possible to reduce duplication of effort around
> > > memory management (e.g. guest_memfd), irqfd, and other core components.
> > > 
> > > In short, Gunyah is a Type-1 hypervisor, meaning that it runs independently of any
> > > high-level OS kernel such as Linux and runs in a higher CPU privilege level than VMs.
> > > Gunyah is shipped as firmware and guests typically talk with Gunyah via hypercalls.
> > > KVM is designed to run as Type-2 hypervisor. This port allows KVM to run in EL1 and
> > > serve as the interface for VM lifecycle management,while offloading virtualization
> > > to Gunyah.
> > 
> > If you're keen on running your own hypervisor then I'm sorry, you get to
> > deal with it soup to nuts. Other hypervisors (e.g. mshv) have their own
> > kernel drivers for managing the host / UAPI parts of driving VMs.
> > 
> > The KVM arch interface is *internal* to KVM, not something to be
> > (ab)used for cramming in a non-KVM hypervisor. KVM and other hypervisors
> > can still share other bits of truly common infrastructure, like
> > guest_memfd.
> > 
> > I understand the value in what you're trying to do, but if you want it
> > to smell like KVM you may as well just let the user run it at EL2.
> 
> +1. KVM is not a generic interface for random third party hypervisors.

I don't think that should be true in the general case. At least, it
depends on whether you mean the literal implementation in
arch/arm64/kvm/ vs. the userspace API and set of ioctls on /dev/kvm.

The kernel exists to provide a coherent userspace API for all kinds of
hardware. That's what it's *for*. It provides users with a consistent
interface to all kinds of network cards, serial ports, etc. — and that
includes firmware/platform features too. 

There's no reason that shouldn't be the same for virtualisation. If the
kernel cannot provide an API which supports *all* kinds of
virtualization, then it seems like we've done something wrong.

On x86 we have /dev/kvm backed by different vendor-specific support for
Intel vs. AMD. And in recent years we've retrofitted confidential
compute to it too, with SEV-SNP, TDX, etc.

We haven't resorted to saying "no, sorry, KVM doesn't support that".

We shouldn't say that for Arm either.


Download attachment "smime.p7s" of type "application/pkcs7-signature" (5069 bytes)