Re: [Xen-devel] [PATCH v7 10/11] viridian: add implementation of synthetic timers

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: 15 March 2019 09:53
> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> Cc: Julien Grall <julien.grall@xxxxxxx>; Andrew Cooper 
> <Andrew.Cooper3@xxxxxxxxxx>; Roger Pau Monne
> <roger.pau@xxxxxxxxxx>; Wei Liu <wei.liu2@xxxxxxxxxx>; George Dunlap 
> <George.Dunlap@xxxxxxxxxx>; Ian
> Jackson <Ian.Jackson@xxxxxxxxxx>; Stefano Stabellini 
> <sstabellini@xxxxxxxxxx>; xen-devel <xen-
> devel@xxxxxxxxxxxxxxxxxxxx>; Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>; 
> Tim (Xen.org)
> <tim@xxxxxxx>
> Subject: Re: [PATCH v7 10/11] viridian: add implementation of synthetic timers
> 
> >>> On 14.03.19 at 19:11, <paul.durrant@xxxxxxxxxx> wrote:
> > This patch introduces an implementation of the STIMER0-15_CONFIG/COUNT MSRs
> > and hence a the first SynIC message source.
> >
> > The new (and documented) 'stimer' viridian enlightenment group may be
> > specified to enable this feature.
> >
> > While in the neighbourhood, this patch adds a missing check for an
> > attempt to write the time reference count MSR, which should result in an
> > exception (but not be reported as an unimplemented MSR).
> >
> > NOTE: It is necessary for correct operation that timer expiration and
> >       message delivery time-stamping use the same time source as the guest.
> >       The specification is ambiguous but testing with a Windows 10 1803
> >       guest has shown that using the partition reference counter as a
> >       source whilst the guest is using RDTSC and the reference tsc page
> >       does not work correctly. Therefore the time_now() function is used.
> >       This implements the algorithm for acquiring partition reference time
> >       that is documented in the specifiction.
> >
> > Signed-off-by: Paul Durrant <paul.durrant@xxxxxxxxxx>
> > Acked-by: Wei Liu <wei.liu2@xxxxxxxxxx>
> 
> Hypervisor parts
> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
> 
> I'll get this series in once the tree is fully open again.
> 

I've been doing more testing on the final series and I'm seeing a problem which 
appears to be down to the poll blocking that I added during review. Just 
occasionally, if I get the VM idle, then the timer appears to wedge up. I can 
usually unblock the VM by sending a keyboard interrupt but the problem does not 
occur at all if I remove the poll blocking flag.

So, AIUI the reason you wanted it added was that you wanted to avoid multiple 
calls hvm_vcpu_has_pending_irq() from returning different intack values? But 
looking again, this could easily happen if a higher irr bit gets set between 
calls (which can apparently happen asynchronously) so I'm really no longer sure 
why I need to avoid multiple polls. What is the problem that needs to be 
avoided?

  Paul


> Jan
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel