xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Wen Congyang <wency@cn.fujitsu.com>
To: Aravind Gopalakrishnan <aravind.gopalakrishnan@amd.com>,
	Jan Beulich <JBeulich@suse.com>
Cc: Tim Deegan <tim@xen.org>, Kevin Tian <kevin.tian@intel.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Jun Nakajima <jun.nakajima@intel.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Dong Eddie <eddie.dong@intel.com>,
	xen devel <xen-devel@lists.xen.org>,
	suravee.suthikulpanit@amd.com,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Yang Hongyang <yanghy@cn.fujitsu.com>,
	Lai Jiangshan <laijs@cn.fujitsu.com>
Subject: Re: [RFC Patch v2 45/45] x86/hvm: Always set pending event injection when loading VMC[BS] state.
Date: Thu, 28 Aug 2014 09:04:20 +0800	[thread overview]
Message-ID: <53FE8014.804@cn.fujitsu.com> (raw)
In-Reply-To: <53FDF200.90408@amd.com>

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@cn.fujitsu.com> 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@cn.fujitsu.com>
>>>>
>>>> Also clear pending software exceptions.
>>>> Copy the fix to SVM as well.
>>>>
>>>> Signed-off-by: Tim Deegan <tim@xen.org>
>>> 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

Before resuming secondary vm, it is the same with primary vm. Because the secondary vm
is running before step1, so VM_ENTRY_INTR_INFO may be valid before resuming
secondary vm(step3). If there is no pending event after resuming secondary vm,
and we don't clear it, vmentry will fail(I only test vmx). I don't know the behavior
in svm. This part of patch is wrote by Tim Deegan.

> 
> Is this a 'fix' we need so that we don't duplicate a pending software interrupt on the secondary VM?
> Is there a way to test this?

I don't know any other way except colo to test it.

Thanks
Wen Congyang

> 
> Thanks,
> -Aravind.
> 
>>>> ---
>>>>   xen/arch/x86/hvm/svm/svm.c | 16 +++++++++-------
>>>>   xen/arch/x86/hvm/vmx/vmx.c | 25 ++++++++++++-------------
>>>>   2 files changed, 21 insertions(+), 20 deletions(-)
>>>>
>>>> diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
>>>> index 71b8a6a..f7a0cb8 100644
>>>> --- a/xen/arch/x86/hvm/svm/svm.c
>>>> +++ b/xen/arch/x86/hvm/svm/svm.c
>>>> @@ -321,16 +321,18 @@ static int svm_vmcb_restore(struct vcpu *v, struct
>>>> hvm_hw_cpu *c)
>>>>           vmcb_set_h_cr3(vmcb, pagetable_get_paddr(p2m_get_pagetable(p2m)));
>>>>       }
>>>>   -    if ( c->pending_valid )
>>>> +    if ( c->pending_valid
>>>> +         && hvm_event_needs_reinjection(c->pending_type, c->pending_vector) )
>>>>       {
>>>>           gdprintk(XENLOG_INFO, "Re-injecting %#"PRIx32", %#"PRIx32"\n",
>>>>                    c->pending_event, c->error_code);
>>>> -
>>>> -        if ( hvm_event_needs_reinjection(c->pending_type, c->pending_vector) )
>>>> -        {
>>>> -            vmcb->eventinj.bytes = c->pending_event;
>>>> -            vmcb->eventinj.fields.errorcode = c->error_code;
>>>> -        }
>>>> +        vmcb->eventinj.bytes = c->pending_event;
>>>> +        vmcb->eventinj.fields.errorcode = c->error_code;
>>>> +    }
>>>> +    else
>>>> +    {
>>>> +        vmcb->eventinj.bytes = 0;
>>>> +        vmcb->eventinj.fields.errorcode = 0;
>>>>       }
>>>>         vmcb->cleanbits.bytes = 0;
>>>> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
>>>> index fb65c7d..5f143c0 100644
>>>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>>>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>>>> @@ -509,23 +509,22 @@ static int vmx_vmcs_restore(struct vcpu *v, struct
>>>> hvm_hw_cpu *c)
>>>>         __vmwrite(GUEST_DR7, c->dr7);
>>>>   -    vmx_vmcs_exit(v);
>>>> -
>>>> -    paging_update_paging_modes(v);
>>>> -
>>>> -    if ( c->pending_valid )
>>>> +    if ( c->pending_valid
>>>> +         && hvm_event_needs_reinjection(c->pending_type, c->pending_vector) )
>>>>       {
>>>>           gdprintk(XENLOG_INFO, "Re-injecting %#"PRIx32", %#"PRIx32"\n",
>>>>                    c->pending_event, c->error_code);
>>>> -
>>>> -        if ( hvm_event_needs_reinjection(c->pending_type, c->pending_vector) )
>>>> -        {
>>>> -            vmx_vmcs_enter(v);
>>>> -            __vmwrite(VM_ENTRY_INTR_INFO, c->pending_event);
>>>> -            __vmwrite(VM_ENTRY_EXCEPTION_ERROR_CODE, c->error_code);
>>>> -            vmx_vmcs_exit(v);
>>>> -        }
>>>> +        __vmwrite(VM_ENTRY_INTR_INFO, c->pending_event);
>>>> +        __vmwrite(VM_ENTRY_EXCEPTION_ERROR_CODE, c->error_code);
>>>>       }
>>>> +    else
>>>> +    {
>>>> +        __vmwrite(VM_ENTRY_INTR_INFO, 0);
>>>> +        __vmwrite(VM_ENTRY_EXCEPTION_ERROR_CODE, 0);
>>>> +    }
>>>> +    vmx_vmcs_exit(v);
>>>> +
>>>> +    paging_update_paging_modes(v);
>>>>         return 0;
>>>>   }
>>>> -- 
>>>> 1.9.3
>>>>
>>>>
>>>> _______________________________________________
>>>> Xen-devel mailing list
>>>> Xen-devel@lists.xen.org
>>>> http://lists.xen.org/xen-devel
>>>
>>>
>>> .
>>>
> 
> .
> 

  reply	other threads:[~2014-08-28  1:04 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-08  7:00 [RFC Patch v2 00/45] COarse-grain LOck-stepping Virtual Machines for Non-stop Service Wen Congyang
2014-08-08  7:01 ` [RFC Patch v2 01/45] copy the correct page to memory Wen Congyang
2014-08-08  7:01 ` [RFC Patch v2 02/45] csum the correct page Wen Congyang
2014-08-08  7:01 ` [RFC Patch v2 03/45] don't zero out ioreq page Wen Congyang
2014-08-08  7:01 ` [RFC Patch v2 04/45] Refactor domain_suspend_callback_common() Wen Congyang
2014-08-08  7:01 ` [RFC Patch v2 05/45] Update libxl__domain_resume() for colo Wen Congyang
2014-08-08  7:01 ` [RFC Patch v2 06/45] Update libxl__domain_suspend_common_switch_qemu_logdirty() " Wen Congyang
2014-08-08  7:01 ` [RFC Patch v2 07/45] Introduce a new internal API libxl__domain_unpause() Wen Congyang
2014-08-08  7:01 ` [RFC Patch v2 08/45] Update libxl__domain_unpause() to support qemu-xen Wen Congyang
2014-08-08  7:01 ` [RFC Patch v2 09/45] support to resume uncooperative HVM guests Wen Congyang
2014-08-08  7:01 ` [RFC Patch v2 10/45] update datecopier to support sending data only Wen Congyang
2014-08-08  7:01 ` [RFC Patch v2 11/45] introduce a new API to aync read data from fd Wen Congyang
2014-08-08  7:01 ` [RFC Patch v2 12/45] move remus related codes to libxl_remus.c Wen Congyang
2014-08-08  7:01 ` [RFC Patch v2 13/45] rename remus device to checkpoint device Wen Congyang
2014-08-08  7:01 ` [RFC Patch v2 14/45] adjust the indentation Wen Congyang
2014-08-08  7:01 ` [RFC Patch v2 15/45] don't touch remus in checkpoint_device Wen Congyang
2014-08-08  7:01 ` [RFC Patch v2 16/45] Update libxl_save_msgs_gen.pl to support return data from xl to xc Wen Congyang
2014-08-08  7:01 ` [RFC Patch v2 17/45] Allow slave sends data to master Wen Congyang
2014-08-08  7:01 ` [RFC Patch v2 18/45] secondary vm suspend/resume/checkpoint code Wen Congyang
2014-08-08  7:01 ` [RFC Patch v2 19/45] primary vm suspend/get_dirty_pfn/resume/checkpoint code Wen Congyang
2014-08-08  7:01 ` [RFC Patch v2 20/45] xc_domain_save: flush cache before calling callbacks->postcopy() in colo mode Wen Congyang
2014-08-08  7:01 ` [RFC Patch v2 21/45] COLO: xc related codes Wen Congyang
2014-08-08  7:01 ` [RFC Patch v2 22/45] send store mfn and console mfn to xl before resuming secondary vm Wen Congyang
2014-08-08  7:01 ` [RFC Patch v2 23/45] implement the cmdline for COLO Wen Congyang
2014-08-08  7:01 ` [RFC Patch v2 24/45] HACK: do checkpoint per 20ms Wen Congyang
2014-08-08  7:01 ` [RFC Patch v2 25/45] colo: dynamic allocate aio_requests to avoid -EBUSY error Wen Congyang
2014-08-08  7:01 ` [RFC Patch v2 26/45] fix memory leak in block-remus Wen Congyang
2014-08-08  7:01 ` [RFC Patch v2 27/45] pass uuid to the callback td_open Wen Congyang
2014-08-08  7:01 ` [RFC Patch v2 28/45] return the correct dev path Wen Congyang
2014-08-08  7:01 ` [RFC Patch v2 29/45] blktap2: use correct way to get remus_image Wen Congyang
2014-08-08  7:01 ` [RFC Patch v2 30/45] don't call client_flush() when switching to unprotected mode Wen Congyang
2014-08-08  7:01 ` [RFC Patch v2 31/45] remus: fix bug in tdremus_close() Wen Congyang
2014-08-08  7:01 ` [RFC Patch v2 32/45] blktap2: use correct way to get free event id Wen Congyang
2014-08-08  7:01 ` [RFC Patch v2 33/45] blktap2: don't return negative " Wen Congyang
2014-08-08  7:01 ` [RFC Patch v2 34/45] blktap2: use correct way to define array Wen Congyang
2014-08-08  7:01 ` [RFC Patch v2 35/45] blktap2: connect to backup asynchronously Wen Congyang
2014-08-08  7:01 ` [RFC Patch v2 36/45] switch to unprotected mode before closing Wen Congyang
2014-08-08  7:01 ` [RFC Patch v2 37/45] blktap2: move async connect related codes to block-replication.c Wen Congyang
2014-08-08  7:01 ` [RFC Patch v2 38/45] blktap2: move ramdisk " Wen Congyang
2014-08-08  7:01 ` [RFC Patch v2 39/45] block-colo: implement colo disk replication Wen Congyang
2014-08-08  7:01 ` [RFC Patch v2 40/45] pass correct file to qemu if we use blktap2 Wen Congyang
2014-08-08  7:01 ` [RFC Patch v2 41/45] support blktap remus in xl Wen Congyang
2014-08-08  7:01 ` [RFC Patch v2 42/45] support blktap colo in xl: Wen Congyang
2014-08-08  7:01 ` [RFC Patch v2 43/45] update libxl__device_disk_from_xs_be() to support blktap device Wen Congyang
2014-08-08  7:01 ` [RFC Patch v2 44/45] libxl/colo: setup and control disk replication for blktap2 backends Wen Congyang
2014-08-08  7:01 ` [RFC Patch v2 45/45] x86/hvm: Always set pending event injection when loading VMC[BS] state Wen Congyang
2014-08-08  7:24   ` Jan Beulich
2014-08-08  7:29     ` Wen Congyang
2014-08-26 16:02   ` Jan Beulich
2014-08-27  0:46     ` Wen Congyang
2014-08-27 14:58       ` Aravind Gopalakrishnan
2014-08-28  1:04         ` Wen Congyang [this message]
2014-08-28  8:54           ` Andrew Cooper
2014-08-28 11:17             ` Wen Congyang
2014-08-28 11:31               ` Paul Durrant
2014-08-29  5:59                 ` Wen Congyang
2014-08-28  9:53         ` Tim Deegan
2014-08-27 23:24     ` Tian, Kevin
2014-08-27 15:02   ` Andrew Cooper
2014-08-08  7:01 ` [RFC Patch v2 46/45] Introduce "xen-load-devices-state" Wen Congyang
2014-08-08  7:19 ` [RFC Patch v2 00/45] COarse-grain LOck-stepping Virtual Machines for Non-stop Service Jan Beulich
2014-08-08  7:39   ` Wen Congyang
2014-08-08  8:21   ` Wen Congyang
2014-08-08  9:02     ` Jan Beulich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53FE8014.804@cn.fujitsu.com \
    --to=wency@cn.fujitsu.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=JBeulich@suse.com \
    --cc=aravind.gopalakrishnan@amd.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=eddie.dong@intel.com \
    --cc=jun.nakajima@intel.com \
    --cc=kevin.tian@intel.com \
    --cc=laijs@cn.fujitsu.com \
    --cc=suravee.suthikulpanit@amd.com \
    --cc=tim@xen.org \
    --cc=xen-devel@lists.xen.org \
    --cc=yanghy@cn.fujitsu.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).