qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] [PATCH 0/5] spapr: fix VCPU ids miscalculation


From: Greg Kurz
Subject: [Qemu-devel] [PATCH 0/5] spapr: fix VCPU ids miscalculation
Date: Wed, 14 Feb 2018 20:40:08 +0100
User-agent: StGit/0.17.1-46-g6855-dirty

After the review of Laurent's patch "spapr: set vsmt to MAX(8, smp_threads)",
I realized that most of the machine code that deals with VCPU ids assume the
spacing between cores is kvmppc_smt_threads() instead of spapr->vsmt. Most
of the time this is ok because both are equals, and QEMU used to exit if
it failed to set the VSMT mode into KVM.

This changed with the recent commit 8904e5a75005 "spapr: Adjust default
VSMT value for better migration compatibility", and really hurts setups
where kvmppc_smt_threads() and spapr->vsmt can have a different value:
older KVMs or even a recent KVM on a POWER8 host with subcores. The most
notable effects are DRCs associated to wrong VCPUs, which makes CPU
hot-plug completely unusable.

The fix is as simple as using spapr->vsmt everywhere. This is patch 1.
The rest of the series is an effort to consolidate the numbering logic
in a single place. This will avoid future breakage if the VCPU id logic
needs to be changed again later. Changes in patches 2 to 4 are rather
mechanical. Patch 5 is a bit more controversial as it breaks the
migration of unusual CPU topologies that used to be supported by
pre-2.7 machine types.

Please comment.

--
Greg

---

Greg Kurz (5):
      spapr: use spapr->vsmt to compute VCPU ids
      spapr: move VCPU calculation to core machine code
      spapr: rename spapr_vcpu_id() to spapr_get_vcpu_id()
      spapr: consolidate the VCPU id numbering logic in a single place
      spapr: drop DIV_ROUND_UP() from xics_max_server_number()


 hw/ppc/spapr.c          |   74 +++++++++++++++++++++++++++++++++--------------
 hw/ppc/spapr_cpu_core.c |    9 +-----
 include/hw/ppc/spapr.h  |    3 +-
 3 files changed, 56 insertions(+), 30 deletions(-)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]