On 03/02/11 11:58, Alon Levy wrote: > On Wed, Mar 02, 2011 at 11:25:44AM +0100, Jes Sorensen wrote: >> I had a few thoughts about this already, which I think will work for >> both spice and vnc. What we could do is to expose the video memory via >> shared memory. That way a spice or vnc daemon could get direct access to >> the memory, this would limit communication to keyboard/mouse events, as >> well as video mode info, and possibly notifications to the client about >> which ranges of memory have been updated. >> >> Using shared memory this way should allow us to implement the video >> clients without performance loss, in fact it should be beneficial since >> it would allow them to run fully separate from the host daemon. >> > > I think that would work well for spice. Spice uses shared memory from the > pci device for both the framebuffer and surfaces/commands, but this is > not really relevant at this level. What about IO and irq? that would add > additional latencies, no? because each io exit would need to be ipc'ed over > to the spice/vnc process? and same way in the other direction, requesting > qemu to trigger an interrupt in the next vm entry.
I am glad the shmem approach will work for Spice. There would be something there with IRQs etc, I agree. but there are methods to help that too, we could use a shared memory event ring for example. Cheers, Jes