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

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Boris Ostrovsky [mailto:boris.ostrovsky@xxxxxxxxxx]
> Sent: 09 June 2017 14:52
> To: Jan Beulich <JBeulich@xxxxxxxx>; 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>; Juergen
> Gross <jgross@xxxxxxxx>
> Subject: Re: [Xen-devel] debian stretch dom0 + xen 4.9 fails to boot
> 
> On 06/09/2017 09:05 AM, Jan Beulich wrote:
> >>>> On 09.06.17 at 14:19, <Paul.Durrant@xxxxxxxxxx> wrote:
> >> ..., but all this has
> >> got me wondering why Xen bothers to read the MBR, or the EDD info for
> that
> >> matter? EDD or MBR signatures are returned by the
> XENPF_firmware_info
> >> hypercall, and Linux does seem to have code called early on in
> >> xen_start_kernel() that does make such hypercalls, but it also appears to
> be
> >> able to boot happily if I put edd=off on my Xen command line, so is this
> code
> >> really necessary?
> > Well, that's a question to the Linux folks. I would guess there's
> > management code around wanting that info, but I'm not sure. Us
> > doing this is simply because of Linux wanting it and having no
> > other way to get at least some of this information (it could surely
> > read the MBRs, but it wouldn't be able to associate them with
> > BIOS drive numbers used for the other EDD information obtained).
> 
> Not sure what it is for. Perhaps there are some tools that poke into sysfs?
> 
> 
> commit 96f28bc66adb1414cfc9405ff80cfffdc44edd84
> Author: David Vrabel <david.vrabel@xxxxxxxxxx>
> Date:   Wed Apr 3 17:31:50 2013 +0100
> 
>     x86/xen: populate boot_params with EDD data
> 
>     During early setup of a dom0 kernel, populate boot_params with the
>     Enhanced Disk Drive (EDD) and MBR signature data.  This makes
>     information on the BIOS boot device available in /sys/firmware/edd/.
> 
>     Signed-off-by: David Vrabel <david.vrabel@xxxxxxxxxx>
>     Acked-by: Jan Beulich <jbeulich@xxxxxxxx>
>     Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>

Interesting. The Xen side of things seems to have been there forever:

commit 79e96982cade240531d7d84fa5b966b2b64c04af
Author: kfraser@localhost.localdomain <kfraser@localhost.localdomain>
Date:   Tue Jun 12 14:03:09 2007 +0100

    x86: Gather BIOS EDD info during boot.
    Still needs plumbing to dom0.
    Signed-off-by: Keir Fraser <keir@xxxxxxxxxxxxx>

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.

  Paul


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