On Sat, Sep 05, 2009 at 12:59:26AM +0200, Alexander Graf wrote: > > Am 04.09.2009 um 19:05 schrieb Marcelo Tosatti <[email protected]>: > >> 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 <[email protected]> >>> Signed-off-by: Alexander Graf <[email protected]> >> >> 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? -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
