xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Cc: suravee.suthikulpanit@amd.com, xen-devel@lists.xen.org
Subject: Re: [PATCH 2/2 V2] iommu/amd: Workaround for erratum 787
Date: Mon, 10 Jun 2013 17:31:45 +0100	[thread overview]
Message-ID: <20130610163145.GI8802@ocelot.phlegethon.org> (raw)
In-Reply-To: <51B606E402000078000DCBA0@nat28.tlf.novell.com>

At 16:03 +0100 on 10 Jun (1370880211), Jan Beulich wrote:
> >>> On 10.06.13 at 15:55, "Jan Beulich" <JBeulich@suse.com> wrote:
> >>>> On 10.06.13 at 14:43, Tim Deegan <tim@xen.org> wrote:
> >> How about:
> >>  write-to-clear status.pending
> >>  process the log
> >>  if (status.pending)
> >>     reschedule the tasklet
> >>  else
> >>     unmask the interrupt.
> > 
> > Actually, I don't think that's right: Clearing the pending bit with
> > the respective interrupt source disabled doesn't allow the
> > pending bit to become set again upon arrival of a new log entry,

>From my reading of the IOMMU spec the pending bit gets set whether the
enable bit is set or not:

  PPRInt: peripheral page service request interrupt. Revision 1:
  RO. Reset 0b. Reserved.  Revision 2: RW1C. Reset 0b. 1=PPR request
  entry written to the PPR log by the IOMMU. 0=No PPR entry written to
  the PPR log by the IOMMU. An interrupt is generated when PPRInt=1b and
  MMIO Offset 0018h[PPRIntEn]=1b.

and

  EventLogInt: event log interrupt. RW1C. Reset 0b. 1=Event entry
  written to the event log by the IOMMU. 0=No event entry written to the
  event log by the IOMMU. An interrupt is generated when EventLogInt=1b
  and MMIO Offset 0018h[EventIntEn]=1b.

so we should be OK without a second pass if the pending bit is still
clear after unmasking the interrupt.

> So with this done I now realized that all of these transformations
> don't really belong in this erratum workaround patch.

Agreed.  I think this reshuffle to avoid lost entries should be its own
patch, and the erratum 787 one should follow it -- unless the logic we
end up with handles erratum 787 as a side-effect. :)

> static void iommu_check_event_log(struct amd_iommu *iommu)
> {
>     u32 entry;
>     unsigned long flags;
> 
>     for ( ; ; )
>     {
>         /* RW1C interrupt status bit */
>         writel(IOMMU_STATUS_EVENT_LOG_INT_MASK,
>                iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
> 
>         iommu_read_log(iommu, &iommu->event_log,
>                        sizeof(event_entry_t), parse_event_log_entry);
> 
>         spin_lock_irqsave(&iommu->lock, flags);
> 
>         /* Check event overflow. */
>         entry = readl(iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
>         if ( entry & IOMMU_STATUS_EVENT_OVERFLOW_MASK )
>             iommu_reset_log(iommu, &iommu->event_log,
>                             set_iommu_event_log_control);
>         else
>         {
>             entry = readl(iommu->mmio_base + IOMMU_CONTROL_MMIO_OFFSET);
>             if ( !(entry & IOMMU_CONTROL_EVENT_LOG_INT_MASK) )
>             {
>                 entry |= IOMMU_CONTROL_EVENT_LOG_INT_MASK;
>                 writel(entry, iommu->mmio_base + IOMMU_CONTROL_MMIO_OFFSET);
>                 spin_unlock_irqrestore(&iommu->lock, flags);
>                 continue;
>             }
>         }
> 
>         break;
>     }
> 
>     /*
>      * Workaround for erratum787:
>      * Re-check to make sure the bit has been cleared.
>      */
>     entry = readl(iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
>     if ( entry & IOMMU_STATUS_EVENT_LOG_INT_MASK )
>         tasklet_schedule(&amd_iommu_irq_tasklet);
> 
>     spin_unlock_irqrestore(&iommu->lock, flags);
> }
> 
> You'll note that even here we're having a loop again, which you
> presumably won't like much.

Well, this time the event handling is inside the loop, so it ought to
catch and disable bad passthrough devices.  I'd still prefer having the
tasklet schedule itself and terminate, but I'm happy to defer to your
taste.

> The only alternative I see is to run
> iommu_read_log() with iommu->lock held, which has the caveat of
> the function itself taking a lock (albeit - without having done any
> proving yet - I think that lock is taken completely pointlessly).
> 
> In any case - the erratum workaround is really just the comment
> and three following lines. Everything else belongs elsewhere imo.

Yep.

Tim.

  reply	other threads:[~2013-06-10 16:31 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-10  5:05 [PATCH 1/2 V2] iommu/amd: Fix logic for clearing the IOMMU interrupt bits suravee.suthikulpanit
2013-06-10  5:05 ` [PATCH 2/2 V2] iommu/amd: Workaround for erratum 787 suravee.suthikulpanit
2013-06-10  9:35   ` Tim Deegan
2013-06-10  9:47     ` Jan Beulich
2013-06-10 10:40       ` Tim Deegan
2013-06-10 10:53         ` Jan Beulich
2013-06-10 12:43           ` Tim Deegan
2013-06-10 13:23             ` Jan Beulich
2013-06-10 13:41             ` Jan Beulich
2013-06-10 13:56               ` Tim Deegan
2013-06-10 13:55             ` Jan Beulich
2013-06-10 15:03               ` Jan Beulich
2013-06-10 16:31                 ` Tim Deegan [this message]
2013-06-10 23:13                   ` Suravee Suthikulanit
2013-06-11  6:45                     ` Jan Beulich
2013-06-11  6:40                   ` Jan Beulich
2013-06-11  8:53                     ` Tim Deegan
2013-06-10 13:53           ` Suravee Suthikulanit
2013-06-10 13:59             ` Jan Beulich
2013-06-10 15:11               ` Suravee Suthikulanit
2013-06-10 15:21                 ` Jan Beulich
2013-06-10 10:59   ` [PATCH 2/2 v3] " Jan Beulich
2013-06-11  6:47     ` [PATCH 2/2 v5] " Jan Beulich
2013-06-17 18:57       ` Suravee Suthikulanit
2013-06-10 10:05 ` [PATCH 1/2 V2] iommu/amd: Fix logic for clearing the IOMMU interrupt bits Jan Beulich
2013-06-10 10:56 ` [PATCH 1/2 v3] " Jan Beulich
2013-06-10 11:02   ` Jan Beulich
2013-06-10 12:18   ` Tim Deegan
2013-06-10 12:31     ` Jan Beulich
2013-06-10 13:58       ` Suravee Suthikulanit
2013-06-10 12:41     ` [PATCH 1/2 v4] " Jan Beulich
2013-06-10 12:46       ` Tim Deegan
2013-06-10 13:49       ` George Dunlap
2013-06-10 14:08         ` Jan Beulich
2013-06-11  6:47       ` [PATCH 1/2 v5] " Jan Beulich
2013-06-11 23:03         ` Suravee Suthikulanit
2013-06-12  6:24           ` Jan Beulich
2013-06-12 22:37             ` Suravee Suthikulpanit
2013-06-13  1:44               ` Suravee Suthikulpanit
2013-06-13  7:54                 ` Jan Beulich
2013-06-13 13:48                   ` Suravee Suthikulpanit
2013-06-13 14:20                 ` George Dunlap
2013-06-13 14:30                   ` Processed: " xen
2013-06-13 15:58                 ` Jan Beulich
2013-06-13 16:34                   ` Suravee Suthikulanit
2013-06-14  6:27                     ` Jan Beulich
2013-06-14  6:40                       ` Jan Beulich
2013-06-14  7:14                         ` [PATCH] AMD IOMMU: make interrupt work again Jan Beulich
2013-06-14 16:10                           ` Suravee Suthikulanit
2013-06-17 18:59             ` [PATCH 1/2 v5] iommu/amd: Fix logic for clearing the IOMMU interrupt bits Suravee Suthikulanit

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=20130610163145.GI8802@ocelot.phlegethon.org \
    --to=tim@xen.org \
    --cc=JBeulich@suse.com \
    --cc=suravee.suthikulpanit@amd.com \
    --cc=xen-devel@lists.xen.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;
as well as URLs for NNTP newsgroup(s).