qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Roman Kagan
Subject: Re: [Qemu-devel] [PATCH 05/23] hyperv: ensure VP index equal to QEMU cpu_index
Date: Thu, 15 Jun 2017 14:40:25 +0300
User-agent: Mutt/1.8.0 (2017-02-23)

On Thu, Jun 15, 2017 at 10:26:58AM +0200, Paolo Bonzini wrote:
> On 14/06/2017 20:59, Eduardo Habkost wrote:
> > On Wed, Jun 14, 2017 at 09:40:37PM +0300, Roman Kagan wrote:
> >> One more data point is that until now there was no use for vp_index in
> >> QEMU, so it didn't care how KVM managed it.  In KVM the only
> >> vp_index-aware path that the guests could trigger was exactly reading of
> >> HV_X64_MSR_VP_INDEX.
> >>
> >> So let me try to sum up (to make sure I understand it right);
> >>
> >> 1) we add KVM_CAP_HYPERV_SYNIC2 to KVM; when QEMU enables it KVM
> >>    switches to using vcpu_id as vp_index and stops zeroing synic pages
> > 
> > If we want to keep KVM code simpler, we could make QEMU
> > explicitly initialize vp_index using vcpu_id (== arch_id == apic_id)
> > if KVM_CAP_HYPERV_SYNIC2 is reported as supported.
> >
> >> 2) new QEMU refuses to start in non-compat mode when
> >>    KVM_CAP_HYPERV_SYNIC2 is not supported
> > 
> > It depends on which cases are considered "in non-compat mode".
> > Getting a VM not runnable just because the machine-type was
> > updated is not desirable, especially considering that on most
> > cases we will create the VCPUs on the same order and things would
> > keep working.  Probably the best we can do on this case is to
> > automatically enable compat mode, but print a warning saying
> > future QEMU versions might break if the kernel is not upgraded.
> 
> Anything that specifies hv_synic can be broken.  There was really no
> reason to specify it for anything except experimenting.

Hyper-V SynIC timers depend on it, and they work since QEMU 2.6 / KVM
4.5 and even supported by libvirt since 1.3.3.

> So QEMU never has to enable KVM_CAP_HYPERV_SYNIC.  No compat mode is
> necessary.  In fact, I don't see any reason to _keep_
> KVM_CAP_HYPERV_SYNIC in the kernel, either.  This means that KVM can
> also switch unconditionally the vp_index to vcpu_id, because old QEMU +
> new kernel won't even start.

I'm afraid this is too harsh on users...

Roman.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]