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