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

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



On 20 August 2013 14:39, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> On Tue, 2013-08-20 at 14:32 +0100, Julien Grall wrote:
>> On 20 August 2013 14:11, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
>> > On Tue, 2013-08-20 at 13:19 +0100, Julien Grall wrote:
>> >> On 20 August 2013 13:09, Andre Przywara <andre.przywara@xxxxxxxxxx> wrote:
>> >> > On 07/10/2013 01:48 PM, Julien Grall wrote:
>> >> >>
>> >> >> On 3 June 2013 14:43, Andre Przywara <andre.przywara@xxxxxxxxxxx> 
>> >> >> 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 also have a simple patch for u-boot to transfer the content of the
>> >> >>> "xen_bootargs" environment variable into the xen,xen-bootargs dtb
>> >> >>> property.
>> >> >>> I will post the u-boot patch to their ML later.
>> >> >>>
>> >> >>> Changes from v1:
>> >> >>> - fix whitespace issues
>> >> >>
>> >> >>
>> >> >> Any news about this patch ? :)
>> >> >
>> >> >
>> >> > Sorry for the lag ;-)
>> >> >
>> >> >
>> >> >>
>> >> >>> Signed-off-by: Andre Przywara <andre.przywara@xxxxxxxxxxx>
>> >> >>> ---
>> >> >>>   xen/arch/arm/domain_build.c | 13 ++++++++++---
>> >> >>>   xen/common/device_tree.c    |  7 ++++++-
>> >> >>>   2 files changed, 16 insertions(+), 4 deletions(-)
>> >> >>>
>> >> >>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
>> >> >>> index b92c64b..5809489 100644
>> >> >>> --- a/xen/arch/arm/domain_build.c
>> >> >>> +++ b/xen/arch/arm/domain_build.c
>> >> >>> @@ -139,6 +139,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 &&
>> >> >>> @@ -169,11 +170,17 @@ static int write_properties(struct domain *d,
>> >> >>> struct kernel_info *kinfo,
>> >> >>>            */
>> >> >>>           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;
>> >> >>
>> >> >>
>> >> >> Here, you overwrite the previous "bootargs". This variable is set if
>> >> >> the module node contains "bootargs" property
>> >> >> (see process_multiboot_node in common/device_tree.c)
>> >> >
>> >> >
>> >> > I'd say that is intended. I think those command lines directly under 
>> >> > /chosen
>> >> > should have the highest priority. If someone has
>> >> > /chosen/xen,dom0-bootargs, that should be used instead of a most likely
>> >> > hard-coded value under modules.
>> >>
>> >> I don't  think people use bootargs in module.
>> >
>> > They are documented as existing in
>> > docs/misc/arm/device-tree/booting.txt, so something would need to change
>> > in either the code or the docs I think.
>>
>> The wiki page only mentions xen,dom0-bootargs solution :).
>
> Do the wiki pages use the /modules stuff at all? If not then would not
> expect they would use /module/N/bootargs either.

Nothing. The versatile express loads the Linux Image from the an
hardcoded address in the flash.

The arndale board uses /modules/... but it already set up in the provided
device tree.

That's why I think we can remove module@0/bootargs.

>> BTW, Andre, can you document this patch at least in docs/misc/arm?
>
> I think this is a must. In fact IIRC this was the main reason the patch
> wasn't just applied.

Indeed. I forgot that I have already asked few mails before :).

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

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