summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python
diff options
context:
space:
mode:
authorMikhail Malyshev <mike.malyshev@gmail.com>2026-09-20 07:24:59 +0000
committerSean Christopherson <seanjc@google.com>2026-09-28 17:55:23 -0700
commit98a843669196ace8789a859796e45caffb970e40 (patch)
tree46bb4b1699f6c018a2e1104002db865f61f08988 /tools/perf/scripts/python
parent27f02d851410ece239f4024aae87143ed00f4354 (diff)
KVM: x86/mmu: Convert can't-happen fault path EFAULTs to KVM_BUG_ON() + -EIO
Four -EFAULT returns in x86's page fault path are guarded by WARN_ON_ONCE() because they describe KVM bugs, not conditions the guest or userspace can reach: - direct_map() and FNAME(fetch)() completing the walk at a level other than the goal level, i.e. KVM's shadow page table walk disagreeing with the mapping level KVM itself just computed. - a CR2 with bits 63:32 set on 32-bit KVM, which the hardware cannot produce. - PFERR_PRIVATE_ACCESS set on a reserved-bit fault. KVM sets that synthetic bit itself, and only when PFERR_RSVD_MASK is clear. Returning -EFAULT for a KVM bug conflicts with KVM_CAP_MEMORY_FAULT_INFO, which promises that an -EFAULT out of KVM_RUN on a guest page fault VM-Exit is accompanied by kvm_run.memory_fault. Describing a broken KVM invariant as a memory fault would be actively misleading, as there is no guest access for userspace to resolve and retry. Convert the four sites to KVM_BUG_ON() + -EIO, the established way to report that KVM is hosed, so that -EFAULT out of the fault path always means "guest memory access KVM could not resolve". Suggested-by: Sean Christopherson <seanjc@google.com> Link: https://lore.kernel.org/all/Zr-8M9rYplgN6IS3@google.com/ Signed-off-by: Mikhail Malyshev <mike.malyshev@gmail.com> Link: https://patch.msgid.link/20260920072459.3485710-3-mike.malyshev@gmail.com Signed-off-by: Sean Christopherson <seanjc@google.com>
Diffstat (limited to 'tools/perf/scripts/python')
0 files changed, 0 insertions, 0 deletions