On Mon, May 2, 2016 at 3:40 PM, Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> wrote: > On Mon, May 02, 2016 at 01:04:28PM +0530, Pratyush Anand wrote: >> On Sat, Apr 30, 2016 at 1:50 PM, Russell King - ARM Linux >> <linux@xxxxxxxxxxxxxxxx> wrote: >> > On Sat, Apr 30, 2016 at 08:57:34AM +0530, Pratyush Anand wrote: >> >> On Fri, Apr 29, 2016 at 11:30 PM, Russell King - ARM Linux >> >> <linux@xxxxxxxxxxxxxxxx> wrote: >> >> > On Fri, Apr 29, 2016 at 08:26:00PM +0530, Pratyush Anand wrote: >> >> >> Hi Russell, >> >> >> >> >> >> On Thu, Apr 28, 2016 at 2:58 PM, Russell King >> >> >> <rmk+kernel@xxxxxxxxxxxxxxxx> wrote: >> >> >> > Advertise the location of bootable RAM to kexec-tools. kexec needs to >> >> >> > know where it can place the kernel in RAM, and so be executable when >> >> >> > the system needs to jump into it. >> >> >> > >> >> >> > Advertise these areas in /proc/iomem with a "System RAM (boot alias)" >> >> >> > tag. >> >> >> > >> >> >> > Signed-off-by: Russell King <rmk+kernel@xxxxxxxxxxxxxxxx> >> >> >> >> >> >> Can you please also share git tree path of corresponding kexec-tools changes? >> >> >> >> >> >> Could it be a better idea (if things in user space become simpler) >> >> >> that in stead of patch 5 and 6, we pass arch_phys_to_idmap_offset to >> >> >> user space, and then user space manipulates existing "Crash kernel" >> >> >> and "System RAM" resources. >> >> > >> >> > Given that it's only _one_ platform right now, I don't think that >> >> > additional complexity is worth it. It means that we have to invent >> >> >> >> Probably, I could not communicate it well. I was not trying to have >> >> *additional* complexity. Wanted to see if things could be simpler >> >> rather. So this is what my understanding was: >> >> -- We create one patch to pass arch_phys_to_idmap_offset to user space >> >> (say in /sys/kernel/bootmem_idmap_offset) >> >> -- We do not use patch 5,6,11 and 12 of this series. Probably few more >> >> content of the series will go away. >> > >> > Patches 11 and 12 don't go away with what you're suggesting. Patches >> > 11 and 12 are necessary to allow the boot-view addresses to be passed >> > into the kernel through kexec, and to allow kexec to find appropriate >> > memory resources. >> >> But once we would have manipulated "start" and "end" of "Crash Kernel" >> and "System RAM" resources in user space using >> /sys/kernel/bootmem_idmap_offset , then kernel through kexec system >> call would have already receive boot-view addresses, no? > > Correct, but that's still a problem for all the reasons I gave in the > email to which you replied to. > > I'm not sure where the misunderstanding is. No, no..there is no misunderstanding. I agreed to your implementation because that will work for generic cases and for me complete series is OK. I just wanted to clarify my understanding, and so was the last argument. > > Let me repeat: even if we do what you're suggesting, patches 11 and 12 > do *not* go away. I've explained in detail why each of the changes are > necessary (which you have cut from your reply.) > Again, it is just for clarifying myself. I cut the reply because I understood that in patch 11 and 12, you convert addresses passed by kexec tools from run time view to boot view using different helpers like phys_to_boot_phys(). So, had kexec system call passed boot view addresses, we would have not needed 11 and 12. This is what I wanted to clarify. > In other words: exporting this offset via > /sys/kernel/bootmem_idmap_offset is technically inferior to the solution > I have come up with here, and it saves very little complexity and code. I still have opinion that code will probably be more simple and reduce significantly, however solution will siege to work the moment idmap_offset is not a simple additive value. Therefore, I am OK with your implementation. ~Pratyush -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
