diff options
| author | Sean Christopherson <seanjc@google.com> | 2026-08-26 09:42:13 -0700 |
|---|---|---|
| committer | Sean Christopherson <seanjc@google.com> | 2026-09-11 11:48:14 -0700 |
| commit | 6415d9c4ee19be3816c89974562d67e2c00c8638 (patch) | |
| tree | 3317d27efe2cc7f20c4198d200e0fbfe753ab1f8 /rust/kernel/alloc/kvec/errors.rs | |
| parent | 698b8c88e15914a88f686b552c14c0c5caff3cc7 (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 'rust/kernel/alloc/kvec/errors.rs')
0 files changed, 0 insertions, 0 deletions
