qemu-ppc
[Top][All Lists]
Advanced

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

[Qemu-ppc] [PATCH RFC 0/4] Exploit settable KVM_CAP_PPC_SMT


From: Sam Bobroff
Subject: [Qemu-ppc] [PATCH RFC 0/4] Exploit settable KVM_CAP_PPC_SMT
Date: Tue, 27 Jun 2017 10:22:09 +1000
User-agent: NeoMutt/20170113 (1.7.2)

Hello QEMU PPC people,

KVM on PPC will soon allow writing to the, currently read-only, KVM capability
'KVM_CAP_PPC_SMT'. See the KVM patches for details [1].

This is useful to QEMU because:
* It is required to run any VMs with more than one thread/core on a Power9
  host.
* On Power7 and Power8 hosts (or hosts in those compatibility modes), when
  running VMs with less than the host's threads/core, VCPUIDs can be made
  consecutive.
* VMs can be migrated between hosts with different threads/core (as long as
  both hosts can support that VSMT mode), or to or from legacy hosts that do
  not have this feature.

Issues/Questions:
* I have a lot of issues/questions so this is an RFC patch set.
* Adding the vsmt property to the machine option was the easiest way to
  implement it, but it feels like it would make more sense to users if it were
  a CPU option. Does anyone have a better idea of where it should go? Is a CPU
  property worth persuing?
* The HMP/QMP patch will require a kernel header update, which I have not
  included here yet since this is an RFC series. Instead I've just left a
  testing value in so that it will compile (it matches the one used in the
  patches posted to kvm-ppc).
* I added "info vsmt" and the QMP version to assist libvirt in supporting this
  feature. Is that the right way to do that?
* "info vsmt": Rather than adding a new info command, would it be better to
  optionally include the same fields in "info kvm"?
* "info vsmt": I realize the way I've added these doesn't restrict them to PPC
  but there didn't seem to be an easy way of adding them only for one arch. Is
  there a better way to handle this?
* I didn't include the VSMT value as part of the migration state because AFAIK,
  QEMU doesn't migrate things that are specified on the command line. However,
  it would be possible to catch a mismatch and fail gracefully rather than
  letting the guest crash (probably on a failed IPI). Should it be in the
  migration state?
* I suspect some of my error report text could be better. Suggestions?
* It seems like there might be generic functions I could use for
  spapr_get_vsmt() and spapr_set_vsmt() (the ones I wrote are already generic),
  but I can't find any. Am I missing something? Should I add some?

Notes:
[1]: See:
    http://marc.info/?l=kvm-ppc&m=149562161912013&w=2
    http://marc.info/?l=kvm-ppc&m=149802545610234&w=2


Sam Bobroff (4):
  PPC: TCG: Correct SEGV when smp_threads > 1
  PPC: KVM: Move kvm_cap_smt into sPAPRMachineState
  PPC: KVM: Support machine option to set VSMT mode
  PPC: KVM: Expose possible VSMT modes via QMP and HMP

 accel/kvm/kvm-all.c         |  2 +
 hmp-commands-info.hx        | 14 +++++++
 hmp.c                       | 16 ++++++++
 hmp.h                       |  1 +
 hw/ppc/spapr.c              | 97 ++++++++++++++++++++++++++++++++++++++++++---
 hw/ppc/spapr_cpu_core.c     |  5 ++-
 include/hw/ppc/spapr.h      |  1 +
 include/sysemu/kvm.h        |  1 +
 linux-headers/linux/kvm.h   |  1 +
 qapi-schema.json            | 28 +++++++++++++
 qmp.c                       | 20 ++++++++++
 target/ppc/kvm.c            | 11 +++--
 target/ppc/kvm_ppc.h        |  8 +---
 target/ppc/translate_init.c | 23 +++--------
 14 files changed, 193 insertions(+), 35 deletions(-)

-- 
2.12.1.382.gc0f9c7058




reply via email to

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