On 08.12.2022 14:51, Julien Grall wrote: > On 08/12/2022 12:49, Ayan Kumar Halder wrote: >> Currently, kernel_uimage_probe() does not set info->zimage.start. As a >> result, it contains the default value (ie 0). This causes, >> kernel_zimage_place() to treat the binary (contained within uImage) as >> position independent executable. Thus, it loads it at an incorrect address. >> >> The correct approach would be to read "uimage.ep" and set >> info->zimage.start. This will ensure that the binary is loaded at the >> correct address. > > In non-statically allocated setup, a user doesn't know where the memory > for dom0/domU will be allocated. > > So I think this was correct to ignore the address. In fact, I am worry > that... > >> --- a/xen/arch/arm/kernel.c >> +++ b/xen/arch/arm/kernel.c >> @@ -222,6 +222,8 @@ static int __init kernel_uimage_probe(struct kernel_info >> *info, >> if ( len > size - sizeof(uimage) ) >> return -EINVAL; >> >> + info->zimage.start = be32_to_cpu(uimage.ep); > ... this will now ended up to break anyone that may have set an address > but didn't care where it should be loaded. > > I also understand your use case but now, we have contradictory > approaches. I am not entirely sure how we can solve it. We may have to > break those users (Cc some folks that may use it). But we should figure > out what is the alternative for them.
I don't know anything about the uimage format, but is the ep field required to be non-zero? If not, it being non-zero would retain prior behavior. Jan
