On 01.07.2020 11:02, Roger Pau Monné wrote: > It's my understanding that the purpose of pt_update_irq and > pt_intr_post is to attempt to implement the "delay for missed ticks" > mode, where Xen will accumulate timer interrupts if they cannot be > injected. As shown by the patch above, this is all broken when the > timer is added to a vCPU (pt->vcpu) different than the actual target > vCPU where the interrupt gets delivered (note this can also be a list > of vCPUs if routed from the IO-APIC using Fixed mode). > > I'm at lost at how to fix this so that virtual timers work properly > and we also keep the "delay for missed ticks" mode without doing a > massive rework and somehow keeping track of where injected interrupts > originated, which seems an overly complicated solution. > > My proposal hence would be to completely remove the timer_mode, and > just treat virtual timer interrupts as other interrupts, ie: they will > be injected from the callback (pt_timer_fn) and the vCPU(s) would be > kicked. Whether interrupts would get lost (ie: injected when a > previous one is still pending) depends on the contention on the > system. I'm not aware of any current OS that uses timer interrupts as > a way to track time. I think current OSes know the differences between > a timer counter and an event timer, and will use them appropriately.
Fundamentally - why not, the more that this promises to be a simplification. The question we need to answer up front is whether we're happy to possibly break old OSes (presumably ones no-one ought to be using anymore these days, due to their support life cycles long having ended). Jan
