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

[David Gibson]

On Tue, Jun 27, 2017 at 10:22:09AM +1000, Sam Bobroff wrote:
> 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?

JSYK, I don't think it's plausible this will get in for qemu-2.10 at
this point.  I'm still fine to review and (once it's ready) queue
updated versions for 2.11.

-- 
David Gibson                    | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
                                | _way_ _around_!
http://www.ozlabs.org/~dgibson

signature.asc
Description: PGP signature