Re: [Qemu-devel] [PATCH 05/23] hyperv: ensure VP index equal to QEMU cpu_index

[Eduardo Habkost]

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