All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Ivan Orlov <ivan.orlov0322@gmail.com>
Cc: Ivan Orlov <iorlov@amazon.com>,
	bp@alien8.de, dave.hansen@linux.intel.com,  mingo@redhat.com,
	pbonzini@redhat.com, shuah@kernel.org, tglx@linutronix.de,
	 hpa@zytor.com, kvm@vger.kernel.org,
	linux-kernel@vger.kernel.org,  linux-kselftest@vger.kernel.org,
	x86@kernel.org, pdurrant@amazon.co.uk,  dwmw@amazon.co.uk
Subject: Re: [PATCH v2 3/6] KVM: VMX: Handle vectoring error in check_emulate_instruction
Date: Wed, 11 Dec 2024 17:01:07 -0800	[thread overview]
Message-ID: <Z1o1013dUex8w9hK@google.com> (raw)
In-Reply-To: <2b75550c-0dc7-4bcc-ac60-9ad4402c17f8@gmail.com>

On Wed, Dec 11, 2024, Ivan Orlov wrote:
> On 12/11/24 18:15, Sean Christopherson wrote:
> > Hmm, this should probably be "pf_mmio", not just "mmio".  E.g. if KVM is emulating
> > large swaths of guest code because unrestricted guest is disabled, then can end up
> > emulating an MMIO access for "normal" emulation.
> > 
> > Hmm, actually, what if we go with this?
> > 
> >    static inline bool kvm_can_emulate_event_vectoring(int emul_type)
> >    {
> > 	return !(emul_type & EMULTYPE_PF) ||
> > 	       (emul_type & EMULTYPE_WRITE_PF_TO_SP);
> >    }
> > 
> 
> Hm, by the way, what is the desired behaviour if EMULTYPE_ALLOW_RETRY_PF is
> set? Is it correct that we return an internal error if it is set during
> vectoring? Or KVM may try to unprotect the page and re-execute?

Heh, it's sneaky, but EMULTYPE_ALLOW_RETRY_PF can be set if and only if
RET_PF_WRITE_PROTECTED is set.  Hmm, that makes me think we should do the below
(EMULTYPE_WRITE_PF_TO_SP was a recent addition).

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 2e713480933a..de5f6985d123 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -9077,7 +9077,7 @@ int x86_emulate_instruction(struct kvm_vcpu *vcpu, gpa_t cr2_or_gpa,
 
        if ((emulation_type & EMULTYPE_ALLOW_RETRY_PF) &&
            (WARN_ON_ONCE(is_guest_mode(vcpu)) ||
-            WARN_ON_ONCE(!(emulation_type & EMULTYPE_PF))))
+            WARN_ON_ONCE(!(emulation_type & EMULTYPE_WRITE_PF_TO_SP))))
                emulation_type &= ~EMULTYPE_ALLOW_RETRY_PF;
 
        r = kvm_check_emulate_insn(vcpu, emulation_type, insn, insn_len);

That said, let me get back to you on this when my brain is less tired.  I'm not
sure emulating when an exit occurred during event delivery is _ever_ correct.

> If so, we may need something like
> 
> static inline bool kvm_can_emulate_event_vectoring(int emul_type)
> {
> 	return !(emul_type & EMULTYPE_PF) ||
> 	       (emul_type & ~(EMULTYPE_PF));
> }
> 
> So it returns true if EMULTYPE_PF is not set or if it's not the only set
> bit.



  reply	other threads:[~2024-12-12  1:01 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-11 10:27 [PATCH v2 0/6] Enhance event delivery error handling Ivan Orlov
2024-11-11 10:27 ` [PATCH v2 1/6] KVM: x86: Add function for vectoring error generation Ivan Orlov
2024-12-11 18:02   ` Sean Christopherson
2024-11-11 10:27 ` [PATCH v2 2/6] KVM: x86: Add emulation status for vectoring during MMIO Ivan Orlov
2024-11-11 10:27 ` [PATCH v2 3/6] KVM: VMX: Handle vectoring error in check_emulate_instruction Ivan Orlov
2024-12-11 18:15   ` Sean Christopherson
2024-12-11 22:05     ` Ivan Orlov
2024-12-11 23:12     ` Ivan Orlov
2024-12-12  1:01       ` Sean Christopherson [this message]
2024-12-12 16:41         ` Ivan Orlov
2024-12-12 19:42           ` Sean Christopherson
2024-12-13 17:38             ` Ivan Orlov
2024-12-13 20:09               ` Sean Christopherson
2024-11-11 10:27 ` [PATCH v2 4/6] KVM: SVM: Handle MMIO during vectroing error Ivan Orlov
2024-12-11 18:16   ` Sean Christopherson
2024-11-11 10:27 ` [PATCH v2 5/6] selftests: KVM: extract lidt into helper function Ivan Orlov
2024-11-11 10:27 ` [PATCH v2 6/6] selftests: KVM: Add test case for MMIO during vectoring Ivan Orlov
2024-12-11 18:19   ` Sean Christopherson
2024-12-12 17:11     ` Ivan Orlov
2024-12-11 18:20 ` [PATCH v2 0/6] Enhance event delivery error handling Sean Christopherson
2024-12-11 21:45   ` Ivan Orlov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Z1o1013dUex8w9hK@google.com \
    --to=seanjc@google.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=dwmw@amazon.co.uk \
    --cc=hpa@zytor.com \
    --cc=iorlov@amazon.com \
    --cc=ivan.orlov0322@gmail.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=pdurrant@amazon.co.uk \
    --cc=shuah@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.