Linux IOMMU Development
 help / color / mirror / Atom feed
From: Pranjal Shrivastava <praan@google.com>
To: Nicolin Chen <nicolinc@nvidia.com>
Cc: Joerg Roedel <joro@8bytes.org>, Will Deacon <will@kernel.org>,
	Robin Murphy <robin.murphy@arm.com>,
	Mostafa Saleh <smostafa@google.com>,
	iommu@lists.linux.dev, Daniel Mentz <danielmentz@google.com>
Subject: Re: [PATCH v3 1/2] iommu/arm-smmu-v3: Print better events records
Date: Tue, 1 Oct 2024 20:52:57 +0000	[thread overview]
Message-ID: <ZvxhKfUtXse9Nqxs@google.com> (raw)
In-Reply-To: <Zvr4vmU7u2BY3MLM@Asurada-Nvidia>

On Mon, Sep 30, 2024 at 12:15:10PM -0700, Nicolin Chen wrote:
> On Sat, Sep 28, 2024 at 12:51:42AM +0000, Pranjal Shrivastava wrote:
> 
> > +static const char * const class_str[] = {
> > +       [0] = "CD fetch",
> > +       [1] = "Stage 1 translation table fetch",
> > +       [2] = "Input address caused fault ",
> > +       [3] = "Reserved",
> > +};
> 
> s/class_str/event_class_str
> 

Ack.

> > @@ -1756,6 +1784,66 @@ arm_smmu_find_master(struct arm_smmu_device *smmu, u32 sid)
> >         return rb_entry(node, struct arm_smmu_stream, node)->master;
> >  }
> > 
> > +static void arm_smmu_dump_raw_event(struct arm_smmu_device *smmu,
> > +                                   struct arm_smmu_event *event)
> > +{
> > +       int i;
> > +
> > +       dev_err(smmu->dev, "event 0x%02x received: master %s:\n",
> > +               event->id, event->master_name);
> > +
> > +       for (i = 0; i < EVTQ_ENT_DWORDS; ++i)
> > +               dev_err(smmu->dev, "\t0x%016llx\n",
> > +                        (unsigned long long)event->raw[i]);
> 
> Though I know that is what we have been doing in the driver, I
> wonder if we have to cast from u64 to ull?
> 

I think we can do that? Are we avoiding potential compiler troubles?

> > +static void arm_smmu_dump_event(struct arm_smmu_device *smmu,
> > +                               struct arm_smmu_event *event)
> > +{
> > +       char title[256] = {0};
> > +       char mastr[256] = {0};
> > +       char addrs[256] = {0};
> > +       char flags[256] = {0};
> > +       char other[256] = {0};
> > +
> > +       snprintf(title, 256, "Unexpected event received: %s\n", event_str[event->id]);
> > +       snprintf(mastr, 256, "\tmaster: %s sid: 0x%08x.0x%05x\n",
> > +                event->master_name, event->sid, event->ssid);
> > +
> > +       switch (event->id) {
> > +       case EVT_ID_TRANSLATION_FAULT:
> > +       case EVT_ID_ADDR_SIZE_FAULT:
> > +       case EVT_ID_ACCESS_FAULT:
> > +       case EVT_ID_PERMISSION_FAULT:
> > +               snprintf(addrs, 256, "\tiova = %#llx ipa = %#llx\n", event->iova, event->ipa);
> > +               snprintf(flags, 256, "\t%s%s%s%s%s%s\n",
> > +                               event->privileged ? "Priv |" : "Unpriv |",
> > +                               event->instruction ? " Inst |" : " Data |",
> > +                               event->read ? " Read |" : " Write |",
> 
> Indentations are not matched with the snprintf(mastr line:
> 		snprintf(flags, 256, "\t%s%s%s%s%s%s\n",
> 			 event->privileged ? "Priv |" : "Unpriv |",
> 			 ...
> 

Ack, will fix this in the next version..

> > +                               event->s2 ? "S2|" : "S1|", class_str[event->class],
> 
> The previous flags have spaces: " Inst |", " Read |". So, maybe:
> 			 " S2 |" and " S1 |" here?
> 

Ack. I'm guessing even in the worst case we'd get to 78 chars so adding
a space should be fine?

> > +                               ((event->id == EVT_ID_PERMISSION_FAULT) &&
> > +                                (event->class == EVTQ_1_CLASS_TT)) ?
> > +                                 (FIELD_GET(EVTQ_1_TT_READ, event->raw[1]) ?
> > +                                 "|TTD Read" : "|TTD Write") : "");
> 
> I'd try to avoid that nested ternary. Perhaps:
> 	char ttrnd[32] = {0};
> 	...
> 	case EVT_ID_PERMISSION_FAULT:
> 		if (event->class == EVTQ_1_CLASS_TT) {
> 			snprintf(ttrnd, 256, "%s",
> 				 FIELD_GET(EVTQ_1_TT_READ, event->raw[1]) ?
> 				 " | TTD Read" : " | TTD Write");
> 		}
> 		fallthrough;
> 	case EVT_ID_TRANSLATION_FAULT:
> 	case EVT_ID_ADDR_SIZE_FAULT:
> 	case EVT_ID_ACCESS_FAULT:
> 		snprintf(flags, 256, "\t%s%s%s%s%s%s\n",
> 			 event->privileged ? "Priv |" : "Unpriv |",
> 			 event->instruction ? " Inst |" : " Data |",
> 			 event->read ? " Read |" : " Write |",
> 			 event->s2 ? " S2 |" : " S1 |",
> 			 event_class_str[event->class], ttrnd);
> 

Hmm, I like that idea. I'll add something like this!

> > +               snprintf(other, 256, "\tSTAG = %#x Stall = %#x\n",
> > +                               event->stag, event->stall);
> > +               break;
> > +
> > +       case EVT_ID_STE_FETCH_FAULT:
> > +       case EVT_ID_CD_FETCH_FAULT:
> > +       case EVT_ID_VMS_FETCH_FAULT:
> > +               snprintf(addrs, 256, "\tFetch address: %#llx\n", event->ipa);
> > +               break;
> > +       }
> > +
> > +       dev_err(smmu->dev, "%s%s%s%s%s", title, mastr,
> > +               strlen(addrs) ? addrs : "",
> > +               strlen(flags) ? flags : "",
> > +               strlen(other) ? other : "");
> 
> It looks to me that you init-ed them well, so maybe strlen isn't
> necessary?
> 

True, missed that, will remove this.

> > +
> > +       arm_smmu_dump_raw_event(smmu, event);
> > +}
> 
> I assume these prints would look good, yet, would you please try
> triggering a FAULT to give us a showcase in the commit message?
> 

Sure, let me arrange for a sample FAULT log in the next version!

> > +static void arm_smmu_get_evt_info(struct arm_smmu_device *smmu, u64 *evt,
> > +                                 struct arm_smmu_event *event)
> > +{
> > +       mutex_lock(&smmu->streams_mutex);
> > +       event->master = arm_smmu_find_master(smmu, event->sid);
> > +       mutex_unlock(&smmu->streams_mutex);
> > +
> > +       if (event->master)
> > +               event->master_name = dev_name(event->master->dev);
> > +       else
> > +               event->master_name = "(unassigned sid)";
> 
> Likely safer for dev_name to be in the mutex too.
> 

Ack.

> Thanks
> Nicolin

Thanks,
Pranjal

  reply	other threads:[~2024-10-01 20:53 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-28  0:51 [PATCH v3 0/2] Parse out event records Pranjal Shrivastava
2024-09-28  0:51 ` [PATCH v3 1/2] iommu/arm-smmu-v3: Print better events records Pranjal Shrivastava
2024-09-30 19:15   ` Nicolin Chen
2024-10-01 20:52     ` Pranjal Shrivastava [this message]
2024-10-01 23:04       ` Nicolin Chen
2024-10-02 13:57     ` Jason Gunthorpe
2024-10-02 16:55       ` Nicolin Chen
2024-10-02 17:10         ` Jason Gunthorpe
2024-10-02 17:22           ` Nicolin Chen
2024-10-03 21:26             ` Pranjal Shrivastava
2024-10-03 22:50               ` Nicolin Chen
2024-10-11  7:53                 ` Pranjal Shrivastava
2024-10-11 10:02                   ` Pranjal Shrivastava
2024-09-28  0:51 ` [PATCH v3 2/2] iommu/arm-smmu-v3: Adopt arm_smmu_event in handlers Pranjal Shrivastava
2024-09-30 19:32   ` Nicolin Chen
2024-10-01 21:02     ` Pranjal Shrivastava
2024-10-01 22:59       ` Nicolin Chen
2024-10-03 21:34         ` Pranjal Shrivastava
2024-10-03 22:53           ` Nicolin Chen
2024-10-11  7:55             ` Pranjal Shrivastava
2024-10-11 10:21               ` Robin Murphy
2024-10-11 10:45                 ` Pranjal Shrivastava
2024-10-11 11:06                   ` Pranjal Shrivastava
2024-10-11 12:59                     ` Robin Murphy
2024-10-11 20:31                       ` Pranjal Shrivastava
2024-10-15 18:34                       ` Pranjal Shrivastava
2024-10-15 20:03                         ` Robin Murphy
2024-10-17  8:06                           ` Pranjal Shrivastava

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=ZvxhKfUtXse9Nqxs@google.com \
    --to=praan@google.com \
    --cc=danielmentz@google.com \
    --cc=iommu@lists.linux.dev \
    --cc=joro@8bytes.org \
    --cc=nicolinc@nvidia.com \
    --cc=robin.murphy@arm.com \
    --cc=smostafa@google.com \
    --cc=will@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox