Re: [Qemu-devel] Re: [RFC: 0/2] patch for QEMU HPET periodic timer emulation to alleviate time drift

[Jan Kiszka <jan.kiszka@siemens.com>]

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