From: David Brazdil <dbrazdil@google.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>,
kvmarm@lists.cs.columbia.edu, Jonathan Corbet <corbet@lwn.net>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>, Marc Zyngier <maz@kernel.org>,
James Morse <james.morse@arm.com>,
Julien Thierry <julien.thierry.kdev@gmail.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Dennis Zhou <dennis@kernel.org>, Tejun Heo <tj@kernel.org>,
Christoph Lameter <cl@linux.com>,
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, kernel-team@android.com
Subject: Re: [PATCH v3 06/23] kvm: arm64: Add kvm-arm.protected early kernel parameter
Date: Tue, 1 Dec 2020 14:43:49 +0000 [thread overview]
Message-ID: <20201201144349.bglz7yicc3peixe6@google.com> (raw)
In-Reply-To: <20201201140734.GA86881@C02TD0UTHF1T.local>
> > > be just me, but if you agree please update so that it doesn't give remote
> > > idea that it is not valid on VHE enabled hardware.
> > >
> > > I was trying to run this on the hardware and was trying to understand the
> > > details on how to do that.
> >
> > I see what you're saying, but !CONFIG_ARM64_VHE isn't accurate either. The
> > option makes sense if:
> > 1) all cores booted in EL2
> > == is_hyp_mode_available()
> > 2) ID_AA64MMFR1_EL1.VH=0 or !CONFIG_ARM64_VHE
> > == !is_kernel_in_hyp_mode()
> >
> > The former feels implied for KVM, the latter could be 'Valid if the kernel
> > is running in EL1'? WDYT?
>
> I reckon we can avoid the restriction if we instead add an early stub
> like with have for KASLR. That way we could parse the command line
> early, and if necessary re-initialize EL2 and drop to EL1 before the
> main kernel has to make any decisions about how to initialize things.
> That would allow us to have a more general kvm-arm.mode option where a
> single kernel Image could support:
>
> * "protected" mode on nVHE or VHE HW
> * "nvhe" mode on nVHE or VHE HW
> * "vhe" mode on VHE HW
>
> ... defaulting to VHE/nVHE modes depending on HW support.
>
> That would also be somewhat future-proof if we have to add other
> variants of protected mode in future, as we could extend the mode option
> with parameters for each mode.
Agreed that 'mode' is a more future-proof flag and I would very much love to
have an option to force nVHE on VHE HW. I however expect that the early stub
would not be a trivial addition and would not want to get into that in this
series. Could we agree on 'protected' as the only supported value for the time
being?
David
next prev parent reply other threads:[~2020-12-01 14:44 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-26 15:53 [PATCH v3 00/23] Opt-in always-on nVHE hypervisor David Brazdil
2020-11-26 15:53 ` [PATCH v3 01/23] psci: Support psci_ops.get_version for v0.1 David Brazdil
2020-11-26 17:21 ` Mark Rutland
2020-11-26 15:54 ` [PATCH v3 02/23] psci: Accessor for configured PSCI function IDs David Brazdil
2020-11-26 17:24 ` Mark Rutland
2020-11-26 17:29 ` David Brazdil
2020-11-26 17:34 ` Lorenzo Pieralisi
2020-11-26 15:54 ` [PATCH v3 03/23] arm64: Make cpu_logical_map() take unsigned int David Brazdil
2020-11-26 17:28 ` Mark Rutland
2020-12-02 15:44 ` David Brazdil
2020-11-26 15:54 ` [PATCH v3 04/23] arm64: Move MAIR_EL1_SET to asm/memory.h David Brazdil
2020-11-26 17:35 ` Mark Rutland
2020-12-01 13:58 ` David Brazdil
2020-11-26 15:54 ` [PATCH v3 05/23] arm64: Extract parts of el2_setup into a macro David Brazdil
2020-11-26 18:06 ` Mark Rutland
2020-12-01 13:55 ` David Brazdil
2020-11-26 15:54 ` [PATCH v3 06/23] kvm: arm64: Add kvm-arm.protected early kernel parameter David Brazdil
2020-11-27 16:32 ` Sudeep Holla
2020-12-01 13:19 ` David Brazdil
2020-12-01 14:07 ` Mark Rutland
2020-12-01 14:43 ` David Brazdil [this message]
2020-12-01 14:58 ` Mark Rutland
2020-11-26 15:54 ` [PATCH v3 07/23] kvm: arm64: Initialize MAIR_EL2 using a constant David Brazdil
2020-11-26 15:54 ` [PATCH v3 08/23] kvm: arm64: Remove vector_ptr param of hyp-init David Brazdil
2020-11-26 15:54 ` [PATCH v3 09/23] kvm: arm64: Move hyp-init params to a per-CPU struct David Brazdil
2020-11-26 15:54 ` [PATCH v3 10/23] kvm: arm64: Add .hyp.data..ro_after_init ELF section David Brazdil
2020-11-26 15:54 ` [PATCH v3 11/23] kvm: arm64: Support per_cpu_ptr in nVHE hyp code David Brazdil
2020-11-26 15:54 ` [PATCH v3 12/23] kvm: arm64: Create nVHE copy of cpu_logical_map David Brazdil
2020-11-26 15:54 ` [PATCH v3 13/23] kvm: arm64: Add SMC handler in nVHE EL2 David Brazdil
2020-11-26 15:54 ` [PATCH v3 14/23] kvm: arm64: Bootstrap PSCI " David Brazdil
2020-11-26 15:54 ` [PATCH v3 15/23] kvm: arm64: Add offset for hyp VA <-> PA conversion David Brazdil
2020-11-26 15:54 ` [PATCH v3 16/23] kvm: arm64: Forward safe PSCI SMCs coming from host David Brazdil
2020-11-27 10:14 ` Lorenzo Pieralisi
2020-12-02 17:49 ` David Brazdil
2020-11-27 16:51 ` Sudeep Holla
2020-12-01 13:20 ` David Brazdil
2020-11-26 15:54 ` [PATCH v3 17/23] kvm: arm64: Extract __do_hyp_init into a helper function David Brazdil
2020-11-26 15:54 ` [PATCH v3 18/23] kvm: arm64: Add function to enter host from KVM nVHE hyp code David Brazdil
2020-11-26 15:54 ` [PATCH v3 19/23] kvm: arm64: Intercept host's CPU_ON SMCs David Brazdil
2020-11-27 17:47 ` Sudeep Holla
2020-12-01 13:51 ` David Brazdil
2020-11-26 15:54 ` [PATCH v3 20/23] kvm: arm64: Intercept host's CPU_SUSPEND PSCI SMCs David Brazdil
2020-12-01 14:57 ` Mark Rutland
2020-11-26 15:54 ` [PATCH v3 21/23] kvm: arm64: Keep nVHE EL2 vector installed David Brazdil
2020-11-26 15:54 ` [PATCH v3 22/23] kvm: arm64: Trap host SMCs in protected mode David Brazdil
2020-11-26 15:54 ` [PATCH v3 23/23] kvm: arm64: Fix EL2 mode availability checks David Brazdil
2020-11-26 15:57 ` [PATCH v3 00/23] Opt-in always-on nVHE hypervisor Matthew Wilcox
2020-11-26 16:19 ` Marc Zyngier
2020-11-26 16:23 ` Matthew Wilcox
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=20201201144349.bglz7yicc3peixe6@google.com \
--to=dbrazdil@google.com \
--cc=catalin.marinas@arm.com \
--cc=cl@linux.com \
--cc=corbet@lwn.net \
--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-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=sudeep.holla@arm.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).