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=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, 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 A0D01C0650E for ; Wed, 3 Jul 2019 17:35:33 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id 3AF122189E for ; Wed, 3 Jul 2019 17:35:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3AF122189E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com 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 7CB4E4A528; Wed, 3 Jul 2019 13:35:32 -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 vTFZTodf86vp; Wed, 3 Jul 2019 13:35:31 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 302E74A51C; Wed, 3 Jul 2019 13:35:31 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 0F7EF4A4F7 for ; Wed, 3 Jul 2019 13:35:30 -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 paCOW9U94f8Z for ; Wed, 3 Jul 2019 13:35:28 -0400 (EDT) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by mm01.cs.columbia.edu (Postfix) with ESMTP id A56AC4A4F6 for ; Wed, 3 Jul 2019 13:35:28 -0400 (EDT) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 2C437344; Wed, 3 Jul 2019 10:35:28 -0700 (PDT) Received: from [10.1.196.105] (eglon.cambridge.arm.com [10.1.196.105]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A38253F718; Wed, 3 Jul 2019 10:35:25 -0700 (PDT) Subject: Re: [RFC v2 12/14] arm64/lib: asid: Allow user to update the context under the lock To: Julien Grall References: <20190620130608.17230-1-julien.grall@arm.com> <20190620130608.17230-13-julien.grall@arm.com> From: James Morse Message-ID: Date: Wed, 3 Jul 2019 18:35:23 +0100 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <20190620130608.17230-13-julien.grall@arm.com> Content-Language: en-GB Cc: marc.zyngier@arm.com, catalin.marinas@arm.com, will.deacon@arm.com, linux-kernel@vger.kernel.org, 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 Hi Julien, On 20/06/2019 14:06, Julien Grall wrote: > Some users of the ASID allocator (e.g VMID) will require to update the > context when a new ASID is generated. This has to be protected by a lock > to prevent concurrent modification. > > Rather than introducing yet another lock, it is possible to re-use the > allocator lock for that purpose. This patch introduces a new callback > that will be call when updating the context. You're using this later in the series to mask out the generation from the atomic64 to leave just the vmid. Where does this concurrent modification happen? The value is only written if we have a rollover, and while its active the only bits that could change are the generation. (subsequent vCPUs that take the slow path for the same VM will see the updated generation and skip the new_context call) If we did the generation filtering in update_vmid() after the call to asid_check_context(), what would go wrong? It happens more often than is necessary and would need a WRITE_ONCE(), but the vmid can't change until we become preemptible and another vCPU gets a chance to make its vmid active. This thing is horribly subtle, so I'm sure I've missed something here! I can't see where the arch code's equivalent case is. It also filters the generation out of the atomic64 in cpu_do_switch_mm(). This happens with interrupts masked so we can't re-schedule and set another asid as 'active'. KVM's equivalent is !preemptible. Thanks, James _______________________________________________ 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=-2.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,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 2F296C06513 for ; Wed, 3 Jul 2019 17:35:32 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 0AC9921882 for ; Wed, 3 Jul 2019 17:35:32 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="MF/4ul1p" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0AC9921882 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-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=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description :Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=bRoRyMhKHVzADesHgswhpCEAqc6ptntVVB75yGiFemU=; b=MF/4ul1pH7zTTM kYgnhzmpE7eJGx8dlOf2b0RttciX5muKWqzolHgkQJunls8HzBOMhSJiPWQAZEjiSvoVLOduz+S6i +tH+AIQhPNUSrwMZAL8zkOyznhl0solNTdRWrjtIACRHq7aFcs7Rf3a0HYuiqjSoy6lAzIvkUJjiO Fe7Z9JHJ453MKiX6BwTs+QrcxO2hHCozUhrztvRtDVfWxs7j7ZRW8i/ZwPjJTjADzuTo/MN9sOWIX oSIL1iZEztkedGjOvj/0IKl9GNFUnVw4F5z7yhlVDot8w0tNw+ReY7Ae4kdyyzBxA3q860oogxXsm yqndj8h5Y73aGwMpo8rA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1hijAJ-0005Rj-NP; Wed, 03 Jul 2019 17:35:31 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1hijAH-0005RQ-FM for linux-arm-kernel@lists.infradead.org; Wed, 03 Jul 2019 17:35:30 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 2C437344; Wed, 3 Jul 2019 10:35:28 -0700 (PDT) Received: from [10.1.196.105] (eglon.cambridge.arm.com [10.1.196.105]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A38253F718; Wed, 3 Jul 2019 10:35:25 -0700 (PDT) Subject: Re: [RFC v2 12/14] arm64/lib: asid: Allow user to update the context under the lock To: Julien Grall References: <20190620130608.17230-1-julien.grall@arm.com> <20190620130608.17230-13-julien.grall@arm.com> From: James Morse Message-ID: Date: Wed, 3 Jul 2019 18:35:23 +0100 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <20190620130608.17230-13-julien.grall@arm.com> Content-Language: en-GB X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190703_103529_557389_4DFAE2A6 X-CRM114-Status: GOOD ( 14.21 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: julien.thierry@arm.com, marc.zyngier@arm.com, catalin.marinas@arm.com, suzuki.poulose@arm.com, will.deacon@arm.com, linux-kernel@vger.kernel.org, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Julien, On 20/06/2019 14:06, Julien Grall wrote: > Some users of the ASID allocator (e.g VMID) will require to update the > context when a new ASID is generated. This has to be protected by a lock > to prevent concurrent modification. > > Rather than introducing yet another lock, it is possible to re-use the > allocator lock for that purpose. This patch introduces a new callback > that will be call when updating the context. You're using this later in the series to mask out the generation from the atomic64 to leave just the vmid. Where does this concurrent modification happen? The value is only written if we have a rollover, and while its active the only bits that could change are the generation. (subsequent vCPUs that take the slow path for the same VM will see the updated generation and skip the new_context call) If we did the generation filtering in update_vmid() after the call to asid_check_context(), what would go wrong? It happens more often than is necessary and would need a WRITE_ONCE(), but the vmid can't change until we become preemptible and another vCPU gets a chance to make its vmid active. This thing is horribly subtle, so I'm sure I've missed something here! I can't see where the arch code's equivalent case is. It also filters the generation out of the atomic64 in cpu_do_switch_mm(). This happens with interrupts masked so we can't re-schedule and set another asid as 'active'. KVM's equivalent is !preemptible. Thanks, James _______________________________________________ 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 X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, 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 420BDC0650E for ; Wed, 3 Jul 2019 17:35:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 184D321882 for ; Wed, 3 Jul 2019 17:35:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726900AbfGCRf3 (ORCPT ); Wed, 3 Jul 2019 13:35:29 -0400 Received: from foss.arm.com ([217.140.110.172]:53878 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726473AbfGCRf3 (ORCPT ); Wed, 3 Jul 2019 13:35:29 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 2C437344; Wed, 3 Jul 2019 10:35:28 -0700 (PDT) Received: from [10.1.196.105] (eglon.cambridge.arm.com [10.1.196.105]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A38253F718; Wed, 3 Jul 2019 10:35:25 -0700 (PDT) Subject: Re: [RFC v2 12/14] arm64/lib: asid: Allow user to update the context under the lock To: Julien Grall Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, marc.zyngier@arm.com, julien.thierry@arm.com, suzuki.poulose@arm.com, catalin.marinas@arm.com, will.deacon@arm.com References: <20190620130608.17230-1-julien.grall@arm.com> <20190620130608.17230-13-julien.grall@arm.com> From: James Morse Message-ID: Date: Wed, 3 Jul 2019 18:35:23 +0100 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <20190620130608.17230-13-julien.grall@arm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Julien, On 20/06/2019 14:06, Julien Grall wrote: > Some users of the ASID allocator (e.g VMID) will require to update the > context when a new ASID is generated. This has to be protected by a lock > to prevent concurrent modification. > > Rather than introducing yet another lock, it is possible to re-use the > allocator lock for that purpose. This patch introduces a new callback > that will be call when updating the context. You're using this later in the series to mask out the generation from the atomic64 to leave just the vmid. Where does this concurrent modification happen? The value is only written if we have a rollover, and while its active the only bits that could change are the generation. (subsequent vCPUs that take the slow path for the same VM will see the updated generation and skip the new_context call) If we did the generation filtering in update_vmid() after the call to asid_check_context(), what would go wrong? It happens more often than is necessary and would need a WRITE_ONCE(), but the vmid can't change until we become preemptible and another vCPU gets a chance to make its vmid active. This thing is horribly subtle, so I'm sure I've missed something here! I can't see where the arch code's equivalent case is. It also filters the generation out of the atomic64 in cpu_do_switch_mm(). This happens with interrupts masked so we can't re-schedule and set another asid as 'active'. KVM's equivalent is !preemptible. Thanks, James