lkml.org 
[lkml]   [2011]   [May]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH v2] x86, vt-d: enable x2apic opt out
    On Mon, 2011-05-16 at 21:32 +0100, Alex Williamson wrote:
    >
    > > Is this just a workaround for a crappy BIOS? What is the *actual* reason
    > > for wanting to disable x2apic?
    >
    > Just a guess, but the OEM probably hasn't updated their SMI handlers to
    > understand x2apic yet and won't before the product ships because some
    > other OS doesn't bother to use x2apic.

    But I think we'll still use x2apic if interrupt remapping isn't enabled
    (for example if VT-d is disabled in the BIOS and the whole DMAR table is
    absent), or if we're booted with 'iommu=off' or indeed if the
    distribution vendor has hacked the kernel so that iommu=off is the
    *default*, because they've seen so many broken BIOSes.

    AFAICT although CONFIG_X86_X2APIC depends on CONFIG_INTR_REMAP, we can
    still enable x2apic at runtime if interrupt remapping is not operating?
    We end up hitting this code in enable_IR_x2apic():

    if (!ret) {
    /* IR is required if there is APIC ID > 255 even when running
    * under KVM
    */
    if (max_physical_apicid > 255 ||
    !hypervisor_x2apic_available())
    goto nox2apic;
    /*
    * without IR all CPUs can be addressed by IOAPIC/MSI
    * only in physical mode
    */
    x2apic_force_phys();
    }

    So if that *is* the reason, this doesn't seem like a viable solution.

    --
    David Woodhouse Open Source Technology Centre
    David.Woodhouse@intel.com Intel Corporation
    [unhandled content-type:application/x-pkcs7-signature]
    \
     
     \ /
      Last update: 2011-05-19 01:01    [W:4.442 / U:0.060 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site