From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:51099)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <rusty@ozlabs.org>) id 1Sw27P-00079X-E6
	for qemu-devel@nongnu.org; Mon, 30 Jul 2012 22:23:32 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <rusty@ozlabs.org>) id 1Sw27O-0006uU-4t
	for qemu-devel@nongnu.org; Mon, 30 Jul 2012 22:23:31 -0400
Received: from ozlabs.org ([203.10.76.45]:49253)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <rusty@ozlabs.org>) id 1Sw27N-0006u2-Q0
	for qemu-devel@nongnu.org; Mon, 30 Jul 2012 22:23:30 -0400
From: Rusty Russell <rusty@rustcorp.com.au>
In-Reply-To: <87ipd5xmpb.fsf@codemonkey.ws>
References: <1343629462.21647.32.camel@pasglop> <50165D0A.6060608@redhat.com>
	<1343647217.21647.40.camel@pasglop> <50166F2A.1040507@redhat.com>
	<1343649267.21647.44.camel@pasglop>
	<501676D7.3010504@redhat.com> <878ve11j70.fsf@codemonkey.ws>
	<50168C68.9010103@redhat.com> <874nopicrc.fsf@codemonkey.ws>
	<5016926E.3090109@redhat.com> <87obmx491u.fsf@codemonkey.ws>
	<50169BD5.6060807@redhat.com> <87ipd5xmpb.fsf@codemonkey.ws>
Date: Tue, 31 Jul 2012 09:17:11 +0930
Message-ID: <87ipd4lslc.fsf@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each
	other out
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Anthony Liguori <anthony@codemonkey.ws>, Avi Kivity <avi@redhat.com>
Cc: qemu-devel@nongnu.org

On Mon, 30 Jul 2012 11:01:20 -0500, Anthony Liguori <anthony@codemonkey.ws> wrote:
> Avi Kivity <avi@redhat.com> writes:
> > It doesn't seem to be such a huge problem, though it does turn virtio
> > into a respec'ed PCI.
> 
> Virtio was originally designed to be a DMA API (although not ABI).  From
> a virtio-pci perspective, adding a large memory area that can be
> referenced is not a big deal at all.  You can take PFNs into the memory
> area and just handle it like you would any other address reference.
> 
> But for the virtio API within Linux, it presents a challenge.
> Originally, there was a desire to support DMA-based interfaces like
> Xen's grant tables or PowerVM's TCE transfers.
> 
> While there have been proof of concepts, it's never landed in an
> upstream kernel.  I'd be perfectly happy forcing the virtio API to
> assume the ability to share large areas of memory between the host and
> guest and eliminate the possibility to support all types of hypervisors
> for some devices.
> 
> (While Xen supports shared memory, PowerVM does not--I don't give a damn
> about supporting PowerVM FWIW).
> 
> Rusty, what do you think about the above?

Shared memory is an efficiency thing, not a requirement.  If the virtio
side-channel tells the device about the location of framebuffer
changes, it could still be quite efficient.

Cheers,
Rusty.