From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Denis V. Lunev" Subject: Re: [PATCH v3] kvm:vmx: more complete state update on APICv on/off Date: Thu, 19 May 2016 08:40:13 +0300 Message-ID: <573D51BD.30807@openvz.org> References: <1463582900-22620-1-git-send-email-rkagan@virtuozzo.com> <573D1E7E.30203@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Cc: Paolo Bonzini , Steve Rutherford To: Yang Zhang , Roman Kagan , Return-path: Received: from mail-he1eur01on0129.outbound.protection.outlook.com ([104.47.0.129]:24192 "EHLO EUR01-HE1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752241AbcESHLJ (ORCPT ); Thu, 19 May 2016 03:11:09 -0400 In-Reply-To: <573D1E7E.30203@gmail.com> Sender: kvm-owner@vger.kernel.org List-ID: On 05/19/2016 05:01 AM, Yang Zhang wrote: > On 2016/5/18 22:48, Roman Kagan wrote: >> The function to update APICv on/off state (in particular, to deactivate >> it when enabling Hyper-V SynIC), used to be incomplete: it didn't adjust >> APICv-related fields among secondary processor-based VM-execution >> controls. > > Hi Roman, > > I have question about the performance between APICv and Hyper-V SynIC. > As we known APICv is a hardware feature which including three > features: APIC register virtualization, virtual interrupt delivery and > Posted Interrupt. My gut feeling is that the average performance that > improved by APICv should greater than Hyper-v SynIC. Am i right? If > yes, current policy that disable the whole APICv seems too aggressive. > Argh.. We have faced this situation in Parallels Desktop may be 3 years ago. Unfortunately, there is no data at the moment. It was toooo old and made by other team. As far as I remember (for that time), interrupt delivery becomes faster, but operations with on of CR registers becomes much slower and general performance score becomes lower. The problem with SynIC is that it is mandatory prerequisite to enable HyperV bus in the guest, which is our final goal. Thus there is no other way for us. > btw, do you have any performance data, not micro-level? Thanks. > not collected at the moment, especially with KVM.