> -----Original Message----- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 08 June 2017 14:19 > 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>; > 'BorisOstrovsky' <boris.ostrov...@oracle.com>; Juergen Gross > <jgr...@suse.com> > Subject: RE: [Xen-devel] debian stretch dom0 + xen 4.9 fails to boot > > >>> On 08.06.17 at 14:42, <paul.durr...@citrix.com> 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.
Yes, I tested with edd=skipmbr on the command line (and no patch applied) and the system booted, so it's definitely the MBR read that is at fault. > > Do you, btw, really need both the size and alignment increases? > At first I tried just increasing the .fill to 4096 but that did not seem to work. I have not found anything that says int13 0x2 buffers need to be aligned... but the BIOS being buggy in this respect I guess it could easily require that. I'm just testing some more code to try to see exactly how much memory the MBR read scribbles on. Paul > Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
