Anthony Liguori wrote:
I'd strongly recommend working these patches on qemu-devel and lkml. I suspect Avi may disagree with me, but in order for this to be eventually merged in either place, you're going to have additional requirements put on you.
I don't disagree with the fact that there will be additional requirements, but I might disagree with some of those additional requirements themselves. In particular I think your proposal was unimplementable; I would like to see how how you can address my concerns.
I don't think bulk memory sharing and the current transactional virtio mechanisms are a good fit for each other; but if we were to add a BAR-like capability to virtio that would address the compatibility requirement (though it might be difficult to implement on s390 with its requirement on contiguous host virtual address space).
A model which does fit the current virtio capabilities is that of a DMA engine - guest A specifies an sglist to copy; guest B specifies an sglist to receive the copy; the host does the copy, using a real DMA engine if available. Note A == B is a possibility, and is a way to expose a DMA engine to a single guest for its own use in moving memory around.
I think both models could prove useful.
If it goes in via qemu-kvm.git, there's a possibility that you'll be forced into an ABI break down the road (consider the old hypercall and balloon drivers).
I agree this is best merged upstream first. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- 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
