Mark, On 01/22/2016 08:13 PM, Mark Rutland wrote: > On Fri, Jan 22, 2016 at 03:23:14PM +0900, AKASHI Takahiro wrote: >> On 01/21/2016 09:02 PM, Mark Rutland wrote: >>> On Thu, Jan 21, 2016 at 03:53:42PM +0900, AKASHI Takahiro wrote: >>>> On 01/20/2016 08:49 PM, Mark Rutland wrote: >>>>> On Wed, Jan 20, 2016 at 03:07:53PM +0900, AKASHI Takahiro wrote: >>>>>> On 01/20/2016 11:49 AM, Dave Young wrote: >>>>>>> Firmware do not know kernel endianniess, kernel should respect firmware >>>>>>> maps and adapt to it, it sounds like a generic issue not specfic to kexec. >>>>>> >>>>>> On arm64, a kernel image header has a bit field to specify the image's endianness. >>>>>> Anyway, our current implementation replies on a user-supplied dtb to start BE kernel. >>>>> >>>>> The firmware should _never_ care about the kernel's endianness. The >>>>> bootlaoder or first kernel shouldn't care about the next kernel's >>>>> endianness apart from in exceptional circumstances. The DTB for a LE >>>>> kernel should look identical to that passed to a BE kernel. >>>> >>>> Please note that I didn't say anything different from your last two statements. >>>> The current arm64 kexec implementation doesn't do anything specific to BE, >>>> but as far as BE kernel doesn't support UEFI, users are responsible for >>>> providing a proper dtb. >>> >>> I'm just confused as to what you mean by a "proper dtb" in that case. >>> >>> If you just mean one with memory nodes hacked in, then that would >>> currently be a way to make that work, yes. >> >> One of useful cases that I have in my mind is kdump. >> We may want to use a small sub-set of dtb, especially devices, to >> make the reboot more reliable. Device drivers are likely to be vulnerable >> at crash. > > I don't think that we can reliably have userspace carve out devices from > the DTB or from ACPI tables in order to achieve that. That's going to > end up complex and/or incomplete. We also can't do this in the > kexec_load_file / Secure Boot case. > > That's not to say we cannot try, as it's possible when using kexec_load. > However, it's only going to be possible on a subset of systems, and it > would probably make sense to reserve this approach to those cases we > cannot work around by other means (e.g. whitelisting "safe" devices in > the kdump kernel, forcing explicit resets, etc). > >>> It seems like the better option is to fix the BE kernel to support a >>> UEFI memory map, as that solves other issues. >> >> Why did Ard throw away his patch? > > In the absence of kexec it wasn't necessary, it only supported a subset > of the runtime services (and no other features like DMI IIRC), and it > looked like it would be painful to debug (if something went wrong while > a CPU was in LE mode, we couldn't even panic()). > > Given BE kernels on UEFI were never supported until that point, there > wasn't a compelling reason to support that case. > > Even if we support the UEFI memory map, I don't think it's worth the > effort to support runtime services, ACPI, and related code that's only > ever been tested on LE. So realistically this would only work on systems > using UEFI && DT rather than UEFI && ACPI. > >> So, are you now suggesting that we put both "elfcorehdr=" and >> "usable-memory=" under /chosen in dtb? > > Yes. > >> That's fair enough. (as far as nobody cares about incompatibility >> with other archs.) > > Glad to hear! :) I'm preparing for a new version based on our discussions. Do you think that UEFI memory map support on BE kernel is a prerequisite for accepting my kdump? -Takahiro AKASHI > Thanks, > Mark. >
