linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: David Brazdil <dbrazdil@google.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	kernel-team@android.com,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Quentin Perret <qperret@google.com>,
	linux-kernel@vger.kernel.org, James Morse <james.morse@arm.com>,
	linux-arm-kernel@lists.infradead.org, Tejun Heo <tj@kernel.org>,
	Dennis Zhou <dennis@kernel.org>, Christoph Lameter <cl@linux.com>,
	Will Deacon <will@kernel.org>,
	kvmarm@lists.cs.columbia.edu,
	Julien Thierry <julien.thierry.kdev@gmail.com>,
	Andrew Scull <ascull@google.com>
Subject: Re: [RFC PATCH 00/26] kvm: arm64: Always-on nVHE hypervisor
Date: Fri, 06 Nov 2020 12:25:05 +0000	[thread overview]
Message-ID: <60a77f17737ffcfa31c3d1dfacc24384@kernel.org> (raw)
In-Reply-To: <20201104183630.27513-1-dbrazdil@google.com>

On 2020-11-04 18:36, David Brazdil wrote:
> As we progress towards being able to keep guest state private to the
> host running nVHE hypervisor, this series allows the hypervisor to
> install itself on newly booted CPUs before the host is allowed to run
> on them.
> 
> To this end, the hypervisor starts trapping host SMCs and intercepting
> host's PSCI CPU_ON/OFF/SUSPEND calls. It replaces the host's entry 
> point
> with its own, initializes the EL2 state of the new CPU and installs
> the nVHE hyp vector before ERETing to the host's entry point.
> 
> Other PSCI SMCs are forwarded to EL3, though only the known set of SMCs
> implemented in the kernel is allowed. Non-PSCI SMCs are also forwarded
> to EL3. Future changes will need to ensure the safety of all SMCs wrt.
> private guests.
> 
> The host is still allowed to reset EL2 back to the stub vector, eg. for
> hibernation or kexec, but will not disable nVHE when there are no VMs.
> 
> Tested on Rock Pi 4b.
> 
> 
> Sending this as an RFC to get feedback on the following decisions:
> 
> 1) The kernel checks new cores' features against the finalized system
> capabilities. To avoid the need to move this code/data to EL2, the
> implementation only allows to boot cores that were online at the time 
> of
> KVM initialization.
> 
> 2) Trapping and forwarding SMCs cannot be switched off. This could 
> cause
> issues eg. if EL3 always returned to EL1. A kernel command line flag 
> may
> be needed to turn the feature off on such platforms.

I'd rather have it the other way around (buy-in rather than turn off).
On top of the potential issue with stupid EL3s, there is the issue that
PSCI is optional, and that protected VMs won't be able to work without
it. Another related thing is that EL3 itself is optional.

Note that this flag shouldn't be specific to PSCI proxying. It should 
also
control Stage-2 wrapping, and the whole pKVM.

Thanks,

         M.
-- 
Jazz is not dead. It just smells funny...

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

      parent reply	other threads:[~2020-11-06 12:26 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-04 18:36 [RFC PATCH 00/26] kvm: arm64: Always-on nVHE hypervisor David Brazdil
2020-11-04 18:36 ` [RFC PATCH 01/26] psci: Export configured PSCI version David Brazdil
2020-11-05  9:47   ` Marc Zyngier
2020-11-04 18:36 ` [RFC PATCH 02/26] psci: Export configured PSCI function IDs David Brazdil
2020-11-05  9:53   ` Marc Zyngier
2020-11-04 18:36 ` [RFC PATCH 03/26] psci: Export psci_cpu_suspend_feature David Brazdil
2020-11-04 18:36 ` [RFC PATCH 04/26] arm64: Move MAIR_EL1_SET to asm/memory.h David Brazdil
2020-11-04 18:36 ` [RFC PATCH 05/26] kvm: arm64: Initialize MAIR_EL2 using a constant David Brazdil
2020-11-04 18:36 ` [RFC PATCH 06/26] kvm: arm64: Add .hyp.data ELF section David Brazdil
2020-11-04 18:36 ` [RFC PATCH 07/26] kvm: arm64: Support per_cpu_ptr in nVHE hyp code David Brazdil
2020-11-04 18:36 ` [RFC PATCH 08/26] kvm: arm64: Create nVHE copy of cpu_logical_map David Brazdil
2020-11-04 18:36 ` [RFC PATCH 09/26] kvm: arm64: Move hyp-init params to a per-CPU struct David Brazdil
2020-11-04 18:36 ` [RFC PATCH 10/26] kvm: arm64: Refactor handle_trap to use a switch David Brazdil
2020-11-04 18:36 ` [RFC PATCH 11/26] kvm: arm64: Extract parts of el2_setup into a macro David Brazdil
2020-11-04 18:36 ` [RFC PATCH 12/26] kvm: arm64: Add SMC handler in nVHE EL2 David Brazdil
2020-11-05 11:08   ` Marc Zyngier
2020-11-04 18:36 ` [RFC PATCH 13/26] kvm: arm64: Bootstrap PSCI " David Brazdil
2020-11-04 18:36 ` [RFC PATCH 14/26] kvm: arm64: Forward safe PSCI SMCs coming from host David Brazdil
2020-11-04 18:36 ` [RFC PATCH 15/26] arm64: kvm: Add standalone ticket spinlock implementation for use at hyp David Brazdil
2020-11-04 18:36 ` [RFC PATCH 16/26] kvm: arm64: Add offset for hyp VA <-> PA conversion David Brazdil
2020-11-04 18:36 ` [RFC PATCH 17/26] kvm: arm64: Bootstrap PSCI power state of host CPUs David Brazdil
2020-11-04 18:36 ` [RFC PATCH 18/26] kvm: arm64: Intercept PSCI_CPU_OFF host SMC calls David Brazdil
2020-11-05 11:30   ` Marc Zyngier
2020-11-05 11:42     ` David Brazdil
2020-11-04 18:36 ` [RFC PATCH 19/26] kvm: arm64: Extract __do_hyp_init into a helper function David Brazdil
2020-11-04 18:36 ` [RFC PATCH 20/26] kvm: arm64: Add CPU entry point in nVHE hyp David Brazdil
2020-11-04 18:36 ` [RFC PATCH 21/26] kvm: arm64: Add function to enter host from KVM nVHE hyp code David Brazdil
2020-11-04 18:36 ` [RFC PATCH 22/26] kvm: arm64: Intercept PSCI_CPU_ON host SMC calls David Brazdil
2020-11-04 18:36 ` [RFC PATCH 23/26] kvm: arm64: Intercept host's CPU_SUSPEND PSCI SMCs David Brazdil
2020-11-05 10:34   ` Andrew Walbran
2020-11-05 11:04     ` David Brazdil
2020-11-04 18:36 ` [RFC PATCH 24/26] kvm: arm64: Keep nVHE EL2 vector installed David Brazdil
2020-11-04 18:36 ` [RFC PATCH 25/26] kvm: arm64: Trap host SMCs David Brazdil
2020-11-04 18:36 ` [RFC PATCH 26/26] kvm: arm64: Fix EL2 mode availability checks David Brazdil
2020-11-06 12:25 ` Marc Zyngier [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=60a77f17737ffcfa31c3d1dfacc24384@kernel.org \
    --to=maz@kernel.org \
    --cc=ascull@google.com \
    --cc=catalin.marinas@arm.com \
    --cc=cl@linux.com \
    --cc=dbrazdil@google.com \
    --cc=dennis@kernel.org \
    --cc=james.morse@arm.com \
    --cc=julien.thierry.kdev@gmail.com \
    --cc=kernel-team@android.com \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=mark.rutland@arm.com \
    --cc=qperret@google.com \
    --cc=suzuki.poulose@arm.com \
    --cc=tj@kernel.org \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).