1. 11 7月, 2016 1 次提交
  2. 06 7月, 2016 1 次提交
    • R
      build: Use $(CCAS) for compiling .S files · 5f6f0e27
      Richard Henderson 提交于
      We fail to pass to $(AS) all of the different flags that may be required
      for a given set of CFLAGS.  Rather than figuring out the host-specific
      mapping, it's better to allow the compiler driver to do that.
      
      However, simply using $(CC) runs afoul of clang trying to build the
      option roms.  C.f. 3dd46c78, wherein we changed from
      using $(CC) to using $(AS) in the first place.
      
      Work around this by passing -fno-integrated-as to clang, so that we use
      the external assembler, and the clang driver still passes along all of
      the options that the assembler might require.
      Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
      Signed-off-by: NRichard Henderson <rth@twiddle.net>
      Message-Id: <1466703558-7723-1-git-send-email-rth@twiddle.net>
      5f6f0e27
  3. 04 7月, 2016 2 次提交
    • D
      crypto: allow default TLS priority to be chosen at build time · a1c5e949
      Daniel P. Berrange 提交于
      Modern gnutls can use a global config file to control the
      crypto priority settings for TLS connections. For example
      the priority string "@SYSTEM" instructs gnutls to find the
      priority setting named "SYSTEM" in the global config file.
      
      Latest gnutls GIT codebase gained the ability to reference
      multiple priority strings in the config file, with the first
      one that is found to existing winning. This means it is now
      possible to configure QEMU out of the box with a default
      priority of "@QEMU,SYSTEM", which says to look for the
      settings "QEMU" first, and if not found, use the "SYSTEM"
      settings.
      
      To make use of this facility, we introduce the ability to
      set the QEMU default priority at build time via a new
      configure argument.  It is anticipated that distro vendors
      will set this when building QEMU to a suitable value for
      use with distro crypto policy setup. eg current Fedora
      would run
      
       ./configure --tls-priority=@SYSTEM
      
      while future Fedora would run
      
       ./configure --tls-priority=@QEMU,SYSTEM
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      a1c5e949
    • D
      crypto: switch hash code to use nettle/gcrypt directly · 0c16c056
      Daniel P. Berrange 提交于
      Currently the internal hash code is using the gnutls hash APIs.
      GNUTLS in turn is wrapping either nettle or gcrypt. Not only
      were the GNUTLS hash APIs not added until GNUTLS 2.9.10, but
      they don't expose support for all the algorithms QEMU needs
      to use with LUKS.
      
      Address this by directly wrapping nettle/gcrypt in QEMU and
      avoiding GNUTLS's extra layer of indirection. This gives us
      support for hash functions on a much wider range of platforms
      and opens up ability to support more hash functions. It also
      avoids a GNUTLS bug which would not correctly handle hashing
      of large data blocks if int != size_t.
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      0c16c056
  4. 28 6月, 2016 2 次提交
  5. 26 6月, 2016 2 次提交
    • P
      configure: Don't allow user-only targets for unknown CPU architectures · affc88cc
      Peter Maydell 提交于
      For the user-only targets, we need to know something about the host CPU
      architecture even if we are using the TCI interpreter rather than TCG.
      (In particular user-exec.c has code for handling signals that needs
      to know about that host's context structures.)
      
      Specifically forbid building the user-only targets on unknown CPU
      architectures, rather than allowing them to configure but then fail
      when building user-exec.c.
      
      This change drops supports for two configurations which were theoretically
      possible before:
       * linux-user targets on M68K hosts using TCI
       * linux-user targets on HPPA hosts using TCI
      
      We don't think anybody is actually trying to use these in practice, though:
       * interpreted TCG on a slow host CPU would be unusably slow
       * the m68k user-exec.c support is missing is_write detection so guest
         code which writes to the same page it is executing from was broken
         (will include any guest program using signals)
       * HPPA TCG backend support was dropped two and a half years ago
         with no complaints
      Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      Reviewed-by: NLaurent Vivier <laurent@vivier.eu>
      Reviewed-by: NRichard Henderson <rth@twiddle.net>
      Signed-off-by: NRiku Voipio <riku.voipio@linaro.org>
      affc88cc
    • P
      configure: Don't override ARCH=unknown if enabling TCI · 997f6ed3
      Peter Maydell 提交于
      At the moment if configure finds an unknown CPU it will set
      ARCH to 'unknown', and then later either bail out or set it
      to 'tci' (depending on whether the user passed configure the
      --enable-tcg-interpreter switch). This is unnecessarily
      confusing, because we could be using TCI in two cases:
       * a known host architecture (in which case ARCH is set to
         the actual host architecture, like 'i386')
       * an unknown host architecture (in which case ARCH is
         set to 'tci')
      so nothing can rely on ARCH=tci to mean "using TCI".
      Remove the line setting ARCH, so we leave it as "unknown",
      which is what the actual situation is.
      Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      Reviewed-by: NLaurent Vivier <laurent@vivier.eu>
      Reviewed-by: NRichard Henderson <rth@twiddle.net>
      Signed-off-by: NRiku Voipio <riku.voipio@linaro.org>
      997f6ed3
  6. 20 6月, 2016 1 次提交
  7. 17 6月, 2016 5 次提交
  8. 08 6月, 2016 1 次提交
  9. 07 6月, 2016 4 次提交
  10. 03 6月, 2016 1 次提交
  11. 23 5月, 2016 1 次提交
    • S
      configure: Allow builds with extra warnings · 5919e032
      Stefan Weil 提交于
      The clang compiler supports a useful compiler option -Weverything,
      and GCC also has other warnings not enabled by -Wall.
      
      If glib header files trigger a warning, however, testing glib with
      -Werror will always fail. A size mismatch is also detected without
      -Werror, so simply remove it.
      
      Cc: qemu-stable@nongnu.org
      Signed-off-by: NStefan Weil <sw@weilnetz.de>
      Message-Id: <1461879221-13338-1-git-send-email-sw@weilnetz.de>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      5919e032
  12. 18 5月, 2016 1 次提交
  13. 11 5月, 2016 6 次提交
  14. 02 5月, 2016 1 次提交
    • J
      configure: Check if struct fsxattr is available from linux header · 277abf15
      Jan Vesely 提交于
      Fixes build failure with --enable-xfsctl and
      new linux headers (>=4.5) and older xfsprogs(<4.5):
      In file included from /usr/include/xfs/xfs.h:38:0,
                       from /var/tmp/portage/app-emulation/qemu-2.5.0-r1/work/qemu-2.5.0/block/raw-posix.c:97:
      /usr/include/xfs/xfs_fs.h:42:8: error: redefinition of ‘struct fsxattr’
       struct fsxattr {
              ^
      In file included from /var/tmp/portage/app-emulation/qemu-2.5.0-r1/work/qemu-2.5.0/block/raw-posix.c:60:0:
      /usr/include/linux/fs.h:155:8: note: originally defined here
       struct fsxattr {
      
      This is really a bug in the system headers, but we can work around it
      by defining HAVE_FSXATTR in the QEMU headers if linux/fs.h provides
      the struct, so that xfs_fs.h doesn't try to define it as well.
      
      CC: qemu-trivial@nongnu.org
      CC: Markus Armbruster <armbru@redhat.com>
      CC: Peter Maydell <peter.maydell@linaro.org>
      CC: Stefan Weil <sw@weilnetz.de>
      Tested-by: NStefan Weil <sw@weilnetz.de>
      Signed-off-by: NJan Vesely <jano.vesely@gmail.com>
      [PMM: adjusted commit message, comments]
      Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      277abf15
  15. 20 4月, 2016 1 次提交
    • J
      block/gluster: prevent data loss after i/o error · d85fa9eb
      Jeff Cody 提交于
      Upon receiving an I/O error after an fsync, by default gluster will
      dump its cache.  However, QEMU will retry the fsync, which is especially
      useful when encountering errors such as ENOSPC when using the werror=stop
      option.  When using caching with gluster, however, the last written data
      will be lost upon encountering ENOSPC.  Using the write-behind-cache
      xlator option of 'resync-failed-syncs-after-fsync' should cause gluster
      to retain the cached data after a failed fsync, so that ENOSPC and other
      transient errors are recoverable.
      
      Unfortunately, we have no way of knowing if the
      'resync-failed-syncs-after-fsync' xlator option is supported, so for now
      close the fd and set the BDS driver to NULL upon fsync error.
      Signed-off-by: NJeff Cody <jcody@redhat.com>
      d85fa9eb
  16. 17 4月, 2016 1 次提交
  17. 30 3月, 2016 1 次提交
  18. 24 3月, 2016 1 次提交
  19. 23 3月, 2016 1 次提交
  20. 17 3月, 2016 2 次提交
    • D
      crypto: add support for PBKDF2 algorithm · 37788f25
      Daniel P. Berrange 提交于
      The LUKS data format includes use of PBKDF2 (Password-Based
      Key Derivation Function). The Nettle library can provide
      an implementation of this, but we don't want code directly
      depending on a specific crypto library backend. Introduce
      a new include/crypto/pbkdf.h header which defines a QEMU
      API for invoking PBKDK2. The initial implementations are
      backed by nettle & gcrypt, which are commonly available
      with distros shipping GNUTLS.
      
      The test suite data is taken from the cryptsetup codebase
      under the LGPLv2.1+ license. This merely aims to verify
      that whatever backend we provide for this function in QEMU
      will comply with the spec.
      Reviewed-by: NFam Zheng <famz@redhat.com>
      Reviewed-by: NEric Blake <eblake@redhat.com>
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      37788f25
    • D
      crypto: add cryptographic random byte source · b917da4c
      Daniel P. Berrange 提交于
      There are three backend impls provided. The preferred
      is gnutls, which is backed by nettle in modern distros.
      The gcrypt impl is provided for cases where QEMU build
      against gnutls is disabled, but crypto is still desired.
      No nettle impl is provided, since it is non-trivial to
      use the nettle APIs for random numbers. Users of nettle
      should ensure gnutls is enabled for QEMU.
      Reviewed-by: NFam Zheng <famz@redhat.com>
      Reviewed-by: NEric Blake <eblake@redhat.com>
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      b917da4c
  21. 08 3月, 2016 1 次提交
  22. 23 2月, 2016 1 次提交
  23. 11 2月, 2016 1 次提交
  24. 10 2月, 2016 1 次提交