[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Unable to boot Linux with master EDK2



On Fri, 18 Jan 2019 at 19:39, Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> wrote:
>
> On Fri, 18 Jan 2019 at 19:30, Julien Grall <julien.grall@xxxxxxx> wrote:
> >
> > Hi all,
> >
> > I am trying to boot a Xen guest using the latest EDK2 master (cce9d76358
> > "BaseTools: Allow empty value for HiiPcd in Dsc"), GRUB and Linux 5.0-rc2.
> >
> > The last code executed by Linux is when installing the virtual address
> > map in the EFI stub and then it seems to get stuck. I don't have much
> > information from the console:
> >
> > InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B 7E041040
> > Loading driver at 0x00068C70000 EntryPoint=0x00069D65664
> > Loading driver at 0x00068C70000 EntryPoint=0x00069D65664
> > InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 7DF6AB18
> > ProtectUefiImageCommon - 0x7E041040
> >   - 0x0000000068C70000 - 0x0000000002006000
> > SetUefiImageMemoryAttributes - 0x0000000068C70000 - 0x0000000000001000 
> > (0x0000000000004008)
> > SetUefiImageMemoryAttributes - 0x0000000068C71000 - 0x00000000011CD000 
> > (0x0000000000020008)
> > SetUefiImageMemoryAttributes - 0x0000000069E3E000 - 0x0000000000E38000 
> > (0x0000000000004008)
> > EFI stub: Booting Linux Kernel...
> > EFI stub: Using DTB from configuration table
> > EFI stub: Exiting boot services and installing virtual address map...
> > XenBus: Set state to 5
> > XenBus: Set state to 5, done
> > XenPvBlk: waiting backend state 5, current: 4
> > XenStore: Watch event 7E957398
> > XenBus: Set state to 6
> > XenBus: Set state to 6, done
> > XenPvBlk: waiting backend state 6, current: 5
> > XenStore: Watch event 7E957398
> > XenBus: Set state to 1
> > XenBus: Set state to 1, done
> > Xen GrantTable, removing 38003
> > Xen GrantTable, removing 38002
> > Xen GrantTable, removing 38001
> > Xen GrantTable, removing 38000
> > SetUefiImageMemoryAttributes - 0x000000007F360000 - 0x0000000000040000 
> > (0x0000000000000008)
> > SetUefiImageMemoryAttributes - 0x000000007BFF0000 - 0x0000000000040000 
> > (0x0000000000000008)
> > SetUefiImageMemoryAttributes - 0x000000007BFA0000 - 0x0000000000040000 
> > (0x0000000000000008)
> > SetUefiImageMemoryAttributes - 0x000000007BF00000 - 0x0000000000040000 
> > (0x0000000000000008)
> > SetUefiImageMemoryAttributes - 0x000000007BE60000 - 0x0000000000040000 
> > (0x0000000000000008)
> > SetUefiImageMemoryAttributes - 0x000000007BDC0000 - 0x0000000000040000 
> > (0x0000000000000008)
> >
> > The bisector pointed to the following commit:
> >
> > commit 2f4a5a9f4c17ed88aaa3114d1e161e42cb80a9bf
> > Author: Dandan Bi <dandan.bi@xxxxxxxxx>
> > Date:   Thu Jan 3 15:31:23 2019 +0800
> >
> >     MdePkg/BasePeCoffLib: Add more check for relocation data
> >
> >     REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1426
> >
> >     V2:
> >     (1) Add NULL pointer check for the input parameters
> >     (2) Add check for the "Adjust" value before applying fix ups.
> >
> >     In function PeCoffLoaderRelocateImageForRuntime, it doesn't
> >     do much check when do relocation. For API level consideration,
> >     it's not safe enough.
> >     So this patch is to replace the same code logic with function
> >     PeCoffLoaderImageAddress which will cover more validation.
> >
> >     Cc: Michael D Kinney <michael.d.kinney@xxxxxxxxx>
> >     Cc: Liming Gao <liming.gao@xxxxxxxxx>
> >     Contributed-under: TianoCore Contribution Agreement 1.1
> >     Signed-off-by: Dandan Bi <dandan.bi@xxxxxxxxx>
> >     Reviewed-by: Liming Gao <liming.gao@xxxxxxxxx>
> >
> > Any ideas what could have gone wrong?
> >

Yes, that patch broke lots of platforms: OVMF, ArmVirtQemu and ARM
Juno as well. You need the following patch to fix it

https://lists.01.org/pipermail/edk2-devel/2019-January/035372.html

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.