From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=52623 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OrCIw-0008Nq-Gn for qemu-devel@nongnu.org; Thu, 02 Sep 2010 12:06:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OrCIp-00071r-05 for qemu-devel@nongnu.org; Thu, 02 Sep 2010 12:06:19 -0400 Received: from moutng.kundenserver.de ([212.227.126.171]:49927) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OrCIo-00071j-KD for qemu-devel@nongnu.org; Thu, 02 Sep 2010 12:06:14 -0400 Message-ID: <4C7FCB53.5010503@mail.berlios.de> Date: Thu, 02 Sep 2010 18:05:39 +0200 From: Stefan Weil MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 2/7] pci: memory access API and IOMMU support References: <1283119703-9781-1-git-send-email-eduard.munteanu@linux360.ro> <4C7EB336.40003@mail.berlios.de> <20100902085104.GB7211@localhost> In-Reply-To: <20100902085104.GB7211@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduard - Gabriel Munteanu Cc: kvm@vger.kernel.org, mst@redhat.com, joro@8bytes.org, qemu-devel@nongnu.org, blauwirbel@gmail.com, yamahata@valinux.co.jp, paul@codesourcery.com, avi@redhat.com Am 02.09.2010 10:51, schrieb Eduard - Gabriel Munteanu: > On Wed, Sep 01, 2010 at 10:10:30PM +0200, Stefan Weil wrote: > >> Please see my comments at the end of this mail. >> >> >> Am 30.08.2010 00:08, schrieb Eduard - Gabriel Munteanu: >> >>> PCI devices should access memory through pci_memory_*() instead of >>> cpu_physical_memory_*(). This also provides support for translation and >>> access checking in case an IOMMU is emulated. >>> >>> Memory maps are treated as remote IOTLBs (that is, translation caches >>> belonging to the IOMMU-aware device itself). Clients (devices) must >>> provide callbacks for map invalidation in case these maps are >>> persistent beyond the current I/O context, e.g. AIO DMA transfers. >>> >>> Signed-off-by: Eduard - Gabriel Munteanu >>> --- >>> > [snip] > > >>> +static inline void pci_memory_read(PCIDevice *dev, >>> + pcibus_t addr, >>> + uint8_t *buf, >>> + pcibus_t len) >>> +{ >>> + pci_memory_rw(dev, addr, buf, len, 0); >>> +} >>> + >>> +static inline void pci_memory_write(PCIDevice *dev, >>> + pcibus_t addr, >>> + const uint8_t *buf, >>> + pcibus_t len) >>> +{ >>> + pci_memory_rw(dev, addr, (uint8_t *) buf, len, 1); >>> +} >>> + >>> #endif >>> >> The functions pci_memory_read and pci_memory_write not only read >> or write byte data but many different data types which leads to >> a lot of type casts in your other patches. >> >> I'd prefer "void *buf" and "const void *buf" in the argument lists. >> Then all those type casts could be removed. >> >> Regards >> Stefan Weil >> > I only followed an approach similar to how cpu_physical_memory_{read,write}() > is defined. I think I should change both cpu_physical_memory_* stuff and > pci_memory_* stuff, not only the latter, if I decide to go on that > approach. > > > Eduard > Yes, cpu_physical_memory_read, cpu_physical_memory_write and cpu_physical_memory_rw should be changed, too. They also require several type casts today. But this change can be done in an independent patch. Stefan