Re: [Xen-devel] xen/arm: Domain not fully destroyed when using credit2

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

On Tue, 2017-01-24 at 15:06 +0000, Julien Grall wrote:
> On 24/01/17 14:16, Dario Faggioli wrote:
> > There, we have tracing (BTW, did that made it to ARM eventually?)
> > and
> > there's TRC_PM_IDLE_ENTRY/EXIT which do pretty much the same of
> > your
> > printk-s.
> 
> There is patch on the ML for xentrace support (see [1]) but nothing
> has 
> been upstreamed yet. Waiting for a new version from the contributor.
> 
Yep, that was I was remembering, and referring to. Thanks for the
update.

> > And if I look at it, I do see even totally idle (from the scheduler
> > point of view) pCPUs, I indeed see them going back and forth from
> > and
> > to C3.
> 
> My knowledge on x86 is limited. When does a CPU decides to leave the 
> idle mode?
> 
I'm not an expert of that part either. Jan and Andrew for sure know
best how monitor/mwait works (both in general, and our own
implementation).

What I know (and can quickly infer from glancing at the code), is that
timers are certainly involved.

In fact, we wake up when the most imminent timer would expire (see
mwait_idle_with_hints()), and a timer set by the scheduler fully
qualifies as being the one (if it's the most imminent).

My point was that, still from scheduling perspective, neither Credit1
nor Credit2 sets a wakeup timer for idle pCPUs.

Well, in Credit1, the master_ticker timer is never stopped (while,
e.g., the per-pCPU tick is stopped before entering deep sleep,
via sched_tick_suspend(), see commit 964fae8ac), but that's only 1
pCPU.

> In the case of ARM, the wfi instruction will put the CPU in idle
> mode 
> until an interrupt is received.
> 
Just looking up references for MWAIT, I've found this:
(http://x86.renejeschke.de/html/file_module_x86_id_215.html)

"A store to the address range armed by the MONITOR instruction, an
interrupt, an NMI or SMI, a debug exception, a machine check exception,
the BINIT# signal, the INIT# signal, or the RESET# signal will exit the
implementation-dependent-optimized state. Note that an interrupt will
cause the processor to exit only if the state was entered with
interrupts enabled."

So, yeah, interrupt, as expectable, wakes x86 up.

Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

Attachment: signature.asc
Description: This is a digitally signed message part

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