[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v3] ARM: parse separate DT properties for different commandlines

On 08/27/2013 05:03 PM, Julien Grall wrote:
On 08/27/2013 02:34 PM, Ian Campbell wrote:
On Wed, 2013-08-21 at 23:53 +0100, Julien Grall wrote:
On 20 August 2013 16:21, Andre Przywara <andre.przywara@xxxxxxxxxx> wrote:
Currently we use the chosen/bootargs property as the Xen commandline
and rely on xen,dom0-bootargs for Dom0. However this brings issues
with bootloaders, which usually build bootargs by bootscripts for a
Linux kernel - and not for the entirely different Xen hypervisor.

Introduce a new possible device tree property "xen,xen-bootargs"
explicitly for the Xen hypervisor and make the selection of which to
use more fine grained:
- If xen,xen-bootargs is present, it will be used for Xen.
- If xen,dom0-bootargs is present, it will be used for Dom0.
- If xen,xen-bootargs is _not_ present, but xen,dom0-bootargs is,
   bootargs will be used for Xen. Like the current situation.
- If no Xen specific properties are present, bootargs is for Dom0.
- If xen,xen-bootargs is present, but xen,dom0-bootargs is missing,
   bootargs will be used for Dom0.

The aim is to allow common bootscripts to boot both Xen and native
Linux with the same device tree blob. If needed, one could hard-code
the Xen commandline into the DTB, leaving bootargs for Dom0 to be set
by the (non Xen-aware) bootloader.

I will send out a appropriate u-boot patch, which writes the content
of the "xen_bootargs" environment variable into the xen,xen-bootargs
dtb property.

Since we plan to support multiboot, is it relevant to send a u-boot patch
for a temporary workaround?

We could use a u-boot script to create the correct properties/nodes in
the device tree. What do you think?

I think a combination of propagating xen_bootargs and using a script to
populate the /chosen/modules@N nodes sounds like quite a convenient way
to do things.

It's not clear that multiboot adds much more than some syntactic sugar
to this.

v1 .. v2:
  - fix whitespace issues
v2 .. v3:
  - add documentation

Signed-off-by: Andre Przywara <andre.przywara@xxxxxxxxxx>

Reviewed-by: Julien Grall <julien.grall@xxxxxxxxxx>

BTW, I have modified this code with my latest patch series. I will
rebase it on top of this patch.

Does this mean I should wait for a series from you incorporating this
patch or should I consider just applying this because you've rebased
your series on it?

For the moment I have rebased this patch on top of my patch series (so
my patch series applied, then Andre's patch).

If Andre is fine to delay this patch, I can carry it on my patch series
and modify the necessary things to switch to dt_* functions.

Andre, what do you think?

Yes, that's fine for me.
We need to rethink this whole multiboot approach anyway.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.