| Message ID | 1499238885-26161-23-git-send-email-pbonzini@redhat.com |
|---|---|
| State | New |
| Headers | show |
On 5 July 2017 at 08:14, Paolo Bonzini <pbonzini@redhat.com> wrote: > This will be useful when the functions are called, early in the configure > process, to filter out targets that do not support hardware acceleration. > > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> > +supported_xen_target() { > + test "$xen" = "yes" || return 1 > + glob "$1" "*-softmmu" || return 1 > + case "${1%-softmmu}:$cpu" in > + arm:arm | aarch64:aarch64 | \ > + i386:i386 | i386:x86_64 | x86_64:i386 | x86_64:x86_64) > + return 0 > + ;; This says that arm-on-arm and aarch64-on-aarch64 are supported Xen targets... > + esac > + return 1 > +} > + > if [ "$HOST_VARIANT_DIR" != "" ]; then > echo "HOST_VARIANT_DIR=$HOST_VARIANT_DIR" >> $config_target_mak > fi > -case "$target_name" in > - i386|x86_64) > - if test "$xen" = "yes" -a "$target_softmmu" = "yes" ; then > - echo "CONFIG_XEN=y" >> $config_target_mak > - if test "$xen_pci_passthrough" = yes; then > + > +if supported_xen_target $target; then > + echo "CONFIG_XEN=y" >> $config_target_mak > + if test "$xen_pci_passthrough" = yes; then ...but previously we only enabled CONFIG_XEN on i386 or x86_64 targets. Alex points out that the shippable builds now fail for aarch64 and arm. (I think that my test machines for aarch64 and arm don't fail like this because they happen not to have the Xen headers installed, so the overall "does Xen work on this host" check fails; the shippable configs do pass that test so they try to build the Xen code.) https://app.shippable.com/github/qemu/qemu/runs/267/2/console exec.o: In function `reclaim_ramblock': /root/src/github.com/qemu/qemu/exec.c:2071: undefined reference to `xen_invalidate_map_cache_entry' exec.o: In function `qemu_map_ram_ptr': /root/src/github.com/qemu/qemu/exec.c:2177: undefined reference to `xen_map_cache' /root/src/github.com/qemu/qemu/exec.c:2174: undefined reference to `xen_map_cache' exec.o: In function `qemu_ram_block_from_host': /root/src/github.com/qemu/qemu/exec.c:2242: undefined reference to `xen_ram_addr_from_mapcache' /root/src/github.com/qemu/qemu/exec.c:2242: undefined reference to `xen_ram_addr_from_mapcache' exec.o: In function `qemu_ram_ptr_length': /root/src/github.com/qemu/qemu/exec.c:2210: undefined reference to `xen_map_cache' /root/src/github.com/qemu/qemu/exec.c:2207: undefined reference to `xen_map_cache' exec.o: In function `address_space_unmap': /root/src/github.com/qemu/qemu/exec.c:3357: undefined reference to `xen_invalidate_map_cache_entry' hw/xen/xen_pt.o: In function `xen_pt_pci_read_config': /root/src/github.com/qemu/qemu/hw/xen/xen_pt.c:206: undefined reference to `xen_shutdown_fatal_error' hw/xen/xen_pt.o: In function `xen_igd_passthrough_isa_bridge_create': /root/src/github.com/qemu/qemu/hw/xen/xen_pt.c:698: undefined reference to `igd_passthrough_isa_bridge_create' hw/xen/xen_pt.o: In function `xen_pt_pci_write_config': /root/src/github.com/qemu/qemu/hw/xen/xen_pt.c:355: undefined reference to `xen_shutdown_fatal_error' hw/xen/xen_pt_config_init.o: In function `xen_pt_status_reg_init': /root/src/github.com/qemu/qemu/hw/xen/xen_pt_config_init.c:281: undefined reference to `xen_shutdown_fatal_error' /root/src/github.com/qemu/qemu/hw/xen/xen_pt_config_init.c:275: undefined reference to `xen_shutdown_fatal_error' hw/xen/xen_pt_graphics.o: In function `get_vgabios': /root/src/github.com/qemu/qemu/hw/xen/xen_pt_graphics.c:135: undefined reference to `pci_assign_dev_load_option_rom' collect2: error: ld returned 1 exit status thanks -- PMM
On 10/07/2017 17:49, Peter Maydell wrote: > On 5 July 2017 at 08:14, Paolo Bonzini <pbonzini@redhat.com> wrote: >> This will be useful when the functions are called, early in the configure >> process, to filter out targets that do not support hardware acceleration. >> >> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> > >> +supported_xen_target() { >> + test "$xen" = "yes" || return 1 >> + glob "$1" "*-softmmu" || return 1 >> + case "${1%-softmmu}:$cpu" in >> + arm:arm | aarch64:aarch64 | \ >> + i386:i386 | i386:x86_64 | x86_64:i386 | x86_64:x86_64) >> + return 0 >> + ;; > > This says that arm-on-arm and aarch64-on-aarch64 are supported > Xen targets... Hmm, this comes from my old patches. IIRC the reason for the change, when it wasn't a change (many conflicts ago) was that Xen folks were using --disable-tcg because their device model for Xen PV on ARM was actually an x86_64 QEMU. Stefano and Anthony, is this still true? If so, would it make sense to add the Xen PV machine type to qemu-system-arm---that is, is it something you can whip up easily, or should I just remove that line? Paolo > Alex points out that the shippable builds now fail for aarch64 > and arm. (I think that my test machines for aarch64 and arm > don't fail like this because they happen not to have the Xen > headers installed, so the overall "does Xen work on this host" > check fails; the shippable configs do pass that test so they > try to build the Xen code.)
On 10 July 2017 at 17:14, Paolo Bonzini <pbonzini@redhat.com> wrote: > On 10/07/2017 17:49, Peter Maydell wrote: >> On 5 July 2017 at 08:14, Paolo Bonzini <pbonzini@redhat.com> wrote: >>> This will be useful when the functions are called, early in the configure >>> process, to filter out targets that do not support hardware acceleration. >>> >>> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> >> >>> +supported_xen_target() { >>> + test "$xen" = "yes" || return 1 >>> + glob "$1" "*-softmmu" || return 1 >>> + case "${1%-softmmu}:$cpu" in >>> + arm:arm | aarch64:aarch64 | \ >>> + i386:i386 | i386:x86_64 | x86_64:i386 | x86_64:x86_64) >>> + return 0 >>> + ;; >> >> This says that arm-on-arm and aarch64-on-aarch64 are supported >> Xen targets... > > Hmm, this comes from my old patches. IIRC the reason for the change, > when it wasn't a change (many conflicts ago) was that Xen folks were > using --disable-tcg because their device model for Xen PV on ARM was > actually an x86_64 QEMU. > > Stefano and Anthony, is this still true? If so, would it make sense to > add the Xen PV machine type to qemu-system-arm---that is, is it > something you can whip up easily, or should I just remove that line? I think you should just fix configure for the moment, because this patch wasn't supposed to change anything about what we build (AIUI). We can think about changing the Xen PV on ARM build setup as a separate thing if we want to, I suspect it is more invasive than a couple of lines changing in configure. thanks -- PMM
On 10/07/2017 18:24, Peter Maydell wrote: > On 10 July 2017 at 17:14, Paolo Bonzini <pbonzini@redhat.com> wrote: >> On 10/07/2017 17:49, Peter Maydell wrote: >>> On 5 July 2017 at 08:14, Paolo Bonzini <pbonzini@redhat.com> wrote: >>>> This will be useful when the functions are called, early in the configure >>>> process, to filter out targets that do not support hardware acceleration. >>>> >>>> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> >>> >>>> +supported_xen_target() { >>>> + test "$xen" = "yes" || return 1 >>>> + glob "$1" "*-softmmu" || return 1 >>>> + case "${1%-softmmu}:$cpu" in >>>> + arm:arm | aarch64:aarch64 | \ >>>> + i386:i386 | i386:x86_64 | x86_64:i386 | x86_64:x86_64) >>>> + return 0 >>>> + ;; >>> >>> This says that arm-on-arm and aarch64-on-aarch64 are supported >>> Xen targets... >> >> Hmm, this comes from my old patches. IIRC the reason for the change, >> when it wasn't a change (many conflicts ago) was that Xen folks were >> using --disable-tcg because their device model for Xen PV on ARM was >> actually an x86_64 QEMU. >> >> Stefano and Anthony, is this still true? If so, would it make sense to >> add the Xen PV machine type to qemu-system-arm---that is, is it >> something you can whip up easily, or should I just remove that line? > > I think you should just fix configure for the moment, because > this patch wasn't supposed to change anything about what we > build (AIUI). We can think about changing the Xen PV on ARM > build setup as a separate thing if we want to, I suspect it > is more invasive than a couple of lines changing in configure. Yes, definitely more invasive. I'll prepare a fix. Paolo
On Mon, Jul 10, 2017 at 04:49:18PM +0100, Peter Maydell wrote: > On 5 July 2017 at 08:14, Paolo Bonzini <pbonzini@redhat.com> wrote: > > This will be useful when the functions are called, early in the configure > > process, to filter out targets that do not support hardware acceleration. > > > > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> > > > +supported_xen_target() { > > + test "$xen" = "yes" || return 1 > > + glob "$1" "*-softmmu" || return 1 > > + case "${1%-softmmu}:$cpu" in > > + arm:arm | aarch64:aarch64 | \ > > + i386:i386 | i386:x86_64 | x86_64:i386 | x86_64:x86_64) > > + return 0 > > + ;; > > This says that arm-on-arm and aarch64-on-aarch64 are supported > Xen targets... > > > + esac > > + return 1 > > +} > > + > > > > if [ "$HOST_VARIANT_DIR" != "" ]; then > > echo "HOST_VARIANT_DIR=$HOST_VARIANT_DIR" >> $config_target_mak > > fi > > -case "$target_name" in > > - i386|x86_64) > > - if test "$xen" = "yes" -a "$target_softmmu" = "yes" ; then > > - echo "CONFIG_XEN=y" >> $config_target_mak > > - if test "$xen_pci_passthrough" = yes; then > > + > > +if supported_xen_target $target; then > > + echo "CONFIG_XEN=y" >> $config_target_mak > > + if test "$xen_pci_passthrough" = yes; then > > ...but previously we only enabled CONFIG_XEN on i386 or x86_64 > targets. > > Alex points out that the shippable builds now fail for aarch64 > and arm. (I think that my test machines for aarch64 and arm > don't fail like this because they happen not to have the Xen > headers installed, so the overall "does Xen work on this host" > check fails; the shippable configs do pass that test so they > try to build the Xen code.) > > https://app.shippable.com/github/qemu/qemu/runs/267/2/console > > exec.o: In function `reclaim_ramblock': > /root/src/github.com/qemu/qemu/exec.c:2071: undefined reference to > `xen_invalidate_map_cache_entry' > exec.o: In function `qemu_map_ram_ptr': > /root/src/github.com/qemu/qemu/exec.c:2177: undefined reference to > `xen_map_cache' > /root/src/github.com/qemu/qemu/exec.c:2174: undefined reference to > `xen_map_cache' > exec.o: In function `qemu_ram_block_from_host': > /root/src/github.com/qemu/qemu/exec.c:2242: undefined reference to > `xen_ram_addr_from_mapcache' > /root/src/github.com/qemu/qemu/exec.c:2242: undefined reference to > `xen_ram_addr_from_mapcache' > exec.o: In function `qemu_ram_ptr_length': > /root/src/github.com/qemu/qemu/exec.c:2210: undefined reference to > `xen_map_cache' > /root/src/github.com/qemu/qemu/exec.c:2207: undefined reference to > `xen_map_cache' > exec.o: In function `address_space_unmap': > /root/src/github.com/qemu/qemu/exec.c:3357: undefined reference to > `xen_invalidate_map_cache_entry' > hw/xen/xen_pt.o: In function `xen_pt_pci_read_config': > /root/src/github.com/qemu/qemu/hw/xen/xen_pt.c:206: undefined > reference to `xen_shutdown_fatal_error' > hw/xen/xen_pt.o: In function `xen_igd_passthrough_isa_bridge_create': > /root/src/github.com/qemu/qemu/hw/xen/xen_pt.c:698: undefined > reference to `igd_passthrough_isa_bridge_create' > hw/xen/xen_pt.o: In function `xen_pt_pci_write_config': > /root/src/github.com/qemu/qemu/hw/xen/xen_pt.c:355: undefined > reference to `xen_shutdown_fatal_error' > hw/xen/xen_pt_config_init.o: In function `xen_pt_status_reg_init': > /root/src/github.com/qemu/qemu/hw/xen/xen_pt_config_init.c:281: > undefined reference to `xen_shutdown_fatal_error' > /root/src/github.com/qemu/qemu/hw/xen/xen_pt_config_init.c:275: > undefined reference to `xen_shutdown_fatal_error' > hw/xen/xen_pt_graphics.o: In function `get_vgabios': > /root/src/github.com/qemu/qemu/hw/xen/xen_pt_graphics.c:135: undefined > reference to `pci_assign_dev_load_option_rom' > collect2: error: ld returned 1 exit status Our CI also fail on this merge, QEMU build fine, be it can't be use. Error message (on arm*): qemu-system-i386: -xen-domid 1: Option not supported for this target Full log: http://logs.test-lab.xenproject.org/osstest/logs/111601/
On Mon, 10 Jul 2017, Peter Maydell wrote: > On 10 July 2017 at 17:14, Paolo Bonzini <pbonzini@redhat.com> wrote: > > On 10/07/2017 17:49, Peter Maydell wrote: > >> On 5 July 2017 at 08:14, Paolo Bonzini <pbonzini@redhat.com> wrote: > >>> This will be useful when the functions are called, early in the configure > >>> process, to filter out targets that do not support hardware acceleration. > >>> > >>> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> > >> > >>> +supported_xen_target() { > >>> + test "$xen" = "yes" || return 1 > >>> + glob "$1" "*-softmmu" || return 1 > >>> + case "${1%-softmmu}:$cpu" in > >>> + arm:arm | aarch64:aarch64 | \ > >>> + i386:i386 | i386:x86_64 | x86_64:i386 | x86_64:x86_64) > >>> + return 0 > >>> + ;; > >> > >> This says that arm-on-arm and aarch64-on-aarch64 are supported > >> Xen targets... > > > > Hmm, this comes from my old patches. IIRC the reason for the change, > > when it wasn't a change (many conflicts ago) was that Xen folks were > > using --disable-tcg because their device model for Xen PV on ARM was > > actually an x86_64 QEMU. > > > > Stefano and Anthony, is this still true? If so, would it make sense to > > add the Xen PV machine type to qemu-system-arm---that is, is it > > something you can whip up easily, or should I just remove that line? > > I think you should just fix configure for the moment, because > this patch wasn't supposed to change anything about what we > build (AIUI). We can think about changing the Xen PV on ARM > build setup as a separate thing if we want to, I suspect it > is more invasive than a couple of lines changing in configure. Let's leave the current build issue aside for a moment, given that it seems to be solved now. Today, we build qemu-system-i386 for Xen on ARM just for the xenpv machine. Using qemu-system-i386 causes all sort of confusion in our users and even distro packagers. Using qemu-system-aarch64 on ARM64 would be better. But the best solution I think it would be to build a cpu-less arch-neutral xenpv machine. Something like qemu-system-null or qemu-system-xen.
what about this RFC series? http://lists.nongnu.org/archive/html/qemu-devel/2017-07/msg02513.html On 07/10/2017 01:28 PM, Paolo Bonzini wrote: > On 10/07/2017 18:24, Peter Maydell wrote: >> On 10 July 2017 at 17:14, Paolo Bonzini <pbonzini@redhat.com> wrote: >>> On 10/07/2017 17:49, Peter Maydell wrote: >>>> On 5 July 2017 at 08:14, Paolo Bonzini <pbonzini@redhat.com> wrote: >>>>> This will be useful when the functions are called, early in the configure >>>>> process, to filter out targets that do not support hardware acceleration. >>>>> >>>>> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> >>>> >>>>> +supported_xen_target() { >>>>> + test "$xen" = "yes" || return 1 >>>>> + glob "$1" "*-softmmu" || return 1 >>>>> + case "${1%-softmmu}:$cpu" in >>>>> + arm:arm | aarch64:aarch64 | \ >>>>> + i386:i386 | i386:x86_64 | x86_64:i386 | x86_64:x86_64) >>>>> + return 0 >>>>> + ;; >>>> >>>> This says that arm-on-arm and aarch64-on-aarch64 are supported >>>> Xen targets... >>> >>> Hmm, this comes from my old patches. IIRC the reason for the change, >>> when it wasn't a change (many conflicts ago) was that Xen folks were >>> using --disable-tcg because their device model for Xen PV on ARM was >>> actually an x86_64 QEMU. >>> >>> Stefano and Anthony, is this still true? If so, would it make sense to >>> add the Xen PV machine type to qemu-system-arm---that is, is it >>> something you can whip up easily, or should I just remove that line? >> >> I think you should just fix configure for the moment, because >> this patch wasn't supposed to change anything about what we >> build (AIUI). We can think about changing the Xen PV on ARM >> build setup as a separate thing if we want to, I suspect it >> is more invasive than a couple of lines changing in configure. > > Yes, definitely more invasive. > > I'll prepare a fix. > > Paolo >
----- Original Message ----- > From: "Philippe Mathieu-Daudé" <f4bug@amsat.org> > To: "Paolo Bonzini" <pbonzini@redhat.com>, "Peter Maydell" <peter.maydell@linaro.org> > Cc: "Anthony PERARD" <anthony.perard@citrix.com>, "Stefano Stabellini" <sstabellini@kernel.org>, "Alex Bennée" > <alex.bennee@linaro.org>, "QEMU Developers" <qemu-devel@nongnu.org> > Sent: Friday, July 14, 2017 5:26:36 PM > Subject: Re: [Qemu-devel] [PULL 22/42] configure: factor out list of supported Xen/KVM/HAX targets > > what about this RFC series? > http://lists.nongnu.org/archive/html/qemu-devel/2017-07/msg02513.html Too late for 2.10, but the way to go is to define a new "xenpv" target. In fact, --disable-tcg was the prerequisite for that if I remember correctly my old discussions with Citrix folks (could it have been Wei Liu?) Paolo > On 07/10/2017 01:28 PM, Paolo Bonzini wrote: > > On 10/07/2017 18:24, Peter Maydell wrote: > >> On 10 July 2017 at 17:14, Paolo Bonzini <pbonzini@redhat.com> wrote: > >>> On 10/07/2017 17:49, Peter Maydell wrote: > >>>> On 5 July 2017 at 08:14, Paolo Bonzini <pbonzini@redhat.com> wrote: > >>>>> This will be useful when the functions are called, early in the > >>>>> configure > >>>>> process, to filter out targets that do not support hardware > >>>>> acceleration. > >>>>> > >>>>> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> > >>>> > >>>>> +supported_xen_target() { > >>>>> + test "$xen" = "yes" || return 1 > >>>>> + glob "$1" "*-softmmu" || return 1 > >>>>> + case "${1%-softmmu}:$cpu" in > >>>>> + arm:arm | aarch64:aarch64 | \ > >>>>> + i386:i386 | i386:x86_64 | x86_64:i386 | x86_64:x86_64) > >>>>> + return 0 > >>>>> + ;; > >>>> > >>>> This says that arm-on-arm and aarch64-on-aarch64 are supported > >>>> Xen targets... > >>> > >>> Hmm, this comes from my old patches. IIRC the reason for the change, > >>> when it wasn't a change (many conflicts ago) was that Xen folks were > >>> using --disable-tcg because their device model for Xen PV on ARM was > >>> actually an x86_64 QEMU. > >>> > >>> Stefano and Anthony, is this still true? If so, would it make sense to > >>> add the Xen PV machine type to qemu-system-arm---that is, is it > >>> something you can whip up easily, or should I just remove that line? > >> > >> I think you should just fix configure for the moment, because > >> this patch wasn't supposed to change anything about what we > >> build (AIUI). We can think about changing the Xen PV on ARM > >> build setup as a separate thing if we want to, I suspect it > >> is more invasive than a couple of lines changing in configure. > > > > Yes, definitely more invasive. > > > > I'll prepare a fix. > > > > Paolo > > >
diff --git a/configure b/configure index c571ad1..0f14e79 100755 --- a/configure +++ b/configure @@ -163,6 +163,50 @@ have_backend () { echo "$trace_backends" | grep "$1" >/dev/null } +glob() { + eval test -z '"${1#'"$2"'}"' +} + +supported_hax_target() { + test "$hax" = "yes" || return 1 + glob "$1" "*-softmmu" || return 1 + case "${1%-softmmu}" in + i386|x86_64) + return 0 + ;; + esac + return 1 +} + +supported_kvm_target() { + test "$kvm" = "yes" || return 1 + glob "$1" "*-softmmu" || return 1 + case "${1%-softmmu}:$cpu" in + arm:arm | aarch64:aarch64 | \ + i386:i386 | i386:x86_64 | i386:x32 | \ + x86_64:i386 | x86_64:x86_64 | x86_64:x32 | \ + mips:mips | mipsel:mips | \ + ppc:ppc | ppcemb:ppc | ppc64:ppc | \ + ppc:ppc64 | ppcemb:ppc64 | ppc64:ppc64 | \ + s390x:s390x) + return 0 + ;; + esac + return 1 +} + +supported_xen_target() { + test "$xen" = "yes" || return 1 + glob "$1" "*-softmmu" || return 1 + case "${1%-softmmu}:$cpu" in + arm:arm | aarch64:aarch64 | \ + i386:i386 | i386:x86_64 | x86_64:i386 | x86_64:x86_64) + return 0 + ;; + esac + return 1 +} + # default parameters source_path=$(dirname "$0") cpu="" @@ -6178,46 +6222,22 @@ echo "TARGET_ABI_DIR=$TARGET_ABI_DIR" >> $config_target_mak if [ "$HOST_VARIANT_DIR" != "" ]; then echo "HOST_VARIANT_DIR=$HOST_VARIANT_DIR" >> $config_target_mak fi -case "$target_name" in - i386|x86_64) - if test "$xen" = "yes" -a "$target_softmmu" = "yes" ; then - echo "CONFIG_XEN=y" >> $config_target_mak - if test "$xen_pci_passthrough" = yes; then + +if supported_xen_target $target; then + echo "CONFIG_XEN=y" >> $config_target_mak + if test "$xen_pci_passthrough" = yes; then echo "CONFIG_XEN_PCI_PASSTHROUGH=y" >> "$config_target_mak" - fi fi - ;; - *) -esac -case "$target_name" in - aarch64|arm|i386|x86_64|ppcemb|ppc|ppc64|s390x|mipsel|mips) - # Make sure the target and host cpus are compatible - if test "$kvm" = "yes" -a "$target_softmmu" = "yes" -a \ - \( "$target_name" = "$cpu" -o \ - \( "$target_name" = "ppcemb" -a "$cpu" = "ppc" \) -o \ - \( "$target_name" = "ppc64" -a "$cpu" = "ppc" \) -o \ - \( "$target_name" = "ppc" -a "$cpu" = "ppc64" \) -o \ - \( "$target_name" = "ppcemb" -a "$cpu" = "ppc64" \) -o \ - \( "$target_name" = "mipsel" -a "$cpu" = "mips" \) -o \ - \( "$target_name" = "x86_64" -a "$cpu" = "i386" \) -o \ - \( "$target_name" = "i386" -a "$cpu" = "x86_64" \) -o \ - \( "$target_name" = "x86_64" -a "$cpu" = "x32" \) -o \ - \( "$target_name" = "i386" -a "$cpu" = "x32" \) \) ; then - echo "CONFIG_KVM=y" >> $config_target_mak - if test "$vhost_net" = "yes" ; then +fi +if supported_kvm_target $target; then + echo "CONFIG_KVM=y" >> $config_target_mak + if test "$vhost_net" = "yes" ; then echo "CONFIG_VHOST_NET=y" >> $config_target_mak echo "CONFIG_VHOST_NET_TEST_$target_name=y" >> $config_host_mak - fi fi -esac -if test "$hax" = "yes" ; then - if test "$target_softmmu" = "yes" ; then - case "$target_name" in - i386|x86_64) - echo "CONFIG_HAX=y" >> $config_target_mak - ;; - esac - fi +fi +if supported_hax_target $target; then + echo "CONFIG_HAX=y" >> $config_target_mak fi if test "$target_bigendian" = "yes" ; then echo "TARGET_WORDS_BIGENDIAN=y" >> $config_target_mak
This will be useful when the functions are called, early in the configure process, to filter out targets that do not support hardware acceleration. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> --- configure | 90 ++++++++++++++++++++++++++++++++++++++------------------------- 1 file changed, 55 insertions(+), 35 deletions(-)