[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] QEMU: Discussion of separating core functionality vs su
From: |
Jes Sorensen |
Subject: |
Re: [Qemu-devel] QEMU: Discussion of separating core functionality vs supportive features |
Date: |
Wed, 02 Mar 2011 12:05:28 +0100 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 |
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
Re: [Qemu-devel] QEMU: Discussion of separating core functionality vs supportive features, Jes Sorensen, 2011/03/02