[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 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? > 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. Cheers, > --- > docs/misc/arm/device-tree/booting.txt | 28 +++++++++++++++++++++++++++- > xen/arch/arm/domain_build.c | 15 +++++++++++---- > xen/common/device_tree.c | 7 ++++++- > 3 files changed, 44 insertions(+), 6 deletions(-) > > diff --git a/docs/misc/arm/device-tree/booting.txt > b/docs/misc/arm/device-tree/booting.txt > index 94cd3f1..08ed775 100644 > --- a/docs/misc/arm/device-tree/booting.txt > +++ b/docs/misc/arm/device-tree/booting.txt > @@ -1,3 +1,6 @@ > +Dom0 kernel and ramdisk modules > +================================ > + > Xen is passed the dom0 kernel and initrd via a reference in the /chosen > node of the device tree. > > @@ -22,4 +25,27 @@ properties: > > - bootargs (optional) > > - Command line associated with this module > + Command line associated with this module. This is deprecated and > should > + be replaced by the bootargs variations described below. > + > + > +Command lines > +============= > + > +Xen also checks for properties directly under /chosen to find suitable > command > +lines for Xen and Dom0. The logic is the following: > + > + - 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. > + - 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. > + > +Most of these cases is to make booting with Xen-unaware bootloaders easier. > +For those you would hardcode the Xen commandline in the DTB under > +/chosen/xen,xen-bootargs and would let the bootloader set the Dom0 command > +line by writing bootargs (as for native Linux). > +A Xen-aware bootloader would set xen,xen-bootargs for Xen, xen,dom0-bootargs > +for Dom0 and bootargs for native Linux. > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c > index 01492bb..c82ece1 100644 > --- a/xen/arch/arm/domain_build.c > +++ b/xen/arch/arm/domain_build.c > @@ -140,6 +140,7 @@ static int write_properties(struct domain *d, struct > kernel_info *kinfo, > u32 address_cells, u32 size_cells) > { > const char *bootargs = NULL; > + int had_dom0_bootargs = 0; > int prop; > > if ( early_info.modules.nr_mods >= 1 && > @@ -166,15 +167,21 @@ static int write_properties(struct domain *d, struct > kernel_info *kinfo, > * > * * remember xen,dom0-bootargs if we don't already have > * bootargs (from module #1, above). > - * * remove bootargs and xen,dom0-bootargs. > + * * remove bootargs, xen,dom0-bootargs and xen,xen-bootargs. > */ > if ( device_tree_node_matches(fdt, node, "chosen") ) > { > - if ( strcmp(prop_name, "bootargs") == 0 ) > + if ( strcmp(prop_name, "xen,xen-bootargs") == 0 ) > + continue; > + if ( strcmp(prop_name, "xen,dom0-bootargs") == 0 ) > + { > + had_dom0_bootargs = 1; > + bootargs = prop_data; > continue; > - else if ( strcmp(prop_name, "xen,dom0-bootargs") == 0 ) > + } > + if ( strcmp(prop_name, "bootargs") == 0 ) > { > - if ( !bootargs ) > + if ( !bootargs && !had_dom0_bootargs ) > bootargs = prop_data; > continue; > } > diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c > index 84d704d..e22bd22 100644 > --- a/xen/common/device_tree.c > +++ b/xen/common/device_tree.c > @@ -325,7 +325,12 @@ const char *device_tree_bootargs(const void *fdt) > if ( node < 0 ) > return NULL; > > - prop = fdt_get_property(fdt, node, "bootargs", NULL); > + prop = fdt_get_property(fdt, node, "xen,xen-bootargs", NULL); > + if ( prop == NULL ) > + { > + if (fdt_get_property(fdt, node, "xen,dom0-bootargs", NULL)) > + prop = fdt_get_property(fdt, node, "bootargs", NULL); > + } > if ( prop == NULL ) > return NULL; -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |