All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: unlisted-recipients:; (no To-header on input)
Cc: Kashyap Chamarthy <kashyap.cv@gmail.com>,
	Gleb Natapov <gleb@redhat.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: Re: [nvmx testing, linux on linux] Disabling EPT in L1 renders L2 stuck on boot
Date: Tue, 08 Oct 2013 16:48:05 +0200	[thread overview]
Message-ID: <52541B25.504@redhat.com> (raw)
In-Reply-To: <52540298.2030807@redhat.com>

Il 08/10/2013 15:03, Paolo Bonzini ha scritto:
> Il 08/10/2013 07:38, Kashyap Chamarthy ha scritto:
>> On Mon, Oct 7, 2013 at 6:29 PM, Kashyap Chamarthy <kashyap.cv@gmail.com> wrote:
>>> Gleb, so I just did a trace of KVM MMU to try to understand why L2 is
>>> stuck with shadow on EPT
>>
>> Paolo, were you able to reproduce this again? Yesterday, on #qemu you
>> mentioned you'll test it again :-)
> 
> Yes, I could reproduce it too.
> 
>>> Boot L2 guest:
> 
> Here L2 doesn't go past the second instruction.  It gets a page fault
> even though the spte is present, and KVM then loops on a page fault
> for 0xfe05b.
> 
> Here is an annotated function_graph trace of L1.
> 
> It's possible that L0 is injecting the same fault repeatedly, i.e.
> they are not different faults from the processor.  I'll get an L0
> trace next.
> 

The L0 trace is not particularly helpful (and probably would not be
particularly helpful even if there were a specific tracepoint for
VMREAD):

287.534156: kvm_exit:             reason VMRESUME rip 0xffffffffa021f8d1 info 0 0
287.534160: kvm_mmu_get_page:     sp gfn 0 0/4 q0 direct --- !pge !nxe root 0sync
287.534161: kvm_entry:            vcpu 0
287.534162: kvm_exit:             reason EXCEPTION_NMI rip 0xe05b info fe05b 80000b0e
287.534170: kvm_mmu_get_page:     sp gfn 0 0/4 q0 direct --- !pge !nxe root 0sync
287.534171: kvm_entry:            vcpu 0
287.534172: kvm_exit:             reason VMREAD rip 0xffffffffa021f97d info 0 0
287.534173: kvm_entry:            vcpu 0
287.534174: kvm_exit:             reason VMREAD rip 0xffffffffa021f996 info 0 0
287.534174: kvm_entry:            vcpu 0
287.534175: kvm_exit:             reason VMREAD rip 0xffffffffa021f9b5 info 0 0
287.534175: kvm_entry:            vcpu 0
287.534177: kvm_exit:             reason VMREAD rip 0xffffffffa021b377 info 0 0
287.534177: kvm_entry:            vcpu 0
287.534178: kvm_exit:             reason VMREAD rip 0xffffffffa021b5ce info 0 0
287.534179: kvm_entry:            vcpu 0
287.534180: kvm_exit:             reason VMREAD rip 0xffffffffa0222c95 info 0 0
287.534180: kvm_entry:            vcpu 0
287.534181: kvm_exit:             reason VMREAD rip 0xffffffffa0222e1c info 0 0
287.534182: kvm_entry:            vcpu 0
287.534185: kvm_exit:             reason MSR_READ rip 0xffffffff8104c2b6 info 0 0
287.534185: kvm_msr:              msr_read 1d9 = 0x0
287.534185: kvm_entry:            vcpu 0

And then it repeats:

287.534186: kvm_exit:             reason VMRESUME rip 0xffffffffa021f8d1 info 0 0
287.534191: kvm_mmu_get_page:     sp gfn 0 0/4 q0 direct --- !pge !nxe root 0sync
287.534192: kvm_entry:            vcpu 0

Trying to add function_graph loses a lot of events.

Paolo

  reply	other threads:[~2013-10-08 14:48 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-04  8:31 [nvmx testing, linux on linux] Disabling EPT in L1 renders L2 stuck on boot Kashyap Chamarthy
2013-10-04  9:33 ` Kashyap Chamarthy
2013-10-04  9:39   ` Gleb Natapov
2013-10-04 12:33     ` Kashyap Chamarthy
2013-10-04 13:05       ` Gleb Natapov
2013-10-04 13:08         ` Gleb Natapov
2013-10-04 15:28           ` Kashyap Chamarthy
2013-10-07 12:59             ` Kashyap Chamarthy
2013-10-07 15:18               ` Gleb Natapov
2013-10-08  5:38               ` Kashyap Chamarthy
2013-10-08 13:03                 ` Paolo Bonzini
2013-10-08 14:48                   ` Paolo Bonzini [this message]
2013-10-09  6:22                     ` Kashyap Chamarthy
2013-10-09  8:16                       ` Gleb Natapov
2013-10-09 17:46                         ` Kashyap Chamarthy

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=52541B25.504@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=gleb@redhat.com \
    --cc=kashyap.cv@gmail.com \
    --cc=kvm@vger.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.