From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mukesh Rathor Subject: Re: [PATCH 10/18 V2]: PVH xen: introduce vmx_pvh.c and pvh.c Date: Thu, 4 Apr 2013 16:00:16 -0700 Message-ID: <20130404160016.16b38274@mantra.us.oracle.com> References: <20130315174145.4bc0e78f@mantra.us.oracle.com> <20130321164912.GO12338@ocelot.phlegethon.org> <20130402183734.16b1ba68@mantra.us.oracle.com> <20130404091219.GA42936@ocelot.phlegethon.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20130404091219.GA42936@ocelot.phlegethon.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Tim Deegan Cc: "Xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On Thu, 4 Apr 2013 10:12:19 +0100 Tim Deegan wrote: > At 18:37 -0700 on 02 Apr (1364927854), Mukesh Rathor wrote: > > On Thu, 21 Mar 2013 16:49:12 +0000 Tim Deegan wrote: > > > > +static int vmxit_invlpg(void) > > > > +{ > > > > + ulong vaddr = __vmread(EXIT_QUALIFICATION); > > > > + > > > > + vmx_update_guest_eip(); > > > > + vpid_sync_vcpu_gva(current, vaddr); > > > > > > If there's no special handling of invlpg, you should just not > > > intercept it. > > > > well, we call vpid_sync_vcpu_gva(), but we can optimize this further > > in future. > > It would be trivial just to drop the intercept now. All > vpid_sync_vcpu_gva() does is emulate (potentially rather > inefficiently) the invlpg that's been intercepted. Ok, got it now. Thanks.