From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] KVM: MMU: Replace role.glevels with role.cr4_pae Date: Wed, 14 Apr 2010 19:32:12 +0300 Message-ID: <4BC5EE0C.60705@redhat.com> References: <1271262003-29973-1-git-send-email-avi@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org To: Marcelo Tosatti Return-path: Received: from mx1.redhat.com ([209.132.183.28]:58191 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754876Ab0DNRQQ (ORCPT ); Wed, 14 Apr 2010 13:16:16 -0400 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o3EHFuGr027888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 14 Apr 2010 13:16:16 -0400 Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com [10.35.255.11]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o3EGWCjN001242 for ; Wed, 14 Apr 2010 12:32:13 -0400 In-Reply-To: <1271262003-29973-1-git-send-email-avi@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 04/14/2010 07:20 PM, Avi Kivity wrote: > There is no real distinction between glevels=3 and glevels=4; both have > exactly the same format and the code is treated exactly the same way. Drop > role.glevels and replace is with role.cr4_pae (which is meaningful). This > simplifies the code a bit. > > As a side effect, it allows sharing shadow page tables between pae and > longmode guest page tables at the same guest page. > > > static int kvm_sync_page(struct kvm_vcpu *vcpu, struct kvm_mmu_page *sp) > { > - if (sp->role.glevels != vcpu->arch.mmu.root_level) { > + if (sp->role.cr4_pae != !!is_pae(vcpu)) { > kvm_mmu_zap_page(vcpu->kvm, sp); > return 1; > } > This bit confuses me a little. Why is it needed? It will never hit from mmu_sync_children(), and as for kvm_mmu_get_page(), it will simply zap unrelated pages? Is it related to the restriction that we can only unsync if we have just one shadow page for a gfn? That's somewhat artificial (and hurts nonpae guests, and guests with linear page tables). -- error compiling committee.c: too many arguments to function