Re: debian stretch dom0 + xen 4.9 fails to boot

From: "Jan Beulich" <JBeulich@suse.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
Cc: Juergen Gross <jgross@suse.com>,
	AndrewCooper <Andrew.Cooper3@citrix.com>,
	"Julien Grall (julien.grall@arm.com)" <julien.grall@arm.com>,
	'Boris Ostrovsky' <boris.ostrovsky@oracle.com>,
	"xen-devel(xen-devel@lists.xenproject.org)"
	<xen-devel@lists.xenproject.org>
Subject: Re: debian stretch dom0 + xen 4.9 fails to boot
Date: Fri, 09 Jun 2017 09:41:16 -0600	[thread overview]
Message-ID: <593ADDBC020000780016171F@prv-mh.provo.novell.com> (raw)
In-Reply-To: <f579ca3d79c34baab75f63a3810975bb@AMSPEX02CL03.citrite.net>

>>> On 09.06.17 at 17:14, <Paul.Durrant@citrix.com> 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.

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?

Jan

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