Re: [PATCH v4] x86, vt-d: enable x2apic opt out

[Woodhouse, David]

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

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
David.Woodhouse@xxxxxxxxx                              Intel Corporation

Attachment: smime.p7s
Description: S/MIME cryptographic signature