Select Git revision
Search by author
- Any Author
- authors
-
72162444 72162444 gaochangning
-
Aakash Dave aakash.dave
-
Aaron Kim akim
-
Aaron Kloc akloc
-
Aaron Lan aaron.lan
-
Aaron Nabil aaronna
-
Aaron Pohle aaron.pohle
-
Abbott Chung chung.abbott
-
Abdallah Omar abdallah_omar
-
Abdessamii Chalbi abdessamii.chalbi
-
Abdul Hussain Sirajudeen abdul.hussain
-
Abdullah Alghamdi a.alghamdi
-
Abdullah Elmarghany abdullah_elmarghany
-
Abel Fang abel_fang
-
Abhijeet Badurkar abhijeet.badurkar
-
Abhijit Adsule adsule
-
Abhijit Murthy abhijit
-
Abhi Khanal akhanal
-
Abhilash Sahoo abhilashsahoo
-
Abhimanyu Raj abhimanyu.raj
- Oct 25, 2022
-
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit 62ed93d1 Author: Arnaldo Carvalho de Melo <acme@redhat.com> Date: Thu Jul 1 13:39:15 2021 -0300 tools headers cpufeatures: Sync with the kernel sources To pick the changes from: 2b129932 ("x86/speculation: Add RSB VM Exit protections") 28a99e95 ("x86/amd: Use IBPB for firmware calls") 4ad3278d ("x86/speculation: Disable RRSBA behavior") 26aae8cc ("x86/cpu/amd: Enumerate BTC_NO") 9756bba2 ("x86/speculation: Fill RSB on vmexit for IBRS") 3ebc1700 ("x86/bugs: Add retbleed=ibpb") 2dbb887e ("x86/entry: Add kernel IBRS implementation") 6b80b59b ("x86/bugs: Report AMD retbleed vulnerability") a149180f ("x86: Add magic AMD return-thunk") 15e67227 ("x86: Undo return-thunk damage") a883d624 ("x86/cpufeatures: Move RETPOLINE flags to word 11") aae99a7c ("x86/cpufeatures: Introduce x2AVIC CPUID bit") 6f33a9da ("x86: Fix comment for X86_FEATURE_ZEN") 51802186 ("x86/speculation/mmio: Enumerate Processor MMIO Stale Data bug") This only causes these perf files to be rebuilt: CC /tmp/build/perf/bench/mem-memcpy-x86-64-asm.o CC /tmp/build/perf/bench/mem-memset-x86-64-asm.o And addresses this perf build warning: Warning: Kernel ABI header at 'tools/arch/x86/include/asm/cpufeatures.h' differs from latest version at 'arch/x86/include/asm/cpufeatures.h' diff -u tools/arch/x86/include/asm/cpufeatures.h arch/x86/include/asm/cpufeatures.h Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Alexandre Chartre <alexandre.chartre@oracle.com> Cc: Andrew Cooper <andrew.cooper3@citrix.com> Cc: Borislav Petkov <bp@suse.de> Cc: Daniel Sneddon <daniel.sneddon@linux.intel.com> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: Ian Rogers <irogers@google.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Josh Poimboeuf <jpoimboe@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> Cc: Wyes Karny <wyes.karny@amd.com> Link: https://lore.kernel.org/lkml/Yvznmu5oHv0ZDN2w@kernel.org Signed-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
Vitaly Kuznetsov <vkuznets@redhat.com>
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit eea085d1 Author: Arnaldo Carvalho de Melo <acme@redhat.com> Date: Tue Mar 2 17:20:08 2021 -0300 tools headers UAPI: Sync KVM's vmx.h header with the kernel sources To pick the changes in: 2f4073e0 ("KVM: VMX: Enable Notify VM exit") That makes 'perf kvm-stat' aware of this new NOTIFY exit reason, thus addressing the following perf build warning: Warning: Kernel ABI header at 'tools/arch/x86/include/uapi/asm/vmx.h' differs from latest version at 'arch/x86/include/uapi/asm/vmx.h' diff -u tools/arch/x86/include/uapi/asm/vmx.h arch/x86/include/uapi/asm/vmx.h Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Ian Rogers <irogers@google.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Tao Xu <tao3.xu@intel.com> Link: http://lore.kernel.org/lkml/Yv6LavXMZ+njijpq@kernel.org Signed-off-by:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit 4b3f7644 Author: Arnaldo Carvalho de Melo <acme@redhat.com> Date: Thu Jul 1 13:39:15 2021 -0300 tools headers cpufeatures: Sync with the kernel sources To pick the changes from: d6d0c7f6 ("x86/cpufeatures: Add PerfMonV2 feature bit") 296d5a17 ("KVM: SEV-ES: Use V_TSC_AUX if available instead of RDTSC/MSR_TSC_AUX intercepts") f3090339 ("x86/cpufeatures: Add virtual TSC_AUX feature bit") 8ad7e8f6 ("x86/fpu/xsave: Support XSAVEC in the kernel") 59bd54a8 ("x86/tdx: Detect running as a TDX guest in early boot") a77d41ac ("x86/cpufeatures: Add AMD Fam19h Branch Sampling feature") This only causes these perf files to be rebuilt: CC /tmp/build/perf/bench/mem-memcpy-x86-64-asm.o CC /tmp/build/perf/bench/mem-memset-x86-64-asm.o And addresses this perf build warning: Warning: Kernel ABI header at 'tools/arch/x86/include/asm/cpufeatures.h' differs from latest version at 'arch/x86/include/asm/cpufeatures.h' diff -u tools/arch/x86/include/asm/cpufeatures.h arch/x86/include/asm/cpufeatures.h Warning: Kernel ABI header at 'tools/arch/x86/include/asm/disabled-features.h' differs from latest version at 'arch/x86/include/asm/disabled-features.h' diff -u tools/arch/x86/include/asm/disabled-features.h arch/x86/include/asm/disabled-features.h Cc: Peter Zijlstra <peterz@infradead.org> Cc: Sandipan Das <sandipan.das@amd.com> Cc: Babu Moger <babu.moger@amd.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Cc: Stephane Eranian <eranian@google.com> Cc: Peter Zijlstra <peterz@infradead.org> Link: https://lore.kernel.org/lkml/YrDkgmwhLv+nKeOo@kernel.org Signed-off-by:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit 37b2a651 Author: Paolo Bonzini <pbonzini@redhat.com> Date: Tue Mar 8 04:49:37 2022 -0500 KVM: use __vcalloc for very large allocations Allocations whose size is related to the memslot size can be arbitrarily large. Do not use kvzalloc/kvcalloc, as those are limited to "not crazy" sizes that fit in 32 bits. Cc: stable@vger.kernel.org Fixes: 7661809d ("mm: don't allow oversized kvmalloc() calls") Reviewed-by:
David Hildenbrand <david@redhat.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> RHEL-only: Upstream commit 37b2a651 ("KVM: use __vcalloc for very large allocations") was previously backported without the hunk which goes to kvm_page_track_write_tracking_alloc(). Signed-off-by:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit 3d9606b0 Author: Josh Poimboeuf <jpoimboe@kernel.org> Date: Thu Aug 18 08:53:43 2022 -0700 x86/kvm: Fix "missing ENDBR" BUG for fastop functions The following BUG was reported: traps: Missing ENDBR: andw_ax_dx+0x0/0x10 [kvm] ------------[ cut here ]------------ kernel BUG at arch/x86/kernel/traps.c:253! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI <TASK> asm_exc_control_protection+0x2b/0x30 RIP: 0010:andw_ax_dx+0x0/0x10 [kvm] Code: c3 cc cc cc cc 0f 1f 44 00 00 66 0f 1f 00 48 19 d0 c3 cc cc cc cc 0f 1f 40 00 f3 0f 1e fa 20 d0 c3 cc cc cc cc 0f 1f 44 00 00 <66> 0f 1f 00 66 21 d0 c3 cc cc cc cc 0f 1f 40 00 66 0f 1f 00 21 d0 ? andb_al_dl+0x10/0x10 [kvm] ? fastop+0x5d/0xa0 [kvm] x86_emulate_insn+0x822/0x1060 [kvm] x86_emulate_instruction+0x46f/0x750 [kvm] complete_emulated_mmio+0x216/0x2c0 [kvm] kvm_arch_vcpu_ioctl_run+0x604/0x650 [kvm] kvm_vcpu_ioctl+0x2f4/0x6b0 [kvm] ? wake_up_q+0xa0/0xa0 The BUG occurred because the ENDBR in the andw_ax_dx() fastop function had been incorrectly "sealed" (converted to a NOP) by apply_ibt_endbr(). Objtool marked it to be sealed because KVM has no compile-time references to the function. Instead KVM calculates its address at runtime. Prevent objtool from annotating fastop functions as sealable by creating throwaway dummy compile-time references to the functions. Fixes: 6649fa87 ("x86/ibt,kvm: Add ENDBR to fastops") Reported-by:
Pengfei Xu <pengfei.xu@intel.com> Debugged-by:
Peter Zijlstra <peterz@infradead.org> Signed-off-by:
Josh Poimboeuf <jpoimboe@kernel.org> Message-Id: <0d4116f90e9d0c1b754bb90c585e6f0415a1c508.1660837839.git.jpoimboe@kernel.org> Signed-off-by:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit e27e5bea Author: Josh Poimboeuf <jpoimboe@kernel.org> Date: Thu Aug 18 14:39:27 2022 -0700 x86/ibt, objtool: Add IBT_NOSEAL() Add a macro which prevents a function from getting sealed if there are no compile-time references to it. Signed-off-by:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit e5bc0dea Author: Arnaldo Carvalho de Melo <acme@redhat.com> Date: Fri Sep 10 11:46:54 2021 -0300 tools headers UAPI: Sync x86's asm/kvm.h with the kernel sources To pick the changes in: 43bb9e00 ("KVM: x86: Tweak name of MONITOR/MWAIT #UD quirk to make it #UD specific") 94dfc73e ("treewide: uapi: Replace zero-length arrays with flexible-array members") bfbcc81b ("KVM: x86: Add a quirk for KVM's "MONITOR/MWAIT are NOPs!" behavior") b1728622 ("KVM: x86: PIT: Preserve state of speaker port data bit") ed235117 ("KVM: x86: Extend KVM_{G,S}ET_VCPU_EVENTS to support pending triple fault") That just rebuilds kvm-stat.c on x86, no change in functionality. This silences these perf build warning: Warning: Kernel ABI header at 'tools/arch/x86/include/uapi/asm/kvm.h' differs from latest version at 'arch/x86/include/uapi/asm/kvm.h' diff -u tools/arch/x86/include/uapi/asm/kvm.h arch/x86/include/uapi/asm/kvm.h Cc: Chenyi Qiang <chenyi.qiang@intel.com> Cc: Sean Christopherson <seanjc@google.com> Cc: Gustavo A. R. Silva <gustavoars@kernel.org> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Paul Durrant <pdurrant@amazon.com> Link: https://lore.kernel.org/lkml/Yv6OMPKYqYSbUxwZ@kernel.org Signed-off-by:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit 87693645 Author: Like Xu <likexu@tencent.com> Date: Wed Aug 31 11:35:24 2022 +0800 perf/x86/core: Completely disable guest PEBS via guest's global_ctrl When a guest PEBS counter is cross-mapped by a host counter, software will remove the corresponding bit in the arr[global_ctrl].guest and expect hardware to perform a change of state "from enable to disable" via the msr_slot[] switch during the vmx transaction. The real world is that if user adjust the counter overflow value small enough, it still opens a tiny race window for the previously PEBS-enabled counter to write cross-mapped PEBS records into the guest's PEBS buffer, when arr[global_ctrl].guest has been prioritised (switch_msr_special stuff) to switch into the enabled state, while the arr[pebs_enable].guest has not. Close this window by clearing invalid bits in the arr[global_ctrl].guest. Cc: linux-perf-users@vger.kernel.org Cc: Kan Liang <kan.liang@linux.intel.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Sean Christopherson <seanjc@google.com> Fixes: 85425032 ("KVM: x86/pmu: Disable guest PEBS temporarily in two rare situations") Signed-off-by:
Like Xu <likexu@tencent.com> Message-Id: <20220831033524.58561-1-likexu@tencent.com> Signed-off-by:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit 7f7f86a7 Author: Arnaldo Carvalho de Melo <acme@redhat.com> Date: Fri Aug 7 08:45:47 2020 -0300 tools arch x86: Sync the msr-index.h copy with the kernel sources To pick up the changes in: 2b129932 ("x86/speculation: Add RSB VM Exit protections") 4af184ee ("tools/power turbostat: dump secondary Turbo-Ratio-Limit") 4ad3278d ("x86/speculation: Disable RRSBA behavior") d7caac99 ("x86/cpu/amd: Add Spectral Chicken") 6ad0ad2b ("x86/bugs: Report Intel retbleed vulnerability") c59a1f10 ("KVM: x86/pmu: Add IA32_PEBS_ENABLE MSR emulation for extended PEBS") 465932db ("x86/cpu: Add new VMX feature, Tertiary VM-Execution control") 027bbb88 ("KVM: x86/speculation: Disable Fill buffer clear within guests") 51802186 ("x86/speculation/mmio: Enumerate Processor MMIO Stale Data bug") Addressing these tools/perf build warnings: diff -u tools/arch/x86/include/asm/msr-index.h arch/x86/include/asm/msr-index.h Warning: Kernel ABI header at 'tools/arch/x86/include/asm/msr-index.h' differs from latest version at 'arch/x86/include/asm/msr-index.h' That makes the beautification scripts to pick some new entries: $ tools/perf/trace/beauty/tracepoints/x86_msr.sh > before $ cp arch/x86/include/asm/msr-index.h tools/arch/x86/include/asm/msr-index.h $ tools/perf/trace/beauty/tracepoints/x86_msr.sh > after $ diff -u before after --- before 2022-08-17 09:05:13.938246475 -0300 +++ after 2022-08-17 09:05:22.221455851 -0300 @@ -161,6 +161,7 @@ [0x0000048f] = "IA32_VMX_TRUE_EXIT_CTLS", [0x00000490] = "IA32_VMX_TRUE_ENTRY_CTLS", [0x00000491] = "IA32_VMX_VMFUNC", + [0x00000492] = "IA32_VMX_PROCBASED_CTLS3", [0x000004c1] = "IA32_PMC0", [0x000004d0] = "IA32_MCG_EXT_CTL", [0x00000560] = "IA32_RTIT_OUTPUT_BASE", @@ -212,6 +213,7 @@ [0x0000064D] = "PLATFORM_ENERGY_STATUS", [0x0000064e] = "PPERF", [0x0000064f] = "PERF_LIMIT_REASONS", + [0x00000650] = "SECONDARY_TURBO_RATIO_LIMIT", [0x00000658] = "PKG_WEIGHTED_CORE_C0_RES", [0x00000659] = "PKG_ANY_CORE_C0_RES", [0x0000065A] = "PKG_ANY_GFXE_C0_RES", $ Now one can trace systemwide asking to see backtraces to where those MSRs are being read/written, see this example with a previous update: # perf trace -e msr:*_msr/max-stack=32/ --filter="msr>=IA32_U_CET && msr<=IA32_INT_SSP_TAB" ^C# If we use -v (verbose mode) we can see what it does behind the scenes: # perf trace -v -e msr:*_msr/max-stack=32/ --filter="msr>=IA32_U_CET && msr<=IA32_INT_SSP_TAB" Using CPUID AuthenticAMD-25-21-0 0x6a0 0x6a8 New filter for msr:read_msr: (msr>=0x6a0 && msr<=0x6a8) && (common_pid != 597499 && common_pid != 3313) 0x6a0 0x6a8 New filter for msr:write_msr: (msr>=0x6a0 && msr<=0x6a8) && (common_pid != 597499 && common_pid != 3313) mmap size 528384B ^C# Example with a frequent msr: # perf trace -v -e msr:*_msr/max-stack=32/ --filter="msr==IA32_SPEC_CTRL" --max-events 2 Using CPUID AuthenticAMD-25-21-0 0x48 New filter for msr:read_msr: (msr==0x48) && (common_pid != 2612129 && common_pid != 3841) 0x48 New filter for msr:write_msr: (msr==0x48) && (common_pid != 2612129 && common_pid != 3841) mmap size 528384B Looking at the vmlinux_path (8 entries long) symsrc__init: build id mismatch for vmlinux. Using /proc/kcore for kernel data Using /proc/kallsyms for symbols 0.000 Timer/2525383 msr:write_msr(msr: IA32_SPEC_CTRL, val: 6) do_trace_write_msr ([kernel.kallsyms]) do_trace_write_msr ([kernel.kallsyms]) __switch_to_xtra ([kernel.kallsyms]) __switch_to ([kernel.kallsyms]) __schedule ([kernel.kallsyms]) schedule ([kernel.kallsyms]) futex_wait_queue_me ([kernel.kallsyms]) futex_wait ([kernel.kallsyms]) do_futex ([kernel.kallsyms]) __x64_sys_futex ([kernel.kallsyms]) do_syscall_64 ([kernel.kallsyms]) entry_SYSCALL_64_after_hwframe ([kernel.kallsyms]) __futex_abstimed_wait_common64 (/usr/lib64/libpthread-2.33.so) 0.030 :0/0 msr:write_msr(msr: IA32_SPEC_CTRL, val: 2) do_trace_write_msr ([kernel.kallsyms]) do_trace_write_msr ([kernel.kallsyms]) __switch_to_xtra ([kernel.kallsyms]) __switch_to ([kernel.kallsyms]) __schedule ([kernel.kallsyms]) schedule_idle ([kernel.kallsyms]) do_idle ([kernel.kallsyms]) cpu_startup_entry ([kernel.kallsyms]) secondary_startup_64_no_verify ([kernel.kallsyms]) # Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Daniel Sneddon <daniel.sneddon@linux.intel.com> Cc: Ian Rogers <irogers@google.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Len Brown <len.brown@intel.com> Cc: Like Xu <like.xu@linux.intel.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Robert Hoo <robert.hu@linux.intel.com> Signed-off-by:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit 334865b2 Author: Nick Desaulniers <ndesaulniers@google.com> Date: Tue Mar 29 13:21:45 2022 -0700 x86/extable: Prefer local labels in .set directives Bernardo reported an error that Nathan bisected down to (x86_64) defconfig+LTO_CLANG_FULL+X86_PMEM_LEGACY. LTO vmlinux.o ld.lld: error: <instantiation>:1:13: redefinition of 'found' .set found, 0 ^ <inline asm>:29:1: while in macro instantiation extable_type_reg reg=%eax, type=(17 | ((0) << 16)) ^ This appears to be another LTO specific issue similar to what was folded into commit 4b5305de ("x86/extable: Extend extable functionality"), where the `.set found, 0` in DEFINE_EXTABLE_TYPE_REG in arch/x86/include/asm/asm.h conflicts with the symbol for the static function `found` in arch/x86/kernel/pmem.c. Assembler .set directive declare symbols with global visibility, so the assembler may not rename such symbols in the event of a conflict. LTO could rename static functions if there was a conflict in C sources, but it cannot see into symbols defined in inline asm. The symbols are also retained in the symbol table, regardless of LTO. Give the symbols .L prefixes making them locally visible, so that they may be renamed for LTO to avoid conflicts, and to drop them from the symbol table regardless of LTO. Fixes: 4b5305de ("x86/extable: Extend extable functionality") Reported-by:
Bernardo Meurer Costa <beme@google.com> Debugged-by:
Nathan Chancellor <nathan@kernel.org> Signed-off-by:
Nick Desaulniers <ndesaulniers@google.com> Signed-off-by:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit 9cdbeec4 Author: Peter Zijlstra <peterz@infradead.org> Date: Tue Jan 11 12:11:14 2022 +0100 x86/entry_32: Fix segment exceptions The LKP robot reported that commit in Fixes: caused a failure. Turns out the ldt_gdt_32 selftest turns into an infinite loop trying to clear the segment. As discovered by Sean, what happens is that PARANOID_EXIT_TO_KERNEL_MODE in the handle_exception_return path overwrites the entry stack data with the task stack data, restoring the "bad" segment value. Instead of having the exception retry the instruction, have it emulate the full instruction. Replace EX_TYPE_POP_ZERO with EX_TYPE_POP_REG which will do the equivalent of: POP %reg; MOV $imm, %reg. In order to encode the segment registers, add them as registers 8-11 for 32-bit. By setting regs->[defg]s the (nested) RESTORE_REGS will pop this value at the end of the exception handler and by increasing regs->sp, it will have skipped the stack slot. This was debugged by Sean Christopherson <seanjc@google.com>. [ bp: Add EX_REG_GS too. ] Fixes: aa93e2ad ("x86/entry_32: Remove .fixup usage") Reported-by:
kernel test robot <oliver.sang@intel.com> Signed-off-by:
Borislav Petkov <bp@suse.de> Link: https://lore.kernel.org/r/Yd1l0gInc4zRcnt/@hirez.programming.kicks-ass.net Signed-off-by:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit 71d7c575 Merge: 5d6c7de6 44187235 Author: Paolo Bonzini <pbonzini@redhat.com> Date: Fri Apr 29 06:38:56 2022 -0400 Merge branch 'kvm-fixes-for-5.18-rc5' into HEAD Fixes for (relatively) old bugs, to be merged in both the -rc and next development trees. The merge reconciles the ABI fixes for KVM_EXIT_SYSTEM_EVENT between 5.18 and commit c24a950e ("KVM, SEV: Add KVM_EXIT_SHUTDOWN metadata for SEV-ES", 2022-04-13). Signed-off-by:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit bf465ca8 Author: Arnaldo Carvalho de Melo <acme@redhat.com> Date: Sun May 9 09:39:02 2021 -0300 tools headers UAPI: Sync linux/kvm.h with the kernel sources To pick the changes in: 8a061562 ("RISC-V: KVM: Add extensible CSR emulation framework") f5ecfee9 ("KVM: s390: resetting the Topology-Change-Report") 450a5639 ("KVM: stats: Fix value for KVM_STATS_UNIT_MAX for boolean stats") 1b870fa5 ("kvm: stats: tell userspace which values are boolean") db1c875e ("KVM: s390: add KVM_S390_ZPCI_OP to manage guest zPCI devices") 94dfc73e ("treewide: uapi: Replace zero-length arrays with flexible-array members") 084cc29f ("KVM: x86/MMU: Allow NX huge pages to be disabled on a per-vm basis") 2f4073e0 ("KVM: VMX: Enable Notify VM exit") ed235117 ("KVM: x86: Extend KVM_{G,S}ET_VCPU_EVENTS to support pending triple fault") e9bf3acb ("KVM: s390: Add KVM_CAP_S390_PROTECTED_DUMP") 8aba0958 ("KVM: s390: Add CPU dump functionality") 0460eb35 ("KVM: s390: Add configuration dump functionality") fe9a93e0 ("KVM: s390: pv: Add query dump information") 35d02493 ("KVM: s390: pv: Add query interface") c24a950e ("KVM, SEV: Add KVM_EXIT_SHUTDOWN metadata for SEV-ES") ffbb61d0 ("KVM: x86: Accept KVM_[GS]ET_TSC_KHZ as a VM ioctl.") 661a20fa ("KVM: x86/xen: Advertise and document KVM_XEN_HVM_CONFIG_EVTCHN_SEND") fde0451b ("KVM: x86/xen: Support per-vCPU event channel upcall via local APIC") 28d1629f ("KVM: x86/xen: Kernel acceleration for XENVER_version") 53639526 ("KVM: x86/xen: handle PV timers oneshot mode") 942c2490 ("KVM: x86/xen: Add KVM_XEN_VCPU_ATTR_TYPE_VCPU_ID") 2fd6df2f ("KVM: x86/xen: intercept EVTCHNOP_send from guests") 35025735 ("KVM: x86/xen: Support direct injection of event channel events") That just rebuilds perf, as these patches add just an ioctl that is S390 specific and may clash with other arches, so are so far being excluded in the harvester script: $ tools/perf/trace/beauty/kvm_ioctl.sh > before $ cp include/uapi/linux/kvm.h tools/include/uapi/linux/kvm.h $ tools/perf/trace/beauty/kvm_ioctl.sh > after $ diff -u before after $ grep 390 tools/perf/trace/beauty/kvm_ioctl.sh egrep -v " ((ARM|PPC|S390)_|[GS]ET_(DEBUGREGS|PIT2|XSAVE|TSC_KHZ)|CREATE_SPAPR_TCE_64)" | \ $ This is also by now used by tools/testing/selftests/kvm/, a simple test build succeeded. This silences this perf build warning: Warning: Kernel ABI header at 'tools/include/uapi/linux/kvm.h' differs from latest version at 'include/uapi/linux/kvm.h' diff -u tools/include/uapi/linux/kvm.h include/uapi/linux/kvm.h Cc: Anup Patel <anup@brainfault.org> Cc: Ben Gardon <bgardon@google.com> Cc: Chenyi Qiang <chenyi.qiang@intel.com> Cc: Christian Borntraeger <borntraeger@linux.ibm.com> Cc: David Woodhouse <dwmw@amazon.co.uk> Cc: Gustavo A. R. Silva <gustavoars@kernel.org> Cc: Janosch Frank <frankja@linux.ibm.com> Cc: João Martins <joao.m.martins@oracle.com> Cc: Matthew Rosato <mjrosato@linux.ibm.com> Cc: Oliver Upton <oupton@google.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Peter Gonda <pgonda@google.com> Cc: Pierre Morel <pmorel@linux.ibm.com> Cc: Tao Xu <tao3.xu@intel.com> Link: https://lore.kernel.org/lkml/YvzuryClcn%2FvA0Gn@kernel.org/ Signed-off-by:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit 7fe718fb Author: Arnaldo Carvalho de Melo <acme@redhat.com> Date: Sun May 9 09:39:02 2021 -0300 tools headers UAPI: Sync linux/kvm.h with the kernel sources To pick the changes in: bfbab445 ("KVM: arm64: Implement PSCI SYSTEM_SUSPEND") 7b33a09d ("KVM: arm64: Add support for userspace to suspend a vCPU") ffbb61d0 ("KVM: x86: Accept KVM_[GS]ET_TSC_KHZ as a VM ioctl.") 661a20fa ("KVM: x86/xen: Advertise and document KVM_XEN_HVM_CONFIG_EVTCHN_SEND") fde0451b ("KVM: x86/xen: Support per-vCPU event channel upcall via local APIC") 28d1629f ("KVM: x86/xen: Kernel acceleration for XENVER_version") 53639526 ("KVM: x86/xen: handle PV timers oneshot mode") 942c2490 ("KVM: x86/xen: Add KVM_XEN_VCPU_ATTR_TYPE_VCPU_ID") 2fd6df2f ("KVM: x86/xen: intercept EVTCHNOP_send from guests") 35025735 ("KVM: x86/xen: Support direct injection of event channel events") That automatically adds support for this new ioctl: $ tools/perf/trace/beauty/kvm_ioctl.sh > before $ cp include/uapi/linux/kvm.h tools/include/uapi/linux/kvm.h $ tools/perf/trace/beauty/kvm_ioctl.sh > after $ diff -u before after --- before 2022-06-28 12:13:07.281150509 -0300 +++ after 2022-06-28 12:13:16.423392896 -0300 @@ -98,6 +98,7 @@ [0xcc] = "GET_SREGS2", [0xcd] = "SET_SREGS2", [0xce] = "GET_STATS_FD", + [0xd0] = "XEN_HVM_EVTCHN_SEND", [0xe0] = "CREATE_DEVICE", [0xe1] = "SET_DEVICE_ATTR", [0xe2] = "GET_DEVICE_ATTR", $ This silences these perf build warning: Warning: Kernel ABI header at 'tools/include/uapi/linux/kvm.h' differs from latest version at 'include/uapi/linux/kvm.h' diff -u tools/include/uapi/linux/kvm.h include/uapi/linux/kvm.h Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Woodhouse <dwmw@amazon.co.uk> Cc: Ian Rogers <irogers@google.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Joao Martins <joao.m.martins@oracle.com> Cc: Marc Zyngier <maz@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Oliver Upton <oupton@google.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Link: http://lore.kernel.org/lkml/Yrs4RE+qfgTaWdAt@kernel.org Signed-off-by:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit 474e76c4 Author: Arnaldo Carvalho de Melo <acme@redhat.com> Date: Sun May 9 09:39:02 2021 -0300 tools headers UAPI: Sync linux/kvm.h with the kernel sources To pick the changes in: d495f942 ("KVM: fix bad user ABI for KVM_EXIT_SYSTEM_EVENT") That just rebuilds perf, as these patches don't add any new KVM ioctl to be harvested for the the 'perf trace' ioctl syscall argument beautifiers. This is also by now used by tools/testing/selftests/kvm/, a simple test build succeeded. This silences this perf build warning: Warning: Kernel ABI header at 'tools/include/uapi/linux/kvm.h' differs from latest version at 'include/uapi/linux/kvm.h' diff -u tools/include/uapi/linux/kvm.h include/uapi/linux/kvm.h Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Paolo Bonzini <pbonzini@redhat.com> Link: http://lore.kernel.org/lkml/YnE5BIweGmCkpOTN@kernel.org Signed-off-by:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit 2e323f36 Author: Arnaldo Carvalho de Melo <acme@redhat.com> Date: Fri Sep 10 11:46:54 2021 -0300 tools headers UAPI: Sync x86's asm/kvm.h with the kernel sources To pick the changes in: f1a9761f ("KVM: x86: Allow userspace to opt out of hypercall patching") That just rebuilds kvm-stat.c on x86, no change in functionality. This silences these perf build warning: Warning: Kernel ABI header at 'tools/arch/x86/include/uapi/asm/kvm.h' differs from latest version at 'arch/x86/include/uapi/asm/kvm.h' diff -u tools/arch/x86/include/uapi/asm/kvm.h arch/x86/include/uapi/asm/kvm.h Cc: Oliver Upton <oupton@google.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Link: https://lore.kernel.org/lkml/Yq8qgiMwRcl9ds+f@kernel.org Signed-off-by:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit 22472d12 Author: Josh Poimboeuf <jpoimboe@kernel.org> Date: Thu Aug 18 08:53:42 2022 -0700 x86/kvm: Simplify FOP_SETCC() SETCC_ALIGN and FOP_ALIGN are both 16. Remove the special casing for FOP_SETCC() and just make it a normal fastop. Signed-off-by:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit 22c6a0ef Author: Paolo Bonzini <pbonzini@redhat.com> Date: Thu Aug 11 12:41:25 2022 -0400 KVM: x86: check validity of argument to KVM_SET_MP_STATE An invalid argument to KVM_SET_MP_STATE has no effect other than making the vCPU fail to run at the next KVM_RUN. Since it is extremely unlikely that any userspace is relying on it, fail with -EINVAL just like for other architectures. Signed-off-by:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit 3c0ba05c Author: Miaohe Lin <linmiaohe@huawei.com> Date: Thu Sep 1 20:23:00 2022 +0800 KVM: x86: fix memoryleak in kvm_arch_vcpu_create() When allocating memory for mci_ctl2_banks fails, KVM doesn't release mce_banks leading to memoryleak. Fix this issue by calling kfree() for it when kcalloc() fails. Fixes: 281b5278 ("KVM: x86: Add emulation for MSR_IA32_MCx_CTL2 MSRs.") Signed-off-by:
Miaohe Lin <linmiaohe@huawei.com> Message-Id: <20220901122300.22298-1-linmiaohe@huawei.com> Signed-off-by:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit 0204750b Author: Jim Mattson <jmattson@google.com> Date: Tue Aug 30 10:49:47 2022 -0700 KVM: x86: Mask off unsupported and unknown bits of IA32_ARCH_CAPABILITIES KVM should not claim to virtualize unknown IA32_ARCH_CAPABILITIES bits. When kvm_get_arch_capabilities() was originally written, there were only a few bits defined in this MSR, and KVM could virtualize all of them. However, over the years, several bits have been defined that KVM cannot just blindly pass through to the guest without additional work (such as virtualizing an MSR promised by the IA32_ARCH_CAPABILITES feature bit). Define a mask of supported IA32_ARCH_CAPABILITIES bits, and mask off any other bits that are set in the hardware MSR. Cc: Paolo Bonzini <pbonzini@redhat.com> Fixes: 5b76a3cf ("KVM: VMX: Tell the nested hypervisor to skip L1D flush on vmentry") Signed-off-by:
Jim Mattson <jmattson@google.com> Reviewed-by:
Vipin Sharma <vipinsh@google.com> Reviewed-by:
Xiaoyao Li <xiaoyao.li@intel.com> Message-Id: <20220830174947.2182144-1-jmattson@google.com> Signed-off-by:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit 372d0708 Author: David Matlack <dmatlack@google.com> Date: Fri Jul 22 23:48:38 2022 +0000 KVM: selftests: Fix ambiguous mov in KVM_ASM_SAFE() Change the mov in KVM_ASM_SAFE() that zeroes @vector to a movb to make it unambiguous. This fixes a build failure with Clang since, unlike the GNU assembler, the LLVM integrated assembler rejects ambiguous X86 instructions that don't have suffixes: In file included from x86_64/hyperv_features.c:13: include/x86_64/processor.h:825:9: error: ambiguous instructions require an explicit suffix (could be 'movb', 'movw', 'movl', or 'movq') return kvm_asm_safe("wrmsr", "a"(val & -1u), "d"(val >> 32), "c"(msr)); ^ include/x86_64/processor.h:802:15: note: expanded from macro 'kvm_asm_safe' asm volatile(KVM_ASM_SAFE(insn) \ ^ include/x86_64/processor.h:788:16: note: expanded from macro 'KVM_ASM_SAFE' "1: " insn "\n\t" \ ^ <inline asm>:5:2: note: instantiated into assembly here mov $0, 15(%rsp) ^ It seems like this change could introduce undesirable behavior in the future, e.g. if someone used a type larger than a u8 for @vector, since KVM_ASM_SAFE() will only zero the bottom byte. I tried changing the type of @vector to an int to see what would happen. GCC failed to compile due to a size mismatch between `movb` and `%eax`. Clang succeeded in compiling, but the generated code looked correct, so perhaps it will not be an issue. That being said it seems like there could be a better solution to this issue that does not assume @vector is a u8. Fixes: 3b23054c ("KVM: selftests: Add x86-64 support for exception fixup") Signed-off-by:
David Matlack <dmatlack@google.com> Reviewed-by:
Sean Christopherson <seanjc@google.com> Message-Id: <20220722234838.2160385-3-dmatlack@google.com> Signed-off-by:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit 67ef8664 Author: David Matlack <dmatlack@google.com> Date: Fri Jul 22 23:48:37 2022 +0000 KVM: selftests: Fix KVM_EXCEPTION_MAGIC build with Clang Change KVM_EXCEPTION_MAGIC to use the all-caps "ULL", rather than lower case. This fixes a build failure with Clang: In file included from x86_64/hyperv_features.c:13: include/x86_64/processor.h:825:9: error: unexpected token in argument list return kvm_asm_safe("wrmsr", "a"(val & -1u), "d"(val >> 32), "c"(msr)); ^ include/x86_64/processor.h:802:15: note: expanded from macro 'kvm_asm_safe' asm volatile(KVM_ASM_SAFE(insn) \ ^ include/x86_64/processor.h:785:2: note: expanded from macro 'KVM_ASM_SAFE' "mov $" __stringify(KVM_EXCEPTION_MAGIC) ", %%r9\n\t" \ ^ <inline asm>:1:18: note: instantiated into assembly here mov $0xabacadabaull, %r9 ^ Fixes: 3b23054c ("KVM: selftests: Add x86-64 support for exception fixup") Signed-off-by:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit 020dac41 Author: Jim Mattson <jmattson@google.com> Date: Wed Aug 10 14:30:50 2022 -0700 KVM: VMX: Heed the 'msr' argument in msr_write_intercepted() Regardless of the 'msr' argument passed to the VMX version of msr_write_intercepted(), the function always checks to see if a specific MSR (IA32_SPEC_CTRL) is intercepted for write. This behavior seems unintentional and unexpected. Modify the function so that it checks to see if the provided 'msr' index is intercepted for write. Fixes: 67f4b996 ("KVM: nVMX: Handle dynamic MSR intercept toggling") Cc: Sean Christopherson <seanjc@google.com> Signed-off-by:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit b64d740e Author: Junaid Shahid <junaids@google.com> Date: Wed Aug 10 15:49:39 2022 -0700 kvm: x86: mmu: Always flush TLBs when enabling dirty logging When A/D bits are not available, KVM uses a software access tracking mechanism, which involves making the SPTEs inaccessible. However, the clear_young() MMU notifier does not flush TLBs. So it is possible that there may still be stale, potentially writable, TLB entries. This is usually fine, but can be problematic when enabling dirty logging, because it currently only does a TLB flush if any SPTEs were modified. But if all SPTEs are in access-tracked state, then there won't be a TLB flush, which means that the guest could still possibly write to memory and not have it reflected in the dirty bitmap. So just unconditionally flush the TLBs when enabling dirty logging. As an alternative, KVM could explicitly check the MMU-Writable bit when write-protecting SPTEs to decide if a flush is needed (instead of checking the Writable bit), but given that a flush almost always happens anyway, so just making it unconditional seems simpler. Signed-off-by:
Junaid Shahid <junaids@google.com> Message-Id: <20220810224939.2611160-1-junaids@google.com> Signed-off-by:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit 1441ca14 Author: Junaid Shahid <junaids@google.com> Date: Fri Jul 22 19:43:16 2022 -0700 kvm: x86: mmu: Drop the need_remote_flush() function This is only used by kvm_mmu_pte_write(), which no longer actually creates the new SPTE and instead just clears the old SPTE. So we just need to check if the old SPTE was shadow-present instead of calling need_remote_flush(). Hence we can drop this function. It was incomplete anyway as it didn't take access-tracking into account. This patch should not result in any functional change. Signed-off-by:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit eceb6e1d Author: Li kunyu <kunyu@nfschina.com> Date: Fri Aug 19 10:15:35 2022 +0800 KVM: Drop unnecessary initialization of "ops" in kvm_ioctl_create_device() The variable is initialized but it is only used after its assignment. Reviewed-by:
Li kunyu <kunyu@nfschina.com> Message-Id: <20220819021535.483702-1-kunyu@nfschina.com> Signed-off-by:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit 28249139 Author: Li kunyu <kunyu@nfschina.com> Date: Fri Aug 19 10:28:04 2022 +0800 KVM: Drop unnecessary initialization of "npages" in hva_to_pfn_slow() The variable is initialized but it is only used after its assignment. Reviewed-by:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit 20ec3ebd Author: Chao Peng <chao.p.peng@linux.intel.com> Date: Tue Aug 16 20:53:22 2022 +0800 KVM: Rename mmu_notifier_* to mmu_invalidate_* The motivation of this renaming is to make these variables and related helper functions less mmu_notifier bound and can also be used for non mmu_notifier based page invalidation. mmu_invalidate_* was chosen to better describe the purpose of 'invalidating' a page that those variables are used for. - mmu_notifier_seq/range_start/range_end are renamed to mmu_invalidate_seq/range_start/range_end. - mmu_notifier_retry{_hva} helper functions are renamed to mmu_invalidate_retry{_hva}. - mmu_notifier_count is renamed to mmu_invalidate_in_progress to avoid confusion with mn_active_invalidate_count. - While here, also update kvm_inc/dec_notifier_count() to kvm_mmu_invalidate_begin/end() to match the change for mmu_notifier_count. No functional change intended. Signed-off-by:
Chao Peng <chao.p.peng@linux.intel.com> Message-Id: <20220816125322.1110439-3-chao.p.peng@linux.intel.com> Signed-off-by:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit bdd1c37a Author: Chao Peng <chao.p.peng@linux.intel.com> Date: Tue Aug 16 20:53:21 2022 +0800 KVM: Rename KVM_PRIVATE_MEM_SLOTS to KVM_INTERNAL_MEM_SLOTS KVM_INTERNAL_MEM_SLOTS better reflects the fact those slots are KVM internally used (invisible to userspace) and avoids confusion to future private slots that can have different meaning. Signed-off-by:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit c2b82397 Author: Sean Christopherson <seanjc@google.com> Date: Tue Aug 16 05:39:37 2022 +0000 KVM: Move coalesced MMIO initialization (back) into kvm_create_vm() Invoke kvm_coalesced_mmio_init() from kvm_create_vm() now that allocating and initializing coalesced MMIO objects is separate from registering any associated devices. Moving coalesced MMIO cleans up the last oddity where KVM does VM creation/initialization after kvm_create_vm(), and more importantly after kvm_arch_post_init_vm() is called and the VM is added to the global vm_list, i.e. after the VM is fully created as far as KVM is concerned. Originally, kvm_coalesced_mmio_init() was called by kvm_create_vm(), but the original implementation was completely devoid of error handling. Commit 6ce5a090 ("KVM: coalesced_mmio: fix kvm_coalesced_mmio_init()'s error handling" fixed the various bugs, and in doing so rightly moved the call to after kvm_create_vm() because kvm_coalesced_mmio_init() also registered the coalesced MMIO device. Commit 2b3c246a ("KVM: Make coalesced mmio use a device per zone") cleaned up that mess by having each zone register a separate device, i.e. moved device registration to its logical home in kvm_vm_ioctl_register_coalesced_mmio(). As a result, kvm_coalesced_mmio_init() is now a "pure" initialization helper and can be safely called from kvm_create_vm(). Opportunstically drop the #ifdef, KVM provides stubs for kvm_coalesced_mmio_{init,free}() when CONFIG_KVM_MMIO=n (s390). Signed-off-by:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit 405294f2 Author: Sean Christopherson <seanjc@google.com> Date: Tue Aug 16 05:39:36 2022 +0000 KVM: Unconditionally get a ref to /dev/kvm module when creating a VM Unconditionally get a reference to the /dev/kvm module when creating a VM instead of using try_get_module(), which will fail if the module is in the process of being forcefully unloaded. The error handling when try_get_module() fails doesn't properly unwind all that has been done, e.g. doesn't call kvm_arch_pre_destroy_vm() and doesn't remove the VM from the global list. Not removing VMs from the global list tends to be fatal, e.g. leads to use-after-free explosions. The obvious alternative would be to add proper unwinding, but the justification for using try_get_module(), "rmmod --wait", is completely bogus as support for "rmmod --wait", i.e. delete_module() without O_NONBLOCK, was removed by commit 3f2b9c9c ("module: remove rmmod --wait option.") nearly a decade ago. It's still possible for try_get_module() to fail due to the module dying (more like being killed), as the module will be tagged MODULE_STATE_GOING by "rmmod --force", i.e. delete_module(..., O_TRUNC), but playing nice with forced unloading is an exercise in futility and gives a falsea sense of security. Using try_get_module() only prevents acquiring _new_ references, it doesn't magically put the references held by other VMs, and forced unloading doesn't wait, i.e. "rmmod --force" on KVM is all but guaranteed to cause spectacular fireworks; the window where KVM will fail try_get_module() is tiny compared to the window where KVM is building and running the VM with an elevated module refcount. Addressing KVM's inability to play nice with "rmmod --force" is firmly out-of-scope. Forcefully unloading any module taints kernel (for obvious reasons) _and_ requires the kernel to be built with CONFIG_MODULE_FORCE_UNLOAD=y, which is off by default and comes with the amusing disclaimer that it's "mainly for kernel developers and desperate users". In other words, KVM is free to scoff at bug reports due to using "rmmod --force" while VMs may be running. Fixes: 5f6de5cb ("KVM: Prevent module exit until all VMs are freed") Cc: stable@vger.kernel.org Cc: David Matlack <dmatlack@google.com> Signed-off-by:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit 4ba4f419 Author: Sean Christopherson <seanjc@google.com> Date: Tue Aug 16 05:39:35 2022 +0000 KVM: Properly unwind VM creation if creating debugfs fails Properly unwind VM creation if kvm_create_vm_debugfs() fails. A recent change to invoke kvm_create_vm_debug() in kvm_create_vm() was led astray by buggy try_get_module() handling adding by commit 5f6de5cb ("KVM: Prevent module exit until all VMs are freed"). The debugfs error path effectively inherits the bad error path of try_module_get(), e.g. KVM leaves the to-be-free VM on vm_list even though KVM appears to do the right thing by calling module_put() and falling through. Opportunistically hoist kvm_create_vm_debugfs() above the call to kvm_arch_post_init_vm() so that the "post-init" arch hook is actually invoked after the VM is initialized (ignoring kvm_coalesced_mmio_init() for the moment). x86 is the only non-nop implementation of the post-init hook, and it doesn't allocate/initialize any objects that are reachable via debugfs code (spawns a kthread worker for the NX huge page mitigation). Leave the buggy try_get_module() alone for now, it will be fixed in a separate commit. Fixes: b74ed7a6 ("KVM: Actually create debugfs in kvm_create_vm()") Reported-by:
<syzbot+744e173caec2e1627ee0@syzkaller.appspotmail.com> Cc: Oliver Upton <oliver.upton@linux.dev> Signed-off-by:
Oliver Upton <oliver.upton@linux.dev> Message-Id: <20220816053937.2477106-2-seanjc@google.com> Signed-off-by:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit 6348aafa Author: Sean Christopherson <seanjc@google.com> Date: Wed Jul 27 23:34:24 2022 +0000 KVM: VMX: Adjust number of LBR records for PERF_CAPABILITIES at refresh Now that the PMU is refreshed when MSR_IA32_PERF_CAPABILITIES is written by host userspace, zero out the number of LBR records for a vCPU during PMU refresh if PMU_CAP_LBR_FMT is not set in PERF_CAPABILITIES instead of handling the check at run-time. guest_cpuid_has() is expensive due to the linear search of guest CPUID entries, intel_pmu_lbr_is_enabled() is checked on every VM-Enter, _and_ simply enumerating the same "Model" as the host causes KVM to set the number of LBR records to a non-zero value. Signed-off-by:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit 7de8e5b6 Author: Sean Christopherson <seanjc@google.com> Date: Wed Jul 27 23:34:23 2022 +0000 KVM: VMX: Use proper type-safe functions for vCPU => LBRs helpers Turn vcpu_to_lbr_desc() and vcpu_to_lbr_records() into functions in order to provide type safety, to document exactly what they return, and to allow consuming the helpers in vmx.h. Move the definitions as necessary (the macros "reference" to_vmx() before its definition). No functional change intended. Signed-off-by:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit 17a024a8 Author: Sean Christopherson <seanjc@google.com> Date: Wed Jul 27 23:34:22 2022 +0000 KVM: x86: Refresh PMU after writes to MSR_IA32_PERF_CAPABILITIES Refresh the PMU if userspace modifies MSR_IA32_PERF_CAPABILITIES. KVM consumes the vCPU's PERF_CAPABILITIES when enumerating PEBS support, but relies on CPUID updates to refresh the PMU. I.e. KVM will do the wrong thing if userspace stuffs PERF_CAPABILITIES _after_ setting guest CPUID. Opportunistically fix a curly-brace indentation. Fixes: c59a1f10 ("KVM: x86/pmu: Add IA32_PEBS_ENABLE MSR emulation for extended PEBS") Cc: Like Xu <like.xu.linux@gmail.com> Signed-off-by:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit 9d27d461 Author: Sean Christopherson <seanjc@google.com> Date: Thu Aug 4 12:18:15 2022 -0700 KVM: selftests: Test all possible "invalid" PERF_CAPABILITIES.LBR_FMT vals Test all possible input values to verify that KVM rejects all values except the exact host value. Due to the LBR format affecting the core functionality of LBRs, KVM can't emulate "other" formats, so even though there are a variety of legal values, KVM should reject anything but an exact host match. Suggested-by:
Like Xu <like.xu.linux@gmail.com> Signed-off-by:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit 0fcc1029 Author: Gavin Shan <gshan@redhat.com> Date: Wed Aug 10 18:41:14 2022 +0800 KVM: selftests: Use getcpu() instead of sched_getcpu() in rseq_test sched_getcpu() is glibc dependent and it can simply return the CPU ID from the registered rseq information, as Florian Weimer pointed. In this case, it's pointless to compare the return value from sched_getcpu() and that fetched from the registered rseq information. Fix the issue by replacing sched_getcpu() with getcpu(), as Florian suggested. The comments are modified accordingly by replacing "sched_getcpu()" with "getcpu()". Reported-by:
Yihuang Yu <yihyu@redhat.com> Suggested-by:
Florian Weimer <fweimer@redhat.com> Suggested-by:
Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Suggested-by:
Gavin Shan <gshan@redhat.com> Message-Id: <20220810104114.6838-3-gshan@redhat.com> Signed-off-by:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit 66d42ac7 Author: Gavin Shan <gshan@redhat.com> Date: Wed Aug 10 18:41:13 2022 +0800 KVM: selftests: Make rseq compatible with glibc-2.35 The rseq information is registered by TLS, starting from glibc-2.35. In this case, the test always fails due to syscall(__NR_rseq). For example, on RHEL9.1 where upstream glibc-2.35 features are enabled on downstream glibc-2.34, the test fails like below. # ./rseq_test ==== Test Assertion Failure ==== rseq_test.c:60: !r pid=112043 tid=112043 errno=22 - Invalid argument 1 0x0000000000401973: main at rseq_test.c:226 2 0x0000ffff84b6c79b: ?? ??:0 3 0x0000ffff84b6c86b: ?? ??:0 4 0x0000000000401b6f: _start at ??:? rseq failed, errno = 22 (Invalid argument) # rpm -aq | grep glibc-2 glibc-2.34-39.el9.aarch64 Fix the issue by using "../rseq/rseq.c" to fetch the rseq information, registred by TLS if it exists. Otherwise, we're going to register our own rseq information as before. Reported-by:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit b74ed7a6 Author: Oliver Upton <oupton@google.com> Date: Wed Jul 20 09:22:51 2022 +0000 KVM: Actually create debugfs in kvm_create_vm() Doing debugfs creation after vm creation leaves things in a quasi-initialized state for a while. This is further complicated by the fact that we tear down debugfs from kvm_destroy_vm(). Align debugfs and stats init/destroy with the vm init/destroy pattern to avoid any headaches. Note the fix for a benign mistake in error handling for calls to kvm_arch_create_vm_debugfs() rolled in. Since all implementations of the function return 0 unconditionally it isn't actually a bug at the moment. Lastly, tear down debugfs/stats data in the kvm_create_vm_debugfs() error path. Previously it was safe to assume that kvm_destroy_vm() would take out the garbage, that is no longer the case. Signed-off-by:
Oliver Upton <oupton@google.com> Message-Id: <20220720092259.3491733-6-oliver.upton@linux.dev> Signed-off-by:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit 59f82aad Author: Oliver Upton <oupton@google.com> Date: Wed Jul 20 09:22:50 2022 +0000 KVM: Pass the name of the VM fd to kvm_create_vm_debugfs() At the time the VM fd is used in kvm_create_vm_debugfs(), the fd has been allocated but not yet installed. It is only really useful as an identifier in strings for the VM (such as debugfs). Treat it exactly as such by passing the string name of the fd to kvm_create_vm_debugfs(), futureproofing against possible misuse of the VM fd. Suggested-by:
-
