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? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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
Thiago Camargo Martins Cordeiro
2010-Jan-07 04:33 UTC
Re: [Xen-devel] Porting SPICE to Xen
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 >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 :| _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 > :| >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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-qxlI 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 :| _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel