WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: [PATCH] FPU LWP 5/8: add a mask option to xsave() and x

To: Jan Beulich <JBeulich@xxxxxxxxxx>
Subject: [Xen-devel] Re: [PATCH] FPU LWP 5/8: add a mask option to xsave() and xrstor()
From: Wei Huang <wei.huang2@xxxxxxx>
Date: Wed, 4 May 2011 11:03:27 -0500
Cc: Keir, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Fraser <keir@xxxxxxx>
Delivery-date: Wed, 04 May 2011 09:07:07 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4DC1162D020000780003F9BA@xxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4DC062D3.9000906@xxxxxxx> <4DC1162D020000780003F9BA@xxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
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<wei.huang2@xxxxxxx>  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





_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel