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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6F388ECAAA2 for ; Sun, 28 Aug 2022 04:18:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 86E776B0073; Sun, 28 Aug 2022 00:18:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 81D386B0074; Sun, 28 Aug 2022 00:18:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6BF66940007; Sun, 28 Aug 2022 00:18:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 5AB466B0073 for ; Sun, 28 Aug 2022 00:18:13 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 1044C16020D for ; Sun, 28 Aug 2022 04:18:13 +0000 (UTC) X-FDA: 79847694066.15.CE73615 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf14.hostedemail.com (Postfix) with ESMTP id 83A39100030 for ; Sun, 28 Aug 2022 04:18:12 +0000 (UTC) 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 1713BB80AB2; Sun, 28 Aug 2022 04:18:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4A00DC433D6; Sun, 28 Aug 2022 04:18:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1661660289; bh=b1DxuemUuHqOzbSQHotO5yGNBJEyQ9fNAcJWznoBnHo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=nmqpvICagbOYzuUK7zRSHuKWYR4Q6wHz8Z9BkMNnSLOBbT3S9p5jf0P52D7k/ZA34 bP6vV99xNBskD3SnyAx9kgBAXl7RZWs0v8z8zyi4DZ49GSquJa1D52Nop6T5IsWn9b 50PJkZjDYXCr5OT1/m3MiZSXOT4WN1QSb+9RZEawAlQPjul2E9aPJSWl0qAp/0zVP0 TLRINEII6KF7d2AcAPgWVRhqFhnirzGoVeJ73gOpnN7pybKLs78LO5I1El23pKyXGq jPA+f4DkI4LJcocNVCzvyeTM7yQdnYM+rQTA8bHrXCWMPlN69lDOPDJAvOETpgzis/ 8N8bc3zBd4WMw== Date: Sun, 28 Aug 2022 07:18:02 +0300 From: Jarkko Sakkinen To: "Kalra, Ashish" Cc: Peter Gonda , the arch/x86 maintainers , LKML , kvm list , "linux-coco@lists.linux.dev" , "linux-mm@kvack.org" , Linux Crypto Mailing List , Thomas Gleixner , Ingo Molnar , Joerg Roedel , "Lendacky, Thomas" , "H. Peter Anvin" , Ard Biesheuvel , Paolo Bonzini , Sean Christopherson , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Andy Lutomirski , Dave Hansen , Sergio Lopez , Peter Zijlstra , Srinivas Pandruvada , David Rientjes , Dov Murik , Tobin Feldman-Fitzthum , Borislav Petkov , "Roth, Michael" , Vlastimil Babka , "Kirill A . Shutemov" , Andi Kleen , Tony Luck , Marc Orr , Sathyanarayanan Kuppuswamy , Alper Gun , "Dr. David Alan Gilbert" Subject: Re: [PATCH Part2 v6 02/49] iommu/amd: Introduce function to check SEV-SNP support Message-ID: References: <12df64394b1788156c8a3c2ee8dfd62b51ab3a81.1655761627.git.ashish.kalra@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=nmqpvICa; spf=pass (imf14.hostedemail.com: domain of jarkko@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=jarkko@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1661660292; a=rsa-sha256; cv=none; b=wdZSgtUqT6z0E0y7yd/PNqFlSYxTkYikK2YQJ2BXVI0VTEh9v7EzjV0ll81o7VkDZnliGH /WS7cFZHoP64IqnI8s+MijXqd9wXXQ94pAjSqOtbnmD3L+Q6PGJd6NkOj95R6xwe9PBKeG ZE/CcRR8AlS78r4phFcL2kBCGYRpop4= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1661660292; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=sDusgdszL4Qm0/Ljdwpyndtmn5xT2pd5nrQ3d84P+Ss=; b=cPNFsuF9Yd794fHMCPj2UN2FOJoncce53+wCaBxjl892Zq6LWWTFRDW+vxqTzh9paNfVts IJQDsTfcIB7GZmI2PWmLCi8zkgmrdEzOWy6eTs7hEcov+J60KlRqhrKT4xYeXDQ2d0j6Jl rVtyXePx9UEaqmgJR7b6TFrb/KXWyKQ= Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=nmqpvICa; spf=pass (imf14.hostedemail.com: domain of jarkko@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=jarkko@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-Stat-Signature: k8n4qqmbn7smx6mmmkbdzdwsr9i7i1qm X-Rspamd-Queue-Id: 83A39100030 X-Rspam-User: X-Rspamd-Server: rspam04 X-HE-Tag: 1661660292-477102 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Aug 26, 2022 at 06:54:16PM +0000, Kalra, Ashish wrote: > [AMD Official Use Only - General] > > Hello Jarkko, > > >> > >> It really should be, in order to have any practical use: > >> > >> if (no_iommu) { > >> pr_err("SEV-SNP: IOMMU is disabled.\n"); > >> return false; > >> } > >> > >> if (iommu_default_passthrough()) { > >> pr_err("SEV-SNP: IOMMU is configured in passthrough mode.\n"); > >> return false; > >> } > >> > >> The comment is *completely* redundant, it absolutely does not serve > >> any sane purpose. It just tells what the code already clearly stating. > >> > >> The combo error message on the other hand leaves you to the question > >> "which one was it", and for that reason combining the checks leaves > >> you to a louse debugging experience. > > >Also, are those really *errors*? That implies that there is something wrong. > > >Since you can have a legit configuration, IMHO they should be either warn or info. What do you think? > > >They are definitely not errors > > Yes, they can be warn or info, but as I mentioned above this patch is now part of IOMMU + SNP series, > so these comments are now relevant for that. Yeah, warn/info/error is less relevant than the second point I was making. It's a good idea to spit out two instead of one to make best of spitting out anything in the first place :-) That way you make no mistake interpreting what does the log message connect to, which can sometimes make a difference while debugging a kernel issue. BR, Jarkko