On Mon, Apr 15, 2024, Rick P Edgecombe wrote: > On Mon, 2024-04-15 at 14:17 -0700, Sean Christopherson wrote: > > > But doesn't the fault handler need the vCPU state? > > > > Ignoring guest MTRRs, which will hopefully soon be a non-issue, no. There are > > only six possible roots if TDP is enabled: > > > > 1. 4-level !SMM !guest_mode > > 2. 4-level SMM !guest_mode > > 3. 5-level !SMM !guest_mode > > 4. 5-level SMM !guest_mode > > 5. 4-level !SMM guest_mode > > 6. 5-level !SMM guest_mode > > > > 4-level vs. 5-level is a guest MAXPHYADDR thing, and swapping the MMU > > eliminates the SMM and guest_mode issues. If there is per-vCPU state that > > makes its way into the TDP page tables, then we have problems, because it > > means that there is per-vCPU state in per-VM structures that isn't > > accounted for. > > > > There are a few edge cases where KVM treads carefully, e.g. if the fault is > > to the vCPU's APIC-access page, but KVM manually handles those to avoid > > consuming per-vCPU state. > > > > That said, I think this option is effectively 1b, because dropping the SMM > > vs. guest_mode state has the same uAPI problems as forcibly swapping the > > MMU, it's just a different way of doing so. > > > > The first question to answer is, do we want to return an error or > > "silently" install mappings for !SMM, !guest_mode. And so this option > > becomes relevant only _if_ we want to unconditionally install mappings for > > the 'base" mode. > > Ah, I thought there was some logic around CR0.CD. There is, but it's hopefully going the way of the dodo, along with full MTRR virtualization: https://lore.kernel.org/all/20240309010929.1403984-1-seanjc@xxxxxxxxxx
