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.5 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 94EE1C433DB for ; Fri, 5 Mar 2021 16:59:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3EC9265081 for ; Fri, 5 Mar 2021 16:59:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231127AbhCEQ7R (ORCPT ); Fri, 5 Mar 2021 11:59:17 -0500 Received: from mail.kernel.org ([198.145.29.99]:44102 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230387AbhCEQ7L (ORCPT ); Fri, 5 Mar 2021 11:59:11 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 5B31D64F1E; Fri, 5 Mar 2021 16:59:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1614963551; bh=Anr2szlxokrML4bcZ0Hk4njlruTj6i3bBKAsz8Ik/i8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ZUPrT4WrxDvcA5waC/JCToBDhp1Kk6d3fuhFTFtApJbxl0DgugRoL98HlHKCN+L7k tDU5jCwdV+7H8hoi0mdwLKsCb6Sb6+QgoyLpevCgAngM79HAAGqMdDWgx6G4KN1p0z 3jQAWjeCtBm8z+uq76vuvHzUu3XyyM/ucb1oWgdgFZeql/ibvBWxASXsCw5Ya/5Bj9 66KUukox4oZMKGGxtCD3+ISsnUhlVKb4PZPuMde71ut26Ojz2C/0qfpL0Lex4NeBt9 /cwZFHGTuCvZyl0jAguHl1gtlz88pIRcTXtKzXA0H3PgovHmIkSq6dLJSpA1aSfQur Wkmsn/I2oG+ZQ== Date: Fri, 5 Mar 2021 16:59:05 +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 28/32] KVM: arm64: Add kvm_pgtable_stage2_idmap_greedy() Message-ID: <20210305165904.GA23172@willie-the-truck> References: <20210302150002.3685113-1-qperret@google.com> <20210302150002.3685113-29-qperret@google.com> <20210305143941.GA23017@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 Fri, Mar 05, 2021 at 03:03:36PM +0000, Quentin Perret wrote: > On Friday 05 Mar 2021 at 14:39:42 (+0000), Will Deacon wrote: > > On Tue, Mar 02, 2021 at 02:59:58PM +0000, Quentin Perret wrote: > > > + /* Reduce the kvm_mem_range to a granule size */ > > > + ret = __stage2_reduce_range(&data, range->end); > > > + if (ret) > > > + return ret; > > > + > > > + /* Walk the range to check permissions and reduce further if needed */ > > > + do { > > > + ret = kvm_pgtable_walk(pgt, range->start, range->end, &walker); > > > > (we spent some time debugging an issue here and you spotted that you're > > passing range->end instead of the size ;) > > Yep, I have the fix applied locally, and ready to fly in v4 :) > > > > + } while (ret == -EAGAIN); > > > > I'm a bit nervous about this loop -- what guarantees forward progress here? > > Can we return to the host after a few tries instead? > > -EAGAIN only happens when we've been able to successfully reduce the > range to a potentially valid granule size. That can't happen infinitely. > > We're guaranteed to fail when trying to reduce the range to a > granularity smaller than PAGE_SIZE (the -EINVAL case of > __stage2_reduce_range), which is indicative of a host memory abort in a > page it should not access (because marked PROT_NONE for instance). Can you compute an upper bound on the number of iterations based on the number of page-table levels then? I'm just conscious that all of this is effectively running with irqs disabled, and so being able to reason about the amount of work we're going to do makes me much more comfortable. 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,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 80AEFC433DB for ; Fri, 5 Mar 2021 16:59:18 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id DC20C65081 for ; Fri, 5 Mar 2021 16:59:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DC20C65081 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 3BB7A4B532; Fri, 5 Mar 2021 11:59:17 -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 j-I2jAFWUxCR; Fri, 5 Mar 2021 11:59:14 -0500 (EST) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id B8C704B4F0; Fri, 5 Mar 2021 11:59:14 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 175A24B4EF for ; Fri, 5 Mar 2021 11:59:13 -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 AIsBPdCaIcDV for ; Fri, 5 Mar 2021 11:59:12 -0500 (EST) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 25D134B328 for ; Fri, 5 Mar 2021 11:59:12 -0500 (EST) Received: by mail.kernel.org (Postfix) with ESMTPSA id 5B31D64F1E; Fri, 5 Mar 2021 16:59:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1614963551; bh=Anr2szlxokrML4bcZ0Hk4njlruTj6i3bBKAsz8Ik/i8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ZUPrT4WrxDvcA5waC/JCToBDhp1Kk6d3fuhFTFtApJbxl0DgugRoL98HlHKCN+L7k tDU5jCwdV+7H8hoi0mdwLKsCb6Sb6+QgoyLpevCgAngM79HAAGqMdDWgx6G4KN1p0z 3jQAWjeCtBm8z+uq76vuvHzUu3XyyM/ucb1oWgdgFZeql/ibvBWxASXsCw5Ya/5Bj9 66KUukox4oZMKGGxtCD3+ISsnUhlVKb4PZPuMde71ut26Ojz2C/0qfpL0Lex4NeBt9 /cwZFHGTuCvZyl0jAguHl1gtlz88pIRcTXtKzXA0H3PgovHmIkSq6dLJSpA1aSfQur Wkmsn/I2oG+ZQ== Date: Fri, 5 Mar 2021 16:59:05 +0000 From: Will Deacon To: Quentin Perret Subject: Re: [PATCH v3 28/32] KVM: arm64: Add kvm_pgtable_stage2_idmap_greedy() Message-ID: <20210305165904.GA23172@willie-the-truck> References: <20210302150002.3685113-1-qperret@google.com> <20210302150002.3685113-29-qperret@google.com> <20210305143941.GA23017@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 Fri, Mar 05, 2021 at 03:03:36PM +0000, Quentin Perret wrote: > On Friday 05 Mar 2021 at 14:39:42 (+0000), Will Deacon wrote: > > On Tue, Mar 02, 2021 at 02:59:58PM +0000, Quentin Perret wrote: > > > + /* Reduce the kvm_mem_range to a granule size */ > > > + ret = __stage2_reduce_range(&data, range->end); > > > + if (ret) > > > + return ret; > > > + > > > + /* Walk the range to check permissions and reduce further if needed */ > > > + do { > > > + ret = kvm_pgtable_walk(pgt, range->start, range->end, &walker); > > > > (we spent some time debugging an issue here and you spotted that you're > > passing range->end instead of the size ;) > > Yep, I have the fix applied locally, and ready to fly in v4 :) > > > > + } while (ret == -EAGAIN); > > > > I'm a bit nervous about this loop -- what guarantees forward progress here? > > Can we return to the host after a few tries instead? > > -EAGAIN only happens when we've been able to successfully reduce the > range to a potentially valid granule size. That can't happen infinitely. > > We're guaranteed to fail when trying to reduce the range to a > granularity smaller than PAGE_SIZE (the -EINVAL case of > __stage2_reduce_range), which is indicative of a host memory abort in a > page it should not access (because marked PROT_NONE for instance). Can you compute an upper bound on the number of iterations based on the number of page-table levels then? I'm just conscious that all of this is effectively running with irqs disabled, and so being able to reason about the amount of work we're going to do makes me much more comfortable. 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.5 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 01095C433E0 for ; Fri, 5 Mar 2021 17:00:54 +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 7BE4564F1E for ; Fri, 5 Mar 2021 17:00:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7BE4564F1E 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=mxnk4HniONaYWajusSFZ3jw192W9jfqX1It2Ppf4iTw=; b=fs6EwZU0/Ihb0A/eoIl0QTEor sZpfOrdxqm8FtNbNrnlnYWU1ydWW3S+sg4lw9fLH4OeAHoqjk3y7apASPXqF/MchozxFBGQpIEUB6 7wcsBrSG27Kj5tivEen0YdD2A9cZqcjbz9jD55AV/sJ7+3YJQlcExQRLibVRE4Gypj753NzvJs7lE ROONoU2Xb9LarZZImImK8INpJKlFZrk3ozozrb3CE1GgwwvPgsaN08m0gjyEQS59q5CfItjqQa0Ke cPeP5rvlc7UZ8ANlbtmR78zjcipSNc60RR2Q48qYBIeTtrMV9Tn0ERYf8E0K7s6dNoo3v7lywLEIT 2ufCGr8Yg==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lIDnJ-00Fhh7-5s; Fri, 05 Mar 2021 16:59:17 +0000 Received: from mail.kernel.org ([198.145.29.99]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lIDnE-00FhgL-Pf for linux-arm-kernel@lists.infradead.org; Fri, 05 Mar 2021 16:59:15 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id 5B31D64F1E; Fri, 5 Mar 2021 16:59:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1614963551; bh=Anr2szlxokrML4bcZ0Hk4njlruTj6i3bBKAsz8Ik/i8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ZUPrT4WrxDvcA5waC/JCToBDhp1Kk6d3fuhFTFtApJbxl0DgugRoL98HlHKCN+L7k tDU5jCwdV+7H8hoi0mdwLKsCb6Sb6+QgoyLpevCgAngM79HAAGqMdDWgx6G4KN1p0z 3jQAWjeCtBm8z+uq76vuvHzUu3XyyM/ucb1oWgdgFZeql/ibvBWxASXsCw5Ya/5Bj9 66KUukox4oZMKGGxtCD3+ISsnUhlVKb4PZPuMde71ut26Ojz2C/0qfpL0Lex4NeBt9 /cwZFHGTuCvZyl0jAguHl1gtlz88pIRcTXtKzXA0H3PgovHmIkSq6dLJSpA1aSfQur Wkmsn/I2oG+ZQ== Date: Fri, 5 Mar 2021 16:59:05 +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 28/32] KVM: arm64: Add kvm_pgtable_stage2_idmap_greedy() Message-ID: <20210305165904.GA23172@willie-the-truck> References: <20210302150002.3685113-1-qperret@google.com> <20210302150002.3685113-29-qperret@google.com> <20210305143941.GA23017@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-20210305_165913_955095_78BB13E1 X-CRM114-Status: GOOD ( 20.46 ) 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 Fri, Mar 05, 2021 at 03:03:36PM +0000, Quentin Perret wrote: > On Friday 05 Mar 2021 at 14:39:42 (+0000), Will Deacon wrote: > > On Tue, Mar 02, 2021 at 02:59:58PM +0000, Quentin Perret wrote: > > > + /* Reduce the kvm_mem_range to a granule size */ > > > + ret = __stage2_reduce_range(&data, range->end); > > > + if (ret) > > > + return ret; > > > + > > > + /* Walk the range to check permissions and reduce further if needed */ > > > + do { > > > + ret = kvm_pgtable_walk(pgt, range->start, range->end, &walker); > > > > (we spent some time debugging an issue here and you spotted that you're > > passing range->end instead of the size ;) > > Yep, I have the fix applied locally, and ready to fly in v4 :) > > > > + } while (ret == -EAGAIN); > > > > I'm a bit nervous about this loop -- what guarantees forward progress here? > > Can we return to the host after a few tries instead? > > -EAGAIN only happens when we've been able to successfully reduce the > range to a potentially valid granule size. That can't happen infinitely. > > We're guaranteed to fail when trying to reduce the range to a > granularity smaller than PAGE_SIZE (the -EINVAL case of > __stage2_reduce_range), which is indicative of a host memory abort in a > page it should not access (because marked PROT_NONE for instance). Can you compute an upper bound on the number of iterations based on the number of page-table levels then? I'm just conscious that all of this is effectively running with irqs disabled, and so being able to reason about the amount of work we're going to do makes me much more comfortable. Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel