[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] EFI and multiboot2 devlopment work for Xen
>>> Ian Campbell <ian.campbell@xxxxxxxxxx> 10/23/13 10:32 AM >>> >The second (standard PE/COFF entry point) can be launched using the UEFI >chainloader call. AIUI this should work with xen.efi today. There are >some limitations however, firstly there is no way to pass additional >blobs and so the launched image must load e.g. dom0 and initrd itself, >which Linux does by processing the initrd= option in the command line >and using UEFI functionality to load the blobs from disk. Xen does by >reading its own config file and loading dom0 + initrd based on that. I >assume this means that chainload doesn't call ExitBootServices (anyone >can confirm?). Another limitation of this is that the UEFI functionality >to load stuff from disk can only read from FAT partitions. Again that's only a pseudo limitation: Rather than implementing support for other file systems in GrUB, it should be implemented as EFI module. Then any subsequent EFI binary would benefit from this. (Obviously, as a half hearted intermediate solution, GrUB - which iiuc stays in memory after transferring control - could export its file system support to its descendants). > It's not >clear to me if this mechanism limits only the loading of additional >blobs from FAT or if that applies to the kernel image itself. Only the additional blobs would be affected. > The >kernel is PIC on entry so no relocations are actually needed. In theory >the Linux EFI stub could instead have included a NULL relocation table >but doesn't. (I expect Xen is in the same boat WRT relocations). No, Xen definitely needs its relocations processed. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |