Re: [Qemu-devel] [kvm-devel] [PATCH v2] kvm-ppc: halt secondary cpus when guest reset

[Alexander Graf]

On 10.01.2012, at 18:52, Jan Kiszka wrote:

> On 2012-01-10 18:43, Scott Wood wrote:
>> On 01/10/2012 03:38 AM, Jan Kiszka wrote:
>>> On 2012-01-10 00:17, Scott Wood wrote:
>>>> On 01/09/2012 04:39 PM, Alexander Graf wrote:
>>>>> 
>>>>> On 09.01.2012, at 22:23, Scott Wood wrote:
>>>>>> Alex, is there a better way to deal with the IRQ chip issue?
>>>>> 
>>>>> To be honest, I'm not sure what the issue really is.
>>>> 
>>>> If irqchip is enabled, env->halted won't result in a CPU being
>>>> considered idle -- since QEMU won't see the interrupt that wakes the
>>>> vcpu, and the idling is handled in the kernel.  In this case we're
>>>> waiting for MMIO rather than an interrupt, and it's the kernel that
>>>> doesn't know what's going on.
>>>> 
>>>> It seems wrong to use env->stopped, though, as a spin-table release
>>>> should not override a user's explicit request to stop a CPU.  It might
>>>> be OK (though a bit ugly) if the only usage of env->stopped is through
>>>> pause_all_vcpus(), and the boot thread is the first one to be kicked
>>>> (though in theory the boot cpu could wake another cpu, and that could
>>>> wake a cpu that comes before it, causing a race with pause_all_vcpus()).
>>>> 
>>>> If it is OK to use env->stopped, is there any reason not to always use
>>>> it (versus just with irqchip)?
>>> 
>>> Why don't you wait in the kernel with in-kernel irqchip under all
>>> condition (except pausing VCPUs, of course) on PPC? Just like x86 does.
>> 
>> We do for normal idling.  This is a bit different, in that we're not
>> waiting for an interrupt, but for an MMIO that releases the cpu at
>> boot-time.
> 
> Where is the state stored that declares a VCPU to wait for that event?
> Where is it set, where removed?

It's set in the reset callback of the vcpu in QEMU. Basically we're starting 
all secondary CPUs in "waiting for an MMIO to come" state to not waste CPU 
cycles. On real hardware, secondaries are running in a tight loop trying to 
check if they should wake up.

When the primary is good to go, it will then flip a bit in MMIO space (on real 
hardware this is just RAM) which gives us an event to wake up a secondary.

> What about implementing MP_STATE on PPC, at least those states that make
> sense? Don't you need that anyway for normal HALT<->RUNNABLE transitions?

The in-kernel code isn't upstream yet, so we're free to change things still. 
But yes, I guess doing it the same way as x86 does make sense here.


Alex