[Qemu-devel] Spice project is now open

[Qemu-devel] Spice project is now open

[Yaniv Kamay]

Hi,

Spice project is now open, for more information visit http://spice-space.org,
due to a server relocation the site will be down during this weekend.

Spice ship patched QEMU based on fairly old KVM snapshot as a reference
implementation. The Spice team plane to push all the relevant bits into
QEMU upstream.

Spice depend upon guest side drivers in order to be fully functional, those
drivers are unavailable at this point due to technicalities for that reason we
advice not to try an evaluate Spice until the availability of the Windows
binaries.

Thanks,
Yaniv

Re: [Qemu-devel] Spice project is now open

[Jun Koi]

On Fri, Dec 11, 2009 at 10:45 PM, Yaniv Kamay <ykamay@redhat.com> wrote:
> Hi,
>
> Spice project is now open, for more information visit http://spice-space.org,
> due to a server relocation the site will be down during this weekend.
>
> Spice ship patched QEMU based on fairly old KVM snapshot as a reference
> implementation. The Spice team plane to push all the relevant bits into
> QEMU upstream.
>
> Spice depend upon guest side drivers in order to be fully functional, those
> drivers are unavailable at this point due to technicalities for that reason we
> advice not to try an evaluate Spice until the availability of the Windows
> binaries.

This is a great news!

I read that Spice supports Aero. This means we can run Windows Vista
Aero inside guest VM now??
This means we can also play Windows 3D games in guest VM now??

Thanks,
Jun
>
> Thanks,
> Yaniv
>
>
>

Re: [Qemu-devel] Spice project is now open

[Alexander Graf]

On 11.12.2009, at 14:45, Yaniv Kamay wrote:

> Hi,
> 
> Spice project is now open, for more information visit http://spice-space.org,
> due to a server relocation the site will be down during this weekend.
> 
> Spice ship patched QEMU based on fairly old KVM snapshot as a reference
> implementation. The Spice team plane to push all the relevant bits into
> QEMU upstream.

What's the roadmap here? It'd be a shame to have yet another fork of qemu.

Alex

Re: [Qemu-devel] Spice project is now open

[Yaniv Kamay]

----- "Jun Koi" <junkoi2004@gmail.com> wrote:

> On Fri, Dec 11, 2009 at 10:45 PM, Yaniv Kamay <ykamay@redhat.com>
> wrote:
> > Hi,
> >
> > Spice project is now open, for more information visit
> http://spice-space.org,
> > due to a server relocation the site will be down during this
> weekend.
> >
> > Spice ship patched QEMU based on fairly old KVM snapshot as a
> reference
> > implementation. The Spice team plane to push all the relevant bits
> into
> > QEMU upstream.
> >
> > Spice depend upon guest side drivers in order to be fully
> functional, those
> > drivers are unavailable at this point due to technicalities for that
> reason we
> > advice not to try an evaluate Spice until the availability of the
> Windows
> > binaries.
> 
> This is a great news!
> 
> I read that Spice supports Aero. This means we can run Windows Vista
> Aero inside guest VM now??
> This means we can also play Windows 3D games in guest VM now??

No, we do not support 3d but we plan to support 3d in general and especially
Aero.


> 
> Thanks,
> Jun
> >
> > Thanks,
> > Yaniv
> >
> >
> >

Re: [Qemu-devel] Spice project is now open

[Yaniv Kamay]

----- "Alexander Graf" <agraf@suse.de> wrote:

> On 11.12.2009, at 14:45, Yaniv Kamay wrote:
> 
> > Hi,
> > 
> > Spice project is now open, for more information visit
> http://spice-space.org,
> > due to a server relocation the site will be down during this
> weekend.
> > 
> > Spice ship patched QEMU based on fairly old KVM snapshot as a
> reference
> > implementation. The Spice team plane to push all the relevant bits
> into
> > QEMU upstream.
> 
> What's the roadmap here? It'd be a shame to have yet another fork of
> qemu.

We do not have any reason nor like to fork but for now we need to have
a functional system. I hope that spice patche will get accepted and all
will go well. 

> 
> Alex

Re: [Qemu-devel] Spice project is now open

[Jun Koi]

On Fri, Dec 11, 2009 at 11:09 PM, Alexander Graf <agraf@suse.de> wrote:
>
> On 11.12.2009, at 14:45, Yaniv Kamay wrote:
>
>> Hi,
>>
>> Spice project is now open, for more information visit http://spice-space.org,
>> due to a server relocation the site will be down during this weekend.
>>
>> Spice ship patched QEMU based on fairly old KVM snapshot as a reference
>> implementation. The Spice team plane to push all the relevant bits into
>> QEMU upstream.
>
> What's the roadmap here? It'd be a shame to have yet another fork of qemu.

Knowing that this is a Redhat project, I am sure that will not happen.

Thanks,
J

Re: [Qemu-devel] Spice project is now open

[Anthony Liguori]

Yaniv Kamay wrote:
> Hi,
>
> Spice project is now open, for more information visit http://spice-space.org,
> due to a server relocation the site will be down during this weekend.
>
> Spice ship patched QEMU based on fairly old KVM snapshot as a reference
> implementation. The Spice team plane to push all the relevant bits into
> QEMU upstream.
>   

Historically, we have not supported multiple display mechanisms favoring 
making one mechanism as good as it can be.

Supporting both Spice and VNC would go against this policy.  It's not 
outside the realm of possibility, but there has to be a good 
justification for it.

We need to separate the advantages of having a paravirtual display 
driver from the advantages of a remote display protocol.  For instance, 
VNC is capable of doing ARGB cursor offloading to the client.  We do not 
support it in QEMU because the VGA drivers we emulate do not support 
this functionality.  Likewise, VNC can support sound tunneling and QEMU 
does implement this (although virt-manager does not yet).

So from a protocol perspective, what are the advantages of Spice over VNC?

Obviously, the disadvantages are that for all practical purposes, it's a 
closed protocol.  While there is now a specification, there is not a 
clear mechanism for extending it by third parties.  VNC has a published 
protocol and there's a documented process for extending by third 
parties.  There are a large number of existing VNC clients so from an 
interoperability perspective, VNC clearly wins.

Since VNC is extensible (and we've extended it many times for QEMU), if 
Spice possesses unique encoding mechanisms that are advantageous, why 
wouldn't we just add those mechanisms to VNC as an extension?

Regards,

Anthony Liguori

Re: [Qemu-devel] Spice project is now open

[Anthony Liguori]

Jun Koi wrote:
> On Fri, Dec 11, 2009 at 11:09 PM, Alexander Graf <agraf@suse.de> wrote:
>   
>> On 11.12.2009, at 14:45, Yaniv Kamay wrote:
>>
>>     
>>> Hi,
>>>
>>> Spice project is now open, for more information visit http://spice-space.org,
>>> due to a server relocation the site will be down during this weekend.
>>>
>>> Spice ship patched QEMU based on fairly old KVM snapshot as a reference
>>> implementation. The Spice team plane to push all the relevant bits into
>>> QEMU upstream.
>>>       
>> What's the roadmap here? It'd be a shame to have yet another fork of qemu.
>>     
>
> Knowing that this is a Redhat project, I am sure that will not happen.
>   

It already has.  It's not a git tree with staged patches.  It's a 
tarball release of a really old version of kvm-userspace that's called 
'vdesktop'.

That's a fork like it or not.

Regards,

Anthony Liguori

Re: [Qemu-devel] Spice project is now open

[Yaniv Kamay]

----- "Anthony Liguori" <anthony@codemonkey.ws> wrote:

> Yaniv Kamay wrote:
> > Hi,
> >
> > Spice project is now open, for more information visit
> http://spice-space.org,
> > due to a server relocation the site will be down during this
> weekend.
> >
> > Spice ship patched QEMU based on fairly old KVM snapshot as a
> reference
> > implementation. The Spice team plane to push all the relevant bits
> into
> > QEMU upstream.
> >   
> 
> Historically, we have not supported multiple display mechanisms
> favoring 
> making one mechanism as good as it can be.
> 
> Supporting both Spice and VNC would go against this policy.  It's not
> 
> outside the realm of possibility, but there has to be a good 
> justification for it.
> 
> We need to separate the advantages of having a paravirtual display 
> driver from the advantages of a remote display protocol.  For
> instance, 
> VNC is capable of doing ARGB cursor offloading to the client.  We do
> not 
> support it in QEMU because the VGA drivers we emulate do not support 
> this functionality.  Likewise, VNC can support sound tunneling and
> QEMU 
> does implement this (although virt-manager does not yet).
> 
> So from a protocol perspective, what are the advantages of Spice over
> VNC?
> 
> Obviously, the disadvantages are that for all practical purposes, it's
> a 
> closed protocol.  While there is now a specification, there is not a 
> clear mechanism for extending it by third parties.  VNC has a
> published 
> protocol and there's a documented process for extending by third 
> parties.  There are a large number of existing VNC clients so from an
> 
> interoperability perspective, VNC clearly wins.
> 
> Since VNC is extensible (and we've extended it many times for QEMU),
> if 
> Spice possesses unique encoding mechanisms that are advantageous, why
> 
> wouldn't we just add those mechanisms to VNC as an extension?

I'm not getting into this discussion and is not going to happen, you have all
the necessary information on spiec-space.org in order to take intelligent
decision. The QEMU community can choose to reject Spice if it decide to do so.

> 
> Regards,
> 
> Anthony Liguori

Re: [Qemu-devel] Spice project is now open

[Chris Wright]

* Anthony Liguori (anthony@codemonkey.ws) wrote:
> Jun Koi wrote:
>> On Fri, Dec 11, 2009 at 11:09 PM, Alexander Graf <agraf@suse.de> wrote:
>>   
>>> On 11.12.2009, at 14:45, Yaniv Kamay wrote:
>>>> due to a server relocation the site will be down during this weekend.
>>>>
>>>> Spice ship patched QEMU based on fairly old KVM snapshot as a reference
>>>> implementation. The Spice team plane to push all the relevant bits into
>>>> QEMU upstream.
>>>>       
>>> What's the roadmap here? It'd be a shame to have yet another fork of qemu.
>>>     
>>
>> Knowing that this is a Redhat project, I am sure that will not happen.
>>   
>
> It already has.  It's not a git tree with staged patches.  It's a  
> tarball release of a really old version of kvm-userspace that's called  
> 'vdesktop'.

The lack of proper git tree and patches is a very unfortunate way to get
things started, I agree.

> That's a fork like it or not.

It is a branch of work.  The branch has been done without community
interaction, so yes, it looks like a fork.  The whole purpose of getting
spice licensed and released as an open source project is to work towards
eliminating the branch.

I'll repeat what Yaniv said already:

     Spice ship patched QEMU based on fairly old KVM snapshot as a reference
     implementation. The Spice team plane to push all the relevant bits into
     QEMU upstream.

I believe they wanted to get things out as soon as possible.

thanks,
-chris

Re: [Qemu-devel] Spice project is now open

[Chris Wright]

* Yaniv Kamay (ykamay@redhat.com) wrote:
> ----- "Anthony Liguori" <anthony@codemonkey.ws> wrote:
> > Since VNC is extensible (and we've extended it many times for QEMU),
> > if 
> > Spice possesses unique encoding mechanisms that are advantageous, why
> > 
> > wouldn't we just add those mechanisms to VNC as an extension?
> 
> I'm not getting into this discussion and is not going to happen, you have all
> the necessary information on spiec-space.org in order to take intelligent
> decision. The QEMU community can choose to reject Spice if it decide to do so.

No.  You need to respond with technical details to Anthony's legitimate
question.  When you are asking a project to accept your work, you must
make an effort to explain your reasoning to the project maintainers.

thanks.
-chris

Re: [Qemu-devel] Spice project is now open

[Anthony Liguori]

> I'm not getting into this discussion and is not going to happen, you have all
> the necessary information on spiec-space.org in order to take intelligent
> decision. The QEMU community can choose to reject Spice if it decide to do so.
>   

There's nothing to reject.  You haven't posted patches.

When you do post patches, if you can't/won't offer an explanation as to 
why it's better than what we already have, then they will be rejected.

Regards,

Anthony Liguori

Re: [Qemu-devel] Spice project is now open

[Anthony Liguori]

Chris Wright wrote:
>> That's a fork like it or not.
>>     
>
> It is a branch of work.  The branch has been done without community
> interaction, so yes, it looks like a fork.

Branches don't carry independent names like "vdesktop".  They don't 
carry their own version strings like 0.4.

Regards,

Anthony Liguori

Re: [Qemu-devel] Spice project is now open

[Yaniv Kamay]

----- "Anthony Liguori" <anthony@codemonkey.ws> wrote:

> Jun Koi wrote:
> > On Fri, Dec 11, 2009 at 11:09 PM, Alexander Graf <agraf@suse.de>
> wrote:
> >   
> >> On 11.12.2009, at 14:45, Yaniv Kamay wrote:
> >>
> >>     
> >>> Hi,
> >>>
> >>> Spice project is now open, for more information visit
> http://spice-space.org,
> >>> due to a server relocation the site will be down during this
> weekend.
> >>>
> >>> Spice ship patched QEMU based on fairly old KVM snapshot as a
> reference
> >>> implementation. The Spice team plane to push all the relevant bits
> into
> >>> QEMU upstream.
> >>>       
> >> What's the roadmap here? It'd be a shame to have yet another fork
> of qemu.
> >>     
> >
> > Knowing that this is a Redhat project, I am sure that will not
> happen.
> >   
> 
> It already has.  It's not a git tree with staged patches.  It's a 
> tarball release of a really old version of kvm-userspace that's called
> 
> 'vdesktop'.


This guy is evil and he is motivate by personal agenda. I hope you all will
wakeup.


> 
> That's a fork like it or not.
> 
> Regards,
> 
> Anthony Liguori

Re: [Qemu-devel] Spice project is now open

[Yaniv Kamay]

----- "Anthony Liguori" <anthony@codemonkey.ws> wrote:

> > I'm not getting into this discussion and is not going to happen, you
> have all
> > the necessary information on spiec-space.org in order to take
> intelligent
> > decision. The QEMU community can choose to reject Spice if it decide
> to do so.
> >   
> 
> There's nothing to reject.  You haven't posted patches.
> 
> When you do post patches, if you can't/won't offer an explanation as
> to 
> why it's better than what we already have, then they will be
> rejected.


Now I'm really scare.


> 
> Regards,
> 
> Anthony Liguori

Re: [Qemu-devel] Spice project is now open

[Anthony Liguori]

Yaniv Kamay wrote:
>> It already has.  It's not a git tree with staged patches.  It's a 
>> tarball release of a really old version of kvm-userspace that's called
>>
>> 'vdesktop'.
>>     
>
>
> This guy is evil and he is motivate by personal agenda. I hope you all will
> wakeup.
>   

Okay, I'm done with this thread.  I hope you have better luck in the 
future with Spice.

Regards,

Anthony Liguori

Re: [Qemu-devel] Spice project is now open

[Alexander Graf]

On 11.12.2009, at 18:02, Yaniv Kamay wrote:

> 
> ----- "Anthony Liguori" <anthony@codemonkey.ws> wrote:
> 
>> Jun Koi wrote:
>>> On Fri, Dec 11, 2009 at 11:09 PM, Alexander Graf <agraf@suse.de>
>> wrote:
>>> 
>>>> On 11.12.2009, at 14:45, Yaniv Kamay wrote:
>>>> 
>>>> 
>>>>> Hi,
>>>>> 
>>>>> Spice project is now open, for more information visit
>> http://spice-space.org,
>>>>> due to a server relocation the site will be down during this
>> weekend.
>>>>> 
>>>>> Spice ship patched QEMU based on fairly old KVM snapshot as a
>> reference
>>>>> implementation. The Spice team plane to push all the relevant bits
>> into
>>>>> QEMU upstream.
>>>>> 
>>>> What's the roadmap here? It'd be a shame to have yet another fork
>> of qemu.
>>>> 
>>> 
>>> Knowing that this is a Redhat project, I am sure that will not
>> happen.
>>> 
>> 
>> It already has.  It's not a git tree with staged patches.  It's a 
>> tarball release of a really old version of kvm-userspace that's called
>> 
>> 'vdesktop'.
> 
> 
> This guy is evil and he is motivate by personal agenda. I hope you all will
> wakeup.

While I don't quite understand what you're trying to say here, let me stress one thing:

I really think we're in dire need of better remote VM viewing interfaces. I personally don't care how they are achieved. Whether we're using spice, vmware drivers or port the vbox drivers to qemu doesn't really make to much of a difference to me. I just want to see video playback and 3D working.

That said, I believe spice has very promising parts and it would be a shame not to have you guys as part of the qemu community. Open Source people tend to be quite open at times, especially in expressing their beliefs. Most of the time they don't match with one's own :-).

So expect some heavy review, questioning of ways you do things and proposals on how to make things different. It might sound odd at first, but in the end it really benefits the code. Not developing code separately and "pushing" it to a project is part of that. Code gets reviewed, rejected, changed all the time.

I heartly welcome you to the open source world!

Alex

Re: [Qemu-devel] Spice project is now open

[Alexander Graf]

On 11.12.2009, at 18:16, Anthony Liguori wrote:

> Yaniv Kamay wrote:
>>> It already has.  It's not a git tree with staged patches.  It's a tarball release of a really old version of kvm-userspace that's called
>>> 
>>> 'vdesktop'.
>>>    
>> 
>> 
>> This guy is evil and he is motivate by personal agenda. I hope you all will
>> wakeup.
>>  
> 
> Okay, I'm done with this thread.  I hope you have better luck in the future with Spice.

C'mon. You know better than to be that easily offended, right?

Alex

Re: [Qemu-devel] Spice project is now open

[Anthony Liguori]

Alexander Graf wrote:
> On 11.12.2009, at 18:16, Anthony Liguori wrote:
>
>   
>> Yaniv Kamay wrote:
>>     
>>>> It already has.  It's not a git tree with staged patches.  It's a tarball release of a really old version of kvm-userspace that's called
>>>>
>>>> 'vdesktop'.
>>>>    
>>>>         
>>> This guy is evil and he is motivate by personal agenda. I hope you all will
>>> wakeup.
>>>  
>>>       
>> Okay, I'm done with this thread.  I hope you have better luck in the future with Spice.
>>     
>
> C'mon. You know better than to be that easily offended, right?
>   

This is clearly not a productive discussion so I don't see the point in 
continuing it (and yes, I know I just did ;-)).

Regards,

Anthony Liguori

Re: [Qemu-devel] Spice project is now open

[Chris Wright]

* Anthony Liguori (anthony@codemonkey.ws) wrote:
> Chris Wright wrote:
>>> That's a fork like it or not.
>>>     
>>
>> It is a branch of work.  The branch has been done without community
>> interaction, so yes, it looks like a fork.
>
> Branches don't carry independent names like "vdesktop".  They don't  
> carry their own version strings like 0.4.

That's true.  It's not unusual to see things like this when a project has
done all of its work out-of-tree.  The classic difficulty of maintaining
a large set of changes out-of-tree.

thanks,
-chris

Re: [Qemu-devel] Spice project is now open

[Johannes Schindelin]

Hi,

On Fri, 11 Dec 2009, Anthony Liguori wrote:

> > I'm not getting into this discussion and is not going to happen, you 
> > have all the necessary information on spiec-space.org in order to take 
> > intelligent decision. The QEMU community can choose to reject Spice if 
> > it decide to do so.
> >   
> 
> There's nothing to reject.  You haven't posted patches.
> 
> When you do post patches, if you can't/won't offer an explanation as to why
> it's better than what we already have, then they will be rejected.

It is nice to see the cozy and nice welcome.

For the record, I have nothing to do with SPICE, other than reading 
Slashdot to find out that SPICE was Open Sourced.

And for another record, nothing can be as instable as VNC support in 
QEmu has turned out to be, so I would not be so negative about something 
that was tried and tested for a long time, certainly not when I was 
relying on a proprietary and not-at-all documented VNC extension that does 
not even have an appropriate name.

Ciao,
Dscho

Re: [Qemu-devel] Spice project is now open

[Izik Eidus]

On Fri, 11 Dec 2009 09:57:48 -0600
Anthony Liguori <anthony@codemonkey.ws> wrote:

> Yaniv Kamay wrote:
> > Hi,
> >
> > Spice project is now open, for more information visit
> > http://spice-space.org, due to a server relocation the site will be
> > down during this weekend.
> >
> > Spice ship patched QEMU based on fairly old KVM snapshot as a
> > reference implementation. The Spice team plane to push all the
> > relevant bits into QEMU upstream.
> >   
> 
> Historically, we have not supported multiple display mechanisms
> favoring making one mechanism as good as it can be.
> 
> Supporting both Spice and VNC would go against this policy.  It's not 
> outside the realm of possibility, but there has to be a good 
> justification for it.
> 
> We need to separate the advantages of having a paravirtual display 
> driver from the advantages of a remote display protocol.  For
> instance, VNC is capable of doing ARGB cursor offloading to the
> client.  We do not support it in QEMU because the VGA drivers we
> emulate do not support this functionality.  Likewise, VNC can support
> sound tunneling and QEMU does implement this (although virt-manager
> does not yet).
> 
> So from a protocol perspective, what are the advantages of Spice over
> VNC?


Spice desgien is highly diffrence than VNC
The first thing about spice is that it isnt just a framebuffer drawing
and not a bitmaps protocol.

Spice protocl support multiple graphics commands, multiple surfaces
drawings, Spice is desgined to render as less as it can on the server
and instead to render on the client side much of the work,
To achive this spice use all kind of techniques such as depth viewing
tree.

We already have patchs that support offscreen surfaces -> the
architacture for high end 3d, this make things even more complicated.

Spice is a library, it is library for remote display, it handle by
itself all the connection between the spice client to the host that run
the guest, it include:
sound, display, keyboard, usb, network tunneling (for printers) and so
on...

The patchs that we wanted to push into qemu were what is called VDI
interfaces, it allow to qemu work with what ever interface it want,
what so bad about that?

I think we should allow freedom of choice to the users to decide what
protcol they want to use, Spice and VNC are all diffrent and were born
to meet diffrent goals.

I would happy to answer more questions if anyone have

Thanks.


> 
> Obviously, the disadvantages are that for all practical purposes,
> it's a closed protocol.  While there is now a specification, there is
> not a clear mechanism for extending it by third parties.  VNC has a
> published protocol and there's a documented process for extending by
> third parties.  There are a large number of existing VNC clients so
> from an interoperability perspective, VNC clearly wins.
> 
> Since VNC is extensible (and we've extended it many times for QEMU),
> if Spice possesses unique encoding mechanisms that are advantageous,
> why wouldn't we just add those mechanisms to VNC as an extension?
> 
> Regards,
> 
> Anthony Liguori
> 
> 

Re: [Qemu-devel] Spice project is now open

[Glauber Costa]

>> It already has.  It's not a git tree with staged patches.  It's a
>> tarball release of a really old version of kvm-userspace that's called
>>
>> 'vdesktop'.
>
>
> This guy is evil and he is motivate by personal agenda. I hope you all will
> wakeup.
>

I don't see anthony with any specific agenda here than making qemu as best
as it can get. If he is evil, I'm the devil myself.

-- 
Glauber  Costa.
"Free as in Freedom"
http://glommer.net

"The less confident you are, the more serious you have to act."

Re: [Qemu-devel] Spice project is now open

[Ben Taylor]

On Fri, Dec 11, 2009 at 6:48 PM, Izik Eidus <ieidus@redhat.com> wrote:
> On Fri, 11 Dec 2009 09:57:48 -0600
> Anthony Liguori <anthony@codemonkey.ws> wrote:
>
>> Yaniv Kamay wrote:
>> > Hi,
>> >
>> > Spice project is now open, for more information visit
>> > http://spice-space.org, due to a server relocation the site will be
>> > down during this weekend.
>> >
>> > Spice ship patched QEMU based on fairly old KVM snapshot as a
>> > reference implementation. The Spice team plane to push all the
>> > relevant bits into QEMU upstream.
>> >
>>
>> Historically, we have not supported multiple display mechanisms
>> favoring making one mechanism as good as it can be.
>>
>> Supporting both Spice and VNC would go against this policy.  It's not
>> outside the realm of possibility, but there has to be a good
>> justification for it.
>>
>> We need to separate the advantages of having a paravirtual display
>> driver from the advantages of a remote display protocol.  For
>> instance, VNC is capable of doing ARGB cursor offloading to the
>> client.  We do not support it in QEMU because the VGA drivers we
>> emulate do not support this functionality.  Likewise, VNC can support
>> sound tunneling and QEMU does implement this (although virt-manager
>> does not yet).
>>
>> So from a protocol perspective, what are the advantages of Spice over
>> VNC?
>
>
> Spice desgien is highly diffrence than VNC
> The first thing about spice is that it isnt just a framebuffer drawing
> and not a bitmaps protocol.
>
> Spice protocl support multiple graphics commands, multiple surfaces
> drawings, Spice is desgined to render as less as it can on the server
> and instead to render on the client side much of the work,
> To achive this spice use all kind of techniques such as depth viewing
> tree.
>
> We already have patchs that support offscreen surfaces -> the
> architacture for high end 3d, this make things even more complicated.
>
> Spice is a library, it is library for remote display, it handle by
> itself all the connection between the spice client to the host that run
> the guest, it include:
> sound, display, keyboard, usb, network tunneling (for printers) and so
> on...
>
> The patchs that we wanted to push into qemu were what is called VDI
> interfaces, it allow to qemu work with what ever interface it want,
> what so bad about that?
>
> I think we should allow freedom of choice to the users to decide what
> protcol they want to use, Spice and VNC are all diffrent and were born
> to meet diffrent goals.
>
> I would happy to answer more questions if anyone have

I think the simple point is that, AFAICS, the spice folks are expecting
the qemu team to integrate their big ugly tarball, instead of doing what
everyone else does, which is forward port everything to current head
and then provide a current set of patches against GIT head.

Anything else is just a waste of time. The paths both projects are
at are too far apart.

Re: [Qemu-devel] Spice project is now open

[Izik Eidus]

On Fri, 11 Dec 2009 20:48:28 +0200
Izik Eidus <ieidus@redhat.com> wrote:

> On Fri, 11 Dec 2009 09:57:48 -0600
> Anthony Liguori <anthony@codemonkey.ws> wrote:
> 
> > Yaniv Kamay wrote:
> > > Hi,
> > >
> > > Spice project is now open, for more information visit
> > > http://spice-space.org, due to a server relocation the site will
> > > be down during this weekend.
> > >
> > > Spice ship patched QEMU based on fairly old KVM snapshot as a
> > > reference implementation. The Spice team plane to push all the
> > > relevant bits into QEMU upstream.
> > >   
> > 
> > Historically, we have not supported multiple display mechanisms
> > favoring making one mechanism as good as it can be.
> > 
> > Supporting both Spice and VNC would go against this policy.  It's
> > not outside the realm of possibility, but there has to be a good 
> > justification for it.
> > 
> > We need to separate the advantages of having a paravirtual display 
> > driver from the advantages of a remote display protocol.  For
> > instance, VNC is capable of doing ARGB cursor offloading to the
> > client.  We do not support it in QEMU because the VGA drivers we
> > emulate do not support this functionality.  Likewise, VNC can
> > support sound tunneling and QEMU does implement this (although
> > virt-manager does not yet).
> > 
> > So from a protocol perspective, what are the advantages of Spice
> > over VNC?
> 
> 
> Spice desgien is highly diffrence than VNC
> The first thing about spice is that it isnt just a framebuffer drawing
> and not a bitmaps protocol.
> 
> Spice protocl support multiple graphics commands, multiple surfaces
> drawings, Spice is desgined to render as less as it can on the server
> and instead to render on the client side much of the work,
> To achive this spice use all kind of techniques such as depth viewing
> tree.
> 
> We already have patchs that support offscreen surfaces -> the
> architacture for high end 3d, this make things even more complicated.
> 
> Spice is a library, it is library for remote display, it handle by
> itself all the connection between the spice client to the host that
> run the guest, it include:
> sound, display, keyboard, usb, network tunneling (for printers) and so
> on...
> 

I want to add that qemu is not the sole user of spice, Spice will be
used as a protocol to connect into physical windows/linux machines....

So how can we change the library just for qemu?

Re: [Qemu-devel] Spice project is now open

[malc]

On Fri, 11 Dec 2009, Izik Eidus wrote:

> On Fri, 11 Dec 2009 09:57:48 -0600
> Anthony Liguori <anthony@codemonkey.ws> wrote:
> 
[..snip..]

> 
> Spice desgien is highly diffrence than VNC
> The first thing about spice is that it isnt just a framebuffer drawing
> and not a bitmaps protocol.
> 
> Spice protocl support multiple graphics commands, multiple surfaces
> drawings, Spice is desgined to render as less as it can on the server
> and instead to render on the client side much of the work,
> To achive this spice use all kind of techniques such as depth viewing
> tree.
> 
> We already have patchs that support offscreen surfaces -> the
> architacture for high end 3d, this make things even more complicated.
> 
> Spice is a library, it is library for remote display, it handle by
> itself all the connection between the spice client to the host that run
> the guest, it include:
> sound, display, keyboard, usb, network tunneling (for printers) and so
> on...
> 
> The patchs that we wanted to push into qemu were what is called VDI
> interfaces, it allow to qemu work with what ever interface it want,
> what so bad about that?
> 
> I think we should allow freedom of choice to the users to decide what
> protcol they want to use, Spice and VNC are all diffrent and were born
> to meet diffrent goals.
> 
> I would happy to answer more questions if anyone have

Any particular reason for implementing audio as a driver instead of
a capture?

-- 
mailto:av1474@comtv.ru

Re: [Qemu-devel] Spice project is now open

[Anthony Liguori]

Hi Izik,

Thanks for the explanation.

Izik Eidus wrote:
>> So from a protocol perspective, what are the advantages of Spice over
>> VNC?
>>     
>
>
> Spice desgien is highly diffrence than VNC
> The first thing about spice is that it isnt just a framebuffer drawing
> and not a bitmaps protocol.
>
> Spice protocl support multiple graphics commands,

VNC actually does have high level 2d commands like CopyRect.  The higher 
end encodings (like Tight and ZRLE) provide for mechanisms to do 
operations like fill even with different types of patterns.

Do you have any performance data that demonstrates where SPICE does well 
compared to something like VNC?

>  multiple surfaces
> drawings,

VNC does not have a notion of off-screen pixmaps but it would be pretty 
easy to add.  I think the simpliest approach would be to introduce the 
notion of a Viewport which clips the visible screen to a smaller size.  
That way, you could resize the screen to 2x or 3x the viewable
screen.  You could us things like CopyRect to blt from an off-screen 
surface to the on-screen surface.  I think the real question though is 
how much of a win is off-screen drawing?

We've always been very limited by the VGA devices we emulate so we've 
never really tried to make the most out of VNC.

>  Spice is desgined to render as less as it can on the server
> and instead to render on the client side much of the work,
> To achive this spice use all kind of techniques such as depth viewing
> tree.
>   

I'm not familiar with what a "depth viewing tree".  Can you elaborate?

> The patchs that we wanted to push into qemu were what is called VDI
> interfaces, it allow to qemu work with what ever interface it want,
> what so bad about that?
>   

Those patches never made it to the list.

> I think we should allow freedom of choice to the users to decide what
> protcol they want to use, Spice and VNC are all diffrent and were born
> to meet diffrent goals.
>   

What would be ideal, is if there was a mechanism whereas a client could 
connect to the VNC server, and get VNC traffic if it's a normal VNC 
client, but if it was a smarter client, got a more sophisticated 
stream.  If that was something that was Spice or Spice-like, that would 
be perfect.

But to introduce another protocol where a user has to make a choice to 
use Spice over VNC, I think we need a really good justification for 
that.  It's really about complexity.  A user shouldn't have to know 
about Spice or VNC.  They shouldn't have to contemplate the trade-offs 
of whether their management tool is aware or not.  It should Just Work.

> I would happy to answer more questions if anyone have
>   

Thanks.

Regards,

Anthony Liguori

Re: [Qemu-devel] Spice project is now open

[Izik Eidus]

On Fri, 11 Dec 2009 18:57:17 +0000
Ben Taylor <bentaylor.solx86@gmail.com> wrote:

> I think the simple point is that, AFAICS, the spice folks are
> expecting the qemu team to integrate their big ugly tarball, instead
> of doing what everyone else does, which is forward port everything to
> current head and then provide a current set of patches against GIT
> head.


This was never the issue.
We have planes to send the vdi interfaces to qemu, we just open sourced
spice, it take time.

I think you guys totaly didnt understand us.

We will send patchs to qemu-devel adding the vdi interfaces.

But again spice itself is library and it have more than one user other
than qemu, so the way the protocol work is spice specific and not qemu
specific.

And this why we are adding the VDI interfaces, it allow qemu to work
with whatever library the users will want to use.

What so bad about that?

> 
> Anything else is just a waste of time. The paths both projects are
> at are too far apart.

Re: [Qemu-devel] Spice project is now open

[Anthony Liguori]

Izik Eidus wrote:
> I want to add that qemu is not the sole user of spice, Spice will be
> used as a protocol to connect into physical windows/linux machines....
>
> So how can we change the library just for qemu?
>   
A library is not necessarily a problem.

What would be a probably is if the library maintains guest visible 
state.  There are a lot of advantages to keeping qemu as the sole 
maintainer of guest visible state as it simplifies things like live 
migration.  More importantly, it allows us to do things like Avi's 
suggested security sandboxing using seccomp().  For that to work, we 
need to make sure that we can isolate any code that interacts directly 
with the guest.

Regards,

Anthony Liguori

Re: [Qemu-devel] Spice project is now open

[Glauber Costa]

>>
>> Spice is a library, it is library for remote display, it handle by
>> itself all the connection between the spice client to the host that
>> run the guest, it include:
>> sound, display, keyboard, usb, network tunneling (for printers) and so
>> on...
>>
>
> I want to add that qemu is not the sole user of spice, Spice will be
> used as a protocol to connect into physical windows/linux machines....
>
> So how can we change the library just for qemu?
>
I don't fully understand spice yet, but what's the difficulty here?
libraries changes every single day to try to acomodate for the needs
of specific users, be it through generalizations, shims, or whatever.

This is just another day in the OSS world.


-- 
Glauber  Costa.
"Free as in Freedom"
http://glommer.net

"The less confident you are, the more serious you have to act."

Re: [Qemu-devel] Spice project is now open

[Glauber Costa]

>> I think we should allow freedom of choice to the users to decide what
>> protcol they want to use, Spice and VNC are all diffrent and were born
>> to meet diffrent goals.
>>
>> I would happy to answer more questions if anyone have
>
> I think the simple point is that, AFAICS, the spice folks are expecting
> the qemu team to integrate their big ugly tarball, instead of doing what
> everyone else does, which is forward port everything to current head
> and then provide a current set of patches against GIT head.
>
> Anything else is just a waste of time. The paths both projects are
> at are too far apart.
>

More important than forward porting, is respecting the design decisions
a huge community has agreed upon. Of course, when you become part
of that community, you can try to shift these designs towards your goals,
but trying to force them is just ridiculous.

That said, I do believe spice can play a essential role in making us go
forward, but the attitude towards it has to change quite a bit.

-- 
Glauber  Costa.
"Free as in Freedom"
http://glommer.net

"The less confident you are, the more serious you have to act."

Re: [Qemu-devel] Spice project is now open

[Izik Eidus]

On Fri, 11 Dec 2009 22:03:33 +0300 (MSK)
malc <av1474@comtv.ru> wrote:

> On Fri, 11 Dec 2009, Izik Eidus wrote:
> 
> > On Fri, 11 Dec 2009 09:57:48 -0600
> > Anthony Liguori <anthony@codemonkey.ws> wrote:
> > 
> [..snip..]
> 
> > 
> > Spice desgien is highly diffrence than VNC
> > The first thing about spice is that it isnt just a framebuffer
> > drawing and not a bitmaps protocol.
> > 
> > Spice protocl support multiple graphics commands, multiple surfaces
> > drawings, Spice is desgined to render as less as it can on the
> > server and instead to render on the client side much of the work,
> > To achive this spice use all kind of techniques such as depth
> > viewing tree.
> > 
> > We already have patchs that support offscreen surfaces -> the
> > architacture for high end 3d, this make things even more
> > complicated.
> > 
> > Spice is a library, it is library for remote display, it handle by
> > itself all the connection between the spice client to the host that
> > run the guest, it include:
> > sound, display, keyboard, usb, network tunneling (for printers) and
> > so on...
> > 
> > The patchs that we wanted to push into qemu were what is called VDI
> > interfaces, it allow to qemu work with what ever interface it want,
> > what so bad about that?
> > 
> > I think we should allow freedom of choice to the users to decide
> > what protcol they want to use, Spice and VNC are all diffrent and
> > were born to meet diffrent goals.
> > 
> > I would happy to answer more questions if anyone have
> 
> Any particular reason for implementing audio as a driver instead of
> a capture?


Spice doesnt have paravirtual audio driver, it use the AC97 device.
> 

Re: [Qemu-devel] Spice project is now open

[Glauber Costa]

>
> But to introduce another protocol where a user has to make a choice to use
> Spice over VNC, I think we need a really good justification for that.  It's
> really about complexity.  A user shouldn't have to know about Spice or VNC.
>  They shouldn't have to contemplate the trade-offs of whether their
> management tool is aware or not.  It should Just Work.
>
>> I would happy to answer more questions if anyone have
>>
>
> Thanks.

Just to make a point clear:

AFAIU, there are two parts of qemu spice support. The protocol (vnc-like), and
the guest device (vga-like). I am right?


-- 
Glauber  Costa.
"Free as in Freedom"
http://glommer.net

"The less confident you are, the more serious you have to act."

Re: [Qemu-devel] Spice project is now open

[Izik Eidus]

On Fri, 11 Dec 2009 13:04:02 -0600
Anthony Liguori <anthony@codemonkey.ws> wrote:

> Hi Izik,
> 
> Thanks for the explanation.
> 
> Izik Eidus wrote:
> >> So from a protocol perspective, what are the advantages of Spice
> >> over VNC?
> >>     
> >
> >
> > Spice desgien is highly diffrence than VNC
> > The first thing about spice is that it isnt just a framebuffer
> > drawing and not a bitmaps protocol.
> >
> > Spice protocl support multiple graphics commands,
> 
> VNC actually does have high level 2d commands like CopyRect.  The
> higher end encodings (like Tight and ZRLE) provide for mechanisms to
> do operations like fill even with different types of patterns.
> 
> Do you have any performance data that demonstrates where SPICE does
> well compared to something like VNC?

I should speek with the marketing guys, will be able to answer on that
specific question in few days.


But simple 2D Commands are just not enougth for spice.
We have multiple drawing surfaces, that are depended on each other.
We Dont renender untill the very moment that the guest try to read its
video memory, we have video streaming, and we have cache based by the
guest driver.
We have private channels for stuff like keyboard, display and so on...


> 
> >  multiple surfaces
> > drawings,
> 
> VNC does not have a notion of off-screen pixmaps but it would be
> pretty easy to add.  I think the simpliest approach would be to
> introduce the notion of a Viewport which clips the visible screen to
> a smaller size. That way, you could resize the screen to 2x or 3x the
> viewable screen.  You could us things like CopyRect to blt from an
> off-screen surface to the on-screen surface.  I think the real
> question though is how much of a win is off-screen drawing?
> 
> We've always been very limited by the VGA devices we emulate so we've 
> never really tried to make the most out of VNC.
> 
> >  Spice is desgined to render as less as it can on the server
> > and instead to render on the client side much of the work,
> > To achive this spice use all kind of techniques such as depth
> > viewing tree.
> >   
> 
> I'm not familiar with what a "depth viewing tree".  Can you elaborate?

In it simplest way of working, we will take the simplest case of what
it is doing:
If you have application that rendered a window, and then it renendered
another window on top of it, you dont want to send the commands that
rendered the old window, beacuse the new commands hide the older one...

When the guest will try to read the video memory, you wont want the
server to render the old commands.

But you will want to rendner the old commands in case the new commands
are depended on the older commands...

> 
> > The patchs that we wanted to push into qemu were what is called VDI
> > interfaces, it allow to qemu work with what ever interface it want,
> > what so bad about that?
> >   
> 
> Those patches never made it to the list.


It will take some time, it is in our todo, we never expected qemu to
merge spice without this patches!


> 
> > I think we should allow freedom of choice to the users to decide
> > what protcol they want to use, Spice and VNC are all diffrent and
> > were born to meet diffrent goals.
> >   
> 
> What would be ideal, is if there was a mechanism whereas a client
> could connect to the VNC server, and get VNC traffic if it's a normal
> VNC client, but if it was a smarter client, got a more sophisticated 
> stream.  If that was something that was Spice or Spice-like, that
> would be perfect.
> 
> But to introduce another protocol where a user has to make a choice
> to use Spice over VNC, I think we need a really good justification
> for that.  It's really about complexity.  A user shouldn't have to
> know about Spice or VNC.  They shouldn't have to contemplate the
> trade-offs of whether their management tool is aware or not.  It
> should Just Work.


This why we suggest the VDI interface, to solve all this choicses we
made for the users,

Think about qemu give infastracture to multiple librarys to use it?
For example one user can use qemu with  VNC, one with SPICE, and one
can use qemu with diffrent private local rendering soultion (for highly
fast local 3d rendering...)


> 
> > I would happy to answer more questions if anyone have
> >   
> 
> Thanks.
> 
> Regards,
> 
> Anthony Liguori

Re: [Qemu-devel] Spice project is now open

[Izik Eidus]

On Fri, 11 Dec 2009 13:06:47 -0600
Anthony Liguori <anthony@codemonkey.ws> wrote:

> Izik Eidus wrote:
> > I want to add that qemu is not the sole user of spice, Spice will be
> > used as a protocol to connect into physical windows/linux
> > machines....
> >
> > So how can we change the library just for qemu?
> >   
> A library is not necessarily a problem.
> 
> What would be a probably is if the library maintains guest visible 
> state.  There are a lot of advantages to keeping qemu as the sole 
> maintainer of guest visible state as it simplifies things like live 
> migration.  More importantly, it allows us to do things like Avi's 
> suggested security sandboxing using seccomp().  For that to work, we 
> need to make sure that we can isolate any code that interacts
> directly with the guest.

Spice guest visible state inside qemu is just its PCI QXL device.
This part is qemu specificed.


> 
> Regards,
> 
> Anthony Liguori

Re: [Qemu-devel] Spice project is now open

[Izik Eidus]

On Fri, 11 Dec 2009 17:07:13 -0200
Glauber Costa <glommer@gmail.com> wrote:

> >>
> >> Spice is a library, it is library for remote display, it handle by
> >> itself all the connection between the spice client to the host that
> >> run the guest, it include:
> >> sound, display, keyboard, usb, network tunneling (for printers)
> >> and so on...
> >>
> >
> > I want to add that qemu is not the sole user of spice, Spice will be
> > used as a protocol to connect into physical windows/linux
> > machines....
> >
> > So how can we change the library just for qemu?
> >
> I don't fully understand spice yet, but what's the difficulty here?
> libraries changes every single day to try to acomodate for the needs
> of specific users, be it through generalizations, shims, or whatever.
> 
> This is just another day in the OSS world.
> 
> 

We are working on spice for physical machines, the library contain all
what need for remote displays.

Re: [Qemu-devel] Spice project is now open

[malc]

On Fri, 11 Dec 2009, Izik Eidus wrote:

> On Fri, 11 Dec 2009 22:03:33 +0300 (MSK)
> malc <av1474@comtv.ru> wrote:
> 
> > On Fri, 11 Dec 2009, Izik Eidus wrote:
> > 
> > > On Fri, 11 Dec 2009 09:57:48 -0600
> > > Anthony Liguori <anthony@codemonkey.ws> wrote:
> > > 
> > [..snip..]
> > 
> > > 

[..snip..]

> > 
> > Any particular reason for implementing audio as a driver instead of
> > a capture?
> 
> 
> Spice doesnt have paravirtual audio driver, it use the AC97 device.

Yes it has - interface_audio_driver in audio/vd_interface_audio.c

-- 
mailto:av1474@comtv.ru

Re: [Qemu-devel] Spice project is now open

[Mark McLoughlin]

On Fri, 2009-12-11 at 13:04 -0600, Anthony Liguori wrote:
> But to introduce another protocol where a user has to make a choice to 
> use Spice over VNC, I think we need a really good justification for 
> that.  It's really about complexity.  A user shouldn't have to know 
> about Spice or VNC.  They shouldn't have to contemplate the trade-offs 
> of whether their management tool is aware or not.  It should Just Work. 

That's a good goal.

If we add a new protocol, we could achieve the same thing by allowing
qemu support both VNC and Spice at runtime. Then you just need a client
like virt-viewer that can handle both protocols, and old VNC clients
will continue to be able to connect to newer qemu.

Cheers,
Mark.

Re: [Qemu-devel] Spice project is now open

[Izik Eidus]

On Fri, 11 Dec 2009 17:15:02 -0200
Glauber Costa <glommer@gmail.com> wrote:

> >
> > But to introduce another protocol where a user has to make a choice
> > to use Spice over VNC, I think we need a really good justification
> > for that.  It's really about complexity.  A user shouldn't have to
> > know about Spice or VNC. They shouldn't have to contemplate the
> > trade-offs of whether their management tool is aware or not.  It
> > should Just Work.
> >
> >> I would happy to answer more questions if anyone have
> >>
> >
> > Thanks.
> 
> Just to make a point clear:
> 
> AFAIU, there are two parts of qemu spice support. The protocol
> (vnc-like), and the guest device (vga-like). I am right?
> 
> 

qemu spice support is built by just 2 parts

qxl pci device - para virtual display device,
vdi interfaces - what allow to qemu to connect into the spice library.

Re: [Qemu-devel] Spice project is now open

[Anthony Liguori]

Izik Eidus wrote:
> I should speek with the marketing guys, will be able to answer on that
> specific question in few days.
>
>
> But simple 2D Commands are just not enougth for spice.
> We have multiple drawing surfaces, that are depended on each other.
> We Dont renender untill the very moment that the guest try to read its
> video memory, we have video streaming, and we have cache based by the
> guest driver.
> We have private channels for stuff like keyboard, display and so on...
>   

The video streaming is an encoding heuristic though, right?

The lack of guest visible rendering is interesting.

  

>> I'm not familiar with what a "depth viewing tree".  Can you elaborate?
>>     
>
> In it simplest way of working, we will take the simplest case of what
> it is doing:
> If you have application that rendered a window, and then it renendered
> another window on top of it, you dont want to send the commands that
> rendered the old window, beacuse the new commands hide the older one...
>   

Ah, this is unique to a windowing protocol.  A framebuffer protocol does 
not have to worry about this because the OS does it for you.

How well does this work with a Linux guest?  To get a lot of this level 
of information, you have to hook in at the X protocol level (which is 
what NX does).  Can you really do much at the X driver level?

Of course, a lot of interesting stuff (like drawing ops and text 
rendering) doesn't even happen in the X server these days.

>>> I think we should allow freedom of choice to the users to decide
>>> what protcol they want to use, Spice and VNC are all diffrent and
>>> were born to meet diffrent goals.
>>>   
>>>       
>> What would be ideal, is if there was a mechanism whereas a client
>> could connect to the VNC server, and get VNC traffic if it's a normal
>> VNC client, but if it was a smarter client, got a more sophisticated 
>> stream.  If that was something that was Spice or Spice-like, that
>> would be perfect.
>>
>> But to introduce another protocol where a user has to make a choice
>> to use Spice over VNC, I think we need a really good justification
>> for that.  It's really about complexity.  A user shouldn't have to
>> know about Spice or VNC.  They shouldn't have to contemplate the
>> trade-offs of whether their management tool is aware or not.  It
>> should Just Work.
>>     
>
>
> This why we suggest the VDI interface, to solve all this choicses we
> made for the users,
>   

Okay, but it's hard to evaluate that suggestion without seeing the VDI 
interface :-)

> Think about qemu give infastracture to multiple librarys to use it?
> For example one user can use qemu with  VNC, one with SPICE, and one
> can use qemu with diffrent private local rendering soultion (for highly
> fast local 3d rendering...)
>   

As I said, I don't have a problem with externalizing things.  I think 
there's some discussion about how best to do that.  For instance, I 
think we want to avoid shared library plugins as it introduces a good 
deal of instability into our address space.

Regards,

Anthony Liguori

Re: [Qemu-devel] Spice project is now open

[Izik Eidus]

On Fri, 11 Dec 2009 22:24:38 +0300 (MSK)
malc <av1474@comtv.ru> wrote:

> On Fri, 11 Dec 2009, Izik Eidus wrote:
> 
> > On Fri, 11 Dec 2009 22:03:33 +0300 (MSK)
> > malc <av1474@comtv.ru> wrote:
> > 
> > > On Fri, 11 Dec 2009, Izik Eidus wrote:
> > > 
> > > > On Fri, 11 Dec 2009 09:57:48 -0600
> > > > Anthony Liguori <anthony@codemonkey.ws> wrote:
> > > > 
> > > [..snip..]
> > > 
> > > > 
> 
> [..snip..]
> 
> > > 
> > > Any particular reason for implementing audio as a driver instead
> > > of a capture?
> > 
> > 
> > Spice doesnt have paravirtual audio driver, it use the AC97 device.
> 
> Yes it has - interface_audio_driver in audio/vd_interface_audio.c
> 

I think the file name here is missleading you...

Re: [Qemu-devel] Spice project is now open

[Glauber Costa]

On Fri, Dec 11, 2009 at 5:22 PM, Izik Eidus <ieidus@redhat.com> wrote:
> On Fri, 11 Dec 2009 13:06:47 -0600
> Anthony Liguori <anthony@codemonkey.ws> wrote:
>
>> Izik Eidus wrote:
>> > I want to add that qemu is not the sole user of spice, Spice will be
>> > used as a protocol to connect into physical windows/linux
>> > machines....
>> >
>> > So how can we change the library just for qemu?
>> >
>> A library is not necessarily a problem.
>>
>> What would be a probably is if the library maintains guest visible
>> state.  There are a lot of advantages to keeping qemu as the sole
>> maintainer of guest visible state as it simplifies things like live
>> migration.  More importantly, it allows us to do things like Avi's
>> suggested security sandboxing using seccomp().  For that to work, we
>> need to make sure that we can isolate any code that interacts
>> directly with the guest.
>
> Spice guest visible state inside qemu is just its PCI QXL device.
> This part is qemu specificed.
>

But this part can work together with vnc with no problems, right?
If this is so, why don't we just start by merging it, while trying
to make the case for the rendering protocol in parallel ?

-- 
Glauber  Costa.
"Free as in Freedom"
http://glommer.net

"The less confident you are, the more serious you have to act."

Re: [Qemu-devel] Spice project is now open

[Anthony Liguori]

Mark McLoughlin wrote:
> On Fri, 2009-12-11 at 13:04 -0600, Anthony Liguori wrote:
>   
>> But to introduce another protocol where a user has to make a choice to 
>> use Spice over VNC, I think we need a really good justification for 
>> that.  It's really about complexity.  A user shouldn't have to know 
>> about Spice or VNC.  They shouldn't have to contemplate the trade-offs 
>> of whether their management tool is aware or not.  It should Just Work. 
>>     
>
> That's a good goal.
>
> If we add a new protocol, we could achieve the same thing by allowing
> qemu support both VNC and Spice at runtime. Then you just need a client
> like virt-viewer that can handle both protocols, and old VNC clients
> will continue to be able to connect to newer qemu.
>   

Supporting them at the same time could be potentially challenging.  You 
would need to render Spice locally in qemu in order to expose it via vnc.

Another nasty bit is that two protocols mean two different sets of 
authentication mechanisms.  Does Spice support SASL based 
authentication?  Could it make sense to essentially tunnel Spice through 
vnc in order to reuse the existing authentication infrastructure?

Regards,

Anthony Liguori

Re: [Qemu-devel] Spice project is now open

[Izik Eidus]

On Fri, 11 Dec 2009 13:30:22 -0600
Anthony Liguori <anthony@codemonkey.ws> wrote:

> Izik Eidus wrote:
> > I should speek with the marketing guys, will be able to answer on
> > that specific question in few days.
> >
> >
> > But simple 2D Commands are just not enougth for spice.
> > We have multiple drawing surfaces, that are depended on each other.
> > We Dont renender untill the very moment that the guest try to read
> > its video memory, we have video streaming, and we have cache based
> > by the guest driver.
> > We have private channels for stuff like keyboard, display and so
> > on... 
> 
> The video streaming is an encoding heuristic though, right?
> 
> The lack of guest visible rendering is interesting.

The video streaming now is motiation jpeg due to patents problems.

What you mean lack of guest visible rendering?, I might didnt
understand you


> 
>   
> 
> >> I'm not familiar with what a "depth viewing tree".  Can you
> >> elaborate? 
> >
> > In it simplest way of working, we will take the simplest case of
> > what it is doing:
> > If you have application that rendered a window, and then it
> > renendered another window on top of it, you dont want to send the
> > commands that rendered the old window, beacuse the new commands
> > hide the older one... 
> 
> Ah, this is unique to a windowing protocol.  A framebuffer protocol
> does not have to worry about this because the OS does it for you.

Not true.
This is optimization for remote rendering, in physical machines we can
rendner what ever we want, it take more cpu to try to use trees in
order to render the right things....
But with remote machines, we dont want to stress the network, so we
want to transfer just what we really need.

> 
> How well does this work with a Linux guest?  To get a lot of this
> level of information, you have to hook in at the X protocol level
> (which is what NX does).  Can you really do much at the X driver
> level?

Well we have X driver, why would there be any problems with X?

Spice driver to X (I mean from the X prespective on things) is just
another display driver.


> 
> Of course, a lot of interesting stuff (like drawing ops and text 
> rendering) doesn't even happen in the X server these days.
> 
> >>> I think we should allow freedom of choice to the users to decide
> >>> what protcol they want to use, Spice and VNC are all diffrent and
> >>> were born to meet diffrent goals.
> >>>   
> >>>       
> >> What would be ideal, is if there was a mechanism whereas a client
> >> could connect to the VNC server, and get VNC traffic if it's a
> >> normal VNC client, but if it was a smarter client, got a more
> >> sophisticated stream.  If that was something that was Spice or
> >> Spice-like, that would be perfect.
> >>
> >> But to introduce another protocol where a user has to make a choice
> >> to use Spice over VNC, I think we need a really good justification
> >> for that.  It's really about complexity.  A user shouldn't have to
> >> know about Spice or VNC.  They shouldn't have to contemplate the
> >> trade-offs of whether their management tool is aware or not.  It
> >> should Just Work.
> >>     
> >
> >
> > This why we suggest the VDI interface, to solve all this choicses we
> > made for the users,
> >   
> 
> Okay, but it's hard to evaluate that suggestion without seeing the
> VDI interface :-)

No problems!
http://www.spice-space.org/docs/vd_interfaces.pdf

> 
> > Think about qemu give infastracture to multiple librarys to use it?
> > For example one user can use qemu with  VNC, one with SPICE, and one
> > can use qemu with diffrent private local rendering soultion (for
> > highly fast local 3d rendering...)
> >   
> 
> As I said, I don't have a problem with externalizing things.  I think 
> there's some discussion about how best to do that.  For instance, I 
> think we want to avoid shared library plugins as it introduces a good 
> deal of instability into our address space.

Well why libc is diffrent then?

> 
> Regards,
> 
> Anthony Liguori

Re: [Qemu-devel] Spice project is now open

[Chris Wright]

* Glauber Costa (glommer@gmail.com) wrote:
> >
> > But to introduce another protocol where a user has to make a choice to use
> > Spice over VNC, I think we need a really good justification for that.  It's
> > really about complexity.  A user shouldn't have to know about Spice or VNC.
> >  They shouldn't have to contemplate the trade-offs of whether their
> > management tool is aware or not.  It should Just Work.
> >
> >> I would happy to answer more questions if anyone have
> >>
> >
> > Thanks.
> 
> Just to make a point clear:
> 
> AFAIU, there are two parts of qemu spice support. The protocol (vnc-like), and
> the guest device (vga-like). I am right?

There's also some qemu glue to deliver "desktop" to spice protocol.
Sometimes called the remoting API, or VDI.

thanks,
-chris

Re: [Qemu-devel] Spice project is now open

[Mark McLoughlin]

On Fri, 2009-12-11 at 13:38 -0600, Anthony Liguori wrote:
> Mark McLoughlin wrote:
> > On Fri, 2009-12-11 at 13:04 -0600, Anthony Liguori wrote:
> >   
> >> But to introduce another protocol where a user has to make a choice to 
> >> use Spice over VNC, I think we need a really good justification for 
> >> that.  It's really about complexity.  A user shouldn't have to know 
> >> about Spice or VNC.  They shouldn't have to contemplate the trade-offs 
> >> of whether their management tool is aware or not.  It should Just Work. 
> >>     
> >
> > That's a good goal.
> >
> > If we add a new protocol, we could achieve the same thing by allowing
> > qemu support both VNC and Spice at runtime. Then you just need a client
> > like virt-viewer that can handle both protocols, and old VNC clients
> > will continue to be able to connect to newer qemu.
> >   
> 
> Supporting them at the same time could be potentially challenging.  You 
> would need to render Spice locally in qemu in order to expose it via vnc.
> 
> Another nasty bit is that two protocols mean two different sets of 
> authentication mechanisms.  Does Spice support SASL based 
> authentication?  Could it make sense to essentially tunnel Spice through 
> vnc in order to reuse the existing authentication infrastructure?

I don't doubt there are challenges.

I think your requirement that old clients work with new servers and new
clients work with old servers is a good one. Maybe extending VNC is the
best way to get there, but it should be recognized there is another way
of achieving the same thing if Spice does require a new protocol.

The underlying goal is getting lost in the "Spice can't be a VNC
extension" discussion :-)

Cheers,
Mark.

Re: [Qemu-devel] Spice project is now open

[Anthony Liguori]

Izik Eidus wrote:
> On Fri, 11 Dec 2009 13:30:22 -0600
> Anthony Liguori <anthony@codemonkey.ws> wrote:
>
>   
>> Izik Eidus wrote:
>>     
>>> I should speek with the marketing guys, will be able to answer on
>>> that specific question in few days.
>>>
>>>
>>> But simple 2D Commands are just not enougth for spice.
>>> We have multiple drawing surfaces, that are depended on each other.
>>> We Dont renender untill the very moment that the guest try to read
>>> its video memory, we have video streaming, and we have cache based
>>> by the guest driver.
>>> We have private channels for stuff like keyboard, display and so
>>> on... 
>>>       
>> The video streaming is an encoding heuristic though, right?
>>
>> The lack of guest visible rendering is interesting.
>>     
>
> The video streaming now is motiation jpeg due to patents problems.
>   

The approach taken by THINC was to support just a YUV overlay.  That 
gets you half way there in terms of compressing a video stream.  Since 
most hardware provides YUV->RGB acceleration, it fits very well into 
existing driver architectures.  For instance, VMware VGA supports YUV 
overlays because X has the Xv interface for this.

The other important bit is tiling.  That's easy enough to support in 
something like VNC since it's rectangle based.  The one real missing bit 
is tile motion.  I would think you wouldn't get that with mjpeg anyway.

The other equally important piece is hardware scaling.  Obviously, if 
you have a normal desktop resolution and are full screening an NTSC dvd, 
you can save a huge amount of bandwidth by supporting a scaled overlay.

I think adding both of these things to VNC would be pretty easy.  I 
think the result would probably be better than a heuristic based mjpeg 
(simply because of the accelerated scaling).

Any thoughts on that?  Am I misunderstanding how the mjpeg works with 
Spice and QXL?

> What you mean lack of guest visible rendering?, I might didnt
> understand you
>   

Sorry, I meant what Spice does with video memory (that it doesn't render 
a bitmap until the guest tries to read video memory).  If I understood 
that correctly, it sounds very interesting.  Again, I'd love to see the 
perf details around that.
>>>> I'm not familiar with what a "depth viewing tree".  Can you
>>>> elaborate? 
>>>>         
>>> In it simplest way of working, we will take the simplest case of
>>> what it is doing:
>>> If you have application that rendered a window, and then it
>>> renendered another window on top of it, you dont want to send the
>>> commands that rendered the old window, beacuse the new commands
>>> hide the older one... 
>>>       
>> Ah, this is unique to a windowing protocol.  A framebuffer protocol
>> does not have to worry about this because the OS does it for you.
>>     
>
> Not true.
> This is optimization for remote rendering, in physical machines we can
> rendner what ever we want, it take more cpu to try to use trees in
> order to render the right things....
> But with remote machines, we dont want to stress the network, so we
> want to transfer just what we really need.
>   

If the z-order of the window is such that one window is not displayed, 
then it's contents will not be rendered.  In Windows, individual windows 
only receive a WM_PAINT message with the visible region.  Not all apps 
clip accordingly of course.

For X, only windows that are visible receive expose events and again, 
they're given a clipping region with what is actually displayed.

By the time we get to video memory, the display server has already 
straightened out what portions of the screen are visible and what 
aren't.  It will not render a hidden window and then render another 
window on top of it.

>> How well does this work with a Linux guest?  To get a lot of this
>> level of information, you have to hook in at the X protocol level
>> (which is what NX does).  Can you really do much at the X driver
>> level?
>>     
>
> Well we have X driver, why would there be any problems with X?
>   

A lot of the things in Spice (from a quick glance at the spec) are too 
high level for just an X driver.  For instance, there are glyph based 
operations presumably for text rendering.  There are also brush 
primitives.  While X has some support for these things, it's so old and 
broken that in modern applications, most toolkits just render to a local 
buffer, and then do a draw the image to the window.  That means the X 
server has no visibility into the fact that you're actually rendering 
text which means an X driver cannot take advantage of that information.

> Spice driver to X (I mean from the X prespective on things) is just
> another display driver.
>   

What's the performance compared to the Windows driver?

>>> Think about qemu give infastracture to multiple librarys to use it?
>>> For example one user can use qemu with  VNC, one with SPICE, and one
>>> can use qemu with diffrent private local rendering soultion (for
>>> highly fast local 3d rendering...)
>>>   
>>>       
>> As I said, I don't have a problem with externalizing things.  I think 
>> there's some discussion about how best to do that.  For instance, I 
>> think we want to avoid shared library plugins as it introduces a good 
>> deal of instability into our address space.
>>     
>
> Well why libc is diffrent then?
>   

libc is not a plugin.  It implements very well defined behaviors that 
have well understood behaviors.  Also, glibc generally does not crash 
:-)  I would not want a user to replace glibc with a different libc.

Regards,

Anthony Liguori

Re: [Qemu-devel] Spice project is now open

[Anthony Liguori]

Mark McLoughlin wrote:
> I don't doubt there are challenges.
>
> I think your requirement that old clients work with new servers and new
> clients work with old servers is a good one. Maybe extending VNC is the
> best way to get there, but it should be recognized there is another way
> of achieving the same thing if Spice does require a new protocol.
>
> The underlying goal is getting lost in the "Spice can't be a VNC
> extension" discussion :-)
>   

Fair point.

Regards,

Anthony Liguori

Re: [Qemu-devel] Spice project is now open

[malc]

On Fri, 11 Dec 2009, Izik Eidus wrote:

> On Fri, 11 Dec 2009 22:24:38 +0300 (MSK)
> malc <av1474@comtv.ru> wrote:
> 
> > On Fri, 11 Dec 2009, Izik Eidus wrote:
> > 
> > > On Fri, 11 Dec 2009 22:03:33 +0300 (MSK)
> > > malc <av1474@comtv.ru> wrote:
> > > 
> > > > On Fri, 11 Dec 2009, Izik Eidus wrote:
> > > > 
> > > > > On Fri, 11 Dec 2009 09:57:48 -0600
> > > > > Anthony Liguori <anthony@codemonkey.ws> wrote:
> > > > > 
> > > > [..snip..]
> > > > 
> > > > > 
> > 
> > [..snip..]
> > 
> > > > 
> > > > Any particular reason for implementing audio as a driver instead
> > > > of a capture?
> > > 
> > > 
> > > Spice doesnt have paravirtual audio driver, it use the AC97 device.
> > 
> > Yes it has - interface_audio_driver in audio/vd_interface_audio.c
> > 
> 
> I think the file name here is missleading you...

I think you just don't understand what i'm asking. Let me try to expand:
one way to implement audio interception is by having a special
audio_driver (wavaudio.c vd_interface_audio.c) the other is by using
a capture interface atop of existing driver (wavcapture.c vnc.c)

I was curious as to why the former was chosen.

-- 
mailto:av1474@comtv.ru

Re: [Qemu-devel] Spice project is now open

[Izik Eidus]

On Fri, 11 Dec 2009 13:51:53 -0600
Anthony Liguori <anthony@codemonkey.ws> wrote:

> Izik Eidus wrote:
> > On Fri, 11 Dec 2009 13:30:22 -0600
> > Anthony Liguori <anthony@codemonkey.ws> wrote:
> >
> >   
> >> Izik Eidus wrote:
> >>     
> >>> I should speek with the marketing guys, will be able to answer on
> >>> that specific question in few days.
> >>>
> >>>
> >>> But simple 2D Commands are just not enougth for spice.
> >>> We have multiple drawing surfaces, that are depended on each
> >>> other. We Dont renender untill the very moment that the guest try
> >>> to read its video memory, we have video streaming, and we have
> >>> cache based by the guest driver.
> >>> We have private channels for stuff like keyboard, display and so
> >>> on... 
> >>>       
> >> The video streaming is an encoding heuristic though, right?
> >>
> >> The lack of guest visible rendering is interesting.
> >>     
> >
> > The video streaming now is motiation jpeg due to patents problems.
> >   
> 
> The approach taken by THINC was to support just a YUV overlay.  That 
> gets you half way there in terms of compressing a video stream.
> Since most hardware provides YUV->RGB acceleration, it fits very well
> into existing driver architectures.  For instance, VMware VGA
> supports YUV overlays because X has the Xv interface for this.
> 
> The other important bit is tiling.  That's easy enough to support in 
> something like VNC since it's rectangle based.  The one real missing
> bit is tile motion.  I would think you wouldn't get that with mjpeg
> anyway.
> 
> The other equally important piece is hardware scaling.  Obviously, if 
> you have a normal desktop resolution and are full screening an NTSC
> dvd, you can save a huge amount of bandwidth by supporting a scaled
> overlay.
> 
> I think adding both of these things to VNC would be pretty easy.  I 
> think the result would probably be better than a heuristic based
> mjpeg (simply because of the accelerated scaling).
> 
> Any thoughts on that?  Am I misunderstanding how the mjpeg works with 
> Spice and QXL?


I personaly dont like mjpeg, and yes in the end of the day you can add
the video streaming into vnc, but what is the point here?

We acctuly want to kick away that video streaming, and move into the
DirectX and X video extentions video support (that will be made using
the qxl driver) - will give much better performence.


> 
> > What you mean lack of guest visible rendering?, I might didnt
> > understand you
> >   
> 
> Sorry, I meant what Spice does with video memory (that it doesn't
> render a bitmap until the guest tries to read video memory).  If I
> understood that correctly, it sounds very interesting.  Again, I'd
> love to see the perf details around that.
> >>>> I'm not familiar with what a "depth viewing tree".  Can you
> >>>> elaborate? 
> >>>>         
> >>> In it simplest way of working, we will take the simplest case of
> >>> what it is doing:
> >>> If you have application that rendered a window, and then it
> >>> renendered another window on top of it, you dont want to send the
> >>> commands that rendered the old window, beacuse the new commands
> >>> hide the older one... 
> >>>       
> >> Ah, this is unique to a windowing protocol.  A framebuffer protocol
> >> does not have to worry about this because the OS does it for you.
> >>     
> >
> > Not true.
> > This is optimization for remote rendering, in physical machines we
> > can rendner what ever we want, it take more cpu to try to use trees
> > in order to render the right things....
> > But with remote machines, we dont want to stress the network, so we
> > want to transfer just what we really need.
> >   
> 
> If the z-order of the window is such that one window is not
> displayed, then it's contents will not be rendered.  In Windows,
> individual windows only receive a WM_PAINT message with the visible
> region.  Not all apps clip accordingly of course.
> 
> For X, only windows that are visible receive expose events and again, 
> they're given a clipping region with what is actually displayed.
> 
> By the time we get to video memory, the display server has already 
> straightened out what portions of the screen are visible and what 
> aren't.  It will not render a hidden window and then render another 
> window on top of it.

I dont understand, if you have applciation that draw Rectangle, and
just another Rectanlge on top of it, wont it hide it?, doesnt we want
just to send the newest Rectangle?

> 
> >> How well does this work with a Linux guest?  To get a lot of this
> >> level of information, you have to hook in at the X protocol level
> >> (which is what NX does).  Can you really do much at the X driver
> >> level?
> >>     
> >
> > Well we have X driver, why would there be any problems with X?
> >   
> 
> A lot of the things in Spice (from a quick glance at the spec) are
> too high level for just an X driver.  For instance, there are glyph
> based operations presumably for text rendering.  There are also brush 
> primitives.  While X has some support for these things, it's so old
> and broken that in modern applications, most toolkits just render to
> a local buffer, and then do a draw the image to the window.  That
> means the X server has no visibility into the fact that you're
> actually rendering text which means an X driver cannot take advantage
> of that information.


Well any driver can use what ever spice commands it want, the X driver
doesnt have to use all the spice commands, what is so bad about that?

Spice is not protocol for just windows or X or whatever, it id display
protocol that implment common display commands that can be used over
every display system.

> 
> > Spice driver to X (I mean from the X prespective on things) is just
> > another display driver.
> >   
> 
> What's the performance compared to the Windows driver?
> 
> >>> Think about qemu give infastracture to multiple librarys to use
> >>> it? For example one user can use qemu with  VNC, one with SPICE,
> >>> and one can use qemu with diffrent private local rendering
> >>> soultion (for highly fast local 3d rendering...)
> >>>   
> >>>       
> >> As I said, I don't have a problem with externalizing things.  I
> >> think there's some discussion about how best to do that.  For
> >> instance, I think we want to avoid shared library plugins as it
> >> introduces a good deal of instability into our address space.
> >>     
> >
> > Well why libc is diffrent then?
> >   
> 
> libc is not a plugin.  It implements very well defined behaviors that 
> have well understood behaviors.  Also, glibc generally does not crash 
> :-)  I would not want a user to replace glibc with a different libc.
> 
> Regards,
> 
> Anthony Liguori

Re: [Qemu-devel] Spice project is now open

[Izik Eidus]

On Fri, 11 Dec 2009 22:53:25 +0300 (MSK)
malc <av1474@comtv.ru> wrote:

> On Fri, 11 Dec 2009, Izik Eidus wrote:
> 
> > On Fri, 11 Dec 2009 22:24:38 +0300 (MSK)
> > malc <av1474@comtv.ru> wrote:
> > 
> > > On Fri, 11 Dec 2009, Izik Eidus wrote:
> > > 
> > > > On Fri, 11 Dec 2009 22:03:33 +0300 (MSK)
> > > > malc <av1474@comtv.ru> wrote:
> > > > 
> > > > > On Fri, 11 Dec 2009, Izik Eidus wrote:
> > > > > 
> > > > > > On Fri, 11 Dec 2009 09:57:48 -0600
> > > > > > Anthony Liguori <anthony@codemonkey.ws> wrote:
> > > > > > 
> > > > > [..snip..]
> > > > > 
> > > > > > 
> > > 
> > > [..snip..]
> > > 
> > > > > 
> > > > > Any particular reason for implementing audio as a driver
> > > > > instead of a capture?
> > > > 
> > > > 
> > > > Spice doesnt have paravirtual audio driver, it use the AC97
> > > > device.
> > > 
> > > Yes it has - interface_audio_driver in audio/vd_interface_audio.c
> > > 
> > 
> > I think the file name here is missleading you...
> 
> I think you just don't understand what i'm asking. Let me try to
> expand: one way to implement audio interception is by having a special
> audio_driver (wavaudio.c vd_interface_audio.c) the other is by using
> a capture interface atop of existing driver (wavcapture.c vnc.c)
> 
> I was curious as to why the former was chosen.
> 

I see what you mean, I didnt write this part, so i will have to ask who
wrote it and will come back to you with an answer why he did it like
that.

Thanks.

Re: [Qemu-devel] Spice project is now open

[Izik Eidus]

On Fri, 11 Dec 2009 13:51:53 -0600
Anthony Liguori <anthony@codemonkey.ws> wrote:

> libc is not a plugin.  It implements very well defined behaviors that 
> have well understood behaviors.  Also, glibc generally does not crash 
> :-)  I would not want a user to replace glibc with a different libc.

I think it problomatic to say "I dont want to use this library" beacuse
"Librarys can crush", do you have any reason to say it on spice? did
you look on the code and saw huge ugly bugs?

> 
> Regards,
> 
> Anthony Liguori
> 
> 

Re: [Qemu-devel] Spice project is now open

[Anthony Liguori]

Izik Eidus wrote:
> I personaly dont like mjpeg, and yes in the end of the day you can add
> the video streaming into vnc, but what is the point here?
>   

What I'm trying to understand is, what can we do with Spice that we 
couldn't possibly do with vnc.  That means understanding each feature 
and then figuring out if there's a vnc analog.

If there are compellingly unique features to Spice that can't be 
duplicated in vnc, then it's a no brainer.  If you can do most things in 
vnc but it would be hackish whereas Spice makes it all elegant, then 
provided we can merge Spice without a huge amount of pain, then it's a 
net win.

However, if we need to make a few changes to vnc in order to get the 
same performance as Spice, then it's not quite as clear that it's what 
we should be using.

We're talking about a major change here.  There is a ton of management 
software that assumes vnc today.  Even though there are Spice clients 
out there, there are embedded vnc clients in certain tools today along 
with java applets.

That's not to say we shouldn't embrace Spice, we just have to make sure 
we have a good reason to.

> We acctuly want to kick away that video streaming, and move into the
> DirectX and X video extentions video support (that will be made using
> the qxl driver) - will give much better performence.
>   

Okay, I suspect we're in agreement here then.

>> By the time we get to video memory, the display server has already 
>> straightened out what portions of the screen are visible and what 
>> aren't.  It will not render a hidden window and then render another 
>> window on top of it.
>>     
>
> I dont understand, if you have applciation that draw Rectangle, and
> just another Rectanlge on top of it, wont it hide it?, doesnt we want
> just to send the newest Rectangle?
>   

If you're using something like gdk, the toolkit double buffers windows 
by default and does a single flip on expose.  So this sort of thing 
never makes it way to the X server.  But the other point is, if you draw 
a rectangle with gdk, all the X server ever sees is the drawing of an image.

> Well any driver can use what ever spice commands it want, the X driver
> doesnt have to use all the spice commands, what is so bad about that?
>   

What I'm asking is what's the performance of the X driver vs. say, VNC?  
Do these high level operations really make sense for a Linux guest if we 
cannot ever implement them in an X driver?

I can see where this is a win with Windows because you can hook into 
GDI, but I'm not sure that this could ever do better than say, NX 
without something really clever or really deep integration with toolkits.

> Spice is not protocol for just windows or X or whatever, it id display
> protocol that implment common display commands that can be used over
> every display system.
>   

Are there plans to integrate Spice support in gdk (or cairo)?  I think 
that would be required to get performance parity with Windows.

Regards,

Anthony Liguori

Re: [Qemu-devel] Spice project is now open

[Anthony Liguori]

Izik Eidus wrote:
> On Fri, 11 Dec 2009 13:51:53 -0600
> Anthony Liguori <anthony@codemonkey.ws> wrote:
>
>   
>> libc is not a plugin.  It implements very well defined behaviors that 
>> have well understood behaviors.  Also, glibc generally does not crash 
>> :-)  I would not want a user to replace glibc with a different libc.
>>     
>
> I think it problomatic to say "I dont want to use this library" beacuse
> "Librarys can crush", do you have any reason to say it on spice? did
> you look on the code and saw huge ugly bugs?
>   

Libraries are fine.  But libraries are not plugins.

It's the difference between qemu writing directly to libspice verses 
having a libspice-vdi that implements the VDI plugin interface and then 
a mechanism in qemu to load arbitrary libraries that implement the VDI 
interface.

If I understand correctly, VDI is a plugin interface.

Regards,

Anthony Liguori

Re: [Qemu-devel] Spice project is now open

[Izik Eidus]

On Fri, 11 Dec 2009 14:46:55 -0600
Anthony Liguori <anthony@codemonkey.ws> wrote:

> Izik Eidus wrote:
> > I personaly dont like mjpeg, and yes in the end of the day you can
> > add the video streaming into vnc, but what is the point here?
> >   
> 
> What I'm trying to understand is, what can we do with Spice that we 
> couldn't possibly do with vnc.  That means understanding each feature 
> and then figuring out if there's a vnc analog.
> 
> If there are compellingly unique features to Spice that can't be 
> duplicated in vnc, then it's a no brainer.  If you can do most things
> in vnc but it would be hackish whereas Spice makes it all elegant,
> then provided we can merge Spice without a huge amount of pain, then
> it's a net win.
> 
> However, if we need to make a few changes to vnc in order to get the 
> same performance as Spice, then it's not quite as clear that it's
> what we should be using.
> 
> We're talking about a major change here.  There is a ton of
> management software that assumes vnc today.  Even though there are
> Spice clients out there, there are embedded vnc clients in certain
> tools today along with java applets.
> 
> That's not to say we shouldn't embrace Spice, we just have to make
> sure we have a good reason to.

Ok, I understand your concerns.

But even though that spice and vnc achive in the end of the day the
same thing - they both allow remote rendering, they have fendumental
diffrent architacture.

Spice server work with a ring to the guest, it was build from day one
to work like that, In addition it was built from day one so that the
server will render only what it must to render (to allow much higher
virtualization denticity).

Just to make clear how much spice is diffrence from VNC is by the fact
that only the library itself (not including the drivers) have 128,277
lines of code inside it. (In my old qemu repo i see almost 600,000
lines for qemu) so this should give better prespective on how much
spice is diffrent from vnc.

So ofcurse in theory you can take all this 128,000 lines and push them
into qemu-vnc.c ?, but you got to remember that spice is not just
specific qemu thing, Spice should be used to work on physical machines
too, just cutting all this lines of code from spice and throw it into
qemu-vnc.c will be meaning a fork of spice inside qemu....

It isnt just the rings and the rendering style that make spice
diffrence, it is the channels it have for each compoment, it is the
multiple drawing surfaces, and so on...

This why the VDI interfaces were made, it was made so who ever used
VNC, can still use it, whoever want to use SPICE can still use spice,

By merging SPICE you just merge VDI interfaces, not the library
itself, it is so self contained thanks to the VDI interfaces, that it
almost dont touch anything inside qemu, I belive this was one of the
best aurgoments when Avi pushed kvm into the kernel - the fact that it
was a module that can be easyly removed if ppl dont want to use it. 


> 
> > We acctuly want to kick away that video streaming, and move into the
> > DirectX and X video extentions video support (that will be made
> > using the qxl driver) - will give much better performence.
> >   
> 
> Okay, I suspect we're in agreement here then.

Thanks God ! ;-)


> 
> >> By the time we get to video memory, the display server has already 
> >> straightened out what portions of the screen are visible and what 
> >> aren't.  It will not render a hidden window and then render
> >> another window on top of it.
> >>     
> >
> > I dont understand, if you have applciation that draw Rectangle, and
> > just another Rectanlge on top of it, wont it hide it?, doesnt we
> > want just to send the newest Rectangle?
> >   
> 
> If you're using something like gdk, the toolkit double buffers
> windows by default and does a single flip on expose.  So this sort of
> thing never makes it way to the X server.  But the other point is, if
> you draw a rectangle with gdk, all the X server ever sees is the
> drawing of an image.

Spice work on the driver primitives it doesnt know what is GDK, if the
X driver will draw rectangle and then another rectangle, VNC will have
to draw it twice, spice not.


> 
> > Well any driver can use what ever spice commands it want, the X
> > driver doesnt have to use all the spice commands, what is so bad
> > about that? 
> 
> What I'm asking is what's the performance of the X driver vs. say,
> VNC? Do these high level operations really make sense for a Linux
> guest if we cannot ever implement them in an X driver?

Ohh, The performence is much better user interactive and higher density
the user interactive come from the paravirtual device and the fact that
we dont send commands that were "hide" into the client.

The higher density come from the fact that the server that run the VM
(qemu) almost never have to render the stuff....


> 
> I can see where this is a win with Windows because you can hook into 
> GDI, but I'm not sure that this could ever do better than say, NX 
> without something really clever or really deep integration with
> toolkits.
> 
> > Spice is not protocol for just windows or X or whatever, it id
> > display protocol that implment common display commands that can be
> > used over every display system.
> >   
> 
> Are there plans to integrate Spice support in gdk (or cairo)?  I
> think that would be required to get performance parity with Windows.

Can you expline more what you mean?
Spice work on the driver primitives, so I am not sure I understand here
what you suggest...

Thanks.

> 
> Regards,
> 
> Anthony Liguori

Re: [Qemu-devel] Spice project is now open

[Izik Eidus]

On Fri, 11 Dec 2009 14:48:53 -0600
Anthony Liguori <anthony@codemonkey.ws> wrote:

> Izik Eidus wrote:
> > On Fri, 11 Dec 2009 13:51:53 -0600
> > Anthony Liguori <anthony@codemonkey.ws> wrote:
> >
> >   
> >> libc is not a plugin.  It implements very well defined behaviors
> >> that have well understood behaviors.  Also, glibc generally does
> >> not crash :-)  I would not want a user to replace glibc with a
> >> different libc. 
> >
> > I think it problomatic to say "I dont want to use this library"
> > beacuse "Librarys can crush", do you have any reason to say it on
> > spice? did you look on the code and saw huge ugly bugs?
> >   
> 
> Libraries are fine.  But libraries are not plugins.
> 
> It's the difference between qemu writing directly to libspice verses 
> having a libspice-vdi that implements the VDI plugin interface and
> then a mechanism in qemu to load arbitrary libraries that implement
> the VDI interface.
> 
> If I understand correctly, VDI is a plugin interface.

Ok, I guess you think VDI-interfaces are doing much more than they do
in reiality.

It is just simple interface to Allow Spice / VNC / whatever not have to
de-duplicate code in order to get information from - lets say the
keyboard....

Is it really diffrence from any other function callbacks that used for
such purpuse?


> 
> Regards,
> 
> Anthony Liguori
> 
> 

Re: [Qemu-devel] Spice project is now open

[Anthony Liguori]

Izik Eidus wrote:
>>>> By the time we get to video memory, the display server has already 
>>>> straightened out what portions of the screen are visible and what 
>>>> aren't.  It will not render a hidden window and then render
>>>> another window on top of it.
>>>>     
>>>>         
>>> I dont understand, if you have applciation that draw Rectangle, and
>>> just another Rectanlge on top of it, wont it hide it?, doesnt we
>>> want just to send the newest Rectangle?
>>>   
>>>       
>> If you're using something like gdk, the toolkit double buffers
>> windows by default and does a single flip on expose.  So this sort of
>> thing never makes it way to the X server.  But the other point is, if
>> you draw a rectangle with gdk, all the X server ever sees is the
>> drawing of an image.
>>     
>
> Spice work on the driver primitives it doesnt know what is GDK, if the
> X driver will draw rectangle and then another rectangle, VNC will have
> to draw it twice, spice not.
>   

The point is, there isn't a "draw a rectangle" primitive in X.  There 
also isn't a "draw some text using this font" in X.[1]

These things exist at higher levels (like GTK and QT).

[1] there actually are but modern applications don't use them.

> Ohh, The performence is much better user interactive and higher density
> the user interactive come from the paravirtual device and the fact that
> we dont send commands that were "hide" into the client.
>
> The higher density come from the fact that the server that run the VM
> (qemu) almost never have to render the stuff....
>   

With the Linux guest driver?  If you can quantify that, it would be very 
useful.

>> Are there plans to integrate Spice support in gdk (or cairo)?  I
>> think that would be required to get performance parity with Windows.
>>     
>
> Can you expline more what you mean?
> Spice work on the driver primitives, so I am not sure I understand here
> what you suggest...
>   

I think the point I'm trying to get across, is that Windows has a 
centralized architecture of drawing primitives and interfaces that is 
relatively easy for drivers to hook into.

Linux doesn't have this.  Different things are handled in different 
places and some layers (like GDK) aren't really made for hooking into.

What I'm trying to understand is whether it will be possible to 
implement a lot of the Spice accelerations for Linux guests.

Regards,

Anthony Liguori

Re: [Qemu-devel] Spice project is now open

[Anthony Liguori]

Izik Eidus wrote:
> Ok, I guess you think VDI-interfaces are doing much more than they do
> in reiality.
>
> It is just simple interface to Allow Spice / VNC / whatever not have to
> de-duplicate code in order to get information from - lets say the
> keyboard....
>
> Is it really diffrence from any other function callbacks that used for
> such purpuse?
>   

Plugin interfaces have been discussed a few times in the past.  The 
concerns have been 1) they will be abused with the introduction of 
proprietary plugins 2) we would have tremendous difficulty maintaining a 
stable plugin abi 3) they would create stability issues in qemu because 
the plugin quality cannot be controlled.

For 3, it's a matter of getting a bug report of a crash in qemu with a 
random plugin module enabled.  How do we know whether the crash is 
really a qemu bug or whether it was an issue in the plugin?  This isn't 
so bad in dynamic languages like Python but it's a real pain in C.

Regards,

Anthony Liguori

>   
>> Regards,
>>
>> Anthony Liguori
>>
>>
>>     
>
>   

Re: [Qemu-devel] Spice project is now open

[Alexander Graf]

On 11.12.2009, at 22:13, Izik Eidus wrote:

> On Fri, 11 Dec 2009 14:46:55 -0600
> Anthony Liguori <anthony@codemonkey.ws> wrote:
> 
>> Izik Eidus wrote:
>>> I personaly dont like mjpeg, and yes in the end of the day you can
>>> add the video streaming into vnc, but what is the point here?
>>> 
>> 
>> What I'm trying to understand is, what can we do with Spice that we 
>> couldn't possibly do with vnc.  That means understanding each feature 
>> and then figuring out if there's a vnc analog.
>> 
>> If there are compellingly unique features to Spice that can't be 
>> duplicated in vnc, then it's a no brainer.  If you can do most things
>> in vnc but it would be hackish whereas Spice makes it all elegant,
>> then provided we can merge Spice without a huge amount of pain, then
>> it's a net win.
>> 
>> However, if we need to make a few changes to vnc in order to get the 
>> same performance as Spice, then it's not quite as clear that it's
>> what we should be using.
>> 
>> We're talking about a major change here.  There is a ton of
>> management software that assumes vnc today.  Even though there are
>> Spice clients out there, there are embedded vnc clients in certain
>> tools today along with java applets.
>> 
>> That's not to say we shouldn't embrace Spice, we just have to make
>> sure we have a good reason to.
> 
> Ok, I understand your concerns.
> 
> But even though that spice and vnc achive in the end of the day the
> same thing - they both allow remote rendering, they have fendumental
> diffrent architacture.
> 
> Spice server work with a ring to the guest, it was build from day one
> to work like that, In addition it was built from day one so that the
> server will render only what it must to render (to allow much higher
> virtualization denticity).

The ring is from qemu <-> guest, right? I mean, qemu <-> client would be a TCP transport anyways, so the ring argument is void.

> Just to make clear how much spice is diffrence from VNC is by the fact
> that only the library itself (not including the drivers) have 128,277
> lines of code inside it. (In my old qemu repo i see almost 600,000
> lines for qemu) so this should give better prespective on how much
> spice is diffrent from vnc.
> 
> So ofcurse in theory you can take all this 128,000 lines and push them
> into qemu-vnc.c ?, but you got to remember that spice is not just
> specific qemu thing, Spice should be used to work on physical machines
> too, just cutting all this lines of code from spice and throw it into
> qemu-vnc.c will be meaning a fork of spice inside qemu....

I definitely understand your point of having a single protocol. The good news is that your physical machine stuff isn't released yet (AFAIK), so luckily there's still time to change parts of the protocol :-).

> It isnt just the rings and the rendering style that make spice
> diffrence, it is the channels it have for each compoment, it is the
> multiple drawing surfaces, and so on...

These should be fairly easy to implement in VNC too. In fact, I remember a project implementing off-screen drawing in VNC using a larger region of the screen than what was visible and then copyrect them in.

> This why the VDI interfaces were made, it was made so who ever used
> VNC, can still use it, whoever want to use SPICE can still use spice,
> 
> By merging SPICE you just merge VDI interfaces, not the library
> itself, it is so self contained thanks to the VDI interfaces, that it
> almost dont touch anything inside qemu, I belive this was one of the
> best aurgoments when Avi pushed kvm into the kernel - the fact that it
> was a module that can be easyly removed if ppl dont want to use it. 
> 
> 
>> 
>>> We acctuly want to kick away that video streaming, and move into the
>>> DirectX and X video extentions video support (that will be made
>>> using the qxl driver) - will give much better performence.
>>> 
>> 
>> Okay, I suspect we're in agreement here then.
> 
> Thanks God ! ;-)
> 
> 
>> 
>>>> By the time we get to video memory, the display server has already 
>>>> straightened out what portions of the screen are visible and what 
>>>> aren't.  It will not render a hidden window and then render
>>>> another window on top of it.
>>>> 
>>> 
>>> I dont understand, if you have applciation that draw Rectangle, and
>>> just another Rectanlge on top of it, wont it hide it?, doesnt we
>>> want just to send the newest Rectangle?
>>> 
>> 
>> If you're using something like gdk, the toolkit double buffers
>> windows by default and does a single flip on expose.  So this sort of
>> thing never makes it way to the X server.  But the other point is, if
>> you draw a rectangle with gdk, all the X server ever sees is the
>> drawing of an image.
> 
> Spice work on the driver primitives it doesnt know what is GDK, if the
> X driver will draw rectangle and then another rectangle, VNC will have
> to draw it twice, spice not.

Well, in fact VNC would wait for the refresh timer of the VGA framebuffer dirty thing and only send a single update too.

But Anthony's point was that rectangle drawing isn't used anymore. Instead gtk/qt just draw it themselves and tell the X driver "here's an image".

Alex

Re: [Qemu-devel] Spice project is now open

[Dor Laor]

On 12/12/2009 12:08 AM, Alexander Graf wrote:
>
> On 11.12.2009, at 22:13, Izik Eidus wrote:
>
>> On Fri, 11 Dec 2009 14:46:55 -0600
>> Anthony Liguori<anthony@codemonkey.ws>  wrote:
>>
>>> Izik Eidus wrote:
>>>> I personaly dont like mjpeg, and yes in the end of the day you can
>>>> add the video streaming into vnc, but what is the point here?
>>>>
>>>
>>> What I'm trying to understand is, what can we do with Spice that we
>>> couldn't possibly do with vnc.  That means understanding each feature
>>> and then figuring out if there's a vnc analog.
>>>
>>> If there are compellingly unique features to Spice that can't be
>>> duplicated in vnc, then it's a no brainer.  If you can do most things
>>> in vnc but it would be hackish whereas Spice makes it all elegant,
>>> then provided we can merge Spice without a huge amount of pain, then
>>> it's a net win.
>>>
>>> However, if we need to make a few changes to vnc in order to get the
>>> same performance as Spice, then it's not quite as clear that it's
>>> what we should be using.
>>>
>>> We're talking about a major change here.  There is a ton of
>>> management software that assumes vnc today.  Even though there are
>>> Spice clients out there, there are embedded vnc clients in certain
>>> tools today along with java applets.
>>>
>>> That's not to say we shouldn't embrace Spice, we just have to make
>>> sure we have a good reason to.
>>
>> Ok, I understand your concerns.
>>
>> But even though that spice and vnc achive in the end of the day the
>> same thing - they both allow remote rendering, they have fendumental
>> diffrent architacture.
>>
>> Spice server work with a ring to the guest, it was build from day one
>> to work like that, In addition it was built from day one so that the
>> server will render only what it must to render (to allow much higher
>> virtualization denticity).
>
> The ring is from qemu<->  guest, right? I mean, qemu<->  client would be a TCP transport anyways, so the ring argument is void.

Right, the ring is like any pv device. The descriptor is passed from the 
ring through the 'graphic VDI interface' to the spice server that is 
linked together with qemu.
Izik or the code can give better answer.

In fact, the code + lots of documentation exist. Indeed, this is just an 
early bird and it will change into qemu/kvm git repo for easier access. 
Once spice features are better understood, a merge plan should be 
decided and bits should start their journey into qemu.

>
>> Just to make clear how much spice is diffrence from VNC is by the fact
>> that only the library itself (not including the drivers) have 128,277
>> lines of code inside it. (In my old qemu repo i see almost 600,000
>> lines for qemu) so this should give better prespective on how much
>> spice is diffrent from vnc.
>>
>> So ofcurse in theory you can take all this 128,000 lines and push them
>> into qemu-vnc.c ?, but you got to remember that spice is not just
>> specific qemu thing, Spice should be used to work on physical machines
>> too, just cutting all this lines of code from spice and throw it into
>> qemu-vnc.c will be meaning a fork of spice inside qemu....
>
> I definitely understand your point of having a single protocol. The good news is that your physical machine stuff isn't released yet (AFAIK), so luckily there's still time to change parts of the protocol :-).
>
>> It isnt just the rings and the rendering style that make spice
>> diffrence, it is the channels it have for each compoment, it is the
>> multiple drawing surfaces, and so on...
>
> These should be fairly easy to implement in VNC too. In fact, I remember a project implementing off-screen drawing in VNC using a larger region of the screen than what was visible and then copyrect them in.
>
>> This why the VDI interfaces were made, it was made so who ever used
>> VNC, can still use it, whoever want to use SPICE can still use spice,
>>
>> By merging SPICE you just merge VDI interfaces, not the library
>> itself, it is so self contained thanks to the VDI interfaces, that it
>> almost dont touch anything inside qemu, I belive this was one of the
>> best aurgoments when Avi pushed kvm into the kernel - the fact that it
>> was a module that can be easyly removed if ppl dont want to use it.
>>
>>
>>>
>>>> We acctuly want to kick away that video streaming, and move into the
>>>> DirectX and X video extentions video support (that will be made
>>>> using the qxl driver) - will give much better performence.
>>>>
>>>
>>> Okay, I suspect we're in agreement here then.
>>
>> Thanks God ! ;-)
>>
>>
>>>
>>>>> By the time we get to video memory, the display server has already
>>>>> straightened out what portions of the screen are visible and what
>>>>> aren't.  It will not render a hidden window and then render
>>>>> another window on top of it.
>>>>>
>>>>
>>>> I dont understand, if you have applciation that draw Rectangle, and
>>>> just another Rectanlge on top of it, wont it hide it?, doesnt we
>>>> want just to send the newest Rectangle?
>>>>
>>>
>>> If you're using something like gdk, the toolkit double buffers
>>> windows by default and does a single flip on expose.  So this sort of
>>> thing never makes it way to the X server.  But the other point is, if
>>> you draw a rectangle with gdk, all the X server ever sees is the
>>> drawing of an image.
>>
>> Spice work on the driver primitives it doesnt know what is GDK, if the
>> X driver will draw rectangle and then another rectangle, VNC will have
>> to draw it twice, spice not.
>
> Well, in fact VNC would wait for the refresh timer of the VGA framebuffer dirty thing and only send a single update too.
>
> But Anthony's point was that rectangle drawing isn't used anymore. Instead gtk/qt just draw it themselves and tell the X driver "here's an image".
>
> Alex
>

Re: [Qemu-devel] Spice project is now open

[Izik Eidus]

On Fri, 11 Dec 2009 15:54:52 -0600
Anthony Liguori <anthony@codemonkey.ws> wrote:

> Izik Eidus wrote:
> >>>> By the time we get to video memory, the display server has
> >>>> already straightened out what portions of the screen are visible
> >>>> and what aren't.  It will not render a hidden window and then
> >>>> render another window on top of it.
> >>>>     
> >>>>         
> >>> I dont understand, if you have applciation that draw Rectangle,
> >>> and just another Rectanlge on top of it, wont it hide it?, doesnt
> >>> we want just to send the newest Rectangle?
> >>>   
> >>>       
> >> If you're using something like gdk, the toolkit double buffers
> >> windows by default and does a single flip on expose.  So this sort
> >> of thing never makes it way to the X server.  But the other point
> >> is, if you draw a rectangle with gdk, all the X server ever sees
> >> is the drawing of an image.
> >>     
> >
> > Spice work on the driver primitives it doesnt know what is GDK, if
> > the X driver will draw rectangle and then another rectangle, VNC
> > will have to draw it twice, spice not.
> >   
> 
> The point is, there isn't a "draw a rectangle" primitive in X.  There 
> also isn't a "draw some text using this font" in X.[1]
> 
> These things exist at higher levels (like GTK and QT).
> 
> [1] there actually are but modern applications don't use them.


While X can use just the Fill and Copy commands for spice, no one block
driver writer to add the GTK / QT levels you are talking about and send
this commands into spice (Xrender???), In addition to the Fill and Copy
commands spice can help improve performence with offscreen surfaces
support that allowing sending the pixmaps in the background while the
network is idle.

We are currently at the moment just implmented the X driver and we are
working to add better support for spice in this area (probably
it will be improvments regerding to xrender), so this parts have still
big potential to improve in spice.

In addition when we will merge the 3d support, driver would be able to
translate opengl commands into spice 3d commands.



> 
> > Ohh, The performence is much better user interactive and higher
> > density the user interactive come from the paravirtual device and
> > the fact that we dont send commands that were "hide" into the
> > client.
> >
> > The higher density come from the fact that the server that run the
> > VM (qemu) almost never have to render the stuff....
> >   
> 
> With the Linux guest driver?  If you can quantify that, it would be
> very useful.

The X driver is still very new, we have still a way to go to add all
what X need to achive the performence spice can offer.

> 
> >> Are there plans to integrate Spice support in gdk (or cairo)?  I
> >> think that would be required to get performance parity with
> >> Windows. 
> >
> > Can you expline more what you mean?
> > Spice work on the driver primitives, so I am not sure I understand
> > here what you suggest...
> >   
> 
> I think the point I'm trying to get across, is that Windows has a 
> centralized architecture of drawing primitives and interfaces that is 
> relatively easy for drivers to hook into.
> 
> Linux doesn't have this.  Different things are handled in different 
> places and some layers (like GDK) aren't really made for hooking into.
> 
> What I'm trying to understand is whether it will be possible to 
> implement a lot of the Spice accelerations for Linux guests.



Xrender, and Opengl would be possible to be implment in spice
I think Xrender is what Cairo use for hardware accelration and this
much of what you need no?

> 
> Regards,
> 
> Anthony Liguori

Re: [Qemu-devel] Spice project is now open

[Izik Eidus]

On Fri, 11 Dec 2009 23:08:01 +0100
Alexander Graf <agraf@suse.de> wrote:

> 
> On 11.12.2009, at 22:13, Izik Eidus wrote:
> 
> > On Fri, 11 Dec 2009 14:46:55 -0600
> > Anthony Liguori <anthony@codemonkey.ws> wrote:
> > 
> >> Izik Eidus wrote:
> >>> I personaly dont like mjpeg, and yes in the end of the day you can
> >>> add the video streaming into vnc, but what is the point here?
> >>> 
> >> 
> >> What I'm trying to understand is, what can we do with Spice that
> >> we couldn't possibly do with vnc.  That means understanding each
> >> feature and then figuring out if there's a vnc analog.
> >> 
> >> If there are compellingly unique features to Spice that can't be 
> >> duplicated in vnc, then it's a no brainer.  If you can do most
> >> things in vnc but it would be hackish whereas Spice makes it all
> >> elegant, then provided we can merge Spice without a huge amount of
> >> pain, then it's a net win.
> >> 
> >> However, if we need to make a few changes to vnc in order to get
> >> the same performance as Spice, then it's not quite as clear that
> >> it's what we should be using.
> >> 
> >> We're talking about a major change here.  There is a ton of
> >> management software that assumes vnc today.  Even though there are
> >> Spice clients out there, there are embedded vnc clients in certain
> >> tools today along with java applets.
> >> 
> >> That's not to say we shouldn't embrace Spice, we just have to make
> >> sure we have a good reason to.
> > 
> > Ok, I understand your concerns.
> > 
> > But even though that spice and vnc achive in the end of the day the
> > same thing - they both allow remote rendering, they have fendumental
> > diffrent architacture.
> > 
> > Spice server work with a ring to the guest, it was build from day
> > one to work like that, In addition it was built from day one so
> > that the server will render only what it must to render (to allow
> > much higher virtualization denticity).
> 
> The ring is from qemu <-> guest, right? I mean, qemu <-> client would
> be a TCP transport anyways, so the ring argument is void.


Beside the fact that we dont have the network overhead...

> 
> > Just to make clear how much spice is diffrence from VNC is by the
> > fact that only the library itself (not including the drivers) have
> > 128,277 lines of code inside it. (In my old qemu repo i see almost
> > 600,000 lines for qemu) so this should give better prespective on
> > how much spice is diffrent from vnc.
> > 
> > So ofcurse in theory you can take all this 128,000 lines and push
> > them into qemu-vnc.c ?, but you got to remember that spice is not
> > just specific qemu thing, Spice should be used to work on physical
> > machines too, just cutting all this lines of code from spice and
> > throw it into qemu-vnc.c will be meaning a fork of spice inside
> > qemu....
> 
> I definitely understand your point of having a single protocol. The
> good news is that your physical machine stuff isn't released yet
> (AFAIK), so luckily there's still time to change parts of the
> protocol :-).
> 
> > It isnt just the rings and the rendering style that make spice
> > diffrence, it is the channels it have for each compoment, it is the
> > multiple drawing surfaces, and so on...
> 
> These should be fairly easy to implement in VNC too. In fact, I
> remember a project implementing off-screen drawing in VNC using a
> larger region of the screen than what was visible and then copyrect
> them in.

In theory you can even change the whole of VNC into SPICE or the whole
of VI into EMACS, so???, I personaly think changing code isnt the
problem, the problem is always the desgien, and SPICE have fandumental
diffrent desgien than VNC, (Here you can say: OK I can make my VNC
desgien like SPICE, or you can say I think SPICE dsgien is bad, or you
can just use SPICE...)

> 
> > This why the VDI interfaces were made, it was made so who ever used
> > VNC, can still use it, whoever want to use SPICE can still use
> > spice,
> > 
> > By merging SPICE you just merge VDI interfaces, not the library
> > itself, it is so self contained thanks to the VDI interfaces, that
> > it almost dont touch anything inside qemu, I belive this was one of
> > the best aurgoments when Avi pushed kvm into the kernel - the fact
> > that it was a module that can be easyly removed if ppl dont want to
> > use it. 
> > 
> > 
> >> 
> >>> We acctuly want to kick away that video streaming, and move into
> >>> the DirectX and X video extentions video support (that will be
> >>> made using the qxl driver) - will give much better performence.
> >>> 
> >> 
> >> Okay, I suspect we're in agreement here then.
> > 
> > Thanks God ! ;-)
> > 
> > 
> >> 
> >>>> By the time we get to video memory, the display server has
> >>>> already straightened out what portions of the screen are visible
> >>>> and what aren't.  It will not render a hidden window and then
> >>>> render another window on top of it.
> >>>> 
> >>> 
> >>> I dont understand, if you have applciation that draw Rectangle,
> >>> and just another Rectanlge on top of it, wont it hide it?, doesnt
> >>> we want just to send the newest Rectangle?
> >>> 
> >> 
> >> If you're using something like gdk, the toolkit double buffers
> >> windows by default and does a single flip on expose.  So this sort
> >> of thing never makes it way to the X server.  But the other point
> >> is, if you draw a rectangle with gdk, all the X server ever sees
> >> is the drawing of an image.
> > 
> > Spice work on the driver primitives it doesnt know what is GDK, if
> > the X driver will draw rectangle and then another rectangle, VNC
> > will have to draw it twice, spice not.
> 
> Well, in fact VNC would wait for the refresh timer of the VGA
> framebuffer dirty thing and only send a single update too.

Yes but what will happen if you run vnc using paravirtual device?

> 
> But Anthony's point was that rectangle drawing isn't used anymore.
> Instead gtk/qt just draw it themselves and tell the X driver "here's
> an image".


And what about 3D ? or Xrender operations such as composing ?
(streching)?



> 
> Alex

Re: [Qemu-devel] Spice project is now open

[Chris Wright]

* Anthony Liguori (anthony@codemonkey.ws) wrote:
> Izik Eidus wrote:
>> Ok, I guess you think VDI-interfaces are doing much more than they do
>> in reiality.
>>
>> It is just simple interface to Allow Spice / VNC / whatever not have to
>> de-duplicate code in order to get information from - lets say the
>> keyboard....
>>
>> Is it really diffrence from any other function callbacks that used for
>> such purpuse?
>>   
>
> Plugin interfaces have been discussed a few times in the past.  The  
> concerns have been 1) they will be abused with the introduction of  
> proprietary plugins 2) we would have tremendous difficulty maintaining a  
> stable plugin abi 3) they would create stability issues in qemu because  
> the plugin quality cannot be controlled.

I think you're talking about dlopen() vs. direct linkage of .so?

Here's some code to ground things a bit.

ifdef CONFIG_SPICE
CFLAGS+=$(SPICE_CFLAGS)
LIBS+=$(SPICE_LIBS)
endif

And specifically, there's a notion of the VDI interface added to
core qemu, which can be extended by simply registering callbacks to that
interface:

vl.c::main()
...
#ifdef CONFIG_SPICE
	...
	spice_init(&core_interface);.
#endif

thanks,
-chris

Re: [Qemu-devel] Spice project is now open

[Alexander Graf]

On 11.12.2009, at 23:46, Izik Eidus wrote:

> On Fri, 11 Dec 2009 23:08:01 +0100
> Alexander Graf <agraf@suse.de> wrote:
> 
>> 
>> On 11.12.2009, at 22:13, Izik Eidus wrote:
>> 
>>> On Fri, 11 Dec 2009 14:46:55 -0600
>>> Anthony Liguori <anthony@codemonkey.ws> wrote:
>>> 
>>>> Izik Eidus wrote:
>>>>> I personaly dont like mjpeg, and yes in the end of the day you can
>>>>> add the video streaming into vnc, but what is the point here?
>>>>> 
>>>> 
>>>> What I'm trying to understand is, what can we do with Spice that
>>>> we couldn't possibly do with vnc.  That means understanding each
>>>> feature and then figuring out if there's a vnc analog.
>>>> 
>>>> If there are compellingly unique features to Spice that can't be 
>>>> duplicated in vnc, then it's a no brainer.  If you can do most
>>>> things in vnc but it would be hackish whereas Spice makes it all
>>>> elegant, then provided we can merge Spice without a huge amount of
>>>> pain, then it's a net win.
>>>> 
>>>> However, if we need to make a few changes to vnc in order to get
>>>> the same performance as Spice, then it's not quite as clear that
>>>> it's what we should be using.
>>>> 
>>>> We're talking about a major change here.  There is a ton of
>>>> management software that assumes vnc today.  Even though there are
>>>> Spice clients out there, there are embedded vnc clients in certain
>>>> tools today along with java applets.
>>>> 
>>>> That's not to say we shouldn't embrace Spice, we just have to make
>>>> sure we have a good reason to.
>>> 
>>> Ok, I understand your concerns.
>>> 
>>> But even though that spice and vnc achive in the end of the day the
>>> same thing - they both allow remote rendering, they have fendumental
>>> diffrent architacture.
>>> 
>>> Spice server work with a ring to the guest, it was build from day
>>> one to work like that, In addition it was built from day one so
>>> that the server will render only what it must to render (to allow
>>> much higher virtualization denticity).
>> 
>> The ring is from qemu <-> guest, right? I mean, qemu <-> client would
>> be a TCP transport anyways, so the ring argument is void.
> 
> 
> Beside the fact that we dont have the network overhead...

Eh - when you connect to the VM remotely you still get the network overhead, because you're connecting to it via the network :-).

> 
>> 
>>> Just to make clear how much spice is diffrence from VNC is by the
>>> fact that only the library itself (not including the drivers) have
>>> 128,277 lines of code inside it. (In my old qemu repo i see almost
>>> 600,000 lines for qemu) so this should give better prespective on
>>> how much spice is diffrent from vnc.
>>> 
>>> So ofcurse in theory you can take all this 128,000 lines and push
>>> them into qemu-vnc.c ?, but you got to remember that spice is not
>>> just specific qemu thing, Spice should be used to work on physical
>>> machines too, just cutting all this lines of code from spice and
>>> throw it into qemu-vnc.c will be meaning a fork of spice inside
>>> qemu....
>> 
>> I definitely understand your point of having a single protocol. The
>> good news is that your physical machine stuff isn't released yet
>> (AFAIK), so luckily there's still time to change parts of the
>> protocol :-).
>> 
>>> It isnt just the rings and the rendering style that make spice
>>> diffrence, it is the channels it have for each compoment, it is the
>>> multiple drawing surfaces, and so on...
>> 
>> These should be fairly easy to implement in VNC too. In fact, I
>> remember a project implementing off-screen drawing in VNC using a
>> larger region of the screen than what was visible and then copyrect
>> them in.
> 
> In theory you can even change the whole of VNC into SPICE or the whole
> of VI into EMACS, so???, I personaly think changing code isnt the
> problem, the problem is always the desgien, and SPICE have fandumental
> diffrent desgien than VNC, (Here you can say: OK I can make my VNC
> desgien like SPICE, or you can say I think SPICE dsgien is bad, or you
> can just use SPICE...)

Oh I'm not trying to talk you or anyone into anything. I was merely trying to stress that SPICE isn't really its own protocol but extensions to the RDP protocol (IIUC). You could do similar extensions to VNC if you liked. Thus I'd love to see a generic mid-layer and implementations of RDP and VNC on top of that actually.

> 
>> 
>>> This why the VDI interfaces were made, it was made so who ever used
>>> VNC, can still use it, whoever want to use SPICE can still use
>>> spice,
>>> 
>>> By merging SPICE you just merge VDI interfaces, not the library
>>> itself, it is so self contained thanks to the VDI interfaces, that
>>> it almost dont touch anything inside qemu, I belive this was one of
>>> the best aurgoments when Avi pushed kvm into the kernel - the fact
>>> that it was a module that can be easyly removed if ppl dont want to
>>> use it. 
>>> 
>>> 
>>>> 
>>>>> We acctuly want to kick away that video streaming, and move into
>>>>> the DirectX and X video extentions video support (that will be
>>>>> made using the qxl driver) - will give much better performence.
>>>>> 
>>>> 
>>>> Okay, I suspect we're in agreement here then.
>>> 
>>> Thanks God ! ;-)
>>> 
>>> 
>>>> 
>>>>>> By the time we get to video memory, the display server has
>>>>>> already straightened out what portions of the screen are visible
>>>>>> and what aren't.  It will not render a hidden window and then
>>>>>> render another window on top of it.
>>>>>> 
>>>>> 
>>>>> I dont understand, if you have applciation that draw Rectangle,
>>>>> and just another Rectanlge on top of it, wont it hide it?, doesnt
>>>>> we want just to send the newest Rectangle?
>>>>> 
>>>> 
>>>> If you're using something like gdk, the toolkit double buffers
>>>> windows by default and does a single flip on expose.  So this sort
>>>> of thing never makes it way to the X server.  But the other point
>>>> is, if you draw a rectangle with gdk, all the X server ever sees
>>>> is the drawing of an image.
>>> 
>>> Spice work on the driver primitives it doesnt know what is GDK, if
>>> the X driver will draw rectangle and then another rectangle, VNC
>>> will have to draw it twice, spice not.
>> 
>> Well, in fact VNC would wait for the refresh timer of the VGA
>> framebuffer dirty thing and only send a single update too.
> 
> Yes but what will happen if you run vnc using paravirtual device?

That depends on what you get from the PV device. I'm not sure what the vmware svga does, but from what I've seen they try to keep a lot of the cleverness in the guest driver.

> 
>> 
>> But Anthony's point was that rectangle drawing isn't used anymore.
>> Instead gtk/qt just draw it themselves and tell the X driver "here's
>> an image".
> 
> 
> And what about 3D ? or Xrender operations such as composing ?
> (streching)?

Yes, you get those :-). It makes a _lot_ of sense to be your own X driver! The point was if we could achieve even more :-). But let's try to focus on what's there first.

Alex

Re: [Qemu-devel] Spice project is now open

[Izik Eidus]

On Sat, 12 Dec 2009 00:54:47 +0100
Alexander Graf <agraf@suse.de> wrote:

> 
> On 11.12.2009, at 23:46, Izik Eidus wrote:
> 
> > On Fri, 11 Dec 2009 23:08:01 +0100
> > Alexander Graf <agraf@suse.de> wrote:
> > 
> >> 
> >> On 11.12.2009, at 22:13, Izik Eidus wrote:
> >> 
> >>> On Fri, 11 Dec 2009 14:46:55 -0600
> >>> Anthony Liguori <anthony@codemonkey.ws> wrote:
> >>> 
> >>>> Izik Eidus wrote:
> >>>>> I personaly dont like mjpeg, and yes in the end of the day you
> >>>>> can add the video streaming into vnc, but what is the point
> >>>>> here?
> >>>>> 
> >>>> 
> >>>> What I'm trying to understand is, what can we do with Spice that
> >>>> we couldn't possibly do with vnc.  That means understanding each
> >>>> feature and then figuring out if there's a vnc analog.
> >>>> 
> >>>> If there are compellingly unique features to Spice that can't be 
> >>>> duplicated in vnc, then it's a no brainer.  If you can do most
> >>>> things in vnc but it would be hackish whereas Spice makes it all
> >>>> elegant, then provided we can merge Spice without a huge amount
> >>>> of pain, then it's a net win.
> >>>> 
> >>>> However, if we need to make a few changes to vnc in order to get
> >>>> the same performance as Spice, then it's not quite as clear that
> >>>> it's what we should be using.
> >>>> 
> >>>> We're talking about a major change here.  There is a ton of
> >>>> management software that assumes vnc today.  Even though there
> >>>> are Spice clients out there, there are embedded vnc clients in
> >>>> certain tools today along with java applets.
> >>>> 
> >>>> That's not to say we shouldn't embrace Spice, we just have to
> >>>> make sure we have a good reason to.
> >>> 
> >>> Ok, I understand your concerns.
> >>> 
> >>> But even though that spice and vnc achive in the end of the day
> >>> the same thing - they both allow remote rendering, they have
> >>> fendumental diffrent architacture.
> >>> 
> >>> Spice server work with a ring to the guest, it was build from day
> >>> one to work like that, In addition it was built from day one so
> >>> that the server will render only what it must to render (to allow
> >>> much higher virtualization denticity).
> >> 
> >> The ring is from qemu <-> guest, right? I mean, qemu <-> client
> >> would be a TCP transport anyways, so the ring argument is void.
> > 
> > 
> > Beside the fact that we dont have the network overhead...
> 
> Eh - when you connect to the VM remotely you still get the network
> overhead, because you're connecting to it via the network :-).

Yes but you send the data from the HOST networking, not from the
virtualized guest networking (That will later send it from the Host
networking)...


> 
> > 
> >> 
> >>> Just to make clear how much spice is diffrence from VNC is by the
> >>> fact that only the library itself (not including the drivers) have
> >>> 128,277 lines of code inside it. (In my old qemu repo i see almost
> >>> 600,000 lines for qemu) so this should give better prespective on
> >>> how much spice is diffrent from vnc.
> >>> 
> >>> So ofcurse in theory you can take all this 128,000 lines and push
> >>> them into qemu-vnc.c ?, but you got to remember that spice is not
> >>> just specific qemu thing, Spice should be used to work on physical
> >>> machines too, just cutting all this lines of code from spice and
> >>> throw it into qemu-vnc.c will be meaning a fork of spice inside
> >>> qemu....
> >> 
> >> I definitely understand your point of having a single protocol. The
> >> good news is that your physical machine stuff isn't released yet
> >> (AFAIK), so luckily there's still time to change parts of the
> >> protocol :-).
> >> 
> >>> It isnt just the rings and the rendering style that make spice
> >>> diffrence, it is the channels it have for each compoment, it is
> >>> the multiple drawing surfaces, and so on...
> >> 
> >> These should be fairly easy to implement in VNC too. In fact, I
> >> remember a project implementing off-screen drawing in VNC using a
> >> larger region of the screen than what was visible and then copyrect
> >> them in.
> > 
> > In theory you can even change the whole of VNC into SPICE or the
> > whole of VI into EMACS, so???, I personaly think changing code isnt
> > the problem, the problem is always the desgien, and SPICE have
> > fandumental diffrent desgien than VNC, (Here you can say: OK I can
> > make my VNC desgien like SPICE, or you can say I think SPICE dsgien
> > is bad, or you can just use SPICE...)
> 
> Oh I'm not trying to talk you or anyone into anything. I was merely
> trying to stress that SPICE isn't really its own protocol but
> extensions to the RDP protocol (IIUC). You could do similar
> extensions to VNC if you liked. Thus I'd love to see a generic
> mid-layer and implementations of RDP and VNC on top of that actually.

One of the decisions we have made in SPICE, was to provide a full
functional remote system, not realying on other system,
We already have far more features than VNC have, so what is the logical
in making spice extention of VNC? it more logical to make VNC extention
of SPICE...

SPICE have networking tunneling, local/server mouse, (in progress) usb
remote, audio / recording channel , private channels for each
compoment, Even if VNC would have part of this stuff, It seems like
they are trying to achive things in diffrent way than SPICE does.


> 
> > 
> >> 
> >>> This why the VDI interfaces were made, it was made so who ever
> >>> used VNC, can still use it, whoever want to use SPICE can still
> >>> use spice,
> >>> 
> >>> By merging SPICE you just merge VDI interfaces, not the library
> >>> itself, it is so self contained thanks to the VDI interfaces, that
> >>> it almost dont touch anything inside qemu, I belive this was one
> >>> of the best aurgoments when Avi pushed kvm into the kernel - the
> >>> fact that it was a module that can be easyly removed if ppl dont
> >>> want to use it. 
> >>> 
> >>> 
> >>>> 
> >>>>> We acctuly want to kick away that video streaming, and move into
> >>>>> the DirectX and X video extentions video support (that will be
> >>>>> made using the qxl driver) - will give much better performence.
> >>>>> 
> >>>> 
> >>>> Okay, I suspect we're in agreement here then.
> >>> 
> >>> Thanks God ! ;-)
> >>> 
> >>> 
> >>>> 
> >>>>>> By the time we get to video memory, the display server has
> >>>>>> already straightened out what portions of the screen are
> >>>>>> visible and what aren't.  It will not render a hidden window
> >>>>>> and then render another window on top of it.
> >>>>>> 
> >>>>> 
> >>>>> I dont understand, if you have applciation that draw Rectangle,
> >>>>> and just another Rectanlge on top of it, wont it hide it?,
> >>>>> doesnt we want just to send the newest Rectangle?
> >>>>> 
> >>>> 
> >>>> If you're using something like gdk, the toolkit double buffers
> >>>> windows by default and does a single flip on expose.  So this
> >>>> sort of thing never makes it way to the X server.  But the other
> >>>> point is, if you draw a rectangle with gdk, all the X server
> >>>> ever sees is the drawing of an image.
> >>> 
> >>> Spice work on the driver primitives it doesnt know what is GDK, if
> >>> the X driver will draw rectangle and then another rectangle, VNC
> >>> will have to draw it twice, spice not.
> >> 
> >> Well, in fact VNC would wait for the refresh timer of the VGA
> >> framebuffer dirty thing and only send a single update too.
> > 
> > Yes but what will happen if you run vnc using paravirtual device?
> 
> That depends on what you get from the PV device. I'm not sure what
> the vmware svga does, but from what I've seen they try to keep a lot
> of the cleverness in the guest driver.


Yes, but for our PV driver spice is the optimal system :)

Thanks.


> 
> > 
> >> 
> >> But Anthony's point was that rectangle drawing isn't used anymore.
> >> Instead gtk/qt just draw it themselves and tell the X driver
> >> "here's an image".
> > 
> > 
> > And what about 3D ? or Xrender operations such as composing ?
> > (streching)?
> 
> Yes, you get those :-). It makes a _lot_ of sense to be your own X
> driver! The point was if we could achieve even more :-). But let's
> try to focus on what's there first.
> 
> Alex
> 

Re: [Qemu-devel] Spice project is now open

[Alexander Graf]

On 12.12.2009, at 01:14, Izik Eidus wrote:

> On Sat, 12 Dec 2009 00:54:47 +0100
> Alexander Graf <agraf@suse.de> wrote:
> 
>> 
>> On 11.12.2009, at 23:46, Izik Eidus wrote:
>> 
>>> On Fri, 11 Dec 2009 23:08:01 +0100
>>> Alexander Graf <agraf@suse.de> wrote:
>>> 
>>>> 
>>>> On 11.12.2009, at 22:13, Izik Eidus wrote:
>>>> 
>>>>> On Fri, 11 Dec 2009 14:46:55 -0600
>>>>> Anthony Liguori <anthony@codemonkey.ws> wrote:
>>>>> 
>>>>>> Izik Eidus wrote:
>>>>>>> I personaly dont like mjpeg, and yes in the end of the day you
>>>>>>> can add the video streaming into vnc, but what is the point
>>>>>>> here?
>>>>>>> 
>>>>>> 
>>>>>> What I'm trying to understand is, what can we do with Spice that
>>>>>> we couldn't possibly do with vnc.  That means understanding each
>>>>>> feature and then figuring out if there's a vnc analog.
>>>>>> 
>>>>>> If there are compellingly unique features to Spice that can't be 
>>>>>> duplicated in vnc, then it's a no brainer.  If you can do most
>>>>>> things in vnc but it would be hackish whereas Spice makes it all
>>>>>> elegant, then provided we can merge Spice without a huge amount
>>>>>> of pain, then it's a net win.
>>>>>> 
>>>>>> However, if we need to make a few changes to vnc in order to get
>>>>>> the same performance as Spice, then it's not quite as clear that
>>>>>> it's what we should be using.
>>>>>> 
>>>>>> We're talking about a major change here.  There is a ton of
>>>>>> management software that assumes vnc today.  Even though there
>>>>>> are Spice clients out there, there are embedded vnc clients in
>>>>>> certain tools today along with java applets.
>>>>>> 
>>>>>> That's not to say we shouldn't embrace Spice, we just have to
>>>>>> make sure we have a good reason to.
>>>>> 
>>>>> Ok, I understand your concerns.
>>>>> 
>>>>> But even though that spice and vnc achive in the end of the day
>>>>> the same thing - they both allow remote rendering, they have
>>>>> fendumental diffrent architacture.
>>>>> 
>>>>> Spice server work with a ring to the guest, it was build from day
>>>>> one to work like that, In addition it was built from day one so
>>>>> that the server will render only what it must to render (to allow
>>>>> much higher virtualization denticity).
>>>> 
>>>> The ring is from qemu <-> guest, right? I mean, qemu <-> client
>>>> would be a TCP transport anyways, so the ring argument is void.
>>> 
>>> 
>>> Beside the fact that we dont have the network overhead...
>> 
>> Eh - when you connect to the VM remotely you still get the network
>> overhead, because you're connecting to it via the network :-).
> 
> Yes but you send the data from the HOST networking, not from the
> virtualized guest networking (That will later send it from the Host
> networking)...

Exactly. So you'd get the same as with virtio-fb and VNC :-).

> 
> 
>> 
>>> 
>>>> 
>>>>> Just to make clear how much spice is diffrence from VNC is by the
>>>>> fact that only the library itself (not including the drivers) have
>>>>> 128,277 lines of code inside it. (In my old qemu repo i see almost
>>>>> 600,000 lines for qemu) so this should give better prespective on
>>>>> how much spice is diffrent from vnc.
>>>>> 
>>>>> So ofcurse in theory you can take all this 128,000 lines and push
>>>>> them into qemu-vnc.c ?, but you got to remember that spice is not
>>>>> just specific qemu thing, Spice should be used to work on physical
>>>>> machines too, just cutting all this lines of code from spice and
>>>>> throw it into qemu-vnc.c will be meaning a fork of spice inside
>>>>> qemu....
>>>> 
>>>> I definitely understand your point of having a single protocol. The
>>>> good news is that your physical machine stuff isn't released yet
>>>> (AFAIK), so luckily there's still time to change parts of the
>>>> protocol :-).
>>>> 
>>>>> It isnt just the rings and the rendering style that make spice
>>>>> diffrence, it is the channels it have for each compoment, it is
>>>>> the multiple drawing surfaces, and so on...
>>>> 
>>>> These should be fairly easy to implement in VNC too. In fact, I
>>>> remember a project implementing off-screen drawing in VNC using a
>>>> larger region of the screen than what was visible and then copyrect
>>>> them in.
>>> 
>>> In theory you can even change the whole of VNC into SPICE or the
>>> whole of VI into EMACS, so???, I personaly think changing code isnt
>>> the problem, the problem is always the desgien, and SPICE have
>>> fandumental diffrent desgien than VNC, (Here you can say: OK I can
>>> make my VNC desgien like SPICE, or you can say I think SPICE dsgien
>>> is bad, or you can just use SPICE...)
>> 
>> Oh I'm not trying to talk you or anyone into anything. I was merely
>> trying to stress that SPICE isn't really its own protocol but
>> extensions to the RDP protocol (IIUC). You could do similar
>> extensions to VNC if you liked. Thus I'd love to see a generic
>> mid-layer and implementations of RDP and VNC on top of that actually.
> 
> One of the decisions we have made in SPICE, was to provide a full
> functional remote system, not realying on other system,
> We already have far more features than VNC have, so what is the logical
> in making spice extention of VNC? it more logical to make VNC extention
> of SPICE...
> 
> SPICE have networking tunneling, local/server mouse, (in progress) usb
> remote, audio / recording channel , private channels for each
> compoment, Even if VNC would have part of this stuff, It seems like
> they are trying to achive things in diffrent way than SPICE does.

It kind of reminds me of the vbus story ;-).

You have some really interesting pieces of software there. Especially the QXL virtual adapter and guest drivers are really interesting.

I'm simply not convinced that SPICE is the "ideal" way of doing things. Why don't we just look at this a bit more differentiated, rather than an "everything or nothing" solution?

Imagine you had a QXL adapter emulation in qemu. You would take all the cool accelerations you have and pass them directly to the VNC module. Now you add bitmap caching support to VNC. I bet you'll reach about as fast graphics performance as you do with SPICE today.

As for the other parts, they should really be modular too. I don't want to restrict a user to SPICE if he wants to do remote USB. That should be handled in a more generic fashion, with SPICE being one recipient of the virtual USB stream. I might just as well want to have a USB device passed to my guest from my server where I have this cool smart card reader attached, but have the guest display using SDL.

So I'm not complaining about any way SPICE does things. I'm trying to split up the various bits and pieces and try to evaluate them separately :-). That's the UNIX way - have separate tools that do only small parts of the whole picture, but do those really well.

Alex

Re: [Qemu-devel] Spice project is now open

[Izik Eidus]

On Sat, 12 Dec 2009 01:27:09 +0100
Alexander Graf <agraf@suse.de> wrote:

> 
> On 12.12.2009, at 01:14, Izik Eidus wrote:
> 
> > On Sat, 12 Dec 2009 00:54:47 +0100
> > Alexander Graf <agraf@suse.de> wrote:
> > 
> >> 
> >> On 11.12.2009, at 23:46, Izik Eidus wrote:
> >> 
> >>> On Fri, 11 Dec 2009 23:08:01 +0100
> >>> Alexander Graf <agraf@suse.de> wrote:
> >>> 
> >>>> 
> >>>> On 11.12.2009, at 22:13, Izik Eidus wrote:
> >>>> 
> >>>>> On Fri, 11 Dec 2009 14:46:55 -0600
> >>>>> Anthony Liguori <anthony@codemonkey.ws> wrote:
> >>>>> 
> >>>>>> Izik Eidus wrote:
> >>>>>>> I personaly dont like mjpeg, and yes in the end of the day you
> >>>>>>> can add the video streaming into vnc, but what is the point
> >>>>>>> here?
> >>>>>>> 
> >>>>>> 
> >>>>>> What I'm trying to understand is, what can we do with Spice
> >>>>>> that we couldn't possibly do with vnc.  That means
> >>>>>> understanding each feature and then figuring out if there's a
> >>>>>> vnc analog.
> >>>>>> 
> >>>>>> If there are compellingly unique features to Spice that can't
> >>>>>> be duplicated in vnc, then it's a no brainer.  If you can do
> >>>>>> most things in vnc but it would be hackish whereas Spice makes
> >>>>>> it all elegant, then provided we can merge Spice without a
> >>>>>> huge amount of pain, then it's a net win.
> >>>>>> 
> >>>>>> However, if we need to make a few changes to vnc in order to
> >>>>>> get the same performance as Spice, then it's not quite as
> >>>>>> clear that it's what we should be using.
> >>>>>> 
> >>>>>> We're talking about a major change here.  There is a ton of
> >>>>>> management software that assumes vnc today.  Even though there
> >>>>>> are Spice clients out there, there are embedded vnc clients in
> >>>>>> certain tools today along with java applets.
> >>>>>> 
> >>>>>> That's not to say we shouldn't embrace Spice, we just have to
> >>>>>> make sure we have a good reason to.
> >>>>> 
> >>>>> Ok, I understand your concerns.
> >>>>> 
> >>>>> But even though that spice and vnc achive in the end of the day
> >>>>> the same thing - they both allow remote rendering, they have
> >>>>> fendumental diffrent architacture.
> >>>>> 
> >>>>> Spice server work with a ring to the guest, it was build from
> >>>>> day one to work like that, In addition it was built from day
> >>>>> one so that the server will render only what it must to render
> >>>>> (to allow much higher virtualization denticity).
> >>>> 
> >>>> The ring is from qemu <-> guest, right? I mean, qemu <-> client
> >>>> would be a TCP transport anyways, so the ring argument is void.
> >>> 
> >>> 
> >>> Beside the fact that we dont have the network overhead...
> >> 
> >> Eh - when you connect to the VM remotely you still get the network
> >> overhead, because you're connecting to it via the network :-).
> > 
> > Yes but you send the data from the HOST networking, not from the
> > virtualized guest networking (That will later send it from the Host
> > networking)...
> 
> Exactly. So you'd get the same as with virtio-fb and VNC :-).

Yes, virtio-fb and spice have the same overhead for the ring part,
but this not what i understood when you said:
"The ring is from qemu <-> guest, right? I mean, qemu <-> client
 would be a TCP transport anyways, so the ring argument is void."

But leave it :).

> 
> > 
> > 
> >> 
> >>> 
> >>>> 
> >>>>> Just to make clear how much spice is diffrence from VNC is by
> >>>>> the fact that only the library itself (not including the
> >>>>> drivers) have 128,277 lines of code inside it. (In my old qemu
> >>>>> repo i see almost 600,000 lines for qemu) so this should give
> >>>>> better prespective on how much spice is diffrent from vnc.
> >>>>> 
> >>>>> So ofcurse in theory you can take all this 128,000 lines and
> >>>>> push them into qemu-vnc.c ?, but you got to remember that spice
> >>>>> is not just specific qemu thing, Spice should be used to work
> >>>>> on physical machines too, just cutting all this lines of code
> >>>>> from spice and throw it into qemu-vnc.c will be meaning a fork
> >>>>> of spice inside qemu....
> >>>> 
> >>>> I definitely understand your point of having a single protocol.
> >>>> The good news is that your physical machine stuff isn't released
> >>>> yet (AFAIK), so luckily there's still time to change parts of the
> >>>> protocol :-).
> >>>> 
> >>>>> It isnt just the rings and the rendering style that make spice
> >>>>> diffrence, it is the channels it have for each compoment, it is
> >>>>> the multiple drawing surfaces, and so on...
> >>>> 
> >>>> These should be fairly easy to implement in VNC too. In fact, I
> >>>> remember a project implementing off-screen drawing in VNC using a
> >>>> larger region of the screen than what was visible and then
> >>>> copyrect them in.
> >>> 
> >>> In theory you can even change the whole of VNC into SPICE or the
> >>> whole of VI into EMACS, so???, I personaly think changing code
> >>> isnt the problem, the problem is always the desgien, and SPICE
> >>> have fandumental diffrent desgien than VNC, (Here you can say: OK
> >>> I can make my VNC desgien like SPICE, or you can say I think
> >>> SPICE dsgien is bad, or you can just use SPICE...)
> >> 
> >> Oh I'm not trying to talk you or anyone into anything. I was merely
> >> trying to stress that SPICE isn't really its own protocol but
> >> extensions to the RDP protocol (IIUC). You could do similar
> >> extensions to VNC if you liked. Thus I'd love to see a generic
> >> mid-layer and implementations of RDP and VNC on top of that
> >> actually.
> > 
> > One of the decisions we have made in SPICE, was to provide a full
> > functional remote system, not realying on other system,
> > We already have far more features than VNC have, so what is the
> > logical in making spice extention of VNC? it more logical to make
> > VNC extention of SPICE...
> > 
> > SPICE have networking tunneling, local/server mouse, (in progress)
> > usb remote, audio / recording channel , private channels for each
> > compoment, Even if VNC would have part of this stuff, It seems like
> > they are trying to achive things in diffrent way than SPICE does.
> 
> It kind of reminds me of the vbus story ;-).
> 
We are not forking qemu, we are self depended protocol, we have the
right to implment the protocol the best way as we understand, I don`t
see much connection with the VBus case...

The real interesting part is, that we not forcing any changes to qemu,
we dont say "throw" vnc, we just add another protocol, that users
already are using and are very happy.
check out:

http://www.brianmadden.com/blogs/brianmadden/archive/2009/12/10/red-hat-makes-the-qumranet-spice-protocol-open-source-a-free-alternative-to-ica-pcoip.aspx

Why is it that bad to allow user freedom of choice for whatever
protocol it want to use for its remote system?

Thanks.

> 
> Alex

Re: [Qemu-devel] Spice project is now open

[Alexander Graf]

On 12.12.2009, at 01:53, Izik Eidus wrote:

> On Sat, 12 Dec 2009 01:27:09 +0100
> Alexander Graf <agraf@suse.de> wrote:
> 
>> 
>> On 12.12.2009, at 01:14, Izik Eidus wrote:
>> 
>>> On Sat, 12 Dec 2009 00:54:47 +0100
>>> Alexander Graf <agraf@suse.de> wrote:
>>> 
>>>> 
>>>> On 11.12.2009, at 23:46, Izik Eidus wrote:
>>>> 
>>>>> On Fri, 11 Dec 2009 23:08:01 +0100
>>>>> Alexander Graf <agraf@suse.de> wrote:
>>>>> 
>>>>>> 
>>>>>> On 11.12.2009, at 22:13, Izik Eidus wrote:
>>>>>> 
>>>>>>> On Fri, 11 Dec 2009 14:46:55 -0600
>>>>>>> Anthony Liguori <anthony@codemonkey.ws> wrote:
>>>>>>> 
>>>>>>>> Izik Eidus wrote:
>>>>>>>>> I personaly dont like mjpeg, and yes in the end of the day you
>>>>>>>>> can add the video streaming into vnc, but what is the point
>>>>>>>>> here?
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> What I'm trying to understand is, what can we do with Spice
>>>>>>>> that we couldn't possibly do with vnc.  That means
>>>>>>>> understanding each feature and then figuring out if there's a
>>>>>>>> vnc analog.
>>>>>>>> 
>>>>>>>> If there are compellingly unique features to Spice that can't
>>>>>>>> be duplicated in vnc, then it's a no brainer.  If you can do
>>>>>>>> most things in vnc but it would be hackish whereas Spice makes
>>>>>>>> it all elegant, then provided we can merge Spice without a
>>>>>>>> huge amount of pain, then it's a net win.
>>>>>>>> 
>>>>>>>> However, if we need to make a few changes to vnc in order to
>>>>>>>> get the same performance as Spice, then it's not quite as
>>>>>>>> clear that it's what we should be using.
>>>>>>>> 
>>>>>>>> We're talking about a major change here.  There is a ton of
>>>>>>>> management software that assumes vnc today.  Even though there
>>>>>>>> are Spice clients out there, there are embedded vnc clients in
>>>>>>>> certain tools today along with java applets.
>>>>>>>> 
>>>>>>>> That's not to say we shouldn't embrace Spice, we just have to
>>>>>>>> make sure we have a good reason to.
>>>>>>> 
>>>>>>> Ok, I understand your concerns.
>>>>>>> 
>>>>>>> But even though that spice and vnc achive in the end of the day
>>>>>>> the same thing - they both allow remote rendering, they have
>>>>>>> fendumental diffrent architacture.
>>>>>>> 
>>>>>>> Spice server work with a ring to the guest, it was build from
>>>>>>> day one to work like that, In addition it was built from day
>>>>>>> one so that the server will render only what it must to render
>>>>>>> (to allow much higher virtualization denticity).
>>>>>> 
>>>>>> The ring is from qemu <-> guest, right? I mean, qemu <-> client
>>>>>> would be a TCP transport anyways, so the ring argument is void.
>>>>> 
>>>>> 
>>>>> Beside the fact that we dont have the network overhead...
>>>> 
>>>> Eh - when you connect to the VM remotely you still get the network
>>>> overhead, because you're connecting to it via the network :-).
>>> 
>>> Yes but you send the data from the HOST networking, not from the
>>> virtualized guest networking (That will later send it from the Host
>>> networking)...
>> 
>> Exactly. So you'd get the same as with virtio-fb and VNC :-).
> 
> Yes, virtio-fb and spice have the same overhead for the ring part,
> but this not what i understood when you said:
> "The ring is from qemu <-> guest, right? I mean, qemu <-> client
> would be a TCP transport anyways, so the ring argument is void."

Oh one of your arguments about the superiority of SPICE was that it uses a ring buffer. I just wanted to make sure you're talking about the guest <-> hypervisor interface there, thus not stressing anything in the SPICE protocol :-).

> 
> But leave it :).
> 
>> 
>>> 
>>> 
>>>> 
>>>>> 
>>>>>> 
>>>>>>> Just to make clear how much spice is diffrence from VNC is by
>>>>>>> the fact that only the library itself (not including the
>>>>>>> drivers) have 128,277 lines of code inside it. (In my old qemu
>>>>>>> repo i see almost 600,000 lines for qemu) so this should give
>>>>>>> better prespective on how much spice is diffrent from vnc.
>>>>>>> 
>>>>>>> So ofcurse in theory you can take all this 128,000 lines and
>>>>>>> push them into qemu-vnc.c ?, but you got to remember that spice
>>>>>>> is not just specific qemu thing, Spice should be used to work
>>>>>>> on physical machines too, just cutting all this lines of code
>>>>>>> from spice and throw it into qemu-vnc.c will be meaning a fork
>>>>>>> of spice inside qemu....
>>>>>> 
>>>>>> I definitely understand your point of having a single protocol.
>>>>>> The good news is that your physical machine stuff isn't released
>>>>>> yet (AFAIK), so luckily there's still time to change parts of the
>>>>>> protocol :-).
>>>>>> 
>>>>>>> It isnt just the rings and the rendering style that make spice
>>>>>>> diffrence, it is the channels it have for each compoment, it is
>>>>>>> the multiple drawing surfaces, and so on...
>>>>>> 
>>>>>> These should be fairly easy to implement in VNC too. In fact, I
>>>>>> remember a project implementing off-screen drawing in VNC using a
>>>>>> larger region of the screen than what was visible and then
>>>>>> copyrect them in.
>>>>> 
>>>>> In theory you can even change the whole of VNC into SPICE or the
>>>>> whole of VI into EMACS, so???, I personaly think changing code
>>>>> isnt the problem, the problem is always the desgien, and SPICE
>>>>> have fandumental diffrent desgien than VNC, (Here you can say: OK
>>>>> I can make my VNC desgien like SPICE, or you can say I think
>>>>> SPICE dsgien is bad, or you can just use SPICE...)
>>>> 
>>>> Oh I'm not trying to talk you or anyone into anything. I was merely
>>>> trying to stress that SPICE isn't really its own protocol but
>>>> extensions to the RDP protocol (IIUC). You could do similar
>>>> extensions to VNC if you liked. Thus I'd love to see a generic
>>>> mid-layer and implementations of RDP and VNC on top of that
>>>> actually.
>>> 
>>> One of the decisions we have made in SPICE, was to provide a full
>>> functional remote system, not realying on other system,
>>> We already have far more features than VNC have, so what is the
>>> logical in making spice extention of VNC? it more logical to make
>>> VNC extention of SPICE...
>>> 
>>> SPICE have networking tunneling, local/server mouse, (in progress)
>>> usb remote, audio / recording channel , private channels for each
>>> compoment, Even if VNC would have part of this stuff, It seems like
>>> they are trying to achive things in diffrent way than SPICE does.
>> 
>> It kind of reminds me of the vbus story ;-).
>> 
> We are not forking qemu, we are self depended protocol, we have the
> right to implment the protocol the best way as we understand, I don`t
> see much connection with the VBus case...
> 
> The real interesting part is, that we not forcing any changes to qemu,
> we dont say "throw" vnc, we just add another protocol, that users
> already are using and are very happy.
> check out:
> 
> http://www.brianmadden.com/blogs/brianmadden/archive/2009/12/10/red-hat-makes-the-qumranet-spice-protocol-open-source-a-free-alternative-to-ica-pcoip.aspx
> 
> Why is it that bad to allow user freedom of choice for whatever
> protocol it want to use for its remote system?

Nothing at all! I want to make it even more modular. I want to see a lego like approach where we can combine all the good parts together and use whatever we like from whatever corner we come from.

So the thing I dislike is the "take all of QXL and SPICE or leave everything" sort of attitude that's coming over. I'd love to use QXL, but I don't want to use SPICE :-). Thus I want to make sure we're going in a really modular direction, so all the bits can be combined to every users' liking. Thus creating choice.


Alex

Re: [Qemu-devel] Spice project is now open

[Izik Eidus]

On Sat, 12 Dec 2009 02:08:05 +0100
Alexander Graf <agraf@suse.de> wrote:

> So the thing I dislike is the "take all of QXL and SPICE or leave
> everything" sort of attitude that's coming over. I'd love to use QXL,
> but I don't want to use SPICE :-). Thus I want to make sure we're
> going in a really modular direction, so all the bits can be combined
> to every users' liking. Thus creating choice.

We are palning to add local rendering support for qxl inside qemu...

> 
> 
> Alex
> 

Re: [Qemu-devel] Spice project is now open

[Anthony Liguori]

Chris Wright wrote:
> * Anthony Liguori (anthony@codemonkey.ws) wrote:
>   
>> Izik Eidus wrote:
>>     
>>> Ok, I guess you think VDI-interfaces are doing much more than they do
>>> in reiality.
>>>
>>> It is just simple interface to Allow Spice / VNC / whatever not have to
>>> de-duplicate code in order to get information from - lets say the
>>> keyboard....
>>>
>>> Is it really diffrence from any other function callbacks that used for
>>> such purpuse?
>>>   
>>>       
>> Plugin interfaces have been discussed a few times in the past.  The  
>> concerns have been 1) they will be abused with the introduction of  
>> proprietary plugins 2) we would have tremendous difficulty maintaining a  
>> stable plugin abi 3) they would create stability issues in qemu because  
>> the plugin quality cannot be controlled.
>>     
>
> I think you're talking about dlopen() vs. direct linkage of .so?
>
> Here's some code to ground things a bit.
>
> ifdef CONFIG_SPICE
> CFLAGS+=$(SPICE_CFLAGS)
> LIBS+=$(SPICE_LIBS)
> endif
>
> And specifically, there's a notion of the VDI interface added to
> core qemu, which can be extended by simply registering callbacks to that
> interface:
>
> vl.c::main()
> ...
> #ifdef CONFIG_SPICE
> 	...
> 	spice_init(&core_interface);.
> #endif
>   

Ah, that's entirely reasonable.  When user provided libraries was 
mentioned, I assumed dlopen() style plugins.

Regards,

Anthony Liguori

Re: [Qemu-devel] Spice project is now open

[Izik Eidus]

On Fri, 11 Dec 2009 22:26:59 +0200
Izik Eidus <ieidus@redhat.com> wrote:

> On Fri, 11 Dec 2009 22:53:25 +0300 (MSK)
> malc <av1474@comtv.ru> wrote:
> 
> > On Fri, 11 Dec 2009, Izik Eidus wrote:
> > 
> > > On Fri, 11 Dec 2009 22:24:38 +0300 (MSK)
> > > malc <av1474@comtv.ru> wrote:
> > > 
> > > > On Fri, 11 Dec 2009, Izik Eidus wrote:
> > > > 
> > > > > On Fri, 11 Dec 2009 22:03:33 +0300 (MSK)
> > > > > malc <av1474@comtv.ru> wrote:
> > > > > 
> > > > > > On Fri, 11 Dec 2009, Izik Eidus wrote:
> > > > > > 
> > > > > > > On Fri, 11 Dec 2009 09:57:48 -0600
> > > > > > > Anthony Liguori <anthony@codemonkey.ws> wrote:
> > > > > > > 
> > > > > > [..snip..]
> > > > > > 
> > > > > > > 
> > > > 
> > > > [..snip..]
> > > > 
> > > > > > 
> > > > > > Any particular reason for implementing audio as a driver
> > > > > > instead of a capture?
> > > > > 
> > > > > 
> > > > > Spice doesnt have paravirtual audio driver, it use the AC97
> > > > > device.
> > > > 
> > > > Yes it has - interface_audio_driver in
> > > > audio/vd_interface_audio.c
> > > > 
> > > 
> > > I think the file name here is missleading you...
> > 
> > I think you just don't understand what i'm asking. Let me try to
> > expand: one way to implement audio interception is by having a
> > special audio_driver (wavaudio.c vd_interface_audio.c) the other is
> > by using a capture interface atop of existing driver (wavcapture.c
> > vnc.c)
> > 
> > I was curious as to why the former was chosen.
> > 
> 
> I see what you mean, I didnt write this part, so i will have to ask
> who wrote it and will come back to you with an answer why he did it
> like that.

Why sould we be any differnt from alsa or ogg, we are just another
audio player.


> 
> Thanks.
> 
> 

Re: [Qemu-devel] Spice project is now open

[Gerd Hoffmann]

   Hi,

> Well, in fact VNC would wait for the refresh timer of the VGA
> framebuffer dirty thing and only send a single update too.

Well, it isn't that simple.  When copyrect is used updates can be *much* 
more frequently.  Reason is that the vnc server has to push out 
outstanding dirty regions before sending the copyrect command. 
Otherwise the client-side blit would work with stale data.

cheers,
   Gerd

Re: [Qemu-devel] Spice project is now open

[Anthony Liguori]

Gerd Hoffmann wrote:
>   Hi,
>
>> Well, in fact VNC would wait for the refresh timer of the VGA
>> framebuffer dirty thing and only send a single update too.
>
> Well, it isn't that simple.  When copyrect is used updates can be 
> *much* more frequently.  Reason is that the vnc server has to push out 
> outstanding dirty regions before sending the copyrect command. 
> Otherwise the client-side blit would work with stale data.

Correct.  It's possible to do dependency tracking in order to queue the 
copyrects along with the intermediate updates but so far, this hasn't 
seemed to be necessary.

Regards,

Anthony Liguori

Re: [Qemu-devel] Spice project is now open

[Izik Eidus]

On Fri, 11 Dec 2009 17:07:13 -0200
Glauber Costa <glommer@gmail.com> wrote:

> >>
> >> Spice is a library, it is library for remote display, it handle by
> >> itself all the connection between the spice client to the host that
> >> run the guest, it include:
> >> sound, display, keyboard, usb, network tunneling (for printers)
> >> and so on...
> >>
> >
> > I want to add that qemu is not the sole user of spice, Spice will be
> > used as a protocol to connect into physical windows/linux
> > machines....
> >
> > So how can we change the library just for qemu?
> >
> I don't fully understand spice yet, but what's the difficulty here?
> libraries changes every single day to try to acomodate for the needs
> of specific users, be it through generalizations, shims, or whatever.
> 
> This is just another day in the OSS world.
> 
> 

We are working on physical machines support for spice. the library
contain all what need for remote display.