On 18.03.2024 14:49, Andrew Cooper wrote:
> On 18/03/2024 1:29 pm, Jan Beulich wrote:
>> On 18.03.2024 12:04, Andrew Cooper wrote:
>>> --- a/xen/common/virtual_region.c
>>> +++ b/xen/common/virtual_region.c
>>> @@ -39,6 +39,11 @@ static struct virtual_region core = {
>>> { __start_bug_frames_2, __stop_bug_frames_2 },
>>> { __start_bug_frames_3, __stop_bug_frames_3 },
>>> },
>>> +
>>> +#ifdef CONFIG_X86
>>> + .ex = __start___ex_table,
>>> + .ex_end = __stop___ex_table,
>>> +#endif
>>> };
>>>
>>> /* Becomes irrelevant when __init sections are cleared. */
>>> @@ -57,6 +62,11 @@ static struct virtual_region core_init __initdata = {
>>> { __start_bug_frames_2, __stop_bug_frames_2 },
>>> { __start_bug_frames_3, __stop_bug_frames_3 },
>>> },
>>> +
>>> +#ifdef CONFIG_X86
>>> + .ex = __start___ex_table,
>>> + .ex_end = __stop___ex_table,
>>> +#endif
>>> };
>> My main reservation here is this x86-specific code in a common file.
>> Are we certain both RISC-V and PPC will get away without needing to
>> touch this? If so, I might consider ack-ing. But really I'd prefer if
>> this could be minimally abstracted, via e.g. CONFIG_HAS_EXTABLE
>> (selected by x86 only for now).
>
> This isn't the first bit of CONFIG_X86 in this file. However, I'd not
> spotted that we have CONFIG_HAS_EX_TABLE already. I can swap.
At which point:
Reviewed-by: Jan Beulich <jbeul...@suse.com>
Jan
