Re: crash in efi_runtime_call

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Fri, Apr 17, 2015 at 02:45:23PM +0100, Andrew Cooper wrote:
> On 17/04/15 14:40, Konrad Rzeszutek Wilk wrote:
> > On Fri, Apr 17, 2015 at 01:54:28PM +0100, Andrew Cooper wrote:
> >> On 17/04/15 13:39, Jan Beulich wrote:
> >>>>>> On 17.04.15 at 13:59, <andrew.cooper3@citrix.com> wrote:
> >>>> On 17/04/15 12:17, Olaf Hering wrote:
> >>>>> Since booting xen fails on my ProBook unless I specify "maxcpus=1" I
> >>>>> tried the EFI firmware today. To my surprise it boots and finds all
> >>>>> cpus. But once some efi driver in dom0 is loaded xen crashes. The same
> >>>>> happens with xen-4.4 as included in SLE12.
> >>>>>
> >>>>> ...
> >>>>> (XEN) Xen call trace:
> >>>>> (XEN)    [<00000000aec1e8e1>] 00000000aec1e8e1
> >>>>> (XEN)    [<ffff82d080222600>] efi_runtime_call+0x7f0/0x890
> >>>>> (XEN)    [<ffff82d0801641a9>] do_platform_op+0x679/0x1670
> >>>>> (XEN)    [<ffff82d08021dfb9>] syscall_enter+0xa9/0xae
> >>>>> ....
> >>>>>
> >>>>> Can I do anything about it, or is this a firmware bug? I will move the
> >>>>> offending efi driver away and try again.
> >>>>>
> >>>>> Olaf
> >>>> This is a firmware bug.
> >>> +1 (and I'm surprised how common this is)
> >> The bug is present in the reference implementation code, which means it
> >> is present in a lot of real firmware.  We have kit from 3 different
> >> vendors which are affected, including latest available firmware.
> >>
> >>>>> (XEN)  0000100000000-000023fffffff type=7 attr=000000000000000
> >>>>> (XEN)  00000fec10000-00000fec10fff type=11 attr=8000000000000001
> >>>>> (XEN)  00000fff40000-00000fff46fff type=11 attr=8000000000000000
> >>>>> (XEN) Unknown cachability for MFNs 0xfff40-0xfff46
> >>>> This unknown cacheability causes Xen not to make pagetables for the region.
> >>>>
> >>>> There is a patch or two floating around the list, but currently no
> >>>> resolution on the argument it created.
> >>>>
> >>>> https://github.com/xenserver/xen-4.5.pg/blob/master/master/unknown-cacheabilit 
> >>>> y.patch
> >>>> is the XenServer fix.
> >>> Now that's surely wrong
> >> Right or wrong, this is (apparently; I have not checked) what Linux does.
> >>
> >>>  - if anything, unknown should be treated as
> >>> UC (and quite likely specifically in a case like the one Olaf reports here,
> >>> as the offending memory range pretty likely is other than normal RAM).
> >>> What I'd accept as a patch would be the addition of a command line
> >>> option enforcing the mapping of such unknown cacheability areas with
> >>> a certain caching type (default then being UC).
> >> If I can find some copious free time, I will see about making this happen.
> > I actually did cobble a patch like this, but it is based on Daniel's Multibootv2
> > so it won't apply cleany. See attached patchset with various 'work-arounds'.
> >
> > Jan if you are OK with them (well the 'idea' behind them) I can refresh
> > it against staging and post them?
> 
> I was planning to make one efi= command line option along the
> psr/ept/iommu line, rather than having a large number of top-level
> options (and folding our one efi-rs option into it).

That does sound more sensible than a bunch of 'efi-XYZ'.
> 
> But otherwise, that sounds like a plan.

Great. Next week I will post it.
> 
> ~Andrew
>