| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
| |
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
| |
notification. tasklet_schedule() contains a spinlock and is unsafe in
NMI context.
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
|
|
|
|
| |
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
|
|
|
|
|
|
|
|
|
| |
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.
|
|
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.
|