[was Re: Use CPUID to communicate with the hypervisor.]
On Tue, 2008-09-30 at 01:11 -0700, Gerd Hoffmann wrote:
> Alok Kataria wrote:
> > Hi Gerd,
> >
> > I really fail to see your point here. Maybe you can point out what am i
> > missing.
> > Think about the current situation, whenever there is migration to such a
> > tsc-is-different system , how does the guest come to know about the
> > frequency change, either through a $event or if it reboots it runs the
> > calibration algorithm.
>
> Well, that should be clearly defined, that is my point. When asking the
> hypervisor for the tsc instead of running a calibration loop, then we
> have a small bit of paravirtualization: The guest is aware that it runs
> on a hypervisor and just asks it directly. So while we are at it we can
> also define a way to communicate tsc freq changes between host and
> guest, so the cost of trap'n'emulate tsc reads can be avoided. Or we
> define "tsc is constant" and leave it to the hypervisor to make sure it
> actually appears being constant to the guest, even in case it changes on
> the host. But it must be defined one way or another, so the guest knows
> whenever it should expect the tsc frequency change or not.
Hi Gerd,
As Zach explained, we support a view that, tsc is constant. This Timing
CPUID leaf should be just seen as a way to get the current TSC from the
hypervisor. Also, one thing to note would be that, this interface allows
us to reinitialize the TSC frequency if the need is felt.
Coming back to the migration problem, as you too acknowledge, migration
to a host with a different frequency should be seen as a different
problem. I would be interested in learning about any proposal that you
may have thought about to handle this.
>
> Is the tsc cpu leaf interface set in stone already (aka implemented in
> vmware versions released to public)?
Yep, this interface is already implemented in the VMware workstation 6.5
product.
>
> > What special things does Xen do at migration, which would be affected by
> > this interface ?
>
> paravirtualized xen guests have a paravirtual clock. That is a struct
> containing three pieces of information: system time, tsc counter for the
> last system time update, tsc frequency. The guest gets the current time
> by reading the system time and adding a delta calculated from current
> tsc, tsc of last systime update and tsc frequency. Handling tsc
> frequency changes is obviously trivial here, just update the field on
> the next systime update ;)
Oh nice, that is convenient.
Thanks,
Alok
Alok Kataria wrote:
> Hi Gerd,
>
> As Zach explained, we support a view that, tsc is constant.
Ok, so the guest doesn't have to worry about possible tsc changes when
using that interface. Should go into the comment documenting the leaf.
> Coming back to the migration problem, as you too acknowledge, migration
> to a host with a different frequency should be seen as a different
> problem. I would be interested in learning about any proposal that you
> may have thought about to handle this.
xen paravirtualized is explained below.
xen full virtualized: dunno.
kvm: provide something else for timekeeping to avoid the tsc trouble
altogether if possible. hpet, pm_timer, paravirtualized clocksource.
Obviously can't work for all guests though. paravirtual clocksource
works like the xen one.
cheers,
Gerd
>>> What special things does Xen do at migration, which would be affected by
>>> this interface ?
>> paravirtualized xen guests have a paravirtual clock. That is a struct
>> containing three pieces of information: system time, tsc counter for the
>> last system time update, tsc frequency. The guest gets the current time
>> by reading the system time and adding a delta calculated from current
>> tsc, tsc of last systime update and tsc frequency. Handling tsc
>> frequency changes is obviously trivial here, just update the field on
>> the next systime update ;)
>
> Oh nice, that is convenient.
>
> Thanks,
> Alok
>
>