Re: debian stretch dom0 + xen 4.9 fails to boot

[Julien Grall <julien.grall@arm.com>]

Hi Paul,

On 06/06/17 16:51, Paul Durrant wrote:
>> -----Original Message-----
>> From: Jan Beulich [mailto:JBeulich@suse.com]
>> Sent: 06 June 2017 16:11
>> To: Paul Durrant <Paul.Durrant@citrix.com>
>> Cc: xen-devel (xen-devel@lists.xenproject.org) <xen-
>> devel@lists.xenproject.org>
>> Subject: Re: [Xen-devel] debian stretch dom0 + xen 4.9 fails to boot
>>
>>>>> On 06.06.17 at 16:32, <Paul.Durrant@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 <jgross@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 <jgross@suse.com>
>>>     Reviewed-by: Jan Beulich <jbeulich@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