From: Alexander G. <ag...@su...> - 2009-11-03 00:00:09
|
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 |