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.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).
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 <jbeul...@suse.com>
> 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
