[lkml]   [2011]   [May]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH v4] x86, vt-d: enable x2apic opt out
    On Wed, 2011-05-25 at 23:01 +0100, Thomas Gleixner wrote:
    > On Wed, 25 May 2011, Ingo Molnar wrote:
    > > So why isnt the x2apic disabled in the CPUID? That's the canonical
    > > way to unsupport a particular non-working CPU hw feature.

    A valid question. Rajesh?

    > Because some committee decided to make it an ACPI feature.
    > That's broken by design, but you can't change the stupid spec retroactively.

    You can ask for clarification of the stupid spec though. :)

    Is it *really* tied to interrupt-remapping, as the wording in the spec

    In particular, what about the case where VT-d has been disabled in the
    BIOS so there is *no* DMAR table at all, and hence nowhere for this 'opt
    out' bit to be set?

    Currently, it looks like we still enable x2apic in that case. We have a
    *build* time dependency which means you can't build x2apic support
    unless you also build interrupt-remapping support. But unless there's a
    lot of dead code in our x2apic support, it looks like we still enable
    x2apic at run time if we didn't enable IR for various reasons.

    Is that going to make these broken BIOSes fall over too? If so, it
    really does look like the placement of this bit in the DMAR table is
    entirely wrong.

    Rajesh, can you tell use *exactly* what is the BIOS brokenness that this
    hack was invented to work around?

    David Woodhouse Open Source Technology Centre Intel Corporation
    [unhandled content-type:application/x-pkcs7-signature]
     \ /
      Last update: 2011-05-26 01:41    [W:0.021 / U:22.688 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site