RE: [Xen-devel] [PATCH 0 of 5] PV on HVM Xen

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

Sorry I've fallen hopelessly behind on this thread (rope? :-)
so apologies if this has already been addressed:

If the host and guest need to share the same tsc to work
properly, and there are apps in the guest that assume a
monotonically increasing TSC (or even "approximately monotonically
increasing", e.g. can filter out reasonably small differences),
and the VM migrates from a physical machine that's been running
a long time to a recently booted physical machine, what
happens to the app?  (Answer: Prior to 4.0, or with tsc_mode==2
in 4.0, the app fails.)

TSC emulation addresses this issue (which is why it is effectively
the default in Xen 4.0**) but has the side effect that the TSC reads
required for the pvclock algorithm are trapped/emulated.  In this
case, pvclock may not be much faster than alternative
clocksource implementations.

Sheng/Stefano, have you actually measured pvclock recently
and compared it to other alternatives?  I'm wondering how
much of this discussion is moot.

Dan

P.S. Note that TSC emulation in many cases behaves differently
before and after migration, specifically on modern processors
depending on the clock frequency of the source/destination
machines, so please ensure post-migration is measured as this
will be the common case in many virtualized data centers.

** see xen-unstable.hg/docs/misc/tscmode.txt

> -----Original Message-----
> From: Jeremy Fitzhardinge [mailto:jeremy@xxxxxxxx]
> Sent: Monday, March 15, 2010 5:09 PM
> To: Stefano Stabellini
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx; Sheng Yang
> Subject: Re: [Xen-devel] [PATCH 0 of 5] PV on HVM Xen
> 
> On 03/15/2010 05:28 AM, Stefano Stabellini wrote:
> > I like your pv clocksource implementation.
> > The only reason why I would defer the patch is that I don't
> particularly
> > like the "enable_pv" hypercall, so I would try to get away without
> it,
> > resetting the tsc offset automatically when enabling the VIRQ_TIMER
> on
> > an HVM domain.
> >
> 
> Ah, so the issue is that if we're using the pvclock, the host and guest
> need to share the same tsc, so we can't deal with any kind of tsc
> offset?
> 
> In that case, I'd prefer to have an explicit "set/remove tsc offset"
> vcpu op rather than making it the implicit side-effect of anything
> else.  In particular, since clock sources and event sources are
> completely distinct, making tsc offset (a clock source thing) affected
> VIRQ_TIMER (and event source thing) seems like a particularly poor
> idea.
> 
> That, or make the pvclock structure the HVM vcpu sees have timing
> parameters which already incorporate the tsc offset.  We've already
> demonstrated that there's no need to have the time info in the real
> shared memory between Xen and the domain (it can be updated via copy
> when needed).
> 
>      J
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel

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