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
--
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