[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH raisin 4/4] Update to 4.7, update qemu and qemu_traditional recipes



On 15/06/16 11:39, Stefano Stabellini wrote:
> On Tue, 14 Jun 2016, Anthony PERARD wrote:
>> On Tue, Jun 14, 2016 at 11:34:43AM +0100, George Dunlap wrote:
>>> On 14/06/16 11:31, Stefano Stabellini wrote:
>>>> On Tue, 14 Jun 2016, George Dunlap wrote:
>>>>> On 14/06/16 11:08, Stefano Stabellini wrote:
>>>>>> On Tue, 14 Jun 2016, George Dunlap wrote:
>>>>>>> On 14/06/16 10:46, Stefano Stabellini wrote:
>>>>>>>> On Mon, 13 Jun 2016, George Dunlap wrote:
>>>>>>>>> Add a 4.7 config file, make it the default.
>>>>>>>>>
>>>>>>>>> Also update the qemu and qemu_traditional recipies after Ian Cambell's
>>>>>>>>> work to split off separate libraries.
>>>>>>>>>
>>>>>>>>> Signed-off-by: George Dunlap <george.dunlap@xxxxxxxxxx>
>>>>>>>>> ---
>>>>>>>>> CC: Stefano Stabellini <sstabellini@xxxxxxxxxx>
>>>>>>>>> ---
>>>>>>>>>  components/qemu             | 21 +++++++++++++--------
>>>>>>>>>  components/qemu_traditional |  2 +-
>>>>>>>>>  configs/config-4.7          |  8 ++++++++
>>>>>>>>>  defconfig                   |  2 +-
>>>>>>>>>  4 files changed, 23 insertions(+), 10 deletions(-)
>>>>>>>>>
>>>>>>>>> diff --git a/components/qemu b/components/qemu
>>>>>>>>> index e0d92a5..8624b50 100644
>>>>>>>>> --- a/components/qemu
>>>>>>>>> +++ b/components/qemu
>>>>>>>>> @@ -23,15 +23,20 @@ function qemu_build() {
>>>>>>>>>      cd "$BASEDIR"
>>>>>>>>>      git-checkout $QEMU_URL $QEMU_REVISION qemu-dir
>>>>>>>>>      cd qemu-dir
>>>>>>>>> -    ./configure --enable-xen --target-list=i386-softmmu 
>>>>>>>>> --prefix=$PREFIX \
>>>>>>>>> -        --extra-cflags="-I$INST_DIR/$PREFIX/include" \
>>>>>>>>> -        --extra-ldflags="-L$INST_DIR/$PREFIX/lib 
>>>>>>>>> -Wl,-rpath-link=$INST_DIR/$PREFIX/lib \
>>>>>>>>> +
>>>>>>>>> +    ./configure --enable-xen --target-list=i386-softmmu \
>>>>>>>>> +             --prefix=$PREFIX \
>>>>>>>>> +             --extra-cflags="-DXC_WANT_COMPAT_EVTCHN_API=1 \
>>>>>>>>> +             -DXC_WANT_COMPAT_GNTTAB_API=1 \
>>>>>>>>> +             -DXC_WANT_COMPAT_MAP_FOREIGN_API=1 \
>>>>>>>>> +                -I$INST_DIR/$PREFIX/include" \
>>>>>>>>> +             --extra-ldflags="-L$INST_DIR/$PREFIX/lib 
>>>>>>>>> -Wl,-rpath-link=$INST_DIR/$PREFIX/lib \
>>>>>>>>>                           -L$INST_DIR/$PREFIX/lib64 
>>>>>>>>> -Wl,-rpath-link=$INST_DIR/$PREFIX/lib64" \
>>>>>>>>> -        --disable-kvm \
>>>>>>>>> -        --disable-docs \
>>>>>>>>> -        --bindir=$PREFIX/lib/xen/bin \
>>>>>>>>> -        --datadir=$PREFIX/share/qemu-xen \
>>>>>>>>> -        --disable-guest-agent
>>>>>>>>> +             --bindir=$PREFIX/lib/xen/bin \
>>>>>>>>> +             --datadir=$PREFIX/share/qemu-xen \
>>>>>>>>> +             --disable-kvm \
>>>>>>>>> +             --disable-docs \
>>>>>>>>> +             --disable-guest-agent
>>>>>>>>
>>>>>>>> This is adding XC_WANT_COMPAT_EVTCHN_API=1, etc, unconditionally. If we
>>>>>>>> make this change, will raisin still be able to buil an older qemu
>>>>>>>> against an older xen?
>>>>>>>
>>>>>>> I've tested this with XEN_RELEASE set to 4.5 and 4.6, and it builds just
>>>>>>> fine.  The #define is just ignored, since neither Xen nor qemu in the
>>>>>>> 4.5 and 4.6 branches know anything about it.
>>>>>>>
>>>>>>> If part of our goal is to be a repository of the canonical way to build
>>>>>>> things, though, perhaps it would be better to have the extra flags be
>>>>>>> conditional on the value of XEN_RELEASE.
>>>>>>
>>>>>> If we are sure that it's ignored than it might be benign. Maybe we
>>>>>> should just add an in-code comment to explain why we added it though.
>>>>>
>>>>> Well really, I think that the detection should be put into the qemu
>>>>> configure scripts -- i.e., it should detect that there's the new API and
>>>>> add the appropriate #defines itself.  But that's the sort of change I
>>>>> don't think there will be a lot of enthusiasm for. :-)
>>>>
>>>> Actually there is already code in QEMU configure script for the
>>>> detection. In fact I was wondering if explicitly passing XC_WANT_* is
>>>> actually necessary. I don't think it is from QEMU POV.
>>>
>>> That code might be in qemu-upstream, but it's not in the qemu-xen trees;
>>> if you revert this bit of the patch and try to build with raisin it will
>>> fail.  That's why I even bothered to add these in in the first place;
>>> and why IanC added these runes to tools/Makefile.
>>>
>>> Anthony, can you comment more authoritatively here on what's going on?
>>
>> Yes, easy, xen-4.7 introduce a new API but qemu-xen-4.7 does not know
>> about it, so qemu-xen will fail to compile. But there are some magic
>> flags that are use to provide an compatible API and can qemu-xen
>> compile.
>>
>> QEMU have been taught about the new API and will use it, without the
>> magic flags. QEMU will actually ignore the magic flags with a bunch of
>> #undef.
>  
> Looking a bit more closely, these flags are to enable backward
> compatibility in libxc, which of course is not supposed to break any
> QEMUs, old or new. To the contrary, it helps older QEMUs to build
> properly against newer Xen versions (qemu-xen-4.7 falls in this
> category). In addition new QEMU is able to ignore these flags when it
> knows that it can use the new interface. So overall I would just pass
> them unconditionally with a comment as explanation.

Well I've already updated the patch to enable them conditionally (with a
comment), so I think I'll just use the new version. :-)

 -George


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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.