On 14.03.2025 19:33, Andrew Cooper wrote: > It is only the hardware task switching mechanism which cares about a TSS being > at least 0x67 bytes long.
I/O bitmap accesses are where this particular limit comes into play. For 32-bit task switching a slightly shorter one would still do, I think? > Furthermore, since this check was added, the limit is now 0x6b if CET-SS is > active. Which isn't reflected at all in struct tss64: Aiui that's an addition to the 32-bit TSS only. > Nevertheless, task switches, being a relic > of the 32-bit days, aren't relevant to Xen. Yet as per above I/O bitmap handling is, even if all we put there is IOBMP_INVALID_OFFSET. > LTR is is perfectly possible to load a shorter TSS, and indeed we will be > doing so with FRED active. Well, yes; it is my understanding that shorter ones can already be loaded without FRED. > --- a/xen/arch/x86/cpu/common.c > +++ b/xen/arch/x86/cpu/common.c > @@ -900,8 +900,6 @@ void load_system_tables(void) > wrmsrl(MSR_INTERRUPT_SSP_TABLE, (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); All of the above said, the removal worries me primarily with the sizeof() still in use here. Jan
