Re: [Xen-devel] [PATCH 1/3] libxc/xc_domain_resume: Update comment.

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Tue, 2016-01-26 at 14:47 -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Jan 26, 2016 at 04:19:54PM +0000, Ian Campbell wrote:
> > On Mon, 2016-01-25 at 16:06 -0500, Konrad Rzeszutek Wilk wrote:
> > > To hopefully clarify what it meant.
> > > 
> > > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
> > > ---
> > > Âtools/libxc/xc_resume.c | 7 +++++--
> > > Â1 file changed, 5 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/tools/libxc/xc_resume.c b/tools/libxc/xc_resume.c
> > > index 87d4324..19ba2a3 100644
> > > --- a/tools/libxc/xc_resume.c
> > > +++ b/tools/libxc/xc_resume.c
> > > @@ -248,9 +248,12 @@ out:
> > > Â/*
> > > Â * Resume execution of a domain after suspend shutdown.
> > > Â * This can happen in one of two ways:
> > > - *ÂÂ1. Resume with special return code.
> > > - *ÂÂ2. Reset guest environment so it believes it is resumed in a new
> > > + *ÂÂ1. (fast=1) Resume with special return code (1) that the guest
> > > + *ÂÂÂÂÂgets from SCHEDOP_shutdown:SHUTDOWN_suspend.
> > 
> > "SCHEDOP_shutdown(SHUTDOWN_suspend)" looks more like the function call
> > which this in effect is.
> > 
> > I think I'd say "Resume the guest without resetting the domain
> > environment.
> > The guests's call to SCHEDOP_shutdown(SHUTDOWN_suspend) will return 1".
> > 
> > (assuming that is true re resetting)
> > 
> > > + *
> > > + *ÂÂ2. (fast=0) Reset guest environment so it believes it is resumed
> > > in a new
> > > Â *ÂÂÂÂÂdomain context.
> > 
> > with the above I would suggesting adding "The guests's call to
> > SCHEDOP_shutdown(SHUTDOWN_suspend) will return 0".
> > 
> > > + *
> > > Â * (2) should be used only for guests which cannot handle the
> > > special
> > > Â * new return code. (1) is always safe (but slower).
> > 
> > Is this correct? I'd have said (2) was always safe but slow?
> 
> That does not sound right. It should have said that fast=1 
> would be fast but not safe. And 2) (fast=0) is safe but slower.
> 
> Let me resend this - with it hopefully being more clear.
> > 
> > And I would invert the first, that is to say that (1) should be used in
> > preference with guests which support it.
> 
> Reading the 1) I am bit perplexed. It says "safe" but what it does is far
> from safe - it manipulates the vCPU eax register to be 1. Granted it does
> it on a "paused" vCPU and once the vCPU resume it can read it.

I think "(1) is always safe (but slower)" should have always read "(2) is
always safe (but slower)". (1) has always been "fast and loose" and
requires guest side support.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel