> -----Original Message----- > From: Jan Beulich [mailto:[email protected]] > Sent: 19 March 2019 13:32 > To: Paul Durrant <[email protected]> > Cc: Julien Grall <[email protected]>; Andrew Cooper > <[email protected]>; George Dunlap > <[email protected]>; Ian Jackson <[email protected]>; Roger Pau > Monne > <[email protected]>; Wei Liu <[email protected]>; Stefano Stabellini > <[email protected]>; > xen-devel <[email protected]>; Konrad Rzeszutek Wilk > <[email protected]>; Tim > (Xen.org) <[email protected]> > Subject: RE: [PATCH v9 10/11] viridian: add implementation of synthetic timers > > >>> On 19.03.19 at 13:47, <[email protected]> wrote: > >> From: Jan Beulich [mailto:[email protected]] > >> 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 [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
