>>> 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. Do you, btw, really need both the size and alignment increases? Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
