[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150227103650.GA9011@leverpostej>
Date: Fri, 27 Feb 2015 10:36:50 +0000
From: Mark Rutland <mark.rutland@....com>
To: Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc: Timur Tabi <timur@...eaurora.org>,
"hanjun.guo@...aro.org" <hanjun.guo@...aro.org>,
Catalin Marinas <Catalin.Marinas@....com>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Will Deacon <Will.Deacon@....com>,
Olof Johansson <olof@...om.net>,
"grant.likely@...aro.org" <grant.likely@...aro.org>,
Ashwin Chaugule <ashwinc@...eaurora.org>,
Lorenzo Pieralisi <Lorenzo.Pieralisi@....com>,
Robert Richter <rric@...nel.org>,
Arnd Bergmann <arnd@...db.de>,
"graeme.gregory@...aro.org" <graeme.gregory@...aro.org>,
Linaro ACPI Mailman List <linaro-acpi@...ts.linaro.org>,
Marc Zyngier <Marc.Zyngier@....com>,
"jcm@...hat.com" <jcm@...hat.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
Mark Brown <broonie@...nel.org>,
"suravee.suthikulpanit@....com" <suravee.suthikulpanit@....com>,
Sudeep Holla <Sudeep.Holla@....com>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v9 00/21] Introduce ACPI for ARM64 based on ACPI 5.1
> > I'm still debugging it, but v9 on the 4.0-rc1 kernel crashes after calling
> > the UEFI boot time services exit function. That is, this line:
> >
> > status = sys_table->boottime->exit_boot_services(handle, mmap_key);
> >
> > in allocate_new_fdt_and_exit_boot() gets called, and then soon after it
> > returns, the kernel crashes. It's really early because the UEFI exception
> > handler is called.
> >
> > I did not have this problem with v8 patchset on 3.19.
> >
>
> Are you not seeing this on v4.0-rc1 without the patchset applied?
>
> Could the crash be inside the subsequent call to
> SetVirtualAddressMap() instead of inside ExitBootServices()?
>
> If so, you have a firmware bug: Mark Rutland spotted a similar bug in
> the AMD Seattle firmware, which has been fixed in the mean time.
> It has to do with the firmware dereferencing the virtual mapping as it
> is being installed, which violates the UEFI spec.
A simple way to test is to change EFI_RT_VIRTUAL_BASE to point to the
(unmapped) high half of the address space (e.g. set it to
0xffff000000000000). If EFI is using pointers erroneously then something
should fault within SetVirtualAddressMap(), and you can catch this with
your favourite debugger.
Otherwise it's possible that the virtual address space chosen will cover
memory and/or devices in the existing idmap, and any erroneous accesses
will corrupt memory and/or cause devices to explode.
Thanks,
Mark
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists