From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH v2] Shared memory device with interrupt support Date: Tue, 19 May 2009 07:31:53 +0300 Message-ID: <4A123639.9000901@redhat.com> References: <1241712992-17004-1-git-send-email-cam@cs.ualberta.ca> <4A11AECB.70908@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Cam Macdonell , kvm@vger.kernel.org To: Anthony Liguori Return-path: Received: from mx2.redhat.com ([66.187.237.31]:60181 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750802AbZESEbu (ORCPT ); Tue, 19 May 2009 00:31:50 -0400 In-Reply-To: <4A11AECB.70908@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: 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.