KVM: PPC: Book3S HV: Handle guest-caused machine checks on POWER7 without panicking
Currently, if a machine check interrupt happens while we are in the
guest, we exit the guest and call the host's machine check handler,
which tends to cause the host to panic. Some machine checks can be
triggered by the guest; for example, if the guest creates two entries
in the SLB that map the same effective address, and then accesses that
effective address, the CPU will take a machine check interrupt.
To handle this better, when a machine check happens inside the guest,
we call a new function, kvmppc_realmode_machine_check(), while still in
real mode before exiting the guest. On POWER7, it handles the cases
that the guest can trigger, either by flushing and reloading the SLB,
or by flushing the TLB, and then it delivers the machine check interrupt
directly to the guest without going back to the host. On POWER7, the
OPAL firmware patches the machine check interrupt vector so that it
gets control first, and it leaves behind its analysis of the situation
in a structure pointed to by the opal_mc_evt field of the paca. The
kvmppc_realmode_machine_check() function looks at this, and if OPAL
reports that there was no error, or that it has handled the error, we
also go straight back to the guest with a machine check. We have to
deliver a machine check to the guest since the machine check interrupt
might have trashed valid values in SRR0/1.
If the machine check is one we can't handle in real mode, and one that
OPAL hasn't already handled, or on PPC970, we exit the guest and call
the host's machine check handler. We do this by jumping to the
machine_check_fwnmi label, rather than absolute address 0x200, because
we don't want to re-execute OPAL's handler on POWER7. On PPC970, the
two are equivalent because address 0x200 just contains a branch.
Then, if the host machine check handler decides that the system can
continue executing, kvmppc_handle_exit() delivers a machine check
interrupt to the guest -- once again to let the guest know that SRR0/1
have been modified.
Signed-off-by: Paul Mackerras <paulus@samba.org>
[agraf: fix checkpatch warnings]
Signed-off-by: Alexander Graf <agraf@suse.de>
2012-11-24 06:37:50 +08:00
|
|
|
/*
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
* it under the terms of the GNU General Public License, version 2, as
|
|
|
|
* published by the Free Software Foundation.
|
|
|
|
*
|
|
|
|
* Copyright 2012 Paul Mackerras, IBM Corp. <paulus@au1.ibm.com>
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/types.h>
|
|
|
|
#include <linux/string.h>
|
|
|
|
#include <linux/kvm.h>
|
|
|
|
#include <linux/kvm_host.h>
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <asm/opal.h>
|
2013-10-30 22:35:40 +08:00
|
|
|
#include <asm/mce.h>
|
KVM: PPC: Book3S HV: Fix TB corruption in guest exit path on HMI interrupt
When a guest is assigned to a core it converts the host Timebase (TB)
into guest TB by adding guest timebase offset before entering into
guest. During guest exit it restores the guest TB to host TB. This means
under certain conditions (Guest migration) host TB and guest TB can differ.
When we get an HMI for TB related issues the opal HMI handler would
try fixing errors and restore the correct host TB value. With no guest
running, we don't have any issues. But with guest running on the core
we run into TB corruption issues.
If we get an HMI while in the guest, the current HMI handler invokes opal
hmi handler before forcing guest to exit. The guest exit path subtracts
the guest TB offset from the current TB value which may have already
been restored with host value by opal hmi handler. This leads to incorrect
host and guest TB values.
With split-core, things become more complex. With split-core, TB also gets
split and each subcore gets its own TB register. When a hmi handler fixes
a TB error and restores the TB value, it affects all the TB values of
sibling subcores on the same core. On TB errors all the thread in the core
gets HMI. With existing code, the individual threads call opal hmi handle
independently which can easily throw TB out of sync if we have guest
running on subcores. Hence we will need to co-ordinate with all the
threads before making opal hmi handler call followed by TB resync.
This patch introduces a sibling subcore state structure (shared by all
threads in the core) in paca which holds information about whether sibling
subcores are in Guest mode or host mode. An array in_guest[] of size
MAX_SUBCORE_PER_CORE=4 is used to maintain the state of each subcore.
The subcore id is used as index into in_guest[] array. Only primary
thread entering/exiting the guest is responsible to set/unset its
designated array element.
On TB error, we get HMI interrupt on every thread on the core. Upon HMI,
this patch will now force guest to vacate the core/subcore. Primary
thread from each subcore will then turn off its respective bit
from the above bitmap during the guest exit path just after the
guest->host partition switch is complete.
All other threads that have just exited the guest OR were already in host
will wait until all other subcores clears their respective bit.
Once all the subcores turn off their respective bit, all threads will
will make call to opal hmi handler.
It is not necessary that opal hmi handler would resync the TB value for
every HMI interrupts. It would do so only for the HMI caused due to
TB errors. For rest, it would not touch TB value. Hence to make things
simpler, primary thread would call TB resync explicitly once for each
core immediately after opal hmi handler instead of subtracting guest
offset from TB. TB resync call will restore the TB with host value.
Thus we can be sure about the TB state.
One of the primary threads exiting the guest will take up the
responsibility of calling TB resync. It will use one of the top bits
(bit 63) from subcore state flags bitmap to make the decision. The first
primary thread (among the subcores) that is able to set the bit will
have to call the TB resync. Rest all other threads will wait until TB
resync is complete. Once TB resync is complete all threads will then
proceed.
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2016-05-15 12:14:26 +08:00
|
|
|
#include <asm/machdep.h>
|
|
|
|
#include <asm/cputhreads.h>
|
|
|
|
#include <asm/hmi.h>
|
2016-10-10 08:31:20 +08:00
|
|
|
#include <asm/asm-prototypes.h>
|
KVM: PPC: Book3S HV: Handle guest-caused machine checks on POWER7 without panicking
Currently, if a machine check interrupt happens while we are in the
guest, we exit the guest and call the host's machine check handler,
which tends to cause the host to panic. Some machine checks can be
triggered by the guest; for example, if the guest creates two entries
in the SLB that map the same effective address, and then accesses that
effective address, the CPU will take a machine check interrupt.
To handle this better, when a machine check happens inside the guest,
we call a new function, kvmppc_realmode_machine_check(), while still in
real mode before exiting the guest. On POWER7, it handles the cases
that the guest can trigger, either by flushing and reloading the SLB,
or by flushing the TLB, and then it delivers the machine check interrupt
directly to the guest without going back to the host. On POWER7, the
OPAL firmware patches the machine check interrupt vector so that it
gets control first, and it leaves behind its analysis of the situation
in a structure pointed to by the opal_mc_evt field of the paca. The
kvmppc_realmode_machine_check() function looks at this, and if OPAL
reports that there was no error, or that it has handled the error, we
also go straight back to the guest with a machine check. We have to
deliver a machine check to the guest since the machine check interrupt
might have trashed valid values in SRR0/1.
If the machine check is one we can't handle in real mode, and one that
OPAL hasn't already handled, or on PPC970, we exit the guest and call
the host's machine check handler. We do this by jumping to the
machine_check_fwnmi label, rather than absolute address 0x200, because
we don't want to re-execute OPAL's handler on POWER7. On PPC970, the
two are equivalent because address 0x200 just contains a branch.
Then, if the host machine check handler decides that the system can
continue executing, kvmppc_handle_exit() delivers a machine check
interrupt to the guest -- once again to let the guest know that SRR0/1
have been modified.
Signed-off-by: Paul Mackerras <paulus@samba.org>
[agraf: fix checkpatch warnings]
Signed-off-by: Alexander Graf <agraf@suse.de>
2012-11-24 06:37:50 +08:00
|
|
|
|
|
|
|
/* SRR1 bits for machine check on POWER7 */
|
|
|
|
#define SRR1_MC_LDSTERR (1ul << (63-42))
|
|
|
|
#define SRR1_MC_IFETCH_SH (63-45)
|
|
|
|
#define SRR1_MC_IFETCH_MASK 0x7
|
|
|
|
#define SRR1_MC_IFETCH_SLBPAR 2 /* SLB parity error */
|
|
|
|
#define SRR1_MC_IFETCH_SLBMULTI 3 /* SLB multi-hit */
|
|
|
|
#define SRR1_MC_IFETCH_SLBPARMULTI 4 /* SLB parity + multi-hit */
|
|
|
|
#define SRR1_MC_IFETCH_TLBMULTI 5 /* I-TLB multi-hit */
|
|
|
|
|
|
|
|
/* DSISR bits for machine check on POWER7 */
|
|
|
|
#define DSISR_MC_DERAT_MULTI 0x800 /* D-ERAT multi-hit */
|
|
|
|
#define DSISR_MC_TLB_MULTI 0x400 /* D-TLB multi-hit */
|
|
|
|
#define DSISR_MC_SLB_PARITY 0x100 /* SLB parity error */
|
|
|
|
#define DSISR_MC_SLB_MULTI 0x080 /* SLB multi-hit */
|
|
|
|
#define DSISR_MC_SLB_PARMULTI 0x040 /* SLB parity + multi-hit */
|
|
|
|
|
|
|
|
/* POWER7 SLB flush and reload */
|
|
|
|
static void reload_slb(struct kvm_vcpu *vcpu)
|
|
|
|
{
|
|
|
|
struct slb_shadow *slb;
|
|
|
|
unsigned long i, n;
|
|
|
|
|
|
|
|
/* First clear out SLB */
|
|
|
|
asm volatile("slbmte %0,%0; slbia" : : "r" (0));
|
|
|
|
|
|
|
|
/* Do they have an SLB shadow buffer registered? */
|
|
|
|
slb = vcpu->arch.slb_shadow.pinned_addr;
|
|
|
|
if (!slb)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* Sanity check */
|
2014-06-11 16:34:19 +08:00
|
|
|
n = min_t(u32, be32_to_cpu(slb->persistent), SLB_MIN_SIZE);
|
KVM: PPC: Book3S HV: Handle guest-caused machine checks on POWER7 without panicking
Currently, if a machine check interrupt happens while we are in the
guest, we exit the guest and call the host's machine check handler,
which tends to cause the host to panic. Some machine checks can be
triggered by the guest; for example, if the guest creates two entries
in the SLB that map the same effective address, and then accesses that
effective address, the CPU will take a machine check interrupt.
To handle this better, when a machine check happens inside the guest,
we call a new function, kvmppc_realmode_machine_check(), while still in
real mode before exiting the guest. On POWER7, it handles the cases
that the guest can trigger, either by flushing and reloading the SLB,
or by flushing the TLB, and then it delivers the machine check interrupt
directly to the guest without going back to the host. On POWER7, the
OPAL firmware patches the machine check interrupt vector so that it
gets control first, and it leaves behind its analysis of the situation
in a structure pointed to by the opal_mc_evt field of the paca. The
kvmppc_realmode_machine_check() function looks at this, and if OPAL
reports that there was no error, or that it has handled the error, we
also go straight back to the guest with a machine check. We have to
deliver a machine check to the guest since the machine check interrupt
might have trashed valid values in SRR0/1.
If the machine check is one we can't handle in real mode, and one that
OPAL hasn't already handled, or on PPC970, we exit the guest and call
the host's machine check handler. We do this by jumping to the
machine_check_fwnmi label, rather than absolute address 0x200, because
we don't want to re-execute OPAL's handler on POWER7. On PPC970, the
two are equivalent because address 0x200 just contains a branch.
Then, if the host machine check handler decides that the system can
continue executing, kvmppc_handle_exit() delivers a machine check
interrupt to the guest -- once again to let the guest know that SRR0/1
have been modified.
Signed-off-by: Paul Mackerras <paulus@samba.org>
[agraf: fix checkpatch warnings]
Signed-off-by: Alexander Graf <agraf@suse.de>
2012-11-24 06:37:50 +08:00
|
|
|
if ((void *) &slb->save_area[n] > vcpu->arch.slb_shadow.pinned_end)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* Load up the SLB from that */
|
|
|
|
for (i = 0; i < n; ++i) {
|
2014-06-11 16:34:19 +08:00
|
|
|
unsigned long rb = be64_to_cpu(slb->save_area[i].esid);
|
|
|
|
unsigned long rs = be64_to_cpu(slb->save_area[i].vsid);
|
KVM: PPC: Book3S HV: Handle guest-caused machine checks on POWER7 without panicking
Currently, if a machine check interrupt happens while we are in the
guest, we exit the guest and call the host's machine check handler,
which tends to cause the host to panic. Some machine checks can be
triggered by the guest; for example, if the guest creates two entries
in the SLB that map the same effective address, and then accesses that
effective address, the CPU will take a machine check interrupt.
To handle this better, when a machine check happens inside the guest,
we call a new function, kvmppc_realmode_machine_check(), while still in
real mode before exiting the guest. On POWER7, it handles the cases
that the guest can trigger, either by flushing and reloading the SLB,
or by flushing the TLB, and then it delivers the machine check interrupt
directly to the guest without going back to the host. On POWER7, the
OPAL firmware patches the machine check interrupt vector so that it
gets control first, and it leaves behind its analysis of the situation
in a structure pointed to by the opal_mc_evt field of the paca. The
kvmppc_realmode_machine_check() function looks at this, and if OPAL
reports that there was no error, or that it has handled the error, we
also go straight back to the guest with a machine check. We have to
deliver a machine check to the guest since the machine check interrupt
might have trashed valid values in SRR0/1.
If the machine check is one we can't handle in real mode, and one that
OPAL hasn't already handled, or on PPC970, we exit the guest and call
the host's machine check handler. We do this by jumping to the
machine_check_fwnmi label, rather than absolute address 0x200, because
we don't want to re-execute OPAL's handler on POWER7. On PPC970, the
two are equivalent because address 0x200 just contains a branch.
Then, if the host machine check handler decides that the system can
continue executing, kvmppc_handle_exit() delivers a machine check
interrupt to the guest -- once again to let the guest know that SRR0/1
have been modified.
Signed-off-by: Paul Mackerras <paulus@samba.org>
[agraf: fix checkpatch warnings]
Signed-off-by: Alexander Graf <agraf@suse.de>
2012-11-24 06:37:50 +08:00
|
|
|
|
|
|
|
rb = (rb & ~0xFFFul) | i; /* insert entry number */
|
|
|
|
asm volatile("slbmte %0,%1" : : "r" (rs), "r" (rb));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* On POWER7, see if we can handle a machine check that occurred inside
|
|
|
|
* the guest in real mode, without switching to the host partition.
|
|
|
|
*
|
|
|
|
* Returns: 0 => exit guest, 1 => deliver machine check to guest
|
|
|
|
*/
|
|
|
|
static long kvmppc_realmode_mc_power7(struct kvm_vcpu *vcpu)
|
|
|
|
{
|
|
|
|
unsigned long srr1 = vcpu->arch.shregs.msr;
|
2013-10-30 22:35:40 +08:00
|
|
|
struct machine_check_event mce_evt;
|
KVM: PPC: Book3S HV: Handle guest-caused machine checks on POWER7 without panicking
Currently, if a machine check interrupt happens while we are in the
guest, we exit the guest and call the host's machine check handler,
which tends to cause the host to panic. Some machine checks can be
triggered by the guest; for example, if the guest creates two entries
in the SLB that map the same effective address, and then accesses that
effective address, the CPU will take a machine check interrupt.
To handle this better, when a machine check happens inside the guest,
we call a new function, kvmppc_realmode_machine_check(), while still in
real mode before exiting the guest. On POWER7, it handles the cases
that the guest can trigger, either by flushing and reloading the SLB,
or by flushing the TLB, and then it delivers the machine check interrupt
directly to the guest without going back to the host. On POWER7, the
OPAL firmware patches the machine check interrupt vector so that it
gets control first, and it leaves behind its analysis of the situation
in a structure pointed to by the opal_mc_evt field of the paca. The
kvmppc_realmode_machine_check() function looks at this, and if OPAL
reports that there was no error, or that it has handled the error, we
also go straight back to the guest with a machine check. We have to
deliver a machine check to the guest since the machine check interrupt
might have trashed valid values in SRR0/1.
If the machine check is one we can't handle in real mode, and one that
OPAL hasn't already handled, or on PPC970, we exit the guest and call
the host's machine check handler. We do this by jumping to the
machine_check_fwnmi label, rather than absolute address 0x200, because
we don't want to re-execute OPAL's handler on POWER7. On PPC970, the
two are equivalent because address 0x200 just contains a branch.
Then, if the host machine check handler decides that the system can
continue executing, kvmppc_handle_exit() delivers a machine check
interrupt to the guest -- once again to let the guest know that SRR0/1
have been modified.
Signed-off-by: Paul Mackerras <paulus@samba.org>
[agraf: fix checkpatch warnings]
Signed-off-by: Alexander Graf <agraf@suse.de>
2012-11-24 06:37:50 +08:00
|
|
|
long handled = 1;
|
|
|
|
|
|
|
|
if (srr1 & SRR1_MC_LDSTERR) {
|
|
|
|
/* error on load/store */
|
|
|
|
unsigned long dsisr = vcpu->arch.shregs.dsisr;
|
|
|
|
|
|
|
|
if (dsisr & (DSISR_MC_SLB_PARMULTI | DSISR_MC_SLB_MULTI |
|
|
|
|
DSISR_MC_SLB_PARITY | DSISR_MC_DERAT_MULTI)) {
|
|
|
|
/* flush and reload SLB; flushes D-ERAT too */
|
|
|
|
reload_slb(vcpu);
|
|
|
|
dsisr &= ~(DSISR_MC_SLB_PARMULTI | DSISR_MC_SLB_MULTI |
|
|
|
|
DSISR_MC_SLB_PARITY | DSISR_MC_DERAT_MULTI);
|
|
|
|
}
|
|
|
|
if (dsisr & DSISR_MC_TLB_MULTI) {
|
2013-10-30 22:34:56 +08:00
|
|
|
if (cur_cpu_spec && cur_cpu_spec->flush_tlb)
|
2014-12-19 11:11:05 +08:00
|
|
|
cur_cpu_spec->flush_tlb(TLB_INVAL_SCOPE_LPID);
|
KVM: PPC: Book3S HV: Handle guest-caused machine checks on POWER7 without panicking
Currently, if a machine check interrupt happens while we are in the
guest, we exit the guest and call the host's machine check handler,
which tends to cause the host to panic. Some machine checks can be
triggered by the guest; for example, if the guest creates two entries
in the SLB that map the same effective address, and then accesses that
effective address, the CPU will take a machine check interrupt.
To handle this better, when a machine check happens inside the guest,
we call a new function, kvmppc_realmode_machine_check(), while still in
real mode before exiting the guest. On POWER7, it handles the cases
that the guest can trigger, either by flushing and reloading the SLB,
or by flushing the TLB, and then it delivers the machine check interrupt
directly to the guest without going back to the host. On POWER7, the
OPAL firmware patches the machine check interrupt vector so that it
gets control first, and it leaves behind its analysis of the situation
in a structure pointed to by the opal_mc_evt field of the paca. The
kvmppc_realmode_machine_check() function looks at this, and if OPAL
reports that there was no error, or that it has handled the error, we
also go straight back to the guest with a machine check. We have to
deliver a machine check to the guest since the machine check interrupt
might have trashed valid values in SRR0/1.
If the machine check is one we can't handle in real mode, and one that
OPAL hasn't already handled, or on PPC970, we exit the guest and call
the host's machine check handler. We do this by jumping to the
machine_check_fwnmi label, rather than absolute address 0x200, because
we don't want to re-execute OPAL's handler on POWER7. On PPC970, the
two are equivalent because address 0x200 just contains a branch.
Then, if the host machine check handler decides that the system can
continue executing, kvmppc_handle_exit() delivers a machine check
interrupt to the guest -- once again to let the guest know that SRR0/1
have been modified.
Signed-off-by: Paul Mackerras <paulus@samba.org>
[agraf: fix checkpatch warnings]
Signed-off-by: Alexander Graf <agraf@suse.de>
2012-11-24 06:37:50 +08:00
|
|
|
dsisr &= ~DSISR_MC_TLB_MULTI;
|
|
|
|
}
|
|
|
|
/* Any other errors we don't understand? */
|
|
|
|
if (dsisr & 0xffffffffUL)
|
|
|
|
handled = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
switch ((srr1 >> SRR1_MC_IFETCH_SH) & SRR1_MC_IFETCH_MASK) {
|
|
|
|
case 0:
|
|
|
|
break;
|
|
|
|
case SRR1_MC_IFETCH_SLBPAR:
|
|
|
|
case SRR1_MC_IFETCH_SLBMULTI:
|
|
|
|
case SRR1_MC_IFETCH_SLBPARMULTI:
|
|
|
|
reload_slb(vcpu);
|
|
|
|
break;
|
|
|
|
case SRR1_MC_IFETCH_TLBMULTI:
|
2013-10-30 22:34:56 +08:00
|
|
|
if (cur_cpu_spec && cur_cpu_spec->flush_tlb)
|
2014-12-19 11:11:05 +08:00
|
|
|
cur_cpu_spec->flush_tlb(TLB_INVAL_SCOPE_LPID);
|
KVM: PPC: Book3S HV: Handle guest-caused machine checks on POWER7 without panicking
Currently, if a machine check interrupt happens while we are in the
guest, we exit the guest and call the host's machine check handler,
which tends to cause the host to panic. Some machine checks can be
triggered by the guest; for example, if the guest creates two entries
in the SLB that map the same effective address, and then accesses that
effective address, the CPU will take a machine check interrupt.
To handle this better, when a machine check happens inside the guest,
we call a new function, kvmppc_realmode_machine_check(), while still in
real mode before exiting the guest. On POWER7, it handles the cases
that the guest can trigger, either by flushing and reloading the SLB,
or by flushing the TLB, and then it delivers the machine check interrupt
directly to the guest without going back to the host. On POWER7, the
OPAL firmware patches the machine check interrupt vector so that it
gets control first, and it leaves behind its analysis of the situation
in a structure pointed to by the opal_mc_evt field of the paca. The
kvmppc_realmode_machine_check() function looks at this, and if OPAL
reports that there was no error, or that it has handled the error, we
also go straight back to the guest with a machine check. We have to
deliver a machine check to the guest since the machine check interrupt
might have trashed valid values in SRR0/1.
If the machine check is one we can't handle in real mode, and one that
OPAL hasn't already handled, or on PPC970, we exit the guest and call
the host's machine check handler. We do this by jumping to the
machine_check_fwnmi label, rather than absolute address 0x200, because
we don't want to re-execute OPAL's handler on POWER7. On PPC970, the
two are equivalent because address 0x200 just contains a branch.
Then, if the host machine check handler decides that the system can
continue executing, kvmppc_handle_exit() delivers a machine check
interrupt to the guest -- once again to let the guest know that SRR0/1
have been modified.
Signed-off-by: Paul Mackerras <paulus@samba.org>
[agraf: fix checkpatch warnings]
Signed-off-by: Alexander Graf <agraf@suse.de>
2012-11-24 06:37:50 +08:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
handled = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2013-10-30 22:35:40 +08:00
|
|
|
* See if we have already handled the condition in the linux host.
|
|
|
|
* We assume that if the condition is recovered then linux host
|
KVM: PPC: Book3S HV: Handle guest-caused machine checks on POWER7 without panicking
Currently, if a machine check interrupt happens while we are in the
guest, we exit the guest and call the host's machine check handler,
which tends to cause the host to panic. Some machine checks can be
triggered by the guest; for example, if the guest creates two entries
in the SLB that map the same effective address, and then accesses that
effective address, the CPU will take a machine check interrupt.
To handle this better, when a machine check happens inside the guest,
we call a new function, kvmppc_realmode_machine_check(), while still in
real mode before exiting the guest. On POWER7, it handles the cases
that the guest can trigger, either by flushing and reloading the SLB,
or by flushing the TLB, and then it delivers the machine check interrupt
directly to the guest without going back to the host. On POWER7, the
OPAL firmware patches the machine check interrupt vector so that it
gets control first, and it leaves behind its analysis of the situation
in a structure pointed to by the opal_mc_evt field of the paca. The
kvmppc_realmode_machine_check() function looks at this, and if OPAL
reports that there was no error, or that it has handled the error, we
also go straight back to the guest with a machine check. We have to
deliver a machine check to the guest since the machine check interrupt
might have trashed valid values in SRR0/1.
If the machine check is one we can't handle in real mode, and one that
OPAL hasn't already handled, or on PPC970, we exit the guest and call
the host's machine check handler. We do this by jumping to the
machine_check_fwnmi label, rather than absolute address 0x200, because
we don't want to re-execute OPAL's handler on POWER7. On PPC970, the
two are equivalent because address 0x200 just contains a branch.
Then, if the host machine check handler decides that the system can
continue executing, kvmppc_handle_exit() delivers a machine check
interrupt to the guest -- once again to let the guest know that SRR0/1
have been modified.
Signed-off-by: Paul Mackerras <paulus@samba.org>
[agraf: fix checkpatch warnings]
Signed-off-by: Alexander Graf <agraf@suse.de>
2012-11-24 06:37:50 +08:00
|
|
|
* will have generated an error log event that we will pick
|
|
|
|
* up and log later.
|
2014-06-11 16:48:21 +08:00
|
|
|
* Don't release mce event now. We will queue up the event so that
|
|
|
|
* we can log the MCE event info on host console.
|
KVM: PPC: Book3S HV: Handle guest-caused machine checks on POWER7 without panicking
Currently, if a machine check interrupt happens while we are in the
guest, we exit the guest and call the host's machine check handler,
which tends to cause the host to panic. Some machine checks can be
triggered by the guest; for example, if the guest creates two entries
in the SLB that map the same effective address, and then accesses that
effective address, the CPU will take a machine check interrupt.
To handle this better, when a machine check happens inside the guest,
we call a new function, kvmppc_realmode_machine_check(), while still in
real mode before exiting the guest. On POWER7, it handles the cases
that the guest can trigger, either by flushing and reloading the SLB,
or by flushing the TLB, and then it delivers the machine check interrupt
directly to the guest without going back to the host. On POWER7, the
OPAL firmware patches the machine check interrupt vector so that it
gets control first, and it leaves behind its analysis of the situation
in a structure pointed to by the opal_mc_evt field of the paca. The
kvmppc_realmode_machine_check() function looks at this, and if OPAL
reports that there was no error, or that it has handled the error, we
also go straight back to the guest with a machine check. We have to
deliver a machine check to the guest since the machine check interrupt
might have trashed valid values in SRR0/1.
If the machine check is one we can't handle in real mode, and one that
OPAL hasn't already handled, or on PPC970, we exit the guest and call
the host's machine check handler. We do this by jumping to the
machine_check_fwnmi label, rather than absolute address 0x200, because
we don't want to re-execute OPAL's handler on POWER7. On PPC970, the
two are equivalent because address 0x200 just contains a branch.
Then, if the host machine check handler decides that the system can
continue executing, kvmppc_handle_exit() delivers a machine check
interrupt to the guest -- once again to let the guest know that SRR0/1
have been modified.
Signed-off-by: Paul Mackerras <paulus@samba.org>
[agraf: fix checkpatch warnings]
Signed-off-by: Alexander Graf <agraf@suse.de>
2012-11-24 06:37:50 +08:00
|
|
|
*/
|
2013-10-30 22:35:40 +08:00
|
|
|
if (!get_mce_event(&mce_evt, MCE_EVENT_DONTRELEASE))
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
if (mce_evt.version == MCE_V1 &&
|
|
|
|
(mce_evt.severity == MCE_SEV_NO_ERROR ||
|
|
|
|
mce_evt.disposition == MCE_DISPOSITION_RECOVERED))
|
KVM: PPC: Book3S HV: Handle guest-caused machine checks on POWER7 without panicking
Currently, if a machine check interrupt happens while we are in the
guest, we exit the guest and call the host's machine check handler,
which tends to cause the host to panic. Some machine checks can be
triggered by the guest; for example, if the guest creates two entries
in the SLB that map the same effective address, and then accesses that
effective address, the CPU will take a machine check interrupt.
To handle this better, when a machine check happens inside the guest,
we call a new function, kvmppc_realmode_machine_check(), while still in
real mode before exiting the guest. On POWER7, it handles the cases
that the guest can trigger, either by flushing and reloading the SLB,
or by flushing the TLB, and then it delivers the machine check interrupt
directly to the guest without going back to the host. On POWER7, the
OPAL firmware patches the machine check interrupt vector so that it
gets control first, and it leaves behind its analysis of the situation
in a structure pointed to by the opal_mc_evt field of the paca. The
kvmppc_realmode_machine_check() function looks at this, and if OPAL
reports that there was no error, or that it has handled the error, we
also go straight back to the guest with a machine check. We have to
deliver a machine check to the guest since the machine check interrupt
might have trashed valid values in SRR0/1.
If the machine check is one we can't handle in real mode, and one that
OPAL hasn't already handled, or on PPC970, we exit the guest and call
the host's machine check handler. We do this by jumping to the
machine_check_fwnmi label, rather than absolute address 0x200, because
we don't want to re-execute OPAL's handler on POWER7. On PPC970, the
two are equivalent because address 0x200 just contains a branch.
Then, if the host machine check handler decides that the system can
continue executing, kvmppc_handle_exit() delivers a machine check
interrupt to the guest -- once again to let the guest know that SRR0/1
have been modified.
Signed-off-by: Paul Mackerras <paulus@samba.org>
[agraf: fix checkpatch warnings]
Signed-off-by: Alexander Graf <agraf@suse.de>
2012-11-24 06:37:50 +08:00
|
|
|
handled = 1;
|
|
|
|
|
2013-10-30 22:35:40 +08:00
|
|
|
out:
|
|
|
|
/*
|
2014-06-11 16:48:21 +08:00
|
|
|
* We are now going enter guest either through machine check
|
|
|
|
* interrupt (for unhandled errors) or will continue from
|
|
|
|
* current HSRR0 (for handled errors) in guest. Hence
|
|
|
|
* queue up the event so that we can log it from host console later.
|
2013-10-30 22:35:40 +08:00
|
|
|
*/
|
2014-06-11 16:48:21 +08:00
|
|
|
machine_check_queue_event();
|
KVM: PPC: Book3S HV: Handle guest-caused machine checks on POWER7 without panicking
Currently, if a machine check interrupt happens while we are in the
guest, we exit the guest and call the host's machine check handler,
which tends to cause the host to panic. Some machine checks can be
triggered by the guest; for example, if the guest creates two entries
in the SLB that map the same effective address, and then accesses that
effective address, the CPU will take a machine check interrupt.
To handle this better, when a machine check happens inside the guest,
we call a new function, kvmppc_realmode_machine_check(), while still in
real mode before exiting the guest. On POWER7, it handles the cases
that the guest can trigger, either by flushing and reloading the SLB,
or by flushing the TLB, and then it delivers the machine check interrupt
directly to the guest without going back to the host. On POWER7, the
OPAL firmware patches the machine check interrupt vector so that it
gets control first, and it leaves behind its analysis of the situation
in a structure pointed to by the opal_mc_evt field of the paca. The
kvmppc_realmode_machine_check() function looks at this, and if OPAL
reports that there was no error, or that it has handled the error, we
also go straight back to the guest with a machine check. We have to
deliver a machine check to the guest since the machine check interrupt
might have trashed valid values in SRR0/1.
If the machine check is one we can't handle in real mode, and one that
OPAL hasn't already handled, or on PPC970, we exit the guest and call
the host's machine check handler. We do this by jumping to the
machine_check_fwnmi label, rather than absolute address 0x200, because
we don't want to re-execute OPAL's handler on POWER7. On PPC970, the
two are equivalent because address 0x200 just contains a branch.
Then, if the host machine check handler decides that the system can
continue executing, kvmppc_handle_exit() delivers a machine check
interrupt to the guest -- once again to let the guest know that SRR0/1
have been modified.
Signed-off-by: Paul Mackerras <paulus@samba.org>
[agraf: fix checkpatch warnings]
Signed-off-by: Alexander Graf <agraf@suse.de>
2012-11-24 06:37:50 +08:00
|
|
|
|
|
|
|
return handled;
|
|
|
|
}
|
|
|
|
|
|
|
|
long kvmppc_realmode_machine_check(struct kvm_vcpu *vcpu)
|
|
|
|
{
|
2014-12-03 10:30:38 +08:00
|
|
|
return kvmppc_realmode_mc_power7(vcpu);
|
KVM: PPC: Book3S HV: Handle guest-caused machine checks on POWER7 without panicking
Currently, if a machine check interrupt happens while we are in the
guest, we exit the guest and call the host's machine check handler,
which tends to cause the host to panic. Some machine checks can be
triggered by the guest; for example, if the guest creates two entries
in the SLB that map the same effective address, and then accesses that
effective address, the CPU will take a machine check interrupt.
To handle this better, when a machine check happens inside the guest,
we call a new function, kvmppc_realmode_machine_check(), while still in
real mode before exiting the guest. On POWER7, it handles the cases
that the guest can trigger, either by flushing and reloading the SLB,
or by flushing the TLB, and then it delivers the machine check interrupt
directly to the guest without going back to the host. On POWER7, the
OPAL firmware patches the machine check interrupt vector so that it
gets control first, and it leaves behind its analysis of the situation
in a structure pointed to by the opal_mc_evt field of the paca. The
kvmppc_realmode_machine_check() function looks at this, and if OPAL
reports that there was no error, or that it has handled the error, we
also go straight back to the guest with a machine check. We have to
deliver a machine check to the guest since the machine check interrupt
might have trashed valid values in SRR0/1.
If the machine check is one we can't handle in real mode, and one that
OPAL hasn't already handled, or on PPC970, we exit the guest and call
the host's machine check handler. We do this by jumping to the
machine_check_fwnmi label, rather than absolute address 0x200, because
we don't want to re-execute OPAL's handler on POWER7. On PPC970, the
two are equivalent because address 0x200 just contains a branch.
Then, if the host machine check handler decides that the system can
continue executing, kvmppc_handle_exit() delivers a machine check
interrupt to the guest -- once again to let the guest know that SRR0/1
have been modified.
Signed-off-by: Paul Mackerras <paulus@samba.org>
[agraf: fix checkpatch warnings]
Signed-off-by: Alexander Graf <agraf@suse.de>
2012-11-24 06:37:50 +08:00
|
|
|
}
|
KVM: PPC: Book3S HV: Fix TB corruption in guest exit path on HMI interrupt
When a guest is assigned to a core it converts the host Timebase (TB)
into guest TB by adding guest timebase offset before entering into
guest. During guest exit it restores the guest TB to host TB. This means
under certain conditions (Guest migration) host TB and guest TB can differ.
When we get an HMI for TB related issues the opal HMI handler would
try fixing errors and restore the correct host TB value. With no guest
running, we don't have any issues. But with guest running on the core
we run into TB corruption issues.
If we get an HMI while in the guest, the current HMI handler invokes opal
hmi handler before forcing guest to exit. The guest exit path subtracts
the guest TB offset from the current TB value which may have already
been restored with host value by opal hmi handler. This leads to incorrect
host and guest TB values.
With split-core, things become more complex. With split-core, TB also gets
split and each subcore gets its own TB register. When a hmi handler fixes
a TB error and restores the TB value, it affects all the TB values of
sibling subcores on the same core. On TB errors all the thread in the core
gets HMI. With existing code, the individual threads call opal hmi handle
independently which can easily throw TB out of sync if we have guest
running on subcores. Hence we will need to co-ordinate with all the
threads before making opal hmi handler call followed by TB resync.
This patch introduces a sibling subcore state structure (shared by all
threads in the core) in paca which holds information about whether sibling
subcores are in Guest mode or host mode. An array in_guest[] of size
MAX_SUBCORE_PER_CORE=4 is used to maintain the state of each subcore.
The subcore id is used as index into in_guest[] array. Only primary
thread entering/exiting the guest is responsible to set/unset its
designated array element.
On TB error, we get HMI interrupt on every thread on the core. Upon HMI,
this patch will now force guest to vacate the core/subcore. Primary
thread from each subcore will then turn off its respective bit
from the above bitmap during the guest exit path just after the
guest->host partition switch is complete.
All other threads that have just exited the guest OR were already in host
will wait until all other subcores clears their respective bit.
Once all the subcores turn off their respective bit, all threads will
will make call to opal hmi handler.
It is not necessary that opal hmi handler would resync the TB value for
every HMI interrupts. It would do so only for the HMI caused due to
TB errors. For rest, it would not touch TB value. Hence to make things
simpler, primary thread would call TB resync explicitly once for each
core immediately after opal hmi handler instead of subtracting guest
offset from TB. TB resync call will restore the TB with host value.
Thus we can be sure about the TB state.
One of the primary threads exiting the guest will take up the
responsibility of calling TB resync. It will use one of the top bits
(bit 63) from subcore state flags bitmap to make the decision. The first
primary thread (among the subcores) that is able to set the bit will
have to call the TB resync. Rest all other threads will wait until TB
resync is complete. Once TB resync is complete all threads will then
proceed.
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2016-05-15 12:14:26 +08:00
|
|
|
|
|
|
|
/* Check if dynamic split is in force and return subcore size accordingly. */
|
|
|
|
static inline int kvmppc_cur_subcore_size(void)
|
|
|
|
{
|
|
|
|
if (local_paca->kvm_hstate.kvm_split_mode)
|
|
|
|
return local_paca->kvm_hstate.kvm_split_mode->subcore_size;
|
|
|
|
|
|
|
|
return threads_per_subcore;
|
|
|
|
}
|
|
|
|
|
|
|
|
void kvmppc_subcore_enter_guest(void)
|
|
|
|
{
|
|
|
|
int thread_id, subcore_id;
|
|
|
|
|
|
|
|
thread_id = cpu_thread_in_core(local_paca->paca_index);
|
|
|
|
subcore_id = thread_id / kvmppc_cur_subcore_size();
|
|
|
|
|
|
|
|
local_paca->sibling_subcore_state->in_guest[subcore_id] = 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
void kvmppc_subcore_exit_guest(void)
|
|
|
|
{
|
|
|
|
int thread_id, subcore_id;
|
|
|
|
|
|
|
|
thread_id = cpu_thread_in_core(local_paca->paca_index);
|
|
|
|
subcore_id = thread_id / kvmppc_cur_subcore_size();
|
|
|
|
|
|
|
|
local_paca->sibling_subcore_state->in_guest[subcore_id] = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool kvmppc_tb_resync_required(void)
|
|
|
|
{
|
|
|
|
if (test_and_set_bit(CORE_TB_RESYNC_REQ_BIT,
|
|
|
|
&local_paca->sibling_subcore_state->flags))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void kvmppc_tb_resync_done(void)
|
|
|
|
{
|
|
|
|
clear_bit(CORE_TB_RESYNC_REQ_BIT,
|
|
|
|
&local_paca->sibling_subcore_state->flags);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* kvmppc_realmode_hmi_handler() is called only by primary thread during
|
|
|
|
* guest exit path.
|
|
|
|
*
|
|
|
|
* There are multiple reasons why HMI could occur, one of them is
|
|
|
|
* Timebase (TB) error. If this HMI is due to TB error, then TB would
|
|
|
|
* have been in stopped state. The opal hmi handler Will fix it and
|
|
|
|
* restore the TB value with host timebase value. For HMI caused due
|
|
|
|
* to non-TB errors, opal hmi handler will not touch/restore TB register
|
|
|
|
* and hence there won't be any change in TB value.
|
|
|
|
*
|
|
|
|
* Since we are not sure about the cause of this HMI, we can't be sure
|
|
|
|
* about the content of TB register whether it holds guest or host timebase
|
|
|
|
* value. Hence the idea is to resync the TB on every HMI, so that we
|
|
|
|
* know about the exact state of the TB value. Resync TB call will
|
|
|
|
* restore TB to host timebase.
|
|
|
|
*
|
|
|
|
* Things to consider:
|
|
|
|
* - On TB error, HMI interrupt is reported on all the threads of the core
|
|
|
|
* that has encountered TB error irrespective of split-core mode.
|
|
|
|
* - The very first thread on the core that get chance to fix TB error
|
|
|
|
* would rsync the TB with local chipTOD value.
|
|
|
|
* - The resync TB is a core level action i.e. it will sync all the TBs
|
|
|
|
* in that core independent of split-core mode. This means if we trigger
|
|
|
|
* TB sync from a thread from one subcore, it would affect TB values of
|
|
|
|
* sibling subcores of the same core.
|
|
|
|
*
|
|
|
|
* All threads need to co-ordinate before making opal hmi handler.
|
|
|
|
* All threads will use sibling_subcore_state->in_guest[] (shared by all
|
|
|
|
* threads in the core) in paca which holds information about whether
|
|
|
|
* sibling subcores are in Guest mode or host mode. The in_guest[] array
|
|
|
|
* is of size MAX_SUBCORE_PER_CORE=4, indexed using subcore id to set/unset
|
|
|
|
* subcore status. Only primary threads from each subcore is responsible
|
|
|
|
* to set/unset its designated array element while entering/exiting the
|
|
|
|
* guset.
|
|
|
|
*
|
|
|
|
* After invoking opal hmi handler call, one of the thread (of entire core)
|
|
|
|
* will need to resync the TB. Bit 63 from subcore state bitmap flags
|
|
|
|
* (sibling_subcore_state->flags) will be used to co-ordinate between
|
|
|
|
* primary threads to decide who takes up the responsibility.
|
|
|
|
*
|
|
|
|
* This is what we do:
|
|
|
|
* - Primary thread from each subcore tries to set resync required bit[63]
|
|
|
|
* of paca->sibling_subcore_state->flags.
|
|
|
|
* - The first primary thread that is able to set the flag takes the
|
|
|
|
* responsibility of TB resync. (Let us call it as thread leader)
|
|
|
|
* - All other threads which are in host will call
|
|
|
|
* wait_for_subcore_guest_exit() and wait for in_guest[0-3] from
|
|
|
|
* paca->sibling_subcore_state to get cleared.
|
|
|
|
* - All the primary thread will clear its subcore status from subcore
|
|
|
|
* state in_guest[] array respectively.
|
|
|
|
* - Once all primary threads clear in_guest[0-3], all of them will invoke
|
|
|
|
* opal hmi handler.
|
|
|
|
* - Now all threads will wait for TB resync to complete by invoking
|
|
|
|
* wait_for_tb_resync() except the thread leader.
|
|
|
|
* - Thread leader will do a TB resync by invoking opal_resync_timebase()
|
|
|
|
* call and the it will clear the resync required bit.
|
|
|
|
* - All other threads will now come out of resync wait loop and proceed
|
|
|
|
* with individual execution.
|
|
|
|
* - On return of this function, primary thread will signal all
|
|
|
|
* secondary threads to proceed.
|
|
|
|
* - All secondary threads will eventually call opal hmi handler on
|
|
|
|
* their exit path.
|
|
|
|
*/
|
|
|
|
|
|
|
|
long kvmppc_realmode_hmi_handler(void)
|
|
|
|
{
|
|
|
|
int ptid = local_paca->kvm_hstate.ptid;
|
|
|
|
bool resync_req;
|
|
|
|
|
|
|
|
/* This is only called on primary thread. */
|
|
|
|
BUG_ON(ptid != 0);
|
|
|
|
__this_cpu_inc(irq_stat.hmi_exceptions);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* By now primary thread has already completed guest->host
|
|
|
|
* partition switch but haven't signaled secondaries yet.
|
|
|
|
* All the secondary threads on this subcore is waiting
|
|
|
|
* for primary thread to signal them to go ahead.
|
|
|
|
*
|
|
|
|
* For threads from subcore which isn't in guest, they all will
|
|
|
|
* wait until all other subcores on this core exit the guest.
|
|
|
|
*
|
|
|
|
* Now set the resync required bit. If you are the first to
|
|
|
|
* set this bit then kvmppc_tb_resync_required() function will
|
|
|
|
* return true. For rest all other subcores
|
|
|
|
* kvmppc_tb_resync_required() will return false.
|
|
|
|
*
|
|
|
|
* If resync_req == true, then this thread is responsible to
|
|
|
|
* initiate TB resync after hmi handler has completed.
|
|
|
|
* All other threads on this core will wait until this thread
|
|
|
|
* clears the resync required bit flag.
|
|
|
|
*/
|
|
|
|
resync_req = kvmppc_tb_resync_required();
|
|
|
|
|
|
|
|
/* Reset the subcore status to indicate it has exited guest */
|
|
|
|
kvmppc_subcore_exit_guest();
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Wait for other subcores on this core to exit the guest.
|
|
|
|
* All the primary threads and threads from subcore that are
|
|
|
|
* not in guest will wait here until all subcores are out
|
|
|
|
* of guest context.
|
|
|
|
*/
|
|
|
|
wait_for_subcore_guest_exit();
|
|
|
|
|
|
|
|
/*
|
|
|
|
* At this point we are sure that primary threads from each
|
|
|
|
* subcore on this core have completed guest->host partition
|
|
|
|
* switch. Now it is safe to call HMI handler.
|
|
|
|
*/
|
|
|
|
if (ppc_md.hmi_exception_early)
|
|
|
|
ppc_md.hmi_exception_early(NULL);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Check if this thread is responsible to resync TB.
|
|
|
|
* All other threads will wait until this thread completes the
|
|
|
|
* TB resync.
|
|
|
|
*/
|
|
|
|
if (resync_req) {
|
|
|
|
opal_resync_timebase();
|
|
|
|
/* Reset TB resync req bit */
|
|
|
|
kvmppc_tb_resync_done();
|
|
|
|
} else {
|
|
|
|
wait_for_tb_resync();
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|