From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40760) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7HwX-0005rf-AO for qemu-devel@nongnu.org; Tue, 23 Jun 2015 02:44:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z7HwS-0007ab-I4 for qemu-devel@nongnu.org; Tue, 23 Jun 2015 02:44:25 -0400 Date: Tue, 23 Jun 2015 16:44:42 +1000 From: David Gibson Message-ID: <20150623064442.GC13352@voom.redhat.com> References: <1434627456-13745-1-git-send-email-aik@ozlabs.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="t68BHbxK7znCsyk3" Content-Disposition: inline In-Reply-To: <1434627456-13745-1-git-send-email-aik@ozlabs.ru> Subject: Re: [Qemu-devel] [PATCH qemu v8 00/14] spapr: vfio: Enable Dynamic DMA windows (DDW) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexey Kardashevskiy Cc: Alex Williamson , qemu-ppc@nongnu.org, qemu-devel@nongnu.org, Gavin Shan , Alexander Graf --t68BHbxK7znCsyk3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 18, 2015 at 09:37:22PM +1000, Alexey Kardashevskiy wrote: >=20 > (cut-n-paste from kernel patchset) >=20 > Each Partitionable Endpoint (IOMMU group) has an address range on a PCI b= us > where devices are allowed to do DMA. These ranges are called DMA windows. > By default, there is a single DMA window, 1 or 2GB big, mapped at zero > on a PCI bus. >=20 > PAPR defines a DDW RTAS API which allows pseries guests > querying the hypervisor about DDW support and capabilities (page size mask > for now). A pseries guest may request an additional (to the default) > DMA windows using this RTAS API. > The existing pseries Linux guests request an additional window as big as > the guest RAM and map the entire guest window which effectively creates > direct mapping of the guest memory to a PCI bus. >=20 > This patchset reworks PPC64 IOMMU code and adds necessary structures > to support big windows. >=20 > Once a Linux guest discovers the presence of DDW, it does: > 1. query hypervisor about number of available windows and page size masks; > 2. create a window with the biggest possible page size (today 4K/64K/16M); > 3. map the entire guest RAM via H_PUT_TCE* hypercalls; > 4. switche dma_ops to direct_dma_ops on the selected PE. >=20 > Once this is done, H_PUT_TCE is not called anymore for 64bit devices and > the guest does not waste time on DMA map/unmap operations. >=20 > Note that 32bit devices won't use DDW and will keep using the default > DMA window so KVM optimizations will be required (to be posted later). >=20 > This patchset adds DDW support for pseries. The host kernel changes are > required, posted as: >=20 > [PATCH kernel v11 00/34] powerpc/iommu/vfio: Enable Dynamic DMA windows >=20 > This patchset is based on git://github.com/dgibson/qemu.git spapr-next br= anch. A couple of general queries - this touchs on the kernel part as well as the qemu part: * Am I correct in thinking that the point in doing the pre-registration stuff is to allow the kernel to handle PUT_TCE in real mode? i.e. that the advatage of doing preregistration rather than accounting on the DMA_MAP and DMA_UNMAP itself only appears once you have kernel KVM+VFIO acceleration? * Do you have test numbers to show that it's still worthwhile to have kernel acceleration once you have a guest using DDW? With DDW in play, even if PUT_TCE is slow, it should be called a lot less often. The reason I ask is that the preregistration handling is a pretty big chunk of code that inserts itself into some pretty core kernel data structures, all for one pretty specific use case. We only want to do that if there's a strong justification for it. --=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 --t68BHbxK7znCsyk3 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJViQBaAAoJEGw4ysog2bOSEJAP+wabiUHlCYr0M3OFCa98gXA0 /L4pPCxaY1DBrC5CUoTfuT0wmvbzDVq/iBhW8rvCadsRucc1M8OXGf3ERUxmjwcG 8NtUMIhnDf3PI7JnScgXxPcjF61oCotoUoq9lPWQyJFH0MoDLqudRc9ULraW0k1C tNsmTrB46kvHPEWvVma2l0lzwBp5wac01dZqdIhoPvb9mgNStWmtZYRfVlfV1iA1 fkWeiC+Wj10mj79cJxuv1J2HDkU6kqAthtLTTI0+EraQrM/Pu9tqF7y9iOEANss0 YTELklWOWvH7zKbiFu8HAw0ogq1UcRfy5EABBuRTTpY0Vl8hUaBra4WasM3rhi+p C7UhXES93oGjKEcHNZQpJoWP8s8aoMPHWKAHiPYCfyljIAJbBeMs5lho581tQJLS 2KfNhCC+i0aYxceORIKnrpLETy/MaAXpqmC5kYb4uBJYjmNi7S0in6tGA1AeiPeF QI2TGbKvQd/aAXECtXcWA0Nq2CimPugdc5hzNSkjoLdaf7xrqDZ613TAk1sWh1XJ q0RU8E9tzZ0t2XiqvtKX3bz2sEagCH20sZZhIeOZUN53KfO+7QwbQZPwVvyuXTud a9CnQSxRHf8OWSmVwgN4DfcOUb8sey/zZ8VU4A1nZvBUgN/GfqTh4JApfm5tc+sW KnYeEHvq+rKP3sRO0YPd =os8w -----END PGP SIGNATURE----- --t68BHbxK7znCsyk3--