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.
As to extable on other architectures, that's not something I can answer,
although it's not something I can see in Oleksii's or Shawn's series so far.
~Andrew
