[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] manipulation of RDTSC values in VT xen
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |