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 Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by smtp.lore.kernel.org (Postfix) with ESMTP id 33785C433EF for ; Wed, 20 Apr 2022 16:55:50 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 7F66049EEE; Wed, 20 Apr 2022 12:55:50 -0400 (EDT) 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=@google.com 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 SiImbzMHTp0T; Wed, 20 Apr 2022 12:55:49 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 6286049E3F; Wed, 20 Apr 2022 12:55:49 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id A5D2449E16 for ; Wed, 20 Apr 2022 12:55:48 -0400 (EDT) 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 M2FmG7GS-xh1 for ; Wed, 20 Apr 2022 12:55:47 -0400 (EDT) Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com [209.85.208.41]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 96E5E49B07 for ; Wed, 20 Apr 2022 12:55:47 -0400 (EDT) Received: by mail-ed1-f41.google.com with SMTP id c6so3098071edn.8 for ; Wed, 20 Apr 2022 09:55:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=vUTv+50MNanSPxQdcGK+5r6sVmuK08fgNGG0Mf/jqBI=; b=iaqM1FoiEMcdthoIscB4EGxWnfhv/7xjyGKn4gIYpZHRrZPFYv2bhDYEqwxTUUPq3f MBxFAQIxeQGYEDY3oK29YT38KSDuW3cHq8JkOpdd4sAuedKILI1Ug1iJ1a1kl9I8P6mD Y5dRhiHuMdLNpXQOZFC1pxLJVGLOjllNv/t/zpRTHgqsu+YKyZnrtZesTx4Lnhup2nbU 5VNDjtGqnI7R/JkhaEOkFnXoIkSP9OXMsnNzUJQ3KKLbePthP8+NBRw3HM3upPsJn1aI Fc7SnEGGItiNTvVn+7JEsg1baMxX5uzfKSee2UM61YtwsD/ll2+J5Jk1RFF1JsnIsliO ruYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=vUTv+50MNanSPxQdcGK+5r6sVmuK08fgNGG0Mf/jqBI=; b=uthdXX0l070Lc22Raabg/qwUTRBlYflBat9eyoSffhqq6wOOYLHdGuY8lm0ElFL1rA 02jMowxarOvXSVq+iqKE1+4al6QylplUXmmfvzOvGOz6Kkx6+/b83vuy4bCeKmt9iUc0 7oBmVqsNc7Lh7r5BChklNOwXpbs0W7Tf1dFLPJvC5KREG30anDEKcCpy2dYj2ZW7YxJ+ pkwbL0PvONH0Ecme8Aa8snWj+s6pmWLtu07uV0HCdoHIN4cA77dgJNmv0wWN/uheLoBR 8eW3OOJtI/eovNMkLgAUhkKPj2VmSnAfySts0bFJgE68tAIE4AQXnEv0m32x1Rqj/m9h 0oxA== X-Gm-Message-State: AOAM531Hg80ygrqW0RQEn1iyfIhg1TpGKH0C0YKirMPGVxtAATRApMhW FvmzNzYcoSY//yfCJLXJBs9oRA== X-Google-Smtp-Source: ABdhPJwZN16RiJ3cGzzLbJpClyclGhaHPFmT1JB/AMEONy3NRQjyx8rtnJoF85sLehdmloUKBwbWAw== X-Received: by 2002:a05:6402:2711:b0:423:ef0d:aa86 with SMTP id y17-20020a056402271100b00423ef0daa86mr15314652edd.262.1650473746365; Wed, 20 Apr 2022 09:55:46 -0700 (PDT) Received: from google.com (30.171.91.34.bc.googleusercontent.com. [34.91.171.30]) by smtp.gmail.com with ESMTPSA id s20-20020a056402015400b00418f9574a36sm10182331edu.73.2022.04.20.09.55.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 Apr 2022 09:55:46 -0700 (PDT) Date: Wed, 20 Apr 2022 16:55:43 +0000 From: Quentin Perret To: Oliver Upton Subject: Re: [RFC PATCH 06/17] KVM: arm64: Implement break-before-make sequence for parallel walks Message-ID: References: <20220415215901.1737897-1-oupton@google.com> <20220415215901.1737897-7-oupton@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20220415215901.1737897-7-oupton@google.com> Cc: kvm@vger.kernel.org, Marc Zyngier , Peter Shier , Ben Gardon , David Matlack , Paolo Bonzini , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org 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 Friday 15 Apr 2022 at 21:58:50 (+0000), Oliver Upton wrote: > +/* > + * Used to indicate a pte for which a 'make-before-break' sequence is in 'break-before-make' presumably :-) ? > +static void stage2_make_pte(kvm_pte_t *ptep, kvm_pte_t new, struct kvm_pgtable_mm_ops *mm_ops) > +{ > + /* Yikes! We really shouldn't install to an entry we don't own. */ > + WARN_ON(!stage2_pte_is_locked(*ptep)); > + > + if (stage2_pte_is_counted(new)) > + mm_ops->get_page(ptep); > + > + if (kvm_pte_valid(new)) { > + WRITE_ONCE(*ptep, new); > + dsb(ishst); > + } else { > + smp_store_release(ptep, new); > + } > +} I'm struggling a bit to understand this pattern. We currently use smp_store_release() to install valid mappings, which this patch seems to change. Is the behaviour change intentional? If so, could you please share some details about the reasoning that applies here? Thanks, Quentin _______________________________________________ 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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 8BF66C433F5 for ; Wed, 20 Apr 2022 16:57:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; 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=NSfcjlVq2lVXb983RmWiJSN9Jvf7KmeiPaDk2jsIqfI=; b=k6OgzrRUXN+b18 8E5qGUZPtgTUilW3IK2ccJbmwsoBJSQeOo1rJo+ko9b4pjdhRn5wLlD7vxSp+LZ/1ixu/Z9QfWXw5 6SXyPpGOIjzVYxSD7nbWCBIGX6z6FYq/uJHyt9h/GaR6b36/mX9HseWqrtVpUI4lmiAcDXIFVpKQF gZiEIs/RKYb1qFWVaK5bEaVsyeqrZNDkzVR+cjlMqG+GScb6v2Ra0grij9Mi/7DkZVeV8F1TtjDDh kLW70UdfidjOWPasXXRKznRfGJqfjUTbeuME2pQg0MH9fdAtGThoUneQNC/GEgjCf1+ZOo0ekMERZ lVqgLX27ngKf+bK49y2w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nhDcU-009mpr-7d; Wed, 20 Apr 2022 16:55:59 +0000 Received: from mail-ed1-x529.google.com ([2a00:1450:4864:20::529]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nhDcP-009mlE-Iz for linux-arm-kernel@lists.infradead.org; Wed, 20 Apr 2022 16:55:55 +0000 Received: by mail-ed1-x529.google.com with SMTP id b24so3085438edu.10 for ; Wed, 20 Apr 2022 09:55:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=vUTv+50MNanSPxQdcGK+5r6sVmuK08fgNGG0Mf/jqBI=; b=iaqM1FoiEMcdthoIscB4EGxWnfhv/7xjyGKn4gIYpZHRrZPFYv2bhDYEqwxTUUPq3f MBxFAQIxeQGYEDY3oK29YT38KSDuW3cHq8JkOpdd4sAuedKILI1Ug1iJ1a1kl9I8P6mD Y5dRhiHuMdLNpXQOZFC1pxLJVGLOjllNv/t/zpRTHgqsu+YKyZnrtZesTx4Lnhup2nbU 5VNDjtGqnI7R/JkhaEOkFnXoIkSP9OXMsnNzUJQ3KKLbePthP8+NBRw3HM3upPsJn1aI Fc7SnEGGItiNTvVn+7JEsg1baMxX5uzfKSee2UM61YtwsD/ll2+J5Jk1RFF1JsnIsliO ruYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=vUTv+50MNanSPxQdcGK+5r6sVmuK08fgNGG0Mf/jqBI=; b=yOcf4ahZjUoYrfbViScpGY49BscluH3Kirdw1qdhwzxGVd0UpEFhAuyA8d4jbVc67e xC3NX/4olHf2umkWp8OqTzID5eyzpgSDNfot53hdqjsdyasSYIDo44l9DOv1aGnmBXyg CWjqeZT6YylKaifv94nH/cZnmvzipS2Ytdq+UVnq+TIVad95uY+DN8zn7BlmelIKZ4x6 eKYDb6VLBNNUe+FTW1Z/bbp92PdDl9GtMpMLmNgV55wYimTzwh5X4vnP4lEZOgpxcJYp G8xrCEDQ3/WWqpTDQMKyuXn1ZdTJtKM8ydN5kUPALNazI5zBFNUOQui/J8745jySRi7f EX8w== X-Gm-Message-State: AOAM533AMEOFhybopPO8vky4gbmbW3DnDler62imKrfZNWz3lelsrvdg 5jeMmVYHedvbjy/2aSt/7b5ILQ== X-Google-Smtp-Source: ABdhPJwZN16RiJ3cGzzLbJpClyclGhaHPFmT1JB/AMEONy3NRQjyx8rtnJoF85sLehdmloUKBwbWAw== X-Received: by 2002:a05:6402:2711:b0:423:ef0d:aa86 with SMTP id y17-20020a056402271100b00423ef0daa86mr15314652edd.262.1650473746365; Wed, 20 Apr 2022 09:55:46 -0700 (PDT) Received: from google.com (30.171.91.34.bc.googleusercontent.com. [34.91.171.30]) by smtp.gmail.com with ESMTPSA id s20-20020a056402015400b00418f9574a36sm10182331edu.73.2022.04.20.09.55.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 Apr 2022 09:55:46 -0700 (PDT) Date: Wed, 20 Apr 2022 16:55:43 +0000 From: Quentin Perret To: Oliver Upton Cc: kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, Marc Zyngier , Ben Gardon , Peter Shier , David Matlack , Paolo Bonzini , linux-arm-kernel@lists.infradead.org Subject: Re: [RFC PATCH 06/17] KVM: arm64: Implement break-before-make sequence for parallel walks Message-ID: References: <20220415215901.1737897-1-oupton@google.com> <20220415215901.1737897-7-oupton@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20220415215901.1737897-7-oupton@google.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220420_095553_667895_C64653C4 X-CRM114-Status: GOOD ( 13.57 ) 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 Friday 15 Apr 2022 at 21:58:50 (+0000), Oliver Upton wrote: > +/* > + * Used to indicate a pte for which a 'make-before-break' sequence is in 'break-before-make' presumably :-) ? > +static void stage2_make_pte(kvm_pte_t *ptep, kvm_pte_t new, struct kvm_pgtable_mm_ops *mm_ops) > +{ > + /* Yikes! We really shouldn't install to an entry we don't own. */ > + WARN_ON(!stage2_pte_is_locked(*ptep)); > + > + if (stage2_pte_is_counted(new)) > + mm_ops->get_page(ptep); > + > + if (kvm_pte_valid(new)) { > + WRITE_ONCE(*ptep, new); > + dsb(ishst); > + } else { > + smp_store_release(ptep, new); > + } > +} I'm struggling a bit to understand this pattern. We currently use smp_store_release() to install valid mappings, which this patch seems to change. Is the behaviour change intentional? If so, could you please share some details about the reasoning that applies here? Thanks, Quentin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1A079C433FE for ; Wed, 20 Apr 2022 16:55:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1380805AbiDTQ6g (ORCPT ); Wed, 20 Apr 2022 12:58:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48448 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1359073AbiDTQ6e (ORCPT ); Wed, 20 Apr 2022 12:58:34 -0400 Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 077691C924 for ; Wed, 20 Apr 2022 09:55:48 -0700 (PDT) Received: by mail-ed1-x52c.google.com with SMTP id c64so3074296edf.11 for ; Wed, 20 Apr 2022 09:55:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=vUTv+50MNanSPxQdcGK+5r6sVmuK08fgNGG0Mf/jqBI=; b=iaqM1FoiEMcdthoIscB4EGxWnfhv/7xjyGKn4gIYpZHRrZPFYv2bhDYEqwxTUUPq3f MBxFAQIxeQGYEDY3oK29YT38KSDuW3cHq8JkOpdd4sAuedKILI1Ug1iJ1a1kl9I8P6mD Y5dRhiHuMdLNpXQOZFC1pxLJVGLOjllNv/t/zpRTHgqsu+YKyZnrtZesTx4Lnhup2nbU 5VNDjtGqnI7R/JkhaEOkFnXoIkSP9OXMsnNzUJQ3KKLbePthP8+NBRw3HM3upPsJn1aI Fc7SnEGGItiNTvVn+7JEsg1baMxX5uzfKSee2UM61YtwsD/ll2+J5Jk1RFF1JsnIsliO ruYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=vUTv+50MNanSPxQdcGK+5r6sVmuK08fgNGG0Mf/jqBI=; b=4JqtGa5IPwzORPClApbtX4St7H59HO1QI6XsznyguZkkcxCut5J/tH9PCZGM2L/SSv 7jRs3NfnH73ae7E/qKj1qplvqDnREBx9NxWtKG2lEN7NGNPNkDm64ME+nFDJyJG6lth8 7ID+3ulw71xE89poZGnKBIPWdC2lt+x30f7YmN/VLiKamLyfE9EK5qkKJxTmLHD+dNAj /M9ljqJ0KrdkRhp4DmNPRDXBu973Bs/PwpBj176qAlMmj1E5GbrClnyJ64GPpTkPwfBb a3gtBXrQIbZsKrjJbjIL7bOaFn44kSZfTpvjS51dryACsBaB72Xw0ew9xW4JjAyQ1x/H ITcw== X-Gm-Message-State: AOAM531oyjg/T8FvW3Zxbsy9felk/0n2VE0zWgFGWJer2XpGPlu9MYdq wuE5F2RB1d2DQ0R9+9X4ajL3Dtc/8QWM8Q== X-Google-Smtp-Source: ABdhPJwZN16RiJ3cGzzLbJpClyclGhaHPFmT1JB/AMEONy3NRQjyx8rtnJoF85sLehdmloUKBwbWAw== X-Received: by 2002:a05:6402:2711:b0:423:ef0d:aa86 with SMTP id y17-20020a056402271100b00423ef0daa86mr15314652edd.262.1650473746365; Wed, 20 Apr 2022 09:55:46 -0700 (PDT) Received: from google.com (30.171.91.34.bc.googleusercontent.com. [34.91.171.30]) by smtp.gmail.com with ESMTPSA id s20-20020a056402015400b00418f9574a36sm10182331edu.73.2022.04.20.09.55.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 Apr 2022 09:55:46 -0700 (PDT) Date: Wed, 20 Apr 2022 16:55:43 +0000 From: Quentin Perret To: Oliver Upton Cc: kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, Marc Zyngier , Ben Gardon , Peter Shier , David Matlack , Paolo Bonzini , linux-arm-kernel@lists.infradead.org Subject: Re: [RFC PATCH 06/17] KVM: arm64: Implement break-before-make sequence for parallel walks Message-ID: References: <20220415215901.1737897-1-oupton@google.com> <20220415215901.1737897-7-oupton@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220415215901.1737897-7-oupton@google.com> Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Friday 15 Apr 2022 at 21:58:50 (+0000), Oliver Upton wrote: > +/* > + * Used to indicate a pte for which a 'make-before-break' sequence is in 'break-before-make' presumably :-) ? > +static void stage2_make_pte(kvm_pte_t *ptep, kvm_pte_t new, struct kvm_pgtable_mm_ops *mm_ops) > +{ > + /* Yikes! We really shouldn't install to an entry we don't own. */ > + WARN_ON(!stage2_pte_is_locked(*ptep)); > + > + if (stage2_pte_is_counted(new)) > + mm_ops->get_page(ptep); > + > + if (kvm_pte_valid(new)) { > + WRITE_ONCE(*ptep, new); > + dsb(ishst); > + } else { > + smp_store_release(ptep, new); > + } > +} I'm struggling a bit to understand this pattern. We currently use smp_store_release() to install valid mappings, which this patch seems to change. Is the behaviour change intentional? If so, could you please share some details about the reasoning that applies here? Thanks, Quentin