On Thu, Jun 15, 2017 at 07:05:29PM +0300, Roman Kagan wrote: > On Thu, Jun 15, 2017 at 03:27:28PM +0200, Igor Mammedov wrote: [...] > > > > > future. But the APIC id is also the KVM vcpu_id, so there's no need > > > > > to > > > > > have VP_INDEX maintained by QEMU. > > > > agreed it'd be better to reuse vcpu_id/apic id as interface between > > > > qemu/kvm/guest instead of adding additional cpu_index concept in ABI > > > > > > Having consulted the spec, I'm not so confident any more this is the > > > right move. > > > > > > > 7.8.1 Virtual Processor Index > > > > > > > > Virtual processors are identified by using an index (VP index). The > > > > maximum number of virtual processors per partition supported by the > > > > current implementation of the hypervisor can be obtained through CPUID > > > > leaf 0x40000005. A virtual processor index must be less than the > > > > maximum number of virtual processors per partition. > > > > > > This seems to imply that VP index should be dense. As if they use it > > > directly as an index into an array whose length is equal to the max > > > number of vcpus. (BTW the value we report for it is currently hardcoded > > > to 0x40 which probably needs fixing, too.) > > the question here is where "maximum number of virtual processors" comes from > > We provide it in a corresponding cpuid leaf. > > > if it's possible to tell guest value explicitly, > > we can use pcms->apic_id_limit for it. > > But, depending on the apic_id encoding scheme, this can be arbitrarily > bigger than the actual maximum number of vcpus. Which can result in > guest confusion or inefficiency.
Note that it will be bigger only if threads-per-core or cores-per-thread are not powers of 2. If your use case don't require configuration of a virtual thread/core topology, the APIC IDs can be always contiguous. -- Eduardo