linux-kernel - Re: linux-next: manual merge of the dwmw2-iommu tree with Linus' tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20110525114010.GF30983@elte.hu>
Date:	Wed, 25 May 2011 13:40:10 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	David Woodhouse <dwmw2@...radead.org>
Cc:	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
	"Song, Youquan" <youquan.song@...el.com>,
	Suresh Siddha <suresh.b.siddha@...el.com>
Subject: Re: linux-next: manual merge of the dwmw2-iommu tree with Linus' tree

* David Woodhouse <dwmw2@...radead.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/