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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
