Re: [Qemu-devel] [RFC v4 00/58] Memory API

[Sasha Levin]

On Tue, Jul 19, 2011 at 11:51 PM, Anthony Liguori <address@hidden> 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.