qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Re: [RFC: 0/2] patch for QEMU HPET periodic timer emula


From: Jan Kiszka
Subject: Re: [Qemu-devel] Re: [RFC: 0/2] patch for QEMU HPET periodic timer emulation to alleviate time drift
Date: Mon, 07 Feb 2011 15:57:54 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

On 2011-02-07 15:54, Anthony Liguori wrote:
> On 02/07/2011 08:43 AM, Jan Kiszka wrote:
>> On 2011-02-07 15:28, Anthony Liguori wrote:
>>    
>>> On 02/07/2011 08:10 AM, Jan Kiszka wrote:
>>>      
>>>> Again: please not in an ad-hoc fashion but as a generic services usable
>>>> by _all_ periodic timer sources that want to implement compensation.
>>>> This infrastructure should also be designed to once integrate IRQ
>>>> coalescing information as well.
>>>>
>>>> The point why I'm insisting on a broader solution is that both sources
>>>> for lost ticks (iothread and vcpu) end up in the same output: an
>>>> adjustment of the injection frequency of the affected timer device.
>>>> There is not "HPET" or "RTC" or "PIT" in this, all this may apply to the
>>>> SoC timer of some emulated ARM board as well.
>>>>
>>>>        
>>> Fair enough, how about:
>>>
>>> typedef struct PeriodicTimer PeriodicTimer;
>>>
>>> /**
>>>    * @accumulated_ticks:  the number of unacknowledged ticks in total
>>> since the creation of the timer
>>>    **/
>>> typedef void (PeriodicTimer)(void *opaque, int accumulated_ticks);
>>>      
>> I guess you mean PeriodicTimerFunc.
> 
> Yes.
> 
>>   Why the accumulated_ticks argument?
>>    
> 
> Then the missing ticks is stored in the PeriodicTimer instead of storing 
> it in the device state.  That means we won't forget to save it in vmstate.

There should rather be a special vmstate struct for PeriodicTimer, just
like we already have for normal timers.

> 
> It's convenient because then if we lose ticks in the PeriodicTimer 
> layer, the devices have instance access to that info.  When you do a 
> read() from timerfd, it returns the number of coalesced events.  That's 
> the interface I had in my mind.
> 
> We could just add a getter for PeriodicTimer and it would serve the same 
> purpose.

I'm still not sure what the device model is supposed to do with that
information. I think at could remain private to the PeriodicTimer
implementation (unless we want to dump some stats or such).

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux



reply via email to

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