Re: [kvm-unit-tests PATCH 10/10] arm64: gic: Use IPI test checking for the LPI tests

2020-11-26 Thread Zenghui Yu
On 2020/11/25 23:51, Alexandru Elisei wrote: The reason for the failure is that the test "dev2/eventid=20 now triggers an LPI" triggers 2 LPIs, not one. This behavior was present before this patch, but it was ignored because check_lpi_stats() wasn't looking at the acked array. I'm not familiar w

[PATCH 0/2] KVM: arm64: Fix DEMUX register access

2020-11-26 Thread Andrew Jones
The first patch is a fix, but not one likely to ever truly be needed, as it's unlikely to find seven levels of cache. The bug was found while code reading. Writing the second patch was actually why I was reading the code. The issue being fixed for the get-reg-list test was found when running it on

[PATCH 1/2] KVM: arm64: CSSELR_EL1 max is 13

2020-11-26 Thread Andrew Jones
Not counting TnD, which KVM doesn't currently consider, CSSELR_EL1 can have a maximum value of 0b1101 (13), which corresponds to an instruction cache at level 7. With CSSELR_MAX set to 12 we can only select up to cache level 6. Change it to 14. Signed-off-by: Andrew Jones --- arch/arm64/kvm/sys_

[PATCH 2/2] KVM: selftests: Filter out DEMUX registers

2020-11-26 Thread Andrew Jones
DEMUX register presence depends on the host's hardware (the CLIDR_EL1 register to be precise). This means there's no set of them that we can bless and that it's possible to encounter new ones when running on different hardware (which would generate "Consider adding them ..." messages, but we'll nev

Re: [PATCH 1/2] KVM: arm64: CSSELR_EL1 max is 13

2020-11-26 Thread Marc Zyngier
On 2020-11-26 13:46, Andrew Jones wrote: Not counting TnD, which KVM doesn't currently consider, CSSELR_EL1 can have a maximum value of 0b1101 (13), which corresponds to an instruction cache at level 7. With CSSELR_MAX set to 12 we can only select up to cache level 6. Change it to 14. Signed-off

Re: [PATCH 1/2] KVM: arm64: CSSELR_EL1 max is 13

2020-11-26 Thread Andrew Jones
On Thu, Nov 26, 2020 at 02:13:44PM +, Marc Zyngier wrote: > On 2020-11-26 13:46, Andrew Jones wrote: > > Not counting TnD, which KVM doesn't currently consider, CSSELR_EL1 > > can have a maximum value of 0b1101 (13), which corresponds to an > > instruction cache at level 7. With CSSELR_MAX set

Re: [PATCH 1/2] KVM: arm64: CSSELR_EL1 max is 13

2020-11-26 Thread Marc Zyngier
On 2020-11-26 14:32, Andrew Jones wrote: On Thu, Nov 26, 2020 at 02:13:44PM +, Marc Zyngier wrote: On 2020-11-26 13:46, Andrew Jones wrote: > Not counting TnD, which KVM doesn't currently consider, CSSELR_EL1 > can have a maximum value of 0b1101 (13), which corresponds to an > instruction ca

Re: [PATCH 1/2] KVM: arm64: CSSELR_EL1 max is 13

2020-11-26 Thread Andrew Jones
On Thu, Nov 26, 2020 at 02:34:05PM +, Marc Zyngier wrote: > On 2020-11-26 14:32, Andrew Jones wrote: > > On Thu, Nov 26, 2020 at 02:13:44PM +, Marc Zyngier wrote: > > > On 2020-11-26 13:46, Andrew Jones wrote: > > > > Not counting TnD, which KVM doesn't currently consider, CSSELR_EL1 > > >

[PATCH] KVM: arm64: Refuse to run VCPU if PMU is not initialized

2020-11-26 Thread Alexandru Elisei
When enabling the PMU in kvm_arm_pmu_v3_enable(), KVM returns early if the PMU flag created is false and skips any other checks. Because PMU emulation is gated only on the VCPU feature being set, this makes it possible for userspace to get away with setting the VCPU feature but not doing any initia

Re: [PATCH 3/8] KVM: arm64: Refuse illegal KVM_ARM_VCPU_PMU_V3 at reset time

2020-11-26 Thread Alexandru Elisei
Hi Marc, On 11/13/20 6:25 PM, Marc Zyngier wrote: > We accept to configure a PMU when a vcpu is created, even if the > HW (or the host) doesn't support it. This results in failures > when attributes get set, which is a bit odd as we should have > failed the vcpu creation the first place. > > Move

Re: [PATCH 5/8] KVM: arm64: Remove PMU RAZ/WI handling

2020-11-26 Thread Alexandru Elisei
Hi Marc, This patch looks correct to me, I checked in the Arm ARM DDI 0487F.b and indeed all accesses to the PMU registers are UNDEFINED if the PMU is not present. I checked all the accessors and now all the PMU registers that KVM emulates will inject an undefined exception if the VCPU feature is

Re: [PATCH 6/8] KVM: arm64: Remove dead PMU sysreg decoding code

2020-11-26 Thread Alexandru Elisei
Hi Marc, I checked and indeed the remaining cases cover all registers that use this accessor. However, I'm a bit torn here. The warning that I got when trying to run a guest with the PMU feature flag set, but not initialized (reported at [1]) was also not supposed to ever be reached: static u3

Re: [PATCH 3/8] KVM: arm64: Refuse illegal KVM_ARM_VCPU_PMU_V3 at reset time

2020-11-26 Thread Marc Zyngier
Hi Alex, On 2020-11-26 14:59, Alexandru Elisei wrote: Hi Marc, On 11/13/20 6:25 PM, Marc Zyngier wrote: We accept to configure a PMU when a vcpu is created, even if the HW (or the host) doesn't support it. This results in failures when attributes get set, which is a bit odd as we should have f

Re: [PATCH 6/8] KVM: arm64: Remove dead PMU sysreg decoding code

2020-11-26 Thread Marc Zyngier
Hi Alex, On 2020-11-26 15:18, Alexandru Elisei wrote: Hi Marc, I checked and indeed the remaining cases cover all registers that use this accessor. However, I'm a bit torn here. The warning that I got when trying to run a guest with the PMU feature flag set, but not initialized (reported at

Re: [PATCH 3/8] KVM: arm64: Refuse illegal KVM_ARM_VCPU_PMU_V3 at reset time

2020-11-26 Thread Alexandru Elisei
Hi Marc, On 11/26/20 3:25 PM, Marc Zyngier wrote: > Hi Alex, > > On 2020-11-26 14:59, Alexandru Elisei wrote: >> Hi Marc, >> >> On 11/13/20 6:25 PM, Marc Zyngier wrote: >>> We accept to configure a PMU when a vcpu is created, even if the >>> HW (or the host) doesn't support it. This results in fai

Re: [PATCH 6/8] KVM: arm64: Remove dead PMU sysreg decoding code

2020-11-26 Thread Alexandru Elisei
Hi Marc, On 11/26/20 3:34 PM, Marc Zyngier wrote: > Hi Alex, > > On 2020-11-26 15:18, Alexandru Elisei wrote: >> Hi Marc, >> >> I checked and indeed the remaining cases cover all registers that use >> this accessor. >> >> However, I'm a bit torn here. The warning that I got when trying to run a >

Re: [PATCH 6/8] KVM: arm64: Remove dead PMU sysreg decoding code

2020-11-26 Thread Marc Zyngier
On 2020-11-26 15:54, Alexandru Elisei wrote: Hi Marc, On 11/26/20 3:34 PM, Marc Zyngier wrote: Hi Alex, On 2020-11-26 15:18, Alexandru Elisei wrote: Hi Marc, I checked and indeed the remaining cases cover all registers that use this accessor. However, I'm a bit torn here. The warning that I

Re: [PATCH v3 00/23] Opt-in always-on nVHE hypervisor

2020-11-26 Thread Matthew Wilcox
On Thu, Nov 26, 2020 at 03:53:58PM +, 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 ERETin

Re: [PATCH v3 00/23] Opt-in always-on nVHE hypervisor

2020-11-26 Thread Matthew Wilcox
On Thu, Nov 26, 2020 at 04:19:55PM +, Marc Zyngier wrote: > On 2020-11-26 15:57, Matthew Wilcox wrote: > > On Thu, Nov 26, 2020 at 03:53:58PM +, David Brazdil wrote: > > > The hypervisor starts trapping host SMCs and intercepting host's PSCI > > > CPU_ON/SUSPEND calls. It replaces the host'

Re: [PATCH v3 00/23] Opt-in always-on nVHE hypervisor

2020-11-26 Thread Marc Zyngier
On 2020-11-26 15:57, Matthew Wilcox wrote: On Thu, Nov 26, 2020 at 03:53:58PM +, 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 inst

Re: [PATCH 0/8] KVM: arm64: Disabled PMU handling

2020-11-26 Thread Alexandru Elisei
Hi Marc, On 11/13/20 6:25 PM, Marc Zyngier wrote: > It recently dawned on me that the way we handle PMU traps when the PMU > is disabled is plain wrong. We consider that handling the registers as > RAZ/WI is a fine thing to do, while the ARMv8 ARM is pretty clear that > that's not OK and that such

Re: [PATCH v3 01/23] psci: Support psci_ops.get_version for v0.1

2020-11-26 Thread Mark Rutland
On Thu, Nov 26, 2020 at 03:53:59PM +, 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

Re: [PATCH v3 02/23] psci: Accessor for configured PSCI function IDs

2020-11-26 Thread Mark Rutland
On Thu, Nov 26, 2020 at 03:54:00PM +, 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-

Re: [PATCH v3 03/23] arm64: Make cpu_logical_map() take unsigned int

2020-11-26 Thread Mark Rutland
On Thu, Nov 26, 2020 at 03:54:01PM +, 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 Is there a function problem here, or is this just cleanup from inspection? Core code inc

Re: [PATCH v3 02/23] psci: Accessor for configured PSCI function IDs

2020-11-26 Thread Lorenzo Pieralisi
On Thu, Nov 26, 2020 at 03:54:00PM +, 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 usi

Re: [PATCH v3 04/23] arm64: Move MAIR_EL1_SET to asm/memory.h

2020-11-26 Thread Mark Rutland
On Thu, Nov 26, 2020 at 03:54:02PM +, 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. > > S

Re: [PATCH v3 05/23] arm64: Extract parts of el2_setup into a macro

2020-11-26 Thread Mark Rutland
On Thu, Nov 26, 2020 at 03:54:03PM +, 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 g

[PATCH v3 18/23] kvm: arm64: Add function to enter host from KVM nVHE hyp code

2020-11-26 Thread 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 co

[PATCH v3 02/23] psci: Accessor for configured PSCI function IDs

2020-11-26 Thread 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 --- drivers/firmware/psci/psci.c | 16 ---

[PATCH v3 09/23] kvm: arm64: Move hyp-init params to a per-CPU struct

2020-11-26 Thread 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. Refact

[PATCH v3 21/23] kvm: arm64: Keep nVHE EL2 vector installed

2020-11-26 Thread 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 --- a

[PATCH v3 11/23] kvm: arm64: Support per_cpu_ptr in nVHE hyp code

2020-11-26 Thread 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

[PATCH v3 10/23] kvm: arm64: Add .hyp.data..ro_after_init ELF section

2020-11-26 Thread 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 secti

[PATCH v3 01/23] psci: Support psci_ops.get_version for v0.1

2020-11-26 Thread 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 current

[PATCH v3 08/23] kvm: arm64: Remove vector_ptr param of hyp-init

2020-11-26 Thread 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. Sig

[PATCH v3 20/23] kvm: arm64: Intercept host's CPU_SUSPEND PSCI SMCs

2020-11-26 Thread 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 EL

[PATCH v3 07/23] kvm: arm64: Initialize MAIR_EL2 using a constant

2020-11-26 Thread 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. Sig

[PATCH v3 19/23] kvm: arm64: Intercept host's CPU_ON SMCs

2020-11-26 Thread 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 retu

[PATCH v3 14/23] kvm: arm64: Bootstrap PSCI SMC handler in nVHE EL2

2020-11-26 Thread 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 S

[PATCH v3 06/23] kvm: arm64: Add kvm-arm.protected early kernel parameter

2020-11-26 Thread 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 SMC

[PATCH v3 12/23] kvm: arm64: Create nVHE copy of cpu_logical_map

2020-11-26 Thread 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 featur

[PATCH v3 04/23] arm64: Move MAIR_EL1_SET to asm/memory.h

2020-11-26 Thread 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 --- arch/arm64/include/asm/memory.h | 13