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

[Xen-devel] Bug in devicetree_for_each_node() in xen/arch/arm/bootfdt.c ?



I’ve been trying to figure out why Xen only reports 2GB on my ARM platform that actually has 3GB, and I think I’ve found a bug, but I’m not familiar enough with the Xen code to fix it.

 

The relevant parts of my dts are:

/dts-v1/;

 

/ {

     model = "Broadcom STB (7445d0)";

     compatible = "brcm,bcm7445d0", "brcm,brcmstb";

     #address-cells = <0x2>;

     #size-cells = <0x2>;

     interrupt-parent = <0x1>;

 

     memory {

           #address-cells = <0x1>;

           #size-cells = <0x1>;

           device_type = "memory";

           reg = <0x0 0x0 0x0 0x40000000 0x0 0x40000000 0x0 0x40000000>;

 

           region@10000000 {

                contiguous-region;

                reg = <0x10000000 0x1f800000>;

                linux,phandle = <0x2>;

                phandle = <0x2>;

           };

 

           region@30000000 {

                contiguous-region;

                reg = <0x30000000 0x10000000>;

                linux,phandle = <0x3>;

                phandle = <0x3>;

           };

 

           region@40000000 {

                contiguous-region;

                reg = <0x40000000 0x40000000>;

                linux,phandle = <0x4>;

                phandle = <0x4>;

           };

 

           region@80000000 {

                contiguous-region;

                reg = <0x80000000 0x40000000>;

                linux,phandle = <0x5>;

                phandle = <0x5>;

           };

     };

 

As you can see, it specifies 0 + 1GB + 1GB + 1GB. When I run “xl info” in Dom0, though, it reports “Total 2048”.

 

Digging into the code, I found that in bootinfo.mem.nr_banks is 2 rather than the expected 3 (or 4?). That turned out to be because in process_memory_node(), address_cells and size_cells were both 2 and so the prop_len of 32 was resulting in “banks” being set to 2.

 

Looking at device_tree_for_each_node(), it looks like something is wrong because it contains this loop:

    for ( node = 0, depth = 0;

          node >=0 && depth >= 0;

          node = fdt_next_node(fdt, node, &depth) )

    {

                […]

        ret = func(fdt, node, name, depth,

                   address_cells[depth-1], size_cells[depth-1], data);

which looks like it will read before the start of the array for the first node, when depth=0. My first instinct was to remove those two “-1”s, but the resulting code didn’t run, so I figured I’d try to enlist some help J Of course it’s possible that my problem is unrelated to this, but reading before the start of the array definitely seems like a bug that should be fixed (although in practice those values are never used for node 0). Looking through the history, it seems to have been like that since the function was first introduced (http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=9cf4a9a467171c8a2c3d97c2bfadb1bc8b15a3d6).

 

I’m happy to test out any patches.

 

Chris

(Not subscribed to the list)

 

_______________________________________________
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®.