summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/bin
diff options
context:
space:
mode:
authorSean Christopherson <seanjc@google.com>2026-08-26 09:42:13 -0700
committerSean Christopherson <seanjc@google.com>2026-09-11 11:48:14 -0700
commit6415d9c4ee19be3816c89974562d67e2c00c8638 (patch)
tree3317d27efe2cc7f20c4198d200e0fbfe753ab1f8 /tools/perf/scripts/python/bin
parent698b8c88e15914a88f686b552c14c0c5caff3cc7 (diff)
KVM: x86/mmu: Top-up memory caches when retrying "map private PFN"
When mapping a private PFN in TDX's post-populate callback, top-up the memory caches on every attempt to map the PFN to harden against bugs in the map flow that could consume cache entries even if mapping ultimately fails. E.g. as pointed out by Sashiko, the in-progress Dynamic PAMT support could consume PAMT cache entries on TDX-Module lock contention. Harden KVM even though consuming an entry on failure is considered a KVM bug. Retry should only be encountered if KVM is buggy (the locks held by the sole call path will prevent retries from being needed due to TDX-specific details, and memory can be faulted in only once the VM is TD_STATE_RUNNABLE, and KVM_TDX_INIT_MEM_REGION is only usable if the VM is *not* TD_STATE_RUNNABLE), top-up is "free" if there's no work to be done, and populating a TDX guest's memory is a slow path, i.e. there's no meaningful downside to the hardening. Reported-by: Sashiko Bot <sashiko-bot@kernel.org> Closes: https://lore.kernel.org/all/20260718061050.E17B01F000E9@smtp.kernel.org Reviewed-by: Rick Edgecombe <rick.p.edgecombe@intel.com> Link: https://patch.msgid.link/20260826164214.756512-4-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