Blue Swirl wrote: >>>> This is - according to my current understanding - the proposed >>>> alternative architecture: >>>> >>>> .---------------. >>>> | de-coalescing | >>>> | logic | >>>> '---------------' >>>> ^ | >>>> period,| |IRQ >>>> coalesced| |(or tuned VM clock) >>>> (yes/no)| v >>>> .-------. .--------. .-------. >>>> | RTC |-----IRQ----->| router |-----IRQ---->| APIC | >>>> '-------' '--------' '-------' >>>> | ^ | ^ >>>> | | | | >>>> '-------period-------' '------period-------' >>> The period information is already known by the higher level clock >>> management, >> The timer device models program the next event of some qemu-timer. There >> is no tag attached explaining the timer subsystem or anyone else the >> reason behind this programming. > > Yes, but why would we care? All timers in the system besides RTC > should be affected likewise, this would in fact be the benefit from > handling the problem at higher level.
And how does your equation for calculating the clock slow-down look like? Jan
signature.asc
Description: OpenPGP digital signature
