From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NkFCT-0000hC-WA for qemu-devel@nongnu.org; Wed, 24 Feb 2010 06:14:42 -0500 Received: from [199.232.76.173] (port=51296 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NkFCS-0000gs-Vw for qemu-devel@nongnu.org; Wed, 24 Feb 2010 06:14:41 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NkFCS-0006rK-AG for qemu-devel@nongnu.org; Wed, 24 Feb 2010 06:14:40 -0500 Received: from mx1.redhat.com ([209.132.183.28]:48596) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NkFCR-0006rE-TA for qemu-devel@nongnu.org; Wed, 24 Feb 2010 06:14:40 -0500 Message-ID: <4B850A1A.40600@redhat.com> Date: Wed, 24 Feb 2010 13:14:34 +0200 From: Avi Kivity 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> In-Reply-To: <8286e4ee1002232220l79bf50e4t70cf7591d798cebe@mail.gmail.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: Cam Macdonell Cc: qemu-devel@nongnu.org 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). -- error compiling committee.c: too many arguments to function