All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Xen 4.12 panic on Thinkpad W540 with UEFI mutiboot2, efi=no-rs workarounds it
Date: Wed, 7 Aug 2019 17:51:12 +0200	[thread overview]
Message-ID: <20190807155112.GA3257@mail-itl> (raw)
In-Reply-To: <59f6c90b-3dbb-b0eb-ff45-0f8fd4c915de@suse.com>


[-- Attachment #1.1: Type: text/plain, Size: 3998 bytes --]

On Wed, Aug 07, 2019 at 05:33:05PM +0200, Jan Beulich wrote:
> On 07.08.2019 17:17, Marek Marczykowski-Górecki  wrote:
> > On Wed, Aug 07, 2019 at 04:45:43PM +0200, Jan Beulich wrote:
> > > On 07.08.2019 15:26, Marek Marczykowski-Górecki  wrote:
> > > > Hi,
> > > > 
> > > > Xen 4.12 crashes when booting on UEFI (with multiboot2) unless I disable
> > > > runtime services. The crash happens shortly after starting dom0 kernel.
> > > > Unfortunately I don't have serial console there, so the only log I have
> > > > is a photo of VGA console (attached). Below I retype part of the message:
> > > > 
> > > > (XEN) ----[ Xen-4.12.0-3.fc29  x86_64  debug=n   Not tainted ]----
> > > > (XEN) CPU:    0
> > > > (XEN) RIP:    e008:[<00000000000000f6>] 00000000000000f6
> > > > (XEN) RFLAGS: 0000000000010287   CONTEXT: hypervisor (d0v0)
> > > > ...
> > > > (XEN) Xen call trace:
> > > > (XEN)    [<00000000000000f6>] 00000000000000f6
> > > > (XEN)    [<ffff82d08026c6ad>] flushtlb.c#pre_flush+0x3d/0x80
> > > > (XEN)    [                  ] efi_runtime_call+0x493/0xbd0
> > > > (XEN)    [                  ] efi_runtime_call+0x441/0xbd0
> > > > (XEN)    [                  ] vcpu_restore_fpu_nonlazy+0xe7/0x180
> > > > (XEN)    [                  ] do_platform_op+0/0x1880
> > > > (XEN)    [                  ] do_platform_op+0xb9c/0x1880
> > > > (XEN)    [                  ] do_platform_op+0xb9c/0x1880
> > > > (XEN)    [                  ] sched_credit2.c#csched2_schedule+0xcd0/0x13a0
> > > > (XEN)    [                  ] lstar_enter+0xae/0x120
> > > > (XEN)    [                  ] do_platform_op+0/0x1880
> > > > (XEN)    [                  ] pv_hypercall+0x152/0x220
> > > > (XEN)    [                  ] lstar_enter+0xae/0x120
> > > > (XEN)    [                  ] lstar_enter+0xa2/0x120
> > > > (XEN)    [                  ] lstar_enter+0xae/0x120
> > > > (XEN)    [                  ] lstar_enter+0xa2/0x120
> > > > (XEN)    [                  ] lstar_enter+0xae/0x120
> > > > (XEN)    [                  ] lstar_enter+0xa2/0x120
> > > > (XEN)    [                  ] lstar_enter+0xae/0x120
> > > > (XEN)    [                  ] lstar_enter+0xa2/0x120
> > > > (XEN)    [                  ] lstar_enter+0xae/0x120
> > > > (XEN)    [                  ] lstar_enter+0xa2/0x120
> > > > (XEN)    [                  ] lstar_enter+0xae/0x120
> > > > (XEN)    [                  ] lstar_enter+0x10c/0x120
> > > > (XEN)
> > > > (XEN)
> > > > (XEN) *****************************************
> > > > (XEN) Panic on CPU 0:
> > > > (XEN) FATAL TRAP: vector = 0 (divide error)
> > > > (XEN) [error_code=0000]
> > > > (XEN) *****************************************
> > > > 
> > > > Any idea? Lack of serial console doesn't help with collecting logs...
> > > 
> > > May I suggest that you repeat this with a debug hypervisor, such that
> > > the call trace becomes more usable/sensible?
> > 
> > Actually, I've already tried, but every other build I try, I get even
> > less useful call trace, for example debug unstable build:
> > 
> >      Xen call trace:
> >         [<000000007b751c09>] 000000007b751c09
> >         [<8c2b0398e0000daa>] 8c2b0398e0000daa
> > ...
> >      GENERAL PROTECTION FAULT
> >      [error_code=0000]
> 
> But this makes reasonable sense: The faulting insn is "call *0x18(%rax)"
> and %rax is 6954b2b0, which points into a block of type
> EfiBootServicesData (and hence likely reused by the time of the crash
> for other purposes). Hence the "/mapbs" option of xen.efi might help
> here too, but iirc there's no equivalent for it in the MB2 case.

Oh, yes, indeed in Qubes we have /mapbs enabled by default with xen.efi.
I'd like to add it to MB2 case too. Is command line parsed at this point
(efi_exit_boot()) already? 

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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

  reply	other threads:[~2019-08-07 15:51 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20190807132657.GA2852@mail-itl>
2019-08-07 13:50 ` [Xen-devel] Xen 4.12 panic on Thinkpad W540 with UEFI mutiboot2, efi=no-rs workarounds it Andrew Cooper
2019-08-07 14:45 ` Jan Beulich
     [not found]   ` <20190807151703.GA2659@mail-itl>
2019-08-07 15:33     ` Jan Beulich
2019-08-07 15:51       ` Marek Marczykowski-Górecki [this message]
2019-08-07 15:58         ` Jan Beulich
2019-08-07 16:04           ` Marek Marczykowski-Górecki
2019-08-07 16:34             ` Jan Beulich
     [not found]               ` <20190807192557.GC3257@mail-itl>
2019-08-08  2:53                 ` Marek Marczykowski-Górecki
2019-08-08  6:03                   ` Jan Beulich
2019-10-08 11:50                     ` Marek Marczykowski-Górecki
2019-10-08 13:08                       ` Jan Beulich
2019-10-08 13:52                         ` Marek Marczykowski-Górecki
2019-10-08 14:19                           ` Jan Beulich
2019-10-08 16:29                             ` Marek Marczykowski-Górecki
2019-10-09  0:40                               ` Marek Marczykowski-Górecki
2019-10-09  8:56                               ` Jan Beulich
2019-10-09 10:31                                 ` Marek Marczykowski-Górecki
2019-10-09 10:50                                   ` Jan Beulich
2019-10-09 11:00                                     ` Marek Marczykowski-Górecki
2019-10-09 11:48                                       ` Jan Beulich
2019-10-09 11:52                                         ` Marek Marczykowski-Górecki
2019-10-09 12:07                                           ` Jan Beulich
2019-10-09 12:21                                             ` Marek Marczykowski-Górecki
2019-10-09 12:24                                               ` Jan Beulich
2019-10-09 12:27                                                 ` Marek Marczykowski-Górecki
2019-10-09 13:31                                                   ` Jan Beulich
2019-10-09 23:57                                                     ` Marek Marczykowski-Górecki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190807155112.GA3257@mail-itl \
    --to=marmarek@invisiblethingslab.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.