Re: [Xen-devel] [PATCH 2/2] x86/viridian: Add partition time reference counter MSR support

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: 01 August 2014 16:52
> To: Paul Durrant
> Cc: Ian Campbell; Ian Jackson; Stefano Stabellini; xen-devel@xxxxxxxxxxxxx;
> Keir (Xen.org)
> Subject: Re: [PATCH 2/2] x86/viridian: Add partition time reference counter
> MSR support
> 
> >>> On 01.08.14 at 17:21, <paul.durrant@xxxxxxxxxx> wrote:
> > The counter value used in this implementation properly fulfils the
> > documented semantics of the MSR.
> 
> Does it? See below ...
> 
> > @@ -344,6 +346,20 @@ int rdmsr_viridian_regs(uint32_t idx, uint64_t *val)
> >          *val = v->arch.hvm_vcpu.viridian.apic_assist.raw;
> >          break;
> >
> > +
> > +    case VIRIDIAN_MSR_TIME_REF_COUNT:
> 
> Please don't add a second blank line above this case.
> 
> > +    {
> > +        uint64_t sec, nsec;
> > +
> > +        if ( ~viridian_feature_mask(d) & HVMPV_time_ref_count )
> > +            return 0;
> > +
> > +        perfc_incr(mshv_rdmsr_time_ref_count);
> > +        sec = shared_info(d, wc_sec);
> > +        nsec = shared_info(d, wc_nsec);
> > +        *val = (SECONDS(sec) + nsec + NOW()) / 100ul;
> > +        break;
> > +    }
> 
> Doesn't this assume fully synchronized wall clocks between source and
> destination hosts of a migration?

Yes, that's true.

> And suffer from discontinuities due
> to host wall clock adjustments? Or domain_set_time_offset()
> invocations?
> 
> As mentioned on IRC to Andrew the other day (not sure if he
> communicated this onwards),

He didn't.

> why can't the Viridian clock not use the
> same pt_global_vcpu_target() based approach other virtual clocks do?
> 

I'll have a look at that. We need something that won't go backwards on migrate.

  Paul

> Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel