Porting SPICE to Xen

Porting SPICE to Xen

[David]

[-- Attachment #1.1: Type: text/plain, Size: 326 bytes --]

Has anyone toyed with the idea of porting SPICE to Xen? I've been playing
with it and it's quite impressive.

As far as I can tell it can run without KVM being loaded so it must run
almost entirely in userspace, could it be as simple as applying the xen
patches to the "spiced" qemu to make a "spiced" qemu-dm?

Any thoughts?

[-- Attachment #1.2: Type: text/html, Size: 374 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: Porting SPICE to Xen

[Stefano Stabellini]

On Mon, 28 Dec 2009, David wrote:
> Has anyone toyed with the idea of porting SPICE to Xen? I've been playing with it and it's quite impressive.
> 
> As far as I can tell it can run without KVM being loaded so it must run almost entirely in userspace, could it be as
> simple as applying the xen patches to the "spiced" qemu to make a "spiced" qemu-dm?
> 
> Any thoughts?
> 
> 

In theory it is entirely possible but at the moment we don't have a set
of patches for qemu but a whole qemu branch so it would make this
difficult.

Of course any effort to produce this set of patches from our current
qemu-xen tree would be very welcome :)

Re: Porting SPICE to Xen

[Thiago Camargo Martins Cordeiro]

[-- Attachment #1.1: Type: text/plain, Size: 1001 bytes --]

If this happen, it will work with paravirtualized domUs too? Or maybe it is
only for HVM domains?!

Cheers!
Thiago

2010/1/6 Stefano Stabellini <stefano.stabellini@eu.citrix.com>

> On Mon, 28 Dec 2009, David wrote:
> > Has anyone toyed with the idea of porting SPICE to Xen? I've been playing
> with it and it's quite impressive.
> >
> > As far as I can tell it can run without KVM being loaded so it must run
> almost entirely in userspace, could it be as
> > simple as applying the xen patches to the "spiced" qemu to make a
> "spiced" qemu-dm?
> >
> > Any thoughts?
> >
> >
>
> In theory it is entirely possible but at the moment we don't have a set
> of patches for qemu but a whole qemu branch so it would make this
> difficult.
>
> Of course any effort to produce this set of patches from our current
> qemu-xen tree would be very welcome :)
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

[-- Attachment #1.2: Type: text/html, Size: 1608 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: Porting SPICE to Xen

[Vincent Hanquez]

On 01/07/2010 04:33 AM, Thiago Camargo Martins Cordeiro wrote:
> If this happen, it will work with paravirtualized domUs too? Or maybe 
> it is only for HVM domains?!
SPICE is 2 differents parts, the part that expose the PCI device to the 
guest and "replace" the graphic card IIRC, and the actual remote desktop 
protocol.

at the moment the 2 are fairly intertwined, so it would only work with 
HVM domains [1], but depending on how the things get de-intertwined 
(which is something qemu people want), it might be possible to have it 
on PV. I wouldn't hold my breath on PV domain though.

(I'm no SPICE expert however, so it take it with a grain of salt.)

[1] providing all the pieces are available upstream in qemu etc.. which 
probably going to take a while too.
-- 
Vincent

Re: Porting SPICE to Xen

[Daniel P. Berrange]

On Thu, Jan 07, 2010 at 11:01:39AM +0000, Vincent Hanquez wrote:
> On 01/07/2010 04:33 AM, Thiago Camargo Martins Cordeiro wrote:
> >If this happen, it will work with paravirtualized domUs too? Or maybe 
> >it is only for HVM domains?!
> SPICE is 2 differents parts, the part that expose the PCI device to the 
> guest and "replace" the graphic card IIRC, and the actual remote desktop 
> protocol.

That's not entirely accurate terminology. SPICE is the remote desktop
protocol & client/server side libraries. When SPICE is integrated into
QEMU, it takes advantage of a new graphics card called "QXL", and the
corresponding guest OS drivers. IIUC, currently SPICE can't use the
Cirrus card, and the QXL card doesn't work with VNC, but those are both
just artifacts of the current integration of SPICE with QEMU, not problems
of SPICE or QXL themselves, which from an architectural POV are both
separate things.

> at the moment the 2 are fairly intertwined, so it would only work with 
> HVM domains [1], but depending on how the things get de-intertwined 
> (which is something qemu people want), it might be possible to have it 
> on PV. I wouldn't hold my breath on PV domain though.

It depends what you'd want from PV domain integration. I expect you could
make SPICE "work" with the PVFB, but it probably wouldn't offer much of a
performance benefit over VNC, because it'll be limited to dumb framebuffer
mode. To take full advantage of SPICE requries a graphics card supporting
the various advanced operations, which is what QXL supplies. Enhancing 
PVFB to support some of the advanced QXL features would be where the
significant work arrives

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

Re: Porting SPICE to Xen

[David]

[-- Attachment #1.1: Type: text/plain, Size: 2631 bytes --]

HVM would be a good start. It would be a good way for Xen to break into the
VDI space easily, unless there's something I haven't come across?

As far as I understand, if the QXL driver isn't installed, it will fall back
to standard VGA. The spice client will still be able to connect, but it just
wont be accelerated.

The spice protocol doesn't just handle graphics, but sound and USB is in the
pipeline.

The guest QXL driver is available for windows anyway, so that will be HVM
only, I'm not sure about the status of the X guest driver.



2010/1/7 Daniel P. Berrange <berrange@redhat.com>

> On Thu, Jan 07, 2010 at 11:01:39AM +0000, Vincent Hanquez wrote:
> > On 01/07/2010 04:33 AM, Thiago Camargo Martins Cordeiro wrote:
> > >If this happen, it will work with paravirtualized domUs too? Or maybe
> > >it is only for HVM domains?!
> > SPICE is 2 differents parts, the part that expose the PCI device to the
> > guest and "replace" the graphic card IIRC, and the actual remote desktop
> > protocol.
>
> That's not entirely accurate terminology. SPICE is the remote desktop
> protocol & client/server side libraries. When SPICE is integrated into
> QEMU, it takes advantage of a new graphics card called "QXL", and the
> corresponding guest OS drivers. IIUC, currently SPICE can't use the
> Cirrus card, and the QXL card doesn't work with VNC, but those are both
> just artifacts of the current integration of SPICE with QEMU, not problems
> of SPICE or QXL themselves, which from an architectural POV are both
> separate things.
>
> > at the moment the 2 are fairly intertwined, so it would only work with
> > HVM domains [1], but depending on how the things get de-intertwined
> > (which is something qemu people want), it might be possible to have it
> > on PV. I wouldn't hold my breath on PV domain though.
>
> It depends what you'd want from PV domain integration. I expect you could
> make SPICE "work" with the PVFB, but it probably wouldn't offer much of a
> performance benefit over VNC, because it'll be limited to dumb framebuffer
> mode. To take full advantage of SPICE requries a graphics card supporting
> the various advanced operations, which is what QXL supplies. Enhancing
> PVFB to support some of the advanced QXL features would be where the
> significant work arrives
>
> Daniel
> --
> |: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/:|
> |: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org:|
> |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/:|
> |: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505
> :|
>

[-- Attachment #1.2: Type: text/html, Size: 3632 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: Porting SPICE to Xen

[Vincent Hanquez]

On 01/08/2010 12:46 AM, David wrote:
> HVM would be a good start. It would be a good way for Xen to break 
> into the VDI space easily, unless there's something I haven't come 
> across?
>
> As far as I understand, if the QXL driver isn't installed, it will 
> fall back to standard VGA. The spice client will still be able to 
> connect, but it just wont be accelerated.
>
> The spice protocol doesn't just handle graphics, but sound and USB is 
> in the pipeline.
>
> The guest QXL driver is available for windows anyway, so that will be 
> HVM only, I'm not sure about the status of the X guest driver.
>

I just found out about that (maybe i'm just lagging), not sure the state 
either, but at least the source code is available:

http://cgit.freedesktop.org/xorg/driver/xf86-video-qxl

-- 
Vincent

Re: Porting SPICE to Xen

[Daniel P. Berrange]

On Mon, Jan 11, 2010 at 11:27:21AM +0000, Vincent Hanquez wrote:
> On 01/08/2010 12:46 AM, David wrote:
> >HVM would be a good start. It would be a good way for Xen to break 
> >into the VDI space easily, unless there's something I haven't come 
> >across?
> >
> >As far as I understand, if the QXL driver isn't installed, it will 
> >fall back to standard VGA. The spice client will still be able to 
> >connect, but it just wont be accelerated.
> >
> >The spice protocol doesn't just handle graphics, but sound and USB is 
> >in the pipeline.
> >
> >The guest QXL driver is available for windows anyway, so that will be 
> >HVM only, I'm not sure about the status of the X guest driver.
> >
> 
> I just found out about that (maybe i'm just lagging), not sure the state 
> either, but at least the source code is available:
> 
> http://cgit.freedesktop.org/xorg/driver/xf86-video-qxl

I think its fair to class that driver as functional, but not really
taking advantage of all the QXL has to offer, so won't show the level
of performance improvements QXL gives with the Window guest driver.
The X driver should be in Fedora soon.

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

Re: Porting SPICE to Xen

[David]

[-- Attachment #1.1: Type: text/plain, Size: 1333 bytes --]

Yea QXL is going into mainstream Xorg I think, seen a release announcement a
few days ago.


Also:


Simon Horman writes ("Re: [Xen-devel] Qemu version for upcoming Xen 4.0
release?"):
>> An idea from left-field, but is there any chance of merging qemu-xen
>> into qemu?

>We're planning to do this, hopefully into qemu 0.13 which is planned
>for the middle of this year


This could be interesting if SPICE makes its way into QEMU upstream also.

2010/1/11 Vincent Hanquez <vincent.hanquez@eu.citrix.com>

> On 01/08/2010 12:46 AM, David wrote:
>
>> HVM would be a good start. It would be a good way for Xen to break into
>> the VDI space easily, unless there's something I haven't come across?
>>
>> As far as I understand, if the QXL driver isn't installed, it will fall
>> back to standard VGA. The spice client will still be able to connect, but it
>> just wont be accelerated.
>>
>> The spice protocol doesn't just handle graphics, but sound and USB is in
>> the pipeline.
>>
>> The guest QXL driver is available for windows anyway, so that will be HVM
>> only, I'm not sure about the status of the X guest driver.
>>
>>
> I just found out about that (maybe i'm just lagging), not sure the state
> either, but at least the source code is available:
>
> http://cgit.freedesktop.org/xorg/driver/xf86-video-qxl
>
> --
> Vincent
>

[-- Attachment #1.2: Type: text/html, Size: 2070 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Porting Spice to Xen

[Yanjun Wu]

[-- Attachment #1.1: Type: text/plain, Size: 239 bytes --]

Is there any plan in Xen community to port Spice to Xen?
I saw it already appeared in Xen roadmap wiki. But I'm wondering whether
there are any people actually doing it now.
And is there any existing xen based VDI project or plan? Thanks.

[-- Attachment #1.2: Type: text/html, Size: 295 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: Porting Spice to Xen

[Stefano Stabellini]

[-- Attachment #1: Type: text/plain, Size: 454 bytes --]

On Tue, 30 Nov 2010, Yanjun Wu wrote:
> Is there any plan in Xen community to port Spice to Xen?  
> I saw it already appeared in Xen roadmap wiki. But I'm wondering whether there are any people actually doing it now. 

The first step is getting upstream qemu to work with Xen, and we are
working toward that goal.
After that we can see about spice.

> And is there any existing xen based VDI project or plan? Thanks.
> 

Citrix XenDesktop

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Porting spice to xen

[ZhouPeng]

[-- Attachment #1.1: Type: text/plain, Size: 825 bytes --]

Hi all,

We have tried to port spice to Xen (Xen 4.0.1, Dom0 kernel 2.6.18).
The current porting allows basic spice run for xen-fv.

Now We are trying to port the qxl component, but it's difficult
because of the big difference between xen-qemu and upstream qemu.
If you enable the qxl device in our current porting(do it by setting
'qxl=1' in xm config file), you are most likely to get a mess screen.
:(

So any help in qxl porting will be much appreciated.

Our work is shared here: http://code.google.com/p/spice4xen/

It's not be a good way to port spice to xen-qemu because of tremendous
difference. But before the Xen with upstream-qemu supported has been
released and runs stable, it may be a choice.

Best,
--
Zhou Peng
Operating System Technology Group
Institute of Software, the Chinese Academy of Sciences (ISCAS)

[-- Attachment #1.2: Type: text/html, Size: 975 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: Porting spice to xen

[Stefano Stabellini]

On Thu, 7 Apr 2011, ZhouPeng wrote:
> Hi all,
> 
> We have tried to port spice to Xen (Xen 4.0.1, Dom0 kernel 2.6.18).
> The current porting allows basic spice run for xen-fv.
> 
> Now We are trying to port the qxl component, but it's difficult
> because of the big difference between xen-qemu and upstream qemu.
> If you enable the qxl device in our current porting(do it by setting
> 'qxl=1' in xm config file), you are most likely to get a mess screen.
> :(
> 
> So any help in qxl porting will be much appreciated.
> 
> Our work is shared here: http://code.google.com/p/spice4xen/
> 
> It's not be a good way to port spice to xen-qemu because of tremendous
> difference. But before the Xen with upstream-qemu supported has been
> released and runs stable, it may be a choice.

I think that porting spice and qxl to the current qemu-xen tree is not
worth the effort, considering that we are very close to having xen
support in upstream qemu right now.
Also if you don't want to wait for xen support to go upstream in qemu
you can checkout Anthony Perard's git qemu branch and work directly on
it:

git://xenbits.xen.org/people/aperard/qemu-dm.git qemu-dm-v12

Re: Porting spice to xen

[ZhouPeng]

[-- Attachment #1.1: Type: text/plain, Size: 1457 bytes --]

2011/4/7 Stefano Stabellini <stefano.stabellini@eu.citrix.com>

> On Thu, 7 Apr 2011, ZhouPeng wrote:
> > Hi all,
> >
> > We have tried to port spice to Xen (Xen 4.0.1, Dom0 kernel 2.6.18).
> > The current porting allows basic spice run for xen-fv.
> >
> > Now We are trying to port the qxl component, but it's difficult
> > because of the big difference between xen-qemu and upstream qemu.
> > If you enable the qxl device in our current porting(do it by setting
> > 'qxl=1' in xm config file), you are most likely to get a mess screen.
> > :(
> >
> > So any help in qxl porting will be much appreciated.
> >
> > Our work is shared here: http://code.google.com/p/spice4xen/
> >
> > It's not be a good way to port spice to xen-qemu because of tremendous
> > difference. But before the Xen with upstream-qemu supported has been
> > released and runs stable, it may be a choice.
>
> I think that porting spice and qxl to the current qemu-xen tree is not
> worth the effort, considering that we are very close to having xen
> support in upstream qemu right now.
>

  Good news. How long will it be released?

Also if you don't want to wait for xen support to go upstream in qemu
> you can checkout Anthony Perard's git qemu branch and work directly on
> it:
>
> git://xenbits.xen.org/people/aperard/qemu-dm.git qemu-dm-v12
>

-- 
Zhou Peng
Operating System Technology Group
Institute of Software, the Chinese Academy of Sciences (ISCAS)
<ailvpeng25@gmail.com>

[-- Attachment #1.2: Type: text/html, Size: 2284 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: Porting spice to xen

[Stefano Stabellini]

[-- Attachment #1: Type: text/plain, Size: 484 bytes --]

On Fri, 8 Apr 2011, ZhouPeng wrote:
> I think that porting spice and qxl to the current qemu-xen tree is not
> worth the effort, considering that we are very close to having xen
> support in upstream qemu right now.
> 
>  
>   Good news. How long will it be released?

It should be almost a matter of days now.
If I were you I would start working on Anthony's tree because it is very
similar to what is going to look like qemu upstream after the patch
series is accepted.

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: Porting spice to xen

[ZhouPeng]

[-- Attachment #1.1: Type: text/plain, Size: 762 bytes --]

I will have a try of Anthony's tree.
Thank you, Stefano Stabellini.

2011/4/8 Stefano Stabellini <stefano.stabellini@eu.citrix.com>

> On Fri, 8 Apr 2011, ZhouPeng wrote:
> > I think that porting spice and qxl to the current qemu-xen tree is not
> > worth the effort, considering that we are very close to having xen
> > support in upstream qemu right now.
> >
> >
> >   Good news. How long will it be released?
>
> It should be almost a matter of days now.
> If I were you I would start working on Anthony's tree because it is very
> similar to what is going to look like qemu upstream after the patch
> series is accepted.



-- 
Zhou Peng
Operating System Technology Group
Institute of Software, the Chinese Academy of Sciences (ISCAS)
<ailvpeng25@gmail.com>

[-- Attachment #1.2: Type: text/html, Size: 1172 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel