Received: by 10.223.176.5 with SMTP id f5csp2162181wra; Thu, 8 Feb 2018 09:22:35 -0800 (PST) X-Google-Smtp-Source: AH8x225ILDkLmFeoYJgaAYApUR2Hfja7rC7iBPIh6dctbk5bik2pHHOO/TRwaK+uWqbAl2miWrnU X-Received: by 10.99.113.15 with SMTP id m15mr1129586pgc.236.1518110555158; Thu, 08 Feb 2018 09:22:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518110555; cv=none; d=google.com; s=arc-20160816; b=EZqoIVi0cU5S+abC8U5J8RCneOqoRsbnSqqEGqxu6JuvvR/jjUGTqnMtQXB8+LPk+v ag6IS0SxLlW2nuMEKh1WcVzQxNHcGIbTbob1N/t6VkYogrkmAioJwCFKkhTJ0I+J+gIt G9ZwcSEAFy/mHPl7eqBL1vfQZyBO7E8KvljLxeqzNoeHp7mS5jeXgysZH3Gids0pH985 BFoFGQv23Pfx09pT3ovNLI0JHNELrWQRtlTfokyW0li1r4stiwcW3SkCzmfXp5FdrEg5 eWLuPhwmRZRP+EUTwebjzMVcgT8/qwgCByGt6yE3SMXuHVaNM0IeqMU4vUh0PSQwZD4A Mj3g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=UPoEZD3kz5wEs71h1/TJKt2rHo5MK1d3ZRcWasiRuBc=; b=Rtl77Qa5O/wI+ZtVzIVp4dXXAhQ4s45IDaZboqDmHO1iX9UNwVOCpTwkm43KRL1cNr 8zlDre/xnoKRq63X1uVQKrLz8tyOQ1OHt/CHB1yvi5SPOiojKaFG3hUpiXvON9msj93q CWHlVS+5i3X4NRK0Y6tpGWpKwTLtF3i5FcuJRFp4iuoAtt2NCsBWjslTAXDINAXtO1q1 G5k4V4id8WJCCUe8Vdb8oLEF/eDZfIejl1eCTgsFrHzrSpTQOnNF8cfmXxcRYM/b0gmo KUvZixEAO5DydBLsqDzDo/bqvtVs5CZLhW8MW/FTcC6ttecjkMEiFDmdtbSvIT7eTkh+ XG9A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b5si244928pff.349.2018.02.08.09.22.19; Thu, 08 Feb 2018 09:22:35 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752498AbeBHRVC (ORCPT + 99 others); Thu, 8 Feb 2018 12:21:02 -0500 Received: from foss.arm.com ([217.140.101.70]:37790 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752208AbeBHRVB (ORCPT ); Thu, 8 Feb 2018 12:21:01 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 6E52880D; Thu, 8 Feb 2018 09:21:01 -0800 (PST) Received: from [10.1.206.28] (e107814-lin.cambridge.arm.com [10.1.206.28]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 088D63F24D; Thu, 8 Feb 2018 09:20:58 -0800 (PST) Subject: Re: [PATCH v1 09/16] kvm: arm/arm64: Delay stage2 page table allocation To: Christoffer Dall Cc: linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu, marc.zyngier@arm.com, linux-kernel@vger.kernel.org, kristina.martsenko@arm.com, peter.maydell@linaro.org, pbonzini@redhat.com, rkrcmar@redhat.com, will.deacon@arm.com, ard.biesheuvel@linaro.org, mark.rutland@arm.com, catalin.marinas@arm.com, Christoffer Dall References: <20180109190414.4017-1-suzuki.poulose@arm.com> <20180109190414.4017-10-suzuki.poulose@arm.com> <20180208110114.GL29286@cbox> From: Suzuki K Poulose Message-ID: <53d91b79-67f3-c86f-8cda-d18939cfcaf8@arm.com> Date: Thu, 8 Feb 2018 17:20:57 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <20180208110114.GL29286@cbox> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/02/18 11:01, Christoffer Dall wrote: > On Tue, Jan 09, 2018 at 07:04:04PM +0000, Suzuki K Poulose wrote: >> We allocate the entry level page tables for stage2 when the >> VM is created. This doesn't give us the flexibility of configuring >> the physical address space size for a VM. In order to allow >> the VM to choose the required size, we delay the allocation of >> stage2 entry level tables until we really try to map something. >> >> This could be either when the VM creates a memory range or when >> it tries to map a device memory. So we add in a hook to these >> two places to make sure the tables are allocated. We use >> kvm->slots_lock to serialize the allocation entry point, since >> we add hooks to the arch specific call back with the mutex held. ... >> >> -/** >> - * kvm_phys_addr_ioremap - map a device range to guest IPA >> - * >> - * @kvm: The KVM pointer >> - * @guest_ipa: The IPA at which to insert the mapping >> - * @pa: The physical address of the device >> - * @size: The size of the mapping >> +/* >> + * Finalise the stage2 page table layout. Must be called with kvm->slots_lock >> + * held. >> */ >> -int kvm_phys_addr_ioremap(struct kvm *kvm, phys_addr_t guest_ipa, >> +static int __kvm_init_stage2_table(struct kvm *kvm) >> +{ >> + /* Double check if somebody has already allocated it */ > > dubious comment: Either leave it out or explain that we need to check > again with the mutex held. > >> + if (likely(kvm->arch.pgd)) >> + return 0; >> + return kvm_alloc_stage2_pgd(kvm); >> +} >> + >> +static int kvm_init_stage2_table(struct kvm *kvm) >> +{ >> + int rc; >> + >> + /* >> + * Once allocated, the stage2 entry level tables are only >> + * freed when the KVM instance is destroyed. So, if we see >> + * something valid here, that guarantees that we have >> + * done the one time allocation and it is something valid >> + * and won't go away until the last reference to the KVM >> + * is gone. >> + */ > > Really not sure if this comment adds something beyond what's described > by the code already? Agreed. Will clean it up. Thanks Suzuki