On Tue, Mar 14, 2017 at 04:55:34PM +0000, Alex Bennée wrote:
>
> Krzysztof Kozlowski <k...@kernel.org> writes:
>
> > Hi,
> >
> <snip>
> >
> > Overview of the problem
> > =======================
> > On Exynos4210, by default Linux kernel uses cpuidle driver which tries
> > to enter low power mode, called AFTR (Arm Off, Top Running). On real
> > hardware this brings some power savings. This AFTR mode requires second
> > CPU to be off, so the driver (coupled cpuidle driver) when system is idle:
> > 1. Turns off second CPU,
> > 2. Enters AFTR on CPU0.
> >
> > However the QEMU system is then totally unresponsive (e.g. on serial
> > console)
> > and RCU stalls appear from time to time. I spent some time on it and did
> > not
> > find the real cause behind the lag. Maybe it is because the second CPU
> > does not really power down itself and system just burns the cycles under
> > spin
> > locks?
>
> Was this tested post the MTTCG merge? Maybe there is an interaction
> between power saving/halting the vCPU?
>
> I mention this because I already made some minor tweaks for handing the
> WFI instruction in MTTCG. See commit c22edfebff. You can test this by
> forcing the original behaviour by adding:
>
> -accel tcg,thread=single
>
> to your command line.
>
I am testing it on v2.8.0-2005-g17783ac828ad. Without any -accel, the
system boots but responsiveness of serial console is bad. Bad but at
least it is responding still a little bit.
With the -accel you mentioned, system does not even reach user-space
(initramfs).
I tried rebasing on newer (e.g. v2.8.0-2182-g5e2fb7c598c6) but
compilation fails all the time on:
/home/dev/qemu/qemu/vl.c: In function ‘main’:
/home/dev/qemu/qemu/vl.c:3131:18: error: ‘QEMU_OPTION_blockdev’ undeclared
(first use in this function)
case QEMU_OPTION_blockdev:
Best regards,
Krzysztof
