From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [Qemu-devel] [RFC v4 00/58] Memory API Date: Wed, 20 Jul 2011 11:10:17 +0300 Message-ID: <4E268D69.9010402@redhat.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org To: Anthony Liguori Return-path: Received: from mx1.redhat.com ([209.132.183.28]:27369 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751529Ab1GTIKZ (ORCPT ); Wed, 20 Jul 2011 04:10:25 -0400 In-Reply-To: <4E25EE3A.8030007@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: 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