On Tue, Dec 17, 2019 at 11:26 AM Stefano Stabellini <[email protected]> wrote: > > On Tue, 17 Dec 2019, Roman Shaposhnik wrote: > > On Tue, Dec 17, 2019 at 10:30 AM Stefano Stabellini > > <[email protected]> wrote: > > > > > > On Tue, 17 Dec 2019, Julien Grall wrote: > > > > Hi, > > > > > > > > On 17/12/2019 04:39, Roman Shaposhnik wrote: > > > > > On Mon, Dec 16, 2019 at 6:55 PM Stefano Stabellini > > > > > <[email protected]> wrote: > > > > > > On Mon, 16 Dec 2019, Roman Shaposhnik wrote: > > > > > > If I sum all the memory sizes together I get 0x3ddfd000 which is > > > > > > 990M. > > > > > > If so, I wonder how you could boot succesfully with dom0_mem=1024M > > > > > > even > > > > > > on Xen 4.12... :-? > > > > > > > > > > That is a very interesting observation indeed! I actually don't > > > > > remember where that device tree came from, but I think it was from one > > > > > of the Linaro sites. > > > > > > > > This is mostly likely because of: > > > > > > > > commit 6341a674573f1834f083f0ab0f5b36b075f9e02e > > > > Author: Julien Grall <[email protected]> > > > > Date: Wed Aug 21 22:42:31 2019 +0100 > > > > > > > > xen/arm: domain_build: Don't continue if unable to allocate all > > > > dom0 banks > > > > > > > > Xen will only print a warning if there are memory unallocated when > > > > using > > > > 1:1 mapping (only used by dom0). This also includes the case where > > > > no > > > > memory has been allocated. > > > > > > > > It will bring to all sort of issues that can be hard to diagnostic > > > > for > > > > users (the warning can be difficult to spot or disregard). > > > > > > > > If the users request 1GB of memory, then most likely they want the > > > > exact > > > > amount and not 512MB. So panic if all the memory has not been > > > > allocated. > > > > > > > > After this change, the behavior is the same as for non-1:1 memory > > > > allocation (used by domU). > > > > > > > > At the same time, reflow the message to have the format on a single > > > > line. > > > > > > > > Signed-off-by: Julien Grall <[email protected]> > > > > Acked-by: Stefano Stabellini <[email protected]> > > > > > > Ah! Roman, could you please post the full boot log of a successful 4.12 > > > boot? > > > > > > If it has a "Failed to allocate requested dom0 memory" message, then we > > > know what the issue is. > > > > Aha! Our messages seems to have crossed ;-) Full log is attached and > > yes -- that's > > the problem indeed. > > > > So at least that mystery is solved. But I'm still not able to get to a > > full 1G of memory > > even with your update to the device tree file. Any chance you can send me > > the > > device tree file that works for you? > > I didn't try on real hardware, I only tried on QEMU with a similar > configuration. I went back and check the HiKey device tree I used and it > is the same as yours (including the ramoops reserved-memory error). > > Apparently there are 1G and 2G variants of the HiKey, obviously both > yours and my device tree are for the 1G variant. I try to dig through > the docs but couldn't find the details of the 2G variant. I cannot find > anywhere the memory range for the top 1G of memory not even on the > LeMaker docs! :-/
Yup. That's exactly the issue on my end as well - can't seem to find an
authoritative source for that devicetree.
I did find this, though:
https://releases.linaro.org/96boards/hikey/linaro/debian/15.11/
which looks like it has the latest (at least file timestamp-wise) devicetree.
If you look at the memory and reserved memory nodes there, they
are actually much simpler than what we've got:
memory {
device_type = "memory";
reg = <0x0 0x0 0x0 0x40000000>;
};
reserved-memory {
#address-cells = <0x2>;
#size-cells = <0x2>;
ranges;
mcu-buf@05e00000 {
no-map;
reg = <0x0 0x5e00000 0x0 0x100000 0x0
0x740f000 0x0 0x1000>;
};
mbox-buf@06dff000 {
no-map;
reg = <0x0 0x6dff000 0x0 0x1000>;
};
};
So -- just on a whim -- I changed it to:
reg = <0x0 0x0 0x0 0x80000000>;
Interestingly enough, Xen booted, and complained about only 192MB
unallocated this time.
So, I dropped the size of Dom0 to 640M and I got it boot and here's
what I'm seeing as
an output of xl info:
total_memory : 1120
free_memory : 390
It still nowhere close to 2G.
Then I booted the Linux kernel without Xen and it correctly identified
all 2G worth of RAM, and in fact,
when I converted /sys/firmware/devicetree/base back into dts, here's
what I've got:
memory {
device_type = "memory";
reg = <0x0 0x0 0x0 0x5e00000 0x0 0x5f00000 0x0 0x1000
0x0 0x5f02000 0x0 0xefd000 0x0 0x6e00000 0x0 0x60f000 0x0 0x7410000
0x0 0x1aaf0000 0x0 0x21f00000 0x0 0x100000 0x0 0x22000000 0x0
0x1c000000>;
};
reserved-memory {
ranges;
#size-cells = <0x2>;
#address-cells = <0x2>;
ramoops@21f00000 {
ftrace-size = <0x20000>;
console-size = <0x20000>;
reg = <0x0 0x21f00000 0x0 0x100000>;
record-size = <0x20000>;
compatible = "ramoops";
};
linux,cma {
linux,cma-default;
reusable;
size = <0x0 0x8000000>;
compatible = "shared-dma-pool";
};
};
If you look at the REG -- it does now add up to 2Gb, but booting Xen
with it has exactly the
same effect as booting it with: reg = <0x0 0x0 0x0 0x80000000>;
I am attaching a full log, and I see the following in the logs:
(XEN) Allocating 1:1 mappings totalling 720MB for dom0:
(XEN) BANK[0] 0x00000008000000-0x0000001c000000 (320MB)
(XEN) BANK[1] 0x00000040000000-0x00000058000000 (384MB)
(XEN) BANK[2] 0x0000007b000000-0x0000007c000000 (16MB)
Which sort of makes sense, I guess -- but I still don't understand
where all these ranges
are coming from and how come Xen doesn't see the full 2Gb even with various
devicetrees I tried.
Any ideas here would be greatly apprecaited!
Thanks,
Roman.
P.S. Any guess at what these mean?
(XEN) traps.c:1973:d0v0 HSR=0x93880006 pc=0x00ffff87355558
gva=0xffff872f2000 gpa=0x000000000f0000
(XEN) traps.c:1973:d0v0 HSR=0x93880006 pc=0x00ffffb734e558
gva=0xffffb72eb000 gpa=0x000000000f0000
(XEN) traps.c:1973:d0v0 HSR=0x93880006 pc=0x00ffff8f9d2558
gva=0xffff8f96f000 gpa=0x000000000f0000
xen4.log
Description: Binary data
_______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
