On 04/22/2015 10:54 PM, Ian Campbell wrote: > On Wed, 2015-04-01 at 14:41 +0800, Yang Hongyang wrote: >> From: Wen Congyang <we...@cn.fujitsu.com> >> >> For PVHVM, the hypercall return code is 0, and it can be resumed >> in a new domain context. >> >> For HVM, do nothing. >> >> Signed-off-by: Wen Congyang <we...@cn.fujitsu.com> >> --- >> tools/libxc/xc_resume.c | 20 ++++++++++++++++---- >> 1 file changed, 16 insertions(+), 4 deletions(-) >> >> diff --git a/tools/libxc/xc_resume.c b/tools/libxc/xc_resume.c >> index e67bebd..b862ce3 100644 >> --- a/tools/libxc/xc_resume.c >> +++ b/tools/libxc/xc_resume.c >> @@ -109,6 +109,21 @@ static int xc_domain_resume_cooperative(xc_interface >> *xch, uint32_t domid) >> return do_domctl(xch, &domctl); >> } >> >> +static int xc_domain_resume_hvm(xc_interface *xch, uint32_t domid) >> +{ >> + DECLARE_DOMCTL; >> + >> + /* >> + * If it is PVHVM, the hypercall return code is 0, and resume >> + * it in a new domain context. > > What is a "new domain context"?
Hmm, this patch is written some years ago. IIRC, we suspend PVHVM and resume it is like this: 1. suspend it via evtchn 2. modifty the return code to 1 3. the guest know that the suspend is cancelled, we will use fast path to resume it. But we may update the guest's state(modify memory, cpu's registers, device status...). In this case, we cannot use the fast path to resume it. Keep the return code 0, and use a very slow path to resume the guest. We have updated the guest state, so I call it a new domain context... > >> + * >> + * If it is a HVM, do nothing. > > If it is an HVM guest they you do something, you call a hypercall. > > If that hypercall is somehow a NOP for an HVM domain then I think that > needs to be explained somewhere here. Hmm, IIRC, it is a NOP. For HVM, we only need that xc_domain_resume() doesn't fail. Thanks Wen Congyang > > > > . > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel