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. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list