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@xxxxxxxxxxxxx]
Sent: 2008年5月28日 20:43
To: Cui, Dexuan; xen-devel@xxxxxxxxxxxxxxxxxxx
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@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Cui, Dexuan
> Sent: 2008年5月28日 20:03
> To: Keir Fraser; xen-devel@xxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxx>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home