- 17 Oct, 2021 24 commits
-
-
Marc Zyngier authored
* kvm-arm64/memory-accounting: : . : Sprinkle a bunch of GFP_KERNEL_ACCOUNT all over the code base : to better track memory allocation made on behalf of a VM. : . KVM: arm64: Add memcg accounting to KVM allocations KVM: arm64: vgic: Add memcg accounting to vgic allocations Signed-off-by:Marc Zyngier <maz@kernel.org>
-
Jia He authored
Inspired by commit 254272ce ("kvm: x86: Add memcg accounting to KVM allocations"), it would be better to make arm64 KVM consistent with common kvm codes. The memory allocations of VM scope should be charged into VM process cgroup, hence change GFP_KERNEL to GFP_KERNEL_ACCOUNT. There remain a few cases since these allocations are global, not in VM scope. Signed-off-by:
Jia He <justin.he@arm.com> Reviewed-by:
Oliver Upton <oupton@google.com> Signed-off-by:
-
Jia He authored
Inspired by commit 254272ce ("kvm: x86: Add memcg accounting to KVM allocations"), it would be better to make arm64 vgic consistent with common kvm codes. The memory allocations of VM scope should be charged into VM process cgroup, hence change GFP_KERNEL to GFP_KERNEL_ACCOUNT. There remain a few cases since these allocations are global, not in VM scope. Signed-off-by:
-
Marc Zyngier authored
* kvm-arm64/selftest/timer: : . : Add a set of selftests for the KVM/arm64 timer emulation. : Comes with a minimal GICv3 infrastructure. : . KVM: arm64: selftests: arch_timer: Support vCPU migration KVM: arm64: selftests: Add arch_timer test KVM: arm64: selftests: Add host support for vGIC KVM: arm64: selftests: Add basic GICv3 support KVM: arm64: selftests: Add light-weight spinlock support KVM: arm64: selftests: Add guest support to get the vcpuid KVM: arm64: selftests: Maintain consistency for vcpuid type KVM: arm64: selftests: Add support to disable and enable local IRQs KVM: arm64: selftests: Add basic support to generate delays KVM: arm64: selftests: Add basic support for arch_timers KVM: arm64: selftests: Add support for cpu_relax KVM: arm64: selftests: Introduce ARM64_SYS_KVM_REG tools: arm64: Import sysreg.h KVM: arm64: selftests: Add MMIO readl/writel support Signed-off-by: -
Raghavendra Rao Ananta authored
Since the timer stack (hardware and KVM) is per-CPU, there are potential chances for races to occur when the scheduler decides to migrate a vCPU thread to a different physical CPU. Hence, include an option to stress-test this part as well by forcing the vCPUs to migrate across physical CPUs in the system at a particular rate. Originally, the bug for the fix with commit 3134cc8b ("KVM: arm64: vgic: Resample HW pending state on deactivation") was discovered using arch_timer test with vCPU migrations and can be easily reproduced. Signed-off-by:
Raghavendra Rao Ananta <rananta@google.com> Reviewed-by:
Andrew Jones <drjones@redhat.com> Signed-off-by:
-
Raghavendra Rao Ananta authored
Add a KVM selftest to validate the arch_timer functionality. Primarily, the test sets up periodic timer interrupts and validates the basic architectural expectations upon its receipt. The test provides command-line options to configure the period of the timer, number of iterations, and number of vCPUs. Signed-off-by:
-
Raghavendra Rao Ananta authored
Implement a simple library to perform vGIC-v3 setup from a host point of view. This includes creating a vGIC device, setting up distributor and redistributor attributes, and mapping the guest physical addresses. The definition of REDIST_REGION_ATTR_ADDR is taken from aarch64/vgic_init test. Hence, replace the definition by including vgic.h in the test file. Signed-off-by:
Ricardo Koller <ricarkol@google.com> Reviewed-by:
-
Raghavendra Rao Ananta authored
Add basic support for ARM Generic Interrupt Controller v3. The support provides guests to setup interrupts. The work is inspired from kvm-unit-tests and the kernel's GIC driver (drivers/irqchip/irq-gic-v3.c). Signed-off-by:
-
Raghavendra Rao Ananta authored
Add a simpler version of spinlock support for ARM64 for the guests to use. The implementation is loosely based on the spinlock implementation in kvm-unit-tests. Signed-off-by:
-
Raghavendra Rao Ananta authored
At times, such as when in the interrupt handler, the guest wants to get the vcpuid that it's running on to pull the per-cpu private data. As a result, introduce guest_get_vcpuid() that returns the vcpuid of the calling vcpu. The interface is architecture independent, but defined only for arm64 as of now. Suggested-by:
Reiji Watanabe <reijiw@google.com> Signed-off-by:
-
Raghavendra Rao Ananta authored
The prototype of aarch64_vcpu_setup() accepts vcpuid as 'int', while the rest of the aarch64 (and struct vcpu) carries it as 'uint32_t'. Hence, change the prototype to make it consistent throughout the board. Signed-off-by:
-
Raghavendra Rao Ananta authored
Add functions local_irq_enable() and local_irq_disable() to enable and disable the IRQs from the guest, respectively. Signed-off-by:
-
Raghavendra Rao Ananta authored
Add udelay() support to generate a delay in the guest. The routines are derived and simplified from kernel's arch/arm64/lib/delay.c. Signed-off-by:
-
Raghavendra Rao Ananta authored
Add a minimalistic library support to access the virtual timers, that can be used for simple timing functionalities, such as introducing delays in the guest. Signed-off-by:
-
Raghavendra Rao Ananta authored
Implement the guest helper routine, cpu_relax(), to yield the processor to other tasks. The function was derived from arch/arm64/include/asm/vdso/processor.h. Signed-off-by:
-
Raghavendra Rao Ananta authored
With the inclusion of sysreg.h, that brings in system register encodings, it would be redundant to re-define register encodings again in processor.h to use it with ARM64_SYS_REG for the KVM functions such as set_reg() or get_reg(). Hence, add helper macro, ARM64_SYS_KVM_REG, that converts SYS_* definitions in sysreg.h into ARM64_SYS_REG definitions. Also replace all the users of ARM64_SYS_REG, relying on the encodings created in processor.h, with ARM64_SYS_KVM_REG and remove the definitions. Signed-off-by:
-
Raghavendra Rao Ananta authored
Bring-in the kernel's arch/arm64/include/asm/sysreg.h into tools/ for arm64 to make use of all the standard register definitions in consistence with the kernel. Make use of the register read/write definitions from sysreg.h, instead of the existing definitions. A syntax correction is needed for the files that use write_sysreg() to make it compliant with the new (kernel's) syntax. Reviewed-by:
-
Raghavendra Rao Ananta authored
Define the readl() and writel() functions for the guests to access (4-byte) the MMIO region. The routines, and their dependents, are inspired from the kernel's arch/arm64/include/asm/io.h and arch/arm64/include/asm/barrier.h. Signed-off-by:
-
Marc Zyngier authored
* kvm-arm64/vgic-fixes-5.16: : . : Multiple updates to the GICv3 emulation in order to better support : the dreadful Apple M1 that only implements half of it, and in a : broken way... : . KVM: arm64: vgic-v3: Align emulated cpuif LPI state machine with the pseudocode KVM: arm64: vgic-v3: Don't advertise ICC_CTLR_EL1.SEIS KVM: arm64: vgic-v3: Reduce common group trapping to ICV_DIR_EL1 when possible KVM: arm64: vgic-v3: Work around GICv3 locally generated SErrors KVM: arm64: Force ID_AA64PFR0_EL1.GIC=1 when exposing a virtual GICv3 Signed-off-by: -
Marc Zyngier authored
Having realised that a virtual LPI does transition through an active state that does not exist on bare metal, align the CPU interface emulation with the behaviour specified in the architecture pseudocode. The LPIs now transition to active on IAR read, and to inactive on EOI write. Special care is taken not to increment the EOIcount for an LPI that isn't present in the LRs. Signed-off-by:
-
Marc Zyngier authored
Since we are trapping all sysreg accesses when ICH_VTR_EL2.SEIS is set, and that we never deliver an SError when emulating any of the GICv3 sysregs, don't advertise ICC_CTLR_EL1.SEIS. Reviewed-by:
Alexandru Elisei <alexandru.elisei@arm.com> Signed-off-by:
-
Marc Zyngier authored
On systems that advertise ICH_VTR_EL2.SEIS, we trap all GICv3 sysreg accesses from the guest. From a performance perspective, this is OK as long as the guest doesn't hammer the GICv3 CPU interface. In most cases, this is fine, unless the guest actively uses priorities and switches PMR_EL1 very often. Which is exactly what happens when a Linux guest runs with irqchip.gicv3_pseudo_nmi=1. In these condition, the performance plumets as we hit PMR each time we mask/unmask interrupts. Not good. There is however an opportunity for improvement. Careful reading of the architecture specification indicates that the only GICv3 sysreg belonging to the common group (which contains the SGI registers, PMR, DIR, CTLR and RPR) that is allowed to generate a SError is DIR. Everything else is safe. It is thus possible to substitute the trapping of all the common group with just that of DIR if it supported by the implementation. Yes, that's yet another optional bit of the architecture. So let's just do that, as it leads to some impressive result on the M1: Without this change: bash-5.1# /host/home/maz/hackbench 100 process 1000 Running with 100*40 (== 4000) tasks. Time: 56.596 With this change: bash-5.1# /host/home/maz/hackbench 100 process 1000 Running with 100*40 (== 4000) tasks. Time: 8.649 which is a pretty convincing result. Signed-off-by:
-
Marc Zyngier authored
The infamous M1 has a feature nobody else ever implemented, in the form of the "GIC locally generated SError interrupts", also known as SEIS for short. These SErrors are generated when a guest does something that violates the GIC state machine. It would have been simpler to just *ignore* the damned thing, but that's not what this HW does. Oh well. This part of of the architecture is also amazingly under-specified. There is a whole 10 lines that describe the feature in a spec that is 930 pages long, and some of these lines are factually wrong. Oh, and it is deprecated, so the insentive to clarify it is low. Now, the spec says that this should be a *virtual* SError when HCR_EL2.AMO is set. As it turns out, that's not always the case on this CPU, and the SError sometimes fires on the host as a physical SError. Goodbye, cruel world. This clearly is a HW bug, and it means that a guest can easily take the host down, on demand. Thankfully, we have seen systems that were just as broken in the past, and we have the perfect vaccine for it. Apple M1, please meet the Cavium ThunderX workaround. All your GIC accesses will be trapped, sanitised, and emulated. Only the signalling aspect of the HW will be used. It won't be super speedy, but it will at least be safe. You're most welcome. Given that this has only ever been seen on this single implementation, that the spec is unclear at best and that we cannot trust it to ever be implemented correctly, gate the workaround solely on ICH_VTR_EL2.SEIS being set. Tested-by:
Joey Gouly <joey.gouly@arm.com> Reviewed-by:
-
Marc Zyngier authored
Until now, we always let ID_AA64PFR0_EL1.GIC reflect the value visible on the host, even if we were running a GICv2-enabled VM on a GICv3+compat host. That's fine, but we also now have the case of a host that does not expose ID_AA64PFR0_EL1.GIC==1 despite having a vGIC. Yes, this is confusing. Thank you M1. Let's go back to first principles and expose ID_AA64PFR0_EL1.GIC=1 when a GICv3 is exposed to the guest. This also hides a GICv4.1 CPU interface from the guest which has no business knowing about the v4.1 extension. Reviewed-by:
-
- 12 Oct, 2021 2 commits
-
-
Marc Zyngier authored
* kvm-arm64/misc-5.16: : . : - Allow KVM to be disabled from the command-line : - Clean up CONFIG_KVM vs CONFIG_HAVE_KVM : - Fix endianess evaluation on MMIO access from EL0 : . KVM: arm64: Fix reporting of endianess when the access originates at EL0 Signed-off-by: -
Marc Zyngier authored
We currently check SCTLR_EL1.EE when computing the address of a faulting guest access. However, the fault could have occured at EL0, in which case the right bit to check would be SCTLR_EL1.E0E. This is pretty unlikely to cause any issue in practice: You'd have to have a guest with a LE EL1 and a BE EL0 (or the other way around), and have mapped a device into the EL0 page tables. Good luck with that! Signed-off-by:
-
- 11 Oct, 2021 14 commits
-
-
Marc Zyngier authored
* kvm-arm64/pkvm/restrict-hypercalls: : . : Restrict the use of some hypercalls as well as kexec once : the protected KVM mode has been initialised. : . Documentation: admin-guide: Document side effects when pKVM is enabled Signed-off-by: -
Alexandru Elisei authored
Recent changes to KVM for arm64 has made it impossible for the host to hibernate or use kexec when protected mode is enabled via the kernel command line. There are people who rely on kexec (for example, developers who use kexec as a quick way to test a new kernel), let's document this change in behaviour, so it doesn't catch them by surprise and we have a place to point people to if it does. Signed-off-by:
-
Marc Zyngier authored
* kvm-arm64/raz-sysregs: : . : Simplify the handling of RAZ register, removing pointless indirections. : . KVM: arm64: Replace get_raz_id_reg() with get_raz_reg() KVM: arm64: Use get_raz_reg() for userspace reads of PMSWINC_EL0 KVM: arm64: Return early from read_id_reg() if register is RAZ Signed-off-by: -
Alexandru Elisei authored
Reading a RAZ ID register isn't different from reading any other RAZ register, so get rid of get_raz_id_reg() and replace it with get_raz_reg(), which does the same thing, but does it without going through two layers of indirection. No functional change. Suggested-by:
-
Alexandru Elisei authored
PMSWINC_EL0 is a write-only register and was initially part of the VCPU register state, but was later removed in commit 7a3ba309 ("KVM: arm64: Remove PMSWINC_EL0 shadow register"). To prevent regressions, the register was kept accessible from userspace as Read-As-Zero (RAZ). The read function that is used to handle userspace reads of this register is get_raz_id_reg(), which, while technically correct, as it returns 0, it is not semantically correct, as PMSWINC_EL0 is not an ID register as the function name suggests. Add a new function, get_raz_reg(), to use it as the accessor for PMSWINC_EL0, as to not conflate get_raz_id_reg() to handle other types of registers. No functional change intended. Signed-off-by:
-
Alexandru Elisei authored
If read_id_reg() is called for an ID register which is Read-As-Zero (RAZ), it initializes the return value to zero, then goes through a list of registers which require special handling before returning the final value. By not returning as soon as it checks that the register should be RAZ, the function creates the opportunity for bugs, if, for example, a patch changes a register to RAZ (like has happened with PMSWINC_EL0 in commit 11663111), but doesn't remove the special handling from read_id_reg(); or if a register is RAZ in certain situations, but readable in others. Return early to make it impossible for a RAZ register to be anything other than zero. Reviewed-by:
-
Marc Zyngier authored
* kvm-arm64/misc-5.16: : . : - Allow KVM to be disabled from the command-line : - Clean up CONFIG_KVM vs CONFIG_HAVE_KVM : . KVM: arm64: Depend on HAVE_KVM instead of OF KVM: arm64: Unconditionally include generic KVM's Kconfig KVM: arm64: Allow KVM to be disabled from the command line Signed-off-by: -
Sean Christopherson authored
Select HAVE_KVM at all times on arm64, as the OF requirement is always there (even in the case of an ACPI system, we still depend on some of the OF infrastructure), and won't fo away. No functional change intended. Signed-off-by:
Sean Christopherson <seanjc@google.com> Acked-by:
Will Deacon <will@kernel.org> [maz: Drop the "HAVE_KVM if OF" dependency, as OF is always there on arm64, new commit message] Signed-off-by:
-
Sean Christopherson authored
Unconditionally "source" the generic KVM Kconfig instead of wrapping it with KVM=y. A future patch will select HAVE_KVM so that referencing HAVE_KVM in common kernel code doesn't break, and because KVM=y and HAVE_KVM=n is weird. Source the generic KVM Kconfig unconditionally so that HAVE_KVM and KVM don't end up with a circular dependency. Note, all but one of generic KVM's "configs" are of the HAVE_XYZ nature, and the one outlier correctly takes a dependency on CONFIG_KVM, i.e. the generic Kconfig is intended to be included unconditionally. No functional change intended. Signed-off-by:
-
Marc Zyngier authored
Although KVM can be compiled out of the kernel, it cannot be disabled at runtime. Allow this possibility by introducing a new mode that will prevent KVM from initialising. This is useful in the (limited) circumstances where you don't want KVM to be available (what is wrong with you?), or when you want to install another hypervisor instead (good luck with that). Reviewed-by:
David Brazdil <dbrazdil@google.com> Acked-by:
Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by:
Andrew Scull <ascull@google.com> Link: https://lore.kernel.org/r/20211001170553.3062988-1-maz@kernel.org
-
Marc Zyngier authored
* kvm-arm64/vgic-ipa-checks: : . : Add extra checks to prevent ther various GIC regions to land : outside of the IPA space (and tests to verify that it works). : . KVM: arm64: selftests: Add init ITS device test KVM: arm64: selftests: Add test for legacy GICv3 REDIST base partially above IPA range KVM: arm64: selftests: Add tests for GIC redist/cpuif partially above IPA range KVM: arm64: selftests: Add some tests for GICv2 in vgic_init KVM: arm64: selftests: Make vgic_init/vm_gic_create version agnostic KVM: arm64: selftests: Make vgic_init gic version agnostic KVM: arm64: vgic: Drop vgic_check_ioaddr() KVM: arm64: vgic-v3: Check ITS region is not above the VM IPA size KVM: arm64: vgic-v2: Check cpu interface region is not above the VM IPA size KVM: arm64: vgic-v3: Check redist region is not above the VM IPA size kvm: arm64: vgic: Introduce vgic_check_iorange Signed-off-by: -
Ricardo Koller authored
Add some ITS device init tests: general KVM device tests (address not defined already, address aligned) and tests for the ITS region being within the addressable IPA range. Signed-off-by:
Eric Auger <eric.auger@redhat.com> Reviewed-by:
-
Ricardo Koller authored
Add a new test into vgic_init which checks that the first vcpu fails to run if there is not sufficient REDIST space below the addressable IPA range. This only applies to the KVM_VGIC_V3_ADDR_TYPE_REDIST legacy API as the required REDIST space is not know when setting the DIST region. Note that using the REDIST_REGION API results in a different check at first vcpu run: that the number of redist regions is enough for all vcpus. And there is already a test for that case in, the first step of test_v3_new_redist_regions. Reviewed-by:
-
Ricardo Koller authored
Add tests for checking that KVM returns the right error when trying to set GICv2 CPU interfaces or GICv3 Redistributors partially above the addressable IPA range. Also tighten the IPA range by replacing KVM_CAP_ARM_VM_IPA_SIZE with the IPA range currently configured for the guest (i.e., the default). The check for the GICv3 redistributor created using the REDIST legacy API is not sufficient as this new test only checks the check done using vcpus already created when setting the base. The next commit will add the missing test which verifies that the KVM check is done at first vcpu run. Signed-off-by:
-
