From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eduard - Gabriel Munteanu Subject: Re: [Qemu-devel] [PATCH RFC] dma_rw.h (was Re: [PATCH 0/7] AMD IOMMU emulation patchset v4) Date: Thu, 16 Sep 2010 10:12:12 +0300 Message-ID: <20100916071212.GB7811@localhost> References: <1283007298-10942-1-git-send-email-eduard.munteanu@linux360.ro> <20100913200120.GA20918@redhat.com> <4C8E8D6E.90800@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "Michael S. Tsirkin" , kvm@vger.kernel.org, joro@8bytes.org, qemu-devel@nongnu.org, blauwirbel@gmail.com, yamahata@valinux.co.jp, paul@codesourcery.com, avi@redhat.com To: Anthony Liguori Return-path: Received: from mail-bw0-f46.google.com ([209.85.214.46]:51358 "EHLO mail-bw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752565Ab0IPHOJ (ORCPT ); Thu, 16 Sep 2010 03:14:09 -0400 Received: by bwz11 with SMTP id 11so1310171bwz.19 for ; Thu, 16 Sep 2010 00:14:08 -0700 (PDT) Content-Disposition: inline In-Reply-To: <4C8E8D6E.90800@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: On Mon, Sep 13, 2010 at 03:45:34PM -0500, Anthony Liguori wrote: > On 09/13/2010 03:01 PM, Michael S. Tsirkin wrote: > > So I think the following will give the idea of what an API > > might look like that will let us avoid the scary hacks in > > e.g. the ide layer and other generic layers that need to do DMA, > > without either binding us to pci, adding more complexity with > > callbacks, or losing type safety with casts and void*. > > > > Basically we have DMADevice that we can use container_of on > > to get a PCIDevice from, and DMAMmu that will get instanciated > > in a specific MMU. > > > > This is not complete code - just a header - I might complete > > this later if/when there's interest or hopefully someone interested > > in iommu emulation will. > > > > Notes: > > the IOMMU_PERM_RW code seem unused, so I replaced > > this with plain is_write. Is it ever useful? > > > > It seems that invalidate callback should be able to > > get away with just a device, so I switched to that > > from a void pointer for type safety. > > Seems enough for the users I saw. > > > > I saw devices do stl_le_phys and such, these > > might need to be wrapped as well. > > > > Signed-off-by: Michael S. Tsirkin > > > > One of the troubles with an interface like this is that I'm not sure a > generic model universally works. > > For instance, I know some PCI busses do transparent byte swapping. For > this to work, there has to be a notion of generic memory reads/writes > vs. reads of a 32-bit, 16-bit, and 8-bit value. > > With a generic API, we lose the flexibility to do this type of bus > interface. > > Regards, > > Anthony Liguori > [snip] I suppose additional callbacks that do the actual R/W could solve this. If those aren't present, default to cpu_physical_memory_*(). It should be easy for such a callback to decide on a case-by-case basis depending on the R/W transaction size, if this is ever needed. Eduard From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=43313 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ow8fa-0006o4-Hi for qemu-devel@nongnu.org; Thu, 16 Sep 2010 03:14:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Ow8fZ-0002ts-Cd for qemu-devel@nongnu.org; Thu, 16 Sep 2010 03:14:10 -0400 Received: from mail-bw0-f45.google.com ([209.85.214.45]:40516) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Ow8fZ-0002te-7z for qemu-devel@nongnu.org; Thu, 16 Sep 2010 03:14:09 -0400 Received: by bwz4 with SMTP id 4so1484633bwz.4 for ; Thu, 16 Sep 2010 00:14:08 -0700 (PDT) Sender: Eduard - Gabriel Munteanu Date: Thu, 16 Sep 2010 10:12:12 +0300 From: Eduard - Gabriel Munteanu Subject: Re: [Qemu-devel] [PATCH RFC] dma_rw.h (was Re: [PATCH 0/7] AMD IOMMU emulation patchset v4) Message-ID: <20100916071212.GB7811@localhost> References: <1283007298-10942-1-git-send-email-eduard.munteanu@linux360.ro> <20100913200120.GA20918@redhat.com> <4C8E8D6E.90800@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C8E8D6E.90800@codemonkey.ws> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: kvm@vger.kernel.org, "Michael S. Tsirkin" , joro@8bytes.org, qemu-devel@nongnu.org, blauwirbel@gmail.com, yamahata@valinux.co.jp, paul@codesourcery.com, avi@redhat.com On Mon, Sep 13, 2010 at 03:45:34PM -0500, Anthony Liguori wrote: > On 09/13/2010 03:01 PM, Michael S. Tsirkin wrote: > > So I think the following will give the idea of what an API > > might look like that will let us avoid the scary hacks in > > e.g. the ide layer and other generic layers that need to do DMA, > > without either binding us to pci, adding more complexity with > > callbacks, or losing type safety with casts and void*. > > > > Basically we have DMADevice that we can use container_of on > > to get a PCIDevice from, and DMAMmu that will get instanciated > > in a specific MMU. > > > > This is not complete code - just a header - I might complete > > this later if/when there's interest or hopefully someone interested > > in iommu emulation will. > > > > Notes: > > the IOMMU_PERM_RW code seem unused, so I replaced > > this with plain is_write. Is it ever useful? > > > > It seems that invalidate callback should be able to > > get away with just a device, so I switched to that > > from a void pointer for type safety. > > Seems enough for the users I saw. > > > > I saw devices do stl_le_phys and such, these > > might need to be wrapped as well. > > > > Signed-off-by: Michael S. Tsirkin > > > > One of the troubles with an interface like this is that I'm not sure a > generic model universally works. > > For instance, I know some PCI busses do transparent byte swapping. For > this to work, there has to be a notion of generic memory reads/writes > vs. reads of a 32-bit, 16-bit, and 8-bit value. > > With a generic API, we lose the flexibility to do this type of bus > interface. > > Regards, > > Anthony Liguori > [snip] I suppose additional callbacks that do the actual R/W could solve this. If those aren't present, default to cpu_physical_memory_*(). It should be easy for such a callback to decide on a case-by-case basis depending on the R/W transaction size, if this is ever needed. Eduard