From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH v5 04/13] ARM: KVM: Memory virtualization setup Date: Mon, 12 Dec 2011 16:40:05 +0200 Message-ID: <4EE61245.1010100@redhat.com> References: <20111211102403.21693.6887.stgit@localhost> <20111211102442.21693.544.stgit@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: android-virt@lists.cs.columbia.edu, kvm@vger.kernel.org, Marc.Zyngier@arm.com, catalin.marinas@arm.com, tech@virtualopensystems.com, peter.maydell@linaro.org To: Christoffer Dall Return-path: Received: from mx1.redhat.com ([209.132.183.28]:58488 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752952Ab1LLOkZ (ORCPT ); Mon, 12 Dec 2011 09:40:25 -0500 In-Reply-To: <20111211102442.21693.544.stgit@localhost> Sender: kvm-owner@vger.kernel.org List-ID: On 12/11/2011 12:24 PM, Christoffer Dall wrote: > This commit introduces the framework for guest memory management > through the use of 2nd stage translation. Each VM has a pointer > to a level-1 tabled (the pgd field in struct kvm_arch) which is > used for the 2nd stage translations. Entries are added when handling > guest faults (later patch) and the table itself can be allocated and > freed through the following functions implemented in > arch/arm/kvm/arm_mmu.c: > - kvm_alloc_stage2_pgd(struct kvm *kvm); > - kvm_free_stage2_pgd(struct kvm *kvm); > > Further, each entry in TLBs and caches are tagged with a VMID > identifier in addition to ASIDs. The VMIDs are managed using > a bitmap and assigned when creating the VM in kvm_arch_init_vm() > where the 2nd stage pgd is also allocated. The table is freed in > kvm_arch_destroy_vm(). Both functions are called from the main > KVM code. > > > struct kvm_arch { > - pgd_t *pgd; /* 1-level 2nd stage table */ > + u32 vmid; /* The VMID used for the virt. memory system */ > + pgd_t *pgd; /* 1-level 2nd stage table */ > + u64 vttbr; /* VTTBR value associated with above pgd and vmid */ > }; > I can't say I have a solid grasp here, but my feeling is that vmid needs to be per-vcpu. Otherwise vcpu 1 can migrate to a cpu that previously ran vcpu 0, and reuse its tlb since they have the same vmid. -- error compiling committee.c: too many arguments to function