[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 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.

_______________________________________________
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®.