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] write_tsc in a PV domain?

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: RE: [Xen-devel] write_tsc in a PV domain?
From: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Date: Tue, 25 Aug 2009 16:09:27 -0700 (PDT)
Cc: "Xen-Devel \(E-mail\)" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 25 Aug 2009 16:10:12 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4A946571.30904@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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> > Is it "legal" to write to the TSC, e.g. via wrmsr(0x10,x,y),
> > in a PV kernel?  Assuming this were executed and would cause
> > a GPF, I can't find the code in Xen that would handle it, or
> > even ignore it.
> arch/x86/traps.c:emulate_privileged_op(), case 0x30.  It looks like
> writing to 0x10 would be silently ignored.

Hmmm... maybe I am misreading the code but it looks like the
default case will end up with "goto fail" which will not
update IP and so will infinite loop trapping on that instruction.

It appears that write_tsc calls are made in linux-2.6.18 (though
apparently never get executed) but disappear somewhere before
2.6.24 and don't exist in 2.6.30 either.  So perhaps write_tsc
has never been executed in a PV guest and just doesn't work.

> Allowing it would require
> careful handling to avoid screwing up timekeeping (you'd need 
> to update
> the timekeeping parameters), but also fairly pointless 
> because it would
> only affect the pcpu that the vcpu happens to be running on 
> at that moment.

I'm still working on TSC emulation which will return
Xen system time.  The physical TSC won't get changed,
but maintaining an offset is necessary if its
possible for TSC to be "written".  I guess I will
ignore that possibility for now.

Hmmm... what about save/restore/migration?  For pvclock
to work properly across save/restore/migration, a Xen system
time offset must already be handled, so I'm thinking I
don't need to worry about that case.

Xen-devel mailing list