On Wed, Nov 12, 2014 at 11:07:22AM +0000, Mark Rutland wrote:
[...]
We are currently suggesting adding an RDSP property to the chosen node in the tiny DT, but a command-line arguement like kexec proposed could be another option I guess, albeit not a very pretty one.
I'm not sure what an RDSP command line property would have to do with kexec. I'll assume I've misunderstood something.
I thought the kexec patches proposed passing the RDSP on the command-line to boot the secondary kernel, so if that ended up being supported by the kernel for kexec, maybe that could be leveraged by Xen's boot protocol. It was an idea someone brought to me, just thought I'd mention it.
Ah, that's not something I'd heard of.
Maybe there was a misunderstanding then, I thought you were cc'ed on those discussions.
I may just have lost them in my inbox. I'm on a few too many mailing lists these days. Sorry about that.
I'm not a fan of placing fundamentally required system description on the command line. It's fine for explicit overrides but I don't think it should be the default mechanism as that causes its own set of problems (who wants to fight with their hypervisor to pass a command line to a guest kernel?).
Agreed completely, but I've been lacking strong technical arguments against passing this stuff on the cmdline. My personal preferred approach for the Xen Dom0 case is to add a property to the DT.
Something under /chosen, or a firmware node would sound preferable to me. For UEFI we pass the system table address as /chosen/linux,uefi-system-table = <... ...>, and I think the RDSP could be handled similarly if necessary. The user can than override that via the command line if desired.
We have actually done that in the past when we had to support u-boot and bootwrapper as a bootloader. It works fine in the kernel and its a minimal patch to support.
Graeme