From: Sean Christopherson <seanjc@google.com>
To: Yahya Sohail <ysohail@cs.utexas.edu>
Cc: kvm@vger.kernel.org
Subject: Re: KVM_EXIT_FAIL_ENTRY with hardware_entry_failure_reason = 7
Date: Thu, 27 Jul 2023 09:52:53 -0700 [thread overview]
Message-ID: <ZMKg5WosmBu78Vgv@google.com> (raw)
In-Reply-To: <7d4a5084-5e1e-22dd-c203-99f46850145a@cs.utexas.edu>
On Wed, Jul 26, 2023, Yahya Sohail wrote:
> On 7/26/23 14:51, Sean Christopherson wrote:
> > On Wed, Jul 26, 2023, Yahya Sohail wrote:
> > > On 7/26/23 12:17, Sean Christopherson wrote:
> > > I do know that the emulator I'm copying state from likely doesn't consider
> > > all bits in the control fields, so it's possible that they're in an invalid
> > > state. When I ran the model before with the value for cr0 copied out of the
> > > emulator I also got KVM_EXIT_FAIL_ENTRY, but with a different value for
> > > hardware_entry_failure_reason = 0x80000021. I fixed this by changing the
> > > value of cr0 to be (hopefully) valid.
> >
> > What were the before and after values of CR0?
>
> Before, CR0 was 0x80000000.
Yeah, CR0.PG=1 with CR0.PE=0 (paging without protected mode) is invalid. But
KVM fails to reject this combination from userspace without the series/patch I
linked earlier. That would explain why the VM-Enter fails instead of KVM rejecting
KVM_SET_SREGS.
https://lore.kernel.org/all/20230613203037.1968489-1-seanjc@google.com
> It appears the paging bit was not set even after
> I "fixed" cr0. I have now made sure the paging bit and the fixed bits are
> properly set in CR0. CR0 is now equal to 0x8393870b
How did you get that value? AFAICT, it's not outright illegal, but only because
the CPU ignores reserved bits in CR0[31:0], as opposed to rejecting them.
> That being said, I'm still not sure how to go about debugging the
> VM_EXIT_FAIL_ENTRY with hardware_entry_failure_reason = 0x80000021. The
> entry in the tracepoint log (see above) of L0 (when running the VM as L2)
> does not seem to be very helpful (unlike the invalid CR0 messages I got
> before when CR0 was invalid). Is there any more information that can be
> gleaned from this log entry?
Probably not.
> Any other way to get more information as to what piece of state is invalid?
Enable /sys/module/kvm_intel/parameters/dump_invalid_vmcs, then KVM will print
out most (all?) VMCS fields on the failed VM-Entry. From there you'll have to
hunt through guest state to figure out which fields, or combinations of fields,
is invalid.
next prev parent reply other threads:[~2023-07-27 16:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-26 16:35 KVM_EXIT_FAIL_ENTRY with hardware_entry_failure_reason = 7 Yahya Sohail
2023-07-26 17:17 ` Sean Christopherson
2023-07-26 19:16 ` Yahya Sohail
2023-07-26 19:51 ` Sean Christopherson
2023-07-26 22:14 ` Yahya Sohail
2023-07-27 16:52 ` Sean Christopherson [this message]
2023-07-28 17:45 ` Yahya Sohail
2023-08-02 19:04 ` Sean Christopherson
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=ZMKg5WosmBu78Vgv@google.com \
--to=seanjc@google.com \
--cc=kvm@vger.kernel.org \
--cc=ysohail@cs.utexas.edu \
/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