[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [RFC Patch 24/25] fix vm entry fail



At 07/24/2014 06:40 PM, Tim Deegan Write:
> Hi,
> 
> At 19:39 +0800 on 18 Jul (1405708749), Wen Congyang 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>
> 
> This looks correct but incomplete -- we should also clear this state for
> the other cases where we don't explicitly set it.  I've done this
> below, and also copied the fix to the equivalent SVM code.  Can you
> test that it works for you?

Sorry for later reply.

COLO for upstream is not finished, and I cannot reproduce this bug.
So, I use old version colo(based on xen 4.1), and test this patch.
I works for me.

Thanks for your help
Wen Congyang

> 
> Cheers,
> 
> Tim.
> 
> commit c9e81a06c02ffc45594798616409335fc09cd32f
> Author: Wen Congyang <wency@xxxxxxxxxxxxxx>
> Date:   Fri Jul 18 19:39:09 2014 +0800
> 
>     x86/hvm: Always set pending event injection when loading VMC[BS] state.
>     
>     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>
> 
> diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
> index 76616ac..6551b38 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 2caa04a..cfc4801 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;
>  }
> .
> 


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.