Re: vPT rework (and timer mode)

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Mon, Jul 06, 2020 at 08:03:50AM +0100, Paul Durrant wrote:
> > -----Original Message-----
> > From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> > Sent: 03 July 2020 16:03
> > To: Jan Beulich <jbeulich@xxxxxxxx>; Roger Pau Monné <roger.pau@xxxxxxxxxx>
> > Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx; Wei Liu <wl@xxxxxxx>; Paul Durrant 
> > <paul@xxxxxxx>
> > Subject: Re: vPT rework (and timer mode)
> > 
> > On 03/07/2020 15:50, Jan Beulich wrote:
> > > 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).
> > 
> > The various timer modes were all compatibility, and IIRC, mostly for
> > Windows XP and older which told time by counting the number of timer
> > interrupts.
> > 
> > Paul - you might remember better than me?
> 
> I think it is only quite recently that Windows has started favouring 
> enlightened time sources rather than counting ticks but an admin may still 
> turn all the viridian enlightenments off so just dropping ticks will probably 
> still cause time to drift backwards.

Even when not using the viridian enlightenments, Windows should rely
on emulated time counters (or the TSC) rather than counting ticks?

I guess I could give it a try with one of the emulated Windows versions
that we test on osstest.

Thanks, Roger.