On 9/14/20 4:33 PM, Sean Christopherson wrote: > On Mon, Sep 14, 2020 at 03:15:23PM -0500, Tom Lendacky wrote: >> From: Tom Lendacky <[email protected]> >> >> When a guest is running as an SEV-ES guest, it is not possible to emulate >> MMIO. Add support to prevent trying to perform MMIO emulation. >> >> Signed-off-by: Tom Lendacky <[email protected]> >> --- >> arch/x86/kvm/mmu/mmu.c | 7 +++++++ >> 1 file changed, 7 insertions(+) >> >> diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c >> index a5d0207e7189..2e1b8b876286 100644 >> --- a/arch/x86/kvm/mmu/mmu.c >> +++ b/arch/x86/kvm/mmu/mmu.c >> @@ -5485,6 +5485,13 @@ int kvm_mmu_page_fault(struct kvm_vcpu *vcpu, gpa_t >> cr2_or_gpa, u64 error_code, >> if (!mmio_info_in_cache(vcpu, cr2_or_gpa, direct) && >> !is_guest_mode(vcpu)) >> emulation_type |= EMULTYPE_ALLOW_RETRY_PF; >> emulate: >> + /* >> + * When the guest is an SEV-ES guest, emulation is not possible. Allow >> + * the guest to handle the MMIO emulation. >> + */ >> + if (vcpu->arch.vmsa_encrypted) >> + return 1; > > A better approach is to refactor need_emulation_on_page_fault() (the hook > that's just out of sight in this patch) into a more generic > kvm_x86_ops.is_emulatable() so that the latter can be used to kill emulation > everywhere, and for other reasons. E.g. TDX obviously shares very similar > logic, but SGX also adds a case where KVM can theoretically end up in an > emulator path without the ability to access the necessary guest state. > > I have exactly such a prep patch (because SGX and TDX...), I'll get it posted > in the next day or two.
Sounds good. I'll check it out when it's posted. Thanks, Tom > >> + >> /* >> * On AMD platforms, under certain conditions insn_len may be zero on >> #NPF. >> * This can happen if a guest gets a page-fault on data access but the >> HW >> -- >> 2.28.0 >>
