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

Re: [XEN v3] xen/arm: Probe the entry point address of an uImage correctly


  • To: Julien Grall <julien@xxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, Ayan Kumar Halder <ayan.kumar.halder@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • From: Ayan Kumar Halder <ayankuma@xxxxxxx>
  • Date: Tue, 20 Dec 2022 12:51:45 +0000
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=RMKV+B326RtZumuiokKFM0kfwewgRomynsS6USFV6HQ=; b=RGF8V5Aq6G1Sk3cdjOdV+Y0yO8Zwa6tCwKV6ijSHTXHTklJsjeNK40N0+7Mykq0AZ/8D5H0PyZNN++wBRqY33tt89MptW2PH2cnXTXk/Kp+fXUukVUusN35Ex7BAM+TGUiUnW+ZUc10hCs4OS/J0q42i5UBb5tKMyOw2j6z3LFGZgxDA4Nx3KGdXy6NHgbA/2AK6Cm3Q2U+WnY+ucT29vUoWo3PVIU5g2I39cDT3NNJWgBta7ztiO5raRQrJyfXv0LDi0wcUHlC7SfvmTMjFxSxjTeTF80ysILxHQt41QVGbHw+93XWkWZfVSUUOYBmkFLi4GYInGPgb2pr27KI/oQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TjxcDjMT4FCUrIXTNbODy83WT7RoiH1Yojpo6V2Ndi4GLzj66H5x/nNLg7athfcRl9RG9nr7fKH09QXTx4I8FJBjFQ2MoGW7wj5Q/VJFrkTZ9BJuu9mcs6FTWAH1PYxqkgiNp4VJfTtfmyIfi8jY43jslILQ99rcBn3gahF63CycpHcgtG1sHp8fCdkI1qTqcMSuAyyTOR8yGnMSdCS1piqLwdIP6MGn4bPLjLIr+y5f6Vsx9njQeU+rkXvEFLf1HiTHUH0ix4d9zJsYnIUETvyCjrIVxMdu/DoIoL56hr6ER4KZ0Vqg6nwr+L3jPQP+ugL24gFtIJtT2x60lyKk/Q==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com;
  • Cc: sstabellini@xxxxxxxxxx, stefano.stabellini@xxxxxxx, Volodymyr_Babchuk@xxxxxxxx, bertrand.marquis@xxxxxxx
  • Delivery-date: Tue, 20 Dec 2022 12:52:08 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>


On 20/12/2022 12:14, Julien Grall wrote:
Hi Ayan,
Hi Julien,

On 20/12/2022 10:44, Ayan Kumar Halder wrote:
+
+    /*
+     * Currently, we support uImage headers for uncompressed images only. +     * Thus, it is valid for the load address and start address to be the
+     * same. This is consistent with the uboot behavior (Refer
+     * "case IH_COMP_NONE" in image_decomp().
Please make it clear that you are referring to uboot function.

Could we avoid to mention the u-boot function? The reason I am asking is the code is in a different repo and the function name can easily change without us noticing (so the comment would rot).

Is the behavior documented somewhere in U-boot (or online)? If not, what's the guarantee that it will not change?

I could not find any documentation which states this. I found this from the following in uboot source code.

https://source.denx.de/u-boot/u-boot/-/blob/master/boot/image.c#L458

AFAIU when kernel_uimage_probe() get invoked, the image has already been decompressed. So, I added this as a limitation.

I e looked at the U-boot code and, AFAIU, the check is merely to avoid the memcpy() if the image start matches the start of the decompression area. So I don't understand why we need the limitation in Xen.

Now the lack of documentation (or at least I didn't find any) makes a bit more tricky to understand what the fields in the U-boot header are for. I have skimmed through the code and I disagree with the implementation you chose for Xen.

The comment for 'ih_ep' suggests this is the entry point address. That's may be different from the beginning of your blob. I think this is what ih_load is for.

So I think we want to load the blob at ih_load and then set pc to point to ih_ep. This will require a bit more work in Xen because the assumption so far is the entry point matches the start of the blob.

Please let me known if I missed anything.

I think you are correct. I will rework this to correctly handle load address and entry point.

- Ayan


Cheers,




 


Rackspace

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