1. 29 6月, 2016 2 次提交
  2. 21 6月, 2016 1 次提交
  3. 17 6月, 2016 1 次提交
  4. 07 6月, 2016 5 次提交
  5. 01 6月, 2016 2 次提交
    • F
      Makefile: Rules for docker testing · 324027c2
      Fam Zheng 提交于
      This adds a group of make targets to run docker tests, all are available
      in source tree without running ./configure.
      
      The usage is shown with "make docker".
      
      Besides the fixed ones, dynamic targets for building each image and
      running each test in each image are generated automatically by make,
      scanning $(SRC_PATH)/tests/docker/ files with specific patterns.
      
      Alternative to manually list particular targets (docker-TEST@IMAGE)
      set, you can control which tests/images to run by filtering variables,
      TESTS= and IMAGES=, which are expressed in Makefile pattern syntax,
      "foo% %bar ...". For example:
      
          $ make docker-test IMAGES="ubuntu fedora"
      
      Unfortunately, it's impossible to propagate "-j $JOBS" into make in
      containers, however since each combination is made a first class target
      in the top Makefile, "make -j$N docker-test" still parallels the tests
      coarsely.
      
      Still, $J is made a magic variable to let all make invocations in
      containers to use -j$J.
      
      Instead of providing a live version of the source tree to the docker
      container we snapshot it with git-archive. This ensures the tree is in a
      pristine state for whatever operations the container is going to run on
      them.
      
      Uncommitted changes known to files known by the git index will be
      included in the snapshot if there are any.
      Signed-off-by: NFam Zheng <famz@redhat.com>
      Signed-off-by: NAlex Bennée <alex.bennee@linaro.org>
      Message-id: 1464755128-32490-5-git-send-email-famz@redhat.com
      324027c2
    • F
      Makefile: Always include rules.mak · fb57c881
      Fam Zheng 提交于
      When config-host.mak is not found it is safe to assume SRC_PATH is ".".
      So, it is okay to move inclusion of ruls.mak out of the ifeq condition.
      Signed-off-by: NFam Zheng <famz@redhat.com>
      Message-id: 1464755128-32490-4-git-send-email-famz@redhat.com
      fb57c881
  6. 29 5月, 2016 1 次提交
  7. 23 5月, 2016 1 次提交
    • P
      Remove config-devices.mak on 'make clean' · 168340b6
      Peter Maydell 提交于
      Our dependency mechanism works like this:
       * on first build there is neither a .o nor a .d
       * we create the .d as a side effect of creating the .o
       * for rebuilds we know when we need to update the .o,
         which also updates the .d
      
      This system requires that you're never in a situation where there is
      a .o file but no .d (because then we will never realise we need to
      build the .d, and we will not have the dependency information about
      when to rebuild the .o).
      
      This is working fine for our object files, but we also try to use it
      for $TARGET/config-devices.mak (where the dependency file is
      in $TARGET-config-devices.mak.d). Unfortunately "make clean" doesn't
      remove config-devices.mak, which means that it puts us in the
      forbidden situation of "object file exists but not its .d file".
      This in turn means that we will fail to notice when we need to rebuild:
        mkdir build/depbug
        (cd build/depbug && '../../configure')
        make -C build/depbug -j8
        make -C build/depbug clean
        echo "CONFIG_CANARY = y" >> default-configs/arm-softmmu.mak
        make -C build/depbug
        grep CANARY build/depbug/aarch64-softmmu/config-devices.mak
      
      The CANARY token should show up in config-devices.mak but does not.
      
      Fix this bug by making "make clean" delete the config-devices.mak files.
      config-all-devices.mak doesn't have the same problem since it has
      no .d file, but delete it too, since it is created by "make" and
      logically should be removed by "make clean".
      
      (Note that it is important not to remove config-devices.mak until
      after we have recursively run 'make clean' in the subdirectories.)
      Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      Message-Id: <1463484451-22979-1-git-send-email-peter.maydell@linaro.org>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      168340b6
  8. 11 3月, 2016 1 次提交
    • D
      osdep: add wrappers for socket functions · a2d96af4
      Daniel P. Berrange 提交于
      The windows socket functions look identical to the normal POSIX
      sockets functions, but instead of setting errno, the caller needs
      to call WSAGetLastError(). QEMU has tried to deal with this
      incompatibility by defining a socket_error() method that callers
      must use that abstracts the difference between WSAGetLastError()
      and errno.
      
      This approach is somewhat error prone though - many callers of
      the sockets functions are just using errno directly because it
      is easy to forget the need use a QEMU specific wrapper. It is
      not always immediately obvious that a particular function will
      in fact call into Windows sockets functions, so the dev may not
      even realize they need to use socket_error().
      
      This introduces an alternative approach to portability inspired
      by the way GNULIB fixes portability problems. We use a macro to
      redefine the original socket function names to refer to a QEMU
      wrapper function. The wrapper function calls the original Win32
      sockets method and then sets errno from the WSAGetLastError()
      value.
      
      Thus all code can simply call the normal POSIX sockets APIs are
      have standard errno reporting on error, even on Windows. This
      makes the socket_error() method obsolete.
      
      We also bring closesocket & ioctlsocket into this approach. Even
      though they are non-standard Win32 names, we can't wrap the normal
      close/ioctl methods since there's no reliable way to distinguish
      between a file descriptor and HANDLE in Win32.
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      a2d96af4
  9. 25 2月, 2016 1 次提交
  10. 17 2月, 2016 1 次提交
    • D
      nbd: convert block client to use I/O channels for connection setup · 064097d9
      Daniel P. Berrange 提交于
      This converts the NBD block driver client to use the QIOChannelSocket
      class for initial connection setup. The NbdClientSession struct has
      two pointers, one to the master QIOChannelSocket providing the raw
      data channel, and one to a QIOChannel which is the current channel
      used for I/O. Initially the two point to the same object, but when
      TLS support is added, they will point to different objects.
      
      The qemu-img & qemu-io tools now need to use MODULE_INIT_QOM to
      ensure the QIOChannel object classes are registered. The qemu-nbd
      tool already did this.
      
      In this initial conversion though, all I/O is still actually done
      using the raw POSIX sockets APIs.
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      Message-Id: <1455129674-17255-4-git-send-email-berrange@redhat.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      064097d9
  11. 11 2月, 2016 1 次提交
  12. 09 2月, 2016 1 次提交
  13. 08 1月, 2016 2 次提交
  14. 23 12月, 2015 1 次提交
  15. 18 12月, 2015 1 次提交
    • D
      io: add abstract QIOChannel classes · 666a3af9
      Daniel P. Berrange 提交于
      Start the new generic I/O channel framework by defining a
      QIOChannel abstract base class. This is designed to feel
      similar to GLib's GIOChannel, but with the addition of
      support for using iovecs, qemu error reporting, file
      descriptor passing, coroutine integration and use of
      the QOM framework for easier sub-classing.
      
      The intention is that anywhere in QEMU that almost
      anywhere that deals with sockets will use this new I/O
      infrastructure, so that it becomes trivial to then layer
      in support for TLS encryption. This will at least include
      the VNC server, char device backend and migration code.
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      666a3af9
  16. 26 11月, 2015 1 次提交
    • M
      makefile: fix qemu-ga make install for --disable-tools · 68aa262a
      Michael Roth 提交于
      ab59e3ec introduced a fix for `make install` on w32 that involved
      filtering out qemu-ga from $TOOLS install recipe so that we could
      append $(EXESUF) to it before attempting to install the binary
      via install-prog function.
      
      install-prog takes a list of binaries to install to a particular
      directory. If the list is empty it breaks. We guard against this
      by ensuring $TOOLS is not empty prior to calling.
      
      However, ab59e3ec introduces extra filtering after this check which
      can still result on us attempting to call install-prog with an
      empty list of binaries. In particular, this occurs if we
      build with the --disable-tools configure option, which results
      in qemu-ga being the only member of $TOOLS.
      
      Fix this by doing a simple s/qemu-ga/qemu-ga$(EXESUF)/ pass through
      $TOOLS instead of filtering out qemu-ga to handle it seperately.
      Reported-by: NSteve Ellcey <sellcey@imgtec.com>
      Cc: Stefan Weil <sw@weilnetz.de>
      Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
      68aa262a
  17. 18 11月, 2015 1 次提交
    • M
      makefile: fix w32 install target for qemu-ga · ab59e3ec
      Michael Roth 提交于
      fafcaf1d added a 'qemu-ga' install target on w32, which can be used
      in place of the existing qemu-ga.exe target to also handle dealing
      with other components such as DLLs for VSS/fsfreeze and generating
      an MSI package if appropriate configure options are present.
      
      As part of that, qemu-ga$(EXESUF) was removed from $TOOLS in favor
      of this new qemu-ga target.
      
      The install rule however relies on a direct mapping of the $TOOLS
      entry to the actual resulting binary. In the case of w32, qemu-ga
      is not identical to qemu-ga$(EXESUF), and the install recipe fails
      to find the 'qemu-ga' binary.
      
      Fix this by essentially remapping 'qemu-ga' back to 'qemu-ga.exe'
      in the install recipe.
      
      This raises the question of whether or not qemu-ga should continue
      to live in TOOLS as opposed to its own special target, but as a
      late fix for a regression in 2.5 this commit should be safer, since
      we rely on qemu-ga's presence in $TOOLS in several places throughout
      Makefile.
      Reported-by: NStefan Weil <sw@weilnetz.de>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Reviewed-by: NStefan Weil <sw@weilnetz.de>
      Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
      ab59e3ec
  18. 25 10月, 2015 1 次提交
  19. 20 10月, 2015 1 次提交
    • M
      build: qemu-ga: add 'qemu-ga' build target for w32 · fafcaf1d
      Michael Roth 提交于
      Currently POSIX builds rely on 'qemu-ga' target to do qga-only
      distributable build. On w32, as with most standalone binary targets,
      we rely on 'qemu-ga.exe' target.
      
      Unlike with POSIX, qemu-ga for w32 has a number of related targets
      such as VSS DLL and MSI package. We can do the full distributable
      qga-only build on w32 with:
      
        make qemu-ga.exe
      
      or:
      
        make msi
      
      To make that work, we tie VSS dependencies onto qemu-ga.exe.
      However, in reality the DLL isn't part of the binary, so we use a
      filter to pull them out of the LINK recipe, which attempts to link
      against prereqs for binary targets. Additionally, it could be argued
      that VSS is a separate distributable, and shouldn't be implied by
      qemu-ga.exe binary target.
      
      To avoid this, we can tie the VSS dependencies only to the 'msi'
      target, but that would make it impossible to do a qga-only build of
      the w32 distributable without building the 'msi' package, which was
      supported in the past.
      
      An alternative approach is to add a new target to build the whole
      distributable. w32 allows us to use the same build target we use
      on POSIX, 'qemu-ga', since the current binary-only target on w32
      is 'qemu-ga.exe'.
      
      To further simplify the build, we also make 'qemu-ga' build the MSI
      package if the appropriate ./configure options are set, making the
      full qga-only build the same on both POSIX and w32: `make qemu-ga`
      
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
      Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
      fafcaf1d
  20. 25 9月, 2015 2 次提交
    • D
      Makefile: fix build when VPATH is outside GIT tree · 57f54629
      Daniel P. Berrange 提交于
      Steve Ellcey / Leon Alrae reported that QEMU fails to build when
      the VPATH directory is outside of the GIT tree, and the system
      emulators & tools build is disabled. eg
      
         cd ..
         mkdir build
         cd build
         ../qemu/configure --disable-system --disable-tools
         make
         (...)
         make[1]: *** No rule to make target `../qom/object.o', needed by `qemu-aarch64'. Stop.
         make: *** [subdir-aarch64-linux-user] Error 2
      
      The problem is due to the fact that some sub directory deps
      were listed against SOFTMMU_SUBDIR_RULES instead of SUBDIR_RULES,
      so were only processed for system emulators, not user emalutors.
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      Message-Id: <1442570495-22029-1-git-send-email-berrange@redhat.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      57f54629
    • S
      nsis: Add QEMU version information to Windows registry · 805d8a67
      Stefan Weil 提交于
      The uninstall keys include an option key "DisplayVersion" which we set
      now. By default the version value is read from file VERSION, but it is
      also possible to pass VERSION=#.#.# to make.
      Signed-off-by: NStefan Weil <sw@weilnetz.de>
      805d8a67
  21. 24 9月, 2015 1 次提交
  22. 21 9月, 2015 1 次提交
    • M
      qapi: New QMP command query-qmp-schema for QMP introspection · 39a18158
      Markus Armbruster 提交于
      qapi/introspect.json defines the introspection schema.  It's designed
      for QMP introspection, but should do for similar uses, such as QGA.
      
      The introspection schema does not reflect all the rules and
      restrictions that apply to QAPI schemata.  A valid QAPI schema has an
      introspection value conforming to the introspection schema, but the
      converse is not true.
      
      Introspection lowers away a number of schema details, and makes
      implicit things explicit:
      
      * The built-in types are declared with their JSON type.
      
        All integer types are mapped to 'int', because how many bits we use
        internally is an implementation detail.  It could be pressed into
        external interface service as very approximate range information,
        but that's a bad idea.  If we need range information, we better do
        it properly.
      
      * Implicit type definitions are made explicit, and given
        auto-generated names:
      
        - Array types, named by appending "List" to the name of their
          element type, like in generated C.
      
        - The enumeration types implicitly defined by simple union types,
          named by appending "Kind" to the name of their simple union type,
          like in generated C.
      
        - Types that don't occur in generated C.  Their names start with ':'
          so they don't clash with the user's names.
      
      * All type references are by name.
      
      * The struct and union types are generalized into an object type.
      
      * Base types are flattened.
      
      * Commands take a single argument and return a single result.
      
        Dictionary argument or list result is an implicit type definition.
      
        The empty object type is used when a command takes no arguments or
        produces no results.
      
        The argument is always of object type, but the introspection schema
        doesn't reflect that.
      
        The 'gen': false directive is omitted as implementation detail.
      
        The 'success-response' directive is omitted as well for now, even
        though it's not an implementation detail, because it's not used by
        QMP.
      
      * Events carry a single data value.
      
        Implicit type definition and empty object type use, just like for
        commands.
      
        The value is of object type, but the introspection schema doesn't
        reflect that.
      
      * Types not used by commands or events are omitted.
      
        Indirect use counts as use.
      
      * Optional members have a default, which can only be null right now
      
        Instead of a mandatory "optional" flag, we have an optional default.
        No default means mandatory, default null means optional without
        default value.  Non-null is available for optional with default
        (possible future extension).
      
      * Clients should *not* look up types by name, because type names are
        not ABI.  Look up the command or event you're interested in, then
        follow the references.
      
        TODO Should we hide the type names to eliminate the temptation?
      
      New generator scripts/qapi-introspect.py computes an introspection
      value for its input, and generates a C variable holding it.
      
      It can generate awfully long lines.  Marked TODO.
      
      A new test-qmp-input-visitor test case feeds its result for both
      tests/qapi-schema/qapi-schema-test.json and qapi-schema.json to a
      QmpInputVisitor to verify it actually conforms to the schema.
      
      New QMP command query-qmp-schema takes its return value from that
      variable.  Its reply is some 85KiBytes for me right now.
      
      If this turns out to be too much, we have a couple of options:
      
      * We can use shorter names in the JSON.  Not the QMP style.
      
      * Optionally return the sub-schema for commands and events given as
        arguments.
      
        Right now qmp_query_schema() sends the string literal computed by
        qmp-introspect.py.  To compute sub-schema at run time, we'd have to
        duplicate parts of qapi-introspect.py in C.  Unattractive.
      
      * Let clients cache the output of query-qmp-schema.
      
        It changes only on QEMU upgrades, i.e. rarely.  Provide a command
        query-qmp-schema-hash.  Clients can have a cache indexed by hash,
        and re-query the schema only when they don't have it cached.  Even
        simpler: put the hash in the QMP greeting.
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Reviewed-by: NEric Blake <eblake@redhat.com>
      39a18158
  23. 16 9月, 2015 1 次提交
  24. 15 9月, 2015 2 次提交
    • D
      qom: allow QOM to be linked into tools binaries · 0c7012e0
      Daniel P. Berrange 提交于
      The qom objects are currently added to common-obj-y
      which is only linked into the system emulators. The
      later crypto patches will depend on QOM infrastructure
      and will also be used from tools binaries. Thus the QOM
      objects are moved into a new qom-obj-y variable which
      can be referenced when linking tools, system emulators
      and tests.
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      0c7012e0
    • D
      crypto: move crypto objects out of libqemuutil.la · fb37726d
      Daniel P. Berrange 提交于
      Future patches will be adding more crypto related APIs which
      rely on QOM infrastructure. This creates a problem, because
      QOM relies on library constructors to register objects. When
      you have a file in a static .a library though which is only
      referenced by a constructor the linker is dumb and will drop
      that file when linking to the final executable :-( The only
      workaround for this is to link the .a library to the executable
      using the -Wl,--whole-archive flag, but this creates its own
      set of problems because QEMU is relying on lazy linking for
      libqemuutil.a. Using --whole-archive majorly increases the
      size of final executables as they now contain a bunch of
      object code they don't actually use.
      
      The least bad option is to thus not include the crypto objects
      in libqemuutil.la, and instead define a crypto-obj-y variable
      that is referenced directly by all the executables that need
      this code (tools + softmmu, but not qemu-ga). We avoid pulling
      entire of crypto-obj-y into the userspace emulators as that
      would force them to link to gnutls too, which is not required.
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      fb37726d
  25. 02 9月, 2015 5 次提交
  26. 28 7月, 2015 1 次提交
  27. 24 6月, 2015 1 次提交