[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [xen-unstable bisection] complete test-amd64-amd64-qemuu-nested-amd



On 23/02/2017 22:54, osstest service owner wrote:
> *** Found and reproduced problem changeset ***
>
>   Bug is in tree:  xen git://xenbits.xen.org/xen.git
>   Bug introduced:  49de10f3c1718bb952f4b075d07f37eb9f605b2b
>   Bug not present: 38b48605f3693e950bb4155ea8dac6614d796c2b
>   Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/106036/
>
>
>   commit 49de10f3c1718bb952f4b075d07f37eb9f605b2b
>   Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>   Date:   Wed Nov 2 14:36:49 2016 +0000
>   
>       x86/hvm: Don't raise #GP behind the emulators back for MSR accesses
>

Jan: your gut feel was spot on.

This time,

Feb 23 22:30:29.269782 (XEN) d3v0: Invalid EFER update: 0x1d01 -> 0x3901
- LMSLE without support
Feb 23 22:30:52.069589 (XEN) hvm.c:1616:d3v0 All CPUs offline --
powering off.

From the L1 serial log
(http://logs.test-lab.xenproject.org/osstest/logs/106036/test-amd64-amd64-qemuu-nested-amd/nocera1---var-log-xen-osstest-serial-l1.guest.osstest.log)

(XEN) mwait-idle: does not run on family 16 model 8
(XEN) HVM: ASIDs enabled.
(XEN) *** DOUBLE FAULT ***
(XEN) ----[ Xen-4.9-unstable  x86_64  debug=y   Not tainted ]----
(XEN) CPU:    0
(XEN) RIP:    e008:[<ffff82d0801ed997>] svm.c#svm_cpu_up+0x1ba/0x21f
(XEN) RFLAGS: 0000000000010256   CONTEXT: hypervisor
(XEN) rax: 0000000000003d01   rbx: ffff82d080336080   rcx: 00000000c0000080
(XEN) rdx: 0000000000000000   rsi: 0000000000001d01   rdi: 0000000000000000
(XEN) rbp: ffff82d080317d98   rsp: ffff82d080317d88   r8:  ffff8300bf55c000
(XEN) r9:  0000000000000000   r10: ffff82d080317d28   r11: 00000000ffffffff
(XEN) r12: ffff82d0802d9cc0   r13: ffff82d080317fff   r14: 0000000000000000
(XEN) r15: ffff82d08034ba80   cr0: 000000008005003b   cr4: 00000000000006e0
(XEN) cr3: 00000000bf505000   cr2: 0000000000000000
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Valid stack range: ffff82d080316000-ffff82d080318000,
sp=ffff82d080317d88, tss.esp0=ffff82d080317fc0
(XEN) No stack overflow detected. Skipping stack trace.
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) DOUBLE FAULT -- system shutdown
(XEN) ****************************************
(XEN)
(XEN) Manual reset required ('noreboot' specified)

The problem is that hvm_msr_write_intercept() calls hvm_set_efer() and
has an escape path which skipped the previous gp_fault path which I
edited.  hvm_set_efer() raises #GP itself, returns X86EMUL_EXCEPTION,
which causes svm_do_msr_access() to raise #GP a second time.  (It also
means that across a XenServer extended test, not a single VM ever make a
write to EFER which faulted...)

I already have a task on my TODO list to modify hvm_set_cr$N() & friends
to avoid raising exceptions behind the emulators back, which I believe
is the final task to fixing:

    /*
     * TODO: Make this true:
     *
    ASSERT(ctxt->event_pending == (rc == X86EMUL_EXCEPTION));
     *
     * Some codepaths still raise exceptions behind the back of the ...


Looks like this has just jumped to the top of my priority list.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.