[Qemu-devel] [PULL 3/3] tests: vm: auto_install OpenBSD

[Fam Zheng]

From: Fam Zheng 

Upgrade OpenBSD to 6.4 using auto_install. Especially, drop SDL1,
include SDL2.

Also do the build in $HOME since both /var/tmp and /tmp are tmpfs with
limited capacities.

Signed-off-by: Fam Zheng 

Message-Id: <20181031025712.18602-1-f...@redhat.com>
Signed-off-by: Fam Zheng 
---
 tests/vm/basevm.py |  6 ++--
 tests/vm/openbsd   | 85 ++
 2 files changed, 76 insertions(+), 15 deletions(-)

diff --git a/tests/vm/basevm.py b/tests/vm/basevm.py
index 5caf77d6b8..6fb446d4c5 100755
--- a/tests/vm/basevm.py
+++ b/tests/vm/basevm.py
@@ -68,8 +68,6 @@ class BaseVM(object):
 self._args = [ \
 "-nodefaults", "-m", "4G",
 "-cpu", "max",
-"-netdev", "user,id=vnet,hostfwd=:127.0.0.1:0-:22",
-"-device", "virtio-net-pci,netdev=vnet",
 "-vnc", "127.0.0.1:0,to=20",
 "-serial", "file:%s" % os.path.join(self._tmpdir, "serial.out")]
 if vcpus and vcpus > 1:
@@ -146,8 +144,10 @@ class BaseVM(object):
 "-device",
 "virtio-blk,drive=%s,serial=%s,bootindex=1" % 
(name, name)]
 
-def boot(self, img, extra_args=[]):
+def boot(self, img, extra_args=[], extra_usernet_args=""):
 args = self._args + [
+"-netdev", "user,id=vnet,hostfwd=:127.0.0.1:0-:22" + 
extra_usernet_args,
+"-device", "virtio-net-pci,netdev=vnet",
 "-device", "VGA",
 "-drive", "file=%s,if=none,id=drive0,cache=writeback" % img,
 "-device", "virtio-blk,drive=drive0,bootindex=0"]
diff --git a/tests/vm/openbsd b/tests/vm/openbsd
index cfe0572c59..99a7e98d80 100755
--- a/tests/vm/openbsd
+++ b/tests/vm/openbsd
@@ -14,6 +14,9 @@
 import os
 import sys
 import subprocess
+import time
+import atexit
+import tempfile
 import basevm
 
 class OpenBSDVM(basevm.BaseVM):
@@ -21,25 +24,83 @@ class OpenBSDVM(basevm.BaseVM):
 arch = "x86_64"
 BUILD_SCRIPT = """
 set -e;
-rm -rf /var/tmp/qemu-test.*
-cd $(mktemp -d /var/tmp/qemu-test.XX);
+rm -rf $HOME/qemu-test.*
+cd $(mktemp -d $HOME/qemu-test.XX);
 tar -xf /dev/rsd1c;
-./configure --cc=x86_64-unknown-openbsd6.1-gcc-4.9.4 
--python=python2.7 {configure_opts};
+./configure {configure_opts};
 gmake --output-sync -j{jobs} {verbose};
 # XXX: "gmake check" seems to always hang or fail
 #gmake --output-sync -j{jobs} check {verbose};
 """
 
+def _install_os(self, img):
+tmpdir = tempfile.mkdtemp()
+pxeboot = 
self._download_with_cache("https://fastly.cdn.openbsd.org/pub/OpenBSD/6.4/amd64/pxeboot;,
+
sha256sum="d87ab39d941ff926d693943a927585945456ccedb76ea504a251b4b93cd4c266")
+bsd_rd = 
self._download_with_cache("https://fastly.cdn.openbsd.org/pub/OpenBSD/6.4/amd64/bsd.rd;,
+
sha256sum="89505c683cbcd75582fe475e847ed53d89e2b8180c3e3d61f4eb4b76b5e11f5c")
+install = 
self._download_with_cache("https://fastly.cdn.openbsd.org/pub/OpenBSD/6.4/amd64/install64.iso;,
+
sha256sum='81833b79e23dc0f961ac5fb34484bca66386deb3181ddb8236870fa4f488cdd2')
+subprocess.check_call(["qemu-img", "create", img, "32G"])
+subprocess.check_call(["cp", pxeboot, os.path.join(tmpdir, 
"auto_install")])
+subprocess.check_call(["cp", bsd_rd, os.path.join(tmpdir, "bsd")])
+
+self._gen_install_conf(tmpdir)
+# BOOTP filename being auto_install makes sure OpenBSD installer
+# not prompt for "auto install mode"
+usernet_args = ",tftp=%s,bootfile=/auto_install" % tmpdir
+usernet_args += ",tftp-server-name=10.0.2.4"
+usernet_args += ",guestfwd=tcp:10.0.2.4:80-cmd:cat %s" % \
+os.path.join(tmpdir, "install.conf")
+self.boot(img,
+  extra_args=["-boot", "once=n", "-no-reboot",
+  "-cdrom", install],
+  extra_usernet_args=usernet_args)
+self.wait()
+
+def _gen_install_conf(self, tmpdir):
+contents = """\
+HTTP/1.0 200 OK
+
+System hostname = qemu-openbsd
+Password for root = qemupass
+Public ssh key for root = {pub_key}
+Allow root ssh login = yes
+Network interfaces = vio0
+IPv4 address for vio0 = dhcp
+Setup a user = qemu
+Password for user = qemupass
+Public ssh key for user = {pub_key}
+What timezone are you in = US/Eastern
+Server = fastly.cdn.openbsd.org
+Use http = yes
+Default IPv4 route = 10.0.2.2
+Location of sets = cd0
+Set name(s) = all
+Continue without verification = yes
+""".format(pub_key=basevm.SSH_PUB_KEY)
+with open(os.path.join(tmpdir, "install.conf"), "w") as f:
+f.write(contents)
+
 def build_image(self, img):
-cimg = 
self._download_with_cache("http://download.patchew.org/openbsd-6.1-amd64.img.xz;,
-

[Qemu-devel] [PULL 1/3] block/nvme: optimize the performance of nvme driver based on vfio-pci

[Fam Zheng]

From: Li Feng 

When the IO size is larger than 2 pages, we move the the pointer one by
one in the pagelist, this is inefficient.

This is a simple benchmark result:

Before:
$ qemu-io -c 'write 0 1G' nvme://:00:04.0/1

wrote 1073741824/1073741824 bytes at offset 0
1 GiB, 1 ops; 0:00:02.41 (424.504 MiB/sec and 0.4146 ops/sec)

 $ qemu-io -c 'read 0 1G' nvme://:00:04.0/1

read 1073741824/1073741824 bytes at offset 0
1 GiB, 1 ops; 0:00:02.03 (503.055 MiB/sec and 0.4913 ops/sec)

After:
$ qemu-io -c 'write 0 1G' nvme://:00:04.0/1

wrote 1073741824/1073741824 bytes at offset 0
1 GiB, 1 ops; 0:00:02.17 (471.517 MiB/sec and 0.4605 ops/sec)

 $ qemu-io -c 'read 0 1G' nvme://:00:04.0/1

read 1073741824/1073741824 bytes at offset 0
1 GiB, 1 ops; 0:00:01.94 (526.770 MiB/sec and 0.5144 ops/sec)

Signed-off-by: Li Feng 
Message-Id: <20181101103807.25862-1-lifeng1...@gmail.com>
Signed-off-by: Fam Zheng 
---
 block/nvme.c | 16 ++--
 1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/block/nvme.c b/block/nvme.c
index 29294038fc..982097b5b1 100644
--- a/block/nvme.c
+++ b/block/nvme.c
@@ -837,7 +837,7 @@ try_map:
 }
 
 for (j = 0; j < qiov->iov[i].iov_len / s->page_size; j++) {
-pagelist[entries++] = iova + j * s->page_size;
+pagelist[entries++] = cpu_to_le64(iova + j * s->page_size);
 }
 trace_nvme_cmd_map_qiov_iov(s, i, qiov->iov[i].iov_base,
 qiov->iov[i].iov_len / s->page_size);
@@ -850,20 +850,16 @@ try_map:
 case 0:
 abort();
 case 1:
-cmd->prp1 = cpu_to_le64(pagelist[0]);
+cmd->prp1 = pagelist[0];
 cmd->prp2 = 0;
 break;
 case 2:
-cmd->prp1 = cpu_to_le64(pagelist[0]);
-cmd->prp2 = cpu_to_le64(pagelist[1]);;
+cmd->prp1 = pagelist[0];
+cmd->prp2 = pagelist[1];
 break;
 default:
-cmd->prp1 = cpu_to_le64(pagelist[0]);
-cmd->prp2 = cpu_to_le64(req->prp_list_iova);
-for (i = 0; i < entries - 1; ++i) {
-pagelist[i] = cpu_to_le64(pagelist[i + 1]);
-}
-pagelist[entries - 1] = 0;
+cmd->prp1 = pagelist[0];
+cmd->prp2 = cpu_to_le64(req->prp_list_iova + sizeof(uint64_t));
 break;
 }
 trace_nvme_cmd_map_qiov(s, cmd, req, qiov, entries);
-- 
2.11.0

[Qemu-devel] [PULL 2/3] docker: Use a stable snapshot for Debian Sid

[Fam Zheng]

From: Philippe Mathieu-Daudé 

The Debian Sid repository is not garanteed to be stable, as his
'unstable' name suggest :)

To allow quick testing, Debian maintainers might push packages
various time a day. Sometime package dependencies might break,
which is annoying when using this repository for stable development
(which is not recommended, but Sid provides edge packages we use
for testing).

Debian provides repositories snapshots which are suitable for our
use. Pick a recent date that works. When required, update to newer
releases will be easy.

This fixes current issues with this image:

  $ make docker-image-debian-sid
  [...]
  The following packages have unmet dependencies:
   build-essential : Depends: dpkg-dev (>= 1.17.11) but it is not going to be 
installed
   git : Depends: perl but it is not going to be installed
 Depends: liberror-perl but it is not going to be installed
   pkg-config : Depends: libdpkg-perl but it is not going to be installed
   texinfo : Depends: perl (>= 5.26.2-6) but it is not going to be installed
 Depends: libtext-unidecode-perl but it is not going to be installed
 Depends: libxml-libxml-perl but it is not going to be installed
  E: Unable to correct problems, you have held broken packages.

Signed-off-by: Philippe Mathieu-Daudé 
Message-Id: <20181101183705.5422-1-phi...@redhat.com>
Signed-off-by: Fam Zheng 
---
 tests/docker/dockerfiles/debian-sid.docker | 4 
 1 file changed, 4 insertions(+)

diff --git a/tests/docker/dockerfiles/debian-sid.docker 
b/tests/docker/dockerfiles/debian-sid.docker
index 9a3d168705..4e4cda0ba5 100644
--- a/tests/docker/dockerfiles/debian-sid.docker
+++ b/tests/docker/dockerfiles/debian-sid.docker
@@ -13,6 +13,10 @@
 
 FROM debian:sid-slim
 
+# Use a snapshot known to work (see http://snapshot.debian.org/#Usage)
+ENV DEBIAN_SNAPSHOT_DATE "20181030"
+RUN sed -i "s%^deb \(https\?://\)deb.debian.org/debian/\? \(.*\)%deb 
[check-valid-until=no] 
\1snapshot.debian.org/archive/debian/${DEBIAN_SNAPSHOT_DATE} \2%" 
/etc/apt/sources.list
+
 # Duplicate deb line as deb-src
 RUN cat /etc/apt/sources.list | sed "s/^deb\ /deb-src /" >> 
/etc/apt/sources.list
 
-- 
2.11.0

[Qemu-devel] [PULL 0/3] Block and testing patches

[Fam Zheng]

The following changes since commit 9b2e891ec5ccdb4a7d583b77988848282606fdea:

  Merge remote-tracking branch 'remotes/marcel/tags/rdma-pull-request' into 
staging (2018-12-22 11:25:31 +)

are available in the git repository at:

  https://f...@github.com/famz/qemu tags/block-and-testing-pull-request

for you to fetch changes up to 3baa6942169cce0f58b88484ad010742c382480a:

  tests: vm: auto_install OpenBSD (2019-01-02 20:51:15 +0800)


Pull request



Fam Zheng (1):
  tests: vm: auto_install OpenBSD

Li Feng (1):
  block/nvme: optimize the performance of nvme driver based on vfio-pci

Philippe Mathieu-Daudé (1):
  docker: Use a stable snapshot for Debian Sid

 block/nvme.c   | 16 +++---
 tests/docker/dockerfiles/debian-sid.docker |  4 ++
 tests/vm/basevm.py |  6 +--
 tests/vm/openbsd   | 85 +-
 4 files changed, 86 insertions(+), 25 deletions(-)

-- 
2.11.0

[Qemu-devel] [Bug 1701835] Re: floating-point operation bugs in qemu-alpha

[Bruno Haible]

The fpcr value seen in a process running in a VM comes from the Linux
kernel, file linux/arch/alpha/kernel/process.c, function flush_thread():

/* Arrange for each exec'ed process to start off with a clean slate
   with respect to the FPU.  This is all exceptions disabled.  */
current_thread_info()->ieee_state = 0;
wrfpcr(FPCR_DYN_NORMAL | ieee_swcr_to_fpcr(0));

where FPCR_DYN_NORMAL is 0x2UL << 58 /* towards nearest */

Where do we go from here? As far as I understand, qemu-alpha ought to
initialize the DYN bits to FPCR_DYN_NORMAL. Where in the code should
this be done? I see code in target/alpha/cpu.c, function
alpha_cpu_initfn, that initializes the DYN bits to FPCR_DYN_NORMAL. Is
this at the wrong place? Is it insufficient for another reason?

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1701835

Title:
  floating-point operation bugs in qemu-alpha

Status in QEMU:
  New

Bug description:
  When running the gnulib testsuite, I'm seeing test failures in the tests for 
libm functions
cbrt
cbrtf
ceil
ceilf
coshf
exp2
exp2f
floor
floorf
fma
fmaf
fmal
frexp
frexpf
hypot
hypotf
hypotl
ilogb
ilogbf
isfinite
isinf
isnan
isnand
isnanf
ldexp
ldexpf
ldexpl
log1p
log1pf
log2
log2f
logb
logbf
logbl
rint
rintf
rintl
signbit
sqrt
sqrtf
strtod
  that I don't see when running the same (statically linked) executables in a 
VM, through qemu-system-alpha.

  How to reproduce:
  - Using gnulib, run ./gnulib-tool --create-testdir --dir=../testdir-math 
--single-configure cbrt cbrtf ceil ceilf coshf exp2 exp2f float floor floorf 
fma fmaf fmal frexp frexpf hypot hypotf hypotl ilogb ilogbf isfinite isinf 
isnan isnand isnanf ldexp ldexpf ldexpl log1p log1pf log2 log2f logb logbf 
logbl math printf-frexp rint rintf rintl round roundf signbit sqrt sqrtf strtod 
trunc truncf
  - Copy the resulting directory to a VM running Linux 2.6.26 with 
qemu-system-alpha.
  - There, configure and build the package:
mkdir build-native-static; cd build-native-static; ../configure 
CPPFLAGS="-Wall" LDFLAGS="-static"; make; make check
Only 4 tests fail.
  - Copy the resulting binaries back to the original x86_64 machine.
  - Set environment variables for using qemu-alpha.
  - Here, 50 tests fail that did not fail originally:

  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-cbrt
  ../../gltests/test-cbrt.h:39: assertion 'err > - L_(4.0) * L_(16.0) / 
TWO_MANT_DIG && err < L_(4.0) * L_(16.0) / TWO_MANT_DIG' failed
  Aborted (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-ceil1
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-ceil2
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-ceilf1
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-ceilf2
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-coshf 
  ../../gltests/test-coshf.c:37: assertion 'y >= 1.1854652f && y <= 1.1854653f' 
failed
  Aborted (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-float
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-floor1
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-floor2
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-floorf1
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-floorf2
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-fma1   
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-fma2
  ../../gltests/test-fma2.h:116: assertion 'result == expected' failed
  Aborted (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-fmaf1
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-fmaf2
  ../../gltests/test-fma2.h:116: assertion 'result == expected' failed
  Aborted (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-fmal2
  ../../gltests/test-fma2.h:116: assertion 'result == expected' failed
  Aborted (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-frexp
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-frexpf
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-hypot 
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-hypotf
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-hypotl
  ../../gltests/test-hypot.h:41: assertion 'z == HUGEVAL' failed
  Aborted (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-ilogb 
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-ilogbf
  Floating point exception (core dumped)
  $ 

[Qemu-devel] [PATCH v2] osdep: Make MIN/MAX evaluate arguments only once

[Eric Blake]

Add the macro QEMU_TYPEOF() to access __auto_type in new enough
compilers, while falling back to typeof on older compilers (the
fallback doesn't handle variable length arrays, but we don't use
those; it also expands to more text).

Then use that macro to make MIN/MAX only evaluate their argument
once; this uses type promotion (by adding to 0) to work around
the fact that typeof(bitfield) won't compile.  However, we are
unable to work around gcc refusing to compile ({}) in a constant
context, even when only used in the dead branch of a
__builtin_choose_expr(), so we have to provide a second macro
pair MIN_CONST and MAX_CONST for use when both arguments are
known to be compile-time constants and where the result must
also be usable in constant contexts.

Fix the resulting callsites that compute a compile-time constant
min or max to use the new macros.

Signed-off-by: Eric Blake 

---
v2: Force use of our smart macros, and make macro handle bitfields,
constant expressions, and older compilers [Zoltan]
---
 hw/usb/hcd-xhci.h   |  2 +-
 include/exec/cpu-defs.h |  2 +-
 include/qemu/compiler.h | 10 +
 include/qemu/osdep.h| 46 ++---
 migration/qemu-file.c   |  2 +-
 5 files changed, 51 insertions(+), 11 deletions(-)

diff --git a/hw/usb/hcd-xhci.h b/hw/usb/hcd-xhci.h
index fc36a4c787c..10beee9a7b1 100644
--- a/hw/usb/hcd-xhci.h
+++ b/hw/usb/hcd-xhci.h
@@ -210,7 +210,7 @@ struct XHCIState {
 uint32_t dcbaap_high;
 uint32_t config;

-USBPort  uports[MAX(MAXPORTS_2, MAXPORTS_3)];
+USBPort  uports[MAX_CONST(MAXPORTS_2, MAXPORTS_3)];
 XHCIPort ports[MAXPORTS];
 XHCISlot slots[MAXSLOTS];
 uint32_t numports;
diff --git a/include/exec/cpu-defs.h b/include/exec/cpu-defs.h
index 6a60f94a41d..5b2fd46f687 100644
--- a/include/exec/cpu-defs.h
+++ b/include/exec/cpu-defs.h
@@ -90,7 +90,7 @@ typedef uint64_t target_ulong;
  * of tlb_table inside env (which is non-trivial but not huge).
  */
 #define CPU_TLB_BITS \
-MIN(8,   \
+MIN_CONST(8, \
 TCG_TARGET_TLB_DISPLACEMENT_BITS - CPU_TLB_ENTRY_BITS -  \
 (NB_MMU_MODES <= 1 ? 0 : \
  NB_MMU_MODES <= 2 ? 1 : \
diff --git a/include/qemu/compiler.h b/include/qemu/compiler.h
index 261842beae2..3bf6f68a6b0 100644
--- a/include/qemu/compiler.h
+++ b/include/qemu/compiler.h
@@ -191,4 +191,14 @@
 #define QEMU_GENERIC9(x, a0, ...) QEMU_GENERIC_IF(x, a0, QEMU_GENERIC8(x, 
__VA_ARGS__))
 #define QEMU_GENERIC10(x, a0, ...) QEMU_GENERIC_IF(x, a0, QEMU_GENERIC9(x, 
__VA_ARGS__))

+/*
+ * Automatic type deduction, to be used as:
+ * QEMU_TYPEOF(expr) name = expr;
+ */
+#if QEMU_GNUC_PREREQ(4, 9)
+# define QEMU_TYPEOF(a) __auto_type
+#else
+# define QEMU_TYPEOF(a) typeof(a)
+#endif
+
 #endif /* COMPILER_H */
diff --git a/include/qemu/osdep.h b/include/qemu/osdep.h
index 3bf48bcdec0..821ce627f73 100644
--- a/include/qemu/osdep.h
+++ b/include/qemu/osdep.h
@@ -232,18 +232,48 @@ extern int daemon(int, int);
 #define SIZE_MAX ((size_t)-1)
 #endif

-#ifndef MIN
-#define MIN(a, b) (((a) < (b)) ? (a) : (b))
-#endif
-#ifndef MAX
-#define MAX(a, b) (((a) > (b)) ? (a) : (b))
-#endif
+/*
+ * Two variations of MIN/MAX macros. The first is for runtime use, and
+ * evaluates arguments only once (so it is safe even with side
+ * effects), but will not work in constant contexts (such as array
+ * size declarations).  The second is for compile-time use, where
+ * evaluating arguments twice is safe because the result is going to
+ * be constant anyway.
+ */
+#undef MIN
+#define MIN(a, b)\
+({   \
+QEMU_TYPEOF((a) + 0) _a = (a) + 0;   \
+QEMU_TYPEOF((b) + 0) _b = (b) + 0;   \
+_a < _b ? _a : _b;   \
+})
+#define MIN_CONST(a, b) \
+__builtin_choose_expr(  \
+__builtin_constant_p(a) && __builtin_constant_p(b), \
+(a) < (b) ? (a) : (b),  \
+__builtin_unreachable())
+#undef MAX
+#define MAX(a, b)\
+({   \
+QEMU_TYPEOF((a) + 0) _a = (a) + 0;   \
+QEMU_TYPEOF((b) + 0) _b = (b) + 0;   \
+_a > _b ? _a : _b;   \
+})
+#define MAX_CONST(a, b) \
+__builtin_choose_expr(  \
+__builtin_constant_p(a) && __builtin_constant_p(b), \
+(a) > (b) ? (a) : (b),  \
+__builtin_unreachable())

 /* Minimum function that returns zero only iff both values are zero.
  * Intended for use with unsigned values only. */
 #ifndef MIN_NON_ZERO

[Qemu-devel] [PATCH] target/alpha: Fix user-only initialization of fpcr

[Richard Henderson]

When the representation of fpcr was changed, the user-only
initialization was not updated to match.  Oops.

Fixes: f3d3aad4a92
Fixes: https://bugs.launchpad.net/bugs/1701835
Reported-by: Bruno Haible 
Signed-off-by: Richard Henderson 
---
 target/alpha/cpu.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/target/alpha/cpu.c b/target/alpha/cpu.c
index a953897fcc..1fd95d6c0f 100644
--- a/target/alpha/cpu.c
+++ b/target/alpha/cpu.c
@@ -205,9 +205,9 @@ static void alpha_cpu_initfn(Object *obj)
 env->lock_addr = -1;
 #if defined(CONFIG_USER_ONLY)
 env->flags = ENV_FLAG_PS_USER | ENV_FLAG_FEN;
-cpu_alpha_store_fpcr(env, (FPCR_INVD | FPCR_DZED | FPCR_OVFD
-   | FPCR_UNFD | FPCR_INED | FPCR_DNOD
-   | FPCR_DYN_NORMAL));
+cpu_alpha_store_fpcr(env, (uint64_t)(FPCR_INVD | FPCR_DZED | FPCR_OVFD
+ | FPCR_UNFD | FPCR_INED | FPCR_DNOD
+ | FPCR_DYN_NORMAL) << 32);
 #else
 env->flags = ENV_FLAG_PAL_MODE | ENV_FLAG_FEN;
 #endif
-- 
2.17.2

[Qemu-devel] [Bug 1701835] Re: floating-point operation bugs in qemu-alpha

[Stefan Ring]

https://download.majix.org/dec/alpha_arch_ref.pdf

The bits are defined in 4.7.8 Floating-Point Control Register (FPCR).
59/58 zero is chopped rounding. This does not seem like a good default.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1701835

Title:
  floating-point operation bugs in qemu-alpha

Status in QEMU:
  New

Bug description:
  When running the gnulib testsuite, I'm seeing test failures in the tests for 
libm functions
cbrt
cbrtf
ceil
ceilf
coshf
exp2
exp2f
floor
floorf
fma
fmaf
fmal
frexp
frexpf
hypot
hypotf
hypotl
ilogb
ilogbf
isfinite
isinf
isnan
isnand
isnanf
ldexp
ldexpf
ldexpl
log1p
log1pf
log2
log2f
logb
logbf
logbl
rint
rintf
rintl
signbit
sqrt
sqrtf
strtod
  that I don't see when running the same (statically linked) executables in a 
VM, through qemu-system-alpha.

  How to reproduce:
  - Using gnulib, run ./gnulib-tool --create-testdir --dir=../testdir-math 
--single-configure cbrt cbrtf ceil ceilf coshf exp2 exp2f float floor floorf 
fma fmaf fmal frexp frexpf hypot hypotf hypotl ilogb ilogbf isfinite isinf 
isnan isnand isnanf ldexp ldexpf ldexpl log1p log1pf log2 log2f logb logbf 
logbl math printf-frexp rint rintf rintl round roundf signbit sqrt sqrtf strtod 
trunc truncf
  - Copy the resulting directory to a VM running Linux 2.6.26 with 
qemu-system-alpha.
  - There, configure and build the package:
mkdir build-native-static; cd build-native-static; ../configure 
CPPFLAGS="-Wall" LDFLAGS="-static"; make; make check
Only 4 tests fail.
  - Copy the resulting binaries back to the original x86_64 machine.
  - Set environment variables for using qemu-alpha.
  - Here, 50 tests fail that did not fail originally:

  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-cbrt
  ../../gltests/test-cbrt.h:39: assertion 'err > - L_(4.0) * L_(16.0) / 
TWO_MANT_DIG && err < L_(4.0) * L_(16.0) / TWO_MANT_DIG' failed
  Aborted (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-ceil1
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-ceil2
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-ceilf1
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-ceilf2
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-coshf 
  ../../gltests/test-coshf.c:37: assertion 'y >= 1.1854652f && y <= 1.1854653f' 
failed
  Aborted (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-float
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-floor1
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-floor2
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-floorf1
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-floorf2
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-fma1   
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-fma2
  ../../gltests/test-fma2.h:116: assertion 'result == expected' failed
  Aborted (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-fmaf1
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-fmaf2
  ../../gltests/test-fma2.h:116: assertion 'result == expected' failed
  Aborted (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-fmal2
  ../../gltests/test-fma2.h:116: assertion 'result == expected' failed
  Aborted (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-frexp
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-frexpf
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-hypot 
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-hypotf
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-hypotl
  ../../gltests/test-hypot.h:41: assertion 'z == HUGEVAL' failed
  Aborted (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-ilogb 
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-ilogbf
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-isfinite
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-isinf   
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-isnan
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-isnand-nolibm
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-isnand   
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-isnanf-nolibm
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha 

[Qemu-devel] [Bug 1701835] Re: floating-point operation bugs in qemu-alpha

[Bruno Haible]

Under qemu-system-alpha I get 680e8000 as well.

Under qemu-alpha (versions 2.8.1, 2.9.0, 2.10.0, 2.11.0, 2.12.0, 3.1.0)
I get 600e8000, i.e. bit 59 is unset.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1701835

Title:
  floating-point operation bugs in qemu-alpha

Status in QEMU:
  New

Bug description:
  When running the gnulib testsuite, I'm seeing test failures in the tests for 
libm functions
cbrt
cbrtf
ceil
ceilf
coshf
exp2
exp2f
floor
floorf
fma
fmaf
fmal
frexp
frexpf
hypot
hypotf
hypotl
ilogb
ilogbf
isfinite
isinf
isnan
isnand
isnanf
ldexp
ldexpf
ldexpl
log1p
log1pf
log2
log2f
logb
logbf
logbl
rint
rintf
rintl
signbit
sqrt
sqrtf
strtod
  that I don't see when running the same (statically linked) executables in a 
VM, through qemu-system-alpha.

  How to reproduce:
  - Using gnulib, run ./gnulib-tool --create-testdir --dir=../testdir-math 
--single-configure cbrt cbrtf ceil ceilf coshf exp2 exp2f float floor floorf 
fma fmaf fmal frexp frexpf hypot hypotf hypotl ilogb ilogbf isfinite isinf 
isnan isnand isnanf ldexp ldexpf ldexpl log1p log1pf log2 log2f logb logbf 
logbl math printf-frexp rint rintf rintl round roundf signbit sqrt sqrtf strtod 
trunc truncf
  - Copy the resulting directory to a VM running Linux 2.6.26 with 
qemu-system-alpha.
  - There, configure and build the package:
mkdir build-native-static; cd build-native-static; ../configure 
CPPFLAGS="-Wall" LDFLAGS="-static"; make; make check
Only 4 tests fail.
  - Copy the resulting binaries back to the original x86_64 machine.
  - Set environment variables for using qemu-alpha.
  - Here, 50 tests fail that did not fail originally:

  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-cbrt
  ../../gltests/test-cbrt.h:39: assertion 'err > - L_(4.0) * L_(16.0) / 
TWO_MANT_DIG && err < L_(4.0) * L_(16.0) / TWO_MANT_DIG' failed
  Aborted (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-ceil1
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-ceil2
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-ceilf1
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-ceilf2
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-coshf 
  ../../gltests/test-coshf.c:37: assertion 'y >= 1.1854652f && y <= 1.1854653f' 
failed
  Aborted (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-float
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-floor1
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-floor2
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-floorf1
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-floorf2
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-fma1   
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-fma2
  ../../gltests/test-fma2.h:116: assertion 'result == expected' failed
  Aborted (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-fmaf1
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-fmaf2
  ../../gltests/test-fma2.h:116: assertion 'result == expected' failed
  Aborted (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-fmal2
  ../../gltests/test-fma2.h:116: assertion 'result == expected' failed
  Aborted (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-frexp
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-frexpf
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-hypot 
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-hypotf
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-hypotl
  ../../gltests/test-hypot.h:41: assertion 'z == HUGEVAL' failed
  Aborted (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-ilogb 
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-ilogbf
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-isfinite
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-isinf   
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-isnan
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-isnand-nolibm
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-isnand   
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-isnanf-nolibm
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-isnanf   

[Qemu-devel] [Bug 1701835] Re: floating-point operation bugs in qemu-alpha

[Stefan Ring]

Run this:

#include 
#include 

double get_fpcr()
{
double x;
asm ("mf_fpcr %0": "=f" (x));
return x;
}

int main()
{
double fpcr = get_fpcr();
unsigned long l;
memcpy(, , 8);
printf("%016lx\n", l);
return 0;
}

Under qemu-system-alpha I get 680e8000.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1701835

Title:
  floating-point operation bugs in qemu-alpha

Status in QEMU:
  New

Bug description:
  When running the gnulib testsuite, I'm seeing test failures in the tests for 
libm functions
cbrt
cbrtf
ceil
ceilf
coshf
exp2
exp2f
floor
floorf
fma
fmaf
fmal
frexp
frexpf
hypot
hypotf
hypotl
ilogb
ilogbf
isfinite
isinf
isnan
isnand
isnanf
ldexp
ldexpf
ldexpl
log1p
log1pf
log2
log2f
logb
logbf
logbl
rint
rintf
rintl
signbit
sqrt
sqrtf
strtod
  that I don't see when running the same (statically linked) executables in a 
VM, through qemu-system-alpha.

  How to reproduce:
  - Using gnulib, run ./gnulib-tool --create-testdir --dir=../testdir-math 
--single-configure cbrt cbrtf ceil ceilf coshf exp2 exp2f float floor floorf 
fma fmaf fmal frexp frexpf hypot hypotf hypotl ilogb ilogbf isfinite isinf 
isnan isnand isnanf ldexp ldexpf ldexpl log1p log1pf log2 log2f logb logbf 
logbl math printf-frexp rint rintf rintl round roundf signbit sqrt sqrtf strtod 
trunc truncf
  - Copy the resulting directory to a VM running Linux 2.6.26 with 
qemu-system-alpha.
  - There, configure and build the package:
mkdir build-native-static; cd build-native-static; ../configure 
CPPFLAGS="-Wall" LDFLAGS="-static"; make; make check
Only 4 tests fail.
  - Copy the resulting binaries back to the original x86_64 machine.
  - Set environment variables for using qemu-alpha.
  - Here, 50 tests fail that did not fail originally:

  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-cbrt
  ../../gltests/test-cbrt.h:39: assertion 'err > - L_(4.0) * L_(16.0) / 
TWO_MANT_DIG && err < L_(4.0) * L_(16.0) / TWO_MANT_DIG' failed
  Aborted (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-ceil1
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-ceil2
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-ceilf1
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-ceilf2
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-coshf 
  ../../gltests/test-coshf.c:37: assertion 'y >= 1.1854652f && y <= 1.1854653f' 
failed
  Aborted (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-float
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-floor1
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-floor2
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-floorf1
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-floorf2
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-fma1   
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-fma2
  ../../gltests/test-fma2.h:116: assertion 'result == expected' failed
  Aborted (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-fmaf1
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-fmaf2
  ../../gltests/test-fma2.h:116: assertion 'result == expected' failed
  Aborted (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-fmal2
  ../../gltests/test-fma2.h:116: assertion 'result == expected' failed
  Aborted (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-frexp
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-frexpf
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-hypot 
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-hypotf
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-hypotl
  ../../gltests/test-hypot.h:41: assertion 'z == HUGEVAL' failed
  Aborted (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-ilogb 
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-ilogbf
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-isfinite
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-isinf   
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-isnan
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-isnand-nolibm
  Floating point exception (core dumped)
  $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-isnand   
  Floating point exception (core dumped)
  $ 

[Qemu-devel] Emulation of TCG OPAL self-encrypting drive

[David Kozub]

Hi,

Can QEMU emulate an OPAL disk? The only relevant thing I found is a post 
from 2017 about TPM that mentions OPAL:

https://lists.gnu.org/archive/html/qemu-devel/2017-07/msg04586.html

specifically this bit:


Well, at some point somebody's going to want us to implement this,
but... they can do that when they do that.


So I assume it is not implemented. (?)

I agree with the sentiment expressed in the mail linked above w.r.t. OPAL 
security. I'm interested in this from SW development/debugging/fiddling 
perspective. A sufficient solution for me would not add any real 
encryption but would respond to the various OPAL commands send via ATA 
TRUSTED SEND/RECEIVE commands.


In fact, a more generic solution would work for me: If it was possible to 
send ATA commands from QEMU to a separate process which could then handle 
them as it liked and reply back to QEMU. This could be useful for other 
fiddling/debugging situations too.


Or, just a pass-through to a block device in the host - but a pass-through 
that would allow OPAL commands.


I'm grateful for any hints/ideas. Perhaps something like this is already 
possible with QEMU?


Best regards,
David

[Qemu-devel] [Bug 1810603] [NEW] QEMU QCow Images crow dramatically

[Eric Blake]

On 1/5/19 9:32 AM, Lenny Helpline wrote:

> 
> You can reproduce this bug as follow:
> 1) create an initial disk image
> 2) create a linked clone
> 3) create a snapshot of the linked clone
> 4) revert the snapshot every X minutes / hours

Needs more details to reproduce.  What is the exact command you used for
each of these steps?  For example, without that command, I can't tell if
you are creating internal or external snapshots, and that drastically
changes the approach for how to deal with reverting snapshots.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1810603

Title:
  QEMU QCow Images crow dramatically

Status in QEMU:
  New

Bug description:
  I've recently migrated our VM infrastructure (~200 guest on 15 hosts)
  from vbox to Qemu (using KVM / libvirt). We have a master image (QEMU
  QCow v3) from which we spawn multiple instances (linked clones). All
  guests are being revert once per hour for security reasons.

  About 2 weeks after we successfully migrated to Qemu, we noticed that
  almost all disks went full across all 15 hosts. Our investigation
  showed that the initial qcow disk images blow up from a few gigabytes
  to 100GB and more. This should not happen, as we revert all VMs back
  to the initial snapshot once per hour and hence all changes that have
  been made to disks must be reverted too.

  We did an addition test with 24 hour time frame with which we could
  reproduce this bug as documented below.

  Initial disk image size (created on Jan 04):
  -rw-r--r-- 1 root root 7.1G Jan  4 15:59 W10-TS01-0.img
  -rw-r--r-- 1 root root 7.3G Jan  4 15:59 W10-TS02-0.img
  -rw-r--r-- 1 root root 7.4G Jan  4 15:59 W10-TS03-0.img
  -rw-r--r-- 1 root root 8.3G Jan  4 16:02 W10-CLIENT01-0.img
  -rw-r--r-- 1 root root 8.6G Jan  4 16:05 W10-CLIENT02-0.img
  -rw-r--r-- 1 root root 8.0G Jan  4 16:05 W10-CLIENT03-0.img
  -rw-r--r-- 1 root root 8.3G Jan  4 16:08 W10-CLIENT04-0.img
  -rw-r--r-- 1 root root 8.1G Jan  4 16:12 W10-CLIENT05-0.img
  -rw-r--r-- 1 root root 8.0G Jan  4 16:12 W10-CLIENT06-0.img
  -rw-r--r-- 1 root root 8.1G Jan  4 16:16 W10-CLIENT07-0.img
  -rw-r--r-- 1 root root 7.6G Jan  4 16:16 W10-CLIENT08-0.img
  -rw-r--r-- 1 root root 7.6G Jan  4 16:19 W10-CLIENT09-0.img
  -rw-r--r-- 1 root root 7.5G Jan  4 16:21 W10-ROUTER-0.img
  -rw-r--r-- 1 root root  18G Jan  4 16:25 W10-MASTER-IMG.qcow2

  Disk image size after 24 hours (printed on Jan 05):
  -rw-r--r-- 1 root root  13G Jan  5 15:07 W10-TS01-0.img
  -rw-r--r-- 1 root root 8.9G Jan  5 14:20 W10-TS02-0.img
  -rw-r--r-- 1 root root 9.0G Jan  5 15:07 W10-TS03-0.img
  -rw-r--r-- 1 root root  10G Jan  5 15:08 W10-CLIENT01-0.img
  -rw-r--r-- 1 root root  11G Jan  5 15:08 W10-CLIENT02-0.img
  -rw-r--r-- 1 root root  11G Jan  5 15:08 W10-CLIENT03-0.img
  -rw-r--r-- 1 root root  11G Jan  5 15:08 W10-CLIENT04-0.img
  -rw-r--r-- 1 root root  19G Jan  5 15:07 W10-CLIENT05-0.img
  -rw-r--r-- 1 root root  14G Jan  5 15:08 W10-CLIENT06-0.img
  -rw-r--r-- 1 root root 9.7G Jan  5 15:07 W10-CLIENT07-0.img
  -rw-r--r-- 1 root root  35G Jan  5 15:08 W10-CLIENT08-0.img
  -rw-r--r-- 1 root root 9.2G Jan  5 15:07 W10-CLIENT09-0.img
  -rw-r--r-- 1 root root  41G Jan  5 15:08 W10-ROUTER-0.img
  -rw-r--r-- 1 root root  18G Jan  4 16:25 W10-MASTER-IMG.qcow2

  You can reproduce this bug as follow:
  1) create an initial disk image
  2) create a linked clone
  3) create a snapshot of the linked clone
  4) revert the snapshot every X minutes / hours

  Due the described behavior / bug, our VM farm is completely down at
  the moment (as we run out of disk space on all host systems). A quick
  fix for this bug would be much appreciated.

  Host OS: Ubuntu 18.04.01 LTS
  Kernel: 4.15.0-43-generic
  Qemu: 3.1.0
  libvirt: 4.10.0
  Guest OS: Windows 10 64bit

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1810603/+subscriptions

Re: [Qemu-devel] [Bug 1810603] [NEW] QEMU QCow Images crow dramatically

[Eric Blake]

On 1/5/19 9:32 AM, Lenny Helpline wrote:

> 
> You can reproduce this bug as follow:
> 1) create an initial disk image
> 2) create a linked clone
> 3) create a snapshot of the linked clone
> 4) revert the snapshot every X minutes / hours

Needs more details to reproduce.  What is the exact command you used for
each of these steps?  For example, without that command, I can't tell if
you are creating internal or external snapshots, and that drastically
changes the approach for how to deal with reverting snapshots.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] Why one virtio-pci device has two different DeviceState?

[Peter Maydell]

On Fri, 4 Jan 2019 at 20:23, Jintack Lim  wrote:
> I was wondering why one virtio-pci device has two different
> DeviceState? - one directly from VirtIOPCIProxy and the other from
> VirtIO such as VirtIONet. As an example, they are denoted as
> qdev and vdev respectively in virtio_net_pci_realize().

It's been a while since I looked at this, but there are two
basic issues underlying the weird way virtio devices are
set up:
 (1) PCI is not the only "transport" -- the VirtIONet etc
 are shared with other transports like MMIO or the S390 ones
 (2) retaining back-compatibility matters a lot here: we need
 command lines to still work, and also the migration data
 stream needs to stay compatible
Some of the way the devices are reflects the way we started
with a design where there was only a single device (eg the
pci virtio-net device) and then refactored it to support
multiple transports while retaining back compatibility.

> I thought that just one DeviceState is enough for any device in QEMU.
> Maybe I'm missing something fundamental here.

This isn't generally true, it's just that a lot of
our devices are of the simple straightforward kind
where that's true. It's also possible for an
implementation of a device to be as a combination
of other devices, which is what we have here.
virtio-pci-net is-a PCIDevice (which in turn is-a Device),
but it has-a VirtIONet device (which is-a Device) as
part of its implementation.
(It's also possible to manually create the pci
transport and the virtio-net backend separately
and connect them together without the virtio-pci-net
device at all. That's more often used with non-pci
transports but it works for pci too.)

You can also see a similar thing with a lot of the
"container" SoC objects like TYPE_ASPEED_SOC, which
is a subclass of DeviceState, but is implemented
using a dozen different objects all of which are
themselves DeviceState subclasses.

thanks
-- PMM

[Qemu-devel] [Bug 1810603] [NEW] QEMU QCow Images crow dramatically

[Lenny Helpline]

Public bug reported:

I've recently migrated our VM infrastructure (~200 guest on 15 hosts)
from vbox to Qemu (using KVM / libvirt). We have a master image (QEMU
QCow v3) from which we spawn multiple instances (linked clones). All
guests are being revert once per hour for security reasons.

About 2 weeks after we successfully migrated to Qemu, we noticed that
almost all disks went full across all 15 hosts. Our investigation showed
that the initial qcow disk images blow up from a few gigabytes to 100GB
and more. This should not happen, as we revert all VMs back to the
initial snapshot once per hour and hence all changes that have been made
to disks must be reverted too.

We did an addition test with 24 hour time frame with which we could
reproduce this bug as documented below.

Initial disk image size (created on Jan 04):
-rw-r--r-- 1 root root 7.1G Jan  4 15:59 W10-TS01-0.img
-rw-r--r-- 1 root root 7.3G Jan  4 15:59 W10-TS02-0.img
-rw-r--r-- 1 root root 7.4G Jan  4 15:59 W10-TS03-0.img
-rw-r--r-- 1 root root 8.3G Jan  4 16:02 W10-CLIENT01-0.img
-rw-r--r-- 1 root root 8.6G Jan  4 16:05 W10-CLIENT02-0.img
-rw-r--r-- 1 root root 8.0G Jan  4 16:05 W10-CLIENT03-0.img
-rw-r--r-- 1 root root 8.3G Jan  4 16:08 W10-CLIENT04-0.img
-rw-r--r-- 1 root root 8.1G Jan  4 16:12 W10-CLIENT05-0.img
-rw-r--r-- 1 root root 8.0G Jan  4 16:12 W10-CLIENT06-0.img
-rw-r--r-- 1 root root 8.1G Jan  4 16:16 W10-CLIENT07-0.img
-rw-r--r-- 1 root root 7.6G Jan  4 16:16 W10-CLIENT08-0.img
-rw-r--r-- 1 root root 7.6G Jan  4 16:19 W10-CLIENT09-0.img
-rw-r--r-- 1 root root 7.5G Jan  4 16:21 W10-ROUTER-0.img
-rw-r--r-- 1 root root  18G Jan  4 16:25 W10-MASTER-IMG.qcow2

Disk image size after 24 hours (printed on Jan 05):
-rw-r--r-- 1 root root  13G Jan  5 15:07 W10-TS01-0.img
-rw-r--r-- 1 root root 8.9G Jan  5 14:20 W10-TS02-0.img
-rw-r--r-- 1 root root 9.0G Jan  5 15:07 W10-TS03-0.img
-rw-r--r-- 1 root root  10G Jan  5 15:08 W10-CLIENT01-0.img
-rw-r--r-- 1 root root  11G Jan  5 15:08 W10-CLIENT02-0.img
-rw-r--r-- 1 root root  11G Jan  5 15:08 W10-CLIENT03-0.img
-rw-r--r-- 1 root root  11G Jan  5 15:08 W10-CLIENT04-0.img
-rw-r--r-- 1 root root  19G Jan  5 15:07 W10-CLIENT05-0.img
-rw-r--r-- 1 root root  14G Jan  5 15:08 W10-CLIENT06-0.img
-rw-r--r-- 1 root root 9.7G Jan  5 15:07 W10-CLIENT07-0.img
-rw-r--r-- 1 root root  35G Jan  5 15:08 W10-CLIENT08-0.img
-rw-r--r-- 1 root root 9.2G Jan  5 15:07 W10-CLIENT09-0.img
-rw-r--r-- 1 root root  41G Jan  5 15:08 W10-ROUTER-0.img
-rw-r--r-- 1 root root  18G Jan  4 16:25 W10-MASTER-IMG.qcow2

You can reproduce this bug as follow:
1) create an initial disk image
2) create a linked clone
3) create a snapshot of the linked clone
4) revert the snapshot every X minutes / hours

Due the described behavior / bug, our VM farm is completely down at the
moment (as we run out of disk space on all host systems). A quick fix
for this bug would be much appreciated.

Host OS: Ubuntu 18.04.01 LTS
Kernel: 4.15.0-43-generic
Qemu: 3.1.0
libvirt: 4.10.0
Guest OS: Windows 10 64bit

** Affects: qemu
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1810603

Title:
  QEMU QCow Images crow dramatically

Status in QEMU:
  New

Bug description:
  I've recently migrated our VM infrastructure (~200 guest on 15 hosts)
  from vbox to Qemu (using KVM / libvirt). We have a master image (QEMU
  QCow v3) from which we spawn multiple instances (linked clones). All
  guests are being revert once per hour for security reasons.

  About 2 weeks after we successfully migrated to Qemu, we noticed that
  almost all disks went full across all 15 hosts. Our investigation
  showed that the initial qcow disk images blow up from a few gigabytes
  to 100GB and more. This should not happen, as we revert all VMs back
  to the initial snapshot once per hour and hence all changes that have
  been made to disks must be reverted too.

  We did an addition test with 24 hour time frame with which we could
  reproduce this bug as documented below.

  Initial disk image size (created on Jan 04):
  -rw-r--r-- 1 root root 7.1G Jan  4 15:59 W10-TS01-0.img
  -rw-r--r-- 1 root root 7.3G Jan  4 15:59 W10-TS02-0.img
  -rw-r--r-- 1 root root 7.4G Jan  4 15:59 W10-TS03-0.img
  -rw-r--r-- 1 root root 8.3G Jan  4 16:02 W10-CLIENT01-0.img
  -rw-r--r-- 1 root root 8.6G Jan  4 16:05 W10-CLIENT02-0.img
  -rw-r--r-- 1 root root 8.0G Jan  4 16:05 W10-CLIENT03-0.img
  -rw-r--r-- 1 root root 8.3G Jan  4 16:08 W10-CLIENT04-0.img
  -rw-r--r-- 1 root root 8.1G Jan  4 16:12 W10-CLIENT05-0.img
  -rw-r--r-- 1 root root 8.0G Jan  4 16:12 W10-CLIENT06-0.img
  -rw-r--r-- 1 root root 8.1G Jan  4 16:16 W10-CLIENT07-0.img
  -rw-r--r-- 1 root root 7.6G Jan  4 16:16 W10-CLIENT08-0.img
  -rw-r--r-- 1 root root 7.6G Jan  4 16:19 W10-CLIENT09-0.img
  -rw-r--r-- 1 root root 7.5G Jan  4 16:21 W10-ROUTER-0.img
  -rw-r--r-- 1 root root  18G Jan  4 16:25 

Re: [Qemu-devel] [RFC PATCH 23/25] x86_64-softmmu.mak: remove i386-softmmu.mak include

[Peter Maydell]

On Thu, 27 Dec 2018 at 06:35, Yang Zhong  wrote:
>
> Only keep same boards definitions as i386-softmmu.mak in
> x86_64-softmmu.mak.
>
> Signed-off-by: Yang Zhong 
> ---
>  default-configs/x86_64-softmmu.mak | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/default-configs/x86_64-softmmu.mak 
> b/default-configs/x86_64-softmmu.mak
> index 64b2ee2960..0c69c2930c 100644
> --- a/default-configs/x86_64-softmmu.mak
> +++ b/default-configs/x86_64-softmmu.mak
> @@ -1,3 +1,7 @@
>  # Default configuration for x86_64-softmmu
>
> -include i386-softmmu.mak
> +# Boards:
> +#
> +CONFIG_ISAPC=y
> +CONFIG_I440FX=y
> +CONFIG_Q35=y

Could you explain the rationale for doing this? Now
any new i386 board has to be added in two places,
doesn't it?

thanks
-- PMM

[Qemu-devel] [PATCH] arm: Stub out NRF51 TWI magnetometer/accelerometer detection

[Stefan Hajnoczi]

From: Steffen Görtz 

Recent microbit firmwares panic if the TWI magnetometer/accelerometer
devices are not detected during startup.  We don't implement TWI (I2C)
so let's stub out these devices just to let the firmware boot.

Signed-off-by: Stefan Hajnoczi 
Based-on: <20190103091119.9367-1-stefa...@redhat.com>
---
Steffen: Please post your Signed-off-by.  I did some minor cleanups so
your patch can be merged.  Thanks!

 include/hw/arm/nrf51.h |  1 +
 include/hw/arm/nrf51_soc.h |  1 +
 hw/arm/nrf51_soc.c | 62 ++
 3 files changed, 64 insertions(+)

diff --git a/include/hw/arm/nrf51.h b/include/hw/arm/nrf51.h
index 175bb6c301..5411121b66 100644
--- a/include/hw/arm/nrf51.h
+++ b/include/hw/arm/nrf51.h
@@ -25,6 +25,7 @@
 #define NRF51_IOMEM_SIZE  0x2000
 
 #define NRF51_UART_BASE   0x40002000
+#define NRF51_TWI_BASE0x40003000
 #define NRF51_TIMER_BASE  0x40008000
 #define NRF51_TIMER_SIZE  0x1000
 #define NRF51_RNG_BASE0x4000D000
diff --git a/include/hw/arm/nrf51_soc.h b/include/hw/arm/nrf51_soc.h
index e06f0304b4..fbdefc07e4 100644
--- a/include/hw/arm/nrf51_soc.h
+++ b/include/hw/arm/nrf51_soc.h
@@ -39,6 +39,7 @@ typedef struct NRF51State {
 MemoryRegion sram;
 MemoryRegion flash;
 MemoryRegion clock;
+MemoryRegion twi;
 
 uint32_t sram_size;
 uint32_t flash_size;
diff --git a/hw/arm/nrf51_soc.c b/hw/arm/nrf51_soc.c
index 1630c27594..265438f916 100644
--- a/hw/arm/nrf51_soc.c
+++ b/hw/arm/nrf51_soc.c
@@ -32,6 +32,11 @@
 #define NRF51822_FLASH_SIZE (256 * NRF51_PAGE_SIZE)
 #define NRF51822_SRAM_SIZE  (16 * NRF51_PAGE_SIZE)
 
+#define NRF51_TWI_EVENT_STOPPED 0x104
+#define NRF51_TWI_EVENT_RXDREADY 0x108
+#define NRF51_TWI_EVENT_TXDSENT 0x11c
+#define NRF51_TWI_REG_RXD 0x518
+
 #define BASE_TO_IRQ(base) ((base >> 12) & 0x1F)
 
 static uint64_t clock_read(void *opaque, hwaddr addr, unsigned int size)
@@ -53,6 +58,58 @@ static const MemoryRegionOps clock_ops = {
 .write = clock_write
 };
 
+/* Two-Wire Interface (TWI) is not implemented but the microbit-dal firmware
+ * panics if the TWI accelerometer and magnetometer WHO_AM_I registers cannot
+ * be read.  Stub out this read sequence so microbit-dal starts up.
+ */
+static uint32_t twi_read_sequence[] = {0x5A, 0x5A, 0x40};
+static uint32_t twi_regs[0x1000 / 4];
+
+static uint64_t twi_read(void *opaque, hwaddr addr, unsigned int size)
+{
+static int i;
+uint64_t data = 0x00;
+
+switch (addr) {
+case NRF51_TWI_EVENT_STOPPED:
+data = 0x01;
+break;
+case NRF51_TWI_EVENT_RXDREADY:
+data = 0x01;
+break;
+case NRF51_TWI_EVENT_TXDSENT:
+data = 0x01;
+break;
+case NRF51_TWI_REG_RXD:
+data = twi_read_sequence[i];
+if (i < ARRAY_SIZE(twi_read_sequence)) {
+i++;
+}
+break;
+default:
+data = twi_regs[addr / 4];
+break;
+}
+
+qemu_log_mask(LOG_UNIMP, "%s: 0x%" HWADDR_PRIx " [%u] = %" PRIx32 "\n",
+  __func__, addr, size, (uint32_t)data);
+
+
+return data;
+}
+
+static void twi_write(void *opaque, hwaddr addr, uint64_t data,
+  unsigned int size)
+{
+qemu_log_mask(LOG_UNIMP, "%s: 0x%" HWADDR_PRIx " <- 0x%" PRIx64 " [%u]\n",
+  __func__, addr, data, size);
+twi_regs[addr / 4] = data;
+}
+
+static const MemoryRegionOps twi_ops = {
+.read = twi_read,
+.write = twi_write
+};
 
 static void nrf51_soc_realize(DeviceState *dev_soc, Error **errp)
 {
@@ -156,6 +213,11 @@ static void nrf51_soc_realize(DeviceState *dev_soc, Error 
**errp)
 memory_region_add_subregion_overlap(>container,
 NRF51_IOMEM_BASE, >clock, -1);
 
+memory_region_init_io(>twi, NULL, _ops, NULL,
+  "nrf51_soc.twi", 0x1000);
+memory_region_add_subregion_overlap(>container,
+NRF51_TWI_BASE, >twi, -1);
+
 create_unimplemented_device("nrf51_soc.io", NRF51_IOMEM_BASE,
 NRF51_IOMEM_SIZE);
 create_unimplemented_device("nrf51_soc.ficr", NRF51_FICR_BASE,
-- 
2.20.1

Re: [Qemu-devel] [RFC PATCH] osdep: Make MIN/MAX evaluate arguments only once

[Eric Blake]

On 1/5/19 7:48 AM, Eric Blake wrote:

> I'm fine keeping the name MIN/MAX for the common use, but we'd need a
> second pair, maybe named MIN_CONST/MAX_CONST, for use in contexts that
> require a constant (there, both arguments are evaluated twice because it
> is the naive implementation, but that is harmless because both arguments
> are constant and the macro is then usable in places where the smart
> MIN/MAX are not).  I don't know if trying to use __builtin_constant_p in
> the const version would also be worthwhile.  In fact, if
> __builtin_constant_p is powerful enough, perhaps we could use it to
> force a single macro to expand to the naive version if both arguments
> are constant and the smart version otherwise.  I'll give that a shot.

Alas, even though __builtin_constant_p can let the compiler overlook
SOME cases of non-constant code (as in __builtin_constant_p(0 && foo())
returning 1), it is not powerful enough to ignore the dead branch:

$ cat foo.c
#define MIN(a, b)   \
(__builtin_constant_p(a) && __builtin_constant_p(b) ?   \
 (a) < (b) ? (a) : (b) :\
 ({ \
 __auto_type _a = (a) + 0;  \
 __auto_type _b = (b) + 0;  \
 _a < _b ? _a : _b; \
 }))

char x[MIN(1, 2)];

int
main(int argc, char **argv)
{
return MIN(argc, 0);
}
$ gcc -o foo -Wall foo.c
foo.c:4:6: error: braced-group within expression allowed only inside a
function
  ({ \
  ^
foo.c:10:8: note: in expansion of macro ‘MIN’
 char x[MIN(1, 2)];
^~~

If anyone can come up with a workaround for single-macro usage, be my
guest.  Otherwise, I'm going with the two-macro solution, with MIN/MAX
for common use, and MIN_CONST/MAX_CONST for constant-context use.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org



signature.asc
Description: OpenPGP digital signature

[Qemu-devel] [PULL 6/8] nbd/client: More consistent error messages

[Eric Blake]

Consolidate on using decimal (not hex), on outputting the
option reply name (not just value), and a consistent comma between
clauses, when the client reports protocol discrepancies from the
server.  While it won't affect normal operation, it makes
debugging additions easier.

Signed-off-by: Eric Blake 
Reviewed-by: Richard W.M. Jones 
Reviewed-by: Vladimir Sementsov-Ogievskiy 
Message-Id: <20181215135324.152629-6-ebl...@redhat.com>
---
 nbd/client.c | 21 -
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/nbd/client.c b/nbd/client.c
index 0ad7147ed95..e77414711ba 100644
--- a/nbd/client.c
+++ b/nbd/client.c
@@ -132,8 +132,9 @@ static int nbd_receive_option_reply(QIOChannel *ioc, 
uint32_t opt,
 return -1;
 }
 if (reply->option != opt) {
-error_setg(errp, "Unexpected option type %x expected %x",
-   reply->option, opt);
+error_setg(errp, "Unexpected option type %u (%s), expected %u (%s)",
+   reply->option, nbd_opt_lookup(reply->option),
+   opt, nbd_opt_lookup(opt));
 nbd_send_opt_abort(ioc);
 return -1;
 }
@@ -267,8 +268,9 @@ static int nbd_receive_list(QIOChannel *ioc, const char 
*want, bool *match,
 }
 return 0;
 } else if (reply.type != NBD_REP_SERVER) {
-error_setg(errp, "Unexpected reply type %" PRIx32 " expected %x",
-   reply.type, NBD_REP_SERVER);
+error_setg(errp, "Unexpected reply type %u (%s), expected %u (%s)",
+   reply.type, nbd_rep_lookup(reply.type),
+   NBD_REP_SERVER, nbd_rep_lookup(NBD_REP_SERVER));
 nbd_send_opt_abort(ioc);
 return -1;
 }
@@ -380,9 +382,9 @@ static int nbd_opt_go(QIOChannel *ioc, const char *wantname,
 return 1;
 }
 if (reply.type != NBD_REP_INFO) {
-error_setg(errp, "unexpected reply type %" PRIu32
-   " (%s), expected %u",
-   reply.type, nbd_rep_lookup(reply.type), NBD_REP_INFO);
+error_setg(errp, "unexpected reply type %u (%s), expected %u (%s)",
+   reply.type, nbd_rep_lookup(reply.type),
+   NBD_REP_INFO, nbd_rep_lookup(NBD_REP_INFO));
 nbd_send_opt_abort(ioc);
 return -1;
 }
@@ -706,8 +708,9 @@ static int nbd_negotiate_simple_meta_context(QIOChannel 
*ioc,
 }

 if (reply.type != NBD_REP_ACK) {
-error_setg(errp, "Unexpected reply type %" PRIx32 " expected %x",
-   reply.type, NBD_REP_ACK);
+error_setg(errp, "Unexpected reply type %u (%s), expected %u (%s)",
+   reply.type, nbd_rep_lookup(reply.type),
+   NBD_REP_ACK, nbd_rep_lookup(NBD_REP_ACK));
 nbd_send_opt_abort(ioc);
 return -1;
 }
-- 
2.20.1

[Qemu-devel] [PULL 5/8] nbd: Document timeline of various features

[Eric Blake]

It can be useful to figure out which NBD protocol features are
exposed by a server, as well as what features a client will
take advantage of if available, for a given qemu release.  It's
not always precise to base features on version numbers (thanks
to downstream backports), but any documentation is better than
making users search through git logs themselves.

This patch originally stemmed from a request to document that
pristine 3.0 has a known bug where NBD_OPT_LIST_META_CONTEXT
with 0 queries forgot to advertise an available
"qemu:dirty-bitmap" context, but documenting bugs like this (or
the fact that 3.0 also botched NBD_CMD_CACHE) gets to be too
much details, especially since buggy releases will be less
likely connection targets over time.  Instead, I chose to just
remind users to check stable release branches.

Suggested-by: Vladimir Sementsov-Ogievskiy 
Signed-off-by: Eric Blake 
Message-Id: <20181215135324.152629-3-ebl...@redhat.com>
Reviewed-by: Richard W.M. Jones 
Reviewed-by: Vladimir Sementsov-Ogievskiy 
---
 docs/interop/nbd.txt | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/docs/interop/nbd.txt b/docs/interop/nbd.txt
index 77b5f459111..fc64473e02b 100644
--- a/docs/interop/nbd.txt
+++ b/docs/interop/nbd.txt
@@ -15,7 +15,6 @@ Qemu supports the "base:allocation" metadata context as 
defined in the
 NBD protocol specification, and also defines an additional metadata
 namespace "qemu".

-
 == "qemu" namespace ==

 The "qemu" namespace currently contains only one type of context,
@@ -36,3 +35,21 @@ in addition to 
"qemu:dirty-bitmap:":
 namespace.
 * "qemu:dirty-bitmap:" - returns list of all available dirty-bitmap
  metadata contexts.
+
+= Features by version =
+
+The following list documents which qemu version first implemented
+various features (both as a server exposing the feature, and as a
+client taking advantage of the feature when present), to make it
+easier to plan for cross-version interoperability.  Note that in
+several cases, the initial release containing a feature may require
+additional patches from the corresponding stable branch to fix bugs in
+the operation of that feature.
+
+* 2.6: NBD_OPT_STARTTLS with TLS X.509 Certificates
+* 2.8: NBD_CMD_WRITE_ZEROES
+* 2.10: NBD_OPT_GO, NBD_INFO_BLOCK
+* 2.11: NBD_OPT_STRUCTURED_REPLY
+* 2.12: NBD_CMD_BLOCK_STATUS for "base:allocation"
+* 3.0: NBD_OPT_STARTTLS with TLS Pre-Shared Keys (PSK),
+NBD_CMD_BLOCK_STATUS for "qemu:dirty-bitmap:", NBD_CMD_CACHE
-- 
2.20.1

[Qemu-devel] [PULL 4/8] qemu-nbd: Use program name in error messages

[Eric Blake]

This changes output from:

$ qemu-nbd nosuch
Failed to blk_new_open 'nosuch': Could not open 'nosuch': No such file or 
directory

to something more consistent with qemu-img and qemu:

$ qemu-nbd nosuch
qemu-nbd: Failed to blk_new_open 'nosuch': Could not open 'nosuch': No such 
file or directory

Update the lone affected test to match.  (Hmm - is it sad that we don't
do much testing of expected failures?)

Signed-off-by: Eric Blake 
Reviewed-by: Richard W.M. Jones 
Reviewed-by: Vladimir Sementsov-Ogievskiy 
Message-Id: <20181215135324.152629-2-ebl...@redhat.com>
---
 qemu-nbd.c | 1 +
 tests/qemu-iotests/233.out | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/qemu-nbd.c b/qemu-nbd.c
index ca7109652e5..e169b839ece 100644
--- a/qemu-nbd.c
+++ b/qemu-nbd.c
@@ -571,6 +571,7 @@ int main(int argc, char **argv)
 #endif

 module_call_init(MODULE_INIT_TRACE);
+error_set_progname(argv[0]);
 qcrypto_init(_fatal);

 module_call_init(MODULE_INIT_QOM);
diff --git a/tests/qemu-iotests/233.out b/tests/qemu-iotests/233.out
index 94acd9b9479..5f416721b03 100644
--- a/tests/qemu-iotests/233.out
+++ b/tests/qemu-iotests/233.out
@@ -27,7 +27,7 @@ virtual size: 64M (67108864 bytes)
 disk size: unavailable

 == check TLS with different CA fails ==
-option negotiation failed: Verify failed: No certificate was found.
+qemu-nbd: option negotiation failed: Verify failed: No certificate was found.
 qemu-img: Could not open 'driver=nbd,host=127.0.0.1,port=PORT,tls-creds=tls0': 
The certificate hasn't got a known issuer

 == perform I/O over TLS ==
-- 
2.20.1

[Qemu-devel] [PULL 3/8] block/nbd-client: use traces instead of noisy error_report_err

[Eric Blake]

From: Vladimir Sementsov-Ogievskiy 

Reduce extra noise of nbd-client, change 083 correspondingly.

In various commits (be41c100 in 2.10, f140e300 in 2.11, 78a33ab
in 2.12), we added spots where qemu as an NBD client would report
problems communicating with the server to stderr, because there
was no where else to send the error to.  However, this is racy,
particularly since the most common source of these errors is when
either the client or the server abruptly hangs up, leaving one
coroutine to report the error only if it wins (or loses) the
race in attempting the read from the server before another
thread completes its cleanup of a protocol error that caused the
disconnect in the first place.  The race is also apparent in the
fact that differences in the flush behavior of the server can
alter the frequency of encountering the race in the client (see
commit 6d39db96).

Rather than polluting stderr, it's better to just trace these
situations, for use by developers debugging a flaky connection,
particularly since the real error that either triggers the abrupt
disconnection in the first place, or that results from the EIO
when a request can't receive a reply, DOES make it back to the
user in the normal Error propagation channels.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
Message-Id: <20181102151152.288399-4-vsement...@virtuozzo.com>
[eblake: drop depedence on error hint, enhance commit message]
Signed-off-by: Eric Blake 
---
 block/nbd-client.c | 23 +++
 block/trace-events |  4 
 tests/qemu-iotests/083.out | 28 
 3 files changed, 23 insertions(+), 32 deletions(-)

diff --git a/block/nbd-client.c b/block/nbd-client.c
index fc5b7eda8ee..ef320759716 100644
--- a/block/nbd-client.c
+++ b/block/nbd-client.c
@@ -28,6 +28,8 @@
  */

 #include "qemu/osdep.h"
+
+#include "trace.h"
 #include "qapi/error.h"
 #include "nbd-client.h"

@@ -79,7 +81,8 @@ static coroutine_fn void nbd_read_reply_entry(void *opaque)
 assert(s->reply.handle == 0);
 ret = nbd_receive_reply(s->ioc, >reply, _err);
 if (local_err) {
-error_report_err(local_err);
+trace_nbd_read_reply_entry_fail(ret, error_get_pretty(local_err));
+error_free(local_err);
 }
 if (ret <= 0) {
 break;
@@ -771,7 +774,11 @@ static int nbd_co_request(BlockDriverState *bs, NBDRequest 
*request,

 ret = nbd_co_receive_return_code(client, request->handle, _err);
 if (local_err) {
-error_report_err(local_err);
+trace_nbd_co_request_fail(request->from, request->len, request->handle,
+  request->flags, request->type,
+  nbd_cmd_lookup(request->type),
+  ret, error_get_pretty(local_err));
+error_free(local_err);
 }
 return ret;
 }
@@ -802,7 +809,11 @@ int nbd_client_co_preadv(BlockDriverState *bs, uint64_t 
offset,
 ret = nbd_co_receive_cmdread_reply(client, request.handle, offset, qiov,
_err);
 if (local_err) {
-error_report_err(local_err);
+trace_nbd_co_request_fail(request.from, request.len, request.handle,
+  request.flags, request.type,
+  nbd_cmd_lookup(request.type),
+  ret, error_get_pretty(local_err));
+error_free(local_err);
 }
 return ret;
 }
@@ -925,7 +936,11 @@ int coroutine_fn 
nbd_client_co_block_status(BlockDriverState *bs,
 ret = nbd_co_receive_blockstatus_reply(client, request.handle, bytes,
, _err);
 if (local_err) {
-error_report_err(local_err);
+trace_nbd_co_request_fail(request.from, request.len, request.handle,
+  request.flags, request.type,
+  nbd_cmd_lookup(request.type),
+  ret, error_get_pretty(local_err));
+error_free(local_err);
 }
 if (ret < 0) {
 return ret;
diff --git a/block/trace-events b/block/trace-events
index 3e8c47bb243..693c14c4435 100644
--- a/block/trace-events
+++ b/block/trace-events
@@ -156,3 +156,7 @@ nvme_cmd_map_qiov_iov(void *s, int i, void *page, int 
pages) "s %p iov[%d] %p pa

 # block/iscsi.c
 iscsi_xcopy(void *src_lun, uint64_t src_off, void *dst_lun, uint64_t dst_off, 
uint64_t bytes, int ret) "src_lun %p offset %"PRIu64" dst_lun %p offset 
%"PRIu64" bytes %"PRIu64" ret %d"
+
+# block/nbd-client.c
+nbd_read_reply_entry_fail(int ret, const char *err) "ret = %d, err: %s"
+nbd_co_request_fail(uint64_t from, uint32_t len, uint64_t handle, uint16_t 
flags, uint16_t type, const char *name, int ret, const char *err) "Request 
failed { .from = %" PRIu64", .len = %" PRIu32 ", .handle = %" PRIu64 ", .flags 
= 0x%" PRIx16 ", .type = %" PRIu16 " (%s) } ret = %d, err: %s"
diff --git 

[Qemu-devel] [PULL 7/8] qemu-nbd: Fail earlier for -c/-d on non-linux

[Eric Blake]

Connecting to a /dev/nbdN device is a Linux-specific action.
We were already masking -c and -d from 'qemu-nbd --help' on
non-linux.  However, while -d fails with a sensible error
message, it took hunting through a couple of files to prove
that.  What's more, the code for -c doesn't fail until after
it has created a pthread and tried to open a device - possibly
even printing an error message with %m on a non-Linux platform
in spite of the comment that %m is glibc-specific.  Make the
failure happen sooner, then get rid of stubs that are no
longer needed because of the early exits.

While at it: tweak the blank newlines in --help output to be
consistent, whether or not built on Linux.

Signed-off-by: Eric Blake 
Message-Id: <20181215135324.152629-7-ebl...@redhat.com>
Reviewed-by: Richard W.M. Jones 
Reviewed-by: Vladimir Sementsov-Ogievskiy 
---
 nbd/client.c | 18 +-
 qemu-nbd.c   | 21 +++--
 2 files changed, 20 insertions(+), 19 deletions(-)

diff --git a/nbd/client.c b/nbd/client.c
index e77414711ba..5a03a844187 100644
--- a/nbd/client.c
+++ b/nbd/client.c
@@ -1031,23 +1031,7 @@ int nbd_disconnect(int fd)
 return 0;
 }

-#else
-int nbd_init(int fd, QIOChannelSocket *ioc, NBDExportInfo *info,
-Error **errp)
-{
-error_setg(errp, "nbd_init is only supported on Linux");
-return -ENOTSUP;
-}
-
-int nbd_client(int fd)
-{
-return -ENOTSUP;
-}
-int nbd_disconnect(int fd)
-{
-return -ENOTSUP;
-}
-#endif
+#endif /* __linux__ */

 int nbd_send_request(QIOChannel *ioc, NBDRequest *request)
 {
diff --git a/qemu-nbd.c b/qemu-nbd.c
index e169b839ece..2807e132396 100644
--- a/qemu-nbd.c
+++ b/qemu-nbd.c
@@ -43,6 +43,12 @@
 #include "trace/control.h"
 #include "qemu-version.h"

+#ifdef __linux__
+#define HAVE_NBD_DEVICE 1
+#else
+#define HAVE_NBD_DEVICE 0
+#endif
+
 #define SOCKET_PATH"/var/lock/qemu-nbd-%s"
 #define QEMU_NBD_OPT_CACHE 256
 #define QEMU_NBD_OPT_AIO   257
@@ -98,11 +104,11 @@ static void usage(const char *name)
 "specify tracing options\n"
 "  --forkfork off the server process and exit the parent\n"
 "once the server is running\n"
-#ifdef __linux__
+#if HAVE_NBD_DEVICE
+"\n"
 "Kernel NBD client support:\n"
 "  -c, --connect=DEV connect FILE to the local NBD device DEV\n"
 "  -d, --disconnect  disconnect the specified device\n"
-"\n"
 #endif
 "\n"
 "Block device options:\n"
@@ -236,6 +242,7 @@ static void termsig_handler(int signum)
 }


+#if HAVE_NBD_DEVICE
 static void *show_parts(void *arg)
 {
 char *device = arg;
@@ -321,6 +328,7 @@ out:
 kill(getpid(), SIGTERM);
 return (void *) EXIT_FAILURE;
 }
+#endif /* HAVE_NBD_DEVICE */

 static int nbd_can_accept(void)
 {
@@ -814,6 +822,12 @@ int main(int argc, char **argv)
 }
 }

+#if !HAVE_NBD_DEVICE
+if (disconnect || device) {
+error_report("Kernel /dev/nbdN support not available");
+exit(EXIT_FAILURE);
+}
+#else /* HAVE_NBD_DEVICE */
 if (disconnect) {
 int nbdfd = open(argv[optind], O_RDWR);
 if (nbdfd < 0) {
@@ -829,6 +843,7 @@ int main(int argc, char **argv)

 return 0;
 }
+#endif

 if ((device && !verbose) || fork_process) {
 int stderr_fd[2];
@@ -1006,6 +1021,7 @@ int main(int argc, char **argv)
 nbd_export_set_description(exp, export_description);

 if (device) {
+#if HAVE_NBD_DEVICE
 int ret;

 ret = pthread_create(_thread, NULL, nbd_client_thread, device);
@@ -1013,6 +1029,7 @@ int main(int argc, char **argv)
 error_report("Failed to create client thread: %s", strerror(ret));
 exit(EXIT_FAILURE);
 }
+#endif
 } else {
 /* Shut up GCC warnings.  */
 memset(_thread, 0, sizeof(client_thread));
-- 
2.20.1

[Qemu-devel] [PULL 1/8] nbd: publish _lookup functions

[Eric Blake]

From: Vladimir Sementsov-Ogievskiy 

These functions are used for formatting pretty trace points. We are
going to add some in block/nbd-client, so, let's publish all these
functions at once. Note, that nbd_reply_type_lookup is already
published, and constants, "named" by these functions live in
include/block/nbd.h too.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
Message-Id: <20181102151152.288399-3-vsement...@virtuozzo.com>
Reviewed-by: Eric Blake 
Signed-off-by: Eric Blake 
---
 include/block/nbd.h | 5 +
 nbd/nbd-internal.h  | 5 -
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/include/block/nbd.h b/include/block/nbd.h
index 6a5bfe5d559..65402d33964 100644
--- a/include/block/nbd.h
+++ b/include/block/nbd.h
@@ -343,5 +343,10 @@ static inline bool nbd_reply_is_structured(NBDReply *reply)
 }

 const char *nbd_reply_type_lookup(uint16_t type);
+const char *nbd_opt_lookup(uint32_t opt);
+const char *nbd_rep_lookup(uint32_t rep);
+const char *nbd_info_lookup(uint16_t info);
+const char *nbd_cmd_lookup(uint16_t info);
+const char *nbd_err_lookup(int err);

 #endif
diff --git a/nbd/nbd-internal.h b/nbd/nbd-internal.h
index eeff78d3c98..f38be9ebaaf 100644
--- a/nbd/nbd-internal.h
+++ b/nbd/nbd-internal.h
@@ -100,11 +100,6 @@ struct NBDTLSHandshakeData {

 void nbd_tls_handshake(QIOTask *task,
void *opaque);
-const char *nbd_opt_lookup(uint32_t opt);
-const char *nbd_rep_lookup(uint32_t rep);
-const char *nbd_info_lookup(uint16_t info);
-const char *nbd_cmd_lookup(uint16_t info);
-const char *nbd_err_lookup(int err);

 int nbd_drop(QIOChannel *ioc, size_t size, Error **errp);

-- 
2.20.1

[Qemu-devel] [PULL 8/8] nbd/client: Drop pointless buf variable

[Eric Blake]

There's no need to read into a temporary buffer (oversized
since commit 7d3123e1) followed by a byteswap into a uint64_t
to check for a magic number via memcmp(), when the code
immediately below demonstrates reading into the uint64_t then
byteswapping in place and checking for a magic number via
integer math.  What's more, having a different error message
when the server's first reply byte is 0 is unusual - it's no
different from any other wrong magic number, and we already
detected short reads. That whole strlen() issue has been
present and useless since commit 1d45f8b5 in 2010; perhaps it
was leftover debugging (since the correct magic number happens
to be ASCII)?  Make the error messages more consistent and
detailed while touching things.

Signed-off-by: Eric Blake 
Reviewed-by: Richard W.M. Jones 
Reviewed-by: Vladimir Sementsov-Ogievskiy 
Message-Id: <20181215135324.152629-9-ebl...@redhat.com>
---
 nbd/nbd-internal.h |  3 ++-
 nbd/client.c   | 22 +++---
 2 files changed, 9 insertions(+), 16 deletions(-)

diff --git a/nbd/nbd-internal.h b/nbd/nbd-internal.h
index f38be9ebaaf..82aa221227f 100644
--- a/nbd/nbd-internal.h
+++ b/nbd/nbd-internal.h
@@ -46,8 +46,9 @@
 /* Size of oldstyle negotiation */
 #define NBD_OLDSTYLE_NEGOTIATE_SIZE (8 + 8 + 8 + 4 + 124)

+#define NBD_INIT_MAGIC  0x4e42444d41474943LL /* ASCII "NBDMAGIC" */
 #define NBD_REQUEST_MAGIC   0x25609513
-#define NBD_OPTS_MAGIC  0x49484156454F5054LL
+#define NBD_OPTS_MAGIC  0x49484156454F5054LL /* ASCII "IHAVEOPT" */
 #define NBD_CLIENT_MAGIC0x420281861253LL
 #define NBD_REP_MAGIC   0x0003e889045565a9LL

diff --git a/nbd/client.c b/nbd/client.c
index 5a03a844187..f625c207c54 100644
--- a/nbd/client.c
+++ b/nbd/client.c
@@ -733,7 +733,6 @@ int nbd_receive_negotiate(QIOChannel *ioc, const char *name,
   QIOChannel **outioc, NBDExportInfo *info,
   Error **errp)
 {
-char buf[256];
 uint64_t magic;
 int rc;
 bool zeroes = true;
@@ -754,27 +753,20 @@ int nbd_receive_negotiate(QIOChannel *ioc, const char 
*name,
 goto fail;
 }

-if (nbd_read(ioc, buf, 8, errp) < 0) {
-error_prepend(errp, "Failed to read data: ");
+if (nbd_read(ioc, , sizeof(magic), errp) < 0) {
+error_prepend(errp, "Failed to read initial magic: ");
 goto fail;
 }
-
-buf[8] = '\0';
-if (strlen(buf) == 0) {
-error_setg(errp, "Server connection closed unexpectedly");
-goto fail;
-}
-
-magic = ldq_be_p(buf);
+magic = be64_to_cpu(magic);
 trace_nbd_receive_negotiate_magic(magic);

-if (memcmp(buf, "NBDMAGIC", 8) != 0) {
-error_setg(errp, "Invalid magic received");
+if (magic != NBD_INIT_MAGIC) {
+error_setg(errp, "Bad initial magic received: 0x%" PRIx64, magic);
 goto fail;
 }

 if (nbd_read(ioc, , sizeof(magic), errp) < 0) {
-error_prepend(errp, "Failed to read magic: ");
+error_prepend(errp, "Failed to read server magic: ");
 goto fail;
 }
 magic = be64_to_cpu(magic);
@@ -913,7 +905,7 @@ int nbd_receive_negotiate(QIOChannel *ioc, const char *name,
 }
 info->flags = oldflags;
 } else {
-error_setg(errp, "Bad magic received");
+error_setg(errp, "Bad server magic received: 0x%" PRIx64, magic);
 goto fail;
 }

-- 
2.20.1

[Qemu-devel] [PULL 2/8] nbd/client: Trace all server option error messages

[Eric Blake]

Not all servers send free-form text alongside option error replies, but
for servers that do (such as qemu), we pass the server's message as a
hint alongside our own error reporting.  However, it would also be
useful to trace such server messages, since we can't guarantee how the
hint may be consumed.

Signed-off-by: Eric Blake 
Message-Id: <20181218225714.284495-3-ebl...@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy 
---
 nbd/client.c | 2 ++
 nbd/trace-events | 1 +
 2 files changed, 3 insertions(+)

diff --git a/nbd/client.c b/nbd/client.c
index b4d457a19ad..0ad7147ed95 100644
--- a/nbd/client.c
+++ b/nbd/client.c
@@ -171,6 +171,8 @@ static int nbd_handle_reply_err(QIOChannel *ioc, 
NBDOptionReply *reply,
 goto cleanup;
 }
 msg[reply->length] = '\0';
+trace_nbd_server_error_msg(reply->type,
+   nbd_reply_type_lookup(reply->type), msg);
 }

 switch (reply->type) {
diff --git a/nbd/trace-events b/nbd/trace-events
index 5e1d4afe8e6..5492042acbf 100644
--- a/nbd/trace-events
+++ b/nbd/trace-events
@@ -1,6 +1,7 @@
 # nbd/client.c
 nbd_send_option_request(uint32_t opt, const char *name, uint32_t len) "Sending 
option request %" PRIu32" (%s), len %" PRIu32
 nbd_receive_option_reply(uint32_t option, const char *optname, uint32_t type, 
const char *typename, uint32_t length) "Received option reply %" PRIu32" (%s), 
type %" PRIu32" (%s), len %" PRIu32
+nbd_server_error_msg(uint32_t err, const char *type, const char *msg) "server 
reported error 0x%" PRIx32 " (%s) with additional message: %s"
 nbd_reply_err_unsup(uint32_t option, const char *name) "server doesn't 
understand request %" PRIu32 " (%s), attempting fallback"
 nbd_opt_go_start(const char *name) "Attempting NBD_OPT_GO for export '%s'"
 nbd_opt_go_success(void) "Export is good to go"
-- 
2.20.1

[Qemu-devel] [PULL 0/8] NBD patches through 2019-01-05

[Eric Blake]

The following changes since commit 9b2e891ec5ccdb4a7d583b77988848282606fdea:

  Merge remote-tracking branch 'remotes/marcel/tags/rdma-pull-request' into 
staging (2018-12-22 11:25:31 +)

are available in the Git repository at:

  https://repo.or.cz/qemu/ericb.git tags/pull-nbd-2019-01-05

for you to fetch changes up to ef2e35fcc8e14bcc9366df5fdf53f65d679f8dca:

  nbd/client: Drop pointless buf variable (2019-01-05 07:53:22 -0600)


nbd patches for 2019-01-05

Error and trace improvements in NBD code, such as less noise for
common disconnect scenarios.

- Vladimir Sementsov-Ogievskiy: 0/3 nbd-client: drop extra error noise
- Eric Blake: portions of 0/22 nbd: add qemu-nbd --list


Eric Blake (6):
  nbd/client: Trace all server option error messages
  qemu-nbd: Use program name in error messages
  nbd: Document timeline of various features
  nbd/client: More consistent error messages
  qemu-nbd: Fail earlier for -c/-d on non-linux
  nbd/client: Drop pointless buf variable

Vladimir Sementsov-Ogievskiy (2):
  nbd: publish _lookup functions
  block/nbd-client: use traces instead of noisy error_report_err

 docs/interop/nbd.txt   | 19 +-
 include/block/nbd.h|  5 
 nbd/nbd-internal.h |  8 ++
 block/nbd-client.c | 23 ++---
 nbd/client.c   | 63 --
 qemu-nbd.c | 22 ++--
 block/trace-events |  4 +++
 nbd/trace-events   |  1 +
 tests/qemu-iotests/083.out | 28 -
 tests/qemu-iotests/233.out |  2 +-
 10 files changed, 92 insertions(+), 83 deletions(-)

-- 
2.20.1

Re: [Qemu-devel] [PATCH v2 08/22] nbd/client: Drop pointless buf variable

[Eric Blake]

On 12/15/18 7:53 AM, Eric Blake wrote:
> There's no need to read into a temporary buffer (oversized
> since commit 7d3123e1) followed by a byteswap into a uint64_t
> to check for a magic number via memcmp(), when the code
> immediately below demonstrates reading into the uint64_t then
> byteswapping in place and checking for a magic number via
> integer math.  What's more, having a different error message
> when the server's first reply byte is 0 is unusual - it's no
> different from any other wrong magic number, and we already
> detected short reads. That whole strlen() issue has been
> present and useless since commit 1d45f8b5 in 2010; perhaps it
> was leftover debugging (since the correct magic number happens
> to be ASCII)?  Make the error messages more consistent and
> detailed while touching things.
> 
> Signed-off-by: Eric Blake 
> Reviewed-by: Richard W.M. Jones 
> Reviewed-by: Vladimir Sementsov-Ogievskiy 

I'm queuing 1, 2, 5, 6, and 8 for my next NBD pull request, and will
respin the rest of the series to incorporate review comments.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [RFC PATCH] osdep: Make MIN/MAX evaluate arguments only once

[Eric Blake]

On 1/4/19 6:23 PM, Zoltán Kővágó wrote:
> Hi,
> 
> I have a similar patch in my queue[1]
> 

Sorry for not noticing that thread.


>>  #ifndef MIN
>> -#define MIN(a, b) (((a) < (b)) ? (a) : (b))

The old version is at least named in ALL_CAPS, to warn the user that it
is a macro and may have side effects due to multiple evaluations.

>> +#define MIN(a, b)  \
>> +({ \
>> +__auto_type _a = (a);  \
>> +__auto_type _b = (b);  \
>> +_a < _b ? _a : _b; \
>> +})
>>  #endif


> I tried this[2], but apparently random linux headers define their own
> MIN/MAX and in case this version won't be used.

Indeed; changing

#ifndef MIN

to

#undef MIN

forces us to use our version rather than inheriting something, at which
point...

> And the version above
> with __auto_type and statement expression doesn't work on bitfields and
> when not in functions (for example struct XHCIState has
> USBPort  uports[MAX(MAXPORTS_2, MAXPORTS_3)];
> as one of its member).

Yeah, I ran into that on libvirt as well.  It's a real bummer that
__auto_type can't be used in constant expressions; I don't know if C11
generics can be used to come up with an alternative that still qualifies
as a constant expression.

Quoting your other mail:

>> /home/dirty_ice/qemu/include/qemu/osdep.h:240:5: error: ‘__auto_type’
>> used with a bit-field initializer
>> /home/dirty_ice/qemu/include/qemu/osdep.h:247:35: error: braced-group
>> within expression allowed only inside a function
>> 
>> The first one is fixable with an explicit cast (ugly but works),

Or by writing:

__auto_type _a = (a) + 0;
typeof((a) + 0) _a = (a) + 0;

to force type promotion of the bitfield 'a' (no casts needed, either at
the caller or in the macro).  Since we are doing ?: between a and b, we
end up with integer promotion anyways (that is, MIN(char, char) still
results in int, and that's unchanged regardless of naive or smart
implementation of the macro; the only way to get MIN(char, char) to
result in char is with typeof, although I don't see any strong reasons
why making the macro return an unpromoted value would ever be useful).

>> but the
>> second one is more problematic. It means we can't write stuff like
>> 
>> USBPort  uports[MAX(MAXPORTS_2, MAXPORTS_3)];
>> 
>> when not in a function. So we either need a dumb version of MIN/MAX, or
>> scrape the idea altogether.

I'm fine keeping the name MIN/MAX for the common use, but we'd need a
second pair, maybe named MIN_CONST/MAX_CONST, for use in contexts that
require a constant (there, both arguments are evaluated twice because it
is the naive implementation, but that is harmless because both arguments
are constant and the macro is then usable in places where the smart
MIN/MAX are not).  I don't know if trying to use __builtin_constant_p in
the const version would also be worthwhile.  In fact, if
__builtin_constant_p is powerful enough, perhaps we could use it to
force a single macro to expand to the naive version if both arguments
are constant and the smart version otherwise.  I'll give that a shot.

> It only works because currently glib/gmacros.h or
> sys/param.h defines it's own MIN/MAX which is identical to the old version.
> 
> Now that I think about it, instead of undefining the old macro or only
> conditionally defining it, maybe the best course of action would be to
> rename MIN/MAX to something more unique so it won't clash with random
> system headers.

No, if we want smart MIN/MAX, we merely undefine whatever random junk
got inherited from the system.  If we rename anything, it should be the
constant version for use where the smart version is semantically prohibited.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org



signature.asc
Description: OpenPGP digital signature

[Qemu-devel] [Bug 1810433] Re: aarch64-linux-user master: inconsistent pwrite behaviour

[Matwey V. Kornilov]

I've also check qemu-arm with the same test code. Surprisingly, I see
correct result:

pwrite ret = 0

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1810433

Title:
  aarch64-linux-user master: inconsistent pwrite behaviour

Status in QEMU:
  New

Bug description:
  Hello,

  I am running aarch64-linux-user from master, commit
  20d6c7312f1b812bb9c750f4087f69ac8485cc90

  And I've found the following inconsistent emulation of pwrite() call when 
buf==NULL and len=0.
  Minimal reproducible sample is the following:

  #define _GNU_SOURCE
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 

  /*
   System  | Result
  -+
   Native x86_64 4.12.14   | pwrite ret = 0
   Native aarch64 4.4.159  | pwrite ret = 0
   qemu-aarch64 at x86_64  | pwrite ret = -1
     ( 20d6c7312f1b8 ) |
  */

  int main(int argc, char** argv) {
   int fd = open("test.dat", O_CREAT | O_RDWR, 0644);
   if (fd < 0) {
    perror("open");
    return 1;
   }

   int ret = fallocate(fd, 0, 0, 1000);
   if (ret < 0) {
    perror("fallocate");
    return 1;
   }

   ssize_t ret_pwrite = pwrite(fd, NULL, 0, 0);
   printf("pwrite ret = %ld\n", ret_pwrite);

   close(fd);

   return 0;
  }

  
  Please note, that the same binary executable prints different output at 
native aarch64 platform and under aarch64-linux-user

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1810433/+subscriptions

[Qemu-devel] [Bug 1810590] [NEW] Record/replay example does not work

[Andreas Gustafsson]

Public bug reported:

Trying the record part of the record/replay example at
https://github.com/qemu/qemu/blob/master/docs/replay.txt qemu
immediately hangs with no guest output displayed.  This is with qemu
from today's git (e59dbbac0364344a3ad84c3497a98c56003d3fb8).

To reproduce:

  wget
https://people.debian.org/~aurel32/qemu/i386/debian_squeeze_i386_standard.qcow2

  mv debian_squeeze_i386_standard.qcow2 disk.qcow2

  qemu-system-i386 \
   -icount shift=7,rr=record,rrfile=replay.bin \
   -drive file=disk.qcow2,if=none,id=img-direct \
   -drive driver=blkreplay,if=none,image=img-direct,id=img-blkreplay \
   -device ide-hd,drive=img-blkreplay \
   -netdev user,id=net1 -device rtl8139,netdev=net1 \
   -object filter-replay,id=replay,netdev=net1

The above qemu command line is exactly the same as in the example.

Tested on a Debian 9 x86_64 host.

** Affects: qemu
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1810590

Title:
  Record/replay example does not work

Status in QEMU:
  New

Bug description:
  Trying the record part of the record/replay example at
  https://github.com/qemu/qemu/blob/master/docs/replay.txt qemu
  immediately hangs with no guest output displayed.  This is with qemu
  from today's git (e59dbbac0364344a3ad84c3497a98c56003d3fb8).

  To reproduce:

wget
  
https://people.debian.org/~aurel32/qemu/i386/debian_squeeze_i386_standard.qcow2

mv debian_squeeze_i386_standard.qcow2 disk.qcow2

qemu-system-i386 \
 -icount shift=7,rr=record,rrfile=replay.bin \
 -drive file=disk.qcow2,if=none,id=img-direct \
 -drive driver=blkreplay,if=none,image=img-direct,id=img-blkreplay \
 -device ide-hd,drive=img-blkreplay \
 -netdev user,id=net1 -device rtl8139,netdev=net1 \
 -object filter-replay,id=replay,netdev=net1

  The above qemu command line is exactly the same as in the example.

  Tested on a Debian 9 x86_64 host.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1810590/+subscriptions

[Qemu-devel] [PATCH] qemu-iotests: add test case for dmg

[yuchenlin]

Recently, some bugs in dmg file have been fixed. To prevent reading dmg
is broken someday in the future, add a simple test which ensures the
conversion from dmg to raw should not hang or face any I/O error.

Signed-off-by: yuchenlin 
---
 tests/qemu-iotests/236|  53 ++
 tests/qemu-iotests/236.out|   4 ++
 tests/qemu-iotests/check  |   7 +++
 tests/qemu-iotests/group  |   1 +
 .../sample_images/simple-dmg.dmg.bz2  | Bin 0 -> 3479 bytes
 5 files changed, 65 insertions(+)
 create mode 100755 tests/qemu-iotests/236
 create mode 100644 tests/qemu-iotests/236.out
 create mode 100644 tests/qemu-iotests/sample_images/simple-dmg.dmg.bz2

diff --git a/tests/qemu-iotests/236 b/tests/qemu-iotests/236
new file mode 100755
index 00..6f085d573d
--- /dev/null
+++ b/tests/qemu-iotests/236
@@ -0,0 +1,53 @@
+#!/bin/bash
+#
+# Test case for dmg
+#
+# Copyright (C) 2019 yuchenlin 
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see .
+#
+
+# creator
+owner=npes87...@gmail.com
+
+seq=`basename $0`
+echo "QA output created by $seq"
+
+status=1   # failure is the default!
+
+_cleanup()
+{
+rm -f "$TEST_IMG.raw"
+_cleanup_test_img
+}
+trap "_cleanup; exit \$status" 0 1 2 3 15
+
+# get standard environment, filters and checks
+. ./common.rc
+
+_supported_fmt dmg
+_supported_proto file
+_supported_os Linux
+
+echo
+echo "== Testing conversion to raw should success =="
+_use_sample_img simple-dmg.dmg.bz2
+if ! $QEMU_IMG convert -f $IMGFMT -O raw "$TEST_IMG" "$TEST_IMG.raw" ; then
+exit 1
+fi
+
+# success, all done
+echo "*** done"
+rm -f $seq.full
+status=0
diff --git a/tests/qemu-iotests/236.out b/tests/qemu-iotests/236.out
new file mode 100644
index 00..a92fc657dd
--- /dev/null
+++ b/tests/qemu-iotests/236.out
@@ -0,0 +1,4 @@
+QA output created by 236
+
+== Testing conversion to raw should success ==
+*** done
diff --git a/tests/qemu-iotests/check b/tests/qemu-iotests/check
index 89ed275988..895e1e3dcb 100755
--- a/tests/qemu-iotests/check
+++ b/tests/qemu-iotests/check
@@ -237,6 +237,7 @@ image format options
 -vhdx   test vhdx
 -vmdk   test vmdk
 -luks   test luks
+-dmgtest dmg
 
 image protocol options
 -file   test file (default)
@@ -304,6 +305,12 @@ testlist options
 xpand=false
 ;;
 
+-dmg)
+IMGFMT=dmg
+IMGFMT_GENERIC=false
+xpand=false
+;;
+
 -qed)
 IMGFMT=qed
 xpand=false
diff --git a/tests/qemu-iotests/group b/tests/qemu-iotests/group
index 61a6d98ebd..623ede30f5 100644
--- a/tests/qemu-iotests/group
+++ b/tests/qemu-iotests/group
@@ -233,3 +233,4 @@
 233 auto quick
 234 auto quick migration
 235 auto quick
+236 rw auto quick
diff --git a/tests/qemu-iotests/sample_images/simple-dmg.dmg.bz2 
b/tests/qemu-iotests/sample_images/simple-dmg.dmg.bz2
new file mode 100644
index 
..05e719d03d48d6df4f0e995dd8bae1ce54c9f5f0
GIT binary patch
literal 3479
zcmV;I4QTR0T4*^jL0KkKS(36)s{k7pfB*mg|NsC0|NsC0|NsC0|NsC0|Ns5}|NsC0
z|NsC0|Nr0#eji@i`+e|w_jjtUioUNn9=bhi?FYz+8lea^Pt`n6Q`GfM=uI^|rccqR
z#)^4QQ(^vx-<6U8+BMo&{rPgMO9KU6K>tx+G-x7
zKxhH7gFqfr)EbhWqfmN7Xqi0_(|U$T%^~Te(<9O!s(P57)gFnX(HMqCnW^apCLkWB
zfB?c`7=Y8$P|yP*p{9YL8X6e}jSLZ{Kmat*Y9I=F1sjv(V%IjnFNxA1T<(7k~Y;aPez3F!fB%)byHqn^PtYN0c*2G*ZllN2a;wYb5Z@K!FpiLKS04
zAXF_RNbYzNTvjprs6=NSa4=(xVBCm>1#>twBnc>5NRuJv+UXVcw)$K?45Ra5gMtys
z5#=tTi{6o_Dolm>AW0*9z$7i33Gt*7^pYSUXUfIy=|9=(Y5F2D)W#);#I!)dBq)W~
zrFlJ*pf<%vEyY-2j;_z6FzSi8mQn!dfdGLU#z+u}O%{xk@FlI`
z^B@Tz!-52v0~!WxwY>yM5j2L!wDW07lb>SjKuGF1Bv7*3#(>;=WH?%<2(%C(%mi
z3SK&{tsN6|F+h=$fRF|SAT=$CM8UPyf@;hw?Ie+ur$Ms`?n=
z=TVuCRg<`%CTS#rC3Rqi{8+-#G7{}$If>{u-}tqnXQGZ1vrDn(W+-ydtwD_5(m9
zUlJm4YF$|a547Ok)VNY_1&|O?|T)
z42v8J{j@}JBoR7501!b0TQLa}5=%fGiZ01vc2PsfW3IL_R4y29^38$GN@}eFEu8;#~W3O
zhYo*p2)1qo0FWCdNC$P6JWDI)lRL3RsCq~;CddNVfDeUAK|}zQbl`V}JlvEcUSn8M
zpVIf%kFZ>u>OO0J!nRehCj34b%X*%F`iNsN=6_pV>qqFshZ5Cm#cE(tAoIY;2;n;
z>6lWK8VC|iQ`TBT@eh_haUvW?s0F~|jWOEDBrNGaBoJh|LX9lsM4vqVlOYszX7pdA
z{D&2t%ysWP%2Q6LEk#Gf-=1UdvZ5a1%=kY@b_PJ?B`u>CaLI_7b|;n=Za
zp~fR)pUI5+fvC#Km(lVCNpb=XW#mzCYrKf$7gM(TqYzYBKqz54qqz-xcv$fGQrdYy
zRD%pqsY(=-5JXlPYst2Xv=#sccTUb6A-KFq8XNZ`G)4wExi9zHxBO=zO;AbFM}`M!