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

[Julien Grall <julien.grall@xxxxxxx>]

Hi,

On 24/01/17 13:40, Dario Faggioli wrote:
> On Tue, 2017-01-24 at 13:24 +0000, Julien Grall wrote:
> > On 24/01/17 13:19, Dario Faggioli wrote:
> > > How are Dom0 vCPUs pinned, exclusively (i.e., there are 2 pCPUs on
> > > which _only_ Dom0 and _no_ DomU can run)?
> > I have dom0_vcpu_pins on Xen command line option (so I guess only
> > pinned?), no further configuration for DOM0.
> Ok, thanks. Yeah, that means Dom0 vCPU 0 is pinned to pCPU 0, and vCPU
> 1 is pinned to pCPU 1. And it's not excluside, i.e., other domains can
> run on pCPUs 0 and 1, if the scheduler decides so (because they're
> free, because the scheduler decides to preempt Dom0, etc).
>
> This is of course fine, I just wanted to make sure I was understanding
> the setup.
>
> > > So, when you say "no interrupt traffic", do you perhaps mean that
> > > SCHEDULE_SOFTIRQ is rarely (never!) raised for idle pCPUs? Or are
> > > you
> > > really talking about actual interrupts (either inter-processor or
> > > not)?
> > I am talking about actual physical interrupts. The traffic is reduced
> > to
> > none with credit2 on idle pCPU.
> Ah, wow... And how --forgive my naiveness-- do you measure / check
> that?
I added a print in the interrupt path (gic_interrupt for ARM) to dump 
the interrupt number. This needs to be restrict to CPU2 and above to 
avoid been flooded:
if ( smp_processor_id() > 1 )
  printk("%s: CPU%u IRQ%u\n", __FUNCTION__, smp_processor_id(), irq);

I also added a print in the idle loop before and after the idling 
instruction (wfi for ARM, pm_idle for x86 I think). You can see the CPU 
to go in idle mode but never coming back.
Cheers,

--
Julien Grall

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