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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
