On Sun, May 29, 2016 at 07:29:27PM -0300, Marcelo Tosatti wrote:
> On Wed, May 25, 2016 at 09:30:02PM +0300, Roman Kagan wrote:
> > On Mon, May 23, 2016 at 08:44:03PM -0300, Marcelo Tosatti wrote:
> > > On Mon, May 23, 2016 at 06:55:06PM -0300, Marcelo Tosatti wrote:
> > > which fails once you run
> > >
> > > void main(void)
> > > {
> > > int ret;
> > > struct timex tx;
> > > char *ptr;
> > >
> > > memset((void*)&tx, 0, sizeof(tx));
> > >
> > > tx.freq = -6553600;
> > > //tx.freq = -237507;
> > > tx.modes = ADJ_FREQUENCY;
> > > ret = adjtimex(&tx);
> >
> > Right, which is a problem with kvm-clock too (as I wrote in another
> > thread, pvclock_gtod_data updates don't currently trigger per-VM
> > masterclock updates). I'm still struggling through the multiple lengthy
> > discussions trying to figure out if it's a bug or a feature...
>
> Its a bug, i am writing an improvement based on Paolo's change to
> update the multiplier.
>
> But the hyperv tsc reference page patches should not depend on it.
Unfortunately it does: since hyperv tsc reference page doesn't have
seqlock semantics, it's emulated (per Paolo's suggestion) by marking the
contents invalid with seqcount == 0, which makes Windows use MSR-based
clock. And the two clocks are not expected to diverge.
Roman.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
