Re: [Xen-devel] [PATCH v2] xen: Add acpu_sleep=s3_fake command-line option for testing

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 22.05.18 at 16:50, <george.dunlap@xxxxxxxxxx> wrote:
> In fact, with `s3_fake` enabled, Xen just hangs when XPTI / BTI are
> enabled; but with it disabled, I actually get a stack trace.  Serial
> output and xen-syms.map attached.

Interesting (not sure if I simply didn't pay attention before):

(XEN) *** DOUBLE FAULT ***
(XEN) ----[ Xen-4.11-rc  x86_64  debug=y   Not tainted ]----
(XEN) CPU:    0
(XEN) RIP:    e008:[<ffff82d080378964>] handle_exception+0x9c/0xff
(XEN) RFLAGS: 0000000000010006   CONTEXT: hypervisor
(XEN) rax: ffffc900402140b8   rbx: 0000000000000000   rcx: 0000000000000005
(XEN) rdx: 0000000000000000   rsi: 0000000000000000   rdi: 0000000000000000
(XEN) rbp: 000036ffbfdebf27   rsp: ffffc90040214000   r8:  0000000000000000
(XEN) r9:  0000000000000000   r10: 0000000000000000   r11: 0000000000000000
(XEN) r12: 0000000000000000   r13: 0000000000000000   r14: ffffc90040217fff
(XEN) r15: 0000000000000000   cr0: 000000008005003b   cr4: 0000000000002660
(XEN) cr3: 000000019200a000   cr2: ffffc90040213ff8
(XEN) fsb: 0000000000000000   gsb: ffff88003dcc0000   gss: 0000000000000000
(XEN) ds: 002b   es: 002b   fs: 8e00   gs: 87c1   ss: e010   cs: e008
(XEN) Current stack base ffffc90040210000 differs from expected ffff8300dfa80000
(XEN) Valid stack range: ffffc90040216000-ffffc90040218000, 
sp=ffffc90040214000, tss.rsp0=ffff8300dfa87fa0

We're in handle_exception, but on a guest (presumably Dom0) kernel stack.

The selector values in FS and GS are also highly suspicious.

I can't explain either for the moment, as bypassing do_suspend_lowlevel()
ought to mean that none of TR, FS, or GS get touched at all. Looking at
the flow of execution I wonder though whether your opt_fake_s3 wasn't
better placed further down the call tree, e.g. in acpi_enter_sleep_state().
That would cause more of the involved code path to be tested.

Btw, so far you've only mentioned XPTI and BTI collectively enabled or
disabled. Have you tried with one of them on and the other off?

> (The mail server doesn't seem to want the full xen-syms file -- let me
> know if you need it and I'll figure out how to get it to you.)

While in general I would have considered this useful (or even necessary),
in order to be able to work out at what exact insn the #DF occurred, with
the above I'm no longer certain this matters - things must have gone
wrong much earlier.

I guess what we really need is a raw dump of whatever stack we're on
currently, so we have a chance to reconstruct at least recent execution
history (like what exception has lead us into handle_exception). Once
again - for now I'm completely lost as to us having managed to switch to
a non-hypervisor stack in hypervisor context (or to run guest code with
hypervisor CS/SS).

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel