Re: [Qemu-devel] [PATCH v4 0/6] Add the STM32F405 and Netduino Plus 2 machine

2019-09-05 Thread no-reply
Patchew URL: 
https://patchew.org/QEMU/cover.1567750222.git.alist...@alistair23.me/



Hi,

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

Subject: [Qemu-devel] [PATCH v4 0/6] Add the STM32F405 and Netduino Plus 2 
machine
Message-id: cover.1567750222.git.alist...@alistair23.me
Type: series

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

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
8b0ecd4 hw/arm: Add the Netduino Plus 2
407f73f hw/arm: Add the STM32F4xx SoC
512fff3 hw/misc: Add the STM32F4xx EXTI device
2caad5c hw/misc: Add the STM32F4xx Sysconfig device
955f060 target/arm: Allow setting M mode entry and sp
d81d27f armv7m: Allow entry information to be returned

=== OUTPUT BEGIN ===
1/6 Checking commit d81d27f0996a (armv7m: Allow entry information to be 
returned)
WARNING: line over 80 characters
#24: FILE: hw/arm/armv7m.c:309:
+uint64_t armv7m_load_kernel(ARMCPU *cpu, const char *kernel_filename, int 
mem_size)

WARNING: line over 80 characters
#52: FILE: include/hw/arm/boot.h:36:
+uint64_t armv7m_load_kernel(ARMCPU *cpu, const char *kernel_filename, int 
mem_size);

total: 0 errors, 2 warnings, 30 lines checked

Patch 1/6 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
2/6 Checking commit 955f06078662 (target/arm: Allow setting M mode entry and sp)
3/6 Checking commit 2caad5c67035 (hw/misc: Add the STM32F4xx Sysconfig device)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#77: 
new file mode 100644

ERROR: suspect code indent for conditional statements (4, 7)
#135: FILE: hw/misc/stm32f4xx_syscfg.c:54:
+if (extract32(s->syscfg_exticr[icrreg], startbit, 4) == config) {
+   qemu_set_irq(s->gpio_out[irq], level);

WARNING: line over 80 characters
#222: FILE: hw/misc/stm32f4xx_syscfg.c:141:
+VMSTATE_UINT32_ARRAY(syscfg_exticr, STM32F4xxSyscfgState, 
SYSCFG_NUM_EXTICR),

total: 1 errors, 2 warnings, 285 lines checked

Patch 3/6 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

4/6 Checking commit 512fff3fab76 (hw/misc: Add the STM32F4xx EXTI device)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#50: 
new file mode 100644

total: 0 errors, 1 warnings, 281 lines checked

Patch 4/6 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
5/6 Checking commit 407f73fb3229 (hw/arm: Add the STM32F4xx SoC)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#57: 
new file mode 100644

total: 0 errors, 1 warnings, 404 lines checked

Patch 5/6 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
6/6 Checking commit 8b0ecd413bdc (hw/arm: Add the Netduino Plus 2)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#54: 
new file mode 100644

total: 0 errors, 1 warnings, 86 lines checked

Patch 6/6 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
=== OUTPUT END ===

Test command exited with code: 1


The full log is available at
http://patchew.org/logs/cover.1567750222.git.alist...@alistair23.me/testing.checkpatch/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

[Qemu-devel] [PATCH v4 6/6] hw/arm: Add the Netduino Plus 2

2019-09-05 Thread Alistair Francis
Signed-off-by: Alistair Francis 
---
 MAINTAINERS|  6 +
 hw/arm/Kconfig |  3 +++
 hw/arm/Makefile.objs   |  1 +
 hw/arm/netduinoplus2.c | 58 ++
 4 files changed, 68 insertions(+)
 create mode 100644 hw/arm/netduinoplus2.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 4aea8cb3fa..5f23865ce3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -828,6 +828,12 @@ M: Peter Maydell 
 S: Maintained
 F: hw/arm/netduino2.c
 
+Netduino Plus 2
+M: Alistair Francis 
+M: Peter Maydell 
+S: Maintained
+F: hw/arm/netduinoplus2.c
+
 SmartFusion2
 M: Subbaraya Sundeep 
 M: Peter Maydell 
diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index 46a4f052e9..c153ac0975 100644
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -101,6 +101,9 @@ config NETDUINOPLUS2
 bool
 select STM32F405_SOC
 
+config NETDUINOPLUS2
+bool
+
 config NSERIES
 bool
 select OMAP
diff --git a/hw/arm/Makefile.objs b/hw/arm/Makefile.objs
index 0191c22c4f..4267805dc9 100644
--- a/hw/arm/Makefile.objs
+++ b/hw/arm/Makefile.objs
@@ -11,6 +11,7 @@ obj-$(CONFIG_MAINSTONE) += mainstone.o
 obj-$(CONFIG_MICROBIT) += microbit.o
 obj-$(CONFIG_MUSICPAL) += musicpal.o
 obj-$(CONFIG_NETDUINO2) += netduino2.o
+obj-$(CONFIG_NETDUINOPLUS2) += netduinoplus2.o
 obj-$(CONFIG_NSERIES) += nseries.o
 obj-$(CONFIG_SX1) += omap_sx1.o
 obj-$(CONFIG_CHEETAH) += palm.o
diff --git a/hw/arm/netduinoplus2.c b/hw/arm/netduinoplus2.c
new file mode 100644
index 00..4a75da8543
--- /dev/null
+++ b/hw/arm/netduinoplus2.c
@@ -0,0 +1,58 @@
+/*
+ * Netduino Plus 2 Machine Model
+ *
+ * Copyright (c) 2014 Alistair Francis 
+ *
+ * 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 "qapi/error.h"
+#include "hw/boards.h"
+#include "qemu/error-report.h"
+#include "hw/arm/stm32f405_soc.h"
+#include "hw/arm/boot.h"
+
+static void netduinoplus2_init(MachineState *machine)
+{
+DeviceState *dev;
+uint32_t kernel_entry;
+
+dev = qdev_create(NULL, TYPE_STM32F405_SOC);
+qdev_prop_set_string(dev, "cpu-type", ARM_CPU_TYPE_NAME("cortex-m4"));
+object_property_set_bool(OBJECT(dev), true, "realized", &error_fatal);
+
+kernel_entry = armv7m_load_kernel(ARM_CPU(first_cpu),
+  machine->kernel_filename,
+  FLASH_SIZE);
+
+object_property_set_int(OBJECT(first_cpu), kernel_entry,
+"init-entry", &error_fatal);
+object_property_set_int(OBJECT(first_cpu),
+SRAM_BASE_ADDRESS + (SRAM_SIZE * 2) / 3,
+"init-sp", &error_fatal);
+}
+
+static void netduinoplus2_machine_init(MachineClass *mc)
+{
+mc->desc = "Netduino Plus 2 Machine";
+mc->init = netduinoplus2_init;
+}
+
+DEFINE_MACHINE("netduinoplus2", netduinoplus2_machine_init)
-- 
2.22.0




[Qemu-devel] [PATCH v4 5/6] hw/arm: Add the STM32F4xx SoC

2019-09-05 Thread Alistair Francis
Signed-off-by: Alistair Francis 
Reviewed-by: Peter Maydell 
---
 MAINTAINERS|   8 +
 hw/arm/Kconfig |   3 +
 hw/arm/Makefile.objs   |   1 +
 hw/arm/stm32f405_soc.c | 301 +
 include/hw/arm/stm32f405_soc.h |  73 
 5 files changed, 386 insertions(+)
 create mode 100644 hw/arm/stm32f405_soc.c
 create mode 100644 include/hw/arm/stm32f405_soc.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 65d8a7c2d2..4aea8cb3fa 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -814,6 +814,14 @@ F: hw/adc/*
 F: hw/ssi/stm32f2xx_spi.c
 F: include/hw/*/stm32*.h
 
+STM32F405
+M: Alistair Francis 
+M: Peter Maydell 
+S: Maintained
+F: hw/arm/stm32f405_soc.c
+F: hw/misc/stm32f4xx_syscfg.c
+F: hw/misc/stm32f4xx_exti.c
+
 Netduino 2
 M: Alistair Francis 
 M: Peter Maydell 
diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index 68a3b27685..46a4f052e9 100644
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -313,6 +313,9 @@ config STM32F405_SOC
 select STM32F4XX_SYSCFG
 select STM32F4XX_EXTI
 
+config STM32F405_SOC
+bool
+
 config XLNX_ZYNQMP_ARM
 bool
 select AHCI
diff --git a/hw/arm/Makefile.objs b/hw/arm/Makefile.objs
index 43ce8d5b19..0191c22c4f 100644
--- a/hw/arm/Makefile.objs
+++ b/hw/arm/Makefile.objs
@@ -36,6 +36,7 @@ obj-$(CONFIG_STRONGARM) += strongarm.o
 obj-$(CONFIG_ALLWINNER_A10) += allwinner-a10.o cubieboard.o
 obj-$(CONFIG_RASPI) += bcm2835_peripherals.o bcm2836.o raspi.o
 obj-$(CONFIG_STM32F205_SOC) += stm32f205_soc.o
+obj-$(CONFIG_STM32F405_SOC) += stm32f405_soc.o
 obj-$(CONFIG_XLNX_ZYNQMP_ARM) += xlnx-zynqmp.o xlnx-zcu102.o
 obj-$(CONFIG_XLNX_VERSAL) += xlnx-versal.o xlnx-versal-virt.o
 obj-$(CONFIG_FSL_IMX25) += fsl-imx25.o imx25_pdk.o
diff --git a/hw/arm/stm32f405_soc.c b/hw/arm/stm32f405_soc.c
new file mode 100644
index 00..498bc1192c
--- /dev/null
+++ b/hw/arm/stm32f405_soc.c
@@ -0,0 +1,301 @@
+/*
+ * STM32F405 SoC
+ *
+ * Copyright (c) 2014 Alistair Francis 
+ *
+ * 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 "qapi/error.h"
+#include "qemu-common.h"
+#include "exec/address-spaces.h"
+#include "hw/arm/stm32f405_soc.h"
+#include "hw/misc/unimp.h"
+
+#define SYSCFG_ADD 0x40013800
+static const uint32_t usart_addr[] = { 0x40011000, 0x40004400, 0x40004800,
+   0x40004C00, 0x40005000, 0x40011400,
+   0x40007800, 0x40007C00 };
+/* At the moment only Timer 2 to 5 are modelled */
+static const uint32_t timer_addr[] = { 0x4000, 0x4400,
+   0x4800, 0x4C00 };
+#define ADC_ADDR   0x40012000
+static const uint32_t spi_addr[] =   { 0x40013000, 0x40003800, 0x40003C00,
+   0x40013400, 0x40015000, 0x40015400 };
+#define EXTI_ADDR  0x40013C00
+
+#define SYSCFG_IRQ   71
+static const int usart_irq[] = { 37, 38, 39, 52, 53, 71, 82, 83 };
+static const int timer_irq[] = { 28, 29, 30, 50 };
+#define ADC_IRQ 18
+static const int spi_irq[] =   { 35, 36, 51, 0, 0, 0 };
+static const int exti_irq[] =  { 6, 7, 8, 9, 10, 23, 23, 23, 23, 23, 40,
+ 40, 40, 40, 40, 40} ;
+
+
+static void stm32f405_soc_initfn(Object *obj)
+{
+STM32F405State *s = STM32F405_SOC(obj);
+int i;
+
+sysbus_init_child_obj(obj, "armv7m", &s->armv7m, sizeof(s->armv7m),
+  TYPE_ARMV7M);
+
+sysbus_init_child_obj(obj, "syscfg", &s->syscfg, sizeof(s->syscfg),
+  TYPE_STM32F4XX_SYSCFG);
+
+for (i = 0; i < STM_NUM_USARTS; i++) {
+sysbus_init_child_obj(obj, "usart[*]", &s->usart[i],
+  sizeof(s->usart[i]), TYPE_STM32F2XX_USART);
+}
+
+for (i = 0; i < STM_NUM_TIMERS; i++) {
+sysbus_init_child_obj(obj, "timer[*]", &s->timer[i],
+  

[Qemu-devel] [PATCH v4 2/6] target/arm: Allow setting M mode entry and sp

2019-09-05 Thread Alistair Francis
Add M mode initial entry PC and SP properties.

Signed-off-by: Alistair Francis 
---
 target/arm/cpu.c | 52 +++-
 target/arm/cpu.h |  3 +++
 2 files changed, 50 insertions(+), 5 deletions(-)

diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index 2399c14471..315aa503f6 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -311,6 +311,9 @@ static void arm_cpu_reset(CPUState *s)
  */
 initial_msp = ldl_p(rom);
 initial_pc = ldl_p(rom + 4);
+} else if (cpu->init_sp || cpu->init_entry) {
+initial_msp = cpu->init_sp;
+initial_pc = cpu->init_entry;
 } else {
 /* Address zero not covered by a ROM blob, or the ROM blob
  * is in non-modifiable memory and this is a second reset after
@@ -1055,6 +1058,38 @@ static void arm_set_init_svtor(Object *obj, Visitor *v, 
const char *name,
 visit_type_uint32(v, name, &cpu->init_svtor, errp);
 }
 
+static void arm_get_init_sp(Object *obj, Visitor *v, const char *name,
+void *opaque, Error **errp)
+{
+ARMCPU *cpu = ARM_CPU(obj);
+
+visit_type_uint32(v, name, &cpu->init_sp, errp);
+}
+
+static void arm_set_init_sp(Object *obj, Visitor *v, const char *name,
+void *opaque, Error **errp)
+{
+ARMCPU *cpu = ARM_CPU(obj);
+
+visit_type_uint32(v, name, &cpu->init_sp, errp);
+}
+
+static void arm_get_init_entry(Object *obj, Visitor *v, const char *name,
+void *opaque, Error **errp)
+{
+ARMCPU *cpu = ARM_CPU(obj);
+
+visit_type_uint32(v, name, &cpu->init_entry, errp);
+}
+
+static void arm_set_init_entry(Object *obj, Visitor *v, const char *name,
+void *opaque, Error **errp)
+{
+ARMCPU *cpu = ARM_CPU(obj);
+
+visit_type_uint32(v, name, &cpu->init_entry, errp);
+}
+
 void arm_cpu_post_init(Object *obj)
 {
 ARMCPU *cpu = ARM_CPU(obj);
@@ -1155,19 +1190,26 @@ void arm_cpu_post_init(Object *obj)
 }
 }
 
+/*
+ * M profile: initial value of the SP, entry and Secure VTOR.
+ * We can't just use a simple DEFINE_PROP_UINT32 for this because we want
+ * to permit the property to be set after realize.
+ */
 if (arm_feature(&cpu->env, ARM_FEATURE_M_SECURITY)) {
 object_property_add_link(obj, "idau", TYPE_IDAU_INTERFACE, &cpu->idau,
  qdev_prop_allow_set_link_before_realize,
  OBJ_PROP_LINK_STRONG,
  &error_abort);
-/*
- * M profile: initial value of the Secure VTOR. We can't just use
- * a simple DEFINE_PROP_UINT32 for this because we want to permit
- * the property to be set after realize.
- */
 object_property_add(obj, "init-svtor", "uint32",
 arm_get_init_svtor, arm_set_init_svtor,
 NULL, NULL, &error_abort);
+} else if (arm_feature(&cpu->env, ARM_FEATURE_M)) {
+object_property_add(obj, "init-sp", "uint32",
+arm_get_init_sp, arm_set_init_sp,
+NULL, NULL, &error_abort);
+object_property_add(obj, "init-entry", "uint32",
+arm_get_init_entry, arm_set_init_entry,
+NULL, NULL, &error_abort);
 }
 
 qdev_property_add_static(DEVICE(obj), &arm_cpu_cfgend_property,
diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index 297ad5e47a..4856d4c36b 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -805,6 +805,9 @@ struct ARMCPU {
  */
 uint32_t psci_conduit;
 
+/* For M, initial value of the entry and SP */
+uint32_t init_sp, init_entry;
+
 /* For v8M, initial value of the Secure VTOR */
 uint32_t init_svtor;
 
-- 
2.22.0




[Qemu-devel] [PATCH v4 3/6] hw/misc: Add the STM32F4xx Sysconfig device

2019-09-05 Thread Alistair Francis
Signed-off-by: Alistair Francis 
Reviewed-by: Peter Maydell 
---
 default-configs/arm-softmmu.mak|   1 +
 hw/arm/Kconfig |   9 ++
 hw/misc/Kconfig|   3 +
 hw/misc/Makefile.objs  |   1 +
 hw/misc/stm32f4xx_syscfg.c | 168 +
 hw/misc/trace-events   |   6 ++
 include/hw/misc/stm32f4xx_syscfg.h |  61 +++
 7 files changed, 249 insertions(+)
 create mode 100644 hw/misc/stm32f4xx_syscfg.c
 create mode 100644 include/hw/misc/stm32f4xx_syscfg.h

diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
index 1f2e0e7fde..645e6201bb 100644
--- a/default-configs/arm-softmmu.mak
+++ b/default-configs/arm-softmmu.mak
@@ -30,6 +30,7 @@ CONFIG_Z2=y
 CONFIG_COLLIE=y
 CONFIG_ASPEED_SOC=y
 CONFIG_NETDUINO2=y
+CONFIG_NETDUINOPLUS2=y
 CONFIG_MPS2=y
 CONFIG_RASPI=y
 CONFIG_DIGIC=y
diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index 76a2a6bcbf..9019c9fa50 100644
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -97,6 +97,10 @@ config NETDUINO2
 bool
 select STM32F205_SOC
 
+config NETDUINOPLUS2
+bool
+select STM32F405_SOC
+
 config NSERIES
 bool
 select OMAP
@@ -303,6 +307,11 @@ config STM32F205_SOC
 select STM32F2XX_ADC
 select STM32F2XX_SPI
 
+config STM32F405_SOC
+bool
+select ARM_V7M
+select STM32F4XX_SYSCFG
+
 config XLNX_ZYNQMP_ARM
 bool
 select AHCI
diff --git a/hw/misc/Kconfig b/hw/misc/Kconfig
index 51754bb47c..b9097ab2e0 100644
--- a/hw/misc/Kconfig
+++ b/hw/misc/Kconfig
@@ -82,6 +82,9 @@ config IMX
 config STM32F2XX_SYSCFG
 bool
 
+config STM32F4XX_SYSCFG
+bool
+
 config MIPS_ITU
 bool
 
diff --git a/hw/misc/Makefile.objs b/hw/misc/Makefile.objs
index e4aad707fb..51da9abf2a 100644
--- a/hw/misc/Makefile.objs
+++ b/hw/misc/Makefile.objs
@@ -57,6 +57,7 @@ obj-$(CONFIG_SLAVIO) += slavio_misc.o
 obj-$(CONFIG_ZYNQ) += zynq_slcr.o
 obj-$(CONFIG_ZYNQ) += zynq-xadc.o
 obj-$(CONFIG_STM32F2XX_SYSCFG) += stm32f2xx_syscfg.o
+obj-$(CONFIG_STM32F4XX_SYSCFG) += stm32f4xx_syscfg.o
 obj-$(CONFIG_MIPS_CPS) += mips_cmgcr.o
 obj-$(CONFIG_MIPS_CPS) += mips_cpc.o
 obj-$(CONFIG_MIPS_ITU) += mips_itu.o
diff --git a/hw/misc/stm32f4xx_syscfg.c b/hw/misc/stm32f4xx_syscfg.c
new file mode 100644
index 00..b34fb34885
--- /dev/null
+++ b/hw/misc/stm32f4xx_syscfg.c
@@ -0,0 +1,168 @@
+/*
+ * STM32F4xx SYSCFG
+ *
+ * Copyright (c) 2014 Alistair Francis 
+ *
+ * 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 "qemu/log.h"
+#include "trace.h"
+#include "hw/misc/stm32f4xx_syscfg.h"
+
+static void stm32f4xx_syscfg_reset(DeviceState *dev)
+{
+STM32F4xxSyscfgState *s = STM32F4XX_SYSCFG(dev);
+
+s->syscfg_memrmp = 0x;
+s->syscfg_pmc = 0x;
+s->syscfg_exticr[0] = 0x;
+s->syscfg_exticr[1] = 0x;
+s->syscfg_exticr[2] = 0x;
+s->syscfg_exticr[3] = 0x;
+s->syscfg_cmpcr = 0x;
+}
+
+static void stm32f4xx_syscfg_set_irq(void *opaque, int irq, int level)
+{
+STM32F4xxSyscfgState *s = opaque;
+int icrreg = irq / 4;
+int startbit = (irq & 3) * 4;
+uint8_t config = config = irq / 16;
+
+trace_stm32f4xx_syscfg_set_irq(irq / 16, irq % 16, level);
+
+g_assert(icrreg < SYSCFG_NUM_EXTICR);
+
+if (extract32(s->syscfg_exticr[icrreg], startbit, 4) == config) {
+   qemu_set_irq(s->gpio_out[irq], level);
+   trace_stm32f4xx_pulse_exti(irq);
+   }
+}
+
+static uint64_t stm32f4xx_syscfg_read(void *opaque, hwaddr addr,
+ unsigned int size)
+{
+STM32F4xxSyscfgState *s = opaque;
+
+trace_stm32f4xx_syscfg_read(addr);
+
+switch (addr) {
+case SYSCFG_MEMRMP:
+return s->syscfg_memrmp;
+case SYSCFG_PMC:
+return s->syscfg_pmc;
+case SYSCFG_EXTICR1...SYSCFG_EXTICR4:
+return s->syscfg_exticr[addr / 4 - SYSCFG_EXTICR1 / 4];
+case SYSC

[Qemu-devel] [PATCH v4 4/6] hw/misc: Add the STM32F4xx EXTI device

2019-09-05 Thread Alistair Francis
Signed-off-by: Alistair Francis 
Reviewed-by: Peter Maydell 
---
 hw/arm/Kconfig   |   1 +
 hw/misc/Kconfig  |   3 +
 hw/misc/Makefile.objs|   1 +
 hw/misc/stm32f4xx_exti.c | 187 +++
 hw/misc/trace-events |   5 +
 include/hw/misc/stm32f4xx_exti.h |  60 ++
 6 files changed, 257 insertions(+)
 create mode 100644 hw/misc/stm32f4xx_exti.c
 create mode 100644 include/hw/misc/stm32f4xx_exti.h

diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index 9019c9fa50..68a3b27685 100644
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -311,6 +311,7 @@ config STM32F405_SOC
 bool
 select ARM_V7M
 select STM32F4XX_SYSCFG
+select STM32F4XX_EXTI
 
 config XLNX_ZYNQMP_ARM
 bool
diff --git a/hw/misc/Kconfig b/hw/misc/Kconfig
index b9097ab2e0..fa56e5d375 100644
--- a/hw/misc/Kconfig
+++ b/hw/misc/Kconfig
@@ -85,6 +85,9 @@ config STM32F2XX_SYSCFG
 config STM32F4XX_SYSCFG
 bool
 
+config STM32F4XX_EXTI
+bool
+
 config MIPS_ITU
 bool
 
diff --git a/hw/misc/Makefile.objs b/hw/misc/Makefile.objs
index 51da9abf2a..fdceae0c51 100644
--- a/hw/misc/Makefile.objs
+++ b/hw/misc/Makefile.objs
@@ -58,6 +58,7 @@ obj-$(CONFIG_ZYNQ) += zynq_slcr.o
 obj-$(CONFIG_ZYNQ) += zynq-xadc.o
 obj-$(CONFIG_STM32F2XX_SYSCFG) += stm32f2xx_syscfg.o
 obj-$(CONFIG_STM32F4XX_SYSCFG) += stm32f4xx_syscfg.o
+obj-$(CONFIG_STM32F4XX_EXTI) += stm32f4xx_exti.o
 obj-$(CONFIG_MIPS_CPS) += mips_cmgcr.o
 obj-$(CONFIG_MIPS_CPS) += mips_cpc.o
 obj-$(CONFIG_MIPS_ITU) += mips_itu.o
diff --git a/hw/misc/stm32f4xx_exti.c b/hw/misc/stm32f4xx_exti.c
new file mode 100644
index 00..04ac82ae26
--- /dev/null
+++ b/hw/misc/stm32f4xx_exti.c
@@ -0,0 +1,187 @@
+/*
+ * STM32F4XX EXTI
+ *
+ * Copyright (c) 2014 Alistair Francis 
+ *
+ * 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 "qemu/log.h"
+#include "trace.h"
+#include "hw/misc/stm32f4xx_exti.h"
+
+static void stm32f4xx_exti_reset(DeviceState *dev)
+{
+STM32F4xxExtiState *s = STM32F4XX_EXTI(dev);
+
+s->exti_imr = 0x;
+s->exti_emr = 0x;
+s->exti_rtsr = 0x;
+s->exti_ftsr = 0x;
+s->exti_swier = 0x;
+s->exti_pr = 0x;
+}
+
+static void stm32f4xx_exti_set_irq(void *opaque, int irq, int level)
+{
+STM32F4xxExtiState *s = opaque;
+
+if (!((1 << irq) & s->exti_imr)) {
+/* Interrupt is masked */
+return;
+}
+
+trace_stm32f4xx_exti_set_irq(irq, level);
+
+if (((1 << irq) & s->exti_rtsr) && level) {
+/* Rising Edge */
+qemu_irq_pulse(s->irq[irq]);
+s->exti_pr |= 1 << irq;
+}
+
+if (((1 << irq) & s->exti_ftsr) && !level) {
+/* Falling Edge */
+qemu_irq_pulse(s->irq[irq]);
+s->exti_pr |= 1 << irq;
+}
+}
+
+static uint64_t stm32f4xx_exti_read(void *opaque, hwaddr addr,
+ unsigned int size)
+{
+STM32F4xxExtiState *s = opaque;
+
+trace_stm32f4xx_exti_read(addr);
+
+switch (addr) {
+case EXTI_IMR:
+return s->exti_imr;
+case EXTI_EMR:
+return s->exti_emr;
+case EXTI_RTSR:
+return s->exti_rtsr;
+case EXTI_FTSR:
+return s->exti_ftsr;
+case EXTI_SWIER:
+return s->exti_swier;
+case EXTI_PR:
+return s->exti_pr;
+default:
+qemu_log_mask(LOG_GUEST_ERROR,
+  "STM32F4XX_exti_read: Bad offset %x\n", (int)addr);
+return 0;
+}
+return 0;
+}
+
+static void stm32f4xx_exti_write(void *opaque, hwaddr addr,
+   uint64_t val64, unsigned int size)
+{
+STM32F4xxExtiState *s = opaque;
+uint32_t value = (uint32_t) val64;
+
+trace_stm32f4xx_exti_write(addr, value);
+
+switch (addr) {
+case EXTI_IMR:
+s->exti_imr = value;
+return;
+case EXTI_EMR:
+s->exti_emr = value;
+return;
+

[Qemu-devel] [PATCH v4 0/6] Add the STM32F405 and Netduino Plus 2 machine

2019-09-05 Thread Alistair Francis


Now that the Arm-M4 CPU has been added to QEMU we can add the Netduino
Plus 2 machine. This is very similar to the STM32F205 and Netduino 2 SoC
and machine.

v4:
 - Rebase on master
v3:
 - Remove custom reset handler
 - Add init-entry and init-sp properties
 - Rebase on master (including Kconfig changes)
v2:
 - Reorder patchset
 - Return the kernel entry point instead of using a pointer
 - Address Peter's comments


Alistair Francis (6):
  armv7m: Allow entry information to be returned
  target/arm: Allow setting M mode entry and sp
  hw/misc: Add the STM32F4xx Sysconfig device
  hw/misc: Add the STM32F4xx EXTI device
  hw/arm: Add the STM32F4xx SoC
  hw/arm: Add the Netduino Plus 2

 MAINTAINERS|  14 ++
 default-configs/arm-softmmu.mak|   1 +
 hw/arm/Kconfig |  16 ++
 hw/arm/Makefile.objs   |   2 +
 hw/arm/armv7m.c|   4 +-
 hw/arm/netduinoplus2.c |  58 ++
 hw/arm/stm32f405_soc.c | 301 +
 hw/misc/Kconfig|   6 +
 hw/misc/Makefile.objs  |   2 +
 hw/misc/stm32f4xx_exti.c   | 187 ++
 hw/misc/stm32f4xx_syscfg.c | 168 
 hw/misc/trace-events   |  11 ++
 include/hw/arm/boot.h  |   4 +-
 include/hw/arm/stm32f405_soc.h |  73 +++
 include/hw/misc/stm32f4xx_exti.h   |  60 ++
 include/hw/misc/stm32f4xx_syscfg.h |  61 ++
 target/arm/cpu.c   |  52 -
 target/arm/cpu.h   |   3 +
 18 files changed, 1016 insertions(+), 7 deletions(-)
 create mode 100644 hw/arm/netduinoplus2.c
 create mode 100644 hw/arm/stm32f405_soc.c
 create mode 100644 hw/misc/stm32f4xx_exti.c
 create mode 100644 hw/misc/stm32f4xx_syscfg.c
 create mode 100644 include/hw/arm/stm32f405_soc.h
 create mode 100644 include/hw/misc/stm32f4xx_exti.h
 create mode 100644 include/hw/misc/stm32f4xx_syscfg.h

-- 
2.22.0




[Qemu-devel] [PATCH v4 1/6] armv7m: Allow entry information to be returned

2019-09-05 Thread Alistair Francis
Allow the kernel's entry point information to be returned when loading a
kernel.

Signed-off-by: Alistair Francis 
Reviewed-by: Philippe Mathieu-Daudé 
Tested-by: Philippe Mathieu-Daudé 
---
 hw/arm/armv7m.c   | 4 +++-
 include/hw/arm/boot.h | 4 +++-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/hw/arm/armv7m.c b/hw/arm/armv7m.c
index 7a3c48f002..40755d77db 100644
--- a/hw/arm/armv7m.c
+++ b/hw/arm/armv7m.c
@@ -306,7 +306,7 @@ static void armv7m_reset(void *opaque)
 cpu_reset(CPU(cpu));
 }
 
-void armv7m_load_kernel(ARMCPU *cpu, const char *kernel_filename, int mem_size)
+uint64_t armv7m_load_kernel(ARMCPU *cpu, const char *kernel_filename, int 
mem_size)
 {
 int image_size;
 uint64_t entry;
@@ -353,6 +353,8 @@ void armv7m_load_kernel(ARMCPU *cpu, const char 
*kernel_filename, int mem_size)
  * board must call this function!
  */
 qemu_register_reset(armv7m_reset, cpu);
+
+return entry;
 }
 
 static Property bitband_properties[] = {
diff --git a/include/hw/arm/boot.h b/include/hw/arm/boot.h
index 7f4d0ca7cd..e35b83c0d2 100644
--- a/include/hw/arm/boot.h
+++ b/include/hw/arm/boot.h
@@ -27,11 +27,13 @@ typedef enum {
  * @kernel_filename: file to load
  * @mem_size: mem_size: maximum image size to load
  *
+ * returns: location of the kernel's entry point
+ *
  * Load the guest image for an ARMv7M system. This must be called by
  * any ARMv7M board. (This is necessary to ensure that the CPU resets
  * correctly on system reset, as well as for kernel loading.)
  */
-void armv7m_load_kernel(ARMCPU *cpu, const char *kernel_filename, int 
mem_size);
+uint64_t armv7m_load_kernel(ARMCPU *cpu, const char *kernel_filename, int 
mem_size);
 
 /* arm_boot.c */
 struct arm_boot_info {
-- 
2.22.0




[Qemu-devel] Could not transaction encrypted image

2019-09-05 Thread 18781374080


hi ,everyone!
I am a newcomer to QEMU, and I don't know if it's a native question
I create snapshots of virtual machines that use encrypted disk, The console 
gave me the following error:
2019-09-06 10:13:41,902+0800 ERROR (jsonrpc/0) [virt.vm] 
(vmId='ebdb8b82-b8c0-46b1-bb2a-678873d46d2f') Unable to take snapshot (vm:4616)


Traceback(most recent call last):
File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py",line 4613, in 
snapshot
  self._dom,snapshotCreateXML(snapxml, snapFlags)
File "/usr/lib/python2.7/site-packages/vdsm/virt/virdomain.py", in line 98, 
in f 
   ret = attr(*args, **kwargs)
File "/usr/lib/python2.7/site-packages/vdsm/common/libvirtconnection.py", 
line 130, in wrapper
ret = f(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/vdsm/common/function.py", line 92, in 
wrapper
return func(inst, *args, **kwargs)
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 2620, in 
snapshotCreateXML
if ret is None:raise libvirtError('virDomainSnapshotCreateXML() failed', 
dom=self)
 libvirtError: internal error: unable to execute QEMU command 'transaction': 
Parameter 'encrypt.key-secret' is required for cipher





I know I need to add encrypt in 'transacton' command. The key - secret 
information, through the search after I found the QEMU command is through QMP, 
but I don't know how to compile and add the required information。

Any help or reminder is appreciated! thank you!

| |
18781374080
|
|
18781374...@163.com
|
签名由网易邮箱大师定制

[Qemu-devel] Could not transaction encrypted image

2019-09-05 Thread 18781374080


hi ,everyone!
I am a newcomer to QEMU, and I don't know if it's a native question
I create snapshots of virtual machines that use encrypted disk, The console 
gave me the following error:
2019-09-06 10:13:41,902+0800 ERROR (jsonrpc/0) [virt.vm] 
(vmId='ebdb8b82-b8c0-46b1-bb2a-678873d46d2f') Unable to take snapshot (vm:4616)

Traceback (most recent call last):

  File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 4613, in 
snapshot

self._dom.snapshotCreateXML(snapxml, snapFlags)

  File "/usr/lib/python2.7/site-packages/vdsm/virt/virdomain.py", line 98, in f

ret = attr(*args, **kwargs)

  File "/usr/lib/python2.7/site-packages/vdsm/common/libvirtconnection.py", 
line 130, in wrapper

ret = f(*args, **kwargs)

  File "/usr/lib/python2.7/site-packages/vdsm/common/function.py", line 92, in 
wrapper

return func(inst, *args, **kwargs)

  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 2620, in 
snapshotCreateXML

if ret is None:raise libvirtError('virDomainSnapshotCreateXML() failed', 
dom=self)

libvirtError: internal error: unable to execute QEMU command 'transaction': 
Parameter 'encrypt.key-secret' is required for cipher

I know I need to add encrypt in 'transacton' command. The key - secret 
information, through the search after I found the QEMU command is through QMP, 
but I don't know how to compile and add the required information,

Any help or reminder is appreciated! thank you!




| |
18781374080
|
|
18781374...@163.com
|
签名由网易邮箱大师定制

Re: [Qemu-devel] [Qemu-arm] [PATCH v5 17/17] target/arm: Rely on hflags correct in cpu_get_tb_cpu_state

2019-09-05 Thread Richard Henderson
On 9/5/19 11:50 AM, Alex Bennée wrote:
> I wish there was an assert form that would handily print out the
> difference between the two values. I wonder if glib has one...

g_assert_cmphex(), but checkpatch.pl flags its use because there's a glib
environment variable that disables the assert.


r~



[Qemu-devel] [PATCH] Check correct register for clock source

2019-09-05 Thread Amithash Prasad
When WDT_RESTART is written, the data is not the contents
of the WDT_CTRL register. Hence ensure we are looking at
WDT_CTRL to check if bit WDT_CTRL_1MHZ_CLK is set or not.

Signed-off-by: Amithash Prasad 
---
 hw/watchdog/wdt_aspeed.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/watchdog/wdt_aspeed.c b/hw/watchdog/wdt_aspeed.c
index 9b93213417..f710036535 100644
--- a/hw/watchdog/wdt_aspeed.c
+++ b/hw/watchdog/wdt_aspeed.c
@@ -140,7 +140,7 @@ static void aspeed_wdt_write(void *opaque, hwaddr offset, 
uint64_t data,
 case WDT_RESTART:
 if ((data & 0x) == WDT_RESTART_MAGIC) {
 s->regs[WDT_STATUS] = s->regs[WDT_RELOAD_VALUE];
-aspeed_wdt_reload(s, !(data & WDT_CTRL_1MHZ_CLK));
+aspeed_wdt_reload(s, !(s->regs[WDT_CTRL] & WDT_CTRL_1MHZ_CLK));
 }
 break;
 case WDT_CTRL:
-- 
2.21.0




Re: [Qemu-devel] [PATCH] Check correct register for clock source

2019-09-05 Thread Joel Stanley
On Fri, 6 Sep 2019 at 01:10, Amithash Prasad  wrote:
>
> When WDT_RESTART is written, the data is not the contents
> of the WDT_CTRL register. Hence ensure we are looking at
> WDT_CTRL to check if bit WDT_CTRL_1MHZ_CLK is set or not.
>
> Signed-off-by: Amithash Prasad 

Reviewed-by: Joel Stanley 

Thanks for the patch!

> ---
>  hw/watchdog/wdt_aspeed.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hw/watchdog/wdt_aspeed.c b/hw/watchdog/wdt_aspeed.c
> index 9b93213417..f710036535 100644
> --- a/hw/watchdog/wdt_aspeed.c
> +++ b/hw/watchdog/wdt_aspeed.c
> @@ -140,7 +140,7 @@ static void aspeed_wdt_write(void *opaque, hwaddr offset, 
> uint64_t data,
>  case WDT_RESTART:
>  if ((data & 0x) == WDT_RESTART_MAGIC) {
>  s->regs[WDT_STATUS] = s->regs[WDT_RELOAD_VALUE];
> -aspeed_wdt_reload(s, !(data & WDT_CTRL_1MHZ_CLK));
> +aspeed_wdt_reload(s, !(s->regs[WDT_CTRL] & WDT_CTRL_1MHZ_CLK));
>  }
>  break;
>  case WDT_CTRL:
> --
> 2.21.0
>



Re: [Qemu-devel] Cryptic errors from PIP install if missing openssl-devel

2019-09-05 Thread David Gibson
On Thu, Sep 05, 2019 at 09:38:24AM -0400, Cleber Rosa wrote:
> On Thu, Sep 05, 2019 at 12:09:24PM +1000, David Gibson wrote:
> > On Wed, Sep 04, 2019 at 03:57:17PM -0400, Cleber Rosa wrote:
> > > 
> > > Hi David,
> > > 
> > > I've pushed a branch here (most of the commits have already been sent
> > > separately):
> > > 
> > >https://github.com/clebergnu/qemu/tree/ppc64
> > > 
> > > I've tested on a RHEL 8 ppc64le Power 9, and it seems to work for me.
> > > My steps for building QEMU:
> > > 
> > >   - Configured with: '/home/cleber/src/qemu/configure' 
> > > '--enable-slirp=git' '--python=/usr/bin/python3' 
> > > '--target-list=x86_64-softmmu,ppc64-softmmu,arm-softmmu,aarch64-softmmu,mips-softmmu,mipsel-softmmu,mips64-softmmu,mips64el-softmmu,sh4-softmmu,s390x-softmmu,alpha-softmmu,m68k-softmmu,riscv64-softmmu'
> > >   - make
> > >   - make check-acceptance
> > > 
> > > Would you be able to test if that branch works smoothly for you?
> > 
> > So, with this tree I'm no longer getting problems if openssl-devel is
> > not installed, so that much looks good.
> > 
> > I am getting some different errors - I was seeing this before (with
> > openssl-devel installed) sometimes, but only sometimes.  I haven't yet
> > worked out a pattern for when they appeared.  They also don't appear
> > to be fatal, the rest of the tests seem to be running ok.  Any ideas?
> > 
> >  VENV/home/dwg/qemu/build/rhel8/tests/venv
> >   PIP /home/dwg/qemu/tests/requirements.txt
> >   AVOCADO tests/acceptance
> > Error running method "run" of plugin "html": 'Namespace' object has no 
> > attribute 'get'
> > Error running method "run" of plugin "varianter_cit": 'Namespace' object 
> > has no attribute 'get'
> 
> Hi David,
> 
> Yes, those should not be fatal.  Anyway, they are caused by two things:
> 
>  1) A second set of Avocado plugins installation with different versions
> than the Avocado installation on QEMU's tests venv

Ah!  That'll be from the Avocado setup that Lukaš set up on there for
some different tests.

>  2) The tests' venv, which is created with "--system-site-packages",
> option that is described as "Give the virtual environment access
> to the system site-packages dir."
> 
> The motivation to have "--system-site-packages" is that, if the user
> had any of the "requirements.txt" depedencies installed system wide,
> the venv would simply use it and skip downloads.  Maybe we should make
> that an optional feature, disabled by default, so that the test's venv
> is better isolated and more predictable by default.

If pip doesn't have good enough version tracking that it's verifying
the correct versions of the installed packages as well as the
presence, then yes I tend to agree that keeping it better isolated
would be preferable.

> 
> Eduardo,
> 
> I remember we discussed #2, so your opinion is appreciated here.
> 
> Thanks,
> - Cleber.
> 

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


signature.asc
Description: PGP signature


Re: [Qemu-devel] [PATCH v7 00/30] riscv: sifive_u: Improve the emulation fidelity of sifive_u machine

2019-09-05 Thread Bin Meng
Hi Palmer,

On Fri, Sep 6, 2019 at 3:00 AM Palmer Dabbelt  wrote:
>
> On Thu, 05 Sep 2019 08:25:46 PDT (-0700), bmeng...@gmail.com wrote:
> > Hi Alistair,
> >
> > On Thu, Sep 5, 2019 at 3:50 AM Alistair Francis  
> > wrote:
> >>
> >> On Sat, Aug 31, 2019 at 7:54 PM Bin Meng  wrote:
> >> >
> >> > As of today, the QEMU 'sifive_u' machine is a special target that does
> >> > not boot the upstream OpenSBI/U-Boot firmware images built for the real
> >> > SiFive HiFive Unleashed board. Hence OpenSBI supports a special platform
> >> > "qemu/sifive_u". For U-Boot, the sifive_fu540_defconfig is referenced
> >> > in the OpenSBI doc as its payload, but that does not boot at all due
> >> > to various issues in current QEMU 'sifive_u' machine codes.
> >> >
> >> > This series aims to improve the emulation fidelity of sifive_u machine,
> >> > so that the upstream OpenSBI, U-Boot and kernel images built for the
> >> > SiFive HiFive Unleashed board can be used out of the box without any
> >> > special hack.
> >> >
> >> > The major changes include:
> >> > - Heterogeneous harts creation supported, so that we can create a CPU
> >> >   that exactly mirrors the real hardware: 1 E51 + 4 U54.
> >> > - Implemented a PRCI model for FU540
> >> > - Implemented an OTP model for FU540, primarily used for storing serial
> >> >   number of the board
> >> > - Fixed GEM support that was seriously broken on sifive_u
> >> > - Synced device tree with upstream Linux kernel on sifive_u
> >> >
> >> > OpenSBI v0.4 image built for sifive/fu540 is included as the default
> >> > bios image for 'sifive_u' machine.
> >> >
> >> > The series is tested against OpenSBI v0.4 image for sifive/fu540
> >> > paltform, U-Boot v2019.10-rc1 image for sifive_fu540_defconfig,
> >> > and Linux kernel v5.3-rc3 image with the following patch:
> >> >
> >> > macb: Update compatibility string for SiFive FU540-C000 [1]
> >> >
> >> > OpenSBI + U-Boot, ping/tftpboot with U-Boot MACB driver works well.
> >> > Boot Linux 64-bit defconfig image, verified that system console on
> >> > the serial 0 and ping host work pretty well.
> >> >
> >> > An OpenSBI patch [2] was sent to drop the special "qemu/sifive_u" 
> >> > platform
> >> > support in OpenSBI. The original plan was to get the drop patch applied
> >> > after this QEMU series is merged. However after discussion in the OpenSBI
> >> > mailing list, it seems the best option for us is to let OpenSBI continue
> >> > shipping the special "qemu/sifive_u" platform support to work with QEMU
> >> > version <= 4.1 and deprecate the support sometime in the future. A patch
> >> > will need to be sent to OpenSBI mailing list to update its document.
> >> >
> >> > v4 is now rebased on Palmer's QEMU RISC-V repo "for-master" branch.
> >> > Dropped the following v3 patch that was already done by someone else.
> >> > - riscv: sifive_u: Generate an aliases node in the device tree
> >> > - riscv: sifive_u: Support loading initramfs
> >>
> >> I'm having trouble applying this. Do you mind sharing a public git branch?
> >
> > So I see Palmer has rebased his "for-master" branch against QEMU
> > master and now this patch series cannot be applied cleanly.
> >
> > Even worse, the current "for-master" branch has build errors for QEMU 
> > RISC-V.
>
> Sorry, I haven't gotten around to fixing up the patch queue for now.  It's
> always OK to just send stuff against Peter's master, particularly if it's a 
> big
> patch set like this, as that's more likely to be a stable base for testing.

I was originally using Peter's branch but later I got to know there
was some patch conflicts between my patch series and what was already
applied in the RISC-V queue. Hence I switched to rebase my series on
"for-master" since v4.

I will rebase my patch series again, and send out a v8 (hopefully the
last version) soon.

Regards,
Bin



[Qemu-devel] [PULL v2 9/9] nbd: Implement server use of NBD FAST_ZERO

2019-09-05 Thread Eric Blake
The server side is fairly straightforward: we can always advertise
support for detection of fast zero, and implement it by mapping the
request to the block layer BDRV_REQ_NO_FALLBACK.

Signed-off-by: Eric Blake 
Message-Id: <20190823143726.27062-5-ebl...@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy 
[eblake: update iotests 223, 233]
---
 nbd/server.c   | 8 ++--
 tests/qemu-iotests/223.out | 2 +-
 tests/qemu-iotests/233.out | 2 +-
 3 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/nbd/server.c b/nbd/server.c
index 4992148de1c4..28c3c8be854c 100644
--- a/nbd/server.c
+++ b/nbd/server.c
@@ -1513,7 +1513,8 @@ NBDExport *nbd_export_new(BlockDriverState *bs, uint64_t 
dev_offset,
 exp->nbdflags |= NBD_FLAG_CAN_MULTI_CONN;
 }
 } else {
-exp->nbdflags |= NBD_FLAG_SEND_TRIM | NBD_FLAG_SEND_WRITE_ZEROES;
+exp->nbdflags |= (NBD_FLAG_SEND_TRIM | NBD_FLAG_SEND_WRITE_ZEROES |
+  NBD_FLAG_SEND_FAST_ZERO);
 }
 assert(size <= INT64_MAX - dev_offset);
 exp->size = QEMU_ALIGN_DOWN(size, BDRV_SECTOR_SIZE);
@@ -2166,7 +2167,7 @@ static int nbd_co_receive_request(NBDRequestData *req, 
NBDRequest *request,
 if (request->type == NBD_CMD_READ && client->structured_reply) {
 valid_flags |= NBD_CMD_FLAG_DF;
 } else if (request->type == NBD_CMD_WRITE_ZEROES) {
-valid_flags |= NBD_CMD_FLAG_NO_HOLE;
+valid_flags |= NBD_CMD_FLAG_NO_HOLE | NBD_CMD_FLAG_FAST_ZERO;
 } else if (request->type == NBD_CMD_BLOCK_STATUS) {
 valid_flags |= NBD_CMD_FLAG_REQ_ONE;
 }
@@ -2305,6 +2306,9 @@ static coroutine_fn int nbd_handle_request(NBDClient 
*client,
 if (!(request->flags & NBD_CMD_FLAG_NO_HOLE)) {
 flags |= BDRV_REQ_MAY_UNMAP;
 }
+if (request->flags & NBD_CMD_FLAG_FAST_ZERO) {
+flags |= BDRV_REQ_NO_FALLBACK;
+}
 ret = blk_pwrite_zeroes(exp->blk, request->from + exp->dev_offset,
 request->len, flags);
 return nbd_send_generic_reply(client, request->handle, ret,
diff --git a/tests/qemu-iotests/223.out b/tests/qemu-iotests/223.out
index 2db0dc991a27..5d00398c11cb 100644
--- a/tests/qemu-iotests/223.out
+++ b/tests/qemu-iotests/223.out
@@ -49,7 +49,7 @@ exports available: 2
qemu:dirty-bitmap:b
  export: 'n2'
   size:  4194304
-  flags: 0x4ed ( flush fua trim zeroes df cache )
+  flags: 0xced ( flush fua trim zeroes df cache fast-zero )
   min block: 1
   opt block: 4096
   max block: 33554432
diff --git a/tests/qemu-iotests/233.out b/tests/qemu-iotests/233.out
index a3ecc4eb5ccf..24321efa113b 100644
--- a/tests/qemu-iotests/233.out
+++ b/tests/qemu-iotests/233.out
@@ -37,7 +37,7 @@ disk size: unavailable
 exports available: 1
  export: ''
   size:  67108864
-  flags: 0x4ed ( flush fua trim zeroes df cache )
+  flags: 0xced ( flush fua trim zeroes df cache fast-zero )
   min block: 1
   opt block: 4096
   max block: 33554432
-- 
2.21.0




[Qemu-devel] [PULL v2 6/9] nbd: Improve per-export flag handling in server

2019-09-05 Thread Eric Blake
When creating a read-only image, we are still advertising support for
TRIM and WRITE_ZEROES to the client, even though the client should not
be issuing those commands.  But seeing this requires looking across
multiple functions:

All callers to nbd_export_new() passed a single flag based solely on
whether the export allows writes.  Later, we then pass a constant set
of flags to nbd_negotiate_options() (namely, the set of flags which we
always support, at least for writable images), which is then further
dynamically modified with NBD_FLAG_SEND_DF based on client requests
for structured options.  Finally, when processing NBD_OPT_EXPORT_NAME
or NBD_OPT_EXPORT_GO we bitwise-or the original caller's flag with the
runtime set of flags we've built up over several functions.

Let's refactor things to instead compute a baseline of flags as soon
as possible which gets shared between multiple clients, in
nbd_export_new(), and changing the signature for the callers to pass
in a simpler bool rather than having to figure out flags.  We can then
get rid of the 'myflags' parameter to various functions, and instead
refer to client for everything we need (we still have to perform a
bitwise-OR for NBD_FLAG_SEND_DF during NBD_OPT_EXPORT_NAME and
NBD_OPT_EXPORT_GO, but it's easier to see what is being computed).
This lets us quit advertising senseless flags for read-only images, as
well as making the next patch for exposing FAST_ZERO support easier to
write.

Signed-off-by: Eric Blake 
Message-Id: <20190823143726.27062-2-ebl...@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy 
[eblake: improve commit message, update iotest 223]
---
 include/block/nbd.h|  2 +-
 blockdev-nbd.c |  3 +-
 nbd/server.c   | 62 +-
 qemu-nbd.c |  6 ++--
 tests/qemu-iotests/223.out |  2 +-
 5 files changed, 40 insertions(+), 35 deletions(-)

diff --git a/include/block/nbd.h b/include/block/nbd.h
index 991fd52a5134..2c87b42dfd48 100644
--- a/include/block/nbd.h
+++ b/include/block/nbd.h
@@ -326,7 +326,7 @@ typedef struct NBDClient NBDClient;

 NBDExport *nbd_export_new(BlockDriverState *bs, uint64_t dev_offset,
   uint64_t size, const char *name, const char *desc,
-  const char *bitmap, uint16_t nbdflags, bool shared,
+  const char *bitmap, bool readonly, bool shared,
   void (*close)(NBDExport *), bool writethrough,
   BlockBackend *on_eject_blk, Error **errp);
 void nbd_export_close(NBDExport *exp);
diff --git a/blockdev-nbd.c b/blockdev-nbd.c
index 1fcfdb0997c6..213f226ac1c4 100644
--- a/blockdev-nbd.c
+++ b/blockdev-nbd.c
@@ -187,8 +187,7 @@ void qmp_nbd_server_add(const char *device, bool has_name, 
const char *name,
 writable = false;
 }

-exp = nbd_export_new(bs, 0, len, name, NULL, bitmap,
- writable ? 0 : NBD_FLAG_READ_ONLY, !writable,
+exp = nbd_export_new(bs, 0, len, name, NULL, bitmap, !writable, !writable,
  NULL, false, on_eject_blk, errp);
 if (!exp) {
 return;
diff --git a/nbd/server.c b/nbd/server.c
index 74d205812fee..d5078f7468af 100644
--- a/nbd/server.c
+++ b/nbd/server.c
@@ -419,14 +419,14 @@ static void nbd_check_meta_export(NBDClient *client)

 /* Send a reply to NBD_OPT_EXPORT_NAME.
  * Return -errno on error, 0 on success. */
-static int nbd_negotiate_handle_export_name(NBDClient *client,
-uint16_t myflags, bool no_zeroes,
+static int nbd_negotiate_handle_export_name(NBDClient *client, bool no_zeroes,
 Error **errp)
 {
 char name[NBD_MAX_NAME_SIZE + 1];
 char buf[NBD_REPLY_EXPORT_NAME_SIZE] = "";
 size_t len;
 int ret;
+uint16_t myflags;

 /* Client sends:
 [20 ..  xx]   export name (length bytes)
@@ -454,10 +454,13 @@ static int nbd_negotiate_handle_export_name(NBDClient 
*client,
 return -EINVAL;
 }

-trace_nbd_negotiate_new_style_size_flags(client->exp->size,
- client->exp->nbdflags | myflags);
+myflags = client->exp->nbdflags;
+if (client->structured_reply) {
+myflags |= NBD_FLAG_SEND_DF;
+}
+trace_nbd_negotiate_new_style_size_flags(client->exp->size, myflags);
 stq_be_p(buf, client->exp->size);
-stw_be_p(buf + 8, client->exp->nbdflags | myflags);
+stw_be_p(buf + 8, myflags);
 len = no_zeroes ? 10 : sizeof(buf);
 ret = nbd_write(client->ioc, buf, len, errp);
 if (ret < 0) {
@@ -522,8 +525,7 @@ static int nbd_reject_length(NBDClient *client, bool fatal, 
Error **errp)
 /* Handle NBD_OPT_INFO and NBD_OPT_GO.
  * Return -errno on error, 0 if ready for next option, and 1 to move
  * into transmission phase.  */
-static int nbd_negotiate_handle_info(NBDClient *client, uint16_t myflags,
-

[Qemu-devel] [PULL v2 0/9] NBD patches through 2019-09-05

2019-09-05 Thread Eric Blake
The following changes since commit eac2f39602e0423adf56be410c9a22c31fec9a81:

  target/arm: Inline gen_bx_im into callers (2019-09-05 13:23:04 +0100)

are available in the Git repository at:

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

for you to fetch changes up to b491dbb7f8e09ef864770c205a3b5bce6c5c1881:

  nbd: Implement server use of NBD FAST_ZERO (2019-09-05 16:04:53 -0500)

v2 pull request: fix iotests 223 and 233 (only re-sending the patches
that needed tweaking, per this backport-diff):
001/9:[0002] [FC] 'nbd: Advertise multi-conn for shared read-only connections'
002/9:[] [--] 'nbd: Use g_autofree in a few places'
003/9:[0008] [FC] 'nbd: Tolerate more errors to structured reply request'
004/9:[] [--] 'block: workaround for unaligned byte range in fallocate()'
005/9:[] [--] 'docs: Update preferred NBD device syntax'
006/9:[0002] [FC] 'nbd: Improve per-export flag handling in server'
007/9:[] [--] 'nbd: Prepare for NBD_CMD_FLAG_FAST_ZERO'
008/9:[] [--] 'nbd: Implement client use of NBD FAST_ZERO'
009/9:[0004] [FC] 'nbd: Implement server use of NBD FAST_ZERO'


nbd patches for 2019-09-05

- Advertise NBD_FLAG_CAN_MULTI_CONN on readonly images
- Tolerate larger set of server error responses during handshake
- More precision on handling fallocate() failures due to alignment
- Better documentation of NBD connection URIs
- Implement new extension NBD_CMD_FLAG_FAST_ZERO to benefit qemu-img convert


Andrey Shinkevich (1):
  block: workaround for unaligned byte range in fallocate()

Eric Blake (8):
  nbd: Advertise multi-conn for shared read-only connections
  nbd: Use g_autofree in a few places
  nbd: Tolerate more errors to structured reply request
  docs: Update preferred NBD device syntax
  nbd: Improve per-export flag handling in server
  nbd: Prepare for NBD_CMD_FLAG_FAST_ZERO
  nbd: Implement client use of NBD FAST_ZERO
  nbd: Implement server use of NBD FAST_ZERO

 docs/interop/nbd.txt   |  2 ++
 qemu-doc.texi  | 11 --
 include/block/nbd.h|  6 +++-
 block/io.c |  2 +-
 block/file-posix.c |  7 
 block/nbd.c| 18 ++
 blockdev-nbd.c |  3 +-
 nbd/client.c   | 85 ++
 nbd/common.c   |  5 +++
 nbd/server.c   | 83 +---
 qemu-nbd.c |  7 ++--
 nbd/trace-events   |  2 +-
 tests/qemu-iotests/223.out |  4 +--
 tests/qemu-iotests/233.out | 10 +++---
 14 files changed, 141 insertions(+), 104 deletions(-)

-- 
2.21.0




[Qemu-devel] [PULL v2 1/9] nbd: Advertise multi-conn for shared read-only connections

2019-09-05 Thread Eric Blake
The NBD specification defines NBD_FLAG_CAN_MULTI_CONN, which can be
advertised when the server promises cache consistency between
simultaneous clients (basically, rules that determine what FUA and
flush from one client are able to guarantee for reads from another
client).  When we don't permit simultaneous clients (such as qemu-nbd
without -e), the bit makes no sense; and for writable images, we
probably have a lot more work before we can declare that actions from
one client are cache-consistent with actions from another.  But for
read-only images, where flush isn't changing any data, we might as
well advertise multi-conn support.  What's more, advertisement of the
bit makes it easier for clients to determine if 'qemu-nbd -e' was in
use, where a second connection will succeed rather than hang until the
first client goes away.

This patch affects qemu as server in advertising the bit.  We may want
to consider patches to qemu as client to attempt parallel connections
for higher throughput by spreading the load over those connections
when a server advertises multi-conn, but for now sticking to one
connection per nbd:// BDS is okay.

See also: https://bugzilla.redhat.com/1708300
Signed-off-by: Eric Blake 
Message-Id: <20190815185024.7010-1-ebl...@redhat.com>
[eblake: tweak blockdev-nbd.c to not request shared when writable,
fix iotest 233]
Reviewed-by: John Snow 
---
 docs/interop/nbd.txt   | 1 +
 include/block/nbd.h| 2 +-
 blockdev-nbd.c | 2 +-
 nbd/server.c   | 4 +++-
 qemu-nbd.c | 2 +-
 tests/qemu-iotests/223.out | 2 +-
 6 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/docs/interop/nbd.txt b/docs/interop/nbd.txt
index fc64473e02b2..6dfec7f47647 100644
--- a/docs/interop/nbd.txt
+++ b/docs/interop/nbd.txt
@@ -53,3 +53,4 @@ the operation of that feature.
 * 2.12: NBD_CMD_BLOCK_STATUS for "base:allocation"
 * 3.0: NBD_OPT_STARTTLS with TLS Pre-Shared Keys (PSK),
 NBD_CMD_BLOCK_STATUS for "qemu:dirty-bitmap:", NBD_CMD_CACHE
+* 4.2: NBD_FLAG_CAN_MULTI_CONN for sharable read-only exports
diff --git a/include/block/nbd.h b/include/block/nbd.h
index 7b36d672f046..991fd52a5134 100644
--- a/include/block/nbd.h
+++ b/include/block/nbd.h
@@ -326,7 +326,7 @@ typedef struct NBDClient NBDClient;

 NBDExport *nbd_export_new(BlockDriverState *bs, uint64_t dev_offset,
   uint64_t size, const char *name, const char *desc,
-  const char *bitmap, uint16_t nbdflags,
+  const char *bitmap, uint16_t nbdflags, bool shared,
   void (*close)(NBDExport *), bool writethrough,
   BlockBackend *on_eject_blk, Error **errp);
 void nbd_export_close(NBDExport *exp);
diff --git a/blockdev-nbd.c b/blockdev-nbd.c
index c621686131fd..1fcfdb0997c6 100644
--- a/blockdev-nbd.c
+++ b/blockdev-nbd.c
@@ -188,7 +188,7 @@ void qmp_nbd_server_add(const char *device, bool has_name, 
const char *name,
 }

 exp = nbd_export_new(bs, 0, len, name, NULL, bitmap,
- writable ? 0 : NBD_FLAG_READ_ONLY,
+ writable ? 0 : NBD_FLAG_READ_ONLY, !writable,
  NULL, false, on_eject_blk, errp);
 if (!exp) {
 return;
diff --git a/nbd/server.c b/nbd/server.c
index f55ccf8edfde..0fb41c6c50ea 100644
--- a/nbd/server.c
+++ b/nbd/server.c
@@ -1461,7 +1461,7 @@ static void nbd_eject_notifier(Notifier *n, void *data)

 NBDExport *nbd_export_new(BlockDriverState *bs, uint64_t dev_offset,
   uint64_t size, const char *name, const char *desc,
-  const char *bitmap, uint16_t nbdflags,
+  const char *bitmap, uint16_t nbdflags, bool shared,
   void (*close)(NBDExport *), bool writethrough,
   BlockBackend *on_eject_blk, Error **errp)
 {
@@ -1487,6 +1487,8 @@ NBDExport *nbd_export_new(BlockDriverState *bs, uint64_t 
dev_offset,
 perm = BLK_PERM_CONSISTENT_READ;
 if ((nbdflags & NBD_FLAG_READ_ONLY) == 0) {
 perm |= BLK_PERM_WRITE;
+} else if (shared) {
+nbdflags |= NBD_FLAG_CAN_MULTI_CONN;
 }
 blk = blk_new(bdrv_get_aio_context(bs), perm,
   BLK_PERM_CONSISTENT_READ | BLK_PERM_WRITE_UNCHANGED |
diff --git a/qemu-nbd.c b/qemu-nbd.c
index 83b6c32d73aa..2403ef3d0f9f 100644
--- a/qemu-nbd.c
+++ b/qemu-nbd.c
@@ -1173,7 +1173,7 @@ int main(int argc, char **argv)
 }

 export = nbd_export_new(bs, dev_offset, fd_size, export_name,
-export_description, bitmap, nbdflags,
+export_description, bitmap, nbdflags, shared > 1,
 nbd_export_closed, writethrough, NULL,
 &error_fatal);

diff --git a/tests/qemu-iotests/223.out b/tests/qemu-iotests/223.out
index d5201b2356a3..2bca28ae72f9 100644
--- a/tests/qemu-iotests/223.out
+++ b/tests/qemu-iotests/

[Qemu-devel] [PULL v2 3/9] nbd: Tolerate more errors to structured reply request

2019-09-05 Thread Eric Blake
A server may have a reason to reject a request for structured replies,
beyond just not recognizing them as a valid request; similarly, it may
have a reason for rejecting a request for a meta context.  It doesn't
hurt us to continue talking to such a server; otherwise 'qemu-nbd
--list' of such a server fails to display all available details about
the export.

Encountered when temporarily tweaking nbdkit to reply with
NBD_REP_ERR_POLICY.  Present since structured reply support was first
added (commit d795299b reused starttls handling, but starttls is
different in that we can't fall back to other behavior on any error).

Note that for an unencrypted client trying to connect to a server that
requires encryption, this defers the point of failure to when we
finally execute a strict command (such as NBD_OPT_GO or NBD_OPT_LIST),
now that the intermediate NBD_OPT_STRUCTURED_REPLY does not diagnose
NBD_REP_ERR_TLS_REQD as fatal; but as the protocol eventually gets us
to a command where we can't continue onwards, the changed error
message doesn't cause any security concerns.

Signed-off-by: Eric Blake 
Message-Id: <20190824172813.29720-3-ebl...@redhat.com>
Reviewed-by: Daniel P. Berrangé 
[eblake: fix iotest 233]
---
 nbd/client.c   | 63 --
 nbd/trace-events   |  2 +-
 tests/qemu-iotests/233.out |  8 ++---
 3 files changed, 38 insertions(+), 35 deletions(-)

diff --git a/nbd/client.c b/nbd/client.c
index a9d8d32feff7..b9dc829175f9 100644
--- a/nbd/client.c
+++ b/nbd/client.c
@@ -1,5 +1,5 @@
 /*
- *  Copyright (C) 2016-2018 Red Hat, Inc.
+ *  Copyright (C) 2016-2019 Red Hat, Inc.
  *  Copyright (C) 2005  Anthony Liguori 
  *
  *  Network Block Device Client Side
@@ -142,17 +142,18 @@ static int nbd_receive_option_reply(QIOChannel *ioc, 
uint32_t opt,
 return 0;
 }

-/* If reply represents success, return 1 without further action.
- * If reply represents an error, consume the optional payload of
- * the packet on ioc.  Then return 0 for unsupported (so the client
- * can fall back to other approaches), or -1 with errp set for other
- * errors.
+/*
+ * If reply represents success, return 1 without further action.  If
+ * reply represents an error, consume the optional payload of the
+ * packet on ioc.  Then return 0 for unsupported (so the client can
+ * fall back to other approaches), where @strict determines if only
+ * ERR_UNSUP or all errors fit that category, or -1 with errp set for
+ * other errors.
  */
 static int nbd_handle_reply_err(QIOChannel *ioc, NBDOptionReply *reply,
-Error **errp)
+bool strict, Error **errp)
 {
-char *msg = NULL;
-int result = -1;
+g_autofree char *msg = NULL;

 if (!(reply->type & (1 << 31))) {
 return 1;
@@ -163,26 +164,28 @@ static int nbd_handle_reply_err(QIOChannel *ioc, 
NBDOptionReply *reply,
 error_setg(errp, "server error %" PRIu32
" (%s) message is too long",
reply->type, nbd_rep_lookup(reply->type));
-goto cleanup;
+goto err;
 }
 msg = g_malloc(reply->length + 1);
 if (nbd_read(ioc, msg, reply->length, NULL, errp) < 0) {
 error_prepend(errp, "Failed to read option error %" PRIu32
   " (%s) message: ",
   reply->type, nbd_rep_lookup(reply->type));
-goto cleanup;
+goto err;
 }
 msg[reply->length] = '\0';
 trace_nbd_server_error_msg(reply->type,
nbd_reply_type_lookup(reply->type), msg);
 }

+if (reply->type == NBD_REP_ERR_UNSUP || !strict) {
+trace_nbd_reply_err_ignored(reply->option,
+nbd_opt_lookup(reply->option),
+reply->type, nbd_rep_lookup(reply->type));
+return 0;
+}
+
 switch (reply->type) {
-case NBD_REP_ERR_UNSUP:
-trace_nbd_reply_err_unsup(reply->option, 
nbd_opt_lookup(reply->option));
-result = 0;
-goto cleanup;
-
 case NBD_REP_ERR_POLICY:
 error_setg(errp, "Denied by server for option %" PRIu32 " (%s)",
reply->option, nbd_opt_lookup(reply->option));
@@ -227,12 +230,9 @@ static int nbd_handle_reply_err(QIOChannel *ioc, 
NBDOptionReply *reply,
 error_append_hint(errp, "server reported: %s\n", msg);
 }

- cleanup:
-g_free(msg);
-if (result < 0) {
-nbd_send_opt_abort(ioc);
-}
-return result;
+ err:
+nbd_send_opt_abort(ioc);
+return -1;
 }

 /* nbd_receive_list:
@@ -257,7 +257,7 @@ static int nbd_receive_list(QIOChannel *ioc, char **name, 
char **description,
 if (nbd_receive_option_reply(ioc, NBD_OPT_LIST, &reply, errp) < 0) {
 return -1;
 }
-error = nbd_handle_reply_err(ioc, &reply, errp);
+error = nbd_handle_reply_err(ioc, &reply, true, errp);
 

Re: [Qemu-devel] [PATCH v3] target/xtensa: linux-user: add call0 ABI support

2019-09-05 Thread Max Filippov
Hi Laurent,

On Mon, Aug 26, 2019 at 12:58 PM Max Filippov  wrote:
>
> Xtensa binaries built for call0 ABI don't rotate register window on
> function calls and returns. Invocation of signal handlers from the
> kernel is therefore different in windowed and call0 ABIs.
> There's currently no way to determine xtensa ELF binary ABI from the
> binary itself. Add handler for the -xtensa-abi-call0 command line
> parameter/QEMU_XTENSA_ABI_CALL0 envitonment variable to the qemu-user
> and record ABI choice. Use it to initialize PS.WOE in xtensa_cpu_reset.
> Check PS.WOE in setup_rt_frame to determine how a signal should be
> delivered.
>
> Signed-off-by: Max Filippov 
> ---
> Changes v2->v3:
>
> - revert to checking PS.WOE in the setup_rt_frame
>
> Changes v1->v2:
>
> - move handling of QEMU_XTENSA_ABI_CALL0 to linux-user/main.c
> - check xtensa_abi_call0 instead of PS.WOE in the setup_rt_frame
>
>  linux-user/main.c  | 17 +
>  linux-user/xtensa/signal.c | 25 +
>  target/xtensa/cpu.c| 24 
>  target/xtensa/cpu.h|  3 +++
>  4 files changed, 57 insertions(+), 12 deletions(-)

Could you please take a look at the most recent (v3) version of
this change?

The corresponding linux change is queued here:
https://github.com/jcmvbkbc/linux-xtensa/commit/09f8a6db20e6ed8eab1b2b23d09d2458f6e15062

-- 
Thanks.
-- Max



Re: [Qemu-devel] [PULL 0/9] NBD patches through 2019-09-05

2019-09-05 Thread Eric Blake
n 9/5/19 1:21 PM, Eric Blake wrote:
> The following changes since commit eac2f39602e0423adf56be410c9a22c31fec9a81:
> 
>   target/arm: Inline gen_bx_im into callers (2019-09-05 13:23:04 +0100)
> 
> are available in the Git repository at:
> 
>   https://repo.or.cz/qemu/ericb.git tags/pull-nbd-2019-09-05
> 
> for you to fetch changes up to 73bddca33cb1749ddcbcc1e9972a77d93000553b:
> 
>   nbd: Implement server use of NBD FAST_ZERO (2019-09-05 10:48:46 -0500)
> 

>   nbd: Prepare for NBD_CMD_FLAG_FAST_ZERO
>   nbd: Implement client use of NBD FAST_ZERO
>   nbd: Implement server use of NBD FAST_ZERO

These cause failures in iotests 223 and 233; I'll post a v2 pull request
shortly fixing that.

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



signature.asc
Description: OpenPGP digital signature


Re: [Qemu-devel] [RFC] docs: vhost-user: add in-band kick/call messages

2019-09-05 Thread Johannes Berg
 
> +``VHOST_USER_VQ_CALL``
> +  :id: 34
> +  :equivalent ioctl: N/A
> +  :slave payload: vring state description
> +  :master payload: N/A

Oops. This message should be called VHOST_USER_VRING_KICK.

This file doesn't take about virtqueues, just vrings, and I inverted the
call/kick.

[...]
 
> +``VHOST_USER_VQ_KICK``
> +  :id: 4
> +  :equivalent ioctl: N/A
> +  :slave payload: vring state description
> +  :master payload: N/A

Similarly, that should be called VHOST_USER_SLAVE_VRING_CALL.

Anyway, some comments would be appreciated. I'm working on an
implementation now for my simulation environment, and I guess I can keep
that private etc. but if there's interest I can submit an (optional)
implementation of this for libvhost-user too, I think.

johannes




Re: [Qemu-devel] [RFC 3/3] virtiofsd: add virtiofsctl command-line management tool

2019-09-05 Thread Marc-André Lureau
Hi

On Thu, Sep 5, 2019 at 9:13 PM Dr. David Alan Gilbert
 wrote:
>
> * Stefan Hajnoczi (stefa...@redhat.com) wrote:
> > virtiofsctl can control a running virtiofsd process:
> >
> >   usage: ./virtiofsctl COMMAND [args...]
> >
> >   Commands:
> > get-log-level   - show current log level
> > set-log-level LEVEL - set current log level to one of
> >   "err", "warning", "info", "debug"
> >
> > Make sure it is running in the same DBus session as virtiofsd.  This may
> > require setting the DBUS_SESSION_BUS_ADDRESS environment variable to the
> > same value as used by virtiofsd.
> >
> > Signed-off-by: Stefan Hajnoczi 
> > ---
> >  Makefile|  3 ++
> >  Makefile.objs   |  1 +
> >  contrib/virtiofsd/Makefile.objs |  3 ++
> >  contrib/virtiofsd/virtiofsctl.c | 55 +
> >  4 files changed, 62 insertions(+)
> >  create mode 100644 contrib/virtiofsd/virtiofsctl.c
> >
> > diff --git a/Makefile b/Makefile
> > index 6b1af33348..d7ed9e7669 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -419,6 +419,7 @@ dummy := $(call unnest-vars,, \
> >  ivshmem-client-obj-y \
> >  ivshmem-server-obj-y \
> >  virtiofsd-obj-y \
> > +virtiofsctl-obj-y \
> >  rdmacm-mux-obj-y \
> >  libvhost-user-obj-y \
> >  vhost-user-scsi-obj-y \
> > @@ -661,6 +662,8 @@ contrib/virtiofsd/gdbus_generated.c-timestamp: 
> > $(SRC_PATH)/contrib/virtiofsd/org
> >
> >  virtiofsd$(EXESUF): $(virtiofsd-obj-y) libvhost-user.a $(COMMON_LDADDS)
> >   $(call LINK, $^)
> > +virtiofsctl$(EXESUF): $(virtiofsctl-obj-y)
> > + $(call LINK, $^)
> >  endif
> >
> >  vhost-user-gpu$(EXESUF): $(vhost-user-gpu-obj-y) $(libvhost-user-obj-y) 
> > libqemuutil.a libqemustub.a
> > diff --git a/Makefile.objs b/Makefile.objs
> > index dfdd7d56ea..326a8abb8e 100644
> > --- a/Makefile.objs
> > +++ b/Makefile.objs
> > @@ -126,6 +126,7 @@ rdmacm-mux-obj-y = contrib/rdmacm-mux/
> >  vhost-user-input-obj-y = contrib/vhost-user-input/
> >  vhost-user-gpu-obj-y = contrib/vhost-user-gpu/
> >  virtiofsd-obj-y = contrib/virtiofsd/
> > +virtiofsctl-obj-y = contrib/virtiofsd/
> >
> >  ##
> >  trace-events-subdirs =
> > diff --git a/contrib/virtiofsd/Makefile.objs 
> > b/contrib/virtiofsd/Makefile.objs
> > index d59ab60f3d..3f944d493e 100644
> > --- a/contrib/virtiofsd/Makefile.objs
> > +++ b/contrib/virtiofsd/Makefile.objs
> > @@ -11,6 +11,9 @@ virtiofsd-obj-y = buffer.o \
> >gdbus_generated.o \
> >dbus.o
> >
> > +virtiofsctl-obj-y = virtiofsctl.o \
> > +gdbus_generated.o
> > +
> >  seccomp.o-cflags := $(SECCOMP_CFLAGS)
> >  seccomp.o-libs := $(SECCOMP_LIBS)
> >
> > diff --git a/contrib/virtiofsd/virtiofsctl.c 
> > b/contrib/virtiofsd/virtiofsctl.c
> > new file mode 100644
> > index 00..39bee2b881
> > --- /dev/null
> > +++ b/contrib/virtiofsd/virtiofsctl.c
> > @@ -0,0 +1,55 @@
> > +#include 
> > +#include "gdbus_generated.h"
> > +
> > +static void get_log_level(Virtiofsd *virtiofsd)
> > +{
> > +const char *value = virtiofsd_get_log_level(virtiofsd);
> > +
> > +printf("%s\n", value ? value : "(null)");
> > +}
> > +
> > +static void set_log_level(Virtiofsd *virtiofsd, const char *value)
> > +{
> > +virtiofsd_set_log_level(virtiofsd, value);
> > +}
> > +
> > +static void usage(const char *progname)
> > +{
> > +printf("usage: %s COMMAND [args...]\n", progname);
> > +printf("\n");
> > +printf("Commands:\n");
> > +printf("  get-log-level   - show current log level\n");
> > +printf("  set-log-level LEVEL - set current log level to one of\n");
> > +printf("\"err\", \"warning\", \"info\", 
> > \"debug\"\n");
> > +exit(0);
> > +}
> > +
> > +int main(int argc, char **argv)
> > +{
> > +Virtiofsd *virtiofsd;
> > +GError *error = NULL;
> > +
> > +if (argc < 2) {
> > +usage(argv[0]);
> > +}
> > +
> > +virtiofsd = virtiofsd_proxy_new_for_bus_sync(G_BUS_TYPE_SESSION,
> > +G_DBUS_PROXY_FLAGS_NONE, "org.qemu.virtiofsd",
> > +"/org/qemu/virtiofsd", NULL, &error);
> > +if (error) {
> > +fprintf(stderr, "%s\n", error->message);
> > +g_error_free(error);
> > +return 1;
> > +}
> > +
> > +if (strcmp(argv[0], "get-log-level") == 0) {
>
> This and the one below works a lot better with argv[1] !
>
> (I wonder if a little python script would be better for these type of
> wrappers).

Or just plain gdbus/busctl calls (which already has bash completion
fwiw), and/or eventually a shell script.

>
> Dave
>
> > +get_log_level(virtiofsd);
> > +} else if (strcmp(argv[0], "set-log-level") == 0) {
>
> > +if (argc != 3) {
> > +usage(argv[0]);
> > +}
> > +set_log_level(virtiofs

Re: [Qemu-devel] [PATCH v5 2/3] cpus: Fix throttling during vm_stop

2019-09-05 Thread Eric Blake
On 8/26/19 5:37 AM, Yury Kotov wrote:
> Throttling thread sleeps in VCPU thread. For high throttle percentage
> this sleep is more than 10ms. E.g. for 60% - 15ms, for 99% - 990ms.
> vm_stop() kicks all VCPUs and waits for them. It's called at the end of
> migration and because of the long sleep the migration downtime might be
> more than 100ms even for downtime-limit 1ms.
> Use qemu_cond_timedwait for high percentage to wake up during vm_stop.
> 
> Signed-off-by: Yury Kotov 
> ---
>  cpus.c | 25 +
>  1 file changed, 17 insertions(+), 8 deletions(-)
> 

> @@ -790,11 +792,20 @@ static void cpu_throttle_thread(CPUState *cpu, 
> run_on_cpu_data opaque)
>  
>  pct = (double)cpu_throttle_get_percentage()/100;
>  throttle_ratio = pct / (1 - pct);
> -sleeptime_ns = (long)(throttle_ratio * CPU_THROTTLE_TIMESLICE_NS);
> -
> -qemu_mutex_unlock_iothread();
> -g_usleep(sleeptime_ns / 1000); /* Convert ns to us for usleep call */
> -qemu_mutex_lock_iothread();
> +/* Add 1ns to fix double's rounding error (like 0.999...) */
> +sleeptime_ns = (int64_t)(throttle_ratio * CPU_THROTTLE_TIMESLICE_NS + 1);

The cast to int64_t is not strictly necessary here, but doesn't hurt
(since it shows you DO know you are going from double to 64-bit int).

> +endtime_ns = qemu_clock_get_ns(QEMU_CLOCK_REALTIME) + sleeptime_ns;
> +while (sleeptime_ns > 0 && !cpu->stop) {
> +if (sleeptime_ns > SCALE_MS) {
> +qemu_cond_timedwait(cpu->halt_cond, &qemu_global_mutex,
> +sleeptime_ns / SCALE_MS);
> +} else {
> +qemu_mutex_unlock_iothread();
> +g_usleep(sleeptime_ns / SCALE_US);
> +qemu_mutex_lock_iothread();
> +}
> +sleeptime_ns = endtime_ns - qemu_clock_get_ns(QEMU_CLOCK_REALTIME);
> +}

Looks reasonable.

(I wonder if an alternative approach, of doing a poll() or similar
instead of g_usleep, and using a pipe-to-self where we write to the pipe
in the same scenarios where cpu->halt_cond would be broadcast, in order
to wake up the sleeping poll in a responsive manner, would be any easier
or more efficient - but don't rewrite the patch just because of my question)

Reviewed-by: Eric Blake 

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



Re: [Qemu-devel] [PATCH v5 1/3] qemu-thread: Add qemu_cond_timedwait

2019-09-05 Thread Eric Blake
On 8/26/19 5:37 AM, Yury Kotov wrote:
> Signed-off-by: Yury Kotov 
> ---

Rather sparse on the commit message details.

>  include/qemu/thread.h| 18 ++
>  util/qemu-thread-posix.c | 40 
>  util/qemu-thread-win32.c | 16 
>  util/qsp.c   | 18 ++
>  4 files changed, 80 insertions(+), 12 deletions(-)
> 

> +++ b/util/qemu-thread-posix.c
> @@ -36,6 +36,18 @@ static void error_exit(int err, const char *msg)
>  abort();
>  }
>  
> +static void compute_abs_deadline(struct timespec *ts, int ms)
> +{
> +struct timeval tv;
> +gettimeofday(&tv, NULL);
> +ts->tv_nsec = tv.tv_usec * 1000 + (ms % 1000) * 100;
> +ts->tv_sec = tv.tv_sec + ms / 1000;
> +if (ts->tv_nsec >= 10) {
> +ts->tv_sec++;
> +ts->tv_nsec -= 10;
> +}

I don't know if any named constants would make this easier or harder to
read (such as USEC_PER_SEC 100 or NSEC_PER_SEC 10), but the
conversion from relative ms to absolute timespec looks correct. [1]

> +void qemu_cond_timedwait_impl(QemuCond *cond, QemuMutex *mutex, int ms,
> +  const char *file, const int line)
> +{
> +int err;
> +struct timespec ts;
> +
> +assert(cond->initialized);
> +trace_qemu_mutex_unlock(mutex, file, line);
> +compute_abs_deadline(&ts, ms);
> +err = pthread_cond_timedwait(&cond->cond, &mutex->lock, &ts);
> +trace_qemu_mutex_locked(mutex, file, line);
> +if (err && err != ETIMEDOUT) {
> +error_exit(err, __func__);
> +}
> +}

However, this function returning void looks odd.  Although ETIMEDOUT is
the one error that guarantees that mutex is reobtained (all other errors
occur before the mutex is given up in the first place), and even though
the man page warns that you MUST recheck the condition variable in a
while loop regardless of success or failure (it might be a spurious
successful wake-up due to a broadcast where neither the condition nor
the timeout has actually been reached yet; or it might be a race where
the function reports a timeout immediately before the condition variable
became available after all), it still seems like callers might like to
know if a timeout happened, without having to calculate an ending
absolute time themselves.


>  
> -static void compute_abs_deadline(struct timespec *ts, int ms)
> -{
> -struct timeval tv;

[1] Oh, you mixed code motion with new code, but the commit message
didn't mention that.  It's not necessarily worth splitting the patch,
but at least mentioning it would be worthwhile.

> +++ b/util/qemu-thread-win32.c
> @@ -145,6 +145,22 @@ void qemu_cond_wait_impl(QemuCond *cond, QemuMutex 
> *mutex, const char *file, con
>  qemu_mutex_post_lock(mutex, file, line);
>  }
>  
> +void qemu_cond_timedwait_impl(QemuCond *cond, QemuMutex *mutex, int ms,
> +  const char *file, const int line)
> +{
> +int rc = 0;
> +
> +assert(cond->initialized);
> +trace_qemu_mutex_unlock(mutex, file, line);
> +if (!SleepConditionVariableSRW(&cond->var, &mutex->lock, ms, 0)) {
> +rc = GetLastError();
> +}
> +trace_qemu_mutex_locked(mutex, file, line);
> +if (rc && rc != ERROR_TIMEOUT) {
> +error_exit(rc, __func__);
> +}
> +}

I am less certain that this implementation is correct, but on the
surface it seems okay.


>  
> +static void
> +qsp_cond_timedwait(QemuCond *cond, QemuMutex *mutex, int ms,
> +   const char *file, int line)
> +{
> +QSPEntry *e;
> +int64_t t0, t1;
> +
> +t0 = get_clock();
> +qemu_cond_timedwait_impl(cond, mutex, ms, file, line);
> +t1 = get_clock();
> +
> +e = qsp_entry_get(cond, file, line, QSP_CONDVAR);
> +qsp_entry_record(e, t1 - t0);
> +}

Another function where a bool or int return (to distinguish success from
timeout) might be worthwhile to some callers.

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



Re: [Qemu-devel] [PATCH v2] riscv: sifive_test: Add reset functionality

2019-09-05 Thread Palmer Dabbelt

On Thu, 05 Sep 2019 08:57:44 PDT (-0700), bmeng...@gmail.com wrote:

Hi Palmer,

On Thu, Sep 5, 2019 at 11:55 PM Bin Meng  wrote:


This adds a reset opcode for sifive_test device to trigger a system
reset for testing purpose.

Signed-off-by: Bin Meng 
Reviewed-by: Palmer Dabbelt 

---

Changes in v2:
- fix build error in the "for-master" branch of Palmer's RISC-V repo
  that was rebased on QEMU master

 hw/riscv/sifive_test.c | 4 
 include/hw/riscv/sifive_test.h | 3 ++-
 2 files changed, 6 insertions(+), 1 deletion(-)



Please drop the already applied v1 patch in your "for-master" branch
and apply this v2.

After you rebased the "for-master' branch, this patch no longer build
any more due to changes in QEMU master.

Regards,
Bin


Thanks!



Re: [Qemu-devel] [PATCH v7 00/30] riscv: sifive_u: Improve the emulation fidelity of sifive_u machine

2019-09-05 Thread Palmer Dabbelt

On Thu, 05 Sep 2019 08:25:46 PDT (-0700), bmeng...@gmail.com wrote:

Hi Alistair,

On Thu, Sep 5, 2019 at 3:50 AM Alistair Francis  wrote:


On Sat, Aug 31, 2019 at 7:54 PM Bin Meng  wrote:
>
> As of today, the QEMU 'sifive_u' machine is a special target that does
> not boot the upstream OpenSBI/U-Boot firmware images built for the real
> SiFive HiFive Unleashed board. Hence OpenSBI supports a special platform
> "qemu/sifive_u". For U-Boot, the sifive_fu540_defconfig is referenced
> in the OpenSBI doc as its payload, but that does not boot at all due
> to various issues in current QEMU 'sifive_u' machine codes.
>
> This series aims to improve the emulation fidelity of sifive_u machine,
> so that the upstream OpenSBI, U-Boot and kernel images built for the
> SiFive HiFive Unleashed board can be used out of the box without any
> special hack.
>
> The major changes include:
> - Heterogeneous harts creation supported, so that we can create a CPU
>   that exactly mirrors the real hardware: 1 E51 + 4 U54.
> - Implemented a PRCI model for FU540
> - Implemented an OTP model for FU540, primarily used for storing serial
>   number of the board
> - Fixed GEM support that was seriously broken on sifive_u
> - Synced device tree with upstream Linux kernel on sifive_u
>
> OpenSBI v0.4 image built for sifive/fu540 is included as the default
> bios image for 'sifive_u' machine.
>
> The series is tested against OpenSBI v0.4 image for sifive/fu540
> paltform, U-Boot v2019.10-rc1 image for sifive_fu540_defconfig,
> and Linux kernel v5.3-rc3 image with the following patch:
>
> macb: Update compatibility string for SiFive FU540-C000 [1]
>
> OpenSBI + U-Boot, ping/tftpboot with U-Boot MACB driver works well.
> Boot Linux 64-bit defconfig image, verified that system console on
> the serial 0 and ping host work pretty well.
>
> An OpenSBI patch [2] was sent to drop the special "qemu/sifive_u" platform
> support in OpenSBI. The original plan was to get the drop patch applied
> after this QEMU series is merged. However after discussion in the OpenSBI
> mailing list, it seems the best option for us is to let OpenSBI continue
> shipping the special "qemu/sifive_u" platform support to work with QEMU
> version <= 4.1 and deprecate the support sometime in the future. A patch
> will need to be sent to OpenSBI mailing list to update its document.
>
> v4 is now rebased on Palmer's QEMU RISC-V repo "for-master" branch.
> Dropped the following v3 patch that was already done by someone else.
> - riscv: sifive_u: Generate an aliases node in the device tree
> - riscv: sifive_u: Support loading initramfs

I'm having trouble applying this. Do you mind sharing a public git branch?


So I see Palmer has rebased his "for-master" branch against QEMU
master and now this patch series cannot be applied cleanly.

Even worse, the current "for-master" branch has build errors for QEMU RISC-V.


Sorry, I haven't gotten around to fixing up the patch queue for now.  It's 
always OK to just send stuff against Peter's master, particularly if it's a big 
patch set like this, as that's more likely to be a stable base for testing.




Re: [Qemu-devel] [PATCH v1 02/42] configure: clean-up container cross compile detect

2019-09-05 Thread David Hildenbrand
On 05.09.19 20:35, Alex Bennée wrote:
> 
> David Hildenbrand  writes:
> 
>> On 04.09.19 22:29, Alex Bennée wrote:
>>> The introduction of podman support inadvertently broke configure's
>>> detect of the container support as the configure probe didn't specify
>>> an engine type. To fix this in docker.py:
>>>
>>>   - only (re)set USE_ENGINE if --engine is specified
>>>   - enhance the output so docker is no longer just yes
>>>
>>> In the configure script we can at least start cleaning up the
>>> detecting and naming of variables. To avoid too much churn the
>>> conversion of the various make DOCKER_foo variables has been left for
>>> future clean-ups.
>>
>> This is not only a "clean-up" but an actual fix :) (maybe add a Fixes:
>> tag).
> 
> Done... do I get a Tested-by: ?

Most certainly, you saved me quite some time today:

Tested-by: David Hildenbrand 

Thanks!

-- 

Thanks,

David / dhildenb



Re: [Qemu-devel] [PATCH v1 02/42] configure: clean-up container cross compile detect

2019-09-05 Thread Alex Bennée


David Hildenbrand  writes:

> On 04.09.19 22:29, Alex Bennée wrote:
>> The introduction of podman support inadvertently broke configure's
>> detect of the container support as the configure probe didn't specify
>> an engine type. To fix this in docker.py:
>>
>>   - only (re)set USE_ENGINE if --engine is specified
>>   - enhance the output so docker is no longer just yes
>>
>> In the configure script we can at least start cleaning up the
>> detecting and naming of variables. To avoid too much churn the
>> conversion of the various make DOCKER_foo variables has been left for
>> future clean-ups.
>
> This is not only a "clean-up" but an actual fix :) (maybe add a Fixes:
> tag).

Done... do I get a Tested-by: ?

>
> This makes it work again for me.
>
> t460s: ~/git/qemu mvc $ tests/docker/docker.py probe
> docker
>
> Thanks!
>
>>
>> Signed-off-by: Alex Bennée 
>> ---
>>  configure  | 10 +-
>>  tests/docker/docker.py |  7 ---
>>  2 files changed, 9 insertions(+), 8 deletions(-)
>>
>> diff --git a/configure b/configure
>> index 95134c0180b..94845fc5101 100755
>> --- a/configure
>> +++ b/configure
>> @@ -495,7 +495,7 @@ qed="yes"
>>  parallels="yes"
>>  sheepdog="yes"
>>  libxml2=""
>> -docker="no"
>> +container="no"
>>  debug_mutex="no"
>>  libpmem=""
>>  default_devices="yes"
>> @@ -5894,14 +5894,14 @@ EOF
>>  fi
>>
>>  ##
>> -# Docker and cross-compiler support
>> +# Container based cross-compiler support
>>  #
>>  # This is specifically for building test
>>  # cases for foreign architectures, not
>>  # cross-compiling QEMU itself.
>>
>> -if has "docker"; then
>> -docker=$($python $source_path/tests/docker/docker.py probe)
>> +if has "docker" || has "podman"; then
>> +container=$($python $source_path/tests/docker/docker.py probe)
>>  fi
>>
>>  ##
>> @@ -6474,7 +6474,7 @@ echo "qed support   $qed"
>>  echo "parallels support $parallels"
>>  echo "sheepdog support  $sheepdog"
>>  echo "capstone  $capstone"
>> -echo "docker$docker"
>> +echo "container support $container"
>>  echo "libpmem support   $libpmem"
>>  echo "libudev   $libudev"
>>  echo "default devices   $default_devices"
>> diff --git a/tests/docker/docker.py b/tests/docker/docker.py
>> index 4bba29e104e..e23209f71ee 100755
>> --- a/tests/docker/docker.py
>> +++ b/tests/docker/docker.py
>> @@ -536,9 +536,9 @@ class ProbeCommand(SubCommand):
>>  try:
>>  docker = Docker()
>>  if docker._command[0] == "docker":
>> -print("yes")
>> +print("docker")
>>  elif docker._command[0] == "sudo":
>> -print("sudo")
>> +print("sudo docker")
>>  elif docker._command[0] == "podman":
>>  print("podman")
>>  except Exception:
>> @@ -651,7 +651,8 @@ def main():
>>  cmd.args(subp)
>>  subp.set_defaults(cmdobj=cmd)
>>  args, argv = parser.parse_known_args()
>> -USE_ENGINE = args.engine
>> +if args.engine:
>> +USE_ENGINE = args.engine
>>  return args.cmdobj.run(args, argv)
>>
>>
>>


--
Alex Bennée



[Qemu-devel] [PULL 6/9] nbd: Improve per-export flag handling in server

2019-09-05 Thread Eric Blake
When creating a read-only image, we are still advertising support for
TRIM and WRITE_ZEROES to the client, even though the client should not
be issuing those commands.  But seeing this requires looking across
multiple functions:

All callers to nbd_export_new() passed a single flag based solely on
whether the export allows writes.  Later, we then pass a constant set
of flags to nbd_negotiate_options() (namely, the set of flags which we
always support, at least for writable images), which is then further
dynamically modified with NBD_FLAG_SEND_DF based on client requests
for structured options.  Finally, when processing NBD_OPT_EXPORT_NAME
or NBD_OPT_EXPORT_GO we bitwise-or the original caller's flag with the
runtime set of flags we've built up over several functions.

Let's refactor things to instead compute a baseline of flags as soon
as possible which gets shared between multiple clients, in
nbd_export_new(), and changing the signature for the callers to pass
in a simpler bool rather than having to figure out flags.  We can then
get rid of the 'myflags' parameter to various functions, and instead
refer to client for everything we need (we still have to perform a
bitwise-OR for NBD_FLAG_SEND_DF during NBD_OPT_EXPORT_NAME and
NBD_OPT_EXPORT_GO, but it's easier to see what is being computed).
This lets us quit advertising senseless flags for read-only images, as
well as making the next patch for exposing FAST_ZERO support easier to
write.

Signed-off-by: Eric Blake 
Message-Id: <20190823143726.27062-2-ebl...@redhat.com>
[eblake: improve commit message]
Reviewed-by: Vladimir Sementsov-Ogievskiy 
---
 include/block/nbd.h |  2 +-
 blockdev-nbd.c  |  3 +--
 nbd/server.c| 62 +
 qemu-nbd.c  |  6 ++---
 4 files changed, 39 insertions(+), 34 deletions(-)

diff --git a/include/block/nbd.h b/include/block/nbd.h
index 991fd52a5134..2c87b42dfd48 100644
--- a/include/block/nbd.h
+++ b/include/block/nbd.h
@@ -326,7 +326,7 @@ typedef struct NBDClient NBDClient;

 NBDExport *nbd_export_new(BlockDriverState *bs, uint64_t dev_offset,
   uint64_t size, const char *name, const char *desc,
-  const char *bitmap, uint16_t nbdflags, bool shared,
+  const char *bitmap, bool readonly, bool shared,
   void (*close)(NBDExport *), bool writethrough,
   BlockBackend *on_eject_blk, Error **errp);
 void nbd_export_close(NBDExport *exp);
diff --git a/blockdev-nbd.c b/blockdev-nbd.c
index 1fcfdb0997c6..213f226ac1c4 100644
--- a/blockdev-nbd.c
+++ b/blockdev-nbd.c
@@ -187,8 +187,7 @@ void qmp_nbd_server_add(const char *device, bool has_name, 
const char *name,
 writable = false;
 }

-exp = nbd_export_new(bs, 0, len, name, NULL, bitmap,
- writable ? 0 : NBD_FLAG_READ_ONLY, !writable,
+exp = nbd_export_new(bs, 0, len, name, NULL, bitmap, !writable, !writable,
  NULL, false, on_eject_blk, errp);
 if (!exp) {
 return;
diff --git a/nbd/server.c b/nbd/server.c
index 74d205812fee..d5078f7468af 100644
--- a/nbd/server.c
+++ b/nbd/server.c
@@ -419,14 +419,14 @@ static void nbd_check_meta_export(NBDClient *client)

 /* Send a reply to NBD_OPT_EXPORT_NAME.
  * Return -errno on error, 0 on success. */
-static int nbd_negotiate_handle_export_name(NBDClient *client,
-uint16_t myflags, bool no_zeroes,
+static int nbd_negotiate_handle_export_name(NBDClient *client, bool no_zeroes,
 Error **errp)
 {
 char name[NBD_MAX_NAME_SIZE + 1];
 char buf[NBD_REPLY_EXPORT_NAME_SIZE] = "";
 size_t len;
 int ret;
+uint16_t myflags;

 /* Client sends:
 [20 ..  xx]   export name (length bytes)
@@ -454,10 +454,13 @@ static int nbd_negotiate_handle_export_name(NBDClient 
*client,
 return -EINVAL;
 }

-trace_nbd_negotiate_new_style_size_flags(client->exp->size,
- client->exp->nbdflags | myflags);
+myflags = client->exp->nbdflags;
+if (client->structured_reply) {
+myflags |= NBD_FLAG_SEND_DF;
+}
+trace_nbd_negotiate_new_style_size_flags(client->exp->size, myflags);
 stq_be_p(buf, client->exp->size);
-stw_be_p(buf + 8, client->exp->nbdflags | myflags);
+stw_be_p(buf + 8, myflags);
 len = no_zeroes ? 10 : sizeof(buf);
 ret = nbd_write(client->ioc, buf, len, errp);
 if (ret < 0) {
@@ -522,8 +525,7 @@ static int nbd_reject_length(NBDClient *client, bool fatal, 
Error **errp)
 /* Handle NBD_OPT_INFO and NBD_OPT_GO.
  * Return -errno on error, 0 if ready for next option, and 1 to move
  * into transmission phase.  */
-static int nbd_negotiate_handle_info(NBDClient *client, uint16_t myflags,
- Error **errp)
+static int nbd_negotiate_handle_info(NBDClient *client, Er

[Qemu-devel] [PULL 9/9] nbd: Implement server use of NBD FAST_ZERO

2019-09-05 Thread Eric Blake
The server side is fairly straightforward: we can always advertise
support for detection of fast zero, and implement it by mapping the
request to the block layer BDRV_REQ_NO_FALLBACK.

Signed-off-by: Eric Blake 
Message-Id: <20190823143726.27062-5-ebl...@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy 
---
 nbd/server.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/nbd/server.c b/nbd/server.c
index 4992148de1c4..28c3c8be854c 100644
--- a/nbd/server.c
+++ b/nbd/server.c
@@ -1513,7 +1513,8 @@ NBDExport *nbd_export_new(BlockDriverState *bs, uint64_t 
dev_offset,
 exp->nbdflags |= NBD_FLAG_CAN_MULTI_CONN;
 }
 } else {
-exp->nbdflags |= NBD_FLAG_SEND_TRIM | NBD_FLAG_SEND_WRITE_ZEROES;
+exp->nbdflags |= (NBD_FLAG_SEND_TRIM | NBD_FLAG_SEND_WRITE_ZEROES |
+  NBD_FLAG_SEND_FAST_ZERO);
 }
 assert(size <= INT64_MAX - dev_offset);
 exp->size = QEMU_ALIGN_DOWN(size, BDRV_SECTOR_SIZE);
@@ -2166,7 +2167,7 @@ static int nbd_co_receive_request(NBDRequestData *req, 
NBDRequest *request,
 if (request->type == NBD_CMD_READ && client->structured_reply) {
 valid_flags |= NBD_CMD_FLAG_DF;
 } else if (request->type == NBD_CMD_WRITE_ZEROES) {
-valid_flags |= NBD_CMD_FLAG_NO_HOLE;
+valid_flags |= NBD_CMD_FLAG_NO_HOLE | NBD_CMD_FLAG_FAST_ZERO;
 } else if (request->type == NBD_CMD_BLOCK_STATUS) {
 valid_flags |= NBD_CMD_FLAG_REQ_ONE;
 }
@@ -2305,6 +2306,9 @@ static coroutine_fn int nbd_handle_request(NBDClient 
*client,
 if (!(request->flags & NBD_CMD_FLAG_NO_HOLE)) {
 flags |= BDRV_REQ_MAY_UNMAP;
 }
+if (request->flags & NBD_CMD_FLAG_FAST_ZERO) {
+flags |= BDRV_REQ_NO_FALLBACK;
+}
 ret = blk_pwrite_zeroes(exp->blk, request->from + exp->dev_offset,
 request->len, flags);
 return nbd_send_generic_reply(client, request->handle, ret,
-- 
2.21.0




[Qemu-devel] [PULL 7/9] nbd: Prepare for NBD_CMD_FLAG_FAST_ZERO

2019-09-05 Thread Eric Blake
Commit fe0480d6 and friends added BDRV_REQ_NO_FALLBACK as a way to
avoid wasting time on a preliminary write-zero request that will later
be rewritten by actual data, if it is known that the write-zero
request will use a slow fallback; but in doing so, could not optimize
for NBD.  The NBD specification is now considering an extension that
will allow passing on those semantics; this patch updates the new
protocol bits and 'qemu-nbd --list' output to recognize the bit, as
well as the new errno value possible when using the new flag; while
upcoming patches will improve the client to use the feature when
present, and the server to advertise support for it.

The NBD spec recommends (but not requires) that ENOTSUP be avoided for
all but failures of a fast zero (the only time it is mandatory to
avoid an ENOTSUP failure is when fast zero is supported but not
requested during write zeroes; the questionable use is for ENOTSUP to
other actions like a normal write request).  However, clients that get
an unexpected ENOTSUP will either already be treating it the same as
EINVAL, or may appreciate the extra bit of information.  We were
equally loose for returning EOVERFLOW in more situations than
recommended by the spec, so if it turns out to be a problem in
practice, a later patch can tighten handling for both error codes.

Signed-off-by: Eric Blake 
Message-Id: <20190823143726.27062-3-ebl...@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy 
[eblake: tweak commit message, also handle EOPNOTSUPP]
---
 docs/interop/nbd.txt | 3 ++-
 include/block/nbd.h  | 4 
 nbd/common.c | 5 +
 nbd/server.c | 5 +
 qemu-nbd.c   | 1 +
 5 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/docs/interop/nbd.txt b/docs/interop/nbd.txt
index 6dfec7f47647..45118809618e 100644
--- a/docs/interop/nbd.txt
+++ b/docs/interop/nbd.txt
@@ -53,4 +53,5 @@ the operation of that feature.
 * 2.12: NBD_CMD_BLOCK_STATUS for "base:allocation"
 * 3.0: NBD_OPT_STARTTLS with TLS Pre-Shared Keys (PSK),
 NBD_CMD_BLOCK_STATUS for "qemu:dirty-bitmap:", NBD_CMD_CACHE
-* 4.2: NBD_FLAG_CAN_MULTI_CONN for sharable read-only exports
+* 4.2: NBD_FLAG_CAN_MULTI_CONN for sharable read-only exports,
+NBD_CMD_FLAG_FAST_ZERO
diff --git a/include/block/nbd.h b/include/block/nbd.h
index 2c87b42dfd48..21550747cf35 100644
--- a/include/block/nbd.h
+++ b/include/block/nbd.h
@@ -140,6 +140,7 @@ enum {
 NBD_FLAG_CAN_MULTI_CONN_BIT =  8, /* Multi-client cache consistent */
 NBD_FLAG_SEND_RESIZE_BIT=  9, /* Send resize */
 NBD_FLAG_SEND_CACHE_BIT = 10, /* Send CACHE (prefetch) */
+NBD_FLAG_SEND_FAST_ZERO_BIT = 11, /* FAST_ZERO flag for WRITE_ZEROES */
 };

 #define NBD_FLAG_HAS_FLAGS (1 << NBD_FLAG_HAS_FLAGS_BIT)
@@ -153,6 +154,7 @@ enum {
 #define NBD_FLAG_CAN_MULTI_CONN(1 << NBD_FLAG_CAN_MULTI_CONN_BIT)
 #define NBD_FLAG_SEND_RESIZE   (1 << NBD_FLAG_SEND_RESIZE_BIT)
 #define NBD_FLAG_SEND_CACHE(1 << NBD_FLAG_SEND_CACHE_BIT)
+#define NBD_FLAG_SEND_FAST_ZERO(1 << NBD_FLAG_SEND_FAST_ZERO_BIT)

 /* New-style handshake (global) flags, sent from server to client, and
control what will happen during handshake phase. */
@@ -205,6 +207,7 @@ enum {
 #define NBD_CMD_FLAG_DF (1 << 2) /* don't fragment structured read */
 #define NBD_CMD_FLAG_REQ_ONE(1 << 3) /* only one extent in BLOCK_STATUS
   * reply chunk */
+#define NBD_CMD_FLAG_FAST_ZERO  (1 << 4) /* fail if WRITE_ZEROES is not fast */

 /* Supported request types */
 enum {
@@ -270,6 +273,7 @@ static inline bool nbd_reply_type_is_error(int type)
 #define NBD_EINVAL 22
 #define NBD_ENOSPC 28
 #define NBD_EOVERFLOW  75
+#define NBD_ENOTSUP95
 #define NBD_ESHUTDOWN  108

 /* Details collected by NBD_OPT_EXPORT_NAME and NBD_OPT_GO */
diff --git a/nbd/common.c b/nbd/common.c
index cc8b278e541d..ddfe7d118371 100644
--- a/nbd/common.c
+++ b/nbd/common.c
@@ -201,6 +201,8 @@ const char *nbd_err_lookup(int err)
 return "ENOSPC";
 case NBD_EOVERFLOW:
 return "EOVERFLOW";
+case NBD_ENOTSUP:
+return "ENOTSUP";
 case NBD_ESHUTDOWN:
 return "ESHUTDOWN";
 default:
@@ -231,6 +233,9 @@ int nbd_errno_to_system_errno(int err)
 case NBD_EOVERFLOW:
 ret = EOVERFLOW;
 break;
+case NBD_ENOTSUP:
+ret = ENOTSUP;
+break;
 case NBD_ESHUTDOWN:
 ret = ESHUTDOWN;
 break;
diff --git a/nbd/server.c b/nbd/server.c
index d5078f7468af..4992148de1c4 100644
--- a/nbd/server.c
+++ b/nbd/server.c
@@ -55,6 +55,11 @@ static int system_errno_to_nbd_errno(int err)
 return NBD_ENOSPC;
 case EOVERFLOW:
 return NBD_EOVERFLOW;
+case ENOTSUP:
+#if ENOTSUP != EOPNOTSUPP
+case EOPNOTSUPP:
+#endif
+return NBD_ENOTSUP;
 case ESHUTDOWN:
 return NBD_ESHUTDOWN;
 case EINVAL:
diff --git a/qemu-nbd.c b/qemu-nbd.c
index ae841150760e..9032b6de2ace 100644
--- a/

[Qemu-devel] [PULL 5/9] docs: Update preferred NBD device syntax

2019-09-05 Thread Eric Blake
Mention the preferred URI form, especially since NBD is trying to
standardize that form: https://lists.debian.org/nbd/2019/06/msg00012.html

Signed-off-by: Eric Blake 
Message-Id: <20190903145634.20237-1-ebl...@redhat.com>
Reviewed-by: John Snow 
---
 qemu-doc.texi | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/qemu-doc.texi b/qemu-doc.texi
index 577d1e837640..ec460f1d7af5 100644
--- a/qemu-doc.texi
+++ b/qemu-doc.texi
@@ -297,9 +297,16 @@ qemu-system-i386 -drive 
file=iscsi://192.0.2.1/iqn.2001-04.com.example/1

 @item NBD
 QEMU supports NBD (Network Block Devices) both using TCP protocol as well
-as Unix Domain Sockets.
+as Unix Domain Sockets.  With TCP, the default port is 10809.

-Syntax for specifying a NBD device using TCP
+Syntax for specifying a NBD device using TCP, in preferred URI form:
+``nbd://[:]/[]''
+
+Syntax for specifying a NBD device using Unix Domain Sockets; remember
+that '?' is a shell glob character and may need quoting:
+``nbd+unix:///[]?socket=''
+
+Older syntax that is also recognized:
 ``nbd::[:exportname=]''

 Syntax for specifying a NBD device using Unix Domain Sockets
-- 
2.21.0




[Qemu-devel] [PULL 8/9] nbd: Implement client use of NBD FAST_ZERO

2019-09-05 Thread Eric Blake
The client side is fairly straightforward: if the server advertised
fast zero support, then we can map that to BDRV_REQ_NO_FALLBACK
support.  A server that advertises FAST_ZERO but not WRITE_ZEROES
is technically broken, but we can ignore that situation as it does
not change our behavior.

Signed-off-by: Eric Blake 
Message-Id: <20190823143726.27062-4-ebl...@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy 
---
 block/nbd.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/block/nbd.c b/block/nbd.c
index c4c91a158602..813c40d8f067 100644
--- a/block/nbd.c
+++ b/block/nbd.c
@@ -1044,6 +1044,10 @@ static int nbd_client_co_pwrite_zeroes(BlockDriverState 
*bs, int64_t offset,
 if (!(flags & BDRV_REQ_MAY_UNMAP)) {
 request.flags |= NBD_CMD_FLAG_NO_HOLE;
 }
+if (flags & BDRV_REQ_NO_FALLBACK) {
+assert(s->info.flags & NBD_FLAG_SEND_FAST_ZERO);
+request.flags |= NBD_CMD_FLAG_FAST_ZERO;
+}

 if (!bytes) {
 return 0;
@@ -1239,6 +1243,9 @@ static int nbd_client_connect(BlockDriverState *bs, Error 
**errp)
 }
 if (s->info.flags & NBD_FLAG_SEND_WRITE_ZEROES) {
 bs->supported_zero_flags |= BDRV_REQ_MAY_UNMAP;
+if (s->info.flags & NBD_FLAG_SEND_FAST_ZERO) {
+bs->supported_zero_flags |= BDRV_REQ_NO_FALLBACK;
+}
 }

 s->sioc = sioc;
-- 
2.21.0




[Qemu-devel] [PULL 2/9] nbd: Use g_autofree in a few places

2019-09-05 Thread Eric Blake
Thanks to our recent move to use glib's g_autofree, I can join the
bandwagon.  Getting rid of gotos is fun ;)

There are probably more places where we could register cleanup
functions and get rid of more gotos; this patch just focuses on the
labels that existed merely to call g_free.

Signed-off-by: Eric Blake 
Message-Id: <20190824172813.29720-2-ebl...@redhat.com>
Reviewed-by: Daniel P. Berrangé 
Reviewed-by: Vladimir Sementsov-Ogievskiy 
---
 block/nbd.c  | 11 ---
 nbd/client.c | 22 +++---
 nbd/server.c | 12 
 3 files changed, 15 insertions(+), 30 deletions(-)

diff --git a/block/nbd.c b/block/nbd.c
index beed46fb3414..c4c91a158602 100644
--- a/block/nbd.c
+++ b/block/nbd.c
@@ -1374,7 +1374,7 @@ static bool nbd_has_filename_options_conflict(QDict 
*options, Error **errp)
 static void nbd_parse_filename(const char *filename, QDict *options,
Error **errp)
 {
-char *file;
+g_autofree char *file = NULL;
 char *export_name;
 const char *host_spec;
 const char *unixpath;
@@ -1396,7 +1396,7 @@ static void nbd_parse_filename(const char *filename, 
QDict *options,
 export_name = strstr(file, EN_OPTSTR);
 if (export_name) {
 if (export_name[strlen(EN_OPTSTR)] == 0) {
-goto out;
+return;
 }
 export_name[0] = 0; /* truncate 'file' */
 export_name += strlen(EN_OPTSTR);
@@ -1407,11 +1407,11 @@ static void nbd_parse_filename(const char *filename, 
QDict *options,
 /* extract the host_spec - fail if it's not nbd:... */
 if (!strstart(file, "nbd:", &host_spec)) {
 error_setg(errp, "File name string for NBD must start with 'nbd:'");
-goto out;
+return;
 }

 if (!*host_spec) {
-goto out;
+return;
 }

 /* are we a UNIX or TCP socket? */
@@ -1431,9 +1431,6 @@ static void nbd_parse_filename(const char *filename, 
QDict *options,
 out_inet:
 qapi_free_InetSocketAddress(addr);
 }
-
-out:
-g_free(file);
 }

 static bool nbd_process_legacy_socket_options(QDict *output_options,
diff --git a/nbd/client.c b/nbd/client.c
index 49bf9906f94b..a9d8d32feff7 100644
--- a/nbd/client.c
+++ b/nbd/client.c
@@ -247,12 +247,11 @@ static int nbd_handle_reply_err(QIOChannel *ioc, 
NBDOptionReply *reply,
 static int nbd_receive_list(QIOChannel *ioc, char **name, char **description,
 Error **errp)
 {
-int ret = -1;
 NBDOptionReply reply;
 uint32_t len;
 uint32_t namelen;
-char *local_name = NULL;
-char *local_desc = NULL;
+g_autofree char *local_name = NULL;
+g_autofree char *local_desc = NULL;
 int error;

 if (nbd_receive_option_reply(ioc, NBD_OPT_LIST, &reply, errp) < 0) {
@@ -298,7 +297,7 @@ static int nbd_receive_list(QIOChannel *ioc, char **name, 
char **description,
 local_name = g_malloc(namelen + 1);
 if (nbd_read(ioc, local_name, namelen, "export name", errp) < 0) {
 nbd_send_opt_abort(ioc);
-goto out;
+return -1;
 }
 local_name[namelen] = '\0';
 len -= namelen;
@@ -306,24 +305,17 @@ static int nbd_receive_list(QIOChannel *ioc, char **name, 
char **description,
 local_desc = g_malloc(len + 1);
 if (nbd_read(ioc, local_desc, len, "export description", errp) < 0) {
 nbd_send_opt_abort(ioc);
-goto out;
+return -1;
 }
 local_desc[len] = '\0';
 }

 trace_nbd_receive_list(local_name, local_desc ?: "");
-*name = local_name;
-local_name = NULL;
+*name = g_steal_pointer(&local_name);
 if (description) {
-*description = local_desc;
-local_desc = NULL;
+*description = g_steal_pointer(&local_desc);
 }
-ret = 1;
-
- out:
-g_free(local_name);
-g_free(local_desc);
-return ret;
+return 1;
 }


diff --git a/nbd/server.c b/nbd/server.c
index 0fb41c6c50ea..74d205812fee 100644
--- a/nbd/server.c
+++ b/nbd/server.c
@@ -206,7 +206,7 @@ static int GCC_FMT_ATTR(4, 0)
 nbd_negotiate_send_rep_verr(NBDClient *client, uint32_t type,
 Error **errp, const char *fmt, va_list va)
 {
-char *msg;
+g_autofree char *msg = NULL;
 int ret;
 size_t len;

@@ -216,18 +216,14 @@ nbd_negotiate_send_rep_verr(NBDClient *client, uint32_t 
type,
 trace_nbd_negotiate_send_rep_err(msg);
 ret = nbd_negotiate_send_rep_len(client, type, len, errp);
 if (ret < 0) {
-goto out;
+return ret;
 }
 if (nbd_write(client->ioc, msg, len, errp) < 0) {
 error_prepend(errp, "write failed (error message): ");
-ret = -EIO;
-} else {
-ret = 0;
+return -EIO;
 }

-out:
-g_free(msg);
-return ret;
+return 0;
 }

 /* Send an error reply.
-- 
2.21.0




[Qemu-devel] [PULL 4/9] block: workaround for unaligned byte range in fallocate()

2019-09-05 Thread Eric Blake
From: Andrey Shinkevich 

Revert the commit 118f99442d 'block/io.c: fix for the allocation failure'
and use better error handling for file systems that do not support
fallocate() for an unaligned byte range. Allow falling back to pwrite
in case fallocate() returns EINVAL.

Suggested-by: Kevin Wolf 
Suggested-by: Eric Blake 
Signed-off-by: Andrey Shinkevich 
Reviewed-by: Eric Blake 
Reviewed-by: Denis V. Lunev 
Message-Id: <1566913973-15490-1-git-send-email-andrey.shinkev...@virtuozzo.com>
Signed-off-by: Eric Blake 
---
 block/io.c | 2 +-
 block/file-posix.c | 7 +++
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/block/io.c b/block/io.c
index 0fa10831edb7..16a598fd0857 100644
--- a/block/io.c
+++ b/block/io.c
@@ -1746,7 +1746,7 @@ static int coroutine_fn 
bdrv_co_do_pwrite_zeroes(BlockDriverState *bs,
 assert(!bs->supported_zero_flags);
 }

-if (ret < 0 && !(flags & BDRV_REQ_NO_FALLBACK)) {
+if (ret == -ENOTSUP && !(flags & BDRV_REQ_NO_FALLBACK)) {
 /* Fall back to bounce buffer if write zeroes is unsupported */
 BdrvRequestFlags write_flags = flags & ~BDRV_REQ_ZERO_WRITE;

diff --git a/block/file-posix.c b/block/file-posix.c
index 71f168ee2f13..87c5a4ccbdc8 100644
--- a/block/file-posix.c
+++ b/block/file-posix.c
@@ -1588,6 +1588,13 @@ static int handle_aiocb_write_zeroes(void *opaque)
 if (s->has_write_zeroes) {
 int ret = do_fallocate(s->fd, FALLOC_FL_ZERO_RANGE,
aiocb->aio_offset, aiocb->aio_nbytes);
+if (ret == -EINVAL) {
+/*
+ * Allow falling back to pwrite for file systems that
+ * do not support fallocate() for an unaligned byte range.
+ */
+return -ENOTSUP;
+}
 if (ret == 0 || ret != -ENOTSUP) {
 return ret;
 }
-- 
2.21.0




[Qemu-devel] [PULL 3/9] nbd: Tolerate more errors to structured reply request

2019-09-05 Thread Eric Blake
A server may have a reason to reject a request for structured replies,
beyond just not recognizing them as a valid request; similarly, it may
have a reason for rejecting a request for a meta context.  It doesn't
hurt us to continue talking to such a server; otherwise 'qemu-nbd
--list' of such a server fails to display all available details about
the export.

Encountered when temporarily tweaking nbdkit to reply with
NBD_REP_ERR_POLICY.  Present since structured reply support was first
added (commit d795299b reused starttls handling, but starttls is
different in that we can't fall back to other behavior on any error).

Signed-off-by: Eric Blake 
Message-Id: <20190824172813.29720-3-ebl...@redhat.com>
Reviewed-by: Daniel P. Berrangé 
---
 nbd/client.c | 63 +---
 nbd/trace-events |  2 +-
 2 files changed, 34 insertions(+), 31 deletions(-)

diff --git a/nbd/client.c b/nbd/client.c
index a9d8d32feff7..b9dc829175f9 100644
--- a/nbd/client.c
+++ b/nbd/client.c
@@ -1,5 +1,5 @@
 /*
- *  Copyright (C) 2016-2018 Red Hat, Inc.
+ *  Copyright (C) 2016-2019 Red Hat, Inc.
  *  Copyright (C) 2005  Anthony Liguori 
  *
  *  Network Block Device Client Side
@@ -142,17 +142,18 @@ static int nbd_receive_option_reply(QIOChannel *ioc, 
uint32_t opt,
 return 0;
 }

-/* If reply represents success, return 1 without further action.
- * If reply represents an error, consume the optional payload of
- * the packet on ioc.  Then return 0 for unsupported (so the client
- * can fall back to other approaches), or -1 with errp set for other
- * errors.
+/*
+ * If reply represents success, return 1 without further action.  If
+ * reply represents an error, consume the optional payload of the
+ * packet on ioc.  Then return 0 for unsupported (so the client can
+ * fall back to other approaches), where @strict determines if only
+ * ERR_UNSUP or all errors fit that category, or -1 with errp set for
+ * other errors.
  */
 static int nbd_handle_reply_err(QIOChannel *ioc, NBDOptionReply *reply,
-Error **errp)
+bool strict, Error **errp)
 {
-char *msg = NULL;
-int result = -1;
+g_autofree char *msg = NULL;

 if (!(reply->type & (1 << 31))) {
 return 1;
@@ -163,26 +164,28 @@ static int nbd_handle_reply_err(QIOChannel *ioc, 
NBDOptionReply *reply,
 error_setg(errp, "server error %" PRIu32
" (%s) message is too long",
reply->type, nbd_rep_lookup(reply->type));
-goto cleanup;
+goto err;
 }
 msg = g_malloc(reply->length + 1);
 if (nbd_read(ioc, msg, reply->length, NULL, errp) < 0) {
 error_prepend(errp, "Failed to read option error %" PRIu32
   " (%s) message: ",
   reply->type, nbd_rep_lookup(reply->type));
-goto cleanup;
+goto err;
 }
 msg[reply->length] = '\0';
 trace_nbd_server_error_msg(reply->type,
nbd_reply_type_lookup(reply->type), msg);
 }

+if (reply->type == NBD_REP_ERR_UNSUP || !strict) {
+trace_nbd_reply_err_ignored(reply->option,
+nbd_opt_lookup(reply->option),
+reply->type, nbd_rep_lookup(reply->type));
+return 0;
+}
+
 switch (reply->type) {
-case NBD_REP_ERR_UNSUP:
-trace_nbd_reply_err_unsup(reply->option, 
nbd_opt_lookup(reply->option));
-result = 0;
-goto cleanup;
-
 case NBD_REP_ERR_POLICY:
 error_setg(errp, "Denied by server for option %" PRIu32 " (%s)",
reply->option, nbd_opt_lookup(reply->option));
@@ -227,12 +230,9 @@ static int nbd_handle_reply_err(QIOChannel *ioc, 
NBDOptionReply *reply,
 error_append_hint(errp, "server reported: %s\n", msg);
 }

- cleanup:
-g_free(msg);
-if (result < 0) {
-nbd_send_opt_abort(ioc);
-}
-return result;
+ err:
+nbd_send_opt_abort(ioc);
+return -1;
 }

 /* nbd_receive_list:
@@ -257,7 +257,7 @@ static int nbd_receive_list(QIOChannel *ioc, char **name, 
char **description,
 if (nbd_receive_option_reply(ioc, NBD_OPT_LIST, &reply, errp) < 0) {
 return -1;
 }
-error = nbd_handle_reply_err(ioc, &reply, errp);
+error = nbd_handle_reply_err(ioc, &reply, true, errp);
 if (error <= 0) {
 return error;
 }
@@ -363,7 +363,7 @@ static int nbd_opt_info_or_go(QIOChannel *ioc, uint32_t opt,
 if (nbd_receive_option_reply(ioc, opt, &reply, errp) < 0) {
 return -1;
 }
-error = nbd_handle_reply_err(ioc, &reply, errp);
+error = nbd_handle_reply_err(ioc, &reply, true, errp);
 if (error <= 0) {
 return error;
 }
@@ -538,12 +538,15 @@ static int nbd_receive_query_exports(QIOChannel *ioc,
 }
 }

-/* nbd_request_simple_

[Qemu-devel] [PULL 0/9] NBD patches through 2019-09-05

2019-09-05 Thread Eric Blake
The following changes since commit eac2f39602e0423adf56be410c9a22c31fec9a81:

  target/arm: Inline gen_bx_im into callers (2019-09-05 13:23:04 +0100)

are available in the Git repository at:

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

for you to fetch changes up to 73bddca33cb1749ddcbcc1e9972a77d93000553b:

  nbd: Implement server use of NBD FAST_ZERO (2019-09-05 10:48:46 -0500)


nbd patches for 2019-09-05

- Advertise NBD_FLAG_CAN_MULTI_CONN on readonly images
- Tolerate larger set of server error responses during handshake
- More precision on handling fallocate() failures due to alignment
- Better documentation of NBD connection URIs
- Implement new extension NBD_CMD_FLAG_FAST_ZERO to benefit qemu-img convert


Andrey Shinkevich (1):
  block: workaround for unaligned byte range in fallocate()

Eric Blake (8):
  nbd: Advertise multi-conn for shared read-only connections
  nbd: Use g_autofree in a few places
  nbd: Tolerate more errors to structured reply request
  docs: Update preferred NBD device syntax
  nbd: Improve per-export flag handling in server
  nbd: Prepare for NBD_CMD_FLAG_FAST_ZERO
  nbd: Implement client use of NBD FAST_ZERO
  nbd: Implement server use of NBD FAST_ZERO

 docs/interop/nbd.txt |  2 ++
 qemu-doc.texi| 11 +--
 include/block/nbd.h  |  6 +++-
 block/io.c   |  2 +-
 block/file-posix.c   |  7 +
 block/nbd.c  | 18 ++-
 blockdev-nbd.c   |  3 +-
 nbd/client.c | 85 +---
 nbd/common.c |  5 
 nbd/server.c | 83 --
 qemu-nbd.c   |  7 +++--
 nbd/trace-events |  2 +-
 12 files changed, 134 insertions(+), 97 deletions(-)

-- 
2.21.0




[Qemu-devel] [PULL 1/9] nbd: Advertise multi-conn for shared read-only connections

2019-09-05 Thread Eric Blake
The NBD specification defines NBD_FLAG_CAN_MULTI_CONN, which can be
advertised when the server promises cache consistency between
simultaneous clients (basically, rules that determine what FUA and
flush from one client are able to guarantee for reads from another
client).  When we don't permit simultaneous clients (such as qemu-nbd
without -e), the bit makes no sense; and for writable images, we
probably have a lot more work before we can declare that actions from
one client are cache-consistent with actions from another.  But for
read-only images, where flush isn't changing any data, we might as
well advertise multi-conn support.  What's more, advertisement of the
bit makes it easier for clients to determine if 'qemu-nbd -e' was in
use, where a second connection will succeed rather than hang until the
first client goes away.

This patch affects qemu as server in advertising the bit.  We may want
to consider patches to qemu as client to attempt parallel connections
for higher throughput by spreading the load over those connections
when a server advertises multi-conn, but for now sticking to one
connection per nbd:// BDS is okay.

See also: https://bugzilla.redhat.com/1708300
Signed-off-by: Eric Blake 
Message-Id: <20190815185024.7010-1-ebl...@redhat.com>
[eblake: tweak blockdev-nbd.c to not request shared when writable]
Reviewed-by: John Snow 
---
 docs/interop/nbd.txt | 1 +
 include/block/nbd.h  | 2 +-
 blockdev-nbd.c   | 2 +-
 nbd/server.c | 4 +++-
 qemu-nbd.c   | 2 +-
 5 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/docs/interop/nbd.txt b/docs/interop/nbd.txt
index fc64473e02b2..6dfec7f47647 100644
--- a/docs/interop/nbd.txt
+++ b/docs/interop/nbd.txt
@@ -53,3 +53,4 @@ the operation of that feature.
 * 2.12: NBD_CMD_BLOCK_STATUS for "base:allocation"
 * 3.0: NBD_OPT_STARTTLS with TLS Pre-Shared Keys (PSK),
 NBD_CMD_BLOCK_STATUS for "qemu:dirty-bitmap:", NBD_CMD_CACHE
+* 4.2: NBD_FLAG_CAN_MULTI_CONN for sharable read-only exports
diff --git a/include/block/nbd.h b/include/block/nbd.h
index 7b36d672f046..991fd52a5134 100644
--- a/include/block/nbd.h
+++ b/include/block/nbd.h
@@ -326,7 +326,7 @@ typedef struct NBDClient NBDClient;

 NBDExport *nbd_export_new(BlockDriverState *bs, uint64_t dev_offset,
   uint64_t size, const char *name, const char *desc,
-  const char *bitmap, uint16_t nbdflags,
+  const char *bitmap, uint16_t nbdflags, bool shared,
   void (*close)(NBDExport *), bool writethrough,
   BlockBackend *on_eject_blk, Error **errp);
 void nbd_export_close(NBDExport *exp);
diff --git a/blockdev-nbd.c b/blockdev-nbd.c
index c621686131fd..1fcfdb0997c6 100644
--- a/blockdev-nbd.c
+++ b/blockdev-nbd.c
@@ -188,7 +188,7 @@ void qmp_nbd_server_add(const char *device, bool has_name, 
const char *name,
 }

 exp = nbd_export_new(bs, 0, len, name, NULL, bitmap,
- writable ? 0 : NBD_FLAG_READ_ONLY,
+ writable ? 0 : NBD_FLAG_READ_ONLY, !writable,
  NULL, false, on_eject_blk, errp);
 if (!exp) {
 return;
diff --git a/nbd/server.c b/nbd/server.c
index f55ccf8edfde..0fb41c6c50ea 100644
--- a/nbd/server.c
+++ b/nbd/server.c
@@ -1461,7 +1461,7 @@ static void nbd_eject_notifier(Notifier *n, void *data)

 NBDExport *nbd_export_new(BlockDriverState *bs, uint64_t dev_offset,
   uint64_t size, const char *name, const char *desc,
-  const char *bitmap, uint16_t nbdflags,
+  const char *bitmap, uint16_t nbdflags, bool shared,
   void (*close)(NBDExport *), bool writethrough,
   BlockBackend *on_eject_blk, Error **errp)
 {
@@ -1487,6 +1487,8 @@ NBDExport *nbd_export_new(BlockDriverState *bs, uint64_t 
dev_offset,
 perm = BLK_PERM_CONSISTENT_READ;
 if ((nbdflags & NBD_FLAG_READ_ONLY) == 0) {
 perm |= BLK_PERM_WRITE;
+} else if (shared) {
+nbdflags |= NBD_FLAG_CAN_MULTI_CONN;
 }
 blk = blk_new(bdrv_get_aio_context(bs), perm,
   BLK_PERM_CONSISTENT_READ | BLK_PERM_WRITE_UNCHANGED |
diff --git a/qemu-nbd.c b/qemu-nbd.c
index 83b6c32d73aa..2403ef3d0f9f 100644
--- a/qemu-nbd.c
+++ b/qemu-nbd.c
@@ -1173,7 +1173,7 @@ int main(int argc, char **argv)
 }

 export = nbd_export_new(bs, dev_offset, fd_size, export_name,
-export_description, bitmap, nbdflags,
+export_description, bitmap, nbdflags, shared > 1,
 nbd_export_closed, writethrough, NULL,
 &error_fatal);

-- 
2.21.0




Re: [Qemu-devel] [PATCH v1 02/42] configure: clean-up container cross compile detect

2019-09-05 Thread David Hildenbrand
On 04.09.19 22:29, Alex Bennée wrote:
> The introduction of podman support inadvertently broke configure's
> detect of the container support as the configure probe didn't specify
> an engine type. To fix this in docker.py:
> 
>   - only (re)set USE_ENGINE if --engine is specified
>   - enhance the output so docker is no longer just yes
> 
> In the configure script we can at least start cleaning up the
> detecting and naming of variables. To avoid too much churn the
> conversion of the various make DOCKER_foo variables has been left for
> future clean-ups.

This is not only a "clean-up" but an actual fix :) (maybe add a Fixes: tag).

This makes it work again for me.

t460s: ~/git/qemu mvc $ tests/docker/docker.py probe
docker

Thanks!

> 
> Signed-off-by: Alex Bennée 
> ---
>  configure  | 10 +-
>  tests/docker/docker.py |  7 ---
>  2 files changed, 9 insertions(+), 8 deletions(-)
> 
> diff --git a/configure b/configure
> index 95134c0180b..94845fc5101 100755
> --- a/configure
> +++ b/configure
> @@ -495,7 +495,7 @@ qed="yes"
>  parallels="yes"
>  sheepdog="yes"
>  libxml2=""
> -docker="no"
> +container="no"
>  debug_mutex="no"
>  libpmem=""
>  default_devices="yes"
> @@ -5894,14 +5894,14 @@ EOF
>  fi
>  
>  ##
> -# Docker and cross-compiler support
> +# Container based cross-compiler support
>  #
>  # This is specifically for building test
>  # cases for foreign architectures, not
>  # cross-compiling QEMU itself.
>  
> -if has "docker"; then
> -docker=$($python $source_path/tests/docker/docker.py probe)
> +if has "docker" || has "podman"; then
> +container=$($python $source_path/tests/docker/docker.py probe)
>  fi
>  
>  ##
> @@ -6474,7 +6474,7 @@ echo "qed support   $qed"
>  echo "parallels support $parallels"
>  echo "sheepdog support  $sheepdog"
>  echo "capstone  $capstone"
> -echo "docker$docker"
> +echo "container support $container"
>  echo "libpmem support   $libpmem"
>  echo "libudev   $libudev"
>  echo "default devices   $default_devices"
> diff --git a/tests/docker/docker.py b/tests/docker/docker.py
> index 4bba29e104e..e23209f71ee 100755
> --- a/tests/docker/docker.py
> +++ b/tests/docker/docker.py
> @@ -536,9 +536,9 @@ class ProbeCommand(SubCommand):
>  try:
>  docker = Docker()
>  if docker._command[0] == "docker":
> -print("yes")
> +print("docker")
>  elif docker._command[0] == "sudo":
> -print("sudo")
> +print("sudo docker")
>  elif docker._command[0] == "podman":
>  print("podman")
>  except Exception:
> @@ -651,7 +651,8 @@ def main():
>  cmd.args(subp)
>  subp.set_defaults(cmdobj=cmd)
>  args, argv = parser.parse_known_args()
> -USE_ENGINE = args.engine
> +if args.engine:
> +USE_ENGINE = args.engine
>  return args.cmdobj.run(args, argv)
>  
>  
> 


-- 

Thanks,

David / dhildenb



Re: [Qemu-devel] [RFC 0/3] virtiofsd: get/set log level via DBus

2019-09-05 Thread Dr. David Alan Gilbert
* Stefan Hajnoczi (stefa...@redhat.com) wrote:
> It is likely that virtiofsd will need to support "management commands" for
> reconfiguring it at runtime.  The first use case was proposed by Eryu Guan for
> getting/setting the current log level.
> 
> I promised to try out DBus as the management interface because it has a rich
> feature set and is accessible from most programming languages.  It should be
> able to support all the use cases we come up with.
> 
> This patch series is a prototype that implements the get-log-level and
> set-log-level management commands via DBus.  Use the new virtiofsctl tool to
> talk to a running virtiofsd process:
> 
>   # dbus-run-session ./virtiofsd ...
>   ...
>   Using dbus address 
> unix:abstract=/tmp/dbus-H9WBbpjk3O,guid=0be16acefb868e6025a8737f5d7124d2
>   # export 
> DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-H9WBbpjk3O,guid=0be16acefb868e6025a8737f5d7124d2
>   # ./virtiofsctl set-log-level err
> 
> Most of the work is done by gdbus-codegen(1).  It generates code for the
> org.qemu.Virtiofsd.xml interface definition.  Our code can use the simple
> virtiofsd_get/set_log_level() APIs and it will make corresponding DBus calls.
> 
> I'm pretty happy with this approach because the code is straightforward.  It
> hasn't even triggered seccomp failures yet :).

Yes it's less complex than I'd worried.
Now, I do think we've got to think about how qemu in general is going to
use dbus as people were discussing it, because then we have to think
what the security aspects are - do we need to look at some calls only
available to some clients etc.

Dave

> Error handling is a little problematic.  I noticed that virtiofsctl silently
> returns success even if it cannot talk to virtiofsd.  This is due to the code
> generated by gdbus-codegen(1) which has no error reporting :(.  This can be
> solved by writing more low-level GDBus code instead of using the high-level
> generated bindings.
> 
> What do you think about this approach?
> 
> Stefan Hajnoczi (3):
>   virtiofsd: add org.qemu.Virtiofsd interface
>   virtiofsd: add DBus server to handle log level changes
>   virtiofsd: add virtiofsctl command-line management tool
> 
>  configure|   7 +
>  Makefile |  16 +++
>  Makefile.objs|   1 +
>  contrib/virtiofsd/Makefile.objs  |  10 +-
>  contrib/virtiofsd/dbus.h |   9 ++
>  contrib/virtiofsd/dbus.c | 162 +++
>  contrib/virtiofsd/passthrough_ll.c   |   8 +-
>  contrib/virtiofsd/virtiofsctl.c  |  55 
>  .gitignore   |   1 +
>  contrib/virtiofsd/org.qemu.Virtiofsd.xml |   7 +
>  10 files changed, 274 insertions(+), 2 deletions(-)
>  create mode 100644 contrib/virtiofsd/dbus.h
>  create mode 100644 contrib/virtiofsd/dbus.c
>  create mode 100644 contrib/virtiofsd/virtiofsctl.c
>  create mode 100644 contrib/virtiofsd/org.qemu.Virtiofsd.xml
> 
> -- 
> 2.21.0
> 
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK



Re: [Qemu-devel] [PATCH 2/2] block/nvme: add support for discard

2019-09-05 Thread Maxim Levitsky
On Thu, 2019-09-05 at 13:27 -0400, John Snow wrote:
> 
> On 9/5/19 9:24 AM, Maxim Levitsky wrote:
> > On Wed, 2019-08-28 at 12:03 +0300, Maxim Levitsky wrote:
> > > On Tue, 2019-08-27 at 18:29 -0400, John Snow wrote:
> > > > 
> > > > On 8/25/19 3:15 AM, Maxim Levitsky wrote:
> > > > > Signed-off-by: Maxim Levitsky 
> > > > > ---
> > > > >  block/nvme.c   | 83 
> > > > > ++
> > > > >  block/trace-events |  2 ++
> > > > >  2 files changed, 85 insertions(+)
> > > > > 
> > > > > diff --git a/block/nvme.c b/block/nvme.c
> > > > > index f8bd11e19a..dd041f39c9 100644
> > > > > --- a/block/nvme.c
> > > > > +++ b/block/nvme.c
> > > > > @@ -112,6 +112,7 @@ typedef struct {
> > > > >  bool plugged;
> > > > >  
> > > > >  bool supports_write_zeros;
> > > > > +bool supports_discard;
> > > > >  
> > > > >  CoMutex dma_map_lock;
> > > > >  CoQueue dma_flush_queue;
> > > > > @@ -463,6 +464,7 @@ static void nvme_identify(BlockDriverState *bs, 
> > > > > int namespace, Error **errp)
> > > > >  
> > > > >  oncs = le16_to_cpu(idctrl->oncs);
> > > > >  s->supports_write_zeros = (oncs & NVME_ONCS_WRITE_ZEROS) != 0;
> > > > > +s->supports_discard = (oncs & NVME_ONCS_DSM) != 0;
> > > > 
> > > > Same comment -- checking !!(register & FIELD) is nicer than the
> > > > negative. (I'm actually not sure even the !! is needed, but it seems to
> > > > be a QEMU-ism and I've caught myself using it...)
> > > 
> > > All right, no problem to use !!
> > > 
> > > > 
> > > > Rest looks good to me on a skim, but I'm not very well-versed in NVME.
> > > 
> > > Thanks!
> > > 
> > 
> > Kind ping about this patch series.
> > 
> > Apart from using !!, do you think that this patch series
> > can be merged, or should I do anything else?
> > Which tree do you think this should be committed to?
> > 
> > I kind of want to see that merged before the freeze
> > starts, if there are no objections,
> > to reduce the amount of pending stuff in my queue.
> > 
> 
> Didn't I ask a few other things?
> 
> like not using "res30" because you've moved the fields around, and
> trying to be consistent about "zeros" vs "zeroes".
> 
> Removing "+#define NVME_ID_NS_DLFEAT_GUARD_CRC(dlfeat)   ((dlfeat) &
> 0x10)" because it's unused.


All right I forgot about it, that's one of they joys of duplication of a kernel
driver in the userspace...


> 
> You also probably require review (or at least an ACK) from Keith Busch
> who maintains this file.
> 
> --js

All right,
Best regards,
Maxim Levitsky





Re: [Qemu-devel] [RFC 2/3] virtiofsd: add DBus server to handle log level changes

2019-09-05 Thread Dr. David Alan Gilbert
* Stefan Hajnoczi (stefa...@redhat.com) wrote:
> Introduce a DBus server thread that runs alongside the other virtiofsd
> threads.  It processes changes to the /org/qemu/virtiofsd object which
> can be accessed at the org.qemu.virtiofsd location on the bus.
> 
> This code does not use locking because we are the only writer to the
> int current_log_level variable.  More advanced management commands would
> require locking to prevent race conditions with the other threads.
> 
> Signed-off-by: Stefan Hajnoczi 

OK, that is less complex than I'd feared.
I guess there's something probably nice to do with name/integer mapping
for warning levels that we could use from one of the libraries.

Dave

> ---
>  contrib/virtiofsd/Makefile.objs|   3 +-
>  contrib/virtiofsd/dbus.h   |   9 ++
>  contrib/virtiofsd/dbus.c   | 162 +
>  contrib/virtiofsd/passthrough_ll.c |   8 +-
>  4 files changed, 180 insertions(+), 2 deletions(-)
>  create mode 100644 contrib/virtiofsd/dbus.h
>  create mode 100644 contrib/virtiofsd/dbus.c
> 
> diff --git a/contrib/virtiofsd/Makefile.objs b/contrib/virtiofsd/Makefile.objs
> index 9b2af1bc23..d59ab60f3d 100644
> --- a/contrib/virtiofsd/Makefile.objs
> +++ b/contrib/virtiofsd/Makefile.objs
> @@ -8,7 +8,8 @@ virtiofsd-obj-y = buffer.o \
>helper.o \
>passthrough_ll.o \
>seccomp.o \
> -  gdbus_generated.o
> +  gdbus_generated.o \
> +  dbus.o
>  
>  seccomp.o-cflags := $(SECCOMP_CFLAGS)
>  seccomp.o-libs := $(SECCOMP_LIBS)
> diff --git a/contrib/virtiofsd/dbus.h b/contrib/virtiofsd/dbus.h
> new file mode 100644
> index 00..aa18e47408
> --- /dev/null
> +++ b/contrib/virtiofsd/dbus.h
> @@ -0,0 +1,9 @@
> +#ifndef DBUS_H
> +#define DBUS_H
> +
> +#include 
> +
> +bool setup_dbus(void);
> +void cleanup_dbus(void);
> +
> +#endif /* DBUS_H */
> diff --git a/contrib/virtiofsd/dbus.c b/contrib/virtiofsd/dbus.c
> new file mode 100644
> index 00..bc2308e34b
> --- /dev/null
> +++ b/contrib/virtiofsd/dbus.c
> @@ -0,0 +1,162 @@
> +#include 
> +#include 
> +#include 
> +#include "fuse_log.h"
> +#include "dbus.h"
> +#include "gdbus_generated.h"
> +
> +static GThread *the_dbus_thread;
> +static GMainContext *the_dbus_context;
> +static GMainLoop *the_dbus_loop;
> +
> +/* Set the string property based on the current log level */
> +static void refresh_log_level(Virtiofsd *virtiofsd)
> +{
> +switch (current_log_level) {
> +case LOG_ERR:
> +virtiofsd_set_log_level(virtiofsd, "err");
> +break;
> +case LOG_WARNING:
> +virtiofsd_set_log_level(virtiofsd, "warning");
> +break;
> +case LOG_INFO:
> +virtiofsd_set_log_level(virtiofsd, "info");
> +break;
> +case LOG_DEBUG:
> +virtiofsd_set_log_level(virtiofsd, "debug");
> +break;
> +}
> +}
> +
> +/* Handle changes to Virtiofsd object properties */
> +static void notify(GObject *object, GParamSpec *pspec)
> +{
> +Virtiofsd *virtiofsd = VIRTIOFSD(object);
> +
> +fprintf(stderr, "%s %s\n", __func__, pspec->name);
> +
> +if (strcmp(pspec->name, "log-level") == 0) {
> +const char *s = virtiofsd_get_log_level(virtiofsd);
> +
> +if (strcmp(s, "err") == 0) {
> +current_log_level = LOG_ERR;
> +} else if (strcmp(s, "warning") == 0) {
> +current_log_level = LOG_WARNING;
> +} else if (strcmp(s, "info") == 0) {
> +current_log_level = LOG_INFO;
> +} else if (strcmp(s, "debug") == 0) {
> +current_log_level = LOG_DEBUG;
> +} else {
> +/* Invalid, reset the log level property */
> +refresh_log_level(virtiofsd);
> +}
> +}
> +}
> +
> +typedef struct {
> +Virtiofsd *virtiofsd;
> +pthread_barrier_t *started;
> +} GBusOwnNameData;
> +
> +static void bus_acquired(GDBusConnection *connection, const gchar *name,
> +gpointer user_data)
> +{
> +GBusOwnNameData *data = user_data;
> +GError *error = NULL;
> +
> +if (!g_dbus_interface_skeleton_export(
> +G_DBUS_INTERFACE_SKELETON(data->virtiofsd),
> +connection, "/org/qemu/virtiofsd", &error)) {
> +fuse_err("g_dbus_interface_skeleton_export: %s\n", error->message);
> +g_error_free(error);
> +exit(EXIT_FAILURE);
> +}
> +}
> +
> +static void name_acquired(GDBusConnection *connection, const gchar *name,
> +gpointer user_data)
> +{
> +GBusOwnNameData *data = user_data;
> +
> +pthread_barrier_wait(data->started);
> +}
> +
> +static void name_lost(GDBusConnection *connection, const gchar *name,
> +gpointer user_data)
> +{
> +if (connection) {
> +fuse_err("unable to own dbus name\n");
> +} else {
> +fuse_err("unable to connect to dbus\n");
> +}
> +exit(EXIT_FAILURE);
> +}
> +
> 

Re: [Qemu-devel] [PATCH 2/2] block/nvme: add support for discard

2019-09-05 Thread John Snow



On 9/5/19 9:24 AM, Maxim Levitsky wrote:
> On Wed, 2019-08-28 at 12:03 +0300, Maxim Levitsky wrote:
>> On Tue, 2019-08-27 at 18:29 -0400, John Snow wrote:
>>>
>>> On 8/25/19 3:15 AM, Maxim Levitsky wrote:
 Signed-off-by: Maxim Levitsky 
 ---
  block/nvme.c   | 83 ++
  block/trace-events |  2 ++
  2 files changed, 85 insertions(+)

 diff --git a/block/nvme.c b/block/nvme.c
 index f8bd11e19a..dd041f39c9 100644
 --- a/block/nvme.c
 +++ b/block/nvme.c
 @@ -112,6 +112,7 @@ typedef struct {
  bool plugged;
  
  bool supports_write_zeros;
 +bool supports_discard;
  
  CoMutex dma_map_lock;
  CoQueue dma_flush_queue;
 @@ -463,6 +464,7 @@ static void nvme_identify(BlockDriverState *bs, int 
 namespace, Error **errp)
  
  oncs = le16_to_cpu(idctrl->oncs);
  s->supports_write_zeros = (oncs & NVME_ONCS_WRITE_ZEROS) != 0;
 +s->supports_discard = (oncs & NVME_ONCS_DSM) != 0;
>>>
>>> Same comment -- checking !!(register & FIELD) is nicer than the
>>> negative. (I'm actually not sure even the !! is needed, but it seems to
>>> be a QEMU-ism and I've caught myself using it...)
>>
>> All right, no problem to use !!
>>
>>>
>>> Rest looks good to me on a skim, but I'm not very well-versed in NVME.
>>
>> Thanks!
>>
> 
> Kind ping about this patch series.
> 
> Apart from using !!, do you think that this patch series
> can be merged, or should I do anything else?
> Which tree do you think this should be committed to?
> 
> I kind of want to see that merged before the freeze
> starts, if there are no objections,
> to reduce the amount of pending stuff in my queue.
> 

Didn't I ask a few other things?

like not using "res30" because you've moved the fields around, and
trying to be consistent about "zeros" vs "zeroes".

Removing "+#define NVME_ID_NS_DLFEAT_GUARD_CRC(dlfeat)   ((dlfeat) &
0x10)" because it's unused.

You also probably require review (or at least an ACK) from Keith Busch
who maintains this file.

--js



Re: [Qemu-devel] [PATCH v1 03/42] tests/docker: fix "cc" command to work with podman

2019-09-05 Thread John Snow



On 9/5/19 5:51 AM, Alex Bennée wrote:
> 
> John Snow  writes:
> 
>> On 9/4/19 4:29 PM, Alex Bennée wrote:
>>> Podman requires a little bit of additional magic to the uid mapping
>>> which was already done for the normal RunCommand. We simplify the
>>> logic by pushing it directly into the Docker::run method to avoid
>>> instantiating an extra Docker() object and ensure the CC command
>>> always runs as the current user.
>>>
>>> Signed-off-by: Alex Bennée 
>>> ---
>>>  tests/docker/docker.py | 30 +++---
>>>  tests/tcg/Makefile.include |  2 +-
>>>  2 files changed, 16 insertions(+), 16 deletions(-)
>>>
>>> diff --git a/tests/docker/docker.py b/tests/docker/docker.py
>>> index e23209f71ee..8f391eb278b 100755
>>> --- a/tests/docker/docker.py
>>> +++ b/tests/docker/docker.py
>>> @@ -318,10 +318,20 @@ class Docker(object):
>>>  return False
>>>  return checksum == 
>>> _text_checksum(_dockerfile_preprocess(dockerfile))
>>>
>>> -def run(self, cmd, keep, quiet):
>>> +def run(self, cmd, keep, quiet, as_user=False):
>>>  label = uuid.uuid1().hex
>>>  if not keep:
>>>  self._instances.append(label)
>>> +
>>> +if as_user:
>>> +uid = os.getuid()
>>> +cmd = [ "-u", str(uid) ] + cmd
>>> +# podman requires a bit more fiddling
>>> +if self._command[0] == "podman":
>>> +cmd = [ "--uidmap", "%d:0:1" % uid,
>>> +"--uidmap", "0:1:%d" % uid,
>>> +"--uidmap", "%d:%d:64536" % (uid + 1, uid + 1)] + 
>>> cmd
>>> +
>>
>> I was having problems with constructs like these recently. I think we
>> either need to use --userns=keep-id (vastly preferred) or adjust 64536
>> there to read as "65536 - uid" because not everyone will have a UID of
>> 1000.
> 
> From Marc-André's original commit:
> 
>   With a user 1000, the default mapping is: 1000 (host) -> 0 (container).
> 
>   So write access to /var/tmp/ccache ends will end with permission
>   denied error.
> 
>   With "--uidmap 1000:0:1 --uidmap 0:1:1000", the mapping is:
>   1000 (host) -> 0 (container, 1st namespace) -> 1000 (container, 2nd 
> namespace).
>   (the rest is mumbo jumbo to avoid holes in the range of UIDs)
> 
>   A future podman version may have an option such as --userns-keep-uid.
>   Thanks to Debarshi Ray  for the help!
> 
> So I assumed this doesn't exist for all versions of podman yet. Given
> how new the support is I guess we could just say you need a minimum
> version for working podman support.
> 

I think that's probably fine to say. Matt Heon says that 1.4.x should be
available in RHEL7 and RHEL8 both, and it's available in Fedora 30, so
it should be reasonably well represented on modern development machines.

It's also entirely optional as you may continue using docker if you wish.

Thanks for staging the patch to fix this; I'll try to test it out in
conjunction with your patchset here later when time permits.

--js



Re: [Qemu-devel] [RFC 3/3] virtiofsd: add virtiofsctl command-line management tool

2019-09-05 Thread Dr. David Alan Gilbert
* Stefan Hajnoczi (stefa...@redhat.com) wrote:
> virtiofsctl can control a running virtiofsd process:
> 
>   usage: ./virtiofsctl COMMAND [args...]
> 
>   Commands:
> get-log-level   - show current log level
> set-log-level LEVEL - set current log level to one of
>   "err", "warning", "info", "debug"
> 
> Make sure it is running in the same DBus session as virtiofsd.  This may
> require setting the DBUS_SESSION_BUS_ADDRESS environment variable to the
> same value as used by virtiofsd.
> 
> Signed-off-by: Stefan Hajnoczi 
> ---
>  Makefile|  3 ++
>  Makefile.objs   |  1 +
>  contrib/virtiofsd/Makefile.objs |  3 ++
>  contrib/virtiofsd/virtiofsctl.c | 55 +
>  4 files changed, 62 insertions(+)
>  create mode 100644 contrib/virtiofsd/virtiofsctl.c
> 
> diff --git a/Makefile b/Makefile
> index 6b1af33348..d7ed9e7669 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -419,6 +419,7 @@ dummy := $(call unnest-vars,, \
>  ivshmem-client-obj-y \
>  ivshmem-server-obj-y \
>  virtiofsd-obj-y \
> +virtiofsctl-obj-y \
>  rdmacm-mux-obj-y \
>  libvhost-user-obj-y \
>  vhost-user-scsi-obj-y \
> @@ -661,6 +662,8 @@ contrib/virtiofsd/gdbus_generated.c-timestamp: 
> $(SRC_PATH)/contrib/virtiofsd/org
>  
>  virtiofsd$(EXESUF): $(virtiofsd-obj-y) libvhost-user.a $(COMMON_LDADDS)
>   $(call LINK, $^)
> +virtiofsctl$(EXESUF): $(virtiofsctl-obj-y)
> + $(call LINK, $^)
>  endif
>  
>  vhost-user-gpu$(EXESUF): $(vhost-user-gpu-obj-y) $(libvhost-user-obj-y) 
> libqemuutil.a libqemustub.a
> diff --git a/Makefile.objs b/Makefile.objs
> index dfdd7d56ea..326a8abb8e 100644
> --- a/Makefile.objs
> +++ b/Makefile.objs
> @@ -126,6 +126,7 @@ rdmacm-mux-obj-y = contrib/rdmacm-mux/
>  vhost-user-input-obj-y = contrib/vhost-user-input/
>  vhost-user-gpu-obj-y = contrib/vhost-user-gpu/
>  virtiofsd-obj-y = contrib/virtiofsd/
> +virtiofsctl-obj-y = contrib/virtiofsd/
>  
>  ##
>  trace-events-subdirs =
> diff --git a/contrib/virtiofsd/Makefile.objs b/contrib/virtiofsd/Makefile.objs
> index d59ab60f3d..3f944d493e 100644
> --- a/contrib/virtiofsd/Makefile.objs
> +++ b/contrib/virtiofsd/Makefile.objs
> @@ -11,6 +11,9 @@ virtiofsd-obj-y = buffer.o \
>gdbus_generated.o \
>dbus.o
>  
> +virtiofsctl-obj-y = virtiofsctl.o \
> +gdbus_generated.o
> +
>  seccomp.o-cflags := $(SECCOMP_CFLAGS)
>  seccomp.o-libs := $(SECCOMP_LIBS)
>  
> diff --git a/contrib/virtiofsd/virtiofsctl.c b/contrib/virtiofsd/virtiofsctl.c
> new file mode 100644
> index 00..39bee2b881
> --- /dev/null
> +++ b/contrib/virtiofsd/virtiofsctl.c
> @@ -0,0 +1,55 @@
> +#include 
> +#include "gdbus_generated.h"
> +
> +static void get_log_level(Virtiofsd *virtiofsd)
> +{
> +const char *value = virtiofsd_get_log_level(virtiofsd);
> +
> +printf("%s\n", value ? value : "(null)");
> +}
> +
> +static void set_log_level(Virtiofsd *virtiofsd, const char *value)
> +{
> +virtiofsd_set_log_level(virtiofsd, value);
> +}
> +
> +static void usage(const char *progname)
> +{
> +printf("usage: %s COMMAND [args...]\n", progname);
> +printf("\n");
> +printf("Commands:\n");
> +printf("  get-log-level   - show current log level\n");
> +printf("  set-log-level LEVEL - set current log level to one of\n");
> +printf("\"err\", \"warning\", \"info\", 
> \"debug\"\n");
> +exit(0);
> +}
> +
> +int main(int argc, char **argv)
> +{
> +Virtiofsd *virtiofsd;
> +GError *error = NULL;
> +
> +if (argc < 2) {
> +usage(argv[0]);
> +}
> +
> +virtiofsd = virtiofsd_proxy_new_for_bus_sync(G_BUS_TYPE_SESSION,
> +G_DBUS_PROXY_FLAGS_NONE, "org.qemu.virtiofsd",
> +"/org/qemu/virtiofsd", NULL, &error);
> +if (error) {
> +fprintf(stderr, "%s\n", error->message);
> +g_error_free(error);
> +return 1;
> +}
> +
> +if (strcmp(argv[0], "get-log-level") == 0) {

This and the one below works a lot better with argv[1] !

(I wonder if a little python script would be better for these type of
wrappers).

Dave

> +get_log_level(virtiofsd);
> +} else if (strcmp(argv[0], "set-log-level") == 0) {

> +if (argc != 3) {
> +usage(argv[0]);
> +}
> +set_log_level(virtiofsd, argv[2]);
> +}
> +g_object_unref(virtiofsd);
> +return 0;
> +}
> -- 
> 2.21.0
> 
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK



Re: [Qemu-devel] [PULL v2 0/9] qtests and misc patches

2019-09-05 Thread Peter Maydell
On Thu, 5 Sep 2019 at 16:30, Thomas Huth  wrote:
>
>  Hi Peter,
>
> the following changes since commit 500efcfcf0fe2e0dae1d25637a13435ce7b6e421:
>
>   Merge remote-tracking branch 'remotes/rth/tags/pull-or1k-20190904' into 
> staging (2019-09-05 09:33:01 +0100)
>
> are available in the Git repository at:
>
>   https://gitlab.com/huth/qemu.git tags/pull-request-2019-09-05-v2
>
> for you to fetch changes up to e7dc804ef0d7cac9ac8b4a1324ab7dbfafb55704:
>
>   gitlab-ci.yml: Install libattr-devel and libcap-devel to test virtio-9p 
> (2019-09-05 16:00:01 +0200)
>
> 
> - Make the core libqtest library independent from global_qtest
> - Clean up docs from hard-coded qemu-system-* names
> - Install libattr-dev and libcap-dev in gitlab-ci to test virtio-9p
> 



Applied, thanks.

Please update the changelog at https://wiki.qemu.org/ChangeLog/4.2
for any user-visible changes.

-- PMM



Re: [Qemu-devel] [PATCH v3 0/6] tests/docker: add podman support

2019-09-05 Thread Alex Bennée


David Hildenbrand  writes:

> On 13.07.19 16:33, Marc-André Lureau wrote:
>> Hi,
>>
>> podman allows to run containers in a similar fashion as docker, but
>> without daemon or root privileges. Thank you podman!
>>
>> There is a weird issue with getaddrinfo(), that I reported upstream
>> https://github.com/containers/libpod/issues/3535. For now, it is
>> worked around with extra socket_check_protocol_support() checks.
>>
>> thanks
>>
>> v3:
>> - add --run-as-current-user, suggest by Paolo
>> - move podman user tweaks to docker.py
>> - rebasing
>>
>> v2:
>> - add socket_check_protocol_support() to test-char
>> - keep TAP harness happy when socket_check_protocol_support() fails
>> - removed bad AI_ADDRCONFIG patch
>> - rebased
>>
>> Marc-André Lureau (6):
>>   docker.py: add --run-as-current-user
>>   docker.py: add podman support
>>   tests/docker: add podman support
>>   tests: specify the address family when checking bind
>>   test-char: skip tcp tests if ipv4 check failed
>>   test: skip tests if socket_check_protocol_support() failed
>>
>>  Makefile   |  2 +-
>>  tests/Makefile.include |  2 +-
>>  tests/docker/Makefile.include  | 10 +--
>>  tests/docker/docker.py | 53 ++
>>  tests/socket-helpers.c | 17 ---
>>  tests/socket-helpers.h | 11 ---
>>  tests/test-char.c  | 19 +---
>>  tests/test-io-channel-socket.c |  4 ++-
>>  tests/test-util-sockets.c  |  4 ++-
>>  9 files changed, 91 insertions(+), 31 deletions(-)
>>
>
> Most probably not related to this series. I assume I am once again doing
> something very wrong (although this used to work). I am on Fedora 30 -
> hope somebody can help me:
>
> t460s: ~/git/qemu mvc $ docker run hello-world
>
> Hello from Docker!
> This message shows that your installation appears to be working correctly.
> [...]
>
> t460s: ~/git/qemu mvc $ tests/docker/docker.py probe
> no
>
> t460s: ~/git/qemu mvc $ ./configure --target-list=i386-softmmu,...
> [...]
> dockerno
> [...]
>
> So docker is working but the configure script says I don't have docker.
> What am I missing? (I only want to run tcg tests)

See:

  Subject: [PATCH  v1 02/42] configure: clean-up container cross compile detect
  Date: Wed,  4 Sep 2019 21:29:33 +0100
  Message-Id: <20190904203013.9028-3-alex.ben...@linaro.org>
  In-Reply-To: <20190904203013.9028-1-alex.ben...@linaro.org>

But there are other fixes in that series to make it work with check-tcg
better.

--
Alex Bennée



Re: [Qemu-devel] [PATCH v6 16/42] block: Flush all children in generic code

2019-09-05 Thread Kevin Wolf
Am 12.08.2019 um 14:58 hat Max Reitz geschrieben:
> On 10.08.19 17:36, Vladimir Sementsov-Ogievskiy wrote:
> > 09.08.2019 19:13, Max Reitz wrote:
> >> If the driver does not support .bdrv_co_flush() so bdrv_co_flush()
> >> itself has to flush the children of the given node, it should not flush
> >> just bs->file->bs, but in fact all children.
> >>
> >> In any case, the BLKDBG_EVENT() should be emitted on the primary child,
> >> because that is where a blkdebug node would be if there is any.
> >>
> >> Suggested-by: Vladimir Sementsov-Ogievskiy 
> >> Signed-off-by: Max Reitz 
> >> ---
> >>   block/io.c | 23 +--
> >>   1 file changed, 17 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/block/io.c b/block/io.c
> >> index c5a8e3e6a3..bcc770d336 100644
> >> --- a/block/io.c
> >> +++ b/block/io.c
> >> @@ -2572,6 +2572,8 @@ static void coroutine_fn bdrv_flush_co_entry(void 
> >> *opaque)
> >>   
> >>   int coroutine_fn bdrv_co_flush(BlockDriverState *bs)
> >>   {
> >> +BdrvChild *primary_child = bdrv_primary_child(bs);
> >> +BdrvChild *child;
> >>   int current_gen;
> >>   int ret = 0;
> >>   
> >> @@ -2601,7 +2603,7 @@ int coroutine_fn bdrv_co_flush(BlockDriverState *bs)
> >>   }
> >>   
> >>   /* Write back cached data to the OS even with cache=unsafe */
> >> -BLKDBG_EVENT(bs->file, BLKDBG_FLUSH_TO_OS);
> >> +BLKDBG_EVENT(primary_child, BLKDBG_FLUSH_TO_OS);
> >>   if (bs->drv->bdrv_co_flush_to_os) {
> >>   ret = bs->drv->bdrv_co_flush_to_os(bs);
> >>   if (ret < 0) {
> >> @@ -2611,15 +2613,15 @@ int coroutine_fn bdrv_co_flush(BlockDriverState 
> >> *bs)
> >>   
> >>   /* But don't actually force it to the disk with cache=unsafe */
> >>   if (bs->open_flags & BDRV_O_NO_FLUSH) {
> >> -goto flush_parent;
> >> +goto flush_children;
> >>   }
> >>   
> >>   /* Check if we really need to flush anything */
> >>   if (bs->flushed_gen == current_gen) {
> >> -goto flush_parent;
> >> +goto flush_children;
> >>   }
> >>   
> >> -BLKDBG_EVENT(bs->file, BLKDBG_FLUSH_TO_DISK);
> >> +BLKDBG_EVENT(primary_child, BLKDBG_FLUSH_TO_DISK);
> >>   if (!bs->drv) {
> >>   /* bs->drv->bdrv_co_flush() might have ejected the BDS
> >>* (even in case of apparent success) */
> >> @@ -2663,8 +2665,17 @@ int coroutine_fn bdrv_co_flush(BlockDriverState *bs)
> >>   /* Now flush the underlying protocol.  It will also have 
> >> BDRV_O_NO_FLUSH
> >>* in the case of cache=unsafe, so there are no useless flushes.
> >>*/
> >> -flush_parent:
> >> -ret = bs->file ? bdrv_co_flush(bs->file->bs) : 0;
> >> +flush_children:
> >> +ret = 0; > +QLIST_FOREACH(child, &bs->children, next) {
> >> +int this_child_ret;
> >> +
> >> +this_child_ret = bdrv_co_flush(child->bs);
> >> +if (!ret) {
> >> +ret = this_child_ret;
> >> +}
> >> +}
> > 
> > Hmm, you said that we want to flush only children with write-access from 
> > parent..
> 
> Good that you remember it, I must have overlooked it (when reading the
> replies to the previous version). :-)
> 
> > Shouldn't we check it? Or we assume that it's always safe to call 
> > bdrv_co_flush on
> > a node?
> 
> I think it’s always safe.  But checking it seems like a nice touch, yes.

I'm not sure why we would unconditionally flush all children anyway. The
only drivers I can think of that really need to flush more than one
child are blkverify and quorum, and both of them already implement this.
blkverify implements .bdrv_co_flush, so it's not affected by the change
anyway, but quorum children will be flushed twice now.

But more than this, I'm worried about the overhead of needlessly
recursing through the whole backing chain and calling flush on every
node there.  Maybe bs->write_gen saves us so that at least this doesn't
result in an fdatasync() call for each, but still... Without a use case,
I'd rather not do this.

Oh, well, after having written all of this, I see that qcow2 with an
external data file is buggy... This could be fixed in the qcow2 driver,
but maybe restricting the recursion to read-only is actually good enough
then. Can you mention this case in the commit message and maybe build a
test for it?

Kevin



Re: [Qemu-devel] [PATCH v3 0/6] tests/docker: add podman support

2019-09-05 Thread David Hildenbrand
On 05.09.19 18:15, David Hildenbrand wrote:
> On 13.07.19 16:33, Marc-André Lureau wrote:
>> Hi,
>>
>> podman allows to run containers in a similar fashion as docker, but
>> without daemon or root privileges. Thank you podman!
>>
>> There is a weird issue with getaddrinfo(), that I reported upstream
>> https://github.com/containers/libpod/issues/3535. For now, it is
>> worked around with extra socket_check_protocol_support() checks.
>>
>> thanks
>>
>> v3:
>> - add --run-as-current-user, suggest by Paolo
>> - move podman user tweaks to docker.py
>> - rebasing
>>
>> v2:
>> - add socket_check_protocol_support() to test-char
>> - keep TAP harness happy when socket_check_protocol_support() fails
>> - removed bad AI_ADDRCONFIG patch
>> - rebased
>>
>> Marc-André Lureau (6):
>>   docker.py: add --run-as-current-user
>>   docker.py: add podman support
>>   tests/docker: add podman support
>>   tests: specify the address family when checking bind
>>   test-char: skip tcp tests if ipv4 check failed
>>   test: skip tests if socket_check_protocol_support() failed
>>
>>  Makefile   |  2 +-
>>  tests/Makefile.include |  2 +-
>>  tests/docker/Makefile.include  | 10 +--
>>  tests/docker/docker.py | 53 ++
>>  tests/socket-helpers.c | 17 ---
>>  tests/socket-helpers.h | 11 ---
>>  tests/test-char.c  | 19 +---
>>  tests/test-io-channel-socket.c |  4 ++-
>>  tests/test-util-sockets.c  |  4 ++-
>>  9 files changed, 91 insertions(+), 31 deletions(-)
>>
> 
> Most probably not related to this series. I assume I am once again doing
> something very wrong (although this used to work). I am on Fedora 30 -
> hope somebody can help me:
> 
> t460s: ~/git/qemu mvc $ docker run hello-world
> 
> Hello from Docker!
> This message shows that your installation appears to be working correctly.
> [...]
> 
> t460s: ~/git/qemu mvc $ tests/docker/docker.py probe
> no
> 
> t460s: ~/git/qemu mvc $ ./configure --target-list=i386-softmmu,...
> [...]
> dockerno
> [...]
> 
> So docker is working but the configure script says I don't have docker.
> What am I missing? (I only want to run tcg tests)
> 

FWIW, reverting

commit 9459f754134bb786edf85ca9fc00f1805e67bd74
Author: Marc-André Lureau 
Date:   Fri Jul 12 16:46:13 2019 +0400

docker.py: add podman support

Add a --engine option to select either docker, podman or auto.


fixes it for me

t460s: ~/git/qemu mvc $ tests/docker/docker.py probe
yes


So there is something wrong about that patch.

-- 

Thanks,

David / dhildenb



Re: [Qemu-devel] [PATCH v3 0/6] tests/docker: add podman support

2019-09-05 Thread David Hildenbrand
On 13.07.19 16:33, Marc-André Lureau wrote:
> Hi,
> 
> podman allows to run containers in a similar fashion as docker, but
> without daemon or root privileges. Thank you podman!
> 
> There is a weird issue with getaddrinfo(), that I reported upstream
> https://github.com/containers/libpod/issues/3535. For now, it is
> worked around with extra socket_check_protocol_support() checks.
> 
> thanks
> 
> v3:
> - add --run-as-current-user, suggest by Paolo
> - move podman user tweaks to docker.py
> - rebasing
> 
> v2:
> - add socket_check_protocol_support() to test-char
> - keep TAP harness happy when socket_check_protocol_support() fails
> - removed bad AI_ADDRCONFIG patch
> - rebased
> 
> Marc-André Lureau (6):
>   docker.py: add --run-as-current-user
>   docker.py: add podman support
>   tests/docker: add podman support
>   tests: specify the address family when checking bind
>   test-char: skip tcp tests if ipv4 check failed
>   test: skip tests if socket_check_protocol_support() failed
> 
>  Makefile   |  2 +-
>  tests/Makefile.include |  2 +-
>  tests/docker/Makefile.include  | 10 +--
>  tests/docker/docker.py | 53 ++
>  tests/socket-helpers.c | 17 ---
>  tests/socket-helpers.h | 11 ---
>  tests/test-char.c  | 19 +---
>  tests/test-io-channel-socket.c |  4 ++-
>  tests/test-util-sockets.c  |  4 ++-
>  9 files changed, 91 insertions(+), 31 deletions(-)
> 

Most probably not related to this series. I assume I am once again doing
something very wrong (although this used to work). I am on Fedora 30 -
hope somebody can help me:

t460s: ~/git/qemu mvc $ docker run hello-world

Hello from Docker!
This message shows that your installation appears to be working correctly.
[...]

t460s: ~/git/qemu mvc $ tests/docker/docker.py probe
no

t460s: ~/git/qemu mvc $ ./configure --target-list=i386-softmmu,...
[...]
dockerno
[...]

So docker is working but the configure script says I don't have docker.
What am I missing? (I only want to run tcg tests)

-- 

Thanks,

David / dhildenb



Re: [Qemu-devel] [PULL 0/4] Docs patches

2019-09-05 Thread Peter Maydell
On Thu, 5 Sep 2019 at 14:45, Daniel P. Berrangé  wrote:
>
> The following changes since commit 500efcfcf0fe2e0dae1d25637a13435ce7b6e421:
>
>   Merge remote-tracking branch 'remotes/rth/tags/pull-or1k-20190904' into 
> staging (2019-09-05 09:33:01 +0100)
>
> are available in the Git repository at:
>
>   https://github.com/berrange/qemu tags/docs-pull-request
>
> for you to fetch changes up to 9f8efa74d3f1cb9c957ee382c2b4feb2ae30:
>
>   docs: split the CODING_STYLE doc into distinct groups (2019-09-05 14:41:00 
> +0100)
>
> 
>
> * Merges HACKING into CODING_STYLE
> * Converts README and CODING_STYLE docs into RST syntax
> * Documents use of auto cleanup functions
>
> 


Applied, thanks.

Please update the changelog at https://wiki.qemu.org/ChangeLog/4.2
for any user-visible changes.

-- PMM



Re: [Qemu-devel] [RFC v3 PATCH 44/45] multi-process: add the concept description to docs/devel/qemu-multiprocess

2019-09-05 Thread Elena Ufimtseva
On Thu, Sep 5, 2019 at 3:19 AM Peter Maydell 
wrote:

> On Tue, 3 Sep 2019 at 22:19, Jagannathan Raman 
> wrote:
> >
> > From: John G Johnson 
> >
> > Signed-off-by: John G Johnson 
> > Signed-off-by: Elena Ufimtseva 
> > Signed-off-by: Jagannathan Raman 
> > ---
> >  v2 -> v3:
> >- Updated with latest design of this project
> >
> >  docs/devel/qemu-multiprocess.txt | 627
> +++
> >  1 file changed, 627 insertions(+)
> >  create mode 100644 docs/devel/qemu-multiprocess.txt
>
> Hi; you can ignore this review comment until there's more
> consensus on whether we want to take this patch series, but
> new documents in docs/ should be in RST format and included
> in the relevant contents page (here docs/devel/index.rst),
> please.
>
> thanks
> -- PMM
>
> Thanks Peter, will change this.

-- 
Elena


Re: [Qemu-devel] [RFC v3 PATCH 41/45] multi-process/mon: trim HMP command set for remote storage processes

2019-09-05 Thread Dr. David Alan Gilbert
* Jag Raman (jag.ra...@oracle.com) wrote:
> 
> 
> On 9/4/2019 4:56 AM, Dr. David Alan Gilbert wrote:
> > * Jagannathan Raman (jag.ra...@oracle.com) wrote:
> > > Trim down the list of HMP commands available for storage class of
> > > remote processes.
> > > 
> > > Signed-off-by: Elena Ufimtseva 
> > > Signed-off-by: John G Johnson 
> > > Signed-off-by: Jagannathan Raman 
> > > ---
> > >   New patch in v3
> > > 
> > >   Makefile.objs  |   2 +
> > >   Makefile.target|  14 +-
> > >   hmp-scsi-commands-info.hx  | 167 
> > >   hmp-scsi-commands.hx   | 384 
> > > +
> > >   monitor/misc.c |  84 +-
> > >   monitor/monitor-internal.h |  38 +
> > >   qom/Makefile.objs  |   2 +-
> > >   7 files changed, 651 insertions(+), 40 deletions(-)
> > >   create mode 100644 hmp-scsi-commands-info.hx
> > >   create mode 100644 hmp-scsi-commands.hx
> > > 
> > > diff --git a/Makefile.objs b/Makefile.objs
> > > index 04af900..11cd7be 100644
> > > --- a/Makefile.objs
> > > +++ b/Makefile.objs
> > > @@ -45,6 +45,8 @@ remote-pci-obj-$(CONFIG_MPQEMU) += iothread.o
> > >   remote-lsi-obj-$(CONFIG_MPQEMU) += hw/
> > >   remote-lsi-obj-$(CONFIG_MPQEMU) += ui/
> > > +remote-lsi-obj-$(CONFIG_MPQEMU) += device-hotplug.o
> > > +
> > >   ###
> > >   # crypto-obj-y is code used by both qemu system emulation and qemu-img
> > > diff --git a/Makefile.target b/Makefile.target
> > > index 0ca832f..00a4b85 100644
> > > --- a/Makefile.target
> > > +++ b/Makefile.target
> > > @@ -210,6 +210,10 @@ endif
> > >   generated-files-y += hmp-commands.h hmp-commands-info.h
> > >   generated-files-y += config-devices.h
> > > +ifdef CONFIG_MPQEMU
> > > +generated-files-y += hmp-scsi-commands.h hmp-scsi-commands-info.h
> > > +endif
> > > +
> > >   endif # CONFIG_SOFTMMU
> > >   dummy := $(call unnest-vars,,obj-y)
> > > @@ -294,10 +298,18 @@ hmp-commands.h: $(SRC_PATH)/hmp-commands.hx 
> > > $(SRC_PATH)/scripts/hxtool
> > >   hmp-commands-info.h: $(SRC_PATH)/hmp-commands-info.hx 
> > > $(SRC_PATH)/scripts/hxtool
> > >   $(call quiet-command,sh $(SRC_PATH)/scripts/hxtool -h < $< > 
> > > $@,"GEN","$(TARGET_DIR)$@")
> > > +ifdef CONFIG_MPQEMU
> > > +hmp-scsi-commands.h: $(SRC_PATH)/hmp-scsi-commands.hx 
> > > $(SRC_PATH)/scripts/hxtool
> > > + $(call quiet-command,sh $(SRC_PATH)/scripts/hxtool -h < $< > 
> > > $@,"GEN","$(TARGET_DIR)$@")
> > > +
> > > +hmp-scsi-commands-info.h: $(SRC_PATH)/hmp-scsi-commands-info.hx 
> > > $(SRC_PATH)/scripts/hxtool
> > > + $(call quiet-command,sh $(SRC_PATH)/scripts/hxtool -h < $< > 
> > > $@,"GEN","$(TARGET_DIR)$@")
> > > +endif
> > > +
> > >   clean: clean-target
> > >   rm -f *.a *~ $(PROGS)
> > >   rm -f $(shell find . -name '*.[od]')
> > > - rm -f hmp-commands.h gdbstub-xml.c
> > > + rm -f hmp-commands.h gdbstub-xml.c hmp-scsi-commands.h 
> > > hmp-scsi-commands-info.h
> > >   rm -f trace/generated-helpers.c 
> > > trace/generated-helpers.c-timestamp
> > >   ifdef CONFIG_TRACE_SYSTEMTAP
> > >   rm -f *.stp
> > > diff --git a/hmp-scsi-commands-info.hx b/hmp-scsi-commands-info.hx
> > > new file mode 100644
> > > index 000..315a445
> > > --- /dev/null
> > > +++ b/hmp-scsi-commands-info.hx
> > > @@ -0,0 +1,167 @@
> > > +HXCOMM Use DEFHEADING() to define headings in both help text and texi
> > > +HXCOMM Text between STEXI and ETEXI are copied to texi version and
> > > +HXCOMM discarded from C version
> > > +HXCOMM DEF(command, args, callback, arg_string, help) is used to 
> > > construct
> > > +HXCOMM monitor info commands
> > > +HXCOMM HXCOMM can be used for comments, discarded from both texi and C
> > > +
> > > +STEXI
> > > +@table @option
> > > +@item info @var{subcommand}
> > > +@findex info
> > > +Show various information about the system state.
> > > +@table @option
> > > +ETEXI
> > > +
> > > +{
> > > +.name   = "version",
> > > +.args_type  = "",
> > > +.params = "",
> > > +.help   = "show the version of QEMU",
> > > +.cmd= hmp_info_version,
> > > +.flags  = "p",
> > > +},
> > > +
> > > +STEXI
> > > +@item info version
> > > +@findex info version
> > > +Show the version of QEMU.
> > > +ETEXI
> > 
> > It feels like you need a way to share this stuff without copying it;
> > 'info version' isn't really a scsi specific command!
> > One idea is you could add a new field, e.g.
> > 
> >   .subcommands = "scsi,somethingelse"
> > 
> > and then you process it to pick that up?
> 
> What do you think about breaking up hmp-commands-info.hx into smaller
> files based on the types of devices it applies to - for example,
> storage, network, console, etc..? We could then include the generated
> file based on the device type.

Yes that makes sense; however the question is whether the things your
programs need split so neatly.

Da

Re: [Qemu-devel] [PATCH v2] riscv: sifive_test: Add reset functionality

2019-09-05 Thread Bin Meng
Hi Palmer,

On Thu, Sep 5, 2019 at 11:55 PM Bin Meng  wrote:
>
> This adds a reset opcode for sifive_test device to trigger a system
> reset for testing purpose.
>
> Signed-off-by: Bin Meng 
> Reviewed-by: Palmer Dabbelt 
>
> ---
>
> Changes in v2:
> - fix build error in the "for-master" branch of Palmer's RISC-V repo
>   that was rebased on QEMU master
>
>  hw/riscv/sifive_test.c | 4 
>  include/hw/riscv/sifive_test.h | 3 ++-
>  2 files changed, 6 insertions(+), 1 deletion(-)
>

Please drop the already applied v1 patch in your "for-master" branch
and apply this v2.

After you rebased the "for-master' branch, this patch no longer build
any more due to changes in QEMU master.

Regards,
Bin



[Qemu-devel] [PATCH v2] riscv: sifive_test: Add reset functionality

2019-09-05 Thread Bin Meng
This adds a reset opcode for sifive_test device to trigger a system
reset for testing purpose.

Signed-off-by: Bin Meng 
Reviewed-by: Palmer Dabbelt 

---

Changes in v2:
- fix build error in the "for-master" branch of Palmer's RISC-V repo
  that was rebased on QEMU master

 hw/riscv/sifive_test.c | 4 
 include/hw/riscv/sifive_test.h | 3 ++-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/hw/riscv/sifive_test.c b/hw/riscv/sifive_test.c
index afbb3aa..3557e16 100644
--- a/hw/riscv/sifive_test.c
+++ b/hw/riscv/sifive_test.c
@@ -22,6 +22,7 @@
 #include "hw/hw.h"
 #include "hw/sysbus.h"
 #include "qemu/module.h"
+#include "sysemu/runstate.h"
 #include "target/riscv/cpu.h"
 #include "hw/hw.h"
 #include "hw/riscv/sifive_test.h"
@@ -42,6 +43,9 @@ static void sifive_test_write(void *opaque, hwaddr addr,
 exit(code);
 case FINISHER_PASS:
 exit(0);
+case FINISHER_RESET:
+qemu_system_reset_request(SHUTDOWN_CAUSE_GUEST_RESET);
+return;
 default:
 break;
 }
diff --git a/include/hw/riscv/sifive_test.h b/include/hw/riscv/sifive_test.h
index 3a603a6..1ec416a 100644
--- a/include/hw/riscv/sifive_test.h
+++ b/include/hw/riscv/sifive_test.h
@@ -36,7 +36,8 @@ typedef struct SiFiveTestState {
 
 enum {
 FINISHER_FAIL = 0x,
-FINISHER_PASS = 0x
+FINISHER_PASS = 0x,
+FINISHER_RESET = 0x
 };
 
 DeviceState *sifive_test_create(hwaddr addr);
-- 
2.7.4




Re: [Qemu-devel] [RFC v3 PATCH 41/45] multi-process/mon: trim HMP command set for remote storage processes

2019-09-05 Thread Jag Raman




On 9/4/2019 4:56 AM, Dr. David Alan Gilbert wrote:

* Jagannathan Raman (jag.ra...@oracle.com) wrote:

Trim down the list of HMP commands available for storage class of
remote processes.

Signed-off-by: Elena Ufimtseva 
Signed-off-by: John G Johnson 
Signed-off-by: Jagannathan Raman 
---
  New patch in v3

  Makefile.objs  |   2 +
  Makefile.target|  14 +-
  hmp-scsi-commands-info.hx  | 167 
  hmp-scsi-commands.hx   | 384 +
  monitor/misc.c |  84 +-
  monitor/monitor-internal.h |  38 +
  qom/Makefile.objs  |   2 +-
  7 files changed, 651 insertions(+), 40 deletions(-)
  create mode 100644 hmp-scsi-commands-info.hx
  create mode 100644 hmp-scsi-commands.hx

diff --git a/Makefile.objs b/Makefile.objs
index 04af900..11cd7be 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -45,6 +45,8 @@ remote-pci-obj-$(CONFIG_MPQEMU) += iothread.o
  remote-lsi-obj-$(CONFIG_MPQEMU) += hw/
  remote-lsi-obj-$(CONFIG_MPQEMU) += ui/
  
+remote-lsi-obj-$(CONFIG_MPQEMU) += device-hotplug.o

+
  ###
  # crypto-obj-y is code used by both qemu system emulation and qemu-img
  
diff --git a/Makefile.target b/Makefile.target

index 0ca832f..00a4b85 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -210,6 +210,10 @@ endif
  generated-files-y += hmp-commands.h hmp-commands-info.h
  generated-files-y += config-devices.h
  
+ifdef CONFIG_MPQEMU

+generated-files-y += hmp-scsi-commands.h hmp-scsi-commands-info.h
+endif
+
  endif # CONFIG_SOFTMMU
  
  dummy := $(call unnest-vars,,obj-y)

@@ -294,10 +298,18 @@ hmp-commands.h: $(SRC_PATH)/hmp-commands.hx 
$(SRC_PATH)/scripts/hxtool
  hmp-commands-info.h: $(SRC_PATH)/hmp-commands-info.hx 
$(SRC_PATH)/scripts/hxtool
$(call quiet-command,sh $(SRC_PATH)/scripts/hxtool -h < $< > 
$@,"GEN","$(TARGET_DIR)$@")
  
+ifdef CONFIG_MPQEMU

+hmp-scsi-commands.h: $(SRC_PATH)/hmp-scsi-commands.hx 
$(SRC_PATH)/scripts/hxtool
+   $(call quiet-command,sh $(SRC_PATH)/scripts/hxtool -h < $< > 
$@,"GEN","$(TARGET_DIR)$@")
+
+hmp-scsi-commands-info.h: $(SRC_PATH)/hmp-scsi-commands-info.hx 
$(SRC_PATH)/scripts/hxtool
+   $(call quiet-command,sh $(SRC_PATH)/scripts/hxtool -h < $< > 
$@,"GEN","$(TARGET_DIR)$@")
+endif
+
  clean: clean-target
rm -f *.a *~ $(PROGS)
rm -f $(shell find . -name '*.[od]')
-   rm -f hmp-commands.h gdbstub-xml.c
+   rm -f hmp-commands.h gdbstub-xml.c hmp-scsi-commands.h 
hmp-scsi-commands-info.h
rm -f trace/generated-helpers.c trace/generated-helpers.c-timestamp
  ifdef CONFIG_TRACE_SYSTEMTAP
rm -f *.stp
diff --git a/hmp-scsi-commands-info.hx b/hmp-scsi-commands-info.hx
new file mode 100644
index 000..315a445
--- /dev/null
+++ b/hmp-scsi-commands-info.hx
@@ -0,0 +1,167 @@
+HXCOMM Use DEFHEADING() to define headings in both help text and texi
+HXCOMM Text between STEXI and ETEXI are copied to texi version and
+HXCOMM discarded from C version
+HXCOMM DEF(command, args, callback, arg_string, help) is used to construct
+HXCOMM monitor info commands
+HXCOMM HXCOMM can be used for comments, discarded from both texi and C
+
+STEXI
+@table @option
+@item info @var{subcommand}
+@findex info
+Show various information about the system state.
+@table @option
+ETEXI
+
+{
+.name   = "version",
+.args_type  = "",
+.params = "",
+.help   = "show the version of QEMU",
+.cmd= hmp_info_version,
+.flags  = "p",
+},
+
+STEXI
+@item info version
+@findex info version
+Show the version of QEMU.
+ETEXI


It feels like you need a way to share this stuff without copying it;
'info version' isn't really a scsi specific command!
One idea is you could add a new field, e.g.

  .subcommands = "scsi,somethingelse"

and then you process it to pick that up?


What do you think about breaking up hmp-commands-info.hx into smaller
files based on the types of devices it applies to - for example,
storage, network, console, etc..? We could then include the generated
file based on the device type.

Thanks!
--
Jag






diff --git a/monitor/misc.c b/monitor/misc.c
index 00338c0..4914f46 100644
--- a/monitor/misc.c
+++ b/monitor/misc.c
@@ -176,12 +176,12 @@ int hmp_compare_cmd(const char *name, const char *list)
  return 0;
  }
  
-static void do_help_cmd(Monitor *mon, const QDict *qdict)

+void do_help_cmd(Monitor *mon, const QDict *qdict)


If you're unstatic'ing things that don't have hmp in the name then you
need to add it, i.e. hmp_do_help_cmd.

Dave


  {
  help_cmd(mon, qdict_get_try_str(qdict, "name"));
  }
  
-static void hmp_trace_event(Monitor *mon, const QDict *qdict)

+void hmp_trace_event(Monitor *mon, const QDict *qdict)
  {
  const char *tp_name = qdict_get_str(qdict, "name");
  bool new_state = qdict_get_bool(qdict, "option");
@@ -225,7 +225,7 @@ static void hmp_trace

Re: [Qemu-devel] [Qemu-arm] [PATCH v5 17/17] target/arm: Rely on hflags correct in cpu_get_tb_cpu_state

2019-09-05 Thread Alex Bennée


Laurent Desnogues  writes:

> On Thu, Sep 5, 2019 at 5:24 PM Alex Bennée  wrote:
>>
>>
>> Richard Henderson  writes:
>>
>> > This is the payoff.
>> >
>> > From perf record -g data of ubuntu 18 boot and shutdown:
>> >
>> > BEFORE:
>> >
>> > -   23.02% 2.82%  qemu-system-aar  [.] helper_lookup_tb_ptr
>> >- 20.22% helper_lookup_tb_ptr
>> >   + 10.05% tb_htable_lookup
>> >   - 9.13% cpu_get_tb_cpu_state
>> >3.20% aa64_va_parameters_both
>> >0.55% fp_exception_el
>> >
>> > -   11.66% 4.74%  qemu-system-aar  [.] cpu_get_tb_cpu_state
>> >- 6.96% cpu_get_tb_cpu_state
>> > 3.63% aa64_va_parameters_both
>> > 0.60% fp_exception_el
>> > 0.53% sve_exception_el
>> >
>> > AFTER:
>> >
>> > -   16.40% 3.40%  qemu-system-aar  [.] helper_lookup_tb_ptr
>> >- 13.03% helper_lookup_tb_ptr
>> >   + 11.19% tb_htable_lookup
>> > 0.55% cpu_get_tb_cpu_state
>> >
>> >  0.98% 0.71%  qemu-system-aar  [.] cpu_get_tb_cpu_state
>> >
>> >  0.87% 0.24%  qemu-system-aar  [.] rebuild_hflags_a64
>> >
>> > Before, helper_lookup_tb_ptr is the second hottest function in the
>> > application, consuming almost a quarter of the runtime.  Within the
>> > entire execution, cpu_get_tb_cpu_state consumes about 12%.
>> >
>> > After, helper_lookup_tb_ptr has dropped to the fourth hottest function,
>> > with consumption dropping to a sixth of the runtime.  Within the
>> > entire execution, cpu_get_tb_cpu_state has dropped below 1%, and the
>> > supporting function to rebuild hflags also consumes about 1%.
>> >
>> > Assertions are retained for --enable-debug-tcg.
>> >
>> > Tested-by: Alex Bennée 
>>
>> Hmm something must have been missed for M-profile because:
>>
>>   make run-tcg-tests-arm-softmmu V=1
>>
>> Leads to:
>>
>>   timeout 15  
>> /home/alex/lsrc/qemu.git/builds/all.debug/arm-softmmu/qemu-system-arm 
>> -monitor none -display none -chardev 
>> file,path=test-armv6m-undef.out,id=output -semihosting -M microbit -kernel 
>> test-armv6m-undef
>>   qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)
>>
>>   R00= R01= R02= R03=
>>   R04= R05= R06= R07=
>>   R08= R09= R10= R11=
>>   R12= R13=20003fe0 R14=fff9 R15=00c0
>>   XPSR=4103 -Z-- T handler
>>   FPSCR: 
>>   timeout: the monitored command dumped core
>>
>> But annoyingly not shown up by the debug-tcg verification. The commit
>> before works fine.
>
> There's a typo in the patch:  that should not be CONFIG_TCG_DEBUG but
> CONFIG_DEBUG_TCG.  With this you should see the assert fire.

Indeed:

  cpu_get_tb_cpu_state: cache 11c0 <> 312000c0

I wish there was an assert form that would handily print out the
difference between the two values. I wonder if glib has one...

>
> I let Richard know that there's an issue with the handling of CPSR E
> flag (BE_DATA in hflags).  I don't know if that applies to your test.
>
> Thanks,
>
> Laurent
>
>> > Reviewed-by: Alex Bennée 
>> > Signed-off-by: Richard Henderson 
>> > ---
>> > v2: Retain asserts for future debugging.
>> > ---
>> >  target/arm/helper.c | 9 ++---
>> >  1 file changed, 6 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/target/arm/helper.c b/target/arm/helper.c
>> > index d1bf71a260..5e4f996882 100644
>> > --- a/target/arm/helper.c
>> > +++ b/target/arm/helper.c
>> > @@ -11211,12 +11211,15 @@ void HELPER(rebuild_hflags_a64)(CPUARMState 
>> > *env, int el)
>> >  void cpu_get_tb_cpu_state(CPUARMState *env, target_ulong *pc,
>> >target_ulong *cs_base, uint32_t *pflags)
>> >  {
>> > -uint32_t flags, pstate_for_ss;
>> > +uint32_t flags = env->hflags;
>> > +uint32_t pstate_for_ss;
>> >
>> >  *cs_base = 0;
>> > -flags = rebuild_hflags_internal(env);
>> > +#ifdef CONFIG_TCG_DEBUG
>> > +assert(flags == rebuild_hflags_internal(env));
>> > +#endif
>> >
>> > -if (is_a64(env)) {
>> > +if (FIELD_EX32(flags, TBFLAG_ANY, AARCH64_STATE)) {
>> >  *pc = env->pc;
>> >  if (cpu_isar_feature(aa64_bti, env_archcpu(env))) {
>> >  flags = FIELD_DP32(flags, TBFLAG_A64, BTYPE, env->btype);
>>
>>
>> --
>> Alex Bennée
>>


--
Alex Bennée



[Qemu-devel] [PATCH] q35: lpc: allow to lock down 128K RAM at default SMBASE address

2019-09-05 Thread Igor Mammedov
lpc already has SMI negotiation feature, extend it by adding
optin ICH9_LPC_SMI_F_LOCKED_SMBASE_BIT to supported features.

Writing this bit into "etc/smi/requested-features" fw_cfg file,
tells QEMU to alias 0x3,128K RAM range into SMRAM address
space and mask this region from normal RAM address space
(reads return 0xff and writes are ignored, i.e. guest code
should be able to deal with not usable 0x3,128K RAM range
once ICH9_LPC_SMI_F_LOCKED_SMBASE_BIT is activated).

To make negotiated change effective, guest should read
"etc/smi/features-ok" fw_cfg file, which activates negotiated
features and locks down negotiating capabilities until hard reset.

Flow for initializing SMI handler on guest side:
 1. set SMI handler entry point at default SMBASE location
 2. check that host supports ICH9_LPC_SMI_F_LOCKED_SMBASE_BIT
in "etc/smi/supported-features" and set if supported set
it in "etc/smi/requested-features"
 3. read "etc/smi/features-ok", if returned value is 1
negotiated at step 2 features are activated successfully.

Signed-off-by: Igor Mammedov 
---
 include/hw/i386/ich9.h | 11 ++--
 hw/i386/pc.c   |  4 ++-
 hw/i386/pc_q35.c   |  3 ++-
 hw/isa/lpc_ich9.c  | 58 +-
 4 files changed, 71 insertions(+), 5 deletions(-)

diff --git a/include/hw/i386/ich9.h b/include/hw/i386/ich9.h
index 72e803f6e2..c28685b753 100644
--- a/include/hw/i386/ich9.h
+++ b/include/hw/i386/ich9.h
@@ -12,11 +12,14 @@
 #include "hw/acpi/acpi.h"
 #include "hw/acpi/ich9.h"
 #include "hw/pci/pci_bus.h"
+#include "qemu/units.h"
 
 void ich9_lpc_set_irq(void *opaque, int irq_num, int level);
 int ich9_lpc_map_irq(PCIDevice *pci_dev, int intx);
 PCIINTxRoute ich9_route_intx_pin_to_irq(void *opaque, int pirq_pin);
-void ich9_lpc_pm_init(PCIDevice *pci_lpc, bool smm_enabled);
+void ich9_lpc_pm_init(PCIDevice *pci_lpc, bool smm_enabled,
+  MemoryRegion *system_memory, MemoryRegion *ram,
+  MemoryRegion *smram);
 I2CBus *ich9_smb_init(PCIBus *bus, int devfn, uint32_t smb_io_base);
 
 void ich9_generate_smi(void);
@@ -71,6 +74,8 @@ typedef struct ICH9LPCState {
 uint8_t smi_features_ok;  /* guest-visible, read-only; selecting it
* triggers feature lockdown */
 uint64_t smi_negotiated_features; /* guest-invisible, host endian */
+MemoryRegion smbase_blackhole;
+MemoryRegion smbase_window;
 
 /* isa bus */
 ISABus *isa_bus;
@@ -248,5 +253,7 @@ typedef struct ICH9LPCState {
 
 /* bit positions used in fw_cfg SMI feature negotiation */
 #define ICH9_LPC_SMI_F_BROADCAST_BIT0
-
+#define ICH9_LPC_SMI_F_LOCKED_SMBASE_BIT1
+#define ICH9_LPC_SMBASE_ADDR0x3
+#define ICH9_LPC_SMBASE_RAM_SIZE(128 * KiB)
 #endif /* HW_ICH9_H */
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index c14ed86439..99a98303eb 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -119,7 +119,9 @@ struct hpet_fw_config hpet_cfg = {.count = UINT8_MAX};
 /* Physical Address of PVH entry point read from kernel ELF NOTE */
 static size_t pvh_start_addr;
 
-GlobalProperty pc_compat_4_1[] = {};
+GlobalProperty pc_compat_4_1[] = {
+{ "ICH9-LPC", "x-smi-locked-smbase", "off" },
+};
 const size_t pc_compat_4_1_len = G_N_ELEMENTS(pc_compat_4_1);
 
 GlobalProperty pc_compat_4_0[] = {};
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index d4e8a1cb9f..50462686a0 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -292,7 +292,8 @@ static void pc_q35_init(MachineState *machine)
  0xff0104);
 
 /* connect pm stuff to lpc */
-ich9_lpc_pm_init(lpc, pc_machine_is_smm_enabled(pcms));
+ich9_lpc_pm_init(lpc, pc_machine_is_smm_enabled(pcms), get_system_memory(),
+ram_memory, MEMORY_REGION(object_resolve_path("/machine/smram", 
NULL)));
 
 if (pcms->sata_enabled) {
 /* ahci and SATA device, for q35 1 ahci controller is built-in */
diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c
index 17c292e306..17a8cd1b51 100644
--- a/hw/isa/lpc_ich9.c
+++ b/hw/isa/lpc_ich9.c
@@ -359,6 +359,38 @@ static void ich9_set_sci(void *opaque, int irq_num, int 
level)
 }
 }
 
+static uint64_t smbase_blackhole_read(void *ptr, hwaddr reg, unsigned size)
+{
+return 0x;
+}
+
+static void smbase_blackhole_write(void *opaque, hwaddr addr, uint64_t val,
+   unsigned width)
+{
+/* nothing */
+}
+
+static const MemoryRegionOps smbase_blackhole_ops = {
+.read = smbase_blackhole_read,
+.write = smbase_blackhole_write,
+.endianness = DEVICE_NATIVE_ENDIAN,
+.valid.min_access_size = 1,
+.valid.max_access_size = 4,
+.impl.min_access_size = 4,
+.impl.max_access_size = 4,
+.endianness = DEVICE_LITTLE_ENDIAN,
+};
+
+static void ich9_lpc_smbase_locked_update(ICH9LPCState *lpc)
+{
+bool en = lpc->smi_negotiated_features & ICH9_LPC_SMI_F_LOCKED_SMBASE_BIT;
+
+m

Re: [Qemu-devel] [edk2-rfc] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF

2019-09-05 Thread Igor Mammedov
On Thu, 5 Sep 2019 15:08:31 +0200
Laszlo Ersek  wrote:

> On 09/04/19 11:52, Igor Mammedov wrote:
> 
> >  it could be stolen RAM + black hole like TSEG, assuming fw can live 
> > without RAM(0x3+128K) range
> >   (in this case fwcfg interface would only work for locking down the range)
> > 
> >  or
> > 
> >  we can actually have a dedicated SMRAM (like in my earlier RFC),
> >  in this case FW can use RAM(0x3+128K) when SMRAM isn't mapped into RAM 
> > address space
> >  (in this case fwcfg would be used to temporarily map SMRAM into normal RAM 
> > and unmap/lock
> >   after SMI relocation handler was initialized).
> > 
> > If possible I'd prefer a simpler TSEG like variant.  
> 
> I think TSEG-like behavior is between these two. That is, I believe we
> should have explicit open/close/lock operations. And, when the range is
> closed (meaning, closed+unlocked, or closed+locked), then the black hole
> should take effect for code that's not running in SMM.
> 
> Put differently, its like the second choice, except the range never
> appears as normal RAM. "When SMRAM isn't mapped into RAM address space",
> then the address range shows "nothing" (black hole).
I guess we at point where patch is better then words, I'll send one as reply 
here shortly.
I've just implemented subset of above (opened, closed+locked).


> Regarding "fw can live without RAM(0x3+128K) range" -- do you mean
> whether the firmware could use another RAM area for fw_cfg DMA?
> 
> If that's the question, then I wouldn't worry about it. I'd remove the
> 0x3+128K range from the memory map, so the fw_cfg stuff (or anything
> else) would never allocate memory from the range. It's much more
> concerning to me however how the SMM infrastructure would deal with a
> hole in the memory map right there.
I didn't mean fwcfg in this context, what I meant if firmware were able
to avoid using RAM(0x3+128K) range (since it becomes unusable after 
locking).
Looks like you just answered it here




Re: [Qemu-devel] [PATCH v6 0/4] virtio/block: handle zoned backing devices

2019-09-05 Thread Stefan Hajnoczi
On Wed, Sep 04, 2019 at 05:00:56PM -0400, Dmitry Fomichev wrote:
> Currently, attaching zoned block devices (i.e., storage devices
> compliant to ZAC/ZBC standards) using several virtio methods doesn't
> work properly as zoned devices appear as regular block devices at the
> guest. This may cause unexpected i/o errors and, potentially, some
> data corruption.
> 
> To be more precise, attaching a zoned device via virtio-pci-blk,
> virtio-scsi-pci/scsi-disk or virtio-scsi-pci/scsi-hd demonstrates the
> above behavior. The virtio-scsi-pci/scsi-block method works with a
> recent patch. The virtio-scsi-pci/scsi-generic method also appears to
> handle zoned devices without problems.
> 
> This patch set adds code to check if the backing device that is being
> opened is a zoned Host Managed device. If this is the case, the patch
> prohibits attaching such device for all use cases lacking proper
> zoned support.
> 
> Host Aware zoned block devices are designed to work as regular block
> devices at a guest system that does not support ZBD. Therefore, this
> patch set doesn't prohibit attachment of Host Aware devices.
> 
> Considering that there is still a couple of different working ways
> to attach a ZBD, this patch set provides a reasonable short-term
> solution for this problem.
> 
> ZBD support for virtio-scsi-pci/scsi-disk and virtio-scsi-pci/scsi-hd
> does not seem as necessary. Users will be expected to attach zoned
> block devices via virtio-scsi-pci/scsi-block instead.
> 
> This patch set contains some Linux-specific code. This code is
> necessary to obtain Zoned Block Device model value from Linux sysfs.
> 
> History:
> 
> v1 -> v2:
> - rework code to be permission-based
> - always allow Host Aware devices to be attached
> - add fix for Host Aware attachments aka RCAP output snoop
> 
> v2 -> v3:
> - drop the patch for RCAP output snoop - merged separately
> 
> v3 -> v4:
> - rebase to the current code
> 
> v4 -> v5:
> - avoid checkpatch warning
> 
> v5 -> v6:
> - address review comments from Stefan Hajnoczi
> 
> Dmitry Fomichev (4):
>   block: Add zoned device model property
>   raw: Recognize zoned backing devices
>   block/ide/scsi: Set BLK_PERM_SUPPORT_HM_ZONED
>   raw: Don't open ZBDs if backend can't handle them
> 
>  block.c   | 15 +++
>  block/file-posix.c| 89 +--
>  block/io.c|  5 +++
>  hw/block/block.c  |  8 +++-
>  hw/block/fdc.c|  5 ++-
>  hw/block/nvme.c   |  2 +-
>  hw/block/virtio-blk.c |  2 +-
>  hw/block/xen-block.c  |  2 +-
>  hw/ide/qdev.c |  2 +-
>  hw/scsi/scsi-disk.c   | 13 +++---
>  hw/scsi/scsi-generic.c|  2 +-
>  hw/usb/dev-storage.c  |  2 +-
>  include/block/block.h | 19 -
>  include/block/block_int.h |  3 ++
>  include/hw/block/block.h  |  3 +-
>  15 files changed, 141 insertions(+), 31 deletions(-)
> 
> -- 
> 2.21.0
> 

Reviewed-by: Stefan Hajnoczi 


signature.asc
Description: PGP signature


Re: [Qemu-devel] [Qemu-arm] [PATCH v5 17/17] target/arm: Rely on hflags correct in cpu_get_tb_cpu_state

2019-09-05 Thread Laurent Desnogues
On Thu, Sep 5, 2019 at 5:24 PM Alex Bennée  wrote:
>
>
> Richard Henderson  writes:
>
> > This is the payoff.
> >
> > From perf record -g data of ubuntu 18 boot and shutdown:
> >
> > BEFORE:
> >
> > -   23.02% 2.82%  qemu-system-aar  [.] helper_lookup_tb_ptr
> >- 20.22% helper_lookup_tb_ptr
> >   + 10.05% tb_htable_lookup
> >   - 9.13% cpu_get_tb_cpu_state
> >3.20% aa64_va_parameters_both
> >0.55% fp_exception_el
> >
> > -   11.66% 4.74%  qemu-system-aar  [.] cpu_get_tb_cpu_state
> >- 6.96% cpu_get_tb_cpu_state
> > 3.63% aa64_va_parameters_both
> > 0.60% fp_exception_el
> > 0.53% sve_exception_el
> >
> > AFTER:
> >
> > -   16.40% 3.40%  qemu-system-aar  [.] helper_lookup_tb_ptr
> >- 13.03% helper_lookup_tb_ptr
> >   + 11.19% tb_htable_lookup
> > 0.55% cpu_get_tb_cpu_state
> >
> >  0.98% 0.71%  qemu-system-aar  [.] cpu_get_tb_cpu_state
> >
> >  0.87% 0.24%  qemu-system-aar  [.] rebuild_hflags_a64
> >
> > Before, helper_lookup_tb_ptr is the second hottest function in the
> > application, consuming almost a quarter of the runtime.  Within the
> > entire execution, cpu_get_tb_cpu_state consumes about 12%.
> >
> > After, helper_lookup_tb_ptr has dropped to the fourth hottest function,
> > with consumption dropping to a sixth of the runtime.  Within the
> > entire execution, cpu_get_tb_cpu_state has dropped below 1%, and the
> > supporting function to rebuild hflags also consumes about 1%.
> >
> > Assertions are retained for --enable-debug-tcg.
> >
> > Tested-by: Alex Bennée 
>
> Hmm something must have been missed for M-profile because:
>
>   make run-tcg-tests-arm-softmmu V=1
>
> Leads to:
>
>   timeout 15  
> /home/alex/lsrc/qemu.git/builds/all.debug/arm-softmmu/qemu-system-arm 
> -monitor none -display none -chardev 
> file,path=test-armv6m-undef.out,id=output -semihosting -M microbit -kernel 
> test-armv6m-undef
>   qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)
>
>   R00= R01= R02= R03=
>   R04= R05= R06= R07=
>   R08= R09= R10= R11=
>   R12= R13=20003fe0 R14=fff9 R15=00c0
>   XPSR=4103 -Z-- T handler
>   FPSCR: 
>   timeout: the monitored command dumped core
>
> But annoyingly not shown up by the debug-tcg verification. The commit
> before works fine.

There's a typo in the patch:  that should not be CONFIG_TCG_DEBUG but
CONFIG_DEBUG_TCG.  With this you should see the assert fire.

I let Richard know that there's an issue with the handling of CPSR E
flag (BE_DATA in hflags).  I don't know if that applies to your test.

Thanks,

Laurent

> > Reviewed-by: Alex Bennée 
> > Signed-off-by: Richard Henderson 
> > ---
> > v2: Retain asserts for future debugging.
> > ---
> >  target/arm/helper.c | 9 ++---
> >  1 file changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/target/arm/helper.c b/target/arm/helper.c
> > index d1bf71a260..5e4f996882 100644
> > --- a/target/arm/helper.c
> > +++ b/target/arm/helper.c
> > @@ -11211,12 +11211,15 @@ void HELPER(rebuild_hflags_a64)(CPUARMState *env, 
> > int el)
> >  void cpu_get_tb_cpu_state(CPUARMState *env, target_ulong *pc,
> >target_ulong *cs_base, uint32_t *pflags)
> >  {
> > -uint32_t flags, pstate_for_ss;
> > +uint32_t flags = env->hflags;
> > +uint32_t pstate_for_ss;
> >
> >  *cs_base = 0;
> > -flags = rebuild_hflags_internal(env);
> > +#ifdef CONFIG_TCG_DEBUG
> > +assert(flags == rebuild_hflags_internal(env));
> > +#endif
> >
> > -if (is_a64(env)) {
> > +if (FIELD_EX32(flags, TBFLAG_ANY, AARCH64_STATE)) {
> >  *pc = env->pc;
> >  if (cpu_isar_feature(aa64_bti, env_archcpu(env))) {
> >  flags = FIELD_DP32(flags, TBFLAG_A64, BTYPE, env->btype);
>
>
> --
> Alex Bennée
>



[Qemu-devel] [PULL v2 9/9] gitlab-ci.yml: Install libattr-devel and libcap-devel to test virtio-9p

2019-09-05 Thread Thomas Huth
So far the gitlab-ci was not testing virtio-9p yet, since we did not
install libattr-devel and libcap-devel in any of the pipelines. Do
it now to get some more test coverage.

Message-Id: <20190905111729.1197-1-th...@redhat.com>
Acked-by: Greg Kurz 
Signed-off-by: Thomas Huth 
---
 .gitlab-ci.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index cd4c03372b..ed8067f5cf 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -59,7 +59,7 @@ build-user:
 
 build-clang:
  script:
- - apt-get install -y -qq clang libsdl2-dev
+ - apt-get install -y -qq clang libsdl2-dev libattr1-dev libcap-dev
   xfslibs-dev libiscsi-dev libnfs-dev libseccomp-dev gnutls-dev librbd-dev
  - ./configure --cc=clang --cxx=clang++ --enable-werror
   --target-list="alpha-softmmu arm-softmmu m68k-softmmu mips64-softmmu
-- 
2.18.1




Re: [Qemu-devel] [PULL 0/4] Docs patches

2019-09-05 Thread Peter Maydell
On Thu, 5 Sep 2019 at 14:45, Daniel P. Berrangé  wrote:
>
> The following changes since commit 500efcfcf0fe2e0dae1d25637a13435ce7b6e421:
>
>   Merge remote-tracking branch 'remotes/rth/tags/pull-or1k-20190904' into 
> staging (2019-09-05 09:33:01 +0100)
>
> are available in the Git repository at:
>
>   https://github.com/berrange/qemu tags/docs-pull-request
>
> for you to fetch changes up to 9f8efa74d3f1cb9c957ee382c2b4feb2ae30:
>
>   docs: split the CODING_STYLE doc into distinct groups (2019-09-05 14:41:00 
> +0100)
>
> 
>
> * Merges HACKING into CODING_STYLE
> * Converts README and CODING_STYLE docs into RST syntax
> * Documents use of auto cleanup functions
>
> 
>
> Daniel P. Berrangé (4):
>   docs: convert README, CODING_STYLE and HACKING to RST syntax
>   docs: merge HACKING.rst contents into CODING_STYLE.rst
>   docs: document use of automatic cleanup functions in glib
>   docs: split the CODING_STYLE doc into distinct groups
>
>  CODING_STYLE  | 216 --
>  CODING_STYLE.rst  | 641 ++
>  HACKING   | 257 -
>  README => README.rst  |  47 ++--
>  scripts/checkpatch.pl |   2 +-

I'm going to apply this, but something I thought of looking at
the diffstat: should some or all of this be in the docs/devel
manual rather than free-floating rst files in the root directory?

thanks
-- PMM



[Qemu-devel] [PULL v2 0/9] qtests and misc patches

2019-09-05 Thread Thomas Huth
 Hi Peter,

the following changes since commit 500efcfcf0fe2e0dae1d25637a13435ce7b6e421:

  Merge remote-tracking branch 'remotes/rth/tags/pull-or1k-20190904' into 
staging (2019-09-05 09:33:01 +0100)

are available in the Git repository at:

  https://gitlab.com/huth/qemu.git tags/pull-request-2019-09-05-v2

for you to fetch changes up to e7dc804ef0d7cac9ac8b4a1324ab7dbfafb55704:

  gitlab-ci.yml: Install libattr-devel and libcap-devel to test virtio-9p 
(2019-09-05 16:00:01 +0200)


- Make the core libqtest library independent from global_qtest
- Clean up docs from hard-coded qemu-system-* names
- Install libattr-dev and libcap-dev in gitlab-ci to test virtio-9p


Thomas Huth (9):
  tests/migration: Do not use functions anymore that rely on global_qtest
  tests/libqos/e1000e: Make e1000e libqos functions independent from 
global_qtest
  tests/libqos: Replace clock_step with qtest_clock_step in virtio code
  tests: Remove unnecessary global_qtest references
  tests/libqtest: Move global_test wrapper function into a separate header
  tests/libqtest: Use libqtest-single.h in tests that require global_qtest
  tests/vm: Take the J=x setting into account for the vm-boot-ssh targets, 
too
  qemu-doc: Do not hard-code the name of the QEMU binary
  gitlab-ci.yml: Install libattr-devel and libcap-devel to test virtio-9p

 .gitlab-ci.yml|   2 +-
 MAINTAINERS   |   2 +-
 docs/qemu-block-drivers.texi  |  72 +-
 docs/qemu-cpu-models.texi |  10 +-
 qemu-doc.texi |  81 +--
 qemu-options.hx   | 128 -
 tests/ahci-test.c |   1 -
 tests/bios-tables-test.c  |   1 -
 tests/cpu-plug-test.c |   2 +-
 tests/display-vga-test.c  |   2 +-
 tests/e1000e-test.c   |   2 +-
 tests/fdc-test.c  |   2 +-
 tests/i440fx-test.c   |   2 +-
 tests/i82801b11-test.c|   2 +-
 tests/intel-hda-test.c|   2 +-
 tests/ioh3420-test.c  |   2 +-
 tests/ipmi-kcs-test.c |   3 +-
 tests/ivshmem-test.c  |   3 -
 tests/libqos/e1000e.c |  16 ++-
 tests/libqos/virtio-mmio.c|  14 +-
 tests/libqos/virtio-pci.c |  14 +-
 tests/libqos/virtio.c |  20 +--
 tests/libqos/virtio.h |   6 +-
 tests/libqtest-single.h   | 315 ++
 tests/libqtest.c  |  13 --
 tests/libqtest.h  | 289 --
 tests/m25p80-test.c   |   2 +-
 tests/migration-test.c|   6 +-
 tests/qos-test.c  |   2 +-
 tests/rtas-test.c |   1 -
 tests/rtc-test.c  |   2 +-
 tests/rtl8139-test.c  |   2 +-
 tests/test-arm-mptimer.c  |   2 +-
 tests/test-netfilter.c|   2 +-
 tests/test-x86-cpuid-compat.c |   2 +-
 tests/tmp105-test.c   |   2 +-
 tests/tpm-crb-test.c  |   2 +-
 tests/tpm-tests.c |   2 +-
 tests/tpm-tis-test.c  |   2 +-
 tests/usb-hcd-ohci-test.c |   2 +-
 tests/usb-hcd-uhci-test.c |   2 +-
 tests/usb-hcd-xhci-test.c |   2 +-
 tests/vhost-user-test.c   |   2 +-
 tests/virtio-9p-test.c|   2 +-
 tests/virtio-blk-test.c   |   5 +-
 tests/virtio-ccw-test.c   |   2 +-
 tests/virtio-net-test.c   |   2 +-
 tests/virtio-scsi-test.c  |   2 +-
 tests/virtio-serial-test.c|   2 +-
 tests/vm/Makefile.include |   1 +
 50 files changed, 548 insertions(+), 511 deletions(-)
 create mode 100644 tests/libqtest-single.h



[Qemu-devel] [PULL v2 6/9] tests/libqtest: Use libqtest-single.h in tests that require global_qtest

2019-09-05 Thread Thomas Huth
Tests that require global_qtest or the related wrapper functions now
use the libqtest-single.h header that is dedicated for everything
related to global_qtest. The core libqtest.c and libqtest.h files are
now completely indepedent from global_qtest, so that the core library
is now not depending on a global state anymore.

Message-Id: <20190904130047.25808-7-th...@redhat.com>
Reviewed-by: Eric Blake 
Reviewed-by: Stefan Hajnoczi 
Signed-off-by: Thomas Huth 
---
 tests/cpu-plug-test.c | 2 +-
 tests/display-vga-test.c  | 2 +-
 tests/e1000e-test.c   | 2 +-
 tests/fdc-test.c  | 2 +-
 tests/i440fx-test.c   | 2 +-
 tests/i82801b11-test.c| 2 +-
 tests/intel-hda-test.c| 2 +-
 tests/ioh3420-test.c  | 2 +-
 tests/ipmi-kcs-test.c | 3 +--
 tests/libqtest-single.h   | 4 
 tests/libqtest.c  | 2 --
 tests/libqtest.h  | 4 
 tests/m25p80-test.c   | 2 +-
 tests/qos-test.c  | 2 +-
 tests/rtc-test.c  | 2 +-
 tests/rtl8139-test.c  | 2 +-
 tests/test-arm-mptimer.c  | 2 +-
 tests/test-netfilter.c| 2 +-
 tests/test-x86-cpuid-compat.c | 2 +-
 tests/tmp105-test.c   | 2 +-
 tests/tpm-crb-test.c  | 2 +-
 tests/tpm-tests.c | 2 +-
 tests/tpm-tis-test.c  | 2 +-
 tests/usb-hcd-ohci-test.c | 2 +-
 tests/usb-hcd-uhci-test.c | 2 +-
 tests/usb-hcd-xhci-test.c | 2 +-
 tests/vhost-user-test.c   | 2 +-
 tests/virtio-9p-test.c| 2 +-
 tests/virtio-blk-test.c   | 2 +-
 tests/virtio-ccw-test.c   | 2 +-
 tests/virtio-net-test.c   | 2 +-
 tests/virtio-scsi-test.c  | 2 +-
 tests/virtio-serial-test.c| 2 +-
 33 files changed, 34 insertions(+), 37 deletions(-)

diff --git a/tests/cpu-plug-test.c b/tests/cpu-plug-test.c
index 3049620854..776407e1b6 100644
--- a/tests/cpu-plug-test.c
+++ b/tests/cpu-plug-test.c
@@ -10,7 +10,7 @@
 #include "qemu/osdep.h"
 
 #include "qemu-common.h"
-#include "libqtest.h"
+#include "libqtest-single.h"
 #include "qapi/qmp/qdict.h"
 
 struct PlugTestData {
diff --git a/tests/display-vga-test.c b/tests/display-vga-test.c
index bd176dcf3a..ace3bb28e0 100644
--- a/tests/display-vga-test.c
+++ b/tests/display-vga-test.c
@@ -8,7 +8,7 @@
  */
 
 #include "qemu/osdep.h"
-#include "libqtest.h"
+#include "libqtest-single.h"
 
 static void pci_cirrus(void)
 {
diff --git a/tests/e1000e-test.c b/tests/e1000e-test.c
index 93628c588d..1a232a663a 100644
--- a/tests/e1000e-test.c
+++ b/tests/e1000e-test.c
@@ -26,7 +26,7 @@
 
 #include "qemu/osdep.h"
 #include "qemu-common.h"
-#include "libqtest.h"
+#include "libqtest-single.h"
 #include "qemu-common.h"
 #include "libqos/pci-pc.h"
 #include "qemu/sockets.h"
diff --git a/tests/fdc-test.c b/tests/fdc-test.c
index 31cd3295c1..26b69f7c5c 100644
--- a/tests/fdc-test.c
+++ b/tests/fdc-test.c
@@ -25,7 +25,7 @@
 #include "qemu/osdep.h"
 
 
-#include "libqtest.h"
+#include "libqtest-single.h"
 #include "qapi/qmp/qdict.h"
 #include "qemu-common.h"
 
diff --git a/tests/i440fx-test.c b/tests/i440fx-test.c
index 69205b58a8..1f57d9684b 100644
--- a/tests/i440fx-test.c
+++ b/tests/i440fx-test.c
@@ -14,7 +14,7 @@
 
 #include "qemu/osdep.h"
 
-#include "libqtest.h"
+#include "libqtest-single.h"
 #include "libqos/pci.h"
 #include "libqos/pci-pc.h"
 #include "hw/pci/pci_regs.h"
diff --git a/tests/i82801b11-test.c b/tests/i82801b11-test.c
index a6e31594c9..4345da338b 100644
--- a/tests/i82801b11-test.c
+++ b/tests/i82801b11-test.c
@@ -8,7 +8,7 @@
  */
 
 #include "qemu/osdep.h"
-#include "libqtest.h"
+#include "libqtest-single.h"
 
 /* Tests only initialization so far. TODO: Replace with functional tests */
 static void nop(void)
diff --git a/tests/intel-hda-test.c b/tests/intel-hda-test.c
index b782b2e944..fc25ccc33c 100644
--- a/tests/intel-hda-test.c
+++ b/tests/intel-hda-test.c
@@ -8,7 +8,7 @@
  */
 
 #include "qemu/osdep.h"
-#include "libqtest.h"
+#include "libqtest-single.h"
 
 #define HDA_ID "hda0"
 #define CODEC_DEVICES " -device hda-output,bus=" HDA_ID ".0" \
diff --git a/tests/ioh3420-test.c b/tests/ioh3420-test.c
index b54c4b9f11..f6ca43cca7 100644
--- a/tests/ioh3420-test.c
+++ b/tests/ioh3420-test.c
@@ -8,7 +8,7 @@
  */
 
 #include "qemu/osdep.h"
-#include "libqtest.h"
+#include "libqtest-single.h"
 
 /* Tests only initialization so far. TODO: Replace with functional tests */
 static void nop(void)
diff --git a/tests/ipmi-kcs-test.c b/tests/ipmi-kcs-test.c
index a2354c10c7..693a6aacb5 100644
--- a/tests/ipmi-kcs-test.c
+++ b/tests/ipmi-kcs-test.c
@@ -24,8 +24,7 @@
 
 #include "qemu/osdep.h"
 
-
-#include "libqtest.h"
+#include "libqtest-single.h"
 
 #define IPMI_IRQ5
 
diff --git a/tests/libqtest-single.h b/tests/libqtest-single.h
index 49259558a5..6f1bb1331c 100644
--- a/tests/libqtest-single.h
+++ b/tests/libqtest-single.h
@@ -11,6 +11,10 @@
 #ifndef LIBQTEST_SINGLE_H
 #define LIBQTEST_SINGLE_H
 
+#include "libqtest.h"
+
+QTestState *global_qtest __attribu

Re: [Qemu-devel] [PATCH v4 00/69] target/arm: Convert aa32 base isa to decodetree

2019-09-05 Thread Peter Maydell
On Wed, 4 Sep 2019 at 20:31, Richard Henderson
 wrote:
>
> This unifies the implementation of the actual instructions for
> a32, t32, and t16.
>
> The changes from v3 are minimal, mostly rebase conflicts.  There
> is one change for checkpatch warnings, in patch 34 in trans_RFE.
>
> There is one outstanding checkpatch warning, but it's in a minimal
> change to some existing code that is removed before the end of the
> patch set.
>
> All patches have reviews now.


Since this is all reviewed and it's big enough that it would
have been a target-arm pullreq all by itself, I've just
applied it directly to master.

thanks
-- PMM



Re: [Qemu-devel] [Qemu-arm] [PATCH v5 02/17] target/arm: Split out rebuild_hflags_a64

2019-09-05 Thread Alex Bennée


Richard Henderson  writes:

> Create a function to compute the values of the TBFLAG_A64 bits
> that will be cached.  For now, the env->hflags variable is not
> used, and the results are fed back to cpu_get_tb_cpu_state.
>
> Signed-off-by: Richard Henderson 
> ---
>  target/arm/helper.c | 131 +++-
>  1 file changed, 69 insertions(+), 62 deletions(-)
>
> diff --git a/target/arm/helper.c b/target/arm/helper.c
> index f2c6419369..02cb43cf58 100644
> --- a/target/arm/helper.c
> +++ b/target/arm/helper.c
> @@ -11032,6 +11032,71 @@ static uint32_t rebuild_hflags_common(CPUARMState 
> *env, int fp_el,
>  return flags;
>  }
>
> +static uint32_t rebuild_hflags_a64(CPUARMState *env, int el, int fp_el,
> +   ARMMMUIdx mmu_idx)
> +{

> +
> +if (cpu_isar_feature(aa64_bti, env_archcpu(env))) {
> +/* Note that SCTLR_EL[23].BT == SCTLR_BT1.  */
> +if (sctlr & (el == 0 ? SCTLR_BT0 : SCTLR_BT1)) {
> +flags = FIELD_DP32(flags, TBFLAG_A64, BT, 1);
> +}
> +}
> +
> +return rebuild_hflags_common(env, fp_el, mmu_idx, flags);
> +}
> +
>  void cpu_get_tb_cpu_state(CPUARMState *env, target_ulong *pc,
>target_ulong *cs_base, uint32_t *pflags)
>  {
> @@ -11041,67 +11106,9 @@ void cpu_get_tb_cpu_state(CPUARMState *env, 
> target_ulong *pc,
>  uint32_t flags = 0;
>
>  if (is_a64(env)) {

> -
> -if (cpu_isar_feature(aa64_bti, cpu)) {
> -/* Note that SCTLR_EL[23].BT == SCTLR_BT1.  */
> -if (sctlr & (current_el == 0 ? SCTLR_BT0 : SCTLR_BT1)) {
> -flags = FIELD_DP32(flags, TBFLAG_A64, BT, 1);
> -}
> +flags = rebuild_hflags_a64(env, current_el, fp_el, mmu_idx);
> +if (cpu_isar_feature(aa64_bti, env_archcpu(env))) {
>  flags = FIELD_DP32(flags, TBFLAG_A64, BTYPE, env->btype);

It seems off to only hoist part of the BTI flag check into the helper,
was it just missed or is there a reason? If so it could probably do with
an additional comment.

>  }
>  } else {
> @@ -11121,9 +11128,9 @@ void cpu_get_tb_cpu_state(CPUARMState *env, 
> target_ulong *pc,
>  flags = FIELD_DP32(flags, TBFLAG_A32,
> XSCALE_CPAR, env->cp15.c15_cpar);
>  }
> -}
>
> -flags = rebuild_hflags_common(env, fp_el, mmu_idx, flags);
> +flags = rebuild_hflags_common(env, fp_el, mmu_idx, flags);
> +}
>
>  /* The SS_ACTIVE and PSTATE_SS bits correspond to the state machine
>   * states defined in the ARM ARM for software singlestep:


--
Alex Bennée



Re: [Qemu-devel] [PATCH v7 00/30] riscv: sifive_u: Improve the emulation fidelity of sifive_u machine

2019-09-05 Thread Bin Meng
Hi Alistair,

On Thu, Sep 5, 2019 at 3:50 AM Alistair Francis  wrote:
>
> On Sat, Aug 31, 2019 at 7:54 PM Bin Meng  wrote:
> >
> > As of today, the QEMU 'sifive_u' machine is a special target that does
> > not boot the upstream OpenSBI/U-Boot firmware images built for the real
> > SiFive HiFive Unleashed board. Hence OpenSBI supports a special platform
> > "qemu/sifive_u". For U-Boot, the sifive_fu540_defconfig is referenced
> > in the OpenSBI doc as its payload, but that does not boot at all due
> > to various issues in current QEMU 'sifive_u' machine codes.
> >
> > This series aims to improve the emulation fidelity of sifive_u machine,
> > so that the upstream OpenSBI, U-Boot and kernel images built for the
> > SiFive HiFive Unleashed board can be used out of the box without any
> > special hack.
> >
> > The major changes include:
> > - Heterogeneous harts creation supported, so that we can create a CPU
> >   that exactly mirrors the real hardware: 1 E51 + 4 U54.
> > - Implemented a PRCI model for FU540
> > - Implemented an OTP model for FU540, primarily used for storing serial
> >   number of the board
> > - Fixed GEM support that was seriously broken on sifive_u
> > - Synced device tree with upstream Linux kernel on sifive_u
> >
> > OpenSBI v0.4 image built for sifive/fu540 is included as the default
> > bios image for 'sifive_u' machine.
> >
> > The series is tested against OpenSBI v0.4 image for sifive/fu540
> > paltform, U-Boot v2019.10-rc1 image for sifive_fu540_defconfig,
> > and Linux kernel v5.3-rc3 image with the following patch:
> >
> > macb: Update compatibility string for SiFive FU540-C000 [1]
> >
> > OpenSBI + U-Boot, ping/tftpboot with U-Boot MACB driver works well.
> > Boot Linux 64-bit defconfig image, verified that system console on
> > the serial 0 and ping host work pretty well.
> >
> > An OpenSBI patch [2] was sent to drop the special "qemu/sifive_u" platform
> > support in OpenSBI. The original plan was to get the drop patch applied
> > after this QEMU series is merged. However after discussion in the OpenSBI
> > mailing list, it seems the best option for us is to let OpenSBI continue
> > shipping the special "qemu/sifive_u" platform support to work with QEMU
> > version <= 4.1 and deprecate the support sometime in the future. A patch
> > will need to be sent to OpenSBI mailing list to update its document.
> >
> > v4 is now rebased on Palmer's QEMU RISC-V repo "for-master" branch.
> > Dropped the following v3 patch that was already done by someone else.
> > - riscv: sifive_u: Generate an aliases node in the device tree
> > - riscv: sifive_u: Support loading initramfs
>
> I'm having trouble applying this. Do you mind sharing a public git branch?

So I see Palmer has rebased his "for-master" branch against QEMU
master and now this patch series cannot be applied cleanly.

Even worse, the current "for-master" branch has build errors for QEMU RISC-V.

Regards,
Bin



Re: [Qemu-devel] [Qemu-arm] [PATCH v5 17/17] target/arm: Rely on hflags correct in cpu_get_tb_cpu_state

2019-09-05 Thread Alex Bennée


Richard Henderson  writes:

> This is the payoff.
>
> From perf record -g data of ubuntu 18 boot and shutdown:
>
> BEFORE:
>
> -   23.02% 2.82%  qemu-system-aar  [.] helper_lookup_tb_ptr
>- 20.22% helper_lookup_tb_ptr
>   + 10.05% tb_htable_lookup
>   - 9.13% cpu_get_tb_cpu_state
>3.20% aa64_va_parameters_both
>0.55% fp_exception_el
>
> -   11.66% 4.74%  qemu-system-aar  [.] cpu_get_tb_cpu_state
>- 6.96% cpu_get_tb_cpu_state
> 3.63% aa64_va_parameters_both
> 0.60% fp_exception_el
> 0.53% sve_exception_el
>
> AFTER:
>
> -   16.40% 3.40%  qemu-system-aar  [.] helper_lookup_tb_ptr
>- 13.03% helper_lookup_tb_ptr
>   + 11.19% tb_htable_lookup
> 0.55% cpu_get_tb_cpu_state
>
>  0.98% 0.71%  qemu-system-aar  [.] cpu_get_tb_cpu_state
>
>  0.87% 0.24%  qemu-system-aar  [.] rebuild_hflags_a64
>
> Before, helper_lookup_tb_ptr is the second hottest function in the
> application, consuming almost a quarter of the runtime.  Within the
> entire execution, cpu_get_tb_cpu_state consumes about 12%.
>
> After, helper_lookup_tb_ptr has dropped to the fourth hottest function,
> with consumption dropping to a sixth of the runtime.  Within the
> entire execution, cpu_get_tb_cpu_state has dropped below 1%, and the
> supporting function to rebuild hflags also consumes about 1%.
>
> Assertions are retained for --enable-debug-tcg.
>
> Tested-by: Alex Bennée 

Hmm something must have been missed for M-profile because:

  make run-tcg-tests-arm-softmmu V=1

Leads to:

  timeout 15  
/home/alex/lsrc/qemu.git/builds/all.debug/arm-softmmu/qemu-system-arm -monitor 
none -display none -chardev file,path=test-armv6m-undef.out,id=output 
-semihosting -M microbit -kernel test-armv6m-undef
  qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)

  R00= R01= R02= R03=
  R04= R05= R06= R07=
  R08= R09= R10= R11=
  R12= R13=20003fe0 R14=fff9 R15=00c0
  XPSR=4103 -Z-- T handler
  FPSCR: 
  timeout: the monitored command dumped core

But annoyingly not shown up by the debug-tcg verification. The commit
before works fine.

> Reviewed-by: Alex Bennée 
> Signed-off-by: Richard Henderson 
> ---
> v2: Retain asserts for future debugging.
> ---
>  target/arm/helper.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/target/arm/helper.c b/target/arm/helper.c
> index d1bf71a260..5e4f996882 100644
> --- a/target/arm/helper.c
> +++ b/target/arm/helper.c
> @@ -11211,12 +11211,15 @@ void HELPER(rebuild_hflags_a64)(CPUARMState *env, 
> int el)
>  void cpu_get_tb_cpu_state(CPUARMState *env, target_ulong *pc,
>target_ulong *cs_base, uint32_t *pflags)
>  {
> -uint32_t flags, pstate_for_ss;
> +uint32_t flags = env->hflags;
> +uint32_t pstate_for_ss;
>
>  *cs_base = 0;
> -flags = rebuild_hflags_internal(env);
> +#ifdef CONFIG_TCG_DEBUG
> +assert(flags == rebuild_hflags_internal(env));
> +#endif
>
> -if (is_a64(env)) {
> +if (FIELD_EX32(flags, TBFLAG_ANY, AARCH64_STATE)) {
>  *pc = env->pc;
>  if (cpu_isar_feature(aa64_bti, env_archcpu(env))) {
>  flags = FIELD_DP32(flags, TBFLAG_A64, BTYPE, env->btype);


--
Alex Bennée



Re: [Qemu-devel] Cryptic errors from PIP install if missing openssl-devel

2019-09-05 Thread Cleber Rosa
On Thu, Sep 05, 2019 at 11:06:18AM -0300, Eduardo Habkost wrote:
> On Thu, Sep 05, 2019 at 09:38:24AM -0400, Cleber Rosa wrote:
> > On Thu, Sep 05, 2019 at 12:09:24PM +1000, David Gibson wrote:
> > > On Wed, Sep 04, 2019 at 03:57:17PM -0400, Cleber Rosa wrote:
> > > > 
> > > > Hi David,
> > > > 
> > > > I've pushed a branch here (most of the commits have already been sent
> > > > separately):
> > > > 
> > > >https://github.com/clebergnu/qemu/tree/ppc64
> > > > 
> > > > I've tested on a RHEL 8 ppc64le Power 9, and it seems to work for me.
> > > > My steps for building QEMU:
> > > > 
> > > >   - Configured with: '/home/cleber/src/qemu/configure' 
> > > > '--enable-slirp=git' '--python=/usr/bin/python3' 
> > > > '--target-list=x86_64-softmmu,ppc64-softmmu,arm-softmmu,aarch64-softmmu,mips-softmmu,mipsel-softmmu,mips64-softmmu,mips64el-softmmu,sh4-softmmu,s390x-softmmu,alpha-softmmu,m68k-softmmu,riscv64-softmmu'
> > > >   - make
> > > >   - make check-acceptance
> > > > 
> > > > Would you be able to test if that branch works smoothly for you?
> > > 
> > > So, with this tree I'm no longer getting problems if openssl-devel is
> > > not installed, so that much looks good.
> > > 
> > > I am getting some different errors - I was seeing this before (with
> > > openssl-devel installed) sometimes, but only sometimes.  I haven't yet
> > > worked out a pattern for when they appeared.  They also don't appear
> > > to be fatal, the rest of the tests seem to be running ok.  Any ideas?
> > > 
> > >  VENV/home/dwg/qemu/build/rhel8/tests/venv
> > >   PIP /home/dwg/qemu/tests/requirements.txt
> > >   AVOCADO tests/acceptance
> > > Error running method "run" of plugin "html": 'Namespace' object has no 
> > > attribute 'get'
> > > Error running method "run" of plugin "varianter_cit": 'Namespace' object 
> > > has no attribute 'get'
> > 
> > Hi David,
> > 
> > Yes, those should not be fatal.  Anyway, they are caused by two things:
> > 
> >  1) A second set of Avocado plugins installation with different versions
> > than the Avocado installation on QEMU's tests venv
> > 
> >  2) The tests' venv, which is created with "--system-site-packages",
> > option that is described as "Give the virtual environment access
> > to the system site-packages dir."
> > 
> > The motivation to have "--system-site-packages" is that, if the user
> > had any of the "requirements.txt" depedencies installed system wide,
> > the venv would simply use it and skip downloads.  Maybe we should make
> > that an optional feature, disabled by default, so that the test's venv
> > is better isolated and more predictable by default.
> > 
> > Eduardo,
> > 
> > I remember we discussed #2, so your opinion is appreciated here.
> 
> I think I was the person who insisted for --system-site-packages.
> Considering that we're often using very recent versions of
> Avocado, maybe trying to use system-provided Avocado modules by
> default wasn't a good idea after all.
> 
> Making --system-site-packages optional and not enabling it by
> default sounds like a reasonable workaround.
>

OK, agreed.

FIY, given the fact that pip itself keeps a local cache, not using
"--system-site-packages" this shouldn't be much of a hit when it
comes to downloads.

Cheers,
- Cleber.

> -- 
> Eduardo
> 



Re: [Qemu-devel] [RFC v3 PATCH 19/45] multi-process: Add LSI device proxy object

2019-09-05 Thread Jag Raman




On 9/5/2019 6:22 AM, Gerd Hoffmann wrote:

   Hi,


+static uint64_t proxy_lsi_io_read(void *opaque, hwaddr addr, unsigned size)
+{
+ProxyLSIState *s = opaque;
+
+return proxy_default_bar_read(PCI_PROXY_DEV(s), &s->io_io, addr, size,
+  false);
+}
+
+static void proxy_lsi_io_write(void *opaque, hwaddr addr, uint64_t val,
+   unsigned size)
+{
+ProxyLSIState *s = opaque;
+
+proxy_default_bar_write(PCI_PROXY_DEV(s), &s->io_io, addr, val, size,
+false);
+}
+
+static const MemoryRegionOps proxy_lsi_io_ops = {
+.read = proxy_lsi_io_read,
+.write = proxy_lsi_io_write,
+.endianness = DEVICE_NATIVE_ENDIAN,
+.impl = {
+.min_access_size = 1,
+.max_access_size = 1,
+},
+};


Hmm, as more devices get proxy support there will be alot of simliar
boilerplate.

I think it would be useful to have a

struct pci_device_description {
u16 vendor_id,
u16 device_id,
[ ... ]
struct {
[ ... ]
} bar[6];
};


+proxy_class->realize = proxy_lsi_realize;
+proxy_class->command = g_strdup("qemu-scsi-dev");


Hook that up here (proxy_class->description = &lsi_description),
then have the pci proxy realize function setup everything.  All pci
bar access is just forwarded to the proxy, that should be doable
without duplicating the code for each proxied pci device ...

At least parts of the pci_device_description can probably also used for
non-proxy device setup (should work for pci config space, probably
would not work for memory regions as they are very device specific).


Sounds great. We'll move similar boilerplate code to the pci proxy
class in the next rev.

Thanks!
--
Jag



cheers,
   Gerd






Re: [Qemu-devel] [RFC v3 PATCH 40/45] multi-process/mon: Refactor monitor/chardev functions out of vl.c

2019-09-05 Thread Jag Raman




On 9/4/2019 4:37 AM, Dr. David Alan Gilbert wrote:

* Jagannathan Raman (jag.ra...@oracle.com) wrote:

Some of the initialization helper functions w.r.t monitor & chardev
in vl.c are also used by the remote process. Therefore, these functions
are refactored into a shared file that both QEMU & remote process
could use.

Signed-off-by: Elena Ufimtseva 
Signed-off-by: John G Johnson 
Signed-off-by: Jagannathan Raman 


Shouldn't the monitor parts be moved into something under monitor/ and
the chardev parts be moved into chardev/ ?


Sure, will do.

Thanks!
--
Jag



Dave


---
  New patch in v3

  vl-parse.c | 92 ++
  vl.c   | 91 -
  vl.h   |  4 +++
  3 files changed, 96 insertions(+), 91 deletions(-)

diff --git a/vl-parse.c b/vl-parse.c
index d3716d1..bee904d 100644
--- a/vl-parse.c
+++ b/vl-parse.c
@@ -155,3 +155,95 @@ int device_init_func(void *opaque, QemuOpts *opts, Error 
**errp)
  object_unref(OBJECT(dev));
  return 0;
  }
+
+void monitor_parse(const char *optarg, const char *mode, bool pretty)
+{
+static int monitor_device_index;
+QemuOpts *opts;
+const char *p;
+char label[32];
+
+if (strstart(optarg, "chardev:", &p)) {
+snprintf(label, sizeof(label), "%s", p);
+} else {
+snprintf(label, sizeof(label), "compat_monitor%d",
+ monitor_device_index);
+opts = qemu_chr_parse_compat(label, optarg, true);
+if (!opts) {
+error_report("parse error: %s", optarg);
+exit(1);
+}
+}
+
+opts = qemu_opts_create(qemu_find_opts("mon"), label, 1, &error_fatal);
+qemu_opt_set(opts, "mode", mode, &error_abort);
+qemu_opt_set(opts, "chardev", label, &error_abort);
+if (!strcmp(mode, "control")) {
+qemu_opt_set_bool(opts, "pretty", pretty, &error_abort);
+} else {
+assert(pretty == false);
+}
+monitor_device_index++;
+}
+
+int mon_init_func(void *opaque, QemuOpts *opts, Error **errp)
+{
+Chardev *chr;
+bool qmp;
+bool pretty = false;
+const char *chardev;
+const char *mode;
+
+mode = qemu_opt_get(opts, "mode");
+if (mode == NULL) {
+mode = "readline";
+}
+if (strcmp(mode, "readline") == 0) {
+qmp = false;
+} else if (strcmp(mode, "control") == 0) {
+qmp = true;
+} else {
+error_setg(errp, "unknown monitor mode \"%s\"", mode);
+return -1;
+}
+
+if (!qmp && qemu_opt_get(opts, "pretty")) {
+warn_report("'pretty' is deprecated for HMP monitors, it has no effect 
"
+"and will be removed in future versions");
+}
+if (qemu_opt_get_bool(opts, "pretty", 0)) {
+pretty = true;
+}
+
+chardev = qemu_opt_get(opts, "chardev");
+if (!chardev) {
+error_report("chardev is required");
+exit(1);
+}
+chr = qemu_chr_find(chardev);
+if (chr == NULL) {
+error_setg(errp, "chardev \"%s\" not found", chardev);
+return -1;
+}
+
+if (qmp) {
+monitor_init_qmp(chr, pretty);
+} else {
+monitor_init_hmp(chr, true);
+}
+return 0;
+}
+
+int chardev_init_func(void *opaque, QemuOpts *opts, Error **errp)
+{
+Error *local_err = NULL;
+
+if (!qemu_chr_new_from_opts(opts, NULL, &local_err)) {
+if (local_err) {
+error_propagate(errp, local_err);
+return -1;
+}
+exit(0);
+}
+return 0;
+}
diff --git a/vl.c b/vl.c
index 08e9c09..3c03405 100644
--- a/vl.c
+++ b/vl.c
@@ -2264,19 +2264,6 @@ static int device_help_func(void *opaque, QemuOpts 
*opts, Error **errp)
  return qdev_device_help(opts);
  }
  
-static int chardev_init_func(void *opaque, QemuOpts *opts, Error **errp)

-{
-Error *local_err = NULL;
-
-if (!qemu_chr_new_from_opts(opts, NULL, &local_err)) {
-if (local_err) {
-error_propagate(errp, local_err);
-return -1;
-}
-exit(0);
-}
-return 0;
-}
  
  #ifdef CONFIG_VIRTFS

  static int fsdev_init_func(void *opaque, QemuOpts *opts, Error **errp)
@@ -2285,84 +2272,6 @@ static int fsdev_init_func(void *opaque, QemuOpts *opts, 
Error **errp)
  }
  #endif
  
-static int mon_init_func(void *opaque, QemuOpts *opts, Error **errp)

-{
-Chardev *chr;
-bool qmp;
-bool pretty = false;
-const char *chardev;
-const char *mode;
-
-mode = qemu_opt_get(opts, "mode");
-if (mode == NULL) {
-mode = "readline";
-}
-if (strcmp(mode, "readline") == 0) {
-qmp = false;
-} else if (strcmp(mode, "control") == 0) {
-qmp = true;
-} else {
-error_setg(errp, "unknown monitor mode \"%s\"", mode);
-return -1;
-}
-
-if (!qmp && qemu_opt_get(opts, "pretty")) {
-warn_report("'pretty' is deprecated for HMP monitors, it has no effect 
"
-"and 

[Qemu-devel] [RFC 1/3] virtiofsd: add org.qemu.Virtiofsd interface

2019-09-05 Thread Stefan Hajnoczi
Define a DBus interface for virtiofsd management.  It only allows
querying and changing the log level at the moment.

In the future more methods and properties could be added.

Signed-off-by: Stefan Hajnoczi 
---
 configure|  7 +++
 Makefile | 13 +
 contrib/virtiofsd/Makefile.objs  |  6 +-
 .gitignore   |  1 +
 contrib/virtiofsd/org.qemu.Virtiofsd.xml |  7 +++
 5 files changed, 33 insertions(+), 1 deletion(-)
 create mode 100644 contrib/virtiofsd/org.qemu.Virtiofsd.xml

diff --git a/configure b/configure
index 2976e64b9b..17b789d772 100755
--- a/configure
+++ b/configure
@@ -3674,10 +3674,16 @@ if $pkg_config --atleast-version=$glib_req_ver gio-2.0; 
then
 gio=yes
 gio_cflags=$($pkg_config --cflags gio-2.0)
 gio_libs=$($pkg_config --libs gio-2.0)
+gdbus_codegen=$($pkg_config --variable=gdbus_codegen gio-2.0)
 else
 gio=no
 fi
 
+if $pkg_config --atleast-version=$glib_req_ver gio-unix-2.0; then
+gio_cflags="$gio_cflags $($pkg_config --cflags gio-unix-2.0)"
+gio_libs="$gio_libs $($pkg_config --libs gio-unix-2.0)"
+fi
+
 # Sanity check that the current size_t matches the
 # size that glib thinks it should be. This catches
 # problems on multi-arch where people try to build
@@ -6856,6 +6862,7 @@ if test "$gio" = "yes" ; then
 echo "CONFIG_GIO=y" >> $config_host_mak
 echo "GIO_CFLAGS=$gio_cflags" >> $config_host_mak
 echo "GIO_LIBS=$gio_libs" >> $config_host_mak
+echo "GDBUS_CODEGEN=$gdbus_codegen" >> $config_host_mak
 fi
 echo "CONFIG_TLS_PRIORITY=\"$tls_priority\"" >> $config_host_mak
 if test "$gnutls" = "yes" ; then
diff --git a/Makefile b/Makefile
index a3dfdd6fa8..6b1af33348 100644
--- a/Makefile
+++ b/Makefile
@@ -124,6 +124,11 @@ GENERATED_QAPI_FILES += qapi/qapi-doc.texi
 
 generated-files-y += $(GENERATED_QAPI_FILES)
 
+ifdef CONFIG_LINUX
+generated-files-y += contrib/virtiofsd/gdbus_generated.h
+generated-files-y += contrib/virtiofsd/gdbus_generated.c
+endif
+
 generated-files-y += trace/generated-tcg-tracers.h
 
 generated-files-y += trace/generated-helpers-wrappers.h
@@ -646,6 +651,14 @@ rdmacm-mux$(EXESUF): $(rdmacm-mux-obj-y) $(COMMON_LDADDS)
$(call LINK, $^)
 
 ifdef CONFIG_LINUX # relies on Linux-specific syscalls
+contrib/virtiofsd/gdbus_generated.h contrib/virtiofsd/gdbus_generated.c: 
contrib/virtiofsd/gdbus_generated.c-timestamp ;
+contrib/virtiofsd/gdbus_generated.c-timestamp: 
$(SRC_PATH)/contrib/virtiofsd/org.qemu.Virtiofsd.xml
+   $(call quiet-command,$(GDBUS_CODEGEN) $< \
+   --interface-prefix org.qemu \
+   --generate-c-code contrib/virtiofsd/gdbus_generated, \
+   "GEN","$(@:%-timestamp=%)")
+   @>$@
+
 virtiofsd$(EXESUF): $(virtiofsd-obj-y) libvhost-user.a $(COMMON_LDADDS)
$(call LINK, $^)
 endif
diff --git a/contrib/virtiofsd/Makefile.objs b/contrib/virtiofsd/Makefile.objs
index 25f1e8dd73..9b2af1bc23 100644
--- a/contrib/virtiofsd/Makefile.objs
+++ b/contrib/virtiofsd/Makefile.objs
@@ -7,9 +7,13 @@ virtiofsd-obj-y = buffer.o \
   fuse_virtio.o \
   helper.o \
   passthrough_ll.o \
-  seccomp.o
+  seccomp.o \
+  gdbus_generated.o
 
 seccomp.o-cflags := $(SECCOMP_CFLAGS)
 seccomp.o-libs := $(SECCOMP_LIBS)
 
+gdbus_generated.o-cflags := $(GIO_CFLAGS)
+gdbus_generated.o-libs := $(GIO_LIBS)
+
 passthrough_ll.o-libs += -lcap
diff --git a/.gitignore b/.gitignore
index fd6e6c38c7..c04d5dd0b1 100644
--- a/.gitignore
+++ b/.gitignore
@@ -6,6 +6,7 @@
 /config-target.*
 /config.status
 /config-temp
+/contrib/virtiofsd/gdbus_generated.*
 /elf2dmp
 /trace-events-all
 /trace/generated-events.h
diff --git a/contrib/virtiofsd/org.qemu.Virtiofsd.xml 
b/contrib/virtiofsd/org.qemu.Virtiofsd.xml
new file mode 100644
index 00..efc0c59020
--- /dev/null
+++ b/contrib/virtiofsd/org.qemu.Virtiofsd.xml
@@ -0,0 +1,7 @@
+http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd";>
+
+
+
+
+
-- 
2.21.0




[Qemu-devel] [RFC 2/3] virtiofsd: add DBus server to handle log level changes

2019-09-05 Thread Stefan Hajnoczi
Introduce a DBus server thread that runs alongside the other virtiofsd
threads.  It processes changes to the /org/qemu/virtiofsd object which
can be accessed at the org.qemu.virtiofsd location on the bus.

This code does not use locking because we are the only writer to the
int current_log_level variable.  More advanced management commands would
require locking to prevent race conditions with the other threads.

Signed-off-by: Stefan Hajnoczi 
---
 contrib/virtiofsd/Makefile.objs|   3 +-
 contrib/virtiofsd/dbus.h   |   9 ++
 contrib/virtiofsd/dbus.c   | 162 +
 contrib/virtiofsd/passthrough_ll.c |   8 +-
 4 files changed, 180 insertions(+), 2 deletions(-)
 create mode 100644 contrib/virtiofsd/dbus.h
 create mode 100644 contrib/virtiofsd/dbus.c

diff --git a/contrib/virtiofsd/Makefile.objs b/contrib/virtiofsd/Makefile.objs
index 9b2af1bc23..d59ab60f3d 100644
--- a/contrib/virtiofsd/Makefile.objs
+++ b/contrib/virtiofsd/Makefile.objs
@@ -8,7 +8,8 @@ virtiofsd-obj-y = buffer.o \
   helper.o \
   passthrough_ll.o \
   seccomp.o \
-  gdbus_generated.o
+  gdbus_generated.o \
+  dbus.o
 
 seccomp.o-cflags := $(SECCOMP_CFLAGS)
 seccomp.o-libs := $(SECCOMP_LIBS)
diff --git a/contrib/virtiofsd/dbus.h b/contrib/virtiofsd/dbus.h
new file mode 100644
index 00..aa18e47408
--- /dev/null
+++ b/contrib/virtiofsd/dbus.h
@@ -0,0 +1,9 @@
+#ifndef DBUS_H
+#define DBUS_H
+
+#include 
+
+bool setup_dbus(void);
+void cleanup_dbus(void);
+
+#endif /* DBUS_H */
diff --git a/contrib/virtiofsd/dbus.c b/contrib/virtiofsd/dbus.c
new file mode 100644
index 00..bc2308e34b
--- /dev/null
+++ b/contrib/virtiofsd/dbus.c
@@ -0,0 +1,162 @@
+#include 
+#include 
+#include 
+#include "fuse_log.h"
+#include "dbus.h"
+#include "gdbus_generated.h"
+
+static GThread *the_dbus_thread;
+static GMainContext *the_dbus_context;
+static GMainLoop *the_dbus_loop;
+
+/* Set the string property based on the current log level */
+static void refresh_log_level(Virtiofsd *virtiofsd)
+{
+switch (current_log_level) {
+case LOG_ERR:
+virtiofsd_set_log_level(virtiofsd, "err");
+break;
+case LOG_WARNING:
+virtiofsd_set_log_level(virtiofsd, "warning");
+break;
+case LOG_INFO:
+virtiofsd_set_log_level(virtiofsd, "info");
+break;
+case LOG_DEBUG:
+virtiofsd_set_log_level(virtiofsd, "debug");
+break;
+}
+}
+
+/* Handle changes to Virtiofsd object properties */
+static void notify(GObject *object, GParamSpec *pspec)
+{
+Virtiofsd *virtiofsd = VIRTIOFSD(object);
+
+fprintf(stderr, "%s %s\n", __func__, pspec->name);
+
+if (strcmp(pspec->name, "log-level") == 0) {
+const char *s = virtiofsd_get_log_level(virtiofsd);
+
+if (strcmp(s, "err") == 0) {
+current_log_level = LOG_ERR;
+} else if (strcmp(s, "warning") == 0) {
+current_log_level = LOG_WARNING;
+} else if (strcmp(s, "info") == 0) {
+current_log_level = LOG_INFO;
+} else if (strcmp(s, "debug") == 0) {
+current_log_level = LOG_DEBUG;
+} else {
+/* Invalid, reset the log level property */
+refresh_log_level(virtiofsd);
+}
+}
+}
+
+typedef struct {
+Virtiofsd *virtiofsd;
+pthread_barrier_t *started;
+} GBusOwnNameData;
+
+static void bus_acquired(GDBusConnection *connection, const gchar *name,
+gpointer user_data)
+{
+GBusOwnNameData *data = user_data;
+GError *error = NULL;
+
+if (!g_dbus_interface_skeleton_export(
+G_DBUS_INTERFACE_SKELETON(data->virtiofsd),
+connection, "/org/qemu/virtiofsd", &error)) {
+fuse_err("g_dbus_interface_skeleton_export: %s\n", error->message);
+g_error_free(error);
+exit(EXIT_FAILURE);
+}
+}
+
+static void name_acquired(GDBusConnection *connection, const gchar *name,
+gpointer user_data)
+{
+GBusOwnNameData *data = user_data;
+
+pthread_barrier_wait(data->started);
+}
+
+static void name_lost(GDBusConnection *connection, const gchar *name,
+gpointer user_data)
+{
+if (connection) {
+fuse_err("unable to own dbus name\n");
+} else {
+fuse_err("unable to connect to dbus\n");
+}
+exit(EXIT_FAILURE);
+}
+
+static gpointer dbus_thread(gpointer opaque)
+{
+GBusOwnNameData data;
+Virtiofsd *virtiofsd;
+guint owner_id;
+
+g_main_context_push_thread_default(the_dbus_context);
+
+virtiofsd = virtiofsd_skeleton_new();
+refresh_log_level(virtiofsd);
+g_signal_connect(virtiofsd, "notify", G_CALLBACK(notify), NULL);
+
+data.virtiofsd = virtiofsd;
+data.started = opaque;
+
+owner_id = g_bus_own_name(G_BUS_TYPE_SESSION, "org.qemu.virtiofsd",
+G_BUS_NAME_OWNER_FLAGS_DO_NOT_QUEUE, bus_ac

[Qemu-devel] [RFC 3/3] virtiofsd: add virtiofsctl command-line management tool

2019-09-05 Thread Stefan Hajnoczi
virtiofsctl can control a running virtiofsd process:

  usage: ./virtiofsctl COMMAND [args...]

  Commands:
get-log-level   - show current log level
set-log-level LEVEL - set current log level to one of
  "err", "warning", "info", "debug"

Make sure it is running in the same DBus session as virtiofsd.  This may
require setting the DBUS_SESSION_BUS_ADDRESS environment variable to the
same value as used by virtiofsd.

Signed-off-by: Stefan Hajnoczi 
---
 Makefile|  3 ++
 Makefile.objs   |  1 +
 contrib/virtiofsd/Makefile.objs |  3 ++
 contrib/virtiofsd/virtiofsctl.c | 55 +
 4 files changed, 62 insertions(+)
 create mode 100644 contrib/virtiofsd/virtiofsctl.c

diff --git a/Makefile b/Makefile
index 6b1af33348..d7ed9e7669 100644
--- a/Makefile
+++ b/Makefile
@@ -419,6 +419,7 @@ dummy := $(call unnest-vars,, \
 ivshmem-client-obj-y \
 ivshmem-server-obj-y \
 virtiofsd-obj-y \
+virtiofsctl-obj-y \
 rdmacm-mux-obj-y \
 libvhost-user-obj-y \
 vhost-user-scsi-obj-y \
@@ -661,6 +662,8 @@ contrib/virtiofsd/gdbus_generated.c-timestamp: 
$(SRC_PATH)/contrib/virtiofsd/org
 
 virtiofsd$(EXESUF): $(virtiofsd-obj-y) libvhost-user.a $(COMMON_LDADDS)
$(call LINK, $^)
+virtiofsctl$(EXESUF): $(virtiofsctl-obj-y)
+   $(call LINK, $^)
 endif
 
 vhost-user-gpu$(EXESUF): $(vhost-user-gpu-obj-y) $(libvhost-user-obj-y) 
libqemuutil.a libqemustub.a
diff --git a/Makefile.objs b/Makefile.objs
index dfdd7d56ea..326a8abb8e 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -126,6 +126,7 @@ rdmacm-mux-obj-y = contrib/rdmacm-mux/
 vhost-user-input-obj-y = contrib/vhost-user-input/
 vhost-user-gpu-obj-y = contrib/vhost-user-gpu/
 virtiofsd-obj-y = contrib/virtiofsd/
+virtiofsctl-obj-y = contrib/virtiofsd/
 
 ##
 trace-events-subdirs =
diff --git a/contrib/virtiofsd/Makefile.objs b/contrib/virtiofsd/Makefile.objs
index d59ab60f3d..3f944d493e 100644
--- a/contrib/virtiofsd/Makefile.objs
+++ b/contrib/virtiofsd/Makefile.objs
@@ -11,6 +11,9 @@ virtiofsd-obj-y = buffer.o \
   gdbus_generated.o \
   dbus.o
 
+virtiofsctl-obj-y = virtiofsctl.o \
+gdbus_generated.o
+
 seccomp.o-cflags := $(SECCOMP_CFLAGS)
 seccomp.o-libs := $(SECCOMP_LIBS)
 
diff --git a/contrib/virtiofsd/virtiofsctl.c b/contrib/virtiofsd/virtiofsctl.c
new file mode 100644
index 00..39bee2b881
--- /dev/null
+++ b/contrib/virtiofsd/virtiofsctl.c
@@ -0,0 +1,55 @@
+#include 
+#include "gdbus_generated.h"
+
+static void get_log_level(Virtiofsd *virtiofsd)
+{
+const char *value = virtiofsd_get_log_level(virtiofsd);
+
+printf("%s\n", value ? value : "(null)");
+}
+
+static void set_log_level(Virtiofsd *virtiofsd, const char *value)
+{
+virtiofsd_set_log_level(virtiofsd, value);
+}
+
+static void usage(const char *progname)
+{
+printf("usage: %s COMMAND [args...]\n", progname);
+printf("\n");
+printf("Commands:\n");
+printf("  get-log-level   - show current log level\n");
+printf("  set-log-level LEVEL - set current log level to one of\n");
+printf("\"err\", \"warning\", \"info\", 
\"debug\"\n");
+exit(0);
+}
+
+int main(int argc, char **argv)
+{
+Virtiofsd *virtiofsd;
+GError *error = NULL;
+
+if (argc < 2) {
+usage(argv[0]);
+}
+
+virtiofsd = virtiofsd_proxy_new_for_bus_sync(G_BUS_TYPE_SESSION,
+G_DBUS_PROXY_FLAGS_NONE, "org.qemu.virtiofsd",
+"/org/qemu/virtiofsd", NULL, &error);
+if (error) {
+fprintf(stderr, "%s\n", error->message);
+g_error_free(error);
+return 1;
+}
+
+if (strcmp(argv[0], "get-log-level") == 0) {
+get_log_level(virtiofsd);
+} else if (strcmp(argv[0], "set-log-level") == 0) {
+if (argc != 3) {
+usage(argv[0]);
+}
+set_log_level(virtiofsd, argv[2]);
+}
+g_object_unref(virtiofsd);
+return 0;
+}
-- 
2.21.0




Re: [Qemu-devel] [RFC v3 PATCH 07/45] multi-process: define proxy-link object

2019-09-05 Thread Jag Raman




On 9/5/2019 10:37 AM, Eric Blake wrote:

On 9/4/19 3:22 AM, Daniel P. Berrangé wrote:

On Tue, Sep 03, 2019 at 04:37:33PM -0400, Jagannathan Raman wrote:

Defines proxy-link object which forms the communication link between
QEMU & emulation program.
Adds functions to configure members of proxy-link object instance.
Adds functions to send and receive messages over the communication
channel.
Adds GMainLoop to handle events received on the communication channel.



+
+#ifndef PROXY_LINK_H
+#define PROXY_LINK_H
+
+#include 
+#include 
+#include 


I'm guessing this is the cause - nothing should be including this
directly - it is pulled  in for you via qemu/osdep.h


+#include 
+
+#include "qemu/osdep.h"


For that matter, "qemu/osdep.h" should ALWAYS be listed first, before
any system headers, and inclusion of  and  is also
redundant, just as the .


Removing  resolved the build issue. We'll remove  in all
files in the next rev.

We soon realized the "qemu/osdep.h" should be the first include in all
the files. We'll ensure that this is the case for all files in the next
revision.

Thanks!
--
Jag








[Qemu-devel] [RFC 0/3] virtiofsd: get/set log level via DBus

2019-09-05 Thread Stefan Hajnoczi
It is likely that virtiofsd will need to support "management commands" for
reconfiguring it at runtime.  The first use case was proposed by Eryu Guan for
getting/setting the current log level.

I promised to try out DBus as the management interface because it has a rich
feature set and is accessible from most programming languages.  It should be
able to support all the use cases we come up with.

This patch series is a prototype that implements the get-log-level and
set-log-level management commands via DBus.  Use the new virtiofsctl tool to
talk to a running virtiofsd process:

  # dbus-run-session ./virtiofsd ...
  ...
  Using dbus address 
unix:abstract=/tmp/dbus-H9WBbpjk3O,guid=0be16acefb868e6025a8737f5d7124d2
  # export 
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-H9WBbpjk3O,guid=0be16acefb868e6025a8737f5d7124d2
  # ./virtiofsctl set-log-level err

Most of the work is done by gdbus-codegen(1).  It generates code for the
org.qemu.Virtiofsd.xml interface definition.  Our code can use the simple
virtiofsd_get/set_log_level() APIs and it will make corresponding DBus calls.

I'm pretty happy with this approach because the code is straightforward.  It
hasn't even triggered seccomp failures yet :).

Error handling is a little problematic.  I noticed that virtiofsctl silently
returns success even if it cannot talk to virtiofsd.  This is due to the code
generated by gdbus-codegen(1) which has no error reporting :(.  This can be
solved by writing more low-level GDBus code instead of using the high-level
generated bindings.

What do you think about this approach?

Stefan Hajnoczi (3):
  virtiofsd: add org.qemu.Virtiofsd interface
  virtiofsd: add DBus server to handle log level changes
  virtiofsd: add virtiofsctl command-line management tool

 configure|   7 +
 Makefile |  16 +++
 Makefile.objs|   1 +
 contrib/virtiofsd/Makefile.objs  |  10 +-
 contrib/virtiofsd/dbus.h |   9 ++
 contrib/virtiofsd/dbus.c | 162 +++
 contrib/virtiofsd/passthrough_ll.c   |   8 +-
 contrib/virtiofsd/virtiofsctl.c  |  55 
 .gitignore   |   1 +
 contrib/virtiofsd/org.qemu.Virtiofsd.xml |   7 +
 10 files changed, 274 insertions(+), 2 deletions(-)
 create mode 100644 contrib/virtiofsd/dbus.h
 create mode 100644 contrib/virtiofsd/dbus.c
 create mode 100644 contrib/virtiofsd/virtiofsctl.c
 create mode 100644 contrib/virtiofsd/org.qemu.Virtiofsd.xml

-- 
2.21.0




Re: [Qemu-devel] [RFC v3 PATCH 01/45] multi-process: memory: alloc RAM from file at offset

2019-09-05 Thread Dr. David Alan Gilbert
* Jag Raman (jag.ra...@oracle.com) wrote:
> 
> 
> On 9/4/2019 4:11 AM, Dr. David Alan Gilbert wrote:
> > * Jagannathan Raman (jag.ra...@oracle.com) wrote:
> > > Allow RAM MemoryRegion to be created from an offset in a file, instead
> > > of allocating at offset of 0 by default. This is needed to synchronize
> > > RAM between QEMU & remote process.
> > > This will be needed for the following patches.
> > > 
> > > Signed-off-by: Jagannathan Raman 
> > > Signed-off-by: John G Johnson 
> > > Signed-off-by: Elena Ufimtseva 
> > > ---
> > >   exec.c| 11 +++
> > >   include/exec/ram_addr.h   |  2 +-
> > >   include/qemu/mmap-alloc.h |  3 ++-
> > >   memory.c  |  2 +-
> > >   util/mmap-alloc.c |  7 ---
> > >   util/oslib-posix.c|  2 +-
> > >   6 files changed, 16 insertions(+), 11 deletions(-)
> > 
> > I'm surprised this doesn't change something in
> > vhost-user.c:vhost_user_set_mem_table so that the vhost-user client
> > knows what it's mapping?
> 
> Hi Dave,
> 
> vhost-user does not use the functions addressed in this patch for
> mapping the RAM onto the remote process. It calls mmap() for this
> purpose (vu_set_mem_table_exec()).

It should at least check that the file it's sending over set-mem-table
has a 0 offset, otherwise things could get confused if someone tries
to run a vhost-user device on a system that's also running multi-process
(which should be a whole world of fun!)

dave

> Thanks!
> --
> Jag
> 
> > 
> > Dave
> > 
> > > diff --git a/exec.c b/exec.c
> > > index 3e78de3..b3f1aa9 100644
> > > --- a/exec.c
> > > +++ b/exec.c
> > > @@ -1885,6 +1885,7 @@ static void *file_ram_alloc(RAMBlock *block,
> > >   ram_addr_t memory,
> > >   int fd,
> > >   bool truncate,
> > > +off_t offset,
> > >   Error **errp)
> > >   {
> > >   MachineState *ms = MACHINE(qdev_get_machine());
> > > @@ -1936,7 +1937,8 @@ static void *file_ram_alloc(RAMBlock *block,
> > >   }
> > >   area = qemu_ram_mmap(fd, memory, block->mr->align,
> > > - block->flags & RAM_SHARED, block->flags & 
> > > RAM_PMEM);
> > > + block->flags & RAM_SHARED, block->flags & 
> > > RAM_PMEM,
> > > + offset);
> > >   if (area == MAP_FAILED) {
> > >   error_setg_errno(errp, errno,
> > >"unable to map backing store for guest RAM");
> > > @@ -2325,7 +2327,7 @@ static void ram_block_add(RAMBlock *new_block, 
> > > Error **errp, bool shared)
> > >   #ifdef CONFIG_POSIX
> > >   RAMBlock *qemu_ram_alloc_from_fd(ram_addr_t size, MemoryRegion *mr,
> > >uint32_t ram_flags, int fd,
> > > - Error **errp)
> > > + off_t offset, Error **errp)
> > >   {
> > >   RAMBlock *new_block;
> > >   Error *local_err = NULL;
> > > @@ -2370,7 +2372,8 @@ RAMBlock *qemu_ram_alloc_from_fd(ram_addr_t size, 
> > > MemoryRegion *mr,
> > >   new_block->used_length = size;
> > >   new_block->max_length = size;
> > >   new_block->flags = ram_flags;
> > > -new_block->host = file_ram_alloc(new_block, size, fd, !file_size, 
> > > errp);
> > > +new_block->host = file_ram_alloc(new_block, size, fd, !file_size, 
> > > offset,
> > > + errp);
> > >   if (!new_block->host) {
> > >   g_free(new_block);
> > >   return NULL;
> > > @@ -2400,7 +2403,7 @@ RAMBlock *qemu_ram_alloc_from_file(ram_addr_t size, 
> > > MemoryRegion *mr,
> > >   return NULL;
> > >   }
> > > -block = qemu_ram_alloc_from_fd(size, mr, ram_flags, fd, errp);
> > > +block = qemu_ram_alloc_from_fd(size, mr, ram_flags, fd, 0, errp);
> > >   if (!block) {
> > >   if (created) {
> > >   unlink(mem_path);
> > > diff --git a/include/exec/ram_addr.h b/include/exec/ram_addr.h
> > > index b7b2e60..15837a1 100644
> > > --- a/include/exec/ram_addr.h
> > > +++ b/include/exec/ram_addr.h
> > > @@ -164,7 +164,7 @@ RAMBlock *qemu_ram_alloc_from_file(ram_addr_t size, 
> > > MemoryRegion *mr,
> > >  Error **errp);
> > >   RAMBlock *qemu_ram_alloc_from_fd(ram_addr_t size, MemoryRegion *mr,
> > >uint32_t ram_flags, int fd,
> > > - Error **errp);
> > > + off_t offset, Error **errp);
> > >   RAMBlock *qemu_ram_alloc_from_ptr(ram_addr_t size, void *host,
> > > MemoryRegion *mr, Error **errp);
> > > diff --git a/include/qemu/mmap-alloc.h b/include/qemu/mmap-alloc.h
> > > index e786266..4f57985 100644
> > > --- a/include/qemu/mmap-alloc.h
> > > +++ b/include/qemu/mmap-alloc.h
> > > @@ -25,7 +25,8 @@ void *qemu_ram_mmap(int fd,
> > >

Re: [Qemu-devel] [RFC v3 PATCH 02/45] multi-process: util: Add qemu_thread_cancel() to cancel running thread

2019-09-05 Thread Jag Raman




On 9/4/2019 5:11 AM, Daniel P. Berrangé wrote:

On Tue, Sep 03, 2019 at 04:37:28PM -0400, Jagannathan Raman wrote:

qemu_thread_cancel() added to destroy a given running thread.
This will be needed in the following patches.


I don't see anything in the following patches that actually uses
this new function.

That is good though, because it is incredibly difficult to
correctly use pthread_cancel() in such a way that you correctly
release all memory and other resources (file descriptors) owned
by the thread being cancelled.

So this looks like it can thankfully be dropped.


Thanks Daniel. Will drop this in the next revision.
--
Jag





Signed-off-by: John G Johnson 
Signed-off-by: Jagannathan Raman 
Signed-off-by: Elena Ufimtseva 
---
  include/qemu/thread.h|  1 +
  util/qemu-thread-posix.c | 10 ++
  2 files changed, 11 insertions(+)


Regards,
Daniel





[Qemu-devel] [Bug 1805256] Re: qemu-img hangs on high core count ARM system

2019-09-05 Thread Rafael David Tinoco
** Changed in: qemu (Ubuntu)
   Status: Confirmed => In Progress

** Changed in: qemu (Ubuntu)
 Assignee: (unassigned) => Rafael David Tinoco (rafaeldtinoco)

** Changed in: qemu (Ubuntu)
   Importance: Undecided => Medium

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

Title:
  qemu-img hangs on high core count ARM system

Status in QEMU:
  Confirmed
Status in qemu package in Ubuntu:
  In Progress

Bug description:
  On the HiSilicon D06 system - a 96 core NUMA arm64 box - qemu-img
  frequently hangs (~50% of the time) with this command:

  qemu-img convert -f qcow2 -O qcow2 /tmp/cloudimg /tmp/cloudimg2

  Where "cloudimg" is a standard qcow2 Ubuntu cloud image. This
  qcow2->qcow2 conversion happens to be something uvtool does every time
  it fetches images.

  Once hung, attaching gdb gives the following backtrace:

  (gdb) bt
  #0  0xae4f8154 in __GI_ppoll (fds=0xe8a67dc0, 
nfds=187650274213760, 
  timeout=, timeout@entry=0x0, sigmask=0xc123b950)
  at ../sysdeps/unix/sysv/linux/ppoll.c:39
  #1  0xbbefaf00 in ppoll (__ss=0x0, __timeout=0x0, __nfds=, 
  __fds=) at /usr/include/aarch64-linux-gnu/bits/poll2.h:77
  #2  qemu_poll_ns (fds=, nfds=, 
  timeout=timeout@entry=-1) at util/qemu-timer.c:322
  #3  0xbbefbf80 in os_host_main_loop_wait (timeout=-1)
  at util/main-loop.c:233
  #4  main_loop_wait (nonblocking=) at util/main-loop.c:497
  #5  0xbbe2aa30 in convert_do_copy (s=0xc123bb58) at 
qemu-img.c:1980
  #6  img_convert (argc=, argv=) at 
qemu-img.c:2456
  #7  0xbbe2333c in main (argc=7, argv=) at 
qemu-img.c:4975

  Reproduced w/ latest QEMU git (@ 53744e0a182)

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



Re: [Qemu-devel] [PATCH v2 1/2] virtio: add vhost-user-fs base device

2019-09-05 Thread Dr. David Alan Gilbert
* Cornelia Huck (coh...@redhat.com) wrote:
> On Fri, 23 Aug 2019 18:56:56 +0100
> "Dr. David Alan Gilbert (git)"  wrote:
> 
> > From: "Dr. David Alan Gilbert" 
> > 
> > The virtio-fs virtio device provides shared file system access using
> > the FUSE protocol carried ovew virtio.
> > The actual file server is implemented in an external vhost-user-fs device
> > backend process.
> > 
> > Signed-off-by: Stefan Hajnoczi 
> > Signed-off-by: Sebastien Boeuf 
> > Signed-off-by: Dr. David Alan Gilbert 
> > ---
> >  configure   |  13 +
> >  hw/virtio/Makefile.objs |   1 +
> >  hw/virtio/vhost-user-fs.c   | 297 
> >  include/hw/virtio/vhost-user-fs.h   |  45 +++
> >  include/standard-headers/linux/virtio_fs.h  |  41 +++
> >  include/standard-headers/linux/virtio_ids.h |   1 +
> >  6 files changed, 398 insertions(+)
> >  create mode 100644 hw/virtio/vhost-user-fs.c
> >  create mode 100644 include/hw/virtio/vhost-user-fs.h
> >  create mode 100644 include/standard-headers/linux/virtio_fs.h
> > 
> 
> > diff --git a/hw/virtio/vhost-user-fs.c b/hw/virtio/vhost-user-fs.c
> > new file mode 100644
> > index 00..72e270d869
> > --- /dev/null
> > +++ b/hw/virtio/vhost-user-fs.c
> > @@ -0,0 +1,297 @@
> > +/*
> > + * Vhost-user filesystem virtio device
> > + *
> > + * Copyright 2018 Red Hat, Inc.
> 
> Should that be 2018, 2019? (Also for vhost-user-fs.h.)

Will fix.

> > + *
> > + * Authors:
> > + *  Stefan Hajnoczi 
> > + *
> > + * This work is licensed under the terms of the GNU GPL, version 2 or
> > + * (at your option) any later version.  See the COPYING file in the
> > + * top-level directory.
> > + */
> > +
> 
> (...)

??

> > +static void vuf_start(VirtIODevice *vdev)
> > +{
> > +VHostUserFS *fs = VHOST_USER_FS(vdev);
> > +BusState *qbus = BUS(qdev_get_parent_bus(DEVICE(vdev)));
> > +VirtioBusClass *k = VIRTIO_BUS_GET_CLASS(qbus);
> > +int ret;
> > +int i;
> > +
> > +if (!k->set_guest_notifiers) {
> > +error_report("binding does not support guest notifiers");
> > +return;
> > +}
> > +
> > +ret = vhost_dev_enable_notifiers(&fs->vhost_dev, vdev);
> > +if (ret < 0) {
> > +error_report("Error enabling host notifiers: %d", -ret);
> > +return;
> > +}
> > +
> > +ret = k->set_guest_notifiers(qbus->parent, fs->vhost_dev.nvqs, true);
> > +if (ret < 0) {
> > +error_report("Error binding guest notifier: %d", -ret);
> > +goto err_host_notifiers;
> > +}
> > +
> > +fs->vhost_dev.acked_features = vdev->guest_features;
> > +ret = vhost_dev_start(&fs->vhost_dev, vdev);
> > +if (ret < 0) {
> > +error_report("Error starting vhost: %d", -ret);
> > +goto err_guest_notifiers;
> > +}
> > +
> > +/*
> > + * guest_notifier_mask/pending not used yet, so just unmask
> > + * everything here.  virtio-pci will do the right thing by
> > + * enabling/disabling irqfd.
> 
> I still think referring to virtio-pci doing the right thing is not the
> right thing here :) Can you spell out _what_ the right thing actually
> is?

mst: Can you look at this?

This appears to be a chunk of code that's copied into many vhost files;
it's in at least vhost-user.c, vhost-user-blk.c, vhost-scsi-common.c and
vhost-vsock.c - it seemns to go back until at least 2013.

> > + */
> > +for (i = 0; i < fs->vhost_dev.nvqs; i++) {
> > +vhost_virtqueue_mask(&fs->vhost_dev, vdev, i, false);
> > +}
> > +
> > +return;
> > +
> > +err_guest_notifiers:
> > +k->set_guest_notifiers(qbus->parent, fs->vhost_dev.nvqs, false);
> > +err_host_notifiers:
> > +vhost_dev_disable_notifiers(&fs->vhost_dev, vdev);
> > +}
> > +
> 
> (...)
> 
> > diff --git a/include/standard-headers/linux/virtio_fs.h 
> > b/include/standard-headers/linux/virtio_fs.h
> > new file mode 100644
> > index 00..00bd7a6fa7
> > --- /dev/null
> > +++ b/include/standard-headers/linux/virtio_fs.h
> 
> This will probably be imported from the Linux source code, right? If
> yes, this should go into a separate patch (and the headers update patch
> probably needs an update.)

OK, will do.

> > @@ -0,0 +1,41 @@
> > +#ifndef _LINUX_VIRTIO_FS_H
> > +#define _LINUX_VIRTIO_FS_H
> > +/* This header is BSD licensed so anyone can use the definitions to 
> > implement
> > + * compatible drivers/servers.
> > + *
> > + * Redistribution and use in source and binary forms, with or without
> > + * modification, are permitted provided that the following conditions
> > + * are met:
> > + * 1. Redistributions of source code must retain the above copyright
> > + *notice, this list of conditions and the following disclaimer.
> > + * 2. Redistributions in binary form must reproduce the above copyright
> > + *notice, this list of conditions and the following disclaimer in the
> > + *documentation and/or other materials provided with the distribution.
> > + * 3. 

Re: [Qemu-devel] [RFC v3 PATCH 01/45] multi-process: memory: alloc RAM from file at offset

2019-09-05 Thread Jag Raman




On 9/4/2019 4:11 AM, Dr. David Alan Gilbert wrote:

* Jagannathan Raman (jag.ra...@oracle.com) wrote:

Allow RAM MemoryRegion to be created from an offset in a file, instead
of allocating at offset of 0 by default. This is needed to synchronize
RAM between QEMU & remote process.
This will be needed for the following patches.

Signed-off-by: Jagannathan Raman 
Signed-off-by: John G Johnson 
Signed-off-by: Elena Ufimtseva 
---
  exec.c| 11 +++
  include/exec/ram_addr.h   |  2 +-
  include/qemu/mmap-alloc.h |  3 ++-
  memory.c  |  2 +-
  util/mmap-alloc.c |  7 ---
  util/oslib-posix.c|  2 +-
  6 files changed, 16 insertions(+), 11 deletions(-)


I'm surprised this doesn't change something in
vhost-user.c:vhost_user_set_mem_table so that the vhost-user client
knows what it's mapping?


Hi Dave,

vhost-user does not use the functions addressed in this patch for
mapping the RAM onto the remote process. It calls mmap() for this
purpose (vu_set_mem_table_exec()).

Thanks!
--
Jag



Dave


diff --git a/exec.c b/exec.c
index 3e78de3..b3f1aa9 100644
--- a/exec.c
+++ b/exec.c
@@ -1885,6 +1885,7 @@ static void *file_ram_alloc(RAMBlock *block,
  ram_addr_t memory,
  int fd,
  bool truncate,
+off_t offset,
  Error **errp)
  {
  MachineState *ms = MACHINE(qdev_get_machine());
@@ -1936,7 +1937,8 @@ static void *file_ram_alloc(RAMBlock *block,
  }
  
  area = qemu_ram_mmap(fd, memory, block->mr->align,

- block->flags & RAM_SHARED, block->flags & RAM_PMEM);
+ block->flags & RAM_SHARED, block->flags & RAM_PMEM,
+ offset);
  if (area == MAP_FAILED) {
  error_setg_errno(errp, errno,
   "unable to map backing store for guest RAM");
@@ -2325,7 +2327,7 @@ static void ram_block_add(RAMBlock *new_block, Error 
**errp, bool shared)
  #ifdef CONFIG_POSIX
  RAMBlock *qemu_ram_alloc_from_fd(ram_addr_t size, MemoryRegion *mr,
   uint32_t ram_flags, int fd,
- Error **errp)
+ off_t offset, Error **errp)
  {
  RAMBlock *new_block;
  Error *local_err = NULL;
@@ -2370,7 +2372,8 @@ RAMBlock *qemu_ram_alloc_from_fd(ram_addr_t size, 
MemoryRegion *mr,
  new_block->used_length = size;
  new_block->max_length = size;
  new_block->flags = ram_flags;
-new_block->host = file_ram_alloc(new_block, size, fd, !file_size, errp);
+new_block->host = file_ram_alloc(new_block, size, fd, !file_size, offset,
+ errp);
  if (!new_block->host) {
  g_free(new_block);
  return NULL;
@@ -2400,7 +2403,7 @@ RAMBlock *qemu_ram_alloc_from_file(ram_addr_t size, 
MemoryRegion *mr,
  return NULL;
  }
  
-block = qemu_ram_alloc_from_fd(size, mr, ram_flags, fd, errp);

+block = qemu_ram_alloc_from_fd(size, mr, ram_flags, fd, 0, errp);
  if (!block) {
  if (created) {
  unlink(mem_path);
diff --git a/include/exec/ram_addr.h b/include/exec/ram_addr.h
index b7b2e60..15837a1 100644
--- a/include/exec/ram_addr.h
+++ b/include/exec/ram_addr.h
@@ -164,7 +164,7 @@ RAMBlock *qemu_ram_alloc_from_file(ram_addr_t size, 
MemoryRegion *mr,
 Error **errp);
  RAMBlock *qemu_ram_alloc_from_fd(ram_addr_t size, MemoryRegion *mr,
   uint32_t ram_flags, int fd,
- Error **errp);
+ off_t offset, Error **errp);
  
  RAMBlock *qemu_ram_alloc_from_ptr(ram_addr_t size, void *host,

MemoryRegion *mr, Error **errp);
diff --git a/include/qemu/mmap-alloc.h b/include/qemu/mmap-alloc.h
index e786266..4f57985 100644
--- a/include/qemu/mmap-alloc.h
+++ b/include/qemu/mmap-alloc.h
@@ -25,7 +25,8 @@ void *qemu_ram_mmap(int fd,
  size_t size,
  size_t align,
  bool shared,
-bool is_pmem);
+bool is_pmem,
+off_t start);
  
  void qemu_ram_munmap(int fd, void *ptr, size_t size);
  
diff --git a/memory.c b/memory.c

index 5d8c9a9..debed5e 100644
--- a/memory.c
+++ b/memory.c
@@ -1622,7 +1622,7 @@ void memory_region_init_ram_from_fd(MemoryRegion *mr,
  mr->destructor = memory_region_destructor_ram;
  mr->ram_block = qemu_ram_alloc_from_fd(size, mr,
 share ? RAM_SHARED : 0,
-   fd, &err);
+   fd, 0, &err);
  mr->dirty_log_mask = tcg_enabled() ? (1 << DIRTY_MEMORY_CODE) : 0;
  if (err) {
  mr->size = int128_zero();
diff --git a/util/mmap-alloc.c b/ut

Re: [Qemu-devel] [PATCH v5 3/3] qcow2: add zstd cluster compression

2019-09-05 Thread Denis Plotnikov
On 05.09.2019 17:31, Eric Blake wrote:
> On 9/5/19 2:44 AM, Denis Plotnikov wrote:
>
>
 +
 +s_size = be32_to_cpu(*(const uint32_t *) src);
>>> As written, this looks like you may be dereferencing an unaligned
>>> pointer.  It so happens that be32_to_cpu() applies & to your * to get
>>> back at the raw pointer, and then is careful to handle unaligned
>>> pointers, so it works; but it would look a lot nicer as merely:
>>>
>>> s_size = be32_to_cpu(src);
>> yes, but I can't use be32_to_cpu(*src) since src is a void pointer
> Then we need the correct ld*_p function; sorry for leading you down the
> wrong path.  Looks like the right one is:
>
> s_size = ldl_be_p(src)
>
> (include/qemu/bswap.h has some good comments, but you have to know they
> exist...)

No problem, that happens. By the way, I've already sent the series using 
ldl_be_p

Thanks!

Denis

>



[Qemu-devel] [Bug 1842925] Re: no batmap on convertion from qcow2 to vhd

2019-09-05 Thread Marat Salakhutdinov
we use vhd-util from link
http://download.cloud.com.s3.amazonaws.com/tools/vhd-util

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

Title:
  no batmap on convertion from qcow2 to vhd

Status in QEMU:
  New

Bug description:
  we run following version of qemu-img:
  $ qemu-img --version
  qemu-img version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.41), Copyright (c) 
2004-2008 Fabrice Bellard
  $

  Here is os version:
  $ cat /etc/os-release 
  NAME="Ubuntu"
  VERSION="16.04.6 LTS (Xenial Xerus)"
  ID=ubuntu
  ID_LIKE=debian
  PRETTY_NAME="Ubuntu 16.04.6 LTS"
  VERSION_ID="16.04"
  HOME_URL="http://www.ubuntu.com/";
  SUPPORT_URL="http://help.ubuntu.com/";
  BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/";
  VERSION_CODENAME=xenial
  UBUNTU_CODENAME=xenial
  $

  When we use qemu-img for conversion of qcow2 to vhd newly created file
  doesnt show batmap summary when we run:

  # vhd-util read -p -n centos76.vhd
  VHD Footer Summary:
  ---
  Cookie  : conectix
  Features: (0x0002) 
  File format version : Major: 1, Minor: 0
  Data offset : 512
  Timestamp   : Mon Mar  4 13:21:27 2019
  Creator Application : 'qemu'
  Creator version : Major: 5, Minor: 3
  Creator OS  : Windows
  Original disk size  : 8192 MB (8590417920 Bytes)
  Current disk size   : 8192 MB (8590417920 Bytes)
  Geometry: Cyl: 16645, Hds: 16, Sctrs: 63
  : = 8192 MB (8590417920 Bytes)
  Disk type   : Dynamic hard disk
  Checksum: 0xf119|0xf119 (Good!)
  UUID: 23772822-a66c-45a2-be37-8474604147c7
  Saved state : No
  Hidden  : 0

  VHD Header Summary:
  ---
  Cookie  : cxsparse
  Data offset (unusd) : 18446744073709
  Table offset: 1536
  Header version  : 0x0001
  Max BAT size: 4097
  Block size  : 2097152 (2 MB)
  Parent name : 
  Parent UUID : ----
  Parent timestamp: Fri Dec 31 19:00:00 1999
  Checksum: 0xf466|0xf466 (Good!)

  #

  I am not so strong in VHD format details and not exactly sure how
  batmap is needed, but when I do conversion of qcow2 image by using
  vhd-util at the end I get file with proper batmap summary.

  In our environment we use CloudStack and Citrix and we use those
  converted from qcow2 to vhd images as templates. In general there is
  no problems, but whenever we create snapshot out of VM created from
  such template vhd-util read command starts giving us error like below:

  #
  ---
  Cookie  : conectix
  Features: (0x0002) 
  File format version : Major: 1, Minor: 0
  Data offset : 512
  Timestamp   : Thu Aug 29 16:04:30 2019
  Creator Application : 'tap'
  Creator version : Major: 1, Minor: 3
  Creator OS  : Unknown!
  Original disk size  : 8194 MB (8592031744 Bytes)
  Current disk size   : 8194 MB (8592031744 Bytes)
  Geometry: Cyl: 16648, Hds: 16, Sctrs: 63
  : = 8193 MB (8591966208 Bytes)
  Disk type   : Dynamic hard disk
  Checksum: 0xf074|0xf074 (Good!)
  UUID: 2b3cac7d-16e1-4771-b8cd-bb8c7876c761
  Saved state : No
  Hidden  : 0

  VHD Header Summary:
  ---
  Cookie  : cxsparse
  Data offset (unusd) : 18446744073709
  Table offset: 1536
  Header version  : 0x0001
  Max BAT size: 4097
  Block size  : 2097152 (2 MB)
  Parent name : 
  Parent UUID : ----
  Parent timestamp: Sat Jan  1 00:00:00 2000
  Checksum: 0xf466|0xf466 (Good!)

  failed to get batmap header

  #

  With the templates that show correct batmap summary that are created
  by conversion of qcow2 image by vhd-util convert we don't have such
  problems.

  So I wanted to check with community if not existence of the batmap can
  cause (be the reason of) this behaviour later on snapshot creation
  stage? Should we always have batmap summary on output of vhd-util read
  command?

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



Re: [Qemu-devel] [PATCH v3 3/4] docs: document use of automatic cleanup functions in glib

2019-09-05 Thread Eric Blake
On 8/29/19 11:50 AM, Daniel P. Berrangé wrote:
> Document the use of g_autofree and g_autoptr in glib for automatic
> freeing of memory.
> 
> Signed-off-by: Daniel P. Berrangé 
> ---
>  CODING_STYLE.rst | 85 
>  1 file changed, 85 insertions(+)
> 
> diff --git a/CODING_STYLE.rst b/CODING_STYLE.rst
> index 4501d87352..39397f0f6f 100644
> --- a/CODING_STYLE.rst
> +++ b/CODING_STYLE.rst
> @@ -441,6 +441,91 @@ In addition, QEMU assumes that the compiler does not use 
> the latitude
>  given in C99 and C11 to treat aspects of signed '<<' as undefined, as
>  documented in the GNU Compiler Collection manual starting at version 4.0.
>  
> +Automatic memory deallocation
> +=
> +
> +QEMU has a mandatory dependency either the GCC or CLang compiler. As

s/either/on either/

> +such it has the freedom to make use of a C language extension for
> +automatically running a cleanup function when a stack variable goes
> +out of scope. This can be used to simplify function cleanup paths,
> +often allowing many goto jumps to be eliminated, through automatic
> +free'ing of memory.
> +

> +
> +For example, instead of
> +
> +.. code-block:: c
> +
> +int somefunc(void) {

Should that { be on its own line to match our prevailing style?

> +int ret = -1;
> +char *foo = g_strdup_printf("foo%", "wibble");
> +GList *bar = .
> +
> +if (eek) {
> +   goto cleanup;
> +}
> +
> +ret = 0;
> +
> +  cleanup:
> +g_free(foo);
> +g_list_free(bar);
> +return ret;
> +}
> +
> +Using g_autofree/g_autoptr enables the code to be written as:
> +
> +.. code-block:: c
> +
> +int somefunc(void) {

here too

> +g_autofree char *foo = g_strdup_printf("foo%", "wibble");
> +g_autoptr (GList) bar = .
> +
> +if (eek) {
> +   return -1;
> +}
> +
> +return 0;
> +}
> +
> +While this generally results in simpler, less leak-prone code, there
> +are still some caveats to beware of
> +
> +* Variables declared with g_auto* MUST always be initialized,
> +  otherwise the cleanup function will use uninitialized stack memory
> +
> +* If a variable declared with g_auto* holds a value which must
> +  live beyond the life of the function, that value must be saved
> +  and the original variable NULL'd out. This can be simpler using
> +  g_steal_pointer
> +
> +
> +.. code-block:: c
> +
> +char *somefunc(void) {

and again

> +g_autofree char *foo = g_strdup_printf("foo%", "wibble");
> +g_autoptr (GList) bar = .
> +
> +if (eek) {
> +   return NULL;
> +}
> +
> +return g_steal_pointer(&foo);
> +}
> +
> +
>  Error handling and reporting
>  
>  
> 

With those fixes,
Reviewed-by: Eric Blake 

-- 
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 v3 2/4] docs: merge HACKING.rst contents into CODING_STYLE.rst

2019-09-05 Thread Eric Blake
On 8/29/19 11:50 AM, Daniel P. Berrangé wrote:
> The split of information between the two docs is rather arbitary and
> unclear. It is simpler for contributors if all the information is in
> one file.
> 
> Signed-off-by: Daniel P. Berrangé 
> ---
>  CODING_STYLE.rst | 296 ++
>  HACKING.rst  | 300 ---
>  README.rst   |   2 +-
>  3 files changed, 297 insertions(+), 301 deletions(-)
>  delete mode 100644 HACKING.rst
> 

Reviewed-by: Eric Blake 

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



signature.asc
Description: OpenPGP digital signature


Re: [Qemu-devel] [RFC v3 PATCH 07/45] multi-process: define proxy-link object

2019-09-05 Thread Eric Blake
On 9/4/19 3:22 AM, Daniel P. Berrangé wrote:
> On Tue, Sep 03, 2019 at 04:37:33PM -0400, Jagannathan Raman wrote:
>> Defines proxy-link object which forms the communication link between
>> QEMU & emulation program.
>> Adds functions to configure members of proxy-link object instance.
>> Adds functions to send and receive messages over the communication
>> channel.
>> Adds GMainLoop to handle events received on the communication channel.

>> +
>> +#ifndef PROXY_LINK_H
>> +#define PROXY_LINK_H
>> +
>> +#include 
>> +#include 
>> +#include 
> 
> I'm guessing this is the cause - nothing should be including this
> directly - it is pulled  in for you via qemu/osdep.h
> 
>> +#include 
>> +
>> +#include "qemu/osdep.h"

For that matter, "qemu/osdep.h" should ALWAYS be listed first, before
any system headers, and inclusion of  and  is also
redundant, just as the .


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



Re: [Qemu-devel] [PATCH v5 3/3] qcow2: add zstd cluster compression

2019-09-05 Thread Eric Blake
On 9/5/19 2:44 AM, Denis Plotnikov wrote:


>>> +
>>> +s_size = be32_to_cpu(*(const uint32_t *) src);
>> As written, this looks like you may be dereferencing an unaligned
>> pointer.  It so happens that be32_to_cpu() applies & to your * to get
>> back at the raw pointer, and then is careful to handle unaligned
>> pointers, so it works; but it would look a lot nicer as merely:
>>
>> s_size = be32_to_cpu(src);
> 
> yes, but I can't use be32_to_cpu(*src) since src is a void pointer

Then we need the correct ld*_p function; sorry for leading you down the
wrong path.  Looks like the right one is:

s_size = ldl_be_p(src)

(include/qemu/bswap.h has some good comments, but you have to know they
exist...)

-- 
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 v6 14/42] block: Use CAFs when working with backing chains

2019-09-05 Thread Kevin Wolf
Am 09.08.2019 um 18:13 hat Max Reitz geschrieben:
> Use child access functions when iterating through backing chains so
> filters do not break the chain.
> 
> Signed-off-by: Max Reitz 
> ---
>  block.c | 40 
>  1 file changed, 28 insertions(+), 12 deletions(-)
> 
> diff --git a/block.c b/block.c
> index 86b84bea21..42abbaf0ba 100644
> --- a/block.c
> +++ b/block.c
> @@ -4376,7 +4376,8 @@ int bdrv_change_backing_file(BlockDriverState *bs,
>  }
>  
>  /*
> - * Finds the image layer in the chain that has 'bs' as its backing file.
> + * Finds the image layer in the chain that has 'bs' (or a filter on
> + * top of it) as its backing file.
>   *
>   * active is the current topmost image.
>   *
> @@ -4388,11 +4389,18 @@ int bdrv_change_backing_file(BlockDriverState *bs,
>  BlockDriverState *bdrv_find_overlay(BlockDriverState *active,
>  BlockDriverState *bs)
>  {
> -while (active && bs != backing_bs(active)) {
> -active = backing_bs(active);
> +bs = bdrv_skip_rw_filters(bs);
> +active = bdrv_skip_rw_filters(active);

This does more than the commit message says. In addition to iterating
through filters instead of stopping, it also changes the semantics of
the function to return the next non-filter on top of bs instead of the
next node.

The block jobs seem to use it only for bdrv_is_allocated_above(), which
should return the same thing in both cases, so the behaviour stays the
same. qmp_block_commit() will check op blockers on a different node now,
which could be a fix or a bug, I can't tell offhand. Probably the
blocking doesn't really work anyway.

All of this should be mentioned in the commit message at least. Maybe
it's also worth splitting in two patches.

> +while (active) {
> +BlockDriverState *next = bdrv_backing_chain_next(active);
> +if (bs == next) {
> +return active;
> +}
> +active = next;
>  }
>  
> -return active;
> +return NULL;
>  }
>  
>  /* Given a BDS, searches for the base layer. */
> @@ -4544,9 +4552,7 @@ int bdrv_drop_intermediate(BlockDriverState *top, 
> BlockDriverState *base,
>   * other intermediate nodes have been dropped.
>   * If 'top' is an implicit node (e.g. "commit_top") we should skip
>   * it because no one inherits from it. We use explicit_top for that. */
> -while (explicit_top && explicit_top->implicit) {
> -explicit_top = backing_bs(explicit_top);
> -}
> +explicit_top = bdrv_skip_implicit_filters(explicit_top);
>  update_inherits_from = bdrv_inherits_from_recursive(base, explicit_top);
>  
>  /* success - we can delete the intermediate states, and link top->base */
> @@ -5014,7 +5020,7 @@ BlockDriverState *bdrv_lookup_bs(const char *device,
>  bool bdrv_chain_contains(BlockDriverState *top, BlockDriverState *base)
>  {
>  while (top && top != base) {
> -top = backing_bs(top);
> +top = bdrv_filtered_bs(top);
>  }
>  
>  return top != NULL;
> @@ -5253,7 +5259,17 @@ BlockDriverState 
> *bdrv_find_backing_image(BlockDriverState *bs,
>  
>  is_protocol = path_has_protocol(backing_file);
>  
> -for (curr_bs = bs; curr_bs->backing; curr_bs = curr_bs->backing->bs) {
> +/*
> + * Being largely a legacy function, skip any filters here
> + * (because filters do not have normal filenames, so they cannot
> + * match anyway; and allowing json:{} filenames is a bit out of
> + * scope).
> + */
> +for (curr_bs = bdrv_skip_rw_filters(bs);
> + bdrv_filtered_cow_child(curr_bs) != NULL;
> + curr_bs = bdrv_backing_chain_next(curr_bs))

This could just use bs_below instead of recalculating the node if you
moved the declaration of bs_below to the function scope.

> +{
> +BlockDriverState *bs_below = bdrv_backing_chain_next(curr_bs);
>  
>  /* If either of the filename paths is actually a protocol, then
>   * compare unmodified paths; otherwise make paths relative */
> @@ -5261,7 +5277,7 @@ BlockDriverState 
> *bdrv_find_backing_image(BlockDriverState *bs,
>  char *backing_file_full_ret;
>  
>  if (strcmp(backing_file, curr_bs->backing_file) == 0) {
> -retval = curr_bs->backing->bs;
> +retval = bs_below;
>  break;
>  }
>  /* Also check against the full backing filename for the image */
> @@ -5271,7 +5287,7 @@ BlockDriverState 
> *bdrv_find_backing_image(BlockDriverState *bs,
>  bool equal = strcmp(backing_file, backing_file_full_ret) == 
> 0;
>  g_free(backing_file_full_ret);
>  if (equal) {
> -retval = curr_bs->backing->bs;
> +retval = bs_below;
>  break;
>  }
>  }
> @@ -5297,7 +5313,7 @@ BlockDriverState 
> *bdrv_find_backing_image(BlockDriverState *bs,
>  g_fr

Re: [Qemu-devel] Cryptic errors from PIP install if missing openssl-devel

2019-09-05 Thread Eduardo Habkost
On Thu, Sep 05, 2019 at 09:38:24AM -0400, Cleber Rosa wrote:
> On Thu, Sep 05, 2019 at 12:09:24PM +1000, David Gibson wrote:
> > On Wed, Sep 04, 2019 at 03:57:17PM -0400, Cleber Rosa wrote:
> > > 
> > > Hi David,
> > > 
> > > I've pushed a branch here (most of the commits have already been sent
> > > separately):
> > > 
> > >https://github.com/clebergnu/qemu/tree/ppc64
> > > 
> > > I've tested on a RHEL 8 ppc64le Power 9, and it seems to work for me.
> > > My steps for building QEMU:
> > > 
> > >   - Configured with: '/home/cleber/src/qemu/configure' 
> > > '--enable-slirp=git' '--python=/usr/bin/python3' 
> > > '--target-list=x86_64-softmmu,ppc64-softmmu,arm-softmmu,aarch64-softmmu,mips-softmmu,mipsel-softmmu,mips64-softmmu,mips64el-softmmu,sh4-softmmu,s390x-softmmu,alpha-softmmu,m68k-softmmu,riscv64-softmmu'
> > >   - make
> > >   - make check-acceptance
> > > 
> > > Would you be able to test if that branch works smoothly for you?
> > 
> > So, with this tree I'm no longer getting problems if openssl-devel is
> > not installed, so that much looks good.
> > 
> > I am getting some different errors - I was seeing this before (with
> > openssl-devel installed) sometimes, but only sometimes.  I haven't yet
> > worked out a pattern for when they appeared.  They also don't appear
> > to be fatal, the rest of the tests seem to be running ok.  Any ideas?
> > 
> >  VENV/home/dwg/qemu/build/rhel8/tests/venv
> >   PIP /home/dwg/qemu/tests/requirements.txt
> >   AVOCADO tests/acceptance
> > Error running method "run" of plugin "html": 'Namespace' object has no 
> > attribute 'get'
> > Error running method "run" of plugin "varianter_cit": 'Namespace' object 
> > has no attribute 'get'
> 
> Hi David,
> 
> Yes, those should not be fatal.  Anyway, they are caused by two things:
> 
>  1) A second set of Avocado plugins installation with different versions
> than the Avocado installation on QEMU's tests venv
> 
>  2) The tests' venv, which is created with "--system-site-packages",
> option that is described as "Give the virtual environment access
> to the system site-packages dir."
> 
> The motivation to have "--system-site-packages" is that, if the user
> had any of the "requirements.txt" depedencies installed system wide,
> the venv would simply use it and skip downloads.  Maybe we should make
> that an optional feature, disabled by default, so that the test's venv
> is better isolated and more predictable by default.
> 
> Eduardo,
> 
> I remember we discussed #2, so your opinion is appreciated here.

I think I was the person who insisted for --system-site-packages.
Considering that we're often using very recent versions of
Avocado, maybe trying to use system-provided Avocado modules by
default wasn't a good idea after all.

Making --system-site-packages optional and not enabling it by
default sounds like a reasonable workaround.

-- 
Eduardo



Re: [Qemu-devel] [Qemu-arm] [PATCH v5 01/17] target/arm: Split out rebuild_hflags_common

2019-09-05 Thread Alex Bennée


Richard Henderson  writes:

> Create a function to compute the values of the TBFLAG_ANY bits
> that will be cached.  For now, the env->hflags variable is not
> used, and the results are fed back to cpu_get_tb_cpu_state.
>
> Signed-off-by: Richard Henderson 

Reviewed-by: Alex Bennée 

> ---
>  target/arm/cpu.h| 29 ++---
>  target/arm/helper.c | 26 +++---
>  2 files changed, 37 insertions(+), 18 deletions(-)
>
> diff --git a/target/arm/cpu.h b/target/arm/cpu.h
> index 0981303170..3dc52c032b 100644
> --- a/target/arm/cpu.h
> +++ b/target/arm/cpu.h
> @@ -231,6 +231,9 @@ typedef struct CPUARMState {
>  uint32_t pstate;
>  uint32_t aarch64; /* 1 if CPU is in aarch64 state; inverse of PSTATE.nRW 
> */
>
> +/* Cached TBFLAGS state.  See below for which bits are included.  */
> +uint32_t hflags;
> +
>  /* Frequently accessed CPSR bits are stored separately for efficiency.
> This contains all the other bits.  Use cpsr_{read,write} to access
> the whole CPSR.  */
> @@ -3136,15 +3139,18 @@ typedef ARMCPU ArchCPU;
>
>  #include "exec/cpu-all.h"
>
> -/* Bit usage in the TB flags field: bit 31 indicates whether we are
> +/*
> + * Bit usage in the TB flags field: bit 31 indicates whether we are
>   * in 32 or 64 bit mode. The meaning of the other bits depends on that.
>   * We put flags which are shared between 32 and 64 bit mode at the top
>   * of the word, and flags which apply to only one mode at the bottom.
> + *
> + * Unless otherwise noted, these bits are cached in env->hflags.
>   */
>  FIELD(TBFLAG_ANY, AARCH64_STATE, 31, 1)
>  FIELD(TBFLAG_ANY, MMUIDX, 28, 3)
>  FIELD(TBFLAG_ANY, SS_ACTIVE, 27, 1)
> -FIELD(TBFLAG_ANY, PSTATE_SS, 26, 1)
> +FIELD(TBFLAG_ANY, PSTATE_SS, 26, 1) /* Not cached. */
>  /* Target EL if we take a floating-point-disabled exception */
>  FIELD(TBFLAG_ANY, FPEXC_EL, 24, 2)
>  FIELD(TBFLAG_ANY, BE_DATA, 23, 1)
> @@ -3155,13 +3161,14 @@ FIELD(TBFLAG_ANY, BE_DATA, 23, 1)
>  FIELD(TBFLAG_ANY, DEBUG_TARGET_EL, 21, 2)
>
>  /* Bit usage when in AArch32 state: */
> -FIELD(TBFLAG_A32, THUMB, 0, 1)
> -FIELD(TBFLAG_A32, VECLEN, 1, 3)
> -FIELD(TBFLAG_A32, VECSTRIDE, 4, 2)
> +FIELD(TBFLAG_A32, THUMB, 0, 1)  /* Not cached. */
> +FIELD(TBFLAG_A32, VECLEN, 1, 3) /* Not cached. */
> +FIELD(TBFLAG_A32, VECSTRIDE, 4, 2)  /* Not cached. */
>  /*
>   * We store the bottom two bits of the CPAR as TB flags and handle
>   * checks on the other bits at runtime. This shares the same bits as
>   * VECSTRIDE, which is OK as no XScale CPU has VFP.
> + * Not cached, because VECLEN+VECSTRIDE are not cached.
>   */
>  FIELD(TBFLAG_A32, XSCALE_CPAR, 4, 2)
>  /*
> @@ -3170,15 +3177,15 @@ FIELD(TBFLAG_A32, XSCALE_CPAR, 4, 2)
>   * the same thing as the current security state of the processor!
>   */
>  FIELD(TBFLAG_A32, NS, 6, 1)
> -FIELD(TBFLAG_A32, VFPEN, 7, 1)
> -FIELD(TBFLAG_A32, CONDEXEC, 8, 8)
> +FIELD(TBFLAG_A32, VFPEN, 7, 1)  /* Not cached. */
> +FIELD(TBFLAG_A32, CONDEXEC, 8, 8)   /* Not cached. */
>  FIELD(TBFLAG_A32, SCTLR_B, 16, 1)
>  /* For M profile only, set if FPCCR.LSPACT is set */
> -FIELD(TBFLAG_A32, LSPACT, 18, 1)
> +FIELD(TBFLAG_A32, LSPACT, 18, 1)/* Not cached. */
>  /* For M profile only, set if we must create a new FP context */
> -FIELD(TBFLAG_A32, NEW_FP_CTXT_NEEDED, 19, 1)
> +FIELD(TBFLAG_A32, NEW_FP_CTXT_NEEDED, 19, 1) /* Not cached. */
>  /* For M profile only, set if FPCCR.S does not match current security state 
> */
> -FIELD(TBFLAG_A32, FPCCR_S_WRONG, 20, 1)
> +FIELD(TBFLAG_A32, FPCCR_S_WRONG, 20, 1) /* Not cached. */
>  /* For M profile only, Handler (ie not Thread) mode */
>  FIELD(TBFLAG_A32, HANDLER, 21, 1)
>  /* For M profile only, whether we should generate stack-limit checks */
> @@ -3190,7 +3197,7 @@ FIELD(TBFLAG_A64, SVEEXC_EL, 2, 2)
>  FIELD(TBFLAG_A64, ZCR_LEN, 4, 4)
>  FIELD(TBFLAG_A64, PAUTH_ACTIVE, 8, 1)
>  FIELD(TBFLAG_A64, BT, 9, 1)
> -FIELD(TBFLAG_A64, BTYPE, 10, 2)
> +FIELD(TBFLAG_A64, BTYPE, 10, 2) /* Not cached. */
>  FIELD(TBFLAG_A64, TBID, 12, 2)
>
>  static inline bool bswap_code(bool sctlr_b)
> diff --git a/target/arm/helper.c b/target/arm/helper.c
> index 7e0d5398ab..f2c6419369 100644
> --- a/target/arm/helper.c
> +++ b/target/arm/helper.c
> @@ -11016,6 +11016,22 @@ ARMMMUIdx arm_stage1_mmu_idx(CPUARMState *env)
>  }
>  #endif
>
> +static uint32_t rebuild_hflags_common(CPUARMState *env, int fp_el,
> +  ARMMMUIdx mmu_idx, uint32_t flags)
> +{
> +flags = FIELD_DP32(flags, TBFLAG_ANY, FPEXC_EL, fp_el);
> +flags = FIELD_DP32(flags, TBFLAG_ANY, MMUIDX,
> +   arm_to_core_mmu_idx(mmu_idx));
> +
> +if (arm_cpu_data_is_big_endian(env)) {
> +flags = FIELD_DP32(flags, TBFLAG_ANY, BE_DATA, 1);
> +}
> +if (arm_singlestep_active(env)) {
> +flags = FIELD_DP32(flags, TBFLAG_ANY, SS_ACTIVE, 1);
> +}
> +return flags;
> +}
> +
>  void cpu_get_tb_cpu_stat

Re: [Qemu-devel] [PATCH] gitlab-ci.yml: Install libattr1-dev and libcap-dev to test virtio-9p

2019-09-05 Thread Thomas Huth
On 05/09/2019 14.21, Greg Kurz wrote:
> On Thu,  5 Sep 2019 13:17:29 +0200
> Thomas Huth  wrote:
> 
>> So far the gitlab-ci was not testing virtio-9p yet, since we did not
>> install libattr1-dev and libcap-dev in any of the pipelines. Do it
>> now to get some more test coverage.
>>
>> Signed-off-by: Thomas Huth 
>> ---
>>  .gitlab-ci.yml | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
>> index cd4c03372b..ed8067f5cf 100644
>> --- a/.gitlab-ci.yml
>> +++ b/.gitlab-ci.yml
>> @@ -59,7 +59,7 @@ build-user:
>>  
>>  build-clang:
>>   script:
>> - - apt-get install -y -qq clang libsdl2-dev
>> + - apt-get install -y -qq clang libsdl2-dev libattr1-dev libcap-dev
>>xfslibs-dev libiscsi-dev libnfs-dev libseccomp-dev gnutls-dev 
>> librbd-dev
>>   - ./configure --cc=clang --cxx=clang++ --enable-werror
>>--target-list="alpha-softmmu arm-softmmu m68k-softmmu mips64-softmmu
> 
> I don't know gitlab-ci at all but shouldn't these libs be added to some
> other builds as well ?

Currently the "features" are distributed over the different pipelines,
so that the build in total does not take too long. Looking at how long
the travis stuff takes, I'd also like to try to keep it short here.

 Thomas



Re: [Qemu-devel] [PATCH v5 16/17] target/arm: Rebuild hflags at EL changes and MSR writes

2019-09-05 Thread Alex Bennée


Richard Henderson  writes:

> Now setting, but not relying upon, env->hflags.
>
> Signed-off-by: Richard Henderson 
> ---
>  linux-user/syscall.c   |  1 +
>  target/arm/cpu.c   |  1 +
>  target/arm/helper-a64.c|  3 +++
>  target/arm/helper.c|  2 ++
>  target/arm/machine.c   |  1 +
>  target/arm/op_helper.c |  1 +
>  target/arm/translate-a64.c |  6 +-
>  target/arm/translate.c | 18 --
>  8 files changed, 30 insertions(+), 3 deletions(-)
>
> diff --git a/linux-user/syscall.c b/linux-user/syscall.c
> index 8b41a03901..be01c33759 100644


I had to manually fix these up due to the patch failing to apply. I
think because 9e9b10c64911 removes the gen_io_end() calls.

> diff --git a/target/arm/translate-a64.c b/target/arm/translate-a64.c
> index fc3e5f5c38..4412c60383 100644
> --- a/target/arm/translate-a64.c
> +++ b/target/arm/translate-a64.c
> @@ -1777,11 +1777,15 @@ static void handle_sys(DisasContext *s, uint32_t 
> insn, bool isread,
>  /* I/O operations must end the TB here (whether read or write) */
>  gen_io_end();
>  s->base.is_jmp = DISAS_UPDATE;
> -} else if (!isread && !(ri->type & ARM_CP_SUPPRESS_TB_END)) {
> +}
> +if (!isread && !(ri->type & ARM_CP_SUPPRESS_TB_END)) {
>  /* We default to ending the TB on a coprocessor register write,
>   * but allow this to be suppressed by the register definition
>   * (usually only necessary to work around guest bugs).
>   */
> +TCGv_i32 tcg_el = tcg_const_i32(s->current_el);
> +gen_helper_rebuild_hflags_a64(cpu_env, tcg_el);
> +tcg_temp_free_i32(tcg_el);
>  s->base.is_jmp = DISAS_UPDATE;
>  }
>  }
> diff --git a/target/arm/translate.c b/target/arm/translate.c
> index d948757131..2f7beca065 100644
> --- a/target/arm/translate.c
> +++ b/target/arm/translate.c
> @@ -7130,6 +7130,8 @@ static int disas_coproc_insn(DisasContext *s, uint32_t 
> insn)
>  ri = get_arm_cp_reginfo(s->cp_regs,
>  ENCODE_CP_REG(cpnum, is64, s->ns, crn, crm, opc1, opc2));
>  if (ri) {
> +bool need_exit_tb;
> +
>  /* Check access permissions */
>  if (!cp_access_ok(s->current_el, ri, isread)) {
>  return 1;
> @@ -7301,15 +7303,27 @@ static int disas_coproc_insn(DisasContext *s, 
> uint32_t insn)
>  }
>  }
>
> +need_exit_tb = false;
>  if ((tb_cflags(s->base.tb) & CF_USE_ICOUNT) && (ri->type & 
> ARM_CP_IO)) {
>  /* I/O operations must end the TB here (whether read or write) */
>  gen_io_end();
> -gen_lookup_tb(s);
> -} else if (!isread && !(ri->type & ARM_CP_SUPPRESS_TB_END)) {
> +need_exit_tb = true;
> +}
> +if (!isread && !(ri->type & ARM_CP_SUPPRESS_TB_END)) {
>  /* We default to ending the TB on a coprocessor register write,
>   * but allow this to be suppressed by the register definition
>   * (usually only necessary to work around guest bugs).
>   */
> +TCGv_i32 tcg_el = tcg_const_i32(s->current_el);
> +if (arm_dc_feature(s, ARM_FEATURE_M)) {
> +gen_helper_rebuild_hflags_m32(cpu_env, tcg_el);
> +} else {
> +gen_helper_rebuild_hflags_a32(cpu_env, tcg_el);
> +}
> +tcg_temp_free_i32(tcg_el);
> +need_exit_tb = true;
> +}
> +if (need_exit_tb) {
>  gen_lookup_tb(s);
>  }


--
Alex Bennée



[Qemu-devel] [PULL 2/4] docs: merge HACKING.rst contents into CODING_STYLE.rst

2019-09-05 Thread Daniel P . Berrangé
The split of information between the two docs is rather arbitary and
unclear. It is simpler for contributors if all the information is in
one file.

Reviewed-by: Alex Bennée 
Signed-off-by: Daniel P. Berrangé 
---
 CODING_STYLE.rst | 296 ++
 HACKING.rst  | 300 ---
 README.rst   |   2 +-
 3 files changed, 297 insertions(+), 301 deletions(-)
 delete mode 100644 HACKING.rst

diff --git a/CODING_STYLE.rst b/CODING_STYLE.rst
index 713357cb80..4501d87352 100644
--- a/CODING_STYLE.rst
+++ b/CODING_STYLE.rst
@@ -205,6 +205,302 @@ comment anyway.)
 Rationale: Consistency, and ease of visually picking out a multiline
 comment from the surrounding code.
 
+Preprocessor
+
+
+Variadic macros
+---
+
+For variadic macros, stick with this C99-like syntax:
+
+.. code-block:: c
+
+#define DPRINTF(fmt, ...)   \
+do { printf("IRQ: " fmt, ## __VA_ARGS__); } while (0)
+
+Include directives
+--
+
+Order include directives as follows:
+
+.. code-block:: c
+
+#include "qemu/osdep.h"  /* Always first... */
+#include <...>   /* then system headers... */
+#include "..."   /* and finally QEMU headers. */
+
+The "qemu/osdep.h" header contains preprocessor macros that affect the behavior
+of core system headers like .  It must be the first include so that
+core system headers included by external libraries get the preprocessor macros
+that QEMU depends on.
+
+Do not include "qemu/osdep.h" from header files since the .c file will have
+already included it.
+
+C types
+===
+
+It should be common sense to use the right type, but we have collected
+a few useful guidelines here.
+
+Scalars
+---
+
+If you're using "int" or "long", odds are good that there's a better type.
+If a variable is counting something, it should be declared with an
+unsigned type.
+
+If it's host memory-size related, size_t should be a good choice (use
+ssize_t only if required). Guest RAM memory offsets must use ram_addr_t,
+but only for RAM, it may not cover whole guest address space.
+
+If it's file-size related, use off_t.
+If it's file-offset related (i.e., signed), use off_t.
+If it's just counting small numbers use "unsigned int";
+(on all but oddball embedded systems, you can assume that that
+type is at least four bytes wide).
+
+In the event that you require a specific width, use a standard type
+like int32_t, uint32_t, uint64_t, etc.  The specific types are
+mandatory for VMState fields.
+
+Don't use Linux kernel internal types like u32, __u32 or __le32.
+
+Use hwaddr for guest physical addresses except pcibus_t
+for PCI addresses.  In addition, ram_addr_t is a QEMU internal address
+space that maps guest RAM physical addresses into an intermediate
+address space that can map to host virtual address spaces.  Generally
+speaking, the size of guest memory can always fit into ram_addr_t but
+it would not be correct to store an actual guest physical address in a
+ram_addr_t.
+
+For CPU virtual addresses there are several possible types.
+vaddr is the best type to use to hold a CPU virtual address in
+target-independent code. It is guaranteed to be large enough to hold a
+virtual address for any target, and it does not change size from target
+to target. It is always unsigned.
+target_ulong is a type the size of a virtual address on the CPU; this means
+it may be 32 or 64 bits depending on which target is being built. It should
+therefore be used only in target-specific code, and in some
+performance-critical built-per-target core code such as the TLB code.
+There is also a signed version, target_long.
+abi_ulong is for the ``*``-user targets, and represents a type the size of
+'void ``*``' in that target's ABI. (This may not be the same as the size of a
+full CPU virtual address in the case of target ABIs which use 32 bit pointers
+on 64 bit CPUs, like sparc32plus.) Definitions of structures that must match
+the target's ABI must use this type for anything that on the target is defined
+to be an 'unsigned long' or a pointer type.
+There is also a signed version, abi_long.
+
+Of course, take all of the above with a grain of salt.  If you're about
+to use some system interface that requires a type like size_t, pid_t or
+off_t, use matching types for any corresponding variables.
+
+Also, if you try to use e.g., "unsigned int" as a type, and that
+conflicts with the signedness of a related variable, sometimes
+it's best just to use the *wrong* type, if "pulling the thread"
+and fixing all related variables would be too invasive.
+
+Finally, while using descriptive types is important, be careful not to
+go overboard.  If whatever you're doing causes warnings, or requires
+casts, then reconsider or ask for help.
+
+Pointers
+
+
+Ensure that all of your pointers are "const-correct".
+Unless a pointer is used to modify the pointed-to storage,
+gi

[Qemu-devel] [PULL 4/4] docs: split the CODING_STYLE doc into distinct groups

2019-09-05 Thread Daniel P . Berrangé
Reviewed-by: Peter Maydell 
Signed-off-by: Daniel P. Berrangé 
---
 CODING_STYLE.rst | 9 +
 1 file changed, 9 insertions(+)

diff --git a/CODING_STYLE.rst b/CODING_STYLE.rst
index 39397f0f6f..427699e0e4 100644
--- a/CODING_STYLE.rst
+++ b/CODING_STYLE.rst
@@ -7,6 +7,9 @@ QEMU Coding Style
 Please use the script checkpatch.pl in the scripts directory to check
 patches before submitting.
 
+Formatting and style
+
+
 Whitespace
 ==
 
@@ -205,6 +208,9 @@ comment anyway.)
 Rationale: Consistency, and ease of visually picking out a multiline
 comment from the surrounding code.
 
+Language usage
+**
+
 Preprocessor
 
 
@@ -526,6 +532,9 @@ are still some caveats to beware of
 }
 
 
+QEMU Specific Idioms
+
+
 Error handling and reporting
 
 
-- 
2.21.0




[Qemu-devel] [PULL 1/4] docs: convert README, CODING_STYLE and HACKING to RST syntax

2019-09-05 Thread Daniel P . Berrangé
Reviewed-by: Alex Bennée 
Signed-off-by: Daniel P. Berrangé 
---
 CODING_STYLE => CODING_STYLE.rst | 121 +++---
 HACKING => HACKING.rst   | 123 +--
 README => README.rst |  47 +++-
 scripts/checkpatch.pl|   2 +-
 4 files changed, 191 insertions(+), 102 deletions(-)
 rename CODING_STYLE => CODING_STYLE.rst (72%)
 rename HACKING => HACKING.rst (79%)
 rename README => README.rst (84%)

diff --git a/CODING_STYLE b/CODING_STYLE.rst
similarity index 72%
rename from CODING_STYLE
rename to CODING_STYLE.rst
index cb8edcbb36..713357cb80 100644
--- a/CODING_STYLE
+++ b/CODING_STYLE.rst
@@ -1,10 +1,14 @@
+=
 QEMU Coding Style
 =
 
+.. contents:: Table of Contents
+
 Please use the script checkpatch.pl in the scripts directory to check
 patches before submitting.
 
-1. Whitespace
+Whitespace
+==
 
 Of course, the most important aspect in any coding style is whitespace.
 Crusty old coders who have trouble spotting the glasses on their noses
@@ -16,26 +20,27 @@ QEMU indents are four spaces.  Tabs are never used, except 
in Makefiles
 where they have been irreversibly coded into the syntax.
 Spaces of course are superior to tabs because:
 
- - You have just one way to specify whitespace, not two.  Ambiguity breeds
-   mistakes.
- - The confusion surrounding 'use tabs to indent, spaces to justify' is gone.
- - Tab indents push your code to the right, making your screen seriously
-   unbalanced.
- - Tabs will be rendered incorrectly on editors who are misconfigured not
-   to use tab stops of eight positions.
- - Tabs are rendered badly in patches, causing off-by-one errors in almost
-   every line.
- - It is the QEMU coding style.
+* You have just one way to specify whitespace, not two.  Ambiguity breeds
+  mistakes.
+* The confusion surrounding 'use tabs to indent, spaces to justify' is gone.
+* Tab indents push your code to the right, making your screen seriously
+  unbalanced.
+* Tabs will be rendered incorrectly on editors who are misconfigured not
+  to use tab stops of eight positions.
+* Tabs are rendered badly in patches, causing off-by-one errors in almost
+  every line.
+* It is the QEMU coding style.
 
 Do not leave whitespace dangling off the ends of lines.
 
-1.1 Multiline Indent
+Multiline Indent
+
 
 There are several places where indent is necessary:
 
- - if/else
- - while/for
- - function definition & call
+* if/else
+* while/for
+* function definition & call
 
 When breaking up a long line to fit within line width, we need a proper indent
 for the following lines.
@@ -45,6 +50,8 @@ opening parenthesis of the first.
 
 For example:
 
+.. code-block:: c
+
 if (a == 1 &&
 b == 2) {
 
@@ -53,12 +60,13 @@ For example:
 
 In case of function, there are several variants:
 
-* 4 spaces indent from the beginning
-* align the secondary lines just after the opening parenthesis of the
-  first
+* 4 spaces indent from the beginning
+* align the secondary lines just after the opening parenthesis of the first
 
 For example:
 
+.. code-block:: c
+
 do_something(x, y,
 z);
 
@@ -68,7 +76,8 @@ For example:
 do_something(x, do_another(y,
z));
 
-2. Line width
+Line width
+==
 
 Lines should be 80 characters; try not to make them longer.
 
@@ -77,16 +86,18 @@ that use long function or symbol names.  Even in that case, 
do not make
 lines much longer than 80 characters.
 
 Rationale:
- - Some people like to tile their 24" screens with a 6x4 matrix of 80x24
-   xterms and use vi in all of them.  The best way to punish them is to
-   let them keep doing it.
- - Code and especially patches is much more readable if limited to a sane
-   line length.  Eighty is traditional.
- - The four-space indentation makes the most common excuse ("But look
-   at all that white space on the left!") moot.
- - It is the QEMU coding style.
 
-3. Naming
+* Some people like to tile their 24" screens with a 6x4 matrix of 80x24
+  xterms and use vi in all of them.  The best way to punish them is to
+  let them keep doing it.
+* Code and especially patches is much more readable if limited to a sane
+  line length.  Eighty is traditional.
+* The four-space indentation makes the most common excuse ("But look
+  at all that white space on the left!") moot.
+* It is the QEMU coding style.
+
+Naming
+==
 
 Variables are lower_case_with_underscores; easy to type and read.  Structured
 type names are in CamelCase; harder to type but standing out.  Enum type
@@ -95,10 +106,11 @@ names are lower_case_with_underscores_ending_with_a_t, 
like the POSIX
 uint64_t and family.  Note that this last convention contradicts POSIX
 and is therefore likely to be changed.
 
-When wrapping standard library functions, use the prefix qemu_ to alert
+When wrapping standard library functions, use the prefix ``qemu_`` to alert
 readers that they are

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

2019-09-05 Thread Daniel P . Berrangé
The following changes since commit 500efcfcf0fe2e0dae1d25637a13435ce7b6e421:

  Merge remote-tracking branch 'remotes/rth/tags/pull-or1k-20190904' into 
staging (2019-09-05 09:33:01 +0100)

are available in the Git repository at:

  https://github.com/berrange/qemu tags/docs-pull-request

for you to fetch changes up to 9f8efa74d3f1cb9c957ee382c2b4feb2ae30:

  docs: split the CODING_STYLE doc into distinct groups (2019-09-05 14:41:00 
+0100)



* Merges HACKING into CODING_STYLE
* Converts README and CODING_STYLE docs into RST syntax
* Documents use of auto cleanup functions



Daniel P. Berrangé (4):
  docs: convert README, CODING_STYLE and HACKING to RST syntax
  docs: merge HACKING.rst contents into CODING_STYLE.rst
  docs: document use of automatic cleanup functions in glib
  docs: split the CODING_STYLE doc into distinct groups

 CODING_STYLE  | 216 --
 CODING_STYLE.rst  | 641 ++
 HACKING   | 257 -
 README => README.rst  |  47 ++--
 scripts/checkpatch.pl |   2 +-
 5 files changed, 671 insertions(+), 492 deletions(-)
 delete mode 100644 CODING_STYLE
 create mode 100644 CODING_STYLE.rst
 delete mode 100644 HACKING
 rename README => README.rst (84%)

-- 
2.21.0




[Qemu-devel] [PULL 3/4] docs: document use of automatic cleanup functions in glib

2019-09-05 Thread Daniel P . Berrangé
Document the use of g_autofree and g_autoptr in glib for automatic
freeing of memory.

Reviewed-by: Alex Bennée 
Signed-off-by: Daniel P. Berrangé 
---
 CODING_STYLE.rst | 85 
 1 file changed, 85 insertions(+)

diff --git a/CODING_STYLE.rst b/CODING_STYLE.rst
index 4501d87352..39397f0f6f 100644
--- a/CODING_STYLE.rst
+++ b/CODING_STYLE.rst
@@ -441,6 +441,91 @@ In addition, QEMU assumes that the compiler does not use 
the latitude
 given in C99 and C11 to treat aspects of signed '<<' as undefined, as
 documented in the GNU Compiler Collection manual starting at version 4.0.
 
+Automatic memory deallocation
+=
+
+QEMU has a mandatory dependency either the GCC or CLang compiler. As
+such it has the freedom to make use of a C language extension for
+automatically running a cleanup function when a stack variable goes
+out of scope. This can be used to simplify function cleanup paths,
+often allowing many goto jumps to be eliminated, through automatic
+free'ing of memory.
+
+The GLib2 library provides a number of functions/macros for enabling
+automatic cleanup:
+
+  ``_
+
+Most notably:
+
+* g_autofree - will invoke g_free() on the variable going out of scope
+
+* g_autoptr - for structs / objects, will invoke the cleanup func created
+  by a previous use of G_DEFINE_AUTOPTR_CLEANUP_FUNC. This is
+  supported for most GLib data types and GObjects
+
+For example, instead of
+
+.. code-block:: c
+
+int somefunc(void) {
+int ret = -1;
+char *foo = g_strdup_printf("foo%", "wibble");
+GList *bar = .
+
+if (eek) {
+   goto cleanup;
+}
+
+ret = 0;
+
+  cleanup:
+g_free(foo);
+g_list_free(bar);
+return ret;
+}
+
+Using g_autofree/g_autoptr enables the code to be written as:
+
+.. code-block:: c
+
+int somefunc(void) {
+g_autofree char *foo = g_strdup_printf("foo%", "wibble");
+g_autoptr (GList) bar = .
+
+if (eek) {
+   return -1;
+}
+
+return 0;
+}
+
+While this generally results in simpler, less leak-prone code, there
+are still some caveats to beware of
+
+* Variables declared with g_auto* MUST always be initialized,
+  otherwise the cleanup function will use uninitialized stack memory
+
+* If a variable declared with g_auto* holds a value which must
+  live beyond the life of the function, that value must be saved
+  and the original variable NULL'd out. This can be simpler using
+  g_steal_pointer
+
+
+.. code-block:: c
+
+char *somefunc(void) {
+g_autofree char *foo = g_strdup_printf("foo%", "wibble");
+g_autoptr (GList) bar = .
+
+if (eek) {
+   return NULL;
+}
+
+return g_steal_pointer(&foo);
+}
+
+
 Error handling and reporting
 
 
-- 
2.21.0




  1   2   >