From: Sean Christopherson <seanjc@google.com>
To: Weijiang Yang <weijiang.yang@intel.com>
Cc: pbonzini@redhat.com, kvm@vger.kernel.org
Subject: Re: [kvm-unit-tests PATCH] x86:VMX: Fixup for VMX test failures
Date: Thu, 3 Aug 2023 10:11:32 -0700 [thread overview]
Message-ID: <ZMvfxFgHlWMyrvbq@google.com> (raw)
In-Reply-To: <a5bc09c4-cc24-1e70-b70f-dbbce4251717@intel.com>
On Thu, Aug 03, 2023, Weijiang Yang wrote:
> On 8/3/2023 3:43 AM, Sean Christopherson wrote:
> > > diff --git a/x86/vmx_tests.c b/x86/vmx_tests.c
> > > index 7952ccb..b6d4982 100644
> > > --- a/x86/vmx_tests.c
> > > +++ b/x86/vmx_tests.c
> > > @@ -4173,7 +4173,10 @@ static void test_invalid_event_injection(void)
> > > ent_intr_info);
> > > vmcs_write(GUEST_CR0, guest_cr0_save & ~X86_CR0_PE & ~X86_CR0_PG);
> > > vmcs_write(ENT_INTR_INFO, ent_intr_info);
> > > - test_vmx_invalid_controls();
> > > + if (basic.errcode)
> > > + test_vmx_valid_controls();
> > > + else
> > > + test_vmx_invalid_controls();
> > This is wrong, no? The consistency check is only skipped for PM, the above CR0.PE
> > modification means the target is RM.
> I think this case is executed with !CPU_URG, so RM is "converted" to PM because we
> have below in KVM:
> bool urg = nested_cpu_has2(vmcs12,
> SECONDARY_EXEC_UNRESTRICTED_GUEST);
> bool prot_mode = !urg || vmcs12->guest_cr0 & X86_CR0_PE;
> ...
> if (!prot_mode || intr_type != INTR_TYPE_HARD_EXCEPTION ||
> !nested_cpu_has_no_hw_errcode(vcpu)) {
> /* VM-entry interruption-info field: deliver error code */
> should_have_error_code =
> intr_type == INTR_TYPE_HARD_EXCEPTION &&
> prot_mode &&
> x86_exception_has_error_code(vector);
> if (CC(has_error_code != should_have_error_code))
> return -EINVAL;
> }
>
> so on platform with basic.errcode == 1, this case passes.
Huh. I get the logic, but IMO based on the SDM, that's a ucode bug that got
propagated into KVM (or an SDM bug, which is my bet for how this gets treated).
I verified HSW at least does indeed generate VM-Fail and not VM-Exit(INVALID_STATE),
so it doesn't appear that KVM is making stuff (for once). Either that or I'm
misreading the SDM (definite possibility), but the only relevant condition I see is:
bit 0 (corresponding to CR0.PE) is set in the CR0 field in the guest-state area
I don't see anything in the SDM that states the CR0.PE is assumed to be '1' for
consistency checks when unrestricted guest is disabled.
Can you bug a VMX architect again to get clarification, e.g. to get an SDM update?
Or just point out where I missed something in the SDM, again...
next prev parent reply other threads:[~2023-08-03 17:11 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-20 11:58 [kvm-unit-tests PATCH] x86:VMX: Fixup for VMX test failures Yang Weijiang
2023-08-02 19:43 ` Sean Christopherson
2023-08-03 5:56 ` Yang, Weijiang
2023-08-03 17:11 ` Sean Christopherson [this message]
2023-08-04 2:07 ` Yang, Weijiang
2023-08-24 7:25 ` Yang, Weijiang
2023-08-24 16:18 ` Sean Christopherson
2023-08-24 20:47 ` Neiger, Gil
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=ZMvfxFgHlWMyrvbq@google.com \
--to=seanjc@google.com \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=weijiang.yang@intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox