[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] [PATCH] replace rdtsc emulation-vs-native xen boot option with per-domain (hypervisor part)



> >> Perhaps a better choice would be for emulated tsc
> >> to return Xen system time in both kernel and user
> >> mode (which is what it does for HVM domains) and,
> >> when a domain has tsc_native==0,
> >> Xen sets its pvclock parameters so that no scaling
> >> occurs?  This results in the guest reporting that
> >> it has a 1GHz clock, but may be more consistent.
> > 
> > Yes, this has to be fixed. There's no good reason for different TSC
> > behaviours between kernel and userspace when both are 
> emulated. If nothing
> > else, when Jeremy's patches go in (which I am sure they 
> will, as the concept
> > is sane and the implementation appears so too) then that is 
> going to be
> > incompatible with emulated tsc as it behaves currently.
> 
> Should be fixed by c/s 20271.

Excellent.  Thanks.

But in reviewing this patch, I noticed that you removed
the vtsc_stime_offset field in struct arch_domain.

This was intended to record the offset across migration.
But a per-domain stime offset must already be recorded
somewhere else, or hvm fully-emulated platform timers
would be broken across migration.

Do pv guests need something similar or is it magically
handled someplace that I couldn't quickly find?

Thanks,
Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.