From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:57500) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sf2Ql-0000bB-Re for qemu-devel@nongnu.org; Thu, 14 Jun 2012 01:17:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sf2Qk-0002IH-2b for qemu-devel@nongnu.org; Thu, 14 Jun 2012 01:17:15 -0400 Received: from gate.crashing.org ([63.228.1.57]:57578) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sf2Qj-0002GE-Pl for qemu-devel@nongnu.org; Thu, 14 Jun 2012 01:17:13 -0400 Message-ID: <1339651015.9220.158.camel@pasglop> From: Benjamin Herrenschmidt Date: Thu, 14 Jun 2012 15:16:55 +1000 In-Reply-To: <20120614023154.GB29384@zapo> References: <4FD62B5C.4040106@redhat.com> <4FD63A7F.8090902@codemonkey.ws> <1339452058.9220.32.camel@pasglop> <4FD67132.1060001@codemonkey.ws> <4FD7100F.3080207@redhat.com> <1339547861.9220.77.camel@pasglop> <20120614000001.GA26263@zapo> <1339637650.9220.134.camel@pasglop> <20120614020306.GA29384@zapo> <1339640205.9220.139.camel@pasglop> <20120614023154.GB29384@zapo> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Subject: Re: [Qemu-devel] [RFC] QOMification of AXI streams List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Peter Maydell , Anthony Liguori , "qemu-devel@nongnu.org Developers" , Peter Crosthwaite , Michal Simek , Avi Kivity , Andreas =?ISO-8859-1?Q?F=E4rber?= , John Williams , Paul Brook < snip thread > So I was looking at this accessor business. We already have them for PCI. PAPR VIO already has its own as well. That leaves us with various devices such as OHCI that can exist on different bus types and use the lower-level "DMAContext" based variant... Now I'm keen to keep it (essentially, keep the series as-is really) and say let's just merge it for 1.2, unless you think you can come up with something better before that deadline. At the end of the day, DMAContext is a fine structure to hold the iommu ops and identify the top level DMA translation, we might just end up burying it elsewhere in the long run, but for now it's easy to keep as-is. There's few enough drivers who directly use the dma_* API, really. Mostly those who sit on multiple bus, and a bit of search/replace in there won't be hard if needed in the future. After the discussion we had with a few other folks on the list it looks like a "proper" model isn't something that we need today to fix a specific issue, the simpler DMAContext approach will work fine, unless I missed something. And we can always make DMAContext itself hierarchical or burry it in the MemoryRegion and leave the type itself as a handle for upstream transactions. Cheers, Ben.