On 03.11.2009, at 00:57, Ondrej Zajicek wrote:
On Tue, Nov 03, 2009 at 12:24:15AM +0100, Alexander Graf wrote:
Also, we still need to keep the local frame buffer copy in sync so
we
can mmap and read from it, right? So it's not really worth it
probably...
But then again we could just try to be closer to a real graphics
card.
What if we'd set up a memory region on the host that is basically our
graphics frame buffer? For S390 we could just append the graphics
memory
to the guest's memory.
We could use that as backing buffer in the qemu graphics frontend
and as
frame buffer in the Linux fbdev layer, similar to what real graphics
cards set up.
Using shared memory pages between host and guest seems like a natural
way to implement paravirtualized graphics card. Most things are
straightforward, only a little problematic thing is when fbdev
is mmaped from guest to userspace - you have to detect writes
and notify host that it changed.
Yes, currently I use the deferred IO stuff and send over "write"
commands with the full contents of the frame buffer.
But having a shared frame buffer really sounds better.
The major thing I really want to do different from xenfb though is
that the _host_ renders. That way "copy" operations still work as
designed, enabling vnc to pass them through directly. That might also
allow for some sort of DRI interface to pass through 3d data to the
host... at least in the future :-).
Alex
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
