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.
