diff mbox

hostmem-file: add a property 'notrunc' to avoid data corruption

Message ID 20161020061301.31372-1-haozhong.zhang@intel.com (mailing list archive)
State New, archived
Headers show

Commit Message

Haozhong Zhang Oct. 20, 2016, 6:13 a.m. UTC 
If a file is used as the backend of memory-backend-file and its size is
not identical to the property 'size', the file will be truncated. For a
file used as the backend of vNVDIMM, its data is expected to be
persistent and the truncation may corrupt the existing data.

A property 'notrunc' is added to memory-backend-file to allow users to
control the truncation. If 'notrunc' is on, QEMU will not truncate the
backend file and require the property 'size' is not larger than the file
size. If 'notrunc' is off, QEMU will behave as before.

Signed-off-by: Haozhong Zhang <haozhong.zhang@intel.com>
---
 backends/hostmem-file.c | 25 ++++++++++++++++-
 exec.c                  | 74 +++++++++++++++++++++++++++++++++++++++++++++++--
 include/exec/memory.h   |  3 ++
 include/exec/ram_addr.h |  3 +-
 memory.c                |  4 ++-
 numa.c                  |  2 +-
 6 files changed, 105 insertions(+), 6 deletions(-)

Comments

no-reply@patchew.org Oct. 20, 2016, 6:35 a.m. UTC | #1 
Hi,

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

Subject: [Qemu-devel] [PATCH] hostmem-file: add a property 'notrunc' to avoid data corruption
Type: series
Message-id: 20161020061301.31372-1-haozhong.zhang@intel.com

=== TEST SCRIPT BEGIN ===
#!/bin/bash
set -e
git submodule update --init dtc
# Let docker tests dump environment info
export SHOW_ENV=1
export J=16
make docker-test-quick@centos6
make docker-test-mingw@fedora
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
9007bed hostmem-file: add a property 'notrunc' to avoid data corruption

=== OUTPUT BEGIN ===
Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc'
Cloning into 'dtc'...
Submodule path 'dtc': checked out '65cc4d2748a2c2e6f27f1cf39e07a5dbabd80ebf'
  BUILD   centos6
make[1]: Entering directory '/var/tmp/patchew-tester-tmp-7squmlt9/src'
  ARCHIVE qemu.tgz
  ARCHIVE dtc.tgz
  COPY    RUNNER
    RUN test-quick in qemu:centos6 
Packages installed:
SDL-devel-1.2.14-7.el6_7.1.x86_64
ccache-3.1.6-2.el6.x86_64
epel-release-6-8.noarch
gcc-4.4.7-17.el6.x86_64
git-1.7.1-4.el6_7.1.x86_64
glib2-devel-2.28.8-5.el6.x86_64
libfdt-devel-1.4.0-1.el6.x86_64
make-3.81-23.el6.x86_64
package g++ is not installed
pixman-devel-0.32.8-1.el6.x86_64
tar-1.23-15.el6_8.x86_64
zlib-devel-1.2.3-29.el6.x86_64

Environment variables:
PACKAGES=libfdt-devel ccache     tar git make gcc g++     zlib-devel glib2-devel SDL-devel pixman-devel     epel-release
HOSTNAME=51da138370e3
TERM=xterm
MAKEFLAGS= -j16
HISTSIZE=1000
J=16
USER=root
CCACHE_DIR=/var/tmp/ccache
EXTRA_CONFIGURE_OPTS=
V=
SHOW_ENV=1
MAIL=/var/spool/mail/root
PATH=/usr/lib/ccache:/usr/lib64/ccache:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PWD=/
LANG=en_US.UTF-8
TARGET_LIST=
HISTCONTROL=ignoredups
SHLVL=1
HOME=/root
TEST_DIR=/tmp/qemu-test
LOGNAME=root
LESSOPEN=||/usr/bin/lesspipe.sh %s
FEATURES= dtc
DEBUG=
G_BROKEN_FILENAMES=1
CCACHE_HASHDIR=
_=/usr/bin/env

Configure options:
--enable-werror --target-list=x86_64-softmmu,aarch64-softmmu --prefix=/var/tmp/qemu-build/install
No C++ compiler available; disabling C++ specific optional code
Install prefix    /var/tmp/qemu-build/install
BIOS directory    /var/tmp/qemu-build/install/share/qemu
binary directory  /var/tmp/qemu-build/install/bin
library directory /var/tmp/qemu-build/install/lib
module directory  /var/tmp/qemu-build/install/lib/qemu
libexec directory /var/tmp/qemu-build/install/libexec
include directory /var/tmp/qemu-build/install/include
config directory  /var/tmp/qemu-build/install/etc
local state directory   /var/tmp/qemu-build/install/var
Manual directory  /var/tmp/qemu-build/install/share/man
ELF interp prefix /usr/gnemul/qemu-%M
Source path       /tmp/qemu-test/src
C compiler        cc
Host C compiler   cc
C++ compiler      
Objective-C compiler cc
ARFLAGS           rv
CFLAGS            -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g 
QEMU_CFLAGS       -I/usr/include/pixman-1    -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include   -fPIE -DPIE -m64 -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 -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all
LDFLAGS           -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -pie -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
tcg debug enabled no
gprof enabled     no
sparse enabled    no
strip binaries    yes
profiler          no
static build      no
pixman            system
SDL support       yes (1.2.14)
GTK support       no 
GTK GL support    no
VTE support       no 
TLS priority      NORMAL
GNUTLS support    no
GNUTLS rnd        no
libgcrypt         no
libgcrypt kdf     no
nettle            no 
nettle kdf        no
libtasn1          no
curses support    no
virgl support     no
curl support      no
mingw32 support   no
Audio drivers     oss
Block whitelist (rw) 
Block whitelist (ro) 
VirtFS support    no
VNC support       yes
VNC SASL support  no
VNC JPEG support  no
VNC PNG support   no
xen support       no
brlapi support    no
bluez  support    no
Documentation     no
PIE               yes
vde support       no
netmap support    no
Linux AIO support no
ATTR/XATTR support yes
Install blobs     yes
KVM support       yes
RDMA support      no
TCG interpreter   no
fdt support       yes
preadv support    yes
fdatasync         yes
madvise           yes
posix_madvise     yes
libcap-ng support no
vhost-net support yes
vhost-scsi support yes
vhost-vsock support yes
Trace backends    log
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 no
QGA MSI support   no
seccomp support   no
coroutine backend ucontext
coroutine pool    yes
debug stack usage no
GlusterFS support no
Archipelago support no
gcov              gcov
gcov enabled      no
TPM support       yes
libssh2 support   no
TPM passthrough   yes
QOM debugging     yes
lzo support       no
snappy support    no
bzip2 support     no
NUMA host support no
tcmalloc support  no
jemalloc support  no
avx2 optimization no
replication support yes
  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-types.h
  GEN     qapi-visit.h
  GEN     qapi-event.h
  GEN     qmp-introspect.h
  GEN     x86_64-softmmu/config-devices.mak
  GEN     module_block.h
  GEN     aarch64-softmmu/config-devices.mak
  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/generated-tracers.h
  GEN     trace/generated-tcg-tracers.h
  GEN     trace/generated-helpers-wrappers.h
  GEN     trace/generated-helpers.h
  GEN     config-all-devices.mak
  CC      tests/qemu-iotests/socket_scm_helper.o
  GEN     qga/qapi-generated/qga-qapi-types.h
  GEN     qga/qapi-generated/qga-qapi-visit.h
  GEN     qga/qapi-generated/qga-qmp-commands.h
  GEN     qga/qapi-generated/qga-qapi-types.c
  GEN     qga/qapi-generated/qga-qapi-visit.c
  GEN     qga/qapi-generated/qga-qmp-marshal.c
  GEN     qmp-introspect.c
  GEN     qapi-types.c
  GEN     qapi-visit.c
  GEN     qapi-event.c
  CC      qapi/qapi-visit-core.o
  CC      qapi/qapi-dealloc-visitor.o
  CC      qapi/qmp-input-visitor.o
  CC      qapi/qmp-output-visitor.o
  CC      qapi/qmp-registry.o
  CC      qapi/qmp-dispatch.o
  CC      qapi/string-input-visitor.o
  CC      qapi/string-output-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/qint.o
  CC      qobject/qstring.o
  CC      qobject/qdict.o
  CC      qobject/qlist.o
  CC      qobject/qfloat.o
  CC      qobject/qbool.o
  CC      qobject/qjson.o
  CC      qobject/qobject.o
  CC      qobject/json-lexer.o
  CC      qobject/json-streamer.o
  CC      qobject/json-parser.o
  GEN     trace/generated-tracers.c
  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/compatfd.o
  CC      util/event_notifier-posix.o
  CC      util/mmap-alloc.o
  CC      util/oslib-posix.o
  CC      util/qemu-openpty.o
  CC      util/qemu-thread-posix.o
  CC      util/envlist.o
  CC      util/memfd.o
  CC      util/path.o
  CC      util/module.o
  CC      util/bitmap.o
  CC      util/bitops.o
  CC      util/hbitmap.o
  CC      util/fifo8.o
  CC      util/acl.o
  CC      util/error.o
  CC      util/qemu-error.o
  CC      util/qemu-config.o
  CC      util/id.o
  CC      util/iov.o
  CC      util/qemu-sockets.o
  CC      util/uri.o
  CC      util/notify.o
  CC      util/qemu-option.o
  CC      util/crc32c.o
  CC      util/qemu-progress.o
  CC      util/hexdump.o
  CC      util/uuid.o
  CC      util/throttle.o
  CC      util/getauxval.o
  CC      util/readline.o
  CC      util/rcu.o
  CC      util/rfifolock.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-ucontext.o
  CC      util/timed-average.o
  CC      util/buffer.o
  CC      util/base64.o
  CC      util/log.o
  CC      util/qdist.o
  CC      util/qht.o
  CC      util/range.o
  CC      stubs/arch-query-cpu-def.o
  CC      crypto/pbkdf-stub.o
  CC      stubs/arch-query-cpu-model-expansion.o
  CC      stubs/arch-query-cpu-model-comparison.o
  CC      stubs/bdrv-next-monitor-owned.o
  CC      stubs/arch-query-cpu-model-baseline.o
  CC      stubs/blk-commit-all.o
  CC      stubs/clock-warp.o
  CC      stubs/blockdev-close-all-bdrv-states.o
  CC      stubs/cpu-get-clock.o
  CC      stubs/cpu-get-icount.o
  CC      stubs/dump.o
  CC      stubs/fdset-add-fd.o
  CC      stubs/fdset-find-fd.o
  CC      stubs/fdset-get-fd.o
  CC      stubs/fdset-remove-fd.o
  CC      stubs/gdbstub.o
  CC      stubs/get-fd.o
  CC      stubs/get-next-serial.o
  CC      stubs/get-vm-name.o
  CC      stubs/iothread-lock.o
  CC      stubs/is-daemonized.o
  CC      stubs/machine-init-done.o
  CC      stubs/migr-blocker.o
  CC      stubs/mon-is-qmp.o
  CC      stubs/mon-printf.o
  CC      stubs/monitor-init.o
  CC      stubs/notify-event.o
  CC      stubs/qtest.o
  CC      stubs/replay.o
  CC      stubs/replay-user.o
  CC      stubs/reset.o
  CC      stubs/runstate-check.o
  CC      stubs/set-fd-handler.o
  CC      stubs/slirp.o
  CC      stubs/sysbus.o
  CC      stubs/trace-control.o
  CC      stubs/uuid.o
  CC      stubs/vm-stop.o
  CC      stubs/vmstate.o
  CC      stubs/cpus.o
  CC      stubs/kvm.o
  CC      stubs/qmp_pc_dimm_device_list.o
  CC      stubs/target-monitor-defs.o
  CC      stubs/vhost.o
  CC      stubs/target-get-monitor-def.o
  CC      stubs/iohandler.o
  CC      stubs/smbios_type_38.o
  CC      stubs/ipmi.o
  CC      contrib/ivshmem-client/ivshmem-client.o
  CC      stubs/pc_madt_cpu_entry.o
  CC      contrib/ivshmem-client/main.o
  CC      contrib/ivshmem-server/ivshmem-server.o
  CC      contrib/ivshmem-server/main.o
  CC      qemu-nbd.o
  CC      async.o
  CC      thread-pool.o
  CC      block.o
  CC      blockjob.o
  CC      main-loop.o
  CC      iohandler.o
  CC      qemu-timer.o
  CC      aio-posix.o
  CC      qemu-io-cmds.o
  CC      replication.o
  CC      block/raw_bsd.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/qed.o
  CC      block/qed-gencb.o
  CC      block/qed-table.o
  CC      block/qed-l2-cache.o
  CC      block/qed-cluster.o
  CC      block/qed-check.o
  CC      block/vhdx.o
  CC      block/quorum.o
  CC      block/parallels.o
  CC      block/vhdx-endian.o
  CC      block/vhdx-log.o
  CC      block/blkdebug.o
  CC      block/blkverify.o
  CC      block/blkreplay.o
  CC      block/qapi.o
  CC      block/raw-posix.o
  CC      block/block-backend.o
  CC      block/snapshot.o
  CC      block/null.o
  CC      block/mirror.o
  CC      block/io.o
  CC      block/commit.o
  CC      block/throttle-groups.o
  CC      block/nbd.o
  CC      block/nbd-client.o
  CC      block/sheepdog.o
  CC      block/dirty-bitmap.o
  CC      block/accounting.o
  CC      block/write-threshold.o
  CC      block/backup.o
  CC      block/replication.o
  CC      nbd/server.o
  CC      block/crypto.o
  CC      nbd/client.o
  CC      nbd/common.o
  CC      crypto/init.o
  CC      crypto/hash.o
  CC      crypto/desrfb.o
  CC      crypto/hash-glib.o
  CC      crypto/aes.o
  CC      crypto/cipher.o
  CC      crypto/tlscreds.o
  CC      crypto/tlscredsanon.o
  CC      crypto/tlscredsx509.o
  CC      crypto/tlssession.o
  CC      crypto/pbkdf.o
  CC      crypto/secret.o
  CC      crypto/random-platform.o
  CC      crypto/ivgen-plain.o
  CC      crypto/ivgen.o
  CC      crypto/ivgen-essiv.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-command.o
  CC      io/channel-file.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/task.o
  CC      qom/object.o
  CC      qom/container.o
  CC      qom/qom-qobject.o
  CC      qom/object_interfaces.o
  GEN     qemu-img-cmds.h
  CC      qemu-bridge-helper.o
  CC      qemu-io.o
  CC      blockdev-nbd.o
  CC      blockdev.o
  CC      qdev-monitor.o
  CC      device-hotplug.o
  CC      iothread.o
  CC      qemu-char.o
  CC      os-posix.o
  CC      page_cache.o
  CC      accel.o
  CC      bt-host.o
  CC      bt-vhci.o
  CC      dma-helpers.o
  CC      vl.o
  CC      tpm.o
  CC      device_tree.o
  GEN     qmp-marshal.c
  CC      qmp.o
  CC      hmp.o
  CC      tcg-runtime.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/ossaudio.o
  CC      audio/wavcapture.o
  CC      backends/rng.o
  CC      backends/rng-egd.o
  CC      backends/rng-random.o
  CC      backends/msmouse.o
  CC      backends/testdev.o
  CC      backends/tpm.o
  CC      backends/hostmem.o
  CC      backends/hostmem-ram.o
  CC      backends/hostmem-file.o
  CC      block/stream.o
  CC      disas/arm.o
  CC      disas/i386.o
  CC      fsdev/qemu-fsdev-dummy.o
  CC      fsdev/qemu-fsdev-opts.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/memory_hotplug_acpi_table.o
  CC      hw/acpi/cpu.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/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/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_cfi02.o
  CC      hw/block/pflash_cfi01.o
  CC      hw/block/onenand.o
  CC      hw/block/ecc.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/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/fw-path-provider.o
  CC      hw/core/irq.o
  CC      hw/core/hotplug.o
  CC      hw/core/ptimer.o
  CC      hw/core/sysbus.o
  CC      hw/core/machine.o
  CC      hw/core/null-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/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/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/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/vmmouse.o
  CC      hw/input/virtio-input.o
  CC      hw/input/virtio-input-hid.o
  CC      hw/input/virtio-input-host.o
  CC      hw/intc/i8259_common.o
  CC      hw/intc/i8259.o
  CC      hw/intc/pl190.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/isa-bus.o
  CC      hw/isa/apm.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/debugexit.o
  CC      hw/misc/sga.o
  CC      hw/misc/pc-testdev.o
  CC      hw/misc/pci-testdev.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/allwinner_emac.o
  CC      hw/net/imx_fec.o
  CC      hw/net/cadence_gem.o
  CC      hw/net/stellaris_enet.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/fw_cfg.o
  CC      hw/pci-bridge/pci_bridge_dev.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/pci_bridge.o
  CC      hw/pci/msix.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_aer.o
  CC      hw/pci/pcie_port.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
/tmp/qemu-test/src/hw/nvram/fw_cfg.c: In function ‘fw_cfg_dma_transfer’:
/tmp/qemu-test/src/hw/nvram/fw_cfg.c:330: warning: ‘read’ may be used uninitialized in this function
  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/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/timer/arm_timer.o
  CC      hw/timer/arm_mptimer.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/tpm/tpm_tis.o
  CC      hw/tpm/tpm_passthrough.o
  CC      hw/tpm/tpm_util.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.o
  CC      hw/usb/hcd-ehci-pci.o
  CC      hw/usb/hcd-ehci-sysbus.o
  CC      hw/usb/hcd-xhci.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/dev-mtp.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/watchdog/watchdog.o
  CC      hw/watchdog/wdt_i6300esb.o
  CC      hw/watchdog/wdt_ib700.o
  CC      migration/migration.o
  CC      migration/socket.o
  CC      migration/fd.o
  CC      migration/exec.o
  CC      migration/tls.o
  CC      migration/vmstate.o
  CC      migration/qemu-file.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/queue.o
  CC      net/net.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/l2tpv3.o
  CC      net/tap.o
  CC      net/vhost-user.o
  CC      net/tap-linux.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      qom/cpu.o
  CC      replay/replay.o
  CC      replay/replay-internal.o
  CC      replay/replay-events.o
/tmp/qemu-test/src/replay/replay-internal.c: In function ‘replay_put_array’:
/tmp/qemu-test/src/replay/replay-internal.c:65: warning: ignoring return value of ‘fwrite’, declared with attribute warn_unused_result
  CC      replay/replay-time.o
  CC      replay/replay-char.o
  CC      replay/replay-input.o
  CC      replay/replay-snapshot.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/slirp.o
  CC      slirp/dhcpv6.o
  CC      slirp/mbuf.o
  CC      slirp/misc.o
  CC      slirp/sbuf.o
  CC      slirp/socket.o
  CC      slirp/tcp_input.o
  CC      slirp/tcp_output.o
  CC      slirp/tcp_subr.o
  CC      slirp/tcp_timer.o
  CC      slirp/udp.o
  CC      slirp/udp6.o
/tmp/qemu-test/src/slirp/tcp_input.c: In function ‘tcp_input’:
/tmp/qemu-test/src/slirp/tcp_input.c:219: warning: ‘save_ip.ip_p’ may be used uninitialized in this function
/tmp/qemu-test/src/slirp/tcp_input.c:219: warning: ‘save_ip.ip_len’ may be used uninitialized in this function
/tmp/qemu-test/src/slirp/tcp_input.c:219: warning: ‘save_ip.ip_tos’ may be used uninitialized in this function
/tmp/qemu-test/src/slirp/tcp_input.c:219: warning: ‘save_ip.ip_id’ may be used uninitialized in this function
/tmp/qemu-test/src/slirp/tcp_input.c:219: warning: ‘save_ip.ip_off’ may be used uninitialized in this function
/tmp/qemu-test/src/slirp/tcp_input.c:219: warning: ‘save_ip.ip_ttl’ may be used uninitialized in this function
/tmp/qemu-test/src/slirp/tcp_input.c:219: warning: ‘save_ip.ip_sum’ may be used uninitialized in this function
/tmp/qemu-test/src/slirp/tcp_input.c:219: warning: ‘save_ip.ip_src.s_addr’ may be used uninitialized in this function
/tmp/qemu-test/src/slirp/tcp_input.c:219: warning: ‘save_ip.ip_dst.s_addr’ may be used uninitialized in this function
/tmp/qemu-test/src/slirp/tcp_input.c:220: warning: ‘save_ip6.ip_nh’ may be used uninitialized in this function
  CC      slirp/bootp.o
  CC      slirp/tftp.o
  CC      slirp/arp_table.o
  CC      slirp/ndp_table.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-legacy.o
  CC      ui/input-keymap.o
  CC      ui/input-linux.o
  CC      ui/sdl.o
  CC      ui/sdl_zoom.o
  CC      ui/x_keymap.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
  LINK    tests/qemu-iotests/socket_scm_helper
  CC      qga/commands.o
  CC      qga/guest-agent-command-state.o
  CC      qga/main.o
  CC      qga/commands-posix.o
  CC      qga/channel-posix.o
  CC      qga/qapi-generated/qga-qapi-visit.o
  CC      qga/qapi-generated/qga-qapi-types.o
  CC      qga/qapi-generated/qga-qmp-marshal.o
  CC      qmp-introspect.o
  CC      qapi-types.o
  CC      qapi-visit.o
  CC      qapi-event.o
  AR      libqemustub.a
  AS      optionrom/multiboot.o
  AS      optionrom/linuxboot.o
  CC      optionrom/linuxboot_dma.o
  CC      qemu-img.o
cc: unrecognized option '-no-integrated-as'
cc: unrecognized option '-no-integrated-as'
  AS      optionrom/kvmvapic.o
  CC      qmp-marshal.o
  BUILD   optionrom/multiboot.img
  BUILD   optionrom/linuxboot.img
  CC      trace/generated-tracers.o
  BUILD   optionrom/linuxboot_dma.img
  BUILD   optionrom/multiboot.raw
  BUILD   optionrom/linuxboot.raw
  BUILD   optionrom/kvmvapic.img
  BUILD   optionrom/linuxboot_dma.raw
  BUILD   optionrom/kvmvapic.raw
  SIGN    optionrom/linuxboot.bin
  SIGN    optionrom/kvmvapic.bin
  SIGN    optionrom/linuxboot_dma.bin
  AR      libqemuutil.a
  SIGN    optionrom/multiboot.bin
  LINK    qemu-ga
  LINK    ivshmem-client
  LINK    ivshmem-server
  LINK    qemu-nbd
  LINK    qemu-img
  LINK    qemu-io
  LINK    qemu-bridge-helper
  GEN     x86_64-softmmu/hmp-commands.h
  GEN     x86_64-softmmu/hmp-commands-info.h
  GEN     x86_64-softmmu/config-target.h
  GEN     aarch64-softmmu/hmp-commands.h
  GEN     aarch64-softmmu/hmp-commands-info.h
  GEN     aarch64-softmmu/config-target.h
  CC      x86_64-softmmu/exec.o
  CC      x86_64-softmmu/translate-all.o
  CC      x86_64-softmmu/cpu-exec.o
  CC      x86_64-softmmu/translate-common.o
  CC      x86_64-softmmu/cpu-exec-common.o
  CC      x86_64-softmmu/tcg/tcg.o
  CC      x86_64-softmmu/tcg/tcg-op.o
  CC      x86_64-softmmu/tcg/optimize.o
  CC      x86_64-softmmu/arch_init.o
  CC      x86_64-softmmu/tcg/tcg-common.o
  CC      x86_64-softmmu/fpu/softfloat.o
  CC      x86_64-softmmu/disas.o
  CC      x86_64-softmmu/cpus.o
  CC      x86_64-softmmu/monitor.o
  CC      x86_64-softmmu/gdbstub.o
  CC      x86_64-softmmu/balloon.o
  CC      x86_64-softmmu/ioport.o
  CC      aarch64-softmmu/exec.o
  CC      aarch64-softmmu/translate-all.o
  CC      aarch64-softmmu/cpu-exec.o
  CC      x86_64-softmmu/numa.o
  CC      x86_64-softmmu/qtest.o
  CC      x86_64-softmmu/bootdevice.o
  CC      x86_64-softmmu/kvm-all.o
  CC      aarch64-softmmu/translate-common.o
  CC      aarch64-softmmu/cpu-exec-common.o
  CC      aarch64-softmmu/tcg/tcg.o
  CC      aarch64-softmmu/tcg/tcg-op.o
  CC      aarch64-softmmu/tcg/optimize.o
  CC      x86_64-softmmu/memory.o
  CC      aarch64-softmmu/tcg/tcg-common.o
  CC      x86_64-softmmu/cputlb.o
  CC      x86_64-softmmu/memory_mapping.o
  CC      aarch64-softmmu/fpu/softfloat.o
  CC      x86_64-softmmu/dump.o
  CC      x86_64-softmmu/migration/ram.o
  CC      x86_64-softmmu/migration/savevm.o
  CC      x86_64-softmmu/xen-common-stub.o
  CC      aarch64-softmmu/disas.o
  CC      x86_64-softmmu/xen-hvm-stub.o
  GEN     aarch64-softmmu/gdbstub-xml.c
  CC      x86_64-softmmu/hw/acpi/nvdimm.o
  CC      aarch64-softmmu/kvm-stub.o
  CC      x86_64-softmmu/hw/block/virtio-blk.o
  CC      aarch64-softmmu/arch_init.o
  CC      x86_64-softmmu/hw/block/dataplane/virtio-blk.o
  CC      x86_64-softmmu/hw/char/virtio-serial-bus.o
  CC      x86_64-softmmu/hw/core/nmi.o
  CC      x86_64-softmmu/hw/core/generic-loader.o
  CC      aarch64-softmmu/cpus.o
  CC      aarch64-softmmu/monitor.o
  CC      x86_64-softmmu/hw/cpu/core.o
  CC      x86_64-softmmu/hw/display/vga.o
  CC      aarch64-softmmu/gdbstub.o
  CC      aarch64-softmmu/balloon.o
  CC      aarch64-softmmu/ioport.o
  CC      x86_64-softmmu/hw/display/virtio-gpu.o
  CC      x86_64-softmmu/hw/display/virtio-gpu-3d.o
  CC      x86_64-softmmu/hw/display/virtio-gpu-pci.o
  CC      aarch64-softmmu/numa.o
  CC      aarch64-softmmu/qtest.o
  CC      aarch64-softmmu/bootdevice.o
  CC      x86_64-softmmu/hw/display/virtio-vga.o
  CC      aarch64-softmmu/memory.o
  CC      aarch64-softmmu/cputlb.o
  CC      aarch64-softmmu/memory_mapping.o
  CC      x86_64-softmmu/hw/intc/apic.o
  CC      x86_64-softmmu/hw/intc/apic_common.o
  CC      x86_64-softmmu/hw/intc/ioapic.o
  CC      x86_64-softmmu/hw/isa/lpc_ich9.o
  CC      x86_64-softmmu/hw/misc/vmport.o
  CC      aarch64-softmmu/dump.o
  CC      x86_64-softmmu/hw/misc/ivshmem.o
  CC      aarch64-softmmu/migration/ram.o
  CC      x86_64-softmmu/hw/misc/pvpanic.o
  CC      x86_64-softmmu/hw/misc/edu.o
  CC      x86_64-softmmu/hw/misc/hyperv_testdev.o
  CC      aarch64-softmmu/migration/savevm.o
  CC      aarch64-softmmu/xen-common-stub.o
  CC      aarch64-softmmu/xen-hvm-stub.o
  CC      aarch64-softmmu/hw/adc/stm32f2xx_adc.o
  CC      aarch64-softmmu/hw/block/virtio-blk.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/block/dataplane/virtio-blk.o
  CC      x86_64-softmmu/hw/scsi/virtio-scsi-dataplane.o
  CC      x86_64-softmmu/hw/scsi/vhost-scsi.o
  CC      aarch64-softmmu/hw/char/exynos4210_uart.o
  CC      x86_64-softmmu/hw/timer/mc146818rtc.o
  CC      x86_64-softmmu/hw/vfio/common.o
  CC      aarch64-softmmu/hw/char/omap_uart.o
  CC      aarch64-softmmu/hw/char/digic-uart.o
  CC      x86_64-softmmu/hw/vfio/pci.o
  CC      aarch64-softmmu/hw/char/stm32f2xx_usart.o
  CC      x86_64-softmmu/hw/vfio/pci-quirks.o
  CC      x86_64-softmmu/hw/vfio/platform.o
  CC      x86_64-softmmu/hw/vfio/calxeda-xgmac.o
  CC      aarch64-softmmu/hw/char/bcm2835_aux.o
  CC      x86_64-softmmu/hw/vfio/amd-xgbe.o
  CC      aarch64-softmmu/hw/char/virtio-serial-bus.o
  CC      aarch64-softmmu/hw/core/nmi.o
  CC      x86_64-softmmu/hw/vfio/spapr.o
  CC      x86_64-softmmu/hw/virtio/virtio.o
  CC      x86_64-softmmu/hw/virtio/virtio-balloon.o
  CC      aarch64-softmmu/hw/core/generic-loader.o
  CC      x86_64-softmmu/hw/virtio/vhost.o
  CC      aarch64-softmmu/hw/cpu/arm11mpcore.o
  CC      aarch64-softmmu/hw/cpu/realview_mpcore.o
  CC      x86_64-softmmu/hw/virtio/vhost-backend.o
  CC      aarch64-softmmu/hw/cpu/a9mpcore.o
  CC      aarch64-softmmu/hw/cpu/a15mpcore.o
  CC      aarch64-softmmu/hw/cpu/core.o
  CC      aarch64-softmmu/hw/display/omap_dss.o
  CC      x86_64-softmmu/hw/virtio/vhost-user.o
  CC      aarch64-softmmu/hw/display/omap_lcdc.o
  CC      x86_64-softmmu/hw/virtio/vhost-vsock.o
  CC      x86_64-softmmu/hw/i386/multiboot.o
  CC      aarch64-softmmu/hw/display/pxa2xx_lcd.o
  CC      aarch64-softmmu/hw/display/bcm2835_fb.o
  CC      x86_64-softmmu/hw/i386/pc.o
  CC      aarch64-softmmu/hw/display/vga.o
  CC      aarch64-softmmu/hw/display/virtio-gpu.o
  CC      x86_64-softmmu/hw/i386/pc_piix.o
  CC      x86_64-softmmu/hw/i386/pc_q35.o
  CC      x86_64-softmmu/hw/i386/pc_sysfw.o
  CC      aarch64-softmmu/hw/display/virtio-gpu-3d.o
  CC      aarch64-softmmu/hw/display/virtio-gpu-pci.o
  CC      x86_64-softmmu/hw/i386/x86-iommu.o
  CC      aarch64-softmmu/hw/display/dpcd.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      x86_64-softmmu/hw/i386/intel_iommu.o
  CC      aarch64-softmmu/hw/dma/soc_dma.o
  CC      aarch64-softmmu/hw/dma/pxa2xx_dma.o
  CC      x86_64-softmmu/hw/i386/amd_iommu.o
  CC      x86_64-softmmu/hw/i386/kvmvapic.o
  CC      x86_64-softmmu/hw/i386/acpi-build.o
  CC      aarch64-softmmu/hw/dma/bcm2835_dma.o
  CC      aarch64-softmmu/hw/gpio/omap_gpio.o
  CC      aarch64-softmmu/hw/gpio/imx_gpio.o
/tmp/qemu-test/src/hw/i386/pc_piix.c: In function ‘igd_passthrough_isa_bridge_create’:
/tmp/qemu-test/src/hw/i386/pc_piix.c:1046: warning: ‘pch_rev_id’ may be used uninitialized in this function
  CC      aarch64-softmmu/hw/i2c/omap_i2c.o
  CC      x86_64-softmmu/hw/i386/pci-assign-load-rom.o
  CC      x86_64-softmmu/hw/i386/kvm/clock.o
  CC      aarch64-softmmu/hw/input/pxa2xx_keypad.o
  CC      aarch64-softmmu/hw/input/tsc210x.o
  CC      x86_64-softmmu/hw/i386/kvm/apic.o
  CC      x86_64-softmmu/hw/i386/kvm/i8259.o
  CC      aarch64-softmmu/hw/intc/armv7m_nvic.o
  CC      x86_64-softmmu/hw/i386/kvm/ioapic.o
  CC      aarch64-softmmu/hw/intc/exynos4210_gic.o
  CC      x86_64-softmmu/hw/i386/kvm/i8254.o
  CC      aarch64-softmmu/hw/intc/exynos4210_combiner.o
  CC      x86_64-softmmu/hw/i386/kvm/pci-assign.o
  CC      x86_64-softmmu/target-i386/translate.o
  CC      x86_64-softmmu/target-i386/helper.o
  CC      x86_64-softmmu/target-i386/cpu.o
  CC      aarch64-softmmu/hw/intc/omap_intc.o
  CC      aarch64-softmmu/hw/intc/bcm2835_ic.o
  CC      x86_64-softmmu/target-i386/bpt_helper.o
  CC      aarch64-softmmu/hw/intc/bcm2836_control.o
  CC      x86_64-softmmu/target-i386/excp_helper.o
  CC      aarch64-softmmu/hw/intc/allwinner-a10-pic.o
  CC      aarch64-softmmu/hw/intc/aspeed_vic.o
  CC      aarch64-softmmu/hw/intc/arm_gicv3_cpuif.o
  CC      aarch64-softmmu/hw/misc/ivshmem.o
  CC      aarch64-softmmu/hw/misc/arm_sysctl.o
  CC      aarch64-softmmu/hw/misc/cbus.o
  CC      x86_64-softmmu/target-i386/fpu_helper.o
  CC      x86_64-softmmu/target-i386/cc_helper.o
/tmp/qemu-test/src/hw/i386/acpi-build.c: In function ‘build_append_pci_bus_devices’:
/tmp/qemu-test/src/hw/i386/acpi-build.c:472: warning: ‘notify_method’ may be used uninitialized in this function
  CC      x86_64-softmmu/target-i386/int_helper.o
  CC      aarch64-softmmu/hw/misc/exynos4210_pmu.o
  CC      x86_64-softmmu/target-i386/svm_helper.o
  CC      aarch64-softmmu/hw/misc/imx_ccm.o
  CC      x86_64-softmmu/target-i386/smm_helper.o
  CC      x86_64-softmmu/target-i386/misc_helper.o
  CC      aarch64-softmmu/hw/misc/imx31_ccm.o
  CC      aarch64-softmmu/hw/misc/imx25_ccm.o
  CC      x86_64-softmmu/target-i386/mem_helper.o
  CC      aarch64-softmmu/hw/misc/imx6_ccm.o
  CC      aarch64-softmmu/hw/misc/imx6_src.o
  CC      aarch64-softmmu/hw/misc/mst_fpga.o
  CC      x86_64-softmmu/target-i386/seg_helper.o
  CC      aarch64-softmmu/hw/misc/omap_clk.o
  CC      x86_64-softmmu/target-i386/mpx_helper.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/gdbstub.o
  CC      x86_64-softmmu/target-i386/machine.o
  CC      x86_64-softmmu/target-i386/arch_memory_mapping.o
  CC      aarch64-softmmu/hw/misc/omap_tap.o
  CC      aarch64-softmmu/hw/misc/bcm2835_mbox.o
  CC      x86_64-softmmu/target-i386/arch_dump.o
  CC      aarch64-softmmu/hw/misc/bcm2835_property.o
  CC      aarch64-softmmu/hw/misc/zynq_slcr.o
  CC      x86_64-softmmu/target-i386/monitor.o
  CC      aarch64-softmmu/hw/misc/zynq-xadc.o
  CC      x86_64-softmmu/target-i386/kvm.o
  CC      aarch64-softmmu/hw/misc/stm32f2xx_syscfg.o
  CC      aarch64-softmmu/hw/misc/edu.o
  CC      x86_64-softmmu/target-i386/hyperv.o
  GEN     trace/generated-helpers.c
  CC      aarch64-softmmu/hw/misc/auxbus.o
  CC      aarch64-softmmu/hw/misc/aspeed_scu.o
  CC      aarch64-softmmu/hw/misc/aspeed_sdmc.o
  CC      x86_64-softmmu/trace/control-target.o
  CC      aarch64-softmmu/hw/net/virtio-net.o
  CC      aarch64-softmmu/hw/net/vhost_net.o
  CC      aarch64-softmmu/hw/pcmcia/pxa2xx.o
  CC      aarch64-softmmu/hw/scsi/virtio-scsi.o
  CC      x86_64-softmmu/trace/generated-helpers.o
  CC      aarch64-softmmu/hw/scsi/virtio-scsi-dataplane.o
  CC      aarch64-softmmu/hw/scsi/vhost-scsi.o
  CC      aarch64-softmmu/hw/sd/omap_mmc.o
  CC      aarch64-softmmu/hw/sd/pxa2xx_mmci.o
  CC      aarch64-softmmu/hw/ssi/omap_spi.o
  CC      aarch64-softmmu/hw/ssi/imx_spi.o
  CC      aarch64-softmmu/hw/timer/exynos4210_mct.o
  CC      aarch64-softmmu/hw/timer/exynos4210_pwm.o
  CC      aarch64-softmmu/hw/timer/exynos4210_rtc.o
  CC      aarch64-softmmu/hw/timer/omap_gptimer.o
  CC      aarch64-softmmu/hw/timer/omap_synctimer.o
  CC      aarch64-softmmu/hw/timer/pxa2xx_timer.o
  CC      aarch64-softmmu/hw/timer/digic-timer.o
  CC      aarch64-softmmu/hw/timer/allwinner-a10-pit.o
  CC      aarch64-softmmu/hw/usb/tusb6010.o
  CC      aarch64-softmmu/hw/vfio/common.o
  CC      aarch64-softmmu/hw/vfio/pci.o
  CC      aarch64-softmmu/hw/vfio/pci-quirks.o
  CC      aarch64-softmmu/hw/vfio/platform.o
  CC      aarch64-softmmu/hw/vfio/calxeda-xgmac.o
  CC      aarch64-softmmu/hw/vfio/amd-xgbe.o
  CC      aarch64-softmmu/hw/vfio/spapr.o
  CC      aarch64-softmmu/hw/virtio/virtio.o
  CC      aarch64-softmmu/hw/virtio/virtio-balloon.o
  CC      aarch64-softmmu/hw/virtio/vhost.o
  CC      aarch64-softmmu/hw/virtio/vhost-backend.o
  CC      aarch64-softmmu/hw/virtio/vhost-user.o
  CC      aarch64-softmmu/hw/virtio/vhost-vsock.o
  CC      aarch64-softmmu/hw/arm/boot.o
  CC      aarch64-softmmu/hw/arm/collie.o
  CC      aarch64-softmmu/hw/arm/exynos4_boards.o
  CC      aarch64-softmmu/hw/arm/gumstix.o
  CC      aarch64-softmmu/hw/arm/highbank.o
  CC      aarch64-softmmu/hw/arm/digic_boards.o
  CC      aarch64-softmmu/hw/arm/integratorcp.o
  CC      aarch64-softmmu/hw/arm/mainstone.o
  CC      aarch64-softmmu/hw/arm/musicpal.o
  CC      aarch64-softmmu/hw/arm/nseries.o
  CC      aarch64-softmmu/hw/arm/omap_sx1.o
  CC      aarch64-softmmu/hw/arm/palm.o
  CC      aarch64-softmmu/hw/arm/realview.o
  CC      aarch64-softmmu/hw/arm/spitz.o
  CC      aarch64-softmmu/hw/arm/stellaris.o
  CC      aarch64-softmmu/hw/arm/tosa.o
  CC      aarch64-softmmu/hw/arm/versatilepb.o
  CC      aarch64-softmmu/hw/arm/vexpress.o
  CC      aarch64-softmmu/hw/arm/virt.o
  CC      aarch64-softmmu/hw/arm/xilinx_zynq.o
  CC      aarch64-softmmu/hw/arm/virt-acpi-build.o
  CC      aarch64-softmmu/hw/arm/z2.o
  CC      aarch64-softmmu/hw/arm/netduino2.o
  CC      aarch64-softmmu/hw/arm/sysbus-fdt.o
  CC      aarch64-softmmu/hw/arm/armv7m.o
  CC      aarch64-softmmu/hw/arm/pxa2xx.o
  CC      aarch64-softmmu/hw/arm/exynos4210.o
  CC      aarch64-softmmu/hw/arm/pxa2xx_gpio.o
  CC      aarch64-softmmu/hw/arm/pxa2xx_pic.o
  CC      aarch64-softmmu/hw/arm/digic.o
  CC      aarch64-softmmu/hw/arm/omap1.o
  CC      aarch64-softmmu/hw/arm/omap2.o
  LINK    x86_64-softmmu/qemu-system-x86_64
  CC      aarch64-softmmu/hw/arm/strongarm.o
  CC      aarch64-softmmu/hw/arm/allwinner-a10.o
  CC      aarch64-softmmu/hw/arm/cubieboard.o
  CC      aarch64-softmmu/hw/arm/bcm2835_peripherals.o
  CC      aarch64-softmmu/hw/arm/bcm2836.o
  CC      aarch64-softmmu/hw/arm/raspi.o
  CC      aarch64-softmmu/hw/arm/stm32f205_soc.o
  CC      aarch64-softmmu/hw/arm/xlnx-zynqmp.o
  CC      aarch64-softmmu/hw/arm/xlnx-ep108.o
  CC      aarch64-softmmu/hw/arm/fsl-imx25.o
  CC      aarch64-softmmu/hw/arm/imx25_pdk.o
  CC      aarch64-softmmu/hw/arm/fsl-imx31.o
  CC      aarch64-softmmu/hw/arm/kzm.o
  CC      aarch64-softmmu/hw/arm/fsl-imx6.o
  CC      aarch64-softmmu/hw/arm/sabrelite.o
  CC      aarch64-softmmu/hw/arm/aspeed_soc.o
  CC      aarch64-softmmu/hw/arm/aspeed.o
  CC      aarch64-softmmu/target-arm/arm-semi.o
  CC      aarch64-softmmu/target-arm/machine.o
  CC      aarch64-softmmu/target-arm/psci.o
  CC      aarch64-softmmu/target-arm/monitor.o
  CC      aarch64-softmmu/target-arm/arch_dump.o
  CC      aarch64-softmmu/target-arm/kvm-stub.o
  CC      aarch64-softmmu/target-arm/translate.o
  CC      aarch64-softmmu/target-arm/op_helper.o
  CC      aarch64-softmmu/target-arm/helper.o
  CC      aarch64-softmmu/target-arm/cpu.o
  CC      aarch64-softmmu/target-arm/neon_helper.o
  CC      aarch64-softmmu/target-arm/iwmmxt_helper.o
  CC      aarch64-softmmu/target-arm/gdbstub.o
  CC      aarch64-softmmu/target-arm/cpu64.o
  CC      aarch64-softmmu/target-arm/translate-a64.o
  CC      aarch64-softmmu/target-arm/helper-a64.o
  CC      aarch64-softmmu/target-arm/gdbstub64.o
  CC      aarch64-softmmu/target-arm/crypto_helper.o
  CC      aarch64-softmmu/target-arm/arm-powerctl.o
  GEN     trace/generated-helpers.c
  CC      aarch64-softmmu/trace/control-target.o
  CC      aarch64-softmmu/gdbstub-xml.o
  CC      aarch64-softmmu/trace/generated-helpers.o
/tmp/qemu-test/src/target-arm/translate-a64.c: In function ‘handle_shri_with_rndacc’:
/tmp/qemu-test/src/target-arm/translate-a64.c:6405: warning: ‘tcg_src_hi’ may be used uninitialized in this function
/tmp/qemu-test/src/target-arm/translate-a64.c: In function ‘disas_simd_scalar_two_reg_misc’:
/tmp/qemu-test/src/target-arm/translate-a64.c:8132: warning: ‘rmode’ may be used uninitialized in this function
  LINK    aarch64-softmmu/qemu-system-aarch64
  TEST    tests/qapi-schema/alternate-any.out
  TEST    tests/qapi-schema/alternate-array.out
  TEST    tests/qapi-schema/alternate-base.out
  TEST    tests/qapi-schema/alternate-clash.out
  TEST    tests/qapi-schema/alternate-conflict-dict.out
  TEST    tests/qapi-schema/alternate-conflict-string.out
  TEST    tests/qapi-schema/alternate-empty.out
  TEST    tests/qapi-schema/alternate-nested.out
  TEST    tests/qapi-schema/alternate-unknown.out
  TEST    tests/qapi-schema/args-alternate.out
  TEST    tests/qapi-schema/args-any.out
  TEST    tests/qapi-schema/args-array-empty.out
  TEST    tests/qapi-schema/args-array-unknown.out
  TEST    tests/qapi-schema/args-bad-boxed.out
  TEST    tests/qapi-schema/args-boxed-anon.out
  TEST    tests/qapi-schema/args-boxed-empty.out
  TEST    tests/qapi-schema/args-boxed-string.out
  TEST    tests/qapi-schema/args-int.out
  TEST    tests/qapi-schema/args-invalid.out
  TEST    tests/qapi-schema/args-member-array-bad.out
  TEST    tests/qapi-schema/args-member-case.out
  TEST    tests/qapi-schema/args-member-unknown.out
  TEST    tests/qapi-schema/args-name-clash.out
  TEST    tests/qapi-schema/args-union.out
  TEST    tests/qapi-schema/args-unknown.out
  TEST    tests/qapi-schema/bad-base.out
  TEST    tests/qapi-schema/bad-data.out
  TEST    tests/qapi-schema/bad-ident.out
  TEST    tests/qapi-schema/bad-type-bool.out
  TEST    tests/qapi-schema/bad-type-dict.out
  TEST    tests/qapi-schema/bad-type-int.out
  TEST    tests/qapi-schema/base-cycle-direct.out
  TEST    tests/qapi-schema/base-cycle-indirect.out
  TEST    tests/qapi-schema/command-int.out
  TEST    tests/qapi-schema/comments.out
  TEST    tests/qapi-schema/double-data.out
  TEST    tests/qapi-schema/double-type.out
  TEST    tests/qapi-schema/duplicate-key.out
  TEST    tests/qapi-schema/empty.out
  TEST    tests/qapi-schema/enum-bad-name.out
  TEST    tests/qapi-schema/enum-bad-prefix.out
  TEST    tests/qapi-schema/enum-clash-member.out
  TEST    tests/qapi-schema/enum-dict-member.out
  TEST    tests/qapi-schema/enum-int-member.out
  TEST    tests/qapi-schema/enum-member-case.out
  TEST    tests/qapi-schema/enum-missing-data.out
  TEST    tests/qapi-schema/enum-wrong-data.out
  TEST    tests/qapi-schema/escape-outside-string.out
  TEST    tests/qapi-schema/escape-too-big.out
  TEST    tests/qapi-schema/escape-too-short.out
  TEST    tests/qapi-schema/event-boxed-empty.out
  TEST    tests/qapi-schema/event-case.out
  TEST    tests/qapi-schema/event-nest-struct.out
  TEST    tests/qapi-schema/flat-union-array-branch.out
  TEST    tests/qapi-schema/flat-union-bad-base.out
  TEST    tests/qapi-schema/flat-union-bad-discriminator.out
  TEST    tests/qapi-schema/flat-union-base-any.out
  TEST    tests/qapi-schema/flat-union-base-union.out
  TEST    tests/qapi-schema/flat-union-clash-member.out
  TEST    tests/qapi-schema/flat-union-empty.out
  TEST    tests/qapi-schema/flat-union-incomplete-branch.out
  TEST    tests/qapi-schema/flat-union-inline.out
  TEST    tests/qapi-schema/flat-union-int-branch.out
  TEST    tests/qapi-schema/flat-union-invalid-branch-key.out
  TEST    tests/qapi-schema/flat-union-invalid-discriminator.out
  TEST    tests/qapi-schema/flat-union-no-base.out
  TEST    tests/qapi-schema/flat-union-string-discriminator.out
  TEST    tests/qapi-schema/flat-union-optional-discriminator.out
  TEST    tests/qapi-schema/funny-char.out
  TEST    tests/qapi-schema/ident-with-escape.out
  TEST    tests/qapi-schema/include-before-err.out
  TEST    tests/qapi-schema/include-cycle.out
  TEST    tests/qapi-schema/include-format-err.out
  TEST    tests/qapi-schema/include-nested-err.out
  TEST    tests/qapi-schema/include-no-file.out
  TEST    tests/qapi-schema/include-non-file.out
  TEST    tests/qapi-schema/include-relpath.out
  TEST    tests/qapi-schema/include-repetition.out
  TEST    tests/qapi-schema/include-self-cycle.out
  TEST    tests/qapi-schema/include-simple.out
  TEST    tests/qapi-schema/indented-expr.out
  TEST    tests/qapi-schema/leading-comma-list.out
  TEST    tests/qapi-schema/leading-comma-object.out
  TEST    tests/qapi-schema/missing-colon.out
  TEST    tests/qapi-schema/missing-comma-list.out
  TEST    tests/qapi-schema/missing-comma-object.out
  TEST    tests/qapi-schema/missing-type.out
  TEST    tests/qapi-schema/nested-struct-data.out
  TEST    tests/qapi-schema/non-objects.out
  TEST    tests/qapi-schema/qapi-schema-test.out
  TEST    tests/qapi-schema/quoted-structural-chars.out
  TEST    tests/qapi-schema/redefined-builtin.out
  TEST    tests/qapi-schema/redefined-command.out
  TEST    tests/qapi-schema/redefined-event.out
  TEST    tests/qapi-schema/redefined-type.out
  TEST    tests/qapi-schema/reserved-command-q.out
  TEST    tests/qapi-schema/reserved-enum-q.out
  TEST    tests/qapi-schema/reserved-member-has.out
  TEST    tests/qapi-schema/reserved-member-q.out
  TEST    tests/qapi-schema/reserved-member-u.out
  TEST    tests/qapi-schema/reserved-member-underscore.out
  TEST    tests/qapi-schema/reserved-type-kind.out
  TEST    tests/qapi-schema/reserved-type-list.out
  TEST    tests/qapi-schema/returns-alternate.out
  TEST    tests/qapi-schema/returns-array-bad.out
  TEST    tests/qapi-schema/returns-dict.out
  TEST    tests/qapi-schema/returns-unknown.out
  TEST    tests/qapi-schema/returns-whitelist.out
  TEST    tests/qapi-schema/struct-base-clash-deep.out
  TEST    tests/qapi-schema/struct-base-clash.out
  TEST    tests/qapi-schema/struct-data-invalid.out
  TEST    tests/qapi-schema/struct-member-invalid.out
  TEST    tests/qapi-schema/trailing-comma-list.out
  TEST    tests/qapi-schema/trailing-comma-object.out
  TEST    tests/qapi-schema/type-bypass-bad-gen.out
  TEST    tests/qapi-schema/unclosed-list.out
  TEST    tests/qapi-schema/unclosed-object.out
  TEST    tests/qapi-schema/unclosed-string.out
  TEST    tests/qapi-schema/unicode-str.out
  TEST    tests/qapi-schema/union-base-no-discriminator.out
  TEST    tests/qapi-schema/union-branch-case.out
  TEST    tests/qapi-schema/union-clash-branches.out
  TEST    tests/qapi-schema/union-invalid-base.out
  TEST    tests/qapi-schema/union-empty.out
  TEST    tests/qapi-schema/union-optional-branch.out
  TEST    tests/qapi-schema/union-unknown.out
  TEST    tests/qapi-schema/unknown-escape.out
  TEST    tests/qapi-schema/unknown-expr-key.out
  CC      tests/check-qdict.o
  CC      tests/check-qfloat.o
  CC      tests/check-qint.o
  CC      tests/check-qstring.o
  CC      tests/check-qnull.o
  CC      tests/check-qlist.o
  CC      tests/check-qjson.o
  CC      tests/test-qmp-output-visitor.o
  GEN     tests/test-qapi-visit.c
  GEN     tests/test-qapi-types.c
  GEN     tests/test-qmp-introspect.c
  CC      tests/test-clone-visitor.o
  GEN     tests/test-qapi-event.c
  CC      tests/test-qmp-input-visitor.o
  CC      tests/test-qmp-input-strict.o
  CC      tests/test-qmp-commands.o
  GEN     tests/test-qmp-marshal.c
  CC      tests/test-string-output-visitor.o
  CC      tests/test-string-input-visitor.o
  CC      tests/test-qmp-event.o
  CC      tests/test-opts-visitor.o
  CC      tests/test-coroutine.o
  CC      tests/test-visitor-serialization.o
  CC      tests/test-aio.o
  CC      tests/test-iov.o
  CC      tests/test-rfifolock.o
  CC      tests/test-throttle.o
  CC      tests/test-thread-pool.o
  CC      tests/test-hbitmap.o
  CC      tests/test-blockjob.o
  CC      tests/test-blockjob-txn.o
  CC      tests/test-x86-cpuid.o
  CC      tests/test-vmstate.o
  CC      tests/test-xbzrle.o
  CC      tests/test-cutils.o
  CC      tests/rcutorture.o
  CC      tests/test-mul64.o
  CC      tests/test-int128.o
  CC      tests/test-rcu-list.o
  CC      tests/test-qdist.o
/tmp/qemu-test/src/tests/test-int128.c:180: warning: ‘__noclone__’ attribute directive ignored
  CC      tests/test-qht.o
  CC      tests/test-qht-par.o
  CC      tests/qht-bench.o
  CC      tests/test-bitops.o
  CC      tests/check-qom-interface.o
  CC      tests/check-qom-proplist.o
  CC      tests/test-qemu-opts.o
  CC      tests/test-write-threshold.o
  CC      tests/test-crypto-hash.o
  CC      tests/test-crypto-secret.o
  CC      tests/test-crypto-cipher.o
  CC      tests/test-qga.o
  CC      tests/libqtest.o
  CC      tests/test-timed-average.o
  CC      tests/test-io-task.o
  CC      tests/test-io-channel-socket.o
  CC      tests/io-channel-helpers.o
  CC      tests/test-io-channel-file.o
  CC      tests/test-io-channel-command.o
  CC      tests/test-io-channel-buffer.o
  CC      tests/test-base64.o
  CC      tests/test-crypto-ivgen.o
  CC      tests/test-logging.o
  CC      tests/test-crypto-afsplit.o
  CC      tests/test-crypto-xts.o
  CC      tests/test-crypto-block.o
  CC      tests/test-replication.o
  CC      tests/test-bufferiszero.o
  CC      tests/test-uuid.o
  CC      tests/ptimer-test.o
  CC      tests/ptimer-test-stubs.o
  CC      tests/vhost-user-test.o
  CC      tests/libqos/pci.o
  CC      tests/libqos/fw_cfg.o
  CC      tests/libqos/malloc.o
  CC      tests/libqos/i2c.o
  CC      tests/libqos/libqos.o
  CC      tests/libqos/pci-pc.o
  CC      tests/libqos/malloc-pc.o
  CC      tests/libqos/libqos-pc.o
  CC      tests/libqos/ahci.o
  CC      tests/libqos/virtio.o
  CC      tests/libqos/virtio-pci.o
  CC      tests/libqos/malloc-generic.o
  CC      tests/libqos/virtio-mmio.o
  CC      tests/endianness-test.o
  CC      tests/fdc-test.o
  CC      tests/ide-test.o
  CC      tests/ahci-test.o
  CC      tests/boot-order-test.o
  CC      tests/hd-geo-test.o
  CC      tests/bios-tables-test.o
  CC      tests/boot-sector.o
  CC      tests/boot-serial-test.o
  CC      tests/pxe-test.o
  CC      tests/rtc-test.o
  CC      tests/ipmi-kcs-test.o
/tmp/qemu-test/src/tests/ide-test.c: In function ‘cdrom_pio_impl’:
/tmp/qemu-test/src/tests/ide-test.c:739: warning: ignoring return value of ‘fwrite’, declared with attribute warn_unused_result
/tmp/qemu-test/src/tests/ide-test.c: In function ‘test_cdrom_dma’:
/tmp/qemu-test/src/tests/ide-test.c:832: warning: ignoring return value of ‘fwrite’, declared with attribute warn_unused_result
  CC      tests/ipmi-bt-test.o
  CC      tests/i440fx-test.o
  CC      tests/drive_del-test.o
  CC      tests/fw_cfg-test.o
  CC      tests/wdt_ib700-test.o
  CC      tests/tco-test.o
  CC      tests/e1000-test.o
  CC      tests/e1000e-test.o
  CC      tests/pcnet-test.o
  CC      tests/rtl8139-test.o
  CC      tests/eepro100-test.o
  CC      tests/ne2000-test.o
  CC      tests/es1370-test.o
  CC      tests/nvme-test.o
  CC      tests/ac97-test.o
  CC      tests/virtio-net-test.o
  CC      tests/virtio-balloon-test.o
  CC      tests/virtio-blk-test.o
  CC      tests/virtio-scsi-test.o
  CC      tests/virtio-rng-test.o
  CC      tests/virtio-console-test.o
  CC      tests/virtio-serial-test.o
  CC      tests/tpci200-test.o
  CC      tests/ipoctal232-test.o
  CC      tests/display-vga-test.o
  CC      tests/intel-hda-test.o
  CC      tests/ivshmem-test.o
  CC      tests/vmxnet3-test.o
  CC      tests/pvpanic-test.o
  CC      tests/i82801b11-test.o
  CC      tests/ioh3420-test.o
  CC      tests/usb-hcd-ohci-test.o
  CC      tests/libqos/malloc-spapr.o
  CC      tests/libqos/pci-spapr.o
  CC      tests/libqos/libqos-spapr.o
  CC      tests/libqos/usb.o
  CC      tests/libqos/rtas.o
  CC      tests/usb-hcd-uhci-test.o
  CC      tests/usb-hcd-ehci-test.o
  CC      tests/usb-hcd-xhci-test.o
  CC      tests/pc-cpu-test.o
  CC      tests/test-netfilter.o
  CC      tests/q35-test.o
  CC      tests/test-filter-mirror.o
  CC      tests/test-filter-redirector.o
  CC      tests/postcopy-test.o
  CC      tests/test-x86-cpuid-compat.o
  CC      tests/device-introspect-test.o
  CC      tests/qom-test.o
  LINK    tests/check-qdict
  LINK    tests/check-qfloat
  LINK    tests/check-qint
  LINK    tests/check-qstring
  LINK    tests/check-qlist
  LINK    tests/check-qnull
  LINK    tests/check-qjson
  CC      tests/test-qapi-event.o
  CC      tests/test-qapi-visit.o
  CC      tests/test-qapi-types.o
  CC      tests/test-qmp-introspect.o
  CC      tests/test-qmp-marshal.o
  LINK    tests/test-coroutine
  LINK    tests/test-visitor-serialization
  LINK    tests/test-iov
  LINK    tests/test-aio
  LINK    tests/test-rfifolock
  LINK    tests/test-throttle
  LINK    tests/test-thread-pool
  LINK    tests/test-hbitmap
  LINK    tests/test-blockjob
  LINK    tests/test-blockjob-txn
  LINK    tests/test-x86-cpuid
  LINK    tests/test-xbzrle
  LINK    tests/test-vmstate
  LINK    tests/test-cutils
  LINK    tests/test-int128
  LINK    tests/test-mul64
  LINK    tests/rcutorture
  LINK    tests/test-rcu-list
  LINK    tests/test-qdist
  LINK    tests/test-qht
  LINK    tests/qht-bench
  LINK    tests/test-bitops
  LINK    tests/check-qom-interface
  LINK    tests/check-qom-proplist
  LINK    tests/test-qemu-opts
  LINK    tests/test-write-threshold
  LINK    tests/test-crypto-hash
  LINK    tests/test-crypto-cipher
  LINK    tests/test-crypto-secret
  LINK    tests/test-qga
  LINK    tests/test-timed-average
  LINK    tests/test-io-task
  LINK    tests/test-io-channel-socket
  LINK    tests/test-io-channel-file
  LINK    tests/test-io-channel-command
  LINK    tests/test-io-channel-buffer
  LINK    tests/test-base64
  LINK    tests/test-crypto-ivgen
  LINK    tests/test-crypto-afsplit
  LINK    tests/test-crypto-xts
  LINK    tests/test-crypto-block
  LINK    tests/test-logging
  LINK    tests/test-replication
  LINK    tests/test-bufferiszero
  LINK    tests/test-uuid
  LINK    tests/ptimer-test
  LINK    tests/vhost-user-test
  LINK    tests/endianness-test
  LINK    tests/fdc-test
  LINK    tests/ide-test
  LINK    tests/ahci-test
  LINK    tests/hd-geo-test
  LINK    tests/boot-order-test
  LINK    tests/bios-tables-test
  LINK    tests/boot-serial-test
  LINK    tests/pxe-test
  LINK    tests/rtc-test
  LINK    tests/ipmi-kcs-test
  LINK    tests/ipmi-bt-test
  LINK    tests/i440fx-test
  LINK    tests/fw_cfg-test
  LINK    tests/drive_del-test
  LINK    tests/wdt_ib700-test
  LINK    tests/tco-test
  LINK    tests/e1000-test
  LINK    tests/e1000e-test
  LINK    tests/rtl8139-test
  LINK    tests/pcnet-test
  LINK    tests/eepro100-test
  LINK    tests/ne2000-test
  LINK    tests/nvme-test
  LINK    tests/ac97-test
  LINK    tests/es1370-test
  LINK    tests/virtio-net-test
  LINK    tests/virtio-balloon-test
  LINK    tests/virtio-blk-test
  LINK    tests/virtio-rng-test
  LINK    tests/virtio-scsi-test
  LINK    tests/virtio-serial-test
  LINK    tests/virtio-console-test
  LINK    tests/tpci200-test
  LINK    tests/ipoctal232-test
  LINK    tests/display-vga-test
  LINK    tests/intel-hda-test
  LINK    tests/ivshmem-test
  LINK    tests/vmxnet3-test
  LINK    tests/pvpanic-test
  LINK    tests/i82801b11-test
  LINK    tests/ioh3420-test
  LINK    tests/usb-hcd-ohci-test
  LINK    tests/usb-hcd-uhci-test
  LINK    tests/usb-hcd-ehci-test
  LINK    tests/usb-hcd-xhci-test
  LINK    tests/pc-cpu-test
  LINK    tests/q35-test
  LINK    tests/test-netfilter
  LINK    tests/test-filter-mirror
  LINK    tests/test-filter-redirector
  LINK    tests/postcopy-test
  LINK    tests/test-x86-cpuid-compat
  LINK    tests/device-introspect-test
  LINK    tests/qom-test
  GTESTER tests/check-qdict
  GTESTER tests/check-qfloat
  GTESTER tests/check-qint
  GTESTER tests/check-qstring
  GTESTER tests/check-qlist
  GTESTER tests/check-qnull
  GTESTER tests/check-qjson
  LINK    tests/test-qmp-output-visitor
  LINK    tests/test-clone-visitor
  LINK    tests/test-qmp-input-visitor
  LINK    tests/test-qmp-input-strict
  LINK    tests/test-qmp-commands
  LINK    tests/test-string-input-visitor
  LINK    tests/test-string-output-visitor
  LINK    tests/test-qmp-event
  LINK    tests/test-opts-visitor
  GTESTER tests/test-coroutine
  GTESTER tests/test-visitor-serialization
  GTESTER tests/test-iov
  GTESTER tests/test-aio
  GTESTER tests/test-rfifolock
  GTESTER tests/test-thread-pool
  GTESTER tests/test-throttle
  GTESTER tests/test-hbitmap
  GTESTER tests/test-blockjob
  GTESTER tests/test-blockjob-txn
  GTESTER tests/test-x86-cpuid
  GTESTER tests/test-xbzrle
  GTESTER tests/test-vmstate
  GTESTER tests/test-cutils
  GTESTER tests/test-mul64
Failed to load simple/primitive:b_1
Failed to load simple/primitive:i64_2
Failed to load simple/primitive:i32_1
Failed to load simple/primitive:i32_1
  GTESTER tests/test-int128
  GTESTER tests/rcutorture
  GTESTER tests/test-rcu-list
  GTESTER tests/test-qdist
  GTESTER tests/test-qht
  GTESTER tests/test-qemu-opts
  LINK    tests/test-qht-par
  GTESTER tests/test-bitops
  GTESTER tests/check-qom-interface
  GTESTER tests/check-qom-proplist
  GTESTER tests/test-write-threshold
  GTESTER tests/test-crypto-hash
  GTESTER tests/test-crypto-cipher
  GTESTER tests/test-crypto-secret
  GTESTER tests/test-qga
  GTESTER tests/test-io-task
  GTESTER tests/test-timed-average
  GTESTER tests/test-io-channel-socket
  GTESTER tests/test-io-channel-file
  GTESTER tests/test-io-channel-command
  GTESTER tests/test-io-channel-buffer
  GTESTER tests/test-base64
  GTESTER tests/test-crypto-ivgen
  GTESTER tests/test-crypto-afsplit
  GTESTER tests/test-crypto-xts
  GTESTER tests/test-crypto-block
  GTESTER tests/test-logging
  GTESTER tests/test-replication
  GTESTER tests/test-bufferiszero
  GTESTER tests/test-uuid
  GTESTER tests/ptimer-test
  GTESTER check-qtest-x86_64
  GTESTER check-qtest-aarch64
  GTESTER tests/test-qmp-output-visitor
  GTESTER tests/test-clone-visitor
  GTESTER tests/test-qmp-input-visitor
  GTESTER tests/test-qmp-input-strict
  GTESTER tests/test-qmp-commands
  GTESTER tests/test-string-input-visitor
  GTESTER tests/test-string-output-visitor
  GTESTER tests/test-opts-visitor
  GTESTER tests/test-qht-par
  GTESTER tests/test-qmp-event
Could not access KVM kernel module: No such file or directory
failed to initialize KVM: No such file or directory
Back to tcg accelerator.
Could not access KVM kernel module: No such file or directory
failed to initialize KVM: No such file or directory
Back to tcg accelerator.
Could not access KVM kernel module: No such file or directory
failed to initialize KVM: No such file or directory
Back to tcg accelerator.
Could not access KVM kernel module: No such file or directory
failed to initialize KVM: No such file or directory
Back to tcg accelerator.
Could not access KVM kernel module: No such file or directory
failed to initialize KVM: No such file or directory
Back to tcg accelerator.
Could not access KVM kernel module: No such file or directory
failed to initialize KVM: No such file or directory
Back to tcg accelerator.
Could not access KVM kernel module: No such file or directory
failed to initialize KVM: No such file or directory
Back to tcg accelerator.
Could not access KVM kernel module: No such file or directory
failed to initialize KVM: No such file or directory
Back to tcg accelerator.
make[1]: Leaving directory '/var/tmp/patchew-tester-tmp-7squmlt9/src'
  BUILD   fedora
make[1]: Entering directory '/var/tmp/patchew-tester-tmp-7squmlt9/src'
  ARCHIVE qemu.tgz
  ARCHIVE dtc.tgz
  COPY    RUNNER
    RUN test-mingw in qemu:fedora 
Packages installed:
PyYAML-3.11-12.fc24.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
ccache-3.3.1-1.fc24.x86_64
clang-3.8.0-2.fc24.x86_64
findutils-4.6.0-7.fc24.x86_64
flex-2.6.0-2.fc24.x86_64
gcc-6.1.1-3.fc24.x86_64
gcc-c++-6.1.1-3.fc24.x86_64
git-2.7.4-2.fc24.x86_64
glib2-devel-2.48.2-1.fc24.x86_64
libfdt-devel-1.4.2-1.fc24.x86_64
make-4.1-5.fc24.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.48.2-1.fc24.noarch
mingw32-gmp-6.1.0-1.fc24.noarch
mingw32-gnutls-3.4.14-1.fc24.noarch
mingw32-gtk2-2.24.30-1.fc24.noarch
mingw32-gtk3-3.20.9-1.fc24.noarch
mingw32-libjpeg-turbo-1.4.2-1.fc24.noarch
mingw32-libpng-1.6.23-1.fc24.noarch
mingw32-libssh2-1.4.3-5.fc24.noarch
mingw32-libtasn1-4.5-2.fc24.noarch
mingw32-nettle-3.2-1.fc24.noarch
mingw32-pixman-0.34.0-1.fc24.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.48.2-1.fc24.noarch
mingw64-gmp-6.1.0-1.fc24.noarch
mingw64-gnutls-3.4.14-1.fc24.noarch
mingw64-gtk2-2.24.30-1.fc24.noarch
mingw64-gtk3-3.20.9-1.fc24.noarch
mingw64-libjpeg-turbo-1.4.2-1.fc24.noarch
mingw64-libpng-1.6.23-1.fc24.noarch
mingw64-libssh2-1.4.3-5.fc24.noarch
mingw64-libtasn1-4.5-2.fc24.noarch
mingw64-nettle-3.2-1.fc24.noarch
mingw64-pixman-0.34.0-1.fc24.noarch
mingw64-pkg-config-0.28-6.fc24.x86_64
perl-5.22.2-362.fc24.x86_64
pixman-devel-0.34.0-2.fc24.x86_64
sparse-0.5.0-7.fc24.x86_64
tar-1.28-7.fc24.x86_64
which-2.20-13.fc24.x86_64
zlib-devel-1.2.8-10.fc24.x86_64

Environment variables:
PACKAGES=ccache git tar PyYAML sparse flex bison     glib2-devel pixman-devel zlib-devel SDL-devel libfdt-devel     gcc gcc-c++ clang make perl which bc findutils     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=
TERM=xterm
MAKEFLAGS= -j16
HISTSIZE=1000
J=16
USER=root
CCACHE_DIR=/var/tmp/ccache
EXTRA_CONFIGURE_OPTS=
V=
SHOW_ENV=1
MAIL=/var/spool/mail/root
PATH=/usr/lib/ccache:/usr/lib64/ccache:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PWD=/
TARGET_LIST=
HISTCONTROL=ignoredups
SHLVL=1
HOME=/root
TEST_DIR=/tmp/qemu-test
LOGNAME=root
LESSOPEN=||/usr/bin/lesspipe.sh %s
FEATURES=mingw clang pyyaml dtc
DEBUG=
_=/usr/bin/env

Configure options:
--enable-werror --target-list=x86_64-softmmu,aarch64-softmmu --prefix=/var/tmp/qemu-build/install --cross-prefix=x86_64-w64-mingw32- --enable-trace-backends=simple --enable-debug --enable-gnutls --enable-nettle --enable-curl --enable-vnc --enable-bzip2 --enable-guest-agent --with-sdlabi=1.2 --with-gtkabi=2.0
Install prefix    /var/tmp/qemu-build/install
BIOS directory    /var/tmp/qemu-build/install
binary directory  /var/tmp/qemu-build/install
library directory /var/tmp/qemu-build/install/lib
module directory  /var/tmp/qemu-build/install/lib
libexec directory /var/tmp/qemu-build/install/libexec
include directory /var/tmp/qemu-build/install/include
config directory  /var/tmp/qemu-build/install
local state directory   queried at runtime
Windows SDK       no
Source path       /tmp/qemu-test/src
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            -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 -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 -Wmissing-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
tcg debug enabled yes
gprof enabled     no
sparse enabled    no
strip binaries    no
profiler          no
static build      no
pixman            system
SDL support       yes (1.2.15)
GTK support       yes (2.24.30)
GTK GL support    no
VTE support       no 
TLS priority      NORMAL
GNUTLS support    yes
GNUTLS rnd        yes
libgcrypt         no
libgcrypt kdf     no
nettle            yes (3.2)
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
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
RDMA support      no
TCG interpreter   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
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
GlusterFS support no
Archipelago support no
gcov              gcov
gcov enabled      no
TPM support       yes
libssh2 support   yes
TPM passthrough   no
QOM debugging     yes
lzo support       no
snappy support    no
bzip2 support     yes
NUMA host support no
tcmalloc support  no
jemalloc support  no
avx2 optimization yes
replication support yes
mkdir -p dtc/libfdt
  GEN     x86_64-softmmu/config-devices.mak.tmp
mkdir -p dtc/tests
  GEN     config-host.h
  GEN     aarch64-softmmu/config-devices.mak.tmp
  GEN     qemu-options.def
  GEN     qmp-commands.h
  GEN     qapi-types.h
  GEN     qapi-visit.h
  GEN     qapi-event.h
  GEN     qmp-introspect.h
  GEN     module_block.h
  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     x86_64-softmmu/config-devices.mak
  GEN     aarch64-softmmu/config-devices.mak
  GEN     trace/generated-tracers.h
  GEN     trace/generated-tcg-tracers.h
	 DEP /tmp/qemu-test/src/dtc/tests/dumptrees.c
  GEN     trace/generated-helpers-wrappers.h
  GEN     trace/generated-helpers.h
	 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/subnode_iterate.c
  GEN     config-all-devices.mak
	 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/phandle_format.c
	 DEP /tmp/qemu-test/src/dtc/tests/path-references.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/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_check_compatible.c
	 DEP /tmp/qemu-test/src/dtc/tests/node_offset_by_phandle.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/subnode_offset.c
	 DEP /tmp/qemu-test/src/dtc/tests/find_property.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_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/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/data.c
	 DEP /tmp/qemu-test/src/dtc/checks.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_wip.o
	 CC libfdt/fdt_sw.o
	 CC libfdt/fdt_ro.o
	 CC libfdt/fdt_rw.o
	 CC libfdt/fdt_strerror.o
	 CC libfdt/fdt_empty_tree.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
  RC      version.lo
  RC      version.o
  GEN     qga/qapi-generated/qga-qapi-types.h
  GEN     qga/qapi-generated/qga-qapi-visit.h
  GEN     qga/qapi-generated/qga-qmp-commands.h
  GEN     qga/qapi-generated/qga-qapi-types.c
  GEN     qga/qapi-generated/qga-qapi-visit.c
  GEN     qga/qapi-generated/qga-qmp-marshal.c
  GEN     qmp-introspect.c
  GEN     qapi-types.c
  GEN     qapi-visit.c
  GEN     qapi-event.c
  CC      qapi/qapi-visit-core.o
  CC      qapi/qmp-input-visitor.o
  CC      qapi/qmp-output-visitor.o
  CC      qapi/qapi-dealloc-visitor.o
  CC      qapi/qmp-registry.o
  CC      qapi/qmp-dispatch.o
  CC      qapi/string-input-visitor.o
  CC      qapi/string-output-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/qint.o
  CC      qobject/qstring.o
  CC      qobject/qdict.o
  CC      qobject/qlist.o
  CC      qobject/qfloat.o
  CC      qobject/qbool.o
  CC      qobject/qjson.o
  CC      qobject/qobject.o
  CC      qobject/json-lexer.o
  CC      qobject/json-streamer.o
  CC      qobject/json-parser.o
  GEN     trace/generated-tracers.c
  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/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/bitmap.o
  CC      util/bitops.o
  CC      util/hbitmap.o
  CC      util/fifo8.o
  CC      util/acl.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/hexdump.o
  CC      util/crc32c.o
  CC      util/uuid.o
  CC      util/throttle.o
  CC      util/getauxval.o
  CC      util/readline.o
  CC      util/rfifolock.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/qdist.o
  CC      util/qht.o
  CC      util/range.o
  CC      crypto/pbkdf-stub.o
  CC      stubs/arch-query-cpu-def.o
  CC      stubs/arch-query-cpu-model-comparison.o
  CC      stubs/arch-query-cpu-model-expansion.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/fdset-add-fd.o
  CC      stubs/fdset-find-fd.o
  CC      stubs/fdset-get-fd.o
  CC      stubs/fdset-remove-fd.o
  CC      stubs/gdbstub.o
  CC      stubs/get-fd.o
  CC      stubs/get-next-serial.o
  CC      stubs/get-vm-name.o
  CC      stubs/is-daemonized.o
  CC      stubs/iothread-lock.o
  CC      stubs/migr-blocker.o
  CC      stubs/machine-init-done.o
  CC      stubs/mon-is-qmp.o
  CC      stubs/mon-printf.o
  CC      stubs/monitor-init.o
  CC      stubs/notify-event.o
  CC      stubs/qtest.o
  CC      stubs/replay.o
  CC      stubs/replay-user.o
  CC      stubs/reset.o
  CC      stubs/runstate-check.o
  CC      stubs/set-fd-handler.o
  CC      stubs/slirp.o
  CC      stubs/sysbus.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/cpus.o
  CC      stubs/kvm.o
  CC      stubs/qmp_pc_dimm_device_list.o
  CC      stubs/target-monitor-defs.o
  CC      stubs/target-get-monitor-def.o
  CC      stubs/vhost.o
  CC      stubs/iohandler.o
  CC      stubs/smbios_type_38.o
  CC      stubs/ipmi.o
  CC      stubs/pc_madt_cpu_entry.o
  GEN     qemu-img-cmds.h
  CC      async.o
  CC      thread-pool.o
  CC      block.o
  CC      blockjob.o
  CC      main-loop.o
  CC      iohandler.o
  CC      qemu-timer.o
  CC      aio-win32.o
  CC      qemu-io-cmds.o
  CC      replication.o
  CC      block/raw_bsd.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/dmg.o
  CC      block/vvfat.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/qed.o
  CC      block/qed-gencb.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/quorum.o
  CC      block/vhdx-log.o
  CC      block/parallels.o
  CC      block/blkdebug.o
  CC      block/blkverify.o
  CC      block/blkreplay.o
  CC      block/snapshot.o
  CC      block/block-backend.o
  CC      block/qapi.o
  CC      block/raw-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/crypto.o
  CC      nbd/server.o
  CC      nbd/client.o
  CC      nbd/common.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/aes.o
  CC      crypto/desrfb.o
  CC      crypto/cipher.o
  CC      crypto/tlscreds.o
  CC      crypto/tlscredsanon.o
  CC      crypto/tlscredsx509.o
  CC      crypto/tlssession.o
  CC      crypto/secret.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/block.o
  CC      crypto/xts.o
  CC      crypto/block-qcow.o
  CC      crypto/block-luks.o
  CC      io/channel.o
  CC      io/channel-buffer.o
  CC      io/channel-command.o
  CC      io/channel-file.o
  CC      io/channel-socket.o
  CC      io/channel-tls.o
  CC      io/channel-websock.o
  CC      io/channel-watch.o
  CC      io/channel-util.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      iothread.o
  CC      qdev-monitor.o
  CC      device-hotplug.o
  CC      os-win32.o
  CC      qemu-char.o
  CC      page_cache.o
  CC      accel.o
  CC      bt-host.o
  CC      bt-vhci.o
  CC      dma-helpers.o
  CC      vl.o
  CC      tpm.o
  CC      device_tree.o
  GEN     qmp-marshal.c
  CC      qmp.o
  CC      hmp.o
  CC      tcg-runtime.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/audio_win_int.o
  CC      audio/wavcapture.o
  CC      backends/rng.o
  CC      backends/rng-egd.o
  CC      backends/msmouse.o
  CC      backends/testdev.o
  CC      backends/tpm.o
  CC      backends/hostmem.o
  CC      backends/hostmem-ram.o
  CC      block/stream.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/memory_hotplug_acpi_table.o
  CC      hw/acpi/cpu.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/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/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/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/fw-path-provider.o
  CC      hw/core/irq.o
  CC      hw/core/hotplug.o
  CC      hw/core/ptimer.o
  CC      hw/core/sysbus.o
  CC      hw/core/machine.o
  CC      hw/core/null-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/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/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/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/vmmouse.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/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/isa-bus.o
  CC      hw/isa/apm.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/debugexit.o
  CC      hw/misc/sga.o
  CC      hw/misc/pc-testdev.o
  CC      hw/misc/pci-testdev.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/allwinner_emac.o
  CC      hw/net/imx_fec.o
  CC      hw/net/cadence_gem.o
  CC      hw/net/stellaris_enet.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/fw_cfg.o
  CC      hw/pci-bridge/pci_bridge_dev.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/pci_bridge.o
  CC      hw/pci/msix.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_aer.o
  CC      hw/pci/pcie_port.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/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/timer/arm_timer.o
  CC      hw/timer/arm_mptimer.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/tpm/tpm_tis.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.o
  CC      hw/usb/hcd-ehci-pci.o
  CC      hw/usb/hcd-ehci-sysbus.o
  CC      hw/usb/hcd-xhci.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/watchdog/watchdog.o
  CC      hw/watchdog/wdt_i6300esb.o
  CC      hw/watchdog/wdt_ib700.o
  CC      migration/migration.o
  CC      migration/socket.o
  CC      migration/fd.o
  CC      migration/exec.o
  CC      migration/tls.o
  CC      migration/vmstate.o
  CC      migration/qemu-file.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/tap-win32.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      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      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/sbuf.o
  CC      slirp/tcp_input.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      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/x_keymap.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      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
  CC      qga/vss-win32.o
  CC      qga/qapi-generated/qga-qapi-types.o
  AS      optionrom/multiboot.o
  CC      qga/qapi-generated/qga-qapi-visit.o
  AS      optionrom/linuxboot.o
  CC      optionrom/linuxboot_dma.o
  AS      optionrom/kvmvapic.o
  BUILD   optionrom/multiboot.img
  CC      qga/qapi-generated/qga-qmp-marshal.o
  CC      qmp-introspect.o
  BUILD   optionrom/linuxboot.img
  CC      qapi-types.o
  BUILD   optionrom/kvmvapic.img
  CC      qapi-visit.o
  BUILD   optionrom/multiboot.raw
  CC      qapi-event.o
  BUILD   optionrom/linuxboot.raw
  BUILD   optionrom/linuxboot_dma.img
  BUILD   optionrom/kvmvapic.raw
  BUILD   optionrom/linuxboot_dma.raw
  AR      libqemustub.a
  CC      qemu-img.o
  SIGN    optionrom/multiboot.bin
  CC      qmp-marshal.o
  SIGN    optionrom/linuxboot_dma.bin
  SIGN    optionrom/kvmvapic.bin
  SIGN    optionrom/linuxboot.bin
  CC      trace/generated-tracers.o
  AR      libqemuutil.a
  LINK    qemu-ga.exe
  LINK    qemu-img.exe
  LINK    qemu-io.exe
  GEN     x86_64-softmmu/hmp-commands.h
  GEN     x86_64-softmmu/hmp-commands-info.h
  GEN     x86_64-softmmu/config-target.h
  CC      x86_64-softmmu/exec.o
  CC      x86_64-softmmu/translate-all.o
  CC      x86_64-softmmu/cpu-exec.o
  CC      x86_64-softmmu/translate-common.o
  CC      x86_64-softmmu/cpu-exec-common.o
  CC      x86_64-softmmu/tcg/tcg.o
  CC      x86_64-softmmu/tcg/optimize.o
  CC      x86_64-softmmu/tcg/tcg-common.o
  CC      x86_64-softmmu/fpu/softfloat.o
  CC      x86_64-softmmu/kvm-stub.o
  CC      x86_64-softmmu/arch_init.o
  CC      x86_64-softmmu/disas.o
  CC      x86_64-softmmu/monitor.o
  CC      x86_64-softmmu/tcg/tcg-op.o
  CC      x86_64-softmmu/cpus.o
  CC      x86_64-softmmu/gdbstub.o
  CC      x86_64-softmmu/balloon.o
  GEN     aarch64-softmmu/hmp-commands.h
  GEN     aarch64-softmmu/hmp-commands-info.h
  GEN     aarch64-softmmu/config-target.h
  CC      aarch64-softmmu/exec.o
  CC      aarch64-softmmu/translate-all.o
  CC      aarch64-softmmu/cpu-exec.o
  CC      x86_64-softmmu/ioport.o
  CC      aarch64-softmmu/translate-common.o
  CC      aarch64-softmmu/cpu-exec-common.o
  CC      x86_64-softmmu/numa.o
/tmp/qemu-test/src/exec.c:66:23: fatal error: sys/ioctl.h: No such file or directory
 #include <sys/ioctl.h>
                       ^
compilation terminated.
/tmp/qemu-test/src/rules.mak:60: recipe for target 'exec.o' failed
make[1]: *** [exec.o] Error 1
make[1]: *** Waiting for unfinished jobs....
  CC      aarch64-softmmu/tcg/tcg.o
  CC      aarch64-softmmu/tcg/tcg-op.o
  CC      aarch64-softmmu/tcg/optimize.o
  CC      aarch64-softmmu/tcg/tcg-common.o
  CC      aarch64-softmmu/fpu/softfloat.o
/tmp/qemu-test/src/exec.c:66:23: fatal error: sys/ioctl.h: No such file or directory
 #include <sys/ioctl.h>
                       ^
compilation terminated.
  CC      aarch64-softmmu/disas.o
/tmp/qemu-test/src/rules.mak:60: recipe for target 'exec.o' failed
make[1]: *** [exec.o] Error 1
make[1]: *** Waiting for unfinished jobs....
Makefile:202: recipe for target 'subdir-x86_64-softmmu' failed
make: *** [subdir-x86_64-softmmu] Error 2
make: *** Waiting for unfinished jobs....
Makefile:202: recipe for target 'subdir-aarch64-softmmu' failed
make: *** [subdir-aarch64-softmmu] Error 2
tests/docker/Makefile.include:112: recipe for target 'docker-run' failed
make[1]: *** [docker-run] Error 2
make[1]: Leaving directory '/var/tmp/patchew-tester-tmp-7squmlt9/src'
tests/docker/Makefile.include:143: recipe for target 'docker-run-test-mingw@fedora' failed
make: *** [docker-run-test-mingw@fedora] Error 2
=== 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
Igor Mammedov Oct. 20, 2016, 12:34 p.m. UTC | #2 
On Thu, 20 Oct 2016 14:13:01 +0800
Haozhong Zhang <haozhong.zhang@intel.com> wrote:

> If a file is used as the backend of memory-backend-file and its size is
> not identical to the property 'size', the file will be truncated. For a
> file used as the backend of vNVDIMM, its data is expected to be
> persistent and the truncation may corrupt the existing data.
I wonder if it's possible just skip 'size' property in your case instead
'notrunc' property. That way if size is not present one'd get actual size
using get_file_size() and set 'size' to it?
And if 'size' is provided and 'size' != file_size then error out.

> 
> A property 'notrunc' is added to memory-backend-file to allow users to
> control the truncation. If 'notrunc' is on, QEMU will not truncate the
> backend file and require the property 'size' is not larger than the file
> size. If 'notrunc' is off, QEMU will behave as before.
[...]

>  
>  #ifdef __linux__
> +static uint64_t get_file_size(const char *path, Error **errp)
Maybe QEMU laredy has an utility to do it that could be shared,
CCing block maintainers.

> +{
> +    int fd;
> +    struct stat st;
> +    uint64_t size = 0;
> +    Error *local_err = NULL;
> +
> +    fd = qemu_open(path, O_RDONLY);
> +    if (fd < 0) {
> +        error_setg(&local_err, "cannot open file");
error_setg_errno
> +        goto out;
> +    }
> +
> +    if (stat(path, &st)) {
fstat()

> +        error_setg(&local_err, "cannot get file stat");
error_setg_errno
> +        goto out_fclose;
> +    }
> +
> +    switch (st.st_mode & S_IFMT) {
> +    case S_IFREG:
> +        size = st.st_size;
> +        break;
> +
> +    case S_IFBLK:
> +        if (ioctl(fd, BLKGETSIZE64, &size)) {
compilation might fail on platforms without  BLKGETSIZE64,


> +            error_setg(&local_err, "cannot get size of block device");
error_setg_errno
> +            size = 0;
> +        }
> +        break;
> +
> +    default:
> +        error_setg(&local_err,
> +                   "only block device on Linux and regular file are supported");
what about huge page usecase, would it fall right here fail?

> +    }
> +
> + out_fclose:
> +    close(fd);
> + out:
> +    error_propagate(errp, local_err);
> +    return size;
> +}
> +
[...]
Haozhong Zhang Oct. 20, 2016, 1:11 p.m. UTC | #3 
On 10/20/16 14:34 +0200, Igor Mammedov wrote:
>On Thu, 20 Oct 2016 14:13:01 +0800
>Haozhong Zhang <haozhong.zhang@intel.com> wrote:
>
>> If a file is used as the backend of memory-backend-file and its size is
>> not identical to the property 'size', the file will be truncated. For a
>> file used as the backend of vNVDIMM, its data is expected to be
>> persistent and the truncation may corrupt the existing data.
>I wonder if it's possible just skip 'size' property in your case instead
>'notrunc' property. That way if size is not present one'd get actual size
>using get_file_size() and set 'size' to it?
>And if 'size' is provided and 'size' != file_size then error out.
>

I don't know how this can be implemented in QEMU. Specially, how does
the memory-backend-file know it's used for vNVDIMM, so that it can
skip the 'size' property?

Besides, it cannot cover the case that only a part of file is used as
the backend of vNVDIMM, which is allowed by the current implementation.

>>
>> A property 'notrunc' is added to memory-backend-file to allow users to
>> control the truncation. If 'notrunc' is on, QEMU will not truncate the
>> backend file and require the property 'size' is not larger than the file
>> size. If 'notrunc' is off, QEMU will behave as before.
>[...]
>
>>
>>  #ifdef __linux__
>> +static uint64_t get_file_size(const char *path, Error **errp)
>Maybe QEMU laredy has an utility to do it that could be shared,
>CCing block maintainers.
>
>> +{
>> +    int fd;
>> +    struct stat st;
>> +    uint64_t size = 0;
>> +    Error *local_err = NULL;
>> +
>> +    fd = qemu_open(path, O_RDONLY);
>> +    if (fd < 0) {
>> +        error_setg(&local_err, "cannot open file");
>error_setg_errno
>> +        goto out;
>> +    }
>> +
>> +    if (stat(path, &st)) {
>fstat()

will change

>
>> +        error_setg(&local_err, "cannot get file stat");
>error_setg_errno

ditto

>> +        goto out_fclose;
>> +    }
>> +
>> +    switch (st.st_mode & S_IFMT) {
>> +    case S_IFREG:
>> +        size = st.st_size;
>> +        break;
>> +
>> +    case S_IFBLK:
>> +        if (ioctl(fd, BLKGETSIZE64, &size)) {
>compilation might fail on platforms without  BLKGETSIZE64,
>

BLKGETSIZE64 was first introduced by linux kernel 2.4.10. For these
linux specific code, does QEMU have any assumption for the least
kernel version? If no, I'll fallback to BLKGETSIZE if BLKGETSIZE64
fails.

>
>> +            error_setg(&local_err, "cannot get size of block device");
>error_setg_errno
>> +            size = 0;
>> +        }
>> +        break;
>> +
>> +    default:
>> +        error_setg(&local_err,
>> +                   "only block device on Linux and regular file are supported");
>what about huge page usecase, would it fall right here fail?
>

Yes, it will fail. notrunc is not necessary for the huge page case. I
could report more messages here, like "remove notrunc if hugetlbfs is used".

>> +    }
>> +
>> + out_fclose:
>> +    close(fd);
>> + out:
>> +    error_propagate(errp, local_err);
>> +    return size;
>> +}
>> +
>[...]
>

Thank you for the review!

Haozhong
Eduardo Habkost Oct. 20, 2016, 1:21 p.m. UTC | #4 
On Thu, Oct 20, 2016 at 02:34:12PM +0200, Igor Mammedov wrote:
> On Thu, 20 Oct 2016 14:13:01 +0800
> Haozhong Zhang <haozhong.zhang@intel.com> wrote:
> 
> > If a file is used as the backend of memory-backend-file and its size is
> > not identical to the property 'size', the file will be truncated. For a
> > file used as the backend of vNVDIMM, its data is expected to be
> > persistent and the truncation may corrupt the existing data.
> I wonder if it's possible just skip 'size' property in your case instead
> 'notrunc' property. That way if size is not present one'd get actual size
> using get_file_size() and set 'size' to it?
> And if 'size' is provided and 'size' != file_size then error out.

I think it is valid to start with a zero-size file and then let
QEMU extend it. But I agree we should: 1) make 'size' optional as
you suggested; 2) never truncate the file to a smaller size.
Daniel P. Berrangé Oct. 20, 2016, 1:27 p.m. UTC | #5 
On Thu, Oct 20, 2016 at 02:34:12PM +0200, Igor Mammedov wrote:
> On Thu, 20 Oct 2016 14:13:01 +0800
> Haozhong Zhang <haozhong.zhang@intel.com> wrote:
> 
> > If a file is used as the backend of memory-backend-file and its size is
> > not identical to the property 'size', the file will be truncated. For a
> > file used as the backend of vNVDIMM, its data is expected to be
> > persistent and the truncation may corrupt the existing data.
> I wonder if it's possible just skip 'size' property in your case instead
> 'notrunc' property. That way if size is not present one'd get actual size
> using get_file_size() and set 'size' to it?
> And if 'size' is provided and 'size' != file_size then error out.

That works if you always want to expose the entire file, but if you
intentionally only want to expose a subset you would still want
to set a size (and possibly offset too) and avoid the truncation


Regards,
Daniel
Haozhong Zhang Oct. 20, 2016, 1:33 p.m. UTC | #6 
On 10/20/16 11:21 -0200, Eduardo Habkost wrote:
>On Thu, Oct 20, 2016 at 02:34:12PM +0200, Igor Mammedov wrote:
>> On Thu, 20 Oct 2016 14:13:01 +0800
>> Haozhong Zhang <haozhong.zhang@intel.com> wrote:
>>
>> > If a file is used as the backend of memory-backend-file and its size is
>> > not identical to the property 'size', the file will be truncated. For a
>> > file used as the backend of vNVDIMM, its data is expected to be
>> > persistent and the truncation may corrupt the existing data.
>> I wonder if it's possible just skip 'size' property in your case instead
>> 'notrunc' property. That way if size is not present one'd get actual size
>> using get_file_size() and set 'size' to it?
>> And if 'size' is provided and 'size' != file_size then error out.
>
>I think it is valid to start with a zero-size file and then let
>QEMU extend it.

For vNVDIMM, extending from zero-size file can be valid when a file is
first used. However, it's not valid for the second and following use
of the same file.

>But I agree we should: 1) make 'size' optional as
>you suggested; 2) never truncate the file to a smaller size.
>

I will add another patch for this. Is there any way in QEMU to decide
whether a memory-backend-file object is used for vNVDIMM when the
object is being created? Or 'size' can be optional for all kinds of
usages?

Thanks,
Haozhong
Eduardo Habkost Oct. 20, 2016, 1:34 p.m. UTC | #7 
On Thu, Oct 20, 2016 at 09:11:38PM +0800, Haozhong Zhang wrote:
> On 10/20/16 14:34 +0200, Igor Mammedov wrote:
> > On Thu, 20 Oct 2016 14:13:01 +0800
> > Haozhong Zhang <haozhong.zhang@intel.com> wrote:
> > 
> > > If a file is used as the backend of memory-backend-file and its size is
> > > not identical to the property 'size', the file will be truncated. For a
> > > file used as the backend of vNVDIMM, its data is expected to be
> > > persistent and the truncation may corrupt the existing data.
> > I wonder if it's possible just skip 'size' property in your case instead
> > 'notrunc' property. That way if size is not present one'd get actual size
> > using get_file_size() and set 'size' to it?
> > And if 'size' is provided and 'size' != file_size then error out.
> > 
> 
> I don't know how this can be implemented in QEMU. Specially, how does
> the memory-backend-file know it's used for vNVDIMM, so that it can
> skip the 'size' property?
> 
> Besides, it cannot cover the case that only a part of file is used as
> the backend of vNVDIMM, which is allowed by the current implementation.

I see 3 possible cases:

* If desired RAM size is the same as file size, 'size' can be
  optional.
* If desired RAM size is smaller than file size, we don't need to
  truncate the file at all. In this case, we could even use the
  size specified in the frontend config options (-numa and/or
  -m), instead of requiring size to be specified on the backend
  object.
* If desired RAM size is larger than file size, the only option
  is to specify size explicitly on the backend object and extend
  it using ftruncate().

None of those cases would require a new option.
Eduardo Habkost Oct. 20, 2016, 1:40 p.m. UTC | #8 
On Thu, Oct 20, 2016 at 02:27:06PM +0100, Daniel P. Berrange wrote:
> On Thu, Oct 20, 2016 at 02:34:12PM +0200, Igor Mammedov wrote:
> > On Thu, 20 Oct 2016 14:13:01 +0800
> > Haozhong Zhang <haozhong.zhang@intel.com> wrote:
> > 
> > > If a file is used as the backend of memory-backend-file and its size is
> > > not identical to the property 'size', the file will be truncated. For a
> > > file used as the backend of vNVDIMM, its data is expected to be
> > > persistent and the truncation may corrupt the existing data.
> > I wonder if it's possible just skip 'size' property in your case instead
> > 'notrunc' property. That way if size is not present one'd get actual size
> > using get_file_size() and set 'size' to it?
> > And if 'size' is provided and 'size' != file_size then error out.
> 
> That works if you always want to expose the entire file, but if you
> intentionally only want to expose a subset you would still want
> to set a size (and possibly offset too) and avoid the truncation

In this case, if you don't want truncation at all you shouldn't
need to set a size on the backend object. Then QEMU could simply
use the size specified in the frontend config (i.e. from -numa
and/or -m).
Igor Mammedov Oct. 20, 2016, 1:42 p.m. UTC | #9 
On Thu, 20 Oct 2016 21:11:38 +0800
Haozhong Zhang <haozhong.zhang@intel.com> wrote:

> On 10/20/16 14:34 +0200, Igor Mammedov wrote:
> >On Thu, 20 Oct 2016 14:13:01 +0800
> >Haozhong Zhang <haozhong.zhang@intel.com> wrote:
> >  
> >> If a file is used as the backend of memory-backend-file and its size is
> >> not identical to the property 'size', the file will be truncated. For a
> >> file used as the backend of vNVDIMM, its data is expected to be
> >> persistent and the truncation may corrupt the existing data.  
> >I wonder if it's possible just skip 'size' property in your case instead
> >'notrunc' property. That way if size is not present one'd get actual size
> >using get_file_size() and set 'size' to it?
> >And if 'size' is provided and 'size' != file_size then error out.
> >  
> 
> I don't know how this can be implemented in QEMU. Specially, how does
> the memory-backend-file know it's used for vNVDIMM, so that it can
> skip the 'size' property?
Does memory-backend-file needs to know that it's used by NVDIMM?
Looking at nvdimm_realize it doesn't as it's assumes 
  hostemem_size == pmem_size + label_size

I'd make hostmem_file.size optional and take size from file
and if 'size' is specified explictly require it to mach file size.
It's generic and has nothing to do with nvdimm.

 
> Besides, it cannot cover the case that only a part of file is used as
> the backend of vNVDIMM, which is allowed by the current implementation.
and which hasn't ever worked due to truncation this patch tries to fix.


> 
> >>
> >> A property 'notrunc' is added to memory-backend-file to allow users to
> >> control the truncation. If 'notrunc' is on, QEMU will not truncate the
> >> backend file and require the property 'size' is not larger than the file
> >> size. If 'notrunc' is off, QEMU will behave as before.  
> >[...]
> >  
> >>
> >>  #ifdef __linux__
> >> +static uint64_t get_file_size(const char *path, Error **errp)  
> >Maybe QEMU laredy has an utility to do it that could be shared,
> >CCing block maintainers.
> >  
> >> +{
> >> +    int fd;
> >> +    struct stat st;
> >> +    uint64_t size = 0;
> >> +    Error *local_err = NULL;
> >> +
> >> +    fd = qemu_open(path, O_RDONLY);
> >> +    if (fd < 0) {
> >> +        error_setg(&local_err, "cannot open file");  
> >error_setg_errno  
> >> +        goto out;
> >> +    }
> >> +
> >> +    if (stat(path, &st)) {  
> >fstat()  
> 
> will change
> 
> >  
> >> +        error_setg(&local_err, "cannot get file stat");  
> >error_setg_errno  
> 
> ditto
> 
> >> +        goto out_fclose;
> >> +    }
> >> +
> >> +    switch (st.st_mode & S_IFMT) {
> >> +    case S_IFREG:
> >> +        size = st.st_size;
> >> +        break;
> >> +
> >> +    case S_IFBLK:
> >> +        if (ioctl(fd, BLKGETSIZE64, &size)) {  
> >compilation might fail on platforms without  BLKGETSIZE64,
> >  
> 
> BLKGETSIZE64 was first introduced by linux kernel 2.4.10. For these
> linux specific code, does QEMU have any assumption for the least
> kernel version? If no, I'll fallback to BLKGETSIZE if BLKGETSIZE64
> fails.
> 
> >  
> >> +            error_setg(&local_err, "cannot get size of block device");  
> >error_setg_errno  
> >> +            size = 0;
> >> +        }
> >> +        break;
> >> +
> >> +    default:
> >> +        error_setg(&local_err,
> >> +                   "only block device on Linux and regular file are supported");  
> >what about huge page usecase, would it fall right here fail?
> >  
> 
> Yes, it will fail. notrunc is not necessary for the huge page case. I
> could report more messages here, like "remove notrunc if hugetlbfs is used".
it's better to skip this check in case of hugetlbfs so user won't have to do anything

 
> >> +    }
> >> +
> >> + out_fclose:
> >> +    close(fd);
> >> + out:
> >> +    error_propagate(errp, local_err);
> >> +    return size;
> >> +}
> >> +  
> >[...]
> >  
> 
> Thank you for the review!
> 
> Haozhong
>
Eduardo Habkost Oct. 20, 2016, 1:47 p.m. UTC | #10 
On Thu, Oct 20, 2016 at 09:33:53PM +0800, Haozhong Zhang wrote:
> On 10/20/16 11:21 -0200, Eduardo Habkost wrote:
> > On Thu, Oct 20, 2016 at 02:34:12PM +0200, Igor Mammedov wrote:
> > > On Thu, 20 Oct 2016 14:13:01 +0800
> > > Haozhong Zhang <haozhong.zhang@intel.com> wrote:
> > > 
> > > > If a file is used as the backend of memory-backend-file and its size is
> > > > not identical to the property 'size', the file will be truncated. For a
> > > > file used as the backend of vNVDIMM, its data is expected to be
> > > > persistent and the truncation may corrupt the existing data.
> > > I wonder if it's possible just skip 'size' property in your case instead
> > > 'notrunc' property. That way if size is not present one'd get actual size
> > > using get_file_size() and set 'size' to it?
> > > And if 'size' is provided and 'size' != file_size then error out.
> > 
> > I think it is valid to start with a zero-size file and then let
> > QEMU extend it.
> 
> For vNVDIMM, extending from zero-size file can be valid when a file is
> first used. However, it's not valid for the second and following use
> of the same file.
> 
> > But I agree we should: 1) make 'size' optional as
> > you suggested; 2) never truncate the file to a smaller size.
> > 
> 
> I will add another patch for this. Is there any way in QEMU to decide
> whether a memory-backend-file object is used for vNVDIMM when the
> object is being created? Or 'size' can be optional for all kinds of
> usages?

I believe 'size' can be optional for all usage, because at the
moment the memory allocation code asks the backend for a memory
region, it is supposed to know desired RAM size from the frontend
configuration (-numa, -m, or "size" property of pc-dimm).
Haozhong Zhang Oct. 20, 2016, 1:47 p.m. UTC | #11 
On 10/20/16 11:34 -0200, Eduardo Habkost wrote:
>On Thu, Oct 20, 2016 at 09:11:38PM +0800, Haozhong Zhang wrote:
>> On 10/20/16 14:34 +0200, Igor Mammedov wrote:
>> > On Thu, 20 Oct 2016 14:13:01 +0800
>> > Haozhong Zhang <haozhong.zhang@intel.com> wrote:
>> >
>> > > If a file is used as the backend of memory-backend-file and its size is
>> > > not identical to the property 'size', the file will be truncated. For a
>> > > file used as the backend of vNVDIMM, its data is expected to be
>> > > persistent and the truncation may corrupt the existing data.
>> > I wonder if it's possible just skip 'size' property in your case instead
>> > 'notrunc' property. That way if size is not present one'd get actual size
>> > using get_file_size() and set 'size' to it?
>> > And if 'size' is provided and 'size' != file_size then error out.
>> >
>>
>> I don't know how this can be implemented in QEMU. Specially, how does
>> the memory-backend-file know it's used for vNVDIMM, so that it can
>> skip the 'size' property?
>>
>> Besides, it cannot cover the case that only a part of file is used as
>> the backend of vNVDIMM, which is allowed by the current implementation.
>
>I see 3 possible cases:
>
>* If desired RAM size is the same as file size, 'size' can be
>  optional.
>* If desired RAM size is smaller than file size, we don't need to
>  truncate the file at all. In this case, we could even use the
>  size specified in the frontend config options (-numa and/or
>  -m), instead of requiring size to be specified on the backend
>  object.
>* If desired RAM size is larger than file size, the only option
>  is to specify size explicitly on the backend object and extend
>  it using ftruncate().
>
>None of those cases would require a new option.
>

One reason I added an additional notrunc is to make it to possible to
preserve the previous truncation behavior (when nontrunc is
off). However, as you listed here, it's not necessary to preserve the
previous truncation behavior, so notrunc is not necessary neither.

Haozhong
Igor Mammedov Oct. 20, 2016, 1:47 p.m. UTC | #12 
On Thu, 20 Oct 2016 21:33:53 +0800
Haozhong Zhang <haozhong.zhang@intel.com> wrote:

> On 10/20/16 11:21 -0200, Eduardo Habkost wrote:
> >On Thu, Oct 20, 2016 at 02:34:12PM +0200, Igor Mammedov wrote:  
> >> On Thu, 20 Oct 2016 14:13:01 +0800
> >> Haozhong Zhang <haozhong.zhang@intel.com> wrote:
> >>  
> >> > If a file is used as the backend of memory-backend-file and its size is
> >> > not identical to the property 'size', the file will be truncated. For a
> >> > file used as the backend of vNVDIMM, its data is expected to be
> >> > persistent and the truncation may corrupt the existing data.  
> >> I wonder if it's possible just skip 'size' property in your case instead
> >> 'notrunc' property. That way if size is not present one'd get actual size
> >> using get_file_size() and set 'size' to it?
> >> And if 'size' is provided and 'size' != file_size then error out.  
> >
> >I think it is valid to start with a zero-size file and then let
> >QEMU extend it.  
> 
> For vNVDIMM, extending from zero-size file can be valid when a file is
> first used. However, it's not valid for the second and following use
> of the same file.
I'd avoid 0 sized backend files and enforce non 0 size value
with exact match to actual file size. i.e. let mgmt side take care of
proper backend file allocation.

> 
> >But I agree we should: 1) make 'size' optional as
> >you suggested; 2) never truncate the file to a smaller size.
> >  
> 
> I will add another patch for this. Is there any way in QEMU to decide
> whether a memory-backend-file object is used for vNVDIMM when the
> object is being created? Or 'size' can be optional for all kinds of
> usages?
> 
> Thanks,
> Haozhong
Igor Mammedov Oct. 20, 2016, 1:54 p.m. UTC | #13 
On Thu, 20 Oct 2016 14:27:06 +0100
"Daniel P. Berrange" <berrange@redhat.com> wrote:

> On Thu, Oct 20, 2016 at 02:34:12PM +0200, Igor Mammedov wrote:
> > On Thu, 20 Oct 2016 14:13:01 +0800
> > Haozhong Zhang <haozhong.zhang@intel.com> wrote:
> >   
> > > If a file is used as the backend of memory-backend-file and its size is
> > > not identical to the property 'size', the file will be truncated. For a
> > > file used as the backend of vNVDIMM, its data is expected to be
> > > persistent and the truncation may corrupt the existing data.  
> > I wonder if it's possible just skip 'size' property in your case instead
> > 'notrunc' property. That way if size is not present one'd get actual size
> > using get_file_size() and set 'size' to it?
> > And if 'size' is provided and 'size' != file_size then error out.  
> 
> That works if you always want to expose the entire file, but if you
> intentionally only want to expose a subset you would still want
> to set a size (and possibly offset too) and avoid the truncation
we don't do it now and probably shouldn't do it at all to keep interface sane.
Idea of file backend has been simple:
 here if file to map and let frontend to use/partition it as it deems fit.

in case of NVDIMM frontend might partition backend file into data
and label areas (as it's implemented now).

> 
> 
> Regards,
> Daniel
Kevin Wolf Oct. 20, 2016, 1:55 p.m. UTC | #14 
Am 20.10.2016 um 14:34 hat Igor Mammedov geschrieben:
> >  #ifdef __linux__
> > +static uint64_t get_file_size(const char *path, Error **errp)
> Maybe QEMU laredy has an utility to do it that could be shared,
> CCing block maintainers.

We have quite a bit of code for determining the right size of a file
(including block devices) on different platforms and devices. See the
.bdrv_getlength implementations in raw-posix.c and raw-win32.c.

However, none of them are made for consumption outside the block layer.

Kevin
Eduardo Habkost Oct. 20, 2016, 1:56 p.m. UTC | #15 
On Thu, Oct 20, 2016 at 03:42:15PM +0200, Igor Mammedov wrote:
> On Thu, 20 Oct 2016 21:11:38 +0800
> Haozhong Zhang <haozhong.zhang@intel.com> wrote:
> 
> > On 10/20/16 14:34 +0200, Igor Mammedov wrote:
> > >On Thu, 20 Oct 2016 14:13:01 +0800
> > >Haozhong Zhang <haozhong.zhang@intel.com> wrote:
> > >  
> > >> If a file is used as the backend of memory-backend-file and its size is
> > >> not identical to the property 'size', the file will be truncated. For a
> > >> file used as the backend of vNVDIMM, its data is expected to be
> > >> persistent and the truncation may corrupt the existing data.  
> > >I wonder if it's possible just skip 'size' property in your case instead
> > >'notrunc' property. That way if size is not present one'd get actual size
> > >using get_file_size() and set 'size' to it?
> > >And if 'size' is provided and 'size' != file_size then error out.
> > >  
> > 
> > I don't know how this can be implemented in QEMU. Specially, how does
> > the memory-backend-file know it's used for vNVDIMM, so that it can
> > skip the 'size' property?
> Does memory-backend-file needs to know that it's used by NVDIMM?
> Looking at nvdimm_realize it doesn't as it's assumes 
>   hostemem_size == pmem_size + label_size
> 
> I'd make hostmem_file.size optional and take size from file
> and if 'size' is specified explictly require it to mach file size.
> It's generic and has nothing to do with nvdimm.

We can take size from file, or take size from the
host_memory_backend_get_memory() callers.

Enumerating all sizes that QEMU can use as input:

A) Backend file size
B) memory backend "size" option
C) frontend-provided size (-numa size, -m, or pc-dimm "size"
    property)

My suggestion is:
* B should be optional.
* If B is omitted, we should never truncate the file to a smaller
  size.
* If B is omitted, we can use C as the size when mapping the
  file.
* If B is omitted, and C > A, maybe we could use ftruncate() to
  extend the file to make users happy. But I'm not sure we
  should (I think B should be the only option that cause
  truncation).
* If we want to make C optional on some cases, we could use A if
  B is omitted.

Does that make sense?
Haozhong Zhang Oct. 20, 2016, 1:56 p.m. UTC | #16 
On 10/20/16 15:42 +0200, Igor Mammedov wrote:
>On Thu, 20 Oct 2016 21:11:38 +0800
>Haozhong Zhang <haozhong.zhang@intel.com> wrote:
>
>> On 10/20/16 14:34 +0200, Igor Mammedov wrote:
>> >On Thu, 20 Oct 2016 14:13:01 +0800
>> >Haozhong Zhang <haozhong.zhang@intel.com> wrote:
>> >
>> >> If a file is used as the backend of memory-backend-file and its size is
>> >> not identical to the property 'size', the file will be truncated. For a
>> >> file used as the backend of vNVDIMM, its data is expected to be
>> >> persistent and the truncation may corrupt the existing data.
>> >I wonder if it's possible just skip 'size' property in your case instead
>> >'notrunc' property. That way if size is not present one'd get actual size
>> >using get_file_size() and set 'size' to it?
>> >And if 'size' is provided and 'size' != file_size then error out.
>> >
>>
>> I don't know how this can be implemented in QEMU. Specially, how does
>> the memory-backend-file know it's used for vNVDIMM, so that it can
>> skip the 'size' property?
>Does memory-backend-file needs to know that it's used by NVDIMM?
>Looking at nvdimm_realize it doesn't as it's assumes
>  hostemem_size == pmem_size + label_size
>
>I'd make hostmem_file.size optional and take size from file
>and if 'size' is specified explictly require it to mach file size.
>It's generic and has nothing to do with nvdimm.
>

I thought you meant to make 'size' optional only if it's used for
vNVDIMM. Now I understand it's a general change regardless of the
frontend.

>
>> Besides, it cannot cover the case that only a part of file is used as
>> the backend of vNVDIMM, which is allowed by the current implementation.
>and which hasn't ever worked due to truncation this patch tries to fix.
>
>
>>
>> >>
>> >> A property 'notrunc' is added to memory-backend-file to allow users to
>> >> control the truncation. If 'notrunc' is on, QEMU will not truncate the
>> >> backend file and require the property 'size' is not larger than the file
>> >> size. If 'notrunc' is off, QEMU will behave as before.
>> >[...]
>> >
>> >>
>> >>  #ifdef __linux__
>> >> +static uint64_t get_file_size(const char *path, Error **errp)
>> >Maybe QEMU laredy has an utility to do it that could be shared,
>> >CCing block maintainers.
>> >
>> >> +{
>> >> +    int fd;
>> >> +    struct stat st;
>> >> +    uint64_t size = 0;
>> >> +    Error *local_err = NULL;
>> >> +
>> >> +    fd = qemu_open(path, O_RDONLY);
>> >> +    if (fd < 0) {
>> >> +        error_setg(&local_err, "cannot open file");
>> >error_setg_errno
>> >> +        goto out;
>> >> +    }
>> >> +
>> >> +    if (stat(path, &st)) {
>> >fstat()
>>
>> will change
>>
>> >
>> >> +        error_setg(&local_err, "cannot get file stat");
>> >error_setg_errno
>>
>> ditto
>>
>> >> +        goto out_fclose;
>> >> +    }
>> >> +
>> >> +    switch (st.st_mode & S_IFMT) {
>> >> +    case S_IFREG:
>> >> +        size = st.st_size;
>> >> +        break;
>> >> +
>> >> +    case S_IFBLK:
>> >> +        if (ioctl(fd, BLKGETSIZE64, &size)) {
>> >compilation might fail on platforms without  BLKGETSIZE64,
>> >
>>
>> BLKGETSIZE64 was first introduced by linux kernel 2.4.10. For these
>> linux specific code, does QEMU have any assumption for the least
>> kernel version? If no, I'll fallback to BLKGETSIZE if BLKGETSIZE64
>> fails.
>>
>> >
>> >> +            error_setg(&local_err, "cannot get size of block device");
>> >error_setg_errno
>> >> +            size = 0;
>> >> +        }
>> >> +        break;
>> >> +
>> >> +    default:
>> >> +        error_setg(&local_err,
>> >> +                   "only block device on Linux and regular file are supported");
>> >what about huge page usecase, would it fall right here fail?
>> >
>>
>> Yes, it will fail. notrunc is not necessary for the huge page case. I
>> could report more messages here, like "remove notrunc if hugetlbfs is used".
>it's better to skip this check in case of hugetlbfs so user won't have to do anything
>

Agree, it's better to not confuse users.

Thanks,
Haozhong

>
>> >> +    }
>> >> +
>> >> + out_fclose:
>> >> +    close(fd);
>> >> + out:
>> >> +    error_propagate(errp, local_err);
>> >> +    return size;
>> >> +}
>> >> +
>> >[...]
>> >
>>
>> Thank you for the review!
>>
>> Haozhong
>>
>
Eduardo Habkost Oct. 20, 2016, 1:57 p.m. UTC | #17 
On Thu, Oct 20, 2016 at 03:47:32PM +0200, Igor Mammedov wrote:
> On Thu, 20 Oct 2016 21:33:53 +0800
> Haozhong Zhang <haozhong.zhang@intel.com> wrote:
> 
> > On 10/20/16 11:21 -0200, Eduardo Habkost wrote:
> > >On Thu, Oct 20, 2016 at 02:34:12PM +0200, Igor Mammedov wrote:  
> > >> On Thu, 20 Oct 2016 14:13:01 +0800
> > >> Haozhong Zhang <haozhong.zhang@intel.com> wrote:
> > >>  
> > >> > If a file is used as the backend of memory-backend-file and its size is
> > >> > not identical to the property 'size', the file will be truncated. For a
> > >> > file used as the backend of vNVDIMM, its data is expected to be
> > >> > persistent and the truncation may corrupt the existing data.  
> > >> I wonder if it's possible just skip 'size' property in your case instead
> > >> 'notrunc' property. That way if size is not present one'd get actual size
> > >> using get_file_size() and set 'size' to it?
> > >> And if 'size' is provided and 'size' != file_size then error out.  
> > >
> > >I think it is valid to start with a zero-size file and then let
> > >QEMU extend it.  
> > 
> > For vNVDIMM, extending from zero-size file can be valid when a file is
> > first used. However, it's not valid for the second and following use
> > of the same file.
> I'd avoid 0 sized backend files and enforce non 0 size value
> with exact match to actual file size. i.e. let mgmt side take care of
> proper backend file allocation.

This would break compatibility with existing setups that rely on
the ftruncate() behavior.
Igor Mammedov Oct. 20, 2016, 2:15 p.m. UTC | #18 
On Thu, 20 Oct 2016 11:56:10 -0200
Eduardo Habkost <ehabkost@redhat.com> wrote:

> On Thu, Oct 20, 2016 at 03:42:15PM +0200, Igor Mammedov wrote:
> > On Thu, 20 Oct 2016 21:11:38 +0800
> > Haozhong Zhang <haozhong.zhang@intel.com> wrote:
> >   
> > > On 10/20/16 14:34 +0200, Igor Mammedov wrote:  
> > > >On Thu, 20 Oct 2016 14:13:01 +0800
> > > >Haozhong Zhang <haozhong.zhang@intel.com> wrote:
> > > >    
> > > >> If a file is used as the backend of memory-backend-file and its size is
> > > >> not identical to the property 'size', the file will be truncated. For a
> > > >> file used as the backend of vNVDIMM, its data is expected to be
> > > >> persistent and the truncation may corrupt the existing data.    
> > > >I wonder if it's possible just skip 'size' property in your case instead
> > > >'notrunc' property. That way if size is not present one'd get actual size
> > > >using get_file_size() and set 'size' to it?
> > > >And if 'size' is provided and 'size' != file_size then error out.
> > > >    
> > > 
> > > I don't know how this can be implemented in QEMU. Specially, how does
> > > the memory-backend-file know it's used for vNVDIMM, so that it can
> > > skip the 'size' property?  
> > Does memory-backend-file needs to know that it's used by NVDIMM?
> > Looking at nvdimm_realize it doesn't as it's assumes 
> >   hostemem_size == pmem_size + label_size
> > 
> > I'd make hostmem_file.size optional and take size from file
> > and if 'size' is specified explictly require it to mach file size.
> > It's generic and has nothing to do with nvdimm.  
> 
> We can take size from file, or take size from the
> host_memory_backend_get_memory() callers.
> 
> Enumerating all sizes that QEMU can use as input:
> 
> A) Backend file size
> B) memory backend "size" option
> C) frontend-provided size (-numa size, -m, or pc-dimm "size"
>     property)
-numa size affect only anon memory not backend backed one, for
backend baked memory we use memdev where size comes from backend

pc-dimm.size is readonly and isn't supposed to influence backend.size

I'd drop C option

> 
> My suggestion is:
> * B should be optional.
> * If B is omitted, we should never truncate the file to a smaller
>   size.
i.e. derive backend.size from filesize if possible (i.e. not hugepages)

> * If B is omitted, we can use C as the size when mapping the
>   file.
frontend size is the size that's mapped into guest address space.
it should not influence backend's size in backward direction.
You may notice pc-dimm.size is not user settable (readonly) property.

> * If B is omitted, and C > A, maybe we could use ftruncate() to
>   extend the file to make users happy. But I'm not sure we
>   should (I think B should be the only option that cause
>   truncation).
> * If we want to make C optional on some cases, we could use A if
>   B is omitted.
we shouldn't use C to manage backends behavior

But I have a question why do we have truncation at all in place now.

> 
> Does that make sense?
>
Igor Mammedov Oct. 20, 2016, 2:17 p.m. UTC | #19 
On Thu, 20 Oct 2016 11:47:18 -0200
Eduardo Habkost <ehabkost@redhat.com> wrote:

> On Thu, Oct 20, 2016 at 09:33:53PM +0800, Haozhong Zhang wrote:
> > On 10/20/16 11:21 -0200, Eduardo Habkost wrote:  
> > > On Thu, Oct 20, 2016 at 02:34:12PM +0200, Igor Mammedov wrote:  
> > > > On Thu, 20 Oct 2016 14:13:01 +0800
> > > > Haozhong Zhang <haozhong.zhang@intel.com> wrote:
> > > >   
> > > > > If a file is used as the backend of memory-backend-file and its size is
> > > > > not identical to the property 'size', the file will be truncated. For a
> > > > > file used as the backend of vNVDIMM, its data is expected to be
> > > > > persistent and the truncation may corrupt the existing data.  
> > > > I wonder if it's possible just skip 'size' property in your case instead
> > > > 'notrunc' property. That way if size is not present one'd get actual size
> > > > using get_file_size() and set 'size' to it?
> > > > And if 'size' is provided and 'size' != file_size then error out.  
> > > 
> > > I think it is valid to start with a zero-size file and then let
> > > QEMU extend it.  
> > 
> > For vNVDIMM, extending from zero-size file can be valid when a file is
> > first used. However, it's not valid for the second and following use
> > of the same file.
> >   
> > > But I agree we should: 1) make 'size' optional as
> > > you suggested; 2) never truncate the file to a smaller size.
> > >   
> > 
> > I will add another patch for this. Is there any way in QEMU to decide
> > whether a memory-backend-file object is used for vNVDIMM when the
> > object is being created? Or 'size' can be optional for all kinds of
> > usages?  
> 
> I believe 'size' can be optional for all usage, because at the
> moment the memory allocation code asks the backend for a memory
> region, it is supposed to know desired RAM size from the frontend
> configuration (-numa, -m, or "size" property of pc-dimm).

nope, currently the size propagates other way around
 from back-end to front-end and not backwards
Igor Mammedov Oct. 20, 2016, 2:18 p.m. UTC | #20 
On Thu, 20 Oct 2016 11:57:11 -0200
Eduardo Habkost <ehabkost@redhat.com> wrote:

> On Thu, Oct 20, 2016 at 03:47:32PM +0200, Igor Mammedov wrote:
> > On Thu, 20 Oct 2016 21:33:53 +0800
> > Haozhong Zhang <haozhong.zhang@intel.com> wrote:
> >   
> > > On 10/20/16 11:21 -0200, Eduardo Habkost wrote:  
> > > >On Thu, Oct 20, 2016 at 02:34:12PM +0200, Igor Mammedov wrote:    
> > > >> On Thu, 20 Oct 2016 14:13:01 +0800
> > > >> Haozhong Zhang <haozhong.zhang@intel.com> wrote:
> > > >>    
> > > >> > If a file is used as the backend of memory-backend-file and its size is
> > > >> > not identical to the property 'size', the file will be truncated. For a
> > > >> > file used as the backend of vNVDIMM, its data is expected to be
> > > >> > persistent and the truncation may corrupt the existing data.    
> > > >> I wonder if it's possible just skip 'size' property in your case instead
> > > >> 'notrunc' property. That way if size is not present one'd get actual size
> > > >> using get_file_size() and set 'size' to it?
> > > >> And if 'size' is provided and 'size' != file_size then error out.    
> > > >
> > > >I think it is valid to start with a zero-size file and then let
> > > >QEMU extend it.    
> > > 
> > > For vNVDIMM, extending from zero-size file can be valid when a file is
> > > first used. However, it's not valid for the second and following use
> > > of the same file.  
> > I'd avoid 0 sized backend files and enforce non 0 size value
> > with exact match to actual file size. i.e. let mgmt side take care of
> > proper backend file allocation.  
> 
> This would break compatibility with existing setups that rely on
> the ftruncate() behavior.

Question is what exactly rely on truncate behavior?
Haozhong Zhang Oct. 20, 2016, 2:22 p.m. UTC | #21 
On 10/20/16 11:56 -0200, Eduardo Habkost wrote:
>On Thu, Oct 20, 2016 at 03:42:15PM +0200, Igor Mammedov wrote:
>> On Thu, 20 Oct 2016 21:11:38 +0800
>> Haozhong Zhang <haozhong.zhang@intel.com> wrote:
>>
>> > On 10/20/16 14:34 +0200, Igor Mammedov wrote:
>> > >On Thu, 20 Oct 2016 14:13:01 +0800
>> > >Haozhong Zhang <haozhong.zhang@intel.com> wrote:
>> > >
>> > >> If a file is used as the backend of memory-backend-file and its size is
>> > >> not identical to the property 'size', the file will be truncated. For a
>> > >> file used as the backend of vNVDIMM, its data is expected to be
>> > >> persistent and the truncation may corrupt the existing data.
>> > >I wonder if it's possible just skip 'size' property in your case instead
>> > >'notrunc' property. That way if size is not present one'd get actual size
>> > >using get_file_size() and set 'size' to it?
>> > >And if 'size' is provided and 'size' != file_size then error out.
>> > >
>> >
>> > I don't know how this can be implemented in QEMU. Specially, how does
>> > the memory-backend-file know it's used for vNVDIMM, so that it can
>> > skip the 'size' property?
>> Does memory-backend-file needs to know that it's used by NVDIMM?
>> Looking at nvdimm_realize it doesn't as it's assumes
>>   hostemem_size == pmem_size + label_size
>>
>> I'd make hostmem_file.size optional and take size from file
>> and if 'size' is specified explictly require it to mach file size.
>> It's generic and has nothing to do with nvdimm.
>
>We can take size from file, or take size from the
>host_memory_backend_get_memory() callers.
>
>Enumerating all sizes that QEMU can use as input:
>
>A) Backend file size
>B) memory backend "size" option
>C) frontend-provided size (-numa size, -m, or pc-dimm "size"
>    property)
>
>My suggestion is:
>* B should be optional.
>* If B is omitted, we should never truncate the file to a smaller
>  size.
>* If B is omitted, we can use C as the size when mapping the
>  file.
>* If B is omitted, and C > A, maybe we could use ftruncate() to
>  extend the file to make users happy. But I'm not sure we
>  should (I think B should be the only option that cause
>  truncation).

For the words in parentheses, I have one question: what does size B mean?
1) The user knows the file size is the one specified (size B),
   and, if it's not, all bad results are user's fault.
or
2) The user wants only the part of size B is used. How the other part
   is used is unspecified, which, I think, implies the user does not
   expect QEMU to touch it.
   
If it's 1), I think it's reasonable to truncate when B is given.
Otherwise, if B is given, QEMU can truncate the file only if B > A.

Haozhong

>* If we want to make C optional on some cases, we could use A if
>  B is omitted.
>
>Does that make sense?
>
>-- 
>Eduardo
Eduardo Habkost Oct. 20, 2016, 2:47 p.m. UTC | #22 
On Thu, Oct 20, 2016 at 04:15:21PM +0200, Igor Mammedov wrote:
> On Thu, 20 Oct 2016 11:56:10 -0200
> Eduardo Habkost <ehabkost@redhat.com> wrote:
> 
> > On Thu, Oct 20, 2016 at 03:42:15PM +0200, Igor Mammedov wrote:
> > > On Thu, 20 Oct 2016 21:11:38 +0800
> > > Haozhong Zhang <haozhong.zhang@intel.com> wrote:
> > >   
> > > > On 10/20/16 14:34 +0200, Igor Mammedov wrote:  
> > > > >On Thu, 20 Oct 2016 14:13:01 +0800
> > > > >Haozhong Zhang <haozhong.zhang@intel.com> wrote:
> > > > >    
> > > > >> If a file is used as the backend of memory-backend-file and its size is
> > > > >> not identical to the property 'size', the file will be truncated. For a
> > > > >> file used as the backend of vNVDIMM, its data is expected to be
> > > > >> persistent and the truncation may corrupt the existing data.    
> > > > >I wonder if it's possible just skip 'size' property in your case instead
> > > > >'notrunc' property. That way if size is not present one'd get actual size
> > > > >using get_file_size() and set 'size' to it?
> > > > >And if 'size' is provided and 'size' != file_size then error out.
> > > > >    
> > > > 
> > > > I don't know how this can be implemented in QEMU. Specially, how does
> > > > the memory-backend-file know it's used for vNVDIMM, so that it can
> > > > skip the 'size' property?  
> > > Does memory-backend-file needs to know that it's used by NVDIMM?
> > > Looking at nvdimm_realize it doesn't as it's assumes 
> > >   hostemem_size == pmem_size + label_size
> > > 
> > > I'd make hostmem_file.size optional and take size from file
> > > and if 'size' is specified explictly require it to mach file size.
> > > It's generic and has nothing to do with nvdimm.  
> > 
> > We can take size from file, or take size from the
> > host_memory_backend_get_memory() callers.
> > 
> > Enumerating all sizes that QEMU can use as input:
> > 
> > A) Backend file size
> > B) memory backend "size" option
> > C) frontend-provided size (-numa size, -m, or pc-dimm "size"
> >     property)
> -numa size affect only anon memory not backend backed one, for
> backend baked memory we use memdev where size comes from backend
> 
> pc-dimm.size is readonly and isn't supposed to influence backend.size
> 
> I'd drop C option

If C is not present, it should be, as it affects the guest ABI
(and the ABI must never depend on the host you are running or
backend configuration, only on the frontend configuration).

If we are dropping -numa size in favor of the
memory-backend-provided size, that's a bug.

> 
> > 
> > My suggestion is:
> > * B should be optional.
> > * If B is omitted, we should never truncate the file to a smaller
> >   size.
> i.e. derive backend.size from filesize if possible (i.e. not hugepages)
> 
> > * If B is omitted, we can use C as the size when mapping the
> >   file.
> frontend size is the size that's mapped into guest address space.
> it should not influence backend's size in backward direction.
> You may notice pc-dimm.size is not user settable (readonly) property.

Frontend size will not influence backend size, it will just
affect the size of the memory region the frontend code will ask
the backend to provide.

In other words: I believe host_memory_backend_get_memory() needs
a 'size' argument, and that memory allocation could be optionally
delayed to the host_memory_backend_get_memory() call. This way,
we don't need a backend size at all, unless we want the backend
to truncate files or preallocate memory for us.

> 
> > * If B is omitted, and C > A, maybe we could use ftruncate() to
> >   extend the file to make users happy. But I'm not sure we
> >   should (I think B should be the only option that cause
> >   truncation).
> > * If we want to make C optional on some cases, we could use A if
> >   B is omitted.
> we shouldn't use C to manage backends behavior

I don't think this would be "managing backend behavior". I
believe the memory backend is a memory mapper/allocator, but the
exact size of the memory it provide is up to the caller that's
asking for a MemoryRegion.

> 
> But I have a question why do we have truncation at all in place now.

Probably because ftruncate() needs to be run by QEMU if memory is
supposed to be allocated by QEMU (e.g. if using tmpfs or
hugetlbfs).

Even if we decide we don't want it anymore, we can't drop the
ability to extend files without breaking existing setups. We can
probably drop the ability to truncate files to smaller sizes,
though.

> 
> > 
> > Does that make sense?
> > 
>
Eduardo Habkost Oct. 20, 2016, 3 p.m. UTC | #23 
On Thu, Oct 20, 2016 at 04:18:20PM +0200, Igor Mammedov wrote:
> On Thu, 20 Oct 2016 11:57:11 -0200
> Eduardo Habkost <ehabkost@redhat.com> wrote:
> 
> > On Thu, Oct 20, 2016 at 03:47:32PM +0200, Igor Mammedov wrote:
> > > On Thu, 20 Oct 2016 21:33:53 +0800
> > > Haozhong Zhang <haozhong.zhang@intel.com> wrote:
> > >   
> > > > On 10/20/16 11:21 -0200, Eduardo Habkost wrote:  
> > > > >On Thu, Oct 20, 2016 at 02:34:12PM +0200, Igor Mammedov wrote:    
> > > > >> On Thu, 20 Oct 2016 14:13:01 +0800
> > > > >> Haozhong Zhang <haozhong.zhang@intel.com> wrote:
> > > > >>    
> > > > >> > If a file is used as the backend of memory-backend-file and its size is
> > > > >> > not identical to the property 'size', the file will be truncated. For a
> > > > >> > file used as the backend of vNVDIMM, its data is expected to be
> > > > >> > persistent and the truncation may corrupt the existing data.    
> > > > >> I wonder if it's possible just skip 'size' property in your case instead
> > > > >> 'notrunc' property. That way if size is not present one'd get actual size
> > > > >> using get_file_size() and set 'size' to it?
> > > > >> And if 'size' is provided and 'size' != file_size then error out.    
> > > > >
> > > > >I think it is valid to start with a zero-size file and then let
> > > > >QEMU extend it.    
> > > > 
> > > > For vNVDIMM, extending from zero-size file can be valid when a file is
> > > > first used. However, it's not valid for the second and following use
> > > > of the same file.  
> > > I'd avoid 0 sized backend files and enforce non 0 size value
> > > with exact match to actual file size. i.e. let mgmt side take care of
> > > proper backend file allocation.  
> > 
> > This would break compatibility with existing setups that rely on
> > the ftruncate() behavior.
> 
> Question is what exactly rely on truncate behavior?

hugetlbfs or tmpfs + mempolicy would work only if a sparse file
used (otherwise memory would be already allocated before running
QEMU). That means it is easier to simply not set file size before
running QEMU.

I don't know what's libvirt behavior, but I wouldn't want to
break existing scripts that rely on it.
Eduardo Habkost Oct. 20, 2016, 3:14 p.m. UTC | #24 
On Thu, Oct 20, 2016 at 10:22:53PM +0800, Haozhong Zhang wrote:
> On 10/20/16 11:56 -0200, Eduardo Habkost wrote:
> > On Thu, Oct 20, 2016 at 03:42:15PM +0200, Igor Mammedov wrote:
> > > On Thu, 20 Oct 2016 21:11:38 +0800
> > > Haozhong Zhang <haozhong.zhang@intel.com> wrote:
> > > 
> > > > On 10/20/16 14:34 +0200, Igor Mammedov wrote:
> > > > >On Thu, 20 Oct 2016 14:13:01 +0800
> > > > >Haozhong Zhang <haozhong.zhang@intel.com> wrote:
> > > > >
> > > > >> If a file is used as the backend of memory-backend-file and its size is
> > > > >> not identical to the property 'size', the file will be truncated. For a
> > > > >> file used as the backend of vNVDIMM, its data is expected to be
> > > > >> persistent and the truncation may corrupt the existing data.
> > > > >I wonder if it's possible just skip 'size' property in your case instead
> > > > >'notrunc' property. That way if size is not present one'd get actual size
> > > > >using get_file_size() and set 'size' to it?
> > > > >And if 'size' is provided and 'size' != file_size then error out.
> > > > >
> > > >
> > > > I don't know how this can be implemented in QEMU. Specially, how does
> > > > the memory-backend-file know it's used for vNVDIMM, so that it can
> > > > skip the 'size' property?
> > > Does memory-backend-file needs to know that it's used by NVDIMM?
> > > Looking at nvdimm_realize it doesn't as it's assumes
> > >   hostemem_size == pmem_size + label_size
> > > 
> > > I'd make hostmem_file.size optional and take size from file
> > > and if 'size' is specified explictly require it to mach file size.
> > > It's generic and has nothing to do with nvdimm.
> > 
> > We can take size from file, or take size from the
> > host_memory_backend_get_memory() callers.
> > 
> > Enumerating all sizes that QEMU can use as input:
> > 
> > A) Backend file size
> > B) memory backend "size" option
> > C) frontend-provided size (-numa size, -m, or pc-dimm "size"
> >    property)
> > 
> > My suggestion is:
> > * B should be optional.
> > * If B is omitted, we should never truncate the file to a smaller
> >  size.
> > * If B is omitted, we can use C as the size when mapping the
> >  file.
> > * If B is omitted, and C > A, maybe we could use ftruncate() to
> >  extend the file to make users happy. But I'm not sure we
> >  should (I think B should be the only option that cause
> >  truncation).
> 
> For the words in parentheses, I have one question: what does size B mean?
> 1) The user knows the file size is the one specified (size B),
>   and, if it's not, all bad results are user's fault.

The only use case I see for B is to force allocation and
ftruncate to a larger size. All other uses should be covered by
C. But note that Igor and I are having an ongoing discussion in
this thread about using C vs A/B.

> or
> 2) The user wants only the part of size B is used. How the other part
>   is used is unspecified, which, I think, implies the user does not
>   expect QEMU to touch it.

We don't have an option meaning "please touch only this specific
region of the file, leave the rest alone". In this case, not
truncating even when "size" is explicitly set would make sense.

If we wanted that "please don't touch the rest of the file" mode
to be supported, this doesn't seem to be the use case we have in
mind right now, does it? If we did, I believe we would have an
"offset" parameter too.

> If it's 1), I think it's reasonable to truncate when B is given.
> Otherwise, if B is given, QEMU can truncate the file only if B > A.

I would say it's still (1), but we don't need to truncate the
file if B < A, so we can avoid it because it's safer.

> 
> Haozhong
> 
> > * If we want to make C optional on some cases, we could use A if
> >  B is omitted.
> > 
> > Does that make sense?
> > 
> > -- 
> > Eduardo
Igor Mammedov Oct. 20, 2016, 3:14 p.m. UTC | #25 
On Thu, 20 Oct 2016 13:00:29 -0200
Eduardo Habkost <ehabkost@redhat.com> wrote:

> On Thu, Oct 20, 2016 at 04:18:20PM +0200, Igor Mammedov wrote:
> > On Thu, 20 Oct 2016 11:57:11 -0200
> > Eduardo Habkost <ehabkost@redhat.com> wrote:
> >   
> > > On Thu, Oct 20, 2016 at 03:47:32PM +0200, Igor Mammedov wrote:  
> > > > On Thu, 20 Oct 2016 21:33:53 +0800
> > > > Haozhong Zhang <haozhong.zhang@intel.com> wrote:
> > > >     
> > > > > On 10/20/16 11:21 -0200, Eduardo Habkost wrote:    
> > > > > >On Thu, Oct 20, 2016 at 02:34:12PM +0200, Igor Mammedov wrote:      
> > > > > >> On Thu, 20 Oct 2016 14:13:01 +0800
> > > > > >> Haozhong Zhang <haozhong.zhang@intel.com> wrote:
> > > > > >>      
> > > > > >> > If a file is used as the backend of memory-backend-file and its size is
> > > > > >> > not identical to the property 'size', the file will be truncated. For a
> > > > > >> > file used as the backend of vNVDIMM, its data is expected to be
> > > > > >> > persistent and the truncation may corrupt the existing data.      
> > > > > >> I wonder if it's possible just skip 'size' property in your case instead
> > > > > >> 'notrunc' property. That way if size is not present one'd get actual size
> > > > > >> using get_file_size() and set 'size' to it?
> > > > > >> And if 'size' is provided and 'size' != file_size then error out.      
> > > > > >
> > > > > >I think it is valid to start with a zero-size file and then let
> > > > > >QEMU extend it.      
> > > > > 
> > > > > For vNVDIMM, extending from zero-size file can be valid when a file is
> > > > > first used. However, it's not valid for the second and following use
> > > > > of the same file.    
> > > > I'd avoid 0 sized backend files and enforce non 0 size value
> > > > with exact match to actual file size. i.e. let mgmt side take care of
> > > > proper backend file allocation.    
> > > 
> > > This would break compatibility with existing setups that rely on
> > > the ftruncate() behavior.  
> > 
> > Question is what exactly rely on truncate behavior?  
> 
> hugetlbfs or tmpfs + mempolicy would work only if a sparse file
> used (otherwise memory would be already allocated before running
> QEMU). That means it is easier to simply not set file size before
> running QEMU.
> 
> I don't know what's libvirt behavior, but I wouldn't want to
> break existing scripts that rely on it.
We can probably do something like this
 if (file_size == 0 && explicitly_asked_size > file_size)
      do allocation
Eduardo Habkost Oct. 20, 2016, 3:15 p.m. UTC | #26 
On Thu, Oct 20, 2016 at 04:17:35PM +0200, Igor Mammedov wrote:
> On Thu, 20 Oct 2016 11:47:18 -0200
> Eduardo Habkost <ehabkost@redhat.com> wrote:
> 
> > On Thu, Oct 20, 2016 at 09:33:53PM +0800, Haozhong Zhang wrote:
> > > On 10/20/16 11:21 -0200, Eduardo Habkost wrote:  
> > > > On Thu, Oct 20, 2016 at 02:34:12PM +0200, Igor Mammedov wrote:  
> > > > > On Thu, 20 Oct 2016 14:13:01 +0800
> > > > > Haozhong Zhang <haozhong.zhang@intel.com> wrote:
> > > > >   
> > > > > > If a file is used as the backend of memory-backend-file and its size is
> > > > > > not identical to the property 'size', the file will be truncated. For a
> > > > > > file used as the backend of vNVDIMM, its data is expected to be
> > > > > > persistent and the truncation may corrupt the existing data.  
> > > > > I wonder if it's possible just skip 'size' property in your case instead
> > > > > 'notrunc' property. That way if size is not present one'd get actual size
> > > > > using get_file_size() and set 'size' to it?
> > > > > And if 'size' is provided and 'size' != file_size then error out.  
> > > > 
> > > > I think it is valid to start with a zero-size file and then let
> > > > QEMU extend it.  
> > > 
> > > For vNVDIMM, extending from zero-size file can be valid when a file is
> > > first used. However, it's not valid for the second and following use
> > > of the same file.
> > >   
> > > > But I agree we should: 1) make 'size' optional as
> > > > you suggested; 2) never truncate the file to a smaller size.
> > > >   
> > > 
> > > I will add another patch for this. Is there any way in QEMU to decide
> > > whether a memory-backend-file object is used for vNVDIMM when the
> > > object is being created? Or 'size' can be optional for all kinds of
> > > usages?  
> > 
> > I believe 'size' can be optional for all usage, because at the
> > moment the memory allocation code asks the backend for a memory
> > region, it is supposed to know desired RAM size from the frontend
> > configuration (-numa, -m, or "size" property of pc-dimm).
> 
> nope, currently the size propagates other way around
>  from back-end to front-end and not backwards

I'd say that this is a bug. Frontend size is guest ABI and
shouldn't be overridden by backend configuration if it's
explicitly set.
Igor Mammedov Oct. 20, 2016, 3:35 p.m. UTC | #27 
On Thu, 20 Oct 2016 12:47:34 -0200
Eduardo Habkost <ehabkost@redhat.com> wrote:

> On Thu, Oct 20, 2016 at 04:15:21PM +0200, Igor Mammedov wrote:
> > On Thu, 20 Oct 2016 11:56:10 -0200
> > Eduardo Habkost <ehabkost@redhat.com> wrote:
> >   
> > > On Thu, Oct 20, 2016 at 03:42:15PM +0200, Igor Mammedov wrote:  
> > > > On Thu, 20 Oct 2016 21:11:38 +0800
> > > > Haozhong Zhang <haozhong.zhang@intel.com> wrote:
> > > >     
> > > > > On 10/20/16 14:34 +0200, Igor Mammedov wrote:    
> > > > > >On Thu, 20 Oct 2016 14:13:01 +0800
> > > > > >Haozhong Zhang <haozhong.zhang@intel.com> wrote:
> > > > > >      
> > > > > >> If a file is used as the backend of memory-backend-file and its size is
> > > > > >> not identical to the property 'size', the file will be truncated. For a
> > > > > >> file used as the backend of vNVDIMM, its data is expected to be
> > > > > >> persistent and the truncation may corrupt the existing data.      
> > > > > >I wonder if it's possible just skip 'size' property in your case instead
> > > > > >'notrunc' property. That way if size is not present one'd get actual size
> > > > > >using get_file_size() and set 'size' to it?
> > > > > >And if 'size' is provided and 'size' != file_size then error out.
> > > > > >      
> > > > > 
> > > > > I don't know how this can be implemented in QEMU. Specially, how does
> > > > > the memory-backend-file know it's used for vNVDIMM, so that it can
> > > > > skip the 'size' property?    
> > > > Does memory-backend-file needs to know that it's used by NVDIMM?
> > > > Looking at nvdimm_realize it doesn't as it's assumes 
> > > >   hostemem_size == pmem_size + label_size
> > > > 
> > > > I'd make hostmem_file.size optional and take size from file
> > > > and if 'size' is specified explictly require it to mach file size.
> > > > It's generic and has nothing to do with nvdimm.    
> > > 
> > > We can take size from file, or take size from the
> > > host_memory_backend_get_memory() callers.
> > > 
> > > Enumerating all sizes that QEMU can use as input:
> > > 
> > > A) Backend file size
> > > B) memory backend "size" option
> > > C) frontend-provided size (-numa size, -m, or pc-dimm "size"
> > >     property)  
> > -numa size affect only anon memory not backend backed one, for
> > backend baked memory we use memdev where size comes from backend
> > 
> > pc-dimm.size is readonly and isn't supposed to influence backend.size
> > 
> > I'd drop C option  
> 
> If C is not present, it should be, as it affects the guest ABI
> (and the ABI must never depend on the host you are running or
> backend configuration, only on the frontend configuration).
I've meant that C should not affect behavior of backend.

> If we are dropping -numa size in favor of the
> memory-backend-provided size, that's a bug.
-numa size is not applicable here as it's not using backends,
when backends are used it's -numa memdev instead in which case
   numa_info[nodenr].node_mem = object_property_get_int(o, "size", NULL);

> 
> >   
> > > 
> > > My suggestion is:
> > > * B should be optional.
> > > * If B is omitted, we should never truncate the file to a smaller
> > >   size.  
> > i.e. derive backend.size from filesize if possible (i.e. not hugepages)
> >   
> > > * If B is omitted, we can use C as the size when mapping the
> > >   file.  
> > frontend size is the size that's mapped into guest address space.
> > it should not influence backend's size in backward direction.
> > You may notice pc-dimm.size is not user settable (readonly) property.  
> 
> Frontend size will not influence backend size, it will just
> affect the size of the memory region the frontend code will ask
> the backend to provide.
> 
> In other words: I believe host_memory_backend_get_memory() needs
> a 'size' argument, and that memory allocation could be optionally
> delayed to the host_memory_backend_get_memory() call. This way,
> we don't need a backend size at all, unless we want the backend
> to truncate files or preallocate memory for us.
To not complicate things I'd keep current behavior of
  host_memory_backend_get_memory()
i.e return MR for all the baked memory and then frontend
can split and map it into guest address space as it sees fit
using aliases for non trivial cases taking in account frontend's
own size/label_size/whatnot properties.
That's what NVDIMM does now, it gets MR for whole file and
the splits it on data and label areas and maps into GA only
data part using memory_region_init_alias().

> 
> >   
> > > * If B is omitted, and C > A, maybe we could use ftruncate() to
> > >   extend the file to make users happy. But I'm not sure we
> > >   should (I think B should be the only option that cause
> > >   truncation).
> > > * If we want to make C optional on some cases, we could use A if
> > >   B is omitted.  
> > we shouldn't use C to manage backends behavior  
> 
> I don't think this would be "managing backend behavior". I
> believe the memory backend is a memory mapper/allocator, but the
> exact size of the memory it provide is up to the caller that's
> asking for a MemoryRegion.
caller in backend case is QEMU's CLI and backend options,
and yes it's a simple allocator/mapper. If frontend needs
to partition allocated region in some way it should do it
itself in some stable manner as it own layout.
That would keep things simple and consistent with which
and where from different sizes were originated.

[...]
Igor Mammedov Oct. 20, 2016, 3:41 p.m. UTC | #28 
On Thu, 20 Oct 2016 13:15:31 -0200
Eduardo Habkost <ehabkost@redhat.com> wrote:

> On Thu, Oct 20, 2016 at 04:17:35PM +0200, Igor Mammedov wrote:
> > On Thu, 20 Oct 2016 11:47:18 -0200
> > Eduardo Habkost <ehabkost@redhat.com> wrote:
> >   
> > > On Thu, Oct 20, 2016 at 09:33:53PM +0800, Haozhong Zhang wrote:  
> > > > On 10/20/16 11:21 -0200, Eduardo Habkost wrote:    
> > > > > On Thu, Oct 20, 2016 at 02:34:12PM +0200, Igor Mammedov wrote:    
> > > > > > On Thu, 20 Oct 2016 14:13:01 +0800
> > > > > > Haozhong Zhang <haozhong.zhang@intel.com> wrote:
> > > > > >     
> > > > > > > If a file is used as the backend of memory-backend-file and its size is
> > > > > > > not identical to the property 'size', the file will be truncated. For a
> > > > > > > file used as the backend of vNVDIMM, its data is expected to be
> > > > > > > persistent and the truncation may corrupt the existing data.    
> > > > > > I wonder if it's possible just skip 'size' property in your case instead
> > > > > > 'notrunc' property. That way if size is not present one'd get actual size
> > > > > > using get_file_size() and set 'size' to it?
> > > > > > And if 'size' is provided and 'size' != file_size then error out.    
> > > > > 
> > > > > I think it is valid to start with a zero-size file and then let
> > > > > QEMU extend it.    
> > > > 
> > > > For vNVDIMM, extending from zero-size file can be valid when a file is
> > > > first used. However, it's not valid for the second and following use
> > > > of the same file.
> > > >     
> > > > > But I agree we should: 1) make 'size' optional as
> > > > > you suggested; 2) never truncate the file to a smaller size.
> > > > >     
> > > > 
> > > > I will add another patch for this. Is there any way in QEMU to decide
> > > > whether a memory-backend-file object is used for vNVDIMM when the
> > > > object is being created? Or 'size' can be optional for all kinds of
> > > > usages?    
> > > 
> > > I believe 'size' can be optional for all usage, because at the
> > > moment the memory allocation code asks the backend for a memory
> > > region, it is supposed to know desired RAM size from the frontend
> > > configuration (-numa, -m, or "size" property of pc-dimm).  
> > 
> > nope, currently the size propagates other way around
> >  from back-end to front-end and not backwards  
> 
> I'd say that this is a bug. Frontend size is guest ABI and
> shouldn't be overridden by backend configuration if it's
> explicitly set.
frontend.size is always <= backend.size

allocation specified when backend is created (-object/object_add)
and front end size if needed/used is <= backend size

so far code followed this design.
Eduardo Habkost Oct. 20, 2016, 4:56 p.m. UTC | #29 
On Thu, Oct 20, 2016 at 05:35:38PM +0200, Igor Mammedov wrote:
> On Thu, 20 Oct 2016 12:47:34 -0200
> Eduardo Habkost <ehabkost@redhat.com> wrote:
> 
> > On Thu, Oct 20, 2016 at 04:15:21PM +0200, Igor Mammedov wrote:
> > > On Thu, 20 Oct 2016 11:56:10 -0200
> > > Eduardo Habkost <ehabkost@redhat.com> wrote:
> > >   
> > > > On Thu, Oct 20, 2016 at 03:42:15PM +0200, Igor Mammedov wrote:  
> > > > > On Thu, 20 Oct 2016 21:11:38 +0800
> > > > > Haozhong Zhang <haozhong.zhang@intel.com> wrote:
> > > > >     
> > > > > > On 10/20/16 14:34 +0200, Igor Mammedov wrote:    
> > > > > > >On Thu, 20 Oct 2016 14:13:01 +0800
> > > > > > >Haozhong Zhang <haozhong.zhang@intel.com> wrote:
> > > > > > >      
> > > > > > >> If a file is used as the backend of memory-backend-file and its size is
> > > > > > >> not identical to the property 'size', the file will be truncated. For a
> > > > > > >> file used as the backend of vNVDIMM, its data is expected to be
> > > > > > >> persistent and the truncation may corrupt the existing data.      
> > > > > > >I wonder if it's possible just skip 'size' property in your case instead
> > > > > > >'notrunc' property. That way if size is not present one'd get actual size
> > > > > > >using get_file_size() and set 'size' to it?
> > > > > > >And if 'size' is provided and 'size' != file_size then error out.
> > > > > > >      
> > > > > > 
> > > > > > I don't know how this can be implemented in QEMU. Specially, how does
> > > > > > the memory-backend-file know it's used for vNVDIMM, so that it can
> > > > > > skip the 'size' property?    
> > > > > Does memory-backend-file needs to know that it's used by NVDIMM?
> > > > > Looking at nvdimm_realize it doesn't as it's assumes 
> > > > >   hostemem_size == pmem_size + label_size
> > > > > 
> > > > > I'd make hostmem_file.size optional and take size from file
> > > > > and if 'size' is specified explictly require it to mach file size.
> > > > > It's generic and has nothing to do with nvdimm.    
> > > > 
> > > > We can take size from file, or take size from the
> > > > host_memory_backend_get_memory() callers.
> > > > 
> > > > Enumerating all sizes that QEMU can use as input:
> > > > 
> > > > A) Backend file size
> > > > B) memory backend "size" option
> > > > C) frontend-provided size (-numa size, -m, or pc-dimm "size"
> > > >     property)  
> > > -numa size affect only anon memory not backend backed one, for
> > > backend baked memory we use memdev where size comes from backend
> > > 
> > > pc-dimm.size is readonly and isn't supposed to influence backend.size
> > > 
> > > I'd drop C option  
> > 
> > If C is not present, it should be, as it affects the guest ABI
> > (and the ABI must never depend on the host you are running or
> > backend configuration, only on the frontend configuration).
> I've meant that C should not affect behavior of backend.
> 
> > If we are dropping -numa size in favor of the
> > memory-backend-provided size, that's a bug.
> -numa size is not applicable here as it's not using backends,
> when backends are used it's -numa memdev instead in which case
>    numa_info[nodenr].node_mem = object_property_get_int(o, "size", NULL);

OK. My suggestion is to change this to not ignore the size
option, but to validate it and/or do whatever necessary to get a
MemoryRegion of the right size (your suggestion below to split
the memory region would work too).

In other words, this should work:

  $ qemu -object memory-backend-file,id=mem0,mem-path=/tmp/mempath,size=2G \
         -numa node,size=2G,memdev=mem0 -m 2G

this must error out:

  $ qemu -object memory-backend-file,id=mem0,mem-path=/tmp/mempath,size=2G \
         -numa node,size=4G,memdev=mem0 -m 2G

and this should either error out, or result in a 1GB NUMA node
(but never in a 2G NUMA node):

  $ qemu -object memory-backend-file,id=mem0,mem-path=/tmp/mempath,size=2G \
         -numa node,size=1G,memdev=mem0 -m 1G

I will add that to my TODO-list.

> 
> > 
> > >   
> > > > 
> > > > My suggestion is:
> > > > * B should be optional.
> > > > * If B is omitted, we should never truncate the file to a smaller
> > > >   size.  
> > > i.e. derive backend.size from filesize if possible (i.e. not hugepages)
> > >   
> > > > * If B is omitted, we can use C as the size when mapping the
> > > >   file.  
> > > frontend size is the size that's mapped into guest address space.
> > > it should not influence backend's size in backward direction.
> > > You may notice pc-dimm.size is not user settable (readonly) property.  
> > 
> > Frontend size will not influence backend size, it will just
> > affect the size of the memory region the frontend code will ask
> > the backend to provide.
> > 
> > In other words: I believe host_memory_backend_get_memory() needs
> > a 'size' argument, and that memory allocation could be optionally
> > delayed to the host_memory_backend_get_memory() call. This way,
> > we don't need a backend size at all, unless we want the backend
> > to truncate files or preallocate memory for us.
> To not complicate things I'd keep current behavior of
>   host_memory_backend_get_memory()
> i.e return MR for all the baked memory and then frontend
> can split and map it into guest address space as it sees fit
> using aliases for non trivial cases taking in account frontend's
> own size/label_size/whatnot properties.
> That's what NVDIMM does now, it gets MR for whole file and
> the splits it on data and label areas and maps into GA only
> data part using memory_region_init_alias().

Good idea. That would probably work too.

> 
> > 
> > >   
> > > > * If B is omitted, and C > A, maybe we could use ftruncate() to
> > > >   extend the file to make users happy. But I'm not sure we
> > > >   should (I think B should be the only option that cause
> > > >   truncation).
> > > > * If we want to make C optional on some cases, we could use A if
> > > >   B is omitted.  
> > > we shouldn't use C to manage backends behavior  
> > 
> > I don't think this would be "managing backend behavior". I
> > believe the memory backend is a memory mapper/allocator, but the
> > exact size of the memory it provide is up to the caller that's
> > asking for a MemoryRegion.
> caller in backend case is QEMU's CLI and backend options,
> and yes it's a simple allocator/mapper. If frontend needs
> to partition allocated region in some way it should do it
> itself in some stable manner as it own layout.
> That would keep things simple and consistent with which
> and where from different sizes were originated.

If the MemoryRegion API lets us do that, that's an even better
solution.

Probably there's only one case where behavior would be different
than what I was thinking. I would like to be possible to specify
only C (frontend size), and omit both A and B. For example:

  $ mkdir /tmp/mempath
  $ qemu -object memory-backend-file,id=mem0,mem-path=/tmp/mempath \
         -numa node,size=1G,memdev=mem0 -m 1G

I would like this command to create a 1G file inside /tmp/mempath
automatically, without the need for an explicit size=1G argument
to memory-backend-file.

But this would be a new feature, anyway. No need to worry about
it right now. I will add it to my TODO-list and try to send a RFC
later.
Eduardo Habkost Oct. 20, 2016, 4:59 p.m. UTC | #30 
On Thu, Oct 20, 2016 at 05:41:47PM +0200, Igor Mammedov wrote:
> On Thu, 20 Oct 2016 13:15:31 -0200
> Eduardo Habkost <ehabkost@redhat.com> wrote:
> 
> > On Thu, Oct 20, 2016 at 04:17:35PM +0200, Igor Mammedov wrote:
> > > On Thu, 20 Oct 2016 11:47:18 -0200
> > > Eduardo Habkost <ehabkost@redhat.com> wrote:
> > >   
> > > > On Thu, Oct 20, 2016 at 09:33:53PM +0800, Haozhong Zhang wrote:  
> > > > > On 10/20/16 11:21 -0200, Eduardo Habkost wrote:    
> > > > > > On Thu, Oct 20, 2016 at 02:34:12PM +0200, Igor Mammedov wrote:    
> > > > > > > On Thu, 20 Oct 2016 14:13:01 +0800
> > > > > > > Haozhong Zhang <haozhong.zhang@intel.com> wrote:
> > > > > > >     
> > > > > > > > If a file is used as the backend of memory-backend-file and its size is
> > > > > > > > not identical to the property 'size', the file will be truncated. For a
> > > > > > > > file used as the backend of vNVDIMM, its data is expected to be
> > > > > > > > persistent and the truncation may corrupt the existing data.    
> > > > > > > I wonder if it's possible just skip 'size' property in your case instead
> > > > > > > 'notrunc' property. That way if size is not present one'd get actual size
> > > > > > > using get_file_size() and set 'size' to it?
> > > > > > > And if 'size' is provided and 'size' != file_size then error out.    
> > > > > > 
> > > > > > I think it is valid to start with a zero-size file and then let
> > > > > > QEMU extend it.    
> > > > > 
> > > > > For vNVDIMM, extending from zero-size file can be valid when a file is
> > > > > first used. However, it's not valid for the second and following use
> > > > > of the same file.
> > > > >     
> > > > > > But I agree we should: 1) make 'size' optional as
> > > > > > you suggested; 2) never truncate the file to a smaller size.
> > > > > >     
> > > > > 
> > > > > I will add another patch for this. Is there any way in QEMU to decide
> > > > > whether a memory-backend-file object is used for vNVDIMM when the
> > > > > object is being created? Or 'size' can be optional for all kinds of
> > > > > usages?    
> > > > 
> > > > I believe 'size' can be optional for all usage, because at the
> > > > moment the memory allocation code asks the backend for a memory
> > > > region, it is supposed to know desired RAM size from the frontend
> > > > configuration (-numa, -m, or "size" property of pc-dimm).  
> > > 
> > > nope, currently the size propagates other way around
> > >  from back-end to front-end and not backwards  
> > 
> > I'd say that this is a bug. Frontend size is guest ABI and
> > shouldn't be overridden by backend configuration if it's
> > explicitly set.
> frontend.size is always <= backend.size
> 
> allocation specified when backend is created (-object/object_add)
> and front end size if needed/used is <= backend size
> 
> so far code followed this design.

This would work, but it doesn't happen in the case of -numa:

  $ ./x86_64-softmmu/qemu-system-x86_64 \
    -object memory-backend-file,id=mem0,mem-path=/tmp/mempath,size=2G \
    -numa node,size=1G,memdev=mem0 -m 1G
  qemu-system-x86_64: total memory for NUMA nodes (0x80000000) should equal RAM size (0x40000000)

That's a bug we need to fix.
Haozhong Zhang Oct. 21, 2016, 7:22 a.m. UTC | #31 
On 10/20/16 17:35 +0200, Igor Mammedov wrote:
>On Thu, 20 Oct 2016 12:47:34 -0200
>Eduardo Habkost <ehabkost@redhat.com> wrote:
>
>> On Thu, Oct 20, 2016 at 04:15:21PM +0200, Igor Mammedov wrote:
>> > On Thu, 20 Oct 2016 11:56:10 -0200
>> > Eduardo Habkost <ehabkost@redhat.com> wrote:
>> >
>> > > On Thu, Oct 20, 2016 at 03:42:15PM +0200, Igor Mammedov wrote:
>> > > > On Thu, 20 Oct 2016 21:11:38 +0800
>> > > > Haozhong Zhang <haozhong.zhang@intel.com> wrote:
>> > > >
>> > > > > On 10/20/16 14:34 +0200, Igor Mammedov wrote:
>> > > > > >On Thu, 20 Oct 2016 14:13:01 +0800
>> > > > > >Haozhong Zhang <haozhong.zhang@intel.com> wrote:
>> > > > > >
>> > > > > >> If a file is used as the backend of memory-backend-file and its size is
>> > > > > >> not identical to the property 'size', the file will be truncated. For a
>> > > > > >> file used as the backend of vNVDIMM, its data is expected to be
>> > > > > >> persistent and the truncation may corrupt the existing data.
>> > > > > >I wonder if it's possible just skip 'size' property in your case instead
>> > > > > >'notrunc' property. That way if size is not present one'd get actual size
>> > > > > >using get_file_size() and set 'size' to it?
>> > > > > >And if 'size' is provided and 'size' != file_size then error out.
>> > > > > >
>> > > > >
>> > > > > I don't know how this can be implemented in QEMU. Specially, how does
>> > > > > the memory-backend-file know it's used for vNVDIMM, so that it can
>> > > > > skip the 'size' property?
>> > > > Does memory-backend-file needs to know that it's used by NVDIMM?
>> > > > Looking at nvdimm_realize it doesn't as it's assumes
>> > > >   hostemem_size == pmem_size + label_size
>> > > >
>> > > > I'd make hostmem_file.size optional and take size from file
>> > > > and if 'size' is specified explictly require it to mach file size.
>> > > > It's generic and has nothing to do with nvdimm.
>> > >
>> > > We can take size from file, or take size from the
>> > > host_memory_backend_get_memory() callers.
>> > >
>> > > Enumerating all sizes that QEMU can use as input:
>> > >
>> > > A) Backend file size
>> > > B) memory backend "size" option
>> > > C) frontend-provided size (-numa size, -m, or pc-dimm "size"
>> > >     property)
>> > -numa size affect only anon memory not backend backed one, for
>> > backend baked memory we use memdev where size comes from backend
>> >
>> > pc-dimm.size is readonly and isn't supposed to influence backend.size
>> >
>> > I'd drop C option
>>
>> If C is not present, it should be, as it affects the guest ABI
>> (and the ABI must never depend on the host you are running or
>> backend configuration, only on the frontend configuration).
>I've meant that C should not affect behavior of backend.
>
>> If we are dropping -numa size in favor of the
>> memory-backend-provided size, that's a bug.
>-numa size is not applicable here as it's not using backends,
>when backends are used it's -numa memdev instead in which case
>   numa_info[nodenr].node_mem = object_property_get_int(o, "size", NULL);
>
>>
>> >
>> > >
>> > > My suggestion is:
>> > > * B should be optional.
>> > > * If B is omitted, we should never truncate the file to a smaller
>> > >   size.
>> > i.e. derive backend.size from filesize if possible (i.e. not hugepages)
>> >
>> > > * If B is omitted, we can use C as the size when mapping the
>> > >   file.
>> > frontend size is the size that's mapped into guest address space.
>> > it should not influence backend's size in backward direction.
>> > You may notice pc-dimm.size is not user settable (readonly) property.
>>
>> Frontend size will not influence backend size, it will just
>> affect the size of the memory region the frontend code will ask
>> the backend to provide.
>>
>> In other words: I believe host_memory_backend_get_memory() needs
>> a 'size' argument, and that memory allocation could be optionally
>> delayed to the host_memory_backend_get_memory() call. This way,
>> we don't need a backend size at all, unless we want the backend
>> to truncate files or preallocate memory for us.
>To not complicate things I'd keep current behavior of
>  host_memory_backend_get_memory()
>i.e return MR for all the baked memory and then frontend
>can split and map it into guest address space as it sees fit
>using aliases for non trivial cases taking in account frontend's
>own size/label_size/whatnot properties.
>That's what NVDIMM does now, it gets MR for whole file and
>the splits it on data and label areas and maps into GA only
>data part using memory_region_init_alias().
>

As NVDIMM label is mentioned here, I realize a case that extending
file size would fail:

NVDIMM labels record the namespace information of the data area and
should be persistently stored. The current vNVDIMM implementation in
QEMU always stores and finds those labels at the end of the given
backend storage. If a larger size B is given and the backend file is
extended, QEMU will not be able to find the labels stored on the
original file, and hence cannot present the same namespaces to guest.

This problem can fixed by deferring the allocation to
host_memory_backend_get_memory(), and adding a parameter 'notrunc' to
it to specify the truncation behavior. If no truncation is specified
and B > A, QEMU will report error and stop.

In the long term, we will allow the labels to be stored in separated
files, and extending the data file will be allowed.

Haozhong

[..]
Igor Mammedov Oct. 21, 2016, 9:31 a.m. UTC | #32 
On Thu, 20 Oct 2016 14:56:58 -0200
Eduardo Habkost <ehabkost@redhat.com> wrote:

> On Thu, Oct 20, 2016 at 05:35:38PM +0200, Igor Mammedov wrote:
> > On Thu, 20 Oct 2016 12:47:34 -0200
> > Eduardo Habkost <ehabkost@redhat.com> wrote:
> >   
> > > On Thu, Oct 20, 2016 at 04:15:21PM +0200, Igor Mammedov wrote:  
> > > > On Thu, 20 Oct 2016 11:56:10 -0200
> > > > Eduardo Habkost <ehabkost@redhat.com> wrote:
> > > >     
> > > > > On Thu, Oct 20, 2016 at 03:42:15PM +0200, Igor Mammedov wrote:    
> > > > > > On Thu, 20 Oct 2016 21:11:38 +0800
> > > > > > Haozhong Zhang <haozhong.zhang@intel.com> wrote:
> > > > > >       
> > > > > > > On 10/20/16 14:34 +0200, Igor Mammedov wrote:      
> > > > > > > >On Thu, 20 Oct 2016 14:13:01 +0800
> > > > > > > >Haozhong Zhang <haozhong.zhang@intel.com> wrote:
> > > > > > > >        
> > > > > > > >> If a file is used as the backend of memory-backend-file and its size is
> > > > > > > >> not identical to the property 'size', the file will be truncated. For a
> > > > > > > >> file used as the backend of vNVDIMM, its data is expected to be
> > > > > > > >> persistent and the truncation may corrupt the existing data.        
> > > > > > > >I wonder if it's possible just skip 'size' property in your case instead
> > > > > > > >'notrunc' property. That way if size is not present one'd get actual size
> > > > > > > >using get_file_size() and set 'size' to it?
> > > > > > > >And if 'size' is provided and 'size' != file_size then error out.
> > > > > > > >        
> > > > > > > 
> > > > > > > I don't know how this can be implemented in QEMU. Specially, how does
> > > > > > > the memory-backend-file know it's used for vNVDIMM, so that it can
> > > > > > > skip the 'size' property?      
> > > > > > Does memory-backend-file needs to know that it's used by NVDIMM?
> > > > > > Looking at nvdimm_realize it doesn't as it's assumes 
> > > > > >   hostemem_size == pmem_size + label_size
> > > > > > 
> > > > > > I'd make hostmem_file.size optional and take size from file
> > > > > > and if 'size' is specified explictly require it to mach file size.
> > > > > > It's generic and has nothing to do with nvdimm.      
> > > > > 
> > > > > We can take size from file, or take size from the
> > > > > host_memory_backend_get_memory() callers.
> > > > > 
> > > > > Enumerating all sizes that QEMU can use as input:
> > > > > 
> > > > > A) Backend file size
> > > > > B) memory backend "size" option
> > > > > C) frontend-provided size (-numa size, -m, or pc-dimm "size"
> > > > >     property)    
> > > > -numa size affect only anon memory not backend backed one, for
> > > > backend baked memory we use memdev where size comes from backend
> > > > 
> > > > pc-dimm.size is readonly and isn't supposed to influence backend.size
> > > > 
> > > > I'd drop C option    
> > > 
> > > If C is not present, it should be, as it affects the guest ABI
> > > (and the ABI must never depend on the host you are running or
> > > backend configuration, only on the frontend configuration).  
> > I've meant that C should not affect behavior of backend.
> >   
> > > If we are dropping -numa size in favor of the
> > > memory-backend-provided size, that's a bug.  
> > -numa size is not applicable here as it's not using backends,
> > when backends are used it's -numa memdev instead in which case
> >    numa_info[nodenr].node_mem = object_property_get_int(o, "size", NULL);  
> 
> OK. My suggestion is to change this to not ignore the size
> option, but to validate it and/or do whatever necessary to get a
> MemoryRegion of the right size (your suggestion below to split
> the memory region would work too).
> 
> In other words, this should work:
> 
>   $ qemu -object memory-backend-file,id=mem0,mem-path=/tmp/mempath,size=2G \
>          -numa node,size=2G,memdev=mem0 -m 2G
> 
> this must error out:
> 
>   $ qemu -object memory-backend-file,id=mem0,mem-path=/tmp/mempath,size=2G \
>          -numa node,size=4G,memdev=mem0 -m 2G
> 
> and this should either error out, or result in a 1GB NUMA node
> (but never in a 2G NUMA node):
> 
>   $ qemu -object memory-backend-file,id=mem0,mem-path=/tmp/mempath,size=2G \
>          -numa node,size=1G,memdev=mem0 -m 1G
Looks like a bit of over-engineering and mixing together backend with frontend,
I don't see a compelling reason to support
  -numa size=X,memdev=foo
as just memdev=foo is sufficient

so I'd rather error out if user adds 'size' to -numa memdev=foo

[...]

> Probably there's only one case where behavior would be different
> than what I was thinking. I would like to be possible to specify
> only C (frontend size), and omit both A and B. For example:
> 
>   $ mkdir /tmp/mempath
>   $ qemu -object memory-backend-file,id=mem0,mem-path=/tmp/mempath \
>          -numa node,size=1G,memdev=mem0 -m 1G
> 
> I would like this command to create a 1G file inside /tmp/mempath
> automatically, without the need for an explicit size=1G argument
> to memory-backend-file.
This is still C where frontend manages allocation of backend
(i.e. changes backend's 'size' property) vs being just consumer
of whatever backend provides.
Purpose of backend is to create complete/initialized hostside
object regardless of which frontend uses it.
I see all properties of backend (including sizes) as belonging
to hostside which shouldn't be influenced by whatever frontend
it's used. And these properties are specified/managed only by mgmt
side explicitly when creating a backend (either via CLI or monitor/QMP).

In your example I'd error out with:
  "memory-backend-file: requires 'size' to create file in /tmp/mempath"
Igor Mammedov Oct. 21, 2016, 10:28 a.m. UTC | #33 
On Thu, 20 Oct 2016 14:59:11 -0200
Eduardo Habkost <ehabkost@redhat.com> wrote:

> On Thu, Oct 20, 2016 at 05:41:47PM +0200, Igor Mammedov wrote:
> > On Thu, 20 Oct 2016 13:15:31 -0200
> > Eduardo Habkost <ehabkost@redhat.com> wrote:
> >   
> > > On Thu, Oct 20, 2016 at 04:17:35PM +0200, Igor Mammedov wrote:  
> > > > On Thu, 20 Oct 2016 11:47:18 -0200
> > > > Eduardo Habkost <ehabkost@redhat.com> wrote:
> > > >     
> > > > > On Thu, Oct 20, 2016 at 09:33:53PM +0800, Haozhong Zhang wrote:    
> > > > > > On 10/20/16 11:21 -0200, Eduardo Habkost wrote:      
> > > > > > > On Thu, Oct 20, 2016 at 02:34:12PM +0200, Igor Mammedov wrote:      
> > > > > > > > On Thu, 20 Oct 2016 14:13:01 +0800
> > > > > > > > Haozhong Zhang <haozhong.zhang@intel.com> wrote:
> > > > > > > >       
> > > > > > > > > If a file is used as the backend of memory-backend-file and its size is
> > > > > > > > > not identical to the property 'size', the file will be truncated. For a
> > > > > > > > > file used as the backend of vNVDIMM, its data is expected to be
> > > > > > > > > persistent and the truncation may corrupt the existing data.      
> > > > > > > > I wonder if it's possible just skip 'size' property in your case instead
> > > > > > > > 'notrunc' property. That way if size is not present one'd get actual size
> > > > > > > > using get_file_size() and set 'size' to it?
> > > > > > > > And if 'size' is provided and 'size' != file_size then error out.      
> > > > > > > 
> > > > > > > I think it is valid to start with a zero-size file and then let
> > > > > > > QEMU extend it.      
> > > > > > 
> > > > > > For vNVDIMM, extending from zero-size file can be valid when a file is
> > > > > > first used. However, it's not valid for the second and following use
> > > > > > of the same file.
> > > > > >       
> > > > > > > But I agree we should: 1) make 'size' optional as
> > > > > > > you suggested; 2) never truncate the file to a smaller size.
> > > > > > >       
> > > > > > 
> > > > > > I will add another patch for this. Is there any way in QEMU to decide
> > > > > > whether a memory-backend-file object is used for vNVDIMM when the
> > > > > > object is being created? Or 'size' can be optional for all kinds of
> > > > > > usages?      
> > > > > 
> > > > > I believe 'size' can be optional for all usage, because at the
> > > > > moment the memory allocation code asks the backend for a memory
> > > > > region, it is supposed to know desired RAM size from the frontend
> > > > > configuration (-numa, -m, or "size" property of pc-dimm).    
> > > > 
> > > > nope, currently the size propagates other way around
> > > >  from back-end to front-end and not backwards    
> > > 
> > > I'd say that this is a bug. Frontend size is guest ABI and
> > > shouldn't be overridden by backend configuration if it's
> > > explicitly set.  
> > frontend.size is always <= backend.size
> > 
> > allocation specified when backend is created (-object/object_add)
> > and front end size if needed/used is <= backend size
> > 
> > so far code followed this design.  
> 
> This would work, but it doesn't happen in the case of -numa:
> 
>   $ ./x86_64-softmmu/qemu-system-x86_64 \
>     -object memory-backend-file,id=mem0,mem-path=/tmp/mempath,size=2G \
>     -numa node,size=1G,memdev=mem0 -m 1G
>   qemu-system-x86_64: total memory for NUMA nodes (0x80000000) should equal RAM size (0x40000000)
> 
> That's a bug we need to fix.
it's mismatch between option "-m 1G" and sum of memory provided by options
"-numa node,memdev=mem0 -object memory-backend-file,id=mem0,mem-path=/tmp/mempath,size=2G"

Adding -numa 'size=1G' is a bug in above example as it's not supported option,
but parse_numa somehow silently ignores it instead of failing.

Allowing to map only 1G RAM of provided by backend 2G is kind of
nonsense. Currently for pc-dim devices we allow 1:1 mapping only
and initial memory falls into the same category, if we consider
conversion of initial memory to set of pc-dimm devices then we
shouldn't allow to do partial mapping for '-numa memdev' either.
if we convert current numa memory mapping it pc-dimm terms it
would look like:
  -object memory-backend-file,id=mem0,mem-path=/tmp/mempath,size=G
  -device pc-dimm,memdev=mem0,node=0
  ...
and we could drop/obsolete "-m SIZE -numa [mem|memdev]... CLI options
Igor Mammedov Oct. 21, 2016, 11:07 a.m. UTC | #34 
On Fri, 21 Oct 2016 15:22:10 +0800
Haozhong Zhang <haozhong.zhang@intel.com> wrote:

> On 10/20/16 17:35 +0200, Igor Mammedov wrote:
> >On Thu, 20 Oct 2016 12:47:34 -0200
> >Eduardo Habkost <ehabkost@redhat.com> wrote:
> >  
> >> On Thu, Oct 20, 2016 at 04:15:21PM +0200, Igor Mammedov wrote:  
> >> > On Thu, 20 Oct 2016 11:56:10 -0200
> >> > Eduardo Habkost <ehabkost@redhat.com> wrote:
> >> >  
> >> > > On Thu, Oct 20, 2016 at 03:42:15PM +0200, Igor Mammedov wrote:  
> >> > > > On Thu, 20 Oct 2016 21:11:38 +0800
> >> > > > Haozhong Zhang <haozhong.zhang@intel.com> wrote:
> >> > > >  
> >> > > > > On 10/20/16 14:34 +0200, Igor Mammedov wrote:  
> >> > > > > >On Thu, 20 Oct 2016 14:13:01 +0800
> >> > > > > >Haozhong Zhang <haozhong.zhang@intel.com> wrote:
> >> > > > > >  
> >> > > > > >> If a file is used as the backend of memory-backend-file and its size is
> >> > > > > >> not identical to the property 'size', the file will be truncated. For a
> >> > > > > >> file used as the backend of vNVDIMM, its data is expected to be
> >> > > > > >> persistent and the truncation may corrupt the existing data.  
> >> > > > > >I wonder if it's possible just skip 'size' property in your case instead
> >> > > > > >'notrunc' property. That way if size is not present one'd get actual size
> >> > > > > >using get_file_size() and set 'size' to it?
> >> > > > > >And if 'size' is provided and 'size' != file_size then error out.
> >> > > > > >  
> >> > > > >
> >> > > > > I don't know how this can be implemented in QEMU. Specially, how does
> >> > > > > the memory-backend-file know it's used for vNVDIMM, so that it can
> >> > > > > skip the 'size' property?  
> >> > > > Does memory-backend-file needs to know that it's used by NVDIMM?
> >> > > > Looking at nvdimm_realize it doesn't as it's assumes
> >> > > >   hostemem_size == pmem_size + label_size
> >> > > >
> >> > > > I'd make hostmem_file.size optional and take size from file
> >> > > > and if 'size' is specified explictly require it to mach file size.
> >> > > > It's generic and has nothing to do with nvdimm.  
> >> > >
> >> > > We can take size from file, or take size from the
> >> > > host_memory_backend_get_memory() callers.
> >> > >
> >> > > Enumerating all sizes that QEMU can use as input:
> >> > >
> >> > > A) Backend file size
> >> > > B) memory backend "size" option
> >> > > C) frontend-provided size (-numa size, -m, or pc-dimm "size"
> >> > >     property)  
> >> > -numa size affect only anon memory not backend backed one, for
> >> > backend baked memory we use memdev where size comes from backend
> >> >
> >> > pc-dimm.size is readonly and isn't supposed to influence backend.size
> >> >
> >> > I'd drop C option  
> >>
> >> If C is not present, it should be, as it affects the guest ABI
> >> (and the ABI must never depend on the host you are running or
> >> backend configuration, only on the frontend configuration).  
> >I've meant that C should not affect behavior of backend.
> >  
> >> If we are dropping -numa size in favor of the
> >> memory-backend-provided size, that's a bug.  
> >-numa size is not applicable here as it's not using backends,
> >when backends are used it's -numa memdev instead in which case
> >   numa_info[nodenr].node_mem = object_property_get_int(o, "size", NULL);
> >  
> >>  
> >> >  
> >> > >
> >> > > My suggestion is:
> >> > > * B should be optional.
> >> > > * If B is omitted, we should never truncate the file to a smaller
> >> > >   size.  
> >> > i.e. derive backend.size from filesize if possible (i.e. not hugepages)
> >> >  
> >> > > * If B is omitted, we can use C as the size when mapping the
> >> > >   file.  
> >> > frontend size is the size that's mapped into guest address space.
> >> > it should not influence backend's size in backward direction.
> >> > You may notice pc-dimm.size is not user settable (readonly) property.  
> >>
> >> Frontend size will not influence backend size, it will just
> >> affect the size of the memory region the frontend code will ask
> >> the backend to provide.
> >>
> >> In other words: I believe host_memory_backend_get_memory() needs
> >> a 'size' argument, and that memory allocation could be optionally
> >> delayed to the host_memory_backend_get_memory() call. This way,
> >> we don't need a backend size at all, unless we want the backend
> >> to truncate files or preallocate memory for us.  
> >To not complicate things I'd keep current behavior of
> >  host_memory_backend_get_memory()
> >i.e return MR for all the baked memory and then frontend
> >can split and map it into guest address space as it sees fit
> >using aliases for non trivial cases taking in account frontend's
> >own size/label_size/whatnot properties.
> >That's what NVDIMM does now, it gets MR for whole file and
> >the splits it on data and label areas and maps into GA only
> >data part using memory_region_init_alias().
> >  
> 
> As NVDIMM label is mentioned here, I realize a case that extending
> file size would fail:
> 
> NVDIMM labels record the namespace information of the data area and
> should be persistently stored. The current vNVDIMM implementation in
> QEMU always stores and finds those labels at the end of the given
> backend storage. If a larger size B is given and the backend file is
> extended, QEMU will not be able to find the labels stored on the
> original file, and hence cannot present the same namespaces to guest.
>
> This problem can fixed by deferring the allocation to
> host_memory_backend_get_memory(), and adding a parameter 'notrunc' to
> it to specify the truncation behavior. If no truncation is specified
> and B > A, QEMU will report error and stop.
Lets not go there (I mean extending/deferring) and keep thing simple,
backend object should be completely initialized upon completion of
host_memory_backend_memory_complete() (including creation/mapping of
whatever memory it's backed by) or fail if it can't do so.


How about following behavior:

 1) memory-backend-file,mem-path=/some_dir,size=2G
    - uses truncate to extend temporary file created in "mem-path" to 'size'
    for this case to work 'size' is mandatory

 2) memory-backend-file,mem-path=/existing_file,size=2G
    - uses truncate to extend/shrink file "mem-path" to 'size'
    for this case 'size' could be made optional,
    if we take in account that backend could be used as persistent
    storage then shrinking or extending "mem-path" would be corruption
    as backend has no idea about internal layout if mapped file.
    We can do something like this here:

    if (is_size_opt_provided and size_of(mem-path) != 0) {
       error_out with "mem-path=foo size XXX doesn't match 'size=xxx' option"
    } else if (is_size_opt_provided and size_of(mem-path) == 0) {
       // may be we don't need this case and
       // just fold this in above error case
       truncate(mem-path) // extend/shrink
    } else {
      set_size_opt(size_of(mem-path))
    }
Haozhong Zhang Oct. 21, 2016, 11:25 a.m. UTC | #35 
On 10/21/16 13:07 +0200, Igor Mammedov wrote:
>On Fri, 21 Oct 2016 15:22:10 +0800
>Haozhong Zhang <haozhong.zhang@intel.com> wrote:
>
>> On 10/20/16 17:35 +0200, Igor Mammedov wrote:
>> >On Thu, 20 Oct 2016 12:47:34 -0200
>> >Eduardo Habkost <ehabkost@redhat.com> wrote:
>> >
>> >> On Thu, Oct 20, 2016 at 04:15:21PM +0200, Igor Mammedov wrote:
>> >> > On Thu, 20 Oct 2016 11:56:10 -0200
>> >> > Eduardo Habkost <ehabkost@redhat.com> wrote:
>> >> >
>> >> > > On Thu, Oct 20, 2016 at 03:42:15PM +0200, Igor Mammedov wrote:
>> >> > > > On Thu, 20 Oct 2016 21:11:38 +0800
>> >> > > > Haozhong Zhang <haozhong.zhang@intel.com> wrote:
>> >> > > >
>> >> > > > > On 10/20/16 14:34 +0200, Igor Mammedov wrote:
>> >> > > > > >On Thu, 20 Oct 2016 14:13:01 +0800
>> >> > > > > >Haozhong Zhang <haozhong.zhang@intel.com> wrote:
>> >> > > > > >
>> >> > > > > >> If a file is used as the backend of memory-backend-file and its size is
>> >> > > > > >> not identical to the property 'size', the file will be truncated. For a
>> >> > > > > >> file used as the backend of vNVDIMM, its data is expected to be
>> >> > > > > >> persistent and the truncation may corrupt the existing data.
>> >> > > > > >I wonder if it's possible just skip 'size' property in your case instead
>> >> > > > > >'notrunc' property. That way if size is not present one'd get actual size
>> >> > > > > >using get_file_size() and set 'size' to it?
>> >> > > > > >And if 'size' is provided and 'size' != file_size then error out.
>> >> > > > > >
>> >> > > > >
>> >> > > > > I don't know how this can be implemented in QEMU. Specially, how does
>> >> > > > > the memory-backend-file know it's used for vNVDIMM, so that it can
>> >> > > > > skip the 'size' property?
>> >> > > > Does memory-backend-file needs to know that it's used by NVDIMM?
>> >> > > > Looking at nvdimm_realize it doesn't as it's assumes
>> >> > > >   hostemem_size == pmem_size + label_size
>> >> > > >
>> >> > > > I'd make hostmem_file.size optional and take size from file
>> >> > > > and if 'size' is specified explictly require it to mach file size.
>> >> > > > It's generic and has nothing to do with nvdimm.
>> >> > >
>> >> > > We can take size from file, or take size from the
>> >> > > host_memory_backend_get_memory() callers.
>> >> > >
>> >> > > Enumerating all sizes that QEMU can use as input:
>> >> > >
>> >> > > A) Backend file size
>> >> > > B) memory backend "size" option
>> >> > > C) frontend-provided size (-numa size, -m, or pc-dimm "size"
>> >> > >     property)
>> >> > -numa size affect only anon memory not backend backed one, for
>> >> > backend baked memory we use memdev where size comes from backend
>> >> >
>> >> > pc-dimm.size is readonly and isn't supposed to influence backend.size
>> >> >
>> >> > I'd drop C option
>> >>
>> >> If C is not present, it should be, as it affects the guest ABI
>> >> (and the ABI must never depend on the host you are running or
>> >> backend configuration, only on the frontend configuration).
>> >I've meant that C should not affect behavior of backend.
>> >
>> >> If we are dropping -numa size in favor of the
>> >> memory-backend-provided size, that's a bug.
>> >-numa size is not applicable here as it's not using backends,
>> >when backends are used it's -numa memdev instead in which case
>> >   numa_info[nodenr].node_mem = object_property_get_int(o, "size", NULL);
>> >
>> >>
>> >> >
>> >> > >
>> >> > > My suggestion is:
>> >> > > * B should be optional.
>> >> > > * If B is omitted, we should never truncate the file to a smaller
>> >> > >   size.
>> >> > i.e. derive backend.size from filesize if possible (i.e. not hugepages)
>> >> >
>> >> > > * If B is omitted, we can use C as the size when mapping the
>> >> > >   file.
>> >> > frontend size is the size that's mapped into guest address space.
>> >> > it should not influence backend's size in backward direction.
>> >> > You may notice pc-dimm.size is not user settable (readonly) property.
>> >>
>> >> Frontend size will not influence backend size, it will just
>> >> affect the size of the memory region the frontend code will ask
>> >> the backend to provide.
>> >>
>> >> In other words: I believe host_memory_backend_get_memory() needs
>> >> a 'size' argument, and that memory allocation could be optionally
>> >> delayed to the host_memory_backend_get_memory() call. This way,
>> >> we don't need a backend size at all, unless we want the backend
>> >> to truncate files or preallocate memory for us.
>> >To not complicate things I'd keep current behavior of
>> >  host_memory_backend_get_memory()
>> >i.e return MR for all the baked memory and then frontend
>> >can split and map it into guest address space as it sees fit
>> >using aliases for non trivial cases taking in account frontend's
>> >own size/label_size/whatnot properties.
>> >That's what NVDIMM does now, it gets MR for whole file and
>> >the splits it on data and label areas and maps into GA only
>> >data part using memory_region_init_alias().
>> >
>>
>> As NVDIMM label is mentioned here, I realize a case that extending
>> file size would fail:
>>
>> NVDIMM labels record the namespace information of the data area and
>> should be persistently stored. The current vNVDIMM implementation in
>> QEMU always stores and finds those labels at the end of the given
>> backend storage. If a larger size B is given and the backend file is
>> extended, QEMU will not be able to find the labels stored on the
>> original file, and hence cannot present the same namespaces to guest.
>>
>> This problem can fixed by deferring the allocation to
>> host_memory_backend_get_memory(), and adding a parameter 'notrunc' to
>> it to specify the truncation behavior. If no truncation is specified
>> and B > A, QEMU will report error and stop.
>Lets not go there (I mean extending/deferring) and keep thing simple,
>backend object should be completely initialized upon completion of
>host_memory_backend_memory_complete() (including creation/mapping of
>whatever memory it's backed by) or fail if it can't do so.
>
>
>How about following behavior:
>
> 1) memory-backend-file,mem-path=/some_dir,size=2G
>    - uses truncate to extend temporary file created in "mem-path" to 'size'
>    for this case to work 'size' is mandatory
>
> 2) memory-backend-file,mem-path=/existing_file,size=2G
>    - uses truncate to extend/shrink file "mem-path" to 'size'
>    for this case 'size' could be made optional,
>    if we take in account that backend could be used as persistent
>    storage then shrinking or extending "mem-path" would be corruption
>    as backend has no idea about internal layout if mapped file.
>    We can do something like this here:
>
>    if (is_size_opt_provided and size_of(mem-path) != 0) {
>       error_out with "mem-path=foo size XXX doesn't match 'size=xxx' option"
>    } else if (is_size_opt_provided and size_of(mem-path) == 0) {
>       // may be we don't need this case and
>       // just fold this in above error case
>       truncate(mem-path) // extend/shrink
>    } else {
>      set_size_opt(size_of(mem-path))
>    }

Agree. Let's wait for Eduardo's comments. If he has no objection, I'll
prepare a patch in this way.

Thanks,
Haozhong
Eduardo Habkost Oct. 21, 2016, 11:44 a.m. UTC | #36 
On Fri, Oct 21, 2016 at 12:28:28PM +0200, Igor Mammedov wrote:
> On Thu, 20 Oct 2016 14:59:11 -0200
> Eduardo Habkost <ehabkost@redhat.com> wrote:
> 
> > On Thu, Oct 20, 2016 at 05:41:47PM +0200, Igor Mammedov wrote:
> > > On Thu, 20 Oct 2016 13:15:31 -0200
> > > Eduardo Habkost <ehabkost@redhat.com> wrote:
> > >   
> > > > On Thu, Oct 20, 2016 at 04:17:35PM +0200, Igor Mammedov wrote:  
> > > > > On Thu, 20 Oct 2016 11:47:18 -0200
> > > > > Eduardo Habkost <ehabkost@redhat.com> wrote:
> > > > >     
> > > > > > On Thu, Oct 20, 2016 at 09:33:53PM +0800, Haozhong Zhang wrote:    
> > > > > > > On 10/20/16 11:21 -0200, Eduardo Habkost wrote:      
> > > > > > > > On Thu, Oct 20, 2016 at 02:34:12PM +0200, Igor Mammedov wrote:      
> > > > > > > > > On Thu, 20 Oct 2016 14:13:01 +0800
> > > > > > > > > Haozhong Zhang <haozhong.zhang@intel.com> wrote:
> > > > > > > > >       
> > > > > > > > > > If a file is used as the backend of memory-backend-file and its size is
> > > > > > > > > > not identical to the property 'size', the file will be truncated. For a
> > > > > > > > > > file used as the backend of vNVDIMM, its data is expected to be
> > > > > > > > > > persistent and the truncation may corrupt the existing data.      
> > > > > > > > > I wonder if it's possible just skip 'size' property in your case instead
> > > > > > > > > 'notrunc' property. That way if size is not present one'd get actual size
> > > > > > > > > using get_file_size() and set 'size' to it?
> > > > > > > > > And if 'size' is provided and 'size' != file_size then error out.      
> > > > > > > > 
> > > > > > > > I think it is valid to start with a zero-size file and then let
> > > > > > > > QEMU extend it.      
> > > > > > > 
> > > > > > > For vNVDIMM, extending from zero-size file can be valid when a file is
> > > > > > > first used. However, it's not valid for the second and following use
> > > > > > > of the same file.
> > > > > > >       
> > > > > > > > But I agree we should: 1) make 'size' optional as
> > > > > > > > you suggested; 2) never truncate the file to a smaller size.
> > > > > > > >       
> > > > > > > 
> > > > > > > I will add another patch for this. Is there any way in QEMU to decide
> > > > > > > whether a memory-backend-file object is used for vNVDIMM when the
> > > > > > > object is being created? Or 'size' can be optional for all kinds of
> > > > > > > usages?      
> > > > > > 
> > > > > > I believe 'size' can be optional for all usage, because at the
> > > > > > moment the memory allocation code asks the backend for a memory
> > > > > > region, it is supposed to know desired RAM size from the frontend
> > > > > > configuration (-numa, -m, or "size" property of pc-dimm).    
> > > > > 
> > > > > nope, currently the size propagates other way around
> > > > >  from back-end to front-end and not backwards    
> > > > 
> > > > I'd say that this is a bug. Frontend size is guest ABI and
> > > > shouldn't be overridden by backend configuration if it's
> > > > explicitly set.  
> > > frontend.size is always <= backend.size
> > > 
> > > allocation specified when backend is created (-object/object_add)
> > > and front end size if needed/used is <= backend size
> > > 
> > > so far code followed this design.  
> > 
> > This would work, but it doesn't happen in the case of -numa:
> > 
> >   $ ./x86_64-softmmu/qemu-system-x86_64 \
> >     -object memory-backend-file,id=mem0,mem-path=/tmp/mempath,size=2G \
> >     -numa node,size=1G,memdev=mem0 -m 1G
> >   qemu-system-x86_64: total memory for NUMA nodes (0x80000000) should equal RAM size (0x40000000)
> > 
> > That's a bug we need to fix.
> it's mismatch between option "-m 1G" and sum of memory provided by options
> "-numa node,memdev=mem0 -object memory-backend-file,id=mem0,mem-path=/tmp/mempath,size=2G"
> 
> Adding -numa 'size=1G' is a bug in above example as it's not supported option,
> but parse_numa somehow silently ignores it instead of failing.

Exactly. It should fail, at the very least.
Eduardo Habkost Oct. 21, 2016, 11:53 a.m. UTC | #37 
On Fri, Oct 21, 2016 at 11:31:41AM +0200, Igor Mammedov wrote:
> On Thu, 20 Oct 2016 14:56:58 -0200
> Eduardo Habkost <ehabkost@redhat.com> wrote:
> 
> > On Thu, Oct 20, 2016 at 05:35:38PM +0200, Igor Mammedov wrote:
> > > On Thu, 20 Oct 2016 12:47:34 -0200
> > > Eduardo Habkost <ehabkost@redhat.com> wrote:
> > >   
> > > > On Thu, Oct 20, 2016 at 04:15:21PM +0200, Igor Mammedov wrote:  
> > > > > On Thu, 20 Oct 2016 11:56:10 -0200
> > > > > Eduardo Habkost <ehabkost@redhat.com> wrote:
> > > > >     
> > > > > > On Thu, Oct 20, 2016 at 03:42:15PM +0200, Igor Mammedov wrote:    
> > > > > > > On Thu, 20 Oct 2016 21:11:38 +0800
> > > > > > > Haozhong Zhang <haozhong.zhang@intel.com> wrote:
> > > > > > >       
> > > > > > > > On 10/20/16 14:34 +0200, Igor Mammedov wrote:      
> > > > > > > > >On Thu, 20 Oct 2016 14:13:01 +0800
> > > > > > > > >Haozhong Zhang <haozhong.zhang@intel.com> wrote:
> > > > > > > > >        
> > > > > > > > >> If a file is used as the backend of memory-backend-file and its size is
> > > > > > > > >> not identical to the property 'size', the file will be truncated. For a
> > > > > > > > >> file used as the backend of vNVDIMM, its data is expected to be
> > > > > > > > >> persistent and the truncation may corrupt the existing data.        
> > > > > > > > >I wonder if it's possible just skip 'size' property in your case instead
> > > > > > > > >'notrunc' property. That way if size is not present one'd get actual size
> > > > > > > > >using get_file_size() and set 'size' to it?
> > > > > > > > >And if 'size' is provided and 'size' != file_size then error out.
> > > > > > > > >        
> > > > > > > > 
> > > > > > > > I don't know how this can be implemented in QEMU. Specially, how does
> > > > > > > > the memory-backend-file know it's used for vNVDIMM, so that it can
> > > > > > > > skip the 'size' property?      
> > > > > > > Does memory-backend-file needs to know that it's used by NVDIMM?
> > > > > > > Looking at nvdimm_realize it doesn't as it's assumes 
> > > > > > >   hostemem_size == pmem_size + label_size
> > > > > > > 
> > > > > > > I'd make hostmem_file.size optional and take size from file
> > > > > > > and if 'size' is specified explictly require it to mach file size.
> > > > > > > It's generic and has nothing to do with nvdimm.      
> > > > > > 
> > > > > > We can take size from file, or take size from the
> > > > > > host_memory_backend_get_memory() callers.
> > > > > > 
> > > > > > Enumerating all sizes that QEMU can use as input:
> > > > > > 
> > > > > > A) Backend file size
> > > > > > B) memory backend "size" option
> > > > > > C) frontend-provided size (-numa size, -m, or pc-dimm "size"
> > > > > >     property)    
> > > > > -numa size affect only anon memory not backend backed one, for
> > > > > backend baked memory we use memdev where size comes from backend
> > > > > 
> > > > > pc-dimm.size is readonly and isn't supposed to influence backend.size
> > > > > 
> > > > > I'd drop C option    
> > > > 
> > > > If C is not present, it should be, as it affects the guest ABI
> > > > (and the ABI must never depend on the host you are running or
> > > > backend configuration, only on the frontend configuration).  
> > > I've meant that C should not affect behavior of backend.
> > >   
> > > > If we are dropping -numa size in favor of the
> > > > memory-backend-provided size, that's a bug.  
> > > -numa size is not applicable here as it's not using backends,
> > > when backends are used it's -numa memdev instead in which case
> > >    numa_info[nodenr].node_mem = object_property_get_int(o, "size", NULL);  
> > 
> > OK. My suggestion is to change this to not ignore the size
> > option, but to validate it and/or do whatever necessary to get a
> > MemoryRegion of the right size (your suggestion below to split
> > the memory region would work too).
> > 
> > In other words, this should work:
> > 
> >   $ qemu -object memory-backend-file,id=mem0,mem-path=/tmp/mempath,size=2G \
> >          -numa node,size=2G,memdev=mem0 -m 2G
> > 
> > this must error out:
> > 
> >   $ qemu -object memory-backend-file,id=mem0,mem-path=/tmp/mempath,size=2G \
> >          -numa node,size=4G,memdev=mem0 -m 2G
> > 
> > and this should either error out, or result in a 1GB NUMA node
> > (but never in a 2G NUMA node):
> > 
> >   $ qemu -object memory-backend-file,id=mem0,mem-path=/tmp/mempath,size=2G \
> >          -numa node,size=1G,memdev=mem0 -m 1G
> Looks like a bit of over-engineering and mixing together backend with frontend,
> I don't see a compelling reason to support
>   -numa size=X,memdev=foo
> as just memdev=foo is sufficient
> 
> so I'd rather error out if user adds 'size' to -numa memdev=foo

Erroring out would be good enough. I won't argue to allow people
to use only a portion of the backend-provided memory unless we
have a real use case for it.

> 
> [...]
> 
> > Probably there's only one case where behavior would be different
> > than what I was thinking. I would like to be possible to specify
> > only C (frontend size), and omit both A and B. For example:
> > 
> >   $ mkdir /tmp/mempath
> >   $ qemu -object memory-backend-file,id=mem0,mem-path=/tmp/mempath \
> >          -numa node,size=1G,memdev=mem0 -m 1G
> > 
> > I would like this command to create a 1G file inside /tmp/mempath
> > automatically, without the need for an explicit size=1G argument
> > to memory-backend-file.
> This is still C where frontend manages allocation of backend
> (i.e. changes backend's 'size' property) vs being just consumer
> of whatever backend provides.

I don't want it to change the 'size' property of the backend, I
just want to allow the backend to allocate memory on demand in
case size was not specified, to make the command-line interface
simpler and less error-prone.

> Purpose of backend is to create complete/initialized hostside
> object regardless of which frontend uses it.
> I see all properties of backend (including sizes) as belonging
> to hostside which shouldn't be influenced by whatever frontend
> it's used. And these properties are specified/managed only by mgmt
> side explicitly when creating a backend (either via CLI or monitor/QMP).

I agree completely with the above paragraph, but we probably have
different definitions of "complete/initialized". To me,
"complete" doesn't need to include allocation (unless prealloc is
required), and it's OK to let the backend allocate memory on
demand to simplify the command-line interface.

> 
> In your example I'd error out with:
>   "memory-backend-file: requires 'size' to create file in /tmp/mempath"

This is what should happen today, yes. But I would like to make
'size' optional later, to make the interface simpler.

Anyway, let's wait until I have an actual RFC (which may take a
while as it's not high priority to me), otherwise it would be
just a theoretical discussion.

In the meantime, we can change the code to error out on the
examples I gave.
Eduardo Habkost Oct. 21, 2016, 11:56 a.m. UTC | #38 
On Fri, Oct 21, 2016 at 01:07:00PM +0200, Igor Mammedov wrote:
[...]
> How about following behavior:
> 
>  1) memory-backend-file,mem-path=/some_dir,size=2G
>     - uses truncate to extend temporary file created in "mem-path" to 'size'
>     for this case to work 'size' is mandatory
> 
>  2) memory-backend-file,mem-path=/existing_file,size=2G
>     - uses truncate to extend/shrink file "mem-path" to 'size'
>     for this case 'size' could be made optional,
>     if we take in account that backend could be used as persistent
>     storage then shrinking or extending "mem-path" would be corruption
>     as backend has no idea about internal layout if mapped file.
>     We can do something like this here:
> 
>     if (is_size_opt_provided and size_of(mem-path) != 0) {
>        error_out with "mem-path=foo size XXX doesn't match 'size=xxx' option"
>     } else if (is_size_opt_provided and size_of(mem-path) == 0) {
>        // may be we don't need this case and
>        // just fold this in above error case
>        truncate(mem-path) // extend/shrink
>     } else {
>       set_size_opt(size_of(mem-path))
>     }

Agreed.
Igor Mammedov Oct. 21, 2016, 1:26 p.m. UTC | #39 
On Fri, 21 Oct 2016 09:53:43 -0200
Eduardo Habkost <ehabkost@redhat.com> wrote:

> On Fri, Oct 21, 2016 at 11:31:41AM +0200, Igor Mammedov wrote:
> > On Thu, 20 Oct 2016 14:56:58 -0200
> > Eduardo Habkost <ehabkost@redhat.com> wrote:
> >   
> > > On Thu, Oct 20, 2016 at 05:35:38PM +0200, Igor Mammedov wrote:  
> > > > On Thu, 20 Oct 2016 12:47:34 -0200
> > > > Eduardo Habkost <ehabkost@redhat.com> wrote:
> > > >     
> > > > > On Thu, Oct 20, 2016 at 04:15:21PM +0200, Igor Mammedov wrote:    
> > > > > > On Thu, 20 Oct 2016 11:56:10 -0200
> > > > > > Eduardo Habkost <ehabkost@redhat.com> wrote:
> > > > > >       
> > > > > > > On Thu, Oct 20, 2016 at 03:42:15PM +0200, Igor Mammedov wrote:      
> > > > > > > > On Thu, 20 Oct 2016 21:11:38 +0800
> > > > > > > > Haozhong Zhang <haozhong.zhang@intel.com> wrote:
> > > > > > > >         
> > > > > > > > > On 10/20/16 14:34 +0200, Igor Mammedov wrote:        
> > > > > > > > > >On Thu, 20 Oct 2016 14:13:01 +0800
> > > > > > > > > >Haozhong Zhang <haozhong.zhang@intel.com> wrote:
> > > > > > > > > >          
> > > > > > > > > >> If a file is used as the backend of memory-backend-file and its size is
> > > > > > > > > >> not identical to the property 'size', the file will be truncated. For a
> > > > > > > > > >> file used as the backend of vNVDIMM, its data is expected to be
> > > > > > > > > >> persistent and the truncation may corrupt the existing data.          
> > > > > > > > > >I wonder if it's possible just skip 'size' property in your case instead
> > > > > > > > > >'notrunc' property. That way if size is not present one'd get actual size
> > > > > > > > > >using get_file_size() and set 'size' to it?
> > > > > > > > > >And if 'size' is provided and 'size' != file_size then error out.
> > > > > > > > > >          
> > > > > > > > > 
> > > > > > > > > I don't know how this can be implemented in QEMU. Specially, how does
> > > > > > > > > the memory-backend-file know it's used for vNVDIMM, so that it can
> > > > > > > > > skip the 'size' property?        
> > > > > > > > Does memory-backend-file needs to know that it's used by NVDIMM?
> > > > > > > > Looking at nvdimm_realize it doesn't as it's assumes 
> > > > > > > >   hostemem_size == pmem_size + label_size
> > > > > > > > 
> > > > > > > > I'd make hostmem_file.size optional and take size from file
> > > > > > > > and if 'size' is specified explictly require it to mach file size.
> > > > > > > > It's generic and has nothing to do with nvdimm.        
> > > > > > > 
> > > > > > > We can take size from file, or take size from the
> > > > > > > host_memory_backend_get_memory() callers.
> > > > > > > 
> > > > > > > Enumerating all sizes that QEMU can use as input:
> > > > > > > 
> > > > > > > A) Backend file size
> > > > > > > B) memory backend "size" option
> > > > > > > C) frontend-provided size (-numa size, -m, or pc-dimm "size"
> > > > > > >     property)      
> > > > > > -numa size affect only anon memory not backend backed one, for
> > > > > > backend baked memory we use memdev where size comes from backend
> > > > > > 
> > > > > > pc-dimm.size is readonly and isn't supposed to influence backend.size
> > > > > > 
> > > > > > I'd drop C option      
> > > > > 
> > > > > If C is not present, it should be, as it affects the guest ABI
> > > > > (and the ABI must never depend on the host you are running or
> > > > > backend configuration, only on the frontend configuration).    
> > > > I've meant that C should not affect behavior of backend.
> > > >     
> > > > > If we are dropping -numa size in favor of the
> > > > > memory-backend-provided size, that's a bug.    
> > > > -numa size is not applicable here as it's not using backends,
> > > > when backends are used it's -numa memdev instead in which case
> > > >    numa_info[nodenr].node_mem = object_property_get_int(o, "size", NULL);    
> > > 
> > > OK. My suggestion is to change this to not ignore the size
> > > option, but to validate it and/or do whatever necessary to get a
> > > MemoryRegion of the right size (your suggestion below to split
> > > the memory region would work too).
> > > 
> > > In other words, this should work:
> > > 
> > >   $ qemu -object memory-backend-file,id=mem0,mem-path=/tmp/mempath,size=2G \
> > >          -numa node,size=2G,memdev=mem0 -m 2G
> > > 
> > > this must error out:
> > > 
> > >   $ qemu -object memory-backend-file,id=mem0,mem-path=/tmp/mempath,size=2G \
> > >          -numa node,size=4G,memdev=mem0 -m 2G
> > > 
> > > and this should either error out, or result in a 1GB NUMA node
> > > (but never in a 2G NUMA node):
> > > 
> > >   $ qemu -object memory-backend-file,id=mem0,mem-path=/tmp/mempath,size=2G \
> > >          -numa node,size=1G,memdev=mem0 -m 1G  
> > Looks like a bit of over-engineering and mixing together backend with frontend,
> > I don't see a compelling reason to support
> >   -numa size=X,memdev=foo
> > as just memdev=foo is sufficient
> > 
> > so I'd rather error out if user adds 'size' to -numa memdev=foo  
> 
> Erroring out would be good enough. I won't argue to allow people
> to use only a portion of the backend-provided memory unless we
> have a real use case for it.
> 
> > 
> > [...]
> >   
> > > Probably there's only one case where behavior would be different
> > > than what I was thinking. I would like to be possible to specify
> > > only C (frontend size), and omit both A and B. For example:
> > > 
> > >   $ mkdir /tmp/mempath
> > >   $ qemu -object memory-backend-file,id=mem0,mem-path=/tmp/mempath \
> > >          -numa node,size=1G,memdev=mem0 -m 1G
> > > 
> > > I would like this command to create a 1G file inside /tmp/mempath
> > > automatically, without the need for an explicit size=1G argument
> > > to memory-backend-file.  
> > This is still C where frontend manages allocation of backend
> > (i.e. changes backend's 'size' property) vs being just consumer
> > of whatever backend provides.  
> 
> I don't want it to change the 'size' property of the backend, I
> just want to allow the backend to allocate memory on demand in
> case size was not specified, to make the command-line interface
> simpler and less error-prone.
Allocation on demand is changing backend.size property and at that
possibly making frontend to dictate backing file size. And that's
brings more confusion since we would have user settable backend.size
and frontend.size.

That looks to me more error prone and more complicated.
Currently it's clear filename/size and memory region that
represents that file/size comes only from backend.
And in frontends (pc-dimm/nvdimm) size is what is mapped into
guest's GPA, which is full or subset of backends size depending
on frontend device and it's options (optional nvdimm.label-size for example)


> > Purpose of backend is to create complete/initialized hostside
> > object regardless of which frontend uses it.
> > I see all properties of backend (including sizes) as belonging
> > to hostside which shouldn't be influenced by whatever frontend
> > it's used. And these properties are specified/managed only by mgmt
> > side explicitly when creating a backend (either via CLI or monitor/QMP).  
> 
> I agree completely with the above paragraph, but we probably have
> different definitions of "complete/initialized". To me,
> "complete" doesn't need to include allocation (unless prealloc is
> required), and it's OK to let the backend allocate memory on
> demand to simplify the command-line interface.
Yep, I include allocation into definition of completeness.

Now lets imagine allocation on demand when frontend calls
backend.get_memory_region() callback and hotplug flow in case
of allocation failure:

# object_add memory-backend-file,id=mem0,mem-path=/tmp
# device_add pc-dimm,size=foo,memdev=mem0
 qemu would fail here and now pc-dimm code should take care
 of rolling back whatever changes it done to machine
 and then management side would need to delete backend
 as cleanup.

vs current way where object_add returned backend includes allocation:
# object_add memory-backend-file,id=mem0,mem-path=/tmp,size=foo
   fail here without need to do cleanups and not requiring from
   frontends to handle allocation failure.

Maybe I'm saying it badly but what I'm trying to say is that
 * backend should manage/acquire host resources
 * fontend should manage device representation to guest
pretty clear separation of roles

and I see setting host filenames, filesizes, mapping resources
into QEMU, ...  is backend's task.

Otherwise we could just merge frontends with backends and end up
with only one option instead of separate options for backend and
frontend creation, but then it would rather confusing what
properties a hostside vs guestside.


> > 
> > In your example I'd error out with:
> >   "memory-backend-file: requires 'size' to create file in /tmp/mempath"  
> 
> This is what should happen today, yes. But I would like to make
> 'size' optional later, to make the interface simpler.
I'm fine with 'size' being optional as far as it's
implicitly derived from backing file.


> Anyway, let's wait until I have an actual RFC (which may take a
> while as it's not high priority to me), otherwise it would be
> just a theoretical discussion.
> 
> In the meantime, we can change the code to error out on the
> examples I gave.
>
Eduardo Habkost Oct. 24, 2016, 1:10 p.m. UTC | #40 
On Thu, Oct 20, 2016 at 03:55:22PM +0200, Kevin Wolf wrote:
> Am 20.10.2016 um 14:34 hat Igor Mammedov geschrieben:
> > >  #ifdef __linux__
> > > +static uint64_t get_file_size(const char *path, Error **errp)
> > Maybe QEMU laredy has an utility to do it that could be shared,
> > CCing block maintainers.
> 
> We have quite a bit of code for determining the right size of a file
> (including block devices) on different platforms and devices. See the
> .bdrv_getlength implementations in raw-posix.c and raw-win32.c.
> 
> However, none of them are made for consumption outside the block layer.

There's a patch on qemu-devel archives from 2015:
  Subject [PATCH v7 11/35] util: introduce qemu_file_getlength()
it could be reused here.
Haozhong Zhang Oct. 25, 2016, 6:42 a.m. UTC | #41 
On 10/24/16 11:10 -0200, Eduardo Habkost wrote:
>On Thu, Oct 20, 2016 at 03:55:22PM +0200, Kevin Wolf wrote:
>> Am 20.10.2016 um 14:34 hat Igor Mammedov geschrieben:
>> > >  #ifdef __linux__
>> > > +static uint64_t get_file_size(const char *path, Error **errp)
>> > Maybe QEMU laredy has an utility to do it that could be shared,
>> > CCing block maintainers.
>>
>> We have quite a bit of code for determining the right size of a file
>> (including block devices) on different platforms and devices. See the
>> .bdrv_getlength implementations in raw-posix.c and raw-win32.c.
>>
>> However, none of them are made for consumption outside the block layer.
>
>There's a patch on qemu-devel archives from 2015:
>  Subject [PATCH v7 11/35] util: introduce qemu_file_getlength()
>it could be reused here.
>

My new version patches
(https://lists.nongnu.org/archive/html/qemu-devel/2016-10/msg05519.html)
use the same approach to get the file size except that I didn't make
it a common function. I'll move it to a common function in the next
version.

Thanks,
Haozhong
Eduardo Habkost Oct. 25, 2016, 10:01 a.m. UTC | #42 
On Tue, Oct 25, 2016 at 02:42:41PM +0800, Haozhong Zhang wrote:
> On 10/24/16 11:10 -0200, Eduardo Habkost wrote:
> > On Thu, Oct 20, 2016 at 03:55:22PM +0200, Kevin Wolf wrote:
> > > Am 20.10.2016 um 14:34 hat Igor Mammedov geschrieben:
> > > > >  #ifdef __linux__
> > > > > +static uint64_t get_file_size(const char *path, Error **errp)
> > > > Maybe QEMU laredy has an utility to do it that could be shared,
> > > > CCing block maintainers.
> > > 
> > > We have quite a bit of code for determining the right size of a file
> > > (including block devices) on different platforms and devices. See the
> > > .bdrv_getlength implementations in raw-posix.c and raw-win32.c.
> > > 
> > > However, none of them are made for consumption outside the block layer.
> > 
> > There's a patch on qemu-devel archives from 2015:
> >  Subject [PATCH v7 11/35] util: introduce qemu_file_getlength()
> > it could be reused here.
> > 
> 
> My new version patches
> (https://lists.nongnu.org/archive/html/qemu-devel/2016-10/msg05519.html)
> use the same approach to get the file size except that I didn't make
> it a common function. I'll move it to a common function in the next
> version.

I think we can move it into a common function in a follow-up
series. This way the discussion about where to put the common
function (and what we should do on non-posix hosts) won't hold
this series.
diff mbox

Patch

diff --git a/backends/hostmem-file.c b/backends/hostmem-file.c
index 42efb2f..c2df14c 100644
--- a/backends/hostmem-file.c
+++ b/backends/hostmem-file.c
@@ -32,6 +32,7 @@  struct HostMemoryBackendFile {
     HostMemoryBackend parent_obj;
 
     bool share;
+    bool notrunc;
     char *mem_path;
 };
 
@@ -57,7 +58,7 @@  file_backend_memory_alloc(HostMemoryBackend *backend, Error **errp)
         path = object_get_canonical_path(OBJECT(backend));
         memory_region_init_ram_from_file(&backend->mr, OBJECT(backend),
                                  path,
-                                 backend->size, fb->share,
+                                 backend->size, fb->share, fb->notrunc,
                                  fb->mem_path, errp);
         g_free(path);
     }
@@ -103,6 +104,25 @@  static void file_memory_backend_set_share(Object *o, bool value, Error **errp)
     fb->share = value;
 }
 
+static bool file_memory_backend_get_notrunc(Object *o, Error **errp)
+{
+    HostMemoryBackendFile *fb = MEMORY_BACKEND_FILE(o);
+
+    return fb->notrunc;
+}
+
+static void file_memory_backend_set_notrunc(Object *o, bool value, Error **errp)
+{
+    HostMemoryBackend *backend = MEMORY_BACKEND(o);
+    HostMemoryBackendFile *fb = MEMORY_BACKEND_FILE(o);
+
+    if (memory_region_size(&backend->mr)) {
+        error_setg(errp, "cannot change property value");
+        return;
+    }
+    fb->notrunc = value;
+}
+
 static void
 file_backend_class_init(ObjectClass *oc, void *data)
 {
@@ -116,6 +136,9 @@  file_backend_class_init(ObjectClass *oc, void *data)
     object_class_property_add_str(oc, "mem-path",
         get_mem_path, set_mem_path,
         &error_abort);
+    object_class_property_add_bool(oc, "notrunc",
+        file_memory_backend_get_notrunc, file_memory_backend_set_notrunc,
+        &error_abort);
 }
 
 static void file_backend_instance_finalize(Object *o)
diff --git a/exec.c b/exec.c
index e63c5a1..aacaee1 100644
--- a/exec.c
+++ b/exec.c
@@ -63,6 +63,11 @@ 
 #include "qemu/mmap-alloc.h"
 #endif
 
+#include <sys/ioctl.h>
+#ifdef CONFIG_LINUX
+#include <linux/fs.h>
+#endif
+
 //#define DEBUG_SUBPAGE
 
 #if !defined(CONFIG_USER_ONLY)
@@ -91,6 +96,12 @@  static MemoryRegion io_mem_unassigned;
  */
 #define RAM_RESIZEABLE (1 << 2)
 
+/* If the backend of RAM is a file and the RAM size is not identical
+ * to the file size, do not truncate the file to the RAM size. This
+ * flag is used to avoid corrupting the existing data on the file.
+ */
+#define RAM_NOTRUNC    (1 << 3)
+
 #endif
 
 struct CPUTailQ cpus = QTAILQ_HEAD_INITIALIZER(cpus);
@@ -1188,6 +1199,48 @@  void qemu_mutex_unlock_ramlist(void)
 }
 
 #ifdef __linux__
+static uint64_t get_file_size(const char *path, Error **errp)
+{
+    int fd;
+    struct stat st;
+    uint64_t size = 0;
+    Error *local_err = NULL;
+
+    fd = qemu_open(path, O_RDONLY);
+    if (fd < 0) {
+        error_setg(&local_err, "cannot open file");
+        goto out;
+    }
+
+    if (stat(path, &st)) {
+        error_setg(&local_err, "cannot get file stat");
+        goto out_fclose;
+    }
+
+    switch (st.st_mode & S_IFMT) {
+    case S_IFREG:
+        size = st.st_size;
+        break;
+
+    case S_IFBLK:
+        if (ioctl(fd, BLKGETSIZE64, &size)) {
+            error_setg(&local_err, "cannot get size of block device");
+            size = 0;
+        }
+        break;
+
+    default:
+        error_setg(&local_err,
+                   "only block device on Linux and regular file are supported");
+    }
+
+ out_fclose:
+    close(fd);
+ out:
+    error_propagate(errp, local_err);
+    return size;
+}
+
 static void *file_ram_alloc(RAMBlock *block,
                             ram_addr_t memory,
                             const char *path,
@@ -1271,7 +1324,7 @@  static void *file_ram_alloc(RAMBlock *block,
      * If anything goes wrong with it under other filesystems,
      * mmap will fail.
      */
-    if (ftruncate(fd, memory)) {
+    if (!(block->flags & RAM_NOTRUNC) && ftruncate(fd, memory)) {
         perror("ftruncate");
     }
 
@@ -1597,7 +1650,8 @@  static void ram_block_add(RAMBlock *new_block, Error **errp)
 
 #ifdef __linux__
 RAMBlock *qemu_ram_alloc_from_file(ram_addr_t size, MemoryRegion *mr,
-                                   bool share, const char *mem_path,
+                                   bool share, bool notrunc,
+                                   const char *mem_path,
                                    Error **errp)
 {
     RAMBlock *new_block;
@@ -1619,12 +1673,28 @@  RAMBlock *qemu_ram_alloc_from_file(ram_addr_t size, MemoryRegion *mr,
         return NULL;
     }
 
+    if (notrunc) {
+        uint64_t file_size = get_file_size(mem_path, &local_err);
+
+        if (local_err) {
+            error_propagate(errp, local_err);
+            return NULL;
+        }
+
+        if (size > file_size) {
+            error_setg(errp,
+                       "notrunc enabled, but size is larger than file size");
+            return NULL;
+        }
+    }
+
     size = HOST_PAGE_ALIGN(size);
     new_block = g_malloc0(sizeof(*new_block));
     new_block->mr = mr;
     new_block->used_length = size;
     new_block->max_length = size;
     new_block->flags = share ? RAM_SHARED : 0;
+    new_block->flags |= notrunc ? RAM_NOTRUNC : 0;
     new_block->host = file_ram_alloc(new_block, size,
                                      mem_path, errp);
     if (!new_block->host) {
diff --git a/include/exec/memory.h b/include/exec/memory.h
index 10d7eac..c0116e1 100644
--- a/include/exec/memory.h
+++ b/include/exec/memory.h
@@ -418,6 +418,8 @@  void memory_region_init_resizeable_ram(MemoryRegion *mr,
  * @name: the name of the region.
  * @size: size of the region.
  * @share: %true if memory must be mmaped with the MAP_SHARED flag
+ * @notrunc: %true do not truncate the file @path to @size if the
+ *           file size is not identical to @size
  * @path: the path in which to allocate the RAM.
  * @errp: pointer to Error*, to store an error if it happens.
  */
@@ -426,6 +428,7 @@  void memory_region_init_ram_from_file(MemoryRegion *mr,
                                       const char *name,
                                       uint64_t size,
                                       bool share,
+                                      bool notrunc,
                                       const char *path,
                                       Error **errp);
 #endif
diff --git a/include/exec/ram_addr.h b/include/exec/ram_addr.h
index 54d7108..4fd3ec8 100644
--- a/include/exec/ram_addr.h
+++ b/include/exec/ram_addr.h
@@ -96,7 +96,8 @@  void qemu_mutex_lock_ramlist(void);
 void qemu_mutex_unlock_ramlist(void);
 
 RAMBlock *qemu_ram_alloc_from_file(ram_addr_t size, MemoryRegion *mr,
-                                   bool share, const char *mem_path,
+                                   bool share, bool notrunc,
+                                   const char *mem_path,
                                    Error **errp);
 RAMBlock *qemu_ram_alloc_from_ptr(ram_addr_t size, void *host,
                                   MemoryRegion *mr, Error **errp);
diff --git a/memory.c b/memory.c
index 58f9269..5430412 100644
--- a/memory.c
+++ b/memory.c
@@ -1334,6 +1334,7 @@  void memory_region_init_ram_from_file(MemoryRegion *mr,
                                       const char *name,
                                       uint64_t size,
                                       bool share,
+                                      bool trunc,
                                       const char *path,
                                       Error **errp)
 {
@@ -1341,7 +1342,8 @@  void memory_region_init_ram_from_file(MemoryRegion *mr,
     mr->ram = true;
     mr->terminates = true;
     mr->destructor = memory_region_destructor_ram;
-    mr->ram_block = qemu_ram_alloc_from_file(size, mr, share, path, errp);
+    mr->ram_block = qemu_ram_alloc_from_file(size, mr, share, trunc, path,
+                                             errp);
     mr->dirty_log_mask = tcg_enabled() ? (1 << DIRTY_MEMORY_CODE) : 0;
 }
 #endif
diff --git a/numa.c b/numa.c
index 9c09e45..6cf1fb5 100644
--- a/numa.c
+++ b/numa.c
@@ -412,7 +412,7 @@  static void allocate_system_memory_nonnuma(MemoryRegion *mr, Object *owner,
 #ifdef __linux__
         Error *err = NULL;
         memory_region_init_ram_from_file(mr, owner, name, ram_size, false,
-                                         mem_path, &err);
+                                         false, mem_path, &err);
         if (err) {
             error_report_err(err);
             if (mem_prealloc) {