From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3E22CDDC1; Wed, 10 Apr 2024 07:27:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712734033; cv=none; b=L9d6LMaBAt1wWIJxnQlEJSdFmFS45CNigLzPvUCPMKbLBuIjB+8LeHJZvn5n2pmo2FXPXxoHzAWPa2rbU5UI0VTlZBi32Q4oVqhYi9+TpHGOBZZdeZS4zUbBKpAkUPwRFz8kzIcYUFy93lwU4Z6Pa6hfG+pvI2FrQqDbLdBGYEQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712734033; c=relaxed/simple; bh=Nlv4greCsNCXD6xVDNfDR2Ichl1UewO2fmoorEV3bHM=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=Sobu7SdHn5Hre/AzqtJ8D5R3hPFtyIDLhTOIb6Wir8DltcoTOATRDqVZD+Jtpbw4Onr/Oryp50I4TJslOnS5SExP/+BLPfMMWebD35gCfWy76eAqcSXQFqCyNlyMCcjsW2pbdHQkJFVAFYHiOfsxCCDDp0DtxfmqiqdPvuhm2dQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=U6opM9M0; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="U6opM9M0" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C2CE3C433C7; Wed, 10 Apr 2024 07:27:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1712734032; bh=Nlv4greCsNCXD6xVDNfDR2Ichl1UewO2fmoorEV3bHM=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=U6opM9M0oVk3Jcvjud9swIeKHMJODpauPi3b83JrjVz2UH9LJv+U4EJjmdJ29TkOx Q2sjUJ6y/TFIzFk7+FPNleUGzi7qLJL761VtSoKIVSy/9ASdbchhfAjfd4VoiUVhra jqBUsSwwVVSxinEK7G/87PIgNRtTGyegbm1QR5P1rYG679Xt/+HPolCmuzxO+4qSgb sxPY6oC5Eqs2e/mGdC9XyR7fUo3hBQKMxXmjOVvdsagIsshUpxdgaXQ/+HztEXbMoR i3ZSdcqGbCuu2HhkiruwbQSKJjQ8DFU2w1BnC16exY2DDxyAcgJXqBxPXbS9PQTeja cuAub6PQhWMEw== Received: from ip-185-104-136-29.ptr.icomera.net ([185.104.136.29] helo=wait-a-minute.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1ruSMQ-00333E-2I; Wed, 10 Apr 2024 08:27:10 +0100 Date: Wed, 10 Apr 2024 08:27:07 +0100 Message-ID: <87a5m1smno.wl-maz@kernel.org> From: Marc Zyngier To: Mark Brown Cc: Catalin Marinas , Will Deacon , Oliver Upton , James Morse , Suzuki K Poulose , Jonathan Corbet , Shuah Khan , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Dave Martin , kvmarm@lists.linux.dev, linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org Subject: Re: [PATCH v6 1/5] KVM: arm64: Share all userspace hardened thread data with the hypervisor In-Reply-To: <562e1ddb-75e5-4c02-83ea-b946b88d35c8@sirena.org.uk> References: <20240329-arm64-2023-dpisa-v6-0-ba42db6c27f3@kernel.org> <20240329-arm64-2023-dpisa-v6-1-ba42db6c27f3@kernel.org> <87msqesoty.wl-maz@kernel.org> <86h6gju87m.wl-maz@kernel.org> <562e1ddb-75e5-4c02-83ea-b946b88d35c8@sirena.org.uk> 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/28.2 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: 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.104.136.29 X-SA-Exim-Rcpt-To: broonie@kernel.org, catalin.marinas@arm.com, will@kernel.org, oliver.upton@linux.dev, james.morse@arm.com, suzuki.poulose@arm.com, corbet@lwn.net, shuah@kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Dave.Martin@arm.com, kvmarm@lists.linux.dev, linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Tue, 02 Apr 2024 17:20:36 +0100, Mark Brown wrote: > > On Tue, Apr 02, 2024 at 03:53:33PM +0100, Marc Zyngier wrote: > > Mark Brown wrote: > > > > Sure, those patches are still in flight though. It does seem reasonable > > > to target the current code. > > > Sure, if your intent is for this code not to be merged. > > > Because it means this series assumes a different data life cycle, and > > the review effort spent on it will be invalidated once you move to the > > per-CPU state. > > I don't have any visibility on when those patches are likely to get > merged or the general practices with in flight serieses here, last time > around with some of the serieses that were in flight it was quite late > which did make it unclear if things would go in during that release > cycle at all. Here's a trick: you could ask. Other people do. > The amount of churn in KVM recently and long periods where the relevant > patches are apparently pre accepted but for various not always clear Nothing is "pre accepted". Everything gets discussed and reviewed. Specially when it comes to what you call "churn", which I call "crap removal". > reasons not actually merged is making it quite hard to target, you're Things get merged when they are reviewed and ready. Not before. > obviously going to be a lot more in the loop so this is doubtless > clearer to you than to me. It's also been a little unclear what the > expectations are for basing things on - some people do prefer to do > their own merging for example, and while you have mentioned your in This isn't about resolving a simple conflict. This is a fundamental change in the way the state is tracked. We have argued about this for months now, you were Cc'd on the patches addressing this problem, and you even reviewed them. What other hint do you need? > flight serieses your communication style means that it's not been > entirely clear if you're just noting the overlap. Not clear? That's a first. I'm usually seen as "blunt and assertive". But I'll keep that in mind and aspire to greater clarity in the future. > Is it just that > refactoring series you want taking into account here or are there other > in flight serieses that should be rolled into a base? That, and the already merged feature enforcement framework which you keep ignoring. I'll push out a rc3-based branch in to -next shortly so that it is crystal clear what you need to base things on. M. -- Without deviation from the norm, progress is not possible. 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 EC8E6CD1297 for ; Wed, 10 Apr 2024 07:27:29 +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=4m+/Ol+T1qjGknBAFhbvWMgIn7rIHXIf8SyhOoAc8fM=; b=q3s3UzH3ISwPn+ Ji6noQAsStetmQ8Jp2c1pnVeUZJO43dR3VOMjqsHYr+1VdKtY1+uizo5FhE4J+DtfCZvISkn5Ips9 +ofEqHCZacCbvBSseS9fBbvi+mRnZApar3fQLOemyO/STAFe61EBn4Er37AI84Mvj8q08y9v9PDvo ela0wFtPdO7Hy1l0wAKbGhnZURc/Rp8u4/DMnlfbof8P6huSMuG4yhjaKdqCqWeoLEZg7pYJz2ZnE s9rJkYqIBhf6xOXB7Y46rOoj7JeYvZd18Acj0MdJY6Uov74I7BKF/PXzsJ39f9hIYlYY2FGTkdo7R QzcYkQFYrHtXT3/mt/lA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1ruSMZ-00000005bXB-1LiP; Wed, 10 Apr 2024 07:27:19 +0000 Received: from sin.source.kernel.org ([2604:1380:40e1:4800::1]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1ruSMW-00000005bVG-07Ty for linux-arm-kernel@lists.infradead.org; Wed, 10 Apr 2024 07:27:17 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 8A8C5CE2241; Wed, 10 Apr 2024 07:27:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C2CE3C433C7; Wed, 10 Apr 2024 07:27:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1712734032; bh=Nlv4greCsNCXD6xVDNfDR2Ichl1UewO2fmoorEV3bHM=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=U6opM9M0oVk3Jcvjud9swIeKHMJODpauPi3b83JrjVz2UH9LJv+U4EJjmdJ29TkOx Q2sjUJ6y/TFIzFk7+FPNleUGzi7qLJL761VtSoKIVSy/9ASdbchhfAjfd4VoiUVhra jqBUsSwwVVSxinEK7G/87PIgNRtTGyegbm1QR5P1rYG679Xt/+HPolCmuzxO+4qSgb sxPY6oC5Eqs2e/mGdC9XyR7fUo3hBQKMxXmjOVvdsagIsshUpxdgaXQ/+HztEXbMoR i3ZSdcqGbCuu2HhkiruwbQSKJjQ8DFU2w1BnC16exY2DDxyAcgJXqBxPXbS9PQTeja cuAub6PQhWMEw== Received: from ip-185-104-136-29.ptr.icomera.net ([185.104.136.29] helo=wait-a-minute.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1ruSMQ-00333E-2I; Wed, 10 Apr 2024 08:27:10 +0100 Date: Wed, 10 Apr 2024 08:27:07 +0100 Message-ID: <87a5m1smno.wl-maz@kernel.org> From: Marc Zyngier To: Mark Brown Cc: Catalin Marinas , Will Deacon , Oliver Upton , James Morse , Suzuki K Poulose , Jonathan Corbet , Shuah Khan , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Dave Martin , kvmarm@lists.linux.dev, linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org Subject: Re: [PATCH v6 1/5] KVM: arm64: Share all userspace hardened thread data with the hypervisor In-Reply-To: <562e1ddb-75e5-4c02-83ea-b946b88d35c8@sirena.org.uk> References: <20240329-arm64-2023-dpisa-v6-0-ba42db6c27f3@kernel.org> <20240329-arm64-2023-dpisa-v6-1-ba42db6c27f3@kernel.org> <87msqesoty.wl-maz@kernel.org> <86h6gju87m.wl-maz@kernel.org> <562e1ddb-75e5-4c02-83ea-b946b88d35c8@sirena.org.uk> 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/28.2 (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.104.136.29 X-SA-Exim-Rcpt-To: broonie@kernel.org, catalin.marinas@arm.com, will@kernel.org, oliver.upton@linux.dev, james.morse@arm.com, suzuki.poulose@arm.com, corbet@lwn.net, shuah@kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Dave.Martin@arm.com, kvmarm@lists.linux.dev, linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org 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-20240410_002716_670794_03CBD0B2 X-CRM114-Status: GOOD ( 35.35 ) 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 Tue, 02 Apr 2024 17:20:36 +0100, Mark Brown wrote: > > On Tue, Apr 02, 2024 at 03:53:33PM +0100, Marc Zyngier wrote: > > Mark Brown wrote: > > > > Sure, those patches are still in flight though. It does seem reasonable > > > to target the current code. > > > Sure, if your intent is for this code not to be merged. > > > Because it means this series assumes a different data life cycle, and > > the review effort spent on it will be invalidated once you move to the > > per-CPU state. > > I don't have any visibility on when those patches are likely to get > merged or the general practices with in flight serieses here, last time > around with some of the serieses that were in flight it was quite late > which did make it unclear if things would go in during that release > cycle at all. Here's a trick: you could ask. Other people do. > The amount of churn in KVM recently and long periods where the relevant > patches are apparently pre accepted but for various not always clear Nothing is "pre accepted". Everything gets discussed and reviewed. Specially when it comes to what you call "churn", which I call "crap removal". > reasons not actually merged is making it quite hard to target, you're Things get merged when they are reviewed and ready. Not before. > obviously going to be a lot more in the loop so this is doubtless > clearer to you than to me. It's also been a little unclear what the > expectations are for basing things on - some people do prefer to do > their own merging for example, and while you have mentioned your in This isn't about resolving a simple conflict. This is a fundamental change in the way the state is tracked. We have argued about this for months now, you were Cc'd on the patches addressing this problem, and you even reviewed them. What other hint do you need? > flight serieses your communication style means that it's not been > entirely clear if you're just noting the overlap. Not clear? That's a first. I'm usually seen as "blunt and assertive". But I'll keep that in mind and aspire to greater clarity in the future. > Is it just that > refactoring series you want taking into account here or are there other > in flight serieses that should be rolled into a base? That, and the already merged feature enforcement framework which you keep ignoring. I'll push out a rc3-based branch in to -next shortly so that it is crystal clear what you need to base things on. 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