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.coop...@citrix.com>
>> ---
>> CC: Jan Beulich <jbeul...@suse.com>
>> CC: Roger Pau Monné <roger....@citrix.com>
>> ---
>>  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).

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.

~Andrew

Reply via email to