>From: Lu, Guanqun
>Sent: 2009年3月31日 16:55
>Hi Jan,
>
>The point when S3 resumes back, it's running in compat mode.
>But the code doesn't differentiate it, as in
>xen/arch/x86/acpi/wakeup_prot.S.
>Maybe we lose some context during the switches which may
>causes the problem.
One correction here. pCPU is of course in long mode when resuming
from S3 since it happens in Xen. It's current vcpu as a 32bit vcpu with
compatibility context (32bit dom0). There may be some registers only
used in compatibility mode, but kept even when Xen is running in long
mode. However current low level context save/restore across S3
suspend/resume, as you can see, have nothing specific for whether
current context is 32bit vcpu. So we're not sure whether some registers
content specific for compatibility mode get lost (cpu is reset in S3) and
not be recovered by current resume code.
Jan, since you're the No.1 expert in this area, we'd appreciate your
possible suggestions here. :-)
Thanks
Kevin
>
>When it resumes back, hitting '0' on xen serial console gives us:
>
>(XEN) '0' pressed -> dumping Dom0's registers
>(XEN) *** Dumping Dom0 vcpu#0 state: ***
>(XEN) ----[ Xen-3.4-unstable x86_64 debug=y Not tainted ]----
>(XEN) CPU: 0
>(XEN) RIP: 0061:[<00000000c02a9208>]
>(XEN) RFLAGS: 0000000000200246 EM: 0 CONTEXT: pv guest
>(XEN) rax: 00000000000000af rbx: 0000000000000000 rcx:
>00000000bfe7d8e4
>(XEN) rdx: 00000000bfe7d864 rsi: 0000000000000008 rdi:
>0000000000d3cff4
>(XEN) rbp: 00000000bfe7d790 rsp: 00000000c6aa3fe0 r8:
>0000000000000000
>(XEN) r9: 0000000000000000 r10: 0000000000000000 r11:
>0000000000000000
>(XEN) r12: 0000000000000000 r13: 0000000000000000 r14:
>0000000000000000
>(XEN) r15: 0000000000000000 cr0: 000000008005003b cr4:
>00000000000026f0
>(XEN) cr3: 00000000bd6e4000 cr2: 00000000b7fbe000
>(XEN) ds: 007b es: 007b fs: 0000 gs: 0033 ss: 0069 cs: 0061
>(XEN) Guest stack trace from esp=c6aa3fe0:
>(XEN) 00000000 b7f9d405 00000073 00210246 bfe7d790 0000007b
>00000000 00000000
>(XEN) c6aa1080 c02fd6a0 00000000 00000000 00000000 00000000
>ffffffff 00000000
>(XEN) c0126a47 00000000 00000000 00000000 00000000 00000000
>00000000 00000000
>(XEN) ffffffff ffffffbf ffffffff ffffffff 00000000 00000000
>ffffffff ffffffff
>(XEN) ffffffff ffffffff 00000000 00000000 00000000 00000000
>00000000 00000000
>(XEN) ffffffff ffffffff ffffffff ffffffff 00000000 00000000
>ffffffff ffffffff
>(XEN) ffbfffff ffffffff 00000000 00000000 00000000 00000000
>00000000 00000000
>(XEN) fffffeff ffffffff ffffffff ffffffff 00000000 00000000
>ffffffff ffffffff
>(XEN) ffffffff ffffffff 00000000 00000000 00000000 00000000
>00000000 00000000
>(XEN) ffffffff ffffffff ffffffff ffffffff 00000000 00000000
>ffffffff ffffffff
>(XEN) ffffffff ffffffff 00000000 00000000 00000000 00000000
>00000000 00000000
>(XEN) ffffffff ffffffff ffffffff ffffffff 00000000 00000000
>ffffffff ffffffff
>(XEN) bfffffff ffffffff 00000000 00000000 00000000 00000000
>00000000 00000000
>(XEN) fffbffff ffffffff ffefffff ffffffff 00000000 00000000
>ffffffff ffffffff
>(XEN) ff7fffff ffffffff 00000000 00000000 00000000 00000000
>00000000 00000000
>(XEN) ffffffff ffffffff ffffffff ffffffff 00000000 00000000
>ffffffff ffffffff
>(XEN) ffffffff ffffffff 00000000 00000000 00000000 00000000
>00000000 00000000
>(XEN) fff7dfff ffffffff ffffffff ffffffff 00000000 00000000
>ffffffff ffffffff
>(XEN) ffffffff fffffff7 00000000 00000000 00000000 00000000
>00000000 00000000
>(XEN) bfffffff ffffffff ffffffff ffffffff 00000000 00000000
>ffffffff ffffffff
>
>Comparing the eip with the dom0 symbol table,
>0xc02a9208 -> general_protection
>0xc02fd6a0 -> default_exec_domain
>0xc0126a47 -> do_no_restart_syscall
>>From the stack, such invocation chain is observed.
>
>Any idea what's happening there?
>
>And I also dump the MSR just before and after S3, there're no
>difference.
>patch:
>
>diff -r d5ddc782bc49 xen/arch/x86/acpi/power.c
>--- a/xen/arch/x86/acpi/power.c Mon Mar 30 16:48:26 2009 +0100
>+++ b/xen/arch/x86/acpi/power.c Tue Mar 31 12:26:12 2009 +0800
>@@ -42,6 +42,28 @@ struct acpi_sleep_info acpi_sinfo;
>
> void do_suspend_lowlevel(void);
>
>+static void dump_msr_registers(void)
>+{
>+ unsigned long msr;
>+
>+ rdmsrl(MSR_EFER, msr);
>+ printk("<0> EFER: %lx", msr);
>+ rdmsrl(MSR_STAR, msr);
>+ printk("<0> STAR: %lx", msr);
>+ rdmsrl(MSR_LSTAR, msr);
>+ printk("<0> LSTAR: %lx", msr);
>+ rdmsrl(MSR_CSTAR, msr);
>+ printk("<0> CSTAR: %lx", msr);
>+ rdmsrl(MSR_SYSCALL_MASK, msr);
>+ printk("<0> SYSCALL_MASK: %lx", msr);
>+ rdmsrl(MSR_FS_BASE, msr);
>+ printk("<0> FS_BASE: %lx", msr);
>+ rdmsrl(MSR_GS_BASE, msr);
>+ printk("<0> GS_BASE: %lx", msr);
>+ rdmsrl(MSR_SHADOW_GS_BASE, msr);
>+ printk("<0> SH_GS_BASE: %lx", msr);
>+}
>+
> static int device_power_down(void)
> {
> console_suspend();
>@@ -173,6 +195,7 @@ static int enter_state(u32 state)
>
> console_start_sync();
> printk("Entering ACPI S%d state.\n", state);
>+ dump_msr_registers();
>
> local_irq_save(flags);
> spin_debug_disable();
>@@ -208,6 +231,7 @@ static int enter_state(u32 state)
> device_power_up();
>
> printk(XENLOG_INFO "Finishing wakeup from ACPI S%d
>state.\n", state);
>+ dump_msr_registers();
>
> if ( (state == ACPI_STATE_S3) && error )
> panic("Memory integrity was lost on resume (%d)\n", error);
>
>the result is:
>[before] (XEN) EFER: d01<0> STAR: e023e00800000000<0> LSTAR:
>ffff828c8029b000<0> CSTAR: ffff828c8029b080<0> SYSCALL_MASK:
>34700<0> FS_BASE: 0<0> GS_BASE: b7f4a6c0<0> SH_GS_BASE: 0
>[after] (XEN) EFER: d01<0> STAR: e023e00800000000<0> LSTAR:
>ffff828c8029b000<0> CSTAR: ffff828c8029b080<0> SYSCALL_MASK:
>34700<0> FS_BASE: 0<0> GS_BASE: b7f4a6c0<0> SH_GS_BASE: 0
>
>They're the same.
>
>And aslo I dump GDT, IDT, LDT and TR register and tss struct,
>there are no difference seen.
>
>
>So can you give some advice some more registers should be dumped?
>Or maybe our S3 code doesn't take the 32dom0 into
>consideration from the beginning, is there anyway to fix this?
>
>
>
>Thanks!
>
>--
>Guanqun
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@xxxxxxxxxxxxxxxxxxx
>http://lists.xensource.com/xen-devel
>_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home