Re: [Qemu-devel] kvm_intel fails to load on Conroe CPUs running Linux 4.12

[Paolo Bonzini]

On 15/09/2017 16:43, Gerhard Wiesinger wrote:
> On 27.08.2017 20:55, Paolo Bonzini wrote:
>>
>>
>> Il 27 ago 2017 4:48 PM, "Gerhard Wiesinger" > > ha scritto:
>>
>> On 27.08.2017 14 :03, Paolo Bonzini wrote:
>>
>>
>> We will revert the patch, but 4.13.0 will not have the fix.
>> Expect it in later stable kernels (because vacations).
>>
>>
>> Thnx. Why will 4.13.0 NOT have the fix?
>>
>>
>> Because maintainers are on vacation! :-)
>>
>>
> 
> Hello Paolo,
> 
> Any update on this for 4.12 and 4.13 kernels?

A late fix is better than a wrong fix.  Hope to get to it next week!

Paolo

[Qemu-devel] [PATCH 7/6] qemu-iotests: Test change-backing-file command

[Kevin Wolf]

This involves a temporary read-write reopen if the backing file link in
the middle of a backing file chain should be changed and is therefore a
good test for the latest bdrv_reopen() vs. op blockers fixes.

Signed-off-by: Kevin Wolf 
---

I actually managed to find a simple case that reproduces the bug that
is fixed in this series, but outside of my commit job improvements that
originally led me to this work.

 tests/qemu-iotests/195 | 92 ++
 tests/qemu-iotests/195.out | 78 +++
 tests/qemu-iotests/group   |  1 +
 3 files changed, 171 insertions(+)
 create mode 100755 tests/qemu-iotests/195
 create mode 100644 tests/qemu-iotests/195.out

diff --git a/tests/qemu-iotests/195 b/tests/qemu-iotests/195
new file mode 100755
index 00..05a239cbf5
--- /dev/null
+++ b/tests/qemu-iotests/195
@@ -0,0 +1,92 @@
+#!/bin/bash
+#
+# Test change-backing-file command
+#
+# Copyright (C) 2017 Red Hat, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see .
+#
+
+# creator
+owner=kw...@redhat.com
+
+seq=`basename $0`
+echo "QA output created by $seq"
+
+here=`pwd`
+status=1 # failure is the default!
+
+_cleanup()
+{
+_cleanup_test_img
+rm -f "$TEST_IMG.mid"
+}
+trap "_cleanup; exit \$status" 0 1 2 3 15
+
+# get standard environment, filters and checks
+. ./common.rc
+. ./common.filter
+
+_supported_fmt qcow2
+_supported_proto file
+_supported_os Linux
+
+function do_run_qemu()
+{
+echo Testing: "$@" | _filter_imgfmt
+$QEMU -nographic -qmp-pretty stdio -serial none "$@"
+echo
+}
+
+function run_qemu()
+{
+do_run_qemu "$@" 2>&1 | _filter_testdir | _filter_qemu | _filter_qmp \
+  | _filter_qemu_io | _filter_generated_node_ids
+}
+
+size=64M
+TEST_IMG="$TEST_IMG.base" _make_test_img $size
+TEST_IMG="$TEST_IMG.mid" _make_test_img -b "$TEST_IMG.base"
+_make_test_img -b "$TEST_IMG.mid"
+
+echo
+echo "Change backing file of mid (opened read-only)"
+echo
+
+run_qemu -drive if=none,file="$TEST_IMG",backing.node-name=mid <

Re: [Qemu-devel] [PATCH v2 12/16] tcg: Remove tcg_regset_set

[Richard Henderson]

On 09/15/2017 03:21 AM, Alex Bennée wrote:
> 
> Richard Henderson  writes:
> 
>> Signed-off-by: Richard Henderson 
> 
> This breaks the mips cross build:
> 
> In file included from /tmp/qemu-test/src/tcg/tcg.c:254:0:
> /tmp/qemu-test/src/tcg/mips/tcg-target.inc.c: In function 
> 'target_parse_constraint':
> /tmp/qemu-test/src/tcg/mips/tcg-target.inc.c:198:9: error: implicit
> declaration of function 'tcg_regset_set' 
> [-Werror=implicit-function-declaration]
> 
>  tcg_regset_set(ct->u.regs, 0x); 

Yes, I found this myself yesterday.
Fixed in tcg-next.

Thanks,


r~

[Qemu-devel] [Qemu devel v9 PATCH 3/5] msf2: Add Smartfusion2 SPI controller

[Subbaraya Sundeep]

Modelled Microsemi's Smartfusion2 SPI controller.

Signed-off-by: Subbaraya Sundeep 
Reviewed-by: Alistair Francis 
---
 hw/ssi/Makefile.objs |   1 +
 hw/ssi/mss-spi.c | 404 +++
 include/hw/ssi/mss-spi.h |  58 +++
 3 files changed, 463 insertions(+)
 create mode 100644 hw/ssi/mss-spi.c
 create mode 100644 include/hw/ssi/mss-spi.h

diff --git a/hw/ssi/Makefile.objs b/hw/ssi/Makefile.objs
index 487add2..f5bcc65 100644
--- a/hw/ssi/Makefile.objs
+++ b/hw/ssi/Makefile.objs
@@ -4,6 +4,7 @@ common-obj-$(CONFIG_XILINX_SPI) += xilinx_spi.o
 common-obj-$(CONFIG_XILINX_SPIPS) += xilinx_spips.o
 common-obj-$(CONFIG_ASPEED_SOC) += aspeed_smc.o
 common-obj-$(CONFIG_STM32F2XX_SPI) += stm32f2xx_spi.o
+common-obj-$(CONFIG_MSF2) += mss-spi.o
 
 obj-$(CONFIG_OMAP) += omap_spi.o
 obj-$(CONFIG_IMX) += imx_spi.o
diff --git a/hw/ssi/mss-spi.c b/hw/ssi/mss-spi.c
new file mode 100644
index 000..5a8e308
--- /dev/null
+++ b/hw/ssi/mss-spi.c
@@ -0,0 +1,404 @@
+/*
+ * Block model of SPI controller present in
+ * Microsemi's SmartFusion2 and SmartFusion SoCs.
+ *
+ * Copyright (C) 2017 Subbaraya Sundeep 
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include "qemu/osdep.h"
+#include "hw/ssi/mss-spi.h"
+#include "qemu/log.h"
+
+#ifndef MSS_SPI_ERR_DEBUG
+#define MSS_SPI_ERR_DEBUG   0
+#endif
+
+#define DB_PRINT_L(lvl, fmt, args...) do { \
+if (MSS_SPI_ERR_DEBUG >= lvl) { \
+qemu_log("%s: " fmt "\n", __func__, ## args); \
+} \
+} while (0);
+
+#define DB_PRINT(fmt, args...) DB_PRINT_L(1, fmt, ## args)
+
+#define FIFO_CAPACITY 32
+
+#define R_SPI_CONTROL 0
+#define R_SPI_DFSIZE  1
+#define R_SPI_STATUS  2
+#define R_SPI_INTCLR  3
+#define R_SPI_RX  4
+#define R_SPI_TX  5
+#define R_SPI_CLKGEN  6
+#define R_SPI_SS  7
+#define R_SPI_MIS 8
+#define R_SPI_RIS 9
+
+#define S_TXDONE (1 << 0)
+#define S_RXRDY  (1 << 1)
+#define S_RXCHOVRF   (1 << 2)
+#define S_RXFIFOFUL  (1 << 4)
+#define S_RXFIFOFULNXT   (1 << 5)
+#define S_RXFIFOEMP  (1 << 6)
+#define S_RXFIFOEMPNXT   (1 << 7)
+#define S_TXFIFOFUL  (1 << 8)
+#define S_TXFIFOFULNXT   (1 << 9)
+#define S_TXFIFOEMP  (1 << 10)
+#define S_TXFIFOEMPNXT   (1 << 11)
+#define S_FRAMESTART (1 << 12)
+#define S_SSEL   (1 << 13)
+#define S_ACTIVE (1 << 14)
+
+#define C_ENABLE (1 << 0)
+#define C_MODE   (1 << 1)
+#define C_INTRXDATA  (1 << 4)
+#define C_INTTXDATA  (1 << 5)
+#define C_INTRXOVRFLO(1 << 6)
+#define C_SPS(1 << 26)
+#define C_BIGFIFO(1 << 29)
+#define C_RESET  (1 << 31)
+
+#define FRAMESZ_MASK 0x1F
+#define FMCOUNT_MASK 0x0000
+#define FMCOUNT_SHIFT8
+
+static void txfifo_reset(MSSSpiState *s)
+{
+fifo32_reset(&s->tx_fifo);
+
+s->regs[R_SPI_STATUS] &= ~S_TXFIFOFUL;
+s->regs[R_SPI_STATUS] |= S_TXFIFOEMP;
+}
+
+static void rxfifo_reset(MSSSpiState *s)
+{
+fifo32_reset(&s->rx_fifo);
+
+s->regs[R_SPI_STATUS] &= ~S_RXFIFOFUL;
+s->regs[R_SPI_STATUS] |= S_RXFIFOEMP;
+}
+
+static void set_fifodepth(MSSSpiState *s)
+{
+unsigned int size = s->regs[R_SPI_DFSIZE] & FRAMESZ_MASK;
+
+if (size <= 8) {
+s->fifo_depth = 32;
+} else if (size <= 16) {
+s->fifo_depth = 16;
+} else if (size <= 32) {
+s->fifo_depth = 8;
+} else {
+s->fifo_depth = 4;
+}
+}
+
+static void update_mis(MSSSpiState *s)
+{
+uint32_t reg = s->regs[R_SPI_CONTROL];
+uint32_t tmp;
+
+/*
+ * form the Control register interrupt enable bits
+ * same as RIS, MIS and Interrupt clear registers for simplicity
+ */
+tmp = ((reg & C_INTRXOVRFLO) >> 4) | ((reg & C_INTRXDATA) >> 3) |
+   ((reg &

Re: [Qemu-devel] [PATCH 1/2] s390x/ccs: add ccw-tester emulated device

[Cornelia Huck]

On Fri, 15 Sep 2017 09:27:58 +0200
Cornelia Huck  wrote:

> On Thu, 14 Sep 2017 18:50:29 +0200
> Halil Pasic  wrote:
> 
> > On 09/14/2017 04:26 PM, Cornelia Huck wrote:  

> > > There's quite some potential in this. We may want to make this a
> > > permanent addition.
> > > 
> > 
> > I'm happy to contribute! I'm not sure how shall we proceed though.
> > Maybe with making a todo list?  
> 
> I think the first step would be to figure out the ids so we don't step
> on anyone's toes. Then maybe refactor a bit so that other testers can
> be added easily.
> 
> For ideas about things to be tested, maybe put a list into the wiki?

OK, I've created https://wiki.qemu.org/Testing/CCWTestDevice - let me
know if you need an account.

[Qemu-devel] [Qemu devel v9 PATCH 1/5] msf2: Add Smartfusion2 System timer

[Subbaraya Sundeep]

Modelled System Timer in Microsemi's Smartfusion2 Soc.
Timer has two 32bit down counters and two interrupts.

Signed-off-by: Subbaraya Sundeep 
Reviewed-by: Alistair Francis 
---
 hw/timer/Makefile.objs   |   1 +
 hw/timer/mss-timer.c | 289 +++
 include/hw/timer/mss-timer.h |  64 ++
 3 files changed, 354 insertions(+)
 create mode 100644 hw/timer/mss-timer.c
 create mode 100644 include/hw/timer/mss-timer.h

diff --git a/hw/timer/Makefile.objs b/hw/timer/Makefile.objs
index 15cce1c..8c19eac 100644
--- a/hw/timer/Makefile.objs
+++ b/hw/timer/Makefile.objs
@@ -42,3 +42,4 @@ common-obj-$(CONFIG_ASPEED_SOC) += aspeed_timer.o
 
 common-obj-$(CONFIG_SUN4V_RTC) += sun4v-rtc.o
 common-obj-$(CONFIG_CMSDK_APB_TIMER) += cmsdk-apb-timer.o
+common-obj-$(CONFIG_MSF2) += mss-timer.o
diff --git a/hw/timer/mss-timer.c b/hw/timer/mss-timer.c
new file mode 100644
index 000..60f1213
--- /dev/null
+++ b/hw/timer/mss-timer.c
@@ -0,0 +1,289 @@
+/*
+ * Block model of System timer present in
+ * Microsemi's SmartFusion2 and SmartFusion SoCs.
+ *
+ * Copyright (c) 2017 Subbaraya Sundeep .
+ *
+ * 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/main-loop.h"
+#include "qemu/log.h"
+#include "hw/timer/mss-timer.h"
+
+#ifndef MSS_TIMER_ERR_DEBUG
+#define MSS_TIMER_ERR_DEBUG  0
+#endif
+
+#define DB_PRINT_L(lvl, fmt, args...) do { \
+if (MSS_TIMER_ERR_DEBUG >= lvl) { \
+qemu_log("%s: " fmt "\n", __func__, ## args); \
+} \
+} while (0);
+
+#define DB_PRINT(fmt, args...) DB_PRINT_L(1, fmt, ## args)
+
+#define R_TIM_VAL 0
+#define R_TIM_LOADVAL 1
+#define R_TIM_BGLOADVAL   2
+#define R_TIM_CTRL3
+#define R_TIM_RIS 4
+#define R_TIM_MIS 5
+
+#define TIMER_CTRL_ENBL (1 << 0)
+#define TIMER_CTRL_ONESHOT  (1 << 1)
+#define TIMER_CTRL_INTR (1 << 2)
+#define TIMER_RIS_ACK   (1 << 0)
+#define TIMER_RST_CLR   (1 << 6)
+#define TIMER_MODE  (1 << 0)
+
+static void timer_update_irq(struct Msf2Timer *st)
+{
+bool isr, ier;
+
+isr = !!(st->regs[R_TIM_RIS] & TIMER_RIS_ACK);
+ier = !!(st->regs[R_TIM_CTRL] & TIMER_CTRL_INTR);
+qemu_set_irq(st->irq, (ier && isr));
+}
+
+static void timer_update(struct Msf2Timer *st)
+{
+uint64_t count;
+
+if (!(st->regs[R_TIM_CTRL] & TIMER_CTRL_ENBL)) {
+ptimer_stop(st->ptimer);
+return;
+}
+
+count = st->regs[R_TIM_LOADVAL];
+ptimer_set_limit(st->ptimer, count, 1);
+ptimer_run(st->ptimer, 1);
+}
+
+static uint64_t
+timer_read(void *opaque, hwaddr offset, unsigned int size)
+{
+MSSTimerState *t = opaque;
+hwaddr addr;
+struct Msf2Timer *st;
+uint32_t ret = 0;
+int timer = 0;
+int isr;
+int ier;
+
+addr = offset >> 2;
+/*
+ * Two independent timers has same base address.
+ * Based on address passed figure out which timer is being used.
+ */
+if ((addr >= R_TIM1_MAX) && (addr < NUM_TIMERS * R_TIM1_MAX)) {
+timer = 1;
+addr -= R_TIM1_MAX;
+}
+
+st = &t->timers[timer];
+
+switch (addr) {
+case R_TIM_VAL:
+ret = ptimer_get_count(st->ptimer);
+break;
+
+case R_TIM_MIS:
+isr = !!(st->regs[R_TIM_RIS] & TIMER_RIS_ACK);
+ier = !!(st->regs[R_TIM_CTRL] & TIMER_CTRL_INTR);
+ret = ier & isr;
+break;
+
+default:
+if (addr < R_TIM1_MAX) {
+ret = st->regs[addr];
+} else {
+qemu_log_mask(LOG_GUEST_ERROR,
+TYPE_MSS_TIMER": 64-bit mode not supported\n");
+return ret;
+}
+break;
+}
+
+DB_PRINT("timer=%d 0x%" HWADDR_PRIx "=0x%" PRIx32, timer, offset,
+ret);
+return ret;
+}
+
+static void
+timer_write(void *opaque, hwaddr offset,
+uint64_t val64, unsigned int size)
+{
+MSSTimerState *t = opaque;
+hwaddr addr;
+stru

[Qemu-devel] [Qemu devel v9 PATCH 5/5] msf2: Add Emcraft's Smartfusion2 SOM kit

[Subbaraya Sundeep]

Emulated Emcraft's Smartfusion2 System On Module starter
kit.

Signed-off-by: Subbaraya Sundeep 
Reviewed-by: Philippe Mathieu-Daudé 
---
 hw/arm/Makefile.objs |  2 +-
 hw/arm/msf2-som.c| 94 
 2 files changed, 95 insertions(+), 1 deletion(-)
 create mode 100644 hw/arm/msf2-som.c

diff --git a/hw/arm/Makefile.objs b/hw/arm/Makefile.objs
index df36a03..e81a7dc 100644
--- a/hw/arm/Makefile.objs
+++ b/hw/arm/Makefile.objs
@@ -19,4 +19,4 @@ obj-$(CONFIG_FSL_IMX31) += fsl-imx31.o kzm.o
 obj-$(CONFIG_FSL_IMX6) += fsl-imx6.o sabrelite.o
 obj-$(CONFIG_ASPEED_SOC) += aspeed_soc.o aspeed.o
 obj-$(CONFIG_MPS2) += mps2.o
-obj-$(CONFIG_MSF2) += msf2-soc.o
+obj-$(CONFIG_MSF2) += msf2-soc.o msf2-som.o
diff --git a/hw/arm/msf2-som.c b/hw/arm/msf2-som.c
new file mode 100644
index 000..d395696
--- /dev/null
+++ b/hw/arm/msf2-som.c
@@ -0,0 +1,94 @@
+/*
+ * SmartFusion2 SOM starter kit(from Emcraft) emulation.
+ *
+ * Copyright (c) 2017 Subbaraya Sundeep 
+ *
+ * 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 "hw/arm/arm.h"
+#include "exec/address-spaces.h"
+#include "qemu/cutils.h"
+#include "hw/arm/msf2-soc.h"
+
+#define DDR_BASE_ADDRESS  0xA000
+#define DDR_SIZE  (64 * M_BYTE)
+
+#define M2S010_ENVM_SIZE  (256 * K_BYTE)
+#define M2S010_ESRAM_SIZE (64 * K_BYTE)
+
+static void emcraft_sf2_s2s010_init(MachineState *machine)
+{
+DeviceState *dev;
+DeviceState *spi_flash;
+MSF2State *soc;
+DriveInfo *dinfo = drive_get_next(IF_MTD);
+qemu_irq cs_line;
+SSIBus *spi_bus;
+MemoryRegion *sysmem = get_system_memory();
+MemoryRegion *ddr = g_new(MemoryRegion, 1);
+
+memory_region_init_ram(ddr, NULL, "ddr-ram", DDR_SIZE,
+   &error_fatal);
+memory_region_add_subregion(sysmem, DDR_BASE_ADDRESS, ddr);
+
+dev = qdev_create(NULL, TYPE_MSF2_SOC);
+qdev_prop_set_string(dev, "part-name", "M2S010");
+qdev_prop_set_uint64(dev, "eNVM-size", M2S010_ENVM_SIZE);
+qdev_prop_set_uint64(dev, "eSRAM-size", M2S010_ESRAM_SIZE);
+
+/*
+ * CPU clock and peripheral clocks(APB0, APB1)are configurable
+ * in Libero. CPU clock is divided by APB0 and APB1 divisors for
+ * peripherals. Emcraft's SoM kit comes with these settings by default.
+ */
+qdev_prop_set_uint32(dev, "m3clk", 142 * 100);
+qdev_prop_set_uint32(dev, "apb0div", 2);
+qdev_prop_set_uint32(dev, "apb1div", 2);
+
+object_property_set_bool(OBJECT(dev), true, "realized", &error_fatal);
+
+soc = MSF2_SOC(dev);
+
+/* Attach SPI flash to SPI0 controller */
+spi_bus = (SSIBus *)qdev_get_child_bus(dev, "spi0");
+spi_flash = ssi_create_slave_no_init(spi_bus, "s25sl12801");
+qdev_prop_set_uint8(spi_flash, "spansion-cr2nv", 1);
+if (dinfo) {
+qdev_prop_set_drive(spi_flash, "drive", blk_by_legacy_dinfo(dinfo),
+&error_fatal);
+}
+qdev_init_nofail(spi_flash);
+cs_line = qdev_get_gpio_in_named(spi_flash, SSI_GPIO_CS, 0);
+sysbus_connect_irq(SYS_BUS_DEVICE(&soc->spi[0]), 1, cs_line);
+
+armv7m_load_kernel(ARM_CPU(first_cpu), machine->kernel_filename,
+   soc->envm_size);
+}
+
+static void emcraft_sf2_machine_init(MachineClass *mc)
+{
+mc->desc = "SmartFusion2 SOM kit from Emcraft (M2S010)";
+mc->init = emcraft_sf2_s2s010_init;
+}
+
+DEFINE_MACHINE("emcraft-sf2", emcraft_sf2_machine_init)
-- 
2.5.0

[Qemu-devel] [Qemu devel v9 PATCH 0/5] Add support for Smartfusion2 SoC

[Subbaraya Sundeep]

Hi Qemu-devel,

I am trying to add Smartfusion2 SoC.
SoC is from Microsemi and System on Module(SOM)
board is from Emcraft systems. Smartfusion2 has hardened
Microcontroller(Cortex-M3)based Sub System and FPGA fabric.
At the moment only system timer, sysreg and SPI
controller are modelled.

Tested-by: Philippe Mathieu-Daudé 

Testing:
./arm-softmmu/qemu-system-arm -M emcraft-sf2 -serial mon:stdio \
-kernel u-boot.bin -display none -drive file=spi.bin,if=mtd,format=raw

Binaries u-boot.bin and spi.bin are at:
https://github.com/Subbaraya-Sundeep/qemu-test-binaries.git

U-boot is from Emcraft with modified
- SPI driver not to use PDMA.
- ugly hack to pass dtb to kernel in r1.
@
https://github.com/Subbaraya-Sundeep/emcraft-uboot-sf2.git

Linux is 4.5 linux with Smartfusion2 SoC dts and clocksource
driver added by myself @
https://github.com/Subbaraya-Sundeep/linux.git

v9:
used trace instead of DB_PRINT in msf2-sysreg.c
used LOG_UNIMP for non guest errors in msf2-sysreg.c
added unimplemented devices in msf2-soc.c
removed .alias suffix in alias memory region name for eNVM

v8:
memory_region_init_ram to memory_region_init_rom in soc
%s/emcraft_sf2_init/emcraft_sf2_s2s010_init/g in som
Added mc->ignore_memory_transaction_failures = true in som
as per latest commit.
Code simplifications as suggested by Alistair in sysreg and ssi.

v7:
Removed vmstate_register_ram_global as per latest commit
Moved header files to C which are local to C source files
Removed abort() from msf2-sysreg.c
Added VMStateDescription in mss-timer.c

v6:
Moved some defines from header files to source files
Added properties m3clk, apb0div, apb0div1 properties
to soc.
Added properties apb0divisor, apb1divisor to sysreg
Update system_clock_source in msf2-soc.c
Changed machine name smartfusion2-som->emcraft-sf2

v5
As per Philippe comments:
Added abort in Sysreg if guest tries to remap memory
other than default mapping.
Use of CONFIG_MSF2 in Makefile for soc.c
Fixed incorrect logic in timer model.
Renamed msf2-timer.c -> mss-timer.c
msf2-spi.c -> mss-spi.c also type names
Renamed function msf2_init->emcraft_sf2_init in msf2-som.c
Added part-name,eNVM-size,eSRAM-size,pclk0 and pclk1
properties to soc.
Pass soc part-name,memory size and clock rate properties from som.
v4:
Fixed build failure by using PRIx macros.
v3:
Added SoC file and board file as per Alistair comments.
v2:
Added SPI controller so that u-boot loads kernel from spi flash.
v1:
Initial patch set with timer and sysreg

Thanks,
Sundeep


Subbaraya Sundeep (5):
  msf2: Add Smartfusion2 System timer
  msf2: Microsemi Smartfusion2 System Register block
  msf2: Add Smartfusion2 SPI controller
  msf2: Add Smartfusion2 SoC
  msf2: Add Emcraft's Smartfusion2 SOM kit

 default-configs/arm-softmmu.mak |   1 +
 hw/arm/Makefile.objs|   1 +
 hw/arm/msf2-soc.c   | 232 +++
 hw/arm/msf2-som.c   |  94 ++
 hw/misc/Makefile.objs   |   1 +
 hw/misc/msf2-sysreg.c   | 168 +
 hw/misc/trace-events|   5 +
 hw/ssi/Makefile.objs|   1 +
 hw/ssi/mss-spi.c| 404 
 hw/timer/Makefile.objs  |   1 +
 hw/timer/mss-timer.c| 289 
 include/hw/arm/msf2-soc.h   |  66 +++
 include/hw/misc/msf2-sysreg.h   |  77 
 include/hw/ssi/mss-spi.h|  58 ++
 include/hw/timer/mss-timer.h|  64 +++
 15 files changed, 1462 insertions(+)
 create mode 100644 hw/arm/msf2-soc.c
 create mode 100644 hw/arm/msf2-som.c
 create mode 100644 hw/misc/msf2-sysreg.c
 create mode 100644 hw/ssi/mss-spi.c
 create mode 100644 hw/timer/mss-timer.c
 create mode 100644 include/hw/arm/msf2-soc.h
 create mode 100644 include/hw/misc/msf2-sysreg.h
 create mode 100644 include/hw/ssi/mss-spi.h
 create mode 100644 include/hw/timer/mss-timer.h

-- 
2.5.0

[Qemu-devel] [Qemu devel v9 PATCH 4/5] msf2: Add Smartfusion2 SoC

[Subbaraya Sundeep]

Smartfusion2 SoC has hardened Microcontroller subsystem
and flash based FPGA fabric. This patch adds support for
Microcontroller subsystem in the SoC.

Signed-off-by: Subbaraya Sundeep 
Reviewed-by: Alistair Francis 
---
 default-configs/arm-softmmu.mak |   1 +
 hw/arm/Makefile.objs|   1 +
 hw/arm/msf2-soc.c   | 232 
 include/hw/arm/msf2-soc.h   |  66 
 4 files changed, 300 insertions(+)
 create mode 100644 hw/arm/msf2-soc.c
 create mode 100644 include/hw/arm/msf2-soc.h

diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
index bbdd3c1..5059d13 100644
--- a/default-configs/arm-softmmu.mak
+++ b/default-configs/arm-softmmu.mak
@@ -129,3 +129,4 @@ CONFIG_ACPI=y
 CONFIG_SMBIOS=y
 CONFIG_ASPEED_SOC=y
 CONFIG_GPIO_KEY=y
+CONFIG_MSF2=y
diff --git a/hw/arm/Makefile.objs b/hw/arm/Makefile.objs
index a2e56ec..df36a03 100644
--- a/hw/arm/Makefile.objs
+++ b/hw/arm/Makefile.objs
@@ -19,3 +19,4 @@ obj-$(CONFIG_FSL_IMX31) += fsl-imx31.o kzm.o
 obj-$(CONFIG_FSL_IMX6) += fsl-imx6.o sabrelite.o
 obj-$(CONFIG_ASPEED_SOC) += aspeed_soc.o aspeed.o
 obj-$(CONFIG_MPS2) += mps2.o
+obj-$(CONFIG_MSF2) += msf2-soc.o
diff --git a/hw/arm/msf2-soc.c b/hw/arm/msf2-soc.c
new file mode 100644
index 000..5c0a2ea
--- /dev/null
+++ b/hw/arm/msf2-soc.c
@@ -0,0 +1,232 @@
+/*
+ * SmartFusion2 SoC emulation.
+ *
+ * Copyright (c) 2017 Subbaraya Sundeep 
+ *
+ * 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 "hw/arm/arm.h"
+#include "exec/address-spaces.h"
+#include "hw/char/serial.h"
+#include "hw/boards.h"
+#include "sysemu/block-backend.h"
+#include "qemu/cutils.h"
+#include "hw/arm/msf2-soc.h"
+#include "hw/misc/unimp.h"
+
+#define MSF2_TIMER_BASE   0x40004000
+#define MSF2_SYSREG_BASE  0x40038000
+
+#define ENVM_BASE_ADDRESS 0x6000
+
+#define SRAM_BASE_ADDRESS 0x2000
+
+#define MSF2_ENVM_MAX_SIZE(512 * K_BYTE)
+
+/*
+ * eSRAM max size is 80k without SECDED(Single error correction and
+ * dual error detection) feature and 64k with SECDED.
+ * We do not support SECDED now.
+ */
+#define MSF2_ESRAM_MAX_SIZE   (80 * K_BYTE)
+
+static const uint32_t spi_addr[MSF2_NUM_SPIS] = { 0x40001000 , 0x40011000 };
+static const uint32_t uart_addr[MSF2_NUM_UARTS] = { 0x4000 , 0x4001 };
+
+static const int spi_irq[MSF2_NUM_SPIS] = { 2, 3 };
+static const int uart_irq[MSF2_NUM_UARTS] = { 10, 11 };
+static const int timer_irq[MSF2_NUM_TIMERS] = { 14, 15 };
+
+static void m2sxxx_soc_initfn(Object *obj)
+{
+MSF2State *s = MSF2_SOC(obj);
+int i;
+
+object_initialize(&s->armv7m, sizeof(s->armv7m), TYPE_ARMV7M);
+qdev_set_parent_bus(DEVICE(&s->armv7m), sysbus_get_default());
+
+object_initialize(&s->sysreg, sizeof(s->sysreg), TYPE_MSF2_SYSREG);
+qdev_set_parent_bus(DEVICE(&s->sysreg), sysbus_get_default());
+
+object_initialize(&s->timer, sizeof(s->timer), TYPE_MSS_TIMER);
+qdev_set_parent_bus(DEVICE(&s->timer), sysbus_get_default());
+
+for (i = 0; i < MSF2_NUM_SPIS; i++) {
+object_initialize(&s->spi[i], sizeof(s->spi[i]),
+  TYPE_MSS_SPI);
+qdev_set_parent_bus(DEVICE(&s->spi[i]), sysbus_get_default());
+}
+}
+
+static void m2sxxx_soc_realize(DeviceState *dev_soc, Error **errp)
+{
+MSF2State *s = MSF2_SOC(dev_soc);
+DeviceState *dev, *armv7m;
+SysBusDevice *busdev;
+Error *err = NULL;
+int i;
+
+MemoryRegion *system_memory = get_system_memory();
+MemoryRegion *nvm = g_new(MemoryRegion, 1);
+MemoryRegion *nvm_alias = g_new(MemoryRegion, 1);
+MemoryRegion *sram = g_new(MemoryRegion, 1);
+
+memory_region_init_rom(nvm, NULL, "MSF2.eNVM", s->envm_size,
+   &error_fatal);
+/*
+ * On power-on, the eNVM region 0x6000 is automatically
+ * remapped to the C

[Qemu-devel] [Qemu devel v9 PATCH 2/5] msf2: Microsemi Smartfusion2 System Register block

[Subbaraya Sundeep]

Added Sytem register block of Smartfusion2.
This block has PLL registers which are accessed by guest.

Signed-off-by: Subbaraya Sundeep 
Reviewed-by: Alistair Francis 
---
 hw/misc/Makefile.objs |   1 +
 hw/misc/msf2-sysreg.c | 168 ++
 hw/misc/trace-events  |   5 ++
 include/hw/misc/msf2-sysreg.h |  77 +++
 4 files changed, 251 insertions(+)
 create mode 100644 hw/misc/msf2-sysreg.c
 create mode 100644 include/hw/misc/msf2-sysreg.h

diff --git a/hw/misc/Makefile.objs b/hw/misc/Makefile.objs
index 29fb922..e8f0a02 100644
--- a/hw/misc/Makefile.objs
+++ b/hw/misc/Makefile.objs
@@ -59,3 +59,4 @@ obj-$(CONFIG_HYPERV_TESTDEV) += hyperv_testdev.o
 obj-$(CONFIG_AUX) += auxbus.o
 obj-$(CONFIG_ASPEED_SOC) += aspeed_scu.o aspeed_sdmc.o
 obj-y += mmio_interface.o
+obj-$(CONFIG_MSF2) += msf2-sysreg.o
diff --git a/hw/misc/msf2-sysreg.c b/hw/misc/msf2-sysreg.c
new file mode 100644
index 000..dc3597b
--- /dev/null
+++ b/hw/misc/msf2-sysreg.c
@@ -0,0 +1,168 @@
+/*
+ * System Register block model of Microsemi SmartFusion2.
+ *
+ * Copyright (c) 2017 Subbaraya Sundeep 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see .
+ */
+
+#include "qemu/osdep.h"
+#include "qemu/log.h"
+#include "hw/misc/msf2-sysreg.h"
+#include "trace.h"
+
+static inline int msf2_divbits(uint32_t div)
+{
+int ret = 0;
+
+switch (div) {
+case 1:
+ret = 0;
+break;
+case 2:
+ret = 1;
+break;
+case 4:
+ret = 2;
+break;
+case 8:
+ret = 4;
+break;
+case 16:
+ret = 5;
+break;
+case 32:
+ret = 6;
+break;
+default:
+break;
+}
+
+return ret;
+}
+
+static void msf2_sysreg_reset(DeviceState *d)
+{
+MSF2SysregState *s = MSF2_SYSREG(d);
+
+s->regs[MSSDDR_PLL_STATUS_LOW_CR] = 0x021A2358;
+s->regs[MSSDDR_PLL_STATUS] = 0x3;
+s->regs[MSSDDR_FACC1_CR] = msf2_divbits(s->apb0div) << 5 |
+   msf2_divbits(s->apb1div) << 2;
+}
+
+static uint64_t msf2_sysreg_read(void *opaque, hwaddr offset,
+unsigned size)
+{
+MSF2SysregState *s = opaque;
+uint32_t ret = 0;
+
+offset >>= 2;
+if (offset < ARRAY_SIZE(s->regs)) {
+ret = s->regs[offset];
+trace_msf2_sysreg_read(offset << 2, ret);
+} else {
+qemu_log_mask(LOG_GUEST_ERROR,
+"%s: Bad offset 0x%08" HWADDR_PRIx "\n", __func__,
+offset << 2);
+}
+
+return ret;
+}
+
+static void msf2_sysreg_write(void *opaque, hwaddr offset,
+  uint64_t val, unsigned size)
+{
+MSF2SysregState *s = opaque;
+uint32_t newval = val;
+
+offset >>= 2;
+
+switch (offset) {
+case MSSDDR_PLL_STATUS:
+trace_msf2_sysreg_write_pll_status();
+break;
+
+case ESRAM_CR:
+case DDR_CR:
+case ENVM_REMAP_BASE_CR:
+if (newval != s->regs[offset]) {
+qemu_log_mask(LOG_UNIMP,
+   TYPE_MSF2_SYSREG": remapping not supported\n");
+}
+break;
+
+default:
+if (offset < ARRAY_SIZE(s->regs)) {
+trace_msf2_sysreg_write(offset << 2, newval, s->regs[offset]);
+s->regs[offset] = newval;
+} else {
+qemu_log_mask(LOG_GUEST_ERROR,
+"%s: Bad offset 0x%08" HWADDR_PRIx "\n", __func__,
+offset << 2);
+}
+break;
+}
+}
+
+static const MemoryRegionOps sysreg_ops = {
+.read = msf2_sysreg_read,
+.write = msf2_sysreg_write,
+.endianness = DEVICE_NATIVE_ENDIAN,
+};
+
+static void msf2_sysreg_init(Object *obj)
+{
+MSF2SysregState *s = MSF2_SYSREG(obj);
+
+memory_region_init_io(&s->iomem, obj, &sysreg_ops, s, TYPE_MSF2_SYSREG,
+  MSF2_SYSREG_MMIO_SIZE);
+sysbus_init_mmio(SYS_BUS_DEVICE(obj), &s->iomem);
+}
+
+static const VMStateDescription vmstate_msf2_sysreg = {
+.name = TYPE_MSF2_SYSREG,
+.version_id = 1,
+.minimum_version_id = 1,
+.fields = (VMStateField[]) {
+VMSTATE_UINT32_ARRAY(regs, MSF2SysregState, MSF2_SYSREG_MMIO_SIZE / 4),
+VMSTATE_END_OF_LIST()
+}
+};
+
+static Property msf2_sysreg_properties[] = {
+/* default divisors in Libero GUI */
+DEFINE_PROP_UINT32("apb0divisor", MSF2SysregState, apb0div, 2),
+DEFINE_PROP_UINT32("apb1divisor", MSF2SysregState, apb1div, 2),
+DEFINE_PROP_END_OF_LIST(),
+};
+
+static void msf2_sysreg_class_init(ObjectClass *klass, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(klass);
+
+dc->vmsd = &vmst

Re: [Qemu-devel] [PATCH 04/10] disas: Support the Capstone disassembler library

[Richard Henderson]

On 09/14/2017 09:46 PM, Philippe Mathieu-Daudé wrote:
>>   +static bool cap_disas(disassemble_info *info, uint64_t pc, size_t size)
> 
> I'd rather use:
> 
> ..,, target_ulong code, ...
>> +{
> 
> uint64_t pc = (uint64_t)code;

Why?

> 
>> +    bool ret = false;
> 
> Isn't it cleaner to have a stubs/disas_capstone.c?
> 
>> +#ifdef CONFIG_CAPSTONE

If this one function warranted a separate file of its own, maybe, but certainly
not without that.

>> +    cap_mode += (info->endian == BFD_ENDIAN_BIG ? CS_MODE_BIG_ENDIAN
>> + : CS_MODE_LITTLE_ENDIAN);
>> +
> 
>     assert(size); ?

The existing disassembler doesn't have it.  So, no?

>     err = cs_open(info->cap_arch, cap_mode, &handle);
>     if (err != CS_ERR_OK) {
>     (*info->fprintf_func)(info->stream, "Capstone: %s\n",
>   cs_strerror(err));

No.  Or not without extra limits.  We don't want 100k instances of this error
as we dump all of the hunks for "-d in_asm".

We'd be assuming the distro didn't do anything silly wrt compiling with "diet"
mode or with only the host cpu enabled.  I really don't know what to do about
such an eventuality except continue to fall back to the binutils code.

>> +    cbuf = buf = g_malloc(size);
> 
>     if (buf == NULL) {
>     goto err2;
>     }

g_malloc cannot fail.

> 
>     cs_free(insn, 1);
> err2:
> 
>> +    g_free(buf);
>> + err1:

Oops, yes.

>> +
>> +    if (s.info.cap_arch >= 0 && cap_disas(&s.info, (uintptr_t)code, size)) {
> 
> (target_ulong)(uintptr_t)code, ?

Why?  Even if I did change the type of the argument?
The extra cast would be implied by the language.

>>   +    /* ??? Capstone requires that we copy the data into a host-addressable
>> +   buffer first and has no call-back to read more.  Therefore we need
>> +   an estimate of buffer size.  This will work for most RISC, but we'll
>> +   need to figure out something else for variable-length ISAs.  */
>> +    if (s.info.cap_arch >= 0 && cap_disas(&s.info, pc, 4 * nb_insn)) {
> 
> .., MIN(16 * nb_insn, TARGET_PAGE_SIZE))) ?

That's no better than what I have; it simply prints more.  I need a *real*
solution.  It will probably involve not re-using cap_disas but writing code
just for the monitor.


r~

[Qemu-devel] [PATCH RFC v2 0/1] s390x: pci compat handling

[Cornelia Huck]

As David has identified the reason why only 2.7 and older are affected
(thanks!), we can fix migration of these machines by unconditionally
providing the zpci feature bit if cpu models are off.

Still RFC, as I have only sniff-tested it.

We still need to think about what to do with compat machines on pci-less
builds. Probably we should disable compat machines (at least 2.7 and older)
on those builds. Not a pressing issue, as switching off CONFIG_PCI needs
to be done manually.

Changes RFC -> RFC v2:
- switch from machine class property to enabling zpci bit for non-cpu model
  compat machines

Cornelia Huck (1):
  s390x/ccw: create s390 phb for compat reasons as well

 hw/s390x/s390-virtio-ccw.c | 2 ++
 target/s390x/cpu_models.c  | 3 +++
 2 files changed, 5 insertions(+)

-- 
2.13.5

[Qemu-devel] [PATCH RFC v2 1/1] s390x/ccw: create s390 phb for compat reasons as well

[Cornelia Huck]

d32bd032d8 ("s390x/ccw: create s390 phb conditionally") made
registering the s390 pci host bridge conditional on presense
of the zpci facility bit. Sadly, that breaks migration from
machines that did not use the cpu model (2.7 and previous).

Create the s390 phb for pre-cpu model machines as well.

Fixes: d32bd032d8 ("s390x/ccw: create s390 phb conditionally")
Signed-off-by: Cornelia Huck 
---
 hw/s390x/s390-virtio-ccw.c | 2 ++
 target/s390x/cpu_models.c  | 3 +++
 2 files changed, 5 insertions(+)

diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
index 0471407187..907abc7a32 100644
--- a/hw/s390x/s390-virtio-ccw.c
+++ b/hw/s390x/s390-virtio-ccw.c
@@ -269,6 +269,8 @@ static void s390_create_virtio_net(BusState *bus, const 
char *name)
 }
 }
 
+static S390CcwMachineClass *get_machine_class(void);
+
 static void ccw_init(MachineState *machine)
 {
 int ret;
diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c
index c295e641e6..5169379db5 100644
--- a/target/s390x/cpu_models.c
+++ b/target/s390x/cpu_models.c
@@ -196,6 +196,9 @@ bool s390_has_feat(S390Feat feat)
 }
 }
 #endif
+if (feat == S390_FEAT_ZPCI) {
+return true;
+}
 return 0;
 }
 return test_bit(feat, cpu->model->features);
-- 
2.13.5

Re: [Qemu-devel] [RFC 15/15] qmp: let migrate-incoming allow out-of-band

[Dr. David Alan Gilbert]

* Peter Xu (pet...@redhat.com) wrote:
> So it can get rid of being run on main thread.
> 
> Signed-off-by: Peter Xu 
> ---
>  qapi/migration.json | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/qapi/migration.json b/qapi/migration.json
> index ee2b3b8..dedc4f8 100644
> --- a/qapi/migration.json
> +++ b/qapi/migration.json
> @@ -986,7 +986,8 @@
>  # <- { "return": {} }
>  #
>  ##
> -{ 'command': 'migrate-incoming', 'data': {'uri': 'str' } }
> +{ 'command': 'migrate-incoming', 'data': {'uri': 'str' },
> +  'allow-oob': true }

Are you completely convinced migrate-incoming is non-blocking?
What about during the tls handshake if tls is enabled?
(We only set non-blocking on the fd later)

I don't understand in this structure on which thread
process_incoming_migration_co gets run.

Dave

>  ##
>  # @xen-save-devices-state:
> -- 
> 2.7.4
> 
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

Re: [Qemu-devel] [PATCH] target/arm: Remove out of date ARM ARM section references in A64 decoder

[Alex Bennée]

Peter Maydell  writes:

> In the A64 decoder, we have a lot of references to section numbers
> from version A.a of the v8A ARM ARM (DDI0487). This version of the
> document is now long obsolete (we are currently on revision B.a),
> and various intervening versions renumbered all the sections.
>
> The most recent B.a version of the document doesn't assign
> section numbers at all to the individual instruction classes
> in the way that the various A.x versions did. The simplest thing
> to do is just to delete all the out of date C.x.x references.
>
> Signed-off-by: Peter Maydell 
> ---
> Definitely a Friday afternoon kind of a patch...

With a Friday afternoon review ;-)

Reviewed-by: Alex Bennée 

>
>  target/arm/translate-a64.c | 227 
> +++--
>  1 file changed, 114 insertions(+), 113 deletions(-)
>
> diff --git a/target/arm/translate-a64.c b/target/arm/translate-a64.c
> index 9017e30510..e04007376c 100644
> --- a/target/arm/translate-a64.c
> +++ b/target/arm/translate-a64.c
> @@ -1203,12 +1203,14 @@ static inline AArch64DecodeFn *lookup_disas_fn(const 
> AArch64DecodeTable *table,
>  }
>
>  /*
> - * the instruction disassembly implemented here matches
> - * the instruction encoding classifications in chapter 3 (C3)
> - * of the ARM Architecture Reference Manual (DDI0487A_a)
> + * The instruction disassembly implemented here matches
> + * the instruction encoding classifications in chapter C4
> + * of the ARM Architecture Reference Manual (DDI0487B_a);
> + * classification names and decode diagrams here should generally
> + * match up with those in the manual.
>   */
>
> -/* C3.2.7 Unconditional branch (immediate)
> +/* Unconditional branch (immediate)
>   *   31  30   26 25  0
>   * ++---+-+
>   * | op | 0 0 1 0 1 | imm26   |
> @@ -1219,15 +1221,15 @@ static void disas_uncond_b_imm(DisasContext *s, 
> uint32_t insn)
>  uint64_t addr = s->pc + sextract32(insn, 0, 26) * 4 - 4;
>
>  if (insn & (1U << 31)) {
> -/* C5.6.26 BL Branch with link */
> +/* BL Branch with link */
>  tcg_gen_movi_i64(cpu_reg(s, 30), s->pc);
>  }
>
> -/* C5.6.20 B Branch / C5.6.26 BL Branch with link */
> +/* B Branch / BL Branch with link */
>  gen_goto_tb(s, 0, addr);
>  }
>
> -/* C3.2.1 Compare & branch (immediate)
> +/* Compare and branch (immediate)
>   *   31  30 25  24  23  5 4  0
>   * ++-++-++
>   * | sf | 0 1 1 0 1 0 | op | imm19   |   Rt   |
> @@ -1256,7 +1258,7 @@ static void disas_comp_b_imm(DisasContext *s, uint32_t 
> insn)
>  gen_goto_tb(s, 1, addr);
>  }
>
> -/* C3.2.5 Test & branch (immediate)
> +/* Test and branch (immediate)
>   *   31  30 25  24  23   19 18  5 40
>   * ++-++---+-+--+
>   * | b5 | 0 1 1 0 1 1 | op |  b40  |imm14|  Rt  |
> @@ -1285,7 +1287,7 @@ static void disas_test_b_imm(DisasContext *s, uint32_t 
> insn)
>  gen_goto_tb(s, 1, addr);
>  }
>
> -/* C3.2.2 / C5.6.19 Conditional branch (immediate)
> +/* Conditional branch (immediate)
>   *  31   25  24  23  5   4  30
>   * +---++-++--+
>   * | 0 1 0 1 0 1 0 | o1 | imm19   | o0 | cond |
> @@ -1316,7 +1318,7 @@ static void disas_cond_b_imm(DisasContext *s, uint32_t 
> insn)
>  }
>  }
>
> -/* C5.6.68 HINT */
> +/* HINT instruction group, including various allocated HINTs */
>  static void handle_hint(DisasContext *s, uint32_t insn,
>  unsigned int op1, unsigned int op2, unsigned int crm)
>  {
> @@ -1401,7 +1403,7 @@ static void handle_sync(DisasContext *s, uint32_t insn,
>  }
>  }
>
> -/* C5.6.130 MSR (immediate) - move immediate to processor state field */
> +/* MSR (immediate) - move immediate to processor state field */
>  static void handle_msr_i(DisasContext *s, uint32_t insn,
>   unsigned int op1, unsigned int op2, unsigned int 
> crm)
>  {
> @@ -1477,10 +1479,10 @@ static void gen_set_nzcv(TCGv_i64 tcg_rt)
>  tcg_temp_free_i32(nzcv);
>  }
>
> -/* C5.6.129 MRS - move from system register
> - * C5.6.131 MSR (register) - move to system register
> - * C5.6.204 SYS
> - * C5.6.205 SYSL
> +/* MRS - move from system register
> + * MSR (register) - move to system register
> + * SYS
> + * SYSL
>   * These are all essentially the same insn in 'read' and 'write'
>   * versions, with varying op0 fields.
>   */
> @@ -1603,7 +1605,7 @@ static void handle_sys(DisasContext *s, uint32_t insn, 
> bool isread,
>  }
>  }
>
> -/* C3.2.4 System
> +/* System
>   *  31 22 21  20 19 18 16 15   12 118 7   5 40
>   * +-+---+-+-+---+---+-+--+
>   * | 1 1 0 1 0 1 0 1 0 0 | L | op0 | op1 |  CRn  |  CRm  | op2 

Re: [Qemu-devel] [PATCH REPOST v19 1/2] virtio-crypto: Add virtio crypto device specification

[Halil Pasic]

On 09/11/2017 03:12 AM, Longpeng(Mike) wrote:
> From: Gonglei 
> 
> The virtio crypto device is a virtual crypto device (ie. hardware
> crypto accelerator card). Currently, the virtio crypto device provides
> the following crypto services: CIPHER, MAC, HASH, and AEAD.
> 
> In this patch, CIPHER, MAC, HASH, AEAD services are introduced.
> 
> VIRTIO-153
> 
> Signed-off-by: Gonglei 
> Signed-off-by: Longpeng(Mike) 
> ---
[..]


> +\subsubsection{Control Virtqueue}\label{sec:Device Types / Crypto Device / 
> Device Operation / Control Virtqueue}
> +
> +The driver uses the control virtqueue to send control commands to the
> +device, such as session operations (See \ref{sec:Device Types / Crypto 
> Device / Device Operation / Control Virtqueue / Session operation}).
> +
> +The header for controlq is of the following form:
> +\begin{lstlisting}
> +#define VIRTIO_CRYPTO_OPCODE(service, op)   (((service) << 8) | (op))
> +
> +struct virtio_crypto_ctrl_header {
> +#define VIRTIO_CRYPTO_CIPHER_CREATE_SESSION \
> +   VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_CIPHER, 0x02)
> +#define VIRTIO_CRYPTO_CIPHER_DESTROY_SESSION \
> +   VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_CIPHER, 0x03)
> +#define VIRTIO_CRYPTO_HASH_CREATE_SESSION \
> +   VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_HASH, 0x02)
> +#define VIRTIO_CRYPTO_HASH_DESTROY_SESSION \
> +   VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_HASH, 0x03)
> +#define VIRTIO_CRYPTO_MAC_CREATE_SESSION \
> +   VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_MAC, 0x02)
> +#define VIRTIO_CRYPTO_MAC_DESTROY_SESSION \
> +   VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_MAC, 0x03)
> +#define VIRTIO_CRYPTO_AEAD_CREATE_SESSION \
> +   VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AEAD, 0x02)
> +#define VIRTIO_CRYPTO_AEAD_DESTROY_SESSION \
> +   VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AEAD, 0x03)
> +le32 opcode;
> +/* algo should be service-specific algorithms */
> +le32 algo;
> +le32 flag;
> +/* data virtqueue id */
> +le32 queue_id;
> +};
> +\end{lstlisting}
> +
> +The format of the controlq request depends on the VIRTIO_CRYPTO_F_MUX_MODE 
> feature bit:
> +
> +\begin{itemize*}
> +\item If the VIRTIO_CRYPTO_F_MUX_MODE feature bit is NOT negotiated the 
> controlq request is
> +a fixed-size structure of form:
> +\begin{lstlisting}
> +struct virtio_crypto_op_ctrl_req {
> +struct virtio_crypto_ctrl_header header;
> +
> +union {
> +struct virtio_crypto_sym_create_session_req   sym_create_session;
> +struct virtio_crypto_hash_create_session_req  hash_create_session;
> +struct virtio_crypto_mac_create_session_req   mac_create_session;
> +struct virtio_crypto_aead_create_session_req  aead_create_session;
> +struct virtio_crypto_destroy_session_req  destroy_session;
> +} u;
> +};
> +\end{lstlisting}
> +The header is the general header, and the union is of the algorithm-specific 
> type or the
> +virtio_crypto_destroy_session_req structure, which is set by the driver. All 
> the properties
> +in the union are shown as follows.
> +
> +\item If the VIRTIO_CRYPTO_F_MUX_MODE feature bit is negotiated the controlq 
> request is composed
> +of two parts, the additional paramenters are preceded by the general 
> header.
> +
> +\begin{lstlisting}
> +struct virtio_crypto_op_ctrl_req_mux {
> +struct virtio_crypto_ctrl_header header;
> +
> +/* additional paramenter */
> +u8 additional_para[addl_para_len];
> +};
> +\end{lstlisting}
> +
> +The additional paramenters are stored in a virtio_crypto_destroy_session_req 
> structure or
> +in a algorithm-specific structure:
> +\begin{itemize*}
> +\item struct virtio_crypto_sym_create_session_req
> +\item struct virtio_crypto_hash_create_session_req
> +\item struct virtio_crypto_mac_create_session_req
> +\item struct virtio_crypto_aead_create_session_req
> +\end{itemize*}
> +All of the structures above are shown as follows.
> +\end{itemize*}
> +
> +\paragraph{Session operation}\label{sec:Device Types / Crypto Device / 
> Device Operation / Control Virtqueue / Session operation}
> +
> +The session is a
> +handle which describes the cryptographic parameters to be applied to
> +a number of buffers.
> +
> +The following structure stores the result of session creation set by the 
> device:
> +
> +\begin{lstlisting}
> +struct virtio_crypto_session_input {
> +/* Device-writable part */
> +le64 session_id;
> +le32 status;
> +le32 padding;
> +};
> +\end{lstlisting}
> +
> +A request to destroy a session includes the following information:
> +
> +\begin{lstlisting}
> +struct virtio_crypto_destroy_session_req {
> +/* Device-readable part */
> +le64  session_id;
> +/* Device-writable part */
> +le32  status;
> +le32  padding;
> +};
> +\end{lstlisting}
> +
> +\subparagraph{Session operation: HASH session}\label{sec:Device Types / 
> Crypto Device / Device
> +Operation / Control Virtqueue / Session operation / Session ope

Re: [Qemu-devel] [RFC 14/15] qmp: support out-of-band (oob) execution

[Dr. David Alan Gilbert]

* Peter Xu (pet...@redhat.com) wrote:
> Having "allow-oob" to true for a command does not mean that this command
> will always be run in out-of-band mode.  The out-of-band quick path will
> only be executed if we specify the extra "run-oob" flag when sending the
> QMP request:
> 
>   { "execute": "command-that-allows-oob",
> "arguments": { ... },
> "control": { "run-oob": true } }
> 
> The "control" key is introduced to store this extra flag.  "control"
> field is used to store arguments that are shared by all the commands,
> rather than command specific arguments.  Let "run-oob" be the first.
> 
> Signed-off-by: Peter Xu 

I don't understand how this enforces the allowoob, that is it stops
other commands being called with run-oob=true

> ---
>  docs/devel/qapi-code-gen.txt | 10 ++
>  include/qapi/qmp/dispatch.h  |  1 +
>  monitor.c| 11 +++
>  qapi/qmp-dispatch.c  | 34 ++
>  trace-events |  2 ++
>  5 files changed, 58 insertions(+)
> 
> diff --git a/docs/devel/qapi-code-gen.txt b/docs/devel/qapi-code-gen.txt
> index 61fa167..47d16bb 100644
> --- a/docs/devel/qapi-code-gen.txt
> +++ b/docs/devel/qapi-code-gen.txt
> @@ -665,6 +665,16 @@ allowed to run out-of-band can also be introspected using
>  query-qmp-schema command.  Please see the section "Client JSON
>  Protocol introspection" for more information.
>  
> +To execute a command in out-of-band way, we need to specify the
> +"control" field in the request, with "run-oob" set to true. Example:
> +
> + => { "execute": "command-support-oob",
> +  "arguments": { ... },
> +  "control": { "run-oob": true } }
> + <= { "return": { } }
> +
> +Without it, even the commands that supports out-of-band execution will
> +still be run in-band.
>  
>  === Events ===
>  
> diff --git a/include/qapi/qmp/dispatch.h b/include/qapi/qmp/dispatch.h
> index b767988..ee2b8ce 100644
> --- a/include/qapi/qmp/dispatch.h
> +++ b/include/qapi/qmp/dispatch.h
> @@ -49,6 +49,7 @@ bool qmp_command_is_enabled(const QmpCommand *cmd);
>  const char *qmp_command_name(const QmpCommand *cmd);
>  bool qmp_has_success_response(const QmpCommand *cmd);
>  QObject *qmp_build_error_object(Error *err);
> +bool qmp_is_oob(const QObject *request);
>  
>  typedef void (*qmp_cmd_callback_fn)(QmpCommand *cmd, void *opaque);
>  
> diff --git a/monitor.c b/monitor.c
> index 599ea36..cb96204 100644
> --- a/monitor.c
> +++ b/monitor.c
> @@ -3928,6 +3928,7 @@ static void monitor_qmp_bh_dispatcher(void *data)
>  if (!req_obj) {
>  break;
>  }
> +trace_monitor_qmp_cmd_in_band(qobject_get_str(req_obj->id));
>  monitor_qmp_dispatch_one(req_obj);
>  }
>  }
> @@ -3963,6 +3964,16 @@ static void handle_qmp_command(JSONMessageParser 
> *parser, GQueue *tokens,
>  req_obj->id = id;
>  req_obj->req = req;
>  
> +if (qmp_is_oob(req)) {
> +/*
> + * Trigger fast-path to handle the out-of-band request, by
> + * executing the command directly in parser.
> + */
> +trace_monitor_qmp_cmd_out_of_band(qobject_get_str(req_obj->id));
> +monitor_qmp_dispatch_one(req_obj);
> +return;
> +}

I wonder if there is a way to run all allowoob commands in this way;
the only difference being if they're not started with run-oob
you wiat for completion of !oob commands.
That way the allowoob commands are always run from the same
thread/context which feels like it should simplify them.

Dave

>  /*
>   * Put the request to the end of queue so that requests will be
>   * handled in time order.  Ownership for req_obj, req, id,
> diff --git a/qapi/qmp-dispatch.c b/qapi/qmp-dispatch.c
> index b41fa17..9a05dfa 100644
> --- a/qapi/qmp-dispatch.c
> +++ b/qapi/qmp-dispatch.c
> @@ -52,6 +52,12 @@ static QDict *qmp_dispatch_check_obj(const QObject 
> *request, Error **errp)
> "QMP input member 'arguments' must be an object");
>  return NULL;
>  }
> +} else if (!strcmp(arg_name, "control")) {
> +if (qobject_type(arg_obj) != QTYPE_QDICT) {
> +error_setg(errp,
> +   "QMP input member 'control' must be an object");
> +return NULL;
> +}
>  } else {
>  error_setg(errp, "QMP input member '%s' is unexpected",
> arg_name);
> @@ -122,6 +128,34 @@ QObject *qmp_build_error_object(Error *err)
>error_get_pretty(err));
>  }
>  
> +/*
> + * Detect whether a request should be run out-of-band, by quickly
> + * peeking at whether we have: { "control": { "run-oob": True } }. By
> + * default commands are run in-band.
> + */
> +bool qmp_is_oob(const QObject *request)
> +{
> +QDict *dict;
> +QBool *bool_obj;
> +
> +dict = qobject_to_qdict(request);
> +if (!dict) {
> +return false;
> +}
> +
> +dic

Re: [Qemu-devel] [RFC PATCH for-2.11 v3 15/16] travis/osx: build using more Xcode versions

[Alex Bennée]

Philippe Mathieu-Daudé  writes:

> currently default builder is based on Xcode 7.3.1:
> OS X 10.11 (darwin14.5.0)
> Apple LLVM version 7.3.0
>
> add the oldest available Xcode (6.4):
> OS X 10.10 (darwin14.5.0)
> Apple LLVM 6.1.0 (based on LLVM 3.6.0svn)
>
> and the newer available Xcode (8.3.3):
> OS X 10.12 (darwin16.6.0)
> Apple LLVM version 8.1.0

I reckon oldest stable and newest stable is enough for coverage.

>
> see https://docs.travis-ci.com/user/reference/osx/#OS-X-Version
>
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  .travis.yml | 12 
>  1 file changed, 12 insertions(+)
>
> diff --git a/.travis.yml b/.travis.yml
> index 7c93a10c5f..cd59570062 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -117,6 +117,18 @@ matrix:
>compiler: gcc
>  - env: CONFIG=""
>os: osx
> +  # older available: OS X 10.10
> +  osx_image: xcode6.4
> +  compiler: clang
> +- env: CONFIG=""
> +  os: osx
> +  # default: OS X 10.11.6
> +  osx_image: xcode7.3
> +  compiler: clang
> +- env: CONFIG=""
> +  os: osx
> +  # newer stable available, OS X 10.12
> +  osx_image: xcode8.3
>compiler: clang
>  # Plain Trusty System Build
>  - env: CONFIG="--disable-linux-user"


--
Alex Bennée

Re: [Qemu-devel] [RFC PATCH for-2.11 v3 14/16] travis: allow_failures for gprof/gcov

[Alex Bennée]

Philippe Mathieu-Daudé  writes:

> Signed-off-by: Philippe Mathieu-Daudé 

why? We should document the reason in the commit.

> ---
>  .travis.yml | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/.travis.yml b/.travis.yml
> index 1da542f99f..7c93a10c5f 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -87,6 +87,7 @@ before_script:
>  script:
>- make ${MAKEFLAGS} && ${TEST_CMD}
>  matrix:
> +  fast_finish: true
>include:
>  # We manually include builds which we disable "make check" for, they also
>  # are the faster jobs (no testing).
> @@ -233,3 +234,8 @@ matrix:
>  - TEST_CMD=""
>before_script:
>  - ./configure ${CONFIG} --extra-cflags="-g3 -O0 -fsanitize=thread 
> -fuse-ld=gold" || (cat config.log; exit 1)
> +  allow_failures:
> +- env: CONFIG="--enable-gprof --disable-pie"
> +  compiler: gcc
> +- env: CONFIG="--enable-gcov --disable-pie"
> +  compiler: gcc


--
Alex Bennée

Re: [Qemu-devel] [PATCH] linux-user/syscall.c: Handle SH4's exceptional alignment for p{read, write}64

[John Paul Adrian Glaubitz]

On 09/15/2017 05:41 PM, Philippe Mathieu-Daudé wrote:

I'd rather use arch_type from "sysemu/arch_init.h":

   case TARGET_NR_pwrite64:
   /* SH4 doesn't align register pairs, except for p{read,write}64 */
   if (arch_type == QEMU_ARCH_SH4 || regpairs_aligned(cpu_env)) {
   arg4 = arg5;
   arg5 = arg6;
   }

What do you think?


I agree. That looks a bit cleaner. Was actually thinking about something like 
that.


  if (!(p = lock_user(VERIFY_WRITE, arg2, arg3, 0)))
  goto efault;
  ret = get_errno(pread64(arg1, p, arg3, target_offset64(arg4, arg5)));
  unlock_user(p, arg2, ret);
  break;
  case TARGET_NR_pwrite64:
+#if defined(TARGET_SH4)
+    /* SH4 doesn't align register pairs, except for p{read,write}64 */
+    arg4 = arg5;
+    arg5 = arg6;
+#else
  if (regpairs_aligned(cpu_env)) {
  arg4 = arg5;
  arg5 = arg6;
  }
+#endif


same here.


Dito.

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [Qemu-devel] [PATCH] linux-user/syscall.c: Handle SH4's exceptional alignment for p{read, write}64

[Philippe Mathieu-Daudé]

On 09/15/2017 03:58 AM, James Clarke wrote:

Fixes: https://bugs.launchpad.net/qemu/+bug/1716767
Signed-off-by: James Clarke 


Congratulations! You have won yourself a R: entry (Designated reviewer) 
in the "Linux user" and "SH4" sections of MAINTAINERS!



---
  linux-user/syscall.c | 12 
  1 file changed, 12 insertions(+)

diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 9b6364a266..24d6a81c21 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -10495,20 +10495,32 @@ abi_long do_syscall(void *cpu_env, int num, abi_long 
arg1,
  #endif
  #ifdef TARGET_NR_pread64
  case TARGET_NR_pread64:
+#if defined(TARGET_SH4)
+/* SH4 doesn't align register pairs, except for p{read,write}64 */
+arg4 = arg5;
+arg5 = arg6;
+#else
  if (regpairs_aligned(cpu_env)) {
  arg4 = arg5;
  arg5 = arg6;
  }
+#endif


I'd rather use arch_type from "sysemu/arch_init.h":

  case TARGET_NR_pwrite64:
  /* SH4 doesn't align register pairs, except for p{read,write}64 */
  if (arch_type == QEMU_ARCH_SH4 || regpairs_aligned(cpu_env)) {
  arg4 = arg5;
  arg5 = arg6;
  }

What do you think?


  if (!(p = lock_user(VERIFY_WRITE, arg2, arg3, 0)))
  goto efault;
  ret = get_errno(pread64(arg1, p, arg3, target_offset64(arg4, arg5)));
  unlock_user(p, arg2, ret);
  break;
  case TARGET_NR_pwrite64:
+#if defined(TARGET_SH4)
+/* SH4 doesn't align register pairs, except for p{read,write}64 */
+arg4 = arg5;
+arg5 = arg6;
+#else
  if (regpairs_aligned(cpu_env)) {
  arg4 = arg5;
  arg5 = arg6;
  }
+#endif


same here.


  if (!(p = lock_user(VERIFY_READ, arg2, arg3, 1)))
  goto efault;
  ret = get_errno(pwrite64(arg1, p, arg3, target_offset64(arg4, arg5)));
--
2.13.2




Regards,

Phil.

Re: [Qemu-devel] [RFC v2 16/32] vhost+postcopy: Send address back to qemu

[Dr. David Alan Gilbert]

* Peter Xu (pet...@redhat.com) wrote:
> On Wed, Sep 13, 2017 at 01:15:32PM +0100, Dr. David Alan Gilbert wrote:
> > * Peter Xu (pet...@redhat.com) wrote:
> > > On Tue, Sep 12, 2017 at 06:15:13PM +0100, Dr. David Alan Gilbert wrote:
> > > > * Peter Xu (pet...@redhat.com) wrote:
> > > > > On Thu, Aug 24, 2017 at 08:27:14PM +0100, Dr. David Alan Gilbert 
> > > > > (git) wrote:
> > > > > > From: "Dr. David Alan Gilbert" 
> > > > > > 
> > > > > > We need a better way, but at the moment we need the address of the
> > > > > > mappings sent back to qemu so it can interpret the messages on the
> > > > > > userfaultfd it reads.
> > > > > > 
> > > > > > Note: We don't ask for the default 'ack' reply since we've got our 
> > > > > > own.
> > > > > > 
> > > > > > Signed-off-by: Dr. David Alan Gilbert 
> > > > > > ---
> > > > > >  contrib/libvhost-user/libvhost-user.c | 15 -
> > > > > >  docs/interop/vhost-user.txt   |  6 
> > > > > >  hw/virtio/trace-events|  1 +
> > > > > >  hw/virtio/vhost-user.c| 57 
> > > > > > ++-
> > > > > >  4 files changed, 77 insertions(+), 2 deletions(-)
> > > > > > 
> > > > > > diff --git a/contrib/libvhost-user/libvhost-user.c 
> > > > > > b/contrib/libvhost-user/libvhost-user.c
> > > > > > index e6ab059a03..5ec54f7d60 100644
> > > > > > --- a/contrib/libvhost-user/libvhost-user.c
> > > > > > +++ b/contrib/libvhost-user/libvhost-user.c
> > > > > > @@ -477,13 +477,26 @@ vu_set_mem_table_exec(VuDev *dev, 
> > > > > > VhostUserMsg *vmsg)
> > > > > >  DPRINT("%s: region %d: Registered userfault for %llx + 
> > > > > > %llx\n",
> > > > > >  __func__, i, reg_struct.range.start, 
> > > > > > reg_struct.range.len);
> > > > > >  /* TODO: Stash 'zero' support flags somewhere */
> > > > > > -/* TODO: Get address back to QEMU */
> > > > > >  
> > > > > > +/* TODO: We need to find a way for the qemu not to see 
> > > > > > the virtual
> > > > > > + * addresses of the clients, so as to keep better 
> > > > > > separation.
> > > > > > + */
> > > > > > +/* Return the address to QEMU so that it can translate 
> > > > > > the ufd
> > > > > > + * fault addresses back.
> > > > > > + */
> > > > > > +msg_region->userspace_addr = (uintptr_t)(mmap_addr +
> > > > > > + 
> > > > > > dev_region->mmap_offset);
> > > > > >  }
> > > > > >  
> > > > > >  close(vmsg->fds[i]);
> > > > > >  }
> > > > > >  
> > > > > > +if (dev->postcopy_listening) {
> > > > > > +/* Need to return the addresses - send the updated message 
> > > > > > back */
> > > > > > +vmsg->fd_num = 0;
> > > > > > +return true;
> > > > > > +}
> > > > > > +
> > > > > >  return false;
> > > > > >  }
> > > > > >  
> > > > > > diff --git a/docs/interop/vhost-user.txt 
> > > > > > b/docs/interop/vhost-user.txt
> > > > > > index 73c3dd74db..b2a548c94d 100644
> > > > > > --- a/docs/interop/vhost-user.txt
> > > > > > +++ b/docs/interop/vhost-user.txt
> > > > > > @@ -413,12 +413,18 @@ Master message types
> > > > > >Id: 5
> > > > > >Equivalent ioctl: VHOST_SET_MEM_TABLE
> > > > > >Master payload: memory regions description
> > > > > > +  Slave payload: (postcopy only) memory regions description
> > > > > >  
> > > > > >Sets the memory map regions on the slave so it can translate 
> > > > > > the vring
> > > > > >addresses. In the ancillary data there is an array of file 
> > > > > > descriptors
> > > > > >for each memory mapped region. The size and ordering of the 
> > > > > > fds matches
> > > > > >the number and ordering of memory regions.
> > > > > >  
> > > > > > +  When postcopy-listening has been received, SET_MEM_TABLE 
> > > > > > replies with
> > > > > > +  the bases of the memory mapped regions to the master.  It 
> > > > > > must have mmap'd
> > > > > > +  the regions and enabled userfaultfd on them.  Note 
> > > > > > NEED_REPLY_MASK
> > > > > > +  is not set in this case.
> > > > > > +
> > > > > >   * VHOST_USER_SET_LOG_BASE
> > > > > >  
> > > > > >Id: 6
> > > > > > diff --git a/hw/virtio/trace-events b/hw/virtio/trace-events
> > > > > > index f736c7c84f..63fd4a79cf 100644
> > > > > > --- a/hw/virtio/trace-events
> > > > > > +++ b/hw/virtio/trace-events
> > > > > > @@ -2,6 +2,7 @@
> > > > > >  
> > > > > >  # hw/virtio/vhost-user.c
> > > > > >  vhost_user_postcopy_listen(void) ""
> > > > > > +vhost_user_set_mem_table_postcopy(uint64_t client_addr, uint64_t 
> > > > > > qhva, int reply_i, int region_i) "client:0x%"PRIx64" for hva: 
> > > > > > 0x%"PRIx64" reply %d region %d"
> > > > > >  
> > > > > >  # hw/virtio/virtio.c
> > > > > >  virtqueue_alloc_element(void *elem, size_t sz, unsigned in_num, 
> > > > > > unsigned out_num) "elem %p size %

Re: [Qemu-devel] [PATCH for-2.11 v3 10/16] travis: check ./configure outcome, dump config.log on failure

[Alex Bennée]

Philippe Mathieu-Daudé  writes:

> also de-duplicate 'before_script'
>
> Signed-off-by: Philippe Mathieu-Daudé 

Reviewed-by: Alex Bennée 

> ---
>  .travis.yml | 8 ++--
>  1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/.travis.yml b/.travis.yml
> index 72aad5ca35..88ca78c775 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -79,7 +79,7 @@ before_install:
>- wget -O - 
> http://people.linaro.org/~alex.bennee/qemu-submodule-git-seed.tar.xz | tar 
> -xvJ
>- travis_retry git submodule update --init --recursive
>  before_script:
> -  - ./configure ${CONFIG}
> +  - ./configure ${CONFIG} || (cat config.log; exit 1)
>  script:
>- make ${MAKEFLAGS} && ${TEST_CMD}
>  matrix:
> @@ -155,8 +155,6 @@ matrix:
>  - sudo apt-get build-dep -qq qemu
>  - wget -O - 
> http://people.linaro.org/~alex.bennee/qemu-submodule-git-seed.tar.xz | tar 
> -xvJ
>  - travis_retry git submodule update --init --recursive
> -  before_script:
> -- ./configure ${CONFIG} || cat config.log
>  # Trusty Linux User build with latest stable clang
>  - sudo: required
>addons:
> @@ -175,8 +173,6 @@ matrix:
>  - sudo apt-get build-dep -qq qemu
>  - wget -O - 
> http://people.linaro.org/~alex.bennee/qemu-submodule-git-seed.tar.xz | tar 
> -xvJ
>  - travis_retry git submodule update --init --recursive
> -  before_script:
> -- ./configure ${CONFIG} || cat config.log
>  # Using newer GCC with sanitizers
>  - addons:
>  apt:
> @@ -232,4 +228,4 @@ matrix:
>  - CONFIG="--cc=gcc-5 --cxx=g++-5 --disable-pie --disable-linux-user"
>  - TEST_CMD=""
>before_script:
> -- ./configure ${CONFIG} --extra-cflags="-g3 -O0 -fsanitize=thread 
> -fuse-ld=gold" || cat config.log
> +- ./configure ${CONFIG} --extra-cflags="-g3 -O0 -fsanitize=thread 
> -fuse-ld=gold" || (cat config.log; exit 1)


--
Alex Bennée

Re: [Qemu-devel] [PATCH for-2.11 v3 08/16] travis: reorder matrix to speedup failure

[Alex Bennée]

Philippe Mathieu-Daudé  writes:

> Signed-off-by: Philippe Mathieu-Daudé 

Reviewed-by: Alex Bennée 

> ---
>  .travis.yml | 36 +++-
>  1 file changed, 19 insertions(+), 17 deletions(-)
>
> diff --git a/.travis.yml b/.travis.yml
> index e56c928bef..57462b0471 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -64,11 +64,11 @@ env:
>  - MAKEFLAGS="-j3"
>matrix:
>  - CONFIG=""
> -- CONFIG="--enable-debug --enable-debug-tcg --enable-trace-backends=log"
>  - CONFIG="--disable-linux-aio --disable-cap-ng --disable-attr 
> --disable-brlapi --disable-uuid --disable-libusb"
>  - CONFIG="--enable-modules"
>  - CONFIG="--with-coroutine=ucontext"
>  - CONFIG="--with-coroutine=sigaltstack"
> +- CONFIG="--enable-debug --enable-debug-tcg --enable-trace-backends=log"
>  git:
># we want to do this ourselves
>submodules: false
> @@ -83,30 +83,32 @@ script:
>- make ${MAKEFLAGS} && ${TEST_CMD}
>  matrix:
>include:
> +# We manually include builds which we disable "make check" for, they also
> +# are the faster jobs (no testing).
> +- env: CONFIG="--disable-tcg"
> +   TEST_CMD=""
> +  compiler: gcc
> +- env: CONFIG="--enable-trace-backends=ust"
> +   TEST_CMD=""
> +  compiler: gcc
> +- env: CONFIG="--enable-debug --enable-tcg-interpreter"
> +   TEST_CMD=""
> +  compiler: gcc
> +- env: CONFIG="--enable-trace-backends=simple"
> +   TEST_CMD=""
> +  compiler: gcc
> +- env: CONFIG="--enable-trace-backends=ftrace"
> +   TEST_CMD=""
> +  compiler: gcc
>  # Test with CLang for compile portability
>  - env: CONFIG=""
>compiler: clang
> +
>  # gprof/gcov are GCC features
>  - env: CONFIG="--enable-gprof --disable-pie"
>compiler: gcc
>  - env: CONFIG="--enable-gcov --disable-pie"
>compiler: gcc
> -# We manually include builds which we disable "make check" for
> -- env: CONFIG="--enable-debug --enable-tcg-interpreter"
> -   TEST_CMD=""
> -  compiler: gcc
> -- env: CONFIG="--enable-trace-backends=simple"
> -   TEST_CMD=""
> -  compiler: gcc
> -- env: CONFIG="--enable-trace-backends=ftrace"
> -   TEST_CMD=""
> -  compiler: gcc
> -- env: CONFIG="--enable-trace-backends=ust"
> -   TEST_CMD=""
> -  compiler: gcc
> -- env: CONFIG="--disable-tcg"
> -   TEST_CMD=""
> -  compiler: gcc
>  - env: CONFIG=""
>os: osx
>compiler: clang


--
Alex Bennée

Re: [Qemu-devel] [PATCH for-2.11 v3 01/16] travis: update sudo-enabled Trusty images

[Alex Bennée]

Philippe Mathieu-Daudé  writes:

> see https://blog.travis-ci.com/2017-06-19-trusty-updates-2017-Q2
> and
> https://blog.travis-ci.com/2017-06-21-trusty-updates-2017-Q2-launch

I guess we drop this now? Either we are working or we are not :-/

>
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  .travis.yml | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/.travis.yml b/.travis.yml
> index f583839755..b9cafe3d40 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -98,6 +98,7 @@ matrix:
>sudo: required
>addons:
>dist: trusty
> +  group: deprecated-2017Q2
>compiler: gcc
>before_install:
>  - sudo apt-get update -qq
> @@ -109,6 +110,7 @@ matrix:
>sudo: required
>addons:
>dist: trusty
> +  group: deprecated-2017Q2
>compiler: gcc
>before_install:
>  - sudo apt-get update -qq
> @@ -119,6 +121,7 @@ matrix:
>  - sudo: required
>addons:
>dist: trusty
> +  group: deprecated-2017Q2
>language: generic
>compiler: none
>env:
> @@ -138,6 +141,7 @@ matrix:
>  - sudo: required
>addons:
>dist: trusty
> +  group: deprecated-2017Q2
>language: generic
>compiler: none
>env:


--
Alex Bennée

Re: [Qemu-devel] [RFC 00/15] QMP: out-of-band (OOB) execution support

[Dr. David Alan Gilbert]

* Stefan Hajnoczi (stefa...@redhat.com) wrote:
> On Fri, Sep 15, 2017 at 01:29:13PM +0100, Daniel P. Berrange wrote:
> > On Fri, Sep 15, 2017 at 01:19:56PM +0100, Dr. David Alan Gilbert wrote:
> > > * Daniel P. Berrange (berra...@redhat.com) wrote:
> > > > On Fri, Sep 15, 2017 at 01:06:44PM +0100, Dr. David Alan Gilbert wrote:
> > > > > * Daniel P. Berrange (berra...@redhat.com) wrote:
> > > > > > On Fri, Sep 15, 2017 at 11:49:26AM +0100, Stefan Hajnoczi wrote:
> > > > > > > On Fri, Sep 15, 2017 at 11:50:57AM +0800, Peter Xu wrote:
> > > > > > > > On Thu, Sep 14, 2017 at 04:19:11PM +0100, Stefan Hajnoczi wrote:
> > > > > > > > > On Thu, Sep 14, 2017 at 01:15:09PM +0200, Marc-André Lureau 
> > > > > > > > > wrote:
> > > > > > > > > > There should be a limit in the number of requests the 
> > > > > > > > > > thread can
> > > > > > > > > > queue. Before the patch, the limit was enforced by system 
> > > > > > > > > > socket
> > > > > > > > > > buffering I think. Now, should oob commands still be 
> > > > > > > > > > processed even if
> > > > > > > > > > the queue is full? If so, the thread can't be suspended.
> > > > > > > > > 
> > > > > > > > > I agree.
> > > > > > > > > 
> > > > > > > > > Memory usage must be bounded.  The number of requests is less 
> > > > > > > > > important
> > > > > > > > > than the amount of memory consumed by them.
> > > > > > > > > 
> > > > > > > > > Existing QMP clients that send multiple QMP commands without 
> > > > > > > > > waiting for
> > > > > > > > > replies need to rethink their strategy because OOB commands 
> > > > > > > > > cannot be
> > > > > > > > > processed if queued non-OOB commands consume too much memory.
> > > > > > > > 
> > > > > > > > Thanks for pointing out this.  Yes the memory usage problem is 
> > > > > > > > valid,
> > > > > > > > as Markus pointed out as well in previous discussions (in "Flow
> > > > > > > > Control" section of that long reply).  Hopefully this series 
> > > > > > > > basically
> > > > > > > > can work from design prospective, then I'll add this flow 
> > > > > > > > control in
> > > > > > > > next version.
> > > > > > > > 
> > > > > > > > Regarding to what we should do if the limit is reached: Markus
> > > > > > > > provided a few options, but the one I prefer most is that we 
> > > > > > > > don't
> > > > > > > > respond, but send an event showing that a command is dropped.
> > > > > > > > However, I would like it not queued, but a direct reply (after 
> > > > > > > > all,
> > > > > > > > it's an event, and we should not need to care much on ordering 
> > > > > > > > of it).
> > > > > > > > Then we can get rid of the babysitting of those "to be failed"
> > > > > > > > requests asap, meanwhile we don't lose anything IMHO.
> > > > > > > > 
> > > > > > > > I think I also missed at least a unit test for this new 
> > > > > > > > interface.
> > > > > > > > Again, I'll add it after the whole idea is proved solid.  
> > > > > > > > Thanks,
> > > > > > > 
> > > > > > > Another solution: the server reports available receive buffer 
> > > > > > > space to
> > > > > > > the client.  The server only guarantees immediate OOB processing 
> > > > > > > when
> > > > > > > the client stays within the receive buffer size.
> > > > > > > 
> > > > > > > Clients wishing to take advantage of OOB must query the receive 
> > > > > > > buffer
> > > > > > > size and make sure to leave enough room.
> > > > > > 
> > > > > > I don't think having to query it ahead of time is particularly nice,
> > > > > > and of course it is inherantly racy.
> > > > > > 
> > > > > > I would just have QEMU emit an event when it pausing processing of 
> > > > > > the
> > > > > > incoming commands due to a full queue.  If the event includes the ID
> > > > > > of the last queued command, the client will know which (if any) of
> > > > > > its outstanding commands are delayed. Another even can be sent when
> > > > > > it restarts reading.
> > > > > 
> > > > > Hmm and now we're implementing flow control!
> > > > > 
> > > > > a) What exactly is the current semantics/buffer sizes?
> > > > > b) When do clients send multiple QMP commands on one channel without
> > > > > waiting for the response to the previous command?
> > > > > c) Would one queue entry for each class of commands/channel work
> > > > >   (Where a class of commands is currently 'normal' and 'oob')
> > > > 
> > > > I do wonder if we need to worry about request limiting at all from the
> > > > client side.  For non-OOB commands clients will wait for a reply before
> > > > sending a 2nd non-OOB command, so you'll never get a deep queue for.
> > > > 
> > > > OOB commands are supposed to be things which can be handled quickly
> > > > without blocking, so even if a client sent several commands at once
> > > > without waiting for replies, they're going to be processed quickly,
> > > > so whether we temporarily block reading off the wire is a minor
> > > > detail.
> > > 
> > > Lets just define it so that it can't - you send an OOB comma

Re: [Qemu-devel] [PATCH 1/3] kvm: check KVM_CAP_SYNC_MMU with kvm_vm_check_extension()

[Greg Kurz]

On Fri, 15 Sep 2017 07:32:10 +0200
Thomas Huth  wrote:

> On 14.09.2017 21:25, Greg Kurz wrote:
> > On a server-class ppc host, this capability depends on the KVM type,
> > ie, HV or PR. If both KVM are present in the kernel, we will always
> > get the HV specific value, even if we explicitely requested PR on
> > the command line.
> > 
> > This can have an impact if we're using hugepages or a balloon device.
> > 
> > Since we've already created the VM at the time any user calls
> > kvm_has_sync_mmu(), switching to kvm_vm_check_extension() is
> > enough to fix any potential issue.
> > 
> > It is okay for the other archs that also implement KVM_CAP_SYNC_MMU,
> > ie, mips, s390, x86 and arm, because they don't depend on the VM being
> > created or not.
> > 
> > Signed-off-by: Greg Kurz 
> > ---
> >  accel/kvm/kvm-all.c |2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
> > index f85553a85194..323c567cfb68 100644
> > --- a/accel/kvm/kvm-all.c
> > +++ b/accel/kvm/kvm-all.c
> > @@ -2234,7 +2234,7 @@ int kvm_device_access(int fd, int group, uint64_t 
> > attr,
> >  /* Return 1 on success, 0 on failure */
> >  int kvm_has_sync_mmu(void)
> >  {
> > -return kvm_check_extension(kvm_state, KVM_CAP_SYNC_MMU);
> > +return kvm_vm_check_extension(kvm_state, KVM_CAP_SYNC_MMU);
> >  }  
> 
> Reviewed-by: Thomas Huth 
> 
> ... but while you're at it, maybe it would be better to use a bool
> variable for the state of this extension, too, and only check for the
> extension one time at the end of kvm_init() ? kvm_has_sync_mmu() is
> apparently used multiple times in other source files, so we might be
> able to save some cycles by doing the syscall only once?
> 
>  Thomas
> 
> 

Oops, I had overlooked your answer... yes it makes sense indeed.

I'll post a v2 of this patch (not resending the whole series).

Cheers,

--
Greg


pgpjVgbJLIJKL.pgp
Description: OpenPGP digital signature

[Qemu-devel] [PATCH] target/arm: Remove out of date ARM ARM section references in A64 decoder

[Peter Maydell]

In the A64 decoder, we have a lot of references to section numbers
from version A.a of the v8A ARM ARM (DDI0487). This version of the
document is now long obsolete (we are currently on revision B.a),
and various intervening versions renumbered all the sections.

The most recent B.a version of the document doesn't assign
section numbers at all to the individual instruction classes
in the way that the various A.x versions did. The simplest thing
to do is just to delete all the out of date C.x.x references.

Signed-off-by: Peter Maydell 
---
Definitely a Friday afternoon kind of a patch...

 target/arm/translate-a64.c | 227 +++--
 1 file changed, 114 insertions(+), 113 deletions(-)

diff --git a/target/arm/translate-a64.c b/target/arm/translate-a64.c
index 9017e30510..e04007376c 100644
--- a/target/arm/translate-a64.c
+++ b/target/arm/translate-a64.c
@@ -1203,12 +1203,14 @@ static inline AArch64DecodeFn *lookup_disas_fn(const 
AArch64DecodeTable *table,
 }
 
 /*
- * the instruction disassembly implemented here matches
- * the instruction encoding classifications in chapter 3 (C3)
- * of the ARM Architecture Reference Manual (DDI0487A_a)
+ * The instruction disassembly implemented here matches
+ * the instruction encoding classifications in chapter C4
+ * of the ARM Architecture Reference Manual (DDI0487B_a);
+ * classification names and decode diagrams here should generally
+ * match up with those in the manual.
  */
 
-/* C3.2.7 Unconditional branch (immediate)
+/* Unconditional branch (immediate)
  *   31  30   26 25  0
  * ++---+-+
  * | op | 0 0 1 0 1 | imm26   |
@@ -1219,15 +1221,15 @@ static void disas_uncond_b_imm(DisasContext *s, 
uint32_t insn)
 uint64_t addr = s->pc + sextract32(insn, 0, 26) * 4 - 4;
 
 if (insn & (1U << 31)) {
-/* C5.6.26 BL Branch with link */
+/* BL Branch with link */
 tcg_gen_movi_i64(cpu_reg(s, 30), s->pc);
 }
 
-/* C5.6.20 B Branch / C5.6.26 BL Branch with link */
+/* B Branch / BL Branch with link */
 gen_goto_tb(s, 0, addr);
 }
 
-/* C3.2.1 Compare & branch (immediate)
+/* Compare and branch (immediate)
  *   31  30 25  24  23  5 4  0
  * ++-++-++
  * | sf | 0 1 1 0 1 0 | op | imm19   |   Rt   |
@@ -1256,7 +1258,7 @@ static void disas_comp_b_imm(DisasContext *s, uint32_t 
insn)
 gen_goto_tb(s, 1, addr);
 }
 
-/* C3.2.5 Test & branch (immediate)
+/* Test and branch (immediate)
  *   31  30 25  24  23   19 18  5 40
  * ++-++---+-+--+
  * | b5 | 0 1 1 0 1 1 | op |  b40  |imm14|  Rt  |
@@ -1285,7 +1287,7 @@ static void disas_test_b_imm(DisasContext *s, uint32_t 
insn)
 gen_goto_tb(s, 1, addr);
 }
 
-/* C3.2.2 / C5.6.19 Conditional branch (immediate)
+/* Conditional branch (immediate)
  *  31   25  24  23  5   4  30
  * +---++-++--+
  * | 0 1 0 1 0 1 0 | o1 | imm19   | o0 | cond |
@@ -1316,7 +1318,7 @@ static void disas_cond_b_imm(DisasContext *s, uint32_t 
insn)
 }
 }
 
-/* C5.6.68 HINT */
+/* HINT instruction group, including various allocated HINTs */
 static void handle_hint(DisasContext *s, uint32_t insn,
 unsigned int op1, unsigned int op2, unsigned int crm)
 {
@@ -1401,7 +1403,7 @@ static void handle_sync(DisasContext *s, uint32_t insn,
 }
 }
 
-/* C5.6.130 MSR (immediate) - move immediate to processor state field */
+/* MSR (immediate) - move immediate to processor state field */
 static void handle_msr_i(DisasContext *s, uint32_t insn,
  unsigned int op1, unsigned int op2, unsigned int crm)
 {
@@ -1477,10 +1479,10 @@ static void gen_set_nzcv(TCGv_i64 tcg_rt)
 tcg_temp_free_i32(nzcv);
 }
 
-/* C5.6.129 MRS - move from system register
- * C5.6.131 MSR (register) - move to system register
- * C5.6.204 SYS
- * C5.6.205 SYSL
+/* MRS - move from system register
+ * MSR (register) - move to system register
+ * SYS
+ * SYSL
  * These are all essentially the same insn in 'read' and 'write'
  * versions, with varying op0 fields.
  */
@@ -1603,7 +1605,7 @@ static void handle_sys(DisasContext *s, uint32_t insn, 
bool isread,
 }
 }
 
-/* C3.2.4 System
+/* System
  *  31 22 21  20 19 18 16 15   12 118 7   5 40
  * +-+---+-+-+---+---+-+--+
  * | 1 1 0 1 0 1 0 1 0 0 | L | op0 | op1 |  CRn  |  CRm  | op2 |  Rt  |
@@ -1626,13 +1628,13 @@ static void disas_system(DisasContext *s, uint32_t insn)
 return;
 }
 switch (crn) {
-case 2: /* C5.6.68 HINT */
+case 2: /* HINT (including allocated hints like NOP, YIELD, etc) */
 handle_hint(s, insn, op1, op2, crm);
  

Re: [Qemu-devel] [PATCH] linux-user/syscall.c: Handle SH4's exceptional alignment for p{read, write}64

[John Paul Adrian Glaubitz]

On 09/15/2017 08:58 AM, James Clarke wrote:

Fixes: https://bugs.launchpad.net/qemu/+bug/1716767
Signed-off-by: James Clarke 
---
  linux-user/syscall.c | 12 
  1 file changed, 12 insertions(+)

diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 9b6364a266..24d6a81c21 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -10495,20 +10495,32 @@ abi_long do_syscall(void *cpu_env, int num, abi_long 
arg1,
  #endif
  #ifdef TARGET_NR_pread64
  case TARGET_NR_pread64:
+#if defined(TARGET_SH4)
+/* SH4 doesn't align register pairs, except for p{read,write}64 */
+arg4 = arg5;
+arg5 = arg6;
+#else
  if (regpairs_aligned(cpu_env)) {
  arg4 = arg5;
  arg5 = arg6;
  }
+#endif
  if (!(p = lock_user(VERIFY_WRITE, arg2, arg3, 0)))
  goto efault;
  ret = get_errno(pread64(arg1, p, arg3, target_offset64(arg4, arg5)));
  unlock_user(p, arg2, ret);
  break;
  case TARGET_NR_pwrite64:
+#if defined(TARGET_SH4)
+/* SH4 doesn't align register pairs, except for p{read,write}64 */
+arg4 = arg5;
+arg5 = arg6;
+#else
  if (regpairs_aligned(cpu_env)) {
  arg4 = arg5;
  arg5 = arg6;
  }
+#endif
  if (!(p = lock_user(VERIFY_READ, arg2, arg3, 1)))
  goto efault;
  ret = get_errno(pwrite64(arg1, p, arg3, target_offset64(arg4, arg5)));
--
2.13.2


Tested-By: John Paul Adrian Glaubitz 

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

[Qemu-devel] [PATCH v2 0/2] x86_iommu: Fix segfault when starting on non-PCI machines

[Mohammed Gamal]

Starting qemu with
qemu-system-x86_64 -S -M isapc -device {amd|intel}-iommu
leads to a segfault. The code assume PCI bus is present and
tries to access the bus structure without checking.

The patch series moves the error checks from vtd_realize()
and amdvi_realize() to the generic x86_iommu_realize() and
adds a check for PCI bus presence.

v1 --> v2:
* Change error message with capitalized acronym

Mohammed Gamal (2):
  x86_iommu: Move machine check to x86_iommu_realize()
  x86_iommu: check if machine has PCI bus

 hw/i386/amd_iommu.c   | 10 +-
 hw/i386/intel_iommu.c | 10 +-
 hw/i386/x86-iommu.c   | 13 +
 3 files changed, 15 insertions(+), 18 deletions(-)

-- 
1.8.3.1

[Qemu-devel] [PATCH v2 2/2] x86_iommu: check if machine has PCI bus

[Mohammed Gamal]

Starting qemu with
qemu-system-x86_64 -S -M isapc -device {amd|intel}-iommu
leads to a segfault. The code assume PCI bus is present and
tries to access the bus structure without checking.

Since Intel VT-d and AMDVI should only work with PCI, add a
check for PCI bus and return error if not present.

Signed-off-by: Mohammed Gamal 
---
 hw/i386/x86-iommu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/i386/x86-iommu.c b/hw/i386/x86-iommu.c
index 51de519..8a01a2d 100644
--- a/hw/i386/x86-iommu.c
+++ b/hw/i386/x86-iommu.c
@@ -88,7 +88,7 @@ static void x86_iommu_realize(DeviceState *dev, Error **errp)
 PC_MACHINE(object_dynamic_cast(OBJECT(ms), TYPE_PC_MACHINE));
 QLIST_INIT(&x86_iommu->iec_notifiers);
 
-if (!pcms) {
+if (!pcms || !pcms->bus) {
 error_setg(errp, "Machine-type '%s' not supported by IOMMU",
mc->name);
 return;
-- 
1.8.3.1

[Qemu-devel] [PATCH v2 1/2] x86_iommu: Move machine check to x86_iommu_realize()

[Mohammed Gamal]

Instead of having the same error checks in vtd_realize()
and amdvi_realize(), move that over to the generic
x86_iommu_realize().

Signed-off-by: Mohammed Gamal 
---
 hw/i386/amd_iommu.c   | 10 +-
 hw/i386/intel_iommu.c | 10 +-
 hw/i386/x86-iommu.c   | 13 +
 3 files changed, 15 insertions(+), 18 deletions(-)

diff --git a/hw/i386/amd_iommu.c b/hw/i386/amd_iommu.c
index 334938a..839f01f 100644
--- a/hw/i386/amd_iommu.c
+++ b/hw/i386/amd_iommu.c
@@ -1141,18 +1141,10 @@ static void amdvi_realize(DeviceState *dev, Error **err)
 AMDVIState *s = AMD_IOMMU_DEVICE(dev);
 X86IOMMUState *x86_iommu = X86_IOMMU_DEVICE(dev);
 MachineState *ms = MACHINE(qdev_get_machine());
-MachineClass *mc = MACHINE_GET_CLASS(ms);
 PCMachineState *pcms =
 PC_MACHINE(object_dynamic_cast(OBJECT(ms), TYPE_PC_MACHINE));
-PCIBus *bus;
+PCIBus *bus = pcms->bus;
 
-if (!pcms) {
-error_setg(err, "Machine-type '%s' not supported by amd-iommu",
-   mc->name);
-return;
-}
-
-bus = pcms->bus;
 s->iotlb = g_hash_table_new_full(amdvi_uint64_hash,
  amdvi_uint64_equal, g_free, g_free);
 
diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
index 3a5bb0b..aa01812 100644
--- a/hw/i386/intel_iommu.c
+++ b/hw/i386/intel_iommu.c
@@ -3027,20 +3027,12 @@ static bool vtd_decide_config(IntelIOMMUState *s, Error 
**errp)
 static void vtd_realize(DeviceState *dev, Error **errp)
 {
 MachineState *ms = MACHINE(qdev_get_machine());
-MachineClass *mc = MACHINE_GET_CLASS(ms);
 PCMachineState *pcms =
 PC_MACHINE(object_dynamic_cast(OBJECT(ms), TYPE_PC_MACHINE));
-PCIBus *bus;
+PCIBus *bus = pcms->bus;
 IntelIOMMUState *s = INTEL_IOMMU_DEVICE(dev);
 X86IOMMUState *x86_iommu = X86_IOMMU_DEVICE(dev);
 
-if (!pcms) {
-error_setg(errp, "Machine-type '%s' not supported by intel-iommu",
-   mc->name);
-return;
-}
-
-bus = pcms->bus;
 x86_iommu->type = TYPE_INTEL;
 
 if (!vtd_decide_config(s, errp)) {
diff --git a/hw/i386/x86-iommu.c b/hw/i386/x86-iommu.c
index 293caf8..51de519 100644
--- a/hw/i386/x86-iommu.c
+++ b/hw/i386/x86-iommu.c
@@ -21,6 +21,8 @@
 #include "hw/sysbus.h"
 #include "hw/boards.h"
 #include "hw/i386/x86-iommu.h"
+#include "hw/i386/pc.h"
+#include "qapi/error.h"
 #include "qemu/error-report.h"
 #include "trace.h"
 
@@ -80,7 +82,18 @@ static void x86_iommu_realize(DeviceState *dev, Error **errp)
 {
 X86IOMMUState *x86_iommu = X86_IOMMU_DEVICE(dev);
 X86IOMMUClass *x86_class = X86_IOMMU_GET_CLASS(dev);
+MachineState *ms = MACHINE(qdev_get_machine());
+MachineClass *mc = MACHINE_GET_CLASS(ms);
+PCMachineState *pcms =
+PC_MACHINE(object_dynamic_cast(OBJECT(ms), TYPE_PC_MACHINE));
 QLIST_INIT(&x86_iommu->iec_notifiers);
+
+if (!pcms) {
+error_setg(errp, "Machine-type '%s' not supported by IOMMU",
+   mc->name);
+return;
+}
+
 if (x86_class->realize) {
 x86_class->realize(dev, errp);
 }
-- 
1.8.3.1

Re: [Qemu-devel] [PATCH v2 0/5] generalize parsing of cpu_model (x86/arm)

[Igor Mammedov]

On Wed, 13 Sep 2017 18:04:52 +0200
Igor Mammedov  wrote:

> Changelog since v1:
>  * fix merge conflicts with ignore_memory_transaction_failures
>  * fix couple merge conflicts where SoC type string where replaced by type 
> macro
>  * keep plain prefix string in: strncmp(cpu_type, "pxa27", 5)
>  * s/"%s" ARM_CPU_TYPE_SUFFIX/ARM_CPU_TYPE_NAME("%s")/
>  * drop not needed assert
>  * instead of checking error/reporting/exiting explicitly
>use error_fatal which will do all of it for us
>  * squash in "cpu: rename cpu_parse_features() to cpu_parse_cpu_model()"
> 
> 
> Issue 1:  
>
> Some callers call CPUClass->parse_features manually to convert
>
> '-cpu cpufoo,featurestr' string to cpu type and featurestr
>
> into a set of global properties and then do controlled
>
> cpu creation with setting properties and completing it with realize.  
>
> That's a lot of code duplication as they all are practically  
>
> reimplement the same parsing logic.   
>
>   
>
> Some use cpu_generic_init() instead which does the same parsing   
>
> along with creation/realizing cpu within one wrapper. 
>
>   
>
> And some trying to switch to controlled cpu creation, 
>
> implement object_new()/set properties/realize steps   
>
> but forget feature parsing logic witch leads to 'bugs'
>
> commit (00909b585 hw/arm/integratorcp: Support specifying features via -cpu)  
>
>   
>
> Issue 2:  
>
> Default cpu model selection logic is spread over  all board's 
>
> machine_init() fuctions but it's basicallyi hardcodes default 
>
> cpu model string in init function.
>
>   
>
>  if (!cpu_model) {
>
>  cpu_model = "some cpu model string"; 
>
>  }
>
>   
>
> and written in different ways.
>
> it forces machine_init callbacks to parse cpu_model string
>
> either by using cpu_generic_init() or by manually calling 
>
> cpu_class_by_name()/CPUClass::parse_features to perform   
>
> name to cpu type translation.
> 
> This series moves -cpu option parsing to generic machine code 
>
> that removes some of code duplication and makes cpus creation 
>
> process more generic/simple:  
>   
>   
>
>  * unify default (fallback) cpu type handling by replacing
>
>hardcoded cpu_model strings with cpu type directly in  
>
>   
>
>machine_foo_class_init() { 
>
>MachineClass::default_cpu_type = BOARD_DEFAULT_CPU_TYPE
>
>}  
>
>   
>
>which allows to generalize move cpu model parsing instead of   
>
>parsing it in each board.  
>
>   
>
>  * make generic machine vl.c parse cpu_model into properties/cpu_type 
>
>and let boards use cpu_type without any cpu_model prasing. 
>
>Generic parsing will kick in only if board advertises its support  
>
>by setting MachineClass::default_cpu_type to a cpu type.   
>
>   
>
> PS:   
>
> I intend make tree-wide conversion but as one series it's too many patches,   
> 
> so I'm splitting out it into an

Re: [Qemu-devel] [RFC 00/15] QMP: out-of-band (OOB) execution support

[Stefan Hajnoczi]

On Fri, Sep 15, 2017 at 01:29:13PM +0100, Daniel P. Berrange wrote:
> On Fri, Sep 15, 2017 at 01:19:56PM +0100, Dr. David Alan Gilbert wrote:
> > * Daniel P. Berrange (berra...@redhat.com) wrote:
> > > On Fri, Sep 15, 2017 at 01:06:44PM +0100, Dr. David Alan Gilbert wrote:
> > > > * Daniel P. Berrange (berra...@redhat.com) wrote:
> > > > > On Fri, Sep 15, 2017 at 11:49:26AM +0100, Stefan Hajnoczi wrote:
> > > > > > On Fri, Sep 15, 2017 at 11:50:57AM +0800, Peter Xu wrote:
> > > > > > > On Thu, Sep 14, 2017 at 04:19:11PM +0100, Stefan Hajnoczi wrote:
> > > > > > > > On Thu, Sep 14, 2017 at 01:15:09PM +0200, Marc-André Lureau 
> > > > > > > > wrote:
> > > > > > > > > There should be a limit in the number of requests the thread 
> > > > > > > > > can
> > > > > > > > > queue. Before the patch, the limit was enforced by system 
> > > > > > > > > socket
> > > > > > > > > buffering I think. Now, should oob commands still be 
> > > > > > > > > processed even if
> > > > > > > > > the queue is full? If so, the thread can't be suspended.
> > > > > > > > 
> > > > > > > > I agree.
> > > > > > > > 
> > > > > > > > Memory usage must be bounded.  The number of requests is less 
> > > > > > > > important
> > > > > > > > than the amount of memory consumed by them.
> > > > > > > > 
> > > > > > > > Existing QMP clients that send multiple QMP commands without 
> > > > > > > > waiting for
> > > > > > > > replies need to rethink their strategy because OOB commands 
> > > > > > > > cannot be
> > > > > > > > processed if queued non-OOB commands consume too much memory.
> > > > > > > 
> > > > > > > Thanks for pointing out this.  Yes the memory usage problem is 
> > > > > > > valid,
> > > > > > > as Markus pointed out as well in previous discussions (in "Flow
> > > > > > > Control" section of that long reply).  Hopefully this series 
> > > > > > > basically
> > > > > > > can work from design prospective, then I'll add this flow control 
> > > > > > > in
> > > > > > > next version.
> > > > > > > 
> > > > > > > Regarding to what we should do if the limit is reached: Markus
> > > > > > > provided a few options, but the one I prefer most is that we don't
> > > > > > > respond, but send an event showing that a command is dropped.
> > > > > > > However, I would like it not queued, but a direct reply (after 
> > > > > > > all,
> > > > > > > it's an event, and we should not need to care much on ordering of 
> > > > > > > it).
> > > > > > > Then we can get rid of the babysitting of those "to be failed"
> > > > > > > requests asap, meanwhile we don't lose anything IMHO.
> > > > > > > 
> > > > > > > I think I also missed at least a unit test for this new interface.
> > > > > > > Again, I'll add it after the whole idea is proved solid.  Thanks,
> > > > > > 
> > > > > > Another solution: the server reports available receive buffer space 
> > > > > > to
> > > > > > the client.  The server only guarantees immediate OOB processing 
> > > > > > when
> > > > > > the client stays within the receive buffer size.
> > > > > > 
> > > > > > Clients wishing to take advantage of OOB must query the receive 
> > > > > > buffer
> > > > > > size and make sure to leave enough room.
> > > > > 
> > > > > I don't think having to query it ahead of time is particularly nice,
> > > > > and of course it is inherantly racy.
> > > > > 
> > > > > I would just have QEMU emit an event when it pausing processing of the
> > > > > incoming commands due to a full queue.  If the event includes the ID
> > > > > of the last queued command, the client will know which (if any) of
> > > > > its outstanding commands are delayed. Another even can be sent when
> > > > > it restarts reading.
> > > > 
> > > > Hmm and now we're implementing flow control!
> > > > 
> > > > a) What exactly is the current semantics/buffer sizes?
> > > > b) When do clients send multiple QMP commands on one channel without
> > > > waiting for the response to the previous command?
> > > > c) Would one queue entry for each class of commands/channel work
> > > >   (Where a class of commands is currently 'normal' and 'oob')
> > > 
> > > I do wonder if we need to worry about request limiting at all from the
> > > client side.  For non-OOB commands clients will wait for a reply before
> > > sending a 2nd non-OOB command, so you'll never get a deep queue for.
> > > 
> > > OOB commands are supposed to be things which can be handled quickly
> > > without blocking, so even if a client sent several commands at once
> > > without waiting for replies, they're going to be processed quickly,
> > > so whether we temporarily block reading off the wire is a minor
> > > detail.
> > 
> > Lets just define it so that it can't - you send an OOB command and wait
> > for it's response before sending another on that channel.
> > 
> > > IOW, I think we could just have a fixed 10 command queue and apps just
> > > pretend that there's an infinite queue and nothing bad would happen from
> > > the app's POV.
> > 
> > Can you justify 10 as oppo

Re: [Qemu-devel] [PATCH] 9pfs: check the size of transport buffer before marshaling

[Greg Kurz]

On Thu, 14 Sep 2017 19:31:36 +0300
Jan Dakinevich  wrote:

> v9fs_do_readdir_with_stat() and v9fs_do_readdir() stores as much data in
> the buffer as can fit unless marshaling erorr occurs. However, after
> commit 23a006d the behavior pdu_marshal was changed, and on error the
> routine assumes that buffers are misconfigured and breaks communication.
> 

I agree and I could easily reproduce with a linux guest using 9p2000.u, ie, the
v9fs_do_readdir_with_stat() case, but I couldn't find a way to break transport
with 9p2000.L. Do you have a reproducer for the latter ?

I ask because I would appreciate to see some more details in the changelog,
for the records.

> Signed-off-by: Jan Dakinevich 
> ---

Anyway the patch looks fine, but I'll wait for your answer before pushing
to 9p-next.

Cheers,

--
Greg

>  hw/9pfs/9p.c | 44 
>  1 file changed, 32 insertions(+), 12 deletions(-)
> 
> diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
> index 1e38109..8e0b87e 100644
> --- a/hw/9pfs/9p.c
> +++ b/hw/9pfs/9p.c
> @@ -1679,6 +1679,16 @@ static void v9fs_init_qiov_from_pdu(QEMUIOVector 
> *qiov, V9fsPDU *pdu,
>  qemu_iovec_concat(qiov, &elem, skip, size);
>  }
>  
> +static size_t v9fs_marshal_size(V9fsPDU *pdu)
> +{
> +struct iovec *iov;
> +unsigned int niov;
> +
> +pdu->s->transport->init_in_iov_from_pdu(pdu, &iov, &niov, 0);
> +
> +return iov_size(iov, niov);
> +}
> +
>  static int v9fs_xattr_read(V9fsState *s, V9fsPDU *pdu, V9fsFidState *fidp,
> uint64_t off, uint32_t max_count)
>  {
> @@ -1725,6 +1735,10 @@ static int coroutine_fn 
> v9fs_do_readdir_with_stat(V9fsPDU *pdu,
>  off_t saved_dir_pos;
>  struct dirent *dent;
>  
> +/* 11 = 7 + 4 (7 = start offset, 4 = space for storing count) */
> +size_t offset = 11;
> +size_t marshal_size = v9fs_marshal_size(pdu);
> +
>  /* save the directory position */
>  saved_dir_pos = v9fs_co_telldir(pdu, fidp);
>  if (saved_dir_pos < 0) {
> @@ -1752,18 +1766,23 @@ static int coroutine_fn 
> v9fs_do_readdir_with_stat(V9fsPDU *pdu,
>  if (err < 0) {
>  break;
>  }
> -/* 11 = 7 + 4 (7 = start offset, 4 = space for storing count) */
> -len = pdu_marshal(pdu, 11 + count, "S", &v9stat);
>  
> -v9fs_readdir_unlock(&fidp->fs.dir);
> +if (v9stat.size + 2 > MIN(marshal_size - offset, max_count - count)) 
> {
> +v9fs_readdir_unlock(&fidp->fs.dir);
>  
> -if ((len != (v9stat.size + 2)) || ((count + len) > max_count)) {
>  /* Ran out of buffer. Set dir back to old position and return */
>  v9fs_co_seekdir(pdu, fidp, saved_dir_pos);
>  v9fs_stat_free(&v9stat);
>  v9fs_path_free(&path);
>  return count;
>  }
> +
> +len = pdu_marshal(pdu, offset, "S", &v9stat);
> +BUG_ON(len != v9stat.size + 2);
> +
> +v9fs_readdir_unlock(&fidp->fs.dir);
> +
> +offset += len;
>  count += len;
>  v9fs_stat_free(&v9stat);
>  v9fs_path_free(&path);
> @@ -1884,6 +1903,10 @@ static int coroutine_fn v9fs_do_readdir(V9fsPDU *pdu, 
> V9fsFidState *fidp,
>  off_t saved_dir_pos;
>  struct dirent *dent;
>  
> +/* 11 = 7 + 4 (7 = start offset, 4 = space for storing count) */
> +size_t offset = 11;
> +size_t marshal_size = v9fs_marshal_size(pdu);
> +
>  /* save the directory position */
>  saved_dir_pos = v9fs_co_telldir(pdu, fidp);
>  if (saved_dir_pos < 0) {
> @@ -1899,7 +1922,8 @@ static int coroutine_fn v9fs_do_readdir(V9fsPDU *pdu, 
> V9fsFidState *fidp,
>  }
>  v9fs_string_init(&name);
>  v9fs_string_sprintf(&name, "%s", dent->d_name);
> -if ((count + v9fs_readdir_data_size(&name)) > max_count) {
> +if (v9fs_readdir_data_size(&name) > MIN(marshal_size - offset,
> +max_count - count)) {
>  v9fs_readdir_unlock(&fidp->fs.dir);
>  
>  /* Ran out of buffer. Set dir back to old position and return */
> @@ -1918,18 +1942,14 @@ static int coroutine_fn v9fs_do_readdir(V9fsPDU *pdu, 
> V9fsFidState *fidp,
>  qid.type = 0;
>  qid.version = 0;
>  
> -/* 11 = 7 + 4 (7 = start offset, 4 = space for storing count) */
> -len = pdu_marshal(pdu, 11 + count, "Qqbs",
> +len = pdu_marshal(pdu, offset, "Qqbs",
>&qid, dent->d_off,
>dent->d_type, &name);
> +BUG_ON(len != v9fs_readdir_data_size(&name));
>  
>  v9fs_readdir_unlock(&fidp->fs.dir);
>  
> -if (len < 0) {
> -v9fs_co_seekdir(pdu, fidp, saved_dir_pos);
> -v9fs_string_free(&name);
> -return len;
> -}
> +offset += len;
>  count += len;
>  v9fs_string_free(&name);
>  saved_dir_pos = dent->d_off;



pgpWGBaLR8FI5.pgp
Description: OpenPGP d

Re: [Qemu-devel] [PATCH v7 12/13] tests: Add README for vm tests

[Fam Zheng]

On Fri, 09/15 15:24, Alex Bennée wrote:
> 
> Fam Zheng  writes:
> 
> > Signed-off-by: Fam Zheng 
> > ---
> >  tests/vm/README | 63 
> > +
> >  1 file changed, 63 insertions(+)
> >  create mode 100644 tests/vm/README
> >
> > diff --git a/tests/vm/README b/tests/vm/README
> > new file mode 100644
> > index 00..7d2fe4ac8d
> > --- /dev/null
> > +++ b/tests/vm/README
> > @@ -0,0 +1,63 @@
> > +=== VM test suite to run build in guests ===
> > +
> > +== Intro ==
> > +
> > +This test suite contains scripts that bootstrap various guest images that 
> > have
> > +necessary packages to build QEMU. The basic usage is documented in Makefile
> > +help which is displayed with "make vm-test".
> > +
> > +== Quick start ==
> > +
> > +Run "make vm-test" to list available make targets.
> 
> Running make vm-build-netbsd I get several prompts for pass-phrase and
> password:
> 
> Enter passphrase for key './vm-test-QdFtLJ.tmp/id_rsa':
> Password for qemu@:
> Enter passphrase for key './vm-test-QdFtLJ.tmp/id_rsa':
> Password for qemu@:
> ar: creating libfdt/libfdt.a
> 
> Which seems odd considering the private key isn't protected by a
> passphrase and the build tools know what the password is.

Yeah, this version also has a corrupted private key file (the first byte, '-',
is somehow deleted). Sorry for the mess. :(

> 
> We should also mention the images are added to ${QEMU_SRC}/tests/vm/

OK, will do. Also as Peter and Daniel have pointed out, the hostfwd and vnc
should listen on a local address rather than 0.0.0.0. I will send v8 with all of
them fixed.

Fam

Re: [Qemu-devel] [Qemu-arm] [PATCH v7 13/20] hw/arm/smmuv3: Implement IOMMU memory region replay callback

[Auger Eric]

Hi,

On 15/09/2017 12:42, tn wrote:
> Hi Eric,
> 
> On 15.09.2017 09:30, Auger Eric wrote:
>> Hi Tomasz,
>>
>> On 14/09/2017 16:43, Tomasz Nowicki wrote:
>>> On 14.09.2017 16:31, Tomasz Nowicki wrote:
 Hi Eric,

 On 14.09.2017 11:27, Linu Cherian wrote:
> Hi Eric,
>
> On Fri Sep 01, 2017 at 07:21:16PM +0200, Eric Auger wrote:
>> memory_region_iommu_replay() is used for VFIO integration.
>>
>> However its default implementation is not adapted to SMMUv3
>> IOMMU memory region. Indeed the input address range is too
>> huge and its execution is too slow as it calls the translate()
>> callback on each granule.
>>
>> Let's implement the replay callback which hierarchically walk
>> over the page table structure and notify only the segments
>> that are populated with valid entries.
>>
>> Signed-off-by: Eric Auger 
>> ---
>>hw/arm/smmuv3.c | 36 
>>hw/arm/trace-events |  1 +
>>2 files changed, 37 insertions(+)
>>
>> diff --git a/hw/arm/smmuv3.c b/hw/arm/smmuv3.c
>> index 8e7d10d..c43bd93 100644
>> --- a/hw/arm/smmuv3.c
>> +++ b/hw/arm/smmuv3.c
>> @@ -657,6 +657,41 @@ static int smmuv3_notify_entry(IOMMUTLBEntry
>> *entry, void *private)
>>return 0;
>>}
>> +/* Unmap the whole notifier's range */
>> +static void smmuv3_unmap_notifier_range(IOMMUNotifier *n)
>> +{
>> +IOMMUTLBEntry entry;
>> +hwaddr size = n->end - n->start + 1;
>> +
>> +entry.target_as = &address_space_memory;
>> +entry.iova = n->start & ~(size - 1);
>> +entry.perm = IOMMU_NONE;
>> +entry.addr_mask = size - 1;
>> +
>> +memory_region_notify_one(n, &entry);
>> +}
>> +
>> +static void smmuv3_replay(IOMMUMemoryRegion *mr, IOMMUNotifier *n)
>> +{
>> +SMMUTransCfg cfg = {};
>> +int ret;
>> +
>> +trace_smmuv3_replay(mr->parent_obj.name, n, n->start, n->end);
>> +smmuv3_unmap_notifier_range(n);
>> +
>> +ret = smmuv3_decode_config(mr, &cfg);
>> +if (ret) {
>> +error_report("%s error decoding the configuration for iommu
>> mr=%s",
>> + __func__, mr->parent_obj.name);
>> +}
>>
>
> On an invalid config being found, shouldnt we return rather than
> proceeding with
> page table walk. For example on an invalid Stream table entry.

 Indeed, without return here vhost case is not working for me.
>>>
>>> I was just lucky one time. return here has no influence. Vhost still not
>>> working. Sorry for noise.
>>
>> As far as I understand the replay() callback only is called in VFIO use
>> case. So this shouldn't impact vhost.
>>
>> I can't reproduce your vhost issue on my side. I will review the
>> invalidate code again and compare against the last version.
>>
>> What is the page size used by your guest?
> 
> 64K page size for guest as well as for host.
> 
> However, I've just checked 4K page size for guest and then vhost is
> working fine.
So the bug stems from the incorrect target page size used on
SMMU_CMD_TLBI_NH_VA invalidation. This is now corrected by using the
actual config granule size and this fixes the issue with vhost use case
and 64KB page guest. I will release this fix early next week. Sorry for
the inconvenience.

Thanks

Eric
> 
> Thanks,
> Tomasz

Re: [Qemu-devel] [PULL v4 00/38] Test and build patches

[Philippe Mathieu-Daudé]

Hi Daniel,

On 09/15/2017 08:40 AM, Daniel P. Berrange wrote:

On Fri, Sep 15, 2017 at 11:55:44AM +0100, Peter Maydell wrote:

[...]


So, before I commit an ssh private key to our git repo,
can you explain why it's ok that this is public? The
commit message for the relevant patch doesn't really say.


IIUC, the public part of the key gets exposed to the guest images via
cloud-init metadata. During boot the guest read this metadata and add
the public key to authorized_keys. The private key is used by the test
suite on the host so that it can now login to the guests.

So the risk here is that if these guests were exposed to the LAN in any
way, someone could grab our private key and login to these guests.

What saves us is that the VMs are run with user mode slirp networking
so AFAICT, aren't exposed to the LAN.  So as long as we don't change
this to any kind of real networking, I think its acceptable to have
the private key in it and doesn't expose developer's workstations to
undue risk and avoids consuming system entropy to generate new keys

> during build.

which systems are you worried about? build-farms or developer's stations?

why do you want to generate more than 1 key? why not generate 1 key in 
tests/vm/ (or clever ~/.cache/qemu-vm/ already used by those scripts) 
once when the make vm-test rule is called, that would be 1 key per 
repository clone (or 1 per user using ~/.cache).


Distrib aren't using the test suite in binary packages.

Regards,

Phil.

Re: [Qemu-devel] kvm_intel fails to load on Conroe CPUs running Linux 4.12

[Gerhard Wiesinger]

On 27.08.2017 20:55, Paolo Bonzini wrote:



Il 27 ago 2017 4:48 PM, "Gerhard Wiesinger" > ha scritto:


On 27.08.2017 14 :03, Paolo Bonzini wrote:


We will revert the patch, but 4.13.0 will not have the fix.
Expect it in later stable kernels (because vacations).


Thnx. Why will 4.13.0 NOT have the fix?


Because maintainers are on vacation! :-)




Hello Paolo,

Any update on this for 4.12 and 4.13 kernels?

Thnx.

Ciao,

Gerhard

[Qemu-devel] [Bug 1384892] Re: RTL8168 NIC VFIO not working anymore since QEMU 2.1

[Thomas Huth]

The patch that has been mentioned in the last comment has been included here:
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=31e6a7b17b35711eb44f0e
... and has been released with QEMU v2.8 already, so marking this as "fix 
released" now.

** Changed in: qemu
   Status: New => Fix Released

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

Title:
  RTL8168 NIC VFIO not working anymore since QEMU 2.1

Status in QEMU:
  Fix Released

Bug description:
  After upgrading QEMU from 2.0 to 2.1 (and libiscsi from 1.7.0 to 1.12 as a 
dependency) my two RTL8168 NICs stopped working.
  The NICs do not respond to any command and even the LEDs on the network 
connection turn off, a few seconds after the VM started.
  To get them back running I had to downgrade to 2.0 and restart the system.
  Unfortunately, I have no clue what to do or how to debug this problem since 
there are no specific errors logged.
  I tried two different VMs: Debian Wheezy and IPFire (see attachment for 
further details).
  The QEMU 2.1 changelog states "Support for RTL8168 NICs." so there were some 
major changes done, I guess.

  On the IPFire guest the kernel log shows many of these lines:
  r8169 :00:07.0 green1: rtl_eriar_cond == 1 (loop: 100, delay: 100)
  r8169 :00:07.0 green1: rtl_phy_reset_cond == 1 (loop: 100, delay: 1)

  On the Debian guest there is only:
  r8169 :00:07.0: firmware: agent loaded rtl_nic/rtl8168e-3.fw into memory
  r8169 :00:07.0: lan0: link down
  ADDRCONF(NETDEV_UP): lan0: link is not ready

  The commandline for IPFire can be seen in the attachment. It is the same for 
Debian.
  There are also the complete kernel logs for the working (2.0) and non-working 
(2.1) cases.

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

[Qemu-devel] [PATCH v3 1/2] virtio-gpu: Handle endian conversion

[Farhan Ali]

Virtio GPU code currently only supports litte endian format,
and so using the Virtio GPU device on a big endian machine
does not work.

Let's fix it by supporting the correct host cpu byte order.

Signed-off-by: Farhan Ali 
---
 hw/display/virtio-gpu.c | 70 +++--
 1 file changed, 62 insertions(+), 8 deletions(-)

diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
index 6aae147..0ef7e5c 100644
--- a/hw/display/virtio-gpu.c
+++ b/hw/display/virtio-gpu.c
@@ -30,6 +30,48 @@ virtio_gpu_find_resource(VirtIOGPU *g, uint32_t resource_id);
 
 static void virtio_gpu_cleanup_mapping(struct virtio_gpu_simple_resource *res);
 
+static void
+virtio_gpu_ctrl_hdr_bswap(struct virtio_gpu_ctrl_hdr *hdr)
+{
+le32_to_cpus(&hdr->type);
+le32_to_cpus(&hdr->flags);
+le64_to_cpus(&hdr->fence_id);
+le32_to_cpus(&hdr->ctx_id);
+le32_to_cpus(&hdr->padding);
+}
+
+static void virtio_gpu_bswap_32(void *ptr,
+size_t size)
+{
+#ifdef HOST_WORDS_BIGENDIAN
+
+size_t i;
+struct virtio_gpu_ctrl_hdr *hdr = (struct virtio_gpu_ctrl_hdr *) ptr;
+
+virtio_gpu_ctrl_hdr_bswap(hdr);
+
+i = sizeof(struct virtio_gpu_ctrl_hdr);
+while (i < size) {
+le32_to_cpus((uint32_t *)(ptr + i));
+i = i + sizeof(uint32_t);
+}
+
+#endif
+}
+
+static void
+virtio_gpu_t2d_bswap(struct virtio_gpu_transfer_to_host_2d *t2d)
+{
+virtio_gpu_ctrl_hdr_bswap(&t2d->hdr);
+le32_to_cpus(&t2d->r.x);
+le32_to_cpus(&t2d->r.y);
+le32_to_cpus(&t2d->r.width);
+le32_to_cpus(&t2d->r.height);
+le64_to_cpus(&t2d->offset);
+le32_to_cpus(&t2d->resource_id);
+le32_to_cpus(&t2d->padding);
+}
+
 #ifdef CONFIG_VIRGL
 #include 
 #define VIRGL(_g, _virgl, _simple, ...) \
@@ -205,6 +247,7 @@ void virtio_gpu_ctrl_response(VirtIOGPU *g,
 resp->fence_id = cmd->cmd_hdr.fence_id;
 resp->ctx_id = cmd->cmd_hdr.ctx_id;
 }
+virtio_gpu_ctrl_hdr_bswap(resp);
 s = iov_from_buf(cmd->elem.in_sg, cmd->elem.in_num, 0, resp, resp_len);
 if (s != resp_len) {
 qemu_log_mask(LOG_GUEST_ERROR,
@@ -236,8 +279,8 @@ virtio_gpu_fill_display_info(VirtIOGPU *g,
 for (i = 0; i < g->conf.max_outputs; i++) {
 if (g->enabled_output_bitmask & (1 << i)) {
 dpy_info->pmodes[i].enabled = 1;
-dpy_info->pmodes[i].r.width = g->req_state[i].width;
-dpy_info->pmodes[i].r.height = g->req_state[i].height;
+dpy_info->pmodes[i].r.width = cpu_to_le32(g->req_state[i].width);
+dpy_info->pmodes[i].r.height = cpu_to_le32(g->req_state[i].height);
 }
 }
 }
@@ -287,6 +330,7 @@ static void virtio_gpu_resource_create_2d(VirtIOGPU *g,
 struct virtio_gpu_resource_create_2d c2d;
 
 VIRTIO_GPU_FILL_CMD(c2d);
+virtio_gpu_bswap_32(&c2d, sizeof(c2d));
 trace_virtio_gpu_cmd_res_create_2d(c2d.resource_id, c2d.format,
c2d.width, c2d.height);
 
@@ -360,6 +404,7 @@ static void virtio_gpu_resource_unref(VirtIOGPU *g,
 struct virtio_gpu_resource_unref unref;
 
 VIRTIO_GPU_FILL_CMD(unref);
+virtio_gpu_bswap_32(&unref, sizeof(unref));
 trace_virtio_gpu_cmd_res_unref(unref.resource_id);
 
 res = virtio_gpu_find_resource(g, unref.resource_id);
@@ -383,6 +428,7 @@ static void virtio_gpu_transfer_to_host_2d(VirtIOGPU *g,
 struct virtio_gpu_transfer_to_host_2d t2d;
 
 VIRTIO_GPU_FILL_CMD(t2d);
+virtio_gpu_t2d_bswap(&t2d);
 trace_virtio_gpu_cmd_res_xfer_toh_2d(t2d.resource_id);
 
 res = virtio_gpu_find_resource(g, t2d.resource_id);
@@ -439,6 +485,7 @@ static void virtio_gpu_resource_flush(VirtIOGPU *g,
 int i;
 
 VIRTIO_GPU_FILL_CMD(rf);
+virtio_gpu_bswap_32(&rf, sizeof(rf));
 trace_virtio_gpu_cmd_res_flush(rf.resource_id,
rf.r.width, rf.r.height, rf.r.x, rf.r.y);
 
@@ -511,6 +558,7 @@ static void virtio_gpu_set_scanout(VirtIOGPU *g,
 struct virtio_gpu_set_scanout ss;
 
 VIRTIO_GPU_FILL_CMD(ss);
+virtio_gpu_bswap_32(&ss, sizeof(ss));
 trace_virtio_gpu_cmd_set_scanout(ss.scanout_id, ss.resource_id,
  ss.r.width, ss.r.height, ss.r.x, ss.r.y);
 
@@ -633,13 +681,15 @@ int virtio_gpu_create_mapping_iov(struct 
virtio_gpu_resource_attach_backing *ab,
 *addr = g_malloc0(sizeof(uint64_t) * ab->nr_entries);
 }
 for (i = 0; i < ab->nr_entries; i++) {
-hwaddr len = ents[i].length;
-(*iov)[i].iov_len = ents[i].length;
-(*iov)[i].iov_base = cpu_physical_memory_map(ents[i].addr, &len, 1);
+uint64_t a = le64_to_cpu(ents[i].addr);
+uint32_t l = le32_to_cpu(ents[i].length);
+hwaddr len = l;
+(*iov)[i].iov_len = l;
+(*iov)[i].iov_base = cpu_physical_memory_map(a, &len, 1);
 if (addr) {
-(*addr)[i] = ents[i].addr;
+(*addr)[i] = a;
 }
-if (!(*iov)[i].

Re: [Qemu-devel] [Qemu-arm] [PATCH v7 13/20] hw/arm/smmuv3: Implement IOMMU memory region replay callback

[tn]

Hi Eric,

On 15.09.2017 09:30, Auger Eric wrote:

Hi Tomasz,

On 14/09/2017 16:43, Tomasz Nowicki wrote:

On 14.09.2017 16:31, Tomasz Nowicki wrote:

Hi Eric,

On 14.09.2017 11:27, Linu Cherian wrote:

Hi Eric,

On Fri Sep 01, 2017 at 07:21:16PM +0200, Eric Auger wrote:

memory_region_iommu_replay() is used for VFIO integration.

However its default implementation is not adapted to SMMUv3
IOMMU memory region. Indeed the input address range is too
huge and its execution is too slow as it calls the translate()
callback on each granule.

Let's implement the replay callback which hierarchically walk
over the page table structure and notify only the segments
that are populated with valid entries.

Signed-off-by: Eric Auger 
---
   hw/arm/smmuv3.c | 36 
   hw/arm/trace-events |  1 +
   2 files changed, 37 insertions(+)

diff --git a/hw/arm/smmuv3.c b/hw/arm/smmuv3.c
index 8e7d10d..c43bd93 100644
--- a/hw/arm/smmuv3.c
+++ b/hw/arm/smmuv3.c
@@ -657,6 +657,41 @@ static int smmuv3_notify_entry(IOMMUTLBEntry
*entry, void *private)
   return 0;
   }
+/* Unmap the whole notifier's range */
+static void smmuv3_unmap_notifier_range(IOMMUNotifier *n)
+{
+IOMMUTLBEntry entry;
+hwaddr size = n->end - n->start + 1;
+
+entry.target_as = &address_space_memory;
+entry.iova = n->start & ~(size - 1);
+entry.perm = IOMMU_NONE;
+entry.addr_mask = size - 1;
+
+memory_region_notify_one(n, &entry);
+}
+
+static void smmuv3_replay(IOMMUMemoryRegion *mr, IOMMUNotifier *n)
+{
+SMMUTransCfg cfg = {};
+int ret;
+
+trace_smmuv3_replay(mr->parent_obj.name, n, n->start, n->end);
+smmuv3_unmap_notifier_range(n);
+
+ret = smmuv3_decode_config(mr, &cfg);
+if (ret) {
+error_report("%s error decoding the configuration for iommu
mr=%s",
+ __func__, mr->parent_obj.name);
+}



On an invalid config being found, shouldnt we return rather than
proceeding with
page table walk. For example on an invalid Stream table entry.


Indeed, without return here vhost case is not working for me.


I was just lucky one time. return here has no influence. Vhost still not
working. Sorry for noise.


As far as I understand the replay() callback only is called in VFIO use
case. So this shouldn't impact vhost.

I can't reproduce your vhost issue on my side. I will review the
invalidate code again and compare against the last version.

What is the page size used by your guest?


64K page size for guest as well as for host.

However, I've just checked 4K page size for guest and then vhost is 
working fine.


Thanks,
Tomasz

[Qemu-devel] [PATCH v3 2/2] virtio-gpu-ccw: Create a virtio gpu device for the ccw bus

[Farhan Ali]

Wire up the virtio-gpu device for the CCW bus. The virtio-gpu
is a virtio-1 device, so disable revision 0.

Signed-off-by: Farhan Ali 
Acked-by: Christian Borntraeger 
Reviewed-by: Halil Pasic 
Reviewed-by: Thomas Huth 
---
 hw/s390x/virtio-ccw.c | 49 +
 hw/s390x/virtio-ccw.h | 10 ++
 2 files changed, 59 insertions(+)

diff --git a/hw/s390x/virtio-ccw.c b/hw/s390x/virtio-ccw.c
index b1976fd..12cacf6 100644
--- a/hw/s390x/virtio-ccw.c
+++ b/hw/s390x/virtio-ccw.c
@@ -1007,6 +1007,15 @@ static void virtio_ccw_crypto_realize(VirtioCcwDevice 
*ccw_dev, Error **errp)
  NULL);
 }
 
+static void virtio_ccw_gpu_realize(VirtioCcwDevice *ccw_dev, Error **errp)
+{
+VirtIOGPUCcw *dev = VIRTIO_GPU_CCW(ccw_dev);
+DeviceState *vdev = DEVICE(&dev->vdev);
+
+qdev_set_parent_bus(vdev, BUS(&ccw_dev->bus));
+object_property_set_bool(OBJECT(vdev), true, "realized", errp);
+}
+
 /* DeviceState to VirtioCcwDevice. Note: used on datapath,
  * be careful and test performance if you change this.
  */
@@ -1616,6 +1625,45 @@ static const TypeInfo virtio_ccw_crypto = {
 .class_init= virtio_ccw_crypto_class_init,
 };
 
+static Property virtio_ccw_gpu_properties[] = {
+DEFINE_PROP_BIT("ioeventfd", VirtioCcwDevice, flags,
+VIRTIO_CCW_FLAG_USE_IOEVENTFD_BIT, true),
+DEFINE_PROP_UINT32("max_revision", VirtioCcwDevice, max_rev,
+   VIRTIO_CCW_MAX_REV),
+DEFINE_PROP_END_OF_LIST(),
+};
+
+static void virtio_ccw_gpu_instance_init(Object *obj)
+{
+VirtIOGPUCcw *dev = VIRTIO_GPU_CCW(obj);
+VirtioCcwDevice *ccw_dev = VIRTIO_CCW_DEVICE(obj);
+
+ccw_dev->force_revision_1 = true;
+virtio_instance_init_common(obj, &dev->vdev, sizeof(dev->vdev),
+TYPE_VIRTIO_GPU);
+}
+
+static void virtio_ccw_gpu_class_init(ObjectClass *klass, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(klass);
+VirtIOCCWDeviceClass *k = VIRTIO_CCW_DEVICE_CLASS(klass);
+
+k->realize = virtio_ccw_gpu_realize;
+k->exit = virtio_ccw_exit;
+dc->reset = virtio_ccw_reset;
+dc->props = virtio_ccw_gpu_properties;
+dc->hotpluggable = false;
+set_bit(DEVICE_CATEGORY_DISPLAY, dc->categories);
+}
+
+static const TypeInfo virtio_ccw_gpu = {
+.name  = TYPE_VIRTIO_GPU_CCW,
+.parent= TYPE_VIRTIO_CCW_DEVICE,
+.instance_size = sizeof(VirtIOGPUCcw),
+.instance_init = virtio_ccw_gpu_instance_init,
+.class_init= virtio_ccw_gpu_class_init,
+};
+
 static void virtio_ccw_busdev_realize(DeviceState *dev, Error **errp)
 {
 VirtioCcwDevice *_dev = (VirtioCcwDevice *)dev;
@@ -1815,6 +1863,7 @@ static void virtio_ccw_register(void)
 type_register_static(&vhost_vsock_ccw_info);
 #endif
 type_register_static(&virtio_ccw_crypto);
+type_register_static(&virtio_ccw_gpu);
 }
 
 type_init(virtio_ccw_register)
diff --git a/hw/s390x/virtio-ccw.h b/hw/s390x/virtio-ccw.h
index 41d4010..541fdd2 100644
--- a/hw/s390x/virtio-ccw.h
+++ b/hw/s390x/virtio-ccw.h
@@ -27,6 +27,7 @@
 #ifdef CONFIG_VHOST_VSOCK
 #include "hw/virtio/vhost-vsock.h"
 #endif /* CONFIG_VHOST_VSOCK */
+#include "hw/virtio/virtio-gpu.h"
 
 #include "hw/s390x/s390_flic.h"
 #include "hw/s390x/css.h"
@@ -223,4 +224,13 @@ typedef struct VHostVSockCCWState {
 
 #endif /* CONFIG_VHOST_VSOCK */
 
+#define TYPE_VIRTIO_GPU_CCW "virtio-gpu-ccw"
+#define VIRTIO_GPU_CCW(obj) \
+OBJECT_CHECK(VirtIOGPUCcw, (obj), TYPE_VIRTIO_GPU_CCW)
+
+typedef struct VirtIOGPUCcw {
+VirtioCcwDevice parent_obj;
+VirtIOGPU vdev;
+} VirtIOGPUCcw;
+
 #endif
-- 
1.9.1

[Qemu-devel] [PATCH v3 0/2] Virtio GPU for S390

[Farhan Ali]

These patches wire up the virtio-gpu device for CCW bus for
S390.

For the S390 architecture which does not natively support any graphics
device, virtio gpu in 2D mode could be used to emulate a simple graphics
card and use VNC as the display.

eg: qemu-system-s390x ... -device virtio-gpu-ccw,devno=fe.0.0101
-vnc host_ip_addr:5900

Note, to actually see any display content the
guest kernel needs to support DRM layer, Virtio GPU driver,
the Virtual Terminal layer etc.

I would appreciate any feedback on these patches, specially the
first patch.

ChangeLog

v1 -> v2
- remove error_propagate (patch 2)
- Add byteswap functions (patch 1)
- Handle endian conversion for virtio_gpu_ctrl_response (patch 1)

v2 -> v3
- updated patch 1 based on Gerd's feedback
- rename bswap functions (patch 1)
- use in-place swapping functions (patch 1)
- Handle endian conversion for cursor update (patch 1)

Thank you
Farhan


Farhan Ali (2):
  virtio-gpu: Handle endian conversion
  virtio-gpu-ccw: Create a virtio gpu device for the ccw bus

 hw/display/virtio-gpu.c | 70 +++--
 hw/s390x/virtio-ccw.c   | 49 ++
 hw/s390x/virtio-ccw.h   | 10 +++
 3 files changed, 121 insertions(+), 8 deletions(-)

-- 
1.9.1

Re: [Qemu-devel] [PATCH REPOST v19 1/2] virtio-crypto: Add virtio crypto device specification

[Halil Pasic]

On 09/11/2017 03:12 AM, Longpeng(Mike) wrote:
> From: Gonglei 
> 
> The virtio crypto device is a virtual crypto device (ie. hardware
> crypto accelerator card). Currently, the virtio crypto device provides
> the following crypto services: CIPHER, MAC, HASH, and AEAD.
> 
> In this patch, CIPHER, MAC, HASH, AEAD services are introduced.
> 
> VIRTIO-153
> 
> Signed-off-by: Gonglei 
> Signed-off-by: Longpeng(Mike) 
> ---
>  acknowledgements.tex |3 +
>  content.tex  |2 +
>  virtio-crypto.tex| 1479 
> ++
>  3 files changed, 1484 insertions(+)
>  create mode 100644 virtio-crypto.tex
> 
> diff --git a/acknowledgements.tex b/acknowledgements.tex
> index 6c86d12..c4b6844 100644
> --- a/acknowledgements.tex
> +++ b/acknowledgements.tex
> @@ -26,6 +26,8 @@ Sasha Levin,Oracle  \newline
>  Sergey Tverdyshev,   Thales e-Security   \newline
>  Stefan Hajnoczi, Red Hat \newline
>  Tom Lyon,Samya Systems, Inc. \newline
> +Lei Gong,Huawei  \newline
> +Peng Long,   Huawei  \newline
>  \end{oasistitlesection}
> 
>  The following non-members have provided valuable feedback on this
> @@ -43,4 +45,5 @@ Laura Novich, Red Hat   \newline
>  Patrick Durusau, Technical Advisory Board, OASIS \newline
>  Thomas Huth, IBM \newline
>  Yan Vugenfirer, Red Hat / Daynix \newline
> +Halil Pasic, IBM \newline
>  \end{oasistitlesection}
> diff --git a/content.tex b/content.tex
> index d989d98..7710f8c 100644
> --- a/content.tex
> +++ b/content.tex
> @@ -5641,6 +5641,8 @@ descriptor for the \field{sense_len}, \field{residual},
>  \field{status_qualifier}, \field{status}, \field{response} and
>  \field{sense} fields.
> 
> +\input{virtio-crypto.tex}
> +
>  \chapter{Reserved Feature Bits}\label{sec:Reserved Feature Bits}
> 
>  Currently there are three device-independent feature bits defined:
> diff --git a/virtio-crypto.tex b/virtio-crypto.tex
> new file mode 100644
> index 000..1e75cbc
> --- /dev/null
> +++ b/virtio-crypto.tex
> @@ -0,0 +1,1479 @@
> +\section{Crypto Device}\label{sec:Device Types / Crypto Device}
> +
> +The virtio crypto device is a virtual cryptography device as well as a
> +virtual cryptographic accelerator. The virtio crypto device provides the
> +following crypto services: CIPHER, MAC, HASH, and AEAD. Virtio crypto
> +devices have a single control queue and at least one data queue. Crypto
> +operation requests are placed into a data queue, and serviced by the
> +device. Some crypto operation requests are only valid in the context of a
> +session. The role of the control queue is facilitating control operation
> +requests. Sessions management is realized with control operation
> +requests.
> +
> +\subsection{Device ID}\label{sec:Device Types / Crypto Device / Device ID}
> +
> +20
> +
> +\subsection{Virtqueues}\label{sec:Device Types / Crypto Device / Virtqueues}
> +
> +\begin{description}
> +\item[0] dataq1
> +\item[\ldots]
> +\item[N-1] dataqN
> +\item[N] controlq
> +\end{description}
> +
> +N is set by \field{max_dataqueues}.
> +
> +\subsection{Feature bits}\label{sec:Device Types / Crypto Device / Feature 
> bits}
> +
> +\begin{description}
> +\item VIRTIO_CRYPTO_F_MUX_MODE (0) multiplexing mode is available.
> +\item VIRTIO_CRYPTO_F_CIPHER_STATELESS_MODE (1) stateless mode is available 
> for CIPHER service.
> +\item VIRTIO_CRYPTO_F_HASH_STATELESS_MODE (2) stateless mode is available 
> for HASH service.
> +\item VIRTIO_CRYPTO_F_MAC_STATELESS_MODE (3) stateless mode is available for 
> MAC service.
> +\item VIRTIO_CRYPTO_F_AEAD_STATELESS_MODE (4) stateless mode is available 
> for AEAD service.
> +\end{description}
> +
> +\subsubsection{Feature bit requirements}\label{sec:Device Types / Crypto 
> Device / Feature bits}
> +
> +Some crypto feature bits require other crypto feature bits
> +(see \ref{drivernormative:Basic Facilities of a Virtio Device / Feature 
> Bits}):
> +
> +\begin{description}
> +\item[VIRTIO_CRYPTO_F_CIPHER_STATELESS_MODE] Requires 
> VIRTIO_CRYPTO_F_MUX_MODE.
> +\item[VIRTIO_CRYPTO_F_HASH_STATELESS_MODE] Requires VIRTIO_CRYPTO_F_MUX_MODE.
> +\item[VIRTIO_CRYPTO_F_MAC_STATELESS_MODE] Requires VIRTIO_CRYPTO_F_MUX_MODE.
> +\item[VIRTIO_CRYPTO_F_AEAD_STATELESS_MODE] Requires VIRTIO_CRYPTO_F_MUX_MODE.
> +\end{description}
> +
> +\subsection{Supported crypto services}\label{sec:Device Types / Crypto 
> Device / Supported crypto services}
> +
> +The following crypto services are defined:
> +
> +\begin{lstlisting}
> +/* CIPHER service */
> +#define VIRTIO_CRYPTO_SERVICE_CIPHER 0
> +/* HASH service */
> +#define VIRTIO_CRYPTO_SERVICE_HASH   1
> +/* MAC (Message Authentication Codes) service */
> +#define VIRTIO_CRYPTO_SERVICE_MAC2
> +/* AEAD (Authenticated Encryption with Associated Data) service */
> +#define VIRTIO_CRYPTO_SERVICE_AEAD   3
> +\end{lstlisting}
> +
> +The above constants designate bits used to indicate the which of crypto 
> services are
> +offered by the device as descri

[Qemu-devel] [Bug 1717414] [NEW] Sending certain keysyms results in wrong symbol input

[Iordan Iordanov]

Public bug reported:

I develop bVNC, an Android VNC client. I noticed that when I connect to
qemu VMs that have a VNC console, Keysyms that are usually sent over
with SHIFT modifier when connecting from a PC have wrong symbols typed
within the VM. A very short list of examples:

exclam  33 0x0021

results in "1" typed in the VM.

at  64 0x0040

results in "2"

plus43 0x002b

results in "="

asterisk42 0x002a

results in "8"

On Android, KEYCODEs that correspond to the above keysyms do not come
with SHIFT metastate. Therefore, the keysyms that they correspond to are
not sent over with any modifiers and must just work.

The issue was reproduced with bVNC and RealVNC viewers connecting to
many versions of qemu (Ubuntu 14.04, oVirt 3.4, oVirt 4.1, etc.). The
qemu version that comes with oVirt 4.1 is 2.6.0, commit hash
bfc766d38e1fae5767d43845c15c79ac8fa6d6af.

Sincerely,
iordan

** Affects: qemu
 Importance: Undecided
 Status: New

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

Title:
  Sending certain keysyms results in wrong symbol input

Status in QEMU:
  New

Bug description:
  I develop bVNC, an Android VNC client. I noticed that when I connect
  to qemu VMs that have a VNC console, Keysyms that are usually sent
  over with SHIFT modifier when connecting from a PC have wrong symbols
  typed within the VM. A very short list of examples:

  exclam  33 0x0021

  results in "1" typed in the VM.

  at  64 0x0040

  results in "2"

  plus43 0x002b

  results in "="

  asterisk42 0x002a

  results in "8"

  On Android, KEYCODEs that correspond to the above keysyms do not come
  with SHIFT metastate. Therefore, the keysyms that they correspond to
  are not sent over with any modifiers and must just work.

  The issue was reproduced with bVNC and RealVNC viewers connecting to
  many versions of qemu (Ubuntu 14.04, oVirt 3.4, oVirt 4.1, etc.). The
  qemu version that comes with oVirt 4.1 is 2.6.0, commit hash
  bfc766d38e1fae5767d43845c15c79ac8fa6d6af.

  Sincerely,
  iordan

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

Re: [Qemu-devel] [PATCH] target/s390x/kvm: Fix problem when running with SELinux under z/VM

[Thomas Huth]

On 29.03.2017 16:25, Christian Borntraeger wrote:
> On 03/29/2017 04:21 PM, Thomas Huth wrote:
>> On 24.03.2017 10:39, Christian Borntraeger wrote:
>>> On 03/24/2017 10:26 AM, Thomas Huth wrote:
 When running QEMU with KVM under z/VM, the memory for the guest
 is allocated via legacy_s390_alloc() since the KVM_CAP_S390_COW
 extension is not supported on z/VM. legacy_s390_alloc() then uses
 mmap(... PROT_EXEC ...) for the guest memory - but this does not
 work when running with SELinux enabled, mmap() fails and QEMU aborts
 with the following error message:

  cannot set up guest memory 's390.ram': Permission denied

 Looking at the other allocator function qemu_anon_ram_alloc(), it
 seems like PROT_EXEC is normally not needed for allocating the
 guest RAM, and indeed, the guest also starts successfully under
 z/VM when we remove the PROT_EXEC from the legacy_s390_alloc()
 function. So let's get rid of that flag here to be able to run
 with SELinux under z/VM, too.
>>>
>>> Older z/VM versions do not provide the enhanced suppression on protection
>>> facility, which would result in guest failures as soon as the kernel
>>> starts dirty pages tracking by write protecting the pages via the page
>>> table. Some kernel release back (last time I checked) the PROT_EXEC was 
>>> necessary to prevent the dirty pages tracking from taking place. So this
>>> patch would break KVM in that case.
>>>
>>> Newer z/VMs (e.g. 6.3) do provide ESOP. SO the question is,
>>> why is KVM_CAP_S390_COW not set?
>>
>> I now had another look at this, and seems like the ESOP bit is indeed
>> not set in S390_lowcore.machine_flags here. According to /proc/sysinfo,
>> z/VM is version 6.1.0 here, so I guess that's just too old for ESOP?
> 
> Yes, this was introduced with z/VM 6.3

FWIW, the last version without ESOP, z/VM 6.2, is now end of life,
according to: http://www.vm.ibm.com/techinfo/lpmigr/vmleos.html
... so I guess we could remove the legacy_s390_alloc() function now?

 Thomas

Re: [Qemu-devel] [RFC 00/15] QMP: out-of-band (OOB) execution support

[Daniel P. Berrange]

On Fri, Sep 15, 2017 at 03:29:46PM +0100, Dr. David Alan Gilbert wrote:
> * Daniel P. Berrange (berra...@redhat.com) wrote:
> > On Fri, Sep 15, 2017 at 01:19:56PM +0100, Dr. David Alan Gilbert wrote:
> > > * Daniel P. Berrange (berra...@redhat.com) wrote:
> > > > On Fri, Sep 15, 2017 at 01:06:44PM +0100, Dr. David Alan Gilbert wrote:
> > > > > * Daniel P. Berrange (berra...@redhat.com) wrote:
> > > > > > On Fri, Sep 15, 2017 at 11:49:26AM +0100, Stefan Hajnoczi wrote:
> > > > > > > On Fri, Sep 15, 2017 at 11:50:57AM +0800, Peter Xu wrote:
> > > > > > > > On Thu, Sep 14, 2017 at 04:19:11PM +0100, Stefan Hajnoczi wrote:
> > > > > > > > > On Thu, Sep 14, 2017 at 01:15:09PM +0200, Marc-André Lureau 
> > > > > > > > > wrote:
> > > > > > > > > > There should be a limit in the number of requests the 
> > > > > > > > > > thread can
> > > > > > > > > > queue. Before the patch, the limit was enforced by system 
> > > > > > > > > > socket
> > > > > > > > > > buffering I think. Now, should oob commands still be 
> > > > > > > > > > processed even if
> > > > > > > > > > the queue is full? If so, the thread can't be suspended.
> > > > > > > > > 
> > > > > > > > > I agree.
> > > > > > > > > 
> > > > > > > > > Memory usage must be bounded.  The number of requests is less 
> > > > > > > > > important
> > > > > > > > > than the amount of memory consumed by them.
> > > > > > > > > 
> > > > > > > > > Existing QMP clients that send multiple QMP commands without 
> > > > > > > > > waiting for
> > > > > > > > > replies need to rethink their strategy because OOB commands 
> > > > > > > > > cannot be
> > > > > > > > > processed if queued non-OOB commands consume too much memory.
> > > > > > > > 
> > > > > > > > Thanks for pointing out this.  Yes the memory usage problem is 
> > > > > > > > valid,
> > > > > > > > as Markus pointed out as well in previous discussions (in "Flow
> > > > > > > > Control" section of that long reply).  Hopefully this series 
> > > > > > > > basically
> > > > > > > > can work from design prospective, then I'll add this flow 
> > > > > > > > control in
> > > > > > > > next version.
> > > > > > > > 
> > > > > > > > Regarding to what we should do if the limit is reached: Markus
> > > > > > > > provided a few options, but the one I prefer most is that we 
> > > > > > > > don't
> > > > > > > > respond, but send an event showing that a command is dropped.
> > > > > > > > However, I would like it not queued, but a direct reply (after 
> > > > > > > > all,
> > > > > > > > it's an event, and we should not need to care much on ordering 
> > > > > > > > of it).
> > > > > > > > Then we can get rid of the babysitting of those "to be failed"
> > > > > > > > requests asap, meanwhile we don't lose anything IMHO.
> > > > > > > > 
> > > > > > > > I think I also missed at least a unit test for this new 
> > > > > > > > interface.
> > > > > > > > Again, I'll add it after the whole idea is proved solid.  
> > > > > > > > Thanks,
> > > > > > > 
> > > > > > > Another solution: the server reports available receive buffer 
> > > > > > > space to
> > > > > > > the client.  The server only guarantees immediate OOB processing 
> > > > > > > when
> > > > > > > the client stays within the receive buffer size.
> > > > > > > 
> > > > > > > Clients wishing to take advantage of OOB must query the receive 
> > > > > > > buffer
> > > > > > > size and make sure to leave enough room.
> > > > > > 
> > > > > > I don't think having to query it ahead of time is particularly nice,
> > > > > > and of course it is inherantly racy.
> > > > > > 
> > > > > > I would just have QEMU emit an event when it pausing processing of 
> > > > > > the
> > > > > > incoming commands due to a full queue.  If the event includes the ID
> > > > > > of the last queued command, the client will know which (if any) of
> > > > > > its outstanding commands are delayed. Another even can be sent when
> > > > > > it restarts reading.
> > > > > 
> > > > > Hmm and now we're implementing flow control!
> > > > > 
> > > > > a) What exactly is the current semantics/buffer sizes?
> > > > > b) When do clients send multiple QMP commands on one channel without
> > > > > waiting for the response to the previous command?
> > > > > c) Would one queue entry for each class of commands/channel work
> > > > >   (Where a class of commands is currently 'normal' and 'oob')
> > > > 
> > > > I do wonder if we need to worry about request limiting at all from the
> > > > client side.  For non-OOB commands clients will wait for a reply before
> > > > sending a 2nd non-OOB command, so you'll never get a deep queue for.
> > > > 
> > > > OOB commands are supposed to be things which can be handled quickly
> > > > without blocking, so even if a client sent several commands at once
> > > > without waiting for replies, they're going to be processed quickly,
> > > > so whether we temporarily block reading off the wire is a minor
> > > > detail.
> > > 
> > > Lets just define it so that it can't - you send an OO

Re: [Qemu-devel] [RFC 00/15] QMP: out-of-band (OOB) execution support

[Dr. David Alan Gilbert]

* Daniel P. Berrange (berra...@redhat.com) wrote:
> On Fri, Sep 15, 2017 at 01:19:56PM +0100, Dr. David Alan Gilbert wrote:
> > * Daniel P. Berrange (berra...@redhat.com) wrote:
> > > On Fri, Sep 15, 2017 at 01:06:44PM +0100, Dr. David Alan Gilbert wrote:
> > > > * Daniel P. Berrange (berra...@redhat.com) wrote:
> > > > > On Fri, Sep 15, 2017 at 11:49:26AM +0100, Stefan Hajnoczi wrote:
> > > > > > On Fri, Sep 15, 2017 at 11:50:57AM +0800, Peter Xu wrote:
> > > > > > > On Thu, Sep 14, 2017 at 04:19:11PM +0100, Stefan Hajnoczi wrote:
> > > > > > > > On Thu, Sep 14, 2017 at 01:15:09PM +0200, Marc-André Lureau 
> > > > > > > > wrote:
> > > > > > > > > There should be a limit in the number of requests the thread 
> > > > > > > > > can
> > > > > > > > > queue. Before the patch, the limit was enforced by system 
> > > > > > > > > socket
> > > > > > > > > buffering I think. Now, should oob commands still be 
> > > > > > > > > processed even if
> > > > > > > > > the queue is full? If so, the thread can't be suspended.
> > > > > > > > 
> > > > > > > > I agree.
> > > > > > > > 
> > > > > > > > Memory usage must be bounded.  The number of requests is less 
> > > > > > > > important
> > > > > > > > than the amount of memory consumed by them.
> > > > > > > > 
> > > > > > > > Existing QMP clients that send multiple QMP commands without 
> > > > > > > > waiting for
> > > > > > > > replies need to rethink their strategy because OOB commands 
> > > > > > > > cannot be
> > > > > > > > processed if queued non-OOB commands consume too much memory.
> > > > > > > 
> > > > > > > Thanks for pointing out this.  Yes the memory usage problem is 
> > > > > > > valid,
> > > > > > > as Markus pointed out as well in previous discussions (in "Flow
> > > > > > > Control" section of that long reply).  Hopefully this series 
> > > > > > > basically
> > > > > > > can work from design prospective, then I'll add this flow control 
> > > > > > > in
> > > > > > > next version.
> > > > > > > 
> > > > > > > Regarding to what we should do if the limit is reached: Markus
> > > > > > > provided a few options, but the one I prefer most is that we don't
> > > > > > > respond, but send an event showing that a command is dropped.
> > > > > > > However, I would like it not queued, but a direct reply (after 
> > > > > > > all,
> > > > > > > it's an event, and we should not need to care much on ordering of 
> > > > > > > it).
> > > > > > > Then we can get rid of the babysitting of those "to be failed"
> > > > > > > requests asap, meanwhile we don't lose anything IMHO.
> > > > > > > 
> > > > > > > I think I also missed at least a unit test for this new interface.
> > > > > > > Again, I'll add it after the whole idea is proved solid.  Thanks,
> > > > > > 
> > > > > > Another solution: the server reports available receive buffer space 
> > > > > > to
> > > > > > the client.  The server only guarantees immediate OOB processing 
> > > > > > when
> > > > > > the client stays within the receive buffer size.
> > > > > > 
> > > > > > Clients wishing to take advantage of OOB must query the receive 
> > > > > > buffer
> > > > > > size and make sure to leave enough room.
> > > > > 
> > > > > I don't think having to query it ahead of time is particularly nice,
> > > > > and of course it is inherantly racy.
> > > > > 
> > > > > I would just have QEMU emit an event when it pausing processing of the
> > > > > incoming commands due to a full queue.  If the event includes the ID
> > > > > of the last queued command, the client will know which (if any) of
> > > > > its outstanding commands are delayed. Another even can be sent when
> > > > > it restarts reading.
> > > > 
> > > > Hmm and now we're implementing flow control!
> > > > 
> > > > a) What exactly is the current semantics/buffer sizes?
> > > > b) When do clients send multiple QMP commands on one channel without
> > > > waiting for the response to the previous command?
> > > > c) Would one queue entry for each class of commands/channel work
> > > >   (Where a class of commands is currently 'normal' and 'oob')
> > > 
> > > I do wonder if we need to worry about request limiting at all from the
> > > client side.  For non-OOB commands clients will wait for a reply before
> > > sending a 2nd non-OOB command, so you'll never get a deep queue for.
> > > 
> > > OOB commands are supposed to be things which can be handled quickly
> > > without blocking, so even if a client sent several commands at once
> > > without waiting for replies, they're going to be processed quickly,
> > > so whether we temporarily block reading off the wire is a minor
> > > detail.
> > 
> > Lets just define it so that it can't - you send an OOB command and wait
> > for it's response before sending another on that channel.
> > 
> > > IOW, I think we could just have a fixed 10 command queue and apps just
> > > pretend that there's an infinite queue and nothing bad would happen from
> > > the app's POV.
> > 
> > Can you justify 10 as opposed to 1?
> 
> Sem

Re: [Qemu-devel] [PATCH v7 12/13] tests: Add README for vm tests

[Alex Bennée]

Fam Zheng  writes:

> Signed-off-by: Fam Zheng 
> ---
>  tests/vm/README | 63 
> +
>  1 file changed, 63 insertions(+)
>  create mode 100644 tests/vm/README
>
> diff --git a/tests/vm/README b/tests/vm/README
> new file mode 100644
> index 00..7d2fe4ac8d
> --- /dev/null
> +++ b/tests/vm/README
> @@ -0,0 +1,63 @@
> +=== VM test suite to run build in guests ===
> +
> +== Intro ==
> +
> +This test suite contains scripts that bootstrap various guest images that 
> have
> +necessary packages to build QEMU. The basic usage is documented in Makefile
> +help which is displayed with "make vm-test".
> +
> +== Quick start ==
> +
> +Run "make vm-test" to list available make targets.

Running make vm-build-netbsd I get several prompts for pass-phrase and
password:

Enter passphrase for key './vm-test-QdFtLJ.tmp/id_rsa':
Password for qemu@:
Enter passphrase for key './vm-test-QdFtLJ.tmp/id_rsa':
Password for qemu@:
ar: creating libfdt/libfdt.a

Which seems odd considering the private key isn't protected by a
passphrase and the build tools know what the password is.

We should also mention the images are added to ${QEMU_SRC}/tests/vm/

> +
> +== Manual invocation ==
> +
> +Each guest script is an executable script with the same command line options.
> +For example to work with the netbsd guest, use $QEMU_SRC/tests/vm/netbsd:
> +
> +$ cd $QEMU_SRC/tests/vm
> +
> +# To bootstrap the image
> +$ ./netbsd --build-image --image /var/tmp/netbsd.img
> +<...>
> +
> +# To run an arbitrary command in guest (the output will not be echoed 
> unless
> +# --debug is added)
> +$ ./netbsd --debug --image /var/tmp/netbsd.img uname -a
> +
> +# To build QEMU in guest
> +$ ./netbsd --debug --image /var/tmp/netbsd.img --build-qemu $QEMU_SRC
> +
> +# To get to an interactive shell
> +$ ./netbsd --interactive --image /var/tmp/netbsd.img sh
> +
> +== Adding new guests ==
> +
> +Please look at existing guest scripts for how to add new guests.
> +
> +Most importantly, create a subclass of BaseVM and implement build_image()
> +method and define BUILD_SCRIPT, then finally call basevm.main() from the
> +script's main().
> +
> +  - Usually in build_image(), a template image is downloaded from a 
> predefined
> +URL. BaseVM._download_with_cache() takes care of the cache and the
> +checksum, so consider using it.
> +
> +  - Once the image is downloaded, users, SSH server and QEMU build deps 
> should
> +be set up:
> +
> +* Root password set to BaseVM.ROOT_PASS
> +* User BaseVM.GUEST_USER is created, and password set to 
> BaseVM.GUEST_PASS
> +* SSH service is enabled and started on boot, BaseVM.SSH_PUB_KEY is added
> +  to authorized_keys of both root and the normal user
> +* DHCP client service is enabled and started on boot, so that it can
> +  automatically configure the virtio-net-pci NIC and communicate with 
> QEMU
> +  user net (10.0.2.2)
> +* Necessary packages are installed to untar the source tarball and build
> +  QEMU
> +
> +  - Write a proper BUILD_SCRIPT template, which should be a shell script that
> +untars a raw virtio-blk block device, which is the tarball data blob of 
> the
> +QEMU source tree, then configure/build it. Running "make check" is also
> +recommended.
> +


--
Alex Bennée

Re: [Qemu-devel] [PATCH RFC 1/1] s390x/ccw: create s390 phb for compat reasons as well

[Halil Pasic]

On 09/15/2017 03:37 PM, David Hildenbrand wrote:
> On 15.09.2017 15:22, Cornelia Huck wrote:
>> On Fri, 15 Sep 2017 15:09:02 +0200
>> David Hildenbrand  wrote:
>>
>>> On 15.09.2017 15:07, Cornelia Huck wrote:
 On Fri, 15 Sep 2017 13:57:40 +0200
 David Hildenbrand  wrote:
   
> As an alternative, simply
>
> diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c
> index 0f28ebd162..0f22efc3b6 100644
> --- a/target/s390x/cpu_models.c
> +++ b/target/s390x/cpu_models.c
> @@ -195,6 +195,8 @@ bool s390_has_feat(S390Feat feat)
>  return true;
>  }
>  }
> +if (feat == S390_FEAT_ZPCI)
> +return true;  

 Move that out of the CONFIG_KVM #ifdef?
   
>>>
>>> Should not make a difference I think, cpu models are not shielded off
>>> for TCG I think (maybe we should fix that, but doesn't look that easy -
>>> they have no host model which would allow cpu->model = NULL).
>>
>> It just looks odd to have it inside the define...
> 
> sure, you can then also just move it into kvm_enable() next to the other
> ones.
> 
>>
>>>
 (Also, we still have the issue with pci support :/ - depend on
 pci_available?)  
>>>
>>> hm 
>>
>> Should we maybe disallow compat machines if CONFIG_PCI is off, and
>> think about something for the 2.11 machine? Otherwise, I cannot see
>> that end well :/
> 
> If they required PCI, than that is the only way to do it.
> 
>>
>> But I'll just draw up a v2 for now.
>>

Sorry for not contributing anything here. I don't have the whole
thing in my head, so I can't quite follow without digging into this.

I don't think I will be able to join today -- maybe I could have a
look next week .

Halil 

> 
> 

Re: [Qemu-devel] [PATCH 1/2] x86_iommu: Move machine check to x86_iommu_realize()

[Peter Xu]

On Fri, Sep 15, 2017 at 09:52:23PM +0800, Peter Xu wrote:
> On Fri, Sep 15, 2017 at 01:13:45PM +0200, Mohammed Gamal wrote:
> > Instead of having the same error checks in vtd_realize()
> > and amdvi_realize(), move that over to the generic
> > x86_iommu_realize().
> > 
> > Signed-off-by: Mohammed Gamal 
> > ---
> >  hw/i386/amd_iommu.c   | 10 +-
> >  hw/i386/intel_iommu.c | 10 +-
> >  hw/i386/x86-iommu.c   | 13 +
> >  3 files changed, 15 insertions(+), 18 deletions(-)
> > 
> > diff --git a/hw/i386/amd_iommu.c b/hw/i386/amd_iommu.c
> > index 334938a..839f01f 100644
> > --- a/hw/i386/amd_iommu.c
> > +++ b/hw/i386/amd_iommu.c
> > @@ -1141,18 +1141,10 @@ static void amdvi_realize(DeviceState *dev, Error 
> > **err)
> >  AMDVIState *s = AMD_IOMMU_DEVICE(dev);
> >  X86IOMMUState *x86_iommu = X86_IOMMU_DEVICE(dev);
> >  MachineState *ms = MACHINE(qdev_get_machine());
> > -MachineClass *mc = MACHINE_GET_CLASS(ms);
> >  PCMachineState *pcms =
> >  PC_MACHINE(object_dynamic_cast(OBJECT(ms), TYPE_PC_MACHINE));
> > -PCIBus *bus;
> > +PCIBus *bus = pcms->bus;
> >  
> > -if (!pcms) {
> > -error_setg(err, "Machine-type '%s' not supported by amd-iommu",
> > -   mc->name);
> > -return;
> > -}
> > -
> > -bus = pcms->bus;
> >  s->iotlb = g_hash_table_new_full(amdvi_uint64_hash,
> >   amdvi_uint64_equal, g_free, g_free);
> >  
> > diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
> > index 3a5bb0b..aa01812 100644
> > --- a/hw/i386/intel_iommu.c
> > +++ b/hw/i386/intel_iommu.c
> > @@ -3027,20 +3027,12 @@ static bool vtd_decide_config(IntelIOMMUState *s, 
> > Error **errp)
> >  static void vtd_realize(DeviceState *dev, Error **errp)
> >  {
> >  MachineState *ms = MACHINE(qdev_get_machine());
> > -MachineClass *mc = MACHINE_GET_CLASS(ms);
> >  PCMachineState *pcms =
> >  PC_MACHINE(object_dynamic_cast(OBJECT(ms), TYPE_PC_MACHINE));
> > -PCIBus *bus;
> > +PCIBus *bus = pcms->bus;
> >  IntelIOMMUState *s = INTEL_IOMMU_DEVICE(dev);
> >  X86IOMMUState *x86_iommu = X86_IOMMU_DEVICE(dev);
> >  
> > -if (!pcms) {
> > -error_setg(errp, "Machine-type '%s' not supported by intel-iommu",
> > -   mc->name);
> > -return;
> > -}
> > -
> > -bus = pcms->bus;
> >  x86_iommu->type = TYPE_INTEL;
> >  
> >  if (!vtd_decide_config(s, errp)) {
> > diff --git a/hw/i386/x86-iommu.c b/hw/i386/x86-iommu.c
> > index 293caf8..4d17e1f 100644
> > --- a/hw/i386/x86-iommu.c
> > +++ b/hw/i386/x86-iommu.c
> > @@ -21,6 +21,8 @@
> >  #include "hw/sysbus.h"
> >  #include "hw/boards.h"
> >  #include "hw/i386/x86-iommu.h"
> > +#include "hw/i386/pc.h"
> > +#include "qapi/error.h"
> >  #include "qemu/error-report.h"
> >  #include "trace.h"
> >  
> > @@ -80,7 +82,18 @@ static void x86_iommu_realize(DeviceState *dev, Error 
> > **errp)
> >  {
> >  X86IOMMUState *x86_iommu = X86_IOMMU_DEVICE(dev);
> >  X86IOMMUClass *x86_class = X86_IOMMU_GET_CLASS(dev);
> > +MachineState *ms = MACHINE(qdev_get_machine());
> > +MachineClass *mc = MACHINE_GET_CLASS(ms);
> > +PCMachineState *pcms =
> > +PC_MACHINE(object_dynamic_cast(OBJECT(ms), TYPE_PC_MACHINE));
> >  QLIST_INIT(&x86_iommu->iec_notifiers);
> > +
> > +if (!pcms) {
> > +error_setg(errp, "Machine-type '%s' not supported by iommu",
> 
> When moving it, maybe also fix the English? :)
> 
>   "Machine-type '%s' does not support IOMMU."

I was wrong.  I changed the correct thing into error.  E.g., ppc64
obviously supports IOMMU... Please ignore my comment and just pick my
r-b.  Sorry for the noise.

> 
> Otherwise:
> 
> Reviewed-by: Peter Xu 
> 
> Thanks,
> 
> > +   mc->name);
> > +return;
> > +}
> > +
> >  if (x86_class->realize) {
> >  x86_class->realize(dev, errp);
> >  }
> > -- 
> > 1.8.3.1
> > 
> 
> -- 
> Peter Xu

-- 
Peter Xu

Re: [Qemu-devel] [PATCH 2/2] x86_iommu: check if machine has PCI bus

[Peter Xu]

On Fri, Sep 15, 2017 at 01:13:46PM +0200, Mohammed Gamal wrote:
> Starting qemu with
> qemu-system-x86_64 -S -M isapc -device {amd|intel}-iommu
> leads to a segfault. The code assume PCI bus is present and
> tries to access the bus structure without checking.
> 
> Since Intel VT-d and AMDVI should only work with PCI, add a
> check for PCI bus and return error if not present.
> 
> Signed-off-by: Mohammed Gamal 

Reviewed-by: Peter Xu 

> ---
>  hw/i386/x86-iommu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/hw/i386/x86-iommu.c b/hw/i386/x86-iommu.c
> index 4d17e1f..afd8cd9 100644
> --- a/hw/i386/x86-iommu.c
> +++ b/hw/i386/x86-iommu.c
> @@ -88,7 +88,7 @@ static void x86_iommu_realize(DeviceState *dev, Error 
> **errp)
>  PC_MACHINE(object_dynamic_cast(OBJECT(ms), TYPE_PC_MACHINE));
>  QLIST_INIT(&x86_iommu->iec_notifiers);
>  
> -if (!pcms) {
> +if (!pcms || !pcms->bus) {
>  error_setg(errp, "Machine-type '%s' not supported by iommu",
> mc->name);
>  return;
> -- 
> 1.8.3.1
> 

-- 
Peter Xu

Re: [Qemu-devel] [PATCH 1/2] x86_iommu: Move machine check to x86_iommu_realize()

[Peter Xu]

On Fri, Sep 15, 2017 at 01:13:45PM +0200, Mohammed Gamal wrote:
> Instead of having the same error checks in vtd_realize()
> and amdvi_realize(), move that over to the generic
> x86_iommu_realize().
> 
> Signed-off-by: Mohammed Gamal 
> ---
>  hw/i386/amd_iommu.c   | 10 +-
>  hw/i386/intel_iommu.c | 10 +-
>  hw/i386/x86-iommu.c   | 13 +
>  3 files changed, 15 insertions(+), 18 deletions(-)
> 
> diff --git a/hw/i386/amd_iommu.c b/hw/i386/amd_iommu.c
> index 334938a..839f01f 100644
> --- a/hw/i386/amd_iommu.c
> +++ b/hw/i386/amd_iommu.c
> @@ -1141,18 +1141,10 @@ static void amdvi_realize(DeviceState *dev, Error 
> **err)
>  AMDVIState *s = AMD_IOMMU_DEVICE(dev);
>  X86IOMMUState *x86_iommu = X86_IOMMU_DEVICE(dev);
>  MachineState *ms = MACHINE(qdev_get_machine());
> -MachineClass *mc = MACHINE_GET_CLASS(ms);
>  PCMachineState *pcms =
>  PC_MACHINE(object_dynamic_cast(OBJECT(ms), TYPE_PC_MACHINE));
> -PCIBus *bus;
> +PCIBus *bus = pcms->bus;
>  
> -if (!pcms) {
> -error_setg(err, "Machine-type '%s' not supported by amd-iommu",
> -   mc->name);
> -return;
> -}
> -
> -bus = pcms->bus;
>  s->iotlb = g_hash_table_new_full(amdvi_uint64_hash,
>   amdvi_uint64_equal, g_free, g_free);
>  
> diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
> index 3a5bb0b..aa01812 100644
> --- a/hw/i386/intel_iommu.c
> +++ b/hw/i386/intel_iommu.c
> @@ -3027,20 +3027,12 @@ static bool vtd_decide_config(IntelIOMMUState *s, 
> Error **errp)
>  static void vtd_realize(DeviceState *dev, Error **errp)
>  {
>  MachineState *ms = MACHINE(qdev_get_machine());
> -MachineClass *mc = MACHINE_GET_CLASS(ms);
>  PCMachineState *pcms =
>  PC_MACHINE(object_dynamic_cast(OBJECT(ms), TYPE_PC_MACHINE));
> -PCIBus *bus;
> +PCIBus *bus = pcms->bus;
>  IntelIOMMUState *s = INTEL_IOMMU_DEVICE(dev);
>  X86IOMMUState *x86_iommu = X86_IOMMU_DEVICE(dev);
>  
> -if (!pcms) {
> -error_setg(errp, "Machine-type '%s' not supported by intel-iommu",
> -   mc->name);
> -return;
> -}
> -
> -bus = pcms->bus;
>  x86_iommu->type = TYPE_INTEL;
>  
>  if (!vtd_decide_config(s, errp)) {
> diff --git a/hw/i386/x86-iommu.c b/hw/i386/x86-iommu.c
> index 293caf8..4d17e1f 100644
> --- a/hw/i386/x86-iommu.c
> +++ b/hw/i386/x86-iommu.c
> @@ -21,6 +21,8 @@
>  #include "hw/sysbus.h"
>  #include "hw/boards.h"
>  #include "hw/i386/x86-iommu.h"
> +#include "hw/i386/pc.h"
> +#include "qapi/error.h"
>  #include "qemu/error-report.h"
>  #include "trace.h"
>  
> @@ -80,7 +82,18 @@ static void x86_iommu_realize(DeviceState *dev, Error 
> **errp)
>  {
>  X86IOMMUState *x86_iommu = X86_IOMMU_DEVICE(dev);
>  X86IOMMUClass *x86_class = X86_IOMMU_GET_CLASS(dev);
> +MachineState *ms = MACHINE(qdev_get_machine());
> +MachineClass *mc = MACHINE_GET_CLASS(ms);
> +PCMachineState *pcms =
> +PC_MACHINE(object_dynamic_cast(OBJECT(ms), TYPE_PC_MACHINE));
>  QLIST_INIT(&x86_iommu->iec_notifiers);
> +
> +if (!pcms) {
> +error_setg(errp, "Machine-type '%s' not supported by iommu",

When moving it, maybe also fix the English? :)

  "Machine-type '%s' does not support IOMMU."

Otherwise:

Reviewed-by: Peter Xu 

Thanks,

> +   mc->name);
> +return;
> +}
> +
>  if (x86_class->realize) {
>  x86_class->realize(dev, errp);
>  }
> -- 
> 1.8.3.1
> 

-- 
Peter Xu

Re: [Qemu-devel] [PATCH v5 00/22] instrument: Add basic event instrumentation

[Peter Maydell]

On 15 September 2017 at 14:45, Lluís Vilanova  wrote:
> Do you have an opinion on specific trace points, or an observation in general?
>
> I wanted to have the following events:
>
> * cpu hotplug/hotunplug
> * cpu reset
> * memory access translation/execution
> * BBL/TB translation/execution
> * instruction translation/execution
> * exceptions / syscalls

My initial stab at a "basic" set of events would be:
 * instruction executes
 * memory accesses
 * exceptions

But the better approach would probably be to survey the
existing trace APIs in other models.

thanks
-- PMM

Re: [Qemu-devel] [PATCH v5 00/22] instrument: Add basic event instrumentation

[Lluís Vilanova]

Peter Maydell writes:

> On 12 September 2017 at 22:01, Lluís Vilanova  wrote:
>> This series adds an API to add instrumentation events.
>> 
>> It also provides additional APIs for:
>> * Controlling tracing events.
>> * Peek/poke guest memory.

>> Future APIs (for later series):
>> * Peek/poke guest registers.
>> * Add breakpoints to trigger instrumentation functions.
>> * Trigger instrumentation functions from guest code (former hypertrace).
>> * Add events for guest code translation/execution (once the respective 
>> tracing
>> events are accepted upstream).
>> * Add events for exceptions/syscalls.
>> * Add events for TB invalidation (necessary for libraries to deallocate any 
>> data
>> they might have allocated for the TBs they instrumented).
>> 
>> The instrumentation code is dynamically loaded as a library into QEMU either
>> when it starts or later using its remote control interfaces. The loaded code
>> only has access to function explicitly exported through the QI_VPUBLIC macro.
>> 
>> This series is branch 'devel-instrument' in
>> https://code.gso.ac.upc.edu/git/qemu-dbi.

> To parallel the comment I sent on Emilio's series: I think the
> first thing we should do here is work out the API we want to
> present to the instrumentation plugin, because that's permanent
> and we want to get it right. Then we can figure out the
> implementation details later.

> Particular notes:
>  * putting things in the instrumentation plugin API that basically
>parallel some existing trace points is something I'm wary of,
>because a lot of our existing tracing is "output something at
>a point and in a way that's convenient for our internal
>implementation", rather than "what is the right clean interface
>to provide this sort of information". I'd rather we started
>with a blank piece of paper and designed an API, and then
>implemented it.

Do you have an opinion on specific trace points, or an observation in general?

I wanted to have the following events:

* cpu hotplug/hotunplug
* cpu reset
* memory access translation/execution
* BBL/TB translation/execution
* instruction translation/execution
* exceptions / syscalls


>  * I definitely don't think we should expose to the instrumentation
>the distinction between translate time and execute time

Please see my response to your email in v6.

Also, I forgot an even simpler case, like instrumenting a subset of memory
accesses (e.g., only writes).


Thanks,
  Lluis

Re: [Qemu-devel] [PATCH v6 01/22] instrument: Add documentation

[Lluís Vilanova]

Peter Maydell writes:

> On 13 September 2017 at 10:57, Lluís Vilanova  wrote:
>> Signed-off-by: Lluís Vilanova 
>> ---
>> MAINTAINERS |6 ++
>> docs/instrument.txt |  173 
>> +++
>> 2 files changed, 179 insertions(+)
>> create mode 100644 docs/instrument.txt
>> 
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 36eeb42d19..fb0eaee06a 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -1486,6 +1486,12 @@ F: scripts/tracetool/
>> F: docs/tracing.txt
>> T: git git://github.com/stefanha/qemu.git tracing
>> 
>> +Event instrumentation
>> +M: Lluís Vilanova 
>> +M: Stefan Hajnoczi 
>> +S: Maintained
>> +F: docs/instrument.txt
>> +
>> TPM
>> S: Orphan
>> F: tpm.c
>> diff --git a/docs/instrument.txt b/docs/instrument.txt
>> new file mode 100644
>> index 00..24a0d21fc7
>> --- /dev/null
>> +++ b/docs/instrument.txt
>> @@ -0,0 +1,173 @@
>> += Event instrumentation =
>> +
>> +== Introduction ==
>> +
>> +Event instrumentation allows users to execute their own host-native code on 
>> a
>> +set of pre-defined events provided by QEMU. QEMU also exposes other
>> +functionality to peek/poke at the guest state (e.g., memory or registers), 
>> as
>> +well as interacting with tracing events. For those familiar with the term, 
>> this
>> +provides dynamic binary instrumentation, works on all QEMU-supported
>> +architectures, as well as works in both 'user' (standalone application) and
>> +'system' (full-system emulation) modes.
>> +
>> +Look at the headers installed by QEMU on the "qemu-instr" directory for 
>> further
>> +information beyond this document.
>> +
>> +
>> +== Loading an instrumentation library ==
>> +
>> +Instrumentation code can be bundled into a dynamic library, which can be 
>> later
>> +loaded into QEMU:
>> +
>> +* Using the command-line "-instr" argument.
>> +
>> +* Using the "instr-load" and "instr-unload" commands in the HMP and QMP
>> +  interfaces.
>> +
>> +
>> +== Example ==
>> +
>> +1. Configure QEMU with event instrumentation:
>> +
>> +# instrument guest_cpu_enter and guest_mem_before
>> +mkdir -p /path/to/qemu-build
>> +cd /path/to/qemu-build
>> +/path/to/qemu-source/configure \
>> +  --enable-instrument \
>> +  --prefix=/path/to/qemu-install

> Ideally instrumentation should be cost-free in the case where
> we're not using it, so we can default it to enabled.

I wasn't sure if everyone would want it enabled by default on the first release,
but I can easily change that.


>> +
>> +2. Build and install QEMU:
>> +
>> +make install
>> +
>> +3. Create the "Makefile" to build the instrumentation library:
>> +
>> +mkdir -p /tmp/my-instrument
>> +
>> +cat > /tmp/my-instrument/Makefile <> +QEMU_PATH=/tmp/qemu-install/
>> +
>> +CFLAGS += -g
>> +CFLAGS += -O3
>> +CFLAGS += -Werror -Wall
>> +CFLAGS += -I$(QEMU_PATH)/include

> Plugins shouldn't have or need access to all of the QEMU source
> tree or its include files. We want to be able to provide them
> with one header file which defines all they need (and all they
> get), under a suitably non-restrictive license like 2-clause-BSD.

Variable QEMU_PATH refers to the *installation* path of QEMU.

I can change the API headers to use some other license.


>> +
>> +all: libtrace-instrument.la
>> +
>> +libtrace-instrument.la: instrument.lo
>> +libtool --mode=link --tag=CC $(CC) -module -rpath 
>> /usr/local/lib -o $@ $^

> -rpath ?

I couldn't make libtool to generate a .so file without it. I can change the
example to directly use gcc instead of libtool.


>> +
>> +%.lo: %.c
>> +libtool --mode=compile --tag=CC $(CC) $(CFLAGS) -c $^
>> +
>> +clean:
>> +$(RM) -f *.o *.so *.lo
>> +$(RM) -Rf .libs
>> +EOF
>> +
>> +4. Write your instrumentation library:
>> +
>> +cat > /tmp/my-instrument/instrument.c <> +#include 
>> +#include 
>> +
>> +#include  /* manipulate events */
>> +#include/* manipulate tracing */
>> +
>> +/* the address for the memory access is not known at translation time */
>> +void guest_mem_before_trans(QICPU vcpu_trans, QITCGv_cpu vcpu_exec,
>> +QITCGv vaddr, QIMemInfo info)
>> +{
>> +printf("%s: %p %p %p %d %d %d %d\n", __func__, vcpu_trans, 
>> vcpu_exec, vaddr,
>> +   1 << info.size_shift, info.sign_extend, info.endianness, 
>> info.store);
>> +if (info.store) {
>> +/* generate at execution time only for memory writes */
>> +qi_event_gen_guest_mem_before_exec(vcpu_exec, vaddr, info);
>> +}
>> +}
>> +
>> +/* called when QEMU executes a memory access */
>> +void guest_mem_before_exec(QICPU vcpu, uint64_t vaddr, QIMemInfo info)
>> +{
>> +if (info.store) {
>> +/* if called by TCG code, we'll only get writes (see above) */
>> +printf("%s: %p %lx %d %d %d %d\n", __func__, vcpu, v

Re: [Qemu-devel] [PATCH RFC 1/1] s390x/ccw: create s390 phb for compat reasons as well

[David Hildenbrand]

On 15.09.2017 15:22, Cornelia Huck wrote:
> On Fri, 15 Sep 2017 15:09:02 +0200
> David Hildenbrand  wrote:
> 
>> On 15.09.2017 15:07, Cornelia Huck wrote:
>>> On Fri, 15 Sep 2017 13:57:40 +0200
>>> David Hildenbrand  wrote:
>>>   
 As an alternative, simply

 diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c
 index 0f28ebd162..0f22efc3b6 100644
 --- a/target/s390x/cpu_models.c
 +++ b/target/s390x/cpu_models.c
 @@ -195,6 +195,8 @@ bool s390_has_feat(S390Feat feat)
  return true;
  }
  }
 +if (feat == S390_FEAT_ZPCI)
 +return true;  
>>>
>>> Move that out of the CONFIG_KVM #ifdef?
>>>   
>>
>> Should not make a difference I think, cpu models are not shielded off
>> for TCG I think (maybe we should fix that, but doesn't look that easy -
>> they have no host model which would allow cpu->model = NULL).
> 
> It just looks odd to have it inside the define...

sure, you can then also just move it into kvm_enable() next to the other
ones.

> 
>>
>>> (Also, we still have the issue with pci support :/ - depend on
>>> pci_available?)  
>>
>> hm 
> 
> Should we maybe disallow compat machines if CONFIG_PCI is off, and
> think about something for the 2.11 machine? Otherwise, I cannot see
> that end well :/

If they required PCI, than that is the only way to do it.

> 
> But I'll just draw up a v2 for now.
> 


-- 

Thanks,

David

Re: [Qemu-devel] [PATCH v5 11/22] s390x: allow only 1 CPU with TCG

[David Hildenbrand]

On 15.09.2017 15:17, Alex Bennée wrote:
> 
> David Hildenbrand  writes:
> 
>> On 13.09.2017 18:13, Alex Bennée wrote:
>>>
>>> David Hildenbrand  writes:
>>>
 Specifying more than 1 CPU (e.g. -smp 5) leads to SIGP errors (the
 guest tries to bring these CPUs up but fails), because we don't support
 multiple CPUs on s390x under TCG.

 Let's bail out if more than 1 is specified, so we don't raise people's
 hope.
>>>
>>> Why does this restriction exist? Without MTTCG enabled -smp > 1 should
>>> be safe from any races.
>>
>> Because the actual SIGP code (instruction to start/stop ... CPUs) is not
>> implemented yet.
> 
> Ahh OK, I assume something like ARM's PCSI interface then.
> 
> When you do get around to implementing just ensure you use the async
> mechanism to initialise the target processor state to avoid races in
> MTTCG. Essentially you queue the work up on the target and then it is
> run before the powered up vCPU starts running code.

One step at a time, right now I only test with single threaded. MTTCG is
the next step. But I have a good feeling about mttcg, at least speaking
about the SIGP implementation (for the "critical" stuff - start, stop,
initialize - I reuse the KVM code which uses even sync work).

> 
> --
> Alex Bennée
> 


-- 

Thanks,

David

Re: [Qemu-devel] [Qemu-arm] [PATCH v7 13/20] hw/arm/smmuv3: Implement IOMMU memory region replay callback

[Auger Eric]

Hi Tomasz,
On 15/09/2017 12:42, tn wrote:
> Hi Eric,
> 
> On 15.09.2017 09:30, Auger Eric wrote:
>> Hi Tomasz,
>>
>> On 14/09/2017 16:43, Tomasz Nowicki wrote:
>>> On 14.09.2017 16:31, Tomasz Nowicki wrote:
 Hi Eric,

 On 14.09.2017 11:27, Linu Cherian wrote:
> Hi Eric,
>
> On Fri Sep 01, 2017 at 07:21:16PM +0200, Eric Auger wrote:
>> memory_region_iommu_replay() is used for VFIO integration.
>>
>> However its default implementation is not adapted to SMMUv3
>> IOMMU memory region. Indeed the input address range is too
>> huge and its execution is too slow as it calls the translate()
>> callback on each granule.
>>
>> Let's implement the replay callback which hierarchically walk
>> over the page table structure and notify only the segments
>> that are populated with valid entries.
>>
>> Signed-off-by: Eric Auger 
>> ---
>>hw/arm/smmuv3.c | 36 
>>hw/arm/trace-events |  1 +
>>2 files changed, 37 insertions(+)
>>
>> diff --git a/hw/arm/smmuv3.c b/hw/arm/smmuv3.c
>> index 8e7d10d..c43bd93 100644
>> --- a/hw/arm/smmuv3.c
>> +++ b/hw/arm/smmuv3.c
>> @@ -657,6 +657,41 @@ static int smmuv3_notify_entry(IOMMUTLBEntry
>> *entry, void *private)
>>return 0;
>>}
>> +/* Unmap the whole notifier's range */
>> +static void smmuv3_unmap_notifier_range(IOMMUNotifier *n)
>> +{
>> +IOMMUTLBEntry entry;
>> +hwaddr size = n->end - n->start + 1;
>> +
>> +entry.target_as = &address_space_memory;
>> +entry.iova = n->start & ~(size - 1);
>> +entry.perm = IOMMU_NONE;
>> +entry.addr_mask = size - 1;
>> +
>> +memory_region_notify_one(n, &entry);
>> +}
>> +
>> +static void smmuv3_replay(IOMMUMemoryRegion *mr, IOMMUNotifier *n)
>> +{
>> +SMMUTransCfg cfg = {};
>> +int ret;
>> +
>> +trace_smmuv3_replay(mr->parent_obj.name, n, n->start, n->end);
>> +smmuv3_unmap_notifier_range(n);
>> +
>> +ret = smmuv3_decode_config(mr, &cfg);
>> +if (ret) {
>> +error_report("%s error decoding the configuration for iommu
>> mr=%s",
>> + __func__, mr->parent_obj.name);
>> +}
>>
>
> On an invalid config being found, shouldnt we return rather than
> proceeding with
> page table walk. For example on an invalid Stream table entry.

 Indeed, without return here vhost case is not working for me.
>>>
>>> I was just lucky one time. return here has no influence. Vhost still not
>>> working. Sorry for noise.
>>
>> As far as I understand the replay() callback only is called in VFIO use
>> case. So this shouldn't impact vhost.
>>
>> I can't reproduce your vhost issue on my side. I will review the
>> invalidate code again and compare against the last version.
>>
>> What is the page size used by your guest?
> 
> 64K page size for guest as well as for host.
> 
> However, I've just checked 4K page size for guest and then vhost is
> working fine.
I can reproduce the issue with vhost on 64KB page guest. Currently
investigating...

Thanks!

Eric
> 
> Thanks,
> Tomasz

Re: [Qemu-devel] [PATCH RFC 1/1] s390x/ccw: create s390 phb for compat reasons as well

[Cornelia Huck]

On Fri, 15 Sep 2017 15:09:02 +0200
David Hildenbrand  wrote:

> On 15.09.2017 15:07, Cornelia Huck wrote:
> > On Fri, 15 Sep 2017 13:57:40 +0200
> > David Hildenbrand  wrote:
> >   
> >> As an alternative, simply
> >>
> >> diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c
> >> index 0f28ebd162..0f22efc3b6 100644
> >> --- a/target/s390x/cpu_models.c
> >> +++ b/target/s390x/cpu_models.c
> >> @@ -195,6 +195,8 @@ bool s390_has_feat(S390Feat feat)
> >>  return true;
> >>  }
> >>  }
> >> +if (feat == S390_FEAT_ZPCI)
> >> +return true;  
> > 
> > Move that out of the CONFIG_KVM #ifdef?
> >   
> 
> Should not make a difference I think, cpu models are not shielded off
> for TCG I think (maybe we should fix that, but doesn't look that easy -
> they have no host model which would allow cpu->model = NULL).

It just looks odd to have it inside the define...

> 
> > (Also, we still have the issue with pci support :/ - depend on
> > pci_available?)  
> 
> hm 

Should we maybe disallow compat machines if CONFIG_PCI is off, and
think about something for the 2.11 machine? Otherwise, I cannot see
that end well :/

But I'll just draw up a v2 for now.

Re: [Qemu-devel] [PATCH 1/4] ppc/kvm: drop kvmppc_has_cap_htab_fd()

[Thomas Huth]

On 15.09.2017 15:15, Greg Kurz wrote:
> It never got used since its introduction (commit 7c43bca004af).
> 
> Signed-off-by: Greg Kurz 
> ---
>  target/ppc/kvm.c |5 -
>  target/ppc/kvm_ppc.h |6 --
>  2 files changed, 11 deletions(-)
> 
> diff --git a/target/ppc/kvm.c b/target/ppc/kvm.c
> index 1deaf106d2b9..00d7029b8d7a 100644
> --- a/target/ppc/kvm.c
> +++ b/target/ppc/kvm.c
> @@ -2448,11 +2448,6 @@ bool kvmppc_has_cap_epr(void)
>  return cap_epr;
>  }
>  
> -bool kvmppc_has_cap_htab_fd(void)
> -{
> -return cap_htab_fd;
> -}
> -
>  bool kvmppc_has_cap_fixup_hcalls(void)
>  {
>  return cap_fixup_hcalls;
> diff --git a/target/ppc/kvm_ppc.h b/target/ppc/kvm_ppc.h
> index f780e6ec7b72..08aab46c5a56 100644
> --- a/target/ppc/kvm_ppc.h
> +++ b/target/ppc/kvm_ppc.h
> @@ -51,7 +51,6 @@ uint64_t kvmppc_rma_size(uint64_t current_size, unsigned 
> int hash_shift);
>  #endif /* !CONFIG_USER_ONLY */
>  bool kvmppc_has_cap_epr(void);
>  int kvmppc_define_rtas_kernel_token(uint32_t token, const char *function);
> -bool kvmppc_has_cap_htab_fd(void);
>  int kvmppc_get_htab_fd(bool write);
>  int kvmppc_save_htab(QEMUFile *f, int fd, size_t bufsize, int64_t max_ns);
>  int kvmppc_load_htab_chunk(QEMUFile *f, int fd, uint32_t index,
> @@ -246,11 +245,6 @@ static inline int 
> kvmppc_define_rtas_kernel_token(uint32_t token,
>  return -1;
>  }
>  
> -static inline bool kvmppc_has_cap_htab_fd(void)
> -{
> -return false;
> -}
> -
>  static inline int kvmppc_get_htab_fd(bool write)
>  {
>  return -1;
> 

Reviewed-by: Thomas Huth 

Re: [Qemu-devel] [PATCH v5 11/22] s390x: allow only 1 CPU with TCG

[Alex Bennée]

David Hildenbrand  writes:

> On 13.09.2017 18:13, Alex Bennée wrote:
>>
>> David Hildenbrand  writes:
>>
>>> Specifying more than 1 CPU (e.g. -smp 5) leads to SIGP errors (the
>>> guest tries to bring these CPUs up but fails), because we don't support
>>> multiple CPUs on s390x under TCG.
>>>
>>> Let's bail out if more than 1 is specified, so we don't raise people's
>>> hope.
>>
>> Why does this restriction exist? Without MTTCG enabled -smp > 1 should
>> be safe from any races.
>
> Because the actual SIGP code (instruction to start/stop ... CPUs) is not
> implemented yet.

Ahh OK, I assume something like ARM's PCSI interface then.

When you do get around to implementing just ensure you use the async
mechanism to initialise the target processor state to avoid races in
MTTCG. Essentially you queue the work up on the target and then it is
run before the powered up vCPU starts running code.

--
Alex Bennée

[Qemu-devel] [PATCH 4/4] ppc/kvm: generalize the use of kvmppc_get_htab_fd()

[Greg Kurz]

The use of KVM_PPC_GET_HTAB_FD is open-coded in kvmppc_read_hptes()
and kvmppc_write_hpte().

This patch modifies kvmppc_get_htab_fd() so that it can be used
everywhere we need to access the in-kernel htab:
- add an index argument
  => only kvmppc_read_hptes() passes an actual index, all other users
 pass 0
- add an errp argument to propagate error messages to the caller.
  => spapr migration code prints the error
  => hpte helpers pass &error_abort to keep the current behavior
 of hw_error()

While here, this also fixes a bug in kvmppc_write_hpte() so that it
opens the htab fd for writing instead of reading as it currently does.
This never broke anything because we currently never call this code,
as explained in the changelog of commit c1385933804bb:

"This support updating htab managed by the hypervisor. Currently
 we don't have any user for this feature. This actually bring the
 store_hpte interface in-line with the load_hpte one. We may want
 to use this when we want to emulate henter hcall in qemu for HV
 kvm."

The above is still true today.

Signed-off-by: Greg Kurz 
---
 hw/ppc/spapr.c   |   15 +++
 target/ppc/kvm.c |   27 +--
 target/ppc/kvm_ppc.h |4 ++--
 3 files changed, 18 insertions(+), 28 deletions(-)

diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 1ae79326d1ac..eeef549fbc15 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -1211,14 +1211,15 @@ static uint64_t spapr_get_patbe(PPCVirtualHypervisor 
*vhyp)
  */
 static int get_htab_fd(sPAPRMachineState *spapr)
 {
+Error *local_err = NULL;
+
 if (spapr->htab_fd >= 0) {
 return spapr->htab_fd;
 }
 
-spapr->htab_fd = kvmppc_get_htab_fd(false);
+spapr->htab_fd = kvmppc_get_htab_fd(false, 0, &local_err);
 if (spapr->htab_fd < 0) {
-error_report("Unable to open fd for reading hash table from KVM: %s",
- strerror(spapr->htab_fd));
+error_report_err(local_err);
 }
 
 return spapr->htab_fd;
@@ -1931,6 +1932,7 @@ static int htab_load(QEMUFile *f, void *opaque, int 
version_id)
 sPAPRMachineState *spapr = opaque;
 uint32_t section_hdr;
 int fd = -1;
+Error *local_err = NULL;
 
 if (version_id < 1 || version_id > 1) {
 error_report("htab_load() bad version");
@@ -1945,8 +1947,6 @@ static int htab_load(QEMUFile *f, void *opaque, int 
version_id)
 }
 
 if (section_hdr) {
-Error *local_err = NULL;
-
 /* First section gives the htab size */
 spapr_reallocate_hpt(spapr, section_hdr, &local_err);
 if (local_err) {
@@ -1959,10 +1959,9 @@ static int htab_load(QEMUFile *f, void *opaque, int 
version_id)
 if (!spapr->htab) {
 assert(kvm_enabled());
 
-fd = kvmppc_get_htab_fd(true);
+fd = kvmppc_get_htab_fd(true, 0, &local_err);
 if (fd < 0) {
-error_report("Unable to open fd to restore KVM hash table: %s",
- strerror(fd));
+error_report_err(local_err);
 return fd;
 }
 }
diff --git a/target/ppc/kvm.c b/target/ppc/kvm.c
index 09d7dea79e2d..c37d74941085 100644
--- a/target/ppc/kvm.c
+++ b/target/ppc/kvm.c
@@ -2550,21 +2550,25 @@ int kvmppc_define_rtas_kernel_token(uint32_t token, 
const char *function)
 return kvm_vm_ioctl(kvm_state, KVM_PPC_RTAS_DEFINE_TOKEN, &args);
 }
 
-int kvmppc_get_htab_fd(bool write)
+int kvmppc_get_htab_fd(bool write, uint64_t index, Error **errp)
 {
 struct kvm_get_htab_fd s = {
 .flags = write ? KVM_GET_HTAB_WRITE : 0,
-.start_index = 0,
+.start_index = index,
 };
 int ret;
 
 if (!cap_htab_fd) {
-fprintf(stderr, "KVM version doesn't support saving the hash table\n");
+error_setg(errp, "KVM version doesn't support %s the HPT",
+   write ? "writing" : "reading");
 return -ENOTSUP;
 }
 
 ret = kvm_vm_ioctl(kvm_state, KVM_PPC_GET_HTAB_FD, &s);
 if (ret < 0) {
+error_setg(errp, "Unable to open fd for %s HPT %s KVM: %s",
+   write ? "writing" : "reading", write ? "to" : "from",
+   strerror(errno));
 return -errno;
 }
 
@@ -2648,17 +2652,10 @@ void kvm_arch_init_irq_routing(KVMState *s)
 
 void kvmppc_read_hptes(ppc_hash_pte64_t *hptes, hwaddr ptex, int n)
 {
-struct kvm_get_htab_fd ghf = {
-.flags = 0,
-.start_index = ptex,
-};
 int fd, rc;
 int i;
 
-fd = kvm_vm_ioctl(kvm_state, KVM_PPC_GET_HTAB_FD, &ghf);
-if (fd < 0) {
-hw_error("kvmppc_read_hptes: Unable to open HPT fd");
-}
+fd = kvmppc_get_htab_fd(false, ptex, &error_abort);
 
 i = 0;
 while (i < n) {
@@ -2700,19 +2697,13 @@ void kvmppc_read_hptes(ppc_hash_pte64_t *hptes, hwaddr 
ptex, int n)
 void kvmppc_write_hpte(hwaddr ptex, uint64_t pte0, uint64_t pte1)
 {
 int fd, rc;
-struct kvm_get_htab_fd ghf;
 struct {
 struct kvm_get_htab_header hdr;
 

[Qemu-devel] [PATCH 2/4] spapr: introduce helpers to migrate HPT chunks and the end marker

[Greg Kurz]

This consolidates some duplicated code in a single helper.

Signed-off-by: Greg Kurz 
---
 hw/ppc/spapr.c |   38 +-
 1 file changed, 21 insertions(+), 17 deletions(-)

diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index f680f28a15ea..841117f6d185 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -1708,6 +1708,23 @@ static int htab_save_setup(QEMUFile *f, void *opaque)
 return 0;
 }
 
+static void htab_save_chunk(QEMUFile *f, sPAPRMachineState *spapr,
+int chunkstart, int n_valid, int n_invalid)
+{
+qemu_put_be32(f, chunkstart);
+qemu_put_be16(f, n_valid);
+qemu_put_be16(f, n_invalid);
+if (spapr) {
+qemu_put_buffer(f, HPTE(spapr->htab, chunkstart),
+HASH_PTE_SIZE_64 * n_valid);
+}
+}
+
+static void htab_save_end_marker(QEMUFile *f)
+{
+htab_save_chunk(f, NULL, 0, 0, 0);
+}
+
 static void htab_save_first_pass(QEMUFile *f, sPAPRMachineState *spapr,
  int64_t max_ns)
 {
@@ -1739,11 +1756,7 @@ static void htab_save_first_pass(QEMUFile *f, 
sPAPRMachineState *spapr,
 if (index > chunkstart) {
 int n_valid = index - chunkstart;
 
-qemu_put_be32(f, chunkstart);
-qemu_put_be16(f, n_valid);
-qemu_put_be16(f, 0);
-qemu_put_buffer(f, HPTE(spapr->htab, chunkstart),
-HASH_PTE_SIZE_64 * n_valid);
+htab_save_chunk(f, spapr, chunkstart, n_valid, 0);
 
 if (has_timeout &&
 (qemu_clock_get_ns(QEMU_CLOCK_REALTIME) - starttime) > max_ns) 
{
@@ -1805,11 +1818,7 @@ static int htab_save_later_pass(QEMUFile *f, 
sPAPRMachineState *spapr,
 int n_valid = invalidstart - chunkstart;
 int n_invalid = index - invalidstart;
 
-qemu_put_be32(f, chunkstart);
-qemu_put_be16(f, n_valid);
-qemu_put_be16(f, n_invalid);
-qemu_put_buffer(f, HPTE(spapr->htab, chunkstart),
-HASH_PTE_SIZE_64 * n_valid);
+htab_save_chunk(f, spapr, chunkstart, n_valid, n_invalid);
 sent += index - chunkstart;
 
 if (!final && (qemu_clock_get_ns(QEMU_CLOCK_REALTIME) - starttime) 
> max_ns) {
@@ -1872,10 +1881,7 @@ static int htab_save_iterate(QEMUFile *f, void *opaque)
 rc = htab_save_later_pass(f, spapr, MAX_ITERATION_NS);
 }
 
-/* End marker */
-qemu_put_be32(f, 0);
-qemu_put_be16(f, 0);
-qemu_put_be16(f, 0);
+htab_save_end_marker(f);
 
 return rc;
 }
@@ -1915,9 +1921,7 @@ static int htab_save_complete(QEMUFile *f, void *opaque)
 }
 
 /* End marker */
-qemu_put_be32(f, 0);
-qemu_put_be16(f, 0);
-qemu_put_be16(f, 0);
+htab_save_end_marker(f);
 
 return 0;
 }

[Qemu-devel] [PATCH 3/4] ppc/kvm: change kvmppc_get_htab_fd() to return -errno on error

[Greg Kurz]

When kvmppc_get_htab_fd() fails, its return value is propagated up to
qemu_savevm_state_iterate() or to qemu_savevm_state_complete_precopy().
All savevm handlers expect to receive a negative errno on error.

Let's patch kvmppc_get_htab_fd() accordingly.

While here, let's change htab_load() in the spapr code to also
propagate the error, since it doesn't make sense to abort() if
we couldn't get the htab fd from KVM.

Signed-off-by: Greg Kurz 
---
 hw/ppc/spapr.c   |5 +++--
 target/ppc/kvm.c |   10 --
 2 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 841117f6d185..1ae79326d1ac 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -1218,7 +1218,7 @@ static int get_htab_fd(sPAPRMachineState *spapr)
 spapr->htab_fd = kvmppc_get_htab_fd(false);
 if (spapr->htab_fd < 0) {
 error_report("Unable to open fd for reading hash table from KVM: %s",
- strerror(errno));
+ strerror(spapr->htab_fd));
 }
 
 return spapr->htab_fd;
@@ -1962,7 +1962,8 @@ static int htab_load(QEMUFile *f, void *opaque, int 
version_id)
 fd = kvmppc_get_htab_fd(true);
 if (fd < 0) {
 error_report("Unable to open fd to restore KVM hash table: %s",
- strerror(errno));
+ strerror(fd));
+return fd;
 }
 }
 
diff --git a/target/ppc/kvm.c b/target/ppc/kvm.c
index 00d7029b8d7a..09d7dea79e2d 100644
--- a/target/ppc/kvm.c
+++ b/target/ppc/kvm.c
@@ -2556,13 +2556,19 @@ int kvmppc_get_htab_fd(bool write)
 .flags = write ? KVM_GET_HTAB_WRITE : 0,
 .start_index = 0,
 };
+int ret;
 
 if (!cap_htab_fd) {
 fprintf(stderr, "KVM version doesn't support saving the hash table\n");
-return -1;
+return -ENOTSUP;
+}
+
+ret = kvm_vm_ioctl(kvm_state, KVM_PPC_GET_HTAB_FD, &s);
+if (ret < 0) {
+return -errno;
 }
 
-return kvm_vm_ioctl(kvm_state, KVM_PPC_GET_HTAB_FD, &s);
+return ret;
 }
 
 int kvmppc_save_htab(QEMUFile *f, int fd, size_t bufsize, int64_t max_ns)

[Qemu-devel] [PATCH 0/4] ppc/kvm: htab fd code improvements

[Greg Kurz]

This series drops unused code and consolidates some duplicated code that
deals with KVM's htab fd feature. It also fixes some potential bugs.

--
Greg

---

Greg Kurz (4):
  ppc/kvm: drop kvmppc_has_cap_htab_fd()
  spapr: introduce helpers to migrate HPT chunks and the end marker
  ppc/kvm: change kvmppc_get_htab_fd() to return -errno on error
  ppc/kvm: generalize the use of kvmppc_get_htab_fd()


 hw/ppc/spapr.c   |   54 +++---
 target/ppc/kvm.c |   42 ---
 target/ppc/kvm_ppc.h |   10 ++---
 3 files changed, 48 insertions(+), 58 deletions(-)

[Qemu-devel] [PATCH 1/4] ppc/kvm: drop kvmppc_has_cap_htab_fd()

[Greg Kurz]

It never got used since its introduction (commit 7c43bca004af).

Signed-off-by: Greg Kurz 
---
 target/ppc/kvm.c |5 -
 target/ppc/kvm_ppc.h |6 --
 2 files changed, 11 deletions(-)

diff --git a/target/ppc/kvm.c b/target/ppc/kvm.c
index 1deaf106d2b9..00d7029b8d7a 100644
--- a/target/ppc/kvm.c
+++ b/target/ppc/kvm.c
@@ -2448,11 +2448,6 @@ bool kvmppc_has_cap_epr(void)
 return cap_epr;
 }
 
-bool kvmppc_has_cap_htab_fd(void)
-{
-return cap_htab_fd;
-}
-
 bool kvmppc_has_cap_fixup_hcalls(void)
 {
 return cap_fixup_hcalls;
diff --git a/target/ppc/kvm_ppc.h b/target/ppc/kvm_ppc.h
index f780e6ec7b72..08aab46c5a56 100644
--- a/target/ppc/kvm_ppc.h
+++ b/target/ppc/kvm_ppc.h
@@ -51,7 +51,6 @@ uint64_t kvmppc_rma_size(uint64_t current_size, unsigned int 
hash_shift);
 #endif /* !CONFIG_USER_ONLY */
 bool kvmppc_has_cap_epr(void);
 int kvmppc_define_rtas_kernel_token(uint32_t token, const char *function);
-bool kvmppc_has_cap_htab_fd(void);
 int kvmppc_get_htab_fd(bool write);
 int kvmppc_save_htab(QEMUFile *f, int fd, size_t bufsize, int64_t max_ns);
 int kvmppc_load_htab_chunk(QEMUFile *f, int fd, uint32_t index,
@@ -246,11 +245,6 @@ static inline int kvmppc_define_rtas_kernel_token(uint32_t 
token,
 return -1;
 }
 
-static inline bool kvmppc_has_cap_htab_fd(void)
-{
-return false;
-}
-
 static inline int kvmppc_get_htab_fd(bool write)
 {
 return -1;

Re: [Qemu-devel] [PATCH RFC 1/1] s390x/ccw: create s390 phb for compat reasons as well

[David Hildenbrand]

On 15.09.2017 15:07, Cornelia Huck wrote:
> On Fri, 15 Sep 2017 13:57:40 +0200
> David Hildenbrand  wrote:
> 
>> As an alternative, simply
>>
>> diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c
>> index 0f28ebd162..0f22efc3b6 100644
>> --- a/target/s390x/cpu_models.c
>> +++ b/target/s390x/cpu_models.c
>> @@ -195,6 +195,8 @@ bool s390_has_feat(S390Feat feat)
>>  return true;
>>  }
>>  }
>> +if (feat == S390_FEAT_ZPCI)
>> +return true;
> 
> Move that out of the CONFIG_KVM #ifdef?
> 

Should not make a difference I think, cpu models are not shielded off
for TCG I think (maybe we should fix that, but doesn't look that easy -
they have no host model which would allow cpu->model = NULL).

> (Also, we still have the issue with pci support :/ - depend on
> pci_available?)

hm 

> 
>>  #endif
>>  return 0;
>>  }
>>
>>
>> (this is also the way we handle other features without cpu model support
>> -especially if cpu model support is disabled for older machines)
> 
> Now that you mention cpu models (which are disabled on old machines),
> the failure starts to look plausible :)
> 


-- 

Thanks,

David

Re: [Qemu-devel] [PATCH RFC 1/1] s390x/ccw: create s390 phb for compat reasons as well

[Cornelia Huck]

On Fri, 15 Sep 2017 13:57:40 +0200
David Hildenbrand  wrote:

> As an alternative, simply
> 
> diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c
> index 0f28ebd162..0f22efc3b6 100644
> --- a/target/s390x/cpu_models.c
> +++ b/target/s390x/cpu_models.c
> @@ -195,6 +195,8 @@ bool s390_has_feat(S390Feat feat)
>  return true;
>  }
>  }
> +if (feat == S390_FEAT_ZPCI)
> +return true;

Move that out of the CONFIG_KVM #ifdef?

(Also, we still have the issue with pci support :/ - depend on
pci_available?)

>  #endif
>  return 0;
>  }
> 
> 
> (this is also the way we handle other features without cpu model support
> -especially if cpu model support is disabled for older machines)

Now that you mention cpu models (which are disabled on old machines),
the failure starts to look plausible :)

Re: [Qemu-devel] [PATCH v2 2/2] virtio-gpu-ccw: Create a virtio gpu device for the ccw bus

[Farhan Ali]

On 09/15/2017 03:40 AM, Thomas Huth wrote:

On 14.09.2017 17:55, Farhan Ali wrote:

Wire up the virtio-gpu device for the CCW bus. The virtio-gpu
is a virtio-1 device, so disable revision 0.

Signed-off-by: Farhan Ali 
Acked-by: Christian Borntraeger 
Reviewed-by: Halil Pasic 
---
 hw/s390x/virtio-ccw.c | 49 +
 hw/s390x/virtio-ccw.h | 10 ++


Reviewed-by: Thomas Huth 


Thanks for the review :)

Re: [Qemu-devel] [PATCH v2 1/2] virtio-gpu: Handle endian conversion

[Farhan Ali]

On 09/15/2017 03:31 AM, Gerd Hoffmann wrote:

  Hi,


+static void
+virtio_gpu_ctrl_hdr_bswap_cpu(struct virtio_gpu_ctrl_hdr *hdr)
+{
+hdr->type =  le32_to_cpu(hdr->type);
+hdr->flags = le32_to_cpu(hdr->flags);
+hdr->fence_id = le64_to_cpu(hdr->fence_id);
+hdr->ctx_id = le32_to_cpu(hdr->ctx_id);
+hdr->padding = le32_to_cpu(hdr->padding);
+}
+
+static void
+virtio_gpu_ctrl_hdr_bswap_le(struct virtio_gpu_ctrl_hdr *hdr)
+{
+hdr->type =  cpu_to_le32(hdr->type);
+hdr->flags = cpu_to_le32(hdr->flags);
+hdr->fence_id = cpu_to_le64(hdr->fence_id);
+hdr->ctx_id = cpu_to_le32(hdr->ctx_id);
+hdr->padding = cpu_to_le32(hdr->padding);
+}


These two functions do exactly the same thing because cpu_to_le32 and
le32_to_cpu are the same operation.  The two variants only exist to
make the code more readable.  So this isn't needed twice.  I'd suggest
to just call the functions "*_bswap" and drop any _le or _cpu postfix.
Note that there are also variants for in-place swapping.

Have a look at the comments in include/qemu/bswap.h


Thanks for pointing that out. I will re-spin another version.


+
+static void virtio_gpu_bswap_cpu_32(void *ptr,
+size_t size)
+{


#ifdef HOST_WORDS_BIGENDIAN


+size_t i;
+struct virtio_gpu_ctrl_hdr *hdr = (struct virtio_gpu_ctrl_hdr *)
ptr;
+
+virtio_gpu_ctrl_hdr_bswap_cpu(hdr);
+
+i = sizeof(struct virtio_gpu_ctrl_hdr);
+while (i < size) {
+*(uint32_t *)(ptr + i) = le32_to_cpu(*(uint32_t *)(ptr +
i));
+i = i + sizeof(uint32_t);
+}


#endif

I suspect the compiler isn't clever enough to figure the whole function
is a nop on little endian hosts.


This makes sense.

Thanks
Farhan


cheers,
  Gerd

Re: [Qemu-devel] [PATCH 4/7] tcg: Add support for "inlining" regions of code

[Lluís Vilanova]

Richard Henderson writes:

> On 09/14/2017 08:20 AM, Lluís Vilanova wrote:
>> Richard Henderson writes:
>> 
>>> On 09/10/2017 09:27 AM, Lluís Vilanova wrote:
 TCG BBLs and instructions have multiple exit points from where to raise
 tracing events, but some of the necessary information in the generic
 disassembly infrastructure is not available until after generating these
 exit points.
 
 This patch adds support for "inline points" (where the tracing code will
 be placed), and "inline regions" (which identify the TCG code that must
 be inlined). The TCG compiler will basically copy each inline region to
 any inline points that reference it.
>> 
>>> I am not keen on this.
>> 
>>> Is there a reason you can't just emit the tracing code at the appropriate 
>>> place
>>> to begin with?  Perhaps I have to wait to see how this is used...
>> 
>> As I tried to briefly explain on next patch, the main problem without 
>> inlining
>> is that we will see guest_tb_after_trans twice on the trace for each TB in
>> conditional instructions on the guest, since they have two exit points 
>> (which we
>> capture when emitting goto_tb in TCG).

> Without seeing the code, I suspect this is because you didn't examine the
> argument to tcg_gen_exit_tb.  You can tell when goto_tb must have been emitted
> and avoid logging twice.

The generated tracing code for 'guest_*_after' must be right before the
"goto_tb" opcode at the end of a TB (AFAIU generated by
tcg_gen_lookup_and_goto_ptr()), and we have two of those when decoding a guest
conditional jump.

If we couple this with the semantics of the trace_*_tcg functions (trace the
event at translation time, and generate TCG code to trace the event at execution
time), we get the case I described (we don't want to call trace_tb_after_tcg()
or trace_insn_after_tcg() twice for the same TB or instruction).

That is, unless I've missed something.


The only alternative I can think of is changing tracetool to offer an additional
API that provides separate functions for translation-time tracing and
execution-time generation. So from this:

  static inline void trace_event_tcg(CPUState *cpu, TCGv_env env, ...)
  {
  trace_event_trans(cpu, ...);
  if (trace_event_get_vcpu_state(cpu, EVENT_EXEC)) {
  gen_helper_trace_event_exec(env, ...);
  }
  }

We can extend it into this:

  static inline void gen_trace_event_exec(TCGv_env env, ...)
  if (trace_event_get_vcpu_state(cpu, EVENT_EXEC)) {
  gen_helper_trace_event_exec(env, ...);
  }
  }
  static inline void trace_event_tcg(CPUState *cpu, TCGv_env env, ...)
  {
  trace_event_trans(cpu, ...);
  gen_trace_event_exec(env, ...);
  }


Cheers,
  Lluis

Re: [Qemu-devel] [PULL v4 00/38] Test and build patches

[Fam Zheng]

On Fri, 09/15 13:31, Daniel P. Berrange wrote:
> On Fri, Sep 15, 2017 at 08:21:53PM +0800, Fam Zheng wrote:
> > On Fri, 09/15 12:40, Daniel P. Berrange wrote:
> > > On Fri, Sep 15, 2017 at 11:55:44AM +0100, Peter Maydell wrote:
> > > > On 15 September 2017 at 10:02, Fam Zheng  wrote:
> > > > > The following changes since commit 
> > > > > 04ef33052c205170c92df21ca0b4be4f3b102188:
> > > > >
> > > > >   tcg/tci: do not use ldst label (never implemented) (2017-09-11 
> > > > > 19:24:05 +0100)
> > > > >
> > > > > are available in the git repository at:
> > > > >
> > > > >   git://github.com/famz/qemu.git tags/test-and-build-pull-request
> > > > >
> > > > > for you to fetch changes up to 
> > > > > be78fe670401af14e6d63fce5c5467f751207871:
> > > > >
> > > > >   buildsys: Move rdma libs to per object (2017-09-15 15:05:24 +0800)
> > > > >
> > > > > 
> > > > >
> > > > > 
> > > > >
> > > > > Alex Bennée (4):
> > > > >   docker: ensure NOUSER for travis images
> > > > >   docker: docker.py make --no-cache skip checksum test
> > > > >   docker: don't install device-tree-compiler build-deps in 
> > > > > travis.docker
> > > > >   docker: reduce noise when building travis.docker
> > > > >
> > > > > Fam Zheng (34):
> > > > >   docker: Update ubuntu image
> > > > >   docker: Enable features explicitly in test-full
> > > > >   tests/docker: Clean up paths
> > > > >   gitignore: Ignore vm test images
> > > > >   qemu.py: Add "wait()" method
> > > > >   scripts: Add archive-source.sh
> > > > >   tests: Add a test key pair
> > > > 
> > > > So, before I commit an ssh private key to our git repo,
> > > > can you explain why it's ok that this is public? The
> > > > commit message for the relevant patch doesn't really say.
> > > 
> > > IIUC, the public part of the key gets exposed to the guest images via
> > > cloud-init metadata. During boot the guest read this metadata and add
> > > the public key to authorized_keys. The private key is used by the test
> > > suite on the host so that it can now login to the guests.
> > > 
> > > So the risk here is that if these guests were exposed to the LAN in any
> > > way, someone could grab our private key and login to these guests.
> > > 
> > > What saves us is that the VMs are run with user mode slirp networking
> > > so AFAICT, aren't exposed to the LAN.  So as long as we don't change
> > > this to any kind of real networking, I think its acceptable to have
> > > the private key in it and doesn't expose developer's workstations to
> > > undue risk and avoids consuming system entropy to generate new keys
> > > during build.
> > 
> > The hostfwd does listen on a dynamic port on 0.0.0.0, so does vnc. I didn't
> > really care since it's for temporary guests and for me convenience 
> > outweighed a
> > bit.  The VM test is indeed less restricted than the docker ones such as in 
> > that
> > network is always available. Should it be a problem?
> 
> AFAICT there's no functional reason why it needs to listen on 0.0.0.0,
> instead of 127.0.0.1, so general security best practice says it should
> not expose this listening port on LAN interfaces for the developers
> machine, even if we think the risk is low.

Yes, makes sense, let's change it. The only disadvantage of 127.0.0.1 is if the
test is run on a remote host, you don't have to ssh to the host and proxy from
there to login to the guest. The test is automated, so accessing guest may be a
rare need outside patchew (a few months ago I frequently need to diagnose
hanging tests on patchew, no idea how this vm test will do :).

Fam

Re: [Qemu-devel] [PATCH 4/4] ppc: ensure we update the decrementer value during migration

[Mark Cave-Ayland]

On 14/09/17 04:52, David Gibson wrote:

> On Wed, Sep 13, 2017 at 07:58:23PM +0200, Laurent Vivier wrote:
>> On 13/09/2017 19:11, Mark Cave-Ayland wrote:
>>> On 13/09/17 08:12, David Gibson wrote:
>>>
 This is subtly incorrect.  It sets the DECR on load to exactly the
 value that was saved.  That effectively means that the DECR is frozen
 for the migration downtime, which probably isn't what we want.

 Instead we need to save the DECR as an offset from the timebase, and
 restore it relative to the (downtime adjusted) timebase on the
 destination.

 The complication with that is that the timebase is generally migrated
 at the machine level, not the cpu level: the timebase is generally
 synchronized between cpus in the machine, and migrating it at the
 individual cpu could break that.  Which means we probably need a
 machine level hook to handle the decrementer too, even though it
 logically *is* per-cpu, because otherwise we'll be trying to restore
 it before the timebase is restored.
>>>
>>> I know that we discussed this in-depth last year, however I was working
>>> along the lines that Laurent's patch fixed this along the lines of our
>>> previous discussion:
>>> https://lists.gnu.org/archive/html/qemu-devel/2017-02/msg00338.html (and
>>> indeed Laurent's analysis at
>>> https://lists.gnu.org/archive/html/qemu-devel/2017-02/msg01489.html).
>>>
>>> However looking again at the this patch in the context you mentioned
>>> above, I'm starting to wonder if the right solution now is for the
>>> machine init function for g3beige/mac99 to do the same as spapr, e.g.
>>> add cpu_ppc_clock_vm_state_change() as a vm_change_state_handler and
>>> then add VMSTATE_PPC_TIMEBASE_V from the machine PPCTimeBase into my new
>>> subsection?
>>>
>>> Laurent, do you think that your state change handler would work
>>> correctly in this way?
>>
>> I think all is explained in the second link you have mentioned, it seems 
>> we don't need a state handler as KVM DECR will no be updated by the migrated 
>> value:
>>
>> hw/ppc/ppc.c
>>
>> 736 static void __cpu_ppc_store_decr(PowerPCCPU *cpu, uint64_t *nextp,
>> 737  QEMUTimer *timer,
>> 738  void (*raise_excp)(void *),
>> 739  void (*lower_excp)(PowerPCCPU *),
>> 740  uint32_t decr, uint32_t value)
>> 741 {
>> ...
>> 749 if (kvm_enabled()) {
>> 750 /* KVM handles decrementer exceptions, we don't need our own 
>> timer */
>> 751 return;
>> 752 }
>> ...
>>
>> But this allows to migrate it for TCG. And it should be correct because in 
>> case of TCG I think [need to check] timebase is stopped too (so offset is 0)
>>
>> David, do you agree with that?
> 
> Yes, I think so.  Some details might be different, but the basic idea
> of migrating the timebase and decrementers at machine level should be
> the same for pseries and g3beige/whatever.

>From my perspective, I'd really like to bury all of the timebase
migration logic into timebase_load()/timebase_save() so then as you
suggest above, everything will work regardless of the machine type and host.

Playing around with these functions I can see that they are very
PPC-specific - for example cpu_get_host_ticks() can only ever work
correctly migrating between 2 PPC hosts because here on Intel the value
returned is the TSC register which is completely unrelated to the
timebase frequency. Hence the calculated values are nonsense and the
guest inevitably ends up freezing.

I've had a go at converting this back to using the host clock to
calculate the required adjustment to tb_offset (see
https://github.com/mcayland/qemu/commit/68e31f0455a79d41b2ab703364c74ceb4d513154)
but then even that struck me as incorrect since unless there are other
host CPUs with an equivalent of tb_offset, this whole section of code
should only ever run if the host CPU is PPC, and maybe even only under KVM.

My current thoughts are now as follows:

- The existing timebase_load() should never adjust tb_offset unless the
host CPU is also PPC (how do we actually determine this?). Otherwise it
should always be 0.

- The per-CPU decrementer values should be *stored* in the normal
vmstate SPR array as per my latest patch at
https://lists.gnu.org/archive/html/qemu-devel/2017-09/msg02346.html.

BUT:

- The per-CPU decrementer values should be *restored* in timebase_load()
but again should not be adjusted by tb_offset unless the host CPU is
also PPC.

The real question is whether tb_offset is used for a TCG PPC guest on a
PPC host or whether it also remains at 0 as it does here on an Intel
host? If it does remain at 0 for a TCG PPC guest on a PPC host then we
don't need to work out whether we are running on a PPC host at all: we
can just skip the timebase adjustments made by timebase_load() if
!kvm_enabled() and everything should just

Re: [Qemu-devel] [PATCH] rbd: Detect rbd image resizes and propagate them

[Kevin Wolf]

Am 13.09.2017 um 18:44 hat Adam Wolfe Gordon geschrieben:
> Register a watcher with rbd so that we get notified when an image is
> resized. Propagate resizes to parent block devices so that guest devices
> get resized without user intervention.
> 
> Signed-off-by: Adam Wolfe Gordon 
> ---
> Hello!
> 
> We are using this patch in production at DigitalOcean and have tested it 
> fairly
> extensively. However, we use the same block device configuration everywhere, 
> so
> I'd be interested to get an answer to the question I've left in the code:
> 
> > /* NOTE: This assumes there's only one layer between us and the
> >block-backend. Is this always true? */
> 
> If that isn't true, this patch will need a bit of work to traverse up the 
> block
> device tree and find the block-backend.
> 
> Of course, any other feedback would be welcome too - this is my first foray 
> into
> the qemu code.
> 
> Regards,
> Adam
> 
>  block/rbd.c | 80 
> +
>  1 file changed, 80 insertions(+)
> 
> diff --git a/block/rbd.c b/block/rbd.c
> index 144f350e1f..1c9fcbec1f 100644
> --- a/block/rbd.c
> +++ b/block/rbd.c
> @@ -96,6 +96,8 @@ typedef struct BDRVRBDState {
>  rbd_image_t image;
>  char *image_name;
>  char *snap;
> +uint64_t watcher_handle;
> +uint64_t size_bytes;
>  } BDRVRBDState;
>  
>  static char *qemu_rbd_next_tok(char *src, char delim, char **p)
> @@ -540,6 +542,67 @@ out:
>  return rados_str;
>  }
>  
> +/* BH for when rbd notifies us of an update. */
> +static void qemu_rbd_update_bh(void *arg)
> +{
> +BlockDriverState *parent, *bs = arg;
> +BDRVRBDState *s = bs->opaque;
> +bool was_variable_length;
> +uint64_t new_size_bytes;
> +int64_t new_parent_len;
> +BdrvChild *c;
> +int r;
> +
> +r = rbd_get_size(s->image, &new_size_bytes);
> +if (r < 0) {
> +error_report("error reading size for %s: %s", s->name, strerror(-r));
> +return;
> +}
> +
> +/* Avoid no-op resizes on non-resize notifications. */
> +if (new_size_bytes == s->size_bytes) {
> +error_printf("skipping non-resize rbd cb\n");
> +return;
> +}
> +
> +/* NOTE: This assumes there's only one layer between us and the
> +   block-backend. Is this always true? */
> +parent = bs->inherits_from;

There's more wrong about this than just making assumptions about the
graph layout above our own node (which would be wrong enough already).

Other assumptions that you are making here and that don't hold true
generally are that there is only one parent node (no reason why the
image couldn't be used by two different users) and that we always
inherit from a parent. If this node was created explicitly by the user
with its own -blockdev (or -drive) option, it doesn't inherit options
from any of its parents.

Basically, a block driver shouldn't care about its users and it can't
access them in a clean way. This is intentional.

> +if (parent == NULL) {
> +error_report("bs %s does not have parent", 
> bdrv_get_device_or_node_name(bs));
> +return;
> +}
> +
> +/* Force parents to re-read our size. */
> +was_variable_length = bs->drv->has_variable_length;
> +bs->drv->has_variable_length = true;
> +new_parent_len = bdrv_getlength(parent);
> +if (new_parent_len < 0) {
> +error_report("getlength failed on parent %s", 
> bdrv_get_device_or_node_name(parent));
> +bs->drv->has_variable_length = was_variable_length;
> +return;
> +}
> +bs->drv->has_variable_length = was_variable_length;
> +
> +/* Notify block backends that that we have resized.
> +   Copied from bdrv_parent_cb_resize. */
> +QLIST_FOREACH(c, &parent->parents, next_parent) {
> +if (c->role->resize) {
> +c->role->resize(c);
> +}
> +}

This is the right approach that you should use consistently instead.

You don't only notify BlockBackends here (you do so if there is no layer
between rbd and the BlockBackend, i.e. rbd is the root node), but you
also notify any parent nodes (BlockDriverStates), which can react to
this.

child_file/child_format don't currently handle .resize, so if you have
any layers between rbd and the BB, this code doesn't do anything at the
moment.

However, you could introduce an implementation of .resize. An important
point here is that it depends on the specific block driver what to do
with this notification. Maybe we need a new BlockDriver callback. Raw
images will just propagate this and call .resize on all of their
parents. For qcow2 images, the size change of the image file doesn't
make a difference for the virtual disk that the driver exposes, so it
will silently ignore the notification.

Kevin

Re: [Qemu-devel] [PULL v4 00/38] Test and build patches

[Daniel P. Berrange]

On Fri, Sep 15, 2017 at 08:21:53PM +0800, Fam Zheng wrote:
> On Fri, 09/15 12:40, Daniel P. Berrange wrote:
> > On Fri, Sep 15, 2017 at 11:55:44AM +0100, Peter Maydell wrote:
> > > On 15 September 2017 at 10:02, Fam Zheng  wrote:
> > > > The following changes since commit 
> > > > 04ef33052c205170c92df21ca0b4be4f3b102188:
> > > >
> > > >   tcg/tci: do not use ldst label (never implemented) (2017-09-11 
> > > > 19:24:05 +0100)
> > > >
> > > > are available in the git repository at:
> > > >
> > > >   git://github.com/famz/qemu.git tags/test-and-build-pull-request
> > > >
> > > > for you to fetch changes up to be78fe670401af14e6d63fce5c5467f751207871:
> > > >
> > > >   buildsys: Move rdma libs to per object (2017-09-15 15:05:24 +0800)
> > > >
> > > > 
> > > >
> > > > 
> > > >
> > > > Alex Bennée (4):
> > > >   docker: ensure NOUSER for travis images
> > > >   docker: docker.py make --no-cache skip checksum test
> > > >   docker: don't install device-tree-compiler build-deps in travis.docker
> > > >   docker: reduce noise when building travis.docker
> > > >
> > > > Fam Zheng (34):
> > > >   docker: Update ubuntu image
> > > >   docker: Enable features explicitly in test-full
> > > >   tests/docker: Clean up paths
> > > >   gitignore: Ignore vm test images
> > > >   qemu.py: Add "wait()" method
> > > >   scripts: Add archive-source.sh
> > > >   tests: Add a test key pair
> > > 
> > > So, before I commit an ssh private key to our git repo,
> > > can you explain why it's ok that this is public? The
> > > commit message for the relevant patch doesn't really say.
> > 
> > IIUC, the public part of the key gets exposed to the guest images via
> > cloud-init metadata. During boot the guest read this metadata and add
> > the public key to authorized_keys. The private key is used by the test
> > suite on the host so that it can now login to the guests.
> > 
> > So the risk here is that if these guests were exposed to the LAN in any
> > way, someone could grab our private key and login to these guests.
> > 
> > What saves us is that the VMs are run with user mode slirp networking
> > so AFAICT, aren't exposed to the LAN.  So as long as we don't change
> > this to any kind of real networking, I think its acceptable to have
> > the private key in it and doesn't expose developer's workstations to
> > undue risk and avoids consuming system entropy to generate new keys
> > during build.
> 
> The hostfwd does listen on a dynamic port on 0.0.0.0, so does vnc. I didn't
> really care since it's for temporary guests and for me convenience outweighed 
> a
> bit.  The VM test is indeed less restricted than the docker ones such as in 
> that
> network is always available. Should it be a problem?

AFAICT there's no functional reason why it needs to listen on 0.0.0.0,
instead of 127.0.0.1, so general security best practice says it should
not expose this listening port on LAN interfaces for the developers
machine, even if we think the risk is low.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

Re: [Qemu-devel] [PATCH] iotests: Print full path of bad output if mismatch

[Fam Zheng]

On Fri, 09/15 14:16, Kevin Wolf wrote:
> Am 15.09.2017 um 07:45 hat Fam Zheng geschrieben:
> > So it is easier to copy paste the path.
> > 
> > Signed-off-by: Fam Zheng 
> 
> I don't think I ever tried to do anything with the diff that would have
> required the full path, but if you say so... :-)
> 
> Thanks, applied to the block branch.

Thanks.

I often create a new reference output or fix an old one by

cp /x/y/z.out.bad tests/qemu-iotests/???.out

and either the /x/y/z or the path to QEMU repo is some typing if from
out-of-tree build, so getting it from the output of check is handy..

Fam

Re: [Qemu-devel] [RFC 00/15] QMP: out-of-band (OOB) execution support

[Daniel P. Berrange]

On Fri, Sep 15, 2017 at 01:19:56PM +0100, Dr. David Alan Gilbert wrote:
> * Daniel P. Berrange (berra...@redhat.com) wrote:
> > On Fri, Sep 15, 2017 at 01:06:44PM +0100, Dr. David Alan Gilbert wrote:
> > > * Daniel P. Berrange (berra...@redhat.com) wrote:
> > > > On Fri, Sep 15, 2017 at 11:49:26AM +0100, Stefan Hajnoczi wrote:
> > > > > On Fri, Sep 15, 2017 at 11:50:57AM +0800, Peter Xu wrote:
> > > > > > On Thu, Sep 14, 2017 at 04:19:11PM +0100, Stefan Hajnoczi wrote:
> > > > > > > On Thu, Sep 14, 2017 at 01:15:09PM +0200, Marc-André Lureau wrote:
> > > > > > > > There should be a limit in the number of requests the thread can
> > > > > > > > queue. Before the patch, the limit was enforced by system socket
> > > > > > > > buffering I think. Now, should oob commands still be processed 
> > > > > > > > even if
> > > > > > > > the queue is full? If so, the thread can't be suspended.
> > > > > > > 
> > > > > > > I agree.
> > > > > > > 
> > > > > > > Memory usage must be bounded.  The number of requests is less 
> > > > > > > important
> > > > > > > than the amount of memory consumed by them.
> > > > > > > 
> > > > > > > Existing QMP clients that send multiple QMP commands without 
> > > > > > > waiting for
> > > > > > > replies need to rethink their strategy because OOB commands 
> > > > > > > cannot be
> > > > > > > processed if queued non-OOB commands consume too much memory.
> > > > > > 
> > > > > > Thanks for pointing out this.  Yes the memory usage problem is 
> > > > > > valid,
> > > > > > as Markus pointed out as well in previous discussions (in "Flow
> > > > > > Control" section of that long reply).  Hopefully this series 
> > > > > > basically
> > > > > > can work from design prospective, then I'll add this flow control in
> > > > > > next version.
> > > > > > 
> > > > > > Regarding to what we should do if the limit is reached: Markus
> > > > > > provided a few options, but the one I prefer most is that we don't
> > > > > > respond, but send an event showing that a command is dropped.
> > > > > > However, I would like it not queued, but a direct reply (after all,
> > > > > > it's an event, and we should not need to care much on ordering of 
> > > > > > it).
> > > > > > Then we can get rid of the babysitting of those "to be failed"
> > > > > > requests asap, meanwhile we don't lose anything IMHO.
> > > > > > 
> > > > > > I think I also missed at least a unit test for this new interface.
> > > > > > Again, I'll add it after the whole idea is proved solid.  Thanks,
> > > > > 
> > > > > Another solution: the server reports available receive buffer space to
> > > > > the client.  The server only guarantees immediate OOB processing when
> > > > > the client stays within the receive buffer size.
> > > > > 
> > > > > Clients wishing to take advantage of OOB must query the receive buffer
> > > > > size and make sure to leave enough room.
> > > > 
> > > > I don't think having to query it ahead of time is particularly nice,
> > > > and of course it is inherantly racy.
> > > > 
> > > > I would just have QEMU emit an event when it pausing processing of the
> > > > incoming commands due to a full queue.  If the event includes the ID
> > > > of the last queued command, the client will know which (if any) of
> > > > its outstanding commands are delayed. Another even can be sent when
> > > > it restarts reading.
> > > 
> > > Hmm and now we're implementing flow control!
> > > 
> > > a) What exactly is the current semantics/buffer sizes?
> > > b) When do clients send multiple QMP commands on one channel without
> > > waiting for the response to the previous command?
> > > c) Would one queue entry for each class of commands/channel work
> > >   (Where a class of commands is currently 'normal' and 'oob')
> > 
> > I do wonder if we need to worry about request limiting at all from the
> > client side.  For non-OOB commands clients will wait for a reply before
> > sending a 2nd non-OOB command, so you'll never get a deep queue for.
> > 
> > OOB commands are supposed to be things which can be handled quickly
> > without blocking, so even if a client sent several commands at once
> > without waiting for replies, they're going to be processed quickly,
> > so whether we temporarily block reading off the wire is a minor
> > detail.
> 
> Lets just define it so that it can't - you send an OOB command and wait
> for it's response before sending another on that channel.
> 
> > IOW, I think we could just have a fixed 10 command queue and apps just
> > pretend that there's an infinite queue and nothing bad would happen from
> > the app's POV.
> 
> Can you justify 10 as opposed to 1?

Semantically I don't think it makes a difference if the OOB commands are
being processed sequentially by their thread. A >1 length queue would only
matter for non-OOB commands if an app was filling the pipeline with non-OOB
requests, as then that could block reading of OOB commands. 


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.fl

Re: [Qemu-devel] [PULL v4 00/38] Test and build patches

[Fam Zheng]

On Fri, 09/15 12:40, Daniel P. Berrange wrote:
> On Fri, Sep 15, 2017 at 11:55:44AM +0100, Peter Maydell wrote:
> > On 15 September 2017 at 10:02, Fam Zheng  wrote:
> > > The following changes since commit 
> > > 04ef33052c205170c92df21ca0b4be4f3b102188:
> > >
> > >   tcg/tci: do not use ldst label (never implemented) (2017-09-11 19:24:05 
> > > +0100)
> > >
> > > are available in the git repository at:
> > >
> > >   git://github.com/famz/qemu.git tags/test-and-build-pull-request
> > >
> > > for you to fetch changes up to be78fe670401af14e6d63fce5c5467f751207871:
> > >
> > >   buildsys: Move rdma libs to per object (2017-09-15 15:05:24 +0800)
> > >
> > > 
> > >
> > > 
> > >
> > > Alex Bennée (4):
> > >   docker: ensure NOUSER for travis images
> > >   docker: docker.py make --no-cache skip checksum test
> > >   docker: don't install device-tree-compiler build-deps in travis.docker
> > >   docker: reduce noise when building travis.docker
> > >
> > > Fam Zheng (34):
> > >   docker: Update ubuntu image
> > >   docker: Enable features explicitly in test-full
> > >   tests/docker: Clean up paths
> > >   gitignore: Ignore vm test images
> > >   qemu.py: Add "wait()" method
> > >   scripts: Add archive-source.sh
> > >   tests: Add a test key pair
> > 
> > So, before I commit an ssh private key to our git repo,
> > can you explain why it's ok that this is public? The
> > commit message for the relevant patch doesn't really say.
> 
> IIUC, the public part of the key gets exposed to the guest images via
> cloud-init metadata. During boot the guest read this metadata and add
> the public key to authorized_keys. The private key is used by the test
> suite on the host so that it can now login to the guests.
> 
> So the risk here is that if these guests were exposed to the LAN in any
> way, someone could grab our private key and login to these guests.
> 
> What saves us is that the VMs are run with user mode slirp networking
> so AFAICT, aren't exposed to the LAN.  So as long as we don't change
> this to any kind of real networking, I think its acceptable to have
> the private key in it and doesn't expose developer's workstations to
> undue risk and avoids consuming system entropy to generate new keys
> during build.

The hostfwd does listen on a dynamic port on 0.0.0.0, so does vnc. I didn't
really care since it's for temporary guests and for me convenience outweighed a
bit.  The VM test is indeed less restricted than the docker ones such as in that
network is always available. Should it be a problem?

We can probably add restrict=on to slirp and listen on loopback.

Fam

Re: [Qemu-devel] [RFC 00/15] QMP: out-of-band (OOB) execution support

[Dr. David Alan Gilbert]

* Daniel P. Berrange (berra...@redhat.com) wrote:
> On Fri, Sep 15, 2017 at 01:06:44PM +0100, Dr. David Alan Gilbert wrote:
> > * Daniel P. Berrange (berra...@redhat.com) wrote:
> > > On Fri, Sep 15, 2017 at 11:49:26AM +0100, Stefan Hajnoczi wrote:
> > > > On Fri, Sep 15, 2017 at 11:50:57AM +0800, Peter Xu wrote:
> > > > > On Thu, Sep 14, 2017 at 04:19:11PM +0100, Stefan Hajnoczi wrote:
> > > > > > On Thu, Sep 14, 2017 at 01:15:09PM +0200, Marc-André Lureau wrote:
> > > > > > > There should be a limit in the number of requests the thread can
> > > > > > > queue. Before the patch, the limit was enforced by system socket
> > > > > > > buffering I think. Now, should oob commands still be processed 
> > > > > > > even if
> > > > > > > the queue is full? If so, the thread can't be suspended.
> > > > > > 
> > > > > > I agree.
> > > > > > 
> > > > > > Memory usage must be bounded.  The number of requests is less 
> > > > > > important
> > > > > > than the amount of memory consumed by them.
> > > > > > 
> > > > > > Existing QMP clients that send multiple QMP commands without 
> > > > > > waiting for
> > > > > > replies need to rethink their strategy because OOB commands cannot 
> > > > > > be
> > > > > > processed if queued non-OOB commands consume too much memory.
> > > > > 
> > > > > Thanks for pointing out this.  Yes the memory usage problem is valid,
> > > > > as Markus pointed out as well in previous discussions (in "Flow
> > > > > Control" section of that long reply).  Hopefully this series basically
> > > > > can work from design prospective, then I'll add this flow control in
> > > > > next version.
> > > > > 
> > > > > Regarding to what we should do if the limit is reached: Markus
> > > > > provided a few options, but the one I prefer most is that we don't
> > > > > respond, but send an event showing that a command is dropped.
> > > > > However, I would like it not queued, but a direct reply (after all,
> > > > > it's an event, and we should not need to care much on ordering of it).
> > > > > Then we can get rid of the babysitting of those "to be failed"
> > > > > requests asap, meanwhile we don't lose anything IMHO.
> > > > > 
> > > > > I think I also missed at least a unit test for this new interface.
> > > > > Again, I'll add it after the whole idea is proved solid.  Thanks,
> > > > 
> > > > Another solution: the server reports available receive buffer space to
> > > > the client.  The server only guarantees immediate OOB processing when
> > > > the client stays within the receive buffer size.
> > > > 
> > > > Clients wishing to take advantage of OOB must query the receive buffer
> > > > size and make sure to leave enough room.
> > > 
> > > I don't think having to query it ahead of time is particularly nice,
> > > and of course it is inherantly racy.
> > > 
> > > I would just have QEMU emit an event when it pausing processing of the
> > > incoming commands due to a full queue.  If the event includes the ID
> > > of the last queued command, the client will know which (if any) of
> > > its outstanding commands are delayed. Another even can be sent when
> > > it restarts reading.
> > 
> > Hmm and now we're implementing flow control!
> > 
> > a) What exactly is the current semantics/buffer sizes?
> > b) When do clients send multiple QMP commands on one channel without
> > waiting for the response to the previous command?
> > c) Would one queue entry for each class of commands/channel work
> >   (Where a class of commands is currently 'normal' and 'oob')
> 
> I do wonder if we need to worry about request limiting at all from the
> client side.  For non-OOB commands clients will wait for a reply before
> sending a 2nd non-OOB command, so you'll never get a deep queue for.
> 
> OOB commands are supposed to be things which can be handled quickly
> without blocking, so even if a client sent several commands at once
> without waiting for replies, they're going to be processed quickly,
> so whether we temporarily block reading off the wire is a minor
> detail.

Lets just define it so that it can't - you send an OOB command and wait
for it's response before sending another on that channel.

> IOW, I think we could just have a fixed 10 command queue and apps just
> pretend that there's an infinite queue and nothing bad would happen from
> the app's POV.

Can you justify 10 as opposed to 1?

Dave

> Regards,
> Daniel
> -- 
> |: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org -o-https://fstop138.berrange.com :|
> |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

Re: [Qemu-devel] [PATCH] iotests: Print full path of bad output if mismatch

[Kevin Wolf]

Am 15.09.2017 um 07:45 hat Fam Zheng geschrieben:
> So it is easier to copy paste the path.
> 
> Signed-off-by: Fam Zheng 

I don't think I ever tried to do anything with the diff that would have
required the full path, but if you say so... :-)

Thanks, applied to the block branch.

Kevin

Re: [Qemu-devel] [RFC 00/15] QMP: out-of-band (OOB) execution support

[Daniel P. Berrange]

On Fri, Sep 15, 2017 at 01:06:44PM +0100, Dr. David Alan Gilbert wrote:
> * Daniel P. Berrange (berra...@redhat.com) wrote:
> > On Fri, Sep 15, 2017 at 11:49:26AM +0100, Stefan Hajnoczi wrote:
> > > On Fri, Sep 15, 2017 at 11:50:57AM +0800, Peter Xu wrote:
> > > > On Thu, Sep 14, 2017 at 04:19:11PM +0100, Stefan Hajnoczi wrote:
> > > > > On Thu, Sep 14, 2017 at 01:15:09PM +0200, Marc-André Lureau wrote:
> > > > > > There should be a limit in the number of requests the thread can
> > > > > > queue. Before the patch, the limit was enforced by system socket
> > > > > > buffering I think. Now, should oob commands still be processed even 
> > > > > > if
> > > > > > the queue is full? If so, the thread can't be suspended.
> > > > > 
> > > > > I agree.
> > > > > 
> > > > > Memory usage must be bounded.  The number of requests is less 
> > > > > important
> > > > > than the amount of memory consumed by them.
> > > > > 
> > > > > Existing QMP clients that send multiple QMP commands without waiting 
> > > > > for
> > > > > replies need to rethink their strategy because OOB commands cannot be
> > > > > processed if queued non-OOB commands consume too much memory.
> > > > 
> > > > Thanks for pointing out this.  Yes the memory usage problem is valid,
> > > > as Markus pointed out as well in previous discussions (in "Flow
> > > > Control" section of that long reply).  Hopefully this series basically
> > > > can work from design prospective, then I'll add this flow control in
> > > > next version.
> > > > 
> > > > Regarding to what we should do if the limit is reached: Markus
> > > > provided a few options, but the one I prefer most is that we don't
> > > > respond, but send an event showing that a command is dropped.
> > > > However, I would like it not queued, but a direct reply (after all,
> > > > it's an event, and we should not need to care much on ordering of it).
> > > > Then we can get rid of the babysitting of those "to be failed"
> > > > requests asap, meanwhile we don't lose anything IMHO.
> > > > 
> > > > I think I also missed at least a unit test for this new interface.
> > > > Again, I'll add it after the whole idea is proved solid.  Thanks,
> > > 
> > > Another solution: the server reports available receive buffer space to
> > > the client.  The server only guarantees immediate OOB processing when
> > > the client stays within the receive buffer size.
> > > 
> > > Clients wishing to take advantage of OOB must query the receive buffer
> > > size and make sure to leave enough room.
> > 
> > I don't think having to query it ahead of time is particularly nice,
> > and of course it is inherantly racy.
> > 
> > I would just have QEMU emit an event when it pausing processing of the
> > incoming commands due to a full queue.  If the event includes the ID
> > of the last queued command, the client will know which (if any) of
> > its outstanding commands are delayed. Another even can be sent when
> > it restarts reading.
> 
> Hmm and now we're implementing flow control!
> 
> a) What exactly is the current semantics/buffer sizes?
> b) When do clients send multiple QMP commands on one channel without
> waiting for the response to the previous command?
> c) Would one queue entry for each class of commands/channel work
>   (Where a class of commands is currently 'normal' and 'oob')

I do wonder if we need to worry about request limiting at all from the
client side.  For non-OOB commands clients will wait for a reply before
sending a 2nd non-OOB command, so you'll never get a deep queue for.

OOB commands are supposed to be things which can be handled quickly
without blocking, so even if a client sent several commands at once
without waiting for replies, they're going to be processed quickly,
so whether we temporarily block reading off the wire is a minor
detail.

IOW, I think we could just have a fixed 10 command queue and apps just
pretend that there's an infinite queue and nothing bad would happen from
the app's POV.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

Re: [Qemu-devel] [PATCH v2 0/3] iotests: cure s390x failures by switching to ccw/aliases

[Kevin Wolf]

Am 13.09.2017 um 11:10 hat Cornelia Huck geschrieben:
> Recent changes in s390x made pci support dependant on the zpci cpu
> feature, which is not provided on all models (and not on by default).
> This means we cannot instatiate pci devices on a standard qemu
> invocation for s390x. Moreover, the zpci instructions are not even
> wired up for tcg yet, so actually doing anything with those pci devices
> is bound to fail on tcg.
> 
> For 040, 051, 139, and 182, this can be fixed by switching to virtio-ccw
> from virtio-pci on s390x. 051 also needs a bit of post-processing on
> the output.
> 
> For 067, it is easier to switch to virtio aliases, which will pick
> virtio-ccw on s390x and virtio-pci elsewhere. It also exercises the
> aliasing path.

Thanks, dropped the whitespace change in patch 3 and applied to the
block branch.

Kevin

Re: [Qemu-devel] [PULL v4 00/38] Test and build patches

[Daniel P. Berrange]

On Fri, Sep 15, 2017 at 01:03:54PM +0100, Peter Maydell wrote:
> On 15 September 2017 at 12:40, Daniel P. Berrange  wrote:
> > IIUC, the public part of the key gets exposed to the guest images via
> > cloud-init metadata. During boot the guest read this metadata and add
> > the public key to authorized_keys. The private key is used by the test
> > suite on the host so that it can now login to the guests.
> >
> > So the risk here is that if these guests were exposed to the LAN in any
> > way, someone could grab our private key and login to these guests.
> >
> > What saves us is that the VMs are run with user mode slirp networking
> > so AFAICT, aren't exposed to the LAN.
> 
> If I'm reading the right bit of the script we run QEMU with a
> hostfwd specification using 0.0.0.0 as the host part -- doesn't
> that listen on all interfaces including the LAN ones?

Actually yes, you are right, my bad.

That needs to be fixed to use 127.0.0.1 for sure.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

Re: [Qemu-devel] [RFC 00/15] QMP: out-of-band (OOB) execution support

[Dr. David Alan Gilbert]

* Daniel P. Berrange (berra...@redhat.com) wrote:
> On Fri, Sep 15, 2017 at 11:49:26AM +0100, Stefan Hajnoczi wrote:
> > On Fri, Sep 15, 2017 at 11:50:57AM +0800, Peter Xu wrote:
> > > On Thu, Sep 14, 2017 at 04:19:11PM +0100, Stefan Hajnoczi wrote:
> > > > On Thu, Sep 14, 2017 at 01:15:09PM +0200, Marc-André Lureau wrote:
> > > > > There should be a limit in the number of requests the thread can
> > > > > queue. Before the patch, the limit was enforced by system socket
> > > > > buffering I think. Now, should oob commands still be processed even if
> > > > > the queue is full? If so, the thread can't be suspended.
> > > > 
> > > > I agree.
> > > > 
> > > > Memory usage must be bounded.  The number of requests is less important
> > > > than the amount of memory consumed by them.
> > > > 
> > > > Existing QMP clients that send multiple QMP commands without waiting for
> > > > replies need to rethink their strategy because OOB commands cannot be
> > > > processed if queued non-OOB commands consume too much memory.
> > > 
> > > Thanks for pointing out this.  Yes the memory usage problem is valid,
> > > as Markus pointed out as well in previous discussions (in "Flow
> > > Control" section of that long reply).  Hopefully this series basically
> > > can work from design prospective, then I'll add this flow control in
> > > next version.
> > > 
> > > Regarding to what we should do if the limit is reached: Markus
> > > provided a few options, but the one I prefer most is that we don't
> > > respond, but send an event showing that a command is dropped.
> > > However, I would like it not queued, but a direct reply (after all,
> > > it's an event, and we should not need to care much on ordering of it).
> > > Then we can get rid of the babysitting of those "to be failed"
> > > requests asap, meanwhile we don't lose anything IMHO.
> > > 
> > > I think I also missed at least a unit test for this new interface.
> > > Again, I'll add it after the whole idea is proved solid.  Thanks,
> > 
> > Another solution: the server reports available receive buffer space to
> > the client.  The server only guarantees immediate OOB processing when
> > the client stays within the receive buffer size.
> > 
> > Clients wishing to take advantage of OOB must query the receive buffer
> > size and make sure to leave enough room.
> 
> I don't think having to query it ahead of time is particularly nice,
> and of course it is inherantly racy.
> 
> I would just have QEMU emit an event when it pausing processing of the
> incoming commands due to a full queue.  If the event includes the ID
> of the last queued command, the client will know which (if any) of
> its outstanding commands are delayed. Another even can be sent when
> it restarts reading.

Hmm and now we're implementing flow control!

a) What exactly is the current semantics/buffer sizes?
b) When do clients send multiple QMP commands on one channel without
waiting for the response to the previous command?
c) Would one queue entry for each class of commands/channel work
  (Where a class of commands is currently 'normal' and 'oob')

Dave

> Regards,
> Daniel
> -- 
> |: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org -o-https://fstop138.berrange.com :|
> |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

Re: [Qemu-devel] [PULL v4 00/38] Test and build patches

[Peter Maydell]

On 15 September 2017 at 12:40, Daniel P. Berrange  wrote:
> IIUC, the public part of the key gets exposed to the guest images via
> cloud-init metadata. During boot the guest read this metadata and add
> the public key to authorized_keys. The private key is used by the test
> suite on the host so that it can now login to the guests.
>
> So the risk here is that if these guests were exposed to the LAN in any
> way, someone could grab our private key and login to these guests.
>
> What saves us is that the VMs are run with user mode slirp networking
> so AFAICT, aren't exposed to the LAN.

If I'm reading the right bit of the script we run QEMU with a
hostfwd specification using 0.0.0.0 as the host part -- doesn't
that listen on all interfaces including the LAN ones?

thanks
-- PMM

Re: [Qemu-devel] [PATCH RFC 1/1] s390x/ccw: create s390 phb for compat reasons as well

[David Hildenbrand]

On 15.09.2017 12:14, Cornelia Huck wrote:
> d32bd032d8 ("s390x/ccw: create s390 phb conditionally") made
> registering the s390 pci host bridge conditional on presense
> of the zpci facility bit. Sadly, that breaks migration from
> some old machines.
> 
> Create the s390 phb if we need it for compat reasons, even if
> we don't provide the zpci facility.
> 
> Fixes: d32bd032d8 ("s390x/ccw: create s390 phb conditionally")
> Signed-off-by: Cornelia Huck 
> ---
>  hw/s390x/s390-virtio-ccw.c | 6 +-
>  include/hw/s390x/s390-virtio-ccw.h | 1 +
>  2 files changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
> index 0471407187..7e3148eb4a 100644
> --- a/hw/s390x/s390-virtio-ccw.c
> +++ b/hw/s390x/s390-virtio-ccw.c
> @@ -269,6 +269,8 @@ static void s390_create_virtio_net(BusState *bus, const 
> char *name)
>  }
>  }
>  
> +static S390CcwMachineClass *get_machine_class(void);
> +
>  static void ccw_init(MachineState *machine)
>  {
>  int ret;
> @@ -288,7 +290,7 @@ static void ccw_init(MachineState *machine)
>machine->initrd_filename, "s390-ccw.img",
>"s390-netboot.img", true);
>  
> -if (s390_has_feat(S390_FEAT_ZPCI)) {
> +if (s390_has_feat(S390_FEAT_ZPCI) || get_machine_class()->pci_compat) {
>  DeviceState *dev = qdev_create(NULL, TYPE_S390_PCI_HOST_BRIDGE);
>  object_property_add_child(qdev_get_machine(),
>TYPE_S390_PCI_HOST_BRIDGE,
> @@ -429,6 +431,7 @@ static void ccw_machine_class_init(ObjectClass *oc, void 
> *data)
>  s390mc->cpu_model_allowed = true;
>  s390mc->css_migration_enabled = true;
>  s390mc->gs_allowed = true;
> +s390mc->pci_compat = false;
>  mc->init = ccw_init;
>  mc->reset = s390_machine_reset;
>  mc->hot_add_cpu = s390_hot_add_cpu;
> @@ -784,6 +787,7 @@ static void ccw_machine_2_7_class_options(MachineClass 
> *mc)
>  S390CcwMachineClass *s390mc = S390_MACHINE_CLASS(mc);
>  
>  s390mc->cpu_model_allowed = false;
> +s390mc->pci_compat = pci_available;
>  ccw_machine_2_8_class_options(mc);
>  SET_MACHINE_COMPAT(mc, CCW_COMPAT_2_7);
>  }
> diff --git a/include/hw/s390x/s390-virtio-ccw.h 
> b/include/hw/s390x/s390-virtio-ccw.h
> index a9a90c2022..9978c89e90 100644
> --- a/include/hw/s390x/s390-virtio-ccw.h
> +++ b/include/hw/s390x/s390-virtio-ccw.h
> @@ -41,6 +41,7 @@ typedef struct S390CcwMachineClass {
>  bool cpu_model_allowed;
>  bool css_migration_enabled;
>  bool gs_allowed;
> +bool pci_compat;
>  } S390CcwMachineClass;
>  
>  /* runtime-instrumentation allowed by the machine */
> 

As an alternative, simply

diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c
index 0f28ebd162..0f22efc3b6 100644
--- a/target/s390x/cpu_models.c
+++ b/target/s390x/cpu_models.c
@@ -195,6 +195,8 @@ bool s390_has_feat(S390Feat feat)
 return true;
 }
 }
+if (feat == S390_FEAT_ZPCI)
+return true;
 #endif
 return 0;
 }


(this is also the way we handle other features without cpu model support
-especially if cpu model support is disabled for older machines)

-- 

Thanks,

David

Re: [Qemu-devel] [PATCH v7 05/13] tests: Add vm test lib

[Fam Zheng]

On Fri, 09/15 12:37, Alex Bennée wrote:
> 
> Fam Zheng  writes:
> 
> > This is the common code to implement a "VM test" to
> >
> >   1) Download and initialize a pre-defined VM that has necessary
> >   dependencies to build QEMU and SSH access.
> >
> >   2) Archive $SRC_PATH to a .tar file.
> >
> >   3) Boot the VM, and pass the source tar file to the guest.
> >
> >   4) SSH into the VM, untar the source tarball, build from the source.
> >
> > Signed-off-by: Fam Zheng 
> > ---
> >  tests/vm/basevm.py | 256 
> > +
> >  1 file changed, 256 insertions(+)
> >  create mode 100755 tests/vm/basevm.py
> >
> > diff --git a/tests/vm/basevm.py b/tests/vm/basevm.py
> > new file mode 100755
> > index 00..e4603f3fba
> > --- /dev/null
> > +++ b/tests/vm/basevm.py
> > @@ -0,0 +1,256 @@
> > +#!/usr/bin/env python
> > +#
> > +# VM testing base class
> > +#
> > +# Copyright 2017 Red Hat Inc.
> > +#
> > +# Authors:
> > +#  Fam Zheng 
> > +#
> > +# This code is licensed under the GPL version 2 or later.  See
> > +# the COPYING file in the top-level directory.
> > +#
> > +
> > +import os
> > +import sys
> > +import logging
> > +import time
> > +import datetime
> > +sys.path.append(os.path.join(os.path.dirname(__file__), "..", "..", 
> > "scripts"))
> > +from qemu import QEMUMachine
> > +import subprocess
> > +import hashlib
> > +import optparse
> > +import atexit
> > +import tempfile
> > +import shutil
> > +import multiprocessing
> > +import traceback
> > +
> > +SSH_KEY = open(os.path.join(od.path.dirname(__file__),
> > +   "..", "keys", "id_rsa")).read()
> > +SSH_PUB_KEY = open(os.path.join(od.path.dirname(__file__),
> > +   "..", "keys", "id_rsa.pub")).read()
> 
> Hmm I don't think this was tested:
> 
> 12:35:56 [alex@zen:~/l/q/qemu.git] review/fam-vm-build-test-v7(+2/-2) ± make 
> vm-build-netbsd
> CHK version_gen.h
> VM-IMAGE netbsd
> Traceback (most recent call last):
>   File "/home/alex/lsrc/qemu/qemu.git/tests/vm/netbsd", line 17, in 
> import basevm
>   File "/home/alex/lsrc/qemu/qemu.git/tests/vm/basevm.py", line 30, in 
> 
> SSH_KEY = open(os.path.join(od.path.dirname(__file__),
> NameError: name 'od' is not defined
> /home/alex/lsrc/qemu/qemu.git/tests/vm/Makefile.include:23: recipe for target 
> 'tests/vm/netbsd.img' failed

Right, I tested the fixed version (s/od/os).

Fam

Re: [Qemu-devel] [PATCH] dma/i82374: avoid double creation of i82374 device

[Eduardo Otubo]

On Fri, Sep 15, 2017 at 12:18:11PM +0200, Paolo Bonzini wrote:
> On 15/09/2017 11:06, Eduardo Otubo wrote:
> > QEMU fails when used with the following command line:
> > 
> >   ./ppc64-softmmu/qemu-system-ppc64 -S -machine 40p,accel=tcg -device i82374
> >   qemu-system-ppc64: hw/isa/isa-bus.c:110: isa_bus_dma: Assertion 
> > `!bus->dma[0] && !bus->dma[1]' failed.
> >   Aborted (core dumped)
> > 
> > The 40p machine type already creates the device i82374. If specified in the
> > command line, it will try to create it again, hence generating the error. 
> > The
> > function isa_bus_dma() isn't supposed to be called twice for the same bus. 
> > One
> > way to avoid this problem is to set user_creatable=false.
> > 
> > A possible fix in a near future would be making
> > isa_bus_dma()/DMA_init()/i82374_realize() return an error instead of 
> > asserting
> > as well.
> > 
> > Signed-off-by: Eduardo Otubo 
> > ---
> >  hw/dma/i82374.c | 5 +
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/hw/dma/i82374.c b/hw/dma/i82374.c
> > index 6c0f975df0..e76dea8dc7 100644
> > --- a/hw/dma/i82374.c
> > +++ b/hw/dma/i82374.c
> > @@ -139,6 +139,11 @@ static void i82374_class_init(ObjectClass *klass, void 
> > *data)
> >  dc->realize = i82374_realize;
> >  dc->vmsd = &vmstate_i82374;
> >  dc->props = i82374_properties;
> > +dc->user_creatable = false;
> > +/*
> > + * Reason: i82374_realize() crashes (assertion failure inside 
> > isa_bus_dma()
> > + * if the device is instantiated twice.
> > + */
> >  }
> >  
> >  static const TypeInfo i82374_info = {
> > 
> 
> This breaks "make check", doesn't it?
> 
> v2 should be the one that returns an error instead of asserting.

I guess I have misunderstood, then. I'll work on a patch to propagate
the error then.

Thanks,

-- 
Eduardo Otubo
Senior Software Engineer @ RedHat

Re: [Qemu-devel] [PULL v4 00/38] Test and build patches

[Daniel P. Berrange]

On Fri, Sep 15, 2017 at 11:55:44AM +0100, Peter Maydell wrote:
> On 15 September 2017 at 10:02, Fam Zheng  wrote:
> > The following changes since commit 04ef33052c205170c92df21ca0b4be4f3b102188:
> >
> >   tcg/tci: do not use ldst label (never implemented) (2017-09-11 19:24:05 
> > +0100)
> >
> > are available in the git repository at:
> >
> >   git://github.com/famz/qemu.git tags/test-and-build-pull-request
> >
> > for you to fetch changes up to be78fe670401af14e6d63fce5c5467f751207871:
> >
> >   buildsys: Move rdma libs to per object (2017-09-15 15:05:24 +0800)
> >
> > 
> >
> > 
> >
> > Alex Bennée (4):
> >   docker: ensure NOUSER for travis images
> >   docker: docker.py make --no-cache skip checksum test
> >   docker: don't install device-tree-compiler build-deps in travis.docker
> >   docker: reduce noise when building travis.docker
> >
> > Fam Zheng (34):
> >   docker: Update ubuntu image
> >   docker: Enable features explicitly in test-full
> >   tests/docker: Clean up paths
> >   gitignore: Ignore vm test images
> >   qemu.py: Add "wait()" method
> >   scripts: Add archive-source.sh
> >   tests: Add a test key pair
> 
> So, before I commit an ssh private key to our git repo,
> can you explain why it's ok that this is public? The
> commit message for the relevant patch doesn't really say.

IIUC, the public part of the key gets exposed to the guest images via
cloud-init metadata. During boot the guest read this metadata and add
the public key to authorized_keys. The private key is used by the test
suite on the host so that it can now login to the guests.

So the risk here is that if these guests were exposed to the LAN in any
way, someone could grab our private key and login to these guests.

What saves us is that the VMs are run with user mode slirp networking
so AFAICT, aren't exposed to the LAN.  So as long as we don't change
this to any kind of real networking, I think its acceptable to have
the private key in it and doesn't expose developer's workstations to
undue risk and avoids consuming system entropy to generate new keys
during build.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

Re: [Qemu-devel] [PATCH v7 05/13] tests: Add vm test lib

[Alex Bennée]

Fam Zheng  writes:

> This is the common code to implement a "VM test" to
>
>   1) Download and initialize a pre-defined VM that has necessary
>   dependencies to build QEMU and SSH access.
>
>   2) Archive $SRC_PATH to a .tar file.
>
>   3) Boot the VM, and pass the source tar file to the guest.
>
>   4) SSH into the VM, untar the source tarball, build from the source.
>
> Signed-off-by: Fam Zheng 
> ---
>  tests/vm/basevm.py | 256 
> +
>  1 file changed, 256 insertions(+)
>  create mode 100755 tests/vm/basevm.py
>
> diff --git a/tests/vm/basevm.py b/tests/vm/basevm.py
> new file mode 100755
> index 00..e4603f3fba
> --- /dev/null
> +++ b/tests/vm/basevm.py
> @@ -0,0 +1,256 @@
> +#!/usr/bin/env python
> +#
> +# VM testing base class
> +#
> +# Copyright 2017 Red Hat Inc.
> +#
> +# Authors:
> +#  Fam Zheng 
> +#
> +# This code is licensed under the GPL version 2 or later.  See
> +# the COPYING file in the top-level directory.
> +#
> +
> +import os
> +import sys
> +import logging
> +import time
> +import datetime
> +sys.path.append(os.path.join(os.path.dirname(__file__), "..", "..", 
> "scripts"))
> +from qemu import QEMUMachine
> +import subprocess
> +import hashlib
> +import optparse
> +import atexit
> +import tempfile
> +import shutil
> +import multiprocessing
> +import traceback
> +
> +SSH_KEY = open(os.path.join(od.path.dirname(__file__),
> +   "..", "keys", "id_rsa")).read()
> +SSH_PUB_KEY = open(os.path.join(od.path.dirname(__file__),
> +   "..", "keys", "id_rsa.pub")).read()

Hmm I don't think this was tested:

12:35:56 [alex@zen:~/l/q/qemu.git] review/fam-vm-build-test-v7(+2/-2) ± make 
vm-build-netbsd
CHK version_gen.h
VM-IMAGE netbsd
Traceback (most recent call last):
  File "/home/alex/lsrc/qemu/qemu.git/tests/vm/netbsd", line 17, in 
import basevm
  File "/home/alex/lsrc/qemu/qemu.git/tests/vm/basevm.py", line 30, in 
SSH_KEY = open(os.path.join(od.path.dirname(__file__),
NameError: name 'od' is not defined
/home/alex/lsrc/qemu/qemu.git/tests/vm/Makefile.include:23: recipe for target 
'tests/vm/netbsd.img' failed


> +
> +class BaseVM(object):
> +GUEST_USER = "qemu"
> +GUEST_PASS = "qemupass"
> +ROOT_PASS = "qemupass"
> +
> +# The script to run in the guest that builds QEMU
> +BUILD_SCRIPT = ""
> +# The guest name, to be overridden by subclasses
> +name = "#base"
> +def __init__(self, debug=False, vcpus=None):
> +self._guest = None
> +self._tmpdir = tempfile.mkdtemp(prefix="vm-test-", suffix=".tmp", 
> dir=".")
> +atexit.register(shutil.rmtree, self._tmpdir)
> +
> +self._ssh_key_file = os.path.join(self._tmpdir, "id_rsa")
> +open(self._ssh_key_file, "w").write(SSH_KEY)
> +subprocess.check_call(["chmod", "600", self._ssh_key_file])
> +
> +self._ssh_pub_key_file = os.path.join(self._tmpdir, "id_rsa.pub")
> +open(self._ssh_pub_key_file, "w").write(SSH_PUB_KEY)
> +
> +self.debug = debug
> +self._stderr = sys.stderr
> +self._devnull = open(os.devnull, "w")
> +if self.debug:
> +self._stdout = sys.stdout
> +else:
> +self._stdout = self._devnull
> +self._args = [ \
> +"-nodefaults", "-m", "2G",
> +"-cpu", "host",
> +"-netdev", "user,id=vnet,hostfwd=:0.0.0.0:0-:22",
> +"-device", "virtio-net-pci,netdev=vnet",
> +"-vnc", ":0,to=20",
> +"-serial", "file:%s" % os.path.join(self._tmpdir, "serial.out")]
> +if vcpus:
> +self._args += ["-smp", str(vcpus)]
> +if os.access("/dev/kvm", os.R_OK | os.W_OK):
> +self._args += ["-enable-kvm"]
> +else:
> +logging.info("KVM not available, not using -enable-kvm")
> +self._data_args = []
> +
> +def _download_with_cache(self, url, sha256sum=None):
> +def check_sha256sum(fname):
> +if not sha256sum:
> +return True
> +checksum = subprocess.check_output(["sha256sum", 
> fname]).split()[0]
> +return sha256sum == checksum
> +
> +cache_dir = os.path.expanduser("~/.cache/qemu-vm/download")
> +if not os.path.exists(cache_dir):
> +os.makedirs(cache_dir)
> +fname = os.path.join(cache_dir, hashlib.sha1(url).hexdigest())
> +if os.path.exists(fname) and check_sha256sum(fname):
> +return fname
> +logging.debug("Downloading %s to %s...", url, fname)
> +subprocess.check_call(["wget", "-c", url, "-O", fname + ".download"],
> +  stdout=self._stdout, stderr=self._stderr)
> +os.rename(fname + ".download", fname)
> +return fname
> +
> +def _ssh_do(self, user, cmd, check, interactive=False):
> +ssh_cmd = ["ssh", "-q",
> +   "-o", "StrictHostKeyChecking=no",
> +   "-o"

Re: [Qemu-devel] [PULL v4 00/38] Test and build patches

[Fam Zheng]

On Fri, 09/15 11:55, Peter Maydell wrote:
> On 15 September 2017 at 10:02, Fam Zheng  wrote:
> > The following changes since commit 04ef33052c205170c92df21ca0b4be4f3b102188:
> >
> >   tcg/tci: do not use ldst label (never implemented) (2017-09-11 19:24:05 
> > +0100)
> >
> > are available in the git repository at:
> >
> >   git://github.com/famz/qemu.git tags/test-and-build-pull-request
> >
> > for you to fetch changes up to be78fe670401af14e6d63fce5c5467f751207871:
> >
> >   buildsys: Move rdma libs to per object (2017-09-15 15:05:24 +0800)
> >
> > 
> >
> > 
> >
> > Alex Bennée (4):
> >   docker: ensure NOUSER for travis images
> >   docker: docker.py make --no-cache skip checksum test
> >   docker: don't install device-tree-compiler build-deps in travis.docker
> >   docker: reduce noise when building travis.docker
> >
> > Fam Zheng (34):
> >   docker: Update ubuntu image
> >   docker: Enable features explicitly in test-full
> >   tests/docker: Clean up paths
> >   gitignore: Ignore vm test images
> >   qemu.py: Add "wait()" method
> >   scripts: Add archive-source.sh
> >   tests: Add a test key pair
> 
> So, before I commit an ssh private key to our git repo,
> can you explain why it's ok that this is public? The
> commit message for the relevant patch doesn't really say.

It's under tests/, and the key is only used to access a temporarily spawned test
VM.

Fam

Re: [Qemu-devel] [RFC 00/15] QMP: out-of-band (OOB) execution support

[Daniel P. Berrange]

On Fri, Sep 15, 2017 at 11:49:26AM +0100, Stefan Hajnoczi wrote:
> On Fri, Sep 15, 2017 at 11:50:57AM +0800, Peter Xu wrote:
> > On Thu, Sep 14, 2017 at 04:19:11PM +0100, Stefan Hajnoczi wrote:
> > > On Thu, Sep 14, 2017 at 01:15:09PM +0200, Marc-André Lureau wrote:
> > > > There should be a limit in the number of requests the thread can
> > > > queue. Before the patch, the limit was enforced by system socket
> > > > buffering I think. Now, should oob commands still be processed even if
> > > > the queue is full? If so, the thread can't be suspended.
> > > 
> > > I agree.
> > > 
> > > Memory usage must be bounded.  The number of requests is less important
> > > than the amount of memory consumed by them.
> > > 
> > > Existing QMP clients that send multiple QMP commands without waiting for
> > > replies need to rethink their strategy because OOB commands cannot be
> > > processed if queued non-OOB commands consume too much memory.
> > 
> > Thanks for pointing out this.  Yes the memory usage problem is valid,
> > as Markus pointed out as well in previous discussions (in "Flow
> > Control" section of that long reply).  Hopefully this series basically
> > can work from design prospective, then I'll add this flow control in
> > next version.
> > 
> > Regarding to what we should do if the limit is reached: Markus
> > provided a few options, but the one I prefer most is that we don't
> > respond, but send an event showing that a command is dropped.
> > However, I would like it not queued, but a direct reply (after all,
> > it's an event, and we should not need to care much on ordering of it).
> > Then we can get rid of the babysitting of those "to be failed"
> > requests asap, meanwhile we don't lose anything IMHO.
> > 
> > I think I also missed at least a unit test for this new interface.
> > Again, I'll add it after the whole idea is proved solid.  Thanks,
> 
> Another solution: the server reports available receive buffer space to
> the client.  The server only guarantees immediate OOB processing when
> the client stays within the receive buffer size.
> 
> Clients wishing to take advantage of OOB must query the receive buffer
> size and make sure to leave enough room.

I don't think having to query it ahead of time is particularly nice,
and of course it is inherantly racy.

I would just have QEMU emit an event when it pausing processing of the
incoming commands due to a full queue.  If the event includes the ID
of the last queued command, the client will know which (if any) of
its outstanding commands are delayed. Another even can be sent when
it restarts reading.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

[Qemu-devel] [PATCH 2/2] x86_iommu: check if machine has PCI bus

[Mohammed Gamal]

Starting qemu with
qemu-system-x86_64 -S -M isapc -device {amd|intel}-iommu
leads to a segfault. The code assume PCI bus is present and
tries to access the bus structure without checking.

Since Intel VT-d and AMDVI should only work with PCI, add a
check for PCI bus and return error if not present.

Signed-off-by: Mohammed Gamal 
---
 hw/i386/x86-iommu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/i386/x86-iommu.c b/hw/i386/x86-iommu.c
index 4d17e1f..afd8cd9 100644
--- a/hw/i386/x86-iommu.c
+++ b/hw/i386/x86-iommu.c
@@ -88,7 +88,7 @@ static void x86_iommu_realize(DeviceState *dev, Error **errp)
 PC_MACHINE(object_dynamic_cast(OBJECT(ms), TYPE_PC_MACHINE));
 QLIST_INIT(&x86_iommu->iec_notifiers);
 
-if (!pcms) {
+if (!pcms || !pcms->bus) {
 error_setg(errp, "Machine-type '%s' not supported by iommu",
mc->name);
 return;
-- 
1.8.3.1

Re: [Qemu-devel] [RFC 00/15] QMP: out-of-band (OOB) execution support

[Marc-André Lureau]

Hi

On Thu, Sep 14, 2017 at 9:46 PM, Peter Xu  wrote:
> On Thu, Sep 14, 2017 at 07:53:15PM +0100, Dr. David Alan Gilbert wrote:
>> * Marc-André Lureau (marcandre.lur...@gmail.com) wrote:
>> > Hi
>> >
>> > On Thu, Sep 14, 2017 at 9:50 AM, Peter Xu  wrote:
>> > > This series was born from this one:
>> > >
>> > >   https://lists.gnu.org/archive/html/qemu-devel/2017-08/msg04310.html
>> > >
>> > > The design comes from Markus, and also the whole-bunch-of discussions
>> > > in previous thread.  My heartful thanks to Markus, Daniel, Dave,
>> > > Stefan, etc. on discussing the topic (...again!), providing shiny
>> > > ideas and suggestions.  Finally we got such a solution that seems to
>> > > satisfy everyone.
>> > >
>> > > I re-started the versioning since this series is totally different
>> > > from previous one.  Now it's version 1.
>> > >
>> > > In case new reviewers come along the way without reading previous
>> > > discussions, I will try to do a summary on what this is all about.
>> > >
>> > > What is OOB execution?
>> > > ==
>> > >
>> > > It's the shortcut of Out-Of-Band execution, its name is given by
>> > > Markus.  It's a way to quickly execute a QMP request.  Say, originally
>> > > QMP is going throw these steps:
>> > >
>> > >   JSON Parser --> QMP Dispatcher --> Respond
>> > >   /|\(2)(3) |
>> > >(1) |   \|/ (4)
>> > >+-  main thread  +
>> > >
>> > > The requests are executed by the so-called QMP-dispatcher after the
>> > > JSON is parsed.  If OOB is on, we run the command directly in the
>> > > parser and quickly returns.
>> >
>> > All commands should have the "id" field mandatory in this case, else
>> > the client will not distinguish the replies coming from the last/oob
>> > and the previous commands.
>> >
>> > This should probably be enforced upfront by client capability checks,
>> > more below.
>
> Hmm yes since the oob commands are actually running in async way,
> request ID should be needed here.  However I'm not sure whether
> enabling the whole "request ID" thing is too big for this "try to be
> small" oob change... And IMHO it suites better to be part of the whole
> async work (no matter which implementation we'll use).
>
> How about this: we make "id" mandatory for "run-oob" requests only.
> For oob commands, they will always have ID then no ordering issue, and
> we can do it async; for the rest of non-oob commands, we still allow
> them to go without ID, and since they are not oob, they'll always be
> done in order as well.  Would this work?

This mixed-mode is imho more complicated to deal with than having the
protocol enforced one way or the other, but that should work.

>
>> >
>> > > Yeah I know in current code the parser calls dispatcher directly
>> > > (please see handle_qmp_command()).  However it's not true again after
>> > > this series (parser will has its own IO thread, and dispatcher will
>> > > still be run in main thread).  So this OOB does brings something
>> > > different.
>> > >
>> > > There are more details on why OOB and the difference/relationship
>> > > between OOB, async QMP, block/general jobs, etc.. but IMHO that's
>> > > slightly out of topic (and believe me, it's not easy for me to
>> > > summarize that).  For more information, please refers to [1].
>> > >
>> > > Summary ends here.
>> > >
>> > > Some Implementation Details
>> > > ===
>> > >
>> > > Again, I mentioned that the old QMP workflow is this:
>> > >
>> > >   JSON Parser --> QMP Dispatcher --> Respond
>> > >   /|\(2)(3) |
>> > >(1) |   \|/ (4)
>> > >+-  main thread  +
>> > >
>> > > What this series does is, firstly:
>> > >
>> > >   JSON Parser QMP Dispatcher --> Respond
>> > >   /|\ |   /|\   (4) |
>> > >|  | (2)| (3)|  (5)
>> > >(1) |  +->  |   \|/
>> > >+-  main thread  <---+
>> > >
>> > > And further:
>> > >
>> > >queue/kick
>> > >  JSON Parser ==> QMP Dispatcher --> Respond
>> > >  /|\ | (3)   /|\(4)|
>> > >   (1) |  | (2)||  (5)
>> > >   | \|/   |   \|/
>> > > IO thread main thread  <---+
>> >
>> > Is the queue per monitor or per client?
>
> The queue is currently global. I think yes maybe at least we can do it
> per monitor, but I am not sure whether that is urgent or can be
> postponed.  After all now QMPRequest (please refer to patch 11) is
> defined as (mon, id, req) tuple, so at least "id" namespace is
> per-monitor.
>
>> > And is the dispatching going
>> > to be processed even if the client is disconnected, and are new
>> > clients going to receive the replies from previous clients
>> > commands?
>
> [1]
>
> (w

[Qemu-devel] [PATCH 0/2] x86_iommu: Fix segfault when starting on non-PCI machines

[Mohammed Gamal]

Starting qemu with
qemu-system-x86_64 -S -M isapc -device {amd|intel}-iommu
leads to a segfault. The code assume PCI bus is present and
tries to access the bus structure without checking.

The patch series moves the error checks from vtd_realize()
and amdvi_realize() to the generic x86_iommu_realize() and
adds a check for PCI bus presence.

Mohammed Gamal (2):
  x86_iommu: Move machine check to x86_iommu_realize()
  x86_iommu: check if machine has PCI bus

 hw/i386/amd_iommu.c   | 10 +-
 hw/i386/intel_iommu.c | 10 +-
 hw/i386/x86-iommu.c   | 13 +
 3 files changed, 15 insertions(+), 18 deletions(-)

-- 
1.8.3.1

[Qemu-devel] [PATCH 1/2] x86_iommu: Move machine check to x86_iommu_realize()

[Mohammed Gamal]

Instead of having the same error checks in vtd_realize()
and amdvi_realize(), move that over to the generic
x86_iommu_realize().

Signed-off-by: Mohammed Gamal 
---
 hw/i386/amd_iommu.c   | 10 +-
 hw/i386/intel_iommu.c | 10 +-
 hw/i386/x86-iommu.c   | 13 +
 3 files changed, 15 insertions(+), 18 deletions(-)

diff --git a/hw/i386/amd_iommu.c b/hw/i386/amd_iommu.c
index 334938a..839f01f 100644
--- a/hw/i386/amd_iommu.c
+++ b/hw/i386/amd_iommu.c
@@ -1141,18 +1141,10 @@ static void amdvi_realize(DeviceState *dev, Error **err)
 AMDVIState *s = AMD_IOMMU_DEVICE(dev);
 X86IOMMUState *x86_iommu = X86_IOMMU_DEVICE(dev);
 MachineState *ms = MACHINE(qdev_get_machine());
-MachineClass *mc = MACHINE_GET_CLASS(ms);
 PCMachineState *pcms =
 PC_MACHINE(object_dynamic_cast(OBJECT(ms), TYPE_PC_MACHINE));
-PCIBus *bus;
+PCIBus *bus = pcms->bus;
 
-if (!pcms) {
-error_setg(err, "Machine-type '%s' not supported by amd-iommu",
-   mc->name);
-return;
-}
-
-bus = pcms->bus;
 s->iotlb = g_hash_table_new_full(amdvi_uint64_hash,
  amdvi_uint64_equal, g_free, g_free);
 
diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
index 3a5bb0b..aa01812 100644
--- a/hw/i386/intel_iommu.c
+++ b/hw/i386/intel_iommu.c
@@ -3027,20 +3027,12 @@ static bool vtd_decide_config(IntelIOMMUState *s, Error 
**errp)
 static void vtd_realize(DeviceState *dev, Error **errp)
 {
 MachineState *ms = MACHINE(qdev_get_machine());
-MachineClass *mc = MACHINE_GET_CLASS(ms);
 PCMachineState *pcms =
 PC_MACHINE(object_dynamic_cast(OBJECT(ms), TYPE_PC_MACHINE));
-PCIBus *bus;
+PCIBus *bus = pcms->bus;
 IntelIOMMUState *s = INTEL_IOMMU_DEVICE(dev);
 X86IOMMUState *x86_iommu = X86_IOMMU_DEVICE(dev);
 
-if (!pcms) {
-error_setg(errp, "Machine-type '%s' not supported by intel-iommu",
-   mc->name);
-return;
-}
-
-bus = pcms->bus;
 x86_iommu->type = TYPE_INTEL;
 
 if (!vtd_decide_config(s, errp)) {
diff --git a/hw/i386/x86-iommu.c b/hw/i386/x86-iommu.c
index 293caf8..4d17e1f 100644
--- a/hw/i386/x86-iommu.c
+++ b/hw/i386/x86-iommu.c
@@ -21,6 +21,8 @@
 #include "hw/sysbus.h"
 #include "hw/boards.h"
 #include "hw/i386/x86-iommu.h"
+#include "hw/i386/pc.h"
+#include "qapi/error.h"
 #include "qemu/error-report.h"
 #include "trace.h"
 
@@ -80,7 +82,18 @@ static void x86_iommu_realize(DeviceState *dev, Error **errp)
 {
 X86IOMMUState *x86_iommu = X86_IOMMU_DEVICE(dev);
 X86IOMMUClass *x86_class = X86_IOMMU_GET_CLASS(dev);
+MachineState *ms = MACHINE(qdev_get_machine());
+MachineClass *mc = MACHINE_GET_CLASS(ms);
+PCMachineState *pcms =
+PC_MACHINE(object_dynamic_cast(OBJECT(ms), TYPE_PC_MACHINE));
 QLIST_INIT(&x86_iommu->iec_notifiers);
+
+if (!pcms) {
+error_setg(errp, "Machine-type '%s' not supported by iommu",
+   mc->name);
+return;
+}
+
 if (x86_class->realize) {
 x86_class->realize(dev, errp);
 }
-- 
1.8.3.1

Re: [Qemu-devel] [PULL v4 00/38] Test and build patches

[Peter Maydell]

On 15 September 2017 at 10:02, Fam Zheng  wrote:
> The following changes since commit 04ef33052c205170c92df21ca0b4be4f3b102188:
>
>   tcg/tci: do not use ldst label (never implemented) (2017-09-11 19:24:05 
> +0100)
>
> are available in the git repository at:
>
>   git://github.com/famz/qemu.git tags/test-and-build-pull-request
>
> for you to fetch changes up to be78fe670401af14e6d63fce5c5467f751207871:
>
>   buildsys: Move rdma libs to per object (2017-09-15 15:05:24 +0800)
>
> 
>
> 
>
> Alex Bennée (4):
>   docker: ensure NOUSER for travis images
>   docker: docker.py make --no-cache skip checksum test
>   docker: don't install device-tree-compiler build-deps in travis.docker
>   docker: reduce noise when building travis.docker
>
> Fam Zheng (34):
>   docker: Update ubuntu image
>   docker: Enable features explicitly in test-full
>   tests/docker: Clean up paths
>   gitignore: Ignore vm test images
>   qemu.py: Add "wait()" method
>   scripts: Add archive-source.sh
>   tests: Add a test key pair

So, before I commit an ssh private key to our git repo,
can you explain why it's ok that this is public? The
commit message for the relevant patch doesn't really say.

thanks
-- PMM

Re: [Qemu-devel] [PATCH v7 04/13] tests: Add a test key pair

[Alex Bennée]

Fam Zheng  writes:

> This will be used by setup test user ssh.
>
> Signed-off-by: Fam Zheng 

Reviewed-by: Alex Bennée 

> ---
>  tests/keys/id_rsa | 27 +++
>  tests/keys/id_rsa.pub |  1 +
>  2 files changed, 28 insertions(+)
>  create mode 100644 tests/keys/id_rsa
>  create mode 100644 tests/keys/id_rsa.pub
>
> diff --git a/tests/keys/id_rsa b/tests/keys/id_rsa
> new file mode 100644
> index 00..3a3787154b
> --- /dev/null
> +++ b/tests/keys/id_rsa
> @@ -0,0 +1,27 @@
> +BEGIN RSA PRIVATE KEY-
> +MIIEowIBAAKCAQEAopAuOlmLV6LVHdFBj8/eeOwI9CqguIJPp7eAQSZvOiB4Ag/R
> +coEhl/RBbrV5Yc/SmSD4PTpJO/iM10RwliNjDb4a3I8q3sykRJu9c9PI/YsH8WN9
> ++NH2NjKPtJIcKTu287IM5JYxyB6nDoOzILbTyJ1TDR/xH6qYEfBAyiblggdjcvhA
> +RTf93QIn39F/xLypXvT1K2O9BJEsnJ8lEUvB2UXhKo/JTfSeZF8wPBeowaP9EONk
> +7b+nuJOWHGg68Ji6wVi62tjwl2Szch6lxIhZBpnV7QNRKMfYHP6eIyF4pusazzZq
> +Telsq6xI2ghecWLzb/MF5A+rklsGx2FNuJSAJwIDAQABAoIBAHHi4o/8VZNivz0x
> +cWXn8erzKV6tUoWQvW85Lj/2RiwJvSlsnYZDkx5af1CpEE2HA/pFT8PNRqsd+MWC
> +7AEy710cVsM4BYerBFYQaYxwzblaoojo88LSjVPw3h5Z0iLM8+IMVd36nwuc9dpE
> +R8TecMZ1+U4Tl6BgqkK+9xToZRdPKdjS8L5MoFhGN+xY0vRbbJbGaV9Q0IHxLBkB
> +rEBV7T1mUynneCHRUQlJQEwJmKpT8MH3IjsUXlG5YvnuuvcQJSNTaW2iDLxuOKp8
> +cxW8+qL88zpb1D5dppoIu6rlrugN0azSq70ruFJQPc/A8GQrDKoGgRQiagxNY3u+
> +vHZzXlECgYEA0dKO3gfkSxsDBb94sQwskMScqLhcKhztEa8kPxTx6Yqh+x8/scx3
> +XhJyOt669P8U1v8a/2Al+s81oZzzfQSzO1Q7gEwSrgBcRMSIoRBUw9uYcy02ngb/
> +j/ng3DGivfJztjjiSJwb46FHkJ2JR8mF2UisC6UMXk3NgFY/3vWQx78CgYEAxlcG
> +T3hfSWSmTgKRczMJuHQOX9ULfTBIqwP5VqkkkiavzigGRirzb5lgnmuTSPTpF0LB
> +XVPjR2M4q+7gzP0Dca3pocrvLEoxjwIKnCbYKnyyvnUoE9qHv4Kr+vDbgWpa2LXG
> +JbLmE7tgTCIp20jOPPT4xuDvlbzQZBJ5qCQSoZkCgYEAgrotSSihlCnAOFSTXbu4
> +CHp3IKe8xIBBNENq0eK61kcJpOxTQvOha3sSsJsU4JAM6+cFaxb8kseHIqonCj1j
> +bhOM/uJmwQJ4el/4wGDsbxriYOBKpyq1D38gGhDS1IW6kk3erl6VAb36WJ/OaGum
> +eTpN9vNeQWM4Jj2WjdNx4QECgYAwTdd6mU1TmZCrJRL5ZG+0nYc2rbMrnQvFoqUi
> +BvWiJovggHzur90zy73tNzPaq9Ls2FQxf5G1vCN8NCRJqEEjeYCR59OSDMu/EXc2
> +CnvQ9SevHOdS1oEDEjcCWZCMFzPi3XpRih1gptzQDe31uuiHjf3cqcGPzTlPdfRt
> +D8P92QKBgC4UaBvIRwREVJsdZzpIzm224Bpe8LOmA7DeTnjlT0b3lkGiBJ36/Q0p
> +VhYh/6cjX4/iuIs7gJbGon7B+YPB8scmOi3fj0+nkJAONue1mMfBNkba6qQTc6Y2
> +5mEKw2/O7/JpND7ucU3OK9plcw/qnrWDgHxl0Iz95+OzUIIagxne
> +-END RSA PRIVATE KEY-
> diff --git a/tests/keys/id_rsa.pub b/tests/keys/id_rsa.pub
> new file mode 100644
> index 00..d9888e312f
> --- /dev/null
> +++ b/tests/keys/id_rsa.pub
> @@ -0,0 +1 @@
> +ssh-rsa 
> B3NzaC1yc2EDAQABAAABAQCikC46WYtXotUd0UGPz9547Aj0KqC4gk+nt4BBJm86IHgCD9FygSGX9EFutXlhz9KZIPg9Okk7+IzXRHCWI2MNvhrcjyrezKREm71z08j9iwfxY3340fY2Mo+0khwpO7bzsgzkljHIHqcOg7MgttPInVMNH/EfqpgR8EDKJuWCB2Ny+EBFN/3dAiff0X/EvKle9PUrY70EkSycnyURS8HZReEqj8lN9J5kXzA8F6jBo/0Q42Ttv6e4k5YcaDrwmLrBWLra2PCXZLNyHqXEiFkGmdXtA1Eox9gc/p4jIXim6xrPNmpN6WyrrEjaCF5xYvNv8wXkD6uSWwbHYU24lIAn
>  qemu-test


--
Alex Bennée