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.

-- 
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?