[Qemu-devel] [PATCH v4 3/3] hw/gpio: Add in AST2600 specific implementation

[Rashmica Gupta]

The AST2600 has the same sets of 3.6v gpios as the AST2400 plus an
addtional two sets of 1.8V gpios.

Signed-off-by: Rashmica Gupta 
---
 hw/gpio/aspeed_gpio.c | 188 --
 slirp |   2 +-
 2 files changed, 184 insertions(+), 6 deletions(-)

diff --git a/hw/gpio/aspeed_gpio.c b/hw/gpio/aspeed_gpio.c
index bd5af81336..f781fbb6dc 100644
--- a/hw/gpio/aspeed_gpio.c
+++ b/hw/gpio/aspeed_gpio.c
@@ -167,6 +167,49 @@
 #define GPIO_3_6V_MEM_SIZE 0x1F0
 #define GPIO_3_6V_REG_ARRAY_SIZE   (GPIO_3_6V_MEM_SIZE >> 2)
 
+/* AST2600 only - 1.8V gpios */
+/*
+ * The AST2600 has same 3.6V gpios as the AST2400 (memory offsets 0x0-0x198)
+ * and addtional 1.8V gpios (memory offsets 0x800-0x9D4). We create one
+ * GPIOState for the 3.6V gpios mapped at 0x0 and another GPIOState for the
+ * 1.8V gpios mapped at 0x800.
+ */
+#define GPIO_1_8V_REG_OFFSET  0x800
+#define GPIO_1_8V_ABCD_DATA_VALUE ((0x800 - GPIO_1_8V_REG_OFFSET) >> 2)
+#define GPIO_1_8V_ABCD_DIRECTION  ((0x804 - GPIO_1_8V_REG_OFFSET) >> 2)
+#define GPIO_1_8V_ABCD_INT_ENABLE ((0x808 - GPIO_1_8V_REG_OFFSET) >> 2)
+#define GPIO_1_8V_ABCD_INT_SENS_0 ((0x80C - GPIO_1_8V_REG_OFFSET) >> 2)
+#define GPIO_1_8V_ABCD_INT_SENS_1 ((0x810 - GPIO_1_8V_REG_OFFSET) >> 2)
+#define GPIO_1_8V_ABCD_INT_SENS_2 ((0x814 - GPIO_1_8V_REG_OFFSET) >> 2)
+#define GPIO_1_8V_ABCD_INT_STATUS ((0x818 - GPIO_1_8V_REG_OFFSET) >> 2)
+#define GPIO_1_8V_ABCD_RESET_TOLERANT ((0x81C - GPIO_1_8V_REG_OFFSET) >> 2)
+#define GPIO_1_8V_E_DATA_VALUE((0x820 - GPIO_1_8V_REG_OFFSET) >> 2)
+#define GPIO_1_8V_E_DIRECTION ((0x824 - GPIO_1_8V_REG_OFFSET) >> 2)
+#define GPIO_1_8V_E_INT_ENABLE((0x828 - GPIO_1_8V_REG_OFFSET) >> 2)
+#define GPIO_1_8V_E_INT_SENS_0((0x82C - GPIO_1_8V_REG_OFFSET) >> 2)
+#define GPIO_1_8V_E_INT_SENS_1((0x830 - GPIO_1_8V_REG_OFFSET) >> 2)
+#define GPIO_1_8V_E_INT_SENS_2((0x834 - GPIO_1_8V_REG_OFFSET) >> 2)
+#define GPIO_1_8V_E_INT_STATUS((0x838 - GPIO_1_8V_REG_OFFSET) >> 2)
+#define GPIO_1_8V_E_RESET_TOLERANT((0x83C - GPIO_1_8V_REG_OFFSET) >> 2)
+#define GPIO_1_8V_ABCD_DEBOUNCE_1 ((0x840 - GPIO_1_8V_REG_OFFSET) >> 2)
+#define GPIO_1_8V_ABCD_DEBOUNCE_2 ((0x844 - GPIO_1_8V_REG_OFFSET) >> 2)
+#define GPIO_1_8V_E_DEBOUNCE_1((0x848 - GPIO_1_8V_REG_OFFSET) >> 2)
+#define GPIO_1_8V_E_DEBOUNCE_2((0x84C - GPIO_1_8V_REG_OFFSET) >> 2)
+#define GPIO_1_8V_DEBOUNCE_TIME_1 ((0x850 - GPIO_1_8V_REG_OFFSET) >> 2)
+#define GPIO_1_8V_DEBOUNCE_TIME_2 ((0x854 - GPIO_1_8V_REG_OFFSET) >> 2)
+#define GPIO_1_8V_DEBOUNCE_TIME_3 ((0x858 - GPIO_1_8V_REG_OFFSET) >> 2)
+#define GPIO_1_8V_ABCD_COMMAND_SRC_0  ((0x860 - GPIO_1_8V_REG_OFFSET) >> 2)
+#define GPIO_1_8V_ABCD_COMMAND_SRC_1  ((0x864 - GPIO_1_8V_REG_OFFSET) >> 2)
+#define GPIO_1_8V_E_COMMAND_SRC_0 ((0x868 - GPIO_1_8V_REG_OFFSET) >> 2)
+#define GPIO_1_8V_E_COMMAND_SRC_1 ((0x86C - GPIO_1_8V_REG_OFFSET) >> 2)
+#define GPIO_1_8V_ABCD_DATA_READ  ((0x8C0 - GPIO_1_8V_REG_OFFSET) >> 2)
+#define GPIO_1_8V_E_DATA_READ ((0x8C4 - GPIO_1_8V_REG_OFFSET) >> 2)
+#define GPIO_1_8V_ABCD_INPUT_MASK ((0x9D0 - GPIO_1_8V_REG_OFFSET) >> 2)
+#define GPIO_1_8V_E_INPUT_MASK((0x9D4 - GPIO_1_8V_REG_OFFSET) >> 2)
+#define GPIO_1_8V_MEM_SIZE0x9D8
+#define GPIO_1_8V_REG_ARRAY_SIZE  ((GPIO_1_8V_MEM_SIZE - \
+  GPIO_1_8V_REG_OFFSET) >> 2)
+
 static int aspeed_evaluate_irq(GPIOSets *regs, int gpio_prev_high, int gpio)
 {
 uint32_t falling_edge = 0, rising_edge = 0;
@@ -465,6 +508,39 @@ static const AspeedGPIOReg 
aspeed_3_6v_gpios[GPIO_3_6V_REG_ARRAY_SIZE] = {
 [GPIO_AC_INPUT_MASK] = { 7, gpio_reg_input_mask },
 };
 
+static const AspeedGPIOReg aspeed_1_8v_gpios[GPIO_1_8V_REG_ARRAY_SIZE] = {
+/* 1.8V Set ABCD */
+[GPIO_1_8V_ABCD_DATA_VALUE] = {0, gpio_reg_data_value},
+[GPIO_1_8V_ABCD_DIRECTION] =  {0, gpio_reg_direction},
+[GPIO_1_8V_ABCD_INT_ENABLE] = {0, gpio_reg_int_enable},
+[GPIO_1_8V_ABCD_INT_SENS_0] = {0, gpio_reg_int_sens_0},
+[GPIO_1_8V_ABCD_INT_SENS_1] = {0, gpio_reg_int_sens_1},
+[GPIO_1_8V_ABCD_INT_SENS_2] = {0, gpio_reg_int_sens_2},
+[GPIO_1_8V_ABCD_INT_STATUS] = {0, gpio_reg_int_status},
+[GPIO_1_8V_ABCD_RESET_TOLERANT] = {0, gpio_reg_reset_tolerant},
+[GPIO_1_8V_ABCD_DEBOUNCE_1] = {0, gpio_reg_debounce_1},
+[GPIO_1_8V_ABCD_DEBOUNCE_2] = {0, gpio_reg_debounce_2},
+[GPIO_1_8V_ABCD_COMMAND_SRC_0] =  {0, gpio_reg_cmd_source_0},
+[GPIO_1_8V_ABCD_COMMAND_SRC_1] =  {0, gpio_reg_cmd_source_1},
+[GPIO_1_8V_ABCD_DATA_READ] =  {0, gpio_reg_data_read},
+[GPIO_1_8V_ABCD_INPUT_MASK] = {0, gpio_reg_input_mask},
+/* 1.8V Set E */
+[GPIO_1_8V_E_DATA_VALUE] = {1, gpio_reg_data_value},
+[GPIO_1_8V_E_DIRECTION] =  {1, gpio_reg_direction},
+[GPIO_1_8V_E_INT_ENABLE] = {1, gpio_reg_int_ena

[Qemu-devel] [PATCH v4 0/3] Add Aspeed GPIO controller model

[Rashmica Gupta]

v4:
- proper interupt handling thanks to Andrew
- switch statements for reading and writing suggested by Peter
- some small cleanups suggested by Alexey

v3:
- didn't have each gpio set up as an irq 
- now can't access set AC on ast2400 (only exists on ast2500)
- added ast2600 implementation (patch 3)
- renamed a couple of variables for clarity

v2: Addressed Andrew's feedback, added debounce regs, renamed get/set to
read/write to minimise confusion with a 'set' of registers.

Rashmica Gupta (3):
  hw/gpio: Add basic Aspeed GPIO model for AST2400 and AST2500
  aspeed: add a GPIO controller to the SoC
  hw/gpio: Add in AST2600 specific implementation

 hw/arm/aspeed_soc.c   |   17 +
 hw/gpio/Makefile.objs |1 +
 hw/gpio/aspeed_gpio.c | 1054 +
 include/hw/arm/aspeed_soc.h   |3 +
 include/hw/gpio/aspeed_gpio.h |  107 
 slirp |2 +-
 6 files changed, 1183 insertions(+), 1 deletion(-)
 create mode 100644 hw/gpio/aspeed_gpio.c
 create mode 100644 include/hw/gpio/aspeed_gpio.h

-- 
2.20.1

[Qemu-devel] [PATCH v4 1/3] hw/gpio: Add basic Aspeed GPIO model for AST2400 and AST2500

[Rashmica Gupta]

GPIO pins are arranged in groups of 8 pins labeled A,B,..,Y,Z,AA,AB,AC.
(Note that the ast2400 controller only goes up to group AB).
A set has four groups (except set AC which only has one) and is
referred to by the groups it is composed of (eg ABCD,EFGH,...,YZAAAB).
Each set is accessed and controlled by a bank of 14 registers.

These registers operate on a per pin level where each bit in the register
corresponds to a pin, except for the command source registers. The command
source registers operate on a per group level where bits 24, 16, 8 and 0
correspond to each group in the set.

 eg. registers for set ABCD:
 |D7...D0|C7...C0|B7...B0|A7...A0| <- GPIOs
 |31...24|23...16|158|7.0| <- bit position

Note that there are a couple of groups that only have 4 pins.

There are two ways that this model deviates from the behaviour of the
actual controller:
(1) The only control source driving the GPIO pins in the model is the ARM
model (as there currently aren't models for the LPC or Coprocessor).

(2) None of the registers in the model are reset tolerant (needs
integration with the watchdog).

Signed-off-by: Rashmica Gupta 
Tested-by: Andrew Jeffery 
---
 hw/gpio/Makefile.objs |   1 +
 hw/gpio/aspeed_gpio.c | 876 ++
 include/hw/gpio/aspeed_gpio.h | 107 +
 3 files changed, 984 insertions(+)
 create mode 100644 hw/gpio/aspeed_gpio.c
 create mode 100644 include/hw/gpio/aspeed_gpio.h

diff --git a/hw/gpio/Makefile.objs b/hw/gpio/Makefile.objs
index e5da0cb54f..d305b3b24b 100644
--- a/hw/gpio/Makefile.objs
+++ b/hw/gpio/Makefile.objs
@@ -9,3 +9,4 @@ obj-$(CONFIG_OMAP) += omap_gpio.o
 obj-$(CONFIG_IMX) += imx_gpio.o
 obj-$(CONFIG_RASPI) += bcm2835_gpio.o
 obj-$(CONFIG_NRF51_SOC) += nrf51_gpio.o
+obj-$(CONFIG_ASPEED_SOC) += aspeed_gpio.o
diff --git a/hw/gpio/aspeed_gpio.c b/hw/gpio/aspeed_gpio.c
new file mode 100644
index 00..bd5af81336
--- /dev/null
+++ b/hw/gpio/aspeed_gpio.c
@@ -0,0 +1,876 @@
+/*
+ *  ASPEED GPIO Controller
+ *
+ *  Copyright (C) 2017-2019 IBM Corp.
+ *
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ */
+
+#include 
+
+#include "qemu/osdep.h"
+#include "qemu/host-utils.h"
+#include "qemu/log.h"
+#include "hw/gpio/aspeed_gpio.h"
+#include "include/hw/misc/aspeed_scu.h"
+#include "qapi/error.h"
+#include "qapi/visitor.h"
+
+#define GPIOS_PER_REG 32
+#define GPIOS_PER_SET GPIOS_PER_REG
+#define GPIO_PIN_GAP_SIZE 4
+#define GPIOS_PER_GROUP 8
+#define GPIO_GROUP_SHIFT 3
+
+/* GPIO Source Types */
+#define ASPEED_CMD_SRC_MASK 0x01010101
+#define ASPEED_SOURCE_ARM   0
+#define ASPEED_SOURCE_LPC   1
+#define ASPEED_SOURCE_COPROCESSOR   2
+#define ASPEED_SOURCE_RESERVED  3
+
+/* GPIO Interrupt Triggers */
+/*
+ *  For each set of gpios there are three sensitivity registers that control
+ *  the interrupt trigger mode.
+ *
+ *  | 2 | 1 | 0 | trigger mode
+ *  -
+ *  | 0 | 0 | 0 | falling-edge
+ *  | 0 | 0 | 1 | rising-edge
+ *  | 0 | 1 | 0 | level-low
+ *  | 0 | 1 | 1 | level-high
+ *  | 1 | X | X | dual-edge
+ */
+#define ASPEED_FALLING_EDGE 0
+#define ASPEED_RISING_EDGE  1
+#define ASPEED_LEVEL_LOW2
+#define ASPEED_LEVEL_HIGH   3
+#define ASPEED_DUAL_EDGE4
+
+/* GPIO Register Address Offsets */
+#define GPIO_ABCD_DATA_VALUE   (0x000 >> 2)
+#define GPIO_ABCD_DIRECTION(0x004 >> 2)
+#define GPIO_ABCD_INT_ENABLE   (0x008 >> 2)
+#define GPIO_ABCD_INT_SENS_0   (0x00C >> 2)
+#define GPIO_ABCD_INT_SENS_1   (0x010 >> 2)
+#define GPIO_ABCD_INT_SENS_2   (0x014 >> 2)
+#define GPIO_ABCD_INT_STATUS   (0x018 >> 2)
+#define GPIO_ABCD_RESET_TOLERANT   (0x01C >> 2)
+#define GPIO_EFGH_DATA_VALUE   (0x020 >> 2)
+#define GPIO_EFGH_DIRECTION(0x024 >> 2)
+#define GPIO_EFGH_INT_ENABLE   (0x028 >> 2)
+#define GPIO_EFGH_INT_SENS_0   (0x02C >> 2)
+#define GPIO_EFGH_INT_SENS_1   (0x030 >> 2)
+#define GPIO_EFGH_INT_SENS_2   (0x034 >> 2)
+#define GPIO_EFGH_INT_STATUS   (0x038 >> 2)
+#define GPIO_EFGH_RESET_TOLERANT   (0x03C >> 2)
+#define GPIO_ABCD_DEBOUNCE_1   (0x040 >> 2)
+#define GPIO_ABCD_DEBOUNCE_2   (0x044 >> 2)
+#define GPIO_EFGH_DEBOUNCE_1   (0x048 >> 2)
+#define GPIO_EFGH_DEBOUNCE_2   (0x04C >> 2)
+#define GPIO_DEBOUNCE_TIME_1   (0x050 >> 2)
+#define GPIO_DEBOUNCE_TIME_2   (0x054 >> 2)
+#define GPIO_DEBOUNCE_TIME_3   (0x058 >> 2)
+#define GPIO_ABCD_COMMAND_SRC_0(0x060 >> 2)
+#define GPIO_ABCD_COMMAND_SRC_1(0x064 >> 2)
+#define GPIO_EFGH_COMMAND_SRC_0(0x068 >> 2)
+#define GPIO_EFGH_COMMAND_SRC_1(0x06C >> 2)
+#define GPIO_IJKL_DATA_VALUE   (0x070 >> 2)
+#define GPIO_IJKL_DIRECTION(0x074 >> 2)
+#define GPIO_MNOP_DATA_VALUE   (0x078 >> 2)
+#define GPIO_MNOP_DIRECTION(0x07C >> 2)
+#define GPIO_QRST_DATA_VALUE   (0x080 >> 2)
+#define GPIO_QRST_DIRECTION(0x084 >> 2)
+#define GPIO_UVWX_DATA_VALUE   (0x088 >> 2)
+#define GPIO_UVWX_DIRECTION(0x08C >> 2)
+#d

[Qemu-devel] [PATCH v4 2/3] aspeed: add a GPIO controller to the SoC

[Rashmica Gupta]

Signed-off-by: Rashmica Gupta 
---
 hw/arm/aspeed_soc.c | 17 +
 include/hw/arm/aspeed_soc.h |  3 +++
 2 files changed, 20 insertions(+)

diff --git a/hw/arm/aspeed_soc.c b/hw/arm/aspeed_soc.c
index c6fb3700f2..ff422c8ad1 100644
--- a/hw/arm/aspeed_soc.c
+++ b/hw/arm/aspeed_soc.c
@@ -124,6 +124,7 @@ static const AspeedSoCInfo aspeed_socs[] = {
 .spis_num = 1,
 .fmc_typename = "aspeed.smc.fmc",
 .spi_typename = aspeed_soc_ast2400_typenames,
+.gpio_typename = "aspeed.gpio-ast2400",
 .wdts_num = 2,
 .irqmap   = aspeed_soc_ast2400_irqmap,
 .memmap   = aspeed_soc_ast2400_memmap,
@@ -136,6 +137,7 @@ static const AspeedSoCInfo aspeed_socs[] = {
 .spis_num = 1,
 .fmc_typename = "aspeed.smc.fmc",
 .spi_typename = aspeed_soc_ast2400_typenames,
+.gpio_typename = "aspeed.gpio-ast2400",
 .wdts_num = 2,
 .irqmap   = aspeed_soc_ast2400_irqmap,
 .memmap   = aspeed_soc_ast2400_memmap,
@@ -148,6 +150,7 @@ static const AspeedSoCInfo aspeed_socs[] = {
 .spis_num = 1,
 .fmc_typename = "aspeed.smc.fmc",
 .spi_typename = aspeed_soc_ast2400_typenames,
+.gpio_typename = "aspeed.gpio-ast2400",
 .wdts_num = 2,
 .irqmap   = aspeed_soc_ast2400_irqmap,
 .memmap   = aspeed_soc_ast2400_memmap,
@@ -160,6 +163,7 @@ static const AspeedSoCInfo aspeed_socs[] = {
 .spis_num = 2,
 .fmc_typename = "aspeed.smc.ast2500-fmc",
 .spi_typename = aspeed_soc_ast2500_typenames,
+.gpio_typename = "aspeed.gpio-ast2500",
 .wdts_num = 3,
 .irqmap   = aspeed_soc_ast2500_irqmap,
 .memmap   = aspeed_soc_ast2500_memmap,
@@ -246,6 +250,9 @@ static void aspeed_soc_init(Object *obj)
 
 sysbus_init_child_obj(obj, "xdma", OBJECT(&s->xdma), sizeof(s->xdma),
   TYPE_ASPEED_XDMA);
+
+sysbus_init_child_obj(obj, "gpio", OBJECT(&s->gpio), sizeof(s->gpio),
+  sc->info->gpio_typename);
 }
 
 static void aspeed_soc_realize(DeviceState *dev, Error **errp)
@@ -425,6 +432,16 @@ static void aspeed_soc_realize(DeviceState *dev, Error 
**errp)
 sc->info->memmap[ASPEED_XDMA]);
 sysbus_connect_irq(SYS_BUS_DEVICE(&s->xdma), 0,
aspeed_soc_get_irq(s, ASPEED_XDMA));
+
+/* GPIO */
+object_property_set_bool(OBJECT(&s->gpio), true, "realized", &err);
+if (err) {
+error_propagate(errp, err);
+return;
+}
+sysbus_mmio_map(SYS_BUS_DEVICE(&s->gpio), 0, 
sc->info->memmap[ASPEED_GPIO]);
+sysbus_connect_irq(SYS_BUS_DEVICE(&s->gpio), 0,
+   aspeed_soc_get_irq(s, ASPEED_GPIO));
 }
 static Property aspeed_soc_properties[] = {
 DEFINE_PROP_UINT32("num-cpus", AspeedSoCState, num_cpus, 0),
diff --git a/include/hw/arm/aspeed_soc.h b/include/hw/arm/aspeed_soc.h
index cef605ad6b..fa04abddd8 100644
--- a/include/hw/arm/aspeed_soc.h
+++ b/include/hw/arm/aspeed_soc.h
@@ -22,6 +22,7 @@
 #include "hw/ssi/aspeed_smc.h"
 #include "hw/watchdog/wdt_aspeed.h"
 #include "hw/net/ftgmac100.h"
+#include "hw/gpio/aspeed_gpio.h"
 
 #define ASPEED_SPIS_NUM  2
 #define ASPEED_WDTS_NUM  3
@@ -47,6 +48,7 @@ typedef struct AspeedSoCState {
 AspeedSDMCState sdmc;
 AspeedWDTState wdt[ASPEED_WDTS_NUM];
 FTGMAC100State ftgmac100[ASPEED_MACS_NUM];
+AspeedGPIOState gpio;
 } AspeedSoCState;
 
 #define TYPE_ASPEED_SOC "aspeed-soc"
@@ -60,6 +62,7 @@ typedef struct AspeedSoCInfo {
 int spis_num;
 const char *fmc_typename;
 const char **spi_typename;
+const char *gpio_typename;
 int wdts_num;
 const int *irqmap;
 const hwaddr *memmap;
-- 
2.20.1

Re: [Qemu-devel] [qemu-s390x] [PATCH-for-4.2 v1 5/6] s390x/mmu: Better storage key reference and change bit handling

[David Hildenbrand]

On 13.08.19 16:54, Cornelia Huck wrote:
> On Mon, 12 Aug 2019 13:27:36 +0200
> David Hildenbrand  wrote:
> 
>> Any access sets the reference bit. In case we have a read-fault, we
>> should not allow writes to the TLB entry if the change bit was not
>> already set.
>>
>> This is a preparation for proper storage-key reference/change bit handling
>> in TCG and a fix for KVM whereby read accesses would set the change
>> bit (old KVM versions without the ioctl to carry out the translation).
> 
> That would be really old kvm versions, right? So no real need to e.g.
> cc:stable?

Yes - nothing a distribution ever supported AFAIK.

-- 

Thanks,

David / dhildenb

Re: [Qemu-devel] [PATCH v3 1/3] hw/gpio: Add basic Aspeed GPIO model for AST2400 and AST2500

[Rashmica Gupta]

On Tue, 2019-08-06 at 14:57 +0100, Peter Maydell wrote:
> On Tue, 30 Jul 2019 at 06:45, Rashmica Gupta 
> wrote:
> > GPIO pins are arranged in groups of 8 pins labeled
> > A,B,..,Y,Z,AA,AB,AC.
> > (Note that the ast2400 controller only goes up to group AB).
> > A set has four groups (except set AC which only has one) and is
> > referred to by the groups it is composed of (eg
> > ABCD,EFGH,...,YZAAAB).
> > Each set is accessed and controlled by a bank of 14 registers.
> > 
> > These registers operate on a per pin level where each bit in the
> > register
> > corresponds to a pin, except for the command source registers. The
> > command
> > source registers operate on a per group level where bits 24, 16, 8
> > and 0
> > correspond to each group in the set.
> > 
> >  eg. registers for set ABCD:
> >  |D7...D0|C7...C0|B7...B0|A7...A0| <- GPIOs
> >  |31...24|23...16|158|7.0| <- bit position
> > 
> > Note that there are a couple of groups that only have 4 pins.
> > 
> > There are two ways that this model deviates from the behaviour of
> > the
> > actual controller:
> > (1) The only control source driving the GPIO pins in the model is
> > the ARM
> > model (as there currently aren't models for the LPC or
> > Coprocessor).
> > 
> > (2) None of the registers in the model are reset tolerant (needs
> > integration with the watchdog).
> > 
> > +typedef struct AspeedGPIOReg {
> > +uint16_t set_idx;
> > +uint32_t (*read)(GPIOSets *regs);
> > +void (*write)(AspeedGPIOState *s, GPIOSets *regs,
> > +const GPIOSetProperties *props, uint32_t val);
> > + } AspeedGPIOReg;
> 
> Please don't create new abstractions for implementing
> registers that are only used in one device model. We
> have a couple of basic approaches that we use already:

That's fair enough :)

> 
>  * just open coded switch statements in the read and write
>functions for the device's MMIO regions

Thoughts on the switch statement approach in v4? I think it's
much nicer than two huge switch statements. 

>  * if you'd rather have a data structure defining each
>register with hook functions where they need to do
>particular behaviour on reads and writes, have a look
>at the APIs in include/hw/register.h. Currently these are
>used just by some of the Xilinx devices, but if you
>want an API shaped like that you can use it.
> 

I had a play with the existing register API. I couldn't quite
get it to work. When writing to some registers in a set we
need to look at other registers in that set, and so we need
some kind of structure tells us how to find those registers.


> thanks
> -- PMM

Re: [Qemu-devel] [PATCH v3 3/3] hw/gpio: Add in AST2600 specific implementation

[Rashmica Gupta]

Thanks for the feedback! I fixed up all the things you mentioned in v4.

On Tue, 2019-08-13 at 17:31 +1000, Alexey Kardashevskiy wrote:
> 
> On 30/07/2019 15:45, Rashmica Gupta wrote:
> > The AST2600 has the same sets of 3.6v gpios as the AST2400 plus an
> > addtional two sets of 1.8V gpios.
> > 
> > Signed-off-by: Rashmica Gupta 
> > ---
> >   hw/gpio/aspeed_gpio.c | 186
> > +-
> >   include/hw/gpio/aspeed_gpio.h |   2 +-
> >   2 files changed, 184 insertions(+), 4 deletions(-)
> > 
> > diff --git a/hw/gpio/aspeed_gpio.c b/hw/gpio/aspeed_gpio.c
> > index 4f1546a900..a94b5f2780 100644
> > --- a/hw/gpio/aspeed_gpio.c
> > +++ b/hw/gpio/aspeed_gpio.c
> > @@ -16,6 +16,7 @@
> >   #define GPIOS_PER_REG 32
> >   #define GPIOS_PER_SET GPIOS_PER_REG
> >   #define GPIO_3_6V_REG_ARRAY_SIZE  (0x1f0 >> 2)
> > +#define GPIO_1_8V_REG_ARRAY_SIZE  ((0x9d8 - 0x800) >> 2)
> 
> Is this 0x800 a GPIO_1_8_REG_OFFSET from below? And 0x9d8 - 
> GPIO_1_8_E_INPUT_MASK + sizeof(u32)? Use them here?
> 
> Actually the symbol does not seem to be very useful anyway, I'd just
> do 
> "aspeed_1_8v_gpios[]" but it seem to be a pattern here so never
> mind...
> 
> 
> 
> >   #define GPIO_PIN_GAP_SIZE 4
> >   #define GPIOS_PER_GROUP 8
> >   #define GPIO_GROUP_SHIFT 3
> > @@ -145,6 +146,7 @@
> >   #define GPIO_YZAAAB_DEBOUNCE_1 (0x190 >> 2)
> >   #define GPIO_YZAAAB_DEBOUNCE_2 (0x194 >> 2)
> >   #define GPIO_YZAAAB_INPUT_MASK (0x198 >> 2)
> > +/* AST2500 only */
> >   #define GPIO_AC_COMMAND_SRC_0  (0x1A0 >> 2)
> >   #define GPIO_AC_COMMAND_SRC_1  (0x1A4 >> 2)
> >   #define GPIO_AC_INT_ENABLE (0x1A8 >> 2)
> > @@ -163,6 +165,47 @@
> >   #define GPIO_AC_DATA_VALUE (0x1E8 >> 2)
> >   #define GPIO_AC_DIRECTION  (0x1EC >> 2)
> >   
> > +
> > +/* AST2600 only - 1.8V gpios */
> > +/*
> > + * The AST2600 has same 3.6V gpios as the AST2400 (memory offsets
> > 0x0-0x198)
> > + * and addtional 1.8V gpios (memory offsets 0x800-0x9D4). We
> > create one
> > + * GPIOState for the 3.6V gpios mapped at 0x0 and another
> > GPIOState for the
> > + * 1.8V gpios mapped at 0x800.
> > + */
> > +#define GPIO_1_8_REG_OFFSET  0x800
> > +#define GPIO_1_8_ABCD_DATA_VALUE ((0x800 -
> > GPIO_1_8_REG_OFFSET) >> 2)
> > +#define GPIO_1_8_ABCD_DIRECTION  ((0x804 -
> > GPIO_1_8_REG_OFFSET) >> 2)
> > +#define GPIO_1_8_ABCD_INT_ENABLE ((0x808 -
> > GPIO_1_8_REG_OFFSET) >> 2)
> > +#define GPIO_1_8_ABCD_INT_SENS_0 ((0x80C -
> > GPIO_1_8_REG_OFFSET) >> 2)
> > +#define GPIO_1_8_ABCD_INT_SENS_1 ((0x810 -
> > GPIO_1_8_REG_OFFSET) >> 2)
> > +#define GPIO_1_8_ABCD_INT_SENS_2 ((0x814 -
> > GPIO_1_8_REG_OFFSET) >> 2)
> > +#define GPIO_1_8_ABCD_INT_STATUS ((0x818 -
> > GPIO_1_8_REG_OFFSET) >> 2)
> > +#define GPIO_1_8_ABCD_RESET_TOLERANT ((0x81C -
> > GPIO_1_8_REG_OFFSET) >> 2)
> > +#define GPIO_1_8_E_DATA_VALUE((0x820 -
> > GPIO_1_8_REG_OFFSET) >> 2)
> > +#define GPIO_1_8_E_DIRECTION ((0x824 -
> > GPIO_1_8_REG_OFFSET) >> 2)
> > +#define GPIO_1_8_E_INT_ENABLE((0x828 -
> > GPIO_1_8_REG_OFFSET) >> 2)
> > +#define GPIO_1_8_E_INT_SENS_0((0x82C -
> > GPIO_1_8_REG_OFFSET) >> 2)
> > +#define GPIO_1_8_E_INT_SENS_1((0x830 -
> > GPIO_1_8_REG_OFFSET) >> 2)
> > +#define GPIO_1_8_E_INT_SENS_2((0x834 -
> > GPIO_1_8_REG_OFFSET) >> 2)
> > +#define GPIO_1_8_E_INT_STATUS((0x838 -
> > GPIO_1_8_REG_OFFSET) >> 2)
> > +#define GPIO_1_8_E_RESET_TOLERANT((0x83C -
> > GPIO_1_8_REG_OFFSET) >> 2)
> > +#define GPIO_1_8_ABCD_DEBOUNCE_1 ((0x840 -
> > GPIO_1_8_REG_OFFSET) >> 2)
> > +#define GPIO_1_8_ABCD_DEBOUNCE_2 ((0x844 -
> > GPIO_1_8_REG_OFFSET) >> 2)
> > +#define GPIO_1_8_E_DEBOUNCE_1((0x848 -
> > GPIO_1_8_REG_OFFSET) >> 2)
> > +#define GPIO_1_8_E_DEBOUNCE_2((0x84C -
> > GPIO_1_8_REG_OFFSET) >> 2)
> > +#define GPIO_1_8_DEBOUNCE_TIME_1 ((0x850 -
> > GPIO_1_8_REG_OFFSET) >> 2)
> > +#define GPIO_1_8_DEBOUNCE_TIME_2 ((0x854 -
> > GPIO_1_8_REG_OFFSET) >> 2)
> > +#define GPIO_1_8_DEBOUNCE_TIME_3 ((0x858 -
> > GPIO_1_8_REG_OFFSET) >> 2)
> > +#define GPIO_1_8_ABCD_COMMAND_SRC_0  ((0x860 -
> > GPIO_1_8_REG_OFFSET) >> 2)
> > +#define GPIO_1_8_ABCD_COMMAND_SRC_1  ((0x864 -
> > GPIO_1_8_REG_OFFSET) >> 2)
> > +#define GPIO_1_8_E_COMMAND_SRC_0 ((0x868 -
> > GPIO_1_8_REG_OFFSET) >> 2)
> > +#define GPIO_1_8_E_COMMAND_SRC_1 ((0x86C -
> > GPIO_1_8_REG_OFFSET) >> 2)
> > +#define GPIO_1_8_ABCD_DATA_READ  ((0x8C0 -
> > GPIO_1_8_REG_OFFSET) >> 2)
> > +#define GPIO_1_8_E_DATA_READ ((0x8C4 -
> > GPIO_1_8_REG_OFFSET) >> 2)
> > +#define GPIO_1_8_ABCD_INPUT_MASK ((0x9D0 -
> > GPIO_1_8_REG_OFFSET) >> 2)
> > +#define GPIO_1_8_E_INPUT_MASK((0x9D4 -
> > GPIO_1_8_REG_OFFSET) >> 2)
> > +
> >   static int aspeed_evaluate_irq(GPIOSets *regs, int
> > gpio_prev_high, int gpio)
> >   {
> >   uint32_t falling_edge = 0, rising_edge = 0;
> > @@ -626,6 +669,39 @@ static const AspeedGPIOReg
> > aspeed_3_6v_gpios

[Qemu-devel] [PATCH-for-4.2 v2 2/6] s390x/tcg: Rework MMU selection for instruction fetches

[David Hildenbrand]

Instructions are always fetched from primary address space, except when
in home address mode. Perform the selection directly in cpu_mmu_index().

get_mem_index() is only used to perform data access, instructions are
fetched via cpu_lduw_code(), which translates to cpu_mmu_index(env, true).

We don't care about restricting the access permissions of the TLB
entries anymore, as we no longer enter PRIMARY entries into the
SECONDARY MMU. Cleanup related code a bit.

Signed-off-by: David Hildenbrand 
---
 target/s390x/cpu.h|  7 +++
 target/s390x/mmu_helper.c | 38 +++---
 2 files changed, 22 insertions(+), 23 deletions(-)

diff --git a/target/s390x/cpu.h b/target/s390x/cpu.h
index a606547b4d..c34992bb2e 100644
--- a/target/s390x/cpu.h
+++ b/target/s390x/cpu.h
@@ -332,6 +332,13 @@ static inline int cpu_mmu_index(CPUS390XState *env, bool 
ifetch)
 return MMU_REAL_IDX;
 }
 
+if (ifetch) {
+if ((env->psw.mask & PSW_MASK_ASC) == PSW_ASC_HOME) {
+return MMU_HOME_IDX;
+}
+return MMU_PRIMARY_IDX;
+}
+
 switch (env->psw.mask & PSW_MASK_ASC) {
 case PSW_ASC_PRIMARY:
 return MMU_PRIMARY_IDX;
diff --git a/target/s390x/mmu_helper.c b/target/s390x/mmu_helper.c
index 6e9c4d6151..c34e8d2021 100644
--- a/target/s390x/mmu_helper.c
+++ b/target/s390x/mmu_helper.c
@@ -349,8 +349,9 @@ int mmu_translate(CPUS390XState *env, target_ulong vaddr, 
int rw, uint64_t asc,
 {
 static S390SKeysState *ss;
 static S390SKeysClass *skeyclass;
-int r = -1;
+uint64_t asce;
 uint8_t key;
+int r;
 
 if (unlikely(!ss)) {
 ss = s390_get_skeys_device();
@@ -380,36 +381,21 @@ int mmu_translate(CPUS390XState *env, target_ulong vaddr, 
int rw, uint64_t asc,
 
 if (!(env->psw.mask & PSW_MASK_DAT)) {
 *raddr = vaddr;
-r = 0;
-goto out;
+goto nodat;
 }
 
 switch (asc) {
 case PSW_ASC_PRIMARY:
 PTE_DPRINTF("%s: asc=primary\n", __func__);
-r = mmu_translate_asce(env, vaddr, asc, env->cregs[1], raddr, flags,
-   rw, exc);
+asce = env->cregs[1];
 break;
 case PSW_ASC_HOME:
 PTE_DPRINTF("%s: asc=home\n", __func__);
-r = mmu_translate_asce(env, vaddr, asc, env->cregs[13], raddr, flags,
-   rw, exc);
+asce = env->cregs[13];
 break;
 case PSW_ASC_SECONDARY:
 PTE_DPRINTF("%s: asc=secondary\n", __func__);
-/*
- * Instruction: Primary
- * Data: Secondary
- */
-if (rw == MMU_INST_FETCH) {
-r = mmu_translate_asce(env, vaddr, PSW_ASC_PRIMARY, env->cregs[1],
-   raddr, flags, rw, exc);
-*flags &= ~(PAGE_READ | PAGE_WRITE);
-} else {
-r = mmu_translate_asce(env, vaddr, PSW_ASC_SECONDARY, 
env->cregs[7],
-   raddr, flags, rw, exc);
-*flags &= ~(PAGE_EXEC);
-}
+asce = env->cregs[7];
 break;
 case PSW_ASC_ACCREG:
 default:
@@ -417,11 +403,17 @@ int mmu_translate(CPUS390XState *env, target_ulong vaddr, 
int rw, uint64_t asc,
 break;
 }
 
- out:
+/* perform the DAT translation */
+r = mmu_translate_asce(env, vaddr, asc, asce, raddr, flags, rw, exc);
+if (r) {
+return r;
+}
+
+nodat:
 /* Convert real address -> absolute address */
 *raddr = mmu_real2abs(env, *raddr);
 
-if (r == 0 && *raddr < ram_size) {
+if (*raddr < ram_size) {
 if (skeyclass->get_skeys(ss, *raddr / TARGET_PAGE_SIZE, 1, &key)) {
 trace_get_skeys_nonzero(r);
 return 0;
@@ -441,7 +433,7 @@ int mmu_translate(CPUS390XState *env, target_ulong vaddr, 
int rw, uint64_t asc,
 }
 }
 
-return r;
+return 0;
 }
 
 /**
-- 
2.21.0

[Qemu-devel] [PATCH-for-4.2 v2 1/6] s390x/mmu: ASC selection in s390_cpu_get_phys_page_debug()

[David Hildenbrand]

Let's select the ASC before calling the function. This is a prepararion
to remove the ASC magic depending on the access mode from mmu_translate.

There is currently no way to distinguish if we have code or data access.
For now, we were using code access, because especially when debugging with
the gdbstub, we want to read and disassemble what we single-step.

Reviewed-by: Thomas Huth 
Reviewed-by: Cornelia Huck 
Signed-off-by: David Hildenbrand 
---
 target/s390x/helper.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/target/s390x/helper.c b/target/s390x/helper.c
index 13ae9909ad..c5fb8966b6 100644
--- a/target/s390x/helper.c
+++ b/target/s390x/helper.c
@@ -58,6 +58,11 @@ hwaddr s390_cpu_get_phys_page_debug(CPUState *cs, vaddr 
vaddr)
 vaddr &= 0x7fff;
 }
 
+/* We want to read the code (e.g., see what we are single-stepping).*/
+if (asc != PSW_ASC_HOME) {
+asc = PSW_ASC_PRIMARY;
+}
+
 if (mmu_translate(env, vaddr, MMU_INST_FETCH, asc, &raddr, &prot, false)) {
 return -1;
 }
-- 
2.21.0

[Qemu-devel] [PATCH-for-4.2 v2 0/6] s390x/mmu: Storage key reference and change bit handling

[David Hildenbrand]

The first two patches are modified patches from:
[PATCH-for-4.2 v1 0/9] s390x: MMU changes and extensions

This series primarily fixes minor things in the storage key handling code
in the MMU and implements fairly reliable reference and change bit handling
for TCG. To track the reference and change bit, we have to invalidate
TLB entries whenever the storage key is changed by the guest and make sure
not TLB entry is writable in case the storage key does not indicate a
change already.

With this series, the kvm-unit-test "skey" now passes. \o/

v1 -> v2:
- "s390x/tcg: Rework MMU selection for instruction fetches"
-- Cleanup return value handling
- Added RB's

David Hildenbrand (6):
  s390x/mmu: ASC selection in s390_cpu_get_phys_page_debug()
  s390x/tcg: Rework MMU selection for instruction fetches
  s390x/tcg: Flush the TLB of all CPUs on SSKE and RRBE
  s390x/mmu: Trace the right value if setting/getting the storage key
fails
  s390x/mmu: Better storage key reference and change bit handling
  s390x/mmu: Factor out storage key handling

 target/s390x/cpu.h|   7 ++
 target/s390x/helper.c |   5 ++
 target/s390x/mem_helper.c |   4 ++
 target/s390x/mmu_helper.c | 133 --
 4 files changed, 99 insertions(+), 50 deletions(-)

-- 
2.21.0

[Qemu-devel] [PATCH-for-4.2 v2 3/6] s390x/tcg: Flush the TLB of all CPUs on SSKE and RRBE

[David Hildenbrand]

Whenever we modify a storage key, we shuld flush the TLBs of all CPUs,
so the MMU fault handling code can properly consider the changed storage
key (to e.g., properly set the reference and change bit on the next
accesses).

These functions are barely used in modern Linux guests, so the performance
implications are neglectable for now.

This is a preparation for better reference and change bit handling for
TCG, which will require more MMU changes.

Reviewed-by: Cornelia Huck 
Signed-off-by: David Hildenbrand 
---
 target/s390x/mem_helper.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/target/s390x/mem_helper.c b/target/s390x/mem_helper.c
index 29d9eaa5b7..ed54265e03 100644
--- a/target/s390x/mem_helper.c
+++ b/target/s390x/mem_helper.c
@@ -1815,6 +1815,8 @@ void HELPER(sske)(CPUS390XState *env, uint64_t r1, 
uint64_t r2)
 
 key = (uint8_t) r1;
 skeyclass->set_skeys(ss, addr / TARGET_PAGE_SIZE, 1, &key);
+/* TODO: Flush only entries with this target address */
+tlb_flush_all_cpus_synced(env_cpu(env));
 }
 
 /* reset reference bit extended */
@@ -1843,6 +1845,8 @@ uint32_t HELPER(rrbe)(CPUS390XState *env, uint64_t r2)
 if (skeyclass->set_skeys(ss, r2 / TARGET_PAGE_SIZE, 1, &key)) {
 return 0;
 }
+/* TODO: Flush only entries with this target address */
+tlb_flush_all_cpus_synced(env_cpu(env));
 
 /*
  * cc
-- 
2.21.0

[Qemu-devel] [PATCH-for-4.2 v2 5/6] s390x/mmu: Better storage key reference and change bit handling

[David Hildenbrand]

Any access sets the reference bit. In case we have a read-fault, we
should not allow writes to the TLB entry if the change bit was not
already set.

This is a preparation for proper storage-key reference/change bit handling
in TCG and a fix for KVM whereby read accesses would set the change
bit (old KVM versions without the ioctl to carry out the translation).

Reviewed-by: Cornelia Huck 
Signed-off-by: David Hildenbrand 
---
 target/s390x/mmu_helper.c | 24 +++-
 1 file changed, 19 insertions(+), 5 deletions(-)

diff --git a/target/s390x/mmu_helper.c b/target/s390x/mmu_helper.c
index d22c6b9c81..6cc81a29b6 100644
--- a/target/s390x/mmu_helper.c
+++ b/target/s390x/mmu_helper.c
@@ -420,14 +420,28 @@ nodat:
 return 0;
 }
 
-if (*flags & PAGE_READ) {
-key |= SK_R;
-}
-
-if (*flags & PAGE_WRITE) {
+switch (rw) {
+case MMU_DATA_LOAD:
+case MMU_INST_FETCH:
+/*
+ * The TLB entry has to remain write-protected on read-faults if
+ * the storage key does not indicate a change already. Otherwise
+ * we might miss setting the change bit on write accesses.
+ */
+if (!(key & SK_C)) {
+*flags &= ~PAGE_WRITE;
+}
+break;
+case MMU_DATA_STORE:
 key |= SK_C;
+break;
+default:
+g_assert_not_reached();
 }
 
+/* Any store/fetch sets the reference bit */
+key |= SK_R;
+
 r = skeyclass->set_skeys(ss, *raddr / TARGET_PAGE_SIZE, 1, &key);
 if (r) {
 trace_set_skeys_nonzero(r);
-- 
2.21.0

[Qemu-devel] [PATCH-for-4.2 v2 4/6] s390x/mmu: Trace the right value if setting/getting the storage key fails

[David Hildenbrand]

We want to trace the actual return value, not "0".

Reviewed-by: Cornelia Huck 
Signed-off-by: David Hildenbrand 
---
 target/s390x/mmu_helper.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/target/s390x/mmu_helper.c b/target/s390x/mmu_helper.c
index c34e8d2021..d22c6b9c81 100644
--- a/target/s390x/mmu_helper.c
+++ b/target/s390x/mmu_helper.c
@@ -414,7 +414,8 @@ nodat:
 *raddr = mmu_real2abs(env, *raddr);
 
 if (*raddr < ram_size) {
-if (skeyclass->get_skeys(ss, *raddr / TARGET_PAGE_SIZE, 1, &key)) {
+r = skeyclass->get_skeys(ss, *raddr / TARGET_PAGE_SIZE, 1, &key);
+if (r) {
 trace_get_skeys_nonzero(r);
 return 0;
 }
@@ -427,7 +428,8 @@ nodat:
 key |= SK_C;
 }
 
-if (skeyclass->set_skeys(ss, *raddr / TARGET_PAGE_SIZE, 1, &key)) {
+r = skeyclass->set_skeys(ss, *raddr / TARGET_PAGE_SIZE, 1, &key);
+if (r) {
 trace_set_skeys_nonzero(r);
 return 0;
 }
-- 
2.21.0

[Qemu-devel] [PATCH-for-4.2 v2 6/6] s390x/mmu: Factor out storage key handling

[David Hildenbrand]

Factor it out, add a comment how it all works, and also use it in the
REAL MMU.

Reviewed-by: Cornelia Huck 
Signed-off-by: David Hildenbrand 
---
 target/s390x/mmu_helper.c | 113 +++---
 1 file changed, 69 insertions(+), 44 deletions(-)

diff --git a/target/s390x/mmu_helper.c b/target/s390x/mmu_helper.c
index 6cc81a29b6..e125837d68 100644
--- a/target/s390x/mmu_helper.c
+++ b/target/s390x/mmu_helper.c
@@ -334,6 +334,73 @@ static int mmu_translate_asce(CPUS390XState *env, 
target_ulong vaddr,
 return r;
 }
 
+static void mmu_handle_skey(target_ulong addr, int rw, int *flags)
+{
+static S390SKeysClass *skeyclass;
+static S390SKeysState *ss;
+uint8_t key;
+int rc;
+
+if (unlikely(!ss)) {
+ss = s390_get_skeys_device();
+skeyclass = S390_SKEYS_GET_CLASS(ss);
+}
+
+/*
+ * Whenever we create a new TLB entry, we set the storage key reference
+ * bit. In case we allow write accesses, we set the storage key change
+ * bit. Whenever the guest changes the storage key, we have to flush the
+ * TLBs of all CPUs (the whole TLB or all affected entries), so that the
+ * next reference/change will result in an MMU fault and make us properly
+ * update the storage key here.
+ *
+ * Note 1: "record of references ... is not necessarily accurate",
+ * "change bit may be set in case no storing has occurred".
+ * -> We can set reference/change bits even on exceptions.
+ * Note 2: certain accesses seem to ignore storage keys. For example,
+ * DAT translation does not set reference bits for table accesses.
+ *
+ * TODO: key-controlled protection. Only CPU accesses make use of the
+ *   PSW key. CSS accesses are different - we have to pass in the key.
+ *
+ * TODO: we have races between getting and setting the key.
+ */
+if (addr < ram_size) {
+rc = skeyclass->get_skeys(ss, addr / TARGET_PAGE_SIZE, 1, &key);
+if (rc) {
+trace_get_skeys_nonzero(rc);
+return;
+}
+
+switch (rw) {
+case MMU_DATA_LOAD:
+case MMU_INST_FETCH:
+/*
+ * The TLB entry has to remain write-protected on read-faults if
+ * the storage key does not indicate a change already. Otherwise
+ * we might miss setting the change bit on write accesses.
+ */
+if (!(key & SK_C)) {
+*flags &= ~PAGE_WRITE;
+}
+break;
+case MMU_DATA_STORE:
+key |= SK_C;
+break;
+default:
+g_assert_not_reached();
+}
+
+/* Any store/fetch sets the reference bit */
+key |= SK_R;
+
+rc = skeyclass->set_skeys(ss, addr / TARGET_PAGE_SIZE, 1, &key);
+if (rc) {
+trace_set_skeys_nonzero(rc);
+}
+}
+}
+
 /**
  * Translate a virtual (logical) address into a physical (absolute) address.
  * @param vaddr  the virtual address
@@ -347,16 +414,9 @@ static int mmu_translate_asce(CPUS390XState *env, 
target_ulong vaddr,
 int mmu_translate(CPUS390XState *env, target_ulong vaddr, int rw, uint64_t asc,
   target_ulong *raddr, int *flags, bool exc)
 {
-static S390SKeysState *ss;
-static S390SKeysClass *skeyclass;
 uint64_t asce;
-uint8_t key;
 int r;
 
-if (unlikely(!ss)) {
-ss = s390_get_skeys_device();
-skeyclass = S390_SKEYS_GET_CLASS(ss);
-}
 
 *flags = PAGE_READ | PAGE_WRITE | PAGE_EXEC;
 if (is_low_address(vaddr & TARGET_PAGE_MASK) && lowprot_enabled(env, asc)) 
{
@@ -413,42 +473,7 @@ nodat:
 /* Convert real address -> absolute address */
 *raddr = mmu_real2abs(env, *raddr);
 
-if (*raddr < ram_size) {
-r = skeyclass->get_skeys(ss, *raddr / TARGET_PAGE_SIZE, 1, &key);
-if (r) {
-trace_get_skeys_nonzero(r);
-return 0;
-}
-
-switch (rw) {
-case MMU_DATA_LOAD:
-case MMU_INST_FETCH:
-/*
- * The TLB entry has to remain write-protected on read-faults if
- * the storage key does not indicate a change already. Otherwise
- * we might miss setting the change bit on write accesses.
- */
-if (!(key & SK_C)) {
-*flags &= ~PAGE_WRITE;
-}
-break;
-case MMU_DATA_STORE:
-key |= SK_C;
-break;
-default:
-g_assert_not_reached();
-}
-
-/* Any store/fetch sets the reference bit */
-key |= SK_R;
-
-r = skeyclass->set_skeys(ss, *raddr / TARGET_PAGE_SIZE, 1, &key);
-if (r) {
-trace_set_skeys_nonzero(r);
-return 0;
-}
-}
-
+mmu_handle_skey(*raddr, rw, flags);
 return 0;
 }
 
@@ -566,6 +591,6 @@ int mmu_translate_real(CPUS390XState *env, target_ulong 
raddr, int rw,
 
 

Re: [Qemu-devel] [PATCH] pc-bios/s390-ccw/net: fix a possible memory leak in get_uuid()

[Cornelia Huck]

On Wed, 14 Aug 2019 14:14:26 +0800
 wrote:

> There is a possible memory leak in get_uuid(). Should free allocated mem
> before 
> return NULL.
> 
> Signed-off-by: Yifan Luo 
> ---
>  pc-bios/s390-ccw/netmain.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/pc-bios/s390-ccw/netmain.c b/pc-bios/s390-ccw/netmain.c
> index f3542cb2cf1..f2dcc01e272 100644
> --- a/pc-bios/s390-ccw/netmain.c
> +++ b/pc-bios/s390-ccw/netmain.c
> @@ -269,6 +269,7 @@ static const char *get_uuid(void)
>   : "d" (r0), "d" (r1), [addr] "a" (buf)
>   : "cc", "memory");
>  if (cc) {
> +free(mem);
>  return NULL;
>  }
>  

Reviewed-by: Cornelia Huck 

Re: [Qemu-devel] [PATCH v2 1/4] block: introduce aio task pool

[Vladimir Sementsov-Ogievskiy]

13.08.2019 23:47, Max Reitz wrote:
> On 30.07.19 16:18, Vladimir Sementsov-Ogievskiy wrote:
>> Common interface for aio task loops. To be used for improving
>> performance of synchronous io loops in qcow2, block-stream,
>> copy-on-read, and may be other places.
>>
>> Signed-off-by: Vladimir Sementsov-Ogievskiy 
>> ---
> 
> Looks good to me overall.
> 
>>   block/aio_task.h|  52 +++
> 
> I’ve move this to include/block/.
> 
>>   block/aio_task.c| 119 
>>   block/Makefile.objs |   2 +
>>   3 files changed, 173 insertions(+)
>>   create mode 100644 block/aio_task.h
>>   create mode 100644 block/aio_task.c
>>
>> diff --git a/block/aio_task.h b/block/aio_task.h
>> new file mode 100644
>> index 00..933af1d8e7
>> --- /dev/null
>> +++ b/block/aio_task.h
> 
> [...]
> 
>> +typedef struct AioTaskPool AioTaskPool;
>> +typedef struct AioTask AioTask;
>> +typedef int (*AioTaskFunc)(AioTask *task);
> 
> +coroutine_fn
> 
>> +struct AioTask {
>> +AioTaskPool *pool;
>> +AioTaskFunc func;
>> +int ret;
>> +};
>> +
>> +/*
>> + * aio_task_pool_new
>> + *
>> + * The caller is responsible to g_free AioTaskPool pointer after use.
> 
> s/to g_free/for g_freeing/ or something similar.
> 
> Or you’d just add aio_task_pool_free().
> 
>> + */
>> +AioTaskPool *aio_task_pool_new(int max_busy_tasks);
>> +int aio_task_pool_status(AioTaskPool *pool);
> 
> A comment wouldn’t hurt.  It wasn’t immediately clear to me that status
> refers to the error code of a failing task (or 0), although it wasn’t
> too much of a surprise either.
> 
>> +bool aio_task_pool_empty(AioTaskPool *pool);
>> +void aio_task_pool_start_task(AioTaskPool *pool, AioTask *task);
> 
> Maybe make a note that task->pool will be set automatically?
> 
>> +void aio_task_pool_wait_slot(AioTaskPool *pool);
>> +void aio_task_pool_wait_one(AioTaskPool *pool);
>> +void aio_task_pool_wait_all(AioTaskPool *pool);
> 
> Shouldn’t all of these but aio_task_pool_empty() and
> aio_task_pool_status() be coroutine_fns?
> 
>> +#endif /* BLOCK_AIO_TASK_H */
>> diff --git a/block/aio_task.c b/block/aio_task.c
>> new file mode 100644
>> index 00..807be8deb5
>> --- /dev/null
>> +++ b/block/aio_task.c
> 
> [...]
> 
>> +static void aio_task_co(void *opaque)
> 
> +coroutine_fn
> 
> [...]
> 
>> +void aio_task_pool_wait_one(AioTaskPool *pool)
>> +{
>> +assert(pool->busy_tasks > 0);
>> +assert(qemu_coroutine_self() == pool->main_co);
>> +
>> +pool->wait_done = true;
> 
> Hmmm, but the wait actually isn’t done yet. :-)
> 
> Maybe s/wait_done/waiting/?
> 


Aha, really bad variable name. I meant "wait for one task done". Just "waiting" 
would be appropriate.

Thanks for reviewing!

-- 
Best regards,
Vladimir

Re: [Qemu-devel] [PATCH v2 2/4] block/qcow2: refactor qcow2_co_preadv_part

[Vladimir Sementsov-Ogievskiy]

14.08.2019 0:31, Max Reitz wrote:
> On 30.07.19 16:18, Vladimir Sementsov-Ogievskiy wrote:
>> Further patch will run partial requests of iterations of
>> qcow2_co_preadv in parallel for performance reasons. To prepare for
>> this, separate part which may be parallelized into separate function
>> (qcow2_co_preadv_task).
>>
>> While being here, also separate encrypted clusters reading to own
>> function, like it is done for compressed reading.
>>
>> Signed-off-by: Vladimir Sementsov-Ogievskiy 
>> ---
>>   qapi/block-core.json |   2 +-
>>   block/qcow2.c| 206 +++
>>   2 files changed, 112 insertions(+), 96 deletions(-)
> 
> Looks good to me overall, just wondering about some details, as always.
> 
>> diff --git a/block/qcow2.c b/block/qcow2.c
>> index 93ab7edcea..7fa71968b2 100644
>> --- a/block/qcow2.c
>> +++ b/block/qcow2.c
>> @@ -1967,17 +1967,115 @@ out:
>>   return ret;
>>   }
>>   
>> +static coroutine_fn int
>> +qcow2_co_preadv_encrypted(BlockDriverState *bs,
>> +   uint64_t file_cluster_offset,
>> +   uint64_t offset,
>> +   uint64_t bytes,
>> +   QEMUIOVector *qiov,
>> +   uint64_t qiov_offset)
>> +{
>> +int ret;
>> +BDRVQcow2State *s = bs->opaque;
>> +uint8_t *buf;
>> +
>> +assert(bs->encrypted && s->crypto);
>> +assert(bytes <= QCOW_MAX_CRYPT_CLUSTERS * s->cluster_size);
>> +
>> +/*
>> + * For encrypted images, read everything into a temporary
>> + * contiguous buffer on which the AES functions can work.
>> + * Note, that we can implement enctyption, working on qiov,
> 
> -, and s/enctyption/encryption/
> 
>> + * but we must not do decryption in guest buffers for security
>> + * reasons.
> 
> "for security reasons" is a bit handwave-y, no?

Hmm, let's think of it a bit.

WRITE

1. We can't do any operations on write buffers, as guest may use them for
something else and not prepared for their change. [thx to Den, pointed to this 
fact]

READ

Hmm, here otherwise, guest should not expect something meaningful in buffers 
until the
end of read operation, so theoretically we may decrypt directly in guest 
buffer.. What is
bad with it?

1. Making read-part different from write and implementing support of qiov for 
decryptin for
little outcome (hmm, don't double allocation for reads, is it little or not? 
[*]).

2. Guest can read its buffers.
So, it may see encrypted data and guess something about it. Ideally guest
should know nothing about encryption, but on the other hand, is there any
real damage? I don't sure..

3. Guest can modify its buffers.
3.1 I think there is no guarantee that guest will not modify its data before we 
finished
copying to separate buffer, so what guest finally reads is not predictable 
anyway.
3.2 But, modifying during decryption may possibly lead to guest visible error
(which will never be if we operate on separated cluster)

So if we don't afraid of [2] and [3.2], and in a specific case [*] is 
significant, we may want
implement decryption on guest buffers at least as an option..
But all it looks for me like we'll never do it.

===

So, I'd rewrite my "Note" like this:

Also, decryption in separate buffer is better as it hides from the guest 
information
it doesn't own (about encrypted nature of virtual disk).

> 
> [...]
> 
>> +static coroutine_fn int qcow2_co_preadv_task(BlockDriverState *bs,
>> + QCow2ClusterType cluster_type,
>> + uint64_t file_cluster_offset,
>> + uint64_t offset, uint64_t 
>> bytes,
>> + QEMUIOVector *qiov,
>> + size_t qiov_offset)
>> +{
>> +BDRVQcow2State *s = bs->opaque;
>> +int offset_in_cluster = offset_into_cluster(s, offset);
>> +
>> +switch (cluster_type) {
> 
> [...]
> 
>> +default:
>> +g_assert_not_reached();
>> +/*
>> + * QCOW2_CLUSTER_ZERO_PLAIN and QCOW2_CLUSTER_ZERO_ALLOC handled
>> + * in qcow2_co_preadv_part
> 
> Hmm, I’d still add them explicitly as cases and put their own
> g_assert_not_reach() there.
> 
>> + */
>> +}
>> +
>> +g_assert_not_reached();
>> +
>> +return -EIO;
> 
> Maybe abort()ing instead of g_assert_not_reach() would save you from
> having to return here?
> 

Hmm, will check. Any reason to use g_assert_not_reached() instead of abort() in 
"default"?
I just kept it like it was. But it seems to be more often practice to use just 
abort() in
Qemu code.

-- 
Best regards,
Vladimir

Re: [Qemu-devel] [PATCH v2 6/7] target/riscv: rationalise softfloat includes

[Alex Bennée]

Palmer Dabbelt  writes:

> On Fri, 09 Aug 2019 18:55:42 PDT (-0700), alistai...@gmail.com wrote:
>> On Fri, Aug 9, 2019 at 2:22 AM Alex Bennée  wrote:
>>>
>>> We should avoid including the whole of softfloat headers in cpu.h and
>>> explicitly include it only where we will be calling softfloat
>>> functions. We can use the -types.h and -helpers.h in cpu.h for the few
>>> bits that are global.
>>>
>>> Signed-off-by: Alex Bennée 
>>> Reviewed-by: Richard Henderson 
>>
>> I just reviewed v1, but this also applies to v2:
>>
>> Reviewed-by: Alistair Francis 
>
> Acked-by: Palmer Dabbelt 
>
> I'm assuming this are going in through another tree, along with the
> rest of the patch set.

It will yes..

>
>>
>> Alistair
>>
>>> ---
>>>  target/riscv/cpu.c| 1 +
>>>  target/riscv/cpu.h| 2 +-
>>>  target/riscv/fpu_helper.c | 1 +
>>>  3 files changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
>>> index f8d07bd20ad..6d52f97d7c3 100644
>>> --- a/target/riscv/cpu.c
>>> +++ b/target/riscv/cpu.c
>>> @@ -27,6 +27,7 @@
>>>  #include "qemu/error-report.h"
>>>  #include "hw/qdev-properties.h"
>>>  #include "migration/vmstate.h"
>>> +#include "fpu/softfloat-helpers.h"
>>>
>>>  /* RISC-V CPU definitions */
>>>
>>> diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
>>> index 0adb307f329..240b31e2ebb 100644
>>> --- a/target/riscv/cpu.h
>>> +++ b/target/riscv/cpu.h
>>> @@ -22,7 +22,7 @@
>>>
>>>  #include "qom/cpu.h"
>>>  #include "exec/cpu-defs.h"
>>> -#include "fpu/softfloat.h"
>>> +#include "fpu/softfloat-types.h"
>>>
>>>  #define TCG_GUEST_DEFAULT_MO 0
>>>
>>> diff --git a/target/riscv/fpu_helper.c b/target/riscv/fpu_helper.c
>>> index b4f818a6465..0b79562a690 100644
>>> --- a/target/riscv/fpu_helper.c
>>> +++ b/target/riscv/fpu_helper.c
>>> @@ -21,6 +21,7 @@
>>>  #include "qemu/host-utils.h"
>>>  #include "exec/exec-all.h"
>>>  #include "exec/helper-proto.h"
>>> +#include "fpu/softfloat.h"
>>>
>>>  target_ulong riscv_cpu_get_fflags(CPURISCVState *env)
>>>  {
>>> --
>>> 2.20.1


--
Alex Bennée

Re: [Qemu-devel] [Qemu-riscv] [PATCH] riscv: sifive_e: Correct various SoC IP block sizes

[Bin Meng]

Hi Palmer,

On Wed, Aug 7, 2019 at 10:53 AM Bin Meng  wrote:
>
> On Wed, Aug 7, 2019 at 5:06 AM Philippe Mathieu-Daudé  
> wrote:
> >
> > On 8/5/19 8:43 AM, Bin Meng wrote:
> > > On Mon, Aug 5, 2019 at 2:14 PM Chih-Min Chao  
> > > wrote:
> > >> On Sat, Aug 3, 2019 at 8:27 AM Bin Meng  wrote:
> > >>>
> > >>> Some of the SoC IP block sizes are wrong. Correct them according
> > >>> to the FE310 manual.
> > >>>
> > >>> Signed-off-by: Bin Meng 
> > >>> ---
> > >>>
> > >>>  hw/riscv/sifive_e.c | 6 +++---
> > >>>  1 file changed, 3 insertions(+), 3 deletions(-)
> > >>>
> > >>> diff --git a/hw/riscv/sifive_e.c b/hw/riscv/sifive_e.c
> > >>> index 2a499d8..9655847 100644
> > >>> --- a/hw/riscv/sifive_e.c
> > >>> +++ b/hw/riscv/sifive_e.c
> > >>> @@ -53,13 +53,13 @@ static const struct MemmapEntry {
> > >>>  hwaddr base;
> > >>>  hwaddr size;
> > >>>  } sifive_e_memmap[] = {
> > >>> -[SIFIVE_E_DEBUG] ={0x0,  0x100 },
> > >>> +[SIFIVE_E_DEBUG] ={0x0, 0x1000 },
> > >>>  [SIFIVE_E_MROM] = { 0x1000, 0x2000 },
> > >>>  [SIFIVE_E_OTP] =  {0x2, 0x2000 },
> > >>>  [SIFIVE_E_CLINT] ={  0x200,0x1 },
> > >>>  [SIFIVE_E_PLIC] = {  0xc00,  0x400 },
> > >>> -[SIFIVE_E_AON] =  { 0x1000, 0x8000 },
> > >>> -[SIFIVE_E_PRCI] = { 0x10008000, 0x8000 },
> > >>> +[SIFIVE_E_AON] =  { 0x1000, 0x1000 },
> > >>> +[SIFIVE_E_PRCI] = { 0x10008000, 0x1000 },
> > >>>  [SIFIVE_E_OTP_CTRL] = { 0x1001, 0x1000 },
> > >>>  [SIFIVE_E_GPIO0] ={ 0x10012000, 0x1000 },
> > >>>  [SIFIVE_E_UART0] ={ 0x10013000, 0x1000 },
> > >>> --
> > >>> 2.7.4
> > >>>
> > >>
> > >> It seems the modification follows  E310-G002(Hifive1 Rev B) spec and the 
> > >> origin is for E310-G000(Hifive1) spec.
> > >> There should be some way to specify different board version with 
> > >> different memory map or we have policy, always support the latest spec.
> >
> > I agree with Chao, it would be cleaner to have two different boards
> > (machines).
> > Since the SoCs are very similar, you could add a 'revision' property and
> > use it to select the correct map.
> >
>
> I am not sure if adding two different machines will bring us a lot of
> benefits, since the only difference is the SoC revision with different
> block sizes.
>
> > >>
> > >
> > > Yes, I checked both specs. The older spec says these bigger sizes,
> > > however their register sizes fit well in the smaller range as well. So
> > > I think the modification works well for both.
> >
> > This is OK for the PRCI, since sifive_prci_create() does not use
> > memmap[SIFIVE_E_PRCI].size.
> >
> > However the AON case is borderline, since you shrink it from 32KiB to 4KiB.
> >
>
> AON is not implemented anyway currently. And I checked the FE310 old
> spec, its register block size is still within the 4KiB range, so
> shrinking the size should be fine for both old and new SoC.
>
> > BTW (not related to this patch) it is odd a function named
> > sifive_mmio_emulate() creates a RAM region with memory_region_init_ram()
> > and does not use the UnimplementedDevice (see make_unimp_dev() in
> > hw/arm/musca.c).
> >

What's your suggestion regarding this patch?

Regards,
Bin

Re: [Qemu-devel] [PATCH] ppc: Add support for 'mffsl' instruction

[Richard Henderson]

On 8/13/19 4:31 PM, Paul A. Clarke wrote:
> +TCGv_i64 mask = tcg_const_i64(FP_MODE | FP_STATUS | FP_ENABLES);
> +tcg_gen_and_i64(t0, t0, mask);

Better as

  tcg_gen_andi_i64(t0, t0, FP_MODE | FP_STATUS | FP_ENABLES);

You failed to free the temporary that you allocated here.


r~

Re: [Qemu-devel] [PATCH v2] riscv: rv32: Root page table address can be larger than 32-bit

[Bin Meng]

Hi Palmer,

On Sat, Aug 10, 2019 at 9:49 AM Alistair Francis  wrote:
>
> On Wed, Aug 7, 2019 at 7:50 PM Bin Meng  wrote:
> >
> > For RV32, the root page table's PPN has 22 bits hence its address
> > bits could be larger than the maximum bits that target_ulong is
> > able to represent. Use hwaddr instead.
> >
> > Signed-off-by: Bin Meng 
>
> Reviewed-by: Alistair Francis 
>

Would you take this one too?

Regards,
Bin

Re: [Qemu-devel] [PATCH] usb: reword -usb command-line option and mention xHCI

[Dr. David Alan Gilbert]

* Stefan Hajnoczi (stefa...@redhat.com) wrote:
> The -usb section of the man page is not very clear on what exactly -usb
> does and fails to mention xHCI as a modern alternative (-device
> nec-usb-xhci).

Isn't 'qemu-xhci' the current favoured device?

Dave

> Signed-off-by: Stefan Hajnoczi 
> ---
>  qemu-options.hx | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/qemu-options.hx b/qemu-options.hx
> index 9621e934c0..7d11c016d1 100644
> --- a/qemu-options.hx
> +++ b/qemu-options.hx
> @@ -1436,12 +1436,15 @@ STEXI
>  ETEXI
>  
>  DEF("usb", 0, QEMU_OPTION_usb,
> -"-usbenable the USB driver (if it is not used by default 
> yet)\n",
> +"-usbenable on-board USB host controller (if not enabled by 
> default)\n",
>  QEMU_ARCH_ALL)
>  STEXI
>  @item -usb
>  @findex -usb
> -Enable the USB driver (if it is not used by default yet).
> +Enable USB emulation on machine types with an on-board USB host controller 
> (if
> +not enabled by default).  Note that on-board USB host controllers may not
> +support USB 3.0.  In this case -device nec-usb-xhci can be used instead on
> +machines with PCI.
>  ETEXI
>  
>  DEF("usbdevice", HAS_ARG, QEMU_OPTION_usbdevice,
> -- 
> 2.21.0
> 
> 
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

[Qemu-devel] [PATCH 1/2] qapi: deprecate drive-mirror and drive-backup

[Vladimir Sementsov-Ogievskiy]

It's hard and not necessary to maintain outdated versions of these
commands.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
---
 qemu-deprecated.texi  |  4 
 qapi/block-core.json  |  4 
 qapi/transaction.json |  2 +-
 blockdev.c| 10 ++
 4 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi
index fff07bb2a3..2753fafd0b 100644
--- a/qemu-deprecated.texi
+++ b/qemu-deprecated.texi
@@ -179,6 +179,10 @@ and accurate ``query-qmp-schema'' command.
 Character devices creating sockets in client mode should not specify
 the 'wait' field, which is only applicable to sockets in server mode
 
+@subsection drive-mirror, drive-backup and drive-backup transaction action 
(since 4.2)
+
+Use blockdev-mirror and blockdev-backup instead.
+
 @section Human Monitor Protocol (HMP) commands
 
 @subsection The hub_id parameter of 'hostfwd_add' / 'hostfwd_remove' (since 
3.1)
diff --git a/qapi/block-core.json b/qapi/block-core.json
index 0d43d4f37c..4e35526634 100644
--- a/qapi/block-core.json
+++ b/qapi/block-core.json
@@ -1635,6 +1635,8 @@
 ##
 # @drive-backup:
 #
+# Command is deprecated, use blockdev-mirror instead.
+#
 # Start a point-in-time copy of a block device to a new destination.  The
 # status of ongoing drive-backup operations can be checked with
 # query-block-jobs where the BlockJobInfo.type field has the value 'backup'.
@@ -1855,6 +1857,8 @@
 ##
 # @drive-mirror:
 #
+# Command is deprecated, use blockdev-mirror instead.
+#
 # Start mirroring a block device's writes to a new destination. target
 # specifies the target of the new image. If the file exists, or if it
 # is a device, it will be used as the new destination for writes. If
diff --git a/qapi/transaction.json b/qapi/transaction.json
index 95edb78227..a16a9ff8a6 100644
--- a/qapi/transaction.json
+++ b/qapi/transaction.json
@@ -53,7 +53,7 @@
 # - @blockdev-snapshot: since 2.5
 # - @blockdev-snapshot-internal-sync: since 1.7
 # - @blockdev-snapshot-sync: since 1.1
-# - @drive-backup: since 1.6
+# - @drive-backup: deprecated action, since 1.6
 #
 # Since: 1.1
 ##
diff --git a/blockdev.c b/blockdev.c
index 4d141e9a1f..36e9368e01 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -1771,6 +1771,9 @@ static void drive_backup_prepare(BlkActionState *common, 
Error **errp)
 AioContext *aio_context;
 Error *local_err = NULL;
 
+warn_report("drive-backup transaction action is deprecated and will "
+"disappear in future. Use blockdev-backup action instead");
+
 assert(common->action->type == TRANSACTION_ACTION_KIND_DRIVE_BACKUP);
 backup = common->action->u.drive_backup.data;
 
@@ -3591,6 +3594,10 @@ void qmp_drive_backup(DriveBackup *arg, Error **errp)
 {
 
 BlockJob *job;
+
+warn_report("drive-backup command is deprecated and will disappear in "
+"future. Use blockdev-backup instead");
+
 job = do_drive_backup(arg, NULL, errp);
 if (job) {
 job_start(&job->job);
@@ -3831,6 +3838,9 @@ void qmp_drive_mirror(DriveMirror *arg, Error **errp)
 const char *format = arg->format;
 int ret;
 
+warn_report("drive-mirror command is deprecated and will disappear in "
+"future. Use blockdev-mirror instead");
+
 bs = qmp_get_root_bs(arg->device, errp);
 if (!bs) {
 return;
-- 
2.18.0

Re: [Qemu-devel] [PATCH-for-4.2 v2 3/6] s390x/tcg: Flush the TLB of all CPUs on SSKE and RRBE

[Alex Bennée]

David Hildenbrand  writes:

> Whenever we modify a storage key, we shuld flush the TLBs of all CPUs,
> so the MMU fault handling code can properly consider the changed storage
> key (to e.g., properly set the reference and change bit on the next
> accesses).
>
> These functions are barely used in modern Linux guests, so the performance
> implications are neglectable for now.
>
> This is a preparation for better reference and change bit handling for
> TCG, which will require more MMU changes.
>
> Reviewed-by: Cornelia Huck 
> Signed-off-by: David Hildenbrand 
> ---
>  target/s390x/mem_helper.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/target/s390x/mem_helper.c b/target/s390x/mem_helper.c
> index 29d9eaa5b7..ed54265e03 100644
> --- a/target/s390x/mem_helper.c
> +++ b/target/s390x/mem_helper.c
> @@ -1815,6 +1815,8 @@ void HELPER(sske)(CPUS390XState *env, uint64_t r1, 
> uint64_t r2)
>
>  key = (uint8_t) r1;
>  skeyclass->set_skeys(ss, addr / TARGET_PAGE_SIZE, 1, &key);
> +/* TODO: Flush only entries with this target address */
> +tlb_flush_all_cpus_synced(env_cpu(env));

Doesn't:

  tlb_flush_page_all_cpus_synced(env_cpu(env), addr & TARGET_PAGE_MASK);

do what you want here?

>  }
>
>  /* reset reference bit extended */
> @@ -1843,6 +1845,8 @@ uint32_t HELPER(rrbe)(CPUS390XState *env, uint64_t r2)
>  if (skeyclass->set_skeys(ss, r2 / TARGET_PAGE_SIZE, 1, &key)) {
>  return 0;
>  }
> +/* TODO: Flush only entries with this target address */
> +tlb_flush_all_cpus_synced(env_cpu(env));
>
>  /*
>   * cc


--
Alex Bennée

[Qemu-devel] [PATCH 0/2] Deprecate implicit filters

[Vladimir Sementsov-Ogievskiy]

Hi all!

Max's series to fix some problems around filters consists of 42 patches.
I'm sure that we didn't find all bugs around filters, and that filters
would be a constant source of bugs in future, as during developing new
feature nobody will consider all possible cases of dealing with filters
(OK, somebody will, but it's hard).

So, I'm thinking about starting some deprecations which will help us to
simplify all the picture at least in not far future. So, I'd really want
to deprecate implicit filters, ->file child based filters (move all
filters to use backing child), filename based interfaces (use node-names).

Most simple thing is implicit filters, so let's start from them.
drive-mirror don't support filter-node-name, so I propose to deprecate
it at all, together with drive-backup, instead of adding support of
filter-node-name, what do you think?

Vladimir Sementsov-Ogievskiy (2):
  qapi: deprecate drive-mirror and drive-backup
  qapi: deprecate implicit filters

 qemu-deprecated.texi  | 11 +++
 qapi/block-core.json  | 10 --
 qapi/transaction.json |  2 +-
 include/block/block_int.h | 10 +-
 blockdev.c| 20 
 5 files changed, 49 insertions(+), 4 deletions(-)

-- 
2.18.0

[Qemu-devel] [PATCH 2/2] qapi: deprecate implicit filters

[Vladimir Sementsov-Ogievskiy]

To get rid of implicit filters related workarounds in future let's
deprecate them now.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
---
 qemu-deprecated.texi  |  7 +++
 qapi/block-core.json  |  6 --
 include/block/block_int.h | 10 +-
 blockdev.c| 10 ++
 4 files changed, 30 insertions(+), 3 deletions(-)

diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi
index 2753fafd0b..8222440148 100644
--- a/qemu-deprecated.texi
+++ b/qemu-deprecated.texi
@@ -183,6 +183,13 @@ the 'wait' field, which is only applicable to sockets in 
server mode
 
 Use blockdev-mirror and blockdev-backup instead.
 
+@subsection implicit filters (since 4.2)
+
+Mirror and commit jobs inserts filters, which becomes implicit if user
+omitted filter-node-name parameter. So omitting it is deprecated, set it
+always. Note, that drive-mirror don't have this parameter, so it will
+create implicit filter anyway, but drive-mirror is deprecated itself too.
+
 @section Human Monitor Protocol (HMP) commands
 
 @subsection The hub_id parameter of 'hostfwd_add' / 'hostfwd_remove' (since 
3.1)
diff --git a/qapi/block-core.json b/qapi/block-core.json
index 4e35526634..0505ac9d8b 100644
--- a/qapi/block-core.json
+++ b/qapi/block-core.json
@@ -1596,7 +1596,8 @@
 # @filter-node-name: the node name that should be assigned to the
 #filter driver that the commit job inserts into the graph
 #above @top. If this option is not given, a node name is
-#autogenerated. (Since: 2.9)
+#autogenerated. Omitting this option is deprecated, it will
+#be required in future. (Since: 2.9)
 #
 # @auto-finalize: When false, this job will wait in a PENDING state after it 
has
 # finished its work, waiting for @block-job-finalize before
@@ -2249,7 +2250,8 @@
 # @filter-node-name: the node name that should be assigned to the
 #filter driver that the mirror job inserts into the graph
 #above @device. If this option is not given, a node name is
-#autogenerated. (Since: 2.9)
+#autogenerated. Omitting this option is deprecated, it will
+#be required in future. (Since: 2.9)
 #
 # @copy-mode: when to copy data to the destination; defaults to 'background'
 # (Since: 3.0)
diff --git a/include/block/block_int.h b/include/block/block_int.h
index 3aa1e832a8..624da0b4a2 100644
--- a/include/block/block_int.h
+++ b/include/block/block_int.h
@@ -762,7 +762,15 @@ struct BlockDriverState {
 bool sg;/* if true, the device is a /dev/sg* */
 bool probed;/* if true, format was probed rather than specified */
 bool force_share; /* if true, always allow all shared permissions */
-bool implicit;  /* if true, this filter node was automatically inserted */
+
+/*
+ * @implicit field is deprecated, don't set it to true for new filters.
+ * If true, this filter node was automatically inserted and user don't
+ * know about it and unprepared for any effects of it. So, implicit
+ * filters are workarounded and skipped in many places of the block
+ * layer code.
+ */
+bool implicit;
 
 BlockDriver *drv; /* NULL means no media */
 void *opaque;
diff --git a/blockdev.c b/blockdev.c
index 36e9368e01..b3cfaccce1 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -3292,6 +3292,11 @@ void qmp_block_commit(bool has_job_id, const char 
*job_id, const char *device,
 BlockdevOnError on_error = BLOCKDEV_ON_ERROR_REPORT;
 int job_flags = JOB_DEFAULT;
 
+if (!has_filter_node_name) {
+warn_report("Omitting filter-node-name parameter is deprecated, it "
+"will be required in future");
+}
+
 if (!has_speed) {
 speed = 0;
 }
@@ -3990,6 +3995,11 @@ void qmp_blockdev_mirror(bool has_job_id, const char 
*job_id,
 Error *local_err = NULL;
 int ret;
 
+if (!has_filter_node_name) {
+warn_report("Omitting filter-node-name parameter is deprecated, it "
+"will be required in future");
+}
+
 bs = qmp_get_root_bs(device, errp);
 if (!bs) {
 return;
-- 
2.18.0

Re: [Qemu-devel] [PATCH-for-4.2 v2 3/6] s390x/tcg: Flush the TLB of all CPUs on SSKE and RRBE

[David Hildenbrand]

On 14.08.19 12:06, Alex Bennée wrote:
> 
> David Hildenbrand  writes:
> 
>> Whenever we modify a storage key, we shuld flush the TLBs of all CPUs,
>> so the MMU fault handling code can properly consider the changed storage
>> key (to e.g., properly set the reference and change bit on the next
>> accesses).
>>
>> These functions are barely used in modern Linux guests, so the performance
>> implications are neglectable for now.
>>
>> This is a preparation for better reference and change bit handling for
>> TCG, which will require more MMU changes.
>>
>> Reviewed-by: Cornelia Huck 
>> Signed-off-by: David Hildenbrand 
>> ---
>>  target/s390x/mem_helper.c | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/target/s390x/mem_helper.c b/target/s390x/mem_helper.c
>> index 29d9eaa5b7..ed54265e03 100644
>> --- a/target/s390x/mem_helper.c
>> +++ b/target/s390x/mem_helper.c
>> @@ -1815,6 +1815,8 @@ void HELPER(sske)(CPUS390XState *env, uint64_t r1, 
>> uint64_t r2)
>>
>>  key = (uint8_t) r1;
>>  skeyclass->set_skeys(ss, addr / TARGET_PAGE_SIZE, 1, &key);
>> +/* TODO: Flush only entries with this target address */
>> +tlb_flush_all_cpus_synced(env_cpu(env));
> 
> Doesn't:
> 
>   tlb_flush_page_all_cpus_synced(env_cpu(env), addr & TARGET_PAGE_MASK);
> 
> do what you want here?

I would have to flush all TLB entries that target this physical page,
not the entry of the single virtual page. So that does, unfortunately,
not work.

-- 

Thanks,

David / dhildenb

Re: [Qemu-devel] [PATCH v3 1/2] scsi: lsi: exit infinite loop while executing script (CVE-2019-12068)

[P J P]

+-- On Tue, 13 Aug 2019, Paolo Bonzini wrote --+
| After the first instruction is processed, "again" is only reached if 
| s->waiting == LSI_NOWAIT.  Therefore, we could move the Windows hack to the 
| beginning and remove the s->waiting condition.  The only change would be 
| that it would also be triggered by all zero instructions, like this:
| 
| diff --git a/hw/scsi/lsi53c895a.c b/hw/scsi/lsi53c895a.c
| index 10468c1..9d714af 100644
| --- a/hw/scsi/lsi53c895a.c
| +++ b/hw/scsi/lsi53c895a.c
| @@ -185,6 +185,9 @@ static const char *names[] = {
|  /* Flag set if this is a tagged command.  */
|  #define LSI_TAG_VALID (1 << 16)
|  
| +/* Maximum instructions to process. */
| +#define LSI_MAX_INSN1
| +
|  typedef struct lsi_request {
|  SCSIRequest *req;
|  uint32_t tag;
| @@ -1132,7 +1135,19 @@ static void lsi_execute_script(LSIState *s)
|  
|  s->istat1 |= LSI_ISTAT1_SRUN;
|  again:
| -insn_processed++;
| +if (++insn_processed > LSI_MAX_INSN) {
| +/* Some windows drivers make the device spin waiting for a memory
| +   location to change.  If we have been executed a lot of code then
| +   assume this is the case and force an unexpected device disconnect.
| +   This is apparently sufficient to beat the drivers into submission.
| + */
| +if (!(s->sien0 & LSI_SIST0_UDC)) {
| +qemu_log_mask(LOG_GUEST_ERROR,
| +  "lsi_scsi: inf. loop with UDC masked");
| +}
| +lsi_script_scsi_interrupt(s, LSI_SIST0_UDC, 0);
| +lsi_disconnect(s);
...
|
| Does it make sense? 

Yes, this'd also work, but need to return after lsi_disconnect(s), otherwise 
loop would continue.

Should I send a revised patch? (with above change)

Thank you.
--
Prasad J Pandit / Red Hat Product Security Team
47AF CE69 3A90 54AA 9045 1053 DD13 3D32 FE5B 041F

Re: [Qemu-devel] [PATCH v3 1/2] scsi: lsi: exit infinite loop while executing script (CVE-2019-12068)

[Paolo Bonzini]

On 14/08/19 12:25, P J P wrote:
> +-- On Tue, 13 Aug 2019, Paolo Bonzini wrote --+
> | After the first instruction is processed, "again" is only reached if 
> | s->waiting == LSI_NOWAIT.  Therefore, we could move the Windows hack to the 
> | beginning and remove the s->waiting condition.  The only change would be 
> | that it would also be triggered by all zero instructions, like this:
> | 
> | diff --git a/hw/scsi/lsi53c895a.c b/hw/scsi/lsi53c895a.c
> | index 10468c1..9d714af 100644
> | --- a/hw/scsi/lsi53c895a.c
> | +++ b/hw/scsi/lsi53c895a.c
> | @@ -185,6 +185,9 @@ static const char *names[] = {
> |  /* Flag set if this is a tagged command.  */
> |  #define LSI_TAG_VALID (1 << 16)
> |  
> | +/* Maximum instructions to process. */
> | +#define LSI_MAX_INSN1
> | +
> |  typedef struct lsi_request {
> |  SCSIRequest *req;
> |  uint32_t tag;
> | @@ -1132,7 +1135,19 @@ static void lsi_execute_script(LSIState *s)
> |  
> |  s->istat1 |= LSI_ISTAT1_SRUN;
> |  again:
> | -insn_processed++;
> | +if (++insn_processed > LSI_MAX_INSN) {
> | +/* Some windows drivers make the device spin waiting for a memory
> | +   location to change.  If we have been executed a lot of code then
> | +   assume this is the case and force an unexpected device 
> disconnect.
> | +   This is apparently sufficient to beat the drivers into 
> submission.
> | + */
> | +if (!(s->sien0 & LSI_SIST0_UDC)) {
> | +qemu_log_mask(LOG_GUEST_ERROR,
> | +  "lsi_scsi: inf. loop with UDC masked");
> | +}
> | +lsi_script_scsi_interrupt(s, LSI_SIST0_UDC, 0);
> | +lsi_disconnect(s);
> ...
> |
> | Does it make sense? 
> 
> Yes, this'd also work, but need to return after lsi_disconnect(s), otherwise 
> loop would continue.
> 
> Should I send a revised patch? (with above change)

Yes, please.

Paolo

Re: [Qemu-devel] [PATCH v4] migration: do not rom_reset() during incoming migration

[Catherine Ho]

Hi Paolo
Ping, is any other comment I hadn't addressed?

Cheers
Catherine

On Thu, 6 Jun 2019 at 02:31, Dr. David Alan Gilbert 
wrote:

> Paolo, can you take this one please.
>
> * Catherine Ho (catherine.h...@gmail.com) wrote:
> > Commit 18269069c310 ("migration: Introduce ignore-shared capability")
> > addes ignore-shared capability to bypass the shared ramblock (e,g,
> > membackend + numa node). It does good to live migration.
> >
> > As told by Yury,this commit expectes that QEMU doesn't write to guest RAM
> > until VM starts, but it does on aarch64 qemu:
> > Backtrace:
> > 1  0x55f4a296dd84 in address_space_write_rom_internal () at
> > exec.c:3458
> > 2  0x55f4a296de3a in address_space_write_rom () at exec.c:3479
> > 3  0x55f4a2d519ff in rom_reset () at hw/core/loader.c:1101
> > 4  0x55f4a2d475ec in qemu_devices_reset () at hw/core/reset.c:69
> > 5  0x55f4a2c90a28 in qemu_system_reset () at vl.c:1675
> > 6  0x55f4a2c9851d in main () at vl.c:4552
> >
> > Actually, on arm64 virt marchine, ramblock "dtb" will be filled into ram
> > druing rom_reset. In ignore-shared incoming case, this rom filling
> > is not required since all the data has been stored in memory backend
> > file.
> >
> > Further more, as suggested by Peter Xu, if we do rom_reset() now with
> > these ROMs then the RAM data should be re-filled again too with the
> > migration stream coming in.
> >
> > Fixes: commit 18269069c310 ("migration: Introduce ignore-shared
> > capability")
> > Suggested-by: Yury Kotov 
> > Suggested-by: Peter Xu 
> > Signed-off-by: Catherine Ho 
> > ---
> >  hw/core/loader.c | 9 +
> >  1 file changed, 9 insertions(+)
> >
> > diff --git a/hw/core/loader.c b/hw/core/loader.c
> > index fe5cb24122..040109464b 100644
> > --- a/hw/core/loader.c
> > +++ b/hw/core/loader.c
> > @@ -1087,6 +1087,15 @@ static void rom_reset(void *unused)
> >  {
> >  Rom *rom;
> >
> > +/*
> > + * We don't need to fill in the RAM with ROM data because we'll fill
> > + * the data in during the next incoming migration in all cases.
> Note
> > + * that some of those RAMs can actually be modified by the guest on
> ARM
> > + * so this is probably the only right thing to do here.
> > + */
> > +if (runstate_check(RUN_STATE_INMIGRATE))
> > +return;
> > +
> >  QTAILQ_FOREACH(rom, &roms, next) {
> >  if (rom->fw_file) {
> >  continue;
> > --
> > 2.17.1
> >
> --
> Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
>

Re: [Qemu-devel] [PATCH-for-4.2 v2 3/6] s390x/tcg: Flush the TLB of all CPUs on SSKE and RRBE

[Alex Bennée]

David Hildenbrand  writes:

> On 14.08.19 12:06, Alex Bennée wrote:
>>
>> David Hildenbrand  writes:
>>
>>> Whenever we modify a storage key, we shuld flush the TLBs of all CPUs,
>>> so the MMU fault handling code can properly consider the changed storage
>>> key (to e.g., properly set the reference and change bit on the next
>>> accesses).
>>>
>>> These functions are barely used in modern Linux guests, so the performance
>>> implications are neglectable for now.
>>>
>>> This is a preparation for better reference and change bit handling for
>>> TCG, which will require more MMU changes.
>>>
>>> Reviewed-by: Cornelia Huck 
>>> Signed-off-by: David Hildenbrand 
>>> ---
>>>  target/s390x/mem_helper.c | 4 
>>>  1 file changed, 4 insertions(+)
>>>
>>> diff --git a/target/s390x/mem_helper.c b/target/s390x/mem_helper.c
>>> index 29d9eaa5b7..ed54265e03 100644
>>> --- a/target/s390x/mem_helper.c
>>> +++ b/target/s390x/mem_helper.c
>>> @@ -1815,6 +1815,8 @@ void HELPER(sske)(CPUS390XState *env, uint64_t r1, 
>>> uint64_t r2)
>>>
>>>  key = (uint8_t) r1;
>>>  skeyclass->set_skeys(ss, addr / TARGET_PAGE_SIZE, 1, &key);
>>> +/* TODO: Flush only entries with this target address */
>>> +tlb_flush_all_cpus_synced(env_cpu(env));
>>
>> Doesn't:
>>
>>   tlb_flush_page_all_cpus_synced(env_cpu(env), addr & TARGET_PAGE_MASK);
>>
>> do what you want here?
>
> I would have to flush all TLB entries that target this physical page,
> not the entry of the single virtual page. So that does, unfortunately,
> not work.

Ahh I see. Well maybe that should be the comment instead:

  /*
   * As we can only flush by virtual address and not all the entries
   * that point to a physical address we have to flush the whole TLB
   * here.
   */
   tlb_flush_all_cpus_synced(env_cpu(env));

?


--
Alex Bennée

Re: [Qemu-devel] [PATCH-for-4.2 v2 3/6] s390x/tcg: Flush the TLB of all CPUs on SSKE and RRBE

[David Hildenbrand]

On 14.08.19 12:44, Alex Bennée wrote:
> 
> David Hildenbrand  writes:
> 
>> On 14.08.19 12:06, Alex Bennée wrote:
>>>
>>> David Hildenbrand  writes:
>>>
 Whenever we modify a storage key, we shuld flush the TLBs of all CPUs,
 so the MMU fault handling code can properly consider the changed storage
 key (to e.g., properly set the reference and change bit on the next
 accesses).

 These functions are barely used in modern Linux guests, so the performance
 implications are neglectable for now.

 This is a preparation for better reference and change bit handling for
 TCG, which will require more MMU changes.

 Reviewed-by: Cornelia Huck 
 Signed-off-by: David Hildenbrand 
 ---
  target/s390x/mem_helper.c | 4 
  1 file changed, 4 insertions(+)

 diff --git a/target/s390x/mem_helper.c b/target/s390x/mem_helper.c
 index 29d9eaa5b7..ed54265e03 100644
 --- a/target/s390x/mem_helper.c
 +++ b/target/s390x/mem_helper.c
 @@ -1815,6 +1815,8 @@ void HELPER(sske)(CPUS390XState *env, uint64_t r1, 
 uint64_t r2)

  key = (uint8_t) r1;
  skeyclass->set_skeys(ss, addr / TARGET_PAGE_SIZE, 1, &key);
 +/* TODO: Flush only entries with this target address */
 +tlb_flush_all_cpus_synced(env_cpu(env));
>>>
>>> Doesn't:
>>>
>>>   tlb_flush_page_all_cpus_synced(env_cpu(env), addr & TARGET_PAGE_MASK);
>>>
>>> do what you want here?
>>
>> I would have to flush all TLB entries that target this physical page,
>> not the entry of the single virtual page. So that does, unfortunately,
>> not work.
> 
> Ahh I see. Well maybe that should be the comment instead:
> 
>   /*
>* As we can only flush by virtual address and not all the entries
>* that point to a physical address we have to flush the whole TLB
>* here.
>*/
>tlb_flush_all_cpus_synced(env_cpu(env));
> 
> ?

I think "entries that target this address" makes it clear that we are
talking about the TLB entry target address, not the virtual source
address. But I can adjust it. Thanks.

-- 

Thanks,

David / dhildenb

Re: [Qemu-devel] [PATCH 1/6] migration: Add traces for multifd terminate threads

[Dr. David Alan Gilbert]

* Juan Quintela (quint...@redhat.com) wrote:
> Signed-off-by: Juan Quintela 

Reviewed-by: Dr. David Alan Gilbert 

and queued

> ---
>  migration/ram.c| 4 
>  migration/trace-events | 2 ++
>  2 files changed, 6 insertions(+)
> 
> diff --git a/migration/ram.c b/migration/ram.c
> index 889148dd84..ca11d43e30 100644
> --- a/migration/ram.c
> +++ b/migration/ram.c
> @@ -996,6 +996,8 @@ static void multifd_send_terminate_threads(Error *err)
>  {
>  int i;
>  
> +trace_multifd_send_terminate_threads(err != NULL);
> +
>  if (err) {
>  MigrationState *s = migrate_get_current();
>  migrate_set_error(s, err);
> @@ -1254,6 +1256,8 @@ static void multifd_recv_terminate_threads(Error *err)
>  {
>  int i;
>  
> +trace_multifd_recv_terminate_threads(err != NULL);
> +
>  if (err) {
>  MigrationState *s = migrate_get_current();
>  migrate_set_error(s, err);
> diff --git a/migration/trace-events b/migration/trace-events
> index d8e54c367a..886ce70ca0 100644
> --- a/migration/trace-events
> +++ b/migration/trace-events
> @@ -85,12 +85,14 @@ multifd_recv(uint8_t id, uint64_t packet_num, uint32_t 
> used, uint32_t flags, uin
>  multifd_recv_sync_main(long packet_num) "packet num %ld"
>  multifd_recv_sync_main_signal(uint8_t id) "channel %d"
>  multifd_recv_sync_main_wait(uint8_t id) "channel %d"
> +multifd_recv_terminate_threads(bool error) "error %d"
>  multifd_recv_thread_end(uint8_t id, uint64_t packets, uint64_t pages) 
> "channel %d packets %" PRIu64 " pages %" PRIu64
>  multifd_recv_thread_start(uint8_t id) "%d"
>  multifd_send(uint8_t id, uint64_t packet_num, uint32_t used, uint32_t flags, 
> uint32_t next_packet_size) "channel %d packet_num %" PRIu64 " pages %d flags 
> 0x%x next packet size %d"
>  multifd_send_sync_main(long packet_num) "packet num %ld"
>  multifd_send_sync_main_signal(uint8_t id) "channel %d"
>  multifd_send_sync_main_wait(uint8_t id) "channel %d"
> +multifd_send_terminate_threads(bool error) "error %d"
>  multifd_send_thread_end(uint8_t id, uint64_t packets, uint64_t pages) 
> "channel %d packets %" PRIu64 " pages %"  PRIu64
>  multifd_send_thread_start(uint8_t id) "%d"
>  ram_discard_range(const char *rbname, uint64_t start, size_t len) "%s: 
> start: %" PRIx64 " %zx"
> -- 
> 2.21.0
> 
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

Re: [Qemu-devel] [PATCH 1/1] x86: add CPU flags supported inside libvirt

[Jiri Denemark]

On Thu, Jul 18, 2019 at 16:45:37 +0300, Denis V. Lunev wrote:
> There are the following flags available in libvirt inside cpu_map.xm
> 
>   
> 
>  
>   
> 
> We have faced the problem that QEMU does not start once these flags are
> present in the domain.xml.

Libvirt should not add this to the XML by itself (when using host-model
CPU, for example) so the user must have asked for the feature
explicitly. Thus I don't see any problem with QEMU refusing to start
with such configuration. And the workaround is easy, just don't do it.

I'm not sure about cvt16, but IIRC cmt and mbm_* features were added as
a way to detect whether the host CPU supports perf monitoring counters.
I think tt was not the brightest idea, but there's no reason why QEMU
should support enabling these features. Unless it actually makes sense
for QEMU.

If there are any issues with libvirt passing these features to QEMU
without explicit request from the user, we should address them in
libvirt.

Jirka

Re: [Qemu-devel] [PATCH 0/6] Fix multifd with big number of channels

[no-reply]

Patchew URL: https://patchew.org/QEMU/20190814020218.1868-1-quint...@redhat.com/



Hi,

This series failed the asan build test. Please find the testing commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.

=== TEST SCRIPT BEGIN ===
#!/bin/bash
make docker-image-fedora V=1 NETWORK=1
time make docker-test-debug@fedora TARGET_LIST=x86_64-softmmu J=14 NETWORK=1
=== TEST SCRIPT END ===

PASS 1 fdc-test /x86_64/fdc/cmos
PASS 2 fdc-test /x86_64/fdc/no_media_on_start
PASS 3 fdc-test /x86_64/fdc/read_without_media
==8022==WARNING: ASan doesn't fully support makecontext/swapcontext functions 
and may produce false positives in some cases!
PASS 4 fdc-test /x86_64/fdc/media_change
PASS 5 fdc-test /x86_64/fdc/sense_interrupt
PASS 6 fdc-test /x86_64/fdc/relative_seek
---
PASS 32 test-opts-visitor /visitor/opts/range/beyond
PASS 33 test-opts-visitor /visitor/opts/dict/unvisited
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  
tests/test-coroutine -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl 
--test-name="test-coroutine" 
==8066==WARNING: ASan doesn't fully support makecontext/swapcontext functions 
and may produce false positives in some cases!
==8066==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top: 
0x7ffce27db000; bottom 0x7f337a3f8000; size: 0x00c9683e3000 (865037332480)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
PASS 1 test-coroutine /basic/no-dangling-access
---
PASS 13 test-aio /aio/event/wait/no-flush-cb
PASS 12 fdc-test /x86_64/fdc/read_no_dma_19
PASS 14 test-aio /aio/timer/schedule
==8085==WARNING: ASan doesn't fully support makecontext/swapcontext functions 
and may produce false positives in some cases!
PASS 13 fdc-test /x86_64/fdc/fuzz-registers
PASS 15 test-aio /aio/coroutine/queue-chaining
PASS 16 test-aio /aio-gsource/flush
---
PASS 26 test-aio /aio-gsource/event/flush
PASS 27 test-aio /aio-gsource/event/wait/no-flush-cb
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  
QTEST_QEMU_BINARY=x86_64-softmmu/qemu-system-x86_64 QTEST_QEMU_IMG=qemu-img 
tests/ide-test -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl 
--test-name="ide-test" 
==8094==WARNING: ASan doesn't fully support makecontext/swapcontext functions 
and may produce false positives in some cases!
PASS 28 test-aio /aio-gsource/timer/schedule
PASS 1 ide-test /x86_64/ide/identify
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  
tests/test-aio-multithread -m=quick -k --tap < /dev/null | 
./scripts/tap-driver.pl --test-name="test-aio-multithread" 
==8103==WARNING: ASan doesn't fully support makecontext/swapcontext functions 
and may produce false positives in some cases!
PASS 1 test-aio-multithread /aio/multi/lifecycle
==8101==WARNING: ASan doesn't fully support makecontext/swapcontext functions 
and may produce false positives in some cases!
PASS 2 ide-test /x86_64/ide/flush
PASS 2 test-aio-multithread /aio/multi/schedule
==8121==WARNING: ASan doesn't fully support makecontext/swapcontext functions 
and may produce false positives in some cases!
PASS 3 ide-test /x86_64/ide/bmdma/simple_rw
PASS 3 test-aio-multithread /aio/multi/mutex/contended
==8132==WARNING: ASan doesn't fully support makecontext/swapcontext functions 
and may produce false positives in some cases!
PASS 4 ide-test /x86_64/ide/bmdma/trim
==8143==WARNING: ASan doesn't fully support makecontext/swapcontext functions 
and may produce false positives in some cases!
PASS 5 ide-test /x86_64/ide/bmdma/short_prdt
==8149==WARNING: ASan doesn't fully support makecontext/swapcontext functions 
and may produce false positives in some cases!
PASS 6 ide-test /x86_64/ide/bmdma/one_sector_short_prdt
PASS 4 test-aio-multithread /aio/multi/mutex/handoff
==8155==WARNING: ASan doesn't fully support makecontext/swapcontext functions 
and may produce false positives in some cases!
PASS 7 ide-test /x86_64/ide/bmdma/long_prdt
PASS 5 test-aio-multithread /aio/multi/mutex/mcs
==8166==WARNING: ASan doesn't fully support makecontext/swapcontext functions 
and may produce false positives in some cases!
==8166==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top: 
0x7fff3d833000; bottom 0x7efe37d76000; size: 0x010105abd000 (1103901741056)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
PASS 8 ide-test /x86_64/ide/bmdma/no_busmaster
PASS 6 test-aio-multithread /aio/multi/mutex/pthread
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  
tests/test-throttle -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl 
--test-name="test-throttle" 
==8183==WARNING: ASan doesn't fully support makecontext/swapcontext functions 
and may produce false positives in some cases!
PASS 1 test-throttle /throttle/leak_bucket
PASS 2 test-throttle /throttle/compute_wait
PASS 3 test-throttle /throttle/init
---
PASS 15 test-throttle /throttle/conf

Re: [Qemu-devel] [PATCH] usbredir: fix buffer-overflow on vmload

[Gerd Hoffmann]

On Wed, Aug 07, 2019 at 12:40:48PM +0400, Marc-André Lureau wrote:
> If interface_count is NO_INTERFACE_INFO, let's not access the arrays
> out-of-bounds.
> 
> ==994==ERROR: AddressSanitizer: heap-buffer-overflow on address 
> 0x625000243930 at pc 0x5642068086a8 bp 0x7f0b6f9ffa50 sp 0x7f0b6f9ffa40
> READ of size 1 at 0x625000243930 thread T0
> #0 0x5642068086a7 in usbredir_check_bulk_receiving 
> /home/elmarco/src/qemu/hw/usb/redirect.c:1503
> #1 0x56420681301c in usbredir_post_load 
> /home/elmarco/src/qemu/hw/usb/redirect.c:2154
> #2 0x5642068a56c2 in vmstate_load_state 
> /home/elmarco/src/qemu/migration/vmstate.c:168
> #3 0x56420688e2ac in vmstate_load 
> /home/elmarco/src/qemu/migration/savevm.c:829
> #4 0x5642068980cb in qemu_loadvm_section_start_full 
> /home/elmarco/src/qemu/migration/savevm.c:2211
> #5 0x564206899645 in qemu_loadvm_state_main 
> /home/elmarco/src/qemu/migration/savevm.c:2395
> #6 0x5642068998cf in qemu_loadvm_state 
> /home/elmarco/src/qemu/migration/savevm.c:2467
> #7 0x56420685f3e9 in process_incoming_migration_co 
> /home/elmarco/src/qemu/migration/migration.c:449
> #8 0x564207106c47 in coroutine_trampoline 
> /home/elmarco/src/qemu/util/coroutine-ucontext.c:115
> #9 0x7f0c0604e37f  (/lib64/libc.so.6+0x4d37f)
> 
> Signed-off-by: Marc-André Lureau 

Added to usb queue.

thanks,
  Gerd

[Qemu-devel] [PATCH v4] scsi: lsi: exit infinite loop while executing script (CVE-2019-12068)

[P J P]

From: Prasad J Pandit 

When executing script in lsi_execute_script(), the LSI scsi adapter
emulator advances 's->dsp' index to read next opcode. This can lead
to an infinite loop if the next opcode is empty. Exit such loop
after 10k iterations.

Reported-by: Bugs SysSec 
Signed-off-by: Prasad J Pandit 
---
 hw/scsi/lsi53c895a.c | 41 +++--
 1 file changed, 27 insertions(+), 14 deletions(-)

Update v4: slightly modify the check and exit
  -> https://lists.gnu.org/archive/html/qemu-devel/2019-08/msg02304.html

diff --git a/hw/scsi/lsi53c895a.c b/hw/scsi/lsi53c895a.c
index 10468c1ec1..72f7b59ab5 100644
--- a/hw/scsi/lsi53c895a.c
+++ b/hw/scsi/lsi53c895a.c
@@ -185,6 +185,9 @@ static const char *names[] = {
 /* Flag set if this is a tagged command.  */
 #define LSI_TAG_VALID (1 << 16)
 
+/* Maximum instructions to process. */
+#define LSI_MAX_INSN1
+
 typedef struct lsi_request {
 SCSIRequest *req;
 uint32_t tag;
@@ -1132,7 +1135,21 @@ static void lsi_execute_script(LSIState *s)
 
 s->istat1 |= LSI_ISTAT1_SRUN;
 again:
-insn_processed++;
+if (++insn_processed > LSI_MAX_INSN) {
+/* Some windows drivers make the device spin waiting for a memory
+   location to change.  If we have been executed a lot of code then
+   assume this is the case and force an unexpected device disconnect.
+   This is apparently sufficient to beat the drivers into submission.
+ */
+if (!(s->sien0 & LSI_SIST0_UDC)) {
+qemu_log_mask(LOG_GUEST_ERROR,
+  "lsi_scsi: inf. loop with UDC masked");
+}
+lsi_script_scsi_interrupt(s, LSI_SIST0_UDC, 0);
+lsi_disconnect(s);
+trace_lsi_execute_script_stop();
+return;
+}
 insn = read_dword(s, s->dsp);
 if (!insn) {
 /* If we receive an empty opcode increment the DSP by 4 bytes
@@ -1569,19 +1586,7 @@ again:
 }
 }
 }
-if (insn_processed > 1 && s->waiting == LSI_NOWAIT) {
-/* Some windows drivers make the device spin waiting for a memory
-   location to change.  If we have been executed a lot of code then
-   assume this is the case and force an unexpected device disconnect.
-   This is apparently sufficient to beat the drivers into submission.
- */
-if (!(s->sien0 & LSI_SIST0_UDC)) {
-qemu_log_mask(LOG_GUEST_ERROR,
-  "lsi_scsi: inf. loop with UDC masked");
-}
-lsi_script_scsi_interrupt(s, LSI_SIST0_UDC, 0);
-lsi_disconnect(s);
-} else if (s->istat1 & LSI_ISTAT1_SRUN && s->waiting == LSI_NOWAIT) {
+if (s->istat1 & LSI_ISTAT1_SRUN && s->waiting == LSI_NOWAIT) {
 if (s->dcntl & LSI_DCNTL_SSM) {
 lsi_script_dma_interrupt(s, LSI_DSTAT_SSI);
 } else {
@@ -1969,6 +1974,10 @@ static void lsi_reg_writeb(LSIState *s, int offset, 
uint8_t val)
 case 0x2f: /* DSP[24:31] */
 s->dsp &= 0x00ff;
 s->dsp |= val << 24;
+/*
+ * FIXME: if s->waiting != LSI_NOWAIT, this will only execute one
+ * instruction.  Is this correct?
+ */
 if ((s->dmode & LSI_DMODE_MAN) == 0
 && (s->istat1 & LSI_ISTAT1_SRUN) == 0)
 lsi_execute_script(s);
@@ -1987,6 +1996,10 @@ static void lsi_reg_writeb(LSIState *s, int offset, 
uint8_t val)
 break;
 case 0x3b: /* DCNTL */
 s->dcntl = val & ~(LSI_DCNTL_PFF | LSI_DCNTL_STD);
+/*
+ * FIXME: if s->waiting != LSI_NOWAIT, this will only execute one
+ * instruction.  Is this correct?
+ */
 if ((val & LSI_DCNTL_STD) && (s->istat1 & LSI_ISTAT1_SRUN) == 0)
 lsi_execute_script(s);
 break;
-- 
2.21.0

Re: [Qemu-devel] [PATCH v3 1/2] scsi: lsi: exit infinite loop while executing script (CVE-2019-12068)

[P J P]

+-- On Wed, 14 Aug 2019, Paolo Bonzini wrote --+
| On 14/08/19 12:25, P J P wrote:
| > Should I send a revised patch? (with above change)
| 
| Yes, please.

Sent v4. Thank you.
--
Prasad J Pandit / Red Hat Product Security Team
47AF CE69 3A90 54AA 9045 1053 DD13 3D32 FE5B 041F

Re: [Qemu-devel] [PATCH 1/1] usb-redir: merge interrupt packets

[Gerd Hoffmann]

On Wed, Jul 24, 2019 at 02:58:59PM +0200, Martin Cerveny wrote:
> Interrupt packets (limited by wMaxPacketSize) should be buffered and merged
> by algorithm described in USB spec.
> (see usb_20.pdf/5.7.3 Interrupt Transfer Packet Size Constraints).

Added to usb patch queue.

thanks,
  Gerd

Re: [Qemu-devel] [PATCH] xhci: Add No Op Command

[Gerd Hoffmann]

On Sat, Jul 20, 2019 at 03:04:27PM +0900, hikaru...@gmail.com wrote:
> From: Hikaru Nishida 
> 
> This commit adds No Op Command (23) to xHC for verifying the operation
> of the Command Ring mechanisms.
> No Op Command is defined in XHCI spec (4.6.2) and just reports Command
> Completion Event with Completion Code == Success.
> Before this commit, No Op Command is not implemented so xHC reports
> Command Completion Event with Completion Code == TRB Error. This commit
> fixes this behaviour to report Completion Code correctly.
> 
> Signed-off-by: Hikaru Nishida 

Added to usb patch queue.

thanks,
  Gerd

[Qemu-devel] [PATCH 0/4] configure: Fix libssh on Ubuntu 18.04

[Philippe Mathieu-Daudé]

Since a long time occured between libssh 0.7 and libssh 0.8,
distributions went cherry-picking improvments from the trunk
branch into their 0.7 branch, leading to packages versioned
as 0.7 but having 0.8 features.

This series fixes the oddest combination found so far, packaged
with Ubuntu 18.04.

This fixes https://bugs.launchpad.net/qemu/+bug/1838763

Philippe Mathieu-Daudé (4):
  RFC configure: Improve libssh check
  configure: Avoid using libssh deprecated API
  configure: Improve checking libssh version is 0.8
  configure: Log the libssh version detected

 block/ssh.c |  2 +-
 configure   | 21 +++--
 2 files changed, 20 insertions(+), 3 deletions(-)

-- 
2.20.1

[Qemu-devel] [PATCH 2/4] configure: Avoid using libssh deprecated API

[Philippe Mathieu-Daudé]

The libssh packaged by a distribution can predate version 0.8,
but still provides the newer API introduced after version 0.7.

Using the deprecated API leads to build failure, as on Ubuntu 18.04:

CC  block/ssh.o
  block/ssh.c: In function 'check_host_key_hash':
  block/ssh.c:444:5: error: 'ssh_get_publickey' is deprecated 
[-Werror=deprecated-declarations]
   r = ssh_get_publickey(s->session, &pubkey);
   ^
  In file included from block/ssh.c:27:0:
  /usr/include/libssh/libssh.h:489:31: note: declared here
   SSH_DEPRECATED LIBSSH_API int ssh_get_publickey(ssh_session session, ssh_key 
*key);
 ^
  rules.mak:69: recipe for target 'block/ssh.o' failed
  make: *** [block/ssh.o] Error 1

Fix by using the newer API if available.

Suggested-by: Andrea Bolognani 
Signed-off-by: Philippe Mathieu-Daudé 
---
 block/ssh.c | 2 +-
 configure   | 7 +++
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/block/ssh.c b/block/ssh.c
index 501933b855..f5fea921c6 100644
--- a/block/ssh.c
+++ b/block/ssh.c
@@ -438,7 +438,7 @@ check_host_key_hash(BDRVSSHState *s, const char *hash,
 unsigned char *server_hash;
 size_t server_hash_len;
 
-#ifdef HAVE_LIBSSH_0_8
+#ifdef HAVE_SSH_GET_SERVER_PUBLICKEY
 r = ssh_get_server_publickey(s->session, &pubkey);
 #else
 r = ssh_get_publickey(s->session, &pubkey);
diff --git a/configure b/configure
index 1d5c07de1f..fe3fef9309 100755
--- a/configure
+++ b/configure
@@ -3949,11 +3949,18 @@ fi
 if test "$libssh" = "yes"; then
   cat > $TMPC <
+#ifdef HAVE_SSH_GET_SERVER_PUBLICKEY
 int main(void) { return ssh_get_server_publickey(NULL, NULL); }
+#else
+int main(void) { return ssh_get_publickey(NULL, NULL); }
+#endif
 EOF
   if compile_object "$libssh_cflags"; then
 libssh_cflags="-DHAVE_LIBSSH_0_8 $libssh_cflags"
   fi
+  if compile_object "$libssh_cflags -DHAVE_SSH_GET_SERVER_PUBLICKEY"; then
+libssh_cflags="-DHAVE_SSH_GET_SERVER_PUBLICKEY $libssh_cflags"
+  fi
 fi
 
 ##
-- 
2.20.1

[Qemu-devel] [PATCH 3/4] configure: Improve checking libssh version is 0.8

[Philippe Mathieu-Daudé]

To figure out which libssh version is installed, checking for
ssh_get_server_publickey() is not sufficient.

ssh_get_server_publickey() has been introduced in libssh
commit bbd052202 (predating 0.8) but distributions also
backported other pre-0.8 patches, such libssh commit
963c46e4f which introduce the ssh_known_hosts_e enum.

Check the enum is available to assume the version is 0.8.

This fixes build failure on Ubuntu 18.04:

CC  block/ssh.o
  block/ssh.c: In function 'check_host_key_knownhosts':
  block/ssh.c:281:28: error: storage size of 'state' isn't known
   enum ssh_known_hosts_e state;
  ^
  rules.mak:69: recipe for target 'block/ssh.o' failed
  make: *** [block/ssh.o] Error 1

Reported-by: 周文青 <1151451...@qq.com>
Fixes: https://bugs.launchpad.net/qemu/+bug/1838763
Signed-off-by: Philippe Mathieu-Daudé 
---
 configure | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index fe3fef9309..040aa8eb6c 100755
--- a/configure
+++ b/configure
@@ -3949,18 +3949,24 @@ fi
 if test "$libssh" = "yes"; then
   cat > $TMPC <
+#ifdef HAVE_LIBSSH_0_8
+static const enum ssh_known_hosts_e val = SSH_KNOWN_HOSTS_OK;
+#endif
 #ifdef HAVE_SSH_GET_SERVER_PUBLICKEY
 int main(void) { return ssh_get_server_publickey(NULL, NULL); }
 #else
 int main(void) { return ssh_get_publickey(NULL, NULL); }
 #endif
 EOF
-  if compile_object "$libssh_cflags"; then
+  if compile_object "$libssh_cflags -DHAVE_LIBSSH_0_8"; then
 libssh_cflags="-DHAVE_LIBSSH_0_8 $libssh_cflags"
   fi
   if compile_object "$libssh_cflags -DHAVE_SSH_GET_SERVER_PUBLICKEY"; then
 libssh_cflags="-DHAVE_SSH_GET_SERVER_PUBLICKEY $libssh_cflags"
   fi
+  if ! compile_object "$libssh_cflags"; then
+error_exit "cannot use with libssh (is it broken?)"
+  fi
 fi
 
 ##
-- 
2.20.1

[Qemu-devel] [PATCH 4/4] configure: Log the libssh version detected

[Philippe Mathieu-Daudé]

Log wether the version is 0.7 or 0.8 to better understand
user reports.

Signed-off-by: Philippe Mathieu-Daudé 
---
 configure | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index 040aa8eb6c..d06cee0ba0 100755
--- a/configure
+++ b/configure
@@ -3930,6 +3930,7 @@ if test "$libssh" != "no" ; then
   if $pkg_config --exists libssh; then
 libssh_cflags=$($pkg_config libssh --cflags)
 libssh_libs=$($pkg_config libssh --libs)
+libssh_version=$($pkg_config libssh --modversion)
 libssh=yes
   else
 if test "$libssh" = "yes" ; then
@@ -3960,6 +3961,9 @@ int main(void) { return ssh_get_publickey(NULL, NULL); }
 EOF
   if compile_object "$libssh_cflags -DHAVE_LIBSSH_0_8"; then
 libssh_cflags="-DHAVE_LIBSSH_0_8 $libssh_cflags"
+  else
+# If this is not libssh 0.8, this is likely 0.7
+libssh_version="0.7"
   fi
   if compile_object "$libssh_cflags -DHAVE_SSH_GET_SERVER_PUBLICKEY"; then
 libssh_cflags="-DHAVE_SSH_GET_SERVER_PUBLICKEY $libssh_cflags"
@@ -6466,7 +6470,7 @@ echo "GlusterFS support $glusterfs"
 echo "gcov  $gcov_tool"
 echo "gcov enabled  $gcov"
 echo "TPM support   $tpm"
-echo "libssh support$libssh"
+echo "libssh support$libssh $(echo_version $libssh $libssh_version)"
 echo "QOM debugging $qom_cast_debug"
 echo "Live block migration $live_block_migration"
 echo "lzo support   $lzo"
-- 
2.20.1

[Qemu-devel] [RFC PATCH 1/4] configure: Improve libssh check

[Philippe Mathieu-Daudé]

The libssh pkg-config is not complete, the libraries required to
link with libssh are not returned. For example on Ubuntu 18.04:

  $ dpkg -l|fgrep libssh
  ii libssh-4:arm64 0.8.0~20170825.94fa1e38-1ubuntu0.2 arm64 tiny C SSH library 
(OpenSSL flavor)
  ii libssh-dev 0.8.0~20170825.94fa1e38-1ubuntu0.2 arm64 tiny C SSH library. 
Development files (OpenSSL flavor)

  $ pkg-config libssh --libs
  -lssh

Since the ./configure script tries to link an object to figure if
libssh is available, it fails:

  $ cat  config.log
  [...]
  cc -pthread -I/usr/include/glib-2.0 [...] -o config-temp/qemu-conf.exe 
config-temp/qemu-conf.c -m64 -static -g -lssh
  /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libssh.a(dh.c.o): 
In function `ssh_crypto_init':
  (.text+0x1a9): undefined reference to `BN_new'
  (.text+0x1c2): undefined reference to `BN_set_word'
  (.text+0x1c7): undefined reference to `BN_new'
  (.text+0x1e7): undefined reference to `BN_bin2bn'
  (.text+0x1ec): undefined reference to `BN_new'
  (.text+0x20c): undefined reference to `BN_bin2bn'
  (.text+0x218): undefined reference to `OPENSSL_init_crypto'
  [...]
  collect2: error: ld returned 1 exit status

To bypass this check, simply compile an object using libssh headers.

Signed-off-by: Philippe Mathieu-Daudé 
---
Should we check for libcrypto?

$ pkg-config --libs libssh openssl
-lssh -lssl -lcrypto
---
 configure | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure b/configure
index 714e7fb6a1..1d5c07de1f 100755
--- a/configure
+++ b/configure
@@ -3951,7 +3951,7 @@ if test "$libssh" = "yes"; then
 #include 
 int main(void) { return ssh_get_server_publickey(NULL, NULL); }
 EOF
-  if compile_prog "$libssh_cflags" "$libssh_libs"; then
+  if compile_object "$libssh_cflags"; then
 libssh_cflags="-DHAVE_LIBSSH_0_8 $libssh_cflags"
   fi
 fi
-- 
2.20.1

Re: [Qemu-devel] [PATCH v4 1/3] hw/gpio: Add basic Aspeed GPIO model for AST2400 and AST2500

[Cédric Le Goater]

On 14/08/2019 09:14, Rashmica Gupta wrote:
> GPIO pins are arranged in groups of 8 pins labeled A,B,..,Y,Z,AA,AB,AC.
> (Note that the ast2400 controller only goes up to group AB).
> A set has four groups (except set AC which only has one) and is
> referred to by the groups it is composed of (eg ABCD,EFGH,...,YZAAAB).
> Each set is accessed and controlled by a bank of 14 registers.
> 
> These registers operate on a per pin level where each bit in the register
> corresponds to a pin, except for the command source registers. The command
> source registers operate on a per group level where bits 24, 16, 8 and 0
> correspond to each group in the set.
> 
>  eg. registers for set ABCD:
>  |D7...D0|C7...C0|B7...B0|A7...A0| <- GPIOs
>  |31...24|23...16|158|7.0| <- bit position
> 
> Note that there are a couple of groups that only have 4 pins.
> 
> There are two ways that this model deviates from the behaviour of the

( I discovered that this spelling for 'behaviour' was Commonwealth English) 

> actual controller:
> (1) The only control source driving the GPIO pins in the model is the ARM
> model (as there currently aren't models for the LPC or Coprocessor).
> 
> (2) None of the registers in the model are reset tolerant (needs
> integration with the watchdog).
> 
> Signed-off-by: Rashmica Gupta 
> Tested-by: Andrew Jeffery 
> ---
>  hw/gpio/Makefile.objs |   1 +
>  hw/gpio/aspeed_gpio.c | 876 ++
>  include/hw/gpio/aspeed_gpio.h | 107 +

To put the .h files on top :

[diff]
orderFile = /some/path/qemu.git/scripts/git.orderfile

It's easier for review.


Some comments below. It would be nice to integrate the fields of 
AspeedGPIOController under AspeedGPIOClass directly and remove all
the 'ctrl' fields. 


>  3 files changed, 984 insertions(+)
>  create mode 100644 hw/gpio/aspeed_gpio.c
>  create mode 100644 include/hw/gpio/aspeed_gpio.h
> 
> diff --git a/hw/gpio/Makefile.objs b/hw/gpio/Makefile.objs
> index e5da0cb54f..d305b3b24b 100644
> --- a/hw/gpio/Makefile.objs
> +++ b/hw/gpio/Makefile.objs
> @@ -9,3 +9,4 @@ obj-$(CONFIG_OMAP) += omap_gpio.o
>  obj-$(CONFIG_IMX) += imx_gpio.o
>  obj-$(CONFIG_RASPI) += bcm2835_gpio.o
>  obj-$(CONFIG_NRF51_SOC) += nrf51_gpio.o
> +obj-$(CONFIG_ASPEED_SOC) += aspeed_gpio.o
> diff --git a/hw/gpio/aspeed_gpio.c b/hw/gpio/aspeed_gpio.c
> new file mode 100644
> index 00..bd5af81336
> --- /dev/null
> +++ b/hw/gpio/aspeed_gpio.c
> @@ -0,0 +1,876 @@
> +/*
> + *  ASPEED GPIO Controller
> + *
> + *  Copyright (C) 2017-2019 IBM Corp.
> + *
> + * SPDX-License-Identifier: GPL-2.0-or-later
> + */
> +
> +#include 
> +
> +#include "qemu/osdep.h"
> +#include "qemu/host-utils.h"
> +#include "qemu/log.h"
> +#include "hw/gpio/aspeed_gpio.h"
> +#include "include/hw/misc/aspeed_scu.h"
> +#include "qapi/error.h"
> +#include "qapi/visitor.h"
> +
> +#define GPIOS_PER_REG 32
> +#define GPIOS_PER_SET GPIOS_PER_REG
> +#define GPIO_PIN_GAP_SIZE 4
> +#define GPIOS_PER_GROUP 8
> +#define GPIO_GROUP_SHIFT 3
> +
> +/* GPIO Source Types */
> +#define ASPEED_CMD_SRC_MASK 0x01010101
> +#define ASPEED_SOURCE_ARM   0
> +#define ASPEED_SOURCE_LPC   1
> +#define ASPEED_SOURCE_COPROCESSOR   2
> +#define ASPEED_SOURCE_RESERVED  3
> +
> +/* GPIO Interrupt Triggers */
> +/*
> + *  For each set of gpios there are three sensitivity registers that control
> + *  the interrupt trigger mode.
> + *
> + *  | 2 | 1 | 0 | trigger mode
> + *  -
> + *  | 0 | 0 | 0 | falling-edge
> + *  | 0 | 0 | 1 | rising-edge
> + *  | 0 | 1 | 0 | level-low
> + *  | 0 | 1 | 1 | level-high
> + *  | 1 | X | X | dual-edge
> + */
> +#define ASPEED_FALLING_EDGE 0
> +#define ASPEED_RISING_EDGE  1
> +#define ASPEED_LEVEL_LOW2
> +#define ASPEED_LEVEL_HIGH   3
> +#define ASPEED_DUAL_EDGE4
> +
> +/* GPIO Register Address Offsets */
> +#define GPIO_ABCD_DATA_VALUE   (0x000 >> 2)
> +#define GPIO_ABCD_DIRECTION(0x004 >> 2)
> +#define GPIO_ABCD_INT_ENABLE   (0x008 >> 2)
> +#define GPIO_ABCD_INT_SENS_0   (0x00C >> 2)
> +#define GPIO_ABCD_INT_SENS_1   (0x010 >> 2)
> +#define GPIO_ABCD_INT_SENS_2   (0x014 >> 2)
> +#define GPIO_ABCD_INT_STATUS   (0x018 >> 2)
> +#define GPIO_ABCD_RESET_TOLERANT   (0x01C >> 2)
> +#define GPIO_EFGH_DATA_VALUE   (0x020 >> 2)
> +#define GPIO_EFGH_DIRECTION(0x024 >> 2)
> +#define GPIO_EFGH_INT_ENABLE   (0x028 >> 2)
> +#define GPIO_EFGH_INT_SENS_0   (0x02C >> 2)
> +#define GPIO_EFGH_INT_SENS_1   (0x030 >> 2)
> +#define GPIO_EFGH_INT_SENS_2   (0x034 >> 2)
> +#define GPIO_EFGH_INT_STATUS   (0x038 >> 2)
> +#define GPIO_EFGH_RESET_TOLERANT   (0x03C >> 2)
> +#define GPIO_ABCD_DEBOUNCE_1   (0x040 >> 2)
> +#define GPIO_ABCD_DEBOUNCE_2   (0x044 >> 2)
> +#define GPIO_EFGH_DEBOUNCE_1   (0x048 >> 2)
> +#define GPIO_EFGH_DEBOUNCE_2   (0x04C >> 2)
> +#define GPIO_DEBOUNCE_TIME_1   (0x050 >> 2)
> +#define GPIO_DEBOUNCE_TIME_2   (0x

Re: [Qemu-devel] [PATCH 4/4] configure: Log the libssh version detected

[Richard W.M. Jones]

The series seems fine, so:

Acked-by: Richard W.M. Jones 

If it was me I'd be inclined to file a bug against Ubuntu and get them
to fix their broken package instead :-)

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v

Re: [Qemu-devel] [PATCH v4 2/3] aspeed: add a GPIO controller to the SoC

[Cédric Le Goater]

On 14/08/2019 09:14, Rashmica Gupta wrote:
> Signed-off-by: Rashmica Gupta 
> ---
>  hw/arm/aspeed_soc.c | 17 +
>  include/hw/arm/aspeed_soc.h |  3 +++
>  2 files changed, 20 insertions(+)
> 
> diff --git a/hw/arm/aspeed_soc.c b/hw/arm/aspeed_soc.c
> index c6fb3700f2..ff422c8ad1 100644
> --- a/hw/arm/aspeed_soc.c
> +++ b/hw/arm/aspeed_soc.c
> @@ -124,6 +124,7 @@ static const AspeedSoCInfo aspeed_socs[] = {
>  .spis_num = 1,
>  .fmc_typename = "aspeed.smc.fmc",
>  .spi_typename = aspeed_soc_ast2400_typenames,
> +.gpio_typename = "aspeed.gpio-ast2400",

I suppose this patch is based on mainline and not my tree.

My current patchset has removed all these typenames but that's OK. 
It's a minor change we can handle depending on which patch gets
merged first. 

A part from that, it looks good.

Thanks,

C.

  
>  .wdts_num = 2,
>  .irqmap   = aspeed_soc_ast2400_irqmap,
>  .memmap   = aspeed_soc_ast2400_memmap,
> @@ -136,6 +137,7 @@ static const AspeedSoCInfo aspeed_socs[] = {
>  .spis_num = 1,
>  .fmc_typename = "aspeed.smc.fmc",
>  .spi_typename = aspeed_soc_ast2400_typenames,
> +.gpio_typename = "aspeed.gpio-ast2400",
>  .wdts_num = 2,
>  .irqmap   = aspeed_soc_ast2400_irqmap,
>  .memmap   = aspeed_soc_ast2400_memmap,
> @@ -148,6 +150,7 @@ static const AspeedSoCInfo aspeed_socs[] = {
>  .spis_num = 1,
>  .fmc_typename = "aspeed.smc.fmc",
>  .spi_typename = aspeed_soc_ast2400_typenames,
> +.gpio_typename = "aspeed.gpio-ast2400",
>  .wdts_num = 2,
>  .irqmap   = aspeed_soc_ast2400_irqmap,
>  .memmap   = aspeed_soc_ast2400_memmap,
> @@ -160,6 +163,7 @@ static const AspeedSoCInfo aspeed_socs[] = {
>  .spis_num = 2,
>  .fmc_typename = "aspeed.smc.ast2500-fmc",
>  .spi_typename = aspeed_soc_ast2500_typenames,
> +.gpio_typename = "aspeed.gpio-ast2500",
>  .wdts_num = 3,
>  .irqmap   = aspeed_soc_ast2500_irqmap,
>  .memmap   = aspeed_soc_ast2500_memmap,
> @@ -246,6 +250,9 @@ static void aspeed_soc_init(Object *obj)
>  
>  sysbus_init_child_obj(obj, "xdma", OBJECT(&s->xdma), sizeof(s->xdma),
>TYPE_ASPEED_XDMA);
> +
> +sysbus_init_child_obj(obj, "gpio", OBJECT(&s->gpio), sizeof(s->gpio),
> +  sc->info->gpio_typename);
>  }
>  
>  static void aspeed_soc_realize(DeviceState *dev, Error **errp)
> @@ -425,6 +432,16 @@ static void aspeed_soc_realize(DeviceState *dev, Error 
> **errp)
>  sc->info->memmap[ASPEED_XDMA]);
>  sysbus_connect_irq(SYS_BUS_DEVICE(&s->xdma), 0,
> aspeed_soc_get_irq(s, ASPEED_XDMA));
> +
> +/* GPIO */
> +object_property_set_bool(OBJECT(&s->gpio), true, "realized", &err);
> +if (err) {
> +error_propagate(errp, err);
> +return;
> +}
> +sysbus_mmio_map(SYS_BUS_DEVICE(&s->gpio), 0, 
> sc->info->memmap[ASPEED_GPIO]);
> +sysbus_connect_irq(SYS_BUS_DEVICE(&s->gpio), 0,
> +   aspeed_soc_get_irq(s, ASPEED_GPIO));
>  }
>  static Property aspeed_soc_properties[] = {
>  DEFINE_PROP_UINT32("num-cpus", AspeedSoCState, num_cpus, 0),
> diff --git a/include/hw/arm/aspeed_soc.h b/include/hw/arm/aspeed_soc.h
> index cef605ad6b..fa04abddd8 100644
> --- a/include/hw/arm/aspeed_soc.h
> +++ b/include/hw/arm/aspeed_soc.h
> @@ -22,6 +22,7 @@
>  #include "hw/ssi/aspeed_smc.h"
>  #include "hw/watchdog/wdt_aspeed.h"
>  #include "hw/net/ftgmac100.h"
> +#include "hw/gpio/aspeed_gpio.h"
>  
>  #define ASPEED_SPIS_NUM  2
>  #define ASPEED_WDTS_NUM  3
> @@ -47,6 +48,7 @@ typedef struct AspeedSoCState {
>  AspeedSDMCState sdmc;
>  AspeedWDTState wdt[ASPEED_WDTS_NUM];
>  FTGMAC100State ftgmac100[ASPEED_MACS_NUM];
> +AspeedGPIOState gpio;
>  } AspeedSoCState;
>  
>  #define TYPE_ASPEED_SOC "aspeed-soc"
> @@ -60,6 +62,7 @@ typedef struct AspeedSoCInfo {
>  int spis_num;
>  const char *fmc_typename;
>  const char **spi_typename;
> +const char *gpio_typename;
>  int wdts_num;
>  const int *irqmap;
>  const hwaddr *memmap;
> 

Re: [Qemu-devel] [PATCH v4] migration: do not rom_reset() during incoming migration

[Paolo Bonzini]

On 14/08/19 12:40, Catherine Ho wrote:
> Hi Paolo
> Ping, is any other comment I hadn't addressed?

No, I queued the patch now.

Paolo

> Cheers
> Catherine
> 
> On Thu, 6 Jun 2019 at 02:31, Dr. David Alan Gilbert  > wrote:
> 
> Paolo, can you take this one please.
> 
> * Catherine Ho (catherine.h...@gmail.com
> ) wrote:
> > Commit 18269069c310 ("migration: Introduce ignore-shared capability")
> > addes ignore-shared capability to bypass the shared ramblock (e,g,
> > membackend + numa node). It does good to live migration.
> >
> > As told by Yury,this commit expectes that QEMU doesn't write to
> guest RAM
> > until VM starts, but it does on aarch64 qemu:
> > Backtrace:
> > 1  0x55f4a296dd84 in address_space_write_rom_internal () at
> > exec.c:3458
> > 2  0x55f4a296de3a in address_space_write_rom () at exec.c:3479
> > 3  0x55f4a2d519ff in rom_reset () at hw/core/loader.c:1101
> > 4  0x55f4a2d475ec in qemu_devices_reset () at hw/core/reset.c:69
> > 5  0x55f4a2c90a28 in qemu_system_reset () at vl.c:1675
> > 6  0x55f4a2c9851d in main () at vl.c:4552
> >
> > Actually, on arm64 virt marchine, ramblock "dtb" will be filled
> into ram
> > druing rom_reset. In ignore-shared incoming case, this rom filling
> > is not required since all the data has been stored in memory backend
> > file.
> >
> > Further more, as suggested by Peter Xu, if we do rom_reset() now with
> > these ROMs then the RAM data should be re-filled again too with the
> > migration stream coming in.
> >
> > Fixes: commit 18269069c310 ("migration: Introduce ignore-shared
> > capability")
> > Suggested-by: Yury Kotov  >
> > Suggested-by: Peter Xu mailto:pet...@redhat.com>>
> > Signed-off-by: Catherine Ho  >
> > ---
> >  hw/core/loader.c | 9 +
> >  1 file changed, 9 insertions(+)
> >
> > diff --git a/hw/core/loader.c b/hw/core/loader.c
> > index fe5cb24122..040109464b 100644
> > --- a/hw/core/loader.c
> > +++ b/hw/core/loader.c
> > @@ -1087,6 +1087,15 @@ static void rom_reset(void *unused)
> >  {
> >      Rom *rom;
> > 
> > +    /*
> > +     * We don't need to fill in the RAM with ROM data because
> we'll fill
> > +     * the data in during the next incoming migration in all
> cases.  Note
> > +     * that some of those RAMs can actually be modified by the
> guest on ARM
> > +     * so this is probably the only right thing to do here.
> > +     */
> > +    if (runstate_check(RUN_STATE_INMIGRATE))
> > +        return;
> > +
> >      QTAILQ_FOREACH(rom, &roms, next) {
> >          if (rom->fw_file) {
> >              continue;
> > --
> > 2.17.1
> >
> --
> Dr. David Alan Gilbert / dgilb...@redhat.com
>  / Manchester, UK
> 

Re: [Qemu-devel] [PATCH 2/4] configure: Avoid using libssh deprecated API

[Pino Toscano]

On Wednesday, 14 August 2019 14:15:25 CEST Philippe Mathieu-Daudé wrote:
> The libssh packaged by a distribution can predate version 0.8,
> but still provides the newer API introduced after version 0.7.
> 
> Using the deprecated API leads to build failure, as on Ubuntu 18.04:
> 
> CC  block/ssh.o
>   block/ssh.c: In function 'check_host_key_hash':
>   block/ssh.c:444:5: error: 'ssh_get_publickey' is deprecated 
> [-Werror=deprecated-declarations]
>r = ssh_get_publickey(s->session, &pubkey);
>^
>   In file included from block/ssh.c:27:0:
>   /usr/include/libssh/libssh.h:489:31: note: declared here
>SSH_DEPRECATED LIBSSH_API int ssh_get_publickey(ssh_session session, 
> ssh_key *key);
>  ^
>   rules.mak:69: recipe for target 'block/ssh.o' failed
>   make: *** [block/ssh.o] Error 1
> 
> Fix by using the newer API if available.
> 
> Suggested-by: Andrea Bolognani 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  block/ssh.c | 2 +-
>  configure   | 7 +++
>  2 files changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/block/ssh.c b/block/ssh.c
> index 501933b855..f5fea921c6 100644
> --- a/block/ssh.c
> +++ b/block/ssh.c
> @@ -438,7 +438,7 @@ check_host_key_hash(BDRVSSHState *s, const char *hash,
>  unsigned char *server_hash;
>  size_t server_hash_len;
>  
> -#ifdef HAVE_LIBSSH_0_8
> +#ifdef HAVE_SSH_GET_SERVER_PUBLICKEY
>  r = ssh_get_server_publickey(s->session, &pubkey);
>  #else
>  r = ssh_get_publickey(s->session, &pubkey);
> diff --git a/configure b/configure
> index 1d5c07de1f..fe3fef9309 100755
> --- a/configure
> +++ b/configure
> @@ -3949,11 +3949,18 @@ fi
>  if test "$libssh" = "yes"; then
>cat > $TMPC <  #include 
> +#ifdef HAVE_SSH_GET_SERVER_PUBLICKEY
>  int main(void) { return ssh_get_server_publickey(NULL, NULL); }
> +#else
> +int main(void) { return ssh_get_publickey(NULL, NULL); }
> +#endif
>  EOF
>if compile_object "$libssh_cflags"; then
>  libssh_cflags="-DHAVE_LIBSSH_0_8 $libssh_cflags"
>fi
> +  if compile_object "$libssh_cflags -DHAVE_SSH_GET_SERVER_PUBLICKEY"; then
> +libssh_cflags="-DHAVE_SSH_GET_SERVER_PUBLICKEY $libssh_cflags"
> +  fi

Why try to compile it twice? If the check for ssh_get_server_publickey
works, then it is available...

Just add an additional HAVE_SSH_GET_SERVER_PUBLICKEY define when this
test succeeds, and change the usage of ssh_get_server_publickey based
on this.

-- 
Pino Toscano

signature.asc
Description: This is a digitally signed message part.

Re: [Qemu-devel] [RFC PATCH 1/4] configure: Improve libssh check

[Pino Toscano]

On Wednesday, 14 August 2019 14:15:24 CEST Philippe Mathieu-Daudé wrote:
> The libssh pkg-config is not complete, the libraries required to
> link with libssh are not returned. For example on Ubuntu 18.04:
> 
>   $ dpkg -l|fgrep libssh
>   ii libssh-4:arm64 0.8.0~20170825.94fa1e38-1ubuntu0.2 arm64 tiny C SSH 
> library (OpenSSL flavor)
>   ii libssh-dev 0.8.0~20170825.94fa1e38-1ubuntu0.2 arm64 tiny C SSH library. 
> Development files (OpenSSL flavor)
> 
>   $ pkg-config libssh --libs
>   -lssh
> 
> Since the ./configure script tries to link an object to figure if
> libssh is available, it fails:
> 
>   $ cat  config.log
>   [...]
>   cc -pthread -I/usr/include/glib-2.0 [...] -o config-temp/qemu-conf.exe 
> config-temp/qemu-conf.c -m64 -static -g -lssh
>   /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libssh.a(dh.c.o): 
> In function `ssh_crypto_init':
>   (.text+0x1a9): undefined reference to `BN_new'
>   (.text+0x1c2): undefined reference to `BN_set_word'
>   (.text+0x1c7): undefined reference to `BN_new'
>   (.text+0x1e7): undefined reference to `BN_bin2bn'
>   (.text+0x1ec): undefined reference to `BN_new'
>   (.text+0x20c): undefined reference to `BN_bin2bn'
>   (.text+0x218): undefined reference to `OPENSSL_init_crypto'
>   [...]
>   collect2: error: ld returned 1 exit status

Sigh :/

> ---
> Should we check for libcrypto?
> 
> $ pkg-config --libs libssh openssl
> -lssh -lssl -lcrypto

Definitely not! The crypto library is an internal implementation of
libssh, so please do not assume libssh is built against openssl.

-- 
Pino Toscano

signature.asc
Description: This is a digitally signed message part.

Re: [Qemu-devel] [PATCH v4 3/3] hw/gpio: Add in AST2600 specific implementation

[Cédric Le Goater]

On 14/08/2019 09:14, Rashmica Gupta wrote:
> The AST2600 has the same sets of 3.6v gpios as the AST2400 plus an
> addtional two sets of 1.8V gpios.
> 
> Signed-off-by: Rashmica Gupta 
> ---
>  hw/gpio/aspeed_gpio.c | 188 --
>  slirp |   2 +-
>  2 files changed, 184 insertions(+), 6 deletions(-)
> 
> diff --git a/hw/gpio/aspeed_gpio.c b/hw/gpio/aspeed_gpio.c
> index bd5af81336..f781fbb6dc 100644
> --- a/hw/gpio/aspeed_gpio.c
> +++ b/hw/gpio/aspeed_gpio.c
> @@ -167,6 +167,49 @@
>  #define GPIO_3_6V_MEM_SIZE 0x1F0
>  #define GPIO_3_6V_REG_ARRAY_SIZE   (GPIO_3_6V_MEM_SIZE >> 2)
>  
> +/* AST2600 only - 1.8V gpios */
> +/*
> + * The AST2600 has same 3.6V gpios as the AST2400 (memory offsets 0x0-0x198)
> + * and addtional 1.8V gpios (memory offsets 0x800-0x9D4). We create one
> + * GPIOState for the 3.6V gpios mapped at 0x0 and another GPIOState for the
> + * 1.8V gpios mapped at 0x800.
> + */
> +#define GPIO_1_8V_REG_OFFSET  0x800
> +#define GPIO_1_8V_ABCD_DATA_VALUE ((0x800 - GPIO_1_8V_REG_OFFSET) >> 2)
> +#define GPIO_1_8V_ABCD_DIRECTION  ((0x804 - GPIO_1_8V_REG_OFFSET) >> 2)
> +#define GPIO_1_8V_ABCD_INT_ENABLE ((0x808 - GPIO_1_8V_REG_OFFSET) >> 2)
> +#define GPIO_1_8V_ABCD_INT_SENS_0 ((0x80C - GPIO_1_8V_REG_OFFSET) >> 2)
> +#define GPIO_1_8V_ABCD_INT_SENS_1 ((0x810 - GPIO_1_8V_REG_OFFSET) >> 2)
> +#define GPIO_1_8V_ABCD_INT_SENS_2 ((0x814 - GPIO_1_8V_REG_OFFSET) >> 2)
> +#define GPIO_1_8V_ABCD_INT_STATUS ((0x818 - GPIO_1_8V_REG_OFFSET) >> 2)
> +#define GPIO_1_8V_ABCD_RESET_TOLERANT ((0x81C - GPIO_1_8V_REG_OFFSET) >> 2)
> +#define GPIO_1_8V_E_DATA_VALUE((0x820 - GPIO_1_8V_REG_OFFSET) >> 2)
> +#define GPIO_1_8V_E_DIRECTION ((0x824 - GPIO_1_8V_REG_OFFSET) >> 2)
> +#define GPIO_1_8V_E_INT_ENABLE((0x828 - GPIO_1_8V_REG_OFFSET) >> 2)
> +#define GPIO_1_8V_E_INT_SENS_0((0x82C - GPIO_1_8V_REG_OFFSET) >> 2)
> +#define GPIO_1_8V_E_INT_SENS_1((0x830 - GPIO_1_8V_REG_OFFSET) >> 2)
> +#define GPIO_1_8V_E_INT_SENS_2((0x834 - GPIO_1_8V_REG_OFFSET) >> 2)
> +#define GPIO_1_8V_E_INT_STATUS((0x838 - GPIO_1_8V_REG_OFFSET) >> 2)
> +#define GPIO_1_8V_E_RESET_TOLERANT((0x83C - GPIO_1_8V_REG_OFFSET) >> 2)
> +#define GPIO_1_8V_ABCD_DEBOUNCE_1 ((0x840 - GPIO_1_8V_REG_OFFSET) >> 2)
> +#define GPIO_1_8V_ABCD_DEBOUNCE_2 ((0x844 - GPIO_1_8V_REG_OFFSET) >> 2)
> +#define GPIO_1_8V_E_DEBOUNCE_1((0x848 - GPIO_1_8V_REG_OFFSET) >> 2)
> +#define GPIO_1_8V_E_DEBOUNCE_2((0x84C - GPIO_1_8V_REG_OFFSET) >> 2)
> +#define GPIO_1_8V_DEBOUNCE_TIME_1 ((0x850 - GPIO_1_8V_REG_OFFSET) >> 2)
> +#define GPIO_1_8V_DEBOUNCE_TIME_2 ((0x854 - GPIO_1_8V_REG_OFFSET) >> 2)
> +#define GPIO_1_8V_DEBOUNCE_TIME_3 ((0x858 - GPIO_1_8V_REG_OFFSET) >> 2)
> +#define GPIO_1_8V_ABCD_COMMAND_SRC_0  ((0x860 - GPIO_1_8V_REG_OFFSET) >> 2)
> +#define GPIO_1_8V_ABCD_COMMAND_SRC_1  ((0x864 - GPIO_1_8V_REG_OFFSET) >> 2)
> +#define GPIO_1_8V_E_COMMAND_SRC_0 ((0x868 - GPIO_1_8V_REG_OFFSET) >> 2)
> +#define GPIO_1_8V_E_COMMAND_SRC_1 ((0x86C - GPIO_1_8V_REG_OFFSET) >> 2)
> +#define GPIO_1_8V_ABCD_DATA_READ  ((0x8C0 - GPIO_1_8V_REG_OFFSET) >> 2)
> +#define GPIO_1_8V_E_DATA_READ ((0x8C4 - GPIO_1_8V_REG_OFFSET) >> 2)
> +#define GPIO_1_8V_ABCD_INPUT_MASK ((0x9D0 - GPIO_1_8V_REG_OFFSET) >> 2)
> +#define GPIO_1_8V_E_INPUT_MASK((0x9D4 - GPIO_1_8V_REG_OFFSET) >> 2)
> +#define GPIO_1_8V_MEM_SIZE0x9D8
> +#define GPIO_1_8V_REG_ARRAY_SIZE  ((GPIO_1_8V_MEM_SIZE - \
> +  GPIO_1_8V_REG_OFFSET) >> 2)
> +
>  static int aspeed_evaluate_irq(GPIOSets *regs, int gpio_prev_high, int gpio)
>  {
>  uint32_t falling_edge = 0, rising_edge = 0;
> @@ -465,6 +508,39 @@ static const AspeedGPIOReg 
> aspeed_3_6v_gpios[GPIO_3_6V_REG_ARRAY_SIZE] = {
>  [GPIO_AC_INPUT_MASK] = { 7, gpio_reg_input_mask },
>  };
>  
> +static const AspeedGPIOReg aspeed_1_8v_gpios[GPIO_1_8V_REG_ARRAY_SIZE] = {
> +/* 1.8V Set ABCD */
> +[GPIO_1_8V_ABCD_DATA_VALUE] = {0, gpio_reg_data_value},
> +[GPIO_1_8V_ABCD_DIRECTION] =  {0, gpio_reg_direction},
> +[GPIO_1_8V_ABCD_INT_ENABLE] = {0, gpio_reg_int_enable},
> +[GPIO_1_8V_ABCD_INT_SENS_0] = {0, gpio_reg_int_sens_0},
> +[GPIO_1_8V_ABCD_INT_SENS_1] = {0, gpio_reg_int_sens_1},
> +[GPIO_1_8V_ABCD_INT_SENS_2] = {0, gpio_reg_int_sens_2},
> +[GPIO_1_8V_ABCD_INT_STATUS] = {0, gpio_reg_int_status},
> +[GPIO_1_8V_ABCD_RESET_TOLERANT] = {0, gpio_reg_reset_tolerant},
> +[GPIO_1_8V_ABCD_DEBOUNCE_1] = {0, gpio_reg_debounce_1},
> +[GPIO_1_8V_ABCD_DEBOUNCE_2] = {0, gpio_reg_debounce_2},
> +[GPIO_1_8V_ABCD_COMMAND_SRC_0] =  {0, gpio_reg_cmd_source_0},
> +[GPIO_1_8V_ABCD_COMMAND_SRC_1] =  {0, gpio_reg_cmd_source_1},
> +[GPIO_1_8V_ABCD_DATA_READ] =  {0, gpio_reg_data_read},
> +[GPIO_1_8V_ABCD_INPUT_MASK] = {0, gpio_reg_inp

Re: [Qemu-devel] [PATCH] test-bitmap: test set 1 bit case for bitmap_set

[Paolo Bonzini]

On 14/08/19 02:27, Wei Yang wrote:
> All current bitmap_set test cases set range across word, while the
> handle of a range within one word is different from that.
> 
> Add case to set 1 bit as a represent for set range within one word.
> 
> Signed-off-by: Wei Yang 
> 
> ---
> Thanks for Paolo's finding.
> 
> ---
>  tests/test-bitmap.c | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/tests/test-bitmap.c b/tests/test-bitmap.c
> index 18aa584591..087e02a26c 100644
> --- a/tests/test-bitmap.c
> +++ b/tests/test-bitmap.c
> @@ -67,6 +67,18 @@ static void bitmap_set_case(bmap_set_func set_func)
>  
>  bmap = bitmap_new(BMAP_SIZE);
>  
> +/* Set one bit at offset in second word */
> +for (offset = 0; offset <= BITS_PER_LONG; offset++) {
> +bitmap_clear(bmap, 0, BMAP_SIZE);
> +set_func(bmap, BITS_PER_LONG + offset, 1);
> +g_assert_cmpint(find_first_bit(bmap, 2 * BITS_PER_LONG),
> +==, BITS_PER_LONG + offset);
> +g_assert_cmpint(find_next_zero_bit(bmap,
> +   3 * BITS_PER_LONG,
> +   BITS_PER_LONG + offset),
> +==, BITS_PER_LONG + offset + 1);
> +}
> +
>  /* Both Aligned, set bits [BITS_PER_LONG, 3*BITS_PER_LONG] */
>  set_func(bmap, BITS_PER_LONG, 2 * BITS_PER_LONG);
>  g_assert_cmpuint(bmap[1], ==, -1ul);
> 

Queued, thanks for writing the testcase without no one asking! :)

Paolo

Re: [Qemu-devel] [PATCH 3/4] configure: Improve checking libssh version is 0.8

[Pino Toscano]

On Wednesday, 14 August 2019 14:15:26 CEST Philippe Mathieu-Daudé wrote:
> To figure out which libssh version is installed, checking for
> ssh_get_server_publickey() is not sufficient.
> 
> ssh_get_server_publickey() has been introduced in libssh
> commit bbd052202 (predating 0.8) but distributions also
> backported other pre-0.8 patches, such libssh commit
> 963c46e4f which introduce the ssh_known_hosts_e enum.
> 
> Check the enum is available to assume the version is 0.8.
> 
> This fixes build failure on Ubuntu 18.04:
> 
> CC  block/ssh.o
>   block/ssh.c: In function 'check_host_key_knownhosts':
>   block/ssh.c:281:28: error: storage size of 'state' isn't known
>enum ssh_known_hosts_e state;
>   ^
>   rules.mak:69: recipe for target 'block/ssh.o' failed
>   make: *** [block/ssh.o] Error 1
> 
> Reported-by: 周文青 <1151451...@qq.com>
> Fixes: https://bugs.launchpad.net/qemu/+bug/1838763
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  configure | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/configure b/configure
> index fe3fef9309..040aa8eb6c 100755
> --- a/configure
> +++ b/configure
> @@ -3949,18 +3949,24 @@ fi
>  if test "$libssh" = "yes"; then
>cat > $TMPC <  #include 
> +#ifdef HAVE_LIBSSH_0_8
> +static const enum ssh_known_hosts_e val = SSH_KNOWN_HOSTS_OK;
> +#endif
>  #ifdef HAVE_SSH_GET_SERVER_PUBLICKEY
>  int main(void) { return ssh_get_server_publickey(NULL, NULL); }
>  #else
>  int main(void) { return ssh_get_publickey(NULL, NULL); }
>  #endif
>  EOF
> -  if compile_object "$libssh_cflags"; then
> +  if compile_object "$libssh_cflags -DHAVE_LIBSSH_0_8"; then
>  libssh_cflags="-DHAVE_LIBSSH_0_8 $libssh_cflags"
>fi
>if compile_object "$libssh_cflags -DHAVE_SSH_GET_SERVER_PUBLICKEY"; then
>  libssh_cflags="-DHAVE_SSH_GET_SERVER_PUBLICKEY $libssh_cflags"
>fi
> +  if ! compile_object "$libssh_cflags"; then
> +error_exit "cannot use with libssh (is it broken?)"
> +  fi

Ugh no, this is way more twisted and complex than really needed.

Instead, just add another build time check for
ssh_session_is_known_server, and change check_host_key_knownhosts to
use it only when found.

-- 
Pino Toscano

signature.asc
Description: This is a digitally signed message part.

Re: [Qemu-devel] [PATCH 4/4] configure: Log the libssh version detected

[Pino Toscano]

On Wednesday, 14 August 2019 14:15:27 CEST Philippe Mathieu-Daudé wrote:
> Log wether the version is 0.7 or 0.8 to better understand
> user reports.
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  configure | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/configure b/configure
> index 040aa8eb6c..d06cee0ba0 100755
> --- a/configure
> +++ b/configure
> @@ -3930,6 +3930,7 @@ if test "$libssh" != "no" ; then
>if $pkg_config --exists libssh; then
>  libssh_cflags=$($pkg_config libssh --cflags)
>  libssh_libs=$($pkg_config libssh --libs)
> +libssh_version=$($pkg_config libssh --modversion)
>  libssh=yes
>else
>  if test "$libssh" = "yes" ; then
> @@ -3960,6 +3961,9 @@ int main(void) { return ssh_get_publickey(NULL, NULL); }
>  EOF
>if compile_object "$libssh_cflags -DHAVE_LIBSSH_0_8"; then
>  libssh_cflags="-DHAVE_LIBSSH_0_8 $libssh_cflags"
> +  else
> +# If this is not libssh 0.8, this is likely 0.7
> +libssh_version="0.7"
>fi

Not sure why this though -- please leave it out, and just log the
version as found.

-- 
Pino Toscano

signature.asc
Description: This is a digitally signed message part.

Re: [Qemu-devel] [PATCH-for-4.1? 0/7] vl: Allow building with CONFIG_BLUETOOTH disabled

[Philippe Mathieu-Daudé]

On 8/13/19 4:04 PM, Peter Maydell wrote:
> On Tue, 13 Aug 2019 at 15:01, Philippe Mathieu-Daudé  
> wrote:
>> On 7/15/19 3:13 PM, Thomas Huth wrote:
>>> On 12/07/2019 15.39, Philippe Mathieu-Daudé wrote:
 A series of obvious patches to build without the deprecated
 bluetooth devices. Still worth for 4.1 or too late?
 It is clearly not a bugfix.
>>>
>>> I wonder whether this series is worth the effort right now, or whether
>>> we should simply nuke the bluetooth code after 4.1 has been released?
>>
>> Well, perfect is the enemy of good :)
>>
>> This series is already done and is an improvement to what we have.
>>
>> Regarding nuking it, it depends on the Nokia N-series boards, they might
>> become useless without BT support.
> 
> Er, they're not useless at all without BT support. The BT
> hardware is a really tiny part that I doubt many users of
> the board models ever used. As long as we retain a "simulate
> doing nothing much" model of the BT device to show the guest
> I don't care whether the BT backend code disappears.

OK, I won't insist then.

Re: [Qemu-devel] [PATCH v3 0/3] Add Aspeed GPIO controller model

[Cédric Le Goater]

On 30/07/2019 07:44, Rashmica Gupta wrote:
> There are a couple of things I'm not confident about here:
> - what should be in init vs realize?
> - should the irq state be in vmstate?
> - is there a better way to do composition of classes (patch 3)?

You can not do twice : 

 obj = object_new(TYPE_ASPEED_GPIO "-ast2600");

in aspeed_2600_gpio_realize(). This feels wrong. 

Let's see if we can instantiate two GPIO devices with different types 
under the AST2600 SoC instead.

Thanks,

C.

> 
> v3:
> - didn't have each gpio set up as an irq 
> - now can't access set AC on ast2400 (only exists on ast2500)
> - added ast2600 implementation (patch 3)
> - renamed a couple of variables for clarity
> 
> 
> v2: Addressed Andrew's feedback, added debounce regs, renamed get/set to
> read/write to minimise confusion with a 'set' of registers.
> 
> Rashmica Gupta (3):
>   hw/gpio: Add basic Aspeed GPIO model for AST2400 and AST2500
>   aspeed: add a GPIO controller to the SoC
>   hw/gpio: Add in AST2600 specific implementation
> 
>  hw/arm/aspeed_soc.c   |   17 +
>  hw/gpio/Makefile.objs |1 +
>  hw/gpio/aspeed_gpio.c | 1103 +
>  include/hw/arm/aspeed_soc.h   |3 +
>  include/hw/gpio/aspeed_gpio.h |   91 +++
>  5 files changed, 1215 insertions(+)
>  create mode 100644 hw/gpio/aspeed_gpio.c
>  create mode 100644 include/hw/gpio/aspeed_gpio.h
> 

Re: [Qemu-devel] [PATCH-for-4.1? 3/7] MAINTAINERS: Add an entry for the Bluetooth devices

[Philippe Mathieu-Daudé]

Cc'ing qemu-trivial@ to salvage this patch.

On 7/12/19 3:39 PM, Philippe Mathieu-Daudé wrote:
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  MAINTAINERS | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index cc9636b43a..5d8f27d9bd 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1733,6 +1733,13 @@ F: hw/*/*xive*
>  F: include/hw/*/*xive*
>  F: docs/*/*xive*
>  
> +Bluetooth
> +S: Orphan
> +F: bt-*.c
> +F: hw/bt/
> +F: include/hw/bt.h
> +F: include/sysemu/bt.h
> +
>  Subsystems
>  --
>  Audio
> 

[Qemu-devel] [PATCH] pc-bios/s390-ccw/net: fix a possible memory leak in get_uuid()

[luoyifan]

There is a possible memory leak in get_uuid(). Should free allocated mem
before 
return NULL.

Signed-off-by: Yifan Luo 
---
 pc-bios/s390-ccw/netmain.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/pc-bios/s390-ccw/netmain.c b/pc-bios/s390-ccw/netmain.c
index f3542cb2cf1..f2dcc01e272 100644
--- a/pc-bios/s390-ccw/netmain.c
+++ b/pc-bios/s390-ccw/netmain.c
@@ -269,6 +269,7 @@ static const char *get_uuid(void)
  : "d" (r0), "d" (r1), [addr] "a" (buf)
  : "cc", "memory");
 if (cc) {
+free(mem);
 return NULL;
 }
 
-- 
2.21.0

Re: [Qemu-devel] [PATCH v9 01/11] hw/arm: simplify arm_load_dtb

[Cédric Le Goater]

On 13/08/2019 23:55, Eduardo Habkost wrote:
> 
> CCing ARM maintainers.  I'd like to at least get one Acked-by from
> them before queueing this on machine-next.
> 
> 
> On Fri, Aug 09, 2019 at 02:57:21PM +0800, Tao wrote:
>> From: Tao Xu 
>>
>> In struct arm_boot_info, kernel_filename, initrd_filename and
>> kernel_cmdline are copied from from MachineState. This patch add
>> MachineState as a parameter into arm_load_dtb() and move the copy chunk
>> of kernel_filename, initrd_filename and kernel_cmdline into
>> arm_load_kernel().
>>
>> Reviewed-by: Igor Mammedov 
>> Reviewed-by: Liu Jingqi 
>> Suggested-by: Igor Mammedov 
>> Signed-off-by: Tao Xu 
>> ---
>>
>> No changes in v9
>> ---
>>  hw/arm/aspeed.c   |  5 +
>>  hw/arm/boot.c | 14 --
>>  hw/arm/collie.c   |  8 +---
>>  hw/arm/cubieboard.c   |  5 +
>>  hw/arm/exynos4_boards.c   |  7 ++-
>>  hw/arm/highbank.c |  8 +---
>>  hw/arm/imx25_pdk.c|  5 +
>>  hw/arm/integratorcp.c |  8 +---
>>  hw/arm/kzm.c  |  5 +
>>  hw/arm/mainstone.c|  5 +
>>  hw/arm/mcimx6ul-evk.c |  5 +
>>  hw/arm/mcimx7d-sabre.c|  5 +
>>  hw/arm/musicpal.c |  8 +---
>>  hw/arm/nseries.c  |  5 +
>>  hw/arm/omap_sx1.c |  5 +
>>  hw/arm/palm.c | 10 ++
>>  hw/arm/raspi.c|  6 +-
>>  hw/arm/realview.c |  5 +
>>  hw/arm/sabrelite.c|  5 +
>>  hw/arm/sbsa-ref.c |  3 +--
>>  hw/arm/spitz.c|  5 +
>>  hw/arm/tosa.c |  8 +---
>>  hw/arm/versatilepb.c  |  5 +
>>  hw/arm/vexpress.c |  5 +
>>  hw/arm/virt.c |  8 +++-
>>  hw/arm/xilinx_zynq.c  |  8 +---
>>  hw/arm/xlnx-versal-virt.c |  7 ++-
>>  hw/arm/xlnx-zcu102.c  |  5 +
>>  hw/arm/z2.c   |  8 +---
>>  include/hw/arm/boot.h |  4 ++--
>>  30 files changed, 43 insertions(+), 147 deletions(-)
>>
>> diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
>> index 843b708247..f8733b86b9 100644
>> --- a/hw/arm/aspeed.c
>> +++ b/hw/arm/aspeed.c
>> @@ -241,9 +241,6 @@ static void aspeed_board_init(MachineState *machine,
>>  write_boot_rom(drive0, FIRMWARE_ADDR, fl->size, &error_abort);
>>  }
>>  
>> -aspeed_board_binfo.kernel_filename = machine->kernel_filename;
>> -aspeed_board_binfo.initrd_filename = machine->initrd_filename;
>> -aspeed_board_binfo.kernel_cmdline = machine->kernel_cmdline;
>>  aspeed_board_binfo.ram_size = ram_size;
>>  aspeed_board_binfo.loader_start = sc->info->memmap[ASPEED_SDRAM];
>>  aspeed_board_binfo.nb_cpus = bmc->soc.num_cpus;
>> @@ -252,7 +249,7 @@ static void aspeed_board_init(MachineState *machine,
>>  cfg->i2c_init(bmc);
>>  }
>>  
>> -arm_load_kernel(ARM_CPU(first_cpu), &aspeed_board_binfo);
>> +arm_load_kernel(ARM_CPU(first_cpu), machine, &aspeed_board_binfo);
>>  }

It looks OK to me. 

To be noted that the Aspeed machine use machine->kernel_filename to detect 
it is running without a bootloader which does some special settings, such 
as unlocking devices. In that case, we emulate the same behaviour.

Acked-by: Cédric Le Goater 

Thanks,

C.

>>  static void palmetto_bmc_i2c_init(AspeedBoardState *bmc)
>> diff --git a/hw/arm/boot.c b/hw/arm/boot.c
>> index c2b89b3bb9..ba604f8277 100644
>> --- a/hw/arm/boot.c
>> +++ b/hw/arm/boot.c
>> @@ -524,7 +524,7 @@ static void fdt_add_psci_node(void *fdt)
>>  }
>>  
>>  int arm_load_dtb(hwaddr addr, const struct arm_boot_info *binfo,
>> - hwaddr addr_limit, AddressSpace *as)
>> + hwaddr addr_limit, AddressSpace *as, MachineState *ms)
>>  {
>>  void *fdt = NULL;
>>  int size, rc, n = 0;
>> @@ -627,9 +627,9 @@ int arm_load_dtb(hwaddr addr, const struct arm_boot_info 
>> *binfo,
>>  qemu_fdt_add_subnode(fdt, "/chosen");
>>  }
>>  
>> -if (binfo->kernel_cmdline && *binfo->kernel_cmdline) {
>> +if (ms->kernel_cmdline && *ms->kernel_cmdline) {
>>  rc = qemu_fdt_setprop_string(fdt, "/chosen", "bootargs",
>> - binfo->kernel_cmdline);
>> + ms->kernel_cmdline);
>>  if (rc < 0) {
>>  fprintf(stderr, "couldn't set /chosen/bootargs\n");
>>  goto fail;
>> @@ -1261,7 +1261,7 @@ static void arm_setup_firmware_boot(ARMCPU *cpu, 
>> struct arm_boot_info *info)
>>   */
>>  }
>>  
>> -void arm_load_kernel(ARMCPU *cpu, struct arm_boot_info *info)
>> +void arm_load_kernel(ARMCPU *cpu, MachineState *ms, struct arm_boot_info 
>> *info)
>>  {
>>  CPUState *cs;
>>  AddressSpace *as = arm_boot_address_space(cpu, info);
>> @@ -1282,7 +1282,9 @@ void arm_load_kernel(ARMCPU *cpu, struct arm_boot_info 
>> *info)
>>   * doesn't support secure.
>>   */
>>  assert(!(info->secure_board_setup && kvm_enabled()));
>> -
>> +info->kernel_filena

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

[Yao, Jiewen]

My comments below.

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Wednesday, August 14, 2019 12:09 AM
> To: edk2-devel-groups-io 
> Cc: edk2-rfc-groups-io ; qemu devel list
> ; Igor Mammedov ;
> Paolo Bonzini ; Yao, Jiewen
> ; Chen, Yingwen ;
> Nakajima, Jun ; Boris Ostrovsky
> ; Joao Marcal Lemos Martins
> ; Phillip Goerl 
> Subject: Re: CPU hotplug using SMM with QEMU+OVMF
> 
> On 08/13/19 16:16, Laszlo Ersek wrote:
> 
> > Yingwen and Jiewen suggested the following process.
> >
> > Legend:
> >
> > - "New CPU":  CPU being hot-added
> > - "Host CPU": existing CPU
> > - (Flash):code running from flash
> > - (SMM):  code running from SMRAM
> >
> > Steps:
> >
> > (01) New CPU: (Flash) enter reset vector, Global SMI disabled by
> >  default.
> 
> - What does "Global SMI disabled by default" mean? In particular, what
>   is "global" here?
[Jiewen] OK. Let's don’t use the term "global".


>   Do you mean that the CPU being hot-plugged should mask (by default)
>   broadcast SMIs? What about directed SMIs? (An attacker could try that
>   too.)
[Jiewen] I mean all SMIs are blocked for this specific hot-added CPU.


>   And what about other processors? (I'd assume step (01)) is not
>   relevant for other processors, but "global" is quite confusing here.)
[Jiewen] No impact to other processors.


> - Does this part require a new branch somewhere in the OVMF SEC code?
>   How do we determine whether the CPU executing SEC is BSP or
>   hot-plugged AP?
[Jiewen] I think this is blocked from hardware perspective, since the first 
instruction.
There are some hardware specific registers can be used to determine if the CPU 
is new added.
I don’t think this must be same as the real hardware.
You are free to invent some registers in device model to be used in OVMF hot 
plug driver.


> - How do we tell the hot-plugged AP where to start execution? (I.e. that
>   it should execute code at a particular pflash location.)
[Jiewen] Same real mode reset vector at :FFF0.


>   For example, in MpInitLib, we start a specific AP with INIT-SIPI-SIPI,
>   where "SIPI" stores the startup address in the "Interrupt Command
>   Register" (which is memory-mapped in xAPIC mode, and an MSR in x2APIC
>   mode, apparently). That doesn't apply here -- should QEMU auto-start
>   the new CPU?
[Jiewen] You can send INIT-SIPI-SIPI to new CPU only after it can access memory.
SIPI need give AP an below 1M memory address as waking vector.


> - What memory is used as stack by the new CPU, when it runs code from
>   flash?
[Jiewen] Same as other CPU in normal boot. You can use special reserved memory.


>   QEMU does not emulate CAR (Cache As RAM). The new CPU doesn't have
>   access to SMRAM. And we cannot use AcpiNVS or Reserved memory,
> because
>   a malicious OS could use other CPUs -- or PCI device DMA -- to attack
>   the stack (unless QEMU forcibly paused other CPUs upon hotplug; I'm
>   not sure).
[Jiewen] Excellent point!
I don’t think there is problem for real hardware, who always has CAR.
Can QEMU provide some CPU specific space, such as MMIO region?


> - If an attempt is made to hotplug multiple CPUs in quick succession,
>   does something serialize those attempts?
[Jiewen] The BIOS need consider this as availability requirement.
I don’t have strong opinion.
You can design a system that required hotplug must be one-by-one, or fail the 
hot-add.
Or you can design a system that did not have such restriction.
Again, all we need to do is to maintain the integrity of SMM.
The availability should be considered as separate requirement.


>   Again, stack usage could be a concern, even with Cache-As-RAM --
>   HyperThreads (logical processors) on a single core don't have
>   dedicated cache.
[Jiewen] Agree with you on the virtual environment.
For real hardware, we do socket level hot-add only. So HT is not the concern.
But if you want to do that in virtual environment, a processor specific memory
should be considered.


>   Does CPU hotplug apply only at the socket level? If the CPU is
>   multi-core, what is responsible for hot-plugging all cores present in
>   the socket?
[Jiewen] Ditto.


> > (02) New CPU: (Flash) configure memory control to let it access global
> >  host memory.
> 
> In QEMU/KVM guests, we don't have to enable memory explicitly, it just
> exists and works.
> 
> In OVMF X64 SEC, we can't access RAM above 4GB, but that shouldn't be an
> issue per se.
[Jiewen] Agree. I do not see the issue.


> > (03) New CPU: (Flash) send board message to tell host CPU (GPIO->SCI)
> >  -- I am waiting for hot-add message.
> 
> Maybe we can simplify this in QEMU by broadcasting an SMI to existent
> processors immediately upon plugging the new CPU.
> 
> 
> >(NOTE: Host CPU can only
> send
> >  instruction in SMM mode. -- The register is SMM only)
> 
> Sorry, I don't follow -- what register are we talking about here, and
> why is the BSP needed to

Re: [Qemu-devel] [PATCH] usb: reword -usb command-line option and mention xHCI

[Stefan Hajnoczi]

On Tue, Aug 13, 2019 at 07:54:16PM +0200, Thomas Huth wrote:
> On 8/13/19 3:30 PM, Stefan Hajnoczi wrote:
> > The -usb section of the man page is not very clear on what exactly -usb
> > does and fails to mention xHCI as a modern alternative (-device
> > nec-usb-xhci).
> > 
> > Signed-off-by: Stefan Hajnoczi 
> > ---
> >  qemu-options.hx | 7 +--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> > 
> > diff --git a/qemu-options.hx b/qemu-options.hx
> > index 9621e934c0..7d11c016d1 100644
> > --- a/qemu-options.hx
> > +++ b/qemu-options.hx
> > @@ -1436,12 +1436,15 @@ STEXI
> >  ETEXI
> >  
> >  DEF("usb", 0, QEMU_OPTION_usb,
> > -"-usbenable the USB driver (if it is not used by default 
> > yet)\n",
> > +"-usbenable on-board USB host controller (if not enabled 
> > by default)\n",
> >  QEMU_ARCH_ALL)
> >  STEXI
> >  @item -usb
> >  @findex -usb
> > -Enable the USB driver (if it is not used by default yet).
> > +Enable USB emulation on machine types with an on-board USB host controller 
> > (if
> > +not enabled by default).  Note that on-board USB host controllers may not
> > +support USB 3.0.  In this case -device nec-usb-xhci can be used instead on
> 
> Should we maybe rather recommend qemu-xhci instead?

I think nec-usb-xhci is preferred because there are Windows drivers.
IIRC qemu-xhci works under Linux but not under Windows (just because the
PCI Vendor/Device ID aren't covered by any driver).

Gerd: Can you confirm this?

Stefan


signature.asc
Description: PGP signature

Re: [Qemu-devel] bitmaps branch rebase

[Vladimir Sementsov-Ogievskiy]

08.08.2019 0:45, John Snow wrote:
> FYI: I rebased jsnow/bitmaps on top of kwolf/block-next, itself based on
> top of v4.1.0-rc4.
> 
> I'll post this along with the eventual pull request, but here's the
> diffstat against the published patches:
> 
> 011/33:[0003] [FC] 'block/backup: upgrade copy_bitmap to BdrvDirtyBitmap'
> 016/33:[] [-C] 'iotests: Add virtio-scsi device helper'
> 017/33:[0002] [FC] 'iotests: add test 257 for bitmap-mode backups'
> 030/33:[0001] [FC] 'block/backup: teach TOP to never copy unallocated
> regions'
> 032/33:[0018] [FC] 'iotests/257: test traditional sync modes'
> 
> 11: A new hbitmap call was added upstream, changed to
> bdrv_dirty_bitmap_next_zero.
> 16: Context-only (self.has_quit is new context in 040)
> 17: Removed 'auto' to follow upstream trends in iotest fashion
> 30: Remove ret = -ECANCELED as agreed on-list;
>  Context changes for dirty_end patches
> 32: Fix capitalization in test, as mentioned on list.
> 
> I think the changes are actually fairly minimal and translate fairly
> directly; let's review the rebase on-list in response to the PULL mails
> when I send them.
> 


There is a bug in "block/backup: teach TOP to never copy unallocated regions":


 > @@ -256,6 +287,15 @@ static int coroutine_fn backup_do_cow(BackupBlockJob 
 > *job,
 >  continue; /* already copied */
 >  }
 >
 > +if (job->initializing_bitmap) {
 > +ret = backup_bitmap_reset_unallocated(job, start, &skip_bytes);
 > +if (ret == 0) {
 > +trace_backup_do_cow_skip_range(job, start, skip_bytes);
 > +start += skip_bytes;
 > +continue;
 > +}

assume ret == 1, so we see skip_bytes of allocated bytes

 > +}
 > +
 >  dirty_end = bdrv_dirty_bitmap_next_zero(job->copy_bitmap, start,
 >  (end - start));
 >  if (dirty_end < 0) {
 >

but then, we may copy more than skip_bytes, i.e. touch following possibly 
unallocated area.

===

Also, if want to fix it anyway, I think it's better to make additional while 
loop before this one
and reset all unallocated from start to end, otherwise we may call block_status 
for every cluster
on each loop iteration, even if the first call returns skip_bytes >= (end - 
start).

-- 
Best regards,
Vladimir

Re: [Qemu-devel] [PATCH 2/4] configure: Avoid using libssh deprecated API

[Andrea Bolognani]

On Wed, 2019-08-14 at 14:15 +0200, Philippe Mathieu-Daudé wrote:
> The libssh packaged by a distribution can predate version 0.8,
> but still provides the newer API introduced after version 0.7.
> 
> Using the deprecated API leads to build failure, as on Ubuntu 18.04:
> 
> CC  block/ssh.o
>   block/ssh.c: In function 'check_host_key_hash':
>   block/ssh.c:444:5: error: 'ssh_get_publickey' is deprecated 
> [-Werror=deprecated-declarations]
>r = ssh_get_publickey(s->session, &pubkey);
>^
>   In file included from block/ssh.c:27:0:
>   /usr/include/libssh/libssh.h:489:31: note: declared here
>SSH_DEPRECATED LIBSSH_API int ssh_get_publickey(ssh_session session, 
> ssh_key *key);
>  ^
>   rules.mak:69: recipe for target 'block/ssh.o' failed
>   make: *** [block/ssh.o] Error 1
> 
> Fix by using the newer API if available.
> 
> Suggested-by: Andrea Bolognani 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  block/ssh.c | 2 +-
>  configure   | 7 +++
>  2 files changed, 8 insertions(+), 1 deletion(-)

Did I really suggest this? I have no recollection of doing so, or
even getting involved with libssh support in QEMU at all for that
matter.

-- 
Andrea Bolognani / Red Hat / Virtualization

Re: [Qemu-devel] [PATCH v4 0/3] Add Aspeed GPIO controller model

[no-reply]

Patchew URL: 
https://patchew.org/QEMU/20190814071433.22243-1-rashmic...@gmail.com/



Hi,

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

=== TEST SCRIPT BEGIN ===
#!/bin/bash
# Testing script will be invoked under the git checkout with
# HEAD pointing to a commit that has the patches applied on top of "base"
# branch
set -e

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

echo
echo "=== PACKAGES ==="
rpm -qa

echo
echo "=== UNAME ==="
uname -a

CC=$HOME/bin/cc
INSTALL=$PWD/install
BUILD=$PWD/build
mkdir -p $BUILD $INSTALL
SRC=$PWD
cd $BUILD
$SRC/configure --cc=$CC --prefix=$INSTALL
make -j4
# XXX: we need reliable clean up
# make check -j4 V=1
make install
=== TEST SCRIPT END ===

  CC  arm-softmmu/hw/gpio/aspeed_gpio.o
  CC  alpha-softmmu/hw/virtio/vhost-user-blk-pci.o
  CC  aarch64-softmmu/tcg/tcg-op-vec.o
/var/tmp/patchew-tester-tmp-by4iq4ex/src/hw/gpio/aspeed_gpio.c:837:6: error: 
‘AspeedGPIOController’ {aka ‘const struct AspeedGPIOController’} has no member 
named ‘mem_size’
  837 | .mem_size   = GPIO_3_6V_MEM_SIZE,
  |  ^~~~
/var/tmp/patchew-tester-tmp-by4iq4ex/src/hw/gpio/aspeed_gpio.c:844:6: error: 
‘AspeedGPIOController’ {aka ‘const struct AspeedGPIOController’} has no member 
named ‘mem_size’
  844 | .mem_size   = GPIO_1_8V_MEM_SIZE,
  |  ^~~~
make[1]: *** [/var/tmp/patchew-tester-tmp-by4iq4ex/src/rules.mak:69: 
hw/gpio/aspeed_gpio.o] Error 1
---
  CC  aarch64-softmmu/hw/gpio/bcm2835_gpio.o
  CC  aarch64-softmmu/hw/gpio/nrf51_gpio.o
  CC  aarch64-softmmu/hw/gpio/aspeed_gpio.o
/var/tmp/patchew-tester-tmp-by4iq4ex/src/hw/gpio/aspeed_gpio.c:837:6: error: 
‘AspeedGPIOController’ {aka ‘const struct AspeedGPIOController’} has no member 
named ‘mem_size’
  837 | .mem_size   = GPIO_3_6V_MEM_SIZE,
  |  ^~~~
/var/tmp/patchew-tester-tmp-by4iq4ex/src/hw/gpio/aspeed_gpio.c:844:6: error: 
‘AspeedGPIOController’ {aka ‘const struct AspeedGPIOController’} has no member 
named ‘mem_size’
  844 | .mem_size   = GPIO_1_8V_MEM_SIZE,
  |  ^~~~
make[1]: *** [/var/tmp/patchew-tester-tmp-by4iq4ex/src/rules.mak:69: 
hw/gpio/aspeed_gpio.o] Error 1


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

Re: [Qemu-devel] [Qemu-block] [PATCH 7/7] iotests: Disable 126 for some vmdk subformats

[Max Reitz]

On 14.08.19 00:26, John Snow wrote:
> 
> 
> On 8/13/19 10:00 AM, Max Reitz wrote:
>> On 12.08.19 23:33, John Snow wrote:
>>>
>>>
>>> On 7/25/19 11:57 AM, Max Reitz wrote:
 Several vmdk subformats do not work with iotest 126, so disable them.

 (twoGbMaxExtentSparse actually should work, but fixing that is a bit
 difficult.  The problem is that the vmdk descriptor file will contain a
 referenc to "image:base.vmdk", which the block layer cannot open because
>>>
>>> reference
>>>
 it does not know the protocol "image".  This is not trivial to solve,
 because I suppose real protocols like "http://"; should be supported.
 Making vmdk treat all paths with a potential protocol prefix that the
 block layer does not recognize as plain files seems a bit weird,
 though.  Ignoring this problem does not seem too bad.)

 Signed-off-by: Max Reitz 
 ---
  tests/qemu-iotests/126 | 6 ++
  1 file changed, 6 insertions(+)

 diff --git a/tests/qemu-iotests/126 b/tests/qemu-iotests/126
 index 9b0dcf9255..8e55d7c843 100755
 --- a/tests/qemu-iotests/126
 +++ b/tests/qemu-iotests/126
 @@ -33,6 +33,12 @@ status=1# failure is the default!
  
  # Needs backing file support
  _supported_fmt qcow qcow2 qed vmdk
 +# (1) Flat vmdk images do not support backing files
 +# (2) Split vmdk images simply fail this test right now.  Fixing that
 +# is left for another day.
>>>
>>> Which one? :)
>>
>> H?  Fixing refers to #2.  #1 is not a bug or missing feature, it’s
>> just how it is.  (This test needs backing files, so...)
>>
>> If you mean “which are which“, then the ones with *Flat are flat images
>> (:-)), and the ones with twoGbMaxExtent* are split.
>>
> 
> "Which day" ;)
> 
 +_unsupported_imgopts "subformat=monolithicFlat" \
 + "subformat=twoGbMaxExtentFlat" \
 + "subformat=twoGbMaxExtentSparse"
  # This is the default protocol (and we want to test the difference between
  # colons which separate a protocol prefix from the rest and colons which 
 are
  # just part of the filename, so we cannot test protocols which require a 
 prefix)

>>>
>>> What exactly fails?
>>
>> Interestingly I only now noticed that the test passes with “vmdk: Use
>> bdrv_dirname() for relative extent paths” (patch 2) reverted...
>>
>>> Does the VMDK driver see `image:` and think it's a
>>> special filename it needs to handle and fails to do so?
>> No.  Whenever the block layer sees a parsee filename[1] with a colon
>> before a slash, it thinks everything before the colon is a protocol
>> prefix.  For example:
>>
> 
> Actually, I think we're on the same page here. I maybe meant to type
> "block layer" instead of "VMDK driver", but it does look like it does
> special processing on this sort of filename that breaks in this case.
> 
>> $ qemu-img info foo:bar
>> qemu-img: Could not open 'foo:bar': Unknown protocol 'foo'
>>
>> This test is precisely for this.  How can you specify an image filename
>> that has a colon in it (without using -blockdev)?  One way is to prepend
>> it with “./”, the other is “file:”.
>>
>> Now with split VMDKs, we must write something in the header file to
>> reference the extents.  What vmdk does for an image like
>> “image:foo.vmdk” is it writes “image:foo-s001.vmdk” there.
>>
>> When it tries to open that extent, what happens depends on whether
>> “vmdk: Use bdrv_dirname() for relative extent paths” (patch 2) is applied:
>>
>> --- Before that patch ---
>>
>> vmdk takes the descriptor filename, which, thanks to some magic in the
>> block layer, is always “./image:foo.vmdk”, even when you gave it as
>> “file:image:foo.vmdk” (the “file:” is stripped because it does nothing,
>> generally, and the “./” is then prepended because of the false protocol
>> prefix “image:”).
>>
>> It then invokes path_combine() with that path and the path given in the
>> descriptor file (“image:foo-s001.vmdk”).  This yields
>> “./image:foo-s001.vmdk”, which actually works.
>>
>> --- After that patch ---
>>
>> OK, what I messed up is that I just took the extent path to be an
>> absolute path if it has a protocol prefix.  (Because that’s how we
>> usually do it.)  Turns out that vmdk never did that, and path_combine()
>> actually completely ignores protocol prefixes in the relative filename.
>>
>> I suppose I could do the same and just drop the path_has_protocol() from
>> patch 2.  But that’d be a bit broken, as I wrote in the commit
>> message...  If the descriptor file refers to an extent on
>> “http://example.com/extent.vmdk”, I suppose that should not be
>> interpreted as a relative path, but actually work...
>>
>> But anyway, I guess if it’s a bit broken already, I might just keep it
>> that way.
>>
>>
>> tl;dr: Turns out patch 2 broke this test, because it (accidentally)
>> tried to fix something that I consider broken.  If I just keep it broke

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

[Paolo Bonzini]

On 14/08/19 15:20, Yao, Jiewen wrote:
>> - Does this part require a new branch somewhere in the OVMF SEC code?
>>   How do we determine whether the CPU executing SEC is BSP or
>>   hot-plugged AP?
> [Jiewen] I think this is blocked from hardware perspective, since the first 
> instruction.
> There are some hardware specific registers can be used to determine if the 
> CPU is new added.
> I don’t think this must be same as the real hardware.
> You are free to invent some registers in device model to be used in OVMF hot 
> plug driver.

Yes, this would be a new operation mode for QEMU, that only applies to
hot-plugged CPUs.  In this mode the AP doesn't reply to INIT or SMI, in
fact it doesn't reply to anything at all.

>> - How do we tell the hot-plugged AP where to start execution? (I.e. that
>>   it should execute code at a particular pflash location.)
> [Jiewen] Same real mode reset vector at :FFF0.

You do not need a reset vector or INIT/SIPI/SIPI sequence at all in
QEMU.  The AP does not start execution at all when it is unplugged, so
no cache-as-RAM etc.

We only need to modify QEMU so that hot-plugged APIs do not reply to
INIT/SIPI/SMI.

> I don’t think there is problem for real hardware, who always has CAR.
> Can QEMU provide some CPU specific space, such as MMIO region?

Why is a CPU-specific region needed if every other processor is in SMM
and thus trusted.

>>   Does CPU hotplug apply only at the socket level? If the CPU is
>>   multi-core, what is responsible for hot-plugging all cores present in
>>   the socket?

I can answer this: the SMM handler would interact with the hotplug
controller in the same way that ACPI DSDT does normally.  This supports
multiple hotplugs already.

Writes to the hotplug controller from outside SMM would be ignored.

>>> (03) New CPU: (Flash) send board message to tell host CPU (GPIO->SCI)
>>>  -- I am waiting for hot-add message.
>>
>> Maybe we can simplify this in QEMU by broadcasting an SMI to existent
>> processors immediately upon plugging the new CPU.

The QEMU DSDT could be modified (when secure boot is in effect) to OUT
to 0xB2 when hotplug happens.  It could write a well-known value to
0xB2, to be read by an SMI handler in edk2.


>>
>>>(NOTE: Host CPU can only
>> send
>>>  instruction in SMM mode. -- The register is SMM only)
>>
>> Sorry, I don't follow -- what register are we talking about here, and
>> why is the BSP needed to send anything at all? What "instruction" do you
>> have in mind?
> [Jiewen] The new CPU does not enable SMI at reset.
> At some point of time later, the CPU need enable SMI, right?
> The "instruction" here means, the host CPUs need tell to CPU to enable SMI.

Right, this would be a write to the CPU hotplug controller

>>> (04) Host CPU: (OS) get message from board that a new CPU is added.
>>>  (GPIO -> SCI)
>>>
>>> (05) Host CPU: (OS) All CPUs enter SMM (SCI->SWSMI) (NOTE: New CPU
>>>  will not enter CPU because SMI is disabled)
>>
>> I don't understand the OS involvement here. But, again, perhaps QEMU can
>> force all existent CPUs into SMM immediately upon adding the new CPU.
> [Jiewen] OS here means the Host CPU running code in OS environment, not in 
> SMM environment.

See above.

>>> (06) Host CPU: (SMM) Save 38000, Update 38000 -- fill simple SMM
>>>  rebase code.
>>>
>>> (07) Host CPU: (SMM) Send message to New CPU to Enable SMI.
>>
>> Aha, so this is the SMM-only register you mention in step (03). Is the
>> register specified in the Intel SDM?
> [Jiewen] Right. That is the register to let host CPU tell new CPU to enable 
> SMI.
> It is platform specific register. Not defined in SDM.
> You may invent one in device model.

See above.

>>> (10) New CPU: (SMM) Response first SMI at 38000, and rebase SMBASE to
>>>  TSEG.
>>
>> What code does the new CPU execute after it completes step (10)? Does it
>> halt?
>
> [Jiewen] The new CPU exits SMM and return to original place - where it is
> interrupted to enter SMM - running code on the flash.

So in our case we'd need an INIT/SIPI/SIPI sequence between (06) and (07).

>>> (11) Host CPU: (SMM) Restore 38000.
>>
>> These steps (i.e., (06) through (11)) don't appear RAS-specific. The
>> only platform-specific feature seems to be SMI masking register, which
>> could be extracted into a new SmmCpuFeaturesLib API.
>>
>> Thus, would you please consider open sourcing firmware code for steps
>> (06) through (11)?
>>
>> Alternatively -- and in particular because the stack for step (01)
>> concerns me --, we could approach this from a high-level, functional
>> perspective. The states that really matter are the relocated SMBASE for
>> the new CPU, and the state of the full system, right at the end of step
>> (11).
>>
>> When the SMM setup quiesces during normal firmware boot, OVMF could
>> use
>> existent (finalized) SMBASE infomation to *pre-program* some virtual
>> QEMU hardware, with such state that would be expected, as "fina

Re: [Qemu-devel] [PATCH 2/4] configure: Avoid using libssh deprecated API

[Philippe Mathieu-Daudé]

On 8/14/19 3:27 PM, Andrea Bolognani wrote:
> On Wed, 2019-08-14 at 14:15 +0200, Philippe Mathieu-Daudé wrote:
>> The libssh packaged by a distribution can predate version 0.8,
>> but still provides the newer API introduced after version 0.7.
>>
>> Using the deprecated API leads to build failure, as on Ubuntu 18.04:
>>
>> CC  block/ssh.o
>>   block/ssh.c: In function 'check_host_key_hash':
>>   block/ssh.c:444:5: error: 'ssh_get_publickey' is deprecated 
>> [-Werror=deprecated-declarations]
>>r = ssh_get_publickey(s->session, &pubkey);
>>^
>>   In file included from block/ssh.c:27:0:
>>   /usr/include/libssh/libssh.h:489:31: note: declared here
>>SSH_DEPRECATED LIBSSH_API int ssh_get_publickey(ssh_session session, 
>> ssh_key *key);
>>  ^
>>   rules.mak:69: recipe for target 'block/ssh.o' failed
>>   make: *** [block/ssh.o] Error 1
>>
>> Fix by using the newer API if available.
>>
>> Suggested-by: Andrea Bolognani 
>> Signed-off-by: Philippe Mathieu-Daudé 
>> ---
>>  block/ssh.c | 2 +-
>>  configure   | 7 +++
>>  2 files changed, 8 insertions(+), 1 deletion(-)
> 
> Did I really suggest this? I have no recollection of doing so, or
> even getting involved with libssh support in QEMU at all for that
> matter.

I took this suggestion from
https://www.redhat.com/archives/libvir-list/2018-May/msg00597.html

Re: [Qemu-devel] [PATCH 2/6] migration: Make global sem_sync semaphore by channel

[Dr. David Alan Gilbert]

* Juan Quintela (quint...@redhat.com) wrote:
> This makes easy to debug things because when you want for all threads
> to arrive at that semaphore, you know which one your are waiting for.
> 
> Signed-off-by: Juan Quintela 

Reviewed-by: Dr. David Alan Gilbert 

and queued.

> ---
>  migration/ram.c | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/migration/ram.c b/migration/ram.c
> index ca11d43e30..4bdd201a4e 100644
> --- a/migration/ram.c
> +++ b/migration/ram.c
> @@ -661,6 +661,8 @@ typedef struct {
>  uint64_t num_packets;
>  /* pages sent through this channel */
>  uint64_t num_pages;
> +/* syncs main thread and channels */
> +QemuSemaphore sem_sync;
>  }  MultiFDSendParams;
>  
>  typedef struct {
> @@ -896,8 +898,6 @@ struct {
>  MultiFDSendParams *params;
>  /* array of pages to sent */
>  MultiFDPages_t *pages;
> -/* syncs main thread and channels */
> -QemuSemaphore sem_sync;
>  /* global number of generated multifd packets */
>  uint64_t packet_num;
>  /* send channels ready */
> @@ -1038,6 +1038,7 @@ void multifd_save_cleanup(void)
>  p->c = NULL;
>  qemu_mutex_destroy(&p->mutex);
>  qemu_sem_destroy(&p->sem);
> +qemu_sem_destroy(&p->sem_sync);
>  g_free(p->name);
>  p->name = NULL;
>  multifd_pages_clear(p->pages);
> @@ -1047,7 +1048,6 @@ void multifd_save_cleanup(void)
>  p->packet = NULL;
>  }
>  qemu_sem_destroy(&multifd_send_state->channels_ready);
> -qemu_sem_destroy(&multifd_send_state->sem_sync);
>  g_free(multifd_send_state->params);
>  multifd_send_state->params = NULL;
>  multifd_pages_clear(multifd_send_state->pages);
> @@ -1092,7 +1092,7 @@ static void multifd_send_sync_main(void)
>  MultiFDSendParams *p = &multifd_send_state->params[i];
>  
>  trace_multifd_send_sync_main_wait(p->id);
> -qemu_sem_wait(&multifd_send_state->sem_sync);
> +qemu_sem_wait(&p->sem_sync);
>  }
>  trace_multifd_send_sync_main(multifd_send_state->packet_num);
>  }
> @@ -1152,7 +1152,7 @@ static void *multifd_send_thread(void *opaque)
>  qemu_mutex_unlock(&p->mutex);
>  
>  if (flags & MULTIFD_FLAG_SYNC) {
> -qemu_sem_post(&multifd_send_state->sem_sync);
> +qemu_sem_post(&p->sem_sync);
>  }
>  qemu_sem_post(&multifd_send_state->channels_ready);
>  } else if (p->quit) {
> @@ -1175,7 +1175,7 @@ out:
>   */
>  if (ret != 0) {
>  if (flags & MULTIFD_FLAG_SYNC) {
> -qemu_sem_post(&multifd_send_state->sem_sync);
> +qemu_sem_post(&p->sem_sync);
>  }
>  qemu_sem_post(&multifd_send_state->channels_ready);
>  }
> @@ -1221,7 +1221,6 @@ int multifd_save_setup(void)
>  multifd_send_state = g_malloc0(sizeof(*multifd_send_state));
>  multifd_send_state->params = g_new0(MultiFDSendParams, thread_count);
>  multifd_send_state->pages = multifd_pages_init(page_count);
> -qemu_sem_init(&multifd_send_state->sem_sync, 0);
>  qemu_sem_init(&multifd_send_state->channels_ready, 0);
>  
>  for (i = 0; i < thread_count; i++) {
> @@ -1229,6 +1228,7 @@ int multifd_save_setup(void)
>  
>  qemu_mutex_init(&p->mutex);
>  qemu_sem_init(&p->sem, 0);
> +qemu_sem_init(&p->sem_sync, 0);
>  p->quit = false;
>  p->pending_job = 0;
>  p->id = i;
> -- 
> 2.21.0
> 
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

Re: [Qemu-devel] [PATCH] ehci: Ensure that device is not NULL before calling usb_ep_get

[Guenter Roeck]

On Tue, Aug 13, 2019 at 01:42:03PM +0200, Gerd Hoffmann wrote:
> On Tue, Aug 06, 2019 at 06:23:38AM -0700, Guenter Roeck wrote:
> > On 8/2/19 7:11 AM, Gerd Hoffmann wrote:
> > > On Wed, Jul 31, 2019 at 01:08:50PM +0200, Philippe Mathieu-Daudé wrote:
> > > > On 7/30/19 7:45 PM, Guenter Roeck wrote:
> > > > > The following assert is seen once in a while while resetting the
> > > > > Linux kernel.
> > > > > 
> > > > > qemu-system-x86_64: hw/usb/core.c:734: usb_ep_get:
> > > > >   Assertion `dev != NULL' failed.
> > > > > 
> > > > > The call to usb_ep_get() originates from ehci_execute().
> > > > > Analysis and debugging shows that p->queue->dev can indeed be NULL
> > > > > in this function. Add check for this condition and return an error
> > > > > if it is seen.
> > > > 
> > > > Your patch is not wrong as it corrects your case, but I wonder why we
> > > > get there. This assert seems to have catched a bug.
> > > 
> > > https://bugzilla.redhat.com//show_bug.cgi?id=1715801 maybe.
> > > 
> > > > Gerd, shouldn't we call usb_packet_cleanup() in ehci_reset() rather than
> > > > ehci_finalize()? Then we shouldn't need this patch.
> > > 
> > > The two ehci_queues_rip_all() calls in ehci_reset() should clean up 
> > > everything
> > > properly.
> > > 
> > > Can you try the patch below to see whenever a ehci_find_device failure is 
> > > the
> > > root cause?
> > > 
> > > thanks,
> > >Gerd
> > > 
> > > diff --git a/hw/usb/hcd-ehci.c b/hw/usb/hcd-ehci.c
> > > index 62dab0592fa2..2b0a57772ed5 100644
> > > --- a/hw/usb/hcd-ehci.c
> > > +++ b/hw/usb/hcd-ehci.c
> > > @@ -1644,6 +1644,10 @@ static EHCIQueue *ehci_state_fetchqh(EHCIState 
> > > *ehci, int async)
> > >   q->dev = ehci_find_device(q->ehci,
> > > get_field(q->qh.epchar, 
> > > QH_EPCHAR_DEVADDR));
> > >   }
> > > +if (q->dev == NULL) {
> > > +fprintf(stderr, "%s: device %d not found\n", __func__,
> > > +get_field(q->qh.epchar, QH_EPCHAR_DEVADDR));
> > > +}
> > Turns out I end up seeing that message hundreds of times early on each boot,
> > no matter which architecture. It is quite obviously a normal operating 
> > condition.
> 
> Yep, as long as the queue is not active this is completely harmless.
> So we need to check a bit later.  In execute() looks a bit too late
> though, we don't have a good backup plan then.
> 
> Does the patch below solve the problem without bad side effects?
> 
I reverted my patch and applied the patch below to my builds of qemu, for both
v4.0 and v4.1, and installed it in my test bed. I'll let you know how it goes.

Thanks,
Guenter

> thanks,
>   Gerd
> 
> From 5980eaad23f675a2d509d0c55e288793619761bc Mon Sep 17 00:00:00 2001
> From: Gerd Hoffmann 
> Date: Tue, 13 Aug 2019 13:37:09 +0200
> Subject: [PATCH] ehci: try fix queue->dev null ptr dereference
> 
> Reported-by: Guenter Roeck 
> Signed-off-by: Gerd Hoffmann 
> ---
>  hw/usb/hcd-ehci.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/hw/usb/hcd-ehci.c b/hw/usb/hcd-ehci.c
> index 62dab0592fa2..5f089f30054b 100644
> --- a/hw/usb/hcd-ehci.c
> +++ b/hw/usb/hcd-ehci.c
> @@ -1834,6 +1834,9 @@ static int ehci_state_fetchqtd(EHCIQueue *q)
>  ehci_set_state(q->ehci, q->async, EST_EXECUTING);
>  break;
>  }
> +} else if (q->dev == NULL) {
> +ehci_trace_guest_bug(q->ehci, "no device attached to queue");
> +ehci_set_state(q->ehci, q->async, EST_HORIZONTALQH);
>  } else {
>  p = ehci_alloc_packet(q);
>  p->qtdaddr = q->qtdaddr;
> -- 
> 2.18.1
> 

[Qemu-devel] [PATCH 3/4] block/backup: use bdrv_dirty_bitmap_next_dirty

[Vladimir Sementsov-Ogievskiy]

Use more effective search for next dirty byte. Trace point is dropped
to not introduce additional variable and logic only for trace point.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
---
 block/backup.c | 7 +++
 block/trace-events | 1 -
 2 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/block/backup.c b/block/backup.c
index 07d751aea4..9bddea1b59 100644
--- a/block/backup.c
+++ b/block/backup.c
@@ -272,10 +272,9 @@ static int coroutine_fn backup_do_cow(BackupBlockJob *job,
 while (start < end) {
 int64_t dirty_end;
 
-if (!bdrv_dirty_bitmap_get(job->copy_bitmap, start)) {
-trace_backup_do_cow_skip(job, start);
-start += job->cluster_size;
-continue; /* already copied */
+start = bdrv_dirty_bitmap_next_dirty(job->copy_bitmap, start, end);
+if (start < 0) {
+break;
 }
 
 if (job->initializing_bitmap) {
diff --git a/block/trace-events b/block/trace-events
index 04209f058d..7e46f7e036 100644
--- a/block/trace-events
+++ b/block/trace-events
@@ -40,7 +40,6 @@ mirror_yield_in_flight(void *s, int64_t offset, int 
in_flight) "s %p offset %" P
 # backup.c
 backup_do_cow_enter(void *job, int64_t start, int64_t offset, uint64_t bytes) 
"job %p start %" PRId64 " offset %" PRId64 " bytes %" PRIu64
 backup_do_cow_return(void *job, int64_t offset, uint64_t bytes, int ret) "job 
%p offset %" PRId64 " bytes %" PRIu64 " ret %d"
-backup_do_cow_skip(void *job, int64_t start) "job %p start %"PRId64
 backup_do_cow_skip_range(void *job, int64_t start, uint64_t bytes) "job %p 
start %"PRId64" bytes %"PRId64
 backup_do_cow_process(void *job, int64_t start) "job %p start %"PRId64
 backup_do_cow_read_fail(void *job, int64_t start, int ret) "job %p start 
%"PRId64" ret %d"
-- 
2.18.0

[Qemu-devel] [PATCH 2/4] block/dirty-bitmap: add _next_dirty API

[Vladimir Sementsov-Ogievskiy]

We have bdrv_dirty_bitmap_next_zero, let's add corresponding
bdrv_dirty_bitmap_next_dirty, which is more comfortable to use than
bitmap iterators in some cases. It will be used in the following
commit.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
---
 include/block/dirty-bitmap.h |  2 ++
 include/qemu/hbitmap.h   | 13 
 block/dirty-bitmap.c |  6 
 util/hbitmap.c   | 61 +++-
 4 files changed, 54 insertions(+), 28 deletions(-)

diff --git a/include/block/dirty-bitmap.h b/include/block/dirty-bitmap.h
index 493c4566d3..d1310ee76e 100644
--- a/include/block/dirty-bitmap.h
+++ b/include/block/dirty-bitmap.h
@@ -108,6 +108,8 @@ bool bdrv_has_changed_persistent_bitmaps(BlockDriverState 
*bs);
 BdrvDirtyBitmap *bdrv_dirty_bitmap_next(BlockDriverState *bs,
 BdrvDirtyBitmap *bitmap);
 char *bdrv_dirty_bitmap_sha256(const BdrvDirtyBitmap *bitmap, Error **errp);
+int64_t bdrv_dirty_bitmap_next_dirty(BdrvDirtyBitmap *bitmap, int64_t offset,
+ int64_t bytes);
 int64_t bdrv_dirty_bitmap_next_zero(BdrvDirtyBitmap *bitmap, int64_t offset,
 int64_t bytes);
 bool bdrv_dirty_bitmap_next_dirty_area(BdrvDirtyBitmap *bitmap,
diff --git a/include/qemu/hbitmap.h b/include/qemu/hbitmap.h
index 5149ac7721..80ecabe8e2 100644
--- a/include/qemu/hbitmap.h
+++ b/include/qemu/hbitmap.h
@@ -299,6 +299,19 @@ void hbitmap_iter_init(HBitmapIter *hbi, const HBitmap 
*hb, uint64_t first);
  */
 unsigned long hbitmap_iter_skip_words(HBitmapIter *hbi);
 
+/*
+ * hbitmap_next_dirty:
+ *
+ * Find next dirty bit within selected range. If not found, return -1.
+ *
+ * @hb: The HBitmap to operate on
+ * @start: The bit to start from.
+ * @count: Number of bits to proceed. If @start+@count > bitmap size, the whole
+ * bitmap is looked through. You can use UINT64_MAX as @count to search up to
+ * the bitmap end.
+ */
+int64_t hbitmap_next_dirty(const HBitmap *hb, int64_t start, int64_t count);
+
 /* hbitmap_next_zero:
  *
  * Find next not dirty bit within selected range. If not found, return -1.
diff --git a/block/dirty-bitmap.c b/block/dirty-bitmap.c
index eeccdb48f5..efe3a39d49 100644
--- a/block/dirty-bitmap.c
+++ b/block/dirty-bitmap.c
@@ -802,6 +802,12 @@ char *bdrv_dirty_bitmap_sha256(const BdrvDirtyBitmap 
*bitmap, Error **errp)
 return hbitmap_sha256(bitmap->bitmap, errp);
 }
 
+int64_t bdrv_dirty_bitmap_next_dirty(BdrvDirtyBitmap *bitmap, int64_t offset,
+ int64_t bytes)
+{
+return hbitmap_next_zero(bitmap->bitmap, offset, bytes);
+}
+
 int64_t bdrv_dirty_bitmap_next_zero(BdrvDirtyBitmap *bitmap, int64_t offset,
 int64_t bytes)
 {
diff --git a/util/hbitmap.c b/util/hbitmap.c
index c08751fb50..3f2d7451ce 100644
--- a/util/hbitmap.c
+++ b/util/hbitmap.c
@@ -193,6 +193,30 @@ void hbitmap_iter_init(HBitmapIter *hbi, const HBitmap 
*hb, uint64_t first)
 }
 }
 
+int64_t hbitmap_next_dirty(const HBitmap *hb, int64_t start, int64_t count)
+{
+HBitmapIter hbi;
+int64_t firt_dirty_off;
+uint64_t end;
+
+assert(start >= 0 && count >= 0);
+
+if (start >= hb->orig_size || count == 0) {
+return -1;
+}
+
+end = count > hb->orig_size - start ? hb->orig_size : start + count;
+
+hbitmap_iter_init(&hbi, hb, start);
+firt_dirty_off = hbitmap_iter_next(&hbi);
+
+if (firt_dirty_off < 0 || firt_dirty_off >= end) {
+return -1;
+}
+
+return MAX(start, firt_dirty_off);
+}
+
 int64_t hbitmap_next_zero(const HBitmap *hb, int64_t start, int64_t count)
 {
 size_t pos = (start >> hb->granularity) >> BITS_PER_LEVEL;
@@ -248,40 +272,21 @@ int64_t hbitmap_next_zero(const HBitmap *hb, int64_t 
start, int64_t count)
 
 bool hbitmap_next_dirty_area(const HBitmap *hb, int64_t *start, int64_t *count)
 {
-HBitmapIter hbi;
-int64_t firt_dirty_off, area_end;
-uint32_t granularity = 1UL << hb->granularity;
-uint64_t end;
-
-assert(*start >= 0 && *count >= 0);
-
-if (*start >= hb->orig_size || *count == 0) {
-return false;
-}
-
-end = *count > hb->orig_size - *start ? hb->orig_size : *start + *count;
-
-hbitmap_iter_init(&hbi, hb, *start);
-firt_dirty_off = hbitmap_iter_next(&hbi);
+int64_t area_start, area_end;
 
-if (firt_dirty_off < 0 || firt_dirty_off >= end) {
+area_start = hbitmap_next_dirty(hb, *start, *count);
+if (area_start < 0) {
 return false;
 }
 
-if (firt_dirty_off + granularity >= end) {
-area_end = end;
-} else {
-area_end = hbitmap_next_zero(hb, firt_dirty_off + granularity,
- end - firt_dirty_off - granularity);
-if (area_end < 0) {
-area_end = end;
-}
+area_end = QEMU_ALIGN_UP(area_start + 1, 1UL << hb->granularity);
+area_end = hbitmap_next_zero(hb, area_end, *start + *c

[Qemu-devel] [PATCH 4/4] block/backup: fix and improve skipping unallocated in backup_do_cow

[Vladimir Sementsov-Ogievskiy]

1. There is a bug: after detection an allocated area of skip_bytes
length we ignore skip_bytes variable and my finish up by copying more
than skip_bytes.

2. If request area is allocated we call block_status for each cluster
on each loop iteration, even if after the first call we know that the
whole request area is allocated.

Solve all of this by handling resetting all unallocated bytes from
requested area before copying loop.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
---
 block/backup.c | 26 --
 1 file changed, 16 insertions(+), 10 deletions(-)

diff --git a/block/backup.c b/block/backup.c
index 9bddea1b59..d0815b21c8 100644
--- a/block/backup.c
+++ b/block/backup.c
@@ -257,7 +257,6 @@ static int coroutine_fn backup_do_cow(BackupBlockJob *job,
 int ret = 0;
 int64_t start, end; /* bytes */
 void *bounce_buffer = NULL;
-int64_t skip_bytes;
 
 qemu_co_rwlock_rdlock(&job->flush_rwlock);
 
@@ -269,6 +268,22 @@ static int coroutine_fn backup_do_cow(BackupBlockJob *job,
 wait_for_overlapping_requests(job, start, end);
 cow_request_begin(&cow_request, job, start, end);
 
+if (job->initializing_bitmap) {
+int64_t off = start;
+int64_t count;
+
+while (off < end) {
+off = bdrv_dirty_bitmap_next_dirty(job->copy_bitmap,
+   off, end - off);
+if (off < 0) {
+break;
+}
+
+backup_bitmap_reset_unallocated(job, off, &count);
+off += count;
+}
+}
+
 while (start < end) {
 int64_t dirty_end;
 
@@ -277,15 +292,6 @@ static int coroutine_fn backup_do_cow(BackupBlockJob *job,
 break;
 }
 
-if (job->initializing_bitmap) {
-ret = backup_bitmap_reset_unallocated(job, start, &skip_bytes);
-if (ret == 0) {
-trace_backup_do_cow_skip_range(job, start, skip_bytes);
-start += skip_bytes;
-continue;
-}
-}
-
 dirty_end = bdrv_dirty_bitmap_next_zero(job->copy_bitmap, start,
 (end - start));
 if (dirty_end < 0) {
-- 
2.18.0

[Qemu-devel] [PATCH 0/4] backup: fix skipping unallocated clusters

[Vladimir Sementsov-Ogievskiy]

Hi all!

There is a bug in not yet merged patch
"block/backup: teach TOP to never copy unallocated regions"
in https://github.com/jnsnow/qemu bitmaps. 04 fixes it. So, I propose
to put 01-03 somewhere before
"block/backup: teach TOP to never copy unallocated regions"
and squash 04 into "block/backup: teach TOP to never copy unallocated regions"

Based-on: https://github.com/jnsnow/qemu bitmaps

Vladimir Sementsov-Ogievskiy (4):
  block/dirty-bitmap: switch _next_dirty_area and _next_zero to int64_t
  block/dirty-bitmap: add _next_dirty API
  block/backup: use bdrv_dirty_bitmap_next_dirty
  block/backup: fix and improve skipping unallocated in backup_do_cow

 include/block/dirty-bitmap.h |  8 ++--
 include/qemu/hbitmap.h   | 18 +++--
 block/backup.c   | 33 ++---
 block/dirty-bitmap.c | 12 --
 block/mirror.c   |  4 +-
 tests/test-hbitmap.c | 32 
 util/hbitmap.c   | 72 
 block/trace-events   |  1 -
 8 files changed, 107 insertions(+), 73 deletions(-)

-- 
2.18.0

[Qemu-devel] [PATCH 1/4] block/dirty-bitmap: switch _next_dirty_area and _next_zero to int64_t

[Vladimir Sementsov-Ogievskiy]

It's very uncomfortable that we can't use same variable as result of
bdrv_dirty_bitmap_next_zero and parameter of
bdrv_dirty_bitmap_next_dirty_area.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
---
 include/block/dirty-bitmap.h |  6 +++---
 include/qemu/hbitmap.h   |  5 ++---
 block/dirty-bitmap.c |  6 +++---
 block/mirror.c   |  4 ++--
 tests/test-hbitmap.c | 32 
 util/hbitmap.c   | 15 ++-
 6 files changed, 36 insertions(+), 32 deletions(-)

diff --git a/include/block/dirty-bitmap.h b/include/block/dirty-bitmap.h
index 4b4b731b46..493c4566d3 100644
--- a/include/block/dirty-bitmap.h
+++ b/include/block/dirty-bitmap.h
@@ -108,10 +108,10 @@ bool bdrv_has_changed_persistent_bitmaps(BlockDriverState 
*bs);
 BdrvDirtyBitmap *bdrv_dirty_bitmap_next(BlockDriverState *bs,
 BdrvDirtyBitmap *bitmap);
 char *bdrv_dirty_bitmap_sha256(const BdrvDirtyBitmap *bitmap, Error **errp);
-int64_t bdrv_dirty_bitmap_next_zero(BdrvDirtyBitmap *bitmap, uint64_t offset,
-uint64_t bytes);
+int64_t bdrv_dirty_bitmap_next_zero(BdrvDirtyBitmap *bitmap, int64_t offset,
+int64_t bytes);
 bool bdrv_dirty_bitmap_next_dirty_area(BdrvDirtyBitmap *bitmap,
-   uint64_t *offset, uint64_t *bytes);
+   int64_t *offset, int64_t *bytes);
 BdrvDirtyBitmap *bdrv_reclaim_dirty_bitmap_locked(BlockDriverState *bs,
   BdrvDirtyBitmap *bitmap,
   Error **errp);
diff --git a/include/qemu/hbitmap.h b/include/qemu/hbitmap.h
index 4afbe6292e..5149ac7721 100644
--- a/include/qemu/hbitmap.h
+++ b/include/qemu/hbitmap.h
@@ -309,7 +309,7 @@ unsigned long hbitmap_iter_skip_words(HBitmapIter *hbi);
  * bitmap is looked through. You can use UINT64_MAX as @count to search up to
  * the bitmap end.
  */
-int64_t hbitmap_next_zero(const HBitmap *hb, uint64_t start, uint64_t count);
+int64_t hbitmap_next_zero(const HBitmap *hb, int64_t start, int64_t count);
 
 /* hbitmap_next_dirty_area:
  * @hb: The HBitmap to operate on
@@ -324,8 +324,7 @@ int64_t hbitmap_next_zero(const HBitmap *hb, uint64_t 
start, uint64_t count);
  * @offset and @bytes appropriately. Otherwise returns false and leaves @offset
  * and @bytes unchanged.
  */
-bool hbitmap_next_dirty_area(const HBitmap *hb, uint64_t *start,
- uint64_t *count);
+bool hbitmap_next_dirty_area(const HBitmap *hb, int64_t *start, int64_t 
*count);
 
 /* hbitmap_create_meta:
  * Create a "meta" hbitmap to track dirtiness of the bits in this HBitmap.
diff --git a/block/dirty-bitmap.c b/block/dirty-bitmap.c
index 134e0c9a0c..eeccdb48f5 100644
--- a/block/dirty-bitmap.c
+++ b/block/dirty-bitmap.c
@@ -802,14 +802,14 @@ char *bdrv_dirty_bitmap_sha256(const BdrvDirtyBitmap 
*bitmap, Error **errp)
 return hbitmap_sha256(bitmap->bitmap, errp);
 }
 
-int64_t bdrv_dirty_bitmap_next_zero(BdrvDirtyBitmap *bitmap, uint64_t offset,
-uint64_t bytes)
+int64_t bdrv_dirty_bitmap_next_zero(BdrvDirtyBitmap *bitmap, int64_t offset,
+int64_t bytes)
 {
 return hbitmap_next_zero(bitmap->bitmap, offset, bytes);
 }
 
 bool bdrv_dirty_bitmap_next_dirty_area(BdrvDirtyBitmap *bitmap,
-   uint64_t *offset, uint64_t *bytes)
+   int64_t *offset, int64_t *bytes)
 {
 return hbitmap_next_dirty_area(bitmap->bitmap, offset, bytes);
 }
diff --git a/block/mirror.c b/block/mirror.c
index 56937ebe92..0d3b078f44 100644
--- a/block/mirror.c
+++ b/block/mirror.c
@@ -1198,8 +1198,8 @@ do_sync_target_write(MirrorBlockJob *job, MirrorMethod 
method,
  QEMUIOVector *qiov, int flags)
 {
 QEMUIOVector target_qiov;
-uint64_t dirty_offset = offset;
-uint64_t dirty_bytes;
+int64_t dirty_offset = offset;
+int64_t dirty_bytes;
 
 if (qiov) {
 qemu_iovec_init(&target_qiov, qiov->niov);
diff --git a/tests/test-hbitmap.c b/tests/test-hbitmap.c
index eed5d288cb..462a6c3f74 100644
--- a/tests/test-hbitmap.c
+++ b/tests/test-hbitmap.c
@@ -946,7 +946,7 @@ static void 
test_hbitmap_next_zero_check_range(TestHBitmapData *data,
 
 static void test_hbitmap_next_zero_check(TestHBitmapData *data, int64_t start)
 {
-test_hbitmap_next_zero_check_range(data, start, UINT64_MAX);
+test_hbitmap_next_zero_check_range(data, start, INT64_MAX);
 }
 
 static void test_hbitmap_next_zero_do(TestHBitmapData *data, int granularity)
@@ -1014,11 +1014,11 @@ static void 
test_hbitmap_next_zero_after_truncate(TestHBitmapData *data,
 }
 
 static void test_hbitmap_next_dirty_area_check(TestHBitmapData *data,
-   uint64_t offset,
-   

Re: [Qemu-devel] [PATCH 2/4] configure: Avoid using libssh deprecated API

[Andrea Bolognani]

On Wed, 2019-08-14 at 16:15 +0200, Philippe Mathieu-Daudé wrote:
> On 8/14/19 3:27 PM, Andrea Bolognani wrote:
> > On Wed, 2019-08-14 at 14:15 +0200, Philippe Mathieu-Daudé wrote:
> > > The libssh packaged by a distribution can predate version 0.8,
> > > but still provides the newer API introduced after version 0.7.
> > > 
> > > Using the deprecated API leads to build failure, as on Ubuntu 18.04:
> > > 
> > > CC  block/ssh.o
> > >   block/ssh.c: In function 'check_host_key_hash':
> > >   block/ssh.c:444:5: error: 'ssh_get_publickey' is deprecated 
> > > [-Werror=deprecated-declarations]
> > >r = ssh_get_publickey(s->session, &pubkey);
> > >^
> > >   In file included from block/ssh.c:27:0:
> > >   /usr/include/libssh/libssh.h:489:31: note: declared here
> > >SSH_DEPRECATED LIBSSH_API int ssh_get_publickey(ssh_session session, 
> > > ssh_key *key);
> > >  ^
> > >   rules.mak:69: recipe for target 'block/ssh.o' failed
> > >   make: *** [block/ssh.o] Error 1
> > > 
> > > Fix by using the newer API if available.
> > > 
> > > Suggested-by: Andrea Bolognani 
> > > Signed-off-by: Philippe Mathieu-Daudé 
> > > ---
> > >  block/ssh.c | 2 +-
> > >  configure   | 7 +++
> > >  2 files changed, 8 insertions(+), 1 deletion(-)
> > 
> > Did I really suggest this? I have no recollection of doing so, or
> > even getting involved with libssh support in QEMU at all for that
> > matter.
> 
> I took this suggestion from
> https://www.redhat.com/archives/libvir-list/2018-May/msg00597.html

I see :)

I feel like adding a Suggested-by because of something that was
posted on an unrelated project's mailing list is stretching the
definition of the tag a bit, so if you end up having to respin I
think it would be reasonable to drop it, but honestly it's not a
big deal either way: I was just curious.

-- 
Andrea Bolognani / Red Hat / Virtualization

Re: [Qemu-devel] [PATCH 0/6] Fix multifd with big number of channels

[Dr. David Alan Gilbert]

* Juan Quintela (quint...@redhat.com) wrote:
> Hi
> 
> When we have much more channels than cpus, we end having failures when
> writting to sockets. This series:
> - add some traces
> - fix some of the trouble with serialization of creating the
>   threads/channels in proper order.
> - Ask for help with the last patch.  See documentation there.
> 
> Please, review.

patchew is reporting a failure that looks like it came from one of
these; but I'm not sure which one yet!

> 
> Juan Quintela (6):
>   migration: Add traces for multifd terminate threads
>   migration: Make global sem_sync semaphore by channel
>   migration: Make sure that all multifd channels have been created
>   migration: Make multifd threads wait until all have been created
>   migration: add some multifd traces
>   RFH: We lost "connect" events
> 
>  migration/ram.c| 60 +++---
>  migration/trace-events |  8 ++
>  2 files changed, 59 insertions(+), 9 deletions(-)
> 
> -- 
> 2.21.0
> 
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

Re: [Qemu-devel] [PATCH 3/6] migration: Make sure that all multifd channels have been created

[Dr. David Alan Gilbert]

* Juan Quintela (quint...@redhat.com) wrote:
> If we start the migration before all have been created, we have to
> handle the case that one channel still don't exist.  This way it is
> easier.
> 
> Signed-off-by: Juan Quintela 
> ---
>  migration/ram.c| 14 ++
>  migration/trace-events |  1 +
>  2 files changed, 15 insertions(+)
> 
> diff --git a/migration/ram.c b/migration/ram.c
> index 4bdd201a4e..4a6ae677a9 100644
> --- a/migration/ram.c
> +++ b/migration/ram.c
> @@ -663,6 +663,8 @@ typedef struct {
>  uint64_t num_pages;
>  /* syncs main thread and channels */
>  QemuSemaphore sem_sync;
> +/* thread has started and setup is done */
> +QemuSemaphore started;
>  }  MultiFDSendParams;
>  
>  typedef struct {
> @@ -1039,6 +1041,7 @@ void multifd_save_cleanup(void)
>  qemu_mutex_destroy(&p->mutex);
>  qemu_sem_destroy(&p->sem);
>  qemu_sem_destroy(&p->sem_sync);
> +qemu_sem_destroy(&p->started);
>  g_free(p->name);
>  p->name = NULL;
>  multifd_pages_clear(p->pages);
> @@ -1113,6 +1116,8 @@ static void *multifd_send_thread(void *opaque)
>  /* initial packet */
>  p->num_packets = 1;
>  
> +qemu_sem_post(&p->started);
> +
>  while (true) {
>  qemu_sem_wait(&p->sem);
>  qemu_mutex_lock(&p->mutex);
> @@ -1229,6 +1234,7 @@ int multifd_save_setup(void)
>  qemu_mutex_init(&p->mutex);
>  qemu_sem_init(&p->sem, 0);
>  qemu_sem_init(&p->sem_sync, 0);
> +qemu_sem_init(&p->started, 0);
>  p->quit = false;
>  p->pending_job = 0;
>  p->id = i;
> @@ -3486,6 +3492,14 @@ static int ram_save_setup(QEMUFile *f, void *opaque)
>  ram_control_before_iterate(f, RAM_CONTROL_SETUP);
>  ram_control_after_iterate(f, RAM_CONTROL_SETUP);
>  
> +/* We want to wait for all threads to have started before doing
> + * anything else */
> +for (int i = 0; i < migrate_multifd_channels(); i++) {
> +MultiFDSendParams *p = &multifd_send_state->params[i];
> +
> +qemu_sem_wait(&p->started);
> +trace_multifd_send_thread_started(p->id);
> +}

What happens if there's an error during startup and either we cancel or
the migration fails and we try and cleanup - how do we get out of this
loop?

Dave

>  multifd_send_sync_main();
>  qemu_put_be64(f, RAM_SAVE_FLAG_EOS);
>  qemu_fflush(f);
> diff --git a/migration/trace-events b/migration/trace-events
> index 886ce70ca0..dd13a5c4b1 100644
> --- a/migration/trace-events
> +++ b/migration/trace-events
> @@ -95,6 +95,7 @@ multifd_send_sync_main_wait(uint8_t id) "channel %d"
>  multifd_send_terminate_threads(bool error) "error %d"
>  multifd_send_thread_end(uint8_t id, uint64_t packets, uint64_t pages) 
> "channel %d packets %" PRIu64 " pages %"  PRIu64
>  multifd_send_thread_start(uint8_t id) "%d"
> +multifd_send_thread_started(uint8_t id) "channel %d"
>  ram_discard_range(const char *rbname, uint64_t start, size_t len) "%s: 
> start: %" PRIx64 " %zx"
>  ram_load_loop(const char *rbname, uint64_t addr, int flags, void *host) "%s: 
> addr: 0x%" PRIx64 " flags: 0x%x host: %p"
>  ram_load_postcopy_loop(uint64_t addr, int flags) "@%" PRIx64 " %x"
> -- 
> 2.21.0
> 
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

Re: [Qemu-devel] [PATCH v2 2/4] block/qcow2: refactor qcow2_co_preadv_part

[Max Reitz]

On 14.08.19 11:11, Vladimir Sementsov-Ogievskiy wrote:
> 14.08.2019 0:31, Max Reitz wrote:
>> On 30.07.19 16:18, Vladimir Sementsov-Ogievskiy wrote:
>>> Further patch will run partial requests of iterations of
>>> qcow2_co_preadv in parallel for performance reasons. To prepare for
>>> this, separate part which may be parallelized into separate function
>>> (qcow2_co_preadv_task).
>>>
>>> While being here, also separate encrypted clusters reading to own
>>> function, like it is done for compressed reading.
>>>
>>> Signed-off-by: Vladimir Sementsov-Ogievskiy 
>>> ---
>>>   qapi/block-core.json |   2 +-
>>>   block/qcow2.c| 206 +++
>>>   2 files changed, 112 insertions(+), 96 deletions(-)
>>
>> Looks good to me overall, just wondering about some details, as always.
>>
>>> diff --git a/block/qcow2.c b/block/qcow2.c
>>> index 93ab7edcea..7fa71968b2 100644
>>> --- a/block/qcow2.c
>>> +++ b/block/qcow2.c
>>> @@ -1967,17 +1967,115 @@ out:
>>>   return ret;
>>>   }
>>>   
>>> +static coroutine_fn int
>>> +qcow2_co_preadv_encrypted(BlockDriverState *bs,
>>> +   uint64_t file_cluster_offset,
>>> +   uint64_t offset,
>>> +   uint64_t bytes,
>>> +   QEMUIOVector *qiov,
>>> +   uint64_t qiov_offset)
>>> +{
>>> +int ret;
>>> +BDRVQcow2State *s = bs->opaque;
>>> +uint8_t *buf;
>>> +
>>> +assert(bs->encrypted && s->crypto);
>>> +assert(bytes <= QCOW_MAX_CRYPT_CLUSTERS * s->cluster_size);
>>> +
>>> +/*
>>> + * For encrypted images, read everything into a temporary
>>> + * contiguous buffer on which the AES functions can work.
>>> + * Note, that we can implement enctyption, working on qiov,
>>
>> -, and s/enctyption/encryption/
>>
>>> + * but we must not do decryption in guest buffers for security
>>> + * reasons.
>>
>> "for security reasons" is a bit handwave-y, no?
> 
> Hmm, let's think of it a bit.
> 
> WRITE
> 
> 1. We can't do any operations on write buffers, as guest may use them for
> something else and not prepared for their change. [thx to Den, pointed to 
> this fact]

Yep.  So we actually cannot implement encryption in the guest buffer. :-)

> READ
> 
> Hmm, here otherwise, guest should not expect something meaningful in buffers 
> until the
> end of read operation, so theoretically we may decrypt directly in guest 
> buffer.. What is
> bad with it?
> 
> 1. Making read-part different from write and implementing support of qiov for 
> decryptin for
> little outcome (hmm, don't double allocation for reads, is it little or not? 
> [*]).
> 
> 2. Guest can read its buffers.
> So, it may see encrypted data and guess something about it. Ideally guest
> should know nothing about encryption, but on the other hand, is there any
> real damage? I don't sure..
> 
> 3. Guest can modify its buffers.
> 3.1 I think there is no guarantee that guest will not modify its data before 
> we finished
> copying to separate buffer, so what guest finally reads is not predictable 
> anyway.
> 3.2 But, modifying during decryption may possibly lead to guest visible error
> (which will never be if we operate on separated cluster)
> 
> So if we don't afraid of [2] and [3.2], and in a specific case [*] is 
> significant, we may want
> implement decryption on guest buffers at least as an option..
> But all it looks for me like we'll never do it.

Well, I do think it would be weird from a guest perspective to see data
changing twice.  I just couldn’t figure out what the security problem
might be.

> ===
> 
> So, I'd rewrite my "Note" like this:
> 
> Also, decryption in separate buffer is better as it hides from the guest 
> information
> it doesn't own (about encrypted nature of virtual disk).

Sounds good.

>> [...]
>>
>>> +static coroutine_fn int qcow2_co_preadv_task(BlockDriverState *bs,
>>> + QCow2ClusterType cluster_type,
>>> + uint64_t file_cluster_offset,
>>> + uint64_t offset, uint64_t 
>>> bytes,
>>> + QEMUIOVector *qiov,
>>> + size_t qiov_offset)
>>> +{
>>> +BDRVQcow2State *s = bs->opaque;
>>> +int offset_in_cluster = offset_into_cluster(s, offset);
>>> +
>>> +switch (cluster_type) {
>>
>> [...]
>>
>>> +default:
>>> +g_assert_not_reached();
>>> +/*
>>> + * QCOW2_CLUSTER_ZERO_PLAIN and QCOW2_CLUSTER_ZERO_ALLOC handled
>>> + * in qcow2_co_preadv_part
>>
>> Hmm, I’d still add them explicitly as cases and put their own
>> g_assert_not_reach() there.
>>
>>> + */
>>> +}
>>> +
>>> +g_assert_not_reached();
>>> +
>>> +return -EIO;
>>
>> Maybe abort()ing instead of g_assert_not_reach() would save you from
>> having to return here?
>>
> 
> Hmm, wi

[Qemu-devel] [PATCH v1] s390x/tcg: Fix VERIM with 32/64 bit elements

[David Hildenbrand]

Wrong order of operands. The constant always comes last. Makes QEMU crash
reliably on specific git fetch invocations.

Reported-by: Stefano Brivio 
Signed-off-by: David Hildenbrand 
---

I guess it is too late for 4.1 :(

---
 target/s390x/translate_vx.inc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/s390x/translate_vx.inc.c b/target/s390x/translate_vx.inc.c
index 41d5cf869f..0caddb3958 100644
--- a/target/s390x/translate_vx.inc.c
+++ b/target/s390x/translate_vx.inc.c
@@ -213,7 +213,7 @@ static void get_vec_element_ptr_i64(TCGv_ptr ptr, uint8_t 
reg, TCGv_i64 enr,
vec_full_reg_offset(v3), ptr, 16, 16, data, fn)
 #define gen_gvec_3i(v1, v2, v3, c, gen) \
 tcg_gen_gvec_3i(vec_full_reg_offset(v1), vec_full_reg_offset(v2), \
-vec_full_reg_offset(v3), c, 16, 16, gen)
+vec_full_reg_offset(v3), 16, 16, c, gen)
 #define gen_gvec_4(v1, v2, v3, v4, gen) \
 tcg_gen_gvec_4(vec_full_reg_offset(v1), vec_full_reg_offset(v2), \
vec_full_reg_offset(v3), vec_full_reg_offset(v4), \
-- 
2.21.0

Re: [Qemu-devel] [PATCH 2/4] configure: Avoid using libssh deprecated API

[Philippe Mathieu-Daudé]

On 8/14/19 4:51 PM, Andrea Bolognani wrote:
> On Wed, 2019-08-14 at 16:15 +0200, Philippe Mathieu-Daudé wrote:
>> On 8/14/19 3:27 PM, Andrea Bolognani wrote:
>>> On Wed, 2019-08-14 at 14:15 +0200, Philippe Mathieu-Daudé wrote:
 The libssh packaged by a distribution can predate version 0.8,
 but still provides the newer API introduced after version 0.7.

 Using the deprecated API leads to build failure, as on Ubuntu 18.04:

 CC  block/ssh.o
   block/ssh.c: In function 'check_host_key_hash':
   block/ssh.c:444:5: error: 'ssh_get_publickey' is deprecated 
 [-Werror=deprecated-declarations]
r = ssh_get_publickey(s->session, &pubkey);
^
   In file included from block/ssh.c:27:0:
   /usr/include/libssh/libssh.h:489:31: note: declared here
SSH_DEPRECATED LIBSSH_API int ssh_get_publickey(ssh_session session, 
 ssh_key *key);
  ^
   rules.mak:69: recipe for target 'block/ssh.o' failed
   make: *** [block/ssh.o] Error 1

 Fix by using the newer API if available.

 Suggested-by: Andrea Bolognani 
 Signed-off-by: Philippe Mathieu-Daudé 
 ---
  block/ssh.c | 2 +-
  configure   | 7 +++
  2 files changed, 8 insertions(+), 1 deletion(-)
>>>
>>> Did I really suggest this? I have no recollection of doing so, or
>>> even getting involved with libssh support in QEMU at all for that
>>> matter.
>>
>> I took this suggestion from
>> https://www.redhat.com/archives/libvir-list/2018-May/msg00597.html
> 
> I see :)
> 
> I feel like adding a Suggested-by because of something that was
> posted on an unrelated project's mailing list is stretching the
> definition of the tag a bit, so if you end up having to respin I
> think it would be reasonable to drop it, but honestly it's not a
> big deal either way: I was just curious.

Understood, sorry.

Re: [Qemu-devel] [PATCH v2 2/4] block/qcow2: refactor qcow2_co_preadv_part

[Eric Blake]

On 8/14/19 4:11 AM, Vladimir Sementsov-Ogievskiy wrote:
> 14.08.2019 0:31, Max Reitz wrote:
>> On 30.07.19 16:18, Vladimir Sementsov-Ogievskiy wrote:
>>> Further patch will run partial requests of iterations of
>>> qcow2_co_preadv in parallel for performance reasons. To prepare for
>>> this, separate part which may be parallelized into separate function
>>> (qcow2_co_preadv_task).
>>>
>>> While being here, also separate encrypted clusters reading to own
>>> function, like it is done for compressed reading.
>>>
>>> Signed-off-by: Vladimir Sementsov-Ogievskiy 
>>> ---

>>> + * but we must not do decryption in guest buffers for security
>>> + * reasons.
>>
>> "for security reasons" is a bit handwave-y, no?
> 
> Hmm, let's think of it a bit.
> 
> WRITE
> 
> 1. We can't do any operations on write buffers, as guest may use them for
> something else and not prepared for their change. [thx to Den, pointed to 
> this fact]
> 
> READ
> 
> Hmm, here otherwise, guest should not expect something meaningful in buffers 
> until the
> end of read operation, so theoretically we may decrypt directly in guest 
> buffer.. What is
> bad with it?

The badness is that the guest can theoretically reverse-engineer the
encryption keys if they are savvy enough to grab the contents of the
buffer before and after.  The guest must NEVER be able to see the
encrypted bits, which means decryption requires a bounce buffer.

> 
> 1. Making read-part different from write and implementing support of qiov for 
> decryptin for
> little outcome (hmm, don't double allocation for reads, is it little or not? 
> [*]).
> 
> 2. Guest can read its buffers.
> So, it may see encrypted data and guess something about it. Ideally guest
> should know nothing about encryption, but on the other hand, is there any
> real damage? I don't sure..

Yes, this is the security risk.

> 
> 3. Guest can modify its buffers.
> 3.1 I think there is no guarantee that guest will not modify its data before 
> we finished
> copying to separate buffer, so what guest finally reads is not predictable 
> anyway.
> 3.2 But, modifying during decryption may possibly lead to guest visible error
> (which will never be if we operate on separated cluster)
> 
> So if we don't afraid of [2] and [3.2], and in a specific case [*] is 
> significant, we may want
> implement decryption on guest buffers at least as an option..
> But all it looks for me like we'll never do it.
> 
> ===
> 
> So, I'd rewrite my "Note" like this:
> 
> Also, decryption in separate buffer is better as it hides from the guest 
> information
> it doesn't own (about encrypted nature of virtual disk).

Possible wording tweak:

Also, decryption in a separate buffer is better as it prevents the guest
from learning information about the encrypted nature of the virtual disk.


>>> +}
>>> +
>>> +g_assert_not_reached();
>>> +
>>> +return -EIO;
>>
>> Maybe abort()ing instead of g_assert_not_reach() would save you from
>> having to return here?
>>
> 
> Hmm, will check. Any reason to use g_assert_not_reached() instead of abort() 
> in "default"?
> I just kept it like it was. But it seems to be more often practice to use 
> just abort() in
> Qemu code.

Both are used. abort() is shorter to type, but g_assert_not_reach() is
slightly friendlier to developers (which are the only people that would
ever see the failure).  As both are marked noreturn, the real fix is to
drop the dead return -EIO line, the compiler is smart enough to not need
a return statement after a noreturn function.

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v6 25/42] mirror: Deal with filters

[Vladimir Sementsov-Ogievskiy]

12.08.2019 16:26, Max Reitz wrote:
> On 12.08.19 13:09, Vladimir Sementsov-Ogievskiy wrote:
>> 09.08.2019 19:13, Max Reitz wrote:
>>> This includes some permission limiting (for example, we only need to
>>> take the RESIZE permission for active commits where the base is smaller
>>> than the top).
>>>
>>> Signed-off-by: Max Reitz 
>>> ---
>>>block/mirror.c | 117 ++---
>>>blockdev.c |  47 +---
>>>2 files changed, 131 insertions(+), 33 deletions(-)
>>>
>>> diff --git a/block/mirror.c b/block/mirror.c
>>> index 54bafdf176..6ddbfb9708 100644
>>> --- a/block/mirror.c
>>> +++ b/block/mirror.c
>>
>>
>> [..]
>>
>>> @@ -1693,15 +1734,39 @@ static BlockJob *mirror_start_job(
>>>/* In commit_active_start() all intermediate nodes disappear, so
>>> * any jobs in them must be blocked */
>>>if (target_is_backing) {
>>> -BlockDriverState *iter;
>>> -for (iter = backing_bs(bs); iter != target; iter = 
>>> backing_bs(iter)) {
>>> -/* XXX BLK_PERM_WRITE needs to be allowed so we don't block
>>> - * ourselves at s->base (if writes are blocked for a node, 
>>> they are
>>> - * also blocked for its backing file). The other options would 
>>> be a
>>> - * second filter driver above s->base (== target). */
>>> +BlockDriverState *iter, *filtered_target;
>>> +uint64_t iter_shared_perms;
>>> +
>>> +/*
>>> + * The topmost node with
>>> + * bdrv_skip_rw_filters(filtered_target) == 
>>> bdrv_skip_rw_filters(target)
>>> + */
>>> +filtered_target = bdrv_filtered_cow_bs(bdrv_find_overlay(bs, 
>>> target));
>>> +
>>> +assert(bdrv_skip_rw_filters(filtered_target) ==
>>> +   bdrv_skip_rw_filters(target));
>>> +
>>> +/*
>>> + * XXX BLK_PERM_WRITE needs to be allowed so we don't block
>>> + * ourselves at s->base (if writes are blocked for a node, they are
>>> + * also blocked for its backing file). The other options would be a
>>> + * second filter driver above s->base (== target).
>>> + */
>>> +iter_shared_perms = BLK_PERM_WRITE_UNCHANGED | BLK_PERM_WRITE;
>>> +
>>> +for (iter = bdrv_filtered_bs(bs); iter != target;
>>> + iter = bdrv_filtered_bs(iter))
>>> +{
>>> +if (iter == filtered_target) {
>>> +/*
>>> + * From here on, all nodes are filters on the base.
>>> + * This allows us to share BLK_PERM_CONSISTENT_READ.
>>> + */
>>> +iter_shared_perms |= BLK_PERM_CONSISTENT_READ;
>>
>>
>> Hmm, I don't understand, why read from upper nodes is not shared?
> 
> Because they don’t represent a consistent disk state during the commit.
> 
> Please don’t ask me details about CONSISTENT_READ, because I always
> pretend I understand it, but I never really do, actually.
> 
> (My problem is that I do understand why the intermediate nodes shouldn’t
> share CONSISTENT_READ: It’s because they only read garbage, effectively.
>   But I don’t understand how any block job target (like our base here)
> can have CONSISTENT_READ.

I know such example: it's image fleecing scheme, when for backup job source
is a backing for target. If serialization of requests works well target 
represents
consistent state of disk ate backup-start point in time.

But yes, it's not about mirror or commit.

>  Block job targets are mostly written front to
> back (except with sync=none), so they too don’t “[represent] the
> contents of a disk at a specific point.”
> But that is how it was, so that is how it should be kept.)
> 
> If it makes you any happier, BLK_PERM_CONSISTENT_READ’s description
> explicitly notes that it will not be shared on intermediate nodes of a
> commit job.
> 
> Max
> 
>>> +}
>>> +
>>>ret = block_job_add_bdrv(&s->common, "intermediate node", 
>>> iter, 0,
>>> - BLK_PERM_WRITE_UNCHANGED | 
>>> BLK_PERM_WRITE,
>>> - errp);
>>> + iter_shared_perms, errp);
>>>if (ret < 0) {
>>>goto fail;
>>>}
>>
>> [..]
>>
> 
> 


-- 
Best regards,
Vladimir

[Qemu-devel] [PATCH v4] riscv: hmp: Add a command to show virtual memory mappings

[Bin Meng]

This adds 'info mem' command for RISC-V, to show virtual memory
mappings that aids debugging.

Rather than showing every valid PTE, the command compacts the
output by merging all contiguous physical address mappings into
one block and only shows the merged block mapping details.

Signed-off-by: Bin Meng 
Acked-by: Dr. David Alan Gilbert 
Reviewed-by: Palmer Dabbelt 

---

Changes in v4:
- restore to v2, that does not print all harts's PTE, since we
  should switch to a cpu context via the 'cpu' command

Changes in v3:
- print PTEs for all harts instead of just current hart

Changes in v2:
- promote ppn to hwaddr when doing page table address calculation

 hmp-commands-info.hx   |   2 +-
 target/riscv/Makefile.objs |   4 +
 target/riscv/monitor.c | 229 +
 3 files changed, 234 insertions(+), 1 deletion(-)
 create mode 100644 target/riscv/monitor.c

diff --git a/hmp-commands-info.hx b/hmp-commands-info.hx
index c59444c..257ee7d 100644
--- a/hmp-commands-info.hx
+++ b/hmp-commands-info.hx
@@ -249,7 +249,7 @@ STEXI
 Show virtual to physical memory mappings.
 ETEXI
 
-#if defined(TARGET_I386)
+#if defined(TARGET_I386) || defined(TARGET_RISCV)
 {
 .name   = "mem",
 .args_type  = "",
diff --git a/target/riscv/Makefile.objs b/target/riscv/Makefile.objs
index b1c79bc..a8ceccd 100644
--- a/target/riscv/Makefile.objs
+++ b/target/riscv/Makefile.objs
@@ -1,5 +1,9 @@
 obj-y += translate.o op_helper.o cpu_helper.o cpu.o csr.o fpu_helper.o 
gdbstub.o pmp.o
 
+ifeq ($(CONFIG_SOFTMMU),y)
+obj-y += monitor.o
+endif
+
 DECODETREE = $(SRC_PATH)/scripts/decodetree.py
 
 decode32-y = $(SRC_PATH)/target/riscv/insn32.decode
diff --git a/target/riscv/monitor.c b/target/riscv/monitor.c
new file mode 100644
index 000..d725a7a
--- /dev/null
+++ b/target/riscv/monitor.c
@@ -0,0 +1,229 @@
+/*
+ * QEMU monitor for RISC-V
+ *
+ * Copyright (c) 2019 Bin Meng 
+ *
+ * RISC-V specific monitor commands implementation
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2 or later, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include "qemu/osdep.h"
+#include "cpu.h"
+#include "cpu_bits.h"
+#include "monitor/monitor.h"
+#include "monitor/hmp-target.h"
+
+#ifdef TARGET_RISCV64
+#define PTE_HEADER_FIELDS   "vaddrpaddr"\
+"size attr\n"
+#define PTE_HEADER_DELIMITER"  "\
+" ---\n"
+#else
+#define PTE_HEADER_FIELDS   "vaddrpaddrsize attr\n"
+#define PTE_HEADER_DELIMITER"   ---\n"
+#endif
+
+/* Perform linear address sign extension */
+static target_ulong addr_canonical(int va_bits, target_ulong addr)
+{
+#ifdef TARGET_RISCV64
+if (addr & (1UL << (va_bits - 1))) {
+addr |= (hwaddr)-(1L << va_bits);
+}
+#endif
+
+return addr;
+}
+
+static void print_pte_header(Monitor *mon)
+{
+monitor_printf(mon, PTE_HEADER_FIELDS);
+monitor_printf(mon, PTE_HEADER_DELIMITER);
+}
+
+static void print_pte(Monitor *mon, int va_bits, target_ulong vaddr,
+  hwaddr paddr, target_ulong size, int attr)
+{
+/* santity check on vaddr */
+if (vaddr >= (1UL << va_bits)) {
+return;
+}
+
+if (!size) {
+return;
+}
+
+monitor_printf(mon, TARGET_FMT_lx " " TARGET_FMT_plx " " TARGET_FMT_lx
+   " %c%c%c%c%c%c%c\n",
+   addr_canonical(va_bits, vaddr),
+   paddr, size,
+   attr & PTE_R ? 'r' : '-',
+   attr & PTE_W ? 'w' : '-',
+   attr & PTE_X ? 'x' : '-',
+   attr & PTE_U ? 'u' : '-',
+   attr & PTE_G ? 'g' : '-',
+   attr & PTE_A ? 'a' : '-',
+   attr & PTE_D ? 'd' : '-');
+}
+
+static void walk_pte(Monitor *mon, hwaddr base, target_ulong start,
+ int level, int ptidxbits, int ptesize, int va_bits,
+ target_ulong *vbase, hwaddr *pbase, hwaddr *last_paddr,
+ target_ulong *last_size, int *last_attr)
+{
+hwaddr pte_addr;
+hwaddr paddr;
+target_ulong pgsize;
+target_ulong pte;
+int ptshift;
+int attr;
+int idx;
+
+if (level < 0) {
+return;
+}
+
+ptshift = level * ptidxbits;
+pgsize = 1UL << (PGSHIFT + ptshift);
+
+for (idx = 0;

Re: [Qemu-devel] [PATCH] riscv: hmp: Add a command to show virtual memory mappings

[Bin Meng]

Hi Palmer,

On Wed, Aug 14, 2019 at 9:35 AM Bin Meng  wrote:
>
> Hi Palmer,
>
> On Tue, Aug 13, 2019 at 11:18 PM Palmer Dabbelt  wrote:
> >
> > On Wed, 31 Jul 2019 05:49:15 PDT (-0700), bmeng...@gmail.com wrote:
> > > This adds 'info mem' command for RISC-V, to show virtual memory
> > > mappings that aids debugging.
> > >
> > > Rather than showing every valid PTE, the command compacts the
> > > output by merging all contiguous physical address mappings into
> > > one block and only shows the merged block mapping details.
> > >
> > > Signed-off-by: Bin Meng 
> > > ---
> > >
> > >  hmp-commands-info.hx   |   2 +-
> > >  target/riscv/Makefile.objs |   4 +
> > >  target/riscv/monitor.c | 227 
> > > +
> > >  3 files changed, 232 insertions(+), 1 deletion(-)
> > >  create mode 100644 target/riscv/monitor.c
> > >
> > > diff --git a/hmp-commands-info.hx b/hmp-commands-info.hx
> > > index c59444c..257ee7d 100644
> > > --- a/hmp-commands-info.hx
> > > +++ b/hmp-commands-info.hx
> > > @@ -249,7 +249,7 @@ STEXI
> > >  Show virtual to physical memory mappings.
> > >  ETEXI
> > >
> > > -#if defined(TARGET_I386)
> > > +#if defined(TARGET_I386) || defined(TARGET_RISCV)
> > >  {
> > >  .name   = "mem",
> > >  .args_type  = "",
> > > diff --git a/target/riscv/Makefile.objs b/target/riscv/Makefile.objs
> > > index b1c79bc..a8ceccd 100644
> > > --- a/target/riscv/Makefile.objs
> > > +++ b/target/riscv/Makefile.objs
> > > @@ -1,5 +1,9 @@
> > >  obj-y += translate.o op_helper.o cpu_helper.o cpu.o csr.o fpu_helper.o 
> > > gdbstub.o pmp.o
> > >
> > > +ifeq ($(CONFIG_SOFTMMU),y)
> > > +obj-y += monitor.o
> > > +endif
> > > +
> > >  DECODETREE = $(SRC_PATH)/scripts/decodetree.py
> > >
> > >  decode32-y = $(SRC_PATH)/target/riscv/insn32.decode
> > > diff --git a/target/riscv/monitor.c b/target/riscv/monitor.c
> > > new file mode 100644
> > > index 000..30560ff
> > > --- /dev/null
> > > +++ b/target/riscv/monitor.c
> > > @@ -0,0 +1,227 @@
> > > +/*
> > > + * QEMU monitor for RISC-V
> > > + *
> > > + * Copyright (c) 2019 Bin Meng 
> > > + *
> > > + * RISC-V specific monitor commands implementation
> > > + *
> > > + * This program is free software; you can redistribute it and/or modify 
> > > it
> > > + * under the terms and conditions of the GNU General Public License,
> > > + * version 2 or later, as published by the Free Software Foundation.
> > > + *
> > > + * This program is distributed in the hope it will be useful, but WITHOUT
> > > + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> > > + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License 
> > > for
> > > + * more details.
> > > + *
> > > + * You should have received a copy of the GNU General Public License 
> > > along with
> > > + * this program.  If not, see .
> > > + */
> > > +
> > > +#include "qemu/osdep.h"
> > > +#include "cpu.h"
> > > +#include "cpu_bits.h"
> > > +#include "monitor/monitor.h"
> > > +#include "monitor/hmp-target.h"
> > > +
> > > +#ifdef TARGET_RISCV64
> > > +#define PTE_HEADER_FIELDS   "vaddrpaddr"\
> > > +"size attr\n"
> > > +#define PTE_HEADER_DELIMITER"  "\
> > > +" ---\n"
> > > +#else
> > > +#define PTE_HEADER_FIELDS   "vaddrpaddrsize 
> > > attr\n"
> > > +#define PTE_HEADER_DELIMITER"   
> > > ---\n"
> > > +#endif
> > > +
> > > +/* Perform linear address sign extension */
> > > +static target_ulong addr_canonical(int va_bits, target_ulong addr)
> > > +{
> > > +#ifdef TARGET_RISCV64
> > > +if (addr & (1UL << (va_bits - 1))) {
> > > +addr |= (hwaddr)-(1L << va_bits);
> > > +}
> > > +#endif
> > > +
> > > +return addr;
> > > +}
> > > +
> > > +static void print_pte_header(Monitor *mon)
> > > +{
> > > +monitor_printf(mon, PTE_HEADER_FIELDS);
> > > +monitor_printf(mon, PTE_HEADER_DELIMITER);
> > > +}
> > > +
> > > +static void print_pte(Monitor *mon, int va_bits, target_ulong vaddr,
> > > +  hwaddr paddr, target_ulong size, int attr)
> > > +{
> > > +/* santity check on vaddr */
> > > +if (vaddr >= (1UL << va_bits)) {
> > > +return;
> > > +}
> > > +
> > > +if (!size) {
> > > +return;
> > > +}
> > > +
> > > +monitor_printf(mon, TARGET_FMT_lx " " TARGET_FMT_plx " " 
> > > TARGET_FMT_lx
> > > +   " %c%c%c%c%c%c%c\n",
> > > +   addr_canonical(va_bits, vaddr),
> > > +   paddr, size,
> > > +   attr & PTE_R ? 'r' : '-',
> > > +   attr & PTE_W ? 'w' : '-',
> > > +   attr & PTE_X ? 'x' : '-',
> > > +   attr & PTE_U ? 'u' : '-',
> > > +   attr & PTE_G ? 'g' : '-',
> > > +

Re: [Qemu-devel] [PATCH v1] s390x/tcg: Fix VERIM with 32/64 bit elements

[Cornelia Huck]

On Wed, 14 Aug 2019 17:12:42 +0200
David Hildenbrand  wrote:

> Wrong order of operands. The constant always comes last. Makes QEMU crash
> reliably on specific git fetch invocations.
> 
> Reported-by: Stefano Brivio 
> Signed-off-by: David Hildenbrand 
> ---
> 
> I guess it is too late for 4.1 :(

Yup :(

But cc:stable worthy, I guess.

> 
> ---
>  target/s390x/translate_vx.inc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/target/s390x/translate_vx.inc.c b/target/s390x/translate_vx.inc.c
> index 41d5cf869f..0caddb3958 100644
> --- a/target/s390x/translate_vx.inc.c
> +++ b/target/s390x/translate_vx.inc.c
> @@ -213,7 +213,7 @@ static void get_vec_element_ptr_i64(TCGv_ptr ptr, uint8_t 
> reg, TCGv_i64 enr,
> vec_full_reg_offset(v3), ptr, 16, 16, data, fn)
>  #define gen_gvec_3i(v1, v2, v3, c, gen) \
>  tcg_gen_gvec_3i(vec_full_reg_offset(v1), vec_full_reg_offset(v2), \
> -vec_full_reg_offset(v3), c, 16, 16, gen)
> +vec_full_reg_offset(v3), 16, 16, c, gen)
>  #define gen_gvec_4(v1, v2, v3, v4, gen) \
>  tcg_gen_gvec_4(vec_full_reg_offset(v1), vec_full_reg_offset(v2), \
> vec_full_reg_offset(v3), vec_full_reg_offset(v4), \

Re: [Qemu-devel] [PATCH v1] s390x/tcg: Fix VERIM with 32/64 bit elements

[David Hildenbrand]

On 14.08.19 17:41, Cornelia Huck wrote:
> On Wed, 14 Aug 2019 17:12:42 +0200
> David Hildenbrand  wrote:
> 
>> Wrong order of operands. The constant always comes last. Makes QEMU crash
>> reliably on specific git fetch invocations.
>>
>> Reported-by: Stefano Brivio 
>> Signed-off-by: David Hildenbrand 
>> ---
>>
>> I guess it is too late for 4.1 :(
> 
> Yup :(
> 
> But cc:stable worthy, I guess.
> 

Yes. Added this bug to

https://wiki.qemu.org/Planning/4.1#Not_yet_fixed_in_any_rc

>>
>> ---
>>  target/s390x/translate_vx.inc.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/target/s390x/translate_vx.inc.c 
>> b/target/s390x/translate_vx.inc.c
>> index 41d5cf869f..0caddb3958 100644
>> --- a/target/s390x/translate_vx.inc.c
>> +++ b/target/s390x/translate_vx.inc.c
>> @@ -213,7 +213,7 @@ static void get_vec_element_ptr_i64(TCGv_ptr ptr, 
>> uint8_t reg, TCGv_i64 enr,
>> vec_full_reg_offset(v3), ptr, 16, 16, data, fn)
>>  #define gen_gvec_3i(v1, v2, v3, c, gen) \
>>  tcg_gen_gvec_3i(vec_full_reg_offset(v1), vec_full_reg_offset(v2), \
>> -vec_full_reg_offset(v3), c, 16, 16, gen)
>> +vec_full_reg_offset(v3), 16, 16, c, gen)
>>  #define gen_gvec_4(v1, v2, v3, v4, gen) \
>>  tcg_gen_gvec_4(vec_full_reg_offset(v1), vec_full_reg_offset(v2), \
>> vec_full_reg_offset(v3), vec_full_reg_offset(v4), \
> 


-- 

Thanks,

David / dhildenb

Re: [Qemu-devel] [PATCH v2 3/4] block/qcow2: refactor qcow2_co_pwritev_part

[Max Reitz]

On 30.07.19 16:18, Vladimir Sementsov-Ogievskiy wrote:
> Similarly to previous commit, prepare for parallelizing write-loop
> iterations.
> 
> Signed-off-by: Vladimir Sementsov-Ogievskiy 
> ---
>  block/qcow2.c | 150 +-
>  1 file changed, 88 insertions(+), 62 deletions(-)
> 
> diff --git a/block/qcow2.c b/block/qcow2.c
> index 7fa71968b2..37766b8b7c 100644
> --- a/block/qcow2.c
> +++ b/block/qcow2.c

[...]

> @@ -2283,62 +2362,11 @@ static coroutine_fn int qcow2_co_pwritev_part(

[...]

> +ret = qcow2_co_pwritev_task(bs, cluster_offset, offset, cur_bytes,
> +qiov, bytes_done, l2meta);

You’re passing bytes_done as qiov_offset here.  That is initialized to
0, so it ignores the qiov_offset given to qcow2_co_pwritev_part().

Max



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v2 2/4] block/qcow2: refactor qcow2_co_preadv_part

[Max Reitz]

On 14.08.19 17:15, Eric Blake wrote:
> On 8/14/19 4:11 AM, Vladimir Sementsov-Ogievskiy wrote:
>> 14.08.2019 0:31, Max Reitz wrote:
>>> On 30.07.19 16:18, Vladimir Sementsov-Ogievskiy wrote:
 Further patch will run partial requests of iterations of
 qcow2_co_preadv in parallel for performance reasons. To prepare for
 this, separate part which may be parallelized into separate function
 (qcow2_co_preadv_task).

 While being here, also separate encrypted clusters reading to own
 function, like it is done for compressed reading.

 Signed-off-by: Vladimir Sementsov-Ogievskiy 
 ---
> 
 + * but we must not do decryption in guest buffers for security
 + * reasons.
>>>
>>> "for security reasons" is a bit handwave-y, no?
>>
>> Hmm, let's think of it a bit.
>>
>> WRITE
>>
>> 1. We can't do any operations on write buffers, as guest may use them for
>> something else and not prepared for their change. [thx to Den, pointed to 
>> this fact]
>>
>> READ
>>
>> Hmm, here otherwise, guest should not expect something meaningful in buffers 
>> until the
>> end of read operation, so theoretically we may decrypt directly in guest 
>> buffer.. What is
>> bad with it?
> 
> The badness is that the guest can theoretically reverse-engineer the
> encryption keys if they are savvy enough to grab the contents of the
> buffer before and after.  The guest must NEVER be able to see the
> encrypted bits, which means decryption requires a bounce buffer.

Our encryption does not protect against a known-plaintext attack?

Max



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH] test-bitmap: test set 1 bit case for bitmap_set

[Wei Yang]

On Wed, Aug 14, 2019 at 02:38:24PM +0200, Paolo Bonzini wrote:
>On 14/08/19 02:27, Wei Yang wrote:
>> All current bitmap_set test cases set range across word, while the
>> handle of a range within one word is different from that.
>> 
>> Add case to set 1 bit as a represent for set range within one word.
>> 
>> Signed-off-by: Wei Yang 
>> 
>> ---
>> Thanks for Paolo's finding.
>> 
>> ---
>>  tests/test-bitmap.c | 12 
>>  1 file changed, 12 insertions(+)
>> 
>> diff --git a/tests/test-bitmap.c b/tests/test-bitmap.c
>> index 18aa584591..087e02a26c 100644
>> --- a/tests/test-bitmap.c
>> +++ b/tests/test-bitmap.c
>> @@ -67,6 +67,18 @@ static void bitmap_set_case(bmap_set_func set_func)
>>  
>>  bmap = bitmap_new(BMAP_SIZE);
>>  
>> +/* Set one bit at offset in second word */
>> +for (offset = 0; offset <= BITS_PER_LONG; offset++) {
>> +bitmap_clear(bmap, 0, BMAP_SIZE);
>> +set_func(bmap, BITS_PER_LONG + offset, 1);
>> +g_assert_cmpint(find_first_bit(bmap, 2 * BITS_PER_LONG),
>> +==, BITS_PER_LONG + offset);
>> +g_assert_cmpint(find_next_zero_bit(bmap,
>> +   3 * BITS_PER_LONG,
>> +   BITS_PER_LONG + offset),
>> +==, BITS_PER_LONG + offset + 1);
>> +}
>> +
>>  /* Both Aligned, set bits [BITS_PER_LONG, 3*BITS_PER_LONG] */
>>  set_func(bmap, BITS_PER_LONG, 2 * BITS_PER_LONG);
>>  g_assert_cmpuint(bmap[1], ==, -1ul);
>> 
>
>Queued, thanks for writing the testcase without no one asking! :)
>

My pleasure to help :)

>Paolo

-- 
Wei Yang
Help you, Help me

Re: [Qemu-devel] [PATCH v6 30/42] qemu-img: Use child access functions

[Vladimir Sementsov-Ogievskiy]

09.08.2019 19:13, Max Reitz wrote:
> This changes iotest 204's output, because blkdebug on top of a COW node
> used to make qemu-img map disregard the rest of the backing chain (the
> backing chain was broken by the filter).  With this patch, the
> allocation in the base image is reported correctly.
> 
> Signed-off-by: Max Reitz 
> ---
>   qemu-img.c | 33 -
>   tests/qemu-iotests/204.out |  1 +
>   2 files changed, 21 insertions(+), 13 deletions(-)
> 
> diff --git a/qemu-img.c b/qemu-img.c
> index 79983772de..3b30c5ae70 100644
> --- a/qemu-img.c
> +++ b/qemu-img.c
> @@ -1012,7 +1012,7 @@ static int img_commit(int argc, char **argv)
>   /* This is different from QMP, which by default uses the deepest 
> file in
>* the backing chain (i.e., the very base); however, the traditional
>* behavior of qemu-img commit is using the immediate backing file. 
> */
> -base_bs = backing_bs(bs);
> +base_bs = bdrv_backing_chain_next(bs);
>   if (!base_bs) {
>   error_setg(&local_err, "Image does not have a backing file");
>   goto done;
> @@ -1632,18 +1632,20 @@ static int convert_iteration_sectors(ImgConvertState 
> *s, int64_t sector_num)
>   if (s->sector_next_status <= sector_num) {
>   uint64_t offset = (sector_num - src_cur_offset) * BDRV_SECTOR_SIZE;
>   int64_t count;
> +BlockDriverState *src_bs = blk_bs(s->src[src_cur]);
> +BlockDriverState *base;
> +
> +if (s->target_has_backing) {
> +base = bdrv_filtered_cow_bs(bdrv_skip_rw_filters(src_bs));
> +} else {
> +base = NULL;
> +}
>   
>   do {
>   count = n * BDRV_SECTOR_SIZE;
>   
> -if (s->target_has_backing) {
> -ret = bdrv_block_status(blk_bs(s->src[src_cur]), offset,
> -count, &count, NULL, NULL);
> -} else {
> -ret = bdrv_block_status_above(blk_bs(s->src[src_cur]), NULL,
> -  offset, count, &count, NULL,
> -  NULL);
> -}
> +ret = bdrv_block_status_above(src_bs, base, offset, count, 
> &count,
> +  NULL, NULL);
>   
>   if (ret < 0) {
>   if (s->salvage) {
> @@ -2490,7 +2492,8 @@ static int img_convert(int argc, char **argv)
>* s.target_backing_sectors has to be negative, which it will
>* be automatically).  The backing file length is used only
>* for optimizations, so such a case is not fatal. */
> -s.target_backing_sectors = bdrv_nb_sectors(out_bs->backing->bs);
> +s.target_backing_sectors =
> +bdrv_nb_sectors(bdrv_filtered_cow_bs(out_bs));

bdrv_nb_sectors(bdrv_backing_chain_next(out_bs))

>   } else {
>   s.target_backing_sectors = -1;
>   }
> @@ -2853,6 +2856,7 @@ static int get_block_status(BlockDriverState *bs, 
> int64_t offset,
>   
>   depth = 0;
>   for (;;) {
> +bs = bdrv_skip_rw_filters(bs);
>   ret = bdrv_block_status(bs, offset, bytes, &bytes, &map, &file);
>   if (ret < 0) {
>   return ret;
> @@ -2861,7 +2865,7 @@ static int get_block_status(BlockDriverState *bs, 
> int64_t offset,
>   if (ret & (BDRV_BLOCK_ZERO|BDRV_BLOCK_DATA)) {
>   break;
>   }
> -bs = backing_bs(bs);
> +bs = bdrv_filtered_cow_bs(bs);
>   if (bs == NULL) {
>   ret = 0;
>   break;
> @@ -3216,6 +3220,7 @@ static int img_rebase(int argc, char **argv)
>   uint8_t *buf_old = NULL;
>   uint8_t *buf_new = NULL;
>   BlockDriverState *bs = NULL, *prefix_chain_bs = NULL;
> +BlockDriverState *unfiltered_bs;
>   char *filename;
>   const char *fmt, *cache, *src_cache, *out_basefmt, *out_baseimg;
>   int c, flags, src_flags, ret;
> @@ -3350,6 +3355,8 @@ static int img_rebase(int argc, char **argv)
>   }
>   bs = blk_bs(blk);
>   
> +unfiltered_bs = bdrv_skip_rw_filters(bs);
> +
>   if (out_basefmt != NULL) {
>   if (bdrv_find_format(out_basefmt) == NULL) {
>   error_report("Invalid format name: '%s'", out_basefmt);
> @@ -3361,7 +3368,7 @@ static int img_rebase(int argc, char **argv)
>   /* For safe rebasing we need to compare old and new backing file */
>   if (!unsafe) {
>   QDict *options = NULL;
> -BlockDriverState *base_bs = backing_bs(bs);
> +BlockDriverState *base_bs = bdrv_filtered_cow_bs(unfiltered_bs);
>   
>   if (base_bs) {
>   blk_old_backing = blk_new(qemu_get_aio_context(),
> @@ -3517,7 +3524,7 @@ static int img_rebase(int argc, char **argv)
>* If cluster wasn't changed since prefix_chain, we don't 
> need
>* to take action
>

[Qemu-devel] [PATCH v3] ppc: Add support for 'mffsl' instruction

[Paul A. Clarke]

From: "Paul A. Clarke" 

ISA 3.0B added a set of Floating-Point Status and Control Register (FPSCR)
instructions: mffsce, mffscdrn, mffscdrni, mffscrn, mffscrni, mffsl.
This patch adds support for 'mffsl'.

'mffsl' is identical to 'mffs', except it only returns mode, status, and enable
bits from the FPSCR.

On CPUs without support for 'mffsl' (below ISA 3.0), the 'mffsl' instruction
will execute identically to 'mffs'.

Note: I renamed FPSCR_RN to FPSCR_RN0 so I could create an FPSCR_RN mask which
is both bits of the FPSCR rounding mode, as defined in the ISA.

I also fixed a typo in the definition of FPSCR_FR.

Signed-off-by: Paul A. Clarke 

v3:
- Changed tcg_gen_and_i64 to tcg_gen_andi_i64, eliminating the need for a
  temporary, per review from Richard Henderson.

v2:
- I found that I copied too much of the 'mffs' implementation.
  The 'Rc' condition code bits are not needed for 'mffsl'.  Removed.
- I now free the (renamed) 'tmask' temporary.
- I now bail early for older ISA to the original 'mffs' implementation.

---
 disas/ppc.c|  5 +
 target/ppc/cpu.h   | 15 ++-
 target/ppc/fpu_helper.c|  4 ++--
 target/ppc/translate/fp-impl.inc.c | 21 +
 target/ppc/translate/fp-ops.inc.c  |  4 +++-
 5 files changed, 41 insertions(+), 8 deletions(-)

diff --git a/disas/ppc.c b/disas/ppc.c
index a545437..63e97cf 100644
--- a/disas/ppc.c
+++ b/disas/ppc.c
@@ -1765,6 +1765,9 @@ extract_tbr (unsigned long insn,
 /* An X_MASK with the RA and RB fields fixed.  */
 #define XRARB_MASK (X_MASK | RA_MASK | RB_MASK)
 
+/* An X form instruction with the RA field fixed.  */
+#define XRA(op, xop, ra) (X((op), (xop)) | (((ra) << 16) & XRA_MASK))
+
 /* An XRARB_MASK, but with the L bit clear.  */
 #define XRLARB_MASK (XRARB_MASK & ~((unsigned long) 1 << 16))
 
@@ -4998,6 +5001,8 @@ const struct powerpc_opcode powerpc_opcodes[] = {
 { "ddivq",   XRC(63,546,0), X_MASK,POWER6, { FRT, FRA, FRB } },
 { "ddivq.",  XRC(63,546,1), X_MASK,POWER6, { FRT, FRA, FRB } },
 
+{ "mffsl",   XRA(63,583,12), XRARB_MASK,   POWER9, { FRT } },
+
 { "mffs",XRC(63,583,0), XRARB_MASK,COM,{ FRT } },
 { "mffs.",   XRC(63,583,1), XRARB_MASK,COM,{ FRT } },
 
diff --git a/target/ppc/cpu.h b/target/ppc/cpu.h
index c9beba2..74e8da4 100644
--- a/target/ppc/cpu.h
+++ b/target/ppc/cpu.h
@@ -591,7 +591,7 @@ enum {
 #define FPSCR_XE 3  /* Floating-point inexact exception enable   */
 #define FPSCR_NI 2  /* Floating-point non-IEEE mode  */
 #define FPSCR_RN11
-#define FPSCR_RN 0  /* Floating-point rounding control   */
+#define FPSCR_RN00  /* Floating-point rounding control   */
 #define fpscr_fex(((env->fpscr) >> FPSCR_FEX)& 0x1)
 #define fpscr_vx (((env->fpscr) >> FPSCR_VX) & 0x1)
 #define fpscr_ox (((env->fpscr) >> FPSCR_OX) & 0x1)
@@ -614,7 +614,7 @@ enum {
 #define fpscr_ze (((env->fpscr) >> FPSCR_ZE) & 0x1)
 #define fpscr_xe (((env->fpscr) >> FPSCR_XE) & 0x1)
 #define fpscr_ni (((env->fpscr) >> FPSCR_NI) & 0x1)
-#define fpscr_rn (((env->fpscr) >> FPSCR_RN) & 0x3)
+#define fpscr_rn (((env->fpscr) >> FPSCR_RN0)& 0x3)
 /* Invalid operation exception summary */
 #define fpscr_ix ((env->fpscr) & ((1 << FPSCR_VXSNAN) | (1 << FPSCR_VXISI)  | \
   (1 << FPSCR_VXIDI)  | (1 << FPSCR_VXZDZ)  | \
@@ -640,7 +640,7 @@ enum {
 #define FP_VXZDZ(1ull << FPSCR_VXZDZ)
 #define FP_VXIMZ(1ull << FPSCR_VXIMZ)
 #define FP_VXVC (1ull << FPSCR_VXVC)
-#define FP_FR   (1ull << FSPCR_FR)
+#define FP_FR   (1ull << FPSCR_FR)
 #define FP_FI   (1ull << FPSCR_FI)
 #define FP_C(1ull << FPSCR_C)
 #define FP_FL   (1ull << FPSCR_FL)
@@ -648,7 +648,7 @@ enum {
 #define FP_FE   (1ull << FPSCR_FE)
 #define FP_FU   (1ull << FPSCR_FU)
 #define FP_FPCC (FP_FL | FP_FG | FP_FE | FP_FU)
-#define FP_FPRF (FP_C  | FP_FL | FP_FG | FP_FE | FP_FU)
+#define FP_FPRF (FP_C | FP_FPCC)
 #define FP_VXSOFT   (1ull << FPSCR_VXSOFT)
 #define FP_VXSQRT   (1ull << FPSCR_VXSQRT)
 #define FP_VXCVI(1ull << FPSCR_VXCVI)
@@ -659,7 +659,12 @@ enum {
 #define FP_XE   (1ull << FPSCR_XE)
 #define FP_NI   (1ull << FPSCR_NI)
 #define FP_RN1  (1ull << FPSCR_RN1)
-#define FP_RN   (1ull << FPSCR_RN)
+#define FP_RN0  (1ull << FPSCR_RN0)
+#define FP_RN   (FP_RN1 | FP_RN0)
+
+#define FP_MODE FP_RN
+#define FP_ENABLES  (FP_VE | FP_OE | FP_UE | FP_ZE | FP_XE)
+#define FP_STATUS   (FP_FR | FP_FI | FP_FPRF)
 
 /* the exception bits which can be cleared by mcrfs - includes FX */
 #define FP_EX_CLEAR_BITS (FP_FX | FP_OX | FP_UX | FP_ZX | \
diff --git a/target/ppc/fpu_helper.c b/target/ppc/fpu_helper.c
index f437c88..5

Re: [Qemu-devel] [PATCH 5/6] migration: add some multifd traces

[Dr. David Alan Gilbert]

* Juan Quintela (quint...@redhat.com) wrote:
> Signed-off-by: Juan Quintela 


Reviewed-by: Dr. David Alan Gilbert 

Queued
> ---
>  migration/ram.c| 3 +++
>  migration/trace-events | 4 
>  2 files changed, 7 insertions(+)
> 
> diff --git a/migration/ram.c b/migration/ram.c
> index f1aec95f83..25a211c3fb 100644
> --- a/migration/ram.c
> +++ b/migration/ram.c
> @@ -1173,6 +1173,7 @@ static void *multifd_send_thread(void *opaque)
>  
>  out:
>  if (local_err) {
> +trace_multifd_send_error(p->id);
>  multifd_send_terminate_threads(local_err);
>  }
>  
> @@ -1203,6 +1204,7 @@ static void multifd_new_send_channel_async(QIOTask 
> *task, gpointer opaque)
>  QIOChannel *sioc = QIO_CHANNEL(qio_task_get_source(task));
>  Error *local_err = NULL;
>  
> +trace_multifd_new_send_channel_async(p->id);
>  if (qio_task_propagate_error(task, &local_err)) {
>  migrate_set_error(migrate_get_current(), local_err);
>  multifd_save_cleanup();
> @@ -1496,6 +1498,7 @@ bool multifd_recv_new_channel(QIOChannel *ioc, Error 
> **errp)
>  atomic_read(&multifd_recv_state->count));
>  return false;
>  }
> +trace_multifd_recv_new_channel(id);
>  
>  p = &multifd_recv_state->params[id];
>  if (p->c != NULL) {
> diff --git a/migration/trace-events b/migration/trace-events
> index 9fbef614ab..5d85f8bf83 100644
> --- a/migration/trace-events
> +++ b/migration/trace-events
> @@ -81,7 +81,9 @@ migration_bitmap_sync_start(void) ""
>  migration_bitmap_sync_end(uint64_t dirty_pages) "dirty_pages %" PRIu64
>  migration_bitmap_clear_dirty(char *str, uint64_t start, uint64_t size, 
> unsigned long page) "rb %s start 0x%"PRIx64" size 0x%"PRIx64" page 0x%lx"
>  migration_throttle(void) ""
> +multifd_new_send_channel_async(uint8_t id) "channel %d"
>  multifd_recv(uint8_t id, uint64_t packet_num, uint32_t used, uint32_t flags, 
> uint32_t next_packet_size) "channel %d packet_num %" PRIu64 " pages %d flags 
> 0x%x next packet size %d"
> +multifd_recv_new_channel(uint8_t id) "channel %d"
>  multifd_recv_sync_main(long packet_num) "packet num %ld"
>  multifd_recv_sync_main_signal(uint8_t id) "channel %d"
>  multifd_recv_sync_main_wait(uint8_t id) "channel %d"
> @@ -89,7 +91,9 @@ multifd_recv_terminate_threads(bool error) "error %d"
>  multifd_recv_thread_can_start(uint8_t id) "channel %d"
>  multifd_recv_thread_end(uint8_t id, uint64_t packets, uint64_t pages) 
> "channel %d packets %" PRIu64 " pages %" PRIu64
>  multifd_recv_thread_start(uint8_t id) "%d"
> +multifd_save_setup_wait(uint8_t id) "%d"
>  multifd_send(uint8_t id, uint64_t packet_num, uint32_t used, uint32_t flags, 
> uint32_t next_packet_size) "channel %d packet_num %" PRIu64 " pages %d flags 
> 0x%x next packet size %d"
> +multifd_send_error(uint8_t id) "channel %d"
>  multifd_send_sync_main(long packet_num) "packet num %ld"
>  multifd_send_sync_main_signal(uint8_t id) "channel %d"
>  multifd_send_sync_main_wait(uint8_t id) "channel %d"
> -- 
> 2.21.0
> 
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

Re: [Qemu-devel] [PATCH v2 3/4] block/qcow2: refactor qcow2_co_pwritev_part

[Max Reitz]

On 30.07.19 16:18, Vladimir Sementsov-Ogievskiy wrote:
> Similarly to previous commit, prepare for parallelizing write-loop
> iterations.
> 
> Signed-off-by: Vladimir Sementsov-Ogievskiy 
> ---
>  block/qcow2.c | 150 +-
>  1 file changed, 88 insertions(+), 62 deletions(-)
> 
> diff --git a/block/qcow2.c b/block/qcow2.c
> index 7fa71968b2..37766b8b7c 100644
> --- a/block/qcow2.c
> +++ b/block/qcow2.c

[...]

> + * l2meta  - if not NULL, qcow2_co_do_pwritev() will consume it. Caller must 
> not
> + *   use it somehow after qcow2_co_pwritev_task() call

[...]

> +l2meta = NULL; /* l2meta is consumed by qcow2_co_do_pwritev() */

By the way, qcow2_co_do_pwritev() does not exist. :-)

Max



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v2 4/4] block/qcow2: introduce parallel subrequest handling in read and write

[Max Reitz]

On 30.07.19 16:18, Vladimir Sementsov-Ogievskiy wrote:
> It improves performance for fragmented qcow2 images.
> 
> Signed-off-by: Vladimir Sementsov-Ogievskiy 
> ---
>  block/qcow2.c  | 125 +
>  block/trace-events |   1 +
>  2 files changed, 115 insertions(+), 11 deletions(-)
> 
> diff --git a/block/qcow2.c b/block/qcow2.c
> index 37766b8b7c..5f0e66ea48 100644
> --- a/block/qcow2.c
> +++ b/block/qcow2.c

[...]

> @@ -2017,6 +2018,62 @@ fail:
>  return ret;
>  }
>  
> +typedef struct Qcow2AioTask {
> +AioTask task;
> +
> +BlockDriverState *bs;
> +QCow2ClusterType cluster_type; /* only for read */
> +uint64_t file_cluster_offset;
> +uint64_t offset;
> +uint64_t bytes;
> +QEMUIOVector *qiov;
> +uint64_t qiov_offset;
> +QCowL2Meta *l2meta; /* only for write */
> +} Qcow2AioTask;
> +
> +#define QCOW2_MAX_WORKERS 8

Maybe move this to the top, or even qcow2.h?

[...]

> @@ -2112,7 +2182,16 @@ static coroutine_fn int 
> qcow2_co_preadv_part(BlockDriverState *bs,
>  qiov_offset += cur_bytes;
>  }
>  
> -return 0;
> +out:
> +if (aio) {
> +aio_task_pool_wait_all(aio);
> +if (ret == 0) {
> +ret = aio_task_pool_status(aio);
> +}
> +g_free(aio);
> +}
> +
> +return ret;

My gcc complains here that ret may be initialized.  (Which is indeed the
case if @bytes is 0.)

The rest looks good to me.

Max



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v3] ppc: Add support for 'mffsl' instruction

[no-reply]

Patchew URL: 
https://patchew.org/QEMU/1565799261-498-1-git-send-email...@us.ibm.com/



Hi,

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

Subject: [Qemu-devel] [PATCH v3] ppc: Add support for 'mffsl' instruction
Message-id: 1565799261-498-1-git-send-email...@us.ibm.com
Type: series

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

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 * [new tag] patchew/1565799261-498-1-git-send-email...@us.ibm.com -> 
patchew/1565799261-498-1-git-send-email...@us.ibm.com
Submodule 'capstone' (https://git.qemu.org/git/capstone.git) registered for 
path 'capstone'
Submodule 'dtc' (https://git.qemu.org/git/dtc.git) registered for path 'dtc'
Submodule 'roms/QemuMacDrivers' (https://git.qemu.org/git/QemuMacDrivers.git) 
registered for path 'roms/QemuMacDrivers'
Submodule 'roms/SLOF' (https://git.qemu.org/git/SLOF.git) registered for path 
'roms/SLOF'
Submodule 'roms/edk2' (https://git.qemu.org/git/edk2.git) registered for path 
'roms/edk2'
Submodule 'roms/ipxe' (https://git.qemu.org/git/ipxe.git) registered for path 
'roms/ipxe'
Submodule 'roms/openbios' (https://git.qemu.org/git/openbios.git) registered 
for path 'roms/openbios'
Submodule 'roms/openhackware' (https://git.qemu.org/git/openhackware.git) 
registered for path 'roms/openhackware'
Submodule 'roms/opensbi' (https://git.qemu.org/git/opensbi.git) registered for 
path 'roms/opensbi'
Submodule 'roms/qemu-palcode' (https://git.qemu.org/git/qemu-palcode.git) 
registered for path 'roms/qemu-palcode'
Submodule 'roms/seabios' (https://git.qemu.org/git/seabios.git/) registered for 
path 'roms/seabios'
Submodule 'roms/seabios-hppa' (https://git.qemu.org/git/seabios-hppa.git) 
registered for path 'roms/seabios-hppa'
Submodule 'roms/sgabios' (https://git.qemu.org/git/sgabios.git) registered for 
path 'roms/sgabios'
Submodule 'roms/skiboot' (https://git.qemu.org/git/skiboot.git) registered for 
path 'roms/skiboot'
Submodule 'roms/u-boot' (https://git.qemu.org/git/u-boot.git) registered for 
path 'roms/u-boot'
Submodule 'roms/u-boot-sam460ex' (https://git.qemu.org/git/u-boot-sam460ex.git) 
registered for path 'roms/u-boot-sam460ex'
Submodule 'slirp' (https://git.qemu.org/git/libslirp.git) registered for path 
'slirp'
Submodule 'tests/fp/berkeley-softfloat-3' 
(https://git.qemu.org/git/berkeley-softfloat-3.git) registered for path 
'tests/fp/berkeley-softfloat-3'
Submodule 'tests/fp/berkeley-testfloat-3' 
(https://git.qemu.org/git/berkeley-testfloat-3.git) registered for path 
'tests/fp/berkeley-testfloat-3'
Submodule 'ui/keycodemapdb' (https://git.qemu.org/git/keycodemapdb.git) 
registered for path 'ui/keycodemapdb'
Cloning into 'capstone'...
Submodule path 'capstone': checked out 
'22ead3e0bfdb87516656453336160e0a37b066bf'
Cloning into 'dtc'...
Submodule path 'dtc': checked out '88f18909db731a627456f26d779445f84e449536'
Cloning into 'roms/QemuMacDrivers'...
Submodule path 'roms/QemuMacDrivers': checked out 
'90c488d5f4a407342247b9ea869df1c2d9c8e266'
Cloning into 'roms/SLOF'...
Submodule path 'roms/SLOF': checked out 
'ba1ab360eebe6338bb8d7d83a9220ccf7e213af3'
Cloning into 'roms/edk2'...
Submodule path 'roms/edk2': checked out 
'20d2e5a125e34fc8501026613a71549b2a1a3e54'
Submodule 'SoftFloat' (https://github.com/ucb-bar/berkeley-softfloat-3.git) 
registered for path 'ArmPkg/Library/ArmSoftFloatLib/berkeley-softfloat-3'
Submodule 'CryptoPkg/Library/OpensslLib/openssl' 
(https://github.com/openssl/openssl) registered for path 
'CryptoPkg/Library/OpensslLib/openssl'
Cloning into 'ArmPkg/Library/ArmSoftFloatLib/berkeley-softfloat-3'...
Submodule path 'roms/edk2/ArmPkg/Library/ArmSoftFloatLib/berkeley-softfloat-3': 
checked out 'b64af41c3276f97f0e181920400ee056b9c88037'
Cloning into 'CryptoPkg/Library/OpensslLib/openssl'...
Submodule path 'roms/edk2/CryptoPkg/Library/OpensslLib/openssl': checked out 
'50eaac9f3337667259de725451f201e784599687'
Submodule 'boringssl' (https://boringssl.googlesource.com/boringssl) registered 
for path 'boringssl'
Submodule 'krb5' (https://github.com/krb5/krb5) registered for path 'krb5'
Submodule 'pyca.cryptography' (https://github.com/pyca/cryptography.git) 
registered for path 'pyca-cryptography'
Cloning into 'boringssl'...
Submodule path 'roms/edk2/CryptoPkg/Library/OpensslLib/openssl/boringssl': 
checked out '2070f8ad9151dc8f3a73bffaa146b5e6937a583f'
Cloning into 'krb5'...
Submodule path 'roms/edk2/CryptoPkg/Library/OpensslLib/openssl/krb5': checked 
out 'b9ad6c49505c96a088326b62a52568e3484f2168'
Cloning into 'pyca-cryptography'...
Submodule path 
'roms/edk2/CryptoPkg/Library/OpensslLib/openssl/pyca-cryptography': checked out 
'09403100de2f6f1cdd0d484dcb8e620f1c335c8f'
Cloning into 'roms/ipxe'

Re: [Qemu-devel] [PATCH v3] ppc: Add support for 'mffsl' instruction

[Paul Clarke]

Should these 'checkpatch' ERRORs be addressed, even if it will diverge the code 
style from the existing, surrounding code?

On 8/14/19 11:30 AM, no-re...@patchew.org wrote:
> This series seems to have some coding style problems. See output below for
> more information:

> === OUTPUT BEGIN ===
> ERROR: code indent should never use tabs
> #54: FILE: disas/ppc.c:5004:
> +{ "mffsl",   XRA(63,583,12), XRARB_MASK,^IPOWER9,^I{ FRT } },$
> 
> ERROR: space required after that ',' (ctx:VxV)
> #54: FILE: disas/ppc.c:5004:
> +{ "mffsl",   XRA(63,583,12), XRARB_MASK,   POWER9, { FRT } },
> ^
> 
> ERROR: space required after that ',' (ctx:VxV)
> #54: FILE: disas/ppc.c:5004:
> +{ "mffsl",   XRA(63,583,12), XRARB_MASK,   POWER9, { FRT } },
> ^
> 
> ERROR: braces {} are necessary for all arms of this statement
> #148: FILE: target/ppc/translate/fp-impl.inc.c:625:
> +if (unlikely(!(ctx->insns_flags2 & PPC2_ISA300)))
> [...]
> 
> total: 4 errors, 0 warnings, 115 lines checked
> 
> Commit c51c0f894525 (ppc: Add support for 'mffsl' instruction) has style 
> problems, please review.  If any of these errors
> are false positives report them to the maintainer, see
> CHECKPATCH in MAINTAINERS.
> === OUTPUT END ===

PC

Re: [Qemu-devel] [PATCH v3 13/14] migration/ram: add support to send encrypted pages

[Dr. David Alan Gilbert]

* Singh, Brijesh (brijesh.si...@amd.com) wrote:
> When memory encryption is enabled, the guest memory will be encrypted with
> the guest specific key. The patch introduces RAM_SAVE_FLAG_ENCRYPTED_PAGE
> flag to distinguish the encrypted data from plaintext. Encrypted pages
> may need special handling. The kvm_memcrypt_save_outgoing_page() is used
> by the sender to write the encrypted pages onto the socket, similarly the
> kvm_memcrypt_load_incoming_page() is used by the target to read the
> encrypted pages from the socket and load into the guest memory.
> 
> Signed-off-by: Brijesh Singh 

Reviewed-by: Dr. David Alan Gilbert 

> ---
>  migration/ram.c | 131 +++-
>  1 file changed, 130 insertions(+), 1 deletion(-)
> 
> diff --git a/migration/ram.c b/migration/ram.c
> index 57c707525b..100a5a10cd 100644
> --- a/migration/ram.c
> +++ b/migration/ram.c
> @@ -59,6 +59,9 @@
>  #include "qemu/iov.h"
>  #include "hw/boards.h"
>  
> +/* Defines RAM_SAVE_ENCRYPTED_PAGE and  RAM_SAVE_ENCRYPTED_BITMAP */
> +#include "sysemu/sev.h"
> +
>  /***/
>  /* ram save/restore */
>  
> @@ -77,6 +80,7 @@
>  #define RAM_SAVE_FLAG_XBZRLE   0x40
>  /* 0x80 is reserved in migration.h start with 0x100 next */
>  #define RAM_SAVE_FLAG_COMPRESS_PAGE0x100
> +#define RAM_SAVE_FLAG_ENCRYPTED_DATA   0x200
>  
>  static inline bool is_zero_range(uint8_t *p, uint64_t size)
>  {
> @@ -460,6 +464,9 @@ static QemuCond decomp_done_cond;
>  
>  static bool do_compress_ram_page(QEMUFile *f, z_stream *stream, RAMBlock 
> *block,
>   ram_addr_t offset, uint8_t *source_buf);
> +static int ram_save_encrypted_page(RAMState *rs, PageSearchStatus *pss,
> +   bool last_stage);
> +
>  
>  static void *do_data_compress(void *opaque)
>  {
> @@ -2039,6 +2046,73 @@ static int save_normal_page(RAMState *rs, RAMBlock 
> *block, ram_addr_t offset,
>  return 1;
>  }
>  
> +/**
> + * ram_save_encrypted_page - send the given encrypted page to the stream
> + */
> +static int ram_save_encrypted_page(RAMState *rs, PageSearchStatus *pss,
> +   bool last_stage)
> +{
> +int ret;
> +uint8_t *p;
> +RAMBlock *block = pss->block;
> +ram_addr_t offset = pss->page << TARGET_PAGE_BITS;
> +uint64_t bytes_xmit;
> +MachineState *ms = MACHINE(qdev_get_machine());
> +MachineClass *mc = MACHINE_GET_CLASS(ms);
> +struct MachineMemoryEncryptionOps *ops = mc->memory_encryption_ops;
> +
> +p = block->host + offset;
> +
> +ram_counters.transferred +=
> +save_page_header(rs, rs->f, block,
> +offset | RAM_SAVE_FLAG_ENCRYPTED_DATA);
> +
> +qemu_put_be32(rs->f, RAM_SAVE_ENCRYPTED_PAGE);
> +ret = ops->save_outgoing_page(rs->f, p, TARGET_PAGE_SIZE, &bytes_xmit);
> +if (ret) {
> +return -1;
> +}
> +
> +ram_counters.transferred += bytes_xmit;
> +ram_counters.normal++;
> +
> +return 1;
> +}
> +
> +/**
> + * ram_save_encrypted_bitmap: send the encrypted page state bitmap
> + */
> +static int ram_save_encrypted_bitmap(RAMState *rs, QEMUFile *f)
> +{
> +MachineState *ms = MACHINE(qdev_get_machine());
> +MachineClass *mc = MACHINE_GET_CLASS(ms);
> +struct MachineMemoryEncryptionOps *ops = mc->memory_encryption_ops;
> +
> +save_page_header(rs, rs->f, rs->last_seen_block,
> + RAM_SAVE_FLAG_ENCRYPTED_DATA);
> +qemu_put_be32(rs->f, RAM_SAVE_ENCRYPTED_BITMAP);
> +return ops->save_outgoing_bitmap(rs->f);
> +}
> +
> +static int load_encrypted_data(QEMUFile *f, uint8_t *ptr)
> +{
> +MachineState *ms = MACHINE(qdev_get_machine());
> +MachineClass *mc = MACHINE_GET_CLASS(ms);
> +struct MachineMemoryEncryptionOps *ops = mc->memory_encryption_ops;
> +int flag;
> +
> +flag = qemu_get_be32(f);
> +
> +if (flag == RAM_SAVE_ENCRYPTED_PAGE) {
> +return ops->load_incoming_page(f, ptr);
> +} else if (flag == RAM_SAVE_ENCRYPTED_BITMAP) {
> +return ops->load_incoming_bitmap(f);
> +} else {
> +error_report("unknown encrypted flag %x", flag);
> +return 1;
> +}
> +}
> +
>  /**
>   * ram_save_page: send the given page to the stream
>   *
> @@ -2528,6 +2602,22 @@ static bool save_compress_page(RAMState *rs, RAMBlock 
> *block, ram_addr_t offset)
>  return false;
>  }
>  
> +/**
> + * encrypted_test_bitmap: check if the page is encrypted
> + *
> + * Returns a bool indicating whether the page is encrypted.
> + */
> +static bool encrypted_test_bitmap(RAMState *rs, RAMBlock *block,
> +  unsigned long page)
> +{
> +/* ROM devices contains the unencrypted data */
> +if (memory_region_is_rom(block->mr)) {
> +return false;
> +}
> +
> +return test_bit(page, block->encbmap);
> +}
> +
>  /**
>   * ram_save_target_page: save one target page
>   *
> @@ -2548,6 +2638,17 @@

Re: [Qemu-devel] [PATCH 0/4] configure: Fix libssh on Ubuntu 18.04

[no-reply]

Patchew URL: https://patchew.org/QEMU/20190814121527.17876-1-phi...@redhat.com/



Hi,

This series failed the asan build test. Please find the testing commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.

=== TEST SCRIPT BEGIN ===
#!/bin/bash
make docker-image-fedora V=1 NETWORK=1
time make docker-test-debug@fedora TARGET_LIST=x86_64-softmmu J=14 NETWORK=1
=== TEST SCRIPT END ===

Configure options:
--enable-werror --target-list=x86_64-softmmu --prefix=/tmp/qemu-test/install 
--python=/usr/bin/python3 --enable-debug --enable-sanitizers --cxx=clang++ 
--cc=clang --host-cc=clang

ERROR: configure test passed without -Werror but failed with -Werror.
   This is probably a bug in the configure script. The failing command
   will be at the bottom of config.log.
   You can run configure with --disable-werror to bypass this check.
---
funcs: do_compiler do_cc compile_object check_define main
lines: 92 122 627 696 0
clang -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE 
-Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings 
-Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -std=gnu99 -c -o 
config-temp/qemu-conf.o config-temp/qemu-conf.c
config-temp/qemu-conf.c:2:2: error: __i386__ not defined
#error __i386__ not defined
 ^
1 error generated.
---
funcs: do_compiler do_cc compile_object check_define main
lines: 92 122 627 699 0
clang -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE 
-Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings 
-Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -std=gnu99 -c -o 
config-temp/qemu-conf.o config-temp/qemu-conf.c
config-temp/qemu-conf.c:2:2: error: __ILP32__ not defined
#error __ILP32__ not defined
 ^
1 error generated.
---
funcs: do_compiler do_cc compile_prog cc_has_warning_flag main
lines: 92 128 1958 1962 0
clang -m64 -mcx16 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE 
-Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings 
-Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -std=gnu99 
-Wno-string-plus-int -Wno-typedef-redefinition -Wno-initializer-overrides 
-Wexpansion-to-defined -Wendif-labels -Wno-shift-negative-value 
-Wno-missing-include-dirs -Wempty-body -Wnested-externs -Wformat-security 
-Wformat-y2k -Winit-self -Wignored-qualifiers -Werror -Wold-style-declaration 
-o config-temp/qemu-conf.exe config-temp/qemu-conf.c -m64 -g
error: unknown warning option '-Wold-style-declaration'; did you mean 
'-Wout-of-line-declaration'? [-Werror,-Wunknown-warning-option]

funcs: do_compiler do_cc compile_prog cc_has_warning_flag main
lines: 92 128 1958 1962 0
---
funcs: do_compiler do_cc compile_prog main
lines: 92 128 2400 0
clang -fPIE -DPIE -m64 -mcx16 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 
-D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef 
-Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv 
-std=gnu99 -Wno-string-plus-int -Wno-typedef-redefinition 
-Wno-initializer-overrides -Wexpansion-to-defined -Wendif-labels 
-Wno-shift-negative-value -Wno-missing-include-dirs -Wempty-body 
-Wnested-externs -Wformat-security -Wformat-y2k -Winit-self 
-Wignored-qualifiers -Wold-style-definition -Wtype-limits 
-fstack-protector-strong -o config-temp/qemu-conf.exe config-temp/qemu-conf.c 
-Wl,-z,relro -Wl,-z,now -pie -m64 -g -llzfse
config-temp/qemu-conf.c:1:10: fatal error: 'lzfse.h' file not found
#include 
 ^
1 error generated.
---
funcs: do_compiler do_cc compile_prog main
lines: 92 128 2981 0
clang -fPIE -DPIE -m64 -mcx16 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 
-D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef 
-Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv 
-std=gnu99 -Wno-string-plus-int -Wno-typedef-redefinition 
-Wno-initializer-overrides -Wexpansion-to-defined -Wendif-labels 
-Wno-shift-negative-value -Wno-missing-include-dirs -Wempty-body 
-Wnested-externs -Wformat-security -Wformat-y2k -Winit-self 
-Wignored-qualifiers -Wold-style-definition -Wtype-limits 
-fstack-protector-strong -I/usr/include/p11-kit-1 -o config-temp/qemu-conf.exe 
config-temp/qemu-conf.c -Wl,-z,relro -Wl,-z,now -pie -m64 -g -lpam
config-temp/qemu-conf.c:1:10: fatal error: 'security/pam_appl.h' file not found
#include 
 ^
1 error generated.
---
funcs: do_compiler do_cc compile_prog main
lines: 92 128 3313 0
clang -fPIE -DPIE -m64 -mcx16 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 
-D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef 
-Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv 
-std=gnu99 -Wno-string-plus-int -Wno-typedef-redefinition 
-Wno-initializer-overrides -Wexpansion-to-defined -Wendif-labels 
-Wno-shift-negative-value -Wno-missing-include-dirs -Wempty-body 
-Wnested-externs -Wformat-security -Wformat-y2k -Winit-self 
-Wignored-qualifiers -Wold-style-de

Re: [Qemu-devel] [PATCH 0/4] backup: fix skipping unallocated clusters

[Vladimir Sementsov-Ogievskiy]

14 авг. 2019 г. 17:43 пользователь Vladimir Sementsov-Ogievskiy 
 написал:

Hi all!

There is a bug in not yet merged patch
"block/backup: teach TOP to never copy unallocated regions"
in https://github.com/jnsnow/qemu bitmaps. 04 fixes it. So, I propose
to put 01-03 somewhere before
"block/backup: teach TOP to never copy unallocated regions"
and squash 04 into "block/backup: teach TOP to never copy unallocated regions"

Hmm, don't bother with it. Simpler is fix the bug in your commit by just use 
skip_bytes variable when initializing dirty_end.


Based-on: https://github.com/jnsnow/qemu bitmaps

Vladimir Sementsov-Ogievskiy (4):
  block/dirty-bitmap: switch _next_dirty_area and _next_zero to int64_t
  block/dirty-bitmap: add _next_dirty API
  block/backup: use bdrv_dirty_bitmap_next_dirty
  block/backup: fix and improve skipping unallocated in backup_do_cow

include/block/dirty-bitmap.h |  8 ++--
include/qemu/hbitmap.h   | 18 +++--
block/backup.c   | 33 ++---
block/dirty-bitmap.c | 12 --
block/mirror.c   |  4 +-
tests/test-hbitmap.c | 32 
util/hbitmap.c   | 72 
block/trace-events   |  1 -
8 files changed, 107 insertions(+), 73 deletions(-)

--
2.18.0