Re: [PATCH v4 07/11] xen/riscv: add Linux kernel loading support

[Jan Beulich <jbeulich@xxxxxxxx>]

On 06.05.2026 16:53, Oleksii Kurochko wrote:
> 
> 
> On 5/4/26 4:05 PM, Jan Beulich wrote:
>>> --- a/xen/include/xen/fdt-kernel.h
>>> +++ b/xen/include/xen/fdt-kernel.h
>>> @@ -59,8 +59,15 @@ struct kernel_info {
>>>           struct {
>>>               paddr_t kernel_addr;
>>>               paddr_t len;
>>> -#if defined(CONFIG_ARM_64) || defined(CONFIG_RISCV_64)
>>> -            paddr_t text_offset; /* 64-bit Image only */
>>> +#if defined(CONFIG_ARM_64) || defined(CONFIG_RISCV)
>>> +            /*
>>> +             * ARM: 64-bit Image only.
>>> +             * RISC-V: both 32-bit and 64-bit Images.
>>> +             */
>>> +            paddr_t text_offset;
>>> +#endif
>>> +#if defined(CONFIG_RISCV)
>>> +            uint64_t image_size; /* Effective size of Image */
>> As this (apparently) is for both RV64 and RV32 - can the latter really have
>> wider than 32-bit image sizes? If not - use size_t or unsigned long here?
> 
> It seems like we want to have uint64_t as it is explicitly mentioned in 
> image header:
> 
> https://elixir.bootlin.com/linux/v7.0.1/source/arch/riscv/include/asm/image.h#L57
> 
> and also it is used .dword here:
> 
> https://elixir.bootlin.com/linux/v7.0.1/source/arch/riscv/kernel/head.S#L55

Well. The image header having a 64-bit wide field still raises the
question how the value being wider than 32 bits would work on RV32. IOW
for Xen internal purposes I expect unsigned long or size_t would be more
appropriate. When that value is taken from the image header and copied
into the internal struct, it would need checking for absence of
truncation.

Jan