similar to: [PATCH 2/4] x86/hpet: replace disabling of legacy broadcast

Linux up to now is not smart enough to properly clear the HPET when it boots, which is particularly a problem when a kdump attempt from running under Xen is being made. Linux itself added code to work around this to its shutdown paths quite some time ago, so let''s do something similar in Xen: Save the configuration register settings during boot, and restore them during shutdown. This

# HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1254298855 0 # Node ID 5215da46d60f95d57244e709cb3b189caffec50c # Parent 6472342c8ab0789b844714bcf557e9e5eeacca42 Disable HPET broadcast mode on kexec. Without this the new kernel cannot receive timer interrupts from the legacy sources. Hangs are observed in the second kernel''s "check_timer()"

xen/arch/x86/crash.c | 116 ++++++++++++++++++++++++++++++++++----- xen/arch/x86/machine_kexec.c | 19 ++++++ xen/arch/x86/x86_64/entry.S | 34 +++++++++++ xen/include/asm-x86/desc.h | 45 +++++++++++++++ xen/include/asm-x86/processor.h | 4 + 5 files changed, 203 insertions(+), 15 deletions(-) Experimentally, certain crash kernels will triple fault very early

From: Julien Grall <julien.grall@citrix.com> Move smp_call_function and on_selected_cpus to common code. Signed-off-by: Julien Grall <julien.grall@citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Keir Fraser <keir@xen.org> --- Changes in V2: - Add copyright header in xen/common/smp.c xen/arch/arm/gic.c | 3 ++ xen/arch/arm/smp.c

Add check on hpet existence which is removed accidentally in previous changeset (18790). Or else BAD PERIOD error can be seen. Signed-off-by Kevin Tian <kevin.tian@intel.com> diff -r ab0c1bdede53 xen/arch/x86/hpet.c --- a/xen/arch/x86/hpet.c Wed Nov 26 11:14:26 2008 +0000 +++ b/xen/arch/x86/hpet.c Wed Nov 26 19:22:03 2008 -0500 @@ -273,6 +273,8 @@ return hpet_rate;

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

Add suspend/resume to devices owned by Xen. Signed-off-by Ke Yu <ke.yu@intel.com> Signed-off-by Kevin Tian <kevin.tian@intel.com> diff -r 3ef0510e44d0 xen/arch/x86/apic.c --- a/xen/arch/x86/apic.c Tue May 08 10:21:23 2007 +0100 +++ b/xen/arch/x86/apic.c Mon May 14 15:05:28 2007 -0400 @@ -579,6 +579,95 @@ void __devinit setup_local_APIC(void) apic_pm_activate(); } +static

I have an old Dell 1950 that I've rescued from Linux and tossed a copy of -STABLE on it, but am seeing a constant 0.5 load average. With the system completely idle, and kern.eventtimer.timer=LACPI, the load drops to the expected value of zero. This feels like it should be an FAQ, but short of noting that the load is non-zero, is there a programatic way to determine if the event timer is

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

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

Due to recent changes in timer handling (specifically building hpet emulation on top of Xen system time and ensuring it is monotonic), I wonder if it now makes sense to: 1) change hvm default for hpet to 1 (was 0) 2) change hvm timer_mode default from 0 to 2 I encouraged adding the hvm hpet parameter and defaulting it to 0 because the virtual hpet was not reliable and many guests/versions

struct cpufreq_policy, including a cpumask_t member, gets copied in cpufreq_limit_change(), cpufreq_add_cpu(), set_cpufreq_gov(), and set_cpufreq_para(). Make the member a cpumask_var_t, thus reducing the amount of data needing copying (particularly with large NR_CPUS). Signed-off-by: Jan Beulich <jbeulich@suse.com> --- 2011-09-20.orig/xen/arch/x86/acpi/cpufreq/cpufreq.c 2011-10-12

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

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

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,

> 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:

In testing build patches for gcc 4.8 to allow darwin to have asan support, I ran across a defect in mach_override/mach_override.c... http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55289#c27 which was solved with the patch proposed by Alexander Potapenko in... http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55289#c29 Index: mach_override.c

The iommu is enabled by default when xen is booting and later disabled in iommu_setup() when no iommu is present. But under some circumstances iommu-code can be called before iommu_setup() is processed. If there is no iommu available xen crashes. This can happen for example when panic(...) is called that got introduced with patch "x86-64: detect processors subject to AMD erratum #121 and

Xen is crashing for me since version 4.1.3 during boot on a AMD machine. This happens since patch "x86-64: detect processors subject to AMD erratum #121 and refuse to boot." Instead of the actual panic-message from the patch the following stacktrace appears (i typed it down from screen, so it might contain typos) find_iommu_for_device amd_iommu_ioapic_update_ire timer_interrupt

Fixup patch, addressing Andrew's review feedback: Signed-off-by: Kent Overstreet <kmo at daterainc.com> --- include/linux/idr.h | 2 +- lib/idr.c | 38 +++++++++++++++++++++----------------- 2 files changed, 22 insertions(+), 18 deletions(-) diff --git a/include/linux/idr.h b/include/linux/idr.h index f0db12b..cdf39be 100644 --- a/include/linux/idr.h +++