On Tue, Jul 19, 2011 at 11:51 PM, Anthony Liguori <anthony@xxxxxxxxxxxxx> 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 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 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. 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). 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. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
