Re: [TestDay] F20 Xen 4.4 RC3 Spice support

[George Dunlap <george.dunlap@eu.citrix.com>]

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

On 04/11/2014 08:52 AM, Fabio Fantoni wrote:
> Il 10/04/2014 18:21, George Dunlap ha scritto:
>> On Thu, Apr 10, 2014 at 1:26 PM, Fabio Fantoni 
>> <fabio.fantoni@m2r.biz> wrote:
>>> Il 11/02/2014 10:56, Fabio Fantoni ha scritto:
>>>> Il 10/02/2014 18:05, George Dunlap ha scritto:
>>>>
>>>>> On Tue, Feb 4, 2014 at 4:01 PM, Fabio Fantoni <fabio.fantoni@m2r.biz>
>>>>> wrote:
>>>>>> Il 04/02/2014 16:41, Eric Houby ha scritto:
>>>>>>
>>>>>>> Xen list,
>>>>>>>
>>>>>>> I am trying to boot a F20 guest and connect using Spice but have 
>>>>>>> run
>>>>>>> into an issue.
>>>>>>>
>>>>>>> My VM config file includes:
>>>>>>> spice = 1
>>>>>>> spicehost='0.0.0.0'
>>>>>>> spiceport=6001
>>>>>>> spicedisable_ticketing=1
>>>>>>>
>>>>>>>
>>>>>>> Is Spice supported with qemu-xen-traditional?
>>>>>>
>>>>>> No, only with upstream qemu and if compile xen and qemu from 
>>>>>> source you
>>>>>> also
>>>>>> enable spice support on qemu build, for example on my xen build 
>>>>>> tests I
>>>>>> add:
>>>>>>
>>>>>> tools/Makefile
>>>>>> @@ -201,6 +201,8 @@ subdir-all-qemu-xen-dir: qemu-xen-dir-find
>>>>>>            --datadir=$(SHAREDIR)/qemu-xen \
>>>>>>            --localstatedir=/var \
>>>>>>            --disable-kvm \
>>>>>> +        --enable-spice \
>>>>>> +        --enable-usb-redir \
>>>>>>            --disable-docs \
>>>>>>            --disable-guest-agent \
>>>>>>            --python=$(PYTHON) \
>>>>>>
>>>>>> If you use upstream qemu from distribution package probably have 
>>>>>> already
>>>>>> spice build-in, for example, on debian I've already tested and 
>>>>>> working.
>>>>> It might be nice at some point to have this integrated into the
>>>>> top-level configure, possibly enabled by default (gated on the
>>>>> appropriate development libraries being enabled).
>>>>>
>>>>>    -George
>>>
>>>
>>>> I already did a patch to do it time ago in three different ways but 
>>>> all
>>>> rejected :(
>>>> A one reason was the lack of needed libraries on many distros versions
>>>> used with xen.
>>>> Now all newer versions have the needed spice and usbredir libraries
>>>> included, so if you would like reconsider the path please point me 
>>>> in the
>>>> right direction in order to have this done correctly.
>>>> The three way I did were:
>>>> - enabled by default
>>>> - Added optional build configs for qemu upstream (debug part now no 
>>>> more
>>>> needed because already present)
>>>> http://lists.xen.org/archives/html/xen-devel/2012-03/msg00506.html
>>>> - Autoconf: add variable for pass arbitrary options to qemu upstream
>>>> http://lists.xen.org/archives/html/xen-devel/2012-03/msg01677.html
>>>> Probably there are also newer versions of these patches that I not 
>>>> found
>>>> anymore.
>>>>
>>>> Thanks for any reply.
>>>
>>> Ping.
>>> Added also Ian Campbell and Ian Jackson to cc, which have been take 
>>> part to
>>> the discussion about 2 years ago.
>> I think you'll need to rebase and re-post those patches if want us to
>> discuss them after 2 years.
>>
>>   -George
>
> I think the best option would be to identify which one of the three 
> methods is best before do updated and improve patch for it:
> - spice and usbredir enabled by default in qemu upstream build
> - optional spice and usbredir build configs for qemu upstream
> - Autoconf: add variable for pass arbitrary build options to qemu 
> upstream

Looking at that thread, it seems IanJ is in favor of something like your 
final approach (" [PATCH 
v3]Autoconf:addvariableforpassarbitraryoptionstoqemuupstream"); he 
apparently just dropped the thread.  (Or perhaps didn't realize that 
Roger had actually asked you to do the opposite of what he'd asked you 
to do -- it wasn't obvious to me the first time I went through it.)

Normally the thing to do would be to reply "Ping" to that patch, but 
given how long ago it was, it's probably a better idea to take the patch 
as it is, rebase it, and send it again (with [PATCH RESEND] in the 
subject line).

A couple of additional comments while I'm looking at it:
* After the v1->v2 change, you're no longer passing arbitrary options, 
so you should probably change the title of the patch again
* Don't include the patch version number in the commit message

  -George

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

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

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