qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each other o


From: Rusty Russell
Subject: Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each other out
Date: Tue, 31 Jul 2012 09:17:11 +0930
User-agent: Notmuch/0.12 (http://notmuchmail.org) Emacs/23.3.1 (i686-pc-linux-gnu)

On Mon, 30 Jul 2012 11:01:20 -0500, Anthony Liguori <address@hidden> wrote:
> Avi Kivity <address@hidden> 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]