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

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: 19 March 2019 13:32
> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> Cc: Julien Grall <julien.grall@xxxxxxx>; Andrew Cooper 
> <Andrew.Cooper3@xxxxxxxxxx>; George Dunlap
> <George.Dunlap@xxxxxxxxxx>; Ian Jackson <Ian.Jackson@xxxxxxxxxx>; Roger Pau 
> Monne
> <roger.pau@xxxxxxxxxx>; Wei Liu <wei.liu2@xxxxxxxxxx>; Stefano Stabellini 
> <sstabellini@xxxxxxxxxx>;
> xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>; Konrad Rzeszutek Wilk 
> <konrad.wilk@xxxxxxxxxx>; Tim
> (Xen.org) <tim@xxxxxxx>
> Subject: RE: [PATCH v9 10/11] viridian: add implementation of synthetic timers
> 
> >>> On 19.03.19 at 13:47, <Paul.Durrant@xxxxxxxxxx> wrote:
> >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> >> Sent: 19 March 2019 12:18
> >>
> >> So perhaps a set
> >> pending bit should result in the RDMSR handling to clear the enabled
> >> bit in the returned value for a non-periodic timer?
> >
> > I get tied in knots every time I think about this and without waiting for a
> > pending timer to stop when it is disabled I see no way of the race, but I
> > think doing that would be prohibitively slow because windows seems to flip
> > between single-shot and periodic timers on quite a frequent basis.
> 
> I'm afraid I don't understand: Why a timer or any other complications.
> All I'm thinking about is
> 
>     case HV_X64_MSR_STIMER0_CONFIG:
>     case HV_X64_MSR_STIMER1_CONFIG:
>     case HV_X64_MSR_STIMER2_CONFIG:
>     case HV_X64_MSR_STIMER3_CONFIG:
>     {
>         unsigned int stimerx = (idx - HV_X64_MSR_STIMER0_CONFIG) / 2;
>         const struct viridian_stimer *vs =
>             &array_access_nospec(vv->stimer, stimerx);
> 
>         if ( !(viridian_feature_mask(d) & HVMPV_stimer) )
>             return X86EMUL_EXCEPTION;
> 
>         *val = vs->config.raw;
>         if ( !vs->config.periodic && test_bit(stimerx, vv->stimer_pending) )
>             *val &= ~1;
>         break;
>     }
> 
> or a suitable equivalent to avoid the literal 1, plus perhaps a
> helpful comment.

Ok. That shouldn't hurt. I'll avoid the literal 1 as you suggest and test an 
equivalent.

  Paul

> 
> Jan
> 


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