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>