Re: [PATCH v2 0/6] add xsaves/xrstors support

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 17/07/15 08:26, Shuai Ruan wrote:
> Changes in v2:
> * Address comments from Andrew/chao/Jan, mainly:
> * Add details information of xsaves/xrstors feature.
> * Remove XGETBV1/XSAVEC/XSAVEOPT out of 'else' in patch 3.
> * Change macro name XGETBV to XGETBV1 in patch 4.
>
> This patchset enable xsaves/xrstors feature which will be available on 
> Intel Skylake and later platform. Like xsave/xrstor, xsaves/xrstors 
> feature will save and load processor state from a region of memory called 
> XSAVE area. While unlike xsave/xrstor, xsaves/xrstors:
>
> a) use the compacted format only for the extended region 
>    of the XSAVE area which saves memory for you;
> b) can operate on supervisor state components so the feature
>    is prerequisite to support new supervisor state components;
> c) execute only if CPL=0. 
>
> Detail hardware spec can be found in chapter 13 (section 13.11 13.12) of the 
> Intel SDM [1].
>
> patch1: add xsaves/xrstors support for pv guest
> patch2: add xsaves/xrstors support for xen
> patch3-5: add xsaves/xrstors support for hvm guest
> patch6: swtich on detection of xsaves/xrstors/xgetbv in xen
>
> [1] Intel SDM (http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf)

Thankyou for this - it is far more useful 0/$N now.

However, looking at the series, you clearly have not tried migrating a
VM between two different servers, one which is xsavec capable and one
which is not.

The reason why Xen does not currently use compressed xsave areas is that
it has an ABI to maintain which predates compression.  In some cases
there is no question; the uncompressed format must be used.  In other
cases such as migration itself, compressed format could be used, but may
not assume that the far side of the migration has hardware capable of
processing the compressed format.

~Andrew