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: 12 June 2017 16:08
> 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>; 'Boris
> Ostrovsky' <boris.ostrovsky@xxxxxxxxxx>; Juergen Gross
> <jgross@xxxxxxxx>
> Subject: RE: [Xen-devel] debian stretch dom0 + xen 4.9 fails to boot
> 
> >>> On 12.06.17 at 16:43, <Paul.Durrant@xxxxxxxxxx> wrote:
> >> From: Xen-devel [mailto:xen-devel-bounces@xxxxxxxxxxxxx] On Behalf Of
> >> Paul Durrant
> >> Sent: 12 June 2017 15:29
> >> > From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> >> > Sent: 12 June 2017 14:55
> >> > >> > 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.
> >> >
> >> > But a 512-byte aligned 512-byte buffer can't possibly cross a page
> >> > boundary.
> >>
> >> Indeed, which is why I was perplexed. I found that 0x60e00 was ok. Your
> >> patch chose 0x85e00, which was ok too, but for some reason a '.align 512'
> in
> >> front of boot_edd_info yielded an address which was not ok. I just
> checked
> >> what address that yielded though (by booting with edd=off to avoid the
> >> hang) and it was 0x86f40... which clearly means that '.align 512' is not
> doing
> >> what I thought it would do.
> >
> > No, the problem turns out to be the GLOBAL() macro which, in assembly
> files,
> > contains an implicit .align 16!
> 
> No, I don't think so - two successive .align don't have any bad effect,
> the higher value will be it. Instead I think you're suffering from the
> copying of the trampoline space to low memory: What is aligned to a
> 512-byte boundary in the image won't necessarily be in low memory,
> unless trampoline_start is also aligned at least as much.
> 
> But with this likely having been the problem in your experiments I'm
> not feeling sufficiently reassured to submit the patch "officially".
> 

I see you submitted the patch.

I'm happy now because the anomaly in what I was seeing is explained. I was 
convinced that, at some stage, I had found that the image was 64k aligned in 
memory. I was clearly wrong.

  Paul

> Jan
> 
> Jan


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