On Mon, Sep 14, 2020 at 03:15:23PM -0500, Tom Lendacky wrote: > From: Tom Lendacky <thomas.lendacky@xxxxxxx> > > 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 <thomas.lendacky@xxxxxxx> > --- > 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. > + > /* > * 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 >
