[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Xen 4.12 panic on Thinkpad W540 with UEFI mutiboot2, efi=no-rs workarounds it



On Wed, Aug 07, 2019 at 06:34:09PM +0200, Jan Beulich wrote:
> On 07.08.2019 18:04, Marek Marczykowski-Górecki  wrote:
> > On Wed, Aug 07, 2019 at 05:58:59PM +0200, Jan Beulich wrote:
> > > On 07.08.2019 17:51, Marek Marczykowski-Górecki  wrote:
> > > > On Wed, Aug 07, 2019 at 05:33:05PM +0200, Jan Beulich wrote:
> > > > > On 07.08.2019 17:17, Marek Marczykowski-Górecki  wrote:
> > > > > > 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?
> > > 
> > > I'm struggling a little how to reply, considering that I've already
> > > said "iirc there's no equivalent for it in the MB2 case". So I guess
> > > I'm simply not understanding your question, or more specifically
> > > where you want to get with it.
> > 
> > /mapbs option is very specific to xen.efi. I'd like to add a means to
> > set map_bs variable in MB2 case too. I'm asking whether I can use
> > standard command line parser, or do I need something special extracting
> > it from MB2 structures directly.
> 
> Well, efi_multiboot2() gets called from head.S, even before the
> (non-EFI only) cmdline_parse_early. I don't suppose there's a way
> to avoid mixing this new option into the "normal" command line,
> and hence there's also no way around peeking into the command
> line early. Of course there's the option to see whether what
> efi_arch_process_memory_map() could be deferred until later. But
> likely that would be a far more intrusive change than what you're
> considering to carry out.

Ok, regardless of adding proper option for that, I've hardcoded map_bs=1
and it still crashes, just slightly differently:

    Xen call trace:
       [<0000000000000080>] 0000000000000080
       [<8c2b0398e0000daa>] 8c2b0398e0000daa

    Pagetable walk from ffffffff858483a1:
       L4[0x1ff] = 0000000000000000 ffffffffffffffff

    ****************************************
    Panic on CPU 0:
    FATAL PAGE FAULT
    [error_code=0002]
    Faulting linear address: ffffffff858483a1
    ****************************************

Full message attached.

-- 
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: unstable-crash-map-bs.jpg
Description: JPEG image

Attachment: signature.asc
Description: PGP signature

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.