On 2/2/2026 1:51 AM, Shashank Balaji wrote: > No functional change. > > x86_init.hyper.x2apic_available is used only in try_to_enable_x2apic to check > if > x2apic needs to be disabled if interrupt remapping support isn't present. But > the name x2apic_available doesn't reflect that usage. >
I don't understand the premise of this patch. Shouldn't the variable name reflect what is stored rather than how it is used? > This is what x2apic_available is set to for various hypervisors: > > acrn boot_cpu_has(X86_FEATURE_X2APIC) > mshyperv boot_cpu_has(X86_FEATURE_X2APIC) > xen boot_cpu_has(X86_FEATURE_X2APIC) or false > vmware vmware_legacy_x2apic_available > kvm kvm_cpuid_base() != 0 > jailhouse x2apic_enabled() > bhyve true > default false > If both interrupt remapping and x2apic are enabled, what would the name x2apic_without_ir_available signify? A value of "true" would mean x2apic is available without IR. But that would be inaccurate for most hypervisors. A value of "false" could be interpreted as x2apic is not available, which is also inaccurate. To me, x2apic_available makes more sense than x2apic_without_ir_available based on the values being set by the hypervisors. > Bare metal and vmware correctly check if x2apic is available without interrupt > remapping. The rest of them check if x2apic is enabled/supported, and kvm just > checks if the kernel is running on kvm. The other hypervisors may have to have > their checks audited. > AFAIU, the value on bare metal is set to false because this is a hypervisor specific variable. Perhaps I have misunderstood something?
