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
-
Abel Vesa
abel.vesa
-
Abhijeet Badurkar abhijeet.badurkar
-
Abhijit Adsule adsule
-
Abhijit Murthy abhijit
-
Abhi Khanal akhanal
-
Abhilash Sahoo abhilashsahoo
- Oct 25, 2022
-
-
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:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
Vitaly Kuznetsov <vkuznets@redhat.com>
-
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:
David Matlack <dmatlack@google.com> Reviewed-by:
Sean Christopherson <seanjc@google.com> Message-Id: <20220723024316.2725328-1-junaids@google.com> Signed-off-by:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit eceb6e1d530046f964b0e371d4fad02a5b6b42d1 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:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit 20020f4c Author: Oliver Upton <oupton@google.com> Date: Wed Jul 20 09:22:49 2022 +0000 KVM: Get an fd before creating the VM Allocate a VM's fd at the very beginning of kvm_dev_ioctl_create_vm() so that KVM can use the fd value to generate strigns, e.g. for debugfs, when creating and initializing the VM. Signed-off-by:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit 58fc1166 Author: Oliver Upton <oupton@google.com> Date: Wed Jul 20 09:22:48 2022 +0000 KVM: Shove vcpu stats_id init into kvm_vcpu_init() Initialize stats_id alongside other kvm_vcpu fields to make it more difficult to unintentionally access stats_id before it's set. No functional change intended. Signed-off-by:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit f2759c08 Author: Oliver Upton <oupton@google.com> Date: Wed Jul 20 09:22:47 2022 +0000 KVM: Shove vm stats_id init into kvm_create_vm() Initialize stats_id alongside other struct kvm fields to make it more difficult to unintentionally access stats_id before it's set. While at it, move the format string to the first line of the call and fix the indentation of the second line. No functional change intended. Signed-off-by:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit 8bad4606 Author: Sean Christopherson <seanjc@google.com> Date: Fri Aug 5 19:41:33 2022 +0000 KVM: x86/mmu: Add sanity check that MMIO SPTE mask doesn't overlap gen Add compile-time and init-time sanity checks to ensure that the MMIO SPTE mask doesn't overlap the MMIO SPTE generation or the MMU-present bit. The generation currently avoids using bit 63, but that's as much coincidence as it is strictly necessarly. That will change in the future, as TDX support will require setting bit 63 (SUPPRESS_VE) in the mask. Explicitly carve out the bits that are allowed in the mask so that any future shuffling of SPTE bits doesn't silently break MMIO caching (KVM has broken MMIO caching more than once due to overlapping the generation with other things). Suggested-by:
Kai Huang <kai.huang@intel.com> Signed-off-by:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit 1685c0f3 Author: Mingwei Zhang <mizhang@google.com> Date: Sun Aug 7 05:21:41 2022 +0000 KVM: x86/mmu: rename trace function name for asynchronous page fault Rename the tracepoint function from trace_kvm_async_pf_doublefault() to trace_kvm_async_pf_repeated_fault() to make it clear, since double fault has nothing to do with this trace function. Asynchronous Page Fault (APF) is an artifact generated by KVM when it cannot find a physical page to satisfy an EPT violation. KVM uses APF to tell the guest OS to do something else such as scheduling other guest processes to make forward progress. However, when another guest process also touches a previously APFed page, KVM halts the vCPU instead of generating a repeated APF to avoid wasting cycles. Double fault (#DF) clearly has a different meaning and a different consequence when triggered. #DF requires two nested contributory exceptions instead of two page faults faulting at the same address. A prevous bug on APF indicates that it may trigger a double fault in the guest [1] and clearly this trace function has nothing to do with it. So rename this function should be a valid choice. No functional change intended. [1] https://www.spinics.net/lists/kvm/msg214957.html Signed-off-by:
Mingwei Zhang <mizhang@google.com> Message-Id: <20220807052141.69186-1-mizhang@google.com> Signed-off-by:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit c0368991 Author: Coleman Dietsch <dietschc@csp.edu> Date: Mon Aug 8 14:06:07 2022 -0500 KVM: x86/xen: Stop Xen timer before changing IRQ Stop Xen timer (if it's running) prior to changing the IRQ vector and potentially (re)starting the timer. Changing the IRQ vector while the timer is still running can result in KVM injecting a garbage event, e.g. vm_xen_inject_timer_irqs() could see a non-zero xen.timer_pending from a previous timer but inject the new xen.timer_virq. Fixes: 53639526 ("KVM: x86/xen: handle PV timers oneshot mode") Cc: stable@vger.kernel.org Link: https://syzkaller.appspot.com/bug?id=8234a9dfd3aafbf092cc5a7cd9842e3ebc45fc42 Reported-by:
<syzbot+e54f930ed78eb0f85281@syzkaller.appspotmail.com> Signed-off-by:
Coleman Dietsch <dietschc@csp.edu> Reviewed-by:
David Woodhouse <dwmw@amazon.co.uk> Message-Id: <20220808190607.323899-3-dietschc@csp.edu> Signed-off-by:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit af735db3 Author: Coleman Dietsch <dietschc@csp.edu> Date: Mon Aug 8 14:06:06 2022 -0500 KVM: x86/xen: Initialize Xen timer only once Add a check for existing xen timers before initializing a new one. Currently kvm_xen_init_timer() is called on every KVM_XEN_VCPU_ATTR_TYPE_TIMER, which is causing the following ODEBUG crash when vcpu->arch.xen.timer is already set. ODEBUG: init active (active state 0) object type: hrtimer hint: xen_timer_callbac0 RIP: 0010:debug_print_object+0x16e/0x250 lib/debugobjects.c:502 Call Trace: __debug_object_init debug_hrtimer_init debug_init hrtimer_init kvm_xen_init_timer kvm_xen_vcpu_set_attr kvm_arch_vcpu_ioctl kvm_vcpu_ioctl vfs_ioctl Fixes: 53639526 ("KVM: x86/xen: handle PV timers oneshot mode") Cc: stable@vger.kernel.org Link: https://syzkaller.appspot.com/bug?id=8234a9dfd3aafbf092cc5a7cd9842e3ebc45fc42 Reported-by:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit 0c29397a Author: Sean Christopherson <seanjc@google.com> Date: Wed Aug 3 22:49:57 2022 +0000 KVM: SVM: Disable SEV-ES support if MMIO caching is disable Disable SEV-ES if MMIO caching is disabled as SEV-ES relies on MMIO SPTEs generating #NPF(RSVD), which are reflected by the CPU into the guest as a #VC. With SEV-ES, the untrusted host, a.k.a. KVM, doesn't have access to the guest instruction stream or register state and so can't directly emulate in response to a #NPF on an emulated MMIO GPA. Disabling MMIO caching means guest accesses to emulated MMIO ranges cause #NPF(!PRESENT), and those flavors of #NPF cause automatic VM-Exits, not #VC. Adjust KVM's MMIO masks to account for the C-bit location prior to doing SEV(-ES) setup, and document that dependency between adjusting the MMIO SPTE mask and SEV(-ES) setup. Fixes: b09763da ("KVM: x86/mmu: Add module param to disable MMIO caching (for testing)") Reported-by:
Michael Roth <michael.roth@amd.com> Tested-by:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit c3e0c8c2 Author: Sean Christopherson <seanjc@google.com> Date: Wed Aug 3 22:49:56 2022 +0000 KVM: x86/mmu: Fully re-evaluate MMIO caching when SPTE masks change Fully re-evaluate whether or not MMIO caching can be enabled when SPTE masks change; simply clearing enable_mmio_caching when a configuration isn't compatible with caching fails to handle the scenario where the masks are updated, e.g. by VMX for EPT or by SVM to account for the C-bit location, and toggle compatibility from false=>true. Snapshot the original module param so that re-evaluating MMIO caching preserves userspace's desire to allow caching. Use a snapshot approach so that enable_mmio_caching still reflects KVM's actual behavior. Fixes: 8b9e74bf ("KVM: x86/mmu: Use enable_mmio_caching to track if MMIO caching is enabled") Reported-by:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit 982bae43 Author: Sean Christopherson <seanjc@google.com> Date: Wed Aug 3 22:49:55 2022 +0000 KVM: x86: Tag kvm_mmu_x86_module_init() with __init Mark kvm_mmu_x86_module_init() with __init, the entire reason it exists is to initialize variables when kvm.ko is loaded, i.e. it must never be called after module initialization. Fixes: 1d0e8480 ("KVM: x86/mmu: Resolve nx_huge_pages when kvm.ko is loaded") Cc: stable@vger.kernel.org Reviewed-by:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit 4ac5b423 Author: Michal Luczaj <mhal@rbox.co> Date: Fri Jul 29 15:48:01 2022 +0200 KVM: x86: emulator: Fix illegal LEA handling The emulator mishandles LEA with register source operand. Even though such LEA is illegal, it can be encoded and fed to CPU. In which case real hardware throws #UD. The emulator, instead, returns address of x86_emulate_ctxt._regs. This info leak hurts host's kASLR. Tell the decoder that illegal LEA is not to be emulated. Signed-off-by:
Michal Luczaj <mhal@rbox.co> Message-Id: <20220729134801.1120-1-mhal@rbox.co> Signed-off-by:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit 2bc685e6 Author: Yu Zhang <yu.c.zhang@linux.intel.com> Date: Mon Jul 18 15:47:56 2022 +0800 KVM: X86: avoid uninitialized 'fault.async_page_fault' from fixed-up #PF kvm_fixup_and_inject_pf_error() was introduced to fixup the error code( e.g., to add RSVD flag) and inject the #PF to the guest, when guest MAXPHYADDR is smaller than the host one. When it comes to nested, L0 is expected to intercept and fix up the #PF and then inject to L2 directly if - L2.MAXPHYADDR < L0.MAXPHYADDR and - L1 has no intention to intercept L2's #PF (e.g., L2 and L1 have the same MAXPHYADDR value && L1 is using EPT for L2), instead of constructing a #PF VM Exit to L1. Currently, with PFEC_MASK and PFEC_MATCH both set to 0 in vmcs02, the interception and injection may happen on all L2 #PFs. However, failing to initialize 'fault' in kvm_fixup_and_inject_pf_error() may cause the fault.async_page_fault being NOT zeroed, and later the #PF being treated as a nested async page fault, and then being injected to L1. Instead of zeroing 'fault' at the beginning of this function, we mannually set the value of 'fault.async_page_fault', because false is the value we really expect. Fixes: 89786147 ("KVM: x86: Add helper functions for illegal GPA checking and page fault injection") Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=216178 Reported-by:
Yang Lixiao <lixiao.yang@intel.com> Signed-off-by:
Yu Zhang <yu.c.zhang@linux.intel.com> Reviewed-by:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit 70c8327c Author: Sean Christopherson <seanjc@google.com> Date: Thu Aug 4 23:50:28 2022 +0000 KVM: x86: Bug the VM if an accelerated x2APIC trap occurs on a "bad" reg Bug the VM if retrieving the x2APIC MSR/register while processing an accelerated vAPIC trap VM-Exit fails. In theory it's impossible for the lookup to fail as hardware has already validated the register, but bugs happen, and not checking the result of kvm_lapic_msr_read() would result in consuming the uninitialized "val" if a KVM or hardware bug occurs. Fixes: 1bd9dfec ("KVM: x86: Do not block APIC write for non ICR registers") Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Cc: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> Signed-off-by:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit baea2ce5 Author: Paolo Bonzini <pbonzini@redhat.com> Date: Wed Aug 10 14:55:27 2022 -0400 selftests: kvm: fix compilation Commit 49de12ba ("selftests: drop KSFT_KHDR_INSTALL make target") dropped from tools/testing/selftests/lib.mk the code related to KSFT_KHDR_INSTALL, but in doing so it also dropped the definition of the ARCH variable. The ARCH variable is used in several subdirectories, but kvm/ is the only one of these that was using KSFT_KHDR_INSTALL. As a result, kvm selftests cannot be built anymore: In file included from include/x86_64/vmx.h:12, from x86_64/vmx_pmu_caps_test.c:18: include/x86_64/processor.h:15:10: fatal error: asm/msr-index.h: No such file or directory 15 | #include <asm/msr-index.h> | ^~~~~~~~~~~~~~~~~ In file included from ../../../../tools/include/asm/atomic.h:6, from ../../../../tools/include/linux/atomic.h:5, from rseq_test.c:15: ../../../../tools/include/asm/../../arch/x86/include/asm/atomic.h:11:10: fatal error: asm/cmpxchg.h: No such file or directory 11 | #include <asm/cmpxchg.h> | ^~~~~~~~~~~~~~~ Fix it by including the definition that was present in lib.mk. Fixes: 49de12ba ("selftests: drop KSFT_KHDR_INSTALL make target") Cc: Guillaume Tucker <guillaume.tucker@collabora.com> Cc: Anders Roxell <anders.roxell@linaro.org> Cc: Shuah Khan <skhan@linuxfoundation.org> Cc: linux-kselftest@vger.kernel.org Signed-off-by:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit 281106f9 Author: Andrei Vagin <avagin@google.com> Date: Fri Jul 22 16:02:40 2022 -0700 selftests: kvm: set rax before vmcall kvm_hypercall has to place the hypercall number in rax. Trace events show that kvm_pv_test doesn't work properly: kvm_pv_test-53132: kvm_hypercall: nr 0x0 a0 0x0 a1 0x0 a2 0x0 a3 0x0 kvm_pv_test-53132: kvm_hypercall: nr 0x0 a0 0x0 a1 0x0 a2 0x0 a3 0x0 kvm_pv_test-53132: kvm_hypercall: nr 0x0 a0 0x0 a1 0x0 a2 0x0 a3 0x0 With this change, it starts working as expected: kvm_pv_test-54285: kvm_hypercall: nr 0x5 a0 0x0 a1 0x0 a2 0x0 a3 0x0 kvm_pv_test-54285: kvm_hypercall: nr 0xa a0 0x0 a1 0x0 a2 0x0 a3 0x0 kvm_pv_test-54285: kvm_hypercall: nr 0xb a0 0x0 a1 0x0 a2 0x0 a3 0x0 Signed-off-by:
Andrei Vagin <avagin@google.com> Message-Id: <20220722230241.1944655-5-avagin@google.com> Fixes: ac4a4d6d ("selftests: kvm: test enforcement of paravirtual cpuid features") Signed-off-by:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit dd4d1c3b Author: Oliver Upton <oupton@google.com> Date: Tue Jul 19 14:31:34 2022 +0000 selftests: KVM: Add exponent check for boolean stats The only sensible exponent for a boolean stat is 0. Add a test assertion requiring all boolean statistics to have an exponent of 0. Signed-off-by:
Andrew Jones <andrew.jones@linux.dev> Message-Id: <20220719143134.3246798-4-oliver.upton@linux.dev> Signed-off-by:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit 7eebae78 Author: Oliver Upton <oupton@google.com> Date: Tue Jul 19 14:31:33 2022 +0000 selftests: KVM: Provide descriptive assertions in kvm_binary_stats_test As it turns out, tests sometimes fail. When that is the case, packing the test assertion with as much relevant information helps track down the problem more quickly. Sharpen up the stat descriptor assertions in kvm_binary_stats_test to more precisely describe the reason for the test assertion and which stat is to blame. Signed-off-by:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit ad5b0727 Author: Oliver Upton <oupton@google.com> Date: Tue Jul 19 14:31:32 2022 +0000 selftests: KVM: Check stat name before other fields In order to provide more useful test assertions that describe the broken stats descriptor, perform sanity check on the stat name before any other descriptor field. While at it, avoid dereferencing the name field if the sanity check fails as it is more likely to contain garbage. Signed-off-by:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit 31f6e383 Author: Paolo Bonzini <pbonzini@redhat.com> Date: Mon Aug 1 07:27:18 2022 -0400 KVM: x86/mmu: remove unused variable The last use of 'pfn' went away with the same-named argument to host_pfn_mapping_level; now that the hugepage level is obtained exclusively from the host page tables, kvm_mmu_zap_collapsible_spte does not need to know host pfns at all. Fixes: a8ac499b ("KVM: x86/mmu: Don't require refcounted "struct page" to create huge SPTEs") Signed-off-by:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit 4ab0e470 Author: Anup Patel <apatel@ventanamicro.com> Date: Fri Jul 29 17:15:00 2022 +0530 KVM: Add gfp_custom flag in struct kvm_mmu_memory_cache The kvm_mmu_topup_memory_cache() always uses GFP_KERNEL_ACCOUNT for memory allocation which prevents it's use in atomic context. To address this limitation of kvm_mmu_topup_memory_cache(), we add gfp_custom flag in struct kvm_mmu_memory_cache. When the gfp_custom flag is set to some GFP_xyz flags, the kvm_mmu_topup_memory_cache() will use that instead of GFP_KERNEL_ACCOUNT. Signed-off-by:
Anup Patel <apatel@ventanamicro.com> Reviewed-by:
Atish Patra <atishp@rivosinc.com> Signed-off-by:
Anup Patel <anup@brainfault.org> commit 63f4b210 Merge: 2e2e9115 7edc3a68 Author: Paolo Bonzini <pbonzini@redhat.com> Date: Fri Jul 29 09:46:01 2022 -0400 Merge remote-tracking branch 'kvm/next' into kvm-next-5.20 KVM/s390, KVM/x86 and common infrastructure changes for 5.20 x86: * Permit guests to ignore single-bit ECC errors * Fix races in gfn->pfn cache refresh; do not pin pages tracked by the cache * Intel IPI virtualization * Allow getting/setting pending triple fault with KVM_GET/SET_VCPU_EVENTS * PEBS virtualization * Simplify PMU emulation by just using PERF_TYPE_RAW events * More accurate event reinjection on SVM (avoid retrying instructions) * Allow getting/setting the state of the speaker port data bit * Refuse starting the kvm-intel module if VM-Entry/VM-Exit controls are inconsistent * "Notify" VM exit (detect microarchitectural hangs) for Intel * Cleanups for MCE MSR emulation s390: * add an interface to provide a hypervisor dump for secure guests * improve selftests to use TAP interface * enable interpretive execution of zPCI instructions (for PCI passthrough) * First part of deferred teardown * CPU Topology * PV attestation * Minor fixes Generic: * new selftests API using struct kvm_vcpu instead of a (vm, id) tuple x86: * Use try_cmpxchg64 instead of cmpxchg64 * Bugfixes * Ignore benign host accesses to PMU MSRs when PMU is disabled * Allow disabling KVM's "MONITOR/MWAIT are NOPs!" behavior * x86/MMU: Allow NX huge pages to be disabled on a per-vm basis * Port eager page splitting to shadow MMU as well * Enable CMCI capability by default and handle injected UCNA errors * Expose pid of vcpu threads in debugfs * x2AVIC support for AMD * cleanup PIO emulation * Fixes for LLDT/LTR emulation * Don't require refcounted "struct page" to create huge SPTEs x86 cleanups: * Use separate namespaces for guest PTEs and shadow PTEs bitmasks * PIO emulation * Reorganize rmap API, mostly around rmap destruction * Do not workaround very old KVM bugs for L0 that runs with nesting enabled * new selftests API for CPUID Conflicts: virt/kvm/kvm_main.c (upstream merge conflict) Signed-off-by:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit 7edc3a68 Author: Kai Huang <kai.huang@intel.com> Date: Thu Jul 28 15:04:52 2022 +1200 KVM, x86/mmu: Fix the comment around kvm_tdp_mmu_zap_leafs() Now kvm_tdp_mmu_zap_leafs() only zaps leaf SPTEs but not any non-root pages within that GFN range anymore, so the comment around it isn't right. Fix it by shifting the comment from tdp_mmu_zap_leafs() instead of duplicating it, as tdp_mmu_zap_leafs() is static and is only called by kvm_tdp_mmu_zap_leafs(). Opportunistically tweak the blurb about SPTEs being cleared to (a) say "zapped" instead of "cleared" because "cleared" will be wrong if/when KVM allows a non-zero value for non-present SPTE (i.e. for Intel TDX), and (b) to clarify that a flush is needed if and only if a SPTE has been zapped since MMU lock was last acquired. Fixes: f47e5bbb ("KVM: x86/mmu: Zap only TDP MMU leafs in zap range and mmu_notifier unmap") Suggested-by:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit 6fac42f1 Author: Jarkko Sakkinen <jarkko@profian.com> Date: Thu Jul 28 08:09:19 2022 +0300 KVM: SVM: Dump Virtual Machine Save Area (VMSA) to klog As Virtual Machine Save Area (VMSA) is essential in troubleshooting attestation, dump it to the klog with the KERN_DEBUG level of priority. Cc: Jarkko Sakkinen <jarkko@kernel.org> Suggested-by:
Harald Hoyer <harald@profian.com> Signed-off-by:
Jarkko Sakkinen <jarkko@profian.com> Message-Id: <20220728050919.24113-1-jarkko@profian.com> Signed-off-by:
-
Vitaly Kuznetsov authored
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2119111 commit 6c6ab524 Author: Sean Christopherson <seanjc@google.com> Date: Sat Jul 23 01:30:29 2022 +0000 KVM: x86/mmu: Treat NX as a valid SPTE bit for NPT Treat the NX bit as valid when using NPT, as KVM will set the NX bit when the NX huge page mitigation is enabled (mindblowing) and trigger the WARN that fires on reserved SPTE bits being set. KVM has required NX support for SVM since commit b26a71a1 ("KVM: SVM: Refuse to load kvm_amd if NX support is not available") for exactly this reason, but apparently it never occurred to anyone to actually test NPT with the mitigation enabled. ------------[ cut here ]------------ spte = 0x800000018a600ee7, level = 2, rsvd bits = 0x800f0000001fe000 WARNING: CPU: 152 PID: 15966 at arch/x86/kvm/mmu/spte.c:215 make_spte+0x327/0x340 [kvm] Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 10.48.0 01/27/2022 RIP: 0010:make_spte+0x327/0x340 [kvm] Call Trace: <TASK> tdp_mmu_map_handle_target_level+0xc3/0x230 [kvm] kvm_tdp_mmu_map+0x343/0x3b0 [kvm] direct_page_fault+0x1ae/0x2a0 [kvm] kvm_tdp_page_fault+0x7d/0x90 [kvm] kvm_mmu_page_fault+0xfb/0x2e0 [kvm] npf_interception+0x55/0x90 [kvm_amd] svm_invoke_exit_handler+0x31/0xf0 [kvm_amd] svm_handle_exit+0xf6/0x1d0 [kvm_amd] vcpu_enter_guest+0xb6d/0xee0 [kvm] ? kvm_pmu_trigger_event+0x6d/0x230 [kvm] vcpu_run+0x65/0x2c0 [kvm] kvm_arch_vcpu_ioctl_run+0x355/0x610 [kvm] kvm_vcpu_ioctl+0x551/0x610 [kvm] __se_sys_ioctl+0x77/0xc0 __x64_sys_ioctl+0x1d/0x20 do_syscall_64+0x44/0xa0 entry_SYSCALL_64_after_hwframe+0x46/0xb0 </TASK> ---[ end trace 0000000000000000 ]--- Cc: stable@vger.kernel.org Signed-off-by:
-
