From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NkIkB-0002Sm-5g for qemu-devel@nongnu.org; Wed, 24 Feb 2010 10:01:43 -0500 Received: from [199.232.76.173] (port=48047 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NkIkA-0002SL-9r for qemu-devel@nongnu.org; Wed, 24 Feb 2010 10:01:42 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NkIk8-0003R5-He for qemu-devel@nongnu.org; Wed, 24 Feb 2010 10:01:41 -0500 Received: from mail-gw0-f45.google.com ([74.125.83.45]:37933) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NkIk8-0003Qx-8K for qemu-devel@nongnu.org; Wed, 24 Feb 2010 10:01:40 -0500 Received: by gwj17 with SMTP id 17so1625687gwj.4 for ; Wed, 24 Feb 2010 07:01:39 -0800 (PST) Message-ID: <4B853F51.8090705@codemonkey.ws> Date: Wed, 24 Feb 2010 09:01:37 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] VirtIO Support for Memory Regions References: <20100223205225.14860.50990.stgit@st-brides.cs.ualberta.ca> <4B84432C.6090104@codemonkey.ws> <8286e4ee1002232220l79bf50e4t70cf7591d798cebe@mail.gmail.com> <4B850A1A.40600@redhat.com> In-Reply-To: <4B850A1A.40600@redhat.com> 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: Avi Kivity Cc: Cam Macdonell , qemu-devel@nongnu.org On 02/24/2010 05:14 AM, Avi Kivity wrote: > On 02/24/2010 08:20 AM, Cam Macdonell wrote: >> >>> Virtio is really a DMA engine. One of the nice things about it's >>> design is >>> that you can do things like transparent bounce buffering if needed. >>> Adding >>> a mechanism like this breaks this abstract and turns virtio into >>> something >>> that's more than I think it should be. >>> >>> For guest shared memory, what makes sense to me is to make use of >>> uio_pci >>> within a guest to map bars in userspace. The device can have the >>> first bar >>> map a small MMIO region that is tied to a ioeventfd with KVM. With >>> just >>> qemu, it can be tied to a normal eventfd. You can use irqfd with >>> KVM to tie >>> an eventfd to the PCI irq. Likewise, you can use a normal eventfd to >>> emulate that. I'd suggest using a /dev/shm file to act as the >>> shared memory >>> segment. You'll need a little magic within qemu_ram_alloc() to use >>> this >>> (maybe qemu_ram_alloc() should take a context parameter so this can be >>> setup). >> Part of my goal with this patch was to support systems without PCI. >> My previous patch > > Which? The only one I know of is s390 (and it would be a pity not to > have shared memory for that). uio provides insulation against devices and busses. When you use uio in userspace, you don't have to have direct knowledge of the fact that a device is or isn't a PCI device. Regards, Anthony Liguori