[PATCH 00/10] arm64 kexec kernel patches V5

[Ard Biesheuvel]

On 7 November 2014 11:16, Mark Rutland <mark.rutland at arm.com> wrote:
> On Fri, Nov 07, 2014 at 12:41:45AM +0000, Grant Likely wrote:
>> On Thu, Nov 6, 2014 at 3:08 PM, Mark Rutland <mark.rutland at arm.com> wrote:
>> > On Thu, Nov 06, 2014 at 01:56:42AM +0000, Dave Young wrote:
>> >> On 11/03/14 at 07:46pm, Mark Rutland wrote:
>> >> > On Fri, Oct 31, 2014 at 07:52:09AM +0000, Dave Young wrote:
>> >> > > Hi Geoff
>> >> > >
>> >> > > I tested your patches. The macihne is using spin-table cpu enable method
>> >> > > so I tried maxcpus=1 as you suggested.
>> >> > >
>> >> > > There's below issues for me, thoughts?
>> >> > >
>> >> > > 1. For acpi booting there's no /proc/device-tree so kexec can not find dtb
>> >> > > to use.
>> >> >
>> >> > Are you absolutely certain of this?
>> >> >
>> >> > To use ACPI, you must have booted via EFI, as the only mechanism for
>> >> > finding the ACPI tables is via EFI. If booted via EFI, the stub will
>> >> > have created a stub DTB if there is no provided DTB, to pass the command
>> >> > line and pointers to EFI data structures. This stub DTB should be
>> >> > present in the usual place.
>> >>
>> >> Mark, I used kexec-tools from Geoff's git tree, it will create dtb from procfs
>> >> maybe I can pass external dtb to kexec-tools. What you mentioned should be true
>> >> though but I have not get idea how to get the dtb which kernel is using for boot
>> >> since it is not unflattened.
>> >
>> > Ah, sorry. I see the problem now. For ACPI you don't unflatten the tree,
>> > so there's nothing to expose at in sysfs/procfs.
>> >
>> > Somehow we need to unflatten the DTB without exposing it to drivers,
>> > such that it can be exposed to userspace in the usual place but drivers
>> > don't being probing based off of it.
>>
>> Is that even necessary? If the tree isn't unflattened, then it is just
>> a stub tree. There really isn't anything interesting in it.
>
> We need to UEFI properties [1] from /chosen to access the memory map and
> system table (both of which are necessary to access any ACPI tables).
>
>> Kexec should recreate the tree from scratch in that case.
>
> I'm not sure if the required information is exposed to userspace
> elsewhere. Ard, Leif?
>

Personally, I think we should not be using /proc/device-tree at all,
but instead retain the original blob in some way and expose that.

We already have /sys/firmware/efi/systab which contains the physical
addresses of the UEFI configuration tables. We should probably add an
entry for the FDT there anyway, but we would still be looking at
mmap(/dev/mem) to access it, which is not a practice we want to
encourage, I suppose.

Also, we *must* take the secure boot scenario into account. Booting
with an arbitrary user generated DTB is nice, but if you are doing
kexec without an initrd, for instance, it would also be nice if we
could just reuse the existing DTB without bothering the user for it at
all, which would be something we could also allow when running
securely.

-- 
Ard.