Xen Security Advisory 525 v1 (CVE-2024-36350,CVE-2024-36357,CVE-2026-0004) - x86: Transient Scheduler Attacks (update)

xen/arch/x86/spec_ctrl.c +6 -6

index bc8538a56f0e..8f77fe4cdb92 100644
@@ -1450,11 +1450,11 @@ static void __init rfds_calculations(void)
 }
 
 /*
- * Transient Scheduler Attacks
+ * Transient Scheduler Attacks (Store Queue and L1)
  *
  * https://www.amd.com/content/dam/amd/en/documents/resources/bulletin/technical-guidance-for-mitigating-transient-scheduler-attacks.pdf
  */
-static void __init tsa_calculations(void)
+static void __init tsa_sq_l1_calculations(void)
 {
     unsigned int curr_rev, min_rev;

@@ -2247,9 +2247,9 @@ void __init init_speculation_mitigations(void)
      * - March 2023, for RFDS.  Enumerate RFDS_CLEAR to mean that VERW now
      *   scrubs non-architectural entries from certain register files.
      *
-     * - July 2025, for TSA.  Introduces VERW side effects to mitigate
-     *   TSA_{SQ/L1}.  Xen must synthesise the VERW_CLEAR feature based on
-     *   microcode version.
+     * - July 2025, for TSA-L1/SQ.  Introduces VERW side effects on Zen3/4.
+     *   Xen must synthesise the VERW_CLEAR feature based on microcode
+     *   version.
      *
      *   Note, these microcode updates were produced before the remediation of
      *   the microcode signature issues, and are included in the firwmare

@@ -2257,7 +2257,7 @@ void __init init_speculation_mitigations(void)
      */
     mds_calculations();
     rfds_calculations();
-    tsa_calculations();
+    tsa_sq_l1_calculations();
 
     /*
      * Parts which enumerate FB_CLEAR are those with now-updated microcode

From: Andrew Cooper <[email protected]>
Subject: x86/spec-ctrl: Extend TSA-SQ/L1 mitigations to Zen5 CPUs

AMD previously said that Zen5 was not affected by TSA. This statement has been retracted, along with the recommendation to synthesise the TSA_SQ/L1_NO bits on Zen5 CPUs.

Simply removing the synthesis of TSA_SQ/L1_NO creates a migration/resume problem; VMs which had booted between July 2025 and Nov 2026 on Zen5 would no longer be eligible to run on the same system as before.

Tolerate VMs which have seen TSA_SQ/L1_NO, despite knowing this to be an unsafe configuration. The VM is in no worse a position than before.

This is CVE-2024-36350 and CVE-2024-36357, part of XSA-525.

xen/arch/x86/cpu-policy.c +31 -0

index 48a3185eed8d..e797585528d0 100644
@@ -499,6 +499,23 @@ static void __init guest_common_max_feature_adjustments(uint32_t *fs)
          * has been around since the 286.
          */
         __set_bit(X86_FEATURE_VERW_CLEAR, fs);
+
+        /*
+         * Between July 2025 and Nov 2026, AMD had said that Zen5 was not
+         * vulnerable to TSA and to synthesise the TSA_SQ/L1_NO bits, but this
+         * statement has been retracted.
+         *
+         * VM's booted during that period on Zen5 CPUs will have seen the
+         * bits.  Tolerate such VMs; they'll be in no worse a position than
+         * prior to Nov 2026.
+         *
+         * Zen6 enumerates TSA_SQ/L1_NO, so there's no change from this logic.
+         */
+        if ( boot_cpu_data.family == 0x1a )
+        {
+            __set_bit(X86_FEATURE_TSA_SQ_NO, fs);
+            __set_bit(X86_FEATURE_TSA_L1_NO, fs);
+        }
         break;
     }

@@ -592,6 +609,20 @@ static void __init guest_common_default_feature_adjustments(uint32_t *fs)
          */
         if ( !cpu_has_verw_clear )
             __clear_bit(X86_FEATURE_VERW_CLEAR, fs);
+
+        /*
+         * Between July 2025 and Nov 2026, AMD had said that Zen5 was not
+         * vulnerable to TSA and to synthesise the TSA_SQ/L1_NO bits, but this
+         * statement has been retracted.
+         *
+         * The max policy has these set for migration compatibility, but a VM
+         * should not see them by default if the hardware is affected.
+         */
+        if ( !cpu_has_tsa_sq_no )
+            __clear_bit(X86_FEATURE_TSA_SQ_NO, fs);
+
+        if ( !cpu_has_tsa_l1_no )
+            __clear_bit(X86_FEATURE_TSA_L1_NO, fs);
         break;
     }

xen/arch/x86/spec_ctrl.c +15 -8

index 8f77fe4cdb92..3132752090da 100644
@@ -1467,18 +1467,22 @@ static void __init tsa_sq_l1_calculations(void)
         return;
 
     /*
-     * According to the whitepaper, some Fam1A CPUs (Models 0x00...0x4f,
-     * 0x60...0x7f) are not vulnerable but don't enumerate TSA_{SQ,L1}_NO.  If
-     * we see either enumerated, assume both are correct ...
+     * Zen6 and later are stated not to be vulnerable to the 3 known TSA
+     * variants, and enumerate all TSA_*_NO bits.
+     *
+     * Zen5 is vulnerable to all 3.  It gets VERW_CLEAR with new enough
+     * microcode, which is enumerated in CPUID.
+     *
+     * No synthesis should be performed.
      */
-    if ( cpu_has_tsa_sq_no || cpu_has_tsa_l1_no )
+    if ( boot_cpu_data.family > 0x19 )
         return;
 
     /*
-     * ... otherwise, synthesise them.  CPUs other than Fam19 (Zen3/4) are
-     * stated to be not vulnerable.
+     * Zen2 and older are stated not to be vulnerable, and need to synthesise
+     * TSA_SQ/L1_NO.
      */
-    if ( boot_cpu_data.family != 0x19 )
+    if ( boot_cpu_data.family < 0x19 )
     {
         setup_force_cpu_cap(X86_FEATURE_TSA_SQ_NO);
         setup_force_cpu_cap(X86_FEATURE_TSA_L1_NO);

@@ -1486,7 +1490,7 @@ static void __init tsa_sq_l1_calculations(void)
     }
 
     /*
-     * Fam19 CPUs get VERW_CLEAR with new enough microcode, but must
+     * Zen3 and Zen4 get VERW_CLEAR with new enough microcode, but must
      * synthesise the CPUID bit.
      */
     curr_rev = this_cpu(cpu_sig).rev;

@@ -2254,6 +2258,9 @@ void __init init_speculation_mitigations(void)
      *   Note, these microcode updates were produced before the remediation of
      *   the microcode signature issues, and are included in the firwmare
      *   updates fixing the entrysign vulnerability from ~December 2024.
+     *
+     * - September 2026, for TSA-L1/SQ/Fill.  Introduces VERW side effects on
+     *   Zen5, and enumerates VERW_CLEAR.
      */
     mds_calculations();
     rfds_calculations();

xen/include/public/arch-x86/cpufeatureset.h +2 -2

index 72c1bde7e6fe..d750b490098e 100644
@@ -402,8 +402,8 @@ XEN_CPUFEATURE(PB_OPT_CTRL,        16*32+32) /*   MSR_PB_OPT_CTRL.IBPB_ALT */
 XEN_CPUFEATURE(ITS_NO,             16*32+62) /*!A No Indirect Target Selection */
 
 /* AMD-defined CPU features, CPUID level 0x80000021.ecx, word 18 */
-XEN_CPUFEATURE(TSA_SQ_NO,          18*32+ 1) /*A  No Store Queue Transitive Scheduler Attacks */
-XEN_CPUFEATURE(TSA_L1_NO,          18*32+ 2) /*A  No L1D Transitive Scheduler Attacks */
+XEN_CPUFEATURE(TSA_SQ_NO,          18*32+ 1) /*!A No Store Queue Transitive Scheduler Attacks */
+XEN_CPUFEATURE(TSA_L1_NO,          18*32+ 2) /*!A No L1D Transitive Scheduler Attacks */
 
 #endif /* XEN_CPUFEATURE */

From: Andrew Cooper <[email protected]>
Subject: x86/spec-ctrl: Mitigate the new TSA-Fill variant

A new variant of TSA has been found, affecting only Zen5 CPUs.

Updated microcode has been issued. Unlike the original TSA, this microcode does enumerate VERW_CLEAR, so Xen does not need a table of microcode revisions. The handling of VERW_CLEAR for guests is the same as before.

A new CPUID bit, TSA_FILL_NO, indicates that the system is unaffected. It is expected to be set on all Zen6 and later systems. Zen4 and older are believed to be unaffected, and need to synthesise the bit for guests.

This is CVE-2026-0004, part of XSA-525.

xen/arch/x86/include/asm/cpufeature.h +1 -0

index 4933ad234f78..23a2614634d8 100644
@@ -245,6 +245,7 @@ static inline bool boot_cpu_has(unsigned int feat)
 /* CPUID level 0x80000021.ecx */
 #define cpu_has_tsa_sq_no       boot_cpu_has(X86_FEATURE_TSA_SQ_NO)
 #define cpu_has_tsa_l1_no       boot_cpu_has(X86_FEATURE_TSA_L1_NO)
+#define cpu_has_tsa_fill_no     boot_cpu_has(X86_FEATURE_TSA_FILL_NO)
 
 /* Synthesized. */
 #define cpu_has_arch_perfmon    boot_cpu_has(X86_FEATURE_ARCH_PERFMON)

xen/arch/x86/spec_ctrl.c +31 -2

index 3132752090da..fb015cac5e8f 100644
@@ -510,7 +510,7 @@ static void __init print_details(enum ind_thunk thunk)
      * Hardware read-only information, stating immunity to certain issues, or
      * suggestions of which mitigation to use.
      */
-    printk("  Hardware hints:%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s\n",
+    printk("  Hardware hints:%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s\n",
            (caps & ARCH_CAPS_RDCL_NO)                        ? " RDCL_NO"        : "",
            (caps & ARCH_CAPS_EIBRS)                          ? " EIBRS"          : "",
            (caps & ARCH_CAPS_RSBA)                           ? " RSBA"           : "",

@@ -537,7 +537,8 @@ static void __init print_details(enum ind_thunk thunk)
            (e21a & cpufeat_mask(X86_FEATURE_SRSO_NO))        ? " SRSO_NO"        : "",
            (e21a & cpufeat_mask(X86_FEATURE_SRSO_US_NO))     ? " SRSO_US_NO"     : "",
            (e21c & cpufeat_mask(X86_FEATURE_TSA_SQ_NO))      ? " TSA_SQ_NO"      : "",
-           (e21c & cpufeat_mask(X86_FEATURE_TSA_L1_NO))      ? " TSA_L1_NO"      : "");
+           (e21c & cpufeat_mask(X86_FEATURE_TSA_L1_NO))      ? " TSA_L1_NO"      : "",
+           (e21c & cpufeat_mask(X86_FEATURE_TSA_FILL_NO))    ? " TSA_FILL_NO"    : "");
 
     /* Hardware features which need driving to mitigate issues. */
     printk("  Hardware features:%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s\n",

@@ -1524,6 +1525,33 @@ static void __init tsa_sq_l1_calculations(void)
         setup_force_cpu_cap(X86_FEATURE_VERW_CLEAR);
 }
 
+/*
+ * Transient Scheduler Attacks (L1-Fill)
+ *
+ * https://www.amd.com/content/dam/amd/en/documents/resources/bulletin/technical-guidance-for-mitigating-transient-scheduler-attacks.pdf
+ */
+static void __init tsa_fill_calculations(void)
+{
+    /* TSA is only known to affect AMD processors at this time. */
+    if ( boot_cpu_data.vendor != X86_VENDOR_AMD )
+        return;
+
+    /* If we're virtualised, don't attempt to synthesise anything. */
+    if ( cpu_has_hypervisor )
+        return;
+
+    /*
+     * Zen6 and later CPUs are expected to enumerate TSA_FILL_NO.
+     *
+     * Zen5 CPUs are vulnerable and get VERW_CLEAR in microcode.
+     *
+     * Zen4 and earlier are not believed to be affected, but do not enumerate
+     * TSA_FILL_NO.  Synthesise it.
+     */
+    if ( boot_cpu_data.family < 0x1a )
+        setup_force_cpu_cap(X86_FEATURE_TSA_FILL_NO);
+}
+
 static bool __init cpu_has_gds(void)
 {
     /*

@@ -2265,6 +2293,7 @@ void __init init_speculation_mitigations(void)
     mds_calculations();
     rfds_calculations();
     tsa_sq_l1_calculations();
+    tsa_fill_calculations();
 
     /*
      * Parts which enumerate FB_CLEAR are those with now-updated microcode

xen/include/public/arch-x86/cpufeatureset.h +1 -0

index d750b490098e..fb65548381ab 100644
@@ -404,6 +404,7 @@ XEN_CPUFEATURE(ITS_NO,             16*32+62) /*!A No Indirect Target Selection *
 /* AMD-defined CPU features, CPUID level 0x80000021.ecx, word 18 */
 XEN_CPUFEATURE(TSA_SQ_NO,          18*32+ 1) /*!A No Store Queue Transitive Scheduler Attacks */
 XEN_CPUFEATURE(TSA_L1_NO,          18*32+ 2) /*!A No L1D Transitive Scheduler Attacks */
+XEN_CPUFEATURE(TSA_FILL_NO,        18*32+ 7) /*A  No L1D-Fill Transitive Scheduler Attacks */
 
 #endif /* XEN_CPUFEATURE */

From 6c3cf7c8a1a5a0e7717fcee463e2fd498e8b7467 Mon Sep 17 00:00:00 2001
From: Andrew Cooper <[email protected]>
Date: Fri, 7 Nov 2025 15:00:32 +0000
Subject: x86/spec-ctrl: Rename tsa_calculations()
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

... and adjust some comments in preparation to cope with the second TSA variant.

No functional change.

This is part of XSA-525.

xen/arch/x86/spec_ctrl.c +6 -6

index c1ad335d9ea9..e6a1551e0418 100644
@@ -1549,11 +1549,11 @@ static void __init rfds_calculations(void)
 }
 
 /*
- * Transient Scheduler Attacks
+ * Transient Scheduler Attacks (Store Queue and L1)
  *
  * https://www.amd.com/content/dam/amd/en/documents/resources/bulletin/technical-guidance-for-mitigating-transient-scheduler-attacks.pdf
  */
-static void __init tsa_calculations(void)
+static void __init tsa_sq_l1_calculations(void)
 {
     unsigned int curr_rev, min_rev;

@@ -2346,9 +2346,9 @@ void __init init_speculation_mitigations(void)
      * - March 2023, for RFDS.  Enumerate RFDS_CLEAR to mean that VERW now
      *   scrubs non-architectural entries from certain register files.
      *
-     * - July 2025, for TSA.  Introduces VERW side effects to mitigate
-     *   TSA_{SQ/L1}.  Xen must synthesise the VERW_CLEAR feature based on
-     *   microcode version.
+     * - July 2025, for TSA-L1/SQ.  Introduces VERW side effects on Zen3/4.
+     *   Xen must synthesise the VERW_CLEAR feature based on microcode
+     *   version.
      *
      *   Note, these microcode updates were produced before the remediation of
      *   the microcode signature issues, and are included in the firwmare

@@ -2356,7 +2356,7 @@ void __init init_speculation_mitigations(void)
      */
     mds_calculations();
     rfds_calculations();
-    tsa_calculations();
+    tsa_sq_l1_calculations();
 
     /*
      * Parts which enumerate FB_CLEAR are those with now-updated microcode

From 8c91436cb87928408110bfc77ba9e8018d0c0318 Mon Sep 17 00:00:00 2001
From: Andrew Cooper <[email protected]>
Date: Fri, 16 Oct 2026 18:18:56 +0100
Subject: x86/spec-ctrl: Extend TSA-SQ/L1 mitigations to Zen5 CPUs
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

AMD previously said that Zen5 was not affected by TSA. This statement has been retracted, along with the recommendation to synthesise the TSA_SQ/L1_NO bits on Zen5 CPUs.

Tolerate VMs which have seen TSA_SQ/L1_NO, despite knowing this to be an unsafe configuration. The VM is in no worse a position than before.

This is CVE-2024-36350 and CVE-2024-36357, part of XSA-525.

xen/arch/x86/cpu-policy.c +31 -0

index aae8e4983c03..2645e208fa81 100644
@@ -515,6 +515,23 @@ static void __init guest_common_max_feature_adjustments(uint32_t *fs)
          * has been around since the 286.
          */
         __set_bit(X86_FEATURE_VERW_CLEAR, fs);
+
+        /*
+         * Between July 2025 and Nov 2026, AMD had said that Zen5 was not
+         * vulnerable to TSA and to synthesise the TSA_SQ/L1_NO bits, but this
+         * statement has been retracted.
+         *
+         * VM's booted during that period on Zen5 CPUs will have seen the
+         * bits.  Tolerate such VMs; they'll be in no worse a position than
+         * prior to Nov 2026.
+         *
+         * Zen6 enumerates TSA_SQ/L1_NO, so there's no change from this logic.
+         */
+        if ( boot_cpu_data.x86 == 0x1a )
+        {
+            __set_bit(X86_FEATURE_TSA_SQ_NO, fs);
+            __set_bit(X86_FEATURE_TSA_L1_NO, fs);
+        }
         break;
     }

@@ -604,6 +621,20 @@ static void __init guest_common_default_feature_adjustments(uint32_t *fs)
          */
         if ( !cpu_has_verw_clear )
             __clear_bit(X86_FEATURE_VERW_CLEAR, fs);
+
+        /*
+         * Between July 2025 and Nov 2026, AMD had said that Zen5 was not
+         * vulnerable to TSA and to synthesise the TSA_SQ/L1_NO bits, but this
+         * statement has been retracted.
+         *
+         * The max policy has these set for migration compatibility, but a VM
+         * should not see them by default if the hardware is affected.
+         */
+        if ( !cpu_has_tsa_sq_no )
+            __clear_bit(X86_FEATURE_TSA_SQ_NO, fs);
+
+        if ( !cpu_has_tsa_l1_no )
+            __clear_bit(X86_FEATURE_TSA_L1_NO, fs);
         break;
     }

xen/arch/x86/spec_ctrl.c +15 -8

index e6a1551e0418..c2e6c49c442a 100644
@@ -1566,18 +1566,22 @@ static void __init tsa_sq_l1_calculations(void)
         return;
 
     /*
-     * According to the whitepaper, some Fam1A CPUs (Models 0x00...0x4f,
-     * 0x60...0x7f) are not vulnerable but don't enumerate TSA_{SQ,L1}_NO.  If
-     * we see either enumerated, assume both are correct ...
+     * Zen6 and later are stated not to be vulnerable to the 3 known TSA
+     * variants, and enumerate all TSA_*_NO bits.
+     *
+     * Zen5 is vulnerable to all 3.  It gets VERW_CLEAR with new enough
+     * microcode, which is enumerated in CPUID.
+     *
+     * No synthesis should be performed.
      */
-    if ( cpu_has_tsa_sq_no || cpu_has_tsa_l1_no )
+    if ( boot_cpu_data.x86 > 0x19 )
         return;
 
     /*
-     * ... otherwise, synthesise them.  CPUs other than Fam19 (Zen3/4) are
-     * stated to be not vulnerable.
+     * Zen2 and older are stated not to be vulnerable, and need to synthesise
+     * TSA_SQ/L1_NO.
      */
-    if ( boot_cpu_data.x86 != 0x19 )
+    if ( boot_cpu_data.x86 < 0x19 )
     {
         setup_force_cpu_cap(X86_FEATURE_TSA_SQ_NO);
         setup_force_cpu_cap(X86_FEATURE_TSA_L1_NO);

@@ -1585,7 +1589,7 @@ static void __init tsa_sq_l1_calculations(void)
     }
 
     /*
-     * Fam19 CPUs get VERW_CLEAR with new enough microcode, but must
+     * Zen3 and Zen4 get VERW_CLEAR with new enough microcode, but must
      * synthesise the CPUID bit.
      */
     curr_rev = this_cpu(cpu_sig).rev;

@@ -2353,6 +2357,9 @@ void __init init_speculation_mitigations(void)
      *   Note, these microcode updates were produced before the remediation of
      *   the microcode signature issues, and are included in the firwmare
      *   updates fixing the entrysign vulnerability from ~December 2024.
+     *
+     * - September 2026, for TSA-L1/SQ/Fill.  Introduces VERW side effects on
+     *   Zen5, and enumerates VERW_CLEAR.
      */
     mds_calculations();
     rfds_calculations();

xen/include/public/arch-x86/cpufeatureset.h +2 -2

index 7b80cd0c19c5..55b77506698d 100644
@@ -350,8 +350,8 @@ XEN_CPUFEATURE(PB_OPT_CTRL,        16*32+32) /*   MSR_PB_OPT_CTRL.IBPB_ALT */
 XEN_CPUFEATURE(ITS_NO,             16*32+62) /*!A No Indirect Target Selection */
 
 /* AMD-defined CPU features, CPUID level 0x80000021.ecx, word 18 */
-XEN_CPUFEATURE(TSA_SQ_NO,          18*32+ 1) /*A  No Store Queue Transitive Scheduler Attacks */
-XEN_CPUFEATURE(TSA_L1_NO,          18*32+ 2) /*A  No L1D Transitive Scheduler Attacks */
+XEN_CPUFEATURE(TSA_SQ_NO,          18*32+ 1) /*!A No Store Queue Transitive Scheduler Attacks */
+XEN_CPUFEATURE(TSA_L1_NO,          18*32+ 2) /*!A No L1D Transitive Scheduler Attacks */
 
 #endif /* XEN_CPUFEATURE */

From 6ade91ad6ecc3310fc4eaf84d58b163f5fa0c78a Mon Sep 17 00:00:00 2001
From: Andrew Cooper <[email protected]>
Date: Fri, 7 Nov 2025 15:00:32 +0000
Subject: x86/spec-ctrl: Mitigate the new TSA-Fill variant
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

A new variant of TSA has been found, affecting only Zen5 CPUs.

This is CVE-2026-0004, part of XSA-525.

tools/misc/xen-cpuid.c +2 -0

index 4fbfd63dfdc4..d965425566eb 100644
@@ -259,6 +259,8 @@ static const char *const str_e21c[32] =
 {
     /* 0 */                       [ 1] = "tsa-sq-no",
     [ 2] = "tsa-l1-no",
+
+                                  [ 7] = "tsa-fill-no",
 };
 
 static const struct {

xen/arch/x86/include/asm/cpufeature.h +1 -0

index bbae9305de4e..4e09f388744d 100644
@@ -222,6 +222,7 @@ static inline bool boot_cpu_has(unsigned int feat)
 /* CPUID level 0x80000021.ecx */
 #define cpu_has_tsa_sq_no       boot_cpu_has(X86_FEATURE_TSA_SQ_NO)
 #define cpu_has_tsa_l1_no       boot_cpu_has(X86_FEATURE_TSA_L1_NO)
+#define cpu_has_tsa_fill_no     boot_cpu_has(X86_FEATURE_TSA_FILL_NO)
 
 /* Synthesized. */
 #define cpu_has_arch_perfmon    boot_cpu_has(X86_FEATURE_ARCH_PERFMON)

xen/arch/x86/spec_ctrl.c +31 -2

index c2e6c49c442a..1ab9f29c06ae 100644
@@ -513,7 +513,7 @@ static void __init print_details(enum ind_thunk thunk)
      * Hardware read-only information, stating immunity to certain issues, or
      * suggestions of which mitigation to use.
      */
-    printk("  Hardware hints:%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s\n",
+    printk("  Hardware hints:%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s\n",
            (caps & ARCH_CAPS_RDCL_NO)                        ? " RDCL_NO"        : "",
            (caps & ARCH_CAPS_EIBRS)                          ? " EIBRS"          : "",
            (caps & ARCH_CAPS_RSBA)                           ? " RSBA"           : "",

@@ -540,7 +540,8 @@ static void __init print_details(enum ind_thunk thunk)
            (e21a & cpufeat_mask(X86_FEATURE_SRSO_NO))        ? " SRSO_NO"        : "",
            (e21a & cpufeat_mask(X86_FEATURE_SRSO_US_NO))     ? " SRSO_US_NO"     : "",
            (e21c & cpufeat_mask(X86_FEATURE_TSA_SQ_NO))      ? " TSA_SQ_NO"      : "",
-           (e21c & cpufeat_mask(X86_FEATURE_TSA_L1_NO))      ? " TSA_L1_NO"      : "");
+           (e21c & cpufeat_mask(X86_FEATURE_TSA_L1_NO))      ? " TSA_L1_NO"      : "",
+           (e21c & cpufeat_mask(X86_FEATURE_TSA_FILL_NO))    ? " TSA_FILL_NO"    : "");
 
     /* Hardware features which need driving to mitigate issues. */
     printk("  Hardware features:%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s\n",

@@ -1623,6 +1624,33 @@ static void __init tsa_sq_l1_calculations(void)
         setup_force_cpu_cap(X86_FEATURE_VERW_CLEAR);
 }
 
+/*
+ * Transient Scheduler Attacks (L1-Fill)
+ *
+ * https://www.amd.com/content/dam/amd/en/documents/resources/bulletin/technical-guidance-for-mitigating-transient-scheduler-attacks.pdf
+ */
+static void __init tsa_fill_calculations(void)
+{
+    /* TSA is only known to affect AMD processors at this time. */
+    if ( boot_cpu_data.x86_vendor != X86_VENDOR_AMD )
+        return;
+
+    /* If we're virtualised, don't attempt to synthesise anything. */
+    if ( cpu_has_hypervisor )
+        return;
+
+    /*
+     * Zen6 and later CPUs are expected to enumerate TSA_FILL_NO.
+     *
+     * Zen5 CPUs are vulnerable and get VERW_CLEAR in microcode.
+     *
+     * Zen4 and earlier are not believed to be affected, but do not enumerate
+     * TSA_FILL_NO.  Synthesise it.
+     */
+    if ( boot_cpu_data.x86 < 0x1a )
+        setup_force_cpu_cap(X86_FEATURE_TSA_FILL_NO);
+}
+
 static bool __init cpu_has_gds(void)
 {
     /*

@@ -2364,6 +2392,7 @@ void __init init_speculation_mitigations(void)
     mds_calculations();
     rfds_calculations();
     tsa_sq_l1_calculations();
+    tsa_fill_calculations();
 
     /*
      * Parts which enumerate FB_CLEAR are those with now-updated microcode

xen/include/public/arch-x86/cpufeatureset.h +1 -0

index 55b77506698d..5b758475b817 100644
@@ -352,6 +352,7 @@ XEN_CPUFEATURE(ITS_NO,             16*32+62) /*!A No Indirect Target Selection *
 /* AMD-defined CPU features, CPUID level 0x80000021.ecx, word 18 */
 XEN_CPUFEATURE(TSA_SQ_NO,          18*32+ 1) /*!A No Store Queue Transitive Scheduler Attacks */
 XEN_CPUFEATURE(TSA_L1_NO,          18*32+ 2) /*!A No L1D Transitive Scheduler Attacks */
+XEN_CPUFEATURE(TSA_FILL_NO,        18*32+ 7) /*A  No L1D-Fill Transitive Scheduler Attacks */
 
 #endif /* XEN_CPUFEATURE */

From: Andrew Cooper <[email protected]>
Subject: x86/spec-ctrl: Rename tsa_calculations()

... and adjust some comments in preparation to cope with the second TSA variant.

No functional change.

This is part of XSA-525.

xen/arch/x86/spec_ctrl.c +6 -6

index ef198c221139..f12971f37db7 100644
@@ -1549,11 +1549,11 @@ static void __init rfds_calculations(void)
 }
 
 /*
- * Transient Scheduler Attacks
+ * Transient Scheduler Attacks (Store Queue and L1)
  *
  * https://www.amd.com/content/dam/amd/en/documents/resources/bulletin/technical-guidance-for-mitigating-transient-scheduler-attacks.pdf
  */
-static void __init tsa_calculations(void)
+static void __init tsa_sq_l1_calculations(void)
 {
     unsigned int curr_rev, min_rev;

@@ -2346,9 +2346,9 @@ void __init init_speculation_mitigations(void)
      * - March 2023, for RFDS.  Enumerate RFDS_CLEAR to mean that VERW now
      *   scrubs non-architectural entries from certain register files.
      *
-     * - July 2025, for TSA.  Introduces VERW side effects to mitigate
-     *   TSA_{SQ/L1}.  Xen must synthesise the VERW_CLEAR feature based on
-     *   microcode version.
+     * - July 2025, for TSA-L1/SQ.  Introduces VERW side effects on Zen3/4.
+     *   Xen must synthesise the VERW_CLEAR feature based on microcode
+     *   version.
      *
      *   Note, these microcode updates were produced before the remediation of
      *   the microcode signature issues, and are included in the firwmare

@@ -2356,7 +2356,7 @@ void __init init_speculation_mitigations(void)
      */
     mds_calculations();
     rfds_calculations();
-    tsa_calculations();
+    tsa_sq_l1_calculations();
 
     /*
      * Parts which enumerate FB_CLEAR are those with now-updated microcode

From: Andrew Cooper <[email protected]>
Subject: x86/spec-ctrl: Extend TSA-SQ/L1 mitigations to Zen5 CPUs

AMD previously said that Zen5 was not affected by TSA. This statement has been retracted, along with the recommendation to synthesise the TSA_SQ/L1_NO bits on Zen5 CPUs.

Tolerate VMs which have seen TSA_SQ/L1_NO, despite knowing this to be an unsafe configuration. The VM is in no worse a position than before.

This is CVE-2024-36350 and CVE-2024-36357, part of XSA-525.

xen/arch/x86/cpu-policy.c +31 -0

index c594f05ea9b2..e405f43b88c1 100644
@@ -487,6 +487,23 @@ static void __init guest_common_max_feature_adjustments(uint32_t *fs)
          * has been around since the 286.
          */
         __set_bit(X86_FEATURE_VERW_CLEAR, fs);
+
+        /*
+         * Between July 2025 and Nov 2026, AMD had said that Zen5 was not
+         * vulnerable to TSA and to synthesise the TSA_SQ/L1_NO bits, but this
+         * statement has been retracted.
+         *
+         * VM's booted during that period on Zen5 CPUs will have seen the
+         * bits.  Tolerate such VMs; they'll be in no worse a position than
+         * prior to Nov 2026.
+         *
+         * Zen6 enumerates TSA_SQ/L1_NO, so there's no change from this logic.
+         */
+        if ( boot_cpu_data.x86 == 0x1a )
+        {
+            __set_bit(X86_FEATURE_TSA_SQ_NO, fs);
+            __set_bit(X86_FEATURE_TSA_L1_NO, fs);
+        }
         break;
     }

@@ -576,6 +593,20 @@ static void __init guest_common_default_feature_adjustments(uint32_t *fs)
          */
         if ( !cpu_has_verw_clear )
             __clear_bit(X86_FEATURE_VERW_CLEAR, fs);
+
+        /*
+         * Between July 2025 and Nov 2026, AMD had said that Zen5 was not
+         * vulnerable to TSA and to synthesise the TSA_SQ/L1_NO bits, but this
+         * statement has been retracted.
+         *
+         * The max policy has these set for migration compatibility, but a VM
+         * should not see them by default if the hardware is affected.
+         */
+        if ( !cpu_has_tsa_sq_no )
+            __clear_bit(X86_FEATURE_TSA_SQ_NO, fs);
+
+        if ( !cpu_has_tsa_l1_no )
+            __clear_bit(X86_FEATURE_TSA_L1_NO, fs);
         break;
     }

xen/arch/x86/spec_ctrl.c +15 -8

index f12971f37db7..3fb9a52fa5a6 100644
@@ -1566,18 +1566,22 @@ static void __init tsa_sq_l1_calculations(void)
         return;
 
     /*
-     * According to the whitepaper, some Fam1A CPUs (Models 0x00...0x4f,
-     * 0x60...0x7f) are not vulnerable but don't enumerate TSA_{SQ,L1}_NO.  If
-     * we see either enumerated, assume both are correct ...
+     * Zen6 and later are stated not to be vulnerable to the 3 known TSA
+     * variants, and enumerate all TSA_*_NO bits.
+     *
+     * Zen5 is vulnerable to all 3.  It gets VERW_CLEAR with new enough
+     * microcode, which is enumerated in CPUID.
+     *
+     * No synthesis should be performed.
      */
-    if ( cpu_has_tsa_sq_no || cpu_has_tsa_l1_no )
+    if ( boot_cpu_data.x86 > 0x19 )
         return;
 
     /*
-     * ... otherwise, synthesise them.  CPUs other than Fam19 (Zen3/4) are
-     * stated to be not vulnerable.
+     * Zen2 and older are stated not to be vulnerable, and need to synthesise
+     * TSA_SQ/L1_NO.
      */
-    if ( boot_cpu_data.x86 != 0x19 )
+    if ( boot_cpu_data.x86 < 0x19 )
     {
         setup_force_cpu_cap(X86_FEATURE_TSA_SQ_NO);
         setup_force_cpu_cap(X86_FEATURE_TSA_L1_NO);

@@ -1585,7 +1589,7 @@ static void __init tsa_sq_l1_calculations(void)
     }
 
     /*
-     * Fam19 CPUs get VERW_CLEAR with new enough microcode, but must
+     * Zen3 and Zen4 get VERW_CLEAR with new enough microcode, but must
      * synthesise the CPUID bit.
      */
     curr_rev = this_cpu(cpu_sig).rev;

@@ -2353,6 +2357,9 @@ void __init init_speculation_mitigations(void)
      *   Note, these microcode updates were produced before the remediation of
      *   the microcode signature issues, and are included in the firwmare
      *   updates fixing the entrysign vulnerability from ~December 2024.
+     *
+     * - September 2026, for TSA-L1/SQ/Fill.  Introduces VERW side effects on
+     *   Zen5, and enumerates VERW_CLEAR.
      */
     mds_calculations();
     rfds_calculations();

xen/include/public/arch-x86/cpufeatureset.h +2 -2

index d61dccc464ea..a593ec2f73f3 100644
@@ -372,8 +372,8 @@ XEN_CPUFEATURE(PB_OPT_CTRL,        16*32+32) /*   MSR_PB_OPT_CTRL.IBPB_ALT */
 XEN_CPUFEATURE(ITS_NO,             16*32+62) /*!A No Indirect Target Selection */
 
 /* AMD-defined CPU features, CPUID level 0x80000021.ecx, word 18 */
-XEN_CPUFEATURE(TSA_SQ_NO,          18*32+ 1) /*A  No Store Queue Transitive Scheduler Attacks */
-XEN_CPUFEATURE(TSA_L1_NO,          18*32+ 2) /*A  No L1D Transitive Scheduler Attacks */
+XEN_CPUFEATURE(TSA_SQ_NO,          18*32+ 1) /*!A No Store Queue Transitive Scheduler Attacks */
+XEN_CPUFEATURE(TSA_L1_NO,          18*32+ 2) /*!A No L1D Transitive Scheduler Attacks */
 
 #endif /* XEN_CPUFEATURE */

From: Andrew Cooper <[email protected]>
Subject: x86/spec-ctrl: Mitigate the new TSA-Fill variant

A new variant of TSA has been found, affecting only Zen5 CPUs.

This is CVE-2026-0004, part of XSA-525.

xen/arch/x86/include/asm/cpufeature.h +1 -0

index ad50e5356a49..f70d4c3730c0 100644
@@ -227,6 +227,7 @@ static inline bool boot_cpu_has(unsigned int feat)
 /* CPUID level 0x80000021.ecx */
 #define cpu_has_tsa_sq_no       boot_cpu_has(X86_FEATURE_TSA_SQ_NO)
 #define cpu_has_tsa_l1_no       boot_cpu_has(X86_FEATURE_TSA_L1_NO)
+#define cpu_has_tsa_fill_no     boot_cpu_has(X86_FEATURE_TSA_FILL_NO)
 
 /* Synthesized. */
 #define cpu_has_arch_perfmon    boot_cpu_has(X86_FEATURE_ARCH_PERFMON)

xen/arch/x86/spec_ctrl.c +31 -2

index 3fb9a52fa5a6..a13e1e18e66a 100644
@@ -513,7 +513,7 @@ static void __init print_details(enum ind_thunk thunk)
      * Hardware read-only information, stating immunity to certain issues, or
      * suggestions of which mitigation to use.
      */
-    printk("  Hardware hints:%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s\n",
+    printk("  Hardware hints:%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s\n",
            (caps & ARCH_CAPS_RDCL_NO)                        ? " RDCL_NO"        : "",
            (caps & ARCH_CAPS_EIBRS)                          ? " EIBRS"          : "",
            (caps & ARCH_CAPS_RSBA)                           ? " RSBA"           : "",

@@ -540,7 +540,8 @@ static void __init print_details(enum ind_thunk thunk)
            (e21a & cpufeat_mask(X86_FEATURE_SRSO_NO))        ? " SRSO_NO"        : "",
            (e21a & cpufeat_mask(X86_FEATURE_SRSO_US_NO))     ? " SRSO_US_NO"     : "",
            (e21c & cpufeat_mask(X86_FEATURE_TSA_SQ_NO))      ? " TSA_SQ_NO"      : "",
-           (e21c & cpufeat_mask(X86_FEATURE_TSA_L1_NO))      ? " TSA_L1_NO"      : "");
+           (e21c & cpufeat_mask(X86_FEATURE_TSA_L1_NO))      ? " TSA_L1_NO"      : "",
+           (e21c & cpufeat_mask(X86_FEATURE_TSA_FILL_NO))    ? " TSA_FILL_NO"    : "");
 
     /* Hardware features which need driving to mitigate issues. */
     printk("  Hardware features:%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s\n",

@@ -1623,6 +1624,33 @@ static void __init tsa_sq_l1_calculations(void)
         setup_force_cpu_cap(X86_FEATURE_VERW_CLEAR);
 }
 
+/*
+ * Transient Scheduler Attacks (L1-Fill)
+ *
+ * https://www.amd.com/content/dam/amd/en/documents/resources/bulletin/technical-guidance-for-mitigating-transient-scheduler-attacks.pdf
+ */
+static void __init tsa_fill_calculations(void)
+{
+    /* TSA is only known to affect AMD processors at this time. */
+    if ( boot_cpu_data.x86_vendor != X86_VENDOR_AMD )
+        return;
+
+    /* If we're virtualised, don't attempt to synthesise anything. */
+    if ( cpu_has_hypervisor )
+        return;
+
+    /*
+     * Zen6 and later CPUs are expected to enumerate TSA_FILL_NO.
+     *
+     * Zen5 CPUs are vulnerable and get VERW_CLEAR in microcode.
+     *
+     * Zen4 and earlier are not believed to be affected, but do not enumerate
+     * TSA_FILL_NO.  Synthesise it.
+     */
+    if ( boot_cpu_data.x86 < 0x1a )
+        setup_force_cpu_cap(X86_FEATURE_TSA_FILL_NO);
+}
+
 static bool __init cpu_has_gds(void)
 {
     /*

@@ -2364,6 +2392,7 @@ void __init init_speculation_mitigations(void)
     mds_calculations();
     rfds_calculations();
     tsa_sq_l1_calculations();
+    tsa_fill_calculations();
 
     /*
      * Parts which enumerate FB_CLEAR are those with now-updated microcode

xen/include/public/arch-x86/cpufeatureset.h +1 -0

index a593ec2f73f3..a05002eeeb1d 100644
@@ -374,6 +374,7 @@ XEN_CPUFEATURE(ITS_NO,             16*32+62) /*!A No Indirect Target Selection *
 /* AMD-defined CPU features, CPUID level 0x80000021.ecx, word 18 */
 XEN_CPUFEATURE(TSA_SQ_NO,          18*32+ 1) /*!A No Store Queue Transitive Scheduler Attacks */
 XEN_CPUFEATURE(TSA_L1_NO,          18*32+ 2) /*!A No L1D Transitive Scheduler Attacks */
+XEN_CPUFEATURE(TSA_FILL_NO,        18*32+ 7) /*A  No L1D-Fill Transitive Scheduler Attacks */
 
 #endif /* XEN_CPUFEATURE */

From: Andrew Cooper <[email protected]>
Subject: x86/spec-ctrl: Rename tsa_calculations()

... and adjust some comments in preparation to cope with the second TSA variant.

No functional change.

This is part of XSA-525.

xen/arch/x86/spec_ctrl.c +6 -6

index bcdae1ed2377..f09512dfd6af 100644
@@ -1528,11 +1528,11 @@ static void __init rfds_calculations(void)
 }
 
 /*
- * Transient Scheduler Attacks
+ * Transient Scheduler Attacks (Store Queue and L1)
  *
  * https://www.amd.com/content/dam/amd/en/documents/resources/bulletin/technical-guidance-for-mitigating-transient-scheduler-attacks.pdf
  */
-static void __init tsa_calculations(void)
+static void __init tsa_sq_l1_calculations(void)
 {
     unsigned int curr_rev, min_rev;

@@ -2329,9 +2329,9 @@ void __init init_speculation_mitigations(void)
      * - March 2023, for RFDS.  Enumerate RFDS_CLEAR to mean that VERW now
      *   scrubs non-architectural entries from certain register files.
      *
-     * - July 2025, for TSA.  Introduces VERW side effects to mitigate
-     *   TSA_{SQ/L1}.  Xen must synthesise the VERW_CLEAR feature based on
-     *   microcode version.
+     * - July 2025, for TSA-L1/SQ.  Introduces VERW side effects on Zen3/4.
+     *   Xen must synthesise the VERW_CLEAR feature based on microcode
+     *   version.
      *
      *   Note, these microcode updates were produced before the remediation of
      *   the microcode signature issues, and are included in the firwmare

@@ -2339,7 +2339,7 @@ void __init init_speculation_mitigations(void)
      */
     mds_calculations();
     rfds_calculations();
-    tsa_calculations();
+    tsa_sq_l1_calculations();
 
     /*
      * Parts which enumerate FB_CLEAR are those with now-updated microcode

From: Andrew Cooper <[email protected]>
Subject: x86/spec-ctrl: Extend TSA-SQ/L1 mitigations to Zen5 CPUs

AMD previously said that Zen5 was not affected by TSA. This statement has been retracted, along with the recommendation to synthesise the TSA_SQ/L1_NO bits on Zen5 CPUs.

Tolerate VMs which have seen TSA_SQ/L1_NO, despite knowing this to be an unsafe configuration. The VM is in no worse a position than before.

This is CVE-2024-36350 and CVE-2024-36357, part of XSA-525.

xen/arch/x86/cpu-policy.c +31 -0

index 3e628e008e92..612fb1c389af 100644
@@ -490,6 +490,23 @@ static void __init guest_common_max_feature_adjustments(uint32_t *fs)
          * has been around since the 286.
          */
         __set_bit(X86_FEATURE_VERW_CLEAR, fs);
+
+        /*
+         * Between July 2025 and Nov 2026, AMD had said that Zen5 was not
+         * vulnerable to TSA and to synthesise the TSA_SQ/L1_NO bits, but this
+         * statement has been retracted.
+         *
+         * VM's booted during that period on Zen5 CPUs will have seen the
+         * bits.  Tolerate such VMs; they'll be in no worse a position than
+         * prior to Nov 2026.
+         *
+         * Zen6 enumerates TSA_SQ/L1_NO, so there's no change from this logic.
+         */
+        if ( boot_cpu_data.x86 == 0x1a )
+        {
+            __set_bit(X86_FEATURE_TSA_SQ_NO, fs);
+            __set_bit(X86_FEATURE_TSA_L1_NO, fs);
+        }
         break;
     }

@@ -579,6 +596,20 @@ static void __init guest_common_default_feature_adjustments(uint32_t *fs)
          */
         if ( !cpu_has_verw_clear )
             __clear_bit(X86_FEATURE_VERW_CLEAR, fs);
+
+        /*
+         * Between July 2025 and Nov 2026, AMD had said that Zen5 was not
+         * vulnerable to TSA and to synthesise the TSA_SQ/L1_NO bits, but this
+         * statement has been retracted.
+         *
+         * The max policy has these set for migration compatibility, but a VM
+         * should not see them by default if the hardware is affected.
+         */
+        if ( !cpu_has_tsa_sq_no )
+            __clear_bit(X86_FEATURE_TSA_SQ_NO, fs);
+
+        if ( !cpu_has_tsa_l1_no )
+            __clear_bit(X86_FEATURE_TSA_L1_NO, fs);
         break;
     }

xen/arch/x86/spec_ctrl.c +15 -8

index f09512dfd6af..0635286700b6 100644
@@ -1545,18 +1545,22 @@ static void __init tsa_sq_l1_calculations(void)
         return;
 
     /*
-     * According to the whitepaper, some Fam1A CPUs (Models 0x00...0x4f,
-     * 0x60...0x7f) are not vulnerable but don't enumerate TSA_{SQ,L1}_NO.  If
-     * we see either enumerated, assume both are correct ...
+     * Zen6 and later are stated not to be vulnerable to the 3 known TSA
+     * variants, and enumerate all TSA_*_NO bits.
+     *
+     * Zen5 is vulnerable to all 3.  It gets VERW_CLEAR with new enough
+     * microcode, which is enumerated in CPUID.
+     *
+     * No synthesis should be performed.
      */
-    if ( cpu_has_tsa_sq_no || cpu_has_tsa_l1_no )
+    if ( boot_cpu_data.x86 > 0x19 )
         return;
 
     /*
-     * ... otherwise, synthesise them.  CPUs other than Fam19 (Zen3/4) are
-     * stated to be not vulnerable.
+     * Zen2 and older are stated not to be vulnerable, and need to synthesise
+     * TSA_SQ/L1_NO.
      */
-    if ( boot_cpu_data.x86 != 0x19 )
+    if ( boot_cpu_data.x86 < 0x19 )
     {
         setup_force_cpu_cap(X86_FEATURE_TSA_SQ_NO);
         setup_force_cpu_cap(X86_FEATURE_TSA_L1_NO);

@@ -1564,7 +1568,7 @@ static void __init tsa_sq_l1_calculations(void)
     }
 
     /*
-     * Fam19 CPUs get VERW_CLEAR with new enough microcode, but must
+     * Zen3 and Zen4 get VERW_CLEAR with new enough microcode, but must
      * synthesise the CPUID bit.
      */
     curr_rev = this_cpu(cpu_sig).rev;

@@ -2336,6 +2340,9 @@ void __init init_speculation_mitigations(void)
      *   Note, these microcode updates were produced before the remediation of
      *   the microcode signature issues, and are included in the firwmare
      *   updates fixing the entrysign vulnerability from ~December 2024.
+     *
+     * - September 2026, for TSA-L1/SQ/Fill.  Introduces VERW side effects on
+     *   Zen5, and enumerates VERW_CLEAR.
      */
     mds_calculations();
     rfds_calculations();

xen/include/public/arch-x86/cpufeatureset.h +2 -2

index 618674123be3..85f417188e98 100644
@@ -386,8 +386,8 @@ XEN_CPUFEATURE(PB_OPT_CTRL,        16*32+32) /*   MSR_PB_OPT_CTRL.IBPB_ALT */
 XEN_CPUFEATURE(ITS_NO,             16*32+62) /*!A No Indirect Target Selection */
 
 /* AMD-defined CPU features, CPUID level 0x80000021.ecx, word 18 */
-XEN_CPUFEATURE(TSA_SQ_NO,          18*32+ 1) /*A  No Store Queue Transitive Scheduler Attacks */
-XEN_CPUFEATURE(TSA_L1_NO,          18*32+ 2) /*A  No L1D Transitive Scheduler Attacks */
+XEN_CPUFEATURE(TSA_SQ_NO,          18*32+ 1) /*!A No Store Queue Transitive Scheduler Attacks */
+XEN_CPUFEATURE(TSA_L1_NO,          18*32+ 2) /*!A No L1D Transitive Scheduler Attacks */
 
 #endif /* XEN_CPUFEATURE */

From: Andrew Cooper <[email protected]>
Subject: x86/spec-ctrl: Mitigate the new TSA-Fill variant

A new variant of TSA has been found, affecting only Zen5 CPUs.

This is CVE-2026-0004, part of XSA-525.