On 08/31/2018 06:14 PM, Julien Grall wrote: Hi,
> On 08/31/2018 06:01 PM, Amit Singh Tomar wrote: >> While porting XEN on Amlogic SoC we found that in absence of >> image_size field of XEN image header, bootloader(U-BOOT) >> relocates[1] the XEN image to an address(not appropriate >> for Amlogic) derived from text_offset. > > IHMO, this is a bug in U-Boot rather than Xen. The current format, while > old, is still valid. As tempting at is it to blame the "other guy", I think it's really Xen not up to par here. The kernel doc [2] says: ... "Where image_size is zero, text_offset can be assumed to be 0x80000." This is what U-Boot implements. So you load Xen, say, to 16MB into DRAM, and U-Boot moves it to 512 KB, again complying with the kernel doc: "NOTE: versions prior to v4.6 cannot make use of memory below the physical offset of the Image so it is recommended that the Image be placed as close as possible to the start of system RAM." U-Boot derives this property from bit 3 of the flags being clear. > In the case of U-Boot, you usually need to be really careful on the > position of all the blobs (e.g Xen, DTB, Kernel, Initramfs) in the memory. Yes, and in fact it seems one can work around this by cleverly constructing the load addresses, but it's really time to bring Xen into the 21st century (or so) when it comes to the kernel image header ;-) >> This unwanted situation can be fixed by updating image_size field >> along side kernel flags so that image wouldn't relocate from initial >> load address. > > I think the first step is to fix your U-boot and rethink where you load > your binaries. I think U-Boot perfectly complies with the kernel document. Xen not so much. The kernel image format was deliberately updated to become more flexible with certain memory layout situations as we have here. There is for instance a problem if there is something precious at 512KB into DRAM (secure memory owned by firmware), as regardless of the load addresses the user chooses U-Boot will (rightfully!) revert to the original "512KB into DRAM" address to keep compatibility with older kernels - and it believes Xen is such a one because of the ancient header format. But ... > Regarding the patch in itself, I think this is a good addition as it > allow Xen to be loaded in more places. But please rewrite the commit > message accordingly, this is an update to a new version. I totally agree with that, the commit message should be reworded to stress that we want to comply with a newer version of the kernel image header (which is around for four years by now!), and just mention that it fixes problems with non-ancient U-Boots on certain platforms as an additional reason. >> [1]:https://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/lib/image.c;h=699bf44e702f7a7084997406203fd7d2aaaf87fa;hb=HEAD#l50 >> >> >> These changes are derived from kernel v4.18 files >> >> Signed-off-by: Amit Singh Tomar <amittome...@gmail.com> >> --- >> xen/arch/arm/arm64/head.S | 5 ++- >> xen/arch/arm/arm64/lib/assembler.h | 11 +++++ >> xen/arch/arm/xen.lds.S | 3 ++ >> xen/include/asm-arm/arm64/linux_header_vars.h | 62 >> +++++++++++++++++++++++++++ >> 4 files changed, 79 insertions(+), 2 deletions(-) >> create mode 100644 xen/include/asm-arm/arm64/linux_header_vars.h >> >> diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S >> index d63734f..ce72c95 100644 >> --- a/xen/arch/arm/arm64/head.S >> +++ b/xen/arch/arm/arm64/head.S >> @@ -25,6 +25,7 @@ >> #include <asm/early_printk.h> >> #include <efi/efierr.h> >> #include <asm/arm64/efibind.h> >> +#include "lib/assembler.h" >> #define PT_PT 0xf7f /* nG=1 AF=1 SH=11 AP=01 NS=1 ATTR=111 T=1 >> P=1 */ >> #define PT_MEM 0xf7d /* nG=1 AF=1 SH=11 AP=01 NS=1 ATTR=111 T=0 >> P=1 */ >> @@ -120,8 +121,8 @@ efi_head: >> add x13, x18, #0x16 >> b real_start /* branch to kernel start */ >> .quad 0 /* Image load offset from start >> of RAM */ >> - .quad 0 /* reserved */ >> - .quad 0 /* reserved */ >> + le64sym _kernel_size_le /* Effective size of kernel >> image, little-endian */ >> + le64sym _kernel_flags_le /* Informative flags, >> little-endian */ > > All the dance for to convert to little endian is not necessary on Xen. > Please rework your series to avoid such code, this would also reduce > quite significantly the series. Indeed! Cheers, Andre. [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/arm64/booting.txt#n98 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
