* [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration
@ 2018-02-05 14:58 Jianfeng Tan
2018-02-05 15:45 ` no-reply
` (3 more replies)
0 siblings, 4 replies; 28+ messages in thread
From: Jianfeng Tan @ 2018-02-05 14:58 UTC (permalink / raw)
To: qemu-devel
Cc: Jianfeng Tan, Jason Wang, Michael S . Tsirkin, Maxime Coquelin,
Paolo Bonzini
Existing VMs with virtio devices and vhost-kernel as the backend
are always started with mem config:
"-m xG"
(with a ram block named "pc.ram")
while new VMs with virtio devices and vhost-user as the backend
are always started with mem config:
"-m xG -numa node,memdev=pc.ram -object memory-backend-file,id=pc.ram,..."
(with a ram block named "/object/pc.ram")
As we migrate from vhost-kernel to vhost-user, it failes as:
Unknown ramblock "pc.ram", cannot accept migration
error while loading state for instance 0x0 of device 'ram'
load of migration failed: Invalid argument
Here are some options to fix this:
1. When we do ram name comparison, we truncate the prefix as this patch shows.
It cannot cover the corner case: the source VM could have two ram blocks
with name of "pc.ram" and "/object/pc.ram".
2. We add an alias name to RAMBlock; when we do name comparison, not only
idstr is compared, but also compared to the alias. But this will add more
complexity to upper layer stack OpenStack/libvirt.
Any thoughts?
Cc: Jason Wang <jasowang@redhat.com>
Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Maxime Coquelin <maxime.coquelin@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Suggested-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jianfeng Tan <jianfeng.tan@intel.com>
---
exec.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/exec.c b/exec.c
index 4722e52..d294e5c 100644
--- a/exec.c
+++ b/exec.c
@@ -2334,13 +2334,24 @@ found:
RAMBlock *qemu_ram_block_by_name(const char *name)
{
RAMBlock *block;
+ char *name1, *id1;
+ char *name2, *id2;
+
+ name1 = strdup(name);
+ id1 = basename(name1);
RAMBLOCK_FOREACH(block) {
- if (!strcmp(name, block->idstr)) {
+ name2 = strdup(block->idstr);
+ id2 = basename(name2);
+ if (!strcmp(id1, id2)) {
+ free(name1);
+ free(name2);
return block;
}
+ free(name2);
}
+ free(name1);
return NULL;
}
--
2.7.4
^ permalink raw reply related [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration
2018-02-05 14:58 [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration Jianfeng Tan
@ 2018-02-05 15:45 ` no-reply
2018-02-05 15:53 ` Paolo Bonzini
` (2 subsequent siblings)
3 siblings, 0 replies; 28+ messages in thread
From: no-reply @ 2018-02-05 15:45 UTC (permalink / raw)
To: jianfeng.tan; +Cc: famz, qemu-devel, pbonzini, jasowang, maxime.coquelin, mst
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 1517842735-9011-1-git-send-email-jianfeng.tan@intel.com
Subject: [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration
=== TEST SCRIPT BEGIN ===
#!/bin/bash
BASE=base
n=1
total=$(git log --oneline $BASE.. | wc -l)
failed=0
git config --local diff.renamelimit 0
git config --local diff.renames True
commits="$(git log --format=%H --reverse $BASE..)"
for c in $commits; do
echo "Checking PATCH $n/$total: $(git log -n 1 --format=%s $c)..."
if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; then
failed=1
echo
fi
n=$((n+1))
done
exit $failed
=== TEST SCRIPT END ===
Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
* [new tag] patchew/1517842735-9011-1-git-send-email-jianfeng.tan@intel.com -> patchew/1517842735-9011-1-git-send-email-jianfeng.tan@intel.com
Switched to a new branch 'test'
2a645f0bd4 exec: eliminate ram naming issue as migration
=== OUTPUT BEGIN ===
Checking PATCH 1/1: exec: eliminate ram naming issue as migration...
ERROR: code indent should never use tabs
#61: FILE: exec.c:2377:
+^Iid2 = basename(name2);$
ERROR: code indent should never use tabs
#64: FILE: exec.c:2380:
+^I free(name2);$
ERROR: code indent should never use tabs
#67: FILE: exec.c:2383:
+^Ifree(name2);$
total: 3 errors, 0 warnings, 25 lines checked
Your patch has style problems, please review. If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
=== OUTPUT END ===
Test command exited with code: 1
---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to patchew-devel@freelists.org
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration
2018-02-05 14:58 [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration Jianfeng Tan
2018-02-05 15:45 ` no-reply
@ 2018-02-05 15:53 ` Paolo Bonzini
2018-02-05 16:12 ` Tan, Jianfeng
2018-02-05 16:12 ` no-reply
2018-02-05 16:29 ` Igor Mammedov
3 siblings, 1 reply; 28+ messages in thread
From: Paolo Bonzini @ 2018-02-05 15:53 UTC (permalink / raw)
To: Jianfeng Tan, qemu-devel; +Cc: Jason Wang, Michael S . Tsirkin, Maxime Coquelin
On 05/02/2018 15:58, Jianfeng Tan wrote:
> Here are some options to fix this:
>
> 1. When we do ram name comparison, we truncate the prefix as this patch shows.
> It cannot cover the corner case: the source VM could have two ram blocks
> with name of "pc.ram" and "/object/pc.ram".
That shouldn't happen ("pc.ram" exists even in the "-numa
node,memdev=..." case, but it has no RAM block).
> RAMBLOCK_FOREACH(block) {
> - if (!strcmp(name, block->idstr)) {
> + name2 = strdup(block->idstr);
> + id2 = basename(name2);
> + if (!strcmp(id1, id2)) {
> + free(name1);
> + free(name2);
> return block;
> }
> + free(name2);
Instead of this, perhaps just skip "/object/" in both id1 and
block->idstr? This also removes the need for strdup/free.
However, note that
-m xG -numa node,memdev=pc.ram \
-object memory-backend-file,id=pc.ram,...
works for both vhost-kernel and vhost-user, so I'd rather consider this
a configuration problem and not do anything.
Thanks,
Paolo
> }
>
> + free(name1);
> return NULL;
> }
>
>
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration
2018-02-05 14:58 [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration Jianfeng Tan
2018-02-05 15:45 ` no-reply
2018-02-05 15:53 ` Paolo Bonzini
@ 2018-02-05 16:12 ` no-reply
2018-02-05 16:29 ` Igor Mammedov
3 siblings, 0 replies; 28+ messages in thread
From: no-reply @ 2018-02-05 16:12 UTC (permalink / raw)
To: jianfeng.tan; +Cc: famz, qemu-devel, pbonzini, jasowang, maxime.coquelin, mst
Hi,
This series failed docker-mingw@fedora build test. Please find the testing commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
Type: series
Message-id: 1517842735-9011-1-git-send-email-jianfeng.tan@intel.com
Subject: [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration
=== TEST SCRIPT BEGIN ===
#!/bin/bash
set -e
git submodule update --init dtc
# Let docker tests dump environment info
export SHOW_ENV=1
export J=8
time make docker-test-mingw@fedora
=== TEST SCRIPT END ===
Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
2a645f0bd4 exec: eliminate ram naming issue as migration
=== OUTPUT BEGIN ===
Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc'
Cloning into '/var/tmp/patchew-tester-tmp-83d1w41a/src/dtc'...
Submodule path 'dtc': checked out 'e54388015af1fb4bf04d0bca99caba1074d9cc42'
BUILD fedora
GEN /var/tmp/patchew-tester-tmp-83d1w41a/src/docker-src.2018-02-05-11.09.50.15886/qemu.tar
Cloning into '/var/tmp/patchew-tester-tmp-83d1w41a/src/docker-src.2018-02-05-11.09.50.15886/qemu.tar.vroot'...
done.
Your branch is up-to-date with 'origin/test'.
Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc'
Cloning into '/var/tmp/patchew-tester-tmp-83d1w41a/src/docker-src.2018-02-05-11.09.50.15886/qemu.tar.vroot/dtc'...
Submodule path 'dtc': checked out 'e54388015af1fb4bf04d0bca99caba1074d9cc42'
Submodule 'ui/keycodemapdb' (git://git.qemu.org/keycodemapdb.git) registered for path 'ui/keycodemapdb'
Cloning into '/var/tmp/patchew-tester-tmp-83d1w41a/src/docker-src.2018-02-05-11.09.50.15886/qemu.tar.vroot/ui/keycodemapdb'...
Submodule path 'ui/keycodemapdb': checked out '10739aa26051a5d49d88132604539d3ed085e72e'
COPY RUNNER
RUN test-mingw in qemu:fedora
Packages installed:
PyYAML-3.11-13.fc25.x86_64
SDL-devel-1.2.15-21.fc24.x86_64
bc-1.06.95-16.fc24.x86_64
bison-3.0.4-4.fc24.x86_64
bzip2-1.0.6-21.fc25.x86_64
ccache-3.3.4-1.fc25.x86_64
clang-3.9.1-2.fc25.x86_64
findutils-4.6.0-8.fc25.x86_64
flex-2.6.0-3.fc25.x86_64
gcc-6.4.1-1.fc25.x86_64
gcc-c++-6.4.1-1.fc25.x86_64
gettext-0.19.8.1-3.fc25.x86_64
git-2.9.5-3.fc25.x86_64
glib2-devel-2.50.3-1.fc25.x86_64
hostname-3.15-8.fc25.x86_64
libaio-devel-0.3.110-6.fc24.x86_64
libasan-6.4.1-1.fc25.x86_64
libfdt-devel-1.4.2-1.fc25.x86_64
libubsan-6.4.1-1.fc25.x86_64
make-4.1-6.fc25.x86_64
mingw32-SDL-1.2.15-7.fc24.noarch
mingw32-bzip2-1.0.6-7.fc24.noarch
mingw32-curl-7.47.0-1.fc24.noarch
mingw32-glib2-2.50.3-1.fc25.noarch
mingw32-gmp-6.1.1-1.fc25.noarch
mingw32-gnutls-3.5.5-2.fc25.noarch
mingw32-gtk2-2.24.31-2.fc25.noarch
mingw32-gtk3-3.22.17-1.fc25.noarch
mingw32-libjpeg-turbo-1.5.1-1.fc25.noarch
mingw32-libpng-1.6.27-1.fc25.noarch
mingw32-libssh2-1.4.3-5.fc24.noarch
mingw32-libtasn1-4.9-1.fc25.noarch
mingw32-nettle-3.3-1.fc25.noarch
mingw32-pixman-0.34.0-1.fc25.noarch
mingw32-pkg-config-0.28-6.fc24.x86_64
mingw64-SDL-1.2.15-7.fc24.noarch
mingw64-bzip2-1.0.6-7.fc24.noarch
mingw64-curl-7.47.0-1.fc24.noarch
mingw64-glib2-2.50.3-1.fc25.noarch
mingw64-gmp-6.1.1-1.fc25.noarch
mingw64-gnutls-3.5.5-2.fc25.noarch
mingw64-gtk2-2.24.31-2.fc25.noarch
mingw64-gtk3-3.22.17-1.fc25.noarch
mingw64-libjpeg-turbo-1.5.1-1.fc25.noarch
mingw64-libpng-1.6.27-1.fc25.noarch
mingw64-libssh2-1.4.3-5.fc24.noarch
mingw64-libtasn1-4.9-1.fc25.noarch
mingw64-nettle-3.3-1.fc25.noarch
mingw64-pixman-0.34.0-1.fc25.noarch
mingw64-pkg-config-0.28-6.fc24.x86_64
nettle-devel-3.3-1.fc25.x86_64
package python2 is not installed
perl-5.24.3-389.fc25.x86_64
pixman-devel-0.34.0-2.fc24.x86_64
sparse-0.5.0-10.fc25.x86_64
tar-1.29-3.fc25.x86_64
which-2.21-1.fc25.x86_64
zlib-devel-1.2.8-10.fc24.x86_64
Environment variables:
PACKAGES=ccache gettext git tar PyYAML sparse flex bison python2 bzip2 hostname glib2-devel pixman-devel zlib-devel SDL-devel libfdt-devel gcc gcc-c++ clang make perl which bc findutils libaio-devel nettle-devel libasan libubsan mingw32-pixman mingw32-glib2 mingw32-gmp mingw32-SDL mingw32-pkg-config mingw32-gtk2 mingw32-gtk3 mingw32-gnutls mingw32-nettle mingw32-libtasn1 mingw32-libjpeg-turbo mingw32-libpng mingw32-curl mingw32-libssh2 mingw32-bzip2 mingw64-pixman mingw64-glib2 mingw64-gmp mingw64-SDL mingw64-pkg-config mingw64-gtk2 mingw64-gtk3 mingw64-gnutls mingw64-nettle mingw64-libtasn1 mingw64-libjpeg-turbo mingw64-libpng mingw64-curl mingw64-libssh2 mingw64-bzip2
HOSTNAME=f36211f496cf
MAKEFLAGS= -j8
J=8
CCACHE_DIR=/var/tmp/ccache
EXTRA_CONFIGURE_OPTS=
V=
SHOW_ENV=1
PATH=/usr/lib/ccache:/usr/lib64/ccache:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PWD=/
TARGET_LIST=
FGC=f25
SHLVL=1
HOME=/root
TEST_DIR=/tmp/qemu-test
DISTTAG=f25container
FEATURES=mingw clang pyyaml asan dtc
DEBUG=
_=/usr/bin/env
Configure options:
--enable-werror --target-list=x86_64-softmmu,aarch64-softmmu --prefix=/tmp/qemu-test/install --cross-prefix=x86_64-w64-mingw32- --enable-trace-backends=simple --enable-gnutls --enable-nettle --enable-curl --enable-vnc --enable-bzip2 --enable-guest-agent --with-sdlabi=1.2 --with-gtkabi=2.0
Install prefix /tmp/qemu-test/install
BIOS directory /tmp/qemu-test/install
firmware path /tmp/qemu-test/install/share/qemu-firmware
binary directory /tmp/qemu-test/install
library directory /tmp/qemu-test/install/lib
module directory /tmp/qemu-test/install/lib
libexec directory /tmp/qemu-test/install/libexec
include directory /tmp/qemu-test/install/include
config directory /tmp/qemu-test/install
local state directory queried at runtime
Windows SDK no
Source path /tmp/qemu-test/src
GIT binary git
GIT submodules
C compiler x86_64-w64-mingw32-gcc
Host C compiler cc
C++ compiler x86_64-w64-mingw32-g++
Objective-C compiler clang
ARFLAGS rv
CFLAGS -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g
QEMU_CFLAGS -I/usr/x86_64-w64-mingw32/sys-root/mingw/include/pixman-1 -I$(SRC_PATH)/dtc/libfdt -Werror -mms-bitfields -I/usr/x86_64-w64-mingw32/sys-root/mingw/include/glib-2.0 -I/usr/x86_64-w64-mingw32/sys-root/mingw/lib/glib-2.0/include -I/usr/x86_64-w64-mingw32/sys-root/mingw/include -m64 -mcx16 -mthreads -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wendif-labels -Wno-shift-negative-value -Wno-missing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-strong -I/usr/x86_64-w64-mingw32/sys-root/mingw/include -I/usr/x86_64-w64-mingw32/sys-root/mingw/include/p11-kit-1 -I/usr/x86_64-w64-mingw32/sys-root/mingw/include -I/usr/x86_64-w64-mingw32/sys-root/mingw/include -I/usr/x86_64-w64-mingw32/sys-root/mingw/include/libpng16
LDFLAGS -Wl,--nxcompat -Wl,--no-seh -Wl,--dynamicbase -Wl,--warn-common -m64 -g
make make
install install
python python -B
smbd /usr/sbin/smbd
module support no
host CPU x86_64
host big endian no
target list x86_64-softmmu aarch64-softmmu
gprof enabled no
sparse enabled no
strip binaries yes
profiler no
static build no
SDL support yes (1.2.15)
GTK support yes (2.24.31)
GTK GL support no
VTE support no
TLS priority NORMAL
GNUTLS support yes
GNUTLS rnd yes
libgcrypt no
libgcrypt kdf no
nettle yes (3.3)
nettle kdf yes
libtasn1 yes
curses support no
virgl support no
curl support yes
mingw32 support yes
Audio drivers dsound
Block whitelist (rw)
Block whitelist (ro)
VirtFS support no
Multipath support no
VNC support yes
VNC SASL support no
VNC JPEG support yes
VNC PNG support yes
xen support no
brlapi support no
bluez support no
Documentation no
PIE no
vde support no
netmap support no
Linux AIO support no
ATTR/XATTR support no
Install blobs yes
KVM support no
HAX support yes
HVF support no
TCG support yes
TCG debug enabled no
TCG interpreter no
malloc trim support no
RDMA support no
fdt support yes
preadv support no
fdatasync no
madvise no
posix_madvise no
libcap-ng support no
vhost-net support no
vhost-scsi support no
vhost-vsock support no
vhost-user support no
Trace backends simple
Trace output file trace-<pid>
spice support no
rbd support no
xfsctl support no
smartcard support no
libusb no
usb net redir no
OpenGL support no
OpenGL dmabufs no
libiscsi support no
libnfs support no
build guest agent yes
QGA VSS support no
QGA w32 disk info yes
QGA MSI support no
seccomp support no
coroutine backend win32
coroutine pool yes
debug stack usage no
crypto afalg no
GlusterFS support no
gcov gcov
gcov enabled no
TPM support yes
libssh2 support yes
TPM passthrough no
TPM emulator no
QOM debugging yes
Live block migration yes
lzo support no
snappy support no
bzip2 support yes
NUMA host support no
libxml2 no
tcmalloc support no
jemalloc support no
avx2 optimization yes
replication support yes
VxHS block device no
capstone no
WARNING: Use of GTK 2.0 is deprecated and will be removed in
WARNING: future releases. Please switch to using GTK 3.0
WARNING: Use of SDL 1.2 is deprecated and will be removed in
WARNING: future releases. Please switch to using SDL 2.0
GEN x86_64-softmmu/config-devices.mak.tmp
GEN aarch64-softmmu/config-devices.mak.tmp
GEN config-host.h
GEN qemu-options.def
GEN qmp-commands.h
GEN qapi-visit.h
GEN qapi-types.h
GEN qapi-event.h
GEN x86_64-softmmu/config-devices.mak
GEN qmp-marshal.c
GEN aarch64-softmmu/config-devices.mak
GEN qapi-types.c
GEN qapi-visit.c
GEN qapi-event.c
GEN qmp-introspect.h
GEN qmp-introspect.c
GEN trace/generated-tcg-tracers.h
GEN trace/generated-helpers-wrappers.h
GEN trace/generated-helpers.h
GEN trace/generated-helpers.c
GEN module_block.h
GEN ui/input-keymap-atset1-to-qcode.c
GEN ui/input-keymap-linux-to-qcode.c
GEN ui/input-keymap-qcode-to-atset1.c
GEN ui/input-keymap-qcode-to-atset2.c
GEN ui/input-keymap-qcode-to-atset3.c
GEN ui/input-keymap-qcode-to-linux.c
GEN ui/input-keymap-qcode-to-qnum.c
GEN ui/input-keymap-qcode-to-sun.c
GEN ui/input-keymap-qnum-to-qcode.c
GEN ui/input-keymap-usb-to-qcode.c
GEN ui/input-keymap-win32-to-qcode.c
GEN ui/input-keymap-x11-to-qcode.c
GEN ui/input-keymap-xorgevdev-to-qcode.c
GEN ui/input-keymap-xorgkbd-to-qcode.c
GEN ui/input-keymap-xorgxquartz-to-qcode.c
GEN ui/input-keymap-xorgxwin-to-qcode.c
GEN tests/test-qapi-types.h
GEN tests/test-qapi-visit.h
GEN tests/test-qmp-commands.h
GEN tests/test-qapi-event.h
GEN tests/test-qmp-introspect.h
GEN trace-root.h
GEN util/trace.h
GEN crypto/trace.h
GEN io/trace.h
GEN migration/trace.h
GEN block/trace.h
GEN chardev/trace.h
GEN hw/block/trace.h
GEN hw/block/dataplane/trace.h
GEN hw/char/trace.h
GEN hw/intc/trace.h
GEN hw/net/trace.h
GEN hw/virtio/trace.h
GEN hw/audio/trace.h
GEN hw/misc/trace.h
GEN hw/usb/trace.h
GEN hw/scsi/trace.h
GEN hw/nvram/trace.h
GEN hw/display/trace.h
GEN hw/input/trace.h
GEN hw/timer/trace.h
GEN hw/dma/trace.h
GEN hw/sparc/trace.h
GEN hw/sparc64/trace.h
GEN hw/sd/trace.h
GEN hw/isa/trace.h
GEN hw/mem/trace.h
GEN hw/i386/trace.h
GEN hw/i386/xen/trace.h
GEN hw/9pfs/trace.h
GEN hw/ppc/trace.h
GEN hw/pci/trace.h
GEN hw/pci-host/trace.h
GEN hw/s390x/trace.h
GEN hw/vfio/trace.h
GEN hw/acpi/trace.h
GEN hw/arm/trace.h
GEN hw/alpha/trace.h
GEN hw/hppa/trace.h
GEN hw/xen/trace.h
GEN hw/ide/trace.h
GEN ui/trace.h
GEN audio/trace.h
GEN net/trace.h
GEN target/arm/trace.h
GEN target/i386/trace.h
GEN target/mips/trace.h
GEN target/sparc/trace.h
GEN target/s390x/trace.h
GEN target/ppc/trace.h
GEN qom/trace.h
GEN linux-user/trace.h
GEN qapi/trace.h
GEN accel/tcg/trace.h
GEN accel/kvm/trace.h
GEN nbd/trace.h
GEN trace-root.c
GEN scsi/trace.h
GEN util/trace.c
GEN crypto/trace.c
GEN io/trace.c
GEN migration/trace.c
GEN block/trace.c
GEN chardev/trace.c
GEN hw/block/trace.c
GEN hw/block/dataplane/trace.c
GEN hw/char/trace.c
GEN hw/intc/trace.c
GEN hw/net/trace.c
GEN hw/virtio/trace.c
GEN hw/audio/trace.c
GEN hw/misc/trace.c
GEN hw/usb/trace.c
GEN hw/scsi/trace.c
GEN hw/nvram/trace.c
GEN hw/display/trace.c
GEN hw/input/trace.c
GEN hw/timer/trace.c
GEN hw/dma/trace.c
GEN hw/sparc/trace.c
GEN hw/sparc64/trace.c
GEN hw/sd/trace.c
GEN hw/isa/trace.c
GEN hw/mem/trace.c
GEN hw/i386/trace.c
GEN hw/i386/xen/trace.c
GEN hw/9pfs/trace.c
GEN hw/ppc/trace.c
GEN hw/pci/trace.c
GEN hw/pci-host/trace.c
GEN hw/s390x/trace.c
GEN hw/vfio/trace.c
GEN hw/acpi/trace.c
GEN hw/arm/trace.c
GEN hw/alpha/trace.c
GEN hw/hppa/trace.c
GEN hw/xen/trace.c
GEN hw/ide/trace.c
GEN ui/trace.c
GEN audio/trace.c
GEN net/trace.c
GEN target/arm/trace.c
GEN target/i386/trace.c
GEN target/mips/trace.c
GEN target/sparc/trace.c
GEN target/s390x/trace.c
GEN target/ppc/trace.c
GEN qom/trace.c
GEN linux-user/trace.c
GEN qapi/trace.c
GEN accel/tcg/trace.c
GEN accel/kvm/trace.c
GEN nbd/trace.c
GEN config-all-devices.mak
GEN scsi/trace.c
DEP /tmp/qemu-test/src/dtc/tests/dumptrees.c
DEP /tmp/qemu-test/src/dtc/tests/trees.S
DEP /tmp/qemu-test/src/dtc/tests/testutils.c
DEP /tmp/qemu-test/src/dtc/tests/value-labels.c
DEP /tmp/qemu-test/src/dtc/tests/asm_tree_dump.c
DEP /tmp/qemu-test/src/dtc/tests/truncated_property.c
DEP /tmp/qemu-test/src/dtc/tests/check_path.c
DEP /tmp/qemu-test/src/dtc/tests/overlay_bad_fixup.c
DEP /tmp/qemu-test/src/dtc/tests/overlay.c
DEP /tmp/qemu-test/src/dtc/tests/subnode_iterate.c
DEP /tmp/qemu-test/src/dtc/tests/property_iterate.c
DEP /tmp/qemu-test/src/dtc/tests/integer-expressions.c
DEP /tmp/qemu-test/src/dtc/tests/utilfdt_test.c
DEP /tmp/qemu-test/src/dtc/tests/path_offset_aliases.c
DEP /tmp/qemu-test/src/dtc/tests/add_subnode_with_nops.c
DEP /tmp/qemu-test/src/dtc/tests/dtbs_equal_unordered.c
DEP /tmp/qemu-test/src/dtc/tests/dtb_reverse.c
DEP /tmp/qemu-test/src/dtc/tests/dtbs_equal_ordered.c
DEP /tmp/qemu-test/src/dtc/tests/extra-terminating-null.c
DEP /tmp/qemu-test/src/dtc/tests/incbin.c
DEP /tmp/qemu-test/src/dtc/tests/boot-cpuid.c
DEP /tmp/qemu-test/src/dtc/tests/path-references.c
DEP /tmp/qemu-test/src/dtc/tests/phandle_format.c
DEP /tmp/qemu-test/src/dtc/tests/references.c
DEP /tmp/qemu-test/src/dtc/tests/string_escapes.c
DEP /tmp/qemu-test/src/dtc/tests/propname_escapes.c
DEP /tmp/qemu-test/src/dtc/tests/appendprop2.c
DEP /tmp/qemu-test/src/dtc/tests/appendprop1.c
DEP /tmp/qemu-test/src/dtc/tests/del_node.c
DEP /tmp/qemu-test/src/dtc/tests/del_property.c
DEP /tmp/qemu-test/src/dtc/tests/setprop.c
DEP /tmp/qemu-test/src/dtc/tests/set_name.c
DEP /tmp/qemu-test/src/dtc/tests/rw_tree1.c
DEP /tmp/qemu-test/src/dtc/tests/open_pack.c
DEP /tmp/qemu-test/src/dtc/tests/nopulate.c
DEP /tmp/qemu-test/src/dtc/tests/mangle-layout.c
DEP /tmp/qemu-test/src/dtc/tests/move_and_save.c
DEP /tmp/qemu-test/src/dtc/tests/sw_tree1.c
DEP /tmp/qemu-test/src/dtc/tests/nop_node.c
DEP /tmp/qemu-test/src/dtc/tests/nop_property.c
DEP /tmp/qemu-test/src/dtc/tests/setprop_inplace.c
DEP /tmp/qemu-test/src/dtc/tests/stringlist.c
DEP /tmp/qemu-test/src/dtc/tests/addr_size_cells.c
DEP /tmp/qemu-test/src/dtc/tests/notfound.c
DEP /tmp/qemu-test/src/dtc/tests/sized_cells.c
DEP /tmp/qemu-test/src/dtc/tests/char_literal.c
DEP /tmp/qemu-test/src/dtc/tests/get_alias.c
DEP /tmp/qemu-test/src/dtc/tests/node_offset_by_compatible.c
DEP /tmp/qemu-test/src/dtc/tests/node_offset_by_phandle.c
DEP /tmp/qemu-test/src/dtc/tests/node_check_compatible.c
DEP /tmp/qemu-test/src/dtc/tests/node_offset_by_prop_value.c
DEP /tmp/qemu-test/src/dtc/tests/parent_offset.c
DEP /tmp/qemu-test/src/dtc/tests/supernode_atdepth_offset.c
DEP /tmp/qemu-test/src/dtc/tests/get_path.c
DEP /tmp/qemu-test/src/dtc/tests/get_phandle.c
DEP /tmp/qemu-test/src/dtc/tests/getprop.c
DEP /tmp/qemu-test/src/dtc/tests/get_name.c
DEP /tmp/qemu-test/src/dtc/tests/path_offset.c
DEP /tmp/qemu-test/src/dtc/tests/find_property.c
DEP /tmp/qemu-test/src/dtc/tests/subnode_offset.c
DEP /tmp/qemu-test/src/dtc/tests/root_node.c
DEP /tmp/qemu-test/src/dtc/tests/get_mem_rsv.c
DEP /tmp/qemu-test/src/dtc/libfdt/fdt_overlay.c
DEP /tmp/qemu-test/src/dtc/libfdt/fdt_addresses.c
DEP /tmp/qemu-test/src/dtc/libfdt/fdt_empty_tree.c
DEP /tmp/qemu-test/src/dtc/libfdt/fdt_strerror.c
DEP /tmp/qemu-test/src/dtc/libfdt/fdt_rw.c
DEP /tmp/qemu-test/src/dtc/libfdt/fdt_sw.c
DEP /tmp/qemu-test/src/dtc/libfdt/fdt_wip.c
DEP /tmp/qemu-test/src/dtc/libfdt/fdt_ro.c
DEP /tmp/qemu-test/src/dtc/libfdt/fdt.c
DEP /tmp/qemu-test/src/dtc/util.c
DEP /tmp/qemu-test/src/dtc/fdtoverlay.c
DEP /tmp/qemu-test/src/dtc/fdtput.c
DEP /tmp/qemu-test/src/dtc/fdtget.c
DEP /tmp/qemu-test/src/dtc/fdtdump.c
LEX convert-dtsv0-lexer.lex.c
DEP /tmp/qemu-test/src/dtc/srcpos.c
BISON dtc-parser.tab.c
LEX dtc-lexer.lex.c
DEP /tmp/qemu-test/src/dtc/treesource.c
DEP /tmp/qemu-test/src/dtc/livetree.c
DEP /tmp/qemu-test/src/dtc/fstree.c
DEP /tmp/qemu-test/src/dtc/flattree.c
DEP /tmp/qemu-test/src/dtc/dtc.c
DEP /tmp/qemu-test/src/dtc/checks.c
DEP /tmp/qemu-test/src/dtc/data.c
DEP convert-dtsv0-lexer.lex.c
DEP dtc-parser.tab.c
DEP dtc-lexer.lex.c
CHK version_gen.h
UPD version_gen.h
DEP /tmp/qemu-test/src/dtc/util.c
CC libfdt/fdt.o
CC libfdt/fdt_ro.o
CC libfdt/fdt_wip.o
CC libfdt/fdt_sw.o
CC libfdt/fdt_rw.o
CC libfdt/fdt_strerror.o
CC libfdt/fdt_addresses.o
CC libfdt/fdt_empty_tree.o
CC libfdt/fdt_overlay.o
AR libfdt/libfdt.a
x86_64-w64-mingw32-ar: creating libfdt/libfdt.a
a - libfdt/fdt.o
a - libfdt/fdt_ro.o
a - libfdt/fdt_wip.o
a - libfdt/fdt_sw.o
a - libfdt/fdt_rw.o
a - libfdt/fdt_strerror.o
a - libfdt/fdt_empty_tree.o
a - libfdt/fdt_addresses.o
a - libfdt/fdt_overlay.o
RC version.o
GEN qga/qapi-generated/qga-qapi-types.h
GEN qga/qapi-generated/qga-qapi-visit.h
GEN qga/qapi-generated/qga-qapi-types.c
GEN qga/qapi-generated/qga-qapi-visit.c
GEN qga/qapi-generated/qga-qmp-commands.h
GEN qga/qapi-generated/qga-qmp-marshal.c
CC qmp-introspect.o
CC qapi-types.o
CC qapi-visit.o
CC qapi-event.o
CC qapi/qapi-visit-core.o
CC qapi/qapi-dealloc-visitor.o
CC qapi/qobject-input-visitor.o
CC qapi/qobject-output-visitor.o
CC qapi/qmp-registry.o
CC qapi/string-output-visitor.o
CC qapi/qmp-dispatch.o
CC qapi/string-input-visitor.o
CC qapi/opts-visitor.o
CC qapi/qapi-clone-visitor.o
CC qapi/qmp-event.o
CC qapi/qapi-util.o
CC qobject/qnull.o
CC qobject/qnum.o
CC qobject/qstring.o
CC qobject/qlist.o
CC qobject/qdict.o
CC qobject/qbool.o
CC qobject/qlit.o
CC qobject/qjson.o
CC qobject/json-lexer.o
CC qobject/json-streamer.o
CC qobject/qobject.o
CC qobject/json-parser.o
CC trace/simple.o
CC trace/control.o
CC trace/qmp.o
CC util/osdep.o
CC util/cutils.o
CC util/unicode.o
CC util/qemu-timer-common.o
CC util/bufferiszero.o
CC util/lockcnt.o
CC util/aiocb.o
CC util/async.o
CC util/thread-pool.o
CC util/qemu-timer.o
CC util/main-loop.o
CC util/iohandler.o
CC util/aio-win32.o
CC util/event_notifier-win32.o
CC util/oslib-win32.o
CC util/qemu-thread-win32.o
CC util/envlist.o
CC util/path.o
CC util/module.o
CC util/host-utils.o
CC util/bitmap.o
CC util/bitops.o
CC util/hbitmap.o
CC util/fifo8.o
CC util/acl.o
CC util/cacheinfo.o
CC util/error.o
CC util/qemu-error.o
CC util/id.o
CC util/iov.o
CC util/qemu-config.o
CC util/qemu-sockets.o
CC util/uri.o
CC util/notify.o
CC util/qemu-option.o
CC util/qemu-progress.o
CC util/keyval.o
CC util/hexdump.o
CC util/crc32c.o
CC util/uuid.o
CC util/throttle.o
CC util/getauxval.o
CC util/readline.o
CC util/rcu.o
CC util/qemu-coroutine.o
CC util/qemu-coroutine-lock.o
CC util/qemu-coroutine-io.o
CC util/qemu-coroutine-sleep.o
CC util/coroutine-win32.o
CC util/buffer.o
CC util/timed-average.o
CC util/base64.o
CC util/log.o
CC util/pagesize.o
CC util/qdist.o
CC util/qht.o
CC util/range.o
CC util/stats64.o
CC util/systemd.o
CC trace-root.o
CC util/trace.o
CC crypto/trace.o
CC io/trace.o
CC migration/trace.o
CC block/trace.o
CC chardev/trace.o
CC hw/block/trace.o
CC hw/block/dataplane/trace.o
CC hw/char/trace.o
CC hw/intc/trace.o
CC hw/net/trace.o
CC hw/virtio/trace.o
CC hw/audio/trace.o
CC hw/misc/trace.o
CC hw/usb/trace.o
CC hw/scsi/trace.o
CC hw/nvram/trace.o
CC hw/display/trace.o
CC hw/input/trace.o
CC hw/timer/trace.o
CC hw/dma/trace.o
CC hw/sparc/trace.o
CC hw/sparc64/trace.o
CC hw/sd/trace.o
CC hw/isa/trace.o
CC hw/mem/trace.o
CC hw/i386/trace.o
CC hw/i386/xen/trace.o
CC hw/9pfs/trace.o
CC hw/ppc/trace.o
CC hw/pci/trace.o
CC hw/pci-host/trace.o
CC hw/s390x/trace.o
CC hw/acpi/trace.o
CC hw/vfio/trace.o
CC hw/arm/trace.o
CC hw/alpha/trace.o
CC hw/hppa/trace.o
CC hw/xen/trace.o
CC hw/ide/trace.o
CC ui/trace.o
CC audio/trace.o
CC net/trace.o
CC target/arm/trace.o
CC target/i386/trace.o
CC target/mips/trace.o
CC target/sparc/trace.o
CC target/s390x/trace.o
CC target/ppc/trace.o
CC qom/trace.o
CC linux-user/trace.o
CC qapi/trace.o
CC accel/tcg/trace.o
CC accel/kvm/trace.o
CC nbd/trace.o
CC scsi/trace.o
CC crypto/pbkdf-stub.o
CC stubs/arch-query-cpu-def.o
CC stubs/arch-query-cpu-model-expansion.o
CC stubs/arch-query-cpu-model-comparison.o
CC stubs/arch-query-cpu-model-baseline.o
CC stubs/bdrv-next-monitor-owned.o
CC stubs/blk-commit-all.o
CC stubs/blockdev-close-all-bdrv-states.o
CC stubs/clock-warp.o
CC stubs/cpu-get-clock.o
CC stubs/cpu-get-icount.o
CC stubs/dump.o
CC stubs/error-printf.o
CC stubs/fdset.o
CC stubs/gdbstub.o
CC stubs/get-vm-name.o
CC stubs/iothread.o
CC stubs/iothread-lock.o
CC stubs/is-daemonized.o
CC stubs/machine-init-done.o
CC stubs/migr-blocker.o
CC stubs/change-state-handler.o
CC stubs/monitor.o
CC stubs/notify-event.o
CC stubs/qtest.o
CC stubs/replay.o
CC stubs/runstate-check.o
CC stubs/set-fd-handler.o
CC stubs/slirp.o
CC stubs/sysbus.o
CC stubs/tpm.o
CC stubs/trace-control.o
CC stubs/uuid.o
CC stubs/vm-stop.o
CC stubs/vmstate.o
CC stubs/fd-register.o
CC stubs/qmp_pc_dimm.o
CC stubs/target-monitor-defs.o
CC stubs/target-get-monitor-def.o
CC stubs/pc_madt_cpu_entry.o
CC stubs/vmgenid.o
CC stubs/xen-common.o
CC stubs/xen-hvm.o
CC stubs/pci-host-piix.o
GEN qemu-img-cmds.h
CC block.o
CC blockjob.o
CC qemu-io-cmds.o
CC replication.o
CC block/raw-format.o
CC block/qcow.o
CC block/vdi.o
CC block/vmdk.o
CC block/cloop.o
CC block/bochs.o
CC block/vpc.o
CC block/vvfat.o
CC block/dmg.o
CC block/qcow2.o
CC block/qcow2-refcount.o
CC block/qcow2-cluster.o
CC block/qcow2-snapshot.o
CC block/qcow2-cache.o
CC block/qcow2-bitmap.o
CC block/qed.o
CC block/qed-l2-cache.o
CC block/qed-table.o
CC block/qed-cluster.o
CC block/qed-check.o
CC block/vhdx.o
CC block/vhdx-endian.o
CC block/vhdx-log.o
CC block/quorum.o
CC block/parallels.o
CC block/blkdebug.o
CC block/blkverify.o
CC block/blkreplay.o
CC block/block-backend.o
CC block/snapshot.o
CC block/qapi.o
CC block/file-win32.o
CC block/win32-aio.o
CC block/null.o
CC block/mirror.o
CC block/commit.o
CC block/io.o
CC block/throttle-groups.o
CC block/nbd.o
CC block/nbd-client.o
CC block/sheepdog.o
CC block/accounting.o
CC block/dirty-bitmap.o
CC block/write-threshold.o
CC block/backup.o
CC block/replication.o
CC block/throttle.o
CC block/crypto.o
CC nbd/server.o
CC nbd/client.o
CC nbd/common.o
CC scsi/utils.o
CC block/curl.o
CC block/ssh.o
CC block/dmg-bz2.o
CC crypto/init.o
CC crypto/hash.o
CC crypto/hash-nettle.o
CC crypto/hmac.o
CC crypto/hmac-nettle.o
CC crypto/aes.o
CC crypto/desrfb.o
CC crypto/cipher.o
CC crypto/tlscreds.o
CC crypto/tlscredsanon.o
CC crypto/tlscredsx509.o
CC crypto/secret.o
CC crypto/tlssession.o
CC crypto/random-gnutls.o
CC crypto/pbkdf.o
CC crypto/pbkdf-nettle.o
CC crypto/ivgen.o
CC crypto/ivgen-essiv.o
CC crypto/ivgen-plain.o
CC crypto/ivgen-plain64.o
CC crypto/afsplit.o
CC crypto/xts.o
CC crypto/block.o
CC crypto/block-luks.o
CC crypto/block-qcow.o
CC io/channel.o
CC io/channel-buffer.o
CC io/channel-file.o
CC io/channel-command.o
CC io/channel-socket.o
CC io/channel-tls.o
CC io/channel-watch.o
CC io/channel-websock.o
CC io/channel-util.o
CC io/dns-resolver.o
CC io/net-listener.o
CC io/task.o
CC qom/object.o
CC qom/container.o
CC qom/qom-qobject.o
CC qom/object_interfaces.o
CC qemu-io.o
CC blockdev.o
CC blockdev-nbd.o
CC bootdevice.o
CC iothread.o
CC qdev-monitor.o
CC device-hotplug.o
CC bt-host.o
CC os-win32.o
CC bt-vhci.o
CC dma-helpers.o
CC vl.o
CC tpm.o
CC device_tree.o
CC qmp-marshal.o
CC qmp.o
CC hmp.o
CC cpus-common.o
CC audio/audio.o
CC audio/noaudio.o
CC audio/wavaudio.o
CC audio/mixeng.o
CC audio/sdlaudio.o
CC audio/dsoundaudio.o
CC audio/wavcapture.o
CC audio/audio_win_int.o
CC backends/rng.o
CC backends/rng-egd.o
CC backends/tpm.o
CC backends/hostmem.o
CC backends/hostmem-ram.o
CC backends/cryptodev.o
CC backends/cryptodev-builtin.o
CC block/stream.o
CC chardev/msmouse.o
CC chardev/wctablet.o
CC chardev/testdev.o
CC disas/arm.o
CXX disas/arm-a64.o
CC disas/i386.o
CXX disas/libvixl/vixl/utils.o
CXX disas/libvixl/vixl/compiler-intrinsics.o
CXX disas/libvixl/vixl/a64/instructions-a64.o
CXX disas/libvixl/vixl/a64/decoder-a64.o
CXX disas/libvixl/vixl/a64/disasm-a64.o
CC hw/acpi/core.o
CC hw/acpi/piix4.o
CC hw/acpi/pcihp.o
CC hw/acpi/ich9.o
CC hw/acpi/tco.o
CC hw/acpi/cpu_hotplug.o
CC hw/acpi/memory_hotplug.o
CC hw/acpi/cpu.o
CC hw/acpi/nvdimm.o
CC hw/acpi/vmgenid.o
CC hw/acpi/acpi_interface.o
CC hw/acpi/bios-linker-loader.o
CC hw/acpi/aml-build.o
CC hw/acpi/ipmi.o
CC hw/acpi/acpi-stub.o
CC hw/acpi/ipmi-stub.o
CC hw/audio/sb16.o
CC hw/audio/es1370.o
CC hw/audio/ac97.o
CC hw/audio/fmopl.o
CC hw/audio/adlib.o
CC hw/audio/gus.o
CC hw/audio/gusemu_hal.o
CC hw/audio/gusemu_mixer.o
CC hw/audio/cs4231a.o
CC hw/audio/intel-hda.o
CC hw/audio/hda-codec.o
CC hw/audio/pcspk.o
CC hw/audio/wm8750.o
CC hw/audio/pl041.o
CC hw/audio/lm4549.o
CC hw/audio/marvell_88w8618.o
CC hw/audio/soundhw.o
CC hw/block/block.o
CC hw/block/cdrom.o
CC hw/block/hd-geometry.o
CC hw/block/fdc.o
CC hw/block/m25p80.o
CC hw/block/nand.o
CC hw/block/pflash_cfi01.o
CC hw/block/pflash_cfi02.o
CC hw/block/ecc.o
CC hw/block/onenand.o
CC hw/block/nvme.o
CC hw/bt/core.o
CC hw/bt/l2cap.o
CC hw/bt/sdp.o
CC hw/bt/hci.o
CC hw/bt/hid.o
CC hw/bt/hci-csr.o
CC hw/char/ipoctal232.o
CC hw/char/parallel.o
CC hw/char/pl011.o
CC hw/char/serial.o
CC hw/char/serial-isa.o
CC hw/char/serial-pci.o
CC hw/char/virtio-console.o
CC hw/char/cadence_uart.o
CC hw/char/cmsdk-apb-uart.o
CC hw/char/debugcon.o
CC hw/char/imx_serial.o
CC hw/core/qdev.o
CC hw/core/qdev-properties.o
CC hw/core/bus.o
CC hw/core/reset.o
CC hw/core/qdev-fw.o
CC hw/core/fw-path-provider.o
CC hw/core/irq.o
CC hw/core/hotplug.o
CC hw/core/nmi.o
CC hw/core/stream.o
CC hw/core/ptimer.o
CC hw/core/sysbus.o
CC hw/core/machine.o
CC hw/core/loader.o
CC hw/core/qdev-properties-system.o
CC hw/core/register.o
CC hw/core/or-irq.o
CC hw/core/platform-bus.o
CC hw/display/ads7846.o
CC hw/cpu/core.o
CC hw/display/cirrus_vga.o
CC hw/display/pl110.o
CC hw/display/ssd0303.o
CC hw/display/ssd0323.o
CC hw/display/vga-pci.o
CC hw/display/vga-isa.o
CC hw/display/vmware_vga.o
CC hw/display/blizzard.o
CC hw/display/exynos4210_fimd.o
CC hw/display/framebuffer.o
CC hw/display/tc6393xb.o
CC hw/dma/pl080.o
CC hw/dma/pl330.o
CC hw/dma/i8257.o
CC hw/dma/xilinx_axidma.o
CC hw/dma/xlnx-zynq-devcfg.o
CC hw/gpio/max7310.o
CC hw/gpio/pl061.o
CC hw/gpio/zaurus.o
CC hw/gpio/gpio_key.o
CC hw/i2c/core.o
CC hw/i2c/smbus.o
CC hw/i2c/smbus_eeprom.o
CC hw/i2c/i2c-ddc.o
CC hw/i2c/versatile_i2c.o
CC hw/i2c/smbus_ich9.o
CC hw/i2c/pm_smbus.o
CC hw/i2c/bitbang_i2c.o
CC hw/i2c/exynos4210_i2c.o
CC hw/i2c/imx_i2c.o
CC hw/i2c/aspeed_i2c.o
CC hw/ide/core.o
CC hw/ide/atapi.o
CC hw/ide/qdev.o
CC hw/ide/pci.o
CC hw/ide/isa.o
CC hw/ide/piix.o
CC hw/ide/microdrive.o
CC hw/ide/ahci.o
CC hw/ide/ich.o
CC hw/ide/ahci-allwinner.o
CC hw/input/hid.o
CC hw/input/lm832x.o
CC hw/input/pckbd.o
CC hw/input/pl050.o
CC hw/input/ps2.o
CC hw/input/stellaris_input.o
CC hw/input/tsc2005.o
CC hw/input/virtio-input.o
CC hw/input/virtio-input-hid.o
CC hw/intc/i8259_common.o
CC hw/intc/i8259.o
CC hw/intc/pl190.o
CC hw/intc/xlnx-pmu-iomod-intc.o
CC hw/intc/xlnx-zynqmp-ipi.o
CC hw/intc/imx_avic.o
CC hw/intc/realview_gic.o
CC hw/intc/ioapic_common.o
CC hw/intc/arm_gic_common.o
CC hw/intc/arm_gic.o
CC hw/intc/arm_gicv2m.o
CC hw/intc/arm_gicv3_common.o
CC hw/intc/arm_gicv3.o
CC hw/intc/arm_gicv3_dist.o
CC hw/intc/arm_gicv3_redist.o
CC hw/intc/arm_gicv3_its_common.o
CC hw/intc/intc.o
CC hw/ipack/ipack.o
CC hw/ipack/tpci200.o
CC hw/ipmi/ipmi.o
CC hw/ipmi/ipmi_bmc_sim.o
CC hw/ipmi/ipmi_bmc_extern.o
CC hw/ipmi/isa_ipmi_kcs.o
CC hw/ipmi/isa_ipmi_bt.o
CC hw/isa/apm.o
CC hw/isa/isa-bus.o
CC hw/mem/pc-dimm.o
CC hw/mem/nvdimm.o
CC hw/misc/applesmc.o
CC hw/misc/max111x.o
CC hw/misc/tmp105.o
CC hw/misc/tmp421.o
CC hw/misc/debugexit.o
CC hw/misc/sga.o
CC hw/misc/pc-testdev.o
CC hw/misc/pci-testdev.o
CC hw/misc/edu.o
CC hw/misc/unimp.o
CC hw/misc/vmcoreinfo.o
CC hw/misc/arm_l2x0.o
CC hw/misc/arm_integrator_debug.o
CC hw/misc/a9scu.o
CC hw/misc/arm11scu.o
CC hw/net/ne2000.o
CC hw/net/eepro100.o
CC hw/net/pcnet-pci.o
CC hw/net/pcnet.o
CC hw/net/e1000.o
CC hw/net/e1000x_common.o
CC hw/net/net_tx_pkt.o
CC hw/net/net_rx_pkt.o
CC hw/net/e1000e.o
CC hw/net/e1000e_core.o
CC hw/net/rtl8139.o
CC hw/net/vmxnet3.o
CC hw/net/smc91c111.o
CC hw/net/lan9118.o
CC hw/net/ne2000-isa.o
CC hw/net/xgmac.o
CC hw/net/xilinx_axienet.o
CC hw/net/allwinner_emac.o
CC hw/net/imx_fec.o
CC hw/net/cadence_gem.o
CC hw/net/stellaris_enet.o
CC hw/net/ftgmac100.o
CC hw/net/rocker/rocker.o
CC hw/net/rocker/rocker_fp.o
CC hw/net/rocker/rocker_desc.o
CC hw/net/rocker/rocker_world.o
CC hw/net/rocker/rocker_of_dpa.o
CC hw/nvram/eeprom93xx.o
CC hw/nvram/eeprom_at24c.o
CC hw/nvram/fw_cfg.o
CC hw/nvram/chrp_nvram.o
CC hw/pci-bridge/pci_bridge_dev.o
CC hw/pci-bridge/pcie_root_port.o
CC hw/pci-bridge/gen_pcie_root_port.o
CC hw/pci-bridge/pcie_pci_bridge.o
CC hw/pci-bridge/pci_expander_bridge.o
CC hw/pci-bridge/xio3130_upstream.o
CC hw/pci-bridge/xio3130_downstream.o
CC hw/pci-bridge/ioh3420.o
CC hw/pci-bridge/i82801b11.o
CC hw/pci-host/pam.o
CC hw/pci-host/versatile.o
CC hw/pci-host/piix.o
CC hw/pci-host/q35.o
CC hw/pci-host/gpex.o
CC hw/pci/pci.o
CC hw/pci/msix.o
CC hw/pci/pci_bridge.o
CC hw/pci/msi.o
CC hw/pci/shpc.o
CC hw/pci/slotid_cap.o
CC hw/pci/pci_host.o
CC hw/pci/pcie_host.o
CC hw/pci/pcie.o
CC hw/pci/pcie_port.o
CC hw/pci/pcie_aer.o
CC hw/pci/pci-stub.o
CC hw/pcmcia/pcmcia.o
CC hw/scsi/scsi-disk.o
CC hw/scsi/scsi-generic.o
CC hw/scsi/scsi-bus.o
CC hw/scsi/lsi53c895a.o
CC hw/scsi/mptsas.o
CC hw/scsi/mptconfig.o
CC hw/scsi/mptendian.o
CC hw/scsi/megasas.o
CC hw/scsi/vmw_pvscsi.o
CC hw/scsi/esp.o
CC hw/scsi/esp-pci.o
CC hw/sd/pl181.o
CC hw/sd/ssi-sd.o
CC hw/sd/sd.o
CC hw/sd/core.o
CC hw/sd/sdhci.o
CC hw/smbios/smbios.o
CC hw/smbios/smbios_type_38.o
CC hw/smbios/smbios-stub.o
CC hw/smbios/smbios_type_38-stub.o
CC hw/ssi/pl022.o
CC hw/ssi/ssi.o
CC hw/ssi/xilinx_spips.o
CC hw/ssi/aspeed_smc.o
CC hw/ssi/stm32f2xx_spi.o
CC hw/ssi/mss-spi.o
CC hw/timer/arm_timer.o
CC hw/timer/arm_mptimer.o
CC hw/timer/armv7m_systick.o
CC hw/timer/a9gtimer.o
CC hw/timer/cadence_ttc.o
CC hw/timer/ds1338.o
CC hw/timer/hpet.o
CC hw/timer/i8254_common.o
CC hw/timer/i8254.o
CC hw/timer/pl031.o
CC hw/timer/twl92230.o
CC hw/timer/imx_epit.o
CC hw/timer/imx_gpt.o
CC hw/timer/stm32f2xx_timer.o
CC hw/timer/aspeed_timer.o
CC hw/timer/cmsdk-apb-timer.o
CC hw/timer/mss-timer.o
CC hw/tpm/tpm_util.o
CC hw/tpm/tpm_tis.o
CC hw/tpm/tpm_crb.o
CC hw/usb/core.o
CC hw/usb/combined-packet.o
CC hw/usb/bus.o
CC hw/usb/libhw.o
CC hw/usb/desc.o
CC hw/usb/desc-msos.o
CC hw/usb/hcd-uhci.o
CC hw/usb/hcd-ohci.o
CC hw/usb/hcd-ehci-pci.o
CC hw/usb/hcd-ehci-sysbus.o
CC hw/usb/hcd-ehci.o
CC hw/usb/hcd-xhci.o
CC hw/usb/hcd-xhci-nec.o
CC hw/usb/hcd-musb.o
CC hw/usb/dev-hub.o
CC hw/usb/dev-hid.o
CC hw/usb/dev-wacom.o
CC hw/usb/dev-storage.o
CC hw/usb/dev-uas.o
CC hw/usb/dev-audio.o
CC hw/usb/dev-serial.o
CC hw/usb/dev-network.o
CC hw/usb/dev-bluetooth.o
CC hw/usb/dev-smartcard-reader.o
CC hw/usb/host-stub.o
CC hw/virtio/virtio-rng.o
CC hw/virtio/virtio-pci.o
CC hw/virtio/virtio-bus.o
CC hw/virtio/virtio-mmio.o
CC hw/virtio/vhost-stub.o
CC hw/watchdog/watchdog.o
CC hw/watchdog/wdt_i6300esb.o
CC hw/watchdog/wdt_ib700.o
CC hw/watchdog/wdt_aspeed.o
CC migration/migration.o
CC migration/socket.o
CC migration/fd.o
CC migration/exec.o
CC migration/tls.o
CC migration/channel.o
CC migration/savevm.o
CC migration/colo-comm.o
CC migration/colo.o
CC migration/vmstate.o
CC migration/colo-failover.o
CC migration/vmstate-types.o
CC migration/page_cache.o
CC migration/qemu-file.o
CC migration/global_state.o
CC migration/qemu-file-channel.o
CC migration/xbzrle.o
CC migration/postcopy-ram.o
CC migration/qjson.o
CC migration/block.o
CC net/net.o
CC net/queue.o
CC net/checksum.o
CC net/util.o
CC net/hub.o
CC net/socket.o
CC net/dump.o
CC net/eth.o
CC net/slirp.o
CC net/filter.o
CC net/filter-buffer.o
CC net/filter-mirror.o
CC net/colo-compare.o
CC net/colo.o
CC net/filter-rewriter.o
CC net/filter-replay.o
CC net/tap-win32.o
CC qom/cpu.o
CC replay/replay.o
CC replay/replay-internal.o
CC replay/replay-events.o
CC replay/replay-time.o
CC replay/replay-input.o
CC replay/replay-char.o
CC replay/replay-snapshot.o
CC replay/replay-net.o
CC replay/replay-audio.o
CC slirp/cksum.o
CC slirp/if.o
CC slirp/ip_icmp.o
CC slirp/ip6_icmp.o
CC slirp/ip6_input.o
CC slirp/ip6_output.o
CC slirp/ip_input.o
CC slirp/ip_output.o
CC slirp/dnssearch.o
CC slirp/dhcpv6.o
CC slirp/slirp.o
CC slirp/mbuf.o
CC slirp/misc.o
CC slirp/socket.o
CC slirp/tcp_input.o
CC slirp/sbuf.o
CC slirp/tcp_output.o
CC slirp/tcp_subr.o
CC slirp/tcp_timer.o
CC slirp/udp.o
CC slirp/udp6.o
CC slirp/bootp.o
CC slirp/tftp.o
CC slirp/arp_table.o
CC slirp/ndp_table.o
CC slirp/ncsi.o
CC ui/keymaps.o
CC ui/console.o
CC ui/cursor.o
CC ui/qemu-pixman.o
CC ui/input.o
CC ui/input-keymap.o
CC ui/input-legacy.o
CC ui/sdl.o
CC ui/sdl_zoom.o
CC ui/vnc.o
CC ui/vnc-enc-zlib.o
CC ui/vnc-enc-hextile.o
CC ui/vnc-enc-tight.o
CC ui/vnc-palette.o
CC ui/vnc-enc-zrle.o
CC ui/vnc-auth-vencrypt.o
CC ui/vnc-ws.o
CC ui/vnc-jobs.o
CC ui/gtk.o
CC chardev/char.o
CC chardev/char-console.o
CC chardev/char-fe.o
CC chardev/char-file.o
CC chardev/char-io.o
CC chardev/char-mux.o
CC chardev/char-null.o
CC chardev/char-pipe.o
CC chardev/char-ringbuf.o
CC chardev/char-serial.o
CC chardev/char-socket.o
CC chardev/char-stdio.o
CC chardev/char-udp.o
CC chardev/char-win.o
CC chardev/char-win-stdio.o
CC qga/commands.o
CC qga/guest-agent-command-state.o
CC qga/main.o
CC qga/commands-win32.o
CC qga/channel-win32.o
CC qga/service-win32.o
AS optionrom/multiboot.o
AS optionrom/linuxboot.o
CC qga/vss-win32.o
CC optionrom/linuxboot_dma.o
AS optionrom/kvmvapic.o
BUILD optionrom/multiboot.img
BUILD optionrom/linuxboot.img
BUILD optionrom/kvmvapic.img
BUILD optionrom/multiboot.raw
CC qga/qapi-generated/qga-qapi-types.o
BUILD optionrom/linuxboot.raw
BUILD optionrom/linuxboot_dma.img
BUILD optionrom/kvmvapic.raw
CC qga/qapi-generated/qga-qapi-visit.o
BUILD optionrom/linuxboot_dma.raw
CC qga/qapi-generated/qga-qmp-marshal.o
SIGN optionrom/multiboot.bin
SIGN optionrom/linuxboot_dma.bin
AR libqemuutil.a
CC qemu-img.o
SIGN optionrom/kvmvapic.bin
SIGN optionrom/linuxboot.bin
LINK qemu-ga.exe
LINK qemu-img.exe
LINK qemu-io.exe
GEN x86_64-softmmu/hmp-commands.h
GEN x86_64-softmmu/config-target.h
GEN x86_64-softmmu/hmp-commands-info.h
GEN aarch64-softmmu/hmp-commands-info.h
GEN aarch64-softmmu/hmp-commands.h
GEN aarch64-softmmu/config-target.h
CC aarch64-softmmu/exec.o
CC aarch64-softmmu/tcg/tcg.o
CC aarch64-softmmu/tcg/tcg-op.o
CC aarch64-softmmu/tcg/tcg-common.o
CC aarch64-softmmu/disas.o
CC aarch64-softmmu/fpu/softfloat.o
CC aarch64-softmmu/tcg/optimize.o
CC x86_64-softmmu/exec.o
GEN aarch64-softmmu/gdbstub-xml.c
CC aarch64-softmmu/arch_init.o
CC x86_64-softmmu/tcg/tcg.o
CC aarch64-softmmu/cpus.o
CC x86_64-softmmu/tcg/tcg-op.o
CC aarch64-softmmu/monitor.o
CC aarch64-softmmu/gdbstub.o
CC x86_64-softmmu/tcg/optimize.o
CC x86_64-softmmu/tcg/tcg-common.o
CC aarch64-softmmu/balloon.o
CC aarch64-softmmu/ioport.o
CC x86_64-softmmu/fpu/softfloat.o
CC x86_64-softmmu/disas.o
GEN x86_64-softmmu/gdbstub-xml.c
CC aarch64-softmmu/numa.o
CC aarch64-softmmu/qtest.o
CC x86_64-softmmu/arch_init.o
CC aarch64-softmmu/memory.o
CC x86_64-softmmu/cpus.o
CC x86_64-softmmu/monitor.o
CC x86_64-softmmu/gdbstub.o
CC aarch64-softmmu/memory_mapping.o
CC x86_64-softmmu/balloon.o
CC x86_64-softmmu/ioport.o
CC x86_64-softmmu/numa.o
CC x86_64-softmmu/qtest.o
CC x86_64-softmmu/memory.o
CC aarch64-softmmu/dump.o
CC aarch64-softmmu/migration/ram.o
CC aarch64-softmmu/accel/accel.o
CC aarch64-softmmu/accel/stubs/hax-stub.o
CC x86_64-softmmu/memory_mapping.o
CC x86_64-softmmu/dump.o
CC aarch64-softmmu/accel/stubs/hvf-stub.o
CC aarch64-softmmu/accel/stubs/kvm-stub.o
CC x86_64-softmmu/migration/ram.o
CC aarch64-softmmu/accel/tcg/tcg-all.o
CC aarch64-softmmu/accel/tcg/cputlb.o
CC x86_64-softmmu/accel/accel.o
CC aarch64-softmmu/accel/tcg/tcg-runtime.o
CC x86_64-softmmu/accel/stubs/hvf-stub.o
CC aarch64-softmmu/accel/tcg/cpu-exec.o
CC aarch64-softmmu/accel/tcg/cpu-exec-common.o
CC x86_64-softmmu/accel/stubs/kvm-stub.o
CC aarch64-softmmu/accel/tcg/translate-all.o
CC x86_64-softmmu/accel/tcg/tcg-all.o
CC x86_64-softmmu/accel/tcg/cputlb.o
CC x86_64-softmmu/accel/tcg/tcg-runtime.o
CC aarch64-softmmu/accel/tcg/translator.o
CC x86_64-softmmu/accel/tcg/cpu-exec.o
CC aarch64-softmmu/hw/adc/stm32f2xx_adc.o
CC x86_64-softmmu/accel/tcg/cpu-exec-common.o
CC x86_64-softmmu/accel/tcg/translate-all.o
CC x86_64-softmmu/accel/tcg/translator.o
CC x86_64-softmmu/hw/block/virtio-blk.o
CC aarch64-softmmu/hw/block/virtio-blk.o
CC aarch64-softmmu/hw/block/dataplane/virtio-blk.o
CC x86_64-softmmu/hw/block/dataplane/virtio-blk.o
CC aarch64-softmmu/hw/char/exynos4210_uart.o
CC x86_64-softmmu/hw/char/virtio-serial-bus.o
CC aarch64-softmmu/hw/char/omap_uart.o
CC x86_64-softmmu/hw/core/generic-loader.o
CC aarch64-softmmu/hw/char/digic-uart.o
CC x86_64-softmmu/hw/core/null-machine.o
CC x86_64-softmmu/hw/display/vga.o
CC x86_64-softmmu/hw/display/virtio-gpu.o
CC aarch64-softmmu/hw/char/stm32f2xx_usart.o
CC aarch64-softmmu/hw/char/bcm2835_aux.o
CC aarch64-softmmu/hw/char/virtio-serial-bus.o
CC aarch64-softmmu/hw/core/generic-loader.o
CC x86_64-softmmu/hw/display/virtio-gpu-3d.o
CC aarch64-softmmu/hw/core/null-machine.o
CC x86_64-softmmu/hw/display/virtio-gpu-pci.o
CC aarch64-softmmu/hw/cpu/arm11mpcore.o
CC aarch64-softmmu/hw/cpu/realview_mpcore.o
CC aarch64-softmmu/hw/cpu/a15mpcore.o
CC aarch64-softmmu/hw/cpu/a9mpcore.o
CC x86_64-softmmu/hw/display/virtio-vga.o
CC x86_64-softmmu/hw/intc/apic.o
CC x86_64-softmmu/hw/intc/apic_common.o
CC aarch64-softmmu/hw/display/omap_dss.o
CC aarch64-softmmu/hw/display/omap_lcdc.o
CC aarch64-softmmu/hw/display/pxa2xx_lcd.o
CC x86_64-softmmu/hw/intc/ioapic.o
CC aarch64-softmmu/hw/display/bcm2835_fb.o
CC aarch64-softmmu/hw/display/vga.o
CC aarch64-softmmu/hw/display/virtio-gpu.o
CC x86_64-softmmu/hw/isa/lpc_ich9.o
CC x86_64-softmmu/hw/misc/pvpanic.o
CC x86_64-softmmu/hw/misc/mmio_interface.o
CC x86_64-softmmu/hw/net/virtio-net.o
CC x86_64-softmmu/hw/net/vhost_net.o
CC x86_64-softmmu/hw/scsi/virtio-scsi.o
CC aarch64-softmmu/hw/display/virtio-gpu-3d.o
CC aarch64-softmmu/hw/display/virtio-gpu-pci.o
CC x86_64-softmmu/hw/scsi/virtio-scsi-dataplane.o
CC x86_64-softmmu/hw/timer/mc146818rtc.o
CC aarch64-softmmu/hw/display/dpcd.o
CC x86_64-softmmu/hw/virtio/virtio.o
CC aarch64-softmmu/hw/display/xlnx_dp.o
CC aarch64-softmmu/hw/dma/xlnx_dpdma.o
CC aarch64-softmmu/hw/dma/omap_dma.o
CC aarch64-softmmu/hw/dma/soc_dma.o
CC x86_64-softmmu/hw/virtio/virtio-balloon.o
CC aarch64-softmmu/hw/dma/pxa2xx_dma.o
CC x86_64-softmmu/hw/virtio/virtio-crypto.o
CC aarch64-softmmu/hw/dma/bcm2835_dma.o
CC x86_64-softmmu/hw/virtio/virtio-crypto-pci.o
CC x86_64-softmmu/hw/i386/multiboot.o
CC aarch64-softmmu/hw/gpio/omap_gpio.o
CC aarch64-softmmu/hw/gpio/imx_gpio.o
CC aarch64-softmmu/hw/gpio/bcm2835_gpio.o
CC x86_64-softmmu/hw/i386/pc.o
CC x86_64-softmmu/hw/i386/pc_piix.o
CC x86_64-softmmu/hw/i386/pc_q35.o
CC aarch64-softmmu/hw/i2c/omap_i2c.o
CC x86_64-softmmu/hw/i386/pc_sysfw.o
CC aarch64-softmmu/hw/input/pxa2xx_keypad.o
CC x86_64-softmmu/hw/i386/x86-iommu.o
CC x86_64-softmmu/hw/i386/intel_iommu.o
CC x86_64-softmmu/hw/i386/amd_iommu.o
CC x86_64-softmmu/hw/i386/vmport.o
CC aarch64-softmmu/hw/input/tsc210x.o
CC x86_64-softmmu/hw/i386/vmmouse.o
CC x86_64-softmmu/hw/i386/kvmvapic.o
CC aarch64-softmmu/hw/intc/armv7m_nvic.o
CC aarch64-softmmu/hw/intc/exynos4210_gic.o
CC x86_64-softmmu/hw/i386/acpi-build.o
CC x86_64-softmmu/target/i386/helper.o
CC x86_64-softmmu/target/i386/cpu.o
CC aarch64-softmmu/hw/intc/exynos4210_combiner.o
CC x86_64-softmmu/target/i386/gdbstub.o
CC aarch64-softmmu/hw/intc/omap_intc.o
CC x86_64-softmmu/target/i386/xsave_helper.o
CC x86_64-softmmu/target/i386/translate.o
CC x86_64-softmmu/target/i386/bpt_helper.o
CC x86_64-softmmu/target/i386/cc_helper.o
CC x86_64-softmmu/target/i386/excp_helper.o
CC aarch64-softmmu/hw/intc/bcm2835_ic.o
CC aarch64-softmmu/hw/intc/bcm2836_control.o
CC x86_64-softmmu/target/i386/fpu_helper.o
CC x86_64-softmmu/target/i386/int_helper.o
CC aarch64-softmmu/hw/intc/allwinner-a10-pic.o
CC x86_64-softmmu/target/i386/mem_helper.o
CC x86_64-softmmu/target/i386/misc_helper.o
CC aarch64-softmmu/hw/intc/aspeed_vic.o
CC aarch64-softmmu/hw/intc/arm_gicv3_cpuif.o
CC x86_64-softmmu/target/i386/mpx_helper.o
CC aarch64-softmmu/hw/misc/arm_sysctl.o
CC x86_64-softmmu/target/i386/seg_helper.o
CC aarch64-softmmu/hw/misc/cbus.o
CC aarch64-softmmu/hw/misc/exynos4210_pmu.o
CC x86_64-softmmu/target/i386/smm_helper.o
CC aarch64-softmmu/hw/misc/exynos4210_clk.o
CC aarch64-softmmu/hw/misc/exynos4210_rng.o
CC x86_64-softmmu/target/i386/svm_helper.o
CC aarch64-softmmu/hw/misc/imx_ccm.o
CC aarch64-softmmu/hw/misc/imx31_ccm.o
CC aarch64-softmmu/hw/misc/imx25_ccm.o
CC x86_64-softmmu/target/i386/machine.o
CC x86_64-softmmu/target/i386/arch_memory_mapping.o
CC x86_64-softmmu/target/i386/arch_dump.o
CC aarch64-softmmu/hw/misc/imx6_ccm.o
CC x86_64-softmmu/target/i386/monitor.o
CC aarch64-softmmu/hw/misc/imx6_src.o
CC x86_64-softmmu/target/i386/kvm-stub.o
CC aarch64-softmmu/hw/misc/mst_fpga.o
CC x86_64-softmmu/target/i386/hax-all.o
CC aarch64-softmmu/hw/misc/omap_clk.o
CC x86_64-softmmu/target/i386/hax-mem.o
CC aarch64-softmmu/hw/misc/omap_gpmc.o
CC aarch64-softmmu/hw/misc/omap_l4.o
CC aarch64-softmmu/hw/misc/omap_sdrc.o
CC x86_64-softmmu/target/i386/hax-windows.o
CC aarch64-softmmu/hw/misc/omap_tap.o
GEN trace/generated-helpers.c
CC aarch64-softmmu/hw/misc/bcm2835_mbox.o
CC aarch64-softmmu/hw/misc/bcm2835_property.o
CC aarch64-softmmu/hw/misc/bcm2835_rng.o
/tmp/qemu-test/src/exec.c: In function 'qemu_ram_block_by_name':
/tmp/qemu-test/src/exec.c:2373:11: error: implicit declaration of function 'basename' [-Werror=implicit-function-declaration]
id1 = basename(name1);
^~~~~~~~
/tmp/qemu-test/src/exec.c:2373:5: error: nested extern declaration of 'basename' [-Werror=nested-externs]
id1 = basename(name1);
^~~
/tmp/qemu-test/src/exec.c:2373:9: error: assignment makes pointer from integer without a cast [-Werror=int-conversion]
id1 = basename(name1);
^
/tmp/qemu-test/src/exec.c:2377:6: error: assignment makes pointer from integer without a cast [-Werror=int-conversion]
id2 = basename(name2);
^
cc1: all warnings being treated as errors
CC aarch64-softmmu/hw/misc/zynq_slcr.o
/tmp/qemu-test/src/rules.mak:66: recipe for target 'exec.o' failed
make[1]: *** [exec.o] Error 1
make[1]: *** Waiting for unfinished jobs....
Makefile:403: recipe for target 'subdir-x86_64-softmmu' failed
make: *** [subdir-x86_64-softmmu] Error 2
make: *** Waiting for unfinished jobs....
CC aarch64-softmmu/hw/misc/zynq-xadc.o
CC aarch64-softmmu/hw/misc/stm32f2xx_syscfg.o
CC aarch64-softmmu/hw/misc/mps2-scc.o
CC aarch64-softmmu/hw/misc/auxbus.o
CC aarch64-softmmu/hw/misc/aspeed_scu.o
CC aarch64-softmmu/hw/misc/aspeed_sdmc.o
CC aarch64-softmmu/hw/misc/mmio_interface.o
CC aarch64-softmmu/hw/misc/msf2-sysreg.o
CC aarch64-softmmu/hw/net/virtio-net.o
CC aarch64-softmmu/hw/net/vhost_net.o
/tmp/qemu-test/src/exec.c: In function 'qemu_ram_block_by_name':
/tmp/qemu-test/src/exec.c:2373:11: error: implicit declaration of function 'basename' [-Werror=implicit-function-declaration]
id1 = basename(name1);
^~~~~~~~
/tmp/qemu-test/src/exec.c:2373:5: error: nested extern declaration of 'basename' [-Werror=nested-externs]
id1 = basename(name1);
^~~
/tmp/qemu-test/src/exec.c:2373:9: error: assignment makes pointer from integer without a cast [-Werror=int-conversion]
id1 = basename(name1);
^
/tmp/qemu-test/src/exec.c:2377:6: error: assignment makes pointer from integer without a cast [-Werror=int-conversion]
id2 = basename(name2);
^
cc1: all warnings being treated as errors
CC aarch64-softmmu/hw/pcmcia/pxa2xx.o
/tmp/qemu-test/src/rules.mak:66: recipe for target 'exec.o' failed
make[1]: *** [exec.o] Error 1
make[1]: *** Waiting for unfinished jobs....
CC aarch64-softmmu/hw/scsi/virtio-scsi.o
Makefile:403: recipe for target 'subdir-aarch64-softmmu' failed
make: *** [subdir-aarch64-softmmu] Error 2
Traceback (most recent call last):
File "./tests/docker/docker.py", line 407, in <module>
sys.exit(main())
File "./tests/docker/docker.py", line 404, in main
return args.cmdobj.run(args, argv)
File "./tests/docker/docker.py", line 261, in run
return Docker().run(argv, args.keep, quiet=args.quiet)
File "./tests/docker/docker.py", line 229, in run
quiet=quiet)
File "./tests/docker/docker.py", line 147, in _do_check
return subprocess.check_call(self._command + cmd, **kwargs)
File "/usr/lib64/python2.7/subprocess.py", line 186, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['docker', 'run', '--label', 'com.qemu.instance.uuid=042d3c8c0a8f11e892f952540069c830', '-u', '0', '--security-opt', 'seccomp=unconfined', '--rm', '--net=none', '-e', 'TARGET_LIST=', '-e', 'EXTRA_CONFIGURE_OPTS=', '-e', 'V=', '-e', 'J=8', '-e', 'DEBUG=', '-e', 'SHOW_ENV=1', '-e', 'CCACHE_DIR=/var/tmp/ccache', '-v', '/root/.cache/qemu-docker-ccache:/var/tmp/ccache:z', '-v', '/var/tmp/patchew-tester-tmp-83d1w41a/src/docker-src.2018-02-05-11.09.50.15886:/var/tmp/qemu:z,ro', 'qemu:fedora', '/var/tmp/qemu/run', 'test-mingw']' returned non-zero exit status 2
make[1]: *** [tests/docker/Makefile.include:129: docker-run] Error 1
make: *** [tests/docker/Makefile.include:163: docker-run-test-mingw@fedora] Error 2
real 2m28.722s
user 0m4.904s
sys 0m3.597s
=== OUTPUT END ===
Test command exited with code: 2
---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to patchew-devel@freelists.org
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration
2018-02-05 15:53 ` Paolo Bonzini
@ 2018-02-05 16:12 ` Tan, Jianfeng
2018-02-05 16:19 ` Paolo Bonzini
0 siblings, 1 reply; 28+ messages in thread
From: Tan, Jianfeng @ 2018-02-05 16:12 UTC (permalink / raw)
To: Paolo Bonzini, qemu-devel
Cc: Jason Wang, Michael S . Tsirkin, Maxime Coquelin
Hi Paolo,
On 2/5/2018 11:53 PM, Paolo Bonzini wrote:
> On 05/02/2018 15:58, Jianfeng Tan wrote:
>> Here are some options to fix this:
>>
>> 1. When we do ram name comparison, we truncate the prefix as this patch shows.
>> It cannot cover the corner case: the source VM could have two ram blocks
>> with name of "pc.ram" and "/object/pc.ram".
> That shouldn't happen ("pc.ram" exists even in the "-numa
> node,memdev=..." case, but it has no RAM block).
Suppose we have a VM started with "-m xG", and then hot plugged with a
ram block:
(qemu) object_add
memory-backend-file,id=pc.ram,size=1G,mem-path=/dev/hugepages
(qemu) device_add pc-dimm,id=pc.ram,memdev=pc.ram
Then we would have both ram block named pc.ram:
Block Name PSize
pc.ram 4 KiB
/objects/pc.ram 2 MiB
But I assume it's a corner case which not really happen.
>
>> RAMBLOCK_FOREACH(block) {
>> - if (!strcmp(name, block->idstr)) {
>> + name2 = strdup(block->idstr);
>> + id2 = basename(name2);
>> + if (!strcmp(id1, id2)) {
>> + free(name1);
>> + free(name2);
>> return block;
>> }
>> + free(name2);
> Instead of this, perhaps just skip "/object/" in both id1 and
> block->idstr? This also removes the need for strdup/free.
Not familiar with this before, so there would not be something like
/object/xxx/id? In that case, we can just skip "/object/". Thanks!
>
> However, note that
>
> -m xG -numa node,memdev=pc.ram \
> -object memory-backend-file,id=pc.ram,...
>
> works for both vhost-kernel and vhost-user, so I'd rather consider this
> a configuration problem and not do anything.
That configuration indeed works for both. But in the production env,
lots of VMs are already started with previous mem config. If we do
nothing, it will take a long time (shutdown/start for each VM) to
migrate to the new setup. This patch is to make this process more smooth
without any bad effect if possible.
Thanks,
Jianfeng
>
> Thanks,
>
> Paolo
>
>> }
>>
>> + free(name1);
>> return NULL;
>> }
>>
>>
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration
2018-02-05 16:12 ` Tan, Jianfeng
@ 2018-02-05 16:19 ` Paolo Bonzini
2018-02-05 16:44 ` Tan, Jianfeng
2018-02-05 17:15 ` Igor Mammedov
0 siblings, 2 replies; 28+ messages in thread
From: Paolo Bonzini @ 2018-02-05 16:19 UTC (permalink / raw)
To: Tan, Jianfeng, qemu-devel
Cc: Jason Wang, Michael S . Tsirkin, Maxime Coquelin
On 05/02/2018 17:12, Tan, Jianfeng wrote:
> Hi Paolo,
>
> On 2/5/2018 11:53 PM, Paolo Bonzini wrote:
>> On 05/02/2018 15:58, Jianfeng Tan wrote:
>>> Here are some options to fix this:
>>>
>>> 1. When we do ram name comparison, we truncate the prefix as this
>>> patch shows.
>>> It cannot cover the corner case: the source VM could have two ram blocks
>>> with name of "pc.ram" and "/object/pc.ram".
>> That shouldn't happen ("pc.ram" exists even in the "-numa
>> node,memdev=..." case, but it has no RAM block).
>
> Suppose we have a VM started with "-m xG", and then hot plugged with a
> ram block:
> (qemu) object_add
> memory-backend-file,id=pc.ram,size=1G,mem-path=/dev/hugepages
> (qemu) device_add pc-dimm,id=pc.ram,memdev=pc.ram
>
> Then we would have both ram block named pc.ram:
> Block Name PSize
> pc.ram 4 KiB
> /objects/pc.ram 2 MiB
>
> But I assume it's a corner case which not really happen.
Yeah, you're right. :/ I hadn't thought of hotplug. It can happen indeed.
>> However, note that
>>
>> -m xG -numa node,memdev=pc.ram \
>> -object memory-backend-file,id=pc.ram,...
>>
>> works for both vhost-kernel and vhost-user, so I'd rather consider this
>> a configuration problem and not do anything.
>
> That configuration indeed works for both. But in the production env,
> lots of VMs are already started with previous mem config. If we do
> nothing, it will take a long time (shutdown/start for each VM) to
> migrate to the new setup. This patch is to make this process more smooth
> without any bad effect if possible.
I understand. However it's not as bad as "there's no possibility at all
to migrate from vhost-kernel to vhost-user". There are cases that are
more problematic: for example, there's no possibility at all to add
memory NUMA policy during a live migration, unless -object
memory-backend-* was used on the source.
Paolo
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration
2018-02-05 14:58 [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration Jianfeng Tan
` (2 preceding siblings ...)
2018-02-05 16:12 ` no-reply
@ 2018-02-05 16:29 ` Igor Mammedov
2018-02-05 16:51 ` Tan, Jianfeng
3 siblings, 1 reply; 28+ messages in thread
From: Igor Mammedov @ 2018-02-05 16:29 UTC (permalink / raw)
To: Jianfeng Tan
Cc: qemu-devel, Paolo Bonzini, Jason Wang, Maxime Coquelin,
Michael S . Tsirkin
On Mon, 5 Feb 2018 14:58:55 +0000
Jianfeng Tan <jianfeng.tan@intel.com> wrote:
> Existing VMs with virtio devices and vhost-kernel as the backend
> are always started with mem config:
>
> "-m xG"
> (with a ram block named "pc.ram")
>
> while new VMs with virtio devices and vhost-user as the backend
> are always started with mem config:
>
> "-m xG -numa node,memdev=pc.ram -object memory-backend-file,id=pc.ram,..."
> (with a ram block named "/object/pc.ram")
could you elaborate more on what src command line migrating to what dst command line?
> As we migrate from vhost-kernel to vhost-user, it failes as:
>
> Unknown ramblock "pc.ram", cannot accept migration
> error while loading state for instance 0x0 of device 'ram'
> load of migration failed: Invalid argument
>
> Here are some options to fix this:
>
> 1. When we do ram name comparison, we truncate the prefix as this patch shows.
> It cannot cover the corner case: the source VM could have two ram blocks
> with name of "pc.ram" and "/object/pc.ram".
>
> 2. We add an alias name to RAMBlock; when we do name comparison, not only
> idstr is compared, but also compared to the alias. But this will add more
> complexity to upper layer stack OpenStack/libvirt.
>
> Any thoughts?
>
> Cc: Jason Wang <jasowang@redhat.com>
> Cc: Michael S. Tsirkin <mst@redhat.com>
> Cc: Maxime Coquelin <maxime.coquelin@redhat.com>
> Cc: Paolo Bonzini <pbonzini@redhat.com>
> Suggested-by: Michael S. Tsirkin <mst@redhat.com>
> Signed-off-by: Jianfeng Tan <jianfeng.tan@intel.com>
> ---
> exec.c | 13 ++++++++++++-
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/exec.c b/exec.c
> index 4722e52..d294e5c 100644
> --- a/exec.c
> +++ b/exec.c
> @@ -2334,13 +2334,24 @@ found:
> RAMBlock *qemu_ram_block_by_name(const char *name)
> {
> RAMBlock *block;
> + char *name1, *id1;
> + char *name2, *id2;
> +
> + name1 = strdup(name);
> + id1 = basename(name1);
>
> RAMBLOCK_FOREACH(block) {
> - if (!strcmp(name, block->idstr)) {
> + name2 = strdup(block->idstr);
> + id2 = basename(name2);
> + if (!strcmp(id1, id2)) {
> + free(name1);
> + free(name2);
> return block;
> }
> + free(name2);
> }
>
> + free(name1);
> return NULL;
> }
>
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration
2018-02-05 16:19 ` Paolo Bonzini
@ 2018-02-05 16:44 ` Tan, Jianfeng
2018-02-05 16:53 ` Paolo Bonzini
2018-02-05 17:15 ` Igor Mammedov
1 sibling, 1 reply; 28+ messages in thread
From: Tan, Jianfeng @ 2018-02-05 16:44 UTC (permalink / raw)
To: Paolo Bonzini, qemu-devel
Cc: Jason Wang, Michael S . Tsirkin, Maxime Coquelin
On 2/6/2018 12:19 AM, Paolo Bonzini wrote:
> On 05/02/2018 17:12, Tan, Jianfeng wrote:
>> Hi Paolo,
>>
>> On 2/5/2018 11:53 PM, Paolo Bonzini wrote:
>>> On 05/02/2018 15:58, Jianfeng Tan wrote:
>>>> Here are some options to fix this:
>>>>
>>>> 1. When we do ram name comparison, we truncate the prefix as this
>>>> patch shows.
>>>> It cannot cover the corner case: the source VM could have two ram blocks
>>>> with name of "pc.ram" and "/object/pc.ram".
>>> That shouldn't happen ("pc.ram" exists even in the "-numa
>>> node,memdev=..." case, but it has no RAM block).
>> Suppose we have a VM started with "-m xG", and then hot plugged with a
>> ram block:
>> (qemu) object_add
>> memory-backend-file,id=pc.ram,size=1G,mem-path=/dev/hugepages
>> (qemu) device_add pc-dimm,id=pc.ram,memdev=pc.ram
>>
>> Then we would have both ram block named pc.ram:
>> Block Name PSize
>> pc.ram 4 KiB
>> /objects/pc.ram 2 MiB
>>
>> But I assume it's a corner case which not really happen.
> Yeah, you're right. :/ I hadn't thought of hotplug. It can happen indeed.
>
>>> However, note that
>>>
>>> -m xG -numa node,memdev=pc.ram \
>>> -object memory-backend-file,id=pc.ram,...
>>>
>>> works for both vhost-kernel and vhost-user, so I'd rather consider this
>>> a configuration problem and not do anything.
>> That configuration indeed works for both. But in the production env,
>> lots of VMs are already started with previous mem config. If we do
>> nothing, it will take a long time (shutdown/start for each VM) to
>> migrate to the new setup. This patch is to make this process more smooth
>> without any bad effect if possible.
> I understand. However it's not as bad as "there's no possibility at all
> to migrate from vhost-kernel to vhost-user". There are cases that are
> more problematic: for example, there's no possibility at all to add
> memory NUMA policy during a live migration, unless -object
> memory-backend-* was used on the source.
Please help me to understand: Are you saying it's always recommended to
use -object memory-backend-* configuration even with vhost-kernel
backend for the reason you mentioned? Or just another more serious
problem that we shall work on in priority?
Thanks,
Jianfeng
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration
2018-02-05 16:29 ` Igor Mammedov
@ 2018-02-05 16:51 ` Tan, Jianfeng
2018-02-05 18:36 ` Dr. David Alan Gilbert
0 siblings, 1 reply; 28+ messages in thread
From: Tan, Jianfeng @ 2018-02-05 16:51 UTC (permalink / raw)
To: Igor Mammedov
Cc: qemu-devel, Paolo Bonzini, Jason Wang, Maxime Coquelin,
Michael S . Tsirkin
On 2/6/2018 12:29 AM, Igor Mammedov wrote:
> On Mon, 5 Feb 2018 14:58:55 +0000
> Jianfeng Tan <jianfeng.tan@intel.com> wrote:
>
>> Existing VMs with virtio devices and vhost-kernel as the backend
>> are always started with mem config:
>>
>> "-m xG"
>> (with a ram block named "pc.ram")
>>
>> while new VMs with virtio devices and vhost-user as the backend
>> are always started with mem config:
>>
>> "-m xG -numa node,memdev=pc.ram -object memory-backend-file,id=pc.ram,..."
>> (with a ram block named "/object/pc.ram")
> could you elaborate more on what src command line migrating to what dst command line?
The src cmdline:
$QEMU -enable-kvm -cpu host -smp 4 /path/to/img \
-m 2G \
-netdev tap,id=mynet1,vhost=on \
-device virtio-net-pci,netdev=mynet1,mac=52:54:00:12:34:58 ...
The dst cmdline:
$QEMU -enable-kvm -cpu host -smp 4 /path/to/img \
-m 2G -numa node,memdev=pc.ram -mem-prealloc \
-object
memory-backend-file,id=pc.ram,size=2G,mem-path=/dev/hugepages,share=on \
-chardev socket,id=char0,path=/tmp/sock0 \
-netdev type=vhost-user,id=mynet1,chardev=char0,vhostforce \
-device virtio-net-pci,netdev=mynet1,mac=52:54:00:12:34:58 \
-incoming tcp:0:4444 ...
Thanks,
Jianfeng
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration
2018-02-05 16:44 ` Tan, Jianfeng
@ 2018-02-05 16:53 ` Paolo Bonzini
0 siblings, 0 replies; 28+ messages in thread
From: Paolo Bonzini @ 2018-02-05 16:53 UTC (permalink / raw)
To: Tan, Jianfeng, qemu-devel
Cc: Jason Wang, Michael S . Tsirkin, Maxime Coquelin
On 05/02/2018 17:44, Tan, Jianfeng wrote:
>>>
>> I understand. However it's not as bad as "there's no possibility at all
>> to migrate from vhost-kernel to vhost-user". There are cases that are
>> more problematic: for example, there's no possibility at all to add
>> memory NUMA policy during a live migration, unless -object
>> memory-backend-* was used on the source.
>
> Please help me to understand: Are you saying it's always recommended to
> use -object memory-backend-* configuration even with vhost-kernel
> backend for the reason you mentioned?
Indeed---in general, there's no downside to always using -object to
start a virtual machine. Of course when migrating a machine that was
started without -object, you need to use it on the destination too.
Paolo
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration
2018-02-05 16:19 ` Paolo Bonzini
2018-02-05 16:44 ` Tan, Jianfeng
@ 2018-02-05 17:15 ` Igor Mammedov
2018-02-05 17:31 ` Paolo Bonzini
2018-02-05 18:44 ` Dr. David Alan Gilbert
1 sibling, 2 replies; 28+ messages in thread
From: Igor Mammedov @ 2018-02-05 17:15 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Tan, Jianfeng, qemu-devel, Jason Wang, Maxime Coquelin,
Michael S . Tsirkin
On Mon, 5 Feb 2018 17:19:09 +0100
Paolo Bonzini <pbonzini@redhat.com> wrote:
> On 05/02/2018 17:12, Tan, Jianfeng wrote:
> > Hi Paolo,
> >
> > On 2/5/2018 11:53 PM, Paolo Bonzini wrote:
> >> On 05/02/2018 15:58, Jianfeng Tan wrote:
> >>> Here are some options to fix this:
> >>>
> >>> 1. When we do ram name comparison, we truncate the prefix as this
> >>> patch shows.
> >>> It cannot cover the corner case: the source VM could have two ram blocks
> >>> with name of "pc.ram" and "/object/pc.ram".
> >> That shouldn't happen ("pc.ram" exists even in the "-numa
> >> node,memdev=..." case, but it has no RAM block).
> >
> > Suppose we have a VM started with "-m xG", and then hot plugged with a
> > ram block:
> > (qemu) object_add
> > memory-backend-file,id=pc.ram,size=1G,mem-path=/dev/hugepages
> > (qemu) device_add pc-dimm,id=pc.ram,memdev=pc.ram
> >
> > Then we would have both ram block named pc.ram:
> > Block Name PSize
> > pc.ram 4 KiB
> > /objects/pc.ram 2 MiB
> >
> > But I assume it's a corner case which not really happen.
>
> Yeah, you're right. :/ I hadn't thought of hotplug. It can happen indeed.
perhaps we should fail object_add memory-backend-foo if it resulted
in creating ramblock with duplicate id
>
> >> However, note that
> >>
> >> -m xG -numa node,memdev=pc.ram \
> >> -object memory-backend-file,id=pc.ram,...
> >>
> >> works for both vhost-kernel and vhost-user, so I'd rather consider this
> >> a configuration problem and not do anything.
> >
> > That configuration indeed works for both. But in the production env,
> > lots of VMs are already started with previous mem config. If we do
> > nothing, it will take a long time (shutdown/start for each VM) to
> > migrate to the new setup. This patch is to make this process more smooth
> > without any bad effect if possible.
>
> I understand. However it's not as bad as "there's no possibility at all
> to migrate from vhost-kernel to vhost-user". There are cases that are
> more problematic: for example, there's no possibility at all to add
> memory NUMA policy during a live migration, unless -object
> memory-backend-* was used on the source.
>
> Paolo
>
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration
2018-02-05 17:15 ` Igor Mammedov
@ 2018-02-05 17:31 ` Paolo Bonzini
2018-02-07 7:49 ` Tan, Jianfeng
2018-02-05 18:44 ` Dr. David Alan Gilbert
1 sibling, 1 reply; 28+ messages in thread
From: Paolo Bonzini @ 2018-02-05 17:31 UTC (permalink / raw)
To: Igor Mammedov
Cc: Tan, Jianfeng, qemu-devel, Jason Wang, Maxime Coquelin,
Michael S . Tsirkin
On 05/02/2018 18:15, Igor Mammedov wrote:
>>>
>>> Then we would have both ram block named pc.ram:
>>> Block Name PSize
>>> pc.ram 4 KiB
>>> /objects/pc.ram 2 MiB
>>>
>>> But I assume it's a corner case which not really happen.
>> Yeah, you're right. :/ I hadn't thought of hotplug. It can happen indeed.
>
> perhaps we should fail object_add memory-backend-foo if it resulted
> in creating ramblock with duplicate id
Note that it would only be duplicated with Jianfeng's patch. So I'm
worried that his patch is worse than what we have now, because it may
create conflicts with system RAMBlock names are not necessarily
predictable. Right now, -object creates RAMBlock names that are nicely
constrained within /object/.
Paolo
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration
2018-02-05 16:51 ` Tan, Jianfeng
@ 2018-02-05 18:36 ` Dr. David Alan Gilbert
2018-02-06 15:24 ` Igor Mammedov
0 siblings, 1 reply; 28+ messages in thread
From: Dr. David Alan Gilbert @ 2018-02-05 18:36 UTC (permalink / raw)
To: Tan, Jianfeng
Cc: Igor Mammedov, Paolo Bonzini, Jason Wang, Maxime Coquelin,
qemu-devel, Michael S . Tsirkin
* Tan, Jianfeng (jianfeng.tan@intel.com) wrote:
>
>
> On 2/6/2018 12:29 AM, Igor Mammedov wrote:
> > On Mon, 5 Feb 2018 14:58:55 +0000
> > Jianfeng Tan <jianfeng.tan@intel.com> wrote:
> >
> > > Existing VMs with virtio devices and vhost-kernel as the backend
> > > are always started with mem config:
> > >
> > > "-m xG"
> > > (with a ram block named "pc.ram")
> > >
> > > while new VMs with virtio devices and vhost-user as the backend
> > > are always started with mem config:
> > >
> > > "-m xG -numa node,memdev=pc.ram -object memory-backend-file,id=pc.ram,..."
> > > (with a ram block named "/object/pc.ram")
> > could you elaborate more on what src command line migrating to what dst command line?
>
> The src cmdline:
> $QEMU -enable-kvm -cpu host -smp 4 /path/to/img \
> -m 2G \
> -netdev tap,id=mynet1,vhost=on \
> -device virtio-net-pci,netdev=mynet1,mac=52:54:00:12:34:58 ...
>
> The dst cmdline:
> $QEMU -enable-kvm -cpu host -smp 4 /path/to/img \
> -m 2G -numa node,memdev=pc.ram -mem-prealloc \
> -object
> memory-backend-file,id=pc.ram,size=2G,mem-path=/dev/hugepages,share=on \
> -chardev socket,id=char0,path=/tmp/sock0 \
> -netdev type=vhost-user,id=mynet1,chardev=char0,vhostforce \
> -device virtio-net-pci,netdev=mynet1,mac=52:54:00:12:34:58 \
> -incoming tcp:0:4444 ...
I'm surprised that it's safe to -numa node the destination, even with
the hack to the RAMBlock naming. I'd expect it to have other effects
as well.
Dave
> Thanks,
> Jianfeng
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration
2018-02-05 17:15 ` Igor Mammedov
2018-02-05 17:31 ` Paolo Bonzini
@ 2018-02-05 18:44 ` Dr. David Alan Gilbert
1 sibling, 0 replies; 28+ messages in thread
From: Dr. David Alan Gilbert @ 2018-02-05 18:44 UTC (permalink / raw)
To: Igor Mammedov
Cc: Paolo Bonzini, Tan, Jianfeng, Maxime Coquelin, Jason Wang,
qemu-devel, Michael S . Tsirkin
* Igor Mammedov (imammedo@redhat.com) wrote:
> On Mon, 5 Feb 2018 17:19:09 +0100
> Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> > On 05/02/2018 17:12, Tan, Jianfeng wrote:
> > > Hi Paolo,
> > >
> > > On 2/5/2018 11:53 PM, Paolo Bonzini wrote:
> > >> On 05/02/2018 15:58, Jianfeng Tan wrote:
> > >>> Here are some options to fix this:
> > >>>
> > >>> 1. When we do ram name comparison, we truncate the prefix as this
> > >>> patch shows.
> > >>> It cannot cover the corner case: the source VM could have two ram blocks
> > >>> with name of "pc.ram" and "/object/pc.ram".
> > >> That shouldn't happen ("pc.ram" exists even in the "-numa
> > >> node,memdev=..." case, but it has no RAM block).
> > >
> > > Suppose we have a VM started with "-m xG", and then hot plugged with a
> > > ram block:
> > > (qemu) object_add
> > > memory-backend-file,id=pc.ram,size=1G,mem-path=/dev/hugepages
> > > (qemu) device_add pc-dimm,id=pc.ram,memdev=pc.ram
> > >
> > > Then we would have both ram block named pc.ram:
> > > Block Name PSize
> > > pc.ram 4 KiB
> > > /objects/pc.ram 2 MiB
> > >
> > > But I assume it's a corner case which not really happen.
> >
> > Yeah, you're right. :/ I hadn't thought of hotplug. It can happen indeed.
> perhaps we should fail object_add memory-backend-foo if it resulted
> in creating ramblock with duplicate id
>
That's probably not a bad idea; I thought I'd hit a simpliar problem a
while ago; I'd ended up (through a different problem) of having
RAMBlocks with empty names and ended up with two of them.
Dave
> >
> > >> However, note that
> > >>
> > >> -m xG -numa node,memdev=pc.ram \
> > >> -object memory-backend-file,id=pc.ram,...
> > >>
> > >> works for both vhost-kernel and vhost-user, so I'd rather consider this
> > >> a configuration problem and not do anything.
> > >
> > > That configuration indeed works for both. But in the production env,
> > > lots of VMs are already started with previous mem config. If we do
> > > nothing, it will take a long time (shutdown/start for each VM) to
> > > migrate to the new setup. This patch is to make this process more smooth
> > > without any bad effect if possible.
> >
> > I understand. However it's not as bad as "there's no possibility at all
> > to migrate from vhost-kernel to vhost-user". There are cases that are
> > more problematic: for example, there's no possibility at all to add
> > memory NUMA policy during a live migration, unless -object
> > memory-backend-* was used on the source.
> >
> > Paolo
> >
>
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration
2018-02-05 18:36 ` Dr. David Alan Gilbert
@ 2018-02-06 15:24 ` Igor Mammedov
0 siblings, 0 replies; 28+ messages in thread
From: Igor Mammedov @ 2018-02-06 15:24 UTC (permalink / raw)
To: Dr. David Alan Gilbert
Cc: Tan, Jianfeng, Paolo Bonzini, Jason Wang, Maxime Coquelin,
qemu-devel, Michael S . Tsirkin
On Mon, 5 Feb 2018 18:36:31 +0000
"Dr. David Alan Gilbert" <dgilbert@redhat.com> wrote:
> * Tan, Jianfeng (jianfeng.tan@intel.com) wrote:
> >
> >
> > On 2/6/2018 12:29 AM, Igor Mammedov wrote:
> > > On Mon, 5 Feb 2018 14:58:55 +0000
> > > Jianfeng Tan <jianfeng.tan@intel.com> wrote:
> > >
> > > > Existing VMs with virtio devices and vhost-kernel as the backend
> > > > are always started with mem config:
> > > >
> > > > "-m xG"
> > > > (with a ram block named "pc.ram")
> > > >
> > > > while new VMs with virtio devices and vhost-user as the backend
> > > > are always started with mem config:
> > > >
> > > > "-m xG -numa node,memdev=pc.ram -object memory-backend-file,id=pc.ram,..."
> > > > (with a ram block named "/object/pc.ram")
> > > could you elaborate more on what src command line migrating to what dst command line?
> >
> > The src cmdline:
> > $QEMU -enable-kvm -cpu host -smp 4 /path/to/img \
> > -m 2G \
> > -netdev tap,id=mynet1,vhost=on \
> > -device virtio-net-pci,netdev=mynet1,mac=52:54:00:12:34:58 ...
> >
> > The dst cmdline:
> > $QEMU -enable-kvm -cpu host -smp 4 /path/to/img \
> > -m 2G -numa node,memdev=pc.ram -mem-prealloc \
> > -object
> > memory-backend-file,id=pc.ram,size=2G,mem-path=/dev/hugepages,share=on \
> > -chardev socket,id=char0,path=/tmp/sock0 \
> > -netdev type=vhost-user,id=mynet1,chardev=char0,vhostforce \
> > -device virtio-net-pci,netdev=mynet1,mac=52:54:00:12:34:58 \
> > -incoming tcp:0:4444 ...
>
> I'm surprised that it's safe to -numa node the destination, even with
> the hack to the RAMBlock naming. I'd expect it to have other effects
> as well.
it supposed to be 2 mutually exclusive configurations,
but migration stream doesn't have that information explicitly
(different id naming/mapping could fail migration).
> Dave
>
> > Thanks,
> > Jianfeng
> >
> --
> Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration
2018-02-05 17:31 ` Paolo Bonzini
@ 2018-02-07 7:49 ` Tan, Jianfeng
2018-02-07 12:06 ` Igor Mammedov
0 siblings, 1 reply; 28+ messages in thread
From: Tan, Jianfeng @ 2018-02-07 7:49 UTC (permalink / raw)
To: Paolo Bonzini, Igor Mammedov
Cc: qemu-devel, Jason Wang, Maxime Coquelin, Michael S . Tsirkin
> -----Original Message-----
> From: Paolo Bonzini [mailto:pbonzini@redhat.com]
> Sent: Tuesday, February 6, 2018 1:32 AM
> To: Igor Mammedov
> Cc: Tan, Jianfeng; qemu-devel@nongnu.org; Jason Wang; Maxime Coquelin;
> Michael S . Tsirkin
> Subject: Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as
> migration
>
> On 05/02/2018 18:15, Igor Mammedov wrote:
> >>>
> >>> Then we would have both ram block named pc.ram:
> >>> Block Name PSize
> >>> pc.ram 4 KiB
> >>> /objects/pc.ram 2 MiB
> >>>
> >>> But I assume it's a corner case which not really happen.
> >> Yeah, you're right. :/ I hadn't thought of hotplug. It can happen indeed.
> >
> > perhaps we should fail object_add memory-backend-foo if it resulted
> > in creating ramblock with duplicate id
>
> Note that it would only be duplicated with Jianfeng's patch. So I'm
> worried that his patch is worse than what we have now, because it may
> create conflicts with system RAMBlock names are not necessarily
> predictable. Right now, -object creates RAMBlock names that are nicely
> constrained within /object/.
So we are trading off between the benefit it takes and the bad effect it brings.
I'm wondering if the above example is the only failed case this patch leads to, i.e, only there is a ram named "pc.ram" and "/object/pc.ram" in the src VM?
Please also consider the second option, that adding an alias name for RAMBlock; I'm not a big fan for that one, as it just pushes the problem to OpenStack/Libvirt.
Or any other suggestions?
Thanks,
Jianfeng
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration
2018-02-07 7:49 ` Tan, Jianfeng
@ 2018-02-07 12:06 ` Igor Mammedov
2018-02-08 1:20 ` Tan, Jianfeng
0 siblings, 1 reply; 28+ messages in thread
From: Igor Mammedov @ 2018-02-07 12:06 UTC (permalink / raw)
To: Tan, Jianfeng
Cc: Paolo Bonzini, qemu-devel, Jason Wang, Maxime Coquelin,
Michael S . Tsirkin
On Wed, 7 Feb 2018 07:49:58 +0000
"Tan, Jianfeng" <jianfeng.tan@intel.com> wrote:
> > -----Original Message-----
> > From: Paolo Bonzini [mailto:pbonzini@redhat.com]
> > Sent: Tuesday, February 6, 2018 1:32 AM
> > To: Igor Mammedov
> > Cc: Tan, Jianfeng; qemu-devel@nongnu.org; Jason Wang; Maxime Coquelin;
> > Michael S . Tsirkin
> > Subject: Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as
> > migration
> >
> > On 05/02/2018 18:15, Igor Mammedov wrote:
> > >>>
> > >>> Then we would have both ram block named pc.ram:
> > >>> Block Name PSize
> > >>> pc.ram 4 KiB
> > >>> /objects/pc.ram 2 MiB
> > >>>
> > >>> But I assume it's a corner case which not really happen.
> > >> Yeah, you're right. :/ I hadn't thought of hotplug. It can happen indeed.
> > >
> > > perhaps we should fail object_add memory-backend-foo if it resulted
> > > in creating ramblock with duplicate id
> >
> > Note that it would only be duplicated with Jianfeng's patch. So I'm
> > worried that his patch is worse than what we have now, because it may
> > create conflicts with system RAMBlock names are not necessarily
> > predictable. Right now, -object creates RAMBlock names that are nicely
> > constrained within /object/.
>
> So we are trading off between the benefit it takes and the bad effect it brings.
>
> I'm wondering if the above example is the only failed case this patch leads to, i.e, only there is a ram named "pc.ram" and "/object/pc.ram" in the src VM?
>
> Please also consider the second option, that adding an alias name for RAMBlock; I'm not a big fan for that one, as it just pushes the problem to OpenStack/Libvirt.
looking at provided CLI examples it's configuration issue on src and dst,
one shall not mix numa and non numa variants.
> Or any other suggestions?
Fix configuration, namely dst side of it (i.e. use the same -m only variant
without -numa as it's on src).
BTW, what are you trying to achieve adding -numa on dst?
> Thanks,
> Jianfeng
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration
2018-02-07 12:06 ` Igor Mammedov
@ 2018-02-08 1:20 ` Tan, Jianfeng
2018-02-08 9:51 ` Igor Mammedov
0 siblings, 1 reply; 28+ messages in thread
From: Tan, Jianfeng @ 2018-02-08 1:20 UTC (permalink / raw)
To: Igor Mammedov
Cc: Paolo Bonzini, qemu-devel, Jason Wang, Maxime Coquelin,
Michael S . Tsirkin
On 2/7/2018 8:06 PM, Igor Mammedov wrote:
> On Wed, 7 Feb 2018 07:49:58 +0000
> "Tan, Jianfeng" <jianfeng.tan@intel.com> wrote:
>
>>> -----Original Message-----
>>> From: Paolo Bonzini [mailto:pbonzini@redhat.com]
>>> Sent: Tuesday, February 6, 2018 1:32 AM
>>> To: Igor Mammedov
>>> Cc: Tan, Jianfeng; qemu-devel@nongnu.org; Jason Wang; Maxime Coquelin;
>>> Michael S . Tsirkin
>>> Subject: Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as
>>> migration
>>>
>>> On 05/02/2018 18:15, Igor Mammedov wrote:
>>>>>> Then we would have both ram block named pc.ram:
>>>>>> Block Name PSize
>>>>>> pc.ram 4 KiB
>>>>>> /objects/pc.ram 2 MiB
>>>>>>
>>>>>> But I assume it's a corner case which not really happen.
>>>>> Yeah, you're right. :/ I hadn't thought of hotplug. It can happen indeed.
>>>> perhaps we should fail object_add memory-backend-foo if it resulted
>>>> in creating ramblock with duplicate id
>>> Note that it would only be duplicated with Jianfeng's patch. So I'm
>>> worried that his patch is worse than what we have now, because it may
>>> create conflicts with system RAMBlock names are not necessarily
>>> predictable. Right now, -object creates RAMBlock names that are nicely
>>> constrained within /object/.
>> So we are trading off between the benefit it takes and the bad effect it brings.
>>
>> I'm wondering if the above example is the only failed case this patch leads to, i.e, only there is a ram named "pc.ram" and "/object/pc.ram" in the src VM?
>>
>> Please also consider the second option, that adding an alias name for RAMBlock; I'm not a big fan for that one, as it just pushes the problem to OpenStack/Libvirt.
> looking at provided CLI examples it's configuration issue on src and dst,
> one shall not mix numa and non numa variants.
Aha, that's another thing we also want to change. We now add numa at dst
node, only because without -numa, we cannot set up the file-baked memory
with share=on.
For example, "-m xG -mem-path xxx" can set up a file-baked memory, but
the file is not share-able.
>
>> Or any other suggestions?
> Fix configuration, namely dst side of it (i.e. use the same -m only variant
> without -numa as it's on src).
>
> BTW, what are you trying to achieve adding -numa on dst?
See above reply.
Thanks,
Jianfeng
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration
2018-02-08 1:20 ` Tan, Jianfeng
@ 2018-02-08 9:51 ` Igor Mammedov
2018-02-08 10:18 ` Tan, Jianfeng
0 siblings, 1 reply; 28+ messages in thread
From: Igor Mammedov @ 2018-02-08 9:51 UTC (permalink / raw)
To: Tan, Jianfeng
Cc: Paolo Bonzini, qemu-devel, Jason Wang, Maxime Coquelin,
Michael S . Tsirkin
On Thu, 8 Feb 2018 09:20:45 +0800
"Tan, Jianfeng" <jianfeng.tan@intel.com> wrote:
> On 2/7/2018 8:06 PM, Igor Mammedov wrote:
> > On Wed, 7 Feb 2018 07:49:58 +0000
> > "Tan, Jianfeng" <jianfeng.tan@intel.com> wrote:
> >
> >>> -----Original Message-----
> >>> From: Paolo Bonzini [mailto:pbonzini@redhat.com]
> >>> Sent: Tuesday, February 6, 2018 1:32 AM
> >>> To: Igor Mammedov
> >>> Cc: Tan, Jianfeng; qemu-devel@nongnu.org; Jason Wang; Maxime Coquelin;
> >>> Michael S . Tsirkin
> >>> Subject: Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as
> >>> migration
> >>>
> >>> On 05/02/2018 18:15, Igor Mammedov wrote:
> >>>>>> Then we would have both ram block named pc.ram:
> >>>>>> Block Name PSize
> >>>>>> pc.ram 4 KiB
> >>>>>> /objects/pc.ram 2 MiB
> >>>>>>
> >>>>>> But I assume it's a corner case which not really happen.
> >>>>> Yeah, you're right. :/ I hadn't thought of hotplug. It can happen indeed.
> >>>> perhaps we should fail object_add memory-backend-foo if it resulted
> >>>> in creating ramblock with duplicate id
> >>> Note that it would only be duplicated with Jianfeng's patch. So I'm
> >>> worried that his patch is worse than what we have now, because it may
> >>> create conflicts with system RAMBlock names are not necessarily
> >>> predictable. Right now, -object creates RAMBlock names that are nicely
> >>> constrained within /object/.
> >> So we are trading off between the benefit it takes and the bad effect it brings.
> >>
> >> I'm wondering if the above example is the only failed case this patch leads to, i.e, only there is a ram named "pc.ram" and "/object/pc.ram" in the src VM?
> >>
> >> Please also consider the second option, that adding an alias name for RAMBlock; I'm not a big fan for that one, as it just pushes the problem to OpenStack/Libvirt.
> > looking at provided CLI examples it's configuration issue on src and dst,
> > one shall not mix numa and non numa variants.
>
> Aha, that's another thing we also want to change. We now add numa at dst
> node, only because without -numa, we cannot set up the file-baked memory
> with share=on.
then shouldn't you start src with the same -numa to begin with,
changing such things on the fly is not supported.
General rule is that machine on dst has to be the same as on src.
(with backend not visible to guest it possible might be changed
but it's hard to tell if something would break due to that
or would continue working in future since doesn't go along with above rule)
> For example, "-m xG -mem-path xxx" can set up a file-baked memory, but
> the file is not share-able.
It could be solved by adding memdev option to machine,
which would allow to specify backend object. And then on
top make -mem-path alias new option to clean thing up.
But then again, You'd need to start both src and dst
with the same option.
> >
> >> Or any other suggestions?
> > Fix configuration, namely dst side of it (i.e. use the same -m only variant
> > without -numa as it's on src).
> >
> > BTW, what are you trying to achieve adding -numa on dst?
>
> See above reply.
>
> Thanks,
> Jianfeng
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration
2018-02-08 9:51 ` Igor Mammedov
@ 2018-02-08 10:18 ` Tan, Jianfeng
2018-02-08 11:30 ` Igor Mammedov
0 siblings, 1 reply; 28+ messages in thread
From: Tan, Jianfeng @ 2018-02-08 10:18 UTC (permalink / raw)
To: Igor Mammedov
Cc: Paolo Bonzini, qemu-devel, Jason Wang, Maxime Coquelin,
Michael S . Tsirkin
On 2/8/2018 5:51 PM, Igor Mammedov wrote:
> On Thu, 8 Feb 2018 09:20:45 +0800
> "Tan, Jianfeng" <jianfeng.tan@intel.com> wrote:
>
>> On 2/7/2018 8:06 PM, Igor Mammedov wrote:
>>> On Wed, 7 Feb 2018 07:49:58 +0000
>>> "Tan, Jianfeng" <jianfeng.tan@intel.com> wrote:
>>>
>>>>> -----Original Message-----
>>>>> From: Paolo Bonzini [mailto:pbonzini@redhat.com]
>>>>> Sent: Tuesday, February 6, 2018 1:32 AM
>>>>> To: Igor Mammedov
>>>>> Cc: Tan, Jianfeng; qemu-devel@nongnu.org; Jason Wang; Maxime Coquelin;
>>>>> Michael S . Tsirkin
>>>>> Subject: Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as
>>>>> migration
>>>>>
>>>>> On 05/02/2018 18:15, Igor Mammedov wrote:
>>>>>>>> Then we would have both ram block named pc.ram:
>>>>>>>> Block Name PSize
>>>>>>>> pc.ram 4 KiB
>>>>>>>> /objects/pc.ram 2 MiB
>>>>>>>>
>>>>>>>> But I assume it's a corner case which not really happen.
>>>>>>> Yeah, you're right. :/ I hadn't thought of hotplug. It can happen indeed.
>>>>>> perhaps we should fail object_add memory-backend-foo if it resulted
>>>>>> in creating ramblock with duplicate id
>>>>> Note that it would only be duplicated with Jianfeng's patch. So I'm
>>>>> worried that his patch is worse than what we have now, because it may
>>>>> create conflicts with system RAMBlock names are not necessarily
>>>>> predictable. Right now, -object creates RAMBlock names that are nicely
>>>>> constrained within /object/.
>>>> So we are trading off between the benefit it takes and the bad effect it brings.
>>>>
>>>> I'm wondering if the above example is the only failed case this patch leads to, i.e, only there is a ram named "pc.ram" and "/object/pc.ram" in the src VM?
>>>>
>>>> Please also consider the second option, that adding an alias name for RAMBlock; I'm not a big fan for that one, as it just pushes the problem to OpenStack/Libvirt.
>>> looking at provided CLI examples it's configuration issue on src and dst,
>>> one shall not mix numa and non numa variants.
>> Aha, that's another thing we also want to change. We now add numa at dst
>> node, only because without -numa, we cannot set up the file-baked memory
>> with share=on.
> then shouldn't you start src with the same -numa to begin with,
> changing such things on the fly is not supported.
Yes, you are describing the best practice. But we are originally trying
to migrate without any changes to QEMU.
> General rule is that machine on dst has to be the same as on src.
OK.
> (with backend not visible to guest it possible might be changed
> but it's hard to tell if something would break due to that
> or would continue working in future since doesn't go along with above rule)
>
>> For example, "-m xG -mem-path xxx" can set up a file-baked memory, but
>> the file is not share-able.
> It could be solved by adding memdev option to machine,
> which would allow to specify backend object. And then on
> top make -mem-path alias new option to clean thing up.
Do you mean?
src vm: -m xG
dst vm: -m xG,memdev=pc.ram -object
memory-backend-file,id=pc.ram,size=xG,mem-path=xxx,share=on ...
>
> But then again, You'd need to start both src and dst
> with the same option.
Yeah, got it :-)
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration
2018-02-08 10:18 ` Tan, Jianfeng
@ 2018-02-08 11:30 ` Igor Mammedov
2018-02-24 3:08 ` Tan, Jianfeng
2018-02-24 3:11 ` Tan, Jianfeng
0 siblings, 2 replies; 28+ messages in thread
From: Igor Mammedov @ 2018-02-08 11:30 UTC (permalink / raw)
To: Tan, Jianfeng
Cc: Paolo Bonzini, Jason Wang, Maxime Coquelin, qemu-devel,
Michael S . Tsirkin
On Thu, 8 Feb 2018 18:18:20 +0800
"Tan, Jianfeng" <jianfeng.tan@intel.com> wrote:
> On 2/8/2018 5:51 PM, Igor Mammedov wrote:
> > On Thu, 8 Feb 2018 09:20:45 +0800
> > "Tan, Jianfeng" <jianfeng.tan@intel.com> wrote:
> >
> >> On 2/7/2018 8:06 PM, Igor Mammedov wrote:
> >>> On Wed, 7 Feb 2018 07:49:58 +0000
> >>> "Tan, Jianfeng" <jianfeng.tan@intel.com> wrote:
> >>>
> >>>>> -----Original Message-----
> >>>>> From: Paolo Bonzini [mailto:pbonzini@redhat.com]
> >>>>> Sent: Tuesday, February 6, 2018 1:32 AM
> >>>>> To: Igor Mammedov
> >>>>> Cc: Tan, Jianfeng; qemu-devel@nongnu.org; Jason Wang; Maxime Coquelin;
> >>>>> Michael S . Tsirkin
> >>>>> Subject: Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as
> >>>>> migration
> >>>>>
> >>>>> On 05/02/2018 18:15, Igor Mammedov wrote:
> >>>>>>>> Then we would have both ram block named pc.ram:
> >>>>>>>> Block Name PSize
> >>>>>>>> pc.ram 4 KiB
> >>>>>>>> /objects/pc.ram 2 MiB
> >>>>>>>>
> >>>>>>>> But I assume it's a corner case which not really happen.
> >>>>>>> Yeah, you're right. :/ I hadn't thought of hotplug. It can happen indeed.
> >>>>>> perhaps we should fail object_add memory-backend-foo if it resulted
> >>>>>> in creating ramblock with duplicate id
> >>>>> Note that it would only be duplicated with Jianfeng's patch. So I'm
> >>>>> worried that his patch is worse than what we have now, because it may
> >>>>> create conflicts with system RAMBlock names are not necessarily
> >>>>> predictable. Right now, -object creates RAMBlock names that are nicely
> >>>>> constrained within /object/.
> >>>> So we are trading off between the benefit it takes and the bad effect it brings.
> >>>>
> >>>> I'm wondering if the above example is the only failed case this patch leads to, i.e, only there is a ram named "pc.ram" and "/object/pc.ram" in the src VM?
> >>>>
> >>>> Please also consider the second option, that adding an alias name for RAMBlock; I'm not a big fan for that one, as it just pushes the problem to OpenStack/Libvirt.
> >>> looking at provided CLI examples it's configuration issue on src and dst,
> >>> one shall not mix numa and non numa variants.
> >> Aha, that's another thing we also want to change. We now add numa at dst
> >> node, only because without -numa, we cannot set up the file-baked memory
> >> with share=on.
> > then shouldn't you start src with the same -numa to begin with,
> > changing such things on the fly is not supported.
>
> Yes, you are describing the best practice. But we are originally trying
> to migrate without any changes to QEMU.
>
> > General rule is that machine on dst has to be the same as on src.
>
> OK.
>
> > (with backend not visible to guest it possible might be changed
> > but it's hard to tell if something would break due to that
> > or would continue working in future since doesn't go along with above rule)
> >
> >> For example, "-m xG -mem-path xxx" can set up a file-baked memory, but
> >> the file is not share-able.
> > It could be solved by adding memdev option to machine,
> > which would allow to specify backend object. And then on
> > top make -mem-path alias new option to clean thing up.
>
> Do you mean?
>
> src vm: -m xG
> dst vm: -m xG,memdev=pc.ram -object
> memory-backend-file,id=pc.ram,size=xG,mem-path=xxx,share=on ...
Yep, I've meant something like it
src vm: -m xG,memdev=SHARED_RAM -object memory-backend-file,id=SHARED_RAM,size=xG,mem-path=xxx,share=on
dst vm: -m xG,memdev=SHARED_RAM -object memory-backend-file,id=SHARED_RAM,size=xG,mem-path=xxx,share=on
or it could be -machine FOO,inital_ram_memdev=...
maybe making -M optional in this case as size is specified by backend
PS:
it's not a good idea to use QEMU's internal id 'pc.ram'
for user specified objects as it might cause problems.
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration
2018-02-08 11:30 ` Igor Mammedov
@ 2018-02-24 3:08 ` Tan, Jianfeng
2018-02-24 3:11 ` Tan, Jianfeng
1 sibling, 0 replies; 28+ messages in thread
From: Tan, Jianfeng @ 2018-02-24 3:08 UTC (permalink / raw)
To: Igor Mammedov
Cc: Paolo Bonzini, Jason Wang, Maxime Coquelin, qemu-devel,
Michael S . Tsirkin
Hi Igor and all,
> -----Original Message-----
> From: Igor Mammedov [mailto:imammedo@redhat.com]
> Sent: Thursday, February 8, 2018 7:30 PM
> To: Tan, Jianfeng
> Cc: Paolo Bonzini; Jason Wang; Maxime Coquelin; qemu-devel@nongnu.org;
> Michael S . Tsirkin
> Subject: Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as
> migration
>
[...]
> > > It could be solved by adding memdev option to machine,
> > > which would allow to specify backend object. And then on
> > > top make -mem-path alias new option to clean thing up.
> >
> > Do you mean?
> >
> > src vm: -m xG
> > dst vm: -m xG,memdev=pc.ram -object memory-backend-file,id=pc.ram,size=xG,mem-path=xxx,share=on ...
> Yep, I've meant something like it
>
> src vm: -m xG,memdev=SHARED_RAM -object memory-backend-file,id=SHARED_RAM,size=xG,mem-path=xxx,share=on
> dst vm: -m xG,memdev=SHARED_RAM -object memory-backend-file,id=SHARED_RAM,size=xG,mem-path=xxx,share=on
After a second thought, I find adding a backend for nonnuma pc RAM is roundabout way.
And we actually have an existing way to add a file-backed RAM: commit c902760fb25f ("Add option to use file backed guest memory"). Basically, this commit adds two options, --mem-path and --mem-prealloc, without specify a backend explicitly.
So how about just adding a new option --mem-share to decide if that's a private memory or shared memory? That seems much straightforward way to me; after this change we can migrate like:
src vm: -m xG
dst vm: -m xG --mem-path xxx --mem-share
Thanks,
Jianfeng
>
> or it could be -machine FOO,inital_ram_memdev=...
> maybe making -M optional in this case as size is specified by backend
>
> PS:
> it's not a good idea to use QEMU's internal id 'pc.ram'
> for user specified objects as it might cause problems.
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration
2018-02-08 11:30 ` Igor Mammedov
2018-02-24 3:08 ` Tan, Jianfeng
@ 2018-02-24 3:11 ` Tan, Jianfeng
2018-02-26 12:55 ` Igor Mammedov
1 sibling, 1 reply; 28+ messages in thread
From: Tan, Jianfeng @ 2018-02-24 3:11 UTC (permalink / raw)
To: Igor Mammedov
Cc: Paolo Bonzini, Jason Wang, Maxime Coquelin, qemu-devel,
Michael S . Tsirkin
> -----Original Message-----
> From: Tan, Jianfeng
> Sent: Saturday, February 24, 2018 11:08 AM
> To: 'Igor Mammedov'
> Cc: Paolo Bonzini; Jason Wang; Maxime Coquelin; qemu-devel@nongnu.org;
> Michael S . Tsirkin
> Subject: RE: [Qemu-devel] [RFC] exec: eliminate ram naming issue as
> migration
>
> Hi Igor and all,
>
> > -----Original Message-----
> > From: Igor Mammedov [mailto:imammedo@redhat.com]
> > Sent: Thursday, February 8, 2018 7:30 PM
> > To: Tan, Jianfeng
> > Cc: Paolo Bonzini; Jason Wang; Maxime Coquelin; qemu-
> devel@nongnu.org;
> > Michael S . Tsirkin
> > Subject: Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as
> > migration
> >
> [...]
> > > > It could be solved by adding memdev option to machine,
> > > > which would allow to specify backend object. And then on
> > > > top make -mem-path alias new option to clean thing up.
> > >
> > > Do you mean?
> > >
> > > src vm: -m xG
> > > dst vm: -m xG,memdev=pc.ram -object memory-backend-
> file,id=pc.ram,size=xG,mem-path=xxx,share=on ...
> > Yep, I've meant something like it
> >
> > src vm: -m xG,memdev=SHARED_RAM -object memory-backend-
> file,id=SHARED_RAM,size=xG,mem-path=xxx,share=on
> > dst vm: -m xG,memdev=SHARED_RAM -object memory-backend-
> file,id=SHARED_RAM,size=xG,mem-path=xxx,share=on
>
> After a second thought, I find adding a backend for nonnuma pc RAM is
> roundabout way.
>
> And we actually have an existing way to add a file-backed RAM: commit
> c902760fb25f ("Add option to use file backed guest memory"). Basically, this
> commit adds two options, --mem-path and --mem-prealloc, without specify
> a backend explicitly.
>
> So how about just adding a new option --mem-share to decide if that's a
> private memory or shared memory? That seems much straightforward way
> to me; after this change we can migrate like:
>
> src vm: -m xG
> dst vm: -m xG --mem-path xxx --mem-share
>
Attach the patch FYI. Look forward to your thoughts.
diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
index 31612ca..5eaf367 100644
--- a/include/sysemu/sysemu.h
+++ b/include/sysemu/sysemu.h
@@ -127,6 +127,7 @@ extern bool enable_mlock;
extern uint8_t qemu_extra_params_fw[2];
extern QEMUClockType rtc_clock;
extern const char *mem_path;
+extern int mem_share;
extern int mem_prealloc;
#define MAX_NODES 128
diff --git a/numa.c b/numa.c
index 7b9c33a..322289f 100644
--- a/numa.c
+++ b/numa.c
@@ -456,7 +456,7 @@ static void allocate_system_memory_nonnuma(MemoryRegion *mr, Object *owner,
if (mem_path) {
#ifdef __linux__
Error *err = NULL;
- memory_region_init_ram_from_file(mr, owner, name, ram_size, false,
+ memory_region_init_ram_from_file(mr, owner, name, ram_size, mem_share,
mem_path, &err);
if (err) {
error_report_err(err);
diff --git a/qemu-options.hx b/qemu-options.hx
index 678181c..c968c53 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -389,6 +389,15 @@ STEXI
Allocate guest RAM from a temporarily created file in @var{path}.
ETEXI
+DEF("mem-share", 0, QEMU_OPTION_memshare,
+ "-mem-share make guest memory shareable (use with -mem-path)\n",
+ QEMU_ARCH_ALL)
+STEXI
+@item -mem-share
+@findex -mem-share
+Make file-backed guest RAM shareable when using -mem-path.
+ETEXI
+
DEF("mem-prealloc", 0, QEMU_OPTION_mem_prealloc,
"-mem-prealloc preallocate guest memory (use with -mem-path)\n",
QEMU_ARCH_ALL)
diff --git a/vl.c b/vl.c
index 444b750..0ff06c2 100644
--- a/vl.c
+++ b/vl.c
@@ -140,6 +140,7 @@ int display_opengl;
const char* keyboard_layout = NULL;
ram_addr_t ram_size;
const char *mem_path = NULL;
+int mem_share = 0;
int mem_prealloc = 0; /* force preallocation of physical target memory */
bool enable_mlock = false;
int nb_nics;
@@ -3395,6 +3396,9 @@ int main(int argc, char **argv, char **envp)
case QEMU_OPTION_mempath:
mem_path = optarg;
break;
+ case QEMU_OPTION_memshare:
+ mem_share = 1;
+ break;
case QEMU_OPTION_mem_prealloc:
mem_prealloc = 1;
break;
^ permalink raw reply related [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration
2018-02-24 3:11 ` Tan, Jianfeng
@ 2018-02-26 12:55 ` Igor Mammedov
2018-02-26 14:43 ` Paolo Bonzini
2018-02-27 4:36 ` Tan, Jianfeng
0 siblings, 2 replies; 28+ messages in thread
From: Igor Mammedov @ 2018-02-26 12:55 UTC (permalink / raw)
To: Tan, Jianfeng
Cc: Paolo Bonzini, Jason Wang, Maxime Coquelin, qemu-devel,
Michael S . Tsirkin
On Sat, 24 Feb 2018 03:11:30 +0000
"Tan, Jianfeng" <jianfeng.tan@intel.com> wrote:
> > -----Original Message-----
> > From: Tan, Jianfeng
> > Sent: Saturday, February 24, 2018 11:08 AM
> > To: 'Igor Mammedov'
> > Cc: Paolo Bonzini; Jason Wang; Maxime Coquelin; qemu-devel@nongnu.org;
> > Michael S . Tsirkin
> > Subject: RE: [Qemu-devel] [RFC] exec: eliminate ram naming issue as
> > migration
> >
> > Hi Igor and all,
> >
> > > -----Original Message-----
> > > From: Igor Mammedov [mailto:imammedo@redhat.com]
> > > Sent: Thursday, February 8, 2018 7:30 PM
> > > To: Tan, Jianfeng
> > > Cc: Paolo Bonzini; Jason Wang; Maxime Coquelin; qemu-
> > devel@nongnu.org;
> > > Michael S . Tsirkin
> > > Subject: Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as
> > > migration
> > >
> > [...]
> > > > > It could be solved by adding memdev option to machine,
> > > > > which would allow to specify backend object. And then on
> > > > > top make -mem-path alias new option to clean thing up.
> > > >
> > > > Do you mean?
> > > >
> > > > src vm: -m xG
> > > > dst vm: -m xG,memdev=pc.ram -object memory-backend-
> > file,id=pc.ram,size=xG,mem-path=xxx,share=on ...
> > > Yep, I've meant something like it
> > >
> > > src vm: -m xG,memdev=SHARED_RAM -object memory-backend-
> > file,id=SHARED_RAM,size=xG,mem-path=xxx,share=on
> > > dst vm: -m xG,memdev=SHARED_RAM -object memory-backend-
> > file,id=SHARED_RAM,size=xG,mem-path=xxx,share=on
> >
> > After a second thought, I find adding a backend for nonnuma pc RAM is
> > roundabout way.
> >
> > And we actually have an existing way to add a file-backed RAM: commit
> > c902760fb25f ("Add option to use file backed guest memory"). Basically, this
> > commit adds two options, --mem-path and --mem-prealloc, without specify
> > a backend explicitly.
> >
> > So how about just adding a new option --mem-share to decide if that's a
> > private memory or shared memory? That seems much straightforward way
Above options are legacy (which we can't remove for compat reasons),
their replacement is 'memory-backend-file' backend which has all of
the above including 'share' property.
So just add 'memdev' property to machine and reuse memory-backend-file
with it instead of duplicating functionality in the legacy code.
> > to me; after this change we can migrate like:
> >
> > src vm: -m xG
> > dst vm: -m xG --mem-path xxx --mem-share
Even though it might work for now, that's still invalid configuration
for migration, src side must include the same
"--mem-path xxx --mem-share"
options as dst.
It'd be better to fix management application to start QEMU
properly on SRC side.
> Attach the patch FYI. Look forward to your thoughts.
>
> diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
> index 31612ca..5eaf367 100644
> --- a/include/sysemu/sysemu.h
> +++ b/include/sysemu/sysemu.h
> @@ -127,6 +127,7 @@ extern bool enable_mlock;
> extern uint8_t qemu_extra_params_fw[2];
> extern QEMUClockType rtc_clock;
> extern const char *mem_path;
> +extern int mem_share;
> extern int mem_prealloc;
>
> #define MAX_NODES 128
> diff --git a/numa.c b/numa.c
> index 7b9c33a..322289f 100644
> --- a/numa.c
> +++ b/numa.c
> @@ -456,7 +456,7 @@ static void allocate_system_memory_nonnuma(MemoryRegion *mr, Object *owner,
> if (mem_path) {
> #ifdef __linux__
> Error *err = NULL;
> - memory_region_init_ram_from_file(mr, owner, name, ram_size, false,
> + memory_region_init_ram_from_file(mr, owner, name, ram_size, mem_share,
> mem_path, &err);
> if (err) {
> error_report_err(err);
> diff --git a/qemu-options.hx b/qemu-options.hx
> index 678181c..c968c53 100644
> --- a/qemu-options.hx
> +++ b/qemu-options.hx
> @@ -389,6 +389,15 @@ STEXI
> Allocate guest RAM from a temporarily created file in @var{path}.
> ETEXI
>
> +DEF("mem-share", 0, QEMU_OPTION_memshare,
> + "-mem-share make guest memory shareable (use with -mem-path)\n",
> + QEMU_ARCH_ALL)
> +STEXI
> +@item -mem-share
> +@findex -mem-share
> +Make file-backed guest RAM shareable when using -mem-path.
> +ETEXI
> +
> DEF("mem-prealloc", 0, QEMU_OPTION_mem_prealloc,
> "-mem-prealloc preallocate guest memory (use with -mem-path)\n",
> QEMU_ARCH_ALL)
> diff --git a/vl.c b/vl.c
> index 444b750..0ff06c2 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -140,6 +140,7 @@ int display_opengl;
> const char* keyboard_layout = NULL;
> ram_addr_t ram_size;
> const char *mem_path = NULL;
> +int mem_share = 0;
> int mem_prealloc = 0; /* force preallocation of physical target memory */
> bool enable_mlock = false;
> int nb_nics;
> @@ -3395,6 +3396,9 @@ int main(int argc, char **argv, char **envp)
> case QEMU_OPTION_mempath:
> mem_path = optarg;
> break;
> + case QEMU_OPTION_memshare:
> + mem_share = 1;
> + break;
> case QEMU_OPTION_mem_prealloc:
> mem_prealloc = 1;
> break;
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration
2018-02-26 12:55 ` Igor Mammedov
@ 2018-02-26 14:43 ` Paolo Bonzini
2018-02-27 4:55 ` Tan, Jianfeng
2018-02-27 4:36 ` Tan, Jianfeng
1 sibling, 1 reply; 28+ messages in thread
From: Paolo Bonzini @ 2018-02-26 14:43 UTC (permalink / raw)
To: Igor Mammedov, Tan, Jianfeng
Cc: Jason Wang, Maxime Coquelin, qemu-devel, Michael S . Tsirkin
On 26/02/2018 13:55, Igor Mammedov wrote:
>>> So how about just adding a new option --mem-share to decide if that's a
>>> private memory or shared memory? That seems much straightforward way
> Above options are legacy (which we can't remove for compat reasons),
> their replacement is 'memory-backend-file' backend which has all of
> the above including 'share' property.
More precisely, we have added "-object memory-backend-file" to avoid
proliferation of options related to memory. Besides unifying the cases
of 1 and >1 NUMA node, using -object also has the advantage of
supporting memory hotplug.
You wrote "I find adding a backend for nonnuma pc RAM is roundabout way"
but basically the command line says "this VM has only one NUMA node,
backed by this memory object" which is a precise description of what the
VM memory looks like.
> So just add 'memdev' property to machine and reuse memory-backend-file
> with it instead of duplicating functionality in the legacy code.
That would however also have a different RAMBlock id, effectively
producing the same output as "-numa node,memdev=...".
I think this should be solved at the libvirt level. Libvirt should
write in the migration XML cookie whether the VM is using -object or
-mem-path to declare its memory, and newly-started VMs should always use
-object. This won't fix the problem for VMs that are already running,
but it will fix it the next time they are started.
Paolo
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration
2018-02-26 12:55 ` Igor Mammedov
2018-02-26 14:43 ` Paolo Bonzini
@ 2018-02-27 4:36 ` Tan, Jianfeng
2018-02-28 15:40 ` Igor Mammedov
1 sibling, 1 reply; 28+ messages in thread
From: Tan, Jianfeng @ 2018-02-27 4:36 UTC (permalink / raw)
To: Igor Mammedov
Cc: Paolo Bonzini, Jason Wang, Maxime Coquelin, qemu-devel,
Michael S . Tsirkin
> -----Original Message-----
> From: Igor Mammedov [mailto:imammedo@redhat.com]
> Sent: Monday, February 26, 2018 8:56 PM
> To: Tan, Jianfeng
> Cc: Paolo Bonzini; Jason Wang; Maxime Coquelin; qemu-devel@nongnu.org;
> Michael S . Tsirkin
> Subject: Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as
> migration
>
> On Sat, 24 Feb 2018 03:11:30 +0000
> "Tan, Jianfeng" <jianfeng.tan@intel.com> wrote:
>
> > > -----Original Message-----
> > > From: Tan, Jianfeng
> > > Sent: Saturday, February 24, 2018 11:08 AM
> > > To: 'Igor Mammedov'
> > > Cc: Paolo Bonzini; Jason Wang; Maxime Coquelin; qemu-
> devel@nongnu.org;
> > > Michael S . Tsirkin
> > > Subject: RE: [Qemu-devel] [RFC] exec: eliminate ram naming issue as
> > > migration
> > >
> > > Hi Igor and all,
> > >
> > > > -----Original Message-----
> > > > From: Igor Mammedov [mailto:imammedo@redhat.com]
> > > > Sent: Thursday, February 8, 2018 7:30 PM
> > > > To: Tan, Jianfeng
> > > > Cc: Paolo Bonzini; Jason Wang; Maxime Coquelin; qemu-
> > > devel@nongnu.org;
> > > > Michael S . Tsirkin
> > > > Subject: Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as
> > > > migration
> > > >
> > > [...]
> > > > > > It could be solved by adding memdev option to machine,
> > > > > > which would allow to specify backend object. And then on
> > > > > > top make -mem-path alias new option to clean thing up.
> > > > >
> > > > > Do you mean?
> > > > >
> > > > > src vm: -m xG
> > > > > dst vm: -m xG,memdev=pc.ram -object memory-backend-
> > > file,id=pc.ram,size=xG,mem-path=xxx,share=on ...
> > > > Yep, I've meant something like it
> > > >
> > > > src vm: -m xG,memdev=SHARED_RAM -object memory-backend-
> > > file,id=SHARED_RAM,size=xG,mem-path=xxx,share=on
> > > > dst vm: -m xG,memdev=SHARED_RAM -object memory-backend-
> > > file,id=SHARED_RAM,size=xG,mem-path=xxx,share=on
> > >
> > > After a second thought, I find adding a backend for nonnuma pc RAM is
> > > roundabout way.
> > >
> > > And we actually have an existing way to add a file-backed RAM: commit
> > > c902760fb25f ("Add option to use file backed guest memory"). Basically,
> this
> > > commit adds two options, --mem-path and --mem-prealloc, without
> specify
> > > a backend explicitly.
> > >
> > > So how about just adding a new option --mem-share to decide if that's a
> > > private memory or shared memory? That seems much straightforward
> way
> Above options are legacy (which we can't remove for compat reasons),
> their replacement is 'memory-backend-file' backend which has all of
> the above including 'share' property.
OK, such options are legacy. I've no idea of that. Thanks! That makes sense.
>
> So just add 'memdev' property to machine and reuse memory-backend-file
> with it instead of duplicating functionality in the legacy code.
To "-m" or "-machine"?
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration
2018-02-26 14:43 ` Paolo Bonzini
@ 2018-02-27 4:55 ` Tan, Jianfeng
0 siblings, 0 replies; 28+ messages in thread
From: Tan, Jianfeng @ 2018-02-27 4:55 UTC (permalink / raw)
To: Paolo Bonzini, Igor Mammedov
Cc: Jason Wang, Maxime Coquelin, qemu-devel, Michael S . Tsirkin
> -----Original Message-----
> From: Paolo Bonzini [mailto:pbonzini@redhat.com]
> Sent: Monday, February 26, 2018 10:43 PM
> To: Igor Mammedov; Tan, Jianfeng
> Cc: Jason Wang; Maxime Coquelin; qemu-devel@nongnu.org; Michael S .
> Tsirkin
> Subject: Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as
> migration
>
> On 26/02/2018 13:55, Igor Mammedov wrote:
> >>> So how about just adding a new option --mem-share to decide if that's a
> >>> private memory or shared memory? That seems much straightforward
> way
> > Above options are legacy (which we can't remove for compat reasons),
> > their replacement is 'memory-backend-file' backend which has all of
> > the above including 'share' property.
>
> More precisely, we have added "-object memory-backend-file" to avoid
> proliferation of options related to memory. Besides unifying the cases
> of 1 and >1 NUMA node, using -object also has the advantage of
> supporting memory hotplug.
>
> You wrote "I find adding a backend for nonnuma pc RAM is roundabout way"
> but basically the command line says "this VM has only one NUMA node,
> backed by this memory object" which is a precise description of what the
> VM memory looks like.
>
> > So just add 'memdev' property to machine and reuse memory-backend-file
> > with it instead of duplicating functionality in the legacy code.
>
> That would however also have a different RAMBlock id, effectively
> producing the same output as "-numa node,memdev=...".
Is it possible that we force that RAMBlock id to be "pc.ram"?
>
> I think this should be solved at the libvirt level. Libvirt should
> write in the migration XML cookie whether the VM is using -object or
> -mem-path to declare its memory, and newly-started VMs should always use
> -object. This won't fix the problem for VMs that are already running,
> but it will fix it the next time they are started.
In this case, we return to the start point :-)
Thanks,
Jianfeng
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration
2018-02-27 4:36 ` Tan, Jianfeng
@ 2018-02-28 15:40 ` Igor Mammedov
0 siblings, 0 replies; 28+ messages in thread
From: Igor Mammedov @ 2018-02-28 15:40 UTC (permalink / raw)
To: Tan, Jianfeng
Cc: Paolo Bonzini, Jason Wang, Michael S . Tsirkin, Maxime Coquelin,
qemu-devel
On Tue, 27 Feb 2018 04:36:45 +0000
"Tan, Jianfeng" <jianfeng.tan@intel.com> wrote:
> > -----Original Message-----
> > From: Igor Mammedov [mailto:imammedo@redhat.com]
> > Sent: Monday, February 26, 2018 8:56 PM
> > To: Tan, Jianfeng
> > Cc: Paolo Bonzini; Jason Wang; Maxime Coquelin; qemu-devel@nongnu.org;
> > Michael S . Tsirkin
> > Subject: Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as
> > migration
> >
> > On Sat, 24 Feb 2018 03:11:30 +0000
> > "Tan, Jianfeng" <jianfeng.tan@intel.com> wrote:
> >
> > > > -----Original Message-----
> > > > From: Tan, Jianfeng
> > > > Sent: Saturday, February 24, 2018 11:08 AM
> > > > To: 'Igor Mammedov'
> > > > Cc: Paolo Bonzini; Jason Wang; Maxime Coquelin; qemu-
> > devel@nongnu.org;
> > > > Michael S . Tsirkin
> > > > Subject: RE: [Qemu-devel] [RFC] exec: eliminate ram naming issue as
> > > > migration
> > > >
> > > > Hi Igor and all,
> > > >
> > > > > -----Original Message-----
> > > > > From: Igor Mammedov [mailto:imammedo@redhat.com]
> > > > > Sent: Thursday, February 8, 2018 7:30 PM
> > > > > To: Tan, Jianfeng
> > > > > Cc: Paolo Bonzini; Jason Wang; Maxime Coquelin; qemu-
> > > > devel@nongnu.org;
> > > > > Michael S . Tsirkin
> > > > > Subject: Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as
> > > > > migration
> > > > >
> > > > [...]
> > > > > > > It could be solved by adding memdev option to machine,
> > > > > > > which would allow to specify backend object. And then on
> > > > > > > top make -mem-path alias new option to clean thing up.
> > > > > >
> > > > > > Do you mean?
> > > > > >
> > > > > > src vm: -m xG
> > > > > > dst vm: -m xG,memdev=pc.ram -object memory-backend-
> > > > file,id=pc.ram,size=xG,mem-path=xxx,share=on ...
> > > > > Yep, I've meant something like it
> > > > >
> > > > > src vm: -m xG,memdev=SHARED_RAM -object memory-backend-
> > > > file,id=SHARED_RAM,size=xG,mem-path=xxx,share=on
> > > > > dst vm: -m xG,memdev=SHARED_RAM -object memory-backend-
> > > > file,id=SHARED_RAM,size=xG,mem-path=xxx,share=on
> > > >
> > > > After a second thought, I find adding a backend for nonnuma pc RAM is
> > > > roundabout way.
> > > >
> > > > And we actually have an existing way to add a file-backed RAM: commit
> > > > c902760fb25f ("Add option to use file backed guest memory"). Basically,
> > this
> > > > commit adds two options, --mem-path and --mem-prealloc, without
> > specify
> > > > a backend explicitly.
> > > >
> > > > So how about just adding a new option --mem-share to decide if that's a
> > > > private memory or shared memory? That seems much straightforward
> > way
> > Above options are legacy (which we can't remove for compat reasons),
> > their replacement is 'memory-backend-file' backend which has all of
> > the above including 'share' property.
>
> OK, such options are legacy. I've no idea of that. Thanks! That makes sense.
>
> >
> > So just add 'memdev' property to machine and reuse memory-backend-file
> > with it instead of duplicating functionality in the legacy code.
>
> To "-m" or "-machine"?
"-machine", I plan to convert -m to machine options as well (it's somewhere on my TODO list)
but as Paolo pointed out that will help only to avoid using -numa
and won't help with your case, which should be solved at upper layer
(i.e. starting QEMU on src with shared memory from the begging).
^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2018-02-28 15:40 UTC | newest]
Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-02-05 14:58 [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration Jianfeng Tan
2018-02-05 15:45 ` no-reply
2018-02-05 15:53 ` Paolo Bonzini
2018-02-05 16:12 ` Tan, Jianfeng
2018-02-05 16:19 ` Paolo Bonzini
2018-02-05 16:44 ` Tan, Jianfeng
2018-02-05 16:53 ` Paolo Bonzini
2018-02-05 17:15 ` Igor Mammedov
2018-02-05 17:31 ` Paolo Bonzini
2018-02-07 7:49 ` Tan, Jianfeng
2018-02-07 12:06 ` Igor Mammedov
2018-02-08 1:20 ` Tan, Jianfeng
2018-02-08 9:51 ` Igor Mammedov
2018-02-08 10:18 ` Tan, Jianfeng
2018-02-08 11:30 ` Igor Mammedov
2018-02-24 3:08 ` Tan, Jianfeng
2018-02-24 3:11 ` Tan, Jianfeng
2018-02-26 12:55 ` Igor Mammedov
2018-02-26 14:43 ` Paolo Bonzini
2018-02-27 4:55 ` Tan, Jianfeng
2018-02-27 4:36 ` Tan, Jianfeng
2018-02-28 15:40 ` Igor Mammedov
2018-02-05 18:44 ` Dr. David Alan Gilbert
2018-02-05 16:12 ` no-reply
2018-02-05 16:29 ` Igor Mammedov
2018-02-05 16:51 ` Tan, Jianfeng
2018-02-05 18:36 ` Dr. David Alan Gilbert
2018-02-06 15:24 ` Igor Mammedov
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.