Re: [Xen-devel] [RFC Patch v2 45/45] x86/hvm: Always set pending event injection when loading VMC[BS] state.

[Wen Congyang <wency@xxxxxxxxxxxxxx>]

At 08/28/2014 07:31 PM, Paul Durrant Write:
>> -----Original Message-----
>> From: xen-devel-bounces@xxxxxxxxxxxxx [mailto:xen-devel-
>> bounces@xxxxxxxxxxxxx] On Behalf Of Wen Congyang
>> Sent: 28 August 2014 12:18
>> To: Andrew Cooper; Aravind Gopalakrishnan; Jan Beulich
>> Cc: Kevin Tian; Yang Hongyang; Ian Campbell; Eddie Dong; Ian Jackson; Tim
>> (Xen.org); Jun Nakajima; Boris Ostrovsky; xen devel;
>> suravee.suthikulpanit@xxxxxxx; Lai Jiangshan
>> Subject: Re: [Xen-devel] [RFC Patch v2 45/45] x86/hvm: Always set pending
>> event injection when loading VMC[BS] state.
>>
>> At 08/28/2014 04:54 PM, Andrew Cooper Write:
>>> On 28/08/14 02:04, Wen Congyang wrote:
>>>> At 08/27/2014 10:58 PM, Aravind Gopalakrishnan Write:
>>>>> On 8/26/2014 7:46 PM, Wen Congyang wrote:
>>>>>> At 08/27/2014 12:02 AM, Jan Beulich Write:
>>>>>>>>>> On 08.08.14 at 09:01, <wency@xxxxxxxxxxxxxx> wrote:
>>>>>>>> In colo mode, secondary vm is running, so VM_ENTRY_INTR_INFO
>> may
>>>>>>>> valid before restoring vmcs. If there is no pending event after
>>>>>>>> restoring vm, we should clear it.
>>>>>>>>
>>>>>>>> Signed-off-by: Wen Congyang <wency@xxxxxxxxxxxxxx>
>>>>>>>>
>>>>>>>> Also clear pending software exceptions.
>>>>>>>> Copy the fix to SVM as well.
>>>>>>>>
>>>>>>>> Signed-off-by: Tim Deegan <tim@xxxxxxx>
>>>>>>> I only now realized that it's no surprise we're not getting acks from
>>>>>>> the VMX maintainers on this - the majority of them wasn't Cc-ed.
>>>>>>> Now done, but please take care to do so yourself in the future.
>>>>>>>
>>>>>>> As to the SVM maintainers - Ping (I Cc-ed you on an earlier reply)?
>>>>>> Thanks for doing this.
>>>>>> I have repost it in the bugfix patchset, and cc vmx and svm maintainers
>>>>>>
>>>>> Hi,
>>>>> Apologies for the delay.
>>>>>
>>>>> As for the svm changes, the patch seems fairly straightforward and
>> harmless.
>>>>> However, I am not familiar with 'colo mode', so I'm not sure I understand
>> the problem..
>>>> In colo mode, secondary vm runs like this:
>>>> 1. suspend
>>>> 2. update the vm's state(All state is transfered from primary)
>>>> 3. resume
>>>
>>> Is this accurate?  From previous review, I seem to remember that you are
>>> pausing the vm, not suspending it, which is where all of these event
>>> issues derive from.
>>
>> Not pause. We suspend the guest(not save the state). Pausing vm meant
>> that
>> the vm is not running, but the state cannot be updated. For example, if the
>> vm uses pvdriver(not supported now), the backend and frontend share
>> some
>> information, and we only update frontend(backend state is not transfered
>> from primary dom0)...
>>
> 
> If you're doing suspend/resume then PV drivers should re-attached to backends 
> anyway so any state you did transfer would be somewhat pointless. Because of 
> the re-attach though, resume is a pretty heavyweight operation. Is that 
> really what you are doing?

Yes, so I need to do more things to support pvm and pvhvm.

Thanks
Wen Congyang

> 
>   Paul
> 
> 
>> Thanks
>> Wen Congyang
>>
>>>
>>> ~Andrew
>>> .
>>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@xxxxxxxxxxxxx
>> http://lists.xen.org/xen-devel
> .
> 


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