From: Shuai Ruan <shuai.ruan@linux.intel.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: andrew.cooper3@citrix.com, keir@xen.org, xen-devel@lists.xen.org
Subject: Re: [V4] x86/xsaves: fix overwriting between non-lazy/lazy xsaves
Date: Tue, 15 Mar 2016 17:40:37 +0800 [thread overview]
Message-ID: <44168.0163880394$1458035125@news.gmane.org> (raw)
In-Reply-To: <56E2A8F502000078000DB869@prv-mh.provo.novell.com>
On Fri, Mar 11, 2016 at 03:16:05AM -0700, Jan Beulich wrote:
> I don't think this is what we want. In no case is this what I have
> been asking for (which also applies to the remainder of your reply).
> Just to re-iterate: Code outside of the code xsave() / xrstor()
> functions should not be concerned at all what specific save and
> restore instructions are being used. All it needs to care about is
> to know what layout the data is in, and whether compaction or
> expansion is needed while transferring state from / to a guest.
>
> The fact that we introduce a synthetic feature here is solely to
> satisfy the alternative instruction patching mechanism (and it
> could be dropped if both the save and restore paths came to
> use further conditionals, which may well be desirable - I think I
> had suggested this for one of the two paths already). And
> perhaps it was a mistake to scatter around the setting of
> XSTATE_COMPACTION_ENABLED.
>
> May I ask that you take a little step back and think about what
> our needs here really are? For this please consider that we want
> to save/restore state with as little overhead as possible (i.e. it
> may be warranted to make the choice of instruction depend on
> the set of components that need saving/restoring, rather than
> just the availability of certain instructions). And that choice of
> instruction(s) should be as transparent to the rest of the
> hypervisor as possible. Which for example means ...
>
> >> Or maybe (to amend the first comment above)
> >> "using_xsave_compact" is actually the wrong term now, and this
> >> really needs to become "using_xsaves" (in which case the change
> >> suggested in that first comment wouldn't be needed anymore). In
> > The term using_xsave_compact is confusing(actually here using_xsave_compact
> > means using_xsaves). Will change using_xsave_compact -> using_xsaves.
>
> ... that "using_xsaves" is not what the rest of the hypervisor is
> in need of knowing/checking. All that other code a most needs to
> know/check whether the state is / needs to be in compacted form.
>
> Jan
>
Sure. I write a few key points here.
1. For when to use "XSTATE_COMPACTION_ENABLED"
1). it will only be set in xrstor().
2). all code outside xsave()/xrstor() (exclude compress_xsave_states())
only check whether XSTATE_COMPACTION_ENABLED is set or not.
2. For when to use "using_xsaves"
1). only used in xrstor()/xsave().
2). xrstor will not stick to alternative patching. Will use
if(use_xsaves) instead.
3. For save/restore(migration)
1). for save, it is ok to check XSTATE_COMPACTION_ENABLED of
xsave->xsave_hdr.xcomp_bv to decide whether expanded is
needed or not.
2). for restore, in compress_xsave_states(), we can not check
XSTATE_COMPACTION_ENABLED of xsave->xsave_hdr.xcomp_bv
to decide whether compress is needed or not (for
XSTATE_COMPACTION_ENABLED will only be set when perform
first xrstor()).
we should use "using_xsaves" is tell whether compact is needed
or not.(this is the only place outside xsave()/xrstor()
depend on "using_xsaves")
Code in compress_xsave_states looks as follow.
....
if ( !using_xsaves && !xsave_area_compress(src) )
{
memcpy
return
}
.....
compress src
For more detail:
xrstor() will look as follow:
if ( using_xsaves )
{
if ( unlikely(!(prt->xsave_hdr->xcom_bv &
XSTATE_COMPACTION_ENABLED)) )
ptr->xsave_hdr->xcomp_bv =
ptr->xsave_hdr->xstate_bv |
XSTATE_COMPACTION_ENABLED;
XRSTORS;
}
else
XRSTOR;
Any comments on this?
I know you are busy :) and really thanks for
your time spent on making this clear to me.
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-03-15 9:40 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-10 8:22 [V4] x86/xsaves: fix overwriting between non-lazy/lazy xsaves Shuai Ruan
2016-03-10 9:30 ` Jan Beulich
2016-03-11 6:45 ` Shuai Ruan
[not found] ` <20160311064516.GA11162@shuai.ruan@linux.intel.com>
2016-03-11 10:16 ` Jan Beulich
2016-03-15 9:40 ` Shuai Ruan [this message]
[not found] ` <20160315094037.GA4682@shuai.ruan@linux.intel.com>
2016-03-15 13:33 ` Jan Beulich
2016-03-16 9:35 ` Shuai Ruan
[not found] ` <20160316093436.GA3531@shuai.ruan@linux.intel.com>
2016-03-16 10:08 ` Jan Beulich
2016-03-16 10:51 ` Shuai Ruan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='44168.0163880394$1458035125@news.gmane.org' \
--to=shuai.ruan@linux.intel.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=keir@xen.org \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).