On 15.08.2025 10:28, Andrew Cooper wrote:
> On 15/08/2025 9:22 am, Jan Beulich wrote:
>> On 14.08.2025 20:09, Andrew Cooper wrote:
>>> On 14/08/2025 9:55 am, Jan Beulich wrote:
>>>> On 13.08.2025 13:25, Andrew Cooper wrote:
>>>>> On 12/08/2025 10:19 am, Jan Beulich wrote:
>>>>>> On 08.08.2025 22:23, Andrew Cooper wrote:
>>>>>>> Since commit a35816b5cae8 ("x86/traps: Introduce early_traps_init() and
>>>>>>> simplify setup"), load_system_tables() is called later on the BSP, so
>>>>>>> the
>>>>>>> SYS_STATE_early_boot check can be dropped from the safety BUG_ON().
>>>>>>>
>>>>>>> Move the BUILD_BUG_ON() into build_assertions(),
>>>>>> I'm not quite convinced of this move - having the related BUILD_BUG_ON()
>>>>>> and BUG_ON() next to each other would seem better to me.
>>>>> I don't see a specific reason for them to be together, and the comment
>>>>> explains what's going on.
>>>>>
>>>>> With FRED, we want a related BUILD_BUG_ON(), but there's no equivalent
>>>>> BUG_ON() because MSR_RSP_SL0 will #GP on being misaligned.
>>>> That BUILD_BUG_ON() could then sit next to the MSR write? Unless of course
>>>> that ends up sitting in an assembly source.
>>> It's the bottom hunk in patch 14, which you've looked at now.
>>>
>>> Personally, I think both BUILD_BUG_ON()'s should be together, because
>>> they are related.
>> I don't really agree, but I also won't insist on my preference to be
>> followed.
>> IOW please keep as is.
>
> Thankyou. Can I consider this to be A-by then? (This, and the rename
> to percpu_early_traps_init() are the only two remaining items in the
> entire first half of the series.)
Yes:
Acked-by: Jan Beulich <jbeul...@suse.com>
Jan
