On 7 November 2014 11:45, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote: > On 7 November 2014 11:41, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote: >> 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. >> > > 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.
