On Wed, Oct 01, 2014 at 07:09:09PM +0100, Vivek Goyal wrote: > On Wed, Oct 01, 2014 at 07:03:04PM +0100, Mark Rutland wrote: > > On Wed, Oct 01, 2014 at 06:47:14PM +0100, Vivek Goyal wrote: > > > On Wed, Oct 01, 2014 at 05:16:21PM +0100, Mark Rutland wrote: > > > > > > [..] > > > > I'm still rather unhappy about the mechanism by which the DTB is passed > > > > by userspace and detected by the kernel, as I'd prefer that the user > > > > explictly stated which segment they wanted to pass to the (Linux) > > > > kernel, but that would require reworking the kexec syscall to allow > > > > per-segment info/flags. > > > > > > Why does the running kernel need to know about dtb segment. I see following. > > > > > > ldr x0, kexec_dtb_addr > > > > > > IIUC, we are loading this address in x0. Can't we do something similar > > > in user space with purgatory. I mean first jump to purgatory (code > > > compiled in user space but runs prviliged) and that code takes care > > > of loading x0 with right dtb addr and then jump to final kernel. > > > > I believe the fundamental issue here is a lack of a userspace-provided > > purgatory. > > > > I agree that userspace purgatory code could set this up. That would > > address my concerns w.r.t. detecting the DTB kernel-side, as there would > > be no need. It would also address my concerns with booting OSs other > > than Linux, as the purgatory code could do whatever was appropriate for > > whatever OS image was loaded. > > > > So in my view, a userspace-provided purgatory that set up the state the > > next kernel expected would be preferable. That could be as simple as > > setting up the registers and branching -- I assume we'd have the first > > kernel perform the required cache maintenance. > > Apart from setting various registers, we also verify the sha256 checksums > of loaded segments in purgatory to make sure segments are not corrupted. > On x86, we also take care of backing up first 640KB of memory in reserved > area in kdump case. I was under the (possibly mistaken) impression that for kdump the second kernel lived and ran at a high address so as to preserve memory in use by the first kernel. Is the first 640KiB is special on x86, or is does it have some kdump-specific use? > So other arches are already doing all this in purgatory. It would be nice > if arm64 sticks to that convention too. > > First kernel --> purgatory ----> second kernel. That would also be my preference, especially given the flexibility this would leave. Mark.
