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 15:03:48 +0300
User-agent: Mutt/1.8.0 (2017-02-23)

On Thu, Jun 15, 2017 at 01:42:56PM +0200, Paolo Bonzini wrote:
> 
> 
> On 15/06/2017 13:40, Roman Kagan wrote:
> > 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.
> 
> But who is using them, and why would they be doing that?  What is the
> advantage of using SynIC timers?

I guess because they are lighter-weight than HPET, and Windows used to
ignore apic timer so it would choose SynIC timers if available.
Dunno...

Roman.



reply via email to

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