From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 1/2] x86: eliminate TS_XSAVE Date: Sun, 02 May 2010 20:44:56 +0300 Message-ID: <4BDDBA18.3080909@redhat.com> References: <1272812038-32484-1-git-send-email-avi@redhat.com> <1272812038-32484-2-git-send-email-avi@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Dexuan Cui , Sheng Yang , Ingo Molnar , "H. Peter Anvin" , linux-kernel@vger.kernel.org, kvm@vger.kernel.org To: Brian Gerst Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 05/02/2010 08:38 PM, Brian Gerst wrote: > On Sun, May 2, 2010 at 10:53 AM, Avi Kivity wrote: > >> The fpu code currently uses current->thread_info->status& TS_XSAVE as >> a way to distinguish between XSAVE capable processors and older processors. >> The decision is not really task specific; instead we use the task status to >> avoid a global memory reference - the value should be the same across all >> threads. >> >> Eliminate this tie-in into the task structure by using an alternative >> instruction keyed off the XSAVE cpu feature; this results in shorter and >> faster code, without introducing a global memory reference. >> > I think you should either just use cpu_has_xsave, or extend this use > of alternatives to all cpu features. It doesn't make sense to only do > it for xsave. > I was trying to avoid a performance regression relative to the current code, as it appears that some care was taken to avoid the memory reference. I agree that it's probably negligible compared to the save/restore code. If the x86 maintainers agree as well, I'll replace it with cpu_has_xsave. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.