[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