This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 0 of 5] PV on HVM Xen
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Mon, 15 Mar 2010 16:08:51 -0700
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Sheng Yang <sheng@xxxxxxxxxxxxxxx>
Delivery-date: Mon, 15 Mar 2010 16:09:50 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <alpine.DEB.2.00.1003151128010.28944@kaball-desktop>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <alpine.DEB.2.00.1003101457100.28412@kaball-desktop> <alpine.DEB.2.00.1003121024590.27222@kaball-desktop> <alpine.DEB.2.00.1003121432460.27222@kaball-desktop> <201003151205.29964.sheng@xxxxxxxxxxxxxxx> <alpine.DEB.2.00.1003151128010.28944@kaball-desktop>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100301 Fedora/3.0.3-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.3
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).


Xen-devel mailing list