similar to: change hvm defaults for timer_mode and hpet?

> Date: Fri, 17 Feb 2012 12:06:05 +0000 > From: Ian Campbell <Ian.Campbell@citrix.com> > To: Qrux <qrux.qed@gmail.com> > Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> > Subject: Re: [Xen-devel] Xen domU Timekeeping (a.k.a TSC/HPET issues) > Message-ID: <1329480365.3131.50.camel@zakaz.uk.xensource.com> > Content-Type:

Is there any easy way in a shell script to find out the domid of "the domain I just created" with xm create? =================================== Thanks... for the memory I really could use more / My throughput's on the floor The balloon is flat / My swap disk's fat / I've OOM's in store Overcommitted so much (with apologies to the late great Bob Hope)

Folks, A new release candidate for 3.2.0 has just been checked into the xen-unstable tree. It''s available from staging and will be in the main tree when it has passed internal regression tests. Meanwhile, in preparation for 3.1.3, please let me know if there are any further patches from xen-unstable that should be backported into the 3.1 branch. You can pull the xen-3.1-testing.hg

Package: xen-3 Severity: important Tags: patch Cheers, Marco Sinhoreli -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.18.8-xen (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -------------- next part --------------

Windows SVVP tests requiring a HPET ACPI table is in my opinion not a valid reason to always expose that table - respective tests should be run with "hpet=1" in the guest config file. The problem here is that at least with qemu-traditional, which by default doesn''t appear to emulate a HPET, the advertising here can mislead an OS to believe that there actually is a usable HPET,

Hello, It looks like xen 4.1.2* has some problems with solaris 11 iso images too (s. further below log messages) hvm-solaris11.born2b3.net.cfg # --- kernel = ''/usr/lib64/xen-default/boot/hvmloader'' builder = ''hvm'' device_model= ''/usr/lib64/xen-4.1/bin/qemu-dm'' name = ''solaris11hvm.born2b3.net'' acpi =

On Thu, 30 Sep 2010 14:02:34 +0800, gang.wei@intel.com wrote: > I am the original developer of HPET broadcast code. > > First of all, to disable HPET broadcast, no additional patch is required. > Please simply add option "cpuidle=off" or "max_cstate=1" at xen cmdline in > /boot/grub/grub.conf. > > Second, I noticed that the issue just occur on

(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

Hello everyone, I grabbed xen-3.3.1 sources from the Mercurial repository (xen-3.3-testing.hg, changeset 475:1cf755387728, from Oct. 23, 2008) and built Xen from these sources on a 32-core (8 quad core Barcelona CPUs) SunFire machine, running an Ubuntu 8.04 (Hardyy Heron) distribution. Everything seemed to be going OK until I booted an HVM (also Ubuntu 8.04) domain. That domain boots normally but

I saw the presentation "Virtualization of Linux Servers" at OLS last month and it had some nice comparisons of Xen performance vs a lot of other virtualization/container technologies: http://ols.fedoraproject.org/OLS/Reprints-2008/camargos-reprint.pdf As always with benchmarks, there are questions to ask and points to quibble, but overall Xen looks quite good... except on Dbench. Has

I have an error in my dmesg system log about hpet not correctly enabling: hpet_acpi_add: no address or irqs in _CRS The same kernel without Xen enables it fine: hpet0: at MMIO 0xfed00000 (virtual 0xffffffffff5fe000), IRQs 2, 8, 31 hpet0: 3 32-bit timers, 25000000 Hz hpet_resources: 0xfed00000 is busy Do I have to pass an additional boot option? (ACPI is already enabled) or is there

The value of ACPI PM-Timer may be broken on save unless the timer mode is delay_for_missed_ticks. With other timer modes, vcpu->arch.hvm_vcpu.guest_time is always zero and the adjustment from its value is wrong. This patch fixes the saved value of ACPI PM-Timer: - don''t adjust the PM-Timer if vcpu->arch.hvm_vcpu.guest_time is zero. - consolidate calculations of PM-Timer to one

The attached patch adds the HPET description table to ACPI. -- Dexuan Signed-off-by: Dexuan Cui <dexuan.cui@intel.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

This follows Linux commit 39fe05e58c5e448601ce46e6b03900d5bf31c4b0, noticing that all this setup is pointless when ARAT support is there, and knowing that on SLED11''s native kernel it has actually caused S3 resume issues. A question would be whether HPET legacy interrupts should be forced off in this case (rather than leaving whatever came from firmware). Signed-off-by: Jan Beulich

Various versions of Linux under various circumstances select TSC as the primary clocksource for the kernel. This is especially true for uniprocessor kernels, but also in some cases for multiprocessor kernels. In most cases, this is because a processor bit (tsc_invariant? constant_tsc?) is passed through directly from the hardware via Xen and tested by the hvm guest and the result implies that

Greetings, I''m attempting to do gfx_passthru with the primary graphics adapter (03:00.0), passing it to a guest. I can unbind it from the host but when I fire up the guest OS my monitor loses signal from the graphics card and that''s that. The GFX card is dual DVI, I''ve tried both slots. Host is Linux 2.6.32.14-1.2.105.xendom0.fc12.x86_64, Guest is Windows 7. PC is an

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

When trying to use the GPL PV drivers with Windows 7 x64 (and testsigning turned on), I get a BSOD with a STOP 0x00000101 error. There''s also an error at the top that says "A clock interrupt was not received on a secondary processor within the allocated time interval." Is this STOP error related to the HPET or other timing adjustments for Xen? Any advice on things I should

I am trying to get a vm running on a different host. It fails to start with the error below. Both hosts are running the same software CentOS 5.4 and Xen 3.3.1 any clues as to why it fails would be appreciated. [2009-05-04 15:31:59 3933] DEBUG (XendDomainInfo:89) XendDomainInfo.create([''vm'', [''name'', ''agree-37''],

HPET intr-near-missing means if the current counter value is too close to the comparator value to be reprogrammed the expected HPET intr may be missing. Linux kernel uses a mininal 48-hpet-ticks(~3.5us) distance to workaround this, but personal observation showed there is still failure case while delta=0xba (~13.5us). So choosing 20us as the MIN_DELTA_NS should be helpful to prevent near-missing