[Qemu-devel] [PATCH v23 4/7] target/avr: Add instruction translation

[Michael Rolnik]

This includes:
- TCG translations for each instruction

Signed-off-by: Michael Rolnik 
---
 target/avr/translate.c | 2888 
 1 file changed, 2888 insertions(+)
 create mode 100644 target/avr/translate.c

diff --git a/target/avr/translate.c b/target/avr/translate.c
new file mode 100644
index 00..951a48067e
--- /dev/null
+++ b/target/avr/translate.c
@@ -0,0 +1,2888 @@
+/*
+ * QEMU AVR CPU
+ *
+ * Copyright (c) 2016 Michael Rolnik
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see
+ * 
+ */
+
+#include "qemu/osdep.h"
+#include "qemu/qemu-print.h"
+#include "tcg/tcg.h"
+#include "cpu.h"
+#include "exec/exec-all.h"
+#include "disas/disas.h"
+#include "tcg-op.h"
+#include "exec/cpu_ldst.h"
+#include "exec/helper-proto.h"
+#include "exec/helper-gen.h"
+#include "exec/log.h"
+#include "exec/gdbstub.h"
+#include "exec/translator.h"
+
+/*
+ *  Define if you want a BREAK instruction translated to a breakpoint
+ *  Active debugging connection is assumed
+ *  This is for
+ *  https://github.com/seharris/qemu-avr-tests/tree/master/instruction-tests
+ *  tests
+ */
+#undef BREAKPOINT_ON_BREAK
+
+static TCGv cpu_pc;
+
+static TCGv cpu_Cf;
+static TCGv cpu_Zf;
+static TCGv cpu_Nf;
+static TCGv cpu_Vf;
+static TCGv cpu_Sf;
+static TCGv cpu_Hf;
+static TCGv cpu_Tf;
+static TCGv cpu_If;
+
+static TCGv cpu_rampD;
+static TCGv cpu_rampX;
+static TCGv cpu_rampY;
+static TCGv cpu_rampZ;
+
+static TCGv cpu_r[NO_CPU_REGISTERS];
+static TCGv cpu_eind;
+static TCGv cpu_sp;
+
+static TCGv cpu_skip;
+
+static const char reg_names[NO_CPU_REGISTERS][8] = {
+"r0",  "r1",  "r2",  "r3",  "r4",  "r5",  "r6",  "r7",
+"r8",  "r9",  "r10", "r11", "r12", "r13", "r14", "r15",
+"r16", "r17", "r18", "r19", "r20", "r21", "r22", "r23",
+"r24", "r25", "r26", "r27", "r28", "r29", "r30", "r31",
+};
+#define REG(x) (cpu_r[x])
+
+enum {
+DISAS_EXIT   = DISAS_TARGET_0,  /* We want return to the cpu main loop.  */
+DISAS_LOOKUP = DISAS_TARGET_1,  /* We have a variable condition exit.  */
+DISAS_CHAIN  = DISAS_TARGET_2,  /* We have a single condition exit.  */
+};
+
+typedef struct DisasContext DisasContext;
+
+/* This is the state at translation time. */
+struct DisasContext {
+TranslationBlock *tb;
+
+CPUAVRState *env;
+CPUState *cs;
+
+target_long npc;
+uint32_t opcode;
+
+/* Routine used to access memory */
+int memidx;
+int bstate;
+int singlestep;
+
+TCGv skip_var0;
+TCGv skip_var1;
+TCGCond skip_cond;
+bool free_skip_var0;
+};
+
+static int to_A(DisasContext *ctx, int indx) { return 16 + (indx % 16); }
+static int to_B(DisasContext *ctx, int indx) { return 16 + (indx % 8); }
+static int to_C(DisasContext *ctx, int indx) { return 24 + (indx % 4) * 2; }
+static int to_D(DisasContext *ctx, int indx) { return (indx % 16) * 2; }
+
+static uint16_t next_word(DisasContext *ctx)
+{
+return cpu_lduw_code(ctx->env, ctx->npc++ * 2);
+}
+
+static int append_16(DisasContext *ctx, int x)
+{
+return x << 16 | next_word(ctx);
+}
+
+static bool decode_insn(DisasContext *ctx, uint16_t insn);
+#include "decode_insn.inc.c"
+
+static bool avr_have_feature(DisasContext *ctx, int feature)
+{
+if (!avr_feature(ctx->env, feature)) {
+gen_helper_unsupported(cpu_env);
+ctx->bstate = DISAS_NORETURN;
+return false;
+}
+return true;
+}
+
+static void gen_goto_tb(DisasContext *ctx, int n, target_ulong dest)
+{
+TranslationBlock *tb = ctx->tb;
+
+if (ctx->singlestep == 0) {
+tcg_gen_goto_tb(n);
+tcg_gen_movi_i32(cpu_pc, dest);
+tcg_gen_exit_tb(tb, n);
+} else {
+tcg_gen_movi_i32(cpu_pc, dest);
+gen_helper_debug(cpu_env);
+tcg_gen_exit_tb(NULL, 0);
+}
+ctx->bstate = DISAS_NORETURN;
+}
+
+#include "exec/gen-icount.h"
+
+static void gen_add_CHf(TCGv R, TCGv Rd, TCGv Rr)
+{
+TCGv t1 = tcg_temp_new_i32();
+TCGv t2 = tcg_temp_new_i32();
+TCGv t3 = tcg_temp_new_i32();
+
+tcg_gen_and_tl(t1, Rd, Rr); /* t1 = Rd & Rr */
+tcg_gen_andc_tl(t2, Rd, R); /* t2 = Rd & ~R */
+tcg_gen_andc_tl(t3, Rr, R); /* t3 = Rr & ~R */
+tcg_gen_or_tl(t1, t1, t2); /* t1 = t1 | t2 | t3 */
+tcg_gen_or_tl(t1, t1, t3);
+
+tcg_gen_shri_tl(cpu_Cf, t1, 7); /* Cf = t1(7) */
+tcg_gen_shri_tl(cpu_Hf, t1, 3); /* Hf = 

[Qemu-devel] [PATCH v23 6/7] target/avr: Add example board configuration

[Michael Rolnik]

From: Sarah Harris 

A simple board setup that configures an AVR CPU to run a given firmware image.
This is all that's useful to implement without peripheral emulation as AVR CPUs 
include a lot of on-board peripherals.

Signed-off-by: Michael Rolnik 
---
 hw/Kconfig   |   1 +
 hw/avr/Kconfig   |   4 +
 hw/avr/Makefile.objs |   1 +
 hw/avr/sample.c  | 217 +++
 4 files changed, 223 insertions(+)
 create mode 100644 hw/avr/Kconfig
 create mode 100644 hw/avr/Makefile.objs
 create mode 100644 hw/avr/sample.c

diff --git a/hw/Kconfig b/hw/Kconfig
index 195f541e50..1f25636855 100644
--- a/hw/Kconfig
+++ b/hw/Kconfig
@@ -42,6 +42,7 @@ source watchdog/Kconfig
 # arch Kconfig
 source arm/Kconfig
 source alpha/Kconfig
+source avr/Kconfig
 source cris/Kconfig
 source hppa/Kconfig
 source i386/Kconfig
diff --git a/hw/avr/Kconfig b/hw/avr/Kconfig
new file mode 100644
index 00..c6ca8fe775
--- /dev/null
+++ b/hw/avr/Kconfig
@@ -0,0 +1,4 @@
+config AVR_SAMPLE
+bool
+select AVR_TIMER16
+select AVR_USART
diff --git a/hw/avr/Makefile.objs b/hw/avr/Makefile.objs
new file mode 100644
index 00..626b7064b3
--- /dev/null
+++ b/hw/avr/Makefile.objs
@@ -0,0 +1 @@
+obj-y += sample.o
diff --git a/hw/avr/sample.c b/hw/avr/sample.c
new file mode 100644
index 00..e4cb548a33
--- /dev/null
+++ b/hw/avr/sample.c
@@ -0,0 +1,217 @@
+/*
+ * QEMU AVR CPU
+ *
+ * Copyright (c) 2016 Michael Rolnik
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see
+ * 
+ */
+
+/*
+ *  NOTE:
+ *  This is not a real AVR board, this is an example!
+ *  The CPU is an approximation of an ATmega2560, but is missing various
+ *  built-in peripherals.
+ *
+ *  This example board loads provided binary file into flash memory and
+ *  executes it from 0x address in the code memory space.
+ *
+ *  Currently used for AVR CPU validation
+ *
+ */
+
+#include "qemu/osdep.h"
+#include "qapi/error.h"
+#include "qemu-common.h"
+#include "cpu.h"
+#include "hw/hw.h"
+#include "sysemu/sysemu.h"
+#include "sysemu/qtest.h"
+#include "ui/console.h"
+#include "hw/boards.h"
+#include "hw/loader.h"
+#include "qemu/error-report.h"
+#include "exec/address-spaces.h"
+#include "include/hw/sysbus.h"
+#include "include/hw/char/avr_usart.h"
+#include "include/hw/timer/avr_timer16.h"
+#include "elf.h"
+
+#define SIZE_FLASH 0x0004
+#define SIZE_SRAM 0x2200
+/*
+ * Size of additional "external" memory, as if the AVR were configured to use
+ * an external RAM chip.
+ * Note that the configuration registers that normally enable this feature are
+ * unimplemented.
+ */
+#define SIZE_EXMEM 0x
+
+/* Offsets of periphals in emulated memory space (i.e. not host addresses)  */
+#define PRR0 0x64
+#define PRR1 0x65
+#define USART_BASE 0xc0
+#define USART_PRR PRR0
+#define USART_PRR_MASK 0b0010
+#define TIMER1_BASE 0x80
+#define TIMER1_IMSK_BASE 0x6f
+#define TIMER1_IFR_BASE 0x36
+#define TIMER1_PRR PRR0
+#define TIMER1_PRR_MASK 0b0100
+
+/* Interrupt numbers used by peripherals */
+#define USART_RXC_IRQ 24
+#define USART_DRE_IRQ 25
+#define USART_TXC_IRQ 26
+
+#define TIMER1_CAPT_IRQ 15
+#define TIMER1_COMPA_IRQ 16
+#define TIMER1_COMPB_IRQ 17
+#define TIMER1_COMPC_IRQ 18
+#define TIMER1_OVF_IRQ 19
+
+typedef struct {
+MachineClass parent;
+} SampleMachineClass;
+
+typedef struct {
+MachineState parent;
+MemoryRegion *ram;
+MemoryRegion *flash;
+AVRUsartState *usart0;
+AVRTimer16State *timer1;
+} SampleMachineState;
+
+#define TYPE_SAMPLE_MACHINE MACHINE_TYPE_NAME("sample")
+
+#define SAMPLE_MACHINE(obj) \
+OBJECT_CHECK(SampleMachineState, obj, TYPE_SAMPLE_MACHINE)
+#define SAMPLE_MACHINE_GET_CLASS(obj) \
+OBJECT_GET_CLASS(SampleMachineClass, obj, TYPE_SAMPLE_MACHINE)
+#define SAMPLE_MACHINE_CLASS(klass) \
+OBJECT_CLASS_CHECK(SampleMachineClass, klass, TYPE_SAMPLE_MACHINE)
+
+static void sample_init(MachineState *machine)
+{
+SampleMachineState *sms = SAMPLE_MACHINE(machine);
+MemoryRegion *system_memory = get_system_memory();
+AVRCPU *cpu;
+const char *firmware = NULL;
+const char *filename;
+int bytes_loaded;
+SysBusDevice *busdev;
+DeviceState *cpudev;
+
+system_memory = get_system_memory();
+sms->ram = g_new(MemoryRegion, 1);
+sms->flash = 

[Qemu-devel] [PATCH] console: fix cell overflow

[Gerd Hoffmann]

Linux terminal behavior (coming from vt100 I think) is somewhat strange
when it comes to line wraps:  When a character is printed to the last
char cell of a line the cursor does NOT jump to the next line but stays
where it is.  The line feed happens when the next character is printed.

So the valid range for the cursor position is not 0 .. width-1 but
0 .. width, where x == width represents the state where the line is
full but the cursor didn't jump to the next line yet.

The code for the 'clear from start of line' control sequence (ESC[1K)
fails to handle this corner case correctly and may call
console_clear_xy() with x == width.  That will incorrectly clear the
first char cell of the next line, or in case the cursor happens to be on
the last line overflow the cell buffer by one character (three bytes).

Add a check to the loop to fix that.

Didn't spot any other places with the same problem.  But it's easy to
miss that corner case, so also allocate one extra cell as precaution, so
in case we have simliar issues lurking elsewhere it at least wouldn't be
a buffer overflow.

Reported-by: Alexander Oleinik 
Signed-off-by: Gerd Hoffmann 
---
 ui/console.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/ui/console.c b/ui/console.c
index eb7e7e0c517a..13d933510cdb 100644
--- a/ui/console.c
+++ b/ui/console.c
@@ -484,7 +484,7 @@ static void text_console_resize(QemuConsole *s)
 if (s->width < w1)
 w1 = s->width;
 
-cells = g_new(TextCell, s->width * s->total_height);
+cells = g_new(TextCell, s->width * s->total_height + 1);
 for(y = 0; y < s->total_height; y++) {
 c = [y * s->width];
 if (w1 > 0) {
@@ -992,7 +992,7 @@ static void console_putchar(QemuConsole *s, int ch)
 break;
 case 1:
 /* clear from beginning of line */
-for (x = 0; x <= s->x; x++) {
+for (x = 0; x <= s->x && x < s->width; x++) {
 console_clear_xy(s, x, s->y);
 }
 break;
-- 
2.18.1

[Qemu-devel] [PATCH v23 1/7] target/avr: Add outward facing interfaces and core CPU logic

[Michael Rolnik]

From: Sarah Harris 

This includes:
- CPU data structures
- object model classes and functions
- migration functions
- GDB hooks

Signed-off-by: Michael Rolnik 
---
 gdb-xml/avr-cpu.xml|  49 
 target/avr/cpu-param.h |  37 +++
 target/avr/cpu.c   | 599 +
 target/avr/cpu.h   | 283 +++
 target/avr/gdbstub.c   |  85 ++
 target/avr/machine.c   | 123 +
 6 files changed, 1176 insertions(+)
 create mode 100644 gdb-xml/avr-cpu.xml
 create mode 100644 target/avr/cpu-param.h
 create mode 100644 target/avr/cpu.c
 create mode 100644 target/avr/cpu.h
 create mode 100644 target/avr/gdbstub.c
 create mode 100644 target/avr/machine.c

diff --git a/gdb-xml/avr-cpu.xml b/gdb-xml/avr-cpu.xml
new file mode 100644
index 00..c4747f5b40
--- /dev/null
+++ b/gdb-xml/avr-cpu.xml
@@ -0,0 +1,49 @@
+
+
+
+
+
+
+
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+
diff --git a/target/avr/cpu-param.h b/target/avr/cpu-param.h
new file mode 100644
index 00..5bbf985726
--- /dev/null
+++ b/target/avr/cpu-param.h
@@ -0,0 +1,37 @@
+/*
+ * QEMU AVR CPU
+ *
+ * Copyright (c) 2016 Michael Rolnik
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see
+ * 
+ */
+
+#ifndef AVR_CPU_PARAM_H
+#define AVR_CPU_PARAM_H 1
+
+#define TARGET_LONG_BITS 32
+/*
+ * TARGET_PAGE_BITS cannot be more than 8 bits because
+ * 1.  all IO registers occupy [0x .. 0x00ff] address range, and they
+ * should be implemented as a device and not memory
+ * 2.  SRAM starts at the address 0x0100
+ */
+#define TARGET_PAGE_BITS 8
+#define TARGET_PHYS_ADDR_SPACE_BITS 24
+#define TARGET_VIRT_ADDR_SPACE_BITS 24
+#define NB_MMU_MODES 2
+
+
+#endif
diff --git a/target/avr/cpu.c b/target/avr/cpu.c
new file mode 100644
index 00..142fe54524
--- /dev/null
+++ b/target/avr/cpu.c
@@ -0,0 +1,599 @@
+/*
+ * QEMU AVR CPU
+ *
+ * Copyright (c) 2016 Michael Rolnik
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see
+ * 
+ */
+
+#include "qemu/osdep.h"
+#include "qemu/qemu-print.h"
+#include "qemu/log.h"
+#include "cpu.h"
+#include "exec/exec-all.h"
+#include "qapi/error.h"
+#include "hw/qdev-properties.h"
+#include "migration/vmstate.h"
+
+static void avr_cpu_set_pc(CPUState *cs, vaddr value)
+{
+AVRCPU *cpu = AVR_CPU(cs);
+
+cpu->env.pc_w = value / 2; /* internally PC points to words */
+}
+
+static bool avr_cpu_has_work(CPUState *cs)
+{
+AVRCPU *cpu = AVR_CPU(cs);
+CPUAVRState *env = >env;
+
+return (cs->interrupt_request & (CPU_INTERRUPT_HARD | CPU_INTERRUPT_RESET))
+&& cpu_interrupts_enabled(env);
+}
+
+static void avr_cpu_synchronize_from_tb(CPUState *cs, TranslationBlock *tb)
+{
+AVRCPU *cpu = AVR_CPU(cs);
+CPUAVRState *env = >env;
+
+env->pc_w = tb->pc / 2; /* internally PC points to words */
+}
+
+static void avr_cpu_reset(CPUState *cs)
+{
+AVRCPU *cpu = AVR_CPU(cs);
+AVRCPUClass *mcc = AVR_CPU_GET_CLASS(cpu);
+CPUAVRState *env = >env;
+
+mcc->parent_reset(cs);
+
+env->pc_w = 0;
+env->sregI = 1;
+env->sregC = 0;
+env->sregZ = 0;
+env->sregN = 0;
+env->sregV = 0;
+env->sregS = 0;
+env->sregH = 0;
+env->sregT = 0;
+
+env->rampD = 0;
+env->rampX = 0;
+env->rampY = 0;
+env->rampZ = 0;
+env->eind = 0;
+env->sp = 0;
+
+env->skip = 0;
+
+memset(env->r, 0, sizeof(env->r));
+
+tlb_flush(cs);
+}
+
+static void avr_cpu_disas_set_info(CPUState *cpu, disassemble_info *info)
+{
+info->mach = bfd_arch_avr;
+info->print_insn = NULL;
+}
+
+static void avr_cpu_realizefn(DeviceState *dev, Error **errp)
+{
+  

[Qemu-devel] [PATCH v23 2/7] target/avr: Add instruction helpers

[Michael Rolnik]

From: Sarah Harris 

Stubs for unimplemented instructions and helpers for instructions that need to 
interact with QEMU.
SPM and WDR are unimplemented because they require emulation of complex 
peripherals.
The implementation of SLEEP is very limited due to the lack of peripherals to 
generate wake interrupts.
Memory access instructions are implemented here because some address ranges 
actually refer to CPU registers.

Signed-off-by: Michael Rolnik 
---
 target/avr/helper.c | 354 
 target/avr/helper.h |  29 
 2 files changed, 383 insertions(+)
 create mode 100644 target/avr/helper.c
 create mode 100644 target/avr/helper.h

diff --git a/target/avr/helper.c b/target/avr/helper.c
new file mode 100644
index 00..4d4eaed5ea
--- /dev/null
+++ b/target/avr/helper.c
@@ -0,0 +1,354 @@
+/*
+ * QEMU AVR CPU
+ *
+ * Copyright (c) 2016 Michael Rolnik
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see
+ * 
+ */
+
+#include "qemu/osdep.h"
+
+#include "cpu.h"
+#include "hw/irq.h"
+#include "hw/sysbus.h"
+#include "sysemu/sysemu.h"
+#include "exec/exec-all.h"
+#include "exec/cpu_ldst.h"
+#include "exec/helper-proto.h"
+#include "exec/ioport.h"
+#include "qemu/host-utils.h"
+#include "qemu/error-report.h"
+
+bool avr_cpu_exec_interrupt(CPUState *cs, int interrupt_request)
+{
+bool ret = false;
+CPUClass *cc = CPU_GET_CLASS(cs);
+AVRCPU *cpu = AVR_CPU(cs);
+CPUAVRState *env = >env;
+
+if (interrupt_request & CPU_INTERRUPT_RESET) {
+if (cpu_interrupts_enabled(env)) {
+cs->exception_index = EXCP_RESET;
+cc->do_interrupt(cs);
+
+cs->interrupt_request &= ~CPU_INTERRUPT_RESET;
+
+ret = true;
+}
+}
+if (interrupt_request & CPU_INTERRUPT_HARD) {
+if (cpu_interrupts_enabled(env) && env->intsrc != 0) {
+int index = ctz32(env->intsrc);
+cs->exception_index = EXCP_INT(index);
+cc->do_interrupt(cs);
+
+env->intsrc &= env->intsrc - 1; /* clear the interrupt */
+cs->interrupt_request &= ~CPU_INTERRUPT_HARD;
+
+ret = true;
+}
+}
+return ret;
+}
+
+void avr_cpu_do_interrupt(CPUState *cs)
+{
+AVRCPU *cpu = AVR_CPU(cs);
+CPUAVRState *env = >env;
+
+uint32_t ret = env->pc_w;
+int vector = 0;
+int size = avr_feature(env, AVR_FEATURE_JMP_CALL) ? 2 : 1;
+int base = 0;
+
+if (cs->exception_index == EXCP_RESET) {
+vector = 0;
+} else if (env->intsrc != 0) {
+vector = ctz32(env->intsrc) + 1;
+}
+
+if (avr_feature(env, AVR_FEATURE_3_BYTE_PC)) {
+cpu_stb_data(env, env->sp--, (ret & 0xff));
+cpu_stb_data(env, env->sp--, (ret & 0x00ff00) >> 8);
+cpu_stb_data(env, env->sp--, (ret & 0xff) >> 16);
+} else if (avr_feature(env, AVR_FEATURE_2_BYTE_PC)) {
+cpu_stb_data(env, env->sp--, (ret & 0xff));
+cpu_stb_data(env, env->sp--, (ret & 0x00ff00) >> 8);
+} else {
+cpu_stb_data(env, env->sp--, (ret & 0xff));
+}
+
+env->pc_w = base + vector * size;
+env->sregI = 0; /* clear Global Interrupt Flag */
+
+cs->exception_index = -1;
+}
+
+int avr_cpu_memory_rw_debug(CPUState *cs, vaddr addr, uint8_t *buf,
+int len, bool is_write)
+{
+return cpu_memory_rw_debug(cs, addr, buf, len, is_write);
+}
+
+hwaddr avr_cpu_get_phys_page_debug(CPUState *cs, vaddr addr)
+{
+return addr; /* I assume 1:1 address correspondance */
+}
+
+int avr_cpu_handle_mmu_fault(
+CPUState *cs, vaddr address, int size, int rw, int mmu_idx)
+{
+/* currently it's assumed that this will never happen */
+cs->exception_index = EXCP_DEBUG;
+cpu_dump_state(cs, stderr, 0);
+return 1;
+}
+
+bool avr_cpu_tlb_fill(CPUState *cs, vaddr address, int size,
+MMUAccessType access_type, int mmu_idx,
+bool probe, uintptr_t retaddr)
+{
+int prot = 0;
+MemTxAttrs attrs = {};
+uint32_t paddr;
+
+address &= TARGET_PAGE_MASK;
+
+if (mmu_idx == MMU_CODE_IDX) {
+/* access to code in flash */
+paddr = OFFSET_CODE + address;
+prot = PAGE_READ | PAGE_EXEC;
+if (paddr + TARGET_PAGE_SIZE > OFFSET_DATA) {
+error_report("execution left flash memory");

[Qemu-devel] [PATCH v23 5/7] target/avr: Add limited support for USART and 16 bit timer peripherals

[Michael Rolnik]

From: Sarah Harris 

These were designed to facilitate testing but should provide enough function to 
be useful in other contexts.
Only a subset of the functions of each peripheral is implemented, mainly due to 
the lack of a standard way to handle electrical connections (like GPIO pins).

Signed-off-by: Michael Rolnik 
---
 hw/char/Kconfig|   3 +
 hw/char/Makefile.objs  |   1 +
 hw/char/avr_usart.c| 316 ++
 hw/timer/Kconfig   |   3 +
 hw/timer/Makefile.objs |   1 +
 hw/timer/avr_timer16.c | 587 +
 include/hw/char/avr_usart.h|  99 ++
 include/hw/timer/avr_timer16.h |  99 ++
 8 files changed, 1109 insertions(+)
 create mode 100644 hw/char/avr_usart.c
 create mode 100644 hw/timer/avr_timer16.c
 create mode 100644 include/hw/char/avr_usart.h
 create mode 100644 include/hw/timer/avr_timer16.h

diff --git a/hw/char/Kconfig b/hw/char/Kconfig
index 40e7a8b8bb..331b20983f 100644
--- a/hw/char/Kconfig
+++ b/hw/char/Kconfig
@@ -46,3 +46,6 @@ config SCLPCONSOLE
 
 config TERMINAL3270
 bool
+
+config AVR_USART
+bool
diff --git a/hw/char/Makefile.objs b/hw/char/Makefile.objs
index 02d8a66925..09ed50f1d0 100644
--- a/hw/char/Makefile.objs
+++ b/hw/char/Makefile.objs
@@ -21,6 +21,7 @@ obj-$(CONFIG_PSERIES) += spapr_vty.o
 obj-$(CONFIG_DIGIC) += digic-uart.o
 obj-$(CONFIG_STM32F2XX_USART) += stm32f2xx_usart.o
 obj-$(CONFIG_RASPI) += bcm2835_aux.o
+obj-$(CONFIG_AVR_USART) += avr_usart.o
 
 common-obj-$(CONFIG_CMSDK_APB_UART) += cmsdk-apb-uart.o
 common-obj-$(CONFIG_ETRAXFS) += etraxfs_ser.o
diff --git a/hw/char/avr_usart.c b/hw/char/avr_usart.c
new file mode 100644
index 00..26c711336b
--- /dev/null
+++ b/hw/char/avr_usart.c
@@ -0,0 +1,316 @@
+/*
+ * AVR USART
+ *
+ * Copyright (c) 2018 University of Kent
+ * Author: Sarah Harris
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include "qemu/osdep.h"
+#include "hw/char/avr_usart.h"
+#include "qemu/log.h"
+
+static int avr_usart_can_receive(void *opaque)
+{
+AVRUsartState *usart = opaque;
+
+if (usart->data_valid || !(usart->csrb & USART_CSRB_RXEN)) {
+return 0;
+}
+return 1;
+}
+
+static void avr_usart_receive(void *opaque, const uint8_t *buffer, int size)
+{
+AVRUsartState *usart = opaque;
+assert(size == 1);
+assert(!usart->data_valid);
+usart->data = buffer[0];
+usart->data_valid = true;
+usart->csra |= USART_CSRA_RXC;
+if (usart->csrb & USART_CSRB_RXCIE) {
+qemu_set_irq(usart->rxc_irq, 1);
+}
+}
+
+static void update_char_mask(AVRUsartState *usart)
+{
+uint8_t mode = ((usart->csrc & USART_CSRC_CSZ0) ? 1 : 0) |
+((usart->csrc & USART_CSRC_CSZ1) ? 2 : 0) |
+((usart->csrb & USART_CSRB_CSZ2) ? 4 : 0);
+switch (mode) {
+case 0:
+usart->char_mask = 0b1;
+break;
+case 1:
+usart->char_mask = 0b11;
+break;
+case 2:
+usart->char_mask = 0b111;
+break;
+case 3:
+usart->char_mask = 0b;
+break;
+case 4:
+/* Fallthrough. */
+case 5:
+/* Fallthrough. */
+case 6:
+qemu_log_mask(
+LOG_GUEST_ERROR,
+"%s: Reserved character size 0x%x\n",
+__func__,
+mode);
+break;
+case 7:
+qemu_log_mask(
+LOG_GUEST_ERROR,
+"%s: Nine bit character size not supported (forcing eight)\n",
+__func__);
+usart->char_mask = 0b;
+break;
+default:
+assert(0);
+}
+}
+
+static void avr_usart_reset(DeviceState *dev)
+{
+AVRUsartState *usart = AVR_USART(dev);
+usart->data_valid = false;
+usart->csra = 0b0010;
+usart->csrb = 0b;
+usart->csrc = 0b0110;
+usart->brrl = 0;
+usart->brrh = 0;
+update_char_mask(usart);
+

[Qemu-devel] [PATCH v23 7/7] target/avr: Register AVR support with the rest of QEMU, the build system, and the MAINTAINERS file

[Michael Rolnik]

From: Sarah Harris 

Signed-off-by: Michael Rolnik 
---
 MAINTAINERS |  6 ++
 arch_init.c |  2 ++
 configure   |  7 +++
 default-configs/avr-softmmu.mak |  5 +
 include/disas/dis-asm.h |  6 ++
 include/sysemu/arch_init.h  |  1 +
 qapi/common.json|  3 ++-
 target/avr/Makefile.objs| 33 +
 tests/machine-none-test.c   |  1 +
 9 files changed, 63 insertions(+), 1 deletion(-)
 create mode 100644 default-configs/avr-softmmu.mak
 create mode 100644 target/avr/Makefile.objs

diff --git a/MAINTAINERS b/MAINTAINERS
index cad58b9487..c2ad82beb9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -163,6 +163,12 @@ S: Maintained
 F: hw/arm/smmu*
 F: include/hw/arm/smmu*
 
+AVR TCG CPUs
+M: Michael Rolnik 
+S: Maintained
+F: target/avr/
+F: hw/avr/
+
 CRIS TCG CPUs
 M: Edgar E. Iglesias 
 S: Maintained
diff --git a/arch_init.c b/arch_init.c
index 74b0708634..413ad7acfd 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -85,6 +85,8 @@ int graphic_depth = 32;
 #define QEMU_ARCH QEMU_ARCH_UNICORE32
 #elif defined(TARGET_XTENSA)
 #define QEMU_ARCH QEMU_ARCH_XTENSA
+#elif defined(TARGET_AVR)
+#define QEMU_ARCH QEMU_ARCH_AVR
 #endif
 
 const uint32_t arch_type = QEMU_ARCH;
diff --git a/configure b/configure
index b091b82cb3..715050a743 100755
--- a/configure
+++ b/configure
@@ -7499,6 +7499,10 @@ case "$target_name" in
 target_compiler=$cross_cc_aarch64
 eval "target_compiler_cflags=\$cross_cc_cflags_${target_name}"
   ;;
+  avr)
+   gdb_xml_files="avr-cpu.xml"
+target_compiler=$cross_cc_avr
+  ;;
   cris)
 target_compiler=$cross_cc_cris
   ;;
@@ -7776,6 +7780,9 @@ for i in $ARCH $TARGET_BASE_ARCH ; do
   disas_config "ARM_A64"
 fi
   ;;
+  avr)
+disas_config "AVR"
+  ;;
   cris)
 disas_config "CRIS"
   ;;
diff --git a/default-configs/avr-softmmu.mak b/default-configs/avr-softmmu.mak
new file mode 100644
index 00..d1e1c28118
--- /dev/null
+++ b/default-configs/avr-softmmu.mak
@@ -0,0 +1,5 @@
+# Default configuration for avr-softmmu
+
+# Boards:
+#
+CONFIG_AVR_SAMPLE=y
diff --git a/include/disas/dis-asm.h b/include/disas/dis-asm.h
index e9c7dd8eb4..8bedce17ac 100644
--- a/include/disas/dis-asm.h
+++ b/include/disas/dis-asm.h
@@ -211,6 +211,12 @@ enum bfd_architecture
 #define bfd_mach_m32r  0  /* backwards compatibility */
   bfd_arch_mn10200,/* Matsushita MN10200 */
   bfd_arch_mn10300,/* Matsushita MN10300 */
+  bfd_arch_avr,   /* Atmel AVR microcontrollers.  */
+#define bfd_mach_avr1  1
+#define bfd_mach_avr2  2
+#define bfd_mach_avr3  3
+#define bfd_mach_avr4  4
+#define bfd_mach_avr5  5
   bfd_arch_cris,   /* Axis CRIS */
 #define bfd_mach_cris_v0_v10   255
 #define bfd_mach_cris_v32  32
diff --git a/include/sysemu/arch_init.h b/include/sysemu/arch_init.h
index 10cbafe970..aff57bfe61 100644
--- a/include/sysemu/arch_init.h
+++ b/include/sysemu/arch_init.h
@@ -25,6 +25,7 @@ enum {
 QEMU_ARCH_NIOS2 = (1 << 17),
 QEMU_ARCH_HPPA = (1 << 18),
 QEMU_ARCH_RISCV = (1 << 19),
+QEMU_ARCH_AVR = (1 << 20),
 };
 
 extern const uint32_t arch_type;
diff --git a/qapi/common.json b/qapi/common.json
index 99d313ef3b..53f5018b9c 100644
--- a/qapi/common.json
+++ b/qapi/common.json
@@ -183,11 +183,12 @@
 #is true even for "qemu-system-x86_64".
 #
 # ppcemb: dropped in 3.1
+# avr: since 4.1
 #
 # Since: 3.0
 ##
 { 'enum' : 'SysEmuTarget',
-  'data' : [ 'aarch64', 'alpha', 'arm', 'cris', 'hppa', 'i386', 'lm32',
+  'data' : [ 'aarch64', 'alpha', 'arm', 'avr', 'cris', 'hppa', 'i386', 'lm32',
  'm68k', 'microblaze', 'microblazeel', 'mips', 'mips64',
  'mips64el', 'mipsel', 'moxie', 'nios2', 'or1k', 'ppc',
  'ppc64', 'riscv32', 'riscv64', 's390x', 'sh4',
diff --git a/target/avr/Makefile.objs b/target/avr/Makefile.objs
new file mode 100644
index 00..1034d87525
--- /dev/null
+++ b/target/avr/Makefile.objs
@@ -0,0 +1,33 @@
+#
+#  QEMU AVR CPU
+#
+#  Copyright (c) 2016 Michael Rolnik
+#
+#  This library is free software; you can redistribute it and/or
+#  modify it under the terms of the GNU Lesser General Public
+#  License as published by the Free Software Foundation; either
+#  version 2.1 of the License, or (at your option) any later version.
+#
+#  This library is distributed in the hope that it will be useful,
+#  but WITHOUT ANY WARRANTY; without even the implied warranty of
+#  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+#  Lesser General Public License for more details.
+#
+#  You should have received a copy of the GNU Lesser General Public
+#  License along with this library; if not, see
+#  
+#
+
+DECODETREE = $(SRC_PATH)/scripts/decodetree.py
+decode-y = $(SRC_PATH)/target/avr/insn.decode
+
+target/avr/decode_insn.inc.c: $(decode-y) $(DECODETREE)
+   $(call 

[Qemu-devel] [PATCH v23 0/7] QEMU AVR 8 bit cores

[Michael Rolnik]

This series of patches adds 8bit AVR cores to QEMU.
All instruction, except BREAK/DES/SPM/SPMX, are implemented. Not fully tested 
yet.
However I was able to execute simple code with functions. e.g fibonacci 
calculation.
This series of patches include a non real, sample board.
No fuses support yet. PC is set to 0 at reset.

the patches include the following
1. just a basic 8bit AVR CPU, without instruction decoding or translation
2. CPU features which allow define the following 8bit AVR cores
 avr1
 avr2 avr25
 avr3 avr31 avr35
 avr4
 avr5 avr51
 avr6
 xmega2 xmega4 xmega5 xmega6 xmega7
3. a definition of sample machine with SRAM, FLASH and CPU which allows to 
execute simple code
4. encoding for all AVR instructions
5. interrupt handling
6. helpers for IN, OUT, SLEEP, WBR & unsupported instructions
7. a decoder which given an opcode decides what istruction it is
8. translation of AVR instruction into TCG
9. all features together

changes since v3
1. rampD/X/Y/Z registers are encoded as 0x00ff (instead of 0x00ff) for 
faster address manipulaton
2. ffs changed to ctz32
3. duplicate code removed at avr_cpu_do_interrupt
4. using andc instead of not + and
5. fixing V flag calculation in varios instructions
6. freeing local variables in PUSH
7. tcg_const_local_i32 -> tcg_const_i32
8. using sextract32 instead of my implementation
9. fixing BLD instruction
10.xor(r) instead of 0xff - r at COM
11.fixing MULS/MULSU not to modify inputs' content
12.using SUB for NEG
13.fixing tcg_gen_qemu_ld/st call in XCH

changes since v4
1. target is now defined as big endian in order to optimize push_ret/pop_ret
2. all style warnings are fixed
3. adding cpu_set/get_sreg functions
4. simplifying gen_goto_tb as there is no real paging
5. env->pc -> env->pc_w
6. making flag dump more compact
7. more spacing
8. renaming CODE/DATA_INDEX -> MMU_CODE/DATA_IDX
9. removing avr_set_feature
10. SPL/SPH set bug fix
11. switching stb_phys to cpu_stb_data
12. cleaning up avr_decode
13. saving sreg, rampD/X/Y/Z, eind in HW format (savevm)
14. saving CPU features (savevm)

changes since v5
1. BLD bug fix
2. decoder generator is added

chages since v6
1. using cpu_get_sreg/cpu_set_sreg in 
avr_cpu_gdb_read_register/avr_cpu_gdb_write_register
2. configure the target as little endian because otherwise GDB does not work
3. fixing and testing gen_push_ret/gen_pop_ret

changes since v7
1. folding back v6 
2. logging at helper_outb and helper_inb are done for non supported yet 
registers only
3. MAINTAINERS updated

changes since v8
1. removing hw/avr from hw/Makefile.obj as it should not be built for all
2. making linux compilable
3. testing on
a. Mac, Apple LLVM version 7.0.0
b. Ubuntu 12.04, gcc 4.9.2
c. Fedora 23, gcc 5.3.1
4. folding back some patches
5. translation bug fixes for ORI, CPI, XOR instructions
6. propper handling of cpu register writes though memory

changes since v9
1. removing forward declarations of static functions
2. disabling debug prints
3. switching to case range instead of if else if ...
4. LD/ST IN/OUT accessing CPU maintainder registers are not routed to any device
5. commenst about sample board and sample IO device added
6. sample board description is more descriptive now
7. memory_region_allocate_system_memory is used to create RAM
8. now there are helper_fullrd & helper_fullwr when LD/ST try to access 
registers

changes since v10
1. movig back fullwr & fullrd into the commit where outb and inb were introduced
2. changing tlb_fill function signature
3. adding empty line between functions
4. adding newline on the last line of the file
5. using tb->flags to generae full access ST/LD instructions
6. fixing SBRC bug
7. folding back 10th commit
8. whenever a new file is introduced it's added to Makefile.objs

changes since v11
1. updating to v2.7.0-rc
2. removing assignment to env->fullacc from gen_intermediate_code

changes since v12
1. fixing spacing
2. fixing get/put_segment functions
3. removing target-avr/machine.h file
4. VMSTATE_SINGLE_TEST -> VMSTATE_SINGLE
5. comment spelling
6. removing hw/avr/sample_io.c
7. char const* -> const char*
8. proper ram allocation
9. fixing breakpoint functionality.
10.env1 -> env
11.fixing avr_cpu_gdb_write_register & avr_cpu_gdb_read_register functions
12.any cpu is removed
12.feature bits are not saved into vm state

changes since v13
1. rebasing to v2.7.0-rc1

changes since v14
1. I made self review with git gui tool. (I did not know such a thing exists)
2. removing all double/tripple spaces
3. removing comment reference to SampleIO
4. folding back some changes, so there is not deleted lines in my code
5. moving avr configuration, within configure file, before chris

changes since v15
1. removing IO registers cache from CPU
2. implementing CBI/SBI as read(helper_inb), modify, write(helper_outb)
3. implementing CBIC/SBIC as read(helper_inb), check, branch
4. adding missing tcg_temp_free_i32 for tcg_const_i32

changes since v16
1. 

[Qemu-devel] [PATCH v23 3/7] target/avr: Add instruction decoding

[Michael Rolnik]

This includes:
- encoding of all 16 bit instructions
- encoding of all 32 bit instructions

Signed-off-by: Michael Rolnik 
---
 target/avr/insn.decode | 175 +
 1 file changed, 175 insertions(+)
 create mode 100644 target/avr/insn.decode

diff --git a/target/avr/insn.decode b/target/avr/insn.decode
new file mode 100644
index 00..6b387762c6
--- /dev/null
+++ b/target/avr/insn.decode
@@ -0,0 +1,175 @@
+#
+#   A = [16 .. 31]
+#   B = [16 .. 23]
+#   C = [24, 26, 28, 30]
+#   D = [0, 2, 4, 6, 8, .. 30]
+
+%rd 4:5
+%rr 9:1 0:4
+
+_rr  rd rr
+_imm rd imm
+
+@op_rd_rr    .. . . _rr  rd=%rd rr=%rr
+ADD  11 . . @op_rd_rr
+ADC 0001 11 . . @op_rd_rr
+AND 0010 00 . . @op_rd_rr
+CP  0001 01 . . @op_rd_rr
+CPC  01 . . @op_rd_rr
+CPSE0001 00 . . @op_rd_rr
+EOR 0010 01 . . @op_rd_rr
+MOV 0010 11 . . @op_rd_rr
+MUL 1001 11 . . @op_rd_rr
+OR  0010 10 . . @op_rd_rr
+SBC  10 . . @op_rd_rr
+SUB 0001 10 . . @op_rd_rr
+
+
+%rd_c   4:2 !function=to_C
+%imm6   6:2 0:4
+
+@op_rd_imm6   .. .. _imm rd=%rd_c imm=%imm6
+ADIW1001 0110 .. .. @op_rd_imm6
+SBIW1001 0111 .. .. @op_rd_imm6
+
+
+%rd_a   4:4 !function=to_A
+%rr_a   0:4 !function=to_A
+%rd_d   4:4 !function=to_D
+%rr_d   0:4 !function=to_D
+%imm8   8:4 0:4
+
+@op_rd_imm8     _imm rd=%rd_a imm=%imm8
+ANDI0111    @op_rd_imm8
+CPI 0011    @op_rd_imm8
+LDI 1110    @op_rd_imm8
+ORI 0110    @op_rd_imm8
+SBCI0100    @op_rd_imm8
+SUBI0101    @op_rd_imm8
+
+
+@op_rd   ... rd:5 
+ASR 1001 010 . 0101 @op_rd
+COM 1001 010 .  @op_rd
+DEC 1001 010 . 1010 @op_rd
+ELPM2   1001 000 . 0110 @op_rd
+ELPMX   1001 000 . 0111 @op_rd
+INC 1001 010 . 0011 @op_rd
+LDX11001 000 . 1100 @op_rd
+LDX21001 000 . 1101 @op_rd
+LDX31001 000 . 1110 @op_rd
+LDY21001 000 . 1001 @op_rd
+LDY31001 000 . 1010 @op_rd
+LDZ21001 000 . 0001 @op_rd
+LDZ31001 000 . 0010 @op_rd
+LPM21001 000 . 0100 @op_rd
+LPMX1001 000 . 0101 @op_rd
+LSR 1001 010 . 0110 @op_rd
+NEG 1001 010 . 0001 @op_rd
+POP 1001 000 .  @op_rd
+PUSH1001 001 .  @op_rd
+ROR 1001 010 . 0111 @op_rd
+STY21001 001 . 1001 @op_rd
+STY31001 001 . 1010 @op_rd
+STZ21001 001 . 0001 @op_rd
+STZ31001 001 . 0010 @op_rd
+SWAP1001 010 . 0010 @op_rd
+
+
+@op_bit   . bit:3 
+BCLR1001 0100 1 ... 1000@op_bit
+BSET1001 0100 0 ... 1000@op_bit
+
+
+@op_rd_bit   ... rd:5 . bit:3
+BLD  100 . 0 ...@op_rd_bit
+BST  101 . 0 ...@op_rd_bit
+
+
+@op_bit_imm  .. imm:s7 bit:3
+BRBC 01 ... ... @op_bit_imm
+BRBS 00 ... ... @op_bit_imm
+
+
+BREAK   1001 0101 1001 1000
+EICALL  1001 0101 0001 1001
+EIJMP   1001 0100 0001 1001
+ELPM1   1001 0101 1101 1000
+ICALL   1001 0101  1001
+IJMP1001 0100  1001
+LPM11001 0101 1100 1000
+NOP    
+RET 1001 0101  1000
+RETI1001 0101 0001 1000
+SLEEP   1001 0101 1000 1000
+SPM 1001 0101 1110 1000
+SPMX1001 0101  1000
+WDR 1001 0101 1010 1000
+
+
+@op_reg_bit   reg:5 bit:3
+CBI 1001 1000 . ... @op_reg_bit
+SBI 1001 1010 . ... @op_reg_bit
+SBIC1001 1001 . ... @op_reg_bit
+SBIS1001 1011 . ... @op_reg_bit
+
+
+DES 1001 0100 imm:4 1011
+
+
+%rd_b   4:3   

[Qemu-devel] [Bug 1834399] [NEW] AArch64: branch out of range

[Kai]

Public bug reported:

I build lib32-qemu which is a multilib variant for mips o32 on project
Yocto with qemumips64. It finally runs command and fails:


mips-wrsmllib32-linux-gcc  -meb -mabi=32 -mhard-float -fstack-protector-strong  
 -Wformat -Wformat-security -Werror=format-security 
--sysroot=/mnt/docker/LIN1019-1459-ubuntu1604/tmp-glibc/work/mips-wrsmllib32-linux/lib32-qemu/4.0.0-r0/lib32-recipe-sysroot
 
-I/mnt/docker/LIN1019-1459-ubuntu1604/tmp-glibc/work/mips-wrsmllib32-linux/lib32-qemu/4.0.0-r0/lib32-recipe-sysroot/usr/include/pixman-1
 
-I/mnt/docker/LIN1019-1459-ubuntu1604/tmp-glibc/work/mips-wrsmllib32-linux/lib32-qemu/4.0.0-r0/qemu-4.0.0/dtc/libfdt
 -pthread 
-I/mnt/docker/LIN1019-1459-ubuntu1604/tmp-glibc/work/mips-wrsmllib32-linux/lib32-qemu/4.0.0-r0/lib32-recipe-sysroot/usr/include/glib-2.0
 
-I/mnt/docker/LIN1019-1459-ubuntu1604/tmp-glibc/work/mips-wrsmllib32-linux/lib32-qemu/4.0.0-r0/lib32-recipe-sysroot/usr/lib/glib-2.0/include
-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Og -g 
-I/mnt/docker/LIN1019-1459-ubuntu1604/tmp-glibc/work/mips-wrsmllib32-linux/lib32-qemu/4.0.0-r0/qemu-4.0.0/capstone/include
 
-I/mnt/docker/LIN1019-1459-ubuntu1604/tmp-glibc/work/mips-wrsmllib32-linux/lib32-qemu/4.0.0-r0/qemu-4.0.0/tests
 
-DCAPSTONE_USE_SYS_DYN_MEM -DCAPSTONE_HAS_ARM -DCAPSTONE_HAS_ARM64 
-DCAPSTONE_HAS_POWERPC -DCAPSTONE_HAS_X86
-c arch/AArch64/AArch64InstPrinter.c -o 
/mnt/docker/LIN1019-1459-ubuntu1604/tmp-glibc/work/mips-wrsmllib32-linux/lib32-qemu/4.0.0-r0/build/capstone/obj/arch/AArch64/AArch64InstPrinter.o


And error messages:

{standard input}: Assembler messages:
{standard input}:38045: Error: branch out of range
{standard input}:38269: Error: branch out of range
{standard input}:38493: Error: branch out of range
{standard input}:38717: Error: branch out of range
{standard input}:38941: Error: branch out of range
{standard input}:39165: Error: branch out of range
{standard input}:39389: Error: branch out of range
{standard input}:39613: Error: branch out of range
{standard input}:39728: Error: branch out of range
{standard input}:39990: Error: branch out of range
{standard input}:40252: Error: branch out of range
{standard input}:40514: Error: branch out of range
{standard input}:40776: Error: branch out of range
{standard input}:41038: Error: branch out of range


The gcc version is 9.1. I have verified that gcc 8.3 works. And there is no 
error when remove option '-Og' with gcc 9.1.

I am not sure whether it is a defect of gcc 9.1 or capstone. Should it
be fixed in capstone? Thanks.

** Affects: capstone
 Importance: Undecided
 Status: New

** Project changed: qemu => capstone

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

Title:
  AArch64: branch out of range

Status in Capstone:
  New

Bug description:
  I build lib32-qemu which is a multilib variant for mips o32 on project
  Yocto with qemumips64. It finally runs command and fails:

  
  mips-wrsmllib32-linux-gcc  -meb -mabi=32 -mhard-float 
-fstack-protector-strong   -Wformat -Wformat-security -Werror=format-security 
--sysroot=/mnt/docker/LIN1019-1459-ubuntu1604/tmp-glibc/work/mips-wrsmllib32-linux/lib32-qemu/4.0.0-r0/lib32-recipe-sysroot
 
  
-I/mnt/docker/LIN1019-1459-ubuntu1604/tmp-glibc/work/mips-wrsmllib32-linux/lib32-qemu/4.0.0-r0/lib32-recipe-sysroot/usr/include/pixman-1
 
-I/mnt/docker/LIN1019-1459-ubuntu1604/tmp-glibc/work/mips-wrsmllib32-linux/lib32-qemu/4.0.0-r0/qemu-4.0.0/dtc/libfdt
 -pthread 
-I/mnt/docker/LIN1019-1459-ubuntu1604/tmp-glibc/work/mips-wrsmllib32-linux/lib32-qemu/4.0.0-r0/lib32-recipe-sysroot/usr/include/glib-2.0
 
-I/mnt/docker/LIN1019-1459-ubuntu1604/tmp-glibc/work/mips-wrsmllib32-linux/lib32-qemu/4.0.0-r0/lib32-recipe-sysroot/usr/lib/glib-2.0/include
  -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Og -g 
  
-I/mnt/docker/LIN1019-1459-ubuntu1604/tmp-glibc/work/mips-wrsmllib32-linux/lib32-qemu/4.0.0-r0/qemu-4.0.0/capstone/include
 
-I/mnt/docker/LIN1019-1459-ubuntu1604/tmp-glibc/work/mips-wrsmllib32-linux/lib32-qemu/4.0.0-r0/qemu-4.0.0/tests
 
  -DCAPSTONE_USE_SYS_DYN_MEM -DCAPSTONE_HAS_ARM -DCAPSTONE_HAS_ARM64 
-DCAPSTONE_HAS_POWERPC -DCAPSTONE_HAS_X86
  -c arch/AArch64/AArch64InstPrinter.c -o 
/mnt/docker/LIN1019-1459-ubuntu1604/tmp-glibc/work/mips-wrsmllib32-linux/lib32-qemu/4.0.0-r0/build/capstone/obj/arch/AArch64/AArch64InstPrinter.o


  And error messages:

  {standard input}: Assembler messages:
  {standard input}:38045: Error: branch out of range
  {standard input}:38269: Error: branch out of range
  {standard input}:38493: Error: branch out of range
  {standard input}:38717: Error: branch out of range
  {standard input}:38941: Error: branch out of range
  {standard input}:39165: Error: branch out of range
  {standard input}:39389: Error: branch out of range
  {standard input}:39613: Error: branch out of range
  {standard input}:39728: Error: branch out 

Re: [Qemu-devel] [PATCH v4 1/5] virtio: add "use-started" property

[Yongji Xie]

On Wed, 26 Jun 2019 at 18:18, Greg Kurz  wrote:
>
> On Wed, 26 Jun 2019 10:31:26 +0800
> elohi...@gmail.com wrote:
>
> > From: Xie Yongji 
> >
> > In order to avoid migration issues, we introduce a "use-started"
> > property to the base virtio device to indicate whether use
> > "started" flag or not. This property will be true by default and
> > set to false when machine type <= 4.0.
> >
> > Suggested-by: Greg Kurz 
> > Signed-off-by: Xie Yongji 
> > ---
>
> LGTM,
>
> Reviewed-by: Greg Kurz 
>
> This fixes the backward migration breakage I was observing.
>
> Tested-by: Greg Kurz 
>

Thanks for the testing.

Re: [Qemu-devel] [PATCH v4 0/5] virtio: fix some issues of "started" and "start_on_kick" flag

[Yongji Xie]

On Wed, 26 Jun 2019 at 18:43, Laurent Vivier  wrote:
>
> On 26/06/2019 04:31, elohi...@gmail.com wrote:
> > From: Xie Yongji 
>
> Could you use the same address to send the series?
> Or may be you need to add a Signed-off-by with your name and this address?
>
> I don't know what is the rule when someone send a patch with a different
> address than the author one but he is the same person (it's not obvious
> in this case).
>

Sorry for that, this two emails are both mine. The gmail is my
personal email, and I usually use it for the community works.

Thanks,
Yongji

Re: [Qemu-devel] [PATCH v3 0/4] Clean ups in net/net.c

[Jason Wang]

On 2019/5/17 下午9:47, Stefano Garzarella wrote:

This series contains some clean ups in net/net.c

The patch 1 solves an assertion failure when ipv6-prefixlen is not a number,

Following the Markus' advice, I modified the parsing of IPv6 prefix
(patch 2) and IPv4 host:port (patch 3). Then I removed the get_str_sep()
function (patch 4) because it is no longer used.

v3:
  - Patch 2:
- fix indentation [Markus]
- move substrings at the function level, and call g_strfreev(substrings)
  at the end of the function [Markus]
  - add Markus' R-b

v2: https://www.mail-archive.com/qemu-devel@nongnu.org/msg615866.html
v1: https://www.mail-archive.com/qemu-devel@nongnu.org/msg614561.html

Stefano Garzarella (4):
   net: fix assertion failure when ipv6-prefixlen is not a number
   net: avoid using variable length array in net_client_init()
   net: use g_strsplit() for parsing host address and port
   net: remove unused get_str_sep() function

  net/net.c | 99 +++
  1 file changed, 49 insertions(+), 50 deletions(-)



Applied.

Thanks

[Qemu-devel] [PATCH 1/3] migration/postcopy: the valid condition is one less then end

[Wei Yang]

If one equals end, it means we have gone through the whole bitmap.

Use a more restrict check to skip a unnecessary condition.

Signed-off-by: Wei Yang 
---
 migration/ram.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/migration/ram.c b/migration/ram.c
index 908517fc2b..b78169e811 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -2777,7 +2777,7 @@ static int postcopy_send_discard_bm_ram(MigrationState 
*ms,
 for (current = 0; current < end; ) {
 unsigned long one = find_next_bit(unsentmap, end, current);
 
-if (one <= end) {
+if (one < end) {
 unsigned long zero = find_next_zero_bit(unsentmap, end, one + 1);
 unsigned long discard_length;
 
-- 
2.19.1

[Qemu-devel] [PATCH 2/3] migration/postcopy: break the loop when there is no more page to discard

[Wei Yang]

When one is equal or bigger then end, it means there is no page to
discard. Just break the loop in this case instead of processing it.

No functional change, just refactor it a little.

Signed-off-by: Wei Yang 
---
 migration/ram.c | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/migration/ram.c b/migration/ram.c
index b78169e811..b41b58ee54 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -2776,23 +2776,23 @@ static int postcopy_send_discard_bm_ram(MigrationState 
*ms,
 
 for (current = 0; current < end; ) {
 unsigned long one = find_next_bit(unsentmap, end, current);
+unsigned long zero, discard_length;
 
-if (one < end) {
-unsigned long zero = find_next_zero_bit(unsentmap, end, one + 1);
-unsigned long discard_length;
+if (one >= end) {
+break;
+}
 
-if (zero >= end) {
-discard_length = end - one;
-} else {
-discard_length = zero - one;
-}
-if (discard_length) {
-postcopy_discard_send_range(ms, pds, one, discard_length);
-}
-current = one + discard_length;
+zero = find_next_zero_bit(unsentmap, end, one + 1);
+
+if (zero >= end) {
+discard_length = end - one;
 } else {
-current = one;
+discard_length = zero - one;
+}
+if (discard_length) {
+postcopy_discard_send_range(ms, pds, one, discard_length);
 }
+current = one + discard_length;
 }
 
 return 0;
-- 
2.19.1

[Qemu-devel] [PATCH 3/3] migration/postcopy: discard_length must not be 0

[Wei Yang]

Since we break the loop when there is no more page to discard, we are
sure the following process would find some page to discard.

It is not necessary to check it again.

Signed-off-by: Wei Yang 
---
 migration/ram.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/migration/ram.c b/migration/ram.c
index b41b58ee54..246efe6939 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -2789,9 +2789,7 @@ static int postcopy_send_discard_bm_ram(MigrationState 
*ms,
 } else {
 discard_length = zero - one;
 }
-if (discard_length) {
-postcopy_discard_send_range(ms, pds, one, discard_length);
-}
+postcopy_discard_send_range(ms, pds, one, discard_length);
 current = one + discard_length;
 }
 
-- 
2.19.1

[Qemu-devel] [PATCH 0/3] migration/postcopy: cleanup function postcopy_send_discard_bm_ram

[Wei Yang]

Some cleanup of function postcopy_send_discard_bm_ram:

* use a more restrict check for discard page
* break the loop when no more page to discard
* it is for sure discard_length is not 0

No functional change.

Wei Yang (3):
  migration/postcopy: the valid condition is one less then end
  migration/postcopy: break the loop when there is no more page to
discard
  migration/postcopy: discard_length must not be 0

 migration/ram.c | 24 +++-
 1 file changed, 11 insertions(+), 13 deletions(-)

-- 
2.19.1

Re: [Qemu-devel] [PATCH v5 0/5] network announce; interface selection & IDs

[Jason Wang]

On 2019/6/21 上午2:47, Dr. David Alan Gilbert (git) wrote:

From: "Dr. David Alan Gilbert" 

Up until now, the 'announce' feature has mainly been used
for migration where we announce on all interfaces.  Another
use for 'announce' is in cases of network topology changes.

Since network topology changes may only affect a subset
of the interfaces, we add an 'interface list' to announce
to restrict the announcment to the interfaces we're interested
in.

Multiple topology changes might happen in close succession,
so we allow multiple timers, each with their own parameters
(including the interface list).

Signed-off-by: Dr. David Alan Gilbert 

v5
   Minor review fixes [Jason]

Dr. David Alan Gilbert (5):
   net/announce: Allow optional list of interfaces
   net/announce: Add HMP optional interface list
   net/announce: Add optional ID
   net/announce: Add HMP optional ID
   net/announce: Expand test for stopping self announce

  hmp-commands.hx |  7 +++-
  hw/net/virtio-net.c |  4 +-
  include/net/announce.h  |  8 +++-
  monitor/hmp-cmds.c  | 41 ++-
  net/announce.c  | 89 +++--
  net/trace-events|  3 +-
  qapi/net.json   | 16 ++--
  tests/virtio-net-test.c | 57 --
  8 files changed, 198 insertions(+), 27 deletions(-)



Applied.

Thanks

Re: [Qemu-devel] [PATCH V2 4/5] COLO-compare: Add colo-compare remote notify support

[Jason Wang]

On 2019/6/10 上午12:44, Zhang Chen wrote:

From: Zhang Chen 

This patch make colo-compare can send message to remote COLO frame(Xen) when 
occur checkpoint.

Signed-off-by: Zhang Chen 
---
  net/colo-compare.c | 54 +-
  1 file changed, 44 insertions(+), 10 deletions(-)

diff --git a/net/colo-compare.c b/net/colo-compare.c
index 16285f4a96..516b651ecd 100644
--- a/net/colo-compare.c
+++ b/net/colo-compare.c
@@ -120,11 +120,6 @@ enum {
  SECONDARY_IN,
  };
  
-static void colo_compare_inconsistency_notify(void)

-{
-notifier_list_notify(_compare_notifiers,
-migrate_get_current());
-}
  
  static int compare_chr_send(CompareState *s,

  const uint8_t *buf,
@@ -132,6 +127,27 @@ static int compare_chr_send(CompareState *s,
  uint32_t vnet_hdr_len,
  bool notify_remote_frame);
  
+static void notify_remote_frame(CompareState *s)

+{
+char msg[] = "DO_CHECKPOINT";
+int ret = 0;
+
+ret = compare_chr_send(s, (uint8_t *)msg, strlen(msg), 0, true);
+if (ret < 0) {
+error_report("Notify Xen COLO-frame failed");
+}
+}
+
+static void colo_compare_inconsistency_notify(CompareState *s)
+{
+if (s->notify_dev) {
+notify_remote_frame(s);
+} else {
+notifier_list_notify(_compare_notifiers,
+ migrate_get_current());
+}
+}
+
  static gint seq_sorter(Packet *a, Packet *b, gpointer data)
  {
  struct tcp_hdr *atcp, *btcp;
@@ -435,7 +451,7 @@ sec:
  qemu_hexdump((char *)spkt->data, stderr,
   "colo-compare spkt", spkt->size);
  
-colo_compare_inconsistency_notify();

+colo_compare_inconsistency_notify(s);
  }
  }
  
@@ -577,7 +593,7 @@ void colo_compare_unregister_notifier(Notifier *notify)

  }
  
  static int colo_old_packet_check_one_conn(Connection *conn,

-   void *user_data)
+  CompareState *s)
  {
  GList *result = NULL;
  int64_t check_time = REGULAR_PACKET_CHECK_MS;
@@ -588,7 +604,7 @@ static int colo_old_packet_check_one_conn(Connection *conn,
  
  if (result) {

  /* Do checkpoint will flush old packet */
-colo_compare_inconsistency_notify();
+colo_compare_inconsistency_notify(s);
  return 0;
  }
  
@@ -608,7 +624,7 @@ static void colo_old_packet_check(void *opaque)

   * If we find one old packet, stop finding job and notify
   * COLO frame do checkpoint.
   */
-g_queue_find_custom(>conn_list, NULL,
+g_queue_find_custom(>conn_list, s,
  (GCompareFunc)colo_old_packet_check_one_conn);
  }
  
@@ -637,7 +653,8 @@ static void colo_compare_packet(CompareState *s, Connection *conn,

   */
  trace_colo_compare_main("packet different");
  g_queue_push_head(>primary_list, pkt);
-colo_compare_inconsistency_notify();
+
+colo_compare_inconsistency_notify(s);
  break;
  }
  }
@@ -989,7 +1006,24 @@ static void compare_sec_rs_finalize(SocketReadState 
*sec_rs)
  
  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";
+int ret;
+
+if (!strcmp(data, "COLO_USERSPACE_PROXY_INIT")) {
+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")) {
+/* colo-compare do checkpoint, flush pri packet and remove sec packet 
*/
+g_queue_foreach(>conn_list, colo_flush_packets, s);
+}
  }



This protocol looks too simple, is this accepted by Xen?

Thanks


  
  /*

Re: [Qemu-devel] [Qemu-trivial] Fix cacheline size retrieval on FreeBSD/PowerPC(64)

[Justin Hibbits]

On Wed, Jun 26, 2019, 19:08 Laurent Vivier  wrote:

> Le 27/06/2019 à 02:02, Justin Hibbits a écrit :
> >
> >
> > On Wed, Jun 26, 2019, 13:04 Justin Hibbits  > > wrote:
> >
> > On Wed, 26 Jun 2019 18:47:42 +0200
> > Laurent Vivier mailto:laur...@vivier.eu>> wrote:
> >
> > > Le 26/06/2019 à 18:37, Justin Hibbits a écrit :
> > > > On Wed, 26 Jun 2019 18:16:36 +0200
> > > > Laurent Vivier mailto:laur...@vivier.eu>>
> wrote:
> > > >
> > > >> Le 26/06/2019 à 18:14, Laurent Vivier a écrit :
> > > >>> Le 07/06/2019 à 20:56, Justin Hibbits a écrit :
> > >  The attached very trivial patch fixes a startup bug that
> prevents
> > >  at least Qemu 3.1 and later from working on FreeBSD/powerpc64.
> > > 
> > >  - Justin
> > > 
> > > >>>
> > > >>> Please don't send a patch in attachment but inlined in the
> message
> > > >>> (you may use "git send-email" for that).
> > > >>>
> > > >>> This patch fixes "util: add cacheinfo" that has changed the
> type
> > > >>> from unsigned to long.
> > > >>>
> > > >>> You can add the following line in the commit message:
> > > >>>
> > > >>> Fixes: b255b2c8a548 ("util: add cacheinfo")
> > > >>>
> > > >>> Reviewed-by: Laurent Vivier  > >
> > > >>>
> > > >>
> > > >> CC: author of b255b2c8a548 ("util: add cacheinfo")
> > > >>
> > > >> Thanks,
> > > >> Laurent
> > > >
> > > > Hi Laurent,
> > > >
> > > > Sorry.  I had never used git send-email before, so wasn't
> > > > comfortable with it.  I just updated the commit message with your
> > > > feedback and used git send-email to submit the patch.  I hope
> > > > everything went well.
> > >
> > > It seems not. I didn't receive it.
> > >
> > > Did you configure the SMTP server. See git-send-email(1):
> > >
> > >Use gmail as the smtp server
> > >
> > >To use git send-email to send your patches through the GMail
> > > SMTP server, edit ~/.gitconfig to specify your account settings:
> > >
> > >[sendemail]
> > >smtpEncryption = tls
> > >smtpServer = smtp.gmail.com <
> http://smtp.gmail.com>
> > >smtpUser = yourn...@gmail.com
> > 
> > >smtpServerPort = 587
> > >
> > >If you have multifactor authentication setup on your gmail
> > > account, you will need to generate an app-specific password for use
> > > with git send-email. Visit
> > >https://security.google.com/settings/security/apppasswords
> to
> > > create it.
> > >
> > >Once your commits are ready to be sent to the mailing list,
> > > run the following commands:
> > >
> > >$ git format-patch --cover-letter -M origin/master -o
> > > outgoing/ $ edit outgoing/-*
> > >$ git send-email outgoing/*
> > >
> > >The first time you run it, you will be prompted for your
> > > credentials. Enter the app-specific or your regular password as
> > > appropriate. If you have credential helper configured (see
> > > git-credential(1)), the password will be saved in the credential
> > > store so you won’t have to type it the next time.
> > >
> > >Note: the following perl modules are required
> Net::SMTP::SSL,
> > >MIME::Base64 and Authen::SASL
> > >
> > > Thanks,
> > > Laurent
> > >
> > >
> >
> > Hm, you're right.  Even after making the config changes and
> installing
> > the necessary packages, I still have no luck with git send-email.
> Might
> > take a bit to debug this.
> >
> > - Justin
> >
> >
> > Sorry for the multiplicity, looks like Gmail forwarded it eventually,
> > but not until I tried several times debugging it.
>
> Not sure, I didn't receive any of them.
>
> Thanks,
> Laurent
>

Sigh, 4 copies ended up in my Gmail spam folder, so I thought it made it
through.

- Justin

>

Re: [Qemu-devel] [Qemu-trivial] Fix cacheline size retrieval on FreeBSD/PowerPC(64)

[Laurent Vivier]

Le 27/06/2019 à 02:02, Justin Hibbits a écrit :
> 
> 
> On Wed, Jun 26, 2019, 13:04 Justin Hibbits  > wrote:
> 
> On Wed, 26 Jun 2019 18:47:42 +0200
> Laurent Vivier mailto:laur...@vivier.eu>> wrote:
> 
> > Le 26/06/2019 à 18:37, Justin Hibbits a écrit :
> > > On Wed, 26 Jun 2019 18:16:36 +0200
> > > Laurent Vivier mailto:laur...@vivier.eu>> wrote:
> > >   
> > >> Le 26/06/2019 à 18:14, Laurent Vivier a écrit : 
> > >>> Le 07/06/2019 à 20:56, Justin Hibbits a écrit :   
> >  The attached very trivial patch fixes a startup bug that prevents
> >  at least Qemu 3.1 and later from working on FreeBSD/powerpc64.
> > 
> >  - Justin
> >    
> > >>>
> > >>> Please don't send a patch in attachment but inlined in the message
> > >>> (you may use "git send-email" for that).
> > >>>
> > >>> This patch fixes "util: add cacheinfo" that has changed the type
> > >>> from unsigned to long.
> > >>>
> > >>> You can add the following line in the commit message:
> > >>>
> > >>> Fixes: b255b2c8a548 ("util: add cacheinfo")
> > >>>
> > >>> Reviewed-by: Laurent Vivier  >
> > >>>     
> > >>
> > >> CC: author of b255b2c8a548 ("util: add cacheinfo")
> > >>
> > >> Thanks,
> > >> Laurent 
> > >
> > > Hi Laurent,
> > >
> > > Sorry.  I had never used git send-email before, so wasn't
> > > comfortable with it.  I just updated the commit message with your
> > > feedback and used git send-email to submit the patch.  I hope
> > > everything went well. 
> >
> > It seems not. I didn't receive it.
> >
> > Did you configure the SMTP server. See git-send-email(1):
> >
> >    Use gmail as the smtp server
> >
> >        To use git send-email to send your patches through the GMail
> > SMTP server, edit ~/.gitconfig to specify your account settings:
> >
> >            [sendemail]
> >                    smtpEncryption = tls
> >                    smtpServer = smtp.gmail.com 
> >                    smtpUser = yourn...@gmail.com
> 
> >                    smtpServerPort = 587
> >
> >        If you have multifactor authentication setup on your gmail
> > account, you will need to generate an app-specific password for use
> > with git send-email. Visit
> >        https://security.google.com/settings/security/apppasswords to
> > create it.
> >
> >        Once your commits are ready to be sent to the mailing list,
> > run the following commands:
> >
> >            $ git format-patch --cover-letter -M origin/master -o
> > outgoing/ $ edit outgoing/-*
> >            $ git send-email outgoing/*
> >
> >        The first time you run it, you will be prompted for your
> > credentials. Enter the app-specific or your regular password as
> > appropriate. If you have credential helper configured (see
> > git-credential(1)), the password will be saved in the credential
> > store so you won’t have to type it the next time.
> >
> >        Note: the following perl modules are required Net::SMTP::SSL,
> >        MIME::Base64 and Authen::SASL
> >
> > Thanks,
> > Laurent
> >
> > 
> 
> Hm, you're right.  Even after making the config changes and installing
> the necessary packages, I still have no luck with git send-email.  Might
> take a bit to debug this.
> 
> - Justin
> 
> 
> Sorry for the multiplicity, looks like Gmail forwarded it eventually,
> but not until I tried several times debugging it.

Not sure, I didn't receive any of them.

Thanks,
Laurent

Re: [Qemu-devel] [Qemu-trivial] Fix cacheline size retrieval on FreeBSD/PowerPC(64)

[Justin Hibbits]

On Wed, Jun 26, 2019, 13:04 Justin Hibbits  wrote:

> On Wed, 26 Jun 2019 18:47:42 +0200
> Laurent Vivier  wrote:
>
> > Le 26/06/2019 à 18:37, Justin Hibbits a écrit :
> > > On Wed, 26 Jun 2019 18:16:36 +0200
> > > Laurent Vivier  wrote:
> > >
> > >> Le 26/06/2019 à 18:14, Laurent Vivier a écrit :
> > >>> Le 07/06/2019 à 20:56, Justin Hibbits a écrit :
> >  The attached very trivial patch fixes a startup bug that prevents
> >  at least Qemu 3.1 and later from working on FreeBSD/powerpc64.
> > 
> >  - Justin
> > 
> > >>>
> > >>> Please don't send a patch in attachment but inlined in the message
> > >>> (you may use "git send-email" for that).
> > >>>
> > >>> This patch fixes "util: add cacheinfo" that has changed the type
> > >>> from unsigned to long.
> > >>>
> > >>> You can add the following line in the commit message:
> > >>>
> > >>> Fixes: b255b2c8a548 ("util: add cacheinfo")
> > >>>
> > >>> Reviewed-by: Laurent Vivier 
> > >>>
> > >>
> > >> CC: author of b255b2c8a548 ("util: add cacheinfo")
> > >>
> > >> Thanks,
> > >> Laurent
> > >
> > > Hi Laurent,
> > >
> > > Sorry.  I had never used git send-email before, so wasn't
> > > comfortable with it.  I just updated the commit message with your
> > > feedback and used git send-email to submit the patch.  I hope
> > > everything went well.
> >
> > It seems not. I didn't receive it.
> >
> > Did you configure the SMTP server. See git-send-email(1):
> >
> >Use gmail as the smtp server
> >
> >To use git send-email to send your patches through the GMail
> > SMTP server, edit ~/.gitconfig to specify your account settings:
> >
> >[sendemail]
> >smtpEncryption = tls
> >smtpServer = smtp.gmail.com
> >smtpUser = yourn...@gmail.com
> >smtpServerPort = 587
> >
> >If you have multifactor authentication setup on your gmail
> > account, you will need to generate an app-specific password for use
> > with git send-email. Visit
> >https://security.google.com/settings/security/apppasswords to
> > create it.
> >
> >Once your commits are ready to be sent to the mailing list,
> > run the following commands:
> >
> >$ git format-patch --cover-letter -M origin/master -o
> > outgoing/ $ edit outgoing/-*
> >$ git send-email outgoing/*
> >
> >The first time you run it, you will be prompted for your
> > credentials. Enter the app-specific or your regular password as
> > appropriate. If you have credential helper configured (see
> > git-credential(1)), the password will be saved in the credential
> > store so you won’t have to type it the next time.
> >
> >Note: the following perl modules are required Net::SMTP::SSL,
> >MIME::Base64 and Authen::SASL
> >
> > Thanks,
> > Laurent
> >
> >
>
> Hm, you're right.  Even after making the config changes and installing
> the necessary packages, I still have no luck with git send-email.  Might
> take a bit to debug this.
>
> - Justin
>

Sorry for the multiplicity, looks like Gmail forwarded it eventually, but
not until I tried several times debugging it.

- Justin

>

Re: [Qemu-devel] [GSoC] Help needed in implementing live migration

[Sukrit Bhatnagar]

On Tue, 25 Jun 2019 at 00:11, Dr. David Alan Gilbert
 wrote:
>
> * Sukrit Bhatnagar (skrtbht...@gmail.com) wrote:
> > Hi David,
> >
> > I am Sukrit, GSoC participant working on PVRDMA live migration.
> > We had a short chat about vmxnet3 migration about a week ago
> > on the IRC channel.
> >
> > I am facing an issue while doing migration of the pvrdma device.
> > While loading the device state, we need to perform a few dma
> > mappings on the destination. But on the destination, the migration
> > fails due a BounceBuffer being locked (in_use). This global
> > BounceBuffer is used in address_space_map/unmap functions
> > which the rdma_pci_dma_map/unmap calls.
> > Essentially, we need a way to remap guest physical address on
> > the destination after migration.
> >
> > I had posted an RFC a while ago on the list:
> > https://lists.gnu.org/archive/html/qemu-devel/2019-06/msg04924.html
> > https://lists.gnu.org/archive/html/qemu-devel/2019-06/msg04923.html
> >
> > My mentors (Marcel and Yuval) told me to ask you for help
> > regarding this. It would be really great if you can guide me in
> > finding a workaround for this.
>
> Hi,
>   I'll have a look; I need to get some other things finished first.

Adding cc: qemu-devel, sorry for the private email.

> Dave
> > Thanks,
> > Sukrit
> --
> Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

Re: [Qemu-devel] [PATCH] block/qcow: Improve error when opening qcow2 files as qcow

[Eric Blake]

On 6/26/19 4:53 PM, John Snow wrote:
> Reported-by: radmehrsae...@gmail.com
> Fixes: https://bugs.launchpad.net/bugs/1832914
> Signed-off-by: John Snow 
> ---
>  block/qcow.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)

Yes, this is useful.

Reviewed-by: Eric Blake 

Reminds me of when I helped convince the file(1) database maintainers
that 'qcow2 (v3)' was better than 'qcow (v3)'.
(https://bugzilla.redhat.com/show_bug.cgi?id=1654349, file.git 60b896d4)

> 
> diff --git a/block/qcow.c b/block/qcow.c
> index 6dee5bb792..a9cb6ae0bd 100644
> --- a/block/qcow.c
> +++ b/block/qcow.c
> @@ -156,7 +156,12 @@ static int qcow_open(BlockDriverState *bs, QDict 
> *options, int flags,
>  goto fail;
>  }
>  if (header.version != QCOW_VERSION) {
> -error_setg(errp, "Unsupported qcow version %" PRIu32, 
> header.version);
> +error_setg(errp, "qcow (v%d) does not support qcow version %" PRIu32,
> +   QCOW_VERSION, header.version);
> +if (header.version == 2 || header.version == 3) {
> +error_append_hint(errp, "Try the 'qcow2' driver instead.");
> +}
> +
>  ret = -ENOTSUP;
>  goto fail;
>  }
> 

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



signature.asc
Description: OpenPGP digital signature

[Qemu-devel] [PATCH v1 1/1] hw/scsi: Report errors and sense to guests through scsi-block

[Alistair Francis]

From: Shin'ichiro Kawasaki 

When host block devices are bridged to a guest system through
virtio-scsi-pci and scsi-block driver, scsi_handle_rw_error() in
hw/scsi/scsi-disk.c checks the error number to judge which error to
report to the guests. EIO and EINVAL are not reported and ignored. Once
EIO or EINVAL happen, eternal wait of guest system happens. This problem
was observed with zoned block devices on the host system attached to the
guest via virtio-scsi-pci. To avoid the eternal wait, add EIO and EINVAL
to the list of error numbers to report to the guest.

On top of this, it is required to report SCSI sense data to the guest
so that the guest can handle the error correctly. However,
scsi_handle_rw_error() does not passthrough sense data that host
scsi-block device reported. Instead, it newly generates fixed sense
data only for certain error numbers. This is inflexible to support new
error codes to report to guest. To avoid this inflexiblity, pass the SCSI
sense data that the host scsi-block device reported as is. To be more
precise, set valid sense_len in the SCSIDiskReq referring sb_len_wr that
host SCSI device SG_IO ioctl reported. Add update_sense callback to
SCSIDiskClass to refer the SG_IO ioctl result only when scsi-block device
is targeted.

Signed-off-by: Shin'ichiro Kawasaki 
Signed-off-by: Alistair Francis 
---
 hw/scsi/scsi-disk.c | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/hw/scsi/scsi-disk.c b/hw/scsi/scsi-disk.c
index ed7295bfd7..6801e3a0d0 100644
--- a/hw/scsi/scsi-disk.c
+++ b/hw/scsi/scsi-disk.c
@@ -62,6 +62,7 @@ typedef struct SCSIDiskClass {
 DMAIOFunc   *dma_readv;
 DMAIOFunc   *dma_writev;
 bool(*need_fua_emulation)(SCSICommand *cmd);
+void(*update_sense)(SCSIRequest *r);
 } SCSIDiskClass;
 
 typedef struct SCSIDiskReq {
@@ -438,6 +439,7 @@ static bool scsi_handle_rw_error(SCSIDiskReq *r, int error, 
bool acct_failed)
 {
 bool is_read = (r->req.cmd.mode == SCSI_XFER_FROM_DEV);
 SCSIDiskState *s = DO_UPCAST(SCSIDiskState, qdev, r->req.dev);
+SCSIDiskClass *sdc = (SCSIDiskClass *) object_get_class(OBJECT(s));
 BlockErrorAction action = blk_get_error_action(s->qdev.conf.blk,
is_read, error);
 
@@ -452,9 +454,12 @@ static bool scsi_handle_rw_error(SCSIDiskReq *r, int 
error, bool acct_failed)
  * pause the host.
  */
 assert(r->status && *r->status);
+if (sdc->update_sense) {
+sdc->update_sense(>req);
+}
 error = scsi_sense_buf_to_errno(r->req.sense, 
sizeof(r->req.sense));
 if (error == ECANCELED || error == EAGAIN || error == ENOTCONN ||
-error == 0)  {
+error == EIO || error == EINVAL || error == 0)  {
 /* These errors are handled by guest. */
 scsi_req_complete(>req, *r->status);
 return true;
@@ -2894,6 +2899,13 @@ static int scsi_block_parse_cdb(SCSIDevice *d, 
SCSICommand *cmd,
 }
 }
 
+static void scsi_block_update_sense(SCSIRequest *req)
+{
+SCSIDiskReq *r = DO_UPCAST(SCSIDiskReq, req, req);
+SCSIBlockReq *br = DO_UPCAST(SCSIBlockReq, req, r);
+r->req.sense_len = MIN(br->io_header.sb_len_wr, sizeof(r->req.sense));
+}
+
 #endif
 
 static
@@ -3059,6 +3071,7 @@ static void scsi_block_class_initfn(ObjectClass *klass, 
void *data)
 sc->parse_cdb= scsi_block_parse_cdb;
 sdc->dma_readv   = scsi_block_dma_readv;
 sdc->dma_writev  = scsi_block_dma_writev;
+sdc->update_sense = scsi_block_update_sense;
 sdc->need_fua_emulation = scsi_block_no_fua;
 dc->desc = "SCSI block device passthrough";
 dc->props = scsi_block_properties;
-- 
2.22.0

[Qemu-devel] [PATCH] block/qcow: Improve error when opening qcow2 files as qcow

[John Snow]

Reported-by: radmehrsae...@gmail.com
Fixes: https://bugs.launchpad.net/bugs/1832914
Signed-off-by: John Snow 
---
 block/qcow.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/block/qcow.c b/block/qcow.c
index 6dee5bb792..a9cb6ae0bd 100644
--- a/block/qcow.c
+++ b/block/qcow.c
@@ -156,7 +156,12 @@ static int qcow_open(BlockDriverState *bs, QDict *options, 
int flags,
 goto fail;
 }
 if (header.version != QCOW_VERSION) {
-error_setg(errp, "Unsupported qcow version %" PRIu32, header.version);
+error_setg(errp, "qcow (v%d) does not support qcow version %" PRIu32,
+   QCOW_VERSION, header.version);
+if (header.version == 2 || header.version == 3) {
+error_append_hint(errp, "Try the 'qcow2' driver instead.");
+}
+
 ret = -ENOTSUP;
 goto fail;
 }
-- 
2.21.0

Re: [Qemu-devel] [Qemu-block] [PATCH V2 RESEND] block/replication.c: Fix crash issue after failover

[John Snow]

On 6/21/19 2:28 AM, Zhang Chen wrote:
> From: Zhang Chen 
> 
> If we try to close replication after failover, it will crash here.
> So we need check the block job on active disk before cancel the job.
> 
> Signed-off-by: Zhang Chen 
> ---
>  block/replication.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/block/replication.c b/block/replication.c
> index b41bc507c0..a68bc7e986 100644
> --- a/block/replication.c
> +++ b/block/replication.c
> @@ -149,7 +149,9 @@ static void replication_close(BlockDriverState *bs)
>  replication_stop(s->rs, false, NULL);
>  }
>  if (s->stage == BLOCK_REPLICATION_FAILOVER) {
> -job_cancel_sync(>commit_job->job);
> +if (s->commit_job) {
> +job_cancel_sync(>commit_job->job);
> +}
>  }
>  
>  if (s->mode == REPLICATION_MODE_SECONDARY) {
> 

I actually don't understand this right away.

The only place I see that sets commit_job is replication_stop, which
sets it immediately after s->stage = BLOCK_REPLICATION_FAILOVER.

So if we're here in replication_close, shouldn't we have a valid job object?

...unless we never succeeded in launching this commit job, but then
don't we have worse problems?

...Or, perhaps the job actually finished, but then we never cleared the
job variable in replication_done, but then I don't see why this if
statement would actually help us.

Can you share some details of the crash to help me understand the crash,
and why this patch helps?

--js

Re: [Qemu-devel] [Qemu-block] [PATCH v2 0/2] nbd: enable keepalive

[Eric Blake]

On 6/26/19 4:23 PM, Eric Blake wrote:
> On 6/26/19 4:18 PM, John Snow wrote:
>>
>>
>> On 6/5/19 12:18 PM, Vladimir Sementsov-Ogievskiy wrote:
>>> Hi all!
>>>
>>> Here is a suggestion to enable keepalive option to track server availablity.
>>> We suggest to enable it by default. If we need, we'll be able to add option
>>> to specify timeout by hand later.
>>>
>>> v2: 01 - Fix io channel returned errors to be -1 [Daniel]
>>> 02 - Fix typo in commit message [Eric]
>>>
>>> Vladimir Sementsov-Ogievskiy (2):
>>>   io/channel: add qio_channel_set_keepalive
>>>   nbd-client: enable TCP keepalive
>>>
>>>  include/io/channel.h | 15 +++
>>>  block/nbd-client.c   |  1 +
>>>  io/channel-socket.c  | 20 
>>>  io/channel.c | 14 ++
>>>  4 files changed, 50 insertions(+)
>>>
>>
>> Ping -- I think this was good to go with Dan's ACK, based on the
>> discussion from v1.
> 
> Actually, I thought that we changed tactics, and that the latest version is:
> 
> https://lists.gnu.org/archive/html/qemu-devel/2019-06/msg01989.html
> 
> [PATCH v2] qapi: InitSocketAddress: add keepalive option
> 
> to make the setting conditional based on blockdev parameters rather than
> unconditional.

Or even v3, which still had review comments pending:

https://lists.gnu.org/archive/html/qemu-devel/2019-06/msg05508.html

[PATCH v3] qapi: Add InetSocketAddress member keep-alive

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [Qemu-block] [PATCH v2 0/2] nbd: enable keepalive

[John Snow]

On 6/26/19 5:23 PM, Eric Blake wrote:
> On 6/26/19 4:18 PM, John Snow wrote:
>>
>>
>> On 6/5/19 12:18 PM, Vladimir Sementsov-Ogievskiy wrote:
>>> Hi all!
>>>
>>> Here is a suggestion to enable keepalive option to track server availablity.
>>> We suggest to enable it by default. If we need, we'll be able to add option
>>> to specify timeout by hand later.
>>>
>>> v2: 01 - Fix io channel returned errors to be -1 [Daniel]
>>> 02 - Fix typo in commit message [Eric]
>>>
>>> Vladimir Sementsov-Ogievskiy (2):
>>>   io/channel: add qio_channel_set_keepalive
>>>   nbd-client: enable TCP keepalive
>>>
>>>  include/io/channel.h | 15 +++
>>>  block/nbd-client.c   |  1 +
>>>  io/channel-socket.c  | 20 
>>>  io/channel.c | 14 ++
>>>  4 files changed, 50 insertions(+)
>>>
>>
>> Ping -- I think this was good to go with Dan's ACK, based on the
>> discussion from v1.
> 
> Actually, I thought that we changed tactics, and that the latest version is:
> 
> https://lists.gnu.org/archive/html/qemu-devel/2019-06/msg01989.html
> 
> [PATCH v2] qapi: InitSocketAddress: add keepalive option
> 
> to make the setting conditional based on blockdev parameters rather than
> unconditional.
> 

OK, thanks for the pointer! I had my head buried for a little bit and I
am playing catchup with discussions, and it looked like this one needed
attention, but I missed this.

Thank you!

--js

Re: [Qemu-devel] [Qemu-block] [PATCH v2 0/2] nbd: enable keepalive

[Eric Blake]

On 6/26/19 4:18 PM, John Snow wrote:
> 
> 
> On 6/5/19 12:18 PM, Vladimir Sementsov-Ogievskiy wrote:
>> Hi all!
>>
>> Here is a suggestion to enable keepalive option to track server availablity.
>> We suggest to enable it by default. If we need, we'll be able to add option
>> to specify timeout by hand later.
>>
>> v2: 01 - Fix io channel returned errors to be -1 [Daniel]
>> 02 - Fix typo in commit message [Eric]
>>
>> Vladimir Sementsov-Ogievskiy (2):
>>   io/channel: add qio_channel_set_keepalive
>>   nbd-client: enable TCP keepalive
>>
>>  include/io/channel.h | 15 +++
>>  block/nbd-client.c   |  1 +
>>  io/channel-socket.c  | 20 
>>  io/channel.c | 14 ++
>>  4 files changed, 50 insertions(+)
>>
> 
> Ping -- I think this was good to go with Dan's ACK, based on the
> discussion from v1.

Actually, I thought that we changed tactics, and that the latest version is:

https://lists.gnu.org/archive/html/qemu-devel/2019-06/msg01989.html

[PATCH v2] qapi: InitSocketAddress: add keepalive option

to make the setting conditional based on blockdev parameters rather than
unconditional.

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [Qemu-block] [PATCH v2 0/2] nbd: enable keepalive

[John Snow]

On 6/5/19 12:18 PM, Vladimir Sementsov-Ogievskiy wrote:
> Hi all!
> 
> Here is a suggestion to enable keepalive option to track server availablity.
> We suggest to enable it by default. If we need, we'll be able to add option
> to specify timeout by hand later.
> 
> v2: 01 - Fix io channel returned errors to be -1 [Daniel]
> 02 - Fix typo in commit message [Eric]
> 
> Vladimir Sementsov-Ogievskiy (2):
>   io/channel: add qio_channel_set_keepalive
>   nbd-client: enable TCP keepalive
> 
>  include/io/channel.h | 15 +++
>  block/nbd-client.c   |  1 +
>  io/channel-socket.c  | 20 
>  io/channel.c | 14 ++
>  4 files changed, 50 insertions(+)
> 

Ping -- I think this was good to go with Dan's ACK, based on the
discussion from v1.

Re: [Qemu-devel] [Qemu-block] [PATCH 00/13] hw/block/pflash_cfi02: Clean-up and fixes

[John Snow]

On 6/26/19 5:06 PM, Philippe Mathieu-Daudé wrote:
> Hi John,
> 
> On 6/26/19 10:33 PM, John Snow wrote:
>> I don't think this series ever made it upstream, and it's now well past
>> 30 days, so I might encourage a resend when you can if this is still
>> important to pursue.
> 
> I should have sent a 'ping' indeed.
> I keep rebasing because I have it in my pflash-next queue, and I added
> more patches from Stephen. I am still running tests, and it is a pain to
> test things that have never been tested.
> Anyway, my plan is to send a "current status of pflash-next" series.
> 
> Thanks for worrying :)
> 
> Phil.
> 

Great, thanks!

Re: [Qemu-devel] [Qemu-block] [PATCH 00/13] hw/block/pflash_cfi02: Clean-up and fixes

[Philippe Mathieu-Daudé]

Hi John,

On 6/26/19 10:33 PM, John Snow wrote:
> I don't think this series ever made it upstream, and it's now well past
> 30 days, so I might encourage a resend when you can if this is still
> important to pursue.

I should have sent a 'ping' indeed.
I keep rebasing because I have it in my pflash-next queue, and I added
more patches from Stephen. I am still running tests, and it is a pain to
test things that have never been tested.
Anyway, my plan is to send a "current status of pflash-next" series.

Thanks for worrying :)

Phil.

> --js
> 
> On 5/5/19 6:15 PM, Philippe Mathieu-Daudé wrote:
>> Hi,
>>
>> While reviewing Stephen Checkoway's v4 "Implement missing AMD
>> pflash functionality" [*] I found it hard (for me) to digest,
>> so I took step by step notes. This series is the result of
>> those notes.
>> Regarding Stephen's series, this series only contains the
>> generic code movement and trivial cleanup. The other patches
>> are rather dense and I need more time to study the specs.
>>
>> Stephen: If you take out the patch #2 ("Use the GLib API"),
>> you can rebase your series on top of this.
>> I'd appreciate if you can adapt your tests to use the GLib
>> functions, else I plan to do it later.

PD: Oh, Stephen, if you read it, forget about this comment!


>> [*] https://lists.gnu.org/archive/html/qemu-devel/2019-04/msg04595.html
>>
>> Philippe Mathieu-Daudé (10):
>>   tests/pflash-cfi02: Use the GLib API
>>   tests/pflash-cfi02: Use IEC binary prefixes for size constants
>>   hw/block/pflash_cfi02: Fix debug format string
>>   hw/block/pflash_cfi02: Add an enum to define the write cycles
>>   hw/block/pflash_cfi02: Add helpers to manipulate the status bits
>>   hw/block/pflash_cfi02: Simplify a statement using fall through
>>   hw/block/pflash_cfi02: Use the ldst API in pflash_write()
>>   hw/block/pflash_cfi02: Use the ldst API in pflash_read()
>>   hw/block/pflash_cfi02: Extract the pflash_data_read() function
>>   hw/block/pflash_cfi02: Unify the MemoryRegionOps
>>
>> Stephen Checkoway (3):
>>   tests/pflash-cfi02: Add test for supported CFI commands
>>   hw/block/pflash_cfi02: Fix command address comparison
>>   hw/block/pflash_cfi02: Use the chip erase time specified in the CFI
>> table
>>
>>  hw/block/pflash_cfi02.c   | 234 +-
>>  tests/Makefile.include|   2 +
>>  tests/pflash-cfi02-test.c | 232 +
>>  3 files changed, 339 insertions(+), 129 deletions(-)
>>  create mode 100644 tests/pflash-cfi02-test.c
>>

Re: [Qemu-devel] [Qemu-block] [PATCH v2] block/rbd: implement .bdrv_get_allocated_file_size callback

[John Snow]

It looks like this has hit a 30 day expiration without any reviews or
being merged; do we still want this? If so, can you please resend?

On 5/10/19 11:33 AM, Stefano Garzarella wrote:
> This patch allows 'qemu-img info' to show the 'disk size' for
> the RBD images that have the fast-diff feature enabled.
> 
> If this feature is enabled, we use the rbd_diff_iterate2() API
> to calculate the allocated size for the image.
> 
> Signed-off-by: Stefano Garzarella 
> ---
> v2:
>   - calculate the actual usage only if the fast-diff feature is
> enabled [Jason]
> ---
>  block/rbd.c | 54 +
>  1 file changed, 54 insertions(+)
> 
> diff --git a/block/rbd.c b/block/rbd.c
> index 0c549c9935..f1bc76ab80 100644
> --- a/block/rbd.c
> +++ b/block/rbd.c
> @@ -1046,6 +1046,59 @@ static int64_t qemu_rbd_getlength(BlockDriverState *bs)
>  return info.size;
>  }
>  
> +static int rbd_allocated_size_cb(uint64_t offset, size_t len, int exists,
> + void *arg)
> +{
> +int64_t *alloc_size = (int64_t *) arg;
> +
> +if (exists) {
> +(*alloc_size) += len;
> +}
> +
> +return 0;
> +}
> +
> +static int64_t qemu_rbd_get_allocated_file_size(BlockDriverState *bs)
> +{
> +BDRVRBDState *s = bs->opaque;
> +uint64_t flags, features;
> +int64_t alloc_size = 0;
> +int r;
> +
> +r = rbd_get_flags(s->image, );
> +if (r < 0) {
> +return r;
> +}
> +

Do you know where rbd_get_flags is documented? I can't seem to quickly
find a reference that tells me what to expect from calling it. It
returns an int, I guess an error code, but how can I confirm this?

*clones the ceph repository*

src/librbd/internal.cc get_flags convinces me it probably works like I
think, but is there not a reference here?

> +r = rbd_get_features(s->image, );
> +if (r < 0) {
> +return r;
> +}
> +
> +/*
> + * We use rbd_diff_iterate2() only if the RBD image have fast-diff
> + * feature enabled. If it is disabled, rbd_diff_iterate2() could be
> + * very slow on a big image.
> + */
> +if (!(features & RBD_FEATURE_FAST_DIFF) ||
> +(flags & RBD_FLAG_FAST_DIFF_INVALID)) {
> +return -1;
> +}
> +

(Is there a reference for the list of flags to make sure there aren't
other cases we might want to skip this?)

It looks reasonable at a glance, but maybe let's return -ENOTSUP instead
of -1, based on the idea that bdrv_get_allocated_file_size returns
-ENOMEDIUM in a prominent error case -- let's match that error convention.

(Well, I wonder what the librbd calls are returning and if THOSE mean
anything.)

> +/*
> + * rbd_diff_iterate2(), if the source snapshot name is NULL, invokes
> + * the callback on all allocated regions of the image.
> + */
> +r = rbd_diff_iterate2(s->image, NULL, 0,
> +  bs->total_sectors * BDRV_SECTOR_SIZE, 0, 1,
> +  _allocated_size_cb, _size);
> +if (r < 0) {
> +return r;
> +}
> +

I guess I'll take your word for it. ¯\_(ツ)_/¯

> +return alloc_size;
> +}
> +
>  static int coroutine_fn qemu_rbd_co_truncate(BlockDriverState *bs,
>   int64_t offset,
>   PreallocMode prealloc,
> @@ -1254,6 +1307,7 @@ static BlockDriver bdrv_rbd = {
>  .bdrv_get_info  = qemu_rbd_getinfo,
>  .create_opts= _rbd_create_opts,
>  .bdrv_getlength = qemu_rbd_getlength,
> +.bdrv_get_allocated_file_size = qemu_rbd_get_allocated_file_size,
>  .bdrv_co_truncate   = qemu_rbd_co_truncate,
>  .protocol_name  = "rbd",
>  
> 

[Qemu-devel] [PATCH v4 0/5] 9p: Fix file ID collisions

[Christian Schoenebeck via Qemu-devel]

This is v4 of a proposed patch set for fixing file ID collisions with 9pfs.

v3->v4:

  * Rebased to latest git master head.

  * Splitted Antonios' patch set to its original 4 individual patches.
(was merged previously as only 1 patch).

  * Addressed discussed issues directly on Antonios' patches
(was a separate patch before).

  * Added virtfs command line option "remap_inodes": Unless this option
is not enabled, no inode remapping is performed at all, the user
just gets an error message when trying to use more than 1 device
per export.

  * Dropped persistency feature of QIDs beyond reboots.

  * Dropped disputed "vii" feature.

Greg, please check if I am doing anything superfluous in patch 3 regarding
the new command line parameter "remap_inodes".

Daniel, I also have a libvirt patch for this new "remap_inodes" command
line parameter, but I guess I wait for this qemu patch set to get through.

Christian Schoenebeck (5):
  9p: unsigned type for type, version, path
  9p: Treat multiple devices on one export as an error
  9p: Added virtfs option "remap_inodes"
  9p: stat_to_qid: implement slow path
  9p: Use variable length suffixes for inode remapping

 fsdev/9p-marshal.h  |   6 +-
 fsdev/file-op-9p.h  |   1 +
 fsdev/qemu-fsdev-opts.c |   7 +-
 fsdev/qemu-fsdev.c  |   6 +
 hw/9pfs/9p.c| 448 +---
 hw/9pfs/9p.h|  83 +
 hw/9pfs/trace-events|  14 +-
 qemu-options.hx |  17 +-
 vl.c|   3 +
 9 files changed, 550 insertions(+), 35 deletions(-)

-- 
2.11.0

[Qemu-devel] [PATCH v4 4/5] 9p: stat_to_qid: implement slow path

[Christian Schoenebeck via Qemu-devel]

stat_to_qid attempts via qid_path_prefixmap to map unique files (which are
identified by 64 bit inode nr and 32 bit device id) to a 64 QID path value.
However this implementation makes some assumptions about inode number
generation on the host.

If qid_path_prefixmap fails, we still have 48 bits available in the QID
path to fall back to a less memory efficient full mapping.

Signed-off-by: Antonios Motakis 
Signed-off-by: Christian Schoenebeck 
---
 hw/9pfs/9p.c | 63 +++-
 hw/9pfs/9p.h |  9 +
 2 files changed, 67 insertions(+), 5 deletions(-)

diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
index 7ccc68a829..e6e410972f 100644
--- a/hw/9pfs/9p.c
+++ b/hw/9pfs/9p.c
@@ -579,23 +579,69 @@ static uint32_t qpp_hash(QppEntry e)
 return qemu_xxhash7(e.ino_prefix, e.dev, 0, 0, 0);
 }
 
+static uint32_t qpf_hash(QpfEntry e)
+{
+return qemu_xxhash7(e.ino, e.dev, 0, 0, 0);
+}
+
 static bool qpp_lookup_func(const void *obj, const void *userp)
 {
 const QppEntry *e1 = obj, *e2 = userp;
 return e1->dev == e2->dev && e1->ino_prefix == e2->ino_prefix;
 }
 
-static void qpp_table_remove(void *p, uint32_t h, void *up)
+static bool qpf_lookup_func(const void *obj, const void *userp)
+{
+const QpfEntry *e1 = obj, *e2 = userp;
+return e1->dev == e2->dev && e1->ino == e2->ino;
+}
+
+static void qp_table_remove(void *p, uint32_t h, void *up)
 {
 g_free(p);
 }
 
-static void qpp_table_destroy(struct qht *ht)
+static void qp_table_destroy(struct qht *ht)
 {
-qht_iter(ht, qpp_table_remove, NULL);
+qht_iter(ht, qp_table_remove, NULL);
 qht_destroy(ht);
 }
 
+static int qid_path_fullmap(V9fsPDU *pdu, const struct stat *stbuf,
+uint64_t *path)
+{
+QpfEntry lookup = {
+.dev = stbuf->st_dev,
+.ino = stbuf->st_ino
+}, *val;
+uint32_t hash = qpf_hash(lookup);
+
+/* most users won't need the fullmap, so init the table lazily */
+if (!pdu->s->qpf_table.map) {
+qht_init(>s->qpf_table, qpf_lookup_func, 1 << 16, 
QHT_MODE_AUTO_RESIZE);
+}
+
+val = qht_lookup(>s->qpf_table, , hash);
+
+if (!val) {
+if (pdu->s->qp_fullpath_next == 0) {
+/* no more files can be mapped :'( */
+return -ENFILE;
+}
+
+val = g_malloc0(sizeof(QppEntry));
+*val = lookup;
+
+/* new unique inode and device combo */
+val->path = pdu->s->qp_fullpath_next++;
+pdu->s->qp_fullpath_next &= QPATH_INO_MASK;
+qht_insert(>s->qpf_table, val, hash, NULL);
+}
+
+*path = val->path;
+return 0;
+}
+
 /* stat_to_qid needs to map inode number (64 bits) and device id (32 bits)
  * to a unique QID path (64 bits). To avoid having to map and keep track
  * of up to 2^64 objects, we map only the 16 highest bits of the inode plus
@@ -642,6 +688,10 @@ static int stat_to_qid(V9fsPDU *pdu, const struct stat 
*stbuf, V9fsQID *qidp)
 if (pdu->s->ctx.export_flags & V9FS_REMAP_INODES) {
 /* map inode+device to qid path (fast path) */
 err = qid_path_prefixmap(pdu, stbuf, >path);
+if (err == -ENFILE) {
+/* fast path didn't work, fall back to full map */
+err = qid_path_fullmap(pdu, stbuf, >path);
+}
 if (err) {
 return err;
 }
@@ -3752,6 +3802,7 @@ int v9fs_device_realize_common(V9fsState *s, const 
V9fsTransport *t,
 /* QID path hash table. 1 entry ought to be enough for anybody ;) */
 qht_init(>qpp_table, qpp_lookup_func, 1, QHT_MODE_AUTO_RESIZE);
 s->qp_prefix_next = 1; /* reserve 0 to detect overflow */
+s->qp_fullpath_next = 1;
 
 s->ctx.fst = >fst;
 fsdev_throttle_init(s->ctx.fst);
@@ -3766,7 +3817,8 @@ out:
 }
 g_free(s->tag);
 g_free(s->ctx.fs_root);
-qpp_table_destroy(>qpp_table);
+qp_table_destroy(>qpp_table);
+qp_table_destroy(>qpf_table);
 v9fs_path_free();
 }
 return rc;
@@ -3779,7 +3831,8 @@ void v9fs_device_unrealize_common(V9fsState *s, Error 
**errp)
 }
 fsdev_throttle_cleanup(s->ctx.fst);
 g_free(s->tag);
-qpp_table_destroy(>qpp_table);
+qp_table_destroy(>qpp_table);
+qp_table_destroy(>qpf_table);
 g_free(s->ctx.fs_root);
 }
 
diff --git a/hw/9pfs/9p.h b/hw/9pfs/9p.h
index 0200e04176..2b74561030 100644
--- a/hw/9pfs/9p.h
+++ b/hw/9pfs/9p.h
@@ -245,6 +245,13 @@ typedef struct {
 uint16_t qp_prefix;
 } QppEntry;
 
+/* QID path full entry, as above */
+typedef struct {
+dev_t dev;
+ino_t ino;
+uint64_t path;
+} QpfEntry;
+
 struct V9fsState
 {
 QLIST_HEAD(, V9fsPDU) free_list;
@@ -268,7 +275,9 @@ struct V9fsState
 V9fsQID root_qid;
 dev_t dev_id;
 struct qht qpp_table;
+struct qht qpf_table;
 uint16_t qp_prefix_next;
+uint64_t qp_fullpath_next;
 };
 
 /* 9p2000.L open flags */
-- 
2.11.0

[Qemu-devel] [PATCH v4 3/5] 9p: Added virtfs option "remap_inodes"

[Christian Schoenebeck via Qemu-devel]

To support multiple devices on the 9p share, and avoid
qid path collisions we take the device id as input
to generate a unique QID path. The lowest 48 bits of
the path will be set equal to the file inode, and the
top bits will be uniquely assigned based on the top
16 bits of the inode and the device id.

Signed-off-by: Antonios Motakis 
Signed-off-by: Christian Schoenebeck 
---
 fsdev/file-op-9p.h  |   1 +
 fsdev/qemu-fsdev-opts.c |   7 +++-
 fsdev/qemu-fsdev.c  |   6 +++
 hw/9pfs/9p.c| 105 ++--
 hw/9pfs/9p.h|  12 ++
 qemu-options.hx |  17 +++-
 vl.c|   3 ++
 7 files changed, 135 insertions(+), 16 deletions(-)

diff --git a/fsdev/file-op-9p.h b/fsdev/file-op-9p.h
index c757c8099f..6c1663c252 100644
--- a/fsdev/file-op-9p.h
+++ b/fsdev/file-op-9p.h
@@ -59,6 +59,7 @@ typedef struct ExtendedOps {
 #define V9FS_RDONLY 0x0040
 #define V9FS_PROXY_SOCK_FD  0x0080
 #define V9FS_PROXY_SOCK_NAME0x0100
+#define V9FS_REMAP_INODES   0x0200
 
 #define V9FS_SEC_MASK   0x003C
 
diff --git a/fsdev/qemu-fsdev-opts.c b/fsdev/qemu-fsdev-opts.c
index 7c31af..64a8052266 100644
--- a/fsdev/qemu-fsdev-opts.c
+++ b/fsdev/qemu-fsdev-opts.c
@@ -31,7 +31,9 @@ static QemuOptsList qemu_fsdev_opts = {
 }, {
 .name = "readonly",
 .type = QEMU_OPT_BOOL,
-
+}, {
+.name = "remap_inodes",
+.type = QEMU_OPT_BOOL,
 }, {
 .name = "socket",
 .type = QEMU_OPT_STRING,
@@ -76,6 +78,9 @@ static QemuOptsList qemu_virtfs_opts = {
 .name = "readonly",
 .type = QEMU_OPT_BOOL,
 }, {
+.name = "remap_inodes",
+.type = QEMU_OPT_BOOL,
+}, {
 .name = "socket",
 .type = QEMU_OPT_STRING,
 }, {
diff --git a/fsdev/qemu-fsdev.c b/fsdev/qemu-fsdev.c
index 077a8c4e2b..b6fa9799be 100644
--- a/fsdev/qemu-fsdev.c
+++ b/fsdev/qemu-fsdev.c
@@ -121,6 +121,7 @@ int qemu_fsdev_add(QemuOpts *opts, Error **errp)
 const char *fsdev_id = qemu_opts_id(opts);
 const char *fsdriver = qemu_opt_get(opts, "fsdriver");
 const char *writeout = qemu_opt_get(opts, "writeout");
+bool remap_inodes = qemu_opt_get_bool(opts, "remap_inodes", 0);
 bool ro = qemu_opt_get_bool(opts, "readonly", 0);
 
 if (!fsdev_id) {
@@ -161,6 +162,11 @@ int qemu_fsdev_add(QemuOpts *opts, Error **errp)
 } else {
 fsle->fse.export_flags &= ~V9FS_RDONLY;
 }
+if (remap_inodes) {
+fsle->fse.export_flags |= V9FS_REMAP_INODES;
+} else {
+fsle->fse.export_flags &= ~V9FS_REMAP_INODES;
+}
 
 if (fsle->fse.ops->parse_opts) {
 if (fsle->fse.ops->parse_opts(opts, >fse, errp)) {
diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
index cbaa212625..7ccc68a829 100644
--- a/hw/9pfs/9p.c
+++ b/hw/9pfs/9p.c
@@ -25,6 +25,7 @@
 #include "trace.h"
 #include "migration/blocker.h"
 #include "sysemu/qtest.h"
+#include "qemu/xxhash.h"
 
 int open_fd_hw;
 int total_open_fd;
@@ -571,24 +572,96 @@ static void coroutine_fn virtfs_reset(V9fsPDU *pdu)
 P9_STAT_MODE_NAMED_PIPE |   \
 P9_STAT_MODE_SOCKET)
 
-/* This is the algorithm from ufs in spfs */
+
+/* creative abuse of tb_hash_func7, which is based on xxhash */
+static uint32_t qpp_hash(QppEntry e)
+{
+return qemu_xxhash7(e.ino_prefix, e.dev, 0, 0, 0);
+}
+
+static bool qpp_lookup_func(const void *obj, const void *userp)
+{
+const QppEntry *e1 = obj, *e2 = userp;
+return e1->dev == e2->dev && e1->ino_prefix == e2->ino_prefix;
+}
+
+static void qpp_table_remove(void *p, uint32_t h, void *up)
+{
+g_free(p);
+}
+
+static void qpp_table_destroy(struct qht *ht)
+{
+qht_iter(ht, qpp_table_remove, NULL);
+qht_destroy(ht);
+}
+
+/* stat_to_qid needs to map inode number (64 bits) and device id (32 bits)
+ * to a unique QID path (64 bits). To avoid having to map and keep track
+ * of up to 2^64 objects, we map only the 16 highest bits of the inode plus
+ * the device id to the 16 highest bits of the QID path. The 48 lowest bits
+ * of the QID path equal to the lowest bits of the inode number.
+ *
+ * This takes advantage of the fact that inode number are usually not
+ * random but allocated sequentially, so we have fewer items to keep
+ * track of.
+ */
+static int qid_path_prefixmap(V9fsPDU *pdu, const struct stat *stbuf,
+uint64_t *path)
+{
+QppEntry lookup = {
+.dev = stbuf->st_dev,
+.ino_prefix = (uint16_t) (stbuf->st_ino >> 48)
+}, *val;
+uint32_t hash = qpp_hash(lookup);
+
+val = qht_lookup(>s->qpp_table, , hash);
+
+if (!val) {
+if (pdu->s->qp_prefix_next == 0) {
+/* we ran out of prefixes */
+return -ENFILE;
+}
+
+val = 

[Qemu-devel] [PATCH v4 5/5] 9p: Use variable length suffixes for inode remapping

[Christian Schoenebeck via Qemu-devel]

Use variable length suffixes for inode remapping instead of the fixed 16
bit size prefixes before. With this change the inode numbers on guest will
typically be much smaller (e.g. around >2^1 .. >2^7 instead of >2^48 with
the previous fixed size inode remapping.

Additionally this solution should be more efficient, since inode numbers in
practice can take almost their entire 64 bit range on guest as well. Which
might also be beneficial for nested virtualization.

The "Exponential Golomb" algorithm is used as basis for generating the
variable length suffixes. The algorithm has a paramter k which controls the
distribution of bits on increasing indeces (minimum bits at low index vs.
maximum bits at high index). With k=0 the generated suffixes look like:

Index Dec/Bin -> Generated Suffix Bin
1 [1] -> [1] (1 bits)
2 [10] -> [010] (3 bits)
3 [11] -> [110] (3 bits)
4 [100] -> [00100] (5 bits)
5 [101] -> [10100] (5 bits)
6 [110] -> [01100] (5 bits)
7 [111] -> [11100] (5 bits)
8 [1000] -> [0001000] (7 bits)
9 [1001] -> [1001000] (7 bits)
10 [1010] -> [0101000] (7 bits)
11 [1011] -> [1101000] (7 bits)
12 [1100] -> [0011000] (7 bits)
...
65533 [1101] ->  [1011000] (31 bits)
65534 [1110] ->  [0111000] (31 bits)
65535 [] ->  [000] (31 bits)
Hence minBits=1 maxBits=31

And with k=5 they would look like:

Index Dec/Bin -> Generated Suffix Bin
1 [1] -> [01] (6 bits)
2 [10] -> [11] (6 bits)
3 [11] -> [010001] (6 bits)
4 [100] -> [110001] (6 bits)
5 [101] -> [001001] (6 bits)
6 [110] -> [101001] (6 bits)
7 [111] -> [011001] (6 bits)
8 [1000] -> [111001] (6 bits)
9 [1001] -> [000101] (6 bits)
10 [1010] -> [100101] (6 bits)
11 [1011] -> [010101] (6 bits)
12 [1100] -> [110101] (6 bits)
...
65533 [1101] -> [001110001000] (28 bits)
65534 [1110] -> [101110001000] (28 bits)
65535 [] -> [00001000] (28 bits)
Hence minBits=6 maxBits=28

Signed-off-by: Christian Schoenebeck 
---
 hw/9pfs/9p.c | 267 ++-
 hw/9pfs/9p.h |  67 ++-
 2 files changed, 312 insertions(+), 22 deletions(-)

diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
index e6e410972f..46c9f11384 100644
--- a/hw/9pfs/9p.c
+++ b/hw/9pfs/9p.c
@@ -26,6 +26,7 @@
 #include "migration/blocker.h"
 #include "sysemu/qtest.h"
 #include "qemu/xxhash.h"
+#include 
 
 int open_fd_hw;
 int total_open_fd;
@@ -572,6 +573,123 @@ static void coroutine_fn virtfs_reset(V9fsPDU *pdu)
 P9_STAT_MODE_NAMED_PIPE |   \
 P9_STAT_MODE_SOCKET)
 
+#if P9_VARI_LENGTH_INODE_SUFFIXES
+
+/* Mirrors all bits of a byte. So e.g. binary 1010 would become 0101. 
*/
+static inline uint8_t mirror8bit(uint8_t byte) {
+return (byte * 0x0202020202ULL & 0x010884422010ULL) % 1023;
+}
+
+/* Same as mirror8bit() just for a 64 bit data type instead for a byte. */
+static inline uint64_t mirror64bit(uint64_t value) {
+return ((uint64_t)mirror8bit( value& 0xff) << 56) |
+   ((uint64_t)mirror8bit((value >> 8)  & 0xff) << 48) |
+   ((uint64_t)mirror8bit((value >> 16) & 0xff) << 40) |
+   ((uint64_t)mirror8bit((value >> 24) & 0xff) << 32) |
+   ((uint64_t)mirror8bit((value >> 32) & 0xff) << 24) |
+   ((uint64_t)mirror8bit((value >> 40) & 0xff) << 16) |
+   ((uint64_t)mirror8bit((value >> 48) & 0xff) << 8 ) |
+   ((uint64_t)mirror8bit((value >> 56) & 0xff)  ) ;
+}
+
+/* Parameter k for the Exponential Golomb algorihm to be used.
+ *
+ * The smaller this value, the smaller the minimum bit count for the Exp.
+ * Golomb generated affixes will be (at lowest index) however for the
+ * price of having higher maximum bit count of generated affixes (at highest
+ * index). Likewise increasing this parameter yields in smaller maximum bit
+ * count for the price of having higher minimum bit count.
+ */
+#define EXP_GOLOMB_K0
+
+# if !EXP_GOLOMB_K
+
+/** @brief Exponential Golomb algorithm limited to the case k=0.
+ *
+ * See expGolombEncode() below for details.
+ *
+ * @param n - natural number (or index) of the prefix to be generated
+ *(1, 2, 3, ...)
+ */
+static VariLenAffix expGolombEncodeK0(uint64_t n) {
+const int bits = (int) log2(n) + 1;
+return (VariLenAffix) {
+.type = AffixType_Prefix,
+.value = n,
+.bits = bits + bits - 1
+};
+}
+
+# else
+
+/** @brief Exponential Golomb algorithm for arbitrary k (including k=0).
+ *
+ * The Exponential Golomb algorithm generates @b prefixes (@b not suffixes!)
+ * with growing length and with the mathematical property of being
+ * "prefix-free". The latter means the generated prefixes can be prepended
+ * in front of arbitrary numbers and the resulting concatenated numbers are
+ * guaranteed to be always unique.
+ *
+ * This 

[Qemu-devel] [PATCH v4 2/5] 9p: Treat multiple devices on one export as an error

[Christian Schoenebeck via Qemu-devel]

The QID path should uniquely identify a file. However, the
inode of a file is currently used as the QID path, which
on its own only uniquely identifies wiles within a device.
Here we track the device hosting the 9pfs share, in order
to prevent security issues with QID path collisions from
other devices.

Signed-off-by: Antonios Motakis 
Signed-off-by: Christian Schoenebeck 
---
 hw/9pfs/9p.c | 71 
 hw/9pfs/9p.h |  1 +
 2 files changed, 58 insertions(+), 14 deletions(-)

diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
index 586a6dccba..cbaa212625 100644
--- a/hw/9pfs/9p.c
+++ b/hw/9pfs/9p.c
@@ -572,10 +572,20 @@ static void coroutine_fn virtfs_reset(V9fsPDU *pdu)
 P9_STAT_MODE_SOCKET)
 
 /* This is the algorithm from ufs in spfs */
-static void stat_to_qid(const struct stat *stbuf, V9fsQID *qidp)
+static int stat_to_qid(V9fsPDU *pdu, const struct stat *stbuf, V9fsQID *qidp)
 {
 size_t size;
 
+if (pdu->s->dev_id == 0) {
+pdu->s->dev_id = stbuf->st_dev;
+} else if (pdu->s->dev_id != stbuf->st_dev) {
+error_report_once(
+"9p: Multiple devices detected in same VirtFS export. "
+"You must use a separate export for each device."
+);
+return -ENOSYS;
+}
+
 memset(>path, 0, sizeof(qidp->path));
 size = MIN(sizeof(stbuf->st_ino), sizeof(qidp->path));
 memcpy(>path, >st_ino, size);
@@ -587,6 +597,8 @@ static void stat_to_qid(const struct stat *stbuf, V9fsQID 
*qidp)
 if (S_ISLNK(stbuf->st_mode)) {
 qidp->type |= P9_QID_TYPE_SYMLINK;
 }
+
+return 0;
 }
 
 static int coroutine_fn fid_to_qid(V9fsPDU *pdu, V9fsFidState *fidp,
@@ -599,7 +611,10 @@ static int coroutine_fn fid_to_qid(V9fsPDU *pdu, 
V9fsFidState *fidp,
 if (err < 0) {
 return err;
 }
-stat_to_qid(, qidp);
+err = stat_to_qid(pdu, , qidp);
+if (err < 0) {
+return err;
+}
 return 0;
 }
 
@@ -830,7 +845,10 @@ static int coroutine_fn stat_to_v9stat(V9fsPDU *pdu, 
V9fsPath *path,
 
 memset(v9stat, 0, sizeof(*v9stat));
 
-stat_to_qid(stbuf, >qid);
+err = stat_to_qid(pdu, stbuf, >qid);
+if (err < 0) {
+return err;
+}
 v9stat->mode = stat_to_v9mode(stbuf);
 v9stat->atime = stbuf->st_atime;
 v9stat->mtime = stbuf->st_mtime;
@@ -891,7 +909,7 @@ static int coroutine_fn stat_to_v9stat(V9fsPDU *pdu, 
V9fsPath *path,
 #define P9_STATS_ALL   0x3fffULL /* Mask for All fields above */
 
 
-static void stat_to_v9stat_dotl(V9fsState *s, const struct stat *stbuf,
+static int stat_to_v9stat_dotl(V9fsPDU *pdu, const struct stat *stbuf,
 V9fsStatDotl *v9lstat)
 {
 memset(v9lstat, 0, sizeof(*v9lstat));
@@ -913,7 +931,7 @@ static void stat_to_v9stat_dotl(V9fsState *s, const struct 
stat *stbuf,
 /* Currently we only support BASIC fields in stat */
 v9lstat->st_result_mask = P9_STATS_BASIC;
 
-stat_to_qid(stbuf, >qid);
+return stat_to_qid(pdu, stbuf, >qid);
 }
 
 static void print_sg(struct iovec *sg, int cnt)
@@ -1115,7 +1133,6 @@ static void coroutine_fn v9fs_getattr(void *opaque)
 uint64_t request_mask;
 V9fsStatDotl v9stat_dotl;
 V9fsPDU *pdu = opaque;
-V9fsState *s = pdu->s;
 
 retval = pdu_unmarshal(pdu, offset, "dq", , _mask);
 if (retval < 0) {
@@ -1136,7 +1153,10 @@ static void coroutine_fn v9fs_getattr(void *opaque)
 if (retval < 0) {
 goto out;
 }
-stat_to_v9stat_dotl(s, , _dotl);
+retval = stat_to_v9stat_dotl(pdu, , _dotl);
+if (retval < 0) {
+goto out;
+}
 
 /*  fill st_gen if requested and supported by underlying fs */
 if (request_mask & P9_STATS_GEN) {
@@ -1381,7 +1401,10 @@ static void coroutine_fn v9fs_walk(void *opaque)
 if (err < 0) {
 goto out;
 }
-stat_to_qid(, );
+err = stat_to_qid(pdu, , );
+if (err < 0) {
+goto out;
+}
 v9fs_path_copy(, );
 }
 memcpy([name_idx], , sizeof(qid));
@@ -1483,7 +1506,10 @@ static void coroutine_fn v9fs_open(void *opaque)
 if (err < 0) {
 goto out;
 }
-stat_to_qid(, );
+err = stat_to_qid(pdu, , );
+if (err < 0) {
+goto out;
+}
 if (S_ISDIR(stbuf.st_mode)) {
 err = v9fs_co_opendir(pdu, fidp);
 if (err < 0) {
@@ -1593,7 +1619,10 @@ static void coroutine_fn v9fs_lcreate(void *opaque)
 fidp->flags |= FID_NON_RECLAIMABLE;
 }
 iounit =  get_iounit(pdu, >path);
-stat_to_qid(, );
+err = stat_to_qid(pdu, , );
+if (err < 0) {
+goto out;
+}
 err = pdu_marshal(pdu, offset, "Qd", , iounit);
 if (err < 0) {
 goto out;
@@ -2327,7 +2356,10 @@ static void coroutine_fn v9fs_create(void *opaque)
 }
 }
 iounit = get_iounit(pdu, >path);
-stat_to_qid(, );
+err = stat_to_qid(pdu, , );
+ 

[Qemu-devel] [PATCH v4 1/5] 9p: unsigned type for type, version, path

[Christian Schoenebeck via Qemu-devel]

There is no need for signedness on these QID fields for 9p.

Signed-off-by: Antonios Motakis 
Signed-off-by: Christian Schoenebeck 
---
 fsdev/9p-marshal.h   |  6 +++---
 hw/9pfs/9p.c |  6 +++---
 hw/9pfs/trace-events | 14 +++---
 3 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/fsdev/9p-marshal.h b/fsdev/9p-marshal.h
index c8823d878f..8f3babb60a 100644
--- a/fsdev/9p-marshal.h
+++ b/fsdev/9p-marshal.h
@@ -9,9 +9,9 @@ typedef struct V9fsString
 
 typedef struct V9fsQID
 {
-int8_t type;
-int32_t version;
-int64_t path;
+uint8_t type;
+uint32_t version;
+uint64_t path;
 } V9fsQID;
 
 typedef struct V9fsStat
diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
index 55821343e5..586a6dccba 100644
--- a/hw/9pfs/9p.c
+++ b/hw/9pfs/9p.c
@@ -743,9 +743,9 @@ static int donttouch_stat(V9fsStat *stat)
 {
 if (stat->type == -1 &&
 stat->dev == -1 &&
-stat->qid.type == -1 &&
-stat->qid.version == -1 &&
-stat->qid.path == -1 &&
+stat->qid.type == 0xff &&
+stat->qid.version == (uint32_t) -1 &&
+stat->qid.path == (uint64_t) -1 &&
 stat->mode == -1 &&
 stat->atime == -1 &&
 stat->mtime == -1 &&
diff --git a/hw/9pfs/trace-events b/hw/9pfs/trace-events
index c0a0a4ab5d..6964756922 100644
--- a/hw/9pfs/trace-events
+++ b/hw/9pfs/trace-events
@@ -6,7 +6,7 @@ v9fs_rerror(uint16_t tag, uint8_t id, int err) "tag %d id %d 
err %d"
 v9fs_version(uint16_t tag, uint8_t id, int32_t msize, char* version) "tag %d 
id %d msize %d version %s"
 v9fs_version_return(uint16_t tag, uint8_t id, int32_t msize, char* version) 
"tag %d id %d msize %d version %s"
 v9fs_attach(uint16_t tag, uint8_t id, int32_t fid, int32_t afid, char* uname, 
char* aname) "tag %u id %u fid %d afid %d uname %s aname %s"
-v9fs_attach_return(uint16_t tag, uint8_t id, int8_t type, int32_t version, 
int64_t path) "tag %d id %d type %d version %d path %"PRId64
+v9fs_attach_return(uint16_t tag, uint8_t id, uint8_t type, uint32_t version, 
uint64_t path) "tag %d id %d type %d version %d path %"PRId64
 v9fs_stat(uint16_t tag, uint8_t id, int32_t fid) "tag %d id %d fid %d"
 v9fs_stat_return(uint16_t tag, uint8_t id, int32_t mode, int32_t atime, 
int32_t mtime, int64_t length) "tag %d id %d stat={mode %d atime %d mtime %d 
length %"PRId64"}"
 v9fs_getattr(uint16_t tag, uint8_t id, int32_t fid, uint64_t request_mask) 
"tag %d id %d fid %d request_mask %"PRIu64
@@ -14,9 +14,9 @@ v9fs_getattr_return(uint16_t tag, uint8_t id, uint64_t 
result_mask, uint32_t mod
 v9fs_walk(uint16_t tag, uint8_t id, int32_t fid, int32_t newfid, uint16_t 
nwnames) "tag %d id %d fid %d newfid %d nwnames %d"
 v9fs_walk_return(uint16_t tag, uint8_t id, uint16_t nwnames, void* qids) "tag 
%d id %d nwnames %d qids %p"
 v9fs_open(uint16_t tag, uint8_t id, int32_t fid, int32_t mode) "tag %d id %d 
fid %d mode %d"
-v9fs_open_return(uint16_t tag, uint8_t id, int8_t type, int32_t version, 
int64_t path, int iounit) "tag %d id %d qid={type %d version %d path %"PRId64"} 
iounit %d"
+v9fs_open_return(uint16_t tag, uint8_t id, uint8_t type, uint32_t version, 
uint64_t path, int iounit) "tag %d id %d qid={type %d version %d path 
%"PRId64"} iounit %d"
 v9fs_lcreate(uint16_t tag, uint8_t id, int32_t dfid, int32_t flags, int32_t 
mode, uint32_t gid) "tag %d id %d dfid %d flags %d mode %d gid %u"
-v9fs_lcreate_return(uint16_t tag, uint8_t id, int8_t type, int32_t version, 
int64_t path, int32_t iounit) "tag %d id %d qid={type %d version %d path 
%"PRId64"} iounit %d"
+v9fs_lcreate_return(uint16_t tag, uint8_t id, uint8_t type, uint32_t version, 
uint64_t path, int32_t iounit) "tag %d id %d qid={type %d version %d path 
%"PRId64"} iounit %d"
 v9fs_fsync(uint16_t tag, uint8_t id, int32_t fid, int datasync) "tag %d id %d 
fid %d datasync %d"
 v9fs_clunk(uint16_t tag, uint8_t id, int32_t fid) "tag %d id %d fid %d"
 v9fs_read(uint16_t tag, uint8_t id, int32_t fid, uint64_t off, uint32_t 
max_count) "tag %d id %d fid %d off %"PRIu64" max_count %u"
@@ -26,21 +26,21 @@ v9fs_readdir_return(uint16_t tag, uint8_t id, uint32_t 
count, ssize_t retval) "t
 v9fs_write(uint16_t tag, uint8_t id, int32_t fid, uint64_t off, uint32_t 
count, int cnt) "tag %d id %d fid %d off %"PRIu64" count %u cnt %d"
 v9fs_write_return(uint16_t tag, uint8_t id, int32_t total, ssize_t err) "tag 
%d id %d total %d err %zd"
 v9fs_create(uint16_t tag, uint8_t id, int32_t fid, char* name, int32_t perm, 
int8_t mode) "tag %d id %d fid %d name %s perm %d mode %d"
-v9fs_create_return(uint16_t tag, uint8_t id, int8_t type, int32_t version, 
int64_t path, int iounit) "tag %d id %d qid={type %d version %d path %"PRId64"} 
iounit %d"
+v9fs_create_return(uint16_t tag, uint8_t id, uint8_t type, uint32_t version, 
uint64_t path, int iounit) "tag %d id %d qid={type %d version %d path 
%"PRId64"} iounit %d"
 v9fs_symlink(uint16_t tag, uint8_t id, int32_t fid,  char* name, char* 
symname, uint32_t gid) "tag %d id %d fid %d name %s symname %s 

Re: [Qemu-devel] [Qemu-block] [PATCH 00/13] hw/block/pflash_cfi02: Clean-up and fixes

[John Snow]

I don't think this series ever made it upstream, and it's now well past
30 days, so I might encourage a resend when you can if this is still
important to pursue.

--js

On 5/5/19 6:15 PM, Philippe Mathieu-Daudé wrote:
> Hi,
> 
> While reviewing Stephen Checkoway's v4 "Implement missing AMD
> pflash functionality" [*] I found it hard (for me) to digest,
> so I took step by step notes. This series is the result of
> those notes.
> Regarding Stephen's series, this series only contains the
> generic code movement and trivial cleanup. The other patches
> are rather dense and I need more time to study the specs.
> 
> Stephen: If you take out the patch #2 ("Use the GLib API"),
> you can rebase your series on top of this.
> I'd appreciate if you can adapt your tests to use the GLib
> functions, else I plan to do it later.
> 
> Regards,
> 
> Phil.
> 
> [*] https://lists.gnu.org/archive/html/qemu-devel/2019-04/msg04595.html
> 
> Philippe Mathieu-Daudé (10):
>   tests/pflash-cfi02: Use the GLib API
>   tests/pflash-cfi02: Use IEC binary prefixes for size constants
>   hw/block/pflash_cfi02: Fix debug format string
>   hw/block/pflash_cfi02: Add an enum to define the write cycles
>   hw/block/pflash_cfi02: Add helpers to manipulate the status bits
>   hw/block/pflash_cfi02: Simplify a statement using fall through
>   hw/block/pflash_cfi02: Use the ldst API in pflash_write()
>   hw/block/pflash_cfi02: Use the ldst API in pflash_read()
>   hw/block/pflash_cfi02: Extract the pflash_data_read() function
>   hw/block/pflash_cfi02: Unify the MemoryRegionOps
> 
> Stephen Checkoway (3):
>   tests/pflash-cfi02: Add test for supported CFI commands
>   hw/block/pflash_cfi02: Fix command address comparison
>   hw/block/pflash_cfi02: Use the chip erase time specified in the CFI
> table
> 
>  hw/block/pflash_cfi02.c   | 234 +-
>  tests/Makefile.include|   2 +
>  tests/pflash-cfi02-test.c | 232 +
>  3 files changed, 339 insertions(+), 129 deletions(-)
>  create mode 100644 tests/pflash-cfi02-test.c
> 

Re: [Qemu-devel] [PATCH v7 1/4] VirtIO-RNG: Update default entropy source to `/dev/urandom`

[Laurent Vivier]

On 29/05/2019 16:31, Laurent Vivier wrote:
> From: Kashyap Chamarthy 
> 
> When QEMU exposes a VirtIO-RNG device to the guest, that device needs a
> source of entropy, and that source needs to be "non-blocking", like
> `/dev/urandom`.  However, currently QEMU defaults to the problematic
> `/dev/random`, which on Linux is "blocking" (as in, it waits until
> sufficient entropy is available).
> 
> Why prefer `/dev/urandom` over `/dev/random`?
> -
> 
> The man pages of urandom(4) and random(4) state:
> 
> "The /dev/random device is a legacy interface which dates back to a
> time where the cryptographic primitives used in the implementation
> of /dev/urandom were not widely trusted.  It will return random
> bytes only within the estimated number of bits of fresh noise in the
> entropy pool, blocking if necessary.  /dev/random is suitable for
> applications that need high quality randomness, and can afford
> indeterminate delays."
> 
> Further, the "Usage" section of the said man pages state:
> 
> "The /dev/random interface is considered a legacy interface, and
> /dev/urandom is preferred and sufficient in all use cases, with the
> exception of applications which require randomness during early boot
> time; for these applications, getrandom(2) must be used instead,
> because it will block until the entropy pool is initialized.
> 
> "If a seed file is saved across reboots as recommended below (all
> major Linux distributions have done this since 2000 at least), the
> output is cryptographically secure against attackers without local
> root access as soon as it is reloaded in the boot sequence, and
> perfectly adequate for network encryption session keys.  Since reads
> from /dev/random may block, users will usually want to open it in
> nonblocking mode (or perform a read with timeout), and provide some
> sort of user notification if the desired entropy is not immediately
> available."
> 
> And refer to random(7) for a comparison of `/dev/random` and
> `/dev/urandom`.
> 
> What about other OSes?
> --
> 
> `/dev/urandom` exists and works on OS-X, FreeBSD, DragonFlyBSD, NetBSD
> and OpenBSD, which cover all the non-Linux platforms we explicitly
> support, aside from Windows.
> 
> On Windows `/dev/random` doesn't work either so we don't regress.
> This is actually another argument in favour of using the newly
> proposed 'rng-builtin' backend by default, as that will work on
> Windows.
> 
> - - -
> 
> Given the above, change the entropy source for VirtIO-RNG device to
> `/dev/urandom`.
> 
> Related discussion in these[1][2] past threads.
> 
> [1] https://lists.nongnu.org/archive/html/qemu-devel/2018-06/msg08335.html
> -- "RNG: Any reason QEMU doesn't default to `/dev/urandom`?"
> [2] https://lists.nongnu.org/archive/html/qemu-devel/2018-09/msg02724.html
> -- "[RFC] Virtio RNG: Consider changing the default entropy source to
>/dev/urandom"
> 
> Signed-off-by: Kashyap Chamarthy 
> Reviewed-by: Daniel P. Berrangé 
> Reviewed-by: Stefan Hajnoczi 
> Reviewed-by: Markus Armbruster 
> Signed-off-by: Laurent Vivier 
> ---
>  backends/rng-random.c | 2 +-
>  qemu-options.hx   | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/backends/rng-random.c b/backends/rng-random.c
> index e2a49b0571d7..eff36ef14084 100644
> --- a/backends/rng-random.c
> +++ b/backends/rng-random.c
> @@ -112,7 +112,7 @@ static void rng_random_init(Object *obj)
>  rng_random_set_filename,
>  NULL);
>  
> -s->filename = g_strdup("/dev/random");
> +s->filename = g_strdup("/dev/urandom");
>  s->fd = -1;
>  }
>  
> diff --git a/qemu-options.hx b/qemu-options.hx
> index 39dc17042967..f6e9bd1d9c42 100644
> --- a/qemu-options.hx
> +++ b/qemu-options.hx
> @@ -4328,7 +4328,7 @@ Creates a random number generator backend which obtains 
> entropy from
>  a device on the host. The @option{id} parameter is a unique ID that
>  will be used to reference this entropy backend from the @option{virtio-rng}
>  device. The @option{filename} parameter specifies which file to obtain
> -entropy from and if omitted defaults to @option{/dev/random}.
> +entropy from and if omitted defaults to @option{/dev/urandom}.
>  
>  @item -object rng-egd,id=@var{id},chardev=@var{chardevid}
>  
> 

I can push this one via a trivial-branch pull request if no one thinks
other patches of the series are ready to be merged.

Thanks,
Laurent

Re: [Qemu-devel] [PATCH v4 0/7] tcg/ppc: Add vector opcodes

[BALATON Zoltan]

On Wed, 26 Jun 2019, Mark Cave-Ayland wrote:

On 26/06/2019 19:42, Richard Henderson wrote:


On 6/26/19 7:00 PM, Mark Cave-Ayland wrote:

Interestingly if I set a trap and then switch the opcode to "lis r4,0" 
(0x3c80)
then we carry on as normal until the next "lis r2,0" instruction. Looking 
through the
whole output of -d out_asm this is the first mention of r2 which makes me 
wonder if
it is special somehow? At least a quick search indicates that for 32-bit PPC r2 
is
supposed to be dedicated as a TOC pointer.

Is there a quick way to disable r2 from the list of available registers to see 
if
that gets things going?


Interesting.  I'm not sure why that's happening.

As a quick hack,


  /* For some memory operations, we need a scratch that isn't R0.  For the AIX
 calling convention, we can re-use the TOC register since we'll be reloading
 it at every call.  Otherwise R12 will do nicely as neither a call-saved
 register nor a parameter register.  */
- #ifdef _CALL_AIX
+ #if 0
  # define TCG_REG_TMP1   TCG_REG_R2
  #else
  # define TCG_REG_TMP1   TCG_REG_R12
  #endif


But I thought that _CALL_AIX was only defined for ppc64 elf version 1.  I
thought that ppc32 used _CALL_SYSV instead.  Certainly that's what is used
elsewhere...


No, that didn't work either. I've confirmed using #ifdef _CALL_AIX #error ERROR
#endif that _CALL_AIX is *NOT* defined and _CALL_SYSV *is* defined.

I've also tried removing TCG_REG_R2 from tcg_target_reg_alloc_order[] and
tcg_regset_set_reg() for TCG_REG_R2 from tcg_target_init() and I'm still 
generating
bad code that writes to r2(!).

Since I can't find any other mentions of TCG_REG_TMP1 and TCG_REG_R2 that isn't
inside an #ifdef _CALL_AIX ... #endif section I'm starting to get stuck. Is 
there any
chance that the R_PPC_ADDR32 change could be causing this at all?


There's one more mention of TCG_REG_R2 in tcg-target.inc.c 
tcg_target_init() function where it's set as call clobber but then later 
in same func again as reserved if _CALL_SYSV or 64 bits. Not sure if the 
later tcg_regset_set_reg overrides the first one or that should be removed 
or put in an #else of the later conditional call. (Still don't know what 
I'm talking about just trowing random ideas.)


Regards,
BALATON Zoltan

[Qemu-devel] [PULL 0/4] Trivial patches patches

[Laurent Vivier]

The following changes since commit 474f3938d79ab36b9231c9ad3b5a9314c2aeacde:

  Merge remote-tracking branch 'remotes/amarkovic/tags/mips-queue-jun-21-2019' 
into staging (2019-06-21 15:40:50 +0100)

are available in the Git repository at:

  git://github.com/vivier/qemu.git tags/trivial-patches-pull-request

for you to fetch changes up to b827891d73778eaf962b0536f955194cf4faa424:

  MAINTAINERS: Change maintership of Xen code under hw/9pfs (2019-06-26 
18:30:03 +0200)


configure improvements and fixes
MAINTAINERS update



Antonio Ospite (2):
  configure: set source_path only once and make its definition more
robust
  configure: disallow spaces and colons in source path and build path

Daniel P. Berrangé (1):
  configure: use valid args testing sem_timedwait

Greg Kurz (1):
  MAINTAINERS: Change maintership of Xen code under hw/9pfs

 MAINTAINERS |  3 ++-
 Makefile|  4 
 configure   | 13 +
 3 files changed, 15 insertions(+), 5 deletions(-)

-- 
2.21.0

[Qemu-devel] [PULL 2/4] configure: disallow spaces and colons in source path and build path

[Laurent Vivier]

From: Antonio Ospite 

The configure script breaks when the qemu source directory is in a path
containing white spaces, in particular the list of targets is not
correctly generated when calling "./configure --help" because of how the
default_target_list variable is built.

In addition to that, *building* qemu from a directory with spaces breaks
some assumptions in the Makefiles, even if the original source path does
not contain spaces like in the case of an out-of-tree build, or when
symlinks are involved.

To avoid these issues, refuse to run the configure script and the
Makefile if there are spaces or colons in the source path or the build
path, taking as inspiration what the kbuild system in linux does.

Buglink: https://bugs.launchpad.net/qemu/+bug/1817345

Reviewed-by: Eric Blake 
Signed-off-by: Antonio Ospite 
Message-Id: <20190526144747.30019-3-...@ao2.it>
Signed-off-by: Laurent Vivier 
---
 Makefile  | 4 
 configure | 5 +
 2 files changed, 9 insertions(+)

diff --git a/Makefile b/Makefile
index cfb18f152544..c62594445d5f 100644
--- a/Makefile
+++ b/Makefile
@@ -1,5 +1,9 @@
 # Makefile for QEMU.
 
+ifneq ($(words $(subst :, ,$(CURDIR))), 1)
+  $(error main directory cannot contain spaces nor colons)
+endif
+
 # Always point to the root of the build tree (needs GNU make).
 BUILD_DIR=$(CURDIR)
 
diff --git a/configure b/configure
index b6962d1381a5..cf3d9d30bfce 100755
--- a/configure
+++ b/configure
@@ -279,6 +279,11 @@ ld_has() {
 # make source path absolute
 source_path=$(cd "$(dirname -- "$0")"; pwd)
 
+if printf %s\\n "$source_path" "$PWD" | grep -q "[[:space:]:]";
+then
+  error_exit "main directory cannot contain spaces nor colons"
+fi
+
 # default parameters
 cpu=""
 iasl="iasl"
-- 
2.21.0

[Qemu-devel] [PULL 4/4] MAINTAINERS: Change maintership of Xen code under hw/9pfs

[Laurent Vivier]

From: Greg Kurz 

Xen folks are the actual maintainers for this.

Signed-off-by: Greg Kurz 
Reviewed-by: Philippe Mathieu-Daudé 
Acked-by: Anthony PERARD 
Acked-by: Paul Durrant 
Acked-by: Stefano Stabellini 
Message-Id: <155912548463.2019004.3515830305299809902.st...@bahia.lan>
Signed-off-by: Laurent Vivier 
---
 MAINTAINERS | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index cad58b948791..8206fc51dbbc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -408,7 +408,7 @@ M: Paul Durrant 
 L: xen-de...@lists.xenproject.org
 S: Supported
 F: */xen*
-F: hw/9pfs/xen-9p-backend.c
+F: hw/9pfs/xen-9p*
 F: hw/char/xen_console.c
 F: hw/display/xenfb.c
 F: hw/net/xen_nic.c
@@ -1498,6 +1498,7 @@ virtio-9p
 M: Greg Kurz 
 S: Supported
 F: hw/9pfs/
+X: hw/9pfs/xen-9p*
 F: fsdev/
 F: tests/virtio-9p-test.c
 T: git https://github.com/gkurz/qemu.git 9p-next
-- 
2.21.0

[Qemu-devel] [PULL 3/4] configure: use valid args testing sem_timedwait

[Laurent Vivier]

From: Daniel P. Berrangé 

The sem_timedwait function has been annotated as requiring
non-null args in latest header files from GCC snapshot
representing the future 2.30 release.

This causes configure to fail when -Werror is used:

config-temp/qemu-conf.c: In function ‘main’:
config-temp/qemu-conf.c:2:25: error: null argument where non-null required 
(argument 1) [-Werror=nonnull]
2 | int main(void) { return sem_timedwait(0, 0); }
  | ^
config-temp/qemu-conf.c:2:25: error: null argument where non-null required 
(argument 2) [-Werror=nonnull]

Signed-off-by: Daniel P. Berrangé 
Reviewed-by: Laurent Vivier 
Message-Id: <20190617114114.24897-1-berra...@redhat.com>
Signed-off-by: Laurent Vivier 
---
 configure | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure b/configure
index cf3d9d30bfce..f94633101094 100755
--- a/configure
+++ b/configure
@@ -5144,7 +5144,7 @@ fi
 sem_timedwait=no
 cat > $TMPC << EOF
 #include 
-int main(void) { return sem_timedwait(0, 0); }
+int main(void) { sem_t s; struct timespec t = {0}; return sem_timedwait(, 
); }
 EOF
 if compile_prog "" "" ; then
 sem_timedwait=yes
-- 
2.21.0

[Qemu-devel] [PULL 1/4] configure: set source_path only once and make its definition more robust

[Laurent Vivier]

From: Antonio Ospite 

Since commit 79d77bcd36 (configure: Remove --source-path option,
2019-04-29) source_path cannot be overridden anymore, move it out of the
"default parameters" block since the word "default" may suggest that the
value can change, while in fact it does not.

While at it, only set source_path once and separate the positional
argument of basename with "--" to more robustly cover the case of path
names starting with a dash.

Reviewed-by: Eric Blake 
Signed-off-by: Antonio Ospite 
Message-Id: <20190526144747.30019-2-...@ao2.it>
Signed-off-by: Laurent Vivier 
---
 configure | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/configure b/configure
index b091b82cb371..b6962d1381a5 100755
--- a/configure
+++ b/configure
@@ -276,10 +276,10 @@ ld_has() {
 $ld --help 2>/dev/null | grep ".$1" >/dev/null 2>&1
 }
 
-# default parameters
-source_path=$(dirname "$0")
 # make source path absolute
-source_path=$(cd "$source_path"; pwd)
+source_path=$(cd "$(dirname -- "$0")"; pwd)
+
+# default parameters
 cpu=""
 iasl="iasl"
 interp_prefix="/usr/gnemul/qemu-%M"
-- 
2.21.0

Re: [Qemu-devel] [PATCH v4 0/7] tcg/ppc: Add vector opcodes

[Mark Cave-Ayland]

On 26/06/2019 19:42, Richard Henderson wrote:

> On 6/26/19 7:00 PM, Mark Cave-Ayland wrote:
>> Interestingly if I set a trap and then switch the opcode to "lis r4,0" 
>> (0x3c80)
>> then we carry on as normal until the next "lis r2,0" instruction. Looking 
>> through the
>> whole output of -d out_asm this is the first mention of r2 which makes me 
>> wonder if
>> it is special somehow? At least a quick search indicates that for 32-bit PPC 
>> r2 is
>> supposed to be dedicated as a TOC pointer.
>>
>> Is there a quick way to disable r2 from the list of available registers to 
>> see if
>> that gets things going?
> 
> Interesting.  I'm not sure why that's happening.
> 
> As a quick hack,
> 
> 
>   /* For some memory operations, we need a scratch that isn't R0.  For the AIX
>  calling convention, we can re-use the TOC register since we'll be 
> reloading
>  it at every call.  Otherwise R12 will do nicely as neither a call-saved
>  register nor a parameter register.  */
> - #ifdef _CALL_AIX
> + #if 0
>   # define TCG_REG_TMP1   TCG_REG_R2
>   #else
>   # define TCG_REG_TMP1   TCG_REG_R12
>   #endif
> 
> 
> But I thought that _CALL_AIX was only defined for ppc64 elf version 1.  I
> thought that ppc32 used _CALL_SYSV instead.  Certainly that's what is used
> elsewhere...

No, that didn't work either. I've confirmed using #ifdef _CALL_AIX #error ERROR
#endif that _CALL_AIX is *NOT* defined and _CALL_SYSV *is* defined.

I've also tried removing TCG_REG_R2 from tcg_target_reg_alloc_order[] and
tcg_regset_set_reg() for TCG_REG_R2 from tcg_target_init() and I'm still 
generating
bad code that writes to r2(!).

Since I can't find any other mentions of TCG_REG_TMP1 and TCG_REG_R2 that isn't
inside an #ifdef _CALL_AIX ... #endif section I'm starting to get stuck. Is 
there any
chance that the R_PPC_ADDR32 change could be causing this at all?


ATB,

Mark.

Re: [Qemu-devel] [PULL 02/11] vhost-user: check unix_listen() return value

[Marc-André Lureau]

Hi

On Wed, Jun 26, 2019 at 7:56 PM Eric Blake  wrote:
>
> On 6/16/19 4:36 PM, Michael S. Tsirkin wrote:
> > From: Marc-André Lureau 
> >
> > This check shouldn't be necessary, since _fatal is given as
> > argument and will exit() on failure. However, this change should
> > silence coverity CID 1401761 & 1401705.
> >
> > Signed-off-by: Marc-André Lureau 
> > Message-Id: <20190605145829.7674-3-marcandre.lur...@redhat.com>
> > Reviewed-by: Michael S. Tsirkin 
> > Signed-off-by: Michael S. Tsirkin 
> > ---
> >  contrib/vhost-user-gpu/main.c   | 4 
> >  contrib/vhost-user-input/main.c | 4 
> >  2 files changed, 8 insertions(+)
> >
> > diff --git a/contrib/vhost-user-gpu/main.c b/contrib/vhost-user-gpu/main.c
> > index 9614c9422c..e0b6df5b4d 100644
> > --- a/contrib/vhost-user-gpu/main.c
> > +++ b/contrib/vhost-user-gpu/main.c
> > @@ -1160,6 +1160,10 @@ main(int argc, char *argv[])
> >
> >  if (opt_socket_path) {
> >  int lsock = unix_listen(opt_socket_path, _fatal);
> > +if (lsock < 0) {
> > +g_printerr("Failed to listen on %s.\n", opt_socket_path);
> > +exit(EXIT_FAILURE);
> > +}
>
> 4 lines to appease Coverity; wouldn't the following one-liner also do
> the trick?
>
> int lsock = unix_listen(opt_socket_path, _fatal);
> assert (lsock >= 0);

Probably, I didn't think too much about it. However looking at it now,
it would be worthwhile to report the error to the user in a friendlier
way than what error_fatal do. So I guess a follow-up patch should
introduce a local Error.

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


-- 
Marc-André Lureau

Re: [Qemu-devel] [PATCH for-4.1 v3 12/17] tcg/ppc: Initial backend support for Altivec

[Mark Cave-Ayland]

On 26/06/2019 19:36, BALATON Zoltan wrote:

> On Tue, 19 Mar 2019, Richard Henderson wrote:
>> diff --git a/tcg/ppc/tcg-target.inc.c b/tcg/ppc/tcg-target.inc.c
>> index ec8e336be8..70a64dd214 100644
>> --- a/tcg/ppc/tcg-target.inc.c
>> +++ b/tcg/ppc/tcg-target.inc.c
>> @@ -42,6 +42,9 @@
>> # define TCG_REG_TMP1   TCG_REG_R12
>> #endif
>>
>> +#define TCG_VEC_TMP1    TCG_REG_V0
>> +#define TCG_VEC_TMP2    TCG_REG_V1
>> +
>> #define TCG_REG_TB TCG_REG_R31
>> #define USE_REG_TB (TCG_TARGET_REG_BITS == 64)
>>
>> @@ -61,6 +64,7 @@
>>
>> static tcg_insn_unit *tb_ret_addr;
>>
>> +bool have_isa_altivec;
>> bool have_isa_2_06;
>> bool have_isa_3_00;
>>
>> @@ -72,39 +76,15 @@ bool have_isa_3_00;
>> #endif
>>
>> #ifdef CONFIG_DEBUG_TCG
>> -static const char * const tcg_target_reg_names[TCG_TARGET_NB_REGS] = {
>> -    "r0",
>> -    "r1",
>> -    "r2",
>> -    "r3",
>> -    "r4",
>> -    "r5",
>> -    "r6",
>> -    "r7",
>> -    "r8",
>> -    "r9",
>> -    "r10",
>> -    "r11",
>> -    "r12",
>> -    "r13",
>> -    "r14",
>> -    "r15",
>> -    "r16",
>> -    "r17",
>> -    "r18",
>> -    "r19",
>> -    "r20",
>> -    "r21",
>> -    "r22",
>> -    "r23",
>> -    "r24",
>> -    "r25",
>> -    "r26",
>> -    "r27",
>> -    "r28",
>> -    "r29",
>> -    "r30",
>> -    "r31"
>> +static const char tcg_target_reg_names[TCG_TARGET_NB_REGS][4] = {
>> +    "r0",  "r1",  "r2",  "r3",  "r4",  "r5",  "r6",  "r7",
>> +    "r8",  "r9",  "r10", "r11", "r12", "r13", "r14", "r15",
>> +    "r16", "r17", "r18", "r19", "r20", "r21", "r22", "r23",
>> +    "r24", "r25", "r26", "r27", "r28", "r29", "r30", "r31",
>> +    "v0",  "v1",  "v2",  "v3",  "v4",  "v5",  "v6",  "v7",
>> +    "v8",  "v9",  "v10", "v11", "v12", "v13", "v14", "v15",
>> +    "v16", "v17", "v18", "v19", "v20", "v21", "v22", "v23",
>> +    "v24", "v25", "v26", "v27", "v28", "v29", "v30", "v31",
>> };
>> #endif
>>
>> @@ -139,6 +119,26 @@ static const int tcg_target_reg_alloc_order[] = {
>>     TCG_REG_R5,
>>     TCG_REG_R4,
>>     TCG_REG_R3,
> 
> Purely guessing without knowing anything about this but would removing 
> TCG_REG_R2
> from this tcg_target_reg_alloc_order[] list help? Question is why it was not a
> problem before?

Thanks for the suggestion, but I've just tried it and it doesn't seem to make 
any
difference :(


ATB,

Mark.

Re: [Qemu-devel] [PATCH v4 0/7] tcg/ppc: Add vector opcodes

[Richard Henderson]

On 6/26/19 7:00 PM, Mark Cave-Ayland wrote:
> Interestingly if I set a trap and then switch the opcode to "lis r4,0" 
> (0x3c80)
> then we carry on as normal until the next "lis r2,0" instruction. Looking 
> through the
> whole output of -d out_asm this is the first mention of r2 which makes me 
> wonder if
> it is special somehow? At least a quick search indicates that for 32-bit PPC 
> r2 is
> supposed to be dedicated as a TOC pointer.
> 
> Is there a quick way to disable r2 from the list of available registers to 
> see if
> that gets things going?

Interesting.  I'm not sure why that's happening.

As a quick hack,


  /* For some memory operations, we need a scratch that isn't R0.  For the AIX
 calling convention, we can re-use the TOC register since we'll be reloading
 it at every call.  Otherwise R12 will do nicely as neither a call-saved
 register nor a parameter register.  */
- #ifdef _CALL_AIX
+ #if 0
  # define TCG_REG_TMP1   TCG_REG_R2
  #else
  # define TCG_REG_TMP1   TCG_REG_R12
  #endif


But I thought that _CALL_AIX was only defined for ppc64 elf version 1.  I
thought that ppc32 used _CALL_SYSV instead.  Certainly that's what is used
elsewhere...


r~

Re: [Qemu-devel] [PATCH for-4.1 v3 12/17] tcg/ppc: Initial backend support for Altivec

[BALATON Zoltan]

On Tue, 19 Mar 2019, Richard Henderson wrote:

diff --git a/tcg/ppc/tcg-target.inc.c b/tcg/ppc/tcg-target.inc.c
index ec8e336be8..70a64dd214 100644
--- a/tcg/ppc/tcg-target.inc.c
+++ b/tcg/ppc/tcg-target.inc.c
@@ -42,6 +42,9 @@
# define TCG_REG_TMP1   TCG_REG_R12
#endif

+#define TCG_VEC_TMP1TCG_REG_V0
+#define TCG_VEC_TMP2TCG_REG_V1
+
#define TCG_REG_TB TCG_REG_R31
#define USE_REG_TB (TCG_TARGET_REG_BITS == 64)

@@ -61,6 +64,7 @@

static tcg_insn_unit *tb_ret_addr;

+bool have_isa_altivec;
bool have_isa_2_06;
bool have_isa_3_00;

@@ -72,39 +76,15 @@ bool have_isa_3_00;
#endif

#ifdef CONFIG_DEBUG_TCG
-static const char * const tcg_target_reg_names[TCG_TARGET_NB_REGS] = {
-"r0",
-"r1",
-"r2",
-"r3",
-"r4",
-"r5",
-"r6",
-"r7",
-"r8",
-"r9",
-"r10",
-"r11",
-"r12",
-"r13",
-"r14",
-"r15",
-"r16",
-"r17",
-"r18",
-"r19",
-"r20",
-"r21",
-"r22",
-"r23",
-"r24",
-"r25",
-"r26",
-"r27",
-"r28",
-"r29",
-"r30",
-"r31"
+static const char tcg_target_reg_names[TCG_TARGET_NB_REGS][4] = {
+"r0",  "r1",  "r2",  "r3",  "r4",  "r5",  "r6",  "r7",
+"r8",  "r9",  "r10", "r11", "r12", "r13", "r14", "r15",
+"r16", "r17", "r18", "r19", "r20", "r21", "r22", "r23",
+"r24", "r25", "r26", "r27", "r28", "r29", "r30", "r31",
+"v0",  "v1",  "v2",  "v3",  "v4",  "v5",  "v6",  "v7",
+"v8",  "v9",  "v10", "v11", "v12", "v13", "v14", "v15",
+"v16", "v17", "v18", "v19", "v20", "v21", "v22", "v23",
+"v24", "v25", "v26", "v27", "v28", "v29", "v30", "v31",
};
#endif

@@ -139,6 +119,26 @@ static const int tcg_target_reg_alloc_order[] = {
TCG_REG_R5,
TCG_REG_R4,
TCG_REG_R3,


Purely guessing without knowing anything about this but would removing 
TCG_REG_R2 from this tcg_target_reg_alloc_order[] list help? Question is 
why it was not a problem before?


Regards,
BALATON Zoltan

Re: [Qemu-devel] [PATCH v8 10/10] hw/m68k: define Macintosh Quadra 800

[Thomas Huth]

Am Wed, 26 Jun 2019 19:51:12 +0200
schrieb Philippe Mathieu-Daudé :

> On 6/25/19 6:30 PM, Thomas Huth wrote:
> > Am Thu, 20 Jun 2019 00:19:33 +0200
> > schrieb Laurent Vivier :
> >   
> >> If you want to test the machine, it doesn't yet boot a MacROM, but
> >> you can boot a linux kernel from the command line.  
> > 
> > I gave the patch series a quick try, and was indeed able to boot the
> > Debian installer with the q800 machine, so:
> > 
> > Tested-by: Thomas Huth   
> 
> While this reply is valid for this patch, was it meant for the series'
> cover?

No, I haven't tested each and every part of this series, so this was
indeed only meant for this patch here.

 Thomas

Re: [Qemu-devel] [PATCH v2 1/4] target/mips: Fix emulation of ILVEV. on big endian host

[Richard Henderson]

On 6/20/19 3:45 PM, Aleksandar Markovic wrote:
> From: Aleksandar Markovic 
> 
> Fix emulation of ILVEV. on big endian host by applying
> mapping of data element indexes from one endian to another.
> 
> Signed-off-by: Aleksandar Markovic 
> Reviewed-by: Aleksandar Rikalo 
> ---
>  target/mips/msa_helper.c | 37 +
>  1 file changed, 37 insertions(+)
> 
> diff --git a/target/mips/msa_helper.c b/target/mips/msa_helper.c
> index be059a3..215d8af 100644
> --- a/target/mips/msa_helper.c
> +++ b/target/mips/msa_helper.c
> @@ -1737,6 +1737,24 @@ void helper_msa_ilvev_df(CPUMIPSState *env, uint32_t 
> df, uint32_t wd,
>  
>  switch (df) {
>  case DF_BYTE:
> +#if defined(TARGET_WORDS_BIGENDIAN)

The commit message talks about the endianness of the host, whereas this check
is for the endianness of the target.


> +pwd->b[8]  = pws->b[9];
> +pwd->b[9]  = pwt->b[9];
> +pwd->b[10] = pws->b[11];
> +pwd->b[11] = pwt->b[11];
> +pwd->b[12] = pws->b[13];
> +pwd->b[13] = pwt->b[13];
> +pwd->b[14] = pws->b[15];
> +pwd->b[15] = pwt->b[15];
> +pwd->b[0]  = pws->b[1];
> +pwd->b[1]  = pwt->b[1];
> +pwd->b[2]  = pws->b[3];
> +pwd->b[3]  = pwt->b[3];
> +pwd->b[4]  = pws->b[5];
> +pwd->b[5]  = pwt->b[5];
> +pwd->b[6]  = pws->b[7];
> +pwd->b[7]  = pwt->b[7];
> +#else
>  pwd->b[15] = pws->b[14];
>  pwd->b[14] = pwt->b[14];
>  pwd->b[13] = pws->b[12];

FWIW, avoiding this sort of duplication is why other targets define helper
macros like

PPC:
#define VsrB(i) u8[15 - (i)]
etc

ARM, S390:
/* Note that vector data is stored in host-endian 64-bit chunks,
   so addressing units smaller than that needs a host-endian fixup.  */
#ifdef HOST_WORDS_BIGENDIAN
#define H1(x)  ((x) ^ 7)
etc


r~

Re: [Qemu-devel] [PATCH 1/8] target/ppc: Optimize emulation of lvsl and lvsr instructions

[Richard Henderson]

On 6/19/19 1:03 PM, Stefan Brankovic wrote:
> +/* Get sh(from description) by anding EA with 0xf. */
> +gen_addr_reg_index(ctx, EA);
> +tcg_gen_ext_i32_i64(sh, EA);

>From patchew, this fails to build one of the ppc*-linux-user configurations.

You need to use tcg_gen_extu_tl_i64().


r~

[Qemu-devel] [PATCH] hw/sd/aspeed_sdhci: New device

[Eddie James]

The Aspeed SOCs have two SD/MMC controllers. Add a device that
encapsulates both of these controllers and models the Aspeed-specific
registers and behavior.

Both controllers use a single HW interrupt. In order to trigger that
interrupt, a function pointer was added to the generic SDHCI structure.
This function (if the pointer is set) is called when the SDHCI model
changes it's interrupt status, allowing the user (the Aspeed SDHCI
model in this case) to set it's own interrupt.

This goes on top of Cedric's set of Aspeed changes.

Tested, booted, and read from /dev/mmcblk0 and /dev/mmcblk1:
./arm-softmmu/qemu-system-arm -M ast2500-evb -nographic \
 -drive file=flash-romulus,format=raw,if=mtd \
 -drive file=,format=raw,if=sd \
 -drive file=,format=raw,if=sd \
 -kernel zImage \
 -dtb aspeed-ast2500-evb.dtb \
 -initrd romulus.cpio.lzma \
 -d trace:sdhci* -no-reboot

Signed-off-by: Eddie James 
---
 hw/arm/aspeed.c  |   1 -
 hw/arm/aspeed_soc.c  |  67 ++
 hw/sd/Makefile.objs  |   1 +
 hw/sd/aspeed_sdhci.c | 163 +++
 hw/sd/sdhci.c|   8 ++-
 include/hw/arm/aspeed_soc.h  |   3 +
 include/hw/sd/aspeed_sdhci.h |  39 +++
 include/hw/sd/sdhci.h|   1 +
 8 files changed, 281 insertions(+), 2 deletions(-)
 create mode 100644 hw/sd/aspeed_sdhci.c
 create mode 100644 include/hw/sd/aspeed_sdhci.h

diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
index 5fee2f5..fbec946 100644
--- a/hw/arm/aspeed.c
+++ b/hw/arm/aspeed.c
@@ -422,7 +422,6 @@ static void aspeed_machine_class_init(ObjectClass *oc, void 
*data)
 mc->desc = board->desc;
 mc->init = aspeed_machine_init;
 mc->max_cpus = ASPEED_CPUS_NUM;
-mc->no_sdcard = 1;
 mc->no_floppy = 1;
 mc->no_cdrom = 1;
 mc->no_parallel = 1;
diff --git a/hw/arm/aspeed_soc.c b/hw/arm/aspeed_soc.c
index 1bbbdae..1378498 100644
--- a/hw/arm/aspeed_soc.c
+++ b/hw/arm/aspeed_soc.c
@@ -22,6 +22,7 @@
 #include "qemu/error-report.h"
 #include "hw/i2c/aspeed_i2c.h"
 #include "net/net.h"
+#include "sysemu/blockdev.h"
 
 #define ASPEED_SOC_IOMEM_SIZE   0x0020
 
@@ -62,6 +63,7 @@ static const hwaddr aspeed_soc_ast2500_memmap[] = {
 [ASPEED_XDMA]   = 0x1E6E7000,
 [ASPEED_ADC]= 0x1E6E9000,
 [ASPEED_SRAM]   = 0x1E72,
+[ASPEED_SDHCI]  = 0x1E74,
 [ASPEED_GPIO]   = 0x1E78,
 [ASPEED_RTC]= 0x1E781000,
 [ASPEED_TIMER1] = 0x1E782000,
@@ -142,6 +144,7 @@ static const int aspeed_soc_ast2400_irqmap[] = {
 [ASPEED_ETH1]   = 2,
 [ASPEED_ETH2]   = 3,
 [ASPEED_XDMA]   = 6,
+[ASPEED_SDHCI]  = 26,
 };
 
 #define aspeed_soc_ast2500_irqmap aspeed_soc_ast2400_irqmap
@@ -378,6 +381,16 @@ static void aspeed_soc_init(Object *obj)
 sysbus_init_child_obj(obj, "fsi[*]", OBJECT(>fsi[0]),
   sizeof(s->fsi[0]), TYPE_ASPEED_FSI);
 }
+
+sysbus_init_child_obj(obj, "sdhci", OBJECT(>sdhci), sizeof(s->sdhci),
+  TYPE_ASPEED_SDHCI);
+
+for (i = 0; i < ASPEED_SDHCI_NUM_SLOTS; ++i) {
+sysbus_init_child_obj(obj, "sdhci_slot[*]",
+  OBJECT(>sdhci.slots[i].sdhci),
+  sizeof(s->sdhci.slots[i].sdhci),
+  TYPE_SYSBUS_SDHCI);
+}
 }
 
 static void aspeed_soc_realize(DeviceState *dev, Error **errp)
@@ -699,6 +712,60 @@ static void aspeed_soc_realize(DeviceState *dev, Error 
**errp)
 sysbus_connect_irq(SYS_BUS_DEVICE(>fsi[0]), 0,
aspeed_soc_get_irq(s, ASPEED_FSI1));
 }
+
+/* SD/SDIO */
+for (i = 0; i < ASPEED_SDHCI_NUM_SLOTS; i++) {
+hwaddr hci_addr = sc->info->memmap[ASPEED_SDHCI] + (0x100 * (i + 1));
+DriveInfo *di;
+BlockBackend *blk;
+DeviceState *card;
+
+/*
+ * Compatible with:
+ * - SD Host Controller Specification Version 2.0
+ * - SDIO Specification Version 2.0
+ * - MMC Specification Version 4.3
+ */
+object_property_set_int(OBJECT(>sdhci.slots[i].sdhci), 2,
+"sd-spec-version", );
+if (err) {
+error_propagate(errp, err);
+return;
+}
+
+object_property_set_uint(OBJECT(>sdhci.slots[i].sdhci),
+ ASPEED_SDHCI_CAPABILITIES, "capareg", );
+if (err) {
+error_propagate(errp, err);
+return;
+}
+
+object_property_set_bool(OBJECT(>sdhci.slots[i].sdhci), true,
+ "realized", );
+if (err) {
+error_propagate(errp, err);
+return;
+}
+
+sysbus_mmio_map(SYS_BUS_DEVICE(>sdhci.slots[i].sdhci), 0, hci_addr);
+
+di = drive_get_next(IF_SD);
+blk = di ? blk_by_legacy_dinfo(di) : NULL;
+card = qdev_create(qdev_get_child_bus(DEVICE(>sdhci.slots[i].sdhci),
+  

Re: [Qemu-devel] [PATCH 6/8] target/ppc: Optimize emulation of vclzw instruction

[Richard Henderson]

On 6/19/19 1:03 PM, Stefan Brankovic wrote:
> Optimize Altivec instruction vclzw (Vector Count Leading Zeros Word).
> This instruction counts the number of leading zeros of each word element
> in source register and places result in the appropriate word element of
> destination register.
> 
> Counting is to be performed in four iterations of for loop(one for each
> word elemnt of source register vB). Every iteration consists of loading
> appropriate word element from source register, counting leading zeros
> with tcg_gen_clzi_i32, and saving the result in appropriate word element
> of destination register.
> 
> Signed-off-by: Stefan Brankovic 
> ---
>  target/ppc/helper.h |  1 -
>  target/ppc/int_helper.c |  3 ---
>  target/ppc/translate/vmx-impl.inc.c | 28 +++-
>  3 files changed, 27 insertions(+), 5 deletions(-)

Reviewed-by: Richard Henderson 


r~

Re: [Qemu-devel] [PATCH 2/8] target/ppc: Optimize emulation of vsl and vsr instructions

[Richard Henderson]

On 6/19/19 1:03 PM, Stefan Brankovic wrote:
> Optimization of altivec instructions vsl and vsr(Vector Shift Left/Rigt).
> Perform shift operation (left and right respectively) on 128 bit value of
> register vA by value specified in bits 125-127 of register vB. Lowest 3
> bits in each byte element of register vB must be identical or result is
> undefined.
> 
> For vsl instruction, the first step is bits 125-127 of register vB have
> to be saved in variable sh. Then, the highest sh bits of the lower
> doubleword element of register vA are saved in variable shifted,
> in order not to lose those bits when shift operation is performed on
> the lower doubleword element of register vA, which is the next
> step. After shifting the lower doubleword element shift operation
> is performed on higher doubleword element of vA, with replacement of
> the lowest sh bits(that are now 0) with bits saved in shifted.
> 
> For vsr instruction, firstly, the bits 125-127 of register vB have
> to be saved in variable sh. Then, the lowest sh bits of the higher
> doubleword element of register vA are saved in variable shifted,
> in odred not to lose those bits when the shift operation is
> performed on the higher doubleword element of register vA, which is
> the next step. After shifting higher doubleword element, shift operation
> is performed on lower doubleword element of vA, with replacement of
> highest sh bits(that are now 0) with bits saved in shifted.
> 
> Signed-off-by: Stefan Brankovic 
> ---
>  target/ppc/helper.h |  2 -
>  target/ppc/int_helper.c | 35 -
>  target/ppc/translate/vmx-impl.inc.c | 99 
> -
>  3 files changed, 97 insertions(+), 39 deletions(-)

Reviewed-by: Richard Henderson 


r~

Re: [Qemu-devel] [PATCH v4 0/7] tcg/ppc: Add vector opcodes

[Richard Henderson]

On 6/26/19 10:33 AM, David Gibson wrote:
>>> out of curiosity: is your Power9 system BE or LE?
>>
>> The Power9 is LE.
> 
> It's the kernel determines endianness, not the system.

Yes.  Lazy verbiage on my part -- I did mean "The Power9 that I have access to
is configured as LE".


r~

Re: [Qemu-devel] [PATCH v2 12/14] target/arm/kvm: scratch vcpu: Preserve input kvm_vcpu_init features

[Richard Henderson]

On 6/21/19 6:34 PM, Andrew Jones wrote:
> kvm_arm_create_scratch_host_vcpu() takes a struct kvm_vcpu_init
> parameter. Rather than just using it as an output parameter to
> pass back the preferred target, use it also as an input parameter,
> allowing a caller to pass a selected target if they wish and to
> also pass cpu features. If the caller doesn't want to select a
> target they can pass -1 for the target which indicates they want
> to use the preferred target and have it passed back like before.
> 
> Signed-off-by: Andrew Jones 
> ---
>  target/arm/kvm.c   | 20 +++-
>  target/arm/kvm32.c |  6 +-
>  target/arm/kvm64.c |  6 +-
>  3 files changed, 25 insertions(+), 7 deletions(-)

Reviewed-by: Richard Henderson 


r~

Re: [Qemu-devel] [PATCH v2 10/14] target/arm/kvm64: Add kvm_arch_get/put_sve

[Richard Henderson]

On 6/21/19 6:34 PM, Andrew Jones wrote:
> +/*
> + * If ARM_MAX_VQ is increased to be greater than 16, then we can no
> + * longer hard code slices to 1 in kvm_arch_put/get_sve().
> + */
> +QEMU_BUILD_BUG_ON(ARM_MAX_VQ > 16);

This seems easy to fix, or simply drop the slices entirely for now, as
otherwise they are a teeny bit confusing.

It's a shame that these slices exist at all.  It seems like the kernel could
use the negotiated max sve size to grab the data all at once.

> +for (n = 0; n < KVM_ARM64_SVE_NUM_ZREGS; n++) {
> +uint64_t *q = aa64_vfp_qreg(env, n);
> +#ifdef HOST_WORDS_BIGENDIAN
> +uint64_t d[ARM_MAX_VQ * 2];
> +int j;
> +for (j = 0; j < cpu->sve_max_vq * 2; j++) {
> +d[j] = bswap64(q[j]);
> +}
> +reg.addr = (uintptr_t)d;
> +#else
> +reg.addr = (uintptr_t)q;
> +#endif
> +reg.id = KVM_REG_ARM64_SVE_ZREG(n, i);
> +ret = kvm_vcpu_ioctl(cs, KVM_SET_ONE_REG, );

It might be worth splitting this...

> +for (n = 0; n < KVM_ARM64_SVE_NUM_PREGS; n++) {
> +uint64_t *q = >vfp.pregs[n].p[0];
> +#ifdef HOST_WORDS_BIGENDIAN
> +uint64_t d[ARM_MAX_VQ * 2 / 8];
> +int j;
> +for (j = 0; j < cpu->sve_max_vq * 2 / 8; j++) {
> +d[j] = bswap64(q[j]);
> +}
> +reg.addr = (uintptr_t)d;
> +#else
> +reg.addr = (uintptr_t)q;
> +#endif
> +reg.id = KVM_REG_ARM64_SVE_PREG(n, i);
> +ret = kvm_vcpu_ioctl(cs, KVM_SET_ONE_REG, );

... and this (unified w/ reg + size parameters?) to a function because ...

> +reg.addr = (uintptr_t)>vfp.pregs[FFR_PRED_NUM].p[0];
> +reg.id = KVM_REG_ARM64_SVE_FFR(i);
> +ret = kvm_vcpu_ioctl(cs, KVM_SET_ONE_REG, );

... you forgot to apply the bswap here.

Likewise for the other direction.


r~


PS: It's also tempting to drop the ifdefs and, since we know the host supports
sve instructions, and that the host supports sve_max_vq, do the reformatting as

uint64_t scratch[ARM_MAX_VQ * 2];
asm("whilelo  p0.d, xzr, %2\n\t"
"ld1d z0.d, p0/z [%1]\n\t"
"str  z0, [%0]"
: "=Q"(scratch)
: "Q"(*aa64_vfp_qreg(env, n)),
  "r"(cpu->sve_max_vq)
: "p0", "v0");

PPS: Ideally, this would be further cleaned up with acle builtins, but those
are still under development for GCC.

Re: [Qemu-devel] [PATCH v3 1/8] target/ppc: Optimize emulation of lvsl and lvsr instructions

[Richard Henderson]

On 6/21/19 1:07 PM, Stefan Brankovic wrote:
> +#if defined(TARGET_PPC64)
> +tcg_gen_andi_i64(sh, EA, 0xfULL);
> +#else
> +tcg_gen_ext_i32_i64(sh, EA);
> +tcg_gen_andi_i64(sh, sh, 0xfULL);
> +#endif

Didn't see v3 before reviewing v2, however as noted there, tcg_gen_extu_tl_i64.


r~

Re: [Qemu-devel] [PATCH 1/8] target/ppc: Optimize emulation of lvsl and lvsr instructions

[Richard Henderson]

On 6/19/19 1:03 PM, Stefan Brankovic wrote:
> Adding simple macro that is calling tcg implementation of appropriate
> instruction if altivec support is active.
> 
> Optimization of altivec instruction lvsl (Load Vector for Shift Left).
> Place bytes sh:sh+15 of value 0x00 || 0x01 || 0x02 || ... || 0x1E || 0x1F
> in destination register. Sh is calculated by adding 2 source registers and
> getting bits 60-63 of result.
> 
> First, the bits [28-31] are placed from EA to variable sh. After that,
> the bytes are created in the following way:
> sh:(sh+7) of X(from description) by multiplying sh with 0x0101010101010101
> followed by addition of the result with 0x0001020304050607. Value obtained
> is placed in higher doubleword element of vD.
> (sh+8):(sh+15) by adding the result of previous multiplication with
> 0x08090a0b0c0d0e0f. Value obtained is placed in lower doubleword element
> of vD.
> 
> Optimization of altivec instruction lvsr (Load Vector for Shift Right).
> Place bytes 16-sh:31-sh of value 0x00 || 0x01 || 0x02 || ... || 0x1E ||
> 0x1F in destination register. Sh is calculated by adding 2 source
> registers and getting bits 60-63 of result.
> 
> First, the bits [28-31] are placed from EA to variable sh. After that,
> the bytes are created in the following way:
> sh:(sh+7) of X(from description) by multiplying sh with 0x0101010101010101
> followed by substraction of the result from 0x1011121314151617. Value
> obtained is placed in higher doubleword element of vD.
> (sh+8):(sh+15) by substracting the result of previous multiplication from
> 0x18191a1b1c1d1e1f. Value obtained is placed in lower doubleword element
> of vD.
> 
> Signed-off-by: Stefan Brankovic 
> ---
>  target/ppc/helper.h |   2 -
>  target/ppc/int_helper.c |  18 --
>  target/ppc/translate/vmx-impl.inc.c | 120 
> ++--
>  3 files changed, 88 insertions(+), 52 deletions(-)

Reviewed-by: Richard Henderson 


r~

Re: [Qemu-devel] [PATCH v2 08/14] target/arm/kvm64: Fix error returns

[Richard Henderson]

On 6/21/19 6:34 PM, Andrew Jones wrote:
> A couple return -EINVAL's forgot their '-'s.
> 
> Signed-off-by: Andrew Jones 
> Reviewed-by: Eric Auger 
> ---
>  target/arm/kvm64.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Reviewed-by: Richard Henderson 


r~

Re: [Qemu-devel] [PATCH 4/8] target/ppc: Optimize emulation of vgbbd instruction

[Richard Henderson]

On 6/19/19 1:03 PM, Stefan Brankovic wrote:
> Optimize altivec instruction vgbbd (Vector Gather Bits by Bytes by Doubleword)
> All ith bits (i in range 1 to 8) of each byte of doubleword element in
> source register are concatenated and placed into ith byte of appropriate
> doubleword element in destination register.
> 
> Following solution is done for both doubleword elements of source register
> in parallel, in order to reduce the number of instructions needed(that's why
> arrays are used):
> First, both doubleword elements of source register vB are placed in
> appropriate element of array avr. Bits are gathered in 2x8 iterations(2 for
> loops). In first iteration bit 1 of byte 1, bit 2 of byte 2,... bit 8 of
> byte 8 are in their final spots so avr[i], i={0,1} can be and-ed with
> tcg_mask. For every following iteration, both avr[i] and tcg_mask variables
> have to be shifted right for 7 and 8 places, respectively, in order to get
> bit 1 of byte 2, bit 2 of byte 3.. bit 7 of byte 8 in their final spots so
> shifted avr values(saved in tmp) can be and-ed with new value of tcg_mask...
> After first 8 iteration(first loop), all the first bits are in their final
> places, all second bits but second bit from eight byte are in their places...
> only 1 eight bit from eight byte is in it's place). In second loop we do all
> operations symmetrically, in order to get other half of bits in their final
> spots. Results for first and second doubleword elements are saved in
> result[0] and result[1] respectively. In the end those results are saved in
> appropriate doubleword element of destination register vD.
> 
> Signed-off-by: Stefan Brankovic 
> ---
>  target/ppc/helper.h |   1 -
>  target/ppc/int_helper.c | 276 
> 
>  target/ppc/translate/vmx-impl.inc.c |  77 +-
>  3 files changed, 76 insertions(+), 278 deletions(-)

Reviewed-by: Richard Henderson 


r~

Re: [Qemu-devel] [PATCH v2 08/14] target/arm/kvm64: Fix error returns

[Richard Henderson]

On 6/21/19 6:34 PM, Andrew Jones wrote:
> A couple return -EINVAL's forgot their '-'s.
> 
> Signed-off-by: Andrew Jones 
> Reviewed-by: Eric Auger 
> ---
>  target/arm/kvm64.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Reviewed-by: Richard Henderson 


r~

Re: [Qemu-devel] [PATCH v2 11/14] target/arm/kvm64: max cpu: Enable SVE when available

[Richard Henderson]

On 6/21/19 6:34 PM, Andrew Jones wrote:
> @@ -675,6 +689,11 @@ static void aarch64_max_initfn(Object *obj)
>  
>  if (kvm_enabled()) {
>  kvm_arm_set_cpu_features_from_host(cpu);
> +/*
> + * KVM doesn't yet support the sve-max-vq property, but
> + * setting cpu->sve_max_vq is also used to turn SVE on.
> + */
> +cpu->sve_max_vq = ARM_SVE_INIT;

Can we support this value with KVM_GET/SET_ONE_REG on ZCR_EL2?  (IIRC KVM
requires VHE to support SVE, so the host is always EL2 and the guest is always
EL1.)

Or do we need to probe this via normal userland prctl?

Or am I getting ahead of the patches to follow?


r~

Re: [Qemu-devel] [PATCH v4 0/7] tcg/ppc: Add vector opcodes

[BALATON Zoltan]

On Wed, 26 Jun 2019, Mark Cave-Ayland wrote:

On 26/06/2019 08:45, Richard Henderson wrote:

On 6/25/19 7:55 PM, Mark Cave-Ayland wrote:

And here's where we are blowing up according to -d in_asm,op_out_asm:

IN:
0x00f22ca0:  101ffc84  vor  v0, v31, v31

OP:
 ld_i32 tmp0,env,$0xfff8
 movi_i32 tmp1,$0x0
 brcond_i32 tmp0,tmp1,lt,$L0

  00f22ca0
 ld_vec v128,e8,tmp2,env,$0xd6b0
 st_vec v128,e8,tmp2,env,$0xd4c0


Yep, that looks right.

As an aside, this does suggest to me that target/ppc might be well served in
moving the ppc_vsr_t members of CPUPPCState earlier, so that this offset is
smaller.


 movi_i32 nip,$0xf22ca4
 movi_i32 nip,$0xf22ca4
 movi_i32 tmp0,$0x10002
 call raise_exception,$0x2,$0,env,tmp0


And this, presumably is the single-step debug exception.


0xa4e7f12c:  3c40  lis  r2, 0
0xa4e7f130:  6042d6b0  ori  r2, r2, 0xd6b0
0xa4e7f134:  7c5b10ce  lvx  v2, r27, r2



0xa4e7f138:  3c40  lis  r2, 0
0xa4e7f13c:  6042d4c0  ori  r2, r2, 0xd4c0
0xa4e7f140:  7c5b11ce  stvx v2, r27, r2


These also look correct.  Form an offset into r2, load or store from env+r2.

This also shows what I mention above re offset.  For a ppc host, the offset is
large enough to require two instructions to form them.


Any ideas what might be going on here?


What is the observed problem that makes you think that this is the incorrect
instruction?


What I've been doing is set a breakpoint a few instructions before and then 
issuing
"stepi" commands via the gdbstub. As I step over the "vor v0, v31, v31" 
instruction
then either the qemu-system-ppc process segfaults outside of gdb, or inside gdb 
it
goes to bg. Bringing it back to fg just causes gdb to get confused and in the 
end the
only thing I can do is kill the gdb process.

On the plus side I've managed to work out where we are faulting by hacking the 
load
and store functions to inject trap opcodes in the ld_vec and st_vec and it 
appears
that we are segfaulting here:

OUT: [size=96]
0xa4e7f120:  81dbfff8  lwz  r14, -8(r27)
0xa4e7f124:  2f8e  cmpwicr7, r14, 0
0xa4e7f128:  419c004c  blt  cr7, 0xa4e7f174
0xa4e7f12c:  3c40  lis  r2, 0
  ^^
0xa4e7f130:  6042d6b0  ori  r2, r2, 0xd6b0
0xa4e7f134:  7c5b10ce  lvx  v2, r27, r2
0xa4e7f138:  3c40  lis  r2, 0
0xa4e7f13c:  6042d4c0  ori  r2, r2, 0xd4c0
0xa4e7f140:  7c5b11ce  stvx v2, r27, r2
0xa4e7f144:  3dc000f2  lis  r14, 0xf2
0xa4e7f148:  61ce2ca4  ori  r14, r14, 0x2ca4
0xa4e7f14c:  91db016c  stw  r14, 0x16c(r27)
0xa4e7f150:  7f63db78  mr   r3, r27
0xa4e7f154:  3c81  lis  r4, 1
0xa4e7f158:  60840002  ori  r4, r4, 2
0xa4e7f15c:  3c87  lis  r0, 0x87
0xa4e7f160:  6000b618  ori  r0, r0, 0xb618
0xa4e7f164:  7c0903a6  mtctrr0
0xa4e7f168:  4e800421  bctrl
0xa4e7f16c:  3860  li   r3, 0
0xa4e7f170:  4bfffef0  b0xa4e7f060
0xa4e7f174:  3c60a4e7  lis  r3, -0x5b19
0xa4e7f178:  6063f0c3  ori  r3, r3, 0xf0c3
0xa4e7f17c:  4bfffee4  b0xa4e7f060

Interestingly if I set a trap and then switch the opcode to "lis r4,0" 
(0x3c80)
then we carry on as normal until the next "lis r2,0" instruction. Looking 
through the
whole output of -d out_asm this is the first mention of r2 which makes me 
wonder if
it is special somehow? At least a quick search indicates that for 32-bit PPC r2 
is
supposed to be dedicated as a TOC pointer.


According to a PowerPC ABI doc: 
http://refspecs.linux-foundation.org/elf/elfspec_ppc.pdf
r2 is system reserved and should not be used by application code and 
another one (probably the same you were referring to mentions TOC 
https://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi-1.9.html#REG. 
I'm not sure if that's relevant for the above but it looks like clobbering 
r2 might cause problems.


Regards,
BALATON Zoltan

Re: [Qemu-devel] [PATCH RFC 0/3] qemu-img: remove command documentation duplication

[John Snow]

On 6/26/19 2:03 PM, Max Reitz wrote:
> On 10.04.19 03:24, John Snow wrote:
>> This might hopefully cut down on the doc duplication/mismatching
>> until I can devise something more comprehensive.
>>
>> Ideally, I'd like to redo all of the documentation for qemu-img
>> nearly from scratch; with a parser generator that helps generate
>> the documentation as well so they'll never get out of date.
>>
>> That's probably quite a ways off, and maybe there are other
>> structural changes we want to make with respect to sphinx and
>> other build tools, so I am sending something very minimal instead.
>>
>> This ought to be functionally identical down to the last char.
>>
>> (I've re-included patch one which I have sent to the list separately,
>> purely as a dependency if you want to apply these patches.)
>>
>> John Snow (3):
>>   qemu-img: fix .hx and .texi disparity
>>   pxtool: Add new qemu-img command info generation tool
>>   qemu-img.texi: use macros for command summaries
> 
> Hm.  Non-RFC ping?
> 
> Max
> 

This was mostly a quick hack; it didn't seek to eliminate ALL of the .hx
files we have, and it's not a comprehensive solution.

It is a quick stopgap that should work well enough for now, but it's
replacing one hack with another hack.

...Well, this hack is SLIGHTLY nicer, but I think I did some silly
things like using a zero-argument macro for texi instead of just
defining a variable. I don't know what I'm doing with texi stuff.

And then since I wrote it, there's been more buzz about reworking the
Sphinx documentation, so maybe this is too lateral of a move. I don't know.

I don't think it got review from the QAPI powers, though, and I think
I'd like to hear what they have to say before I invest any more time in
trying to fix this up.

--js

Re: [Qemu-devel] [Qemu-trivial] Fix cacheline size retrieval on FreeBSD/PowerPC(64)

[Justin Hibbits]

On Wed, 26 Jun 2019 18:47:42 +0200
Laurent Vivier  wrote:

> Le 26/06/2019 à 18:37, Justin Hibbits a écrit :
> > On Wed, 26 Jun 2019 18:16:36 +0200
> > Laurent Vivier  wrote:
> >   
> >> Le 26/06/2019 à 18:14, Laurent Vivier a écrit :  
> >>> Le 07/06/2019 à 20:56, Justin Hibbits a écrit :
>  The attached very trivial patch fixes a startup bug that prevents
>  at least Qemu 3.1 and later from working on FreeBSD/powerpc64.
> 
>  - Justin
> 
> >>>
> >>> Please don't send a patch in attachment but inlined in the message
> >>> (you may use "git send-email" for that).
> >>>
> >>> This patch fixes "util: add cacheinfo" that has changed the type
> >>> from unsigned to long.
> >>>
> >>> You can add the following line in the commit message:
> >>>
> >>> Fixes: b255b2c8a548 ("util: add cacheinfo")
> >>>
> >>> Reviewed-by: Laurent Vivier 
> >>> 
> >>
> >> CC: author of b255b2c8a548 ("util: add cacheinfo")
> >>
> >> Thanks,
> >> Laurent  
> > 
> > Hi Laurent,
> > 
> > Sorry.  I had never used git send-email before, so wasn't
> > comfortable with it.  I just updated the commit message with your
> > feedback and used git send-email to submit the patch.  I hope
> > everything went well.  
> 
> It seems not. I didn't receive it.
> 
> Did you configure the SMTP server. See git-send-email(1):
> 
>Use gmail as the smtp server
> 
>To use git send-email to send your patches through the GMail
> SMTP server, edit ~/.gitconfig to specify your account settings:
> 
>[sendemail]
>smtpEncryption = tls
>smtpServer = smtp.gmail.com
>smtpUser = yourn...@gmail.com
>smtpServerPort = 587
> 
>If you have multifactor authentication setup on your gmail
> account, you will need to generate an app-specific password for use
> with git send-email. Visit
>https://security.google.com/settings/security/apppasswords to
> create it.
> 
>Once your commits are ready to be sent to the mailing list,
> run the following commands:
> 
>$ git format-patch --cover-letter -M origin/master -o
> outgoing/ $ edit outgoing/-*
>$ git send-email outgoing/*
> 
>The first time you run it, you will be prompted for your
> credentials. Enter the app-specific or your regular password as
> appropriate. If you have credential helper configured (see
> git-credential(1)), the password will be saved in the credential
> store so you won’t have to type it the next time.
> 
>Note: the following perl modules are required Net::SMTP::SSL,
>MIME::Base64 and Authen::SASL
> 
> Thanks,
> Laurent
> 
>  

Hm, you're right.  Even after making the config changes and installing
the necessary packages, I still have no luck with git send-email.  Might
take a bit to debug this.

- Justin

Re: [Qemu-devel] [PATCH RFC 0/3] qemu-img: remove command documentation duplication

[Max Reitz]

On 10.04.19 03:24, John Snow wrote:
> This might hopefully cut down on the doc duplication/mismatching
> until I can devise something more comprehensive.
> 
> Ideally, I'd like to redo all of the documentation for qemu-img
> nearly from scratch; with a parser generator that helps generate
> the documentation as well so they'll never get out of date.
> 
> That's probably quite a ways off, and maybe there are other
> structural changes we want to make with respect to sphinx and
> other build tools, so I am sending something very minimal instead.
> 
> This ought to be functionally identical down to the last char.
> 
> (I've re-included patch one which I have sent to the list separately,
> purely as a dependency if you want to apply these patches.)
> 
> John Snow (3):
>   qemu-img: fix .hx and .texi disparity
>   pxtool: Add new qemu-img command info generation tool
>   qemu-img.texi: use macros for command summaries

Hm.  Non-RFC ping?

Max



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PULL 02/11] vhost-user: check unix_listen() return value

[Eric Blake]

On 6/16/19 4:36 PM, Michael S. Tsirkin wrote:
> From: Marc-André Lureau 
> 
> This check shouldn't be necessary, since _fatal is given as
> argument and will exit() on failure. However, this change should
> silence coverity CID 1401761 & 1401705.
> 
> Signed-off-by: Marc-André Lureau 
> Message-Id: <20190605145829.7674-3-marcandre.lur...@redhat.com>
> Reviewed-by: Michael S. Tsirkin 
> Signed-off-by: Michael S. Tsirkin 
> ---
>  contrib/vhost-user-gpu/main.c   | 4 
>  contrib/vhost-user-input/main.c | 4 
>  2 files changed, 8 insertions(+)
> 
> diff --git a/contrib/vhost-user-gpu/main.c b/contrib/vhost-user-gpu/main.c
> index 9614c9422c..e0b6df5b4d 100644
> --- a/contrib/vhost-user-gpu/main.c
> +++ b/contrib/vhost-user-gpu/main.c
> @@ -1160,6 +1160,10 @@ main(int argc, char *argv[])
>  
>  if (opt_socket_path) {
>  int lsock = unix_listen(opt_socket_path, _fatal);
> +if (lsock < 0) {
> +g_printerr("Failed to listen on %s.\n", opt_socket_path);
> +exit(EXIT_FAILURE);
> +}

4 lines to appease Coverity; wouldn't the following one-liner also do
the trick?

int lsock = unix_listen(opt_socket_path, _fatal);
assert (lsock >= 0);

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v8 10/10] hw/m68k: define Macintosh Quadra 800

[Philippe Mathieu-Daudé]

On 6/25/19 6:30 PM, Thomas Huth wrote:
> Am Thu, 20 Jun 2019 00:19:33 +0200
> schrieb Laurent Vivier :
> 
>> If you want to test the machine, it doesn't yet boot a MacROM, but
>> you can boot a linux kernel from the command line.
> 
> I gave the patch series a quick try, and was indeed able to boot the
> Debian installer with the q800 machine, so:
> 
> Tested-by: Thomas Huth 

While this reply is valid for this patch, was it meant for the series'
cover?

Re: [Qemu-devel] [PATCH] xen-block: support feature-large-sector-size

[Max Reitz]

On 26.06.19 19:19, Anthony PERARD wrote:
> On Wed, Jun 26, 2019 at 06:48:50PM +0200, Max Reitz wrote:
>> On 09.04.19 18:40, Paul Durrant wrote:
>>> A recent Xen commit [1] clarified the semantics of sector based quantities
>>> used in the blkif protocol such that it is now safe to create a xen-block
>>> device with a logical_block_size != 512, as long as the device only
>>> connects to a frontend advertizing 'feature-large-block-size'.
>>>
>>> This patch modifies xen-block accordingly. It also uses a stack variable
>>> for the BlockBackend in xen_block_realize() to avoid repeated dereferencing
>>> of the BlockConf pointer, and changes the parameters of
>>> xen_block_dataplane_create() so that the BlockBackend pointer and sector
>>> size are passed expicitly rather than implicitly via the BlockConf.
>>>
>>> These modifications have been tested against a recent Windows PV XENVBD
>>> driver [2] using a xen-disk device with a 4kB logical block size.
>>>
>>> [1] 
>>> http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=67e1c050e36b2c9900cca83618e56189effbad98
>>> [2] https://winpvdrvbuild.xenproject.org:8080/job/XENVBD-master/126
>>>
>>> Signed-off-by: Paul Durrant 
>>> ---
>>> Cc: Stefano Stabellini 
>>> Cc: Anthony Perard 
>>> Cc: Stefan Hajnoczi 
>>> Cc: Kevin Wolf 
>>> Cc: Max Reitz 
>>> ---
>>>  hw/block/dataplane/xen-block.c | 25 --
>>>  hw/block/dataplane/xen-block.h |  3 ++-
>>>  hw/block/xen-block.c   | 38 +-
>>>  3 files changed, 40 insertions(+), 26 deletions(-)
>>
>> Thanks, added “by frontend” to the error message and applied to my block
>> branch:
>>
>> https://git.xanclic.moe/XanClic/qemu/commits/branch/block
> 
> :(, I've just sent a pull request with that patch:
> https://patchew.org/QEMU/20190624153257.20163-1-anthony.per...@citrix.com/20190624153257.20163-2-anthony.per...@citrix.com/

That’s just as well, then. :-)

> I guess I need to start sending an email every time I've added a patch
> to my queue.

Well, it certainly won’t hurt.  Although in this cases it’s just a bit
of an unfortunate coincidence that I looked at this patch now when Peter
seems to be away (otherwise I’d have seen it in master).

Max



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v8 03/10] dp8393x: manage big endian bus

[Philippe Mathieu-Daudé]

On 6/26/19 12:11 PM, Laurent Vivier wrote:
> Le 26/06/2019 à 10:57, Philippe Mathieu-Daudé a écrit :
>> On 6/25/19 7:09 PM, Laurent Vivier wrote:
>>> Le 25/06/2019 à 17:57, Philippe Mathieu-Daudé a écrit :
 On 6/24/19 10:07 PM, Laurent Vivier wrote:
> Hi,
>
> Jason, Can I have an Acked-by from you (as network devices maintainer)?

 Hmm something seems odd here indeed...

 What a stable model! This file has no logical modification since its
 introduction, a65f56eeba "Implement sonic netcard (MIPS Jazz)"

 Here we had:

 static void dp8393x_writeb(void *opaque, hwaddr addr, uint32_t val)
 {
 uint16_t old_val = dp8393x_readw(opaque, addr & ~0x1);

 switch (addr & 3) {
 case 0:
 val = val | (old_val & 0xff00);
 break;
 case 1:
 val = (val << 8) | (old_val & 0x00ff);
 break;
 }
 dp8393x_writew(opaque, addr & ~0x1, val);
 }

 So we had 16-bit endian shifting there.

 And few lines below:

 /* XXX: Check byte ordering */
 ...
 /* Calculate the ethernet checksum */
 #ifdef SONIC_CALCULATE_RXCRC
 checksum = cpu_to_le32(crc32(0, buf, rx_len));
 #else
 checksum = 0;
 #endif

 After various housekeeping, we get:

 84689cbb97 "net/dp8393x: do not use old_mmio accesses"

 The MIPS Jazz is known to run in both endianess, but I haven't checked
 if at that time both were available.

 Have you tried this patch?

 -- >8 --
 diff --git a/hw/net/dp8393x.c b/hw/net/dp8393x.c
 index bdb0b3b2c2..646e11206f 100644
 @@ -651,7 +651,7 @@ static const MemoryRegionOps dp8393x_ops = {
  .write = dp8393x_write,
  .impl.min_access_size = 2,
  .impl.max_access_size = 2,
 -.endianness = DEVICE_NATIVE_ENDIAN,
 +.endianness = DEVICE_LITTLE_ENDIAN,
  };
 ---

 (but then mips64-softmmu Jazz would have networking broken).

>>>
>>> I doesn't help, the endianness is a MemoryRegion property (see
>>> memory_region_wrong_endianness()) so it is used when the CPU writes to
>>> the device MMIO, not when the device accesses the other memory.
>>> In this case, it reads from system_memory. Perhaps we can create the
>>> address_space with a system_memory in big endian mode?
>>
>> Ah I missed that...
>>
>> What about not using address_space_rw(data) but directly use
>> address_space_lduw_le() and address_space_stw_le() instead?
>>
> 
> It's more complicated than that, because access size depends on a
> register value:
> 
> static uint16_t dp8393x_get(dp8393xState *s, int width, uint16_t *base,
> int offset)
> {
> uint16_t val;
> 
> if (s->big_endian) {
> val = be16_to_cpu(base[offset * width + width - 1]);
> } else {
> val = le16_to_cpu(base[offset * width]);
> }
> return val;
> }
> 
> and width is:
> 
> width = (s->regs[SONIC_DCR] & SONIC_DCR_DW) ? 2 : 1;
> 
> So in the end we always need the big_endian flag to know how to read the
> memory. I think it's simpler to read/write the memory (like a real DMA
> access), and then to swap data internally.

Fair enough. My R-b tag stands anyway :)

> Moreover, the big-endian/little-endian is a real feature of the
> controller (see  1.3 DATA WIDTH AND BYTE ORDERING,
> http://pccomponents.com/datasheets/NSC83932.PDF )

Can you (or the maintainer taking this series) amend this information to
your commit?

Thanks for the info provided in this thread,

Phil.

Re: [Qemu-devel] [PATCH v2] Fix build error when VNC is configured out

[Philippe Mathieu-Daudé]

On 6/26/19 6:49 PM, Stefano Garzarella wrote:
> On Tue, Jun 25, 2019 at 02:39:05PM +0200, Christophe de Dinechin wrote:
>> In hmp_change(), the variable hmp_mon is only used
>> by code under #ifdef CONFIG_VNC. This results in a build
>> error when VNC is configured out with the default of
>> treating warnings as errors:
>>
>> monitor/hmp-cmds.c: In function ‘hmp_change’:
>> monitor/hmp-cmds.c:1946:17: error: unused variable ‘hmp_mon’ 
>> [-Werror=unused-variable]
>> 1946 | MonitorHMP *hmp_mon = container_of(mon, MonitorHMP, common);
>>  | ^~~
>>
>> v2: Move variable down as suggested by Philippe Mathieu-Daudé
> 
> Should we move out this line from the commit message?
> (Maybe Dave can remove it when apply)

Yes please :) It was meant to go after the '---' separator.

>>
>> Signed-off-by: Christophe de Dinechin 
>> ---
>>  monitor/hmp-cmds.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Reviewed-by: Stefano Garzarella 
> 

Reviewed-by: Philippe Mathieu-Daudé 

Re: [Qemu-devel] [PATCH 3/7] configure: integrate Meson in the build system

[Markus Armbruster]

Paolo Bonzini  writes:

> The Meson build system is integrated in the existing configure/make steps
> by invoking Meson from the configure script and converting Meson's build.ninja
> rules to an included Makefile.
>
> Signed-off-by: Paolo Bonzini 
> ---
>  Makefile |   9 +
>  configure|  30 ++
>  meson.build  |   9 +
>  scripts/ninjatool.py | 964 
> +++

Uff.

>  4 files changed, 1012 insertions(+)
>  create mode 100644 meson.build
>  create mode 100644 scripts/ninjatool.py
>
> diff --git a/Makefile b/Makefile
> index 8e2fc66..b8f802c 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -48,6 +48,15 @@ git-submodule-update:
>  endif
>  endif
>  
> +export NINJA=./ninjatool
> +Makefile.ninja: build.ninja ninjatool
> + ./ninjatool -t ninja2make --omit dist uninstall < $< > $@
> +-include Makefile.ninja
> +
> +ninjatool: $(SRC_PATH)/scripts/ninjatool.py
> + sed -e '1c\' -e '#! $(PYTHON)' $< > $@
> + chmod +x $@

Why do we need this here, but not for other Python scripts?

We have 39 Python scripts with #!/usr/bin/env python, one with
#!/usr/bin/env python2, and 12 with #!/usr/bin/python.  The Makefiles
generally use $(PYTHON) SCRIPT ARGS...

> +
>  .git-submodule-status: git-submodule-update config-host.mak
>  
>  # Check that we're not trying to do an out-of-tree build from
> diff --git a/configure b/configure
> index 0814a5f..b8c3c58 100755
> --- a/configure
> +++ b/configure
> @@ -493,6 +493,7 @@ docker="no"
>  debug_mutex="no"
>  libpmem=""
>  default_devices="yes"
> +meson=meson
>  
>  # cross compilers defaults, can be overridden with --cross-cc-ARCH
>  cross_cc_aarch64="aarch64-linux-gnu-gcc"
> @@ -983,6 +984,8 @@ for opt do
>;;
>--python=*) python="$optarg"
>;;
> +  --meson=*) meson="$optarg"
> +  ;;
>--gcov=*) gcov_tool="$optarg"
>;;
>--smbd=*) smbd="$optarg"
> @@ -1685,6 +1688,7 @@ Advanced options (experts only):
>--make=MAKE  use specified make [$make]
>--install=INSTALLuse specified install [$install]
>--python=PYTHON  use specified python [$python]
> +  --meson=PYTHON   use specified meson [$meson]
>--smbd=SMBD  use specified smbd [$smbd]
>--with-git=GIT   use specified git [$git]
>--static enable static build [$static]
> @@ -1850,6 +1854,11 @@ then
>  error_exit "Python not found. Use --python=/path/to/python"
>  fi
>  
> +if ! has "$meson"
> +then
> +error_exit "Meson not found. Use --meson=/path/to/meson"
> +fi
> +
>  # Note that if the Python conditional here evaluates True we will exit
>  # with status 1 which is a shell 'false' value.
>  if ! $python -c 'import sys; sys.exit(sys.version_info < (2,7))'; then
> @@ -7983,6 +7992,27 @@ echo "# Automatically generated by configure - do not 
> modify" > "$iotests_common
>  echo >> "$iotests_common_env"
>  echo "export PYTHON='$python'" >> "$iotests_common_env"
>  
> +# bootstrap ninjatool, we need it before Make runs
> +if ! test -x ninjatool; then
> +  sed -e '1c\' -e "#! $python" ${source_path}/scripts/ninjatool.py > 
> ninjatool
> +  chmod +x ninjatool
> +fi
> +rm -rf meson-private meson-info meson-logs

Ignorant question: why do we need configure remove this stuff?

> +NINJA=$PWD/ninjatool $python $meson setup \

This prints

/usr/bin/python3: can't open file 'meson': [Errno 2] No such file or 
directory

for me, then goes on happily.

For what it's worth:

$ type meson
meson is /usr/bin/meson

Are you sure you want to override /usr/bin/meson's #! line?

If I drop $python, I get

meson.build:1:0: ERROR: Meson version is 0.50.1 but project requires 
>=0.50.999.

which is expected.

It's too hot right for me now to figure out how to obtain a suitable
version.

> + --prefix "$prefix" \
> + --libdir "$libdir" \
> + --libexecdir "$libexecdir" \
> + --bindir "$bindir" \
> + --includedir "$includedir" \
> + --datadir "$datadir" \
> + --mandir "$mandir" \
> + --sysconfdir "$sysconfdir" \
> + --localstatedir "$local_statedir" \
> + $(test "$strip_opt" = yes && echo --strip) \
> + --buildtype $(if test "$debug" = yes; then echo debug; else echo 
> release; fi) \
> + "$PWD" "$source_path"
> +
> +
>  # Save the configure command line for later reuse.
>  cat   #!/bin/sh
> diff --git a/meson.build b/meson.build
> new file mode 100644
> index 000..b683d70
> --- /dev/null
> +++ b/meson.build
> @@ -0,0 +1,9 @@
> +project('qemu', 'c', meson_version: '>=0.50.999')
> +
> +kconfig = import('unstable-kconfig')
> +config_host = kconfig.load(meson.current_build_dir() / 'config-host.mak')
> +
> +add_project_arguments(config_host['QEMU_CFLAGS'].split(),
> +  language: 'c')
> +add_project_arguments(config_host['QEMU_INCLUDES'].split(),
> +  language: 'c')
> diff --git a/scripts/ninjatool.py b/scripts/ninjatool.py
> new file mode 100644

Re: [Qemu-devel] [PATCH] xen-block: support feature-large-sector-size

[Anthony PERARD]

On Wed, Jun 26, 2019 at 06:48:50PM +0200, Max Reitz wrote:
> On 09.04.19 18:40, Paul Durrant wrote:
> > A recent Xen commit [1] clarified the semantics of sector based quantities
> > used in the blkif protocol such that it is now safe to create a xen-block
> > device with a logical_block_size != 512, as long as the device only
> > connects to a frontend advertizing 'feature-large-block-size'.
> > 
> > This patch modifies xen-block accordingly. It also uses a stack variable
> > for the BlockBackend in xen_block_realize() to avoid repeated dereferencing
> > of the BlockConf pointer, and changes the parameters of
> > xen_block_dataplane_create() so that the BlockBackend pointer and sector
> > size are passed expicitly rather than implicitly via the BlockConf.
> > 
> > These modifications have been tested against a recent Windows PV XENVBD
> > driver [2] using a xen-disk device with a 4kB logical block size.
> > 
> > [1] 
> > http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=67e1c050e36b2c9900cca83618e56189effbad98
> > [2] https://winpvdrvbuild.xenproject.org:8080/job/XENVBD-master/126
> > 
> > Signed-off-by: Paul Durrant 
> > ---
> > Cc: Stefano Stabellini 
> > Cc: Anthony Perard 
> > Cc: Stefan Hajnoczi 
> > Cc: Kevin Wolf 
> > Cc: Max Reitz 
> > ---
> >  hw/block/dataplane/xen-block.c | 25 --
> >  hw/block/dataplane/xen-block.h |  3 ++-
> >  hw/block/xen-block.c   | 38 +-
> >  3 files changed, 40 insertions(+), 26 deletions(-)
> 
> Thanks, added “by frontend” to the error message and applied to my block
> branch:
> 
> https://git.xanclic.moe/XanClic/qemu/commits/branch/block

:(, I've just sent a pull request with that patch:
https://patchew.org/QEMU/20190624153257.20163-1-anthony.per...@citrix.com/20190624153257.20163-2-anthony.per...@citrix.com/

I guess I need to start sending an email every time I've added a patch
to my queue.

Cheers,

-- 
Anthony PERARD

Re: [Qemu-devel] [PATCH v4 0/7] tcg/ppc: Add vector opcodes

[Mark Cave-Ayland]

On 26/06/2019 08:45, Richard Henderson wrote:

> On 6/25/19 7:55 PM, Mark Cave-Ayland wrote:
>> And here's where we are blowing up according to -d in_asm,op_out_asm:
>>
>> IN:
>> 0x00f22ca0:  101ffc84  vor  v0, v31, v31
>>
>> OP:
>>  ld_i32 tmp0,env,$0xfff8
>>  movi_i32 tmp1,$0x0
>>  brcond_i32 tmp0,tmp1,lt,$L0
>>
>>   00f22ca0
>>  ld_vec v128,e8,tmp2,env,$0xd6b0
>>  st_vec v128,e8,tmp2,env,$0xd4c0
> 
> Yep, that looks right.
> 
> As an aside, this does suggest to me that target/ppc might be well served in
> moving the ppc_vsr_t members of CPUPPCState earlier, so that this offset is
> smaller.
> 
>>  movi_i32 nip,$0xf22ca4
>>  movi_i32 nip,$0xf22ca4
>>  movi_i32 tmp0,$0x10002
>>  call raise_exception,$0x2,$0,env,tmp0
> 
> And this, presumably is the single-step debug exception.
> 
>> 0xa4e7f12c:  3c40  lis  r2, 0
>> 0xa4e7f130:  6042d6b0  ori  r2, r2, 0xd6b0
>> 0xa4e7f134:  7c5b10ce  lvx  v2, r27, r2
> 
>> 0xa4e7f138:  3c40  lis  r2, 0
>> 0xa4e7f13c:  6042d4c0  ori  r2, r2, 0xd4c0
>> 0xa4e7f140:  7c5b11ce  stvx v2, r27, r2
> 
> These also look correct.  Form an offset into r2, load or store from env+r2.
> 
> This also shows what I mention above re offset.  For a ppc host, the offset is
> large enough to require two instructions to form them.
> 
>> Any ideas what might be going on here?
> 
> What is the observed problem that makes you think that this is the incorrect
> instruction?

What I've been doing is set a breakpoint a few instructions before and then 
issuing
"stepi" commands via the gdbstub. As I step over the "vor v0, v31, v31" 
instruction
then either the qemu-system-ppc process segfaults outside of gdb, or inside gdb 
it
goes to bg. Bringing it back to fg just causes gdb to get confused and in the 
end the
only thing I can do is kill the gdb process.

On the plus side I've managed to work out where we are faulting by hacking the 
load
and store functions to inject trap opcodes in the ld_vec and st_vec and it 
appears
that we are segfaulting here:

OUT: [size=96]
0xa4e7f120:  81dbfff8  lwz  r14, -8(r27)
0xa4e7f124:  2f8e  cmpwicr7, r14, 0
0xa4e7f128:  419c004c  blt  cr7, 0xa4e7f174
0xa4e7f12c:  3c40  lis  r2, 0
   ^^
0xa4e7f130:  6042d6b0  ori  r2, r2, 0xd6b0
0xa4e7f134:  7c5b10ce  lvx  v2, r27, r2
0xa4e7f138:  3c40  lis  r2, 0
0xa4e7f13c:  6042d4c0  ori  r2, r2, 0xd4c0
0xa4e7f140:  7c5b11ce  stvx v2, r27, r2
0xa4e7f144:  3dc000f2  lis  r14, 0xf2
0xa4e7f148:  61ce2ca4  ori  r14, r14, 0x2ca4
0xa4e7f14c:  91db016c  stw  r14, 0x16c(r27)
0xa4e7f150:  7f63db78  mr   r3, r27
0xa4e7f154:  3c81  lis  r4, 1
0xa4e7f158:  60840002  ori  r4, r4, 2
0xa4e7f15c:  3c87  lis  r0, 0x87
0xa4e7f160:  6000b618  ori  r0, r0, 0xb618
0xa4e7f164:  7c0903a6  mtctrr0
0xa4e7f168:  4e800421  bctrl
0xa4e7f16c:  3860  li   r3, 0
0xa4e7f170:  4bfffef0  b0xa4e7f060
0xa4e7f174:  3c60a4e7  lis  r3, -0x5b19
0xa4e7f178:  6063f0c3  ori  r3, r3, 0xf0c3
0xa4e7f17c:  4bfffee4  b0xa4e7f060

Interestingly if I set a trap and then switch the opcode to "lis r4,0" 
(0x3c80)
then we carry on as normal until the next "lis r2,0" instruction. Looking 
through the
whole output of -d out_asm this is the first mention of r2 which makes me 
wonder if
it is special somehow? At least a quick search indicates that for 32-bit PPC r2 
is
supposed to be dedicated as a TOC pointer.

Is there a quick way to disable r2 from the list of available registers to see 
if
that gets things going?


ATB,

Mark.

Re: [Qemu-devel] [Qemu-block] [RFC] nvme: how to support multiple namespaces

[Klaus Birkelund]

On Wed, Jun 26, 2019 at 12:14:15PM +0200, Paolo Bonzini wrote:
> On 26/06/19 06:46, Markus Armbruster wrote:
> >> I'm not sure how to wire it together without the bus abstraction? So
> >> I'll stick with the bus for now. It *is* extremely convenient!
> > 
> > As far as I can tell offhand, a common use of bus-less connections
> > between devices is wiring together composite devices.  Example:
> > 
> > static void designware_pcie_host_init(Object *obj)
> > {
> > DesignwarePCIEHost *s = DESIGNWARE_PCIE_HOST(obj);
> > DesignwarePCIERoot *root = >root;
> > 
> > object_initialize_child(obj, "root",  root, sizeof(*root),
> > TYPE_DESIGNWARE_PCIE_ROOT, _abort, 
> > NULL);
> > qdev_prop_set_int32(DEVICE(root), "addr", PCI_DEVFN(0, 0));
> > qdev_prop_set_bit(DEVICE(root), "multifunction", false);
> > }
> > 
> > This creates a TYPE_DESIGNWARE_PCIE_ROOT device "within" the
> > TYPE_DESIGNWARE_PCIE_HOST device.
> > 
> > Bus-less connections between separate devices (i.e. neither device is a
> > part of the other) are also possible.  But I'm failing at grep right
> > now.  Here's an example for connecting a device to a machine:
> > 
> > static void mch_realize(PCIDevice *d, Error **errp)
> > {
> > int i;
> > MCHPCIState *mch = MCH_PCI_DEVICE(d);
> > 
> > [...]
> > object_property_add_const_link(qdev_get_machine(), "smram",
> >OBJECT(>smram), _abort);
> > [...]
> > }
> 
> This is a link to a memory region.  A connection to a separate device
> can be found in hw/dma/xilinx_axidma.c and hw/net/xilinx_axienet.c,
> where you have
> 
>  data stream <> data stream
>/\
>dmaenet
>\/
>  control stream <--> control stream
> 
> where the horizontal links in the middle are set up by board code, while
> the diagonal lines on the side are set up by device code.
> 
> > Paolo, can you provide guidance on when to use a bus, and when not to?
> 
> I would definitely use a bus if 1) it is common for the user (and not
> for machine code) to set up the connection 2) the relationship is
> parent-child.  Link properties are basically unused on the command line,
> and it only makes sense to make something different if the connection is
> some kind of graph so bus-child does not cut it.
> 

Definitely looks like the bus is the way to go. The controller/namespace
relationship is strictly parent-child.

Thanks both of you for the advice!


Klaus

Re: [Qemu-devel] [PATCH v2 07/14] target/arm/cpu64: max cpu: Introduce sve properties

[Auger Eric]

Hi,
On 6/21/19 6:34 PM, Andrew Jones wrote:
> Introduce cpu properties to give fine control over SVE vector lengths.
> We introduce a property for each valid length up to the current
> maximum supported, which is 2048-bits. The properties are named, e.g.
> sve128, sve256, sve512, ..., where the number is the number of bits.
> 
> It's now possible to do something like -cpu max,sve-max-vq=4,sve384=off
> to provide a guest vector lengths 128, 256, and 512 bits. The resulting
> set must conform to the architectural constraint of having all power-of-2
> lengths smaller than the maximum length present. It's also possible to
> only provide sve properties, e.g. -cpu max,sve512=on. That
> example provides the machine with 128, 256, and 512 bit vector lengths.
> It doesn't hurt to explicitly ask for all expected vector lengths,
> which is what, for example, libvirt should do.
> 
> Note1, it is not possible to use sve properties before
> sve-max-vq, e.g. -cpu max,sve384=off,sve-max-vq=4, as supporting
> that overly complicates the user input validation.
> 
> Note2, while one might expect -cpu max,sve-max-vq=4,sve512=on to be the
> same as -cpu max,sve512=on, they are not. The former enables all vector
> lengths 512 bits and smaller, while the latter only sets the 512-bit
> length and its smaller power-of-2 lengths. It's probably best not to use
> sve-max-vq with sve properties, but it can't be completely
> forbidden as we want qmp_query_cpu_model_expansion to work with guests
> launched with e.g. -cpu max,sve-max-vq=8 on their command line.
> 
> Signed-off-by: Andrew Jones 
> ---
>  target/arm/cpu.c |   6 +
>  target/arm/cpu.h |  14 ++
>  target/arm/cpu64.c   | 360 ++-
>  target/arm/helper.c  |  11 +-
>  target/arm/monitor.c |  16 ++
>  tests/arm-cpu-features.c | 217 +++
>  6 files changed, 620 insertions(+), 4 deletions(-)
> 
> diff --git a/target/arm/cpu.c b/target/arm/cpu.c
> index f08e178fc84b..e060a0d9df0e 100644
> --- a/target/arm/cpu.c
> +++ b/target/arm/cpu.c
> @@ -1019,6 +1019,12 @@ static void arm_cpu_realizefn(DeviceState *dev, Error 
> **errp)
>  return;
>  }
>  
> +arm_cpu_sve_finalize(cpu, _err);
> +if (local_err) {
> +error_propagate(errp, local_err);
> +return;
> +}
> +
>  if (arm_feature(env, ARM_FEATURE_AARCH64) &&
>  cpu->has_vfp != cpu->has_neon) {
>  /*
> diff --git a/target/arm/cpu.h b/target/arm/cpu.h
> index f9da672be575..cbb155cf72a5 100644
> --- a/target/arm/cpu.h
> +++ b/target/arm/cpu.h
> @@ -184,8 +184,13 @@ typedef struct {
>  
>  #ifdef TARGET_AARCH64
>  # define ARM_MAX_VQ16
> +void arm_cpu_sve_finalize(ARMCPU *cpu, Error **errp);
> +uint32_t arm_cpu_vq_map_next_smaller(ARMCPU *cpu, uint32_t vq);
>  #else
>  # define ARM_MAX_VQ1
> +static inline void arm_cpu_sve_finalize(ARMCPU *cpu, Error **errp) { }
> +static inline uint32_t arm_cpu_vq_map_next_smaller(ARMCPU *cpu, uint32_t vq)
> +{ return 0; }
>  #endif
>  
>  typedef struct ARMVectorReg {
> @@ -915,6 +920,15 @@ struct ARMCPU {
>  
>  /* Used to set the maximum vector length the cpu will support.  */
>  uint32_t sve_max_vq;
> +
> +/*
> + * In sve_vq_map each set bit is a supported vector length of
> + * (bit-number + 1) * 16 bytes, i.e. each bit number + 1 is the vector
> + * length in quadwords. We need a map size twice the maximum
> + * quadword length though because we use two bits for each vector
> + * length in order to track three states: uninitialized, off, and on.
> + */
> +DECLARE_BITMAP(sve_vq_map, ARM_MAX_VQ * 2);
>  };
>  
>  void arm_cpu_post_init(Object *obj);
> diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
> index 02ada65f240c..5def82111dee 100644
> --- a/target/arm/cpu64.c
> +++ b/target/arm/cpu64.c
> @@ -257,6 +257,149 @@ static void aarch64_a72_initfn(Object *obj)
>  define_arm_cp_regs(cpu, cortex_a72_a57_a53_cp_reginfo);
>  }
>  
> +/*
> + * While we eventually use cpu->sve_vq_map as a typical bitmap, where each vq
> + * has only two states (off/on), until we've finalized the map at realize 
> time
> + * we use an extra bit, at the vq - 1 + ARM_MAX_VQ bit number, to also allow
> + * tracking of the uninitialized state. The arm_vq_state typedef and 
> following
> + * functions allow us to more easily work with the bitmap. Also, while the 
> map
> + * is still initializing, sve-max-vq has an additional three states, bringing
> + * the number of its states to five, which are the following:
> + *
> + * sve-max-vq:
> + *   0:SVE is disabled. The default value for a vq in the map is 'OFF'.
> + *  -1:SVE is enabled, but neither sve-max-vq nor sve properties
> + * have yet been specified by the user. The default value for a vq in
> + * the map is 'ON'.
> + *  -2:SVE is enabled and one or more sve properties have been
> + * set to 'OFF' by the user, but no sve properties have yet
> + *   

Re: [Qemu-devel] [PULL 0/3] M68k next patches

[no-reply]

Patchew URL: https://patchew.org/QEMU/20190626162100.24774-1-laur...@vivier.eu/



Hi,

This series failed build test on s390x host. Please find the details below.

=== TEST SCRIPT BEGIN ===
#!/bin/bash
# Testing script will be invoked under the git checkout with
# HEAD pointing to a commit that has the patches applied on top of "base"
# branch
set -e
CC=$HOME/bin/cc
INSTALL=$PWD/install
BUILD=$PWD/build
mkdir -p $BUILD $INSTALL
SRC=$PWD
cd $BUILD
$SRC/configure --cc=$CC --prefix=$INSTALL
make -j4
# XXX: we need reliable clean up
# make check -j4 V=1
make install

echo
echo "=== ENV ==="
env

echo
echo "=== PACKAGES ==="
rpm -qa
=== TEST SCRIPT END ===




The full log is available at
http://patchew.org/logs/20190626162100.24774-1-laur...@vivier.eu/testing.s390x/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

Re: [Qemu-devel] [PATCH] xen-block: support feature-large-sector-size

[Max Reitz]

On 09.04.19 18:40, Paul Durrant wrote:
> A recent Xen commit [1] clarified the semantics of sector based quantities
> used in the blkif protocol such that it is now safe to create a xen-block
> device with a logical_block_size != 512, as long as the device only
> connects to a frontend advertizing 'feature-large-block-size'.
> 
> This patch modifies xen-block accordingly. It also uses a stack variable
> for the BlockBackend in xen_block_realize() to avoid repeated dereferencing
> of the BlockConf pointer, and changes the parameters of
> xen_block_dataplane_create() so that the BlockBackend pointer and sector
> size are passed expicitly rather than implicitly via the BlockConf.
> 
> These modifications have been tested against a recent Windows PV XENVBD
> driver [2] using a xen-disk device with a 4kB logical block size.
> 
> [1] 
> http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=67e1c050e36b2c9900cca83618e56189effbad98
> [2] https://winpvdrvbuild.xenproject.org:8080/job/XENVBD-master/126
> 
> Signed-off-by: Paul Durrant 
> ---
> Cc: Stefano Stabellini 
> Cc: Anthony Perard 
> Cc: Stefan Hajnoczi 
> Cc: Kevin Wolf 
> Cc: Max Reitz 
> ---
>  hw/block/dataplane/xen-block.c | 25 --
>  hw/block/dataplane/xen-block.h |  3 ++-
>  hw/block/xen-block.c   | 38 +-
>  3 files changed, 40 insertions(+), 26 deletions(-)

Thanks, added “by frontend” to the error message and applied to my block
branch:

https://git.xanclic.moe/XanClic/qemu/commits/branch/block

Max



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v2] Fix build error when VNC is configured out

[Stefano Garzarella]

On Tue, Jun 25, 2019 at 02:39:05PM +0200, Christophe de Dinechin wrote:
> In hmp_change(), the variable hmp_mon is only used
> by code under #ifdef CONFIG_VNC. This results in a build
> error when VNC is configured out with the default of
> treating warnings as errors:
> 
> monitor/hmp-cmds.c: In function ‘hmp_change’:
> monitor/hmp-cmds.c:1946:17: error: unused variable ‘hmp_mon’ 
> [-Werror=unused-variable]
> 1946 | MonitorHMP *hmp_mon = container_of(mon, MonitorHMP, common);
>  | ^~~
> 
> v2: Move variable down as suggested by Philippe Mathieu-Daudé

Should we move out this line from the commit message?
(Maybe Dave can remove it when apply)

> 
> Signed-off-by: Christophe de Dinechin 
> ---
>  monitor/hmp-cmds.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Stefano Garzarella 

Re: [Qemu-devel] [Qemu-trivial] Fix cacheline size retrieval on FreeBSD/PowerPC(64)

[Laurent Vivier]

Le 26/06/2019 à 18:37, Justin Hibbits a écrit :
> On Wed, 26 Jun 2019 18:16:36 +0200
> Laurent Vivier  wrote:
> 
>> Le 26/06/2019 à 18:14, Laurent Vivier a écrit :
>>> Le 07/06/2019 à 20:56, Justin Hibbits a écrit :  
 The attached very trivial patch fixes a startup bug that prevents
 at least Qemu 3.1 and later from working on FreeBSD/powerpc64.

 - Justin
  
>>>
>>> Please don't send a patch in attachment but inlined in the message
>>> (you may use "git send-email" for that).
>>>
>>> This patch fixes "util: add cacheinfo" that has changed the type
>>> from unsigned to long.
>>>
>>> You can add the following line in the commit message:
>>>
>>> Fixes: b255b2c8a548 ("util: add cacheinfo")
>>>
>>> Reviewed-by: Laurent Vivier 
>>>   
>>
>> CC: author of b255b2c8a548 ("util: add cacheinfo")
>>
>> Thanks,
>> Laurent
> 
> Hi Laurent,
> 
> Sorry.  I had never used git send-email before, so wasn't comfortable
> with it.  I just updated the commit message with your feedback and used
> git send-email to submit the patch.  I hope everything went well.

It seems not. I didn't receive it.

Did you configure the SMTP server. See git-send-email(1):

   Use gmail as the smtp server

   To use git send-email to send your patches through the GMail SMTP
   server, edit ~/.gitconfig to specify your account settings:

   [sendemail]
   smtpEncryption = tls
   smtpServer = smtp.gmail.com
   smtpUser = yourn...@gmail.com
   smtpServerPort = 587

   If you have multifactor authentication setup on your gmail account, you
   will need to generate an app-specific password for use with git
   send-email. Visit
   https://security.google.com/settings/security/apppasswords to create
   it.

   Once your commits are ready to be sent to the mailing list, run the
   following commands:

   $ git format-patch --cover-letter -M origin/master -o outgoing/
   $ edit outgoing/-*
   $ git send-email outgoing/*

   The first time you run it, you will be prompted for your credentials.
   Enter the app-specific or your regular password as appropriate. If you
   have credential helper configured (see git-credential(1)), the password
   will be saved in the credential store so you won’t have to type it the
   next time.

   Note: the following perl modules are required Net::SMTP::SSL,
   MIME::Base64 and Authen::SASL

Thanks,
Laurent

 

Re: [Qemu-devel] [Qemu-trivial] Fix cacheline size retrieval on FreeBSD/PowerPC(64)

[Justin Hibbits]

On Wed, 26 Jun 2019 18:16:36 +0200
Laurent Vivier  wrote:

> Le 26/06/2019 à 18:14, Laurent Vivier a écrit :
> > Le 07/06/2019 à 20:56, Justin Hibbits a écrit :  
> >> The attached very trivial patch fixes a startup bug that prevents
> >> at least Qemu 3.1 and later from working on FreeBSD/powerpc64.
> >>
> >> - Justin
> >>  
> > 
> > Please don't send a patch in attachment but inlined in the message
> > (you may use "git send-email" for that).
> > 
> > This patch fixes "util: add cacheinfo" that has changed the type
> > from unsigned to long.
> > 
> > You can add the following line in the commit message:
> > 
> > Fixes: b255b2c8a548 ("util: add cacheinfo")
> > 
> > Reviewed-by: Laurent Vivier 
> >   
> 
> CC: author of b255b2c8a548 ("util: add cacheinfo")
> 
> Thanks,
> Laurent

Hi Laurent,

Sorry.  I had never used git send-email before, so wasn't comfortable
with it.  I just updated the commit message with your feedback and used
git send-email to submit the patch.  I hope everything went well.

Thanks for your feedback.

- Justin

[Qemu-devel] [PULL 0/3] M68k next patches

[Laurent Vivier]

The following changes since commit 474f3938d79ab36b9231c9ad3b5a9314c2aeacde:

  Merge remote-tracking branch 'remotes/amarkovic/tags/mips-queue-jun-21-2019' 
into staging (2019-06-21 15:40:50 +0100)

are available in the Git repository at:

  git://github.com/vivier/qemu-m68k.git tags/m68k-next-pull-request

for you to fetch changes up to c6d0700f57b2c50229a27e31b9f99056a011215f:

  linux-user/m68k: remove simulator syscall interface (2019-06-26 17:14:41 
+0200)


remove m68k simulator syscall interface
Fix comments format
Fix gdbstub



Laurent Vivier (1):
  linux-user/m68k: remove simulator syscall interface

Lucien Murray-Pitts (2):
  The m68k gdbstub SR reg request doesnt include Condition-Codes
  m68k comments break patch submission due to being incorrectly
formatted

 linux-user/Makefile.objs|   1 -
 linux-user/m68k-sim.c   | 163 --
 linux-user/m68k/cpu_loop.c  |  17 +-
 linux-user/m68k/target_syscall.h|   2 -
 linux-user/qemu.h   |   1 -
 target/m68k/cpu-qom.h   |   2 +-
 target/m68k/cpu.c   |   6 +-
 target/m68k/cpu.h   |  29 ++--
 target/m68k/fpu_helper.c|   6 +-
 target/m68k/gdbstub.c   |   9 +-
 target/m68k/helper.c|  16 +-
 target/m68k/m68k-semi.c |  24 ++-
 target/m68k/op_helper.c |  58 ---
 target/m68k/softfloat.c | 181 ++--
 target/m68k/softfloat.h |   3 +-
 target/m68k/softfloat_fpsp_tables.h |   3 +-
 target/m68k/translate.c | 246 ++--
 17 files changed, 356 insertions(+), 411 deletions(-)
 delete mode 100644 linux-user/m68k-sim.c

-- 
2.21.0

Re: [Qemu-devel] [Qemu-trivial] [PATCH] MAINTAINERS: Change maintership of Xen code under hw/9pfs

[Greg Kurz]

On Wed, 26 Jun 2019 18:30:47 +0200
Laurent Vivier  wrote:

> Le 15/06/2019 à 07:43, Philippe Mathieu-Daudé a écrit :
> > Cc'ing qemu-trivial@
> > 
> > On 6/14/19 6:50 PM, Greg Kurz wrote:
> > [...]  
> >> Markus, Xen maintainers,
> >>
> >> All needed Acked-by have been provided. I don't plan to send a 9pfs PR
> >> anytime soon. Can this go through someone else's tree please ?
> >>
> >> Cheers,
> >>
> >> --
> >> Greg
> >>  
> >   
> 
> Applied to my trivial-patches branch.
> 
> Thanks,
> Laurent

Merci Laurent ! :)

Cheers,

--
Greg

[Qemu-devel] Add SPLIT_LOCK DETECT capability to SnowRidge (SNR) cpu model

[Paul Lai]

SPLIT_LOCK DETECT is enabled in qemu patch:
  x86: define a new MSR based feature word -- FEAT_CORE_CAPABILITY
and kernel patch series that includes:
  x86/split_lock: Align x86_capability to unsigned long to avoid split locked
access

WAITPKG (UMONITOR/UMWAIT/TPAUSE) supplied in:
  x86/cpu: Add support for UMONITOR/UMWAIT/TPAUSE
are turned off by default, so not added to this cpu model.

Signed-off-by: Paul Lai 
Tested-by: Tao3 Xu 

---
Changes in v4:
Add SPLIT_LOCK DETECT capability to SnowRidge (SNR) cpu model
---
 target/i386/cpu.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index c96f032f03..63d89276fe 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -2739,7 +2739,10 @@ static X86CPUDefinition builtin_x86_defs[] = {
 CPUID_7_0_ECX_MOVDIR64B,
 .features[FEAT_7_0_EDX] =
 CPUID_7_0_EDX_SPEC_CTRL |
-CPUID_7_0_EDX_ARCH_CAPABILITIES | CPUID_7_0_EDX_SPEC_CTRL_SSBD,
+CPUID_7_0_EDX_ARCH_CAPABILITIES | CPUID_7_0_EDX_SPEC_CTRL_SSBD |
+CPUID_7_0_EDX_CORE_CAPABILITY,
+.features[FEAT_CORE_CAPABILITY] =
+MSR_CORE_CAP_SPLIT_LOCK_DETECT,
 /*
  * Missing: XSAVES (not supported by some Linux versions,
  * including v4.1 to v4.12).
-- 
2.17.2

Re: [Qemu-devel] [Qemu-trivial] [PATCH] docs/vhost-user.json: some firmware.json copy leftovers

[Laurent Vivier]

Le 26/06/2019 à 18:24, Laurent Vivier a écrit :
> Le 05/06/2019 à 15:12, Marc-André Lureau a écrit :
>> Signed-off-by: Marc-André Lureau 
>> ---
>>  docs/interop/vhost-user.json | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/docs/interop/vhost-user.json b/docs/interop/vhost-user.json
>> index ae88c03117..da6aaf51c8 100644
>> --- a/docs/interop/vhost-user.json
>> +++ b/docs/interop/vhost-user.json
>> @@ -178,11 +178,11 @@
>>  #
>>  #   - /usr/share/qemu/vhost-user/50-crosvm-gpu.json
>>  #
>> -# then the sysadmin can prevent the default QEMU being used at all with
>> +# then the sysadmin can prevent the default QEMU GPU being used at all with
>>  #
>>  #   $ touch /etc/qemu/vhost-user/50-qemu-gpu.json
>>  #
>> -# The sysadmin can replace/alter the distro default OVMF with
>> +# The sysadmin can replace/alter the distro default QEMU GPU with
>>  #
>>  #   $ vim /etc/qemu/vhost-user/50-qemu-gpu.json
>>  #
>> @@ -190,7 +190,7 @@
>>  #
>>  #   $ vim /etc/qemu/vhost-user/10-qemu-gpu.json
>>  #
>> -# or they can provide a parallel OVMF with lower priority
>> +# or they can provide a parallel QEMU GPU with lower priority
>>  #
>>  #   $ vim /etc/qemu/vhost-user/99-qemu-gpu.json
>>  #
>>
> 
> Applied to my trivial-patches branch.

In fact, no, it has already been merged.

Thanks,
Laurent

Re: [Qemu-devel] [Qemu-trivial] [PATCH] docs/vhost-user.json: some firmware.json copy leftovers

[Laurent Vivier]

Le 05/06/2019 à 15:12, Marc-André Lureau a écrit :
> Signed-off-by: Marc-André Lureau 
> ---
>  docs/interop/vhost-user.json | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/docs/interop/vhost-user.json b/docs/interop/vhost-user.json
> index ae88c03117..da6aaf51c8 100644
> --- a/docs/interop/vhost-user.json
> +++ b/docs/interop/vhost-user.json
> @@ -178,11 +178,11 @@
>  #
>  #   - /usr/share/qemu/vhost-user/50-crosvm-gpu.json
>  #
> -# then the sysadmin can prevent the default QEMU being used at all with
> +# then the sysadmin can prevent the default QEMU GPU being used at all with
>  #
>  #   $ touch /etc/qemu/vhost-user/50-qemu-gpu.json
>  #
> -# The sysadmin can replace/alter the distro default OVMF with
> +# The sysadmin can replace/alter the distro default QEMU GPU with
>  #
>  #   $ vim /etc/qemu/vhost-user/50-qemu-gpu.json
>  #
> @@ -190,7 +190,7 @@
>  #
>  #   $ vim /etc/qemu/vhost-user/10-qemu-gpu.json
>  #
> -# or they can provide a parallel OVMF with lower priority
> +# or they can provide a parallel QEMU GPU with lower priority
>  #
>  #   $ vim /etc/qemu/vhost-user/99-qemu-gpu.json
>  #
> 

Applied to my trivial-patches branch.

Thanks,
Laurent

Re: [Qemu-devel] [Qemu-trivial] [PATCH] MAINTAINERS: Change maintership of Xen code under hw/9pfs

[Laurent Vivier]

Le 15/06/2019 à 07:43, Philippe Mathieu-Daudé a écrit :
> Cc'ing qemu-trivial@
> 
> On 6/14/19 6:50 PM, Greg Kurz wrote:
> [...]
>> Markus, Xen maintainers,
>>
>> All needed Acked-by have been provided. I don't plan to send a 9pfs PR
>> anytime soon. Can this go through someone else's tree please ?
>>
>> Cheers,
>>
>> --
>> Greg
>>
> 

Applied to my trivial-patches branch.

Thanks,
Laurent

Re: [Qemu-devel] [Qemu-trivial] [PATCH] configure: use valid args testing sem_timedwait

[Laurent Vivier]

Le 17/06/2019 à 13:41, Daniel P. Berrangé a écrit :
> The sem_timedwait function has been annotated as requiring
> non-null args in latest header files from GCC snapshot
> representing the future 2.30 release.
> 
> This causes configure to fail when -Werror is used:
> 
> config-temp/qemu-conf.c: In function ‘main’:
> config-temp/qemu-conf.c:2:25: error: null argument where non-null required 
> (argument 1) [-Werror=nonnull]
> 2 | int main(void) { return sem_timedwait(0, 0); }
>   | ^
> config-temp/qemu-conf.c:2:25: error: null argument where non-null required 
> (argument 2) [-Werror=nonnull]
> 
> Signed-off-by: Daniel P. Berrangé 
> ---
>  configure | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/configure b/configure
> index b091b82cb3..6632d05fc7 100755
> --- a/configure
> +++ b/configure
> @@ -5139,7 +5139,7 @@ fi
>  sem_timedwait=no
>  cat > $TMPC << EOF
>  #include 
> -int main(void) { return sem_timedwait(0, 0); }
> +int main(void) { sem_t s; struct timespec t = {0}; return sem_timedwait(, 
> ); }
>  EOF
>  if compile_prog "" "" ; then
>  sem_timedwait=yes
> 

Applied to my trivial-patches branch.

Thanks,
Laurent

[Qemu-devel] [PULL 3/3] linux-user/m68k: remove simulator syscall interface

[Laurent Vivier]

This interface has been introduced in 2005 with the
coldfire implementation (e6e5906b6e ColdFire target.)
and looks like to do what the linux-user interface already
does with the TRAP exception rather than the ILLEGAL
exception.

This interface has not been maintained since that.
The semi-hosting interface is not removed so coldfire kernel
with semi-hosting is always supported.

Signed-off-by: Laurent Vivier 
Message-Id: <20190524162049.806-1-laur...@vivier.eu>
Signed-off-by: Laurent Vivier 
---
 linux-user/Makefile.objs |   1 -
 linux-user/m68k-sim.c| 163 ---
 linux-user/m68k/cpu_loop.c   |  17 +---
 linux-user/m68k/target_syscall.h |   2 -
 linux-user/qemu.h|   1 -
 5 files changed, 1 insertion(+), 183 deletions(-)
 delete mode 100644 linux-user/m68k-sim.c

diff --git a/linux-user/Makefile.objs b/linux-user/Makefile.objs
index 285c5dfa17..d2f33beb5e 100644
--- a/linux-user/Makefile.objs
+++ b/linux-user/Makefile.objs
@@ -8,4 +8,3 @@ obj-$(TARGET_I386) += vm86.o
 obj-$(TARGET_ARM) += arm/nwfpe/
 obj-$(TARGET_ARM) += arm/semihost.o
 obj-$(TARGET_AARCH64) += arm/semihost.o
-obj-$(TARGET_M68K) += m68k-sim.o
diff --git a/linux-user/m68k-sim.c b/linux-user/m68k-sim.c
deleted file mode 100644
index 9bc6ff3d3a..00
--- a/linux-user/m68k-sim.c
+++ /dev/null
@@ -1,163 +0,0 @@
-/*
- *  m68k simulator syscall interface
- *
- *  Copyright (c) 2005 CodeSourcery, LLC. Written by Paul Brook.
- *
- *  This program is free software; you can redistribute it and/or modify
- *  it under the terms of the GNU General Public License as published by
- *  the Free Software Foundation; either version 2 of the License, or
- *  (at your option) any later version.
- *
- *  This program is distributed in the hope that it will be useful,
- *  but WITHOUT ANY WARRANTY; without even the implied warranty of
- *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *  GNU General Public License for more details.
- *
- *  You should have received a copy of the GNU General Public License
- *  along with this program; if not, see .
- */
-
-#include "qemu/osdep.h"
-
-#include "qemu.h"
-
-#define SYS_EXIT1
-#define SYS_READ3
-#define SYS_WRITE   4
-#define SYS_OPEN5
-#define SYS_CLOSE   6
-#define SYS_BRK 17
-#define SYS_FSTAT   28
-#define SYS_ISATTY  29
-#define SYS_LSEEK   199
-
-struct m68k_sim_stat {
-uint16_t sim_st_dev;
-uint16_t sim_st_ino;
-uint32_t sim_st_mode;
-uint16_t sim_st_nlink;
-uint16_t sim_st_uid;
-uint16_t sim_st_gid;
-uint16_t sim_st_rdev;
-uint32_t sim_st_size;
-uint32_t sim_st_atime;
-uint32_t sim_st_mtime;
-uint32_t sim_st_ctime;
-uint32_t sim_st_blksize;
-uint32_t sim_st_blocks;
-};
-
-static inline uint32_t check_err(CPUM68KState *env, uint32_t code)
-{
-  env->dregs[0] = code;
-  if (code == (uint32_t)-1) {
-  env->dregs[1] = errno;
-  } else {
-  env->dregs[1] = 0;
-  }
-  return code;
-}
-
-#define SIM_O_APPEND0x0008
-#define SIM_O_CREAT 0x0200
-#define SIM_O_TRUNC 0x0400
-#define SIM_O_EXCL  0x0800
-#define SIM_O_NONBLOCK  0x4000
-#define SIM_O_NOCTTY0x8000
-#define SIM_O_SYNC  0x2000
-
-static int translate_openflags(int flags)
-{
-int hf;
-
-switch (flags & 3) {
-case 0: hf = O_RDONLY; break;
-case 1: hf = O_WRONLY; break;
-case 2: hf = O_RDWR; break;
-default: hf = O_RDWR; break;
-}
-
-if (flags & SIM_O_APPEND) hf |= O_APPEND;
-if (flags & SIM_O_CREAT) hf |= O_CREAT;
-if (flags & SIM_O_TRUNC) hf |= O_TRUNC;
-if (flags & SIM_O_EXCL) hf |= O_EXCL;
-if (flags & SIM_O_NONBLOCK) hf |= O_NONBLOCK;
-if (flags & SIM_O_NOCTTY) hf |= O_NOCTTY;
-if (flags & SIM_O_SYNC) hf |= O_SYNC;
-
-return hf;
-}
-
-#define ARG(x) tswap32(args[x])
-void do_m68k_simcall(CPUM68KState *env, int nr)
-{
-uint32_t *args;
-
-args = (uint32_t *)(unsigned long)(env->aregs[7] + 4);
-switch (nr) {
-case SYS_EXIT:
-exit(ARG(0));
-case SYS_READ:
-check_err(env, read(ARG(0), (void *)(unsigned long)ARG(1), ARG(2)));
-break;
-case SYS_WRITE:
-check_err(env, write(ARG(0), (void *)(unsigned long)ARG(1), ARG(2)));
-break;
-case SYS_OPEN:
-check_err(env, open((char *)(unsigned long)ARG(0),
-translate_openflags(ARG(1)), ARG(2)));
-break;
-case SYS_CLOSE:
-{
-/* Ignore attempts to close stdin/out/err.  */
-int fd = ARG(0);
-if (fd > 2)
-  check_err(env, close(fd));
-else
-  check_err(env, 0);
-break;
-}
-case SYS_BRK:
-{
-int32_t ret;
-
-ret = do_brk((abi_ulong)ARG(0));
-if (ret == -ENOMEM)
-ret = -1;
-check_err(env, ret);
-}
-break;
-case 

[Qemu-devel] [Qemu-devel v4] Introduce SnowRidge CPU model

[Paul Lai]

SnowRidge CPU supports Accelerator Infrastrcture Architecture (MOVDIRI,
MOVDIR64B), CLDEMOTE and SPLIT_LOCK_DISABLE.

MOVDIRI, MOVDIR64B, and CLDEMOTE are found via CPUID.
The availability of SPLIT_LOCK_DISABLE is check via msr access

References can be found in either:
 https://software.intel.com/en-us/articles/intel-sdm
 
https://software.intel.com/en-us/download/intel-architecture-instruction-set-extensions-and-future-features-programming-reference

Signed-off-by: Paul Lai 
Tested-by: Tao3 Xu 
---
Somehow v3 didn't have the desired -Server on the model name ... 
---
 target/i386/cpu.c | 68 +++
 1 file changed, 68 insertions(+)

diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index da6eb67cfb..c96f032f03 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -2687,6 +2687,74 @@ static X86CPUDefinition builtin_x86_defs[] = {
 .xlevel = 0x8008,
 .model_id = "Intel Xeon Processor (Icelake)",
 },
+{
+.name = "SnowRidge-Server",
+.level = 27,
+.vendor = CPUID_VENDOR_INTEL,
+.family = 6,
+.model = 134,
+.stepping = 1,
+.features[FEAT_1_EDX] =
+/* missing: CPUID_PN CPUID_IA64 */
+/* missing: CPUID_DTS, CPUID_HT, CPUID_TM, CPUID_PBE */
+CPUID_FP87 | CPUID_VME | CPUID_DE | CPUID_PSE |
+CPUID_TSC | CPUID_MSR | CPUID_PAE | CPUID_MCE |
+CPUID_CX8 | CPUID_APIC | CPUID_SEP |
+CPUID_MTRR | CPUID_PGE | CPUID_MCA | CPUID_CMOV |
+CPUID_PAT | CPUID_PSE36 | CPUID_CLFLUSH |
+CPUID_MMX |
+CPUID_FXSR | CPUID_SSE | CPUID_SSE2,
+.features[FEAT_1_ECX] =
+CPUID_EXT_SSE3 | CPUID_EXT_PCLMULQDQ | CPUID_EXT_MONITOR |
+CPUID_EXT_VMX |
+CPUID_EXT_SSSE3 |
+CPUID_EXT_CX16 |
+CPUID_EXT_SSE41 |
+CPUID_EXT_SSE42 | CPUID_EXT_X2APIC | CPUID_EXT_MOVBE |
+CPUID_EXT_POPCNT |
+CPUID_EXT_TSC_DEADLINE_TIMER | CPUID_EXT_AES | CPUID_EXT_XSAVE |
+CPUID_EXT_RDRAND,
+.features[FEAT_8000_0001_EDX] =
+CPUID_EXT2_SYSCALL |
+CPUID_EXT2_NX |
+CPUID_EXT2_PDPE1GB | CPUID_EXT2_RDTSCP |
+CPUID_EXT2_LM,
+.features[FEAT_8000_0001_ECX] =
+CPUID_EXT3_LAHF_LM |
+CPUID_EXT3_3DNOWPREFETCH,
+.features[FEAT_7_0_EBX] =
+CPUID_7_0_EBX_FSGSBASE |
+CPUID_7_0_EBX_SMEP |
+CPUID_7_0_EBX_ERMS |
+CPUID_7_0_EBX_MPX |  /* missing bits 13, 15 */
+CPUID_7_0_EBX_RDSEED |
+CPUID_7_0_EBX_SMAP | CPUID_7_0_EBX_CLFLUSHOPT |
+CPUID_7_0_EBX_CLWB |
+CPUID_7_0_EBX_SHA_NI,
+.features[FEAT_7_0_ECX] =
+CPUID_7_0_ECX_UMIP |
+/* missing bit 5 */
+CPUID_7_0_ECX_GFNI |
+CPUID_7_0_ECX_MOVDIRI | CPUID_7_0_ECX_CLDEMOTE |
+CPUID_7_0_ECX_MOVDIR64B,
+.features[FEAT_7_0_EDX] =
+CPUID_7_0_EDX_SPEC_CTRL |
+CPUID_7_0_EDX_ARCH_CAPABILITIES | CPUID_7_0_EDX_SPEC_CTRL_SSBD,
+/*
+ * Missing: XSAVES (not supported by some Linux versions,
+ * including v4.1 to v4.12).
+ * KVM doesn't yet expose any XSAVES state save component,
+ * and the only one defined in Skylake (processor tracing)
+ * probably will block migration anyway.
+ */
+.features[FEAT_XSAVE] =
+CPUID_XSAVE_XSAVEOPT | CPUID_XSAVE_XSAVEC |
+CPUID_XSAVE_XGETBV1,
+.features[FEAT_6_EAX] =
+CPUID_6_EAX_ARAT,
+.xlevel = 0x8008,
+.model_id = "Intel Atom Processor (SnowRidge)",
+},
 {
 .name = "KnightsMill",
 .level = 0xd,
-- 
2.17.2

[Qemu-devel] [PULL 2/3] m68k comments break patch submission due to being incorrectly formatted

[Laurent Vivier]

From: Lucien Murray-Pitts 

Altering all comments in target/m68k to match Qemu coding styles so that future
patches wont fail due to style breaches.

Signed-off-by: Lucien Murray-Pitts 
Reviewed-by: Laurent Vivier 
Message-Id: <20190606234125.GA4830@localhost.localdomain>
Signed-off-by: Laurent Vivier 
---
 target/m68k/cpu-qom.h   |   2 +-
 target/m68k/cpu.c   |   6 +-
 target/m68k/cpu.h   |  29 ++--
 target/m68k/fpu_helper.c|   6 +-
 target/m68k/gdbstub.c   |   6 +-
 target/m68k/helper.c|  16 +-
 target/m68k/m68k-semi.c |  24 ++-
 target/m68k/op_helper.c |  58 ---
 target/m68k/softfloat.c | 181 ++--
 target/m68k/softfloat.h |   3 +-
 target/m68k/softfloat_fpsp_tables.h |   3 +-
 target/m68k/translate.c | 246 ++--
 12 files changed, 353 insertions(+), 227 deletions(-)

diff --git a/target/m68k/cpu-qom.h b/target/m68k/cpu-qom.h
index 9885bba317..0c157251a2 100644
--- a/target/m68k/cpu-qom.h
+++ b/target/m68k/cpu-qom.h
@@ -31,7 +31,7 @@
 #define M68K_CPU_GET_CLASS(obj) \
 OBJECT_GET_CLASS(M68kCPUClass, (obj), TYPE_M68K_CPU)
 
-/**
+/*
  * M68kCPUClass:
  * @parent_realize: The parent class' realize handler.
  * @parent_reset: The parent class' reset handler.
diff --git a/target/m68k/cpu.c b/target/m68k/cpu.c
index 3d0971d4a2..e6596de29c 100644
--- a/target/m68k/cpu.c
+++ b/target/m68k/cpu.c
@@ -203,8 +203,10 @@ static void any_cpu_initfn(Object *obj)
 m68k_set_feature(env, M68K_FEATURE_CF_ISA_APLUSC);
 m68k_set_feature(env, M68K_FEATURE_BRAL);
 m68k_set_feature(env, M68K_FEATURE_CF_FPU);
-/* MAC and EMAC are mututally exclusive, so pick EMAC.
-   It's mostly backwards compatible.  */
+/*
+ * MAC and EMAC are mututally exclusive, so pick EMAC.
+ * It's mostly backwards compatible.
+ */
 m68k_set_feature(env, M68K_FEATURE_CF_EMAC);
 m68k_set_feature(env, M68K_FEATURE_CF_EMAC_B);
 m68k_set_feature(env, M68K_FEATURE_USP);
diff --git a/target/m68k/cpu.h b/target/m68k/cpu.h
index 5ef200a9fb..20de3c379a 100644
--- a/target/m68k/cpu.h
+++ b/target/m68k/cpu.h
@@ -106,9 +106,11 @@ typedef struct CPUM68KState {
 float_status fp_status;
 
 uint64_t mactmp;
-/* EMAC Hardware deals with 48-bit values composed of one 32-bit and
-   two 8-bit parts.  We store a single 64-bit value and
-   rearrange/extend this when changing modes.  */
+/*
+ * EMAC Hardware deals with 48-bit values composed of one 32-bit and
+ * two 8-bit parts.  We store a single 64-bit value and
+ * rearrange/extend this when changing modes.
+ */
 uint64_t macc[4];
 uint32_t macsr;
 uint32_t mac_mask;
@@ -146,7 +148,7 @@ typedef struct CPUM68KState {
 uint32_t features;
 } CPUM68KState;
 
-/**
+/*
  * M68kCPU:
  * @env: #CPUM68KState
  *
@@ -171,9 +173,11 @@ int m68k_cpu_gdb_write_register(CPUState *cpu, uint8_t 
*buf, int reg);
 
 void m68k_tcg_init(void);
 void m68k_cpu_init_gdb(M68kCPU *cpu);
-/* you can call this signal handler from your SIGBUS and SIGSEGV
-   signal handlers to inform the virtual CPU of exceptions. non zero
-   is returned if the signal was handled by the virtual CPU.  */
+/*
+ * you can call this signal handler from your SIGBUS and SIGSEGV
+ * signal handlers to inform the virtual CPU of exceptions. non zero
+ * is returned if the signal was handled by the virtual CPU.
+ */
 int cpu_m68k_signal_handler(int host_signum, void *pinfo,
void *puc);
 uint32_t cpu_m68k_get_ccr(CPUM68KState *env);
@@ -182,7 +186,8 @@ void cpu_m68k_set_sr(CPUM68KState *env, uint32_t);
 void cpu_m68k_set_fpcr(CPUM68KState *env, uint32_t val);
 
 
-/* Instead of computing the condition codes after each m68k instruction,
+/*
+ * Instead of computing the condition codes after each m68k instruction,
  * QEMU just stores one operand (called CC_SRC), the result
  * (called CC_DEST) and the type of operation (called CC_OP). When the
  * condition codes are needed, the condition codes can be calculated
@@ -447,9 +452,11 @@ void m68k_switch_sp(CPUM68KState *env);
 
 void do_m68k_semihosting(CPUM68KState *env, int nr);
 
-/* There are 4 ColdFire core ISA revisions: A, A+, B and C.
-   Each feature covers the subset of instructions common to the
-   ISA revisions mentioned.  */
+/*
+ * There are 4 ColdFire core ISA revisions: A, A+, B and C.
+ * Each feature covers the subset of instructions common to the
+ * ISA revisions mentioned.
+ */
 
 enum m68k_features {
 M68K_FEATURE_M68000,
diff --git a/target/m68k/fpu_helper.c b/target/m68k/fpu_helper.c
index b35489ba4e..9b039c856d 100644
--- a/target/m68k/fpu_helper.c
+++ b/target/m68k/fpu_helper.c
@@ -25,7 +25,8 @@
 #include "exec/cpu_ldst.h"
 #include "softfloat.h"
 
-/* Undefined offsets may be different on various FPU.
+/*
+ * Undefined offsets may be different on various FPU.
  * On 68040 they 

Re: [Qemu-devel] [Qemu-trivial] Fix cacheline size retrieval on FreeBSD/PowerPC(64)

[Laurent Vivier]

Le 26/06/2019 à 18:14, Laurent Vivier a écrit :
> Le 07/06/2019 à 20:56, Justin Hibbits a écrit :
>> The attached very trivial patch fixes a startup bug that prevents at
>> least Qemu 3.1 and later from working on FreeBSD/powerpc64.
>>
>> - Justin
>>
> 
> Please don't send a patch in attachment but inlined in the message
> (you may use "git send-email" for that).
> 
> This patch fixes "util: add cacheinfo" that has changed the type from
> unsigned to long.
> 
> You can add the following line in the commit message:
> 
> Fixes: b255b2c8a548 ("util: add cacheinfo")
> 
> Reviewed-by: Laurent Vivier 
> 

CC: author of b255b2c8a548 ("util: add cacheinfo")

Thanks,
Laurent

Re: [Qemu-devel] [Qemu-trivial] Fix cacheline size retrieval on FreeBSD/PowerPC(64)

[Laurent Vivier]

Le 07/06/2019 à 20:56, Justin Hibbits a écrit :
> The attached very trivial patch fixes a startup bug that prevents at
> least Qemu 3.1 and later from working on FreeBSD/powerpc64.
> 
> - Justin
> 

Please don't send a patch in attachment but inlined in the message
(you may use "git send-email" for that).

This patch fixes "util: add cacheinfo" that has changed the type from
unsigned to long.

You can add the following line in the commit message:

Fixes: b255b2c8a548 ("util: add cacheinfo")

Reviewed-by: Laurent Vivier 

Re: [Qemu-devel] [PATCH v3 2/2] configure: disallow spaces and colons in source path and build path

[Laurent Vivier]

Le 26/05/2019 à 16:47, Antonio Ospite a écrit :
> From: Antonio Ospite 
> 
> The configure script breaks when the qemu source directory is in a path
> containing white spaces, in particular the list of targets is not
> correctly generated when calling "./configure --help" because of how the
> default_target_list variable is built.
> 
> In addition to that, *building* qemu from a directory with spaces breaks
> some assumptions in the Makefiles, even if the original source path does
> not contain spaces like in the case of an out-of-tree build, or when
> symlinks are involved.
> 
> To avoid these issues, refuse to run the configure script and the
> Makefile if there are spaces or colons in the source path or the build
> path, taking as inspiration what the kbuild system in linux does.
> 
> Buglink: https://bugs.launchpad.net/qemu/+bug/1817345
> 
> Reviewed-by: Eric Blake 
> Signed-off-by: Antonio Ospite 
> ---
>  Makefile  | 4 
>  configure | 5 +
>  2 files changed, 9 insertions(+)
> 
> diff --git a/Makefile b/Makefile
> index e02b88bcb1..bed1323a45 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1,5 +1,9 @@
>  # Makefile for QEMU.
>  
> +ifneq ($(words $(subst :, ,$(CURDIR))), 1)
> +  $(error main directory cannot contain spaces nor colons)
> +endif
> +
>  # Always point to the root of the build tree (needs GNU make).
>  BUILD_DIR=$(CURDIR)
>  
> diff --git a/configure b/configure
> index 9f12120ad9..2833d73ccc 100755
> --- a/configure
> +++ b/configure
> @@ -279,6 +279,11 @@ ld_has() {
>  # make source path absolute
>  source_path=$(cd "$(dirname -- "$0")"; pwd)
>  
> +if printf %s\\n "$source_path" "$PWD" | grep -q "[[:space:]:]";
> +then
> +  error_exit "main directory cannot contain spaces nor colons"
> +fi
> +
>  # default parameters
>  cpu=""
>  iasl="iasl"
> 

Applied to my trivial-patches branch.

Thanks,
Laurent