From: Ingo Molnar <mingo@elte.hu>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
linux-next@vger.kernel.org, linux-kernel@vger.kernel.org, "Song,
Youquan" <youquan.song@intel.com>,
Suresh Siddha <suresh.b.siddha@intel.com>
Subject: Re: linux-next: manual merge of the dwmw2-iommu tree with Linus' tree
Date: Wed, 25 May 2011 13:40:10 +0200 [thread overview]
Message-ID: <20110525114010.GF30983@elte.hu> (raw)
In-Reply-To: <alpine.LFD.2.02.1105251133001.3164@localhost6.localdomain6>
* David Woodhouse <dwmw2@infradead.org> wrote:
> On Wed, 25 May 2011, Ingo Molnar wrote:
>
> > That particular change was still under discussion and i'm not at all
> > sure we want to do it like that. So please repost the latest version.
>
> I had not seen such discussion; I had the impression that having dealt
> with my feedback about making the thing more visible to the user, Youquan
> considered the patch complete.
I lurked your discussion with Youquan and expected another iteration
posted. I was keeping my gun powder dry for the next round because i
saw you reaping the patch to pieces already and there was nothing
more to say really :)
> I am more than happy to absolve responsibility for this patch
> altogether and drop it from tree, though. It is *absolutely* the
> wrong approach, in my opinion. If the BIOS is broken and cannot
> cope with x2apic, the solution is to line the "engineers"
> responsible up against the wall and shoot them. And then to
> implement a "quiesce all SMI" feature that the OS can invoke, and
> make it mandatory. Presumably that's the underlying problem they
> were trying to solve?
>
> The answer certainly isn't to add a flag in the DMAR table to opt
> out of x2apic use, when afaict the kernel is capable of using
> x2apic in some cases even when the *is* no DMAR. (Either that, or
> we have a lot of dead code in that area which *looks* like it copes
> with x2apic+!dmar).
Yeah, that was exactly my main concern as well: why should we allow
the BIOS to tell us not to use a CPU feature that the CPU tells us is
usable?
We generally do not allow such level of BIOS control. They should fix
the BIOS to not generate DMAR tables at all if they want us to 'opt
out', or ship a CPU without x2apic (or a CPU microcode version that
turns off the x2apic CPUID bit or whatever).
So unless i missed some fine detail of control here, the whole idea
of generating DMAR tables (which were always inherently connected to
x2apic really) that tell us 'never mind about x2apic!' seems rather
counter-productive ...
> I'll drop this patch from my tree when I get home and happily wash
> my hands of it. It's all yours; have fun :)
Thanks. Youquan, mind resending the latest and greatest version so we
can continue flami^W iterating it? Please also Cc: David.
Thanks,
Ingo
next prev parent reply other threads:[~2011-05-25 11:40 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-25 3:00 linux-next: manual merge of the dwmw2-iommu tree with Linus' tree Stephen Rothwell
2011-05-25 9:16 ` Ingo Molnar
2011-05-25 10:57 ` David Woodhouse
2011-05-25 11:40 ` Ingo Molnar [this message]
2011-05-25 20:16 ` Youquan Song
2011-05-25 20:59 ` David Woodhouse
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=20110525114010.GF30983@elte.hu \
--to=mingo@elte.hu \
--cc=dwmw2@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=sfr@canb.auug.org.au \
--cc=suresh.b.siddha@intel.com \
--cc=youquan.song@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;
as well as URLs for NNTP newsgroup(s).