The attached patch adds the support of xsave/xrstor infrastructure for x86. xsave/xrstor manages the existing and future processor extended states in x86 architecture. The XSAVE/XRSTOR/XGETBV/XSETBV instructions and the Processor Extended State are defined in the Intel SDMs: http://www.intel.com/products/processor/manuals/ The basic ideas of the patch are: 1) enable the xsave/xrstor feature when Xen boots; 2) xsave/xrstor the related processor states (i.e., FPU/MMX, SSE) on vcpu context switch; 3) with the xsave/xrstor feature enabled, Xen doesn''t intercept HVM vcpu''s #NM at all, and Xen still intercepts PV vcpu''s #NM and forwards it into PV vcpu if necessary; 4) xsave/xrstor-aware HVM guest is supported in the patch. Signed-off-by: Dexuan Cui <dexuan.cui@intel.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi Keir,
In the xsave/xrstor patch, I don''t use
"arch.guest_context.fpu_ctxt" any longer.
I use "arch_vcpu.xsave_area" to save the processor extended states.
Looks this causes trouble for guest''s save/restore (including PV guest
and HVM guest):
On xsave/xrstor-capable host, to support guest''s save/restore, Control
Panel should save/restore the variable-length "xsave_area", but the
current hypercall XEN_DOMCTL_{get/set}vcpucontext can''t transfer the
"xsave_area" between Control Panel and hypervisor, so a new hypercall
is needed for this? Looks it''s not very easy to make the codes clean...
:(
Could you give some suggestions?
Thanks!
-- Dexuan
-----Original Message-----
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Cui, Dexuan
Sent: 2008年5月28日 20:03
To: Keir Fraser; xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] Add xsave/xrstor support to Xen
The attached patch adds the support of xsave/xrstor infrastructure for
x86.
xsave/xrstor manages the existing and future processor extended states
in x86 architecture.
The XSAVE/XRSTOR/XGETBV/XSETBV instructions and the Processor Extended
State are defined in the Intel SDMs:
http://www.intel.com/products/processor/manuals/
The basic ideas of the patch are:
1) enable the xsave/xrstor feature when Xen boots;
2) xsave/xrstor the related processor states (i.e., FPU/MMX, SSE) on
vcpu context switch;
3) with the xsave/xrstor feature enabled, Xen doesn''t intercept HVM
vcpu''s #NM at all, and Xen still intercepts PV vcpu''s #NM and
forwards
it into PV vcpu if necessary;
4) xsave/xrstor-aware HVM guest is supported in the patch.
Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
I''m missing any context about these new instructions. Why would we use them rather than FXSAVE/FXRSTOR? They seem to save the same state. Unless the amount of PV guest state that needs to be saved/restored has actually been extended then there will be no need to change the cpucontext hypercalls or the save/restore format. -- Keir On 28/5/08 13:06, "Cui, Dexuan" <dexuan.cui@intel.com> wrote:> Hi Keir, > In the xsave/xrstor patch, I don''t use "arch.guest_context.fpu_ctxt" any > longer. > I use "arch_vcpu.xsave_area" to save the processor extended states. > > Looks this causes trouble for guest''s save/restore (including PV guest and HVM > guest): > > On xsave/xrstor-capable host, to support guest''s save/restore, Control Panel > should save/restore the variable-length "xsave_area", but the current > hypercall XEN_DOMCTL_{get/set}vcpucontext can''t transfer the "xsave_area" > between Control Panel and hypervisor, so a new hypercall is needed for this? > Looks it''s not very easy to make the codes clean... :( > > Could you give some suggestions? > > Thanks! > > -- Dexuan > > > -----Original Message----- > From: xen-devel-bounces@lists.xensource.com > [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Cui, Dexuan > Sent: 2008年5月28日 20:03 > To: Keir Fraser; xen-devel@lists.xensource.com > Subject: [Xen-devel] [PATCH] Add xsave/xrstor support to Xen > > The attached patch adds the support of xsave/xrstor infrastructure for > x86. > xsave/xrstor manages the existing and future processor extended states > in x86 architecture. > > The XSAVE/XRSTOR/XGETBV/XSETBV instructions and the Processor Extended > State are defined in the Intel SDMs: > http://www.intel.com/products/processor/manuals/ > > The basic ideas of the patch are: > 1) enable the xsave/xrstor feature when Xen boots; > 2) xsave/xrstor the related processor states (i.e., FPU/MMX, SSE) on > vcpu context switch; > 3) with the xsave/xrstor feature enabled, Xen doesn''t intercept HVM > vcpu''s #NM at all, and Xen still intercepts PV vcpu''s #NM and forwards > it into PV vcpu if necessary; > 4) xsave/xrstor-aware HVM guest is supported in the patch. > > Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
The xsave/xrstor infrastructure is mainly for extensibility with respect to the "processor extened states" since more extended states are coming (i.e. http://softwarecommunity.intel.com/isn/downloads/intelavx/Intel-AVX-Programming-Reference-31943302.pdf). With the patch, XSAVE-aware HVM guest can make use of the coming extended features. And Intel SDM 3A: chatper 12 ( SYSTEM PROGRAMMING FOR INSTRUCTION SET EXTENSIONS AND PROCESSOR EXTENDED STATES) supplies a generic description. BTW, some CPU, such as Intel Core 2 Duo Processor E8500, E8400, have had the support of the XSAVE/XRSTOR instructions. For now, the xsave_area is at least 512 + 64 (the xsave header) = 576 bytes in length, though the first 512 bytes are completely compatible with the legacy 512-byte arch.guest_context.fpu_ctxt; actually we also have to save the per-vcpu 64-bit "xfeature_mask", and the gloabal variables "xsave_cntxt_max_size, xfeature_low, xfeature_high" (imagine different CPU has different XSAVE capability). So I think we have to extend the current save/restore format. -- Dexuan -----Original Message----- From: Keir Fraser [mailto:keir.fraser@eu.citrix.com] Sent: 2008年5月28日 20:43 To: Cui, Dexuan; xen-devel@lists.xensource.com Subject: Re: [Xen-devel] [PATCH] Add xsave/xrstor support to Xen I''m missing any context about these new instructions. Why would we use them rather than FXSAVE/FXRSTOR? They seem to save the same state. Unless the amount of PV guest state that needs to be saved/restored has actually been extended then there will be no need to change the cpucontext hypercalls or the save/restore format. -- Keir On 28/5/08 13:06, "Cui, Dexuan" <dexuan.cui@intel.com> wrote:> Hi Keir, > In the xsave/xrstor patch, I don''t use "arch.guest_context.fpu_ctxt" any > longer. > I use "arch_vcpu.xsave_area" to save the processor extended states. > > Looks this causes trouble for guest''s save/restore (including PV guest and HVM > guest): > > On xsave/xrstor-capable host, to support guest''s save/restore, Control Panel > should save/restore the variable-length "xsave_area", but the current > hypercall XEN_DOMCTL_{get/set}vcpucontext can''t transfer the "xsave_area" > between Control Panel and hypervisor, so a new hypercall is needed for this? > Looks it''s not very easy to make the codes clean... :( > > Could you give some suggestions? > > Thanks! > > -- Dexuan > > > -----Original Message----- > From: xen-devel-bounces@lists.xensource.com > [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Cui, Dexuan > Sent: 2008年5月28日 20:03 > To: Keir Fraser; xen-devel@lists.xensource.com > Subject: [Xen-devel] [PATCH] Add xsave/xrstor support to Xen > > The attached patch adds the support of xsave/xrstor infrastructure for > x86. > xsave/xrstor manages the existing and future processor extended states > in x86 architecture. > > The XSAVE/XRSTOR/XGETBV/XSETBV instructions and the Processor Extended > State are defined in the Intel SDMs: > http://www.intel.com/products/processor/manuals/ > > The basic ideas of the patch are: > 1) enable the xsave/xrstor feature when Xen boots; > 2) xsave/xrstor the related processor states (i.e., FPU/MMX, SSE) on > vcpu context switch; > 3) with the xsave/xrstor feature enabled, Xen doesn''t intercept HVM > vcpu''s #NM at all, and Xen still intercepts PV vcpu''s #NM and forwards > it into PV vcpu if necessary; > 4) xsave/xrstor-aware HVM guest is supported in the patch. > > Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 28/5/08 14:11, "Cui, Dexuan" <dexuan.cui@intel.com> wrote:> For now, the xsave_area is at least 512 + 64 (the xsave header) = 576 bytes in > length, though the first 512 bytes are completely compatible with the legacy > 512-byte arch.guest_context.fpu_ctxt; actually we also have to save the > per-vcpu 64-bit "xfeature_mask", and the gloabal variables > "xsave_cntxt_max_size, xfeature_low, xfeature_high" (imagine different CPU has > different XSAVE capability). So I think we have to extend the current > save/restore format.I must say I am happy to wait until there are some actual extended state vectors to be saved. It''s not clear that the XSAVE format is the right way to extend the HVM save/restore format. The right direction may depend on what types of new state are introduced, whether these are achitectural or vendor-specific, etc. It doesn''t sound like there''s a downside to sitting on the fence and doing nothing for now. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel