Re: [RFC PATCH] arm64: unify WORKAROUND_SPECULATIVE_AT_{NVHE,VHE}

From: Will Deacon <will@kernel.org>
To: James Morse <james.morse@arm.com>
Cc: qwandor@google.com, Marc Zyngier <maz@kernel.org>,
	tabba@google.com, Steven Price <steven.price@arm.com>,
	wedsonaf@google.com, dbrazdil@google.com,
	kernel-team@android.com, kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH] arm64: unify WORKAROUND_SPECULATIVE_AT_{NVHE,VHE}
Date: Fri, 27 Mar 2020 16:59:36 +0000	[thread overview]
Message-ID: <20200327165935.GA8048@willie-the-truck> (raw)
In-Reply-To: <a8cc7a17-cb84-3e52-15f4-87b27a01876b@arm.com>

Hi James,

On Fri, Mar 27, 2020 at 04:11:56PM +0000, James Morse wrote:
> On 3/27/20 2:39 PM, Andrew Scull wrote:
> > Errata 1165522, 1319367 and 1530923 each allow TLB entries to be
> > allocated as a result of a speculative AT instruction. In order to
> > avoid mandating VHE on certain affected CPUs, apply the workaround to
> > both the nVHE and the VHE case for all affected CPUs.
> 
> You're booting a VHE capable system without VHE, and need KVM?
> Do tell!

I'll stick my neck out for this part...

Basically, we're looking at enabling virtualisation on Android through
KVM and we're going to be upstreaming more of this as it gets going.
One of the goals of this work is to provide an environment where virtual
machines can run in isolation from the KVM host; in such a design, the
guest memory must not be accessible to the host, so this doesn't lend
itself at all to VHE. Our current work is focussing on extending the nVHE
__hyp_text so that things like stage-2 page table and vCPU state is all
handled there, with a stage-2 put over the host kernel to prevent access
to guest memory. The host is still responsible for scheduling vCPUs, so
a compromised host can cause a DoS but it's the data integrity that we
really care about. We're looking at implementing this on top of the SPCI
spec from Arm, where the VMs are a lot less dynamic than a traditional
KVM invocation but implement message passing and shared memory interfaces
so that we can still use things like virtio. We're also aiming to support
SPCI partitions alongside traditional VMs, although the stage-2 must still
be handled at EL2 for both types of guest.

It's a bit like a Type-1.5 hypervisor ;)

Anyway, there's plenty to do, but one of the exercises is removing some of
the artificial Kconfig dependencies we have on VHE. This erratum workaround
is one of them, but there are others such as SVE and Pointer Auth.

> Would enabling the nVHE workaround on a VHE capable part solve your problem?

Could do, but it seems a bit weird to enable the workarounds independently
once both VHE and nVHE are supported. We probably need to use has_vhe() to
distinguish the two paths, rather than rely on the presence of the
workaround as a proxy for that.

Will
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm