All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Jason Wang <jasowang@redhat.com>,
	"mst@redhat.com" <mst@redhat.com>,
	"peterx@redhat.com" <peterx@redhat.com>
Cc: "Liu, Yi L" <yi.l.liu@intel.com>,
	"yi.y.sun@linux.intel.com" <yi.y.sun@linux.intel.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: RE: [PATCH V2 4/4] intel-iommu: PASID support
Date: Mon, 28 Mar 2022 07:03:38 +0000	[thread overview]
Message-ID: <BN9PR11MB527635384D3CD8F0FB4232388C1D9@BN9PR11MB5276.namprd11.prod.outlook.com> (raw)
In-Reply-To: <20220321055429.10260-5-jasowang@redhat.com>

> From: Jason Wang
> Sent: Monday, March 21, 2022 1:54 PM
> 
> +    /*
> +     * vtd-spec v3.4 3.14:
> +     *
> +     * """
> +     * Requests-with-PASID with input address in range 0xFEEx_xxxx are
> +     * translated normally like any other request-with-PASID through
> +     * DMA-remapping hardware. However, if such a request is processed
> +     * using pass-through translation, it will be blocked as described
> +     * in the paragraph below.

While PASID+PT is blocked as described in the below paragraph, the
paragraph itself applies to all situations:

  1) PT + noPASID
  2) translation + noPASID
  3) PT + PASID
  4) translation + PASID

because...

> +     *
> +     * Software must not program paging-structure entries to remap any
> +     * address to the interrupt address range. Untranslated requests
> +     * and translation requests that result in an address in the
> +     * interrupt range will be blocked with condition code LGN.4 or
> +     * SGN.8.

... if you look at the definition of LGN.4 or SGN.8:

LGN.4:	When legacy mode (RTADDR_REG.TTM=00b) is enabled, hardware
	detected an output address (i.e. address after remapping) in the
	interrupt address range (0xFEEx_xxxx). For Translated requests and
	requests with pass-through translation type (TT=10), the output
	address is the same as the address in the request

The last sentence in the first paragraph above just highlights the fact that
when input address of PT is in interrupt range then it is blocked by LGN.4
or SGN.8 due to output address also in interrupt range.

> +     * """
> +     *
> +     * We enable per as memory region (iommu_ir_fault) for catching
> +     * the tranlsation for interrupt range through PASID + PT.
> +     */
> +    if (pt && as->pasid != PCI_NO_PASID) {
> +        memory_region_set_enabled(&as->iommu_ir_fault, true);
> +    } else {
> +        memory_region_set_enabled(&as->iommu_ir_fault, false);
> +    }
> +

Given above this should be a bug fix for nopasid first and then apply it
to pasid path too.

Thanks
Kevin


  parent reply	other threads:[~2022-03-28  7:06 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-21  5:54 [PATCH V2 0/4] PASID support for Intel IOMMU Jason Wang
2022-03-21  5:54 ` [PATCH V2 1/4] intel-iommu: don't warn guest errors when getting rid2pasid entry Jason Wang
2022-03-24  8:21   ` Tian, Kevin
2022-03-28  2:27     ` Jason Wang
2022-03-28  8:53       ` Yi Liu
2022-03-29  4:52         ` Jason Wang
2022-03-30  8:16           ` Tian, Kevin
2022-03-30  8:36             ` Jason Wang
2022-04-02  7:33               ` Tian, Kevin
2022-04-06  3:33                 ` Jason Wang
2022-04-06  3:41                   ` Tian, Kevin
2022-04-22  0:13               ` Peter Xu
2022-04-22  6:24                 ` Jason Wang
2022-04-22  7:57           ` Michael S. Tsirkin
2022-03-21  5:54 ` [PATCH V2 2/4] intel-iommu: drop VTDBus Jason Wang
2022-04-22  1:17   ` Peter Xu
2022-04-22  6:26     ` Jason Wang
2022-04-22 12:55       ` Peter Xu
2022-03-21  5:54 ` [PATCH V2 3/4] intel-iommu: convert VTD_PE_GET_FPD_ERR() to be a function Jason Wang
2022-03-24  8:26   ` Tian, Kevin
2022-03-28  2:27     ` Jason Wang
2022-04-22 13:08   ` Peter Xu
2022-03-21  5:54 ` [PATCH V2 4/4] intel-iommu: PASID support Jason Wang
2022-03-24  8:53   ` Tian, Kevin
2022-03-28  2:31     ` Jason Wang
2022-03-28  6:47       ` Tian, Kevin
2022-03-29  4:46         ` Jason Wang
2022-03-30  8:00           ` Tian, Kevin
2022-03-30  8:32             ` Jason Wang
2022-04-02  7:27               ` Tian, Kevin
2022-04-06  3:31                 ` Jason Wang
2022-04-22 15:03                 ` Peter Xu
2022-04-23 16:51                   ` Michael S. Tsirkin
2022-03-28  7:03   ` Tian, Kevin [this message]
2022-03-29  4:48     ` Jason Wang
2022-03-30  8:02       ` Tian, Kevin
2022-03-30  8:31         ` Jason Wang
2022-04-02  7:24           ` Tian, Kevin
2022-04-06  3:31             ` Jason Wang
2022-03-28  8:45   ` Yi Liu
2022-03-29  4:54     ` Jason Wang
2022-04-01 13:42       ` Yi Liu
2022-04-02  1:52         ` Jason Wang

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=BN9PR11MB527635384D3CD8F0FB4232388C1D9@BN9PR11MB5276.namprd11.prod.outlook.com \
    --to=kevin.tian@intel.com \
    --cc=jasowang@redhat.com \
    --cc=mst@redhat.com \
    --cc=peterx@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=yi.l.liu@intel.com \
    --cc=yi.y.sun@linux.intel.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.