On Thu, Aug 4, 2011 at 9:24 PM, Geoff Levand <ge...@infradead.org> wrote: > Also, it needs to be considered that a lot of kernels are out > there will be confused if started with high mem already allocated.
True, but is there anything we can do about that? Isn't is okay to tell users of first stage boot loaders utilizing this mechanism that whatever steps their boot chain contains has to support this highmem pass over? As far as I can tell all current loaders won't be affected by this patch. When a user wants to chain a loader with this mechanism with petitboot, he needs a petitboot coming with a kernel containing this feature, and can then kexec whatever contains it too. >> Using the lv1 repo is an option, but does it make sense? It's even less >> standard than a FDT and we'd have to put both the region1 location and >> the initrd location in there (there's no point to maintaining highmem if >> you aren't going to use it). >> >> FWIW, the lv1 repo writing hypercalls are unused and undocumented. > > The hcalls to create, write, and delete nodes are known, but I don't > recall if I verified they work: > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/powerpc/include/asm/lv1call.h;hb=HEAD#l265 > > #92 should be named lv1_write_repository_node. > > You can only modify the repo for your lpar, so: > > lv1_{create,write}_repository_node(n1, n2, n3, n4, v1, v2); > lv1_delete_repository_node(n1, n2, n3, n4); I tried this and it indeed works - I can pass over the highmem info just fine using repository nodes. If there is a chance that another OS might require this highmem pass over then I agree that using the repository makes more sense. I can prepare a patch for that, replacing this one. Any suggestions on which nodes to use? For a test run I used: FIELD_FIRST("bi", 0), FIELD("highmem", 0), FIELD("address", 0), 0 and FIELD_FIRST("bi", 0), FIELD("highmem", 0), FIELD("size", 0), 0 Regards, Andre _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
