[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2b75550c-0dc7-4bcc-ac60-9ad4402c17f8@gmail.com>
Date: Wed, 11 Dec 2024 23:12:29 +0000
From: Ivan Orlov <ivan.orlov0322@...il.com>
To: Sean Christopherson <seanjc@...gle.com>, Ivan Orlov <iorlov@...zon.com>
Cc: bp@...en8.de, dave.hansen@...ux.intel.com, mingo@...hat.com,
pbonzini@...hat.com, shuah@...nel.org, tglx@...utronix.de, hpa@...or.com,
kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-kselftest@...r.kernel.org, x86@...nel.org, pdurrant@...zon.co.uk,
dwmw@...zon.co.uk
Subject: Re: [PATCH v2 3/6] KVM: VMX: Handle vectoring error in
check_emulate_instruction
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?
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.
--
Kind regards,
Ivan Orlov
Powered by blists - more mailing lists