On 7 November 2014 11:45, Ard Biesheuvel [off-list ref] wrote:

On 7 November 2014 11:41, Ard Biesheuvel [off-list ref] wrote:

quoted

On 7 November 2014 11:16, Mark Rutland [off-list ref] wrote:

quoted

On Fri, Nov 07, 2014 at 12:41:45AM +0000, Grant Likely wrote:

quoted

On Thu, Nov 6, 2014 at 3:08 PM, Mark Rutland [off-list ref] wrote:

quoted

On Thu, Nov 06, 2014 at 01:56:42AM +0000, Dave Young wrote:

quoted

On 11/03/14 at 07:46pm, Mark Rutland wrote:

quoted

On Fri, Oct 31, 2014 at 07:52:09AM +0000, Dave Young wrote:

quoted

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).

quoted

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.

Nah, strike that. The configuration table entry contains the original
fdt, so with the device nodes etc still present. The stub makes

*memory* nodes not device nodes

changes to the DTB, and /that/ is the version we want to retain so
subsequent kexec reboots can use it.

Sorry for the noise.

-- 
Ard.