- 09 Oct, 2022 1 commit
-
-
Oliver Upton authored
Work out the minimum page table level where KVM supports block mappings at compile time. While at it, rewrite the comment around supported block mappings to directly describe what KVM supports instead of phrasing in terms of what it does not. Signed-off-by:
Oliver Upton <oliver.upton@linux.dev> Signed-off-by:
Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20221007234151.461779-2-oliver.upton@linux.dev
-
- 01 Oct, 2022 3 commits
-
-
Marc Zyngier authored
* kvm-arm64/misc-6.1: : . : Misc KVM/arm64 fixes and improvement for v6.1 : : - Simplify the affinity check when moving a GICv3 collection : : - Tone down the shouting when kvm-arm.mode=protected is passed : to a guest : : - Fix various comments : : - Advertise the new kvmarm@lists.linux.dev and deprecate the : old Columbia list : . KVM: arm64: Advertise new kvmarm mailing list KVM: arm64: Fix comment typo in nvhe/switch.c KVM: selftests: Update top-of-file comment in psci_test KVM: arm64: Ignore kvm-arm.mode if !is_hyp_mode_available() KVM: arm64: vgic: Remove duplicate check in update_affinity_collection() Signed-off-by: -
Marc Zyngier authored
* kvm-arm64/dirty-log-ordered: : . : Retrofit some ordering into the existing API dirty-ring by: : : - relying on acquire/release semantics which are the default on x86, : but need to be explicit on arm64 : : - adding a new capability that indicate which flavor is supported, either : with explicit ordering (arm64) or both implicit and explicit (x86), : as suggested by Paolo at KVM Forum : : - documenting the requirements for this new capability on weakly ordered : architectures : : - updating the selftests to do the right thing : . KVM: selftests: dirty-log: Use KVM_CAP_DIRTY_LOG_RING_ACQ_REL if available KVM: selftests: dirty-log: Upgrade flag accesses to acquire/release semantics KVM: Document weakly ordered architecture requirements for dirty ring KVM: x86: Select CONFIG_HAVE_KVM_DIRTY_RING_ACQ_REL KVM: Add KVM_CAP_DIRTY_LOG_RING_ACQ_REL capability and config option KVM: Use acquire/release semantics when accessing dirty ring GFN state Signed-off-by: -
Marc Zyngier authored
As announced on the kvmarm list, we're moving the mailing list over to kvmarm@lists.linux.dev: <quote> As you probably all know, the kvmarm mailing has been hosted on Columbia's machines for as long as the project existed (over 13 years). After all this time, the university has decided to retire the list infrastructure and asked us to find a new hosting. A new mailing list has been created on lists.linux.dev[1], and I'm kindly asking everyone interested in following the KVM/arm64 developments to start subscribing to it (and start posting your patches there). I hope that people will move over to it quickly enough that we can soon give Columbia the green light to turn their systems off. Note that the new list will only get archived automatically once we fully switch over, but I'll make sure we fill any gap and not lose any message. In the meantime, please Cc both lists. [...] [1] https://subspace.kernel.org/lists.linux.dev.html </quote> Signed-off-by:
-
- 29 Sep, 2022 7 commits
-
-
Marc Zyngier authored
Pick KVM_CAP_DIRTY_LOG_RING_ACQ_REL if exposed by the kernel. Signed-off-by:
Gavin Shan <gshan@redhat.com> Reviewed-by:
Peter Xu <peterx@redhat.com> Link: https://lore.kernel.org/r/20220926145120.27974-7-maz@kernel.org
-
Marc Zyngier authored
In order to preserve ordering, make sure that the flag accesses in the dirty log are done using acquire/release accessors. Signed-off-by:
-
Marc Zyngier authored
Now that the kernel can expose to userspace that its dirty ring management relies on explicit ordering, document these new requirements for VMMs to do the right thing. Signed-off-by:
-
Marc Zyngier authored
Since x86 is TSO (give or take), allow it to advertise the new ACQ_REL version of the dirty ring capability. No other change is required for it. Signed-off-by:
-
Marc Zyngier authored
In order to differenciate between architectures that require no extra synchronisation when accessing the dirty ring and those who do, add a new capability (KVM_CAP_DIRTY_LOG_RING_ACQ_REL) that identify the latter sort. TSO architectures can obviously advertise both, while relaxed architectures must only advertise the ACQ_REL version. This requires some configuration symbol rejigging, with HAVE_KVM_DIRTY_RING being only indirectly selected by two top-level config symbols: - HAVE_KVM_DIRTY_RING_TSO for strongly ordered architectures (x86) - HAVE_KVM_DIRTY_RING_ACQ_REL for weakly ordered architectures (arm64) Suggested-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
Marc Zyngier authored
The current implementation of the dirty ring has an implicit requirement that stores to the dirty ring from userspace must be: - be ordered with one another - visible from another CPU executing a ring reset While these implicit requirements work well for x86 (and any other TSO-like architecture), they do not work for more relaxed architectures such as arm64 where stores to different addresses can be freely reordered, and loads from these addresses not observing writes from another CPU unless the required barriers (or acquire/release semantics) are used. In order to start fixing this, upgrade the ring reset accesses: - the kvm_dirty_gfn_harvested() helper now uses acquire semantics so it is ordered after all previous writes, including that from userspace - the kvm_dirty_gfn_set_invalid() helper now uses release semantics so that the next_slot and next_offset reads don't drift past the entry invalidation This is only a partial fix as the userspace side also need upgrading. Signed-off-by:
-
Wei-Lin Chang authored
Fix the comment of __hyp_vgic_restore_state() from saying VEH to VHE, also change the underscore to a dash to match the comment above __hyp_vgic_save_state(). Signed-off-by:
Wei-Lin Chang <r09922117@csie.ntu.edu.tw> Signed-off-by:
-
- 28 Sep, 2022 1 commit
-
-
Oliver Upton authored
Fix the comment to accurately describe the test and recently added SYSTEM_SUSPEND test case. What was once psci_cpu_on_test was renamed and extended to squeeze in a test case for PSCI SYSTEM_SUSPEND. Nonetheless, the author of those changes (whoever they may be...) failed to update the file comment to reflect what had changed. Reported-by:
Reiji Watanabe <reijiw@google.com> Signed-off-by:
-
- 26 Sep, 2022 2 commits
-
-
Elliot Berman authored
Ignore kvm-arm.mode if !is_hyp_mode_available(). Specifically, we want to avoid switching kvm_mode to KVM_MODE_PROTECTED if hypervisor mode is not available. This prevents "Protected KVM" cpu capability being reported when Linux is booting in EL1 and would not have KVM enabled. Reasonably though, we should warn if the command line is requesting a KVM mode at all if KVM isn't actually available. Allow "kvm-arm.mode=none" to skip the warning since this would disable KVM anyway. Signed-off-by:
Elliot Berman <quic_eberman@quicinc.com> Signed-off-by:
-
Gavin Shan authored
The 'coll' parameter to update_affinity_collection() is never NULL, so comparing it with 'ite->collection' is enough to cover both the NULL case and the "another collection" case. Remove the duplicate check in update_affinity_collection(). Signed-off-by:
-
- 19 Sep, 2022 6 commits
-
-
Marc Zyngier authored
* kvm-arm64/single-step-async-exception: : . : Single-step fixes from Reiji Watanabe: : : "This series fixes two bugs of single-step execution enabled by : userspace, and add a test case for KVM_GUESTDBG_SINGLESTEP to : the debug-exception test to verify the single-step behavior." : . KVM: arm64: selftests: Add a test case for KVM_GUESTDBG_SINGLESTEP KVM: arm64: selftests: Refactor debug-exceptions to make it amenable to new test cases KVM: arm64: Clear PSTATE.SS when the Software Step state was Active-pending KVM: arm64: Preserve PSTATE.SS for the guest while single-step is enabled Signed-off-by: -
Reiji Watanabe authored
Add a test case for KVM_GUESTDBG_SINGLESTEP to the debug-exceptions test. The test enables single-step execution from userspace, and check if the exit to userspace occurs for each instruction that is stepped. Set the default number of the test iterations to a number of iterations sufficient to always reproduce the problem that the previous patch fixes on an Ampere Altra machine. Signed-off-by:
-
Reiji Watanabe authored
Split up the current test into a helper, but leave the debug version checking in main(), to make it convenient to add a new debug exception test case in a subsequent patch. Signed-off-by:
-
Reiji Watanabe authored
While userspace enables single-step, if the Software Step state at the last guest exit was "Active-pending", clear PSTATE.SS on guest entry to restore the state. Currently, KVM sets PSTATE.SS to 1 on every guest entry while userspace enables single-step for the vCPU (with KVM_GUESTDBG_SINGLESTEP). It means KVM always makes the vCPU's Software Step state "Active-not-pending" on the guest entry, which lets the VCPU perform single-step (then Software Step exception is taken). This could cause extra single-step (without returning to userspace) if the Software Step state at the last guest exit was "Active-pending" (i.e. the last exit was triggered by an asynchronous exception after the single-step is performed, but before the Software Step exception is taken. See "Figure D2-3 Software step state machine" and "D2.12.7 Behavior in the active-pending state" in ARM DDI 0487I.a for more info about this behavior). Fix this by clearing PSTATE.SS on guest entry if the Software Step state at the last exit was "Active-pending" so that KVM restore the state (and the exception is taken before further single-step is performed). Fixes: 337b99bf ("KVM: arm64: guest debug, add support for single-step") Signed-off-by:
-
Reiji Watanabe authored
Preserve the PSTATE.SS value for the guest while userspace enables single-step (i.e. while KVM manipulates the PSTATE.SS) for the vCPU. Currently, while userspace enables single-step for the vCPU (with KVM_GUESTDBG_SINGLESTEP), KVM sets PSTATE.SS to 1 on every guest entry, not saving its original value. When userspace disables single-step, KVM doesn't restore the original value for the subsequent guest entry (use the current value instead). Exception return instructions copy PSTATE.SS from SPSR_ELx.SS only in certain cases when single-step is enabled (and set it to 0 in other cases). So, the value matters only when the guest enables single-step (and when the guest's Software step state isn't affected by single-step enabled by userspace, practically), though. Fix this by preserving the original PSTATE.SS value while userspace enables single-step, and restoring the value once it is disabled. This fix modifies the behavior of GET_ONE_REG/SET_ONE_REG for the PSTATE.SS while single-step is enabled by userspace. Presently, GET_ONE_REG/SET_ONE_REG gets/sets the current PSTATE.SS value, which KVM will override on the next guest entry (i.e. the value userspace gets/sets is not used for the next guest entry). With this patch, GET_ONE_REG/SET_ONE_REG will get/set the guest's preserved value, which KVM will preserve and try to restore after single-step is disabled. Fixes: 337b99bf ("KVM: arm64: guest debug, add support for single-step") Signed-off-by:
-
Marc Zyngier authored
Merge arm64/for-next/sysreg in order to avoid upstream conflicts due to the never ending sysreg repainting... Signed-off-by:
-
- 16 Sep, 2022 7 commits
-
-
Mark Brown authored
Convert ID_AA64AFRn_EL1 to automatic generation as per DDI0487I.a, no functional changes. Signed-off-by:
Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20220910163354.860255-7-broonie@kernel.orgSigned-off-by:
Catalin Marinas <catalin.marinas@arm.com>
-
Mark Brown authored
Convert ID_AA64FDR1_EL1 to automatic generation as per DDI0487I.a, no functional changes. Signed-off-by:
-
Mark Brown authored
Convert ID_AA64DFR0_EL1 to automatic generation as per DDI0487I.a, no functional changes. Signed-off-by:
-
Mark Brown authored
Currently the kernel refers to the versions of the PMU and SPE features by the version of the architecture where those features were updated but the ARM refers to them using the FEAT_ names for the features. To improve consistency and help with updating for newer features and since v9 will make our current naming scheme a bit more confusing update the macros identfying features to use the FEAT_ based scheme. Signed-off-by:
-
Mark Brown authored
Normally we include the full register name in the defines for fields within registers but this has not been followed for ID registers. In preparation for automatic generation of defines add the _EL1s into the defines for ID_AA64DFR0_EL1 to follow the convention. No functional changes. Signed-off-by:
-
Mark Brown authored
The naming scheme the architecture uses for the fields in ID_AA64DFR0_EL1 does not align well with kernel conventions, using as it does a lot of MixedCase in various arrangements. In preparation for automatically generating the defines for this register rename the defines used to match what is in the architecture. Signed-off-by:
-
Marc Zyngier authored
* kvm-arm64/aarch32-raz-idregs: : . : Rework AArch32 ID registers exposed by KVM on AArch64-only : systems by treating them as RAZ/WI instead as UNKOWN as : architected, which allows them to be trivially migrated : between different systems. : : Patches courtesy of Oliver Upton. : . KVM: selftests: Add test for AArch32 ID registers KVM: arm64: Treat 32bit ID registers as RAZ/WI on 64bit-only system KVM: arm64: Add a visibility bit to ignore user writes KVM: arm64: Spin off helper for calling visibility hook KVM: arm64: Drop raz parameter from read_id_reg() KVM: arm64: Remove internal accessor helpers for id regs KVM: arm64: Use visibility hook to treat ID regs as RAZ Signed-off-by:
-
- 14 Sep, 2022 7 commits
-
-
Oliver Upton authored
Add a test to assert that KVM handles the AArch64 views of the AArch32 ID registers as RAZ/WI (writable only from userspace). For registers that were already hidden or unallocated, expect RAZ + invariant behavior. Signed-off-by:
-
Oliver Upton authored
One of the oddities of the architecture is that the AArch64 views of the AArch32 ID registers are UNKNOWN if AArch32 isn't implemented at any EL. Nonetheless, KVM exposes these registers to userspace for the sake of save/restore. It is possible that the UNKNOWN value could differ between systems, leading to a rejected write from userspace. Avoid the issue altogether by handling the AArch32 ID registers as RAZ/WI when on an AArch64-only system. Signed-off-by:
-
Oliver Upton authored
We're about to ignore writes to AArch32 ID registers on AArch64-only systems. Add a bit to indicate a register is handled as write ignore when accessed from userspace. Signed-off-by:
-
Oliver Upton authored
No functional change intended. Reviewed-by:
-
Oliver Upton authored
There is no longer a need for caller-specified RAZ visibility. Hoist the call to sysreg_visible_as_raz() into read_id_reg() and drop the parameter. No functional change intended. Suggested-by:
-
Oliver Upton authored
The internal accessors are only ever called once. Dump out their contents in the caller. No functional change intended. Signed-off-by:
-
Oliver Upton authored
The generic id reg accessors already handle RAZ registers by way of the visibility hook. Add a visibility hook that returns REG_RAZ unconditionally and throw out the RAZ specific accessors. Reviewed-by:
-
- 09 Sep, 2022 6 commits
-
-
Mark Brown authored
The FEAT_NMI extension adds a new system register ALLINT for controlling NMI related interrupt masking, add a definition of this register as per DDI0487H.a. Signed-off-by:
Kristina Martsenko <kristina.martsenko@arm.com> Link: https://lore.kernel.org/r/20220905225425.1871461-29-broonie@kernel.orgSigned-off-by:
-
Mark Brown authored
Convert SCXTNUM_EL1 to automatic generation as per DDI0487H.a, no functional changes. Signed-off-by:
-
Mark Brown authored
Convert TPIDR_EL1 to automatic generation as per DDI0487H.a, no functional changes. Signed-off-by:
-
Mark Brown authored
Convert ID_AA64PFR1_EL1 to be automatically generated as per DDI04187H.a, no functional changes. Signed-off-by:
-
Mark Brown authored
Automatically generate the constants for ID_AA64PFR0_EL1 as per DDI0487I.a, no functional changes. The generic defines for the ELx fields are left in place as they remain useful. Signed-off-by:
-
Mark Brown authored
Convert ID_AA64MMFR2_EL1 defines to automatic generation as per DDI0487H.a, no functional changes. Signed-off-by:
-
