From: "Woodhouse, David" <david.woodhouse@intel.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@elte.hu>,
"Song, Youquan" <youquan.song@intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"hpa@zytor.com" <hpa@zytor.com>,
"hpa@linux.intel.com" <hpa@linux.intel.com>,
"Kay, Allen M" <allen.m.kay@intel.com>,
"Siddha, Suresh B" <suresh.b.siddha@intel.com>,
"Sankaran, Rajesh" <rajesh.sankaran@intel.com>,
"Mallick, Asit K" <asit.k.mallick@intel.com>,
"Liu, Kent" <kent.liu@intel.com>,
Youquan Song <youquan.song@linux.intel.com>
Subject: Re: [PATCH v4] x86, vt-d: enable x2apic opt out
Date: Thu, 26 May 2011 00:37:50 +0100 [thread overview]
Message-ID: <1306366670.2029.46.camel@i7.infradead.org> (raw)
In-Reply-To: <alpine.LFD.2.02.1105252359460.3078@ionos>
[-- Attachment #1: Type: text/plain, Size: 1501 bytes --]
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@intel.com Intel Corporation
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6242 bytes --]
next prev parent reply other threads:[~2011-05-25 23:38 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-25 16:36 Youquan Song
2011-05-25 20:58 ` Ingo Molnar
2011-05-25 22:01 ` Thomas Gleixner
2011-05-25 23:37 ` Woodhouse, David [this message]
2011-06-09 15:34 ` Youquan Song
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1306366670.2029.46.camel@i7.infradead.org \
--to=david.woodhouse@intel.com \
--cc=akpm@linux-foundation.org \
--cc=allen.m.kay@intel.com \
--cc=asit.k.mallick@intel.com \
--cc=hpa@linux.intel.com \
--cc=hpa@zytor.com \
--cc=kent.liu@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rajesh.sankaran@intel.com \
--cc=suresh.b.siddha@intel.com \
--cc=tglx@linutronix.de \
--cc=youquan.song@intel.com \
--cc=youquan.song@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®