From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:36233) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QleZM-0005Om-G9 for qemu-devel@nongnu.org; Tue, 26 Jul 2011 06:08:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QleZL-00024g-87 for qemu-devel@nongnu.org; Tue, 26 Jul 2011 06:08:56 -0400 Received: from mx1.redhat.com ([209.132.183.28]:26235) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QleZK-00024c-VX for qemu-devel@nongnu.org; Tue, 26 Jul 2011 06:08:55 -0400 Message-ID: <4E2E9230.5020302@redhat.com> Date: Tue, 26 Jul 2011 13:08:48 +0300 From: Avi Kivity MIME-Version: 1.0 References: <1311602584-23409-1-git-send-email-avi@redhat.com> <1311602584-23409-12-git-send-email-avi@redhat.com> <4E2DBF24.20803@codemonkey.ws> In-Reply-To: <4E2DBF24.20803@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 11/23] memory: add ioeventfd support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org On 07/25/2011 10:08 PM, Anthony Liguori wrote: >> >> +static void as_memory_ioeventfd_add(AddressSpace *as, >> MemoryRegionIoeventfd *fd) >> +{ >> + int r; >> + >> + if (!fd->match_data || fd->addr.size != 4) { >> + abort(); >> + } >> + >> + r = kvm_set_ioeventfd_mmio_long(fd->fd, fd->addr.start, >> fd->data, true); >> + if (r< 0) { >> + abort(); >> + } > > > asserts would be friendlier. I thought asserts were disabled by default. But I see it isn't so; will update. > > I really dislike baking ioeventfd into this API. There is only one > user of ioeventfd in the tree. Two: virtio-pci and ivshmem. > > I worry that by having things like ioeventfd the API, we're making it > too difficult to side-step the API which prevents future optimizations. > > I'd prefer virtio-pci to have ugliness in it where it circumvented the > layering vs. having such a device specific thing in generic code. It's impossible (or at least, impossible without further information from the API) to do this and retain correctness. Currently virtio-pci is broken wrt bridges and overlapping BARs; it's probably also broken on targets that bridge the I/O address space to MMIO. With the memory API, this is fixed in a natural way by making the I/O address space a subregion of the bridge which does the conversion; the code will automatically add the needed offset and use MMIO ioeventfd instead of portio. On a more general note, I don't want this to be a lean and mean API that throws any complexity to the users; instead I want to make writing devices as simple as possible and own all the smarts. (an example - undecoded address bits can be specified to the API which then takes care of replication or shifting). -- error compiling committee.c: too many arguments to function