Thread (34 messages) 34 messages, 8 authors, 2009-11-06

Re: [Linux-fbdev-devel] [PATCH] Add VirtIO Frame Buffer Support

From: Alexander Graf <hidden>
Date: 2009-11-02 23:59:59
Also in: kvm, qemu-devel

On 03.11.2009, at 00:57, Ondrej Zajicek wrote:
On Tue, Nov 03, 2009 at 12:24:15AM +0100, Alexander Graf wrote:
quoted
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help