Re: [patch 3/3] KVM: VMX: initialize TSC offset relative to vm creation time

Avi Kivity
2008-12-11T17:38:29Z

>> This looks fine, but have you tested it on a host with unsync tsc? I'm
>> worried that we'll get regressions there even on uniprocessor guest.
>> I'd like to keep the current behaviour for the special case of
>> uniprocessor guest on unsync tsc host.
>>
>
> I don't see how. For UP guests the TSC is initialized to zero during
> vcpu setup, similarly to the current behaviour.
>
> Can you explain?
>
>

On a host with an unsync tsc, when you move the vcpu to another cpu, the
tsc may jump backwards.

>> There's a further improvement possible: treating the tsc as shared among
>> all vcpus, so that a guest write to one will update all of them, like on
>> a hyperthreaded core. This will prevent the unsyncing caused by the
>> host trying to sync tscs, and the vcpu being scheduled away at the same
>> time.
>>
>
> You mean the guest trying to sync tscs? Indeed, that is sensitive to
> scheduling (like most of the calibration algorithms that are time
> sensitive).

Yes.

> Your suggestion differs from the behaviour of actual
> hardware, though.
>

It's similar to how hyperthreaded cpus work, so there is precedent.

> Anyway, this patch is trivial, and an improvement compared to the
> current situation.
>

I'm worried that it will regress for single vcpu guests on unsync tsc hosts.

> What are the possible implications of simply not zeroing the guest TSC ?
> Guests will have access to the hosts TSC value, but how bad that is?
>

We need to set the guest tsc anyway for live migration, so we may as
well reset it on startup. It's not a correctness issue, just seems
cleaner that way.

--
error compiling committee.c: too many arguments to function