Re: [PATCH 03/22] x86/traps: Drop incorrect BUILD_BUG_ON() and comment in load_system_tables()

[Jan Beulich <jbeulich@xxxxxxxx>]

On 13.08.2025 11:40, Andrew Cooper wrote:
> On 12/08/2025 9:11 am, Jan Beulich wrote:
>> On 08.08.2025 22:22, Andrew Cooper wrote:
>>> This was added erroneously by me.
>>>
>>> Hardware task switching does demand a TSS of at least 0x67 bytes, but that's
>>> not relevant in 64bit, and not relevant for Xen since commit
>>> 5d1181a5ea5e ("xen: Remove x86_32 build target.") in 2012.
>>>
>>> We already load a 0-length TSS in early_traps_init() demonstrating that it's
>>> possible.
>>>
>>> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>>> ---
>>> CC: Jan Beulich <JBeulich@xxxxxxxx>
>>> CC: Roger Pau Monné <roger.pau@xxxxxxxxxx>
>>> ---
>>>  xen/arch/x86/cpu/common.c | 2 --
>>>  1 file changed, 2 deletions(-)
>>>
>>> diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
>>> index f6ec5c9df522..cdc41248d4e9 100644
>>> --- a/xen/arch/x86/cpu/common.c
>>> +++ b/xen/arch/x86/cpu/common.c
>>> @@ -936,8 +936,6 @@ void load_system_tables(void)
>>>             wrmsrl(MSR_ISST, (unsigned long)ist_ssp);
>>>     }
>>>  
>>> -   BUILD_BUG_ON(sizeof(*tss) <= 0x67); /* Mandated by the architecture. */
>>> -
>>>     _set_tssldt_desc(gdt + TSS_ENTRY, (unsigned long)tss,
>>>                      sizeof(*tss) - 1, SYS_DESC_tss_avail);
>>>     if ( IS_ENABLED(CONFIG_PV32) )
>> Well, the comment is wrong. Whether the BUILD_BUG_ON() itself is also wrong
>> depends on our intentions with the structure. Don't we need it to be that
>> size for everything (incl I/O bitmap) to work correctly elsewhere?
> 
> We don't use the IO bitmap.  We've talked about it a few times, but
> never got it sorted.
> 
> Xen's TSS could be as short as 0x37 (covering IST3) and still work
> correctly and safely (as there's no task switching).

Then shouldn't we have a BUILD_BUG_ON(sizeof(*tss) <= 0x37) here? Hmm,
arguably that get pretty close to useless, though, so
Acked-by: Jan Beulich <jbeulich@xxxxxxxx>

> A failure to read tss->iopb is the same as a failure to read the bitmap
> itself.  In fact, it's probably marginally faster for users of
> IOBMP_INVALID_OFFSET as it fails one step earlier.

(Provided there are no errata lurking anywhere.)

Jan