qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 0/2] Convert sparc devices to new ptimer API


From: Mark Cave-Ayland
Subject: Re: [PATCH 0/2] Convert sparc devices to new ptimer API
Date: Sun, 20 Oct 2019 17:11:03 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0

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 <address@hidden>

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]