Re: [Qemu-devel] [PATCH] configure: Add pkg-config handling for libgcrypt

2022-01-07 Thread Andrea Bolognani
On Fri, Jan 07, 2022 at 12:06:47PM +, Daniel P. Berrangé wrote:
> On Fri, Jan 07, 2022 at 12:55:42PM +0100, Thomas Huth wrote:
> > On 07/01/2022 12.43, Andrea Bolognani wrote:
> > > On Thu, Aug 29, 2019 at 10:15:05AM +0100, Daniel P. Berrangé wrote:
> > > > Where are you seeing pkg-config files for libgcrypt ?
> > > >
> > > > The upstream project has (frustratingly) been hostile to any proposal to
> > > > add pkg-config support saying people should stick with their custom
> > > > libgcrypt-config tool
> > > >
> > > > https://dev.gnupg.org/T2037
> > >
> > > Resurrecting an old thread to point out that the upstream stance
> > > seems to have changed since that discussion:
> > >
> > >
> > > https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commit;h=97194b422bc89a6137f4e218d4cdee118c63e96e
> > >
> > > libgcrypt 1.9.0, released almost exactly a year ago, comes with a
> > > pkg-config file out of the box. With that in mind, I think it would
> > > make sense to re-evaluate this patch for inclusion.
> >
> > Maybe ... but we switched to Meson in between, so the patch needs to be
> > rewritten to use meson.build instead, I think.

Right. I didn't mean that the patch should be merged as-is, and I
wouldn't expect it to even apply two years later :)

> > Also it seems like version
> > 1.9 is not available in all distros yet, so someone needs to do an
> > assessment whether the distros that use an older version of libgrypt provide
> > a .pc file or not...

The original approach used the .pc file where present and used
libgcrypt-config as a fallback. Once QEMU stopped targeting all
operating system that have libgcrypt < 1.9, the fallback path could
have been dropped.

> Comes back to my question of what is the benefit of using the .pc file
> when what we have already works and is known to be portable.
>
> When using meson there is essentially zero burden to using the
> libgcrypt-config approach, because that's all handled transparently
> by meson.  This is different from the situation with configure,
> where libgcrypt-config required extra work on our side.

I didn't realize that was the case! I see now that Meson implements
special handling for libgcrypt, which is very nice indeed :)

> Overall I don't see any need to change it.

IIUC, the fact that the call currently looks like

  gcrypt = dependency('libgcrypt', version: '>=1.8',
  method: 'config-tool', ...)

means that Meson will not use the .pc file even when it's present. I
think changing method to "auto" would cause it to use the .pc file
when it's available, which is likely a better behavior.

-- 
Andrea Bolognani / Red Hat / Virtualization




Re: [Qemu-devel] [PATCH] configure: Add pkg-config handling for libgcrypt

2022-01-07 Thread Daniel P . Berrangé
On Fri, Jan 07, 2022 at 12:55:42PM +0100, Thomas Huth wrote:
> On 07/01/2022 12.43, Andrea Bolognani wrote:
> > On Thu, Aug 29, 2019 at 10:15:05AM +0100, Daniel P. Berrangé wrote:
> > > On Thu, Aug 29, 2019 at 04:53:02PM +0800, zhe...@windriver.com wrote:
> > > > libgcrypt may also be controlled by pkg-config, this patch adds 
> > > > pkg-config
> > > > handling for libgcrypt.
> > > 
> > > Where are you seeing pkg-config files for libgcrypt ?
> > > 
> > > The upstream project has (frustratingly) been hostile to any proposal to
> > > add pkg-config support saying people should stick with their custom
> > > libgcrypt-config tool
> > > 
> > > https://dev.gnupg.org/T2037
> > > 
> > > Even if this is something added by some distro downstream, what is the
> > > benefit in using it, compared with libgcrypt-confg which should already
> > > work & is portable.
> > 
> > Resurrecting an old thread to point out that the upstream stance
> > seems to have changed since that discussion:
> > 
> >
> > https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commit;h=97194b422bc89a6137f4e218d4cdee118c63e96e
> > 
> > libgcrypt 1.9.0, released almost exactly a year ago, comes with a
> > pkg-config file out of the box. With that in mind, I think it would
> > make sense to re-evaluate this patch for inclusion.
> 
> Maybe ... but we switched to Meson in between, so the patch needs to be
> rewritten to use meson.build instead, I think. Also it seems like version
> 1.9 is not available in all distros yet, so someone needs to do an
> assessment whether the distros that use an older version of libgrypt provide
> a .pc file or not...

Comes back to my question of what is the benefit of using the .pc file
when what we have already works and is known to be portable.

When using meson there is essentially zero burden to using the
libgcrypt-config approach, because that's all handled transparently
by meson.  This is different from the situation with configure,
where libgcrypt-config required extra work on our side.

Overall I don't see any need to change it.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|




Re: [Qemu-devel] [PATCH] configure: Add pkg-config handling for libgcrypt

2022-01-07 Thread Thomas Huth

On 07/01/2022 12.43, Andrea Bolognani wrote:

On Thu, Aug 29, 2019 at 10:15:05AM +0100, Daniel P. Berrangé wrote:

On Thu, Aug 29, 2019 at 04:53:02PM +0800, zhe...@windriver.com wrote:

libgcrypt may also be controlled by pkg-config, this patch adds pkg-config
handling for libgcrypt.


Where are you seeing pkg-config files for libgcrypt ?

The upstream project has (frustratingly) been hostile to any proposal to
add pkg-config support saying people should stick with their custom
libgcrypt-config tool

https://dev.gnupg.org/T2037

Even if this is something added by some distro downstream, what is the
benefit in using it, compared with libgcrypt-confg which should already
work & is portable.


Resurrecting an old thread to point out that the upstream stance
seems to have changed since that discussion:

   
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commit;h=97194b422bc89a6137f4e218d4cdee118c63e96e

libgcrypt 1.9.0, released almost exactly a year ago, comes with a
pkg-config file out of the box. With that in mind, I think it would
make sense to re-evaluate this patch for inclusion.


Maybe ... but we switched to Meson in between, so the patch needs to be 
rewritten to use meson.build instead, I think. Also it seems like version 
1.9 is not available in all distros yet, so someone needs to do an 
assessment whether the distros that use an older version of libgrypt provide 
a .pc file or not...


 Thomas




Re: [Qemu-devel] [PATCH] configure: Add pkg-config handling for libgcrypt

2022-01-07 Thread Andrea Bolognani
On Thu, Aug 29, 2019 at 10:15:05AM +0100, Daniel P. Berrangé wrote:
> On Thu, Aug 29, 2019 at 04:53:02PM +0800, zhe...@windriver.com wrote:
> > libgcrypt may also be controlled by pkg-config, this patch adds pkg-config
> > handling for libgcrypt.
>
> Where are you seeing pkg-config files for libgcrypt ?
>
> The upstream project has (frustratingly) been hostile to any proposal to
> add pkg-config support saying people should stick with their custom
> libgcrypt-config tool
>
>https://dev.gnupg.org/T2037
>
> Even if this is something added by some distro downstream, what is the
> benefit in using it, compared with libgcrypt-confg which should already
> work & is portable.

Resurrecting an old thread to point out that the upstream stance
seems to have changed since that discussion:

  
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commit;h=97194b422bc89a6137f4e218d4cdee118c63e96e

libgcrypt 1.9.0, released almost exactly a year ago, comes with a
pkg-config file out of the box. With that in mind, I think it would
make sense to re-evaluate this patch for inclusion.

-- 
Andrea Bolognani / Red Hat / Virtualization




Re: [Qemu-devel] [PATCH] configure: Define NCURSES_WIDECHAR if we're using curses

2021-06-07 Thread Daniel P . Berrangé
On Mon, Jun 07, 2021 at 02:57:41PM +0200, Laszlo Ersek wrote:
> On 06/06/21 20:13, Stefan Weil wrote:
> > Am 02.06.17 um 16:35 schrieb Peter Maydell:
> > 
> >> We want the wide character functions from the ncurses header.
> >> Unfortunately it doesn't provide them by default, but only
> >> if either:
> >>   * NCURSES_WIDECHAR is defined (for ncurses 20111030 and up)
> >>   * _XOPEN_SOURCE/_XOPEN_SOURCE_EXTENDED are suitably defined
> >>
> >> So far we have been implicitly relying on the latter, because
> >> for GNU libc when we define _GNU_SOURCE this causes libc
> >> to define the _XOPEN_SOURCE macros for us. Unfortunately
> >> this doesn't work on all libcs, because some (like OSX and
> >> musl libc) do not define _XOPEN_SOURCE when _GNU_SOURCE
> >> is defined.
> >>
> >> We can't fix this by defining _XOPEN_SOURCE ourselves, because
> >> that also means "and don't provide any functions that aren't in
> >> that standard", and not all libcs provide any way to override
> >> that to also get the non-standard functions. In particular
> >> FreeBSD has no such mechanism, and OSX's _DARWIN_C_SOURCE
> >> doesn't reenable everything (for instance getpagesize()
> >> is still not prototyped if _DARWIN_C_SOURCE and _XOPEN_SOURCE
> >> are both defined).
> >>
> >> So we have to define NCURSES_WIDECHAR. (This will only work
> >> if your ncurses is at least 20111030, as older versions
> >> don't honour this macro.)
> > 
> > 
> > I answer to this very old e-mail because I noticed today that defining
> > NCURSES_WIDECHAR does not work with the latest MacOS on M1:
> > 
> > Apple still delivers a curses.h which indicates NCURSES_VERSION "5.7"
> > (20081102). It does not know NCURSES_WIDECHAR, but support for curses
> > can be enabled with _XOPEN_SOURCE_EXTENDED=1.
> > 
> > I used this patch for git master:
> > 
> > diff --git a/meson.build b/meson.build
> > index 626cf932c1..513332a76d 100644
> > --- a/meson.build
> > +++ b/meson.build
> > @@ -606,7 +606,7 @@ if have_system and not get_option('curses').disabled()
> >  endif
> >    endforeach
> >    msg = get_option('curses').enabled() ? 'curses library not found' : ''
> > -  curses_compile_args = ['-DNCURSES_WIDECHAR']
> > +  curses_compile_args = ['-DNCURSES_WIDECHAR',
> > '-D_XOPEN_SOURCE_EXTENDED=1']
> >    if curses.found()
> >  if cc.links(curses_test, args: curses_compile_args, dependencies:
> > [curses])
> >    curses = declare_dependency(compile_args: curses_compile_args,
> > dependencies: [curses])
> > 
> > 
> > Then curses is detected and works when configure is given the right
> > PKG_CONFIG_PATH:
> > 
> > PKG_CONFIG_PATH=/opt/homebrew/Library/Homebrew/os/mac/pkgconfig/11
> > ./configure
> 
> _XOPEN_SOURCE_EXTENDED is only supposed to make a difference in SUSv2.
> If MacOS needs it, whatever, but I don't view it as a good idea for any
> other host OS.

Easy to do with

  if host_machine.system() == 'darwin'
curses_compile_args = [ '-D_XOPEN_SOURCE_EXTENDED=1']
  else
curses_compile_args = ['-DNCURSES_WIDECHAR']
  endif

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|




Re: [Qemu-devel] [PATCH] configure: Define NCURSES_WIDECHAR if we're using curses

2021-06-07 Thread Laszlo Ersek
On 06/06/21 20:13, Stefan Weil wrote:
> Am 02.06.17 um 16:35 schrieb Peter Maydell:
> 
>> We want the wide character functions from the ncurses header.
>> Unfortunately it doesn't provide them by default, but only
>> if either:
>>   * NCURSES_WIDECHAR is defined (for ncurses 20111030 and up)
>>   * _XOPEN_SOURCE/_XOPEN_SOURCE_EXTENDED are suitably defined
>>
>> So far we have been implicitly relying on the latter, because
>> for GNU libc when we define _GNU_SOURCE this causes libc
>> to define the _XOPEN_SOURCE macros for us. Unfortunately
>> this doesn't work on all libcs, because some (like OSX and
>> musl libc) do not define _XOPEN_SOURCE when _GNU_SOURCE
>> is defined.
>>
>> We can't fix this by defining _XOPEN_SOURCE ourselves, because
>> that also means "and don't provide any functions that aren't in
>> that standard", and not all libcs provide any way to override
>> that to also get the non-standard functions. In particular
>> FreeBSD has no such mechanism, and OSX's _DARWIN_C_SOURCE
>> doesn't reenable everything (for instance getpagesize()
>> is still not prototyped if _DARWIN_C_SOURCE and _XOPEN_SOURCE
>> are both defined).
>>
>> So we have to define NCURSES_WIDECHAR. (This will only work
>> if your ncurses is at least 20111030, as older versions
>> don't honour this macro.)
> 
> 
> I answer to this very old e-mail because I noticed today that defining
> NCURSES_WIDECHAR does not work with the latest MacOS on M1:
> 
> Apple still delivers a curses.h which indicates NCURSES_VERSION "5.7"
> (20081102). It does not know NCURSES_WIDECHAR, but support for curses
> can be enabled with _XOPEN_SOURCE_EXTENDED=1.
> 
> I used this patch for git master:
> 
> diff --git a/meson.build b/meson.build
> index 626cf932c1..513332a76d 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -606,7 +606,7 @@ if have_system and not get_option('curses').disabled()
>  endif
>    endforeach
>    msg = get_option('curses').enabled() ? 'curses library not found' : ''
> -  curses_compile_args = ['-DNCURSES_WIDECHAR']
> +  curses_compile_args = ['-DNCURSES_WIDECHAR',
> '-D_XOPEN_SOURCE_EXTENDED=1']
>    if curses.found()
>  if cc.links(curses_test, args: curses_compile_args, dependencies:
> [curses])
>    curses = declare_dependency(compile_args: curses_compile_args,
> dependencies: [curses])
> 
> 
> Then curses is detected and works when configure is given the right
> PKG_CONFIG_PATH:
> 
> PKG_CONFIG_PATH=/opt/homebrew/Library/Homebrew/os/mac/pkgconfig/11
> ./configure

_XOPEN_SOURCE_EXTENDED is only supposed to make a difference in SUSv2.
If MacOS needs it, whatever, but I don't view it as a good idea for any
other host OS.

Just my two cents, since I've been CC'd.

Laszlo




Re: [Qemu-devel] [PATCH] configure: Define NCURSES_WIDECHAR if we're using curses

2021-06-06 Thread Stefan Weil

Am 02.06.17 um 16:35 schrieb Peter Maydell:


We want the wide character functions from the ncurses header.
Unfortunately it doesn't provide them by default, but only
if either:
  * NCURSES_WIDECHAR is defined (for ncurses 20111030 and up)
  * _XOPEN_SOURCE/_XOPEN_SOURCE_EXTENDED are suitably defined

So far we have been implicitly relying on the latter, because
for GNU libc when we define _GNU_SOURCE this causes libc
to define the _XOPEN_SOURCE macros for us. Unfortunately
this doesn't work on all libcs, because some (like OSX and
musl libc) do not define _XOPEN_SOURCE when _GNU_SOURCE
is defined.

We can't fix this by defining _XOPEN_SOURCE ourselves, because
that also means "and don't provide any functions that aren't in
that standard", and not all libcs provide any way to override
that to also get the non-standard functions. In particular
FreeBSD has no such mechanism, and OSX's _DARWIN_C_SOURCE
doesn't reenable everything (for instance getpagesize()
is still not prototyped if _DARWIN_C_SOURCE and _XOPEN_SOURCE
are both defined).

So we have to define NCURSES_WIDECHAR. (This will only work
if your ncurses is at least 20111030, as older versions
don't honour this macro.)



I answer to this very old e-mail because I noticed today that defining 
NCURSES_WIDECHAR does not work with the latest MacOS on M1:


Apple still delivers a curses.h which indicates NCURSES_VERSION "5.7" 
(20081102). It does not know NCURSES_WIDECHAR, but support for curses 
can be enabled with _XOPEN_SOURCE_EXTENDED=1.


I used this patch for git master:

diff --git a/meson.build b/meson.build
index 626cf932c1..513332a76d 100644
--- a/meson.build
+++ b/meson.build
@@ -606,7 +606,7 @@ if have_system and not get_option('curses').disabled()
 endif
   endforeach
   msg = get_option('curses').enabled() ? 'curses library not found' : ''
-  curses_compile_args = ['-DNCURSES_WIDECHAR']
+  curses_compile_args = ['-DNCURSES_WIDECHAR', 
'-D_XOPEN_SOURCE_EXTENDED=1']

   if curses.found()
 if cc.links(curses_test, args: curses_compile_args, dependencies: 
[curses])
   curses = declare_dependency(compile_args: curses_compile_args, 
dependencies: [curses])



Then curses is detected and works when configure is given the right 
PKG_CONFIG_PATH:


PKG_CONFIG_PATH=/opt/homebrew/Library/Homebrew/os/mac/pkgconfig/11 
./configure


Regards

Stefan





Re: [Qemu-devel] [PATCH] configure: linux-user doesn't need neither fdt nor slirp

2020-02-18 Thread Laurent Vivier
Le 21/06/2019 à 15:05, Laurent Vivier a écrit :
> if softmmu is not enabled, we disable by default fdt and
> slirp as they are only used by -softmmu targets.
> 
> A side effect is the git submodules are not cloned
> if they are not needed.
> 
> Clone and build can be forced with --enable-fdt and
> --enable-slirp.
> 
> Signed-off-by: Laurent Vivier 
> ---
>  configure | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/configure b/configure
> index b091b82cb371..4b3853298c79 100755
> --- a/configure
> +++ b/configure
> @@ -4066,6 +4066,11 @@ if test "$fdt_required" = "yes"; then
>fdt=yes
>  fi
>  
> +# linux-user doesn't need fdt
> +if test -z "$fdt" -a "$softmmu" != "yes" ; then
> +fdt="no"
> +fi
> +
>  if test "$fdt" != "no" ; then
>fdt_libs="-lfdt"
># explicitly check for libfdt_env.h as it is missing in some stable 
> installs
> @@ -5923,6 +5928,11 @@ fi
>  ##
>  # check for slirp
>  
> +# linux-user doesn't need slirp
> +if test -z "$slirp" -a "$softmmu" != "yes" ; then
> +slirp="no"
> +fi
> +
>  case "$slirp" in
>"" | yes)
>  if $pkg_config slirp; then
> 

I've updated the comments according to Philippe's comments and applied
it to my linux-user branch.

Thanks,
Laurent



Re: [Qemu-devel] [PATCH] configure: Add xkbcommon configure options

2019-09-16 Thread Philippe Mathieu-Daudé
On 9/14/19 4:51 PM, James Le Cuirot wrote:
> This dependency is currently "automagic", which is bad for distributions.
> 

Fixes: 6a021536e23
Reviewed-by: Philippe Mathieu-Daudé 

> Signed-off-by: James Le Cuirot 
> ---
>  configure | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/configure b/configure
> index 30aad233d1..30544f52e6 100755
> --- a/configure
> +++ b/configure
> @@ -1521,6 +1521,10 @@ for opt do
>;;
>--disable-libpmem) libpmem=no
>;;
> +  --enable-xkbcommon) xkbcommon=yes
> +  ;;
> +  --disable-xkbcommon) xkbcommon=no
> +  ;;
>*)
>echo "ERROR: unknown option $opt"
>echo "Try '$0 --help' for more information"
> @@ -1804,6 +1808,7 @@ disabled with --disable-FEATURE, default is enabled if 
> available:
>capstonecapstone disassembler support
>debug-mutex mutex debugging support
>libpmem libpmem support
> +  xkbcommon   xkbcommon support
>  
>  NOTE: The object files are built at the place where configure is launched
>  EOF
> 




[Qemu-devel] [PATCH] configure: Add xkbcommon configure options

2019-09-14 Thread James Le Cuirot
This dependency is currently "automagic", which is bad for distributions.

Signed-off-by: James Le Cuirot 
---
 configure | 5 +
 1 file changed, 5 insertions(+)

diff --git a/configure b/configure
index 30aad233d1..30544f52e6 100755
--- a/configure
+++ b/configure
@@ -1521,6 +1521,10 @@ for opt do
   ;;
   --disable-libpmem) libpmem=no
   ;;
+  --enable-xkbcommon) xkbcommon=yes
+  ;;
+  --disable-xkbcommon) xkbcommon=no
+  ;;
   *)
   echo "ERROR: unknown option $opt"
   echo "Try '$0 --help' for more information"
@@ -1804,6 +1808,7 @@ disabled with --disable-FEATURE, default is enabled if 
available:
   capstonecapstone disassembler support
   debug-mutex mutex debugging support
   libpmem libpmem support
+  xkbcommon   xkbcommon support
 
 NOTE: The object files are built at the place where configure is launched
 EOF
-- 
2.23.0




Re: [Qemu-devel] [PATCH] configure: Add pkg-config handling for libgcrypt

2019-08-29 Thread He Zhe



On 8/29/19 5:15 PM, Daniel P. Berrangé wrote:
> On Thu, Aug 29, 2019 at 04:53:02PM +0800, zhe...@windriver.com wrote:
>> From: He Zhe 
>>
>> libgcrypt may also be controlled by pkg-config, this patch adds pkg-config
>> handling for libgcrypt.
> Where are you seeing pkg-config files for libgcrypt ?
>
> The upstream project has (frustratingly) been hostile to any proposal to
> add pkg-config support saying people should stick with their custom 
> libgcrypt-config tool
>
>https://dev.gnupg.org/T2037
>
> Even if this is something added by some distro downstream, what is the
> benefit in using it, compared with libgcrypt-confg which should already
> work & is portable.

IMHO, it could be easy for people to use pkg-config as a center to control
configurations for many different packages.

This is just an addition for qemu to be able to work in both cases. It does not
remove libgcrypt-confg and can fall back to libgcrypt-confg when pkg-config does
not work.

Zhe

>
>> Signed-off-by: He Zhe 
>> ---
>>  configure | 48 
>>  1 file changed, 40 insertions(+), 8 deletions(-)
>>
>> diff --git a/configure b/configure
>> index e44e454..0f362a7 100755
>> --- a/configure
>> +++ b/configure
>> @@ -2875,6 +2875,30 @@ has_libgcrypt() {
>>  return 0
>>  }
>>  
>> +has_libgcrypt_pkgconfig() {
>> +if ! has $pkg_config ; then
>> +return 1
>> +fi
>> +
>> +if ! $pkg_config --list-all | grep libgcrypt > /dev/null 2>&1 ; then
>> +return 1
>> +fi
>> +
>> +if test -n "$cross_prefix" ; then
>> +host=$($pkg_config --variable=host libgcrypt)
>> +if test "${host%-gnu}-" != "${cross_prefix%-gnu}" ; then
>> +print_error "host($host) does not match 
>> cross_prefix($cross_prefix)"
>> +return 1
>> +fi
>> +fi
>> +
>> +if ! $pkg_config --atleast-version=1.5.0 libgcrypt ; then
>> +print_error "libgcrypt version is $($pkg_config --modversion 
>> libgcrypt)"
>> +return 1
>> +fi
>> +
>> +return 0
>> +}
>>  
>>  if test "$nettle" != "no"; then
>>  pass="no"
>> @@ -2902,7 +2926,14 @@ fi
>>  
>>  if test "$gcrypt" != "no"; then
>>  pass="no"
>> -if has_libgcrypt; then
>> +if has_libgcrypt_pkgconfig; then
>> +gcrypt_cflags=$($pkg_config --cflags libgcrypt)
>> +if test "$static" = "yes" ; then
>> +gcrypt_libs=$($pkg_config --libs --static libgcrypt)
>> +else
>> +gcrypt_libs=$($pkg_config --libs libgcrypt)
>> +fi
>> +elif has_libgcrypt; then
>>  gcrypt_cflags=$(libgcrypt-config --cflags)
>>  gcrypt_libs=$(libgcrypt-config --libs)
>>  # Debian has removed -lgpg-error from libgcrypt-config
>> @@ -2912,15 +2943,16 @@ if test "$gcrypt" != "no"; then
>>  then
>>  gcrypt_libs="$gcrypt_libs -lgpg-error"
>>  fi
>> +fi
>>  
>> -# Link test to make sure the given libraries work (e.g for static).
>> -write_c_skeleton
>> -if compile_prog "" "$gcrypt_libs" ; then
>> -LIBS="$gcrypt_libs $LIBS"
>> -QEMU_CFLAGS="$QEMU_CFLAGS $gcrypt_cflags"
>> -pass="yes"
>> -fi
>> +# Link test to make sure the given libraries work (e.g for static).
>> +write_c_skeleton
>> +if compile_prog "" "$gcrypt_libs" ; then
>> +LIBS="$gcrypt_libs $LIBS"
>> +QEMU_CFLAGS="$QEMU_CFLAGS $gcrypt_cflags"
>> +pass="yes"
>>  fi
>> +
>>  if test "$pass" = "yes"; then
>>  gcrypt="yes"
>>  cat > $TMPC << EOF
>> -- 
>> 2.7.4
>>
> Regards,
> Daniel




[Qemu-devel] [PATCH] configure: Add pkg-config handling for libgcrypt

2019-08-29 Thread zhe.he
From: He Zhe 

libgcrypt may also be controlled by pkg-config, this patch adds pkg-config
handling for libgcrypt.

Signed-off-by: He Zhe 
---
 configure | 48 
 1 file changed, 40 insertions(+), 8 deletions(-)

diff --git a/configure b/configure
index e44e454..0f362a7 100755
--- a/configure
+++ b/configure
@@ -2875,6 +2875,30 @@ has_libgcrypt() {
 return 0
 }
 
+has_libgcrypt_pkgconfig() {
+if ! has $pkg_config ; then
+return 1
+fi
+
+if ! $pkg_config --list-all | grep libgcrypt > /dev/null 2>&1 ; then
+return 1
+fi
+
+if test -n "$cross_prefix" ; then
+host=$($pkg_config --variable=host libgcrypt)
+if test "${host%-gnu}-" != "${cross_prefix%-gnu}" ; then
+print_error "host($host) does not match 
cross_prefix($cross_prefix)"
+return 1
+fi
+fi
+
+if ! $pkg_config --atleast-version=1.5.0 libgcrypt ; then
+print_error "libgcrypt version is $($pkg_config --modversion 
libgcrypt)"
+return 1
+fi
+
+return 0
+}
 
 if test "$nettle" != "no"; then
 pass="no"
@@ -2902,7 +2926,14 @@ fi
 
 if test "$gcrypt" != "no"; then
 pass="no"
-if has_libgcrypt; then
+if has_libgcrypt_pkgconfig; then
+gcrypt_cflags=$($pkg_config --cflags libgcrypt)
+if test "$static" = "yes" ; then
+gcrypt_libs=$($pkg_config --libs --static libgcrypt)
+else
+gcrypt_libs=$($pkg_config --libs libgcrypt)
+fi
+elif has_libgcrypt; then
 gcrypt_cflags=$(libgcrypt-config --cflags)
 gcrypt_libs=$(libgcrypt-config --libs)
 # Debian has removed -lgpg-error from libgcrypt-config
@@ -2912,15 +2943,16 @@ if test "$gcrypt" != "no"; then
 then
 gcrypt_libs="$gcrypt_libs -lgpg-error"
 fi
+fi
 
-# Link test to make sure the given libraries work (e.g for static).
-write_c_skeleton
-if compile_prog "" "$gcrypt_libs" ; then
-LIBS="$gcrypt_libs $LIBS"
-QEMU_CFLAGS="$QEMU_CFLAGS $gcrypt_cflags"
-pass="yes"
-fi
+# Link test to make sure the given libraries work (e.g for static).
+write_c_skeleton
+if compile_prog "" "$gcrypt_libs" ; then
+   LIBS="$gcrypt_libs $LIBS"
+   QEMU_CFLAGS="$QEMU_CFLAGS $gcrypt_cflags"
+   pass="yes"
 fi
+
 if test "$pass" = "yes"; then
 gcrypt="yes"
 cat > $TMPC << EOF
-- 
2.7.4




[Qemu-devel] [PATCH] configure: Add pkg-config handling for libgcrypt

2019-08-29 Thread zhe.he
From: He Zhe 

libgcrypt may also be controlled by pkg-config, this patch adds pkg-config
handling for libgcrypt.

Signed-off-by: He Zhe 
---
 configure | 48 
 1 file changed, 40 insertions(+), 8 deletions(-)

diff --git a/configure b/configure
index e44e454..0f362a7 100755
--- a/configure
+++ b/configure
@@ -2875,6 +2875,30 @@ has_libgcrypt() {
 return 0
 }
 
+has_libgcrypt_pkgconfig() {
+if ! has $pkg_config ; then
+return 1
+fi
+
+if ! $pkg_config --list-all | grep libgcrypt > /dev/null 2>&1 ; then
+return 1
+fi
+
+if test -n "$cross_prefix" ; then
+host=$($pkg_config --variable=host libgcrypt)
+if test "${host%-gnu}-" != "${cross_prefix%-gnu}" ; then
+print_error "host($host) does not match 
cross_prefix($cross_prefix)"
+return 1
+fi
+fi
+
+if ! $pkg_config --atleast-version=1.5.0 libgcrypt ; then
+print_error "libgcrypt version is $($pkg_config --modversion 
libgcrypt)"
+return 1
+fi
+
+return 0
+}
 
 if test "$nettle" != "no"; then
 pass="no"
@@ -2902,7 +2926,14 @@ fi
 
 if test "$gcrypt" != "no"; then
 pass="no"
-if has_libgcrypt; then
+if has_libgcrypt_pkgconfig; then
+gcrypt_cflags=$($pkg_config --cflags libgcrypt)
+if test "$static" = "yes" ; then
+gcrypt_libs=$($pkg_config --libs --static libgcrypt)
+else
+gcrypt_libs=$($pkg_config --libs libgcrypt)
+fi
+elif has_libgcrypt; then
 gcrypt_cflags=$(libgcrypt-config --cflags)
 gcrypt_libs=$(libgcrypt-config --libs)
 # Debian has removed -lgpg-error from libgcrypt-config
@@ -2912,15 +2943,16 @@ if test "$gcrypt" != "no"; then
 then
 gcrypt_libs="$gcrypt_libs -lgpg-error"
 fi
+fi
 
-# Link test to make sure the given libraries work (e.g for static).
-write_c_skeleton
-if compile_prog "" "$gcrypt_libs" ; then
-LIBS="$gcrypt_libs $LIBS"
-QEMU_CFLAGS="$QEMU_CFLAGS $gcrypt_cflags"
-pass="yes"
-fi
+# Link test to make sure the given libraries work (e.g for static).
+write_c_skeleton
+if compile_prog "" "$gcrypt_libs" ; then
+   LIBS="$gcrypt_libs $LIBS"
+   QEMU_CFLAGS="$QEMU_CFLAGS $gcrypt_cflags"
+   pass="yes"
 fi
+
 if test "$pass" = "yes"; then
 gcrypt="yes"
 cat > $TMPC << EOF
-- 
2.7.4




Re: [Qemu-devel] [PATCH] configure: Add pkg-config handling for libgcrypt

2019-08-29 Thread Daniel P . Berrangé
On Thu, Aug 29, 2019 at 05:26:49PM +0800, He Zhe wrote:
> 
> 
> On 8/29/19 5:15 PM, Daniel P. Berrangé wrote:
> > On Thu, Aug 29, 2019 at 04:53:02PM +0800, zhe...@windriver.com wrote:
> >> From: He Zhe 
> >>
> >> libgcrypt may also be controlled by pkg-config, this patch adds pkg-config
> >> handling for libgcrypt.
> > Where are you seeing pkg-config files for libgcrypt ?
> >
> > The upstream project has (frustratingly) been hostile to any proposal to
> > add pkg-config support saying people should stick with their custom 
> > libgcrypt-config tool
> >
> >https://dev.gnupg.org/T2037
> >
> > Even if this is something added by some distro downstream, what is the
> > benefit in using it, compared with libgcrypt-confg which should already
> > work & is portable.
> 
> IMHO, it could be easy for people to use pkg-config as a center to control
> configurations for many different packages.
> 
> This is just an addition for qemu to be able to work in both cases. It does 
> not
> remove libgcrypt-confg and can fall back to libgcrypt-confg when pkg-config 
> does
> not work.

The addition has a maint cost associated with it, since we have have two
different ways to achieve the same thing. When only one of the approaches
is provided by upstream, the other is not going to be widely tested. In
maintaining packages in Fedora which rely on pkg-config files that are
not upstream, we've seen frequent breakage when. So my preference is
stick with what we have that is supported by upstream gcrypt.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|



Re: [Qemu-devel] [PATCH] configure: Add pkg-config handling for libgcrypt

2019-08-29 Thread Daniel P . Berrangé
On Thu, Aug 29, 2019 at 04:53:02PM +0800, zhe...@windriver.com wrote:
> From: He Zhe 
> 
> libgcrypt may also be controlled by pkg-config, this patch adds pkg-config
> handling for libgcrypt.

Where are you seeing pkg-config files for libgcrypt ?

The upstream project has (frustratingly) been hostile to any proposal to
add pkg-config support saying people should stick with their custom 
libgcrypt-config tool

   https://dev.gnupg.org/T2037

Even if this is something added by some distro downstream, what is the
benefit in using it, compared with libgcrypt-confg which should already
work & is portable.

> 
> Signed-off-by: He Zhe 
> ---
>  configure | 48 
>  1 file changed, 40 insertions(+), 8 deletions(-)
> 
> diff --git a/configure b/configure
> index e44e454..0f362a7 100755
> --- a/configure
> +++ b/configure
> @@ -2875,6 +2875,30 @@ has_libgcrypt() {
>  return 0
>  }
>  
> +has_libgcrypt_pkgconfig() {
> +if ! has $pkg_config ; then
> +return 1
> +fi
> +
> +if ! $pkg_config --list-all | grep libgcrypt > /dev/null 2>&1 ; then
> +return 1
> +fi
> +
> +if test -n "$cross_prefix" ; then
> +host=$($pkg_config --variable=host libgcrypt)
> +if test "${host%-gnu}-" != "${cross_prefix%-gnu}" ; then
> +print_error "host($host) does not match 
> cross_prefix($cross_prefix)"
> +return 1
> +fi
> +fi
> +
> +if ! $pkg_config --atleast-version=1.5.0 libgcrypt ; then
> +print_error "libgcrypt version is $($pkg_config --modversion 
> libgcrypt)"
> +return 1
> +fi
> +
> +return 0
> +}
>  
>  if test "$nettle" != "no"; then
>  pass="no"
> @@ -2902,7 +2926,14 @@ fi
>  
>  if test "$gcrypt" != "no"; then
>  pass="no"
> -if has_libgcrypt; then
> +if has_libgcrypt_pkgconfig; then
> +gcrypt_cflags=$($pkg_config --cflags libgcrypt)
> +if test "$static" = "yes" ; then
> +gcrypt_libs=$($pkg_config --libs --static libgcrypt)
> +else
> +gcrypt_libs=$($pkg_config --libs libgcrypt)
> +fi
> +elif has_libgcrypt; then
>  gcrypt_cflags=$(libgcrypt-config --cflags)
>  gcrypt_libs=$(libgcrypt-config --libs)
>  # Debian has removed -lgpg-error from libgcrypt-config
> @@ -2912,15 +2943,16 @@ if test "$gcrypt" != "no"; then
>  then
>  gcrypt_libs="$gcrypt_libs -lgpg-error"
>  fi
> +fi
>  
> -# Link test to make sure the given libraries work (e.g for static).
> -write_c_skeleton
> -if compile_prog "" "$gcrypt_libs" ; then
> -LIBS="$gcrypt_libs $LIBS"
> -QEMU_CFLAGS="$QEMU_CFLAGS $gcrypt_cflags"
> -pass="yes"
> -fi
> +# Link test to make sure the given libraries work (e.g for static).
> +write_c_skeleton
> +if compile_prog "" "$gcrypt_libs" ; then
> + LIBS="$gcrypt_libs $LIBS"
> + QEMU_CFLAGS="$QEMU_CFLAGS $gcrypt_cflags"
> + pass="yes"
>  fi
> +
>  if test "$pass" = "yes"; then
>  gcrypt="yes"
>  cat > $TMPC << EOF
> -- 
> 2.7.4
> 

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|



Re: [Qemu-devel] [PATCH] configure: more resilient Python version capture

2019-08-26 Thread Cleber Rosa
On Sat, Aug 24, 2019 at 07:32:24AM +, tony.ngu...@bt.com wrote:
> > -python_version=$($python -V 2>&1 | sed -e 's/Python\ //')
> > +python_version=$(python2 -c 'import sys; print("%d.%d.%d" % 
> > (sys.version_info[0], sys.version_info[1], sys.version_info[2]))' 
> > 2>/dev/null)
> 
> On a Python 3 only system, configure will no longer print the version.
>

Oh my, this is not what I intended... gross late Friday mistake.  I meant:

python_version=$($python -c 'import sys; print("%d.%d.%d" % 
(sys.version_info[0], sys.version_info[1], sys.version_info[2]))' 2>/dev/null)

- Cleber.



Re: [Qemu-devel] [PATCH] configure: more resilient Python version capture

2019-08-25 Thread Peter Maydell
On Sat, 24 Aug 2019 at 08:32,  wrote:
> > -echo "PYTHON_VERSION=$python_version" >> $config_host_mak
> > +echo "PYTHON2=$python2" >> $config_host_mak
> ...
> > -ifneq ($(findstring v2,"v$(PYTHON_VERSION)"),v2)
> > +ifneq ($(PYTHON2),y)
>
> Succinctly, if Python 3.
>
> We can further ween the world off Python 2 by replacing python2="y" for
> python3="y" and PYTHON2 for PYTHON3.

I don't think it's a big deal which way round we do this, because
once we drop Python 2 support the if and the variable will just
be deleted entirely.

thanks
-- PMM



Re: [Qemu-devel] [PATCH] configure: more resilient Python version capture

2019-08-24 Thread tony.nguyen
> -python_version=$($python -V 2>&1 | sed -e 's/Python\ //')
> +python_version=$(python2 -c 'import sys; print("%d.%d.%d" % 
> (sys.version_info[0], sys.version_info[1], sys.version_info[2]))' 2>/dev/null)

On a Python 3 only system, configure will no longer print the version.

e.g. 
/* snip */
install   install
pythonpython3 -B ()
slirp support git 
/* snip */

> @@ -6511,6 +6511,7 @@ if ! $python -c 'import sys; sys.exit(sys.version_info 
> < (3,0))'; then
>echo
>echo "warning: Python 2 support is deprecated" >&2 
>echo "warning: Python 3 will be required for building future versions of 
> QEMU" >&2 
> +  python2="y"
>  fi  
...
> -echo "PYTHON_VERSION=$python_version" >> $config_host_mak
> +echo "PYTHON2=$python2" >> $config_host_mak
...
> -ifneq ($(findstring v2,"v$(PYTHON_VERSION)"),v2)
> +ifneq ($(PYTHON2),y)

Succinctly, if Python 3.

We can further ween the world off Python 2 by replacing python2="y" for 
python3="y" and PYTHON2 for PYTHON3.


[Qemu-devel] [PATCH] configure: more resilient Python version capture

2019-08-23 Thread Cleber Rosa
The current approach to capture the Python version is fragile, as it
was demonstrated by a very specific build of Python 3 on Fedora 29
that, under non-interactive shells would print multiline version
information.

The (badly) stripped version output would be sent to config-host.mak,
producing bad syntax and rendering the makefiles unusable.  Now, the
Python versions is printed by configure, but only a simple (and better
controlled variable) indicating whether the build system is using
Python 2 is kept on config-host.mak.

Signed-off-by: Cleber Rosa 
---
 configure  | 5 +++--
 tests/Makefile.include | 2 +-
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/configure b/configure
index e44e454c43..90b29037ab 100755
--- a/configure
+++ b/configure
@@ -1864,7 +1864,7 @@ if ! $python -c 'import sys; sys.exit(sys.version_info < 
(2,7))'; then
 fi
 
 # Preserve python version since some functionality is dependent on it
-python_version=$($python -V 2>&1 | sed -e 's/Python\ //')
+python_version=$(python2 -c 'import sys; print("%d.%d.%d" % 
(sys.version_info[0], sys.version_info[1], sys.version_info[2]))' 2>/dev/null)
 
 # Suppress writing compiled files
 python="$python -B"
@@ -6511,6 +6511,7 @@ if ! $python -c 'import sys; sys.exit(sys.version_info < 
(3,0))'; then
   echo
   echo "warning: Python 2 support is deprecated" >&2
   echo "warning: Python 3 will be required for building future versions of 
QEMU" >&2
+  python2="y"
 fi
 
 config_host_mak="config-host.mak"
@@ -7333,7 +7334,7 @@ echo "INSTALL_DATA=$install -c -m 0644" >> 
$config_host_mak
 echo "INSTALL_PROG=$install -c -m 0755" >> $config_host_mak
 echo "INSTALL_LIB=$install -c -m 0644" >> $config_host_mak
 echo "PYTHON=$python" >> $config_host_mak
-echo "PYTHON_VERSION=$python_version" >> $config_host_mak
+echo "PYTHON2=$python2" >> $config_host_mak
 echo "CC=$cc" >> $config_host_mak
 if $iasl -h > /dev/null 2>&1; then
   echo "IASL=$iasl" >> $config_host_mak
diff --git a/tests/Makefile.include b/tests/Makefile.include
index 49684fd4f4..f5ac09549c 100644
--- a/tests/Makefile.include
+++ b/tests/Makefile.include
@@ -1135,7 +1135,7 @@ TESTS_RESULTS_DIR=$(BUILD_DIR)/tests/results
 AVOCADO_SHOW=app
 AVOCADO_TAGS=$(patsubst %-softmmu,-t arch:%, $(filter 
%-softmmu,$(TARGET_DIRS)))
 
-ifneq ($(findstring v2,"v$(PYTHON_VERSION)"),v2)
+ifneq ($(PYTHON2),y)
 $(TESTS_VENV_DIR): $(TESTS_VENV_REQ)
$(call quiet-command, \
 $(PYTHON) -m venv --system-site-packages $@, \
-- 
2.21.0




Re: [Qemu-devel] [PATCH] configure: fix sdl detection using sdl2-config

2019-08-21 Thread Laurent Vivier
Le 11/07/2019 à 00:55, Carlo Marcelo Arenas Belón a écrit :
> If SDL2 is requested but pkg-config doesn't have a module for it
> configure should fallback to use sdl*-config, but wasn't able to
> because and old variable (from SDL) was being used by mistake.
> 
> Correct the variable name and complete other related changes so
> there are no more references to the old SDL.
> 
> Fixes: 0015ca5cbabe ("ui: remove support for SDL1.2 in favour of SDL2")
> Signed-off-by: Carlo Marcelo Arenas Belón 
> ---
>  configure | 9 -
>  1 file changed, 4 insertions(+), 5 deletions(-)
> 
> diff --git a/configure b/configure
> index 4983c8b533..0f88ba98a6 100755
> --- a/configure
> +++ b/configure
> @@ -3016,15 +3016,15 @@ fi
>  ##
>  # SDL probe
>  
> -# Look for sdl configuration program (pkg-config or sdl-config).  Try
> -# sdl-config even without cross prefix, and favour pkg-config over 
> sdl-config.
> +# Look for sdl configuration program (pkg-config or sdl2-config).  Try
> +# sdl2-config even without cross prefix, and favour pkg-config over 
> sdl2-config.
>  
>  sdl_probe ()
>  {
>if $pkg_config sdl2 --exists; then
>  sdlconfig="$pkg_config sdl2"
>  sdlversion=$($sdlconfig --modversion 2>/dev/null)
> -  elif has ${sdl_config}; then
> +  elif has "$sdl2_config"; then
>  sdlconfig="$sdl2_config"
>  sdlversion=$($sdlconfig --version)
>else
> @@ -3035,7 +3035,7 @@ sdl_probe ()
>  # no need to do the rest
>  return
>fi
> -  if test -n "$cross_prefix" && test "$(basename "$sdlconfig")" = 
> sdl-config; then
> +  if test -n "$cross_prefix" && test "$(basename "$sdlconfig")" = 
> sdl2-config; then
>  echo warning: using "\"$sdlconfig\"" to detect cross-compiled sdl >&2
>fi
>  
> @@ -8019,7 +8019,6 @@ preserve_env PKG_CONFIG
>  preserve_env PKG_CONFIG_LIBDIR
>  preserve_env PKG_CONFIG_PATH
>  preserve_env PYTHON
> -preserve_env SDL_CONFIG
>  preserve_env SDL2_CONFIG
>  preserve_env SMBD
>  preserve_env STRIP
> 

Applied to my trivial-patches branch.

Thanks,
Laurent





Re: [Qemu-devel] [PATCH] configure: remove AUTOCONF_HOST

2019-08-06 Thread no-reply
Patchew URL: 
https://patchew.org/QEMU/1565075472-15106-1-git-send-email-pbonz...@redhat.com/



Hi,

This series failed the asan build test. Please find the testing commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.

=== TEST SCRIPT BEGIN ===
#!/bin/bash
make docker-image-fedora V=1 NETWORK=1
time make docker-test-debug@fedora TARGET_LIST=x86_64-softmmu J=14 NETWORK=1
=== TEST SCRIPT END ===

PASS 32 test-opts-visitor /visitor/opts/range/beyond
PASS 33 test-opts-visitor /visitor/opts/dict/unvisited
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  
tests/test-coroutine -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl 
--test-name="test-coroutine" 
==7961==WARNING: ASan doesn't fully support makecontext/swapcontext functions 
and may produce false positives in some cases!
PASS 1 test-coroutine /basic/no-dangling-access
PASS 2 test-coroutine /basic/lifecycle
PASS 3 test-coroutine /basic/yield
==7961==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top: 
0x7ffeb6d86000; bottom 0x7f0a67bf8000; size: 0x00f44f18e000 (1049299050496)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
PASS 4 test-coroutine /basic/nesting
---
PASS 1 fdc-test /x86_64/fdc/cmos
PASS 2 fdc-test /x86_64/fdc/no_media_on_start
PASS 3 fdc-test /x86_64/fdc/read_without_media
==7970==WARNING: ASan doesn't fully support makecontext/swapcontext functions 
and may produce false positives in some cases!
PASS 4 fdc-test /x86_64/fdc/media_change
PASS 5 fdc-test /x86_64/fdc/sense_interrupt
PASS 6 fdc-test /x86_64/fdc/relative_seek
---
PASS 11 test-aio /aio/event/wait
PASS 12 test-aio /aio/event/flush
PASS 13 test-aio /aio/event/wait/no-flush-cb
==7990==WARNING: ASan doesn't fully support makecontext/swapcontext functions 
and may produce false positives in some cases!
PASS 14 test-aio /aio/timer/schedule
PASS 15 test-aio /aio/coroutine/queue-chaining
PASS 16 test-aio /aio-gsource/flush
---
PASS 28 test-aio /aio-gsource/timer/schedule
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  
tests/test-aio-multithread -m=quick -k --tap < /dev/null | 
./scripts/tap-driver.pl --test-name="test-aio-multithread" 
PASS 1 test-aio-multithread /aio/multi/lifecycle
==7996==WARNING: ASan doesn't fully support makecontext/swapcontext functions 
and may produce false positives in some cases!
PASS 2 test-aio-multithread /aio/multi/schedule
PASS 12 fdc-test /x86_64/fdc/read_no_dma_19
PASS 3 test-aio-multithread /aio/multi/mutex/contended
PASS 13 fdc-test /x86_64/fdc/fuzz-registers
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  
QTEST_QEMU_BINARY=x86_64-softmmu/qemu-system-x86_64 QTEST_QEMU_IMG=qemu-img 
tests/ide-test -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl 
--test-name="ide-test" 
==8024==WARNING: ASan doesn't fully support makecontext/swapcontext functions 
and may produce false positives in some cases!
PASS 4 test-aio-multithread /aio/multi/mutex/handoff
PASS 1 ide-test /x86_64/ide/identify
==8036==WARNING: ASan doesn't fully support makecontext/swapcontext functions 
and may produce false positives in some cases!
PASS 5 test-aio-multithread /aio/multi/mutex/mcs
PASS 2 ide-test /x86_64/ide/flush
PASS 6 test-aio-multithread /aio/multi/mutex/pthread
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  
tests/test-throttle -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl 
--test-name="test-throttle" 
==8047==WARNING: ASan doesn't fully support makecontext/swapcontext functions 
and may produce false positives in some cases!
PASS 1 test-throttle /throttle/leak_bucket
PASS 2 test-throttle /throttle/compute_wait
PASS 3 test-throttle /throttle/init
---
PASS 6 test-throttle /throttle/detach_attach
PASS 7 test-throttle /throttle/config_functions
PASS 8 test-throttle /throttle/accounting
==8053==WARNING: ASan doesn't fully support makecontext/swapcontext functions 
and may produce false positives in some cases!
PASS 9 test-throttle /throttle/groups
PASS 10 test-throttle /throttle/config/enabled
PASS 11 test-throttle /throttle/config/conflicting
---
PASS 15 test-throttle /throttle/config/iops_size
PASS 3 ide-test /x86_64/ide/bmdma/simple_rw
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  
tests/test-thread-pool -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl 
--test-name="test-thread-pool" 
==8059==WARNING: ASan doesn't fully support makecontext/swapcontext functions 
and may produce false positives in some cases!
PASS 1 test-thread-pool /thread-pool/submit
PASS 2 test-thread-pool /thread-pool/submit-aio
==8061==WARNING: ASan doesn't fully support makecontext/swapcontext functions 
and may produce false positives in some cases!
PASS 3 test-thread-pool /thread-pool/submit-co
PASS 4 test-thread-pool /thread-pool/submit-many
PASS 4 ide-test /x86_64/ide/bmdma/trim
==8093==WARNING: ASan doesn't fully support makecontext/swapcontext functions 

[Qemu-devel] [PATCH] configure: remove AUTOCONF_HOST

2019-08-06 Thread Paolo Bonzini
From: Marc-André Lureau 

This is a left-over from commit
c12b6d70e384c769ca372e15ffd19b3e9f563662 ("pixman: drop submodule")

Signed-off-by: Marc-André Lureau 
Signed-off-by: Paolo Bonzini 
---
 configure | 5 -
 1 file changed, 5 deletions(-)

diff --git a/configure b/configure
index c5a5b44..ae70780 100755
--- a/configure
+++ b/configure
@@ -7346,11 +7346,6 @@ if test "$sparse" = "yes" ; then
   echo "HOST_CC  := REAL_CC=\"\$(HOST_CC)\" cgcc"  >> $config_host_mak
   echo "QEMU_CFLAGS  += -Wbitwise -Wno-transparent-union -Wno-old-initializer 
-Wno-non-pointer-null" >> $config_host_mak
 fi
-if test "$cross_prefix" != ""; then
-  echo "AUTOCONF_HOST := --host=${cross_prefix%-}" >> $config_host_mak
-else
-  echo "AUTOCONF_HOST := " >> $config_host_mak
-fi
 echo "LDFLAGS=$LDFLAGS" >> $config_host_mak
 echo "LDFLAGS_NOPIE=$LDFLAGS_NOPIE" >> $config_host_mak
 echo "QEMU_LDFLAGS=$QEMU_LDFLAGS" >> $config_host_mak
-- 
1.8.3.1




Re: [Qemu-devel] [PATCH] configure: remove AUTOCONF_HOST

2019-07-23 Thread Philippe Mathieu-Daudé
On 7/23/19 2:16 PM, Marc-André Lureau wrote:
> This is a left-over from commit
> c12b6d70e384c769ca372e15ffd19b3e9f563662 ("pixman: drop submodule")
> 
> Signed-off-by: Marc-André Lureau 
> ---
>  configure | 5 -
>  1 file changed, 5 deletions(-)
> 
> diff --git a/configure b/configure
> index ad0b8582bf..82c65ab46a 100755
> --- a/configure
> +++ b/configure
> @@ -7351,11 +7351,6 @@ if test "$sparse" = "yes" ; then
>echo "HOST_CC  := REAL_CC=\"\$(HOST_CC)\" cgcc"  >> $config_host_mak
>echo "QEMU_CFLAGS  += -Wbitwise -Wno-transparent-union 
> -Wno-old-initializer -Wno-non-pointer-null" >> $config_host_mak
>  fi
> -if test "$cross_prefix" != ""; then
> -  echo "AUTOCONF_HOST := --host=${cross_prefix%-}" >> $config_host_mak
> -else
> -  echo "AUTOCONF_HOST := " >> $config_host_mak
> -fi
>  echo "LDFLAGS=$LDFLAGS" >> $config_host_mak
>  echo "LDFLAGS_NOPIE=$LDFLAGS_NOPIE" >> $config_host_mak
>  echo "QEMU_LDFLAGS=$QEMU_LDFLAGS" >> $config_host_mak
> 

Reviewed-by: Philippe Mathieu-Daudé 



[Qemu-devel] [PATCH] configure: remove AUTOCONF_HOST

2019-07-23 Thread Marc-André Lureau
This is a left-over from commit
c12b6d70e384c769ca372e15ffd19b3e9f563662 ("pixman: drop submodule")

Signed-off-by: Marc-André Lureau 
---
 configure | 5 -
 1 file changed, 5 deletions(-)

diff --git a/configure b/configure
index ad0b8582bf..82c65ab46a 100755
--- a/configure
+++ b/configure
@@ -7351,11 +7351,6 @@ if test "$sparse" = "yes" ; then
   echo "HOST_CC  := REAL_CC=\"\$(HOST_CC)\" cgcc"  >> $config_host_mak
   echo "QEMU_CFLAGS  += -Wbitwise -Wno-transparent-union -Wno-old-initializer 
-Wno-non-pointer-null" >> $config_host_mak
 fi
-if test "$cross_prefix" != ""; then
-  echo "AUTOCONF_HOST := --host=${cross_prefix%-}" >> $config_host_mak
-else
-  echo "AUTOCONF_HOST := " >> $config_host_mak
-fi
 echo "LDFLAGS=$LDFLAGS" >> $config_host_mak
 echo "LDFLAGS_NOPIE=$LDFLAGS_NOPIE" >> $config_host_mak
 echo "QEMU_LDFLAGS=$QEMU_LDFLAGS" >> $config_host_mak
-- 
2.22.0.545.g9c9b961d7e




Re: [Qemu-devel] [PATCH] configure: Define target access alignment in configure

2019-07-19 Thread Paolo Bonzini
On 19/07/19 11:17, Aleksandar Markovic wrote:
> 
> On Jul 18, 2019 11:55 AM, "Paolo Bonzini"  > wrote:
>>
>> On 18/07/19 08:01, tony.ngu...@bt.com  wrote:
>> > This patch moves the define of target access alignment earlier from
>> > target/foo/cpu.h to configure.
>> >
>> > Suggested in Richard Henderson's reply to "[PATCH 1/4] tcg: TCGMemOp
> is now
>> > accelerator independent MemOp"
>> >
>> > Signed-off-by: Tony Nguyen  >
>> > ---
>> >  configure             | 12 ++--
>> >  include/exec/poison.h |  1 +
>> >  include/qom/cpu.h     |  2 +-
>> >  target/alpha/cpu.h    |  2 --
>> >  target/hppa/cpu.h     |  1 -
>> >  target/mips/cpu.h     |  2 --
>> >  target/sh4/cpu.h      |  2 --
>> >  target/sparc/cpu.h    |  2 --
>> >  target/xtensa/cpu.h   |  2 --
>> >  tcg/tcg.c             |  2 +-
>> >  tcg/tcg.h             |  8 +---
>> >  11 files changed, 18 insertions(+), 18 deletions(-)
>> >
>> > diff --git a/configure b/configure
>> > index eb635c3b9a..c07687c656 100755
>> > --- a/configure
>> > +++ b/configure
>> > @@ -7424,11 +7424,16 @@ for target in $target_list; do
>> >  target_dir="$target"
>> >  config_target_mak=$target_dir/config-target.mak
>> >  target_name=$(echo $target | cut -d '-' -f 1)
>> > +target_aligned_only="no"
>> > +case "$target_name" in
>> > + 
> alpha|hppa|mips64el|mips64|mipsel|mips|mipsn32|mipsn32el|sh4|sh4eb|sparc|sparc64|sparc32plus|xtensa|xtensaeb)
>> > +  target_aligned_only="yes"
>> > +  ;;
>> > +esac
>> >  target_bigendian="no"
>> > -
>> >  case "$target_name" in
>> >   
> armeb|aarch64_be|hppa|lm32|m68k|microblaze|mips|mipsn32|mips64|moxie|or1k|ppc|ppc64|ppc64abi32|s390x|sh4eb|sparc|sparc64|sparc32plus|xtensaeb)
>> > -  target_bigendian=yes
>> > +  target_bigendian="yes"
>> >    ;;
>> >  esac
>> >  target_softmmu="no"
>> > @@ -7710,6 +7715,9 @@ fi
>> >  if supported_whpx_target $target; then
>> >      echo "CONFIG_WHPX=y" >> $config_target_mak
>> >  fi
>> > +if test "$target_aligned_only" = "yes" ; then
>> > +  echo "TARGET_ALIGNED_ONLY=y" >> $config_target_mak
>> > +fi
>> >  if test "$target_bigendian" = "yes" ; then
>> >    echo "TARGET_WORDS_BIGENDIAN=y" >> $config_target_mak
>> >  fi
>> > diff --git a/include/exec/poison.h b/include/exec/poison.h
>> > index b862320fa6..955eb863ab 100644
>> > --- a/include/exec/poison.h
>> > +++ b/include/exec/poison.h
>> > @@ -35,6 +35,7 @@
>> >  #pragma GCC poison TARGET_UNICORE32
>> >  #pragma GCC poison TARGET_XTENSA
>> > 
>> > +#pragma GCC poison TARGET_ALIGNED_ONLY
>> >  #pragma GCC poison TARGET_HAS_BFLT
>> >  #pragma GCC poison TARGET_NAME
>> >  #pragma GCC poison TARGET_SUPPORTS_MTTCG
>> > diff --git a/include/qom/cpu.h b/include/qom/cpu.h
>> > index 5ee0046b62..9b50b73339 100644
>> > --- a/include/qom/cpu.h
>> > +++ b/include/qom/cpu.h
>> > @@ -89,7 +89,7 @@ struct TranslationBlock;
>> >   * @do_unassigned_access: Callback for unassigned access handling.
>> >   * (this is deprecated: new targets should use
> do_transaction_failed instead)
>> >   * @do_unaligned_access: Callback for unaligned access handling, if
>> > - * the target defines #ALIGNED_ONLY.
>> > + * the target defines #TARGET_ALIGNED_ONLY.
>> >   * @do_transaction_failed: Callback for handling failed memory
> transactions
>> >   * (ie bus faults or external aborts; not MMU faults)
>> >   * @virtio_is_big_endian: Callback to return %true if a CPU which
> supports
>> > diff --git a/target/alpha/cpu.h b/target/alpha/cpu.h
>> > index b3e8a823e1..16eb8047cf 100644
>> > --- a/target/alpha/cpu.h
>> > +++ b/target/alpha/cpu.h
>> > @@ -23,8 +23,6 @@
>> >  #include "cpu-qom.h"
>> >  #include "exec/cpu-defs.h"
>> > 
>> > -#define ALIGNED_ONLY
>> > -
>> >  /* Alpha processors have a weak memory model */
>> >  #define TCG_GUEST_DEFAULT_MO      (0)
>> > 
>> > diff --git a/target/hppa/cpu.h b/target/hppa/cpu.h
>> > index aab251bc4b..2be67c289a 100644
>> > --- a/target/hppa/cpu.h
>> > +++ b/target/hppa/cpu.h
>> > @@ -30,7 +30,6 @@
>> >     basis.  It's probably easier to fall back to a strong memory
> model.  */
>> >  #define TCG_GUEST_DEFAULT_MO        TCG_MO_ALL
>> > 
>> > -#define ALIGNED_ONLY
>> >  #define MMU_KERNEL_IDX   0
>> >  #define MMU_USER_IDX     3
>> >  #define MMU_PHYS_IDX     4
>> > diff --git a/target/mips/cpu.h b/target/mips/cpu.h
>> > index 21c0615e02..c13cd4eb31 100644
>> > --- a/target/mips/cpu.h
>> > +++ b/target/mips/cpu.h
>> > @@ -1,8 +1,6 @@
>> >  #ifndef MIPS_CPU_H
>> >  #define MIPS_CPU_H
>> > 
>> > -#define ALIGNED_ONLY
>> > -
>> >  #include "cpu-qom.h"
>> >  #include "exec/cpu-defs.h"
>> >  #include "fpu/softfloat.h"
>> > diff --git a/target/sh4/cpu.h b/target/sh4/cpu.h
>> > index aee733eaaa..ecaa7a18a9 100644
>> > --- a/target/sh4/cpu.h
>> > +++ b/target/sh4/cpu.h
>> > @@ -23,8 +23,6 @@
>> >  #include "cpu-qom.h"
>> >  #include "exec/cpu-defs.h"
>> > 
>> > -#define ALIGNED_ONLY
>> > -
>> >  /* CPU Subtypes */
>> >  #define SH_CPU_SH7750  (1 << 0)
>> >  #define 

Re: [Qemu-devel] [PATCH] configure: Define target access alignment in configure

2019-07-19 Thread Aleksandar Markovic
On Jul 18, 2019 8:02 AM,  wrote:
>
> This patch moves the define of target access alignment earlier from
> target/foo/cpu.h to configure.
>
> Suggested in Richard Henderson's reply to "[PATCH 1/4] tcg: TCGMemOp is
now
> accelerator independent MemOp"
>
> Signed-off-by: Tony Nguyen 
> ---

Hi, Tony.

In this patch you considered ALIGNED_ONLY, and proposed improvement. Do you
see in the related code other preprocessor constants that should be treated
in a similar way? If yes, perhaps we should do the same for them. Please
analyse a little more.

Yours, Aleksandar

>  configure | 12 ++--
>  include/exec/poison.h |  1 +
>  include/qom/cpu.h |  2 +-
>  target/alpha/cpu.h|  2 --
>  target/hppa/cpu.h |  1 -
>  target/mips/cpu.h |  2 --
>  target/sh4/cpu.h  |  2 --
>  target/sparc/cpu.h|  2 --
>  target/xtensa/cpu.h   |  2 --
>  tcg/tcg.c |  2 +-
>  tcg/tcg.h |  8 +---
>  11 files changed, 18 insertions(+), 18 deletions(-)
>
> diff --git a/configure b/configure
> index eb635c3b9a..c07687c656 100755
> --- a/configure
> +++ b/configure
> @@ -7424,11 +7424,16 @@ for target in $target_list; do
>  target_dir="$target"
>  config_target_mak=$target_dir/config-target.mak
>  target_name=$(echo $target | cut -d '-' -f 1)
> +target_aligned_only="no"
> +case "$target_name" in
> +
alpha|hppa|mips64el|mips64|mipsel|mips|mipsn32|mipsn32el|sh4|sh4eb|sparc|sparc64|sparc32plus|xtensa|xtensaeb)
> +  target_aligned_only="yes"
> +  ;;
> +esac
>  target_bigendian="no"
> -
>  case "$target_name" in
>
 
armeb|aarch64_be|hppa|lm32|m68k|microblaze|mips|mipsn32|mips64|moxie|or1k|ppc|ppc64|ppc64abi32|s390x|sh4eb|sparc|sparc64|sparc32plus|xtensaeb)
> -  target_bigendian=yes
> +  target_bigendian="yes"
>;;
>  esac
>  target_softmmu="no"
> @@ -7710,6 +7715,9 @@ fi
>  if supported_whpx_target $target; then
>  echo "CONFIG_WHPX=y" >> $config_target_mak
>  fi
> +if test "$target_aligned_only" = "yes" ; then
> +  echo "TARGET_ALIGNED_ONLY=y" >> $config_target_mak
> +fi
>  if test "$target_bigendian" = "yes" ; then
>echo "TARGET_WORDS_BIGENDIAN=y" >> $config_target_mak
>  fi
> diff --git a/include/exec/poison.h b/include/exec/poison.h
> index b862320fa6..955eb863ab 100644
> --- a/include/exec/poison.h
> +++ b/include/exec/poison.h
> @@ -35,6 +35,7 @@
>  #pragma GCC poison TARGET_UNICORE32
>  #pragma GCC poison TARGET_XTENSA
>
> +#pragma GCC poison TARGET_ALIGNED_ONLY
>  #pragma GCC poison TARGET_HAS_BFLT
>  #pragma GCC poison TARGET_NAME
>  #pragma GCC poison TARGET_SUPPORTS_MTTCG
> diff --git a/include/qom/cpu.h b/include/qom/cpu.h
> index 5ee0046b62..9b50b73339 100644
> --- a/include/qom/cpu.h
> +++ b/include/qom/cpu.h
> @@ -89,7 +89,7 @@ struct TranslationBlock;
>   * @do_unassigned_access: Callback for unassigned access handling.
>   * (this is deprecated: new targets should use do_transaction_failed
instead)
>   * @do_unaligned_access: Callback for unaligned access handling, if
> - * the target defines #ALIGNED_ONLY.
> + * the target defines #TARGET_ALIGNED_ONLY.
>   * @do_transaction_failed: Callback for handling failed memory
transactions
>   * (ie bus faults or external aborts; not MMU faults)
>   * @virtio_is_big_endian: Callback to return %true if a CPU which
supports
> diff --git a/target/alpha/cpu.h b/target/alpha/cpu.h
> index b3e8a823e1..16eb8047cf 100644
> --- a/target/alpha/cpu.h
> +++ b/target/alpha/cpu.h
> @@ -23,8 +23,6 @@
>  #include "cpu-qom.h"
>  #include "exec/cpu-defs.h"
>
> -#define ALIGNED_ONLY
> -
>  /* Alpha processors have a weak memory model */
>  #define TCG_GUEST_DEFAULT_MO  (0)
>
> diff --git a/target/hppa/cpu.h b/target/hppa/cpu.h
> index aab251bc4b..2be67c289a 100644
> --- a/target/hppa/cpu.h
> +++ b/target/hppa/cpu.h
> @@ -30,7 +30,6 @@
> basis.  It's probably easier to fall back to a strong memory model.
*/
>  #define TCG_GUEST_DEFAULT_MOTCG_MO_ALL
>
> -#define ALIGNED_ONLY
>  #define MMU_KERNEL_IDX   0
>  #define MMU_USER_IDX 3
>  #define MMU_PHYS_IDX 4
> diff --git a/target/mips/cpu.h b/target/mips/cpu.h
> index 21c0615e02..c13cd4eb31 100644
> --- a/target/mips/cpu.h
> +++ b/target/mips/cpu.h
> @@ -1,8 +1,6 @@
>  #ifndef MIPS_CPU_H
>  #define MIPS_CPU_H
>
> -#define ALIGNED_ONLY
> -
>  #include "cpu-qom.h"
>  #include "exec/cpu-defs.h"
>  #include "fpu/softfloat.h"
> diff --git a/target/sh4/cpu.h b/target/sh4/cpu.h
> index aee733eaaa..ecaa7a18a9 100644
> --- a/target/sh4/cpu.h
> +++ b/target/sh4/cpu.h
> @@ -23,8 +23,6 @@
>  #include "cpu-qom.h"
>  #include "exec/cpu-defs.h"
>
> -#define ALIGNED_ONLY
> -
>  /* CPU Subtypes */
>  #define SH_CPU_SH7750  (1 << 0)
>  #define SH_CPU_SH7750S (1 << 1)
> diff --git a/target/sparc/cpu.h b/target/sparc/cpu.h
> index 8ed2250cd0..1406f0ba2e 100644
> --- a/target/sparc/cpu.h
> +++ b/target/sparc/cpu.h
> @@ -5,8 +5,6 @@
>  #include "cpu-qom.h"
>  #include "exec/cpu-defs.h"
>
> -#define ALIGNED_ONLY
> -
>  #if !defined(TARGET_SPARC64)
>  #define TARGET_DPREGS 16
>  

Re: [Qemu-devel] [PATCH] configure: Define target access alignment in configure

2019-07-19 Thread Aleksandar Markovic
On Jul 18, 2019 11:55 AM, "Paolo Bonzini"  wrote:
>
> On 18/07/19 08:01, tony.ngu...@bt.com wrote:
> > This patch moves the define of target access alignment earlier from
> > target/foo/cpu.h to configure.
> >
> > Suggested in Richard Henderson's reply to "[PATCH 1/4] tcg: TCGMemOp is
now
> > accelerator independent MemOp"
> >
> > Signed-off-by: Tony Nguyen 
> > ---
> >  configure | 12 ++--
> >  include/exec/poison.h |  1 +
> >  include/qom/cpu.h |  2 +-
> >  target/alpha/cpu.h|  2 --
> >  target/hppa/cpu.h |  1 -
> >  target/mips/cpu.h |  2 --
> >  target/sh4/cpu.h  |  2 --
> >  target/sparc/cpu.h|  2 --
> >  target/xtensa/cpu.h   |  2 --
> >  tcg/tcg.c |  2 +-
> >  tcg/tcg.h |  8 +---
> >  11 files changed, 18 insertions(+), 18 deletions(-)
> >
> > diff --git a/configure b/configure
> > index eb635c3b9a..c07687c656 100755
> > --- a/configure
> > +++ b/configure
> > @@ -7424,11 +7424,16 @@ for target in $target_list; do
> >  target_dir="$target"
> >  config_target_mak=$target_dir/config-target.mak
> >  target_name=$(echo $target | cut -d '-' -f 1)
> > +target_aligned_only="no"
> > +case "$target_name" in
> > +
alpha|hppa|mips64el|mips64|mipsel|mips|mipsn32|mipsn32el|sh4|sh4eb|sparc|sparc64|sparc32plus|xtensa|xtensaeb)
> > +  target_aligned_only="yes"
> > +  ;;
> > +esac
> >  target_bigendian="no"
> > -
> >  case "$target_name" in
> >
armeb|aarch64_be|hppa|lm32|m68k|microblaze|mips|mipsn32|mips64|moxie|or1k|ppc|ppc64|ppc64abi32|s390x|sh4eb|sparc|sparc64|sparc32plus|xtensaeb)
> > -  target_bigendian=yes
> > +  target_bigendian="yes"
> >;;
> >  esac
> >  target_softmmu="no"
> > @@ -7710,6 +7715,9 @@ fi
> >  if supported_whpx_target $target; then
> >  echo "CONFIG_WHPX=y" >> $config_target_mak
> >  fi
> > +if test "$target_aligned_only" = "yes" ; then
> > +  echo "TARGET_ALIGNED_ONLY=y" >> $config_target_mak
> > +fi
> >  if test "$target_bigendian" = "yes" ; then
> >echo "TARGET_WORDS_BIGENDIAN=y" >> $config_target_mak
> >  fi
> > diff --git a/include/exec/poison.h b/include/exec/poison.h
> > index b862320fa6..955eb863ab 100644
> > --- a/include/exec/poison.h
> > +++ b/include/exec/poison.h
> > @@ -35,6 +35,7 @@
> >  #pragma GCC poison TARGET_UNICORE32
> >  #pragma GCC poison TARGET_XTENSA
> >
> > +#pragma GCC poison TARGET_ALIGNED_ONLY
> >  #pragma GCC poison TARGET_HAS_BFLT
> >  #pragma GCC poison TARGET_NAME
> >  #pragma GCC poison TARGET_SUPPORTS_MTTCG
> > diff --git a/include/qom/cpu.h b/include/qom/cpu.h
> > index 5ee0046b62..9b50b73339 100644
> > --- a/include/qom/cpu.h
> > +++ b/include/qom/cpu.h
> > @@ -89,7 +89,7 @@ struct TranslationBlock;
> >   * @do_unassigned_access: Callback for unassigned access handling.
> >   * (this is deprecated: new targets should use do_transaction_failed
instead)
> >   * @do_unaligned_access: Callback for unaligned access handling, if
> > - * the target defines #ALIGNED_ONLY.
> > + * the target defines #TARGET_ALIGNED_ONLY.
> >   * @do_transaction_failed: Callback for handling failed memory
transactions
> >   * (ie bus faults or external aborts; not MMU faults)
> >   * @virtio_is_big_endian: Callback to return %true if a CPU which
supports
> > diff --git a/target/alpha/cpu.h b/target/alpha/cpu.h
> > index b3e8a823e1..16eb8047cf 100644
> > --- a/target/alpha/cpu.h
> > +++ b/target/alpha/cpu.h
> > @@ -23,8 +23,6 @@
> >  #include "cpu-qom.h"
> >  #include "exec/cpu-defs.h"
> >
> > -#define ALIGNED_ONLY
> > -
> >  /* Alpha processors have a weak memory model */
> >  #define TCG_GUEST_DEFAULT_MO  (0)
> >
> > diff --git a/target/hppa/cpu.h b/target/hppa/cpu.h
> > index aab251bc4b..2be67c289a 100644
> > --- a/target/hppa/cpu.h
> > +++ b/target/hppa/cpu.h
> > @@ -30,7 +30,6 @@
> > basis.  It's probably easier to fall back to a strong memory
model.  */
> >  #define TCG_GUEST_DEFAULT_MOTCG_MO_ALL
> >
> > -#define ALIGNED_ONLY
> >  #define MMU_KERNEL_IDX   0
> >  #define MMU_USER_IDX 3
> >  #define MMU_PHYS_IDX 4
> > diff --git a/target/mips/cpu.h b/target/mips/cpu.h
> > index 21c0615e02..c13cd4eb31 100644
> > --- a/target/mips/cpu.h
> > +++ b/target/mips/cpu.h
> > @@ -1,8 +1,6 @@
> >  #ifndef MIPS_CPU_H
> >  #define MIPS_CPU_H
> >
> > -#define ALIGNED_ONLY
> > -
> >  #include "cpu-qom.h"
> >  #include "exec/cpu-defs.h"
> >  #include "fpu/softfloat.h"
> > diff --git a/target/sh4/cpu.h b/target/sh4/cpu.h
> > index aee733eaaa..ecaa7a18a9 100644
> > --- a/target/sh4/cpu.h
> > +++ b/target/sh4/cpu.h
> > @@ -23,8 +23,6 @@
> >  #include "cpu-qom.h"
> >  #include "exec/cpu-defs.h"
> >
> > -#define ALIGNED_ONLY
> > -
> >  /* CPU Subtypes */
> >  #define SH_CPU_SH7750  (1 << 0)
> >  #define SH_CPU_SH7750S (1 << 1)
> > diff --git a/target/sparc/cpu.h b/target/sparc/cpu.h
> > index 8ed2250cd0..1406f0ba2e 100644
> > --- a/target/sparc/cpu.h
> > +++ b/target/sparc/cpu.h
> > @@ -5,8 +5,6 @@
> >  #include "cpu-qom.h"
> >  #include "exec/cpu-defs.h"
> >
> > -#define ALIGNED_ONLY
> > -
> >  

Re: [Qemu-devel] [PATCH] configure: Define target access alignment in configure

2019-07-19 Thread Aleksandar Markovic
On Jul 18, 2019 8:02 AM,  wrote:
>
> This patch moves the define of target access alignment earlier from
> target/foo/cpu.h to configure.
>
> Suggested in Richard Henderson's reply to "[PATCH 1/4] tcg: TCGMemOp is
now
> accelerator independent MemOp"
>
> Signed-off-by: Tony Nguyen 
> ---
>  configure | 12 ++--
>  include/exec/poison.h |  1 +
>  include/qom/cpu.h |  2 +-
>  target/alpha/cpu.h|  2 --
>  target/hppa/cpu.h |  1 -
>  target/mips/cpu.h |  2 --
>  target/sh4/cpu.h  |  2 --
>  target/sparc/cpu.h|  2 --
>  target/xtensa/cpu.h   |  2 --
>  tcg/tcg.c |  2 +-
>  tcg/tcg.h |  8 +---
>  11 files changed, 18 insertions(+), 18 deletions(-)
>
> diff --git a/configure b/configure
> index eb635c3b9a..c07687c656 100755
> --- a/configure
> +++ b/configure
> @@ -7424,11 +7424,16 @@ for target in $target_list; do
>  target_dir="$target"
>  config_target_mak=$target_dir/config-target.mak
>  target_name=$(echo $target | cut -d '-' -f 1)
> +target_aligned_only="no"
> +case "$target_name" in
> +
alpha|hppa|mips64el|mips64|mipsel|mips|mipsn32|mipsn32el|sh4|sh4eb|sparc|sparc64|sparc32plus|xtensa|xtensaeb)
> +  target_aligned_only="yes"
> +  ;;
> +esac
>  target_bigendian="no"
> -
>  case "$target_name" in
>
 
armeb|aarch64_be|hppa|lm32|m68k|microblaze|mips|mipsn32|mips64|moxie|or1k|ppc|ppc64|ppc64abi32|s390x|sh4eb|sparc|sparc64|sparc32plus|xtensaeb)
> -  target_bigendian=yes
> +  target_bigendian="yes"

This line should be in a separate patch. What is the difference between yes
and “yes”? Does this fix a bug, or is just a cosmetic thing?

Thanks, Aleksandar

>;;
>  esac
>  target_softmmu="no"
> @@ -7710,6 +7715,9 @@ fi
>  if supported_whpx_target $target; then
>  echo "CONFIG_WHPX=y" >> $config_target_mak
>  fi
> +if test "$target_aligned_only" = "yes" ; then
> +  echo "TARGET_ALIGNED_ONLY=y" >> $config_target_mak
> +fi
>  if test "$target_bigendian" = "yes" ; then
>echo "TARGET_WORDS_BIGENDIAN=y" >> $config_target_mak
>  fi
> diff --git a/include/exec/poison.h b/include/exec/poison.h
> index b862320fa6..955eb863ab 100644
> --- a/include/exec/poison.h
> +++ b/include/exec/poison.h
> @@ -35,6 +35,7 @@
>  #pragma GCC poison TARGET_UNICORE32
>  #pragma GCC poison TARGET_XTENSA
>
> +#pragma GCC poison TARGET_ALIGNED_ONLY
>  #pragma GCC poison TARGET_HAS_BFLT
>  #pragma GCC poison TARGET_NAME
>  #pragma GCC poison TARGET_SUPPORTS_MTTCG
> diff --git a/include/qom/cpu.h b/include/qom/cpu.h
> index 5ee0046b62..9b50b73339 100644
> --- a/include/qom/cpu.h
> +++ b/include/qom/cpu.h
> @@ -89,7 +89,7 @@ struct TranslationBlock;
>   * @do_unassigned_access: Callback for unassigned access handling.
>   * (this is deprecated: new targets should use do_transaction_failed
instead)
>   * @do_unaligned_access: Callback for unaligned access handling, if
> - * the target defines #ALIGNED_ONLY.
> + * the target defines #TARGET_ALIGNED_ONLY.
>   * @do_transaction_failed: Callback for handling failed memory
transactions
>   * (ie bus faults or external aborts; not MMU faults)
>   * @virtio_is_big_endian: Callback to return %true if a CPU which
supports
> diff --git a/target/alpha/cpu.h b/target/alpha/cpu.h
> index b3e8a823e1..16eb8047cf 100644
> --- a/target/alpha/cpu.h
> +++ b/target/alpha/cpu.h
> @@ -23,8 +23,6 @@
>  #include "cpu-qom.h"
>  #include "exec/cpu-defs.h"
>
> -#define ALIGNED_ONLY
> -
>  /* Alpha processors have a weak memory model */
>  #define TCG_GUEST_DEFAULT_MO  (0)
>
> diff --git a/target/hppa/cpu.h b/target/hppa/cpu.h
> index aab251bc4b..2be67c289a 100644
> --- a/target/hppa/cpu.h
> +++ b/target/hppa/cpu.h
> @@ -30,7 +30,6 @@
> basis.  It's probably easier to fall back to a strong memory model.
*/
>  #define TCG_GUEST_DEFAULT_MOTCG_MO_ALL
>
> -#define ALIGNED_ONLY
>  #define MMU_KERNEL_IDX   0
>  #define MMU_USER_IDX 3
>  #define MMU_PHYS_IDX 4
> diff --git a/target/mips/cpu.h b/target/mips/cpu.h
> index 21c0615e02..c13cd4eb31 100644
> --- a/target/mips/cpu.h
> +++ b/target/mips/cpu.h
> @@ -1,8 +1,6 @@
>  #ifndef MIPS_CPU_H
>  #define MIPS_CPU_H
>
> -#define ALIGNED_ONLY
> -
>  #include "cpu-qom.h"
>  #include "exec/cpu-defs.h"
>  #include "fpu/softfloat.h"
> diff --git a/target/sh4/cpu.h b/target/sh4/cpu.h
> index aee733eaaa..ecaa7a18a9 100644
> --- a/target/sh4/cpu.h
> +++ b/target/sh4/cpu.h
> @@ -23,8 +23,6 @@
>  #include "cpu-qom.h"
>  #include "exec/cpu-defs.h"
>
> -#define ALIGNED_ONLY
> -
>  /* CPU Subtypes */
>  #define SH_CPU_SH7750  (1 << 0)
>  #define SH_CPU_SH7750S (1 << 1)
> diff --git a/target/sparc/cpu.h b/target/sparc/cpu.h
> index 8ed2250cd0..1406f0ba2e 100644
> --- a/target/sparc/cpu.h
> +++ b/target/sparc/cpu.h
> @@ -5,8 +5,6 @@
>  #include "cpu-qom.h"
>  #include "exec/cpu-defs.h"
>
> -#define ALIGNED_ONLY
> -
>  #if !defined(TARGET_SPARC64)
>  #define TARGET_DPREGS 16
>  #else
> diff --git a/target/xtensa/cpu.h b/target/xtensa/cpu.h
> index 2c277134f1..0459243e6b 100644
> --- 

Re: [Qemu-devel] [PATCH] configure: Define target access alignment in configure

2019-07-19 Thread Aleksandar Markovic
On Jul 18, 2019 8:02 AM,  wrote:
>
> This patch moves the define of target access alignment earlier from
> target/foo/cpu.h to configure.
>
> Suggested in Richard Henderson's reply to "[PATCH 1/4] tcg: TCGMemOp is
now
> accelerator independent MemOp"
>
> Signed-off-by: Tony Nguyen 
> ---

Tony,

No matter how small the change is, while sending patches, you must cc
corresponding maintainers, if your change includes the code in files they
maintain.

Thanks, Aleksandar

>  configure | 12 ++--
>  include/exec/poison.h |  1 +
>  include/qom/cpu.h |  2 +-
>  target/alpha/cpu.h|  2 --
>  target/hppa/cpu.h |  1 -
>  target/mips/cpu.h |  2 --
>  target/sh4/cpu.h  |  2 --
>  target/sparc/cpu.h|  2 --
>  target/xtensa/cpu.h   |  2 --
>  tcg/tcg.c |  2 +-
>  tcg/tcg.h |  8 +---
>  11 files changed, 18 insertions(+), 18 deletions(-)
>
> diff --git a/configure b/configure
> index eb635c3b9a..c07687c656 100755
> --- a/configure
> +++ b/configure
> @@ -7424,11 +7424,16 @@ for target in $target_list; do
>  target_dir="$target"
>  config_target_mak=$target_dir/config-target.mak
>  target_name=$(echo $target | cut -d '-' -f 1)
> +target_aligned_only="no"
> +case "$target_name" in
> +
alpha|hppa|mips64el|mips64|mipsel|mips|mipsn32|mipsn32el|sh4|sh4eb|sparc|sparc64|sparc32plus|xtensa|xtensaeb)
> +  target_aligned_only="yes"
> +  ;;
> +esac
>  target_bigendian="no"
> -
>  case "$target_name" in
>
 
armeb|aarch64_be|hppa|lm32|m68k|microblaze|mips|mipsn32|mips64|moxie|or1k|ppc|ppc64|ppc64abi32|s390x|sh4eb|sparc|sparc64|sparc32plus|xtensaeb)
> -  target_bigendian=yes
> +  target_bigendian="yes"
>;;
>  esac
>  target_softmmu="no"
> @@ -7710,6 +7715,9 @@ fi
>  if supported_whpx_target $target; then
>  echo "CONFIG_WHPX=y" >> $config_target_mak
>  fi
> +if test "$target_aligned_only" = "yes" ; then
> +  echo "TARGET_ALIGNED_ONLY=y" >> $config_target_mak
> +fi
>  if test "$target_bigendian" = "yes" ; then
>echo "TARGET_WORDS_BIGENDIAN=y" >> $config_target_mak
>  fi
> diff --git a/include/exec/poison.h b/include/exec/poison.h
> index b862320fa6..955eb863ab 100644
> --- a/include/exec/poison.h
> +++ b/include/exec/poison.h
> @@ -35,6 +35,7 @@
>  #pragma GCC poison TARGET_UNICORE32
>  #pragma GCC poison TARGET_XTENSA
>
> +#pragma GCC poison TARGET_ALIGNED_ONLY
>  #pragma GCC poison TARGET_HAS_BFLT
>  #pragma GCC poison TARGET_NAME
>  #pragma GCC poison TARGET_SUPPORTS_MTTCG
> diff --git a/include/qom/cpu.h b/include/qom/cpu.h
> index 5ee0046b62..9b50b73339 100644
> --- a/include/qom/cpu.h
> +++ b/include/qom/cpu.h
> @@ -89,7 +89,7 @@ struct TranslationBlock;
>   * @do_unassigned_access: Callback for unassigned access handling.
>   * (this is deprecated: new targets should use do_transaction_failed
instead)
>   * @do_unaligned_access: Callback for unaligned access handling, if
> - * the target defines #ALIGNED_ONLY.
> + * the target defines #TARGET_ALIGNED_ONLY.
>   * @do_transaction_failed: Callback for handling failed memory
transactions
>   * (ie bus faults or external aborts; not MMU faults)
>   * @virtio_is_big_endian: Callback to return %true if a CPU which
supports
> diff --git a/target/alpha/cpu.h b/target/alpha/cpu.h
> index b3e8a823e1..16eb8047cf 100644
> --- a/target/alpha/cpu.h
> +++ b/target/alpha/cpu.h
> @@ -23,8 +23,6 @@
>  #include "cpu-qom.h"
>  #include "exec/cpu-defs.h"
>
> -#define ALIGNED_ONLY
> -
>  /* Alpha processors have a weak memory model */
>  #define TCG_GUEST_DEFAULT_MO  (0)
>
> diff --git a/target/hppa/cpu.h b/target/hppa/cpu.h
> index aab251bc4b..2be67c289a 100644
> --- a/target/hppa/cpu.h
> +++ b/target/hppa/cpu.h
> @@ -30,7 +30,6 @@
> basis.  It's probably easier to fall back to a strong memory model.
*/
>  #define TCG_GUEST_DEFAULT_MOTCG_MO_ALL
>
> -#define ALIGNED_ONLY
>  #define MMU_KERNEL_IDX   0
>  #define MMU_USER_IDX 3
>  #define MMU_PHYS_IDX 4
> diff --git a/target/mips/cpu.h b/target/mips/cpu.h
> index 21c0615e02..c13cd4eb31 100644
> --- a/target/mips/cpu.h
> +++ b/target/mips/cpu.h
> @@ -1,8 +1,6 @@
>  #ifndef MIPS_CPU_H
>  #define MIPS_CPU_H
>
> -#define ALIGNED_ONLY
> -
>  #include "cpu-qom.h"
>  #include "exec/cpu-defs.h"
>  #include "fpu/softfloat.h"
> diff --git a/target/sh4/cpu.h b/target/sh4/cpu.h
> index aee733eaaa..ecaa7a18a9 100644
> --- a/target/sh4/cpu.h
> +++ b/target/sh4/cpu.h
> @@ -23,8 +23,6 @@
>  #include "cpu-qom.h"
>  #include "exec/cpu-defs.h"
>
> -#define ALIGNED_ONLY
> -
>  /* CPU Subtypes */
>  #define SH_CPU_SH7750  (1 << 0)
>  #define SH_CPU_SH7750S (1 << 1)
> diff --git a/target/sparc/cpu.h b/target/sparc/cpu.h
> index 8ed2250cd0..1406f0ba2e 100644
> --- a/target/sparc/cpu.h
> +++ b/target/sparc/cpu.h
> @@ -5,8 +5,6 @@
>  #include "cpu-qom.h"
>  #include "exec/cpu-defs.h"
>
> -#define ALIGNED_ONLY
> -
>  #if !defined(TARGET_SPARC64)
>  #define TARGET_DPREGS 16
>  #else
> diff --git a/target/xtensa/cpu.h b/target/xtensa/cpu.h
> index 2c277134f1..0459243e6b 100644

Re: [Qemu-devel] [PATCH] configure: Define target access alignment in configure

2019-07-18 Thread Richard Henderson
On 7/17/19 11:01 PM, tony.ngu...@bt.com wrote:
> This patch moves the define of target access alignment earlier from
> target/foo/cpu.h to configure.
> 
> Suggested in Richard Henderson's reply to "[PATCH 1/4] tcg: TCGMemOp is now
> accelerator independent MemOp"
> 
> Signed-off-by: Tony Nguyen 
> ---
>  configure | 12 ++--
>  include/exec/poison.h |  1 +
>  include/qom/cpu.h |  2 +-
>  target/alpha/cpu.h|  2 --
>  target/hppa/cpu.h |  1 -
>  target/mips/cpu.h |  2 --
>  target/sh4/cpu.h  |  2 --
>  target/sparc/cpu.h|  2 --
>  target/xtensa/cpu.h   |  2 --
>  tcg/tcg.c |  2 +-
>  tcg/tcg.h |  8 +---
>  11 files changed, 18 insertions(+), 18 deletions(-)

Thanks for this.
Reviewed-by: Richard Henderson 


r~



Re: [Qemu-devel] [PATCH] configure: Define target access alignment in configure

2019-07-18 Thread Paolo Bonzini
On 18/07/19 08:01, tony.ngu...@bt.com wrote:
> This patch moves the define of target access alignment earlier from
> target/foo/cpu.h to configure.
> 
> Suggested in Richard Henderson's reply to "[PATCH 1/4] tcg: TCGMemOp is now
> accelerator independent MemOp"
> 
> Signed-off-by: Tony Nguyen 
> ---
>  configure | 12 ++--
>  include/exec/poison.h |  1 +
>  include/qom/cpu.h |  2 +-
>  target/alpha/cpu.h|  2 --
>  target/hppa/cpu.h |  1 -
>  target/mips/cpu.h |  2 --
>  target/sh4/cpu.h  |  2 --
>  target/sparc/cpu.h|  2 --
>  target/xtensa/cpu.h   |  2 --
>  tcg/tcg.c |  2 +-
>  tcg/tcg.h |  8 +---
>  11 files changed, 18 insertions(+), 18 deletions(-)
> 
> diff --git a/configure b/configure
> index eb635c3b9a..c07687c656 100755
> --- a/configure
> +++ b/configure
> @@ -7424,11 +7424,16 @@ for target in $target_list; do
>  target_dir="$target"
>  config_target_mak=$target_dir/config-target.mak
>  target_name=$(echo $target | cut -d '-' -f 1)
> +target_aligned_only="no"
> +case "$target_name" in
> +  
> alpha|hppa|mips64el|mips64|mipsel|mips|mipsn32|mipsn32el|sh4|sh4eb|sparc|sparc64|sparc32plus|xtensa|xtensaeb)
> +  target_aligned_only="yes"
> +  ;;
> +esac
>  target_bigendian="no"
> -
>  case "$target_name" in
>
> armeb|aarch64_be|hppa|lm32|m68k|microblaze|mips|mipsn32|mips64|moxie|or1k|ppc|ppc64|ppc64abi32|s390x|sh4eb|sparc|sparc64|sparc32plus|xtensaeb)
> -  target_bigendian=yes
> +  target_bigendian="yes"
>;;
>  esac
>  target_softmmu="no"
> @@ -7710,6 +7715,9 @@ fi
>  if supported_whpx_target $target; then
>  echo "CONFIG_WHPX=y" >> $config_target_mak
>  fi
> +if test "$target_aligned_only" = "yes" ; then
> +  echo "TARGET_ALIGNED_ONLY=y" >> $config_target_mak
> +fi
>  if test "$target_bigendian" = "yes" ; then
>echo "TARGET_WORDS_BIGENDIAN=y" >> $config_target_mak
>  fi
> diff --git a/include/exec/poison.h b/include/exec/poison.h
> index b862320fa6..955eb863ab 100644
> --- a/include/exec/poison.h
> +++ b/include/exec/poison.h
> @@ -35,6 +35,7 @@
>  #pragma GCC poison TARGET_UNICORE32
>  #pragma GCC poison TARGET_XTENSA
>  
> +#pragma GCC poison TARGET_ALIGNED_ONLY
>  #pragma GCC poison TARGET_HAS_BFLT
>  #pragma GCC poison TARGET_NAME
>  #pragma GCC poison TARGET_SUPPORTS_MTTCG
> diff --git a/include/qom/cpu.h b/include/qom/cpu.h
> index 5ee0046b62..9b50b73339 100644
> --- a/include/qom/cpu.h
> +++ b/include/qom/cpu.h
> @@ -89,7 +89,7 @@ struct TranslationBlock;
>   * @do_unassigned_access: Callback for unassigned access handling.
>   * (this is deprecated: new targets should use do_transaction_failed instead)
>   * @do_unaligned_access: Callback for unaligned access handling, if
> - * the target defines #ALIGNED_ONLY.
> + * the target defines #TARGET_ALIGNED_ONLY.
>   * @do_transaction_failed: Callback for handling failed memory transactions
>   * (ie bus faults or external aborts; not MMU faults)
>   * @virtio_is_big_endian: Callback to return %true if a CPU which supports
> diff --git a/target/alpha/cpu.h b/target/alpha/cpu.h
> index b3e8a823e1..16eb8047cf 100644
> --- a/target/alpha/cpu.h
> +++ b/target/alpha/cpu.h
> @@ -23,8 +23,6 @@
>  #include "cpu-qom.h"
>  #include "exec/cpu-defs.h"
>  
> -#define ALIGNED_ONLY
> -
>  /* Alpha processors have a weak memory model */
>  #define TCG_GUEST_DEFAULT_MO  (0)
>  
> diff --git a/target/hppa/cpu.h b/target/hppa/cpu.h
> index aab251bc4b..2be67c289a 100644
> --- a/target/hppa/cpu.h
> +++ b/target/hppa/cpu.h
> @@ -30,7 +30,6 @@
> basis.  It's probably easier to fall back to a strong memory model.  */
>  #define TCG_GUEST_DEFAULT_MOTCG_MO_ALL
>  
> -#define ALIGNED_ONLY
>  #define MMU_KERNEL_IDX   0
>  #define MMU_USER_IDX 3
>  #define MMU_PHYS_IDX 4
> diff --git a/target/mips/cpu.h b/target/mips/cpu.h
> index 21c0615e02..c13cd4eb31 100644
> --- a/target/mips/cpu.h
> +++ b/target/mips/cpu.h
> @@ -1,8 +1,6 @@
>  #ifndef MIPS_CPU_H
>  #define MIPS_CPU_H
>  
> -#define ALIGNED_ONLY
> -
>  #include "cpu-qom.h"
>  #include "exec/cpu-defs.h"
>  #include "fpu/softfloat.h"
> diff --git a/target/sh4/cpu.h b/target/sh4/cpu.h
> index aee733eaaa..ecaa7a18a9 100644
> --- a/target/sh4/cpu.h
> +++ b/target/sh4/cpu.h
> @@ -23,8 +23,6 @@
>  #include "cpu-qom.h"
>  #include "exec/cpu-defs.h"
>  
> -#define ALIGNED_ONLY
> -
>  /* CPU Subtypes */
>  #define SH_CPU_SH7750  (1 << 0)
>  #define SH_CPU_SH7750S (1 << 1)
> diff --git a/target/sparc/cpu.h b/target/sparc/cpu.h
> index 8ed2250cd0..1406f0ba2e 100644
> --- a/target/sparc/cpu.h
> +++ b/target/sparc/cpu.h
> @@ -5,8 +5,6 @@
>  #include "cpu-qom.h"
>  #include "exec/cpu-defs.h"
>  
> -#define ALIGNED_ONLY
> -
>  #if !defined(TARGET_SPARC64)
>  #define TARGET_DPREGS 16
>  #else
> diff --git a/target/xtensa/cpu.h b/target/xtensa/cpu.h
> index 2c277134f1..0459243e6b 100644
> --- a/target/xtensa/cpu.h
> +++ b/target/xtensa/cpu.h
> @@ -32,8 +32,6 @@
>  #include "exec/cpu-defs.h"
>  #include "xtensa-isa.h"
>  
> -#define 

Re: [Qemu-devel] [PATCH] configure: Define target access alignment in configure

2019-07-18 Thread Philippe Mathieu-Daudé
On 7/18/19 8:01 AM, tony.ngu...@bt.com wrote:
> This patch moves the define of target access alignment earlier from
> target/foo/cpu.h to configure.
> 
> Suggested in Richard Henderson's reply to "[PATCH 1/4] tcg: TCGMemOp is now
> accelerator independent MemOp"
> 
> Signed-off-by: Tony Nguyen 
> ---
>  configure | 12 ++--
>  include/exec/poison.h |  1 +
>  include/qom/cpu.h |  2 +-
>  target/alpha/cpu.h|  2 --
>  target/hppa/cpu.h |  1 -
>  target/mips/cpu.h |  2 --
>  target/sh4/cpu.h  |  2 --
>  target/sparc/cpu.h|  2 --
>  target/xtensa/cpu.h   |  2 --
>  tcg/tcg.c |  2 +-
>  tcg/tcg.h |  8 +---
>  11 files changed, 18 insertions(+), 18 deletions(-)
> 
> diff --git a/configure b/configure
> index eb635c3b9a..c07687c656 100755
> --- a/configure
> +++ b/configure
> @@ -7424,11 +7424,16 @@ for target in $target_list; do
>  target_dir="$target"
>  config_target_mak=$target_dir/config-target.mak
>  target_name=$(echo $target | cut -d '-' -f 1)
> +target_aligned_only="no"
> +case "$target_name" in
> +  
> alpha|hppa|mips64el|mips64|mipsel|mips|mipsn32|mipsn32el|sh4|sh4eb|sparc|sparc64|sparc32plus|xtensa|xtensaeb)
> +  target_aligned_only="yes"
> +  ;;
> +esac
>  target_bigendian="no"
> -
>  case "$target_name" in
>
> armeb|aarch64_be|hppa|lm32|m68k|microblaze|mips|mipsn32|mips64|moxie|or1k|ppc|ppc64|ppc64abi32|s390x|sh4eb|sparc|sparc64|sparc32plus|xtensaeb)
> -  target_bigendian=yes
> +  target_bigendian="yes"

This change seems unrelated, good cleanup otherwise!

Reviewed-by: Philippe Mathieu-Daudé 

>;;
>  esac
>  target_softmmu="no"
> @@ -7710,6 +7715,9 @@ fi
>  if supported_whpx_target $target; then
>  echo "CONFIG_WHPX=y" >> $config_target_mak
>  fi
> +if test "$target_aligned_only" = "yes" ; then
> +  echo "TARGET_ALIGNED_ONLY=y" >> $config_target_mak
> +fi
>  if test "$target_bigendian" = "yes" ; then
>echo "TARGET_WORDS_BIGENDIAN=y" >> $config_target_mak
>  fi
> diff --git a/include/exec/poison.h b/include/exec/poison.h
> index b862320fa6..955eb863ab 100644
> --- a/include/exec/poison.h
> +++ b/include/exec/poison.h
> @@ -35,6 +35,7 @@
>  #pragma GCC poison TARGET_UNICORE32
>  #pragma GCC poison TARGET_XTENSA
>  
> +#pragma GCC poison TARGET_ALIGNED_ONLY
>  #pragma GCC poison TARGET_HAS_BFLT
>  #pragma GCC poison TARGET_NAME
>  #pragma GCC poison TARGET_SUPPORTS_MTTCG
> diff --git a/include/qom/cpu.h b/include/qom/cpu.h
> index 5ee0046b62..9b50b73339 100644
> --- a/include/qom/cpu.h
> +++ b/include/qom/cpu.h
> @@ -89,7 +89,7 @@ struct TranslationBlock;
>   * @do_unassigned_access: Callback for unassigned access handling.
>   * (this is deprecated: new targets should use do_transaction_failed instead)
>   * @do_unaligned_access: Callback for unaligned access handling, if
> - * the target defines #ALIGNED_ONLY.
> + * the target defines #TARGET_ALIGNED_ONLY.
>   * @do_transaction_failed: Callback for handling failed memory transactions
>   * (ie bus faults or external aborts; not MMU faults)
>   * @virtio_is_big_endian: Callback to return %true if a CPU which supports
> diff --git a/target/alpha/cpu.h b/target/alpha/cpu.h
> index b3e8a823e1..16eb8047cf 100644
> --- a/target/alpha/cpu.h
> +++ b/target/alpha/cpu.h
> @@ -23,8 +23,6 @@
>  #include "cpu-qom.h"
>  #include "exec/cpu-defs.h"
>  
> -#define ALIGNED_ONLY
> -
>  /* Alpha processors have a weak memory model */
>  #define TCG_GUEST_DEFAULT_MO  (0)
>  
> diff --git a/target/hppa/cpu.h b/target/hppa/cpu.h
> index aab251bc4b..2be67c289a 100644
> --- a/target/hppa/cpu.h
> +++ b/target/hppa/cpu.h
> @@ -30,7 +30,6 @@
> basis.  It's probably easier to fall back to a strong memory model.  */
>  #define TCG_GUEST_DEFAULT_MOTCG_MO_ALL
>  
> -#define ALIGNED_ONLY
>  #define MMU_KERNEL_IDX   0
>  #define MMU_USER_IDX 3
>  #define MMU_PHYS_IDX 4
> diff --git a/target/mips/cpu.h b/target/mips/cpu.h
> index 21c0615e02..c13cd4eb31 100644
> --- a/target/mips/cpu.h
> +++ b/target/mips/cpu.h
> @@ -1,8 +1,6 @@
>  #ifndef MIPS_CPU_H
>  #define MIPS_CPU_H
>  
> -#define ALIGNED_ONLY
> -
>  #include "cpu-qom.h"
>  #include "exec/cpu-defs.h"
>  #include "fpu/softfloat.h"
> diff --git a/target/sh4/cpu.h b/target/sh4/cpu.h
> index aee733eaaa..ecaa7a18a9 100644
> --- a/target/sh4/cpu.h
> +++ b/target/sh4/cpu.h
> @@ -23,8 +23,6 @@
>  #include "cpu-qom.h"
>  #include "exec/cpu-defs.h"
>  
> -#define ALIGNED_ONLY
> -
>  /* CPU Subtypes */
>  #define SH_CPU_SH7750  (1 << 0)
>  #define SH_CPU_SH7750S (1 << 1)
> diff --git a/target/sparc/cpu.h b/target/sparc/cpu.h
> index 8ed2250cd0..1406f0ba2e 100644
> --- a/target/sparc/cpu.h
> +++ b/target/sparc/cpu.h
> @@ -5,8 +5,6 @@
>  #include "cpu-qom.h"
>  #include "exec/cpu-defs.h"
>  
> -#define ALIGNED_ONLY
> -
>  #if !defined(TARGET_SPARC64)
>  #define TARGET_DPREGS 16
>  #else
> diff --git a/target/xtensa/cpu.h b/target/xtensa/cpu.h
> index 2c277134f1..0459243e6b 100644
> --- a/target/xtensa/cpu.h
> +++ 

[Qemu-devel] [PATCH] configure: Define target access alignment in configure

2019-07-18 Thread tony.nguyen
This patch moves the define of target access alignment earlier from
target/foo/cpu.h to configure.

Suggested in Richard Henderson's reply to "[PATCH 1/4] tcg: TCGMemOp is now
accelerator independent MemOp"

Signed-off-by: Tony Nguyen 
---
 configure | 12 ++--
 include/exec/poison.h |  1 +
 include/qom/cpu.h |  2 +-
 target/alpha/cpu.h|  2 --
 target/hppa/cpu.h |  1 -
 target/mips/cpu.h |  2 --
 target/sh4/cpu.h  |  2 --
 target/sparc/cpu.h|  2 --
 target/xtensa/cpu.h   |  2 --
 tcg/tcg.c |  2 +-
 tcg/tcg.h |  8 +---
 11 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/configure b/configure
index eb635c3b9a..c07687c656 100755
--- a/configure
+++ b/configure
@@ -7424,11 +7424,16 @@ for target in $target_list; do
 target_dir="$target"
 config_target_mak=$target_dir/config-target.mak
 target_name=$(echo $target | cut -d '-' -f 1)
+target_aligned_only="no"
+case "$target_name" in
+  
alpha|hppa|mips64el|mips64|mipsel|mips|mipsn32|mipsn32el|sh4|sh4eb|sparc|sparc64|sparc32plus|xtensa|xtensaeb)
+  target_aligned_only="yes"
+  ;;
+esac
 target_bigendian="no"
-
 case "$target_name" in
   
armeb|aarch64_be|hppa|lm32|m68k|microblaze|mips|mipsn32|mips64|moxie|or1k|ppc|ppc64|ppc64abi32|s390x|sh4eb|sparc|sparc64|sparc32plus|xtensaeb)
-  target_bigendian=yes
+  target_bigendian="yes"
   ;;
 esac
 target_softmmu="no"
@@ -7710,6 +7715,9 @@ fi
 if supported_whpx_target $target; then
 echo "CONFIG_WHPX=y" >> $config_target_mak
 fi
+if test "$target_aligned_only" = "yes" ; then
+  echo "TARGET_ALIGNED_ONLY=y" >> $config_target_mak
+fi
 if test "$target_bigendian" = "yes" ; then
   echo "TARGET_WORDS_BIGENDIAN=y" >> $config_target_mak
 fi
diff --git a/include/exec/poison.h b/include/exec/poison.h
index b862320fa6..955eb863ab 100644
--- a/include/exec/poison.h
+++ b/include/exec/poison.h
@@ -35,6 +35,7 @@
 #pragma GCC poison TARGET_UNICORE32
 #pragma GCC poison TARGET_XTENSA
 
+#pragma GCC poison TARGET_ALIGNED_ONLY
 #pragma GCC poison TARGET_HAS_BFLT
 #pragma GCC poison TARGET_NAME
 #pragma GCC poison TARGET_SUPPORTS_MTTCG
diff --git a/include/qom/cpu.h b/include/qom/cpu.h
index 5ee0046b62..9b50b73339 100644
--- a/include/qom/cpu.h
+++ b/include/qom/cpu.h
@@ -89,7 +89,7 @@ struct TranslationBlock;
  * @do_unassigned_access: Callback for unassigned access handling.
  * (this is deprecated: new targets should use do_transaction_failed instead)
  * @do_unaligned_access: Callback for unaligned access handling, if
- * the target defines #ALIGNED_ONLY.
+ * the target defines #TARGET_ALIGNED_ONLY.
  * @do_transaction_failed: Callback for handling failed memory transactions
  * (ie bus faults or external aborts; not MMU faults)
  * @virtio_is_big_endian: Callback to return %true if a CPU which supports
diff --git a/target/alpha/cpu.h b/target/alpha/cpu.h
index b3e8a823e1..16eb8047cf 100644
--- a/target/alpha/cpu.h
+++ b/target/alpha/cpu.h
@@ -23,8 +23,6 @@
 #include "cpu-qom.h"
 #include "exec/cpu-defs.h"
 
-#define ALIGNED_ONLY
-
 /* Alpha processors have a weak memory model */
 #define TCG_GUEST_DEFAULT_MO  (0)
 
diff --git a/target/hppa/cpu.h b/target/hppa/cpu.h
index aab251bc4b..2be67c289a 100644
--- a/target/hppa/cpu.h
+++ b/target/hppa/cpu.h
@@ -30,7 +30,6 @@
basis.  It's probably easier to fall back to a strong memory model.  */
 #define TCG_GUEST_DEFAULT_MOTCG_MO_ALL
 
-#define ALIGNED_ONLY
 #define MMU_KERNEL_IDX   0
 #define MMU_USER_IDX 3
 #define MMU_PHYS_IDX 4
diff --git a/target/mips/cpu.h b/target/mips/cpu.h
index 21c0615e02..c13cd4eb31 100644
--- a/target/mips/cpu.h
+++ b/target/mips/cpu.h
@@ -1,8 +1,6 @@
 #ifndef MIPS_CPU_H
 #define MIPS_CPU_H
 
-#define ALIGNED_ONLY
-
 #include "cpu-qom.h"
 #include "exec/cpu-defs.h"
 #include "fpu/softfloat.h"
diff --git a/target/sh4/cpu.h b/target/sh4/cpu.h
index aee733eaaa..ecaa7a18a9 100644
--- a/target/sh4/cpu.h
+++ b/target/sh4/cpu.h
@@ -23,8 +23,6 @@
 #include "cpu-qom.h"
 #include "exec/cpu-defs.h"
 
-#define ALIGNED_ONLY
-
 /* CPU Subtypes */
 #define SH_CPU_SH7750  (1 << 0)
 #define SH_CPU_SH7750S (1 << 1)
diff --git a/target/sparc/cpu.h b/target/sparc/cpu.h
index 8ed2250cd0..1406f0ba2e 100644
--- a/target/sparc/cpu.h
+++ b/target/sparc/cpu.h
@@ -5,8 +5,6 @@
 #include "cpu-qom.h"
 #include "exec/cpu-defs.h"
 
-#define ALIGNED_ONLY
-
 #if !defined(TARGET_SPARC64)
 #define TARGET_DPREGS 16
 #else
diff --git a/target/xtensa/cpu.h b/target/xtensa/cpu.h
index 2c277134f1..0459243e6b 100644
--- a/target/xtensa/cpu.h
+++ b/target/xtensa/cpu.h
@@ -32,8 +32,6 @@
 #include "exec/cpu-defs.h"
 #include "xtensa-isa.h"
 
-#define ALIGNED_ONLY
-
 /* Xtensa processors have a weak memory model */
 #define TCG_GUEST_DEFAULT_MO  (0)
 
diff --git a/tcg/tcg.c b/tcg/tcg.c
index be2c33c400..8d23fb0592 100644
--- a/tcg/tcg.c
+++ b/tcg/tcg.c
@@ -1926,7 +1926,7 @@ static const char * const ldst_name[] =
 };
 
 static const char * const alignment_name[(MO_AMASK >> MO_ASHIFT) + 1] = {

Re: [Qemu-devel] [PATCH] configure: fix sdl detection using sdl2-config

2019-07-12 Thread Philippe Mathieu-Daudé
Cc'ing Gerd

On 7/11/19 12:55 AM, Carlo Marcelo Arenas Belón wrote:
> If SDL2 is requested but pkg-config doesn't have a module for it
> configure should fallback to use sdl*-config, but wasn't able to
> because and old variable (from SDL) was being used by mistake.
> 
> Correct the variable name and complete other related changes so
> there are no more references to the old SDL.
> 
> Fixes: 0015ca5cbabe ("ui: remove support for SDL1.2 in favour of SDL2")
> Signed-off-by: Carlo Marcelo Arenas Belón 
> ---
>  configure | 9 -
>  1 file changed, 4 insertions(+), 5 deletions(-)
> 
> diff --git a/configure b/configure
> index 4983c8b533..0f88ba98a6 100755
> --- a/configure
> +++ b/configure
> @@ -3016,15 +3016,15 @@ fi
>  ##
>  # SDL probe
>  
> -# Look for sdl configuration program (pkg-config or sdl-config).  Try
> -# sdl-config even without cross prefix, and favour pkg-config over 
> sdl-config.
> +# Look for sdl configuration program (pkg-config or sdl2-config).  Try
> +# sdl2-config even without cross prefix, and favour pkg-config over 
> sdl2-config.
>  
>  sdl_probe ()
>  {
>if $pkg_config sdl2 --exists; then
>  sdlconfig="$pkg_config sdl2"
>  sdlversion=$($sdlconfig --modversion 2>/dev/null)
> -  elif has ${sdl_config}; then
> +  elif has "$sdl2_config"; then
>  sdlconfig="$sdl2_config"
>  sdlversion=$($sdlconfig --version)
>else
> @@ -3035,7 +3035,7 @@ sdl_probe ()
>  # no need to do the rest
>  return
>fi
> -  if test -n "$cross_prefix" && test "$(basename "$sdlconfig")" = 
> sdl-config; then
> +  if test -n "$cross_prefix" && test "$(basename "$sdlconfig")" = 
> sdl2-config; then
>  echo warning: using "\"$sdlconfig\"" to detect cross-compiled sdl >&2
>fi
>  
> @@ -8019,7 +8019,6 @@ preserve_env PKG_CONFIG
>  preserve_env PKG_CONFIG_LIBDIR
>  preserve_env PKG_CONFIG_PATH
>  preserve_env PYTHON
> -preserve_env SDL_CONFIG
>  preserve_env SDL2_CONFIG
>  preserve_env SMBD
>  preserve_env STRIP
> 



Re: [Qemu-devel] [PATCH] configure: fix sdl detection using sdl2-config

2019-07-12 Thread Thomas Huth
On 11/07/2019 00.55, Carlo Marcelo Arenas Belón wrote:
> If SDL2 is requested but pkg-config doesn't have a module for it
> configure should fallback to use sdl*-config, but wasn't able to
> because and old variable (from SDL) was being used by mistake.
> 
> Correct the variable name and complete other related changes so
> there are no more references to the old SDL.
> 
> Fixes: 0015ca5cbabe ("ui: remove support for SDL1.2 in favour of SDL2")
> Signed-off-by: Carlo Marcelo Arenas Belón 
> ---
>  configure | 9 -
>  1 file changed, 4 insertions(+), 5 deletions(-)
> 
> diff --git a/configure b/configure
> index 4983c8b533..0f88ba98a6 100755
> --- a/configure
> +++ b/configure
> @@ -3016,15 +3016,15 @@ fi
>  ##
>  # SDL probe
>  
> -# Look for sdl configuration program (pkg-config or sdl-config).  Try
> -# sdl-config even without cross prefix, and favour pkg-config over 
> sdl-config.
> +# Look for sdl configuration program (pkg-config or sdl2-config).  Try
> +# sdl2-config even without cross prefix, and favour pkg-config over 
> sdl2-config.
>  
>  sdl_probe ()
>  {
>if $pkg_config sdl2 --exists; then
>  sdlconfig="$pkg_config sdl2"
>  sdlversion=$($sdlconfig --modversion 2>/dev/null)
> -  elif has ${sdl_config}; then
> +  elif has "$sdl2_config"; then
>  sdlconfig="$sdl2_config"
>  sdlversion=$($sdlconfig --version)
>else
> @@ -3035,7 +3035,7 @@ sdl_probe ()
>  # no need to do the rest
>  return
>fi
> -  if test -n "$cross_prefix" && test "$(basename "$sdlconfig")" = 
> sdl-config; then
> +  if test -n "$cross_prefix" && test "$(basename "$sdlconfig")" = 
> sdl2-config; then
>  echo warning: using "\"$sdlconfig\"" to detect cross-compiled sdl >&2
>fi
>  
> @@ -8019,7 +8019,6 @@ preserve_env PKG_CONFIG
>  preserve_env PKG_CONFIG_LIBDIR
>  preserve_env PKG_CONFIG_PATH
>  preserve_env PYTHON
> -preserve_env SDL_CONFIG
>  preserve_env SDL2_CONFIG
>  preserve_env SMBD
>  preserve_env STRIP
> 

Reviewed-by: Thomas Huth 



[Qemu-devel] [PATCH] configure: fix sdl detection using sdl2-config

2019-07-10 Thread Carlo Marcelo Arenas Belón
If SDL2 is requested but pkg-config doesn't have a module for it
configure should fallback to use sdl*-config, but wasn't able to
because and old variable (from SDL) was being used by mistake.

Correct the variable name and complete other related changes so
there are no more references to the old SDL.

Fixes: 0015ca5cbabe ("ui: remove support for SDL1.2 in favour of SDL2")
Signed-off-by: Carlo Marcelo Arenas Belón 
---
 configure | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/configure b/configure
index 4983c8b533..0f88ba98a6 100755
--- a/configure
+++ b/configure
@@ -3016,15 +3016,15 @@ fi
 ##
 # SDL probe
 
-# Look for sdl configuration program (pkg-config or sdl-config).  Try
-# sdl-config even without cross prefix, and favour pkg-config over sdl-config.
+# Look for sdl configuration program (pkg-config or sdl2-config).  Try
+# sdl2-config even without cross prefix, and favour pkg-config over 
sdl2-config.
 
 sdl_probe ()
 {
   if $pkg_config sdl2 --exists; then
 sdlconfig="$pkg_config sdl2"
 sdlversion=$($sdlconfig --modversion 2>/dev/null)
-  elif has ${sdl_config}; then
+  elif has "$sdl2_config"; then
 sdlconfig="$sdl2_config"
 sdlversion=$($sdlconfig --version)
   else
@@ -3035,7 +3035,7 @@ sdl_probe ()
 # no need to do the rest
 return
   fi
-  if test -n "$cross_prefix" && test "$(basename "$sdlconfig")" = sdl-config; 
then
+  if test -n "$cross_prefix" && test "$(basename "$sdlconfig")" = sdl2-config; 
then
 echo warning: using "\"$sdlconfig\"" to detect cross-compiled sdl >&2
   fi
 
@@ -8019,7 +8019,6 @@ preserve_env PKG_CONFIG
 preserve_env PKG_CONFIG_LIBDIR
 preserve_env PKG_CONFIG_PATH
 preserve_env PYTHON
-preserve_env SDL_CONFIG
 preserve_env SDL2_CONFIG
 preserve_env SMBD
 preserve_env STRIP
-- 
2.22.0




Re: [Qemu-devel] [PATCH] configure: remove obsoleted $sparc_cpu variable

2019-07-10 Thread Philippe Mathieu-Daudé
On 7/10/19 1:43 AM, Carlo Marcelo Arenas Belón wrote:
> 9b9c37c364 ("tcg-sparc: Assume v9 cpu always, i.e. force v8plus in
> 32-bit mode.", 2012-09-21) removed the need for this variable and
> most of the references to it, but this one.
> 
> Remove defunct code, no effect or functionality change expected.
> 
> Signed-off-by: Carlo Marcelo Arenas Belón 
> ---
>  configure | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/configure b/configure
> index 4983c8b533..7518f201ab 100755
> --- a/configure
> +++ b/configure
> @@ -6378,9 +6378,6 @@ if test "$vnc" = "yes" ; then
>  echo "VNC JPEG support  $vnc_jpeg"
>  echo "VNC PNG support   $vnc_png"
>  fi
> -if test -n "$sparc_cpu"; then
> -echo "Target Sparc Arch $sparc_cpu"
> -fi
>  echo "xen support   $xen"
>  if test "$xen" = "yes" ; then
>echo "xen ctrl version  $xen_ctrl_version"
> 

Reviewed-by: Philippe Mathieu-Daudé 
Tested-by: Philippe Mathieu-Daudé 



Re: [Qemu-devel] [PATCH] configure: remove obsoleted $sparc_cpu variable

2019-07-10 Thread Richard Henderson
On 7/10/19 1:43 AM, Carlo Marcelo Arenas Belón wrote:
> 9b9c37c364 ("tcg-sparc: Assume v9 cpu always, i.e. force v8plus in
> 32-bit mode.", 2012-09-21) removed the need for this variable and
> most of the references to it, but this one.
> 
> Remove defunct code, no effect or functionality change expected.
> 
> Signed-off-by: Carlo Marcelo Arenas Belón 
> ---
>  configure | 3 ---
>  1 file changed, 3 deletions(-)

Reviewed-by: Richard Henderson 


r~



[Qemu-devel] [PATCH] configure: remove obsoleted $sparc_cpu variable

2019-07-09 Thread Carlo Marcelo Arenas Belón
9b9c37c364 ("tcg-sparc: Assume v9 cpu always, i.e. force v8plus in
32-bit mode.", 2012-09-21) removed the need for this variable and
most of the references to it, but this one.

Remove defunct code, no effect or functionality change expected.

Signed-off-by: Carlo Marcelo Arenas Belón 
---
 configure | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/configure b/configure
index 4983c8b533..7518f201ab 100755
--- a/configure
+++ b/configure
@@ -6378,9 +6378,6 @@ if test "$vnc" = "yes" ; then
 echo "VNC JPEG support  $vnc_jpeg"
 echo "VNC PNG support   $vnc_png"
 fi
-if test -n "$sparc_cpu"; then
-echo "Target Sparc Arch $sparc_cpu"
-fi
 echo "xen support   $xen"
 if test "$xen" = "yes" ; then
   echo "xen ctrl version  $xen_ctrl_version"
-- 
2.22.0




Re: [Qemu-devel] [PATCH] configure: linux-user doesn't need neither fdt nor slirp

2019-06-21 Thread Philippe Mathieu-Daudé
On 6/21/19 3:05 PM, Laurent Vivier wrote:
> if softmmu is not enabled, we disable by default fdt and
> slirp as they are only used by -softmmu targets.
> 
> A side effect is the git submodules are not cloned
> if they are not needed.
> 
> Clone and build can be forced with --enable-fdt and
> --enable-slirp.
> 
> Signed-off-by: Laurent Vivier 
> ---
>  configure | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/configure b/configure
> index b091b82cb371..4b3853298c79 100755
> --- a/configure
> +++ b/configure
> @@ -4066,6 +4066,11 @@ if test "$fdt_required" = "yes"; then
>fdt=yes
>  fi
>  
> +# linux-user doesn't need fdt

"fdt is only required when building softmmu targets"

(we don't need it to build tools such qemu-img)

> +if test -z "$fdt" -a "$softmmu" != "yes" ; then
> +fdt="no"
> +fi
> +
>  if test "$fdt" != "no" ; then
>fdt_libs="-lfdt"
># explicitly check for libfdt_env.h as it is missing in some stable 
> installs
> @@ -5923,6 +5928,11 @@ fi
>  ##
>  # check for slirp
>  
> +# linux-user doesn't need slirp

"slirp is only required when building softmmu targets"

> +if test -z "$slirp" -a "$softmmu" != "yes" ; then
> +slirp="no"
> +fi
> +
>  case "$slirp" in
>"" | yes)
>  if $pkg_config slirp; then
> 

Reviewed-by: Philippe Mathieu-Daudé 
Tested-by: Philippe Mathieu-Daudé 



Re: [Qemu-devel] [PATCH] configure: linux-user doesn't need neither fdt nor slirp

2019-06-21 Thread Marc-André Lureau
Hi

On Fri, Jun 21, 2019 at 3:05 PM Laurent Vivier  wrote:
>
> if softmmu is not enabled, we disable by default fdt and
> slirp as they are only used by -softmmu targets.
>
> A side effect is the git submodules are not cloned
> if they are not needed.
>
> Clone and build can be forced with --enable-fdt and
> --enable-slirp.
>
> Signed-off-by: Laurent Vivier 

lgtm
Reviewed-by: Marc-André Lureau 

> ---
>  configure | 10 ++
>  1 file changed, 10 insertions(+)
>
> diff --git a/configure b/configure
> index b091b82cb371..4b3853298c79 100755
> --- a/configure
> +++ b/configure
> @@ -4066,6 +4066,11 @@ if test "$fdt_required" = "yes"; then
>fdt=yes
>  fi
>
> +# linux-user doesn't need fdt
> +if test -z "$fdt" -a "$softmmu" != "yes" ; then
> +fdt="no"
> +fi
> +
>  if test "$fdt" != "no" ; then
>fdt_libs="-lfdt"
># explicitly check for libfdt_env.h as it is missing in some stable 
> installs
> @@ -5923,6 +5928,11 @@ fi
>  ##
>  # check for slirp
>
> +# linux-user doesn't need slirp
> +if test -z "$slirp" -a "$softmmu" != "yes" ; then
> +slirp="no"
> +fi
> +
>  case "$slirp" in
>"" | yes)
>  if $pkg_config slirp; then
> --
> 2.21.0
>



[Qemu-devel] [PATCH] configure: linux-user doesn't need neither fdt nor slirp

2019-06-21 Thread Laurent Vivier
if softmmu is not enabled, we disable by default fdt and
slirp as they are only used by -softmmu targets.

A side effect is the git submodules are not cloned
if they are not needed.

Clone and build can be forced with --enable-fdt and
--enable-slirp.

Signed-off-by: Laurent Vivier 
---
 configure | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/configure b/configure
index b091b82cb371..4b3853298c79 100755
--- a/configure
+++ b/configure
@@ -4066,6 +4066,11 @@ if test "$fdt_required" = "yes"; then
   fdt=yes
 fi
 
+# linux-user doesn't need fdt
+if test -z "$fdt" -a "$softmmu" != "yes" ; then
+fdt="no"
+fi
+
 if test "$fdt" != "no" ; then
   fdt_libs="-lfdt"
   # explicitly check for libfdt_env.h as it is missing in some stable installs
@@ -5923,6 +5928,11 @@ fi
 ##
 # check for slirp
 
+# linux-user doesn't need slirp
+if test -z "$slirp" -a "$softmmu" != "yes" ; then
+slirp="no"
+fi
+
 case "$slirp" in
   "" | yes)
 if $pkg_config slirp; then
-- 
2.21.0




[Qemu-devel] [PATCH] configure: use valid args testing sem_timedwait

2019-06-17 Thread Daniel P . Berrangé
The sem_timedwait function has been annotated as requiring
non-null args in latest header files from GCC snapshot
representing the future 2.30 release.

This causes configure to fail when -Werror is used:

config-temp/qemu-conf.c: In function ‘main’:
config-temp/qemu-conf.c:2:25: error: null argument where non-null required 
(argument 1) [-Werror=nonnull]
2 | int main(void) { return sem_timedwait(0, 0); }
  | ^
config-temp/qemu-conf.c:2:25: error: null argument where non-null required 
(argument 2) [-Werror=nonnull]

Signed-off-by: Daniel P. Berrangé 
---
 configure | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure b/configure
index b091b82cb3..6632d05fc7 100755
--- a/configure
+++ b/configure
@@ -5139,7 +5139,7 @@ fi
 sem_timedwait=no
 cat > $TMPC << EOF
 #include 
-int main(void) { return sem_timedwait(0, 0); }
+int main(void) { sem_t s; struct timespec t = {0}; return sem_timedwait(, 
); }
 EOF
 if compile_prog "" "" ; then
 sem_timedwait=yes
-- 
2.21.0




Re: [Qemu-devel] [PATCH] configure: remove tpm_passthrough & tpm_emulator

2019-05-24 Thread Paolo Bonzini
On 24/05/19 20:14, Marc-André Lureau wrote:
> This is a left-over from commit 7aaa6a16373 "tpm: express dependencies
> with Kconfig".
> 
> Signed-off-by: Marc-André Lureau 
> ---
>  configure | 10 --
>  1 file changed, 10 deletions(-)
> 
> diff --git a/configure b/configure
> index 528b9ff705..4da99ee750 100755
> --- a/configure
> +++ b/configure
> @@ -6434,8 +6434,6 @@ echo "gcov  $gcov_tool"
>  echo "gcov enabled  $gcov"
>  echo "TPM support   $tpm"
>  echo "libssh2 support   $libssh2"
> -echo "TPM passthrough   $tpm_passthrough"
> -echo "TPM emulator  $tpm_emulator"
>  echo "QOM debugging $qom_cast_debug"
>  echo "Live block migration $live_block_migration"
>  echo "lzo support   $lzo"
> @@ -7133,14 +7131,6 @@ fi
>  
>  if test "$tpm" = "yes"; then
>echo 'CONFIG_TPM=$(CONFIG_SOFTMMU)' >> $config_host_mak
> -  # TPM passthrough support?
> -  if test "$tpm_passthrough" = "yes"; then
> -echo "CONFIG_TPM_PASSTHROUGH=y" >> $config_host_mak
> -  fi
> -  # TPM emulator support?
> -  if test "$tpm_emulator" = "yes"; then
> -echo "CONFIG_TPM_EMULATOR=y" >> $config_host_mak
> -  fi
>  fi
>  
>  echo "TRACE_BACKENDS=$trace_backends" >> $config_host_mak
> 

Queued, thanks.

Paolo



[Qemu-devel] [PATCH] configure: remove tpm_passthrough & tpm_emulator

2019-05-24 Thread Marc-André Lureau
This is a left-over from commit 7aaa6a16373 "tpm: express dependencies
with Kconfig".

Signed-off-by: Marc-André Lureau 
---
 configure | 10 --
 1 file changed, 10 deletions(-)

diff --git a/configure b/configure
index 528b9ff705..4da99ee750 100755
--- a/configure
+++ b/configure
@@ -6434,8 +6434,6 @@ echo "gcov  $gcov_tool"
 echo "gcov enabled  $gcov"
 echo "TPM support   $tpm"
 echo "libssh2 support   $libssh2"
-echo "TPM passthrough   $tpm_passthrough"
-echo "TPM emulator  $tpm_emulator"
 echo "QOM debugging $qom_cast_debug"
 echo "Live block migration $live_block_migration"
 echo "lzo support   $lzo"
@@ -7133,14 +7131,6 @@ fi
 
 if test "$tpm" = "yes"; then
   echo 'CONFIG_TPM=$(CONFIG_SOFTMMU)' >> $config_host_mak
-  # TPM passthrough support?
-  if test "$tpm_passthrough" = "yes"; then
-echo "CONFIG_TPM_PASSTHROUGH=y" >> $config_host_mak
-  fi
-  # TPM emulator support?
-  if test "$tpm_emulator" = "yes"; then
-echo "CONFIG_TPM_EMULATOR=y" >> $config_host_mak
-  fi
 fi
 
 echo "TRACE_BACKENDS=$trace_backends" >> $config_host_mak
-- 
2.22.0.rc1.1.g079e7d2849.dirty




Re: [Qemu-devel] [PATCH] configure: Only enable iconv if curses is enabled

2019-05-24 Thread Gerd Hoffmann
On Fri, May 17, 2019 at 04:18:05PM -0500, Kumar Gala wrote:
> iconv is only used with if curses is enabled, there's no need to do any
> configure checking for iconv, if curses is disabled.  Also, ignore
> --enable-iconv if curses is already disabled.

How about just doing this ...

--- a/configure
+++ b/configure
@@ -3551,6 +3551,7 @@ EOF
   feature_not_found "curses" "Install ncurses devel"
 fi
 curses=no
+iconv=no  # curses is the only user
   fi
 fi

... instead?



Re: [Qemu-devel] [PATCH] configure: Fix spelling of sdl-image in --help

2019-05-18 Thread Thomas Huth
On 17/05/2019 20.32, Markus Armbruster wrote:
> Fixes: a442fe2f2b2f20e7be0934277e9400b844b11999
> Cc: qemu-triv...@nongnu.org
> Signed-off-by: Markus Armbruster 
> ---
>  configure | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/configure b/configure
> index d2fc346302..cef51b2a0b 100755
> --- a/configure
> +++ b/configure
> @@ -1745,7 +1745,7 @@ disabled with --disable-FEATURE, default is enabled if 
> available:
>gcrypt  libgcrypt cryptography support
>auth-pamPAM access control
>sdl SDL UI
> -  sdl_image   SDL Image support for icons
> +  sdl-image   SDL Image support for icons
>gtk gtk UI
>vte vte support for the gtk UI
>curses  curses UI
> 

Reviewed-by: Thomas Huth 



[Qemu-devel] [PATCH] configure: Only enable iconv if curses is enabled

2019-05-17 Thread Kumar Gala
iconv is only used with if curses is enabled, there's no need to do any
configure checking for iconv, if curses is disabled.  Also, ignore
--enable-iconv if curses is already disabled.

Signed-off-by: Kumar Gala 
---
 configure | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/configure b/configure
index d2fc346302..a1b60fa977 100755
--- a/configure
+++ b/configure
@@ -1235,13 +1235,18 @@ for opt do
   ;;
   --disable-stack-protector) stack_protector="no"
   ;;
-  --disable-curses) curses="no"
+  --disable-curses)
+  curses="no"
+  iconv="no"
   ;;
   --enable-curses) curses="yes"
   ;;
   --disable-iconv) iconv="no"
   ;;
-  --enable-iconv) iconv="yes"
+  --enable-iconv)
+  if test "$curses" != "no" ; then
+ iconv="yes"
+  fi
   ;;
   --disable-curl) curl="no"
   ;;
-- 
2.20.1




[Qemu-devel] [PATCH] configure: Fix spelling of sdl-image in --help

2019-05-17 Thread Markus Armbruster
Fixes: a442fe2f2b2f20e7be0934277e9400b844b11999
Cc: qemu-triv...@nongnu.org
Signed-off-by: Markus Armbruster 
---
 configure | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure b/configure
index d2fc346302..cef51b2a0b 100755
--- a/configure
+++ b/configure
@@ -1745,7 +1745,7 @@ disabled with --disable-FEATURE, default is enabled if 
available:
   gcrypt  libgcrypt cryptography support
   auth-pamPAM access control
   sdl SDL UI
-  sdl_image   SDL Image support for icons
+  sdl-image   SDL Image support for icons
   gtk gtk UI
   vte vte support for the gtk UI
   curses  curses UI
-- 
2.17.2




Re: [Qemu-devel] [PATCH] configure: only link capstone to emulation targets

2019-05-16 Thread Richard Henderson
On 5/16/19 4:39 AM, Daniel P. Berrangé wrote:
> Only the emulators link to code that uses capstone, so adding it to the
> global LIBs places undesirable dependancies on other binaries, in
> particular the tools.
> 
> There is no variable that covers both user emulation and machine
> emulation, so add a new "$libs_cpu" for this purpose.
> 
> In particular this removes the 8 MB capstone dep from the things
> qemu-img links against, allowing for a more minimal installation
> in scenarios that don't want system emulators installed.
> 
> Signed-off-by: Daniel P. Berrangé 
> ---
>  Makefile.target | 1 +
>  configure   | 6 --
>  2 files changed, 5 insertions(+), 2 deletions(-)

Reviewed-by: Richard Henderson 


r~



[Qemu-devel] [PATCH] configure: only link capstone to emulation targets

2019-05-16 Thread Daniel P . Berrangé
Only the emulators link to code that uses capstone, so adding it to the
global LIBs places undesirable dependancies on other binaries, in
particular the tools.

There is no variable that covers both user emulation and machine
emulation, so add a new "$libs_cpu" for this purpose.

In particular this removes the 8 MB capstone dep from the things
qemu-img links against, allowing for a more minimal installation
in scenarios that don't want system emulators installed.

Signed-off-by: Daniel P. Berrangé 
---
 Makefile.target | 1 +
 configure   | 6 --
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/Makefile.target b/Makefile.target
index ae02495951..15e5191f36 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -117,6 +117,7 @@ obj-$(CONFIG_TCG) += fpu/softfloat.o
 obj-y += target/$(TARGET_BASE_ARCH)/
 obj-y += disas.o
 obj-$(call notempty,$(TARGET_XML_FILES)) += gdbstub-xml.o
+LIBS := $(libs_cpu) $(LIBS)
 
 #
 # Linux user emulator target
diff --git a/configure b/configure
index 8999698bc2..64f09c5905 100755
--- a/configure
+++ b/configure
@@ -289,6 +289,7 @@ audio_drv_list=""
 block_drv_rw_whitelist=""
 block_drv_ro_whitelist=""
 host_cc="cc"
+libs_cpu=""
 libs_softmmu=""
 libs_tools=""
 audio_pt_int=""
@@ -5015,12 +5016,12 @@ case "$capstone" in
 else
   LIBCAPSTONE=libcapstone.a
 fi
-LIBS="-L\$(BUILD_DIR)/capstone -lcapstone $LIBS"
+libs_cpu="-L\$(BUILD_DIR)/capstone -lcapstone $libs_cpu"
 ;;
 
   system)
 QEMU_CFLAGS="$QEMU_CFLAGS $($pkg_config --cflags capstone)"
-LIBS="$($pkg_config --libs capstone) $LIBS"
+libs_cpu="$($pkg_config --libs capstone) $libs_cpu"
 ;;
 
   no)
@@ -6488,6 +6489,7 @@ echo "qemu_helperdir=$libexecdir" >> $config_host_mak
 echo "qemu_localedir=$qemu_localedir" >> $config_host_mak
 echo "qemu_icondir=$qemu_icondir" >> $config_host_mak
 echo "qemu_desktopdir=$qemu_desktopdir" >> $config_host_mak
+echo "libs_cpu=$libs_cpu" >> $config_host_mak
 echo "libs_softmmu=$libs_softmmu" >> $config_host_mak
 echo "GIT=$git" >> $config_host_mak
 echo "GIT_SUBMODULES=$git_submodules" >> $config_host_mak
-- 
2.21.0




Re: [Qemu-devel] [PATCH] configure: Disable slirp if --disable-system

2019-05-15 Thread Aleksandar Markovic
On May 15, 2019 12:07 PM, "Peter Maydell"  wrote:
>
> On Tue, 14 May 2019 at 20:16, Aleksandar Markovic
>  wrote:
> >
> > On May 13, 2019 11:14 PM, "Richard Henderson" <
richard.hender...@linaro.org>
> > wrote:
> > >
> > > On 5/11/19 5:47 AM, Aleksandar Markovic wrote:
> > > > If no, the patch shoud be amended. If yes, the commit message
should be
> > > > extended.
> > >
> > > Like what?  I think it's pretty clear as is.
> > >
> >
> > Richard, no. In this case, there is a glaring discrepancy between the
title
> > and the functionality that the change provides. Much better title would
be
> > “configure: Disable slirp if no system mode target is selected”.
> >
> > I leave it to you to find out what can be improved in the commit
message.
>
> Aleksandar: I think this is not really a very productive stance to take.
> Richard thinks the commit message is reasonable. If you have something
> you would like him to change, I think we will reach a useful endpoint
> much more quickly and smoothly if you suggest some new text, rather than
> effectively saying "you need to think of something, and I'm going to keep
> making you rewrite it until you telepathically figure out what the text
> I wanted you to write is".
>

OK, Peter, no problem from my side. I was trying to make Richard think more
about what he writes in his commit messages, and how he organizes his code.
Sorry if this looked unproductive or even perhaps offensive.

Yours,
Aleksadar

> thanks
> -- PMM


Re: [Qemu-devel] [PATCH] configure: Disable slirp if --disable-system

2019-05-15 Thread Peter Maydell
On Tue, 14 May 2019 at 20:16, Aleksandar Markovic
 wrote:
>
> On May 13, 2019 11:14 PM, "Richard Henderson" 
> wrote:
> >
> > On 5/11/19 5:47 AM, Aleksandar Markovic wrote:
> > > If no, the patch shoud be amended. If yes, the commit message should be
> > > extended.
> >
> > Like what?  I think it's pretty clear as is.
> >
>
> Richard, no. In this case, there is a glaring discrepancy between the title
> and the functionality that the change provides. Much better title would be
> “configure: Disable slirp if no system mode target is selected”.
>
> I leave it to you to find out what can be improved in the commit message.

Aleksandar: I think this is not really a very productive stance to take.
Richard thinks the commit message is reasonable. If you have something
you would like him to change, I think we will reach a useful endpoint
much more quickly and smoothly if you suggest some new text, rather than
effectively saying "you need to think of something, and I'm going to keep
making you rewrite it until you telepathically figure out what the text
I wanted you to write is".

thanks
-- PMM



Re: [Qemu-devel] [PATCH] configure: Change capstone's default state to disabled

2019-05-14 Thread Programmingkid


> On May 12, 2019, at 9:47 AM, Thomas Huth  wrote:
> 
> On 11/05/2019 20.28, Programmingkid wrote:
>> 
>>> On May 11, 2019, at 2:05 PM, Thomas Huth  wrote:
>>> 
>>> On 11/05/2019 19.21, Programmingkid wrote:
 
> On Apr 20, 2019, at 6:40 AM, Thomas Huth  wrote:
> 
> On 19/04/2019 15.44, G 3 wrote:
> [...]
>> Thank you for replying. Capstone comes with QEMU? Every time I try to
>> compile QEMU I see an error relating to Capstone not being on my system.
>> Why do you feel that disabling Capstone by default is not a good idea?
>> 
>> Here is the error message I see when compiling QEMU:
>> 
>> CHK version_gen.h
>> make[1]: *** No rule to make target
>> `/Users/John/qemu-git/capstone/libcapstone.a'.  Stop.
>> make: *** [subdir-capstone] Error 2
> 
> I assume you're using a git checkout here, right? For git checkouts, the
> Makefile should take care of calling the scripts/git-submodule.sh script
> which should initialize the submodule in the capstone directory.
> 
> What's the content of your .git-submodule-status file? What does
> "configure" say about capstone support on your system?
> 
> Thomas
 
 Yes I use a git checkout.
 
 This is the contents of my .git-submodule-status file:
 #!/bin/sh
>>> [...]
>>> 
>>> That were the contents of scripts/git-submodule.sh. I meant the hidden
>>> file .git-submodule-status in the main directory.
>> 
>> This is it:
>> 88f18909db731a627456f26d779445f84e449536 dtc (v1.4.7)
>> f0da6726207b740f6101028b2992f918477a4b08 slirp (v4.0.0-rc0-25-gf0da672)
>> b64af41c3276f97f0e181920400ee056b9c88037 tests/fp/berkeley-softfloat-3 
>> (heads/master)
>> 5a59dcec19327396a011a17fd924aed4fec416b3 tests/fp/berkeley-testfloat-3 
>> (remotes/origin/HEAD)
>> 6b3d716e2b6472eb7189d3220552280ef3d832ce ui/keycodemapdb 
>> (heads/master-4-g6b3d716)
> 
> There should be an entry for capstone in here, too. :-/
> 
 I did a 'make clean' followed by a 'make distclean'. Then tried building 
 again using this command line:
 
 ./configure --target-list=ppc-softmmu,i386-softmmu,x86_64-softmmu
 make -j 4
>>> 
>>> That should normally populate the capstone directory. What happens if
>>> you run "make git-submodule-update" directly?
>> 
>> Here is the result:
>> $ make git-submodule-update
>> make[1]: Nothing to be done for `all'.
>> make[1]: *** No rule to make target 
>> `/Users/John/Documents/Development/Projects/Qemu/qemu-git/capstone/libcapstone.a'.
>>   Stop.
>> make: *** [subdir-capstone] Error 2
> 
> Apparently the submodule update is not working right for you. What do
> you get when you run:
> 
> git submodule update capstone
> 
> ?

Nothing appears to happen. When I try to make QEMU I still see the same error 
about no rule to make target libcapstone.a.

> 
 I took a look at the capstone folder. There is no 'make' file in this 
 folder. Should there be one?
>>> 
>>> Yes, the capstone folder should be populated automatically. Is it
>>> completely empty for you?
>> 
>> It isn't empty. All I see are two folders: obj and docs.
> 
> Maybe try to clean the folder first:
> 
> rm -r capstone
> mkdir capstone
> make git-submodule-update
> 
> If that does not help, maybe try a completely fresh git checkout?

That did it! The capstone folder is now fully populated. Thank you so much.


Re: [Qemu-devel] [PATCH] configure: Disable slirp if --disable-system

2019-05-14 Thread Aleksandar Markovic
On May 13, 2019 11:14 PM, "Richard Henderson" 
wrote:
>
> On 5/11/19 5:47 AM, Aleksandar Markovic wrote:
> >
> > On May 10, 2019 10:36 PM, "Richard Henderson" <
richard.hender...@linaro.org
> > > wrote:
> >>
> >> For linux-user, there is no need to add slirp to the set of
> >> git modules checked out, nor build it.
> >>
> >> This also avoids a makefile bug wrt insufficient dependencies
> >> on subdir-slirp.  If slirp/ is not initially present, the
> >> dependencies that check it out are associated with softmmu,
> >> which then generates a build error on slirp/ not present.
> >>
> >
> > Hi,
> >
> > Does this work if only user mode targets are specified via
ˊ--target-listˊ
> > switch?
>
> Yes.  There is a bit of code that converts such a target list to the same
> result as --disable-system, which is $softmmu = no.
>
> > If no, the patch shoud be amended. If yes, the commit message should be
> > extended.
>
> Like what?  I think it's pretty clear as is.
>

Richard, no. In this case, there is a glaring discrepancy between the title
and the functionality that the change provides. Much better title would be
“configure: Disable slirp if no system mode target is selected”.

I leave it to you to find out what can be improved in the commit message.

How well did you test your change? Did you try some corner cases?

I don't have concerns about the wording of the commit message only. I agree
with Thomas that combination of “no system mode target is selected” and
“--enable-slirp is used” must have some special handing. We can't just
leave the rest of the script to do whatever the current code happens to do.
The patch code should be completed.

Thanks,
Aleksandar

>
> r~


Re: [Qemu-devel] [PATCH] configure: Disable slirp if --disable-system

2019-05-13 Thread Richard Henderson
On 5/11/19 5:47 AM, Aleksandar Markovic wrote:
> 
> On May 10, 2019 10:36 PM, "Richard Henderson"  > wrote:
>>
>> For linux-user, there is no need to add slirp to the set of
>> git modules checked out, nor build it.
>>
>> This also avoids a makefile bug wrt insufficient dependencies
>> on subdir-slirp.  If slirp/ is not initially present, the
>> dependencies that check it out are associated with softmmu,
>> which then generates a build error on slirp/ not present.
>>
> 
> Hi,
> 
> Does this work if only user mode targets are specified via ˊ--target-listˊ
> switch?

Yes.  There is a bit of code that converts such a target list to the same
result as --disable-system, which is $softmmu = no.

> If no, the patch shoud be amended. If yes, the commit message should be
> extended.

Like what?  I think it's pretty clear as is.


r~



Re: [Qemu-devel] [PATCH] configure: Change capstone's default state to disabled

2019-05-13 Thread Daniel P . Berrangé
On Mon, May 13, 2019 at 10:48:58AM +0100, Peter Maydell wrote:
> On Mon, 13 May 2019 at 10:08, Daniel P. Berrangé  wrote:
> >
> > On Sun, May 12, 2019 at 03:47:49PM +0200, Thomas Huth wrote:
> > > Maybe try to clean the folder first:
> > >
> > >  rm -r capstone
> > >  mkdir capstone
> > >  make git-submodule-update
> > >
> > > If that does not help, maybe try a completely fresh git checkout?
> >
> > Rather than deleting stuff like that, it is best to use git to put your
> > dir back to a clean state.
> >
> >git submodule deinit --all --force
> >git clean -f -x -d
> 
> That git clean line will blow away any untracked files in
> your entire tree, won't it? If so, better move anything
> you cared about somewhere else first...

Yes, git clean blows away everything that isn't tracked.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|



Re: [Qemu-devel] [PATCH] configure: Change capstone's default state to disabled

2019-05-13 Thread Peter Maydell
On Mon, 13 May 2019 at 10:08, Daniel P. Berrangé  wrote:
>
> On Sun, May 12, 2019 at 03:47:49PM +0200, Thomas Huth wrote:
> > Maybe try to clean the folder first:
> >
> >  rm -r capstone
> >  mkdir capstone
> >  make git-submodule-update
> >
> > If that does not help, maybe try a completely fresh git checkout?
>
> Rather than deleting stuff like that, it is best to use git to put your
> dir back to a clean state.
>
>git submodule deinit --all --force
>git clean -f -x -d

That git clean line will blow away any untracked files in
your entire tree, won't it? If so, better move anything
you cared about somewhere else first...

thanks
-- PMM



Re: [Qemu-devel] [PATCH] configure: Change capstone's default state to disabled

2019-05-13 Thread Daniel P . Berrangé
On Sun, May 12, 2019 at 03:47:49PM +0200, Thomas Huth wrote:
> Maybe try to clean the folder first:
> 
>  rm -r capstone
>  mkdir capstone
>  make git-submodule-update
> 
> If that does not help, maybe try a completely fresh git checkout?

Rather than deleting stuff like that, it is best to use git to put your
dir back to a clean state.

   git submodule deinit --all --force
   git clean -f -x -d 

After doing this, then run  'configure' again with normal args and try
to build.

If it still fails, please provide the /full/ output printed by configure,
as well as all output from make, and also the contents of the 'config.log'
file.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|



Re: [Qemu-devel] [PATCH] configure: Change capstone's default state to disabled

2019-05-12 Thread Thomas Huth
On 11/05/2019 20.28, Programmingkid wrote:
> 
>> On May 11, 2019, at 2:05 PM, Thomas Huth  wrote:
>>
>> On 11/05/2019 19.21, Programmingkid wrote:
>>>
 On Apr 20, 2019, at 6:40 AM, Thomas Huth  wrote:

 On 19/04/2019 15.44, G 3 wrote:
[...]
> Thank you for replying. Capstone comes with QEMU? Every time I try to
> compile QEMU I see an error relating to Capstone not being on my system.
> Why do you feel that disabling Capstone by default is not a good idea?
>
> Here is the error message I see when compiling QEMU:
>
> CHK version_gen.h
> make[1]: *** No rule to make target
> `/Users/John/qemu-git/capstone/libcapstone.a'.  Stop.
> make: *** [subdir-capstone] Error 2

 I assume you're using a git checkout here, right? For git checkouts, the
 Makefile should take care of calling the scripts/git-submodule.sh script
 which should initialize the submodule in the capstone directory.

 What's the content of your .git-submodule-status file? What does
 "configure" say about capstone support on your system?

 Thomas
>>>
>>> Yes I use a git checkout.
>>>
>>> This is the contents of my .git-submodule-status file:
>>> #!/bin/sh
>> [...]
>>
>> That were the contents of scripts/git-submodule.sh. I meant the hidden
>> file .git-submodule-status in the main directory.
> 
> This is it:
>  88f18909db731a627456f26d779445f84e449536 dtc (v1.4.7)
>  f0da6726207b740f6101028b2992f918477a4b08 slirp (v4.0.0-rc0-25-gf0da672)
>  b64af41c3276f97f0e181920400ee056b9c88037 tests/fp/berkeley-softfloat-3 
> (heads/master)
>  5a59dcec19327396a011a17fd924aed4fec416b3 tests/fp/berkeley-testfloat-3 
> (remotes/origin/HEAD)
>  6b3d716e2b6472eb7189d3220552280ef3d832ce ui/keycodemapdb 
> (heads/master-4-g6b3d716)

There should be an entry for capstone in here, too. :-/

>>> I did a 'make clean' followed by a 'make distclean'. Then tried building 
>>> again using this command line:
>>>
>>> ./configure --target-list=ppc-softmmu,i386-softmmu,x86_64-softmmu
>>> make -j 4
>>
>> That should normally populate the capstone directory. What happens if
>> you run "make git-submodule-update" directly?
> 
> Here is the result:
> $ make git-submodule-update
> make[1]: Nothing to be done for `all'.
> make[1]: *** No rule to make target 
> `/Users/John/Documents/Development/Projects/Qemu/qemu-git/capstone/libcapstone.a'.
>   Stop.
> make: *** [subdir-capstone] Error 2

Apparently the submodule update is not working right for you. What do
you get when you run:

 git submodule update capstone

?

>>> I took a look at the capstone folder. There is no 'make' file in this 
>>> folder. Should there be one?
>>
>> Yes, the capstone folder should be populated automatically. Is it
>> completely empty for you?
> 
> It isn't empty. All I see are two folders: obj and docs.

Maybe try to clean the folder first:

 rm -r capstone
 mkdir capstone
 make git-submodule-update

If that does not help, maybe try a completely fresh git checkout?

 Thomas



Re: [Qemu-devel] [PATCH] configure: Change capstone's default state to disabled

2019-05-11 Thread Programmingkid


> On May 11, 2019, at 2:05 PM, Thomas Huth  wrote:
> 
> On 11/05/2019 19.21, Programmingkid wrote:
>> 
>>> On Apr 20, 2019, at 6:40 AM, Thomas Huth  wrote:
>>> 
>>> On 19/04/2019 15.44, G 3 wrote:
 
 On Apr 19, 2019, at 3:10 AM, Thomas Huth wrote:
 
> On 19/04/2019 00.47, John Arbuckle wrote:
>> Capstone is not necessary in order to use QEMU. Disable it by default.
>> This will save the user the pain of having to figure why QEMU isn't
>> building when this library is missing.
>> 
>> Signed-off-by: John Arbuckle 
>> ---
>> configure | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/configure b/configure
>> index 1c563a7027..77d7967f92 100755
>> --- a/configure
>> +++ b/configure
>> @@ -433,7 +433,7 @@ opengl_dmabuf="no"
>> cpuid_h="no"
>> avx2_opt=""
>> zlib="yes"
>> -capstone=""
>> +capstone="no"
>> lzo=""
>> snappy=""
>> bzip2=""
> 
> AFAIK we ship capstone as a submodule, so how can this be missing? Also,
> our philosophy is to keep everything enabled by default if possible, so
> that the code paths don't bitrot. Thus I don't think that disabling this
> by default is a good idea. ... so if you've got a problem here, there
> must be another solution (e.g. is the system capstone detection not
> working right on your system?).
> 
> Thomas
 
 Thank you for replying. Capstone comes with QEMU? Every time I try to
 compile QEMU I see an error relating to Capstone not being on my system.
 Why do you feel that disabling Capstone by default is not a good idea?
 
 Here is the error message I see when compiling QEMU:
 
 CHK version_gen.h
 make[1]: *** No rule to make target
 `/Users/John/qemu-git/capstone/libcapstone.a'.  Stop.
 make: *** [subdir-capstone] Error 2
>>> 
>>> I assume you're using a git checkout here, right? For git checkouts, the
>>> Makefile should take care of calling the scripts/git-submodule.sh script
>>> which should initialize the submodule in the capstone directory.
>>> 
>>> What's the content of your .git-submodule-status file? What does
>>> "configure" say about capstone support on your system?
>>> 
>>> Thomas
>> 
>> Yes I use a git checkout.
>> 
>> This is the contents of my .git-submodule-status file:
>> #!/bin/sh
> [...]
> 
> That were the contents of scripts/git-submodule.sh. I meant the hidden
> file .git-submodule-status in the main directory.

This is it:
 88f18909db731a627456f26d779445f84e449536 dtc (v1.4.7)
 f0da6726207b740f6101028b2992f918477a4b08 slirp (v4.0.0-rc0-25-gf0da672)
 b64af41c3276f97f0e181920400ee056b9c88037 tests/fp/berkeley-softfloat-3 
(heads/master)
 5a59dcec19327396a011a17fd924aed4fec416b3 tests/fp/berkeley-testfloat-3 
(remotes/origin/HEAD)
 6b3d716e2b6472eb7189d3220552280ef3d832ce ui/keycodemapdb 
(heads/master-4-g6b3d716)


> 
>> I did a 'make clean' followed by a 'make distclean'. Then tried building 
>> again using this command line:
>> 
>> ./configure --target-list=ppc-softmmu,i386-softmmu,x86_64-softmmu
>> make -j 4
> 
> That should normally populate the capstone directory. What happens if
> you run "make git-submodule-update" directly?

Here is the result:
$ make git-submodule-update
make[1]: Nothing to be done for `all'.
make[1]: *** No rule to make target 
`/Users/John/Documents/Development/Projects/Qemu/qemu-git/capstone/libcapstone.a'.
  Stop.
make: *** [subdir-capstone] Error 2


>> Here is the error message I see:
>> 
>> make[1]: *** No rule to make target 
>> `/Users/John/Documents/Development/Projects/Qemu/qemu-git/capstone/libcapstone.a'.
>>  Stop.
>> make: *** [subdir-capstone] Error 2
>> 
>> I took a look at the capstone folder. There is no 'make' file in this 
>> folder. Should there be one?
> 
> Yes, the capstone folder should be populated automatically. Is it
> completely empty for you?

It isn't empty. All I see are two folders: obj and docs.

Thank you.




Re: [Qemu-devel] [PATCH] configure: Change capstone's default state to disabled

2019-05-11 Thread Thomas Huth
On 11/05/2019 19.21, Programmingkid wrote:
> 
>> On Apr 20, 2019, at 6:40 AM, Thomas Huth  wrote:
>>
>> On 19/04/2019 15.44, G 3 wrote:
>>>
>>> On Apr 19, 2019, at 3:10 AM, Thomas Huth wrote:
>>>
 On 19/04/2019 00.47, John Arbuckle wrote:
> Capstone is not necessary in order to use QEMU. Disable it by default.
> This will save the user the pain of having to figure why QEMU isn't
> building when this library is missing.
>
> Signed-off-by: John Arbuckle 
> ---
>  configure | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/configure b/configure
> index 1c563a7027..77d7967f92 100755
> --- a/configure
> +++ b/configure
> @@ -433,7 +433,7 @@ opengl_dmabuf="no"
>  cpuid_h="no"
>  avx2_opt=""
>  zlib="yes"
> -capstone=""
> +capstone="no"
>  lzo=""
>  snappy=""
>  bzip2=""

 AFAIK we ship capstone as a submodule, so how can this be missing? Also,
 our philosophy is to keep everything enabled by default if possible, so
 that the code paths don't bitrot. Thus I don't think that disabling this
 by default is a good idea. ... so if you've got a problem here, there
 must be another solution (e.g. is the system capstone detection not
 working right on your system?).

  Thomas
>>>
>>> Thank you for replying. Capstone comes with QEMU? Every time I try to
>>> compile QEMU I see an error relating to Capstone not being on my system.
>>> Why do you feel that disabling Capstone by default is not a good idea?
>>>
>>> Here is the error message I see when compiling QEMU:
>>>
>>> CHK version_gen.h
>>> make[1]: *** No rule to make target
>>> `/Users/John/qemu-git/capstone/libcapstone.a'.  Stop.
>>> make: *** [subdir-capstone] Error 2
>>
>> I assume you're using a git checkout here, right? For git checkouts, the
>> Makefile should take care of calling the scripts/git-submodule.sh script
>> which should initialize the submodule in the capstone directory.
>>
>> What's the content of your .git-submodule-status file? What does
>> "configure" say about capstone support on your system?
>>
>> Thomas
> 
> Yes I use a git checkout.
> 
> This is the contents of my .git-submodule-status file:
> #!/bin/sh
[...]

That were the contents of scripts/git-submodule.sh. I meant the hidden
file .git-submodule-status in the main directory.

> I did a 'make clean' followed by a 'make distclean'. Then tried building 
> again using this command line:
> 
> ./configure --target-list=ppc-softmmu,i386-softmmu,x86_64-softmmu
> make -j 4

That should normally populate the capstone directory. What happens if
you run "make git-submodule-update" directly?

> Here is the error message I see:
> 
> make[1]: *** No rule to make target 
> `/Users/John/Documents/Development/Projects/Qemu/qemu-git/capstone/libcapstone.a'.
>   Stop.
> make: *** [subdir-capstone] Error 2
> 
> I took a look at the capstone folder. There is no 'make' file in this folder. 
> Should there be one?

Yes, the capstone folder should be populated automatically. Is it
completely empty for you?

 Thomas




Re: [Qemu-devel] [PATCH] configure: Change capstone's default state to disabled

2019-05-11 Thread Programmingkid


> On Apr 20, 2019, at 6:40 AM, Thomas Huth  wrote:
> 
> On 19/04/2019 15.44, G 3 wrote:
>> 
>> On Apr 19, 2019, at 3:10 AM, Thomas Huth wrote:
>> 
>>> On 19/04/2019 00.47, John Arbuckle wrote:
 Capstone is not necessary in order to use QEMU. Disable it by default.
 This will save the user the pain of having to figure why QEMU isn't
 building when this library is missing.
 
 Signed-off-by: John Arbuckle 
 ---
  configure | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/configure b/configure
 index 1c563a7027..77d7967f92 100755
 --- a/configure
 +++ b/configure
 @@ -433,7 +433,7 @@ opengl_dmabuf="no"
  cpuid_h="no"
  avx2_opt=""
  zlib="yes"
 -capstone=""
 +capstone="no"
  lzo=""
  snappy=""
  bzip2=""
>>> 
>>> AFAIK we ship capstone as a submodule, so how can this be missing? Also,
>>> our philosophy is to keep everything enabled by default if possible, so
>>> that the code paths don't bitrot. Thus I don't think that disabling this
>>> by default is a good idea. ... so if you've got a problem here, there
>>> must be another solution (e.g. is the system capstone detection not
>>> working right on your system?).
>>> 
>>>  Thomas
>> 
>> Thank you for replying. Capstone comes with QEMU? Every time I try to
>> compile QEMU I see an error relating to Capstone not being on my system.
>> Why do you feel that disabling Capstone by default is not a good idea?
>> 
>> Here is the error message I see when compiling QEMU:
>> 
>> CHK version_gen.h
>> make[1]: *** No rule to make target
>> `/Users/John/qemu-git/capstone/libcapstone.a'.  Stop.
>> make: *** [subdir-capstone] Error 2
> 
> I assume you're using a git checkout here, right? For git checkouts, the
> Makefile should take care of calling the scripts/git-submodule.sh script
> which should initialize the submodule in the capstone directory.
> 
> What's the content of your .git-submodule-status file? What does
> "configure" say about capstone support on your system?
> 
> Thomas

Yes I use a git checkout.

This is the contents of my .git-submodule-status file:
#!/bin/sh
#
# This code is licensed under the GPL version 2 or later.  See
# the COPYING file in the top-level directory.

substat=".git-submodule-status"

command=$1
shift
maybe_modules="$@"

test -z "$GIT" && GIT=git

error() {
echo "$0: $*"
echo
echo "Unable to automatically checkout GIT submodules '$modules'."
echo "If you require use of an alternative GIT binary (for example to"
echo "enable use of a transparent proxy), then please specify it by"
echo "running configure by with the '--with-git' argument. e.g."
echo
echo " $ ./configure --with-git='tsocks git'"
echo
echo "Alternatively you may disable automatic GIT submodule checkout"
echo "with:"
echo
echo " $ ./configure --disable-git-update"
echo
echo "and then manually update submodules prior to running make, with:"
echo
echo " $ scripts/git-submodule.sh update $modules"
echo
exit 1
}

modules=""
for m in $maybe_modules
do
$GIT submodule status $m 1> /dev/null 2>&1
if test $? = 0
then
modules="$modules $m"
else
echo "warn: ignoring non-existent submodule $m"
fi
done

if test -n "$maybe_modules" && ! test -e ".git"
then
echo "$0: unexpectedly called with submodules but no git checkout exists"
exit 1
fi

case "$command" in
status)
if test -z "$maybe_modules"
then
 test -s ${substat} && exit 1 || exit 0
fi

test -f "$substat" || exit 1
CURSTATUS=$($GIT submodule status $modules)
OLDSTATUS=$(cat $substat)
test "$CURSTATUS" = "$OLDSTATUS"
exit $?
;;
update)
if test -z "$maybe_modules"
then
test -e $substat || touch $substat
exit 0
fi

$GIT submodule update --init $modules 1>/dev/null
test $? -ne 0 && error "failed to update modules"

$GIT submodule status $modules > "${substat}"
test $? -ne 0 && error "failed to save git submodule status" >&2
;;
esac

exit 0



The Configure command says:
capstone  git

I did a 'make clean' followed by a 'make distclean'. Then tried building again 
using this command line:

./configure --target-list=ppc-softmmu,i386-softmmu,x86_64-softmmu
make -j 4

Here is the error message I see:

make[1]: *** No rule to make target 
`/Users/John/Documents/Development/Projects/Qemu/qemu-git/capstone/libcapstone.a'.
  Stop.
make: *** [subdir-capstone] Error 2

I took a look at the capstone folder. There is no 'make' file in this folder. 
Should there be one?

Thank you.


Re: [Qemu-devel] [PATCH] configure: Disable slirp if --disable-system

2019-05-11 Thread Aleksandar Markovic
On May 10, 2019 10:36 PM, "Richard Henderson" 
wrote:
>
> For linux-user, there is no need to add slirp to the set of
> git modules checked out, nor build it.
>
> This also avoids a makefile bug wrt insufficient dependencies
> on subdir-slirp.  If slirp/ is not initially present, the
> dependencies that check it out are associated with softmmu,
> which then generates a build error on slirp/ not present.
>

Hi,

Does this work if only user mode targets are specified via ˊ--target-listˊ
switch? If no, the patch shoud be amended. If yes, the commit message
should be extended.

Thanks,
Aleksandar

> Signed-off-by: Richard Henderson 
> ---
>  configure | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/configure b/configure
> index 63f312bd1f..9de7e43a80 100755
> --- a/configure
> +++ b/configure
> @@ -5878,6 +5878,10 @@ fi
>  ##
>  # check for slirp
>
> +if test "$softmmu" = "no"; then
> +slirp=no
> +fi
> +
>  case "$slirp" in
>"" | yes)
>  if $pkg_config slirp; then
> --
> 2.17.1
>
>


Re: [Qemu-devel] [PATCH] configure: Disable slirp if --disable-system

2019-05-11 Thread Thomas Huth
On 10/05/2019 22.34, Richard Henderson wrote:
> For linux-user, there is no need to add slirp to the set of
> git modules checked out, nor build it.
> 
> This also avoids a makefile bug wrt insufficient dependencies
> on subdir-slirp.  If slirp/ is not initially present, the
> dependencies that check it out are associated with softmmu,
> which then generates a build error on slirp/ not present.
> 
> Signed-off-by: Richard Henderson 
> ---
>  configure | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/configure b/configure
> index 63f312bd1f..9de7e43a80 100755
> --- a/configure
> +++ b/configure
> @@ -5878,6 +5878,10 @@ fi
>  ##
>  # check for slirp
>  
> +if test "$softmmu" = "no"; then
> +slirp=no
> +fi

Maybe also check that the user did not try to run configure with both,
--disable-system and --enable-slirp? I.e. that $slirp != "yes" ?

 Thomas



[Qemu-devel] [PATCH] configure: Disable slirp if --disable-system

2019-05-10 Thread Richard Henderson
For linux-user, there is no need to add slirp to the set of
git modules checked out, nor build it.

This also avoids a makefile bug wrt insufficient dependencies
on subdir-slirp.  If slirp/ is not initially present, the
dependencies that check it out are associated with softmmu,
which then generates a build error on slirp/ not present.

Signed-off-by: Richard Henderson 
---
 configure | 4 
 1 file changed, 4 insertions(+)

diff --git a/configure b/configure
index 63f312bd1f..9de7e43a80 100755
--- a/configure
+++ b/configure
@@ -5878,6 +5878,10 @@ fi
 ##
 # check for slirp
 
+if test "$softmmu" = "no"; then
+slirp=no
+fi
+
 case "$slirp" in
   "" | yes)
 if $pkg_config slirp; then
-- 
2.17.1




Re: [Qemu-devel] [PATCH] configure: copy MacOS NDRV driver into sharedir for out-of-tree builds

2019-05-10 Thread Peter Maydell
On Fri, 10 May 2019 at 18:18, Mark Cave-Ayland
 wrote:
>
> On 10/05/2019 17:49, Peter Maydell wrote:
> > The comment above this bit of code says:
> >
> > # Caution: do not add files or directories here using wildcards. This
> > # will result in problems later if a new file matching the wildcard is
> > # added to the source tree -- nothing will cause configure to be rerun
> > # so the build tree will be missing the link back to the new file, and
> > # tests might fail.
> >
> > The pc-bios/ directory is awkward legacy which we
> > can't really apply the next part of the comment to
> > ("Prefer to keep the relevant files in their own
> > directory and symlink the directory instead"), but since
> > there is only one *.ndrv file we can at least avoid the
> > wildcard by writing "qemu_vga.ndrv" instead of "*.ndrv".
>
> I did spot that, but figured that it was outdated because no-one else was 
> really
> following it. The reason for adding the explicit wildcard is that the driver 
> build
> produces 2 separate .ndrv files - debug, and non-debug - and so it saves me a 
> bit of
> effort after a rebase and rebuild.

It's followed by everything except for the legacy pc-bios
files that were too painful to clean up.

> Should we say up front as part of the conversion to o-o-t builds that all 
> files must
> be explicitly listed in that section as per the comment? Or should each type 
> of
> driver live in its own subdirectory?

The problem here really is that there are two possible
failure modes:
 (1) we use a wildcard, and then when we add a new file
 the link isn't added, and incremental builds fail
 (2) we don't use a wildcard, and then when we add a new
 file we have to manually list it, and if we forget
 then builds fail (both incremental and not)

The ideal way to avoid this is to have an entire directory
which contains pregenerated bios blobs and nothing else,
so we can just symlink the whole directory into the build
tree. But pc-bios has this awkward mix of files which
are pre-generated (and thus in git in the source tree)
and files which will get built by make (and which must
live only in the build tree).

thanks
-- PMM



Re: [Qemu-devel] [PATCH] configure: copy MacOS NDRV driver into sharedir for out-of-tree builds

2019-05-10 Thread Mark Cave-Ayland
On 10/05/2019 17:49, Peter Maydell wrote:

> On Fri, 10 May 2019 at 17:37, Mark Cave-Ayland
>  wrote:
>>
>> Make sure that we include *.ndrv files with those being copied to sharedir
>> during out-of-tree builds. This ensures that the MacOS driver is correctly
>> located and loaded by qemu-system-ppc.
>>
>> Signed-off-by: Mark Cave-Ayland 
>> ---
>>  configure | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/configure b/configure
>> index 63f312bd1f..9493537301 100755
>> --- a/configure
>> +++ b/configure
>> @@ -7886,6 +7886,7 @@ for bios_file in \
>>  $source_path/pc-bios/*.dtb \
>>  $source_path/pc-bios/*.img \
>>  $source_path/pc-bios/openbios-* \
>> +$source_path/pc-bios/*.ndrv \
>>  $source_path/pc-bios/u-boot.* \
>>  $source_path/pc-bios/edk2-*.fd.bz2 \
>>  $source_path/pc-bios/palcode-*
> 
> The comment above this bit of code says:
> 
> # Caution: do not add files or directories here using wildcards. This
> # will result in problems later if a new file matching the wildcard is
> # added to the source tree -- nothing will cause configure to be rerun
> # so the build tree will be missing the link back to the new file, and
> # tests might fail.
> 
> The pc-bios/ directory is awkward legacy which we
> can't really apply the next part of the comment to
> ("Prefer to keep the relevant files in their own
> directory and symlink the directory instead"), but since
> there is only one *.ndrv file we can at least avoid the
> wildcard by writing "qemu_vga.ndrv" instead of "*.ndrv".

I did spot that, but figured that it was outdated because no-one else was really
following it. The reason for adding the explicit wildcard is that the driver 
build
produces 2 separate .ndrv files - debug, and non-debug - and so it saves me a 
bit of
effort after a rebase and rebuild.

Should we say up front as part of the conversion to o-o-t builds that all files 
must
be explicitly listed in that section as per the comment? Or should each type of
driver live in its own subdirectory?


ATB,

Mark.



Re: [Qemu-devel] [PATCH] configure: copy MacOS NDRV driver into sharedir for out-of-tree builds

2019-05-10 Thread Peter Maydell
On Fri, 10 May 2019 at 17:37, Mark Cave-Ayland
 wrote:
>
> Make sure that we include *.ndrv files with those being copied to sharedir
> during out-of-tree builds. This ensures that the MacOS driver is correctly
> located and loaded by qemu-system-ppc.
>
> Signed-off-by: Mark Cave-Ayland 
> ---
>  configure | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/configure b/configure
> index 63f312bd1f..9493537301 100755
> --- a/configure
> +++ b/configure
> @@ -7886,6 +7886,7 @@ for bios_file in \
>  $source_path/pc-bios/*.dtb \
>  $source_path/pc-bios/*.img \
>  $source_path/pc-bios/openbios-* \
> +$source_path/pc-bios/*.ndrv \
>  $source_path/pc-bios/u-boot.* \
>  $source_path/pc-bios/edk2-*.fd.bz2 \
>  $source_path/pc-bios/palcode-*

The comment above this bit of code says:

# Caution: do not add files or directories here using wildcards. This
# will result in problems later if a new file matching the wildcard is
# added to the source tree -- nothing will cause configure to be rerun
# so the build tree will be missing the link back to the new file, and
# tests might fail.

The pc-bios/ directory is awkward legacy which we
can't really apply the next part of the comment to
("Prefer to keep the relevant files in their own
directory and symlink the directory instead"), but since
there is only one *.ndrv file we can at least avoid the
wildcard by writing "qemu_vga.ndrv" instead of "*.ndrv".

thanks
-- PMM



[Qemu-devel] [PATCH] configure: copy MacOS NDRV driver into sharedir for out-of-tree builds

2019-05-10 Thread Mark Cave-Ayland
Make sure that we include *.ndrv files with those being copied to sharedir
during out-of-tree builds. This ensures that the MacOS driver is correctly
located and loaded by qemu-system-ppc.

Signed-off-by: Mark Cave-Ayland 
---
 configure | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configure b/configure
index 63f312bd1f..9493537301 100755
--- a/configure
+++ b/configure
@@ -7886,6 +7886,7 @@ for bios_file in \
 $source_path/pc-bios/*.dtb \
 $source_path/pc-bios/*.img \
 $source_path/pc-bios/openbios-* \
+$source_path/pc-bios/*.ndrv \
 $source_path/pc-bios/u-boot.* \
 $source_path/pc-bios/edk2-*.fd.bz2 \
 $source_path/pc-bios/palcode-*
-- 
2.11.0




Re: [Qemu-devel] [PATCH] configure: Require python3 >= 3.5

2019-05-09 Thread Daniel P . Berrangé
On Thu, May 09, 2019 at 11:36:04AM +0200, Kevin Wolf wrote:
> Am 09.05.2019 um 11:24 hat Kevin Wolf geschrieben:
> > Am 09.05.2019 um 07:45 hat Markus Armbruster geschrieben:
> > > Eduardo Habkost  writes:
> > > > diff --git a/.travis.yml b/.travis.yml
> > > > index 66448d99d6..0f6986b3f1 100644
> > > > --- a/.travis.yml
> > > > +++ b/.travis.yml
> > > > @@ -211,7 +211,7 @@ matrix:
> > > >  - CONFIG="--target-list=x86_64-softmmu"
> > > >language: python
> > > >python:
> > > > -- "3.4"
> > > > +- "3.5"
> > > >  
> > > >  
> > > >  - env:
> > > 
> > > Easily missed, good work.
> > > 
> > > My grep for similar references to Python versions we don't support found
> > > a few 2.x, x < 7.  Not this patch's problem, of course, but let me show
> > > them anyway:
> > 
> > I'm sure that we have a few more instances of Python 2 compatibility
> > code in qemu-iotests that can be removed after this is merged. These are
> > what I could find quickly, but there are probably more:
> > 
> > 242:# Read one byte in a way compatible with Python 2
> > iotests.py:# Python < 3.4 needs to know not to add whitespace 
> > when pretty-printing:
> > 
> > 149:from __future__ import print_function
> > 165:from __future__ import print_function
> > iotests.py:from __future__ import print_function
> > nbd-fault-injector.py:from __future__ import print_function
> > qcow2.py:from __future__ import print_function
> > qed.py:from __future__ import print_function
> > 
> > 044:if sys.version_info.major == 2:
> > 163:if sys.version_info.major == 2:
> > iotests.py:if sys.version_info.major >= 3:
> > iotests.py:if sys.version_info.major >= 3:
> > nbd-fault-injector.py:if sys.version_info.major >= 3:
> > 
> > I'm planning to take care of the qemu-iotests ones.
> > 
> > Also, with Python 3.5 as the new minimum, I think I'd like to add type
> > hints to iotests.py and possibly the qemu package (for QEMUQtestMachine
> > and friends). The syntax isn't as nice as if we could go straight to
> > 3.6, but still, finally some type checking instead of running into
> > stupid runtime bugs!
> 
> Ah, sorry, I was getting too excited there. We only deprecate 2.x now
> (and not even in this patch), but don't remove it yet. So I guess this
> will have to wait until next year.

If you're happy using one of the comment based hinting syntax, that
will work, or at least not break, with python 2

https://www.bernat.tech/the-state-of-type-hints-in-python/

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|



Re: [Qemu-devel] [PATCH] configure: Require python3 >= 3.5

2019-05-09 Thread Kevin Wolf
Am 09.05.2019 um 11:24 hat Kevin Wolf geschrieben:
> Am 09.05.2019 um 07:45 hat Markus Armbruster geschrieben:
> > Eduardo Habkost  writes:
> > > diff --git a/.travis.yml b/.travis.yml
> > > index 66448d99d6..0f6986b3f1 100644
> > > --- a/.travis.yml
> > > +++ b/.travis.yml
> > > @@ -211,7 +211,7 @@ matrix:
> > >  - CONFIG="--target-list=x86_64-softmmu"
> > >language: python
> > >python:
> > > -- "3.4"
> > > +- "3.5"
> > >  
> > >  
> > >  - env:
> > 
> > Easily missed, good work.
> > 
> > My grep for similar references to Python versions we don't support found
> > a few 2.x, x < 7.  Not this patch's problem, of course, but let me show
> > them anyway:
> 
> I'm sure that we have a few more instances of Python 2 compatibility
> code in qemu-iotests that can be removed after this is merged. These are
> what I could find quickly, but there are probably more:
> 
> 242:# Read one byte in a way compatible with Python 2
> iotests.py:# Python < 3.4 needs to know not to add whitespace 
> when pretty-printing:
> 
> 149:from __future__ import print_function
> 165:from __future__ import print_function
> iotests.py:from __future__ import print_function
> nbd-fault-injector.py:from __future__ import print_function
> qcow2.py:from __future__ import print_function
> qed.py:from __future__ import print_function
> 
> 044:if sys.version_info.major == 2:
> 163:if sys.version_info.major == 2:
> iotests.py:if sys.version_info.major >= 3:
> iotests.py:if sys.version_info.major >= 3:
> nbd-fault-injector.py:if sys.version_info.major >= 3:
> 
> I'm planning to take care of the qemu-iotests ones.
> 
> Also, with Python 3.5 as the new minimum, I think I'd like to add type
> hints to iotests.py and possibly the qemu package (for QEMUQtestMachine
> and friends). The syntax isn't as nice as if we could go straight to
> 3.6, but still, finally some type checking instead of running into
> stupid runtime bugs!

Ah, sorry, I was getting too excited there. We only deprecate 2.x now
(and not even in this patch), but don't remove it yet. So I guess this
will have to wait until next year.

Kevin



Re: [Qemu-devel] [PATCH] configure: Require python3 >= 3.5

2019-05-09 Thread Kevin Wolf
Am 09.05.2019 um 07:45 hat Markus Armbruster geschrieben:
> Eduardo Habkost  writes:
> > diff --git a/.travis.yml b/.travis.yml
> > index 66448d99d6..0f6986b3f1 100644
> > --- a/.travis.yml
> > +++ b/.travis.yml
> > @@ -211,7 +211,7 @@ matrix:
> >  - CONFIG="--target-list=x86_64-softmmu"
> >language: python
> >python:
> > -- "3.4"
> > +- "3.5"
> >  
> >  
> >  - env:
> 
> Easily missed, good work.
> 
> My grep for similar references to Python versions we don't support found
> a few 2.x, x < 7.  Not this patch's problem, of course, but let me show
> them anyway:

I'm sure that we have a few more instances of Python 2 compatibility
code in qemu-iotests that can be removed after this is merged. These are
what I could find quickly, but there are probably more:

242:# Read one byte in a way compatible with Python 2
iotests.py:# Python < 3.4 needs to know not to add whitespace when 
pretty-printing:

149:from __future__ import print_function
165:from __future__ import print_function
iotests.py:from __future__ import print_function
nbd-fault-injector.py:from __future__ import print_function
qcow2.py:from __future__ import print_function
qed.py:from __future__ import print_function

044:if sys.version_info.major == 2:
163:if sys.version_info.major == 2:
iotests.py:if sys.version_info.major >= 3:
iotests.py:if sys.version_info.major >= 3:
nbd-fault-injector.py:if sys.version_info.major >= 3:

I'm planning to take care of the qemu-iotests ones.

Also, with Python 3.5 as the new minimum, I think I'd like to add type
hints to iotests.py and possibly the qemu package (for QEMUQtestMachine
and friends). The syntax isn't as nice as if we could go straight to
3.6, but still, finally some type checking instead of running into
stupid runtime bugs!

Kevin



Re: [Qemu-devel] [PATCH] configure: Require python3 >= 3.5

2019-05-08 Thread Markus Armbruster
Eduardo Habkost  writes:

> The oldest python3 version in distros that will be supported by
> QEMU 4.1 is 3.5.3 (the one in Debian Stretch).  Error out if
> running python3 < 3.5.
>
> We have a .travis.yml job configured to use Python 3.4.  Change
> it to use Python 3.5.
>
> Signed-off-by: Eduardo Habkost 
> ---
>  configure   | 5 +++--
>  .travis.yml | 2 +-
>  2 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/configure b/configure
> index 6b3ed8c532..520c207d66 100755
> --- a/configure
> +++ b/configure
> @@ -1841,8 +1841,9 @@ fi
>  
>  # Note that if the Python conditional here evaluates True we will exit
>  # with status 1 which is a shell 'false' value.
> -if ! $python -c 'import sys; sys.exit(sys.version_info < (2,7))'; then
> -  error_exit "Cannot use '$python', Python 2 >= 2.7 or Python 3 is 
> required." \
> +if ! $python -c 'import sys; sys.exit(sys.version_info < (2,7) or \
> +  (3,0) <= sys.version_info < (3,5))'; 
> then
> +  error_exit "Cannot use '$python', Python 2 >= 2.7 or Python 3 >= 3.5 is 
> required." \
>"Use --python=/path/to/python to specify a supported Python."
>  fi
>  
> diff --git a/.travis.yml b/.travis.yml
> index 66448d99d6..0f6986b3f1 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -211,7 +211,7 @@ matrix:
>  - CONFIG="--target-list=x86_64-softmmu"
>language: python
>python:
> -- "3.4"
> +- "3.5"
>  
>  
>  - env:

Easily missed, good work.

My grep for similar references to Python versions we don't support found
a few 2.x, x < 7.  Not this patch's problem, of course, but let me show
them anyway:

* scripts/qapi/common.py

# re.subn() lacks flags support before Python 2.7, use re.compile()

  I'll clean this up.

* tests/image-fuzzer/

  docs/image-fuzzer.txt "Fuzzer requirements" item "17. Should be
  compatible with python version 2.4-2.7".

  Stefan, does the fuzzer need porting to Python 3?

  Two spots in the code are marked as 2.4 work-arounds:

tests/image-fuzzer/qcow2/fuzz.py:in Python 2.4
tests/image-fuzzer/runner.py:# Python 2.4 doesn't support 'finally' 
and 'except' in the same 'try'

Grep also found tests/vm/netbsd and tests/vm/openbsd pass
--python=python2.7 to configure.  Eduardo, should they be upgraded to a
suitable version of Python 3?  Possibly in your "[PATCH] Deprecate
Python 2 support"?

If yes, then https://wiki.qemu.org/Hosts/BSD also needs an update.



Re: [Qemu-devel] [PATCH] configure: Require python3 >= 3.5

2019-05-08 Thread Thomas Huth
On 08/05/2019 20.23, Eduardo Habkost wrote:
> The oldest python3 version in distros that will be supported by
> QEMU 4.1 is 3.5.3 (the one in Debian Stretch).  Error out if
> running python3 < 3.5.
> 
> We have a .travis.yml job configured to use Python 3.4.  Change
> it to use Python 3.5.
> 
> Signed-off-by: Eduardo Habkost 
> ---
>  configure   | 5 +++--
>  .travis.yml | 2 +-
>  2 files changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/configure b/configure
> index 6b3ed8c532..520c207d66 100755
> --- a/configure
> +++ b/configure
> @@ -1841,8 +1841,9 @@ fi
>  
>  # Note that if the Python conditional here evaluates True we will exit
>  # with status 1 which is a shell 'false' value.
> -if ! $python -c 'import sys; sys.exit(sys.version_info < (2,7))'; then
> -  error_exit "Cannot use '$python', Python 2 >= 2.7 or Python 3 is 
> required." \
> +if ! $python -c 'import sys; sys.exit(sys.version_info < (2,7) or \
> +  (3,0) <= sys.version_info < (3,5))'; 
> then
> +  error_exit "Cannot use '$python', Python 2 >= 2.7 or Python 3 >= 3.5 is 
> required." \

Nit: There won't be a Python2 > 2.7 anymore, so you could also replace
"2 >= 2.7" with "2.7" here. But well, it will go away next year anyway, so:

Reviewed-by: Thomas Huth 



[Qemu-devel] [PATCH] configure: Require python3 >= 3.5

2019-05-08 Thread Eduardo Habkost
The oldest python3 version in distros that will be supported by
QEMU 4.1 is 3.5.3 (the one in Debian Stretch).  Error out if
running python3 < 3.5.

We have a .travis.yml job configured to use Python 3.4.  Change
it to use Python 3.5.

Signed-off-by: Eduardo Habkost 
---
 configure   | 5 +++--
 .travis.yml | 2 +-
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/configure b/configure
index 6b3ed8c532..520c207d66 100755
--- a/configure
+++ b/configure
@@ -1841,8 +1841,9 @@ fi
 
 # Note that if the Python conditional here evaluates True we will exit
 # with status 1 which is a shell 'false' value.
-if ! $python -c 'import sys; sys.exit(sys.version_info < (2,7))'; then
-  error_exit "Cannot use '$python', Python 2 >= 2.7 or Python 3 is required." \
+if ! $python -c 'import sys; sys.exit(sys.version_info < (2,7) or \
+  (3,0) <= sys.version_info < (3,5))'; then
+  error_exit "Cannot use '$python', Python 2 >= 2.7 or Python 3 >= 3.5 is 
required." \
   "Use --python=/path/to/python to specify a supported Python."
 fi
 
diff --git a/.travis.yml b/.travis.yml
index 66448d99d6..0f6986b3f1 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -211,7 +211,7 @@ matrix:
 - CONFIG="--target-list=x86_64-softmmu"
   language: python
   python:
-- "3.4"
+- "3.5"
 
 
 - env:
-- 
2.18.0.rc1.1.g3f1ff2140




Re: [Qemu-devel] [PATCH] configure: Remove old *-config-devices.mak.d files when running configure

2019-04-30 Thread Thomas Huth
On 11/03/2019 17.21, Eric Blake wrote:
> On 3/11/19 5:29 AM, Thomas Huth wrote:
>> When running "make" in a build directory from the pre-Kconfig merge time,
>> the build process currently fails with:
>>
>>  make: *** No rule to make target `.../default-configs/pci.mak',
>>   needed by `aarch64-softmmu/config-devices.mak'.  Stop.
>>
>> To make sure that this problem at least goes away when the user runs
>> "configure" (or "sh config.status") again, we have to make sure that
>> we re-generate the .mak.d files. Thus remove the old stale files
>> while running the configure script.
>>
>> Signed-off-by: Thomas Huth 
>> ---
>>  configure | 3 +++
>>  1 file changed, 3 insertions(+)
> 
> What are the conditions for make deciding it needs to rerun
> config.status? Are end users still going to get 'make' failing with the
> cryptic message (where we just advise on-list and on-wiki to
> './config.status' to fix it), or is there a way to build in a dependency
> so that the makefile itself knows that if config.status has to be rerun,
> that takes priority over any other rule that depends on .mak files?

I just noticed that I never replied to this mail so far, sorry!

The conditions for rerunning config.status can be found in the Makefile:

config-host.mak: $(SRC_PATH)/configure $(SRC_PATH)/pc-bios $(SRC_PATH)/VERSION
@echo $@ is out-of-date, running configure
...

At least we change VERSION regularly, so while not being perfect, the problem
should go away after a while with this patch. Not sure whether there is a better
way to do this - maybe depend on the files in default-configs/, too? Or maybe we
could simply bump VERSION from x.y.50 to x.y.51 the next time when we ever hit
such a problem again...?

 Thomas



Re: [Qemu-devel] [PATCH] configure: Remove --source-path option

2019-04-29 Thread Peter Maydell
On Thu, 25 Apr 2019 at 17:42, Antonio Ospite
 wrote:
> Now that 4.0 has been released, maybe we can move on with this minor change.
>
> I will send a fix for https://bugs.launchpad.net/qemu/+bug/1817345 after
> this patch lands.

This patch has just gone in to master, so that should be ok
for you to rebase your patch on now.

thanks
-- PMM



Re: [Qemu-devel] [PATCH] configure: Add -Wno-typedef-redefinition to CFLAGS (for Clang)

2019-04-27 Thread Richard Henderson
On 4/27/19 8:45 AM, Thomas Huth wrote:
> Without the -Wno-typedef-redefinition option, clang complains if a typedef
> gets redefined in gnu99 mode (since this is officially a C11 feature). This
> used to also happen with older versions of GCC, but since we've bumped our
> minimum GCC version to 4.8, all versions of GCC that we support do not seem
> to issue this warning in gnu99 mode anymore. So this has become a common
> problem for people who only test their code with GCC - they do not notice
> the issue until they submit their patches and suddenly patchew or a
> maintainer complains.
> 
> Now that we do not urgently need to keep the code clean from typedef
> redefintions anymore with recent versions of GCC, we can ease the
> situation with clang, too, and simply shut these warnings off for good.
> 
> Signed-off-by: Thomas Huth 
> ---
>  configure | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Richard Henderson 


r~



[Qemu-devel] [PATCH] configure: Add -Wno-typedef-redefinition to CFLAGS (for Clang)

2019-04-27 Thread Thomas Huth
Without the -Wno-typedef-redefinition option, clang complains if a typedef
gets redefined in gnu99 mode (since this is officially a C11 feature). This
used to also happen with older versions of GCC, but since we've bumped our
minimum GCC version to 4.8, all versions of GCC that we support do not seem
to issue this warning in gnu99 mode anymore. So this has become a common
problem for people who only test their code with GCC - they do not notice
the issue until they submit their patches and suddenly patchew or a
maintainer complains.

Now that we do not urgently need to keep the code clean from typedef
redefintions anymore with recent versions of GCC, we can ease the
situation with clang, too, and simply shut these warnings off for good.

Signed-off-by: Thomas Huth 
---
 configure | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure b/configure
index 2cc365be51..8e15dc9870 100755
--- a/configure
+++ b/configure
@@ -1917,7 +1917,7 @@ gcc_flags="-Wformat-security -Wformat-y2k -Winit-self 
-Wignored-qualifiers $gcc_
 gcc_flags="-Wno-missing-include-dirs -Wempty-body -Wnested-externs $gcc_flags"
 gcc_flags="-Wendif-labels -Wno-shift-negative-value $gcc_flags"
 gcc_flags="-Wno-initializer-overrides -Wexpansion-to-defined $gcc_flags"
-gcc_flags="-Wno-string-plus-int $gcc_flags"
+gcc_flags="-Wno-string-plus-int -Wno-typedef-redefinition $gcc_flags"
 # Note that we do not add -Werror to gcc_flags here, because that would
 # enable it for all configure tests. If a configure test failed due
 # to -Werror this would just silently disable some features,
-- 
2.21.0




Re: [Qemu-devel] [PATCH] configure: Remove --source-path option

2019-04-25 Thread Antonio Ospite

On 19/03/19 09:41, Antonio Ospite wrote:

On 18/03/19 14:40, Peter Maydell wrote:

Normally configure identifies the source path by looking
at the location where the configure script itself exists.
We also provide a --source-path option which lets the user
manually override this.

There isn't really an obvious use case for the --source-path
option, and in commit 927128222b0a91f56c13a in 2017 we
accidentally added some logic that looks at $source_path
before the command line option that overrides it has been
processed.

The fact that nobody complained suggests that there isn't
any use of this option and we aren't testing it either;
remove it. This allows us to move the "make $source_path
absolute" logic up so that there is no window in the script
where $source_path is set but not yet absolute.

Signed-off-by: Peter Maydell 
---
Since this is a "noticed while reading code" issue rather than
one that's actually causing a problem, it's probably 4.1
material at this point.

Cc'ing Antonio since they also have a patch to configure
which this will affect.


Thanks for CC-ing me, I will send a v2 of my patch after this one gets in.

A minor comment below.


---
  configure | 10 ++
  1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/configure b/configure
index 7071f525843..bc2953e6114 100755
--- a/configure
+++ b/configure
@@ -278,6 +278,8 @@ ld_has() {
  # default parameters
  source_path=$(dirname "$0")
+# make source path absolute
+source_path=$(cd "$source_path"; pwd)


While we are at it, can't source_path be set only once?

And probably $(dirname -- "$0") is a little more robust, it covers the 
case of directories starting with a dash, so maybe:


# default parameters
# make source path absolute
source_path=$(cd "$(dirname -- "$0")"; pwd)
...



Ping.

Now that 4.0 has been released, maybe we can move on with this minor change.

I will send a fix for https://bugs.launchpad.net/qemu/+bug/1817345 after 
this patch lands.


Thank you,
   Antonio


  cpu=""
  iasl="iasl"
  interp_prefix="/usr/gnemul/qemu-%M"
@@ -519,8 +521,6 @@ for opt do
    ;;
    --cxx=*) CXX="$optarg"
    ;;
-  --source-path=*) source_path="$optarg"
-  ;;
    --cpu=*) cpu="$optarg"
    ;;
    --extra-cflags=*) QEMU_CFLAGS="$QEMU_CFLAGS $optarg"
@@ -599,9 +599,6 @@ if test "$debug_info" = "yes"; then
  LDFLAGS="-g $LDFLAGS"
  fi
-# make source path absolute
-source_path=$(cd "$source_path"; pwd)
-
  # running configure in the source tree?
  # we know that's the case if configure is there.
  if test -f "./configure"; then
@@ -945,8 +942,6 @@ for opt do
    ;;
    --interp-prefix=*) interp_prefix="$optarg"
    ;;
-  --source-path=*)
-  ;;
    --cross-prefix=*)
    ;;
    --cc=*)
@@ -1624,7 +1619,6 @@ $(echo Available targets: $default_target_list | \
    fold -s -w 53 | sed -e 's/^/   /')
  Advanced options (experts only):
-  --source-path=PATH   path of source code [$source_path]
    --cross-prefix=PREFIX    use PREFIX for compile tools [$cross_prefix]
    --cc=CC  use C compiler CC [$cc]
    --iasl=IASL  use ACPI compiler IASL [$iasl]








Re: [Qemu-devel] [PATCH] configure: Change capstone's default state to disabled

2019-04-20 Thread Thomas Huth
On 19/04/2019 15.44, G 3 wrote:
> 
> On Apr 19, 2019, at 3:10 AM, Thomas Huth wrote:
> 
>> On 19/04/2019 00.47, John Arbuckle wrote:
>>> Capstone is not necessary in order to use QEMU. Disable it by default.
>>> This will save the user the pain of having to figure why QEMU isn't
>>> building when this library is missing.
>>>
>>> Signed-off-by: John Arbuckle 
>>> ---
>>>  configure | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/configure b/configure
>>> index 1c563a7027..77d7967f92 100755
>>> --- a/configure
>>> +++ b/configure
>>> @@ -433,7 +433,7 @@ opengl_dmabuf="no"
>>>  cpuid_h="no"
>>>  avx2_opt=""
>>>  zlib="yes"
>>> -capstone=""
>>> +capstone="no"
>>>  lzo=""
>>>  snappy=""
>>>  bzip2=""
>>
>> AFAIK we ship capstone as a submodule, so how can this be missing? Also,
>> our philosophy is to keep everything enabled by default if possible, so
>> that the code paths don't bitrot. Thus I don't think that disabling this
>> by default is a good idea. ... so if you've got a problem here, there
>> must be another solution (e.g. is the system capstone detection not
>> working right on your system?).
>>
>>  Thomas
> 
> Thank you for replying. Capstone comes with QEMU? Every time I try to
> compile QEMU I see an error relating to Capstone not being on my system.
> Why do you feel that disabling Capstone by default is not a good idea?
> 
> Here is the error message I see when compiling QEMU:
> 
> CHK version_gen.h
> make[1]: *** No rule to make target
> `/Users/John/qemu-git/capstone/libcapstone.a'.  Stop.
> make: *** [subdir-capstone] Error 2

I assume you're using a git checkout here, right? For git checkouts, the
Makefile should take care of calling the scripts/git-submodule.sh script
which should initialize the submodule in the capstone directory.

What's the content of your .git-submodule-status file? What does
"configure" say about capstone support on your system?

 Thomas



Re: [Qemu-devel] [PATCH] configure: Change capstone's default state to disabled

2019-04-19 Thread Programmingkid


> On Apr 19, 2019, at 2:22 PM, Richard Henderson  wrote:
> 
> On 4/19/19 3:44 AM, G 3 wrote:
>> 
>> Here is the error message I see when compiling QEMU:
>> 
>> CHK version_gen.h
>> make[1]: *** No rule to make target
>> `/Users/John/qemu-git/capstone/libcapstone.a'.  Stop.
>> make: *** [subdir-capstone] Error 2
> 
> You are configuring with --static?
> 
> I've seen this before myself -- IMO it's broken distro packaging, in that the
> shipped pkgconfig/capstone.pc claims static library support, but the static
> library itself wasn't shipped.
> 
> We should probably work around this in configure, and report the packaging 
> bug.

I do not use --static. This is what I use: ./configure 
--target-list=ppc-softmmu.

I think this is a bug with configure, or with the capstone repo.


Re: [Qemu-devel] [PATCH] configure: Change capstone's default state to disabled

2019-04-19 Thread Richard Henderson
On 4/19/19 3:44 AM, G 3 wrote:
> 
> Here is the error message I see when compiling QEMU:
> 
> CHK version_gen.h
> make[1]: *** No rule to make target
> `/Users/John/qemu-git/capstone/libcapstone.a'.  Stop.
> make: *** [subdir-capstone] Error 2

You are configuring with --static?

I've seen this before myself -- IMO it's broken distro packaging, in that the
shipped pkgconfig/capstone.pc claims static library support, but the static
library itself wasn't shipped.

We should probably work around this in configure, and report the packaging bug.


r~



Re: [Qemu-devel] [PATCH] configure: Change capstone's default state to disabled

2019-04-19 Thread G 3



On Apr 19, 2019, at 3:10 AM, Thomas Huth wrote:


On 19/04/2019 00.47, John Arbuckle wrote:
Capstone is not necessary in order to use QEMU. Disable it by  
default.

This will save the user the pain of having to figure why QEMU isn't
building when this library is missing.

Signed-off-by: John Arbuckle 
---
 configure | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure b/configure
index 1c563a7027..77d7967f92 100755
--- a/configure
+++ b/configure
@@ -433,7 +433,7 @@ opengl_dmabuf="no"
 cpuid_h="no"
 avx2_opt=""
 zlib="yes"
-capstone=""
+capstone="no"
 lzo=""
 snappy=""
 bzip2=""


AFAIK we ship capstone as a submodule, so how can this be missing?  
Also,
our philosophy is to keep everything enabled by default if  
possible, so
that the code paths don't bitrot. Thus I don't think that disabling  
this

by default is a good idea. ... so if you've got a problem here, there
must be another solution (e.g. is the system capstone detection not
working right on your system?).

 Thomas


Thank you for replying. Capstone comes with QEMU? Every time I try to  
compile QEMU I see an error relating to Capstone not being on my  
system. Why do you feel that disabling Capstone by default is not a  
good idea?


Here is the error message I see when compiling QEMU:

CHK version_gen.h
make[1]: *** No rule to make target `/Users/John/qemu-git/capstone/ 
libcapstone.a'.  Stop.

make: *** [subdir-capstone] Error 2




Re: [Qemu-devel] [PATCH] configure: Change capstone's default state to disabled

2019-04-19 Thread Thomas Huth
On 19/04/2019 00.47, John Arbuckle wrote:
> Capstone is not necessary in order to use QEMU. Disable it by default.
> This will save the user the pain of having to figure why QEMU isn't
> building when this library is missing.
> 
> Signed-off-by: John Arbuckle 
> ---
>  configure | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/configure b/configure
> index 1c563a7027..77d7967f92 100755
> --- a/configure
> +++ b/configure
> @@ -433,7 +433,7 @@ opengl_dmabuf="no"
>  cpuid_h="no"
>  avx2_opt=""
>  zlib="yes"
> -capstone=""
> +capstone="no"
>  lzo=""
>  snappy=""
>  bzip2=""

AFAIK we ship capstone as a submodule, so how can this be missing? Also,
our philosophy is to keep everything enabled by default if possible, so
that the code paths don't bitrot. Thus I don't think that disabling this
by default is a good idea. ... so if you've got a problem here, there
must be another solution (e.g. is the system capstone detection not
working right on your system?).

 Thomas



[Qemu-devel] [PATCH] configure: Change capstone's default state to disabled

2019-04-18 Thread John Arbuckle
Capstone is not necessary in order to use QEMU. Disable it by default.
This will save the user the pain of having to figure why QEMU isn't
building when this library is missing.

Signed-off-by: John Arbuckle 
---
 configure | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure b/configure
index 1c563a7027..77d7967f92 100755
--- a/configure
+++ b/configure
@@ -433,7 +433,7 @@ opengl_dmabuf="no"
 cpuid_h="no"
 avx2_opt=""
 zlib="yes"
-capstone=""
+capstone="no"
 lzo=""
 snappy=""
 bzip2=""
-- 
2.14.3 (Apple Git-98)




Re: [Qemu-devel] [PATCH] configure: Automatically fall back to TCI on non-release architectures

2019-04-11 Thread Richard Henderson
On 4/9/19 8:17 PM, Stefan Weil wrote:
> On 09.04.19 22:39, Richard Henderson wrote:
>> On 4/9/19 9:46 AM, Stefan Weil wrote:
>>> * Calling conventions. The current implementation works on many hosts,
>>> but for example not on Sparc. A fix would require simple calling
>>> conventions for all helper functions (for example stack based argument
>>> passing, can this be enforced?), or it needs to know the signature of
>>> each helper function at runtime. I'm afraid that fixing this would
>>> require much work. A runtime test whether calls of helper functions work
>>> correctly could be implemented easily and could abort the program
>>> execution when calls fail to pass the right arguments. Would such a
>>> runtime test help a little bit?
>>
>> In the rewrite of tci that I proposed some years ago,
>> I used libffi for this.
>>
>> Those patches could probably be recovered...
>>
>> https://patchwork.ozlabs.org/patch/348528/
>> https://patchwork.ozlabs.org/patch/348527/
> 
> 
> The first patch is the important one because it adds the signature to
> each helper function. As soon as this information is passed to the
> interpreter, the rest is simple. It should not be necessary to add a new
> dependency on libffi, because there are no foreign calling conventions
> here: all helpers use the C calling convention of the host architecture.

Perhaps the "foreign" in libffi is confusing you.  Its goal *is* the C calling
convention of the host architecture.

> The TCG implementation for Sparc (and other hosts with special calling
> conventions) must also have some minimum information on the signatures
> of the helper functions. It should be possible to use the same
> information for TCI. Maybe your approach ist a general form which could
> be used for any TCG implementation.

We currently capture only enough information to support the TCG native hosts.
If we were to attempt to support, e.g. m68k as a host, then we would have to
expand this.  What I capture for libffi is exact, so it's certainly possible.

But the number of possible function signatures is large.  I forget the simple
math that expresses this well, but doing this the long way suggests 4372 as the
number of combinations (up to 6 arguments of 3 types; 4 return types).

This number is large enough that you cannot just open code all of the possible
calls.  You absolutely have to know something about the host compiler's calling
convention.

I see only 3 possibilities for this:

(1) Use per host ifdefs and/or assembly to DTRT within TCI.
This admits that TCI requires *some* porting and does
not automatically run everywhere.
(2) Use an external library that already has said assembly,
and has already been ported to every interesting processor,
since it is often done along with the compiler port.
(3) Write a proper TCG backend for each host.

If you see another possibility, please enlighten me.


r~



Re: [Qemu-devel] [PATCH] configure: Automatically fall back to TCI on non-release architectures

2019-04-10 Thread Stefan Weil
On 10.04.19 10:22, Thomas Huth wrote:
> Additionally, I think it should be possible to compile with the
> x86_64-linux-user target and then to run "make check-tcg" ... however,
> that currently crashes with:
> 
> TODO qemu/tcg/tci.c:859: tcg_qemu_tb_exec()
> qemu/tcg/tci.c:859: tcg fatal error
> qemu: uncaught target signal 11 (Segmentation fault) - core dumped

That's easy to fix. I implemented only those TCG opcodes which really
were executed during testing. This test triggers an assertion because it
needs INDEX_op_ld16u_i64 which was missing up to now.

I'll send a patch which adds support for INDEX_op_ld16u_i64.

Thank you for your tests.

Stefan




Re: [Qemu-devel] [PATCH] configure: Automatically fall back to TCI on non-release architectures

2019-04-10 Thread Thomas Huth
On 10/04/2019 08.07, Thomas Huth wrote:
> On 09/04/2019 21.46, Stefan Weil wrote:
>> On 05.04.19 11:16, Philippe Mathieu-Daudé wrote:
>>> On 4/5/19 11:02 AM, Daniel P. Berrangé wrote:
 On Fri, Apr 05, 2019 at 10:47:54AM +0200, Philippe Mathieu-Daudé wrote:
 Do the various crashes that you illustrate in that cover letter
 still exist today ? If so, 2 years of continued brokenness with no
 fixes would reinforce the the view that it is time to remove TCI
 from the codebase.
>>>
>>> Or find a maintainer and add tests...
>>
>> Thank you for CC'ing me. I could not spend much of my free time for QEMU
>> last year and typically will miss important messages on the list unless
>> my address is explicitly given. Nevertheless I still feel responsible
>> for TCI, and I am also listed as maintainer in MAINTAINERS.
> 
> That's great, good to know that you're still interested in TCI! ... but
> I think one of the main problems is still that we completely lack test
> coverage for TCI - the code always is in danger to bit-rot if it is not
> tested by default.
> 
> I could maybe have a try to add some test to our .gitlab-ci.yml file ...
> if you or somebody else could add one to .travis.yml, that would be
> great. Something like:
> 
>  - ./configure --enable-tcg-interpreter 
> --target-list=alpha-softmmu,ppc64-softmmu,i386-softmmu,sparc-softmmu,microblaze-softmmu,moxie-softmmu,arm-softmmu,hppa-softmmu
>  - make
>  - make tests/boot-serial-test
>  - QTEST_QEMU_BINARY="alpha-softmmu/qemu-system-alpha"  
> ./tests/boot-serial-test
>  - QTEST_QEMU_BINARY="ppc64-softmmu/qemu-system-ppc64"  
> ./tests/boot-serial-test
>  - ...

Additionally, I think it should be possible to compile with the
x86_64-linux-user target and then to run "make check-tcg" ... however,
that currently crashes with:

TODO qemu/tcg/tci.c:859: tcg_qemu_tb_exec()
qemu/tcg/tci.c:859: tcg fatal error
qemu: uncaught target signal 11 (Segmentation fault) - core dumped

 Thomas



Re: [Qemu-devel] [PATCH] configure: Automatically fall back to TCI on non-release architectures

2019-04-10 Thread Thomas Huth
On 09/04/2019 21.46, Stefan Weil wrote:
[...]
> The known problems with the current implementation are
[...]
> * Calling conventions. The current implementation works on many hosts,
> but for example not on Sparc
Is there also a problem with the sparc *target* (i.e. not only sparc
hosts)? TCI does not seem to work here:

 https://gitlab.com/huth/qemu/-/jobs/193861498

 Thomas



Re: [Qemu-devel] [PATCH] configure: Automatically fall back to TCI on non-release architectures

2019-04-10 Thread Stefan Weil
On 10.04.19 08:07, Thomas Huth wrote:
> That's great, good to know that you're still interested in TCI! ... but
> I think one of the main problems is still that we completely lack test
> coverage for TCI - the code always is in danger to bit-rot if it is not
> tested by default.


Ideally it would be possible to build a QEMU executable with KVM (on
those hosts which support it), native TCG and TCI, so users could decide
at runtime which of the three alternatives they want. Then CI builds
(not necessarily production builds) would include all source files and
could also run tests with TCI if desired.

It was not possible to have native and interpreted TCG selectable at
runtime when I started the TCI implementation, but time went on and QEMU
and TCG evolved, so maybe it is now possible.

Stefan




Re: [Qemu-devel] [PATCH] configure: Automatically fall back to TCI on non-release architectures

2019-04-10 Thread Stefan Weil
On 09.04.19 22:39, Richard Henderson wrote:
> On 4/9/19 9:46 AM, Stefan Weil wrote:
>> * Calling conventions. The current implementation works on many hosts,
>> but for example not on Sparc. A fix would require simple calling
>> conventions for all helper functions (for example stack based argument
>> passing, can this be enforced?), or it needs to know the signature of
>> each helper function at runtime. I'm afraid that fixing this would
>> require much work. A runtime test whether calls of helper functions work
>> correctly could be implemented easily and could abort the program
>> execution when calls fail to pass the right arguments. Would such a
>> runtime test help a little bit?
> 
> In the rewrite of tci that I proposed some years ago,
> I used libffi for this.
> 
> Those patches could probably be recovered...
> 
> https://patchwork.ozlabs.org/patch/348528/
> https://patchwork.ozlabs.org/patch/348527/


The first patch is the important one because it adds the signature to
each helper function. As soon as this information is passed to the
interpreter, the rest is simple. It should not be necessary to add a new
dependency on libffi, because there are no foreign calling conventions
here: all helpers use the C calling convention of the host architecture.

The TCG implementation for Sparc (and other hosts with special calling
conventions) must also have some minimum information on the signatures
of the helper functions. It should be possible to use the same
information for TCI. Maybe your approach ist a general form which could
be used for any TCG implementation.

Stefan



Re: [Qemu-devel] [PATCH] configure: Automatically fall back to TCI on non-release architectures

2019-04-10 Thread Thomas Huth
On 09/04/2019 21.46, Stefan Weil wrote:
> On 05.04.19 11:16, Philippe Mathieu-Daudé wrote:
>> On 4/5/19 11:02 AM, Daniel P. Berrangé wrote:
>>> On Fri, Apr 05, 2019 at 10:47:54AM +0200, Philippe Mathieu-Daudé wrote:
>>> Do the various crashes that you illustrate in that cover letter
>>> still exist today ? If so, 2 years of continued brokenness with no
>>> fixes would reinforce the the view that it is time to remove TCI
>>> from the codebase.
>>
>> Or find a maintainer and add tests...
> 
> Thank you for CC'ing me. I could not spend much of my free time for QEMU
> last year and typically will miss important messages on the list unless
> my address is explicitly given. Nevertheless I still feel responsible
> for TCI, and I am also listed as maintainer in MAINTAINERS.

That's great, good to know that you're still interested in TCI! ... but
I think one of the main problems is still that we completely lack test
coverage for TCI - the code always is in danger to bit-rot if it is not
tested by default.

I could maybe have a try to add some test to our .gitlab-ci.yml file ...
if you or somebody else could add one to .travis.yml, that would be
great. Something like:

 - ./configure --enable-tcg-interpreter 
--target-list=alpha-softmmu,ppc64-softmmu,i386-softmmu,sparc-softmmu,microblaze-softmmu,moxie-softmmu,arm-softmmu,hppa-softmmu
 - make
 - make tests/boot-serial-test
 - QTEST_QEMU_BINARY="alpha-softmmu/qemu-system-alpha"  ./tests/boot-serial-test
 - QTEST_QEMU_BINARY="ppc64-softmmu/qemu-system-ppc64"  ./tests/boot-serial-test
 - ...

 Thomas



Re: [Qemu-devel] [PATCH] configure: Automatically fall back to TCI on non-release architectures

2019-04-09 Thread Richard Henderson
On 4/9/19 9:46 AM, Stefan Weil wrote:
> * Calling conventions. The current implementation works on many hosts,
> but for example not on Sparc. A fix would require simple calling
> conventions for all helper functions (for example stack based argument
> passing, can this be enforced?), or it needs to know the signature of
> each helper function at runtime. I'm afraid that fixing this would
> require much work. A runtime test whether calls of helper functions work
> correctly could be implemented easily and could abort the program
> execution when calls fail to pass the right arguments. Would such a
> runtime test help a little bit?

In the rewrite of tci that I proposed some years ago,
I used libffi for this.

Those patches could probably be recovered...

https://patchwork.ozlabs.org/patch/348528/
https://patchwork.ozlabs.org/patch/348527/


r~



Re: [Qemu-devel] [PATCH] configure: Automatically fall back to TCI on non-release architectures

2019-04-09 Thread Stefan Weil
On 05.04.19 11:16, Philippe Mathieu-Daudé wrote:
> On 4/5/19 11:02 AM, Daniel P. Berrangé wrote:
>> On Fri, Apr 05, 2019 at 10:47:54AM +0200, Philippe Mathieu-Daudé wrote:
>> Do the various crashes that you illustrate in that cover letter
>> still exist today ? If so, 2 years of continued brokenness with no
>> fixes would reinforce the the view that it is time to remove TCI
>> from the codebase.
> 
> Or find a maintainer and add tests...

Thank you for CC'ing me. I could not spend much of my free time for QEMU
last year and typically will miss important messages on the list unless
my address is explicitly given. Nevertheless I still feel responsible
for TCI, and I am also listed as maintainer in MAINTAINERS.

In the past there was only limited use of TCI (as far as I know), and
the current implementation worked for many applications, for example to
count the frequency of TCG opcodes.

The known problems with the current implementation are

* Misaligned memory accesses. This should be easy to fix. I already sent
a patch (currently discussed) which fixed user mode emulation on ARM for me.

* Calling conventions. The current implementation works on many hosts,
but for example not on Sparc. A fix would require simple calling
conventions for all helper functions (for example stack based argument
passing, can this be enforced?), or it needs to know the signature of
each helper function at runtime. I'm afraid that fixing this would
require much work. A runtime test whether calls of helper functions work
correctly could be implemented easily and could abort the program
execution when calls fail to pass the right arguments. Would such a
runtime test help a little bit?

* Performance. It can be improved a bit by implementing more TCG opcodes
for the interpreter, but of course TCI is slower than TCG (which is
slower than KVM).

Cheers
Stefan



Re: [Qemu-devel] [PATCH] configure: Automatically fall back to TCI on non-release architectures

2019-04-06 Thread Richard Henderson
On 4/5/19 2:56 PM, Helge Deller wrote:
> Looking just at some of the debian "ports" (non-release) architectures:
> alpha, hppa, ia64, m68k, powerpc, sh4, sparc64

FWIW:

sparc64 does have a tcg backend.
(Indeed, tcg/sparc does *not* support 32-bit cpus!)

powerpc does have a tcg backend, and it has both 32 and 64-bit users.

Both hppa and ia64 used to have tcg backends, and could
be resurrected if there was a will.

I have a tcg/alpha backend that I haven't bothered to
merge, because I assumed there was little interest.


r~



Re: [Qemu-devel] [PATCH] configure: Automatically fall back to TCI on non-release architectures

2019-04-05 Thread Philippe Mathieu-Daudé
On 4/5/19 11:02 AM, Daniel P. Berrangé wrote:
> On Fri, Apr 05, 2019 at 10:47:54AM +0200, Philippe Mathieu-Daudé wrote:
>> Hi Helge,
>>
>> On 4/5/19 9:56 AM, Helge Deller wrote:
>>> On 05.04.19 03:34, Peter Maydell wrote:
 On Fri, 5 Apr 2019 at 01:59, Helge Deller  wrote:
> If a non-release architecture is found, and it's known that there is no
> native TCG support for that CPU, automatically fall back to the TCI
> implementation instead of requesting the user to run configure again
> with the --enable-tcg-interpreter option.
>
> This change simplifies building qemu in automatic build environments
> (like in my case the debian buildds) because one does not need to
> special case on the architectures.

 I don't think we should do this. TCI is unmaintained, has several
 known flaws,
>>>
>>> Just out of interest: Is there a list with those flaws somewhere?
>>
>> The last big discussion is in this thread:
>> https://lists.gnu.org/archive/html/qemu-devel/2017-06/msg06528.html

I just noticed this link doesn't show the full thread replies list, and
want to point out Stefan's one:

https://lists.gnu.org/archive/html/qemu-devel/2017-06/msg06841.html

I guess remember someone (Thomas? you Daniel?) posting a link of 3 forks
using TCI for reverse engineering but I can't find it to check if they
are still active.

> Do the various crashes that you illustrate in that cover letter
> still exist today ? If so, 2 years of continued brokenness with no
> fixes would reinforce the the view that it is time to remove TCI
> from the codebase.

Or find a maintainer and add tests...



Re: [Qemu-devel] [PATCH] configure: Automatically fall back to TCI on non-release architectures

2019-04-05 Thread Daniel P . Berrangé
On Fri, Apr 05, 2019 at 11:02:52AM +0200, Helge Deller wrote:
> On 05.04.19 10:26, Daniel P. Berrangé wrote:
> > On Fri, Apr 05, 2019 at 09:56:46AM +0200, Helge Deller wrote:
> >> Hi Peter,
> >>
> >> On 05.04.19 03:34, Peter Maydell wrote:
> >>> On Fri, 5 Apr 2019 at 01:59, Helge Deller  wrote:
>  If a non-release architecture is found, and it's known that there is no
>  native TCG support for that CPU, automatically fall back to the TCI
>  implementation instead of requesting the user to run configure again
>  with the --enable-tcg-interpreter option.
> 
>  This change simplifies building qemu in automatic build environments
>  (like in my case the debian buildds) because one does not need to
>  special case on the architectures.
> >>>
> >>> I don't think we should do this. TCI is unmaintained, has several
> >>> known flaws,
> >>
> >> Just out of interest: Is there a list with those flaws somewhere?
> >>
> >>> does not provide the level of performance that
> >>> people expect from QEMU, and we've talked about removing it
> >>> altogether. In particular, distros should not automatically ship
> >>> a TCI QEMU -- it's something that a user can use if they
> >>> explicitly opt into but which I don't think we want to surprise
> >>> anybody with.
> >>
> >> I won't argue against your points. They are all valid.
> >>
> >>> If we care about a host architecture we should support it
> >>> with a proper TCG backend. If we don't care that much we
> >>> shouldn't support it.
> >>
> >> Looking just at some of the debian "ports" (non-release) architectures:
> >> alpha, hppa, ia64, m68k, powerpc, sh4, sparc64
> >> Most likely nobody will ever care enough to write a TCG backend for those,
> >> and it doesn't even make sense because they are so much slower than
> >> the currently supported TCG backend architectures. So why should one want
> >> to emulate a fast x86 machine on slow m68k for example?
> >>
> >> The only reason when it *can* make sense is, when you need "basic"
> >> emulation or availability of binaries for cross-dependecies in distros,
> >> e.g. to build other packages or to be able to install other packages.
> >> As one example, many packages depend on libvirt (frontend tools, monitoring
> >> stuff, ...) and libvirt again depends on some qemu binaries.
> >> So, having qemu buildable (even if the result is slow) makes life easier.
> >
> > If it is just a matter of satisfying dependencies, it is easy to build
> > a minimal libvirt that is essentially just the client libraries and not
> > the QEMU driver that would in turn allow other packages to build. 
> > Alternatively
> > it should be possible to build the downstream apps with their libvirt dep
> > disabled avoiding pulling in the whole virtualization chain as a build
> > pre-req.
> 
> libvirt was just one example, and yes, it's possible to work around in
> multiple ways.
> 
> As another example, even if I only want to build "qemu-img", I still need
> to manually give the --enable-tcg-interpreter configure option.

That is something I would consider a valid bug to fix. We should permit
people to do  "./configure --disable-system --disable-user --enable-tools".
Requiring --enable-tcg-interpreter in that scenario is clearly wrong,
as we're not even building it.

> >> I know, my point above now turns into a "distro packaging" issue.
> >> That's why I'm questioning, why should distros (or even direct end-users)
> >> be forced to distinguish between architectures?
> >> Shouldn't running "./configure" find out what's available and then
> >>  auto-configure itself to the *best* what's possible?
> >
> > "best" depends on the POV. You want configure to enable support on
> > hppa by default since you have an interest in that architecture, which
> > is fine. The QEMU maintainers, however, have a POV that considers
> > raising an error by default to be the "best" solution for architectures
> > that are considered unsupported, requiring explicit arg to optin to use
> > unsupported features.
> 
> Yes, fair point.
> Sadly such special treatment by projects makes life for me
> as an architecture maintainer much harder :-(

FWIW I like to see code portability that is as broad as is practical.
At the same time though, essentially every open source project is
massively overloaded with work they want to accomplish vs number of
contributors available.

There has to be a tradeoff in where effort is spent and usually that
tradeoff ends up priortizing areas that are going to benefit the
largest number of users. In recent times QEMU has been trying to
formalize what it considers supported vs unsupported so that we have
a better plan for where we spend our limited contributor resources.
The intent is that this will help us improve overall project quality.
That has meant dropping support for many older distros, and marking
some OSes, distros & architectures as unsupported with a view to fully
dropping ability to build on them in future.

Regards,

Re: [Qemu-devel] [PATCH] configure: Automatically fall back to TCI on non-release architectures

2019-04-05 Thread Peter Maydell
On Fri, 5 Apr 2019 at 16:02, Helge Deller  wrote:
> Sadly such special treatment by projects makes life for me
> as an architecture maintainer much harder :-(

It's kind of inevitable for programs that aren't straightforwardly
architecture agnostic. gcc doesn't work for architectures which
don't have implemented backends either...

thanks
-- PMM



  1   2   3   4   5   6   7   8   9   10   >