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 180E9C6FA83 for ; Tue, 27 Sep 2022 10:18:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230382AbiI0KSN (ORCPT ); Tue, 27 Sep 2022 06:18:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60770 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229608AbiI0KSJ (ORCPT ); Tue, 27 Sep 2022 06:18:09 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 725D6D079C for ; Tue, 27 Sep 2022 03:18:08 -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 dfw.source.kernel.org (Postfix) with ESMTPS id 7E69F6173B for ; Tue, 27 Sep 2022 10:18:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D6F1EC433D6; Tue, 27 Sep 2022 10:18:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1664273886; bh=H/HZ+8Yn/BiaXmw/8d1VR0gleRQhWzamBner0vTDoWc=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=DGpqE+yyCTkC0ISYppAy954jrFGx++xsqBqQX6E48GFXhLByX9Xck+RIWjTLzztn5 gkGZBxgjzCcQibYUQGHjRLx1InlistGkQ8hzAjifhoDmnlKgokqQXWSsbu8lFLx4CN Oock7os8ojEAXXh35ySF3E1ow4QQqTkS6ZiheYjv8ZykFFCjoF10S6xI/ef6Sz2Jb6 JM1N6zkjX0+F4Ge2ycxMKSF+DQcFe/5DdX++1Kga9HWUI3TgdmiV7mn/JA7Yk1H7vP zrnHIvEOTjOXJsKR34mvW5y0HVrhtwiSW5pqtUfmFoNzu9S+0r8/WI5ud5h7F4RA8v VrkokeQGxfTLg== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.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 1od7fA-00Cwgn-IO; Tue, 27 Sep 2022 11:18:04 +0100 Date: Tue, 27 Sep 2022 06:18:03 -0400 Message-ID: <86zgel6rz8.wl-maz@kernel.org> From: Marc Zyngier To: Mingwei Zhang , Oliver Upton Cc: Catalin Marinas , Will Deacon , James Morse , Alexandru Elisei , Suzuki K Poulose , linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org Subject: Re: [PATCH] KVM: arm64: Cleanup the __get_fault_info() to take out the code that validates HPFAR In-Reply-To: References: <20220927002715.2142353-1-mizhang@google.com> 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 (aarch64-unknown-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: mizhang@google.com, oliver.upton@linux.dev, catalin.marinas@arm.com, will@kernel.org, james.morse@arm.com, alexandru.elisei@arm.com, suzuki.poulose@arm.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, linux-kernel@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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 27 Sep 2022 01:14:16 -0400, Oliver Upton wrote: > > Hi Mingwei, > > On Tue, Sep 27, 2022 at 12:27:15AM +0000, Mingwei Zhang wrote: > > Cleanup __get_fault_info() to take out the code that checks HPFAR. The > > conditions in __get_fault_info() that checks if HPFAR contains a valid IPA > > is slightly messy in that several conditions are written within one IF > > statement acrossing multiple lines and are connected with different logical > > operators. Among them, some conditions come from ARM Spec, while others > ^~~~~~~~ > > Call it the ARM ARM or Arm ARM, depending on what stylization you > subscribe to :) > > > come from CPU erratum. This makes the code hard to read and > > difficult to extend. > > I'd recommend you avoid alluding to future changes unless they're posted > on the mailing list. Honestly, I'd refrain from such changes *unless* they enable something else. The current code is well understood by people hacking on it, and although I don't mind revamping it, it has to be for a good reason. I'd be much more receptive to such a change if it was a prefix to something that actually made a significant change. Thanks, M. -- Without deviation from the norm, progress is not possible.