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: 08 June 2017 14:19
> 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>;
> 'BorisOstrovsky' <boris.ostrovsky@xxxxxxxxxx>; Juergen Gross
> <jgross@xxxxxxxx>
> Subject: RE: [Xen-devel] debian stretch dom0 + xen 4.9 fails to boot
> 
> >>> On 08.06.17 at 14:42, <Paul.Durrant@xxxxxxxxxx> wrote:
> > For those following this...
> >
> > By poking characters at the screen and bisecting where they stopped, I
> have
> > narrowed the problem to the code in edd.S. I can successfully boot by
> setting
> > opt_edd=off on the Xen cmd line and I can also boot with the following
> patch
> > applied:
> >
> > diff --git a/xen/arch/x86/boot/edd.S b/xen/arch/x86/boot/edd.S
> > index 73371f98b5..5409f1d9a1 100644
> > --- a/xen/arch/x86/boot/edd.S
> > +++ b/xen/arch/x86/boot/edd.S
> > @@ -148,5 +148,6 @@ GLOBAL(boot_mbr_signature_nr)
> >          .byte   0
> >  GLOBAL(boot_mbr_signature)
> >          .fill   EDD_MBR_SIG_MAX*8,1,0
> > +       .align  4096
> >  GLOBAL(boot_edd_info)
> > -        .fill   512,1,0                         # big enough for a disc
> > sector
> > +        .fill   4096,1,0                         # big enough for a disc
> > sector
> >
> > (based on a hunch that the BIOS defaults to a 4K sector for my NVMe drive)
> >
> > I need to investigate some more but I do wonder whether the EDD info
> should
> > be read first to determine the appropriate size of memory buffer to use
> when
> > issuing the read of the MBR. Hardcoding a 4k reservation seems like the
> wrong
> > thing to do, even if it is sufficient for this BIOS.
> 
> boot_edd_info is being used for two things - reading the MBR of
> each disk and storing data retrieved from INT 13 Fn 41 and 48.
> The latter occupies 492 bytes (6 times 8+74). Which would make
> me guess the system has a 4k disk, and the BIOS doesn't abstract
> away this characteristic when handling INT 13 Fn 02 (which is
> supposed to only act in multiples of 512-byte sectors, as opposed
> to Fn 42).
> 
> The alternative of Fn 48 overflowing its buffer would seem less
> likely, especially with the buffer holding a size on input.
> 
> Do you, btw, really need both the size and alignment increases?
> 

More investigation has characterized the problem a little more but I still 
don't understand precisely what it happening. The trampoline code sets %ds to 
0x86 and the image is loaded at offset 0 in that segment, i.e. it is located at 
0x86000. The boot_edd_info 512 byte range ends up spanning the 0x87000 boundary 
and when this area is used for reading the MBR I see the lock-up. If I insert 
some bytes sufficient to push boot_edd_info up to or beyond 0x87000 then the 
system boots and I have verified that bytes located immediately before or after 
boot_edd_info are not scribbled on by the int13 call. However, if I arrange for 
boot_edd_info to be located even just one byte below 0x87000 then the system 
again fails to boot.
I am now attempting to grab some memory below the trampoline, pattern fill it 
and then try to figure out if there is any collateral damage from the int13 
that is further afield from the actual value in es:bx, 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?

  Paul

> Jan


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