qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: Peter Xu <peterx@redhat.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
	Jason Wang <jasowang@redhat.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	Eduardo Habkost <eduardo@habkost.net>,
	 Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
Subject: Re: [RFC PATCH] intel-iommu: Report interrupt remapping faults
Date: Sat, 11 Mar 2023 10:30:02 +0000	[thread overview]
Message-ID: <04a460689cbf86e88d6aae6a2248b77a8792c4f2.camel@infradead.org> (raw)
In-Reply-To: <ZAuZ1g7GyrgvH+NP@x1n>

[-- Attachment #1: Type: text/plain, Size: 5367 bytes --]

On Fri, 2023-03-10 at 15:57 -0500, Peter Xu wrote:
> On Fri, Mar 10, 2023 at 05:49:38PM +0000, David Woodhouse wrote:
> > From: David Woodhouse <dwmw@amazon.co.uk>
> > 
> > +}
> > +
> > +#define log_irte_fault(f, sid, i) vtd_report_ir_fault(iommu, sid, f, i)
> 
> This one seems not used.

Oops yes, that was supposed to be temporary until I did the
search/replace.

> > +
> >  /* Handle Invalidation Queue Errors of queued invalidation interface error
> >   * conditions.
> >   */
> > @@ -3300,7 +3320,8 @@ static Property vtd_properties[] = {
> >  
> >  /* Read IRTE entry with specific index */
> >  static int vtd_irte_get(IntelIOMMUState *iommu, uint16_t index,
> > -                        VTD_IR_TableEntry *entry, uint16_t sid)
> > +                        VTD_IR_TableEntry *entry, uint16_t sid,
> > +                        bool do_fault)
> >  {
> >      static const uint16_t vtd_svt_mask[VTD_SQ_MAX] = \
> >          {0xffff, 0xfffb, 0xfff9, 0xfff8};
> > @@ -3311,6 +3332,9 @@ static int vtd_irte_get(IntelIOMMUState *iommu, uint16_t index,
> >      if (index >= iommu->intr_size) {
> >          error_report_once("%s: index too large: ind=0x%x",
> >                            __func__, index);
> > +        if (do_fault) {
> > +            vtd_report_ir_fault(iommu, sid, VTD_FR_IR_INDEX_OVER, index);
> > +        }
> 
> IIUC it's only the fault reason to report, then I am thinking if it's
> easier to let the caller taking care of that?
> 
> Though we'll need conditions for fault disabled, e.g....
> 
> >          return -VTD_FR_IR_INDEX_OVER;

Well, remember I want to kill that *return* of the VTD_FR_xxx error, so
although it looks like duplication now, it won't be.


> >      }
> >  
> > @@ -3319,17 +3343,33 @@ static int vtd_irte_get(IntelIOMMUState *iommu, uint16_t index,
> >                          entry, sizeof(*entry), MEMTXATTRS_UNSPECIFIED)) {
> >          error_report_once("%s: read failed: ind=0x%x addr=0x%" PRIx64,
> >                            __func__, index, addr);
> > +        if (do_fault) {
> > +            vtd_report_ir_fault(iommu, sid, VTD_FR_IR_ROOT_INVAL, index);
> > +        }
> >          return -VTD_FR_IR_ROOT_INVAL;
> >      }
> >  
> >      trace_vtd_ir_irte_get(index, le64_to_cpu(entry->data[1]),
> >                            le64_to_cpu(entry->data[0]));
> >  
> > +       /*
> > +        * The remaining potential fault conditions are "qualified" by the
> > +        * Fault Processing Disable bit in the IRTE. Even "not present".
> > +        * So just clear the do_fault flag if PFD is set, which will
> > +        * prevent faults being raised.
> > +        */
> > +       if (entry->irte.fault_disable) {
> > +               do_fault = false;
> > +    }
> > +
> >      if (!entry->irte.present) {
> >          error_report_once("%s: detected non-present IRTE "
> >                            "(index=%u, high=0x%" PRIx64 ", low=0x%" PRIx64 ")",
> >                            __func__, index, le64_to_cpu(entry->data[1]),
> >                            le64_to_cpu(entry->data[0]));
> > +        if (do_fault) {
> > +            vtd_report_ir_fault(iommu, sid, VTD_FR_IR_ENTRY_P, index);
> > +        }
> >          return -VTD_FR_IR_ENTRY_P;
> 
> ... here IIUC we can do:
> 
>   if (entry->irte.fault_disable)
>         return 0;
>   else
>         return -VTD_FR_IR_ENTRY_P;
>         
> Hence when error occurs we always keep the error report above, and let the
> caller report IR fault when <0.  It seems this will at least avoid plenty
> of same calls within vtd_irte_get().
> 
> I do see a few others outside vtd_irte_get().  In short, it'll be nice to
> avoid calling this same pattern in multiple places somehow.

I suppose we could pass the do_fault *into* vtd_report_ir_fault(). It's
a similar pattern to vtd_report_fault() which also takes an is_fpd_set
argument.

(Note: If I could tolerate just passing VTD_FRCD_IR_IDX(index) I think
I could actually just *call* the existing vtd_report_fault() without
having to touch any of the fault reporting functions at all. The bits
do all end up in the right place. It just seemed a bit icky.)

I did briefly ponder just returning the value and then letting the
caller do the report, but then we'd *also* have to make the return code
distinguish between "failed, but do not report a fault" and "succeeded,
and your translation is valid" cases. I figured I preferred it this
way.


> > --- a/hw/i386/intel_iommu_internal.h
> > +++ b/hw/i386/intel_iommu_internal.h
> > @@ -268,6 +268,7 @@
> >  #define VTD_FRCD_FI(val)        ((val) & ~0xfffULL)
> >  #define VTD_FRCD_PV(val)        (((val) & 0xffffULL) << 40)
> >  #define VTD_FRCD_PP(val)        (((val) & 0x1) << 31)
> > +#define VTD_FRCD_IR_IDX(val)    (((val) & 0xffffULL) << 48)


Think 'val' probably needs casting to a (uint64_t) before the shift there.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5965 bytes --]

      reply	other threads:[~2023-03-11 10:31 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-10 17:49 [RFC PATCH] intel-iommu: Report interrupt remapping faults David Woodhouse
2023-03-10 20:57 ` Peter Xu
2023-03-11 10:30   ` David Woodhouse [this message]

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=04a460689cbf86e88d6aae6a2248b77a8792c4f2.camel@infradead.org \
    --to=dwmw2@infradead.org \
    --cc=eduardo@habkost.net \
    --cc=jasowang@redhat.com \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.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).