Re: [Qemu-devel] [PULL 17/28] hw/ptimer: Perform counter wrap around if timer already expired

[Dmitry Osipenko]

On 24.06.2016 21:37, Mark Cave-Ayland wrote:
> On 24/06/16 19:19, Dmitry Osipenko wrote:
> 
>> On 24.06.2016 19:02, Peter Maydell wrote:
>>> On 24 June 2016 at 16:58, Mark Cave-Ayland
>>> <address@hidden> wrote:
>>>> On 06/06/16 15:47, Peter Maydell wrote:
>>>>
>>>>> From: Dmitry Osipenko <address@hidden>
>>>>>
>>>>> ptimer_get_count() might be called while QEMU timer already been expired.
>>>>> In that case ptimer would return counter = 0, which might be undesirable
>>>>> in case of polled timer. Do counter wrap around for periodic timer to keep
>>>>> it distributed. In order to achieve more accurate emulation behaviour of
>>>>> certain hardware, don't perform wrap around when in icount mode and return
>>>>> counter = 0 in that case (that doesn't affect polled counter
>>>>> distribution).
>>>>>
>>>
>>>> Whilst testing Artyom's qemu-system-sparc patch today, I noticed another
>>>> regression which I've bisected down to the above commit.
>>>>
>>>> Booting my NetBSD/OpenBSD test images with current git master causes the
>>>> following warning to appear on the console: "WARNING: negative runtime;
>>>> monotonic clock has gone backwards".
>>>>
>>>> Could this be a regression or does qemu-system-sparc make an incorrect
>>>> assumption as to how the timer should work in this scenario?
>>>
>>> I'm not sure -- Dmitry ?
>>>
>>> thanks
>>> -- PMM
>>>
>>
>> The problem could be due to the IRQ being raised after the poll of the 
>> wrapped
>> around counter in non-icount mode, so CPU "sees the future". In that case 
>> patch
>> should be reverted and reworked. During the review of the patch we decided 
>> that
>> it shouldn't be an issue. I'll take a closer look at it and try to reproduce 
>> the
>> issue.
> 
> Hi Dmitry,
> 
> Thanks for looking at this. The reproducer with NetBSD is fairly easy:
> 
> ./qemu-system-sparc -cdrom NetBSD-6.1.5-sparc.iso -boot d
> 
> Hit 1 followed by Enter for the first couple of questions, and by the time you
> get asked for the terminal settings you should find that the message has been
> emitted somewhere on the console.
> 
> 
> ATB,
> 
> Mark.
> 
> (repost due to mail client crash - apologies if this is a repeat)
> 

Hi Mark,

Thanks for the guide. I successfully reproduced the issue (it's exactly what I
supposed in my previous reply) and will send fix for it shortly. Sorry for
inconvenience.

-- 
Dmitry