|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] REGRESSION: Xen 4.13 RC5 fails to bootstrap Dom0 on ARM
On Tue, Dec 17, 2019 at 11:26 AM Stefano Stabellini
<sstabellini@xxxxxxxxxx> wrote:
>
> On Tue, 17 Dec 2019, Roman Shaposhnik wrote:
> > On Tue, Dec 17, 2019 at 10:30 AM Stefano Stabellini
> > <sstabellini@xxxxxxxxxx> 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
> > > > > <sstabellini@xxxxxxxxxx> 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 <julien.grall@xxxxxxx>
> > > > 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 <julien.grall@xxxxxxx>
> > > > Acked-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>
> > >
> > > 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
Attachment:
xen4.log _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |