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: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 0 of 5] PV on HVM Xen
From: Frank van der Linden <frank.van.der.linden@xxxxxxxxxx>
Date: Mon, 15 Mar 2010 17:24:19 -0600
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Delivery-date: Mon, 15 Mar 2010 16:25:30 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4B9EBE03.4080105@xxxxxxxx>
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> <4B9EBE03.4080105@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv: Gecko/20100131 Lightning/1.0b1 Thunderbird/3.0.1
On 03/15/10 05:08 PM, Jeremy Fitzhardinge wrote:
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).

I'd like to see it done explicitly too. You could use PV timestamps without actually using VIRQ_TIMER. It would not be an optimal combination, but you could do it. In fact, just today I looked at an old patch that I had lying around to do just this for Solaris PV domU.

Also, relying on side-effects makes for bad interfaces.

- Frank

Xen-devel mailing list