From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: [PATCH 0 of 5] PV on HVM Xen Date: Mon, 15 Mar 2010 16:08:51 -0700 Message-ID: <4B9EBE03.4080105@goop.org> References: <201003151205.29964.sheng@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Stefano Stabellini Cc: "xen-devel@lists.xensource.com" , Sheng Yang List-Id: xen-devel@lists.xenproject.org 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