From: Mark Rutland <mark.rutland@arm.com>
To: David Brazdil <dbrazdil@google.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:58:40 +0000 [thread overview]
Message-ID: <20201201145840.GC86881@C02TD0UTHF1T.local> (raw)
In-Reply-To: <20201201144349.bglz7yicc3peixe6@google.com>
On Tue, Dec 01, 2020 at 02:43:49PM +0000, David Brazdil wrote:
> > > > 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?
Sure, that works for me.
Thanks,
Mark.
next prev parent reply other threads:[~2020-12-01 14:59 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
2020-12-01 14:58 ` Mark Rutland [this message]
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=20201201145840.GC86881@C02TD0UTHF1T.local \
--to=mark.rutland@arm.com \
--cc=catalin.marinas@arm.com \
--cc=cl@linux.com \
--cc=corbet@lwn.net \
--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-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lorenzo.pieralisi@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).