From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: crash in efi_runtime_call Date: Fri, 17 Apr 2015 10:03:01 -0400 Message-ID: <20150417140301.GF22508@l.oracle.com> References: <20150417111700.GA4009@aepfle.de> <5530F586.70801@citrix.com> <55311B380200007800073390@mail.emea.novell.com> <55310284.2060306@citrix.com> <20150417134044.GG19690@l.oracle.com> <55310E73.6070401@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <55310E73.6070401@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andrew Cooper Cc: Olaf Hering , Jan Beulich , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org 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, 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) [] efi_runtime_call+0x7f0/0x890 > >>>>> (XEN) [] do_platform_op+0x679/0x1670 > >>>>> (XEN) [] 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 >