2013-04-18 04:31:15 +08:00
|
|
|
/*
|
|
|
|
* Copyright 2012 Michael Ellerman, IBM Corporation.
|
|
|
|
* Copyright 2012 Benjamin Herrenschmidt, IBM Corporation
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
* it under the terms of the GNU General Public License, version 2, as
|
|
|
|
* published by the Free Software Foundation.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#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>
|
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>
|
2016-08-19 13:35:55 +08:00
|
|
|
#include <asm/pgtable.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);
|
2017-01-30 18:21:51 +08:00
|
|
|
kvmppc_set_host_ipi(hcpu, 1);
|
|
|
|
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);
|
|
|
|
}
|
|
|
|
|
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
|
|
|
unsigned long eoi_rc;
|
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
}
|