Re: [PATCH v4 --for 4.6 COLOPre 11/25] tools/libxc: support to resume uncooperative HVM guests

[Wen Congyang <wency@cn.fujitsu.com>]

On 07/17/2015 12:27 AM, Ian Jackson wrote:
> Yang Hongyang writes ("Re: [Xen-devel] [PATCH v4 --for 4.6 COLOPre 11/25] tools/libxc: support to resume uncooperative HVM guests"):
>> On 07/16/2015 11:40 PM, Ian Jackson wrote:
>>>    what this patch is doing
>>>
>>>      That is, what the change in behaviour is.  This includes clearly
>>>      distinguishing old behaviour, before the patch, from new
>>>      behaviour, after the patch.  I appreciate that there may be
>>>      language problems which are making this more difficult - I think
>>>      your native language may not use tenses the way English does.  So
>>>      we can help you with the language, but we need the old and new
>>>      behaviours to be clearly marked in your message.
>>
>> I thought this is being addressed in the commit message, sorry again
>> for my poor English and not make it clear, I would appreciate your
>> help.
> 
> Right.  Thanks.  I hope we can work on this together.  I appreciate
> that working in a non-native language is difficult.
> 
> OK, at the moment I find the existing proposed commit message unclear
> about before-and-after.  I'm not sure I can write it correctly.  Can I
> make a suggestion ?  How about you send me a copy of it with
> the different parts explicitly marked BEFORE: and AFTER: ?
> 
>>>    what the constraints on the new functionality will be.
>>>
>>>      It appears that you are supporting slow path resume for all HVM
>>>      guests.  Is that true ?  Are there any cases left unhandled ?
>>
>> For the first question, yes. For second, Sorry that I don't catch
>> your question, did you mean in some cases resuming HVM through slow
>> path will be unhandled?
> 
> What I mean is: I think that this patch has this overall effect:
> 
>    BEFORE: HVM resume for slow path does not work
> 
>    AFTER: HVM resume for slow path does work
> 
> But I have questions.  I don't know in what way it "does not work".
> What happens instead ?

Sorry for the late reply.
BEFORE: HVM resume for slow path does not work. You will get the following
error message:
"Cannot resume uncooperative HVM guests"

Fast resume: the guest status is not changed, so there is no need to disconnect and
reconnect the backend and frontend pv driver.

Slow path resume: the guest status is changed, so we must disconnect and reconnect
the backend and frontend pv driver. When we reconnect the backend and frontend, it
will take too many time, because xenstore is very slow. That is why it is a slow path.

In which case the slow path doesn't work? If the guest status is changed, but it is
also corrupted. I don't know what will happen in this case. I think resuming PV guest
in such state doesn't work(the behavior is undefined.)

> 
> And, another question: is it true that
> 
>    AFTER: HVM resume for slow path does work in all cases
> 
> or
> 
>    AFTER: HVM resume for slow path works in some cases (specify!)
>           but in other cases it (does something else - what?)
> 
> Does that make sense of my question ?

In my test, it works. I know I cannot say it does work in all cases.
How to know if it does work in all cases?
    List all cases, and do a test for all cases.
But I think it is hard to list all cases...

How to resume domU if its state(memory, device state, cpu's register...) is changed?
Note that, the domU can be resumed.(All states are copied from another guest with the same
config).
Before this patch, we only support pv guest, and do the following thing:
1. rewrite store_mfn and console_mfn
2. reset all secondary CPU states
3. resume domain(do_domctl(xch, ...), cmd is XEN_DOMCTL_resumedomain)

Thanks
Wen Congyang

> 
> 
> Thanks,
> Ian.
> .
>