From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=3.0 tests=BAYES_00,DATE_IN_PAST_03_06, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7758AC49361 for ; Thu, 17 Jun 2021 07:22:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5B20C613B9 for ; Thu, 17 Jun 2021 07:22:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230383AbhFQHY0 (ORCPT ); Thu, 17 Jun 2021 03:24:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52576 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230184AbhFQHYS (ORCPT ); Thu, 17 Jun 2021 03:24:18 -0400 Received: from ozlabs.org (ozlabs.org [IPv6:2401:3900:2:1::2]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 17A9AC061574; Thu, 17 Jun 2021 00:22:11 -0700 (PDT) Received: by ozlabs.org (Postfix, from userid 1007) id 4G5D5W5rs3z9sWH; Thu, 17 Jun 2021 17:22:07 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gibson.dropbear.id.au; s=201602; t=1623914527; bh=tFVUtNbdZ+Fw5LYQ7mSmAwqiFoN6XF0MqDJ61aM3Yrg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ScwxV0RsYOHqcnlffmG1ZaoGQ2430eMxloExqv65ydVRdbmXlOoaDWQfCKUvUquBL yUFFdOaIgV275bfscZF39oYoyHvQiUNdD/DCfOArYOdFZ7eGMcldGgRsonWclzUPtd Rw2uY4AqHpHww6Q7+gawy0lPus+exB4r67vDky4g= Date: Thu, 17 Jun 2021 14:07:46 +1000 From: David Gibson To: "Tian, Kevin" Cc: LKML , Joerg Roedel , Jason Gunthorpe , Lu Baolu , David Woodhouse , "iommu@lists.linux-foundation.org" , "kvm@vger.kernel.org" , "Alex Williamson (alex.williamson@redhat.com)" , Jason Wang , Eric Auger , Jonathan Corbet , "Raj, Ashok" , "Liu, Yi L" , "Wu, Hao" , "Jiang, Dave" , Jacob Pan , Jean-Philippe Brucker , Kirti Wankhede , Robin Murphy Subject: Re: [RFC] /dev/ioasid uAPI proposal Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="gK7m5XMN4F+it+mS" Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --gK7m5XMN4F+it+mS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 03, 2021 at 08:12:27AM +0000, Tian, Kevin wrote: > > From: David Gibson > > Sent: Wednesday, June 2, 2021 2:15 PM > > > [...] > =20 > > > > > > /* > > > * Get information about an I/O address space > > > * > > > * Supported capabilities: > > > * - VFIO type1 map/unmap; > > > * - pgtable/pasid_table binding > > > * - hardware nesting vs. software nesting; > > > * - ... > > > * > > > * Related attributes: > > > * - supported page sizes, reserved IOVA ranges (DMA mapping); > >=20 > > Can I request we represent this in terms of permitted IOVA ranges, > > rather than reserved IOVA ranges. This works better with the "window" > > model I have in mind for unifying the restrictions of the POWER IOMMU > > with Type1 like mapping. >=20 > Can you elaborate how permitted range work better here? Pretty much just that MAP operations would fail if they don't entirely lie within a permitted range. So, for example if your IOMMU only implements say, 45 bits of IOVA, then you'd have 0..0x1fffffffffff as your only permitted range. If, like the POWER paravirtual IOMMU (in defaut configuration) you have a small (1G) 32-bit range and a large (45-bit) 64-bit range at a high address, you'd have say: 0x00000000..0x3fffffff (32-bit range) and 0x800000000000000 .. 0x8001fffffffffff (64-bit range) as your permitted ranges. If your IOMMU supports truly full 64-bit addressing, but has a reserved range (for MSIs or whatever) at 0xaaaa000..0xbbbb0000 then you'd have permitted ranges of 0..0xaaa9ffff and 0xbbbb0000..0xffffffffffffffff. [snip] > > For debugging and certain hypervisor edge cases it might be useful to > > have a call to allow userspace to lookup and specific IOVA in a guest > > managed pgtable. >=20 > Since all the mapping metadata is from userspace, why would one=20 > rely on the kernel to provide such service? Or are you simply asking > for some debugfs node to dump the I/O page table for a given=20 > IOASID? I'm thinking of this as a debugging aid so you can make sure that how the kernel is interpreting that metadata in the same way that your userspace expects it to interpret that metadata. --=20 David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson --gK7m5XMN4F+it+mS Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEdfRlhq5hpmzETofcbDjKyiDZs5IFAmDKypAACgkQbDjKyiDZ s5KJ2RAAyi8TAl1qgdNgAf5wIGmOThtFfEghnObAGDxj+Jk30YI5r5tFLn1kX/ub vWiXHGBSWYWqixxkkpepzvDI+uT/PziBrUJFP2b/sdvxEwfNNXPV08Df2y5gruUb Oz6a2lqBelPjWI95H1fbtBn3sBQCTQoL1E35Ft9tcT6F/GPDZo9JUHlp1tuinJt8 lCkIMjvpgcefvh67yiQdnz0SRJunnn45WYK2KHQbyDHvpYuyPmRHQ6xz8iuDttO4 q+vssdbEqMA3doxWedxvmdNr9SE+Dm6ISpSdFvvy6I1O9CsThFAzsKkHyf5NBLQy ttSSroxg5sqPPYqHznZlg7bG0fjxsDdYkzo66FPP2WtVmJTmKBet54HY+MQsR1do gHZtCz+KGHBBLONRkHn5SSAwnjbUgv8+KTGmo92lCUI0PmBWta1L9s9CFG0sCiXn f64/CNc/134/PtjDgrh3N5mFxlAKKkV6y7j/DJ0dMF7Bid001DTKC7WbVvrxTxxB j7yo3I/jqxG4t5JelMN67wAFnRfM74N7SkyfhyL9E2oE92NHxGhwAdi8YPLNQf7L 4IbhKPz3q7tb34hDfRo9koANkQ09mkbNSGZTREXdRCrcevn69NyPk1jAmsUTt50M seWfdBaV6WXG1qEVBPJidolTU71ErZRpvlV1JsZr6LD4qudwkaU= =OGRh -----END PGP SIGNATURE----- --gK7m5XMN4F+it+mS--