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

[Dor Laor <dlaor@redhat.com>]

On 03/02/2011 12:58 PM, Alon Levy wrote:
> On Wed, Mar 02, 2011 at 11:25:44AM +0100, Jes Sorensen wrote:
>> 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@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.
>>
>
> 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

Is that the only DMA do you do? That's good for this model.

> 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.

The qxl device can be in the privileged qemu (as a start) and it will 
handle irqs directly. Even today you need to notify the spice server 
thread, so nothing will change
>
>> Cheers,
>> Jes
>>