[xen staging] x86/amd: Use setup_force_cpu_cap() for BTC_NO

[patchbot@xxxxxxx]

commit dcfcc4acabf9b84b3b9ba32f2d19241c4897c0ec
Author:     Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
AuthorDate: Tue Nov 25 18:18:33 2025 +0000
Commit:     Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
CommitDate: Mon Dec 1 16:20:41 2025 +0000

    x86/amd: Use setup_force_cpu_cap() for BTC_NO
    
    A XenServer feature in the process of being upstreamed is to be able to
    re-calculate the guest CPU Policies at runtime, e.g. after a microcode load
    and/or livepatch to expose new functionality.  Right now, upstream Xen only
    rescans the Raw CPU Policy on microcode load.
    
    One complication with recalculating the guest policies is that BTC_NO is
    handled differently to other $FOO_NO bits, by using __set_bit() rather than
    setup_force_cpu_cap().
    
    For consistency, switch it to using setup_force_cpu_cap().  This doesn't
    matter for upstream Xen right now, but it will ease upstreaming the feature.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Acked-by: Jan Beulich <jbeulich@xxxxxxxx>
---
 xen/arch/x86/cpu/amd.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c
index 805a8189e6..b3e12b084c 100644
--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -1115,8 +1115,9 @@ static void cf_check init_amd(struct cpuinfo_x86 *c)
                 * Branch Type Confusion, but predate the allocation of the
                 * BTC_NO bit.  Fill it back in if we're not virtualised.
                 */
-               if (!cpu_has_hypervisor && !cpu_has(c, X86_FEATURE_BTC_NO))
-                       __set_bit(X86_FEATURE_BTC_NO, c->x86_capability);
+               if (c == &boot_cpu_data && !cpu_has_hypervisor &&
+                   !cpu_has(c, X86_FEATURE_BTC_NO))
+                       setup_force_cpu_cap(X86_FEATURE_BTC_NO);
                break;
        }
 
--
generated by git-patchbot for /home/xen/git/xen.git#staging