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. 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. Thanks Vivek
