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: <1475675843.11869.8.camel@redhat.com>
Date:   Wed, 05 Oct 2016 09:57:23 -0400
From:   Rik van Riel <riel@...hat.com>
To:     Paolo Bonzini <pbonzini@...hat.com>, linux-kernel@...r.kernel.org
Cc:     dave.hansen@...ux.intel.com, x86@...nel.org, tglx@...utronix.de,
        mingo@...hat.com, luto@...nel.org, pa@...or.com, bp@...e.de
Subject: Re: [PATCH 2/9] x86/fpu: Hard-disable lazy fpu mode

On Wed, 2016-10-05 at 09:14 +0200, Paolo Bonzini wrote:
> 
> On 05/10/2016 02:34, riel@...hat.com wrote:
> > 
> > From: Andy Lutomirski <luto@...nel.org>
> > 
> > Since commit 58122bf1d856 ("x86/fpu: Default eagerfpu=on on all
> > CPUs") in Linux 4.6, eager FPU mode has been the default on all x86
> > systems, and no one has reported any regressions.
> > 
> > This patch removes the ability to enable lazy mode: use_eager_fpu()
> > becomes "return true" and all of the FPU mode selection machinery
> > is
> > removed.
> 
> I haven't quite followed up on my promise to benchmark lazy vs. eager
> FPU, but I probably should do that now...
> 
> I see two possible issues with this.  First, AMD as far as I know
> does
> not have XSAVEOPT.  Second, when using virtualization, depending on
> how
> you configure your cluster it's enough to have one pre-SandyBridge
> Intel
> machine to force no XSAVE on all machines.

The "OPT" part of XSAVEOPT does not work across the
host/guest boundary, anyway.

One of the items used in the tuple that determines
whether the optimization can be used is whether
or not the system is in the VMX root, or in a guest.

In other words, across a VMEXIT / VMENTER boundary,
it does full saves & restores, if I am reading the
manual right.

-- 
All Rights Reversed.
Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ