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 2FA97C433F5 for ; Wed, 20 Apr 2022 18:50:35 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id A87F24B1B6; Wed, 20 Apr 2022 14:50:34 -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=@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 ayMNGO40vsQV; Wed, 20 Apr 2022 14:50:33 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 6A0394B164; Wed, 20 Apr 2022 14:50:33 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 0263C4B15E for ; Wed, 20 Apr 2022 14:50:33 -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 l5dol3W3z2hF for ; Wed, 20 Apr 2022 14:50:31 -0400 (EDT) Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id A2AFF4B15C for ; Wed, 20 Apr 2022 14:50:31 -0400 (EDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id E5FDB60FCA; Wed, 20 Apr 2022 18:50:30 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B08FDC385A0; Wed, 20 Apr 2022 18:50:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1650480630; bh=TtpYHAojBKeFkFtzR8GvyFddahkz6NTMC2Tu1YaWfEc=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=KXNNu8UMbtulTxejPpUKkAbRITmuRqN5XhQAMhPdb4UZvhS3Q6ohduM35eWAf6DaG 6m3esYRyAT2ZvvWyOGSverrpS7o5XSscZgK914A348XuJHwxEIb2d6t1rRHc+23fKx nLWP+8kSDqH/C/WYjaljQBtfPGp7S/VsQlrtXoe2FFUfE4pSp12NrVNzlC+yC/eAEF 7yEBLDTnFMpgjI2r4AVm+htUubzXRUGtNjC4X+ljhAZdSblVukmanvG0XXyWduWO8k gVWgYgYlREVbK1WFHApeoJhSwA0axqaW2yBtDrVQEIjzX7UIQpXlGpsJN6DRt4ffj5 d+qhujr3KSC0Q== Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nhFPI-005hdC-7b; Wed, 20 Apr 2022 19:50:28 +0100 Date: Wed, 20 Apr 2022 19:50:27 +0100 Message-ID: <87ilr3a8ss.wl-maz@kernel.org> From: Marc Zyngier To: Catalin Marinas Subject: Re: [PATCH v2 00/10] arm64: Add initial support for FEAT_WFxT In-Reply-To: References: <20220419182755.601427-1-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: catalin.marinas@arm.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, will@kernel.org, mark.rutland@arm.com, james.morse@arm.com, suzuki.poulose@arm.com, alexandru.elisei@arm.com, joey.gouly@arm.com, kernel-team@android.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Cc: kernel-team@android.com, kvm@vger.kernel.org, Joey Gouly , Will Deacon , 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 Wed, 20 Apr 2022 18:24:31 +0100, Catalin Marinas wrote: > > On Tue, Apr 19, 2022 at 07:27:45PM +0100, Marc Zyngier wrote: > > A potential addition to this series would be to remove the event > > generation from the counters, and rely on the timeout where it > > matters (spinlocks?). Feedback welcome. > > I think we still need to keep the event generation around, at least for > hardware bugs we don't know about. I don't think user-space rely on it > though, people tend to come up with weird delays like isb ;). But yes, > the WFET should be handy when it turns up in hardware. My hope was that the trick of using the event generation to work around systems failing to broadcast events could become a thing of the past when WFET is present in the HW. After all, they serve the same purpose (generate a local event to un-wedge the CPU). But the more I look at it, the more I hate the potential solution. One of the issues is that WFxT takes an absolute deadline, rather than a relative one. So you end up with things like: ISB MRS x0, CNTVCT_EL0 ADD x0, x0, #some_small_value WFET x0 which is really heavy handed for the slow path of an atomic operation. Even if you have ECV and CNTVCTSS_EL0 (which allows you to get rid of the ISB), it is a royal pain. It would be much better if there was a *relative* version of WFET that would directly take a timeout relative to the current virtual count, but I can sense HW designers calling me names already, so I'll shut up. M. -- Without deviation from the norm, progress is not possible. _______________________________________________ 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 7E4B8C433EF for ; Wed, 20 Apr 2022 18:51:48 +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:MIME-Version:References:In-Reply-To: Subject:Cc:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=QwF16/XTVBHDXiKeoFb1C2VbJAykW7hL4sHX1t++pR0=; b=nMBeH4htVMrjIl 7KDClHHiWWIOMlnYU4b2It8n+Gl7ghXhwSA0fSwuvwC1WtghHSl/nVBEtwy0perZ9dfktW7qNBFvO fBbqGJAOkWagy7+QGBWF+GrO9xh1o2LSffthyKgGiBVfFeROb1txdIz1QhaSGiV3BUcEVjq2KTgt9 0mRnQvLKqhuBmwVt/LouxZSgp8IAF5uEclm9bibjiCFMp2DNXZX4rrqKIeCuhOxnJvoIJ/h+CJZBd lRUOegbIGd5XsFog5H0LNJ29FDoP694r7BMuNk+ilS/Em8sWW/8nPznSjmW+yOxOmsSwmBybE8Tn+ UsImgmETQurZbF+bRxzA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nhFPO-00A79j-Er; Wed, 20 Apr 2022 18:50:34 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nhFPL-00A78j-Ee for linux-arm-kernel@lists.infradead.org; Wed, 20 Apr 2022 18:50:32 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id E5FDB60FCA; Wed, 20 Apr 2022 18:50:30 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B08FDC385A0; Wed, 20 Apr 2022 18:50:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1650480630; bh=TtpYHAojBKeFkFtzR8GvyFddahkz6NTMC2Tu1YaWfEc=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=KXNNu8UMbtulTxejPpUKkAbRITmuRqN5XhQAMhPdb4UZvhS3Q6ohduM35eWAf6DaG 6m3esYRyAT2ZvvWyOGSverrpS7o5XSscZgK914A348XuJHwxEIb2d6t1rRHc+23fKx nLWP+8kSDqH/C/WYjaljQBtfPGp7S/VsQlrtXoe2FFUfE4pSp12NrVNzlC+yC/eAEF 7yEBLDTnFMpgjI2r4AVm+htUubzXRUGtNjC4X+ljhAZdSblVukmanvG0XXyWduWO8k gVWgYgYlREVbK1WFHApeoJhSwA0axqaW2yBtDrVQEIjzX7UIQpXlGpsJN6DRt4ffj5 d+qhujr3KSC0Q== Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nhFPI-005hdC-7b; Wed, 20 Apr 2022 19:50:28 +0100 Date: Wed, 20 Apr 2022 19:50:27 +0100 Message-ID: <87ilr3a8ss.wl-maz@kernel.org> From: Marc Zyngier To: Catalin Marinas Cc: linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, Will Deacon , Mark Rutland , James Morse , Suzuki K Poulose , Alexandru Elisei , Joey Gouly , kernel-team@android.com Subject: Re: [PATCH v2 00/10] arm64: Add initial support for FEAT_WFxT In-Reply-To: References: <20220419182755.601427-1-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: catalin.marinas@arm.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, will@kernel.org, mark.rutland@arm.com, james.morse@arm.com, suzuki.poulose@arm.com, alexandru.elisei@arm.com, joey.gouly@arm.com, kernel-team@android.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220420_115031_599657_EFD85E53 X-CRM114-Status: GOOD ( 23.66 ) 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 Wed, 20 Apr 2022 18:24:31 +0100, Catalin Marinas wrote: > > On Tue, Apr 19, 2022 at 07:27:45PM +0100, Marc Zyngier wrote: > > A potential addition to this series would be to remove the event > > generation from the counters, and rely on the timeout where it > > matters (spinlocks?). Feedback welcome. > > I think we still need to keep the event generation around, at least for > hardware bugs we don't know about. I don't think user-space rely on it > though, people tend to come up with weird delays like isb ;). But yes, > the WFET should be handy when it turns up in hardware. My hope was that the trick of using the event generation to work around systems failing to broadcast events could become a thing of the past when WFET is present in the HW. After all, they serve the same purpose (generate a local event to un-wedge the CPU). But the more I look at it, the more I hate the potential solution. One of the issues is that WFxT takes an absolute deadline, rather than a relative one. So you end up with things like: ISB MRS x0, CNTVCT_EL0 ADD x0, x0, #some_small_value WFET x0 which is really heavy handed for the slow path of an atomic operation. Even if you have ECV and CNTVCTSS_EL0 (which allows you to get rid of the ISB), it is a royal pain. It would be much better if there was a *relative* version of WFET that would directly take a timeout relative to the current virtual count, but I can sense HW designers calling me names already, so I'll shut up. M. -- Without deviation from the norm, progress is not possible. _______________________________________________ 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 1D252C433EF for ; Wed, 20 Apr 2022 18:50:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358721AbiDTSxV (ORCPT ); Wed, 20 Apr 2022 14:53:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37960 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244792AbiDTSxU (ORCPT ); Wed, 20 Apr 2022 14:53:20 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8698B43AC4 for ; Wed, 20 Apr 2022 11:50:33 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 33B1DB82148 for ; Wed, 20 Apr 2022 18:50:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B08FDC385A0; Wed, 20 Apr 2022 18:50:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1650480630; bh=TtpYHAojBKeFkFtzR8GvyFddahkz6NTMC2Tu1YaWfEc=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=KXNNu8UMbtulTxejPpUKkAbRITmuRqN5XhQAMhPdb4UZvhS3Q6ohduM35eWAf6DaG 6m3esYRyAT2ZvvWyOGSverrpS7o5XSscZgK914A348XuJHwxEIb2d6t1rRHc+23fKx nLWP+8kSDqH/C/WYjaljQBtfPGp7S/VsQlrtXoe2FFUfE4pSp12NrVNzlC+yC/eAEF 7yEBLDTnFMpgjI2r4AVm+htUubzXRUGtNjC4X+ljhAZdSblVukmanvG0XXyWduWO8k gVWgYgYlREVbK1WFHApeoJhSwA0axqaW2yBtDrVQEIjzX7UIQpXlGpsJN6DRt4ffj5 d+qhujr3KSC0Q== Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nhFPI-005hdC-7b; Wed, 20 Apr 2022 19:50:28 +0100 Date: Wed, 20 Apr 2022 19:50:27 +0100 Message-ID: <87ilr3a8ss.wl-maz@kernel.org> From: Marc Zyngier To: Catalin Marinas Cc: linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, Will Deacon , Mark Rutland , James Morse , Suzuki K Poulose , Alexandru Elisei , Joey Gouly , kernel-team@android.com Subject: Re: [PATCH v2 00/10] arm64: Add initial support for FEAT_WFxT In-Reply-To: References: <20220419182755.601427-1-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: catalin.marinas@arm.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, will@kernel.org, mark.rutland@arm.com, james.morse@arm.com, suzuki.poulose@arm.com, alexandru.elisei@arm.com, joey.gouly@arm.com, kernel-team@android.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Wed, 20 Apr 2022 18:24:31 +0100, Catalin Marinas wrote: > > On Tue, Apr 19, 2022 at 07:27:45PM +0100, Marc Zyngier wrote: > > A potential addition to this series would be to remove the event > > generation from the counters, and rely on the timeout where it > > matters (spinlocks?). Feedback welcome. > > I think we still need to keep the event generation around, at least for > hardware bugs we don't know about. I don't think user-space rely on it > though, people tend to come up with weird delays like isb ;). But yes, > the WFET should be handy when it turns up in hardware. My hope was that the trick of using the event generation to work around systems failing to broadcast events could become a thing of the past when WFET is present in the HW. After all, they serve the same purpose (generate a local event to un-wedge the CPU). But the more I look at it, the more I hate the potential solution. One of the issues is that WFxT takes an absolute deadline, rather than a relative one. So you end up with things like: ISB MRS x0, CNTVCT_EL0 ADD x0, x0, #some_small_value WFET x0 which is really heavy handed for the slow path of an atomic operation. Even if you have ECV and CNTVCTSS_EL0 (which allows you to get rid of the ISB), it is a royal pain. It would be much better if there was a *relative* version of WFET that would directly take a timeout relative to the current virtual count, but I can sense HW designers calling me names already, so I'll shut up. M. -- Without deviation from the norm, progress is not possible.