[Qemu-devel] [PATCH v2 0/3] Series to implement suspend for ppc/spapr

2019-07-21 Thread Nicholas Piggin
Hi, this series is rebased on top of the qmp event fix, and takes
Paolo's suggestion to implement ->wakeup for i386 before adding
ppc, which makes it much nicer.

If the first two patches can be agreed on initially and merged, I
can take the third patch through the ppc list after that.

Thanks,
Nick

Nicholas Piggin (3):
  machine: Add wakeup method to MachineClass
  i386: use machine class ->wakeup method
  spapr: Implement ibm,suspend-me

 hw/i386/pc.c   |  8 
 hw/ppc/spapr.c |  7 +++
 hw/ppc/spapr_rtas.c| 32 
 include/hw/boards.h|  1 +
 include/hw/ppc/spapr.h |  3 ++-
 vl.c   | 16 +++-
 6 files changed, 65 insertions(+), 2 deletions(-)

-- 
2.20.1




[Qemu-devel] [PATCH v2 1/3] machine: Add wakeup method to MachineClass

2019-07-21 Thread Nicholas Piggin
Waking from suspend is not logically a machine reset on all machines,
particularly in the paravirtualized case rather than hardware
emulated. The ppc spapr machine for example just invokes hypervisor
to suspend, and expects that call to return with the machine in the
same state (modulo some possible migration and reconfiguration
details).

Implement a machine ->wakeup method and use that if it exists.

Signed-off-by: Nicholas Piggin 
---
 include/hw/boards.h |  1 +
 vl.c| 18 +-
 2 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/include/hw/boards.h b/include/hw/boards.h
index a71d1a53a5..915ac3352b 100644
--- a/include/hw/boards.h
+++ b/include/hw/boards.h
@@ -180,6 +180,7 @@ struct MachineClass {
 
 void (*init)(MachineState *state);
 void (*reset)(MachineState *state);
+void (*wakeup)(MachineState *state);
 void (*hot_add_cpu)(MachineState *state, const int64_t id, Error **errp);
 int (*kvm_type)(MachineState *machine, const char *arg);
 void (*smp_parse)(MachineState *ms, QemuOpts *opts);
diff --git a/vl.c b/vl.c
index cefe5a3968..45ea034410 100644
--- a/vl.c
+++ b/vl.c
@@ -1556,6 +1556,22 @@ void qemu_system_reset(ShutdownCause reason)
 cpu_synchronize_all_post_reset();
 }
 
+/*
+ * Wake the VM after suspend.
+ */
+static void qemu_system_wakeup(void)
+{
+MachineClass *mc;
+
+mc = current_machine ? MACHINE_GET_CLASS(current_machine) : NULL;
+
+if (mc && mc->wakeup) {
+mc->wakeup(current_machine);
+} else {
+qemu_system_reset(SHUTDOWN_CAUSE_NONE);
+}
+}
+
 void qemu_system_guest_panicked(GuestPanicInformation *info)
 {
 qemu_log_mask(LOG_GUEST_ERROR, "Guest crashed");
@@ -1764,7 +1780,7 @@ static bool main_loop_should_exit(void)
 }
 if (qemu_wakeup_requested()) {
 pause_all_vcpus();
-qemu_system_reset(SHUTDOWN_CAUSE_NONE);
+qemu_system_wakeup();
 notifier_list_notify(_notifiers, _reason);
 wakeup_reason = QEMU_WAKEUP_REASON_NONE;
 resume_all_vcpus();
-- 
2.20.1




[Qemu-devel] [PATCH v2 1/3] machine: Add wakeup method to MachineClass

2019-07-21 Thread Nicholas Piggin
Waking from suspend is not logically a machine reset on all machines,
particularly in the paravirtualized case rather than hardware
emulated. The ppc spapr machine for example just invokes hypervisor
to suspend, and expects that call to return with the machine in the
same state (modulo some possible migration and reconfiguration
details).

Implement a machine ->wakeup method and use that if it exists.

Signed-off-by: Nicholas Piggin 
---
 include/hw/boards.h |  1 +
 vl.c| 18 +-
 2 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/include/hw/boards.h b/include/hw/boards.h
index a71d1a53a5..915ac3352b 100644
--- a/include/hw/boards.h
+++ b/include/hw/boards.h
@@ -180,6 +180,7 @@ struct MachineClass {
 
 void (*init)(MachineState *state);
 void (*reset)(MachineState *state);
+void (*wakeup)(MachineState *state);
 void (*hot_add_cpu)(MachineState *state, const int64_t id, Error **errp);
 int (*kvm_type)(MachineState *machine, const char *arg);
 void (*smp_parse)(MachineState *ms, QemuOpts *opts);
diff --git a/vl.c b/vl.c
index cefe5a3968..45ea034410 100644
--- a/vl.c
+++ b/vl.c
@@ -1556,6 +1556,22 @@ void qemu_system_reset(ShutdownCause reason)
 cpu_synchronize_all_post_reset();
 }
 
+/*
+ * Wake the VM after suspend.
+ */
+static void qemu_system_wakeup(void)
+{
+MachineClass *mc;
+
+mc = current_machine ? MACHINE_GET_CLASS(current_machine) : NULL;
+
+if (mc && mc->wakeup) {
+mc->wakeup(current_machine);
+} else {
+qemu_system_reset(SHUTDOWN_CAUSE_NONE);
+}
+}
+
 void qemu_system_guest_panicked(GuestPanicInformation *info)
 {
 qemu_log_mask(LOG_GUEST_ERROR, "Guest crashed");
@@ -1764,7 +1780,7 @@ static bool main_loop_should_exit(void)
 }
 if (qemu_wakeup_requested()) {
 pause_all_vcpus();
-qemu_system_reset(SHUTDOWN_CAUSE_NONE);
+qemu_system_wakeup();
 notifier_list_notify(_notifiers, _reason);
 wakeup_reason = QEMU_WAKEUP_REASON_NONE;
 resume_all_vcpus();
-- 
2.20.1




[Qemu-devel] [PATCH v2 0/3] Series to implement suspend for ppc/spapr

2019-07-21 Thread Nicholas Piggin
Hi, this series is rebased on top of the qmp event fix, and takes
Paolo's suggestion to implement ->wakeup for i386 before adding
ppc, which makes it much nicer.

If the first two patches can be agreed on initially and merged, I
can take the third patch through the ppc list after that.

Thanks,
Nick

Nicholas Piggin (3):
  machine: Add wakeup method to MachineClass
  i386: use machine class ->wakeup method
  spapr: Implement ibm,suspend-me

 hw/i386/pc.c   |  8 
 hw/ppc/spapr.c |  7 +++
 hw/ppc/spapr_rtas.c| 32 
 include/hw/boards.h|  1 +
 include/hw/ppc/spapr.h |  3 ++-
 vl.c   | 16 +++-
 6 files changed, 65 insertions(+), 2 deletions(-)

-- 
2.20.1




Re: [Qemu-devel] [RFC PATCH qemu] spapr: Stop providing RTAS blob

2019-07-21 Thread Alexey Kardashevskiy




On 16/07/2019 15:35, Alexey Kardashevskiy wrote:

SLOF implements one itself so let's remove it from QEMU. It is one less
image and simpler setup as the RTAS blob never stays in its initial place
anyway as the guest OS always decides where to put it.

This totally depends on https://patchwork.ozlabs.org/patch/1132440/ ,
hence RFC.

Signed-off-by: Alexey Kardashevskiy 
---
  configure   |   6 +
  Makefile|   2 +-
  pc-bios/spapr-rtas/Makefile |  27 -
  include/hw/ppc/spapr.h  |   2 --
  hw/ppc/spapr.c  |  32 ++---
  hw/ppc/spapr_rtas.c |  41 
  MAINTAINERS |   2 --
  pc-bios/spapr-rtas.bin  | Bin 20 -> 0 bytes
  pc-bios/spapr-rtas/spapr-rtas.S |  37 
  9 files changed, 4 insertions(+), 145 deletions(-)
  delete mode 100644 pc-bios/spapr-rtas/Makefile
  delete mode 100644 pc-bios/spapr-rtas.bin
  delete mode 100644 pc-bios/spapr-rtas/spapr-rtas.S

diff --git a/configure b/configure
index 4983c8b53300..a132d2eb5666 100755
--- a/configure
+++ b/configure
@@ -6205,9 +6205,6 @@ if { test "$cpu" = "i386" || test "$cpu" = "x86_64"; } && 
\
  fi
  done
  fi
-if test "$ARCH" = "ppc64" && test "$targetos" != "Darwin" ; then
-  roms="$roms spapr-rtas"
-fi
  
  # Only build s390-ccw bios if we're on s390x and the compiler has -march=z900

  if test "$cpu" = "s390x" ; then
@@ -7919,14 +7916,13 @@ fi
  DIRS="tests tests/tcg tests/tcg/cris tests/tcg/lm32 tests/libqos tests/qapi-schema 
tests/tcg/xtensa tests/qemu-iotests tests/vm"
  DIRS="$DIRS tests/fp tests/qgraph"
  DIRS="$DIRS docs docs/interop fsdev scsi"
-DIRS="$DIRS pc-bios/optionrom pc-bios/spapr-rtas pc-bios/s390-ccw"
+DIRS="$DIRS pc-bios/optionrom pc-bios/s390-ccw"
  DIRS="$DIRS roms/seabios roms/vgabios"
  LINKS="Makefile tests/tcg/Makefile"
  LINKS="$LINKS tests/tcg/cris/Makefile tests/tcg/cris/.gdbinit"
  LINKS="$LINKS tests/tcg/lm32/Makefile tests/tcg/xtensa/Makefile po/Makefile"
  LINKS="$LINKS tests/fp/Makefile"
  LINKS="$LINKS pc-bios/optionrom/Makefile pc-bios/keymaps"
-LINKS="$LINKS pc-bios/spapr-rtas/Makefile"
  LINKS="$LINKS pc-bios/s390-ccw/Makefile"
  LINKS="$LINKS roms/seabios/Makefile roms/vgabios/Makefile"
  LINKS="$LINKS pc-bios/qemu-icon.bmp"
diff --git a/Makefile b/Makefile
index 1fcbaed62c76..d780f4eebceb 100644
--- a/Makefile
+++ b/Makefile
@@ -764,7 +764,7 @@ efi-e1000e.rom efi-vmxnet3.rom \
  bamboo.dtb canyonlands.dtb petalogix-s3adsp1800.dtb petalogix-ml605.dtb \
  multiboot.bin linuxboot.bin linuxboot_dma.bin kvmvapic.bin pvh.bin \
  s390-ccw.img s390-netboot.img \
-spapr-rtas.bin slof.bin skiboot.lid \
+slof.bin skiboot.lid \
  palcode-clipper \
  u-boot.e500 u-boot-sam460-20100605.bin \
  qemu_vga.ndrv \
diff --git a/pc-bios/spapr-rtas/Makefile b/pc-bios/spapr-rtas/Makefile
deleted file mode 100644
index 4b9bb1230658..
--- a/pc-bios/spapr-rtas/Makefile
+++ /dev/null
@@ -1,27 +0,0 @@
-all: build-all
-# Dummy command so that make thinks it has done something
-   @true
-
-include ../../config-host.mak
-include $(SRC_PATH)/rules.mak
-
-$(call set-vpath, $(SRC_PATH)/pc-bios/spapr-rtas)
-
-.PHONY : all clean build-all
-
-#CFLAGS += -I$(SRC_PATH)
-#QEMU_CFLAGS = $(CFLAGS)
-
-build-all: spapr-rtas.bin
-
-%.o: %.S
-   $(call quiet-command,$(CCAS) -mbig -c -o $@ $<,"CCAS","$(TARGET_DIR)$@")
-
-%.img: %.o
-   $(call quiet-command,$(CC) -nostdlib -mbig -o $@ 
$<,"Building","$(TARGET_DIR)$@")
-
-%.bin: %.img
-   $(call quiet-command,$(OBJCOPY) -O binary -j .text $< 
$@,"Building","$(TARGET_DIR)$@")
-
-clean:
-   rm -f *.o *.d *.img *.bin *~
diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h
index 60553d32c4fa..b6640370c839 100644
--- a/include/hw/ppc/spapr.h
+++ b/include/hw/ppc/spapr.h
@@ -152,8 +152,6 @@ struct SpaprMachineState {
  
  hwaddr rma_size;

  int vrma_adjust;
-ssize_t rtas_size;
-void *rtas_blob;
  uint32_t fdt_size;
  uint32_t fdt_initial_size;
  void *fdt_blob;
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 8783b433960c..36cd45bd78b3 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -89,7 +89,6 @@
   * We load our kernel at 4M, leaving space for SLOF initial image
   */
  #define FDT_MAX_SIZE0x10
-#define RTAS_MAX_SIZE   0x1
  #define RTAS_MAX_ADDR   0x8000 /* RTAS must stay below that */
  #define FW_MAX_SIZE 0x40
  #define FW_FILE_NAME"slof.bin"
@@ -1704,8 +1703,7 @@ static void spapr_machine_reset(MachineState *machine)
  {
  SpaprMachineState *spapr = SPAPR_MACHINE(machine);
  PowerPCCPU *first_ppc_cpu;
-uint32_t rtas_limit;
-hwaddr rtas_addr, fdt_addr;
+hwaddr fdt_addr;
  void *fdt;
  int rc;
  
@@ -1783,14 +1781,10 @@ static void spapr_machine_reset(MachineState *machine)

   * or just below 2GB, whichever is lower, so that 

[Qemu-devel] [Bug 1837347] [NEW] core dump after raspi2 kernel boot

2019-07-21 Thread Aditya Govardhan
Public bug reported:

Host info:
==
x86-64, Ubuntu 18.04, QEMU 4.0.0 (downloaded tarball from main site)

Guest info:
===
ARM7l, Raspbian OS off the main raspberry pi site

QEMU command:
=
qemu-system-arm -M raspi2 -kernel bootpart/kernel7.img -dtb 
bootpart/bcm2709-rpi-2-b.dtb -drive 
file=2019-07-10-raspbian-buster.img,format=raw,if=sd -append "rw earlyprintk 
console=ttyAMA0,115200 fsck.repair=yes rootwait memtest=1 loglevel=8 
dwc_otg.lpm_enable=0 root=/dev/mmcblk0p2" -serial stdio

kernel7.img and bcm2709-rpi-2-b.dtb were obtained by the following
commands:

guestfish --ro -a 2019-07-10-raspbian-buster.img -m /dev/sda1
> copy-out / bootpart/
> quit

Output:
===

https://pastebin.com/fL1eXhV0

References:
===
https://translatedcode.wordpress.com/2016/11/03/installing-debian-on-qemus-32-bit-arm-virt-board/
https://translatedcode.wordpress.com/2018/04/25/debian-on-qemus-raspberry-pi-3-model/


The core dump error can occur at both times, before logging in and after 
logging in, in this case I have given the output after logging in to show the 
initial processes running.

Also please let me know if I using any kernel flags incorrectly

** Affects: qemu
 Importance: Undecided
 Status: New


** Tags: raspi2

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

Title:
  core dump after raspi2 kernel boot

Status in QEMU:
  New

Bug description:
  Host info:
  ==
  x86-64, Ubuntu 18.04, QEMU 4.0.0 (downloaded tarball from main site)

  Guest info:
  ===
  ARM7l, Raspbian OS off the main raspberry pi site

  QEMU command:
  =
  qemu-system-arm -M raspi2 -kernel bootpart/kernel7.img -dtb 
bootpart/bcm2709-rpi-2-b.dtb -drive 
file=2019-07-10-raspbian-buster.img,format=raw,if=sd -append "rw earlyprintk 
console=ttyAMA0,115200 fsck.repair=yes rootwait memtest=1 loglevel=8 
dwc_otg.lpm_enable=0 root=/dev/mmcblk0p2" -serial stdio

  kernel7.img and bcm2709-rpi-2-b.dtb were obtained by the following
  commands:

  guestfish --ro -a 2019-07-10-raspbian-buster.img -m /dev/sda1
  > copy-out / bootpart/
  > quit

  Output:
  ===

  https://pastebin.com/fL1eXhV0

  References:
  ===
  
https://translatedcode.wordpress.com/2016/11/03/installing-debian-on-qemus-32-bit-arm-virt-board/
  
https://translatedcode.wordpress.com/2018/04/25/debian-on-qemus-raspberry-pi-3-model/

  
  The core dump error can occur at both times, before logging in and after 
logging in, in this case I have given the output after logging in to show the 
initial processes running.

  Also please let me know if I using any kernel flags incorrectly

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



[Qemu-devel] [Bug 1829964] Re: HOST VRAM Leak when performs android-x86 window rotation with Virt-GPU

2019-07-21 Thread Launchpad Bug Tracker
[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

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

Title:
  HOST VRAM Leak when performs android-x86 window rotation with Virt-GPU

Status in QEMU:
  Expired

Bug description:
  I will report something strange thing about host VRAM leakage after
  anroid-x86 window rotation when it runs with virt-gpu(+ virgl-
  renderer)

  Please watching below video link.

  https://www.youtube.com/watch?v=mJIbGZLWF1s=youtu.be

  (orginal video file : https://drive.google.com/file/d
  /1lkdTx_8yTbSVjKXlnxnnk96fWe-w6Mxb/view?usp=sharing)

  I don't sure what is the problem...

  Here are my tested history
  
--
  Install android-x86 on I7 desktop PCs with intel UHD GPU  - No leak.
  Install android-x86 on I7 desktop PCs with NVIDIA GTX GPU series - No leak.
  Install android-x86 on guest machine emulated skylake cpu with 
QEMU(+virt-gpu, virgl-renderer) - Leak
  (HOST CPU - I5, INTEL UHD GPU)
  Install android-x86 on guest machine emulated skylake cpu with 
QEMU(+virt-gpu, virgl-renderer) - Leak
  (HOST CPU - I7, NVIDIA GTX GPU)

  COMMON:
  In case of NVIDIA GPU : check vram using nvidia-smi
  In case of intel UHD GPU : check shared-vram using free cmd

  We checked guest android-x86 system down when vram is full after performing 
many rotation
  
---

  Is it virt-gpu driver's problem?

  I hope someone can help me...

  Thanks in advance!!


  PS


  Here are qemu options I used...

  -machine type=q35,accel=kvm -cpu host --enable-kvm \
  -smp cpus=4,cores=4,threads=1 -m 4096 \
  -drive file=ctb0319.qcow2,format=qcow2,if=virtio,aio=threads \
  -device virtio-vga,virgl=on \
  -device qemu-xhci,id=xhci -device usb-mouse,bus=xhci.0 -device 
usb-kbd,bus=xhci.0 \
  -soundhw hda -display sdl,gl=on -netdev 
user,id=qemunet0,hostfwd=tcp::4000-:7000,hostfwd=tcp::-:,hostfwd=tcp::4012-:7012,hostfwd=tcp::4013-:7013
 -device virtio-net,netdev=qemunet0 -boot menu=on

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



[Qemu-devel] [PATCH] i386/kvm: Do not sync nested state during runtime

2019-07-21 Thread Jan Kiszka
Writing the nested state e.g. after a vmport access can invalidate
important parts of the kernel-internal state, and it is not needed as
well. So leave this out from KVM_PUT_RUNTIME_STATE.

Suggested-by: Paolo Bonzini 
Signed-off-by: Jan Kiszka 
---
 target/i386/kvm.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/target/i386/kvm.c b/target/i386/kvm.c
index ec7870c6af..da98b2cbca 100644
--- a/target/i386/kvm.c
+++ b/target/i386/kvm.c
@@ -3577,12 +3577,12 @@ int kvm_arch_put_registers(CPUState *cpu, int level)
 
 assert(cpu_is_stopped(cpu) || qemu_cpu_is_self(cpu));
 
-ret = kvm_put_nested_state(x86_cpu);
-if (ret < 0) {
-return ret;
-}
-
 if (level >= KVM_PUT_RESET_STATE) {
+ret = kvm_put_nested_state(x86_cpu);
+if (ret < 0) {
+return ret;
+}
+
 ret = kvm_put_msr_feature_control(x86_cpu);
 if (ret < 0) {
 return ret;
-- 
2.16.4



[Qemu-devel] [PATCH v2 2/2] configure: Cosmetic yes to "yes" for consistency

2019-07-21 Thread tony.nguyen
Signed-off-by: Tony Nguyen 
---
 configure | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure b/configure
index 8316a16..c07687c 100755
--- a/configure
+++ b/configure
@@ -7433,7 +7433,7 @@ esac
 target_bigendian="no"
 case "$target_name" in
   
armeb|aarch64_be|hppa|lm32|m68k|microblaze|mips|mipsn32|mips64|moxie|or1k|ppc|ppc64|ppc64abi32|s390x|sh4eb|sparc|sparc64|sparc32plus|xtensaeb)
-  target_bigendian=yes
+  target_bigendian="yes"
   ;;
 esac
 target_softmmu="no"
-- 
1.8.3.1



[Qemu-devel] [PATCH v2 1/2] configure: Define target access alignment in configure

2019-07-21 Thread tony.nguyen
Move the define of target access alignment earlier from
target/foo/cpu.h to configure.

Signed-off-by: Tony Nguyen 
---
 configure | 10 +-
 include/exec/poison.h |  1 +
 include/qom/cpu.h |  2 +-
 target/alpha/cpu.h|  2 --
 target/hppa/cpu.h |  1 -
 target/mips/cpu.h |  2 --
 target/sh4/cpu.h  |  2 --
 target/sparc/cpu.h|  2 --
 target/xtensa/cpu.h   |  2 --
 tcg/tcg.c |  2 +-
 tcg/tcg.h |  8 +---
 11 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/configure b/configure
index eb635c3..8316a16 100755
--- a/configure
+++ b/configure
@@ -7424,8 +7424,13 @@ for target in $target_list; do
 target_dir="$target"
 config_target_mak=$target_dir/config-target.mak
 target_name=$(echo $target | cut -d '-' -f 1)
+target_aligned_only="no"
+case "$target_name" in
+  
alpha|hppa|mips64el|mips64|mipsel|mips|mipsn32|mipsn32el|sh4|sh4eb|sparc|sparc64|sparc32plus|xtensa|xtensaeb)
+  target_aligned_only="yes"
+  ;;
+esac
 target_bigendian="no"
-
 case "$target_name" in
   
armeb|aarch64_be|hppa|lm32|m68k|microblaze|mips|mipsn32|mips64|moxie|or1k|ppc|ppc64|ppc64abi32|s390x|sh4eb|sparc|sparc64|sparc32plus|xtensaeb)
   target_bigendian=yes
@@ -7710,6 +7715,9 @@ fi
 if supported_whpx_target $target; then
 echo "CONFIG_WHPX=y" >> $config_target_mak
 fi
+if test "$target_aligned_only" = "yes" ; then
+  echo "TARGET_ALIGNED_ONLY=y" >> $config_target_mak
+fi
 if test "$target_bigendian" = "yes" ; then
   echo "TARGET_WORDS_BIGENDIAN=y" >> $config_target_mak
 fi
diff --git a/include/exec/poison.h b/include/exec/poison.h
index b862320..955eb86 100644
--- a/include/exec/poison.h
+++ b/include/exec/poison.h
@@ -35,6 +35,7 @@
 #pragma GCC poison TARGET_UNICORE32
 #pragma GCC poison TARGET_XTENSA
 
+#pragma GCC poison TARGET_ALIGNED_ONLY
 #pragma GCC poison TARGET_HAS_BFLT
 #pragma GCC poison TARGET_NAME
 #pragma GCC poison TARGET_SUPPORTS_MTTCG
diff --git a/include/qom/cpu.h b/include/qom/cpu.h
index 5ee0046..9b50b73 100644
--- a/include/qom/cpu.h
+++ b/include/qom/cpu.h
@@ -89,7 +89,7 @@ struct TranslationBlock;
  * @do_unassigned_access: Callback for unassigned access handling.
  * (this is deprecated: new targets should use do_transaction_failed instead)
  * @do_unaligned_access: Callback for unaligned access handling, if
- * the target defines #ALIGNED_ONLY.
+ * the target defines #TARGET_ALIGNED_ONLY.
  * @do_transaction_failed: Callback for handling failed memory transactions
  * (ie bus faults or external aborts; not MMU faults)
  * @virtio_is_big_endian: Callback to return %true if a CPU which supports
diff --git a/target/alpha/cpu.h b/target/alpha/cpu.h
index b3e8a82..16eb804 100644
--- a/target/alpha/cpu.h
+++ b/target/alpha/cpu.h
@@ -23,8 +23,6 @@
 #include "cpu-qom.h"
 #include "exec/cpu-defs.h"
 
-#define ALIGNED_ONLY
-
 /* Alpha processors have a weak memory model */
 #define TCG_GUEST_DEFAULT_MO  (0)
 
diff --git a/target/hppa/cpu.h b/target/hppa/cpu.h
index aab251b..2be67c2 100644
--- a/target/hppa/cpu.h
+++ b/target/hppa/cpu.h
@@ -30,7 +30,6 @@
basis.  It's probably easier to fall back to a strong memory model.  */
 #define TCG_GUEST_DEFAULT_MOTCG_MO_ALL
 
-#define ALIGNED_ONLY
 #define MMU_KERNEL_IDX   0
 #define MMU_USER_IDX 3
 #define MMU_PHYS_IDX 4
diff --git a/target/mips/cpu.h b/target/mips/cpu.h
index 21c0615..c13cd4e 100644
--- a/target/mips/cpu.h
+++ b/target/mips/cpu.h
@@ -1,8 +1,6 @@
 #ifndef MIPS_CPU_H
 #define MIPS_CPU_H
 
-#define ALIGNED_ONLY
-
 #include "cpu-qom.h"
 #include "exec/cpu-defs.h"
 #include "fpu/softfloat.h"
diff --git a/target/sh4/cpu.h b/target/sh4/cpu.h
index aee733e..ecaa7a1 100644
--- a/target/sh4/cpu.h
+++ b/target/sh4/cpu.h
@@ -23,8 +23,6 @@
 #include "cpu-qom.h"
 #include "exec/cpu-defs.h"
 
-#define ALIGNED_ONLY
-
 /* CPU Subtypes */
 #define SH_CPU_SH7750  (1 << 0)
 #define SH_CPU_SH7750S (1 << 1)
diff --git a/target/sparc/cpu.h b/target/sparc/cpu.h
index 8ed2250..1406f0b 100644
--- a/target/sparc/cpu.h
+++ b/target/sparc/cpu.h
@@ -5,8 +5,6 @@
 #include "cpu-qom.h"
 #include "exec/cpu-defs.h"
 
-#define ALIGNED_ONLY
-
 #if !defined(TARGET_SPARC64)
 #define TARGET_DPREGS 16
 #else
diff --git a/target/xtensa/cpu.h b/target/xtensa/cpu.h
index 2c27713..0459243 100644
--- a/target/xtensa/cpu.h
+++ b/target/xtensa/cpu.h
@@ -32,8 +32,6 @@
 #include "exec/cpu-defs.h"
 #include "xtensa-isa.h"
 
-#define ALIGNED_ONLY
-
 /* Xtensa processors have a weak memory model */
 #define TCG_GUEST_DEFAULT_MO  (0)
 
diff --git a/tcg/tcg.c b/tcg/tcg.c
index be2c33c..8d23fb0 100644
--- a/tcg/tcg.c
+++ b/tcg/tcg.c
@@ -1926,7 +1926,7 @@ static const char * const ldst_name[] =
 };
 
 static const char * const alignment_name[(MO_AMASK >> MO_ASHIFT) + 1] = {
-#ifdef ALIGNED_ONLY
+#ifdef TARGET_ALIGNED_ONLY
 [MO_UNALN >> MO_ASHIFT]= "un+",
 [MO_ALIGN >> MO_ASHIFT]= "",
 #else
diff --git a/tcg/tcg.h b/tcg/tcg.h
index b411e17..529acb2 100644
--- a/tcg/tcg.h
+++ b/tcg/tcg.h
@@ -333,10 

Re: [Qemu-devel] [PATCH v7 10/13] vfio: Add load state functions to SaveVMHandlers

2019-07-21 Thread Yan Zhao
On Fri, Jul 19, 2019 at 03:00:13AM +0800, Kirti Wankhede wrote:
> 
> 
> On 7/12/2019 8:22 AM, Yan Zhao wrote:
> > On Tue, Jul 09, 2019 at 05:49:17PM +0800, Kirti Wankhede wrote:
> >> Flow during _RESUMING device state:
> >> - If Vendor driver defines mappable region, mmap migration region.
> >> - Load config state.
> >> - For data packet, till VFIO_MIG_FLAG_END_OF_STATE is not reached
> >> - read data_size from packet, read buffer of data_size
> >> - read data_offset from where QEMU should write data.
> >> if region is mmaped, write data of data_size to mmaped region.
> >> - write data_size.
> >> In case of mmapped region, write to data_size indicates kernel
> >> driver that data is written in staging buffer.
> >> - if region is trapped, pwrite() data of data_size from data_offset.
> >> - Repeat above until VFIO_MIG_FLAG_END_OF_STATE.
> >> - Unmap migration region.
> >>
> >> For user, data is opaque. User should write data in the same order as
> >> received.
> >>
> >> Signed-off-by: Kirti Wankhede 
> >> Reviewed-by: Neo Jia 
> >> ---
> >>  hw/vfio/migration.c  | 162 
> >> +++
> >>  hw/vfio/trace-events |   3 +
> >>  2 files changed, 165 insertions(+)
> >>
> >> diff --git a/hw/vfio/migration.c b/hw/vfio/migration.c
> >> index 4e9b4cce230b..5fb4c5329ede 100644
> >> --- a/hw/vfio/migration.c
> >> +++ b/hw/vfio/migration.c
> >> @@ -249,6 +249,26 @@ static int vfio_save_device_config_state(QEMUFile *f, 
> >> void *opaque)
> >>  return qemu_file_get_error(f);
> >>  }
> >>  
> >> +static int vfio_load_device_config_state(QEMUFile *f, void *opaque)
> >> +{
> >> +VFIODevice *vbasedev = opaque;
> >> +uint64_t data;
> >> +
> >> +if (vbasedev->ops && vbasedev->ops->vfio_load_config) {
> >> +vbasedev->ops->vfio_load_config(vbasedev, f);
> >> +}
> >> +
> >> +data = qemu_get_be64(f);
> >> +if (data != VFIO_MIG_FLAG_END_OF_STATE) {
> >> +error_report("%s: Failed loading device config space, "
> >> + "end flag incorrect 0x%"PRIx64, vbasedev->name, 
> >> data);
> >> +return -EINVAL;
> >> +}
> >> +
> >> +trace_vfio_load_device_config_state(vbasedev->name);
> >> +return qemu_file_get_error(f);
> >> +}
> >> +
> >>  /* -- 
> >> */
> >>  
> >>  static int vfio_save_setup(QEMUFile *f, void *opaque)
> >> @@ -421,12 +441,154 @@ static int vfio_save_complete_precopy(QEMUFile *f, 
> >> void *opaque)
> >>  return ret;
> >>  }
> >>  
> >> +static int vfio_load_setup(QEMUFile *f, void *opaque)
> >> +{
> >> +VFIODevice *vbasedev = opaque;
> >> +VFIOMigration *migration = vbasedev->migration;
> >> +int ret = 0;
> >> +
> >> +if (migration->region.buffer.mmaps) {
> >> +ret = vfio_region_mmap(>region.buffer);
> >> +if (ret) {
> >> +error_report("%s: Failed to mmap VFIO migration region %d: 
> >> %s",
> >> + vbasedev->name, migration->region.index,
> >> + strerror(-ret));
> >> +return ret;
> >> +}
> >> +}
> >> +
> >> +ret = vfio_migration_set_state(vbasedev, VFIO_DEVICE_STATE_RESUMING);
> >> +if (ret) {
> >> +error_report("%s: Failed to set state RESUMING", vbasedev->name);
> >> +}
> >> +return ret;
> >> +}
> >> +
> >> +static int vfio_load_cleanup(void *opaque)
> >> +{
> >> +vfio_save_cleanup(opaque);
> >> +return 0;
> >> +}
> >> +
> >> +static int vfio_load_state(QEMUFile *f, void *opaque, int version_id)
> >> +{
> >> +VFIODevice *vbasedev = opaque;
> >> +VFIOMigration *migration = vbasedev->migration;
> >> +int ret = 0;
> >> +uint64_t data, data_size;
> >> +
> > I think checking of version_id is still needed.
> > 
> 
> Checking version_id with what value?
>
this version_id passed-in is the source VFIO software interface id.
need to check it with the value in target side, right?

Though we previously discussed the sysfs node interface to check live
migration version even before launching live migration, I think we still
need this runtime software version check in qemu to ensure software
interfaces in QEMU VFIO are compatible.

Thanks
Yan



[Qemu-devel] [PATCH v2 0/2] configure: Define target access alignment in configure

2019-07-21 Thread tony.nguyen
Move the define of target access alignment earlier from
target/foo/cpu.h to configure.

Suggested in Richard Henderson's reply to "[PATCH 1/4] tcg: TCGMemOp
is now accelerator independent MemOp"

Analysed target/foo/cpu.h for more candidates to define earlier but 

did not spot any other straight forward predicates.

Possible future clean ups:
- TCG_GUEST_DEFAULT_MO and TCG_TARGET_DEFAULT_MO seems like duplicates
- TARGET_INSN_START_EXTRA_WORDS 1 seems redundant as ifndef value is 1

v2:
- split cosmetic changes into separate patch
- cc corresponding maintainers

Thanks to Aleksandar Markovic for the guide in v1 =)

Tony Nguyen (2):
  configure: Define TARGET_ALIGNED_ONLY earlier
  configure: Cosmetic yes to "yes" for consistency

 configure | 12 ++--
 include/exec/poison.h |  1 +
 include/qom/cpu.h |  2 +-
 target/alpha/cpu.h|  2 --
 target/hppa/cpu.h |  1 -
 target/mips/cpu.h |  2 --
 target/sh4/cpu.h  |  2 --
 target/sparc/cpu.h|  2 --
 target/xtensa/cpu.h   |  2 --
 tcg/tcg.c |  2 +-
 tcg/tcg.h |  8 +---
 11 files changed, 18 insertions(+), 18 deletions(-)

-- 
1.8.3.1


Re: [Qemu-devel] [PATCH v1 1/3] virtio-balloon: simplify deflate with pbp

2019-07-21 Thread David Gibson
On Fri, Jul 19, 2019 at 06:01:18PM +0200, David Hildenbrand wrote:
> Let's simplify this - the case we are optimizing for is very hard to
> trigger and not worth the effort. If we're switching from inflation to
> deflation, let's reset the pbp.
> 
> Signed-off-by: David Hildenbrand 

Acked-by: David Gibson 

> ---
>  hw/virtio/virtio-balloon.c | 24 
>  1 file changed, 4 insertions(+), 20 deletions(-)
> 
> diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c
> index 9de3c030bf..287d5d4c97 100644
> --- a/hw/virtio/virtio-balloon.c
> +++ b/hw/virtio/virtio-balloon.c
> @@ -121,7 +121,7 @@ static void balloon_deflate_page(VirtIOBalloon *balloon,
>  void *addr = memory_region_get_ram_ptr(mr) + offset;
>  RAMBlock *rb;
>  size_t rb_page_size;
> -ram_addr_t ram_offset, host_page_base;
> +ram_addr_t ram_offset;
>  void *host_addr;
>  int ret;
>  
> @@ -129,26 +129,10 @@ static void balloon_deflate_page(VirtIOBalloon *balloon,
>   * host address? */
>  rb = qemu_ram_block_from_host(addr, false, _offset);
>  rb_page_size = qemu_ram_pagesize(rb);
> -host_page_base = ram_offset & ~(rb_page_size - 1);
> -
> -if (balloon->pbp
> -&& rb == balloon->pbp->rb
> -&& host_page_base == balloon->pbp->base) {
> -int subpages = rb_page_size / BALLOON_PAGE_SIZE;
>  
> -/*
> - * This means the guest has asked to discard some of the 4kiB
> - * subpages of a host page, but then changed its mind and
> - * asked to keep them after all.  It's exceedingly unlikely
> - * for a guest to do this in practice, but handle it anyway,
> - * since getting it wrong could mean discarding memory the
> - * guest is still using. */
> -clear_bit((ram_offset - balloon->pbp->base) / BALLOON_PAGE_SIZE,
> -  balloon->pbp->bitmap);
> -
> -if (bitmap_empty(balloon->pbp->bitmap, subpages)) {
> -virtio_balloon_reset_pbp(balloon);
> -}
> +if (balloon->pbp) {
> +/* Let's play safe and always reset the pbp on deflation requests. */
> +virtio_balloon_reset_pbp(balloon);
>  }
>  
>  host_addr = (void *)((uintptr_t)addr & ~(rb_page_size - 1));

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature


Re: [Qemu-devel] [PATCH v1 3/3] virtio-balloon: Rework pbp tracking data

2019-07-21 Thread David Gibson
On Fri, Jul 19, 2019 at 06:01:20PM +0200, David Hildenbrand wrote:
> Using the address of a RAMBlock to test for a matching pbp is not really
> safe. Instead, let's use the guest physical address of the base page
> along with the page size (via the number of subpages).
> 
> While at it, move "struct PartiallyBalloonedPage" to virtio-balloon.h
> now (previously most probably avoided to te the ramblock), renaming it.
> 
> Also, let's only dynamically allocating the bitmap. This makes the code
> easier to read and maintain - we can reuse bitmap_new().
> 
> Signed-off-by: David Hildenbrand 

This mostly looks good, but one thing bothers me..

> ---
>  hw/virtio/virtio-balloon.c | 52 +-
>  include/hw/virtio/virtio-balloon.h | 15 +++--
>  2 files changed, 42 insertions(+), 25 deletions(-)
> 
> diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c
> index 29cee344b2..8e5f9459c2 100644
> --- a/hw/virtio/virtio-balloon.c
> +++ b/hw/virtio/virtio-balloon.c
> @@ -34,23 +34,31 @@
>  
>  #define BALLOON_PAGE_SIZE  (1 << VIRTIO_BALLOON_PFN_SHIFT)
>  
> -struct PartiallyBalloonedPage {
> -RAMBlock *rb;
> -ram_addr_t base;
> -unsigned long bitmap[];
> -};
> -
>  static void virtio_balloon_reset_pbp(VirtIOBalloon *balloon)
>  {
> -g_free(balloon->pbp);
> -balloon->pbp = NULL;
> +balloon->pbp.base_gpa = 0;
> +balloon->pbp.subpages = 0;
> +g_free(balloon->pbp.bitmap);
> +balloon->pbp.bitmap = NULL;
> +}
> +
> +static bool virtio_balloon_pbp_valid(VirtIOBalloon *balloon)
> +{
> +return balloon->pbp.bitmap;
> +}
> +
> +static bool virtio_balloon_pbp_matches(VirtIOBalloon *balloon,
> +   ram_addr_t base_gpa, long subpages)
> +{
> +return balloon->pbp.subpages == subpages &&
> +   balloon->pbp.base_gpa == base_gpa;

.. so, I'm trying to think what base_gpa matching, but subpages not
matching means.  I think that can only happen if a pbp is created,
then the ramblock it was in is unplugged, then another ramblock is
plugged in covering the same address and with a different (host) page
size.  Which is unlikely but possible, IIUC.  However, also possible
and marginally less unlikely is to plug a new block of the same page
size, in which case this *will* match, but presumably the pbp should
still be discarded.

>  }
>  
>  static void balloon_inflate_page(VirtIOBalloon *balloon,
>   MemoryRegion *mr, hwaddr mr_offset)
>  {
>  void *addr = memory_region_get_ram_ptr(mr) + mr_offset;
> -ram_addr_t rb_offset, rb_aligned_offset;
> +ram_addr_t rb_offset, rb_aligned_offset, base_gpa;
>  RAMBlock *rb;
>  size_t rb_page_size;
>  int subpages;
> @@ -81,32 +89,32 @@ static void balloon_inflate_page(VirtIOBalloon *balloon,
>  
>  rb_aligned_offset = QEMU_ALIGN_DOWN(rb_offset, rb_page_size);
>  subpages = rb_page_size / BALLOON_PAGE_SIZE;
> +base_gpa = memory_region_get_ram_addr(mr) + mr_offset -
> +   (rb_offset - rb_aligned_offset);
>  
> -if (balloon->pbp
> -&& (rb != balloon->pbp->rb
> -|| rb_aligned_offset != balloon->pbp->base)) {
> +if (virtio_balloon_pbp_valid(balloon) &&
> +!virtio_balloon_pbp_matches(balloon, base_gpa, subpages)) {
>  /* We've partially ballooned part of a host page, but now
>   * we're trying to balloon part of a different one.  Too hard,
>   * give up on the old partial page */
>  virtio_balloon_reset_pbp(balloon);
>  }
>  
> -if (!balloon->pbp) {
> +if (!virtio_balloon_pbp_valid(balloon)) {
>  /* Starting on a new host page */
> -size_t bitlen = BITS_TO_LONGS(subpages) * sizeof(unsigned long);
> -balloon->pbp = g_malloc0(sizeof(PartiallyBalloonedPage) + bitlen);
> -balloon->pbp->rb = rb;
> -balloon->pbp->base = rb_aligned_offset;
> +balloon->pbp.base_gpa = base_gpa;
> +balloon->pbp.subpages = subpages;
> +balloon->pbp.bitmap = bitmap_new(subpages);
>  }
>  
> -set_bit((rb_offset - balloon->pbp->base) / BALLOON_PAGE_SIZE,
> -balloon->pbp->bitmap);
> +set_bit((rb_offset - rb_aligned_offset) / BALLOON_PAGE_SIZE,
> +balloon->pbp.bitmap);
>  
> -if (bitmap_full(balloon->pbp->bitmap, subpages)) {
> +if (bitmap_full(balloon->pbp.bitmap, subpages)) {
>  /* We've accumulated a full host page, we can actually discard
>   * it now */
>  
> -ram_block_discard_range(rb, balloon->pbp->base, rb_page_size);
> +ram_block_discard_range(rb, rb_aligned_offset, rb_page_size);
>  /* We ignore errors from ram_block_discard_range(), because it
>   * has already reported them, and failing to discard a balloon
>   * page is not fatal */
> @@ -130,7 +138,7 @@ static void balloon_deflate_page(VirtIOBalloon *balloon,
>  rb = qemu_ram_block_from_host(addr, false, _offset);
>  

Re: [Qemu-devel] [PATCH v1 2/3] virtio-balloon: Better names for offset variables in inflate/deflate code

2019-07-21 Thread David Gibson
On Fri, Jul 19, 2019 at 06:01:19PM +0200, David Hildenbrand wrote:
> "host_page_base" is really confusing, let's make this clearer, also
> rename the other offsets to indicate to which base they apply.
> 
> offset -> mr_offset
> ram_offset -> rb_offset
> host_page_base -> rb_aligned_offset
> 
> While at it, use QEMU_ALIGN_DOWN() instead of a handcrafted computation
> and move the computation to the place where it is needed.
> 
> Signed-off-by: David Hildenbrand 

Acked-by: David Gibson 

> ---
>  hw/virtio/virtio-balloon.c | 26 +-
>  1 file changed, 13 insertions(+), 13 deletions(-)
> 
> diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c
> index 287d5d4c97..29cee344b2 100644
> --- a/hw/virtio/virtio-balloon.c
> +++ b/hw/virtio/virtio-balloon.c
> @@ -47,24 +47,23 @@ static void virtio_balloon_reset_pbp(VirtIOBalloon 
> *balloon)
>  }
>  
>  static void balloon_inflate_page(VirtIOBalloon *balloon,
> - MemoryRegion *mr, hwaddr offset)
> + MemoryRegion *mr, hwaddr mr_offset)
>  {
> -void *addr = memory_region_get_ram_ptr(mr) + offset;
> +void *addr = memory_region_get_ram_ptr(mr) + mr_offset;
> +ram_addr_t rb_offset, rb_aligned_offset;
>  RAMBlock *rb;
>  size_t rb_page_size;
>  int subpages;
> -ram_addr_t ram_offset, host_page_base;
>  
>  /* XXX is there a better way to get to the RAMBlock than via a
>   * host address? */
> -rb = qemu_ram_block_from_host(addr, false, _offset);
> +rb = qemu_ram_block_from_host(addr, false, _offset);
>  rb_page_size = qemu_ram_pagesize(rb);
> -host_page_base = ram_offset & ~(rb_page_size - 1);
>  
>  if (rb_page_size == BALLOON_PAGE_SIZE) {
>  /* Easy case */
>  
> -ram_block_discard_range(rb, ram_offset, rb_page_size);
> +ram_block_discard_range(rb, rb_offset, rb_page_size);
>  /* We ignore errors from ram_block_discard_range(), because it
>   * has already reported them, and failing to discard a balloon
>   * page is not fatal */
> @@ -80,11 +79,12 @@ static void balloon_inflate_page(VirtIOBalloon *balloon,
>  warn_report_once(
>  "Balloon used with backing page size > 4kiB, this may not be reliable");
>  
> +rb_aligned_offset = QEMU_ALIGN_DOWN(rb_offset, rb_page_size);
>  subpages = rb_page_size / BALLOON_PAGE_SIZE;
>  
>  if (balloon->pbp
>  && (rb != balloon->pbp->rb
> -|| host_page_base != balloon->pbp->base)) {
> +|| rb_aligned_offset != balloon->pbp->base)) {
>  /* We've partially ballooned part of a host page, but now
>   * we're trying to balloon part of a different one.  Too hard,
>   * give up on the old partial page */
> @@ -96,10 +96,10 @@ static void balloon_inflate_page(VirtIOBalloon *balloon,
>  size_t bitlen = BITS_TO_LONGS(subpages) * sizeof(unsigned long);
>  balloon->pbp = g_malloc0(sizeof(PartiallyBalloonedPage) + bitlen);
>  balloon->pbp->rb = rb;
> -balloon->pbp->base = host_page_base;
> +balloon->pbp->base = rb_aligned_offset;
>  }
>  
> -set_bit((ram_offset - balloon->pbp->base) / BALLOON_PAGE_SIZE,
> +set_bit((rb_offset - balloon->pbp->base) / BALLOON_PAGE_SIZE,
>  balloon->pbp->bitmap);
>  
>  if (bitmap_full(balloon->pbp->bitmap, subpages)) {
> @@ -116,18 +116,18 @@ static void balloon_inflate_page(VirtIOBalloon *balloon,
>  }
>  
>  static void balloon_deflate_page(VirtIOBalloon *balloon,
> - MemoryRegion *mr, hwaddr offset)
> + MemoryRegion *mr, hwaddr mr_offset)
>  {
> -void *addr = memory_region_get_ram_ptr(mr) + offset;
> +void *addr = memory_region_get_ram_ptr(mr) + mr_offset;
> +ram_addr_t rb_offset;
>  RAMBlock *rb;
>  size_t rb_page_size;
> -ram_addr_t ram_offset;
>  void *host_addr;
>  int ret;
>  
>  /* XXX is there a better way to get to the RAMBlock than via a
>   * host address? */
> -rb = qemu_ram_block_from_host(addr, false, _offset);
> +rb = qemu_ram_block_from_host(addr, false, _offset);
>  rb_page_size = qemu_ram_pagesize(rb);
>  
>  if (balloon->pbp) {

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature


Re: [Qemu-devel] [PATCH v1] x86: Intel AVX512_BF16 feature enabling

2019-07-21 Thread Jing Liu




On 7/19/2019 4:10 PM, Paolo Bonzini wrote:

On 19/07/19 09:20, Jing Liu wrote:

Then CPUID[7,0].EAX is set automatically to 0 or 1 depending on whether
BF16 is enabled or not.


Could I ask why don't we directly check BF16 enabling when
cpu_x86_cpuid(env, 7, 0, ...) during kvm_arch_init_vcpu ?


Because the code for setting CPUID is common for all accelerators (there
are five supported: KVM, HAX, HVF, TCG, WHPX).


What is the use of the two new properties? Are they used for users
setting parameters when boot up guest, and why we need users setting
func7 level?


For example to test guests with CPUID[7,0].EAX==1, even if the host does
not have BF16.


Thanks. :)




@@ -5075,6 +5101,10 @@ static void x86_cpu_expand_features(X86CPU *cpu,
Error **errp)
  x86_cpu_adjust_feat_level(cpu, FEAT_SVM);
  x86_cpu_adjust_feat_level(cpu, FEAT_XSAVE);

+   if ((env->features[FEAT_7_1_EAX] & CPUID_7_1_EAX_AVX512_BF16) &&
+    kvm_enabled()) {


No need to check KVM.  You could also do just
x86_cpu_adjust_feat_level(cpu, FEAT_7_1_EAX) and set
cpu->min_level_func7 in x86_cpu_adjust_feat_level with something like

 if (eax == 7) {
 x86_cpu_adjust_level(cpu, >cpu_min_level_func7,
  fi->cpuid.ecx);
 }



Got it. One question I'm wondering is, is it possible for users setting
an invalid property like level-func7=2? Do we need some protection?


@@ -5098,6 +5128,9 @@ static void x86_cpu_expand_features(X86CPU *cpu,
Error **errp)
  }

  /* Set cpuid_*level* based on cpuid_min_*level, if not explicitly
set */
+    if (env->cpuid_level_func7 == UINT32_MAX) {
+    env->cpuid_level_func7 = env->cpuid_min_level_func7;
+    }


Looks good.


  if (env->cpuid_level == UINT32_MAX) {
  env->cpuid_level = env->cpuid_min_level;
  }
@@ -5869,9 +5902,11 @@ static Property x86_cpu_properties[] = {
  DEFINE_PROP_BOOL("host-phys-bits", X86CPU, host_phys_bits, false),
  DEFINE_PROP_UINT8("host-phys-bits-limit", X86CPU,
host_phys_bits_limit, 0),
  DEFINE_PROP_BOOL("fill-mtrr-mask", X86CPU, fill_mtrr_mask, true),
+    DEFINE_PROP_UINT32("level-func7", X86CPU, env.cpuid_level_func7,
UINT32_MAX),


Looks good.


  DEFINE_PROP_UINT32("level", X86CPU, env.cpuid_level, UINT32_MAX),
  DEFINE_PROP_UINT32("xlevel", X86CPU, env.cpuid_xlevel, UINT32_MAX),
  DEFINE_PROP_UINT32("xlevel2", X86CPU, env.cpuid_xlevel2, UINT32_MAX),
+    DEFINE_PROP_UINT32("min-level-func7", X86CPU,
env.cpuid_min_level_func7, 0),


No need for this property, just like there is no min-level property.


Would remove it.

Thanks,
Jing





Re: [Qemu-devel] [PATCH v7 11/11] tests/bios-tables-test: add test cases for ACPI HMAT

2019-07-21 Thread Liu, Jingqi
> -Original Message-
> From: Xu, Tao3
> Sent: Tuesday, July 16, 2019 10:51 PM
> To: imamm...@redhat.com; ebl...@redhat.com; ehabk...@redhat.com
> Cc: Xu, Tao3 ; Liu, Jingqi ; 
> Williams, Dan J ;
> jonathan.came...@huawei.com; Du, Fan ; qemu-devel@nongnu.org
> Subject: [PATCH v7 11/11] tests/bios-tables-test: add test cases for ACPI HMAT
> 
> ACPI table HMAT has been introduced, QEMU now builds HMAT tables for 
> Heterogeneous Memory with boot option '-numa node'.
> 
> Add test cases on PC and Q35 machines with 2 numa nodes.
> Because HMAT is generated when system enable numa, the following tables need 
> to be added for this test:
>   tests/acpi-test-data/pc/*.acpihmat
>   tests/acpi-test-data/pc/HMAT.*
>   tests/acpi-test-data/q35/*.acpihmat
>   tests/acpi-test-data/q35/HMAT.*
> 
> Suggested-by: Igor Mammedov 
> Signed-off-by: Tao Xu 
Looks good for me.

Reviewed-by: Jingqi Liu 

Thanks
Jingqi Liu
> ---
> 
> No changes in v7.
> ---
>  tests/bios-tables-test.c | 43 
>  1 file changed, 43 insertions(+)
> 
> diff --git a/tests/bios-tables-test.c b/tests/bios-tables-test.c index 
> d863233fe9..27a17921f2 100644
> --- a/tests/bios-tables-test.c
> +++ b/tests/bios-tables-test.c
> @@ -860,6 +860,47 @@ static void test_acpi_piix4_tcg_dimm_pxm(void)
>  test_acpi_tcg_dimm_pxm(MACHINE_PC);
>  }
> 
> +static void test_acpi_tcg_acpi_hmat(const char *machine) {
> +test_data data;
> +
> +memset(, 0, sizeof(data));
> +data.machine = machine;
> +data.variant = ".acpihmat";
> +test_acpi_one(" -smp 2,sockets=2"
> +  " -m 128M,slots=2,maxmem=1G"
> +  " -object memory-backend-ram,size=64M,id=m0"
> +  " -object memory-backend-ram,size=64M,id=m1"
> +  " -numa node,nodeid=0,memdev=m0"
> +  " -numa node,nodeid=1,memdev=m1,initiator=0"
> +  " -numa cpu,node-id=0,socket-id=0"
> +  " -numa cpu,node-id=0,socket-id=1"
> +  " -numa hmat-lb,initiator=0,target=0,hierarchy=memory,"
> +  "data-type=access-latency,base-lat=10,latency=5"
> +  " -numa hmat-lb,initiator=0,target=0,hierarchy=memory,"
> +  "data-type=access-bandwidth,base-bw=20,bandwidth=5"
> +  " -numa hmat-lb,initiator=0,target=1,hierarchy=memory,"
> +  "data-type=access-latency,base-lat=10,latency=10"
> +  " -numa hmat-lb,initiator=0,target=1,hierarchy=memory,"
> +  "data-type=access-bandwidth,base-bw=20,bandwidth=10"
> +  " -numa hmat-cache,node-id=0,size=0x2,total=1,level=1"
> +  ",assoc=direct,policy=write-back,line=8"
> +  " -numa hmat-cache,node-id=1,size=0x2,total=1,level=1"
> +  ",assoc=direct,policy=write-back,line=8",
> +  );
> +free_test_data();
> +}
> +
> +static void test_acpi_q35_tcg_acpi_hmat(void) {
> +test_acpi_tcg_acpi_hmat(MACHINE_Q35);
> +}
> +
> +static void test_acpi_piix4_tcg_acpi_hmat(void)
> +{
> +test_acpi_tcg_acpi_hmat(MACHINE_PC);
> +}
> +
>  static void test_acpi_virt_tcg(void)
>  {
>  test_data data = {
> @@ -904,6 +945,8 @@ int main(int argc, char *argv[])
>  qtest_add_func("acpi/q35/numamem", test_acpi_q35_tcg_numamem);
>  qtest_add_func("acpi/piix4/dimmpxm", test_acpi_piix4_tcg_dimm_pxm);
>  qtest_add_func("acpi/q35/dimmpxm", test_acpi_q35_tcg_dimm_pxm);
> +qtest_add_func("acpi/piix4/acpihmat", test_acpi_piix4_tcg_acpi_hmat);
> +qtest_add_func("acpi/q35/acpihmat",
> + test_acpi_q35_tcg_acpi_hmat);
>  } else if (strcmp(arch, "aarch64") == 0) {
>  qtest_add_func("acpi/virt", test_acpi_virt_tcg);
>  }
> --
> 2.20.1




Re: [Qemu-devel] [PATCH v7 05/11] numa: Extend CLI to provide initiator information for numa nodes

2019-07-21 Thread Liu, Jingqi
> -Original Message-
> From: Xu, Tao3
> Sent: Tuesday, July 16, 2019 10:51 PM
> To: imamm...@redhat.com; ebl...@redhat.com; ehabk...@redhat.com
> Cc: Xu, Tao3 ; Liu, Jingqi ; 
> Williams, Dan J ;
> jonathan.came...@huawei.com; Du, Fan ; qemu-devel@nongnu.org
> Subject: [PATCH v7 05/11] numa: Extend CLI to provide initiator information 
> for numa nodes
> 
> In ACPI 6.3 chapter 5.2.27 Heterogeneous Memory Attribute Table (HMAT), The 
> initiator represents processor which access to memory. And
> in 5.2.27.3 Memory Proximity Domain Attributes Structure, the attached 
> initiator is defined as where the memory controller responsible for
> a memory proximity domain. With attached initiator information, the topology 
> of heterogeneous memory can be described.
> 
> Extend CLI of "-numa node" option to indicate the initiator numa node-id.
> In the linux kernel, the codes in drivers/acpi/hmat/hmat.c parse and report 
> the platform's HMAT tables.
> 
> Suggested-by: Dan Williams 
> Signed-off-by: Tao Xu 
Looks good for me.

Reviewed-by: Jingqi Liu 

Thanks
Jingqi Liu
> ---
> 
> No changes in v7.
> 
> Changes in v6:
> - Add the version designator (since 4.2) after @initiator (Eric)
> ---
>  hw/core/machine.c | 24 
>  hw/core/numa.c| 13 +
>  include/sysemu/numa.h |  3 +++
>  qapi/machine.json |  6 +-
>  qemu-options.hx   | 27 +++
>  5 files changed, 68 insertions(+), 5 deletions(-)
> 
> diff --git a/hw/core/machine.c b/hw/core/machine.c index 
> 4228bcd2a2..063cb7923c 100644
> --- a/hw/core/machine.c
> +++ b/hw/core/machine.c
> @@ -653,6 +653,7 @@ void machine_set_cpu_numa_node(MachineState *machine,
> const CpuInstanceProperties *props, Error 
> **errp)  {
>  MachineClass *mc = MACHINE_GET_CLASS(machine);
> +NodeInfo *numa_info = machine->numa_state->nodes;
>  bool match = false;
>  int i;
> 
> @@ -722,6 +723,16 @@ void machine_set_cpu_numa_node(MachineState *machine,
>  match = true;
>  slot->props.node_id = props->node_id;
>  slot->props.has_node_id = props->has_node_id;
> +
> +if (numa_info[props->node_id].initiator_valid &&
> +(props->node_id != numa_info[props->node_id].initiator)) {
> +error_setg(errp, "The initiator of CPU NUMA node %" PRId64
> +   " should be itself.", props->node_id);
> +return;
> +}
> +numa_info[props->node_id].initiator_valid = true;
> +numa_info[props->node_id].has_cpu = true;
> +numa_info[props->node_id].initiator = props->node_id;
>  }
> 
>  if (!match) {
> @@ -1063,6 +1074,7 @@ static void machine_numa_finish_cpu_init(MachineState 
> *machine)
>  GString *s = g_string_new(NULL);
>  MachineClass *mc = MACHINE_GET_CLASS(machine);
>  const CPUArchIdList *possible_cpus = mc->possible_cpu_arch_ids(machine);
> +NodeInfo *numa_info = machine->numa_state->nodes;
> 
>  assert(machine->numa_state->num_nodes);
>  for (i = 0; i < possible_cpus->len; i++) { @@ -1096,6 +1108,18 @@ static 
> void machine_numa_finish_cpu_init(MachineState *machine)
>  machine_set_cpu_numa_node(machine, , _fatal);
>  }
>  }
> +
> +for (i = 0; i < machine->numa_state->num_nodes; i++) {
> +if (numa_info[i].initiator_valid &&
> +!numa_info[numa_info[i].initiator].has_cpu) {
> +error_report("The initiator-id %"PRIu16 " of NUMA node %d"
> + " does not exist.", numa_info[i].initiator, i);
> +error_printf("\n");
> +
> +exit(1);
> +}
> +}
> +
>  if (s->len && !qtest_enabled()) {
>  warn_report("CPU(s) not present in any NUMA nodes: %s",
>  s->str);
> diff --git a/hw/core/numa.c b/hw/core/numa.c index 8fcbba05d6..cfb6339810 
> 100644
> --- a/hw/core/numa.c
> +++ b/hw/core/numa.c
> @@ -128,6 +128,19 @@ static void parse_numa_node(MachineState *ms, 
> NumaNodeOptions *node,
>  numa_info[nodenr].node_mem = object_property_get_uint(o, "size", 
> NULL);
>  numa_info[nodenr].node_memdev = MEMORY_BACKEND(o);
>  }
> +
> +if (node->has_initiator) {
> +if (numa_info[nodenr].initiator_valid &&
> +(node->initiator != numa_info[nodenr].initiator)) {
> +error_setg(errp, "The initiator of NUMA node %" PRIu16 " has 
> been "
> +   "set to node %" PRIu16, nodenr,
> +   numa_info[nodenr].initiator);
> +return;
> +}
> +
> +numa_info[nodenr].initiator_valid = true;
> +numa_info[nodenr].initiator = node->initiator;
> +}
>  numa_info[nodenr].present = true;
>  max_numa_nodeid = MAX(max_numa_nodeid, nodenr + 1);
>  ms->numa_state->num_nodes++;
> diff --git a/include/sysemu/numa.h b/include/sysemu/numa.h index 
> 76da3016db..46ad06e000 100644
> --- 

Re: [Qemu-devel] [PATCH v3 1/2] bitmap: get last word mask from nr directly

2019-07-21 Thread Wei Yang
On Sun, Jul 21, 2019 at 07:27:14PM +0200, Paolo Bonzini wrote:
>On 21/07/19 02:33, Wei Yang wrote:
>> On Thu, Jul 18, 2019 at 09:04:55AM +0800, Wei Yang wrote:
>>> The value left in nr is the number of bits for the last word, which
>>> could be calculate the last word mask directly.
>>>
>>> Remove the unnecessary size.
>>>
>> 
>> May I ask why Patch 2 is picked up, but this one is not?
>
>Tests are always good to have, this cleanup will wait for 4.2 but it's
>in the queue.
>

Thanks :-)

>Paolo
>
>>> Signed-off-by: Wei Yang 
>>>
>>> ---
>>> v2: refine bitmap_set_atomic too, suggested from Peter
>>> ---
>>> util/bitmap.c | 9 +++--
>>> 1 file changed, 3 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/util/bitmap.c b/util/bitmap.c
>>> index 1753ff7f5b..5b15249796 100644
>>> --- a/util/bitmap.c
>>> +++ b/util/bitmap.c
>>> @@ -160,7 +160,6 @@ int slow_bitmap_andnot(unsigned long *dst, const 
>>> unsigned long *bitmap1,
>>> void bitmap_set(unsigned long *map, long start, long nr)
>>> {
>>> unsigned long *p = map + BIT_WORD(start);
>>> -const long size = start + nr;
>>> int bits_to_set = BITS_PER_LONG - (start % BITS_PER_LONG);
>>> unsigned long mask_to_set = BITMAP_FIRST_WORD_MASK(start);
>>>
>>> @@ -174,7 +173,7 @@ void bitmap_set(unsigned long *map, long start, long nr)
>>> p++;
>>> }
>>> if (nr) {
>>> -mask_to_set &= BITMAP_LAST_WORD_MASK(size);
>>> +mask_to_set &= BITMAP_LAST_WORD_MASK(nr);
>>> *p |= mask_to_set;
>>> }
>>> }
>>> @@ -182,7 +181,6 @@ void bitmap_set(unsigned long *map, long start, long nr)
>>> void bitmap_set_atomic(unsigned long *map, long start, long nr)
>>> {
>>> unsigned long *p = map + BIT_WORD(start);
>>> -const long size = start + nr;
>>> int bits_to_set = BITS_PER_LONG - (start % BITS_PER_LONG);
>>> unsigned long mask_to_set = BITMAP_FIRST_WORD_MASK(start);
>>>
>>> @@ -208,7 +206,7 @@ void bitmap_set_atomic(unsigned long *map, long start, 
>>> long nr)
>>>
>>> /* Last word */
>>> if (nr) {
>>> -mask_to_set &= BITMAP_LAST_WORD_MASK(size);
>>> +mask_to_set &= BITMAP_LAST_WORD_MASK(nr);
>>> atomic_or(p, mask_to_set);
>>> } else {
>>> /* If we avoided the full barrier in atomic_or(), issue a
>>> @@ -221,7 +219,6 @@ void bitmap_set_atomic(unsigned long *map, long start, 
>>> long nr)
>>> void bitmap_clear(unsigned long *map, long start, long nr)
>>> {
>>> unsigned long *p = map + BIT_WORD(start);
>>> -const long size = start + nr;
>>> int bits_to_clear = BITS_PER_LONG - (start % BITS_PER_LONG);
>>> unsigned long mask_to_clear = BITMAP_FIRST_WORD_MASK(start);
>>>
>>> @@ -235,7 +232,7 @@ void bitmap_clear(unsigned long *map, long start, long 
>>> nr)
>>> p++;
>>> }
>>> if (nr) {
>>> -mask_to_clear &= BITMAP_LAST_WORD_MASK(size);
>>> +mask_to_clear &= BITMAP_LAST_WORD_MASK(nr);
>>> *p &= ~mask_to_clear;
>>> }
>>> }
>>> -- 
>>> 2.17.1
>>>
>> 

-- 
Wei Yang
Help you, Help me



[Qemu-devel] [Bug 1818937] Re: Crash with HV_ERROR on macOS host

2019-07-21 Thread Gergely Kis
We can reproduce this problem with Linux guests as well (running 4.15
Ubuntu Xenial and 4.14 Android kernels). Mac models with integrated GPU
seem to be more affected according to our testing, and the crash does
not always occur, needs multiple tries to be triggered. We would be
happy to assist in debugging, once you have a patch that can generate
more detailed logs.

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

Title:
  Crash with HV_ERROR on macOS host

Status in QEMU:
  New

Bug description:
  On macOS host running Windows 10 guest, qemu crashed with error
  message: Error: HV_ERROR.

  Host: macOS Mojave 10.14.3 (18D109) Late 2014 Mac mini presumably Core i5 
4278U.
  QEMU: git commit a3e3b0a7bd5de211a62cdf2d6c12b96d3c403560
  QEMU parameter: qemu-system-x86_64 -m 3000 -drive 
file=disk.img,if=virtio,discard=unmap -accel hvf -soundhw hda -smp 3

  thread list
  Process 56054 stopped
thread #1: tid = 0x2ffec8, 0x7fff48d0805a vImage`vLookupTable_Planar16 
+ 970, queue = 'com.apple.main-thread'
thread #2: tid = 0x2ffecc, 0x7fff79d6d7de 
libsystem_kernel.dylib`__psynch_cvwait + 10
thread #3: tid = 0x2ffecd, 0x7fff79d715aa 
libsystem_kernel.dylib`__select + 10
thread #4: tid = 0x2ffece, 0x7fff79d71d9a 
libsystem_kernel.dylib`__sigwait + 10
  * thread #6: tid = 0x2ffed0, 0x7fff79d7023e 
libsystem_kernel.dylib`__pthread_kill + 10, stop reason = signal SIGABRT
thread #7: tid = 0x2ffed1, 0x7fff79d6d7de 
libsystem_kernel.dylib`__psynch_cvwait + 10
thread #8: tid = 0x2ffed2, 0x7fff79d6d7de 
libsystem_kernel.dylib`__psynch_cvwait + 10
thread #11: tid = 0x2fff34, 0x7fff79d6a17a 
libsystem_kernel.dylib`mach_msg_trap + 10, name = 'com.apple.NSEventThread'
thread #30: tid = 0x300c04, 0x7fff79e233f8 
libsystem_pthread.dylib`start_wqthread
thread #31: tid = 0x300c16, 0x7fff79e233f8 
libsystem_pthread.dylib`start_wqthread
thread #32: tid = 0x300c17, 0x
thread #33: tid = 0x300c93, 0x7fff79d6d7de 
libsystem_kernel.dylib`__psynch_cvwait + 10

  
  Crashed thread:

  * thread #6, stop reason = signal SIGABRT
* frame #0: 0x7fff79d7023e libsystem_kernel.dylib`__pthread_kill + 10
  frame #1: 0x7fff79e26c1c libsystem_pthread.dylib`pthread_kill + 285
  frame #2: 0x7fff79cd91c9 libsystem_c.dylib`abort + 127
  frame #3: 0x00010baa476d 
qemu-system-x86_64`assert_hvf_ok(ret=) at hvf.c:106 [opt]
  frame #4: 0x00010baa4c8f 
qemu-system-x86_64`hvf_vcpu_exec(cpu=0x7f8e5283de00) at hvf.c:681 [opt]
  frame #5: 0x00010b988423 
qemu-system-x86_64`qemu_hvf_cpu_thread_fn(arg=0x7f8e5283de00) at 
cpus.c:1636 [opt]
  frame #6: 0x00010bd9dfce 
qemu-system-x86_64`qemu_thread_start(args=) at 
qemu-thread-posix.c:502 [opt]
  frame #7: 0x7fff79e24305 libsystem_pthread.dylib`_pthread_body + 126
  frame #8: 0x7fff79e2726f libsystem_pthread.dylib`_pthread_start + 70
  frame #9: 0x7fff79e23415 libsystem_pthread.dylib`thread_start + 13

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



Re: [Qemu-devel] [PATCH 4/4] target/sparc: sun4u Invert Endian TTE bit

2019-07-21 Thread Mark Cave-Ayland
On 17/07/2019 07:10, tony.ngu...@bt.com wrote:

> This bit configures endianness of PCI MMIO devices. It is used by
> Solaris and OpenBSD sunhme drivers.
> 
> Tested working on OpenBSD.
> 
> Unfortunately Solaris 10 had a unrelated keyboard issue blocking
> testing... another inch towards Solaris 10 on SPARC64 =)
> 
> Signed-off-by: Tony Nguyen 
> ---
>  target/sparc/cpu.h|  2 ++
>  target/sparc/mmu_helper.c | 41 +++
>  2 files changed, 31 insertions(+), 12 deletions(-)
> 
> diff --git a/target/sparc/cpu.h b/target/sparc/cpu.h
> index 8ed2250cd0..77e8e07194 100644
> --- a/target/sparc/cpu.h
> +++ b/target/sparc/cpu.h
> @@ -277,6 +277,7 @@ enum {
>  
>  #define TTE_VALID_BIT   (1ULL << 63)
>  #define TTE_NFO_BIT (1ULL << 60)
> +#define TTE_IE_BIT  (1ULL << 59)
>  #define TTE_USED_BIT(1ULL << 41)
>  #define TTE_LOCKED_BIT  (1ULL <<  6)
>  #define TTE_SIDEEFFECT_BIT  (1ULL <<  3)
> @@ -293,6 +294,7 @@ enum {
>  
>  #define TTE_IS_VALID(tte)   ((tte) & TTE_VALID_BIT)
>  #define TTE_IS_NFO(tte) ((tte) & TTE_NFO_BIT)
> +#define TTE_IS_IE(tte)  ((tte) & TTE_IE_BIT)
>  #define TTE_IS_USED(tte)((tte) & TTE_USED_BIT)
>  #define TTE_IS_LOCKED(tte)  ((tte) & TTE_LOCKED_BIT)
>  #define TTE_IS_SIDEEFFECT(tte) ((tte) & TTE_SIDEEFFECT_BIT)
> diff --git a/target/sparc/mmu_helper.c b/target/sparc/mmu_helper.c
> index cbd1e91179..f7b97d1e46 100644
> --- a/target/sparc/mmu_helper.c
> +++ b/target/sparc/mmu_helper.c
> @@ -492,7 +492,8 @@ static inline int ultrasparc_tag_match(SparcTLBEntry *tlb,
>  
>  static int get_physical_address_data(CPUSPARCState *env,
>   hwaddr *physical, int *prot,
> - target_ulong address, int rw, int 
> mmu_idx)
> + MemTxAttrs *attrs, target_ulong address,
> + int rw, int mmu_idx)
>  {
>  CPUState *cs = env_cpu(env);
>  unsigned int i;
> @@ -536,6 +537,10 @@ static int get_physical_address_data(CPUSPARCState *env,
>  if (ultrasparc_tag_match(>dtlb[i], address, context, physical)) 
> {
>  int do_fault = 0;
>  
> +if (TTE_IS_IE(env->dtlb[i].tte)) {
> +attrs->byte_swap = true;
> +}
> +
>  /* access ok? */
>  /* multiple bits in SFSR.FT may be set on TT_DFAULT */
>  if (TTE_IS_PRIV(env->dtlb[i].tte) && is_user) {
> @@ -686,7 +691,7 @@ static int get_physical_address_code(CPUSPARCState *env,
>  }
>  
>  static int get_physical_address(CPUSPARCState *env, hwaddr *physical,
> -int *prot, int *access_index,
> +int *prot, MemTxAttrs *attrs,
>  target_ulong address, int rw, int mmu_idx,
>  target_ulong *page_size)
>  {
> @@ -716,11 +721,12 @@ static int get_physical_address(CPUSPARCState *env, 
> hwaddr *physical,
>  }
>  
>  if (rw == 2) {
> +*attrs = MEMTXATTRS_UNSPECIFIED;
>  return get_physical_address_code(env, physical, prot, address,
>   mmu_idx);
>  } else {
> -return get_physical_address_data(env, physical, prot, address, rw,
> - mmu_idx);
> +return get_physical_address_data(env, physical, prot, attrs, address,
> + rw, mmu_idx);
>  }
>  }
>  
> @@ -734,10 +740,11 @@ bool sparc_cpu_tlb_fill(CPUState *cs, vaddr address, 
> int size,
>  target_ulong vaddr;
>  hwaddr paddr;
>  target_ulong page_size;
> -int error_code = 0, prot, access_index;
> +MemTxAttrs attrs = {> +int error_code = 0, prot;
>  
>  address &= TARGET_PAGE_MASK;
> -error_code = get_physical_address(env, , , _index,
> +error_code = get_physical_address(env, , , ,
>address, access_type,
>mmu_idx, _size);
>  if (likely(error_code == 0)) {
> @@ -747,7 +754,8 @@ bool sparc_cpu_tlb_fill(CPUState *cs, vaddr address, int 
> size,
> env->dmmu.mmu_primary_context,
> env->dmmu.mmu_secondary_context);
>  
> -tlb_set_page(cs, vaddr, paddr, prot, mmu_idx, page_size);
> +tlb_set_page_with_attrs(cs, vaddr, paddr, attrs, prot, mmu_idx,
> +page_size);
>  return true;
>  }
>  if (probe) {
> @@ -789,7 +797,7 @@ void dump_mmu(CPUSPARCState *env)
>  }
>  if (TTE_IS_VALID(env->dtlb[i].tte)) {
>  qemu_printf("[%02u] VA: %" PRIx64 ", PA: %llx"
> -", %s, %s, %s, %s, ctx %" PRId64 " %s\n",
> +", %s, %s, %s, %s, ie %s, ctx %" PRId64 " %s\n",
>  i,
>

[Qemu-devel] [PATCH 1/2] LUKS: better error message when creating too large files

2019-07-21 Thread Maxim Levitsky
Currently if you attampt to create too large file with luks you
get the following error message:

Formatting 'test.luks', fmt=luks size=17592186044416 key-secret=sec0
qemu-img: test.luks: Could not resize file: File too large

While for raw format the error message is
qemu-img: test.img: The image size is too large for file format 'raw'


The reason for this is that qemu-img checks for errono of the failure,
and presents the later error when it is -EFBIG

However crypto generic code 'swallows' the errno and replaces it
with -EIO.

As an attempt to make it better, we can make luks driver,
detect -EFBIG and in this case present a better error message,
which is what this patch does

The new error message is:

qemu-img: error creating test.luks: The requested file size is too large

Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1534898
Signed-off-by: Maxim Levitsky 
---
 block/crypto.c | 25 +
 1 file changed, 21 insertions(+), 4 deletions(-)

diff --git a/block/crypto.c b/block/crypto.c
index 8237424ae6..73b1013fa1 100644
--- a/block/crypto.c
+++ b/block/crypto.c
@@ -102,18 +102,35 @@ static ssize_t block_crypto_init_func(QCryptoBlock *block,
   Error **errp)
 {
 struct BlockCryptoCreateData *data = opaque;
+Error *local_error = NULL;
+int ret;
 
 if (data->size > INT64_MAX || headerlen > INT64_MAX - data->size) {
-error_setg(errp, "The requested file size is too large");
-return -EFBIG;
+ret = -EFBIG;
+goto error;
 }
 
 /* User provided size should reflect amount of space made
  * available to the guest, so we must take account of that
  * which will be used by the crypto header
  */
-return blk_truncate(data->blk, data->size + headerlen, PREALLOC_MODE_OFF,
-errp);
+ret = blk_truncate(data->blk, data->size + headerlen, PREALLOC_MODE_OFF,
+   _error);
+
+if (ret >= 0) {
+return ret;
+}
+
+error:
+if (ret == -EFBIG) {
+/* Replace the error message with a better one */
+error_free(local_error);
+error_setg(errp, "The requested file size is too large");
+} else {
+error_propagate(errp, local_error);
+}
+
+return ret;
 }
 
 
-- 
2.17.2




[Qemu-devel] [PATCH 2/2] qemu-img: better error message when opening a backing file fails

2019-07-21 Thread Maxim Levitsky
Currently we print message like that:

"
new_file.qcow2 : error message
"

However the error could have come from opening the backing file (e.g when it 
missing encryption keys),
thus try to clarify this by using this format:

"
qemu-img: error creating new_file.qcow2: base_file.qcow2: error message
Could not open backing image to determine size.
"


Test used:

qemu-img create -f qcow2 \
--object secret,id=sec0,data=hunter9 \
--object secret,id=sec1,data=my_new_secret_password \
-b 'json:{ "encrypt.key-secret": "sec1", "driver": "qcow2", "file": { 
"driver": "file", "filename": "base.qcow2" }}' \
-o encrypt.format=luks,encrypt.key-secret=sec1 \
sn.qcow2


Error message before:

qemu-img: sn.qcow2: Invalid password, cannot unlock any keyslot
Could not open backing image to determine size.


Error message after:

qemu-img: error creating sn.qcow2: \
json:{ "encrypt.key-secret": "sec1", "driver": "qcow2", "file": { 
"driver": "file", "filename": "base.qcow2" }}: \
Invalid password, cannot unlock any keyslot
Could not open backing image to determine size.

Signed-off-by: Maxim Levitsky 
---
 block.c| 1 +
 qemu-img.c | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/block.c b/block.c
index 29e931e217..5eb47b2199 100644
--- a/block.c
+++ b/block.c
@@ -5790,6 +5790,7 @@ void bdrv_img_create(const char *filename, const char 
*fmt,
 "This may become an error in future versions.\n");
 local_err = NULL;
 } else if (!bs) {
+error_prepend(_err, "%s: ", backing_file);
 /* Couldn't open bs, do not have size */
 error_append_hint(_err,
   "Could not open backing image to determine 
size.\n");
diff --git a/qemu-img.c b/qemu-img.c
index 79983772de..134bf2fbe0 100644
--- a/qemu-img.c
+++ b/qemu-img.c
@@ -545,7 +545,7 @@ static int img_create(int argc, char **argv)
 bdrv_img_create(filename, fmt, base_filename, base_fmt,
 options, img_size, flags, quiet, _err);
 if (local_err) {
-error_reportf_err(local_err, "%s: ", filename);
+error_reportf_err(local_err, "error creating %s: ", filename);
 goto fail;
 }
 
-- 
2.17.2




[Qemu-devel] [PATCH 0/2] RFC: Trivial error message fixes for luks format

2019-07-21 Thread Maxim Levitsky
These are attempts to improve a bit error message
based on bunch of luks related bugzillas assigned to me.
Feel free to reject these if you think that it doesn't
make the messages better.

Best regards,
Maxim Levitsky

Maxim Levitsky (2):
  LUKS: better error message when creating too large files
  qemu-img: better error message when opening a backing file fails

 block.c|  1 +
 block/crypto.c | 25 +
 qemu-img.c |  2 +-
 3 files changed, 23 insertions(+), 5 deletions(-)

-- 
2.17.2




Re: [Qemu-devel] [PATCH v3 1/2] bitmap: get last word mask from nr directly

2019-07-21 Thread Paolo Bonzini
On 21/07/19 02:33, Wei Yang wrote:
> On Thu, Jul 18, 2019 at 09:04:55AM +0800, Wei Yang wrote:
>> The value left in nr is the number of bits for the last word, which
>> could be calculate the last word mask directly.
>>
>> Remove the unnecessary size.
>>
> 
> May I ask why Patch 2 is picked up, but this one is not?

Tests are always good to have, this cleanup will wait for 4.2 but it's
in the queue.

Paolo

>> Signed-off-by: Wei Yang 
>>
>> ---
>> v2: refine bitmap_set_atomic too, suggested from Peter
>> ---
>> util/bitmap.c | 9 +++--
>> 1 file changed, 3 insertions(+), 6 deletions(-)
>>
>> diff --git a/util/bitmap.c b/util/bitmap.c
>> index 1753ff7f5b..5b15249796 100644
>> --- a/util/bitmap.c
>> +++ b/util/bitmap.c
>> @@ -160,7 +160,6 @@ int slow_bitmap_andnot(unsigned long *dst, const 
>> unsigned long *bitmap1,
>> void bitmap_set(unsigned long *map, long start, long nr)
>> {
>> unsigned long *p = map + BIT_WORD(start);
>> -const long size = start + nr;
>> int bits_to_set = BITS_PER_LONG - (start % BITS_PER_LONG);
>> unsigned long mask_to_set = BITMAP_FIRST_WORD_MASK(start);
>>
>> @@ -174,7 +173,7 @@ void bitmap_set(unsigned long *map, long start, long nr)
>> p++;
>> }
>> if (nr) {
>> -mask_to_set &= BITMAP_LAST_WORD_MASK(size);
>> +mask_to_set &= BITMAP_LAST_WORD_MASK(nr);
>> *p |= mask_to_set;
>> }
>> }
>> @@ -182,7 +181,6 @@ void bitmap_set(unsigned long *map, long start, long nr)
>> void bitmap_set_atomic(unsigned long *map, long start, long nr)
>> {
>> unsigned long *p = map + BIT_WORD(start);
>> -const long size = start + nr;
>> int bits_to_set = BITS_PER_LONG - (start % BITS_PER_LONG);
>> unsigned long mask_to_set = BITMAP_FIRST_WORD_MASK(start);
>>
>> @@ -208,7 +206,7 @@ void bitmap_set_atomic(unsigned long *map, long start, 
>> long nr)
>>
>> /* Last word */
>> if (nr) {
>> -mask_to_set &= BITMAP_LAST_WORD_MASK(size);
>> +mask_to_set &= BITMAP_LAST_WORD_MASK(nr);
>> atomic_or(p, mask_to_set);
>> } else {
>> /* If we avoided the full barrier in atomic_or(), issue a
>> @@ -221,7 +219,6 @@ void bitmap_set_atomic(unsigned long *map, long start, 
>> long nr)
>> void bitmap_clear(unsigned long *map, long start, long nr)
>> {
>> unsigned long *p = map + BIT_WORD(start);
>> -const long size = start + nr;
>> int bits_to_clear = BITS_PER_LONG - (start % BITS_PER_LONG);
>> unsigned long mask_to_clear = BITMAP_FIRST_WORD_MASK(start);
>>
>> @@ -235,7 +232,7 @@ void bitmap_clear(unsigned long *map, long start, long 
>> nr)
>> p++;
>> }
>> if (nr) {
>> -mask_to_clear &= BITMAP_LAST_WORD_MASK(size);
>> +mask_to_clear &= BITMAP_LAST_WORD_MASK(nr);
>> *p &= ~mask_to_clear;
>> }
>> }
>> -- 
>> 2.17.1
>>
> 




Re: [Qemu-devel] [PATCH] ioapic: kvm: Skip route updates for masked pins

2019-07-21 Thread Paolo Bonzini
On 21/07/19 12:04, Michael S. Tsirkin wrote:
> On Sun, Jul 21, 2019 at 10:58:42AM +0200, Jan Kiszka wrote:
>> On 03.06.19 02:36, Michael S. Tsirkin wrote:
>>> On Sun, Jun 02, 2019 at 01:42:13PM +0200, Jan Kiszka wrote:
 From: Jan Kiszka 

 Masked entries will not generate interrupt messages, thus do no need to
 be routed by KVM. This is a cosmetic cleanup, just avoiding warnings of
 the kind

 qemu-system-x86_64: vtd_irte_get: detected non-present IRTE (index=0, 
 high=0xff00, low=0x100)

 if the masked entry happens to reference a non-present IRTE.

 Signed-off-by: Jan Kiszka 
>>>
>>> Reviewed-by: Michael S. Tsirkin 
>>>
 ---
  hw/intc/ioapic.c | 8 +---
  1 file changed, 5 insertions(+), 3 deletions(-)

 diff --git a/hw/intc/ioapic.c b/hw/intc/ioapic.c
 index 7074489fdf..2fb288a22d 100644
 --- a/hw/intc/ioapic.c
 +++ b/hw/intc/ioapic.c
 @@ -197,9 +197,11 @@ static void 
 ioapic_update_kvm_routes(IOAPICCommonState *s)
  MSIMessage msg;
  struct ioapic_entry_info info;
  ioapic_entry_parse(s->ioredtbl[i], );
 -msg.address = info.addr;
 -msg.data = info.data;
 -kvm_irqchip_update_msi_route(kvm_state, i, msg, NULL);
 +if (!info.masked) {
 +msg.address = info.addr;
 +msg.data = info.data;
 +kvm_irqchip_update_msi_route(kvm_state, i, msg, NULL);
 +}
  }
  kvm_irqchip_commit_routes(kvm_state);
  }
 --
 2.16.4
>>>
>>>
>>
>> Ping. Or is this queued for 4.2?
>>
>> Jan
> 
> Paolo was queueing ioapic things recently. I can take this if
> he doesn't respond until I pack up my next pull req.
> 

I've already sent a pull request and had missed this patch, so please go
ahead.

Paolo



Re: [Qemu-devel] Handling of fall through code

2019-07-21 Thread Stefan Weil
Am 09.07.2019 um 10:25 schrieb Peter Maydell:
> On Mon, 8 Jul 2019 at 20:39, Aleksandar Markovic  
> wrote:
>> They are all real issues. Two of them are cases of missing
>> '/* fall through */' (I plan to send fixes for them in 4.2 timeframe)
>> and five of them are cases of missing 'break' (I plan to send
>> corresponding fixes for 4.1 in few days).
> Adding missing /* fall through */ comments would be fine as
> a patch for 4.1 rc1 if you liked, though you can of course
> wait til 4.2 if that's better for you.
>
> thanks
> -- PMM


Peter, is this fall through for ARM correct?

https://github.com/qemu/qemu/blob/master/target/arm/helper.c#L7958

It looks rather suspicious and is one of the remaining related compiler
warnings.

Regards
Stefan




Re: [Qemu-devel] [PATCH v2 03/14] audio: add audiodev property to vnc and wav_capture

2019-07-21 Thread Zoltán Kővágó

On 2019-07-16 08:23, Markus Armbruster wrote:

"Kővágó, Zoltán"  writes:


Signed-off-by: Kővágó, Zoltán 
---
  ui/vnc.h|  2 ++
  monitor/misc.c  | 12 +++-
  ui/vnc.c| 15 ++-
  hmp-commands.hx | 13 -
  qemu-options.hx |  6 ++
  5 files changed, 41 insertions(+), 7 deletions(-)

diff --git a/ui/vnc.h b/ui/vnc.h
index 2f84db3142..6f54653455 100644
--- a/ui/vnc.h
+++ b/ui/vnc.h
@@ -183,6 +183,8 @@ struct VncDisplay
  #ifdef CONFIG_VNC_SASL
  VncDisplaySASL sasl;
  #endif
+
+AudioState *audio_state;
  };
  
  typedef struct VncTight {

diff --git a/monitor/misc.c b/monitor/misc.c
index e39a0e..f97810d370 100644
--- a/monitor/misc.c
+++ b/monitor/misc.c
@@ -1148,7 +1148,17 @@ static void hmp_wavcapture(Monitor *mon, const QDict 
*qdict)
  int bits = qdict_get_try_int(qdict, "bits", -1);
  int has_channels = qdict_haskey(qdict, "nchannels");
  int nchannels = qdict_get_try_int(qdict, "nchannels", -1);
+const char *audiodev = qdict_get_try_str(qdict, "audiodev");
  CaptureState *s;
+AudioState *as = NULL;
+
+if (audiodev) {
+as = audio_state_by_name(audiodev);
+if (!as) {
+monitor_printf(mon, "Invalid audiodev specified\n");
+return;
+}
+}


Note for later: if "audiodev" is specified, it must name an existing
AudioState.

  
  s = g_malloc0 (sizeof (*s));
  
@@ -1156,7 +1166,7 @@ static void hmp_wavcapture(Monitor *mon, const QDict *qdict)

  bits = has_bits ? bits : 16;
  nchannels = has_channels ? nchannels : 2;
  
-if (wav_start_capture(NULL, s, path, freq, bits, nchannels)) {

+if (wav_start_capture(as, s, path, freq, bits, nchannels)) {
  monitor_printf(mon, "Failed to add wave capture\n");
  g_free (s);
  return;


Note for later: this is the only other failure mode.


diff --git a/ui/vnc.c b/ui/vnc.c
index 140f364dda..24f9be5b5d 100644
--- a/ui/vnc.c
+++ b/ui/vnc.c
@@ -1222,7 +1222,7 @@ static void audio_add(VncState *vs)
  ops.destroy = audio_capture_destroy;
  ops.capture = audio_capture;
  
-vs->audio_cap = AUD_add_capture(NULL, >as, , vs);

+vs->audio_cap = AUD_add_capture(vs->vd->audio_state, >as, , vs);
  if (!vs->audio_cap) {
  error_report("Failed to add audio capture");
  }
@@ -3369,6 +3369,9 @@ static QemuOptsList qemu_vnc_opts = {
  },{
  .name = "non-adaptive",
  .type = QEMU_OPT_BOOL,
+},{
+.name = "audiodev",
+.type = QEMU_OPT_STRING,
  },
  { /* end of list */ }
  },
@@ -3806,6 +3809,7 @@ void vnc_display_open(const char *id, Error **errp)
  const char *saslauthz;
  int lock_key_sync = 1;
  int key_delay_ms;
+const char *audiodev;
  
  if (!vd) {

  error_setg(errp, "VNC display not active");
@@ -3991,6 +3995,15 @@ void vnc_display_open(const char *id, Error **errp)
  }
  vd->ledstate = 0;
  
+audiodev = qemu_opt_get(opts, "audiodev");

+if (audiodev) {
+vd->audio_state = audio_state_by_name(audiodev);
+if (!vd->audio_state) {
+error_setg(errp, "Audiodev '%s' not found", audiodev);
+goto fail;
+}
+}


Note for later: if "audiodev" is specified, it must name an existing
AudioState.

I like this error message better than the one in hmp_wavcapture().  Use
it there, too?

Move it into audio_state_by_name() by giving it an Error **errp
parameter?  Matter of taste, up to you.


+
  device_id = qemu_opt_get(opts, "display");
  if (device_id) {
  int head = qemu_opt_get_number(opts, "head", 0);
diff --git a/hmp-commands.hx b/hmp-commands.hx
index bfa5681dd2..fa7f009268 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -819,16 +819,19 @@ ETEXI
  
  {

  .name   = "wavcapture",
-.args_type  = "path:F,freq:i?,bits:i?,nchannels:i?",
-.params = "path [frequency [bits [channels]]]",
+.args_type  = "path:F,freq:i?,bits:i?,nchannels:i?,audiodev:s?",
+.params = "path [frequency [bits [channels [audiodev",
  .help   = "capture audio to a wave file (default frequency=44100 
bits=16 channels=2)",
  .cmd= hmp_wavcapture,
  },
  STEXI
-@item wavcapture @var{filename} [@var{frequency} [@var{bits} [@var{channels}]]]
+@item wavcapture @var{filename} [@var{frequency} [@var{bits} [@var{channels} 
[@var{audiodev}
  @findex wavcapture
-Capture audio into @var{filename}. Using sample rate @var{frequency}
-bits per sample @var{bits} and number of channels @var{channels}.
+Capture audio into @var{filename} from @var{audiodev}, using sample rate
+@var{frequency} bits per sample @var{bits} and number of channels
+@var{channels}. When not using an -audiodev argument on command line,
+@var{audiodev} must be omitted, otherwise is must specify a valid
+audiodev.


I can see the code for "must specify a valid audiodev" in

Re: [Qemu-devel] [PATCH] ioapic: kvm: Skip route updates for masked pins

2019-07-21 Thread Michael S. Tsirkin
On Sun, Jul 21, 2019 at 10:58:42AM +0200, Jan Kiszka wrote:
> On 03.06.19 02:36, Michael S. Tsirkin wrote:
> > On Sun, Jun 02, 2019 at 01:42:13PM +0200, Jan Kiszka wrote:
> >> From: Jan Kiszka 
> >>
> >> Masked entries will not generate interrupt messages, thus do no need to
> >> be routed by KVM. This is a cosmetic cleanup, just avoiding warnings of
> >> the kind
> >>
> >> qemu-system-x86_64: vtd_irte_get: detected non-present IRTE (index=0, 
> >> high=0xff00, low=0x100)
> >>
> >> if the masked entry happens to reference a non-present IRTE.
> >>
> >> Signed-off-by: Jan Kiszka 
> >
> > Reviewed-by: Michael S. Tsirkin 
> >
> >> ---
> >>  hw/intc/ioapic.c | 8 +---
> >>  1 file changed, 5 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/hw/intc/ioapic.c b/hw/intc/ioapic.c
> >> index 7074489fdf..2fb288a22d 100644
> >> --- a/hw/intc/ioapic.c
> >> +++ b/hw/intc/ioapic.c
> >> @@ -197,9 +197,11 @@ static void 
> >> ioapic_update_kvm_routes(IOAPICCommonState *s)
> >>  MSIMessage msg;
> >>  struct ioapic_entry_info info;
> >>  ioapic_entry_parse(s->ioredtbl[i], );
> >> -msg.address = info.addr;
> >> -msg.data = info.data;
> >> -kvm_irqchip_update_msi_route(kvm_state, i, msg, NULL);
> >> +if (!info.masked) {
> >> +msg.address = info.addr;
> >> +msg.data = info.data;
> >> +kvm_irqchip_update_msi_route(kvm_state, i, msg, NULL);
> >> +}
> >>  }
> >>  kvm_irqchip_commit_routes(kvm_state);
> >>  }
> >> --
> >> 2.16.4
> >
> >
> 
> Ping. Or is this queued for 4.2?
> 
> Jan

Paolo was queueing ioapic things recently. I can take this if
he doesn't respond until I pack up my next pull req.

-- 
MST



Re: [Qemu-devel] [PATCH V3] net/colo-compare.c: Fix memory leak and code style issue.

2019-07-21 Thread Zhang, Chen
Sorry, I re-sent the old version.
Please redirect to V4 patch.

Thanks
Zhang Chen

> -Original Message-
> From: Zhang, Chen
> Sent: Thursday, July 18, 2019 5:22 PM
> To: Li Zhijian ; Peter Maydell
> ; Jason Wang ; qemu-dev
> 
> Cc: Zhang Chen ; Zhang, Chen 
> Subject: [PATCH V3] net/colo-compare.c: Fix memory leak and code style issue.
> 
> From: Zhang Chen 
> 
> This patch to fix the origin "char *data" menory leak, code style issue and 
> add
> necessary check here.
> Reported-by: Coverity (CID 1402785)
> 
> Signed-off-by: Zhang Chen 
> ---
>  net/colo-compare.c | 28 +---
>  1 file changed, 21 insertions(+), 7 deletions(-)
> 
> diff --git a/net/colo-compare.c b/net/colo-compare.c index
> 909dd6c6eb..fcccb4c6f6 100644
> --- a/net/colo-compare.c
> +++ b/net/colo-compare.c
> @@ -127,6 +127,17 @@ static int compare_chr_send(CompareState *s,
>  uint32_t vnet_hdr_len,
>  bool notify_remote_frame);
> 
> +static bool packet_matches_str(const char *str,
> +   uint8_t *buf,
> +   uint32_t packet_len) {
> +if (packet_len != strlen(str)) {
> +return false;
> +}
> +
> +return !memcmp(str, buf, strlen(str)); }
> +
>  static void notify_remote_frame(CompareState *s)  {
>  char msg[] = "DO_CHECKPOINT";
> @@ -1008,21 +1019,24 @@ static void
> compare_notify_rs_finalize(SocketReadState *notify_rs)  {
>  CompareState *s = container_of(notify_rs, CompareState, notify_rs);
> 
> -/* Get Xen colo-frame's notify and handle the message */
> -char *data = g_memdup(notify_rs->buf, notify_rs->packet_len);
> -char msg[] = "COLO_COMPARE_GET_XEN_INIT";
> +const char msg[] = "COLO_COMPARE_GET_XEN_INIT";
>  int ret;
> 
> -if (!strcmp(data, "COLO_USERSPACE_PROXY_INIT")) {
> +if (packet_matches_str("COLO_USERSPACE_PROXY_INIT",
> +   notify_rs->buf,
> +   notify_rs->packet_len)) {
>  ret = compare_chr_send(s, (uint8_t *)msg, strlen(msg), 0, true);
>  if (ret < 0) {
>  error_report("Notify Xen COLO-frame INIT failed");
>  }
> -}
> -
> -if (!strcmp(data, "COLO_CHECKPOINT")) {
> +} else if (packet_matches_str("COLO_CHECKPOINT",
> +  notify_rs->buf,
> +  notify_rs->packet_len)) {
>  /* colo-compare do checkpoint, flush pri packet and remove sec 
> packet */
>  g_queue_foreach(>conn_list, colo_flush_packets, s);
> +} else {
> +error_report("COLO compare got unsupported instruction '%s'",
> + (char *)notify_rs->buf);
>  }
>  }
> 
> --
> 2.17.GIT




[Qemu-devel] [PATCH V4] net/colo-compare.c: Fix memory leak and code style issue.

2019-07-21 Thread Zhang Chen
From: Zhang Chen 

This patch to fix the origin "char *data" memory leak, code style issue
and add necessary check here.
Reported-by: Coverity (CID 1402785)

Signed-off-by: Zhang Chen 
---
 net/colo-compare.c | 28 +---
 1 file changed, 21 insertions(+), 7 deletions(-)

diff --git a/net/colo-compare.c b/net/colo-compare.c
index 909dd6c6eb..23c0d906ab 100644
--- a/net/colo-compare.c
+++ b/net/colo-compare.c
@@ -127,6 +127,17 @@ static int compare_chr_send(CompareState *s,
 uint32_t vnet_hdr_len,
 bool notify_remote_frame);
 
+static bool packet_matches_str(const char *str,
+   const uint8_t *buf,
+   uint32_t packet_len)
+{
+if (packet_len != strlen(str)) {
+return false;
+}
+
+return !memcmp(str, buf, strlen(str));
+}
+
 static void notify_remote_frame(CompareState *s)
 {
 char msg[] = "DO_CHECKPOINT";
@@ -1008,21 +1019,24 @@ static void compare_notify_rs_finalize(SocketReadState 
*notify_rs)
 {
 CompareState *s = container_of(notify_rs, CompareState, notify_rs);
 
-/* Get Xen colo-frame's notify and handle the message */
-char *data = g_memdup(notify_rs->buf, notify_rs->packet_len);
-char msg[] = "COLO_COMPARE_GET_XEN_INIT";
+const char msg[] = "COLO_COMPARE_GET_XEN_INIT";
 int ret;
 
-if (!strcmp(data, "COLO_USERSPACE_PROXY_INIT")) {
+if (packet_matches_str("COLO_USERSPACE_PROXY_INIT",
+   notify_rs->buf,
+   notify_rs->packet_len)) {
 ret = compare_chr_send(s, (uint8_t *)msg, strlen(msg), 0, true);
 if (ret < 0) {
 error_report("Notify Xen COLO-frame INIT failed");
 }
-}
-
-if (!strcmp(data, "COLO_CHECKPOINT")) {
+} else if (packet_matches_str("COLO_CHECKPOINT",
+  notify_rs->buf,
+  notify_rs->packet_len)) {
 /* colo-compare do checkpoint, flush pri packet and remove sec packet 
*/
 g_queue_foreach(>conn_list, colo_flush_packets, s);
+} else {
+error_report("COLO compare got unsupported instruction '%s'",
+ (char *)notify_rs->buf);
 }
 }
 
-- 
2.17.GIT




[Qemu-devel] [PATCH] i386/vmmouse: Properly reset state

2019-07-21 Thread Jan Kiszka
From: Jan Kiszka 

nb_queue was not zeroed so that we no longer delivered events if a
previous guest left the device in an overflow state.

The state of absolute does not matter as the next vmmouse_update_handler
call will align it again.

Signed-off-by: Jan Kiszka 
---
 hw/i386/vmmouse.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/i386/vmmouse.c b/hw/i386/vmmouse.c
index 5d2d278be4..e335bd07da 100644
--- a/hw/i386/vmmouse.c
+++ b/hw/i386/vmmouse.c
@@ -257,6 +257,7 @@ static void vmmouse_reset(DeviceState *d)
 VMMouseState *s = VMMOUSE(d);

 s->queue_size = VMMOUSE_QUEUE_SIZE;
+s->nb_queue = 0;

 vmmouse_disable(s);
 }
--
2.16.4



Re: [Qemu-devel] [PATCH] ioapic: kvm: Skip route updates for masked pins

2019-07-21 Thread Jan Kiszka
On 03.06.19 02:36, Michael S. Tsirkin wrote:
> On Sun, Jun 02, 2019 at 01:42:13PM +0200, Jan Kiszka wrote:
>> From: Jan Kiszka 
>>
>> Masked entries will not generate interrupt messages, thus do no need to
>> be routed by KVM. This is a cosmetic cleanup, just avoiding warnings of
>> the kind
>>
>> qemu-system-x86_64: vtd_irte_get: detected non-present IRTE (index=0, 
>> high=0xff00, low=0x100)
>>
>> if the masked entry happens to reference a non-present IRTE.
>>
>> Signed-off-by: Jan Kiszka 
>
> Reviewed-by: Michael S. Tsirkin 
>
>> ---
>>  hw/intc/ioapic.c | 8 +---
>>  1 file changed, 5 insertions(+), 3 deletions(-)
>>
>> diff --git a/hw/intc/ioapic.c b/hw/intc/ioapic.c
>> index 7074489fdf..2fb288a22d 100644
>> --- a/hw/intc/ioapic.c
>> +++ b/hw/intc/ioapic.c
>> @@ -197,9 +197,11 @@ static void ioapic_update_kvm_routes(IOAPICCommonState 
>> *s)
>>  MSIMessage msg;
>>  struct ioapic_entry_info info;
>>  ioapic_entry_parse(s->ioredtbl[i], );
>> -msg.address = info.addr;
>> -msg.data = info.data;
>> -kvm_irqchip_update_msi_route(kvm_state, i, msg, NULL);
>> +if (!info.masked) {
>> +msg.address = info.addr;
>> +msg.data = info.data;
>> +kvm_irqchip_update_msi_route(kvm_state, i, msg, NULL);
>> +}
>>  }
>>  kvm_irqchip_commit_routes(kvm_state);
>>  }
>> --
>> 2.16.4
>
>

Ping. Or is this queued for 4.2?

Jan



Re: [Qemu-devel] [PATCH v5] LUKS: support preallocation

2019-07-21 Thread Maxim Levitsky
On Fri, 2019-07-19 at 12:28 +0200, Max Reitz wrote:
> On 16.07.19 18:19, Maxim Levitsky wrote:
> > preallocation=off and preallocation=metadata
> > both allocate luks header only, and preallocation=falloc/full
> > is passed to underlying file.
> > 
> > Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1534951
> > 
> > Signed-off-by: Maxim Levitsky 
> > ---
> > 
> > This is hopefully a revision without coding style violations.
> > 
> > Note that I still haven't tested the blockdev-create code, other that
> > compile testing it.
> > 
> > Best regards,
> > Maxim Levitsky
> > 
> > 
> >  block/crypto.c   | 30 +++---
> >  qapi/block-core.json |  6 +-
> >  2 files changed, 32 insertions(+), 4 deletions(-)
> 
> Thanks, applied to my block-next branch for 4.2:
> 
> https://git.xanclic.moe/XanClic/qemu/commits/branch/block-next
> 
> Max
> 
> (The Patchew warning doesn’t look like it’s caused by this patch.)
> 

Thank you!!
Best regards,
Maxim Levitsky




Re: [Qemu-devel] [PATCH v4 0/3] Few bugfixes for userspace nvme driver

2019-07-21 Thread Maxim Levitsky
On Fri, 2019-07-19 at 11:51 +0200, Max Reitz wrote:
> On 16.07.19 18:30, Maxim Levitsky wrote:
> > This is reduced version of patch series for userspace nvme driver,
> > that only includes the bugfixes I made.
> > 
> > Best regards,
> > Maxim Levitsky
> > 
> > Maxim Levitsky (3):
> >   block/nvme: fix doorbell stride
> >   block/nvme: support larger that 512 bytes sector devices
> >   block/nvme: don't touch the completion entries
> > 
> >  block/nvme.c | 52 ++--
> >  1 file changed, 42 insertions(+), 10 deletions(-)
> 
> Thanks, applied to my block branch:
> 
> https://git.xanclic.moe/XanClic/qemu/commits/branch/block
> 
> Max
> 
Thank you!!
Best regards,
Maxim Levitsky




[Qemu-devel] [PATCH v2] virtio-scsi: fixed virtio_scsi_ctx_check failed when detaching scsi disk

2019-07-21 Thread l00284672
commit a6f230c move blockbackend back to main AioContext on unplug. It set the 
AioContext of
SCSIDevice to the main AioContex, but s->ctx is still the iothread AioContex(if 
the scsi controller
is configure with iothread). So if there are having in-flight requests during 
unplug, a failing assertion
happend. The bt is below:
(gdb) bt
#0  0x86aacbd0 in raise () from /lib64/libc.so.6
#1  0x86aadf7c in abort () from /lib64/libc.so.6
#2  0x86aa6124 in __assert_fail_base () from /lib64/libc.so.6
#3  0x86aa61a4 in __assert_fail () from /lib64/libc.so.6
#4  0x00529118 in virtio_scsi_ctx_check (d=, 
s=, s=) at 
/home/qemu-4.0.0/hw/scsi/virtio-scsi.c:246
#5  0x00529ec4 in virtio_scsi_handle_cmd_req_prepare (s=0x2779ec00, 
req=0x740397d0) at /home/qemu-4.0.0/hw/scsi/virtio-scsi.c:559
#6  0x0052a228 in virtio_scsi_handle_cmd_vq (s=0x2779ec00, 
vq=0x7c6d7110) at /home/qemu-4.0.0/hw/scsi/virtio-scsi.c:603
#7  0x0052afa8 in virtio_scsi_data_plane_handle_cmd (vdev=, vq=0x7c6d7110) at /home/qemu-4.0.0/hw/scsi/virtio-scsi-dataplane.c:59
#8  0x0054d94c in virtio_queue_host_notifier_aio_poll 
(opaque=) at /home/qemu-4.0.0/hw/virtio/virtio.c:2452

assert(blk_get_aio_context(d->conf.blk) == s->ctx) failed.

To avoid assertion failed,  moving the "if" after qdev_simple_device_unplug_cb.

In addition, to avoid another qemu crash below, add aio_disable_external before
qdev_simple_device_unplug_cb, which disable the further processing of external 
clients
when doing qdev_simple_device_unplug_cb.
(gdb) bt
#0  scsi_req_unref (req=0x6802c6f0) at hw/scsi/scsi-bus.c:1283
#1  0x005294a4 in virtio_scsi_handle_cmd_req_submit (req=,
s=) at /home/qemu-4.0.0/hw/scsi/virtio-scsi.c:589
#2  0x0052a2a8 in virtio_scsi_handle_cmd_vq (s=s@entry=0x9c90e90,
vq=vq@entry=0x7c05f110) at /home/qemu-4.0.0/hw/scsi/virtio-scsi.c:625
#3  0x0052afd8 in virtio_scsi_data_plane_handle_cmd (vdev=,
vq=0x7c05f110) at /home/qemu-4.0.0/hw/scsi/virtio-scsi-dataplane.c:60
#4  0x0054d97c in virtio_queue_host_notifier_aio_poll 
(opaque=)
at /home/qemu-4.0.0/hw/virtio/virtio.c:2447
#5  0x009b204c in run_poll_handlers_once (ctx=ctx@entry=0x6efea40,
timeout=timeout@entry=0x7d7f7308) at util/aio-posix.c:521
#6  0x009b2b64 in run_poll_handlers (ctx=ctx@entry=0x6efea40,
max_ns=max_ns@entry=4000, timeout=timeout@entry=0x7d7f7308) at 
util/aio-posix.c:559
#7  0x009b2ca0 in try_poll_mode (ctx=ctx@entry=0x6efea40, 
timeout=0x7d7f7308,
timeout@entry=0x7d7f7348) at util/aio-posix.c:594
#8  0x009b31b8 in aio_poll (ctx=0x6efea40, blocking=blocking@entry=true)
at util/aio-posix.c:636
#9  0x006973cc in iothread_run (opaque=0x6ebd800) at iothread.c:75
#10 0x009b592c in qemu_thread_start (args=0x6efef60) at 
util/qemu-thread-posix.c:502
#11 0x8057f8bc in start_thread () from /lib64/libpthread.so.0
#12 0x804e5f8c in thread_start () from /lib64/libc.so.6
(gdb) p bus
$1 = (SCSIBus *) 0x0

Signed-off-by: Zhengui li 
---
 hw/scsi/virtio-scsi.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/hw/scsi/virtio-scsi.c b/hw/scsi/virtio-scsi.c
index 839f120..79e555f 100644
--- a/hw/scsi/virtio-scsi.c
+++ b/hw/scsi/virtio-scsi.c
@@ -837,13 +837,15 @@ static void virtio_scsi_hotunplug(HotplugHandler 
*hotplug_dev, DeviceState *dev,
 virtio_scsi_release(s);
 }
 
+aio_disable_external(s->ctx);
+qdev_simple_device_unplug_cb(hotplug_dev, dev, errp);
+aio_enable_external(s->ctx);
+
 if (s->ctx) {
 virtio_scsi_acquire(s);
 blk_set_aio_context(sd->conf.blk, qemu_get_aio_context());
 virtio_scsi_release(s);
 }
-
-qdev_simple_device_unplug_cb(hotplug_dev, dev, errp);
 }
 
 static struct SCSIBusInfo virtio_scsi_scsi_info = {
-- 
2.7.2.windows.1





Re: [Qemu-devel] [PATCH] virtio-scsi: fixed virtio_scsi_ctx_check failed when detaching scsi disk

2019-07-21 Thread no-reply
Patchew URL: 
https://patchew.org/QEMU/1563693178-23328-1-git-send-email-lizhen...@huawei.com/



Hi,

This series seems to have some coding style problems. See output below for
more information:

Message-id: 1563693178-23328-1-git-send-email-lizhen...@huawei.com
Type: series
Subject: [Qemu-devel] [PATCH] virtio-scsi: fixed virtio_scsi_ctx_check failed 
when detaching scsi disk

=== TEST SCRIPT BEGIN ===
#!/bin/bash
git rev-parse base > /dev/null || exit 0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
./scripts/checkpatch.pl --mailback base..
=== TEST SCRIPT END ===

From https://github.com/patchew-project/qemu
 * [new tag]   
patchew/1563693178-23328-1-git-send-email-lizhen...@huawei.com -> 
patchew/1563693178-23328-1-git-send-email-lizhen...@huawei.com
Switched to a new branch 'test'
4d13188428 virtio-scsi: fixed virtio_scsi_ctx_check failed when detaching scsi 
disk

=== OUTPUT BEGIN ===
ERROR: Missing Signed-off-by: line(s)

total: 1 errors, 0 warnings, 18 lines checked

Commit 4d131884288e (virtio-scsi: fixed virtio_scsi_ctx_check failed when 
detaching scsi disk) has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
=== OUTPUT END ===

Test command exited with code: 1


The full log is available at
http://patchew.org/logs/1563693178-23328-1-git-send-email-lizhen...@huawei.com/testing.checkpatch/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

Re: [Qemu-devel] Use of TARGET_FMT_plx in hw/tpm/trace-events

2019-07-21 Thread Thomas Huth
On 20/07/2019 11.42, Philippe Mathieu-Daudé wrote:
> On 7/20/19 8:39 AM, Markus Armbruster wrote:
>> Consider hw/tpm/trace-events
>>
>> # tpm_crb.c
>> tpm_crb_mmio_read(uint64_t addr, unsigned size, uint32_t val) "CRB read 
>> 0x" TARGET_FMT_plx " len:%u val: 0x%" PRIx32
>> tpm_crb_mmio_write(uint64_t addr, unsigned size, uint32_t val) "CRB 
>> write 0x" TARGET_FMT_plx " len:%u val: 0x%" PRIx32
>>
>> Format is TARGET_FMT_plx formats a hwaddr, but the parameter type is
>> uint64_t.  They happen to be the same.  Is this kosher?
>>
> 
> Missed when converting from DPRINTF() to trace-events:
> https://git.qemu.org/?p=qemu.git;a=commitdiff;h=ec427498;hp=8cb340c613
> 
> PRIx64 certainly makes sense here.
> 
> Since it is the single use, once updated we can remote this hunk from
> scripts/tracetool/format/log_stap.py:
> 
> if macro == "TARGET_FMT_plx":
> return "%016x"
> 
> I guess remember a thread with Thomas talking about TARGET_FMT_plx but I
> can't find it, maybe I dreamed about it...

That was:

 https://patchwork.kernel.org/patch/10930327/

... I think we should rename it to HWADDR_PRI0x or so.

 Thomas



[Qemu-devel] [PATCH] virtio-scsi: fixed virtio_scsi_ctx_check failed when detaching scsi disk

2019-07-21 Thread l00284672
commit a6f230c move blockbackend back to main AioContext on unplug. It set the 
AioContext of
SCSIDevice to the main AioContex, but s->ctx is still the iothread AioContex(if 
the scsi controller
is configure with iothread). So if there are having in-flight requests during 
unplug, a failing assertion
happend. The bt is below:
(gdb) bt
#0  0x86aacbd0 in raise () from /lib64/libc.so.6
#1  0x86aadf7c in abort () from /lib64/libc.so.6
#2  0x86aa6124 in __assert_fail_base () from /lib64/libc.so.6
#3  0x86aa61a4 in __assert_fail () from /lib64/libc.so.6
#4  0x00529118 in virtio_scsi_ctx_check (d=, 
s=, s=) at 
/home/qemu-4.0.0/hw/scsi/virtio-scsi.c:246
#5  0x00529ec4 in virtio_scsi_handle_cmd_req_prepare (s=0x2779ec00, 
req=0x740397d0) at /home/qemu-4.0.0/hw/scsi/virtio-scsi.c:559
#6  0x0052a228 in virtio_scsi_handle_cmd_vq (s=0x2779ec00, 
vq=0x7c6d7110) at /home/qemu-4.0.0/hw/scsi/virtio-scsi.c:603
#7  0x0052afa8 in virtio_scsi_data_plane_handle_cmd (vdev=, vq=0x7c6d7110) at /home/qemu-4.0.0/hw/scsi/virtio-scsi-dataplane.c:59
#8  0x0054d94c in virtio_queue_host_notifier_aio_poll 
(opaque=) at /home/qemu-4.0.0/hw/virtio/virtio.c:2452

assert(blk_get_aio_context(d->conf.blk) == s->ctx) failed.

To avoid assertion failed,  moving the "if" after qdev_simple_device_unplug_cb.

In addition, to avoid another qemu crash below, add aio_disable_external before
qdev_simple_device_unplug_cb, which disable the further processing of external 
clients
when doing qdev_simple_device_unplug_cb.
(gdb) bt
#0  scsi_req_unref (req=0x6802c6f0) at hw/scsi/scsi-bus.c:1283
#1  0x005294a4 in virtio_scsi_handle_cmd_req_submit (req=,
s=) at /home/qemu-4.0.0/hw/scsi/virtio-scsi.c:589
#2  0x0052a2a8 in virtio_scsi_handle_cmd_vq (s=s@entry=0x9c90e90,
vq=vq@entry=0x7c05f110) at /home/qemu-4.0.0/hw/scsi/virtio-scsi.c:625
#3  0x0052afd8 in virtio_scsi_data_plane_handle_cmd (vdev=,
vq=0x7c05f110) at /home/qemu-4.0.0/hw/scsi/virtio-scsi-dataplane.c:60
#4  0x0054d97c in virtio_queue_host_notifier_aio_poll 
(opaque=)
at /home/qemu-4.0.0/hw/virtio/virtio.c:2447
#5  0x009b204c in run_poll_handlers_once (ctx=ctx@entry=0x6efea40,
timeout=timeout@entry=0x7d7f7308) at util/aio-posix.c:521
#6  0x009b2b64 in run_poll_handlers (ctx=ctx@entry=0x6efea40,
max_ns=max_ns@entry=4000, timeout=timeout@entry=0x7d7f7308) at 
util/aio-posix.c:559
#7  0x009b2ca0 in try_poll_mode (ctx=ctx@entry=0x6efea40, 
timeout=0x7d7f7308,
timeout@entry=0x7d7f7348) at util/aio-posix.c:594
#8  0x009b31b8 in aio_poll (ctx=0x6efea40, blocking=blocking@entry=true)
at util/aio-posix.c:636
#9  0x006973cc in iothread_run (opaque=0x6ebd800) at iothread.c:75
#10 0x009b592c in qemu_thread_start (args=0x6efef60) at 
util/qemu-thread-posix.c:502
#11 0x8057f8bc in start_thread () from /lib64/libpthread.so.0
#12 0x804e5f8c in thread_start () from /lib64/libc.so.6
(gdb) p bus
$1 = (SCSIBus *) 0x0
---
 hw/scsi/virtio-scsi.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/hw/scsi/virtio-scsi.c b/hw/scsi/virtio-scsi.c
index 839f120..79e555f 100644
--- a/hw/scsi/virtio-scsi.c
+++ b/hw/scsi/virtio-scsi.c
@@ -837,13 +837,15 @@ static void virtio_scsi_hotunplug(HotplugHandler 
*hotplug_dev, DeviceState *dev,
 virtio_scsi_release(s);
 }
 
+aio_disable_external(s->ctx);
+qdev_simple_device_unplug_cb(hotplug_dev, dev, errp);
+aio_enable_external(s->ctx);
+
 if (s->ctx) {
 virtio_scsi_acquire(s);
 blk_set_aio_context(sd->conf.blk, qemu_get_aio_context());
 virtio_scsi_release(s);
 }
-
-qdev_simple_device_unplug_cb(hotplug_dev, dev, errp);
 }
 
 static struct SCSIBusInfo virtio_scsi_scsi_info = {
-- 
2.7.2.windows.1





Re: [Qemu-devel] [PATCH v27 8/8] target/avr: Add tests

2019-07-21 Thread Thomas Huth
On 19/07/2019 15.26, Philippe Mathieu-Daudé wrote:
> On 7/19/19 10:26 AM, Michael Rolnik wrote:
[...]
>> diff --git a/tests/boot-serial-test.c b/tests/boot-serial-test.c
>> index 24852d4c7d..73d273b73f 100644
>> --- a/tests/boot-serial-test.c
>> +++ b/tests/boot-serial-test.c
>> @@ -16,6 +16,17 @@
>>  #include "qemu/osdep.h"
>>  #include "libqtest.h"
>>  
>> +static const uint8_t bios_avr[] = {
>> +0x89, 0xe1, /* ldi r24, 0x19   */
>> +0x80, 0x93, 0xc5, 0x00, /* sts 0x00C5, r24 ; set baud rate to 38400 */
> 
> FWIW we can remove the previous two lines, we don't care about the
> baudrate in this test.
> 
>> +0x88, 0xe0, /* ldi r24, 0x08   */
>> +0x80, 0x93, 0xc1, 0x00, /* sts 0x00C1, r24 ; Enable tx */
>> +0x86, 0xe0, /* ldi r24, 0x06   */
>> +0x80, 0x93, 0xc2, 0x00, /* sts 0x00C2, r24 ; Set the data bits to 8 */
>> +0x84, 0xe5, /* ldi r24, 0x54   */
>> +0x80, 0x93, 0xc6, 0x00, /* sts 0x00C6, r24 ; Output 'T' */
>> +};
>> +
>>  static const uint8_t kernel_mcf5208[] = {
>>  0x41, 0xf9, 0xfc, 0x06, 0x00, 0x00, /* lea 0xfc06,%a0 */
>>  0x10, 0x3c, 0x00, 0x54, /* move.b #'T',%d0 */
>> @@ -92,6 +103,7 @@ typedef struct testdef {
>>  
>>  static testdef_t tests[] = {
>>  { "alpha", "clipper", "", "PCI:" },
>> +{ "avr", "sample", "", "T", sizeof(bios_avr), NULL, bios_avr },
>>  { "ppc", "ppce500", "", "U-Boot" },
>>  { "ppc", "40p", "-vga none -boot d", "Trying cd:," },
>>  { "ppc", "g3beige", "", "PowerPC,750" },
>>
> 
> Testing shows:
> 
>   TESTcheck-qtest-avr: tests/boot-serial-test
> qemu-system-avr: Unable to load /tmp/qtest-boot-serial-cOndewD as ELF,
> trying again as raw binary
> 
> I wonder if this might fail Peter's testing, so Cc'ing Thomas.

Such messages are quite a bit anoying during "make check", indeed. Could
you please fence the message with qtest_enabled() ?

 Thanks,
   Thomas