qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] RFC: spapr: introduce smt_cpu_index


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH] RFC: spapr: introduce smt_cpu_index
Date: Thu, 31 Oct 2013 13:50:05 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130923 Thunderbird/17.0.9

Il 31/10/2013 10:28, Alexey Kardashevskiy ha scritto:
> This is not really a patch to accept or review, this is a conversation
> starter.
> 
> Cc: Badari Pulavarty  <address@hidden>
> Cc: Paul Mackerras <address@hidden>
> Cc: David Gibson <address@hidden>
> Cc: Benjamin Herrenschmidt <address@hidden>
> Cc: Andreas Färber <address@hidden>
> Signed-off-by: Alexey Kardashevskiy <address@hidden>
> 
> ---
> 
> Normall CPUState::cpu_index is used to pick the right CPU for various
> operations. However default consecutive numbering does not always work
> for PPC64.
> 
> For example, on POWER7 (which supports 4 threads per core),
> "-smp 8,threads=4" should create CPUs with indexes 0,1,2,3,4,5,6,7 and
> "-smp 8,threads=1" should create CPUs with indexes 0,4,8,12,16,20,24,28.
> 
> These indexes are reflected in /proc/device-tree/cpus/PowerPC,address@hidden
> and used to call KVM VCPU's ioctl.

I think these two uses should be separated, even if they use the same
formula.  Define a PPC-specific concept, used by TCG as well, and make
kvm_arch_vcpu_id use it.

In other words:

- the hw/ppc/spapr* changes should not use kvm_arch_vcpu_id and
kvm_arch_get_vcpu_by_id, but something like ppc_get_vcpu_dt_id and
ppc_get_vcpu_by_dt_id.

- the comment for the new field should be something like /* The CPU
index used in the device tree.  KVM uses this index too.  */

- kvm_arch_vcpu_id can be a simple wrapper for ppc_get_vcpu_dt_id; no
need for the new kvm_arch_get_vcpu_by_id, and no kvm-stub.c changes
should be necessary either.

- everything else seems fine.

> 2. Apply the patch below and make sure it does not break x86/ARM/s390
> with and without KVM (does not it?);

If you do it right (i.e. do not touch kvm-stub.c) it should "obviously"
not break anything outside PPC.

Paolo




reply via email to

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