From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:42966) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QjMvD-0007hP-Gj for qemu-devel@nongnu.org; Tue, 19 Jul 2011 22:54:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QjMv9-0007p9-JY for qemu-devel@nongnu.org; Tue, 19 Jul 2011 22:54:02 -0400 Received: from mail-yi0-f45.google.com ([209.85.218.45]:58423) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QjMv9-0007p2-Aq for qemu-devel@nongnu.org; Tue, 19 Jul 2011 22:53:59 -0400 Received: by yia25 with SMTP id 25so2343976yia.4 for ; Tue, 19 Jul 2011 19:53:58 -0700 (PDT) Message-ID: <4E264344.1080505@codemonkey.ws> Date: Tue, 19 Jul 2011 21:53:56 -0500 From: Anthony Liguori 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> <4E25AC5D.1030205@redhat.com> <4E25EE3A.8030007@codemonkey.ws> In-Reply-To: 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: Sasha Levin Cc: Avi Kivity , kvm@vger.kernel.org, qemu-devel@nongnu.org On 07/19/2011 04:03 PM, Sasha Levin wrote: > On Tue, Jul 19, 2011 at 11:51 PM, Anthony Liguori wrote: >> The e1000 is not performance competitive with virtio-net though so it >> certainly is reasonable to assume that noone would notice if we removed >> coalesced I/O from the e1000. >> >> The point is, it's so incredibly special cased that having it as part of >> such a general purpose API seems wrong. Of the hundreds of devices, we only >> have one device that we know for sure really needs it and it could easily be >> done independent of the memory API for that device. > > Sorry for sidetracking it a bit, but if coalesced mmio doesn't fit > nicely in a good memory model, maybe the problem is with coalesced > mmio and not the memory model itself. Well, I'd say it's the exception that proves the rule :-) I'm really just advocating that we should treat it as an exception and not try to change our rules to take it into account. > It's something that's not really being used at the moment - neither in > qemu nor in kvm tools (we just use dirty log in a guest memory block > after finding out coalesced mmio is still slow). QEMU does use it and it's quite important. Coalesced MMIO is really about write caching MMIO exits. It only works with devices that have registers where writing has no side effects. Moreover, it only really works well when there are lots and lots of writes to these registers simultaneously. Couple that with the fact that the buffer is a fixed size and it's really not flexible enough to be useful for a wide variety of devices. But for VGA planar mode writes, it works wonders. It would be terrible to totally lose it. That said, I'm not at all convinced it's useful for much other than VGA planar mode. Regards, Anthony Liguori > What about just deprecating it and doing either the sockets approach > (whenever it's ready), or doing a brand new virtio-memory device to > avoid the possibility of sockets turning into something like coalesced > mmio. >