qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC v4 00/58] Memory API


From: Avi Kivity
Subject: Re: [Qemu-devel] [RFC v4 00/58] Memory API
Date: Wed, 20 Jul 2011 11:12:21 +0300
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Thunderbird/3.1.10

On 07/20/2011 09:10 AM, Sasha Levin wrote:
On Tue, 2011-07-19 at 21:53 -0500, Anthony Liguori wrote:
>  QEMU does use it and it's quite important.  Coalesced MMIO is really
>  about write caching MMIO exits.  It only works with devices that have
>  registers where writing has no side effects.  Moreover, it only really
>  works well when there are lots and lots of writes to these registers
>  simultaneously.
>
>  Couple that with the fact that the buffer is a fixed size and it's
>  really not flexible enough to be useful for a wide variety of devices.
>
>  But for VGA planar mode writes, it works wonders.  It would be terrible
>  to totally lose it.  That said, I'm not at all convinced it's useful for
>  much other than VGA planar mode.

Why was the coalesced approach taken in the first place? When I tried
using it for VGA in /tools/kvm it just seemed to me like a builtin
virtio-memory transport.

Thats why I think planar VGA would be fine if we deprecate coalesced
mmio in favor of either socket ioeventfds or a new virtio-memory device.


virtio is guest visible. coealesced mmio is transparent to the guest. socket ioeventds also do coalescing, but they are more expensive to synchronize - you have to poll the socket whenever a synchronization event happens.

--
error compiling committee.c: too many arguments to function




reply via email to

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