Re: [Xen-devel] Test for osstest, features used in Qubes OS

[Simon Gaiser <simon@xxxxxxxxxxxxxxxxxxxxxx>]

George Dunlap:
> On Fri, May 18, 2018 at 5:19 PM, Marek Marczykowski
> <marmarek@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>> On Fri, May 18, 2018 at 09:54:37AM -0600, Jan Beulich wrote:
>>>>>> On 18.05.18 at 17:33, <marmarek@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>>>> Yes, I'm happy to help with that. As I've said, the basic test is very
>>>> simple (rtcwake command) and already very useful. The fact that it is(?)
>>>> broken on staging doesn't make it easier,
>>>
>>> Details on the breakage would be appreciated (on a separate thread),
>>> unless you plan to address it yourself. I recall Simon(?) mentioning this as
>>> well, but also not providing sufficient data to consider looking into it
>>> (perhaps simply because it wasn't easy to obtain useful data, as
>>> frequently is the case with S3 resume). I think it would be nice if we could
>>> release 4.11 without a regression here.
>>
>> I only know that Simon have tested it and it fails. Cc'ing him.

I run into the same problem as George below (see [1] for the inital
report).

> Well I tried it with a post-RC 4.11 and got the below.  I haven't done
> any investigation.
> 
>  -George
> 
[...]
> (XEN) *** DOUBLE FAULT ***
> (XEN) ----[ Xen-4.11-rc  x86_64  debug=y   Not tainted ]----
> (XEN) CPU:    0
> (XEN) RIP:    e008:[<ffff82d080377944>] handle_exception+0x9c/0xf7
> (XEN) RFLAGS: 0000000000010006   CONTEXT: hypervisor
> (XEN) rax: ffffc900422480b8   rbx: 0000000000000000   rcx: 0000000000000005
> (XEN) rdx: 0000000000000000   rsi: 0000000000000000   rdi: 0000000000000000
> (XEN) rbp: 000036ffbddb7f27   rsp: ffffc90042248000   r8:  0000000000000000
> (XEN) r9:  0000000000000000   r10: 0000000000000000   r11: 0000000000000000
> (XEN) r12: 0000000000000000   r13: 0000000000000000   r14: ffffc9004224ffff
> (XEN) r15: 0000000000000000   cr0: 000000008005003b   cr4: 00000000000026e0
> (XEN) cr3: 000000018a100000   cr2: ffffc90042247ff8
> (XEN) fsb: 00007f6242d95700   gsb: ffff88003dc00000   gss: 0000000000000000
> (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e010   cs: e008
> (XEN) Current stack base ffffc90042248000 differs from expected 
> ffff8300dfa80000
> (XEN) Valid stack range: ffffc9004224e000-ffffc90042250000,
> sp=ffffc90042248000, tss.rsp0=ffff8300dfa87fa0
> (XEN) No stack overflow detected. Skipping stack trace.
> (XEN)
> (XEN) ****************************************
> (XEN) Panic on CPU 0:
> (XEN) DOUBLE FAULT -- system shutdown
> (XEN) ****************************************
> (XEN)
> (XEN) Reboot in five seconds...

I have done some more testing in the meantime. The issue also affect
4.10.1, but not 4.10.0. That's useful since it makes the bisect shorter.
A bisect identifies 8462c575d9 "x86/xpti: Hide almost all of .text and
all .data/.rodata/.bss mappings" as the commit which breaks suspend.

8462c575d9 is a squashed backport of:

  422588e885 x86/xpti: Hide almost all of .text and all .data/.rodata/.bss 
mappings
  d1d6fc97d6 x86/xpti: really hide almost all of Xen image
  044fedfaa2 x86/traps: Put idt_table[] back into .bss

And indeed, reverting those on staging fixes suspend. (This also matches
the behavior that xpti=off fixes suspend as George already reported
earlier today).

[1]: https://lists.xenproject.org/archives/html/xen-devel/2018-04/msg01137.html

Attachment: signature.asc
Description: OpenPGP digital signature

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