Re: [PATCH v2] KVM: arm64: Work around C1-Pro erratum 4193714 for protected guests

[Marc Zyngier <maz@kernel.org>]

On Wed, 06 May 2026 14:37:41 +0100,
Vincent Donnefort <vdonnefort@google.com> wrote:
> 
> On Tue, May 05, 2026 at 05:52:03PM +0100, Catalin Marinas wrote:
> > From: James Morse <james.morse@arm.com>
> > 
> > C1-Pro cores with SME have an erratum where TLBI+DSB does not complete
> > all outstanding SME accesses. Instead a DSB needs to be executed on the
> > affected CPUs. The implication is that pages cannot be unmapped from the
> > host Stage 2 and then provided to a protected guest or to the
> > hypervisor. Host SME accesses may still complete after this point.
> > 
> > This erratum breaks pKVM's guarantees, and the workaround is hard to
> > implement as EL2 and EL1 share a security state meaning EL1 can mask
> > IPIs sent by EL2, leading to interrupt blackouts.
> > 
> > Instead, do this in EL3. This has the advantage of a separate security
> > state, meaning lower EL cannot mask the IPI. It is also simpler for EL3
> > to know about CPUs that are off or in PSCI's CPU_SUSPEND.
> > 
> > Add the needed hook to host_stage2_set_owner_metadata_locked(). This
> > covers the cases where the host loses access to a page:
> > 
> >   __pkvm_host_donate_guest()
> >   __pkvm_guest_unshare_host()
> >   host_stage2_set_owner_locked() when owner_id == PKVM_ID_HYP
> > 
> > Since pKVM relies on the firmware call for correctness, check for the
> > firmware counterpart during protected KVM initialisation and fail the
> > pKVM initialisation if it is missing.
> > 
> > Signed-off-by: James Morse <james.morse@arm.com>
> > Co-developed-by: Catalin Marinas <catalin.marinas@arm.com>
> > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> > Cc: Mark Rutland <mark.rutland@arm.com>
> > Cc: Marc Zyngier <maz@kernel.org>
> > Cc: Oliver Upton <oupton@kernel.org>
> > Cc: Will Deacon <will@kernel.org>
> > Cc: Vincent Donnefort <vdonnefort@google.com>
> > Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>
> > Cc: Sudeep Holla <sudeep.holla@kernel.org>
> > ---
> > 
> > Added the kvm-arm list this time, missed it in v1.
> > 
> > Changelog below but it's only probing if the firmware counterpart is
> > present and disable the hypervisor. If that's too harsh, we can leave it
> > as a warning and maybe add a static label/flag to avoid the unnecessary
> > SMC call on page donation.
> 
> As the pKVM upstream support is currently experimental and the protection
> incomplete (see Documentation/virt/kvm/arm/pkvm.rst) perhaps a simple WARN() is
> enough?

I'd rather not set expectations that this behaviour can be preserved
over time. If someone with a broken CPU starts making use of pKVM,
even as a toy, they can legitimately expect this to be working in the
long run without any firmware update.

I would prefer setting the record straight from the start that this
isn't something that can be supported. Someone motivated enough can
always remove the check and run stuff, at their own risks.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.