Dear all
I saw a change about NMI handling in C/S 20059. So could anyone
tell me what''s the difference of these two ways? We found that after
changing to ''self_nmi()'', xenoprofile cannot work correctly.
Since ''self_nmi()'' issue a hypervisor nmi and there is no
change for xenoprofile to record HVM guest regs information.
--- a/xen/arch/x86/hvm/vmx/vmx.c Fri Aug 14 10:57:24 2009 +0100
+++ b/xen/arch/x86/hvm/vmx/vmx.c Fri Aug 14 10:58:32 2009 +0100
@@ -945,8 +945,6 @@ static void vmx_enable_rdtsc_exiting(str
vmx_vmcs_exit(v);
}
-void do_nmi(struct cpu_user_regs *);
-
static void vmx_init_hypercall_page(struct domain *d, void *hypercall_page)
{
char *p;
@@ -2470,7 +2468,7 @@ asmlinkage void vmx_vmexit_handler(struc
(X86_EVENTTYPE_NMI << 8) )
goto exit_and_crash;
HVMTRACE_0D(NMI);
- do_nmi(regs); /* Real NMI, vector 2: normal processing. */
+ self_nmi(); /* Real NMI, vector 2: normal processing. */
break;
case TRAP_machine_check:
HVMTRACE_0D(MCE);
Best regards!
Lv,hui
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Change needed to avoid getting a real NMI while handling the fake NMI created by calling do_nmi() directly. It''s a very valid fix. You''ll have to fix this subsequent issue by having a per-cpu bool_t exposed from self_nmi(): ... this_cpu(is_self_nmi) = 1; apic_icr_write(APIC_DM_NMI...); this_cpu(is_self_nmi) = 0; ... You can check that flag from your NMI handler and if set, and current vcpu is non-idle, you can go at guest_cpu_user_regs() to get the appropriate cpu context for profiling. You could even do that check in the generic NMI handler/dispatcher, and change the regs pointer you pass to the currently registered specific NMI handler. -- Keir On 31/12/2010 01:37, "Lv, Hui" <hui.lv@intel.com> wrote:> Dear all > I saw a change about NMI handling in C/S 20059. So could > anyone tell me what¹s the difference of these two ways? We found that after > changing to self_nmi()¹, xenoprofile cannot work correctly. Since > self_nmi()¹ issue a hypervisor nmi and there is no change for xenoprofile to > record HVM guest regs information. > --- a/xen/arch/x86/hvm/vmx/vmx.c Fri Aug 14 10:57:24 2009 +0100 > +++ b/xen/arch/x86/hvm/vmx/vmx.c Fri Aug 14 10:58:32 2009 +0100 > @@ -945,8 +945,6 @@ static void vmx_enable_rdtsc_exiting(str > vmx_vmcs_exit(v); > } > > -void do_nmi(struct cpu_user_regs *); > - > static void vmx_init_hypercall_page(struct domain *d, void *hypercall_page) > { > char *p; > @@ -2470,7 +2468,7 @@ asmlinkage void vmx_vmexit_handler(struc > (X86_EVENTTYPE_NMI << 8) ) > goto exit_and_crash; > HVMTRACE_0D(NMI); > - do_nmi(regs); /* Real NMI, vector 2: normal processing. */ > + self_nmi(); /* Real NMI, vector 2: normal processing. */ > break; > case TRAP_machine_check: > HVMTRACE_0D(MCE); > > > Best regards! > Lv,hui > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Thanks, it''s very clear. I''ll try to fix it. Best regards, Lv, Hui -----Original Message----- From: Keir Fraser [mailto:keir.xen@gmail.com] On Behalf Of Keir Fraser Sent: Friday, December 31, 2010 5:01 PM To: Lv, Hui; xen-devel@lists.xensource.com Subject: Re: [Xen-devel] NMI handling in HVM Change needed to avoid getting a real NMI while handling the fake NMI created by calling do_nmi() directly. It''s a very valid fix. You''ll have to fix this subsequent issue by having a per-cpu bool_t exposed from self_nmi(): ... this_cpu(is_self_nmi) = 1; apic_icr_write(APIC_DM_NMI...); this_cpu(is_self_nmi) = 0; ... You can check that flag from your NMI handler and if set, and current vcpu is non-idle, you can go at guest_cpu_user_regs() to get the appropriate cpu context for profiling. You could even do that check in the generic NMI handler/dispatcher, and change the regs pointer you pass to the currently registered specific NMI handler. -- Keir On 31/12/2010 01:37, "Lv, Hui" <hui.lv@intel.com> wrote:> Dear all > I saw a change about NMI handling in C/S 20059. So could > anyone tell me what¹s the difference of these two ways? We found that after > changing to Œself_nmi()¹, xenoprofile cannot work correctly. Since > Œself_nmi()¹ issue a hypervisor nmi and there is no change for xenoprofile to > record HVM guest regs information. > --- a/xen/arch/x86/hvm/vmx/vmx.c Fri Aug 14 10:57:24 2009 +0100 > +++ b/xen/arch/x86/hvm/vmx/vmx.c Fri Aug 14 10:58:32 2009 +0100 > @@ -945,8 +945,6 @@ static void vmx_enable_rdtsc_exiting(str > vmx_vmcs_exit(v); > } > > -void do_nmi(struct cpu_user_regs *); > - > static void vmx_init_hypercall_page(struct domain *d, void *hypercall_page) > { > char *p; > @@ -2470,7 +2468,7 @@ asmlinkage void vmx_vmexit_handler(struc > (X86_EVENTTYPE_NMI << 8) ) > goto exit_and_crash; > HVMTRACE_0D(NMI); > - do_nmi(regs); /* Real NMI, vector 2: normal processing. */ > + self_nmi(); /* Real NMI, vector 2: normal processing. */ > break; > case TRAP_machine_check: > HVMTRACE_0D(MCE); > > > Best regards! > Lv,hui > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel