> -----Original Message----- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 12 June 2017 16:08 > To: Paul Durrant <paul.durr...@citrix.com> > Cc: Julien Grall (julien.gr...@arm.com) <julien.gr...@arm.com>; Andrew > Cooper <andrew.coop...@citrix.com>; xen-devel(xen- > de...@lists.xenproject.org) <xen-de...@lists.xenproject.org>; 'Boris > Ostrovsky' <boris.ostrov...@oracle.com>; Juergen Gross > <jgr...@suse.com> > Subject: RE: [Xen-devel] debian stretch dom0 + xen 4.9 fails to boot > > >>> On 12.06.17 at 16:43, <paul.durr...@citrix.com> wrote: > >> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of > >> Paul Durrant > >> Sent: 12 June 2017 15:29 > >> > From: Jan Beulich [mailto:jbeul...@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". >
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@lists.xen.org https://lists.xen.org/xen-devel
