On 1/27/25 12:15 PM, Jan Beulich wrote:
> On 08.01.2025 12:13, Oleksii Kurochko wrote:
>> Move the following parts to asm-generic with the following changes:
>> - struct kernel_info:
>>    - Create arch_kernel_info for arch specific kernel information.
>>      At the moment, it contains domain_type for Arm.
>>    - Rename vpl011 to vuart to have more generic name suitable for other archs.
>>    - s/phandle_gic/phandle_intc to have more generic name suitable for other
>>      archs.
>>    - Make text_offset of zimage structure available for RISCV_64.
>> - Wrap by `#ifdef KERNEL_INFO_SHM_MEM_INIT` definition of KERNEL_SHM_MEM_INIT
>>    and wrap by `#ifndef KERNEL_INFO_INIT` definition of KERNEL_INFO_INIT to have
>>    ability to override KERNEL_INFO_SHM_MEM_INIT for arch in case it doesn't
>>    want to use generic one.
>> - All other parts are left as is from Arm's asm/kernel.h
>>
>> Because of the changes in struct kernel_info the correspondent parts of Arm's
>> code are updated.
>>
>> As part of this patch the following clean up happens:
>> - Drop asm/setup.h from asm/kernel.h as nothing depends from it.
>>    Add inclusion of asm/setup.h for a code which uses device_tree_get_reg() to
>>    avoid compilation issues for CONFIG_STATIC_MEMORY and CONFIG_STATIC_SHM.
>>
>> Signed-off-by: Oleksii Kurochko<oleksii.kurochko@gmail.com>
> I question that what is being moved qualifies for asm-generic, an in particular
> for a header named kernel.h. Some of what you move may make sense to move to
> dom0less-build.h instead. But everything that doesn't fit there needs to find
> a different home, imo.

It doesn't clear what then should be in kernel.h, I did in this way to not have a problem with header inclusion
during the build of Arm.

Definitions DOM0LESSS_* could be moved to dom0less-build.h, all other doesn't really connected only to dom0less feature
and could be re-used for dom0 so it seems like it should leave in a separate header ( if kernel.h isn't good for it ).

Probably kernel.h shouldn't leave in asm-generic as nothing architecture specific is in it, but on the other hand, will it
be okay to have something in xen/include if it isn't supported by all architectures?

~ Oleksii