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: 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).

  Paul

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