On Thu, Aug 01, 2019 at 06:54:49PM +0200, Paolo Bonzini wrote: > On 01/08/19 18:51, Rafael J. Wysocki wrote: > > On 8/1/2019 9:06 AM, Wanpeng Li wrote: > >> From: Wanpeng Li <wanpengli@xxxxxxxxxxx> > >> > >> The downside of guest side polling is that polling is performed even > >> with other runnable tasks in the host. However, even if poll in kvm > >> can aware whether or not other runnable tasks in the same pCPU, it > >> can still incur extra overhead in over-subscribe scenario. Now we can > >> just enable guest polling when dedicated pCPUs are available. > >> > >> Cc: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx> > >> Cc: Paolo Bonzini <pbonzini@xxxxxxxxxx> > >> Cc: Radim Krčmář <rkrcmar@xxxxxxxxxx> > >> Cc: Marcelo Tosatti <mtosatti@xxxxxxxxxx> > >> Signed-off-by: Wanpeng Li <wanpengli@xxxxxxxxxxx> > > > > Paolo, Marcelo, any comments? > > Yes, it's a good idea. > > Acked-by: Paolo Bonzini <pbonzini@xxxxxxxxxx> > > Paolo I think KVM_HINTS_REALTIME is being abused somewhat. It has no clear meaning and used in different locations for different purposes. For example, i think that using pv queued spinlocks and haltpoll is a desired scenario, which the patch below disallows. Wanpeng Li, currently the driver does not autoload. So polling in the guest has to be enabled manually. Isnt that sufficient?
