xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Keir Fraser <keir.fraser@eu.citrix.com>
To: "Jiang, Yunhong" <yunhong.jiang@intel.com>,
	Tim Deegan <Tim.Deegan@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [PATCH] Don't enable irq for machine check vmexit
Date: Thu, 04 Feb 2010 10:03:41 +0000	[thread overview]
Message-ID: <C7904BFD.8FC6%keir.fraser@eu.citrix.com> (raw)
In-Reply-To: <C8EDE645B81E5141A8C6B2F73FD9265118FECE64A0@shzsmsx501.ccr.corp.intel.com>

Yeah, I already replied to you on Monday. What I said was:

"""
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 04/02/2010 09:26, "Jiang, Yunhong" <yunhong.jiang@intel.com> wrote:

> Keir, any comments to this patch?
> 
> Thanks
> Yunhong Jiang
> 
>> -----Original Message-----
>> From: Jiang, Yunhong
>> Sent: Monday, February 01, 2010 5:18 PM
>> To: Jiang, Yunhong; Keir Fraser; Tim.Deegan@citrix.com
>> Cc: xen-devel@lists.xensource.com
>> Subject: RE: [PATCH] Don't enable irq for machine check vmexit
>> 
>> 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@citrix.com
>>> Cc: xen-devel@lists.xensource.com
>>> 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@intel.com>
>>> 
>>> This is in hotspot code path, I try to use unlikely, hope to reduce the
>>> performance
>>> impact
>>> 
>>> Thanks
>>> Yunhong Jiang
> 

  reply	other threads:[~2010-02-04 10:03 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-01  9:18 [PATCH] Don't enable irq for machine check vmexit Jiang, Yunhong
2010-02-01 11:14 ` Keir Fraser
2010-02-04  9:26 ` Jiang, Yunhong
2010-02-04 10:03   ` Keir Fraser [this message]
2010-02-04 12:25     ` Jiang, Yunhong
2010-02-04 14:21       ` Tim Deegan
2010-02-04 14:35         ` Jiang, Yunhong
2010-02-05 10:22         ` Jiang, Yunhong
2010-02-05 10:42           ` Tim Deegan
2010-02-05 14:37             ` Jiang, Yunhong
2010-02-05 12:53           ` Keir Fraser
2010-02-05 14:36             ` Jiang, Yunhong
2010-02-05 14:59               ` Keir Fraser
2010-02-07  4:25                 ` Jiang, Yunhong
  -- strict thread matches above, loose matches on Subject: below --
2010-02-01  8:48 Jiang, Yunhong

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=C7904BFD.8FC6%keir.fraser@eu.citrix.com \
    --to=keir.fraser@eu.citrix.com \
    --cc=Tim.Deegan@eu.citrix.com \
    --cc=xen-devel@lists.xensource.com \
    --cc=yunhong.jiang@intel.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).