From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Magenheimer Subject: RE: [PATCH 0 of 5] PV on HVM Xen Date: Mon, 15 Mar 2010 17:32:22 -0700 (PDT) Message-ID: References: <201003151205.29964.sheng@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <4B9EBE03.4080105@goop.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jeremy Fitzhardinge , Stefano Stabellini Cc: frank.van.der.linden@oracle.com, xen-devel@lists.xensource.com, Sheng Yang List-Id: xen-devel@lists.xenproject.org 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=3D=3D2 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@goop.org] > Sent: Monday, March 15, 2010 5:09 PM > To: Stefano Stabellini > Cc: xen-devel@lists.xensource.com; Sheng Yang > Subject: Re: [Xen-devel] [PATCH 0 of 5] PV on HVM Xen >=20 > 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. > > >=20 > 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? >=20 > 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. >=20 > 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). >=20 > J >=20 > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel