> -----Original Message----- > From: Jan Beulich [mailto:[email protected]] > Sent: 09 June 2017 16:41 > To: Paul Durrant <[email protected]> > Cc: Julien Grall ([email protected]) <[email protected]>; Andrew > Cooper <[email protected]>; xen-devel(xen- > [email protected]) <[email protected]>; 'Boris > Ostrovsky' <[email protected]>; Juergen Gross > <[email protected]> > Subject: RE: [Xen-devel] debian stretch dom0 + xen 4.9 fails to boot > > >>> On 09.06.17 at 17:14, <[email protected]> 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 [email protected] https://lists.xen.org/xen-devel
