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

[Avi Kivity]

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