From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:37377) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SokQf-0006wk-CA for qemu-devel@nongnu.org; Tue, 10 Jul 2012 20:05:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SokQd-0006Tq-Kd for qemu-devel@nongnu.org; Tue, 10 Jul 2012 20:05:16 -0400 Message-ID: <1341965092.18850.11.camel@pasglop> From: Benjamin Herrenschmidt Date: Wed, 11 Jul 2012 10:04:52 +1000 In-Reply-To: <4FFCC0DE.7060400@ozlabs.ru> References: <1341899497-23265-1-git-send-email-aik@ozlabs.ru> <1341899497-23265-3-git-send-email-aik@ozlabs.ru> <4FFCAC0D.4040800@freescale.com> <4FFCC0DE.7060400@ozlabs.ru> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 2/2] vfio-powerpc: added VFIO support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexey Kardashevskiy Cc: Alexander Graf , qemu-devel@nongnu.org, Alex Williamson , qemu-ppc@nongnu.org, Scott Wood , David Gibson On Wed, 2012-07-11 at 09:55 +1000, Alexey Kardashevskiy wrote: > On 11/07/12 08:26, Scott Wood wrote: > > On 07/10/2012 12:51 AM, Alexey Kardashevskiy wrote: > >> The patch enables VFIO on POWER. > >> > >> It literally does the following: > >> > >> 1. POWERPC IOMMU support (the kernel counterpart is required) > > [snip] > >> +/* -------- API for POWERPC IOMMU -------- */ > >> + > >> +#define POWERPC_IOMMU 2 > >> + > >> +struct tce_iommu_info { > >> + __u32 argsz; > >> + __u32 dma32_window_start; > >> + __u32 dma32_window_size; > >> +}; > >> + > >> +#define POWERPC_IOMMU_GET_INFO _IO(VFIO_TYPE, VFIO_BASE + 12) > > > > Is there a more specific name that could be used for this? Not all > > PowerPC chips have the same kind of IOMMU. > > Ben, is is SPAPR? BOOK3S? So we have varieties of different iommus in the kernel indeed, we probably want the info ioctl to reflect that. I would call this one spapr_tce. Also we will want a few other things, dunno if that's reflected here, or whether the ioctl is easily extendable, but in the long run we will need: - Ways to tell KVM about association between a liobn (logical bus number as used in H_PUT_TCE) and an iommu so we can implement the real mode H_PUT_TCE properly. - We will need some conduit to implement the "DDW" APIs (part of PAPR allowing the guest to control the DMA windows, ie, by creating new windows in 64-bit DMA space, with different page sizes etc....). So you may want to make it clear that the above provides information about the "base window" specifically. Cheers, Ben.