linux-kernel - Re: [Xen-devel] [PATCH] x86 fixes for 3.3 impacting distros (v1).

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]

Date:	Fri, 29 Jun 2012 14:52:25 -0700
From:	Cyclonus J <cyclonusj@...il.com>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	marmarek@...isiblethingslab.com, xen-devel@...ts.xensource.com,
	x86@...nel.org, Jason Garrett-Glaser <jason@...4.com>,
	linux-kernel@...r.kernel.org, rostedt@...dmis.org,
	mingo@...hat.com, tglx@...utronix.de,
	"Siddha, Suresh B" <suresh.b.siddha@...el.com>
Subject: Re: [Xen-devel] [PATCH] x86 fixes for 3.3 impacting distros (v1).

On Thu, Jun 28, 2012 at 07:42:12AM -0700, H. Peter Anvin wrote:
> On 06/28/2012 07:28 AM, Konrad Rzeszutek Wilk wrote:
> > 
> > Peter mentioned to me had some ideas about software PAT table lookup. I am not
> > exactly sure what he meant by that.
> > 
> 
> I could see the kernel have programmable PAT values rather than fixed if
> and only if it can be showed to have no measurable performance impact.
> 
> > Just to summarize, there were two ways proposed to fix this:
> > 
> >  1). Make __page_change_attr_set_clr use a new wrapper: pte_attr, that calls
> >      pte_val (pvops call) instead of pte_flag (native). Here is the patch:
> >      http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=commitdiff;h=4f93aa02acd0e34806d4ac9c3a700bb5d040eab6
> >      (no perf regressions across all platforms)
> > 
> >  2). Introduce a new pvops call - pte_flags, which would make pte_flags
> >      (which currently is doing just a bit mask) be pvops-fied.
> >      http://darnok.org/results/baseline_pte_flags_pte_attrs/0001-x86-paravirt-xen-Introduce-pte_flags.patch
> >      http://darnok.org/results/baseline_pte_flags_pte_attrs/0002-x86-paravirt-xen-Optimize-pte_flags-by-marking-it-as.patch
> >      (weird results on AMD, other platforms had no perf degradations)
> > 
> >   3). (not posted), was to do 2), but alter the alternative_asm and instead use asm_goto to
> >      make the compiler use less registers and hopefully reduce the code:
> >      http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=shortlog;h=refs/heads/devel/mmu-perf
> >      But the results I got showed worst performance on baremetal.. which was weird?
> >      Perhaps it is compiler related - never got to follow up on it.
> > 
> 
> OK, let me be blunt: I will unconditionally veto any of these.

Peter,

hmm, It looks like option 1 doesn't have any perf regression, but it is still
not acceptable? That is fine. If you prefer to have a software PAT table lookup, could you provide
some details so I can try to get something align that direction?

CJ

> 
> > 
> > I also chatted with the core Xen hypervisor folks about adding in the context switch code
> > to alter the PAT layout - but they were not keen a about it - and I am not sure how much
> > CPU cycles one loses by doing a wrmsr to the PAT register on every guest context switch
> > (worst case when on has a pvops kernel and a old-style one - where the WC bit would differ)?
> > 
> 
> And you're comparing that to a bunch of new pvops calls?  The discussion
> shouldn't even have started until you had ruled out this solution and
> had data to show it.
> 
> 	-hpa
--
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/