Re: [PATCH 3/3] x86/virt: rename x2apic_available to x2apic_without_ir_available

[Sohil Mehta <sohil.mehta@xxxxxxxxx>]

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?