similar to: Guest TSC and Xen (Intel and AMD feedback please)

Hi: I intend to use RDTSC to make some time tests in Xen guest WinXP. However, from Intel Developer''s Manual I noticed that RDTSC will cause VMExit if "RETSC exiting" VM-Execution control field is 1. So I wonder: How to query VM-Execution control field in a programmable way? BTW: On Intel Developer''s Manual, it mentioned a method using IA32_VMX_PROCBASED_CTLS MSR,

Hi, I have done some debugging to find out the root cause of bug 1282, which has the following symptoms with paravirtualized guests: - after a live migrate, the time on the guest can jump - after a live migrate, the guest "forgets" to wake up processes - after a domU save, dom0 reboot and domU restore, the time is correct but processes are not woken up from sys_nanosleep The problem

Hi all, I was wondering if cpu frequency scaling in dom0 (using the cpufreq=dom0-kernel boot parameter) may cause problems with HVM domUs? This is on Xen 3.2.1. PV domUs seem to work just fine. They adjust to the frequency change on the go. The HVM I run using the unmodified_driver drivers (also from the 3.2.1 release) seem to have very slow timers if dom0 lowers the frequency. Birger

# HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1320922479 0 # Node ID bc79b560aafa1e4dc42af00e6a326dc651b5636a # Parent 460b507e15f864dd6712f5040e36538d6e076ae4 libxl: use named options for tsc_mode. It seems that this knob is expoerted from the hypervisor as a raw integer (no symbolic names) documented in xen/include/asm-x86. Propagating that all the way to the

(Moving from offlist discussion.) I''m interested in opinions... Assume there are four single vcpu domains A, B, C, D, running on a 2-CPU physical machine. We wish to test for time skew on domain A. Assuming B, C, and D are all running some workload that attempts to fully saturate the (single) cpu. 1) Should the affect on domain A be essentially the same regardless of what load

Implement tsc adjust feature IA32_TSC_ADJUST MSR is maintained separately for each logical processor. A logical processor maintains and uses the IA32_TSC_ADJUST MSR as follows: 1). On RESET, the value of the IA32_TSC_ADJUST MSR is 0; 2). If an execution of WRMSR to the IA32_TIME_STAMP_COUNTER MSR adds (or subtracts) value X from the TSC, the logical processor also adds (or subtracts) value X

Folks, The second release candidate for Xen 3.4.0 is available at http://xenbits.xensource.com/xen-unstable.hg, tagged as ''3.4.0-rc2''. Please test! -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

I''m continuing to investigate the usage of rdtsc in userspace and whether there are programs "out there" that use it "unsafely" that might randomly break under Xen if rdtsc is not emulated, e.g. across a migration. Some have argued that nobody should use rdtsc and any programs that use rdtsc directly are "fundamentally broken" so the default for rdtsc

Changeset 17716 provides monotonically increasing guest time for HVM domains, by using the per-domain pl_time structure. hvm_get_guest_time and hvm_set_guest_time were changed to use this. Previously, the guest time was stored directly in the TSC offset fields of the vmx/smv control structures. Since pt_freeze_time and pt_thaw_time use hvm_get/set_guest_time, they now no longer freeze TSC

Hey, I''m experiencing strange problem: non-deterministic PV domain hang, only on some machines (with fast SSD drive). I''ve tried xen-4.1.0 and xen-4.1.1 with many kernels different kernels: VM: - 2.6.38.3 xenlinux based on SUSE package - vanilla 3.0.3 - vanilla 3.1 rc2 dom0: - 2.6.38.3 xenlinux based on SUSE package - vanilla 3.1 rc2 Result always the same: sometimes VM

I''ve noticed with xen-unstable on my quad-core x dual-thread (that''s 8 processors to xen), the boot info spewed for all the C-state/P-state stuff quickly fills the xm dmesg buffer and I lose some of the early-in-boot lines. Do we really need to know "reg.{space_id,bit_width,bit_offset,access_size, address}" and all that other info? Even if so, is there a more compact

On Tue, Sep 18, 2018 at 12:41:57PM +0200, Thomas Gleixner wrote: > On Tue, 18 Sep 2018, Thomas Gleixner wrote: > > On Tue, 18 Sep 2018, Thomas Gleixner wrote: > > > On Tue, 18 Sep 2018, Peter Zijlstra wrote: > > > > > Your memory serves you right. That's indeed observable on CPUs which > > > > > lack TSC_ADJUST. > > > > > >

On Tue, Sep 18, 2018 at 12:41:57PM +0200, Thomas Gleixner wrote: > On Tue, 18 Sep 2018, Thomas Gleixner wrote: > > On Tue, 18 Sep 2018, Thomas Gleixner wrote: > > > On Tue, 18 Sep 2018, Peter Zijlstra wrote: > > > > > Your memory serves you right. That's indeed observable on CPUs which > > > > > lack TSC_ADJUST. > > > > > >

On Tue, 18 Sep 2018, Thomas Gleixner wrote: > On Tue, 18 Sep 2018, Peter Zijlstra wrote: > > > Your memory serves you right. That's indeed observable on CPUs which > > > lack TSC_ADJUST. > > > > But, if the gtod code can observe this, then why doesn't the code that > > checks the sync? > > Because it depends where the involved CPUs are in the

On Tue, 18 Sep 2018, Thomas Gleixner wrote: > On Tue, 18 Sep 2018, Peter Zijlstra wrote: > > > Your memory serves you right. That's indeed observable on CPUs which > > > lack TSC_ADJUST. > > > > But, if the gtod code can observe this, then why doesn't the code that > > checks the sync? > > Because it depends where the involved CPUs are in the

Xenlinux uses a special architecture-dependent bit in the page table, called PG_arch_1 to indicate that a page is "foreign" (PG_foreign). It also apparently uses it to determine if a page is pinned (PG_pinned). Linux/ia64 (and apparently Linux/ppc and Linux/ppc64) use the PG_arch_1 bit for other purposes. On Linux/ia64, it is used to determine if the instruction cache needs to be

Migrate the last TSC values for more accurate timekeeping during live migration Signed-off-by: Dave Winchell <dwinchell@virtualiron.com> Signed-off-by: Ben Guthro <bguthro@virtualiron.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

Hi, I am trying to correlating performance issue in guest VM with the scheduling trace from Xentrace. User-mode application in guest VM periodically dump APIC ID and RDTSC into trace. I also start Xentrace in Dom0 during the same period. However, I notice that range of TSC values report both trace is completely disjointed. TSC values from Xentrace is always greater than what guest VM see, even

Thomas Gleixner <tglx at linutronix.de> writes: > On Tue, 14 Feb 2017, Vitaly Kuznetsov wrote: > >> Hi, >> >> while we're still waiting for a definitive ACK from Microsoft that the >> algorithm is good for SMP case (as we can't prevent the code in vdso from >> migrating between CPUs) I'd like to send v2 with some modifications to keep

Thomas Gleixner <tglx at linutronix.de> writes: > On Tue, 14 Feb 2017, Vitaly Kuznetsov wrote: > >> Hi, >> >> while we're still waiting for a definitive ACK from Microsoft that the >> algorithm is good for SMP case (as we can't prevent the code in vdso from >> migrating between CPUs) I'd like to send v2 with some modifications to keep