From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:32970) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QjCsB-0006Ju-7z for qemu-devel@nongnu.org; Tue, 19 Jul 2011 12:10:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QjCs9-0005ZV-Fv for qemu-devel@nongnu.org; Tue, 19 Jul 2011 12:10:14 -0400 Received: from mx1.redhat.com ([209.132.183.28]:12018) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QjCs8-0005ZK-TH for qemu-devel@nongnu.org; Tue, 19 Jul 2011 12:10:13 -0400 Message-ID: <4E25AC5D.1030205@redhat.com> Date: Tue, 19 Jul 2011 19:10:05 +0300 From: Avi Kivity MIME-Version: 1.0 References: <1310901265-32051-1-git-send-email-avi@redhat.com> <4E2581F4.5090004@codemonkey.ws> <4E25864A.10905@redhat.com> <4E2599BC.9070407@codemonkey.ws> <4E25AB37.2030808@redhat.com> In-Reply-To: <4E25AB37.2030808@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC v4 00/58] Memory API 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/19/2011 07:05 PM, Avi Kivity wrote: > On 07/19/2011 05:50 PM, Anthony Liguori wrote: >> >>>> >>>> There's bits I don't like about the interface >>> >>> Which bits are these? >> >> Nothing I haven't already commented on. I think there's too much in >> the generic level. I don't think coalesced I/O belongs here. It's a >> concept that doesn't fit. I think a side-band API would be nicer. > > Well, it's impossible to do it in a side band. When a range that has > coalesced mmio is exposed is completely orthogonal to programming the > BAR register - it can happen, for example, due to another BAR being > removed or the bridge window being programmed. You can also have a > coalesced mmio region being partially clipped. Of course, it's not really impossible, just clumsy. You could have struct MemoryRegionOps { void (*on_mapping_added)(t_p_a_t offset, unsigned nr, const AddrRange ranges[]); void (*on_mapping_removed)(t_p_a_t offset, unsigned nr, const AddrRange ranges[]); }; the device callbacks would then compare the added or removed ranges with the coalesced mmio ranges needed by the device, and call the kvm callbacks as needed. But that's not something a device model writer should do, IMO (same goes for ioeventfd - they are now part of the API as well). -- error compiling committee.c: too many arguments to function