From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:49881) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UNTK5-0004Ei-Tg for qemu-devel@nongnu.org; Wed, 03 Apr 2013 15:26:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UNTK0-0007cP-NJ for qemu-devel@nongnu.org; Wed, 03 Apr 2013 15:26:17 -0400 Received: from mail-db8lp0185.outbound.messaging.microsoft.com ([213.199.154.185]:29361 helo=db8outboundpool.messaging.microsoft.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UNTK0-0007bx-F0 for qemu-devel@nongnu.org; Wed, 03 Apr 2013 15:26:12 -0400 Date: Wed, 3 Apr 2013 14:26:04 -0500 From: Scott Wood References: <1364943035.24520.28@snotra> <1364960240.2882.230.camel@bling.home> In-Reply-To: (from b08248@gmail.com on Wed Apr 3 14:09:45 2013) Message-ID: <1365017164.25627.7@snotra> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; delsp=Yes; format=Flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] RFC: vfio API changes needed for powerpc List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stuart Yoder Cc: Wood Scott-B07421 , "kvm@vger.kernel.org" , "agraf@suse.de" , "iommu@lists.linux-foundation.org" , "qemu-devel@nongnu.org" , Yoder Stuart-B08248 , Alex Williamson , Bhushan Bharat-R65777 On 04/03/2013 02:09:45 PM, Stuart Yoder wrote: > > Would is be possible for userspace to simply leave room for MSI bank > > mapping (how much room could be determined by something like > > VFIO_IOMMU_GET_MSI_BANK_COUNT) then document the API that userspace =20 > can > > DMA_MAP starting at the 0x0 address of the aperture, growing up, and > > VFIO will map banks on demand at the top of the aperture, growing =20 > down? > > Wouldn't that avoid a lot of issues with userspace needing to know > > anything about MSI banks (other than count) and coordinating irq =20 > numbers > > and enabling handlers? >=20 > This is basically option #A in the original proposals sent. I like > this approach, in that it > is simpler and keeps user space mostly out of this...which is > consistent with how things are done > on x86. User space just needs to know how many windows to leave at > the top of the aperture. > The kernel then has the flexibility to use those windows how it wants. >=20 > But one question, is when should the kernel actually map (and unmap) > the MSI banks. One thing we need to do is enable the aperture...and =20 > current > thinking is that is done on the first DMA_MAP. Similarly when the =20 > last mapping > is unmapped we could also umap the MSI banks. >=20 > Sequence would be something like: >=20 > VFIO_GROUP_SET_CONTAINER // add groups to the container >=20 > VFIO_SET_IOMMU(VFIO_FSL_PAMU) // set iommu model >=20 > cnt =3D VFIO_IOMMU_GET_MSI_BANK_COUNT // returns max # of =20 > MSI banks >=20 > VFIO_IOMMU_SET_ATTR(ATTR_GEOMETRY) // set overall aperture >=20 > VFIO_IOMMU_SET_ATTR(ATTR_WINDOWS) // set # of windows, > including MSI banks >=20 > VFIO_IOMMU_MAP_DMA // map the guest's memory > ---> kernel enables aperture and maps needed MSI banks =20 > here Maps them where? What if there is more than one explicit DMA mapping? What if DMA =20 mappings are changed during operation? -Scott=