[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [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? 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), why can't the Viridian clock not use the
same pt_global_vcpu_target() based approach other virtual clocks do?

Jan


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.