This patchset converts the devices used by sparc machines to the new
ptimer API.

Currently the ptimer design uses a QEMU bottom-half as its mechanism
for calling back into the device model using the ptimer when the
timer has expired.  Unfortunately this design is fatally flawed,
because it means that there is a lag between the ptimer updating its
own state and the device callback function updating device state, and
guest accesses to device registers between the two can return
inconsistent device state. This was reported as a bug in a specific
timer device but it's a problem with the generic ptimer code:
https://bugs.launchpad.net/qemu/+bug/1777777

The updates to the individual ptimer devices are straightforward:
we need to add begin/commit calls around the various places that
modify the ptimer state, and use the new ptimer_init() function
to create the timer.

Testing has been 'make check', and a quick smoke test of a sparc
linux boot image I had lying around, which obviously doesn't
exercise the devices very much, so more specific testing would
be appreciated. I'm happy for these patches to go in via the
sparc tree if you want, or I can collect them up with the other
ptimer-related changes I'm sending for other archs.

thanks
--PMM


Peter Maydell (2):
  hw/timer/grlib_gptimer.c: Switch to transaction-based ptimer API
  hw/timer/slavio_timer.c: Switch to transaction-based ptimer API

 hw/timer/grlib_gptimer.c | 28 ++++++++++++++++++++++++----
 hw/timer/slavio_timer.c  | 20 ++++++++++++++++----
 2 files changed, 40 insertions(+), 8 deletions(-)

-- 
2.20.1

On 17/10/2019 14:23, Peter Maydell wrote:

> This patchset converts the devices used by sparc machines to the new
> ptimer API.
> 
> Currently the ptimer design uses a QEMU bottom-half as its mechanism
> for calling back into the device model using the ptimer when the
> timer has expired.  Unfortunately this design is fatally flawed,
> because it means that there is a lag between the ptimer updating its
> own state and the device callback function updating device state, and
> guest accesses to device registers between the two can return
> inconsistent device state. This was reported as a bug in a specific
> timer device but it's a problem with the generic ptimer code:
> https://bugs.launchpad.net/qemu/+bug/1777777
> 
> The updates to the individual ptimer devices are straightforward:
> we need to add begin/commit calls around the various places that
> modify the ptimer state, and use the new ptimer_init() function
> to create the timer.
> 
> Testing has been 'make check', and a quick smoke test of a sparc
> linux boot image I had lying around, which obviously doesn't
> exercise the devices very much, so more specific testing would
> be appreciated. I'm happy for these patches to go in via the
> sparc tree if you want, or I can collect them up with the other
> ptimer-related changes I'm sending for other archs.
> 
> thanks
> --PMM

I've given these patches a spin on my OpenBIOS test images and I don't see any
obvious regressions, so for the sun4m (slavio) part:

Tested-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>

Frederic, are you able to make sure that the leon3 parts don't cause any problems?
Currently I don't have any outstanding SPARC patches, so if you want to include them
in a ptimer-related PR then that's fine with me.


ATB,

Mark.