From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NlvjN-0004SX-KI
	for qemu-devel@nongnu.org; Sun, 28 Feb 2010 21:51:37 -0500
Received: from [199.232.76.173] (port=39226 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NlvjN-0004SP-BB
	for qemu-devel@nongnu.org; Sun, 28 Feb 2010 21:51:37 -0500
Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim
	4.60) (envelope-from <paul@codesourcery.com>) id 1NlvjM-0005sQ-OT
	for qemu-devel@nongnu.org; Sun, 28 Feb 2010 21:51:37 -0500
Received: from mx20.gnu.org ([199.232.41.8]:6684)
	by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.60) (envelope-from <paul@codesourcery.com>)
	id 1NlvjM-0005sM-IC
	for qemu-devel@nongnu.org; Sun, 28 Feb 2010 21:51:36 -0500
Received: from mail.codesourcery.com ([38.113.113.100])
	by mx20.gnu.org with esmtp (Exim 4.60)
	(envelope-from <paul@codesourcery.com>) id 1NlvjL-000593-1r
	for qemu-devel@nongnu.org; Sun, 28 Feb 2010 21:51:35 -0500
From: Paul Brook <paul@codesourcery.com>
Subject: Re: [Qemu-devel] [PATCH 0/15][RFC] New PCI interfaces
Date: Mon, 1 Mar 2010 02:51:31 +0000
References: <1265752899-26980-1-git-send-email-aliguori@us.ibm.com>
	<f43fc5581002101034x4b554d1cl1c848292ea8a5a0f@mail.gmail.com>
	<4B73090E.1020408@codemonkey.ws>
In-Reply-To: <4B73090E.1020408@codemonkey.ws>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <201003010251.31668.paul@codesourcery.com>
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: qemu-devel@nongnu.org
Cc: Blue Swirl <blauwirbel@gmail.com>, Michael Tsirkin <mstirkin@redhat.com>, Alex Graf <agraf@suse.de>

> Since virtio devices can live on two busses (sysbus with Syborg or PCI),
> we need to introduce a set of virtio specific functions.
>...
> Inside the VirtIODevice, there would be corresponding function pointers,
>  and depending on whether it was a PCI device or a Syborg device, it would
>  call pci_memory_map or cpu_physical_memory_map.

You mean VirtIOBindings not VirtIODevice, right?  Virtio devices should not be 
accessing guest memory directly, they should be using a virtqueue.

Paul