Messages in this thread | | | Date | Wed, 6 Mar 2024 14:22:17 +1300 | Subject | Re: [PATCH 09/16] KVM: x86/mmu: Move private vs. shared check above slot validity checks | From | "Huang, Kai" <> |
| |
On 6/03/2024 1:38 pm, Sean Christopherson wrote: > On Wed, Mar 06, 2024, Kai Huang wrote: >> >> >> On 28/02/2024 3:41 pm, Sean Christopherson wrote: >>> Prioritize private vs. shared gfn attribute checks above slot validity >>> checks to ensure a consistent userspace ABI. E.g. as is, KVM will exit to >>> userspace if there is no memslot, but emulate accesses to the APIC access >>> page even if the attributes mismatch. >> >> IMHO, it would be helpful to explicitly say that, in the later case (emulate >> APIC access page) we still want to report MEMORY_FAULT error first (so that >> userspace can have chance to fixup, IIUC) instead of emulating directly, >> which will unlikely work. > > Hmm, it's not so much that emulating directly won't work, it's that KVM would be > violating its ABI. Emulating APIC accesses after userspace converted the APIC > gfn to private would still work (I think), but KVM's ABI is that emulated MMIO > is shared-only.
But for (at least) TDX guest I recall we _CAN_ allow guest's MMIO to be mapped as private, right? The guest is supposed to get a #VE anyway?
Perhaps I am missing something -- I apologize if this has already been discussed.
> > FWIW, I doubt there's a legitmate use case for converting the APIC gfn to private, > this is purely to ensure KVM has simple, consistent rules for how private vs. > shared access work.
Again I _think_ for TDX APIC gfn can be private? IIUC virtualizing APIC is done by the TDX module, which injects #VE to guest when emulation is required.
| |