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

Re: [Xen-devel] Interrupt injection with ISR set on Intel hardware



btw can you also capture ISR/IRR/PPR right before local_irq_enable()?
though I didn't see a reason why code in-between may impact those 
bits, it doesn't hurt to capture the context right before interrupt is
raised. :-)

> -----Original Message-----
> From: Tian, Kevin
> Sent: Thursday, December 13, 2018 9:28 AM
> To: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx; Wei Liu <wei.liu2@xxxxxxxxxx>; Jan
> Beulich <JBeulich@xxxxxxxx>; Andrew Cooper
> <andrew.cooper3@xxxxxxxxxx>; Nakajima, Jun <jun.nakajima@xxxxxxxxx>
> Subject: RE: Interrupt injection with ISR set on Intel hardware
> 
> > From: Roger Pau Monné [mailto:roger.pau@xxxxxxxxxx]
> > Sent: Wednesday, December 12, 2018 8:18 PM
> >
> > On Wed, Dec 12, 2018 at 11:48:52AM +0000, Tian, Kevin wrote:
> > > > From: Roger Pau Monné [mailto:roger.pau@xxxxxxxxxx]
> > > > Sent: Wednesday, December 12, 2018 7:25 PM
> > > >
> > > > On Wed, Dec 12, 2018 at 10:36:44AM +0000, Tian, Kevin wrote:
> > > > > > From: Roger Pau Monné [mailto:roger.pau@xxxxxxxxxx]
> > > > > > Sent: Monday, October 15, 2018 6:30 PM
> > > > > > (XEN)   [22642] POWER    TYPE 4
> > > > > > (XEN)   [22643] IDLE     PPR 0x00000020
> > > > > > (XEN)                    IRR
> > > > > >
> > > >
> >
> 00000000000000000000000000000000000000000000000000000000000000
> > > > > > 00
> > > > > > (XEN)                    ISR
> > > > > >
> > > >
> >
> 00000000020000000000000000000000000000000000000000000000000000
> > > > > > 00
> > > > > > (XEN)   [22644] WAKE     PPR 0x00000020
> > > > > > (XEN)                    IRR
> > > > > >
> > > >
> >
> 00000000020000000000000000000000000000000000000000000000000000
> > > > > > 00
> > > > > > (XEN)                    ISR
> > > > > >
> > > >
> >
> 00000000020000000000000000000000000000000000000000000000000000
> > > > > > 00
> > > > >
> > > > > looks pending IRR (0x21) doesn't always trigger a spurious interrupt?
> > > >
> > > > Yes, that's correct. Having a pending IRR and going idle doesn't
> > > > always trigger the spurious interrupt re-injection.
> > > >
> > > > > is it a fixed pattern after how many rounds of Cstate enter/exit with
> > > > > pending IRR(0x21) then you see assertion happened (in this example
> > > > > it happens at 3rd time)?
> > > >
> > > > It's not a fixed pattern, here's another trace with IRR(0x21) being
> > > > pending just once during the Cstate transitions:
> > >
> > > did you observe a case where such asset may occur when IRR(0x21)
> > > is cleared but ISR (0x21) is set?
> >
> > No, I've always seen both ISR and IRR set when the interrupt injection
> > happens. This of course doesn't mean it's not possible, but I have not
> > seen any trace with ISR(0x21) set and IRR(0x21) clear.
> >
> 
> sorry but let me double confirm. You always see ISR[21]/IRR[21] being
> set "before and after entering C3" to hit the problem, right? When
> interrupt injection happens later, ISR[21] is set but IRR[21] is cleared (as
> expected for normal interrupt delivery process).
> 
> btw I checked your original mail:
> 
> (XEN)    [<ffff82d0802e2403>] mwait-idle.c#mwait_idle+0x2a5/0x381
> xen/arch/x86/cpu/mwait-idle.c:802
> 
>    788                if (cpu_is_haltable(cpu))
>    789                        mwait_idle_with_hints(eax,
> MWAIT_ECX_INTERRUPT_BREAK);
>    790
>    791                after = cpuidle_get_tick();
>    792
>    793                cstate_restore_tsc();
>    794                trace_exit_reason(irq_traced);
>    795                TRACE_6D(TRC_PM_IDLE_EXIT, cx->type, after,
>    796                        irq_traced[0], irq_traced[1], irq_traced[2],
> irq_traced[3]);
>    797
>    798                /* Now back in C0. */
>    799                update_idle_stats(power, cx, before, after);
>    800                local_irq_enable();
>    801
> -> 802                if (!(lapic_timer_reliable_states & (1 << cstate)))
>    803                        lapic_timer_on();
>    804
>    805                sched_tick_resume();
>    806                cpufreq_dbs_timer_resume();
> 
> Looks above code is different from staging:
> 
> acpi_processor_idle:
>       acpi_idle_do_entry:
>               acpi_processor_ffh_cstate_enter:
>                       mwait_idle_with_hints
> 
> there is no mwait_idle alone. and even with compiler optimization I didn't
> find code sequence like above...
> 
> Thanks
> Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

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