device tree passing feature

[Thiago Jung Bauermann]

Hi Samuel,

Thanks for your response.

Am Freitag, 01 Juli 2016, 11:46:21 schrieb Samuel Mendoza-Jonas:
> On Thu, 2016-06-30 at 11:27 -0300, Thiago Jung Bauermann wrote:
> > I have a question about the petitboot feature which allows the user to
> > specify a device tree blob to pass to the target OS being loaded. What
> > is
> > the use case for it? Is it a debugging and development aid, or do you
> > expect it be useful in a production environment?
> 
> Passing the dtb isn't really a Petitboot feature, rather part of how
> kexec works for PowerPC and ARM. Petitboot may make modifications to, or
> replace the dtb, but the method via with the target kernel obtains its
> device-tree is kexec. So I suspect you would have to say it is mandatory
> for production.

Right. I already have a working kexec_file_load implementation [1], and what 
I'm doing in my patch set is taking the device tree that was used to boot 
the current kernel and modifying it as necessary to pass it to the next 
kernel.

My question is: is there any need in a production environment for userspace 
to provide a different device tree for the next kernel, or can the currently 
running kernel always use the device tree that it received when it was 
booted?

So one new piece of information for me is that Petitboot makes modifications 
to the dtb. Does it do that only if the system administrator provided a 
custom dtb (either via the boot options screen or a configuration file), or 
can it change/replace the dtb even if the system administrator didn't 
provide a custom dtb? Which modifications does Petitboot make?

> > I ask this because I'm implementing the kexec_file_load system call for
> > powerpc, and given its prototype:
> > 
> > long kexec_file_load(int kernel_fd, int initrd_fd, unsigned long
> > cmdline_len, const char *cmdline_ptr, unsigned long flags)
> > 
> > It wouldn't be very straightforward to allow the caller to specify a
> > device tree blob, so I have to ask how necessary such a feature is.
> 
> Yep, I think the problem is kexec_file_load was first implemented with a
> focus on x86 where this isn't an issue, and now we need to consider what
> to do :)

Yes, that's true. I was able to make it work on powerpc even with that x86 
bias, but now I'm wondering if that's enough or not.

> We are definitely going to need a way to pass the device-tree to the
> target kernel - whether we do that by changing the prototype for
> kexec_file_load() PowerPC and ARM, or by dealing with it some other way
> I'm not sure.

Do you say definitely because the kexec'd kernel needs to be passed a device 
tree, or is it because userspace needs to have some control over the device 
tree that the kexec'd kernel receives?

> Sounds like the start of a interesting conversation on the
> linuxppc-dev list :)

Indeed. :-) I'm copying linuxppc-dev here just in case.

A conversation about this just started in the kexec mailing list (I'm 
copying the linuxppc-dev mailing list in my response as well):

https://lists.infradead.org/pipermail/kexec/2016-July/016279.html

[]'s
Thiago Jung Bauermann
IBM Linux Technology Center


[1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2016-June/144658.html