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. -Scott
