aboutsummaryrefslogtreecommitdiffstats
path: root/xen/include/asm-x86/softirq.h
Commit message (Collapse)AuthorAgeFilesLines
* x86: avoid deadlock after a PCI SERR NMIDavid Vrabel2012-02-021-1/+2
| | | | | | | | | | | | | | If a PCI System Error (SERR) is asserted it causes an NMI. If this NMI occurs while the CPU is in printk() then Xen may deadlock as pci_serr_error() calls console_force_unlock() which screws up the console lock. printk() isn't safe to call from NMI context so defer the diagnostic message to a softirq. Signed-off-by: David Vrabel <david.vrabel@citrix.com> Tested-by: George Dunlap <george.dunlap@eu.citrix.com> Committed-by: Keir Fraser <keir@xen.org>
* x86: Core support for Intel MCA supportKeir Fraser2009-03-201-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Those patches based on AMD and SUN's MCA related jobs. We have latest rebase after SUN's latest improvements. We will have late following patches for recovery actions. This is a basic framework for Intel. Some implementation notes: 1) When error happens, if the error is fatal (pcc = 1) or can't be recovered (pcc = 0, yet no good recovery methods), for avoiding losing logs in DOM0, we will reset machine immediately. Most of MCA MSRs are sticky. After reboot, MCA polling mechanism will send vIRQ to DOM0 for logging. 2) When MCE# happens, all CPUs enter MCA context. The first CPU who read&clear the error MSR bank will be this MCE# owner. Necessary locks/synchronization will help to judge the owner and select most severe error. 3) For convenience, we will select the most offending CPU to do most of processing&recovery job. 4) MCE# happens, we will do three jobs: a. Send vIRQ to DOM0 for logging b. Send vMCE# to Impacted Guest (Currently Only inject to impacted DOM0) c. Guest vMCE MSR virtualization 5) Some further improvement/adds for newer CPUs might be done later a) Connection with recovery actions (cpu/memory online/offline) b) More software-recovery identification in severity_scan c) More refines and tests for HVM might be done when needed. This patch Enable basic MCA support For Intel Signed-off-by: Jiang, Yunhong<yunhong.jiang@intel.com> Signed-off-by: Ke, Liping <Liping.ke@intel.com>
* x86, hvm: Move return-to-guest timer and interrupt cranking logicKeir Fraser2008-10-231-1/+2
| | | | | | | | | | | | | | outside of IRQ-safe context. This allows us to safely take non-IRQ-safe spinlocks. The drawback is that {vmx,svm}_intr_assist() now races new event notifications delivered by IRQ or IPI. We close down this race by having vcpu_kick() send a dummy softirq -- this gets picked up in IRQ-sage context and will cause retry of *_intr_assist(). We avoid delivering the softirq where possible by avoiding it when we are running in the non-IRQ context of the VCPU to be kicked. Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
* x86: There are now two x86-specific softirqs.Keir Fraser2008-08-281-1/+1
| | | | Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
* x86: Signal softirq-context calibration with an actual first-classKeir Fraser2008-08-271-1/+2
| | | | | | | | | | softirq handle rather than kludging it with set_timer(). Should be faster and is definitely clearer. Also avoids us using set_timer() in IRQ context (which is currently broken but soon won't be). Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
* x86: Must use a softirq to defer dom0 NMIKeir Fraser2008-06-181-1/+3
| | | | | | | notification. tasklet_schedule() contains a spinlock and is unsafe in NMI context. Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
* [XEN] Arch-specific softirq definitions.kfraser@localhost.localdomain2006-11-301-0/+6
| | | | Signed-off-by: Alex Williamson <alex.williamson@hp.com>
* bitkeeper revision 1.982 (40d300456_XUbFFOMxRh4MjyB7AfJA)kaf24@scramble.cl.cam.ac.uk2004-06-181-17/+0
| | | | | | | | | Hacked the scheduler interfaces in Xen. We now have synchronous pause. Suspend/death VIRQs have gone away; replace by dom-controller msgs. Xen no longer knows about PS/2 keyboard/mouse; DOM0 can go straight at them.
* bitkeeper revision 1.952 (40c8935a3XSRdQfnx5RoO7XgaggvOQ)kaf24@scramble.cl.cam.ac.uk2004-06-101-0/+17
Towards x86_64 support. Merged a bunch of the existing x86_64 stuff back into a generic 'x86' architecture. Aim is to share as much as possible between 32- and 64-bit worlds.