On Wed, Jun 14, 2017 at 03:11:17PM +0200, Igor Mammedov wrote: > On Wed, 14 Jun 2017 10:01:49 -0300 > Eduardo Habkost <ehabk...@redhat.com> wrote: > > > On Wed, Jun 14, 2017 at 01:26:44PM +0200, Paolo Bonzini 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 > > > future. But the APIC id is also the KVM vcpu_id, so there's no need to > > > have VP_INDEX maintained by QEMU. > > > > No, KVM really uses the VCPU _index_ for HV_X64_MSR_VP_INDEX: > and as you pointed out that works just by luck, > as soon as we there would be out of order created CPUs > returned value won't match cpu_index.
This is true, which makes it even worse. > > So instead of spreading this nonsense out to QEMU, is it possible > to fix kernel(kvm+guest) to use apic_id instead? It is possible to fix the kernel, but if we want to support older kernels, QEMU has no choice but creating the VCPUs always in the same order. -- Eduardo
