Hi Paul,
On 06/06/17 16:51, Paul Durrant wrote:
-----Original Message-----
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: 06 June 2017 16:11
To: Paul Durrant <paul.durr...@citrix.com>
Cc: xen-devel (xen-de...@lists.xenproject.org) <xen-
de...@lists.xenproject.org>
Subject: Re: [Xen-devel] debian stretch dom0 + xen 4.9 fails to boot
On 06.06.17 at 16:32, <paul.durr...@citrix.com> wrote:
I've been having fun setting up a new test rig...
I have a skull canyon NUC and I put debian stretch (rc4) on it (so that's a
4.9 kernel) and then tried building and installing the latest Xen staging-4.9
code. The system failed to boot... basically it got stuck before even
managing to get sufficiently into Xen to spit out anything on the console.
Xen 4.8 OTOH booted just fine so I started bisecting and after 14 iterations
I got down to the following commit is being the problem:
commit c0655e492e6b33e26ec9cd33f59725d0db89cdd0
Author: Juergen Gross <jgr...@suse.com>
Date: Fri Mar 24 14:18:54 2017 +0100
x86: split boot trampoline into permanent and temporary part
The hypervisor needs a trampoline in low memory for early boot and
later for bringing up cpus and during wakeup from suspend. Today this
trampoline is kept completely even if most of it isn't needed later.
Split the trampoline into a permanent part and a temporary part needed
at early boot only. Introduce a new entry at the boundary.
Reduce the stack for wakeup code in order for the permanent
trampoline to fit in a single page. 4k of stack seems excessive, about
3k should be more than enough.
Add an ASSERT() to the linker script to ensure the wakeup stack is
always at least 3k.
Signed-off-by: Juergen Gross <jgr...@suse.com>
Reviewed-by: Jan Beulich <jbeul...@suse.com>
To verify this I checked out master, reverted that commit, and tried again.
The NUC still booted fine.
Well, interesting, but I don't think it is very realistic to expect any
fix with just the information you supply. There must be something
rather special about that system, and likely it would help if we
knew what that is. E.g. an unusual E820 map. Worse would be if
they used memory outside of properly marked E820 regions in a
way colliding with what we do.
Otherwise I'm afraid we need to hope for you to debug the issue.
Yes, I was posting this more a heads-up for the moment, so that 4.9 does not go
out with this regression.
I would have appreciated to be CCed in this e-mail as this concern 4.9
release... Please take the habit to CC the release manager for anything
targeting a release.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
