From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:57525) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QjRrQ-0008P1-SU for qemu-devel@nongnu.org; Wed, 20 Jul 2011 04:10:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QjRrN-0007Dn-IB for qemu-devel@nongnu.org; Wed, 20 Jul 2011 04:10:28 -0400 Received: from mx1.redhat.com ([209.132.183.28]:14179) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QjRrN-0007Dh-2s for qemu-devel@nongnu.org; Wed, 20 Jul 2011 04:10:25 -0400 Message-ID: <4E268D69.9010402@redhat.com> Date: Wed, 20 Jul 2011 11:10:17 +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> <4E25AC5D.1030205@redhat.com> <4E25EE3A.8030007@codemonkey.ws> In-Reply-To: <4E25EE3A.8030007@codemonkey.ws> 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 11:51 PM, Anthony Liguori wrote: > On 07/19/2011 11:10 AM, Avi Kivity wrote: >> 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. > > There are exactly two devices that use coalesced I/O: VGA and e1000. > > VGA does coalesced I/O over the legacy VGA region (0xa0000 ... > 0xc0000). This region is very special in the PC and is directly > routed by the I440FX to the appropriate first PCI graphics card. > > The VGA device knows exactly where this region is mapped. The VGA device doesn't know *if* it is mapped. It can be obstructed by the chipset and by SMM. Other chipsets we emulate may support multiple VGA cards. > > The e1000 does coalesced I/O for it's memory registers. But it's > dubious how much this actually matters anymore. The original claim > was a 10% boost with iperf. > > 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 e1000 NIC is the best we have for guests that don't support virtio. It's not reasonable to reduce its performance. > > 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. > We either support coalesced mmio well, or not at all. Even if the API has only one user, that doesn't excuse doing it badly. -- error compiling committee.c: too many arguments to function