On Wed, 14 Jun 2017 13:26:44 +0200 Paolo Bonzini <pbonz...@redhat.com> wrote:
> On 14/06/2017 13:25, Roman Kagan wrote: > >> The problem with that is that it will break as soon as we create > >> VCPUs in a different order. Unsolvable on hosts that don't allow > >> HV_X64_MSR_VP_INDEX to be set, however. > > Right, thanks for putting together a detailed explanation. > > > > This was a thinko back then, not to have HV_X64_MSR_VP_INDEX maintained > > by QEMU. I'm going to post a patch to KVM fixing that. > > > > Meanwhile QEMU needs a way to maintain its notion of vp_index that is > > 1) in sync with kernel's notion > > 2) also with kernels that don't support setting the msr > > 3) persistent across migrations > > > > cpu_index looked like a perfect candidate. > > > > What you want is the APIC id, > which _is_ cpu_index but may not be in the depending on topology cpu_index won't be the same as APIC ID/vcpu_id /AMDs odd core count/. > 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 > > Paolo
