[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 1/3] libxc/xc_domain_resume: Update comment.
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |