From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Subject: Re: Porting SPICE to Xen Date: Fri, 8 Jan 2010 00:46:50 +0000 Message-ID: <6894a6471001071646g558957d4u43e1c066c34e63b3@mail.gmail.com> References: <6894a6470912280850v5b7ad285l6d90f213ef18da0b@mail.gmail.com> <6b7f6eb1001062033v3f80ae52t5d8b590e9d7819cc@mail.gmail.com> <4B45BF13.1070901@eu.citrix.com> <20100107111620.GG16032@redhat.com> Reply-To: admin@dmarkey.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1182549233==" Return-path: In-Reply-To: <20100107111620.GG16032@redhat.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Daniel P. Berrange" Cc: "xen-devel@lists.xensource.com" , Vincent Hanquez , Thiago Camargo Martins Cordeiro , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org --===============1182549233== Content-Type: multipart/alternative; boundary=001485f87c62ed1924047c9c8538 --001485f87c62ed1924047c9c8538 Content-Type: text/plain; charset=ISO-8859-1 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 > 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 > :| > --001485f87c62ed1924047c9c8538 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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?<= div>
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.=A0

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

The guest Q= XL 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 D= aniel 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 ma= ybe
> >it is only for HVM domains?!
> SPICE is 2 differents parts, the part that expose the PCI device to th= e
> guest and "replace" the graphic card IIRC, and the actual re= mote desktop
> protocol.

That's not entirely accurate terminology. SPICE is the remote des= ktop
protocol & client/server side libraries. When SPICE is integrated into<= br> 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<= br> 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 y= ou could
make SPICE "work" with the PVFB, but it probably wouldn't off= er much of a
performance benefit over VNC, because it'll be limited to dumb framebuf= fer
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 =A0 -o- =A0 http://people.redhat.com/berrange/ :|=
|: http://libvirt.org = =A0-o- =A0http://virt= -manager.org =A0-o- =A0h= ttp://ovirt.org :|
|: http://autobuild.org<= /a> =A0 =A0 =A0 -o- =A0 =A0 =A0 =A0 http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 =A0-o- =A0F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9= 505 :|

--001485f87c62ed1924047c9c8538-- --===============1182549233== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1182549233==--