On 01.12.2023 09:42, Nicola Vetrini wrote:
> On 2023-11-30 17:44, Jan Beulich wrote:
>> On 29.11.2023 16:24, Nicola Vetrini wrote:
>>> --- a/xen/arch/x86/desc.c
>>> +++ b/xen/arch/x86/desc.c
>>> @@ -91,7 +91,7 @@ seg_desc_t boot_compat_gdt[PAGE_SIZE /
>>> sizeof(seg_desc_t)] =
>>> * References boot_cpu_gdt_table for a short period, until the CPUs
>>> switch
>>> * onto their per-CPU GDTs.
>>> */
>>> -const struct desc_ptr boot_gdtr = {
>>> +const struct desc_ptr asmlinkage boot_gdtr = {
>>> .limit = LAST_RESERVED_GDT_BYTE,
>>> .base = (unsigned long)(boot_gdt - FIRST_RESERVED_GDT_ENTRY),
>>> };
>>
>> I'm not convinced asmlinkage is okay to use on data. Recall that in
>> principle
>> it may expand to an attribute specifying a non-default calling
>> convention.
>> Such attributes cannot be assumed to continue to be possible to apply
>> to
>> non-functions, even if such may happen to work with a particular
>> compiler
>> version.
>>
>
> It's already being used on variables, I believe.
>
> xen/arch/x86/mm.c:l1_pgentry_t asmlinkage __section(".bss.page_aligned")
> __aligned(PAGE_SIZE)
> xen/arch/x86/setup.c:unsigned long asmlinkage __read_mostly
> cr4_pv32_mask;
> xen/arch/x86/setup.c:char asmlinkage
> __section(".init.bss.stack_aligned") __aligned(STACK_SIZE)
> xen/arch/x86/setup.c:unsigned int asmlinkage __initdata multiboot_ptr;
Yeah, I was fearing that something was overlooked earlier on.
Jan
> If you have concern about this particular variable, then we can fall
> back on SAF or just put a declaration in the appropriate place.
>
