qemu-devel
[Top][All Lists]
Advanced

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

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


From: Mark Cave-Ayland
Subject: Re: [PATCH v2 0/3] Convert sparc devices to new ptimer API
Date: Thu, 24 Oct 2019 19:04:36 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0

On 24/10/2019 13:19, Peter Maydell wrote:

> On Mon, 21 Oct 2019 at 14:43, Peter Maydell <address@hidden> 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.
>>
>> Changes v1->v2:
>>  * patches 2 and 3 are the old 1 and 2 and have been reviewed
>>  * patch 1 is new and removes a pointless NULL check; without
>>    this we'd probably have got Coverity errors when patch 3
>>    added a use of t->timer before the check for it being NULL
> 
> I'm going to apply these to target-arm.next; I know they haven't
> been on list long but the change since v1 is only minor and
> they've all been reviewed.

Thanks Peter! Not sure if you saw my Tested-by tag last week for the slavio 
(sun4m)
parts, but there were no obvious regressions that I could see under 
qemu-system-sparc.


ATB,

Mark.



reply via email to

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