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

[Alexander Graf]

On 10.01.2012, at 23:43, Scott Wood wrote:

> On 01/10/2012 11:52 AM, 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?
>> 
>> 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?
> 
> On ppc, normal halt/runnable transitions are handled entirely in the
> kernel, even without irqchip.
> 
> So, the idea is that on secondary VCPU creation, QEMU sets MP_STATE to
> KVM_MP_STATE_UNITIALIZED, and KVM will hold the thread idle until the
> MMIO is done and QEMU sets MP_STATE to KVM_MP_STATE_RUNNABLE?  It seems
> excessive compared to QEMU being able to figure out for itself when it
> doesn't want to run a VCPU thread, when the decision is based entirely
> on things that are modeled in QEMU (which it will still need to do in
> the non-KVM case).

I agree, but the closer we can stick with how x86 models it today the more 
generic code we have, the better.


Alex