2019-06-04 16:11:33 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
2013-04-18 04:31:15 +08:00
|
|
|
/*
|
|
|
|
* Copyright 2012 Michael Ellerman, IBM Corporation.
|
|
|
|
* Copyright 2012 Benjamin Herrenschmidt, IBM Corporation
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/kvm_host.h>
|
|
|
|
#include <linux/err.h>
|
2016-08-19 13:35:55 +08:00
|
|
|
#include <linux/kernel_stat.h>
|
2020-06-09 12:32:42 +08:00
|
|
|
#include <linux/pgtable.h>
|
2013-04-18 04:31:15 +08:00
|
|
|
|
|
|
|
#include <asm/kvm_book3s.h>
|
|
|
|
#include <asm/kvm_ppc.h>
|
|
|
|
#include <asm/hvcall.h>
|
|
|
|
#include <asm/xics.h>
|
|
|
|
#include <asm/synch.h>
|
2015-12-18 04:59:09 +08:00
|
|
|
#include <asm/cputhreads.h>
|
2013-04-18 04:31:15 +08:00
|
|
|
#include <asm/ppc-opcode.h>
|
KVM: PPC: Book3S HV: Handle passthrough interrupts in guest
Currently, KVM switches back to the host to handle any external
interrupt (when the interrupt is received while running in the
guest). This patch updates real-mode KVM to check if an interrupt
is generated by a passthrough adapter that is owned by this guest.
If so, the real mode KVM will directly inject the corresponding
virtual interrupt to the guest VCPU's ICS and also EOI the interrupt
in hardware. In short, the interrupt is handled entirely in real
mode in the guest context without switching back to the host.
In some rare cases, the interrupt cannot be completely handled in
real mode, for instance, a VCPU that is sleeping needs to be woken
up. In this case, KVM simply switches back to the host with trap
reason set to 0x500. This works, but it is clearly not very efficient.
A following patch will distinguish this case and handle it
correctly in the host. Note that we can use the existing
check_too_hard() routine even though we are not in a hypercall to
determine if there is unfinished business that needs to be
completed in host virtual mode.
The patch assumes that the mapping between hardware interrupt IRQ
and virtual IRQ to be injected to the guest already exists for the
PCI passthrough interrupts that need to be handled in real mode.
If the mapping does not exist, KVM falls back to the default
existing behavior.
The KVM real mode code reads mappings from the mapped array in the
passthrough IRQ map without taking any lock. We carefully order the
loads and stores of the fields in the kvmppc_irq_map data structure
using memory barriers to avoid an inconsistent mapping being seen by
the reader. Thus, although it is possible to miss a map entry, it is
not possible to read a stale value.
[paulus@ozlabs.org - get irq_chip from irq_map rather than pimap,
pulled out powernv eoi change into a separate patch, made
kvmppc_read_intr get the vcpu from the paca rather than being
passed in, rewrote the logic at the end of kvmppc_read_intr to
avoid deep indentation, simplified logic in book3s_hv_rmhandlers.S
since we were always restoring SRR0/1 anyway, get rid of the cached
array (just use the mapped array), removed the kick_all_cpus_sync()
call, clear saved_xirr PACA field when we handle the interrupt in
real mode, fix compilation with CONFIG_KVM_XICS=n.]
Signed-off-by: Suresh Warrier <warrier@linux.vnet.ibm.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2016-08-19 13:35:51 +08:00
|
|
|
#include <asm/pnv-pci.h>
|
KVM: PPC: Book3S HV: Set server for passed-through interrupts
When a guest has a PCI pass-through device with an interrupt, it
will direct the interrupt to a particular guest VCPU. In fact the
physical interrupt might arrive on any CPU, and then get
delivered to the target VCPU in the emulated XICS (guest interrupt
controller), and eventually delivered to the target VCPU.
Now that we have code to handle device interrupts in real mode
without exiting to the host kernel, there is an advantage to having
the device interrupt arrive on the same sub(core) as the target
VCPU is running on. In this situation, the interrupt can be
delivered to the target VCPU without any exit to the host kernel
(using a hypervisor doorbell interrupt between threads if
necessary).
This patch aims to get passed-through device interrupts arriving
on the correct core by setting the interrupt server in the real
hardware XICS for the interrupt to the first thread in the (sub)core
where its target VCPU is running. We do this in the real-mode H_EOI
code because the H_EOI handler already needs to look at the
emulated ICS state for the interrupt (whereas the H_XIRR handler
doesn't), and we know we are running in the target VCPU context
at that point.
We set the server CPU in hardware using an OPAL call, regardless of
what the IRQ affinity mask for the interrupt says, and without
updating the affinity mask. This amounts to saying that when an
interrupt is passed through to a guest, as a matter of policy we
allow the guest's affinity for the interrupt to override the host's.
This is inspired by an earlier patch from Suresh Warrier, although
none of this code came from that earlier patch.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2016-08-19 13:35:56 +08:00
|
|
|
#include <asm/opal.h>
|
2016-10-20 10:32:55 +08:00
|
|
|
#include <asm/smp.h>
|
2013-04-18 04:31:15 +08:00
|
|
|
|
|
|
|
#include "book3s_xics.h"
|
|
|
|
|
|
|
|
#define DEBUG_PASSUP
|
|
|
|
|
2015-12-22 06:33:57 +08:00
|
|
|
int h_ipi_redirect = 1;
|
|
|
|
EXPORT_SYMBOL(h_ipi_redirect);
|
2016-08-19 13:35:54 +08:00
|
|
|
int kvm_irq_bypass = 1;
|
|
|
|
EXPORT_SYMBOL(kvm_irq_bypass);
|
2015-12-22 06:33:57 +08:00
|
|
|
|
2015-03-20 17:39:47 +08:00
|
|
|
static void icp_rm_deliver_irq(struct kvmppc_xics *xics, struct kvmppc_icp *icp,
|
2016-11-11 12:57:36 +08:00
|
|
|
u32 new_irq, bool check_resend);
|
2017-02-07 13:03:17 +08:00
|
|
|
static int xics_opal_set_server(unsigned int hw_irq, int server_cpu);
|
2015-03-20 17:39:47 +08:00
|
|
|
|
|
|
|
/* -- ICS routines -- */
|
|
|
|
static void ics_rm_check_resend(struct kvmppc_xics *xics,
|
|
|
|
struct kvmppc_ics *ics, struct kvmppc_icp *icp)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < KVMPPC_XICS_IRQ_PER_ICS; i++) {
|
|
|
|
struct ics_irq_state *state = &ics->irq_state[i];
|
2016-11-11 12:57:36 +08:00
|
|
|
if (state->resend)
|
|
|
|
icp_rm_deliver_irq(xics, icp, state->number, true);
|
2015-03-20 17:39:47 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
/* -- ICP routines -- */
|
|
|
|
|
2015-12-22 06:22:51 +08:00
|
|
|
#ifdef CONFIG_SMP
|
|
|
|
static inline void icp_send_hcore_msg(int hcore, struct kvm_vcpu *vcpu)
|
|
|
|
{
|
|
|
|
int hcpu;
|
|
|
|
|
|
|
|
hcpu = hcore << threads_shift;
|
|
|
|
kvmppc_host_rm_ops_hv->rm_core[hcore].rm_data = vcpu;
|
|
|
|
smp_muxed_ipi_set_message(hcpu, PPC_MSG_RM_HOST_ACTION);
|
KVM: PPC: Book3S HV: use smp_mb() when setting/clearing host_ipi flag
On a 2-socket Power9 system with 32 cores/128 threads (SMT4) and 1TB
of memory running the following guest configs:
guest A:
- 224GB of memory
- 56 VCPUs (sockets=1,cores=28,threads=2), where:
VCPUs 0-1 are pinned to CPUs 0-3,
VCPUs 2-3 are pinned to CPUs 4-7,
...
VCPUs 54-55 are pinned to CPUs 108-111
guest B:
- 4GB of memory
- 4 VCPUs (sockets=1,cores=4,threads=1)
with the following workloads (with KSM and THP enabled in all):
guest A:
stress --cpu 40 --io 20 --vm 20 --vm-bytes 512M
guest B:
stress --cpu 4 --io 4 --vm 4 --vm-bytes 512M
host:
stress --cpu 4 --io 4 --vm 2 --vm-bytes 256M
the below soft-lockup traces were observed after an hour or so and
persisted until the host was reset (this was found to be reliably
reproducible for this configuration, for kernels 4.15, 4.18, 5.0,
and 5.3-rc5):
[ 1253.183290] rcu: INFO: rcu_sched self-detected stall on CPU
[ 1253.183319] rcu: 124-....: (5250 ticks this GP) idle=10a/1/0x4000000000000002 softirq=5408/5408 fqs=1941
[ 1256.287426] watchdog: BUG: soft lockup - CPU#105 stuck for 23s! [CPU 52/KVM:19709]
[ 1264.075773] watchdog: BUG: soft lockup - CPU#24 stuck for 23s! [worker:19913]
[ 1264.079769] watchdog: BUG: soft lockup - CPU#31 stuck for 23s! [worker:20331]
[ 1264.095770] watchdog: BUG: soft lockup - CPU#45 stuck for 23s! [worker:20338]
[ 1264.131773] watchdog: BUG: soft lockup - CPU#64 stuck for 23s! [avocado:19525]
[ 1280.408480] watchdog: BUG: soft lockup - CPU#124 stuck for 22s! [ksmd:791]
[ 1316.198012] rcu: INFO: rcu_sched self-detected stall on CPU
[ 1316.198032] rcu: 124-....: (21003 ticks this GP) idle=10a/1/0x4000000000000002 softirq=5408/5408 fqs=8243
[ 1340.411024] watchdog: BUG: soft lockup - CPU#124 stuck for 22s! [ksmd:791]
[ 1379.212609] rcu: INFO: rcu_sched self-detected stall on CPU
[ 1379.212629] rcu: 124-....: (36756 ticks this GP) idle=10a/1/0x4000000000000002 softirq=5408/5408 fqs=14714
[ 1404.413615] watchdog: BUG: soft lockup - CPU#124 stuck for 22s! [ksmd:791]
[ 1442.227095] rcu: INFO: rcu_sched self-detected stall on CPU
[ 1442.227115] rcu: 124-....: (52509 ticks this GP) idle=10a/1/0x4000000000000002 softirq=5408/5408 fqs=21403
[ 1455.111787] INFO: task worker:19907 blocked for more than 120 seconds.
[ 1455.111822] Tainted: G L 5.3.0-rc5-mdr-vanilla+ #1
[ 1455.111833] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 1455.111884] INFO: task worker:19908 blocked for more than 120 seconds.
[ 1455.111905] Tainted: G L 5.3.0-rc5-mdr-vanilla+ #1
[ 1455.111925] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 1455.111966] INFO: task worker:20328 blocked for more than 120 seconds.
[ 1455.111986] Tainted: G L 5.3.0-rc5-mdr-vanilla+ #1
[ 1455.111998] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 1455.112048] INFO: task worker:20330 blocked for more than 120 seconds.
[ 1455.112068] Tainted: G L 5.3.0-rc5-mdr-vanilla+ #1
[ 1455.112097] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 1455.112138] INFO: task worker:20332 blocked for more than 120 seconds.
[ 1455.112159] Tainted: G L 5.3.0-rc5-mdr-vanilla+ #1
[ 1455.112179] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 1455.112210] INFO: task worker:20333 blocked for more than 120 seconds.
[ 1455.112231] Tainted: G L 5.3.0-rc5-mdr-vanilla+ #1
[ 1455.112242] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 1455.112282] INFO: task worker:20335 blocked for more than 120 seconds.
[ 1455.112303] Tainted: G L 5.3.0-rc5-mdr-vanilla+ #1
[ 1455.112332] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 1455.112372] INFO: task worker:20336 blocked for more than 120 seconds.
[ 1455.112392] Tainted: G L 5.3.0-rc5-mdr-vanilla+ #1
CPUs 45, 24, and 124 are stuck on spin locks, likely held by
CPUs 105 and 31.
CPUs 105 and 31 are stuck in smp_call_function_many(), waiting on
target CPU 42. For instance:
# CPU 105 registers (via xmon)
R00 = c00000000020b20c R16 = 00007d1bcd800000
R01 = c00000363eaa7970 R17 = 0000000000000001
R02 = c0000000019b3a00 R18 = 000000000000006b
R03 = 000000000000002a R19 = 00007d537d7aecf0
R04 = 000000000000002a R20 = 60000000000000e0
R05 = 000000000000002a R21 = 0801000000000080
R06 = c0002073fb0caa08 R22 = 0000000000000d60
R07 = c0000000019ddd78 R23 = 0000000000000001
R08 = 000000000000002a R24 = c00000000147a700
R09 = 0000000000000001 R25 = c0002073fb0ca908
R10 = c000008ffeb4e660 R26 = 0000000000000000
R11 = c0002073fb0ca900 R27 = c0000000019e2464
R12 = c000000000050790 R28 = c0000000000812b0
R13 = c000207fff623e00 R29 = c0002073fb0ca808
R14 = 00007d1bbee00000 R30 = c0002073fb0ca800
R15 = 00007d1bcd600000 R31 = 0000000000000800
pc = c00000000020b260 smp_call_function_many+0x3d0/0x460
cfar= c00000000020b270 smp_call_function_many+0x3e0/0x460
lr = c00000000020b20c smp_call_function_many+0x37c/0x460
msr = 900000010288b033 cr = 44024824
ctr = c000000000050790 xer = 0000000000000000 trap = 100
CPU 42 is running normally, doing VCPU work:
# CPU 42 stack trace (via xmon)
[link register ] c00800001be17188 kvmppc_book3s_radix_page_fault+0x90/0x2b0 [kvm_hv]
[c000008ed3343820] c000008ed3343850 (unreliable)
[c000008ed33438d0] c00800001be11b6c kvmppc_book3s_hv_page_fault+0x264/0xe30 [kvm_hv]
[c000008ed33439d0] c00800001be0d7b4 kvmppc_vcpu_run_hv+0x8dc/0xb50 [kvm_hv]
[c000008ed3343ae0] c00800001c10891c kvmppc_vcpu_run+0x34/0x48 [kvm]
[c000008ed3343b00] c00800001c10475c kvm_arch_vcpu_ioctl_run+0x244/0x420 [kvm]
[c000008ed3343b90] c00800001c0f5a78 kvm_vcpu_ioctl+0x470/0x7c8 [kvm]
[c000008ed3343d00] c000000000475450 do_vfs_ioctl+0xe0/0xc70
[c000008ed3343db0] c0000000004760e4 ksys_ioctl+0x104/0x120
[c000008ed3343e00] c000000000476128 sys_ioctl+0x28/0x80
[c000008ed3343e20] c00000000000b388 system_call+0x5c/0x70
--- Exception: c00 (System Call) at 00007d545cfd7694
SP (7d53ff7edf50) is in userspace
It was subsequently found that ipi_message[PPC_MSG_CALL_FUNCTION]
was set for CPU 42 by at least 1 of the CPUs waiting in
smp_call_function_many(), but somehow the corresponding
call_single_queue entries were never processed by CPU 42, causing the
callers to spin in csd_lock_wait() indefinitely.
Nick Piggin suggested something similar to the following sequence as
a possible explanation (interleaving of CALL_FUNCTION/RESCHEDULE
IPI messages seems to be most common, but any mix of CALL_FUNCTION and
!CALL_FUNCTION messages could trigger it):
CPU
X: smp_muxed_ipi_set_message():
X: smp_mb()
X: message[RESCHEDULE] = 1
X: doorbell_global_ipi(42):
X: kvmppc_set_host_ipi(42, 1)
X: ppc_msgsnd_sync()/smp_mb()
X: ppc_msgsnd() -> 42
42: doorbell_exception(): // from CPU X
42: ppc_msgsync()
105: smp_muxed_ipi_set_message():
105: smb_mb()
// STORE DEFERRED DUE TO RE-ORDERING
--105: message[CALL_FUNCTION] = 1
| 105: doorbell_global_ipi(42):
| 105: kvmppc_set_host_ipi(42, 1)
| 42: kvmppc_set_host_ipi(42, 0)
| 42: smp_ipi_demux_relaxed()
| 42: // returns to executing guest
| // RE-ORDERED STORE COMPLETES
->105: message[CALL_FUNCTION] = 1
105: ppc_msgsnd_sync()/smp_mb()
105: ppc_msgsnd() -> 42
42: local_paca->kvm_hstate.host_ipi == 0 // IPI ignored
105: // hangs waiting on 42 to process messages/call_single_queue
This can be prevented with an smp_mb() at the beginning of
kvmppc_set_host_ipi(), such that stores to message[<type>] (or other
state indicated by the host_ipi flag) are ordered vs. the store to
to host_ipi.
However, doing so might still allow for the following scenario (not
yet observed):
CPU
X: smp_muxed_ipi_set_message():
X: smp_mb()
X: message[RESCHEDULE] = 1
X: doorbell_global_ipi(42):
X: kvmppc_set_host_ipi(42, 1)
X: ppc_msgsnd_sync()/smp_mb()
X: ppc_msgsnd() -> 42
42: doorbell_exception(): // from CPU X
42: ppc_msgsync()
// STORE DEFERRED DUE TO RE-ORDERING
-- 42: kvmppc_set_host_ipi(42, 0)
| 42: smp_ipi_demux_relaxed()
| 105: smp_muxed_ipi_set_message():
| 105: smb_mb()
| 105: message[CALL_FUNCTION] = 1
| 105: doorbell_global_ipi(42):
| 105: kvmppc_set_host_ipi(42, 1)
| // RE-ORDERED STORE COMPLETES
-> 42: kvmppc_set_host_ipi(42, 0)
42: // returns to executing guest
105: ppc_msgsnd_sync()/smp_mb()
105: ppc_msgsnd() -> 42
42: local_paca->kvm_hstate.host_ipi == 0 // IPI ignored
105: // hangs waiting on 42 to process messages/call_single_queue
Fixing this scenario would require an smp_mb() *after* clearing
host_ipi flag in kvmppc_set_host_ipi() to order the store vs.
subsequent processing of IPI messages.
To handle both cases, this patch splits kvmppc_set_host_ipi() into
separate set/clear functions, where we execute smp_mb() prior to
setting host_ipi flag, and after clearing host_ipi flag. These
functions pair with each other to synchronize the sender and receiver
sides.
With that change in place the above workload ran for 20 hours without
triggering any lock-ups.
Fixes: 755563bc79c7 ("powerpc/powernv: Fixes for hypervisor doorbell handling") # v4.0
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Acked-by: Paul Mackerras <paulus@ozlabs.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20190911223155.16045-1-mdroth@linux.vnet.ibm.com
2019-09-12 06:31:55 +08:00
|
|
|
kvmppc_set_host_ipi(hcpu);
|
2017-01-30 18:21:51 +08:00
|
|
|
smp_mb();
|
|
|
|
kvmhv_rm_send_ipi(hcpu);
|
2015-12-22 06:22:51 +08:00
|
|
|
}
|
|
|
|
#else
|
|
|
|
static inline void icp_send_hcore_msg(int hcore, struct kvm_vcpu *vcpu) { }
|
|
|
|
#endif
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We start the search from our current CPU Id in the core map
|
|
|
|
* and go in a circle until we get back to our ID looking for a
|
|
|
|
* core that is running in host context and that hasn't already
|
|
|
|
* been targeted for another rm_host_ops.
|
|
|
|
*
|
|
|
|
* In the future, could consider using a fairer algorithm (one
|
|
|
|
* that distributes the IPIs better)
|
|
|
|
*
|
|
|
|
* Returns -1, if no CPU could be found in the host
|
|
|
|
* Else, returns a CPU Id which has been reserved for use
|
|
|
|
*/
|
|
|
|
static inline int grab_next_hostcore(int start,
|
|
|
|
struct kvmppc_host_rm_core *rm_core, int max, int action)
|
|
|
|
{
|
|
|
|
bool success;
|
|
|
|
int core;
|
|
|
|
union kvmppc_rm_state old, new;
|
|
|
|
|
|
|
|
for (core = start + 1; core < max; core++) {
|
|
|
|
old = new = READ_ONCE(rm_core[core].rm_state);
|
|
|
|
|
|
|
|
if (!old.in_host || old.rm_action)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/* Try to grab this host core if not taken already. */
|
|
|
|
new.rm_action = action;
|
|
|
|
|
|
|
|
success = cmpxchg64(&rm_core[core].rm_state.raw,
|
|
|
|
old.raw, new.raw) == old.raw;
|
|
|
|
if (success) {
|
|
|
|
/*
|
|
|
|
* Make sure that the store to the rm_action is made
|
|
|
|
* visible before we return to caller (and the
|
|
|
|
* subsequent store to rm_data) to synchronize with
|
|
|
|
* the IPI handler.
|
|
|
|
*/
|
|
|
|
smp_wmb();
|
|
|
|
return core;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int find_available_hostcore(int action)
|
|
|
|
{
|
|
|
|
int core;
|
|
|
|
int my_core = smp_processor_id() >> threads_shift;
|
|
|
|
struct kvmppc_host_rm_core *rm_core = kvmppc_host_rm_ops_hv->rm_core;
|
|
|
|
|
|
|
|
core = grab_next_hostcore(my_core, rm_core, cpu_nr_cores(), action);
|
|
|
|
if (core == -1)
|
|
|
|
core = grab_next_hostcore(core, rm_core, my_core, action);
|
|
|
|
|
|
|
|
return core;
|
|
|
|
}
|
|
|
|
|
2013-04-18 04:31:15 +08:00
|
|
|
static void icp_rm_set_vcpu_irq(struct kvm_vcpu *vcpu,
|
|
|
|
struct kvm_vcpu *this_vcpu)
|
|
|
|
{
|
|
|
|
struct kvmppc_icp *this_icp = this_vcpu->arch.icp;
|
|
|
|
int cpu;
|
2015-12-22 06:22:51 +08:00
|
|
|
int hcore;
|
2013-04-18 04:31:15 +08:00
|
|
|
|
|
|
|
/* Mark the target VCPU as having an interrupt pending */
|
|
|
|
vcpu->stat.queue_intr++;
|
2018-10-08 13:30:48 +08:00
|
|
|
set_bit(BOOK3S_IRQPRIO_EXTERNAL, &vcpu->arch.pending_exceptions);
|
2013-04-18 04:31:15 +08:00
|
|
|
|
|
|
|
/* Kick self ? Just set MER and return */
|
|
|
|
if (vcpu == this_vcpu) {
|
|
|
|
mtspr(SPRN_LPCR, mfspr(SPRN_LPCR) | LPCR_MER);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
KVM: PPC: Book3S: Allow XICS emulation to work in nested hosts using XIVE
Currently, the KVM code assumes that if the host kernel is using the
XIVE interrupt controller (the new interrupt controller that first
appeared in POWER9 systems), then the in-kernel XICS emulation will
use the XIVE hardware to deliver interrupts to the guest. However,
this only works when the host is running in hypervisor mode and has
full access to all of the XIVE functionality. It doesn't work in any
nested virtualization scenario, either with PR KVM or nested-HV KVM,
because the XICS-on-XIVE code calls directly into the native-XIVE
routines, which are not initialized and cannot function correctly
because they use OPAL calls, and OPAL is not available in a guest.
This means that using the in-kernel XICS emulation in a nested
hypervisor that is using XIVE as its interrupt controller will cause a
(nested) host kernel crash. To fix this, we change most of the places
where the current code calls xive_enabled() to select between the
XICS-on-XIVE emulation and the plain XICS emulation to call a new
function, xics_on_xive(), which returns false in a guest.
However, there is a further twist. The plain XICS emulation has some
functions which are used in real mode and access the underlying XICS
controller (the interrupt controller of the host) directly. In the
case of a nested hypervisor, this means doing XICS hypercalls
directly. When the nested host is using XIVE as its interrupt
controller, these hypercalls will fail. Therefore this also adds
checks in the places where the XICS emulation wants to access the
underlying interrupt controller directly, and if that is XIVE, makes
the code use the virtual mode fallback paths, which call generic
kernel infrastructure rather than doing direct XICS access.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2019-02-04 19:07:20 +08:00
|
|
|
if (xive_enabled() && kvmhv_on_pseries()) {
|
|
|
|
/* No XICS access or hypercalls available, too hard */
|
|
|
|
this_icp->rm_action |= XICS_RM_KICK_VCPU;
|
|
|
|
this_icp->rm_kick_target = vcpu;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2015-12-22 06:22:51 +08:00
|
|
|
/*
|
|
|
|
* Check if the core is loaded,
|
|
|
|
* if not, find an available host core to post to wake the VCPU,
|
|
|
|
* if we can't find one, set up state to eventually return too hard.
|
|
|
|
*/
|
KVM: PPC: Book3S HV: Make use of unused threads when running guests
When running a virtual core of a guest that is configured with fewer
threads per core than the physical cores have, the extra physical
threads are currently unused. This makes it possible to use them to
run one or more other virtual cores from the same guest when certain
conditions are met. This applies on POWER7, and on POWER8 to guests
with one thread per virtual core. (It doesn't apply to POWER8 guests
with multiple threads per vcore because they require a 1-1 virtual to
physical thread mapping in order to be able to use msgsndp and the
TIR.)
The idea is that we maintain a list of preempted vcores for each
physical cpu (i.e. each core, since the host runs single-threaded).
Then, when a vcore is about to run, it checks to see if there are
any vcores on the list for its physical cpu that could be
piggybacked onto this vcore's execution. If so, those additional
vcores are put into state VCORE_PIGGYBACK and their runnable VCPU
threads are started as well as the original vcore, which is called
the master vcore.
After the vcores have exited the guest, the extra ones are put back
onto the preempted list if any of their VCPUs are still runnable and
not idle.
This means that vcpu->arch.ptid is no longer necessarily the same as
the physical thread that the vcpu runs on. In order to make it easier
for code that wants to send an IPI to know which CPU to target, we
now store that in a new field in struct vcpu_arch, called thread_cpu.
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Tested-by: Laurent Vivier <lvivier@redhat.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
2015-06-24 19:18:03 +08:00
|
|
|
cpu = vcpu->arch.thread_cpu;
|
2013-04-18 04:31:15 +08:00
|
|
|
if (cpu < 0 || cpu >= nr_cpu_ids) {
|
2015-12-22 06:22:51 +08:00
|
|
|
hcore = -1;
|
2015-12-22 06:33:57 +08:00
|
|
|
if (kvmppc_host_rm_ops_hv && h_ipi_redirect)
|
2015-12-22 06:22:51 +08:00
|
|
|
hcore = find_available_hostcore(XICS_RM_KICK_VCPU);
|
|
|
|
if (hcore != -1) {
|
|
|
|
icp_send_hcore_msg(hcore, vcpu);
|
|
|
|
} else {
|
|
|
|
this_icp->rm_action |= XICS_RM_KICK_VCPU;
|
|
|
|
this_icp->rm_kick_target = vcpu;
|
|
|
|
}
|
2013-04-18 04:31:15 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2015-03-28 11:21:11 +08:00
|
|
|
smp_mb();
|
|
|
|
kvmhv_rm_send_ipi(cpu);
|
2013-04-18 04:31:15 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void icp_rm_clr_vcpu_irq(struct kvm_vcpu *vcpu)
|
|
|
|
{
|
|
|
|
/* Note: Only called on self ! */
|
2018-10-08 13:30:48 +08:00
|
|
|
clear_bit(BOOK3S_IRQPRIO_EXTERNAL, &vcpu->arch.pending_exceptions);
|
2013-04-18 04:31:15 +08:00
|
|
|
mtspr(SPRN_LPCR, mfspr(SPRN_LPCR) & ~LPCR_MER);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline bool icp_rm_try_update(struct kvmppc_icp *icp,
|
|
|
|
union kvmppc_icp_state old,
|
|
|
|
union kvmppc_icp_state new)
|
|
|
|
{
|
|
|
|
struct kvm_vcpu *this_vcpu = local_paca->kvm_hstate.kvm_vcpu;
|
|
|
|
bool success;
|
|
|
|
|
|
|
|
/* Calculate new output value */
|
|
|
|
new.out_ee = (new.xisr && (new.pending_pri < new.cppr));
|
|
|
|
|
|
|
|
/* Attempt atomic update */
|
|
|
|
success = cmpxchg64(&icp->state.raw, old.raw, new.raw) == old.raw;
|
|
|
|
if (!success)
|
|
|
|
goto bail;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Check for output state update
|
|
|
|
*
|
|
|
|
* Note that this is racy since another processor could be updating
|
|
|
|
* the state already. This is why we never clear the interrupt output
|
|
|
|
* here, we only ever set it. The clear only happens prior to doing
|
|
|
|
* an update and only by the processor itself. Currently we do it
|
|
|
|
* in Accept (H_XIRR) and Up_Cppr (H_XPPR).
|
|
|
|
*
|
|
|
|
* We also do not try to figure out whether the EE state has changed,
|
|
|
|
* we unconditionally set it if the new state calls for it. The reason
|
|
|
|
* for that is that we opportunistically remove the pending interrupt
|
|
|
|
* flag when raising CPPR, so we need to set it back here if an
|
|
|
|
* interrupt is still pending.
|
|
|
|
*/
|
|
|
|
if (new.out_ee)
|
|
|
|
icp_rm_set_vcpu_irq(icp->vcpu, this_vcpu);
|
|
|
|
|
|
|
|
/* Expose the state change for debug purposes */
|
|
|
|
this_vcpu->arch.icp->rm_dbgstate = new;
|
|
|
|
this_vcpu->arch.icp->rm_dbgtgt = icp->vcpu;
|
|
|
|
|
|
|
|
bail:
|
|
|
|
return success;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int check_too_hard(struct kvmppc_xics *xics,
|
|
|
|
struct kvmppc_icp *icp)
|
|
|
|
{
|
|
|
|
return (xics->real_mode_dbg || icp->rm_action) ? H_TOO_HARD : H_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2015-03-20 17:39:47 +08:00
|
|
|
static void icp_rm_check_resend(struct kvmppc_xics *xics,
|
|
|
|
struct kvmppc_icp *icp)
|
|
|
|
{
|
|
|
|
u32 icsid;
|
|
|
|
|
|
|
|
/* Order this load with the test for need_resend in the caller */
|
|
|
|
smp_rmb();
|
|
|
|
for_each_set_bit(icsid, icp->resend_map, xics->max_icsid + 1) {
|
|
|
|
struct kvmppc_ics *ics = xics->ics[icsid];
|
|
|
|
|
|
|
|
if (!test_and_clear_bit(icsid, icp->resend_map))
|
|
|
|
continue;
|
|
|
|
if (!ics)
|
|
|
|
continue;
|
|
|
|
ics_rm_check_resend(xics, ics, icp);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool icp_rm_try_to_deliver(struct kvmppc_icp *icp, u32 irq, u8 priority,
|
|
|
|
u32 *reject)
|
|
|
|
{
|
|
|
|
union kvmppc_icp_state old_state, new_state;
|
|
|
|
bool success;
|
|
|
|
|
|
|
|
do {
|
|
|
|
old_state = new_state = READ_ONCE(icp->state);
|
|
|
|
|
|
|
|
*reject = 0;
|
|
|
|
|
|
|
|
/* See if we can deliver */
|
|
|
|
success = new_state.cppr > priority &&
|
|
|
|
new_state.mfrr > priority &&
|
|
|
|
new_state.pending_pri > priority;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If we can, check for a rejection and perform the
|
|
|
|
* delivery
|
|
|
|
*/
|
|
|
|
if (success) {
|
|
|
|
*reject = new_state.xisr;
|
|
|
|
new_state.xisr = irq;
|
|
|
|
new_state.pending_pri = priority;
|
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* If we failed to deliver we set need_resend
|
|
|
|
* so a subsequent CPPR state change causes us
|
|
|
|
* to try a new delivery.
|
|
|
|
*/
|
|
|
|
new_state.need_resend = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
} while (!icp_rm_try_update(icp, old_state, new_state));
|
|
|
|
|
|
|
|
return success;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void icp_rm_deliver_irq(struct kvmppc_xics *xics, struct kvmppc_icp *icp,
|
2016-11-11 12:57:36 +08:00
|
|
|
u32 new_irq, bool check_resend)
|
2015-03-20 17:39:47 +08:00
|
|
|
{
|
|
|
|
struct ics_irq_state *state;
|
|
|
|
struct kvmppc_ics *ics;
|
|
|
|
u32 reject;
|
|
|
|
u16 src;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This is used both for initial delivery of an interrupt and
|
|
|
|
* for subsequent rejection.
|
|
|
|
*
|
|
|
|
* Rejection can be racy vs. resends. We have evaluated the
|
|
|
|
* rejection in an atomic ICP transaction which is now complete,
|
|
|
|
* so potentially the ICP can already accept the interrupt again.
|
|
|
|
*
|
|
|
|
* So we need to retry the delivery. Essentially the reject path
|
|
|
|
* boils down to a failed delivery. Always.
|
|
|
|
*
|
|
|
|
* Now the interrupt could also have moved to a different target,
|
|
|
|
* thus we may need to re-do the ICP lookup as well
|
|
|
|
*/
|
|
|
|
|
|
|
|
again:
|
|
|
|
/* Get the ICS state and lock it */
|
|
|
|
ics = kvmppc_xics_find_ics(xics, new_irq, &src);
|
|
|
|
if (!ics) {
|
|
|
|
/* Unsafe increment, but this does not need to be accurate */
|
2015-03-20 17:39:48 +08:00
|
|
|
xics->err_noics++;
|
2015-03-20 17:39:47 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
state = &ics->irq_state[src];
|
|
|
|
|
|
|
|
/* Get a lock on the ICS */
|
|
|
|
arch_spin_lock(&ics->lock);
|
|
|
|
|
|
|
|
/* Get our server */
|
|
|
|
if (!icp || state->server != icp->server_num) {
|
|
|
|
icp = kvmppc_xics_find_server(xics->kvm, state->server);
|
|
|
|
if (!icp) {
|
|
|
|
/* Unsafe increment again*/
|
2015-03-20 17:39:48 +08:00
|
|
|
xics->err_noicp++;
|
2015-03-20 17:39:47 +08:00
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-11-11 12:57:36 +08:00
|
|
|
if (check_resend)
|
|
|
|
if (!state->resend)
|
|
|
|
goto out;
|
|
|
|
|
2015-03-20 17:39:47 +08:00
|
|
|
/* Clear the resend bit of that interrupt */
|
|
|
|
state->resend = 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If masked, bail out
|
|
|
|
*
|
|
|
|
* Note: PAPR doesn't mention anything about masked pending
|
|
|
|
* when doing a resend, only when doing a delivery.
|
|
|
|
*
|
|
|
|
* However that would have the effect of losing a masked
|
|
|
|
* interrupt that was rejected and isn't consistent with
|
|
|
|
* the whole masked_pending business which is about not
|
|
|
|
* losing interrupts that occur while masked.
|
|
|
|
*
|
|
|
|
* I don't differentiate normal deliveries and resends, this
|
|
|
|
* implementation will differ from PAPR and not lose such
|
|
|
|
* interrupts.
|
|
|
|
*/
|
|
|
|
if (state->priority == MASKED) {
|
|
|
|
state->masked_pending = 1;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Try the delivery, this will set the need_resend flag
|
|
|
|
* in the ICP as part of the atomic transaction if the
|
|
|
|
* delivery is not possible.
|
|
|
|
*
|
|
|
|
* Note that if successful, the new delivery might have itself
|
|
|
|
* rejected an interrupt that was "delivered" before we took the
|
|
|
|
* ics spin lock.
|
|
|
|
*
|
|
|
|
* In this case we do the whole sequence all over again for the
|
|
|
|
* new guy. We cannot assume that the rejected interrupt is less
|
|
|
|
* favored than the new one, and thus doesn't need to be delivered,
|
|
|
|
* because by the time we exit icp_rm_try_to_deliver() the target
|
|
|
|
* processor may well have already consumed & completed it, and thus
|
|
|
|
* the rejected interrupt might actually be already acceptable.
|
|
|
|
*/
|
|
|
|
if (icp_rm_try_to_deliver(icp, new_irq, state->priority, &reject)) {
|
|
|
|
/*
|
|
|
|
* Delivery was successful, did we reject somebody else ?
|
|
|
|
*/
|
|
|
|
if (reject && reject != XICS_IPI) {
|
|
|
|
arch_spin_unlock(&ics->lock);
|
2016-11-11 12:57:33 +08:00
|
|
|
icp->n_reject++;
|
2015-03-20 17:39:47 +08:00
|
|
|
new_irq = reject;
|
2016-11-11 12:57:36 +08:00
|
|
|
check_resend = 0;
|
2015-03-20 17:39:47 +08:00
|
|
|
goto again;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* We failed to deliver the interrupt we need to set the
|
|
|
|
* resend map bit and mark the ICS state as needing a resend
|
|
|
|
*/
|
|
|
|
state->resend = 1;
|
|
|
|
|
2016-11-11 12:57:36 +08:00
|
|
|
/*
|
|
|
|
* Make sure when checking resend, we don't miss the resend
|
|
|
|
* if resend_map bit is seen and cleared.
|
|
|
|
*/
|
|
|
|
smp_wmb();
|
|
|
|
set_bit(ics->icsid, icp->resend_map);
|
|
|
|
|
2015-03-20 17:39:47 +08:00
|
|
|
/*
|
|
|
|
* If the need_resend flag got cleared in the ICP some time
|
|
|
|
* between icp_rm_try_to_deliver() atomic update and now, then
|
|
|
|
* we know it might have missed the resend_map bit. So we
|
|
|
|
* retry
|
|
|
|
*/
|
|
|
|
smp_mb();
|
|
|
|
if (!icp->state.need_resend) {
|
2016-11-11 12:57:34 +08:00
|
|
|
state->resend = 0;
|
2015-03-20 17:39:47 +08:00
|
|
|
arch_spin_unlock(&ics->lock);
|
2016-11-11 12:57:36 +08:00
|
|
|
check_resend = 0;
|
2015-03-20 17:39:47 +08:00
|
|
|
goto again;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
out:
|
|
|
|
arch_spin_unlock(&ics->lock);
|
|
|
|
}
|
|
|
|
|
2013-04-18 04:31:15 +08:00
|
|
|
static void icp_rm_down_cppr(struct kvmppc_xics *xics, struct kvmppc_icp *icp,
|
|
|
|
u8 new_cppr)
|
|
|
|
{
|
|
|
|
union kvmppc_icp_state old_state, new_state;
|
|
|
|
bool resend;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This handles several related states in one operation:
|
|
|
|
*
|
|
|
|
* ICP State: Down_CPPR
|
|
|
|
*
|
|
|
|
* Load CPPR with new value and if the XISR is 0
|
|
|
|
* then check for resends:
|
|
|
|
*
|
|
|
|
* ICP State: Resend
|
|
|
|
*
|
|
|
|
* If MFRR is more favored than CPPR, check for IPIs
|
|
|
|
* and notify ICS of a potential resend. This is done
|
|
|
|
* asynchronously (when used in real mode, we will have
|
|
|
|
* to exit here).
|
|
|
|
*
|
|
|
|
* We do not handle the complete Check_IPI as documented
|
|
|
|
* here. In the PAPR, this state will be used for both
|
|
|
|
* Set_MFRR and Down_CPPR. However, we know that we aren't
|
|
|
|
* changing the MFRR state here so we don't need to handle
|
|
|
|
* the case of an MFRR causing a reject of a pending irq,
|
|
|
|
* this will have been handled when the MFRR was set in the
|
|
|
|
* first place.
|
|
|
|
*
|
|
|
|
* Thus we don't have to handle rejects, only resends.
|
|
|
|
*
|
|
|
|
* When implementing real mode for HV KVM, resend will lead to
|
|
|
|
* a H_TOO_HARD return and the whole transaction will be handled
|
|
|
|
* in virtual mode.
|
|
|
|
*/
|
|
|
|
do {
|
2015-01-07 05:41:46 +08:00
|
|
|
old_state = new_state = READ_ONCE(icp->state);
|
2013-04-18 04:31:15 +08:00
|
|
|
|
|
|
|
/* Down_CPPR */
|
|
|
|
new_state.cppr = new_cppr;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Cut down Resend / Check_IPI / IPI
|
|
|
|
*
|
|
|
|
* The logic is that we cannot have a pending interrupt
|
|
|
|
* trumped by an IPI at this point (see above), so we
|
|
|
|
* know that either the pending interrupt is already an
|
|
|
|
* IPI (in which case we don't care to override it) or
|
|
|
|
* it's either more favored than us or non existent
|
|
|
|
*/
|
|
|
|
if (new_state.mfrr < new_cppr &&
|
|
|
|
new_state.mfrr <= new_state.pending_pri) {
|
|
|
|
new_state.pending_pri = new_state.mfrr;
|
|
|
|
new_state.xisr = XICS_IPI;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Latch/clear resend bit */
|
|
|
|
resend = new_state.need_resend;
|
|
|
|
new_state.need_resend = 0;
|
|
|
|
|
|
|
|
} while (!icp_rm_try_update(icp, old_state, new_state));
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Now handle resend checks. Those are asynchronous to the ICP
|
|
|
|
* state update in HW (ie bus transactions) so we can handle them
|
|
|
|
* separately here as well.
|
|
|
|
*/
|
KVM: PPC: Book3S HV: Fix inaccuracies in ICP emulation for H_IPI
This fixes some inaccuracies in the state machine for the virtualized
ICP when implementing the H_IPI hcall (Set_MFFR and related states):
1. The old code wipes out any pending interrupts when the new MFRR is
more favored than the CPPR but less favored than a pending
interrupt (by always modifying xisr and the pending_pri). This can
cause us to lose a pending external interrupt.
The correct code here is to only modify the pending_pri and xisr in
the ICP if the MFRR is equal to or more favored than the current
pending pri (since in this case, it is guaranteed that that there
cannot be a pending external interrupt). The code changes are
required in both kvmppc_rm_h_ipi and kvmppc_h_ipi.
2. Again, in both kvmppc_rm_h_ipi and kvmppc_h_ipi, there is a check
for whether MFRR is being made less favored AND further if new MFFR
is also less favored than the current CPPR, we check for any
resends pending in the ICP. These checks look like they are
designed to cover the case where if the MFRR is being made less
favored, we opportunistically trigger a resend of any interrupts
that had been previously rejected. Although, this is not a state
described by PAPR, this is an action we actually need to do
especially if the CPPR is already at 0xFF. Because in this case,
the resend bit will stay on until another ICP state change which
may be a long time coming and the interrupt stays pending until
then. The current code which checks for MFRR < CPPR is broken when
CPPR is 0xFF since it will not get triggered in that case.
Ideally, we would want to do a resend only if
prio(pending_interrupt) < mfrr && prio(pending_interrupt) < cppr
where pending interrupt is the one that was rejected. But we don't
have the priority of the pending interrupt state saved, so we
simply trigger a resend whenever the MFRR is made less favored.
3. In kvmppc_rm_h_ipi, where we save state to pass resends to the
virtual mode, we also need to save the ICP whose need_resend we
reset since this does not need to be my ICP (vcpu->arch.icp) as is
incorrectly assumed by the current code. A new field rm_resend_icp
is added to the kvmppc_icp structure for this purpose.
Signed-off-by: Suresh Warrier <warrier@linux.vnet.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
2014-11-03 12:51:59 +08:00
|
|
|
if (resend) {
|
2015-03-20 17:39:48 +08:00
|
|
|
icp->n_check_resend++;
|
2015-03-20 17:39:47 +08:00
|
|
|
icp_rm_check_resend(xics, icp);
|
KVM: PPC: Book3S HV: Fix inaccuracies in ICP emulation for H_IPI
This fixes some inaccuracies in the state machine for the virtualized
ICP when implementing the H_IPI hcall (Set_MFFR and related states):
1. The old code wipes out any pending interrupts when the new MFRR is
more favored than the CPPR but less favored than a pending
interrupt (by always modifying xisr and the pending_pri). This can
cause us to lose a pending external interrupt.
The correct code here is to only modify the pending_pri and xisr in
the ICP if the MFRR is equal to or more favored than the current
pending pri (since in this case, it is guaranteed that that there
cannot be a pending external interrupt). The code changes are
required in both kvmppc_rm_h_ipi and kvmppc_h_ipi.
2. Again, in both kvmppc_rm_h_ipi and kvmppc_h_ipi, there is a check
for whether MFRR is being made less favored AND further if new MFFR
is also less favored than the current CPPR, we check for any
resends pending in the ICP. These checks look like they are
designed to cover the case where if the MFRR is being made less
favored, we opportunistically trigger a resend of any interrupts
that had been previously rejected. Although, this is not a state
described by PAPR, this is an action we actually need to do
especially if the CPPR is already at 0xFF. Because in this case,
the resend bit will stay on until another ICP state change which
may be a long time coming and the interrupt stays pending until
then. The current code which checks for MFRR < CPPR is broken when
CPPR is 0xFF since it will not get triggered in that case.
Ideally, we would want to do a resend only if
prio(pending_interrupt) < mfrr && prio(pending_interrupt) < cppr
where pending interrupt is the one that was rejected. But we don't
have the priority of the pending interrupt state saved, so we
simply trigger a resend whenever the MFRR is made less favored.
3. In kvmppc_rm_h_ipi, where we save state to pass resends to the
virtual mode, we also need to save the ICP whose need_resend we
reset since this does not need to be my ICP (vcpu->arch.icp) as is
incorrectly assumed by the current code. A new field rm_resend_icp
is added to the kvmppc_icp structure for this purpose.
Signed-off-by: Suresh Warrier <warrier@linux.vnet.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
2014-11-03 12:51:59 +08:00
|
|
|
}
|
2013-04-18 04:31:15 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2017-04-05 15:54:56 +08:00
|
|
|
unsigned long xics_rm_h_xirr(struct kvm_vcpu *vcpu)
|
2013-04-18 04:31:15 +08:00
|
|
|
{
|
|
|
|
union kvmppc_icp_state old_state, new_state;
|
|
|
|
struct kvmppc_xics *xics = vcpu->kvm->arch.xics;
|
|
|
|
struct kvmppc_icp *icp = vcpu->arch.icp;
|
|
|
|
u32 xirr;
|
|
|
|
|
|
|
|
if (!xics || !xics->real_mode)
|
|
|
|
return H_TOO_HARD;
|
|
|
|
|
|
|
|
/* First clear the interrupt */
|
|
|
|
icp_rm_clr_vcpu_irq(icp->vcpu);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* ICP State: Accept_Interrupt
|
|
|
|
*
|
|
|
|
* Return the pending interrupt (if any) along with the
|
|
|
|
* current CPPR, then clear the XISR & set CPPR to the
|
|
|
|
* pending priority
|
|
|
|
*/
|
|
|
|
do {
|
2015-01-07 05:41:46 +08:00
|
|
|
old_state = new_state = READ_ONCE(icp->state);
|
2013-04-18 04:31:15 +08:00
|
|
|
|
|
|
|
xirr = old_state.xisr | (((u32)old_state.cppr) << 24);
|
|
|
|
if (!old_state.xisr)
|
|
|
|
break;
|
|
|
|
new_state.cppr = new_state.pending_pri;
|
|
|
|
new_state.pending_pri = 0xff;
|
|
|
|
new_state.xisr = 0;
|
|
|
|
|
|
|
|
} while (!icp_rm_try_update(icp, old_state, new_state));
|
|
|
|
|
|
|
|
/* Return the result in GPR4 */
|
2018-05-07 14:20:07 +08:00
|
|
|
vcpu->arch.regs.gpr[4] = xirr;
|
2013-04-18 04:31:15 +08:00
|
|
|
|
|
|
|
return check_too_hard(xics, icp);
|
|
|
|
}
|
|
|
|
|
2017-04-05 15:54:56 +08:00
|
|
|
int xics_rm_h_ipi(struct kvm_vcpu *vcpu, unsigned long server,
|
|
|
|
unsigned long mfrr)
|
2013-04-18 04:31:15 +08:00
|
|
|
{
|
|
|
|
union kvmppc_icp_state old_state, new_state;
|
|
|
|
struct kvmppc_xics *xics = vcpu->kvm->arch.xics;
|
|
|
|
struct kvmppc_icp *icp, *this_icp = vcpu->arch.icp;
|
|
|
|
u32 reject;
|
|
|
|
bool resend;
|
|
|
|
bool local;
|
|
|
|
|
|
|
|
if (!xics || !xics->real_mode)
|
|
|
|
return H_TOO_HARD;
|
|
|
|
|
|
|
|
local = this_icp->server_num == server;
|
|
|
|
if (local)
|
|
|
|
icp = this_icp;
|
|
|
|
else
|
|
|
|
icp = kvmppc_xics_find_server(vcpu->kvm, server);
|
|
|
|
if (!icp)
|
|
|
|
return H_PARAMETER;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* ICP state: Set_MFRR
|
|
|
|
*
|
|
|
|
* If the CPPR is more favored than the new MFRR, then
|
|
|
|
* nothing needs to be done as there can be no XISR to
|
|
|
|
* reject.
|
|
|
|
*
|
KVM: PPC: Book3S HV: Fix inaccuracies in ICP emulation for H_IPI
This fixes some inaccuracies in the state machine for the virtualized
ICP when implementing the H_IPI hcall (Set_MFFR and related states):
1. The old code wipes out any pending interrupts when the new MFRR is
more favored than the CPPR but less favored than a pending
interrupt (by always modifying xisr and the pending_pri). This can
cause us to lose a pending external interrupt.
The correct code here is to only modify the pending_pri and xisr in
the ICP if the MFRR is equal to or more favored than the current
pending pri (since in this case, it is guaranteed that that there
cannot be a pending external interrupt). The code changes are
required in both kvmppc_rm_h_ipi and kvmppc_h_ipi.
2. Again, in both kvmppc_rm_h_ipi and kvmppc_h_ipi, there is a check
for whether MFRR is being made less favored AND further if new MFFR
is also less favored than the current CPPR, we check for any
resends pending in the ICP. These checks look like they are
designed to cover the case where if the MFRR is being made less
favored, we opportunistically trigger a resend of any interrupts
that had been previously rejected. Although, this is not a state
described by PAPR, this is an action we actually need to do
especially if the CPPR is already at 0xFF. Because in this case,
the resend bit will stay on until another ICP state change which
may be a long time coming and the interrupt stays pending until
then. The current code which checks for MFRR < CPPR is broken when
CPPR is 0xFF since it will not get triggered in that case.
Ideally, we would want to do a resend only if
prio(pending_interrupt) < mfrr && prio(pending_interrupt) < cppr
where pending interrupt is the one that was rejected. But we don't
have the priority of the pending interrupt state saved, so we
simply trigger a resend whenever the MFRR is made less favored.
3. In kvmppc_rm_h_ipi, where we save state to pass resends to the
virtual mode, we also need to save the ICP whose need_resend we
reset since this does not need to be my ICP (vcpu->arch.icp) as is
incorrectly assumed by the current code. A new field rm_resend_icp
is added to the kvmppc_icp structure for this purpose.
Signed-off-by: Suresh Warrier <warrier@linux.vnet.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
2014-11-03 12:51:59 +08:00
|
|
|
* ICP state: Check_IPI
|
|
|
|
*
|
2013-04-18 04:31:15 +08:00
|
|
|
* If the CPPR is less favored, then we might be replacing
|
KVM: PPC: Book3S HV: Fix inaccuracies in ICP emulation for H_IPI
This fixes some inaccuracies in the state machine for the virtualized
ICP when implementing the H_IPI hcall (Set_MFFR and related states):
1. The old code wipes out any pending interrupts when the new MFRR is
more favored than the CPPR but less favored than a pending
interrupt (by always modifying xisr and the pending_pri). This can
cause us to lose a pending external interrupt.
The correct code here is to only modify the pending_pri and xisr in
the ICP if the MFRR is equal to or more favored than the current
pending pri (since in this case, it is guaranteed that that there
cannot be a pending external interrupt). The code changes are
required in both kvmppc_rm_h_ipi and kvmppc_h_ipi.
2. Again, in both kvmppc_rm_h_ipi and kvmppc_h_ipi, there is a check
for whether MFRR is being made less favored AND further if new MFFR
is also less favored than the current CPPR, we check for any
resends pending in the ICP. These checks look like they are
designed to cover the case where if the MFRR is being made less
favored, we opportunistically trigger a resend of any interrupts
that had been previously rejected. Although, this is not a state
described by PAPR, this is an action we actually need to do
especially if the CPPR is already at 0xFF. Because in this case,
the resend bit will stay on until another ICP state change which
may be a long time coming and the interrupt stays pending until
then. The current code which checks for MFRR < CPPR is broken when
CPPR is 0xFF since it will not get triggered in that case.
Ideally, we would want to do a resend only if
prio(pending_interrupt) < mfrr && prio(pending_interrupt) < cppr
where pending interrupt is the one that was rejected. But we don't
have the priority of the pending interrupt state saved, so we
simply trigger a resend whenever the MFRR is made less favored.
3. In kvmppc_rm_h_ipi, where we save state to pass resends to the
virtual mode, we also need to save the ICP whose need_resend we
reset since this does not need to be my ICP (vcpu->arch.icp) as is
incorrectly assumed by the current code. A new field rm_resend_icp
is added to the kvmppc_icp structure for this purpose.
Signed-off-by: Suresh Warrier <warrier@linux.vnet.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
2014-11-03 12:51:59 +08:00
|
|
|
* an interrupt, and thus need to possibly reject it.
|
2013-04-18 04:31:15 +08:00
|
|
|
*
|
KVM: PPC: Book3S HV: Fix inaccuracies in ICP emulation for H_IPI
This fixes some inaccuracies in the state machine for the virtualized
ICP when implementing the H_IPI hcall (Set_MFFR and related states):
1. The old code wipes out any pending interrupts when the new MFRR is
more favored than the CPPR but less favored than a pending
interrupt (by always modifying xisr and the pending_pri). This can
cause us to lose a pending external interrupt.
The correct code here is to only modify the pending_pri and xisr in
the ICP if the MFRR is equal to or more favored than the current
pending pri (since in this case, it is guaranteed that that there
cannot be a pending external interrupt). The code changes are
required in both kvmppc_rm_h_ipi and kvmppc_h_ipi.
2. Again, in both kvmppc_rm_h_ipi and kvmppc_h_ipi, there is a check
for whether MFRR is being made less favored AND further if new MFFR
is also less favored than the current CPPR, we check for any
resends pending in the ICP. These checks look like they are
designed to cover the case where if the MFRR is being made less
favored, we opportunistically trigger a resend of any interrupts
that had been previously rejected. Although, this is not a state
described by PAPR, this is an action we actually need to do
especially if the CPPR is already at 0xFF. Because in this case,
the resend bit will stay on until another ICP state change which
may be a long time coming and the interrupt stays pending until
then. The current code which checks for MFRR < CPPR is broken when
CPPR is 0xFF since it will not get triggered in that case.
Ideally, we would want to do a resend only if
prio(pending_interrupt) < mfrr && prio(pending_interrupt) < cppr
where pending interrupt is the one that was rejected. But we don't
have the priority of the pending interrupt state saved, so we
simply trigger a resend whenever the MFRR is made less favored.
3. In kvmppc_rm_h_ipi, where we save state to pass resends to the
virtual mode, we also need to save the ICP whose need_resend we
reset since this does not need to be my ICP (vcpu->arch.icp) as is
incorrectly assumed by the current code. A new field rm_resend_icp
is added to the kvmppc_icp structure for this purpose.
Signed-off-by: Suresh Warrier <warrier@linux.vnet.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
2014-11-03 12:51:59 +08:00
|
|
|
* ICP State: IPI
|
|
|
|
*
|
|
|
|
* Besides rejecting any pending interrupts, we also
|
|
|
|
* update XISR and pending_pri to mark IPI as pending.
|
|
|
|
*
|
|
|
|
* PAPR does not describe this state, but if the MFRR is being
|
|
|
|
* made less favored than its earlier value, there might be
|
|
|
|
* a previously-rejected interrupt needing to be resent.
|
|
|
|
* Ideally, we would want to resend only if
|
|
|
|
* prio(pending_interrupt) < mfrr &&
|
|
|
|
* prio(pending_interrupt) < cppr
|
|
|
|
* where pending interrupt is the one that was rejected. But
|
|
|
|
* we don't have that state, so we simply trigger a resend
|
|
|
|
* whenever the MFRR is made less favored.
|
2013-04-18 04:31:15 +08:00
|
|
|
*/
|
|
|
|
do {
|
2015-01-07 05:41:46 +08:00
|
|
|
old_state = new_state = READ_ONCE(icp->state);
|
2013-04-18 04:31:15 +08:00
|
|
|
|
|
|
|
/* Set_MFRR */
|
|
|
|
new_state.mfrr = mfrr;
|
|
|
|
|
|
|
|
/* Check_IPI */
|
|
|
|
reject = 0;
|
|
|
|
resend = false;
|
|
|
|
if (mfrr < new_state.cppr) {
|
|
|
|
/* Reject a pending interrupt if not an IPI */
|
KVM: PPC: Book3S HV: Fix inaccuracies in ICP emulation for H_IPI
This fixes some inaccuracies in the state machine for the virtualized
ICP when implementing the H_IPI hcall (Set_MFFR and related states):
1. The old code wipes out any pending interrupts when the new MFRR is
more favored than the CPPR but less favored than a pending
interrupt (by always modifying xisr and the pending_pri). This can
cause us to lose a pending external interrupt.
The correct code here is to only modify the pending_pri and xisr in
the ICP if the MFRR is equal to or more favored than the current
pending pri (since in this case, it is guaranteed that that there
cannot be a pending external interrupt). The code changes are
required in both kvmppc_rm_h_ipi and kvmppc_h_ipi.
2. Again, in both kvmppc_rm_h_ipi and kvmppc_h_ipi, there is a check
for whether MFRR is being made less favored AND further if new MFFR
is also less favored than the current CPPR, we check for any
resends pending in the ICP. These checks look like they are
designed to cover the case where if the MFRR is being made less
favored, we opportunistically trigger a resend of any interrupts
that had been previously rejected. Although, this is not a state
described by PAPR, this is an action we actually need to do
especially if the CPPR is already at 0xFF. Because in this case,
the resend bit will stay on until another ICP state change which
may be a long time coming and the interrupt stays pending until
then. The current code which checks for MFRR < CPPR is broken when
CPPR is 0xFF since it will not get triggered in that case.
Ideally, we would want to do a resend only if
prio(pending_interrupt) < mfrr && prio(pending_interrupt) < cppr
where pending interrupt is the one that was rejected. But we don't
have the priority of the pending interrupt state saved, so we
simply trigger a resend whenever the MFRR is made less favored.
3. In kvmppc_rm_h_ipi, where we save state to pass resends to the
virtual mode, we also need to save the ICP whose need_resend we
reset since this does not need to be my ICP (vcpu->arch.icp) as is
incorrectly assumed by the current code. A new field rm_resend_icp
is added to the kvmppc_icp structure for this purpose.
Signed-off-by: Suresh Warrier <warrier@linux.vnet.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
2014-11-03 12:51:59 +08:00
|
|
|
if (mfrr <= new_state.pending_pri) {
|
2013-04-18 04:31:15 +08:00
|
|
|
reject = new_state.xisr;
|
KVM: PPC: Book3S HV: Fix inaccuracies in ICP emulation for H_IPI
This fixes some inaccuracies in the state machine for the virtualized
ICP when implementing the H_IPI hcall (Set_MFFR and related states):
1. The old code wipes out any pending interrupts when the new MFRR is
more favored than the CPPR but less favored than a pending
interrupt (by always modifying xisr and the pending_pri). This can
cause us to lose a pending external interrupt.
The correct code here is to only modify the pending_pri and xisr in
the ICP if the MFRR is equal to or more favored than the current
pending pri (since in this case, it is guaranteed that that there
cannot be a pending external interrupt). The code changes are
required in both kvmppc_rm_h_ipi and kvmppc_h_ipi.
2. Again, in both kvmppc_rm_h_ipi and kvmppc_h_ipi, there is a check
for whether MFRR is being made less favored AND further if new MFFR
is also less favored than the current CPPR, we check for any
resends pending in the ICP. These checks look like they are
designed to cover the case where if the MFRR is being made less
favored, we opportunistically trigger a resend of any interrupts
that had been previously rejected. Although, this is not a state
described by PAPR, this is an action we actually need to do
especially if the CPPR is already at 0xFF. Because in this case,
the resend bit will stay on until another ICP state change which
may be a long time coming and the interrupt stays pending until
then. The current code which checks for MFRR < CPPR is broken when
CPPR is 0xFF since it will not get triggered in that case.
Ideally, we would want to do a resend only if
prio(pending_interrupt) < mfrr && prio(pending_interrupt) < cppr
where pending interrupt is the one that was rejected. But we don't
have the priority of the pending interrupt state saved, so we
simply trigger a resend whenever the MFRR is made less favored.
3. In kvmppc_rm_h_ipi, where we save state to pass resends to the
virtual mode, we also need to save the ICP whose need_resend we
reset since this does not need to be my ICP (vcpu->arch.icp) as is
incorrectly assumed by the current code. A new field rm_resend_icp
is added to the kvmppc_icp structure for this purpose.
Signed-off-by: Suresh Warrier <warrier@linux.vnet.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
2014-11-03 12:51:59 +08:00
|
|
|
new_state.pending_pri = mfrr;
|
|
|
|
new_state.xisr = XICS_IPI;
|
|
|
|
}
|
2013-04-18 04:31:15 +08:00
|
|
|
}
|
|
|
|
|
KVM: PPC: Book3S HV: Fix inaccuracies in ICP emulation for H_IPI
This fixes some inaccuracies in the state machine for the virtualized
ICP when implementing the H_IPI hcall (Set_MFFR and related states):
1. The old code wipes out any pending interrupts when the new MFRR is
more favored than the CPPR but less favored than a pending
interrupt (by always modifying xisr and the pending_pri). This can
cause us to lose a pending external interrupt.
The correct code here is to only modify the pending_pri and xisr in
the ICP if the MFRR is equal to or more favored than the current
pending pri (since in this case, it is guaranteed that that there
cannot be a pending external interrupt). The code changes are
required in both kvmppc_rm_h_ipi and kvmppc_h_ipi.
2. Again, in both kvmppc_rm_h_ipi and kvmppc_h_ipi, there is a check
for whether MFRR is being made less favored AND further if new MFFR
is also less favored than the current CPPR, we check for any
resends pending in the ICP. These checks look like they are
designed to cover the case where if the MFRR is being made less
favored, we opportunistically trigger a resend of any interrupts
that had been previously rejected. Although, this is not a state
described by PAPR, this is an action we actually need to do
especially if the CPPR is already at 0xFF. Because in this case,
the resend bit will stay on until another ICP state change which
may be a long time coming and the interrupt stays pending until
then. The current code which checks for MFRR < CPPR is broken when
CPPR is 0xFF since it will not get triggered in that case.
Ideally, we would want to do a resend only if
prio(pending_interrupt) < mfrr && prio(pending_interrupt) < cppr
where pending interrupt is the one that was rejected. But we don't
have the priority of the pending interrupt state saved, so we
simply trigger a resend whenever the MFRR is made less favored.
3. In kvmppc_rm_h_ipi, where we save state to pass resends to the
virtual mode, we also need to save the ICP whose need_resend we
reset since this does not need to be my ICP (vcpu->arch.icp) as is
incorrectly assumed by the current code. A new field rm_resend_icp
is added to the kvmppc_icp structure for this purpose.
Signed-off-by: Suresh Warrier <warrier@linux.vnet.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
2014-11-03 12:51:59 +08:00
|
|
|
if (mfrr > old_state.mfrr) {
|
2013-04-18 04:31:15 +08:00
|
|
|
resend = new_state.need_resend;
|
|
|
|
new_state.need_resend = 0;
|
|
|
|
}
|
|
|
|
} while (!icp_rm_try_update(icp, old_state, new_state));
|
|
|
|
|
2015-03-20 17:39:47 +08:00
|
|
|
/* Handle reject in real mode */
|
2013-04-18 04:31:15 +08:00
|
|
|
if (reject && reject != XICS_IPI) {
|
2015-03-20 17:39:48 +08:00
|
|
|
this_icp->n_reject++;
|
2016-11-11 12:57:36 +08:00
|
|
|
icp_rm_deliver_irq(xics, icp, reject, false);
|
2013-04-18 04:31:15 +08:00
|
|
|
}
|
|
|
|
|
2015-03-20 17:39:47 +08:00
|
|
|
/* Handle resends in real mode */
|
KVM: PPC: Book3S HV: Fix inaccuracies in ICP emulation for H_IPI
This fixes some inaccuracies in the state machine for the virtualized
ICP when implementing the H_IPI hcall (Set_MFFR and related states):
1. The old code wipes out any pending interrupts when the new MFRR is
more favored than the CPPR but less favored than a pending
interrupt (by always modifying xisr and the pending_pri). This can
cause us to lose a pending external interrupt.
The correct code here is to only modify the pending_pri and xisr in
the ICP if the MFRR is equal to or more favored than the current
pending pri (since in this case, it is guaranteed that that there
cannot be a pending external interrupt). The code changes are
required in both kvmppc_rm_h_ipi and kvmppc_h_ipi.
2. Again, in both kvmppc_rm_h_ipi and kvmppc_h_ipi, there is a check
for whether MFRR is being made less favored AND further if new MFFR
is also less favored than the current CPPR, we check for any
resends pending in the ICP. These checks look like they are
designed to cover the case where if the MFRR is being made less
favored, we opportunistically trigger a resend of any interrupts
that had been previously rejected. Although, this is not a state
described by PAPR, this is an action we actually need to do
especially if the CPPR is already at 0xFF. Because in this case,
the resend bit will stay on until another ICP state change which
may be a long time coming and the interrupt stays pending until
then. The current code which checks for MFRR < CPPR is broken when
CPPR is 0xFF since it will not get triggered in that case.
Ideally, we would want to do a resend only if
prio(pending_interrupt) < mfrr && prio(pending_interrupt) < cppr
where pending interrupt is the one that was rejected. But we don't
have the priority of the pending interrupt state saved, so we
simply trigger a resend whenever the MFRR is made less favored.
3. In kvmppc_rm_h_ipi, where we save state to pass resends to the
virtual mode, we also need to save the ICP whose need_resend we
reset since this does not need to be my ICP (vcpu->arch.icp) as is
incorrectly assumed by the current code. A new field rm_resend_icp
is added to the kvmppc_icp structure for this purpose.
Signed-off-by: Suresh Warrier <warrier@linux.vnet.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
2014-11-03 12:51:59 +08:00
|
|
|
if (resend) {
|
2015-03-20 17:39:48 +08:00
|
|
|
this_icp->n_check_resend++;
|
2015-03-20 17:39:47 +08:00
|
|
|
icp_rm_check_resend(xics, icp);
|
KVM: PPC: Book3S HV: Fix inaccuracies in ICP emulation for H_IPI
This fixes some inaccuracies in the state machine for the virtualized
ICP when implementing the H_IPI hcall (Set_MFFR and related states):
1. The old code wipes out any pending interrupts when the new MFRR is
more favored than the CPPR but less favored than a pending
interrupt (by always modifying xisr and the pending_pri). This can
cause us to lose a pending external interrupt.
The correct code here is to only modify the pending_pri and xisr in
the ICP if the MFRR is equal to or more favored than the current
pending pri (since in this case, it is guaranteed that that there
cannot be a pending external interrupt). The code changes are
required in both kvmppc_rm_h_ipi and kvmppc_h_ipi.
2. Again, in both kvmppc_rm_h_ipi and kvmppc_h_ipi, there is a check
for whether MFRR is being made less favored AND further if new MFFR
is also less favored than the current CPPR, we check for any
resends pending in the ICP. These checks look like they are
designed to cover the case where if the MFRR is being made less
favored, we opportunistically trigger a resend of any interrupts
that had been previously rejected. Although, this is not a state
described by PAPR, this is an action we actually need to do
especially if the CPPR is already at 0xFF. Because in this case,
the resend bit will stay on until another ICP state change which
may be a long time coming and the interrupt stays pending until
then. The current code which checks for MFRR < CPPR is broken when
CPPR is 0xFF since it will not get triggered in that case.
Ideally, we would want to do a resend only if
prio(pending_interrupt) < mfrr && prio(pending_interrupt) < cppr
where pending interrupt is the one that was rejected. But we don't
have the priority of the pending interrupt state saved, so we
simply trigger a resend whenever the MFRR is made less favored.
3. In kvmppc_rm_h_ipi, where we save state to pass resends to the
virtual mode, we also need to save the ICP whose need_resend we
reset since this does not need to be my ICP (vcpu->arch.icp) as is
incorrectly assumed by the current code. A new field rm_resend_icp
is added to the kvmppc_icp structure for this purpose.
Signed-off-by: Suresh Warrier <warrier@linux.vnet.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
2014-11-03 12:51:59 +08:00
|
|
|
}
|
2013-04-18 04:31:15 +08:00
|
|
|
|
|
|
|
return check_too_hard(xics, this_icp);
|
|
|
|
}
|
|
|
|
|
2017-04-05 15:54:56 +08:00
|
|
|
int xics_rm_h_cppr(struct kvm_vcpu *vcpu, unsigned long cppr)
|
2013-04-18 04:31:15 +08:00
|
|
|
{
|
|
|
|
union kvmppc_icp_state old_state, new_state;
|
|
|
|
struct kvmppc_xics *xics = vcpu->kvm->arch.xics;
|
|
|
|
struct kvmppc_icp *icp = vcpu->arch.icp;
|
|
|
|
u32 reject;
|
|
|
|
|
|
|
|
if (!xics || !xics->real_mode)
|
|
|
|
return H_TOO_HARD;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* ICP State: Set_CPPR
|
|
|
|
*
|
|
|
|
* We can safely compare the new value with the current
|
|
|
|
* value outside of the transaction as the CPPR is only
|
|
|
|
* ever changed by the processor on itself
|
|
|
|
*/
|
|
|
|
if (cppr > icp->state.cppr) {
|
|
|
|
icp_rm_down_cppr(xics, icp, cppr);
|
|
|
|
goto bail;
|
|
|
|
} else if (cppr == icp->state.cppr)
|
|
|
|
return H_SUCCESS;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* ICP State: Up_CPPR
|
|
|
|
*
|
|
|
|
* The processor is raising its priority, this can result
|
|
|
|
* in a rejection of a pending interrupt:
|
|
|
|
*
|
|
|
|
* ICP State: Reject_Current
|
|
|
|
*
|
|
|
|
* We can remove EE from the current processor, the update
|
|
|
|
* transaction will set it again if needed
|
|
|
|
*/
|
|
|
|
icp_rm_clr_vcpu_irq(icp->vcpu);
|
|
|
|
|
|
|
|
do {
|
2015-01-07 05:41:46 +08:00
|
|
|
old_state = new_state = READ_ONCE(icp->state);
|
2013-04-18 04:31:15 +08:00
|
|
|
|
|
|
|
reject = 0;
|
|
|
|
new_state.cppr = cppr;
|
|
|
|
|
|
|
|
if (cppr <= new_state.pending_pri) {
|
|
|
|
reject = new_state.xisr;
|
|
|
|
new_state.xisr = 0;
|
|
|
|
new_state.pending_pri = 0xff;
|
|
|
|
}
|
|
|
|
|
|
|
|
} while (!icp_rm_try_update(icp, old_state, new_state));
|
|
|
|
|
2015-03-20 17:39:47 +08:00
|
|
|
/*
|
|
|
|
* Check for rejects. They are handled by doing a new delivery
|
|
|
|
* attempt (see comments in icp_rm_deliver_irq).
|
|
|
|
*/
|
2013-04-18 04:31:15 +08:00
|
|
|
if (reject && reject != XICS_IPI) {
|
2015-03-20 17:39:48 +08:00
|
|
|
icp->n_reject++;
|
2016-11-11 12:57:36 +08:00
|
|
|
icp_rm_deliver_irq(xics, icp, reject, false);
|
2013-04-18 04:31:15 +08:00
|
|
|
}
|
|
|
|
bail:
|
|
|
|
return check_too_hard(xics, icp);
|
|
|
|
}
|
|
|
|
|
KVM: PPC: Book 3S: XICS: Implement ICS P/Q states
This patch implements P(Presented)/Q(Queued) states for ICS irqs.
When the interrupt is presented, set P. Present if P was not set.
If P is already set, don't present again, set Q.
When the interrupt is EOI'ed, move Q into P (and clear Q). If it is
set, re-present.
The asserted flag used by LSI is also incorporated into the P bit.
When the irq state is saved, P/Q bits are also saved, they need some
qemu modifications to be recognized and passed around to be restored.
KVM_XICS_PENDING bit set and saved should also indicate
KVM_XICS_PRESENTED bit set and saved. But it is possible some old
code doesn't have/recognize the P bit, so when we restore, we set P
for PENDING bit, too.
The idea and much of the code come from Ben.
Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2016-11-11 12:57:35 +08:00
|
|
|
static int ics_rm_eoi(struct kvm_vcpu *vcpu, u32 irq)
|
2013-04-18 04:31:15 +08:00
|
|
|
{
|
|
|
|
struct kvmppc_xics *xics = vcpu->kvm->arch.xics;
|
|
|
|
struct kvmppc_icp *icp = vcpu->arch.icp;
|
|
|
|
struct kvmppc_ics *ics;
|
|
|
|
struct ics_irq_state *state;
|
|
|
|
u16 src;
|
KVM: PPC: Book 3S: XICS: Implement ICS P/Q states
This patch implements P(Presented)/Q(Queued) states for ICS irqs.
When the interrupt is presented, set P. Present if P was not set.
If P is already set, don't present again, set Q.
When the interrupt is EOI'ed, move Q into P (and clear Q). If it is
set, re-present.
The asserted flag used by LSI is also incorporated into the P bit.
When the irq state is saved, P/Q bits are also saved, they need some
qemu modifications to be recognized and passed around to be restored.
KVM_XICS_PENDING bit set and saved should also indicate
KVM_XICS_PRESENTED bit set and saved. But it is possible some old
code doesn't have/recognize the P bit, so when we restore, we set P
for PENDING bit, too.
The idea and much of the code come from Ben.
Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2016-11-11 12:57:35 +08:00
|
|
|
u32 pq_old, pq_new;
|
2013-04-18 04:31:15 +08:00
|
|
|
|
|
|
|
/*
|
KVM: PPC: Book 3S: XICS: Implement ICS P/Q states
This patch implements P(Presented)/Q(Queued) states for ICS irqs.
When the interrupt is presented, set P. Present if P was not set.
If P is already set, don't present again, set Q.
When the interrupt is EOI'ed, move Q into P (and clear Q). If it is
set, re-present.
The asserted flag used by LSI is also incorporated into the P bit.
When the irq state is saved, P/Q bits are also saved, they need some
qemu modifications to be recognized and passed around to be restored.
KVM_XICS_PENDING bit set and saved should also indicate
KVM_XICS_PRESENTED bit set and saved. But it is possible some old
code doesn't have/recognize the P bit, so when we restore, we set P
for PENDING bit, too.
The idea and much of the code come from Ben.
Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2016-11-11 12:57:35 +08:00
|
|
|
* ICS EOI handling: For LSI, if P bit is still set, we need to
|
|
|
|
* resend it.
|
2013-04-18 04:31:15 +08:00
|
|
|
*
|
KVM: PPC: Book 3S: XICS: Implement ICS P/Q states
This patch implements P(Presented)/Q(Queued) states for ICS irqs.
When the interrupt is presented, set P. Present if P was not set.
If P is already set, don't present again, set Q.
When the interrupt is EOI'ed, move Q into P (and clear Q). If it is
set, re-present.
The asserted flag used by LSI is also incorporated into the P bit.
When the irq state is saved, P/Q bits are also saved, they need some
qemu modifications to be recognized and passed around to be restored.
KVM_XICS_PENDING bit set and saved should also indicate
KVM_XICS_PRESENTED bit set and saved. But it is possible some old
code doesn't have/recognize the P bit, so when we restore, we set P
for PENDING bit, too.
The idea and much of the code come from Ben.
Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2016-11-11 12:57:35 +08:00
|
|
|
* For MSI, we move Q bit into P (and clear Q). If it is set,
|
|
|
|
* resend it.
|
2013-04-18 04:31:15 +08:00
|
|
|
*/
|
|
|
|
|
|
|
|
ics = kvmppc_xics_find_ics(xics, irq, &src);
|
|
|
|
if (!ics)
|
|
|
|
goto bail;
|
KVM: PPC: Book 3S: XICS: Implement ICS P/Q states
This patch implements P(Presented)/Q(Queued) states for ICS irqs.
When the interrupt is presented, set P. Present if P was not set.
If P is already set, don't present again, set Q.
When the interrupt is EOI'ed, move Q into P (and clear Q). If it is
set, re-present.
The asserted flag used by LSI is also incorporated into the P bit.
When the irq state is saved, P/Q bits are also saved, they need some
qemu modifications to be recognized and passed around to be restored.
KVM_XICS_PENDING bit set and saved should also indicate
KVM_XICS_PRESENTED bit set and saved. But it is possible some old
code doesn't have/recognize the P bit, so when we restore, we set P
for PENDING bit, too.
The idea and much of the code come from Ben.
Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2016-11-11 12:57:35 +08:00
|
|
|
|
2013-04-18 04:31:15 +08:00
|
|
|
state = &ics->irq_state[src];
|
|
|
|
|
KVM: PPC: Book 3S: XICS: Implement ICS P/Q states
This patch implements P(Presented)/Q(Queued) states for ICS irqs.
When the interrupt is presented, set P. Present if P was not set.
If P is already set, don't present again, set Q.
When the interrupt is EOI'ed, move Q into P (and clear Q). If it is
set, re-present.
The asserted flag used by LSI is also incorporated into the P bit.
When the irq state is saved, P/Q bits are also saved, they need some
qemu modifications to be recognized and passed around to be restored.
KVM_XICS_PENDING bit set and saved should also indicate
KVM_XICS_PRESENTED bit set and saved. But it is possible some old
code doesn't have/recognize the P bit, so when we restore, we set P
for PENDING bit, too.
The idea and much of the code come from Ben.
Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2016-11-11 12:57:35 +08:00
|
|
|
if (state->lsi)
|
|
|
|
pq_new = state->pq_state;
|
|
|
|
else
|
|
|
|
do {
|
|
|
|
pq_old = state->pq_state;
|
|
|
|
pq_new = pq_old >> 1;
|
|
|
|
} while (cmpxchg(&state->pq_state, pq_old, pq_new) != pq_old);
|
|
|
|
|
|
|
|
if (pq_new & PQ_PRESENTED)
|
2016-11-11 12:57:36 +08:00
|
|
|
icp_rm_deliver_irq(xics, NULL, irq, false);
|
2014-06-30 18:51:14 +08:00
|
|
|
|
|
|
|
if (!hlist_empty(&vcpu->kvm->irq_ack_notifier_list)) {
|
|
|
|
icp->rm_action |= XICS_RM_NOTIFY_EOI;
|
|
|
|
icp->rm_eoied_irq = irq;
|
|
|
|
}
|
KVM: PPC: Book3S HV: Set server for passed-through interrupts
When a guest has a PCI pass-through device with an interrupt, it
will direct the interrupt to a particular guest VCPU. In fact the
physical interrupt might arrive on any CPU, and then get
delivered to the target VCPU in the emulated XICS (guest interrupt
controller), and eventually delivered to the target VCPU.
Now that we have code to handle device interrupts in real mode
without exiting to the host kernel, there is an advantage to having
the device interrupt arrive on the same sub(core) as the target
VCPU is running on. In this situation, the interrupt can be
delivered to the target VCPU without any exit to the host kernel
(using a hypervisor doorbell interrupt between threads if
necessary).
This patch aims to get passed-through device interrupts arriving
on the correct core by setting the interrupt server in the real
hardware XICS for the interrupt to the first thread in the (sub)core
where its target VCPU is running. We do this in the real-mode H_EOI
code because the H_EOI handler already needs to look at the
emulated ICS state for the interrupt (whereas the H_XIRR handler
doesn't), and we know we are running in the target VCPU context
at that point.
We set the server CPU in hardware using an OPAL call, regardless of
what the IRQ affinity mask for the interrupt says, and without
updating the affinity mask. This amounts to saying that when an
interrupt is passed through to a guest, as a matter of policy we
allow the guest's affinity for the interrupt to override the host's.
This is inspired by an earlier patch from Suresh Warrier, although
none of this code came from that earlier patch.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2016-08-19 13:35:56 +08:00
|
|
|
|
2016-08-19 13:35:57 +08:00
|
|
|
if (state->host_irq) {
|
|
|
|
++vcpu->stat.pthru_all;
|
|
|
|
if (state->intr_cpu != -1) {
|
|
|
|
int pcpu = raw_smp_processor_id();
|
|
|
|
|
|
|
|
pcpu = cpu_first_thread_sibling(pcpu);
|
|
|
|
++vcpu->stat.pthru_host;
|
|
|
|
if (state->intr_cpu != pcpu) {
|
|
|
|
++vcpu->stat.pthru_bad_aff;
|
2017-02-07 13:03:17 +08:00
|
|
|
xics_opal_set_server(state->host_irq, pcpu);
|
2016-08-19 13:35:57 +08:00
|
|
|
}
|
|
|
|
state->intr_cpu = -1;
|
|
|
|
}
|
KVM: PPC: Book3S HV: Set server for passed-through interrupts
When a guest has a PCI pass-through device with an interrupt, it
will direct the interrupt to a particular guest VCPU. In fact the
physical interrupt might arrive on any CPU, and then get
delivered to the target VCPU in the emulated XICS (guest interrupt
controller), and eventually delivered to the target VCPU.
Now that we have code to handle device interrupts in real mode
without exiting to the host kernel, there is an advantage to having
the device interrupt arrive on the same sub(core) as the target
VCPU is running on. In this situation, the interrupt can be
delivered to the target VCPU without any exit to the host kernel
(using a hypervisor doorbell interrupt between threads if
necessary).
This patch aims to get passed-through device interrupts arriving
on the correct core by setting the interrupt server in the real
hardware XICS for the interrupt to the first thread in the (sub)core
where its target VCPU is running. We do this in the real-mode H_EOI
code because the H_EOI handler already needs to look at the
emulated ICS state for the interrupt (whereas the H_XIRR handler
doesn't), and we know we are running in the target VCPU context
at that point.
We set the server CPU in hardware using an OPAL call, regardless of
what the IRQ affinity mask for the interrupt says, and without
updating the affinity mask. This amounts to saying that when an
interrupt is passed through to a guest, as a matter of policy we
allow the guest's affinity for the interrupt to override the host's.
This is inspired by an earlier patch from Suresh Warrier, although
none of this code came from that earlier patch.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2016-08-19 13:35:56 +08:00
|
|
|
}
|
KVM: PPC: Book 3S: XICS: Implement ICS P/Q states
This patch implements P(Presented)/Q(Queued) states for ICS irqs.
When the interrupt is presented, set P. Present if P was not set.
If P is already set, don't present again, set Q.
When the interrupt is EOI'ed, move Q into P (and clear Q). If it is
set, re-present.
The asserted flag used by LSI is also incorporated into the P bit.
When the irq state is saved, P/Q bits are also saved, they need some
qemu modifications to be recognized and passed around to be restored.
KVM_XICS_PENDING bit set and saved should also indicate
KVM_XICS_PRESENTED bit set and saved. But it is possible some old
code doesn't have/recognize the P bit, so when we restore, we set P
for PENDING bit, too.
The idea and much of the code come from Ben.
Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2016-11-11 12:57:35 +08:00
|
|
|
|
2013-04-18 04:31:15 +08:00
|
|
|
bail:
|
|
|
|
return check_too_hard(xics, icp);
|
|
|
|
}
|
2015-12-18 04:59:09 +08:00
|
|
|
|
2017-04-05 15:54:56 +08:00
|
|
|
int xics_rm_h_eoi(struct kvm_vcpu *vcpu, unsigned long xirr)
|
KVM: PPC: Book 3S: XICS: Implement ICS P/Q states
This patch implements P(Presented)/Q(Queued) states for ICS irqs.
When the interrupt is presented, set P. Present if P was not set.
If P is already set, don't present again, set Q.
When the interrupt is EOI'ed, move Q into P (and clear Q). If it is
set, re-present.
The asserted flag used by LSI is also incorporated into the P bit.
When the irq state is saved, P/Q bits are also saved, they need some
qemu modifications to be recognized and passed around to be restored.
KVM_XICS_PENDING bit set and saved should also indicate
KVM_XICS_PRESENTED bit set and saved. But it is possible some old
code doesn't have/recognize the P bit, so when we restore, we set P
for PENDING bit, too.
The idea and much of the code come from Ben.
Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2016-11-11 12:57:35 +08:00
|
|
|
{
|
|
|
|
struct kvmppc_xics *xics = vcpu->kvm->arch.xics;
|
|
|
|
struct kvmppc_icp *icp = vcpu->arch.icp;
|
|
|
|
u32 irq = xirr & 0x00ffffff;
|
|
|
|
|
|
|
|
if (!xics || !xics->real_mode)
|
|
|
|
return H_TOO_HARD;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* ICP State: EOI
|
|
|
|
*
|
|
|
|
* Note: If EOI is incorrectly used by SW to lower the CPPR
|
|
|
|
* value (ie more favored), we do not check for rejection of
|
|
|
|
* a pending interrupt, this is a SW error and PAPR specifies
|
|
|
|
* that we don't have to deal with it.
|
|
|
|
*
|
|
|
|
* The sending of an EOI to the ICS is handled after the
|
|
|
|
* CPPR update
|
|
|
|
*
|
|
|
|
* ICP State: Down_CPPR which we handle
|
|
|
|
* in a separate function as it's shared with H_CPPR.
|
|
|
|
*/
|
|
|
|
icp_rm_down_cppr(xics, icp, xirr >> 24);
|
|
|
|
|
|
|
|
/* IPIs have no EOI */
|
|
|
|
if (irq == XICS_IPI)
|
|
|
|
return check_too_hard(xics, icp);
|
|
|
|
|
|
|
|
return ics_rm_eoi(vcpu, irq);
|
|
|
|
}
|
|
|
|
|
2020-09-21 19:22:11 +08:00
|
|
|
static unsigned long eoi_rc;
|
KVM: PPC: Book3S HV: Handle passthrough interrupts in guest
Currently, KVM switches back to the host to handle any external
interrupt (when the interrupt is received while running in the
guest). This patch updates real-mode KVM to check if an interrupt
is generated by a passthrough adapter that is owned by this guest.
If so, the real mode KVM will directly inject the corresponding
virtual interrupt to the guest VCPU's ICS and also EOI the interrupt
in hardware. In short, the interrupt is handled entirely in real
mode in the guest context without switching back to the host.
In some rare cases, the interrupt cannot be completely handled in
real mode, for instance, a VCPU that is sleeping needs to be woken
up. In this case, KVM simply switches back to the host with trap
reason set to 0x500. This works, but it is clearly not very efficient.
A following patch will distinguish this case and handle it
correctly in the host. Note that we can use the existing
check_too_hard() routine even though we are not in a hypercall to
determine if there is unfinished business that needs to be
completed in host virtual mode.
The patch assumes that the mapping between hardware interrupt IRQ
and virtual IRQ to be injected to the guest already exists for the
PCI passthrough interrupts that need to be handled in real mode.
If the mapping does not exist, KVM falls back to the default
existing behavior.
The KVM real mode code reads mappings from the mapped array in the
passthrough IRQ map without taking any lock. We carefully order the
loads and stores of the fields in the kvmppc_irq_map data structure
using memory barriers to avoid an inconsistent mapping being seen by
the reader. Thus, although it is possible to miss a map entry, it is
not possible to read a stale value.
[paulus@ozlabs.org - get irq_chip from irq_map rather than pimap,
pulled out powernv eoi change into a separate patch, made
kvmppc_read_intr get the vcpu from the paca rather than being
passed in, rewrote the logic at the end of kvmppc_read_intr to
avoid deep indentation, simplified logic in book3s_hv_rmhandlers.S
since we were always restoring SRR0/1 anyway, get rid of the cached
array (just use the mapped array), removed the kick_all_cpus_sync()
call, clear saved_xirr PACA field when we handle the interrupt in
real mode, fix compilation with CONFIG_KVM_XICS=n.]
Signed-off-by: Suresh Warrier <warrier@linux.vnet.ibm.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2016-08-19 13:35:51 +08:00
|
|
|
|
KVM: PPC: Book3S HV: Use OPAL XICS emulation on POWER9
POWER9 includes a new interrupt controller, called XIVE, which is
quite different from the XICS interrupt controller on POWER7 and
POWER8 machines. KVM-HV accesses the XICS directly in several places
in order to send and clear IPIs and handle interrupts from PCI
devices being passed through to the guest.
In order to make the transition to XIVE easier, OPAL firmware will
include an emulation of XICS on top of XIVE. Access to the emulated
XICS is via OPAL calls. The one complication is that the EOI
(end-of-interrupt) function can now return a value indicating that
another interrupt is pending; in this case, the XIVE will not signal
an interrupt in hardware to the CPU, and software is supposed to
acknowledge the new interrupt without waiting for another interrupt
to be delivered in hardware.
This adapts KVM-HV to use the OPAL calls on machines where there is
no XICS hardware. When there is no XICS, we look for a device-tree
node with "ibm,opal-intc" in its compatible property, which is how
OPAL indicates that it provides XICS emulation.
In order to handle the EOI return value, kvmppc_read_intr() has
become kvmppc_read_one_intr(), with a boolean variable passed by
reference which can be set by the EOI functions to indicate that
another interrupt is pending. The new kvmppc_read_intr() keeps
calling kvmppc_read_one_intr() until there are no more interrupts
to process. The return value from kvmppc_read_intr() is the
largest non-zero value of the returns from kvmppc_read_one_intr().
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2016-11-18 06:02:08 +08:00
|
|
|
static void icp_eoi(struct irq_chip *c, u32 hwirq, __be32 xirr, bool *again)
|
KVM: PPC: Book3S HV: Handle passthrough interrupts in guest
Currently, KVM switches back to the host to handle any external
interrupt (when the interrupt is received while running in the
guest). This patch updates real-mode KVM to check if an interrupt
is generated by a passthrough adapter that is owned by this guest.
If so, the real mode KVM will directly inject the corresponding
virtual interrupt to the guest VCPU's ICS and also EOI the interrupt
in hardware. In short, the interrupt is handled entirely in real
mode in the guest context without switching back to the host.
In some rare cases, the interrupt cannot be completely handled in
real mode, for instance, a VCPU that is sleeping needs to be woken
up. In this case, KVM simply switches back to the host with trap
reason set to 0x500. This works, but it is clearly not very efficient.
A following patch will distinguish this case and handle it
correctly in the host. Note that we can use the existing
check_too_hard() routine even though we are not in a hypercall to
determine if there is unfinished business that needs to be
completed in host virtual mode.
The patch assumes that the mapping between hardware interrupt IRQ
and virtual IRQ to be injected to the guest already exists for the
PCI passthrough interrupts that need to be handled in real mode.
If the mapping does not exist, KVM falls back to the default
existing behavior.
The KVM real mode code reads mappings from the mapped array in the
passthrough IRQ map without taking any lock. We carefully order the
loads and stores of the fields in the kvmppc_irq_map data structure
using memory barriers to avoid an inconsistent mapping being seen by
the reader. Thus, although it is possible to miss a map entry, it is
not possible to read a stale value.
[paulus@ozlabs.org - get irq_chip from irq_map rather than pimap,
pulled out powernv eoi change into a separate patch, made
kvmppc_read_intr get the vcpu from the paca rather than being
passed in, rewrote the logic at the end of kvmppc_read_intr to
avoid deep indentation, simplified logic in book3s_hv_rmhandlers.S
since we were always restoring SRR0/1 anyway, get rid of the cached
array (just use the mapped array), removed the kick_all_cpus_sync()
call, clear saved_xirr PACA field when we handle the interrupt in
real mode, fix compilation with CONFIG_KVM_XICS=n.]
Signed-off-by: Suresh Warrier <warrier@linux.vnet.ibm.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2016-08-19 13:35:51 +08:00
|
|
|
{
|
2017-04-05 15:54:54 +08:00
|
|
|
void __iomem *xics_phys;
|
KVM: PPC: Book3S HV: Handle passthrough interrupts in guest
Currently, KVM switches back to the host to handle any external
interrupt (when the interrupt is received while running in the
guest). This patch updates real-mode KVM to check if an interrupt
is generated by a passthrough adapter that is owned by this guest.
If so, the real mode KVM will directly inject the corresponding
virtual interrupt to the guest VCPU's ICS and also EOI the interrupt
in hardware. In short, the interrupt is handled entirely in real
mode in the guest context without switching back to the host.
In some rare cases, the interrupt cannot be completely handled in
real mode, for instance, a VCPU that is sleeping needs to be woken
up. In this case, KVM simply switches back to the host with trap
reason set to 0x500. This works, but it is clearly not very efficient.
A following patch will distinguish this case and handle it
correctly in the host. Note that we can use the existing
check_too_hard() routine even though we are not in a hypercall to
determine if there is unfinished business that needs to be
completed in host virtual mode.
The patch assumes that the mapping between hardware interrupt IRQ
and virtual IRQ to be injected to the guest already exists for the
PCI passthrough interrupts that need to be handled in real mode.
If the mapping does not exist, KVM falls back to the default
existing behavior.
The KVM real mode code reads mappings from the mapped array in the
passthrough IRQ map without taking any lock. We carefully order the
loads and stores of the fields in the kvmppc_irq_map data structure
using memory barriers to avoid an inconsistent mapping being seen by
the reader. Thus, although it is possible to miss a map entry, it is
not possible to read a stale value.
[paulus@ozlabs.org - get irq_chip from irq_map rather than pimap,
pulled out powernv eoi change into a separate patch, made
kvmppc_read_intr get the vcpu from the paca rather than being
passed in, rewrote the logic at the end of kvmppc_read_intr to
avoid deep indentation, simplified logic in book3s_hv_rmhandlers.S
since we were always restoring SRR0/1 anyway, get rid of the cached
array (just use the mapped array), removed the kick_all_cpus_sync()
call, clear saved_xirr PACA field when we handle the interrupt in
real mode, fix compilation with CONFIG_KVM_XICS=n.]
Signed-off-by: Suresh Warrier <warrier@linux.vnet.ibm.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2016-08-19 13:35:51 +08:00
|
|
|
int64_t rc;
|
|
|
|
|
2018-10-08 13:31:05 +08:00
|
|
|
if (kvmhv_on_pseries()) {
|
|
|
|
unsigned long retbuf[PLPAR_HCALL_BUFSIZE];
|
|
|
|
|
|
|
|
iosync();
|
|
|
|
plpar_hcall_raw(H_EOI, retbuf, hwirq);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
KVM: PPC: Book3S HV: Handle passthrough interrupts in guest
Currently, KVM switches back to the host to handle any external
interrupt (when the interrupt is received while running in the
guest). This patch updates real-mode KVM to check if an interrupt
is generated by a passthrough adapter that is owned by this guest.
If so, the real mode KVM will directly inject the corresponding
virtual interrupt to the guest VCPU's ICS and also EOI the interrupt
in hardware. In short, the interrupt is handled entirely in real
mode in the guest context without switching back to the host.
In some rare cases, the interrupt cannot be completely handled in
real mode, for instance, a VCPU that is sleeping needs to be woken
up. In this case, KVM simply switches back to the host with trap
reason set to 0x500. This works, but it is clearly not very efficient.
A following patch will distinguish this case and handle it
correctly in the host. Note that we can use the existing
check_too_hard() routine even though we are not in a hypercall to
determine if there is unfinished business that needs to be
completed in host virtual mode.
The patch assumes that the mapping between hardware interrupt IRQ
and virtual IRQ to be injected to the guest already exists for the
PCI passthrough interrupts that need to be handled in real mode.
If the mapping does not exist, KVM falls back to the default
existing behavior.
The KVM real mode code reads mappings from the mapped array in the
passthrough IRQ map without taking any lock. We carefully order the
loads and stores of the fields in the kvmppc_irq_map data structure
using memory barriers to avoid an inconsistent mapping being seen by
the reader. Thus, although it is possible to miss a map entry, it is
not possible to read a stale value.
[paulus@ozlabs.org - get irq_chip from irq_map rather than pimap,
pulled out powernv eoi change into a separate patch, made
kvmppc_read_intr get the vcpu from the paca rather than being
passed in, rewrote the logic at the end of kvmppc_read_intr to
avoid deep indentation, simplified logic in book3s_hv_rmhandlers.S
since we were always restoring SRR0/1 anyway, get rid of the cached
array (just use the mapped array), removed the kick_all_cpus_sync()
call, clear saved_xirr PACA field when we handle the interrupt in
real mode, fix compilation with CONFIG_KVM_XICS=n.]
Signed-off-by: Suresh Warrier <warrier@linux.vnet.ibm.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2016-08-19 13:35:51 +08:00
|
|
|
rc = pnv_opal_pci_msi_eoi(c, hwirq);
|
|
|
|
|
|
|
|
if (rc)
|
|
|
|
eoi_rc = rc;
|
|
|
|
|
|
|
|
iosync();
|
|
|
|
|
|
|
|
/* EOI it */
|
|
|
|
xics_phys = local_paca->kvm_hstate.xics_phys;
|
KVM: PPC: Book3S HV: Use OPAL XICS emulation on POWER9
POWER9 includes a new interrupt controller, called XIVE, which is
quite different from the XICS interrupt controller on POWER7 and
POWER8 machines. KVM-HV accesses the XICS directly in several places
in order to send and clear IPIs and handle interrupts from PCI
devices being passed through to the guest.
In order to make the transition to XIVE easier, OPAL firmware will
include an emulation of XICS on top of XIVE. Access to the emulated
XICS is via OPAL calls. The one complication is that the EOI
(end-of-interrupt) function can now return a value indicating that
another interrupt is pending; in this case, the XIVE will not signal
an interrupt in hardware to the CPU, and software is supposed to
acknowledge the new interrupt without waiting for another interrupt
to be delivered in hardware.
This adapts KVM-HV to use the OPAL calls on machines where there is
no XICS hardware. When there is no XICS, we look for a device-tree
node with "ibm,opal-intc" in its compatible property, which is how
OPAL indicates that it provides XICS emulation.
In order to handle the EOI return value, kvmppc_read_intr() has
become kvmppc_read_one_intr(), with a boolean variable passed by
reference which can be set by the EOI functions to indicate that
another interrupt is pending. The new kvmppc_read_intr() keeps
calling kvmppc_read_one_intr() until there are no more interrupts
to process. The return value from kvmppc_read_intr() is the
largest non-zero value of the returns from kvmppc_read_one_intr().
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2016-11-18 06:02:08 +08:00
|
|
|
if (xics_phys) {
|
2017-04-05 15:54:54 +08:00
|
|
|
__raw_rm_writel(xirr, xics_phys + XICS_XIRR);
|
KVM: PPC: Book3S HV: Use OPAL XICS emulation on POWER9
POWER9 includes a new interrupt controller, called XIVE, which is
quite different from the XICS interrupt controller on POWER7 and
POWER8 machines. KVM-HV accesses the XICS directly in several places
in order to send and clear IPIs and handle interrupts from PCI
devices being passed through to the guest.
In order to make the transition to XIVE easier, OPAL firmware will
include an emulation of XICS on top of XIVE. Access to the emulated
XICS is via OPAL calls. The one complication is that the EOI
(end-of-interrupt) function can now return a value indicating that
another interrupt is pending; in this case, the XIVE will not signal
an interrupt in hardware to the CPU, and software is supposed to
acknowledge the new interrupt without waiting for another interrupt
to be delivered in hardware.
This adapts KVM-HV to use the OPAL calls on machines where there is
no XICS hardware. When there is no XICS, we look for a device-tree
node with "ibm,opal-intc" in its compatible property, which is how
OPAL indicates that it provides XICS emulation.
In order to handle the EOI return value, kvmppc_read_intr() has
become kvmppc_read_one_intr(), with a boolean variable passed by
reference which can be set by the EOI functions to indicate that
another interrupt is pending. The new kvmppc_read_intr() keeps
calling kvmppc_read_one_intr() until there are no more interrupts
to process. The return value from kvmppc_read_intr() is the
largest non-zero value of the returns from kvmppc_read_one_intr().
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2016-11-18 06:02:08 +08:00
|
|
|
} else {
|
2017-02-07 13:03:17 +08:00
|
|
|
rc = opal_int_eoi(be32_to_cpu(xirr));
|
KVM: PPC: Book3S HV: Use OPAL XICS emulation on POWER9
POWER9 includes a new interrupt controller, called XIVE, which is
quite different from the XICS interrupt controller on POWER7 and
POWER8 machines. KVM-HV accesses the XICS directly in several places
in order to send and clear IPIs and handle interrupts from PCI
devices being passed through to the guest.
In order to make the transition to XIVE easier, OPAL firmware will
include an emulation of XICS on top of XIVE. Access to the emulated
XICS is via OPAL calls. The one complication is that the EOI
(end-of-interrupt) function can now return a value indicating that
another interrupt is pending; in this case, the XIVE will not signal
an interrupt in hardware to the CPU, and software is supposed to
acknowledge the new interrupt without waiting for another interrupt
to be delivered in hardware.
This adapts KVM-HV to use the OPAL calls on machines where there is
no XICS hardware. When there is no XICS, we look for a device-tree
node with "ibm,opal-intc" in its compatible property, which is how
OPAL indicates that it provides XICS emulation.
In order to handle the EOI return value, kvmppc_read_intr() has
become kvmppc_read_one_intr(), with a boolean variable passed by
reference which can be set by the EOI functions to indicate that
another interrupt is pending. The new kvmppc_read_intr() keeps
calling kvmppc_read_one_intr() until there are no more interrupts
to process. The return value from kvmppc_read_intr() is the
largest non-zero value of the returns from kvmppc_read_one_intr().
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2016-11-18 06:02:08 +08:00
|
|
|
*again = rc > 0;
|
|
|
|
}
|
KVM: PPC: Book3S HV: Handle passthrough interrupts in guest
Currently, KVM switches back to the host to handle any external
interrupt (when the interrupt is received while running in the
guest). This patch updates real-mode KVM to check if an interrupt
is generated by a passthrough adapter that is owned by this guest.
If so, the real mode KVM will directly inject the corresponding
virtual interrupt to the guest VCPU's ICS and also EOI the interrupt
in hardware. In short, the interrupt is handled entirely in real
mode in the guest context without switching back to the host.
In some rare cases, the interrupt cannot be completely handled in
real mode, for instance, a VCPU that is sleeping needs to be woken
up. In this case, KVM simply switches back to the host with trap
reason set to 0x500. This works, but it is clearly not very efficient.
A following patch will distinguish this case and handle it
correctly in the host. Note that we can use the existing
check_too_hard() routine even though we are not in a hypercall to
determine if there is unfinished business that needs to be
completed in host virtual mode.
The patch assumes that the mapping between hardware interrupt IRQ
and virtual IRQ to be injected to the guest already exists for the
PCI passthrough interrupts that need to be handled in real mode.
If the mapping does not exist, KVM falls back to the default
existing behavior.
The KVM real mode code reads mappings from the mapped array in the
passthrough IRQ map without taking any lock. We carefully order the
loads and stores of the fields in the kvmppc_irq_map data structure
using memory barriers to avoid an inconsistent mapping being seen by
the reader. Thus, although it is possible to miss a map entry, it is
not possible to read a stale value.
[paulus@ozlabs.org - get irq_chip from irq_map rather than pimap,
pulled out powernv eoi change into a separate patch, made
kvmppc_read_intr get the vcpu from the paca rather than being
passed in, rewrote the logic at the end of kvmppc_read_intr to
avoid deep indentation, simplified logic in book3s_hv_rmhandlers.S
since we were always restoring SRR0/1 anyway, get rid of the cached
array (just use the mapped array), removed the kick_all_cpus_sync()
call, clear saved_xirr PACA field when we handle the interrupt in
real mode, fix compilation with CONFIG_KVM_XICS=n.]
Signed-off-by: Suresh Warrier <warrier@linux.vnet.ibm.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2016-08-19 13:35:51 +08:00
|
|
|
}
|
|
|
|
|
2017-02-07 13:03:17 +08:00
|
|
|
static int xics_opal_set_server(unsigned int hw_irq, int server_cpu)
|
KVM: PPC: Book3S HV: Set server for passed-through interrupts
When a guest has a PCI pass-through device with an interrupt, it
will direct the interrupt to a particular guest VCPU. In fact the
physical interrupt might arrive on any CPU, and then get
delivered to the target VCPU in the emulated XICS (guest interrupt
controller), and eventually delivered to the target VCPU.
Now that we have code to handle device interrupts in real mode
without exiting to the host kernel, there is an advantage to having
the device interrupt arrive on the same sub(core) as the target
VCPU is running on. In this situation, the interrupt can be
delivered to the target VCPU without any exit to the host kernel
(using a hypervisor doorbell interrupt between threads if
necessary).
This patch aims to get passed-through device interrupts arriving
on the correct core by setting the interrupt server in the real
hardware XICS for the interrupt to the first thread in the (sub)core
where its target VCPU is running. We do this in the real-mode H_EOI
code because the H_EOI handler already needs to look at the
emulated ICS state for the interrupt (whereas the H_XIRR handler
doesn't), and we know we are running in the target VCPU context
at that point.
We set the server CPU in hardware using an OPAL call, regardless of
what the IRQ affinity mask for the interrupt says, and without
updating the affinity mask. This amounts to saying that when an
interrupt is passed through to a guest, as a matter of policy we
allow the guest's affinity for the interrupt to override the host's.
This is inspired by an earlier patch from Suresh Warrier, although
none of this code came from that earlier patch.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2016-08-19 13:35:56 +08:00
|
|
|
{
|
|
|
|
unsigned int mangle_cpu = get_hard_smp_processor_id(server_cpu) << 2;
|
|
|
|
|
2017-02-07 13:03:17 +08:00
|
|
|
return opal_set_xive(hw_irq, mangle_cpu, DEFAULT_PRIORITY);
|
KVM: PPC: Book3S HV: Set server for passed-through interrupts
When a guest has a PCI pass-through device with an interrupt, it
will direct the interrupt to a particular guest VCPU. In fact the
physical interrupt might arrive on any CPU, and then get
delivered to the target VCPU in the emulated XICS (guest interrupt
controller), and eventually delivered to the target VCPU.
Now that we have code to handle device interrupts in real mode
without exiting to the host kernel, there is an advantage to having
the device interrupt arrive on the same sub(core) as the target
VCPU is running on. In this situation, the interrupt can be
delivered to the target VCPU without any exit to the host kernel
(using a hypervisor doorbell interrupt between threads if
necessary).
This patch aims to get passed-through device interrupts arriving
on the correct core by setting the interrupt server in the real
hardware XICS for the interrupt to the first thread in the (sub)core
where its target VCPU is running. We do this in the real-mode H_EOI
code because the H_EOI handler already needs to look at the
emulated ICS state for the interrupt (whereas the H_XIRR handler
doesn't), and we know we are running in the target VCPU context
at that point.
We set the server CPU in hardware using an OPAL call, regardless of
what the IRQ affinity mask for the interrupt says, and without
updating the affinity mask. This amounts to saying that when an
interrupt is passed through to a guest, as a matter of policy we
allow the guest's affinity for the interrupt to override the host's.
This is inspired by an earlier patch from Suresh Warrier, although
none of this code came from that earlier patch.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2016-08-19 13:35:56 +08:00
|
|
|
}
|
|
|
|
|
2016-08-19 13:35:55 +08:00
|
|
|
/*
|
|
|
|
* Increment a per-CPU 32-bit unsigned integer variable.
|
|
|
|
* Safe to call in real-mode. Handles vmalloc'ed addresses
|
|
|
|
*
|
|
|
|
* ToDo: Make this work for any integral type
|
|
|
|
*/
|
|
|
|
|
|
|
|
static inline void this_cpu_inc_rm(unsigned int __percpu *addr)
|
|
|
|
{
|
|
|
|
unsigned long l;
|
|
|
|
unsigned int *raddr;
|
|
|
|
int cpu = smp_processor_id();
|
|
|
|
|
|
|
|
raddr = per_cpu_ptr(addr, cpu);
|
|
|
|
l = (unsigned long)raddr;
|
|
|
|
|
2019-04-17 20:59:14 +08:00
|
|
|
if (get_region_id(l) == VMALLOC_REGION_ID) {
|
2016-08-19 13:35:55 +08:00
|
|
|
l = vmalloc_to_phys(raddr);
|
|
|
|
raddr = (unsigned int *)l;
|
|
|
|
}
|
|
|
|
++*raddr;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We don't try to update the flags in the irq_desc 'istate' field in
|
|
|
|
* here as would happen in the normal IRQ handling path for several reasons:
|
|
|
|
* - state flags represent internal IRQ state and are not expected to be
|
|
|
|
* updated outside the IRQ subsystem
|
|
|
|
* - more importantly, these are useful for edge triggered interrupts,
|
|
|
|
* IRQ probing, etc., but we are only handling MSI/MSIx interrupts here
|
|
|
|
* and these states shouldn't apply to us.
|
|
|
|
*
|
|
|
|
* However, we do update irq_stats - we somewhat duplicate the code in
|
|
|
|
* kstat_incr_irqs_this_cpu() for this since this function is defined
|
|
|
|
* in irq/internal.h which we don't want to include here.
|
|
|
|
* The only difference is that desc->kstat_irqs is an allocated per CPU
|
|
|
|
* variable and could have been vmalloc'ed, so we can't directly
|
|
|
|
* call __this_cpu_inc() on it. The kstat structure is a static
|
|
|
|
* per CPU variable and it should be accessible by real-mode KVM.
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
static void kvmppc_rm_handle_irq_desc(struct irq_desc *desc)
|
|
|
|
{
|
|
|
|
this_cpu_inc_rm(desc->kstat_irqs);
|
|
|
|
__this_cpu_inc(kstat.irqs_sum);
|
|
|
|
}
|
|
|
|
|
KVM: PPC: Book3S HV: Handle passthrough interrupts in guest
Currently, KVM switches back to the host to handle any external
interrupt (when the interrupt is received while running in the
guest). This patch updates real-mode KVM to check if an interrupt
is generated by a passthrough adapter that is owned by this guest.
If so, the real mode KVM will directly inject the corresponding
virtual interrupt to the guest VCPU's ICS and also EOI the interrupt
in hardware. In short, the interrupt is handled entirely in real
mode in the guest context without switching back to the host.
In some rare cases, the interrupt cannot be completely handled in
real mode, for instance, a VCPU that is sleeping needs to be woken
up. In this case, KVM simply switches back to the host with trap
reason set to 0x500. This works, but it is clearly not very efficient.
A following patch will distinguish this case and handle it
correctly in the host. Note that we can use the existing
check_too_hard() routine even though we are not in a hypercall to
determine if there is unfinished business that needs to be
completed in host virtual mode.
The patch assumes that the mapping between hardware interrupt IRQ
and virtual IRQ to be injected to the guest already exists for the
PCI passthrough interrupts that need to be handled in real mode.
If the mapping does not exist, KVM falls back to the default
existing behavior.
The KVM real mode code reads mappings from the mapped array in the
passthrough IRQ map without taking any lock. We carefully order the
loads and stores of the fields in the kvmppc_irq_map data structure
using memory barriers to avoid an inconsistent mapping being seen by
the reader. Thus, although it is possible to miss a map entry, it is
not possible to read a stale value.
[paulus@ozlabs.org - get irq_chip from irq_map rather than pimap,
pulled out powernv eoi change into a separate patch, made
kvmppc_read_intr get the vcpu from the paca rather than being
passed in, rewrote the logic at the end of kvmppc_read_intr to
avoid deep indentation, simplified logic in book3s_hv_rmhandlers.S
since we were always restoring SRR0/1 anyway, get rid of the cached
array (just use the mapped array), removed the kick_all_cpus_sync()
call, clear saved_xirr PACA field when we handle the interrupt in
real mode, fix compilation with CONFIG_KVM_XICS=n.]
Signed-off-by: Suresh Warrier <warrier@linux.vnet.ibm.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2016-08-19 13:35:51 +08:00
|
|
|
long kvmppc_deliver_irq_passthru(struct kvm_vcpu *vcpu,
|
KVM: PPC: Book3S HV: Use OPAL XICS emulation on POWER9
POWER9 includes a new interrupt controller, called XIVE, which is
quite different from the XICS interrupt controller on POWER7 and
POWER8 machines. KVM-HV accesses the XICS directly in several places
in order to send and clear IPIs and handle interrupts from PCI
devices being passed through to the guest.
In order to make the transition to XIVE easier, OPAL firmware will
include an emulation of XICS on top of XIVE. Access to the emulated
XICS is via OPAL calls. The one complication is that the EOI
(end-of-interrupt) function can now return a value indicating that
another interrupt is pending; in this case, the XIVE will not signal
an interrupt in hardware to the CPU, and software is supposed to
acknowledge the new interrupt without waiting for another interrupt
to be delivered in hardware.
This adapts KVM-HV to use the OPAL calls on machines where there is
no XICS hardware. When there is no XICS, we look for a device-tree
node with "ibm,opal-intc" in its compatible property, which is how
OPAL indicates that it provides XICS emulation.
In order to handle the EOI return value, kvmppc_read_intr() has
become kvmppc_read_one_intr(), with a boolean variable passed by
reference which can be set by the EOI functions to indicate that
another interrupt is pending. The new kvmppc_read_intr() keeps
calling kvmppc_read_one_intr() until there are no more interrupts
to process. The return value from kvmppc_read_intr() is the
largest non-zero value of the returns from kvmppc_read_one_intr().
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2016-11-18 06:02:08 +08:00
|
|
|
__be32 xirr,
|
KVM: PPC: Book3S HV: Handle passthrough interrupts in guest
Currently, KVM switches back to the host to handle any external
interrupt (when the interrupt is received while running in the
guest). This patch updates real-mode KVM to check if an interrupt
is generated by a passthrough adapter that is owned by this guest.
If so, the real mode KVM will directly inject the corresponding
virtual interrupt to the guest VCPU's ICS and also EOI the interrupt
in hardware. In short, the interrupt is handled entirely in real
mode in the guest context without switching back to the host.
In some rare cases, the interrupt cannot be completely handled in
real mode, for instance, a VCPU that is sleeping needs to be woken
up. In this case, KVM simply switches back to the host with trap
reason set to 0x500. This works, but it is clearly not very efficient.
A following patch will distinguish this case and handle it
correctly in the host. Note that we can use the existing
check_too_hard() routine even though we are not in a hypercall to
determine if there is unfinished business that needs to be
completed in host virtual mode.
The patch assumes that the mapping between hardware interrupt IRQ
and virtual IRQ to be injected to the guest already exists for the
PCI passthrough interrupts that need to be handled in real mode.
If the mapping does not exist, KVM falls back to the default
existing behavior.
The KVM real mode code reads mappings from the mapped array in the
passthrough IRQ map without taking any lock. We carefully order the
loads and stores of the fields in the kvmppc_irq_map data structure
using memory barriers to avoid an inconsistent mapping being seen by
the reader. Thus, although it is possible to miss a map entry, it is
not possible to read a stale value.
[paulus@ozlabs.org - get irq_chip from irq_map rather than pimap,
pulled out powernv eoi change into a separate patch, made
kvmppc_read_intr get the vcpu from the paca rather than being
passed in, rewrote the logic at the end of kvmppc_read_intr to
avoid deep indentation, simplified logic in book3s_hv_rmhandlers.S
since we were always restoring SRR0/1 anyway, get rid of the cached
array (just use the mapped array), removed the kick_all_cpus_sync()
call, clear saved_xirr PACA field when we handle the interrupt in
real mode, fix compilation with CONFIG_KVM_XICS=n.]
Signed-off-by: Suresh Warrier <warrier@linux.vnet.ibm.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2016-08-19 13:35:51 +08:00
|
|
|
struct kvmppc_irq_map *irq_map,
|
KVM: PPC: Book3S HV: Use OPAL XICS emulation on POWER9
POWER9 includes a new interrupt controller, called XIVE, which is
quite different from the XICS interrupt controller on POWER7 and
POWER8 machines. KVM-HV accesses the XICS directly in several places
in order to send and clear IPIs and handle interrupts from PCI
devices being passed through to the guest.
In order to make the transition to XIVE easier, OPAL firmware will
include an emulation of XICS on top of XIVE. Access to the emulated
XICS is via OPAL calls. The one complication is that the EOI
(end-of-interrupt) function can now return a value indicating that
another interrupt is pending; in this case, the XIVE will not signal
an interrupt in hardware to the CPU, and software is supposed to
acknowledge the new interrupt without waiting for another interrupt
to be delivered in hardware.
This adapts KVM-HV to use the OPAL calls on machines where there is
no XICS hardware. When there is no XICS, we look for a device-tree
node with "ibm,opal-intc" in its compatible property, which is how
OPAL indicates that it provides XICS emulation.
In order to handle the EOI return value, kvmppc_read_intr() has
become kvmppc_read_one_intr(), with a boolean variable passed by
reference which can be set by the EOI functions to indicate that
another interrupt is pending. The new kvmppc_read_intr() keeps
calling kvmppc_read_one_intr() until there are no more interrupts
to process. The return value from kvmppc_read_intr() is the
largest non-zero value of the returns from kvmppc_read_one_intr().
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2016-11-18 06:02:08 +08:00
|
|
|
struct kvmppc_passthru_irqmap *pimap,
|
|
|
|
bool *again)
|
KVM: PPC: Book3S HV: Handle passthrough interrupts in guest
Currently, KVM switches back to the host to handle any external
interrupt (when the interrupt is received while running in the
guest). This patch updates real-mode KVM to check if an interrupt
is generated by a passthrough adapter that is owned by this guest.
If so, the real mode KVM will directly inject the corresponding
virtual interrupt to the guest VCPU's ICS and also EOI the interrupt
in hardware. In short, the interrupt is handled entirely in real
mode in the guest context without switching back to the host.
In some rare cases, the interrupt cannot be completely handled in
real mode, for instance, a VCPU that is sleeping needs to be woken
up. In this case, KVM simply switches back to the host with trap
reason set to 0x500. This works, but it is clearly not very efficient.
A following patch will distinguish this case and handle it
correctly in the host. Note that we can use the existing
check_too_hard() routine even though we are not in a hypercall to
determine if there is unfinished business that needs to be
completed in host virtual mode.
The patch assumes that the mapping between hardware interrupt IRQ
and virtual IRQ to be injected to the guest already exists for the
PCI passthrough interrupts that need to be handled in real mode.
If the mapping does not exist, KVM falls back to the default
existing behavior.
The KVM real mode code reads mappings from the mapped array in the
passthrough IRQ map without taking any lock. We carefully order the
loads and stores of the fields in the kvmppc_irq_map data structure
using memory barriers to avoid an inconsistent mapping being seen by
the reader. Thus, although it is possible to miss a map entry, it is
not possible to read a stale value.
[paulus@ozlabs.org - get irq_chip from irq_map rather than pimap,
pulled out powernv eoi change into a separate patch, made
kvmppc_read_intr get the vcpu from the paca rather than being
passed in, rewrote the logic at the end of kvmppc_read_intr to
avoid deep indentation, simplified logic in book3s_hv_rmhandlers.S
since we were always restoring SRR0/1 anyway, get rid of the cached
array (just use the mapped array), removed the kick_all_cpus_sync()
call, clear saved_xirr PACA field when we handle the interrupt in
real mode, fix compilation with CONFIG_KVM_XICS=n.]
Signed-off-by: Suresh Warrier <warrier@linux.vnet.ibm.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2016-08-19 13:35:51 +08:00
|
|
|
{
|
|
|
|
struct kvmppc_xics *xics;
|
|
|
|
struct kvmppc_icp *icp;
|
KVM: PPC: Book 3S: XICS: Implement ICS P/Q states
This patch implements P(Presented)/Q(Queued) states for ICS irqs.
When the interrupt is presented, set P. Present if P was not set.
If P is already set, don't present again, set Q.
When the interrupt is EOI'ed, move Q into P (and clear Q). If it is
set, re-present.
The asserted flag used by LSI is also incorporated into the P bit.
When the irq state is saved, P/Q bits are also saved, they need some
qemu modifications to be recognized and passed around to be restored.
KVM_XICS_PENDING bit set and saved should also indicate
KVM_XICS_PRESENTED bit set and saved. But it is possible some old
code doesn't have/recognize the P bit, so when we restore, we set P
for PENDING bit, too.
The idea and much of the code come from Ben.
Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2016-11-11 12:57:35 +08:00
|
|
|
struct kvmppc_ics *ics;
|
|
|
|
struct ics_irq_state *state;
|
KVM: PPC: Book3S HV: Handle passthrough interrupts in guest
Currently, KVM switches back to the host to handle any external
interrupt (when the interrupt is received while running in the
guest). This patch updates real-mode KVM to check if an interrupt
is generated by a passthrough adapter that is owned by this guest.
If so, the real mode KVM will directly inject the corresponding
virtual interrupt to the guest VCPU's ICS and also EOI the interrupt
in hardware. In short, the interrupt is handled entirely in real
mode in the guest context without switching back to the host.
In some rare cases, the interrupt cannot be completely handled in
real mode, for instance, a VCPU that is sleeping needs to be woken
up. In this case, KVM simply switches back to the host with trap
reason set to 0x500. This works, but it is clearly not very efficient.
A following patch will distinguish this case and handle it
correctly in the host. Note that we can use the existing
check_too_hard() routine even though we are not in a hypercall to
determine if there is unfinished business that needs to be
completed in host virtual mode.
The patch assumes that the mapping between hardware interrupt IRQ
and virtual IRQ to be injected to the guest already exists for the
PCI passthrough interrupts that need to be handled in real mode.
If the mapping does not exist, KVM falls back to the default
existing behavior.
The KVM real mode code reads mappings from the mapped array in the
passthrough IRQ map without taking any lock. We carefully order the
loads and stores of the fields in the kvmppc_irq_map data structure
using memory barriers to avoid an inconsistent mapping being seen by
the reader. Thus, although it is possible to miss a map entry, it is
not possible to read a stale value.
[paulus@ozlabs.org - get irq_chip from irq_map rather than pimap,
pulled out powernv eoi change into a separate patch, made
kvmppc_read_intr get the vcpu from the paca rather than being
passed in, rewrote the logic at the end of kvmppc_read_intr to
avoid deep indentation, simplified logic in book3s_hv_rmhandlers.S
since we were always restoring SRR0/1 anyway, get rid of the cached
array (just use the mapped array), removed the kick_all_cpus_sync()
call, clear saved_xirr PACA field when we handle the interrupt in
real mode, fix compilation with CONFIG_KVM_XICS=n.]
Signed-off-by: Suresh Warrier <warrier@linux.vnet.ibm.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2016-08-19 13:35:51 +08:00
|
|
|
u32 irq;
|
KVM: PPC: Book 3S: XICS: Implement ICS P/Q states
This patch implements P(Presented)/Q(Queued) states for ICS irqs.
When the interrupt is presented, set P. Present if P was not set.
If P is already set, don't present again, set Q.
When the interrupt is EOI'ed, move Q into P (and clear Q). If it is
set, re-present.
The asserted flag used by LSI is also incorporated into the P bit.
When the irq state is saved, P/Q bits are also saved, they need some
qemu modifications to be recognized and passed around to be restored.
KVM_XICS_PENDING bit set and saved should also indicate
KVM_XICS_PRESENTED bit set and saved. But it is possible some old
code doesn't have/recognize the P bit, so when we restore, we set P
for PENDING bit, too.
The idea and much of the code come from Ben.
Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2016-11-11 12:57:35 +08:00
|
|
|
u16 src;
|
|
|
|
u32 pq_old, pq_new;
|
KVM: PPC: Book3S HV: Handle passthrough interrupts in guest
Currently, KVM switches back to the host to handle any external
interrupt (when the interrupt is received while running in the
guest). This patch updates real-mode KVM to check if an interrupt
is generated by a passthrough adapter that is owned by this guest.
If so, the real mode KVM will directly inject the corresponding
virtual interrupt to the guest VCPU's ICS and also EOI the interrupt
in hardware. In short, the interrupt is handled entirely in real
mode in the guest context without switching back to the host.
In some rare cases, the interrupt cannot be completely handled in
real mode, for instance, a VCPU that is sleeping needs to be woken
up. In this case, KVM simply switches back to the host with trap
reason set to 0x500. This works, but it is clearly not very efficient.
A following patch will distinguish this case and handle it
correctly in the host. Note that we can use the existing
check_too_hard() routine even though we are not in a hypercall to
determine if there is unfinished business that needs to be
completed in host virtual mode.
The patch assumes that the mapping between hardware interrupt IRQ
and virtual IRQ to be injected to the guest already exists for the
PCI passthrough interrupts that need to be handled in real mode.
If the mapping does not exist, KVM falls back to the default
existing behavior.
The KVM real mode code reads mappings from the mapped array in the
passthrough IRQ map without taking any lock. We carefully order the
loads and stores of the fields in the kvmppc_irq_map data structure
using memory barriers to avoid an inconsistent mapping being seen by
the reader. Thus, although it is possible to miss a map entry, it is
not possible to read a stale value.
[paulus@ozlabs.org - get irq_chip from irq_map rather than pimap,
pulled out powernv eoi change into a separate patch, made
kvmppc_read_intr get the vcpu from the paca rather than being
passed in, rewrote the logic at the end of kvmppc_read_intr to
avoid deep indentation, simplified logic in book3s_hv_rmhandlers.S
since we were always restoring SRR0/1 anyway, get rid of the cached
array (just use the mapped array), removed the kick_all_cpus_sync()
call, clear saved_xirr PACA field when we handle the interrupt in
real mode, fix compilation with CONFIG_KVM_XICS=n.]
Signed-off-by: Suresh Warrier <warrier@linux.vnet.ibm.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2016-08-19 13:35:51 +08:00
|
|
|
|
|
|
|
irq = irq_map->v_hwirq;
|
|
|
|
xics = vcpu->kvm->arch.xics;
|
|
|
|
icp = vcpu->arch.icp;
|
|
|
|
|
2016-08-19 13:35:55 +08:00
|
|
|
kvmppc_rm_handle_irq_desc(irq_map->desc);
|
KVM: PPC: Book 3S: XICS: Implement ICS P/Q states
This patch implements P(Presented)/Q(Queued) states for ICS irqs.
When the interrupt is presented, set P. Present if P was not set.
If P is already set, don't present again, set Q.
When the interrupt is EOI'ed, move Q into P (and clear Q). If it is
set, re-present.
The asserted flag used by LSI is also incorporated into the P bit.
When the irq state is saved, P/Q bits are also saved, they need some
qemu modifications to be recognized and passed around to be restored.
KVM_XICS_PENDING bit set and saved should also indicate
KVM_XICS_PRESENTED bit set and saved. But it is possible some old
code doesn't have/recognize the P bit, so when we restore, we set P
for PENDING bit, too.
The idea and much of the code come from Ben.
Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2016-11-11 12:57:35 +08:00
|
|
|
|
|
|
|
ics = kvmppc_xics_find_ics(xics, irq, &src);
|
|
|
|
if (!ics)
|
|
|
|
return 2;
|
|
|
|
|
|
|
|
state = &ics->irq_state[src];
|
|
|
|
|
|
|
|
/* only MSIs register bypass producers, so it must be MSI here */
|
|
|
|
do {
|
|
|
|
pq_old = state->pq_state;
|
|
|
|
pq_new = ((pq_old << 1) & 3) | PQ_PRESENTED;
|
|
|
|
} while (cmpxchg(&state->pq_state, pq_old, pq_new) != pq_old);
|
|
|
|
|
|
|
|
/* Test P=1, Q=0, this is the only case where we present */
|
|
|
|
if (pq_new == PQ_PRESENTED)
|
2016-11-11 12:57:36 +08:00
|
|
|
icp_rm_deliver_irq(xics, icp, irq, false);
|
KVM: PPC: Book3S HV: Handle passthrough interrupts in guest
Currently, KVM switches back to the host to handle any external
interrupt (when the interrupt is received while running in the
guest). This patch updates real-mode KVM to check if an interrupt
is generated by a passthrough adapter that is owned by this guest.
If so, the real mode KVM will directly inject the corresponding
virtual interrupt to the guest VCPU's ICS and also EOI the interrupt
in hardware. In short, the interrupt is handled entirely in real
mode in the guest context without switching back to the host.
In some rare cases, the interrupt cannot be completely handled in
real mode, for instance, a VCPU that is sleeping needs to be woken
up. In this case, KVM simply switches back to the host with trap
reason set to 0x500. This works, but it is clearly not very efficient.
A following patch will distinguish this case and handle it
correctly in the host. Note that we can use the existing
check_too_hard() routine even though we are not in a hypercall to
determine if there is unfinished business that needs to be
completed in host virtual mode.
The patch assumes that the mapping between hardware interrupt IRQ
and virtual IRQ to be injected to the guest already exists for the
PCI passthrough interrupts that need to be handled in real mode.
If the mapping does not exist, KVM falls back to the default
existing behavior.
The KVM real mode code reads mappings from the mapped array in the
passthrough IRQ map without taking any lock. We carefully order the
loads and stores of the fields in the kvmppc_irq_map data structure
using memory barriers to avoid an inconsistent mapping being seen by
the reader. Thus, although it is possible to miss a map entry, it is
not possible to read a stale value.
[paulus@ozlabs.org - get irq_chip from irq_map rather than pimap,
pulled out powernv eoi change into a separate patch, made
kvmppc_read_intr get the vcpu from the paca rather than being
passed in, rewrote the logic at the end of kvmppc_read_intr to
avoid deep indentation, simplified logic in book3s_hv_rmhandlers.S
since we were always restoring SRR0/1 anyway, get rid of the cached
array (just use the mapped array), removed the kick_all_cpus_sync()
call, clear saved_xirr PACA field when we handle the interrupt in
real mode, fix compilation with CONFIG_KVM_XICS=n.]
Signed-off-by: Suresh Warrier <warrier@linux.vnet.ibm.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2016-08-19 13:35:51 +08:00
|
|
|
|
|
|
|
/* EOI the interrupt */
|
KVM: PPC: Book3S HV: Use OPAL XICS emulation on POWER9
POWER9 includes a new interrupt controller, called XIVE, which is
quite different from the XICS interrupt controller on POWER7 and
POWER8 machines. KVM-HV accesses the XICS directly in several places
in order to send and clear IPIs and handle interrupts from PCI
devices being passed through to the guest.
In order to make the transition to XIVE easier, OPAL firmware will
include an emulation of XICS on top of XIVE. Access to the emulated
XICS is via OPAL calls. The one complication is that the EOI
(end-of-interrupt) function can now return a value indicating that
another interrupt is pending; in this case, the XIVE will not signal
an interrupt in hardware to the CPU, and software is supposed to
acknowledge the new interrupt without waiting for another interrupt
to be delivered in hardware.
This adapts KVM-HV to use the OPAL calls on machines where there is
no XICS hardware. When there is no XICS, we look for a device-tree
node with "ibm,opal-intc" in its compatible property, which is how
OPAL indicates that it provides XICS emulation.
In order to handle the EOI return value, kvmppc_read_intr() has
become kvmppc_read_one_intr(), with a boolean variable passed by
reference which can be set by the EOI functions to indicate that
another interrupt is pending. The new kvmppc_read_intr() keeps
calling kvmppc_read_one_intr() until there are no more interrupts
to process. The return value from kvmppc_read_intr() is the
largest non-zero value of the returns from kvmppc_read_one_intr().
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2016-11-18 06:02:08 +08:00
|
|
|
icp_eoi(irq_desc_get_chip(irq_map->desc), irq_map->r_hwirq, xirr,
|
|
|
|
again);
|
KVM: PPC: Book3S HV: Handle passthrough interrupts in guest
Currently, KVM switches back to the host to handle any external
interrupt (when the interrupt is received while running in the
guest). This patch updates real-mode KVM to check if an interrupt
is generated by a passthrough adapter that is owned by this guest.
If so, the real mode KVM will directly inject the corresponding
virtual interrupt to the guest VCPU's ICS and also EOI the interrupt
in hardware. In short, the interrupt is handled entirely in real
mode in the guest context without switching back to the host.
In some rare cases, the interrupt cannot be completely handled in
real mode, for instance, a VCPU that is sleeping needs to be woken
up. In this case, KVM simply switches back to the host with trap
reason set to 0x500. This works, but it is clearly not very efficient.
A following patch will distinguish this case and handle it
correctly in the host. Note that we can use the existing
check_too_hard() routine even though we are not in a hypercall to
determine if there is unfinished business that needs to be
completed in host virtual mode.
The patch assumes that the mapping between hardware interrupt IRQ
and virtual IRQ to be injected to the guest already exists for the
PCI passthrough interrupts that need to be handled in real mode.
If the mapping does not exist, KVM falls back to the default
existing behavior.
The KVM real mode code reads mappings from the mapped array in the
passthrough IRQ map without taking any lock. We carefully order the
loads and stores of the fields in the kvmppc_irq_map data structure
using memory barriers to avoid an inconsistent mapping being seen by
the reader. Thus, although it is possible to miss a map entry, it is
not possible to read a stale value.
[paulus@ozlabs.org - get irq_chip from irq_map rather than pimap,
pulled out powernv eoi change into a separate patch, made
kvmppc_read_intr get the vcpu from the paca rather than being
passed in, rewrote the logic at the end of kvmppc_read_intr to
avoid deep indentation, simplified logic in book3s_hv_rmhandlers.S
since we were always restoring SRR0/1 anyway, get rid of the cached
array (just use the mapped array), removed the kick_all_cpus_sync()
call, clear saved_xirr PACA field when we handle the interrupt in
real mode, fix compilation with CONFIG_KVM_XICS=n.]
Signed-off-by: Suresh Warrier <warrier@linux.vnet.ibm.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2016-08-19 13:35:51 +08:00
|
|
|
|
|
|
|
if (check_too_hard(xics, icp) == H_TOO_HARD)
|
2016-08-19 13:35:52 +08:00
|
|
|
return 2;
|
KVM: PPC: Book3S HV: Handle passthrough interrupts in guest
Currently, KVM switches back to the host to handle any external
interrupt (when the interrupt is received while running in the
guest). This patch updates real-mode KVM to check if an interrupt
is generated by a passthrough adapter that is owned by this guest.
If so, the real mode KVM will directly inject the corresponding
virtual interrupt to the guest VCPU's ICS and also EOI the interrupt
in hardware. In short, the interrupt is handled entirely in real
mode in the guest context without switching back to the host.
In some rare cases, the interrupt cannot be completely handled in
real mode, for instance, a VCPU that is sleeping needs to be woken
up. In this case, KVM simply switches back to the host with trap
reason set to 0x500. This works, but it is clearly not very efficient.
A following patch will distinguish this case and handle it
correctly in the host. Note that we can use the existing
check_too_hard() routine even though we are not in a hypercall to
determine if there is unfinished business that needs to be
completed in host virtual mode.
The patch assumes that the mapping between hardware interrupt IRQ
and virtual IRQ to be injected to the guest already exists for the
PCI passthrough interrupts that need to be handled in real mode.
If the mapping does not exist, KVM falls back to the default
existing behavior.
The KVM real mode code reads mappings from the mapped array in the
passthrough IRQ map without taking any lock. We carefully order the
loads and stores of the fields in the kvmppc_irq_map data structure
using memory barriers to avoid an inconsistent mapping being seen by
the reader. Thus, although it is possible to miss a map entry, it is
not possible to read a stale value.
[paulus@ozlabs.org - get irq_chip from irq_map rather than pimap,
pulled out powernv eoi change into a separate patch, made
kvmppc_read_intr get the vcpu from the paca rather than being
passed in, rewrote the logic at the end of kvmppc_read_intr to
avoid deep indentation, simplified logic in book3s_hv_rmhandlers.S
since we were always restoring SRR0/1 anyway, get rid of the cached
array (just use the mapped array), removed the kick_all_cpus_sync()
call, clear saved_xirr PACA field when we handle the interrupt in
real mode, fix compilation with CONFIG_KVM_XICS=n.]
Signed-off-by: Suresh Warrier <warrier@linux.vnet.ibm.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2016-08-19 13:35:51 +08:00
|
|
|
else
|
|
|
|
return -2;
|
|
|
|
}
|
|
|
|
|
2015-12-18 04:59:09 +08:00
|
|
|
/* --- Non-real mode XICS-related built-in routines --- */
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Host Operations poked by RM KVM
|
|
|
|
*/
|
|
|
|
static void rm_host_ipi_action(int action, void *data)
|
|
|
|
{
|
|
|
|
switch (action) {
|
|
|
|
case XICS_RM_KICK_VCPU:
|
|
|
|
kvmppc_host_rm_ops_hv->vcpu_kick(data);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
WARN(1, "Unexpected rm_action=%d data=%p\n", action, data);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
void kvmppc_xics_ipi_action(void)
|
|
|
|
{
|
|
|
|
int core;
|
|
|
|
unsigned int cpu = smp_processor_id();
|
|
|
|
struct kvmppc_host_rm_core *rm_corep;
|
|
|
|
|
|
|
|
core = cpu >> threads_shift;
|
|
|
|
rm_corep = &kvmppc_host_rm_ops_hv->rm_core[core];
|
|
|
|
|
|
|
|
if (rm_corep->rm_data) {
|
|
|
|
rm_host_ipi_action(rm_corep->rm_state.rm_action,
|
|
|
|
rm_corep->rm_data);
|
2015-12-22 06:22:51 +08:00
|
|
|
/* Order these stores against the real mode KVM */
|
2015-12-18 04:59:09 +08:00
|
|
|
rm_corep->rm_data = NULL;
|
2015-12-22 06:22:51 +08:00
|
|
|
smp_wmb();
|
2015-12-18 04:59:09 +08:00
|
|
|
rm_corep->rm_state.rm_action = 0;
|
|
|
|
}
|
|
|
|
}
|