RE: [Xen-devel] [PATCH] small adjustment to asm constraints for c/s19400

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

>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