Xen devel - Aug 2009 - [RFC] xsave/xrstor: changes to the struct vcpu_guest_context

Hi all,
I'm working to add the xsave/xrstor support for Xen.
The related Intel SDMs are at http://www.intel.com/products/processor/manuals/
And AVX programming reference is at http://software.intel.com/en-us/avx/

After enabling xsave/xrstor in xen, with respect to guest save/restore(S/R) we
need to save more cpu-related states besides FPU/SSE, e.g., we need to save the
xsave_bv_header, and a new state like YMM state, and even more new states in the
future.
To not break guest S/R and keep the compatibility, I think we should make the
changes to the struct vcpu_guest_context as the attached example patch does:

The changes:
1)  define a new struct vcpu_guest_context_new: its first feild is the legacy
struct vcpu_guest_context and the other is the new xsave field;
2) add a new flag (a new bit definition) VGCF_xsave_valid to the existing
'flags' field;

My proposal:
During guest S/R, when we transfer the struct between tools and xen, we *will
always* use the new expanded struct vcpu_guest_context_new:
	3.1) in tools
		3.1.1) when restore:  first we only read the leading part of the struct
(namely, the legacy struct vcpu_guest_context); if VGCF_xsave_valid is set, we
further read the new xsave field;
		3.1.2) when save:  if VGCF_xsave_valid is set, we save the whole expanded
struct vcpu_guest_context_new; else, we only save the legacy part;
	3.2) in xen
		3.2.1) when restore: if VGCF_xsave_valid is set, use the whole expaned struct
vcpu_guest_context_new; else, only use the legacy part;
		3.2.2) when save: if the host supports xsave and the guest enables xsave, xen
sets VGCF_xsave_valid and fills the whole expanded struct
vcpu_guest_context_new;

In this way:
1) guest img saved in old xen, e.g. xen-3.2
	1.1) can be restored in xen-3.2 on xsave-{capable and incapble} host;
	1.2) can be restored in xen-unstable on xsave-{capable and incapble} host;

2) guest img saved in xen-unstable
	2.1) if the host doesn't support xsave, the saved img can be restored in
xen-3.2 or 'older' xen-unstable (namely, before the xsave patches are
checked in) on xsave-{capable and incapable} hosts;
	2.2) if the host does support xsave
		2.2.1) if guest doesn't use xsave, the saved img can be restored in
xen-3.2 or older xen-unstable on xsave-{capable and incapable} hosts;
		2.2.2) if guest does use xsave, the saved img can NOT be restored in xen-3.2
or older xen-unstable, and the saved image can NOT be restored in the new
xen-unstable (namely, after the xsave patches are checked in) on xsave-incapable
host.


BTW, for live migration: the rule and handling should be the same.

Could you please comment on this?  Thanks!

-- Dexuan 

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

On 11/08/2009 11:07, "Cui, Dexuan" <dexuan.cui@intel.com> wrote:
> 1)  define a new struct vcpu_guest_context_new: its first feild is the
legacy
> struct vcpu_guest_context and the other is the new xsave field;
> 2) add a new flag (a new bit definition) VGCF_xsave_valid to the existing
> ''flags'' field;
Looks like a kludge. Quite apart from the fact that messing with
vcpu_guest_contexrt is a pita because its format differs between 32-bit and
64-bit callers/guests.

Instead, I suggest to simply make new domctls to get/set xsave state in its
raw format. That same format can be introduced as a new
''chunk'' in HVM save
files too, and can automatically be included when making the ''hvm
save''
hypercall. By raw format I mean exactly the format produced by XSAVE, albeit
perhaps excluding the first 512 ''legacy'' bytes.

 -- Keir



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