From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] KVM: x86: Implement PCID/INVPCID for guests with EPT Date: Sun, 13 May 2012 13:02:55 +0300 Message-ID: <4FAF86CF.1000207@redhat.com> References: <4FABAB05.1080001@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "'kvm@vger.kernel.org'" To: "Mao, Junjie" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:7940 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751725Ab2EMKDC (ORCPT ); Sun, 13 May 2012 06:03:02 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On 05/11/2012 08:58 AM, Mao, Junjie wrote: > > > > > > +static bool vmx_pcid_supported(void) > > > +{ > > > + /* Enable PCID for non-ept guests may cause performance regression > > > +*/ > > > > Why is that? > > For guests using shadow page tables, every INVPCID must be intercepted so that changes in guest page tables can be reflected on the shadow ones, which brings about performance troubles. Without INVPCID, the PCID feature has little benefits. As a result, PCID/INVPCID is not exposed to non-ept guests. Sorry for being unclear in the comment. Okay, please update the comment. btw, are there plans to add PCID support to Linux in the OS role? > > > + > > > + vmx->invpcid_enabled = false; > > > + if (vmx_pcid_supported()) { > > > + exec_control = vmcs_read32(SECONDARY_VM_EXEC_CONTROL); > > > + if (exec_control & SECONDARY_EXEC_ENABLE_INVPCID) { > > > + best = kvm_find_cpuid_entry(vcpu, 0x1, 0); > > > + if (best && (best->ecx & bit(X86_FEATURE_PCID))) > > > + vmx->invpcid_enabled = true; > > > + else { > > > + exec_control &= ~SECONDARY_EXEC_ENABLE_INVPCID; > > > + vmcs_write32(SECONDARY_VM_EXEC_CONTROL, > > > + exec_control); > > > + best = kvm_find_cpuid_entry(vcpu, 0x7, 0); > > > + best->ecx &= ~bit(X86_FEATURE_INVPCID); > > > + } > > > + } > > > + } > > > } > > > > > > > > > > If we enter a nested guest (which is running without PCID), we need either to > > handle INVPCID exits (and inject a #UD) or disable INVPCID in exec controls. > > The first is faster since it doesn't involve VMWRITEs. > > If we do that, we don't need this code (since it will work for non-nested guests > > as well). > > I'm not that familiar with how nested guests work. So excuse me for a possibly silly question: if we choose to trigger INVPCID exits and inject #UD for both non-nested and nested guests without INVPCID, that means 'INVLPG exiting' should also be set (which is a must for triggering INVPCID exits). Can it cause performance problems for non-nested ept guests? It can. It was my comment that was silly, the guest and the nested guest use different vmcses, so all you need is to make sure the write here goes to the non-nested vmcs (and "enable INVPCID" is kept as zero for nested vmcses). -- error compiling committee.c: too many arguments to function