|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] [RFC v4 00/58] Memory API |
Date: | Tue, 19 Jul 2011 15:51:06 -0500 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10 |
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 interfaceWhich 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.
Regards, Anthony Liguori
You could have struct MemoryRegionOps { void (*on_mapping_added)(t_p_a_t offset, unsigned nr, const AddrRange ranges[]); void (*on_mapping_removed)(t_p_a_t offset, unsigned nr, const AddrRange ranges[]); }; the device callbacks would then compare the added or removed ranges with the coalesced mmio ranges needed by the device, and call the kvm callbacks as needed. But that's not something a device model writer should do, IMO (same goes for ioeventfd - they are now part of the API as well).
[Prev in Thread] | Current Thread | [Next in Thread] |