Re: [libvirt] [PATCH 1/1] Fix cpu check for ppc64
On Thu, May 17, 2012 at 09:36:22AM +0100, Daniel P. Berrange wrote:
On Thu, May 17, 2012 at 04:28:52PM +0800, Li Zhang wrote:
> ppc64 pseries architecture requires that the cpus
> be numbered in a certain way.
> According to SMT, if SMT equals 4, 0-3 on core 0,
> 4-7 on core 1 and so on. So, depending on how guest
> topology has been specified, one cannot assume that
> the vcpus will be numbered 0-N. For example, for
> smp=2, core=2, threads=1, the two cpus will be 0 and
> 4 - one HW thread on each core. libvirt needs to take
> into account.
What you describe here is a hardware view of the CPUs,
which need not be contiguous. libvirt works with a
purely linear view of CPU numbers, where everything is
contiguous & I always assumed that QEMU's query-cpus
command works the same way.
To explain this in a little more detail: POWER7 can run 1, 2 or 4
threads per core, but has a constraint in hardware that all the
threads in a core have to be in the same "partition", meaning all in
the same guest, or all in the host. KVM reflects that in the vcpu
numbering in the way that Li described, which gives userspace the
ability to control which vcpus are put on the same virtual core and
which SMT mode each vcpu runs in. So if userspace (aka qemu) creates
vcpus numbered 0, 4, 8, ..., they will run single-threaded, or if it
creates vcpus numbered 0, 1, 2, 3, they will run as 4 threads on one
core (not necessarily one particular physical core, but whichever
physical core one of them is on, the others will be on the same core).
Qemu currently doesn't map those numbers onto a dense contiguous set
of cpu numbers, though I suppose it could. If the discontiguous
numbering causes problems, we can change either qemu (to remap the
numbers) or KVM (to provide some other way of controlling the
threading mode of the guest).
Regards,
Paul.