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

[Shashank Balaji <shashank.mahadasyam@xxxxxxxx>]

On Thu, Feb 05, 2026 at 04:10:37PM -0800, Sohil Mehta wrote:
> 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?

Sorry about the confusion, I should have used '()'.
x86_init.hyper.x2apic_available() is called only in
try_to_enable_x2apic(). Here's the relevant snippet:

        static __init void try_to_enable_x2apic(int remap_mode)
        {
                if (x2apic_state == X2APIC_DISABLED)
                        return;

                if (remap_mode != IRQ_REMAP_X2APIC_MODE) {
                        u32 apic_limit = 255;

                        /*
                         * Using X2APIC without IR is not architecturally 
supported
                         * on bare metal but may be supported in guests.
                         */
                        if (!x86_init.hyper.x2apic_available()) {
                                pr_info("x2apic: IRQ remapping doesn't support 
X2APIC mode\n");
                                x2apic_disable();
                                return;
                        }

So the question being asked is, "can x2apic be used without IR?", but
the name "x2apic_available" signals "is x2apic available?". I found this
confusing while going through the source.

Most hypervisors set their x2apic_available() implementation to
essentially return if the CPU supports x2apic or not, which is valid
given the name "x2apic_available", but x2apic availability is not what's in
question at the callsite.

> > 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?

If IR is enabled, then the branch to call x2apic_available() wouldn't be taken 
:)
So the meaning of x2apic_without_ir_available wouldn't be relevant
anymore.

> 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.
 
I agree with you, and I think therein lies the problem. Most hypervisors
are answering the broader question "is x2apic available?", so the name
"x2apic_available" makes sense.

I think further work is required to check if various implementations of
x2apic_available() also need to be changed to reflect the "x2apic
without IR?" semantic, but I don't know enough to do that myself. Maybe
I should have added TODOs above the implementations.

I would like the feedback of the virt folks too on all this, maybe I'm
misinterpreting what's going on here.

> > 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?