[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] debian stretch dom0 + xen 4.9 fails to boot
>>> On 08.06.17 at 14:42, <Paul.Durrant@xxxxxxxxxx> 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@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |