Re: debian stretch dom0 + xen 4.9 fails to boot

[Paul Durrant <Paul.Durrant@citrix.com>]

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: 12 June 2017 12:12
> To: Paul Durrant <Paul.Durrant@citrix.com>
> Cc: Julien Grall (julien.grall@arm.com) <julien.grall@arm.com>; Andrew
> Cooper <Andrew.Cooper3@citrix.com>; xen-devel(xen-
> devel@lists.xenproject.org) <xen-devel@lists.xenproject.org>; 'Boris
> Ostrovsky' <boris.ostrovsky@oracle.com>; Juergen Gross
> <jgross@suse.com>
> Subject: RE: [Xen-devel] debian stretch dom0 + xen 4.9 fails to boot
> 
> >>> On 12.06.17 at 12:53, <Paul.Durrant@citrix.com> wrote:
> >>  -----Original Message-----
> > [snip]
> >> > >
> >> > > What do you think it best to do for Xen 4.9? Hardcoding a 4k alignment
> is
> >> > > clearly easy and would work around this BIOS issue but, as you say, it
> >> does
> >> > > grow the image. Reverting Juergen's patch also works round the issue,
> >> but
> >> > > that is more by luck. Re-working the code is preferable, but I guess it's
> >> too
> >> > > late to introduce such code-churn in 4.9.
> >> >
> >> > Reverting Jürgen's code is out of question with all the information
> >> > you've gathered by now. I think re-working the EDD code slightly
> >> > is the best option. Would you mind giving the attached patch a
> >> > try? This still slightly grows the trampoline due to a few more
> >> > instructions being needed, but should still be far better than
> >> > embedding a whole 4k buffer (and then later finding a BIOS/disk
> >> > combination which wants even more). Note that I've left a tiny
> >> > bit of debugging code in there.
> >> >
> >>
> >> Sure, I'll give that a go now.
> >>
> >
> > That worked fine:
> >
> > (XEN) MBR[80] @ 85e0 (86000)
> 
> But that's contrary to your earlier findings: Didn't you say simply
> avoiding a 4k-boundary wasn't enough? And it certainly tells us
> that this isn't a 4k drive (or at least the BIOS doesn't surface 4k
> sectors) - I was really expecting a larger gap between the two
> logged values.
> 

I'll go dump out the edd and double check what it is saying.

My findings indicated that the problem seemed to be doing a read that spanned a 4k boundary caused a problem, so using 0x85e00 would be safe. The anomaly was that simply aligning the edd_info buffer and a 512 byte boundary and continuing to use that for reading did not work.
 
> > so you can add my Tested-by to that.
> 
> I.e. I'm not sure about this, as I'm still uncertain whether some
> corruption didn't again occur. Of course APs coming up properly
> would already be a relatively good sign (as now the permanent
> part of the trampoline would be the predestined area for
> corruption to occur in).
> 

None of my findings ever indicated memory corruption (although there, of course, may have been some that I happened to miss), but rather misbehaviour of the int13 handler itself - either locking up, having odd effects (e.g. black screen), or both.

  Paul

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