• Sean Christopherson's avatar
    KVM: x86: Don't inhibit APICv/AVIC if xAPIC ID mismatch is due to 32-bit ID · f651a008
    Sean Christopherson authored
    Truncate the vcpu_id, a.k.a. x2APIC ID, to an 8-bit value when comparing
    it against the xAPIC ID to avoid false positives (sort of) on systems
    with >255 CPUs, i.e. with IDs that don't fit into a u8.  The intent of
    APIC_ID_MODIFIED is to inhibit APICv/AVIC when the xAPIC is changed from
    it's original value,
    
    The mismatch isn't technically a false positive, as architecturally the
    xAPIC IDs do end up being aliased in this scenario, and neither APICv
    nor AVIC correctly handles IPI virtualization when there is aliasing.
    However, KVM already deliberately does not honor the aliasing behavior
    that results when an x2APIC ID gets truncated to an xAPIC ID.  I.e. the
    resulting APICv/AVIC behavior is aligned with KVM's existing behavior
    when KVM's x2APIC hotplug hack is effectively enabled.
    
    If/when KVM provides a way to disable the hotplug hack, APICv/AVIC can
    piggyback whatever logic disables the optimized APIC map (which is what
    provides the hotplug hack), i.e. so that KVM's optimized map and APIC
    virtualization yield the same behavior.
    
    For now, fix the immediate problem of APIC virtualization being disabled
    for large VMs, which is a much more pressing issue than ensuring KVM
    honors architectural behavior for APIC ID aliasing.
    
    Fixes: 3743c2f0 ("KVM: x86: inhibit APICv/AVIC on changes to APIC ID or APIC base")
    Reported-by: default avatarSuravee Suthikulpanit <suravee.suthikulpanit@amd.com>
    Cc: stable@vger.kernel.org
    Reviewed-by: default avatarMaxim Levitsky <mlevitsk@redhat.com>
    Signed-off-by: default avatarSean Christopherson <seanjc@google.com>
    Message-Id: <20230106011306.85230-7-seanjc@google.com>
    Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
    f651a008
lapic.c 78.6 KB