[Spice-devel] [Qemu-devel] QEMU: Discussion of separating core functionality vs supportive features

[Jes Sorensen]

On 03/01/11 15:25, Dor Laor wrote:
> On 03/01/2011 02:40 PM, Anthony Liguori wrote:
>>
>> On Mar 1, 2011 7:07 AM, "Dor Laor" <dlaor at redhat.com
>>  > Qemu is the one that should spawn them and they should be transparent
>> from the management. This way running qemu stays the same and qemu just
>> need to add the logic to get a SIGCHILD and potentially re-execute an
>> dead son process.
>>
>> Spice is the logical place to start, no?  It's the largest single
>> dependency we have and it does some scary things with qemu_mutex.  I
>> would use spice as a way to prove the concept.
> 
> I agree it is desirable to the this for spice but it is allot more
> complex than virtagent isolation. Spice is performance sensitive and
> contains much more state. It needs to access the guest memory for
> reading the surfaces. It can be solved but needs some major changes.
> Adding spice-devel to the discussion.

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.

Cheers,
Jes