All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Monakov <amonakov@ispras.ru>
To: Shuah Khan <skhan@linuxfoundation.org>
Cc: linux-kernel@vger.kernel.org, Joerg Roedel <joro@8bytes.org>,
	Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>,
	iommu@lists.linux-foundation.org
Subject: Re: [PATCH] iommu/amd: Fix event counter availability check
Date: Wed, 3 Jun 2020 09:54:42 +0300 (MSK)	[thread overview]
Message-ID: <alpine.LNX.2.20.13.2006030935570.3181@monopod.intra.ispras.ru> (raw)
In-Reply-To: <c0f9f676-eff8-572d-9174-4c22c6095a3d@linuxfoundation.org>

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?

Alexander

WARNING: multiple messages have this Message-ID (diff)
From: Alexander Monakov <amonakov@ispras.ru>
To: Shuah Khan <skhan@linuxfoundation.org>
Cc: iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] iommu/amd: Fix event counter availability check
Date: Wed, 3 Jun 2020 09:54:42 +0300 (MSK)	[thread overview]
Message-ID: <alpine.LNX.2.20.13.2006030935570.3181@monopod.intra.ispras.ru> (raw)
In-Reply-To: <c0f9f676-eff8-572d-9174-4c22c6095a3d@linuxfoundation.org>

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?

Alexander
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

  reply	other threads:[~2020-06-03  6:54 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-29 20:07 [PATCH] iommu/amd: Fix event counter availability check Alexander Monakov
2020-05-29 20:07 ` Alexander Monakov
2020-05-31  7:22 ` Alexander Monakov
2020-05-31  7:22   ` Alexander Monakov
2020-06-01  2:48   ` Paul Menzel
2020-06-01  2:48     ` Paul Menzel
2021-02-21 13:44     ` Paul Menzel
2021-02-21 13:44       ` Paul Menzel
2020-06-02 23:51   ` Shuah Khan
2020-06-02 23:51     ` Shuah Khan
2020-06-03  6:54     ` Alexander Monakov [this message]
2020-06-03  6:54       ` Alexander Monakov
2021-02-26 21:44       ` Paul Menzel
2021-02-26 21:44         ` Paul Menzel
2021-02-26 21:55         ` Shuah Khan
2021-02-26 21:55           ` Shuah Khan
2020-06-01  7:37 ` Suravee Suthikulpanit
2020-06-01  7:37   ` Suravee Suthikulpanit
2020-06-01  9:01   ` Alexander Monakov
2020-06-01  9:01     ` Alexander Monakov
2020-06-01 15:10     ` Suravee Suthikulpanit
2020-06-01 15:10       ` Suravee Suthikulpanit
2020-06-01 16:09       ` Alexander Monakov
2020-06-01 16:09         ` Alexander Monakov
2020-06-15 20:48       ` Alexander Monakov
2020-06-15 20:48         ` Alexander Monakov
2020-06-16  9:35         ` Suravee Suthikulpanit
2020-06-16  9:35           ` Suravee Suthikulpanit
2020-06-30 19:22           ` Alexander Monakov
2020-06-30 19:22             ` Alexander Monakov
2020-09-17 17:55           ` Alexander Monakov
2020-09-17 17:55             ` Alexander Monakov
2021-02-21 13:49             ` Paul Menzel
2021-02-21 13:49               ` Paul Menzel
2021-02-22 17:59               ` Suravee Suthikulpanit
2021-02-22 17:59                 ` Suravee Suthikulpanit
2021-02-24 20:35                 ` Paul Menzel
2021-02-24 20:35                   ` Paul Menzel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LNX.2.20.13.2006030935570.3181@monopod.intra.ispras.ru \
    --to=amonakov@ispras.ru \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=skhan@linuxfoundation.org \
    --cc=suravee.suthikulpanit@amd.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.