Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 21 9月, 2016 2 次提交
    • M
      blockdev: Add dynamic module loading for block drivers · 88d88798
      由 Marc Mari 提交于 
      Extend the current module interface to allow for block drivers to be
loaded dynamically on request. The only block drivers that can be
converted into modules are the drivers that don't perform any init
operation except for registering themselves.

In addition, only the protocol drivers are being modularized, as they
are the only ones which see significant performance benefits. The format
drivers do not generally link to external libraries, so modularizing
them is of no benefit from a performance perspective.

All the necessary module information is located in a new structure found
in module_block.h

This spoils the purpose of 5505e8b7 (block/dmg: make it modular).

Before this patch, if module build is enabled, block-dmg.so is linked to
libbz2, whereas the main binary is not. In downstream, theoretically, it
means only the qemu-block-extra package depends on libbz2, while the
main QEMU package needn't to. With this patch, we (temporarily) change
the case so that the main QEMU depends on libbz2 again.
Signed-off-by: NMarc Marí <markmb@redhat.com>
Signed-off-by: NColin Lord <clord@redhat.com>
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Message-id: 1471008424-16465-4-git-send-email-clord@redhat.com
Reviewed-by: NMax Reitz <mreitz@redhat.com>
[mreitz: Do a signed comparison against the length of
 block_driver_modules[], so it will not cause a compile error when
 empty]
Signed-off-by: NMax Reitz <mreitz@redhat.com>
      88d88798
    • M
      blockdev: Add dynamic generation of module_block.h · 0c0c1fd9
      由 Marc Mari 提交于 
      To simplify the addition of new block modules, add a script that generates
module_block.h automatically from the modules' source code.

This script assumes that the QEMU coding style rules are followed.
Signed-off-by: NMarc Marí <markmb@redhat.com>
Signed-off-by: NColin Lord <clord@redhat.com>
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Message-id: 1471008424-16465-3-git-send-email-clord@redhat.com
Reviewed-by: NMax Reitz <mreitz@redhat.com>
Signed-off-by: NMax Reitz <mreitz@redhat.com>
      0c0c1fd9
  3. 20 9月, 2016 2 次提交
  5. 19 9月, 2016 1 次提交
  7. 15 9月, 2016 1 次提交
  9. 10 8月, 2016 1 次提交
  11. 14 7月, 2016 1 次提交
  13. 13 7月, 2016 1 次提交
  15. 04 7月, 2016 2 次提交
  17. 01 7月, 2016 2 次提交
  19. 29 6月, 2016 3 次提交
  21. 21 6月, 2016 1 次提交
  23. 17 6月, 2016 1 次提交
  25. 07 6月, 2016 5 次提交
  27. 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
  29. 29 5月, 2016 1 次提交
  31. 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
  33. 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
  35. 25 2月, 2016 1 次提交
  37. 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
  39. 11 2月, 2016 1 次提交
  41. 09 2月, 2016 1 次提交
  43. 08 1月, 2016 2 次提交
  45. 23 12月, 2015 1 次提交
  47. 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
  49. 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
  51. 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
  53. 25 10月, 2015 1 次提交
  55. 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