From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9E98AC433E6 for ; Mon, 8 Mar 2021 13:54:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 651C7651CC for ; Mon, 8 Mar 2021 13:54:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229573AbhCHNwt (ORCPT ); Mon, 8 Mar 2021 08:52:49 -0500 Received: from mail.kernel.org ([198.145.29.99]:36464 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229965AbhCHNwl (ORCPT ); Mon, 8 Mar 2021 08:52:41 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 096A5651C2; Mon, 8 Mar 2021 13:52:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1615211560; bh=DvWcVEv2Vrw8pMLTCVc0UcvS+o5tJf6N3Zi7lsDgBtw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=n0SmlzBCUl9vwUrnk3vCdFm9Ed2nFSvhEw7I1IbWCJJoc5cL/37GnXspwt50WvvS7 afmBNhOO9O9J7al1g+H/XvELL8IE8nj95MvOIwvspwkz3LhRBsXBpgp7bXnZzvU7OU HK5KQO1YCil3BaiJzcSVOOhc9xvLROz2SXhjo5mxlFesByhc3vGnVgwRlQgzpvbLWP xQpNMhZ7asJwO4eAcs3W0DnephAAMEW/uLkI9G9bZNr0N74JWbnCGJ/MrDwXpHy6cC z4xcns0XTko0wLEsBI+P+Q8EqXY35MknsD51UKfcJ7GWXRgPoKWJshn1klQ+6EWf4C 7DMF6cUcpbcdg== Date: Mon, 8 Mar 2021 13:52:34 +0000 From: Will Deacon To: Quentin Perret Cc: catalin.marinas@arm.com, maz@kernel.org, james.morse@arm.com, julien.thierry.kdev@gmail.com, suzuki.poulose@arm.com, android-kvm@google.com, linux-kernel@vger.kernel.org, kernel-team@android.com, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, tabba@google.com, mark.rutland@arm.com, dbrazdil@google.com, mate.toth-pal@arm.com, seanjc@google.com, robh+dt@kernel.org Subject: Re: [PATCH v3 29/32] KVM: arm64: Wrap the host with a stage 2 Message-ID: <20210308135234.GB26128@willie-the-truck> References: <20210302150002.3685113-1-qperret@google.com> <20210302150002.3685113-30-qperret@google.com> <20210305192905.GE23633@willie-the-truck> <20210308124606.GA25879@willie-the-truck> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 08, 2021 at 01:38:07PM +0000, Quentin Perret wrote: > On Monday 08 Mar 2021 at 12:46:07 (+0000), Will Deacon wrote: > > > > > +static int host_stage2_idmap(u64 addr) > > > > > +{ > > > > > + enum kvm_pgtable_prot prot = KVM_PGTABLE_PROT_R | KVM_PGTABLE_PROT_W; > > > > > + struct kvm_mem_range range; > > > > > + bool is_memory = find_mem_range(addr, &range); > > > > > + struct hyp_pool *pool = is_memory ? &host_s2_mem : &host_s2_dev; > > > > > + int ret; > > > > > + > > > > > + if (is_memory) > > > > > + prot |= KVM_PGTABLE_PROT_X; > > > > > + > > > > > + hyp_spin_lock(&host_kvm.lock); > > > > > + ret = kvm_pgtable_stage2_idmap_greedy(&host_kvm.pgt, addr, prot, > > > > > + &range, pool); > > > > > + if (is_memory || ret != -ENOMEM) > > > > > + goto unlock; > > > > > + host_stage2_unmap_dev_all(); > > > > > + ret = kvm_pgtable_stage2_idmap_greedy(&host_kvm.pgt, addr, prot, > > > > > + &range, pool); > > > > > > > > I find this _really_ hard to reason about, as range is passed by reference > > > > and we don't reset it after the first call returns -ENOMEM for an MMIO > > > > mapping. Maybe some commentary on why it's still valid here? > > > > > > Sure, I'll add something. FWIW, that is intended -- -ENOMEM can only be > > > caused by the call to kvm_pgtable_stage2_map() which leaves the range > > > untouched. So, as long as we don't release the lock, the range returned > > > by the first call to kvm_pgtable_stage2_idmap_greedy() should still be > > > valid. I suppose I could call kvm_pgtable_stage2_map() directly the > > > second time to make it obvious but I thought this would expose the > > > internal of kvm_pgtable_stage2_idmap_greedy() a little bit too much. > > > > I can see it both ways, but updating the kerneldoc for > > kvm_pgtable_stage2_idmap_greedy() to state in which cases the range is > > updated and how would be helpful. It just says "negative error code on > > failure" at the moment. > > Alternatively I could expose the 'reduce' path (maybe with another name > e.g. stage2_find_compatible_range() or so) and remove the > kvm_pgtable_stage2_idmap_greedy() wrapper. So it'd be the caller's > responsibility to not release the lock in between > stage2_find_compatible_range() and kvm_pgtable_stage2_map() for > instance, but that sounds reasonable to me. And that would make it > explicit it's the _map() path that failed with -ENOMEM, and that the > range can be re-used the second time. > > Thoughts? I suppose it depends on whether or not you reckon this could be optimised into a single-pass of the page-table. If not, then splitting it up makes sense to me (and actually, it's not like this has tonnes of callers so even if we changed things in future it wouldn't be too hard to fix them up). Will From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 71863C433DB for ; Mon, 8 Mar 2021 13:52:46 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id C6411651C7 for ; Mon, 8 Mar 2021 13:52:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C6411651C7 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvmarm-bounces@lists.cs.columbia.edu Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 4A6FE4B6EE; Mon, 8 Mar 2021 08:52:45 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Authentication-Results: mm01.cs.columbia.edu (amavisd-new); dkim=softfail (fail, message has been altered) header.i=@kernel.org Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O97FHRY2ySkN; Mon, 8 Mar 2021 08:52:43 -0500 (EST) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id D1E1B4B704; Mon, 8 Mar 2021 08:52:43 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 592004B5FD for ; Mon, 8 Mar 2021 08:52:43 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SmzV9gewWZUc for ; Mon, 8 Mar 2021 08:52:42 -0500 (EST) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id DA5DF4B704 for ; Mon, 8 Mar 2021 08:52:41 -0500 (EST) Received: by mail.kernel.org (Postfix) with ESMTPSA id 096A5651C2; Mon, 8 Mar 2021 13:52:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1615211560; bh=DvWcVEv2Vrw8pMLTCVc0UcvS+o5tJf6N3Zi7lsDgBtw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=n0SmlzBCUl9vwUrnk3vCdFm9Ed2nFSvhEw7I1IbWCJJoc5cL/37GnXspwt50WvvS7 afmBNhOO9O9J7al1g+H/XvELL8IE8nj95MvOIwvspwkz3LhRBsXBpgp7bXnZzvU7OU HK5KQO1YCil3BaiJzcSVOOhc9xvLROz2SXhjo5mxlFesByhc3vGnVgwRlQgzpvbLWP xQpNMhZ7asJwO4eAcs3W0DnephAAMEW/uLkI9G9bZNr0N74JWbnCGJ/MrDwXpHy6cC z4xcns0XTko0wLEsBI+P+Q8EqXY35MknsD51UKfcJ7GWXRgPoKWJshn1klQ+6EWf4C 7DMF6cUcpbcdg== Date: Mon, 8 Mar 2021 13:52:34 +0000 From: Will Deacon To: Quentin Perret Subject: Re: [PATCH v3 29/32] KVM: arm64: Wrap the host with a stage 2 Message-ID: <20210308135234.GB26128@willie-the-truck> References: <20210302150002.3685113-1-qperret@google.com> <20210302150002.3685113-30-qperret@google.com> <20210305192905.GE23633@willie-the-truck> <20210308124606.GA25879@willie-the-truck> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Cc: android-kvm@google.com, catalin.marinas@arm.com, mate.toth-pal@arm.com, seanjc@google.com, tabba@google.com, linux-kernel@vger.kernel.org, robh+dt@kernel.org, linux-arm-kernel@lists.infradead.org, maz@kernel.org, kernel-team@android.com, kvmarm@lists.cs.columbia.edu X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu On Mon, Mar 08, 2021 at 01:38:07PM +0000, Quentin Perret wrote: > On Monday 08 Mar 2021 at 12:46:07 (+0000), Will Deacon wrote: > > > > > +static int host_stage2_idmap(u64 addr) > > > > > +{ > > > > > + enum kvm_pgtable_prot prot = KVM_PGTABLE_PROT_R | KVM_PGTABLE_PROT_W; > > > > > + struct kvm_mem_range range; > > > > > + bool is_memory = find_mem_range(addr, &range); > > > > > + struct hyp_pool *pool = is_memory ? &host_s2_mem : &host_s2_dev; > > > > > + int ret; > > > > > + > > > > > + if (is_memory) > > > > > + prot |= KVM_PGTABLE_PROT_X; > > > > > + > > > > > + hyp_spin_lock(&host_kvm.lock); > > > > > + ret = kvm_pgtable_stage2_idmap_greedy(&host_kvm.pgt, addr, prot, > > > > > + &range, pool); > > > > > + if (is_memory || ret != -ENOMEM) > > > > > + goto unlock; > > > > > + host_stage2_unmap_dev_all(); > > > > > + ret = kvm_pgtable_stage2_idmap_greedy(&host_kvm.pgt, addr, prot, > > > > > + &range, pool); > > > > > > > > I find this _really_ hard to reason about, as range is passed by reference > > > > and we don't reset it after the first call returns -ENOMEM for an MMIO > > > > mapping. Maybe some commentary on why it's still valid here? > > > > > > Sure, I'll add something. FWIW, that is intended -- -ENOMEM can only be > > > caused by the call to kvm_pgtable_stage2_map() which leaves the range > > > untouched. So, as long as we don't release the lock, the range returned > > > by the first call to kvm_pgtable_stage2_idmap_greedy() should still be > > > valid. I suppose I could call kvm_pgtable_stage2_map() directly the > > > second time to make it obvious but I thought this would expose the > > > internal of kvm_pgtable_stage2_idmap_greedy() a little bit too much. > > > > I can see it both ways, but updating the kerneldoc for > > kvm_pgtable_stage2_idmap_greedy() to state in which cases the range is > > updated and how would be helpful. It just says "negative error code on > > failure" at the moment. > > Alternatively I could expose the 'reduce' path (maybe with another name > e.g. stage2_find_compatible_range() or so) and remove the > kvm_pgtable_stage2_idmap_greedy() wrapper. So it'd be the caller's > responsibility to not release the lock in between > stage2_find_compatible_range() and kvm_pgtable_stage2_map() for > instance, but that sounds reasonable to me. And that would make it > explicit it's the _map() path that failed with -ENOMEM, and that the > range can be re-used the second time. > > Thoughts? I suppose it depends on whether or not you reckon this could be optimised into a single-pass of the page-table. If not, then splitting it up makes sense to me (and actually, it's not like this has tonnes of callers so even if we changed things in future it wouldn't be too hard to fix them up). Will _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 870B4C433DB for ; Mon, 8 Mar 2021 13:56:56 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 0B560651D1 for ; Mon, 8 Mar 2021 13:56:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0B560651D1 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=8w5eXNB66a85JXwowEc1n5ZTD717tp0geNA/zXIp7/k=; b=nbh5p17cvmhd5x1FVRPp2x79/ csfrEkVatxc+JnO8XX4sbUSJNupI3sKvL+u6vqAoWAZeS/hdde2RZbLM2z/fCRU2W9RRuQXsiqxez knDfBxa9y8a4l7ppx8csM+GnUvt8OCthCWibfBxExQE6f+vRBew6W7uLYL19+W7RqvHmgshA4uYEC 2GVPVYX5dZdu+zXVmqK7emLASErUCzgvOJtvr9F/Qp/5QCF5SOPUVwsM1j4tZNv6bmo1J9dmbV7+k irg9yGuybXUu3x8KPcYZIPrC86hF47vbZH1PVDlBuhQnLP+YgcJoay7AKDM8AN2kMYoEUHz/pqXrK 8jDD4fqfw==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lJGM0-0001Uj-BA; Mon, 08 Mar 2021 13:55:24 +0000 Received: from mail.kernel.org ([198.145.29.99]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lJGJO-00HawE-FW for linux-arm-kernel@lists.infradead.org; Mon, 08 Mar 2021 13:52:45 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id 096A5651C2; Mon, 8 Mar 2021 13:52:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1615211560; bh=DvWcVEv2Vrw8pMLTCVc0UcvS+o5tJf6N3Zi7lsDgBtw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=n0SmlzBCUl9vwUrnk3vCdFm9Ed2nFSvhEw7I1IbWCJJoc5cL/37GnXspwt50WvvS7 afmBNhOO9O9J7al1g+H/XvELL8IE8nj95MvOIwvspwkz3LhRBsXBpgp7bXnZzvU7OU HK5KQO1YCil3BaiJzcSVOOhc9xvLROz2SXhjo5mxlFesByhc3vGnVgwRlQgzpvbLWP xQpNMhZ7asJwO4eAcs3W0DnephAAMEW/uLkI9G9bZNr0N74JWbnCGJ/MrDwXpHy6cC z4xcns0XTko0wLEsBI+P+Q8EqXY35MknsD51UKfcJ7GWXRgPoKWJshn1klQ+6EWf4C 7DMF6cUcpbcdg== Date: Mon, 8 Mar 2021 13:52:34 +0000 From: Will Deacon To: Quentin Perret Cc: catalin.marinas@arm.com, maz@kernel.org, james.morse@arm.com, julien.thierry.kdev@gmail.com, suzuki.poulose@arm.com, android-kvm@google.com, linux-kernel@vger.kernel.org, kernel-team@android.com, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, tabba@google.com, mark.rutland@arm.com, dbrazdil@google.com, mate.toth-pal@arm.com, seanjc@google.com, robh+dt@kernel.org Subject: Re: [PATCH v3 29/32] KVM: arm64: Wrap the host with a stage 2 Message-ID: <20210308135234.GB26128@willie-the-truck> References: <20210302150002.3685113-1-qperret@google.com> <20210302150002.3685113-30-qperret@google.com> <20210305192905.GE23633@willie-the-truck> <20210308124606.GA25879@willie-the-truck> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210308_135243_193068_C5D63D67 X-CRM114-Status: GOOD ( 29.68 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Mar 08, 2021 at 01:38:07PM +0000, Quentin Perret wrote: > On Monday 08 Mar 2021 at 12:46:07 (+0000), Will Deacon wrote: > > > > > +static int host_stage2_idmap(u64 addr) > > > > > +{ > > > > > + enum kvm_pgtable_prot prot = KVM_PGTABLE_PROT_R | KVM_PGTABLE_PROT_W; > > > > > + struct kvm_mem_range range; > > > > > + bool is_memory = find_mem_range(addr, &range); > > > > > + struct hyp_pool *pool = is_memory ? &host_s2_mem : &host_s2_dev; > > > > > + int ret; > > > > > + > > > > > + if (is_memory) > > > > > + prot |= KVM_PGTABLE_PROT_X; > > > > > + > > > > > + hyp_spin_lock(&host_kvm.lock); > > > > > + ret = kvm_pgtable_stage2_idmap_greedy(&host_kvm.pgt, addr, prot, > > > > > + &range, pool); > > > > > + if (is_memory || ret != -ENOMEM) > > > > > + goto unlock; > > > > > + host_stage2_unmap_dev_all(); > > > > > + ret = kvm_pgtable_stage2_idmap_greedy(&host_kvm.pgt, addr, prot, > > > > > + &range, pool); > > > > > > > > I find this _really_ hard to reason about, as range is passed by reference > > > > and we don't reset it after the first call returns -ENOMEM for an MMIO > > > > mapping. Maybe some commentary on why it's still valid here? > > > > > > Sure, I'll add something. FWIW, that is intended -- -ENOMEM can only be > > > caused by the call to kvm_pgtable_stage2_map() which leaves the range > > > untouched. So, as long as we don't release the lock, the range returned > > > by the first call to kvm_pgtable_stage2_idmap_greedy() should still be > > > valid. I suppose I could call kvm_pgtable_stage2_map() directly the > > > second time to make it obvious but I thought this would expose the > > > internal of kvm_pgtable_stage2_idmap_greedy() a little bit too much. > > > > I can see it both ways, but updating the kerneldoc for > > kvm_pgtable_stage2_idmap_greedy() to state in which cases the range is > > updated and how would be helpful. It just says "negative error code on > > failure" at the moment. > > Alternatively I could expose the 'reduce' path (maybe with another name > e.g. stage2_find_compatible_range() or so) and remove the > kvm_pgtable_stage2_idmap_greedy() wrapper. So it'd be the caller's > responsibility to not release the lock in between > stage2_find_compatible_range() and kvm_pgtable_stage2_map() for > instance, but that sounds reasonable to me. And that would make it > explicit it's the _map() path that failed with -ENOMEM, and that the > range can be re-used the second time. > > Thoughts? I suppose it depends on whether or not you reckon this could be optimised into a single-pass of the page-table. If not, then splitting it up makes sense to me (and actually, it's not like this has tonnes of callers so even if we changed things in future it wouldn't be too hard to fix them up). Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel