From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45318) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZcihG-0001fX-4p for qemu-devel@nongnu.org; Thu, 17 Sep 2015 19:34:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZcihF-0001XA-0H for qemu-devel@nongnu.org; Thu, 17 Sep 2015 19:34:34 -0400 Date: Fri, 18 Sep 2015 09:34:36 +1000 From: David Gibson Message-ID: <20150917233436.GD2547@voom.fritz.box> References: <1442495357-26547-1-git-send-email-david@gibson.dropbear.id.au> <1442495357-26547-9-git-send-email-david@gibson.dropbear.id.au> <1442508878.23936.209.camel@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="h+CsNYkJBPxpZ+B/" Content-Disposition: inline In-Reply-To: <1442508878.23936.209.camel@redhat.com> Subject: Re: [Qemu-devel] [RFC PATCH 08/10] spapr_iommu: Rename vfio_accel parameter List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Williamson Cc: lvivier@redhat.com, thuth@redhat.com, aik@ozlabs.ru, gwshan@linux.vnet.ibm.com, qemu-devel@nongnu.org, qemu-ppc@nongnu.org, pbonzini@redhat.com --h+CsNYkJBPxpZ+B/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 17, 2015 at 10:54:38AM -0600, Alex Williamson wrote: > On Thu, 2015-09-17 at 23:09 +1000, David Gibson wrote: > > The vfio_accel parameter used when creating a new TCE table (guest IOMMU > > context) has a confusing name. What it really means is whether we need= the > > TCE table created to be able to support VFIO devices. > >=20 > > VFIO is relevant, because when available we use in-kernel acceleration = of > > the TCE table, but that may not work with VFIO devices because updates = to > > the table are handled in kernel, bypass qemu and so don't hit qemu's > > infrastructure for keeping the VFIO host IOMMU state in sync with the g= uest > > IOMMU state. > >=20 > > Rename the parameter to "need_vfio" throughout. This is a cosmetic cha= nge, > > with no impact on the logic. > > There's a capability >=20 > nit, why entangle the technology you're using, vfio, with the feature > you want, visible iommu updates? You could rename this to something > even more self describing, like disable_in_kernel_updates, or whatever > more concise name you can come up with. Because vfio availability really is the feature I want. If the kernel gains the ability to wire up the KVM TCE acceleration with VFIO (which I believe is in IBM's plans), then the idea is that spapr_tce_new_table() will return an accelerated table, even when VFIO is requested. Same thing with spapr_tce_need_vfio(). --=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 --h+CsNYkJBPxpZ+B/ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJV+04LAAoJEGw4ysog2bOSbQAQAIa+ktHkiu6XoGaGZrO1DWM6 1+qFTEim9ciBf1miFkC+ZrF0wyjGd/41Mrg1I59dnY8Xs91Fz5d7ztyIUAYW2nh/ /+sOhjXBhaaGCh+BTd92b2pHnM8/kBCfUzwJZsaIBBXxj3I/tqxnn2ejo65/HrAA ZW8GgW9UE23wgpOcleLS3fbldzstViiXkP9RRZeNsuPs2SPki9Ejv/6G7i600iSC XJVeUN/FpRa5E3fpBlnsBv87blzkxg39R+RQnJbM0xezRmNByBb3lJC/+ydiiAOE GWdHS5yWGo4yDeXZT3sYZgrHJXsjU9iszw+06ipgaTL2GG9bLlDEVWhzXiPz7fGj RPpfQEQ/LDz0HsAqj/7oJ1W/HBvbSQ3YWYNW1jZlUGYySufXsMmVmbYAVLFf3vFv LKlX7Vs1dfEGem1EO4FY0Oi+mnQL8FFwUypqsAJXQBcd95jKEvjch9h7bwTyclIo nNqj/ilPVrdosFv6WrhWIbIRMEEJWbW8nblljFa7913wBUp/P+0ssAh8JOqlvmIn HWw3QU2+b0Lea9pXzP3OBdHrjnQ1Fdp0rjLUQxzhcVDNHDvTUgNA/GcgT0xfF5iD C5QoLsNNtXlFe3zRxyIYK0pFnQupCE5yTVYdJERZyDjU03Gobqp7xOLFvD0evGMD u5FNejTuUQQA+Zj6KuID =+UqQ -----END PGP SIGNATURE----- --h+CsNYkJBPxpZ+B/--