WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: [PATCH] Don't enable irq for machine check vmexit

To: "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>, Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>
Subject: [Xen-devel] Re: [PATCH] Don't enable irq for machine check vmexit
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Mon, 01 Feb 2010 11:14:01 +0000
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 01 Feb 2010 03:14:25 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C8EDE645B81E5141A8C6B2F73FD9265118FE9F18AB@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcqjG0NgR06msHUYT3O/DETEqfsfPgABCCMAAAQRARA=
Thread-topic: [PATCH] Don't enable irq for machine check vmexit
User-agent: Microsoft-Entourage/12.23.0.091001
Take a look at changeset 18658: local_irq_enable() was made unconditional in
the vmexit handler function for a good reason!

If you make it conditional on !mce, then in the mce case you can crash in
any later function that acquires a spinlock: maybe_deassert_evtchn_irq(),
for example. You will crash because of taking a irq-unsafe spinlock with
irqs disabled. Kind of the opposite way round to the mce_logout_lock: so
your patch would fix acquisition of that lock but break others.

I'm afraid your only option is to hoist all the mce handling up to the same
place we handle extints. Take c/s 18658 as your template for what to do.

 -- Keir

On 01/02/2010 09:18, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx> wrote:

> Sorry forgot the patch.
> 
> --jyh
> 
> diff -r 857d7b2dd8c7 xen/arch/x86/hvm/vmx/vmx.c
> --- a/xen/arch/x86/hvm/vmx/vmx.c Fri Jan 29 08:59:46 2010 +0000
> +++ b/xen/arch/x86/hvm/vmx/vmx.c Sun Jan 31 18:40:34 2010 +0800
> @@ -2153,6 +2153,7 @@ static void vmx_failed_vmentry(unsigned
>          printk("caused by machine check.\n");
>          HVMTRACE_0D(MCE);
>          do_machine_check(regs);
> +        local_irq_enable();
>          break;
>      default:
>          printk("reason not known yet!");
> @@ -2243,6 +2244,23 @@ err:
>  err:
>      vmx_inject_hw_exception(TRAP_gp_fault, 0);
>      return -1;
> +}
> +
> +int vmx_mce_exit(int exit_reason)
> +{
> +    if ( unlikely(exit_reason & VMX_EXIT_REASONS_FAILED_VMENTRY &&
> +        (uint16_t)exit_reason == EXIT_REASON_MCE_DURING_VMENTRY) )
> +            return 1;
> +    else if (unlikely(exit_reason == EXIT_REASON_EXCEPTION_NMI))
> +    {
> +        uint32_t vector;
> +
> +        vector = __vmread(VM_EXIT_INTR_INFO) & INTR_INFO_VECTOR_MASK;
> +        if (vector == TRAP_machine_check)
> +            return 1;
> +    }
> +
> +    return 0;
>  }
>  
>  asmlinkage void vmx_vmexit_handler(struct cpu_user_regs *regs)
> @@ -2273,7 +2291,8 @@ asmlinkage void vmx_vmexit_handler(struc
>          vmx_do_extint(regs);
>  
>      /* Now enable interrupts so it's safe to take locks. */
> -    local_irq_enable();
> +    if ( !(vmx_mce_exit(exit_reason)) )
> +        local_irq_enable();
>  
>      if ( unlikely(exit_reason & VMX_EXIT_REASONS_FAILED_VMENTRY) )
>          return vmx_failed_vmentry(exit_reason, regs);
> @@ -2433,6 +2452,7 @@ asmlinkage void vmx_vmexit_handler(struc
>          case TRAP_machine_check:
>              HVMTRACE_0D(MCE);
>              do_machine_check(regs);
> +            local_irq_enable();
>              break;
>          case TRAP_invalid_op:
>              vmx_vmexit_ud_intercept(regs);
> 
> 
> 
>> -----Original Message-----
>> From: Jiang, Yunhong
>> Sent: Monday, February 01, 2010 4:48 PM
>> To: Keir Fraser; Tim.Deegan@xxxxxxxxxx
>> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
>> Subject: [PATCH] Don't enable irq for machine check vmexit
>> 
>> We should not enable irq for machine check VMExit
>> 
>> In changeset 18658:824892134573, IRQ is enabled during VMExit except external
>> interrupt. The exception should apply for machine check also, because :
>> a) The mce_logout_lock should be held in irq_disabled context.
>> b) The machine check event should be handled as quickly as possible, enable
>> irq will
>> increase the period greatly.
>> 
>> Signed-off-by: Jiang, Yunhong <yunhong.jiang@xxxxxxxxx>
>> 
>> This is in hotspot code path, I try to use unlikely, hope to reduce the
>> performance
>> impact
>> 
>> Thanks
>> Yunhong Jiang
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel