All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Jason Wang <jasowang@redhat.com>, "Liu, Yi L" <yi.l.liu@intel.com>
Cc: "yi.y.sun@linux.intel.com" <yi.y.sun@linux.intel.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"peterx@redhat.com" <peterx@redhat.com>,
	"mst@redhat.com" <mst@redhat.com>
Subject: RE: [PATCH V2 1/4] intel-iommu: don't warn guest errors when getting rid2pasid entry
Date: Wed, 30 Mar 2022 08:16:17 +0000	[thread overview]
Message-ID: <BN9PR11MB5276C1513B8DD829CC87EE898C1F9@BN9PR11MB5276.namprd11.prod.outlook.com> (raw)
In-Reply-To: <d04f5de3-9e66-9bdb-b268-b7b64c8489bd@redhat.com>

> From: Jason Wang <jasowang@redhat.com>
> Sent: Tuesday, March 29, 2022 12:52 PM
> >
> >>>
> >>> Currently the implementation of vtd_ce_get_rid2pasid_entry() is also
> >>> problematic. According to VT-d spec, RID2PASID field is effective only
> >>> when ecap.rps is true otherwise PASID#0 is used for RID2PASID. I didn't
> >>> see ecap.rps is set, neither is it checked in that function. It
> >>> works possibly
> >>> just because Linux currently programs 0 to RID2PASID...
> >>
> >> This seems to be another issue since the introduction of scalable mode.
> >
> > yes. this is not introduced in this series. The current scalable mode
> > vIOMMU support was following 3.0 spec, while RPS is added in 3.1. Needs
> > to be fixed.
> 
> 
> Interesting, so this is more complicated when dealing with migration
> compatibility. So what I suggest is probably something like:
> 
> -device intel-iommu,version=$version
> 
> Then we can maintain migration compatibility correctly. For 3.0 we can
> go without RPS and 3.1 and above we need to implement RPS.

This is sensible. Probably a new version number is created only when
it breaks compatibility with an old version, i.e. not necessarily to follow
every release from VT-d spec. In this case we definitely need one from
3.0 to 3.1+ given RID2PASID working on a 3.0 implementation will 
trigger a reserved fault due to RPS not set on a 3.1 implementation.

> 
> Since most of the advanced features has not been implemented, we may
> probably start just from 3.4 (assuming it's the latest version). And all
> of the following effort should be done for 3.4 in order to productize it.
> 

Agree. btw in your understanding is intel-iommu in a production quality
now? If not, do we want to apply this version scheme only when it
reaches the production quality or also in the experimental phase?

Thanks
Kevin

  reply	other threads:[~2022-03-30  8:53 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 [this message]
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
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=BN9PR11MB5276C1513B8DD829CC87EE898C1F9@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.