Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1545065pxb; Fri, 26 Feb 2021 13:45:40 -0800 (PST) X-Google-Smtp-Source: ABdhPJzYt7S2ZUoAJJMXxfOGeQ5Hu7PyELXo27fPqKkbGmT2wgeyoNosD5bamvUQotorjNtlGMUu X-Received: by 2002:a17:906:5fc5:: with SMTP id k5mr3949331ejv.345.1614375940455; Fri, 26 Feb 2021 13:45:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614375940; cv=none; d=google.com; s=arc-20160816; b=yywZdHPGKNNwc0HpPC9kWNYAFOuRblDQqhL7l3g3GC5iliv/2MlqqkCo1zPO2p3VF5 fb8MkRM6BGfkA+todbH7ajigxWwxPFzOAyNno+cSFaFGA2lFmDzJi9PTpSmHo5lWjbwf KP1JeiSLl4Ff9cQ9M5MBK1uI6DMTDNaJPYXpb8Qjdgt6qYvn7x8OIkdDGYk3kFkQIoIX vMxLs5xzALm8DVsac7jlJBj6vcLkl4hHi7rfDkJj14AKCLKZExhWC2n81p5ZQxY6UKM5 vle0VB5BQIoXGFOJYs0n7L+CTVJ4+Ijuziyhep6/r4+r9W/3vJ9jATxfA/fbFy0myiUV p+lw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=ppOC1947z12RGEODWmMnvMh8Tq8tXicaOPLvkPVQo7w=; b=kc4DWmIZT43S8Uxpj1o10oUFgw/RHgMC8bfJaHolxy5jjNVK6ZFG//3Dunst5WPjqw n3J2tiGJNihSaoaTK/gN+YCKLkYimKBKLRa23nEmTPmiRpod9pQmJBF5NQ2cscKa9BFb u5Lib5cQhh+qX0FOl0ED4wdDmpSdD50eq4P1zrHoIjygK4S4OuK76jzxYeCBV85pTGak /CAWZ/QnKPiP2cfi7Q9eV3i/+qRpWC3V1N3qlrpoQ/JqAU8NikxUu2xS3Sl+EL2kD3RQ a4i3+YWfwU6JOTahEaJ/cB/ULcm8fxg4X+32EHvxDDA9spdUlPcQ3mxDkG9UOko6ymbM piPQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k22si2580274ejk.92.2021.02.26.13.45.17; Fri, 26 Feb 2021 13:45:40 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229823AbhBZVow (ORCPT + 99 others); Fri, 26 Feb 2021 16:44:52 -0500 Received: from mx3.molgen.mpg.de ([141.14.17.11]:52211 "EHLO mx1.molgen.mpg.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S229622AbhBZVow (ORCPT ); Fri, 26 Feb 2021 16:44:52 -0500 Received: from [192.168.0.5] (ip5f5aed0c.dynamic.kabel-deutschland.de [95.90.237.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: pmenzel) by mx.molgen.mpg.de (Postfix) with ESMTPSA id 527DD20647910; Fri, 26 Feb 2021 22:44:09 +0100 (CET) Subject: Re: [PATCH] iommu/amd: Fix event counter availability check To: Alexander Monakov , Shuah Khan , Suravee Suthikulpanit Cc: iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org, David Coe , Joerg Roedel , "Tj (Elloe Linux)" References: <20200529200738.1923-1-amonakov@ispras.ru> From: Paul Menzel Message-ID: <4aba4c61-1878-3d4e-d52e-3ccac9715010@molgen.mpg.de> Date: Fri, 26 Feb 2021 22:44:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [cc: +suravee, +jörg] Dear Alex, dear Shuah, dear Suravee, dear Jörg, Am 03.06.20 um 08:54 schrieb Alexander Monakov: > On Tue, 2 Jun 2020, Shuah Khan wrote: > >> I changed the logic to read config to get max banks and counters >> before checking if counters are writable and tried writing to all. >> The result is the same and all of them aren't writable. However, >> when disable the writable check and assume they are, I can run > [snip] > > This is similar to what I did. I also noticed that counters can > be successfully used with perf if the initial check is ignored. > I was considering sending a patch to remove the check and adjust > the event counting logic to use counters as read-only, but after > a bit more investigation I've noticed how late pci_enable_device > is done, and came up with this patch. It's a path of less resistance: > I'd expect maintainers to be more averse to removing the check > rather than fixing it so it works as intended (even though I think > the check should not be there in the first place). > > However: > > The ability to modify the counters is needed only for sampling the > events (getting an interrupt when a counter overflows). There's no > code to do that for these AMD IOMMU counters. A solution I would > prefer is to not write to those counters at all. It would simplify or > even remove a bunch of code. I can submit a corresponding patch if > there's general agreement this path is ok. > > What do you think? I like this idea. Suravee, Jörg, what do you think? Commit 6778ff5b21b (iommu/amd: Fix performance counter initialization) delays the boot up to 100 ms, which is over 20 % on fast systems, and also just a workaround, and does not seem to work always. The delay is also not mentioned in the commit message. Kind regards, Paul [1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6778ff5b21bd8e78c8bd547fd66437cf2657fd9b