Re: xen/arm: Domain not fully destroyed when using credit2

[Julien Grall <julien.grall@arm.com>]

On 24/01/17 13:19, Dario Faggioli wrote:
> On Tue, 2017-01-24 at 13:04 +0000, Julien Grall wrote:
>> On 24/01/17 12:53, Dario Faggioli wrote:
>>> Do you have a script and/or some more info for letting me try to
>>> reproduce it (e.g., you say some otf the vCPUs are pinned, which
>>> one?
>>> etc)?
>>
>> That was mentioned in my first e-mail :). My configuration is:
>> 	- ARM platform with 6 cores
>> 	- staging Xen with credit2 enabled by default
>> 	- DOM0 using 2 pinned vCPUs
>> 	- Guest using 2 vCPUs (not pinned)
>>
> Yeah, but some of the details were either missing, or not clear to
> me... Sorry for bothering and thanks for re-stating this here. :-)
>
> 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.

>
>> The script is really simple:
>>
>> for i in `seq 1 10`; do
>> 	sudo xl create ~/works/guest/guest.cfg;
>> 	sudo xl destroy guest;
>> done
>>
> Ok.
>
>>> I'm a bit curious about why you're saying this is being exposed by
>>> using Credit2.
>>
>> It is been exposed by Credit2 because compared to Credit1 there is
>> no
>> interrupt traffic made by the scheduler.
>>
> 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.

Cheers,

-- 
Julien Grall

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