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.)

~Andrew


Reply via email to