Re: [PATCH v2 05/11] xen/riscv: add kernel loading support

[Jan Beulich <jbeulich@xxxxxxxx>]

On 31.03.2026 17:36, Oleksii Kurochko wrote:
> On 3/31/26 5:14 PM, Jan Beulich wrote:
>> On 31.03.2026 16:30, Oleksii Kurochko wrote:
>>> On 3/30/26 4:47 PM, Jan Beulich wrote:
>>>> On 23.03.2026 17:29, Oleksii Kurochko wrote:
>>>>> +    /* Currently there is no length in the header, so just use the size 
>>>>> */
>>>>> +    start = 0;
>>>>> +    end = size;
>>>>
>>>> What's image_size then?
>>>
>>> The comment is incorrect, the length is present in the header, but it is
>>> effective length which isn't equal to the size of binary and is actually
>>> bigger then binary size.
>>>
>>> So here we want to use 'size' as it is a size of binary itself.
>>
>> What is "effective length"? That sounds a little like e.g. .bss extending
>> past the (file) image, yet such would nee taking into account for allocation
>> (but not for reading in / copying over).
> 
> Yes, correct.
> Effective length is how much memory the image needs when loaded and 
> running. So it includes .bss (and similar sections) that are not stored 
> in the file but need zeroed memory at runtime. So:
>   size = actual bytes in the binary file
>   image_size (from header) = total memory the kernel occupies at runtime 
>   (larger, includes BSS)
> 
> So I think that:
>      start = 0;
>      end = size;
> that could be dropped at all. then:
>    info->image.len = size;
> 
> Then in kernel_image_load, pass load_addr + info->image.effective_size 
> to place_modules instead of load_addr + len.

Not really - for loading you need to know how much to load/copy. For
allocation/placement you need to know the overall size.

Jan