On 23/05/2016 03:34, Yang Zhang wrote: > On 2016/5/20 14:38, Denis V. Lunev wrote: >> On 05/20/2016 04:15 AM, Yang Zhang wrote: >>> On 2016/5/19 13:40, Denis V. Lunev wrote: >>>> 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. >>>>> 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. >>> >>> I guess the data may be collected on KVM w/o APICv supporting. >>> Normally, APICv provides the faster way to delivery interrupt than >>> software solution. >>> >> this seems useless. >> >> Once again, interrupt delivery with APICv will be faster, >> this is out of question. Though integral tests can show >> performance degradation. I know, this sounds silly >> and this is test-dependent. >> >> We are going to make this testing after implementing >> of HyperV TSC page avoid extra VM exit on context >> switch. This seems more beneficial at the moment. >> >> For this reason APICv is disabled in Parallels Desktop >> and Parallels Server v6, which are not KVM based. >> >>>> >>>> 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. >>> >>> I see. Actually, we saw the performance improvement with SynIC timer >>> but we don't want to turn off APICv since we think it may hurt the >>> performance. Is it possible to turn on SynIC timer without disable >>> APICv? >>> >> unfortunately no. The problem is AutoEOI feature. At >> least we have no idea how to do that. > > Ok. Thanks for your explanation. You can search the KVM mailing list archives; there are some discussions between me, Andrey and Roman regarding APICv---when I tried their unit tests on a Haswell-EP machine I found that they broke due to AutoEOI, and we came up with the solution of disabling APICv. For what it's worth, we've also seen only very small performance improvements from APICv, with the exception of nested virtualization where APICv's impact is large. Paolo -- 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
