[RFC qemu legoater/aspeed-3.1 0/4] Handle short timer periods

[Cédric Le Goater]

Hello Andrew,

On 1/11/19 4:56 AM, Andrew Jeffery wrote:
> Hello,
> 
> We've had an issue for a while, since the introduction of 4451d3f59f2a
> ("clocksource/drivers/fttmr010: Fix set_next_event handler") in Linux, where
> our qemu instances have a "sticky" behaviour. The VM becomes unresponsive at
> unexpected times for unpredicable but often long periods of time.
> 
> This series, along with the associated patch to Linux's fttmr010 driver[0],
> aims to resolve it.
> 
> [0] http://patchwork.ozlabs.org/patch/1023363/

I gave the whole a try and on a x86 host, QEMU reaches :

[    8.282333] systemd[1]: Set hostname to <romulus>.

on a ppc64el :

[   11.497910] systemd[1]: Set hostname to <romulus>.

which is much better than before.

As the QEMU patchset does not seem to impact support for older images, 
I have updated the aspeed-3.1 branch and also created a new branch for 
dev : aspeed-4.0.

> The series an RFC series because it doesn't fix all the cases, just
> demonstrates a potential way forward. The approach is to provide back-pressure
> - to test if the reload value is set to a value that's smaller than some
> experimentally determined value (in this case, 20us), and if so, configure a
> period of at least 20us. The MAX() of the requested and minimum values is then
> set in the reload register rather than the requested value, which can then be
> read back by Linux. The fttmr010 driver, upon observing the greater value,
> starts pushing back on the clock event subsystem, which then iteratively
> determines a minimum acceptible event period before proceeding with the boot
> process.
> 
> The implementation does not take care of the match register cases, but at the
> moment they are unused by Linux on Aspeed SoCs. The match register case is not
> taken care of because I'm not sure if this implementation is what we want to
> use going forward, or whether we want to do something that's completely hidden
> in the qemu model. However taking advantage of Linux's existing support for
> determining minimum timer periods seemed like easy solution.
> 
> The stickiness turns out to be a consequence of Linux configuring a very short
> timer period (1us, mostly due to the timerio_rng driver), which causes qemu to
> spend a large chunk of its timeslice handling the host timer interrupt rather
> than executing guest code.
> 
> Please critique!

We are adding another QEMU HW tweak in Linux. We need feedback from the
Linux maintainers I would say.

Thanks,

C. 
 
> 
> Andrew
> 
> Andrew Jeffery (4):
>   timer: aspeed: Fire interrupt on failure to meet deadline
>   timer: aspeed: Status register contains reload for stopped timer
>   timer: aspeed: Fix match calculations
>   timer: aspeed: Provide back-pressure information for short periods
> 
>  hw/misc/aspeed_scu.c            |  6 ++++++
>  hw/timer/aspeed_timer.c         | 37 ++++++++++++++++++++++++++-------
>  include/hw/timer/aspeed_timer.h |  1 +
>  3 files changed, 36 insertions(+), 8 deletions(-)
>