From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo Tosatti Subject: Re: [PATCH] Don't map nested_vmcb on INTERCEPT_MSR_PROT Date: Fri, 4 Sep 2009 21:29:30 -0300 Message-ID: <20090905002930.GA10975@amt.cnet> References: <1251989512-22072-1-git-send-email-agraf@suse.de> <20090904170521.GA6591@amt.cnet> <49C3DCB0-64FB-4B31-8264-41AC9FE217F6@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "kvm@vger.kernel.org" , Joerg Roedel To: Alexander Graf Return-path: Received: from mx1.redhat.com ([209.132.183.28]:3143 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934630AbZIEAaI (ORCPT ); Fri, 4 Sep 2009 20:30:08 -0400 Content-Disposition: inline In-Reply-To: <49C3DCB0-64FB-4B31-8264-41AC9FE217F6@suse.de> Sender: kvm-owner@vger.kernel.org List-ID: On Sat, Sep 05, 2009 at 12:59:26AM +0200, Alexander Graf wrote: > > Am 04.09.2009 um 19:05 schrieb Marcelo Tosatti : > >> On Thu, Sep 03, 2009 at 04:51:52PM +0200, Alexander Graf wrote: >>> Thanks to Joerg's previous series of cleanups, we now have almost all >>> information we need to decide what to do on #VMEXIT because we get >>> the variables from the VMCB on VMRUN. >>> >>> Unfortunately there's one piece that slipped through the conversion, >>> namely the MSR intercept which still tries to map the nested VMCB >>> to find out if MSRs are intercepted. >>> >>> So let's use the cached value, removing the need for two atomic maps >>> (which breaks anyways) and fix an oops along the way. >>> >>> CC: Joerg Roedel >>> Signed-off-by: Alexander Graf >> >> Applied, thanks. >> >> BTW, why nested_svm_map takes mmap_sem? Thats looks wrong. > > Hm, good question. > > As long as it's an atomic section that only touches vcpu local data > there's no need to lock at all, right? Yes. gfn_to_page / get_user_pages will grab mmap_sem if required. Can you please send a patch to drop it from nested_svm_map?