A XenServer feature in the process of being upstreamed is to be able to re-caculate 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 upstream the feature. Signed-off-by: Andrew Cooper <[email protected]> --- CC: Jan Beulich <[email protected]> CC: Roger Pau Monné <[email protected]> v2: * Rewrite the commit message. --- 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 805a8189e6cd..b3e12b084c56 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; } -- 2.39.5
