From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Nk20I-0000GK-Hx
	for qemu-devel@nongnu.org; Tue, 23 Feb 2010 16:09:14 -0500
Received: from [199.232.76.173] (port=40702 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Nk20H-0000GC-T4
	for qemu-devel@nongnu.org; Tue, 23 Feb 2010 16:09:14 -0500
Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim
	4.60) (envelope-from <anthony@codemonkey.ws>) id 1Nk20G-0002ao-9S
	for qemu-devel@nongnu.org; Tue, 23 Feb 2010 16:09:13 -0500
Received: from mail-qy0-f185.google.com ([209.85.221.185]:50305)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <anthony@codemonkey.ws>) id 1Nk20F-0002ah-Th
	for qemu-devel@nongnu.org; Tue, 23 Feb 2010 16:09:12 -0500
Received: by qyk15 with SMTP id 15so35189qyk.10
	for <qemu-devel@nongnu.org>; Tue, 23 Feb 2010 13:09:11 -0800 (PST)
Message-ID: <4B8443F4.6080903@codemonkey.ws>
Date: Tue, 23 Feb 2010 15:09:08 -0600
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH] VirtIO Support for Memory Regions
References: <20100223205225.14860.50990.stgit@st-brides.cs.ualberta.ca>
	<4B84432C.6090104@codemonkey.ws>
In-Reply-To: <4B84432C.6090104@codemonkey.ws>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Cam Macdonell <cam@cs.ualberta.ca>
Cc: qemu-devel@nongnu.org

On 02/23/2010 03:05 PM, Anthony Liguori wrote:
> Hi Cam,
>
> On 02/23/2010 02:52 PM, Cam Macdonell wrote:
>> Support for passing memory regions via VirtIO to remove need for PCI
>> support in the guest.
>>
>> Adds new vectors to VirtIO config space to pass memory regions similar
>> to how virtqueues are passed.
>>
>> Kernel patch is forthcoming that add device_ops to access the memory 
>> regions.
>>
>> I have used this mechanism to implement my host shared memory 
>> implementation
>> and modified Alex's Virtio FB to use it as well.
>
> Virtio is really a DMA engine.  One of the nice things about it's 
> design is that you can do things like transparent bounce buffering if 
> needed.  Adding a mechanism like this breaks this abstract and turns 
> virtio into something that's more than I think it should be.

More specifically, virtio does not assume cache coherent shared memory 
today.  While we assume this in the virtio-pci vring implementation, 
that's just an implementation detail of one transport.  Adding generic 
shared memory to virtio presumes that one can have cache coherent shared 
memory in any virtio transport which is not a good assumption to make.

Regards,

Anthony Liguori