Re: [Qemu-devel] [PATCH v5] libxl: add basic spice support for pv domUs

Re: [Qemu-devel] [PATCH v5] libxl: add basic spice support for pv domUs

[Fabio Fantoni]

Il 16/05/2014 14:47, Ian Campbell ha scritto:
> On Fri, 2014-05-16 at 14:37 +0200, Fabio Fantoni wrote:
>> This patch adds basic spice support for pv domUs.
>> The qemu parameters are the same as the hvm ones and they works.
>> Therefore xl cfg parameters are the same as the hvm ones except that
>> features not supported yet by pv domUs (vdagent and usbredirection)
>> are kept disabled by default.
>> It also enables vfb and vkb required to have basic spice working.
> Based on your response in <53722538.80106@m2r.biz> I'm not sure if this
> an accurate description of what you are doing here. AFAICT what you are
> actually doing is enabling SPICE as a backend for the PVFB device, as an
> alternative to VNC and SDL. Is that correct or not?
>
> Ian.
>

Yes, if nobody has a better idea when I'll have sufficient time I'll try 
to complete the vfb part duplicating thespice parametersin vfb[] and 
adding parts "missing" looking like the example code about vnc.
In this patch version (5) for now I did one fix and all other your 
previous advices except the add of spice.enable check in 
libxl__need_xenpv_qemu not needed because is always true with vfb added.

About complete spice (hvm-only for now) I am also other patches adding 2 
more spice parameters that help to lower cpu usage while maintaining the 
highest quality effects and graphics even on high resolutions.
In my latest test I had windows 7 xen domUs with qxl, max resolution and 
32 bit color on 21-23 inch monitor with good performance.
The only 2 main problem reimained with spice I think that are qxl not 
working on linux domUs(xen related) and the high cpu usage for missed 
hardware video coding/decoding support (not xen related).

Thanks for any reply and sorry for my bad english.

Re: [Qemu-devel] [PATCH v5] libxl: add basic spice support for pv domUs

[Ian Campbell]

On Fri, 2014-05-16 at 15:41 +0200, Fabio Fantoni wrote:
> Il 16/05/2014 14:47, Ian Campbell ha scritto:
> > On Fri, 2014-05-16 at 14:37 +0200, Fabio Fantoni wrote:
> >> This patch adds basic spice support for pv domUs.
> >> The qemu parameters are the same as the hvm ones and they works.
> >> Therefore xl cfg parameters are the same as the hvm ones except that
> >> features not supported yet by pv domUs (vdagent and usbredirection)
> >> are kept disabled by default.
> >> It also enables vfb and vkb required to have basic spice working.
> > Based on your response in <53722538.80106@m2r.biz> I'm not sure if this
> > an accurate description of what you are doing here. AFAICT what you are
> > actually doing is enabling SPICE as a backend for the PVFB device, as an
> > alternative to VNC and SDL. Is that correct or not?
> Yes,

In that case then these spice settings should be part of
libxl_device_vfb, like the vnc ones are and they should configurable in
xl configuration files as:

	vfb = [ 'spice=1,spiceport=NNN' ]

There should be no need to move the HVM spice parameters to the top
level of the domain configuration. I'm afraid my previous advice was
based on an incorrect understanding of what you were implementing
(derived from the commit message not being clear about what was actually
going on).

> The only 2 main problem reimained with spice I think that are qxl not 
> working on linux domUs(xen related)

Given the lack of clarity shown so far about what this existing patch is
actually doing doing I'm a little concerned about how QXL is going to
fit into the model in the future.

Ian.

Re: [Qemu-devel] [PATCH v5] libxl: add basic spice support for pv domUs

[Fabio Fantoni]

Il 16/05/2014 15:56, Ian Campbell ha scritto:
> On Fri, 2014-05-16 at 15:41 +0200, Fabio Fantoni wrote:
>> Il 16/05/2014 14:47, Ian Campbell ha scritto:
>>> On Fri, 2014-05-16 at 14:37 +0200, Fabio Fantoni wrote:
>>>> This patch adds basic spice support for pv domUs.
>>>> The qemu parameters are the same as the hvm ones and they works.
>>>> Therefore xl cfg parameters are the same as the hvm ones except that
>>>> features not supported yet by pv domUs (vdagent and usbredirection)
>>>> are kept disabled by default.
>>>> It also enables vfb and vkb required to have basic spice working.
>>> Based on your response in <53722538.80106@m2r.biz> I'm not sure if this
>>> an accurate description of what you are doing here. AFAICT what you are
>>> actually doing is enabling SPICE as a backend for the PVFB device, as an
>>> alternative to VNC and SDL. Is that correct or not?
>> Yes,
> In that case then these spice settings should be part of
> libxl_device_vfb, like the vnc ones are and they should configurable in
> xl configuration files as:
>
> 	vfb = [ 'spice=1,spiceport=NNN' ]
>
> There should be no need to move the HVM spice parameters to the top
> level of the domain configuration. I'm afraid my previous advice was
> based on an incorrect understanding of what you were implementing
> (derived from the commit message not being clear about what was actually
> going on).
>
>> The only 2 main problem reimained with spice I think that are qxl not
>> working on linux domUs(xen related)
> Given the lack of clarity shown so far about what this existing patch is
> actually doing doing I'm a little concerned about how QXL is going to
> fit into the model in the future.
>
> Ian.
>

About libxl patch for QXL support is still the same except the refresh 
with new xen-unstable.
My latest test is based on this source that include all my latest patches:
https://github.com/Fantu/Xen/commits/rebase/m2r-next
I'll repost it with updated and full noted in description.
Regarging qxl problem on xen linux domUs I didn't found other useful 
details to solve the problem and I not have sufficient time now for 
advanced debug.

Thanks for any reply and sorry for my bad english.

Re: [Qemu-devel] [PATCH v5] libxl: add basic spice support for pv domUs

[Ian Campbell]

On Fri, 2014-05-16 at 16:20 +0200, Fabio Fantoni wrote:
> Il 16/05/2014 15:56, Ian Campbell ha scritto:
> > On Fri, 2014-05-16 at 15:41 +0200, Fabio Fantoni wrote:
> >> Il 16/05/2014 14:47, Ian Campbell ha scritto:
> >>> On Fri, 2014-05-16 at 14:37 +0200, Fabio Fantoni wrote:
> >>>> This patch adds basic spice support for pv domUs.
> >>>> The qemu parameters are the same as the hvm ones and they works.
> >>>> Therefore xl cfg parameters are the same as the hvm ones except that
> >>>> features not supported yet by pv domUs (vdagent and usbredirection)
> >>>> are kept disabled by default.
> >>>> It also enables vfb and vkb required to have basic spice working.
> >>> Based on your response in <53722538.80106@m2r.biz> I'm not sure if this
> >>> an accurate description of what you are doing here. AFAICT what you are
> >>> actually doing is enabling SPICE as a backend for the PVFB device, as an
> >>> alternative to VNC and SDL. Is that correct or not?
> >> Yes,
> > In that case then these spice settings should be part of
> > libxl_device_vfb, like the vnc ones are and they should configurable in
> > xl configuration files as:
> >
> > 	vfb = [ 'spice=1,spiceport=NNN' ]
> >
> > There should be no need to move the HVM spice parameters to the top
> > level of the domain configuration. I'm afraid my previous advice was
> > based on an incorrect understanding of what you were implementing
> > (derived from the commit message not being clear about what was actually
> > going on).
> >
> >> The only 2 main problem reimained with spice I think that are qxl not
> >> working on linux domUs(xen related)
> > Given the lack of clarity shown so far about what this existing patch is
> > actually doing doing I'm a little concerned about how QXL is going to
> > fit into the model in the future.
> >
> > Ian.
> >
> 
> About libxl patch for QXL support is still the same except the refresh 
> with new xen-unstable.
> My latest test is based on this source that include all my latest patches:
> https://github.com/Fantu/Xen/commits/rebase/m2r-next
> I'll repost it with updated and full noted in description.
> Regarging qxl problem on xen linux domUs I didn't found other useful 
> details to solve the problem and I not have sufficient time now for 
> advanced debug.

I wasn't talking talking about the problems with it, I was talking about
how enabling QXL in the future will fit in with the data model being
introduced here. I don't want to take spice support on the assumption
that it is just a backend for PVFB and then find out that this is a
wrong model when QXL comes to get added.

My main concern is that you don't appear to understand how the model
fits together either, and yet you keep posting patches to turn things
on. This makes me very nervous.

Ian.

Re: [Qemu-devel] [PATCH v5] libxl: add basic spice support for pv domUs

[Fabio Fantoni]

Il 16/05/2014 16:28, Ian Campbell ha scritto:
> On Fri, 2014-05-16 at 16:20 +0200, Fabio Fantoni wrote:
>> Il 16/05/2014 15:56, Ian Campbell ha scritto:
>>> On Fri, 2014-05-16 at 15:41 +0200, Fabio Fantoni wrote:
>>>> Il 16/05/2014 14:47, Ian Campbell ha scritto:
>>>>> On Fri, 2014-05-16 at 14:37 +0200, Fabio Fantoni wrote:
>>>>>> This patch adds basic spice support for pv domUs.
>>>>>> The qemu parameters are the same as the hvm ones and they works.
>>>>>> Therefore xl cfg parameters are the same as the hvm ones except that
>>>>>> features not supported yet by pv domUs (vdagent and usbredirection)
>>>>>> are kept disabled by default.
>>>>>> It also enables vfb and vkb required to have basic spice working.
>>>>> Based on your response in<53722538.80106@m2r.biz>  I'm not sure if this
>>>>> an accurate description of what you are doing here. AFAICT what you are
>>>>> actually doing is enabling SPICE as a backend for the PVFB device, as an
>>>>> alternative to VNC and SDL. Is that correct or not?
>>>> Yes,
>>> In that case then these spice settings should be part of
>>> libxl_device_vfb, like the vnc ones are and they should configurable in
>>> xl configuration files as:
>>>
>>> 	vfb = [ 'spice=1,spiceport=NNN' ]
>>>
>>> There should be no need to move the HVM spice parameters to the top
>>> level of the domain configuration. I'm afraid my previous advice was
>>> based on an incorrect understanding of what you were implementing
>>> (derived from the commit message not being clear about what was actually
>>> going on).
>>>
>>>> The only 2 main problem reimained with spice I think that are qxl not
>>>> working on linux domUs(xen related)
>>> Given the lack of clarity shown so far about what this existing patch is
>>> actually doing doing I'm a little concerned about how QXL is going to
>>> fit into the model in the future.
>>>
>>> Ian.
>>>
>> About libxl patch for QXL support is still the same except the refresh
>> with new xen-unstable.
>> My latest test is based on this source that include all my latest patches:
>> https://github.com/Fantu/Xen/commits/rebase/m2r-next
>> I'll repost it with updated and full noted in description.
>> Regarging qxl problem on xen linux domUs I didn't found other useful
>> details to solve the problem and I not have sufficient time now for
>> advanced debug.
> I wasn't talking talking about the problems with it, I was talking about
> how enabling QXL in the future will fit in with the data model being
> introduced here. I don't want to take spice support on the assumption
> that it is just a backend for PVFB and then find out that this is a
> wrong model when QXL comes to get added.
>
> My main concern is that you don't appear to understand how the model
> fits together either, and yet you keep posting patches to turn things
> on. This makes me very nervous.
>
> Ian.
>
I seriously doubt that such things (needed for the qxl) will be ever 
done for PV guests.

If this will happen, this would be probably done in pvh instead which I 
think is simplier and quicker.

In the meantime we cannot use spice on PV guests. I believe that I'm not 
the only one to really desire this kind of support. (Spice form both hvm 
and PV guests).

Unfortunately from 2012 I saw no one with better knowledge was on the 
thread to continue and improve the spice support in xen.

So I'm doing my best despite my lack of knowledge and time.

Thanks for any reply and sorry for my bad english.