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>,
	Andrew Cooper <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: Mon, 12 Jun 2017 09:07:59 -0600	[thread overview]
Message-ID: <593ECA6F0200007800162113@prv-mh.provo.novell.com> (raw)
In-Reply-To: <02280900d1ca45338e7dd96cb12c8165@AMSPEX02CL03.citrite.net>

>>> On 12.06.17 at 16:43, <Paul.Durrant@citrix.com> wrote:
>> From: Xen-devel [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of
>> Paul Durrant
>> Sent: 12 June 2017 15:29
>> > From: Jan Beulich [mailto:JBeulich@suse.com]
>> > 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".

Jan

Jan

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