On 22/05/18 16:25, George Dunlap wrote: > On 05/22/2018 03:50 PM, George Dunlap wrote: >> On 05/22/2018 03:43 PM, George Dunlap wrote: >>> On 05/22/2018 03:37 PM, Andrew Cooper wrote: >>>> On 22/05/18 14:48, George Dunlap wrote: >>>>> On 05/22/2018 02:40 PM, Jan Beulich wrote: >>>>>>>>> On 22.05.18 at 15:35, <[email protected]> wrote: >>>>>>> --- a/xen/arch/x86/acpi/power.c >>>>>>> +++ b/xen/arch/x86/acpi/power.c >>>>>>> @@ -33,6 +33,8 @@ >>>>>>> >>>>>>> uint32_t system_reset_counter = 1; >>>>>>> >>>>>>> +static bool __read_mostly opt_fake_s3 = false; >>>>>> With the typo in the title (wants to be acpi_sleep) corrected >>>>> Oops -- I can fix this on check-in (once the development window opens). >>>> If this patch is necessary, or at least a useful aid to track down an S3 >>>> bug in Xen 4.11, I vote for its inclusion. >>>> >>>> As far as the change itself goes, it is very simple, with a minimal >>>> change of any unintended side effects. >>>> >>>> CC'ing the RM for his decision on the subject. >>> Using `rtcwake -s 10 -m mem`, the only difference I've seen between >>> suspend with this patch and without is that it doesn't actually sleep >>> for 10 seconds -- not surprising, as it was never asleep. :-) >> 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. > With your code dump patch (sorry for the wrapping): > > (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: ffffc900402040d8 rbx: 0000000000000000 rcx: 0000000000000003 > > (XEN) rdx: 0000000000000000 rsi: 0000000000000000 rdi: 0000000000000000 > > (XEN) rbp: 000036ffbfdfbf07 rsp: ffffc90040204000 r8: 0000000000000000 > > (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 > > (XEN) r12: 0000000000000000 r13: 0000000000000000 r14: ffffc90040207fff > > (XEN) r15: 0000000000000000 cr0: 000000008005003b cr4: 0000000000002660 > > (XEN) cr3: 000000019200a000 cr2: ffffc90040203ff8 > > (XEN) fsb: 00007f800083d700 gsb: ffff88003dc40000 gss: 0000000000000000 > > (XEN) ds: 002b es: 002b fs: 0000 gs: 0000 ss: e010 cs: e008 > > (XEN) Xen code around <ffff82d080378964> (handle_exception+0x9c/0xff): > > (XEN) 00 f3 90 0f ae e8 eb f9 <e8> 07 00 00 00 f3 90 0f ae e8 eb f9 83 > e9 01 75
Ok - this is in the middle of the RSB loop... > > (XEN) Current stack base ffffc90040200000 differs from expected > ffff8300dfa80000 > > (XEN) Valid stack range: ffffc90040206000-ffffc90040208000, > sp=ffffc90040204000, tss.rsp0=ffff8300dfa87fa0 ...and we've got a stack pointer which looks to be on the base of the guard page, which will explain why we are seeing a double fault - #PF trying to push the return value, and a second #PF trying to push the exception frame. The question is, where are we getting this dodgy stack pointer from. We've executed most of the RSB loop, with the value in %rax being the original stack pointer which will be restored at the end of the loop. ~Andrew _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
