* [PATCH v3 00/23] Opt-in always-on nVHE hypervisor
@ 2020-11-26 15:53 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:53 UTC (permalink / raw)
To: kvmarm
Cc: Mark Rutland, Lorenzo Pieralisi, kernel-team, Jonathan Corbet,
Catalin Marinas, Suzuki K Poulose, linux-doc, linux-kernel,
Sudeep Holla, James Morse, linux-arm-kernel, Marc Zyngier,
Tejun Heo, Dennis Zhou, Christoph Lameter, David Brazdil,
Will Deacon, Julien Thierry
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.
All functionality described below is opt-in, guarded by an early param
'kvm-arm.protected'. Future patches specific to the new "protected" mode
should be hidden behind the same param.
The hypervisor starts trapping host SMCs and intercepting host's PSCI
CPU_ON/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.
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 and therefore had been checked already.
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, based on kvmarm/queue, itself on top of 5.10-rc4.
Patches also available at:
https://android-kvm.googlesource.com/linux topic/psci-on-master_v3
changes since v2:
* avoid non-spec error in CPU_SUSPEND
* refuse to init without PSCI
* compute hyp VA args of hyp-init in hyp instead of using params struct
* use hyp_symbol_addr in per-cpu calls
* simplify memory.h/sysreg.h includes
* rebase on kvmarm/queue, use trap handler args macros
changes since v1:
* early param sets a capability instead of a static key
* assume SMCCC v1.2 for host SMC forwarding
* fix reserved SMC ID range for PSCI
* split init_el2_state into smaller macros, move to el2_setup.h
* many small cleanups
changes since RFC:
* add early param to make features opt-in
* simplify CPU_ON/SUSPEND implementation
* replace spinlocks with CAS atomic
* make cpu_logical_map ro_after_init
David Brazdil (23):
psci: Support psci_ops.get_version for v0.1
psci: Accessor for configured PSCI function IDs
arm64: Make cpu_logical_map() take unsigned int
arm64: Move MAIR_EL1_SET to asm/memory.h
arm64: Extract parts of el2_setup into a macro
kvm: arm64: Add kvm-arm.protected early kernel parameter
kvm: arm64: Initialize MAIR_EL2 using a constant
kvm: arm64: Remove vector_ptr param of hyp-init
kvm: arm64: Move hyp-init params to a per-CPU struct
kvm: arm64: Add .hyp.data..ro_after_init ELF section
kvm: arm64: Support per_cpu_ptr in nVHE hyp code
kvm: arm64: Create nVHE copy of cpu_logical_map
kvm: arm64: Add SMC handler in nVHE EL2
kvm: arm64: Bootstrap PSCI SMC handler in nVHE EL2
kvm: arm64: Add offset for hyp VA <-> PA conversion
kvm: arm64: Forward safe PSCI SMCs coming from host
kvm: arm64: Extract __do_hyp_init into a helper function
kvm: arm64: Add function to enter host from KVM nVHE hyp code
kvm: arm64: Intercept host's CPU_ON SMCs
kvm: arm64: Intercept host's CPU_SUSPEND PSCI SMCs
kvm: arm64: Keep nVHE EL2 vector installed
kvm: arm64: Trap host SMCs in protected mode
kvm: arm64: Fix EL2 mode availability checks
.../admin-guide/kernel-parameters.txt | 5 +
arch/arm64/include/asm/cpucaps.h | 3 +-
arch/arm64/include/asm/el2_setup.h | 182 +++++++++++
arch/arm64/include/asm/kvm_arm.h | 1 +
arch/arm64/include/asm/kvm_asm.h | 8 +-
arch/arm64/include/asm/kvm_hyp.h | 4 +-
arch/arm64/include/asm/kvm_mmu.h | 26 +-
arch/arm64/include/asm/memory.h | 13 +
arch/arm64/include/asm/percpu.h | 6 +
arch/arm64/include/asm/sections.h | 1 +
arch/arm64/include/asm/smp.h | 4 +-
arch/arm64/include/asm/virt.h | 26 ++
arch/arm64/kernel/asm-offsets.c | 3 +
arch/arm64/kernel/cpufeature.c | 29 ++
arch/arm64/kernel/head.S | 144 +--------
arch/arm64/kernel/image-vars.h | 3 +
arch/arm64/kernel/setup.c | 2 +-
arch/arm64/kernel/vmlinux.lds.S | 10 +
arch/arm64/kvm/arm.c | 101 ++++--
.../arm64/kvm/hyp/include/nvhe/trap_handler.h | 18 ++
arch/arm64/kvm/hyp/nvhe/Makefile | 3 +-
arch/arm64/kvm/hyp/nvhe/host.S | 47 +++
arch/arm64/kvm/hyp/nvhe/hyp-init.S | 97 +++++-
arch/arm64/kvm/hyp/nvhe/hyp-main.c | 45 ++-
arch/arm64/kvm/hyp/nvhe/hyp-smp.c | 40 +++
arch/arm64/kvm/hyp/nvhe/hyp.lds.S | 1 +
arch/arm64/kvm/hyp/nvhe/psci-relay.c | 296 ++++++++++++++++++
arch/arm64/kvm/hyp/nvhe/switch.c | 5 +-
arch/arm64/kvm/va_layout.c | 30 +-
arch/arm64/mm/proc.S | 15 +-
drivers/firmware/psci/psci.c | 23 +-
include/linux/psci.h | 10 +
32 files changed, 999 insertions(+), 202 deletions(-)
create mode 100644 arch/arm64/include/asm/el2_setup.h
create mode 100644 arch/arm64/kvm/hyp/include/nvhe/trap_handler.h
create mode 100644 arch/arm64/kvm/hyp/nvhe/hyp-smp.c
create mode 100644 arch/arm64/kvm/hyp/nvhe/psci-relay.c
--
2.29.2.454.gaff20da3a2-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 147+ messages in thread* [PATCH v3 00/23] Opt-in always-on nVHE hypervisor
@ 2020-11-26 15:53 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:53 UTC (permalink / raw)
To: kvmarm
Cc: Lorenzo Pieralisi, kernel-team, Jonathan Corbet, Catalin Marinas,
linux-doc, linux-kernel, Sudeep Holla, linux-arm-kernel,
Marc Zyngier, Tejun Heo, Dennis Zhou, Christoph Lameter,
Will Deacon
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.
All functionality described below is opt-in, guarded by an early param
'kvm-arm.protected'. Future patches specific to the new "protected" mode
should be hidden behind the same param.
The hypervisor starts trapping host SMCs and intercepting host's PSCI
CPU_ON/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.
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 and therefore had been checked already.
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, based on kvmarm/queue, itself on top of 5.10-rc4.
Patches also available at:
https://android-kvm.googlesource.com/linux topic/psci-on-master_v3
changes since v2:
* avoid non-spec error in CPU_SUSPEND
* refuse to init without PSCI
* compute hyp VA args of hyp-init in hyp instead of using params struct
* use hyp_symbol_addr in per-cpu calls
* simplify memory.h/sysreg.h includes
* rebase on kvmarm/queue, use trap handler args macros
changes since v1:
* early param sets a capability instead of a static key
* assume SMCCC v1.2 for host SMC forwarding
* fix reserved SMC ID range for PSCI
* split init_el2_state into smaller macros, move to el2_setup.h
* many small cleanups
changes since RFC:
* add early param to make features opt-in
* simplify CPU_ON/SUSPEND implementation
* replace spinlocks with CAS atomic
* make cpu_logical_map ro_after_init
David Brazdil (23):
psci: Support psci_ops.get_version for v0.1
psci: Accessor for configured PSCI function IDs
arm64: Make cpu_logical_map() take unsigned int
arm64: Move MAIR_EL1_SET to asm/memory.h
arm64: Extract parts of el2_setup into a macro
kvm: arm64: Add kvm-arm.protected early kernel parameter
kvm: arm64: Initialize MAIR_EL2 using a constant
kvm: arm64: Remove vector_ptr param of hyp-init
kvm: arm64: Move hyp-init params to a per-CPU struct
kvm: arm64: Add .hyp.data..ro_after_init ELF section
kvm: arm64: Support per_cpu_ptr in nVHE hyp code
kvm: arm64: Create nVHE copy of cpu_logical_map
kvm: arm64: Add SMC handler in nVHE EL2
kvm: arm64: Bootstrap PSCI SMC handler in nVHE EL2
kvm: arm64: Add offset for hyp VA <-> PA conversion
kvm: arm64: Forward safe PSCI SMCs coming from host
kvm: arm64: Extract __do_hyp_init into a helper function
kvm: arm64: Add function to enter host from KVM nVHE hyp code
kvm: arm64: Intercept host's CPU_ON SMCs
kvm: arm64: Intercept host's CPU_SUSPEND PSCI SMCs
kvm: arm64: Keep nVHE EL2 vector installed
kvm: arm64: Trap host SMCs in protected mode
kvm: arm64: Fix EL2 mode availability checks
.../admin-guide/kernel-parameters.txt | 5 +
arch/arm64/include/asm/cpucaps.h | 3 +-
arch/arm64/include/asm/el2_setup.h | 182 +++++++++++
arch/arm64/include/asm/kvm_arm.h | 1 +
arch/arm64/include/asm/kvm_asm.h | 8 +-
arch/arm64/include/asm/kvm_hyp.h | 4 +-
arch/arm64/include/asm/kvm_mmu.h | 26 +-
arch/arm64/include/asm/memory.h | 13 +
arch/arm64/include/asm/percpu.h | 6 +
arch/arm64/include/asm/sections.h | 1 +
arch/arm64/include/asm/smp.h | 4 +-
arch/arm64/include/asm/virt.h | 26 ++
arch/arm64/kernel/asm-offsets.c | 3 +
arch/arm64/kernel/cpufeature.c | 29 ++
arch/arm64/kernel/head.S | 144 +--------
arch/arm64/kernel/image-vars.h | 3 +
arch/arm64/kernel/setup.c | 2 +-
arch/arm64/kernel/vmlinux.lds.S | 10 +
arch/arm64/kvm/arm.c | 101 ++++--
.../arm64/kvm/hyp/include/nvhe/trap_handler.h | 18 ++
arch/arm64/kvm/hyp/nvhe/Makefile | 3 +-
arch/arm64/kvm/hyp/nvhe/host.S | 47 +++
arch/arm64/kvm/hyp/nvhe/hyp-init.S | 97 +++++-
arch/arm64/kvm/hyp/nvhe/hyp-main.c | 45 ++-
arch/arm64/kvm/hyp/nvhe/hyp-smp.c | 40 +++
arch/arm64/kvm/hyp/nvhe/hyp.lds.S | 1 +
arch/arm64/kvm/hyp/nvhe/psci-relay.c | 296 ++++++++++++++++++
arch/arm64/kvm/hyp/nvhe/switch.c | 5 +-
arch/arm64/kvm/va_layout.c | 30 +-
arch/arm64/mm/proc.S | 15 +-
drivers/firmware/psci/psci.c | 23 +-
include/linux/psci.h | 10 +
32 files changed, 999 insertions(+), 202 deletions(-)
create mode 100644 arch/arm64/include/asm/el2_setup.h
create mode 100644 arch/arm64/kvm/hyp/include/nvhe/trap_handler.h
create mode 100644 arch/arm64/kvm/hyp/nvhe/hyp-smp.c
create mode 100644 arch/arm64/kvm/hyp/nvhe/psci-relay.c
--
2.29.2.454.gaff20da3a2-goog
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 147+ messages in thread* [PATCH v3 01/23] psci: Support psci_ops.get_version for v0.1
2020-11-26 15:53 ` David Brazdil
(?)
@ 2020-11-26 15:53 ` David Brazdil
-1 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:53 UTC (permalink / raw)
To: kvmarm
Cc: Jonathan Corbet, Catalin Marinas, Will Deacon, Marc Zyngier,
James Morse, Julien Thierry, Suzuki K Poulose, Dennis Zhou,
Tejun Heo, Christoph Lameter, Mark Rutland, Lorenzo Pieralisi,
Sudeep Holla, linux-doc, linux-kernel, linux-arm-kernel,
kernel-team, David Brazdil
KVM's host PSCI SMC filter needs to be aware of the PSCI version of the
system but currently it is impossible to distinguish between v0.1 and
PSCI disabled because both have get_version == NULL.
Populate get_version for v0.1 with a function that returns a constant.
psci_opt.get_version is currently unused so this has no effect on
existing functionality.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
drivers/firmware/psci/psci.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
index 00af99b6f97c..213c68418a65 100644
--- a/drivers/firmware/psci/psci.c
+++ b/drivers/firmware/psci/psci.c
@@ -146,6 +146,11 @@ static int psci_to_linux_errno(int errno)
return -EINVAL;
}
+static u32 psci_get_version_0_1(void)
+{
+ return PSCI_VERSION(0, 1);
+}
+
static u32 psci_get_version(void)
{
return invoke_psci_fn(PSCI_0_2_FN_PSCI_VERSION, 0, 0, 0);
@@ -514,6 +519,8 @@ static int __init psci_0_1_init(struct device_node *np)
pr_info("Using PSCI v0.1 Function IDs from DT\n");
+ psci_ops.get_version = psci_get_version_0_1;
+
if (!of_property_read_u32(np, "cpu_suspend", &id)) {
psci_function_id[PSCI_FN_CPU_SUSPEND] = id;
psci_ops.cpu_suspend = psci_cpu_suspend;
--
2.29.2.454.gaff20da3a2-goog
^ permalink raw reply related [flat|nested] 147+ messages in thread* [PATCH v3 01/23] psci: Support psci_ops.get_version for v0.1
@ 2020-11-26 15:53 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:53 UTC (permalink / raw)
To: kvmarm
Cc: Mark Rutland, Lorenzo Pieralisi, kernel-team, Jonathan Corbet,
Catalin Marinas, Suzuki K Poulose, linux-doc, linux-kernel,
Sudeep Holla, James Morse, linux-arm-kernel, Marc Zyngier,
Tejun Heo, Dennis Zhou, Christoph Lameter, David Brazdil,
Will Deacon, Julien Thierry
KVM's host PSCI SMC filter needs to be aware of the PSCI version of the
system but currently it is impossible to distinguish between v0.1 and
PSCI disabled because both have get_version == NULL.
Populate get_version for v0.1 with a function that returns a constant.
psci_opt.get_version is currently unused so this has no effect on
existing functionality.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
drivers/firmware/psci/psci.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
index 00af99b6f97c..213c68418a65 100644
--- a/drivers/firmware/psci/psci.c
+++ b/drivers/firmware/psci/psci.c
@@ -146,6 +146,11 @@ static int psci_to_linux_errno(int errno)
return -EINVAL;
}
+static u32 psci_get_version_0_1(void)
+{
+ return PSCI_VERSION(0, 1);
+}
+
static u32 psci_get_version(void)
{
return invoke_psci_fn(PSCI_0_2_FN_PSCI_VERSION, 0, 0, 0);
@@ -514,6 +519,8 @@ static int __init psci_0_1_init(struct device_node *np)
pr_info("Using PSCI v0.1 Function IDs from DT\n");
+ psci_ops.get_version = psci_get_version_0_1;
+
if (!of_property_read_u32(np, "cpu_suspend", &id)) {
psci_function_id[PSCI_FN_CPU_SUSPEND] = id;
psci_ops.cpu_suspend = psci_cpu_suspend;
--
2.29.2.454.gaff20da3a2-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 147+ messages in thread* [PATCH v3 01/23] psci: Support psci_ops.get_version for v0.1
@ 2020-11-26 15:53 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:53 UTC (permalink / raw)
To: kvmarm
Cc: Lorenzo Pieralisi, kernel-team, Jonathan Corbet, Catalin Marinas,
linux-doc, linux-kernel, Sudeep Holla, linux-arm-kernel,
Marc Zyngier, Tejun Heo, Dennis Zhou, Christoph Lameter,
Will Deacon
KVM's host PSCI SMC filter needs to be aware of the PSCI version of the
system but currently it is impossible to distinguish between v0.1 and
PSCI disabled because both have get_version == NULL.
Populate get_version for v0.1 with a function that returns a constant.
psci_opt.get_version is currently unused so this has no effect on
existing functionality.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
drivers/firmware/psci/psci.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
index 00af99b6f97c..213c68418a65 100644
--- a/drivers/firmware/psci/psci.c
+++ b/drivers/firmware/psci/psci.c
@@ -146,6 +146,11 @@ static int psci_to_linux_errno(int errno)
return -EINVAL;
}
+static u32 psci_get_version_0_1(void)
+{
+ return PSCI_VERSION(0, 1);
+}
+
static u32 psci_get_version(void)
{
return invoke_psci_fn(PSCI_0_2_FN_PSCI_VERSION, 0, 0, 0);
@@ -514,6 +519,8 @@ static int __init psci_0_1_init(struct device_node *np)
pr_info("Using PSCI v0.1 Function IDs from DT\n");
+ psci_ops.get_version = psci_get_version_0_1;
+
if (!of_property_read_u32(np, "cpu_suspend", &id)) {
psci_function_id[PSCI_FN_CPU_SUSPEND] = id;
psci_ops.cpu_suspend = psci_cpu_suspend;
--
2.29.2.454.gaff20da3a2-goog
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply related [flat|nested] 147+ messages in thread* Re: [PATCH v3 01/23] psci: Support psci_ops.get_version for v0.1
2020-11-26 15:53 ` David Brazdil
(?)
@ 2020-11-26 17:21 ` Mark Rutland
-1 siblings, 0 replies; 147+ messages in thread
From: Mark Rutland @ 2020-11-26 17:21 UTC (permalink / raw)
To: David Brazdil
Cc: kvmarm, Jonathan Corbet, Catalin Marinas, Will Deacon,
Marc Zyngier, James Morse, Julien Thierry, Suzuki K Poulose,
Dennis Zhou, Tejun Heo, Christoph Lameter, Lorenzo Pieralisi,
Sudeep Holla, linux-doc, linux-kernel, linux-arm-kernel,
kernel-team
On Thu, Nov 26, 2020 at 03:53:59PM +0000, David Brazdil wrote:
> KVM's host PSCI SMC filter needs to be aware of the PSCI version of the
> system but currently it is impossible to distinguish between v0.1 and
> PSCI disabled because both have get_version == NULL.
>
> Populate get_version for v0.1 with a function that returns a constant.
>
> psci_opt.get_version is currently unused so this has no effect on
> existing functionality.
>
> Signed-off-by: David Brazdil <dbrazdil@google.com>
> ---
> drivers/firmware/psci/psci.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
> index 00af99b6f97c..213c68418a65 100644
> --- a/drivers/firmware/psci/psci.c
> +++ b/drivers/firmware/psci/psci.c
> @@ -146,6 +146,11 @@ static int psci_to_linux_errno(int errno)
> return -EINVAL;
> }
>
> +static u32 psci_get_version_0_1(void)
> +{
> + return PSCI_VERSION(0, 1);
> +}
Elsewhere in this file we've used a psci_${MAJOR}_${MINOR}_* naming
scheme.
To match that, I'd prefer we call this psci_0_1_get_version(), and
rename psci_get_version() to psci_0_2_get_version().
With that:
Acked-by: Mark Rutland <mark.rutland@arm.com>
Thanks,
Mark.
> +
> static u32 psci_get_version(void)
> {
> return invoke_psci_fn(PSCI_0_2_FN_PSCI_VERSION, 0, 0, 0);
> @@ -514,6 +519,8 @@ static int __init psci_0_1_init(struct device_node *np)
>
> pr_info("Using PSCI v0.1 Function IDs from DT\n");
>
> + psci_ops.get_version = psci_get_version_0_1;
> +
> if (!of_property_read_u32(np, "cpu_suspend", &id)) {
> psci_function_id[PSCI_FN_CPU_SUSPEND] = id;
> psci_ops.cpu_suspend = psci_cpu_suspend;
> --
> 2.29.2.454.gaff20da3a2-goog
>
^ permalink raw reply [flat|nested] 147+ messages in thread* Re: [PATCH v3 01/23] psci: Support psci_ops.get_version for v0.1
@ 2020-11-26 17:21 ` Mark Rutland
0 siblings, 0 replies; 147+ messages in thread
From: Mark Rutland @ 2020-11-26 17:21 UTC (permalink / raw)
To: David Brazdil
Cc: Lorenzo Pieralisi, kernel-team, Jonathan Corbet, Catalin Marinas,
Suzuki K Poulose, linux-doc, linux-kernel, Sudeep Holla,
James Morse, linux-arm-kernel, Marc Zyngier, Tejun Heo,
Dennis Zhou, Christoph Lameter, Will Deacon, kvmarm,
Julien Thierry
On Thu, Nov 26, 2020 at 03:53:59PM +0000, David Brazdil wrote:
> KVM's host PSCI SMC filter needs to be aware of the PSCI version of the
> system but currently it is impossible to distinguish between v0.1 and
> PSCI disabled because both have get_version == NULL.
>
> Populate get_version for v0.1 with a function that returns a constant.
>
> psci_opt.get_version is currently unused so this has no effect on
> existing functionality.
>
> Signed-off-by: David Brazdil <dbrazdil@google.com>
> ---
> drivers/firmware/psci/psci.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
> index 00af99b6f97c..213c68418a65 100644
> --- a/drivers/firmware/psci/psci.c
> +++ b/drivers/firmware/psci/psci.c
> @@ -146,6 +146,11 @@ static int psci_to_linux_errno(int errno)
> return -EINVAL;
> }
>
> +static u32 psci_get_version_0_1(void)
> +{
> + return PSCI_VERSION(0, 1);
> +}
Elsewhere in this file we've used a psci_${MAJOR}_${MINOR}_* naming
scheme.
To match that, I'd prefer we call this psci_0_1_get_version(), and
rename psci_get_version() to psci_0_2_get_version().
With that:
Acked-by: Mark Rutland <mark.rutland@arm.com>
Thanks,
Mark.
> +
> static u32 psci_get_version(void)
> {
> return invoke_psci_fn(PSCI_0_2_FN_PSCI_VERSION, 0, 0, 0);
> @@ -514,6 +519,8 @@ static int __init psci_0_1_init(struct device_node *np)
>
> pr_info("Using PSCI v0.1 Function IDs from DT\n");
>
> + psci_ops.get_version = psci_get_version_0_1;
> +
> if (!of_property_read_u32(np, "cpu_suspend", &id)) {
> psci_function_id[PSCI_FN_CPU_SUSPEND] = id;
> psci_ops.cpu_suspend = psci_cpu_suspend;
> --
> 2.29.2.454.gaff20da3a2-goog
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 147+ messages in thread* Re: [PATCH v3 01/23] psci: Support psci_ops.get_version for v0.1
@ 2020-11-26 17:21 ` Mark Rutland
0 siblings, 0 replies; 147+ messages in thread
From: Mark Rutland @ 2020-11-26 17:21 UTC (permalink / raw)
To: David Brazdil
Cc: Lorenzo Pieralisi, kernel-team, Jonathan Corbet, Catalin Marinas,
linux-doc, linux-kernel, Sudeep Holla, linux-arm-kernel,
Marc Zyngier, Tejun Heo, Dennis Zhou, Christoph Lameter,
Will Deacon, kvmarm
On Thu, Nov 26, 2020 at 03:53:59PM +0000, David Brazdil wrote:
> KVM's host PSCI SMC filter needs to be aware of the PSCI version of the
> system but currently it is impossible to distinguish between v0.1 and
> PSCI disabled because both have get_version == NULL.
>
> Populate get_version for v0.1 with a function that returns a constant.
>
> psci_opt.get_version is currently unused so this has no effect on
> existing functionality.
>
> Signed-off-by: David Brazdil <dbrazdil@google.com>
> ---
> drivers/firmware/psci/psci.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
> index 00af99b6f97c..213c68418a65 100644
> --- a/drivers/firmware/psci/psci.c
> +++ b/drivers/firmware/psci/psci.c
> @@ -146,6 +146,11 @@ static int psci_to_linux_errno(int errno)
> return -EINVAL;
> }
>
> +static u32 psci_get_version_0_1(void)
> +{
> + return PSCI_VERSION(0, 1);
> +}
Elsewhere in this file we've used a psci_${MAJOR}_${MINOR}_* naming
scheme.
To match that, I'd prefer we call this psci_0_1_get_version(), and
rename psci_get_version() to psci_0_2_get_version().
With that:
Acked-by: Mark Rutland <mark.rutland@arm.com>
Thanks,
Mark.
> +
> static u32 psci_get_version(void)
> {
> return invoke_psci_fn(PSCI_0_2_FN_PSCI_VERSION, 0, 0, 0);
> @@ -514,6 +519,8 @@ static int __init psci_0_1_init(struct device_node *np)
>
> pr_info("Using PSCI v0.1 Function IDs from DT\n");
>
> + psci_ops.get_version = psci_get_version_0_1;
> +
> if (!of_property_read_u32(np, "cpu_suspend", &id)) {
> psci_function_id[PSCI_FN_CPU_SUSPEND] = id;
> psci_ops.cpu_suspend = psci_cpu_suspend;
> --
> 2.29.2.454.gaff20da3a2-goog
>
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v3 02/23] psci: Accessor for configured PSCI function IDs
2020-11-26 15:53 ` David Brazdil
(?)
@ 2020-11-26 15:54 ` David Brazdil
-1 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Jonathan Corbet, Catalin Marinas, Will Deacon, Marc Zyngier,
James Morse, Julien Thierry, Suzuki K Poulose, Dennis Zhou,
Tejun Heo, Christoph Lameter, Mark Rutland, Lorenzo Pieralisi,
Sudeep Holla, linux-doc, linux-kernel, linux-arm-kernel,
kernel-team, David Brazdil
Function IDs used by PSCI are configurable for v0.1 via DT/APCI. If the
host is using PSCI v0.1, KVM's host PSCI proxy needs to use the same IDs.
Expose the array holding the information with a read-only accessor.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
drivers/firmware/psci/psci.c | 16 ++++++++--------
include/linux/psci.h | 10 ++++++++++
2 files changed, 18 insertions(+), 8 deletions(-)
diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
index 213c68418a65..40609564595e 100644
--- a/drivers/firmware/psci/psci.c
+++ b/drivers/firmware/psci/psci.c
@@ -58,16 +58,16 @@ typedef unsigned long (psci_fn)(unsigned long, unsigned long,
unsigned long, unsigned long);
static psci_fn *invoke_psci_fn;
-enum psci_function {
- PSCI_FN_CPU_SUSPEND,
- PSCI_FN_CPU_ON,
- PSCI_FN_CPU_OFF,
- PSCI_FN_MIGRATE,
- PSCI_FN_MAX,
-};
-
static u32 psci_function_id[PSCI_FN_MAX];
+u32 psci_get_function_id(enum psci_function fn)
+{
+ if (WARN_ON_ONCE(fn < 0 || fn >= PSCI_FN_MAX))
+ return 0;
+
+ return psci_function_id[fn];
+}
+
#define PSCI_0_2_POWER_STATE_MASK \
(PSCI_0_2_POWER_STATE_ID_MASK | \
PSCI_0_2_POWER_STATE_TYPE_MASK | \
diff --git a/include/linux/psci.h b/include/linux/psci.h
index 2a1bfb890e58..5b49a5c82d6f 100644
--- a/include/linux/psci.h
+++ b/include/linux/psci.h
@@ -21,6 +21,16 @@ bool psci_power_state_is_valid(u32 state);
int psci_set_osi_mode(bool enable);
bool psci_has_osi_support(void);
+enum psci_function {
+ PSCI_FN_CPU_SUSPEND,
+ PSCI_FN_CPU_ON,
+ PSCI_FN_CPU_OFF,
+ PSCI_FN_MIGRATE,
+ PSCI_FN_MAX,
+};
+
+u32 psci_get_function_id(enum psci_function fn);
+
struct psci_operations {
u32 (*get_version)(void);
int (*cpu_suspend)(u32 state, unsigned long entry_point);
--
2.29.2.454.gaff20da3a2-goog
^ permalink raw reply related [flat|nested] 147+ messages in thread* [PATCH v3 02/23] psci: Accessor for configured PSCI function IDs
@ 2020-11-26 15:54 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Mark Rutland, Lorenzo Pieralisi, kernel-team, Jonathan Corbet,
Catalin Marinas, Suzuki K Poulose, linux-doc, linux-kernel,
Sudeep Holla, James Morse, linux-arm-kernel, Marc Zyngier,
Tejun Heo, Dennis Zhou, Christoph Lameter, David Brazdil,
Will Deacon, Julien Thierry
Function IDs used by PSCI are configurable for v0.1 via DT/APCI. If the
host is using PSCI v0.1, KVM's host PSCI proxy needs to use the same IDs.
Expose the array holding the information with a read-only accessor.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
drivers/firmware/psci/psci.c | 16 ++++++++--------
include/linux/psci.h | 10 ++++++++++
2 files changed, 18 insertions(+), 8 deletions(-)
diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
index 213c68418a65..40609564595e 100644
--- a/drivers/firmware/psci/psci.c
+++ b/drivers/firmware/psci/psci.c
@@ -58,16 +58,16 @@ typedef unsigned long (psci_fn)(unsigned long, unsigned long,
unsigned long, unsigned long);
static psci_fn *invoke_psci_fn;
-enum psci_function {
- PSCI_FN_CPU_SUSPEND,
- PSCI_FN_CPU_ON,
- PSCI_FN_CPU_OFF,
- PSCI_FN_MIGRATE,
- PSCI_FN_MAX,
-};
-
static u32 psci_function_id[PSCI_FN_MAX];
+u32 psci_get_function_id(enum psci_function fn)
+{
+ if (WARN_ON_ONCE(fn < 0 || fn >= PSCI_FN_MAX))
+ return 0;
+
+ return psci_function_id[fn];
+}
+
#define PSCI_0_2_POWER_STATE_MASK \
(PSCI_0_2_POWER_STATE_ID_MASK | \
PSCI_0_2_POWER_STATE_TYPE_MASK | \
diff --git a/include/linux/psci.h b/include/linux/psci.h
index 2a1bfb890e58..5b49a5c82d6f 100644
--- a/include/linux/psci.h
+++ b/include/linux/psci.h
@@ -21,6 +21,16 @@ bool psci_power_state_is_valid(u32 state);
int psci_set_osi_mode(bool enable);
bool psci_has_osi_support(void);
+enum psci_function {
+ PSCI_FN_CPU_SUSPEND,
+ PSCI_FN_CPU_ON,
+ PSCI_FN_CPU_OFF,
+ PSCI_FN_MIGRATE,
+ PSCI_FN_MAX,
+};
+
+u32 psci_get_function_id(enum psci_function fn);
+
struct psci_operations {
u32 (*get_version)(void);
int (*cpu_suspend)(u32 state, unsigned long entry_point);
--
2.29.2.454.gaff20da3a2-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 147+ messages in thread* [PATCH v3 02/23] psci: Accessor for configured PSCI function IDs
@ 2020-11-26 15:54 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Lorenzo Pieralisi, kernel-team, Jonathan Corbet, Catalin Marinas,
linux-doc, linux-kernel, Sudeep Holla, linux-arm-kernel,
Marc Zyngier, Tejun Heo, Dennis Zhou, Christoph Lameter,
Will Deacon
Function IDs used by PSCI are configurable for v0.1 via DT/APCI. If the
host is using PSCI v0.1, KVM's host PSCI proxy needs to use the same IDs.
Expose the array holding the information with a read-only accessor.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
drivers/firmware/psci/psci.c | 16 ++++++++--------
include/linux/psci.h | 10 ++++++++++
2 files changed, 18 insertions(+), 8 deletions(-)
diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
index 213c68418a65..40609564595e 100644
--- a/drivers/firmware/psci/psci.c
+++ b/drivers/firmware/psci/psci.c
@@ -58,16 +58,16 @@ typedef unsigned long (psci_fn)(unsigned long, unsigned long,
unsigned long, unsigned long);
static psci_fn *invoke_psci_fn;
-enum psci_function {
- PSCI_FN_CPU_SUSPEND,
- PSCI_FN_CPU_ON,
- PSCI_FN_CPU_OFF,
- PSCI_FN_MIGRATE,
- PSCI_FN_MAX,
-};
-
static u32 psci_function_id[PSCI_FN_MAX];
+u32 psci_get_function_id(enum psci_function fn)
+{
+ if (WARN_ON_ONCE(fn < 0 || fn >= PSCI_FN_MAX))
+ return 0;
+
+ return psci_function_id[fn];
+}
+
#define PSCI_0_2_POWER_STATE_MASK \
(PSCI_0_2_POWER_STATE_ID_MASK | \
PSCI_0_2_POWER_STATE_TYPE_MASK | \
diff --git a/include/linux/psci.h b/include/linux/psci.h
index 2a1bfb890e58..5b49a5c82d6f 100644
--- a/include/linux/psci.h
+++ b/include/linux/psci.h
@@ -21,6 +21,16 @@ bool psci_power_state_is_valid(u32 state);
int psci_set_osi_mode(bool enable);
bool psci_has_osi_support(void);
+enum psci_function {
+ PSCI_FN_CPU_SUSPEND,
+ PSCI_FN_CPU_ON,
+ PSCI_FN_CPU_OFF,
+ PSCI_FN_MIGRATE,
+ PSCI_FN_MAX,
+};
+
+u32 psci_get_function_id(enum psci_function fn);
+
struct psci_operations {
u32 (*get_version)(void);
int (*cpu_suspend)(u32 state, unsigned long entry_point);
--
2.29.2.454.gaff20da3a2-goog
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply related [flat|nested] 147+ messages in thread* Re: [PATCH v3 02/23] psci: Accessor for configured PSCI function IDs
2020-11-26 15:54 ` David Brazdil
(?)
@ 2020-11-26 17:24 ` Mark Rutland
-1 siblings, 0 replies; 147+ messages in thread
From: Mark Rutland @ 2020-11-26 17:24 UTC (permalink / raw)
To: David Brazdil
Cc: kvmarm, Jonathan Corbet, Catalin Marinas, Will Deacon,
Marc Zyngier, James Morse, Julien Thierry, Suzuki K Poulose,
Dennis Zhou, Tejun Heo, Christoph Lameter, Lorenzo Pieralisi,
Sudeep Holla, linux-doc, linux-kernel, linux-arm-kernel,
kernel-team
On Thu, Nov 26, 2020 at 03:54:00PM +0000, David Brazdil wrote:
> Function IDs used by PSCI are configurable for v0.1 via DT/APCI. If the
> host is using PSCI v0.1, KVM's host PSCI proxy needs to use the same IDs.
> Expose the array holding the information with a read-only accessor.
>
> Signed-off-by: David Brazdil <dbrazdil@google.com>
> ---
> drivers/firmware/psci/psci.c | 16 ++++++++--------
> include/linux/psci.h | 10 ++++++++++
> 2 files changed, 18 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
> index 213c68418a65..40609564595e 100644
> --- a/drivers/firmware/psci/psci.c
> +++ b/drivers/firmware/psci/psci.c
> @@ -58,16 +58,16 @@ typedef unsigned long (psci_fn)(unsigned long, unsigned long,
> unsigned long, unsigned long);
> static psci_fn *invoke_psci_fn;
>
> -enum psci_function {
> - PSCI_FN_CPU_SUSPEND,
> - PSCI_FN_CPU_ON,
> - PSCI_FN_CPU_OFF,
> - PSCI_FN_MIGRATE,
> - PSCI_FN_MAX,
> -};
> -
> static u32 psci_function_id[PSCI_FN_MAX];
>
> +u32 psci_get_function_id(enum psci_function fn)
> +{
> + if (WARN_ON_ONCE(fn < 0 || fn >= PSCI_FN_MAX))
> + return 0;
> +
> + return psci_function_id[fn];
> +}
I'd really like if we could namespace this with a psci_0_1_* prefix
before we expose it outside of the PSCI code. I appreciate that's a
larger change, but I reckon we only need a couple of new patches:
1) Split the ops which consume the FN ids into separate psci_0_1_*() and
psci_0_2_*() variants, with a common __psci_*() helper that takes the
function ID as an argument. The 0_1 variants would read the function
ID from a variable, and the 0_2 variants would hard-code the id.
2) Replace the psci_function_id array with:
struct psci_0_1_function_ids {
u32 suspend;
u32 cpu_on;
u32 cpu_off;
u32 migrate;
};
... and remove enum psci_function entirely.
3) Add a helper which returns the entire psci_0_1_function_ids struct in
one go. No warnings necessary.
Does that sound OK to you?
Thanks,
Mark.
> +
> #define PSCI_0_2_POWER_STATE_MASK \
> (PSCI_0_2_POWER_STATE_ID_MASK | \
> PSCI_0_2_POWER_STATE_TYPE_MASK | \
> diff --git a/include/linux/psci.h b/include/linux/psci.h
> index 2a1bfb890e58..5b49a5c82d6f 100644
> --- a/include/linux/psci.h
> +++ b/include/linux/psci.h
> @@ -21,6 +21,16 @@ bool psci_power_state_is_valid(u32 state);
> int psci_set_osi_mode(bool enable);
> bool psci_has_osi_support(void);
>
> +enum psci_function {
> + PSCI_FN_CPU_SUSPEND,
> + PSCI_FN_CPU_ON,
> + PSCI_FN_CPU_OFF,
> + PSCI_FN_MIGRATE,
> + PSCI_FN_MAX,
> +};
> +
> +u32 psci_get_function_id(enum psci_function fn);
> +
> struct psci_operations {
> u32 (*get_version)(void);
> int (*cpu_suspend)(u32 state, unsigned long entry_point);
> --
> 2.29.2.454.gaff20da3a2-goog
>
^ permalink raw reply [flat|nested] 147+ messages in thread* Re: [PATCH v3 02/23] psci: Accessor for configured PSCI function IDs
@ 2020-11-26 17:24 ` Mark Rutland
0 siblings, 0 replies; 147+ messages in thread
From: Mark Rutland @ 2020-11-26 17:24 UTC (permalink / raw)
To: David Brazdil
Cc: Lorenzo Pieralisi, kernel-team, Jonathan Corbet, Catalin Marinas,
Suzuki K Poulose, linux-doc, linux-kernel, Sudeep Holla,
James Morse, linux-arm-kernel, Marc Zyngier, Tejun Heo,
Dennis Zhou, Christoph Lameter, Will Deacon, kvmarm,
Julien Thierry
On Thu, Nov 26, 2020 at 03:54:00PM +0000, David Brazdil wrote:
> Function IDs used by PSCI are configurable for v0.1 via DT/APCI. If the
> host is using PSCI v0.1, KVM's host PSCI proxy needs to use the same IDs.
> Expose the array holding the information with a read-only accessor.
>
> Signed-off-by: David Brazdil <dbrazdil@google.com>
> ---
> drivers/firmware/psci/psci.c | 16 ++++++++--------
> include/linux/psci.h | 10 ++++++++++
> 2 files changed, 18 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
> index 213c68418a65..40609564595e 100644
> --- a/drivers/firmware/psci/psci.c
> +++ b/drivers/firmware/psci/psci.c
> @@ -58,16 +58,16 @@ typedef unsigned long (psci_fn)(unsigned long, unsigned long,
> unsigned long, unsigned long);
> static psci_fn *invoke_psci_fn;
>
> -enum psci_function {
> - PSCI_FN_CPU_SUSPEND,
> - PSCI_FN_CPU_ON,
> - PSCI_FN_CPU_OFF,
> - PSCI_FN_MIGRATE,
> - PSCI_FN_MAX,
> -};
> -
> static u32 psci_function_id[PSCI_FN_MAX];
>
> +u32 psci_get_function_id(enum psci_function fn)
> +{
> + if (WARN_ON_ONCE(fn < 0 || fn >= PSCI_FN_MAX))
> + return 0;
> +
> + return psci_function_id[fn];
> +}
I'd really like if we could namespace this with a psci_0_1_* prefix
before we expose it outside of the PSCI code. I appreciate that's a
larger change, but I reckon we only need a couple of new patches:
1) Split the ops which consume the FN ids into separate psci_0_1_*() and
psci_0_2_*() variants, with a common __psci_*() helper that takes the
function ID as an argument. The 0_1 variants would read the function
ID from a variable, and the 0_2 variants would hard-code the id.
2) Replace the psci_function_id array with:
struct psci_0_1_function_ids {
u32 suspend;
u32 cpu_on;
u32 cpu_off;
u32 migrate;
};
... and remove enum psci_function entirely.
3) Add a helper which returns the entire psci_0_1_function_ids struct in
one go. No warnings necessary.
Does that sound OK to you?
Thanks,
Mark.
> +
> #define PSCI_0_2_POWER_STATE_MASK \
> (PSCI_0_2_POWER_STATE_ID_MASK | \
> PSCI_0_2_POWER_STATE_TYPE_MASK | \
> diff --git a/include/linux/psci.h b/include/linux/psci.h
> index 2a1bfb890e58..5b49a5c82d6f 100644
> --- a/include/linux/psci.h
> +++ b/include/linux/psci.h
> @@ -21,6 +21,16 @@ bool psci_power_state_is_valid(u32 state);
> int psci_set_osi_mode(bool enable);
> bool psci_has_osi_support(void);
>
> +enum psci_function {
> + PSCI_FN_CPU_SUSPEND,
> + PSCI_FN_CPU_ON,
> + PSCI_FN_CPU_OFF,
> + PSCI_FN_MIGRATE,
> + PSCI_FN_MAX,
> +};
> +
> +u32 psci_get_function_id(enum psci_function fn);
> +
> struct psci_operations {
> u32 (*get_version)(void);
> int (*cpu_suspend)(u32 state, unsigned long entry_point);
> --
> 2.29.2.454.gaff20da3a2-goog
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 147+ messages in thread* Re: [PATCH v3 02/23] psci: Accessor for configured PSCI function IDs
@ 2020-11-26 17:24 ` Mark Rutland
0 siblings, 0 replies; 147+ messages in thread
From: Mark Rutland @ 2020-11-26 17:24 UTC (permalink / raw)
To: David Brazdil
Cc: Lorenzo Pieralisi, kernel-team, Jonathan Corbet, Catalin Marinas,
linux-doc, linux-kernel, Sudeep Holla, linux-arm-kernel,
Marc Zyngier, Tejun Heo, Dennis Zhou, Christoph Lameter,
Will Deacon, kvmarm
On Thu, Nov 26, 2020 at 03:54:00PM +0000, David Brazdil wrote:
> Function IDs used by PSCI are configurable for v0.1 via DT/APCI. If the
> host is using PSCI v0.1, KVM's host PSCI proxy needs to use the same IDs.
> Expose the array holding the information with a read-only accessor.
>
> Signed-off-by: David Brazdil <dbrazdil@google.com>
> ---
> drivers/firmware/psci/psci.c | 16 ++++++++--------
> include/linux/psci.h | 10 ++++++++++
> 2 files changed, 18 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
> index 213c68418a65..40609564595e 100644
> --- a/drivers/firmware/psci/psci.c
> +++ b/drivers/firmware/psci/psci.c
> @@ -58,16 +58,16 @@ typedef unsigned long (psci_fn)(unsigned long, unsigned long,
> unsigned long, unsigned long);
> static psci_fn *invoke_psci_fn;
>
> -enum psci_function {
> - PSCI_FN_CPU_SUSPEND,
> - PSCI_FN_CPU_ON,
> - PSCI_FN_CPU_OFF,
> - PSCI_FN_MIGRATE,
> - PSCI_FN_MAX,
> -};
> -
> static u32 psci_function_id[PSCI_FN_MAX];
>
> +u32 psci_get_function_id(enum psci_function fn)
> +{
> + if (WARN_ON_ONCE(fn < 0 || fn >= PSCI_FN_MAX))
> + return 0;
> +
> + return psci_function_id[fn];
> +}
I'd really like if we could namespace this with a psci_0_1_* prefix
before we expose it outside of the PSCI code. I appreciate that's a
larger change, but I reckon we only need a couple of new patches:
1) Split the ops which consume the FN ids into separate psci_0_1_*() and
psci_0_2_*() variants, with a common __psci_*() helper that takes the
function ID as an argument. The 0_1 variants would read the function
ID from a variable, and the 0_2 variants would hard-code the id.
2) Replace the psci_function_id array with:
struct psci_0_1_function_ids {
u32 suspend;
u32 cpu_on;
u32 cpu_off;
u32 migrate;
};
... and remove enum psci_function entirely.
3) Add a helper which returns the entire psci_0_1_function_ids struct in
one go. No warnings necessary.
Does that sound OK to you?
Thanks,
Mark.
> +
> #define PSCI_0_2_POWER_STATE_MASK \
> (PSCI_0_2_POWER_STATE_ID_MASK | \
> PSCI_0_2_POWER_STATE_TYPE_MASK | \
> diff --git a/include/linux/psci.h b/include/linux/psci.h
> index 2a1bfb890e58..5b49a5c82d6f 100644
> --- a/include/linux/psci.h
> +++ b/include/linux/psci.h
> @@ -21,6 +21,16 @@ bool psci_power_state_is_valid(u32 state);
> int psci_set_osi_mode(bool enable);
> bool psci_has_osi_support(void);
>
> +enum psci_function {
> + PSCI_FN_CPU_SUSPEND,
> + PSCI_FN_CPU_ON,
> + PSCI_FN_CPU_OFF,
> + PSCI_FN_MIGRATE,
> + PSCI_FN_MAX,
> +};
> +
> +u32 psci_get_function_id(enum psci_function fn);
> +
> struct psci_operations {
> u32 (*get_version)(void);
> int (*cpu_suspend)(u32 state, unsigned long entry_point);
> --
> 2.29.2.454.gaff20da3a2-goog
>
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 147+ messages in thread* Re: [PATCH v3 02/23] psci: Accessor for configured PSCI function IDs
2020-11-26 17:24 ` Mark Rutland
(?)
@ 2020-11-26 17:29 ` David Brazdil
-1 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 17:29 UTC (permalink / raw)
To: Mark Rutland
Cc: kvmarm, Jonathan Corbet, Catalin Marinas, Will Deacon,
Marc Zyngier, James Morse, Julien Thierry, Suzuki K Poulose,
Dennis Zhou, Tejun Heo, Christoph Lameter, Lorenzo Pieralisi,
Sudeep Holla, linux-doc, linux-kernel, linux-arm-kernel,
kernel-team
Hey Mark,
On Thu, Nov 26, 2020 at 05:24:50PM +0000, Mark Rutland wrote:
> On Thu, Nov 26, 2020 at 03:54:00PM +0000, David Brazdil wrote:
> > Function IDs used by PSCI are configurable for v0.1 via DT/APCI. If the
> > host is using PSCI v0.1, KVM's host PSCI proxy needs to use the same IDs.
> > Expose the array holding the information with a read-only accessor.
> >
> > Signed-off-by: David Brazdil <dbrazdil@google.com>
> > ---
> > drivers/firmware/psci/psci.c | 16 ++++++++--------
> > include/linux/psci.h | 10 ++++++++++
> > 2 files changed, 18 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
> > index 213c68418a65..40609564595e 100644
> > --- a/drivers/firmware/psci/psci.c
> > +++ b/drivers/firmware/psci/psci.c
> > @@ -58,16 +58,16 @@ typedef unsigned long (psci_fn)(unsigned long, unsigned long,
> > unsigned long, unsigned long);
> > static psci_fn *invoke_psci_fn;
> >
> > -enum psci_function {
> > - PSCI_FN_CPU_SUSPEND,
> > - PSCI_FN_CPU_ON,
> > - PSCI_FN_CPU_OFF,
> > - PSCI_FN_MIGRATE,
> > - PSCI_FN_MAX,
> > -};
> > -
> > static u32 psci_function_id[PSCI_FN_MAX];
> >
> > +u32 psci_get_function_id(enum psci_function fn)
> > +{
> > + if (WARN_ON_ONCE(fn < 0 || fn >= PSCI_FN_MAX))
> > + return 0;
> > +
> > + return psci_function_id[fn];
> > +}
>
> I'd really like if we could namespace this with a psci_0_1_* prefix
> before we expose it outside of the PSCI code. I appreciate that's a
> larger change, but I reckon we only need a couple of new patches:
>
> 1) Split the ops which consume the FN ids into separate psci_0_1_*() and
> psci_0_2_*() variants, with a common __psci_*() helper that takes the
> function ID as an argument. The 0_1 variants would read the function
> ID from a variable, and the 0_2 variants would hard-code the id.
>
> 2) Replace the psci_function_id array with:
>
> struct psci_0_1_function_ids {
> u32 suspend;
> u32 cpu_on;
> u32 cpu_off;
> u32 migrate;
> };
>
> ... and remove enum psci_function entirely.
>
> 3) Add a helper which returns the entire psci_0_1_function_ids struct in
> one go. No warnings necessary.
>
> Does that sound OK to you?
Sure, sounds easy enough and 2) is in line with how I structured the handlers
in KVM.
Thanks,
David
^ permalink raw reply [flat|nested] 147+ messages in thread* Re: [PATCH v3 02/23] psci: Accessor for configured PSCI function IDs
@ 2020-11-26 17:29 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 17:29 UTC (permalink / raw)
To: Mark Rutland
Cc: Lorenzo Pieralisi, kernel-team, Jonathan Corbet, Catalin Marinas,
Suzuki K Poulose, linux-doc, linux-kernel, Sudeep Holla,
James Morse, linux-arm-kernel, Marc Zyngier, Tejun Heo,
Dennis Zhou, Christoph Lameter, Will Deacon, kvmarm,
Julien Thierry
Hey Mark,
On Thu, Nov 26, 2020 at 05:24:50PM +0000, Mark Rutland wrote:
> On Thu, Nov 26, 2020 at 03:54:00PM +0000, David Brazdil wrote:
> > Function IDs used by PSCI are configurable for v0.1 via DT/APCI. If the
> > host is using PSCI v0.1, KVM's host PSCI proxy needs to use the same IDs.
> > Expose the array holding the information with a read-only accessor.
> >
> > Signed-off-by: David Brazdil <dbrazdil@google.com>
> > ---
> > drivers/firmware/psci/psci.c | 16 ++++++++--------
> > include/linux/psci.h | 10 ++++++++++
> > 2 files changed, 18 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
> > index 213c68418a65..40609564595e 100644
> > --- a/drivers/firmware/psci/psci.c
> > +++ b/drivers/firmware/psci/psci.c
> > @@ -58,16 +58,16 @@ typedef unsigned long (psci_fn)(unsigned long, unsigned long,
> > unsigned long, unsigned long);
> > static psci_fn *invoke_psci_fn;
> >
> > -enum psci_function {
> > - PSCI_FN_CPU_SUSPEND,
> > - PSCI_FN_CPU_ON,
> > - PSCI_FN_CPU_OFF,
> > - PSCI_FN_MIGRATE,
> > - PSCI_FN_MAX,
> > -};
> > -
> > static u32 psci_function_id[PSCI_FN_MAX];
> >
> > +u32 psci_get_function_id(enum psci_function fn)
> > +{
> > + if (WARN_ON_ONCE(fn < 0 || fn >= PSCI_FN_MAX))
> > + return 0;
> > +
> > + return psci_function_id[fn];
> > +}
>
> I'd really like if we could namespace this with a psci_0_1_* prefix
> before we expose it outside of the PSCI code. I appreciate that's a
> larger change, but I reckon we only need a couple of new patches:
>
> 1) Split the ops which consume the FN ids into separate psci_0_1_*() and
> psci_0_2_*() variants, with a common __psci_*() helper that takes the
> function ID as an argument. The 0_1 variants would read the function
> ID from a variable, and the 0_2 variants would hard-code the id.
>
> 2) Replace the psci_function_id array with:
>
> struct psci_0_1_function_ids {
> u32 suspend;
> u32 cpu_on;
> u32 cpu_off;
> u32 migrate;
> };
>
> ... and remove enum psci_function entirely.
>
> 3) Add a helper which returns the entire psci_0_1_function_ids struct in
> one go. No warnings necessary.
>
> Does that sound OK to you?
Sure, sounds easy enough and 2) is in line with how I structured the handlers
in KVM.
Thanks,
David
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 147+ messages in thread* Re: [PATCH v3 02/23] psci: Accessor for configured PSCI function IDs
@ 2020-11-26 17:29 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 17:29 UTC (permalink / raw)
To: Mark Rutland
Cc: Lorenzo Pieralisi, kernel-team, Jonathan Corbet, Catalin Marinas,
linux-doc, linux-kernel, Sudeep Holla, linux-arm-kernel,
Marc Zyngier, Tejun Heo, Dennis Zhou, Christoph Lameter,
Will Deacon, kvmarm
Hey Mark,
On Thu, Nov 26, 2020 at 05:24:50PM +0000, Mark Rutland wrote:
> On Thu, Nov 26, 2020 at 03:54:00PM +0000, David Brazdil wrote:
> > Function IDs used by PSCI are configurable for v0.1 via DT/APCI. If the
> > host is using PSCI v0.1, KVM's host PSCI proxy needs to use the same IDs.
> > Expose the array holding the information with a read-only accessor.
> >
> > Signed-off-by: David Brazdil <dbrazdil@google.com>
> > ---
> > drivers/firmware/psci/psci.c | 16 ++++++++--------
> > include/linux/psci.h | 10 ++++++++++
> > 2 files changed, 18 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
> > index 213c68418a65..40609564595e 100644
> > --- a/drivers/firmware/psci/psci.c
> > +++ b/drivers/firmware/psci/psci.c
> > @@ -58,16 +58,16 @@ typedef unsigned long (psci_fn)(unsigned long, unsigned long,
> > unsigned long, unsigned long);
> > static psci_fn *invoke_psci_fn;
> >
> > -enum psci_function {
> > - PSCI_FN_CPU_SUSPEND,
> > - PSCI_FN_CPU_ON,
> > - PSCI_FN_CPU_OFF,
> > - PSCI_FN_MIGRATE,
> > - PSCI_FN_MAX,
> > -};
> > -
> > static u32 psci_function_id[PSCI_FN_MAX];
> >
> > +u32 psci_get_function_id(enum psci_function fn)
> > +{
> > + if (WARN_ON_ONCE(fn < 0 || fn >= PSCI_FN_MAX))
> > + return 0;
> > +
> > + return psci_function_id[fn];
> > +}
>
> I'd really like if we could namespace this with a psci_0_1_* prefix
> before we expose it outside of the PSCI code. I appreciate that's a
> larger change, but I reckon we only need a couple of new patches:
>
> 1) Split the ops which consume the FN ids into separate psci_0_1_*() and
> psci_0_2_*() variants, with a common __psci_*() helper that takes the
> function ID as an argument. The 0_1 variants would read the function
> ID from a variable, and the 0_2 variants would hard-code the id.
>
> 2) Replace the psci_function_id array with:
>
> struct psci_0_1_function_ids {
> u32 suspend;
> u32 cpu_on;
> u32 cpu_off;
> u32 migrate;
> };
>
> ... and remove enum psci_function entirely.
>
> 3) Add a helper which returns the entire psci_0_1_function_ids struct in
> one go. No warnings necessary.
>
> Does that sound OK to you?
Sure, sounds easy enough and 2) is in line with how I structured the handlers
in KVM.
Thanks,
David
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v3 02/23] psci: Accessor for configured PSCI function IDs
2020-11-26 15:54 ` David Brazdil
(?)
@ 2020-11-26 17:34 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 147+ messages in thread
From: Lorenzo Pieralisi @ 2020-11-26 17:34 UTC (permalink / raw)
To: David Brazdil
Cc: kvmarm, Jonathan Corbet, Catalin Marinas, Will Deacon,
Marc Zyngier, James Morse, Julien Thierry, Suzuki K Poulose,
Dennis Zhou, Tejun Heo, Christoph Lameter, Mark Rutland,
Sudeep Holla, linux-doc, linux-kernel, linux-arm-kernel,
kernel-team
On Thu, Nov 26, 2020 at 03:54:00PM +0000, David Brazdil wrote:
> Function IDs used by PSCI are configurable for v0.1 via DT/APCI. If the
Side note: in ACPI we don't support versions < 0.2, for commit log
accuracy.
Other than that I agree with Mark's change request.
Thanks,
Lorenzo
> host is using PSCI v0.1, KVM's host PSCI proxy needs to use the same IDs.
> Expose the array holding the information with a read-only accessor.
>
> Signed-off-by: David Brazdil <dbrazdil@google.com>
> ---
> drivers/firmware/psci/psci.c | 16 ++++++++--------
> include/linux/psci.h | 10 ++++++++++
> 2 files changed, 18 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
> index 213c68418a65..40609564595e 100644
> --- a/drivers/firmware/psci/psci.c
> +++ b/drivers/firmware/psci/psci.c
> @@ -58,16 +58,16 @@ typedef unsigned long (psci_fn)(unsigned long, unsigned long,
> unsigned long, unsigned long);
> static psci_fn *invoke_psci_fn;
>
> -enum psci_function {
> - PSCI_FN_CPU_SUSPEND,
> - PSCI_FN_CPU_ON,
> - PSCI_FN_CPU_OFF,
> - PSCI_FN_MIGRATE,
> - PSCI_FN_MAX,
> -};
> -
> static u32 psci_function_id[PSCI_FN_MAX];
>
> +u32 psci_get_function_id(enum psci_function fn)
> +{
> + if (WARN_ON_ONCE(fn < 0 || fn >= PSCI_FN_MAX))
> + return 0;
> +
> + return psci_function_id[fn];
> +}
> +
> #define PSCI_0_2_POWER_STATE_MASK \
> (PSCI_0_2_POWER_STATE_ID_MASK | \
> PSCI_0_2_POWER_STATE_TYPE_MASK | \
> diff --git a/include/linux/psci.h b/include/linux/psci.h
> index 2a1bfb890e58..5b49a5c82d6f 100644
> --- a/include/linux/psci.h
> +++ b/include/linux/psci.h
> @@ -21,6 +21,16 @@ bool psci_power_state_is_valid(u32 state);
> int psci_set_osi_mode(bool enable);
> bool psci_has_osi_support(void);
>
> +enum psci_function {
> + PSCI_FN_CPU_SUSPEND,
> + PSCI_FN_CPU_ON,
> + PSCI_FN_CPU_OFF,
> + PSCI_FN_MIGRATE,
> + PSCI_FN_MAX,
> +};
> +
> +u32 psci_get_function_id(enum psci_function fn);
> +
> struct psci_operations {
> u32 (*get_version)(void);
> int (*cpu_suspend)(u32 state, unsigned long entry_point);
> --
> 2.29.2.454.gaff20da3a2-goog
>
^ permalink raw reply [flat|nested] 147+ messages in thread* Re: [PATCH v3 02/23] psci: Accessor for configured PSCI function IDs
@ 2020-11-26 17:34 ` Lorenzo Pieralisi
0 siblings, 0 replies; 147+ messages in thread
From: Lorenzo Pieralisi @ 2020-11-26 17:34 UTC (permalink / raw)
To: David Brazdil
Cc: Mark Rutland, Sudeep Holla, kernel-team, Jonathan Corbet,
Catalin Marinas, Suzuki K Poulose, linux-doc, linux-kernel,
James Morse, linux-arm-kernel, Marc Zyngier, Tejun Heo,
Dennis Zhou, Christoph Lameter, Will Deacon, kvmarm,
Julien Thierry
On Thu, Nov 26, 2020 at 03:54:00PM +0000, David Brazdil wrote:
> Function IDs used by PSCI are configurable for v0.1 via DT/APCI. If the
Side note: in ACPI we don't support versions < 0.2, for commit log
accuracy.
Other than that I agree with Mark's change request.
Thanks,
Lorenzo
> host is using PSCI v0.1, KVM's host PSCI proxy needs to use the same IDs.
> Expose the array holding the information with a read-only accessor.
>
> Signed-off-by: David Brazdil <dbrazdil@google.com>
> ---
> drivers/firmware/psci/psci.c | 16 ++++++++--------
> include/linux/psci.h | 10 ++++++++++
> 2 files changed, 18 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
> index 213c68418a65..40609564595e 100644
> --- a/drivers/firmware/psci/psci.c
> +++ b/drivers/firmware/psci/psci.c
> @@ -58,16 +58,16 @@ typedef unsigned long (psci_fn)(unsigned long, unsigned long,
> unsigned long, unsigned long);
> static psci_fn *invoke_psci_fn;
>
> -enum psci_function {
> - PSCI_FN_CPU_SUSPEND,
> - PSCI_FN_CPU_ON,
> - PSCI_FN_CPU_OFF,
> - PSCI_FN_MIGRATE,
> - PSCI_FN_MAX,
> -};
> -
> static u32 psci_function_id[PSCI_FN_MAX];
>
> +u32 psci_get_function_id(enum psci_function fn)
> +{
> + if (WARN_ON_ONCE(fn < 0 || fn >= PSCI_FN_MAX))
> + return 0;
> +
> + return psci_function_id[fn];
> +}
> +
> #define PSCI_0_2_POWER_STATE_MASK \
> (PSCI_0_2_POWER_STATE_ID_MASK | \
> PSCI_0_2_POWER_STATE_TYPE_MASK | \
> diff --git a/include/linux/psci.h b/include/linux/psci.h
> index 2a1bfb890e58..5b49a5c82d6f 100644
> --- a/include/linux/psci.h
> +++ b/include/linux/psci.h
> @@ -21,6 +21,16 @@ bool psci_power_state_is_valid(u32 state);
> int psci_set_osi_mode(bool enable);
> bool psci_has_osi_support(void);
>
> +enum psci_function {
> + PSCI_FN_CPU_SUSPEND,
> + PSCI_FN_CPU_ON,
> + PSCI_FN_CPU_OFF,
> + PSCI_FN_MIGRATE,
> + PSCI_FN_MAX,
> +};
> +
> +u32 psci_get_function_id(enum psci_function fn);
> +
> struct psci_operations {
> u32 (*get_version)(void);
> int (*cpu_suspend)(u32 state, unsigned long entry_point);
> --
> 2.29.2.454.gaff20da3a2-goog
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 147+ messages in thread* Re: [PATCH v3 02/23] psci: Accessor for configured PSCI function IDs
@ 2020-11-26 17:34 ` Lorenzo Pieralisi
0 siblings, 0 replies; 147+ messages in thread
From: Lorenzo Pieralisi @ 2020-11-26 17:34 UTC (permalink / raw)
To: David Brazdil
Cc: Sudeep Holla, kernel-team, Jonathan Corbet, Catalin Marinas,
linux-doc, linux-kernel, linux-arm-kernel, Marc Zyngier,
Tejun Heo, Dennis Zhou, Christoph Lameter, Will Deacon, kvmarm
On Thu, Nov 26, 2020 at 03:54:00PM +0000, David Brazdil wrote:
> Function IDs used by PSCI are configurable for v0.1 via DT/APCI. If the
Side note: in ACPI we don't support versions < 0.2, for commit log
accuracy.
Other than that I agree with Mark's change request.
Thanks,
Lorenzo
> host is using PSCI v0.1, KVM's host PSCI proxy needs to use the same IDs.
> Expose the array holding the information with a read-only accessor.
>
> Signed-off-by: David Brazdil <dbrazdil@google.com>
> ---
> drivers/firmware/psci/psci.c | 16 ++++++++--------
> include/linux/psci.h | 10 ++++++++++
> 2 files changed, 18 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
> index 213c68418a65..40609564595e 100644
> --- a/drivers/firmware/psci/psci.c
> +++ b/drivers/firmware/psci/psci.c
> @@ -58,16 +58,16 @@ typedef unsigned long (psci_fn)(unsigned long, unsigned long,
> unsigned long, unsigned long);
> static psci_fn *invoke_psci_fn;
>
> -enum psci_function {
> - PSCI_FN_CPU_SUSPEND,
> - PSCI_FN_CPU_ON,
> - PSCI_FN_CPU_OFF,
> - PSCI_FN_MIGRATE,
> - PSCI_FN_MAX,
> -};
> -
> static u32 psci_function_id[PSCI_FN_MAX];
>
> +u32 psci_get_function_id(enum psci_function fn)
> +{
> + if (WARN_ON_ONCE(fn < 0 || fn >= PSCI_FN_MAX))
> + return 0;
> +
> + return psci_function_id[fn];
> +}
> +
> #define PSCI_0_2_POWER_STATE_MASK \
> (PSCI_0_2_POWER_STATE_ID_MASK | \
> PSCI_0_2_POWER_STATE_TYPE_MASK | \
> diff --git a/include/linux/psci.h b/include/linux/psci.h
> index 2a1bfb890e58..5b49a5c82d6f 100644
> --- a/include/linux/psci.h
> +++ b/include/linux/psci.h
> @@ -21,6 +21,16 @@ bool psci_power_state_is_valid(u32 state);
> int psci_set_osi_mode(bool enable);
> bool psci_has_osi_support(void);
>
> +enum psci_function {
> + PSCI_FN_CPU_SUSPEND,
> + PSCI_FN_CPU_ON,
> + PSCI_FN_CPU_OFF,
> + PSCI_FN_MIGRATE,
> + PSCI_FN_MAX,
> +};
> +
> +u32 psci_get_function_id(enum psci_function fn);
> +
> struct psci_operations {
> u32 (*get_version)(void);
> int (*cpu_suspend)(u32 state, unsigned long entry_point);
> --
> 2.29.2.454.gaff20da3a2-goog
>
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v3 03/23] arm64: Make cpu_logical_map() take unsigned int
2020-11-26 15:53 ` David Brazdil
(?)
@ 2020-11-26 15:54 ` David Brazdil
-1 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Jonathan Corbet, Catalin Marinas, Will Deacon, Marc Zyngier,
James Morse, Julien Thierry, Suzuki K Poulose, Dennis Zhou,
Tejun Heo, Christoph Lameter, Mark Rutland, Lorenzo Pieralisi,
Sudeep Holla, linux-doc, linux-kernel, linux-arm-kernel,
kernel-team, David Brazdil
CPU index should never be negative. Change the signature of
(set_)cpu_logical_map to take an unsigned int.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
arch/arm64/include/asm/smp.h | 4 ++--
arch/arm64/kernel/setup.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/include/asm/smp.h b/arch/arm64/include/asm/smp.h
index 2e7f529ec5a6..bcb01ca15325 100644
--- a/arch/arm64/include/asm/smp.h
+++ b/arch/arm64/include/asm/smp.h
@@ -46,9 +46,9 @@ DECLARE_PER_CPU_READ_MOSTLY(int, cpu_number);
* Logical CPU mapping.
*/
extern u64 __cpu_logical_map[NR_CPUS];
-extern u64 cpu_logical_map(int cpu);
+extern u64 cpu_logical_map(unsigned int cpu);
-static inline void set_cpu_logical_map(int cpu, u64 hwid)
+static inline void set_cpu_logical_map(unsigned int cpu, u64 hwid)
{
__cpu_logical_map[cpu] = hwid;
}
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 133257ffd859..2f2973bc67c7 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -276,7 +276,7 @@ arch_initcall(reserve_memblock_reserved_regions);
u64 __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = INVALID_HWID };
-u64 cpu_logical_map(int cpu)
+u64 cpu_logical_map(unsigned int cpu)
{
return __cpu_logical_map[cpu];
}
--
2.29.2.454.gaff20da3a2-goog
^ permalink raw reply related [flat|nested] 147+ messages in thread* [PATCH v3 03/23] arm64: Make cpu_logical_map() take unsigned int
@ 2020-11-26 15:54 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Mark Rutland, Lorenzo Pieralisi, kernel-team, Jonathan Corbet,
Catalin Marinas, Suzuki K Poulose, linux-doc, linux-kernel,
Sudeep Holla, James Morse, linux-arm-kernel, Marc Zyngier,
Tejun Heo, Dennis Zhou, Christoph Lameter, David Brazdil,
Will Deacon, Julien Thierry
CPU index should never be negative. Change the signature of
(set_)cpu_logical_map to take an unsigned int.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
arch/arm64/include/asm/smp.h | 4 ++--
arch/arm64/kernel/setup.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/include/asm/smp.h b/arch/arm64/include/asm/smp.h
index 2e7f529ec5a6..bcb01ca15325 100644
--- a/arch/arm64/include/asm/smp.h
+++ b/arch/arm64/include/asm/smp.h
@@ -46,9 +46,9 @@ DECLARE_PER_CPU_READ_MOSTLY(int, cpu_number);
* Logical CPU mapping.
*/
extern u64 __cpu_logical_map[NR_CPUS];
-extern u64 cpu_logical_map(int cpu);
+extern u64 cpu_logical_map(unsigned int cpu);
-static inline void set_cpu_logical_map(int cpu, u64 hwid)
+static inline void set_cpu_logical_map(unsigned int cpu, u64 hwid)
{
__cpu_logical_map[cpu] = hwid;
}
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 133257ffd859..2f2973bc67c7 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -276,7 +276,7 @@ arch_initcall(reserve_memblock_reserved_regions);
u64 __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = INVALID_HWID };
-u64 cpu_logical_map(int cpu)
+u64 cpu_logical_map(unsigned int cpu)
{
return __cpu_logical_map[cpu];
}
--
2.29.2.454.gaff20da3a2-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 147+ messages in thread* [PATCH v3 03/23] arm64: Make cpu_logical_map() take unsigned int
@ 2020-11-26 15:54 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Lorenzo Pieralisi, kernel-team, Jonathan Corbet, Catalin Marinas,
linux-doc, linux-kernel, Sudeep Holla, linux-arm-kernel,
Marc Zyngier, Tejun Heo, Dennis Zhou, Christoph Lameter,
Will Deacon
CPU index should never be negative. Change the signature of
(set_)cpu_logical_map to take an unsigned int.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
arch/arm64/include/asm/smp.h | 4 ++--
arch/arm64/kernel/setup.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/include/asm/smp.h b/arch/arm64/include/asm/smp.h
index 2e7f529ec5a6..bcb01ca15325 100644
--- a/arch/arm64/include/asm/smp.h
+++ b/arch/arm64/include/asm/smp.h
@@ -46,9 +46,9 @@ DECLARE_PER_CPU_READ_MOSTLY(int, cpu_number);
* Logical CPU mapping.
*/
extern u64 __cpu_logical_map[NR_CPUS];
-extern u64 cpu_logical_map(int cpu);
+extern u64 cpu_logical_map(unsigned int cpu);
-static inline void set_cpu_logical_map(int cpu, u64 hwid)
+static inline void set_cpu_logical_map(unsigned int cpu, u64 hwid)
{
__cpu_logical_map[cpu] = hwid;
}
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 133257ffd859..2f2973bc67c7 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -276,7 +276,7 @@ arch_initcall(reserve_memblock_reserved_regions);
u64 __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = INVALID_HWID };
-u64 cpu_logical_map(int cpu)
+u64 cpu_logical_map(unsigned int cpu)
{
return __cpu_logical_map[cpu];
}
--
2.29.2.454.gaff20da3a2-goog
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply related [flat|nested] 147+ messages in thread* Re: [PATCH v3 03/23] arm64: Make cpu_logical_map() take unsigned int
2020-11-26 15:54 ` David Brazdil
(?)
@ 2020-11-26 17:28 ` Mark Rutland
-1 siblings, 0 replies; 147+ messages in thread
From: Mark Rutland @ 2020-11-26 17:28 UTC (permalink / raw)
To: David Brazdil
Cc: kvmarm, Jonathan Corbet, Catalin Marinas, Will Deacon,
Marc Zyngier, James Morse, Julien Thierry, Suzuki K Poulose,
Dennis Zhou, Tejun Heo, Christoph Lameter, Lorenzo Pieralisi,
Sudeep Holla, linux-doc, linux-kernel, linux-arm-kernel,
kernel-team
On Thu, Nov 26, 2020 at 03:54:01PM +0000, David Brazdil wrote:
> CPU index should never be negative. Change the signature of
> (set_)cpu_logical_map to take an unsigned int.
>
> Signed-off-by: David Brazdil <dbrazdil@google.com>
Is there a function problem here, or is this just cleanup from
inspection?
Core code including the cpuhp_*() callbacks uses an int, so if there's a
strong justification to change this, it suggests there's some treewide
cleanup that should be done.
I don't have strong feelings on the matter, but I'd like to understand
the rationale.
Thanks,
Mark.
> ---
> arch/arm64/include/asm/smp.h | 4 ++--
> arch/arm64/kernel/setup.c | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/include/asm/smp.h b/arch/arm64/include/asm/smp.h
> index 2e7f529ec5a6..bcb01ca15325 100644
> --- a/arch/arm64/include/asm/smp.h
> +++ b/arch/arm64/include/asm/smp.h
> @@ -46,9 +46,9 @@ DECLARE_PER_CPU_READ_MOSTLY(int, cpu_number);
> * Logical CPU mapping.
> */
> extern u64 __cpu_logical_map[NR_CPUS];
> -extern u64 cpu_logical_map(int cpu);
> +extern u64 cpu_logical_map(unsigned int cpu);
>
> -static inline void set_cpu_logical_map(int cpu, u64 hwid)
> +static inline void set_cpu_logical_map(unsigned int cpu, u64 hwid)
> {
> __cpu_logical_map[cpu] = hwid;
> }
> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> index 133257ffd859..2f2973bc67c7 100644
> --- a/arch/arm64/kernel/setup.c
> +++ b/arch/arm64/kernel/setup.c
> @@ -276,7 +276,7 @@ arch_initcall(reserve_memblock_reserved_regions);
>
> u64 __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = INVALID_HWID };
>
> -u64 cpu_logical_map(int cpu)
> +u64 cpu_logical_map(unsigned int cpu)
> {
> return __cpu_logical_map[cpu];
> }
> --
> 2.29.2.454.gaff20da3a2-goog
>
^ permalink raw reply [flat|nested] 147+ messages in thread* Re: [PATCH v3 03/23] arm64: Make cpu_logical_map() take unsigned int
@ 2020-11-26 17:28 ` Mark Rutland
0 siblings, 0 replies; 147+ messages in thread
From: Mark Rutland @ 2020-11-26 17:28 UTC (permalink / raw)
To: David Brazdil
Cc: Lorenzo Pieralisi, kernel-team, Jonathan Corbet, Catalin Marinas,
Suzuki K Poulose, linux-doc, linux-kernel, Sudeep Holla,
James Morse, linux-arm-kernel, Marc Zyngier, Tejun Heo,
Dennis Zhou, Christoph Lameter, Will Deacon, kvmarm,
Julien Thierry
On Thu, Nov 26, 2020 at 03:54:01PM +0000, David Brazdil wrote:
> CPU index should never be negative. Change the signature of
> (set_)cpu_logical_map to take an unsigned int.
>
> Signed-off-by: David Brazdil <dbrazdil@google.com>
Is there a function problem here, or is this just cleanup from
inspection?
Core code including the cpuhp_*() callbacks uses an int, so if there's a
strong justification to change this, it suggests there's some treewide
cleanup that should be done.
I don't have strong feelings on the matter, but I'd like to understand
the rationale.
Thanks,
Mark.
> ---
> arch/arm64/include/asm/smp.h | 4 ++--
> arch/arm64/kernel/setup.c | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/include/asm/smp.h b/arch/arm64/include/asm/smp.h
> index 2e7f529ec5a6..bcb01ca15325 100644
> --- a/arch/arm64/include/asm/smp.h
> +++ b/arch/arm64/include/asm/smp.h
> @@ -46,9 +46,9 @@ DECLARE_PER_CPU_READ_MOSTLY(int, cpu_number);
> * Logical CPU mapping.
> */
> extern u64 __cpu_logical_map[NR_CPUS];
> -extern u64 cpu_logical_map(int cpu);
> +extern u64 cpu_logical_map(unsigned int cpu);
>
> -static inline void set_cpu_logical_map(int cpu, u64 hwid)
> +static inline void set_cpu_logical_map(unsigned int cpu, u64 hwid)
> {
> __cpu_logical_map[cpu] = hwid;
> }
> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> index 133257ffd859..2f2973bc67c7 100644
> --- a/arch/arm64/kernel/setup.c
> +++ b/arch/arm64/kernel/setup.c
> @@ -276,7 +276,7 @@ arch_initcall(reserve_memblock_reserved_regions);
>
> u64 __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = INVALID_HWID };
>
> -u64 cpu_logical_map(int cpu)
> +u64 cpu_logical_map(unsigned int cpu)
> {
> return __cpu_logical_map[cpu];
> }
> --
> 2.29.2.454.gaff20da3a2-goog
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 147+ messages in thread* Re: [PATCH v3 03/23] arm64: Make cpu_logical_map() take unsigned int
@ 2020-11-26 17:28 ` Mark Rutland
0 siblings, 0 replies; 147+ messages in thread
From: Mark Rutland @ 2020-11-26 17:28 UTC (permalink / raw)
To: David Brazdil
Cc: Lorenzo Pieralisi, kernel-team, Jonathan Corbet, Catalin Marinas,
linux-doc, linux-kernel, Sudeep Holla, linux-arm-kernel,
Marc Zyngier, Tejun Heo, Dennis Zhou, Christoph Lameter,
Will Deacon, kvmarm
On Thu, Nov 26, 2020 at 03:54:01PM +0000, David Brazdil wrote:
> CPU index should never be negative. Change the signature of
> (set_)cpu_logical_map to take an unsigned int.
>
> Signed-off-by: David Brazdil <dbrazdil@google.com>
Is there a function problem here, or is this just cleanup from
inspection?
Core code including the cpuhp_*() callbacks uses an int, so if there's a
strong justification to change this, it suggests there's some treewide
cleanup that should be done.
I don't have strong feelings on the matter, but I'd like to understand
the rationale.
Thanks,
Mark.
> ---
> arch/arm64/include/asm/smp.h | 4 ++--
> arch/arm64/kernel/setup.c | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/include/asm/smp.h b/arch/arm64/include/asm/smp.h
> index 2e7f529ec5a6..bcb01ca15325 100644
> --- a/arch/arm64/include/asm/smp.h
> +++ b/arch/arm64/include/asm/smp.h
> @@ -46,9 +46,9 @@ DECLARE_PER_CPU_READ_MOSTLY(int, cpu_number);
> * Logical CPU mapping.
> */
> extern u64 __cpu_logical_map[NR_CPUS];
> -extern u64 cpu_logical_map(int cpu);
> +extern u64 cpu_logical_map(unsigned int cpu);
>
> -static inline void set_cpu_logical_map(int cpu, u64 hwid)
> +static inline void set_cpu_logical_map(unsigned int cpu, u64 hwid)
> {
> __cpu_logical_map[cpu] = hwid;
> }
> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> index 133257ffd859..2f2973bc67c7 100644
> --- a/arch/arm64/kernel/setup.c
> +++ b/arch/arm64/kernel/setup.c
> @@ -276,7 +276,7 @@ arch_initcall(reserve_memblock_reserved_regions);
>
> u64 __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = INVALID_HWID };
>
> -u64 cpu_logical_map(int cpu)
> +u64 cpu_logical_map(unsigned int cpu)
> {
> return __cpu_logical_map[cpu];
> }
> --
> 2.29.2.454.gaff20da3a2-goog
>
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 147+ messages in thread* Re: [PATCH v3 03/23] arm64: Make cpu_logical_map() take unsigned int
2020-11-26 17:28 ` Mark Rutland
(?)
@ 2020-12-02 15:44 ` David Brazdil
-1 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-12-02 15:44 UTC (permalink / raw)
To: Mark Rutland
Cc: kvmarm, Jonathan Corbet, Catalin Marinas, Will Deacon,
Marc Zyngier, James Morse, Julien Thierry, Suzuki K Poulose,
Dennis Zhou, Tejun Heo, Christoph Lameter, Lorenzo Pieralisi,
Sudeep Holla, linux-doc, linux-kernel, linux-arm-kernel,
kernel-team
On Thu, Nov 26, 2020 at 05:28:38PM +0000, Mark Rutland wrote:
> On Thu, Nov 26, 2020 at 03:54:01PM +0000, David Brazdil wrote:
> > CPU index should never be negative. Change the signature of
> > (set_)cpu_logical_map to take an unsigned int.
> >
> > Signed-off-by: David Brazdil <dbrazdil@google.com>
>
> Is there a function problem here, or is this just cleanup from
> inspection?
>
> Core code including the cpuhp_*() callbacks uses an int, so if there's a
> strong justification to change this, it suggests there's some treewide
> cleanup that should be done.
>
> I don't have strong feelings on the matter, but I'd like to understand
> the rationale.
Yeah, it's a mess. Marc and I felt that using a uint was less error-prone wrt
bounds checks. If this gets an int, it still works and only checking the upper
bound is required. Does that make sense?
David
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v3 03/23] arm64: Make cpu_logical_map() take unsigned int
@ 2020-12-02 15:44 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-12-02 15:44 UTC (permalink / raw)
To: Mark Rutland
Cc: Lorenzo Pieralisi, kernel-team, Jonathan Corbet, Catalin Marinas,
Suzuki K Poulose, linux-doc, linux-kernel, Sudeep Holla,
James Morse, linux-arm-kernel, Marc Zyngier, Tejun Heo,
Dennis Zhou, Christoph Lameter, Will Deacon, kvmarm,
Julien Thierry
On Thu, Nov 26, 2020 at 05:28:38PM +0000, Mark Rutland wrote:
> On Thu, Nov 26, 2020 at 03:54:01PM +0000, David Brazdil wrote:
> > CPU index should never be negative. Change the signature of
> > (set_)cpu_logical_map to take an unsigned int.
> >
> > Signed-off-by: David Brazdil <dbrazdil@google.com>
>
> Is there a function problem here, or is this just cleanup from
> inspection?
>
> Core code including the cpuhp_*() callbacks uses an int, so if there's a
> strong justification to change this, it suggests there's some treewide
> cleanup that should be done.
>
> I don't have strong feelings on the matter, but I'd like to understand
> the rationale.
Yeah, it's a mess. Marc and I felt that using a uint was less error-prone wrt
bounds checks. If this gets an int, it still works and only checking the upper
bound is required. Does that make sense?
David
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v3 03/23] arm64: Make cpu_logical_map() take unsigned int
@ 2020-12-02 15:44 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-12-02 15:44 UTC (permalink / raw)
To: Mark Rutland
Cc: Lorenzo Pieralisi, kernel-team, Jonathan Corbet, Catalin Marinas,
linux-doc, linux-kernel, Sudeep Holla, linux-arm-kernel,
Marc Zyngier, Tejun Heo, Dennis Zhou, Christoph Lameter,
Will Deacon, kvmarm
On Thu, Nov 26, 2020 at 05:28:38PM +0000, Mark Rutland wrote:
> On Thu, Nov 26, 2020 at 03:54:01PM +0000, David Brazdil wrote:
> > CPU index should never be negative. Change the signature of
> > (set_)cpu_logical_map to take an unsigned int.
> >
> > Signed-off-by: David Brazdil <dbrazdil@google.com>
>
> Is there a function problem here, or is this just cleanup from
> inspection?
>
> Core code including the cpuhp_*() callbacks uses an int, so if there's a
> strong justification to change this, it suggests there's some treewide
> cleanup that should be done.
>
> I don't have strong feelings on the matter, but I'd like to understand
> the rationale.
Yeah, it's a mess. Marc and I felt that using a uint was less error-prone wrt
bounds checks. If this gets an int, it still works and only checking the upper
bound is required. Does that make sense?
David
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v3 04/23] arm64: Move MAIR_EL1_SET to asm/memory.h
2020-11-26 15:53 ` David Brazdil
(?)
@ 2020-11-26 15:54 ` David Brazdil
-1 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Jonathan Corbet, Catalin Marinas, Will Deacon, Marc Zyngier,
James Morse, Julien Thierry, Suzuki K Poulose, Dennis Zhou,
Tejun Heo, Christoph Lameter, Mark Rutland, Lorenzo Pieralisi,
Sudeep Holla, linux-doc, linux-kernel, linux-arm-kernel,
kernel-team, David Brazdil
KVM currently initializes MAIR_EL2 to the value of MAIR_EL1. In
preparation for initializing MAIR_EL2 before MAIR_EL1, move the constant
into a shared header file. Since it is used for EL1 and EL2, rename to
MAIR_ELx_SET.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
arch/arm64/include/asm/memory.h | 13 +++++++++++++
arch/arm64/mm/proc.S | 15 +--------------
2 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index cd61239bae8c..54a22cb5b17b 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -152,6 +152,19 @@
#define MT_S2_FWB_NORMAL 6
#define MT_S2_FWB_DEVICE_nGnRE 1
+/*
+ * Default MAIR_ELx. MT_NORMAL_TAGGED is initially mapped as Normal memory and
+ * changed during __cpu_setup to Normal Tagged if the system supports MTE.
+ */
+#define MAIR_ELx_SET \
+ (MAIR_ATTRIDX(MAIR_ATTR_DEVICE_nGnRnE, MT_DEVICE_nGnRnE) | \
+ MAIR_ATTRIDX(MAIR_ATTR_DEVICE_nGnRE, MT_DEVICE_nGnRE) | \
+ MAIR_ATTRIDX(MAIR_ATTR_DEVICE_GRE, MT_DEVICE_GRE) | \
+ MAIR_ATTRIDX(MAIR_ATTR_NORMAL_NC, MT_NORMAL_NC) | \
+ MAIR_ATTRIDX(MAIR_ATTR_NORMAL, MT_NORMAL) | \
+ MAIR_ATTRIDX(MAIR_ATTR_NORMAL_WT, MT_NORMAL_WT) | \
+ MAIR_ATTRIDX(MAIR_ATTR_NORMAL, MT_NORMAL_TAGGED))
+
#ifdef CONFIG_ARM64_4K_PAGES
#define IOREMAP_MAX_ORDER (PUD_SHIFT)
#else
diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
index 23c326a06b2d..e3b9aa372b96 100644
--- a/arch/arm64/mm/proc.S
+++ b/arch/arm64/mm/proc.S
@@ -45,19 +45,6 @@
#define TCR_KASAN_FLAGS 0
#endif
-/*
- * Default MAIR_EL1. MT_NORMAL_TAGGED is initially mapped as Normal memory and
- * changed during __cpu_setup to Normal Tagged if the system supports MTE.
- */
-#define MAIR_EL1_SET \
- (MAIR_ATTRIDX(MAIR_ATTR_DEVICE_nGnRnE, MT_DEVICE_nGnRnE) | \
- MAIR_ATTRIDX(MAIR_ATTR_DEVICE_nGnRE, MT_DEVICE_nGnRE) | \
- MAIR_ATTRIDX(MAIR_ATTR_DEVICE_GRE, MT_DEVICE_GRE) | \
- MAIR_ATTRIDX(MAIR_ATTR_NORMAL_NC, MT_NORMAL_NC) | \
- MAIR_ATTRIDX(MAIR_ATTR_NORMAL, MT_NORMAL) | \
- MAIR_ATTRIDX(MAIR_ATTR_NORMAL_WT, MT_NORMAL_WT) | \
- MAIR_ATTRIDX(MAIR_ATTR_NORMAL, MT_NORMAL_TAGGED))
-
#ifdef CONFIG_CPU_PM
/**
* cpu_do_suspend - save CPU registers context
@@ -425,7 +412,7 @@ SYM_FUNC_START(__cpu_setup)
/*
* Memory region attributes
*/
- mov_q x5, MAIR_EL1_SET
+ mov_q x5, MAIR_ELx_SET
#ifdef CONFIG_ARM64_MTE
/*
* Update MAIR_EL1, GCR_EL1 and TFSR*_EL1 if MTE is supported
--
2.29.2.454.gaff20da3a2-goog
^ permalink raw reply related [flat|nested] 147+ messages in thread
* [PATCH v3 04/23] arm64: Move MAIR_EL1_SET to asm/memory.h
@ 2020-11-26 15:54 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Mark Rutland, Lorenzo Pieralisi, kernel-team, Jonathan Corbet,
Catalin Marinas, Suzuki K Poulose, linux-doc, linux-kernel,
Sudeep Holla, James Morse, linux-arm-kernel, Marc Zyngier,
Tejun Heo, Dennis Zhou, Christoph Lameter, David Brazdil,
Will Deacon, Julien Thierry
KVM currently initializes MAIR_EL2 to the value of MAIR_EL1. In
preparation for initializing MAIR_EL2 before MAIR_EL1, move the constant
into a shared header file. Since it is used for EL1 and EL2, rename to
MAIR_ELx_SET.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
arch/arm64/include/asm/memory.h | 13 +++++++++++++
arch/arm64/mm/proc.S | 15 +--------------
2 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index cd61239bae8c..54a22cb5b17b 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -152,6 +152,19 @@
#define MT_S2_FWB_NORMAL 6
#define MT_S2_FWB_DEVICE_nGnRE 1
+/*
+ * Default MAIR_ELx. MT_NORMAL_TAGGED is initially mapped as Normal memory and
+ * changed during __cpu_setup to Normal Tagged if the system supports MTE.
+ */
+#define MAIR_ELx_SET \
+ (MAIR_ATTRIDX(MAIR_ATTR_DEVICE_nGnRnE, MT_DEVICE_nGnRnE) | \
+ MAIR_ATTRIDX(MAIR_ATTR_DEVICE_nGnRE, MT_DEVICE_nGnRE) | \
+ MAIR_ATTRIDX(MAIR_ATTR_DEVICE_GRE, MT_DEVICE_GRE) | \
+ MAIR_ATTRIDX(MAIR_ATTR_NORMAL_NC, MT_NORMAL_NC) | \
+ MAIR_ATTRIDX(MAIR_ATTR_NORMAL, MT_NORMAL) | \
+ MAIR_ATTRIDX(MAIR_ATTR_NORMAL_WT, MT_NORMAL_WT) | \
+ MAIR_ATTRIDX(MAIR_ATTR_NORMAL, MT_NORMAL_TAGGED))
+
#ifdef CONFIG_ARM64_4K_PAGES
#define IOREMAP_MAX_ORDER (PUD_SHIFT)
#else
diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
index 23c326a06b2d..e3b9aa372b96 100644
--- a/arch/arm64/mm/proc.S
+++ b/arch/arm64/mm/proc.S
@@ -45,19 +45,6 @@
#define TCR_KASAN_FLAGS 0
#endif
-/*
- * Default MAIR_EL1. MT_NORMAL_TAGGED is initially mapped as Normal memory and
- * changed during __cpu_setup to Normal Tagged if the system supports MTE.
- */
-#define MAIR_EL1_SET \
- (MAIR_ATTRIDX(MAIR_ATTR_DEVICE_nGnRnE, MT_DEVICE_nGnRnE) | \
- MAIR_ATTRIDX(MAIR_ATTR_DEVICE_nGnRE, MT_DEVICE_nGnRE) | \
- MAIR_ATTRIDX(MAIR_ATTR_DEVICE_GRE, MT_DEVICE_GRE) | \
- MAIR_ATTRIDX(MAIR_ATTR_NORMAL_NC, MT_NORMAL_NC) | \
- MAIR_ATTRIDX(MAIR_ATTR_NORMAL, MT_NORMAL) | \
- MAIR_ATTRIDX(MAIR_ATTR_NORMAL_WT, MT_NORMAL_WT) | \
- MAIR_ATTRIDX(MAIR_ATTR_NORMAL, MT_NORMAL_TAGGED))
-
#ifdef CONFIG_CPU_PM
/**
* cpu_do_suspend - save CPU registers context
@@ -425,7 +412,7 @@ SYM_FUNC_START(__cpu_setup)
/*
* Memory region attributes
*/
- mov_q x5, MAIR_EL1_SET
+ mov_q x5, MAIR_ELx_SET
#ifdef CONFIG_ARM64_MTE
/*
* Update MAIR_EL1, GCR_EL1 and TFSR*_EL1 if MTE is supported
--
2.29.2.454.gaff20da3a2-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 147+ messages in thread
* [PATCH v3 04/23] arm64: Move MAIR_EL1_SET to asm/memory.h
@ 2020-11-26 15:54 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Lorenzo Pieralisi, kernel-team, Jonathan Corbet, Catalin Marinas,
linux-doc, linux-kernel, Sudeep Holla, linux-arm-kernel,
Marc Zyngier, Tejun Heo, Dennis Zhou, Christoph Lameter,
Will Deacon
KVM currently initializes MAIR_EL2 to the value of MAIR_EL1. In
preparation for initializing MAIR_EL2 before MAIR_EL1, move the constant
into a shared header file. Since it is used for EL1 and EL2, rename to
MAIR_ELx_SET.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
arch/arm64/include/asm/memory.h | 13 +++++++++++++
arch/arm64/mm/proc.S | 15 +--------------
2 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index cd61239bae8c..54a22cb5b17b 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -152,6 +152,19 @@
#define MT_S2_FWB_NORMAL 6
#define MT_S2_FWB_DEVICE_nGnRE 1
+/*
+ * Default MAIR_ELx. MT_NORMAL_TAGGED is initially mapped as Normal memory and
+ * changed during __cpu_setup to Normal Tagged if the system supports MTE.
+ */
+#define MAIR_ELx_SET \
+ (MAIR_ATTRIDX(MAIR_ATTR_DEVICE_nGnRnE, MT_DEVICE_nGnRnE) | \
+ MAIR_ATTRIDX(MAIR_ATTR_DEVICE_nGnRE, MT_DEVICE_nGnRE) | \
+ MAIR_ATTRIDX(MAIR_ATTR_DEVICE_GRE, MT_DEVICE_GRE) | \
+ MAIR_ATTRIDX(MAIR_ATTR_NORMAL_NC, MT_NORMAL_NC) | \
+ MAIR_ATTRIDX(MAIR_ATTR_NORMAL, MT_NORMAL) | \
+ MAIR_ATTRIDX(MAIR_ATTR_NORMAL_WT, MT_NORMAL_WT) | \
+ MAIR_ATTRIDX(MAIR_ATTR_NORMAL, MT_NORMAL_TAGGED))
+
#ifdef CONFIG_ARM64_4K_PAGES
#define IOREMAP_MAX_ORDER (PUD_SHIFT)
#else
diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
index 23c326a06b2d..e3b9aa372b96 100644
--- a/arch/arm64/mm/proc.S
+++ b/arch/arm64/mm/proc.S
@@ -45,19 +45,6 @@
#define TCR_KASAN_FLAGS 0
#endif
-/*
- * Default MAIR_EL1. MT_NORMAL_TAGGED is initially mapped as Normal memory and
- * changed during __cpu_setup to Normal Tagged if the system supports MTE.
- */
-#define MAIR_EL1_SET \
- (MAIR_ATTRIDX(MAIR_ATTR_DEVICE_nGnRnE, MT_DEVICE_nGnRnE) | \
- MAIR_ATTRIDX(MAIR_ATTR_DEVICE_nGnRE, MT_DEVICE_nGnRE) | \
- MAIR_ATTRIDX(MAIR_ATTR_DEVICE_GRE, MT_DEVICE_GRE) | \
- MAIR_ATTRIDX(MAIR_ATTR_NORMAL_NC, MT_NORMAL_NC) | \
- MAIR_ATTRIDX(MAIR_ATTR_NORMAL, MT_NORMAL) | \
- MAIR_ATTRIDX(MAIR_ATTR_NORMAL_WT, MT_NORMAL_WT) | \
- MAIR_ATTRIDX(MAIR_ATTR_NORMAL, MT_NORMAL_TAGGED))
-
#ifdef CONFIG_CPU_PM
/**
* cpu_do_suspend - save CPU registers context
@@ -425,7 +412,7 @@ SYM_FUNC_START(__cpu_setup)
/*
* Memory region attributes
*/
- mov_q x5, MAIR_EL1_SET
+ mov_q x5, MAIR_ELx_SET
#ifdef CONFIG_ARM64_MTE
/*
* Update MAIR_EL1, GCR_EL1 and TFSR*_EL1 if MTE is supported
--
2.29.2.454.gaff20da3a2-goog
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply related [flat|nested] 147+ messages in thread
* Re: [PATCH v3 04/23] arm64: Move MAIR_EL1_SET to asm/memory.h
2020-11-26 15:54 ` David Brazdil
(?)
@ 2020-11-26 17:35 ` Mark Rutland
-1 siblings, 0 replies; 147+ messages in thread
From: Mark Rutland @ 2020-11-26 17:35 UTC (permalink / raw)
To: David Brazdil
Cc: kvmarm, Jonathan Corbet, Catalin Marinas, Will Deacon,
Marc Zyngier, James Morse, Julien Thierry, Suzuki K Poulose,
Dennis Zhou, Tejun Heo, Christoph Lameter, Lorenzo Pieralisi,
Sudeep Holla, linux-doc, linux-kernel, linux-arm-kernel,
kernel-team
On Thu, Nov 26, 2020 at 03:54:02PM +0000, David Brazdil wrote:
> KVM currently initializes MAIR_EL2 to the value of MAIR_EL1. In
> preparation for initializing MAIR_EL2 before MAIR_EL1, move the constant
> into a shared header file. Since it is used for EL1 and EL2, rename to
> MAIR_ELx_SET.
>
> Signed-off-by: David Brazdil <dbrazdil@google.com>
> ---
> arch/arm64/include/asm/memory.h | 13 +++++++++++++
> arch/arm64/mm/proc.S | 15 +--------------
> 2 files changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> index cd61239bae8c..54a22cb5b17b 100644
> --- a/arch/arm64/include/asm/memory.h
> +++ b/arch/arm64/include/asm/memory.h
> @@ -152,6 +152,19 @@
> #define MT_S2_FWB_NORMAL 6
> #define MT_S2_FWB_DEVICE_nGnRE 1
>
> +/*
> + * Default MAIR_ELx. MT_NORMAL_TAGGED is initially mapped as Normal memory and
> + * changed during __cpu_setup to Normal Tagged if the system supports MTE.
> + */
> +#define MAIR_ELx_SET \
> + (MAIR_ATTRIDX(MAIR_ATTR_DEVICE_nGnRnE, MT_DEVICE_nGnRnE) | \
> + MAIR_ATTRIDX(MAIR_ATTR_DEVICE_nGnRE, MT_DEVICE_nGnRE) | \
> + MAIR_ATTRIDX(MAIR_ATTR_DEVICE_GRE, MT_DEVICE_GRE) | \
> + MAIR_ATTRIDX(MAIR_ATTR_NORMAL_NC, MT_NORMAL_NC) | \
> + MAIR_ATTRIDX(MAIR_ATTR_NORMAL, MT_NORMAL) | \
> + MAIR_ATTRIDX(MAIR_ATTR_NORMAL_WT, MT_NORMAL_WT) | \
> + MAIR_ATTRIDX(MAIR_ATTR_NORMAL, MT_NORMAL_TAGGED))
Patch 7 initializes MAIR_EL2 with this directly rather than copying it
from MAIR_EL1, which means that MT_NORMAL_TAGGED will never be tagged
within the nVHE hyp code.
Is that expected? I suspect it's worth a comment here (introduced in
patch 7), just to make that clear.
Otherwise this looks fine to me.
Thanks,
Mark.
> +
> #ifdef CONFIG_ARM64_4K_PAGES
> #define IOREMAP_MAX_ORDER (PUD_SHIFT)
> #else
> diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
> index 23c326a06b2d..e3b9aa372b96 100644
> --- a/arch/arm64/mm/proc.S
> +++ b/arch/arm64/mm/proc.S
> @@ -45,19 +45,6 @@
> #define TCR_KASAN_FLAGS 0
> #endif
>
> -/*
> - * Default MAIR_EL1. MT_NORMAL_TAGGED is initially mapped as Normal memory and
> - * changed during __cpu_setup to Normal Tagged if the system supports MTE.
> - */
> -#define MAIR_EL1_SET \
> - (MAIR_ATTRIDX(MAIR_ATTR_DEVICE_nGnRnE, MT_DEVICE_nGnRnE) | \
> - MAIR_ATTRIDX(MAIR_ATTR_DEVICE_nGnRE, MT_DEVICE_nGnRE) | \
> - MAIR_ATTRIDX(MAIR_ATTR_DEVICE_GRE, MT_DEVICE_GRE) | \
> - MAIR_ATTRIDX(MAIR_ATTR_NORMAL_NC, MT_NORMAL_NC) | \
> - MAIR_ATTRIDX(MAIR_ATTR_NORMAL, MT_NORMAL) | \
> - MAIR_ATTRIDX(MAIR_ATTR_NORMAL_WT, MT_NORMAL_WT) | \
> - MAIR_ATTRIDX(MAIR_ATTR_NORMAL, MT_NORMAL_TAGGED))
> -
> #ifdef CONFIG_CPU_PM
> /**
> * cpu_do_suspend - save CPU registers context
> @@ -425,7 +412,7 @@ SYM_FUNC_START(__cpu_setup)
> /*
> * Memory region attributes
> */
> - mov_q x5, MAIR_EL1_SET
> + mov_q x5, MAIR_ELx_SET
> #ifdef CONFIG_ARM64_MTE
> /*
> * Update MAIR_EL1, GCR_EL1 and TFSR*_EL1 if MTE is supported
> --
> 2.29.2.454.gaff20da3a2-goog
>
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v3 04/23] arm64: Move MAIR_EL1_SET to asm/memory.h
@ 2020-11-26 17:35 ` Mark Rutland
0 siblings, 0 replies; 147+ messages in thread
From: Mark Rutland @ 2020-11-26 17:35 UTC (permalink / raw)
To: David Brazdil
Cc: Lorenzo Pieralisi, kernel-team, Jonathan Corbet, Catalin Marinas,
Suzuki K Poulose, linux-doc, linux-kernel, Sudeep Holla,
James Morse, linux-arm-kernel, Marc Zyngier, Tejun Heo,
Dennis Zhou, Christoph Lameter, Will Deacon, kvmarm,
Julien Thierry
On Thu, Nov 26, 2020 at 03:54:02PM +0000, David Brazdil wrote:
> KVM currently initializes MAIR_EL2 to the value of MAIR_EL1. In
> preparation for initializing MAIR_EL2 before MAIR_EL1, move the constant
> into a shared header file. Since it is used for EL1 and EL2, rename to
> MAIR_ELx_SET.
>
> Signed-off-by: David Brazdil <dbrazdil@google.com>
> ---
> arch/arm64/include/asm/memory.h | 13 +++++++++++++
> arch/arm64/mm/proc.S | 15 +--------------
> 2 files changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> index cd61239bae8c..54a22cb5b17b 100644
> --- a/arch/arm64/include/asm/memory.h
> +++ b/arch/arm64/include/asm/memory.h
> @@ -152,6 +152,19 @@
> #define MT_S2_FWB_NORMAL 6
> #define MT_S2_FWB_DEVICE_nGnRE 1
>
> +/*
> + * Default MAIR_ELx. MT_NORMAL_TAGGED is initially mapped as Normal memory and
> + * changed during __cpu_setup to Normal Tagged if the system supports MTE.
> + */
> +#define MAIR_ELx_SET \
> + (MAIR_ATTRIDX(MAIR_ATTR_DEVICE_nGnRnE, MT_DEVICE_nGnRnE) | \
> + MAIR_ATTRIDX(MAIR_ATTR_DEVICE_nGnRE, MT_DEVICE_nGnRE) | \
> + MAIR_ATTRIDX(MAIR_ATTR_DEVICE_GRE, MT_DEVICE_GRE) | \
> + MAIR_ATTRIDX(MAIR_ATTR_NORMAL_NC, MT_NORMAL_NC) | \
> + MAIR_ATTRIDX(MAIR_ATTR_NORMAL, MT_NORMAL) | \
> + MAIR_ATTRIDX(MAIR_ATTR_NORMAL_WT, MT_NORMAL_WT) | \
> + MAIR_ATTRIDX(MAIR_ATTR_NORMAL, MT_NORMAL_TAGGED))
Patch 7 initializes MAIR_EL2 with this directly rather than copying it
from MAIR_EL1, which means that MT_NORMAL_TAGGED will never be tagged
within the nVHE hyp code.
Is that expected? I suspect it's worth a comment here (introduced in
patch 7), just to make that clear.
Otherwise this looks fine to me.
Thanks,
Mark.
> +
> #ifdef CONFIG_ARM64_4K_PAGES
> #define IOREMAP_MAX_ORDER (PUD_SHIFT)
> #else
> diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
> index 23c326a06b2d..e3b9aa372b96 100644
> --- a/arch/arm64/mm/proc.S
> +++ b/arch/arm64/mm/proc.S
> @@ -45,19 +45,6 @@
> #define TCR_KASAN_FLAGS 0
> #endif
>
> -/*
> - * Default MAIR_EL1. MT_NORMAL_TAGGED is initially mapped as Normal memory and
> - * changed during __cpu_setup to Normal Tagged if the system supports MTE.
> - */
> -#define MAIR_EL1_SET \
> - (MAIR_ATTRIDX(MAIR_ATTR_DEVICE_nGnRnE, MT_DEVICE_nGnRnE) | \
> - MAIR_ATTRIDX(MAIR_ATTR_DEVICE_nGnRE, MT_DEVICE_nGnRE) | \
> - MAIR_ATTRIDX(MAIR_ATTR_DEVICE_GRE, MT_DEVICE_GRE) | \
> - MAIR_ATTRIDX(MAIR_ATTR_NORMAL_NC, MT_NORMAL_NC) | \
> - MAIR_ATTRIDX(MAIR_ATTR_NORMAL, MT_NORMAL) | \
> - MAIR_ATTRIDX(MAIR_ATTR_NORMAL_WT, MT_NORMAL_WT) | \
> - MAIR_ATTRIDX(MAIR_ATTR_NORMAL, MT_NORMAL_TAGGED))
> -
> #ifdef CONFIG_CPU_PM
> /**
> * cpu_do_suspend - save CPU registers context
> @@ -425,7 +412,7 @@ SYM_FUNC_START(__cpu_setup)
> /*
> * Memory region attributes
> */
> - mov_q x5, MAIR_EL1_SET
> + mov_q x5, MAIR_ELx_SET
> #ifdef CONFIG_ARM64_MTE
> /*
> * Update MAIR_EL1, GCR_EL1 and TFSR*_EL1 if MTE is supported
> --
> 2.29.2.454.gaff20da3a2-goog
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v3 04/23] arm64: Move MAIR_EL1_SET to asm/memory.h
@ 2020-11-26 17:35 ` Mark Rutland
0 siblings, 0 replies; 147+ messages in thread
From: Mark Rutland @ 2020-11-26 17:35 UTC (permalink / raw)
To: David Brazdil
Cc: Lorenzo Pieralisi, kernel-team, Jonathan Corbet, Catalin Marinas,
linux-doc, linux-kernel, Sudeep Holla, linux-arm-kernel,
Marc Zyngier, Tejun Heo, Dennis Zhou, Christoph Lameter,
Will Deacon, kvmarm
On Thu, Nov 26, 2020 at 03:54:02PM +0000, David Brazdil wrote:
> KVM currently initializes MAIR_EL2 to the value of MAIR_EL1. In
> preparation for initializing MAIR_EL2 before MAIR_EL1, move the constant
> into a shared header file. Since it is used for EL1 and EL2, rename to
> MAIR_ELx_SET.
>
> Signed-off-by: David Brazdil <dbrazdil@google.com>
> ---
> arch/arm64/include/asm/memory.h | 13 +++++++++++++
> arch/arm64/mm/proc.S | 15 +--------------
> 2 files changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> index cd61239bae8c..54a22cb5b17b 100644
> --- a/arch/arm64/include/asm/memory.h
> +++ b/arch/arm64/include/asm/memory.h
> @@ -152,6 +152,19 @@
> #define MT_S2_FWB_NORMAL 6
> #define MT_S2_FWB_DEVICE_nGnRE 1
>
> +/*
> + * Default MAIR_ELx. MT_NORMAL_TAGGED is initially mapped as Normal memory and
> + * changed during __cpu_setup to Normal Tagged if the system supports MTE.
> + */
> +#define MAIR_ELx_SET \
> + (MAIR_ATTRIDX(MAIR_ATTR_DEVICE_nGnRnE, MT_DEVICE_nGnRnE) | \
> + MAIR_ATTRIDX(MAIR_ATTR_DEVICE_nGnRE, MT_DEVICE_nGnRE) | \
> + MAIR_ATTRIDX(MAIR_ATTR_DEVICE_GRE, MT_DEVICE_GRE) | \
> + MAIR_ATTRIDX(MAIR_ATTR_NORMAL_NC, MT_NORMAL_NC) | \
> + MAIR_ATTRIDX(MAIR_ATTR_NORMAL, MT_NORMAL) | \
> + MAIR_ATTRIDX(MAIR_ATTR_NORMAL_WT, MT_NORMAL_WT) | \
> + MAIR_ATTRIDX(MAIR_ATTR_NORMAL, MT_NORMAL_TAGGED))
Patch 7 initializes MAIR_EL2 with this directly rather than copying it
from MAIR_EL1, which means that MT_NORMAL_TAGGED will never be tagged
within the nVHE hyp code.
Is that expected? I suspect it's worth a comment here (introduced in
patch 7), just to make that clear.
Otherwise this looks fine to me.
Thanks,
Mark.
> +
> #ifdef CONFIG_ARM64_4K_PAGES
> #define IOREMAP_MAX_ORDER (PUD_SHIFT)
> #else
> diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
> index 23c326a06b2d..e3b9aa372b96 100644
> --- a/arch/arm64/mm/proc.S
> +++ b/arch/arm64/mm/proc.S
> @@ -45,19 +45,6 @@
> #define TCR_KASAN_FLAGS 0
> #endif
>
> -/*
> - * Default MAIR_EL1. MT_NORMAL_TAGGED is initially mapped as Normal memory and
> - * changed during __cpu_setup to Normal Tagged if the system supports MTE.
> - */
> -#define MAIR_EL1_SET \
> - (MAIR_ATTRIDX(MAIR_ATTR_DEVICE_nGnRnE, MT_DEVICE_nGnRnE) | \
> - MAIR_ATTRIDX(MAIR_ATTR_DEVICE_nGnRE, MT_DEVICE_nGnRE) | \
> - MAIR_ATTRIDX(MAIR_ATTR_DEVICE_GRE, MT_DEVICE_GRE) | \
> - MAIR_ATTRIDX(MAIR_ATTR_NORMAL_NC, MT_NORMAL_NC) | \
> - MAIR_ATTRIDX(MAIR_ATTR_NORMAL, MT_NORMAL) | \
> - MAIR_ATTRIDX(MAIR_ATTR_NORMAL_WT, MT_NORMAL_WT) | \
> - MAIR_ATTRIDX(MAIR_ATTR_NORMAL, MT_NORMAL_TAGGED))
> -
> #ifdef CONFIG_CPU_PM
> /**
> * cpu_do_suspend - save CPU registers context
> @@ -425,7 +412,7 @@ SYM_FUNC_START(__cpu_setup)
> /*
> * Memory region attributes
> */
> - mov_q x5, MAIR_EL1_SET
> + mov_q x5, MAIR_ELx_SET
> #ifdef CONFIG_ARM64_MTE
> /*
> * Update MAIR_EL1, GCR_EL1 and TFSR*_EL1 if MTE is supported
> --
> 2.29.2.454.gaff20da3a2-goog
>
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v3 04/23] arm64: Move MAIR_EL1_SET to asm/memory.h
2020-11-26 17:35 ` Mark Rutland
(?)
@ 2020-12-01 13:58 ` David Brazdil
-1 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-12-01 13:58 UTC (permalink / raw)
To: Mark Rutland
Cc: kvmarm, Jonathan Corbet, Catalin Marinas, Will Deacon,
Marc Zyngier, James Morse, Julien Thierry, Suzuki K Poulose,
Dennis Zhou, Tejun Heo, Christoph Lameter, Lorenzo Pieralisi,
Sudeep Holla, linux-doc, linux-kernel, linux-arm-kernel,
kernel-team
Hey Mark,
> > diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> > index cd61239bae8c..54a22cb5b17b 100644
> > --- a/arch/arm64/include/asm/memory.h
> > +++ b/arch/arm64/include/asm/memory.h
> > @@ -152,6 +152,19 @@
> > #define MT_S2_FWB_NORMAL 6
> > #define MT_S2_FWB_DEVICE_nGnRE 1
> >
> > +/*
> > + * Default MAIR_ELx. MT_NORMAL_TAGGED is initially mapped as Normal memory and
> > + * changed during __cpu_setup to Normal Tagged if the system supports MTE.
> > + */
> > +#define MAIR_ELx_SET \
> > + (MAIR_ATTRIDX(MAIR_ATTR_DEVICE_nGnRnE, MT_DEVICE_nGnRnE) | \
> > + MAIR_ATTRIDX(MAIR_ATTR_DEVICE_nGnRE, MT_DEVICE_nGnRE) | \
> > + MAIR_ATTRIDX(MAIR_ATTR_DEVICE_GRE, MT_DEVICE_GRE) | \
> > + MAIR_ATTRIDX(MAIR_ATTR_NORMAL_NC, MT_NORMAL_NC) | \
> > + MAIR_ATTRIDX(MAIR_ATTR_NORMAL, MT_NORMAL) | \
> > + MAIR_ATTRIDX(MAIR_ATTR_NORMAL_WT, MT_NORMAL_WT) | \
> > + MAIR_ATTRIDX(MAIR_ATTR_NORMAL, MT_NORMAL_TAGGED))
>
> Patch 7 initializes MAIR_EL2 with this directly rather than copying it
> from MAIR_EL1, which means that MT_NORMAL_TAGGED will never be tagged
> within the nVHE hyp code.
>
> Is that expected? I suspect it's worth a comment here (introduced in
> patch 7), just to make that clear.
Ouch, that didn't use to be there. In that case let's not build more implicit
assumptions into the code. I'll pass MAIR_EL1 in kvm_nvhe_init_params.
David
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v3 04/23] arm64: Move MAIR_EL1_SET to asm/memory.h
@ 2020-12-01 13:58 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-12-01 13:58 UTC (permalink / raw)
To: Mark Rutland
Cc: Lorenzo Pieralisi, kernel-team, Jonathan Corbet, Catalin Marinas,
Suzuki K Poulose, linux-doc, linux-kernel, Sudeep Holla,
James Morse, linux-arm-kernel, Marc Zyngier, Tejun Heo,
Dennis Zhou, Christoph Lameter, Will Deacon, kvmarm,
Julien Thierry
Hey Mark,
> > diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> > index cd61239bae8c..54a22cb5b17b 100644
> > --- a/arch/arm64/include/asm/memory.h
> > +++ b/arch/arm64/include/asm/memory.h
> > @@ -152,6 +152,19 @@
> > #define MT_S2_FWB_NORMAL 6
> > #define MT_S2_FWB_DEVICE_nGnRE 1
> >
> > +/*
> > + * Default MAIR_ELx. MT_NORMAL_TAGGED is initially mapped as Normal memory and
> > + * changed during __cpu_setup to Normal Tagged if the system supports MTE.
> > + */
> > +#define MAIR_ELx_SET \
> > + (MAIR_ATTRIDX(MAIR_ATTR_DEVICE_nGnRnE, MT_DEVICE_nGnRnE) | \
> > + MAIR_ATTRIDX(MAIR_ATTR_DEVICE_nGnRE, MT_DEVICE_nGnRE) | \
> > + MAIR_ATTRIDX(MAIR_ATTR_DEVICE_GRE, MT_DEVICE_GRE) | \
> > + MAIR_ATTRIDX(MAIR_ATTR_NORMAL_NC, MT_NORMAL_NC) | \
> > + MAIR_ATTRIDX(MAIR_ATTR_NORMAL, MT_NORMAL) | \
> > + MAIR_ATTRIDX(MAIR_ATTR_NORMAL_WT, MT_NORMAL_WT) | \
> > + MAIR_ATTRIDX(MAIR_ATTR_NORMAL, MT_NORMAL_TAGGED))
>
> Patch 7 initializes MAIR_EL2 with this directly rather than copying it
> from MAIR_EL1, which means that MT_NORMAL_TAGGED will never be tagged
> within the nVHE hyp code.
>
> Is that expected? I suspect it's worth a comment here (introduced in
> patch 7), just to make that clear.
Ouch, that didn't use to be there. In that case let's not build more implicit
assumptions into the code. I'll pass MAIR_EL1 in kvm_nvhe_init_params.
David
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v3 04/23] arm64: Move MAIR_EL1_SET to asm/memory.h
@ 2020-12-01 13:58 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-12-01 13:58 UTC (permalink / raw)
To: Mark Rutland
Cc: Lorenzo Pieralisi, kernel-team, Jonathan Corbet, Catalin Marinas,
linux-doc, linux-kernel, Sudeep Holla, linux-arm-kernel,
Marc Zyngier, Tejun Heo, Dennis Zhou, Christoph Lameter,
Will Deacon, kvmarm
Hey Mark,
> > diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> > index cd61239bae8c..54a22cb5b17b 100644
> > --- a/arch/arm64/include/asm/memory.h
> > +++ b/arch/arm64/include/asm/memory.h
> > @@ -152,6 +152,19 @@
> > #define MT_S2_FWB_NORMAL 6
> > #define MT_S2_FWB_DEVICE_nGnRE 1
> >
> > +/*
> > + * Default MAIR_ELx. MT_NORMAL_TAGGED is initially mapped as Normal memory and
> > + * changed during __cpu_setup to Normal Tagged if the system supports MTE.
> > + */
> > +#define MAIR_ELx_SET \
> > + (MAIR_ATTRIDX(MAIR_ATTR_DEVICE_nGnRnE, MT_DEVICE_nGnRnE) | \
> > + MAIR_ATTRIDX(MAIR_ATTR_DEVICE_nGnRE, MT_DEVICE_nGnRE) | \
> > + MAIR_ATTRIDX(MAIR_ATTR_DEVICE_GRE, MT_DEVICE_GRE) | \
> > + MAIR_ATTRIDX(MAIR_ATTR_NORMAL_NC, MT_NORMAL_NC) | \
> > + MAIR_ATTRIDX(MAIR_ATTR_NORMAL, MT_NORMAL) | \
> > + MAIR_ATTRIDX(MAIR_ATTR_NORMAL_WT, MT_NORMAL_WT) | \
> > + MAIR_ATTRIDX(MAIR_ATTR_NORMAL, MT_NORMAL_TAGGED))
>
> Patch 7 initializes MAIR_EL2 with this directly rather than copying it
> from MAIR_EL1, which means that MT_NORMAL_TAGGED will never be tagged
> within the nVHE hyp code.
>
> Is that expected? I suspect it's worth a comment here (introduced in
> patch 7), just to make that clear.
Ouch, that didn't use to be there. In that case let's not build more implicit
assumptions into the code. I'll pass MAIR_EL1 in kvm_nvhe_init_params.
David
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v3 05/23] arm64: Extract parts of el2_setup into a macro
2020-11-26 15:53 ` David Brazdil
(?)
@ 2020-11-26 15:54 ` David Brazdil
-1 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Jonathan Corbet, Catalin Marinas, Will Deacon, Marc Zyngier,
James Morse, Julien Thierry, Suzuki K Poulose, Dennis Zhou,
Tejun Heo, Christoph Lameter, Mark Rutland, Lorenzo Pieralisi,
Sudeep Holla, linux-doc, linux-kernel, linux-arm-kernel,
kernel-team, David Brazdil
When the a CPU is booted in EL2, the kernel checks for VHE support and
initializes the CPU core accordingly. For nVHE it also installs the stub
vectors and drops down to EL1.
Once KVM gains the ability to boot cores without going through the
kernel entry point, it will need to initialize the CPU the same way.
Extract the relevant bits of el2_setup into an init_el2_state macro
with an argument specifying whether to initialize for VHE or nVHE.
No functional change. Size of el2_setup increased by 148 bytes due
to duplication.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
arch/arm64/include/asm/el2_setup.h | 182 +++++++++++++++++++++++++++++
arch/arm64/kernel/head.S | 144 +++--------------------
2 files changed, 198 insertions(+), 128 deletions(-)
create mode 100644 arch/arm64/include/asm/el2_setup.h
diff --git a/arch/arm64/include/asm/el2_setup.h b/arch/arm64/include/asm/el2_setup.h
new file mode 100644
index 000000000000..b6cfd8aa2a81
--- /dev/null
+++ b/arch/arm64/include/asm/el2_setup.h
@@ -0,0 +1,182 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2012,2013 - ARM Ltd
+ * Author: Marc Zyngier <marc.zyngier@arm.com>
+ */
+
+#ifndef __ARM_KVM_INIT_H__
+#define __ARM_KVM_INIT_H__
+
+#ifndef __ASSEMBLY__
+#error Assembly-only header
+#endif
+
+#include <asm/kvm_arm.h>
+#include <asm/ptrace.h>
+#include <asm/sysreg.h>
+#include <linux/irqchip/arm-gic-v3.h>
+
+.macro __init_el2_sctlr
+ mov_q x0, (SCTLR_EL2_RES1 | ENDIAN_SET_EL2)
+ msr sctlr_el2, x0
+ isb
+.endm
+
+/*
+ * Allow Non-secure EL1 and EL0 to access physical timer and counter.
+ * This is not necessary for VHE, since the host kernel runs in EL2,
+ * and EL0 accesses are configured in the later stage of boot process.
+ * Note that when HCR_EL2.E2H == 1, CNTHCTL_EL2 has the same bit layout
+ * as CNTKCTL_EL1, and CNTKCTL_EL1 accessing instructions are redefined
+ * to access CNTHCTL_EL2. This allows the kernel designed to run at EL1
+ * to transparently mess with the EL0 bits via CNTKCTL_EL1 access in
+ * EL2.
+ */
+.macro __init_el2_timers mode
+.ifeqs "\mode", "nvhe"
+ mrs x0, cnthctl_el2
+ orr x0, x0, #3 // Enable EL1 physical timers
+ msr cnthctl_el2, x0
+.endif
+ msr cntvoff_el2, xzr // Clear virtual offset
+.endm
+
+.macro __init_el2_debug mode
+ mrs x1, id_aa64dfr0_el1
+ sbfx x0, x1, #ID_AA64DFR0_PMUVER_SHIFT, #4
+ cmp x0, #1
+ b.lt 1f // Skip if no PMU present
+ mrs x0, pmcr_el0 // Disable debug access traps
+ ubfx x0, x0, #11, #5 // to EL2 and allow access to
+1:
+ csel x2, xzr, x0, lt // all PMU counters from EL1
+
+ /* Statistical profiling */
+ ubfx x0, x1, #ID_AA64DFR0_PMSVER_SHIFT, #4
+ cbz x0, 3f // Skip if SPE not present
+
+.ifeqs "\mode", "nvhe"
+ mrs_s x0, SYS_PMBIDR_EL1 // If SPE available at EL2,
+ and x0, x0, #(1 << SYS_PMBIDR_EL1_P_SHIFT)
+ cbnz x0, 2f // then permit sampling of physical
+ mov x0, #(1 << SYS_PMSCR_EL2_PCT_SHIFT | \
+ 1 << SYS_PMSCR_EL2_PA_SHIFT)
+ msr_s SYS_PMSCR_EL2, x0 // addresses and physical counter
+2:
+ mov x0, #(MDCR_EL2_E2PB_MASK << MDCR_EL2_E2PB_SHIFT)
+ orr x2, x2, x0 // If we don't have VHE, then
+ // use EL1&0 translation.
+.else
+ orr x2, x2, #MDCR_EL2_TPMS // For VHE, use EL2 translation
+ // and disable access from EL1
+.endif
+
+3:
+ msr mdcr_el2, x2 // Configure debug traps
+.endm
+
+/* LORegions */
+.macro __init_el2_lor
+ mrs x1, id_aa64mmfr1_el1
+ ubfx x0, x1, #ID_AA64MMFR1_LOR_SHIFT, 4
+ cbz x0, 1f
+ msr_s SYS_LORC_EL1, xzr
+1:
+.endm
+
+/* Stage-2 translation */
+.macro __init_el2_stage2
+ msr vttbr_el2, xzr
+.endm
+
+/* GICv3 system register access */
+.macro __init_el2_gicv3
+ mrs x0, id_aa64pfr0_el1
+ ubfx x0, x0, #ID_AA64PFR0_GIC_SHIFT, #4
+ cbz x0, 1f
+
+ mrs_s x0, SYS_ICC_SRE_EL2
+ orr x0, x0, #ICC_SRE_EL2_SRE // Set ICC_SRE_EL2.SRE==1
+ orr x0, x0, #ICC_SRE_EL2_ENABLE // Set ICC_SRE_EL2.Enable==1
+ msr_s SYS_ICC_SRE_EL2, x0
+ isb // Make sure SRE is now set
+ mrs_s x0, SYS_ICC_SRE_EL2 // Read SRE back,
+ tbz x0, #0, 1f // and check that it sticks
+ msr_s SYS_ICH_HCR_EL2, xzr // Reset ICC_HCR_EL2 to defaults
+1:
+.endm
+
+.macro __init_el2_hstr
+ msr hstr_el2, xzr // Disable CP15 traps to EL2
+.endm
+
+/* Virtual CPU ID registers */
+.macro __init_el2_nvhe_idregs
+ mrs x0, midr_el1
+ mrs x1, mpidr_el1
+ msr vpidr_el2, x0
+ msr vmpidr_el2, x1
+.endm
+
+/* Coprocessor traps */
+.macro __init_el2_nvhe_cptr
+ mov x0, #0x33ff
+ msr cptr_el2, x0 // Disable copro. traps to EL2
+.endm
+
+/* SVE register access */
+.macro __init_el2_nvhe_sve
+ mrs x1, id_aa64pfr0_el1
+ ubfx x1, x1, #ID_AA64PFR0_SVE_SHIFT, #4
+ cbz x1, 1f
+
+ bic x0, x0, #CPTR_EL2_TZ // Also disable SVE traps
+ msr cptr_el2, x0 // Disable copro. traps to EL2
+ isb
+ mov x1, #ZCR_ELx_LEN_MASK // SVE: Enable full vector
+ msr_s SYS_ZCR_EL2, x1 // length for EL1.
+1:
+.endm
+
+.macro __init_el2_nvhe_prepare_eret
+ mov x0, #(PSR_F_BIT | PSR_I_BIT | PSR_A_BIT | PSR_D_BIT |\
+ PSR_MODE_EL1h)
+ msr spsr_el2, x0
+.endm
+
+/**
+ * Initialize EL2 registers to sane values. This should be called early on all
+ * cores that were booted in EL2.
+ *
+ * Regs: x0, x1 and x2 are clobbered.
+ */
+.macro init_el2_state mode
+.ifnes "\mode", "vhe"
+.ifnes "\mode", "nvhe"
+.error "Invalid 'mode' argument"
+.endif
+.endif
+
+ __init_el2_sctlr
+ __init_el2_timers \mode
+ __init_el2_debug \mode
+ __init_el2_lor
+ __init_el2_stage2
+ __init_el2_gicv3
+ __init_el2_hstr
+
+ /*
+ * When VHE is not in use, early init of EL2 needs to be done here.
+ * When VHE _is_ in use, EL1 will not be used in the host and
+ * requires no configuration, and all non-hyp-specific EL2 setup
+ * will be done via the _EL1 system register aliases in __cpu_setup.
+ */
+.ifeqs "\mode", "nvhe"
+ __init_el2_nvhe_idregs
+ __init_el2_nvhe_cptr
+ __init_el2_nvhe_sve
+ __init_el2_nvhe_prepare_eret
+.endif
+.endm
+
+#endif /* __ARM_KVM_INIT_H__ */
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index d8d9caf02834..da913ce9e89f 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -11,7 +11,6 @@
#include <linux/linkage.h>
#include <linux/init.h>
-#include <linux/irqchip/arm-gic-v3.h>
#include <linux/pgtable.h>
#include <asm/asm_pointer_auth.h>
@@ -21,6 +20,7 @@
#include <asm/asm-offsets.h>
#include <asm/cache.h>
#include <asm/cputype.h>
+#include <asm/el2_setup.h>
#include <asm/elf.h>
#include <asm/image.h>
#include <asm/kernel-pgtable.h>
@@ -493,159 +493,47 @@ SYM_FUNC_START(el2_setup)
mrs x0, CurrentEL
cmp x0, #CurrentEL_EL2
b.eq 1f
+
mov_q x0, (SCTLR_EL1_RES1 | ENDIAN_SET_EL1)
msr sctlr_el1, x0
mov w0, #BOOT_CPU_MODE_EL1 // This cpu booted in EL1
isb
ret
-1: mov_q x0, (SCTLR_EL2_RES1 | ENDIAN_SET_EL2)
- msr sctlr_el2, x0
-
+1:
#ifdef CONFIG_ARM64_VHE
/*
- * Check for VHE being present. For the rest of the EL2 setup,
- * x2 being non-zero indicates that we do have VHE, and that the
- * kernel is intended to run at EL2.
+ * Check for VHE being present. x2 being non-zero indicates that we
+ * do have VHE, and that the kernel is intended to run at EL2.
*/
mrs x2, id_aa64mmfr1_el1
ubfx x2, x2, #ID_AA64MMFR1_VHE_SHIFT, #4
-#else
- mov x2, xzr
-#endif
+ cbz x2, el2_setup_nvhe
- /* Hyp configuration. */
- mov_q x0, HCR_HOST_NVHE_FLAGS
- cbz x2, set_hcr
mov_q x0, HCR_HOST_VHE_FLAGS
-set_hcr:
msr hcr_el2, x0
isb
- /*
- * Allow Non-secure EL1 and EL0 to access physical timer and counter.
- * This is not necessary for VHE, since the host kernel runs in EL2,
- * and EL0 accesses are configured in the later stage of boot process.
- * Note that when HCR_EL2.E2H == 1, CNTHCTL_EL2 has the same bit layout
- * as CNTKCTL_EL1, and CNTKCTL_EL1 accessing instructions are redefined
- * to access CNTHCTL_EL2. This allows the kernel designed to run at EL1
- * to transparently mess with the EL0 bits via CNTKCTL_EL1 access in
- * EL2.
- */
- cbnz x2, 1f
- mrs x0, cnthctl_el2
- orr x0, x0, #3 // Enable EL1 physical timers
- msr cnthctl_el2, x0
-1:
- msr cntvoff_el2, xzr // Clear virtual offset
-
-#ifdef CONFIG_ARM_GIC_V3
- /* GICv3 system register access */
- mrs x0, id_aa64pfr0_el1
- ubfx x0, x0, #ID_AA64PFR0_GIC_SHIFT, #4
- cbz x0, 3f
-
- mrs_s x0, SYS_ICC_SRE_EL2
- orr x0, x0, #ICC_SRE_EL2_SRE // Set ICC_SRE_EL2.SRE==1
- orr x0, x0, #ICC_SRE_EL2_ENABLE // Set ICC_SRE_EL2.Enable==1
- msr_s SYS_ICC_SRE_EL2, x0
- isb // Make sure SRE is now set
- mrs_s x0, SYS_ICC_SRE_EL2 // Read SRE back,
- tbz x0, #0, 3f // and check that it sticks
- msr_s SYS_ICH_HCR_EL2, xzr // Reset ICC_HCR_EL2 to defaults
-
-3:
-#endif
-
- /* Populate ID registers. */
- mrs x0, midr_el1
- mrs x1, mpidr_el1
- msr vpidr_el2, x0
- msr vmpidr_el2, x1
-
-#ifdef CONFIG_COMPAT
- msr hstr_el2, xzr // Disable CP15 traps to EL2
-#endif
-
- /* EL2 debug */
- mrs x1, id_aa64dfr0_el1
- sbfx x0, x1, #ID_AA64DFR0_PMUVER_SHIFT, #4
- cmp x0, #1
- b.lt 4f // Skip if no PMU present
- mrs x0, pmcr_el0 // Disable debug access traps
- ubfx x0, x0, #11, #5 // to EL2 and allow access to
-4:
- csel x3, xzr, x0, lt // all PMU counters from EL1
-
- /* Statistical profiling */
- ubfx x0, x1, #ID_AA64DFR0_PMSVER_SHIFT, #4
- cbz x0, 7f // Skip if SPE not present
- cbnz x2, 6f // VHE?
- mrs_s x4, SYS_PMBIDR_EL1 // If SPE available at EL2,
- and x4, x4, #(1 << SYS_PMBIDR_EL1_P_SHIFT)
- cbnz x4, 5f // then permit sampling of physical
- mov x4, #(1 << SYS_PMSCR_EL2_PCT_SHIFT | \
- 1 << SYS_PMSCR_EL2_PA_SHIFT)
- msr_s SYS_PMSCR_EL2, x4 // addresses and physical counter
-5:
- mov x1, #(MDCR_EL2_E2PB_MASK << MDCR_EL2_E2PB_SHIFT)
- orr x3, x3, x1 // If we don't have VHE, then
- b 7f // use EL1&0 translation.
-6: // For VHE, use EL2 translation
- orr x3, x3, #MDCR_EL2_TPMS // and disable access from EL1
-7:
- msr mdcr_el2, x3 // Configure debug traps
-
- /* LORegions */
- mrs x1, id_aa64mmfr1_el1
- ubfx x0, x1, #ID_AA64MMFR1_LOR_SHIFT, 4
- cbz x0, 1f
- msr_s SYS_LORC_EL1, xzr
-1:
-
- /* Stage-2 translation */
- msr vttbr_el2, xzr
-
- cbz x2, install_el2_stub
+ init_el2_state vhe
mov w0, #BOOT_CPU_MODE_EL2 // This CPU booted in EL2
isb
ret
+#endif
-SYM_INNER_LABEL(install_el2_stub, SYM_L_LOCAL)
- /*
- * When VHE is not in use, early init of EL2 and EL1 needs to be
- * done here.
- * When VHE _is_ in use, EL1 will not be used in the host and
- * requires no configuration, and all non-hyp-specific EL2 setup
- * will be done via the _EL1 system register aliases in __cpu_setup.
- */
- mov_q x0, (SCTLR_EL1_RES1 | ENDIAN_SET_EL1)
- msr sctlr_el1, x0
-
- /* Coprocessor traps. */
- mov x0, #0x33ff
- msr cptr_el2, x0 // Disable copro. traps to EL2
-
- /* SVE register access */
- mrs x1, id_aa64pfr0_el1
- ubfx x1, x1, #ID_AA64PFR0_SVE_SHIFT, #4
- cbz x1, 7f
-
- bic x0, x0, #CPTR_EL2_TZ // Also disable SVE traps
- msr cptr_el2, x0 // Disable copro. traps to EL2
+SYM_INNER_LABEL(el2_setup_nvhe, SYM_L_LOCAL)
+ mov_q x0, HCR_HOST_NVHE_FLAGS
+ msr hcr_el2, x0
isb
- mov x1, #ZCR_ELx_LEN_MASK // SVE: Enable full vector
- msr_s SYS_ZCR_EL2, x1 // length for EL1.
+
+ init_el2_state nvhe
/* Hypervisor stub */
-7: adr_l x0, __hyp_stub_vectors
+ adr_l x0, __hyp_stub_vectors
msr vbar_el2, x0
- /* spsr */
- mov x0, #(PSR_F_BIT | PSR_I_BIT | PSR_A_BIT | PSR_D_BIT |\
- PSR_MODE_EL1h)
- msr spsr_el2, x0
+ mov_q x0, (SCTLR_EL1_RES1 | ENDIAN_SET_EL1)
+ msr sctlr_el1, x0
msr elr_el2, lr
mov w0, #BOOT_CPU_MODE_EL2 // This CPU booted in EL2
eret
--
2.29.2.454.gaff20da3a2-goog
^ permalink raw reply related [flat|nested] 147+ messages in thread
* [PATCH v3 05/23] arm64: Extract parts of el2_setup into a macro
@ 2020-11-26 15:54 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Mark Rutland, Lorenzo Pieralisi, kernel-team, Jonathan Corbet,
Catalin Marinas, Suzuki K Poulose, linux-doc, linux-kernel,
Sudeep Holla, James Morse, linux-arm-kernel, Marc Zyngier,
Tejun Heo, Dennis Zhou, Christoph Lameter, David Brazdil,
Will Deacon, Julien Thierry
When the a CPU is booted in EL2, the kernel checks for VHE support and
initializes the CPU core accordingly. For nVHE it also installs the stub
vectors and drops down to EL1.
Once KVM gains the ability to boot cores without going through the
kernel entry point, it will need to initialize the CPU the same way.
Extract the relevant bits of el2_setup into an init_el2_state macro
with an argument specifying whether to initialize for VHE or nVHE.
No functional change. Size of el2_setup increased by 148 bytes due
to duplication.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
arch/arm64/include/asm/el2_setup.h | 182 +++++++++++++++++++++++++++++
arch/arm64/kernel/head.S | 144 +++--------------------
2 files changed, 198 insertions(+), 128 deletions(-)
create mode 100644 arch/arm64/include/asm/el2_setup.h
diff --git a/arch/arm64/include/asm/el2_setup.h b/arch/arm64/include/asm/el2_setup.h
new file mode 100644
index 000000000000..b6cfd8aa2a81
--- /dev/null
+++ b/arch/arm64/include/asm/el2_setup.h
@@ -0,0 +1,182 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2012,2013 - ARM Ltd
+ * Author: Marc Zyngier <marc.zyngier@arm.com>
+ */
+
+#ifndef __ARM_KVM_INIT_H__
+#define __ARM_KVM_INIT_H__
+
+#ifndef __ASSEMBLY__
+#error Assembly-only header
+#endif
+
+#include <asm/kvm_arm.h>
+#include <asm/ptrace.h>
+#include <asm/sysreg.h>
+#include <linux/irqchip/arm-gic-v3.h>
+
+.macro __init_el2_sctlr
+ mov_q x0, (SCTLR_EL2_RES1 | ENDIAN_SET_EL2)
+ msr sctlr_el2, x0
+ isb
+.endm
+
+/*
+ * Allow Non-secure EL1 and EL0 to access physical timer and counter.
+ * This is not necessary for VHE, since the host kernel runs in EL2,
+ * and EL0 accesses are configured in the later stage of boot process.
+ * Note that when HCR_EL2.E2H == 1, CNTHCTL_EL2 has the same bit layout
+ * as CNTKCTL_EL1, and CNTKCTL_EL1 accessing instructions are redefined
+ * to access CNTHCTL_EL2. This allows the kernel designed to run at EL1
+ * to transparently mess with the EL0 bits via CNTKCTL_EL1 access in
+ * EL2.
+ */
+.macro __init_el2_timers mode
+.ifeqs "\mode", "nvhe"
+ mrs x0, cnthctl_el2
+ orr x0, x0, #3 // Enable EL1 physical timers
+ msr cnthctl_el2, x0
+.endif
+ msr cntvoff_el2, xzr // Clear virtual offset
+.endm
+
+.macro __init_el2_debug mode
+ mrs x1, id_aa64dfr0_el1
+ sbfx x0, x1, #ID_AA64DFR0_PMUVER_SHIFT, #4
+ cmp x0, #1
+ b.lt 1f // Skip if no PMU present
+ mrs x0, pmcr_el0 // Disable debug access traps
+ ubfx x0, x0, #11, #5 // to EL2 and allow access to
+1:
+ csel x2, xzr, x0, lt // all PMU counters from EL1
+
+ /* Statistical profiling */
+ ubfx x0, x1, #ID_AA64DFR0_PMSVER_SHIFT, #4
+ cbz x0, 3f // Skip if SPE not present
+
+.ifeqs "\mode", "nvhe"
+ mrs_s x0, SYS_PMBIDR_EL1 // If SPE available at EL2,
+ and x0, x0, #(1 << SYS_PMBIDR_EL1_P_SHIFT)
+ cbnz x0, 2f // then permit sampling of physical
+ mov x0, #(1 << SYS_PMSCR_EL2_PCT_SHIFT | \
+ 1 << SYS_PMSCR_EL2_PA_SHIFT)
+ msr_s SYS_PMSCR_EL2, x0 // addresses and physical counter
+2:
+ mov x0, #(MDCR_EL2_E2PB_MASK << MDCR_EL2_E2PB_SHIFT)
+ orr x2, x2, x0 // If we don't have VHE, then
+ // use EL1&0 translation.
+.else
+ orr x2, x2, #MDCR_EL2_TPMS // For VHE, use EL2 translation
+ // and disable access from EL1
+.endif
+
+3:
+ msr mdcr_el2, x2 // Configure debug traps
+.endm
+
+/* LORegions */
+.macro __init_el2_lor
+ mrs x1, id_aa64mmfr1_el1
+ ubfx x0, x1, #ID_AA64MMFR1_LOR_SHIFT, 4
+ cbz x0, 1f
+ msr_s SYS_LORC_EL1, xzr
+1:
+.endm
+
+/* Stage-2 translation */
+.macro __init_el2_stage2
+ msr vttbr_el2, xzr
+.endm
+
+/* GICv3 system register access */
+.macro __init_el2_gicv3
+ mrs x0, id_aa64pfr0_el1
+ ubfx x0, x0, #ID_AA64PFR0_GIC_SHIFT, #4
+ cbz x0, 1f
+
+ mrs_s x0, SYS_ICC_SRE_EL2
+ orr x0, x0, #ICC_SRE_EL2_SRE // Set ICC_SRE_EL2.SRE==1
+ orr x0, x0, #ICC_SRE_EL2_ENABLE // Set ICC_SRE_EL2.Enable==1
+ msr_s SYS_ICC_SRE_EL2, x0
+ isb // Make sure SRE is now set
+ mrs_s x0, SYS_ICC_SRE_EL2 // Read SRE back,
+ tbz x0, #0, 1f // and check that it sticks
+ msr_s SYS_ICH_HCR_EL2, xzr // Reset ICC_HCR_EL2 to defaults
+1:
+.endm
+
+.macro __init_el2_hstr
+ msr hstr_el2, xzr // Disable CP15 traps to EL2
+.endm
+
+/* Virtual CPU ID registers */
+.macro __init_el2_nvhe_idregs
+ mrs x0, midr_el1
+ mrs x1, mpidr_el1
+ msr vpidr_el2, x0
+ msr vmpidr_el2, x1
+.endm
+
+/* Coprocessor traps */
+.macro __init_el2_nvhe_cptr
+ mov x0, #0x33ff
+ msr cptr_el2, x0 // Disable copro. traps to EL2
+.endm
+
+/* SVE register access */
+.macro __init_el2_nvhe_sve
+ mrs x1, id_aa64pfr0_el1
+ ubfx x1, x1, #ID_AA64PFR0_SVE_SHIFT, #4
+ cbz x1, 1f
+
+ bic x0, x0, #CPTR_EL2_TZ // Also disable SVE traps
+ msr cptr_el2, x0 // Disable copro. traps to EL2
+ isb
+ mov x1, #ZCR_ELx_LEN_MASK // SVE: Enable full vector
+ msr_s SYS_ZCR_EL2, x1 // length for EL1.
+1:
+.endm
+
+.macro __init_el2_nvhe_prepare_eret
+ mov x0, #(PSR_F_BIT | PSR_I_BIT | PSR_A_BIT | PSR_D_BIT |\
+ PSR_MODE_EL1h)
+ msr spsr_el2, x0
+.endm
+
+/**
+ * Initialize EL2 registers to sane values. This should be called early on all
+ * cores that were booted in EL2.
+ *
+ * Regs: x0, x1 and x2 are clobbered.
+ */
+.macro init_el2_state mode
+.ifnes "\mode", "vhe"
+.ifnes "\mode", "nvhe"
+.error "Invalid 'mode' argument"
+.endif
+.endif
+
+ __init_el2_sctlr
+ __init_el2_timers \mode
+ __init_el2_debug \mode
+ __init_el2_lor
+ __init_el2_stage2
+ __init_el2_gicv3
+ __init_el2_hstr
+
+ /*
+ * When VHE is not in use, early init of EL2 needs to be done here.
+ * When VHE _is_ in use, EL1 will not be used in the host and
+ * requires no configuration, and all non-hyp-specific EL2 setup
+ * will be done via the _EL1 system register aliases in __cpu_setup.
+ */
+.ifeqs "\mode", "nvhe"
+ __init_el2_nvhe_idregs
+ __init_el2_nvhe_cptr
+ __init_el2_nvhe_sve
+ __init_el2_nvhe_prepare_eret
+.endif
+.endm
+
+#endif /* __ARM_KVM_INIT_H__ */
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index d8d9caf02834..da913ce9e89f 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -11,7 +11,6 @@
#include <linux/linkage.h>
#include <linux/init.h>
-#include <linux/irqchip/arm-gic-v3.h>
#include <linux/pgtable.h>
#include <asm/asm_pointer_auth.h>
@@ -21,6 +20,7 @@
#include <asm/asm-offsets.h>
#include <asm/cache.h>
#include <asm/cputype.h>
+#include <asm/el2_setup.h>
#include <asm/elf.h>
#include <asm/image.h>
#include <asm/kernel-pgtable.h>
@@ -493,159 +493,47 @@ SYM_FUNC_START(el2_setup)
mrs x0, CurrentEL
cmp x0, #CurrentEL_EL2
b.eq 1f
+
mov_q x0, (SCTLR_EL1_RES1 | ENDIAN_SET_EL1)
msr sctlr_el1, x0
mov w0, #BOOT_CPU_MODE_EL1 // This cpu booted in EL1
isb
ret
-1: mov_q x0, (SCTLR_EL2_RES1 | ENDIAN_SET_EL2)
- msr sctlr_el2, x0
-
+1:
#ifdef CONFIG_ARM64_VHE
/*
- * Check for VHE being present. For the rest of the EL2 setup,
- * x2 being non-zero indicates that we do have VHE, and that the
- * kernel is intended to run at EL2.
+ * Check for VHE being present. x2 being non-zero indicates that we
+ * do have VHE, and that the kernel is intended to run at EL2.
*/
mrs x2, id_aa64mmfr1_el1
ubfx x2, x2, #ID_AA64MMFR1_VHE_SHIFT, #4
-#else
- mov x2, xzr
-#endif
+ cbz x2, el2_setup_nvhe
- /* Hyp configuration. */
- mov_q x0, HCR_HOST_NVHE_FLAGS
- cbz x2, set_hcr
mov_q x0, HCR_HOST_VHE_FLAGS
-set_hcr:
msr hcr_el2, x0
isb
- /*
- * Allow Non-secure EL1 and EL0 to access physical timer and counter.
- * This is not necessary for VHE, since the host kernel runs in EL2,
- * and EL0 accesses are configured in the later stage of boot process.
- * Note that when HCR_EL2.E2H == 1, CNTHCTL_EL2 has the same bit layout
- * as CNTKCTL_EL1, and CNTKCTL_EL1 accessing instructions are redefined
- * to access CNTHCTL_EL2. This allows the kernel designed to run at EL1
- * to transparently mess with the EL0 bits via CNTKCTL_EL1 access in
- * EL2.
- */
- cbnz x2, 1f
- mrs x0, cnthctl_el2
- orr x0, x0, #3 // Enable EL1 physical timers
- msr cnthctl_el2, x0
-1:
- msr cntvoff_el2, xzr // Clear virtual offset
-
-#ifdef CONFIG_ARM_GIC_V3
- /* GICv3 system register access */
- mrs x0, id_aa64pfr0_el1
- ubfx x0, x0, #ID_AA64PFR0_GIC_SHIFT, #4
- cbz x0, 3f
-
- mrs_s x0, SYS_ICC_SRE_EL2
- orr x0, x0, #ICC_SRE_EL2_SRE // Set ICC_SRE_EL2.SRE==1
- orr x0, x0, #ICC_SRE_EL2_ENABLE // Set ICC_SRE_EL2.Enable==1
- msr_s SYS_ICC_SRE_EL2, x0
- isb // Make sure SRE is now set
- mrs_s x0, SYS_ICC_SRE_EL2 // Read SRE back,
- tbz x0, #0, 3f // and check that it sticks
- msr_s SYS_ICH_HCR_EL2, xzr // Reset ICC_HCR_EL2 to defaults
-
-3:
-#endif
-
- /* Populate ID registers. */
- mrs x0, midr_el1
- mrs x1, mpidr_el1
- msr vpidr_el2, x0
- msr vmpidr_el2, x1
-
-#ifdef CONFIG_COMPAT
- msr hstr_el2, xzr // Disable CP15 traps to EL2
-#endif
-
- /* EL2 debug */
- mrs x1, id_aa64dfr0_el1
- sbfx x0, x1, #ID_AA64DFR0_PMUVER_SHIFT, #4
- cmp x0, #1
- b.lt 4f // Skip if no PMU present
- mrs x0, pmcr_el0 // Disable debug access traps
- ubfx x0, x0, #11, #5 // to EL2 and allow access to
-4:
- csel x3, xzr, x0, lt // all PMU counters from EL1
-
- /* Statistical profiling */
- ubfx x0, x1, #ID_AA64DFR0_PMSVER_SHIFT, #4
- cbz x0, 7f // Skip if SPE not present
- cbnz x2, 6f // VHE?
- mrs_s x4, SYS_PMBIDR_EL1 // If SPE available at EL2,
- and x4, x4, #(1 << SYS_PMBIDR_EL1_P_SHIFT)
- cbnz x4, 5f // then permit sampling of physical
- mov x4, #(1 << SYS_PMSCR_EL2_PCT_SHIFT | \
- 1 << SYS_PMSCR_EL2_PA_SHIFT)
- msr_s SYS_PMSCR_EL2, x4 // addresses and physical counter
-5:
- mov x1, #(MDCR_EL2_E2PB_MASK << MDCR_EL2_E2PB_SHIFT)
- orr x3, x3, x1 // If we don't have VHE, then
- b 7f // use EL1&0 translation.
-6: // For VHE, use EL2 translation
- orr x3, x3, #MDCR_EL2_TPMS // and disable access from EL1
-7:
- msr mdcr_el2, x3 // Configure debug traps
-
- /* LORegions */
- mrs x1, id_aa64mmfr1_el1
- ubfx x0, x1, #ID_AA64MMFR1_LOR_SHIFT, 4
- cbz x0, 1f
- msr_s SYS_LORC_EL1, xzr
-1:
-
- /* Stage-2 translation */
- msr vttbr_el2, xzr
-
- cbz x2, install_el2_stub
+ init_el2_state vhe
mov w0, #BOOT_CPU_MODE_EL2 // This CPU booted in EL2
isb
ret
+#endif
-SYM_INNER_LABEL(install_el2_stub, SYM_L_LOCAL)
- /*
- * When VHE is not in use, early init of EL2 and EL1 needs to be
- * done here.
- * When VHE _is_ in use, EL1 will not be used in the host and
- * requires no configuration, and all non-hyp-specific EL2 setup
- * will be done via the _EL1 system register aliases in __cpu_setup.
- */
- mov_q x0, (SCTLR_EL1_RES1 | ENDIAN_SET_EL1)
- msr sctlr_el1, x0
-
- /* Coprocessor traps. */
- mov x0, #0x33ff
- msr cptr_el2, x0 // Disable copro. traps to EL2
-
- /* SVE register access */
- mrs x1, id_aa64pfr0_el1
- ubfx x1, x1, #ID_AA64PFR0_SVE_SHIFT, #4
- cbz x1, 7f
-
- bic x0, x0, #CPTR_EL2_TZ // Also disable SVE traps
- msr cptr_el2, x0 // Disable copro. traps to EL2
+SYM_INNER_LABEL(el2_setup_nvhe, SYM_L_LOCAL)
+ mov_q x0, HCR_HOST_NVHE_FLAGS
+ msr hcr_el2, x0
isb
- mov x1, #ZCR_ELx_LEN_MASK // SVE: Enable full vector
- msr_s SYS_ZCR_EL2, x1 // length for EL1.
+
+ init_el2_state nvhe
/* Hypervisor stub */
-7: adr_l x0, __hyp_stub_vectors
+ adr_l x0, __hyp_stub_vectors
msr vbar_el2, x0
- /* spsr */
- mov x0, #(PSR_F_BIT | PSR_I_BIT | PSR_A_BIT | PSR_D_BIT |\
- PSR_MODE_EL1h)
- msr spsr_el2, x0
+ mov_q x0, (SCTLR_EL1_RES1 | ENDIAN_SET_EL1)
+ msr sctlr_el1, x0
msr elr_el2, lr
mov w0, #BOOT_CPU_MODE_EL2 // This CPU booted in EL2
eret
--
2.29.2.454.gaff20da3a2-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 147+ messages in thread
* [PATCH v3 05/23] arm64: Extract parts of el2_setup into a macro
@ 2020-11-26 15:54 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Lorenzo Pieralisi, kernel-team, Jonathan Corbet, Catalin Marinas,
linux-doc, linux-kernel, Sudeep Holla, linux-arm-kernel,
Marc Zyngier, Tejun Heo, Dennis Zhou, Christoph Lameter,
Will Deacon
When the a CPU is booted in EL2, the kernel checks for VHE support and
initializes the CPU core accordingly. For nVHE it also installs the stub
vectors and drops down to EL1.
Once KVM gains the ability to boot cores without going through the
kernel entry point, it will need to initialize the CPU the same way.
Extract the relevant bits of el2_setup into an init_el2_state macro
with an argument specifying whether to initialize for VHE or nVHE.
No functional change. Size of el2_setup increased by 148 bytes due
to duplication.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
arch/arm64/include/asm/el2_setup.h | 182 +++++++++++++++++++++++++++++
arch/arm64/kernel/head.S | 144 +++--------------------
2 files changed, 198 insertions(+), 128 deletions(-)
create mode 100644 arch/arm64/include/asm/el2_setup.h
diff --git a/arch/arm64/include/asm/el2_setup.h b/arch/arm64/include/asm/el2_setup.h
new file mode 100644
index 000000000000..b6cfd8aa2a81
--- /dev/null
+++ b/arch/arm64/include/asm/el2_setup.h
@@ -0,0 +1,182 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2012,2013 - ARM Ltd
+ * Author: Marc Zyngier <marc.zyngier@arm.com>
+ */
+
+#ifndef __ARM_KVM_INIT_H__
+#define __ARM_KVM_INIT_H__
+
+#ifndef __ASSEMBLY__
+#error Assembly-only header
+#endif
+
+#include <asm/kvm_arm.h>
+#include <asm/ptrace.h>
+#include <asm/sysreg.h>
+#include <linux/irqchip/arm-gic-v3.h>
+
+.macro __init_el2_sctlr
+ mov_q x0, (SCTLR_EL2_RES1 | ENDIAN_SET_EL2)
+ msr sctlr_el2, x0
+ isb
+.endm
+
+/*
+ * Allow Non-secure EL1 and EL0 to access physical timer and counter.
+ * This is not necessary for VHE, since the host kernel runs in EL2,
+ * and EL0 accesses are configured in the later stage of boot process.
+ * Note that when HCR_EL2.E2H == 1, CNTHCTL_EL2 has the same bit layout
+ * as CNTKCTL_EL1, and CNTKCTL_EL1 accessing instructions are redefined
+ * to access CNTHCTL_EL2. This allows the kernel designed to run at EL1
+ * to transparently mess with the EL0 bits via CNTKCTL_EL1 access in
+ * EL2.
+ */
+.macro __init_el2_timers mode
+.ifeqs "\mode", "nvhe"
+ mrs x0, cnthctl_el2
+ orr x0, x0, #3 // Enable EL1 physical timers
+ msr cnthctl_el2, x0
+.endif
+ msr cntvoff_el2, xzr // Clear virtual offset
+.endm
+
+.macro __init_el2_debug mode
+ mrs x1, id_aa64dfr0_el1
+ sbfx x0, x1, #ID_AA64DFR0_PMUVER_SHIFT, #4
+ cmp x0, #1
+ b.lt 1f // Skip if no PMU present
+ mrs x0, pmcr_el0 // Disable debug access traps
+ ubfx x0, x0, #11, #5 // to EL2 and allow access to
+1:
+ csel x2, xzr, x0, lt // all PMU counters from EL1
+
+ /* Statistical profiling */
+ ubfx x0, x1, #ID_AA64DFR0_PMSVER_SHIFT, #4
+ cbz x0, 3f // Skip if SPE not present
+
+.ifeqs "\mode", "nvhe"
+ mrs_s x0, SYS_PMBIDR_EL1 // If SPE available at EL2,
+ and x0, x0, #(1 << SYS_PMBIDR_EL1_P_SHIFT)
+ cbnz x0, 2f // then permit sampling of physical
+ mov x0, #(1 << SYS_PMSCR_EL2_PCT_SHIFT | \
+ 1 << SYS_PMSCR_EL2_PA_SHIFT)
+ msr_s SYS_PMSCR_EL2, x0 // addresses and physical counter
+2:
+ mov x0, #(MDCR_EL2_E2PB_MASK << MDCR_EL2_E2PB_SHIFT)
+ orr x2, x2, x0 // If we don't have VHE, then
+ // use EL1&0 translation.
+.else
+ orr x2, x2, #MDCR_EL2_TPMS // For VHE, use EL2 translation
+ // and disable access from EL1
+.endif
+
+3:
+ msr mdcr_el2, x2 // Configure debug traps
+.endm
+
+/* LORegions */
+.macro __init_el2_lor
+ mrs x1, id_aa64mmfr1_el1
+ ubfx x0, x1, #ID_AA64MMFR1_LOR_SHIFT, 4
+ cbz x0, 1f
+ msr_s SYS_LORC_EL1, xzr
+1:
+.endm
+
+/* Stage-2 translation */
+.macro __init_el2_stage2
+ msr vttbr_el2, xzr
+.endm
+
+/* GICv3 system register access */
+.macro __init_el2_gicv3
+ mrs x0, id_aa64pfr0_el1
+ ubfx x0, x0, #ID_AA64PFR0_GIC_SHIFT, #4
+ cbz x0, 1f
+
+ mrs_s x0, SYS_ICC_SRE_EL2
+ orr x0, x0, #ICC_SRE_EL2_SRE // Set ICC_SRE_EL2.SRE==1
+ orr x0, x0, #ICC_SRE_EL2_ENABLE // Set ICC_SRE_EL2.Enable==1
+ msr_s SYS_ICC_SRE_EL2, x0
+ isb // Make sure SRE is now set
+ mrs_s x0, SYS_ICC_SRE_EL2 // Read SRE back,
+ tbz x0, #0, 1f // and check that it sticks
+ msr_s SYS_ICH_HCR_EL2, xzr // Reset ICC_HCR_EL2 to defaults
+1:
+.endm
+
+.macro __init_el2_hstr
+ msr hstr_el2, xzr // Disable CP15 traps to EL2
+.endm
+
+/* Virtual CPU ID registers */
+.macro __init_el2_nvhe_idregs
+ mrs x0, midr_el1
+ mrs x1, mpidr_el1
+ msr vpidr_el2, x0
+ msr vmpidr_el2, x1
+.endm
+
+/* Coprocessor traps */
+.macro __init_el2_nvhe_cptr
+ mov x0, #0x33ff
+ msr cptr_el2, x0 // Disable copro. traps to EL2
+.endm
+
+/* SVE register access */
+.macro __init_el2_nvhe_sve
+ mrs x1, id_aa64pfr0_el1
+ ubfx x1, x1, #ID_AA64PFR0_SVE_SHIFT, #4
+ cbz x1, 1f
+
+ bic x0, x0, #CPTR_EL2_TZ // Also disable SVE traps
+ msr cptr_el2, x0 // Disable copro. traps to EL2
+ isb
+ mov x1, #ZCR_ELx_LEN_MASK // SVE: Enable full vector
+ msr_s SYS_ZCR_EL2, x1 // length for EL1.
+1:
+.endm
+
+.macro __init_el2_nvhe_prepare_eret
+ mov x0, #(PSR_F_BIT | PSR_I_BIT | PSR_A_BIT | PSR_D_BIT |\
+ PSR_MODE_EL1h)
+ msr spsr_el2, x0
+.endm
+
+/**
+ * Initialize EL2 registers to sane values. This should be called early on all
+ * cores that were booted in EL2.
+ *
+ * Regs: x0, x1 and x2 are clobbered.
+ */
+.macro init_el2_state mode
+.ifnes "\mode", "vhe"
+.ifnes "\mode", "nvhe"
+.error "Invalid 'mode' argument"
+.endif
+.endif
+
+ __init_el2_sctlr
+ __init_el2_timers \mode
+ __init_el2_debug \mode
+ __init_el2_lor
+ __init_el2_stage2
+ __init_el2_gicv3
+ __init_el2_hstr
+
+ /*
+ * When VHE is not in use, early init of EL2 needs to be done here.
+ * When VHE _is_ in use, EL1 will not be used in the host and
+ * requires no configuration, and all non-hyp-specific EL2 setup
+ * will be done via the _EL1 system register aliases in __cpu_setup.
+ */
+.ifeqs "\mode", "nvhe"
+ __init_el2_nvhe_idregs
+ __init_el2_nvhe_cptr
+ __init_el2_nvhe_sve
+ __init_el2_nvhe_prepare_eret
+.endif
+.endm
+
+#endif /* __ARM_KVM_INIT_H__ */
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index d8d9caf02834..da913ce9e89f 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -11,7 +11,6 @@
#include <linux/linkage.h>
#include <linux/init.h>
-#include <linux/irqchip/arm-gic-v3.h>
#include <linux/pgtable.h>
#include <asm/asm_pointer_auth.h>
@@ -21,6 +20,7 @@
#include <asm/asm-offsets.h>
#include <asm/cache.h>
#include <asm/cputype.h>
+#include <asm/el2_setup.h>
#include <asm/elf.h>
#include <asm/image.h>
#include <asm/kernel-pgtable.h>
@@ -493,159 +493,47 @@ SYM_FUNC_START(el2_setup)
mrs x0, CurrentEL
cmp x0, #CurrentEL_EL2
b.eq 1f
+
mov_q x0, (SCTLR_EL1_RES1 | ENDIAN_SET_EL1)
msr sctlr_el1, x0
mov w0, #BOOT_CPU_MODE_EL1 // This cpu booted in EL1
isb
ret
-1: mov_q x0, (SCTLR_EL2_RES1 | ENDIAN_SET_EL2)
- msr sctlr_el2, x0
-
+1:
#ifdef CONFIG_ARM64_VHE
/*
- * Check for VHE being present. For the rest of the EL2 setup,
- * x2 being non-zero indicates that we do have VHE, and that the
- * kernel is intended to run at EL2.
+ * Check for VHE being present. x2 being non-zero indicates that we
+ * do have VHE, and that the kernel is intended to run at EL2.
*/
mrs x2, id_aa64mmfr1_el1
ubfx x2, x2, #ID_AA64MMFR1_VHE_SHIFT, #4
-#else
- mov x2, xzr
-#endif
+ cbz x2, el2_setup_nvhe
- /* Hyp configuration. */
- mov_q x0, HCR_HOST_NVHE_FLAGS
- cbz x2, set_hcr
mov_q x0, HCR_HOST_VHE_FLAGS
-set_hcr:
msr hcr_el2, x0
isb
- /*
- * Allow Non-secure EL1 and EL0 to access physical timer and counter.
- * This is not necessary for VHE, since the host kernel runs in EL2,
- * and EL0 accesses are configured in the later stage of boot process.
- * Note that when HCR_EL2.E2H == 1, CNTHCTL_EL2 has the same bit layout
- * as CNTKCTL_EL1, and CNTKCTL_EL1 accessing instructions are redefined
- * to access CNTHCTL_EL2. This allows the kernel designed to run at EL1
- * to transparently mess with the EL0 bits via CNTKCTL_EL1 access in
- * EL2.
- */
- cbnz x2, 1f
- mrs x0, cnthctl_el2
- orr x0, x0, #3 // Enable EL1 physical timers
- msr cnthctl_el2, x0
-1:
- msr cntvoff_el2, xzr // Clear virtual offset
-
-#ifdef CONFIG_ARM_GIC_V3
- /* GICv3 system register access */
- mrs x0, id_aa64pfr0_el1
- ubfx x0, x0, #ID_AA64PFR0_GIC_SHIFT, #4
- cbz x0, 3f
-
- mrs_s x0, SYS_ICC_SRE_EL2
- orr x0, x0, #ICC_SRE_EL2_SRE // Set ICC_SRE_EL2.SRE==1
- orr x0, x0, #ICC_SRE_EL2_ENABLE // Set ICC_SRE_EL2.Enable==1
- msr_s SYS_ICC_SRE_EL2, x0
- isb // Make sure SRE is now set
- mrs_s x0, SYS_ICC_SRE_EL2 // Read SRE back,
- tbz x0, #0, 3f // and check that it sticks
- msr_s SYS_ICH_HCR_EL2, xzr // Reset ICC_HCR_EL2 to defaults
-
-3:
-#endif
-
- /* Populate ID registers. */
- mrs x0, midr_el1
- mrs x1, mpidr_el1
- msr vpidr_el2, x0
- msr vmpidr_el2, x1
-
-#ifdef CONFIG_COMPAT
- msr hstr_el2, xzr // Disable CP15 traps to EL2
-#endif
-
- /* EL2 debug */
- mrs x1, id_aa64dfr0_el1
- sbfx x0, x1, #ID_AA64DFR0_PMUVER_SHIFT, #4
- cmp x0, #1
- b.lt 4f // Skip if no PMU present
- mrs x0, pmcr_el0 // Disable debug access traps
- ubfx x0, x0, #11, #5 // to EL2 and allow access to
-4:
- csel x3, xzr, x0, lt // all PMU counters from EL1
-
- /* Statistical profiling */
- ubfx x0, x1, #ID_AA64DFR0_PMSVER_SHIFT, #4
- cbz x0, 7f // Skip if SPE not present
- cbnz x2, 6f // VHE?
- mrs_s x4, SYS_PMBIDR_EL1 // If SPE available at EL2,
- and x4, x4, #(1 << SYS_PMBIDR_EL1_P_SHIFT)
- cbnz x4, 5f // then permit sampling of physical
- mov x4, #(1 << SYS_PMSCR_EL2_PCT_SHIFT | \
- 1 << SYS_PMSCR_EL2_PA_SHIFT)
- msr_s SYS_PMSCR_EL2, x4 // addresses and physical counter
-5:
- mov x1, #(MDCR_EL2_E2PB_MASK << MDCR_EL2_E2PB_SHIFT)
- orr x3, x3, x1 // If we don't have VHE, then
- b 7f // use EL1&0 translation.
-6: // For VHE, use EL2 translation
- orr x3, x3, #MDCR_EL2_TPMS // and disable access from EL1
-7:
- msr mdcr_el2, x3 // Configure debug traps
-
- /* LORegions */
- mrs x1, id_aa64mmfr1_el1
- ubfx x0, x1, #ID_AA64MMFR1_LOR_SHIFT, 4
- cbz x0, 1f
- msr_s SYS_LORC_EL1, xzr
-1:
-
- /* Stage-2 translation */
- msr vttbr_el2, xzr
-
- cbz x2, install_el2_stub
+ init_el2_state vhe
mov w0, #BOOT_CPU_MODE_EL2 // This CPU booted in EL2
isb
ret
+#endif
-SYM_INNER_LABEL(install_el2_stub, SYM_L_LOCAL)
- /*
- * When VHE is not in use, early init of EL2 and EL1 needs to be
- * done here.
- * When VHE _is_ in use, EL1 will not be used in the host and
- * requires no configuration, and all non-hyp-specific EL2 setup
- * will be done via the _EL1 system register aliases in __cpu_setup.
- */
- mov_q x0, (SCTLR_EL1_RES1 | ENDIAN_SET_EL1)
- msr sctlr_el1, x0
-
- /* Coprocessor traps. */
- mov x0, #0x33ff
- msr cptr_el2, x0 // Disable copro. traps to EL2
-
- /* SVE register access */
- mrs x1, id_aa64pfr0_el1
- ubfx x1, x1, #ID_AA64PFR0_SVE_SHIFT, #4
- cbz x1, 7f
-
- bic x0, x0, #CPTR_EL2_TZ // Also disable SVE traps
- msr cptr_el2, x0 // Disable copro. traps to EL2
+SYM_INNER_LABEL(el2_setup_nvhe, SYM_L_LOCAL)
+ mov_q x0, HCR_HOST_NVHE_FLAGS
+ msr hcr_el2, x0
isb
- mov x1, #ZCR_ELx_LEN_MASK // SVE: Enable full vector
- msr_s SYS_ZCR_EL2, x1 // length for EL1.
+
+ init_el2_state nvhe
/* Hypervisor stub */
-7: adr_l x0, __hyp_stub_vectors
+ adr_l x0, __hyp_stub_vectors
msr vbar_el2, x0
- /* spsr */
- mov x0, #(PSR_F_BIT | PSR_I_BIT | PSR_A_BIT | PSR_D_BIT |\
- PSR_MODE_EL1h)
- msr spsr_el2, x0
+ mov_q x0, (SCTLR_EL1_RES1 | ENDIAN_SET_EL1)
+ msr sctlr_el1, x0
msr elr_el2, lr
mov w0, #BOOT_CPU_MODE_EL2 // This CPU booted in EL2
eret
--
2.29.2.454.gaff20da3a2-goog
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply related [flat|nested] 147+ messages in thread
* Re: [PATCH v3 05/23] arm64: Extract parts of el2_setup into a macro
2020-11-26 15:54 ` David Brazdil
(?)
@ 2020-11-26 18:06 ` Mark Rutland
-1 siblings, 0 replies; 147+ messages in thread
From: Mark Rutland @ 2020-11-26 18:06 UTC (permalink / raw)
To: David Brazdil
Cc: kvmarm, Jonathan Corbet, Catalin Marinas, Will Deacon,
Marc Zyngier, James Morse, Julien Thierry, Suzuki K Poulose,
Dennis Zhou, Tejun Heo, Christoph Lameter, Lorenzo Pieralisi,
Sudeep Holla, linux-doc, linux-kernel, linux-arm-kernel,
kernel-team
On Thu, Nov 26, 2020 at 03:54:03PM +0000, David Brazdil wrote:
> When the a CPU is booted in EL2, the kernel checks for VHE support and
> initializes the CPU core accordingly. For nVHE it also installs the stub
> vectors and drops down to EL1.
>
> Once KVM gains the ability to boot cores without going through the
> kernel entry point, it will need to initialize the CPU the same way.
> Extract the relevant bits of el2_setup into an init_el2_state macro
> with an argument specifying whether to initialize for VHE or nVHE.
>
> No functional change. Size of el2_setup increased by 148 bytes due
> to duplication.
As a heads-up, this will conflict with my rework which is queued in the
arm64 for-next/uaccess branch. I reworked an renamed el2_setup to
initialize SCTLR_ELx and PSTATE more consistently as a prerequisite for
the set_fs() removal.
I'm afraid this is going to conflict, and I reckon this needs to be
rebased atop that. I think the actual conflicts are logically trivial,
but the diff is going to be painful.
I'm certainly in favour of breaking this down into manageable chunks,
especially as that makes the branch naming easier to follow, but I have
a couple of concerns below.
> +/* GICv3 system register access */
> +.macro __init_el2_gicv3
> + mrs x0, id_aa64pfr0_el1
> + ubfx x0, x0, #ID_AA64PFR0_GIC_SHIFT, #4
> + cbz x0, 1f
> +
> + mrs_s x0, SYS_ICC_SRE_EL2
> + orr x0, x0, #ICC_SRE_EL2_SRE // Set ICC_SRE_EL2.SRE==1
> + orr x0, x0, #ICC_SRE_EL2_ENABLE // Set ICC_SRE_EL2.Enable==1
> + msr_s SYS_ICC_SRE_EL2, x0
> + isb // Make sure SRE is now set
> + mrs_s x0, SYS_ICC_SRE_EL2 // Read SRE back,
> + tbz x0, #0, 1f // and check that it sticks
> + msr_s SYS_ICH_HCR_EL2, xzr // Reset ICC_HCR_EL2 to defaults
> +1:
> +.endm
In the head.S code, this was under an ifdef CONFIG_ARM_GIC_V3, but that
ifdef wasn't carried into the macro here, or into its use below. I'm not
sure of the impact, but that does seem to be a functional change.
> +
> +.macro __init_el2_hstr
> + msr hstr_el2, xzr // Disable CP15 traps to EL2
> +.endm
Likewise, this used to be be guarded by CONFIG_COMPAT, but that's not
carried into the macro or its use.
If the intent was to remove the conditionality, then that should be
mentioned in the commit message, since it is a potential functional
change.
Thanks,
Mark.
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v3 05/23] arm64: Extract parts of el2_setup into a macro
@ 2020-11-26 18:06 ` Mark Rutland
0 siblings, 0 replies; 147+ messages in thread
From: Mark Rutland @ 2020-11-26 18:06 UTC (permalink / raw)
To: David Brazdil
Cc: Lorenzo Pieralisi, kernel-team, Jonathan Corbet, Catalin Marinas,
Suzuki K Poulose, linux-doc, linux-kernel, Sudeep Holla,
James Morse, linux-arm-kernel, Marc Zyngier, Tejun Heo,
Dennis Zhou, Christoph Lameter, Will Deacon, kvmarm,
Julien Thierry
On Thu, Nov 26, 2020 at 03:54:03PM +0000, David Brazdil wrote:
> When the a CPU is booted in EL2, the kernel checks for VHE support and
> initializes the CPU core accordingly. For nVHE it also installs the stub
> vectors and drops down to EL1.
>
> Once KVM gains the ability to boot cores without going through the
> kernel entry point, it will need to initialize the CPU the same way.
> Extract the relevant bits of el2_setup into an init_el2_state macro
> with an argument specifying whether to initialize for VHE or nVHE.
>
> No functional change. Size of el2_setup increased by 148 bytes due
> to duplication.
As a heads-up, this will conflict with my rework which is queued in the
arm64 for-next/uaccess branch. I reworked an renamed el2_setup to
initialize SCTLR_ELx and PSTATE more consistently as a prerequisite for
the set_fs() removal.
I'm afraid this is going to conflict, and I reckon this needs to be
rebased atop that. I think the actual conflicts are logically trivial,
but the diff is going to be painful.
I'm certainly in favour of breaking this down into manageable chunks,
especially as that makes the branch naming easier to follow, but I have
a couple of concerns below.
> +/* GICv3 system register access */
> +.macro __init_el2_gicv3
> + mrs x0, id_aa64pfr0_el1
> + ubfx x0, x0, #ID_AA64PFR0_GIC_SHIFT, #4
> + cbz x0, 1f
> +
> + mrs_s x0, SYS_ICC_SRE_EL2
> + orr x0, x0, #ICC_SRE_EL2_SRE // Set ICC_SRE_EL2.SRE==1
> + orr x0, x0, #ICC_SRE_EL2_ENABLE // Set ICC_SRE_EL2.Enable==1
> + msr_s SYS_ICC_SRE_EL2, x0
> + isb // Make sure SRE is now set
> + mrs_s x0, SYS_ICC_SRE_EL2 // Read SRE back,
> + tbz x0, #0, 1f // and check that it sticks
> + msr_s SYS_ICH_HCR_EL2, xzr // Reset ICC_HCR_EL2 to defaults
> +1:
> +.endm
In the head.S code, this was under an ifdef CONFIG_ARM_GIC_V3, but that
ifdef wasn't carried into the macro here, or into its use below. I'm not
sure of the impact, but that does seem to be a functional change.
> +
> +.macro __init_el2_hstr
> + msr hstr_el2, xzr // Disable CP15 traps to EL2
> +.endm
Likewise, this used to be be guarded by CONFIG_COMPAT, but that's not
carried into the macro or its use.
If the intent was to remove the conditionality, then that should be
mentioned in the commit message, since it is a potential functional
change.
Thanks,
Mark.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v3 05/23] arm64: Extract parts of el2_setup into a macro
@ 2020-11-26 18:06 ` Mark Rutland
0 siblings, 0 replies; 147+ messages in thread
From: Mark Rutland @ 2020-11-26 18:06 UTC (permalink / raw)
To: David Brazdil
Cc: Lorenzo Pieralisi, kernel-team, Jonathan Corbet, Catalin Marinas,
linux-doc, linux-kernel, Sudeep Holla, linux-arm-kernel,
Marc Zyngier, Tejun Heo, Dennis Zhou, Christoph Lameter,
Will Deacon, kvmarm
On Thu, Nov 26, 2020 at 03:54:03PM +0000, David Brazdil wrote:
> When the a CPU is booted in EL2, the kernel checks for VHE support and
> initializes the CPU core accordingly. For nVHE it also installs the stub
> vectors and drops down to EL1.
>
> Once KVM gains the ability to boot cores without going through the
> kernel entry point, it will need to initialize the CPU the same way.
> Extract the relevant bits of el2_setup into an init_el2_state macro
> with an argument specifying whether to initialize for VHE or nVHE.
>
> No functional change. Size of el2_setup increased by 148 bytes due
> to duplication.
As a heads-up, this will conflict with my rework which is queued in the
arm64 for-next/uaccess branch. I reworked an renamed el2_setup to
initialize SCTLR_ELx and PSTATE more consistently as a prerequisite for
the set_fs() removal.
I'm afraid this is going to conflict, and I reckon this needs to be
rebased atop that. I think the actual conflicts are logically trivial,
but the diff is going to be painful.
I'm certainly in favour of breaking this down into manageable chunks,
especially as that makes the branch naming easier to follow, but I have
a couple of concerns below.
> +/* GICv3 system register access */
> +.macro __init_el2_gicv3
> + mrs x0, id_aa64pfr0_el1
> + ubfx x0, x0, #ID_AA64PFR0_GIC_SHIFT, #4
> + cbz x0, 1f
> +
> + mrs_s x0, SYS_ICC_SRE_EL2
> + orr x0, x0, #ICC_SRE_EL2_SRE // Set ICC_SRE_EL2.SRE==1
> + orr x0, x0, #ICC_SRE_EL2_ENABLE // Set ICC_SRE_EL2.Enable==1
> + msr_s SYS_ICC_SRE_EL2, x0
> + isb // Make sure SRE is now set
> + mrs_s x0, SYS_ICC_SRE_EL2 // Read SRE back,
> + tbz x0, #0, 1f // and check that it sticks
> + msr_s SYS_ICH_HCR_EL2, xzr // Reset ICC_HCR_EL2 to defaults
> +1:
> +.endm
In the head.S code, this was under an ifdef CONFIG_ARM_GIC_V3, but that
ifdef wasn't carried into the macro here, or into its use below. I'm not
sure of the impact, but that does seem to be a functional change.
> +
> +.macro __init_el2_hstr
> + msr hstr_el2, xzr // Disable CP15 traps to EL2
> +.endm
Likewise, this used to be be guarded by CONFIG_COMPAT, but that's not
carried into the macro or its use.
If the intent was to remove the conditionality, then that should be
mentioned in the commit message, since it is a potential functional
change.
Thanks,
Mark.
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v3 05/23] arm64: Extract parts of el2_setup into a macro
2020-11-26 18:06 ` Mark Rutland
(?)
@ 2020-12-01 13:55 ` David Brazdil
-1 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-12-01 13:55 UTC (permalink / raw)
To: Mark Rutland
Cc: kvmarm, Jonathan Corbet, Catalin Marinas, Will Deacon,
Marc Zyngier, James Morse, Julien Thierry, Suzuki K Poulose,
Dennis Zhou, Tejun Heo, Christoph Lameter, Lorenzo Pieralisi,
Sudeep Holla, linux-doc, linux-kernel, linux-arm-kernel,
kernel-team
Hey Mark,
> In the head.S code, this was under an ifdef CONFIG_ARM_GIC_V3, but that
> ifdef wasn't carried into the macro here, or into its use below. I'm not
> sure of the impact, but that does seem to be a functional change.
>
> > +
> > +.macro __init_el2_hstr
> > + msr hstr_el2, xzr // Disable CP15 traps to EL2
> > +.endm
>
> Likewise, this used to be be guarded by CONFIG_COMPAT, but that's not
> carried into the macro or its use.
>
> If the intent was to remove the conditionality, then that should be
> mentioned in the commit message, since it is a potential functional
> change.
Apologies, and well spotted. Marc suggested removing the ifdefs as redundant
during his review of v2. I'll update the commit message to reflect that.
David
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v3 05/23] arm64: Extract parts of el2_setup into a macro
@ 2020-12-01 13:55 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-12-01 13:55 UTC (permalink / raw)
To: Mark Rutland
Cc: Lorenzo Pieralisi, kernel-team, Jonathan Corbet, Catalin Marinas,
Suzuki K Poulose, linux-doc, linux-kernel, Sudeep Holla,
James Morse, linux-arm-kernel, Marc Zyngier, Tejun Heo,
Dennis Zhou, Christoph Lameter, Will Deacon, kvmarm,
Julien Thierry
Hey Mark,
> In the head.S code, this was under an ifdef CONFIG_ARM_GIC_V3, but that
> ifdef wasn't carried into the macro here, or into its use below. I'm not
> sure of the impact, but that does seem to be a functional change.
>
> > +
> > +.macro __init_el2_hstr
> > + msr hstr_el2, xzr // Disable CP15 traps to EL2
> > +.endm
>
> Likewise, this used to be be guarded by CONFIG_COMPAT, but that's not
> carried into the macro or its use.
>
> If the intent was to remove the conditionality, then that should be
> mentioned in the commit message, since it is a potential functional
> change.
Apologies, and well spotted. Marc suggested removing the ifdefs as redundant
during his review of v2. I'll update the commit message to reflect that.
David
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v3 05/23] arm64: Extract parts of el2_setup into a macro
@ 2020-12-01 13:55 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-12-01 13:55 UTC (permalink / raw)
To: Mark Rutland
Cc: Lorenzo Pieralisi, kernel-team, Jonathan Corbet, Catalin Marinas,
linux-doc, linux-kernel, Sudeep Holla, linux-arm-kernel,
Marc Zyngier, Tejun Heo, Dennis Zhou, Christoph Lameter,
Will Deacon, kvmarm
Hey Mark,
> In the head.S code, this was under an ifdef CONFIG_ARM_GIC_V3, but that
> ifdef wasn't carried into the macro here, or into its use below. I'm not
> sure of the impact, but that does seem to be a functional change.
>
> > +
> > +.macro __init_el2_hstr
> > + msr hstr_el2, xzr // Disable CP15 traps to EL2
> > +.endm
>
> Likewise, this used to be be guarded by CONFIG_COMPAT, but that's not
> carried into the macro or its use.
>
> If the intent was to remove the conditionality, then that should be
> mentioned in the commit message, since it is a potential functional
> change.
Apologies, and well spotted. Marc suggested removing the ifdefs as redundant
during his review of v2. I'll update the commit message to reflect that.
David
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v3 06/23] kvm: arm64: Add kvm-arm.protected early kernel parameter
2020-11-26 15:53 ` David Brazdil
(?)
@ 2020-11-26 15:54 ` David Brazdil
-1 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Jonathan Corbet, Catalin Marinas, Will Deacon, Marc Zyngier,
James Morse, Julien Thierry, Suzuki K Poulose, Dennis Zhou,
Tejun Heo, Christoph Lameter, Mark Rutland, Lorenzo Pieralisi,
Sudeep Holla, linux-doc, linux-kernel, linux-arm-kernel,
kernel-team, David Brazdil
Add an early parameter that allows users to opt into protected KVM mode
when using the nVHE hypervisor. In this mode, guest state will be kept
private from the host. This will primarily involve enabling stage-2
address translation for the host, restricting DMA to host memory, and
filtering host SMCs.
Capability ARM64_PROTECTED_KVM is set if the param is passed, CONFIG_KVM
is enabled and the kernel was not booted with VHE.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
.../admin-guide/kernel-parameters.txt | 5 ++++
arch/arm64/include/asm/cpucaps.h | 3 +-
arch/arm64/include/asm/virt.h | 8 +++++
arch/arm64/kernel/cpufeature.c | 29 +++++++++++++++++++
arch/arm64/kvm/arm.c | 4 ++-
5 files changed, 47 insertions(+), 2 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 526d65d8573a..06c89975c29c 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2259,6 +2259,11 @@
for all guests.
Default is 1 (enabled) if in 64-bit or 32-bit PAE mode.
+ kvm-arm.protected=
+ [KVM,ARM] Allow spawning protected guests whose state
+ is kept private from the host. Only valid for non-VHE.
+ Default is 0 (disabled).
+
kvm-arm.vgic_v3_group0_trap=
[KVM,ARM] Trap guest accesses to GICv3 group-0
system registers
diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
index 162539d4c8cd..9fab6cbffce2 100644
--- a/arch/arm64/include/asm/cpucaps.h
+++ b/arch/arm64/include/asm/cpucaps.h
@@ -66,7 +66,8 @@
#define ARM64_HAS_TLB_RANGE 56
#define ARM64_MTE 57
#define ARM64_WORKAROUND_1508412 58
+#define ARM64_PROTECTED_KVM 59
-#define ARM64_NCAPS 59
+#define ARM64_NCAPS 60
#endif /* __ASM_CPUCAPS_H */
diff --git a/arch/arm64/include/asm/virt.h b/arch/arm64/include/asm/virt.h
index 6069be50baf9..2fde1186b962 100644
--- a/arch/arm64/include/asm/virt.h
+++ b/arch/arm64/include/asm/virt.h
@@ -97,6 +97,14 @@ static __always_inline bool has_vhe(void)
return cpus_have_final_cap(ARM64_HAS_VIRT_HOST_EXTN);
}
+static __always_inline bool is_protected_kvm_enabled(void)
+{
+ if (is_vhe_hyp_code())
+ return false;
+ else
+ return cpus_have_final_cap(ARM64_PROTECTED_KVM);
+}
+
#endif /* __ASSEMBLY__ */
#endif /* ! __ASM__VIRT_H */
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 6f36c4f62f69..dd5bc0f0cf0d 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -1709,6 +1709,29 @@ static void cpu_enable_mte(struct arm64_cpu_capabilities const *cap)
}
#endif /* CONFIG_ARM64_MTE */
+#ifdef CONFIG_KVM
+static bool enable_protected_kvm;
+
+static bool has_protected_kvm(const struct arm64_cpu_capabilities *entry, int __unused)
+{
+ if (!enable_protected_kvm)
+ return false;
+
+ if (is_kernel_in_hyp_mode()) {
+ pr_warn("Protected KVM not available with VHE\n");
+ return false;
+ }
+
+ return true;
+}
+
+static int __init early_protected_kvm_cfg(char *buf)
+{
+ return strtobool(buf, &enable_protected_kvm);
+}
+early_param("kvm-arm.protected", early_protected_kvm_cfg);
+#endif /* CONFIG_KVM */
+
/* Internal helper functions to match cpu capability type */
static bool
cpucap_late_cpu_optional(const struct arm64_cpu_capabilities *cap)
@@ -1822,6 +1845,12 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
.field_pos = ID_AA64PFR0_EL1_SHIFT,
.min_field_value = ID_AA64PFR0_EL1_32BIT_64BIT,
},
+ {
+ .desc = "Protected KVM",
+ .capability = ARM64_PROTECTED_KVM,
+ .type = ARM64_CPUCAP_SYSTEM_FEATURE,
+ .matches = has_protected_kvm,
+ },
#endif
{
.desc = "Kernel page table isolation (KPTI)",
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index 2d0a37c75cda..b25035dc0478 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -1818,7 +1818,9 @@ int kvm_arch_init(void *opaque)
if (err)
goto out_hyp;
- if (in_hyp_mode)
+ if (is_protected_kvm_enabled())
+ kvm_info("Protected nVHE mode initialized successfully\n");
+ else if (in_hyp_mode)
kvm_info("VHE mode initialized successfully\n");
else
kvm_info("Hyp mode initialized successfully\n");
--
2.29.2.454.gaff20da3a2-goog
^ permalink raw reply related [flat|nested] 147+ messages in thread* [PATCH v3 06/23] kvm: arm64: Add kvm-arm.protected early kernel parameter
@ 2020-11-26 15:54 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Mark Rutland, Lorenzo Pieralisi, kernel-team, Jonathan Corbet,
Catalin Marinas, Suzuki K Poulose, linux-doc, linux-kernel,
Sudeep Holla, James Morse, linux-arm-kernel, Marc Zyngier,
Tejun Heo, Dennis Zhou, Christoph Lameter, David Brazdil,
Will Deacon, Julien Thierry
Add an early parameter that allows users to opt into protected KVM mode
when using the nVHE hypervisor. In this mode, guest state will be kept
private from the host. This will primarily involve enabling stage-2
address translation for the host, restricting DMA to host memory, and
filtering host SMCs.
Capability ARM64_PROTECTED_KVM is set if the param is passed, CONFIG_KVM
is enabled and the kernel was not booted with VHE.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
.../admin-guide/kernel-parameters.txt | 5 ++++
arch/arm64/include/asm/cpucaps.h | 3 +-
arch/arm64/include/asm/virt.h | 8 +++++
arch/arm64/kernel/cpufeature.c | 29 +++++++++++++++++++
arch/arm64/kvm/arm.c | 4 ++-
5 files changed, 47 insertions(+), 2 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 526d65d8573a..06c89975c29c 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2259,6 +2259,11 @@
for all guests.
Default is 1 (enabled) if in 64-bit or 32-bit PAE mode.
+ kvm-arm.protected=
+ [KVM,ARM] Allow spawning protected guests whose state
+ is kept private from the host. Only valid for non-VHE.
+ Default is 0 (disabled).
+
kvm-arm.vgic_v3_group0_trap=
[KVM,ARM] Trap guest accesses to GICv3 group-0
system registers
diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
index 162539d4c8cd..9fab6cbffce2 100644
--- a/arch/arm64/include/asm/cpucaps.h
+++ b/arch/arm64/include/asm/cpucaps.h
@@ -66,7 +66,8 @@
#define ARM64_HAS_TLB_RANGE 56
#define ARM64_MTE 57
#define ARM64_WORKAROUND_1508412 58
+#define ARM64_PROTECTED_KVM 59
-#define ARM64_NCAPS 59
+#define ARM64_NCAPS 60
#endif /* __ASM_CPUCAPS_H */
diff --git a/arch/arm64/include/asm/virt.h b/arch/arm64/include/asm/virt.h
index 6069be50baf9..2fde1186b962 100644
--- a/arch/arm64/include/asm/virt.h
+++ b/arch/arm64/include/asm/virt.h
@@ -97,6 +97,14 @@ static __always_inline bool has_vhe(void)
return cpus_have_final_cap(ARM64_HAS_VIRT_HOST_EXTN);
}
+static __always_inline bool is_protected_kvm_enabled(void)
+{
+ if (is_vhe_hyp_code())
+ return false;
+ else
+ return cpus_have_final_cap(ARM64_PROTECTED_KVM);
+}
+
#endif /* __ASSEMBLY__ */
#endif /* ! __ASM__VIRT_H */
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 6f36c4f62f69..dd5bc0f0cf0d 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -1709,6 +1709,29 @@ static void cpu_enable_mte(struct arm64_cpu_capabilities const *cap)
}
#endif /* CONFIG_ARM64_MTE */
+#ifdef CONFIG_KVM
+static bool enable_protected_kvm;
+
+static bool has_protected_kvm(const struct arm64_cpu_capabilities *entry, int __unused)
+{
+ if (!enable_protected_kvm)
+ return false;
+
+ if (is_kernel_in_hyp_mode()) {
+ pr_warn("Protected KVM not available with VHE\n");
+ return false;
+ }
+
+ return true;
+}
+
+static int __init early_protected_kvm_cfg(char *buf)
+{
+ return strtobool(buf, &enable_protected_kvm);
+}
+early_param("kvm-arm.protected", early_protected_kvm_cfg);
+#endif /* CONFIG_KVM */
+
/* Internal helper functions to match cpu capability type */
static bool
cpucap_late_cpu_optional(const struct arm64_cpu_capabilities *cap)
@@ -1822,6 +1845,12 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
.field_pos = ID_AA64PFR0_EL1_SHIFT,
.min_field_value = ID_AA64PFR0_EL1_32BIT_64BIT,
},
+ {
+ .desc = "Protected KVM",
+ .capability = ARM64_PROTECTED_KVM,
+ .type = ARM64_CPUCAP_SYSTEM_FEATURE,
+ .matches = has_protected_kvm,
+ },
#endif
{
.desc = "Kernel page table isolation (KPTI)",
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index 2d0a37c75cda..b25035dc0478 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -1818,7 +1818,9 @@ int kvm_arch_init(void *opaque)
if (err)
goto out_hyp;
- if (in_hyp_mode)
+ if (is_protected_kvm_enabled())
+ kvm_info("Protected nVHE mode initialized successfully\n");
+ else if (in_hyp_mode)
kvm_info("VHE mode initialized successfully\n");
else
kvm_info("Hyp mode initialized successfully\n");
--
2.29.2.454.gaff20da3a2-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 147+ messages in thread* [PATCH v3 06/23] kvm: arm64: Add kvm-arm.protected early kernel parameter
@ 2020-11-26 15:54 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Lorenzo Pieralisi, kernel-team, Jonathan Corbet, Catalin Marinas,
linux-doc, linux-kernel, Sudeep Holla, linux-arm-kernel,
Marc Zyngier, Tejun Heo, Dennis Zhou, Christoph Lameter,
Will Deacon
Add an early parameter that allows users to opt into protected KVM mode
when using the nVHE hypervisor. In this mode, guest state will be kept
private from the host. This will primarily involve enabling stage-2
address translation for the host, restricting DMA to host memory, and
filtering host SMCs.
Capability ARM64_PROTECTED_KVM is set if the param is passed, CONFIG_KVM
is enabled and the kernel was not booted with VHE.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
.../admin-guide/kernel-parameters.txt | 5 ++++
arch/arm64/include/asm/cpucaps.h | 3 +-
arch/arm64/include/asm/virt.h | 8 +++++
arch/arm64/kernel/cpufeature.c | 29 +++++++++++++++++++
arch/arm64/kvm/arm.c | 4 ++-
5 files changed, 47 insertions(+), 2 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 526d65d8573a..06c89975c29c 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2259,6 +2259,11 @@
for all guests.
Default is 1 (enabled) if in 64-bit or 32-bit PAE mode.
+ kvm-arm.protected=
+ [KVM,ARM] Allow spawning protected guests whose state
+ is kept private from the host. Only valid for non-VHE.
+ Default is 0 (disabled).
+
kvm-arm.vgic_v3_group0_trap=
[KVM,ARM] Trap guest accesses to GICv3 group-0
system registers
diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
index 162539d4c8cd..9fab6cbffce2 100644
--- a/arch/arm64/include/asm/cpucaps.h
+++ b/arch/arm64/include/asm/cpucaps.h
@@ -66,7 +66,8 @@
#define ARM64_HAS_TLB_RANGE 56
#define ARM64_MTE 57
#define ARM64_WORKAROUND_1508412 58
+#define ARM64_PROTECTED_KVM 59
-#define ARM64_NCAPS 59
+#define ARM64_NCAPS 60
#endif /* __ASM_CPUCAPS_H */
diff --git a/arch/arm64/include/asm/virt.h b/arch/arm64/include/asm/virt.h
index 6069be50baf9..2fde1186b962 100644
--- a/arch/arm64/include/asm/virt.h
+++ b/arch/arm64/include/asm/virt.h
@@ -97,6 +97,14 @@ static __always_inline bool has_vhe(void)
return cpus_have_final_cap(ARM64_HAS_VIRT_HOST_EXTN);
}
+static __always_inline bool is_protected_kvm_enabled(void)
+{
+ if (is_vhe_hyp_code())
+ return false;
+ else
+ return cpus_have_final_cap(ARM64_PROTECTED_KVM);
+}
+
#endif /* __ASSEMBLY__ */
#endif /* ! __ASM__VIRT_H */
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 6f36c4f62f69..dd5bc0f0cf0d 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -1709,6 +1709,29 @@ static void cpu_enable_mte(struct arm64_cpu_capabilities const *cap)
}
#endif /* CONFIG_ARM64_MTE */
+#ifdef CONFIG_KVM
+static bool enable_protected_kvm;
+
+static bool has_protected_kvm(const struct arm64_cpu_capabilities *entry, int __unused)
+{
+ if (!enable_protected_kvm)
+ return false;
+
+ if (is_kernel_in_hyp_mode()) {
+ pr_warn("Protected KVM not available with VHE\n");
+ return false;
+ }
+
+ return true;
+}
+
+static int __init early_protected_kvm_cfg(char *buf)
+{
+ return strtobool(buf, &enable_protected_kvm);
+}
+early_param("kvm-arm.protected", early_protected_kvm_cfg);
+#endif /* CONFIG_KVM */
+
/* Internal helper functions to match cpu capability type */
static bool
cpucap_late_cpu_optional(const struct arm64_cpu_capabilities *cap)
@@ -1822,6 +1845,12 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
.field_pos = ID_AA64PFR0_EL1_SHIFT,
.min_field_value = ID_AA64PFR0_EL1_32BIT_64BIT,
},
+ {
+ .desc = "Protected KVM",
+ .capability = ARM64_PROTECTED_KVM,
+ .type = ARM64_CPUCAP_SYSTEM_FEATURE,
+ .matches = has_protected_kvm,
+ },
#endif
{
.desc = "Kernel page table isolation (KPTI)",
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index 2d0a37c75cda..b25035dc0478 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -1818,7 +1818,9 @@ int kvm_arch_init(void *opaque)
if (err)
goto out_hyp;
- if (in_hyp_mode)
+ if (is_protected_kvm_enabled())
+ kvm_info("Protected nVHE mode initialized successfully\n");
+ else if (in_hyp_mode)
kvm_info("VHE mode initialized successfully\n");
else
kvm_info("Hyp mode initialized successfully\n");
--
2.29.2.454.gaff20da3a2-goog
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply related [flat|nested] 147+ messages in thread* Re: [PATCH v3 06/23] kvm: arm64: Add kvm-arm.protected early kernel parameter
2020-11-26 15:54 ` David Brazdil
(?)
@ 2020-11-27 16:32 ` Sudeep Holla
-1 siblings, 0 replies; 147+ messages in thread
From: Sudeep Holla @ 2020-11-27 16:32 UTC (permalink / raw)
To: David Brazdil
Cc: kvmarm, Jonathan Corbet, Catalin Marinas, Will Deacon,
Marc Zyngier, James Morse, Julien Thierry, Suzuki K Poulose,
Dennis Zhou, Tejun Heo, Christoph Lameter, Mark Rutland,
Lorenzo Pieralisi, linux-doc, linux-kernel, linux-arm-kernel,
kernel-team
On Thu, Nov 26, 2020 at 03:54:04PM +0000, David Brazdil wrote:
> Add an early parameter that allows users to opt into protected KVM mode
> when using the nVHE hypervisor. In this mode, guest state will be kept
> private from the host. This will primarily involve enabling stage-2
> address translation for the host, restricting DMA to host memory, and
> filtering host SMCs.
>
> Capability ARM64_PROTECTED_KVM is set if the param is passed, CONFIG_KVM
> is enabled and the kernel was not booted with VHE.
>
> Signed-off-by: David Brazdil <dbrazdil@google.com>
> ---
> .../admin-guide/kernel-parameters.txt | 5 ++++
> arch/arm64/include/asm/cpucaps.h | 3 +-
> arch/arm64/include/asm/virt.h | 8 +++++
> arch/arm64/kernel/cpufeature.c | 29 +++++++++++++++++++
> arch/arm64/kvm/arm.c | 4 ++-
> 5 files changed, 47 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 526d65d8573a..06c89975c29c 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -2259,6 +2259,11 @@
> for all guests.
> Default is 1 (enabled) if in 64-bit or 32-bit PAE mode.
>
> + kvm-arm.protected=
> + [KVM,ARM] Allow spawning protected guests whose state
> + is kept private from the host. Only valid for non-VHE.
> + Default is 0 (disabled).
> +
Sorry for being pedantic. Can we reword this to say valid for
!CONFIG_ARM64_VHE ? I read this as valid only for non-VHE hardware, it may
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.
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v3 06/23] kvm: arm64: Add kvm-arm.protected early kernel parameter
@ 2020-11-27 16:32 ` Sudeep Holla
0 siblings, 0 replies; 147+ messages in thread
From: Sudeep Holla @ 2020-11-27 16:32 UTC (permalink / raw)
To: David Brazdil
Cc: Mark Rutland, Lorenzo Pieralisi, kernel-team, Jonathan Corbet,
Catalin Marinas, Suzuki K Poulose, linux-doc, linux-kernel,
James Morse, linux-arm-kernel, Marc Zyngier, Tejun Heo,
Dennis Zhou, Christoph Lameter, Will Deacon, kvmarm,
Julien Thierry
On Thu, Nov 26, 2020 at 03:54:04PM +0000, David Brazdil wrote:
> Add an early parameter that allows users to opt into protected KVM mode
> when using the nVHE hypervisor. In this mode, guest state will be kept
> private from the host. This will primarily involve enabling stage-2
> address translation for the host, restricting DMA to host memory, and
> filtering host SMCs.
>
> Capability ARM64_PROTECTED_KVM is set if the param is passed, CONFIG_KVM
> is enabled and the kernel was not booted with VHE.
>
> Signed-off-by: David Brazdil <dbrazdil@google.com>
> ---
> .../admin-guide/kernel-parameters.txt | 5 ++++
> arch/arm64/include/asm/cpucaps.h | 3 +-
> arch/arm64/include/asm/virt.h | 8 +++++
> arch/arm64/kernel/cpufeature.c | 29 +++++++++++++++++++
> arch/arm64/kvm/arm.c | 4 ++-
> 5 files changed, 47 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 526d65d8573a..06c89975c29c 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -2259,6 +2259,11 @@
> for all guests.
> Default is 1 (enabled) if in 64-bit or 32-bit PAE mode.
>
> + kvm-arm.protected=
> + [KVM,ARM] Allow spawning protected guests whose state
> + is kept private from the host. Only valid for non-VHE.
> + Default is 0 (disabled).
> +
Sorry for being pedantic. Can we reword this to say valid for
!CONFIG_ARM64_VHE ? I read this as valid only for non-VHE hardware, it may
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.
--
Regards,
Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v3 06/23] kvm: arm64: Add kvm-arm.protected early kernel parameter
@ 2020-11-27 16:32 ` Sudeep Holla
0 siblings, 0 replies; 147+ messages in thread
From: Sudeep Holla @ 2020-11-27 16:32 UTC (permalink / raw)
To: David Brazdil
Cc: Lorenzo Pieralisi, kernel-team, Jonathan Corbet, Catalin Marinas,
linux-doc, linux-kernel, linux-arm-kernel, Marc Zyngier,
Tejun Heo, Dennis Zhou, Christoph Lameter, Will Deacon, kvmarm
On Thu, Nov 26, 2020 at 03:54:04PM +0000, David Brazdil wrote:
> Add an early parameter that allows users to opt into protected KVM mode
> when using the nVHE hypervisor. In this mode, guest state will be kept
> private from the host. This will primarily involve enabling stage-2
> address translation for the host, restricting DMA to host memory, and
> filtering host SMCs.
>
> Capability ARM64_PROTECTED_KVM is set if the param is passed, CONFIG_KVM
> is enabled and the kernel was not booted with VHE.
>
> Signed-off-by: David Brazdil <dbrazdil@google.com>
> ---
> .../admin-guide/kernel-parameters.txt | 5 ++++
> arch/arm64/include/asm/cpucaps.h | 3 +-
> arch/arm64/include/asm/virt.h | 8 +++++
> arch/arm64/kernel/cpufeature.c | 29 +++++++++++++++++++
> arch/arm64/kvm/arm.c | 4 ++-
> 5 files changed, 47 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 526d65d8573a..06c89975c29c 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -2259,6 +2259,11 @@
> for all guests.
> Default is 1 (enabled) if in 64-bit or 32-bit PAE mode.
>
> + kvm-arm.protected=
> + [KVM,ARM] Allow spawning protected guests whose state
> + is kept private from the host. Only valid for non-VHE.
> + Default is 0 (disabled).
> +
Sorry for being pedantic. Can we reword this to say valid for
!CONFIG_ARM64_VHE ? I read this as valid only for non-VHE hardware, it may
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.
--
Regards,
Sudeep
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v3 06/23] kvm: arm64: Add kvm-arm.protected early kernel parameter
2020-11-27 16:32 ` Sudeep Holla
(?)
@ 2020-12-01 13:19 ` David Brazdil
-1 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-12-01 13:19 UTC (permalink / raw)
To: Sudeep Holla
Cc: kvmarm, Jonathan Corbet, Catalin Marinas, Will Deacon,
Marc Zyngier, James Morse, Julien Thierry, Suzuki K Poulose,
Dennis Zhou, Tejun Heo, Christoph Lameter, Mark Rutland,
Lorenzo Pieralisi, linux-doc, linux-kernel, linux-arm-kernel,
kernel-team
Hey Sudeep,
> > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> > index 526d65d8573a..06c89975c29c 100644
> > --- a/Documentation/admin-guide/kernel-parameters.txt
> > +++ b/Documentation/admin-guide/kernel-parameters.txt
> > @@ -2259,6 +2259,11 @@
> > for all guests.
> > Default is 1 (enabled) if in 64-bit or 32-bit PAE mode.
> >
> > + kvm-arm.protected=
> > + [KVM,ARM] Allow spawning protected guests whose state
> > + is kept private from the host. Only valid for non-VHE.
> > + Default is 0 (disabled).
> > +
>
> Sorry for being pedantic. Can we reword this to say valid for
> !CONFIG_ARM64_VHE ? I read this as valid only for non-VHE hardware, it may
> 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?
-David
^ permalink raw reply [flat|nested] 147+ messages in thread* Re: [PATCH v3 06/23] kvm: arm64: Add kvm-arm.protected early kernel parameter
@ 2020-12-01 13:19 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-12-01 13:19 UTC (permalink / raw)
To: Sudeep Holla
Cc: Mark Rutland, Lorenzo Pieralisi, kernel-team, Jonathan Corbet,
Catalin Marinas, Suzuki K Poulose, linux-doc, linux-kernel,
James Morse, linux-arm-kernel, Marc Zyngier, Tejun Heo,
Dennis Zhou, Christoph Lameter, Will Deacon, kvmarm,
Julien Thierry
Hey Sudeep,
> > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> > index 526d65d8573a..06c89975c29c 100644
> > --- a/Documentation/admin-guide/kernel-parameters.txt
> > +++ b/Documentation/admin-guide/kernel-parameters.txt
> > @@ -2259,6 +2259,11 @@
> > for all guests.
> > Default is 1 (enabled) if in 64-bit or 32-bit PAE mode.
> >
> > + kvm-arm.protected=
> > + [KVM,ARM] Allow spawning protected guests whose state
> > + is kept private from the host. Only valid for non-VHE.
> > + Default is 0 (disabled).
> > +
>
> Sorry for being pedantic. Can we reword this to say valid for
> !CONFIG_ARM64_VHE ? I read this as valid only for non-VHE hardware, it may
> 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?
-David
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 147+ messages in thread* Re: [PATCH v3 06/23] kvm: arm64: Add kvm-arm.protected early kernel parameter
@ 2020-12-01 13:19 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-12-01 13:19 UTC (permalink / raw)
To: Sudeep Holla
Cc: Lorenzo Pieralisi, kernel-team, Jonathan Corbet, Catalin Marinas,
linux-doc, linux-kernel, linux-arm-kernel, Marc Zyngier,
Tejun Heo, Dennis Zhou, Christoph Lameter, Will Deacon, kvmarm
Hey Sudeep,
> > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> > index 526d65d8573a..06c89975c29c 100644
> > --- a/Documentation/admin-guide/kernel-parameters.txt
> > +++ b/Documentation/admin-guide/kernel-parameters.txt
> > @@ -2259,6 +2259,11 @@
> > for all guests.
> > Default is 1 (enabled) if in 64-bit or 32-bit PAE mode.
> >
> > + kvm-arm.protected=
> > + [KVM,ARM] Allow spawning protected guests whose state
> > + is kept private from the host. Only valid for non-VHE.
> > + Default is 0 (disabled).
> > +
>
> Sorry for being pedantic. Can we reword this to say valid for
> !CONFIG_ARM64_VHE ? I read this as valid only for non-VHE hardware, it may
> 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?
-David
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 147+ messages in thread* Re: [PATCH v3 06/23] kvm: arm64: Add kvm-arm.protected early kernel parameter
2020-12-01 13:19 ` David Brazdil
(?)
@ 2020-12-01 14:07 ` Mark Rutland
-1 siblings, 0 replies; 147+ messages in thread
From: Mark Rutland @ 2020-12-01 14:07 UTC (permalink / raw)
To: David Brazdil
Cc: Sudeep Holla, kvmarm, Jonathan Corbet, Catalin Marinas,
Will Deacon, Marc Zyngier, James Morse, Julien Thierry,
Suzuki K Poulose, Dennis Zhou, Tejun Heo, Christoph Lameter,
Lorenzo Pieralisi, linux-doc, linux-kernel, linux-arm-kernel,
kernel-team
On Tue, Dec 01, 2020 at 01:19:13PM +0000, David Brazdil wrote:
> Hey Sudeep,
>
> > > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> > > index 526d65d8573a..06c89975c29c 100644
> > > --- a/Documentation/admin-guide/kernel-parameters.txt
> > > +++ b/Documentation/admin-guide/kernel-parameters.txt
> > > @@ -2259,6 +2259,11 @@
> > > for all guests.
> > > Default is 1 (enabled) if in 64-bit or 32-bit PAE mode.
> > >
> > > + kvm-arm.protected=
> > > + [KVM,ARM] Allow spawning protected guests whose state
> > > + is kept private from the host. Only valid for non-VHE.
> > > + Default is 0 (disabled).
> > > +
> >
> > Sorry for being pedantic. Can we reword this to say valid for
> > !CONFIG_ARM64_VHE ? I read this as valid only for non-VHE hardware, it may
> > 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.
Thanks,
Mark.
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v3 06/23] kvm: arm64: Add kvm-arm.protected early kernel parameter
@ 2020-12-01 14:07 ` Mark Rutland
0 siblings, 0 replies; 147+ messages in thread
From: Mark Rutland @ 2020-12-01 14:07 UTC (permalink / raw)
To: David Brazdil
Cc: Lorenzo Pieralisi, kernel-team, Jonathan Corbet, Catalin Marinas,
Sudeep Holla, linux-doc, linux-kernel, Suzuki K Poulose,
James Morse, linux-arm-kernel, Marc Zyngier, Tejun Heo,
Dennis Zhou, Christoph Lameter, Will Deacon, kvmarm,
Julien Thierry
On Tue, Dec 01, 2020 at 01:19:13PM +0000, David Brazdil wrote:
> Hey Sudeep,
>
> > > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> > > index 526d65d8573a..06c89975c29c 100644
> > > --- a/Documentation/admin-guide/kernel-parameters.txt
> > > +++ b/Documentation/admin-guide/kernel-parameters.txt
> > > @@ -2259,6 +2259,11 @@
> > > for all guests.
> > > Default is 1 (enabled) if in 64-bit or 32-bit PAE mode.
> > >
> > > + kvm-arm.protected=
> > > + [KVM,ARM] Allow spawning protected guests whose state
> > > + is kept private from the host. Only valid for non-VHE.
> > > + Default is 0 (disabled).
> > > +
> >
> > Sorry for being pedantic. Can we reword this to say valid for
> > !CONFIG_ARM64_VHE ? I read this as valid only for non-VHE hardware, it may
> > 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.
Thanks,
Mark.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v3 06/23] kvm: arm64: Add kvm-arm.protected early kernel parameter
@ 2020-12-01 14:07 ` Mark Rutland
0 siblings, 0 replies; 147+ messages in thread
From: Mark Rutland @ 2020-12-01 14:07 UTC (permalink / raw)
To: David Brazdil
Cc: Lorenzo Pieralisi, kernel-team, Jonathan Corbet, Catalin Marinas,
Sudeep Holla, linux-doc, linux-kernel, linux-arm-kernel,
Marc Zyngier, Tejun Heo, Dennis Zhou, Christoph Lameter,
Will Deacon, kvmarm
On Tue, Dec 01, 2020 at 01:19:13PM +0000, David Brazdil wrote:
> Hey Sudeep,
>
> > > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> > > index 526d65d8573a..06c89975c29c 100644
> > > --- a/Documentation/admin-guide/kernel-parameters.txt
> > > +++ b/Documentation/admin-guide/kernel-parameters.txt
> > > @@ -2259,6 +2259,11 @@
> > > for all guests.
> > > Default is 1 (enabled) if in 64-bit or 32-bit PAE mode.
> > >
> > > + kvm-arm.protected=
> > > + [KVM,ARM] Allow spawning protected guests whose state
> > > + is kept private from the host. Only valid for non-VHE.
> > > + Default is 0 (disabled).
> > > +
> >
> > Sorry for being pedantic. Can we reword this to say valid for
> > !CONFIG_ARM64_VHE ? I read this as valid only for non-VHE hardware, it may
> > 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.
Thanks,
Mark.
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v3 06/23] kvm: arm64: Add kvm-arm.protected early kernel parameter
2020-12-01 14:07 ` Mark Rutland
(?)
@ 2020-12-01 14:43 ` David Brazdil
-1 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-12-01 14:43 UTC (permalink / raw)
To: Mark Rutland
Cc: Sudeep Holla, kvmarm, Jonathan Corbet, Catalin Marinas,
Will Deacon, Marc Zyngier, James Morse, Julien Thierry,
Suzuki K Poulose, Dennis Zhou, Tejun Heo, Christoph Lameter,
Lorenzo Pieralisi, linux-doc, linux-kernel, linux-arm-kernel,
kernel-team
> > > 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
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v3 06/23] kvm: arm64: Add kvm-arm.protected early kernel parameter
@ 2020-12-01 14:43 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-12-01 14:43 UTC (permalink / raw)
To: Mark Rutland
Cc: Lorenzo Pieralisi, kernel-team, Jonathan Corbet, Catalin Marinas,
Sudeep Holla, linux-doc, linux-kernel, Suzuki K Poulose,
James Morse, linux-arm-kernel, Marc Zyngier, Tejun Heo,
Dennis Zhou, Christoph Lameter, Will Deacon, kvmarm,
Julien Thierry
> > > 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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v3 06/23] kvm: arm64: Add kvm-arm.protected early kernel parameter
@ 2020-12-01 14:43 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-12-01 14:43 UTC (permalink / raw)
To: Mark Rutland
Cc: Lorenzo Pieralisi, kernel-team, Jonathan Corbet, Catalin Marinas,
Sudeep Holla, linux-doc, linux-kernel, linux-arm-kernel,
Marc Zyngier, Tejun Heo, Dennis Zhou, Christoph Lameter,
Will Deacon, kvmarm
> > > 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
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v3 06/23] kvm: arm64: Add kvm-arm.protected early kernel parameter
2020-12-01 14:43 ` David Brazdil
(?)
@ 2020-12-01 14:58 ` Mark Rutland
-1 siblings, 0 replies; 147+ messages in thread
From: Mark Rutland @ 2020-12-01 14:58 UTC (permalink / raw)
To: David Brazdil
Cc: Sudeep Holla, kvmarm, Jonathan Corbet, Catalin Marinas,
Will Deacon, Marc Zyngier, James Morse, Julien Thierry,
Suzuki K Poulose, Dennis Zhou, Tejun Heo, Christoph Lameter,
Lorenzo Pieralisi, linux-doc, linux-kernel, linux-arm-kernel,
kernel-team
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.
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v3 06/23] kvm: arm64: Add kvm-arm.protected early kernel parameter
@ 2020-12-01 14:58 ` Mark Rutland
0 siblings, 0 replies; 147+ messages in thread
From: Mark Rutland @ 2020-12-01 14:58 UTC (permalink / raw)
To: David Brazdil
Cc: Lorenzo Pieralisi, kernel-team, Jonathan Corbet, Catalin Marinas,
Sudeep Holla, linux-doc, linux-kernel, Suzuki K Poulose,
James Morse, linux-arm-kernel, Marc Zyngier, Tejun Heo,
Dennis Zhou, Christoph Lameter, Will Deacon, kvmarm,
Julien Thierry
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.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v3 06/23] kvm: arm64: Add kvm-arm.protected early kernel parameter
@ 2020-12-01 14:58 ` Mark Rutland
0 siblings, 0 replies; 147+ messages in thread
From: Mark Rutland @ 2020-12-01 14:58 UTC (permalink / raw)
To: David Brazdil
Cc: Lorenzo Pieralisi, kernel-team, Jonathan Corbet, Catalin Marinas,
Sudeep Holla, linux-doc, linux-kernel, linux-arm-kernel,
Marc Zyngier, Tejun Heo, Dennis Zhou, Christoph Lameter,
Will Deacon, kvmarm
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.
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v3 07/23] kvm: arm64: Initialize MAIR_EL2 using a constant
2020-11-26 15:53 ` David Brazdil
(?)
@ 2020-11-26 15:54 ` David Brazdil
-1 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Jonathan Corbet, Catalin Marinas, Will Deacon, Marc Zyngier,
James Morse, Julien Thierry, Suzuki K Poulose, Dennis Zhou,
Tejun Heo, Christoph Lameter, Mark Rutland, Lorenzo Pieralisi,
Sudeep Holla, linux-doc, linux-kernel, linux-arm-kernel,
kernel-team, David Brazdil
MAIR_EL2 is currently initialized to the value of MAIR_EL1, which itself
is set to a constant MAIR_ELx_SET.
Initialize MAIR_EL2 to MAIR_ELx_SET directly in preparation for allowing
KVM to start CPU cores itself before ERETing to EL1. In that case,
MAIR_EL2 will be initialized before MAIR_EL1.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
arch/arm64/kvm/hyp/nvhe/hyp-init.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-init.S b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
index b11a9d7db677..17b58dbc3a2f 100644
--- a/arch/arm64/kvm/hyp/nvhe/hyp-init.S
+++ b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
@@ -111,7 +111,7 @@ alternative_else_nop_endif
msr tcr_el2, x0
- mrs x0, mair_el1
+ mov_q x0, MAIR_ELx_SET
msr mair_el2, x0
isb
--
2.29.2.454.gaff20da3a2-goog
^ permalink raw reply related [flat|nested] 147+ messages in thread
* [PATCH v3 07/23] kvm: arm64: Initialize MAIR_EL2 using a constant
@ 2020-11-26 15:54 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Mark Rutland, Lorenzo Pieralisi, kernel-team, Jonathan Corbet,
Catalin Marinas, Suzuki K Poulose, linux-doc, linux-kernel,
Sudeep Holla, James Morse, linux-arm-kernel, Marc Zyngier,
Tejun Heo, Dennis Zhou, Christoph Lameter, David Brazdil,
Will Deacon, Julien Thierry
MAIR_EL2 is currently initialized to the value of MAIR_EL1, which itself
is set to a constant MAIR_ELx_SET.
Initialize MAIR_EL2 to MAIR_ELx_SET directly in preparation for allowing
KVM to start CPU cores itself before ERETing to EL1. In that case,
MAIR_EL2 will be initialized before MAIR_EL1.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
arch/arm64/kvm/hyp/nvhe/hyp-init.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-init.S b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
index b11a9d7db677..17b58dbc3a2f 100644
--- a/arch/arm64/kvm/hyp/nvhe/hyp-init.S
+++ b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
@@ -111,7 +111,7 @@ alternative_else_nop_endif
msr tcr_el2, x0
- mrs x0, mair_el1
+ mov_q x0, MAIR_ELx_SET
msr mair_el2, x0
isb
--
2.29.2.454.gaff20da3a2-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 147+ messages in thread
* [PATCH v3 07/23] kvm: arm64: Initialize MAIR_EL2 using a constant
@ 2020-11-26 15:54 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Lorenzo Pieralisi, kernel-team, Jonathan Corbet, Catalin Marinas,
linux-doc, linux-kernel, Sudeep Holla, linux-arm-kernel,
Marc Zyngier, Tejun Heo, Dennis Zhou, Christoph Lameter,
Will Deacon
MAIR_EL2 is currently initialized to the value of MAIR_EL1, which itself
is set to a constant MAIR_ELx_SET.
Initialize MAIR_EL2 to MAIR_ELx_SET directly in preparation for allowing
KVM to start CPU cores itself before ERETing to EL1. In that case,
MAIR_EL2 will be initialized before MAIR_EL1.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
arch/arm64/kvm/hyp/nvhe/hyp-init.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-init.S b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
index b11a9d7db677..17b58dbc3a2f 100644
--- a/arch/arm64/kvm/hyp/nvhe/hyp-init.S
+++ b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
@@ -111,7 +111,7 @@ alternative_else_nop_endif
msr tcr_el2, x0
- mrs x0, mair_el1
+ mov_q x0, MAIR_ELx_SET
msr mair_el2, x0
isb
--
2.29.2.454.gaff20da3a2-goog
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply related [flat|nested] 147+ messages in thread
* [PATCH v3 08/23] kvm: arm64: Remove vector_ptr param of hyp-init
2020-11-26 15:53 ` David Brazdil
(?)
@ 2020-11-26 15:54 ` David Brazdil
-1 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Jonathan Corbet, Catalin Marinas, Will Deacon, Marc Zyngier,
James Morse, Julien Thierry, Suzuki K Poulose, Dennis Zhou,
Tejun Heo, Christoph Lameter, Mark Rutland, Lorenzo Pieralisi,
Sudeep Holla, linux-doc, linux-kernel, linux-arm-kernel,
kernel-team, David Brazdil
KVM precomputes the hyp VA of __kvm_hyp_host_vector, essentially a
constant (minus ASLR), before passing it to __kvm_hyp_init.
Now that we have alternatives for converting kimg VA to hyp VA, replace
this with computing the constant inside __kvm_hyp_init, thus removing
the need for an argument.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
arch/arm64/include/asm/kvm_asm.h | 2 --
arch/arm64/include/asm/kvm_mmu.h | 26 +++++++++++++++++++++++++-
arch/arm64/kvm/arm.c | 4 +---
arch/arm64/kvm/hyp/nvhe/hyp-init.S | 9 ++++++---
4 files changed, 32 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
index 4a6a77d8d13e..531f9d04eefd 100644
--- a/arch/arm64/include/asm/kvm_asm.h
+++ b/arch/arm64/include/asm/kvm_asm.h
@@ -163,10 +163,8 @@ struct kvm_vcpu;
struct kvm_s2_mmu;
DECLARE_KVM_NVHE_SYM(__kvm_hyp_init);
-DECLARE_KVM_NVHE_SYM(__kvm_hyp_host_vector);
DECLARE_KVM_HYP_SYM(__kvm_hyp_vector);
#define __kvm_hyp_init CHOOSE_NVHE_SYM(__kvm_hyp_init)
-#define __kvm_hyp_host_vector CHOOSE_NVHE_SYM(__kvm_hyp_host_vector)
#define __kvm_hyp_vector CHOOSE_HYP_SYM(__kvm_hyp_vector)
extern unsigned long kvm_arm_hyp_percpu_base[NR_CPUS];
diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
index 5168a0c516ae..6945faeb68ac 100644
--- a/arch/arm64/include/asm/kvm_mmu.h
+++ b/arch/arm64/include/asm/kvm_mmu.h
@@ -93,7 +93,31 @@ alternative_cb_end
/* reg = __pa(reg) */
sub \reg, \reg, \tmp
.endm
-
+
+/*
+ * Convert a kernel image address to a hyp VA
+ * reg: kernel address to be converted in place
+ * tmp: temporary register
+ *
+ * The actual code generation takes place in kvm_get_kimage_voffset, and
+ * the instructions below are only there to reserve the space and
+ * perform the register allocation (kvm_get_kimage_voffset uses the
+ * specific registers encoded in the instructions).
+ */
+.macro kimg_hyp_va reg, tmp
+alternative_cb kvm_update_kimg_phys_offset
+ movz \tmp, #0
+ movk \tmp, #0, lsl #16
+ movk \tmp, #0, lsl #32
+ movk \tmp, #0, lsl #48
+alternative_cb_end
+
+ sub \reg, \reg, \tmp
+ mov_q \tmp, PAGE_OFFSET
+ orr \reg, \reg, \tmp
+ kern_hyp_va \reg
+.endm
+
#else
#include <linux/pgtable.h>
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index b25035dc0478..cd6e5dec203f 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -1355,7 +1355,6 @@ static void cpu_init_hyp_mode(void)
{
phys_addr_t pgd_ptr;
unsigned long hyp_stack_ptr;
- unsigned long vector_ptr;
unsigned long tpidr_el2;
struct arm_smccc_res res;
@@ -1373,7 +1372,6 @@ static void cpu_init_hyp_mode(void)
pgd_ptr = kvm_mmu_get_httbr();
hyp_stack_ptr = __this_cpu_read(kvm_arm_hyp_stack_page) + PAGE_SIZE;
hyp_stack_ptr = kern_hyp_va(hyp_stack_ptr);
- vector_ptr = (unsigned long)kern_hyp_va(kvm_ksym_ref(__kvm_hyp_host_vector));
/*
* Call initialization code, and switch to the full blown HYP code.
@@ -1383,7 +1381,7 @@ static void cpu_init_hyp_mode(void)
*/
BUG_ON(!system_capabilities_finalized());
arm_smccc_1_1_hvc(KVM_HOST_SMCCC_FUNC(__kvm_hyp_init),
- pgd_ptr, tpidr_el2, hyp_stack_ptr, vector_ptr, &res);
+ pgd_ptr, tpidr_el2, hyp_stack_ptr, &res);
WARN_ON(res.a0 != SMCCC_RET_SUCCESS);
/*
diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-init.S b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
index 17b58dbc3a2f..b3492a3c4232 100644
--- a/arch/arm64/kvm/hyp/nvhe/hyp-init.S
+++ b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
@@ -50,7 +50,6 @@ __invalid:
* x1: HYP pgd
* x2: per-CPU offset
* x3: HYP stack
- * x4: HYP vectors
*/
__do_hyp_init:
/* Check for a stub HVC call */
@@ -134,9 +133,13 @@ alternative_else_nop_endif
msr sctlr_el2, x0
isb
- /* Set the stack and new vectors */
+ /* Set the stack */
mov sp, x3
- msr vbar_el2, x4
+
+ /* Set the host vector */
+ ldr x0, =__kvm_hyp_host_vector
+ kimg_hyp_va x0, x1
+ msr vbar_el2, x0
/* Hello, World! */
mov x0, #SMCCC_RET_SUCCESS
--
2.29.2.454.gaff20da3a2-goog
^ permalink raw reply related [flat|nested] 147+ messages in thread* [PATCH v3 08/23] kvm: arm64: Remove vector_ptr param of hyp-init
@ 2020-11-26 15:54 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Mark Rutland, Lorenzo Pieralisi, kernel-team, Jonathan Corbet,
Catalin Marinas, Suzuki K Poulose, linux-doc, linux-kernel,
Sudeep Holla, James Morse, linux-arm-kernel, Marc Zyngier,
Tejun Heo, Dennis Zhou, Christoph Lameter, David Brazdil,
Will Deacon, Julien Thierry
KVM precomputes the hyp VA of __kvm_hyp_host_vector, essentially a
constant (minus ASLR), before passing it to __kvm_hyp_init.
Now that we have alternatives for converting kimg VA to hyp VA, replace
this with computing the constant inside __kvm_hyp_init, thus removing
the need for an argument.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
arch/arm64/include/asm/kvm_asm.h | 2 --
arch/arm64/include/asm/kvm_mmu.h | 26 +++++++++++++++++++++++++-
arch/arm64/kvm/arm.c | 4 +---
arch/arm64/kvm/hyp/nvhe/hyp-init.S | 9 ++++++---
4 files changed, 32 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
index 4a6a77d8d13e..531f9d04eefd 100644
--- a/arch/arm64/include/asm/kvm_asm.h
+++ b/arch/arm64/include/asm/kvm_asm.h
@@ -163,10 +163,8 @@ struct kvm_vcpu;
struct kvm_s2_mmu;
DECLARE_KVM_NVHE_SYM(__kvm_hyp_init);
-DECLARE_KVM_NVHE_SYM(__kvm_hyp_host_vector);
DECLARE_KVM_HYP_SYM(__kvm_hyp_vector);
#define __kvm_hyp_init CHOOSE_NVHE_SYM(__kvm_hyp_init)
-#define __kvm_hyp_host_vector CHOOSE_NVHE_SYM(__kvm_hyp_host_vector)
#define __kvm_hyp_vector CHOOSE_HYP_SYM(__kvm_hyp_vector)
extern unsigned long kvm_arm_hyp_percpu_base[NR_CPUS];
diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
index 5168a0c516ae..6945faeb68ac 100644
--- a/arch/arm64/include/asm/kvm_mmu.h
+++ b/arch/arm64/include/asm/kvm_mmu.h
@@ -93,7 +93,31 @@ alternative_cb_end
/* reg = __pa(reg) */
sub \reg, \reg, \tmp
.endm
-
+
+/*
+ * Convert a kernel image address to a hyp VA
+ * reg: kernel address to be converted in place
+ * tmp: temporary register
+ *
+ * The actual code generation takes place in kvm_get_kimage_voffset, and
+ * the instructions below are only there to reserve the space and
+ * perform the register allocation (kvm_get_kimage_voffset uses the
+ * specific registers encoded in the instructions).
+ */
+.macro kimg_hyp_va reg, tmp
+alternative_cb kvm_update_kimg_phys_offset
+ movz \tmp, #0
+ movk \tmp, #0, lsl #16
+ movk \tmp, #0, lsl #32
+ movk \tmp, #0, lsl #48
+alternative_cb_end
+
+ sub \reg, \reg, \tmp
+ mov_q \tmp, PAGE_OFFSET
+ orr \reg, \reg, \tmp
+ kern_hyp_va \reg
+.endm
+
#else
#include <linux/pgtable.h>
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index b25035dc0478..cd6e5dec203f 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -1355,7 +1355,6 @@ static void cpu_init_hyp_mode(void)
{
phys_addr_t pgd_ptr;
unsigned long hyp_stack_ptr;
- unsigned long vector_ptr;
unsigned long tpidr_el2;
struct arm_smccc_res res;
@@ -1373,7 +1372,6 @@ static void cpu_init_hyp_mode(void)
pgd_ptr = kvm_mmu_get_httbr();
hyp_stack_ptr = __this_cpu_read(kvm_arm_hyp_stack_page) + PAGE_SIZE;
hyp_stack_ptr = kern_hyp_va(hyp_stack_ptr);
- vector_ptr = (unsigned long)kern_hyp_va(kvm_ksym_ref(__kvm_hyp_host_vector));
/*
* Call initialization code, and switch to the full blown HYP code.
@@ -1383,7 +1381,7 @@ static void cpu_init_hyp_mode(void)
*/
BUG_ON(!system_capabilities_finalized());
arm_smccc_1_1_hvc(KVM_HOST_SMCCC_FUNC(__kvm_hyp_init),
- pgd_ptr, tpidr_el2, hyp_stack_ptr, vector_ptr, &res);
+ pgd_ptr, tpidr_el2, hyp_stack_ptr, &res);
WARN_ON(res.a0 != SMCCC_RET_SUCCESS);
/*
diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-init.S b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
index 17b58dbc3a2f..b3492a3c4232 100644
--- a/arch/arm64/kvm/hyp/nvhe/hyp-init.S
+++ b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
@@ -50,7 +50,6 @@ __invalid:
* x1: HYP pgd
* x2: per-CPU offset
* x3: HYP stack
- * x4: HYP vectors
*/
__do_hyp_init:
/* Check for a stub HVC call */
@@ -134,9 +133,13 @@ alternative_else_nop_endif
msr sctlr_el2, x0
isb
- /* Set the stack and new vectors */
+ /* Set the stack */
mov sp, x3
- msr vbar_el2, x4
+
+ /* Set the host vector */
+ ldr x0, =__kvm_hyp_host_vector
+ kimg_hyp_va x0, x1
+ msr vbar_el2, x0
/* Hello, World! */
mov x0, #SMCCC_RET_SUCCESS
--
2.29.2.454.gaff20da3a2-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 147+ messages in thread* [PATCH v3 08/23] kvm: arm64: Remove vector_ptr param of hyp-init
@ 2020-11-26 15:54 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Lorenzo Pieralisi, kernel-team, Jonathan Corbet, Catalin Marinas,
linux-doc, linux-kernel, Sudeep Holla, linux-arm-kernel,
Marc Zyngier, Tejun Heo, Dennis Zhou, Christoph Lameter,
Will Deacon
KVM precomputes the hyp VA of __kvm_hyp_host_vector, essentially a
constant (minus ASLR), before passing it to __kvm_hyp_init.
Now that we have alternatives for converting kimg VA to hyp VA, replace
this with computing the constant inside __kvm_hyp_init, thus removing
the need for an argument.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
arch/arm64/include/asm/kvm_asm.h | 2 --
arch/arm64/include/asm/kvm_mmu.h | 26 +++++++++++++++++++++++++-
arch/arm64/kvm/arm.c | 4 +---
arch/arm64/kvm/hyp/nvhe/hyp-init.S | 9 ++++++---
4 files changed, 32 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
index 4a6a77d8d13e..531f9d04eefd 100644
--- a/arch/arm64/include/asm/kvm_asm.h
+++ b/arch/arm64/include/asm/kvm_asm.h
@@ -163,10 +163,8 @@ struct kvm_vcpu;
struct kvm_s2_mmu;
DECLARE_KVM_NVHE_SYM(__kvm_hyp_init);
-DECLARE_KVM_NVHE_SYM(__kvm_hyp_host_vector);
DECLARE_KVM_HYP_SYM(__kvm_hyp_vector);
#define __kvm_hyp_init CHOOSE_NVHE_SYM(__kvm_hyp_init)
-#define __kvm_hyp_host_vector CHOOSE_NVHE_SYM(__kvm_hyp_host_vector)
#define __kvm_hyp_vector CHOOSE_HYP_SYM(__kvm_hyp_vector)
extern unsigned long kvm_arm_hyp_percpu_base[NR_CPUS];
diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
index 5168a0c516ae..6945faeb68ac 100644
--- a/arch/arm64/include/asm/kvm_mmu.h
+++ b/arch/arm64/include/asm/kvm_mmu.h
@@ -93,7 +93,31 @@ alternative_cb_end
/* reg = __pa(reg) */
sub \reg, \reg, \tmp
.endm
-
+
+/*
+ * Convert a kernel image address to a hyp VA
+ * reg: kernel address to be converted in place
+ * tmp: temporary register
+ *
+ * The actual code generation takes place in kvm_get_kimage_voffset, and
+ * the instructions below are only there to reserve the space and
+ * perform the register allocation (kvm_get_kimage_voffset uses the
+ * specific registers encoded in the instructions).
+ */
+.macro kimg_hyp_va reg, tmp
+alternative_cb kvm_update_kimg_phys_offset
+ movz \tmp, #0
+ movk \tmp, #0, lsl #16
+ movk \tmp, #0, lsl #32
+ movk \tmp, #0, lsl #48
+alternative_cb_end
+
+ sub \reg, \reg, \tmp
+ mov_q \tmp, PAGE_OFFSET
+ orr \reg, \reg, \tmp
+ kern_hyp_va \reg
+.endm
+
#else
#include <linux/pgtable.h>
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index b25035dc0478..cd6e5dec203f 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -1355,7 +1355,6 @@ static void cpu_init_hyp_mode(void)
{
phys_addr_t pgd_ptr;
unsigned long hyp_stack_ptr;
- unsigned long vector_ptr;
unsigned long tpidr_el2;
struct arm_smccc_res res;
@@ -1373,7 +1372,6 @@ static void cpu_init_hyp_mode(void)
pgd_ptr = kvm_mmu_get_httbr();
hyp_stack_ptr = __this_cpu_read(kvm_arm_hyp_stack_page) + PAGE_SIZE;
hyp_stack_ptr = kern_hyp_va(hyp_stack_ptr);
- vector_ptr = (unsigned long)kern_hyp_va(kvm_ksym_ref(__kvm_hyp_host_vector));
/*
* Call initialization code, and switch to the full blown HYP code.
@@ -1383,7 +1381,7 @@ static void cpu_init_hyp_mode(void)
*/
BUG_ON(!system_capabilities_finalized());
arm_smccc_1_1_hvc(KVM_HOST_SMCCC_FUNC(__kvm_hyp_init),
- pgd_ptr, tpidr_el2, hyp_stack_ptr, vector_ptr, &res);
+ pgd_ptr, tpidr_el2, hyp_stack_ptr, &res);
WARN_ON(res.a0 != SMCCC_RET_SUCCESS);
/*
diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-init.S b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
index 17b58dbc3a2f..b3492a3c4232 100644
--- a/arch/arm64/kvm/hyp/nvhe/hyp-init.S
+++ b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
@@ -50,7 +50,6 @@ __invalid:
* x1: HYP pgd
* x2: per-CPU offset
* x3: HYP stack
- * x4: HYP vectors
*/
__do_hyp_init:
/* Check for a stub HVC call */
@@ -134,9 +133,13 @@ alternative_else_nop_endif
msr sctlr_el2, x0
isb
- /* Set the stack and new vectors */
+ /* Set the stack */
mov sp, x3
- msr vbar_el2, x4
+
+ /* Set the host vector */
+ ldr x0, =__kvm_hyp_host_vector
+ kimg_hyp_va x0, x1
+ msr vbar_el2, x0
/* Hello, World! */
mov x0, #SMCCC_RET_SUCCESS
--
2.29.2.454.gaff20da3a2-goog
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply related [flat|nested] 147+ messages in thread
* [PATCH v3 09/23] kvm: arm64: Move hyp-init params to a per-CPU struct
2020-11-26 15:53 ` David Brazdil
(?)
@ 2020-11-26 15:54 ` David Brazdil
-1 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Jonathan Corbet, Catalin Marinas, Will Deacon, Marc Zyngier,
James Morse, Julien Thierry, Suzuki K Poulose, Dennis Zhou,
Tejun Heo, Christoph Lameter, Mark Rutland, Lorenzo Pieralisi,
Sudeep Holla, linux-doc, linux-kernel, linux-arm-kernel,
kernel-team, David Brazdil
Once we start initializing KVM on newly booted cores before the rest of
the kernel, parameters to __do_hyp_init will need to be provided by EL2
rather than EL1. At that point it will not be possible to pass its three
arguments directly because PSCI_CPU_ON only supports one context
argument.
Refactor __do_hyp_init to accept its parameters in a struct. This
prepares the code for KVM booting cores as well as removes any limits on
the number of __do_hyp_init arguments.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
arch/arm64/include/asm/kvm_asm.h | 6 ++++++
arch/arm64/include/asm/kvm_hyp.h | 2 +-
arch/arm64/kernel/asm-offsets.c | 3 +++
arch/arm64/kvm/arm.c | 23 +++++++++++++----------
arch/arm64/kvm/hyp/nvhe/hyp-init.S | 16 +++++++---------
arch/arm64/kvm/hyp/nvhe/hyp-main.c | 2 ++
6 files changed, 32 insertions(+), 20 deletions(-)
diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
index 531f9d04eefd..1a7b91534a16 100644
--- a/arch/arm64/include/asm/kvm_asm.h
+++ b/arch/arm64/include/asm/kvm_asm.h
@@ -148,6 +148,12 @@ extern void *__vhe_undefined_symbol;
#endif
+struct kvm_nvhe_init_params {
+ unsigned long tpidr_el2;
+ unsigned long stack_hyp_va;
+ phys_addr_t pgd_pa;
+};
+
/* Translate a kernel address @ptr into its equivalent linear mapping */
#define kvm_ksym_ref(ptr) \
({ \
diff --git a/arch/arm64/include/asm/kvm_hyp.h b/arch/arm64/include/asm/kvm_hyp.h
index 6b664de5ec1f..cb25c15e3d8d 100644
--- a/arch/arm64/include/asm/kvm_hyp.h
+++ b/arch/arm64/include/asm/kvm_hyp.h
@@ -14,6 +14,7 @@
DECLARE_PER_CPU(struct kvm_cpu_context, kvm_hyp_ctxt);
DECLARE_PER_CPU(unsigned long, kvm_hyp_vector);
+DECLARE_PER_CPU(struct kvm_nvhe_init_params, kvm_init_params);
#define read_sysreg_elx(r,nvh,vh) \
({ \
@@ -98,4 +99,3 @@ void __noreturn __hyp_do_panic(bool restore_host, u64 spsr, u64 elr, u64 par);
#endif
#endif /* __ARM64_KVM_HYP_H__ */
-
diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
index 7d32fc959b1a..8d6272a01a00 100644
--- a/arch/arm64/kernel/asm-offsets.c
+++ b/arch/arm64/kernel/asm-offsets.c
@@ -110,6 +110,9 @@ int main(void)
DEFINE(CPU_APGAKEYLO_EL1, offsetof(struct kvm_cpu_context, sys_regs[APGAKEYLO_EL1]));
DEFINE(HOST_CONTEXT_VCPU, offsetof(struct kvm_cpu_context, __hyp_running_vcpu));
DEFINE(HOST_DATA_CONTEXT, offsetof(struct kvm_host_data, host_ctxt));
+ DEFINE(NVHE_INIT_TPIDR_EL2, offsetof(struct kvm_nvhe_init_params, tpidr_el2));
+ DEFINE(NVHE_INIT_STACK_HYP_VA, offsetof(struct kvm_nvhe_init_params, stack_hyp_va));
+ DEFINE(NVHE_INIT_PGD_PA, offsetof(struct kvm_nvhe_init_params, pgd_pa));
#endif
#ifdef CONFIG_CPU_PM
DEFINE(CPU_CTX_SP, offsetof(struct cpu_suspend_ctx, sp));
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index cd6e5dec203f..7b718c6c6c52 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -49,6 +49,7 @@ DECLARE_KVM_HYP_PER_CPU(unsigned long, kvm_hyp_vector);
static DEFINE_PER_CPU(unsigned long, kvm_arm_hyp_stack_page);
unsigned long kvm_arm_hyp_percpu_base[NR_CPUS];
+DECLARE_KVM_NVHE_PER_CPU(struct kvm_nvhe_init_params, kvm_init_params);
/* The VMID used in the VTTBR */
static atomic64_t kvm_vmid_gen = ATOMIC64_INIT(1);
@@ -1353,9 +1354,7 @@ static int kvm_init_vector_slots(void)
static void cpu_init_hyp_mode(void)
{
- phys_addr_t pgd_ptr;
- unsigned long hyp_stack_ptr;
- unsigned long tpidr_el2;
+ struct kvm_nvhe_init_params *params = this_cpu_ptr_nvhe_sym(kvm_init_params);
struct arm_smccc_res res;
/* Switch from the HYP stub to our own HYP init vector */
@@ -1366,12 +1365,17 @@ static void cpu_init_hyp_mode(void)
* kernel's mapping to the linear mapping, and store it in tpidr_el2
* so that we can use adr_l to access per-cpu variables in EL2.
*/
- tpidr_el2 = (unsigned long)this_cpu_ptr_nvhe_sym(__per_cpu_start) -
- (unsigned long)kvm_ksym_ref(CHOOSE_NVHE_SYM(__per_cpu_start));
+ params->tpidr_el2 = (unsigned long)this_cpu_ptr_nvhe_sym(__per_cpu_start) -
+ (unsigned long)kvm_ksym_ref(CHOOSE_NVHE_SYM(__per_cpu_start));
- pgd_ptr = kvm_mmu_get_httbr();
- hyp_stack_ptr = __this_cpu_read(kvm_arm_hyp_stack_page) + PAGE_SIZE;
- hyp_stack_ptr = kern_hyp_va(hyp_stack_ptr);
+ params->stack_hyp_va = kern_hyp_va(__this_cpu_read(kvm_arm_hyp_stack_page) + PAGE_SIZE);
+ params->pgd_pa = kvm_mmu_get_httbr();
+
+ /*
+ * Flush the init params from the data cache because the struct will
+ * be read while the MMU is off.
+ */
+ kvm_flush_dcache_to_poc(params, sizeof(*params));
/*
* Call initialization code, and switch to the full blown HYP code.
@@ -1380,8 +1384,7 @@ static void cpu_init_hyp_mode(void)
* cpus_have_const_cap() wrapper.
*/
BUG_ON(!system_capabilities_finalized());
- arm_smccc_1_1_hvc(KVM_HOST_SMCCC_FUNC(__kvm_hyp_init),
- pgd_ptr, tpidr_el2, hyp_stack_ptr, &res);
+ arm_smccc_1_1_hvc(KVM_HOST_SMCCC_FUNC(__kvm_hyp_init), virt_to_phys(params), &res);
WARN_ON(res.a0 != SMCCC_RET_SUCCESS);
/*
diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-init.S b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
index b3492a3c4232..77c983aa90fa 100644
--- a/arch/arm64/kvm/hyp/nvhe/hyp-init.S
+++ b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
@@ -47,9 +47,7 @@ __invalid:
/*
* x0: SMCCC function ID
- * x1: HYP pgd
- * x2: per-CPU offset
- * x3: HYP stack
+ * x1: struct kvm_nvhe_init_params PA
*/
__do_hyp_init:
/* Check for a stub HVC call */
@@ -70,10 +68,13 @@ __do_hyp_init:
mov x0, #SMCCC_RET_NOT_SUPPORTED
eret
-1:
- /* Set tpidr_el2 for use by HYP to free a register */
- msr tpidr_el2, x2
+1: ldr x0, [x1, #NVHE_INIT_TPIDR_EL2]
+ msr tpidr_el2, x0
+ ldr x0, [x1, #NVHE_INIT_STACK_HYP_VA]
+ mov sp, x0
+
+ ldr x1, [x1, #NVHE_INIT_PGD_PA]
phys_to_ttbr x0, x1
alternative_if ARM64_HAS_CNP
orr x0, x0, #TTBR_CNP_BIT
@@ -133,9 +134,6 @@ alternative_else_nop_endif
msr sctlr_el2, x0
isb
- /* Set the stack */
- mov sp, x3
-
/* Set the host vector */
ldr x0, =__kvm_hyp_host_vector
kimg_hyp_va x0, x1
diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
index 82df7fc24760..a4f1cac714d7 100644
--- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
+++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
@@ -16,6 +16,8 @@
#define DECLARE_REG(type, name, ctxt, reg) \
type name = (type)cpu_reg(ctxt, (reg))
+DEFINE_PER_CPU(struct kvm_nvhe_init_params, kvm_init_params);
+
static void handle___kvm_vcpu_run(struct kvm_cpu_context *host_ctxt)
{
DECLARE_REG(struct kvm_vcpu *, vcpu, host_ctxt, 1);
--
2.29.2.454.gaff20da3a2-goog
^ permalink raw reply related [flat|nested] 147+ messages in thread* [PATCH v3 09/23] kvm: arm64: Move hyp-init params to a per-CPU struct
@ 2020-11-26 15:54 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Mark Rutland, Lorenzo Pieralisi, kernel-team, Jonathan Corbet,
Catalin Marinas, Suzuki K Poulose, linux-doc, linux-kernel,
Sudeep Holla, James Morse, linux-arm-kernel, Marc Zyngier,
Tejun Heo, Dennis Zhou, Christoph Lameter, David Brazdil,
Will Deacon, Julien Thierry
Once we start initializing KVM on newly booted cores before the rest of
the kernel, parameters to __do_hyp_init will need to be provided by EL2
rather than EL1. At that point it will not be possible to pass its three
arguments directly because PSCI_CPU_ON only supports one context
argument.
Refactor __do_hyp_init to accept its parameters in a struct. This
prepares the code for KVM booting cores as well as removes any limits on
the number of __do_hyp_init arguments.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
arch/arm64/include/asm/kvm_asm.h | 6 ++++++
arch/arm64/include/asm/kvm_hyp.h | 2 +-
arch/arm64/kernel/asm-offsets.c | 3 +++
arch/arm64/kvm/arm.c | 23 +++++++++++++----------
arch/arm64/kvm/hyp/nvhe/hyp-init.S | 16 +++++++---------
arch/arm64/kvm/hyp/nvhe/hyp-main.c | 2 ++
6 files changed, 32 insertions(+), 20 deletions(-)
diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
index 531f9d04eefd..1a7b91534a16 100644
--- a/arch/arm64/include/asm/kvm_asm.h
+++ b/arch/arm64/include/asm/kvm_asm.h
@@ -148,6 +148,12 @@ extern void *__vhe_undefined_symbol;
#endif
+struct kvm_nvhe_init_params {
+ unsigned long tpidr_el2;
+ unsigned long stack_hyp_va;
+ phys_addr_t pgd_pa;
+};
+
/* Translate a kernel address @ptr into its equivalent linear mapping */
#define kvm_ksym_ref(ptr) \
({ \
diff --git a/arch/arm64/include/asm/kvm_hyp.h b/arch/arm64/include/asm/kvm_hyp.h
index 6b664de5ec1f..cb25c15e3d8d 100644
--- a/arch/arm64/include/asm/kvm_hyp.h
+++ b/arch/arm64/include/asm/kvm_hyp.h
@@ -14,6 +14,7 @@
DECLARE_PER_CPU(struct kvm_cpu_context, kvm_hyp_ctxt);
DECLARE_PER_CPU(unsigned long, kvm_hyp_vector);
+DECLARE_PER_CPU(struct kvm_nvhe_init_params, kvm_init_params);
#define read_sysreg_elx(r,nvh,vh) \
({ \
@@ -98,4 +99,3 @@ void __noreturn __hyp_do_panic(bool restore_host, u64 spsr, u64 elr, u64 par);
#endif
#endif /* __ARM64_KVM_HYP_H__ */
-
diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
index 7d32fc959b1a..8d6272a01a00 100644
--- a/arch/arm64/kernel/asm-offsets.c
+++ b/arch/arm64/kernel/asm-offsets.c
@@ -110,6 +110,9 @@ int main(void)
DEFINE(CPU_APGAKEYLO_EL1, offsetof(struct kvm_cpu_context, sys_regs[APGAKEYLO_EL1]));
DEFINE(HOST_CONTEXT_VCPU, offsetof(struct kvm_cpu_context, __hyp_running_vcpu));
DEFINE(HOST_DATA_CONTEXT, offsetof(struct kvm_host_data, host_ctxt));
+ DEFINE(NVHE_INIT_TPIDR_EL2, offsetof(struct kvm_nvhe_init_params, tpidr_el2));
+ DEFINE(NVHE_INIT_STACK_HYP_VA, offsetof(struct kvm_nvhe_init_params, stack_hyp_va));
+ DEFINE(NVHE_INIT_PGD_PA, offsetof(struct kvm_nvhe_init_params, pgd_pa));
#endif
#ifdef CONFIG_CPU_PM
DEFINE(CPU_CTX_SP, offsetof(struct cpu_suspend_ctx, sp));
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index cd6e5dec203f..7b718c6c6c52 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -49,6 +49,7 @@ DECLARE_KVM_HYP_PER_CPU(unsigned long, kvm_hyp_vector);
static DEFINE_PER_CPU(unsigned long, kvm_arm_hyp_stack_page);
unsigned long kvm_arm_hyp_percpu_base[NR_CPUS];
+DECLARE_KVM_NVHE_PER_CPU(struct kvm_nvhe_init_params, kvm_init_params);
/* The VMID used in the VTTBR */
static atomic64_t kvm_vmid_gen = ATOMIC64_INIT(1);
@@ -1353,9 +1354,7 @@ static int kvm_init_vector_slots(void)
static void cpu_init_hyp_mode(void)
{
- phys_addr_t pgd_ptr;
- unsigned long hyp_stack_ptr;
- unsigned long tpidr_el2;
+ struct kvm_nvhe_init_params *params = this_cpu_ptr_nvhe_sym(kvm_init_params);
struct arm_smccc_res res;
/* Switch from the HYP stub to our own HYP init vector */
@@ -1366,12 +1365,17 @@ static void cpu_init_hyp_mode(void)
* kernel's mapping to the linear mapping, and store it in tpidr_el2
* so that we can use adr_l to access per-cpu variables in EL2.
*/
- tpidr_el2 = (unsigned long)this_cpu_ptr_nvhe_sym(__per_cpu_start) -
- (unsigned long)kvm_ksym_ref(CHOOSE_NVHE_SYM(__per_cpu_start));
+ params->tpidr_el2 = (unsigned long)this_cpu_ptr_nvhe_sym(__per_cpu_start) -
+ (unsigned long)kvm_ksym_ref(CHOOSE_NVHE_SYM(__per_cpu_start));
- pgd_ptr = kvm_mmu_get_httbr();
- hyp_stack_ptr = __this_cpu_read(kvm_arm_hyp_stack_page) + PAGE_SIZE;
- hyp_stack_ptr = kern_hyp_va(hyp_stack_ptr);
+ params->stack_hyp_va = kern_hyp_va(__this_cpu_read(kvm_arm_hyp_stack_page) + PAGE_SIZE);
+ params->pgd_pa = kvm_mmu_get_httbr();
+
+ /*
+ * Flush the init params from the data cache because the struct will
+ * be read while the MMU is off.
+ */
+ kvm_flush_dcache_to_poc(params, sizeof(*params));
/*
* Call initialization code, and switch to the full blown HYP code.
@@ -1380,8 +1384,7 @@ static void cpu_init_hyp_mode(void)
* cpus_have_const_cap() wrapper.
*/
BUG_ON(!system_capabilities_finalized());
- arm_smccc_1_1_hvc(KVM_HOST_SMCCC_FUNC(__kvm_hyp_init),
- pgd_ptr, tpidr_el2, hyp_stack_ptr, &res);
+ arm_smccc_1_1_hvc(KVM_HOST_SMCCC_FUNC(__kvm_hyp_init), virt_to_phys(params), &res);
WARN_ON(res.a0 != SMCCC_RET_SUCCESS);
/*
diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-init.S b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
index b3492a3c4232..77c983aa90fa 100644
--- a/arch/arm64/kvm/hyp/nvhe/hyp-init.S
+++ b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
@@ -47,9 +47,7 @@ __invalid:
/*
* x0: SMCCC function ID
- * x1: HYP pgd
- * x2: per-CPU offset
- * x3: HYP stack
+ * x1: struct kvm_nvhe_init_params PA
*/
__do_hyp_init:
/* Check for a stub HVC call */
@@ -70,10 +68,13 @@ __do_hyp_init:
mov x0, #SMCCC_RET_NOT_SUPPORTED
eret
-1:
- /* Set tpidr_el2 for use by HYP to free a register */
- msr tpidr_el2, x2
+1: ldr x0, [x1, #NVHE_INIT_TPIDR_EL2]
+ msr tpidr_el2, x0
+ ldr x0, [x1, #NVHE_INIT_STACK_HYP_VA]
+ mov sp, x0
+
+ ldr x1, [x1, #NVHE_INIT_PGD_PA]
phys_to_ttbr x0, x1
alternative_if ARM64_HAS_CNP
orr x0, x0, #TTBR_CNP_BIT
@@ -133,9 +134,6 @@ alternative_else_nop_endif
msr sctlr_el2, x0
isb
- /* Set the stack */
- mov sp, x3
-
/* Set the host vector */
ldr x0, =__kvm_hyp_host_vector
kimg_hyp_va x0, x1
diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
index 82df7fc24760..a4f1cac714d7 100644
--- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
+++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
@@ -16,6 +16,8 @@
#define DECLARE_REG(type, name, ctxt, reg) \
type name = (type)cpu_reg(ctxt, (reg))
+DEFINE_PER_CPU(struct kvm_nvhe_init_params, kvm_init_params);
+
static void handle___kvm_vcpu_run(struct kvm_cpu_context *host_ctxt)
{
DECLARE_REG(struct kvm_vcpu *, vcpu, host_ctxt, 1);
--
2.29.2.454.gaff20da3a2-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 147+ messages in thread* [PATCH v3 09/23] kvm: arm64: Move hyp-init params to a per-CPU struct
@ 2020-11-26 15:54 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Lorenzo Pieralisi, kernel-team, Jonathan Corbet, Catalin Marinas,
linux-doc, linux-kernel, Sudeep Holla, linux-arm-kernel,
Marc Zyngier, Tejun Heo, Dennis Zhou, Christoph Lameter,
Will Deacon
Once we start initializing KVM on newly booted cores before the rest of
the kernel, parameters to __do_hyp_init will need to be provided by EL2
rather than EL1. At that point it will not be possible to pass its three
arguments directly because PSCI_CPU_ON only supports one context
argument.
Refactor __do_hyp_init to accept its parameters in a struct. This
prepares the code for KVM booting cores as well as removes any limits on
the number of __do_hyp_init arguments.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
arch/arm64/include/asm/kvm_asm.h | 6 ++++++
arch/arm64/include/asm/kvm_hyp.h | 2 +-
arch/arm64/kernel/asm-offsets.c | 3 +++
arch/arm64/kvm/arm.c | 23 +++++++++++++----------
arch/arm64/kvm/hyp/nvhe/hyp-init.S | 16 +++++++---------
arch/arm64/kvm/hyp/nvhe/hyp-main.c | 2 ++
6 files changed, 32 insertions(+), 20 deletions(-)
diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
index 531f9d04eefd..1a7b91534a16 100644
--- a/arch/arm64/include/asm/kvm_asm.h
+++ b/arch/arm64/include/asm/kvm_asm.h
@@ -148,6 +148,12 @@ extern void *__vhe_undefined_symbol;
#endif
+struct kvm_nvhe_init_params {
+ unsigned long tpidr_el2;
+ unsigned long stack_hyp_va;
+ phys_addr_t pgd_pa;
+};
+
/* Translate a kernel address @ptr into its equivalent linear mapping */
#define kvm_ksym_ref(ptr) \
({ \
diff --git a/arch/arm64/include/asm/kvm_hyp.h b/arch/arm64/include/asm/kvm_hyp.h
index 6b664de5ec1f..cb25c15e3d8d 100644
--- a/arch/arm64/include/asm/kvm_hyp.h
+++ b/arch/arm64/include/asm/kvm_hyp.h
@@ -14,6 +14,7 @@
DECLARE_PER_CPU(struct kvm_cpu_context, kvm_hyp_ctxt);
DECLARE_PER_CPU(unsigned long, kvm_hyp_vector);
+DECLARE_PER_CPU(struct kvm_nvhe_init_params, kvm_init_params);
#define read_sysreg_elx(r,nvh,vh) \
({ \
@@ -98,4 +99,3 @@ void __noreturn __hyp_do_panic(bool restore_host, u64 spsr, u64 elr, u64 par);
#endif
#endif /* __ARM64_KVM_HYP_H__ */
-
diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
index 7d32fc959b1a..8d6272a01a00 100644
--- a/arch/arm64/kernel/asm-offsets.c
+++ b/arch/arm64/kernel/asm-offsets.c
@@ -110,6 +110,9 @@ int main(void)
DEFINE(CPU_APGAKEYLO_EL1, offsetof(struct kvm_cpu_context, sys_regs[APGAKEYLO_EL1]));
DEFINE(HOST_CONTEXT_VCPU, offsetof(struct kvm_cpu_context, __hyp_running_vcpu));
DEFINE(HOST_DATA_CONTEXT, offsetof(struct kvm_host_data, host_ctxt));
+ DEFINE(NVHE_INIT_TPIDR_EL2, offsetof(struct kvm_nvhe_init_params, tpidr_el2));
+ DEFINE(NVHE_INIT_STACK_HYP_VA, offsetof(struct kvm_nvhe_init_params, stack_hyp_va));
+ DEFINE(NVHE_INIT_PGD_PA, offsetof(struct kvm_nvhe_init_params, pgd_pa));
#endif
#ifdef CONFIG_CPU_PM
DEFINE(CPU_CTX_SP, offsetof(struct cpu_suspend_ctx, sp));
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index cd6e5dec203f..7b718c6c6c52 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -49,6 +49,7 @@ DECLARE_KVM_HYP_PER_CPU(unsigned long, kvm_hyp_vector);
static DEFINE_PER_CPU(unsigned long, kvm_arm_hyp_stack_page);
unsigned long kvm_arm_hyp_percpu_base[NR_CPUS];
+DECLARE_KVM_NVHE_PER_CPU(struct kvm_nvhe_init_params, kvm_init_params);
/* The VMID used in the VTTBR */
static atomic64_t kvm_vmid_gen = ATOMIC64_INIT(1);
@@ -1353,9 +1354,7 @@ static int kvm_init_vector_slots(void)
static void cpu_init_hyp_mode(void)
{
- phys_addr_t pgd_ptr;
- unsigned long hyp_stack_ptr;
- unsigned long tpidr_el2;
+ struct kvm_nvhe_init_params *params = this_cpu_ptr_nvhe_sym(kvm_init_params);
struct arm_smccc_res res;
/* Switch from the HYP stub to our own HYP init vector */
@@ -1366,12 +1365,17 @@ static void cpu_init_hyp_mode(void)
* kernel's mapping to the linear mapping, and store it in tpidr_el2
* so that we can use adr_l to access per-cpu variables in EL2.
*/
- tpidr_el2 = (unsigned long)this_cpu_ptr_nvhe_sym(__per_cpu_start) -
- (unsigned long)kvm_ksym_ref(CHOOSE_NVHE_SYM(__per_cpu_start));
+ params->tpidr_el2 = (unsigned long)this_cpu_ptr_nvhe_sym(__per_cpu_start) -
+ (unsigned long)kvm_ksym_ref(CHOOSE_NVHE_SYM(__per_cpu_start));
- pgd_ptr = kvm_mmu_get_httbr();
- hyp_stack_ptr = __this_cpu_read(kvm_arm_hyp_stack_page) + PAGE_SIZE;
- hyp_stack_ptr = kern_hyp_va(hyp_stack_ptr);
+ params->stack_hyp_va = kern_hyp_va(__this_cpu_read(kvm_arm_hyp_stack_page) + PAGE_SIZE);
+ params->pgd_pa = kvm_mmu_get_httbr();
+
+ /*
+ * Flush the init params from the data cache because the struct will
+ * be read while the MMU is off.
+ */
+ kvm_flush_dcache_to_poc(params, sizeof(*params));
/*
* Call initialization code, and switch to the full blown HYP code.
@@ -1380,8 +1384,7 @@ static void cpu_init_hyp_mode(void)
* cpus_have_const_cap() wrapper.
*/
BUG_ON(!system_capabilities_finalized());
- arm_smccc_1_1_hvc(KVM_HOST_SMCCC_FUNC(__kvm_hyp_init),
- pgd_ptr, tpidr_el2, hyp_stack_ptr, &res);
+ arm_smccc_1_1_hvc(KVM_HOST_SMCCC_FUNC(__kvm_hyp_init), virt_to_phys(params), &res);
WARN_ON(res.a0 != SMCCC_RET_SUCCESS);
/*
diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-init.S b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
index b3492a3c4232..77c983aa90fa 100644
--- a/arch/arm64/kvm/hyp/nvhe/hyp-init.S
+++ b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
@@ -47,9 +47,7 @@ __invalid:
/*
* x0: SMCCC function ID
- * x1: HYP pgd
- * x2: per-CPU offset
- * x3: HYP stack
+ * x1: struct kvm_nvhe_init_params PA
*/
__do_hyp_init:
/* Check for a stub HVC call */
@@ -70,10 +68,13 @@ __do_hyp_init:
mov x0, #SMCCC_RET_NOT_SUPPORTED
eret
-1:
- /* Set tpidr_el2 for use by HYP to free a register */
- msr tpidr_el2, x2
+1: ldr x0, [x1, #NVHE_INIT_TPIDR_EL2]
+ msr tpidr_el2, x0
+ ldr x0, [x1, #NVHE_INIT_STACK_HYP_VA]
+ mov sp, x0
+
+ ldr x1, [x1, #NVHE_INIT_PGD_PA]
phys_to_ttbr x0, x1
alternative_if ARM64_HAS_CNP
orr x0, x0, #TTBR_CNP_BIT
@@ -133,9 +134,6 @@ alternative_else_nop_endif
msr sctlr_el2, x0
isb
- /* Set the stack */
- mov sp, x3
-
/* Set the host vector */
ldr x0, =__kvm_hyp_host_vector
kimg_hyp_va x0, x1
diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
index 82df7fc24760..a4f1cac714d7 100644
--- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
+++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
@@ -16,6 +16,8 @@
#define DECLARE_REG(type, name, ctxt, reg) \
type name = (type)cpu_reg(ctxt, (reg))
+DEFINE_PER_CPU(struct kvm_nvhe_init_params, kvm_init_params);
+
static void handle___kvm_vcpu_run(struct kvm_cpu_context *host_ctxt)
{
DECLARE_REG(struct kvm_vcpu *, vcpu, host_ctxt, 1);
--
2.29.2.454.gaff20da3a2-goog
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply related [flat|nested] 147+ messages in thread
* [PATCH v3 10/23] kvm: arm64: Add .hyp.data..ro_after_init ELF section
2020-11-26 15:53 ` David Brazdil
(?)
@ 2020-11-26 15:54 ` David Brazdil
-1 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Jonathan Corbet, Catalin Marinas, Will Deacon, Marc Zyngier,
James Morse, Julien Thierry, Suzuki K Poulose, Dennis Zhou,
Tejun Heo, Christoph Lameter, Mark Rutland, Lorenzo Pieralisi,
Sudeep Holla, linux-doc, linux-kernel, linux-arm-kernel,
kernel-team, David Brazdil
Add rules for renaming the .data..ro_after_init ELF section in KVM nVHE
object files to .hyp.data..ro_after_init, linking it into the kernel
and mapping it in hyp at runtime.
The section is RW to the host, then mapped RO in hyp. The expectation is
that the host populates the variables in the section and they are never
changed by hyp afterwards.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
arch/arm64/include/asm/sections.h | 1 +
arch/arm64/kernel/vmlinux.lds.S | 10 ++++++++++
arch/arm64/kvm/arm.c | 8 ++++++++
arch/arm64/kvm/hyp/nvhe/hyp.lds.S | 1 +
4 files changed, 20 insertions(+)
diff --git a/arch/arm64/include/asm/sections.h b/arch/arm64/include/asm/sections.h
index 3994169985ef..8ff579361731 100644
--- a/arch/arm64/include/asm/sections.h
+++ b/arch/arm64/include/asm/sections.h
@@ -11,6 +11,7 @@ extern char __alt_instructions[], __alt_instructions_end[];
extern char __hibernate_exit_text_start[], __hibernate_exit_text_end[];
extern char __hyp_idmap_text_start[], __hyp_idmap_text_end[];
extern char __hyp_text_start[], __hyp_text_end[];
+extern char __hyp_data_ro_after_init_start[], __hyp_data_ro_after_init_end[];
extern char __idmap_text_start[], __idmap_text_end[];
extern char __initdata_begin[], __initdata_end[];
extern char __inittext_begin[], __inittext_end[];
diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
index 1bda604f4c70..4382b5d0645d 100644
--- a/arch/arm64/kernel/vmlinux.lds.S
+++ b/arch/arm64/kernel/vmlinux.lds.S
@@ -30,6 +30,13 @@ jiffies = jiffies_64;
*(__kvm_ex_table) \
__stop___kvm_ex_table = .;
+#define HYPERVISOR_DATA_SECTIONS \
+ HYP_SECTION_NAME(.data..ro_after_init) : { \
+ __hyp_data_ro_after_init_start = .; \
+ *(HYP_SECTION_NAME(.data..ro_after_init)) \
+ __hyp_data_ro_after_init_end = .; \
+ }
+
#define HYPERVISOR_PERCPU_SECTION \
. = ALIGN(PAGE_SIZE); \
HYP_SECTION_NAME(.data..percpu) : { \
@@ -37,6 +44,7 @@ jiffies = jiffies_64;
}
#else /* CONFIG_KVM */
#define HYPERVISOR_EXTABLE
+#define HYPERVISOR_DATA_SECTIONS
#define HYPERVISOR_PERCPU_SECTION
#endif
@@ -234,6 +242,8 @@ SECTIONS
_sdata = .;
RW_DATA(L1_CACHE_BYTES, PAGE_SIZE, THREAD_ALIGN)
+ HYPERVISOR_DATA_SECTIONS
+
/*
* Data written with the MMU off but read with the MMU on requires
* cache lines to be invalidated, discarding up to a Cache Writeback
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index 7b718c6c6c52..bb07f0401c68 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -1652,6 +1652,14 @@ static int init_hyp_mode(void)
goto out_err;
}
+ err = create_hyp_mappings(kvm_ksym_ref(__hyp_data_ro_after_init_start),
+ kvm_ksym_ref(__hyp_data_ro_after_init_end),
+ PAGE_HYP_RO);
+ if (err) {
+ kvm_err("Cannot map .hyp.data..ro_after_init section\n");
+ goto out_err;
+ }
+
err = create_hyp_mappings(kvm_ksym_ref(__start_rodata),
kvm_ksym_ref(__end_rodata), PAGE_HYP_RO);
if (err) {
diff --git a/arch/arm64/kvm/hyp/nvhe/hyp.lds.S b/arch/arm64/kvm/hyp/nvhe/hyp.lds.S
index bb2d986ff696..5d76ff2ba63e 100644
--- a/arch/arm64/kvm/hyp/nvhe/hyp.lds.S
+++ b/arch/arm64/kvm/hyp/nvhe/hyp.lds.S
@@ -16,4 +16,5 @@ SECTIONS {
HYP_SECTION_NAME(.data..percpu) : {
PERCPU_INPUT(L1_CACHE_BYTES)
}
+ HYP_SECTION(.data..ro_after_init)
}
--
2.29.2.454.gaff20da3a2-goog
^ permalink raw reply related [flat|nested] 147+ messages in thread* [PATCH v3 10/23] kvm: arm64: Add .hyp.data..ro_after_init ELF section
@ 2020-11-26 15:54 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Mark Rutland, Lorenzo Pieralisi, kernel-team, Jonathan Corbet,
Catalin Marinas, Suzuki K Poulose, linux-doc, linux-kernel,
Sudeep Holla, James Morse, linux-arm-kernel, Marc Zyngier,
Tejun Heo, Dennis Zhou, Christoph Lameter, David Brazdil,
Will Deacon, Julien Thierry
Add rules for renaming the .data..ro_after_init ELF section in KVM nVHE
object files to .hyp.data..ro_after_init, linking it into the kernel
and mapping it in hyp at runtime.
The section is RW to the host, then mapped RO in hyp. The expectation is
that the host populates the variables in the section and they are never
changed by hyp afterwards.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
arch/arm64/include/asm/sections.h | 1 +
arch/arm64/kernel/vmlinux.lds.S | 10 ++++++++++
arch/arm64/kvm/arm.c | 8 ++++++++
arch/arm64/kvm/hyp/nvhe/hyp.lds.S | 1 +
4 files changed, 20 insertions(+)
diff --git a/arch/arm64/include/asm/sections.h b/arch/arm64/include/asm/sections.h
index 3994169985ef..8ff579361731 100644
--- a/arch/arm64/include/asm/sections.h
+++ b/arch/arm64/include/asm/sections.h
@@ -11,6 +11,7 @@ extern char __alt_instructions[], __alt_instructions_end[];
extern char __hibernate_exit_text_start[], __hibernate_exit_text_end[];
extern char __hyp_idmap_text_start[], __hyp_idmap_text_end[];
extern char __hyp_text_start[], __hyp_text_end[];
+extern char __hyp_data_ro_after_init_start[], __hyp_data_ro_after_init_end[];
extern char __idmap_text_start[], __idmap_text_end[];
extern char __initdata_begin[], __initdata_end[];
extern char __inittext_begin[], __inittext_end[];
diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
index 1bda604f4c70..4382b5d0645d 100644
--- a/arch/arm64/kernel/vmlinux.lds.S
+++ b/arch/arm64/kernel/vmlinux.lds.S
@@ -30,6 +30,13 @@ jiffies = jiffies_64;
*(__kvm_ex_table) \
__stop___kvm_ex_table = .;
+#define HYPERVISOR_DATA_SECTIONS \
+ HYP_SECTION_NAME(.data..ro_after_init) : { \
+ __hyp_data_ro_after_init_start = .; \
+ *(HYP_SECTION_NAME(.data..ro_after_init)) \
+ __hyp_data_ro_after_init_end = .; \
+ }
+
#define HYPERVISOR_PERCPU_SECTION \
. = ALIGN(PAGE_SIZE); \
HYP_SECTION_NAME(.data..percpu) : { \
@@ -37,6 +44,7 @@ jiffies = jiffies_64;
}
#else /* CONFIG_KVM */
#define HYPERVISOR_EXTABLE
+#define HYPERVISOR_DATA_SECTIONS
#define HYPERVISOR_PERCPU_SECTION
#endif
@@ -234,6 +242,8 @@ SECTIONS
_sdata = .;
RW_DATA(L1_CACHE_BYTES, PAGE_SIZE, THREAD_ALIGN)
+ HYPERVISOR_DATA_SECTIONS
+
/*
* Data written with the MMU off but read with the MMU on requires
* cache lines to be invalidated, discarding up to a Cache Writeback
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index 7b718c6c6c52..bb07f0401c68 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -1652,6 +1652,14 @@ static int init_hyp_mode(void)
goto out_err;
}
+ err = create_hyp_mappings(kvm_ksym_ref(__hyp_data_ro_after_init_start),
+ kvm_ksym_ref(__hyp_data_ro_after_init_end),
+ PAGE_HYP_RO);
+ if (err) {
+ kvm_err("Cannot map .hyp.data..ro_after_init section\n");
+ goto out_err;
+ }
+
err = create_hyp_mappings(kvm_ksym_ref(__start_rodata),
kvm_ksym_ref(__end_rodata), PAGE_HYP_RO);
if (err) {
diff --git a/arch/arm64/kvm/hyp/nvhe/hyp.lds.S b/arch/arm64/kvm/hyp/nvhe/hyp.lds.S
index bb2d986ff696..5d76ff2ba63e 100644
--- a/arch/arm64/kvm/hyp/nvhe/hyp.lds.S
+++ b/arch/arm64/kvm/hyp/nvhe/hyp.lds.S
@@ -16,4 +16,5 @@ SECTIONS {
HYP_SECTION_NAME(.data..percpu) : {
PERCPU_INPUT(L1_CACHE_BYTES)
}
+ HYP_SECTION(.data..ro_after_init)
}
--
2.29.2.454.gaff20da3a2-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 147+ messages in thread* [PATCH v3 10/23] kvm: arm64: Add .hyp.data..ro_after_init ELF section
@ 2020-11-26 15:54 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Lorenzo Pieralisi, kernel-team, Jonathan Corbet, Catalin Marinas,
linux-doc, linux-kernel, Sudeep Holla, linux-arm-kernel,
Marc Zyngier, Tejun Heo, Dennis Zhou, Christoph Lameter,
Will Deacon
Add rules for renaming the .data..ro_after_init ELF section in KVM nVHE
object files to .hyp.data..ro_after_init, linking it into the kernel
and mapping it in hyp at runtime.
The section is RW to the host, then mapped RO in hyp. The expectation is
that the host populates the variables in the section and they are never
changed by hyp afterwards.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
arch/arm64/include/asm/sections.h | 1 +
arch/arm64/kernel/vmlinux.lds.S | 10 ++++++++++
arch/arm64/kvm/arm.c | 8 ++++++++
arch/arm64/kvm/hyp/nvhe/hyp.lds.S | 1 +
4 files changed, 20 insertions(+)
diff --git a/arch/arm64/include/asm/sections.h b/arch/arm64/include/asm/sections.h
index 3994169985ef..8ff579361731 100644
--- a/arch/arm64/include/asm/sections.h
+++ b/arch/arm64/include/asm/sections.h
@@ -11,6 +11,7 @@ extern char __alt_instructions[], __alt_instructions_end[];
extern char __hibernate_exit_text_start[], __hibernate_exit_text_end[];
extern char __hyp_idmap_text_start[], __hyp_idmap_text_end[];
extern char __hyp_text_start[], __hyp_text_end[];
+extern char __hyp_data_ro_after_init_start[], __hyp_data_ro_after_init_end[];
extern char __idmap_text_start[], __idmap_text_end[];
extern char __initdata_begin[], __initdata_end[];
extern char __inittext_begin[], __inittext_end[];
diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
index 1bda604f4c70..4382b5d0645d 100644
--- a/arch/arm64/kernel/vmlinux.lds.S
+++ b/arch/arm64/kernel/vmlinux.lds.S
@@ -30,6 +30,13 @@ jiffies = jiffies_64;
*(__kvm_ex_table) \
__stop___kvm_ex_table = .;
+#define HYPERVISOR_DATA_SECTIONS \
+ HYP_SECTION_NAME(.data..ro_after_init) : { \
+ __hyp_data_ro_after_init_start = .; \
+ *(HYP_SECTION_NAME(.data..ro_after_init)) \
+ __hyp_data_ro_after_init_end = .; \
+ }
+
#define HYPERVISOR_PERCPU_SECTION \
. = ALIGN(PAGE_SIZE); \
HYP_SECTION_NAME(.data..percpu) : { \
@@ -37,6 +44,7 @@ jiffies = jiffies_64;
}
#else /* CONFIG_KVM */
#define HYPERVISOR_EXTABLE
+#define HYPERVISOR_DATA_SECTIONS
#define HYPERVISOR_PERCPU_SECTION
#endif
@@ -234,6 +242,8 @@ SECTIONS
_sdata = .;
RW_DATA(L1_CACHE_BYTES, PAGE_SIZE, THREAD_ALIGN)
+ HYPERVISOR_DATA_SECTIONS
+
/*
* Data written with the MMU off but read with the MMU on requires
* cache lines to be invalidated, discarding up to a Cache Writeback
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index 7b718c6c6c52..bb07f0401c68 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -1652,6 +1652,14 @@ static int init_hyp_mode(void)
goto out_err;
}
+ err = create_hyp_mappings(kvm_ksym_ref(__hyp_data_ro_after_init_start),
+ kvm_ksym_ref(__hyp_data_ro_after_init_end),
+ PAGE_HYP_RO);
+ if (err) {
+ kvm_err("Cannot map .hyp.data..ro_after_init section\n");
+ goto out_err;
+ }
+
err = create_hyp_mappings(kvm_ksym_ref(__start_rodata),
kvm_ksym_ref(__end_rodata), PAGE_HYP_RO);
if (err) {
diff --git a/arch/arm64/kvm/hyp/nvhe/hyp.lds.S b/arch/arm64/kvm/hyp/nvhe/hyp.lds.S
index bb2d986ff696..5d76ff2ba63e 100644
--- a/arch/arm64/kvm/hyp/nvhe/hyp.lds.S
+++ b/arch/arm64/kvm/hyp/nvhe/hyp.lds.S
@@ -16,4 +16,5 @@ SECTIONS {
HYP_SECTION_NAME(.data..percpu) : {
PERCPU_INPUT(L1_CACHE_BYTES)
}
+ HYP_SECTION(.data..ro_after_init)
}
--
2.29.2.454.gaff20da3a2-goog
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply related [flat|nested] 147+ messages in thread
* [PATCH v3 11/23] kvm: arm64: Support per_cpu_ptr in nVHE hyp code
2020-11-26 15:53 ` David Brazdil
(?)
@ 2020-11-26 15:54 ` David Brazdil
-1 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Jonathan Corbet, Catalin Marinas, Will Deacon, Marc Zyngier,
James Morse, Julien Thierry, Suzuki K Poulose, Dennis Zhou,
Tejun Heo, Christoph Lameter, Mark Rutland, Lorenzo Pieralisi,
Sudeep Holla, linux-doc, linux-kernel, linux-arm-kernel,
kernel-team, David Brazdil
When compiling with __KVM_NVHE_HYPERVISOR__ redefine per_cpu_offset() to
__hyp_per_cpu_offset() which looks up the base of the nVHE per-CPU
region of the given cpu and computes its offset from the
.hyp.data..percpu section.
This enables use of per_cpu_ptr() helpers in nVHE hyp code. Until now
only this_cpu_ptr() was supported by setting TPIDR_EL2.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
arch/arm64/include/asm/percpu.h | 6 ++++++
arch/arm64/kernel/image-vars.h | 3 +++
arch/arm64/kvm/hyp/nvhe/Makefile | 3 ++-
arch/arm64/kvm/hyp/nvhe/hyp-smp.c | 24 ++++++++++++++++++++++++
4 files changed, 35 insertions(+), 1 deletion(-)
create mode 100644 arch/arm64/kvm/hyp/nvhe/hyp-smp.c
diff --git a/arch/arm64/include/asm/percpu.h b/arch/arm64/include/asm/percpu.h
index 1599e17379d8..8f1661603b78 100644
--- a/arch/arm64/include/asm/percpu.h
+++ b/arch/arm64/include/asm/percpu.h
@@ -239,6 +239,12 @@ PERCPU_RET_OP(add, add, ldadd)
#define this_cpu_cmpxchg_8(pcp, o, n) \
_pcp_protect_return(cmpxchg_relaxed, pcp, o, n)
+#ifdef __KVM_NVHE_HYPERVISOR__
+extern unsigned long __hyp_per_cpu_offset(unsigned int cpu);
+#define __per_cpu_offset
+#define per_cpu_offset(cpu) __hyp_per_cpu_offset((cpu))
+#endif
+
#include <asm-generic/percpu.h>
/* Redefine macros for nVHE hyp under DEBUG_PREEMPT to avoid its dependencies. */
diff --git a/arch/arm64/kernel/image-vars.h b/arch/arm64/kernel/image-vars.h
index 4b32588918d9..8539f34d7538 100644
--- a/arch/arm64/kernel/image-vars.h
+++ b/arch/arm64/kernel/image-vars.h
@@ -102,6 +102,9 @@ KVM_NVHE_ALIAS(gic_nonsecure_priorities);
KVM_NVHE_ALIAS(__start___kvm_ex_table);
KVM_NVHE_ALIAS(__stop___kvm_ex_table);
+/* Array containing bases of nVHE per-CPU memory regions. */
+KVM_NVHE_ALIAS(kvm_arm_hyp_percpu_base);
+
#endif /* CONFIG_KVM */
#endif /* __ARM64_KERNEL_IMAGE_VARS_H */
diff --git a/arch/arm64/kvm/hyp/nvhe/Makefile b/arch/arm64/kvm/hyp/nvhe/Makefile
index 77b8c4e06f2f..cf11f8182756 100644
--- a/arch/arm64/kvm/hyp/nvhe/Makefile
+++ b/arch/arm64/kvm/hyp/nvhe/Makefile
@@ -6,7 +6,8 @@
asflags-y := -D__KVM_NVHE_HYPERVISOR__
ccflags-y := -D__KVM_NVHE_HYPERVISOR__
-obj-y := timer-sr.o sysreg-sr.o debug-sr.o switch.o tlb.o hyp-init.o host.o hyp-main.o
+obj-y := timer-sr.o sysreg-sr.o debug-sr.o switch.o tlb.o hyp-init.o host.o \
+ hyp-main.o hyp-smp.o
obj-y += ../vgic-v3-sr.o ../aarch32.o ../vgic-v2-cpuif-proxy.o ../entry.o \
../fpsimd.o ../hyp-entry.o ../exception.o
diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-smp.c b/arch/arm64/kvm/hyp/nvhe/hyp-smp.c
new file mode 100644
index 000000000000..c168d86f885a
--- /dev/null
+++ b/arch/arm64/kvm/hyp/nvhe/hyp-smp.c
@@ -0,0 +1,24 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2020 - Google LLC
+ * Author: David Brazdil <dbrazdil@google.com>
+ */
+
+#include <asm/kvm_asm.h>
+#include <asm/kvm_hyp.h>
+#include <asm/kvm_mmu.h>
+
+unsigned long __hyp_per_cpu_offset(unsigned int cpu)
+{
+ unsigned long *cpu_base_array;
+ unsigned long this_cpu_base;
+ unsigned long elf_base;
+
+ if (cpu >= ARRAY_SIZE(kvm_arm_hyp_percpu_base))
+ hyp_panic();
+
+ cpu_base_array = (unsigned long*)hyp_symbol_addr(kvm_arm_hyp_percpu_base);
+ this_cpu_base = kern_hyp_va(cpu_base_array[cpu]);
+ elf_base = (unsigned long)hyp_symbol_addr(__per_cpu_start);
+ return this_cpu_base - elf_base;
+}
--
2.29.2.454.gaff20da3a2-goog
^ permalink raw reply related [flat|nested] 147+ messages in thread* [PATCH v3 11/23] kvm: arm64: Support per_cpu_ptr in nVHE hyp code
@ 2020-11-26 15:54 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Mark Rutland, Lorenzo Pieralisi, kernel-team, Jonathan Corbet,
Catalin Marinas, Suzuki K Poulose, linux-doc, linux-kernel,
Sudeep Holla, James Morse, linux-arm-kernel, Marc Zyngier,
Tejun Heo, Dennis Zhou, Christoph Lameter, David Brazdil,
Will Deacon, Julien Thierry
When compiling with __KVM_NVHE_HYPERVISOR__ redefine per_cpu_offset() to
__hyp_per_cpu_offset() which looks up the base of the nVHE per-CPU
region of the given cpu and computes its offset from the
.hyp.data..percpu section.
This enables use of per_cpu_ptr() helpers in nVHE hyp code. Until now
only this_cpu_ptr() was supported by setting TPIDR_EL2.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
arch/arm64/include/asm/percpu.h | 6 ++++++
arch/arm64/kernel/image-vars.h | 3 +++
arch/arm64/kvm/hyp/nvhe/Makefile | 3 ++-
arch/arm64/kvm/hyp/nvhe/hyp-smp.c | 24 ++++++++++++++++++++++++
4 files changed, 35 insertions(+), 1 deletion(-)
create mode 100644 arch/arm64/kvm/hyp/nvhe/hyp-smp.c
diff --git a/arch/arm64/include/asm/percpu.h b/arch/arm64/include/asm/percpu.h
index 1599e17379d8..8f1661603b78 100644
--- a/arch/arm64/include/asm/percpu.h
+++ b/arch/arm64/include/asm/percpu.h
@@ -239,6 +239,12 @@ PERCPU_RET_OP(add, add, ldadd)
#define this_cpu_cmpxchg_8(pcp, o, n) \
_pcp_protect_return(cmpxchg_relaxed, pcp, o, n)
+#ifdef __KVM_NVHE_HYPERVISOR__
+extern unsigned long __hyp_per_cpu_offset(unsigned int cpu);
+#define __per_cpu_offset
+#define per_cpu_offset(cpu) __hyp_per_cpu_offset((cpu))
+#endif
+
#include <asm-generic/percpu.h>
/* Redefine macros for nVHE hyp under DEBUG_PREEMPT to avoid its dependencies. */
diff --git a/arch/arm64/kernel/image-vars.h b/arch/arm64/kernel/image-vars.h
index 4b32588918d9..8539f34d7538 100644
--- a/arch/arm64/kernel/image-vars.h
+++ b/arch/arm64/kernel/image-vars.h
@@ -102,6 +102,9 @@ KVM_NVHE_ALIAS(gic_nonsecure_priorities);
KVM_NVHE_ALIAS(__start___kvm_ex_table);
KVM_NVHE_ALIAS(__stop___kvm_ex_table);
+/* Array containing bases of nVHE per-CPU memory regions. */
+KVM_NVHE_ALIAS(kvm_arm_hyp_percpu_base);
+
#endif /* CONFIG_KVM */
#endif /* __ARM64_KERNEL_IMAGE_VARS_H */
diff --git a/arch/arm64/kvm/hyp/nvhe/Makefile b/arch/arm64/kvm/hyp/nvhe/Makefile
index 77b8c4e06f2f..cf11f8182756 100644
--- a/arch/arm64/kvm/hyp/nvhe/Makefile
+++ b/arch/arm64/kvm/hyp/nvhe/Makefile
@@ -6,7 +6,8 @@
asflags-y := -D__KVM_NVHE_HYPERVISOR__
ccflags-y := -D__KVM_NVHE_HYPERVISOR__
-obj-y := timer-sr.o sysreg-sr.o debug-sr.o switch.o tlb.o hyp-init.o host.o hyp-main.o
+obj-y := timer-sr.o sysreg-sr.o debug-sr.o switch.o tlb.o hyp-init.o host.o \
+ hyp-main.o hyp-smp.o
obj-y += ../vgic-v3-sr.o ../aarch32.o ../vgic-v2-cpuif-proxy.o ../entry.o \
../fpsimd.o ../hyp-entry.o ../exception.o
diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-smp.c b/arch/arm64/kvm/hyp/nvhe/hyp-smp.c
new file mode 100644
index 000000000000..c168d86f885a
--- /dev/null
+++ b/arch/arm64/kvm/hyp/nvhe/hyp-smp.c
@@ -0,0 +1,24 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2020 - Google LLC
+ * Author: David Brazdil <dbrazdil@google.com>
+ */
+
+#include <asm/kvm_asm.h>
+#include <asm/kvm_hyp.h>
+#include <asm/kvm_mmu.h>
+
+unsigned long __hyp_per_cpu_offset(unsigned int cpu)
+{
+ unsigned long *cpu_base_array;
+ unsigned long this_cpu_base;
+ unsigned long elf_base;
+
+ if (cpu >= ARRAY_SIZE(kvm_arm_hyp_percpu_base))
+ hyp_panic();
+
+ cpu_base_array = (unsigned long*)hyp_symbol_addr(kvm_arm_hyp_percpu_base);
+ this_cpu_base = kern_hyp_va(cpu_base_array[cpu]);
+ elf_base = (unsigned long)hyp_symbol_addr(__per_cpu_start);
+ return this_cpu_base - elf_base;
+}
--
2.29.2.454.gaff20da3a2-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 147+ messages in thread* [PATCH v3 11/23] kvm: arm64: Support per_cpu_ptr in nVHE hyp code
@ 2020-11-26 15:54 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Lorenzo Pieralisi, kernel-team, Jonathan Corbet, Catalin Marinas,
linux-doc, linux-kernel, Sudeep Holla, linux-arm-kernel,
Marc Zyngier, Tejun Heo, Dennis Zhou, Christoph Lameter,
Will Deacon
When compiling with __KVM_NVHE_HYPERVISOR__ redefine per_cpu_offset() to
__hyp_per_cpu_offset() which looks up the base of the nVHE per-CPU
region of the given cpu and computes its offset from the
.hyp.data..percpu section.
This enables use of per_cpu_ptr() helpers in nVHE hyp code. Until now
only this_cpu_ptr() was supported by setting TPIDR_EL2.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
arch/arm64/include/asm/percpu.h | 6 ++++++
arch/arm64/kernel/image-vars.h | 3 +++
arch/arm64/kvm/hyp/nvhe/Makefile | 3 ++-
arch/arm64/kvm/hyp/nvhe/hyp-smp.c | 24 ++++++++++++++++++++++++
4 files changed, 35 insertions(+), 1 deletion(-)
create mode 100644 arch/arm64/kvm/hyp/nvhe/hyp-smp.c
diff --git a/arch/arm64/include/asm/percpu.h b/arch/arm64/include/asm/percpu.h
index 1599e17379d8..8f1661603b78 100644
--- a/arch/arm64/include/asm/percpu.h
+++ b/arch/arm64/include/asm/percpu.h
@@ -239,6 +239,12 @@ PERCPU_RET_OP(add, add, ldadd)
#define this_cpu_cmpxchg_8(pcp, o, n) \
_pcp_protect_return(cmpxchg_relaxed, pcp, o, n)
+#ifdef __KVM_NVHE_HYPERVISOR__
+extern unsigned long __hyp_per_cpu_offset(unsigned int cpu);
+#define __per_cpu_offset
+#define per_cpu_offset(cpu) __hyp_per_cpu_offset((cpu))
+#endif
+
#include <asm-generic/percpu.h>
/* Redefine macros for nVHE hyp under DEBUG_PREEMPT to avoid its dependencies. */
diff --git a/arch/arm64/kernel/image-vars.h b/arch/arm64/kernel/image-vars.h
index 4b32588918d9..8539f34d7538 100644
--- a/arch/arm64/kernel/image-vars.h
+++ b/arch/arm64/kernel/image-vars.h
@@ -102,6 +102,9 @@ KVM_NVHE_ALIAS(gic_nonsecure_priorities);
KVM_NVHE_ALIAS(__start___kvm_ex_table);
KVM_NVHE_ALIAS(__stop___kvm_ex_table);
+/* Array containing bases of nVHE per-CPU memory regions. */
+KVM_NVHE_ALIAS(kvm_arm_hyp_percpu_base);
+
#endif /* CONFIG_KVM */
#endif /* __ARM64_KERNEL_IMAGE_VARS_H */
diff --git a/arch/arm64/kvm/hyp/nvhe/Makefile b/arch/arm64/kvm/hyp/nvhe/Makefile
index 77b8c4e06f2f..cf11f8182756 100644
--- a/arch/arm64/kvm/hyp/nvhe/Makefile
+++ b/arch/arm64/kvm/hyp/nvhe/Makefile
@@ -6,7 +6,8 @@
asflags-y := -D__KVM_NVHE_HYPERVISOR__
ccflags-y := -D__KVM_NVHE_HYPERVISOR__
-obj-y := timer-sr.o sysreg-sr.o debug-sr.o switch.o tlb.o hyp-init.o host.o hyp-main.o
+obj-y := timer-sr.o sysreg-sr.o debug-sr.o switch.o tlb.o hyp-init.o host.o \
+ hyp-main.o hyp-smp.o
obj-y += ../vgic-v3-sr.o ../aarch32.o ../vgic-v2-cpuif-proxy.o ../entry.o \
../fpsimd.o ../hyp-entry.o ../exception.o
diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-smp.c b/arch/arm64/kvm/hyp/nvhe/hyp-smp.c
new file mode 100644
index 000000000000..c168d86f885a
--- /dev/null
+++ b/arch/arm64/kvm/hyp/nvhe/hyp-smp.c
@@ -0,0 +1,24 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2020 - Google LLC
+ * Author: David Brazdil <dbrazdil@google.com>
+ */
+
+#include <asm/kvm_asm.h>
+#include <asm/kvm_hyp.h>
+#include <asm/kvm_mmu.h>
+
+unsigned long __hyp_per_cpu_offset(unsigned int cpu)
+{
+ unsigned long *cpu_base_array;
+ unsigned long this_cpu_base;
+ unsigned long elf_base;
+
+ if (cpu >= ARRAY_SIZE(kvm_arm_hyp_percpu_base))
+ hyp_panic();
+
+ cpu_base_array = (unsigned long*)hyp_symbol_addr(kvm_arm_hyp_percpu_base);
+ this_cpu_base = kern_hyp_va(cpu_base_array[cpu]);
+ elf_base = (unsigned long)hyp_symbol_addr(__per_cpu_start);
+ return this_cpu_base - elf_base;
+}
--
2.29.2.454.gaff20da3a2-goog
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply related [flat|nested] 147+ messages in thread
* [PATCH v3 12/23] kvm: arm64: Create nVHE copy of cpu_logical_map
2020-11-26 15:53 ` David Brazdil
(?)
@ 2020-11-26 15:54 ` David Brazdil
-1 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Jonathan Corbet, Catalin Marinas, Will Deacon, Marc Zyngier,
James Morse, Julien Thierry, Suzuki K Poulose, Dennis Zhou,
Tejun Heo, Christoph Lameter, Mark Rutland, Lorenzo Pieralisi,
Sudeep Holla, linux-doc, linux-kernel, linux-arm-kernel,
kernel-team, David Brazdil
When KVM starts validating host's PSCI requests, it will need to map
MPIDR back to the CPU ID. To this end, copy cpu_logical_map into nVHE
hyp memory when KVM is initialized.
Only copy the information for CPUs that are online at the point of KVM
initialization so that KVM rejects CPUs whose features were not checked
against the finalized capabilities.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
arch/arm64/kvm/arm.c | 19 +++++++++++++++++++
arch/arm64/kvm/hyp/nvhe/hyp-smp.c | 16 ++++++++++++++++
2 files changed, 35 insertions(+)
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index bb07f0401c68..bb3c541d3ddb 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -61,6 +61,8 @@ static bool vgic_present;
static DEFINE_PER_CPU(unsigned char, kvm_arm_hardware_enabled);
DEFINE_STATIC_KEY_FALSE(userspace_irqchip_in_use);
+extern u64 kvm_nvhe_sym(__cpu_logical_map)[NR_CPUS];
+
int kvm_arch_vcpu_should_kick(struct kvm_vcpu *vcpu)
{
return kvm_vcpu_exiting_guest_mode(vcpu) == IN_GUEST_MODE;
@@ -1531,6 +1533,20 @@ static inline void hyp_cpu_pm_exit(void)
}
#endif
+static void init_cpu_logical_map(void)
+{
+ unsigned int cpu;
+
+ /*
+ * Copy the MPIDR <-> logical CPU ID mapping to hyp.
+ * Only copy the set of online CPUs whose features have been chacked
+ * against the finalized system capabilities. The hypervisor will not
+ * allow any other CPUs from the `possible` set to boot.
+ */
+ for_each_online_cpu(cpu)
+ kvm_nvhe_sym(__cpu_logical_map)[cpu] = cpu_logical_map(cpu);
+}
+
static int init_common_resources(void)
{
return kvm_set_ipa_limit();
@@ -1703,6 +1719,9 @@ static int init_hyp_mode(void)
}
}
+ if (is_protected_kvm_enabled())
+ init_cpu_logical_map();
+
return 0;
out_err:
diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-smp.c b/arch/arm64/kvm/hyp/nvhe/hyp-smp.c
index c168d86f885a..ceb427aabb91 100644
--- a/arch/arm64/kvm/hyp/nvhe/hyp-smp.c
+++ b/arch/arm64/kvm/hyp/nvhe/hyp-smp.c
@@ -8,6 +8,22 @@
#include <asm/kvm_hyp.h>
#include <asm/kvm_mmu.h>
+/*
+ * nVHE copy of data structures tracking available CPU cores.
+ * Only entries for CPUs that were online at KVM init are populated.
+ * Other CPUs should not be allowed to boot because their features were
+ * not checked against the finalized system capabilities.
+ */
+u64 __ro_after_init __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = INVALID_HWID };
+
+u64 cpu_logical_map(unsigned int cpu)
+{
+ if (cpu >= ARRAY_SIZE(__cpu_logical_map))
+ hyp_panic();
+
+ return __cpu_logical_map[cpu];
+}
+
unsigned long __hyp_per_cpu_offset(unsigned int cpu)
{
unsigned long *cpu_base_array;
--
2.29.2.454.gaff20da3a2-goog
^ permalink raw reply related [flat|nested] 147+ messages in thread* [PATCH v3 12/23] kvm: arm64: Create nVHE copy of cpu_logical_map
@ 2020-11-26 15:54 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Mark Rutland, Lorenzo Pieralisi, kernel-team, Jonathan Corbet,
Catalin Marinas, Suzuki K Poulose, linux-doc, linux-kernel,
Sudeep Holla, James Morse, linux-arm-kernel, Marc Zyngier,
Tejun Heo, Dennis Zhou, Christoph Lameter, David Brazdil,
Will Deacon, Julien Thierry
When KVM starts validating host's PSCI requests, it will need to map
MPIDR back to the CPU ID. To this end, copy cpu_logical_map into nVHE
hyp memory when KVM is initialized.
Only copy the information for CPUs that are online at the point of KVM
initialization so that KVM rejects CPUs whose features were not checked
against the finalized capabilities.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
arch/arm64/kvm/arm.c | 19 +++++++++++++++++++
arch/arm64/kvm/hyp/nvhe/hyp-smp.c | 16 ++++++++++++++++
2 files changed, 35 insertions(+)
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index bb07f0401c68..bb3c541d3ddb 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -61,6 +61,8 @@ static bool vgic_present;
static DEFINE_PER_CPU(unsigned char, kvm_arm_hardware_enabled);
DEFINE_STATIC_KEY_FALSE(userspace_irqchip_in_use);
+extern u64 kvm_nvhe_sym(__cpu_logical_map)[NR_CPUS];
+
int kvm_arch_vcpu_should_kick(struct kvm_vcpu *vcpu)
{
return kvm_vcpu_exiting_guest_mode(vcpu) == IN_GUEST_MODE;
@@ -1531,6 +1533,20 @@ static inline void hyp_cpu_pm_exit(void)
}
#endif
+static void init_cpu_logical_map(void)
+{
+ unsigned int cpu;
+
+ /*
+ * Copy the MPIDR <-> logical CPU ID mapping to hyp.
+ * Only copy the set of online CPUs whose features have been chacked
+ * against the finalized system capabilities. The hypervisor will not
+ * allow any other CPUs from the `possible` set to boot.
+ */
+ for_each_online_cpu(cpu)
+ kvm_nvhe_sym(__cpu_logical_map)[cpu] = cpu_logical_map(cpu);
+}
+
static int init_common_resources(void)
{
return kvm_set_ipa_limit();
@@ -1703,6 +1719,9 @@ static int init_hyp_mode(void)
}
}
+ if (is_protected_kvm_enabled())
+ init_cpu_logical_map();
+
return 0;
out_err:
diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-smp.c b/arch/arm64/kvm/hyp/nvhe/hyp-smp.c
index c168d86f885a..ceb427aabb91 100644
--- a/arch/arm64/kvm/hyp/nvhe/hyp-smp.c
+++ b/arch/arm64/kvm/hyp/nvhe/hyp-smp.c
@@ -8,6 +8,22 @@
#include <asm/kvm_hyp.h>
#include <asm/kvm_mmu.h>
+/*
+ * nVHE copy of data structures tracking available CPU cores.
+ * Only entries for CPUs that were online at KVM init are populated.
+ * Other CPUs should not be allowed to boot because their features were
+ * not checked against the finalized system capabilities.
+ */
+u64 __ro_after_init __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = INVALID_HWID };
+
+u64 cpu_logical_map(unsigned int cpu)
+{
+ if (cpu >= ARRAY_SIZE(__cpu_logical_map))
+ hyp_panic();
+
+ return __cpu_logical_map[cpu];
+}
+
unsigned long __hyp_per_cpu_offset(unsigned int cpu)
{
unsigned long *cpu_base_array;
--
2.29.2.454.gaff20da3a2-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 147+ messages in thread* [PATCH v3 12/23] kvm: arm64: Create nVHE copy of cpu_logical_map
@ 2020-11-26 15:54 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Lorenzo Pieralisi, kernel-team, Jonathan Corbet, Catalin Marinas,
linux-doc, linux-kernel, Sudeep Holla, linux-arm-kernel,
Marc Zyngier, Tejun Heo, Dennis Zhou, Christoph Lameter,
Will Deacon
When KVM starts validating host's PSCI requests, it will need to map
MPIDR back to the CPU ID. To this end, copy cpu_logical_map into nVHE
hyp memory when KVM is initialized.
Only copy the information for CPUs that are online at the point of KVM
initialization so that KVM rejects CPUs whose features were not checked
against the finalized capabilities.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
arch/arm64/kvm/arm.c | 19 +++++++++++++++++++
arch/arm64/kvm/hyp/nvhe/hyp-smp.c | 16 ++++++++++++++++
2 files changed, 35 insertions(+)
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index bb07f0401c68..bb3c541d3ddb 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -61,6 +61,8 @@ static bool vgic_present;
static DEFINE_PER_CPU(unsigned char, kvm_arm_hardware_enabled);
DEFINE_STATIC_KEY_FALSE(userspace_irqchip_in_use);
+extern u64 kvm_nvhe_sym(__cpu_logical_map)[NR_CPUS];
+
int kvm_arch_vcpu_should_kick(struct kvm_vcpu *vcpu)
{
return kvm_vcpu_exiting_guest_mode(vcpu) == IN_GUEST_MODE;
@@ -1531,6 +1533,20 @@ static inline void hyp_cpu_pm_exit(void)
}
#endif
+static void init_cpu_logical_map(void)
+{
+ unsigned int cpu;
+
+ /*
+ * Copy the MPIDR <-> logical CPU ID mapping to hyp.
+ * Only copy the set of online CPUs whose features have been chacked
+ * against the finalized system capabilities. The hypervisor will not
+ * allow any other CPUs from the `possible` set to boot.
+ */
+ for_each_online_cpu(cpu)
+ kvm_nvhe_sym(__cpu_logical_map)[cpu] = cpu_logical_map(cpu);
+}
+
static int init_common_resources(void)
{
return kvm_set_ipa_limit();
@@ -1703,6 +1719,9 @@ static int init_hyp_mode(void)
}
}
+ if (is_protected_kvm_enabled())
+ init_cpu_logical_map();
+
return 0;
out_err:
diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-smp.c b/arch/arm64/kvm/hyp/nvhe/hyp-smp.c
index c168d86f885a..ceb427aabb91 100644
--- a/arch/arm64/kvm/hyp/nvhe/hyp-smp.c
+++ b/arch/arm64/kvm/hyp/nvhe/hyp-smp.c
@@ -8,6 +8,22 @@
#include <asm/kvm_hyp.h>
#include <asm/kvm_mmu.h>
+/*
+ * nVHE copy of data structures tracking available CPU cores.
+ * Only entries for CPUs that were online at KVM init are populated.
+ * Other CPUs should not be allowed to boot because their features were
+ * not checked against the finalized system capabilities.
+ */
+u64 __ro_after_init __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = INVALID_HWID };
+
+u64 cpu_logical_map(unsigned int cpu)
+{
+ if (cpu >= ARRAY_SIZE(__cpu_logical_map))
+ hyp_panic();
+
+ return __cpu_logical_map[cpu];
+}
+
unsigned long __hyp_per_cpu_offset(unsigned int cpu)
{
unsigned long *cpu_base_array;
--
2.29.2.454.gaff20da3a2-goog
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply related [flat|nested] 147+ messages in thread
* [PATCH v3 13/23] kvm: arm64: Add SMC handler in nVHE EL2
2020-11-26 15:53 ` David Brazdil
(?)
@ 2020-11-26 15:54 ` David Brazdil
-1 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Jonathan Corbet, Catalin Marinas, Will Deacon, Marc Zyngier,
James Morse, Julien Thierry, Suzuki K Poulose, Dennis Zhou,
Tejun Heo, Christoph Lameter, Mark Rutland, Lorenzo Pieralisi,
Sudeep Holla, linux-doc, linux-kernel, linux-arm-kernel,
kernel-team, David Brazdil
Add handler of host SMCs in KVM nVHE trap handler. Forward all SMCs to
EL3 and propagate the result back to EL1. This is done in preparation
for validating host SMCs in KVM nVHE protected mode.
The implementation assumes that firmware uses SMCCC v1.2 or older. That
means x0-x17 can be used both for arguments and results, other GPRs are
preserved.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
arch/arm64/kvm/hyp/nvhe/host.S | 38 ++++++++++++++++++++++++++++++
arch/arm64/kvm/hyp/nvhe/hyp-main.c | 35 ++++++++++++++++++++++++---
2 files changed, 70 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/kvm/hyp/nvhe/host.S b/arch/arm64/kvm/hyp/nvhe/host.S
index fe2740b224cf..2b56f0bdf874 100644
--- a/arch/arm64/kvm/hyp/nvhe/host.S
+++ b/arch/arm64/kvm/hyp/nvhe/host.S
@@ -180,3 +180,41 @@ SYM_CODE_START(__kvm_hyp_host_vector)
invalid_host_el1_vect // FIQ 32-bit EL1
invalid_host_el1_vect // Error 32-bit EL1
SYM_CODE_END(__kvm_hyp_host_vector)
+
+/*
+ * Forward SMC with arguments in struct kvm_cpu_context, and
+ * store the result into the same struct. Assumes SMCCC 1.2 or older.
+ *
+ * x0: struct kvm_cpu_context*
+ */
+SYM_CODE_START(__kvm_hyp_host_forward_smc)
+ /*
+ * Use x18 to keep the pointer to the host context because
+ * x18 is callee-saved in SMCCC but not in AAPCS64.
+ */
+ mov x18, x0
+
+ ldp x0, x1, [x18, #CPU_XREG_OFFSET(0)]
+ ldp x2, x3, [x18, #CPU_XREG_OFFSET(2)]
+ ldp x4, x5, [x18, #CPU_XREG_OFFSET(4)]
+ ldp x6, x7, [x18, #CPU_XREG_OFFSET(6)]
+ ldp x8, x9, [x18, #CPU_XREG_OFFSET(8)]
+ ldp x10, x11, [x18, #CPU_XREG_OFFSET(10)]
+ ldp x12, x13, [x18, #CPU_XREG_OFFSET(12)]
+ ldp x14, x15, [x18, #CPU_XREG_OFFSET(14)]
+ ldp x16, x17, [x18, #CPU_XREG_OFFSET(16)]
+
+ smc #0
+
+ stp x0, x1, [x18, #CPU_XREG_OFFSET(0)]
+ stp x2, x3, [x18, #CPU_XREG_OFFSET(2)]
+ stp x4, x5, [x18, #CPU_XREG_OFFSET(4)]
+ stp x6, x7, [x18, #CPU_XREG_OFFSET(6)]
+ stp x8, x9, [x18, #CPU_XREG_OFFSET(8)]
+ stp x10, x11, [x18, #CPU_XREG_OFFSET(10)]
+ stp x12, x13, [x18, #CPU_XREG_OFFSET(12)]
+ stp x14, x15, [x18, #CPU_XREG_OFFSET(14)]
+ stp x16, x17, [x18, #CPU_XREG_OFFSET(16)]
+
+ ret
+SYM_CODE_END(__kvm_hyp_host_forward_smc)
diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
index a4f1cac714d7..f25680ede080 100644
--- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
+++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
@@ -18,6 +18,8 @@
DEFINE_PER_CPU(struct kvm_nvhe_init_params, kvm_init_params);
+void __kvm_hyp_host_forward_smc(struct kvm_cpu_context *host_ctxt);
+
static void handle___kvm_vcpu_run(struct kvm_cpu_context *host_ctxt)
{
DECLARE_REG(struct kvm_vcpu *, vcpu, host_ctxt, 1);
@@ -152,12 +154,39 @@ static void handle_host_hcall(struct kvm_cpu_context *host_ctxt)
cpu_reg(host_ctxt, 0) = SMCCC_RET_NOT_SUPPORTED;
}
+static void default_host_smc_handler(struct kvm_cpu_context *host_ctxt)
+{
+ __kvm_hyp_host_forward_smc(host_ctxt);
+}
+
+static void skip_host_instruction(void)
+{
+ write_sysreg_el2(read_sysreg_el2(SYS_ELR) + 4, SYS_ELR);
+}
+
+static void handle_host_smc(struct kvm_cpu_context *host_ctxt)
+{
+ default_host_smc_handler(host_ctxt);
+
+ /*
+ * Unlike HVC, the return address of an SMC is the instruction's PC.
+ * Move the return address past the instruction.
+ */
+ skip_host_instruction();
+}
+
void handle_trap(struct kvm_cpu_context *host_ctxt)
{
u64 esr = read_sysreg_el2(SYS_ESR);
- if (unlikely(ESR_ELx_EC(esr) != ESR_ELx_EC_HVC64))
+ switch (ESR_ELx_EC(esr)) {
+ case ESR_ELx_EC_HVC64:
+ handle_host_hcall(host_ctxt);
+ break;
+ case ESR_ELx_EC_SMC64:
+ handle_host_smc(host_ctxt);
+ break;
+ default:
hyp_panic();
-
- handle_host_hcall(host_ctxt);
+ }
}
--
2.29.2.454.gaff20da3a2-goog
^ permalink raw reply related [flat|nested] 147+ messages in thread* [PATCH v3 13/23] kvm: arm64: Add SMC handler in nVHE EL2
@ 2020-11-26 15:54 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Mark Rutland, Lorenzo Pieralisi, kernel-team, Jonathan Corbet,
Catalin Marinas, Suzuki K Poulose, linux-doc, linux-kernel,
Sudeep Holla, James Morse, linux-arm-kernel, Marc Zyngier,
Tejun Heo, Dennis Zhou, Christoph Lameter, David Brazdil,
Will Deacon, Julien Thierry
Add handler of host SMCs in KVM nVHE trap handler. Forward all SMCs to
EL3 and propagate the result back to EL1. This is done in preparation
for validating host SMCs in KVM nVHE protected mode.
The implementation assumes that firmware uses SMCCC v1.2 or older. That
means x0-x17 can be used both for arguments and results, other GPRs are
preserved.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
arch/arm64/kvm/hyp/nvhe/host.S | 38 ++++++++++++++++++++++++++++++
arch/arm64/kvm/hyp/nvhe/hyp-main.c | 35 ++++++++++++++++++++++++---
2 files changed, 70 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/kvm/hyp/nvhe/host.S b/arch/arm64/kvm/hyp/nvhe/host.S
index fe2740b224cf..2b56f0bdf874 100644
--- a/arch/arm64/kvm/hyp/nvhe/host.S
+++ b/arch/arm64/kvm/hyp/nvhe/host.S
@@ -180,3 +180,41 @@ SYM_CODE_START(__kvm_hyp_host_vector)
invalid_host_el1_vect // FIQ 32-bit EL1
invalid_host_el1_vect // Error 32-bit EL1
SYM_CODE_END(__kvm_hyp_host_vector)
+
+/*
+ * Forward SMC with arguments in struct kvm_cpu_context, and
+ * store the result into the same struct. Assumes SMCCC 1.2 or older.
+ *
+ * x0: struct kvm_cpu_context*
+ */
+SYM_CODE_START(__kvm_hyp_host_forward_smc)
+ /*
+ * Use x18 to keep the pointer to the host context because
+ * x18 is callee-saved in SMCCC but not in AAPCS64.
+ */
+ mov x18, x0
+
+ ldp x0, x1, [x18, #CPU_XREG_OFFSET(0)]
+ ldp x2, x3, [x18, #CPU_XREG_OFFSET(2)]
+ ldp x4, x5, [x18, #CPU_XREG_OFFSET(4)]
+ ldp x6, x7, [x18, #CPU_XREG_OFFSET(6)]
+ ldp x8, x9, [x18, #CPU_XREG_OFFSET(8)]
+ ldp x10, x11, [x18, #CPU_XREG_OFFSET(10)]
+ ldp x12, x13, [x18, #CPU_XREG_OFFSET(12)]
+ ldp x14, x15, [x18, #CPU_XREG_OFFSET(14)]
+ ldp x16, x17, [x18, #CPU_XREG_OFFSET(16)]
+
+ smc #0
+
+ stp x0, x1, [x18, #CPU_XREG_OFFSET(0)]
+ stp x2, x3, [x18, #CPU_XREG_OFFSET(2)]
+ stp x4, x5, [x18, #CPU_XREG_OFFSET(4)]
+ stp x6, x7, [x18, #CPU_XREG_OFFSET(6)]
+ stp x8, x9, [x18, #CPU_XREG_OFFSET(8)]
+ stp x10, x11, [x18, #CPU_XREG_OFFSET(10)]
+ stp x12, x13, [x18, #CPU_XREG_OFFSET(12)]
+ stp x14, x15, [x18, #CPU_XREG_OFFSET(14)]
+ stp x16, x17, [x18, #CPU_XREG_OFFSET(16)]
+
+ ret
+SYM_CODE_END(__kvm_hyp_host_forward_smc)
diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
index a4f1cac714d7..f25680ede080 100644
--- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
+++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
@@ -18,6 +18,8 @@
DEFINE_PER_CPU(struct kvm_nvhe_init_params, kvm_init_params);
+void __kvm_hyp_host_forward_smc(struct kvm_cpu_context *host_ctxt);
+
static void handle___kvm_vcpu_run(struct kvm_cpu_context *host_ctxt)
{
DECLARE_REG(struct kvm_vcpu *, vcpu, host_ctxt, 1);
@@ -152,12 +154,39 @@ static void handle_host_hcall(struct kvm_cpu_context *host_ctxt)
cpu_reg(host_ctxt, 0) = SMCCC_RET_NOT_SUPPORTED;
}
+static void default_host_smc_handler(struct kvm_cpu_context *host_ctxt)
+{
+ __kvm_hyp_host_forward_smc(host_ctxt);
+}
+
+static void skip_host_instruction(void)
+{
+ write_sysreg_el2(read_sysreg_el2(SYS_ELR) + 4, SYS_ELR);
+}
+
+static void handle_host_smc(struct kvm_cpu_context *host_ctxt)
+{
+ default_host_smc_handler(host_ctxt);
+
+ /*
+ * Unlike HVC, the return address of an SMC is the instruction's PC.
+ * Move the return address past the instruction.
+ */
+ skip_host_instruction();
+}
+
void handle_trap(struct kvm_cpu_context *host_ctxt)
{
u64 esr = read_sysreg_el2(SYS_ESR);
- if (unlikely(ESR_ELx_EC(esr) != ESR_ELx_EC_HVC64))
+ switch (ESR_ELx_EC(esr)) {
+ case ESR_ELx_EC_HVC64:
+ handle_host_hcall(host_ctxt);
+ break;
+ case ESR_ELx_EC_SMC64:
+ handle_host_smc(host_ctxt);
+ break;
+ default:
hyp_panic();
-
- handle_host_hcall(host_ctxt);
+ }
}
--
2.29.2.454.gaff20da3a2-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 147+ messages in thread* [PATCH v3 13/23] kvm: arm64: Add SMC handler in nVHE EL2
@ 2020-11-26 15:54 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Lorenzo Pieralisi, kernel-team, Jonathan Corbet, Catalin Marinas,
linux-doc, linux-kernel, Sudeep Holla, linux-arm-kernel,
Marc Zyngier, Tejun Heo, Dennis Zhou, Christoph Lameter,
Will Deacon
Add handler of host SMCs in KVM nVHE trap handler. Forward all SMCs to
EL3 and propagate the result back to EL1. This is done in preparation
for validating host SMCs in KVM nVHE protected mode.
The implementation assumes that firmware uses SMCCC v1.2 or older. That
means x0-x17 can be used both for arguments and results, other GPRs are
preserved.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
arch/arm64/kvm/hyp/nvhe/host.S | 38 ++++++++++++++++++++++++++++++
arch/arm64/kvm/hyp/nvhe/hyp-main.c | 35 ++++++++++++++++++++++++---
2 files changed, 70 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/kvm/hyp/nvhe/host.S b/arch/arm64/kvm/hyp/nvhe/host.S
index fe2740b224cf..2b56f0bdf874 100644
--- a/arch/arm64/kvm/hyp/nvhe/host.S
+++ b/arch/arm64/kvm/hyp/nvhe/host.S
@@ -180,3 +180,41 @@ SYM_CODE_START(__kvm_hyp_host_vector)
invalid_host_el1_vect // FIQ 32-bit EL1
invalid_host_el1_vect // Error 32-bit EL1
SYM_CODE_END(__kvm_hyp_host_vector)
+
+/*
+ * Forward SMC with arguments in struct kvm_cpu_context, and
+ * store the result into the same struct. Assumes SMCCC 1.2 or older.
+ *
+ * x0: struct kvm_cpu_context*
+ */
+SYM_CODE_START(__kvm_hyp_host_forward_smc)
+ /*
+ * Use x18 to keep the pointer to the host context because
+ * x18 is callee-saved in SMCCC but not in AAPCS64.
+ */
+ mov x18, x0
+
+ ldp x0, x1, [x18, #CPU_XREG_OFFSET(0)]
+ ldp x2, x3, [x18, #CPU_XREG_OFFSET(2)]
+ ldp x4, x5, [x18, #CPU_XREG_OFFSET(4)]
+ ldp x6, x7, [x18, #CPU_XREG_OFFSET(6)]
+ ldp x8, x9, [x18, #CPU_XREG_OFFSET(8)]
+ ldp x10, x11, [x18, #CPU_XREG_OFFSET(10)]
+ ldp x12, x13, [x18, #CPU_XREG_OFFSET(12)]
+ ldp x14, x15, [x18, #CPU_XREG_OFFSET(14)]
+ ldp x16, x17, [x18, #CPU_XREG_OFFSET(16)]
+
+ smc #0
+
+ stp x0, x1, [x18, #CPU_XREG_OFFSET(0)]
+ stp x2, x3, [x18, #CPU_XREG_OFFSET(2)]
+ stp x4, x5, [x18, #CPU_XREG_OFFSET(4)]
+ stp x6, x7, [x18, #CPU_XREG_OFFSET(6)]
+ stp x8, x9, [x18, #CPU_XREG_OFFSET(8)]
+ stp x10, x11, [x18, #CPU_XREG_OFFSET(10)]
+ stp x12, x13, [x18, #CPU_XREG_OFFSET(12)]
+ stp x14, x15, [x18, #CPU_XREG_OFFSET(14)]
+ stp x16, x17, [x18, #CPU_XREG_OFFSET(16)]
+
+ ret
+SYM_CODE_END(__kvm_hyp_host_forward_smc)
diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
index a4f1cac714d7..f25680ede080 100644
--- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
+++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
@@ -18,6 +18,8 @@
DEFINE_PER_CPU(struct kvm_nvhe_init_params, kvm_init_params);
+void __kvm_hyp_host_forward_smc(struct kvm_cpu_context *host_ctxt);
+
static void handle___kvm_vcpu_run(struct kvm_cpu_context *host_ctxt)
{
DECLARE_REG(struct kvm_vcpu *, vcpu, host_ctxt, 1);
@@ -152,12 +154,39 @@ static void handle_host_hcall(struct kvm_cpu_context *host_ctxt)
cpu_reg(host_ctxt, 0) = SMCCC_RET_NOT_SUPPORTED;
}
+static void default_host_smc_handler(struct kvm_cpu_context *host_ctxt)
+{
+ __kvm_hyp_host_forward_smc(host_ctxt);
+}
+
+static void skip_host_instruction(void)
+{
+ write_sysreg_el2(read_sysreg_el2(SYS_ELR) + 4, SYS_ELR);
+}
+
+static void handle_host_smc(struct kvm_cpu_context *host_ctxt)
+{
+ default_host_smc_handler(host_ctxt);
+
+ /*
+ * Unlike HVC, the return address of an SMC is the instruction's PC.
+ * Move the return address past the instruction.
+ */
+ skip_host_instruction();
+}
+
void handle_trap(struct kvm_cpu_context *host_ctxt)
{
u64 esr = read_sysreg_el2(SYS_ESR);
- if (unlikely(ESR_ELx_EC(esr) != ESR_ELx_EC_HVC64))
+ switch (ESR_ELx_EC(esr)) {
+ case ESR_ELx_EC_HVC64:
+ handle_host_hcall(host_ctxt);
+ break;
+ case ESR_ELx_EC_SMC64:
+ handle_host_smc(host_ctxt);
+ break;
+ default:
hyp_panic();
-
- handle_host_hcall(host_ctxt);
+ }
}
--
2.29.2.454.gaff20da3a2-goog
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply related [flat|nested] 147+ messages in thread
* [PATCH v3 14/23] kvm: arm64: Bootstrap PSCI SMC handler in nVHE EL2
2020-11-26 15:53 ` David Brazdil
(?)
@ 2020-11-26 15:54 ` David Brazdil
-1 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Jonathan Corbet, Catalin Marinas, Will Deacon, Marc Zyngier,
James Morse, Julien Thierry, Suzuki K Poulose, Dennis Zhou,
Tejun Heo, Christoph Lameter, Mark Rutland, Lorenzo Pieralisi,
Sudeep Holla, linux-doc, linux-kernel, linux-arm-kernel,
kernel-team, David Brazdil
Add a handler of PSCI SMCs in nVHE hyp code. The handler is initialized
with the version used by the host's PSCI driver and the function IDs it
was configured with. If the SMC function ID matches one of the
configured PSCI calls (for v0.1) or falls into the PSCI function ID
range (for v0.2+), the SMC is handled by the PSCI handler. For now, all
SMCs return PSCI_RET_NOT_SUPPORTED.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
arch/arm64/include/asm/kvm_hyp.h | 2 +
arch/arm64/kvm/arm.c | 29 ++++-
.../arm64/kvm/hyp/include/nvhe/trap_handler.h | 18 +++
arch/arm64/kvm/hyp/nvhe/Makefile | 2 +-
arch/arm64/kvm/hyp/nvhe/hyp-main.c | 10 +-
arch/arm64/kvm/hyp/nvhe/psci-relay.c | 103 ++++++++++++++++++
6 files changed, 158 insertions(+), 6 deletions(-)
create mode 100644 arch/arm64/kvm/hyp/include/nvhe/trap_handler.h
create mode 100644 arch/arm64/kvm/hyp/nvhe/psci-relay.c
diff --git a/arch/arm64/include/asm/kvm_hyp.h b/arch/arm64/include/asm/kvm_hyp.h
index cb25c15e3d8d..c0450828378b 100644
--- a/arch/arm64/include/asm/kvm_hyp.h
+++ b/arch/arm64/include/asm/kvm_hyp.h
@@ -93,6 +93,8 @@ void deactivate_traps_vhe_put(void);
u64 __guest_enter(struct kvm_vcpu *vcpu);
+bool kvm_host_psci_handler(struct kvm_cpu_context *host_ctxt);
+
void __noreturn hyp_panic(void);
#ifdef __KVM_NVHE_HYPERVISOR__
void __noreturn __hyp_do_panic(bool restore_host, u64 spsr, u64 elr, u64 par);
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index bb3c541d3ddb..7a17b5048454 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -19,6 +19,7 @@
#include <linux/kvm_irqfd.h>
#include <linux/irqbypass.h>
#include <linux/sched/stat.h>
+#include <linux/psci.h>
#include <trace/events/kvm.h>
#define CREATE_TRACE_POINTS
@@ -62,6 +63,8 @@ static DEFINE_PER_CPU(unsigned char, kvm_arm_hardware_enabled);
DEFINE_STATIC_KEY_FALSE(userspace_irqchip_in_use);
extern u64 kvm_nvhe_sym(__cpu_logical_map)[NR_CPUS];
+extern u32 kvm_nvhe_sym(kvm_host_psci_version);
+extern u32 kvm_nvhe_sym(kvm_host_psci_function_id)[PSCI_FN_MAX];
int kvm_arch_vcpu_should_kick(struct kvm_vcpu *vcpu)
{
@@ -1547,6 +1550,26 @@ static void init_cpu_logical_map(void)
kvm_nvhe_sym(__cpu_logical_map)[cpu] = cpu_logical_map(cpu);
}
+static bool init_psci_relay(void)
+{
+ int i;
+
+ /*
+ * If PSCI has not been initialized, protected KVM cannot install
+ * itself on newly booted CPUs.
+ */
+ if (!psci_ops.get_version) {
+ kvm_err("Cannot initialize protected mode without PSCI\n");
+ return false;
+ }
+
+ kvm_nvhe_sym(kvm_host_psci_version) = psci_ops.get_version();
+ for (i = 0; i < PSCI_FN_MAX; ++i)
+ kvm_nvhe_sym(kvm_host_psci_function_id)[i] = psci_get_function_id(i);
+
+ return true;
+}
+
static int init_common_resources(void)
{
return kvm_set_ipa_limit();
@@ -1719,9 +1742,13 @@ static int init_hyp_mode(void)
}
}
- if (is_protected_kvm_enabled())
+ if (is_protected_kvm_enabled()) {
init_cpu_logical_map();
+ if (!init_psci_relay())
+ goto out_err;
+ }
+
return 0;
out_err:
diff --git a/arch/arm64/kvm/hyp/include/nvhe/trap_handler.h b/arch/arm64/kvm/hyp/include/nvhe/trap_handler.h
new file mode 100644
index 000000000000..92d34675acdb
--- /dev/null
+++ b/arch/arm64/kvm/hyp/include/nvhe/trap_handler.h
@@ -0,0 +1,18 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Trap handler helpers.
+ *
+ * Copyright (C) 2020 - Google LLC
+ * Author: Marc Zyngier <dbrazdil@google.com>
+ */
+
+#ifndef __ARM64_KVM_NVHE_TRAP_HANDLER_H__
+#define __ARM64_KVM_NVHE_TRAP_HANDLER_H__
+
+#include <asm/kvm_host.h>
+
+#define cpu_reg(ctxt, r) (ctxt)->regs.regs[r]
+#define DECLARE_REG(type, name, ctxt, reg) \
+ type name = (type)cpu_reg(ctxt, (reg))
+
+#endif /* __ARM64_KVM_NVHE_TRAP_HANDLER_H__ */
diff --git a/arch/arm64/kvm/hyp/nvhe/Makefile b/arch/arm64/kvm/hyp/nvhe/Makefile
index cf11f8182756..1f1e351c5fe2 100644
--- a/arch/arm64/kvm/hyp/nvhe/Makefile
+++ b/arch/arm64/kvm/hyp/nvhe/Makefile
@@ -7,7 +7,7 @@ asflags-y := -D__KVM_NVHE_HYPERVISOR__
ccflags-y := -D__KVM_NVHE_HYPERVISOR__
obj-y := timer-sr.o sysreg-sr.o debug-sr.o switch.o tlb.o hyp-init.o host.o \
- hyp-main.o hyp-smp.o
+ hyp-main.o hyp-smp.o psci-relay.o
obj-y += ../vgic-v3-sr.o ../aarch32.o ../vgic-v2-cpuif-proxy.o ../entry.o \
../fpsimd.o ../hyp-entry.o ../exception.o
diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
index f25680ede080..bde658d51404 100644
--- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
+++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
@@ -12,9 +12,7 @@
#include <asm/kvm_hyp.h>
#include <asm/kvm_mmu.h>
-#define cpu_reg(ctxt, r) (ctxt)->regs.regs[r]
-#define DECLARE_REG(type, name, ctxt, reg) \
- type name = (type)cpu_reg(ctxt, (reg))
+#include <nvhe/trap_handler.h>
DEFINE_PER_CPU(struct kvm_nvhe_init_params, kvm_init_params);
@@ -166,7 +164,11 @@ static void skip_host_instruction(void)
static void handle_host_smc(struct kvm_cpu_context *host_ctxt)
{
- default_host_smc_handler(host_ctxt);
+ bool handled;
+
+ handled = kvm_host_psci_handler(host_ctxt);
+ if (!handled)
+ default_host_smc_handler(host_ctxt);
/*
* Unlike HVC, the return address of an SMC is the instruction's PC.
diff --git a/arch/arm64/kvm/hyp/nvhe/psci-relay.c b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
new file mode 100644
index 000000000000..44a9fb462d24
--- /dev/null
+++ b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
@@ -0,0 +1,103 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2020 - Google LLC
+ * Author: David Brazdil <dbrazdil@google.com>
+ */
+
+#include <asm/kvm_asm.h>
+#include <asm/kvm_hyp.h>
+#include <asm/kvm_mmu.h>
+#include <kvm/arm_hypercalls.h>
+#include <linux/arm-smccc.h>
+#include <linux/psci.h>
+#include <kvm/arm_psci.h>
+#include <uapi/linux/psci.h>
+
+#include <nvhe/trap_handler.h>
+
+/* Config options set by the host. */
+u32 __ro_after_init kvm_host_psci_version;
+u32 __ro_after_init kvm_host_psci_function_id[PSCI_FN_MAX];
+
+static u64 get_psci_func_id(struct kvm_cpu_context *host_ctxt)
+{
+ DECLARE_REG(u64, func_id, host_ctxt, 0);
+
+ return func_id;
+}
+
+static bool is_psci_0_1_call(u64 func_id)
+{
+ unsigned int i;
+
+ for (i = 0; i < ARRAY_SIZE(kvm_host_psci_function_id); ++i) {
+ if (func_id == kvm_host_psci_function_id[i])
+ return true;
+ }
+ return false;
+}
+
+static bool is_psci_0_2_call(u64 func_id)
+{
+ /* SMCCC reserves IDs 0x00-1F with the given 32/64-bit base for PSCI. */
+ return (PSCI_0_2_FN(0) <= func_id && func_id <= PSCI_0_2_FN(31)) ||
+ (PSCI_0_2_FN64(0) <= func_id && func_id <= PSCI_0_2_FN64(31));
+}
+
+static bool is_psci_call(u64 func_id)
+{
+ switch (kvm_host_psci_version) {
+ case PSCI_VERSION(0, 1):
+ return is_psci_0_1_call(func_id);
+ default:
+ return is_psci_0_2_call(func_id);
+ }
+}
+
+static unsigned long psci_0_1_handler(u64 func_id, struct kvm_cpu_context *host_ctxt)
+{
+ return PSCI_RET_NOT_SUPPORTED;
+}
+
+static unsigned long psci_0_2_handler(u64 func_id, struct kvm_cpu_context *host_ctxt)
+{
+ switch (func_id) {
+ default:
+ return PSCI_RET_NOT_SUPPORTED;
+ }
+}
+
+static unsigned long psci_1_0_handler(u64 func_id, struct kvm_cpu_context *host_ctxt)
+{
+ switch (func_id) {
+ default:
+ return psci_0_2_handler(func_id, host_ctxt);
+ }
+}
+
+bool kvm_host_psci_handler(struct kvm_cpu_context *host_ctxt)
+{
+ u64 func_id = get_psci_func_id(host_ctxt);
+ unsigned long ret;
+
+ if (!is_psci_call(func_id))
+ return false;
+
+ switch (kvm_host_psci_version) {
+ case PSCI_VERSION(0, 1):
+ ret = psci_0_1_handler(func_id, host_ctxt);
+ break;
+ case PSCI_VERSION(0, 2):
+ ret = psci_0_2_handler(func_id, host_ctxt);
+ break;
+ default:
+ ret = psci_1_0_handler(func_id, host_ctxt);
+ break;
+ }
+
+ cpu_reg(host_ctxt, 0) = ret;
+ cpu_reg(host_ctxt, 1) = 0;
+ cpu_reg(host_ctxt, 2) = 0;
+ cpu_reg(host_ctxt, 3) = 0;
+ return true;
+}
--
2.29.2.454.gaff20da3a2-goog
^ permalink raw reply related [flat|nested] 147+ messages in thread* [PATCH v3 14/23] kvm: arm64: Bootstrap PSCI SMC handler in nVHE EL2
@ 2020-11-26 15:54 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Mark Rutland, Lorenzo Pieralisi, kernel-team, Jonathan Corbet,
Catalin Marinas, Suzuki K Poulose, linux-doc, linux-kernel,
Sudeep Holla, James Morse, linux-arm-kernel, Marc Zyngier,
Tejun Heo, Dennis Zhou, Christoph Lameter, David Brazdil,
Will Deacon, Julien Thierry
Add a handler of PSCI SMCs in nVHE hyp code. The handler is initialized
with the version used by the host's PSCI driver and the function IDs it
was configured with. If the SMC function ID matches one of the
configured PSCI calls (for v0.1) or falls into the PSCI function ID
range (for v0.2+), the SMC is handled by the PSCI handler. For now, all
SMCs return PSCI_RET_NOT_SUPPORTED.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
arch/arm64/include/asm/kvm_hyp.h | 2 +
arch/arm64/kvm/arm.c | 29 ++++-
.../arm64/kvm/hyp/include/nvhe/trap_handler.h | 18 +++
arch/arm64/kvm/hyp/nvhe/Makefile | 2 +-
arch/arm64/kvm/hyp/nvhe/hyp-main.c | 10 +-
arch/arm64/kvm/hyp/nvhe/psci-relay.c | 103 ++++++++++++++++++
6 files changed, 158 insertions(+), 6 deletions(-)
create mode 100644 arch/arm64/kvm/hyp/include/nvhe/trap_handler.h
create mode 100644 arch/arm64/kvm/hyp/nvhe/psci-relay.c
diff --git a/arch/arm64/include/asm/kvm_hyp.h b/arch/arm64/include/asm/kvm_hyp.h
index cb25c15e3d8d..c0450828378b 100644
--- a/arch/arm64/include/asm/kvm_hyp.h
+++ b/arch/arm64/include/asm/kvm_hyp.h
@@ -93,6 +93,8 @@ void deactivate_traps_vhe_put(void);
u64 __guest_enter(struct kvm_vcpu *vcpu);
+bool kvm_host_psci_handler(struct kvm_cpu_context *host_ctxt);
+
void __noreturn hyp_panic(void);
#ifdef __KVM_NVHE_HYPERVISOR__
void __noreturn __hyp_do_panic(bool restore_host, u64 spsr, u64 elr, u64 par);
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index bb3c541d3ddb..7a17b5048454 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -19,6 +19,7 @@
#include <linux/kvm_irqfd.h>
#include <linux/irqbypass.h>
#include <linux/sched/stat.h>
+#include <linux/psci.h>
#include <trace/events/kvm.h>
#define CREATE_TRACE_POINTS
@@ -62,6 +63,8 @@ static DEFINE_PER_CPU(unsigned char, kvm_arm_hardware_enabled);
DEFINE_STATIC_KEY_FALSE(userspace_irqchip_in_use);
extern u64 kvm_nvhe_sym(__cpu_logical_map)[NR_CPUS];
+extern u32 kvm_nvhe_sym(kvm_host_psci_version);
+extern u32 kvm_nvhe_sym(kvm_host_psci_function_id)[PSCI_FN_MAX];
int kvm_arch_vcpu_should_kick(struct kvm_vcpu *vcpu)
{
@@ -1547,6 +1550,26 @@ static void init_cpu_logical_map(void)
kvm_nvhe_sym(__cpu_logical_map)[cpu] = cpu_logical_map(cpu);
}
+static bool init_psci_relay(void)
+{
+ int i;
+
+ /*
+ * If PSCI has not been initialized, protected KVM cannot install
+ * itself on newly booted CPUs.
+ */
+ if (!psci_ops.get_version) {
+ kvm_err("Cannot initialize protected mode without PSCI\n");
+ return false;
+ }
+
+ kvm_nvhe_sym(kvm_host_psci_version) = psci_ops.get_version();
+ for (i = 0; i < PSCI_FN_MAX; ++i)
+ kvm_nvhe_sym(kvm_host_psci_function_id)[i] = psci_get_function_id(i);
+
+ return true;
+}
+
static int init_common_resources(void)
{
return kvm_set_ipa_limit();
@@ -1719,9 +1742,13 @@ static int init_hyp_mode(void)
}
}
- if (is_protected_kvm_enabled())
+ if (is_protected_kvm_enabled()) {
init_cpu_logical_map();
+ if (!init_psci_relay())
+ goto out_err;
+ }
+
return 0;
out_err:
diff --git a/arch/arm64/kvm/hyp/include/nvhe/trap_handler.h b/arch/arm64/kvm/hyp/include/nvhe/trap_handler.h
new file mode 100644
index 000000000000..92d34675acdb
--- /dev/null
+++ b/arch/arm64/kvm/hyp/include/nvhe/trap_handler.h
@@ -0,0 +1,18 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Trap handler helpers.
+ *
+ * Copyright (C) 2020 - Google LLC
+ * Author: Marc Zyngier <dbrazdil@google.com>
+ */
+
+#ifndef __ARM64_KVM_NVHE_TRAP_HANDLER_H__
+#define __ARM64_KVM_NVHE_TRAP_HANDLER_H__
+
+#include <asm/kvm_host.h>
+
+#define cpu_reg(ctxt, r) (ctxt)->regs.regs[r]
+#define DECLARE_REG(type, name, ctxt, reg) \
+ type name = (type)cpu_reg(ctxt, (reg))
+
+#endif /* __ARM64_KVM_NVHE_TRAP_HANDLER_H__ */
diff --git a/arch/arm64/kvm/hyp/nvhe/Makefile b/arch/arm64/kvm/hyp/nvhe/Makefile
index cf11f8182756..1f1e351c5fe2 100644
--- a/arch/arm64/kvm/hyp/nvhe/Makefile
+++ b/arch/arm64/kvm/hyp/nvhe/Makefile
@@ -7,7 +7,7 @@ asflags-y := -D__KVM_NVHE_HYPERVISOR__
ccflags-y := -D__KVM_NVHE_HYPERVISOR__
obj-y := timer-sr.o sysreg-sr.o debug-sr.o switch.o tlb.o hyp-init.o host.o \
- hyp-main.o hyp-smp.o
+ hyp-main.o hyp-smp.o psci-relay.o
obj-y += ../vgic-v3-sr.o ../aarch32.o ../vgic-v2-cpuif-proxy.o ../entry.o \
../fpsimd.o ../hyp-entry.o ../exception.o
diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
index f25680ede080..bde658d51404 100644
--- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
+++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
@@ -12,9 +12,7 @@
#include <asm/kvm_hyp.h>
#include <asm/kvm_mmu.h>
-#define cpu_reg(ctxt, r) (ctxt)->regs.regs[r]
-#define DECLARE_REG(type, name, ctxt, reg) \
- type name = (type)cpu_reg(ctxt, (reg))
+#include <nvhe/trap_handler.h>
DEFINE_PER_CPU(struct kvm_nvhe_init_params, kvm_init_params);
@@ -166,7 +164,11 @@ static void skip_host_instruction(void)
static void handle_host_smc(struct kvm_cpu_context *host_ctxt)
{
- default_host_smc_handler(host_ctxt);
+ bool handled;
+
+ handled = kvm_host_psci_handler(host_ctxt);
+ if (!handled)
+ default_host_smc_handler(host_ctxt);
/*
* Unlike HVC, the return address of an SMC is the instruction's PC.
diff --git a/arch/arm64/kvm/hyp/nvhe/psci-relay.c b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
new file mode 100644
index 000000000000..44a9fb462d24
--- /dev/null
+++ b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
@@ -0,0 +1,103 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2020 - Google LLC
+ * Author: David Brazdil <dbrazdil@google.com>
+ */
+
+#include <asm/kvm_asm.h>
+#include <asm/kvm_hyp.h>
+#include <asm/kvm_mmu.h>
+#include <kvm/arm_hypercalls.h>
+#include <linux/arm-smccc.h>
+#include <linux/psci.h>
+#include <kvm/arm_psci.h>
+#include <uapi/linux/psci.h>
+
+#include <nvhe/trap_handler.h>
+
+/* Config options set by the host. */
+u32 __ro_after_init kvm_host_psci_version;
+u32 __ro_after_init kvm_host_psci_function_id[PSCI_FN_MAX];
+
+static u64 get_psci_func_id(struct kvm_cpu_context *host_ctxt)
+{
+ DECLARE_REG(u64, func_id, host_ctxt, 0);
+
+ return func_id;
+}
+
+static bool is_psci_0_1_call(u64 func_id)
+{
+ unsigned int i;
+
+ for (i = 0; i < ARRAY_SIZE(kvm_host_psci_function_id); ++i) {
+ if (func_id == kvm_host_psci_function_id[i])
+ return true;
+ }
+ return false;
+}
+
+static bool is_psci_0_2_call(u64 func_id)
+{
+ /* SMCCC reserves IDs 0x00-1F with the given 32/64-bit base for PSCI. */
+ return (PSCI_0_2_FN(0) <= func_id && func_id <= PSCI_0_2_FN(31)) ||
+ (PSCI_0_2_FN64(0) <= func_id && func_id <= PSCI_0_2_FN64(31));
+}
+
+static bool is_psci_call(u64 func_id)
+{
+ switch (kvm_host_psci_version) {
+ case PSCI_VERSION(0, 1):
+ return is_psci_0_1_call(func_id);
+ default:
+ return is_psci_0_2_call(func_id);
+ }
+}
+
+static unsigned long psci_0_1_handler(u64 func_id, struct kvm_cpu_context *host_ctxt)
+{
+ return PSCI_RET_NOT_SUPPORTED;
+}
+
+static unsigned long psci_0_2_handler(u64 func_id, struct kvm_cpu_context *host_ctxt)
+{
+ switch (func_id) {
+ default:
+ return PSCI_RET_NOT_SUPPORTED;
+ }
+}
+
+static unsigned long psci_1_0_handler(u64 func_id, struct kvm_cpu_context *host_ctxt)
+{
+ switch (func_id) {
+ default:
+ return psci_0_2_handler(func_id, host_ctxt);
+ }
+}
+
+bool kvm_host_psci_handler(struct kvm_cpu_context *host_ctxt)
+{
+ u64 func_id = get_psci_func_id(host_ctxt);
+ unsigned long ret;
+
+ if (!is_psci_call(func_id))
+ return false;
+
+ switch (kvm_host_psci_version) {
+ case PSCI_VERSION(0, 1):
+ ret = psci_0_1_handler(func_id, host_ctxt);
+ break;
+ case PSCI_VERSION(0, 2):
+ ret = psci_0_2_handler(func_id, host_ctxt);
+ break;
+ default:
+ ret = psci_1_0_handler(func_id, host_ctxt);
+ break;
+ }
+
+ cpu_reg(host_ctxt, 0) = ret;
+ cpu_reg(host_ctxt, 1) = 0;
+ cpu_reg(host_ctxt, 2) = 0;
+ cpu_reg(host_ctxt, 3) = 0;
+ return true;
+}
--
2.29.2.454.gaff20da3a2-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 147+ messages in thread* [PATCH v3 14/23] kvm: arm64: Bootstrap PSCI SMC handler in nVHE EL2
@ 2020-11-26 15:54 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Lorenzo Pieralisi, kernel-team, Jonathan Corbet, Catalin Marinas,
linux-doc, linux-kernel, Sudeep Holla, linux-arm-kernel,
Marc Zyngier, Tejun Heo, Dennis Zhou, Christoph Lameter,
Will Deacon
Add a handler of PSCI SMCs in nVHE hyp code. The handler is initialized
with the version used by the host's PSCI driver and the function IDs it
was configured with. If the SMC function ID matches one of the
configured PSCI calls (for v0.1) or falls into the PSCI function ID
range (for v0.2+), the SMC is handled by the PSCI handler. For now, all
SMCs return PSCI_RET_NOT_SUPPORTED.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
arch/arm64/include/asm/kvm_hyp.h | 2 +
arch/arm64/kvm/arm.c | 29 ++++-
.../arm64/kvm/hyp/include/nvhe/trap_handler.h | 18 +++
arch/arm64/kvm/hyp/nvhe/Makefile | 2 +-
arch/arm64/kvm/hyp/nvhe/hyp-main.c | 10 +-
arch/arm64/kvm/hyp/nvhe/psci-relay.c | 103 ++++++++++++++++++
6 files changed, 158 insertions(+), 6 deletions(-)
create mode 100644 arch/arm64/kvm/hyp/include/nvhe/trap_handler.h
create mode 100644 arch/arm64/kvm/hyp/nvhe/psci-relay.c
diff --git a/arch/arm64/include/asm/kvm_hyp.h b/arch/arm64/include/asm/kvm_hyp.h
index cb25c15e3d8d..c0450828378b 100644
--- a/arch/arm64/include/asm/kvm_hyp.h
+++ b/arch/arm64/include/asm/kvm_hyp.h
@@ -93,6 +93,8 @@ void deactivate_traps_vhe_put(void);
u64 __guest_enter(struct kvm_vcpu *vcpu);
+bool kvm_host_psci_handler(struct kvm_cpu_context *host_ctxt);
+
void __noreturn hyp_panic(void);
#ifdef __KVM_NVHE_HYPERVISOR__
void __noreturn __hyp_do_panic(bool restore_host, u64 spsr, u64 elr, u64 par);
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index bb3c541d3ddb..7a17b5048454 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -19,6 +19,7 @@
#include <linux/kvm_irqfd.h>
#include <linux/irqbypass.h>
#include <linux/sched/stat.h>
+#include <linux/psci.h>
#include <trace/events/kvm.h>
#define CREATE_TRACE_POINTS
@@ -62,6 +63,8 @@ static DEFINE_PER_CPU(unsigned char, kvm_arm_hardware_enabled);
DEFINE_STATIC_KEY_FALSE(userspace_irqchip_in_use);
extern u64 kvm_nvhe_sym(__cpu_logical_map)[NR_CPUS];
+extern u32 kvm_nvhe_sym(kvm_host_psci_version);
+extern u32 kvm_nvhe_sym(kvm_host_psci_function_id)[PSCI_FN_MAX];
int kvm_arch_vcpu_should_kick(struct kvm_vcpu *vcpu)
{
@@ -1547,6 +1550,26 @@ static void init_cpu_logical_map(void)
kvm_nvhe_sym(__cpu_logical_map)[cpu] = cpu_logical_map(cpu);
}
+static bool init_psci_relay(void)
+{
+ int i;
+
+ /*
+ * If PSCI has not been initialized, protected KVM cannot install
+ * itself on newly booted CPUs.
+ */
+ if (!psci_ops.get_version) {
+ kvm_err("Cannot initialize protected mode without PSCI\n");
+ return false;
+ }
+
+ kvm_nvhe_sym(kvm_host_psci_version) = psci_ops.get_version();
+ for (i = 0; i < PSCI_FN_MAX; ++i)
+ kvm_nvhe_sym(kvm_host_psci_function_id)[i] = psci_get_function_id(i);
+
+ return true;
+}
+
static int init_common_resources(void)
{
return kvm_set_ipa_limit();
@@ -1719,9 +1742,13 @@ static int init_hyp_mode(void)
}
}
- if (is_protected_kvm_enabled())
+ if (is_protected_kvm_enabled()) {
init_cpu_logical_map();
+ if (!init_psci_relay())
+ goto out_err;
+ }
+
return 0;
out_err:
diff --git a/arch/arm64/kvm/hyp/include/nvhe/trap_handler.h b/arch/arm64/kvm/hyp/include/nvhe/trap_handler.h
new file mode 100644
index 000000000000..92d34675acdb
--- /dev/null
+++ b/arch/arm64/kvm/hyp/include/nvhe/trap_handler.h
@@ -0,0 +1,18 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Trap handler helpers.
+ *
+ * Copyright (C) 2020 - Google LLC
+ * Author: Marc Zyngier <dbrazdil@google.com>
+ */
+
+#ifndef __ARM64_KVM_NVHE_TRAP_HANDLER_H__
+#define __ARM64_KVM_NVHE_TRAP_HANDLER_H__
+
+#include <asm/kvm_host.h>
+
+#define cpu_reg(ctxt, r) (ctxt)->regs.regs[r]
+#define DECLARE_REG(type, name, ctxt, reg) \
+ type name = (type)cpu_reg(ctxt, (reg))
+
+#endif /* __ARM64_KVM_NVHE_TRAP_HANDLER_H__ */
diff --git a/arch/arm64/kvm/hyp/nvhe/Makefile b/arch/arm64/kvm/hyp/nvhe/Makefile
index cf11f8182756..1f1e351c5fe2 100644
--- a/arch/arm64/kvm/hyp/nvhe/Makefile
+++ b/arch/arm64/kvm/hyp/nvhe/Makefile
@@ -7,7 +7,7 @@ asflags-y := -D__KVM_NVHE_HYPERVISOR__
ccflags-y := -D__KVM_NVHE_HYPERVISOR__
obj-y := timer-sr.o sysreg-sr.o debug-sr.o switch.o tlb.o hyp-init.o host.o \
- hyp-main.o hyp-smp.o
+ hyp-main.o hyp-smp.o psci-relay.o
obj-y += ../vgic-v3-sr.o ../aarch32.o ../vgic-v2-cpuif-proxy.o ../entry.o \
../fpsimd.o ../hyp-entry.o ../exception.o
diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
index f25680ede080..bde658d51404 100644
--- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
+++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
@@ -12,9 +12,7 @@
#include <asm/kvm_hyp.h>
#include <asm/kvm_mmu.h>
-#define cpu_reg(ctxt, r) (ctxt)->regs.regs[r]
-#define DECLARE_REG(type, name, ctxt, reg) \
- type name = (type)cpu_reg(ctxt, (reg))
+#include <nvhe/trap_handler.h>
DEFINE_PER_CPU(struct kvm_nvhe_init_params, kvm_init_params);
@@ -166,7 +164,11 @@ static void skip_host_instruction(void)
static void handle_host_smc(struct kvm_cpu_context *host_ctxt)
{
- default_host_smc_handler(host_ctxt);
+ bool handled;
+
+ handled = kvm_host_psci_handler(host_ctxt);
+ if (!handled)
+ default_host_smc_handler(host_ctxt);
/*
* Unlike HVC, the return address of an SMC is the instruction's PC.
diff --git a/arch/arm64/kvm/hyp/nvhe/psci-relay.c b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
new file mode 100644
index 000000000000..44a9fb462d24
--- /dev/null
+++ b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
@@ -0,0 +1,103 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2020 - Google LLC
+ * Author: David Brazdil <dbrazdil@google.com>
+ */
+
+#include <asm/kvm_asm.h>
+#include <asm/kvm_hyp.h>
+#include <asm/kvm_mmu.h>
+#include <kvm/arm_hypercalls.h>
+#include <linux/arm-smccc.h>
+#include <linux/psci.h>
+#include <kvm/arm_psci.h>
+#include <uapi/linux/psci.h>
+
+#include <nvhe/trap_handler.h>
+
+/* Config options set by the host. */
+u32 __ro_after_init kvm_host_psci_version;
+u32 __ro_after_init kvm_host_psci_function_id[PSCI_FN_MAX];
+
+static u64 get_psci_func_id(struct kvm_cpu_context *host_ctxt)
+{
+ DECLARE_REG(u64, func_id, host_ctxt, 0);
+
+ return func_id;
+}
+
+static bool is_psci_0_1_call(u64 func_id)
+{
+ unsigned int i;
+
+ for (i = 0; i < ARRAY_SIZE(kvm_host_psci_function_id); ++i) {
+ if (func_id == kvm_host_psci_function_id[i])
+ return true;
+ }
+ return false;
+}
+
+static bool is_psci_0_2_call(u64 func_id)
+{
+ /* SMCCC reserves IDs 0x00-1F with the given 32/64-bit base for PSCI. */
+ return (PSCI_0_2_FN(0) <= func_id && func_id <= PSCI_0_2_FN(31)) ||
+ (PSCI_0_2_FN64(0) <= func_id && func_id <= PSCI_0_2_FN64(31));
+}
+
+static bool is_psci_call(u64 func_id)
+{
+ switch (kvm_host_psci_version) {
+ case PSCI_VERSION(0, 1):
+ return is_psci_0_1_call(func_id);
+ default:
+ return is_psci_0_2_call(func_id);
+ }
+}
+
+static unsigned long psci_0_1_handler(u64 func_id, struct kvm_cpu_context *host_ctxt)
+{
+ return PSCI_RET_NOT_SUPPORTED;
+}
+
+static unsigned long psci_0_2_handler(u64 func_id, struct kvm_cpu_context *host_ctxt)
+{
+ switch (func_id) {
+ default:
+ return PSCI_RET_NOT_SUPPORTED;
+ }
+}
+
+static unsigned long psci_1_0_handler(u64 func_id, struct kvm_cpu_context *host_ctxt)
+{
+ switch (func_id) {
+ default:
+ return psci_0_2_handler(func_id, host_ctxt);
+ }
+}
+
+bool kvm_host_psci_handler(struct kvm_cpu_context *host_ctxt)
+{
+ u64 func_id = get_psci_func_id(host_ctxt);
+ unsigned long ret;
+
+ if (!is_psci_call(func_id))
+ return false;
+
+ switch (kvm_host_psci_version) {
+ case PSCI_VERSION(0, 1):
+ ret = psci_0_1_handler(func_id, host_ctxt);
+ break;
+ case PSCI_VERSION(0, 2):
+ ret = psci_0_2_handler(func_id, host_ctxt);
+ break;
+ default:
+ ret = psci_1_0_handler(func_id, host_ctxt);
+ break;
+ }
+
+ cpu_reg(host_ctxt, 0) = ret;
+ cpu_reg(host_ctxt, 1) = 0;
+ cpu_reg(host_ctxt, 2) = 0;
+ cpu_reg(host_ctxt, 3) = 0;
+ return true;
+}
--
2.29.2.454.gaff20da3a2-goog
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply related [flat|nested] 147+ messages in thread
* [PATCH v3 15/23] kvm: arm64: Add offset for hyp VA <-> PA conversion
2020-11-26 15:53 ` David Brazdil
(?)
@ 2020-11-26 15:54 ` David Brazdil
-1 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Jonathan Corbet, Catalin Marinas, Will Deacon, Marc Zyngier,
James Morse, Julien Thierry, Suzuki K Poulose, Dennis Zhou,
Tejun Heo, Christoph Lameter, Mark Rutland, Lorenzo Pieralisi,
Sudeep Holla, linux-doc, linux-kernel, linux-arm-kernel,
kernel-team, David Brazdil
Add a host-initialized constant to KVM nVHE hyp code for converting
between EL2 linear map virtual addresses and physical addresses.
Also add `__hyp_pa` macro that performs the conversion.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
arch/arm64/kvm/hyp/nvhe/psci-relay.c | 3 +++
arch/arm64/kvm/va_layout.c | 30 +++++++++++++++++++++++++---
2 files changed, 30 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/kvm/hyp/nvhe/psci-relay.c b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
index 44a9fb462d24..e7091d89f0fc 100644
--- a/arch/arm64/kvm/hyp/nvhe/psci-relay.c
+++ b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
@@ -18,6 +18,9 @@
/* Config options set by the host. */
u32 __ro_after_init kvm_host_psci_version;
u32 __ro_after_init kvm_host_psci_function_id[PSCI_FN_MAX];
+s64 __ro_after_init hyp_physvirt_offset;
+
+#define __hyp_pa(x) ((phys_addr_t)((x)) + hyp_physvirt_offset)
static u64 get_psci_func_id(struct kvm_cpu_context *host_ctxt)
{
diff --git a/arch/arm64/kvm/va_layout.c b/arch/arm64/kvm/va_layout.c
index 4130b72e6891..d8cc51bd60bf 100644
--- a/arch/arm64/kvm/va_layout.c
+++ b/arch/arm64/kvm/va_layout.c
@@ -23,6 +23,30 @@ static u8 tag_lsb;
static u64 tag_val;
static u64 va_mask;
+/*
+ * Compute HYP VA by using the same computation as kern_hyp_va().
+ */
+static u64 __early_kern_hyp_va(u64 addr)
+{
+ addr &= va_mask;
+ addr |= tag_val << tag_lsb;
+ return addr;
+}
+
+/*
+ * Store a hyp VA <-> PA offset into a hyp-owned variable.
+ */
+static void init_hyp_physvirt_offset(void)
+{
+ extern s64 kvm_nvhe_sym(hyp_physvirt_offset);
+ u64 kern_va, hyp_va;
+
+ /* Compute the offset from the hyp VA and PA of a random symbol. */
+ kern_va = (u64)kvm_ksym_ref(__hyp_text_start);
+ hyp_va = __early_kern_hyp_va(kern_va);
+ CHOOSE_NVHE_SYM(hyp_physvirt_offset) = (s64)__pa(kern_va) - (s64)hyp_va;
+}
+
/*
* We want to generate a hyp VA with the following format (with V ==
* vabits_actual):
@@ -54,6 +78,8 @@ __init void kvm_compute_layout(void)
tag_val |= get_random_long() & GENMASK_ULL(vabits_actual - 2, tag_lsb);
}
tag_val >>= tag_lsb;
+
+ init_hyp_physvirt_offset();
}
static u32 compute_instruction(int n, u32 rd, u32 rn)
@@ -146,9 +172,7 @@ void kvm_patch_vector_branch(struct alt_instr *alt,
/*
* Compute HYP VA by using the same computation as kern_hyp_va()
*/
- addr = (uintptr_t)kvm_ksym_ref(__kvm_hyp_vector);
- addr &= va_mask;
- addr |= tag_val << tag_lsb;
+ addr = __early_kern_hyp_va((u64)kvm_ksym_ref(__kvm_hyp_vector));
/* Use PC[10:7] to branch to the same vector in KVM */
addr |= ((u64)origptr & GENMASK_ULL(10, 7));
--
2.29.2.454.gaff20da3a2-goog
^ permalink raw reply related [flat|nested] 147+ messages in thread* [PATCH v3 15/23] kvm: arm64: Add offset for hyp VA <-> PA conversion
@ 2020-11-26 15:54 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Mark Rutland, Lorenzo Pieralisi, kernel-team, Jonathan Corbet,
Catalin Marinas, Suzuki K Poulose, linux-doc, linux-kernel,
Sudeep Holla, James Morse, linux-arm-kernel, Marc Zyngier,
Tejun Heo, Dennis Zhou, Christoph Lameter, David Brazdil,
Will Deacon, Julien Thierry
Add a host-initialized constant to KVM nVHE hyp code for converting
between EL2 linear map virtual addresses and physical addresses.
Also add `__hyp_pa` macro that performs the conversion.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
arch/arm64/kvm/hyp/nvhe/psci-relay.c | 3 +++
arch/arm64/kvm/va_layout.c | 30 +++++++++++++++++++++++++---
2 files changed, 30 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/kvm/hyp/nvhe/psci-relay.c b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
index 44a9fb462d24..e7091d89f0fc 100644
--- a/arch/arm64/kvm/hyp/nvhe/psci-relay.c
+++ b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
@@ -18,6 +18,9 @@
/* Config options set by the host. */
u32 __ro_after_init kvm_host_psci_version;
u32 __ro_after_init kvm_host_psci_function_id[PSCI_FN_MAX];
+s64 __ro_after_init hyp_physvirt_offset;
+
+#define __hyp_pa(x) ((phys_addr_t)((x)) + hyp_physvirt_offset)
static u64 get_psci_func_id(struct kvm_cpu_context *host_ctxt)
{
diff --git a/arch/arm64/kvm/va_layout.c b/arch/arm64/kvm/va_layout.c
index 4130b72e6891..d8cc51bd60bf 100644
--- a/arch/arm64/kvm/va_layout.c
+++ b/arch/arm64/kvm/va_layout.c
@@ -23,6 +23,30 @@ static u8 tag_lsb;
static u64 tag_val;
static u64 va_mask;
+/*
+ * Compute HYP VA by using the same computation as kern_hyp_va().
+ */
+static u64 __early_kern_hyp_va(u64 addr)
+{
+ addr &= va_mask;
+ addr |= tag_val << tag_lsb;
+ return addr;
+}
+
+/*
+ * Store a hyp VA <-> PA offset into a hyp-owned variable.
+ */
+static void init_hyp_physvirt_offset(void)
+{
+ extern s64 kvm_nvhe_sym(hyp_physvirt_offset);
+ u64 kern_va, hyp_va;
+
+ /* Compute the offset from the hyp VA and PA of a random symbol. */
+ kern_va = (u64)kvm_ksym_ref(__hyp_text_start);
+ hyp_va = __early_kern_hyp_va(kern_va);
+ CHOOSE_NVHE_SYM(hyp_physvirt_offset) = (s64)__pa(kern_va) - (s64)hyp_va;
+}
+
/*
* We want to generate a hyp VA with the following format (with V ==
* vabits_actual):
@@ -54,6 +78,8 @@ __init void kvm_compute_layout(void)
tag_val |= get_random_long() & GENMASK_ULL(vabits_actual - 2, tag_lsb);
}
tag_val >>= tag_lsb;
+
+ init_hyp_physvirt_offset();
}
static u32 compute_instruction(int n, u32 rd, u32 rn)
@@ -146,9 +172,7 @@ void kvm_patch_vector_branch(struct alt_instr *alt,
/*
* Compute HYP VA by using the same computation as kern_hyp_va()
*/
- addr = (uintptr_t)kvm_ksym_ref(__kvm_hyp_vector);
- addr &= va_mask;
- addr |= tag_val << tag_lsb;
+ addr = __early_kern_hyp_va((u64)kvm_ksym_ref(__kvm_hyp_vector));
/* Use PC[10:7] to branch to the same vector in KVM */
addr |= ((u64)origptr & GENMASK_ULL(10, 7));
--
2.29.2.454.gaff20da3a2-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 147+ messages in thread* [PATCH v3 15/23] kvm: arm64: Add offset for hyp VA <-> PA conversion
@ 2020-11-26 15:54 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Lorenzo Pieralisi, kernel-team, Jonathan Corbet, Catalin Marinas,
linux-doc, linux-kernel, Sudeep Holla, linux-arm-kernel,
Marc Zyngier, Tejun Heo, Dennis Zhou, Christoph Lameter,
Will Deacon
Add a host-initialized constant to KVM nVHE hyp code for converting
between EL2 linear map virtual addresses and physical addresses.
Also add `__hyp_pa` macro that performs the conversion.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
arch/arm64/kvm/hyp/nvhe/psci-relay.c | 3 +++
arch/arm64/kvm/va_layout.c | 30 +++++++++++++++++++++++++---
2 files changed, 30 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/kvm/hyp/nvhe/psci-relay.c b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
index 44a9fb462d24..e7091d89f0fc 100644
--- a/arch/arm64/kvm/hyp/nvhe/psci-relay.c
+++ b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
@@ -18,6 +18,9 @@
/* Config options set by the host. */
u32 __ro_after_init kvm_host_psci_version;
u32 __ro_after_init kvm_host_psci_function_id[PSCI_FN_MAX];
+s64 __ro_after_init hyp_physvirt_offset;
+
+#define __hyp_pa(x) ((phys_addr_t)((x)) + hyp_physvirt_offset)
static u64 get_psci_func_id(struct kvm_cpu_context *host_ctxt)
{
diff --git a/arch/arm64/kvm/va_layout.c b/arch/arm64/kvm/va_layout.c
index 4130b72e6891..d8cc51bd60bf 100644
--- a/arch/arm64/kvm/va_layout.c
+++ b/arch/arm64/kvm/va_layout.c
@@ -23,6 +23,30 @@ static u8 tag_lsb;
static u64 tag_val;
static u64 va_mask;
+/*
+ * Compute HYP VA by using the same computation as kern_hyp_va().
+ */
+static u64 __early_kern_hyp_va(u64 addr)
+{
+ addr &= va_mask;
+ addr |= tag_val << tag_lsb;
+ return addr;
+}
+
+/*
+ * Store a hyp VA <-> PA offset into a hyp-owned variable.
+ */
+static void init_hyp_physvirt_offset(void)
+{
+ extern s64 kvm_nvhe_sym(hyp_physvirt_offset);
+ u64 kern_va, hyp_va;
+
+ /* Compute the offset from the hyp VA and PA of a random symbol. */
+ kern_va = (u64)kvm_ksym_ref(__hyp_text_start);
+ hyp_va = __early_kern_hyp_va(kern_va);
+ CHOOSE_NVHE_SYM(hyp_physvirt_offset) = (s64)__pa(kern_va) - (s64)hyp_va;
+}
+
/*
* We want to generate a hyp VA with the following format (with V ==
* vabits_actual):
@@ -54,6 +78,8 @@ __init void kvm_compute_layout(void)
tag_val |= get_random_long() & GENMASK_ULL(vabits_actual - 2, tag_lsb);
}
tag_val >>= tag_lsb;
+
+ init_hyp_physvirt_offset();
}
static u32 compute_instruction(int n, u32 rd, u32 rn)
@@ -146,9 +172,7 @@ void kvm_patch_vector_branch(struct alt_instr *alt,
/*
* Compute HYP VA by using the same computation as kern_hyp_va()
*/
- addr = (uintptr_t)kvm_ksym_ref(__kvm_hyp_vector);
- addr &= va_mask;
- addr |= tag_val << tag_lsb;
+ addr = __early_kern_hyp_va((u64)kvm_ksym_ref(__kvm_hyp_vector));
/* Use PC[10:7] to branch to the same vector in KVM */
addr |= ((u64)origptr & GENMASK_ULL(10, 7));
--
2.29.2.454.gaff20da3a2-goog
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply related [flat|nested] 147+ messages in thread
* [PATCH v3 16/23] kvm: arm64: Forward safe PSCI SMCs coming from host
2020-11-26 15:53 ` David Brazdil
(?)
@ 2020-11-26 15:54 ` David Brazdil
-1 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Jonathan Corbet, Catalin Marinas, Will Deacon, Marc Zyngier,
James Morse, Julien Thierry, Suzuki K Poulose, Dennis Zhou,
Tejun Heo, Christoph Lameter, Mark Rutland, Lorenzo Pieralisi,
Sudeep Holla, linux-doc, linux-kernel, linux-arm-kernel,
kernel-team, David Brazdil
Forward the following PSCI SMCs issued by host to EL3 as they do not
require the hypervisor's intervention. This assumes that EL3 correctly
implements the PSCI specification.
Only function IDs implemented in Linux are included.
Where both 32-bit and 64-bit variants exist, it is assumed that the host
will always use the 64-bit variant.
* SMCs that only return information about the system
* PSCI_VERSION - PSCI version implemented by EL3
* PSCI_FEATURES - optional features supported by EL3
* AFFINITY_INFO - power state of core/cluster
* MIGRATE_INFO_TYPE - whether Trusted OS can be migrated
* MIGRATE_INFO_UP_CPU - resident core of Trusted OS
* operations which do not affect the hypervisor
* MIGRATE - migrate Trusted OS to a different core
* SET_SUSPEND_MODE - toggle OS-initiated mode
* system shutdown/reset
* SYSTEM_OFF
* SYSTEM_RESET
* SYSTEM_RESET2
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
arch/arm64/kvm/hyp/nvhe/psci-relay.c | 43 +++++++++++++++++++++++++++-
1 file changed, 42 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kvm/hyp/nvhe/psci-relay.c b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
index e7091d89f0fc..7aa87ab7f5ce 100644
--- a/arch/arm64/kvm/hyp/nvhe/psci-relay.c
+++ b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
@@ -57,14 +57,51 @@ static bool is_psci_call(u64 func_id)
}
}
+static unsigned long psci_call(unsigned long fn, unsigned long arg0,
+ unsigned long arg1, unsigned long arg2)
+{
+ struct arm_smccc_res res;
+
+ arm_smccc_1_1_smc(fn, arg0, arg1, arg2, &res);
+ return res.a0;
+}
+
+static unsigned long psci_forward(struct kvm_cpu_context *host_ctxt)
+{
+ return psci_call(cpu_reg(host_ctxt, 0), cpu_reg(host_ctxt, 1),
+ cpu_reg(host_ctxt, 2), cpu_reg(host_ctxt, 3));
+}
+
+static __noreturn unsigned long psci_forward_noreturn(struct kvm_cpu_context *host_ctxt)
+{
+ psci_forward(host_ctxt);
+ hyp_panic(); /* unreachable */
+}
+
static unsigned long psci_0_1_handler(u64 func_id, struct kvm_cpu_context *host_ctxt)
{
- return PSCI_RET_NOT_SUPPORTED;
+ if (func_id == kvm_host_psci_function_id[PSCI_FN_CPU_OFF])
+ return psci_forward(host_ctxt);
+ else if (func_id == kvm_host_psci_function_id[PSCI_FN_MIGRATE])
+ return psci_forward(host_ctxt);
+ else
+ return PSCI_RET_NOT_SUPPORTED;
}
static unsigned long psci_0_2_handler(u64 func_id, struct kvm_cpu_context *host_ctxt)
{
switch (func_id) {
+ case PSCI_0_2_FN_PSCI_VERSION:
+ case PSCI_0_2_FN_CPU_OFF:
+ case PSCI_0_2_FN64_AFFINITY_INFO:
+ case PSCI_0_2_FN64_MIGRATE:
+ case PSCI_0_2_FN_MIGRATE_INFO_TYPE:
+ case PSCI_0_2_FN64_MIGRATE_INFO_UP_CPU:
+ return psci_forward(host_ctxt);
+ case PSCI_0_2_FN_SYSTEM_OFF:
+ case PSCI_0_2_FN_SYSTEM_RESET:
+ psci_forward_noreturn(host_ctxt);
+ unreachable();
default:
return PSCI_RET_NOT_SUPPORTED;
}
@@ -73,6 +110,10 @@ static unsigned long psci_0_2_handler(u64 func_id, struct kvm_cpu_context *host_
static unsigned long psci_1_0_handler(u64 func_id, struct kvm_cpu_context *host_ctxt)
{
switch (func_id) {
+ case PSCI_1_0_FN_PSCI_FEATURES:
+ case PSCI_1_0_FN_SET_SUSPEND_MODE:
+ case PSCI_1_1_FN64_SYSTEM_RESET2:
+ return psci_forward(host_ctxt);
default:
return psci_0_2_handler(func_id, host_ctxt);
}
--
2.29.2.454.gaff20da3a2-goog
^ permalink raw reply related [flat|nested] 147+ messages in thread* [PATCH v3 16/23] kvm: arm64: Forward safe PSCI SMCs coming from host
@ 2020-11-26 15:54 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Mark Rutland, Lorenzo Pieralisi, kernel-team, Jonathan Corbet,
Catalin Marinas, Suzuki K Poulose, linux-doc, linux-kernel,
Sudeep Holla, James Morse, linux-arm-kernel, Marc Zyngier,
Tejun Heo, Dennis Zhou, Christoph Lameter, David Brazdil,
Will Deacon, Julien Thierry
Forward the following PSCI SMCs issued by host to EL3 as they do not
require the hypervisor's intervention. This assumes that EL3 correctly
implements the PSCI specification.
Only function IDs implemented in Linux are included.
Where both 32-bit and 64-bit variants exist, it is assumed that the host
will always use the 64-bit variant.
* SMCs that only return information about the system
* PSCI_VERSION - PSCI version implemented by EL3
* PSCI_FEATURES - optional features supported by EL3
* AFFINITY_INFO - power state of core/cluster
* MIGRATE_INFO_TYPE - whether Trusted OS can be migrated
* MIGRATE_INFO_UP_CPU - resident core of Trusted OS
* operations which do not affect the hypervisor
* MIGRATE - migrate Trusted OS to a different core
* SET_SUSPEND_MODE - toggle OS-initiated mode
* system shutdown/reset
* SYSTEM_OFF
* SYSTEM_RESET
* SYSTEM_RESET2
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
arch/arm64/kvm/hyp/nvhe/psci-relay.c | 43 +++++++++++++++++++++++++++-
1 file changed, 42 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kvm/hyp/nvhe/psci-relay.c b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
index e7091d89f0fc..7aa87ab7f5ce 100644
--- a/arch/arm64/kvm/hyp/nvhe/psci-relay.c
+++ b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
@@ -57,14 +57,51 @@ static bool is_psci_call(u64 func_id)
}
}
+static unsigned long psci_call(unsigned long fn, unsigned long arg0,
+ unsigned long arg1, unsigned long arg2)
+{
+ struct arm_smccc_res res;
+
+ arm_smccc_1_1_smc(fn, arg0, arg1, arg2, &res);
+ return res.a0;
+}
+
+static unsigned long psci_forward(struct kvm_cpu_context *host_ctxt)
+{
+ return psci_call(cpu_reg(host_ctxt, 0), cpu_reg(host_ctxt, 1),
+ cpu_reg(host_ctxt, 2), cpu_reg(host_ctxt, 3));
+}
+
+static __noreturn unsigned long psci_forward_noreturn(struct kvm_cpu_context *host_ctxt)
+{
+ psci_forward(host_ctxt);
+ hyp_panic(); /* unreachable */
+}
+
static unsigned long psci_0_1_handler(u64 func_id, struct kvm_cpu_context *host_ctxt)
{
- return PSCI_RET_NOT_SUPPORTED;
+ if (func_id == kvm_host_psci_function_id[PSCI_FN_CPU_OFF])
+ return psci_forward(host_ctxt);
+ else if (func_id == kvm_host_psci_function_id[PSCI_FN_MIGRATE])
+ return psci_forward(host_ctxt);
+ else
+ return PSCI_RET_NOT_SUPPORTED;
}
static unsigned long psci_0_2_handler(u64 func_id, struct kvm_cpu_context *host_ctxt)
{
switch (func_id) {
+ case PSCI_0_2_FN_PSCI_VERSION:
+ case PSCI_0_2_FN_CPU_OFF:
+ case PSCI_0_2_FN64_AFFINITY_INFO:
+ case PSCI_0_2_FN64_MIGRATE:
+ case PSCI_0_2_FN_MIGRATE_INFO_TYPE:
+ case PSCI_0_2_FN64_MIGRATE_INFO_UP_CPU:
+ return psci_forward(host_ctxt);
+ case PSCI_0_2_FN_SYSTEM_OFF:
+ case PSCI_0_2_FN_SYSTEM_RESET:
+ psci_forward_noreturn(host_ctxt);
+ unreachable();
default:
return PSCI_RET_NOT_SUPPORTED;
}
@@ -73,6 +110,10 @@ static unsigned long psci_0_2_handler(u64 func_id, struct kvm_cpu_context *host_
static unsigned long psci_1_0_handler(u64 func_id, struct kvm_cpu_context *host_ctxt)
{
switch (func_id) {
+ case PSCI_1_0_FN_PSCI_FEATURES:
+ case PSCI_1_0_FN_SET_SUSPEND_MODE:
+ case PSCI_1_1_FN64_SYSTEM_RESET2:
+ return psci_forward(host_ctxt);
default:
return psci_0_2_handler(func_id, host_ctxt);
}
--
2.29.2.454.gaff20da3a2-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 147+ messages in thread* [PATCH v3 16/23] kvm: arm64: Forward safe PSCI SMCs coming from host
@ 2020-11-26 15:54 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Lorenzo Pieralisi, kernel-team, Jonathan Corbet, Catalin Marinas,
linux-doc, linux-kernel, Sudeep Holla, linux-arm-kernel,
Marc Zyngier, Tejun Heo, Dennis Zhou, Christoph Lameter,
Will Deacon
Forward the following PSCI SMCs issued by host to EL3 as they do not
require the hypervisor's intervention. This assumes that EL3 correctly
implements the PSCI specification.
Only function IDs implemented in Linux are included.
Where both 32-bit and 64-bit variants exist, it is assumed that the host
will always use the 64-bit variant.
* SMCs that only return information about the system
* PSCI_VERSION - PSCI version implemented by EL3
* PSCI_FEATURES - optional features supported by EL3
* AFFINITY_INFO - power state of core/cluster
* MIGRATE_INFO_TYPE - whether Trusted OS can be migrated
* MIGRATE_INFO_UP_CPU - resident core of Trusted OS
* operations which do not affect the hypervisor
* MIGRATE - migrate Trusted OS to a different core
* SET_SUSPEND_MODE - toggle OS-initiated mode
* system shutdown/reset
* SYSTEM_OFF
* SYSTEM_RESET
* SYSTEM_RESET2
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
arch/arm64/kvm/hyp/nvhe/psci-relay.c | 43 +++++++++++++++++++++++++++-
1 file changed, 42 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kvm/hyp/nvhe/psci-relay.c b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
index e7091d89f0fc..7aa87ab7f5ce 100644
--- a/arch/arm64/kvm/hyp/nvhe/psci-relay.c
+++ b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
@@ -57,14 +57,51 @@ static bool is_psci_call(u64 func_id)
}
}
+static unsigned long psci_call(unsigned long fn, unsigned long arg0,
+ unsigned long arg1, unsigned long arg2)
+{
+ struct arm_smccc_res res;
+
+ arm_smccc_1_1_smc(fn, arg0, arg1, arg2, &res);
+ return res.a0;
+}
+
+static unsigned long psci_forward(struct kvm_cpu_context *host_ctxt)
+{
+ return psci_call(cpu_reg(host_ctxt, 0), cpu_reg(host_ctxt, 1),
+ cpu_reg(host_ctxt, 2), cpu_reg(host_ctxt, 3));
+}
+
+static __noreturn unsigned long psci_forward_noreturn(struct kvm_cpu_context *host_ctxt)
+{
+ psci_forward(host_ctxt);
+ hyp_panic(); /* unreachable */
+}
+
static unsigned long psci_0_1_handler(u64 func_id, struct kvm_cpu_context *host_ctxt)
{
- return PSCI_RET_NOT_SUPPORTED;
+ if (func_id == kvm_host_psci_function_id[PSCI_FN_CPU_OFF])
+ return psci_forward(host_ctxt);
+ else if (func_id == kvm_host_psci_function_id[PSCI_FN_MIGRATE])
+ return psci_forward(host_ctxt);
+ else
+ return PSCI_RET_NOT_SUPPORTED;
}
static unsigned long psci_0_2_handler(u64 func_id, struct kvm_cpu_context *host_ctxt)
{
switch (func_id) {
+ case PSCI_0_2_FN_PSCI_VERSION:
+ case PSCI_0_2_FN_CPU_OFF:
+ case PSCI_0_2_FN64_AFFINITY_INFO:
+ case PSCI_0_2_FN64_MIGRATE:
+ case PSCI_0_2_FN_MIGRATE_INFO_TYPE:
+ case PSCI_0_2_FN64_MIGRATE_INFO_UP_CPU:
+ return psci_forward(host_ctxt);
+ case PSCI_0_2_FN_SYSTEM_OFF:
+ case PSCI_0_2_FN_SYSTEM_RESET:
+ psci_forward_noreturn(host_ctxt);
+ unreachable();
default:
return PSCI_RET_NOT_SUPPORTED;
}
@@ -73,6 +110,10 @@ static unsigned long psci_0_2_handler(u64 func_id, struct kvm_cpu_context *host_
static unsigned long psci_1_0_handler(u64 func_id, struct kvm_cpu_context *host_ctxt)
{
switch (func_id) {
+ case PSCI_1_0_FN_PSCI_FEATURES:
+ case PSCI_1_0_FN_SET_SUSPEND_MODE:
+ case PSCI_1_1_FN64_SYSTEM_RESET2:
+ return psci_forward(host_ctxt);
default:
return psci_0_2_handler(func_id, host_ctxt);
}
--
2.29.2.454.gaff20da3a2-goog
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply related [flat|nested] 147+ messages in thread* Re: [PATCH v3 16/23] kvm: arm64: Forward safe PSCI SMCs coming from host
2020-11-26 15:54 ` David Brazdil
(?)
@ 2020-11-27 10:14 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 147+ messages in thread
From: Lorenzo Pieralisi @ 2020-11-27 10:14 UTC (permalink / raw)
To: David Brazdil
Cc: kvmarm, Jonathan Corbet, Catalin Marinas, Will Deacon,
Marc Zyngier, James Morse, Julien Thierry, Suzuki K Poulose,
Dennis Zhou, Tejun Heo, Christoph Lameter, Mark Rutland,
Sudeep Holla, linux-doc, linux-kernel, linux-arm-kernel,
kernel-team
On Thu, Nov 26, 2020 at 03:54:14PM +0000, David Brazdil wrote:
> Forward the following PSCI SMCs issued by host to EL3 as they do not
> require the hypervisor's intervention. This assumes that EL3 correctly
> implements the PSCI specification.
>
> Only function IDs implemented in Linux are included.
>
> Where both 32-bit and 64-bit variants exist, it is assumed that the host
> will always use the 64-bit variant.
>
> * SMCs that only return information about the system
> * PSCI_VERSION - PSCI version implemented by EL3
> * PSCI_FEATURES - optional features supported by EL3
> * AFFINITY_INFO - power state of core/cluster
> * MIGRATE_INFO_TYPE - whether Trusted OS can be migrated
> * MIGRATE_INFO_UP_CPU - resident core of Trusted OS
> * operations which do not affect the hypervisor
> * MIGRATE - migrate Trusted OS to a different core
> * SET_SUSPEND_MODE - toggle OS-initiated mode
> * system shutdown/reset
> * SYSTEM_OFF
> * SYSTEM_RESET
> * SYSTEM_RESET2
What about SYSTEM_SUSPEND ?
Lorenzo
> Signed-off-by: David Brazdil <dbrazdil@google.com>
> ---
> arch/arm64/kvm/hyp/nvhe/psci-relay.c | 43 +++++++++++++++++++++++++++-
> 1 file changed, 42 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kvm/hyp/nvhe/psci-relay.c b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
> index e7091d89f0fc..7aa87ab7f5ce 100644
> --- a/arch/arm64/kvm/hyp/nvhe/psci-relay.c
> +++ b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
> @@ -57,14 +57,51 @@ static bool is_psci_call(u64 func_id)
> }
> }
>
> +static unsigned long psci_call(unsigned long fn, unsigned long arg0,
> + unsigned long arg1, unsigned long arg2)
> +{
> + struct arm_smccc_res res;
> +
> + arm_smccc_1_1_smc(fn, arg0, arg1, arg2, &res);
> + return res.a0;
> +}
> +
> +static unsigned long psci_forward(struct kvm_cpu_context *host_ctxt)
> +{
> + return psci_call(cpu_reg(host_ctxt, 0), cpu_reg(host_ctxt, 1),
> + cpu_reg(host_ctxt, 2), cpu_reg(host_ctxt, 3));
> +}
> +
> +static __noreturn unsigned long psci_forward_noreturn(struct kvm_cpu_context *host_ctxt)
> +{
> + psci_forward(host_ctxt);
> + hyp_panic(); /* unreachable */
> +}
> +
> static unsigned long psci_0_1_handler(u64 func_id, struct kvm_cpu_context *host_ctxt)
> {
> - return PSCI_RET_NOT_SUPPORTED;
> + if (func_id == kvm_host_psci_function_id[PSCI_FN_CPU_OFF])
> + return psci_forward(host_ctxt);
> + else if (func_id == kvm_host_psci_function_id[PSCI_FN_MIGRATE])
> + return psci_forward(host_ctxt);
> + else
> + return PSCI_RET_NOT_SUPPORTED;
> }
>
> static unsigned long psci_0_2_handler(u64 func_id, struct kvm_cpu_context *host_ctxt)
> {
> switch (func_id) {
> + case PSCI_0_2_FN_PSCI_VERSION:
> + case PSCI_0_2_FN_CPU_OFF:
> + case PSCI_0_2_FN64_AFFINITY_INFO:
> + case PSCI_0_2_FN64_MIGRATE:
> + case PSCI_0_2_FN_MIGRATE_INFO_TYPE:
> + case PSCI_0_2_FN64_MIGRATE_INFO_UP_CPU:
> + return psci_forward(host_ctxt);
> + case PSCI_0_2_FN_SYSTEM_OFF:
> + case PSCI_0_2_FN_SYSTEM_RESET:
> + psci_forward_noreturn(host_ctxt);
> + unreachable();
> default:
> return PSCI_RET_NOT_SUPPORTED;
> }
> @@ -73,6 +110,10 @@ static unsigned long psci_0_2_handler(u64 func_id, struct kvm_cpu_context *host_
> static unsigned long psci_1_0_handler(u64 func_id, struct kvm_cpu_context *host_ctxt)
> {
> switch (func_id) {
> + case PSCI_1_0_FN_PSCI_FEATURES:
> + case PSCI_1_0_FN_SET_SUSPEND_MODE:
> + case PSCI_1_1_FN64_SYSTEM_RESET2:
> + return psci_forward(host_ctxt);
> default:
> return psci_0_2_handler(func_id, host_ctxt);
> }
> --
> 2.29.2.454.gaff20da3a2-goog
>
^ permalink raw reply [flat|nested] 147+ messages in thread* Re: [PATCH v3 16/23] kvm: arm64: Forward safe PSCI SMCs coming from host
@ 2020-11-27 10:14 ` Lorenzo Pieralisi
0 siblings, 0 replies; 147+ messages in thread
From: Lorenzo Pieralisi @ 2020-11-27 10:14 UTC (permalink / raw)
To: David Brazdil
Cc: Mark Rutland, Sudeep Holla, kernel-team, Jonathan Corbet,
Catalin Marinas, Suzuki K Poulose, linux-doc, linux-kernel,
James Morse, linux-arm-kernel, Marc Zyngier, Tejun Heo,
Dennis Zhou, Christoph Lameter, Will Deacon, kvmarm,
Julien Thierry
On Thu, Nov 26, 2020 at 03:54:14PM +0000, David Brazdil wrote:
> Forward the following PSCI SMCs issued by host to EL3 as they do not
> require the hypervisor's intervention. This assumes that EL3 correctly
> implements the PSCI specification.
>
> Only function IDs implemented in Linux are included.
>
> Where both 32-bit and 64-bit variants exist, it is assumed that the host
> will always use the 64-bit variant.
>
> * SMCs that only return information about the system
> * PSCI_VERSION - PSCI version implemented by EL3
> * PSCI_FEATURES - optional features supported by EL3
> * AFFINITY_INFO - power state of core/cluster
> * MIGRATE_INFO_TYPE - whether Trusted OS can be migrated
> * MIGRATE_INFO_UP_CPU - resident core of Trusted OS
> * operations which do not affect the hypervisor
> * MIGRATE - migrate Trusted OS to a different core
> * SET_SUSPEND_MODE - toggle OS-initiated mode
> * system shutdown/reset
> * SYSTEM_OFF
> * SYSTEM_RESET
> * SYSTEM_RESET2
What about SYSTEM_SUSPEND ?
Lorenzo
> Signed-off-by: David Brazdil <dbrazdil@google.com>
> ---
> arch/arm64/kvm/hyp/nvhe/psci-relay.c | 43 +++++++++++++++++++++++++++-
> 1 file changed, 42 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kvm/hyp/nvhe/psci-relay.c b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
> index e7091d89f0fc..7aa87ab7f5ce 100644
> --- a/arch/arm64/kvm/hyp/nvhe/psci-relay.c
> +++ b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
> @@ -57,14 +57,51 @@ static bool is_psci_call(u64 func_id)
> }
> }
>
> +static unsigned long psci_call(unsigned long fn, unsigned long arg0,
> + unsigned long arg1, unsigned long arg2)
> +{
> + struct arm_smccc_res res;
> +
> + arm_smccc_1_1_smc(fn, arg0, arg1, arg2, &res);
> + return res.a0;
> +}
> +
> +static unsigned long psci_forward(struct kvm_cpu_context *host_ctxt)
> +{
> + return psci_call(cpu_reg(host_ctxt, 0), cpu_reg(host_ctxt, 1),
> + cpu_reg(host_ctxt, 2), cpu_reg(host_ctxt, 3));
> +}
> +
> +static __noreturn unsigned long psci_forward_noreturn(struct kvm_cpu_context *host_ctxt)
> +{
> + psci_forward(host_ctxt);
> + hyp_panic(); /* unreachable */
> +}
> +
> static unsigned long psci_0_1_handler(u64 func_id, struct kvm_cpu_context *host_ctxt)
> {
> - return PSCI_RET_NOT_SUPPORTED;
> + if (func_id == kvm_host_psci_function_id[PSCI_FN_CPU_OFF])
> + return psci_forward(host_ctxt);
> + else if (func_id == kvm_host_psci_function_id[PSCI_FN_MIGRATE])
> + return psci_forward(host_ctxt);
> + else
> + return PSCI_RET_NOT_SUPPORTED;
> }
>
> static unsigned long psci_0_2_handler(u64 func_id, struct kvm_cpu_context *host_ctxt)
> {
> switch (func_id) {
> + case PSCI_0_2_FN_PSCI_VERSION:
> + case PSCI_0_2_FN_CPU_OFF:
> + case PSCI_0_2_FN64_AFFINITY_INFO:
> + case PSCI_0_2_FN64_MIGRATE:
> + case PSCI_0_2_FN_MIGRATE_INFO_TYPE:
> + case PSCI_0_2_FN64_MIGRATE_INFO_UP_CPU:
> + return psci_forward(host_ctxt);
> + case PSCI_0_2_FN_SYSTEM_OFF:
> + case PSCI_0_2_FN_SYSTEM_RESET:
> + psci_forward_noreturn(host_ctxt);
> + unreachable();
> default:
> return PSCI_RET_NOT_SUPPORTED;
> }
> @@ -73,6 +110,10 @@ static unsigned long psci_0_2_handler(u64 func_id, struct kvm_cpu_context *host_
> static unsigned long psci_1_0_handler(u64 func_id, struct kvm_cpu_context *host_ctxt)
> {
> switch (func_id) {
> + case PSCI_1_0_FN_PSCI_FEATURES:
> + case PSCI_1_0_FN_SET_SUSPEND_MODE:
> + case PSCI_1_1_FN64_SYSTEM_RESET2:
> + return psci_forward(host_ctxt);
> default:
> return psci_0_2_handler(func_id, host_ctxt);
> }
> --
> 2.29.2.454.gaff20da3a2-goog
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 147+ messages in thread* Re: [PATCH v3 16/23] kvm: arm64: Forward safe PSCI SMCs coming from host
@ 2020-11-27 10:14 ` Lorenzo Pieralisi
0 siblings, 0 replies; 147+ messages in thread
From: Lorenzo Pieralisi @ 2020-11-27 10:14 UTC (permalink / raw)
To: David Brazdil
Cc: Sudeep Holla, kernel-team, Jonathan Corbet, Catalin Marinas,
linux-doc, linux-kernel, linux-arm-kernel, Marc Zyngier,
Tejun Heo, Dennis Zhou, Christoph Lameter, Will Deacon, kvmarm
On Thu, Nov 26, 2020 at 03:54:14PM +0000, David Brazdil wrote:
> Forward the following PSCI SMCs issued by host to EL3 as they do not
> require the hypervisor's intervention. This assumes that EL3 correctly
> implements the PSCI specification.
>
> Only function IDs implemented in Linux are included.
>
> Where both 32-bit and 64-bit variants exist, it is assumed that the host
> will always use the 64-bit variant.
>
> * SMCs that only return information about the system
> * PSCI_VERSION - PSCI version implemented by EL3
> * PSCI_FEATURES - optional features supported by EL3
> * AFFINITY_INFO - power state of core/cluster
> * MIGRATE_INFO_TYPE - whether Trusted OS can be migrated
> * MIGRATE_INFO_UP_CPU - resident core of Trusted OS
> * operations which do not affect the hypervisor
> * MIGRATE - migrate Trusted OS to a different core
> * SET_SUSPEND_MODE - toggle OS-initiated mode
> * system shutdown/reset
> * SYSTEM_OFF
> * SYSTEM_RESET
> * SYSTEM_RESET2
What about SYSTEM_SUSPEND ?
Lorenzo
> Signed-off-by: David Brazdil <dbrazdil@google.com>
> ---
> arch/arm64/kvm/hyp/nvhe/psci-relay.c | 43 +++++++++++++++++++++++++++-
> 1 file changed, 42 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kvm/hyp/nvhe/psci-relay.c b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
> index e7091d89f0fc..7aa87ab7f5ce 100644
> --- a/arch/arm64/kvm/hyp/nvhe/psci-relay.c
> +++ b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
> @@ -57,14 +57,51 @@ static bool is_psci_call(u64 func_id)
> }
> }
>
> +static unsigned long psci_call(unsigned long fn, unsigned long arg0,
> + unsigned long arg1, unsigned long arg2)
> +{
> + struct arm_smccc_res res;
> +
> + arm_smccc_1_1_smc(fn, arg0, arg1, arg2, &res);
> + return res.a0;
> +}
> +
> +static unsigned long psci_forward(struct kvm_cpu_context *host_ctxt)
> +{
> + return psci_call(cpu_reg(host_ctxt, 0), cpu_reg(host_ctxt, 1),
> + cpu_reg(host_ctxt, 2), cpu_reg(host_ctxt, 3));
> +}
> +
> +static __noreturn unsigned long psci_forward_noreturn(struct kvm_cpu_context *host_ctxt)
> +{
> + psci_forward(host_ctxt);
> + hyp_panic(); /* unreachable */
> +}
> +
> static unsigned long psci_0_1_handler(u64 func_id, struct kvm_cpu_context *host_ctxt)
> {
> - return PSCI_RET_NOT_SUPPORTED;
> + if (func_id == kvm_host_psci_function_id[PSCI_FN_CPU_OFF])
> + return psci_forward(host_ctxt);
> + else if (func_id == kvm_host_psci_function_id[PSCI_FN_MIGRATE])
> + return psci_forward(host_ctxt);
> + else
> + return PSCI_RET_NOT_SUPPORTED;
> }
>
> static unsigned long psci_0_2_handler(u64 func_id, struct kvm_cpu_context *host_ctxt)
> {
> switch (func_id) {
> + case PSCI_0_2_FN_PSCI_VERSION:
> + case PSCI_0_2_FN_CPU_OFF:
> + case PSCI_0_2_FN64_AFFINITY_INFO:
> + case PSCI_0_2_FN64_MIGRATE:
> + case PSCI_0_2_FN_MIGRATE_INFO_TYPE:
> + case PSCI_0_2_FN64_MIGRATE_INFO_UP_CPU:
> + return psci_forward(host_ctxt);
> + case PSCI_0_2_FN_SYSTEM_OFF:
> + case PSCI_0_2_FN_SYSTEM_RESET:
> + psci_forward_noreturn(host_ctxt);
> + unreachable();
> default:
> return PSCI_RET_NOT_SUPPORTED;
> }
> @@ -73,6 +110,10 @@ static unsigned long psci_0_2_handler(u64 func_id, struct kvm_cpu_context *host_
> static unsigned long psci_1_0_handler(u64 func_id, struct kvm_cpu_context *host_ctxt)
> {
> switch (func_id) {
> + case PSCI_1_0_FN_PSCI_FEATURES:
> + case PSCI_1_0_FN_SET_SUSPEND_MODE:
> + case PSCI_1_1_FN64_SYSTEM_RESET2:
> + return psci_forward(host_ctxt);
> default:
> return psci_0_2_handler(func_id, host_ctxt);
> }
> --
> 2.29.2.454.gaff20da3a2-goog
>
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 147+ messages in thread* Re: [PATCH v3 16/23] kvm: arm64: Forward safe PSCI SMCs coming from host
2020-11-27 10:14 ` Lorenzo Pieralisi
(?)
@ 2020-12-02 17:49 ` David Brazdil
-1 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-12-02 17:49 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: kvmarm, Jonathan Corbet, Catalin Marinas, Will Deacon,
Marc Zyngier, James Morse, Julien Thierry, Suzuki K Poulose,
Dennis Zhou, Tejun Heo, Christoph Lameter, Mark Rutland,
Sudeep Holla, linux-doc, linux-kernel, linux-arm-kernel,
kernel-team
On Fri, Nov 27, 2020 at 10:14:33AM +0000, Lorenzo Pieralisi wrote:
> On Thu, Nov 26, 2020 at 03:54:14PM +0000, David Brazdil wrote:
> > Forward the following PSCI SMCs issued by host to EL3 as they do not
> > require the hypervisor's intervention. This assumes that EL3 correctly
> > implements the PSCI specification.
> >
> > Only function IDs implemented in Linux are included.
> >
> > Where both 32-bit and 64-bit variants exist, it is assumed that the host
> > will always use the 64-bit variant.
> >
> > * SMCs that only return information about the system
> > * PSCI_VERSION - PSCI version implemented by EL3
> > * PSCI_FEATURES - optional features supported by EL3
> > * AFFINITY_INFO - power state of core/cluster
> > * MIGRATE_INFO_TYPE - whether Trusted OS can be migrated
> > * MIGRATE_INFO_UP_CPU - resident core of Trusted OS
> > * operations which do not affect the hypervisor
> > * MIGRATE - migrate Trusted OS to a different core
> > * SET_SUSPEND_MODE - toggle OS-initiated mode
> > * system shutdown/reset
> > * SYSTEM_OFF
> > * SYSTEM_RESET
> > * SYSTEM_RESET2
>
> What about SYSTEM_SUSPEND ?
Oops, forgot that one. Will add a handler similar to CPU_SUSPEND.
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v3 16/23] kvm: arm64: Forward safe PSCI SMCs coming from host
@ 2020-12-02 17:49 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-12-02 17:49 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Mark Rutland, Sudeep Holla, kernel-team, Jonathan Corbet,
Catalin Marinas, Suzuki K Poulose, linux-doc, linux-kernel,
James Morse, linux-arm-kernel, Marc Zyngier, Tejun Heo,
Dennis Zhou, Christoph Lameter, Will Deacon, kvmarm,
Julien Thierry
On Fri, Nov 27, 2020 at 10:14:33AM +0000, Lorenzo Pieralisi wrote:
> On Thu, Nov 26, 2020 at 03:54:14PM +0000, David Brazdil wrote:
> > Forward the following PSCI SMCs issued by host to EL3 as they do not
> > require the hypervisor's intervention. This assumes that EL3 correctly
> > implements the PSCI specification.
> >
> > Only function IDs implemented in Linux are included.
> >
> > Where both 32-bit and 64-bit variants exist, it is assumed that the host
> > will always use the 64-bit variant.
> >
> > * SMCs that only return information about the system
> > * PSCI_VERSION - PSCI version implemented by EL3
> > * PSCI_FEATURES - optional features supported by EL3
> > * AFFINITY_INFO - power state of core/cluster
> > * MIGRATE_INFO_TYPE - whether Trusted OS can be migrated
> > * MIGRATE_INFO_UP_CPU - resident core of Trusted OS
> > * operations which do not affect the hypervisor
> > * MIGRATE - migrate Trusted OS to a different core
> > * SET_SUSPEND_MODE - toggle OS-initiated mode
> > * system shutdown/reset
> > * SYSTEM_OFF
> > * SYSTEM_RESET
> > * SYSTEM_RESET2
>
> What about SYSTEM_SUSPEND ?
Oops, forgot that one. Will add a handler similar to CPU_SUSPEND.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v3 16/23] kvm: arm64: Forward safe PSCI SMCs coming from host
@ 2020-12-02 17:49 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-12-02 17:49 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Sudeep Holla, kernel-team, Jonathan Corbet, Catalin Marinas,
linux-doc, linux-kernel, linux-arm-kernel, Marc Zyngier,
Tejun Heo, Dennis Zhou, Christoph Lameter, Will Deacon, kvmarm
On Fri, Nov 27, 2020 at 10:14:33AM +0000, Lorenzo Pieralisi wrote:
> On Thu, Nov 26, 2020 at 03:54:14PM +0000, David Brazdil wrote:
> > Forward the following PSCI SMCs issued by host to EL3 as they do not
> > require the hypervisor's intervention. This assumes that EL3 correctly
> > implements the PSCI specification.
> >
> > Only function IDs implemented in Linux are included.
> >
> > Where both 32-bit and 64-bit variants exist, it is assumed that the host
> > will always use the 64-bit variant.
> >
> > * SMCs that only return information about the system
> > * PSCI_VERSION - PSCI version implemented by EL3
> > * PSCI_FEATURES - optional features supported by EL3
> > * AFFINITY_INFO - power state of core/cluster
> > * MIGRATE_INFO_TYPE - whether Trusted OS can be migrated
> > * MIGRATE_INFO_UP_CPU - resident core of Trusted OS
> > * operations which do not affect the hypervisor
> > * MIGRATE - migrate Trusted OS to a different core
> > * SET_SUSPEND_MODE - toggle OS-initiated mode
> > * system shutdown/reset
> > * SYSTEM_OFF
> > * SYSTEM_RESET
> > * SYSTEM_RESET2
>
> What about SYSTEM_SUSPEND ?
Oops, forgot that one. Will add a handler similar to CPU_SUSPEND.
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v3 16/23] kvm: arm64: Forward safe PSCI SMCs coming from host
2020-11-26 15:54 ` David Brazdil
(?)
@ 2020-11-27 16:51 ` Sudeep Holla
-1 siblings, 0 replies; 147+ messages in thread
From: Sudeep Holla @ 2020-11-27 16:51 UTC (permalink / raw)
To: David Brazdil
Cc: kvmarm, Jonathan Corbet, Catalin Marinas, Will Deacon,
Marc Zyngier, James Morse, Julien Thierry, Suzuki K Poulose,
Dennis Zhou, Tejun Heo, Christoph Lameter, Mark Rutland,
Lorenzo Pieralisi, linux-doc, linux-kernel, linux-arm-kernel,
kernel-team
On Thu, Nov 26, 2020 at 03:54:14PM +0000, David Brazdil wrote:
> Forward the following PSCI SMCs issued by host to EL3 as they do not
> require the hypervisor's intervention. This assumes that EL3 correctly
> implements the PSCI specification.
>
> Only function IDs implemented in Linux are included.
>
> Where both 32-bit and 64-bit variants exist, it is assumed that the host
> will always use the 64-bit variant.
>
> * SMCs that only return information about the system
> * PSCI_VERSION - PSCI version implemented by EL3
> * PSCI_FEATURES - optional features supported by EL3
> * AFFINITY_INFO - power state of core/cluster
> * MIGRATE_INFO_TYPE - whether Trusted OS can be migrated
> * MIGRATE_INFO_UP_CPU - resident core of Trusted OS
> * operations which do not affect the hypervisor
> * MIGRATE - migrate Trusted OS to a different core
> * SET_SUSPEND_MODE - toggle OS-initiated mode
> * system shutdown/reset
> * SYSTEM_OFF
> * SYSTEM_RESET
> * SYSTEM_RESET2
>
> Signed-off-by: David Brazdil <dbrazdil@google.com>
> ---
> arch/arm64/kvm/hyp/nvhe/psci-relay.c | 43 +++++++++++++++++++++++++++-
> 1 file changed, 42 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kvm/hyp/nvhe/psci-relay.c b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
> index e7091d89f0fc..7aa87ab7f5ce 100644
> --- a/arch/arm64/kvm/hyp/nvhe/psci-relay.c
> +++ b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
> @@ -57,14 +57,51 @@ static bool is_psci_call(u64 func_id)
> }
> }
>
> +static unsigned long psci_call(unsigned long fn, unsigned long arg0,
> + unsigned long arg1, unsigned long arg2)
> +{
> + struct arm_smccc_res res;
> +
> + arm_smccc_1_1_smc(fn, arg0, arg1, arg2, &res);
> + return res.a0;
> +}
> +
> +static unsigned long psci_forward(struct kvm_cpu_context *host_ctxt)
> +{
> + return psci_call(cpu_reg(host_ctxt, 0), cpu_reg(host_ctxt, 1),
> + cpu_reg(host_ctxt, 2), cpu_reg(host_ctxt, 3));
> +}
> +
> +static __noreturn unsigned long psci_forward_noreturn(struct kvm_cpu_context *host_ctxt)
> +{
> + psci_forward(host_ctxt);
> + hyp_panic(); /* unreachable */
> +}
> +
> static unsigned long psci_0_1_handler(u64 func_id, struct kvm_cpu_context *host_ctxt)
> {
> - return PSCI_RET_NOT_SUPPORTED;
> + if (func_id == kvm_host_psci_function_id[PSCI_FN_CPU_OFF])
> + return psci_forward(host_ctxt);
> + else if (func_id == kvm_host_psci_function_id[PSCI_FN_MIGRATE])
> + return psci_forward(host_ctxt);
Looks weird or I am not seeing something right ? Same action for both
right ? Can't they be combined ?
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 147+ messages in thread* Re: [PATCH v3 16/23] kvm: arm64: Forward safe PSCI SMCs coming from host
@ 2020-11-27 16:51 ` Sudeep Holla
0 siblings, 0 replies; 147+ messages in thread
From: Sudeep Holla @ 2020-11-27 16:51 UTC (permalink / raw)
To: David Brazdil
Cc: Mark Rutland, Lorenzo Pieralisi, kernel-team, Jonathan Corbet,
Catalin Marinas, Suzuki K Poulose, linux-doc, linux-kernel,
James Morse, linux-arm-kernel, Marc Zyngier, Tejun Heo,
Dennis Zhou, Christoph Lameter, Will Deacon, kvmarm,
Julien Thierry
On Thu, Nov 26, 2020 at 03:54:14PM +0000, David Brazdil wrote:
> Forward the following PSCI SMCs issued by host to EL3 as they do not
> require the hypervisor's intervention. This assumes that EL3 correctly
> implements the PSCI specification.
>
> Only function IDs implemented in Linux are included.
>
> Where both 32-bit and 64-bit variants exist, it is assumed that the host
> will always use the 64-bit variant.
>
> * SMCs that only return information about the system
> * PSCI_VERSION - PSCI version implemented by EL3
> * PSCI_FEATURES - optional features supported by EL3
> * AFFINITY_INFO - power state of core/cluster
> * MIGRATE_INFO_TYPE - whether Trusted OS can be migrated
> * MIGRATE_INFO_UP_CPU - resident core of Trusted OS
> * operations which do not affect the hypervisor
> * MIGRATE - migrate Trusted OS to a different core
> * SET_SUSPEND_MODE - toggle OS-initiated mode
> * system shutdown/reset
> * SYSTEM_OFF
> * SYSTEM_RESET
> * SYSTEM_RESET2
>
> Signed-off-by: David Brazdil <dbrazdil@google.com>
> ---
> arch/arm64/kvm/hyp/nvhe/psci-relay.c | 43 +++++++++++++++++++++++++++-
> 1 file changed, 42 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kvm/hyp/nvhe/psci-relay.c b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
> index e7091d89f0fc..7aa87ab7f5ce 100644
> --- a/arch/arm64/kvm/hyp/nvhe/psci-relay.c
> +++ b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
> @@ -57,14 +57,51 @@ static bool is_psci_call(u64 func_id)
> }
> }
>
> +static unsigned long psci_call(unsigned long fn, unsigned long arg0,
> + unsigned long arg1, unsigned long arg2)
> +{
> + struct arm_smccc_res res;
> +
> + arm_smccc_1_1_smc(fn, arg0, arg1, arg2, &res);
> + return res.a0;
> +}
> +
> +static unsigned long psci_forward(struct kvm_cpu_context *host_ctxt)
> +{
> + return psci_call(cpu_reg(host_ctxt, 0), cpu_reg(host_ctxt, 1),
> + cpu_reg(host_ctxt, 2), cpu_reg(host_ctxt, 3));
> +}
> +
> +static __noreturn unsigned long psci_forward_noreturn(struct kvm_cpu_context *host_ctxt)
> +{
> + psci_forward(host_ctxt);
> + hyp_panic(); /* unreachable */
> +}
> +
> static unsigned long psci_0_1_handler(u64 func_id, struct kvm_cpu_context *host_ctxt)
> {
> - return PSCI_RET_NOT_SUPPORTED;
> + if (func_id == kvm_host_psci_function_id[PSCI_FN_CPU_OFF])
> + return psci_forward(host_ctxt);
> + else if (func_id == kvm_host_psci_function_id[PSCI_FN_MIGRATE])
> + return psci_forward(host_ctxt);
Looks weird or I am not seeing something right ? Same action for both
right ? Can't they be combined ?
--
Regards,
Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 147+ messages in thread* Re: [PATCH v3 16/23] kvm: arm64: Forward safe PSCI SMCs coming from host
@ 2020-11-27 16:51 ` Sudeep Holla
0 siblings, 0 replies; 147+ messages in thread
From: Sudeep Holla @ 2020-11-27 16:51 UTC (permalink / raw)
To: David Brazdil
Cc: Lorenzo Pieralisi, kernel-team, Jonathan Corbet, Catalin Marinas,
linux-doc, linux-kernel, linux-arm-kernel, Marc Zyngier,
Tejun Heo, Dennis Zhou, Christoph Lameter, Will Deacon, kvmarm
On Thu, Nov 26, 2020 at 03:54:14PM +0000, David Brazdil wrote:
> Forward the following PSCI SMCs issued by host to EL3 as they do not
> require the hypervisor's intervention. This assumes that EL3 correctly
> implements the PSCI specification.
>
> Only function IDs implemented in Linux are included.
>
> Where both 32-bit and 64-bit variants exist, it is assumed that the host
> will always use the 64-bit variant.
>
> * SMCs that only return information about the system
> * PSCI_VERSION - PSCI version implemented by EL3
> * PSCI_FEATURES - optional features supported by EL3
> * AFFINITY_INFO - power state of core/cluster
> * MIGRATE_INFO_TYPE - whether Trusted OS can be migrated
> * MIGRATE_INFO_UP_CPU - resident core of Trusted OS
> * operations which do not affect the hypervisor
> * MIGRATE - migrate Trusted OS to a different core
> * SET_SUSPEND_MODE - toggle OS-initiated mode
> * system shutdown/reset
> * SYSTEM_OFF
> * SYSTEM_RESET
> * SYSTEM_RESET2
>
> Signed-off-by: David Brazdil <dbrazdil@google.com>
> ---
> arch/arm64/kvm/hyp/nvhe/psci-relay.c | 43 +++++++++++++++++++++++++++-
> 1 file changed, 42 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kvm/hyp/nvhe/psci-relay.c b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
> index e7091d89f0fc..7aa87ab7f5ce 100644
> --- a/arch/arm64/kvm/hyp/nvhe/psci-relay.c
> +++ b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
> @@ -57,14 +57,51 @@ static bool is_psci_call(u64 func_id)
> }
> }
>
> +static unsigned long psci_call(unsigned long fn, unsigned long arg0,
> + unsigned long arg1, unsigned long arg2)
> +{
> + struct arm_smccc_res res;
> +
> + arm_smccc_1_1_smc(fn, arg0, arg1, arg2, &res);
> + return res.a0;
> +}
> +
> +static unsigned long psci_forward(struct kvm_cpu_context *host_ctxt)
> +{
> + return psci_call(cpu_reg(host_ctxt, 0), cpu_reg(host_ctxt, 1),
> + cpu_reg(host_ctxt, 2), cpu_reg(host_ctxt, 3));
> +}
> +
> +static __noreturn unsigned long psci_forward_noreturn(struct kvm_cpu_context *host_ctxt)
> +{
> + psci_forward(host_ctxt);
> + hyp_panic(); /* unreachable */
> +}
> +
> static unsigned long psci_0_1_handler(u64 func_id, struct kvm_cpu_context *host_ctxt)
> {
> - return PSCI_RET_NOT_SUPPORTED;
> + if (func_id == kvm_host_psci_function_id[PSCI_FN_CPU_OFF])
> + return psci_forward(host_ctxt);
> + else if (func_id == kvm_host_psci_function_id[PSCI_FN_MIGRATE])
> + return psci_forward(host_ctxt);
Looks weird or I am not seeing something right ? Same action for both
right ? Can't they be combined ?
--
Regards,
Sudeep
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 147+ messages in thread* Re: [PATCH v3 16/23] kvm: arm64: Forward safe PSCI SMCs coming from host
2020-11-27 16:51 ` Sudeep Holla
(?)
@ 2020-12-01 13:20 ` David Brazdil
-1 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-12-01 13:20 UTC (permalink / raw)
To: Sudeep Holla
Cc: kvmarm, Jonathan Corbet, Catalin Marinas, Will Deacon,
Marc Zyngier, James Morse, Julien Thierry, Suzuki K Poulose,
Dennis Zhou, Tejun Heo, Christoph Lameter, Mark Rutland,
Lorenzo Pieralisi, linux-doc, linux-kernel, linux-arm-kernel,
kernel-team
On Fri, Nov 27, 2020 at 04:51:59PM +0000, Sudeep Holla wrote:
> On Thu, Nov 26, 2020 at 03:54:14PM +0000, David Brazdil wrote:
> > Forward the following PSCI SMCs issued by host to EL3 as they do not
> > require the hypervisor's intervention. This assumes that EL3 correctly
> > implements the PSCI specification.
> >
> > Only function IDs implemented in Linux are included.
> >
> > Where both 32-bit and 64-bit variants exist, it is assumed that the host
> > will always use the 64-bit variant.
> >
> > * SMCs that only return information about the system
> > * PSCI_VERSION - PSCI version implemented by EL3
> > * PSCI_FEATURES - optional features supported by EL3
> > * AFFINITY_INFO - power state of core/cluster
> > * MIGRATE_INFO_TYPE - whether Trusted OS can be migrated
> > * MIGRATE_INFO_UP_CPU - resident core of Trusted OS
> > * operations which do not affect the hypervisor
> > * MIGRATE - migrate Trusted OS to a different core
> > * SET_SUSPEND_MODE - toggle OS-initiated mode
> > * system shutdown/reset
> > * SYSTEM_OFF
> > * SYSTEM_RESET
> > * SYSTEM_RESET2
> >
> > Signed-off-by: David Brazdil <dbrazdil@google.com>
> > ---
> > arch/arm64/kvm/hyp/nvhe/psci-relay.c | 43 +++++++++++++++++++++++++++-
> > 1 file changed, 42 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/kvm/hyp/nvhe/psci-relay.c b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
> > index e7091d89f0fc..7aa87ab7f5ce 100644
> > --- a/arch/arm64/kvm/hyp/nvhe/psci-relay.c
> > +++ b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
> > @@ -57,14 +57,51 @@ static bool is_psci_call(u64 func_id)
> > }
> > }
> >
> > +static unsigned long psci_call(unsigned long fn, unsigned long arg0,
> > + unsigned long arg1, unsigned long arg2)
> > +{
> > + struct arm_smccc_res res;
> > +
> > + arm_smccc_1_1_smc(fn, arg0, arg1, arg2, &res);
> > + return res.a0;
> > +}
> > +
> > +static unsigned long psci_forward(struct kvm_cpu_context *host_ctxt)
> > +{
> > + return psci_call(cpu_reg(host_ctxt, 0), cpu_reg(host_ctxt, 1),
> > + cpu_reg(host_ctxt, 2), cpu_reg(host_ctxt, 3));
> > +}
> > +
> > +static __noreturn unsigned long psci_forward_noreturn(struct kvm_cpu_context *host_ctxt)
> > +{
> > + psci_forward(host_ctxt);
> > + hyp_panic(); /* unreachable */
> > +}
> > +
> > static unsigned long psci_0_1_handler(u64 func_id, struct kvm_cpu_context *host_ctxt)
> > {
> > - return PSCI_RET_NOT_SUPPORTED;
> > + if (func_id == kvm_host_psci_function_id[PSCI_FN_CPU_OFF])
> > + return psci_forward(host_ctxt);
> > + else if (func_id == kvm_host_psci_function_id[PSCI_FN_MIGRATE])
> > + return psci_forward(host_ctxt);
>
> Looks weird or I am not seeing something right ? Same action for both
> right ? Can't they be combined ?
Sure, happy to combine them. I thought visually it made sense to have one
action per ID.
^ permalink raw reply [flat|nested] 147+ messages in thread* Re: [PATCH v3 16/23] kvm: arm64: Forward safe PSCI SMCs coming from host
@ 2020-12-01 13:20 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-12-01 13:20 UTC (permalink / raw)
To: Sudeep Holla
Cc: Mark Rutland, Lorenzo Pieralisi, kernel-team, Jonathan Corbet,
Catalin Marinas, Suzuki K Poulose, linux-doc, linux-kernel,
James Morse, linux-arm-kernel, Marc Zyngier, Tejun Heo,
Dennis Zhou, Christoph Lameter, Will Deacon, kvmarm,
Julien Thierry
On Fri, Nov 27, 2020 at 04:51:59PM +0000, Sudeep Holla wrote:
> On Thu, Nov 26, 2020 at 03:54:14PM +0000, David Brazdil wrote:
> > Forward the following PSCI SMCs issued by host to EL3 as they do not
> > require the hypervisor's intervention. This assumes that EL3 correctly
> > implements the PSCI specification.
> >
> > Only function IDs implemented in Linux are included.
> >
> > Where both 32-bit and 64-bit variants exist, it is assumed that the host
> > will always use the 64-bit variant.
> >
> > * SMCs that only return information about the system
> > * PSCI_VERSION - PSCI version implemented by EL3
> > * PSCI_FEATURES - optional features supported by EL3
> > * AFFINITY_INFO - power state of core/cluster
> > * MIGRATE_INFO_TYPE - whether Trusted OS can be migrated
> > * MIGRATE_INFO_UP_CPU - resident core of Trusted OS
> > * operations which do not affect the hypervisor
> > * MIGRATE - migrate Trusted OS to a different core
> > * SET_SUSPEND_MODE - toggle OS-initiated mode
> > * system shutdown/reset
> > * SYSTEM_OFF
> > * SYSTEM_RESET
> > * SYSTEM_RESET2
> >
> > Signed-off-by: David Brazdil <dbrazdil@google.com>
> > ---
> > arch/arm64/kvm/hyp/nvhe/psci-relay.c | 43 +++++++++++++++++++++++++++-
> > 1 file changed, 42 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/kvm/hyp/nvhe/psci-relay.c b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
> > index e7091d89f0fc..7aa87ab7f5ce 100644
> > --- a/arch/arm64/kvm/hyp/nvhe/psci-relay.c
> > +++ b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
> > @@ -57,14 +57,51 @@ static bool is_psci_call(u64 func_id)
> > }
> > }
> >
> > +static unsigned long psci_call(unsigned long fn, unsigned long arg0,
> > + unsigned long arg1, unsigned long arg2)
> > +{
> > + struct arm_smccc_res res;
> > +
> > + arm_smccc_1_1_smc(fn, arg0, arg1, arg2, &res);
> > + return res.a0;
> > +}
> > +
> > +static unsigned long psci_forward(struct kvm_cpu_context *host_ctxt)
> > +{
> > + return psci_call(cpu_reg(host_ctxt, 0), cpu_reg(host_ctxt, 1),
> > + cpu_reg(host_ctxt, 2), cpu_reg(host_ctxt, 3));
> > +}
> > +
> > +static __noreturn unsigned long psci_forward_noreturn(struct kvm_cpu_context *host_ctxt)
> > +{
> > + psci_forward(host_ctxt);
> > + hyp_panic(); /* unreachable */
> > +}
> > +
> > static unsigned long psci_0_1_handler(u64 func_id, struct kvm_cpu_context *host_ctxt)
> > {
> > - return PSCI_RET_NOT_SUPPORTED;
> > + if (func_id == kvm_host_psci_function_id[PSCI_FN_CPU_OFF])
> > + return psci_forward(host_ctxt);
> > + else if (func_id == kvm_host_psci_function_id[PSCI_FN_MIGRATE])
> > + return psci_forward(host_ctxt);
>
> Looks weird or I am not seeing something right ? Same action for both
> right ? Can't they be combined ?
Sure, happy to combine them. I thought visually it made sense to have one
action per ID.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 147+ messages in thread* Re: [PATCH v3 16/23] kvm: arm64: Forward safe PSCI SMCs coming from host
@ 2020-12-01 13:20 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-12-01 13:20 UTC (permalink / raw)
To: Sudeep Holla
Cc: Lorenzo Pieralisi, kernel-team, Jonathan Corbet, Catalin Marinas,
linux-doc, linux-kernel, linux-arm-kernel, Marc Zyngier,
Tejun Heo, Dennis Zhou, Christoph Lameter, Will Deacon, kvmarm
On Fri, Nov 27, 2020 at 04:51:59PM +0000, Sudeep Holla wrote:
> On Thu, Nov 26, 2020 at 03:54:14PM +0000, David Brazdil wrote:
> > Forward the following PSCI SMCs issued by host to EL3 as they do not
> > require the hypervisor's intervention. This assumes that EL3 correctly
> > implements the PSCI specification.
> >
> > Only function IDs implemented in Linux are included.
> >
> > Where both 32-bit and 64-bit variants exist, it is assumed that the host
> > will always use the 64-bit variant.
> >
> > * SMCs that only return information about the system
> > * PSCI_VERSION - PSCI version implemented by EL3
> > * PSCI_FEATURES - optional features supported by EL3
> > * AFFINITY_INFO - power state of core/cluster
> > * MIGRATE_INFO_TYPE - whether Trusted OS can be migrated
> > * MIGRATE_INFO_UP_CPU - resident core of Trusted OS
> > * operations which do not affect the hypervisor
> > * MIGRATE - migrate Trusted OS to a different core
> > * SET_SUSPEND_MODE - toggle OS-initiated mode
> > * system shutdown/reset
> > * SYSTEM_OFF
> > * SYSTEM_RESET
> > * SYSTEM_RESET2
> >
> > Signed-off-by: David Brazdil <dbrazdil@google.com>
> > ---
> > arch/arm64/kvm/hyp/nvhe/psci-relay.c | 43 +++++++++++++++++++++++++++-
> > 1 file changed, 42 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/kvm/hyp/nvhe/psci-relay.c b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
> > index e7091d89f0fc..7aa87ab7f5ce 100644
> > --- a/arch/arm64/kvm/hyp/nvhe/psci-relay.c
> > +++ b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
> > @@ -57,14 +57,51 @@ static bool is_psci_call(u64 func_id)
> > }
> > }
> >
> > +static unsigned long psci_call(unsigned long fn, unsigned long arg0,
> > + unsigned long arg1, unsigned long arg2)
> > +{
> > + struct arm_smccc_res res;
> > +
> > + arm_smccc_1_1_smc(fn, arg0, arg1, arg2, &res);
> > + return res.a0;
> > +}
> > +
> > +static unsigned long psci_forward(struct kvm_cpu_context *host_ctxt)
> > +{
> > + return psci_call(cpu_reg(host_ctxt, 0), cpu_reg(host_ctxt, 1),
> > + cpu_reg(host_ctxt, 2), cpu_reg(host_ctxt, 3));
> > +}
> > +
> > +static __noreturn unsigned long psci_forward_noreturn(struct kvm_cpu_context *host_ctxt)
> > +{
> > + psci_forward(host_ctxt);
> > + hyp_panic(); /* unreachable */
> > +}
> > +
> > static unsigned long psci_0_1_handler(u64 func_id, struct kvm_cpu_context *host_ctxt)
> > {
> > - return PSCI_RET_NOT_SUPPORTED;
> > + if (func_id == kvm_host_psci_function_id[PSCI_FN_CPU_OFF])
> > + return psci_forward(host_ctxt);
> > + else if (func_id == kvm_host_psci_function_id[PSCI_FN_MIGRATE])
> > + return psci_forward(host_ctxt);
>
> Looks weird or I am not seeing something right ? Same action for both
> right ? Can't they be combined ?
Sure, happy to combine them. I thought visually it made sense to have one
action per ID.
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v3 17/23] kvm: arm64: Extract __do_hyp_init into a helper function
2020-11-26 15:53 ` David Brazdil
(?)
@ 2020-11-26 15:54 ` David Brazdil
-1 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Jonathan Corbet, Catalin Marinas, Will Deacon, Marc Zyngier,
James Morse, Julien Thierry, Suzuki K Poulose, Dennis Zhou,
Tejun Heo, Christoph Lameter, Mark Rutland, Lorenzo Pieralisi,
Sudeep Holla, linux-doc, linux-kernel, linux-arm-kernel,
kernel-team, David Brazdil
In preparation for adding a CPU entry point in nVHE hyp code, extract
most of __do_hyp_init hypervisor initialization code into a common
helper function. This will be invoked by the entry point to install KVM
on the newly booted CPU.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
arch/arm64/kvm/hyp/nvhe/hyp-init.S | 35 ++++++++++++++++++++++--------
1 file changed, 26 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-init.S b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
index 77c983aa90fa..98ce40e17b42 100644
--- a/arch/arm64/kvm/hyp/nvhe/hyp-init.S
+++ b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
@@ -68,13 +68,32 @@ __do_hyp_init:
mov x0, #SMCCC_RET_NOT_SUPPORTED
eret
-1: ldr x0, [x1, #NVHE_INIT_TPIDR_EL2]
- msr tpidr_el2, x0
+1: mov x0, x1
+ mov x4, lr
+ bl ___kvm_hyp_init
+ mov lr, x4
- ldr x0, [x1, #NVHE_INIT_STACK_HYP_VA]
- mov sp, x0
+ /* Hello, World! */
+ mov x0, #SMCCC_RET_SUCCESS
+ eret
+SYM_CODE_END(__kvm_hyp_init)
+
+/*
+ * Initialize the hypervisor in EL2.
+ *
+ * Only uses x0..x3 so as to not clobber callee-saved SMCCC registers
+ * and leave x4 for the caller.
+ *
+ * x0: struct kvm_nvhe_init_params PA
+ */
+SYM_CODE_START(___kvm_hyp_init)
+ ldr x1, [x0, #NVHE_INIT_TPIDR_EL2]
+ msr tpidr_el2, x1
+
+ ldr x1, [x0, #NVHE_INIT_STACK_HYP_VA]
+ mov sp, x1
- ldr x1, [x1, #NVHE_INIT_PGD_PA]
+ ldr x1, [x0, #NVHE_INIT_PGD_PA]
phys_to_ttbr x0, x1
alternative_if ARM64_HAS_CNP
orr x0, x0, #TTBR_CNP_BIT
@@ -139,10 +158,8 @@ alternative_else_nop_endif
kimg_hyp_va x0, x1
msr vbar_el2, x0
- /* Hello, World! */
- mov x0, #SMCCC_RET_SUCCESS
- eret
-SYM_CODE_END(__kvm_hyp_init)
+ ret
+SYM_CODE_END(___kvm_hyp_init)
SYM_CODE_START(__kvm_handle_stub_hvc)
cmp x0, #HVC_SOFT_RESTART
--
2.29.2.454.gaff20da3a2-goog
^ permalink raw reply related [flat|nested] 147+ messages in thread
* [PATCH v3 17/23] kvm: arm64: Extract __do_hyp_init into a helper function
@ 2020-11-26 15:54 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Mark Rutland, Lorenzo Pieralisi, kernel-team, Jonathan Corbet,
Catalin Marinas, Suzuki K Poulose, linux-doc, linux-kernel,
Sudeep Holla, James Morse, linux-arm-kernel, Marc Zyngier,
Tejun Heo, Dennis Zhou, Christoph Lameter, David Brazdil,
Will Deacon, Julien Thierry
In preparation for adding a CPU entry point in nVHE hyp code, extract
most of __do_hyp_init hypervisor initialization code into a common
helper function. This will be invoked by the entry point to install KVM
on the newly booted CPU.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
arch/arm64/kvm/hyp/nvhe/hyp-init.S | 35 ++++++++++++++++++++++--------
1 file changed, 26 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-init.S b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
index 77c983aa90fa..98ce40e17b42 100644
--- a/arch/arm64/kvm/hyp/nvhe/hyp-init.S
+++ b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
@@ -68,13 +68,32 @@ __do_hyp_init:
mov x0, #SMCCC_RET_NOT_SUPPORTED
eret
-1: ldr x0, [x1, #NVHE_INIT_TPIDR_EL2]
- msr tpidr_el2, x0
+1: mov x0, x1
+ mov x4, lr
+ bl ___kvm_hyp_init
+ mov lr, x4
- ldr x0, [x1, #NVHE_INIT_STACK_HYP_VA]
- mov sp, x0
+ /* Hello, World! */
+ mov x0, #SMCCC_RET_SUCCESS
+ eret
+SYM_CODE_END(__kvm_hyp_init)
+
+/*
+ * Initialize the hypervisor in EL2.
+ *
+ * Only uses x0..x3 so as to not clobber callee-saved SMCCC registers
+ * and leave x4 for the caller.
+ *
+ * x0: struct kvm_nvhe_init_params PA
+ */
+SYM_CODE_START(___kvm_hyp_init)
+ ldr x1, [x0, #NVHE_INIT_TPIDR_EL2]
+ msr tpidr_el2, x1
+
+ ldr x1, [x0, #NVHE_INIT_STACK_HYP_VA]
+ mov sp, x1
- ldr x1, [x1, #NVHE_INIT_PGD_PA]
+ ldr x1, [x0, #NVHE_INIT_PGD_PA]
phys_to_ttbr x0, x1
alternative_if ARM64_HAS_CNP
orr x0, x0, #TTBR_CNP_BIT
@@ -139,10 +158,8 @@ alternative_else_nop_endif
kimg_hyp_va x0, x1
msr vbar_el2, x0
- /* Hello, World! */
- mov x0, #SMCCC_RET_SUCCESS
- eret
-SYM_CODE_END(__kvm_hyp_init)
+ ret
+SYM_CODE_END(___kvm_hyp_init)
SYM_CODE_START(__kvm_handle_stub_hvc)
cmp x0, #HVC_SOFT_RESTART
--
2.29.2.454.gaff20da3a2-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 147+ messages in thread
* [PATCH v3 17/23] kvm: arm64: Extract __do_hyp_init into a helper function
@ 2020-11-26 15:54 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Lorenzo Pieralisi, kernel-team, Jonathan Corbet, Catalin Marinas,
linux-doc, linux-kernel, Sudeep Holla, linux-arm-kernel,
Marc Zyngier, Tejun Heo, Dennis Zhou, Christoph Lameter,
Will Deacon
In preparation for adding a CPU entry point in nVHE hyp code, extract
most of __do_hyp_init hypervisor initialization code into a common
helper function. This will be invoked by the entry point to install KVM
on the newly booted CPU.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
arch/arm64/kvm/hyp/nvhe/hyp-init.S | 35 ++++++++++++++++++++++--------
1 file changed, 26 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-init.S b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
index 77c983aa90fa..98ce40e17b42 100644
--- a/arch/arm64/kvm/hyp/nvhe/hyp-init.S
+++ b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
@@ -68,13 +68,32 @@ __do_hyp_init:
mov x0, #SMCCC_RET_NOT_SUPPORTED
eret
-1: ldr x0, [x1, #NVHE_INIT_TPIDR_EL2]
- msr tpidr_el2, x0
+1: mov x0, x1
+ mov x4, lr
+ bl ___kvm_hyp_init
+ mov lr, x4
- ldr x0, [x1, #NVHE_INIT_STACK_HYP_VA]
- mov sp, x0
+ /* Hello, World! */
+ mov x0, #SMCCC_RET_SUCCESS
+ eret
+SYM_CODE_END(__kvm_hyp_init)
+
+/*
+ * Initialize the hypervisor in EL2.
+ *
+ * Only uses x0..x3 so as to not clobber callee-saved SMCCC registers
+ * and leave x4 for the caller.
+ *
+ * x0: struct kvm_nvhe_init_params PA
+ */
+SYM_CODE_START(___kvm_hyp_init)
+ ldr x1, [x0, #NVHE_INIT_TPIDR_EL2]
+ msr tpidr_el2, x1
+
+ ldr x1, [x0, #NVHE_INIT_STACK_HYP_VA]
+ mov sp, x1
- ldr x1, [x1, #NVHE_INIT_PGD_PA]
+ ldr x1, [x0, #NVHE_INIT_PGD_PA]
phys_to_ttbr x0, x1
alternative_if ARM64_HAS_CNP
orr x0, x0, #TTBR_CNP_BIT
@@ -139,10 +158,8 @@ alternative_else_nop_endif
kimg_hyp_va x0, x1
msr vbar_el2, x0
- /* Hello, World! */
- mov x0, #SMCCC_RET_SUCCESS
- eret
-SYM_CODE_END(__kvm_hyp_init)
+ ret
+SYM_CODE_END(___kvm_hyp_init)
SYM_CODE_START(__kvm_handle_stub_hvc)
cmp x0, #HVC_SOFT_RESTART
--
2.29.2.454.gaff20da3a2-goog
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply related [flat|nested] 147+ messages in thread
* [PATCH v3 18/23] kvm: arm64: Add function to enter host from KVM nVHE hyp code
2020-11-26 15:53 ` David Brazdil
(?)
@ 2020-11-26 15:54 ` David Brazdil
-1 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Jonathan Corbet, Catalin Marinas, Will Deacon, Marc Zyngier,
James Morse, Julien Thierry, Suzuki K Poulose, Dennis Zhou,
Tejun Heo, Christoph Lameter, Mark Rutland, Lorenzo Pieralisi,
Sudeep Holla, linux-doc, linux-kernel, linux-arm-kernel,
kernel-team, David Brazdil
All nVHE hyp code is currently executed as handlers of host's HVCs. This
will change as nVHE starts intercepting host's PSCI CPU_ON SMCs. The
newly booted CPU will need to initialize EL2 state and then enter the
host. Add __host_enter function that branches into the existing
host state-restoring code after the trap handler would have returned.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
arch/arm64/kvm/hyp/nvhe/host.S | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/kvm/hyp/nvhe/host.S b/arch/arm64/kvm/hyp/nvhe/host.S
index 2b56f0bdf874..a820dfdc9c25 100644
--- a/arch/arm64/kvm/hyp/nvhe/host.S
+++ b/arch/arm64/kvm/hyp/nvhe/host.S
@@ -39,6 +39,7 @@ SYM_FUNC_START(__host_exit)
bl handle_trap
/* Restore host regs x0-x17 */
+__host_enter_restore_full:
ldp x0, x1, [x29, #CPU_XREG_OFFSET(0)]
ldp x2, x3, [x29, #CPU_XREG_OFFSET(2)]
ldp x4, x5, [x29, #CPU_XREG_OFFSET(4)]
@@ -61,6 +62,14 @@ __host_enter_without_restoring:
sb
SYM_FUNC_END(__host_exit)
+/*
+ * void __noreturn __host_enter(struct kvm_cpu_context *host_ctxt);
+ */
+SYM_FUNC_START(__host_enter)
+ mov x29, x0
+ b __host_enter_restore_full
+SYM_FUNC_END(__host_enter)
+
/*
* void __noreturn __hyp_do_panic(bool restore_host, u64 spsr, u64 elr, u64 par);
*/
--
2.29.2.454.gaff20da3a2-goog
^ permalink raw reply related [flat|nested] 147+ messages in thread
* [PATCH v3 18/23] kvm: arm64: Add function to enter host from KVM nVHE hyp code
@ 2020-11-26 15:54 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Mark Rutland, Lorenzo Pieralisi, kernel-team, Jonathan Corbet,
Catalin Marinas, Suzuki K Poulose, linux-doc, linux-kernel,
Sudeep Holla, James Morse, linux-arm-kernel, Marc Zyngier,
Tejun Heo, Dennis Zhou, Christoph Lameter, David Brazdil,
Will Deacon, Julien Thierry
All nVHE hyp code is currently executed as handlers of host's HVCs. This
will change as nVHE starts intercepting host's PSCI CPU_ON SMCs. The
newly booted CPU will need to initialize EL2 state and then enter the
host. Add __host_enter function that branches into the existing
host state-restoring code after the trap handler would have returned.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
arch/arm64/kvm/hyp/nvhe/host.S | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/kvm/hyp/nvhe/host.S b/arch/arm64/kvm/hyp/nvhe/host.S
index 2b56f0bdf874..a820dfdc9c25 100644
--- a/arch/arm64/kvm/hyp/nvhe/host.S
+++ b/arch/arm64/kvm/hyp/nvhe/host.S
@@ -39,6 +39,7 @@ SYM_FUNC_START(__host_exit)
bl handle_trap
/* Restore host regs x0-x17 */
+__host_enter_restore_full:
ldp x0, x1, [x29, #CPU_XREG_OFFSET(0)]
ldp x2, x3, [x29, #CPU_XREG_OFFSET(2)]
ldp x4, x5, [x29, #CPU_XREG_OFFSET(4)]
@@ -61,6 +62,14 @@ __host_enter_without_restoring:
sb
SYM_FUNC_END(__host_exit)
+/*
+ * void __noreturn __host_enter(struct kvm_cpu_context *host_ctxt);
+ */
+SYM_FUNC_START(__host_enter)
+ mov x29, x0
+ b __host_enter_restore_full
+SYM_FUNC_END(__host_enter)
+
/*
* void __noreturn __hyp_do_panic(bool restore_host, u64 spsr, u64 elr, u64 par);
*/
--
2.29.2.454.gaff20da3a2-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 147+ messages in thread
* [PATCH v3 18/23] kvm: arm64: Add function to enter host from KVM nVHE hyp code
@ 2020-11-26 15:54 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Lorenzo Pieralisi, kernel-team, Jonathan Corbet, Catalin Marinas,
linux-doc, linux-kernel, Sudeep Holla, linux-arm-kernel,
Marc Zyngier, Tejun Heo, Dennis Zhou, Christoph Lameter,
Will Deacon
All nVHE hyp code is currently executed as handlers of host's HVCs. This
will change as nVHE starts intercepting host's PSCI CPU_ON SMCs. The
newly booted CPU will need to initialize EL2 state and then enter the
host. Add __host_enter function that branches into the existing
host state-restoring code after the trap handler would have returned.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
arch/arm64/kvm/hyp/nvhe/host.S | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/kvm/hyp/nvhe/host.S b/arch/arm64/kvm/hyp/nvhe/host.S
index 2b56f0bdf874..a820dfdc9c25 100644
--- a/arch/arm64/kvm/hyp/nvhe/host.S
+++ b/arch/arm64/kvm/hyp/nvhe/host.S
@@ -39,6 +39,7 @@ SYM_FUNC_START(__host_exit)
bl handle_trap
/* Restore host regs x0-x17 */
+__host_enter_restore_full:
ldp x0, x1, [x29, #CPU_XREG_OFFSET(0)]
ldp x2, x3, [x29, #CPU_XREG_OFFSET(2)]
ldp x4, x5, [x29, #CPU_XREG_OFFSET(4)]
@@ -61,6 +62,14 @@ __host_enter_without_restoring:
sb
SYM_FUNC_END(__host_exit)
+/*
+ * void __noreturn __host_enter(struct kvm_cpu_context *host_ctxt);
+ */
+SYM_FUNC_START(__host_enter)
+ mov x29, x0
+ b __host_enter_restore_full
+SYM_FUNC_END(__host_enter)
+
/*
* void __noreturn __hyp_do_panic(bool restore_host, u64 spsr, u64 elr, u64 par);
*/
--
2.29.2.454.gaff20da3a2-goog
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply related [flat|nested] 147+ messages in thread
* [PATCH v3 19/23] kvm: arm64: Intercept host's CPU_ON SMCs
2020-11-26 15:53 ` David Brazdil
(?)
@ 2020-11-26 15:54 ` David Brazdil
-1 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Jonathan Corbet, Catalin Marinas, Will Deacon, Marc Zyngier,
James Morse, Julien Thierry, Suzuki K Poulose, Dennis Zhou,
Tejun Heo, Christoph Lameter, Mark Rutland, Lorenzo Pieralisi,
Sudeep Holla, linux-doc, linux-kernel, linux-arm-kernel,
kernel-team, David Brazdil
Add a handler of the CPU_ON PSCI call from host. When invoked, it looks
up the logical CPU ID corresponding to the provided MPIDR and populates
the state struct of the target CPU with the provided x0, pc. It then
calls CPU_ON itself, with an entry point in hyp that initializes EL2
state before returning ERET to the provided PC in EL1.
There is a simple atomic lock around the boot args struct. If it is
already locked, CPU_ON will return PENDING_ON error code.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
arch/arm64/kvm/hyp/nvhe/hyp-init.S | 30 ++++++++
arch/arm64/kvm/hyp/nvhe/psci-relay.c | 109 +++++++++++++++++++++++++++
2 files changed, 139 insertions(+)
diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-init.S b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
index 98ce40e17b42..ea71f653af55 100644
--- a/arch/arm64/kvm/hyp/nvhe/hyp-init.S
+++ b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
@@ -9,6 +9,7 @@
#include <asm/alternative.h>
#include <asm/assembler.h>
+#include <asm/el2_setup.h>
#include <asm/kvm_arm.h>
#include <asm/kvm_asm.h>
#include <asm/kvm_mmu.h>
@@ -161,6 +162,35 @@ alternative_else_nop_endif
ret
SYM_CODE_END(___kvm_hyp_init)
+SYM_CODE_START(__kvm_hyp_cpu_on_entry)
+ msr SPsel, #1 // We want to use SP_EL{1,2}
+
+ /* Check that the core was booted in EL2. */
+ mrs x1, CurrentEL
+ cmp x1, #CurrentEL_EL2
+ b.eq 2f
+
+ /* The core booted in EL1. KVM cannot be initialized on it. */
+1: wfe
+ wfi
+ b 1b
+
+ /* Initialize EL2 CPU state to sane values. */
+2: mov x29, x0
+ init_el2_state nvhe
+ mov x0, x29
+
+ /* Enable MMU, set vectors and stack. */
+ bl ___kvm_hyp_init
+
+ /* Load address of the C handler. */
+ ldr x1, =__kvm_hyp_psci_cpu_entry
+ kimg_hyp_va x1, x2
+
+ /* Leave idmap. */
+ br x1
+SYM_CODE_END(__kvm_hyp_cpu_on_entry)
+
SYM_CODE_START(__kvm_handle_stub_hvc)
cmp x0, #HVC_SOFT_RESTART
b.ne 1f
diff --git a/arch/arm64/kvm/hyp/nvhe/psci-relay.c b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
index 7aa87ab7f5ce..39e507672e6e 100644
--- a/arch/arm64/kvm/hyp/nvhe/psci-relay.c
+++ b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
@@ -9,12 +9,17 @@
#include <asm/kvm_mmu.h>
#include <kvm/arm_hypercalls.h>
#include <linux/arm-smccc.h>
+#include <linux/kvm_host.h>
#include <linux/psci.h>
#include <kvm/arm_psci.h>
#include <uapi/linux/psci.h>
#include <nvhe/trap_handler.h>
+extern char __kvm_hyp_cpu_on_entry[];
+
+void __noreturn __host_enter(struct kvm_cpu_context *host_ctxt);
+
/* Config options set by the host. */
u32 __ro_after_init kvm_host_psci_version;
u32 __ro_after_init kvm_host_psci_function_id[PSCI_FN_MAX];
@@ -22,6 +27,19 @@ s64 __ro_after_init hyp_physvirt_offset;
#define __hyp_pa(x) ((phys_addr_t)((x)) + hyp_physvirt_offset)
+#define INVALID_CPU_ID UINT_MAX
+
+#define CPU_UNLOCKED 0
+#define CPU_LOCKED 1
+
+struct cpu_boot_args {
+ unsigned long pc;
+ unsigned long r0;
+};
+
+static DEFINE_PER_CPU(atomic_t, cpu_on_lock) = ATOMIC_INIT(0);
+static DEFINE_PER_CPU(struct cpu_boot_args, cpu_on_args);
+
static u64 get_psci_func_id(struct kvm_cpu_context *host_ctxt)
{
DECLARE_REG(u64, func_id, host_ctxt, 0);
@@ -78,10 +96,99 @@ static __noreturn unsigned long psci_forward_noreturn(struct kvm_cpu_context *ho
hyp_panic(); /* unreachable */
}
+static unsigned int find_cpu_id(u64 mpidr)
+{
+ unsigned int i;
+
+ /* Reject invalid MPIDRs */
+ if (mpidr & ~MPIDR_HWID_BITMASK)
+ return INVALID_CPU_ID;
+
+ for (i = 0; i < NR_CPUS; i++) {
+ if (cpu_logical_map(i) == mpidr)
+ return i;
+ }
+
+ return INVALID_CPU_ID;
+}
+
+static __always_inline bool try_acquire_cpu_on_lock(atomic_t *l) {
+ return atomic_cmpxchg_acquire(l, CPU_UNLOCKED, CPU_LOCKED) == CPU_UNLOCKED;
+}
+
+static __always_inline void release_cpu_on_lock(atomic_t *l) {
+ atomic_set_release(l, CPU_UNLOCKED);
+}
+
+static int psci_cpu_on(u64 func_id, struct kvm_cpu_context *host_ctxt)
+{
+ DECLARE_REG(u64, mpidr, host_ctxt, 1);
+ DECLARE_REG(unsigned long, pc, host_ctxt, 2);
+ DECLARE_REG(unsigned long, r0, host_ctxt, 3);
+
+ unsigned int cpu_id;
+ atomic_t *lock;
+ struct cpu_boot_args *boot_args;
+ struct kvm_nvhe_init_params *init_params;
+ int ret;
+
+ /*
+ * Find the logical CPU ID for the given MPIDR. The search set is
+ * the set of CPUs that were online at the point of KVM initialization.
+ * Booting other CPUs is rejected because their cpufeatures were not
+ * checked against the finalized capabilities. This could be relaxed
+ * by doing the feature checks in hyp.
+ */
+ cpu_id = find_cpu_id(mpidr);
+ if (cpu_id == INVALID_CPU_ID)
+ return PSCI_RET_INVALID_PARAMS;
+
+ lock = per_cpu_ptr(hyp_symbol_addr(cpu_on_lock), cpu_id);
+ boot_args = per_cpu_ptr(hyp_symbol_addr(cpu_on_args), cpu_id);
+ init_params = per_cpu_ptr(hyp_symbol_addr(kvm_init_params), cpu_id);
+
+ /* Check if the target CPU is already being booted. */
+ if (!try_acquire_cpu_on_lock(lock))
+ return PSCI_RET_ALREADY_ON;
+
+ *boot_args = (struct cpu_boot_args){ .pc = pc, .r0 = r0 };
+ wmb();
+
+ ret = psci_call(func_id, mpidr,
+ __hyp_pa(hyp_symbol_addr(__kvm_hyp_cpu_on_entry)),
+ __hyp_pa(init_params));
+
+ /* If successful, the lock will be released by the target CPU. */
+ if (ret != PSCI_RET_SUCCESS)
+ release_cpu_on_lock(lock);
+
+ return ret;
+}
+
+asmlinkage void __noreturn __kvm_hyp_psci_cpu_entry(void)
+{
+ atomic_t *lock;
+ struct cpu_boot_args *boot_args;
+ struct kvm_cpu_context *host_ctxt;
+
+ lock = this_cpu_ptr(hyp_symbol_addr(cpu_on_lock));
+ boot_args = this_cpu_ptr(hyp_symbol_addr(cpu_on_args));
+ host_ctxt = &this_cpu_ptr(hyp_symbol_addr(kvm_host_data))->host_ctxt;
+
+ cpu_reg(host_ctxt, 0) = boot_args->r0;
+ write_sysreg_el2(boot_args->pc, SYS_ELR);
+
+ release_cpu_on_lock(lock);
+
+ __host_enter(host_ctxt);
+}
+
static unsigned long psci_0_1_handler(u64 func_id, struct kvm_cpu_context *host_ctxt)
{
if (func_id == kvm_host_psci_function_id[PSCI_FN_CPU_OFF])
return psci_forward(host_ctxt);
+ else if (func_id == kvm_host_psci_function_id[PSCI_FN_CPU_ON])
+ return psci_cpu_on(func_id, host_ctxt);
else if (func_id == kvm_host_psci_function_id[PSCI_FN_MIGRATE])
return psci_forward(host_ctxt);
else
@@ -102,6 +209,8 @@ static unsigned long psci_0_2_handler(u64 func_id, struct kvm_cpu_context *host_
case PSCI_0_2_FN_SYSTEM_RESET:
psci_forward_noreturn(host_ctxt);
unreachable();
+ case PSCI_0_2_FN64_CPU_ON:
+ return psci_cpu_on(func_id, host_ctxt);
default:
return PSCI_RET_NOT_SUPPORTED;
}
--
2.29.2.454.gaff20da3a2-goog
^ permalink raw reply related [flat|nested] 147+ messages in thread* [PATCH v3 19/23] kvm: arm64: Intercept host's CPU_ON SMCs
@ 2020-11-26 15:54 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Mark Rutland, Lorenzo Pieralisi, kernel-team, Jonathan Corbet,
Catalin Marinas, Suzuki K Poulose, linux-doc, linux-kernel,
Sudeep Holla, James Morse, linux-arm-kernel, Marc Zyngier,
Tejun Heo, Dennis Zhou, Christoph Lameter, David Brazdil,
Will Deacon, Julien Thierry
Add a handler of the CPU_ON PSCI call from host. When invoked, it looks
up the logical CPU ID corresponding to the provided MPIDR and populates
the state struct of the target CPU with the provided x0, pc. It then
calls CPU_ON itself, with an entry point in hyp that initializes EL2
state before returning ERET to the provided PC in EL1.
There is a simple atomic lock around the boot args struct. If it is
already locked, CPU_ON will return PENDING_ON error code.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
arch/arm64/kvm/hyp/nvhe/hyp-init.S | 30 ++++++++
arch/arm64/kvm/hyp/nvhe/psci-relay.c | 109 +++++++++++++++++++++++++++
2 files changed, 139 insertions(+)
diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-init.S b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
index 98ce40e17b42..ea71f653af55 100644
--- a/arch/arm64/kvm/hyp/nvhe/hyp-init.S
+++ b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
@@ -9,6 +9,7 @@
#include <asm/alternative.h>
#include <asm/assembler.h>
+#include <asm/el2_setup.h>
#include <asm/kvm_arm.h>
#include <asm/kvm_asm.h>
#include <asm/kvm_mmu.h>
@@ -161,6 +162,35 @@ alternative_else_nop_endif
ret
SYM_CODE_END(___kvm_hyp_init)
+SYM_CODE_START(__kvm_hyp_cpu_on_entry)
+ msr SPsel, #1 // We want to use SP_EL{1,2}
+
+ /* Check that the core was booted in EL2. */
+ mrs x1, CurrentEL
+ cmp x1, #CurrentEL_EL2
+ b.eq 2f
+
+ /* The core booted in EL1. KVM cannot be initialized on it. */
+1: wfe
+ wfi
+ b 1b
+
+ /* Initialize EL2 CPU state to sane values. */
+2: mov x29, x0
+ init_el2_state nvhe
+ mov x0, x29
+
+ /* Enable MMU, set vectors and stack. */
+ bl ___kvm_hyp_init
+
+ /* Load address of the C handler. */
+ ldr x1, =__kvm_hyp_psci_cpu_entry
+ kimg_hyp_va x1, x2
+
+ /* Leave idmap. */
+ br x1
+SYM_CODE_END(__kvm_hyp_cpu_on_entry)
+
SYM_CODE_START(__kvm_handle_stub_hvc)
cmp x0, #HVC_SOFT_RESTART
b.ne 1f
diff --git a/arch/arm64/kvm/hyp/nvhe/psci-relay.c b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
index 7aa87ab7f5ce..39e507672e6e 100644
--- a/arch/arm64/kvm/hyp/nvhe/psci-relay.c
+++ b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
@@ -9,12 +9,17 @@
#include <asm/kvm_mmu.h>
#include <kvm/arm_hypercalls.h>
#include <linux/arm-smccc.h>
+#include <linux/kvm_host.h>
#include <linux/psci.h>
#include <kvm/arm_psci.h>
#include <uapi/linux/psci.h>
#include <nvhe/trap_handler.h>
+extern char __kvm_hyp_cpu_on_entry[];
+
+void __noreturn __host_enter(struct kvm_cpu_context *host_ctxt);
+
/* Config options set by the host. */
u32 __ro_after_init kvm_host_psci_version;
u32 __ro_after_init kvm_host_psci_function_id[PSCI_FN_MAX];
@@ -22,6 +27,19 @@ s64 __ro_after_init hyp_physvirt_offset;
#define __hyp_pa(x) ((phys_addr_t)((x)) + hyp_physvirt_offset)
+#define INVALID_CPU_ID UINT_MAX
+
+#define CPU_UNLOCKED 0
+#define CPU_LOCKED 1
+
+struct cpu_boot_args {
+ unsigned long pc;
+ unsigned long r0;
+};
+
+static DEFINE_PER_CPU(atomic_t, cpu_on_lock) = ATOMIC_INIT(0);
+static DEFINE_PER_CPU(struct cpu_boot_args, cpu_on_args);
+
static u64 get_psci_func_id(struct kvm_cpu_context *host_ctxt)
{
DECLARE_REG(u64, func_id, host_ctxt, 0);
@@ -78,10 +96,99 @@ static __noreturn unsigned long psci_forward_noreturn(struct kvm_cpu_context *ho
hyp_panic(); /* unreachable */
}
+static unsigned int find_cpu_id(u64 mpidr)
+{
+ unsigned int i;
+
+ /* Reject invalid MPIDRs */
+ if (mpidr & ~MPIDR_HWID_BITMASK)
+ return INVALID_CPU_ID;
+
+ for (i = 0; i < NR_CPUS; i++) {
+ if (cpu_logical_map(i) == mpidr)
+ return i;
+ }
+
+ return INVALID_CPU_ID;
+}
+
+static __always_inline bool try_acquire_cpu_on_lock(atomic_t *l) {
+ return atomic_cmpxchg_acquire(l, CPU_UNLOCKED, CPU_LOCKED) == CPU_UNLOCKED;
+}
+
+static __always_inline void release_cpu_on_lock(atomic_t *l) {
+ atomic_set_release(l, CPU_UNLOCKED);
+}
+
+static int psci_cpu_on(u64 func_id, struct kvm_cpu_context *host_ctxt)
+{
+ DECLARE_REG(u64, mpidr, host_ctxt, 1);
+ DECLARE_REG(unsigned long, pc, host_ctxt, 2);
+ DECLARE_REG(unsigned long, r0, host_ctxt, 3);
+
+ unsigned int cpu_id;
+ atomic_t *lock;
+ struct cpu_boot_args *boot_args;
+ struct kvm_nvhe_init_params *init_params;
+ int ret;
+
+ /*
+ * Find the logical CPU ID for the given MPIDR. The search set is
+ * the set of CPUs that were online at the point of KVM initialization.
+ * Booting other CPUs is rejected because their cpufeatures were not
+ * checked against the finalized capabilities. This could be relaxed
+ * by doing the feature checks in hyp.
+ */
+ cpu_id = find_cpu_id(mpidr);
+ if (cpu_id == INVALID_CPU_ID)
+ return PSCI_RET_INVALID_PARAMS;
+
+ lock = per_cpu_ptr(hyp_symbol_addr(cpu_on_lock), cpu_id);
+ boot_args = per_cpu_ptr(hyp_symbol_addr(cpu_on_args), cpu_id);
+ init_params = per_cpu_ptr(hyp_symbol_addr(kvm_init_params), cpu_id);
+
+ /* Check if the target CPU is already being booted. */
+ if (!try_acquire_cpu_on_lock(lock))
+ return PSCI_RET_ALREADY_ON;
+
+ *boot_args = (struct cpu_boot_args){ .pc = pc, .r0 = r0 };
+ wmb();
+
+ ret = psci_call(func_id, mpidr,
+ __hyp_pa(hyp_symbol_addr(__kvm_hyp_cpu_on_entry)),
+ __hyp_pa(init_params));
+
+ /* If successful, the lock will be released by the target CPU. */
+ if (ret != PSCI_RET_SUCCESS)
+ release_cpu_on_lock(lock);
+
+ return ret;
+}
+
+asmlinkage void __noreturn __kvm_hyp_psci_cpu_entry(void)
+{
+ atomic_t *lock;
+ struct cpu_boot_args *boot_args;
+ struct kvm_cpu_context *host_ctxt;
+
+ lock = this_cpu_ptr(hyp_symbol_addr(cpu_on_lock));
+ boot_args = this_cpu_ptr(hyp_symbol_addr(cpu_on_args));
+ host_ctxt = &this_cpu_ptr(hyp_symbol_addr(kvm_host_data))->host_ctxt;
+
+ cpu_reg(host_ctxt, 0) = boot_args->r0;
+ write_sysreg_el2(boot_args->pc, SYS_ELR);
+
+ release_cpu_on_lock(lock);
+
+ __host_enter(host_ctxt);
+}
+
static unsigned long psci_0_1_handler(u64 func_id, struct kvm_cpu_context *host_ctxt)
{
if (func_id == kvm_host_psci_function_id[PSCI_FN_CPU_OFF])
return psci_forward(host_ctxt);
+ else if (func_id == kvm_host_psci_function_id[PSCI_FN_CPU_ON])
+ return psci_cpu_on(func_id, host_ctxt);
else if (func_id == kvm_host_psci_function_id[PSCI_FN_MIGRATE])
return psci_forward(host_ctxt);
else
@@ -102,6 +209,8 @@ static unsigned long psci_0_2_handler(u64 func_id, struct kvm_cpu_context *host_
case PSCI_0_2_FN_SYSTEM_RESET:
psci_forward_noreturn(host_ctxt);
unreachable();
+ case PSCI_0_2_FN64_CPU_ON:
+ return psci_cpu_on(func_id, host_ctxt);
default:
return PSCI_RET_NOT_SUPPORTED;
}
--
2.29.2.454.gaff20da3a2-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 147+ messages in thread* [PATCH v3 19/23] kvm: arm64: Intercept host's CPU_ON SMCs
@ 2020-11-26 15:54 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Lorenzo Pieralisi, kernel-team, Jonathan Corbet, Catalin Marinas,
linux-doc, linux-kernel, Sudeep Holla, linux-arm-kernel,
Marc Zyngier, Tejun Heo, Dennis Zhou, Christoph Lameter,
Will Deacon
Add a handler of the CPU_ON PSCI call from host. When invoked, it looks
up the logical CPU ID corresponding to the provided MPIDR and populates
the state struct of the target CPU with the provided x0, pc. It then
calls CPU_ON itself, with an entry point in hyp that initializes EL2
state before returning ERET to the provided PC in EL1.
There is a simple atomic lock around the boot args struct. If it is
already locked, CPU_ON will return PENDING_ON error code.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
arch/arm64/kvm/hyp/nvhe/hyp-init.S | 30 ++++++++
arch/arm64/kvm/hyp/nvhe/psci-relay.c | 109 +++++++++++++++++++++++++++
2 files changed, 139 insertions(+)
diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-init.S b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
index 98ce40e17b42..ea71f653af55 100644
--- a/arch/arm64/kvm/hyp/nvhe/hyp-init.S
+++ b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
@@ -9,6 +9,7 @@
#include <asm/alternative.h>
#include <asm/assembler.h>
+#include <asm/el2_setup.h>
#include <asm/kvm_arm.h>
#include <asm/kvm_asm.h>
#include <asm/kvm_mmu.h>
@@ -161,6 +162,35 @@ alternative_else_nop_endif
ret
SYM_CODE_END(___kvm_hyp_init)
+SYM_CODE_START(__kvm_hyp_cpu_on_entry)
+ msr SPsel, #1 // We want to use SP_EL{1,2}
+
+ /* Check that the core was booted in EL2. */
+ mrs x1, CurrentEL
+ cmp x1, #CurrentEL_EL2
+ b.eq 2f
+
+ /* The core booted in EL1. KVM cannot be initialized on it. */
+1: wfe
+ wfi
+ b 1b
+
+ /* Initialize EL2 CPU state to sane values. */
+2: mov x29, x0
+ init_el2_state nvhe
+ mov x0, x29
+
+ /* Enable MMU, set vectors and stack. */
+ bl ___kvm_hyp_init
+
+ /* Load address of the C handler. */
+ ldr x1, =__kvm_hyp_psci_cpu_entry
+ kimg_hyp_va x1, x2
+
+ /* Leave idmap. */
+ br x1
+SYM_CODE_END(__kvm_hyp_cpu_on_entry)
+
SYM_CODE_START(__kvm_handle_stub_hvc)
cmp x0, #HVC_SOFT_RESTART
b.ne 1f
diff --git a/arch/arm64/kvm/hyp/nvhe/psci-relay.c b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
index 7aa87ab7f5ce..39e507672e6e 100644
--- a/arch/arm64/kvm/hyp/nvhe/psci-relay.c
+++ b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
@@ -9,12 +9,17 @@
#include <asm/kvm_mmu.h>
#include <kvm/arm_hypercalls.h>
#include <linux/arm-smccc.h>
+#include <linux/kvm_host.h>
#include <linux/psci.h>
#include <kvm/arm_psci.h>
#include <uapi/linux/psci.h>
#include <nvhe/trap_handler.h>
+extern char __kvm_hyp_cpu_on_entry[];
+
+void __noreturn __host_enter(struct kvm_cpu_context *host_ctxt);
+
/* Config options set by the host. */
u32 __ro_after_init kvm_host_psci_version;
u32 __ro_after_init kvm_host_psci_function_id[PSCI_FN_MAX];
@@ -22,6 +27,19 @@ s64 __ro_after_init hyp_physvirt_offset;
#define __hyp_pa(x) ((phys_addr_t)((x)) + hyp_physvirt_offset)
+#define INVALID_CPU_ID UINT_MAX
+
+#define CPU_UNLOCKED 0
+#define CPU_LOCKED 1
+
+struct cpu_boot_args {
+ unsigned long pc;
+ unsigned long r0;
+};
+
+static DEFINE_PER_CPU(atomic_t, cpu_on_lock) = ATOMIC_INIT(0);
+static DEFINE_PER_CPU(struct cpu_boot_args, cpu_on_args);
+
static u64 get_psci_func_id(struct kvm_cpu_context *host_ctxt)
{
DECLARE_REG(u64, func_id, host_ctxt, 0);
@@ -78,10 +96,99 @@ static __noreturn unsigned long psci_forward_noreturn(struct kvm_cpu_context *ho
hyp_panic(); /* unreachable */
}
+static unsigned int find_cpu_id(u64 mpidr)
+{
+ unsigned int i;
+
+ /* Reject invalid MPIDRs */
+ if (mpidr & ~MPIDR_HWID_BITMASK)
+ return INVALID_CPU_ID;
+
+ for (i = 0; i < NR_CPUS; i++) {
+ if (cpu_logical_map(i) == mpidr)
+ return i;
+ }
+
+ return INVALID_CPU_ID;
+}
+
+static __always_inline bool try_acquire_cpu_on_lock(atomic_t *l) {
+ return atomic_cmpxchg_acquire(l, CPU_UNLOCKED, CPU_LOCKED) == CPU_UNLOCKED;
+}
+
+static __always_inline void release_cpu_on_lock(atomic_t *l) {
+ atomic_set_release(l, CPU_UNLOCKED);
+}
+
+static int psci_cpu_on(u64 func_id, struct kvm_cpu_context *host_ctxt)
+{
+ DECLARE_REG(u64, mpidr, host_ctxt, 1);
+ DECLARE_REG(unsigned long, pc, host_ctxt, 2);
+ DECLARE_REG(unsigned long, r0, host_ctxt, 3);
+
+ unsigned int cpu_id;
+ atomic_t *lock;
+ struct cpu_boot_args *boot_args;
+ struct kvm_nvhe_init_params *init_params;
+ int ret;
+
+ /*
+ * Find the logical CPU ID for the given MPIDR. The search set is
+ * the set of CPUs that were online at the point of KVM initialization.
+ * Booting other CPUs is rejected because their cpufeatures were not
+ * checked against the finalized capabilities. This could be relaxed
+ * by doing the feature checks in hyp.
+ */
+ cpu_id = find_cpu_id(mpidr);
+ if (cpu_id == INVALID_CPU_ID)
+ return PSCI_RET_INVALID_PARAMS;
+
+ lock = per_cpu_ptr(hyp_symbol_addr(cpu_on_lock), cpu_id);
+ boot_args = per_cpu_ptr(hyp_symbol_addr(cpu_on_args), cpu_id);
+ init_params = per_cpu_ptr(hyp_symbol_addr(kvm_init_params), cpu_id);
+
+ /* Check if the target CPU is already being booted. */
+ if (!try_acquire_cpu_on_lock(lock))
+ return PSCI_RET_ALREADY_ON;
+
+ *boot_args = (struct cpu_boot_args){ .pc = pc, .r0 = r0 };
+ wmb();
+
+ ret = psci_call(func_id, mpidr,
+ __hyp_pa(hyp_symbol_addr(__kvm_hyp_cpu_on_entry)),
+ __hyp_pa(init_params));
+
+ /* If successful, the lock will be released by the target CPU. */
+ if (ret != PSCI_RET_SUCCESS)
+ release_cpu_on_lock(lock);
+
+ return ret;
+}
+
+asmlinkage void __noreturn __kvm_hyp_psci_cpu_entry(void)
+{
+ atomic_t *lock;
+ struct cpu_boot_args *boot_args;
+ struct kvm_cpu_context *host_ctxt;
+
+ lock = this_cpu_ptr(hyp_symbol_addr(cpu_on_lock));
+ boot_args = this_cpu_ptr(hyp_symbol_addr(cpu_on_args));
+ host_ctxt = &this_cpu_ptr(hyp_symbol_addr(kvm_host_data))->host_ctxt;
+
+ cpu_reg(host_ctxt, 0) = boot_args->r0;
+ write_sysreg_el2(boot_args->pc, SYS_ELR);
+
+ release_cpu_on_lock(lock);
+
+ __host_enter(host_ctxt);
+}
+
static unsigned long psci_0_1_handler(u64 func_id, struct kvm_cpu_context *host_ctxt)
{
if (func_id == kvm_host_psci_function_id[PSCI_FN_CPU_OFF])
return psci_forward(host_ctxt);
+ else if (func_id == kvm_host_psci_function_id[PSCI_FN_CPU_ON])
+ return psci_cpu_on(func_id, host_ctxt);
else if (func_id == kvm_host_psci_function_id[PSCI_FN_MIGRATE])
return psci_forward(host_ctxt);
else
@@ -102,6 +209,8 @@ static unsigned long psci_0_2_handler(u64 func_id, struct kvm_cpu_context *host_
case PSCI_0_2_FN_SYSTEM_RESET:
psci_forward_noreturn(host_ctxt);
unreachable();
+ case PSCI_0_2_FN64_CPU_ON:
+ return psci_cpu_on(func_id, host_ctxt);
default:
return PSCI_RET_NOT_SUPPORTED;
}
--
2.29.2.454.gaff20da3a2-goog
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply related [flat|nested] 147+ messages in thread* Re: [PATCH v3 19/23] kvm: arm64: Intercept host's CPU_ON SMCs
2020-11-26 15:54 ` David Brazdil
(?)
@ 2020-11-27 17:47 ` Sudeep Holla
-1 siblings, 0 replies; 147+ messages in thread
From: Sudeep Holla @ 2020-11-27 17:47 UTC (permalink / raw)
To: David Brazdil
Cc: kvmarm, Jonathan Corbet, Catalin Marinas, Will Deacon,
Marc Zyngier, James Morse, Julien Thierry, Suzuki K Poulose,
Dennis Zhou, Tejun Heo, Christoph Lameter, Mark Rutland,
Lorenzo Pieralisi, linux-doc, linux-kernel, linux-arm-kernel,
kernel-team
On Thu, Nov 26, 2020 at 03:54:17PM +0000, David Brazdil wrote:
> Add a handler of the CPU_ON PSCI call from host. When invoked, it looks
> up the logical CPU ID corresponding to the provided MPIDR and populates
> the state struct of the target CPU with the provided x0, pc. It then
> calls CPU_ON itself, with an entry point in hyp that initializes EL2
> state before returning ERET to the provided PC in EL1.
>
> There is a simple atomic lock around the boot args struct. If it is
> already locked, CPU_ON will return PENDING_ON error code.
>
> Signed-off-by: David Brazdil <dbrazdil@google.com>
> ---
> arch/arm64/kvm/hyp/nvhe/hyp-init.S | 30 ++++++++
> arch/arm64/kvm/hyp/nvhe/psci-relay.c | 109 +++++++++++++++++++++++++++
> 2 files changed, 139 insertions(+)
>
> diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-init.S b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
> index 98ce40e17b42..ea71f653af55 100644
> --- a/arch/arm64/kvm/hyp/nvhe/hyp-init.S
> +++ b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
> @@ -9,6 +9,7 @@
>
> #include <asm/alternative.h>
> #include <asm/assembler.h>
> +#include <asm/el2_setup.h>
> #include <asm/kvm_arm.h>
> #include <asm/kvm_asm.h>
> #include <asm/kvm_mmu.h>
> @@ -161,6 +162,35 @@ alternative_else_nop_endif
> ret
> SYM_CODE_END(___kvm_hyp_init)
>
> +SYM_CODE_START(__kvm_hyp_cpu_on_entry)
> + msr SPsel, #1 // We want to use SP_EL{1,2}
> +
> + /* Check that the core was booted in EL2. */
> + mrs x1, CurrentEL
> + cmp x1, #CurrentEL_EL2
> + b.eq 2f
> +
> + /* The core booted in EL1. KVM cannot be initialized on it. */
> +1: wfe
> + wfi
> + b 1b
> +
> + /* Initialize EL2 CPU state to sane values. */
> +2: mov x29, x0
> + init_el2_state nvhe
> + mov x0, x29
> +
> + /* Enable MMU, set vectors and stack. */
> + bl ___kvm_hyp_init
> +
> + /* Load address of the C handler. */
> + ldr x1, =__kvm_hyp_psci_cpu_entry
> + kimg_hyp_va x1, x2
> +
> + /* Leave idmap. */
> + br x1
> +SYM_CODE_END(__kvm_hyp_cpu_on_entry)
> +
> SYM_CODE_START(__kvm_handle_stub_hvc)
> cmp x0, #HVC_SOFT_RESTART
> b.ne 1f
> diff --git a/arch/arm64/kvm/hyp/nvhe/psci-relay.c b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
> index 7aa87ab7f5ce..39e507672e6e 100644
> --- a/arch/arm64/kvm/hyp/nvhe/psci-relay.c
> +++ b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
> @@ -9,12 +9,17 @@
> #include <asm/kvm_mmu.h>
> #include <kvm/arm_hypercalls.h>
> #include <linux/arm-smccc.h>
> +#include <linux/kvm_host.h>
> #include <linux/psci.h>
> #include <kvm/arm_psci.h>
> #include <uapi/linux/psci.h>
>
> #include <nvhe/trap_handler.h>
>
> +extern char __kvm_hyp_cpu_on_entry[];
> +
> +void __noreturn __host_enter(struct kvm_cpu_context *host_ctxt);
> +
> /* Config options set by the host. */
> u32 __ro_after_init kvm_host_psci_version;
> u32 __ro_after_init kvm_host_psci_function_id[PSCI_FN_MAX];
> @@ -22,6 +27,19 @@ s64 __ro_after_init hyp_physvirt_offset;
>
> #define __hyp_pa(x) ((phys_addr_t)((x)) + hyp_physvirt_offset)
>
> +#define INVALID_CPU_ID UINT_MAX
> +
> +#define CPU_UNLOCKED 0
> +#define CPU_LOCKED 1
> +
> +struct cpu_boot_args {
> + unsigned long pc;
> + unsigned long r0;
> +};
> +
> +static DEFINE_PER_CPU(atomic_t, cpu_on_lock) = ATOMIC_INIT(0);
> +static DEFINE_PER_CPU(struct cpu_boot_args, cpu_on_args);
> +
> static u64 get_psci_func_id(struct kvm_cpu_context *host_ctxt)
> {
> DECLARE_REG(u64, func_id, host_ctxt, 0);
> @@ -78,10 +96,99 @@ static __noreturn unsigned long psci_forward_noreturn(struct kvm_cpu_context *ho
> hyp_panic(); /* unreachable */
> }
>
> +static unsigned int find_cpu_id(u64 mpidr)
> +{
> + unsigned int i;
> +
> + /* Reject invalid MPIDRs */
> + if (mpidr & ~MPIDR_HWID_BITMASK)
> + return INVALID_CPU_ID;
> +
> + for (i = 0; i < NR_CPUS; i++) {
I may not have understood the flow correctly, so just asking:
This is just called for secondaries on boot right ? And the cpumasks
are setup by then ? Just trying to see if we can use cpu_possible_mask
instead of running through all 256/1k/4k cpus(ofcourse based on NR_CPUS
config)
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 147+ messages in thread* Re: [PATCH v3 19/23] kvm: arm64: Intercept host's CPU_ON SMCs
@ 2020-11-27 17:47 ` Sudeep Holla
0 siblings, 0 replies; 147+ messages in thread
From: Sudeep Holla @ 2020-11-27 17:47 UTC (permalink / raw)
To: David Brazdil
Cc: Mark Rutland, Lorenzo Pieralisi, kernel-team, Jonathan Corbet,
Catalin Marinas, Suzuki K Poulose, linux-doc, linux-kernel,
James Morse, linux-arm-kernel, Marc Zyngier, Tejun Heo,
Dennis Zhou, Christoph Lameter, Will Deacon, kvmarm,
Julien Thierry
On Thu, Nov 26, 2020 at 03:54:17PM +0000, David Brazdil wrote:
> Add a handler of the CPU_ON PSCI call from host. When invoked, it looks
> up the logical CPU ID corresponding to the provided MPIDR and populates
> the state struct of the target CPU with the provided x0, pc. It then
> calls CPU_ON itself, with an entry point in hyp that initializes EL2
> state before returning ERET to the provided PC in EL1.
>
> There is a simple atomic lock around the boot args struct. If it is
> already locked, CPU_ON will return PENDING_ON error code.
>
> Signed-off-by: David Brazdil <dbrazdil@google.com>
> ---
> arch/arm64/kvm/hyp/nvhe/hyp-init.S | 30 ++++++++
> arch/arm64/kvm/hyp/nvhe/psci-relay.c | 109 +++++++++++++++++++++++++++
> 2 files changed, 139 insertions(+)
>
> diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-init.S b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
> index 98ce40e17b42..ea71f653af55 100644
> --- a/arch/arm64/kvm/hyp/nvhe/hyp-init.S
> +++ b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
> @@ -9,6 +9,7 @@
>
> #include <asm/alternative.h>
> #include <asm/assembler.h>
> +#include <asm/el2_setup.h>
> #include <asm/kvm_arm.h>
> #include <asm/kvm_asm.h>
> #include <asm/kvm_mmu.h>
> @@ -161,6 +162,35 @@ alternative_else_nop_endif
> ret
> SYM_CODE_END(___kvm_hyp_init)
>
> +SYM_CODE_START(__kvm_hyp_cpu_on_entry)
> + msr SPsel, #1 // We want to use SP_EL{1,2}
> +
> + /* Check that the core was booted in EL2. */
> + mrs x1, CurrentEL
> + cmp x1, #CurrentEL_EL2
> + b.eq 2f
> +
> + /* The core booted in EL1. KVM cannot be initialized on it. */
> +1: wfe
> + wfi
> + b 1b
> +
> + /* Initialize EL2 CPU state to sane values. */
> +2: mov x29, x0
> + init_el2_state nvhe
> + mov x0, x29
> +
> + /* Enable MMU, set vectors and stack. */
> + bl ___kvm_hyp_init
> +
> + /* Load address of the C handler. */
> + ldr x1, =__kvm_hyp_psci_cpu_entry
> + kimg_hyp_va x1, x2
> +
> + /* Leave idmap. */
> + br x1
> +SYM_CODE_END(__kvm_hyp_cpu_on_entry)
> +
> SYM_CODE_START(__kvm_handle_stub_hvc)
> cmp x0, #HVC_SOFT_RESTART
> b.ne 1f
> diff --git a/arch/arm64/kvm/hyp/nvhe/psci-relay.c b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
> index 7aa87ab7f5ce..39e507672e6e 100644
> --- a/arch/arm64/kvm/hyp/nvhe/psci-relay.c
> +++ b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
> @@ -9,12 +9,17 @@
> #include <asm/kvm_mmu.h>
> #include <kvm/arm_hypercalls.h>
> #include <linux/arm-smccc.h>
> +#include <linux/kvm_host.h>
> #include <linux/psci.h>
> #include <kvm/arm_psci.h>
> #include <uapi/linux/psci.h>
>
> #include <nvhe/trap_handler.h>
>
> +extern char __kvm_hyp_cpu_on_entry[];
> +
> +void __noreturn __host_enter(struct kvm_cpu_context *host_ctxt);
> +
> /* Config options set by the host. */
> u32 __ro_after_init kvm_host_psci_version;
> u32 __ro_after_init kvm_host_psci_function_id[PSCI_FN_MAX];
> @@ -22,6 +27,19 @@ s64 __ro_after_init hyp_physvirt_offset;
>
> #define __hyp_pa(x) ((phys_addr_t)((x)) + hyp_physvirt_offset)
>
> +#define INVALID_CPU_ID UINT_MAX
> +
> +#define CPU_UNLOCKED 0
> +#define CPU_LOCKED 1
> +
> +struct cpu_boot_args {
> + unsigned long pc;
> + unsigned long r0;
> +};
> +
> +static DEFINE_PER_CPU(atomic_t, cpu_on_lock) = ATOMIC_INIT(0);
> +static DEFINE_PER_CPU(struct cpu_boot_args, cpu_on_args);
> +
> static u64 get_psci_func_id(struct kvm_cpu_context *host_ctxt)
> {
> DECLARE_REG(u64, func_id, host_ctxt, 0);
> @@ -78,10 +96,99 @@ static __noreturn unsigned long psci_forward_noreturn(struct kvm_cpu_context *ho
> hyp_panic(); /* unreachable */
> }
>
> +static unsigned int find_cpu_id(u64 mpidr)
> +{
> + unsigned int i;
> +
> + /* Reject invalid MPIDRs */
> + if (mpidr & ~MPIDR_HWID_BITMASK)
> + return INVALID_CPU_ID;
> +
> + for (i = 0; i < NR_CPUS; i++) {
I may not have understood the flow correctly, so just asking:
This is just called for secondaries on boot right ? And the cpumasks
are setup by then ? Just trying to see if we can use cpu_possible_mask
instead of running through all 256/1k/4k cpus(ofcourse based on NR_CPUS
config)
--
Regards,
Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 147+ messages in thread* Re: [PATCH v3 19/23] kvm: arm64: Intercept host's CPU_ON SMCs
@ 2020-11-27 17:47 ` Sudeep Holla
0 siblings, 0 replies; 147+ messages in thread
From: Sudeep Holla @ 2020-11-27 17:47 UTC (permalink / raw)
To: David Brazdil
Cc: Lorenzo Pieralisi, kernel-team, Jonathan Corbet, Catalin Marinas,
linux-doc, linux-kernel, linux-arm-kernel, Marc Zyngier,
Tejun Heo, Dennis Zhou, Christoph Lameter, Will Deacon, kvmarm
On Thu, Nov 26, 2020 at 03:54:17PM +0000, David Brazdil wrote:
> Add a handler of the CPU_ON PSCI call from host. When invoked, it looks
> up the logical CPU ID corresponding to the provided MPIDR and populates
> the state struct of the target CPU with the provided x0, pc. It then
> calls CPU_ON itself, with an entry point in hyp that initializes EL2
> state before returning ERET to the provided PC in EL1.
>
> There is a simple atomic lock around the boot args struct. If it is
> already locked, CPU_ON will return PENDING_ON error code.
>
> Signed-off-by: David Brazdil <dbrazdil@google.com>
> ---
> arch/arm64/kvm/hyp/nvhe/hyp-init.S | 30 ++++++++
> arch/arm64/kvm/hyp/nvhe/psci-relay.c | 109 +++++++++++++++++++++++++++
> 2 files changed, 139 insertions(+)
>
> diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-init.S b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
> index 98ce40e17b42..ea71f653af55 100644
> --- a/arch/arm64/kvm/hyp/nvhe/hyp-init.S
> +++ b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
> @@ -9,6 +9,7 @@
>
> #include <asm/alternative.h>
> #include <asm/assembler.h>
> +#include <asm/el2_setup.h>
> #include <asm/kvm_arm.h>
> #include <asm/kvm_asm.h>
> #include <asm/kvm_mmu.h>
> @@ -161,6 +162,35 @@ alternative_else_nop_endif
> ret
> SYM_CODE_END(___kvm_hyp_init)
>
> +SYM_CODE_START(__kvm_hyp_cpu_on_entry)
> + msr SPsel, #1 // We want to use SP_EL{1,2}
> +
> + /* Check that the core was booted in EL2. */
> + mrs x1, CurrentEL
> + cmp x1, #CurrentEL_EL2
> + b.eq 2f
> +
> + /* The core booted in EL1. KVM cannot be initialized on it. */
> +1: wfe
> + wfi
> + b 1b
> +
> + /* Initialize EL2 CPU state to sane values. */
> +2: mov x29, x0
> + init_el2_state nvhe
> + mov x0, x29
> +
> + /* Enable MMU, set vectors and stack. */
> + bl ___kvm_hyp_init
> +
> + /* Load address of the C handler. */
> + ldr x1, =__kvm_hyp_psci_cpu_entry
> + kimg_hyp_va x1, x2
> +
> + /* Leave idmap. */
> + br x1
> +SYM_CODE_END(__kvm_hyp_cpu_on_entry)
> +
> SYM_CODE_START(__kvm_handle_stub_hvc)
> cmp x0, #HVC_SOFT_RESTART
> b.ne 1f
> diff --git a/arch/arm64/kvm/hyp/nvhe/psci-relay.c b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
> index 7aa87ab7f5ce..39e507672e6e 100644
> --- a/arch/arm64/kvm/hyp/nvhe/psci-relay.c
> +++ b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
> @@ -9,12 +9,17 @@
> #include <asm/kvm_mmu.h>
> #include <kvm/arm_hypercalls.h>
> #include <linux/arm-smccc.h>
> +#include <linux/kvm_host.h>
> #include <linux/psci.h>
> #include <kvm/arm_psci.h>
> #include <uapi/linux/psci.h>
>
> #include <nvhe/trap_handler.h>
>
> +extern char __kvm_hyp_cpu_on_entry[];
> +
> +void __noreturn __host_enter(struct kvm_cpu_context *host_ctxt);
> +
> /* Config options set by the host. */
> u32 __ro_after_init kvm_host_psci_version;
> u32 __ro_after_init kvm_host_psci_function_id[PSCI_FN_MAX];
> @@ -22,6 +27,19 @@ s64 __ro_after_init hyp_physvirt_offset;
>
> #define __hyp_pa(x) ((phys_addr_t)((x)) + hyp_physvirt_offset)
>
> +#define INVALID_CPU_ID UINT_MAX
> +
> +#define CPU_UNLOCKED 0
> +#define CPU_LOCKED 1
> +
> +struct cpu_boot_args {
> + unsigned long pc;
> + unsigned long r0;
> +};
> +
> +static DEFINE_PER_CPU(atomic_t, cpu_on_lock) = ATOMIC_INIT(0);
> +static DEFINE_PER_CPU(struct cpu_boot_args, cpu_on_args);
> +
> static u64 get_psci_func_id(struct kvm_cpu_context *host_ctxt)
> {
> DECLARE_REG(u64, func_id, host_ctxt, 0);
> @@ -78,10 +96,99 @@ static __noreturn unsigned long psci_forward_noreturn(struct kvm_cpu_context *ho
> hyp_panic(); /* unreachable */
> }
>
> +static unsigned int find_cpu_id(u64 mpidr)
> +{
> + unsigned int i;
> +
> + /* Reject invalid MPIDRs */
> + if (mpidr & ~MPIDR_HWID_BITMASK)
> + return INVALID_CPU_ID;
> +
> + for (i = 0; i < NR_CPUS; i++) {
I may not have understood the flow correctly, so just asking:
This is just called for secondaries on boot right ? And the cpumasks
are setup by then ? Just trying to see if we can use cpu_possible_mask
instead of running through all 256/1k/4k cpus(ofcourse based on NR_CPUS
config)
--
Regards,
Sudeep
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 147+ messages in thread* Re: [PATCH v3 19/23] kvm: arm64: Intercept host's CPU_ON SMCs
2020-11-27 17:47 ` Sudeep Holla
(?)
@ 2020-12-01 13:51 ` David Brazdil
-1 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-12-01 13:51 UTC (permalink / raw)
To: Sudeep Holla
Cc: kvmarm, Jonathan Corbet, Catalin Marinas, Will Deacon,
Marc Zyngier, James Morse, Julien Thierry, Suzuki K Poulose,
Dennis Zhou, Tejun Heo, Christoph Lameter, Mark Rutland,
Lorenzo Pieralisi, linux-doc, linux-kernel, linux-arm-kernel,
kernel-team
Hey Sudeep,
> > +static unsigned int find_cpu_id(u64 mpidr)
> > +{
> > + unsigned int i;
> > +
> > + /* Reject invalid MPIDRs */
> > + if (mpidr & ~MPIDR_HWID_BITMASK)
> > + return INVALID_CPU_ID;
> > +
> > + for (i = 0; i < NR_CPUS; i++) {
>
> I may not have understood the flow correctly, so just asking:
> This is just called for secondaries on boot right ?
No, secondaries are booted before KVM is initialized. kvm_arch_init() installs
the hypervisor on each core that is online at that point. That flow does not
touch this code.
But the kernel can later power down some of those cares and then this handler
is called if it tries to power them on again. You can exercise this with:
# echo 0 > /sys/devices/system/cpu/cpu5/online
# echo 1 > /sys/devices/system/cpu/cpu5/online
> And the cpumasks are setup by then ?
Cpumasks are initialized before KVM init, so yes, we could copy that
information up to EL2 and use it here. That comes down to copying `nr_cpu_ids`
because the possible set is logical IDs 0..nr_cpu_ids-1 (see smp_init_cpus()).
> Just trying to see if we can use cpu_possible_mask instead of running through
> all 256/1k/4k cpus(ofcourse based on NR_CPUS config)
I decided to keep things simple because a valid MPIDR should not need to
scan the entire array, at most the first `nr_cpu_ids` entries. An invalid MPIDR
will scan all NR_CPUS entries but that does not seem worth optimizing for.
David
^ permalink raw reply [flat|nested] 147+ messages in thread* Re: [PATCH v3 19/23] kvm: arm64: Intercept host's CPU_ON SMCs
@ 2020-12-01 13:51 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-12-01 13:51 UTC (permalink / raw)
To: Sudeep Holla
Cc: Mark Rutland, Lorenzo Pieralisi, kernel-team, Jonathan Corbet,
Catalin Marinas, Suzuki K Poulose, linux-doc, linux-kernel,
James Morse, linux-arm-kernel, Marc Zyngier, Tejun Heo,
Dennis Zhou, Christoph Lameter, Will Deacon, kvmarm,
Julien Thierry
Hey Sudeep,
> > +static unsigned int find_cpu_id(u64 mpidr)
> > +{
> > + unsigned int i;
> > +
> > + /* Reject invalid MPIDRs */
> > + if (mpidr & ~MPIDR_HWID_BITMASK)
> > + return INVALID_CPU_ID;
> > +
> > + for (i = 0; i < NR_CPUS; i++) {
>
> I may not have understood the flow correctly, so just asking:
> This is just called for secondaries on boot right ?
No, secondaries are booted before KVM is initialized. kvm_arch_init() installs
the hypervisor on each core that is online at that point. That flow does not
touch this code.
But the kernel can later power down some of those cares and then this handler
is called if it tries to power them on again. You can exercise this with:
# echo 0 > /sys/devices/system/cpu/cpu5/online
# echo 1 > /sys/devices/system/cpu/cpu5/online
> And the cpumasks are setup by then ?
Cpumasks are initialized before KVM init, so yes, we could copy that
information up to EL2 and use it here. That comes down to copying `nr_cpu_ids`
because the possible set is logical IDs 0..nr_cpu_ids-1 (see smp_init_cpus()).
> Just trying to see if we can use cpu_possible_mask instead of running through
> all 256/1k/4k cpus(ofcourse based on NR_CPUS config)
I decided to keep things simple because a valid MPIDR should not need to
scan the entire array, at most the first `nr_cpu_ids` entries. An invalid MPIDR
will scan all NR_CPUS entries but that does not seem worth optimizing for.
David
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 147+ messages in thread* Re: [PATCH v3 19/23] kvm: arm64: Intercept host's CPU_ON SMCs
@ 2020-12-01 13:51 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-12-01 13:51 UTC (permalink / raw)
To: Sudeep Holla
Cc: Lorenzo Pieralisi, kernel-team, Jonathan Corbet, Catalin Marinas,
linux-doc, linux-kernel, linux-arm-kernel, Marc Zyngier,
Tejun Heo, Dennis Zhou, Christoph Lameter, Will Deacon, kvmarm
Hey Sudeep,
> > +static unsigned int find_cpu_id(u64 mpidr)
> > +{
> > + unsigned int i;
> > +
> > + /* Reject invalid MPIDRs */
> > + if (mpidr & ~MPIDR_HWID_BITMASK)
> > + return INVALID_CPU_ID;
> > +
> > + for (i = 0; i < NR_CPUS; i++) {
>
> I may not have understood the flow correctly, so just asking:
> This is just called for secondaries on boot right ?
No, secondaries are booted before KVM is initialized. kvm_arch_init() installs
the hypervisor on each core that is online at that point. That flow does not
touch this code.
But the kernel can later power down some of those cares and then this handler
is called if it tries to power them on again. You can exercise this with:
# echo 0 > /sys/devices/system/cpu/cpu5/online
# echo 1 > /sys/devices/system/cpu/cpu5/online
> And the cpumasks are setup by then ?
Cpumasks are initialized before KVM init, so yes, we could copy that
information up to EL2 and use it here. That comes down to copying `nr_cpu_ids`
because the possible set is logical IDs 0..nr_cpu_ids-1 (see smp_init_cpus()).
> Just trying to see if we can use cpu_possible_mask instead of running through
> all 256/1k/4k cpus(ofcourse based on NR_CPUS config)
I decided to keep things simple because a valid MPIDR should not need to
scan the entire array, at most the first `nr_cpu_ids` entries. An invalid MPIDR
will scan all NR_CPUS entries but that does not seem worth optimizing for.
David
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v3 20/23] kvm: arm64: Intercept host's CPU_SUSPEND PSCI SMCs
2020-11-26 15:53 ` David Brazdil
(?)
@ 2020-11-26 15:54 ` David Brazdil
-1 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Jonathan Corbet, Catalin Marinas, Will Deacon, Marc Zyngier,
James Morse, Julien Thierry, Suzuki K Poulose, Dennis Zhou,
Tejun Heo, Christoph Lameter, Mark Rutland, Lorenzo Pieralisi,
Sudeep Holla, linux-doc, linux-kernel, linux-arm-kernel,
kernel-team, David Brazdil
Add a handler of CPU_SUSPEND host PSCI SMCs. The SMC can either enter
a sleep state indistinguishable from a WFI or a deeper sleep state that
behaves like a CPU_OFF+CPU_ON except that the core is still considered
online when asleep.
The handler saves r0,pc of the host and makes the same call to EL3 with
the hyp CPU entry point. It either returns back to the handler and then
back to the host, or wakes up into the entry point and initializes EL2
state before dropping back to EL1.
A core can only suspend itself but other cores can concurrently invoke
CPU_ON with this core as target. To avoid racing them for the same
boot args struct, CPU_SUSPEND uses a different struct instance and entry
point. Each entry point selects the corresponding struct to restore host
boot args from. This avoids the need for locking in CPU_SUSPEND.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
arch/arm64/kvm/hyp/nvhe/hyp-init.S | 9 +++++
arch/arm64/kvm/hyp/nvhe/psci-relay.c | 50 +++++++++++++++++++++++++---
2 files changed, 54 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-init.S b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
index ea71f653af55..fbb195851fb9 100644
--- a/arch/arm64/kvm/hyp/nvhe/hyp-init.S
+++ b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
@@ -162,7 +162,15 @@ alternative_else_nop_endif
ret
SYM_CODE_END(___kvm_hyp_init)
+SYM_CODE_START(__kvm_hyp_cpu_suspend_entry)
+ mov x28, #0 // is_cpu_on = false
+ b __kvm_hyp_cpu_common_entry
+SYM_CODE_END(__kvm_hyp_cpu_suspend_entry)
+
SYM_CODE_START(__kvm_hyp_cpu_on_entry)
+ mov x28, #1 // is_cpu_on = true
+
+SYM_INNER_LABEL(__kvm_hyp_cpu_common_entry, SYM_L_LOCAL)
msr SPsel, #1 // We want to use SP_EL{1,2}
/* Check that the core was booted in EL2. */
@@ -188,6 +196,7 @@ SYM_CODE_START(__kvm_hyp_cpu_on_entry)
kimg_hyp_va x1, x2
/* Leave idmap. */
+ mov x0, x28
br x1
SYM_CODE_END(__kvm_hyp_cpu_on_entry)
diff --git a/arch/arm64/kvm/hyp/nvhe/psci-relay.c b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
index 39e507672e6e..592c11e9851c 100644
--- a/arch/arm64/kvm/hyp/nvhe/psci-relay.c
+++ b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
@@ -17,6 +17,7 @@
#include <nvhe/trap_handler.h>
extern char __kvm_hyp_cpu_on_entry[];
+extern char __kvm_hyp_cpu_suspend_entry[];
void __noreturn __host_enter(struct kvm_cpu_context *host_ctxt);
@@ -39,6 +40,7 @@ struct cpu_boot_args {
static DEFINE_PER_CPU(atomic_t, cpu_on_lock) = ATOMIC_INIT(0);
static DEFINE_PER_CPU(struct cpu_boot_args, cpu_on_args);
+static DEFINE_PER_CPU(struct cpu_boot_args, cpu_suspend_args);
static u64 get_psci_func_id(struct kvm_cpu_context *host_ctxt)
{
@@ -112,6 +114,34 @@ static unsigned int find_cpu_id(u64 mpidr)
return INVALID_CPU_ID;
}
+static int psci_cpu_suspend(u64 func_id, struct kvm_cpu_context *host_ctxt)
+{
+ DECLARE_REG(u64, power_state, host_ctxt, 1);
+ DECLARE_REG(unsigned long, pc, host_ctxt, 2);
+ DECLARE_REG(unsigned long, r0, host_ctxt, 3);
+
+ struct cpu_boot_args *boot_args;
+ struct kvm_nvhe_init_params *init_params;
+
+ boot_args = this_cpu_ptr(hyp_symbol_addr(cpu_suspend_args));
+ init_params = this_cpu_ptr(hyp_symbol_addr(kvm_init_params));
+
+ /*
+ * No need to acquire a lock before writing to boot_args because a core
+ * can only suspend itself and the racy CPU_ON uses a separate struct.
+ */
+
+ *boot_args = (struct cpu_boot_args){ .pc = pc, .r0 = r0 };
+
+ /*
+ * Will either return if shallow sleep state, or wake up into the entry
+ * point if it is a deep sleep state.
+ */
+ return psci_call(func_id, power_state,
+ __hyp_pa(hyp_symbol_addr(__kvm_hyp_cpu_suspend_entry)),
+ __hyp_pa(init_params));
+}
+
static __always_inline bool try_acquire_cpu_on_lock(atomic_t *l) {
return atomic_cmpxchg_acquire(l, CPU_UNLOCKED, CPU_LOCKED) == CPU_UNLOCKED;
}
@@ -165,27 +195,35 @@ static int psci_cpu_on(u64 func_id, struct kvm_cpu_context *host_ctxt)
return ret;
}
-asmlinkage void __noreturn __kvm_hyp_psci_cpu_entry(void)
+asmlinkage void __noreturn __kvm_hyp_psci_cpu_entry(bool is_cpu_on)
{
atomic_t *lock;
struct cpu_boot_args *boot_args;
struct kvm_cpu_context *host_ctxt;
- lock = this_cpu_ptr(hyp_symbol_addr(cpu_on_lock));
- boot_args = this_cpu_ptr(hyp_symbol_addr(cpu_on_args));
+ if (is_cpu_on)
+ boot_args = this_cpu_ptr(hyp_symbol_addr(cpu_on_args));
+ else
+ boot_args = this_cpu_ptr(hyp_symbol_addr(cpu_suspend_args));
+
host_ctxt = &this_cpu_ptr(hyp_symbol_addr(kvm_host_data))->host_ctxt;
cpu_reg(host_ctxt, 0) = boot_args->r0;
write_sysreg_el2(boot_args->pc, SYS_ELR);
- release_cpu_on_lock(lock);
+ if (is_cpu_on) {
+ lock = this_cpu_ptr(hyp_symbol_addr(cpu_on_lock));
+ release_cpu_on_lock(lock);
+ }
__host_enter(host_ctxt);
}
static unsigned long psci_0_1_handler(u64 func_id, struct kvm_cpu_context *host_ctxt)
{
- if (func_id == kvm_host_psci_function_id[PSCI_FN_CPU_OFF])
+ if (func_id == kvm_host_psci_function_id[PSCI_FN_CPU_SUSPEND])
+ return psci_cpu_suspend(func_id, host_ctxt);
+ else if (func_id == kvm_host_psci_function_id[PSCI_FN_CPU_OFF])
return psci_forward(host_ctxt);
else if (func_id == kvm_host_psci_function_id[PSCI_FN_CPU_ON])
return psci_cpu_on(func_id, host_ctxt);
@@ -209,6 +247,8 @@ static unsigned long psci_0_2_handler(u64 func_id, struct kvm_cpu_context *host_
case PSCI_0_2_FN_SYSTEM_RESET:
psci_forward_noreturn(host_ctxt);
unreachable();
+ case PSCI_0_2_FN64_CPU_SUSPEND:
+ return psci_cpu_suspend(func_id, host_ctxt);
case PSCI_0_2_FN64_CPU_ON:
return psci_cpu_on(func_id, host_ctxt);
default:
--
2.29.2.454.gaff20da3a2-goog
^ permalink raw reply related [flat|nested] 147+ messages in thread* [PATCH v3 20/23] kvm: arm64: Intercept host's CPU_SUSPEND PSCI SMCs
@ 2020-11-26 15:54 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Mark Rutland, Lorenzo Pieralisi, kernel-team, Jonathan Corbet,
Catalin Marinas, Suzuki K Poulose, linux-doc, linux-kernel,
Sudeep Holla, James Morse, linux-arm-kernel, Marc Zyngier,
Tejun Heo, Dennis Zhou, Christoph Lameter, David Brazdil,
Will Deacon, Julien Thierry
Add a handler of CPU_SUSPEND host PSCI SMCs. The SMC can either enter
a sleep state indistinguishable from a WFI or a deeper sleep state that
behaves like a CPU_OFF+CPU_ON except that the core is still considered
online when asleep.
The handler saves r0,pc of the host and makes the same call to EL3 with
the hyp CPU entry point. It either returns back to the handler and then
back to the host, or wakes up into the entry point and initializes EL2
state before dropping back to EL1.
A core can only suspend itself but other cores can concurrently invoke
CPU_ON with this core as target. To avoid racing them for the same
boot args struct, CPU_SUSPEND uses a different struct instance and entry
point. Each entry point selects the corresponding struct to restore host
boot args from. This avoids the need for locking in CPU_SUSPEND.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
arch/arm64/kvm/hyp/nvhe/hyp-init.S | 9 +++++
arch/arm64/kvm/hyp/nvhe/psci-relay.c | 50 +++++++++++++++++++++++++---
2 files changed, 54 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-init.S b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
index ea71f653af55..fbb195851fb9 100644
--- a/arch/arm64/kvm/hyp/nvhe/hyp-init.S
+++ b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
@@ -162,7 +162,15 @@ alternative_else_nop_endif
ret
SYM_CODE_END(___kvm_hyp_init)
+SYM_CODE_START(__kvm_hyp_cpu_suspend_entry)
+ mov x28, #0 // is_cpu_on = false
+ b __kvm_hyp_cpu_common_entry
+SYM_CODE_END(__kvm_hyp_cpu_suspend_entry)
+
SYM_CODE_START(__kvm_hyp_cpu_on_entry)
+ mov x28, #1 // is_cpu_on = true
+
+SYM_INNER_LABEL(__kvm_hyp_cpu_common_entry, SYM_L_LOCAL)
msr SPsel, #1 // We want to use SP_EL{1,2}
/* Check that the core was booted in EL2. */
@@ -188,6 +196,7 @@ SYM_CODE_START(__kvm_hyp_cpu_on_entry)
kimg_hyp_va x1, x2
/* Leave idmap. */
+ mov x0, x28
br x1
SYM_CODE_END(__kvm_hyp_cpu_on_entry)
diff --git a/arch/arm64/kvm/hyp/nvhe/psci-relay.c b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
index 39e507672e6e..592c11e9851c 100644
--- a/arch/arm64/kvm/hyp/nvhe/psci-relay.c
+++ b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
@@ -17,6 +17,7 @@
#include <nvhe/trap_handler.h>
extern char __kvm_hyp_cpu_on_entry[];
+extern char __kvm_hyp_cpu_suspend_entry[];
void __noreturn __host_enter(struct kvm_cpu_context *host_ctxt);
@@ -39,6 +40,7 @@ struct cpu_boot_args {
static DEFINE_PER_CPU(atomic_t, cpu_on_lock) = ATOMIC_INIT(0);
static DEFINE_PER_CPU(struct cpu_boot_args, cpu_on_args);
+static DEFINE_PER_CPU(struct cpu_boot_args, cpu_suspend_args);
static u64 get_psci_func_id(struct kvm_cpu_context *host_ctxt)
{
@@ -112,6 +114,34 @@ static unsigned int find_cpu_id(u64 mpidr)
return INVALID_CPU_ID;
}
+static int psci_cpu_suspend(u64 func_id, struct kvm_cpu_context *host_ctxt)
+{
+ DECLARE_REG(u64, power_state, host_ctxt, 1);
+ DECLARE_REG(unsigned long, pc, host_ctxt, 2);
+ DECLARE_REG(unsigned long, r0, host_ctxt, 3);
+
+ struct cpu_boot_args *boot_args;
+ struct kvm_nvhe_init_params *init_params;
+
+ boot_args = this_cpu_ptr(hyp_symbol_addr(cpu_suspend_args));
+ init_params = this_cpu_ptr(hyp_symbol_addr(kvm_init_params));
+
+ /*
+ * No need to acquire a lock before writing to boot_args because a core
+ * can only suspend itself and the racy CPU_ON uses a separate struct.
+ */
+
+ *boot_args = (struct cpu_boot_args){ .pc = pc, .r0 = r0 };
+
+ /*
+ * Will either return if shallow sleep state, or wake up into the entry
+ * point if it is a deep sleep state.
+ */
+ return psci_call(func_id, power_state,
+ __hyp_pa(hyp_symbol_addr(__kvm_hyp_cpu_suspend_entry)),
+ __hyp_pa(init_params));
+}
+
static __always_inline bool try_acquire_cpu_on_lock(atomic_t *l) {
return atomic_cmpxchg_acquire(l, CPU_UNLOCKED, CPU_LOCKED) == CPU_UNLOCKED;
}
@@ -165,27 +195,35 @@ static int psci_cpu_on(u64 func_id, struct kvm_cpu_context *host_ctxt)
return ret;
}
-asmlinkage void __noreturn __kvm_hyp_psci_cpu_entry(void)
+asmlinkage void __noreturn __kvm_hyp_psci_cpu_entry(bool is_cpu_on)
{
atomic_t *lock;
struct cpu_boot_args *boot_args;
struct kvm_cpu_context *host_ctxt;
- lock = this_cpu_ptr(hyp_symbol_addr(cpu_on_lock));
- boot_args = this_cpu_ptr(hyp_symbol_addr(cpu_on_args));
+ if (is_cpu_on)
+ boot_args = this_cpu_ptr(hyp_symbol_addr(cpu_on_args));
+ else
+ boot_args = this_cpu_ptr(hyp_symbol_addr(cpu_suspend_args));
+
host_ctxt = &this_cpu_ptr(hyp_symbol_addr(kvm_host_data))->host_ctxt;
cpu_reg(host_ctxt, 0) = boot_args->r0;
write_sysreg_el2(boot_args->pc, SYS_ELR);
- release_cpu_on_lock(lock);
+ if (is_cpu_on) {
+ lock = this_cpu_ptr(hyp_symbol_addr(cpu_on_lock));
+ release_cpu_on_lock(lock);
+ }
__host_enter(host_ctxt);
}
static unsigned long psci_0_1_handler(u64 func_id, struct kvm_cpu_context *host_ctxt)
{
- if (func_id == kvm_host_psci_function_id[PSCI_FN_CPU_OFF])
+ if (func_id == kvm_host_psci_function_id[PSCI_FN_CPU_SUSPEND])
+ return psci_cpu_suspend(func_id, host_ctxt);
+ else if (func_id == kvm_host_psci_function_id[PSCI_FN_CPU_OFF])
return psci_forward(host_ctxt);
else if (func_id == kvm_host_psci_function_id[PSCI_FN_CPU_ON])
return psci_cpu_on(func_id, host_ctxt);
@@ -209,6 +247,8 @@ static unsigned long psci_0_2_handler(u64 func_id, struct kvm_cpu_context *host_
case PSCI_0_2_FN_SYSTEM_RESET:
psci_forward_noreturn(host_ctxt);
unreachable();
+ case PSCI_0_2_FN64_CPU_SUSPEND:
+ return psci_cpu_suspend(func_id, host_ctxt);
case PSCI_0_2_FN64_CPU_ON:
return psci_cpu_on(func_id, host_ctxt);
default:
--
2.29.2.454.gaff20da3a2-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 147+ messages in thread* [PATCH v3 20/23] kvm: arm64: Intercept host's CPU_SUSPEND PSCI SMCs
@ 2020-11-26 15:54 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Lorenzo Pieralisi, kernel-team, Jonathan Corbet, Catalin Marinas,
linux-doc, linux-kernel, Sudeep Holla, linux-arm-kernel,
Marc Zyngier, Tejun Heo, Dennis Zhou, Christoph Lameter,
Will Deacon
Add a handler of CPU_SUSPEND host PSCI SMCs. The SMC can either enter
a sleep state indistinguishable from a WFI or a deeper sleep state that
behaves like a CPU_OFF+CPU_ON except that the core is still considered
online when asleep.
The handler saves r0,pc of the host and makes the same call to EL3 with
the hyp CPU entry point. It either returns back to the handler and then
back to the host, or wakes up into the entry point and initializes EL2
state before dropping back to EL1.
A core can only suspend itself but other cores can concurrently invoke
CPU_ON with this core as target. To avoid racing them for the same
boot args struct, CPU_SUSPEND uses a different struct instance and entry
point. Each entry point selects the corresponding struct to restore host
boot args from. This avoids the need for locking in CPU_SUSPEND.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
arch/arm64/kvm/hyp/nvhe/hyp-init.S | 9 +++++
arch/arm64/kvm/hyp/nvhe/psci-relay.c | 50 +++++++++++++++++++++++++---
2 files changed, 54 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-init.S b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
index ea71f653af55..fbb195851fb9 100644
--- a/arch/arm64/kvm/hyp/nvhe/hyp-init.S
+++ b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
@@ -162,7 +162,15 @@ alternative_else_nop_endif
ret
SYM_CODE_END(___kvm_hyp_init)
+SYM_CODE_START(__kvm_hyp_cpu_suspend_entry)
+ mov x28, #0 // is_cpu_on = false
+ b __kvm_hyp_cpu_common_entry
+SYM_CODE_END(__kvm_hyp_cpu_suspend_entry)
+
SYM_CODE_START(__kvm_hyp_cpu_on_entry)
+ mov x28, #1 // is_cpu_on = true
+
+SYM_INNER_LABEL(__kvm_hyp_cpu_common_entry, SYM_L_LOCAL)
msr SPsel, #1 // We want to use SP_EL{1,2}
/* Check that the core was booted in EL2. */
@@ -188,6 +196,7 @@ SYM_CODE_START(__kvm_hyp_cpu_on_entry)
kimg_hyp_va x1, x2
/* Leave idmap. */
+ mov x0, x28
br x1
SYM_CODE_END(__kvm_hyp_cpu_on_entry)
diff --git a/arch/arm64/kvm/hyp/nvhe/psci-relay.c b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
index 39e507672e6e..592c11e9851c 100644
--- a/arch/arm64/kvm/hyp/nvhe/psci-relay.c
+++ b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
@@ -17,6 +17,7 @@
#include <nvhe/trap_handler.h>
extern char __kvm_hyp_cpu_on_entry[];
+extern char __kvm_hyp_cpu_suspend_entry[];
void __noreturn __host_enter(struct kvm_cpu_context *host_ctxt);
@@ -39,6 +40,7 @@ struct cpu_boot_args {
static DEFINE_PER_CPU(atomic_t, cpu_on_lock) = ATOMIC_INIT(0);
static DEFINE_PER_CPU(struct cpu_boot_args, cpu_on_args);
+static DEFINE_PER_CPU(struct cpu_boot_args, cpu_suspend_args);
static u64 get_psci_func_id(struct kvm_cpu_context *host_ctxt)
{
@@ -112,6 +114,34 @@ static unsigned int find_cpu_id(u64 mpidr)
return INVALID_CPU_ID;
}
+static int psci_cpu_suspend(u64 func_id, struct kvm_cpu_context *host_ctxt)
+{
+ DECLARE_REG(u64, power_state, host_ctxt, 1);
+ DECLARE_REG(unsigned long, pc, host_ctxt, 2);
+ DECLARE_REG(unsigned long, r0, host_ctxt, 3);
+
+ struct cpu_boot_args *boot_args;
+ struct kvm_nvhe_init_params *init_params;
+
+ boot_args = this_cpu_ptr(hyp_symbol_addr(cpu_suspend_args));
+ init_params = this_cpu_ptr(hyp_symbol_addr(kvm_init_params));
+
+ /*
+ * No need to acquire a lock before writing to boot_args because a core
+ * can only suspend itself and the racy CPU_ON uses a separate struct.
+ */
+
+ *boot_args = (struct cpu_boot_args){ .pc = pc, .r0 = r0 };
+
+ /*
+ * Will either return if shallow sleep state, or wake up into the entry
+ * point if it is a deep sleep state.
+ */
+ return psci_call(func_id, power_state,
+ __hyp_pa(hyp_symbol_addr(__kvm_hyp_cpu_suspend_entry)),
+ __hyp_pa(init_params));
+}
+
static __always_inline bool try_acquire_cpu_on_lock(atomic_t *l) {
return atomic_cmpxchg_acquire(l, CPU_UNLOCKED, CPU_LOCKED) == CPU_UNLOCKED;
}
@@ -165,27 +195,35 @@ static int psci_cpu_on(u64 func_id, struct kvm_cpu_context *host_ctxt)
return ret;
}
-asmlinkage void __noreturn __kvm_hyp_psci_cpu_entry(void)
+asmlinkage void __noreturn __kvm_hyp_psci_cpu_entry(bool is_cpu_on)
{
atomic_t *lock;
struct cpu_boot_args *boot_args;
struct kvm_cpu_context *host_ctxt;
- lock = this_cpu_ptr(hyp_symbol_addr(cpu_on_lock));
- boot_args = this_cpu_ptr(hyp_symbol_addr(cpu_on_args));
+ if (is_cpu_on)
+ boot_args = this_cpu_ptr(hyp_symbol_addr(cpu_on_args));
+ else
+ boot_args = this_cpu_ptr(hyp_symbol_addr(cpu_suspend_args));
+
host_ctxt = &this_cpu_ptr(hyp_symbol_addr(kvm_host_data))->host_ctxt;
cpu_reg(host_ctxt, 0) = boot_args->r0;
write_sysreg_el2(boot_args->pc, SYS_ELR);
- release_cpu_on_lock(lock);
+ if (is_cpu_on) {
+ lock = this_cpu_ptr(hyp_symbol_addr(cpu_on_lock));
+ release_cpu_on_lock(lock);
+ }
__host_enter(host_ctxt);
}
static unsigned long psci_0_1_handler(u64 func_id, struct kvm_cpu_context *host_ctxt)
{
- if (func_id == kvm_host_psci_function_id[PSCI_FN_CPU_OFF])
+ if (func_id == kvm_host_psci_function_id[PSCI_FN_CPU_SUSPEND])
+ return psci_cpu_suspend(func_id, host_ctxt);
+ else if (func_id == kvm_host_psci_function_id[PSCI_FN_CPU_OFF])
return psci_forward(host_ctxt);
else if (func_id == kvm_host_psci_function_id[PSCI_FN_CPU_ON])
return psci_cpu_on(func_id, host_ctxt);
@@ -209,6 +247,8 @@ static unsigned long psci_0_2_handler(u64 func_id, struct kvm_cpu_context *host_
case PSCI_0_2_FN_SYSTEM_RESET:
psci_forward_noreturn(host_ctxt);
unreachable();
+ case PSCI_0_2_FN64_CPU_SUSPEND:
+ return psci_cpu_suspend(func_id, host_ctxt);
case PSCI_0_2_FN64_CPU_ON:
return psci_cpu_on(func_id, host_ctxt);
default:
--
2.29.2.454.gaff20da3a2-goog
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply related [flat|nested] 147+ messages in thread* Re: [PATCH v3 20/23] kvm: arm64: Intercept host's CPU_SUSPEND PSCI SMCs
2020-11-26 15:54 ` David Brazdil
(?)
@ 2020-12-01 14:57 ` Mark Rutland
-1 siblings, 0 replies; 147+ messages in thread
From: Mark Rutland @ 2020-12-01 14:57 UTC (permalink / raw)
To: David Brazdil
Cc: kvmarm, Jonathan Corbet, Catalin Marinas, Will Deacon,
Marc Zyngier, James Morse, Julien Thierry, Suzuki K Poulose,
Dennis Zhou, Tejun Heo, Christoph Lameter, Lorenzo Pieralisi,
Sudeep Holla, linux-doc, linux-kernel, linux-arm-kernel,
kernel-team
On Thu, Nov 26, 2020 at 03:54:18PM +0000, David Brazdil wrote:
> Add a handler of CPU_SUSPEND host PSCI SMCs. The SMC can either enter
> a sleep state indistinguishable from a WFI or a deeper sleep state that
> behaves like a CPU_OFF+CPU_ON except that the core is still considered
> online when asleep.
>
> The handler saves r0,pc of the host and makes the same call to EL3 with
> the hyp CPU entry point. It either returns back to the handler and then
> back to the host, or wakes up into the entry point and initializes EL2
> state before dropping back to EL1.
For those CPU_SUSPEND calls which lose context, is there no EL2 state
that you need to save/restore, or is that all saved elsewhere already?
The usual suspects are PMU, debug, and timers, so maybe not. It'd be
nice to have a statement in the commit message if we're certain there's
no state that we need to save.
> A core can only suspend itself but other cores can concurrently invoke
> CPU_ON with this core as target. To avoid racing them for the same
> boot args struct, CPU_SUSPEND uses a different struct instance and entry
> point. Each entry point selects the corresponding struct to restore host
> boot args from. This avoids the need for locking in CPU_SUSPEND.
I found this a bit confusing since the first sentence can be read to
mean that CPU_ON is expected to compose with CPU_SUSPEND, whereas what
this is actually saying is the implementation ensures they don't
interact. How about:
| CPU_ON and CPU_SUSPEND are both implemented using struct cpu_boot_args
| to store the state upon powerup, with each CPU having separate structs
| for CPU_ON and CPU_SUSPEND so that CPU_SUSPEND can operate locklessly
| and so that a CPU_ON xall targetting a CPU cannot interfere with a
| concurrent CPU_SUSPEND call on that CPU.
The patch itself looks fine to me.
Thanks,
Mark.
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v3 20/23] kvm: arm64: Intercept host's CPU_SUSPEND PSCI SMCs
@ 2020-12-01 14:57 ` Mark Rutland
0 siblings, 0 replies; 147+ messages in thread
From: Mark Rutland @ 2020-12-01 14:57 UTC (permalink / raw)
To: David Brazdil
Cc: Lorenzo Pieralisi, kernel-team, Jonathan Corbet, Catalin Marinas,
Suzuki K Poulose, linux-doc, linux-kernel, Sudeep Holla,
James Morse, linux-arm-kernel, Marc Zyngier, Tejun Heo,
Dennis Zhou, Christoph Lameter, Will Deacon, kvmarm,
Julien Thierry
On Thu, Nov 26, 2020 at 03:54:18PM +0000, David Brazdil wrote:
> Add a handler of CPU_SUSPEND host PSCI SMCs. The SMC can either enter
> a sleep state indistinguishable from a WFI or a deeper sleep state that
> behaves like a CPU_OFF+CPU_ON except that the core is still considered
> online when asleep.
>
> The handler saves r0,pc of the host and makes the same call to EL3 with
> the hyp CPU entry point. It either returns back to the handler and then
> back to the host, or wakes up into the entry point and initializes EL2
> state before dropping back to EL1.
For those CPU_SUSPEND calls which lose context, is there no EL2 state
that you need to save/restore, or is that all saved elsewhere already?
The usual suspects are PMU, debug, and timers, so maybe not. It'd be
nice to have a statement in the commit message if we're certain there's
no state that we need to save.
> A core can only suspend itself but other cores can concurrently invoke
> CPU_ON with this core as target. To avoid racing them for the same
> boot args struct, CPU_SUSPEND uses a different struct instance and entry
> point. Each entry point selects the corresponding struct to restore host
> boot args from. This avoids the need for locking in CPU_SUSPEND.
I found this a bit confusing since the first sentence can be read to
mean that CPU_ON is expected to compose with CPU_SUSPEND, whereas what
this is actually saying is the implementation ensures they don't
interact. How about:
| CPU_ON and CPU_SUSPEND are both implemented using struct cpu_boot_args
| to store the state upon powerup, with each CPU having separate structs
| for CPU_ON and CPU_SUSPEND so that CPU_SUSPEND can operate locklessly
| and so that a CPU_ON xall targetting a CPU cannot interfere with a
| concurrent CPU_SUSPEND call on that CPU.
The patch itself looks fine to me.
Thanks,
Mark.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v3 20/23] kvm: arm64: Intercept host's CPU_SUSPEND PSCI SMCs
@ 2020-12-01 14:57 ` Mark Rutland
0 siblings, 0 replies; 147+ messages in thread
From: Mark Rutland @ 2020-12-01 14:57 UTC (permalink / raw)
To: David Brazdil
Cc: Lorenzo Pieralisi, kernel-team, Jonathan Corbet, Catalin Marinas,
linux-doc, linux-kernel, Sudeep Holla, linux-arm-kernel,
Marc Zyngier, Tejun Heo, Dennis Zhou, Christoph Lameter,
Will Deacon, kvmarm
On Thu, Nov 26, 2020 at 03:54:18PM +0000, David Brazdil wrote:
> Add a handler of CPU_SUSPEND host PSCI SMCs. The SMC can either enter
> a sleep state indistinguishable from a WFI or a deeper sleep state that
> behaves like a CPU_OFF+CPU_ON except that the core is still considered
> online when asleep.
>
> The handler saves r0,pc of the host and makes the same call to EL3 with
> the hyp CPU entry point. It either returns back to the handler and then
> back to the host, or wakes up into the entry point and initializes EL2
> state before dropping back to EL1.
For those CPU_SUSPEND calls which lose context, is there no EL2 state
that you need to save/restore, or is that all saved elsewhere already?
The usual suspects are PMU, debug, and timers, so maybe not. It'd be
nice to have a statement in the commit message if we're certain there's
no state that we need to save.
> A core can only suspend itself but other cores can concurrently invoke
> CPU_ON with this core as target. To avoid racing them for the same
> boot args struct, CPU_SUSPEND uses a different struct instance and entry
> point. Each entry point selects the corresponding struct to restore host
> boot args from. This avoids the need for locking in CPU_SUSPEND.
I found this a bit confusing since the first sentence can be read to
mean that CPU_ON is expected to compose with CPU_SUSPEND, whereas what
this is actually saying is the implementation ensures they don't
interact. How about:
| CPU_ON and CPU_SUSPEND are both implemented using struct cpu_boot_args
| to store the state upon powerup, with each CPU having separate structs
| for CPU_ON and CPU_SUSPEND so that CPU_SUSPEND can operate locklessly
| and so that a CPU_ON xall targetting a CPU cannot interfere with a
| concurrent CPU_SUSPEND call on that CPU.
The patch itself looks fine to me.
Thanks,
Mark.
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 147+ messages in thread
* [PATCH v3 21/23] kvm: arm64: Keep nVHE EL2 vector installed
2020-11-26 15:53 ` David Brazdil
(?)
@ 2020-11-26 15:54 ` David Brazdil
-1 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Jonathan Corbet, Catalin Marinas, Will Deacon, Marc Zyngier,
James Morse, Julien Thierry, Suzuki K Poulose, Dennis Zhou,
Tejun Heo, Christoph Lameter, Mark Rutland, Lorenzo Pieralisi,
Sudeep Holla, linux-doc, linux-kernel, linux-arm-kernel,
kernel-team, David Brazdil
KVM by default keeps the stub vector installed and installs the nVHE
vector only briefly for init and later on demand. Change this policy
to install the vector at init and then never uninstall it if the kernel
was given the protected KVM command line parameter.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
arch/arm64/kvm/arm.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index 7a17b5048454..6ec8ddf74643 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -1478,7 +1478,8 @@ static void _kvm_arch_hardware_disable(void *discard)
void kvm_arch_hardware_disable(void)
{
- _kvm_arch_hardware_disable(NULL);
+ if (!is_protected_kvm_enabled())
+ _kvm_arch_hardware_disable(NULL);
}
#ifdef CONFIG_CPU_PM
@@ -1521,11 +1522,13 @@ static struct notifier_block hyp_init_cpu_pm_nb = {
static void __init hyp_cpu_pm_init(void)
{
- cpu_pm_register_notifier(&hyp_init_cpu_pm_nb);
+ if (!is_protected_kvm_enabled())
+ cpu_pm_register_notifier(&hyp_init_cpu_pm_nb);
}
static void __init hyp_cpu_pm_exit(void)
{
- cpu_pm_unregister_notifier(&hyp_init_cpu_pm_nb);
+ if (!is_protected_kvm_enabled())
+ cpu_pm_unregister_notifier(&hyp_init_cpu_pm_nb);
}
#else
static inline void hyp_cpu_pm_init(void)
@@ -1617,7 +1620,8 @@ static int init_subsystems(void)
kvm_sys_reg_table_init();
out:
- on_each_cpu(_kvm_arch_hardware_disable, NULL, 1);
+ if (err || !is_protected_kvm_enabled())
+ on_each_cpu(_kvm_arch_hardware_disable, NULL, 1);
return err;
}
--
2.29.2.454.gaff20da3a2-goog
^ permalink raw reply related [flat|nested] 147+ messages in thread* [PATCH v3 21/23] kvm: arm64: Keep nVHE EL2 vector installed
@ 2020-11-26 15:54 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Mark Rutland, Lorenzo Pieralisi, kernel-team, Jonathan Corbet,
Catalin Marinas, Suzuki K Poulose, linux-doc, linux-kernel,
Sudeep Holla, James Morse, linux-arm-kernel, Marc Zyngier,
Tejun Heo, Dennis Zhou, Christoph Lameter, David Brazdil,
Will Deacon, Julien Thierry
KVM by default keeps the stub vector installed and installs the nVHE
vector only briefly for init and later on demand. Change this policy
to install the vector at init and then never uninstall it if the kernel
was given the protected KVM command line parameter.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
arch/arm64/kvm/arm.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index 7a17b5048454..6ec8ddf74643 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -1478,7 +1478,8 @@ static void _kvm_arch_hardware_disable(void *discard)
void kvm_arch_hardware_disable(void)
{
- _kvm_arch_hardware_disable(NULL);
+ if (!is_protected_kvm_enabled())
+ _kvm_arch_hardware_disable(NULL);
}
#ifdef CONFIG_CPU_PM
@@ -1521,11 +1522,13 @@ static struct notifier_block hyp_init_cpu_pm_nb = {
static void __init hyp_cpu_pm_init(void)
{
- cpu_pm_register_notifier(&hyp_init_cpu_pm_nb);
+ if (!is_protected_kvm_enabled())
+ cpu_pm_register_notifier(&hyp_init_cpu_pm_nb);
}
static void __init hyp_cpu_pm_exit(void)
{
- cpu_pm_unregister_notifier(&hyp_init_cpu_pm_nb);
+ if (!is_protected_kvm_enabled())
+ cpu_pm_unregister_notifier(&hyp_init_cpu_pm_nb);
}
#else
static inline void hyp_cpu_pm_init(void)
@@ -1617,7 +1620,8 @@ static int init_subsystems(void)
kvm_sys_reg_table_init();
out:
- on_each_cpu(_kvm_arch_hardware_disable, NULL, 1);
+ if (err || !is_protected_kvm_enabled())
+ on_each_cpu(_kvm_arch_hardware_disable, NULL, 1);
return err;
}
--
2.29.2.454.gaff20da3a2-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 147+ messages in thread* [PATCH v3 21/23] kvm: arm64: Keep nVHE EL2 vector installed
@ 2020-11-26 15:54 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Lorenzo Pieralisi, kernel-team, Jonathan Corbet, Catalin Marinas,
linux-doc, linux-kernel, Sudeep Holla, linux-arm-kernel,
Marc Zyngier, Tejun Heo, Dennis Zhou, Christoph Lameter,
Will Deacon
KVM by default keeps the stub vector installed and installs the nVHE
vector only briefly for init and later on demand. Change this policy
to install the vector at init and then never uninstall it if the kernel
was given the protected KVM command line parameter.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
arch/arm64/kvm/arm.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index 7a17b5048454..6ec8ddf74643 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -1478,7 +1478,8 @@ static void _kvm_arch_hardware_disable(void *discard)
void kvm_arch_hardware_disable(void)
{
- _kvm_arch_hardware_disable(NULL);
+ if (!is_protected_kvm_enabled())
+ _kvm_arch_hardware_disable(NULL);
}
#ifdef CONFIG_CPU_PM
@@ -1521,11 +1522,13 @@ static struct notifier_block hyp_init_cpu_pm_nb = {
static void __init hyp_cpu_pm_init(void)
{
- cpu_pm_register_notifier(&hyp_init_cpu_pm_nb);
+ if (!is_protected_kvm_enabled())
+ cpu_pm_register_notifier(&hyp_init_cpu_pm_nb);
}
static void __init hyp_cpu_pm_exit(void)
{
- cpu_pm_unregister_notifier(&hyp_init_cpu_pm_nb);
+ if (!is_protected_kvm_enabled())
+ cpu_pm_unregister_notifier(&hyp_init_cpu_pm_nb);
}
#else
static inline void hyp_cpu_pm_init(void)
@@ -1617,7 +1620,8 @@ static int init_subsystems(void)
kvm_sys_reg_table_init();
out:
- on_each_cpu(_kvm_arch_hardware_disable, NULL, 1);
+ if (err || !is_protected_kvm_enabled())
+ on_each_cpu(_kvm_arch_hardware_disable, NULL, 1);
return err;
}
--
2.29.2.454.gaff20da3a2-goog
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply related [flat|nested] 147+ messages in thread
* [PATCH v3 22/23] kvm: arm64: Trap host SMCs in protected mode
2020-11-26 15:53 ` David Brazdil
(?)
@ 2020-11-26 15:54 ` David Brazdil
-1 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Jonathan Corbet, Catalin Marinas, Will Deacon, Marc Zyngier,
James Morse, Julien Thierry, Suzuki K Poulose, Dennis Zhou,
Tejun Heo, Christoph Lameter, Mark Rutland, Lorenzo Pieralisi,
Sudeep Holla, linux-doc, linux-kernel, linux-arm-kernel,
kernel-team, David Brazdil
While protected nVHE KVM is installed, start trapping all host SMCs.
By default, these are simply forwarded to EL3, but PSCI SMCs are
validated first.
Create new constant HCR_HOST_NVHE_PROTECTED_FLAGS with the new set of HCR
flags to use while the nVHE vector is installed when the kernel was
booted with the protected flag enabled. Switch back to the default HCR
flags when switching back to the stub vector.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
arch/arm64/include/asm/kvm_arm.h | 1 +
arch/arm64/kvm/hyp/nvhe/hyp-init.S | 10 ++++++++++
arch/arm64/kvm/hyp/nvhe/switch.c | 5 ++++-
3 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
index 64ce29378467..4e90c2debf70 100644
--- a/arch/arm64/include/asm/kvm_arm.h
+++ b/arch/arm64/include/asm/kvm_arm.h
@@ -80,6 +80,7 @@
HCR_FMO | HCR_IMO | HCR_PTW )
#define HCR_VIRT_EXCP_MASK (HCR_VSE | HCR_VI | HCR_VF)
#define HCR_HOST_NVHE_FLAGS (HCR_RW | HCR_API | HCR_APK | HCR_ATA)
+#define HCR_HOST_NVHE_PROTECTED_FLAGS (HCR_HOST_NVHE_FLAGS | HCR_TSC)
#define HCR_HOST_VHE_FLAGS (HCR_RW | HCR_TGE | HCR_E2H)
/* TCR_EL2 Registers bits */
diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-init.S b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
index fbb195851fb9..7af18fa1983d 100644
--- a/arch/arm64/kvm/hyp/nvhe/hyp-init.S
+++ b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
@@ -88,6 +88,11 @@ SYM_CODE_END(__kvm_hyp_init)
* x0: struct kvm_nvhe_init_params PA
*/
SYM_CODE_START(___kvm_hyp_init)
+alternative_if ARM64_PROTECTED_KVM
+ mov_q x1, HCR_HOST_NVHE_PROTECTED_FLAGS
+ msr hcr_el2, x1
+alternative_else_nop_endif
+
ldr x1, [x0, #NVHE_INIT_TPIDR_EL2]
msr tpidr_el2, x1
@@ -233,6 +238,11 @@ reset:
msr sctlr_el2, x5
isb
+alternative_if ARM64_PROTECTED_KVM
+ mov_q x5, HCR_HOST_NVHE_FLAGS
+ msr hcr_el2, x5
+alternative_else_nop_endif
+
/* Install stub vectors */
adr_l x5, __hyp_stub_vectors
msr vbar_el2, x5
diff --git a/arch/arm64/kvm/hyp/nvhe/switch.c b/arch/arm64/kvm/hyp/nvhe/switch.c
index 3e50ff35aa4f..f3d0e9eca56c 100644
--- a/arch/arm64/kvm/hyp/nvhe/switch.c
+++ b/arch/arm64/kvm/hyp/nvhe/switch.c
@@ -97,7 +97,10 @@ static void __deactivate_traps(struct kvm_vcpu *vcpu)
mdcr_el2 |= MDCR_EL2_E2PB_MASK << MDCR_EL2_E2PB_SHIFT;
write_sysreg(mdcr_el2, mdcr_el2);
- write_sysreg(HCR_HOST_NVHE_FLAGS, hcr_el2);
+ if (is_protected_kvm_enabled())
+ write_sysreg(HCR_HOST_NVHE_PROTECTED_FLAGS, hcr_el2);
+ else
+ write_sysreg(HCR_HOST_NVHE_FLAGS, hcr_el2);
write_sysreg(CPTR_EL2_DEFAULT, cptr_el2);
write_sysreg(__kvm_hyp_host_vector, vbar_el2);
}
--
2.29.2.454.gaff20da3a2-goog
^ permalink raw reply related [flat|nested] 147+ messages in thread
* [PATCH v3 22/23] kvm: arm64: Trap host SMCs in protected mode
@ 2020-11-26 15:54 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Mark Rutland, Lorenzo Pieralisi, kernel-team, Jonathan Corbet,
Catalin Marinas, Suzuki K Poulose, linux-doc, linux-kernel,
Sudeep Holla, James Morse, linux-arm-kernel, Marc Zyngier,
Tejun Heo, Dennis Zhou, Christoph Lameter, David Brazdil,
Will Deacon, Julien Thierry
While protected nVHE KVM is installed, start trapping all host SMCs.
By default, these are simply forwarded to EL3, but PSCI SMCs are
validated first.
Create new constant HCR_HOST_NVHE_PROTECTED_FLAGS with the new set of HCR
flags to use while the nVHE vector is installed when the kernel was
booted with the protected flag enabled. Switch back to the default HCR
flags when switching back to the stub vector.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
arch/arm64/include/asm/kvm_arm.h | 1 +
arch/arm64/kvm/hyp/nvhe/hyp-init.S | 10 ++++++++++
arch/arm64/kvm/hyp/nvhe/switch.c | 5 ++++-
3 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
index 64ce29378467..4e90c2debf70 100644
--- a/arch/arm64/include/asm/kvm_arm.h
+++ b/arch/arm64/include/asm/kvm_arm.h
@@ -80,6 +80,7 @@
HCR_FMO | HCR_IMO | HCR_PTW )
#define HCR_VIRT_EXCP_MASK (HCR_VSE | HCR_VI | HCR_VF)
#define HCR_HOST_NVHE_FLAGS (HCR_RW | HCR_API | HCR_APK | HCR_ATA)
+#define HCR_HOST_NVHE_PROTECTED_FLAGS (HCR_HOST_NVHE_FLAGS | HCR_TSC)
#define HCR_HOST_VHE_FLAGS (HCR_RW | HCR_TGE | HCR_E2H)
/* TCR_EL2 Registers bits */
diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-init.S b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
index fbb195851fb9..7af18fa1983d 100644
--- a/arch/arm64/kvm/hyp/nvhe/hyp-init.S
+++ b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
@@ -88,6 +88,11 @@ SYM_CODE_END(__kvm_hyp_init)
* x0: struct kvm_nvhe_init_params PA
*/
SYM_CODE_START(___kvm_hyp_init)
+alternative_if ARM64_PROTECTED_KVM
+ mov_q x1, HCR_HOST_NVHE_PROTECTED_FLAGS
+ msr hcr_el2, x1
+alternative_else_nop_endif
+
ldr x1, [x0, #NVHE_INIT_TPIDR_EL2]
msr tpidr_el2, x1
@@ -233,6 +238,11 @@ reset:
msr sctlr_el2, x5
isb
+alternative_if ARM64_PROTECTED_KVM
+ mov_q x5, HCR_HOST_NVHE_FLAGS
+ msr hcr_el2, x5
+alternative_else_nop_endif
+
/* Install stub vectors */
adr_l x5, __hyp_stub_vectors
msr vbar_el2, x5
diff --git a/arch/arm64/kvm/hyp/nvhe/switch.c b/arch/arm64/kvm/hyp/nvhe/switch.c
index 3e50ff35aa4f..f3d0e9eca56c 100644
--- a/arch/arm64/kvm/hyp/nvhe/switch.c
+++ b/arch/arm64/kvm/hyp/nvhe/switch.c
@@ -97,7 +97,10 @@ static void __deactivate_traps(struct kvm_vcpu *vcpu)
mdcr_el2 |= MDCR_EL2_E2PB_MASK << MDCR_EL2_E2PB_SHIFT;
write_sysreg(mdcr_el2, mdcr_el2);
- write_sysreg(HCR_HOST_NVHE_FLAGS, hcr_el2);
+ if (is_protected_kvm_enabled())
+ write_sysreg(HCR_HOST_NVHE_PROTECTED_FLAGS, hcr_el2);
+ else
+ write_sysreg(HCR_HOST_NVHE_FLAGS, hcr_el2);
write_sysreg(CPTR_EL2_DEFAULT, cptr_el2);
write_sysreg(__kvm_hyp_host_vector, vbar_el2);
}
--
2.29.2.454.gaff20da3a2-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 147+ messages in thread
* [PATCH v3 22/23] kvm: arm64: Trap host SMCs in protected mode
@ 2020-11-26 15:54 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Lorenzo Pieralisi, kernel-team, Jonathan Corbet, Catalin Marinas,
linux-doc, linux-kernel, Sudeep Holla, linux-arm-kernel,
Marc Zyngier, Tejun Heo, Dennis Zhou, Christoph Lameter,
Will Deacon
While protected nVHE KVM is installed, start trapping all host SMCs.
By default, these are simply forwarded to EL3, but PSCI SMCs are
validated first.
Create new constant HCR_HOST_NVHE_PROTECTED_FLAGS with the new set of HCR
flags to use while the nVHE vector is installed when the kernel was
booted with the protected flag enabled. Switch back to the default HCR
flags when switching back to the stub vector.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
arch/arm64/include/asm/kvm_arm.h | 1 +
arch/arm64/kvm/hyp/nvhe/hyp-init.S | 10 ++++++++++
arch/arm64/kvm/hyp/nvhe/switch.c | 5 ++++-
3 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
index 64ce29378467..4e90c2debf70 100644
--- a/arch/arm64/include/asm/kvm_arm.h
+++ b/arch/arm64/include/asm/kvm_arm.h
@@ -80,6 +80,7 @@
HCR_FMO | HCR_IMO | HCR_PTW )
#define HCR_VIRT_EXCP_MASK (HCR_VSE | HCR_VI | HCR_VF)
#define HCR_HOST_NVHE_FLAGS (HCR_RW | HCR_API | HCR_APK | HCR_ATA)
+#define HCR_HOST_NVHE_PROTECTED_FLAGS (HCR_HOST_NVHE_FLAGS | HCR_TSC)
#define HCR_HOST_VHE_FLAGS (HCR_RW | HCR_TGE | HCR_E2H)
/* TCR_EL2 Registers bits */
diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-init.S b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
index fbb195851fb9..7af18fa1983d 100644
--- a/arch/arm64/kvm/hyp/nvhe/hyp-init.S
+++ b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
@@ -88,6 +88,11 @@ SYM_CODE_END(__kvm_hyp_init)
* x0: struct kvm_nvhe_init_params PA
*/
SYM_CODE_START(___kvm_hyp_init)
+alternative_if ARM64_PROTECTED_KVM
+ mov_q x1, HCR_HOST_NVHE_PROTECTED_FLAGS
+ msr hcr_el2, x1
+alternative_else_nop_endif
+
ldr x1, [x0, #NVHE_INIT_TPIDR_EL2]
msr tpidr_el2, x1
@@ -233,6 +238,11 @@ reset:
msr sctlr_el2, x5
isb
+alternative_if ARM64_PROTECTED_KVM
+ mov_q x5, HCR_HOST_NVHE_FLAGS
+ msr hcr_el2, x5
+alternative_else_nop_endif
+
/* Install stub vectors */
adr_l x5, __hyp_stub_vectors
msr vbar_el2, x5
diff --git a/arch/arm64/kvm/hyp/nvhe/switch.c b/arch/arm64/kvm/hyp/nvhe/switch.c
index 3e50ff35aa4f..f3d0e9eca56c 100644
--- a/arch/arm64/kvm/hyp/nvhe/switch.c
+++ b/arch/arm64/kvm/hyp/nvhe/switch.c
@@ -97,7 +97,10 @@ static void __deactivate_traps(struct kvm_vcpu *vcpu)
mdcr_el2 |= MDCR_EL2_E2PB_MASK << MDCR_EL2_E2PB_SHIFT;
write_sysreg(mdcr_el2, mdcr_el2);
- write_sysreg(HCR_HOST_NVHE_FLAGS, hcr_el2);
+ if (is_protected_kvm_enabled())
+ write_sysreg(HCR_HOST_NVHE_PROTECTED_FLAGS, hcr_el2);
+ else
+ write_sysreg(HCR_HOST_NVHE_FLAGS, hcr_el2);
write_sysreg(CPTR_EL2_DEFAULT, cptr_el2);
write_sysreg(__kvm_hyp_host_vector, vbar_el2);
}
--
2.29.2.454.gaff20da3a2-goog
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply related [flat|nested] 147+ messages in thread
* [PATCH v3 23/23] kvm: arm64: Fix EL2 mode availability checks
2020-11-26 15:53 ` David Brazdil
(?)
@ 2020-11-26 15:54 ` David Brazdil
-1 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Jonathan Corbet, Catalin Marinas, Will Deacon, Marc Zyngier,
James Morse, Julien Thierry, Suzuki K Poulose, Dennis Zhou,
Tejun Heo, Christoph Lameter, Mark Rutland, Lorenzo Pieralisi,
Sudeep Holla, linux-doc, linux-kernel, linux-arm-kernel,
kernel-team, David Brazdil
With protected nVHE hyp code interception host's PSCI CPU_ON/SUSPEND
SMCs, the host starts seeing new CPUs boot in EL1 instead of EL2. The
kernel logic that keeps track of the boot mode needs to be adjusted.
Add a static key enabled if KVM protected nVHE initialization is
successful.
When the key is enabled, is_hyp_mode_available continues to report
`true` because its users either treat it as a check whether KVM will be
/ was initialized, or whether stub HVCs can be made (eg. hibernate).
is_hyp_mode_mismatched is changed to report `false` when the key is
enabled. That's because all cores' modes matched at the point of KVM
init and KVM will not allow cores not present at init to boot. That
said, the function is never used after KVM is initialized.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
arch/arm64/include/asm/virt.h | 18 ++++++++++++++++++
arch/arm64/kvm/arm.c | 10 +++++++---
2 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/include/asm/virt.h b/arch/arm64/include/asm/virt.h
index 2fde1186b962..f7cf3f0e5297 100644
--- a/arch/arm64/include/asm/virt.h
+++ b/arch/arm64/include/asm/virt.h
@@ -65,9 +65,19 @@ extern u32 __boot_cpu_mode[2];
void __hyp_set_vectors(phys_addr_t phys_vector_base);
void __hyp_reset_vectors(void);
+DECLARE_STATIC_KEY_FALSE(kvm_protected_mode_initialized);
+
/* Reports the availability of HYP mode */
static inline bool is_hyp_mode_available(void)
{
+ /*
+ * If KVM protected mode is initialized, all CPUs must have been booted
+ * in EL2. Avoid checking __boot_cpu_mode as CPUs now come up in EL1.
+ */
+ if (IS_ENABLED(CONFIG_KVM) &&
+ static_branch_likely(&kvm_protected_mode_initialized))
+ return true;
+
return (__boot_cpu_mode[0] == BOOT_CPU_MODE_EL2 &&
__boot_cpu_mode[1] == BOOT_CPU_MODE_EL2);
}
@@ -75,6 +85,14 @@ static inline bool is_hyp_mode_available(void)
/* Check if the bootloader has booted CPUs in different modes */
static inline bool is_hyp_mode_mismatched(void)
{
+ /*
+ * If KVM protected mode is initialized, all CPUs must have been booted
+ * in EL2. Avoid checking __boot_cpu_mode as CPUs now come up in EL1.
+ */
+ if (IS_ENABLED(CONFIG_KVM) &&
+ static_branch_likely(&kvm_protected_mode_initialized))
+ return false;
+
return __boot_cpu_mode[0] != __boot_cpu_mode[1];
}
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index 6ec8ddf74643..b153c08e50fa 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -46,6 +46,8 @@
__asm__(".arch_extension virt");
#endif
+DEFINE_STATIC_KEY_FALSE(kvm_protected_mode_initialized);
+
DECLARE_KVM_HYP_PER_CPU(unsigned long, kvm_hyp_vector);
static DEFINE_PER_CPU(unsigned long, kvm_arm_hyp_stack_page);
@@ -1877,12 +1879,14 @@ int kvm_arch_init(void *opaque)
if (err)
goto out_hyp;
- if (is_protected_kvm_enabled())
+ if (is_protected_kvm_enabled()) {
+ static_branch_enable(&kvm_protected_mode_initialized);
kvm_info("Protected nVHE mode initialized successfully\n");
- else if (in_hyp_mode)
+ } else if (in_hyp_mode) {
kvm_info("VHE mode initialized successfully\n");
- else
+ } else {
kvm_info("Hyp mode initialized successfully\n");
+ }
return 0;
--
2.29.2.454.gaff20da3a2-goog
^ permalink raw reply related [flat|nested] 147+ messages in thread* [PATCH v3 23/23] kvm: arm64: Fix EL2 mode availability checks
@ 2020-11-26 15:54 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Mark Rutland, Lorenzo Pieralisi, kernel-team, Jonathan Corbet,
Catalin Marinas, Suzuki K Poulose, linux-doc, linux-kernel,
Sudeep Holla, James Morse, linux-arm-kernel, Marc Zyngier,
Tejun Heo, Dennis Zhou, Christoph Lameter, David Brazdil,
Will Deacon, Julien Thierry
With protected nVHE hyp code interception host's PSCI CPU_ON/SUSPEND
SMCs, the host starts seeing new CPUs boot in EL1 instead of EL2. The
kernel logic that keeps track of the boot mode needs to be adjusted.
Add a static key enabled if KVM protected nVHE initialization is
successful.
When the key is enabled, is_hyp_mode_available continues to report
`true` because its users either treat it as a check whether KVM will be
/ was initialized, or whether stub HVCs can be made (eg. hibernate).
is_hyp_mode_mismatched is changed to report `false` when the key is
enabled. That's because all cores' modes matched at the point of KVM
init and KVM will not allow cores not present at init to boot. That
said, the function is never used after KVM is initialized.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
arch/arm64/include/asm/virt.h | 18 ++++++++++++++++++
arch/arm64/kvm/arm.c | 10 +++++++---
2 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/include/asm/virt.h b/arch/arm64/include/asm/virt.h
index 2fde1186b962..f7cf3f0e5297 100644
--- a/arch/arm64/include/asm/virt.h
+++ b/arch/arm64/include/asm/virt.h
@@ -65,9 +65,19 @@ extern u32 __boot_cpu_mode[2];
void __hyp_set_vectors(phys_addr_t phys_vector_base);
void __hyp_reset_vectors(void);
+DECLARE_STATIC_KEY_FALSE(kvm_protected_mode_initialized);
+
/* Reports the availability of HYP mode */
static inline bool is_hyp_mode_available(void)
{
+ /*
+ * If KVM protected mode is initialized, all CPUs must have been booted
+ * in EL2. Avoid checking __boot_cpu_mode as CPUs now come up in EL1.
+ */
+ if (IS_ENABLED(CONFIG_KVM) &&
+ static_branch_likely(&kvm_protected_mode_initialized))
+ return true;
+
return (__boot_cpu_mode[0] == BOOT_CPU_MODE_EL2 &&
__boot_cpu_mode[1] == BOOT_CPU_MODE_EL2);
}
@@ -75,6 +85,14 @@ static inline bool is_hyp_mode_available(void)
/* Check if the bootloader has booted CPUs in different modes */
static inline bool is_hyp_mode_mismatched(void)
{
+ /*
+ * If KVM protected mode is initialized, all CPUs must have been booted
+ * in EL2. Avoid checking __boot_cpu_mode as CPUs now come up in EL1.
+ */
+ if (IS_ENABLED(CONFIG_KVM) &&
+ static_branch_likely(&kvm_protected_mode_initialized))
+ return false;
+
return __boot_cpu_mode[0] != __boot_cpu_mode[1];
}
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index 6ec8ddf74643..b153c08e50fa 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -46,6 +46,8 @@
__asm__(".arch_extension virt");
#endif
+DEFINE_STATIC_KEY_FALSE(kvm_protected_mode_initialized);
+
DECLARE_KVM_HYP_PER_CPU(unsigned long, kvm_hyp_vector);
static DEFINE_PER_CPU(unsigned long, kvm_arm_hyp_stack_page);
@@ -1877,12 +1879,14 @@ int kvm_arch_init(void *opaque)
if (err)
goto out_hyp;
- if (is_protected_kvm_enabled())
+ if (is_protected_kvm_enabled()) {
+ static_branch_enable(&kvm_protected_mode_initialized);
kvm_info("Protected nVHE mode initialized successfully\n");
- else if (in_hyp_mode)
+ } else if (in_hyp_mode) {
kvm_info("VHE mode initialized successfully\n");
- else
+ } else {
kvm_info("Hyp mode initialized successfully\n");
+ }
return 0;
--
2.29.2.454.gaff20da3a2-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 147+ messages in thread* [PATCH v3 23/23] kvm: arm64: Fix EL2 mode availability checks
@ 2020-11-26 15:54 ` David Brazdil
0 siblings, 0 replies; 147+ messages in thread
From: David Brazdil @ 2020-11-26 15:54 UTC (permalink / raw)
To: kvmarm
Cc: Lorenzo Pieralisi, kernel-team, Jonathan Corbet, Catalin Marinas,
linux-doc, linux-kernel, Sudeep Holla, linux-arm-kernel,
Marc Zyngier, Tejun Heo, Dennis Zhou, Christoph Lameter,
Will Deacon
With protected nVHE hyp code interception host's PSCI CPU_ON/SUSPEND
SMCs, the host starts seeing new CPUs boot in EL1 instead of EL2. The
kernel logic that keeps track of the boot mode needs to be adjusted.
Add a static key enabled if KVM protected nVHE initialization is
successful.
When the key is enabled, is_hyp_mode_available continues to report
`true` because its users either treat it as a check whether KVM will be
/ was initialized, or whether stub HVCs can be made (eg. hibernate).
is_hyp_mode_mismatched is changed to report `false` when the key is
enabled. That's because all cores' modes matched at the point of KVM
init and KVM will not allow cores not present at init to boot. That
said, the function is never used after KVM is initialized.
Signed-off-by: David Brazdil <dbrazdil@google.com>
---
arch/arm64/include/asm/virt.h | 18 ++++++++++++++++++
arch/arm64/kvm/arm.c | 10 +++++++---
2 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/include/asm/virt.h b/arch/arm64/include/asm/virt.h
index 2fde1186b962..f7cf3f0e5297 100644
--- a/arch/arm64/include/asm/virt.h
+++ b/arch/arm64/include/asm/virt.h
@@ -65,9 +65,19 @@ extern u32 __boot_cpu_mode[2];
void __hyp_set_vectors(phys_addr_t phys_vector_base);
void __hyp_reset_vectors(void);
+DECLARE_STATIC_KEY_FALSE(kvm_protected_mode_initialized);
+
/* Reports the availability of HYP mode */
static inline bool is_hyp_mode_available(void)
{
+ /*
+ * If KVM protected mode is initialized, all CPUs must have been booted
+ * in EL2. Avoid checking __boot_cpu_mode as CPUs now come up in EL1.
+ */
+ if (IS_ENABLED(CONFIG_KVM) &&
+ static_branch_likely(&kvm_protected_mode_initialized))
+ return true;
+
return (__boot_cpu_mode[0] == BOOT_CPU_MODE_EL2 &&
__boot_cpu_mode[1] == BOOT_CPU_MODE_EL2);
}
@@ -75,6 +85,14 @@ static inline bool is_hyp_mode_available(void)
/* Check if the bootloader has booted CPUs in different modes */
static inline bool is_hyp_mode_mismatched(void)
{
+ /*
+ * If KVM protected mode is initialized, all CPUs must have been booted
+ * in EL2. Avoid checking __boot_cpu_mode as CPUs now come up in EL1.
+ */
+ if (IS_ENABLED(CONFIG_KVM) &&
+ static_branch_likely(&kvm_protected_mode_initialized))
+ return false;
+
return __boot_cpu_mode[0] != __boot_cpu_mode[1];
}
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index 6ec8ddf74643..b153c08e50fa 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -46,6 +46,8 @@
__asm__(".arch_extension virt");
#endif
+DEFINE_STATIC_KEY_FALSE(kvm_protected_mode_initialized);
+
DECLARE_KVM_HYP_PER_CPU(unsigned long, kvm_hyp_vector);
static DEFINE_PER_CPU(unsigned long, kvm_arm_hyp_stack_page);
@@ -1877,12 +1879,14 @@ int kvm_arch_init(void *opaque)
if (err)
goto out_hyp;
- if (is_protected_kvm_enabled())
+ if (is_protected_kvm_enabled()) {
+ static_branch_enable(&kvm_protected_mode_initialized);
kvm_info("Protected nVHE mode initialized successfully\n");
- else if (in_hyp_mode)
+ } else if (in_hyp_mode) {
kvm_info("VHE mode initialized successfully\n");
- else
+ } else {
kvm_info("Hyp mode initialized successfully\n");
+ }
return 0;
--
2.29.2.454.gaff20da3a2-goog
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply related [flat|nested] 147+ messages in thread
* Re: [PATCH v3 00/23] Opt-in always-on nVHE hypervisor
2020-11-26 15:53 ` David Brazdil
(?)
@ 2020-11-26 15:57 ` Matthew Wilcox
-1 siblings, 0 replies; 147+ messages in thread
From: Matthew Wilcox @ 2020-11-26 15:57 UTC (permalink / raw)
To: David Brazdil
Cc: kvmarm, Jonathan Corbet, Catalin Marinas, Will Deacon,
Marc Zyngier, James Morse, Julien Thierry, Suzuki K Poulose,
Dennis Zhou, Tejun Heo, Christoph Lameter, Mark Rutland,
Lorenzo Pieralisi, Sudeep Holla, linux-doc, linux-kernel,
linux-arm-kernel, kernel-team
On Thu, Nov 26, 2020 at 03:53:58PM +0000, David Brazdil wrote:
> The hypervisor starts trapping host SMCs and intercepting host's PSCI
> CPU_ON/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.
I hate CPU people. This is complete gibberish to anyone who doesn't
already have their head deep in ... whatever you're talking about.
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v3 00/23] Opt-in always-on nVHE hypervisor
@ 2020-11-26 15:57 ` Matthew Wilcox
0 siblings, 0 replies; 147+ messages in thread
From: Matthew Wilcox @ 2020-11-26 15:57 UTC (permalink / raw)
To: David Brazdil
Cc: Mark Rutland, Lorenzo Pieralisi, kernel-team, Jonathan Corbet,
Catalin Marinas, Suzuki K Poulose, linux-doc, linux-kernel,
Sudeep Holla, James Morse, linux-arm-kernel, Marc Zyngier,
Tejun Heo, Dennis Zhou, Christoph Lameter, Will Deacon, kvmarm,
Julien Thierry
On Thu, Nov 26, 2020 at 03:53:58PM +0000, David Brazdil wrote:
> The hypervisor starts trapping host SMCs and intercepting host's PSCI
> CPU_ON/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.
I hate CPU people. This is complete gibberish to anyone who doesn't
already have their head deep in ... whatever you're talking about.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v3 00/23] Opt-in always-on nVHE hypervisor
@ 2020-11-26 15:57 ` Matthew Wilcox
0 siblings, 0 replies; 147+ messages in thread
From: Matthew Wilcox @ 2020-11-26 15:57 UTC (permalink / raw)
To: David Brazdil
Cc: Lorenzo Pieralisi, kernel-team, Jonathan Corbet, Catalin Marinas,
linux-doc, linux-kernel, Sudeep Holla, linux-arm-kernel,
Marc Zyngier, Tejun Heo, Dennis Zhou, Christoph Lameter,
Will Deacon, kvmarm
On Thu, Nov 26, 2020 at 03:53:58PM +0000, David Brazdil wrote:
> The hypervisor starts trapping host SMCs and intercepting host's PSCI
> CPU_ON/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.
I hate CPU people. This is complete gibberish to anyone who doesn't
already have their head deep in ... whatever you're talking about.
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v3 00/23] Opt-in always-on nVHE hypervisor
2020-11-26 15:57 ` Matthew Wilcox
(?)
@ 2020-11-26 16:19 ` Marc Zyngier
-1 siblings, 0 replies; 147+ messages in thread
From: Marc Zyngier @ 2020-11-26 16:19 UTC (permalink / raw)
To: Matthew Wilcox
Cc: David Brazdil, kvmarm, Jonathan Corbet, Catalin Marinas,
Will Deacon, James Morse, Julien Thierry, Suzuki K Poulose,
Dennis Zhou, Tejun Heo, Christoph Lameter, Mark Rutland,
Lorenzo Pieralisi, Sudeep Holla, linux-doc, linux-kernel,
linux-arm-kernel, kernel-team
On 2020-11-26 15:57, Matthew Wilcox wrote:
> On Thu, Nov 26, 2020 at 03:53:58PM +0000, David Brazdil wrote:
>> The hypervisor starts trapping host SMCs and intercepting host's PSCI
>> CPU_ON/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.
>
> I hate CPU people. This is complete gibberish to anyone who doesn't
> already have their head deep in ... whatever you're talking about.
What I hate the most is people having a go at other people because they
don't understand what is being discussed. Who is at fault there?
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 147+ messages in thread* Re: [PATCH v3 00/23] Opt-in always-on nVHE hypervisor
@ 2020-11-26 16:19 ` Marc Zyngier
0 siblings, 0 replies; 147+ messages in thread
From: Marc Zyngier @ 2020-11-26 16:19 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Mark Rutland, Lorenzo Pieralisi, kernel-team, Jonathan Corbet,
Catalin Marinas, Suzuki K Poulose, linux-doc, linux-kernel,
James Morse, linux-arm-kernel, Sudeep Holla, Tejun Heo,
Dennis Zhou, Christoph Lameter, David Brazdil, Will Deacon,
kvmarm, Julien Thierry
On 2020-11-26 15:57, Matthew Wilcox wrote:
> On Thu, Nov 26, 2020 at 03:53:58PM +0000, David Brazdil wrote:
>> The hypervisor starts trapping host SMCs and intercepting host's PSCI
>> CPU_ON/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.
>
> I hate CPU people. This is complete gibberish to anyone who doesn't
> already have their head deep in ... whatever you're talking about.
What I hate the most is people having a go at other people because they
don't understand what is being discussed. Who is at fault there?
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
^ permalink raw reply [flat|nested] 147+ messages in thread* Re: [PATCH v3 00/23] Opt-in always-on nVHE hypervisor
@ 2020-11-26 16:19 ` Marc Zyngier
0 siblings, 0 replies; 147+ messages in thread
From: Marc Zyngier @ 2020-11-26 16:19 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Lorenzo Pieralisi, kernel-team, Jonathan Corbet, Catalin Marinas,
linux-doc, linux-kernel, linux-arm-kernel, Sudeep Holla,
Tejun Heo, Dennis Zhou, Christoph Lameter, Will Deacon, kvmarm
On 2020-11-26 15:57, Matthew Wilcox wrote:
> On Thu, Nov 26, 2020 at 03:53:58PM +0000, David Brazdil wrote:
>> The hypervisor starts trapping host SMCs and intercepting host's PSCI
>> CPU_ON/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.
>
> I hate CPU people. This is complete gibberish to anyone who doesn't
> already have their head deep in ... whatever you're talking about.
What I hate the most is people having a go at other people because they
don't understand what is being discussed. Who is at fault there?
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 147+ messages in thread* Re: [PATCH v3 00/23] Opt-in always-on nVHE hypervisor
2020-11-26 16:19 ` Marc Zyngier
(?)
@ 2020-11-26 16:23 ` Matthew Wilcox
-1 siblings, 0 replies; 147+ messages in thread
From: Matthew Wilcox @ 2020-11-26 16:23 UTC (permalink / raw)
To: Marc Zyngier
Cc: David Brazdil, kvmarm, Jonathan Corbet, Catalin Marinas,
Will Deacon, James Morse, Julien Thierry, Suzuki K Poulose,
Dennis Zhou, Tejun Heo, Christoph Lameter, Mark Rutland,
Lorenzo Pieralisi, Sudeep Holla, linux-doc, linux-kernel,
linux-arm-kernel, kernel-team
On Thu, Nov 26, 2020 at 04:19:55PM +0000, Marc Zyngier wrote:
> On 2020-11-26 15:57, Matthew Wilcox wrote:
> > On Thu, Nov 26, 2020 at 03:53:58PM +0000, David Brazdil wrote:
> > > The hypervisor starts trapping host SMCs and intercepting host's PSCI
> > > CPU_ON/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.
> >
> > I hate CPU people. This is complete gibberish to anyone who doesn't
> > already have their head deep in ... whatever you're talking about.
>
> What I hate the most is people having a go at other people because they
> don't understand what is being discussed. Who is at fault there?
The person who wrote an explanation that doesn't actually explain
anything? If you're sending mail to a bunch of mailing lists which
aren't already familiar with what you're trying to do, the onus is on
you to do more explanation.
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v3 00/23] Opt-in always-on nVHE hypervisor
@ 2020-11-26 16:23 ` Matthew Wilcox
0 siblings, 0 replies; 147+ messages in thread
From: Matthew Wilcox @ 2020-11-26 16:23 UTC (permalink / raw)
To: Marc Zyngier
Cc: Mark Rutland, Lorenzo Pieralisi, kernel-team, Jonathan Corbet,
Catalin Marinas, Suzuki K Poulose, linux-doc, linux-kernel,
James Morse, linux-arm-kernel, Sudeep Holla, Tejun Heo,
Dennis Zhou, Christoph Lameter, David Brazdil, Will Deacon,
kvmarm, Julien Thierry
On Thu, Nov 26, 2020 at 04:19:55PM +0000, Marc Zyngier wrote:
> On 2020-11-26 15:57, Matthew Wilcox wrote:
> > On Thu, Nov 26, 2020 at 03:53:58PM +0000, David Brazdil wrote:
> > > The hypervisor starts trapping host SMCs and intercepting host's PSCI
> > > CPU_ON/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.
> >
> > I hate CPU people. This is complete gibberish to anyone who doesn't
> > already have their head deep in ... whatever you're talking about.
>
> What I hate the most is people having a go at other people because they
> don't understand what is being discussed. Who is at fault there?
The person who wrote an explanation that doesn't actually explain
anything? If you're sending mail to a bunch of mailing lists which
aren't already familiar with what you're trying to do, the onus is on
you to do more explanation.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: [PATCH v3 00/23] Opt-in always-on nVHE hypervisor
@ 2020-11-26 16:23 ` Matthew Wilcox
0 siblings, 0 replies; 147+ messages in thread
From: Matthew Wilcox @ 2020-11-26 16:23 UTC (permalink / raw)
To: Marc Zyngier
Cc: Lorenzo Pieralisi, kernel-team, Jonathan Corbet, Catalin Marinas,
linux-doc, linux-kernel, linux-arm-kernel, Sudeep Holla,
Tejun Heo, Dennis Zhou, Christoph Lameter, Will Deacon, kvmarm
On Thu, Nov 26, 2020 at 04:19:55PM +0000, Marc Zyngier wrote:
> On 2020-11-26 15:57, Matthew Wilcox wrote:
> > On Thu, Nov 26, 2020 at 03:53:58PM +0000, David Brazdil wrote:
> > > The hypervisor starts trapping host SMCs and intercepting host's PSCI
> > > CPU_ON/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.
> >
> > I hate CPU people. This is complete gibberish to anyone who doesn't
> > already have their head deep in ... whatever you're talking about.
>
> What I hate the most is people having a go at other people because they
> don't understand what is being discussed. Who is at fault there?
The person who wrote an explanation that doesn't actually explain
anything? If you're sending mail to a bunch of mailing lists which
aren't already familiar with what you're trying to do, the onus is on
you to do more explanation.
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 147+ messages in thread