From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NfIFZ-00023Y-A8 for qemu-devel@nongnu.org; Wed, 10 Feb 2010 14:29:25 -0500 Received: from [199.232.76.173] (port=34099 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NfIFY-00023I-Tg for qemu-devel@nongnu.org; Wed, 10 Feb 2010 14:29:24 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NfIFW-0005Pg-69 for qemu-devel@nongnu.org; Wed, 10 Feb 2010 14:29:24 -0500 Received: from mail-yx0-f183.google.com ([209.85.210.183]:59609) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NfIFV-0005Pa-VI for qemu-devel@nongnu.org; Wed, 10 Feb 2010 14:29:22 -0500 Received: by yxe13 with SMTP id 13so364362yxe.18 for ; Wed, 10 Feb 2010 11:29:21 -0800 (PST) Message-ID: <4B73090E.1020408@codemonkey.ws> Date: Wed, 10 Feb 2010 13:29:18 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 0/15][RFC] New PCI interfaces References: <1265752899-26980-1-git-send-email-aliguori@us.ibm.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: Michael Tsirkin , qemu-devel@nongnu.org, Alex Graf On 02/10/2010 12:34 PM, Blue Swirl wrote: > On Wed, Feb 10, 2010 at 12:01 AM, Anthony Liguori wrote: > >> This is a work in progress that I wanted to share giving some of the discussions >> around rwhandlers. The idea is to make PCI devices have a common set of >> functions to interact with the CPU that is driven entirely through the PCI bus. >> >> I've tested the network card conversions, but have not yet tested the other >> bits. >> > By itself, the patches look OK. But given that the conclusion of the > generic DMA discussion was to aim for mapping approach (in order to > prepare for zero copy DMA), I wonder how the patches fit to the larger > picture. Perhaps instead of pci specific functions, a more generic > memory object with read and write methods could be introduced, which > would be more useful in the longer term? > This is a good point and it's something that needs to be addressed for the virtio conversion. I was thinking: void *pci_memory_map(PCIDevice *dev, pcibus_t addr, pcibus_t *plen, int is_write); void pci_memory_unmap(PCIDevice *dev, void *buf, pcibus_t *plen, int is_write, pcibus_t access_len); Not too surprising. Since virtio devices can live on two busses (sysbus with Syborg or PCI), we need to introduce a set of virtio specific functions. void virtio_memory_read(VirtIODevice *dev, uint64_t addr, void *buf, int len); void virtio_memory_write(VirtIODevice *dev, uint64_t addr, const void *buf, int len); void *virtio_memory_map(VirtIODevice *dev, uint64_t addr, uint64_t *plen, int is_write); void virtio_memory_unmap(VirtIODevice *dev, uint64_t addr, uint64_t *plen, int is_write, uint64_t access_len); Inside the VirtIODevice, there would be corresponding function pointers, and depending on whether it was a PCI device or a Syborg device, it would call pci_memory_map or cpu_physical_memory_map. If we introduced a consistent address type, it would be possible to make generic memory access functions that used a state variable to mask this from the user. I personally prefer the explicit interfaces though. It makes it easy to look at a PCI device and see that it only uses PCI interfaces. I also think that some bus concepts will be difficult to abstract in a generic way. Regards, Anthony Liguori