[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

[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

[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

[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]

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

[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

[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

[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

[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

[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: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

[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

[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

[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

[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]

* 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

[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

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

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

[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

[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

[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

[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

[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

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

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

[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

[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

[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

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

[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

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

[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

[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

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

[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

[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

[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

[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

[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

[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

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

[Paolo Bonzini]

On 12/11/2009 10:54 PM, Anthony Liguori wrote:
>
> 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]

Not necessarily, the X server can support the render extension which 
allows compositing operations on an X pixmap.  Firefox uses that 
extensively, for example to render tiled backgrounds (though probably 
GTK user interface elements can do so less successfully).

Paolo

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

[Anthony Liguori]

Paolo Bonzini wrote:
> On 12/11/2009 10:54 PM, Anthony Liguori wrote:
>>
>> 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]
>
> Not necessarily, the X server can support the render extension which 
> allows compositing operations on an X pixmap.  Firefox uses that 
> extensively, for example to render tiled backgrounds (though probably 
> GTK user interface elements can do so less successfully).

Yes, but this is just a single application.  The point is that these 
things are not as widely standardized on X as they are on Windows.

Regards,

Anthony Liguori

> Paolo
>
>
>

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

[Paolo Bonzini]

On 12/12/2009 04:34 AM, Anthony Liguori wrote:
>> Firefox uses that extensively, for example to render tiled backgrounds
>> (though probably GTK user interface elements can do so less
>> successfully).
>
> Yes, but this is just a single application.  The point is that these
> things are not as widely standardized on X as they are on Windows.

They are standardized (Xrender) and there are high-level de facto 
standard APIs (Cairo or the Qt equivalent).

If glyphs are rendered with Xrender it means that the shapes must be 
somehow transferred to the X server (and hence with SPICE-like protocols 
to the SPICE client), unlike with X fonts.  However these shapes will be 
grayscale (cheap) and the complicated compositing with the background 
will be all done via XRender (i.e. on the SPICE client too).

Regarding compositing, this is done via OpenGL so even though it is true 
that nothing goes through X calls, it is also true that everything does 
go though a high-level API which can be sent on the wire (cfr. AIGLX).

Actually, compositing might really be where a protocol like SPICE 
shines, since it does not generate nearly as many expose events, and 
since you do not have to resend occluded contents on the wire any time 
someone raises a window.

I have no idea how SPICE performs now, but there's definitely nothing in 
a modern X Windows desktop that it cannot deal with.  The only negative 
point it might have compared to Windows is IMO the rendering of text.

Paolo

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

[Anthony Liguori]

Paolo Bonzini wrote:
> On 12/12/2009 04:34 AM, Anthony Liguori wrote:
>>> Firefox uses that extensively, for example to render tiled backgrounds
>>> (though probably GTK user interface elements can do so less
>>> successfully).
>>
>> Yes, but this is just a single application.  The point is that these
>> things are not as widely standardized on X as they are on Windows.
>
> They are standardized (Xrender) and there are high-level de facto 
> standard APIs (Cairo or the Qt equivalent).

Cairo is pretty new and not widely used by applications yet.  But even 
Xrender is very limited compared to all of the things that GDI 
supports.  If it's just a matter of offloading Xrender, you could 
implement compositing in VNC fairly easily.

>
> Regarding compositing, this is done via OpenGL so even though it is 
> true that nothing goes through X calls, it is also true that 
> everything does go though a high-level API which can be sent on the 
> wire (cfr. AIGLX).

Right, but 3D is a different topic.  Spice doesn't address this today.

> Actually, compositing might really be where a protocol like SPICE 
> shines, since it does not generate nearly as many expose events, and 
> since you do not have to resend occluded contents on the wire any time 
> someone raises a window.

It's a trade off.  If you're sending each windows contents verses 
sending the visible screen, you're incurring an upfront cost assuming 
interaction will be improved.  This is something that I'd really like to 
see perf data on because.

> I have no idea how SPICE performs now, but there's definitely nothing 
> in a modern X Windows desktop that it cannot deal with.  The only 
> negative point it might have compared to Windows is IMO the rendering 
> of text.

I think the question I was raising was not whether Spice could handle X, 
but that given the things you can do with X, is all of Spice really 
needed.  IOW, would we get 99% of the way there with Xv accelerated 
overlays and Xrender based compositing for VNC?

BTW, can someone split out these VDI patches and get them on the list?  
Maybe at least an ETA of when that will happen.  I think it would make 
this whole discussion a lot more fruitful if we had more context..

Regards,

Anthony Liguori

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

[Avi Kivity]

On 12/12/2009 05:11 PM, Anthony Liguori wrote:
>
>> I have no idea how SPICE performs now, but there's definitely nothing 
>> in a modern X Windows desktop that it cannot deal with.  The only 
>> negative point it might have compared to Windows is IMO the rendering 
>> of text.
>
> I think the question I was raising was not whether Spice could handle 
> X, but that given the things you can do with X, is all of Spice really 
> needed.  IOW, would we get 99% of the way there with Xv accelerated 
> overlays and Xrender based compositing for VNC?

Suppose only 1% of spice is needed to support X. Given that we wish to 
support Windows well, does it matter?

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

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

[Anthony Liguori]

Avi Kivity wrote:
> On 12/12/2009 05:11 PM, Anthony Liguori wrote:
>>
>>> I have no idea how SPICE performs now, but there's definitely 
>>> nothing in a modern X Windows desktop that it cannot deal with.  The 
>>> only negative point it might have compared to Windows is IMO the 
>>> rendering of text.
>>
>> I think the question I was raising was not whether Spice could handle 
>> X, but that given the things you can do with X, is all of Spice 
>> really needed.  IOW, would we get 99% of the way there with Xv 
>> accelerated overlays and Xrender based compositing for VNC?
>
> Suppose only 1% of spice is needed to support X. Given that we wish to 
> support Windows well, does it matter?

I understand X better than I understand Windows so it's easier for me to 
understand things as they relate to X.

My original question was how much better is Spice support for Windows 
than it is for X.  If Spice is really designed for Windows and does 
really well for it, that's great.  I'm just trying to understand what 
it's good for and what it's not good for.

Regards,

Anthony Liguori

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

[Avi Kivity]

On 12/12/2009 07:28 PM, Anthony Liguori wrote:
>>> I think the question I was raising was not whether Spice could 
>>> handle X, but that given the things you can do with X, is all of 
>>> Spice really needed.  IOW, would we get 99% of the way there with Xv 
>>> accelerated overlays and Xrender based compositing for VNC?
>>
>> Suppose only 1% of spice is needed to support X. Given that we wish 
>> to support Windows well, does it matter?
>
>
> I understand X better than I understand Windows so it's easier for me 
> to understand things as they relate to X.
>
> My original question was how much better is Spice support for Windows 
> than it is for X.  If Spice is really designed for Windows and does 
> really well for it, that's great.  I'm just trying to understand what 
> it's good for and what it's not good for.

Spice was in fact designed primarly for Windows.  But given that 
graphics cards were designed for Windows and X tries to support graphics 
cards well, we should have a pretty good match.  Offscreen bitmaps and 
spice's client-side rendering model should work particularly well, I think.

-- 
error compiling committee.c: too many arguments to function

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

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

[Qemu-devel] X support for QXL and SPICE

[Soeren Sandmann]

Hi,

Here is an overview of what the current QXL driver does and does not
do.  The parts of X rendering that are currently being used by cairo
and Qt are:

- Most of XRender 
        - Image compositing
        - Glyphs
        - Trapezoids

- Bits of the core protocol:
        - Solid fills
        - CopyArea

The X driver for the QXL device is not yet very sophisticated. What it
does is basically this:

        - It keeps a separate memory framebuffer uptodate using
          software

        - Solid fills and CopyArea requests are turned into SPICE
          commands.

        - The cursor is drawn using cursor commands

        - For other things, bitmaps are sent across the wire
                - It uses the hashing feature of SPICE to only send
                  hashcodes for those bitmaps if it can get away with
                  it.

Even this simple support provides a better user experience than VNC
because scrolling is accelerated and doesn't result in a huge bitmap
getting sent across the wire. (I don't know if VNC has support for
bltblt, but even if it does, a screenscraping VNC server can't easily
make use of it).

I believe some parts of XRender can be supported within the existing
SPICE protocol, and that it would be fairly straightforward to add the
other parts.

However, as things stand right now, there is not much point in adding
this support, because X applications essentially always work like
this:

        - render to offscreen pixmap
        - copy pixmap to screen

There is not yet support for offscreen pixmaps in SPICE, so at the
moment, solid fill and CopyArea are the two main things that actually
make a difference.


Soren

[Qemu-devel] Re: X support for QXL and SPICE

[Alexander Graf]

On 12.12.2009, at 00:58, Soeren Sandmann wrote:

> Hi,
> 
> Here is an overview of what the current QXL driver does and does not
> do.  The parts of X rendering that are currently being used by cairo
> and Qt are:
> 
> - Most of XRender 
>        - Image compositing
>        - Glyphs
>        - Trapezoids
> 
> - Bits of the core protocol:
>        - Solid fills
>        - CopyArea
> 
> The X driver for the QXL device is not yet very sophisticated. What it
> does is basically this:
> 
>        - It keeps a separate memory framebuffer uptodate using
>          software

Very good :-).

>        - Solid fills and CopyArea requests are turned into SPICE
>          commands.

The Tight VNC extension implements commands for this. We only implement CopyArea in Qemu though.

>        - The cursor is drawn using cursor commands

VNC (the protocol) implements this.

>        - For other things, bitmaps are sent across the wire
>                - It uses the hashing feature of SPICE to only send
>                  hashcodes for those bitmaps if it can get away with
>                  it.

I think VNC doesn't have a notion of this yet. It should be fairly easy to add though.

> Even this simple support provides a better user experience than VNC
> because scrolling is accelerated and doesn't result in a huge bitmap
> getting sent across the wire. (I don't know if VNC has support for
> bltblt, but even if it does, a screenscraping VNC server can't easily
> make use of it).

What really surprises me is that this is pretty much what Xvnc does. Except for the bitmap cache of course.

Do you get better performance with SPICE on Linux guests than you get with direct Xvnc forwarding and -encodings 'tight copyrect'?

What does performance look like in comparison to Xrdp? That one does implement bitmap caches. It should be really really close, right?

Don't get me wrong - I'm not trying to talk anyone into what's best for anyone. I'm trying to understand what speed we can expect from which solution and what actually speeds up what :-).

Alex

Re: [Qemu-devel] Re: X support for QXL and SPICE

[Izik Eidus]

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


> 
> What does performance look like in comparison to Xrdp? That one does
> implement bitmap caches. It should be really really close, right?

Untill Spice wont have the opengl support merged, I dont think it fair
to compare it into other stuff that do X, the opengl 3d rendering
should take much of spice advantages and work on spice better (at
least this my opinion)

And beside Linux you got Windows that in that area Spice is much more
advanced... 

> 
> Don't get me wrong - I'm not trying to talk anyone into what's best
> for anyone. I'm trying to understand what speed we can expect from
> which solution and what actually speeds up what :-).


We dont get you wrong :).


> 
> Alex
> 

Re: [Qemu-devel] Re: X support for QXL and SPICE

[Alexander Graf]

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

> On Sat, 12 Dec 2009 01:05:36 +0100
> Alexander Graf <agraf@suse.de> wrote:
> 
> 
>> 
>> What does performance look like in comparison to Xrdp? That one does
>> implement bitmap caches. It should be really really close, right?
> 
> Untill Spice wont have the opengl support merged, I dont think it fair
> to compare it into other stuff that do X, the opengl 3d rendering
> should take much of spice advantages and work on spice better (at
> least this my opinion)

Oh Xrdp has 2 modes.

1) frame buffer mode
2) X passthrough

I was talking about the first one.

Alex

[Qemu-devel] Re: X support for QXL and SPICE

[Izik Eidus]

On 12 Dec 2009 00:58:13 +0100
Soeren Sandmann <sandmann@daimi.au.dk> wrote:

> 
> However, as things stand right now, there is not much point in adding
> this support, because X applications essentially always work like
> this:
> 
>         - render to offscreen pixmap
>         - copy pixmap to screen
> 
> There is not yet support for offscreen pixmaps in SPICE, so at the
> moment, solid fill and CopyArea are the two main things that actually
> make a difference.

I Have patch that already add this support, we delayed it integration
in order that we will make sure that the new surfaces/offscreens
architacture would work well for all the users (windows and X), we
should see it in very soon.

Thanks.

> 
> 
> Soren

Re: [Qemu-devel] X support for QXL and SPICE

[Anthony Liguori]

Soeren Sandmann wrote:
> Hi,
>
> Here is an overview of what the current QXL driver does and does not
> do.  The parts of X rendering that are currently being used by cairo
> and Qt are:
>
> - Most of XRender 
>         - Image compositing
>         - Glyphs
>   

Does anything use Xrender for drawing glyphs these days?

Certainly, with a compositing window manager, nothing is getting 
rendered by X...

> The X driver for the QXL device is not yet very sophisticated. What it
> does is basically this:
>
>         - It keeps a separate memory framebuffer uptodate using
>           software
>
>         - Solid fills and CopyArea requests are turned into SPICE
>           commands.
>
>         - The cursor is drawn using cursor commands
>
>         - For other things, bitmaps are sent across the wire
>                 - It uses the hashing feature of SPICE to only send
>                   hashcodes for those bitmaps if it can get away with
>                   it.
>
> Even this simple support provides a better user experience than VNC
> because scrolling is accelerated and doesn't result in a huge bitmap
> getting sent across the wire.

Scrolling is accelerated in VNC.  In the Cirrus adapter, both X and 
Windows use a video-to-video bitblt, we use this to create a VNC 
CopyRect which makes scrolling and Window movement smooth.

> However, as things stand right now, there is not much point in adding
> this support, because X applications essentially always work like
> this:
>
>         - render to offscreen pixmap
>         - copy pixmap to screen
>
> There is not yet support for offscreen pixmaps in SPICE, so at the
> moment, solid fill and CopyArea are the two main things that actually
> make a difference.
>   

Okay, that's in line with what my expectations were.  So what's the 
future of Spice for X?  Anything clever or is Windows the only target 
right now?

Regards,

Anthony Liguori

Re: [Qemu-devel] X support for QXL and SPICE

[Izik Eidus]

On Fri, 11 Dec 2009 21:31:34 -0600
Anthony Liguori <anthony@codemonkey.ws> wrote:
> 
> Okay, that's in line with what my expectations were.  So what's the 
> future of Spice for X?  Anything clever or is Windows the only target 
> right now?

Offscreen pixmaps, Xrender, opengl 3d commands, Video extention.

I dont understand what you want here?

Spice is not responsible for how X work the fact that X doesnt have
many things that windows have - doesnt mean it is bad spice DOES have
them...

Btw Xrender is used by cario hardware accelration...

> 
> Regards,
> 
> Anthony Liguori

Re: [Qemu-devel] X support for QXL and SPICE

[Anthony Liguori]

Izik Eidus wrote:
> On Fri, 11 Dec 2009 21:31:34 -0600
> Anthony Liguori <anthony@codemonkey.ws> wrote:
>   
>> Okay, that's in line with what my expectations were.  So what's the 
>> future of Spice for X?  Anything clever or is Windows the only target 
>> right now?
>>     
>
> Offscreen pixmaps, Xrender, opengl 3d commands, Video extention.
>
> I dont understand what you want here?
>   

To understand what makes Spice special.

> Spice is not responsible for how X work the fact that X doesnt have
> many things that windows have - doesnt mean it is bad spice DOES have
> them...
>   

Don't confuse trying to understand Spice with attempts to poke holes or 
criticize Spice.  There is very little information about what makes 
Spice interesting.

Regards,

Anthony Liguori

Re: [Qemu-devel] X support for QXL and SPICE

[Izik Eidus]

On Sat, 12 Dec 2009 09:13:51 -0600
Anthony Liguori <anthony@codemonkey.ws> wrote:

> Izik Eidus wrote:
> > On Fri, 11 Dec 2009 21:31:34 -0600
> > Anthony Liguori <anthony@codemonkey.ws> wrote:
> >   
> >> Okay, that's in line with what my expectations were.  So what's
> >> the future of Spice for X?  Anything clever or is Windows the only
> >> target right now?
> >>     
> >
> > Offscreen pixmaps, Xrender, opengl 3d commands, Video extention.
> >
> > I dont understand what you want here?
> >   
> 
> To understand what makes Spice special.


Spice is interesting beacuse unlike the great VNC protocol it already
have what it take to make VDI possible to the user.

If you think all the above features are pointless and if you think that
Windows graphic systems (90% of the world wide desktops users) is not
important, I really dont know what to tell you.

It is easy to say about everything "We can implment it in VNC..." yes.
and I can write my own new operation system and tell everyone "Haa,
right now i dont have it, but it is easy to implement"...

It is naive to think that software is all about features..., In this
case Linux / Freebsd are the same thing..., ohh wait they are diffrent
no?.

Wait, I think Google, Yahoo and Bing, does`nt they all have the same
features????, How come ppl still prefer to use Google in that case?

VNC is much older than spice, but still why it didnt get all this SPICE
protocol goodies? why? (I mean it is so easy to add this into VNC...)

> 
> > Spice is not responsible for how X work the fact that X doesnt have
> > many things that windows have - doesnt mean it is bad spice DOES
> > have them...
> >   
> 
> Don't confuse trying to understand Spice with attempts to poke holes
> or criticize Spice.  There is very little information about what
> makes Spice interesting.

There is a complete protocol paper that expline the whole protocol,
There is me answering you to any question that you ask,
There is the whole source open, what more do you need?

> 
> Regards,
> 
> Anthony Liguori
> 

Re: [Qemu-devel] X support for QXL and SPICE

[Alexander Graf]

On 12.12.2009, at 16:29, Izik Eidus wrote:

> On Sat, 12 Dec 2009 09:13:51 -0600
> Anthony Liguori <anthony@codemonkey.ws> wrote:
> 
>> Izik Eidus wrote:
>>> On Fri, 11 Dec 2009 21:31:34 -0600
>>> Anthony Liguori <anthony@codemonkey.ws> wrote:
>>> 
>>>> Okay, that's in line with what my expectations were.  So what's
>>>> the future of Spice for X?  Anything clever or is Windows the only
>>>> target right now?
>>>> 
>>> 
>>> Offscreen pixmaps, Xrender, opengl 3d commands, Video extention.
>>> 
>>> I dont understand what you want here?
>>> 
>> 
>> To understand what makes Spice special.
> 
> 
> Spice is interesting beacuse unlike the great VNC protocol it already
> have what it take to make VDI possible to the user.
> 
> If you think all the above features are pointless and if you think that
> Windows graphic systems (90% of the world wide desktops users) is not
> important, I really dont know what to tell you.
> 
> It is easy to say about everything "We can implment it in VNC..." yes.
> and I can write my own new operation system and tell everyone "Haa,
> right now i dont have it, but it is easy to implement"...
> 
> It is naive to think that software is all about features..., In this
> case Linux / Freebsd are the same thing..., ohh wait they are diffrent
> no?.
> 
> Wait, I think Google, Yahoo and Bing, does`nt they all have the same
> features????, How come ppl still prefer to use Google in that case?
> 
> VNC is much older than spice, but still why it didnt get all this SPICE
> protocol goodies? why? (I mean it is so easy to add this into VNC...)

I think you're getting the wrong message. Let me tell you something about my work on virtio-fb.

I did 2 versions. The first one was completely ring and message based. I used the virtio ring topology to send framebuffer updates along to the hypervisor, basically resembling the linux fb callback interface.

While that worked, it was _horribly_ slow. I didn't know why. Until I found out that all of this transferring happens synchronously! So on every linuxfb function call we basically got a hypervisor exit, resulting in a lot of overhead. Not to speak of all the vmalloc magic I had to do.

If I had known before that this is a bottleneck, I would have designed the protocol differently. In fact, I did for v2 - and ended up having only a single real command in my awesome protocol: "mark dirty". So I ended up basically reimplementing the same framebuffer based interface we use in qemu already. Oh great.

If anybody would have been around to tell me that what I'm doing is a bad idea because he went through it before, or if I had simply known before, I wouldn't have made those mistakes. It's all about knowledge.


Another example.


I'm always having a hard time understanding why VNC is slow. I've seriously always been wondering. And I'm still puzzled as to why RDP is so much superior performance-wise. After all, it basically only implements framebuffer updates too.

So now you bring in SPICE to that equation. I don't know _why_ SPICE is faster. I know that it is and I hear all those awesome great features. But I still don't have a feeling on which part of it really is the performance booster. As with the example above, I would never have guessed that doing synchronous updates is the performance killer. I'm still trying to figure out what is going wrong in VNC :-).

So don't take this as an offense. It's about learning from you guys. You're the ones that measured what makes things fast - and we want to know! Even if we're not building code on it, but using SPICE, it'd still be very valuable to know why exactly it is performing better. And best case also by how much each single feature saves us.


Alex

PS: Let me explain my background on those questions:

I'm stuck with VNC for SUSE Studio for now. While I can't make fundamental changes to the protocol, I can easily modify the guest and I can also easily modify the VNC viewer to add a few new commands. If I can get a throughput reduction of 50% by using 2 out of 10 features SPICE has as VNC protocol extensions, I'd gladly implement them. That'd just make user experience on our side a lot better. If that means using QXL inside the guest, so be it :-).

Re: [Qemu-devel] X support for QXL and SPICE

[Izik Eidus]

On Sat, 12 Dec 2009 16:43:43 +0100
Alexander Graf <agraf@suse.de> wrote:
> 
> 
> I'm always having a hard time understanding why VNC is slow. I've
> seriously always been wondering. And I'm still puzzled as to why RDP
> is so much superior performance-wise. After all, it basically only
> implements framebuffer updates too.

Not really, RDP does have commands in its protocol.
The latest RDP 7 is even more advance in that but lack the abilaty to
enjoy it when not using "same codecs / dx" support.

> 
> So now you bring in SPICE to that equation. I don't know _why_ SPICE
> is faster. I know that it is and I hear all those awesome great
> features. But I still don't have a feeling on which part of it really
> is the performance booster. As with the example above, I would never
> have guessed that doing synchronous updates is the performance
> killer. I'm still trying to figure out what is going wrong in VNC :-).
> 
> So don't take this as an offense. It's about learning from you guys.
> You're the ones that measured what makes things fast - and we want to
> know! Even if we're not building code on it, but using SPICE, it'd
> still be very valuable to know why exactly it is performing better.
> And best case also by how much each single feature saves us.


From my point of view, Effective commands transfer, Smart Depth tree
usage, Effective Cache, (the soon to be merged offscreens), Effective
Compression, and Effective Video streaming, this what need to have for
making things fast...

But It is not that easy as it sound, beacuse spice is really not just
about sending simple "draw_line command".

it is system that was desgiened to send commands from day one, and to
be used by kvm to reduce host cpu usage, The QXL driver, the QXL
Device, the Spice server, The spice Client, all of this peice of
software togather bring spice into what it is.

(As you saw above, you said it yourself, in the middle of making such
 system there are alot of performence questions, some times the answers
 are not absolute, And I sure VNC beat spice in some cases, But this is
 the whole point, allowing the user to choce what ever protocol he
 want)

Thanks.

> 
> 
> Alex
> 
> PS: Let me explain my background on those questions:
> 
> I'm stuck with VNC for SUSE Studio for now. While I can't make
> fundamental changes to the protocol, I can easily modify the guest
> and I can also easily modify the VNC viewer to add a few new
> commands. If I can get a throughput reduction of 50% by using 2 out
> of 10 features SPICE has as VNC protocol extensions, I'd gladly
> implement them. That'd just make user experience on our side a lot
> better. If that means using QXL inside the guest, so be it :-).
> 

Re: [Qemu-devel] X support for QXL and SPICE

[Dave Airlie]

On Sat, Dec 12, 2009 at 1:31 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> Soeren Sandmann wrote:
>>
>> Hi,
>>
>> Here is an overview of what the current QXL driver does and does not
>> do.  The parts of X rendering that are currently being used by cairo
>> and Qt are:
>>
>> - Most of XRender        - Image compositing
>>        - Glyphs
>>
>
> Does anything use Xrender for drawing glyphs these days?

Yes all of cairo apps and gtk, pretty much anything doing anti-aliased
fonts on a modern Linux desktop
uses X render to draw glyps. I think QT can use Xrender also but not
100% sure what the default is.
>
> Certainly, with a compositing window manager, nothing is getting rendered by
> X...

Yes there is, with a GL compositing window manager nothing is rendered
by X, with an Xrender
compositing window manager (metacity or kwin xrender mode). Also
allanti-aliased font operations, and
a number of cairo operations are done using xrender, which means most
of the modern desktop,
I actually broke sw fallbacks to the frontbuffer on my driver last
week and it took me nearly a half a day to realise it.

X rendering in modern apps is like Soeren describes, render to
offscreen pixmap, copy to onscreen.

> Scrolling is accelerated in VNC.  In the Cirrus adapter, both X and Windows
> use a video-to-video bitblt, we use this to create a VNC CopyRect which
> makes scrolling and Window movement smooth.

Firefox scrolling? (though I'm not sure anyone deals with it sainly).

>
>> However, as things stand right now, there is not much point in adding
>> this support, because X applications essentially always work like
>> this:
>>
>>        - render to offscreen pixmap
>>        - copy pixmap to screen
>>
>> There is not yet support for offscreen pixmaps in SPICE, so at the
>> moment, solid fill and CopyArea are the two main things that actually
>> make a difference.
>>
>
> Okay, that's in line with what my expectations were.  So what's the future
> of Spice for X?  Anything clever or is Windows the only target right now?
>

If spice grows offscreen surfaces along with some a few more rendering
operations I expect we can make it go fairly fast for most X apps. Since
at RH we have both spice and X teams I think we can probably produce
some sort of collaborative plan in the short term on how to go forward.

Dave.

Re: [Qemu-devel] X support for QXL and SPICE

[Soeren Sandmann]

Anthony Liguori <anthony@codemonkey.ws> writes:

> Soeren Sandmann wrote:
> > Hi,
> >
> > Here is an overview of what the current QXL driver does and does not
> > do.  The parts of X rendering that are currently being used by cairo
> > and Qt are:
> >
> > - Most of XRender         - Image compositing
> >         - Glyphs
> >
> 
> Does anything use Xrender for drawing glyphs these days?

Yes, essentially everything on a desktop uses Xrender for glyphs.

The way glyphs work in XRender is basically like this:

        - The client stores a bunch of glyphs in the X server. The
          data structure is called a GlyphSet

        - Whenever it wants to draw text, it sends a string of indices
          into this a GlyphSet along with coordinates.

Adding support for this to SPICE amounts to offscreen pixmaps along
with a compact way of representing text.

> Certainly, with a compositing window manager, nothing is getting
> rendered by X...

With a compositing manager, all windows are redirected to offscreen
pixmaps, and the compositing manager will then use either OpenGL or
XRender to composite all those pixmaps together whenever one of them
changes.

Rendering to these offscreen pixmaps is still done by X in the same
way I described before:

        - Render to temporary offscreen pixmap (T)

        - Copy pixmap T to window W, where W is redirected to another
          pixmap, which is not T.

So X is still rendering, even when there is a compositing manager.

> > The X driver for the QXL device is not yet very sophisticated. What it
> > does is basically this:
> >
> >         - It keeps a separate memory framebuffer uptodate using
> >           software
> >
> >         - Solid fills and CopyArea requests are turned into SPICE
> >           commands.
> >
> >         - The cursor is drawn using cursor commands
> >
> >         - For other things, bitmaps are sent across the wire
> >                 - It uses the hashing feature of SPICE to only send
> >                   hashcodes for those bitmaps if it can get away with
> >                   it.
> >
> > Even this simple support provides a better user experience than VNC
> > because scrolling is accelerated and doesn't result in a huge bitmap
> > getting sent across the wire.
> 
> Scrolling is accelerated in VNC.  In the Cirrus adapter, both X and
> Windows use a video-to-video bitblt, we use this to create a VNC
> CopyRect which makes scrolling and Window movement smooth.

The solid fill acceleration also makes a difference because windows
usually have a solid background, so when they are expose (for example
by someone dragging one window over another), their background gets
filled by the X server.

The bitmap hashing also made a fairly noticable difference for
animations where the same few images get sent again and
again. Eventually, many of these cases are better handled with
offscreen pixmaps, but there likely are applications drawing the image
over and over withing putting it into a pixmap.

> > However, as things stand right now, there is not much point in adding
> > this support, because X applications essentially always work like
> > this:
> >
> >         - render to offscreen pixmap
> >         - copy pixmap to screen
> >
> > There is not yet support for offscreen pixmaps in SPICE, so at the
> > moment, solid fill and CopyArea are the two main things that actually
> > make a difference.
> >
> 
> Okay, that's in line with what my expectations were.  So what's the
> future of Spice for X?  Anything clever or is Windows the only target
> right now?

I'd say that offscreen pixmaps is the biggest missing feature at the
moment as far as performance improvements go.

There are some other things that would be interesting to do:

- Really good RandR support

  The QXL driver already has rudimentary RandR support - ie., basic
  mode switching on the fly, which is reflected on the client side.

  But newer versions of RandR are much more capable: a graphics
  adapter can report when screens are plugged in and what their
  capabilities are and so on. It would make sense to capture this
  information on the client side and expose it through the QXL device.


- Video support

  The QXL device tries to detect when a piece of the screen is really
  a video, but we can do better by implementing the Xv extension (or
  whatever ends up being the future of video playback on Linux). It
  may also make sense to add support for "decoding" Theora or other
  video codecs to QXL, and then tunnel compressed video to the client.


Soren

Re: [Qemu-devel] X support for QXL and SPICE

[Gerd Hoffmann]

On 12/12/09 00:58, Soeren Sandmann wrote:
> Even this simple support provides a better user experience than VNC
> because scrolling is accelerated and doesn't result in a huge bitmap
> getting sent across the wire. (I don't know if VNC has support for
> bltblt, but even if it does, a screenscraping VNC server can't easily
> make use of it).

cirrus vga bitblit op is mapped to vnc copyrect.
X + cirrus driver + xterm make use of it for text scrolling.

cheers,
   Gerd

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

[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

[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

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

[Paolo Bonzini]

On 12/11/2009 10:58 PM, Anthony Liguori wrote:
> The concerns have been 1) they will be abused with the introduction
> of proprietary plugins

How so?

> 2) we would have tremendous difficulty maintaining a stable plugin abi

Then don't promise it.  GCC doesn't for example.  (And it solves problem 
1 too!...)

> 3) they would create stability issues
> in qemu because the plugin quality cannot be controlled.

How is this different from 3rd party modules in the kernel?

Paolo

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

[Anthony Liguori]

Paolo Bonzini wrote:
> On 12/11/2009 10:58 PM, Anthony Liguori wrote:
>> The concerns have been 1) they will be abused with the introduction
>> of proprietary plugins
>
> How so?

A typical scenario is someone develops a closed source plugin, but does 
not distribute it with the original piece of software thinking that they 
aren't creating a derived work because there's no combination.

But it's not necessary to get too tied up in this one.  The later are 
more important.

>> 2) we would have tremendous difficulty maintaining a stable plugin abi
>
> Then don't promise it.  GCC doesn't for example.  (And it solves 
> problem 1 too!...)

GCC is not the best example since it's support for plugins are 
relatively new.  It's bad for users.  They start using a plugin for one 
version and they really like it, they want to update to a new version of 
the base program and now their plugin no longer works.  The plugin has 
gone unmaintained and now they have to choose between the plugin and 
updating the base program.

>> 3) they would create stability issues
>> in qemu because the plugin quality cannot be controlled.
>
> How is this different from 3rd party modules in the kernel?

I don't think the kernel is an example of it working smoothly.  It's a 
constant source of frustration for users and people are constantly doing 
ugly things wrt licensing.

Regards,

Anthony Liguori

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

[Andrea Arcangeli]

Hi everyone,

On Fri, Dec 11, 2009 at 09:44:02PM -0600, Anthony Liguori wrote:
> A typical scenario is someone develops a closed source plugin, but does 
> not distribute it with the original piece of software thinking that they 
> aren't creating a derived work because there's no combination.

Creation of derived work of a GPL'd program isn't defined like
this. You can ask confirmation to IBM lawyers. Even ignoring the
explicit allow Linus gave (initially for already existing x86 drivers
coming from other proprietary OS that had more drivers than linux at
the time), it was meant for software written for other OS and ported
over to be dynamic linked into the kernel, so clearly not creating a
derivative work as the binary existed already for other OS.

This has been abused, and later EXPORT_MODULE_GPL was added
too... Even if anybody can remove the _GPL tag with any GPL'd patch,
without necessarily creating a derivative work or breaking the GPL by
removing that _GPL suffix. However if your module only works after you
remove a couple of _GPL suffixes that rings an huge bell that you are
breaking the GPL and everyone will look if that really is a derivative
work or not.

> GCC is not the best example since it's support for plugins are 
> relatively new.  It's bad for users.  They start using a plugin for one 
> version and they really like it, they want to update to a new version of 
> the base program and now their plugin no longer works.  The plugin has 
> gone unmaintained and now they have to choose between the plugin and 
> updating the base program.

If plugin is dead and unmaintained I guess it wasn't so useful after
all... besides it's all GPL so he can maintain it himself.

Libs APIs also are upgraded and they stop building and you got to
upgrade the program too in order to use the new lib. It doesn't matter
if this is called a plugin, static or dynamic lib, in raw terms it's
just a function that changed its arguments, how the function .text is
loaded into the address space is technicality.

> I don't think the kernel is an example of it working smoothly.  It's a 
> constant source of frustration for users and people are constantly doing 
> ugly things wrt licensing.

There are lots of less stable GPL'd module drivers too, it's not just
nvidia, so what? Besides the tainting flag that avoids some of the
time waste of the few abuses of the interface, CONFIG_MODULE=y is
clearly a net win and removing pluggable modules would be insanity. In
life few things are black and white and 100% improvements, but when
the benefit greatly exceeds the downsides, it's fairly silly to use
the few downsides as an argument to reject it. It'd be like refusing
to catch a plane because it could crash in the middle of the ocean.

In a previous email you said:

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

There's no such thing as a policy in open source, this is not a
committee, code rulez in GPL'd world, everything else is irrelevant.


About the discussion of improving VNC, this code has to change and
move so fast (you can see already requests from Alexander to split the
features to allow remote usb from remote qlx, it's expectable code to
change for the better to support more obscure features than 99% of
userbase cares about as it goes open), it's huge, it's unreasonable to
pretend to make official modifications to VNC protocol every time we
do a small change to the protocol to please Alexander or anybody other
reasonable wishes of the day, even vnc could eventually reach
equivalent speedup (which is debatable too). Going the vnc route and
official feature requests to extend the protocol is a dead hand IMHO,
all you can argue is spice or something else separate from vnc.

Likely the spice protocol should be left free to float for a while so
all graphics people can put their hands on it and improve it. Open
sourcing it is going to inevitably improve spice protocol. There is no
hardware involvement, no lock-in, no lack of specs, this is an area
where open source can shine against proprietary world. But policies,
licenses and in general political arguments must be left void and
irrelevant and we must stick to technical discussions about code.

Once things settled down and protocol is stable it is very reasonable
to expect a VNC export to enable/disable so legacy vnc clients can
still be used on qlx guest even if they will lose most of the
benefits. But worrying and discussing it now is too early. It would be
like pretending to provide a git-svn importer before git was actually
usable...

Overall, it's awesome SPICE has been finally released Open Source,
even if in only in tarball form so far.  I hope splitting the tarball
in patches is also feasible... ;) and it will be done, but clearly
it's a clumsy work and so I guess it will take a bit of time so
there's no particular reason to worry about that. You know it's not
worth fighting about tarball issues but hey we're all humans so it can
happen, get over it. The tarball allows first open technical review of
the technology and to get all the bits sorted out. We believe in Open
Source to shine in the long term, and this opens the way for real open
source efficient desktop virtualization. Let's stick to that and
technical arguments ;). Which probably means this thread should stop
temporarily and everyone should wait first possibly "mergeable"
patches to come to list. And my hope is that soon enough we can enjoy
some performance higher than vnc could ever deliver!

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

[Anthony Liguori]

Andrea Arcangeli wrote:
> About the discussion of improving VNC, this code has to change and
> move so fast (you can see already requests from Alexander to split the
> features to allow remote usb from remote qlx, it's expectable code to
> change for the better to support more obscure features than 99% of
> userbase cares about as it goes open), it's huge, it's unreasonable to
> pretend to make official modifications to VNC protocol every time we
> do a small change to the protocol to please Alexander or anybody other
> reasonable wishes of the day, even vnc could eventually reach
> equivalent speedup (which is debatable too). Going the vnc route and
> official feature requests to extend the protocol is a dead hand IMHO,
> all you can argue is spice or something else separate from vnc.
>   

What I really want is a high quality paper comparing Spice to other 
options (like VNC) with performance graphs demonstrating why it's so 
much better.  A paper isn't really necessary but what I'd like to see is 
that level of detailed comparison.

Spice has been closed source for a long time.  For those that have been 
involved with Spice development, I'm sure you understand very well why 
it's so wonderful, but for the rest of us, Spice didn't exist until 
yesterday so it's going to take a little bit for us to all understand 
what actually about it makes it special.

And with respect to the spice protocol, what's the model around making 
changes to the specification?  Is it just submit a patch to the spice 
project?  You complain about VNC's extensibility, but so far, we have no 
idea whether it's even possible to extend Spice.  Given the interactions 
so far, I'm a little concerned about how well we can influence the protocol.

If spice really needs to be able to evolve on it's own, what would it 
take for spice to be implementable from an external process?  What level 
of interaction does it need with qemu?  As long as we can prevent any 
device state from escaping from qemu, I'd be very interested in a model 
where spice lived entirely in a separate address space.

Regards,

Anthony Liguori

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

[Andrea Arcangeli]

On Sat, Dec 12, 2009 at 09:03:26AM -0600, Anthony Liguori wrote:
> Spice has been closed source for a long time.  For those that have been 
> involved with Spice development, I'm sure you understand very well why 
> it's so wonderful, but for the rest of us, Spice didn't exist until 
> yesterday so it's going to take a little bit for us to all understand 
> what actually about it makes it special.

I personally wasn't involved but I've seen it running with video
fullscreen and I don't know the comparison with rdesktop as I never
used it but I know the comparsion with vnc too well ;). It has to get
even faster and avoid decoding the compressed stream on the server.

> project?  You complain about VNC's extensibility, but so far, we have no 
> idea whether it's even possible to extend Spice.  Given the interactions 
> so far, I'm a little concerned about how well we can influence the protocol.

Well this is open source, so you know, anybody can change it, fork it,
takeover it, simply. And it's in the interest of everyone to help in
converging on the best SPICE protocol.

> If spice really needs to be able to evolve on it's own, what would it 
> take for spice to be implementable from an external process?  What level 
> of interaction does it need with qemu?  As long as we can prevent any 
> device state from escaping from qemu, I'd be very interested in a model 
> where spice lived entirely in a separate address space.

Funny thing is I think it's already in a separate process! ;) (you
know it wasn't open source until recently so...), but now that you
mention it, I think it should be changed to not be in a separate
process...

Linux is monolithic, KVM is the monolithic way (xen is the microkernel
slow way), I think you don't need to worry about sharing spice libs in
the same address space. We want to make it as fast as feasible on the
server side. A separate address space forces tlb flushes, mm switches
and screw performance and spice is all about performance. We've
already a pipe to connect server and client, we should try to avoid
having two pipes as much as possible and have a single exit to qemu
spice ring and send directly to spice client with virtio instead of
sending to separate process that eventually sends to remote spice
client.

Like 99% of microkernel designs they're very wasteful, what good it
does that the network is still up and running when you lost access to
your harddisk because the sata driver crashed? Or to have access to
sata disk but network driver crashed and you can't reach the system
anymore. Yeah there are corner cases where they can be useful but
those won't use linux kernel or monolitich kvm design in the first
place and they will run dogslow and they'll demonstrate math
correctness all software running on the bare metal with math which
means you can't patch the software anymore until math people
recomputes. We're not in that environment (luckily).

In this case keeping it separate means the desktop remains reachable
through network but virtual graphics card, virtual mouse and stuff
crashed, if somebody uses qlx that means the VM has to be rebooted
anyway. Ok, it won't risk to create disk corruption but in practice
the slowdown it creates it's not worth paying compared to the minor
risk that you really end up corrupting a bit in qcow2 cluster bitmap
in a way that doesn't crash the VM but silently corrupts data. If
something if I had to pay slowdown for higher reliability of disk I/O
it would be much better to move qcow2 and the I/O stack to its own
address space so it's protected from all the rest too... plus qcow2 is
a lot less performance critical than network graphics! Plus there's
valgrind and all that userland stuff to trap memory corruption, orders
of magnitude easier to debug than kernel random corruption (that over
time we fix too and so we keep run at max speed).

Having the thing modular at runtime not only at ./configure time
(loadable dynamically into qemu address space) OTOH is great idea, so
you can disable the module and verify the crashes go away without
having to rebuild.

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

[Anthony Liguori]

Andrea Arcangeli wrote:
> On Sat, Dec 12, 2009 at 09:03:26AM -0600, Anthony Liguori wrote:
>   
>> Spice has been closed source for a long time.  For those that have been 
>> involved with Spice development, I'm sure you understand very well why 
>> it's so wonderful, but for the rest of us, Spice didn't exist until 
>> yesterday so it's going to take a little bit for us to all understand 
>> what actually about it makes it special.
>>     
>
> I personally wasn't involved but I've seen it running with video
> fullscreen and I don't know the comparison with rdesktop as I never
> used it but I know the comparsion with vnc too well ;). It has to get
> even faster and avoid decoding the compressed stream on the server.
>   

I can run video full screen with VNC on my local lan.  In fact, that's 
the benchmark I use to do perf measurements with gtk-vnc.

I'm not saying that VNC handles video as well as Spice, I can pretty 
much guarantee that it doesn't :-)

>> If spice really needs to be able to evolve on it's own, what would it 
>> take for spice to be implementable from an external process?  What level 
>> of interaction does it need with qemu?  As long as we can prevent any 
>> device state from escaping from qemu, I'd be very interested in a model 
>> where spice lived entirely in a separate address space.
>>     
>
> Funny thing is I think it's already in a separate process! ;) (you
> know it wasn't open source until recently so...), but now that you
> mention it, I think it should be changed to not be in a separate
> process...
>
> Linux is monolithic, KVM is the monolithic way (xen is the microkernel
> slow way), I think you don't need to worry about sharing spice libs in
> the same address space. We want to make it as fast as feasible on the
> server side. A separate address space forces tlb flushes, mm switches
> and screw performance and spice is all about performance. We've
> already a pipe to connect server and client, we should try to avoid
> having two pipes as much as possible and have a single exit to qemu
> spice ring and send directly to spice client with virtio instead of
> sending to separate process that eventually sends to remote spice
> client.
>
> Like 99% of microkernel designs they're very wasteful, what good it
> does that the network is still up and running when you lost access to
> your harddisk because the sata driver crashed? Or to have access to
> sata disk but network driver crashed and you can't reach the system
> anymore. Yeah there are corner cases where they can be useful but
> those won't use linux kernel or monolitich kvm design in the first
> place and they will run dogslow and they'll demonstrate math
> correctness all software running on the bare metal with math which
> means you can't patch the software anymore until math people
> recomputes. We're not in that environment (luckily).
>
> In this case keeping it separate means the desktop remains reachable
> through network but virtual graphics card, virtual mouse and stuff
> crashed, if somebody uses qlx that means the VM has to be rebooted
> anyway.

If Spice can crash a guest, that indicates to me that Spice is 
maintaining guest visible state.  That is difficult architecturally 
because if we want to do something like introduce a secure sandbox for 
running guest visible emulation, libspice would have to be part of that 
sandbox which would seem to be difficult.

The VNC server cannot crash a guest by comparison.

FWIW, I don't see any reason why Spice couldn't be made to be separate 
from guest emulation.  I think it would just require the right 
interfacing in qemu.  I think that's purely an implementation detail.

Regards,

Anthony Liguori

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

[Izik Eidus]

On Sat, 12 Dec 2009 11:40:21 -0600
Anthony Liguori <anthony@codemonkey.ws> wrote:

> FWIW, I don't see any reason why Spice couldn't be made to be
> separate from guest emulation.  I think it would just require the
> right interfacing in qemu.  I think that's purely an implementation
> detail.

The QXL device is one of the core compoments of spice..., how can you
separate it from the guest visible state? (it is pci device)

> 
> Regards,
> 
> Anthony Liguori
> 
> 

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

[Anthony Liguori]

Izik Eidus wrote:
> On Sat, 12 Dec 2009 11:40:21 -0600
> Anthony Liguori <anthony@codemonkey.ws> wrote:
>
>   
>> FWIW, I don't see any reason why Spice couldn't be made to be
>> separate from guest emulation.  I think it would just require the
>> right interfacing in qemu.  I think that's purely an implementation
>> detail.
>>     
>
> The QXL device is one of the core compoments of spice..., how can you
> separate it from the guest visible state? (it is pci device)
>   

How does live migration work then?  Do you have to query libspice for 
it's state?  Does it return an opaque blob?  How can it integrate with 
VMState since libspice doesn't have any knowledge of something like VMState?

Regards,

Anthony Liguori

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

[Izik Eidus]

On Sat, 12 Dec 2009 13:26:30 -0600
Anthony Liguori <anthony@codemonkey.ws> wrote:

> Izik Eidus wrote:
> > On Sat, 12 Dec 2009 11:40:21 -0600
> > Anthony Liguori <anthony@codemonkey.ws> wrote:
> >
> >   
> >> FWIW, I don't see any reason why Spice couldn't be made to be
> >> separate from guest emulation.  I think it would just require the
> >> right interfacing in qemu.  I think that's purely an implementation
> >> detail.
> >>     
> >
> > The QXL device is one of the core compoments of spice..., how can
> > you separate it from the guest visible state? (it is pci device)
> >   
> 
> How does live migration work then?  Do you have to query libspice for 
> it's state?  Does it return an opaque blob?  How can it integrate
> with VMState since libspice doesn't have any knowledge of something
> like VMState?

QXL transfer the device states by itself using qemu migration
mechanisem.

The spice server just need that the pci memory (and the qxl ram/rom
state) will be migrate. (From the point of view of guest visible state)

All this guest visible states are transfered by the qxl device using
qemu.

> 
> Regards,
> 
> Anthony Liguori
> 

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

[Dor Laor]

On 12/12/2009 09:48 PM, Izik Eidus wrote:
> On Sat, 12 Dec 2009 13:26:30 -0600
> Anthony Liguori<anthony@codemonkey.ws>  wrote:
>
>> Izik Eidus wrote:
>>> On Sat, 12 Dec 2009 11:40:21 -0600
>>> Anthony Liguori<anthony@codemonkey.ws>  wrote:
>>>
>>>
>>>> FWIW, I don't see any reason why Spice couldn't be made to be
>>>> separate from guest emulation.  I think it would just require the
>>>> right interfacing in qemu.  I think that's purely an implementation
>>>> detail.
>>>>
>>>
>>> The QXL device is one of the core compoments of spice..., how can
>>> you separate it from the guest visible state? (it is pci device)
>>>
>>
>> How does live migration work then?  Do you have to query libspice for
>> it's state?  Does it return an opaque blob?  How can it integrate
>> with VMState since libspice doesn't have any knowledge of something
>> like VMState?
>
> QXL transfer the device states by itself using qemu migration
> mechanisem.
>
> The spice server just need that the pci memory (and the qxl ram/rom
> state) will be migrate. (From the point of view of guest visible state)
>
> All this guest visible states are transfered by the qxl device using
> qemu.

In addition, the src spice server notifies the client on the migration 
execution and at the end of the migration it commands it to switch to 
the destination. It even passes a one time password session key.

Does vnc has that?

If you're interested of having a basic vnc mode, it will be much more 
easier, cleaner and faster to do the opposite, like Mark suggested -
Add a basic vnc mode to spice.
That said, it shouldn't be a merge criteria, let's start with qxl and 
vdi, and than the spice library.

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

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

[Dor Laor]

On 12/12/2009 07:40 PM, Anthony Liguori wrote:
> If Spice can crash a guest, that indicates to me that Spice is
> maintaining guest visible state.  That is difficult architecturally
> because if we want to do something like introduce a secure sandbox for
> running guest visible emulation, libspice would have to be part of that
> sandbox which would seem to be difficult.
>
> The VNC server cannot crash a guest by comparison.

That's not accurate:
https://bugzilla.redhat.com/show_bug.cgi?id=505641 -  (CVE-2009-3616) 
CVE-2009-3616 Remote VNC client can cause any QEMU VNC server to crash 
with a double-free

and again: https://bugzilla.redhat.com/show_bug.cgi?id=495646  -  Get 
segfault when changing vnc password


Why vnc server code should be protected and spice server not?
In addition, like Izik said, the qxl device/driver pair is a must. QXL 
is a great addition even in 'old' vnc mode since it supports lots of 
goodies. In addition for caching it also allows s3 state (qxl d3) for 
the OS, unlike Cirrus.

More VNC bugs that we run into:

https://bugzilla.redhat.com/show_bug.cgi?id=507880 -  qemu hangs during 
VNC connection from RHEVM
https://bugzilla.redhat.com/show_bug.cgi?id=490344 -  QEMU: Cannot VNC 
to a VM if a VNC is already opened to it
https://bugzilla.redhat.com/show_bug.cgi?id=497524 -  QEMU: Early BIOS 
error message cannot be seen after reboot in VNC
https://bugzilla.redhat.com/show_bug.cgi?id=501263 -  KVM: VNC screen is 
sometimes corrupted (at boot?)


If we'll break spice to components we have the following (and I'm not a 
spice expert):
1. QXL device/driver pair
    Is anyone debate we should have it in qemu?
    We should attach it SDL and vnc backend too anyway.
2. VDI (Virtual Desktop Interface)
    http://www.spice-space.org/vdi.html
    It's an abstraction layer for graphics/keyboard/mouse/sound
    /usb/serial.
    We need it anyway regardless of spice. What is our user like to
    switch from vnc to SDL on runtime? It's good for usb-over-ip for
    remoting, for various mouse modes, etc.
3. Spice server
    Shared library, in the same address space of qemu (like vnc server).
    Very sophisticated peace of code.
4. Spice client - independent.

So #1 shouldn't run into any opposition.
We can discuss why #2 is good, the layering separation between 
guest/host seems good idea to me.
As for #3, this is a library. If we have #2, one can even use a separate 
address space for sanity reasons. From my experience with spice (through 
all Red Hat QA), 99.9% of failures originated in qemu..

HTH,
Dor


>
> FWIW, I don't see any reason why Spice couldn't be made to be separate
> from guest emulation.  I think it would just require the right
> interfacing in qemu.  I think that's purely an implementation detail.
>
> Regards,
>
> Anthony Liguori

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

[Anthony Liguori]

Dor Laor wrote:
> On 12/12/2009 07:40 PM, Anthony Liguori wrote:
>> If Spice can crash a guest, that indicates to me that Spice is
>> maintaining guest visible state.  That is difficult architecturally
>> because if we want to do something like introduce a secure sandbox for
>> running guest visible emulation, libspice would have to be part of that
>> sandbox which would seem to be difficult.
>>
>> The VNC server cannot crash a guest by comparison.
>
> That's not accurate:

Cannot crash the *guest*.  It can crash qemu but it's not guest 
visible.  IOW, the guest never interacts directly with the VNC server.  
The difference matters when it comes to security sandboxing and live 
migration.

> If we'll break spice to components we have the following (and I'm not 
> a spice expert):
> 1. QXL device/driver pair
>    Is anyone debate we should have it in qemu?
>    We should attach it SDL and vnc backend too anyway.
> 2. VDI (Virtual Desktop Interface)
>    http://www.spice-space.org/vdi.html

FYI, www.spice-space.org is not responding for me.

>    It's an abstraction layer for graphics/keyboard/mouse/sound
>    /usb/serial.
>    We need it anyway regardless of spice. What is our user like to
>    switch from vnc to SDL on runtime? It's good for usb-over-ip for
>    remoting, for various mouse modes, etc.
> 3. Spice server
>    Shared library, in the same address space of qemu (like vnc server).
>    Very sophisticated peace of code.

The bit I've been trying to understand is whether the Spice server 
interacts directly with a guest or not.  I assume I'd be able to gather 
that from the VDI interfaces but the server's been down since this morning.

> So #1 shouldn't run into any opposition.
> We can discuss why #2 is good, the layering separation between 
> guest/host seems good idea to me.
> As for #3, this is a library. If we have #2, one can even use a 
> separate address space for sanity reasons. From my experience with 
> spice (through all Red Hat QA), 99.9% of failures originated in qemu..

Where #3 lives is purely a function of what level of integration it 
needs with qemu.  There may be advantages to having it external to 
qemu.  I actually think we should move the VNC server out of qemu...

Dan Berrange and I have been talking about being able to move VNC server 
into a central process such that all of the VMs can have a single VNC 
port that can be connected to.  This greatly simplifies the firewalling 
logic that an administrator has to deal with.   That's a problem I've 
already had to deal with for our management tools.  We use a private 
network for management and we bridge the VNC traffic into the customers 
network so they can see the VGA session.  But since that traffic can be 
a large range of ports and we have to tunnel the traffic through a 
central server to get into the customer network, it's very difficult to 
setup without opening up a mess of ports.  I think we're currently 
opening a few thousand just for VNC.

For VNC, to make this efficient we just need a shared memory transport 
that we can use locally.  I doubt the added latency will matter as long 
as we're not copying data.

Of course, Spice is a different thing altogether.  I have no idea 
whether it makes sense for Spice like it would for VNC.  But I'd like to 
understand if the option is available.

Regards,

Anthony Liguori

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

[Daniel P. Berrange]

On Sat, Dec 12, 2009 at 05:46:08PM -0600, Anthony Liguori wrote:
> Dor Laor wrote:
> >On 12/12/2009 07:40 PM, Anthony Liguori wrote:
> >>If Spice can crash a guest, that indicates to me that Spice is
> >>maintaining guest visible state.  That is difficult architecturally
> >>because if we want to do something like introduce a secure sandbox for
> >>running guest visible emulation, libspice would have to be part of that
> >>sandbox which would seem to be difficult.
> >>
> >>The VNC server cannot crash a guest by comparison.
> >
> >That's not accurate:
> 
> Cannot crash the *guest*.  It can crash qemu but it's not guest 
> visible.  IOW, the guest never interacts directly with the VNC server.  
> The difference matters when it comes to security sandboxing and live 
> migration.
> 
> >If we'll break spice to components we have the following (and I'm not 
> >a spice expert):
> >1. QXL device/driver pair
> >   Is anyone debate we should have it in qemu?
> >   We should attach it SDL and vnc backend too anyway.
> >2. VDI (Virtual Desktop Interface)
> >   http://www.spice-space.org/vdi.html
> 
> FYI, www.spice-space.org is not responding for me.

There is a planned outage for a physical relocation of the server that
hosts spice-space.org, virt-manager.org, ovirt.org, etc & a lot of other
sites. It should be back online before Monday if all has gone to plan.

> Where #3 lives is purely a function of what level of integration it 
> needs with qemu.  There may be advantages to having it external to 
> qemu.  I actually think we should move the VNC server out of qemu...
> 
> Dan Berrange and I have been talking about being able to move VNC server 
> into a central process such that all of the VMs can have a single VNC 
> port that can be connected to.  This greatly simplifies the firewalling 
> logic that an administrator has to deal with.   That's a problem I've 
> already had to deal with for our management tools.  We use a private 
> network for management and we bridge the VNC traffic into the customers 
> network so they can see the VGA session.  But since that traffic can be 
> a large range of ports and we have to tunnel the traffic through a 
> central server to get into the customer network, it's very difficult to 
> setup without opening up a mess of ports.  I think we're currently 
> opening a few thousand just for VNC.

Actually my plan was to have a VNC proxy server, that sat between the
end user & the real VNC in QEMU. Specifically I wanted to allow for a
model where the VNC server end users connected to for console servers
was on a physically separate host from the VMs. I had a handful of
use cases, mostly to deal with an oVirt deployment where console users
could be from the internet, rather than an intranet.

 - Avoiding the need to open up many ports on firewalls
 - Allow on the fly switching between any VMs the currently authenticated
   user was authorized to view without opening more connections (avoids
   needing to re-authenticate for each VM)
 - Avoid needing to expose virtualization hosts to console users,
   since console users may be coming in from an untrusted network, or
   even the internet itself.
 - Allow seemless migration where proxy server simply re-connects to
   the VM on new host, without the end user VNC connection ever noticing.

> For VNC, to make this efficient we just need a shared memory transport 
> that we can use locally.  I doubt the added latency will matter as long 
> as we're not copying data.

That would preclude running it as an off-node service, but since latency
is important that's probably inevitable. In any case there'd be nothing 
to stop someone adding an off-node proxy in front of that anyway should
requirements truely require it. The first point of just getting away from
the one-TCP port per VM model is a worthwhile use case all of its own.

> Of course, Spice is a different thing altogether.  I have no idea 
> whether it makes sense for Spice like it would for VNC.  But I'd like to 
> understand if the option is available.

I believe Spice shares the same needs as VNC in this regard, since when
spawning a VM with Spice, each must be given a pair of unique ports (one
runs cleartext, one with TLS/SSL). 

Regards,
Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

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

[Avi Kivity]

On 12/13/2009 01:46 AM, Anthony Liguori wrote:
>
> Dan Berrange and I have been talking about being able to move VNC 
> server into a central process such that all of the VMs can have a 
> single VNC port that can be connected to.  This greatly simplifies the 
> firewalling logic that an administrator has to deal with.   That's a 
> problem I've already had to deal with for our management tools.  We 
> use a private network for management and we bridge the VNC traffic 
> into the customers network so they can see the VGA session.  But since 
> that traffic can be a large range of ports and we have to tunnel the 
> traffic through a central server to get into the customer network, 
> it's very difficult to setup without opening up a mess of ports.  I 
> think we're currently opening a few thousand just for VNC.

Seems to me the best way to handle this is to run an accept() in a 
server and hand the resulting fd to the vnc server in qemu using ... 
wait for it ... SCM_RIGHTS.

I'm just happy every time someone lobs a question into the air that can 
be answered using SCM_RIGHTS.

-- 
error compiling committee.c: too many arguments to function

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

[Anthony Liguori]

Avi Kivity wrote:
> On 12/13/2009 01:46 AM, Anthony Liguori wrote:
>>
>> Dan Berrange and I have been talking about being able to move VNC 
>> server into a central process such that all of the VMs can have a 
>> single VNC port that can be connected to.  This greatly simplifies 
>> the firewalling logic that an administrator has to deal with.   
>> That's a problem I've already had to deal with for our management 
>> tools.  We use a private network for management and we bridge the VNC 
>> traffic into the customers network so they can see the VGA session.  
>> But since that traffic can be a large range of ports and we have to 
>> tunnel the traffic through a central server to get into the customer 
>> network, it's very difficult to setup without opening up a mess of 
>> ports.  I think we're currently opening a few thousand just for VNC.
>
> Seems to me the best way to handle this is to run an accept() in a 
> server and hand the resulting fd to the vnc server in qemu using ... 
> wait for it ... SCM_RIGHTS.
>
> I'm just happy every time someone lobs a question into the air that 
> can be answered using SCM_RIGHTS.

That's actually a great idea made even better by the use of SCM_RIGHTS :-)

I think it's a bit trickier though because ideally you would want to use 
the vnc protocol to negotiate which vm you're connecting to.  That 
implies that you actually need to hand over the fd in a setup state.  
It's complicated by any encryption protocol too.

Regards,

Anthony Liguori

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

[Avi Kivity]

On 12/14/2009 04:42 PM, Anthony Liguori wrote:
> I think it's a bit trickier though because ideally you would want to 
> use the vnc protocol to negotiate which vm you're connecting to. 

Right, of  course.  If the client can no longer choose the target using 
its port number, it has to select it in some other way.

> That implies that you actually need to hand over the fd in a setup 
> state.  It's complicated by any encryption protocol too.

Yes - need to pass the encryption state.  Hopefully the crypto stacks 
support this.

-- 
error compiling committee.c: too many arguments to function

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

[Daniel P. Berrange]

On Mon, Dec 14, 2009 at 04:53:07PM +0200, Avi Kivity wrote:
> On 12/14/2009 04:42 PM, Anthony Liguori wrote:
> >I think it's a bit trickier though because ideally you would want to 
> >use the vnc protocol to negotiate which vm you're connecting to. 
> 
> Right, of  course.  If the client can no longer choose the target using 
> its port number, it has to select it in some other way.
> 
> >That implies that you actually need to hand over the fd in a setup 
> >state.  It's complicated by any encryption protocol too.
> 
> Yes - need to pass the encryption state.  Hopefully the crypto stacks 
> support this.

There's no mechanism for this in the SASL libraries. With GNUTLS there is
the ability to preserve negotiated session state from one TLS conenection
and used it upon opening the next connection to fast-track the handshake
phase. This doesn't allow you to pass the state for an existing connection
to a new process though and have it carry on

Regards,
Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

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

[Avi Kivity]

On 12/14/2009 05:17 PM, Daniel P. Berrange wrote:
>
>> Yes - need to pass the encryption state.  Hopefully the crypto stacks
>> support this.
>>      
> There's no mechanism for this in the SASL libraries. With GNUTLS there is
> the ability to preserve negotiated session state from one TLS conenection
> and used it upon opening the next connection to fast-track the handshake
> phase. This doesn't allow you to pass the state for an existing connection
> to a new process though and have it carry on
>    

This sucks.  But we can ask the client to reauthenticate.

-- 
error compiling committee.c: too many arguments to function

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

[Anthony Liguori]

Avi Kivity wrote:
> On 12/14/2009 05:17 PM, Daniel P. Berrange wrote:
>>
>>> Yes - need to pass the encryption state.  Hopefully the crypto stacks
>>> support this.
>>>      
>> There's no mechanism for this in the SASL libraries. With GNUTLS 
>> there is
>> the ability to preserve negotiated session state from one TLS 
>> conenection
>> and used it upon opening the next connection to fast-track the handshake
>> phase. This doesn't allow you to pass the state for an existing 
>> connection
>> to a new process though and have it carry on
>>    
>
> This sucks.  But we can ask the client to reauthenticate.

Or instead of passing the socket file descriptor, pass over a socketpair 
and encrypt the traffic in the server.  The encryption requires no 
knowledge of the protocol so it can be done easily enough in the server.

You're already paying the cost for copying the data.  Adding in one copy 
shouldn't be the end of the world.

Regards,

Anthony Liguori

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

[Daniel P. Berrange]

On Mon, Dec 14, 2009 at 08:42:12AM -0600, Anthony Liguori wrote:
> Avi Kivity wrote:
> >On 12/13/2009 01:46 AM, Anthony Liguori wrote:
> >>
> >>Dan Berrange and I have been talking about being able to move VNC 
> >>server into a central process such that all of the VMs can have a 
> >>single VNC port that can be connected to.  This greatly simplifies 
> >>the firewalling logic that an administrator has to deal with.   
> >>That's a problem I've already had to deal with for our management 
> >>tools.  We use a private network for management and we bridge the VNC 
> >>traffic into the customers network so they can see the VGA session.  
> >>But since that traffic can be a large range of ports and we have to 
> >>tunnel the traffic through a central server to get into the customer 
> >>network, it's very difficult to setup without opening up a mess of 
> >>ports.  I think we're currently opening a few thousand just for VNC.
> >
> >Seems to me the best way to handle this is to run an accept() in a 
> >server and hand the resulting fd to the vnc server in qemu using ... 
> >wait for it ... SCM_RIGHTS.
> >
> >I'm just happy every time someone lobs a question into the air that 
> >can be answered using SCM_RIGHTS.
> 
> That's actually a great idea made even better by the use of SCM_RIGHTS :-)
> 
> I think it's a bit trickier though because ideally you would want to use 
> the vnc protocol to negotiate which vm you're connecting to.  That 
> implies that you actually need to hand over the fd in a setup state.  
> It's complicated by any encryption protocol too.

The model I had in mind was for the proxy to define a VNC extension that
allows the client to query what 'desktops' are available and request
switching between them at any time. The list of desktop would of course
be authorized per client, and strong authentication is a must for this.

Any time a switch was made, the RFB protocol would return to the 
'ServerInit' state. The idea is that you should not assume a homogenous 
environment, and you really don't want to fall down to the lowest common
denominator of extensions, nor have the proxy doing re-encoding on the FB
data updates. Returning to the ServerInit state allowing the client to
re-negotiate the set of encodings for the new desktop, and so the proxy 
can be fairly stateless and while needing to understand the wire protocol,
it can just pass through the actual FB update data unchanged.

The combo of the an extension for switching desktops on the fly and the
encryption state problem doesn't really seem to fit with passing the VNC
FD over with SCM_RIGHTS.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

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

[Anthony Liguori]

Daniel P. Berrange wrote:
> On Mon, Dec 14, 2009 at 08:42:12AM -0600, Anthony Liguori wrote:
>   
>> Avi Kivity wrote:
>>     
>>> On 12/13/2009 01:46 AM, Anthony Liguori wrote:
>>>       
>>>> Dan Berrange and I have been talking about being able to move VNC 
>>>> server into a central process such that all of the VMs can have a 
>>>> single VNC port that can be connected to.  This greatly simplifies 
>>>> the firewalling logic that an administrator has to deal with.   
>>>> That's a problem I've already had to deal with for our management 
>>>> tools.  We use a private network for management and we bridge the VNC 
>>>> traffic into the customers network so they can see the VGA session.  
>>>> But since that traffic can be a large range of ports and we have to 
>>>> tunnel the traffic through a central server to get into the customer 
>>>> network, it's very difficult to setup without opening up a mess of 
>>>> ports.  I think we're currently opening a few thousand just for VNC.
>>>>         
>>> Seems to me the best way to handle this is to run an accept() in a 
>>> server and hand the resulting fd to the vnc server in qemu using ... 
>>> wait for it ... SCM_RIGHTS.
>>>
>>> I'm just happy every time someone lobs a question into the air that 
>>> can be answered using SCM_RIGHTS.
>>>       
>> That's actually a great idea made even better by the use of SCM_RIGHTS :-)
>>
>> I think it's a bit trickier though because ideally you would want to use 
>> the vnc protocol to negotiate which vm you're connecting to.  That 
>> implies that you actually need to hand over the fd in a setup state.  
>> It's complicated by any encryption protocol too.
>>     
>
> The model I had in mind was for the proxy to define a VNC extension that
> allows the client to query what 'desktops' are available and request
> switching between them at any time. The list of desktop would of course
> be authorized per client, and strong authentication is a must for this.
>
> Any time a switch was made, the RFB protocol would return to the 
> 'ServerInit' state.

I was thinking about it a bit differently.  I was envisioning the switch 
to be a one time thing as opposed to being able to switch back and forth.

A management app can see multiple guests by connecting repeatedly to the 
same port.  They can implement switching in the client which allows for 
clever things like caching state of multiple clients while not sending 
updates for clients that aren't actively displayed.

Regards,

Anthony Liguori

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

[Avi Kivity]

On 12/14/2009 05:10 PM, Daniel P. Berrange wrote:
>
> The model I had in mind was for the proxy to define a VNC extension that
> allows the client to query what 'desktops' are available and request
> switching between them at any time. The list of desktop would of course
> be authorized per client, and strong authentication is a must for this.
>
> Any time a switch was made, the RFB protocol would return to the
> 'ServerInit' state. The idea is that you should not assume a homogenous
> environment, and you really don't want to fall down to the lowest common
> denominator of extensions, nor have the proxy doing re-encoding on the FB
> data updates. Returning to the ServerInit state allowing the client to
> re-negotiate the set of encodings for the new desktop, and so the proxy
> can be fairly stateless and while needing to understand the wire protocol,
> it can just pass through the actual FB update data unchanged.
>
> The combo of the an extension for switching desktops on the fly and the
> encryption state problem doesn't really seem to fit with passing the VNC
> FD over with SCM_RIGHTS.
>    

You can still implement this with SCM_RIGHTS.  Authenticate, select 
guest, drop tls, pass fd to qemu, authenticate, hack hack hack, drop 
tls, pass fd back to proxy, goto 10.

-- 
error compiling committee.c: too many arguments to function

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

[Anthony Liguori]

Avi Kivity wrote:
> You can still implement this with SCM_RIGHTS.  Authenticate, select 
> guest, drop tls, pass fd to qemu, authenticate, hack hack hack, drop 
> tls, pass fd back to proxy, goto 10.

Here's how I'd envision this working.

Start qemu with:

qemu -vnc proxy:/path/to/unix/domain/socket

We connect to /path/to/unix/domain/socket and wait to recv file 
descriptors after telling the server it's name and what protocol version 
it supports.  We treat each received file descriptor as a new 
connection.  We use do full protocol with no specific authentication.

The server runs and opens /path/to/unix/domain/socket.  Whenever a 
client connects to the server socket, it does protocol negotiation using 
the least common denominator of protocol versions given it.  We use a 
protocol extension to list and negotiate which client to connect to.  
Once that's been established, we send a socketpair() over the 
appropriate domain socket, and do appropriate negotiation to get us up 
to the ServerInit stage.  We use a combination of DesktopResize and WMVi 
in the server to get the client at the appropriate state to match the 
ServerInit.

We then (in the server) blindly proxy any data from the qemu instance to 
the client (encrypting it if necessary).

We won't need to reencode any traffic in this model and it's pretty 
reasonable from a UI perspective.  In fact, if we use a helper, we can 
probably have an even better command line for qemu.

Regards,

Anthony Liguori

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

[Mark McLoughlin]

On Mon, 2009-12-14 at 15:10 +0000, Daniel P. Berrange wrote:

> The model I had in mind was for the proxy to define a VNC extension that
> allows the client to query what 'desktops' are available and request
> switching between them at any time. The list of desktop would of course
> be authorized per client, and strong authentication is a must for this.
> 
> Any time a switch was made, the RFB protocol would return to the 
> 'ServerInit' state. The idea is that you should not assume a homogenous 
> environment, and you really don't want to fall down to the lowest common
> denominator of extensions, nor have the proxy doing re-encoding on the FB
> data updates. Returning to the ServerInit state allowing the client to
> re-negotiate the set of encodings for the new desktop, and so the proxy 
> can be fairly stateless and while needing to understand the wire protocol,
> it can just pass through the actual FB update data unchanged.
> 
> The combo of the an extension for switching desktops on the fly and the
> encryption state problem doesn't really seem to fit with passing the VNC
> FD over with SCM_RIGHTS.

I actually did a demo of this before, in a slightly different context.

The idea was:

  - vnc client connects to gdm, which spawned a Xvnc(A) server with a
    gdm auth dialog

  - user logs in and if you've an Xvnc server already, it would move 
    the client connection to the original Xvnc(B) server

  - first, gdm would tell the (A) to sync it's state; (A) would stop 
    sending updates, flush its zlib/tls streams and pass gdm the
    current state of the connection - e.g. the protocol version, pixel 
    format, supported encodings etc.

  - then gdm would pass the connection fd using SCM_RIGHTS to the 
    existing Xvnc along with the connection state, and (B) would pick
    up the connection

  - from the users point of view, they were logged instantly back into 
    their old session

Simply flushing the encryption/compression state was the key, but AFAIR
clients needed a trivial fix to allow them to properly handle the server
flushing the stream. The alternative was to somehow get the server to
dump its encryption/compression state and pass that to the existing
server, but that seemed quite difficult when I looked.

SCM_RIGHTS rule ... this was definitely one of the most fun hacks I've
done :-)

Cheers,
Mark.

p.s. - I'm sure I can dig up the code, here are some diffs that look
like older than what I remember finishing:

  http://www.gnome.org/~markmc/code/gdm-vnc-support.patch
  http://www.gnome.org/~markmc/code/test-gnutls-client-close-restart.c
  http://www.gnome.org/~markmc/code/test-gnutls-server-close-restart.c
  http://www.gnome.org/~markmc/code/test-zlib.c
  http://www.gnome.org/~markmc/code/vnc-4.0b5-vncviewer-tls.diff
  http://www.gnome.org/~markmc/code/vnc-managed.patch
  http://www.gnome.org/~markmc/code/vnc-tls.patch

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

[Gildas Le Nadan]

>> Dan Berrange and I have been talking about being able to move VNC
>> server into a central process such that all of the VMs can have a
>> single VNC port that can be connected to.  This greatly simplifies
>> the firewalling logic that an administrator has to deal with.
>> That's a problem I've already had to deal with for our management
>> tools.  We use a private network for management and we bridge the
>> VNC traffic into the customers network so they can see the VGA
>> session.  But since that traffic can be a large range of ports and
>> we have to tunnel the traffic through a central server to get into
>> the customer network, it's very difficult to setup without opening
>> up a mess of ports.  I think we're currently opening a few thousand
>> just for VNC.
> 
> Actually my plan was to have a VNC proxy server, that sat between the
>  end user & the real VNC in QEMU. Specifically I wanted to allow for
> a model where the VNC server end users connected to for console
> servers was on a physically separate host from the VMs. I had a
> handful of use cases, mostly to deal with an oVirt deployment where
> console users could be from the internet, rather than an intranet.
> 
> - Avoiding the need to open up many ports on firewalls - Allow on the
> fly switching between any VMs the currently authenticated user was
> authorized to view without opening more connections (avoids needing
> to re-authenticate for each VM) - Avoid needing to expose
> virtualization hosts to console users, since console users may be
> coming in from an untrusted network, or even the internet itself. -
> Allow seemless migration where proxy server simply re-connects to the
> VM on new host, without the end user VNC connection ever noticing.

Hi,

Having a single well known port to connect to the VMs on an host would
be *awesome* as having one port per VM is sooo 1980's in terms of
manageability/secureability.

Actually both use cases described above are needed IMO:

- it would be great to have some sort of server running locally on the 
VM host so that you only have one open port on the VM host itself [1].

- it would be very usefull to have some sort of proxy mechanism that 
would allow redirection from a single host acting as a gateway between 
networks (be it internal or external networks).

The two of them could interact nicely with one connecting to the other 
if needed:

_______VM_Host________    _proxy_Host_     _client_machine_
|    1               | 2  |          |  3  |              |
|VM <-> local server |<-> |   proxy  | <-> |  client      |
|____________________|    |__________|     |______________|

I think one of the most important thing is that the proxy and the local 
server must behave exactly the same way and provide the same features 
(that is the protocol used on connection 2 should be the same as the one 
for connection 3).

This allow the client to work the same independently of the 
configuration/topology. The proxy allows for enterprise class features 
whereas the local server is enough for a small virtual infrastructure or 
even a single machine setup, but that should be transparent to the clients.

I guess there must exist a way to route the connection to the correct 
VM, so there should be something similar to the HTTP Host request-header 
to identify the VM the client wants to connect to [2].

Of course SASL support is mandatory but I guess Dan planned it anyway :)

Ideally there would be some sort of negociation mechanism so the client 
can ask what protocol (vnc, spice, ...) they want to use (if possible 
dynamically within a session if a user change its location/if its need 
evolve).

Obviously both shouldn't need to be run as root.

I guess the proxy should be a project on his own and not part of qemu 
since it is more of an enterprise feature while the local server could 
be added to qemu? Of course since there are some common features, it 
would probably make sense to share some code.

Concerning the proxy, there are all sorts of goodies I would expect from 
it (on top of seamless migration and on-the-fly switching) :
- flexibility in the choice of the authorization backend
- since it is a SPOF, it would be nice for it to work as a cluster (in 
active/passive with failover or better as an active/active cluster)

Since this proxy can be used as a connection broker to either physical 
or virtual machines, load-balancing and session management features 
would be nice.

Of course in a perfect world this wouldn't be a single company project ;)

My humble 2 cents as an operations person,
Gildas

-- 
[1] firewalling is also important on internal networks if you work in a 
large environment, and having a single port makes it easier to 
understand what is going on when diagnosing issues.

[2] You also need to point to the correct host. How you want to 
"publish" the VM/VM Host association so the proxy can route is an 
interesting problem on its own, especially since VM can (and will) 
migrate. There are probably many ways to do this including DNS SRV, 
LDAP, local DB, and having flexibility for this in the proxy is a bonus.

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

[Gerd Hoffmann]

On 12/12/09 23:35, Dor Laor wrote:
> 2. VDI (Virtual Desktop Interface)
> http://www.spice-space.org/vdi.html
> It's an abstraction layer for graphics/keyboard/mouse/sound
> /usb/serial.
> We need it anyway regardless of spice. What is our user like to
> switch from vnc to SDL on runtime? It's good for usb-over-ip for
> remoting, for various mouse modes, etc.

What does spice need which isn't present in qemu today?

You can start qemu with both sdl and vnc enabled.  Graphic output is 
sent to both.  Keyboard and mouse input is accepted from both.  Sound 
via vnc works too.

What doesn't work: usb + chardevs (i.e. serial console), so we need some 
interface here.  For graphics spice probably needs a different interface 
than the existing for a stupid framebuffer with copyrect op.  I don't 
see a need for new keyboard/mouse/sound interfaces though.

cheers,
   Gerd

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

[Anthony Liguori]

Gerd Hoffmann wrote:
> On 12/12/09 23:35, Dor Laor wrote:
>> 2. VDI (Virtual Desktop Interface)
>> http://www.spice-space.org/vdi.html
>> It's an abstraction layer for graphics/keyboard/mouse/sound
>> /usb/serial.
>> We need it anyway regardless of spice. What is our user like to
>> switch from vnc to SDL on runtime? It's good for usb-over-ip for
>> remoting, for various mouse modes, etc.
>
> What does spice need which isn't present in qemu today?
>
> You can start qemu with both sdl and vnc enabled.  Graphic output is 
> sent to both.  Keyboard and mouse input is accepted from both.  Sound 
> via vnc works too.
>
> What doesn't work: usb + chardevs (i.e. serial console), so we need 
> some interface here.  For graphics spice probably needs a different 
> interface than the existing for a stupid framebuffer with copyrect 
> op.  I don't see a need for new keyboard/mouse/sound interfaces though.

(Looking at spice-space.org), VDI seems to be a whole lot more than just 
a graphics thing.  It looks a plugin interface for qemu as it 
incorporates things like fd registration, timer registration, etc.

I don't think it's really needed verses just integrating spice support 
directly.  I don't quite understand the relationship between spice and 
vdi though.  If libspice implements a VDI interface directly and that's 
what it expects people to write against verses vdi existing solely for 
interaction with qemu.  If the later is the case, then it's probably an 
unnecessary abstraction.  If the former is the case, then it's just the 
api we have to live with.

Of course, you could use something like VDI to separate out the vnc 
server into a more well defined module.  However, I'd suggest separating 
that modularity effort from the integration of spice.  Either do that 
starting with the vnc server, then add spice, or add spice with tight 
integration, and then build a common interface.

The later is probably better since it gives you more clear requirements 
for the interface.

Regards,

Anthony Liguori

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

[Andrea Arcangeli]

On Sat, Dec 12, 2009 at 11:40:21AM -0600, Anthony Liguori wrote:
> If Spice can crash a guest, that indicates to me that Spice is 

That's not what I meant, anything in qemu address space can crash a
guest not just spice, even qcow2 could crash a guest, you just need to
*vaddr_in_guest_physical_space = 0 through a corrupted pointer
(corrupted pointers are very rare, gcc is very pedantic, there are
tools to trap those but they historically happened a few times in the
kernel), but when I said it I didn't in mind crashing just the guest,
I meant corrupting qemu memory itself through a different corrupted
vaddr, but it is the same risk, you could flip a bit in a buffer
header holding ext4 metadata in the guest physical address space or
flip a bit in qcow2 cluster bitmap, it doesn't make a difference both
could result in fs corruption in an extremely unlikely scenario (and
that extremely unlikely scenario is the only one where the microkernel
design would eventually payoff, where you get the graphics and mouse
hosed, but the guest sill is reachable through the network). I simply
meant spice should live in the same address space where the other
virtio drivers are living for the same reasons (performance), it's no
different. Izik already answered the other part.

Thanks,
Andrea

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

[Anthony Liguori]

Andrea Arcangeli wrote:
> On Sat, Dec 12, 2009 at 11:40:21AM -0600, Anthony Liguori wrote:
>   
>> If Spice can crash a guest, that indicates to me that Spice is 
>>     
>
> That's not what I meant, anything in qemu address space can crash a
> guest not just spice, even qcow2 could crash a guest, you just need to
> *vaddr_in_guest_physical_space = 0 through a corrupted pointer
> (corrupted pointers are very rare, gcc is very pedantic, there are
> tools to trap those but they historically happened a few times in the
> kernel), but when I said it I didn't in mind crashing just the guest,
> I meant corrupting qemu memory itself through a different corrupted
> vaddr, but it is the same risk, you could flip a bit in a buffer
> header holding ext4 metadata in the guest physical address space or
> flip a bit in qcow2 cluster bitmap, it doesn't make a difference both
> could result in fs corruption in an extremely unlikely scenario (and
> that extremely unlikely scenario is the only one where the microkernel
> design would eventually payoff, where you get the graphics and mouse
> hosed, but the guest sill is reachable through the network). I simply
> meant spice should live in the same address space where the other
> virtio drivers are living for the same reasons (performance), it's no
> different.

This is the bit that confuses me.  VNC is not a driver.  When I say it 
cannot crash the guest, I mean that if the VNC server makes a mistake, 
there may be a SEGV in qemu or it may just result in a VNC client seeing 
corruption.  The guest does not see a bad VGA register content though or 
something like that.  VNC is a host driver or backend service or 
whatever you want to call it.  VNC does not have migration state because 
it has no guest visible state.

When you compare Spice to a virtio driver, that implies to me that it 
does interact directly with the guest.  In fact, when you have a driver 
passing high level commands to Spice, you would think that the status of 
these commands would be pending state, no?

Let's say the guest sends a fill rectangle command and the Spice server 
sends that to a client.  The Spice server needs to know when the client 
has finished that (maybe not, but let's assume it does) so there is now 
a pending request that someone has to keep track of.  If you do a savevm 
or a live migration, or the client disconnects, the state of that 
request has to be saved somewhere (unless you tell the guest that the 
client has disconnected which is how Xen handles pv device migration).

So that's what I'm trying to understand.  How far does the guest's 
visibility go?  Is the guest totally ignorant of anything other than 
QXL?  If so, that's good, and I'm very happy about it :-)

Regards,

Anthony Liguori

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

[Andrea Arcangeli]

On Sat, Dec 12, 2009 at 05:52:49PM -0600, Anthony Liguori wrote:
> This is the bit that confuses me.  VNC is not a driver.  When I say it 
> cannot crash the guest, I mean that if the VNC server makes a mistake, 
> there may be a SEGV in qemu or it may just result in a VNC client seeing 
> corruption.  The guest does not see a bad VGA register content though or 
> something like that.  VNC is a host driver or backend service or 
> whatever you want to call it.  VNC does not have migration state because 
> it has no guest visible state.

Again, a guest crash because of qlx interaction is not what I
mean. And the reason I wasn't even thinking about this scenario is
that the kind of paravirt-driver related guest crash you are talking
about, if it can happen, can happen even if spice lib in the qemu side
lives in a separate address space. This is why this case of pure guest
crash through qlx is not relevant to decide if to have spice lib
inside our outside of qemu address space, I think that is more about
the qlx driver and not spice on the qemu side.

With regard to VNC, as long as VNC lives in the same address space
with the guest, it can just follow a dangling pointer and corrupt and
crash the guest too like libspice or qcow2 or anything else in that
address space could too, or worse silently corrupt guest fs metadata
and leave traces of fs corruption that could emerge months or years
after the bug was fixed. qlx and paravirt definitely not required for
this, VNC can do it too.

> When you compare Spice to a virtio driver, that implies to me that
> it does interact directly with the guest.  In fact, when you have a
> driver passing high level commands to Spice, you would think that
> the status of these commands would be pending state, no?  Let's say
> the guest sends a fill rectangle command and the Spice server sends
> that to a client.  The Spice server needs to know when the client
> has finished that (maybe not, but let's assume it does) so there is
> now a pending request that someone has to keep track of.  If you do
> a savevm or a live migration, or the client disconnects, the state
> of that request has to be saved somewhere (unless you tell the guest
> that the client has disconnected which is how Xen handles pv device
> migration).  So that's what I'm trying to understand.  How far does
> the guest's visibility go?  Is the guest totally ignorant of
> anything other than QXL?  If so, that's good, and I'm very happy
> about it :-) Regards, Anthony Liguori

I would expect it to be ignorant about anything but qlx (what else
does it need to know), but I never looked into spice before it was
open source so it's not like I'm the right person to ask for those
details ;).

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

[Anthony Liguori]

Andrea Arcangeli wrote:
> On Sat, Dec 12, 2009 at 05:52:49PM -0600, Anthony Liguori wrote:
>   
>> This is the bit that confuses me.  VNC is not a driver.  When I say it 
>> cannot crash the guest, I mean that if the VNC server makes a mistake, 
>> there may be a SEGV in qemu or it may just result in a VNC client seeing 
>> corruption.  The guest does not see a bad VGA register content though or 
>> something like that.  VNC is a host driver or backend service or 
>> whatever you want to call it.  VNC does not have migration state because 
>> it has no guest visible state.
>>     
>
> Again, a guest crash because of qlx interaction is not what I
> mean. And the reason I wasn't even thinking about this scenario is
> that the kind of paravirt-driver related guest crash you are talking
> about, if it can happen, can happen even if spice lib in the qemu side
> lives in a separate address space.

Yes, that's absolutely true.

>  This is why this case of pure guest
> crash through qlx is not relevant to decide if to have spice lib
> inside our outside of qemu address space, I think that is more about
> the qlx driver and not spice on the qemu side.
>   

The guest visible state thing has nothing to do with where it lives.  
Sorry if that's gotten mixed in with this discussion.

The reason I care about what interacts directly with the guest is that 
I'd like to see us move qemu to where there's a very strong separate 
between guest-visible interactions and then host services to the point 
where the portions of guest-visible code could be run in a highly secure 
environment.  If all of libspice would have to live in that environment 
because it interacts with a guest directly, that would get complicated.


>> When you compare Spice to a virtio driver, that implies to me that
>> it does interact directly with the guest.  In fact, when you have a
>> driver passing high level commands to Spice, you would think that
>> the status of these commands would be pending state, no?  Let's say
>> the guest sends a fill rectangle command and the Spice server sends
>> that to a client.  The Spice server needs to know when the client
>> has finished that (maybe not, but let's assume it does) so there is
>> now a pending request that someone has to keep track of.  If you do
>> a savevm or a live migration, or the client disconnects, the state
>> of that request has to be saved somewhere (unless you tell the guest
>> that the client has disconnected which is how Xen handles pv device
>> migration).  So that's what I'm trying to understand.  How far does
>> the guest's visibility go?  Is the guest totally ignorant of
>> anything other than QXL?  If so, that's good, and I'm very happy
>> about it :-) Regards, Anthony Liguori
>>     
>
> I would expect it to be ignorant about anything but qlx (what else
> does it need to know), but I never looked into spice before it was
> open source so it's not like I'm the right person to ask for those
> details ;).
>   
:-)

I'm really interested in those details.

Regards,

Anthony Liguori

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

[Izik Eidus]

On Sat, 12 Dec 2009 18:18:01 -0600
Anthony Liguori <anthony@codemonkey.ws> wrote:

> Andrea Arcangeli wrote:
> > On Sat, Dec 12, 2009 at 05:52:49PM -0600, Anthony Liguori wrote:
> >   
> >> This is the bit that confuses me.  VNC is not a driver.  When I
> >> say it cannot crash the guest, I mean that if the VNC server makes
> >> a mistake, there may be a SEGV in qemu or it may just result in a
> >> VNC client seeing corruption.  The guest does not see a bad VGA
> >> register content though or something like that.  VNC is a host
> >> driver or backend service or whatever you want to call it.  VNC
> >> does not have migration state because it has no guest visible
> >> state. 
> >
> > Again, a guest crash because of qlx interaction is not what I
> > mean. And the reason I wasn't even thinking about this scenario is
> > that the kind of paravirt-driver related guest crash you are talking
> > about, if it can happen, can happen even if spice lib in the qemu
> > side lives in a separate address space.
> 
> Yes, that's absolutely true.
> 
> >  This is why this case of pure guest
> > crash through qlx is not relevant to decide if to have spice lib
> > inside our outside of qemu address space, I think that is more about
> > the qlx driver and not spice on the qemu side.
> >   
> 
> The guest visible state thing has nothing to do with where it lives.  
> Sorry if that's gotten mixed in with this discussion.

The guest visible state is just the qxl device.
It is pci device..., and it migrate just like any other pci device
inside qemu...

What am I missing here?

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

[Soeren Sandmann]

Anthony Liguori <anthony@codemonkey.ws> writes:

> So that's what I'm trying to understand.  How far does the guest's
> visibility go?  Is the guest totally ignorant of anything other than
> QXL?  If so, that's good, and I'm very happy about it :-)

The guest only sees a QXL video device. This video device accepts
commands that it then turns into SPICE protocol.

It also maintains a data structure containing enough commands to
reproduce any part of the frame buffer. This means that if
applications do not read from the frame buffer - which they usually
don't - no rendering has to take place on the server side. [1]

Whenever a particular command is not needed anymore in this data
structure, the device will notify the driver that the memory
associated with it can now be reused. If the driver runs out of
memory, it can tell the device to store all of the framebuffer as one
big bitmap, in which case all of the stored commands become available
for reuse.


Soren


[1] The existing X driver does not make use of this functionality for
various reasons, the main one being that without offscreen pixmaps,
essentially all drawing to the frontbuffer would just be pixmaps
anyway.

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

[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

[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]

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

[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

[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