RE: [RFC PATCH 0/5] Utilizing VMX preemption for timer virtualization

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

 




> -----Original Message-----
> From: kvm-owner@xxxxxxxxxxxxxxx [mailto:kvm-owner@xxxxxxxxxxxxxxx] On
> Behalf Of Jan Kiszka
> Sent: Thursday, May 19, 2016 11:04 PM
> To: Yunhong Jiang <yunhong.jiang@xxxxxxxxxxxxxxx>; kvm@xxxxxxxxxxxxxxx
> Cc: rkrcmar@xxxxxxxxxx; pbonzini@xxxxxxxxxx
> Subject: Re: [RFC PATCH 0/5] Utilizing VMX preemption for timer
> virtualization
> 
> On 2016-05-20 03:44, Yunhong Jiang wrote:
> > The VMX-preemption timer is a feature on VMX, it counts down, from the
> > value loaded by VM entry, in VMX nonroot operation. When the timer
> > counts down to zero, it stops counting down and a VM exit occurs.
> >
> > The VMX preemption timer for tsc deadline timer virtualization. The
> > VMX preemption timer is armed when the vCPU is running, and a VMExit
> > will happen if the virtual TSC deadline timer expires.
> >
> > When the vCPU thread is scheduled out, the tsc deadline timer
> > virtualization will be switched to use the current solution, i.e. use
> > the timer for it. It's switched back to VMX preemption timer when the
> > vCPU thread is scheduled int.
> >
> > This solution replace the complex OS's hrtimer system, and also the
> > host timer interrupt handling cost, with a preemption_timer VMexit. It
> > fits well for some NFV usage scenario, when the vCPU is bound to a
> > pCPU and the pCPU is isolated, or some similar scenarioes.
> >
> > However, it possibly has impact if the vCPU thread is scheduled in/out
> > very frequently, because it switches from/to the hrtimer emulation a
> > lot. A module parameter is provided to turn it on or off.
> 
> IIRC, VMX preemption timer was broken on several older CPUs. That was
> one reason we didn't use it to emulated nested preemption timer. Were
> all those CPUs also not exposing the TCP deadline timer?
> 
> In any case, just checking for the feature bit like you do in patch 2
> shouldn't be enough to catch those CPUs. Or were there microcode patches
> distributed by now that translated the errata into bit removals?

I didn't know about this and will check internally.

Replying on outlook now because linux side is broken.
Sorry if anything wrong on the format.

--jyh

> 
> Jan
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux