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;
IronPort-SDR: Hij/irYef87fysAYCFJDcl7PUqZuPgHU1xNAbt0z1yBrQ9UkqHFoRbf7J8OMohHc/+S6KIHEzP
 4lZhgeGtIxrw==
IronPort-SDR: 5st/krb4mnb56RqNJPOOYNchg952TWwOtMoHp3kXcXslXXaMeuaLz0zmje7Lrr8a066nRafB1l
 kZ5WfSeueEnA==
From:   "Tian, Kevin" <kevin.tian@intel.com>
To:     David Gibson <david@gibson.dropbear.id.au>
CC:     Jean-Philippe Brucker <jean-philippe@linaro.org>,
        "Jiang, Dave" <dave.jiang@intel.com>,
        "Raj, Ashok" <ashok.raj@intel.com>,
        "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
        Jonathan Corbet <corbet@lwn.net>,
        David Woodhouse <dwmw2@infradead.org>,
        Jason Wang <jasowang@redhat.com>,
        LKML <linux-kernel@vger.kernel.org>,
        Kirti Wankhede <kwankhede@nvidia.com>,
        "Alex Williamson (alex.williamson@redhat.com)" 
        <alex.williamson@redhat.com>,
        "iommu@lists.linux-foundation.org" <iommu@lists.linux-foundation.org>,
        Jason Gunthorpe <jgg@nvidia.com>,
        "Robin Murphy" <robin.murphy@arm.com>
Subject: RE: [RFC] /dev/ioasid uAPI proposal
Thread-Topic: [RFC] /dev/ioasid uAPI proposal
Thread-Index: AddSzQ970oLnVHLeQca/ysPD8zMJZwBGs/UAALTRUxAAFJZWgAAQLFRgAB7cjgAAE0ZXYAAH9s4AAANRJjAA7xYlAAA2jyxw
Date:   Wed, 9 Jun 2021 02:52:53 +0000
Message-ID: <MWHPR11MB18864D52718BD84E32F7E1B78C369@MWHPR11MB1886.namprd11.prod.outlook.com>
References: <MWHPR11MB1886422D4839B372C6AB245F8C239@MWHPR11MB1886.namprd11.prod.outlook.com>
 <20210528173538.GA3816344@nvidia.com>
 <MWHPR11MB18866C362840EA2D45A402188C3E9@MWHPR11MB1886.namprd11.prod.outlook.com>
 <20210601174229.GP1002214@nvidia.com>
 <MWHPR11MB1886283575628D7A2F4BFFAB8C3D9@MWHPR11MB1886.namprd11.prod.outlook.com>
 <20210602160914.GX1002214@nvidia.com>
 <MWHPR11MB18861FA1636BFB66E5E563508C3C9@MWHPR11MB1886.namprd11.prod.outlook.com>
 <YLhj9mi9J/f+rqkP@yekko>
 <MWHPR11MB1886E929BD1414817E9247898C3C9@MWHPR11MB1886.namprd11.prod.outlook.com>
 <YL6+tBc+Xq7pgb/z@yekko>
In-Reply-To: <YL6+tBc+Xq7pgb/z@yekko>
Accept-Language: en-US
Content-Language: en-US
dlp-version: 11.5.1.3
dlp-product: dlpe-windows
dlp-reaction: no-action
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?jDB1je4QP+a7xemHZsnM9Sa4sHPsrddwp2Yk6jAHY3v+CxCVcFW5CzrW10zB?=
 =?us-ascii?Q?Cn3d3xznAZRIGWq91wrb4ETc96Tdynn815fK5VD2QzP5KT4cCOpt6KnNzxvl?=
 =?us-ascii?Q?STnazBr5wxi1GPwl0Kf7SAcToA4Iu/zR6KUHemJOtY5Cd18y2xeTW67+Ao6l?=
 =?us-ascii?Q?6Zewk8/WRoe2FbHvk4SN2ppCsv0Y6ss93XLl7fZv3a+KsHmcvsVqbQGkHsZG?=
 =?us-ascii?Q?mgbSG0fql9KdXH9CxR5SLHe2ACskSHi8JgRqMG0tXOAUU3qBH0GuJofvEOHl?=
 =?us-ascii?Q?unQ/VtPIUJCC/eWOR1WzOJLlaKX3YYuN5hDKKy8s7WazDQJgPe31qyBph3WK?=
 =?us-ascii?Q?VZu8lz+o0qFsyiov859T++OL3AZPt9qtkEPpkQNjqsUxDMloegmobkxrlOgj?=
 =?us-ascii?Q?Zn8CX5IfHKQL9d2erwY772epJ8/oMgvxZo8VPUy1XFevyCRgOIaG0AMB1oFc?=
 =?us-ascii?Q?MCWSD7LgvJwd/5gw77JP7GyfAift0jxUwfhJS2M5Q21cCpHkN7BlYDiPkLu+?=
 =?us-ascii?Q?FhFBO9BZx46FanTlTiaPLW/mXBWRWa4CoFDVdTz4ajmjDEevT8d+aZn7spjG?=
 =?us-ascii?Q?RwDTMAM6G5uzjbMMx+McM0U7h5D0W8llCaS4zEgAj/kI+z+WdRWXaadRlPik?=
 =?us-ascii?Q?o6WFXDqa7kLy5gNKjAZ8n7YI2Z8aZy/CEK+zgPgOzRTM3kK2kNlQCTWEIF/r?=
 =?us-ascii?Q?3uWit49qpD+FWvgVjtc/ShcuClb7yqI1kU5UUbNiMm3f1j8+ZXs48cZ86La4?=
 =?us-ascii?Q?fDvagZhplBxK0vyfCf+JrmUqeAr5Fsivr0TLYQIYmYzIhXub9sPg3q9DvAMA?=
 =?us-ascii?Q?YWp1T3vbgNnskt93/uTr+LdttoecHxIKRQaYGQhYy4YrQJfvofiYueAEP81z?=
 =?us-ascii?Q?qeToAQvX4GZ2D7TTeFVf1nTn+CWMklXZwxs0lPwR8enmSySvXQuLNmJIkohb?=
 =?us-ascii?Q?Sgq7Cb3rrtQgHj6n4rYBn2hQGD7+F1W+rBQrR8+ctziDzlCRoNjIIskbOTCR?=
 =?us-ascii?Q?jMz+YOcvpE2Ygl+3uIWhnanA0V9Ck25yjEXpP+6hb9uOken9jKIjddATk3D+?=
 =?us-ascii?Q?NM8AD17zxJJI5wpt7sTqGQxwarLmUJZYGD9Icd8MAKmKBa4RWcByWRsK98D+?=
 =?us-ascii?Q?qrErnbMq0uuhi/ebJsLorX9PsgbzkanwKUJ9V4KNx4eAwpTHwfqRRix82qPZ?=
 =?us-ascii?Q?NbqbL++faRFRM9iG+v2E6lFgz8rVITiuGff+I3qVoqGGA/r2RVbXr2/bCyD/?=
 =?us-ascii?Q?A7qd6LyDn4hlETKAecjmUiHrHoBZRaMsKiXjZTQs+uZiT1q0BPex3JCxq5tI?=
 =?us-ascii?Q?i4rV9czs8cgMA2ImRtXi00j7?=
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: MWHPR11MB1886.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6a16ce82-09dd-4a3f-9f23-08d92af1ae01
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jun 2021 02:52:53.8755
 (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: fbGudecMqLrZxeQSy/tAKemdmy0WV80AkSFPQg2Y3rDZdcb5eMSyntU+/IQDbWbTakrsBsQzqFPdL/QXxL9K5w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR11MB4852
X-OriginatorOrg: intel.com
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

> From: David Gibson <david@gibson.dropbear.id.au>
> Sent: Tuesday, June 8, 2021 8:50 AM
>=20
> On Thu, Jun 03, 2021 at 06:49:20AM +0000, Tian, Kevin wrote:
> > > From: David Gibson
> > > Sent: Thursday, June 3, 2021 1:09 PM
> > [...]
> > > > > In this way the SW mode is the same as a HW mode with an infinite
> > > > > cache.
> > > > >
> > > > > The collaposed shadow page table is really just a cache.
> > > > >
> > > >
> > > > OK. One additional thing is that we may need a 'caching_mode"
> > > > thing reported by /dev/ioasid, indicating whether invalidation is
> > > > required when changing non-present to present. For hardware
> > > > nesting it's not reported as the hardware IOMMU will walk the
> > > > guest page table in cases of iotlb miss. For software nesting
> > > > caching_mode is reported so the user must issue invalidation
> > > > upon any change in guest page table so the kernel can update
> > > > the shadow page table timely.
> > >
> > > For the fist cut, I'd have the API assume that invalidates are
> > > *always* required.  Some bypass to avoid them in cases where they're
> > > not needed can be an additional extension.
> > >
> >
> > Isn't a typical TLB semantics is that non-present entries are not
> > cached thus invalidation is not required when making non-present
> > to present?
>=20
> Usually, but not necessarily.
>=20
> > It's true to both CPU TLB and IOMMU TLB.
>=20
> I don't think it's entirely true of the CPU TLB on all ppc MMU models
> (of which there are far too many).
>=20
> > In reality
> > I feel there are more usages built on hardware nesting than software
> > nesting thus making default following hardware TLB behavior makes
> > more sense...
>=20
> I'm arguing for always-require-invalidate because it's strictly more
> general.  Requiring the invalidate will support models that don't
> require it in all cases; we just make the invalidate a no-op.  The
> reverse is not true, so we should tackle the general case first, then
> optimize.
>=20

It makes sense. Will adopt this way.