Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   "Tian, Kevin" <kevin.tian@intel.com>
To:     Jean-Philippe Brucker <jean-philippe@linaro.org>,
        David Gibson <david@gibson.dropbear.id.au>
CC:     Jason Gunthorpe <jgg@nvidia.com>, "Liu, Yi L" <yi.l.liu@intel.com>,
        "alex.williamson@redhat.com" <alex.williamson@redhat.com>,
        "hch@lst.de" <hch@lst.de>,
        "jasowang@redhat.com" <jasowang@redhat.com>,
        "joro@8bytes.org" <joro@8bytes.org>,
        "parav@mellanox.com" <parav@mellanox.com>,
        "lkml@metux.net" <lkml@metux.net>,
        "pbonzini@redhat.com" <pbonzini@redhat.com>,
        "lushenming@huawei.com" <lushenming@huawei.com>,
        "eric.auger@redhat.com" <eric.auger@redhat.com>,
        "corbet@lwn.net" <corbet@lwn.net>,
        "Raj, Ashok" <ashok.raj@intel.com>,
        "yi.l.liu@linux.intel.com" <yi.l.liu@linux.intel.com>,
        "Tian, Jun J" <jun.j.tian@intel.com>, "Wu, Hao" <hao.wu@intel.com>,
        "Jiang, Dave" <dave.jiang@intel.com>,
        "jacob.jun.pan@linux.intel.com" <jacob.jun.pan@linux.intel.com>,
        "kwankhede@nvidia.com" <kwankhede@nvidia.com>,
        "robin.murphy@arm.com" <robin.murphy@arm.com>,
        "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
        "iommu@lists.linux-foundation.org" <iommu@lists.linux-foundation.org>,
        "dwmw2@infradead.org" <dwmw2@infradead.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "baolu.lu@linux.intel.com" <baolu.lu@linux.intel.com>,
        "nicolinc@nvidia.com" <nicolinc@nvidia.com>
Subject: RE: [RFC 11/20] iommu/iommufd: Add IOMMU_IOASID_ALLOC/FREE
Thread-Topic: [RFC 11/20] iommu/iommufd: Add IOMMU_IOASID_ALLOC/FREE
Thread-Index: AQHXrSGPLoYXtOF3o0iA7Cse+/LM66uuxm8AgA72WACAAGbxgIAPTQiAgAAu7ICAAwY+cA==
Date:   Wed, 13 Oct 2021 07:07:34 +0000
Message-ID: <BN9PR11MB54333A0E5C7BD4F8996693278CB79@BN9PR11MB5433.namprd11.prod.outlook.com>
References: <20210919063848.1476776-1-yi.l.liu@intel.com>
 <20210919063848.1476776-12-yi.l.liu@intel.com>
 <20210921174438.GW327412@nvidia.com> <YVanJqG2pt6g+ROL@yekko>
 <20211001122225.GK964074@nvidia.com> <YWPTWdHhoI4k0Ksc@yekko>
 <YWP6tblC2+/2RQtN@myrica>
In-Reply-To: <YWP6tblC2+/2RQtN@myrica>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?gu6maqNeQZqaGbSSyOtFWTA1bFf+F42iXGI6sTmlxzHCZFySaLVoMItYgR88?=
 =?us-ascii?Q?Ow8+I5rOFFS2wNzK13TwQrf4id2Whw7JkrFS8cNvPBbUvwkFZBOtohgyx38r?=
 =?us-ascii?Q?LKXtHf3JN9K3ekgIX9cY/Z2GhZiIlZDoY65gHnnbZN3xVsoXhjc+Y1E5k3vX?=
 =?us-ascii?Q?VVDubPA4bJynQP2XDa189kddERaK+SeRgKGKZrgblfA5eLaBkBGJIBbnKRmQ?=
 =?us-ascii?Q?5T5VYLxWQwfpezAeUVv3mid1LmqOPAgDoCc0EEZkgozdh2r9HUmTgroIVPOz?=
 =?us-ascii?Q?bp3IPo32A5ahxXmvNZW68ur4eSAPUWU5pKZ6dSH83HdP5E8GRORQBS1NFafS?=
 =?us-ascii?Q?V3TmFWbaiUzRm4b5J8Y1gDcnwP03sI1gW1ZadnanCLGADOx4Am8tbqPLXEd5?=
 =?us-ascii?Q?yZVbFgVlgCZGPgCZhaQocPnbYd7wYzcTUpeGzMJum9vxQtVK8/fgF22GE3Vr?=
 =?us-ascii?Q?GA2JNOg4WpLiDNjERuo2KZ/blshHKrzi0pyWximHZFxA2IfrjpJoNAKl8KrE?=
 =?us-ascii?Q?BjrDJn4n2G9QcX2pfr5QHdcUWI+ZmrpGAgAOEmpSh3PNHb56NjxDgx6qu9Jg?=
 =?us-ascii?Q?XQQrf/wDEKo4X2Xmx1uiNmqIBCYEqLmq51wLjwzjBdx4DzBucZ02396q/Hmh?=
 =?us-ascii?Q?63Kt7pzeVRTlSOdwmh791WMxiqdUky9Khr9Ql3zc1SpRktnBS4qgWjxK0ef0?=
 =?us-ascii?Q?bPB/QCO+N7/UZB6/XgLtYjUOk7YoYf4suz9rfig6Hp7f+TzauG5d2oObPczH?=
 =?us-ascii?Q?/QC0tyZuYhGpctOQfl5g6ZLUyOdQXuwGIQ/qx2O+CkSNYqOHqryBRiPZp8ZR?=
 =?us-ascii?Q?jfs2VcFRZzXh170G29XtL0Nm1sWi1/xqnh11QmtjLOcgLHXIwL0nvaGStTa6?=
 =?us-ascii?Q?5+Jkh6JubQLvmM06dEo+Mggu7X2qPpdBRuwLJI03K1AixCNpU2lIx5fTyQP7?=
 =?us-ascii?Q?alv3Csct+LF0eEEOtrocdM2AJRoBStbXF73h+ElZgT1+cw1gIpcx7zXajnpS?=
 =?us-ascii?Q?GVb3gDo68F7U2wDp+5MTG8oEj0j5v1unHDK8dX/KGmvEwXo29rF0gnJBLdUm?=
 =?us-ascii?Q?fWV/YgIJeu5mB1vCzeomQyMt34ddxr8ILzTX6PiIuwpJzmfr4UFnJg/UZS0C?=
 =?us-ascii?Q?r1uqd988fRx4rgBegWidVc0AVxtXkXcZSVzMMcXRfIrs6mZ41/6oFD3cYKeB?=
 =?us-ascii?Q?x/CXw2iWQuhyaQK9ItRNEF0v0/t2XBUtCwZkpWmD6I3nWo/aaDRva3OjmPaw?=
 =?us-ascii?Q?V70q1tK3GJJoUIx3msbFTbNixshthpqFTQkj61DFOFDyEvtpu0UgBgt94/CE?=
 =?us-ascii?Q?EN6PEAfIeeEUGSaZRzVd5RXR?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN9PR11MB5433.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 29f9d70e-c145-4a3d-c0f5-08d98e1821cf
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2021 07:07:34.6472
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 7S1lUVn4eLUR+WjEI62zeN+KPe/vdxVx5WsElOhcu9uEPC92rvJC5lVfNES35BKn99FcK4//dMsgKiBgl9SVJg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB1938
X-OriginatorOrg: intel.com
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

> From: Jean-Philippe Brucker <jean-philippe@linaro.org>
> Sent: Monday, October 11, 2021 4:50 PM
>=20
> On Mon, Oct 11, 2021 at 05:02:01PM +1100, David Gibson wrote:
> > qemu wants to emulate a PAPR vIOMMU, so it says (via interfaces yet to
> > be determined) that it needs an IOAS where things can be mapped in the
> > range 0..2GiB (for the 32-bit window) and 2^59..2^59+1TiB (for the
> > 64-bit window).
> >
> > Ideally the host /dev/iommu will say "ok!", since both those ranges
> > are within the 0..2^60 translated range of the host IOMMU, and don't
> > touch the IO hole.  When the guest calls the IO mapping hypercalls,
> > qemu translates those into DMA_MAP operations, and since they're all
> > within the previously verified windows, they should work fine.
>=20
> Seems like we don't need the negotiation part?  The host kernel
> communicates available IOVA ranges to userspace including holes (patch
> 17), and userspace can check that the ranges it needs are within the IOVA
> space boundaries. That part is necessary for DPDK as well since it needs
> to know about holes in the IOVA space where DMA wouldn't work as
> expected
> (MSI doorbells for example). And there already is a negotiation happening=
,
> when the host kernel rejects MAP ioctl outside the advertised area.
>=20

Agree. This can cover the ppc platforms with fixed reserved ranges.
It's meaningless to have user further tell kernel that it is only willing
to use a subset of advertised area. for ppc platforms with dynamic
reserved ranges which are claimed by user, we can leave it out of
the common set and handled in a different way, either leveraging
ioas nesting if applied or having ppc specific cmd.

Thanks
Kevin