All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: peter.maydell@linaro.org
Cc: danielhb413@gmail.com, qemu-devel@nongnu.org, groug@kaod.org,
	qemu-ppc@nongnu.org, "Cédric Le Goater" <clg@kaod.org>,
	bauerman@linux.ibm.com,
	"David Gibson" <david@gibson.dropbear.id.au>
Subject: [PULL 11/30] spapr/xive: Allocate vCPU IPIs from the vCPU contexts
Date: Fri,  4 Sep 2020 13:47:00 +1000	[thread overview]
Message-ID: <20200904034719.673626-12-david@gibson.dropbear.id.au> (raw)
In-Reply-To: <20200904034719.673626-1-david@gibson.dropbear.id.au>

From: Cédric Le Goater <clg@kaod.org>

When QEMU switches to the XIVE interrupt mode, it creates all the
guest interrupts at the level of the KVM device. These interrupts are
backed by real HW interrupts from the IPI interrupt pool of the XIVE
controller.

Currently, this is done from the QEMU main thread, which results in
allocating all interrupts from the chip on which QEMU is running. IPIs
are not distributed across the system and the load is not well
balanced across the interrupt controllers.

Change the vCPU IPI allocation to run from the vCPU context. The
associated XIVE IPI interrupt will be allocated on the chip on which
the vCPU is running and improve distribution of the IPIs in the system.
When the vCPUs are pinned, this will make the IPI local to the chip of
the vCPU. It will reduce rerouting between interrupt controllers and
gives better performance.

Device interrupts are still treated the same. To improve placement, we
would need some information on the chip owning the virtual source or
the HW source in case of a passthrough device but this reuires
changes in PAPR.

Signed-off-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20200820134547.2355743-5-clg@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
 hw/intc/spapr_xive_kvm.c | 36 +++++++++++++++++++++++++++++++++---
 1 file changed, 33 insertions(+), 3 deletions(-)

diff --git a/hw/intc/spapr_xive_kvm.c b/hw/intc/spapr_xive_kvm.c
index 507637d51e..66bf4c06fe 100644
--- a/hw/intc/spapr_xive_kvm.c
+++ b/hw/intc/spapr_xive_kvm.c
@@ -146,13 +146,43 @@ int kvmppc_xive_cpu_synchronize_state(XiveTCTX *tctx, Error **errp)
     return s.ret;
 }
 
-static int kvmppc_xive_reset_ipi(SpaprXive *xive, CPUState *cs, Error **errp)
+/*
+ * Allocate the vCPU IPIs from the vCPU context. This will allocate
+ * the XIVE IPI interrupt on the chip on which the vCPU is running.
+ * This gives a better distribution of IPIs when the guest has a lot
+ * of vCPUs. When the vCPUs are pinned, this will make the IPI local
+ * to the chip of the vCPU. It will reduce rerouting between interrupt
+ * controllers and gives better performance.
+ */
+typedef struct {
+    SpaprXive *xive;
+    Error *err;
+    int rc;
+} XiveInitIPI;
+
+static void kvmppc_xive_reset_ipi_on_cpu(CPUState *cs, run_on_cpu_data arg)
 {
     unsigned long ipi = kvm_arch_vcpu_id(cs);
+    XiveInitIPI *s = arg.host_ptr;
     uint64_t state = 0;
 
-    return kvm_device_access(xive->fd, KVM_DEV_XIVE_GRP_SOURCE, ipi,
-                              &state, true, errp);
+    s->rc = kvm_device_access(s->xive->fd, KVM_DEV_XIVE_GRP_SOURCE, ipi,
+                              &state, true, &s->err);
+}
+
+static int kvmppc_xive_reset_ipi(SpaprXive *xive, CPUState *cs, Error **errp)
+{
+    XiveInitIPI s = {
+        .xive = xive,
+        .err  = NULL,
+        .rc   = 0,
+    };
+
+    run_on_cpu(cs, kvmppc_xive_reset_ipi_on_cpu, RUN_ON_CPU_HOST_PTR(&s));
+    if (s.err) {
+        error_propagate(errp, s.err);
+    }
+    return s.rc;
 }
 
 int kvmppc_xive_cpu_connect(XiveTCTX *tctx, Error **errp)
-- 
2.26.2



  parent reply	other threads:[~2020-09-04  3:51 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-04  3:46 [PULL 00/30] ppc-for-5.2 queue 20200904 David Gibson
2020-09-04  3:46 ` [PULL 01/30] adb: Correct class size on TYPE_ADB_DEVICE David Gibson
2020-09-04  3:46 ` [PULL 02/30] ppc/pnv: Fix TypeInfo of PnvLpcController abstract class David Gibson
2020-09-04  3:46 ` [PULL 03/30] spapr: Remove unnecessary DRC type-checker macros David Gibson
2020-09-04  3:46 ` [PULL 04/30] spapr/xive: Add a 'hv-prio' property to represent the KVM escalation priority David Gibson
2020-09-04  3:46 ` [PULL 05/30] ppc/pnv: Add a HIOMAP erase command David Gibson
2020-09-04  3:46 ` [PULL 06/30] spapr_vscsi: do not allow device hotplug David Gibson
2020-09-04  3:46 ` [PULL 07/30] spapr/xive: Use the xics flag to check for XIVE-only IRQ backends David Gibson
2020-09-04  3:46 ` [PULL 08/30] spapr/xive: Modify kvm_cpu_is_enabled() interface David Gibson
2020-09-04  3:46 ` [PULL 09/30] spapr/xive: Use kvmppc_xive_source_reset() in post_load David Gibson
2020-09-04  3:46 ` [PULL 10/30] spapr/xive: Allocate IPIs independently from the other sources David Gibson
2020-09-04  3:47 ` David Gibson [this message]
2020-09-04  3:47 ` [PULL 12/30] ppc/spapr_nvdimm: use g_autofree in spapr_nvdimm_validate_opts() David Gibson
2020-09-04  3:47 ` [PULL 13/30] spapr, spapr_nvdimm: fold NVDIMM validation in the same place David Gibson
2020-09-04  3:47 ` [PULL 14/30] ppc/spapr_nvdimm: do not enable support with 'nvdimm=off' David Gibson
2020-09-04  3:47 ` [PULL 15/30] target/arm: Move start-powered-off property to generic CPUState David Gibson
2020-09-04  3:47 ` [PULL 16/30] target/arm: Move setting of CPU halted state to generic code David Gibson
2020-09-04  3:47 ` [PULL 17/30] ppc/spapr: Use start-powered-off CPUState property David Gibson
2020-09-04  3:47 ` [PULL 18/30] ppc/e500: " David Gibson
2020-09-04  3:47 ` [PULL 19/30] mips/cps: " David Gibson
2020-09-04  3:47 ` [PULL 20/30] sparc/sun4m: Don't set cs->halted = 0 in main_cpu_reset() David Gibson
2020-09-04  3:47 ` [PULL 21/30] sparc/sun4m: Use start-powered-off CPUState property David Gibson
2020-09-04  3:47 ` [PULL 22/30] target/s390x: " David Gibson
2020-09-04  3:47 ` [PULL 23/30] hw/ppc/ppc4xx_pci: Use ARRAY_SIZE() instead of magic value David Gibson
2020-09-04  3:47 ` [PULL 24/30] hw/ppc/ppc4xx_pci: Replace pointless warning by assert() David Gibson
2020-09-04  3:47 ` [PULL 25/30] ppc: introducing spapr_numa.c NUMA code helper David Gibson
2020-09-04  3:47 ` [PULL 26/30] ppc/spapr_nvdimm: turn spapr_dt_nvdimm() static David Gibson
2020-09-04  3:47 ` [PULL 27/30] spapr: introduce SpaprMachineState::numa_assoc_array David Gibson
2020-09-04  3:47 ` [PULL 28/30] spapr, spapr_numa: handle vcpu ibm,associativity David Gibson
2020-09-04  3:47 ` [PULL 29/30] spapr, spapr_numa: move lookup-arrays handling to spapr_numa.c David Gibson
2020-09-04  3:47 ` [PULL 30/30] spapr_numa: move NVLink2 associativity " David Gibson
2020-09-06 15:20 ` [PULL 00/30] ppc-for-5.2 queue 20200904 Peter Maydell
2020-09-07  2:38   ` David Gibson
2020-09-07 13:29     ` Laurent Vivier
2020-09-07 14:05       ` Philippe Mathieu-Daudé
2020-09-07 14:31         ` Laurent Vivier
2020-09-07 14:51           ` Cornelia Huck
2020-09-07 16:29             ` Laurent Vivier
2020-09-07 17:26               ` Laurent Vivier
2020-09-07 19:46                 ` Philippe Mathieu-Daudé
2020-09-07 23:50                   ` David Gibson
2020-09-08  6:11                   ` Cornelia Huck
2020-09-08 15:12                     ` Thiago Jung Bauermann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200904034719.673626-12-david@gibson.dropbear.id.au \
    --to=david@gibson.dropbear.id.au \
    --cc=bauerman@linux.ibm.com \
    --cc=clg@kaod.org \
    --cc=danielhb413@gmail.com \
    --cc=groug@kaod.org \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.