xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Julien Grall <julien.grall@arm.com>
To: Dirk Behme <dirk.behme@de.bosch.com>,
	xen-devel@lists.xenproject.org,
	Stefano Stabellini <sstabellini@kernel.org>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Andre Przywara <Andre.Przywara@arm.com>
Subject: Re: [PATCH v4] xen: arm: Update arm64 image header
Date: Wed, 29 Jun 2016 12:47:42 +0100	[thread overview]
Message-ID: <436b36f6-ddcf-f452-5713-16d56e6d32ae@arm.com> (raw)
In-Reply-To: <6202a4b9-a65e-9b80-11c4-210ef0f230b3@de.bosch.com>



On 29/06/2016 12:31, Dirk Behme wrote:
> On 29.06.2016 13:08, Dirk Behme wrote:
>> Hi Julien,
>>
>> On 29.06.2016 12:32, Julien Grall wrote:
>>> Hi Dirk,
>>>
>>> On 27/06/2016 08:53, Dirk Behme wrote:
>>>> +    if ( (end - start) > size ) {
>>>> +        printk(XENLOG_ERR "Error: Kernel Image size: %lu bytes >
>>>> bootmodule size: %lu bytes\n",
>>>> +               zimage.image_size, (uint64_t)size);
>>>> +        printk(XENLOG_ERR "The field 'size' does not match the size
>>>> of blob!\n");
>>>>          return -EINVAL;
>>>> +    }
>>>
>>> This patch is breaking boot on any ARM64 platform (UEFI and
>>> bootwrapper).
>>
>>
>> Well, I wonder if it breaks because the kernel is too large? As intended?
>>
>> You are the expert on this, so I just can give my (limited?)
>> understanding:
>>
>> In my use case, starting with the Xen development and not really knowing
>> the details, taking a random example from the net I had configured 10MB
>> in the device tree:
>>
>> module@0x48200000 {
>>        compatible = "xen,linux-zimage", "xen,multiboot-module";
>>        reg = <0x48200000 0x00A00000>; /* Max Image size 10MB */
>> };
>>
>> This failed silently. No error message.
>>
>> Without knowing any details, my first workaround was to make the kernel
>> smaller. Having a kernel Image smaller than 10MB worked, then.
>>
>> While debugging it, I found that these 0x00A00000 are used for 'size'.
>> And increasing it to 0x00F00000 (15MB) does work for me, now.
>>
>> I don't know anything aobut UEFI and bootwrapper,
>
>
> Just a question: In case of UEFI and bootwrapper, does Xen know the
> exact real file size of the Image file?

Yes.

>
> Then that's the difference to the device tree case, where we don't know
> the Image file size and use a max size estimation from the device tree.

What do you mean by "device tree case"? UEFI and bootwrapper are device 
tree based. The latter will create the node in the device tree with the 
correct size, whilst the former will directly fill Xen internal 
structure (see arch/arm/efi).

>
> Then we should limit the image_size error message to the device tree
> case only. Ignoring the BSS overhead issue, as the size given by the
> device tree is an estimation, anyhow.

Which firmware are you using? If you use u-boot, there are runes to 
create the proper device-tree node on the wiki [1].

To be honest, the device-tree bindings does not mention any estimation 
(see [2]). I have noticed that some pages on the wiki use hardcoded DT 
(see [3]). So the documentation needs to be fixed.

Regards,

[1] 
http://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions#Boot_Modules
[2] 
http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/arm/device-tree/booting.txt;h=8da1e0b8fcf9c98888ed63cd45bd11f1a880288b;hb=HEAD
[3] 
http://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/Lager

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

  reply	other threads:[~2016-06-29 11:47 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-27  7:53 [PATCH v4] xen: arm: Update arm64 image header Dirk Behme
2016-06-28 10:18 ` Julien Grall
2016-06-28 18:33   ` Andrew Cooper
2016-06-29 10:32 ` Julien Grall
2016-06-29 11:08   ` Dirk Behme
2016-06-29 11:22     ` Dirk Behme
2016-06-29 11:31     ` Dirk Behme
2016-06-29 11:47       ` Julien Grall [this message]
2016-06-29 11:55         ` Dirk Behme
2016-06-29 12:08           ` Julien Grall
2016-06-29 11:33     ` Julien Grall
2016-06-29 11:38       ` Dirk Behme

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=436b36f6-ddcf-f452-5713-16d56e6d32ae@arm.com \
    --to=julien.grall@arm.com \
    --cc=Andre.Przywara@arm.com \
    --cc=Andrew.Cooper3@citrix.com \
    --cc=dirk.behme@de.bosch.com \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).