From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wei Huang Subject: Re: [PATCH] FPU LWP 5/8: add a mask option to xsave() and xrstor() Date: Wed, 4 May 2011 11:03:27 -0500 Message-ID: <4DC178CF.2070307@amd.com> References: <4DC062D3.9000906@amd.com> <4DC1162D020000780003F9BA@vpn.id2.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4DC1162D020000780003F9BA@vpn.id2.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jan Beulich Cc: Keir, "xen-devel@lists.xensource.com" , Fraser List-Id: xen-devel@lists.xenproject.org Hi Jan, That is a good point. So far there isn't a way to decide which bits are guarded by CR0.TS. I will bring it up to our design team. I guess LWP will the only exception for a long while. Is the first approach sufficient/acceptable to you for now? #define XSTATE_LAZY (XSTATE_ALL & ~XSTATE_NONLAZY) Thanks, -Wei On 05/04/2011 02:02 AM, Jan Beulich wrote: >>>> On 03.05.11 at 22:17, Wei Huang wrote: >> +#define XSTATE_LAZY (XSTATE_FP | XSTATE_SSE | XSTATE_YMM) >> +#define XSTATE_NONLAZY (XSTATE_LWP) >> +#define XSTATE_ALL (~0) > As said before, this isn't forward compatible. New bits added in > future hardware should explicitly *not* require changes to the OS > (or hypervisor in our case). If you're certain LWP will remain the > only piece not controlled via CR0.TS, then you'll want > > #define XSTATE_LAZY (XSTATE_ALL& ~XSTATE_NONLAZY) > > If you aren't (and I'm afraid you can't), then you'll have to ask > your hardware guys to provide a means to detect which of the > bits cover state not controlled by CR0.TS, and set these masks > dynamically. > > Jan > >