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

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Xen-devel [mailto:xen-devel-bounces@xxxxxxxxxxxxx] On Behalf Of
> Paul Durrant
> Sent: 09 June 2017 16:47
> To: 'Jan Beulich' <JBeulich@xxxxxxxx>
> Cc: Juergen Gross <jgross@xxxxxxxx>; Andrew Cooper
> <Andrew.Cooper3@xxxxxxxxxx>; Julien Grall (julien.grall@xxxxxxx)
> <julien.grall@xxxxxxx>; 'Boris Ostrovsky' <boris.ostrovsky@xxxxxxxxxx>;
> xen-devel(xen-devel@xxxxxxxxxxxxxxxxxxxx) <xen-
> devel@xxxxxxxxxxxxxxxxxxxx>
> Subject: Re: [Xen-devel] debian stretch dom0 + xen 4.9 fails to boot
> 
> > -----Original Message-----
> > From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> > Sent: 09 June 2017 16:41
> > 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 09.06.17 at 17:14, <Paul.Durrant@xxxxxxxxxx> wrote:
> > > I've characterised the issue some more and it appears to be an overflow
> > > inside the int13 handler if es:bx is less than 512 bytes below a 4k
> boundary.
> > > I modified the code to use a hardcoded segment, which I set at 0x6000,
> and
> > > all values of bx up to 0xe00 resulted in a good MBR signature. Values
> above
> > > 0xe00 but below 0xe20 resulted in the buffer not being identified as a
> valid
> > > MBR (I guess because the 0xAA55 fell off) and values of bx above 0xe20
> > > resulted in either a hang (sometimes with a black screen) or a reboot.
> > > This led me to believe that backing out all my debug code and adding a
> > > '.align 512' just before the definition of boot_edd_info should result in 
> > > a
> > > successful boot. Alas this appears not to be the case... I seem to need at
> > > least 2k alignment. I wonder whether it may be more robust to go for 4k
> > > alignment though.
> >
> > At least until we've seen (and merged) Jürgen's further trampoline
> > adjustments, we need to be careful with growing its overall size.
> > Memory below 1Mb is known to be scarce specifically on some EFI
> > systems, and we're currently still allocating space for all of the
> > trampoline instead of just its permanent part. Even on non-EFI
> > systems I'd prefer the trampoline to remain as small as possible.
> >
> > With what you say about the requirements this buggy BIOS has
> > I wonder whether we couldn't help ourselves by doing I/O to
> > other than boot_edd_info. Especially if we did the EDD stuff last
> > (rather than before video), a good portion of the boot time only
> > trampoline space will no longer be needed.
> 
> I think that would be sensible, but I was looking for the simplest
> fix/workaround possible for 4.9 and setting the alignment seems to it.
> 
> >
> > Otoh I wonder where a system this buggy shouldn't be declared
> > unusable (until a suitable BIOS update becomes available). Did
> > you check what constraints Linux places on the buffer used for
> > I/O? IOW can you judge whether bare metal Linux just happens
> > to work (just like older Xen did), or has been fixed to cope with
> > such a situation?
> >
> 
> I'll go have a look and the linux edd code. I'm also trying a BIOS update 
> (which
> is proving to be trickier than I thought as it seems to have killed 
> networking in
> some weird way).

Looking at the code in arch/x86/boot/edd.c in Linux, it sector aligns the 
buffer into which it reads the MBR and the sector size is pulled from the EDD 
which means, I believe, that the MBR read on the skull canyon would be 4k 
aligned.

What do you think it best to do for Xen 4.9? Hardcoding a 4k alignment is 
clearly easy and would work around this BIOS issue but, as you say, it does 
grow the image. Reverting Juergen's patch also works round the issue, but that 
is more by luck. Re-working the code is preferable, but I guess it's too late 
to introduce such code-churn in 4.9.

  Paul

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