Date: Sun, 21 May 2006 16:51:48 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: David Xu <davidxu@freebsd.org> Cc: Rostislav Krasny <rosti.bsd@gmail.com>, Igor Sysoev <is@rambler-co.ru>, Colin Percival <cperciva@freebsd.org>, freebsd-current@freebsd.org Subject: Re: [PATCH] FreeBSD-SA-06:14.fpu Message-ID: <200605212351.k4LNpmhJ095330@apollo.backplane.com> References: <20060430142408.fcd60069.rosti.bsd@gmail.com> <20060519210105.d4418b6f.rosti.bsd@gmail.com> <20060520012653.41cf7366.rosti.bsd@gmail.com> <200605211606.43381.davidxu@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:>
:> By the way, following command could be used to check how kernel has
:> been compiled, regarding the CPU_FXSAVE_LEAK option:
:>
:> objdump -x /boot/kernel/kernel | grep fpu_clean_state
:
:The patch looks fine to me, but can it be CPU_FXSAVE_NOLEAK ?
:so only people know the problem will turn it on.
:
:David Xu
I don't think it really needs to be optioned. Since the FPU state
is demand-loaded from a trap/exception anyway, a huge amount of code
is run in the same path that fpu_clean_state is called from.
fpu_clean_state itself only eats a few nanoseconds (like maybe ~1/10
of the time that fninit takes).
-Matt
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200605212351.k4LNpmhJ095330>