RE: [Xen-devel] manipulation of RDTSC values in VT xen

["Petersson, Mats" <Mats.Petersson@xxxxxxx>]

Chris,  

> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Christopher Kanich
> Sent: 01 February 2006 03:51
> To: xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: [Xen-devel] manipulation of RDTSC values in VT xen
> 
> Hi, I'm currently working with Xen unstable on a VT enabled 
> machine and was wondering if someone could point me to the 
> virtualization point (or somewhere that I might manipulate) 
> the return value of the RDTSC instruction when issued in a 
> guest domain.

The RDTSC instruction CAN be intercepted, using bit 12 in
"Processor-based VM-Execution controls", but I believe at the moment
that this is not being used. This would give EXIT_REASON_RDTSC if this
is intercepted - this functionality is currently not implemented in the
vmx.c. 

> 
> Also, it is my understanding that this value is stored per-VM 
> in the VT architecture, and thus is kept accurate as if the 
> operating system were running solitary on non-VT hardware. Is 
> this correct? I am currently investigating the fidelity of 
> the environment provided by VT Xen to programs run on guest 
> operating systems.

The current way that TSC handling works is that there's an "Offset" in
the VMCS that is added to the TSC value when doing a RDTSC. There's a
few places where TSC offset is written to:
vmcs.c:vmx_do_launch() - this is where the Virtual machine is started
the first time. 
io.c:  interrupt_post_injection() - after an interrupt has been issued. 
io.c:  vmx_do_resume() - when a VM is restarted after an intercepted
event.

The TSC_OFFSET is a signed value that is added to the actual time-stamp
counter when a RDTSC instruction is executed - assuming bit 3 in
Processor-Based Execution control is set, which is the case in the code
I've currently got, which is a few days old - but I don't think there's
been a change... 

--
Mats

> 
> Thanks for any insight you may have to offer, Chris Kanich 
> UCSD Dept. of Computer Science and Engineering
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel