RE: [Xen-devel] write_tsc in a PV domain?

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

> > 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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel