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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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, <george.dunlap@xxxxxxxxxx> 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
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel