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

[Avi Kivity <avi@redhat.com>]

Marcelo Tosatti wrote:

  

>> 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