- 08 Feb, 2022 36 commits
-
-
Marc Zyngier authored
* kvm-arm64/pmu-bl: : . : Improve PMU support on heterogeneous systems, courtesy of Alexandru Elisei : . KVM: arm64: Refuse to run VCPU if the PMU doesn't match the physical CPU KVM: arm64: Add KVM_ARM_VCPU_PMU_V3_SET_PMU attribute KVM: arm64: Keep a list of probed PMUs KVM: arm64: Keep a per-VM pointer to the default PMU perf: Fix wrong name in comment for struct perf_cpu_context KVM: arm64: Do not change the PMU event filter after a VCPU has run Signed-off-by:Marc Zyngier <maz@kernel.org>
-
Alexandru Elisei authored
Userspace can assign a PMU to a VCPU with the KVM_ARM_VCPU_PMU_V3_SET_PMU device ioctl. If the VCPU is scheduled on a physical CPU which has a different PMU, the perf events needed to emulate a guest PMU won't be scheduled in and the guest performance counters will stop counting. Treat it as an userspace error and refuse to run the VCPU in this situation. Suggested-by:
Alexandru Elisei <alexandru.elisei@arm.com> Signed-off-by:
-
Alexandru Elisei authored
When KVM creates an event and there are more than one PMUs present on the system, perf_init_event() will go through the list of available PMUs and will choose the first one that can create the event. The order of the PMUs in this list depends on the probe order, which can change under various circumstances, for example if the order of the PMU nodes change in the DTB or if asynchronous driver probing is enabled on the kernel command line (with the driver_async_probe=armv8-pmu option). Another consequence of this approach is that on heteregeneous systems all virtual machines that KVM creates will use the same PMU. This might cause unexpected behaviour for userspace: when a VCPU is executing on the physical CPU that uses this default PMU, PMU events in the guest work correctly; but when the same VCPU executes on another CPU, PMU events in the guest will suddenly stop counting. Fortunately, perf core allows user to specify on which PMU to create an event by using the perf_event_attr->type field, which is used by perf_init_event() as an index in the radix tree of available PMUs. Add the KVM_ARM_VCPU_PMU_V3_CTRL(KVM_ARM_VCPU_PMU_V3_SET_PMU) VCPU attribute to allow userspace to specify the arm_pmu that KVM will use when creating events for that VCPU. KVM will make no attempt to run the VCPU on the physical CPUs that share the PMU, leaving it up to userspace to manage the VCPU threads' affinity accordingly. To ensure that KVM doesn't expose an asymmetric system to the guest, the PMU set for one VCPU will be used by all other VCPUs. Once a VCPU has run, the PMU cannot be changed in order to avoid changing the list of available events for a VCPU, or to change the semantics of existing events. Signed-off-by:
-
Alexandru Elisei authored
The ARM PMU driver calls kvm_host_pmu_init() after probing to tell KVM that a hardware PMU is available for guest emulation. Heterogeneous systems can have more than one PMU present, and the callback gets called multiple times, once for each of them. Keep track of all the PMUs available to KVM, as they're going to be needed later. Reviewed-by:
Reiji Watanabe <reijiw@google.com> Signed-off-by:
-
Marc Zyngier authored
As we are about to allow selection of the PMU exposed to a guest, start by keeping track of the default one instead of only the PMU version. Signed-off-by:
-
Alexandru Elisei authored
Commit 0793a61d ("performance counters: core code") added the perf subsystem (then called Performance Counters) to Linux, creating the struct perf_cpu_context. The comment for the struct referred to it as a "struct perf_counter_cpu_context". Commit cdd6c482 ("perf: Do the big rename: Performance Counters -> Performance Events") changed the comment to refer to a "struct perf_event_cpu_context", which was still the wrong name for the struct. Change the comment to say "struct perf_cpu_context". CC: Thomas Gleixner <tglx@linutronix.de> CC: Ingo Molnar <mingo@redhat.com> Signed-off-by:
-
Marc Zyngier authored
Userspace can specify which events a guest is allowed to use with the KVM_ARM_VCPU_PMU_V3_FILTER attribute. The list of allowed events can be identified by a guest from reading the PMCEID{0,1}_EL0 registers. Changing the PMU event filter after a VCPU has run can cause reads of the registers performed before the filter is changed to return different values than reads performed with the new event filter in place. The architecture defines the two registers as read-only, and this behaviour contradicts that. Keep track when the first VCPU has run and deny changes to the PMU event filter to prevent this from happening. Signed-off-by: -
Marc Zyngier authored
* kvm-arm64/misc-5.18: : . : Misc fixes for KVM/arm64 5.18: : : - Drop unused kvm parameter to kvm_psci_version() : : - Implement CONFIG_DEBUG_LIST at EL2 : . KVM: arm64: pkvm: Implement CONFIG_DEBUG_LIST at EL2 KVM: arm64: Drop unused param from kvm_psci_version() Signed-off-by: -
Keir Fraser authored
Currently the check functions are stubbed out at EL2. Implement versions suitable for the constrained EL2 environment. Signed-off-by:
Keir Fraser <keirf@google.com> Signed-off-by:
-
Oliver Upton authored
kvm_psci_version() consumes a pointer to struct kvm in addition to a vcpu pointer. Drop the kvm pointer as it is unused. While the comment suggests the explicit kvm pointer was useful for calling from hyp, there exist no such callsite in hyp. Signed-off-by:
Oliver Upton <oupton@google.com> Signed-off-by:
-
Marc Zyngier authored
* kvm-arm64/selftest/vgic-5.18: : . : A bunch of selftest fixes, courtesy of Ricardo Koller : . kvm: selftests: aarch64: use a tighter assert in vgic_poke_irq() kvm: selftests: aarch64: fix some vgic related comments kvm: selftests: aarch64: fix the failure check in kvm_set_gsi_routing_irqchip_check kvm: selftests: aarch64: pass vgic_irq guest args as a pointer kvm: selftests: aarch64: fix assert in gicv3_access_reg Signed-off-by: -
Ricardo Koller authored
vgic_poke_irq() checks that the attr argument passed to the vgic device ioctl is sane. Make this check tighter by moving it to after the last attr update. Signed-off-by:
Ricardo Koller <ricarkol@google.com> Reported-by:
Andrew Jones <drjones@redhat.com> Signed-off-by:
-
Ricardo Koller authored
Fix the formatting of some comments and the wording of one of them (in gicv3_access_reg). Signed-off-by:
-
Ricardo Koller authored
kvm_set_gsi_routing_irqchip_check(expect_failure=true) is used to check the error code returned by the kernel when trying to setup an invalid gsi routing table. The ioctl fails if "pin >= KVM_IRQCHIP_NUM_PINS", so kvm_set_gsi_routing_irqchip_check() should test the error only when "intid >= KVM_IRQCHIP_NUM_PINS+32". The issue is that the test check is "intid >= KVM_IRQCHIP_NUM_PINS", so for a case like "intid = KVM_IRQCHIP_NUM_PINS" the test wrongly assumes that the kernel will return an error. Fix this by using the right check. Signed-off-by:
-
Ricardo Koller authored
The guest in vgic_irq gets its arguments in a struct. This struct used to fit nicely in a single register so vcpu_args_set() was able to pass it by value by setting x0 with it. Unfortunately, this args struct grew after some commits and some guest args became random (specically kvm_supports_irqfd). Fix this by passing the guest args as a pointer (after allocating some guest memory for it). Signed-off-by:
-
Ricardo Koller authored
The val argument in gicv3_access_reg can have any value when used for a read, not necessarily 0. Fix the assert by checking val only for writes. Signed-off-by:
-
Marc Zyngier authored
* kvm-arm64/vmid-allocator: : . : VMID allocation rewrite from Shameerali Kolothum Thodi, paving the : way for pinned VMIDs and SVA. : . KVM: arm64: Make active_vmids invalid on vCPU schedule out KVM: arm64: Align the VMID allocation with the arm64 ASID KVM: arm64: Make VMID bits accessible outside of allocator KVM: arm64: Introduce a new VMID allocator for KVM Signed-off-by: -
Shameer Kolothum authored
Like ASID allocator, we copy the active_vmids into the reserved_vmids on a rollover. But it's unlikely that every CPU will have a vCPU as current task and we may end up unnecessarily reserving the VMID space. Hence, set active_vmids to an invalid one when scheduling out a vCPU. Signed-off-by:
Shameer Kolothum <shameerali.kolothum.thodi@huawei.com> Signed-off-by:
-
Julien Grall authored
At the moment, the VMID algorithm will send an SGI to all the CPUs to force an exit and then broadcast a full TLB flush and I-Cache invalidation. This patch uses the new VMID allocator. The benefits are: - Aligns with arm64 ASID algorithm. - CPUs are not forced to exit at roll-over. Instead, the VMID will be marked reserved and context invalidation is broadcasted. This will reduce the IPIs traffic. - More flexible to add support for pinned KVM VMIDs in the future. With the new algo, the code is now adapted: - The call to update_vmid() will be done with preemption disabled as the new algo requires to store information per-CPU. Signed-off-by:Julien Grall <julien.grall@arm.com> Signed-off-by:
-
Shameer Kolothum authored
Since we already set the kvm_arm_vmid_bits in the VMID allocator init function, make it accessible outside as well so that it can be used in the subsequent patch. Suggested-by:
Will Deacon <will@kernel.org> Signed-off-by:
-
Shameer Kolothum authored
A new VMID allocator for arm64 KVM use. This is based on arm64 ASID allocator algorithm. One major deviation from the ASID allocator is the way we flush the context. Unlike ASID allocator, we expect less frequent rollover in the case of VMIDs. Hence, instead of marking the CPU as flush_pending and issuing a local context invalidation on the next context switch, we broadcast TLB flush + I-cache invalidation over the inner shareable domain on rollover. Signed-off-by:
-
Marc Zyngier authored
* kvm-arm64/fpsimd-doc: : . : FPSIMD documentation update, courtesy of Mark Brown : . arm64/fpsimd: Clarify the purpose of using last in fpsimd_save() KVM: arm64: Add some more comments in kvm_hyp_handle_fpsimd() KVM: arm64: Add comments for context flush and sync callbacks Signed-off-by: -
Mark Brown authored
When saving the floating point context in fpsimd_save() we always reference the state using last-> rather than using current->. Looking at the FP code in isolation the reason for this is not entirely obvious, it's done because when KVM is running it will bind the guest context and rely on the host writing out the guest state on context switch away from the guest. There's a slight trick here in that KVM still uses TIF_FOREIGN_FPSTATE and TIF_SVE to communicate what needs to be saved, it maintains those flags and restores them when it is done running the guest so that the normal restore paths function when we return back to userspace. Add a comment to explain this to help future readers work out what's going on a bit faster. Signed-off-by:
Mark Brown <broonie@kernel.org> Reviewed-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
-
Mark Brown authored
The handling for FPSIMD/SVE traps is multi stage and involves some trap manipulation which isn't quite so immediately obvious as might be desired so add a few more comments. Signed-off-by:
-
Mark Brown authored
Add a little bit of information on where _ctxflush_fp() and _ctxsync_fp() are called to help people unfamiliar with the code get up to speed. Signed-off-by:
-
Marc Zyngier authored
* kvm-arm64/mmu-rwlock: : . : MMU locking optimisations from Jing Zhang, allowing permission : relaxations to occur in parallel. : . KVM: selftests: Add vgic initialization for dirty log perf test for ARM KVM: arm64: Add fast path to handle permission relaxation during dirty logging KVM: arm64: Use read/write spin lock for MMU protection Signed-off-by: -
Jing Zhang authored
For ARM64, if no vgic is setup before the dirty log perf test, the userspace irqchip would be used, which would affect the dirty log perf test result. Signed-off-by:
Jing Zhang <jingzhangos@google.com> Tested-by:
Fuad Tabba <tabba@google.com> Reviewed-by:
-
Jing Zhang authored
To reduce MMU lock contention during dirty logging, all permission relaxation operations would be performed under read lock. Signed-off-by:
-
Jing Zhang authored
Replace MMU spinlock with rwlock and update all instances of the lock being acquired with a write lock acquisition. Future commit will add a fast path for permission relaxation during dirty logging under a read lock. Signed-off-by:
-
Marc Zyngier authored
* kvm-arm64/oslock: : . : Debug OS-Lock emulation courtesy of Oliver Upton. From the cover letter: : : "KVM does not implement the debug architecture to the letter of the : specification. One such issue is the fact that KVM treats the OS Lock as : RAZ/WI, rather than emulating its behavior on hardware. This series adds : emulation support for the OS Lock to KVM. Emulation is warranted as the : OS Lock affects debug exceptions taken from all ELs, and is not limited : to only the context of the guest." : . selftests: KVM: Test OS lock behavior selftests: KVM: Add OSLSR_EL1 to the list of blessed regs KVM: arm64: Emulate the OS Lock KVM: arm64: Allow guest to set the OSLK bit KVM: arm64: Stash OSLSR_EL1 in the cpu context KVM: arm64: Correctly treat writes to OSLSR_EL1 as undefined Signed-off-by: -
Oliver Upton authored
KVM now correctly handles the OS Lock for its guests. When set, KVM blocks all debug exceptions originating from the guest. Add test cases to the debug-exceptions test to assert that software breakpoint, hardware breakpoint, watchpoint, and single-step exceptions are in fact blocked. Signed-off-by:
-
Oliver Upton authored
OSLSR_EL1 is now part of the visible system register state. Add it to the get-reg-list selftest to ensure we keep it that way. Signed-off-by:
-
Oliver Upton authored
The OS lock blocks all debug exceptions at every EL. To date, KVM has not implemented the OS lock for its guests, despite the fact that it is mandatory per the architecture. Simple context switching between the guest and host is not appropriate, as its effects are not constrained to the guest context. Emulate the OS Lock by clearing MDE and SS in MDSCR_EL1, thereby blocking all but software breakpoint instructions. Signed-off-by:
-
Oliver Upton authored
Allow writes to OSLAR and forward the OSLK bit to OSLSR. Do nothing with the value for now. Reviewed-by:
-
Oliver Upton authored
An upcoming change to KVM will emulate the OS Lock from the PoV of the guest. Add OSLSR_EL1 to the cpu context and handle reads using the stored value. Define some mnemonics for for handling the OSLM field and use them to make the reset value of OSLSR_EL1 more readable. Wire up a custom handler for writes from userspace and prevent any of the invariant bits from changing. Note that the OSLK bit is not invariant and will be made writable by the aforementioned change. Reviewed-by:
-
Oliver Upton authored
Writes to OSLSR_EL1 are UNDEFINED and should never trap from EL1 to EL2, but the kvm trap handler for OSLSR_EL1 handles writes via ignore_write(). This is confusing to readers of code, but should have no functional impact. For clarity, use write_to_read_only() rather than ignore_write(). If a trap is unexpectedly taken to EL2 in violation of the architecture, this will WARN_ONCE() and inject an undef into the guest. Reviewed-by:
Mark Rutland <mark.rutland@arm.com> [adopted Mark's changelog suggestion, thanks!] Signed-off-by:
-
- 06 Feb, 2022 4 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4Linus Torvalds authored
Pull ext4 fixes from Ted Ts'o: "Various bug fixes for ext4 fast commit and inline data handling. Also fix regression introduced as part of moving to the new mount API" * tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4: fs/ext4: fix comments mentioning i_mutex ext4: fix incorrect type issue during replay_del_range jbd2: fix kernel-doc descriptions for jbd2_journal_shrink_{scan,count}() ext4: fix potential NULL pointer dereference in ext4_fill_super() jbd2: refactor wait logic for transaction updates into a common function jbd2: cleanup unused functions declarations from jbd2.h ext4: fix error handling in ext4_fc_record_modified_inode() ext4: remove redundant max inline_size check in ext4_da_write_inline_data_begin() ext4: fix error handling in ext4_restore_inline_data() ext4: fast commit may miss file actions ext4: fast commit may not fallback for ineligible commit ext4: modify the logic of ext4_mb_new_blocks_simple ext4: prevent used blocks from being allocated during fast commit replay
-
Linus Torvalds authored
Merge tag 'perf-tools-fixes-for-v5.17-2022-02-06' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux Pull perf tools fixes from Arnaldo Carvalho de Melo: - Fix display of grouped aliased events in 'perf stat'. - Add missing branch_sample_type to perf_event_attr__fprintf(). - Apply correct label to user/kernel symbols in branch mode. - Fix 'perf ftrace' system_wide tracing, it has to be set before creating the maps. - Return error if procfs isn't mounted for PID namespaces when synthesizing records for pre-existing processes. - Set error stream of objdump process for 'perf annotate' TUI, to avoid garbling the screen. - Add missing arm64 support to perf_mmap__read_self(), the kernel part got into 5.17. - Check for NULL pointer before dereference writing debug info about a sample. - Update UAPI copies for asound, perf_event, prctl and kvm headers. - Fix a typo in bpf_counter_cgroup.c. * tag 'perf-tools-fixes-for-v5.17-2022-02-06' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux: perf ftrace: system_wide collection is not effective by default libperf: Add arm64 support to perf_mmap__read_self() tools include UAPI: Sync sound/asound.h copy with the kernel sources perf stat: Fix display of grouped aliased events perf tools: Apply correct label to user/kernel symbols in branch mode perf bpf: Fix a typo in bpf_counter_cgroup.c perf synthetic-events: Return error if procfs isn't mounted for PID namespaces perf session: Check for NULL pointer before dereference perf annotate: Set error stream of objdump process for TUI perf tools: Add missing branch_sample_type to perf_event_attr__fprintf() tools headers UAPI: Sync linux/kvm.h with the kernel sources tools headers UAPI: Sync linux/prctl.h with the kernel sources perf beauty: Make the prctl arg regexp more strict to cope with PR_SET_VMA tools headers cpufeatures: Sync with the kernel sources tools headers UAPI: Sync linux/perf_event.h with the kernel sources tools include UAPI: Sync sound/asound.h copy with the kernel sources
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull perf fixes from Borislav Petkov: - Intel/PT: filters could crash the kernel - Intel: default disable the PMU for SMM, some new-ish EFI firmware has started using CPL3 and the PMU CPL filters don't discriminate against SMM, meaning that CPL3 (userspace only) events now also count EFI/SMM cycles. - Fixup for perf_event_attr::sig_data * tag 'perf_urgent_for_v5.17_rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf/x86/intel/pt: Fix crash with stop filters in single-range mode perf: uapi: Document perf_event_attr::sig_data truncation on 32 bit architectures selftests/perf_events: Test modification of perf_event_attr::sig_data perf: Copy perf_event_attr::sig_data on modification x86/perf: Default set FREEZE_ON_SMI for all
-
