similar to: [PATCH] Fix softlockup issue after vcpu hotplug

The softlockup watchdog is currently a nuisance in a virtual machine, since the whole system could have the CPU stolen from it for a long period of time. While it would be unlikely for a guest domain to be denied timer interrupts for over 10s, it could happen and any softlockup message would be completely spurious. Earlier I proposed that sched_clock() return time in unstolen nanoseconds, which

The softlockup watchdog is currently a nuisance in a virtual machine, since the whole system could have the CPU stolen from it for a long period of time. While it would be unlikely for a guest domain to be denied timer interrupts for over 10s, it could happen and any softlockup message would be completely spurious. Earlier I proposed that sched_clock() return time in unstolen nanoseconds, which

Hi Ingo, This series of patches implements a number of improvements to the softlockup watchdog and its users. They are: 1. Make the watchdog ignore stolen time When running under a hypervisor, the kernel may lose an arbitrary amount of time as "stolen time". This may cause the softlockup watchdog to trigger spruiously. Xen and VMI implement sched_clock() as measuring unstolen time,

Hi Ingo, This series of patches implements a number of improvements to the softlockup watchdog and its users. They are: 1. Make the watchdog ignore stolen time When running under a hypervisor, the kernel may lose an arbitrary amount of time as "stolen time". This may cause the softlockup watchdog to trigger spruiously. Xen and VMI implement sched_clock() as measuring unstolen time,

Here's couple of patches to improve the softlockup watchdog. The first changes the softlockup timer from using jiffies to sched_clock() as a timebase. Xen and VMI implement sched_clock() as counting unstolen time, so time stolen by the hypervisor won't cause the watchdog to bite. The second adds per-cpu enable flags for the watchdog timer. This allows the timer to be disabled when the

Here's couple of patches to improve the softlockup watchdog. The first changes the softlockup timer from using jiffies to sched_clock() as a timebase. Xen and VMI implement sched_clock() as counting unstolen time, so time stolen by the hypervisor won't cause the watchdog to bite. The second adds per-cpu enable flags for the watchdog timer. This allows the timer to be disabled when the

We have tested the latest xen on VT platform with Intel 915/E8500 chipset. Three platforms (32/PAE/32E) test all are based on SMP, It means that we boot up SMP guest OS in VMX. Here is the test summary: New issue ================================================ No new issue Issues List: ================================================ 1) IA32E/PAE: 32bit Vista RTM network doesn''t

BUG: soft lockup detected on CPU#0! Pid: 2213, comm: smbiod EIP: 0061:[<f4990f2e>] CPU: 0 EIP is at smbiod+0x116/0x16d [smbfs] EFLAGS: 00000246 Tainted: GF (2.6.16-xen-automount #1) EAX: 00000000 EBX: f4996400 ECX: f2c99f68 EDX: f2c98000 ESI: f2c98000 EDI: c06f5780 EBP: f2c99fb8 DS: 007b ES: 007b CR0: 8005003b CR2: b7f77000 CR3: 326e2000 CR4: 00000640

Add self pause ability, which is required by vcpu0/dom0 when running on a AP. This can''t be satisfied by existing interface, since the new flag also serves as a sync point. Signed-off-by Kevin Tian <kevin.tian@intel.com> diff -r d5315422dbc8 xen/common/domain.c --- a/xen/common/domain.c Mon May 14 18:35:31 2007 -0400 +++ b/xen/common/domain.c Mon May 14 20:21:04 2007 -0400 @@

Keir, It''s a resending patch for the timeout mechanism to deal with the shared interrupt issue for vt-d enabled hvm guest. We modify the patch following your comments last time and make some other small fix: 1) We don''t touch the locking around the hvm_dpci_eoi(). 2) Remove the HZ from the TIME_OUT_PERIOD macro which may confuse others. 3) Add some

Just saw such warnings like: ... (XEN) printk: 387824 messages suppressed. (XEN) seg_fixup.c:282: Taken fault at bad CS c000, IP 00003aab (XEN) seg_fixup.c:282: Taken fault at bad CS c000, IP 00003ab2 (XEN) seg_fixup.c:282: Taken fault at bad CS c000, IP 00003aab (XEN) seg_fixup.c:282: Taken fault at bad CS c000, IP 00003ab2 ... It only jumped out when switching to/off X-windows within dom0, and

Simplify paging_invlpg when flush is not required. New ''flush'' parameter is added to paging_invlpg, to allow caller assigning whether flush check is required. It''s wasteful to always validate shadow linear mapping if caller doesn''t check return value at all. Signed-off-by Kevin Tian <kevin.tian@intel.com> Thanks, Kevin

I tried latest xen and linux-xen staging tree, but failed to run HVM domain on x86-64 environment. domU creation is OK. However the weird thing is not HVM domain itself. Instead system crashed on dom0 context. I saw once with some stack dump that xen''s page fault handler is executed on a dom0''s stack which then causes nested page fault due to unable to fetch vcpu pointer.

Attached is a patch for shared interrupt between dom0 and HVM domain for vtd. Most of problem is caused by that we should inject interrupt to both domains and the physical interrupt deassertion then may be delayed by the device assigned to the HVM. The patch adds a timer, and the time out value is sufficient large to tolerant the delaying used to wait for the physical interrupt deassertion.

We seem to find an interesting bug, but not for sure. Each time before xen returns to hvm domain, it checks local_events_need_delivery to see whether any events pending and if yes, inject event by callback_irq into the virtual interrupt controller. However, the interesting point is, we never found any place, either in xen or in PV drivers, to clear evtchn_upcall_mask at any time. The initial

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

Hi, I find PV domin hung, When we take those steps 1, save PV domain 2, change system time of PV domain back 3, restore a PV domain or 1, migrate a PV domain from Machine A to Machine B 2, the system time of Machine B is slower than Machine A. the problem is wc_sec will be change when system-time chanaged in dom0 or restore in a

There''re basically two methods to enter a given C-state: legacy (hlt + I/O read), and native(using mwait). MWAIT is always preferred when both underlying CPU and OS support, which is a more efficient way to conduct C-state transition. Xen PM relies on Dom0 to parse ACPI Cx/Px information, which involves one step to notify BIOS about a set of capabilities supported by OSPM. One capability

Enable cpufreq support in Xen for AMD Operton processors by: 1) Allowing the PowerNow! driver in dom0 to write to the PowerNow! MSRs. 2) Adding the cpufreq notifier chain to time-xen.c in dom0. On a frequency change, a platform hypercall is performed to scale the frequency multiplier in the hypervisor. 3) Adding a platform hypercall to the hypervisor the scale the frequency multiplier and reset

F.Y.I >>> "Tian, Kevin" <kevin.tian@intel.com> 08.11.27. 11:50 >>>Sorry for a typo. I did mean domU instead of dom0. :-) The point here is that time_resume will sync to new system time and wall clock at restore, and thus pv guest should be able to continue... Xen system time is not wallclock time which just counts up from power up. As Keir points out, only its