diff options
| author | Sean Christopherson <seanjc@google.com> | 2026-05-23 02:26:58 +0300 |
|---|---|---|
| committer | Sean Christopherson <seanjc@google.com> | 2026-05-27 00:51:18 +0300 |
| commit | fe0b872d750023eda270cbc01c53ead52b1049d8 (patch) | |
| tree | 67318a36fcfdbca3ad5d28b57a0e9acb3b81d5bf /tools/perf/scripts/python/bin | |
| parent | bb24edbb673f6f3d72ad347cfc107e03d1c6792a (diff) | |
| download | linux-fe0b872d750023eda270cbc01c53ead52b1049d8.tar.xz | |
KVM: x86: Tell ->inject_page_fault() whether or a fault came from hardware
When injecting a page fault (including nested TDP faults into L1), tell the
injection routine whether or not the fault originated in hardware, i.e. if
KVM is effectively forwarding a fault it intercept. For nested TDP fault
injection, KVM needs to grab PAGE_WALK vs. GUEST_FINAL information from the
VMCB/VMCS, _if_ the fault originated in hardware.
Note, simply checking whether or not the original exit was due a #NPF or
EPT Violation isn't sufficient/correct, as the fault being synthesized for
L1 may or may not be the "same" fault that triggered a VM-Exit from L2.
E.g. if access to emulated MMIO in L2 hits a !PRESENT fault (EPT Violation
or #NPF), e.g. because MMIO caching is disabled or it's the first time the
GPA has been accessed by L2, then KVM will enter the emulator. If
emulating the MMIO instruction then hits a nested TDP fault, e.g. because
L2 was accessing MMIO with a MOVSQ (memory-to-memory move), or because L1
has since unmapped the code stream, then the TDP fault synthesized to L1
will not be the same emulated fault the triggered the VM-Exit.
No functional change intended (nothing uses the new param, yet...).
Link: https://patch.msgid.link/20260522232701.3671446-3-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Diffstat (limited to 'tools/perf/scripts/python/bin')
0 files changed, 0 insertions, 0 deletions
