Re: [Xen-devel] debian stretch dom0 + xen 4.9 fails to boot

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: 07 June 2017 12:50
> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> Cc: Julien Grall (julien.grall@xxxxxxx) <julien.grall@xxxxxxx>; Andrew
> Cooper <Andrew.Cooper3@xxxxxxxxxx>; xen-devel (xen-
> devel@xxxxxxxxxxxxxxxxxxxx) <xen-devel@xxxxxxxxxxxxxxxxxxxx>; 'Boris
> Ostrovsky' <boris.ostrovsky@xxxxxxxxxx>; Juergen Gross
> <jgross@xxxxxxxx>
> Subject: RE: [Xen-devel] debian stretch dom0 + xen 4.9 fails to boot
> 
> >>> On 07.06.17 at 12:36, <Paul.Durrant@xxxxxxxxxx> wrote:
> >>  -----Original Message-----
> > [snip]
> >> >>
> >> >> TBH: I really can't see what is wrong with that patch. The only change
> >> >> which should be able to break something seems to be the reduction of
> >> the
> >> >> wakeup stack size to 3kB, but this shouldn't affect booting the system
> >> >> at all...
> >> >>
> >> > Yeah, my next test is going to be increasing the size of the wakeup stack
> >> again, but there is really nothing obviously wrong with the patch.
> >>
> >> My gut feeling is that there is some path through boot (tickled by these
> >> two machines) which is clobbering the wrong piece of memory, which was
> >> previously safe and is now not, because of the rearrangements here.
> >>
> >> Debugging these machines is very tricky, because they have no serial or
> >> IMPI whatsoever.
> >>
> >
> > It does appear to be a layout issue. If I modify the code to just set
> > wakeup_stack to wakeup_stack_start + PAGE_SIZE, so it has the full 4k
> then I
> > still get the problem. However if I then move that code block that includes
> > wakeup.S and move it to the end of trampoline.S so that wakup code and
> stack
> > are once again located at the end then the problem goes away.
> 
> Could you do the following two things:
> 1) Subtract, say, 4k from trampoline_phys right before setting it
> (immediately ahead of trampoline_setup)? Ideally you'd also log
> the resulting value (in case it works).

Ok, I'll have a go at that.

> 2) Provide the E820 map of that box.
> I'm suspecting the BIOS might use an EBDA without recording it in
> the low BIOS data area. If it's reported in E820 that would then
> likely be the final kick for us to obey to the E820 map when
> determining where to put the trampoline.
> 

The stretch kernel booted bare-metal reports:

[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x00000000000963ff] usable
[    0.000000] BIOS-e820: [mem 0x0000000000096400-0x000000000009ffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x0000000034d53fff] usable
[    0.000000] BIOS-e820: [mem 0x0000000034d54000-0x0000000034d54fff] ACPI NVS
[    0.000000] BIOS-e820: [mem 0x0000000034d55000-0x0000000034d9efff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000034d9f000-0x000000003bee1fff] usable
[    0.000000] BIOS-e820: [mem 0x000000003bee2000-0x000000003c22cfff] reserved
[    0.000000] BIOS-e820: [mem 0x000000003c22d000-0x000000003c268fff] ACPI data
[    0.000000] BIOS-e820: [mem 0x000000003c269000-0x000000003cb61fff] ACPI NVS
[    0.000000] BIOS-e820: [mem 0x000000003cb62000-0x000000003d2fdfff] reserved
[    0.000000] BIOS-e820: [mem 0x000000003d2fe000-0x000000003d2fefff] usable
[    0.000000] BIOS-e820: [mem 0x000000003d300000-0x000000003d3fffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000e0000000-0x00000000efffffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fe000000-0x00000000fe010fff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000100000000-0x00000008beffffff] usable

  Paul

> Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel