Re: [Qemu-devel] Spice project is now open
On Fri, 11 Dec 2009 17:07:13 -0200 Glauber Costa glom...@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
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
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
On Fri, 11 Dec 2009 22:26:59 +0200 Izik Eidus iei...@redhat.com wrote: On Fri, 11 Dec 2009 22:53:25 +0300 (MSK) malc av1...@comtv.ru wrote: On Fri, 11 Dec 2009, Izik Eidus wrote: On Fri, 11 Dec 2009 22:24:38 +0300 (MSK) malc av1...@comtv.ru wrote: On Fri, 11 Dec 2009, Izik Eidus wrote: On Fri, 11 Dec 2009 22:03:33 +0300 (MSK) malc av1...@comtv.ru wrote: On Fri, 11 Dec 2009, Izik Eidus wrote: On Fri, 11 Dec 2009 09:57:48 -0600 Anthony Liguori anth...@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.
[Qemu-devel] Spice project is now open
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
On Fri, Dec 11, 2009 at 10:45 PM, Yaniv Kamay yka...@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
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 junkoi2...@gmail.com wrote: On Fri, Dec 11, 2009 at 10:45 PM, Yaniv Kamay yka...@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 ag...@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
On Fri, Dec 11, 2009 at 11:09 PM, Alexander Graf ag...@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
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
Jun Koi wrote: On Fri, Dec 11, 2009 at 11:09 PM, Alexander Graf ag...@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
* Anthony Liguori (anth...@codemonkey.ws) wrote: Jun Koi wrote: On Fri, Dec 11, 2009 at 11:09 PM, Alexander Graf ag...@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
* Yaniv Kamay (yka...@redhat.com) wrote: - Anthony Liguori anth...@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
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
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
- Anthony Liguori anth...@codemonkey.ws wrote: Jun Koi wrote: On Fri, Dec 11, 2009 at 11:09 PM, Alexander Graf ag...@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
On 11.12.2009, at 18:02, Yaniv Kamay wrote: - Anthony Liguori anth...@codemonkey.ws wrote: Jun Koi wrote: On Fri, Dec 11, 2009 at 11:09 PM, Alexander Graf ag...@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
- Anthony Liguori anth...@codemonkey.ws wrote: I'm not getting into this discussion and is not going to happen, you have all the necessary information on spiec-space.org in order to take intelligent decision. The QEMU community can choose to reject Spice if it decide to do so. There's nothing to reject. You haven't posted patches. When you do post patches, if you can't/won't offer an explanation as to why it's better than what we already have, then they will be rejected. Now I'm really scare. Regards, Anthony Liguori
Re: [Qemu-devel] Spice project is now open
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
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
* Anthony Liguori (anth...@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
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
On Fri, 11 Dec 2009 09:57:48 -0600 Anthony Liguori anth...@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
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
On Fri, 11 Dec 2009 18:57:17 + Ben Taylor bentaylor.sol...@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
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
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
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
On Fri, 11 Dec 2009 22:03:33 +0300 (MSK) malc av1...@comtv.ru wrote: On Fri, 11 Dec 2009, Izik Eidus wrote: On Fri, 11 Dec 2009 09:57:48 -0600 Anthony Liguori anth...@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
On Fri, 11 Dec 2009 13:04:02 -0600 Anthony Liguori anth...@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
On Fri, 11 Dec 2009 13:06:47 -0600 Anthony Liguori anth...@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
On Fri, 11 Dec 2009 17:07:13 -0200 Glauber Costa glom...@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
On Fri, 11 Dec 2009, Izik Eidus wrote: On Fri, 11 Dec 2009 22:03:33 +0300 (MSK) malc av1...@comtv.ru wrote: On Fri, 11 Dec 2009, Izik Eidus wrote: On Fri, 11 Dec 2009 09:57:48 -0600 Anthony Liguori anth...@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:av1...@comtv.ru
Re: [Qemu-devel] Spice project is now open
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
On Fri, 11 Dec 2009 17:15:02 -0200 Glauber Costa glom...@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
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
On Fri, 11 Dec 2009 22:24:38 +0300 (MSK) malc av1...@comtv.ru wrote: On Fri, 11 Dec 2009, Izik Eidus wrote: On Fri, 11 Dec 2009 22:03:33 +0300 (MSK) malc av1...@comtv.ru wrote: On Fri, 11 Dec 2009, Izik Eidus wrote: On Fri, 11 Dec 2009 09:57:48 -0600 Anthony Liguori anth...@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
On Fri, Dec 11, 2009 at 5:22 PM, Izik Eidus iei...@redhat.com wrote: On Fri, 11 Dec 2009 13:06:47 -0600 Anthony Liguori anth...@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
On Fri, 11 Dec 2009 13:30:22 -0600 Anthony Liguori anth...@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
Izik Eidus wrote: On Fri, 11 Dec 2009 13:30:22 -0600 Anthony Liguori anth...@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
Re: [Qemu-devel] Spice project is now open
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
On Fri, 11 Dec 2009, Izik Eidus wrote: On Fri, 11 Dec 2009 22:24:38 +0300 (MSK) malc av1...@comtv.ru wrote: On Fri, 11 Dec 2009, Izik Eidus wrote: On Fri, 11 Dec 2009 22:03:33 +0300 (MSK) malc av1...@comtv.ru wrote: On Fri, 11 Dec 2009, Izik Eidus wrote: On Fri, 11 Dec 2009 09:57:48 -0600 Anthony Liguori anth...@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:av1...@comtv.ru
Re: [Qemu-devel] Spice project is now open
On Fri, 11 Dec 2009 13:51:53 -0600 Anthony Liguori anth...@codemonkey.ws wrote: Izik Eidus wrote: On Fri, 11 Dec 2009 13:30:22 -0600 Anthony Liguori anth...@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
Re: [Qemu-devel] Spice project is now open
On Fri, 11 Dec 2009 22:53:25 +0300 (MSK) malc av1...@comtv.ru wrote: On Fri, 11 Dec 2009, Izik Eidus wrote: On Fri, 11 Dec 2009 22:24:38 +0300 (MSK) malc av1...@comtv.ru wrote: On Fri, 11 Dec 2009, Izik Eidus wrote: On Fri, 11 Dec 2009 22:03:33 +0300 (MSK) malc av1...@comtv.ru wrote: On Fri, 11 Dec 2009, Izik Eidus wrote: On Fri, 11 Dec 2009 09:57:48 -0600 Anthony Liguori anth...@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
On Fri, 11 Dec 2009 13:51:53 -0600 Anthony Liguori anth...@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
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 wrote: On Fri, 11 Dec 2009 13:51:53 -0600 Anthony Liguori anth...@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
On Fri, 11 Dec 2009 14:46:55 -0600 Anthony Liguori anth...@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
Re: [Qemu-devel] Spice project is now open
On Fri, 11 Dec 2009 14:48:53 -0600 Anthony Liguori anth...@codemonkey.ws wrote: Izik Eidus wrote: On Fri, 11 Dec 2009 13:51:53 -0600 Anthony Liguori anth...@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
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 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
On 11.12.2009, at 22:13, Izik Eidus wrote: On Fri, 11 Dec 2009 14:46:55 -0600 Anthony Liguori anth...@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
Re: [Qemu-devel] Spice project is now open
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 Liguorianth...@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
Re: [Qemu-devel] Spice project is now open
On Fri, 11 Dec 2009 15:54:52 -0600 Anthony Liguori anth...@codemonkey.ws wrote: Izik Eidus wrote: By the time we get to video memory, the display server has already straightened out what portions of the screen are visible and what aren't. It will not render a hidden window and then render another window on top of it. I dont understand, if you have applciation that draw Rectangle, and just another Rectanlge on top of it, wont it hide it?, doesnt we want just to send the newest Rectangle? If you're using something like gdk, the toolkit double buffers windows by default and does a single flip on expose. So this sort of thing never makes it way to the X server. But the other point is, if you draw a rectangle with gdk, all the X server ever sees is the drawing of an image. Spice work on the driver primitives it doesnt know what is GDK, if the X driver will draw rectangle and then another rectangle, VNC will have to draw it twice, spice not. The point is, there isn't a draw a rectangle primitive in X. There also isn't a draw some text using this font in X.[1] These things exist at higher levels (like GTK and QT). [1] there actually are but modern applications don't use them. While X can use just the Fill and Copy commands for spice, no one block driver writer to add the GTK / QT levels you are talking about and send this commands into spice (Xrender???), In addition to the Fill and Copy commands spice can help improve performence with offscreen surfaces support that allowing sending the pixmaps in the background while the network is idle. We are currently at the moment just implmented the X driver and we are working to add better support for spice in this area (probably it will be improvments regerding to xrender), so this parts have still big potential to improve in spice. In addition when we will merge the 3d support, driver would be able to translate opengl commands into spice 3d commands. Ohh, The performence is much better user interactive and higher density the user interactive come from the paravirtual device and the fact that we dont send commands that were hide into the client. The higher density come from the fact that the server that run the VM (qemu) almost never have to render the stuff With the Linux guest driver? If you can quantify that, it would be very useful. The X driver is still very new, we have still a way to go to add all what X need to achive the performence spice can offer. Are there plans to integrate Spice support in gdk (or cairo)? I think that would be required to get performance parity with Windows. Can you expline more what you mean? Spice work on the driver primitives, so I am not sure I understand here what you suggest... I think the point I'm trying to get across, is that Windows has a centralized architecture of drawing primitives and interfaces that is relatively easy for drivers to hook into. Linux doesn't have this. Different things are handled in different places and some layers (like GDK) aren't really made for hooking into. What I'm trying to understand is whether it will be possible to implement a lot of the Spice accelerations for Linux guests. Xrender, and Opengl would be possible to be implment in spice I think Xrender is what Cairo use for hardware accelration and this much of what you need no? Regards, Anthony Liguori
Re: [Qemu-devel] Spice project is now open
On Fri, 11 Dec 2009 23:08:01 +0100 Alexander Graf ag...@suse.de wrote: On 11.12.2009, at 22:13, Izik Eidus wrote: On Fri, 11 Dec 2009 14:46:55 -0600 Anthony Liguori anth...@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.
Re: [Qemu-devel] Spice project is now open
* Anthony Liguori (anth...@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
On 11.12.2009, at 23:46, Izik Eidus wrote: On Fri, 11 Dec 2009 23:08:01 +0100 Alexander Graf ag...@suse.de wrote: On 11.12.2009, at 22:13, Izik Eidus wrote: On Fri, 11 Dec 2009 14:46:55 -0600 Anthony Liguori anth...@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
Re: [Qemu-devel] Spice project is now open
On Sat, 12 Dec 2009 00:54:47 +0100 Alexander Graf ag...@suse.de wrote: On 11.12.2009, at 23:46, Izik Eidus wrote: On Fri, 11 Dec 2009 23:08:01 +0100 Alexander Graf ag...@suse.de wrote: On 11.12.2009, at 22:13, Izik Eidus wrote: On Fri, 11 Dec 2009 14:46:55 -0600 Anthony Liguori anth...@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.
Re: [Qemu-devel] Spice project is now open
On 12.12.2009, at 01:14, Izik Eidus wrote: On Sat, 12 Dec 2009 00:54:47 +0100 Alexander Graf ag...@suse.de wrote: On 11.12.2009, at 23:46, Izik Eidus wrote: On Fri, 11 Dec 2009 23:08:01 +0100 Alexander Graf ag...@suse.de wrote: On 11.12.2009, at 22:13, Izik Eidus wrote: On Fri, 11 Dec 2009 14:46:55 -0600 Anthony Liguori anth...@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
Re: [Qemu-devel] Spice project is now open
On Sat, 12 Dec 2009 01:27:09 +0100 Alexander Graf ag...@suse.de wrote: On 12.12.2009, at 01:14, Izik Eidus wrote: On Sat, 12 Dec 2009 00:54:47 +0100 Alexander Graf ag...@suse.de wrote: On 11.12.2009, at 23:46, Izik Eidus wrote: On Fri, 11 Dec 2009 23:08:01 +0100 Alexander Graf ag...@suse.de wrote: On 11.12.2009, at 22:13, Izik Eidus wrote: On Fri, 11 Dec 2009 14:46:55 -0600 Anthony Liguori anth...@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
Re: [Qemu-devel] Spice project is now open
On 12.12.2009, at 01:53, Izik Eidus wrote: On Sat, 12 Dec 2009 01:27:09 +0100 Alexander Graf ag...@suse.de wrote: On 12.12.2009, at 01:14, Izik Eidus wrote: On Sat, 12 Dec 2009 00:54:47 +0100 Alexander Graf ag...@suse.de wrote: On 11.12.2009, at 23:46, Izik Eidus wrote: On Fri, 11 Dec 2009 23:08:01 +0100 Alexander Graf ag...@suse.de wrote: On 11.12.2009, at 22:13, Izik Eidus wrote: On Fri, 11 Dec 2009 14:46:55 -0600 Anthony Liguori anth...@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.
Re: [Qemu-devel] Spice project is now open
On Sat, 12 Dec 2009 02:08:05 +0100 Alexander Graf ag...@suse.de wrote: So the thing I dislike is the take all of QXL and SPICE or leave everything sort of attitude that's coming over. I'd love to use QXL, but I don't want to use SPICE :-). Thus I want to make sure we're going in a really modular direction, so all the bits can be combined to every users' liking. Thus creating choice. We are palning to add local rendering support for qxl inside qemu... Alex
Re: [Qemu-devel] Spice project is now open
Chris Wright wrote: * Anthony Liguori (anth...@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
