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

[Eduardo Habkost]

On Wed, Jun 14, 2017 at 03:11:17PM +0200, Igor Mammedov wrote:
> On Wed, 14 Jun 2017 10:01:49 -0300
> Eduardo Habkost <address@hidden> 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