[PATCH v2] target/ppc: Fix the test raising the decrementer exception

[Cédric Le Goater]

Commit 4d9b8ef9b5ab ("target/ppc: Fix 64-bit decrementer") introduced
new int64t variables and broke the test triggering the decrementer
exception. Revert partially the change to evaluate both clause of the
if statement.

Reported-by: Coverity CID 1464061
Fixes: 4d9b8ef9b5ab ("target/ppc: Fix 64-bit decrementer")
Suggested-by: Peter Maydell 
Signed-off-by: Cédric Le Goater 
---
 hw/ppc/ppc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/ppc/ppc.c b/hw/ppc/ppc.c
index f5d012f860af..a724b0bb5ecb 100644
--- a/hw/ppc/ppc.c
+++ b/hw/ppc/ppc.c
@@ -848,7 +848,7 @@ static void __cpu_ppc_store_decr(PowerPCCPU *cpu, uint64_t 
*nextp,
  * On MSB edge based DEC implementations the MSB going from 0 -> 1 triggers
  * an edge interrupt, so raise it here too.
  */
-if ((signed_value < 3) ||
+if ((value < 3) ||
 ((tb_env->flags & PPC_DECR_UNDERFLOW_LEVEL) && signed_value < 0) ||
 ((tb_env->flags & PPC_DECR_UNDERFLOW_TRIGGERED) && signed_value < 0
   && signed_decr >= 0)) {
-- 
2.31.1

Re: [PATCH v2 1/2] hw/adc: Add basic Aspeed ADC model

[Peter Delevoryas]

> On Oct 4, 2021, at 12:49 AM, Cédric Le Goater  wrote:
> 
> On 10/3/21 21:18, p...@fb.com wrote:
>> From: Andrew Jeffery 
>> This model implements enough behaviour to do basic functionality tests
>> such as device initialisation and read out of dummy sample values. The
>> sample value generation strategy is similar to the STM ADC already in
>> the tree.
>> Signed-off-by: Andrew Jeffery 
>> [clg : support for multiple engines (AST2600) ]
>> Signed-off-by: Cédric Le Goater 
>> [pdel : refactored engine register struct fields to regs[] array field]
>> [pdel : added guest-error checking for upper-8 channel regs in AST2600]
>> Signed-off-by: Peter Delevoryas 
> 
> Reviewed-by: Cédric Le Goater 
> 
> Thanks,
> 
> C.

Hey Cedric,

Actually, I have just submitted a v3 of this patch series to support 16-bit
reads of the channel data registers. I don’t think I tested using the driver
to read from the ADC, and that’s what Patrick found crashed with these
changes. Since it’s relatively easy to enable 16-bit reads, I figured
I would just include that.

Thanks,
Peter

> 
> 
>> ---
>>  hw/adc/aspeed_adc.c | 422 
>>  hw/adc/meson.build  |   1 +
>>  hw/adc/trace-events |   3 +
>>  include/hw/adc/aspeed_adc.h |  55 +
>>  4 files changed, 481 insertions(+)
>>  create mode 100644 hw/adc/aspeed_adc.c
>>  create mode 100644 include/hw/adc/aspeed_adc.h
>> diff --git a/hw/adc/aspeed_adc.c b/hw/adc/aspeed_adc.c
>> new file mode 100644
>> index 00..fcd93d6853
>> --- /dev/null
>> +++ b/hw/adc/aspeed_adc.c
>> @@ -0,0 +1,422 @@
>> +/*
>> + * Aspeed ADC
>> + *
>> + * Copyright 2017-2021 IBM Corp.
>> + *
>> + * Andrew Jeffery 
>> + *
>> + * SPDX-License-Identifier: GPL-2.0-or-later
>> + */
>> +
>> +#include "qemu/osdep.h"
>> +#include "qapi/error.h"
>> +#include "qemu/log.h"
>> +#include "hw/irq.h"
>> +#include "hw/qdev-properties.h"
>> +#include "migration/vmstate.h"
>> +#include "hw/adc/aspeed_adc.h"
>> +#include "trace.h"
>> +
>> +#define ASPEED_ADC_MEMORY_REGION_SIZE   0x1000
>> +#define ASPEED_ADC_ENGINE_MEMORY_REGION_SIZE0x100
>> +#define  ASPEED_ADC_ENGINE_CH_EN_MASK   0x
>> +#define   ASPEED_ADC_ENGINE_CH_EN(x)((BIT(x)) << 16)
>> +#define  ASPEED_ADC_ENGINE_INIT BIT(8)
>> +#define  ASPEED_ADC_ENGINE_AUTO_COMPBIT(5)
>> +#define  ASPEED_ADC_ENGINE_COMP BIT(4)
>> +#define  ASPEED_ADC_ENGINE_MODE_MASK0x000e
>> +#define   ASPEED_ADC_ENGINE_MODE_OFF(0b000 << 1)
>> +#define   ASPEED_ADC_ENGINE_MODE_STANDBY(0b001 << 1)
>> +#define   ASPEED_ADC_ENGINE_MODE_NORMAL (0b111 << 1)
>> +#define  ASPEED_ADC_ENGINE_EN   BIT(0)
>> +#define ASPEED_ADC_HYST_EN  BIT(31)
>> +
>> +#define ASPEED_ADC_L_MASK   ((1 << 10) - 1)
>> +#define ASPEED_ADC_L(x) ((x) & ASPEED_ADC_L_MASK)
>> +#define ASPEED_ADC_H(x) (((x) >> 16) & ASPEED_ADC_L_MASK)
>> +#define ASPEED_ADC_LH_MASK  (ASPEED_ADC_L_MASK << 16 | 
>> ASPEED_ADC_L_MASK)
>> +#define LOWER_CHANNEL_MASK  ((1 << 10) - 1)
>> +#define LOWER_CHANNEL_DATA(x)   ((x) & LOWER_CHANNEL_MASK)
>> +#define UPPER_CHANNEL_DATA(x)   (((x) >> 16) & LOWER_CHANNEL_MASK)
>> +
>> +#define TO_REG(addr) (addr >> 2)
>> +
>> +#define ENGINE_CONTROL  TO_REG(0x00)
>> +#define INTERRUPT_CONTROL   TO_REG(0x04)
>> +#define VGA_DETECT_CONTROL  TO_REG(0x08)
>> +#define CLOCK_CONTROL   TO_REG(0x0C)
>> +#define DATA_CHANNEL_1_AND_0TO_REG(0x10)
>> +#define DATA_CHANNEL_7_AND_6TO_REG(0x1C)
>> +#define DATA_CHANNEL_9_AND_8TO_REG(0x20)
>> +#define DATA_CHANNEL_15_AND_14  TO_REG(0x2C)
>> +#define BOUNDS_CHANNEL_0TO_REG(0x30)
>> +#define BOUNDS_CHANNEL_7TO_REG(0x4C)
>> +#define BOUNDS_CHANNEL_8TO_REG(0x50)
>> +#define BOUNDS_CHANNEL_15   TO_REG(0x6C)
>> +#define HYSTERESIS_CHANNEL_0TO_REG(0x70)
>> +#define HYSTERESIS_CHANNEL_7TO_REG(0x8C)
>> +#define HYSTERESIS_CHANNEL_8TO_REG(0x90)
>> +#define HYSTERESIS_CHANNEL_15   TO_REG(0xAC)
>> +#define INTERRUPT_SOURCETO_REG(0xC0)
>> +#define COMPENSATING_AND_TRIMMING   TO_REG(0xC4)
>> +
>> +static inline uint32_t update_channels(uint32_t current)
>> +{
>> +return current >> 16) & ASPEED_ADC_L_MASK) + 7) << 16) |
>> +((current + 5) & ASPEED_ADC_L_MASK);
>> +}
>> +
>> +static bool breaks_threshold(AspeedADCEngineState *s, int reg)
>> +{
>> +assert(reg >= DATA_CHANNEL_1_AND_0 &&
>> +   reg < DATA_CHANNEL_1_AND_0 + s->nr_channels / 2);
>> +
>> +int a_bounds_reg = BOUNDS_CHANNEL_0 + (reg - DATA_CHANNEL_1_AND_0) * 2;
>> +int b_bounds_reg = a_bounds_reg + 1;
>> +uint32_t a_and_b = s->regs[reg];
>> +uint32_t a_bounds = s->regs[a_bounds_reg];
>> +uint32_t b_bounds = s->regs[b_bounds_reg];
>> +uint32_t a = ASPEED_ADC_L(a_and_b);
>> +uint32_t b = 

[PATCH v3 1/2] hw/adc: Add basic Aspeed ADC model

[pdel]

From: Andrew Jeffery 

This model implements enough behaviour to do basic functionality tests
such as device initialisation and read out of dummy sample values. The
sample value generation strategy is similar to the STM ADC already in
the tree.

Signed-off-by: Andrew Jeffery 
[clg : support for multiple engines (AST2600) ]
Signed-off-by: Cédric Le Goater 
[pdel : refactored engine register struct fields to regs[] array field]
[pdel : added guest-error checking for upper-8 channel regs in AST2600]
[pdel : allow 16-bit reads of the channel data registers]
Signed-off-by: Peter Delevoryas 
---
 hw/adc/aspeed_adc.c | 427 
 hw/adc/meson.build  |   1 +
 hw/adc/trace-events |   3 +
 include/hw/adc/aspeed_adc.h |  55 +
 4 files changed, 486 insertions(+)
 create mode 100644 hw/adc/aspeed_adc.c
 create mode 100644 include/hw/adc/aspeed_adc.h

diff --git a/hw/adc/aspeed_adc.c b/hw/adc/aspeed_adc.c
new file mode 100644
index 00..c5fcae29f6
--- /dev/null
+++ b/hw/adc/aspeed_adc.c
@@ -0,0 +1,427 @@
+/*
+ * Aspeed ADC
+ *
+ * Copyright 2017-2021 IBM Corp.
+ *
+ * Andrew Jeffery 
+ *
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ */
+
+#include "qemu/osdep.h"
+#include "qapi/error.h"
+#include "qemu/log.h"
+#include "hw/irq.h"
+#include "hw/qdev-properties.h"
+#include "migration/vmstate.h"
+#include "hw/adc/aspeed_adc.h"
+#include "trace.h"
+
+#define ASPEED_ADC_MEMORY_REGION_SIZE   0x1000
+#define ASPEED_ADC_ENGINE_MEMORY_REGION_SIZE0x100
+#define  ASPEED_ADC_ENGINE_CH_EN_MASK   0x
+#define   ASPEED_ADC_ENGINE_CH_EN(x)((BIT(x)) << 16)
+#define  ASPEED_ADC_ENGINE_INIT BIT(8)
+#define  ASPEED_ADC_ENGINE_AUTO_COMPBIT(5)
+#define  ASPEED_ADC_ENGINE_COMP BIT(4)
+#define  ASPEED_ADC_ENGINE_MODE_MASK0x000e
+#define   ASPEED_ADC_ENGINE_MODE_OFF(0b000 << 1)
+#define   ASPEED_ADC_ENGINE_MODE_STANDBY(0b001 << 1)
+#define   ASPEED_ADC_ENGINE_MODE_NORMAL (0b111 << 1)
+#define  ASPEED_ADC_ENGINE_EN   BIT(0)
+#define ASPEED_ADC_HYST_EN  BIT(31)
+
+#define ASPEED_ADC_L_MASK   ((1 << 10) - 1)
+#define ASPEED_ADC_L(x) ((x) & ASPEED_ADC_L_MASK)
+#define ASPEED_ADC_H(x) (((x) >> 16) & ASPEED_ADC_L_MASK)
+#define ASPEED_ADC_LH_MASK  (ASPEED_ADC_L_MASK << 16 | ASPEED_ADC_L_MASK)
+#define LOWER_CHANNEL_MASK  ((1 << 10) - 1)
+#define LOWER_CHANNEL_DATA(x)   ((x) & LOWER_CHANNEL_MASK)
+#define UPPER_CHANNEL_DATA(x)   (((x) >> 16) & LOWER_CHANNEL_MASK)
+
+#define TO_REG(addr) (addr >> 2)
+
+#define ENGINE_CONTROL  TO_REG(0x00)
+#define INTERRUPT_CONTROL   TO_REG(0x04)
+#define VGA_DETECT_CONTROL  TO_REG(0x08)
+#define CLOCK_CONTROL   TO_REG(0x0C)
+#define DATA_CHANNEL_1_AND_0TO_REG(0x10)
+#define DATA_CHANNEL_7_AND_6TO_REG(0x1C)
+#define DATA_CHANNEL_9_AND_8TO_REG(0x20)
+#define DATA_CHANNEL_15_AND_14  TO_REG(0x2C)
+#define BOUNDS_CHANNEL_0TO_REG(0x30)
+#define BOUNDS_CHANNEL_7TO_REG(0x4C)
+#define BOUNDS_CHANNEL_8TO_REG(0x50)
+#define BOUNDS_CHANNEL_15   TO_REG(0x6C)
+#define HYSTERESIS_CHANNEL_0TO_REG(0x70)
+#define HYSTERESIS_CHANNEL_7TO_REG(0x8C)
+#define HYSTERESIS_CHANNEL_8TO_REG(0x90)
+#define HYSTERESIS_CHANNEL_15   TO_REG(0xAC)
+#define INTERRUPT_SOURCETO_REG(0xC0)
+#define COMPENSATING_AND_TRIMMING   TO_REG(0xC4)
+
+static inline uint32_t update_channels(uint32_t current)
+{
+return current >> 16) & ASPEED_ADC_L_MASK) + 7) << 16) |
+((current + 5) & ASPEED_ADC_L_MASK);
+}
+
+static bool breaks_threshold(AspeedADCEngineState *s, int reg)
+{
+assert(reg >= DATA_CHANNEL_1_AND_0 &&
+   reg < DATA_CHANNEL_1_AND_0 + s->nr_channels / 2);
+
+int a_bounds_reg = BOUNDS_CHANNEL_0 + (reg - DATA_CHANNEL_1_AND_0) * 2;
+int b_bounds_reg = a_bounds_reg + 1;
+uint32_t a_and_b = s->regs[reg];
+uint32_t a_bounds = s->regs[a_bounds_reg];
+uint32_t b_bounds = s->regs[b_bounds_reg];
+uint32_t a = ASPEED_ADC_L(a_and_b);
+uint32_t b = ASPEED_ADC_H(a_and_b);
+uint32_t a_lower = ASPEED_ADC_L(a_bounds);
+uint32_t a_upper = ASPEED_ADC_H(a_bounds);
+uint32_t b_lower = ASPEED_ADC_L(b_bounds);
+uint32_t b_upper = ASPEED_ADC_H(b_bounds);
+
+return (a < a_lower || a > a_upper) ||
+   (b < b_lower || b > b_upper);
+}
+
+static uint32_t read_channel_sample(AspeedADCEngineState *s, int reg)
+{
+assert(reg >= DATA_CHANNEL_1_AND_0 &&
+   reg < DATA_CHANNEL_1_AND_0 + s->nr_channels / 2);
+
+/* Poor man's sampling */
+uint32_t value = s->regs[reg];
+s->regs[reg] = update_channels(s->regs[reg]);
+
+if (breaks_threshold(s, reg)) {
+s->regs[INTERRUPT_CONTROL] |= BIT(reg - DATA_CHANNEL_1_AND_0);
+qemu_irq_raise(s->irq);
+}
+
+return 

[PATCH v3 0/2] hw/adc: Add basic Aspeed ADC model

[pdel]

From: Peter Delevoryas 

v1: https://lore.kernel.org/qemu-devel/20211002214414.2858382-1-p...@fbc.om/
v2: https://lore.kernel.org/qemu-devel/20211003191850.513658-1-p...@fb.com/
v3:
- Reduced the minimum access size to 2, to allow 16-bit reads
- Shifted the read value down 16 bits when reading an odd channel's
  data register.

So, v1 and v2 only attempted to support 32-bit reads and writes, but
Patrick was testing Witherspoon with my patches and revealed that the
upstream kernel driver (I was looking at 5.10 and 5.14) definitely
performs 16-bit reads of each channel, and that my patches crash
when that happens.

https://lore.kernel.org/openbmc/YVtJTrgm3b3W4PY9@heinlein/

  static int aspeed_adc_read_raw(struct iio_dev *indio_dev,
 struct iio_chan_spec const *chan,
 int *val, int *val2, long mask)
  {
  struct aspeed_adc_data *data = iio_priv(indio_dev);
  const struct aspeed_adc_model_data *model_data =
  of_device_get_match_data(data->dev);
  
  switch (mask) {
  case IIO_CHAN_INFO_RAW:
  if (!strcmp(model_data->model_name, "ast2600-adc")) {
  *val = readw(data->base + chan->address) + data->cv;
 ^
  }
  else {
  *val = readw(data->base + chan->address);
 ^
  }
  return IIO_VAL_INT;

I actually tested an image that uses this driver, but I wasn't testing
reads through the driver, I was just using the QEMU monitor, so it
didn't crash.

It's easy to at least relax the restrictions enough to allow the 16-bit
reads, and it's also not that hard to return the correct channel from
the channel data sampling. I didn't attempt to do anything special for
correctness of other registers, because I think we just perform 32-bit
reads and writes for them, and I didn't attempt to do the correct thing
for 16-bit writes to the data registers since that's not done by the
driver. (And I'm not sure the hardware supports that anyways?)

Thanks,
Peter

Andrew Jeffery (2):
  hw/adc: Add basic Aspeed ADC model
  hw/arm: Integrate ADC model into Aspeed SoC

 hw/adc/aspeed_adc.c | 427 
 hw/adc/meson.build  |   1 +
 hw/adc/trace-events |   3 +
 hw/arm/aspeed_ast2600.c |  11 +
 hw/arm/aspeed_soc.c |  11 +
 include/hw/adc/aspeed_adc.h |  55 +
 include/hw/arm/aspeed_soc.h |   2 +
 7 files changed, 510 insertions(+)
 create mode 100644 hw/adc/aspeed_adc.c
 create mode 100644 include/hw/adc/aspeed_adc.h

Interdiff against v2:
diff --git a/hw/adc/aspeed_adc.c b/hw/adc/aspeed_adc.c
index fcd93d6853..c5fcae29f6 100644
--- a/hw/adc/aspeed_adc.c
+++ b/hw/adc/aspeed_adc.c
@@ -148,6 +148,11 @@ static uint64_t aspeed_adc_engine_read(void *opaque, 
hwaddr addr,
 /* fallthrough */
 case DATA_CHANNEL_1_AND_0 ... DATA_CHANNEL_7_AND_6:
 value = read_channel_sample(s, reg);
+/* Allow 16-bit reads of the data registers */
+if (addr & 0x2) {
+assert(size == 2);
+value >>= 16;
+}
 break;
 default:
 qemu_log_mask(LOG_UNIMP, "%s: engine[%u]: 0x%" HWADDR_PRIx "\n",
@@ -234,7 +239,7 @@ static const MemoryRegionOps aspeed_adc_engine_ops = {
 .write = aspeed_adc_engine_write,
 .endianness = DEVICE_LITTLE_ENDIAN,
 .valid = {
-.min_access_size = 4,
+.min_access_size = 2,
 .max_access_size = 4,
 .unaligned = false,
 },
-- 
2.30.2

[PATCH v3 2/2] hw/arm: Integrate ADC model into Aspeed SoC

[pdel]

From: Andrew Jeffery 

Signed-off-by: Andrew Jeffery 
Signed-off-by: Cédric Le Goater 
Signed-off-by: Peter Delevoryas 
---
 hw/arm/aspeed_ast2600.c | 11 +++
 hw/arm/aspeed_soc.c | 11 +++
 include/hw/arm/aspeed_soc.h |  2 ++
 3 files changed, 24 insertions(+)

diff --git a/hw/arm/aspeed_ast2600.c b/hw/arm/aspeed_ast2600.c
index 9d70e8e060..d553ee2388 100644
--- a/hw/arm/aspeed_ast2600.c
+++ b/hw/arm/aspeed_ast2600.c
@@ -148,6 +148,9 @@ static void aspeed_soc_ast2600_init(Object *obj)
 snprintf(typename, sizeof(typename), "aspeed.timer-%s", socname);
 object_initialize_child(obj, "timerctrl", >timerctrl, typename);
 
+snprintf(typename, sizeof(typename), "aspeed.adc-%s", socname);
+object_initialize_child(obj, "adc", >adc, typename);
+
 snprintf(typename, sizeof(typename), "aspeed.i2c-%s", socname);
 object_initialize_child(obj, "i2c", >i2c, typename);
 
@@ -322,6 +325,14 @@ static void aspeed_soc_ast2600_realize(DeviceState *dev, 
Error **errp)
 sysbus_connect_irq(SYS_BUS_DEVICE(>timerctrl), i, irq);
 }
 
+/* ADC */
+if (!sysbus_realize(SYS_BUS_DEVICE(>adc), errp)) {
+return;
+}
+sysbus_mmio_map(SYS_BUS_DEVICE(>adc), 0, sc->memmap[ASPEED_DEV_ADC]);
+sysbus_connect_irq(SYS_BUS_DEVICE(>adc), 0,
+   aspeed_soc_get_irq(s, ASPEED_DEV_ADC));
+
 /* UART - attach an 8250 to the IO space as our UART */
 serial_mm_init(get_system_memory(), sc->memmap[s->uart_default], 2,
aspeed_soc_get_irq(s, s->uart_default), 38400,
diff --git a/hw/arm/aspeed_soc.c b/hw/arm/aspeed_soc.c
index ed84502e23..aaec2bba38 100644
--- a/hw/arm/aspeed_soc.c
+++ b/hw/arm/aspeed_soc.c
@@ -162,6 +162,9 @@ static void aspeed_soc_init(Object *obj)
 snprintf(typename, sizeof(typename), "aspeed.timer-%s", socname);
 object_initialize_child(obj, "timerctrl", >timerctrl, typename);
 
+snprintf(typename, sizeof(typename), "aspeed.adc-%s", socname);
+object_initialize_child(obj, "adc", >adc, typename);
+
 snprintf(typename, sizeof(typename), "aspeed.i2c-%s", socname);
 object_initialize_child(obj, "i2c", >i2c, typename);
 
@@ -287,6 +290,14 @@ static void aspeed_soc_realize(DeviceState *dev, Error 
**errp)
 sysbus_connect_irq(SYS_BUS_DEVICE(>timerctrl), i, irq);
 }
 
+/* ADC */
+if (!sysbus_realize(SYS_BUS_DEVICE(>adc), errp)) {
+return;
+}
+sysbus_mmio_map(SYS_BUS_DEVICE(>adc), 0, sc->memmap[ASPEED_DEV_ADC]);
+sysbus_connect_irq(SYS_BUS_DEVICE(>adc), 0,
+   aspeed_soc_get_irq(s, ASPEED_DEV_ADC));
+
 /* UART - attach an 8250 to the IO space as our UART */
 serial_mm_init(get_system_memory(), sc->memmap[s->uart_default], 2,
aspeed_soc_get_irq(s, s->uart_default), 38400,
diff --git a/include/hw/arm/aspeed_soc.h b/include/hw/arm/aspeed_soc.h
index 87d76c9259..8139358549 100644
--- a/include/hw/arm/aspeed_soc.h
+++ b/include/hw/arm/aspeed_soc.h
@@ -15,6 +15,7 @@
 #include "hw/cpu/a15mpcore.h"
 #include "hw/intc/aspeed_vic.h"
 #include "hw/misc/aspeed_scu.h"
+#include "hw/adc/aspeed_adc.h"
 #include "hw/misc/aspeed_sdmc.h"
 #include "hw/misc/aspeed_xdma.h"
 #include "hw/timer/aspeed_timer.h"
@@ -53,6 +54,7 @@ struct AspeedSoCState {
 AspeedSCUState scu;
 AspeedHACEState hace;
 AspeedXDMAState xdma;
+AspeedADCState adc;
 AspeedSMCState fmc;
 AspeedSMCState spi[ASPEED_SPIS_NUM];
 EHCISysBusState ehci[ASPEED_EHCIS_NUM];
-- 
2.30.2

Re: [PATCH] target/ppc: Fix test the decrementer exception

[Cédric Le Goater]

in Subject: s/test//

On 10/4/21 23:45, BALATON Zoltan wrote:

On Mon, 4 Oct 2021, Cédric Le Goater wrote:

Commit 4d9b8ef9b5ab ("target/ppc: Fix 64-bit decrementer") introduced
new int64t variables and broke the test triggering the decrementer
exception. Revert partially the change to evaluate both clause of the
if statement.

Fixes: Coverity CID 1464061


Shouldn't this be:

Reported-by: Coverity CID 1464061
Fixes: 4d9b8ef9b5ab ("target/ppc: Fix 64-bit decrementer")

or something similar?


I went through the commit logs before sending and that seemed to be
the latest practice.

Not an issue. I can resend.

C.



Regards,
BALATON Zoltan


Signed-off-by: Cédric Le Goater 
---
hw/ppc/ppc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/ppc/ppc.c b/hw/ppc/ppc.c
index f5d012f860af..a724b0bb5ecb 100644
--- a/hw/ppc/ppc.c
+++ b/hw/ppc/ppc.c
@@ -848,7 +848,7 @@ static void __cpu_ppc_store_decr(PowerPCCPU *cpu, uint64_t 
*nextp,
 * On MSB edge based DEC implementations the MSB going from 0 -> 1 triggers
 * an edge interrupt, so raise it here too.
 */
-    if ((signed_value < 3) ||
+    if ((value < 3) ||
    ((tb_env->flags & PPC_DECR_UNDERFLOW_LEVEL) && signed_value < 0) ||
    ((tb_env->flags & PPC_DECR_UNDERFLOW_TRIGGERED) && signed_value < 0
  && signed_decr >= 0)) {

Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms)

[Christophe Leroy]

Le 05/10/2021 à 02:48, David Gibson a écrit :

On Fri, Oct 01, 2021 at 04:18:49PM +0200, Thomas Huth wrote:

On 01/10/2021 15.04, Christophe Leroy wrote:



Le 01/10/2021 à 14:04, Thomas Huth a écrit :

On 01/10/2021 13.12, Peter Maydell wrote:

On Fri, 1 Oct 2021 at 10:43, Thomas Huth  wrote:

Nevertheless, as long as nobody has a hint where to find that
ppc405_rom.bin, I think both boards are pretty useless in QEMU (as far as I
can see, they do not work without the bios at all, so it's
also not possible
to use a Linux image with the "-kernel" CLI option directly).


It is at least in theory possible to run bare-metal code on
either board, by passing either a pflash or a bios argument.


True. I did some more research, and seems like there was once
support for those boards in u-boot, but it got removed there a
couple of years ago already:

https://gitlab.com/qemu-project/u-boot/-/commit/98f705c9cefdf

https://gitlab.com/qemu-project/u-boot/-/commit/b147ff2f37d5b

https://gitlab.com/qemu-project/u-boot/-/commit/7514037bcdc37


But I agree that there seem to be no signs of anybody actually
successfully using these boards for anything, so we should
deprecate-and-delete them.


Yes, let's mark them as deprecated now ... if someone still uses
them and speaks up, we can still revert the deprecation again.


I really would like to be able to use them to validate Linux Kernel
changes, hence looking for that missing BIOS.

If we remove ppc405 from QEMU, we won't be able to do any regression
tests of Linux Kernel on those processors.


If you/someone managed to compile an old version of u-boot for one of these
two boards, so that we would finally have something for regression testing,
we can of course also keep the boards in QEMU...


I can see that it would be usefor for some cases, but unless someone
volunteers to track down the necessary firmware and look after it, I
think we do need to deprecate it - I certainly don't have the capacity
to look into this.



I will look at it, please allow me a few weeks though.

Thanks
Christophe

Re: [PATCH v2 1/2] tcg: add dup_const_tl wrapper

[Richard Henderson]

On 10/3/21 2:42 PM, Philipp Tomsich wrote:

dup_const always generates a uint64_t, which may exceed the size of a
target_long (generating warnings with recent-enough compilers).

To ensure that we can use dup_const both for 64bit and 32bit targets,
this adds dup_const_tl, which either maps back to dup_const (for 64bit
targets) or provides a similar implementation using 32bit constants.

Signed-off-by: Philipp Tomsich

---

Changes in v2:
- Changed dup_const_tl to enforce the sanity check with
   qemu_build_not_reached as requested in the review.


Queueing this one patch through tcg-next.
I'll let Alistair take the other through riscv.

r~

Re: [PATCH 0/2] tests/docker: Fix fedora-i386-cross

[Richard Henderson]

On 9/30/21 9:36 AM, Richard Henderson wrote:

Richard Henderson (2):
   tests/docker: Remove fedora-i386-cross from DOCKER_PARTIAL_IMAGES
   tests/docker: Fix fedora-i386-cross


Queuing to tcg-next, just because I'm preparing a PR.


r~

Re: [PATCH] MAINTAINERS: Split HPPA TCG vs HPPA machines/hardware

[Richard Henderson]

On 10/4/21 1:38 AM, Philippe Mathieu-Daudé wrote:

Hardware emulated models don't belong to the TCG MAINTAINERS
section. Move them to the 'HP-PARISC Machines' section.

Signed-off-by: Philippe Mathieu-Daudé
---
  MAINTAINERS | 5 ++---
  1 file changed, 2 insertions(+), 3 deletions(-)


Reviewed-by: Richard Henderson 

r~

Re: [PULL 0/5] Trivial branch for 6.2 patches

[Richard Henderson]

On 10/4/21 1:30 AM, Laurent Vivier wrote:

The following changes since commit 30bd1db58b09c12b68c35f041f919014b885482d:

   Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into 
staging (2021-10-03 08:45:19 -0400)

are available in the Git repository at:

   git://github.com/vivier/qemu.git tags/trivial-branch-for-6.2-pull-request

for you to fetch changes up to daf0db06308b55c518312abc39a4bf74413ac007:

   hw/remote/proxy: Categorize Wireless devices as 'Network' ones (2021-10-04 
09:47:26 +0200)


Pull request trivial-patches 2021104


Applied, thanks.

r~

Re: [PATCH] spapr/xive: Add source status helpers

[David Gibson]

On Mon, Oct 04, 2021 at 11:21:41PM +0200, Cédric Le Goater wrote:
> and use them to set and test the ASSERTED bit of LSI sources.
> 
> Signed-off-by: Cédric Le Goater 

Applied to ppc-for-6.2, thanks.

> ---
>  include/hw/ppc/xive.h| 24 
>  hw/intc/spapr_xive.c |  2 +-
>  hw/intc/spapr_xive_kvm.c | 10 +++---
>  hw/intc/xive.c   |  8 
>  4 files changed, 32 insertions(+), 12 deletions(-)
> 
> diff --git a/include/hw/ppc/xive.h b/include/hw/ppc/xive.h
> index 252c58a1d691..b8ab0bf7490f 100644
> --- a/include/hw/ppc/xive.h
> +++ b/include/hw/ppc/xive.h
> @@ -286,6 +286,30 @@ uint8_t xive_esb_set(uint8_t *pq, uint8_t value);
>  uint8_t xive_source_esb_get(XiveSource *xsrc, uint32_t srcno);
>  uint8_t xive_source_esb_set(XiveSource *xsrc, uint32_t srcno, uint8_t pq);
>  
> +/*
> + * Source status helpers
> + */
> +static inline void xive_source_set_status(XiveSource *xsrc, uint32_t srcno,
> +  uint8_t status, bool enable)
> +{
> +if (enable) {
> +xsrc->status[srcno] |= status;
> +} else {
> +xsrc->status[srcno] &= ~status;
> +}
> +}
> +
> +static inline void xive_source_set_asserted(XiveSource *xsrc, uint32_t srcno,
> +bool enable)
> +{
> +xive_source_set_status(xsrc, srcno, XIVE_STATUS_ASSERTED, enable);
> +}
> +
> +static inline bool xive_source_is_asserted(XiveSource *xsrc, uint32_t srcno)
> +{
> +return xsrc->status[srcno] & XIVE_STATUS_ASSERTED;
> +}
> +
>  void xive_source_pic_print_info(XiveSource *xsrc, uint32_t offset,
>  Monitor *mon);
>  
> diff --git a/hw/intc/spapr_xive.c b/hw/intc/spapr_xive.c
> index 89cfa018f598..4ec659b93e13 100644
> --- a/hw/intc/spapr_xive.c
> +++ b/hw/intc/spapr_xive.c
> @@ -185,7 +185,7 @@ static void spapr_xive_pic_print_info(SpaprXive *xive, 
> Monitor *mon)
> xive_source_irq_is_lsi(xsrc, i) ? "LSI" : "MSI",
> pq & XIVE_ESB_VAL_P ? 'P' : '-',
> pq & XIVE_ESB_VAL_Q ? 'Q' : '-',
> -   xsrc->status[i] & XIVE_STATUS_ASSERTED ? 'A' : ' ',
> +   xive_source_is_asserted(xsrc, i) ? 'A' : ' ',
> xive_eas_is_masked(eas) ? "M" : " ",
> (int) xive_get_field64(EAS_END_DATA, eas->w));
>  
> diff --git a/hw/intc/spapr_xive_kvm.c b/hw/intc/spapr_xive_kvm.c
> index 6d4909d0a856..be94cff14837 100644
> --- a/hw/intc/spapr_xive_kvm.c
> +++ b/hw/intc/spapr_xive_kvm.c
> @@ -242,7 +242,7 @@ int kvmppc_xive_source_reset_one(XiveSource *xsrc, int 
> srcno, Error **errp)
>  
>  if (xive_source_irq_is_lsi(xsrc, srcno)) {
>  state |= KVM_XIVE_LEVEL_SENSITIVE;
> -if (xsrc->status[srcno] & XIVE_STATUS_ASSERTED) {
> +if (xive_source_is_asserted(xsrc, srcno)) {
>  state |= KVM_XIVE_LEVEL_ASSERTED;
>  }
>  }
> @@ -321,7 +321,7 @@ uint64_t kvmppc_xive_esb_rw(XiveSource *xsrc, int srcno, 
> uint32_t offset,
>  if (xive_source_irq_is_lsi(xsrc, srcno) &&
>  offset == XIVE_ESB_LOAD_EOI) {
>  xive_esb_read(xsrc, srcno, XIVE_ESB_SET_PQ_00);
> -if (xsrc->status[srcno] & XIVE_STATUS_ASSERTED) {
> +if (xive_source_is_asserted(xsrc, srcno)) {
>  kvmppc_xive_esb_trigger(xsrc, srcno);
>  }
>  return 0;
> @@ -359,11 +359,7 @@ void kvmppc_xive_source_set_irq(void *opaque, int srcno, 
> int val)
>  return;
>  }
>  } else {
> -if (val) {
> -xsrc->status[srcno] |= XIVE_STATUS_ASSERTED;
> -} else {
> -xsrc->status[srcno] &= ~XIVE_STATUS_ASSERTED;
> -}
> +xive_source_set_asserted(xsrc, srcno, val);
>  }
>  
>  kvmppc_xive_esb_trigger(xsrc, srcno);
> diff --git a/hw/intc/xive.c b/hw/intc/xive.c
> index 6c82326ec768..190194d27f84 100644
> --- a/hw/intc/xive.c
> +++ b/hw/intc/xive.c
> @@ -875,7 +875,7 @@ static bool xive_source_lsi_trigger(XiveSource *xsrc, 
> uint32_t srcno)
>  {
>  uint8_t old_pq = xive_source_esb_get(xsrc, srcno);
>  
> -xsrc->status[srcno] |= XIVE_STATUS_ASSERTED;
> +xive_source_set_asserted(xsrc, srcno, true);
>  
>  switch (old_pq) {
>  case XIVE_ESB_RESET:
> @@ -923,7 +923,7 @@ static bool xive_source_esb_eoi(XiveSource *xsrc, 
> uint32_t srcno)
>   * notification
>   */
>  if (xive_source_irq_is_lsi(xsrc, srcno) &&
> -xsrc->status[srcno] & XIVE_STATUS_ASSERTED) {
> +xive_source_is_asserted(xsrc, srcno)) {
>  ret = xive_source_lsi_trigger(xsrc, srcno);
>  }
>  
> @@ -1104,7 +1104,7 @@ void xive_source_set_irq(void *opaque, int srcno, int 
> val)
>  if (val) {
>  notify = xive_source_lsi_trigger(xsrc, srcno);
>  } else {
> -xsrc->status[srcno] &= ~XIVE_STATUS_ASSERTED;
> +xive_source_set_asserted(xsrc, srcno, false);
>  }
>  

Re: Deprecate the ppc405 boards in QEMU? (was: [PATCH v3 4/7] MAINTAINERS: Orphan obscure ppc platforms)

[David Gibson]

On Fri, Oct 01, 2021 at 04:18:49PM +0200, Thomas Huth wrote:
> On 01/10/2021 15.04, Christophe Leroy wrote:
> > 
> > 
> > Le 01/10/2021 à 14:04, Thomas Huth a écrit :
> > > On 01/10/2021 13.12, Peter Maydell wrote:
> > > > On Fri, 1 Oct 2021 at 10:43, Thomas Huth  wrote:
> > > > > Nevertheless, as long as nobody has a hint where to find that
> > > > > ppc405_rom.bin, I think both boards are pretty useless in QEMU (as 
> > > > > far as I
> > > > > can see, they do not work without the bios at all, so it's
> > > > > also not possible
> > > > > to use a Linux image with the "-kernel" CLI option directly).
> > > > 
> > > > It is at least in theory possible to run bare-metal code on
> > > > either board, by passing either a pflash or a bios argument.
> > > 
> > > True. I did some more research, and seems like there was once
> > > support for those boards in u-boot, but it got removed there a
> > > couple of years ago already:
> > > 
> > > https://gitlab.com/qemu-project/u-boot/-/commit/98f705c9cefdf
> > > 
> > > https://gitlab.com/qemu-project/u-boot/-/commit/b147ff2f37d5b
> > > 
> > > https://gitlab.com/qemu-project/u-boot/-/commit/7514037bcdc37
> > > 
> > > > But I agree that there seem to be no signs of anybody actually
> > > > successfully using these boards for anything, so we should
> > > > deprecate-and-delete them.
> > > 
> > > Yes, let's mark them as deprecated now ... if someone still uses
> > > them and speaks up, we can still revert the deprecation again.
> > 
> > I really would like to be able to use them to validate Linux Kernel
> > changes, hence looking for that missing BIOS.
> > 
> > If we remove ppc405 from QEMU, we won't be able to do any regression
> > tests of Linux Kernel on those processors.
> 
> If you/someone managed to compile an old version of u-boot for one of these
> two boards, so that we would finally have something for regression testing,
> we can of course also keep the boards in QEMU...

I can see that it would be usefor for some cases, but unless someone
volunteers to track down the necessary firmware and look after it, I
think we do need to deprecate it - I certainly don't have the capacity
to look into this.

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


signature.asc
Description: PGP signature

Re: [PATCH 1/2] target/ppc: Use tcg_constant_i32() in gen_setb()

[David Gibson]

On Sun, Oct 03, 2021 at 04:17:10PM +0200, Philippe Mathieu-Daudé wrote:
> Avoid using TCG temporaries for the -1 and 8 constant values.
> 
> Signed-off-by: Philippe Mathieu-Daudé 

Both patches applied to ppc-for-6.2, thanks.

> ---
>  target/ppc/translate.c | 8 ++--
>  1 file changed, 2 insertions(+), 6 deletions(-)
> 
> diff --git a/target/ppc/translate.c b/target/ppc/translate.c
> index b985e9e55bc..193d8e89152 100644
> --- a/target/ppc/translate.c
> +++ b/target/ppc/translate.c
> @@ -5074,19 +5074,15 @@ static void gen_mtspr(DisasContext *ctx)
>  static void gen_setb(DisasContext *ctx)
>  {
>  TCGv_i32 t0 = tcg_temp_new_i32();
> -TCGv_i32 t8 = tcg_temp_new_i32();
> -TCGv_i32 tm1 = tcg_temp_new_i32();
> +TCGv_i32 t8 = tcg_constant_i32(8);
> +TCGv_i32 tm1 = tcg_constant_i32(-1);
>  int crf = crfS(ctx->opcode);
>  
>  tcg_gen_setcondi_i32(TCG_COND_GEU, t0, cpu_crf[crf], 4);
> -tcg_gen_movi_i32(t8, 8);
> -tcg_gen_movi_i32(tm1, -1);
>  tcg_gen_movcond_i32(TCG_COND_GEU, t0, cpu_crf[crf], t8, tm1, t0);
>  tcg_gen_ext_i32_tl(cpu_gpr[rD(ctx->opcode)], t0);
>  
>  tcg_temp_free_i32(t0);
> -tcg_temp_free_i32(t8);
> -tcg_temp_free_i32(tm1);
>  }
>  #endif
>  

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


signature.asc
Description: PGP signature

Re: [PULL 00/26] Linux user for 6.2 patches

[Richard Henderson]

On 10/4/21 12:43 AM, Laurent Vivier wrote:

The following changes since commit bb4aa8f59e18412cff0d69f14aee7abba153161a:

   Merge remote-tracking branch 
'remotes/pmaydell/tags/pull-target-arm-20210930' into staging (2021-09-30 
21:16:54 +0100)

are available in the Git repository at:

   git://github.com/vivier/qemu.git tags/linux-user-for-6.2-pull-request

for you to fetch changes up to efee71c8ca181d4f5b2211736b38a74a2a223375:

   tests/tcg/multiarch: Re-enable signals test for most guests (2021-10-01 
12:03:48 +0200)


Pull request linux-user 20211004

Move signal trampolines to new page



Richard Henderson (26):
   linux-user: Add infrastructure for a signal trampoline page
   linux-user/aarch64: Implement setup_sigtramp
   linux-user/arm: Drop v1 signal frames
   linux-user/arm: Drop "_v2" from symbols in signal.c
   linux-user/arm: Implement setup_sigtramp
   linux-user/alpha: Implement setup_sigtramp
   linux-user/cris: Implement setup_sigtramp
   linux-user/hexagon: Implement setup_sigtramp
   linux-user/hppa: Document non-use of setup_sigtramp
   linux-user/i386: Implement setup_sigtramp
   linux-user/x86_64: Raise SIGSEGV if SA_RESTORER not set
   linux-user/m68k: Implement setup_sigtramp
   linux-user/microblaze: Implement setup_sigtramp
   linux-user/mips: Tidy install_sigtramp
   linux-user/mips: Implement setup_sigtramp
   linux-user/nios2: Document non-use of setup_sigtramp
   linux-user/openrisc: Implement setup_sigtramp
   linux-user/ppc: Simplify encode_trampoline
   linux-user/ppc: Implement setup_sigtramp
   linux-user/riscv: Implement setup_sigtramp
   linux-user/s390x: Implement setup_sigtramp
   linux-user/sh4: Implement setup_sigtramp
   linux-user/sparc: Implement setup_sigtramp
   linux-user/xtensa: Implement setup_sigtramp
   linux-user: Remove default for TARGET_ARCH_HAS_SIGTRAMP_PAGE
   tests/tcg/multiarch: Re-enable signals test for most guests


Applied, thanks.

r~

Re: [PATCH v0 0/2] virtio-blk and vhost-user-blk cross-device migration

[Roman Kagan]

On Mon, Oct 04, 2021 at 11:11:00AM -0400, Michael S. Tsirkin wrote:
> On Mon, Oct 04, 2021 at 06:07:29PM +0300, Denis Plotnikov wrote:
> > It might be useful for the cases when a slow block layer should be replaced
> > with a more performant one on running VM without stopping, i.e. with very 
> > low
> > downtime comparable with the one on migration.
> > 
> > It's possible to achive that for two reasons:
> > 
> > 1.The VMStates of "virtio-blk" and "vhost-user-blk" are almost the same.
> >   They consist of the identical VMSTATE_VIRTIO_DEVICE and differs from
> >   each other in the values of migration service fields only.
> > 2.The device driver used in the guest is the same: virtio-blk
> > 
> > In the series cross-migration is achieved by adding a new type.
> > The new type uses virtio-blk VMState instead of vhost-user-blk specific
> > VMstate, also it implements migration save/load callbacks to be compatible
> > with migration stream produced by "virtio-blk" device.
> > 
> > Adding the new type instead of modifying the existing one is convenent.
> > It ease to differ the new virtio-blk-compatible vhost-user-blk
> > device from the existing non-compatible one using qemu machinery without any
> > other modifiactions. That gives all the variety of qemu device related
> > constraints out of box.
> 
> Hmm I'm not sure I understand. What is the advantage for the user?
> What if vhost-user-blk became an alias for vhost-user-virtio-blk?
> We could add some hacks to make it compatible for old machine types.

The point is that virtio-blk and vhost-user-blk are not
migration-compatible ATM.  OTOH they are the same device from the guest
POV so there's nothing fundamentally preventing the migration between
the two.  In particular, we see it as a means to switch between the
storage backend transports via live migration without disrupting the
guest.

Migration-wise virtio-blk and vhost-user-blk have in common

- the content of the VMState -- VMSTATE_VIRTIO_DEVICE

The two differ in

- the name and the version of the VMStateDescription

- virtio-blk has an extra migration section (via .save/.load callbacks
  on VirtioDeviceClass) containing requests in flight

It looks like to become migration-compatible with virtio-blk,
vhost-user-blk has to start using VMStateDescription of virtio-blk and
provide compatible .save/.load callbacks.  It isn't entirely obvious how
to make this machine-type-dependent, so we came up with a simpler idea
of defining a new device that shares most of the implementation with the
original vhost-user-blk except for the migration stuff.  We're certainly
open to suggestions on how to reconcile this under a single
vhost-user-blk device, as this would be more user-friendly indeed.

We considered using a class property for this and defining the
respective compat clause, but IIUC the class constructors (where .vmsd
and .save/.load are defined) are not supposed to depend on class
properties.

Thanks,
Roman.

Re: Rust in Qemu BoF followup 2: Rust toolchain availability

[David Gibson]

On Thu, Sep 30, 2021 at 11:30:20AM +0100, Peter Maydell wrote:
> On Thu, 30 Sept 2021 at 03:21, David Gibson  
> wrote:
> >
> > Hi again all,
> >
> > I've now done.. or at least started... the second part of my followup
> > from the KVM Forum BoF on Rust in Qemu.
> >
> > I've extended the page at https://wiki.qemu.org/RustInQemu with
> > information on Rust toolchain availability.  However, I found I had a
> > lot more open questions on this one, so there are quite a lot of gaps.
> 
> Thanks for doing this work.
> 
> I note that we have a new host architecture loongarch64 currently
> circling to land. It looks like this is in the "Rust does not have
> support for this target" category at the moment.

AIUI this would be the new Loongson which is no longer MIPS
compatible, yes?  If so, then yes it appears not to have Rust support
at this time.

> > In particular:
> >  * I haven't so far figured out how to definitively check package
> >information for RHEL & SLES (they're not covered by repology, and
> >RHEL module structure confuses me, even as a RedHatter)
> >  * I'm not at all sure what criteria to use to consider something as
> >having "good enough" rustup support, so that information is all
> >blank so far
> 
> I guess the answer here is probably "if it has at least the
> glibc and kernel minimum versions that are documented as
> required for the target-triple in the lists at
> https://doc.rust-lang.org/rustc/platform-support.html then
> that's 'good enough'".

Seems reasonable.  I've updated by table based on that criterion,
though for now I haven't considered architectures - basically if the
distro matches the criterion for any architecture I've marked it as ok.

> >  * I've taken a bit of a stab in the dark about what Rust version is
> >recent enough for our purposes (1.31.0).  I strongly suspect we're
> >going to want to move that to something more recent, but I don't
> >know what, which will mean revising a bunch of stuff
> 
> Hmm. The more we feel we need features that are from a new
> version of Rust the more nervous I get about whether this is
> really something we want to jump to just yet. 1.31 is less than
> 3 years old, which is pretty recent in the context of QEMU's
> own distro support policy.

That's a fair point.  I could be wrong about that.  I'm pretty sure
we'll want Rust 2018 edition support, which is why I used 1.31.0 as
the cutoff.  I know there are a bunch of things that have been
stabilized since then, but I don't know off hand of anything specific
we'll definitely want.

> >  * I'm not really convinced that the way I've formatted it is
> > particularly good, but I haven't though of a better alternative.
> 
> I guess we might also care about the CPU architecture per distro,
> in that even if old version X of the distro supports architecture Y
> and rust today supports architecture Y, that doesn't mean that
> distro version X's shipped rust supported architecture Y.
> But we can probably reasonably say "use rustup" if there are
> corner cases like that.

Yeah.. that's where it starts to get very confusing.

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


signature.asc
Description: PGP signature

[PATCH v4 1/3] docs: remove non-reference uses of single backticks

[John Snow]

The single backtick markup in ReST is the "default role". Currently,
Sphinx's default role is called "content". Sphinx suggests you can use
the "Any" role instead to turn any single-backtick enclosed item into a
cross-reference.

This is useful for things like autodoc for Python docstrings, where it's
often nicer to reference other types with `foo` instead of the more
laborious :py:meth:`foo`. It's also useful in multi-domain cases to
easily reference definitions from other Sphinx domains, such as
referencing C code definitions from outside of kerneldoc comments.

Before we do that, though, we'll need to turn all existing usages of the
"content" role to inline verbatim markup wherever it does not correctly
resolve into a cross-refernece by using double backticks instead.

Signed-off-by: John Snow 
Reviewed-by: Eduardo Habkost 
Reviewed-by: Alexander Bulekov 
---
 docs/devel/fuzzing.rst | 9 +
 docs/devel/tcg-plugins.rst | 2 +-
 docs/interop/live-block-operations.rst | 2 +-
 docs/system/guest-loader.rst   | 2 +-
 qapi/block-core.json   | 4 ++--
 include/qemu/module.h  | 6 +++---
 qemu-options.hx| 4 ++--
 7 files changed, 15 insertions(+), 14 deletions(-)

diff --git a/docs/devel/fuzzing.rst b/docs/devel/fuzzing.rst
index 2749bb9bed3..784ecb99e66 100644
--- a/docs/devel/fuzzing.rst
+++ b/docs/devel/fuzzing.rst
@@ -182,10 +182,11 @@ The output should contain a complete list of matched 
MemoryRegions.
 
 OSS-Fuzz
 
-QEMU is continuously fuzzed on `OSS-Fuzz` 
__(https://github.com/google/oss-fuzz).
-By default, the OSS-Fuzz build will try to fuzz every fuzz-target. Since the
-generic-fuzz target requires additional information provided in environment
-variables, we pre-define some generic-fuzz configs in
+QEMU is continuously fuzzed on `OSS-Fuzz
+`_.  By default, the OSS-Fuzz build
+will try to fuzz every fuzz-target. Since the generic-fuzz target
+requires additional information provided in environment variables, we
+pre-define some generic-fuzz configs in
 ``tests/qtest/fuzz/generic_fuzz_configs.h``. Each config must specify:
 
 - ``.name``: To identify the fuzzer config
diff --git a/docs/devel/tcg-plugins.rst b/docs/devel/tcg-plugins.rst
index 842ae01a4c5..72a1cd932ca 100644
--- a/docs/devel/tcg-plugins.rst
+++ b/docs/devel/tcg-plugins.rst
@@ -211,7 +211,7 @@ The hotpages plugin can be configured using the following 
arguments:
 
 This is an instruction classifier so can be used to count different
 types of instructions. It has a number of options to refine which get
-counted. You can give a value to the `count` argument for a class of
+counted. You can give a value to the ``count`` argument for a class of
 instructions to break it down fully, so for example to see all the system
 registers accesses::
 
diff --git a/docs/interop/live-block-operations.rst 
b/docs/interop/live-block-operations.rst
index 9e3635b2338..814c29bbe1d 100644
--- a/docs/interop/live-block-operations.rst
+++ b/docs/interop/live-block-operations.rst
@@ -640,7 +640,7 @@ at this point:
 (QEMU) block-job-complete device=job0
 
 In either of the above cases, if you once again run the
-`query-block-jobs` command, there should not be any active block
+``query-block-jobs`` command, there should not be any active block
 operation.
 
 Comparing 'commit' and 'mirror': In both then cases, the overlay images
diff --git a/docs/system/guest-loader.rst b/docs/system/guest-loader.rst
index 4320d1183f7..9ef9776bf07 100644
--- a/docs/system/guest-loader.rst
+++ b/docs/system/guest-loader.rst
@@ -51,4 +51,4 @@ The full syntax of the guest-loader is::
 
 ``bootargs=``
   This is an optional field for kernel blobs which will pass command
-  like via the `/chosen/module@/bootargs` node.
+  like via the ``/chosen/module@/bootargs`` node.
diff --git a/qapi/block-core.json b/qapi/block-core.json
index 6d3217abb60..52a6dae9522 100644
--- a/qapi/block-core.json
+++ b/qapi/block-core.json
@@ -491,11 +491,11 @@
 # @granularity: granularity of the dirty bitmap in bytes (since 1.4)
 #
 # @recording: true if the bitmap is recording new writes from the guest.
-# Replaces `active` and `disabled` statuses. (since 4.0)
+# Replaces ``active`` and ``disabled`` statuses. (since 4.0)
 #
 # @busy: true if the bitmap is in-use by some operation (NBD or jobs)
 #and cannot be modified via QMP or used by another operation.
-#Replaces `locked` and `frozen` statuses. (since 4.0)
+#Replaces ``locked`` and ``frozen`` statuses. (since 4.0)
 #
 # @persistent: true if the bitmap was stored on disk, is scheduled to be stored
 #  on disk, or both. (since 4.0)
diff --git a/include/qemu/module.h b/include/qemu/module.h
index 3deac0078b9..5fcc323b2a7 100644
--- a/include/qemu/module.h
+++ b/include/qemu/module.h
@@ -77,14 +77,14 @@ void module_allow_arch(const char *arch);
 /**
  * 

[PATCH v4 3/3] docs/sphinx: change default role to "any"

[John Snow]

This interprets single-backtick syntax in all of our Sphinx docs as a
cross-reference to *something*, including Python symbols.

>From here on out, new uses of `backticks` will cause a build failure if
the target cannot be referenced.

Signed-off-by: John Snow 
Reviewed-by: Eduardo Habkost 
Reviewed-by: Peter Maydell 
---
 docs/conf.py | 5 +
 1 file changed, 5 insertions(+)

diff --git a/docs/conf.py b/docs/conf.py
index ff6e92c6e2e..4d9f56601fc 100644
--- a/docs/conf.py
+++ b/docs/conf.py
@@ -85,6 +85,11 @@
 # The master toctree document.
 master_doc = 'index'
 
+# Interpret `single-backticks` to be a cross-reference to any kind of
+# referenceable object. Unresolvable or ambiguous references will emit a
+# warning at build time.
+default_role = 'any'
+
 # General information about the project.
 project = u'QEMU'
 copyright = u'2021, The QEMU Project Developers'
-- 
2.31.1

[PATCH v4 2/3] docs: (further) remove non-reference uses of single backticks

[John Snow]

The series rotted already. Here's the new changes.

Signed-off-by: John Snow 
---
 docs/system/i386/sgx.rst | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/docs/system/i386/sgx.rst b/docs/system/i386/sgx.rst
index f103ae2a2fd..9aa161af1a1 100644
--- a/docs/system/i386/sgx.rst
+++ b/docs/system/i386/sgx.rst
@@ -77,9 +77,9 @@ CPUID
 
 Due to its myriad dependencies, SGX is currently not listed as supported
 in any of Qemu's built-in CPU configuration. To expose SGX (and SGX Launch
-Control) to a guest, you must either use `-cpu host` to pass-through the
+Control) to a guest, you must either use ``-cpu host`` to pass-through the
 host CPU model, or explicitly enable SGX when using a built-in CPU model,
-e.g. via `-cpu ,+sgx` or `-cpu ,+sgx,+sgxlc`.
+e.g. via ``-cpu ,+sgx`` or ``-cpu ,+sgx,+sgxlc``.
 
 All SGX sub-features enumerated through CPUID, e.g. SGX2, MISCSELECT,
 ATTRIBUTES, etc... can be restricted via CPUID flags. Be aware that enforcing
@@ -126,7 +126,7 @@ creating VM with SGX.
 Feature Control
 ~~~
 
-Qemu SGX updates the `etc/msr_feature_control` fw_cfg entry to set the SGX
+Qemu SGX updates the ``etc/msr_feature_control`` fw_cfg entry to set the SGX
 (bit 18) and SGX LC (bit 17) flags based on their respective CPUID support,
 i.e. existing guest firmware will automatically set SGX and SGX LC accordingly,
 assuming said firmware supports fw_cfg.msr_feature_control.
-- 
2.31.1

[PATCH v4 0/3] docs/sphinx: change default `role` to "any"

[John Snow]

V4: Fixed more occurrences that have occurred since V3.

V3: Removed bad rebase confetti
fixed the OSS-Fuzz link to ... actually be a link.

(Patch 2 can be squashed into patch 1 on merge, but this keeps the diff
easy to see and review.)

--js

John Snow (3):
  docs: remove non-reference uses of single backticks
  docs: (further) remove non-reference uses of single backticks
  docs/sphinx: change default role to "any"

 docs/conf.py   | 5 +
 docs/devel/fuzzing.rst | 9 +
 docs/devel/tcg-plugins.rst | 2 +-
 docs/interop/live-block-operations.rst | 2 +-
 docs/system/guest-loader.rst   | 2 +-
 docs/system/i386/sgx.rst   | 6 +++---
 qapi/block-core.json   | 4 ++--
 include/qemu/module.h  | 6 +++---
 qemu-options.hx| 4 ++--
 9 files changed, 23 insertions(+), 17 deletions(-)

-- 
2.31.1

Re: [PATCH] target/ppc: Fix test the decrementer exception

[BALATON Zoltan]

On Mon, 4 Oct 2021, Cédric Le Goater wrote:

Commit 4d9b8ef9b5ab ("target/ppc: Fix 64-bit decrementer") introduced
new int64t variables and broke the test triggering the decrementer
exception. Revert partially the change to evaluate both clause of the
if statement.

Fixes: Coverity CID 1464061


Shouldn't this be:

Reported-by: Coverity CID 1464061
Fixes: 4d9b8ef9b5ab ("target/ppc: Fix 64-bit decrementer")

or something similar?

Regards,
BALATON Zoltan


Signed-off-by: Cédric Le Goater 
---
hw/ppc/ppc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/ppc/ppc.c b/hw/ppc/ppc.c
index f5d012f860af..a724b0bb5ecb 100644
--- a/hw/ppc/ppc.c
+++ b/hw/ppc/ppc.c
@@ -848,7 +848,7 @@ static void __cpu_ppc_store_decr(PowerPCCPU *cpu, uint64_t 
*nextp,
 * On MSB edge based DEC implementations the MSB going from 0 -> 1 triggers
 * an edge interrupt, so raise it here too.
 */
-if ((signed_value < 3) ||
+if ((value < 3) ||
((tb_env->flags & PPC_DECR_UNDERFLOW_LEVEL) && signed_value < 0) ||
((tb_env->flags & PPC_DECR_UNDERFLOW_TRIGGERED) && signed_value < 0
  && signed_decr >= 0)) {

[PATCH] target/ppc: Fix test the decrementer exception

[Cédric Le Goater]

Commit 4d9b8ef9b5ab ("target/ppc: Fix 64-bit decrementer") introduced
new int64t variables and broke the test triggering the decrementer
exception. Revert partially the change to evaluate both clause of the
if statement.

Fixes: Coverity CID 1464061
Signed-off-by: Cédric Le Goater 
---
 hw/ppc/ppc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/ppc/ppc.c b/hw/ppc/ppc.c
index f5d012f860af..a724b0bb5ecb 100644
--- a/hw/ppc/ppc.c
+++ b/hw/ppc/ppc.c
@@ -848,7 +848,7 @@ static void __cpu_ppc_store_decr(PowerPCCPU *cpu, uint64_t 
*nextp,
  * On MSB edge based DEC implementations the MSB going from 0 -> 1 triggers
  * an edge interrupt, so raise it here too.
  */
-if ((signed_value < 3) ||
+if ((value < 3) ||
 ((tb_env->flags & PPC_DECR_UNDERFLOW_LEVEL) && signed_value < 0) ||
 ((tb_env->flags & PPC_DECR_UNDERFLOW_TRIGGERED) && signed_value < 0
   && signed_decr >= 0)) {
-- 
2.31.1

[PATCH v2 10/12] macfb: fix 24-bit RGB pixel encoding

[Mark Cave-Ayland]

According to Apple Technical Note HW26: "Macintosh Quadra Built-In Video" the
in-built framebuffer encodes each 24-bit pixel into 4 bytes. Adjust the 24-bit
RGB pixel encoding accordingly which agrees with the encoding expected by MacOS
when changing into 24-bit colour mode.

Signed-off-by: Mark Cave-Ayland 
Reviewed-by: Laurent Vivier 
---
 hw/display/macfb.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/hw/display/macfb.c b/hw/display/macfb.c
index ae0cf02dff..ac5d46fa43 100644
--- a/hw/display/macfb.c
+++ b/hw/display/macfb.c
@@ -224,10 +224,10 @@ static void macfb_draw_line24(MacfbState *s, uint8_t *d, 
uint32_t addr,
 int x;
 
 for (x = 0; x < width; x++) {
-r = macfb_read_byte(s, addr);
-g = macfb_read_byte(s, addr + 1);
-b = macfb_read_byte(s, addr + 2);
-addr += 3;
+r = macfb_read_byte(s, addr + 1);
+g = macfb_read_byte(s, addr + 2);
+b = macfb_read_byte(s, addr + 3);
+addr += 4;
 
 *(uint32_t *)d = rgb_to_pixel32(r, g, b);
 d += 4;
-- 
2.20.1

[PATCH v2 09/12] macfb: fix up 1-bit pixel encoding

[Mark Cave-Ayland]

The MacOS driver expects the RGB values for the pixel to be in entries 0 and 1
of the colour palette.

Signed-off-by: Mark Cave-Ayland 
Reviewed-by: Laurent Vivier 
---
 hw/display/macfb.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/hw/display/macfb.c b/hw/display/macfb.c
index 357fe18be5..ae0cf02dff 100644
--- a/hw/display/macfb.c
+++ b/hw/display/macfb.c
@@ -128,7 +128,9 @@ static void macfb_draw_line1(MacfbState *s, uint8_t *d, 
uint32_t addr,
 for (x = 0; x < width; x++) {
 int bit = x & 7;
 int idx = (macfb_read_byte(s, addr) >> (7 - bit)) & 1;
-r = g = b  = ((1 - idx) << 7);
+r = s->color_palette[idx * 3];
+g = s->color_palette[idx * 3 + 1];
+b = s->color_palette[idx * 3 + 2];
 addr += (bit == 7);
 
 *(uint32_t *)d = rgb_to_pixel32(r, g, b);
-- 
2.20.1

[PATCH v2 04/12] macfb: use memory_region_init_ram() in macfb_common_realize() for the framebuffer

[Mark Cave-Ayland]

Currently macfb_common_realize() defines the framebuffer RAM memory region as
being non-migrateable but then immediately registers it for migration. Replace
memory_region_init_ram_nomigrate() with memory_region_init_ram() which is 
clearer
and does exactly the same thing.

Signed-off-by: Mark Cave-Ayland 
Reviewed-by: BALATON Zoltan 
Reviewed-by: Philippe Mathieu-Daudé 
Reviewed-by: Laurent Vivier 
---
 hw/display/macfb.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/hw/display/macfb.c b/hw/display/macfb.c
index 39dab49026..f88f5a6523 100644
--- a/hw/display/macfb.c
+++ b/hw/display/macfb.c
@@ -367,11 +367,10 @@ static bool macfb_common_realize(DeviceState *dev, 
MacfbState *s, Error **errp)
 memory_region_init_io(>mem_ctrl, OBJECT(dev), _ctrl_ops, s,
   "macfb-ctrl", 0x1000);
 
-memory_region_init_ram_nomigrate(>mem_vram, OBJECT(dev), "macfb-vram",
- MACFB_VRAM_SIZE, _abort);
+memory_region_init_ram(>mem_vram, OBJECT(dev), "macfb-vram",
+   MACFB_VRAM_SIZE, _abort);
 s->vram = memory_region_get_ram_ptr(>mem_vram);
 s->vram_bit_mask = MACFB_VRAM_SIZE - 1;
-vmstate_register_ram(>mem_vram, dev);
 memory_region_set_coalescing(>mem_vram);
 
 return true;
-- 
2.20.1

Re: [PATCH 12/15] iotests: Disable AQMP logging under non-debug modes

[John Snow]

On Mon, Oct 4, 2021 at 2:32 PM John Snow  wrote:

>
>
> On Mon, Oct 4, 2021 at 6:12 AM Hanna Reitz  wrote:
>
>> On 18.09.21 04:14, John Snow wrote:
>> >
>> >
>> > On Fri, Sep 17, 2021 at 8:58 PM John Snow > > > wrote:
>> >
>> >
>> >
>> > On Fri, Sep 17, 2021 at 10:30 AM Hanna Reitz > > > wrote:
>> >
>> > On 17.09.21 07:40, John Snow wrote:
>> > > Disable the aqmp logger, which likes to (at the moment)
>> > print out
>> > > intermediate warnings and errors that cause session
>> > termination; disable
>> > > them so they don't interfere with the job output.
>> > >
>> > > Leave any "CRITICAL" warnings enabled though, those are ones
>> > that we
>> > > should never see, no matter what.
>> >
>> > I mean, looks OK to me, but from what I understand (i.e.
>> little),
>> > qmp_client doesn’t log CRITICAL messages, at least I can’t see
>> > any. Only
>> > ERRORs.
>> >
>> >
>> > There's *one* critical message in protocol.py, used for a
>> > circumstance that I *think* should be impossible. I do not think I
>> > currently use any WARNING level statements.
>> >
>> > I guess I’m missing some CRITICAL messages in external
>> > functions called
>> > from qmp_client.py, but shouldn’t we still keep ERRORs?
>> >
>> >
>> > ...Mayybe?
>> >
>> > The errors logged by AQMP are *almost always* raised as Exceptions
>> > somewhere else, eventually. Sometimes when we encounter them in
>> > one context, we need to save them and then re-raise them in a
>> > different execution context. There's one good exception to this:
>> > My pal, EOFError.
>> >
>> > If the reader context encounters EOF, it raises EOFError and this
>> > causes a disconnect to be scheduled asynchronously. *Any*
>> > Exception that causes a disconnect to be scheduled asynchronously
>> > is dutifully logged as an ERROR. At this point in the code, we
>> > don't really know if the user of the library considers this an
>> > "error" yet or not. I've waffled a lot on how exactly to treat
>> > this circumstance. ...Hm, I guess that's really the only case
>> > where I have an error that really ought to be suppressed. I
>> > suppose what I will do here is: if the exception happens to be an
>> > EOFError I will drop the severity of the log message down to INFO.
>> > I don't know why it takes being challenged on this stuff to start
>> > thinking clearly about it, but here we are. Thank you for your
>> > feedback :~)
>> >
>> > --js
>> >
>> >
>> > Oh, CI testing reminds me of why I am a liar here.
>> >
>> > the mirror-top-perms test intentionally expects not to be able to
>> > connect, but we're treated to these two additional lines of output:
>> >
>> > +ERROR:qemu.aqmp.qmp_client.qemub-2536319:Negotiation failed: EOFError
>> > +ERROR:qemu.aqmp.qmp_client.qemub-2536319:Failed to establish session:
>> > EOFError
>> >
>> > Uh. I guess a temporary suppression in mirror-top-perms, then ...?
>>
>> Sounds right to me, if that’s simple enough.
>>
>> (By the way, I understand it right that you want to lower the severity
>> of EOFErrors to INFO only on disconnect, right?  Which is why they’re
>> still logged as ERRORs here, because they aren’t occurring on
>> disconnects?)
>>
>>
> More or less, yeah.
>
> When an EOFError causes the reader coroutine to halt (because it can't
> read the next message), I decided (in v2) to drop that one particular
> logging message down to "INFO", because it might -- or might not be -- an
> expected occurrence from the point of view of whoever is managing the QMP
> connection. Maybe it was expected (The test used qemu-guest-agent or
> something else to make the guest shutdown, taking QEMU down with it without
> the knowledge of the QMP library layer) or maybe it was unexpected (the QMP
> remote really just disappeared from us on a whim). There's no way to know,
> so it probably isn't right to consider it an error.
>
> In the connection case, I left it as an ERROR because the caller asked us
> to connect to an endpoint and we were unable to, which feels unambiguous.
> It will be ultimately reported via Exceptions as qemu.aqmp.ConnectError,
> with additional information available in fields of that exception object.
> Even though the exception is reported to the caller, I decided to log the
> occurrence anyway, because I felt like it should be the job of the library
> to make a good log and not the caller's responsibility to catch the
> exception and then log it themselves.
>
> That does leave us with this atypical case though: the caller is
> intentionally causing problems :)
>
> (Well, atypical for a user of the library who is using it to make a tool
> they expect to work. Quite a typical case for tests in the abstract, though
> we only seem to have precisely one usage of 

[PATCH v2 03/12] macfb: fix overflow of color_palette array

[Mark Cave-Ayland]

The palette_current index counter has a maximum size of 256 * 3 to cover a full
color palette of 256 RGB entries. Linux assumes that the palette_current index
wraps back around to zero after writing 256 RGB entries so ensure that
palette_current is reset at this point to prevent data corruption within
MacfbState.

Signed-off-by: Mark Cave-Ayland 
---
 hw/display/macfb.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/hw/display/macfb.c b/hw/display/macfb.c
index b363bab889..39dab49026 100644
--- a/hw/display/macfb.c
+++ b/hw/display/macfb.c
@@ -303,7 +303,9 @@ static void macfb_ctrl_write(void *opaque,
 s->palette_current = 0;
 break;
 case DAFB_LUT:
-s->color_palette[s->palette_current++] = val;
+s->color_palette[s->palette_current] = val;
+s->palette_current = (s->palette_current + 1) %
+ ARRAY_SIZE(s->color_palette);
 if (s->palette_current % 3) {
 macfb_invalidate_display(s);
 }
-- 
2.20.1

[PATCH v2 00/12] macfb: fixes for booting MacOS

[Mark Cave-Ayland]

This is the next set of patches to allow users to boot MacOS in QEMU's
q800 machine.

Patches 1 to 3 are fixes for existing bugs that I discovered whilst
developing the remainder of the patchset whilst patch 4 simplifies the
registration of the framebuffer RAM.

Patch 5 adds trace events to the framebuffer register accesses. The
framebuffer registers are not officially documented, so the macfb
device changes here are based upon reading of Linux/NetBSD source code,
using gdbstub during the MacOS toolbox ROM initialisation, and changing
the framebuffer size/depth within MacOS itself with these trace events
enabled.

Patches 6 and 7 implement the mode sense logic documented in Apple
Technical Note HW26 "Macintosh Quadra Built-In Video" and configure the
default display type to be VGA.

Patch 8 implements the common monitor modes used for VGA at 640x480 and
800x600 for 1, 2, 4, 8 and 24-bit depths and also the Apple 21" color
monitor at 1152x870 with 8-bit depth.

Patches 9 and 10 fix up errors in the 1-bit and 24-bit pixel encodings
discovered when testing these color depths in MacOS.

Patch 11 adds a timer to implement the 60.15Hz VBL interrupt which is
required for MacOS to process mouse movements, whilst patch 12 wires the
same interrupt to a dedicated pin on VIA2 reserved for the video
interrupt on the Quadra 800.

Signed-off-by: Mark Cave-Ayland 


v2:
- Rebase onto master
- Add R-B tags from Zoltan, Philippe and Laurent
- Rework macfb_common_realize() to return a bool in patch 1
- Add Fixes tag to patch 2
- Use Laurent's suggested change for s->current_palette (slightly modified) in 
patch 3
- Change size trace-events parameter to unsigned int in patch 5
- Add assert() as suggested by Philippe in patch 7
- Move calculation of next VBL time into a separate macfb_next_vbl() function 
in patch 11


Mark Cave-Ayland (12):
  macfb: handle errors that occur during realize
  macfb: fix invalid object reference in macfb_common_realize()
  macfb: fix overflow of color_palette array
  macfb: use memory_region_init_ram() in macfb_common_realize() for the
framebuffer
  macfb: add trace events for reading and writing the control registers
  macfb: implement mode sense to allow display type to be detected
  macfb: add qdev property to specify display type
  macfb: add common monitor modes supported by the MacOS toolbox ROM
  macfb: fix up 1-bit pixel encoding
  macfb: fix 24-bit RGB pixel encoding
  macfb: add vertical blank interrupt
  q800: wire macfb IRQ to separate video interrupt on VIA2

 hw/display/macfb.c | 361 ++---
 hw/display/trace-events|   7 +
 hw/m68k/q800.c |  23 ++-
 include/hw/display/macfb.h |  43 +
 4 files changed, 404 insertions(+), 30 deletions(-)

-- 
2.20.1

[PATCH] spapr/xive: Add source status helpers

[Cédric Le Goater]

and use them to set and test the ASSERTED bit of LSI sources.

Signed-off-by: Cédric Le Goater 
---
 include/hw/ppc/xive.h| 24 
 hw/intc/spapr_xive.c |  2 +-
 hw/intc/spapr_xive_kvm.c | 10 +++---
 hw/intc/xive.c   |  8 
 4 files changed, 32 insertions(+), 12 deletions(-)

diff --git a/include/hw/ppc/xive.h b/include/hw/ppc/xive.h
index 252c58a1d691..b8ab0bf7490f 100644
--- a/include/hw/ppc/xive.h
+++ b/include/hw/ppc/xive.h
@@ -286,6 +286,30 @@ uint8_t xive_esb_set(uint8_t *pq, uint8_t value);
 uint8_t xive_source_esb_get(XiveSource *xsrc, uint32_t srcno);
 uint8_t xive_source_esb_set(XiveSource *xsrc, uint32_t srcno, uint8_t pq);
 
+/*
+ * Source status helpers
+ */
+static inline void xive_source_set_status(XiveSource *xsrc, uint32_t srcno,
+  uint8_t status, bool enable)
+{
+if (enable) {
+xsrc->status[srcno] |= status;
+} else {
+xsrc->status[srcno] &= ~status;
+}
+}
+
+static inline void xive_source_set_asserted(XiveSource *xsrc, uint32_t srcno,
+bool enable)
+{
+xive_source_set_status(xsrc, srcno, XIVE_STATUS_ASSERTED, enable);
+}
+
+static inline bool xive_source_is_asserted(XiveSource *xsrc, uint32_t srcno)
+{
+return xsrc->status[srcno] & XIVE_STATUS_ASSERTED;
+}
+
 void xive_source_pic_print_info(XiveSource *xsrc, uint32_t offset,
 Monitor *mon);
 
diff --git a/hw/intc/spapr_xive.c b/hw/intc/spapr_xive.c
index 89cfa018f598..4ec659b93e13 100644
--- a/hw/intc/spapr_xive.c
+++ b/hw/intc/spapr_xive.c
@@ -185,7 +185,7 @@ static void spapr_xive_pic_print_info(SpaprXive *xive, 
Monitor *mon)
xive_source_irq_is_lsi(xsrc, i) ? "LSI" : "MSI",
pq & XIVE_ESB_VAL_P ? 'P' : '-',
pq & XIVE_ESB_VAL_Q ? 'Q' : '-',
-   xsrc->status[i] & XIVE_STATUS_ASSERTED ? 'A' : ' ',
+   xive_source_is_asserted(xsrc, i) ? 'A' : ' ',
xive_eas_is_masked(eas) ? "M" : " ",
(int) xive_get_field64(EAS_END_DATA, eas->w));
 
diff --git a/hw/intc/spapr_xive_kvm.c b/hw/intc/spapr_xive_kvm.c
index 6d4909d0a856..be94cff14837 100644
--- a/hw/intc/spapr_xive_kvm.c
+++ b/hw/intc/spapr_xive_kvm.c
@@ -242,7 +242,7 @@ int kvmppc_xive_source_reset_one(XiveSource *xsrc, int 
srcno, Error **errp)
 
 if (xive_source_irq_is_lsi(xsrc, srcno)) {
 state |= KVM_XIVE_LEVEL_SENSITIVE;
-if (xsrc->status[srcno] & XIVE_STATUS_ASSERTED) {
+if (xive_source_is_asserted(xsrc, srcno)) {
 state |= KVM_XIVE_LEVEL_ASSERTED;
 }
 }
@@ -321,7 +321,7 @@ uint64_t kvmppc_xive_esb_rw(XiveSource *xsrc, int srcno, 
uint32_t offset,
 if (xive_source_irq_is_lsi(xsrc, srcno) &&
 offset == XIVE_ESB_LOAD_EOI) {
 xive_esb_read(xsrc, srcno, XIVE_ESB_SET_PQ_00);
-if (xsrc->status[srcno] & XIVE_STATUS_ASSERTED) {
+if (xive_source_is_asserted(xsrc, srcno)) {
 kvmppc_xive_esb_trigger(xsrc, srcno);
 }
 return 0;
@@ -359,11 +359,7 @@ void kvmppc_xive_source_set_irq(void *opaque, int srcno, 
int val)
 return;
 }
 } else {
-if (val) {
-xsrc->status[srcno] |= XIVE_STATUS_ASSERTED;
-} else {
-xsrc->status[srcno] &= ~XIVE_STATUS_ASSERTED;
-}
+xive_source_set_asserted(xsrc, srcno, val);
 }
 
 kvmppc_xive_esb_trigger(xsrc, srcno);
diff --git a/hw/intc/xive.c b/hw/intc/xive.c
index 6c82326ec768..190194d27f84 100644
--- a/hw/intc/xive.c
+++ b/hw/intc/xive.c
@@ -875,7 +875,7 @@ static bool xive_source_lsi_trigger(XiveSource *xsrc, 
uint32_t srcno)
 {
 uint8_t old_pq = xive_source_esb_get(xsrc, srcno);
 
-xsrc->status[srcno] |= XIVE_STATUS_ASSERTED;
+xive_source_set_asserted(xsrc, srcno, true);
 
 switch (old_pq) {
 case XIVE_ESB_RESET:
@@ -923,7 +923,7 @@ static bool xive_source_esb_eoi(XiveSource *xsrc, uint32_t 
srcno)
  * notification
  */
 if (xive_source_irq_is_lsi(xsrc, srcno) &&
-xsrc->status[srcno] & XIVE_STATUS_ASSERTED) {
+xive_source_is_asserted(xsrc, srcno)) {
 ret = xive_source_lsi_trigger(xsrc, srcno);
 }
 
@@ -1104,7 +1104,7 @@ void xive_source_set_irq(void *opaque, int srcno, int val)
 if (val) {
 notify = xive_source_lsi_trigger(xsrc, srcno);
 } else {
-xsrc->status[srcno] &= ~XIVE_STATUS_ASSERTED;
+xive_source_set_asserted(xsrc, srcno, false);
 }
 } else {
 if (val) {
@@ -1133,7 +1133,7 @@ void xive_source_pic_print_info(XiveSource *xsrc, 
uint32_t offset, Monitor *mon)
xive_source_irq_is_lsi(xsrc, i) ? "LSI" : "MSI",
pq & XIVE_ESB_VAL_P ? 'P' : '-',
pq & XIVE_ESB_VAL_Q ? 'Q' : '-',
-   xsrc->status[i] 

[PATCH v2 11/12] macfb: add vertical blank interrupt

[Mark Cave-Ayland]

The MacOS driver expects a 60.15Hz vertical blank interrupt to be generated by
the framebuffer which in turn schedules the mouse driver via the Vertical 
Retrace
Manager.

Signed-off-by: Mark Cave-Ayland 
Reviewed-by: Laurent Vivier 
---
 hw/display/macfb.c | 83 ++
 include/hw/display/macfb.h |  8 
 2 files changed, 91 insertions(+)

diff --git a/hw/display/macfb.c b/hw/display/macfb.c
index ac5d46fa43..5b8812e9e7 100644
--- a/hw/display/macfb.c
+++ b/hw/display/macfb.c
@@ -33,9 +33,16 @@
 #define DAFB_MODE_CTRL1 0x8
 #define DAFB_MODE_CTRL2 0xc
 #define DAFB_MODE_SENSE 0x1c
+#define DAFB_INTR_MASK  0x104
+#define DAFB_INTR_STAT  0x108
+#define DAFB_INTR_CLEAR 0x10c
 #define DAFB_RESET  0x200
 #define DAFB_LUT0x213
 
+#define DAFB_INTR_VBL   0x4
+
+/* Vertical Blank period (60.15Hz) */
+#define DAFB_INTR_VBL_PERIOD_NS 16625800
 
 /*
  * Quadra sense codes taken from Apple Technical Note HW26:
@@ -450,6 +457,36 @@ static void macfb_update_display(void *opaque)
 macfb_draw_graphic(s);
 }
 
+static void macfb_update_irq(MacfbState *s)
+{
+uint32_t irq_state = s->irq_state & s->irq_mask;
+
+if (irq_state) {
+qemu_irq_raise(s->irq);
+} else {
+qemu_irq_lower(s->irq);
+}
+}
+
+static int64_t macfb_next_vbl(void)
+{
+return (qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) + DAFB_INTR_VBL_PERIOD_NS) /
+DAFB_INTR_VBL_PERIOD_NS * DAFB_INTR_VBL_PERIOD_NS;
+}
+
+static void macfb_vbl_timer(void *opaque)
+{
+MacfbState *s = opaque;
+int64_t next_vbl;
+
+s->irq_state |= DAFB_INTR_VBL;
+macfb_update_irq(s);
+
+/* 60 Hz irq */
+next_vbl = macfb_next_vbl();
+timer_mod(s->vbl_timer, next_vbl);
+}
+
 static void macfb_reset(MacfbState *s)
 {
 int i;
@@ -478,6 +515,9 @@ static uint64_t macfb_ctrl_read(void *opaque,
 case DAFB_MODE_CTRL2:
 val = s->regs[addr >> 2];
 break;
+case DAFB_INTR_STAT:
+val = s->irq_state;
+break;
 case DAFB_MODE_SENSE:
 val = macfb_sense_read(s);
 break;
@@ -493,6 +533,8 @@ static void macfb_ctrl_write(void *opaque,
  unsigned int size)
 {
 MacfbState *s = opaque;
+int64_t next_vbl;
+
 switch (addr) {
 case DAFB_MODE_VADDR1:
 case DAFB_MODE_VADDR2:
@@ -508,8 +550,23 @@ static void macfb_ctrl_write(void *opaque,
 case DAFB_MODE_SENSE:
 macfb_sense_write(s, val);
 break;
+case DAFB_INTR_MASK:
+s->irq_mask = val;
+if (val & DAFB_INTR_VBL) {
+next_vbl = macfb_next_vbl();
+timer_mod(s->vbl_timer, next_vbl);
+} else {
+timer_del(s->vbl_timer);
+}
+break;
+case DAFB_INTR_CLEAR:
+s->irq_state &= ~DAFB_INTR_VBL;
+macfb_update_irq(s);
+break;
 case DAFB_RESET:
 s->palette_current = 0;
+s->irq_state &= ~DAFB_INTR_VBL;
+macfb_update_irq(s);
 break;
 case DAFB_LUT:
 s->color_palette[s->palette_current] = val;
@@ -586,6 +643,7 @@ static bool macfb_common_realize(DeviceState *dev, 
MacfbState *s, Error **errp)
 s->vram_bit_mask = MACFB_VRAM_SIZE - 1;
 memory_region_set_coalescing(>mem_vram);
 
+s->vbl_timer = timer_new_ns(QEMU_CLOCK_VIRTUAL, macfb_vbl_timer, s);
 macfb_update_mode(s);
 return true;
 }
@@ -601,6 +659,16 @@ static void macfb_sysbus_realize(DeviceState *dev, Error 
**errp)
 
 sysbus_init_mmio(SYS_BUS_DEVICE(s), >mem_ctrl);
 sysbus_init_mmio(SYS_BUS_DEVICE(s), >mem_vram);
+
+qdev_init_gpio_out(dev, >irq, 1);
+}
+
+static void macfb_nubus_set_irq(void *opaque, int n, int level)
+{
+MacfbNubusState *s = NUBUS_MACFB(opaque);
+NubusDevice *nd = NUBUS_DEVICE(s);
+
+nubus_set_irq(nd, level);
 }
 
 static void macfb_nubus_realize(DeviceState *dev, Error **errp)
@@ -621,6 +689,19 @@ static void macfb_nubus_realize(DeviceState *dev, Error 
**errp)
 
 memory_region_add_subregion(>slot_mem, DAFB_BASE, >mem_ctrl);
 memory_region_add_subregion(>slot_mem, VIDEO_BASE, >mem_vram);
+
+ms->irq = qemu_allocate_irq(macfb_nubus_set_irq, s, 0);
+}
+
+static void macfb_nubus_unrealize(DeviceState *dev)
+{
+MacfbNubusState *s = NUBUS_MACFB(dev);
+MacfbNubusDeviceClass *ndc = NUBUS_MACFB_GET_CLASS(dev);
+MacfbState *ms = >macfb;
+
+ndc->parent_unrealize(dev);
+
+qemu_free_irq(ms->irq);
 }
 
 static void macfb_sysbus_reset(DeviceState *d)
@@ -671,6 +752,8 @@ static void macfb_nubus_class_init(ObjectClass *klass, void 
*data)
 
 device_class_set_parent_realize(dc, macfb_nubus_realize,
 >parent_realize);
+device_class_set_parent_unrealize(dc, macfb_nubus_unrealize,
+  >parent_unrealize);
 dc->desc = "Nubus Macintosh framebuffer";
 dc->reset = macfb_nubus_reset;
 dc->vmsd = _macfb;
diff --git a/include/hw/display/macfb.h 

Re: [PATCH v6 09/10] ACPI ERST: bios-tables-test testcase

[Eric DeVolder]

On 9/21/21 6:32 AM, Igor Mammedov wrote:

On Thu,  5 Aug 2021 18:30:38 -0400
Eric DeVolder  wrote:


This change implements the test suite checks for the ERST table.

Signed-off-by: Eric DeVolder 
---
  tests/qtest/bios-tables-test.c | 43 ++
  1 file changed, 43 insertions(+)

diff --git a/tests/qtest/bios-tables-test.c b/tests/qtest/bios-tables-test.c
index 51d3a4e..6ee78ec 100644
--- a/tests/qtest/bios-tables-test.c
+++ b/tests/qtest/bios-tables-test.c
@@ -1378,6 +1378,45 @@ static void test_acpi_piix4_tcg_acpi_hmat(void)
  test_acpi_tcg_acpi_hmat(MACHINE_PC);
  }
  
+static void test_acpi_erst(const char *machine)

+{
+test_data data;
+
+memset(, 0, sizeof(data));
+data.machine = machine;
+/*data.variant = ".acpierst";*/
+test_acpi_one(" -object memory-backend-file,id=erstnvram,"
+"mem-path=tests/acpi-erst.XX,size=0x1,share=on"
+" -device acpi-erst,memdev=erstnvram",
+  );
+free_test_data();
+}
+
+static void test_acpi_piix4_erst(void)
+{
+test_acpi_erst(MACHINE_PC);
+}
+
+static void test_acpi_q35_erst(void)
+{
+test_acpi_erst(MACHINE_Q35);
+}
+
+static void test_acpi_microvm_erst(void)
+{
+test_data data;
+
+test_acpi_microvm_prepare();
+data.variant = ".pcie";
+data.tcg_only = true; /* need constant host-phys-bits */
+test_acpi_one(" -machine microvm,acpi=on,ioapic2=off,rtc=off,pcie=on "
+"-object memory-backend-file,id=erstnvram,"
+"mem-path=tests/acpi-erst.XX,size=0x1,share=on "

  
shouldn't the path be generated with g_dir_make_tmp() & co + corresponding 
cleanup

done!




+"-device acpi-erst,memdev=erstnvram",
+  );
+free_test_data();
+}
+
  static void test_acpi_virt_tcg(void)
  {
  test_data data = {
@@ -1560,7 +1599,11 @@ int main(int argc, char *argv[])
  qtest_add_func("acpi/microvm/oem-fields", 
test_acpi_oem_fields_microvm);
  if (strcmp(arch, "x86_64") == 0) {
  qtest_add_func("acpi/microvm/pcie", test_acpi_microvm_pcie_tcg);
+qtest_add_func("acpi/microvm/acpierst", test_acpi_microvm_erst);
  }
+qtest_add_func("acpi/piix4/acpierst", test_acpi_piix4_erst);
+qtest_add_func("acpi/q35/acpierst", test_acpi_q35_erst);
+
  } else if (strcmp(arch, "aarch64") == 0) {
  qtest_add_func("acpi/virt", test_acpi_virt_tcg);
  qtest_add_func("acpi/virt/numamem", test_acpi_virt_tcg_numamem);

[PATCH v2 12/12] q800: wire macfb IRQ to separate video interrupt on VIA2

[Mark Cave-Ayland]

Whilst the in-built Quadra 800 framebuffer exists within the Nubus address
space for slot 9, it has its own dedicated interrupt on VIA2. Force the
macfb device to occupy slot 9 in the q800 machine and wire its IRQ to the
separate video interrupt since this is what is expected by the MacOS
interrupt handler.

Signed-off-by: Mark Cave-Ayland 
Reviewed-by: Philippe Mathieu-Daudé 
Reviewed-by: Laurent Vivier 
---
 hw/m68k/q800.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/hw/m68k/q800.c b/hw/m68k/q800.c
index df3fd3711e..fd4855047e 100644
--- a/hw/m68k/q800.c
+++ b/hw/m68k/q800.c
@@ -407,8 +407,10 @@ static void q800_init(MachineState *machine)
 MAC_NUBUS_FIRST_SLOT * NUBUS_SUPER_SLOT_SIZE);
 sysbus_mmio_map(SYS_BUS_DEVICE(dev), 1, NUBUS_SLOT_BASE +
 MAC_NUBUS_FIRST_SLOT * NUBUS_SLOT_SIZE);
-
-for (i = 0; i < VIA2_NUBUS_IRQ_NB; i++) {
+qdev_connect_gpio_out(dev, 9,
+  qdev_get_gpio_in_named(via2_dev, "nubus-irq",
+  VIA2_NUBUS_IRQ_INTVIDEO));
+for (i = 1; i < VIA2_NUBUS_IRQ_NB; i++) {
 qdev_connect_gpio_out(dev, 9 + i,
   qdev_get_gpio_in_named(via2_dev, "nubus-irq",
  VIA2_NUBUS_IRQ_9 + i));
@@ -419,6 +421,7 @@ static void q800_init(MachineState *machine)
 /* framebuffer in nubus slot #9 */
 
 dev = qdev_new(TYPE_NUBUS_MACFB);
+qdev_prop_set_uint32(dev, "slot", 9);
 qdev_prop_set_uint32(dev, "width", graphic_width);
 qdev_prop_set_uint32(dev, "height", graphic_height);
 qdev_prop_set_uint8(dev, "depth", graphic_depth);
-- 
2.20.1

[PATCH v2 08/12] macfb: add common monitor modes supported by the MacOS toolbox ROM

[Mark Cave-Ayland]

The monitor modes table is found by experimenting with the Monitors Control
Panel in MacOS and analysing the reads/writes. From this it can be found that
the mode is controlled by writes to the DAFB_MODE_CTRL1 and DAFB_MODE_CTRL2
registers.

Implement the first block of DAFB registers as a register array including the
existing sense register, the newly discovered control registers above, and also
the DAFB_MODE_VADDR1 and DAFB_MODE_VADDR2 registers which are used by NetBSD to
determine the current video mode.

These experiments also show that the offset of the start of video RAM and the
stride can change depending upon the monitor mode, so update 
macfb_draw_graphic()
and both the BI_MAC_VADDR and BI_MAC_VROW bootinfo for the q800 machine
accordingly.

Finally update macfb_common_realize() so that only the resolution and depth
supported by the display type can be specified on the command line.

Signed-off-by: Mark Cave-Ayland 
Reviewed-by: Laurent Vivier 
---
 hw/display/macfb.c | 124 -
 hw/display/trace-events|   1 +
 hw/m68k/q800.c |  11 ++--
 include/hw/display/macfb.h |  16 -
 4 files changed, 131 insertions(+), 21 deletions(-)

diff --git a/hw/display/macfb.c b/hw/display/macfb.c
index f98bcdec2d..357fe18be5 100644
--- a/hw/display/macfb.c
+++ b/hw/display/macfb.c
@@ -22,12 +22,16 @@
 #include "migration/vmstate.h"
 #include "trace.h"
 
-#define VIDEO_BASE 0x1000
+#define VIDEO_BASE 0x0
 #define DAFB_BASE  0x0080
 
 #define MACFB_PAGE_SIZE 4096
 #define MACFB_VRAM_SIZE (4 * MiB)
 
+#define DAFB_MODE_VADDR10x0
+#define DAFB_MODE_VADDR20x4
+#define DAFB_MODE_CTRL1 0x8
+#define DAFB_MODE_CTRL2 0xc
 #define DAFB_MODE_SENSE 0x1c
 #define DAFB_RESET  0x200
 #define DAFB_LUT0x213
@@ -89,6 +93,22 @@ static MacFbSense macfb_sense_table[] = {
 { MACFB_DISPLAY_SVGA, 0x7, 0x5 },
 };
 
+static MacFbMode macfb_mode_table[] = {
+{ MACFB_DISPLAY_VGA, 1, 0x100, 0x71e, 640, 480, 0x400, 0x1000 },
+{ MACFB_DISPLAY_VGA, 2, 0x100, 0x70e, 640, 480, 0x400, 0x1000 },
+{ MACFB_DISPLAY_VGA, 4, 0x100, 0x706, 640, 480, 0x400, 0x1000 },
+{ MACFB_DISPLAY_VGA, 8, 0x100, 0x702, 640, 480, 0x400, 0x1000 },
+{ MACFB_DISPLAY_VGA, 24, 0x100, 0x7ff, 640, 480, 0x1000, 0x1000 },
+{ MACFB_DISPLAY_VGA, 1, 0xd0 , 0x70e, 800, 600, 0x340, 0xe00 },
+{ MACFB_DISPLAY_VGA, 2, 0xd0 , 0x706, 800, 600, 0x340, 0xe00 },
+{ MACFB_DISPLAY_VGA, 4, 0xd0 , 0x702, 800, 600, 0x340, 0xe00 },
+{ MACFB_DISPLAY_VGA, 8, 0xd0,  0x700, 800, 600, 0x340, 0xe00 },
+{ MACFB_DISPLAY_VGA, 24, 0x340, 0x100, 800, 600, 0xd00, 0xe00 },
+{ MACFB_DISPLAY_APPLE_21_COLOR, 1, 0x90, 0x506, 1152, 870, 0x240, 0x80 },
+{ MACFB_DISPLAY_APPLE_21_COLOR, 2, 0x90, 0x502, 1152, 870, 0x240, 0x80 },
+{ MACFB_DISPLAY_APPLE_21_COLOR, 4, 0x90, 0x500, 1152, 870, 0x240, 0x80 },
+{ MACFB_DISPLAY_APPLE_21_COLOR, 8, 0x120, 0x5ff, 1152, 870, 0x480, 0x80 },
+};
 
 typedef void macfb_draw_line_func(MacfbState *s, uint8_t *d, uint32_t addr,
   int width);
@@ -246,7 +266,7 @@ static void macfb_draw_graphic(MacfbState *s)
 ram_addr_t page;
 uint32_t v = 0;
 int y, ymin;
-int macfb_stride = (s->depth * s->width + 7) / 8;
+int macfb_stride = s->mode->stride;
 macfb_draw_line_func *macfb_draw_line;
 
 switch (s->depth) {
@@ -278,7 +298,7 @@ static void macfb_draw_graphic(MacfbState *s)
  DIRTY_MEMORY_VGA);
 
 ymin = -1;
-page = 0;
+page = s->mode->offset;
 for (y = 0; y < s->height; y++, page += macfb_stride) {
 if (macfb_check_dirty(s, snap, page, macfb_stride)) {
 uint8_t *data_display;
@@ -323,25 +343,26 @@ static uint32_t macfb_sense_read(MacfbState *s)
 sense = 0;
 if (!(macfb_sense->ext_sense & 1)) {
 /* Pins 7-4 together */
-if (~s->sense & 3) {
-sense = (~s->sense & 7) | 3;
+if (~s->regs[DAFB_MODE_SENSE >> 2] & 3) {
+sense = (~s->regs[DAFB_MODE_SENSE >> 2] & 7) | 3;
 }
 }
 if (!(macfb_sense->ext_sense & 2)) {
 /* Pins 10-7 together */
-if (~s->sense & 6) {
-sense = (~s->sense & 7) | 6;
+if (~s->regs[DAFB_MODE_SENSE >> 2] & 6) {
+sense = (~s->regs[DAFB_MODE_SENSE >> 2] & 7) | 6;
 }
 }
 if (!(macfb_sense->ext_sense & 4)) {
 /* Pins 4-10 together */
-if (~s->sense & 5) {
-sense = (~s->sense & 7) | 5;
+if (~s->regs[DAFB_MODE_SENSE >> 2] & 5) {
+sense = (~s->regs[DAFB_MODE_SENSE >> 2] & 7) | 5;
 }
 }
 } else {
 /* Normal sense */
-sense = (~macfb_sense->sense & 7) | (~s->sense & 7);
+sense = (~macfb_sense->sense & 7) |
+(~s->regs[DAFB_MODE_SENSE >> 2] & 7);
 }
 

[PATCH v2 06/12] macfb: implement mode sense to allow display type to be detected

[Mark Cave-Ayland]

The MacOS toolbox ROM uses the monitor sense to detect the display type and then
offer a fixed set of resolutions and colour depths accordingly. Implement the
monitor sense using information found in Apple Technical Note HW26: "Macintosh
Quadra Built-In Video" along with some local experiments.

Since the default configuration is 640 x 480 with 8-bit colour then hardcode
the sense register to return MACFB_DISPLAY_VGA for now.

Signed-off-by: Mark Cave-Ayland 
Reviewed-by: Laurent Vivier 
---
 hw/display/macfb.c | 117 -
 hw/display/trace-events|   2 +
 include/hw/display/macfb.h |  20 +++
 3 files changed, 137 insertions(+), 2 deletions(-)

diff --git a/hw/display/macfb.c b/hw/display/macfb.c
index 1128a51c98..6e485d7aef 100644
--- a/hw/display/macfb.c
+++ b/hw/display/macfb.c
@@ -28,8 +28,66 @@
 #define MACFB_PAGE_SIZE 4096
 #define MACFB_VRAM_SIZE (4 * MiB)
 
-#define DAFB_RESET  0x200
-#define DAFB_LUT0x213
+#define DAFB_MODE_SENSE 0x1c
+#define DAFB_RESET  0x200
+#define DAFB_LUT0x213
+
+
+/*
+ * Quadra sense codes taken from Apple Technical Note HW26:
+ * "Macintosh Quadra Built-In Video". The sense codes and
+ * extended sense codes have different meanings:
+ *
+ * Sense:
+ *bit 2: SENSE2 (pin 10)
+ *bit 1: SENSE1 (pin 7)
+ *bit 0: SENSE0 (pin 4)
+ *
+ * 0 = pin tied to ground
+ * 1 = pin unconnected
+ *
+ * Extended Sense:
+ *bit 2: pins 4-10
+ *bit 1: pins 10-7
+ *bit 0: pins 7-4
+ *
+ * 0 = pins tied together
+ * 1 = pins unconnected
+ *
+ * Reads from the sense register appear to be active low, i.e. a 1 indicates
+ * that the pin is tied to ground, a 0 indicates the pin is disconnected.
+ *
+ * Writes to the sense register appear to activate pulldowns i.e. a 1 enables
+ * a pulldown on a particular pin.
+ *
+ * The MacOS toolbox appears to use a series of reads and writes to first
+ * determine if extended sense is to be used, and then check which pins are
+ * tied together in order to determine the display type.
+ */
+
+typedef struct MacFbSense {
+uint8_t type;
+uint8_t sense;
+uint8_t ext_sense;
+} MacFbSense;
+
+static MacFbSense macfb_sense_table[] = {
+{ MACFB_DISPLAY_APPLE_21_COLOR, 0x0, 0 },
+{ MACFB_DISPLAY_APPLE_PORTRAIT, 0x1, 0 },
+{ MACFB_DISPLAY_APPLE_12_RGB, 0x2, 0 },
+{ MACFB_DISPLAY_APPLE_2PAGE_MONO, 0x3, 0 },
+{ MACFB_DISPLAY_NTSC_UNDERSCAN, 0x4, 0 },
+{ MACFB_DISPLAY_NTSC_OVERSCAN, 0x4, 0 },
+{ MACFB_DISPLAY_APPLE_12_MONO, 0x6, 0 },
+{ MACFB_DISPLAY_APPLE_13_RGB, 0x6, 0 },
+{ MACFB_DISPLAY_16_COLOR, 0x7, 0x3 },
+{ MACFB_DISPLAY_PAL1_UNDERSCAN, 0x7, 0x0 },
+{ MACFB_DISPLAY_PAL1_OVERSCAN, 0x7, 0x0 },
+{ MACFB_DISPLAY_PAL2_UNDERSCAN, 0x7, 0x6 },
+{ MACFB_DISPLAY_PAL2_OVERSCAN, 0x7, 0x6 },
+{ MACFB_DISPLAY_VGA, 0x7, 0x5 },
+{ MACFB_DISPLAY_SVGA, 0x7, 0x5 },
+};
 
 
 typedef void macfb_draw_line_func(MacfbState *s, uint8_t *d, uint32_t addr,
@@ -253,6 +311,50 @@ static void macfb_invalidate_display(void *opaque)
 memory_region_set_dirty(>mem_vram, 0, MACFB_VRAM_SIZE);
 }
 
+static uint32_t macfb_sense_read(MacfbState *s)
+{
+MacFbSense *macfb_sense;
+uint8_t sense;
+
+macfb_sense = _sense_table[MACFB_DISPLAY_VGA];
+if (macfb_sense->sense == 0x7) {
+/* Extended sense */
+sense = 0;
+if (!(macfb_sense->ext_sense & 1)) {
+/* Pins 7-4 together */
+if (~s->sense & 3) {
+sense = (~s->sense & 7) | 3;
+}
+}
+if (!(macfb_sense->ext_sense & 2)) {
+/* Pins 10-7 together */
+if (~s->sense & 6) {
+sense = (~s->sense & 7) | 6;
+}
+}
+if (!(macfb_sense->ext_sense & 4)) {
+/* Pins 4-10 together */
+if (~s->sense & 5) {
+sense = (~s->sense & 7) | 5;
+}
+}
+} else {
+/* Normal sense */
+sense = (~macfb_sense->sense & 7) | (~s->sense & 7);
+}
+
+trace_macfb_sense_read(sense);
+return sense;
+}
+
+static void macfb_sense_write(MacfbState *s, uint32_t val)
+{
+s->sense = val;
+
+trace_macfb_sense_write(val);
+return;
+}
+
 static void macfb_update_display(void *opaque)
 {
 MacfbState *s = opaque;
@@ -290,8 +392,15 @@ static uint64_t macfb_ctrl_read(void *opaque,
 hwaddr addr,
 unsigned int size)
 {
+MacfbState *s = opaque;
 uint64_t val = 0;
 
+switch (addr) {
+case DAFB_MODE_SENSE:
+val = macfb_sense_read(s);
+break;
+}
+
 trace_macfb_ctrl_read(addr, val, size);
 return val;
 }
@@ -303,6 +412,9 @@ static void macfb_ctrl_write(void *opaque,
 {
 MacfbState *s = opaque;
 switch (addr) {
+case DAFB_MODE_SENSE:
+macfb_sense_write(s, val);
+break;
 case DAFB_RESET:
 s->palette_current = 0;
 

[PATCH v2 07/12] macfb: add qdev property to specify display type

[Mark Cave-Ayland]

Since the available resolutions and colour depths are determined by the attached
display type, add a qdev property to allow the display type to be specified.

The main resolutions of interest are high resolution 1152x870 with 8-bit colour
and SVGA resolution up to 800x600 with 32-bit colour so update the q800 machine
to allow high resolution mode if specified and otherwise fall back to SVGA.

Signed-off-by: Mark Cave-Ayland 
Reviewed-by: Philippe Mathieu-Daudé 
Reviewed-by: Laurent Vivier 
---
 hw/display/macfb.c | 7 ++-
 hw/m68k/q800.c | 5 +
 include/hw/display/macfb.h | 1 +
 3 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/hw/display/macfb.c b/hw/display/macfb.c
index 6e485d7aef..f98bcdec2d 100644
--- a/hw/display/macfb.c
+++ b/hw/display/macfb.c
@@ -316,7 +316,8 @@ static uint32_t macfb_sense_read(MacfbState *s)
 MacFbSense *macfb_sense;
 uint8_t sense;
 
-macfb_sense = _sense_table[MACFB_DISPLAY_VGA];
+assert(s->type < ARRAY_SIZE(macfb_sense_table));
+macfb_sense = _sense_table[s->type];
 if (macfb_sense->sense == 0x7) {
 /* Extended sense */
 sense = 0;
@@ -544,6 +545,8 @@ static Property macfb_sysbus_properties[] = {
 DEFINE_PROP_UINT32("width", MacfbSysBusState, macfb.width, 640),
 DEFINE_PROP_UINT32("height", MacfbSysBusState, macfb.height, 480),
 DEFINE_PROP_UINT8("depth", MacfbSysBusState, macfb.depth, 8),
+DEFINE_PROP_UINT8("display", MacfbSysBusState, macfb.type,
+  MACFB_DISPLAY_VGA),
 DEFINE_PROP_END_OF_LIST(),
 };
 
@@ -551,6 +554,8 @@ static Property macfb_nubus_properties[] = {
 DEFINE_PROP_UINT32("width", MacfbNubusState, macfb.width, 640),
 DEFINE_PROP_UINT32("height", MacfbNubusState, macfb.height, 480),
 DEFINE_PROP_UINT8("depth", MacfbNubusState, macfb.depth, 8),
+DEFINE_PROP_UINT8("display", MacfbNubusState, macfb.type,
+  MACFB_DISPLAY_VGA),
 DEFINE_PROP_END_OF_LIST(),
 };
 
diff --git a/hw/m68k/q800.c b/hw/m68k/q800.c
index 09b3366024..5223b880bc 100644
--- a/hw/m68k/q800.c
+++ b/hw/m68k/q800.c
@@ -421,6 +421,11 @@ static void q800_init(MachineState *machine)
 qdev_prop_set_uint32(dev, "width", graphic_width);
 qdev_prop_set_uint32(dev, "height", graphic_height);
 qdev_prop_set_uint8(dev, "depth", graphic_depth);
+if (graphic_width == 1152 && graphic_height == 870 && graphic_depth == 8) {
+qdev_prop_set_uint8(dev, "display", MACFB_DISPLAY_APPLE_21_COLOR);
+} else {
+qdev_prop_set_uint8(dev, "display", MACFB_DISPLAY_VGA);
+}
 qdev_realize_and_unref(dev, BUS(nubus), _fatal);
 
 cs = CPU(cpu);
diff --git a/include/hw/display/macfb.h b/include/hw/display/macfb.h
index febf4ce0e8..e95a97ebdc 100644
--- a/include/hw/display/macfb.h
+++ b/include/hw/display/macfb.h
@@ -46,6 +46,7 @@ typedef struct MacfbState {
 uint8_t color_palette[256 * 3];
 uint32_t width, height; /* in pixels */
 uint8_t depth;
+uint8_t type;
 
 uint32_t sense;
 } MacfbState;
-- 
2.20.1

[PATCH 12/13] python: Add iotest linters to test suite

[John Snow]

Run mypy and pylint on the iotests files directly from the Python CI
test infrastructure. This ensures that any accidental breakages to the
qemu.[qmp|aqmp|machine|utils] packages will be caught by that test
suite.

It also ensures that these linters are run with well-known versions and
test against a wide variety of python versions, which helps to find
accidental cross-version python compatibility issues.

Signed-off-by: John Snow 
---
 python/tests/iotests-mypy.sh   | 4 
 python/tests/iotests-pylint.sh | 4 
 2 files changed, 8 insertions(+)
 create mode 100755 python/tests/iotests-mypy.sh
 create mode 100755 python/tests/iotests-pylint.sh

diff --git a/python/tests/iotests-mypy.sh b/python/tests/iotests-mypy.sh
new file mode 100755
index 000..ee764708199
--- /dev/null
+++ b/python/tests/iotests-mypy.sh
@@ -0,0 +1,4 @@
+#!/bin/sh -e
+
+cd ../tests/qemu-iotests/
+python3 -m linters --mypy
diff --git a/python/tests/iotests-pylint.sh b/python/tests/iotests-pylint.sh
new file mode 100755
index 000..4cae03424b4
--- /dev/null
+++ b/python/tests/iotests-pylint.sh
@@ -0,0 +1,4 @@
+#!/bin/sh -e
+
+cd ../tests/qemu-iotests/
+python3 -m linters --pylint
-- 
2.31.1

[PATCH v2 01/12] macfb: handle errors that occur during realize

[Mark Cave-Ayland]

Make sure any errors that occur within the macfb realize chain are detected
and handled correctly to prevent crashes and to ensure that error messages are
reported back to the user.

Signed-off-by: Mark Cave-Ayland 
Reviewed-by: BALATON Zoltan 
Reviewed-by: Laurent Vivier 
---
 hw/display/macfb.c | 23 +--
 1 file changed, 17 insertions(+), 6 deletions(-)

diff --git a/hw/display/macfb.c b/hw/display/macfb.c
index 76808b69cc..2ec25c5d6f 100644
--- a/hw/display/macfb.c
+++ b/hw/display/macfb.c
@@ -343,14 +343,14 @@ static const GraphicHwOps macfb_ops = {
 .gfx_update = macfb_update_display,
 };
 
-static void macfb_common_realize(DeviceState *dev, MacfbState *s, Error **errp)
+static bool macfb_common_realize(DeviceState *dev, MacfbState *s, Error **errp)
 {
 DisplaySurface *surface;
 
 if (s->depth != 1 && s->depth != 2 && s->depth != 4 && s->depth != 8 &&
 s->depth != 16 && s->depth != 24) {
 error_setg(errp, "unknown guest depth %d", s->depth);
-return;
+return false;
 }
 
 s->con = graphic_console_init(dev, 0, _ops, s);
@@ -359,18 +359,20 @@ static void macfb_common_realize(DeviceState *dev, 
MacfbState *s, Error **errp)
 if (surface_bits_per_pixel(surface) != 32) {
 error_setg(errp, "unknown host depth %d",
surface_bits_per_pixel(surface));
-return;
+return false;
 }
 
 memory_region_init_io(>mem_ctrl, OBJECT(dev), _ctrl_ops, s,
   "macfb-ctrl", 0x1000);
 
 memory_region_init_ram_nomigrate(>mem_vram, OBJECT(s), "macfb-vram",
- MACFB_VRAM_SIZE, errp);
+ MACFB_VRAM_SIZE, _abort);
 s->vram = memory_region_get_ram_ptr(>mem_vram);
 s->vram_bit_mask = MACFB_VRAM_SIZE - 1;
 vmstate_register_ram(>mem_vram, dev);
 memory_region_set_coalescing(>mem_vram);
+
+return true;
 }
 
 static void macfb_sysbus_realize(DeviceState *dev, Error **errp)
@@ -378,7 +380,10 @@ static void macfb_sysbus_realize(DeviceState *dev, Error 
**errp)
 MacfbSysBusState *s = MACFB(dev);
 MacfbState *ms = >macfb;
 
-macfb_common_realize(dev, ms, errp);
+if (!macfb_common_realize(dev, ms, errp)) {
+return;
+}
+
 sysbus_init_mmio(SYS_BUS_DEVICE(s), >mem_ctrl);
 sysbus_init_mmio(SYS_BUS_DEVICE(s), >mem_vram);
 }
@@ -391,8 +396,14 @@ static void macfb_nubus_realize(DeviceState *dev, Error 
**errp)
 MacfbState *ms = >macfb;
 
 ndc->parent_realize(dev, errp);
+if (*errp) {
+return;
+}
+
+if (!macfb_common_realize(dev, ms, errp)) {
+return;
+}
 
-macfb_common_realize(dev, ms, errp);
 memory_region_add_subregion(>slot_mem, DAFB_BASE, >mem_ctrl);
 memory_region_add_subregion(>slot_mem, VIDEO_BASE, >mem_vram);
 }
-- 
2.20.1

[PATCH v2 05/12] macfb: add trace events for reading and writing the control registers

[Mark Cave-Ayland]

Signed-off-by: Mark Cave-Ayland 
Reviewed-by: Philippe Mathieu-Daudé 
Reviewed-by: Laurent Vivier 
---
 hw/display/macfb.c  | 8 +++-
 hw/display/trace-events | 4 
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/hw/display/macfb.c b/hw/display/macfb.c
index f88f5a6523..1128a51c98 100644
--- a/hw/display/macfb.c
+++ b/hw/display/macfb.c
@@ -20,6 +20,7 @@
 #include "qapi/error.h"
 #include "hw/qdev-properties.h"
 #include "migration/vmstate.h"
+#include "trace.h"
 
 #define VIDEO_BASE 0x1000
 #define DAFB_BASE  0x0080
@@ -289,7 +290,10 @@ static uint64_t macfb_ctrl_read(void *opaque,
 hwaddr addr,
 unsigned int size)
 {
-return 0;
+uint64_t val = 0;
+
+trace_macfb_ctrl_read(addr, val, size);
+return val;
 }
 
 static void macfb_ctrl_write(void *opaque,
@@ -311,6 +315,8 @@ static void macfb_ctrl_write(void *opaque,
 }
 break;
 }
+
+trace_macfb_ctrl_write(addr, val, size);
 }
 
 static const MemoryRegionOps macfb_ctrl_ops = {
diff --git a/hw/display/trace-events b/hw/display/trace-events
index f03f6655bc..6c460aaa4c 100644
--- a/hw/display/trace-events
+++ b/hw/display/trace-events
@@ -167,3 +167,7 @@ sm501_disp_ctrl_read(uint32_t addr, uint32_t val) 
"addr=0x%x, val=0x%x"
 sm501_disp_ctrl_write(uint32_t addr, uint32_t val) "addr=0x%x, val=0x%x"
 sm501_2d_engine_read(uint32_t addr, uint32_t val) "addr=0x%x, val=0x%x"
 sm501_2d_engine_write(uint32_t addr, uint32_t val) "addr=0x%x, val=0x%x"
+
+# macfb.c
+macfb_ctrl_read(uint64_t addr, uint64_t value, unsigned int size) "addr 
0x%"PRIx64 " value 0x%"PRIx64 " size %d"
+macfb_ctrl_write(uint64_t addr, uint64_t value, unsigned int size) "addr 
0x%"PRIx64 " value 0x%"PRIx64 " size %d"
-- 
2.20.1

[PATCH v2 02/12] macfb: fix invalid object reference in macfb_common_realize()

[Mark Cave-Ayland]

During realize memory_region_init_ram_nomigrate() is used to initialise the RAM
memory region used for the framebuffer but the owner object reference is
incorrect since MacFbState is a typedef and not a QOM type.

Change the memory region owner to be the corresponding DeviceState to fix the
issue and prevent random crashes during macfb_common_realize().

Signed-off-by: Mark Cave-Ayland 
Fixes: 8ac919a0654 ("hw/m68k: add Nubus macfb video card")
Reviewed-by: BALATON Zoltan 
Reviewed-by: Philippe Mathieu-Daudé 
Reviewed-by: Laurent Vivier 
---
 hw/display/macfb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/display/macfb.c b/hw/display/macfb.c
index 2ec25c5d6f..b363bab889 100644
--- a/hw/display/macfb.c
+++ b/hw/display/macfb.c
@@ -365,7 +365,7 @@ static bool macfb_common_realize(DeviceState *dev, 
MacfbState *s, Error **errp)
 memory_region_init_io(>mem_ctrl, OBJECT(dev), _ctrl_ops, s,
   "macfb-ctrl", 0x1000);
 
-memory_region_init_ram_nomigrate(>mem_vram, OBJECT(s), "macfb-vram",
+memory_region_init_ram_nomigrate(>mem_vram, OBJECT(dev), "macfb-vram",
  MACFB_VRAM_SIZE, _abort);
 s->vram = memory_region_get_ram_ptr(>mem_vram);
 s->vram_bit_mask = MACFB_VRAM_SIZE - 1;
-- 
2.20.1

[PATCH 10/13] iotests/linters: Add entry point for linting via Python CI

[John Snow]

We need at least a tiny little shim here to join test file discovery
with test invocation. This logic could conceivably be hosted somewhere
in python/, but I felt it was strictly the least-rude thing to keep the
test logic here in iotests/, even if this small function isn't itself an
iotest.

Note that we don't actually even need the executable bit here, we'll be
relying on the ability to run this module as a script using Python CLI
arguments. No chance it gets misunderstood as an actual iotest that way.

(It's named, not in tests/, doesn't have the execute bit, and doesn't
have an execution shebang.)

Signed-off-by: John Snow 

---

(1) I think that the test file discovery logic and skip list belong together,
and that those items belong in iotests/. I think they also belong in
whichever directory pylintrc and mypy.ini are in, also in iotests/.

(2) Moving this logic into python/tests/ is challenging because I'd have
to import iotests code from elsewhere in the source tree, which just
inverts an existing problem I have been trying to rid us of --
needing to muck around with PYTHONPATH or sys.path hacking in python
scripts. I'm keen to avoid this.

(3) If we moved all python tests into tests/ and gave them *.py
extensions, we wouldn't even need the test discovery functions
anymore, and all of linters.py could be removed entirely, including
this execution shim. We could rely on mypy/pylint's own file
discovery mechanisms at that point. More work than I'm up for with
just this series, but I could be coaxed into doing it if there was
some promise of not rejecting all that busywork ;)

Signed-off-by: John Snow 
---
 tests/qemu-iotests/linters.py | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/tests/qemu-iotests/linters.py b/tests/qemu-iotests/linters.py
index f6a2dc139fd..191df173064 100644
--- a/tests/qemu-iotests/linters.py
+++ b/tests/qemu-iotests/linters.py
@@ -16,6 +16,7 @@
 import os
 import re
 import subprocess
+import sys
 from typing import List, Mapping, Optional
 
 
@@ -81,3 +82,20 @@ def run_linter(
 
 return p.returncode
 
+
+def main() -> int:
+"""
+Used by the Python CI system as an entry point to run these linters.
+"""
+files = get_test_files()
+
+if sys.argv[1] == '--pylint':
+return run_linter('pylint', files)
+elif sys.argv[1] == '--mypy':
+return run_linter('mypy', files)
+
+raise ValueError(f"Unrecognized argument(s): '{sys.argv[1:]}'")
+
+
+if __name__ == '__main__':
+sys.exit(main())
-- 
2.31.1

Re: [PATCH 09/13] virtiofsd: Specify size of notification buffer using config space

[Vivek Goyal]

On Mon, Oct 04, 2021 at 03:33:47PM +0100, Stefan Hajnoczi wrote:
> On Thu, Sep 30, 2021 at 11:30:33AM -0400, Vivek Goyal wrote:
> > Daemon specifies size of notification buffer needed and that should be
> > done using config space.
> > 
> > Only ->notify_buf_size value of config space comes from daemon. Rest of
> > it is filled by qemu device emulation code.
> > 
> > Signed-off-by: Vivek Goyal 
> > Signed-off-by: Ioannis Angelakopoulos 
> > ---
> >  hw/virtio/vhost-user-fs.c  | 27 +++
> >  include/hw/virtio/vhost-user-fs.h  |  2 ++
> >  include/standard-headers/linux/virtio_fs.h |  2 ++
> >  tools/virtiofsd/fuse_virtio.c  | 31 ++
> >  4 files changed, 62 insertions(+)
> > 
> > diff --git a/hw/virtio/vhost-user-fs.c b/hw/virtio/vhost-user-fs.c
> > index 6bafcf0243..68a94708b4 100644
> > --- a/hw/virtio/vhost-user-fs.c
> > +++ b/hw/virtio/vhost-user-fs.c
> > @@ -36,15 +36,41 @@ static const int user_feature_bits[] = {
> >  VHOST_INVALID_FEATURE_BIT
> >  };
> >  
> > +static int vhost_user_fs_handle_config_change(struct vhost_dev *dev)
> > +{
> > +return 0;
> > +}
> > +
> > +const VhostDevConfigOps fs_ops = {
> > +.vhost_dev_config_notifier = vhost_user_fs_handle_config_change,
> > +};
> > +
> >  static void vuf_get_config(VirtIODevice *vdev, uint8_t *config)
> >  {
> >  VHostUserFS *fs = VHOST_USER_FS(vdev);
> >  struct virtio_fs_config fscfg = {};
> > +Error *local_err = NULL;
> > +int ret;
> > +
> > +/*
> > + * As of now we only get notification buffer size from device. And 
> > that's
> > + * needed only if notification queue is enabled.
> > + */
> > +if (fs->notify_enabled) {
> > +ret = vhost_dev_get_config(>vhost_dev, (uint8_t *)>fscfg,
> > +   sizeof(struct virtio_fs_config),
> > +   _err);
> > +if (ret) {
> > +error_report_err(local_err);
> > +return;
> > +}
> > +}
> >  
> >  memcpy((char *)fscfg.tag, fs->conf.tag,
> > MIN(strlen(fs->conf.tag) + 1, sizeof(fscfg.tag)));
> >  
> >  virtio_stl_p(vdev, _request_queues, 
> > fs->conf.num_request_queues);
> > +virtio_stl_p(vdev, _buf_size, fs->fscfg.notify_buf_size);
> >  
> >  memcpy(config, , sizeof(fscfg));
> >  }
> > @@ -316,6 +342,7 @@ static void vuf_device_realize(DeviceState *dev, Error 
> > **errp)
> >  sizeof(struct virtio_fs_config));
> >  
> >  vuf_create_vqs(vdev, true);
> > +vhost_dev_set_config_notifier(>vhost_dev, _ops);
> >  ret = vhost_dev_init(>vhost_dev, >vhost_user,
> >   VHOST_BACKEND_TYPE_USER, 0, errp);
> >  if (ret < 0) {
> > diff --git a/include/hw/virtio/vhost-user-fs.h 
> > b/include/hw/virtio/vhost-user-fs.h
> > index 95dc0dd402..3b114ee260 100644
> > --- a/include/hw/virtio/vhost-user-fs.h
> > +++ b/include/hw/virtio/vhost-user-fs.h
> > @@ -14,6 +14,7 @@
> >  #ifndef _QEMU_VHOST_USER_FS_H
> >  #define _QEMU_VHOST_USER_FS_H
> >  
> > +#include "standard-headers/linux/virtio_fs.h"
> >  #include "hw/virtio/virtio.h"
> >  #include "hw/virtio/vhost.h"
> >  #include "hw/virtio/vhost-user.h"
> > @@ -37,6 +38,7 @@ struct VHostUserFS {
> >  struct vhost_virtqueue *vhost_vqs;
> >  struct vhost_dev vhost_dev;
> >  VhostUserState vhost_user;
> > +struct virtio_fs_config fscfg;
> >  VirtQueue **req_vqs;
> >  VirtQueue *hiprio_vq;
> >  VirtQueue *notification_vq;
> > diff --git a/include/standard-headers/linux/virtio_fs.h 
> > b/include/standard-headers/linux/virtio_fs.h
> > index b7f015186e..867d18acf6 100644
> > --- a/include/standard-headers/linux/virtio_fs.h
> > +++ b/include/standard-headers/linux/virtio_fs.h
> > @@ -17,6 +17,8 @@ struct virtio_fs_config {
> >  
> > /* Number of request queues */
> > uint32_t num_request_queues;
> > +   /* Size of notification buffer */
> > +   uint32_t notify_buf_size;
> >  } QEMU_PACKED;
> >  
> >  /* For the id field in virtio_pci_shm_cap */
> 
> Please put all the include/standard-headers/linux/ changes into a single
> commit that imports these changes from linux.git. Changes to this header
> shouldn't be hand-written, use scripts/update-linux-headers.sh instead.

Will do. These changes are not in kernel yet. So will use
update-linux-headers.sh when changes are upstreamed. But agreed,
that this change should be in separate patch even for review
purpose (before it is merged in kernel).

> 
> > diff --git a/tools/virtiofsd/fuse_virtio.c b/tools/virtiofsd/fuse_virtio.c
> > index f5b87a508a..3b720c5d4a 100644
> > --- a/tools/virtiofsd/fuse_virtio.c
> > +++ b/tools/virtiofsd/fuse_virtio.c
> > @@ -856,6 +856,35 @@ static bool fv_queue_order(VuDev *dev, int qidx)
> >  return false;
> >  }
> >  
> > +static uint64_t fv_get_protocol_features(VuDev *dev)
> > +{
> > +return 1ull << VHOST_USER_PROTOCOL_F_CONFIG;
> > +}
> > +
> > +static int 

Re: [PATCH v6 10/10] ACPI ERST: step 6 of bios-tables-test

[Eric DeVolder]

On 9/21/21 6:24 AM, Igor Mammedov wrote:

On Thu,  5 Aug 2021 18:30:39 -0400
Eric DeVolder  wrote:


Following the guidelines in tests/qtest/bios-tables-test.c, this
is step 6, the re-generated ACPI tables binary blobs.



commit message should include ASL diff for new/changed content

for example see commit:
1aaef7d8092803 acpi: unit-test: Update WAET ACPI Table expected binaries


done





Signed-off-by: Eric DeVolder 
---
  tests/data/acpi/microvm/ERST.pcie   | Bin 0 -> 912 bytes
  tests/data/acpi/pc/DSDT | Bin 6002 -> 6009 bytes
  tests/data/acpi/pc/ERST | Bin 0 -> 912 bytes
  tests/data/acpi/q35/DSDT| Bin 8289 -> 8306 bytes
  tests/data/acpi/q35/ERST| Bin 0 -> 912 bytes
  tests/qtest/bios-tables-test-allowed-diff.h |   6 --
  6 files changed, 6 deletions(-)
  create mode 100644 tests/data/acpi/microvm/ERST.pcie

diff --git a/tests/data/acpi/microvm/ERST.pcie 
b/tests/data/acpi/microvm/ERST.pcie
new file mode 100644
index 
..d9a2b3211ab5893a50751ad52be3782579e367f2
GIT binary patch
literal 912
zcmaKpO%8%E5QPUQ|KVrvh9h_c12J)@5f?5!k_Ygv*jGA8UW7?#`}+D#XXyDpKHiZ?
z@anI_W$gOrZRl(SB7!yMqx}#E4EC=}m^g_!0^0`kEl)DOuIXM6D@@*xq*8vyqH
z)b0KTlmlgmH~xt7vG=QZp?+M@&@5ljF8

diff --git a/tests/data/acpi/pc/ERST b/tests/data/acpi/pc/ERST
index 
e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..f24fadd345c798ee5c17cdb66e0e1703bd1b2f26
 100644
GIT binary patch
literal 912
zcmaKpOAdlC6h#XZC=fn#CoF*_7>J28jW}>wF2KFG3zs9lTPTnl;U#=7r>E_sr(1u2
z21ttC4TZ!l<{$N9cc#e2SmmnSn
O1||j(wg6|p5C#C(xDBxY

delta 42
xcmez5@X&$FCDJ28jW}>wF2KFG3zs9lTPTnl;U#=7r>E_sr(1u2
z21

Re: [PATCH v6 05/10] ACPI ERST: support for ACPI ERST feature

[Eric DeVolder]

Igor, thanks for the close examination. Inline responses below.
eric

On 9/21/21 10:30 AM, Igor Mammedov wrote:

On Thu,  5 Aug 2021 18:30:34 -0400
Eric DeVolder  wrote:


This implements a PCI device for ACPI ERST. This implements the
non-NVRAM "mode" of operation for ERST as it is supported by
Linux and Windows.

Signed-off-by: Eric DeVolder 
---
  hw/acpi/erst.c   | 750 +++
  hw/acpi/meson.build  |   1 +
  hw/acpi/trace-events |  15 ++
  3 files changed, 766 insertions(+)
  create mode 100644 hw/acpi/erst.c

diff --git a/hw/acpi/erst.c b/hw/acpi/erst.c
new file mode 100644
index 000..eb4ab34
--- /dev/null
+++ b/hw/acpi/erst.c
@@ -0,0 +1,750 @@
+/*
+ * ACPI Error Record Serialization Table, ERST, Implementation
+ *
+ * ACPI ERST introduced in ACPI 4.0, June 16, 2009.
+ * ACPI Platform Error Interfaces : Error Serialization
+ *
+ * Copyright (c) 2021 Oracle and/or its affiliates.
+ *
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ */
+
+#include 
+#include 
+#include 
+
+#include "qemu/osdep.h"
+#include "qapi/error.h"
+#include "hw/qdev-core.h"
+#include "exec/memory.h"
+#include "qom/object.h"
+#include "hw/pci/pci.h"
+#include "qom/object_interfaces.h"
+#include "qemu/error-report.h"
+#include "migration/vmstate.h"
+#include "hw/qdev-properties.h"
+#include "hw/acpi/acpi.h"
+#include "hw/acpi/acpi-defs.h"
+#include "hw/acpi/aml-build.h"
+#include "hw/acpi/bios-linker-loader.h"
+#include "exec/address-spaces.h"
+#include "sysemu/hostmem.h"
+#include "hw/acpi/erst.h"
+#include "trace.h"
+
+/* ACPI 4.0: Table 17-16 Serialization Actions */
+#define ACTION_BEGIN_WRITE_OPERATION 0x0
+#define ACTION_BEGIN_READ_OPERATION  0x1
+#define ACTION_BEGIN_CLEAR_OPERATION 0x2
+#define ACTION_END_OPERATION 0x3
+#define ACTION_SET_RECORD_OFFSET 0x4
+#define ACTION_EXECUTE_OPERATION 0x5
+#define ACTION_CHECK_BUSY_STATUS 0x6
+#define ACTION_GET_COMMAND_STATUS0x7
+#define ACTION_GET_RECORD_IDENTIFIER 0x8
+#define ACTION_SET_RECORD_IDENTIFIER 0x9
+#define ACTION_GET_RECORD_COUNT  0xA
+#define ACTION_BEGIN_DUMMY_WRITE_OPERATION   0xB
+#define ACTION_RESERVED  0xC
+#define ACTION_GET_ERROR_LOG_ADDRESS_RANGE   0xD
+#define ACTION_GET_ERROR_LOG_ADDRESS_LENGTH  0xE
+#define ACTION_GET_ERROR_LOG_ADDRESS_RANGE_ATTRIBUTES 0xF
+#define ACTION_GET_EXECUTE_OPERATION_TIMINGS 0x10
+
+/* ACPI 4.0: Table 17-17 Command Status Definitions */
+#define STATUS_SUCCESS0x00
+#define STATUS_NOT_ENOUGH_SPACE   0x01
+#define STATUS_HARDWARE_NOT_AVAILABLE 0x02
+#define STATUS_FAILED 0x03
+#define STATUS_RECORD_STORE_EMPTY 0x04
+#define STATUS_RECORD_NOT_FOUND   0x05
+
+
+/* UEFI 2.1: Appendix N Common Platform Error Record */
+#define UEFI_CPER_RECORD_MIN_SIZE 128U
+#define UEFI_CPER_RECORD_LENGTH_OFFSET 20U
+#define UEFI_CPER_RECORD_ID_OFFSET 96U
+#define IS_UEFI_CPER_RECORD(ptr) \
+(((ptr)[0] == 'C') && \
+ ((ptr)[1] == 'P') && \
+ ((ptr)[2] == 'E') && \
+ ((ptr)[3] == 'R'))
+#define THE_UEFI_CPER_RECORD_ID(ptr) \
+(*(uint64_t *)(&(ptr)[UEFI_CPER_RECORD_ID_OFFSET]))
+
+/*
+ * This implementation is an ACTION (cmd) and VALUE (data)
+ * interface consisting of just two 64-bit registers.
+ */
+#define ERST_REG_SIZE (16UL)
+#define ERST_ACTION_OFFSET (0UL) /* action (cmd) */
+#define ERST_VALUE_OFFSET  (8UL) /* argument/value (data) */
+
+/*
+ * ERST_RECORD_SIZE is the buffer size for exchanging ERST
+ * record contents. Thus, it defines the maximum record size.
+ * As this is mapped through a PCI BAR, it must be a power of
+ * two and larger than UEFI_CPER_RECORD_MIN_SIZE.
+ * The backing storage is divided into fixed size "slots",
+ * each ERST_RECORD_SIZE in length, and each "slot"
+ * storing a single record. No attempt at optimizing storage
+ * through compression, compaction, etc is attempted.
+ * NOTE that slot 0 is reserved for the backing storage header.
+ * Depending upon the size of the backing storage, additional
+ * slots will be part of the slot 0 header in order to account
+ * for a record_id for each available remaining slot.
+ */
+/* 8KiB records, not too small, not too big */
+#define ERST_RECORD_SIZE (8192UL)
+
+#define ACPI_ERST_MEMDEV_PROP "memdev"
+
+/*
+ * From the ACPI ERST spec sections:
+ * A record id of all 0s is used to indicate
+ * 'unspecified' record id.
+ * A record id of all 1s is used to indicate
+ * empty or end.
+ */
+#define ERST_UNSPECIFIED_RECORD_ID (0UL)
+#define ERST_EMPTY_END_RECORD_ID (~0UL)
+#define ERST_EXECUTE_OPERATION_MAGIC 0x9CUL
+#define ERST_IS_VALID_RECORD_ID(rid) \
+((rid != ERST_UNSPECIFIED_RECORD_ID) && \
+ (rid != ERST_EMPTY_END_RECORD_ID))
+
+typedef struct erst_storage_header_s {



+#define ERST_STORE_MAGIC 0x524F545354535245UL


move it out of structure definition,
also where value comes from? (perhaps something starting
with 

[PATCH 13/13] iotests: [RFC] drop iotest 297

[John Snow]

(This is highlighting a what-if, which might make it clear why any
special infrastructure is still required at all. It's not intended to
actually be merged at this step -- running JUST the iotest linters from
e.g. 'make check' is not yet accommodated, so there's no suitable
replacement for 297 for block test authors.)

Drop 297. As a consequence, we no longer need to pass an environment
variable to the mypy/pylint invocations, so that can be dropped. We also
now no longer need to hide output-except-on-error, so that can be
dropped as well.

The only thing that necessitates any special running logic anymore is
the skip list and the python-test-detection code. Without those, we
could easily codify the tests as simply:

[pylint|mypy] *.py tests/*.py

... and drop this entire file. We're not quite there yet, though.

Signed-off-by: John Snow 
---
 tests/qemu-iotests/297| 52 ---
 tests/qemu-iotests/297.out|  2 --
 tests/qemu-iotests/linters.py | 20 ++
 3 files changed, 2 insertions(+), 72 deletions(-)
 delete mode 100755 tests/qemu-iotests/297
 delete mode 100644 tests/qemu-iotests/297.out

diff --git a/tests/qemu-iotests/297 b/tests/qemu-iotests/297
deleted file mode 100755
index f79c80216bf..000
--- a/tests/qemu-iotests/297
+++ /dev/null
@@ -1,52 +0,0 @@
-#!/usr/bin/env python3
-# group: meta
-#
-# Copyright (C) 2020 Red Hat, Inc.
-#
-# This program is free software; you can redistribute it and/or modify
-# it under the terms of the GNU General Public License as published by
-# the Free Software Foundation; either version 2 of the License, or
-# (at your option) any later version.
-#
-# This program is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-# GNU General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License
-# along with this program.  If not, see .
-
-import os
-import shutil
-import sys
-
-import iotests
-import linters
-
-
-# Looking for the list of files to exclude from linting? See linters.py.
-
-
-def main() -> None:
-for linter in ('pylint-3', 'mypy'):
-if shutil.which(linter) is None:
-iotests.notrun(f'{linter} not found')
-
-files = linters.get_test_files()
-
-iotests.logger.debug('Files to be checked:')
-iotests.logger.debug(', '.join(sorted(files)))
-
-env = os.environ.copy()
-env['MYPYPATH'] = env['PYTHONPATH']
-
-print('=== pylint ===')
-sys.stdout.flush()
-linters.run_linter('pylint', files, env=env)
-
-print('=== mypy ===')
-sys.stdout.flush()
-linters.run_linter('mypy', files, env=env, suppress_output=True)
-
-
-iotests.script_main(main)
diff --git a/tests/qemu-iotests/297.out b/tests/qemu-iotests/297.out
deleted file mode 100644
index f2e1314d104..000
--- a/tests/qemu-iotests/297.out
+++ /dev/null
@@ -1,2 +0,0 @@
-=== pylint ===
-=== mypy ===
diff --git a/tests/qemu-iotests/linters.py b/tests/qemu-iotests/linters.py
index 83fcc5a960c..ca90604d8d9 100644
--- a/tests/qemu-iotests/linters.py
+++ b/tests/qemu-iotests/linters.py
@@ -17,7 +17,7 @@
 import re
 import subprocess
 import sys
-from typing import List, Mapping, Optional
+from typing import List
 
 
 # TODO: Empty this list!
@@ -55,31 +55,15 @@ def get_test_files() -> List[str]:
 return list(filter(is_python_file, check_tests))
 
 
-def run_linter(
-tool: str,
-args: List[str],
-env: Optional[Mapping[str, str]] = None,
-suppress_output: bool = False,
-) -> int:
+def run_linter(tool: str, args: List[str]) -> int:
 """
 Run a python-based linting tool.
-
-If suppress_output is True, capture stdout/stderr of the child
-process and only print that information back to stdout if the child
-process's return code was non-zero.
 """
 p = subprocess.run(
 ('python3', '-m', tool, *args),
-env=env,
 check=False,
-stdout=subprocess.PIPE if suppress_output else None,
-stderr=subprocess.STDOUT if suppress_output else None,
-universal_newlines=True,
 )
 
-if suppress_output and p.returncode != 0:
-print(p.stdout)
-
 return p.returncode
 
 
-- 
2.31.1

[PATCH 11/13] iotests/linters: Add workaround for mypy bug #9852

[John Snow]

This one is insidious: if you write an import as "from {namespace}
import {subpackage}" as mirror-top-perms (now) does, mypy will fail on
every-other invocation *if* the package being imported is a typed,
installed, namespace-scoped package.

Upsettingly, that's exactly what 'qemu.[aqmp|qmp|machine]' et al are in
the context of Python CI tests.

Now, I could just edit mirror-top-perms to avoid this invocation, but
since I tripped on a landmine, I might as well head it off at the pass
and make sure nobody else trips on that same landmine.

It seems to have something to do with the order in which files are
checked as well, meaning the random order in which set(os.listdir())
produces the list of files to test will cause problems intermittently
and not just strictly "every other run".

This will be fixed in mypy >= 0.920, which is not released yet. The
workaround for now is to disable incremental checking, which avoids the
issue.

Note: This workaround is not applied when running iotest 297 directly,
because the bug does not surface there! Given the nature of CI jobs not
starting with any stale cache to begin with, this really only has a
half-second impact on manual runs of the Python test suite when executed
directly by a developer on their local machine. The workaround may be
removed when the Python package requirements can stipulate mypy 0.920 or
higher, which can happen as soon as it is released. (Barring any
unforseen compatibility issues that 0.920 may bring with it.)


See also:
 https://github.com/python/mypy/issues/11010
 https://github.com/python/mypy/issues/9852

Signed-off-by: John Snow 
---
 tests/qemu-iotests/linters.py | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tests/qemu-iotests/linters.py b/tests/qemu-iotests/linters.py
index 191df173064..83fcc5a960c 100644
--- a/tests/qemu-iotests/linters.py
+++ b/tests/qemu-iotests/linters.py
@@ -92,7 +92,9 @@ def main() -> int:
 if sys.argv[1] == '--pylint':
 return run_linter('pylint', files)
 elif sys.argv[1] == '--mypy':
-return run_linter('mypy', files)
+# mypy bug #9852; disable incremental checking as a workaround.
+args = ['--no-incremental'] + files
+return run_linter('mypy', args)
 
 raise ValueError(f"Unrecognized argument(s): '{sys.argv[1:]}'")
 
-- 
2.31.1

[PATCH 06/13] iotests/297: Separate environment setup from test execution

[John Snow]

Move environment setup into main(), leaving pure test execution behind
in run_linters().

Signed-off-by: John Snow 
---
 tests/qemu-iotests/297 | 23 ++-
 1 file changed, 14 insertions(+), 9 deletions(-)

diff --git a/tests/qemu-iotests/297 b/tests/qemu-iotests/297
index f9fcb039e27..fcbab0631be 100755
--- a/tests/qemu-iotests/297
+++ b/tests/qemu-iotests/297
@@ -21,7 +21,7 @@ import re
 import shutil
 import subprocess
 import sys
-from typing import List
+from typing import List, Mapping, Optional
 
 import iotests
 
@@ -61,23 +61,20 @@ def get_test_files() -> List[str]:
 return list(filter(is_python_file, check_tests))
 
 
-def run_linters():
-files = get_test_files()
-
-iotests.logger.debug('Files to be checked:')
-iotests.logger.debug(', '.join(sorted(files)))
+def run_linters(
+files: List[str],
+env: Optional[Mapping[str, str]] = None,
+) -> None:
 
 print('=== pylint ===')
 sys.stdout.flush()
 
-env = os.environ.copy()
 subprocess.run(('python3', '-m', 'pylint', *files),
env=env, check=False)
 
 print('=== mypy ===')
 sys.stdout.flush()
 
-env['MYPYPATH'] = env['PYTHONPATH']
 p = subprocess.run((('python3', '-m', 'mypy', *files),
env=env,
check=False,
@@ -94,7 +91,15 @@ def main() -> None:
 if shutil.which(linter) is None:
 iotests.notrun(f'{linter} not found')
 
-run_linters()
+files = get_test_files()
+
+iotests.logger.debug('Files to be checked:')
+iotests.logger.debug(', '.join(sorted(files)))
+
+env = os.environ.copy()
+env['MYPYPATH'] = env['PYTHONPATH']
+
+run_linters(files, env=env)
 
 
 iotests.script_main(main)
-- 
2.31.1

[PATCH 07/13] iotests/297: Split run_linters apart into run_pylint and run_mypy

[John Snow]

Signed-off-by: John Snow 

---

Note, this patch really ought to be squashed with the next one, but I am
performing a move known as "Hedging my bets."
It's easier to squash than de-squash :)

Signed-off-by: John Snow 
---
 tests/qemu-iotests/297 | 19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/tests/qemu-iotests/297 b/tests/qemu-iotests/297
index fcbab0631be..91029dbb34e 100755
--- a/tests/qemu-iotests/297
+++ b/tests/qemu-iotests/297
@@ -61,20 +61,19 @@ def get_test_files() -> List[str]:
 return list(filter(is_python_file, check_tests))
 
 
-def run_linters(
+def run_pylint(
 files: List[str],
 env: Optional[Mapping[str, str]] = None,
 ) -> None:
 
-print('=== pylint ===')
-sys.stdout.flush()
-
 subprocess.run(('python3', '-m', 'pylint', *files),
env=env, check=False)
 
-print('=== mypy ===')
-sys.stdout.flush()
 
+def run_mypy(
+files: List[str],
+env: Optional[Mapping[str, str]] = None,
+) -> None:
 p = subprocess.run((('python3', '-m', 'mypy', *files),
env=env,
check=False,
@@ -99,7 +98,13 @@ def main() -> None:
 env = os.environ.copy()
 env['MYPYPATH'] = env['PYTHONPATH']
 
-run_linters(files, env=env)
+print('=== pylint ===')
+sys.stdout.flush()
+run_pylint(files, env=env)
+
+print('=== mypy ===')
+sys.stdout.flush()
+run_mypy(files, env=env)
 
 
 iotests.script_main(main)
-- 
2.31.1

[PATCH 03/13] iotests/297: Add get_files() function

[John Snow]

Split out file discovery into its own method to begin separating out
configuration/setup and test execution.

Signed-off-by: John Snow 
---
 tests/qemu-iotests/297 | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/tests/qemu-iotests/297 b/tests/qemu-iotests/297
index b8101e6024a..15b54594c11 100755
--- a/tests/qemu-iotests/297
+++ b/tests/qemu-iotests/297
@@ -21,6 +21,7 @@ import re
 import shutil
 import subprocess
 import sys
+from typing import List
 
 import iotests
 
@@ -54,10 +55,14 @@ def is_python_file(filename):
 return False
 
 
-def run_linters():
+def get_test_files() -> List[str]:
 named_tests = [f'tests/{entry}' for entry in os.listdir('tests')]
 check_tests = set(os.listdir('.') + named_tests) - set(SKIP_FILES)
-files = [filename for filename in check_tests if is_python_file(filename)]
+return list(filter(is_python_file, check_tests))
+
+
+def run_linters():
+files = get_test_files()
 
 iotests.logger.debug('Files to be checked:')
 iotests.logger.debug(', '.join(sorted(files)))
-- 
2.31.1

[PATCH 09/13] iotests: split linters.py out from 297

[John Snow]

Now, 297 is just the iotests-specific incantations and linters.py is as
minimal as I can think to make it. The only remaining element in here
that ought to be configuration and not code is the list of skip files,
but they're still numerous enough that repeating them for mypy and
pylint configurations both would be ... a hassle.

Signed-off-by: John Snow 
---
 tests/qemu-iotests/297| 72 +++---
 tests/qemu-iotests/linters.py | 83 +++
 2 files changed, 88 insertions(+), 67 deletions(-)
 create mode 100644 tests/qemu-iotests/linters.py

diff --git a/tests/qemu-iotests/297 b/tests/qemu-iotests/297
index 4c54dd39b46..f79c80216bf 100755
--- a/tests/qemu-iotests/297
+++ b/tests/qemu-iotests/297
@@ -17,76 +17,14 @@
 # along with this program.  If not, see .
 
 import os
-import re
 import shutil
-import subprocess
 import sys
-from typing import List, Mapping, Optional
 
 import iotests
+import linters
 
 
-# TODO: Empty this list!
-SKIP_FILES = (
-'030', '040', '041', '044', '045', '055', '056', '057', '065', '093',
-'096', '118', '124', '132', '136', '139', '147', '148', '149',
-'151', '152', '155', '163', '165', '194', '196', '202',
-'203', '205', '206', '207', '208', '210', '211', '212', '213', '216',
-'218', '219', '224', '228', '234', '235', '236', '237', '238',
-'240', '242', '245', '246', '248', '255', '256', '257', '258', '260',
-'262', '264', '266', '274', '277', '280', '281', '295', '296', '298',
-'299', '302', '303', '304', '307',
-'nbd-fault-injector.py', 'qcow2.py', 'qcow2_format.py', 'qed.py'
-)
-
-
-def is_python_file(filename):
-if not os.path.isfile(filename):
-return False
-
-if filename.endswith('.py'):
-return True
-
-with open(filename, encoding='utf-8') as f:
-try:
-first_line = f.readline()
-return re.match('^#!.*python', first_line) is not None
-except UnicodeDecodeError:  # Ignore binary files
-return False
-
-
-def get_test_files() -> List[str]:
-named_tests = [f'tests/{entry}' for entry in os.listdir('tests')]
-check_tests = set(os.listdir('.') + named_tests) - set(SKIP_FILES)
-return list(filter(is_python_file, check_tests))
-
-
-def run_linter(
-tool: str,
-args: List[str],
-env: Optional[Mapping[str, str]] = None,
-suppress_output: bool = False,
-) -> int:
-"""
-Run a python-based linting tool.
-
-If suppress_output is True, capture stdout/stderr of the child
-process and only print that information back to stdout if the child
-process's return code was non-zero.
-"""
-p = subprocess.run(
-('python3', '-m', tool, *args),
-env=env,
-check=False,
-stdout=subprocess.PIPE if suppress_output else None,
-stderr=subprocess.STDOUT if suppress_output else None,
-universal_newlines=True,
-)
-
-if suppress_output and p.returncode != 0:
-print(p.stdout)
-
-return p.returncode
+# Looking for the list of files to exclude from linting? See linters.py.
 
 
 def main() -> None:
@@ -94,7 +32,7 @@ def main() -> None:
 if shutil.which(linter) is None:
 iotests.notrun(f'{linter} not found')
 
-files = get_test_files()
+files = linters.get_test_files()
 
 iotests.logger.debug('Files to be checked:')
 iotests.logger.debug(', '.join(sorted(files)))
@@ -104,11 +42,11 @@ def main() -> None:
 
 print('=== pylint ===')
 sys.stdout.flush()
-run_linter('pylint', files, env=env)
+linters.run_linter('pylint', files, env=env)
 
 print('=== mypy ===')
 sys.stdout.flush()
-run_linter('mypy', files, env=env, suppress_output=True)
+linters.run_linter('mypy', files, env=env, suppress_output=True)
 
 
 iotests.script_main(main)
diff --git a/tests/qemu-iotests/linters.py b/tests/qemu-iotests/linters.py
new file mode 100644
index 000..f6a2dc139fd
--- /dev/null
+++ b/tests/qemu-iotests/linters.py
@@ -0,0 +1,83 @@
+# Copyright (C) 2020 Red Hat, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see .
+
+import os
+import re
+import subprocess
+from typing import List, Mapping, Optional
+
+
+# TODO: Empty this list!
+SKIP_FILES = (
+'030', '040', '041', '044', '045', '055', '056', '057', '065', '093',
+'096', '118', 

[PATCH 05/13] iotests/297: Create main() function

[John Snow]

Instead of running "run_linters" directly, create a main() function that
will be responsible for environment setup, leaving run_linters()
responsible only for execution of the linters.

(That environment setup will be moved over in forthcoming commits.)

Signed-off-by: John Snow 
Reviewed-by: Vladimir Sementsov-Ogievskiy 
Reviewed-by: Philippe Mathieu-Daudé 
Reviewed-by: Hanna Reitz 
---
 tests/qemu-iotests/297 | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/tests/qemu-iotests/297 b/tests/qemu-iotests/297
index 65b1e7058c2..f9fcb039e27 100755
--- a/tests/qemu-iotests/297
+++ b/tests/qemu-iotests/297
@@ -89,8 +89,12 @@ def run_linters():
 print(p.stdout)
 
 
-for linter in ('pylint-3', 'mypy'):
-if shutil.which(linter) is None:
-iotests.notrun(f'{linter} not found')
+def main() -> None:
+for linter in ('pylint-3', 'mypy'):
+if shutil.which(linter) is None:
+iotests.notrun(f'{linter} not found')
 
-iotests.script_main(run_linters)
+run_linters()
+
+
+iotests.script_main(main)
-- 
2.31.1

[PATCH 01/13] iotests/297: Move pylint config into pylintrc

[John Snow]

Move --score=n and --notes=XXX,FIXME into pylintrc. This pulls
configuration out of code, which I think is probably a good thing in
general.

Signed-off-by: John Snow 
---
 tests/qemu-iotests/297  |  4 +---
 tests/qemu-iotests/pylintrc | 16 
 2 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/tests/qemu-iotests/297 b/tests/qemu-iotests/297
index 91ec34d9521..bc3a0ceb2aa 100755
--- a/tests/qemu-iotests/297
+++ b/tests/qemu-iotests/297
@@ -65,10 +65,8 @@ def run_linters():
 print('=== pylint ===')
 sys.stdout.flush()
 
-# Todo notes are fine, but fixme's or xxx's should probably just be
-# fixed (in tests, at least)
 env = os.environ.copy()
-subprocess.run(('pylint-3', '--score=n', '--notes=FIXME,XXX', *files),
+subprocess.run(('pylint-3', *files),
env=env, check=False)
 
 print('=== mypy ===')
diff --git a/tests/qemu-iotests/pylintrc b/tests/qemu-iotests/pylintrc
index 8cb4e1d6a6d..32ab77b8bb9 100644
--- a/tests/qemu-iotests/pylintrc
+++ b/tests/qemu-iotests/pylintrc
@@ -31,6 +31,22 @@ disable=invalid-name,
 too-many-statements,
 consider-using-f-string,
 
+
+[REPORTS]
+
+# Activate the evaluation score.
+score=no
+
+
+[MISCELLANEOUS]
+
+# List of note tags to take in consideration, separated by a comma.
+# TODO notes are fine, but FIXMEs or XXXs should probably just be
+# fixed (in tests, at least).
+notes=FIXME,
+  XXX,
+
+
 [FORMAT]
 
 # Maximum number of characters on a single line.
-- 
2.31.1

[PATCH 08/13] iotests/297: refactor run_[mypy|pylint] as generic execution shim

[John Snow]

There's virtually nothing special here anymore; we can combine these
into a single, rather generic function.

Signed-off-by: John Snow 
---
 tests/qemu-iotests/297 | 46 +++---
 1 file changed, 25 insertions(+), 21 deletions(-)

diff --git a/tests/qemu-iotests/297 b/tests/qemu-iotests/297
index 91029dbb34e..4c54dd39b46 100755
--- a/tests/qemu-iotests/297
+++ b/tests/qemu-iotests/297
@@ -61,29 +61,33 @@ def get_test_files() -> List[str]:
 return list(filter(is_python_file, check_tests))
 
 
-def run_pylint(
-files: List[str],
-env: Optional[Mapping[str, str]] = None,
-) -> None:
+def run_linter(
+tool: str,
+args: List[str],
+env: Optional[Mapping[str, str]] = None,
+suppress_output: bool = False,
+) -> int:
+"""
+Run a python-based linting tool.
 
-subprocess.run(('python3', '-m', 'pylint', *files),
-   env=env, check=False)
+If suppress_output is True, capture stdout/stderr of the child
+process and only print that information back to stdout if the child
+process's return code was non-zero.
+"""
+p = subprocess.run(
+('python3', '-m', tool, *args),
+env=env,
+check=False,
+stdout=subprocess.PIPE if suppress_output else None,
+stderr=subprocess.STDOUT if suppress_output else None,
+universal_newlines=True,
+)
 
-
-def run_mypy(
-files: List[str],
-env: Optional[Mapping[str, str]] = None,
-) -> None:
-p = subprocess.run((('python3', '-m', 'mypy', *files),
-   env=env,
-   check=False,
-   stdout=subprocess.PIPE,
-   stderr=subprocess.STDOUT,
-   universal_newlines=True)
-
-if p.returncode != 0:
+if suppress_output and p.returncode != 0:
 print(p.stdout)
 
+return p.returncode
+
 
 def main() -> None:
 for linter in ('pylint-3', 'mypy'):
@@ -100,11 +104,11 @@ def main() -> None:
 
 print('=== pylint ===')
 sys.stdout.flush()
-run_pylint(files, env=env)
+run_linter('pylint', files, env=env)
 
 print('=== mypy ===')
 sys.stdout.flush()
-run_mypy(files, env=env)
+run_linter('mypy', files, env=env, suppress_output=True)
 
 
 iotests.script_main(main)
-- 
2.31.1

[PATCH 02/13] iotests/297: Split mypy configuration out into mypy.ini

[John Snow]

More separation of code and configuration.

Signed-off-by: John Snow 
---
 tests/qemu-iotests/297  | 14 +-
 tests/qemu-iotests/mypy.ini | 12 
 2 files changed, 13 insertions(+), 13 deletions(-)
 create mode 100644 tests/qemu-iotests/mypy.ini

diff --git a/tests/qemu-iotests/297 b/tests/qemu-iotests/297
index bc3a0ceb2aa..b8101e6024a 100755
--- a/tests/qemu-iotests/297
+++ b/tests/qemu-iotests/297
@@ -73,19 +73,7 @@ def run_linters():
 sys.stdout.flush()
 
 env['MYPYPATH'] = env['PYTHONPATH']
-p = subprocess.run(('mypy',
-'--warn-unused-configs',
-'--disallow-subclassing-any',
-'--disallow-any-generics',
-'--disallow-incomplete-defs',
-'--disallow-untyped-decorators',
-'--no-implicit-optional',
-'--warn-redundant-casts',
-'--warn-unused-ignores',
-'--no-implicit-reexport',
-'--namespace-packages',
-'--scripts-are-modules',
-*files),
+p = subprocess.run(('mypy', *files),
env=env,
check=False,
stdout=subprocess.PIPE,
diff --git a/tests/qemu-iotests/mypy.ini b/tests/qemu-iotests/mypy.ini
new file mode 100644
index 000..4c0339f5589
--- /dev/null
+++ b/tests/qemu-iotests/mypy.ini
@@ -0,0 +1,12 @@
+[mypy]
+disallow_any_generics = True
+disallow_incomplete_defs = True
+disallow_subclassing_any = True
+disallow_untyped_decorators = True
+implicit_reexport = False
+namespace_packages = True
+no_implicit_optional = True
+scripts_are_modules = True
+warn_redundant_casts = True
+warn_unused_configs = True
+warn_unused_ignores = True
-- 
2.31.1

[PATCH 00/13] python/iotests: Run iotest linters during Python CI

[John Snow]

GitLab: https://gitlab.com/jsnow/qemu/-/commits/python-package-iotest-pt2
CI: https://gitlab.com/jsnow/qemu/-/pipelines/382320226
Based-on: <20210923180715.4168522-1-js...@redhat.com>
  [PATCH v2 0/6] iotests: update environment and linting configuration
  (Staged at kwolf/block sans patch #2, not needed here.)

Factor out pylint and mypy configuration from iotest 297 so that the
Python test infrastructure in python/ can also run these linters. This
will enable what is essentially iotest #297 to run via GitLab CI.

This series generally aims to split "linter configuration" out of code
so that both iotest #297 and the Python test suite can both invoke the
same linters (nearly) identically.

The differences occur where the Python entryway involves setting up a
virtual environment and installing linter packages pinned at specific
versions so that the CI test can be guaranteed to behave
deterministically.

iotest #297 is left as a way to run these tests as a convenience until I
can integrate environment setup and test execution as a part of 'make
check' or similar to serve as a replacement. This invocation just trusts
you've installed the right packages into the right places with the right
versions, as it always has.

V4:

- Some optimizations and touchups were included in 'PATCH v2 0/6]
  iotests: update environment and linting configuration' instead, upon
  which this series is now based.
- Rewrote most patches, being more aggressive about the factoring
  between "iotest" and "linter invocation". The patches are smaller now.
- Almost all configuration is split out into mypy.ini and pylintrc.
- Remove the PWD/CWD juggling that the previous versions added; it's not
  strictly needed for this integration. We can re-add it later if we
  wind up needing it for something.
- mypy and pylintrc tests are split into separate tests. The GitLab CI
  now lists them as two separate test cases, so it's easier to see what
  is failing and why. (And how long those tests take.) It is also now
  therefore possible to ask avocado to run just one or the other.
- mypy bug workaround is only applied strictly in cases where it is
  needed, optimizing speed of iotest 297.

V3:
 - Added patch 1 which has been submitted separately upstream,
   but was necessary for testing.
 - Rebased on top of hreitz/block, which fixed some linting issues.
 - Added a workaround for a rather nasty mypy bug ... >:(

V2:
 - Added patches 1-5 which do some more delinting.
 - Added patch 8, which scans subdirs for tests to lint.
 - Added patch 17, which improves the speed of mypy analysis.
 - Patch 14 is different because of the new patch 8.

John Snow (13):
  iotests/297: Move pylint config into pylintrc
  iotests/297: Split mypy configuration out into mypy.ini
  iotests/297: Add get_files() function
  iotests/297: Don't rely on distro-specific linter binaries
  iotests/297: Create main() function
  iotests/297: Separate environment setup from test execution
  iotests/297: Split run_linters apart into run_pylint and run_mypy
  iotests/297: refactor run_[mypy|pylint] as generic execution shim
  iotests: split linters.py out from 297
  iotests/linters: Add entry point for linting via Python CI
  iotests/linters: Add workaround for mypy bug #9852
  python: Add iotest linters to test suite
  iotests: [RFC] drop iotest 297

 python/tests/iotests-mypy.sh   |  4 ++
 python/tests/iotests-pylint.sh |  4 ++
 tests/qemu-iotests/297.out |  2 -
 tests/qemu-iotests/{297 => linters.py} | 88 ++
 tests/qemu-iotests/mypy.ini| 12 
 tests/qemu-iotests/pylintrc| 16 +
 6 files changed, 71 insertions(+), 55 deletions(-)
 create mode 100755 python/tests/iotests-mypy.sh
 create mode 100755 python/tests/iotests-pylint.sh
 delete mode 100644 tests/qemu-iotests/297.out
 rename tests/qemu-iotests/{297 => linters.py} (52%)
 mode change 100755 => 100644
 create mode 100644 tests/qemu-iotests/mypy.ini

-- 
2.31.1

[PATCH 04/13] iotests/297: Don't rely on distro-specific linter binaries

[John Snow]

'pylint-3' is another Fedora-ism. Use "python3 -m pylint" or "python3 -m
mypy" to access these scripts instead. This style of invocation will
prefer the "correct" tool when run in a virtual environment.

Note that we still check for "pylint-3" before the test begins -- this
check is now "overly strict", but shouldn't cause anything that was
already running correctly to start failing.

Signed-off-by: John Snow 
Reviewed-by: Vladimir Sementsov-Ogievskiy 
Reviewed-by: Philippe Mathieu-Daudé 
Reviewed-by: Hanna Reitz 
---
 tests/qemu-iotests/297 | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/qemu-iotests/297 b/tests/qemu-iotests/297
index 15b54594c11..65b1e7058c2 100755
--- a/tests/qemu-iotests/297
+++ b/tests/qemu-iotests/297
@@ -71,14 +71,14 @@ def run_linters():
 sys.stdout.flush()
 
 env = os.environ.copy()
-subprocess.run(('pylint-3', *files),
+subprocess.run(('python3', '-m', 'pylint', *files),
env=env, check=False)
 
 print('=== mypy ===')
 sys.stdout.flush()
 
 env['MYPYPATH'] = env['PYTHONPATH']
-p = subprocess.run(('mypy', *files),
+p = subprocess.run((('python3', '-m', 'mypy', *files),
env=env,
check=False,
stdout=subprocess.PIPE,
-- 
2.31.1

Invitation: QAPI Sync meeting @ Thu Oct 7, 2021 9am - 10am (EDT) (qemu-devel@nongnu.org)

[jsnow]

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VEVENT
DTSTART:20211007T13Z
DTEND:20211007T14Z
DTSTAMP:20211004T210146Z
ORGANIZER;CN=js...@redhat.com:mailto:js...@redhat.com
UID:72pav8a9ib0m49k8qr9hjib...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=berra...@redhat.com;X-NUM-GUESTS=0:mailto:berra...@redhat.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
 ;CN=js...@redhat.com;X-NUM-GUESTS=0:mailto:js...@redhat.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=pbonz...@redhat.com;X-NUM-GUESTS=0:mailto:pbonz...@redhat.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=arm...@redhat.com;X-NUM-GUESTS=0:mailto:arm...@redhat.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
 ;CN=damien.he...@greensocs.com;X-NUM-GUESTS=0:mailto:damien.hedde@greensocs
 .com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
 ;CN=marcandre.lur...@redhat.com;X-NUM-GUESTS=0:mailto:marcandre.lureau@redh
 at.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=kw...@redhat.com;X-NUM-GUESTS=0:mailto:kw...@redhat.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=qemu-devel@nongnu.org;X-NUM-GUESTS=0:mailto:qemu-devel@nongnu.org
X-MICROSOFT-CDO-OWNERAPPTID:-2106639245
CREATED:20211001T001809Z
DESCRIPTION:Let's discuss our ongoing and future work on the QAPI generator
  and closely related interfaces for QEMU.\n\nPlease prepare for the meeting
  by writing a small overview of your pending and future work\, and the goal
 s that motivate those works. If you send this summary to the mailing list b
 eforehand\, we'll have the opportunity to skim it prior to the meeting.\n\n
 I am suggesting we use a public etherpad instance to keep notes during the 
 meeting: https://etherpad.wikimedia.org/p/qapi-sync\n\nDuring this meeting\
 , I'd like to assemble a list of all ongoing QAPI work and begin work on cr
 afting a roadmap that helps describe that work.\n\nI don't suspect we'll fi
 nish in a single meeting\, but it may be a helpful primer for follow-up dis
 cussions on the ML.\n\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:
 ~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-\nDo not edit this section of the descri
 ption.\n\nThis event has a video call.\nJoin: https://meet.google.com/xqi-t
 iqs-xrz\n(US) +1 929-249-4854 PIN: 637379240#\n\nJoin using SIP\n6779067023
 1...@gmeet.redhat.com (ID: 6779067023105)\nView more joining options: https:
 //tel.meet/xqi-tiqs-xrz?pin=6779067023105=7\n\nView your event at https:
 //calendar.google.com/calendar/event?action=VIEW=NzJwYXY4YTlpYjBtNDlrOH
 FyOWhqaWJnZzcgcWVtdS1kZXZlbEBub25nbnUub3Jn=MTYjanNub3dAcmVkaGF0LmNvbTAx
 YTNkNTk0NTQyOWNkNDk4YzgxYTY1ZDdhMTc3ODM3NzAyOTg0MzM=America%2FNew_York&
 hl=en=1.\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:
 ~:~:~:~:~:~:~:~:~::~:~::-
LAST-MODIFIED:20211004T210146Z
LOCATION:
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:QAPI Sync meeting
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics

Re: [PATCH 08/13] virtiofsd: Create a notification queue

[Vivek Goyal]

On Mon, Oct 04, 2021 at 03:30:38PM +0100, Stefan Hajnoczi wrote:
> On Thu, Sep 30, 2021 at 11:30:32AM -0400, Vivek Goyal wrote:
> > Add a notification queue which will be used to send async notifications
> > for file lock availability.
> > 
> > Signed-off-by: Vivek Goyal 
> > Signed-off-by: Ioannis Angelakopoulos 
> > ---
> >  hw/virtio/vhost-user-fs-pci.c |  4 +-
> >  hw/virtio/vhost-user-fs.c | 62 +--
> >  include/hw/virtio/vhost-user-fs.h |  2 +
> >  tools/virtiofsd/fuse_i.h  |  1 +
> >  tools/virtiofsd/fuse_virtio.c | 70 +++
> >  5 files changed, 116 insertions(+), 23 deletions(-)
> > 
> > diff --git a/hw/virtio/vhost-user-fs-pci.c b/hw/virtio/vhost-user-fs-pci.c
> > index 2ed8492b3f..cdb9471088 100644
> > --- a/hw/virtio/vhost-user-fs-pci.c
> > +++ b/hw/virtio/vhost-user-fs-pci.c
> > @@ -41,8 +41,8 @@ static void vhost_user_fs_pci_realize(VirtIOPCIProxy 
> > *vpci_dev, Error **errp)
> >  DeviceState *vdev = DEVICE(>vdev);
> >  
> >  if (vpci_dev->nvectors == DEV_NVECTORS_UNSPECIFIED) {
> > -/* Also reserve config change and hiprio queue vectors */
> > -vpci_dev->nvectors = dev->vdev.conf.num_request_queues + 2;
> > +/* Also reserve config change, hiprio and notification queue 
> > vectors */
> > +vpci_dev->nvectors = dev->vdev.conf.num_request_queues + 3;
> >  }
> >  
> >  qdev_realize(vdev, BUS(_dev->bus), errp);
> > diff --git a/hw/virtio/vhost-user-fs.c b/hw/virtio/vhost-user-fs.c
> > index d1efbc5b18..6bafcf0243 100644
> > --- a/hw/virtio/vhost-user-fs.c
> > +++ b/hw/virtio/vhost-user-fs.c
> > @@ -31,6 +31,7 @@ static const int user_feature_bits[] = {
> >  VIRTIO_F_NOTIFY_ON_EMPTY,
> >  VIRTIO_F_RING_PACKED,
> >  VIRTIO_F_IOMMU_PLATFORM,
> > +VIRTIO_FS_F_NOTIFICATION,
> >  
> >  VHOST_INVALID_FEATURE_BIT
> >  };
> > @@ -147,7 +148,7 @@ static void vuf_handle_output(VirtIODevice *vdev, 
> > VirtQueue *vq)
> >   */
> >  }
> >  
> > -static void vuf_create_vqs(VirtIODevice *vdev)
> > +static void vuf_create_vqs(VirtIODevice *vdev, bool notification_vq)
> >  {
> >  VHostUserFS *fs = VHOST_USER_FS(vdev);
> >  unsigned int i;
> > @@ -155,6 +156,15 @@ static void vuf_create_vqs(VirtIODevice *vdev)
> >  /* Hiprio queue */
> >  fs->hiprio_vq = virtio_add_queue(vdev, fs->conf.queue_size,
> >   vuf_handle_output);
> > +/*
> > + * Notification queue. Feature negotiation happens later. So at this
> > + * point of time we don't know if driver will use notification queue
> > + * or not.
> > + */
> > +if (notification_vq) {
> > +fs->notification_vq = virtio_add_queue(vdev, fs->conf.queue_size,
> > +   vuf_handle_output);
> > +}
> >  
> >  /* Request queues */
> >  fs->req_vqs = g_new(VirtQueue *, fs->conf.num_request_queues);
> > @@ -163,8 +173,12 @@ static void vuf_create_vqs(VirtIODevice *vdev)
> >vuf_handle_output);
> >  }
> >  
> > -/* 1 high prio queue, plus the number configured */
> > -fs->vhost_dev.nvqs = 1 + fs->conf.num_request_queues;
> > +/* 1 high prio queue, 1 notification queue plus the number configured 
> > */
> > +if (notification_vq) {
> > +fs->vhost_dev.nvqs = 2 + fs->conf.num_request_queues;
> > +} else {
> > +fs->vhost_dev.nvqs = 1 + fs->conf.num_request_queues;
> > +}
> >  fs->vhost_dev.vqs = g_new0(struct vhost_virtqueue, fs->vhost_dev.nvqs);
> >  }
> >  
> > @@ -176,6 +190,11 @@ static void vuf_cleanup_vqs(VirtIODevice *vdev)
> >  virtio_delete_queue(fs->hiprio_vq);
> >  fs->hiprio_vq = NULL;
> >  
> > +if (fs->notification_vq) {
> > +virtio_delete_queue(fs->notification_vq);
> > +}
> > +fs->notification_vq = NULL;
> > +
> >  for (i = 0; i < fs->conf.num_request_queues; i++) {
> >  virtio_delete_queue(fs->req_vqs[i]);
> >  }
> > @@ -194,9 +213,43 @@ static uint64_t vuf_get_features(VirtIODevice *vdev,
> >  {
> >  VHostUserFS *fs = VHOST_USER_FS(vdev);
> >  
> > +virtio_add_feature(, VIRTIO_FS_F_NOTIFICATION);
> > +
> >  return vhost_get_features(>vhost_dev, user_feature_bits, features);
> >  }
> >  
> > +static void vuf_set_features(VirtIODevice *vdev, uint64_t features)
> > +{
> > +VHostUserFS *fs = VHOST_USER_FS(vdev);
> > +
> > +if (virtio_has_feature(features, VIRTIO_FS_F_NOTIFICATION)) {
> > +fs->notify_enabled = true;
> > +/*
> > + * If guest first booted with no notification queue support and
> > + * later rebooted with kernel which supports notification, we
> > + * can end up here
> > + */
> > +if (!fs->notification_vq) {
> > +vuf_cleanup_vqs(vdev);
> > +vuf_create_vqs(vdev, true);
> > +}
> 
> I would simplify things by unconditionally creating the 

Re: [PATCH v6 02/10] ACPI ERST: specification for ERST support

[Eric DeVolder]

On 9/20/21 8:38 AM, Igor Mammedov wrote:

On Thu,  5 Aug 2021 18:30:31 -0400
Eric DeVolder  wrote:


Information on the implementation of the ACPI ERST support.

Signed-off-by: Eric DeVolder 


modulo missing parts documentation looks good to but
I'm tainted at this point (after so many reviews) so
libvirt folks (CCed) can take look at it and see if
something needs to be changed here.


OK. I'll wait for Daniel's feedback before posting v7.




---
  docs/specs/acpi_erst.txt | 147 +++
  1 file changed, 147 insertions(+)
  create mode 100644 docs/specs/acpi_erst.txt

diff --git a/docs/specs/acpi_erst.txt b/docs/specs/acpi_erst.txt
new file mode 100644
index 000..7f7544f
--- /dev/null
+++ b/docs/specs/acpi_erst.txt
@@ -0,0 +1,147 @@
+ACPI ERST DEVICE
+
+
+The ACPI ERST device is utilized to support the ACPI Error Record
+Serialization Table, ERST, functionality. This feature is designed for
+storing error records in persistent storage for future reference
+and/or debugging.
+
+The ACPI specification[1], in Chapter "ACPI Platform Error Interfaces
+(APEI)", and specifically subsection "Error Serialization", outlines a
+method for storing error records into persistent storage.
+
+The format of error records is described in the UEFI specification[2],
+in Appendix N "Common Platform Error Record".
+
+While the ACPI specification allows for an NVRAM "mode" (see
+GET_ERROR_LOG_ADDRESS_RANGE_ATTRIBUTES) where non-volatile RAM is
+directly exposed for direct access by the OS/guest, this device
+implements the non-NVRAM "mode". This non-NVRAM "mode" is what is
+implemented by most BIOS (since flash memory requires programming
+operations in order to update its contents). Furthermore, as of the
+time of this writing, Linux only supports the non-NVRAM "mode".
+
+
+Background/Motivation
+-
+
+Linux uses the persistent storage filesystem, pstore, to record
+information (eg. dmesg tail) upon panics and shutdowns.  Pstore is
+independent of, and runs before, kdump.  In certain scenarios (ie.
+hosts/guests with root filesystems on NFS/iSCSI where networking
+software and/or hardware fails), pstore may contain information
+available for post-mortem debugging.
+
+Two common storage backends for the pstore filesystem are ACPI ERST
+and UEFI. Most BIOS implement ACPI ERST.  UEFI is not utilized in all
+guests. With QEMU supporting ACPI ERST, it becomes a viable pstore
+storage backend for virtual machines (as it is now for bare metal
+machines).
+
+Enabling support for ACPI ERST facilitates a consistent method to
+capture kernel panic information in a wide range of guests: from
+resource-constrained microvms to very large guests, and in particular,
+in direct-boot environments (which would lack UEFI run-time services).
+
+Note that Microsoft Windows also utilizes the ACPI ERST for certain
+crash information, if available[3].
+
+
+Configuration|Usage
+---
+
+To use ACPI ERST, a memory-backend-file object and acpi-erst device
+can be created, for example:
+
+ qemu ...
+ -object 
memory-backend-file,id=erstnvram,mem-path=acpi-erst.backing,size=0x1,share=on
 \
+ -device acpi-erst,memdev=erstnvram
+
+For proper operation, the ACPI ERST device needs a memory-backend-file
+object with the following parameters:
+
+ - id: The id of the memory-backend-file object is used to associate
+   this memory with the acpi-erst device.
+ - size: The size of the ACPI ERST backing storage. This parameter is
+   required.
+ - mem-path: The location of the ACPI ERST backing storage file. This
+   parameter is also required.
+ - share: The share=on parameter is required so that updates to the
+   ERST backing store are written to the file.
+
+and ERST device:
+
+ - memdev: Is the object id of the memory-backend-file.
+
+
+PCI Interface
+-
+
+The ERST device is a PCI device with two BARs, one for accessing the
+programming registers, and the other for accessing the record exchange
+buffer.
+
+BAR0 contains the programming interface consisting of ACTION and VALUE
+64-bit registers.  All ERST actions/operations/side effects happen on
+the write to the ACTION, by design. Any data needed by the action must
+be placed into VALUE prior to writing ACTION.  Reading the VALUE
+simply returns the register contents, which can be updated by a
+previous ACTION.
+
+BAR1 contains the 8KiB record exchange buffer, which is the
+implemented maximum record size.
+
+
+Backend Storage Format
+--
+
+The backend storage is divided into fixed size "slots", 8KiB in
+length, with each slot storing a single record.  Not all slots need to
+be occupied, and they need not be occupied in a contiguous fashion.
+The ability to clear/erase specific records allows for the formation
+of unoccupied slots.
+
+Slot 0 is reserved for a backend storage header that identifies the
+contents as ERST and also facilitates efficient access to the records.

Re: [PATCH v6 01/10] ACPI ERST: bios-tables-test.c steps 1 and 2

[Eric DeVolder]

On 9/20/21 8:05 AM, Igor Mammedov wrote:

On Thu,  5 Aug 2021 18:30:30 -0400
Eric DeVolder  wrote:


Following the guidelines in tests/qtest/bios-tables-test.c, this
change adds empty placeholder files per step 1 for the new ERST
table, and excludes resulting changed files in bios-tables-test-allowed-diff.h
per step 2.



I'd move this right before 10/10


done




Signed-off-by: Eric DeVolder 


Acked-by: Igor Mammedov 



---
  tests/data/acpi/microvm/ERST| 0
  tests/data/acpi/pc/ERST | 0
  tests/data/acpi/q35/ERST| 0
  tests/qtest/bios-tables-test-allowed-diff.h | 6 ++
  4 files changed, 6 insertions(+)
  create mode 100644 tests/data/acpi/microvm/ERST
  create mode 100644 tests/data/acpi/pc/ERST
  create mode 100644 tests/data/acpi/q35/ERST

diff --git a/tests/data/acpi/microvm/ERST b/tests/data/acpi/microvm/ERST
new file mode 100644
index 000..e69de29
diff --git a/tests/data/acpi/pc/ERST b/tests/data/acpi/pc/ERST
new file mode 100644
index 000..e69de29
diff --git a/tests/data/acpi/q35/ERST b/tests/data/acpi/q35/ERST
new file mode 100644
index 000..e69de29
diff --git a/tests/qtest/bios-tables-test-allowed-diff.h 
b/tests/qtest/bios-tables-test-allowed-diff.h
index dfb8523..b3aaf76 100644
--- a/tests/qtest/bios-tables-test-allowed-diff.h
+++ b/tests/qtest/bios-tables-test-allowed-diff.h
@@ -1 +1,7 @@
  /* List of comma-separated changed AML files to ignore */
+"tests/data/acpi/pc/ERST",
+"tests/data/acpi/q35/ERST",
+"tests/data/acpi/microvm/ERST",
+"tests/data/acpi/pc/DSDT",
+"tests/data/acpi/q35/DSDT",
+"tests/data/acpi/microvm/DSDT",

Re: virtio 4M limit

[Christian Schoenebeck]

On Montag, 4. Oktober 2021 21:59:18 CEST Michael S. Tsirkin wrote:
> On Mon, Oct 04, 2021 at 12:44:21PM +0200, Christian Schoenebeck wrote:
> > On Sonntag, 3. Oktober 2021 22:27:03 CEST Michael S. Tsirkin wrote:
> > > On Sun, Oct 03, 2021 at 08:14:55PM +0200, Christian Schoenebeck wrote:
> > > > On Freitag, 1. Oktober 2021 13:21:23 CEST Christian Schoenebeck wrote:
> > > > > Hi Michael,
> > > > > 
> > > > > while testing the following kernel patches I realized there is
> > > > > currently
> > > > > a
> > > > > size limitation of 4 MB with virtio on QEMU side:
> > > > > https://lore.kernel.org/netdev/cover.1632327421.git.linux_oss@crudeb
> > > > > yte.
> > > > > com/
> > > > > 
> > > > > So with those kernel patches applied I can mount 9pfs on Linux guest
> > > > > with
> > > > > the 9p 'msize' (maximum message size) option with a value of up to
> > > > > 4186112
> > > > > successfully. If I try to go higher with 'msize' then the system
> > > > > would
> > > > > hang
> > > > > 
> > > > > with the following QEMU error:
> > > > >   qemu-system-x86_64: virtio: too many write descriptors in indirect
> > > > >   table
> > > > > 
> > > > > Which apparently is due to the amount of scatter gather lists on
> > > > > QEMU
> > > > > virtio side currently being hard coded to 1024 (i.e. multiplied by
> > > > > 4k
> > > > > page size =>> >
> > > > > 
> > > > > 4 MB):
> > > > >   ./include/hw/virtio/virtio.h:
> > > > >   #define VIRTQUEUE_MAX_SIZE 1024
> > > > > 
> > > > > Is that hard coded limit carved into stone for some reason or would
> > > > > it
> > > > > be OK if I change that into a runtime variable?
> > > > 
> > > > After reviewing the code and protocol specs, it seems that this value
> > > > is
> > > > simply too small. I will therefore send a patch suggsting to raise
> > > > this
> > > > value to 32768, as this is the maximum possible value according to the
> > > > virtio specs.
> > > > 
> > > > https://docs.oasis-open.org/virtio/virtio/v1.1/cs01/virtio-v1.1-cs01.h
> > > > tml#
> > > > x1-240006
> > > 
> > > I think it's too aggressive to change it for all devices.
> > > Pls find a way to only have it affect 9pfs.
> > 
> > So basically I should rather introduce a variable that would be used at
> > most places instead of using the macro VIRTQUEUE_MAX_SIZE?
> 
> I guess so.

Good, because I just sent out a v2 series minutes ago.

> > > > > If that would be Ok, maybe something similar that I did with those
> > > > > kernel
> > > > > patches, i.e. retaining 1024 as an initial default value and if
> > > > > indicated
> > > > > from guest side that more is needed, increasing the SG list amount
> > > > > subsequently according to whatever is needed by guest?
> > > > 
> > > > Further changes are probably not necessary.
> > > > 
> > > > The only thing I have spotted that probably should be changed is that
> > > > at
> > > > some few locations, a local array is allocated on the stack with
> > > > VIRTQUEUE_MAX_SIZE as array size, e.g.:
> > > > 
> > > > static void *virtqueue_split_pop(VirtQueue *vq, size_t sz)
> > > > {
> > > > 
> > > > ...
> > > > hwaddr addr[VIRTQUEUE_MAX_SIZE];
> > > > struct iovec iov[VIRTQUEUE_MAX_SIZE];
> > > > ...
> > > > 
> > > > }
> > 
> > What about these allocations on the stack? Is it Ok to disregard this as
> > theoretical issue for now and just retain them on the stack, just with the
> > runtime variable instead of macro as array size?
> 
> I think it's not a big deal ... why do you think it is? Are we running
> out of stack?

No no. :) That was just a theoretical consideration for who knows what kind of 
platform and usage. I have preserved it on stack in today's v2.
 
> > > > > And as I am not too familiar with the virtio protocol, is that
> > > > > current
> > > > > limit already visible to guest side? Because obviously it would make
> > > > > sense if I change my kernel patches so that they automatically limit
> > > > > to
> > > > > whatever QEMU supports instead of causing a hang.
> > > > 
> > > > Apparently the value of VIRTQUEUE_MAX_SIZE (the maximum amount of
> > > > scatter
> > > > gather lists or the maximum queue size ever possible) is not visible
> > > > to
> > > > guest.
> > > > 
> > > > I thought about making a hack to make the guest Linux kernel aware
> > > > whether
> > > > host side has the old limit of 1024 or rather the correct value 32768,
> > > > but
> > > > probably not worth it.
> > > > 
> > > > Best regards,
> > > > Christian Schoenebeck

[PATCH v2 2/3] virtio: increase VIRTQUEUE_MAX_SIZE to 32k

[Christian Schoenebeck]

Raise the maximum possible virtio transfer size to 128M
(more precisely: 32k * PAGE_SIZE). See previous commit for a
more detailed explanation for the reasons of this change.

For not breaking any virtio user, all virtio users transition
to using the new macro VIRTQUEUE_LEGACY_MAX_SIZE instead of
VIRTQUEUE_MAX_SIZE, so they are all still using the old value
of 1k with this commit.

On the long-term, each virtio user should subsequently either
switch from VIRTQUEUE_LEGACY_MAX_SIZE to VIRTQUEUE_MAX_SIZE
after checking that they support the new value of 32k, or
otherwise they should replace the VIRTQUEUE_LEGACY_MAX_SIZE
macro by an appropriate value supported by them.

Signed-off-by: Christian Schoenebeck 
---
 hw/9pfs/virtio-9p-device.c |  2 +-
 hw/block/vhost-user-blk.c  |  6 +++---
 hw/block/virtio-blk.c  |  6 +++---
 hw/char/virtio-serial-bus.c|  2 +-
 hw/input/virtio-input.c|  2 +-
 hw/net/virtio-net.c| 12 ++--
 hw/scsi/virtio-scsi.c  |  2 +-
 hw/virtio/vhost-user-fs.c  |  6 +++---
 hw/virtio/vhost-user-i2c.c |  2 +-
 hw/virtio/vhost-vsock-common.c |  2 +-
 hw/virtio/virtio-balloon.c |  2 +-
 hw/virtio/virtio-crypto.c  |  2 +-
 hw/virtio/virtio-iommu.c   |  2 +-
 hw/virtio/virtio-mem.c |  2 +-
 hw/virtio/virtio-mmio.c|  4 ++--
 hw/virtio/virtio-pmem.c|  2 +-
 hw/virtio/virtio-rng.c |  3 ++-
 include/hw/virtio/virtio.h | 20 +++-
 18 files changed, 49 insertions(+), 30 deletions(-)

diff --git a/hw/9pfs/virtio-9p-device.c b/hw/9pfs/virtio-9p-device.c
index cd5d95dd51..9013e7df6e 100644
--- a/hw/9pfs/virtio-9p-device.c
+++ b/hw/9pfs/virtio-9p-device.c
@@ -217,7 +217,7 @@ static void virtio_9p_device_realize(DeviceState *dev, 
Error **errp)
 
 v->config_size = sizeof(struct virtio_9p_config) + strlen(s->fsconf.tag);
 virtio_init(vdev, "virtio-9p", VIRTIO_ID_9P, v->config_size,
-VIRTQUEUE_MAX_SIZE);
+VIRTQUEUE_LEGACY_MAX_SIZE);
 v->vq = virtio_add_queue(vdev, MAX_REQ, handle_9p_output);
 }
 
diff --git a/hw/block/vhost-user-blk.c b/hw/block/vhost-user-blk.c
index 336f56705c..e5e45262ab 100644
--- a/hw/block/vhost-user-blk.c
+++ b/hw/block/vhost-user-blk.c
@@ -480,9 +480,9 @@ static void vhost_user_blk_device_realize(DeviceState *dev, 
Error **errp)
 error_setg(errp, "queue size must be non-zero");
 return;
 }
-if (s->queue_size > VIRTQUEUE_MAX_SIZE) {
+if (s->queue_size > VIRTQUEUE_LEGACY_MAX_SIZE) {
 error_setg(errp, "queue size must not exceed %d",
-   VIRTQUEUE_MAX_SIZE);
+   VIRTQUEUE_LEGACY_MAX_SIZE);
 return;
 }
 
@@ -491,7 +491,7 @@ static void vhost_user_blk_device_realize(DeviceState *dev, 
Error **errp)
 }
 
 virtio_init(vdev, "virtio-blk", VIRTIO_ID_BLOCK,
-sizeof(struct virtio_blk_config), VIRTQUEUE_MAX_SIZE);
+sizeof(struct virtio_blk_config), VIRTQUEUE_LEGACY_MAX_SIZE);
 
 s->virtqs = g_new(VirtQueue *, s->num_queues);
 for (i = 0; i < s->num_queues; i++) {
diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c
index 9c0f46815c..5883e3e7db 100644
--- a/hw/block/virtio-blk.c
+++ b/hw/block/virtio-blk.c
@@ -1171,10 +1171,10 @@ static void virtio_blk_device_realize(DeviceState *dev, 
Error **errp)
 return;
 }
 if (!is_power_of_2(conf->queue_size) ||
-conf->queue_size > VIRTQUEUE_MAX_SIZE) {
+conf->queue_size > VIRTQUEUE_LEGACY_MAX_SIZE) {
 error_setg(errp, "invalid queue-size property (%" PRIu16 "), "
"must be a power of 2 (max %d)",
-   conf->queue_size, VIRTQUEUE_MAX_SIZE);
+   conf->queue_size, VIRTQUEUE_LEGACY_MAX_SIZE);
 return;
 }
 
@@ -1214,7 +1214,7 @@ static void virtio_blk_device_realize(DeviceState *dev, 
Error **errp)
 virtio_blk_set_config_size(s, s->host_features);
 
 virtio_init(vdev, "virtio-blk", VIRTIO_ID_BLOCK, s->config_size,
-VIRTQUEUE_MAX_SIZE);
+VIRTQUEUE_LEGACY_MAX_SIZE);
 
 s->blk = conf->conf.blk;
 s->rq = NULL;
diff --git a/hw/char/virtio-serial-bus.c b/hw/char/virtio-serial-bus.c
index 9ad915..2d4285ab53 100644
--- a/hw/char/virtio-serial-bus.c
+++ b/hw/char/virtio-serial-bus.c
@@ -1045,7 +1045,7 @@ static void virtio_serial_device_realize(DeviceState 
*dev, Error **errp)
 config_size = offsetof(struct virtio_console_config, emerg_wr);
 }
 virtio_init(vdev, "virtio-serial", VIRTIO_ID_CONSOLE,
-config_size, VIRTQUEUE_MAX_SIZE);
+config_size, VIRTQUEUE_LEGACY_MAX_SIZE);
 
 /* Spawn a new virtio-serial bus on which the ports will ride as devices */
 qbus_init(>bus, sizeof(vser->bus), TYPE_VIRTIO_SERIAL_BUS,
diff --git a/hw/input/virtio-input.c b/hw/input/virtio-input.c
index 345eb2cce7..b6b77488f2 100644
--- a/hw/input/virtio-input.c
+++ b/hw/input/virtio-input.c
@@ 

Re: [PATCH 3/4] MAINTAINERS: Split MIPS TCG frontend vs MIPS machines/hardware

[Jiaxun Yang]

在 2021/10/4 10:25, Philippe Mathieu-Daudé 写道:

Hardware emulated models don't belong to the TCG MAINTAINERS
section. Move them to a new 'Overall MIPS Machines' section
in the 'MIPS Machines' group.

Signed-off-by: Philippe Mathieu-Daudé 

Reviewed-by: Jiaxun Yang 

Thanks.
- Jiaxun

---
  MAINTAINERS | 10 +++---
  1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index a5268ad0651..f1d7279a0f2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -236,11 +236,8 @@ R: Jiaxun Yang 
  R: Aleksandar Rikalo 
  S: Odd Fixes
  F: target/mips/
-F: configs/devices/mips*/*
  F: disas/mips.c
  F: docs/system/cpu-models-mips.rst.inc
-F: hw/mips/
-F: include/hw/mips/
  F: tests/tcg/mips/
  
  MIPS TCG CPUs (nanoMIPS ISA)

@@ -1168,6 +1165,13 @@ F: hw/microblaze/petalogix_ml605_mmu.c
  
  MIPS Machines

  -
+Overall MIPS Machines
+M: Philippe Mathieu-Daudé 
+S: Odd Fixes
+F: configs/devices/mips*/*
+F: hw/mips/
+F: include/hw/mips/
+
  Jazz
  M: Hervé Poussineau 
  R: Aleksandar Rikalo 

[PATCH v2 0/3] virtio: increase VIRTQUEUE_MAX_SIZE to 32k

[Christian Schoenebeck]

At the moment the maximum transfer size with virtio is limited to 4M
(1024 * PAGE_SIZE). This series raises this limit to its maximum
theoretical possible transfer size of 128M (32k pages) according to the
virtio specs:

https://docs.oasis-open.org/virtio/virtio/v1.1/cs01/virtio-v1.1-cs01.html#x1-240006

Maintainers: if you don't care about allowing users to go beyond 4M then no
action is required on your side for now. This series preserves the old value
of 1k for now by using VIRTQUEUE_LEGACY_MAX_SIZE on your end.

If you do want to support 128M however, then replace
VIRTQUEUE_LEGACY_MAX_SIZE by VIRTQUEUE_MAX_SIZE on your end (see patch 3 as
example for 9pfs being the first virtio user supporting it) and make sure
that this new transfer size limit is actually supported by you.

Changes v1 -> v2:

  * Instead of simply raising VIRTQUEUE_MAX_SIZE to 32k for all virtio
users, preserve the old value of 1k for all virtio users unless they
explicitly opted in:
https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg00056.html

Christian Schoenebeck (3):
  virtio: turn VIRTQUEUE_MAX_SIZE into a variable
  virtio: increase VIRTQUEUE_MAX_SIZE to 32k
  virtio-9p-device: switch to 32k max. transfer size

 hw/9pfs/virtio-9p-device.c |  3 ++-
 hw/block/vhost-user-blk.c  |  6 +++---
 hw/block/virtio-blk.c  |  7 ---
 hw/char/virtio-serial-bus.c|  2 +-
 hw/display/virtio-gpu-base.c   |  2 +-
 hw/input/virtio-input.c|  2 +-
 hw/net/virtio-net.c| 25 
 hw/scsi/virtio-scsi.c  |  2 +-
 hw/virtio/vhost-user-fs.c  |  6 +++---
 hw/virtio/vhost-user-i2c.c |  3 ++-
 hw/virtio/vhost-vsock-common.c |  2 +-
 hw/virtio/virtio-balloon.c |  4 ++--
 hw/virtio/virtio-crypto.c  |  3 ++-
 hw/virtio/virtio-iommu.c   |  2 +-
 hw/virtio/virtio-mem.c |  2 +-
 hw/virtio/virtio-mmio.c|  4 ++--
 hw/virtio/virtio-pmem.c|  2 +-
 hw/virtio/virtio-rng.c |  3 ++-
 hw/virtio/virtio.c | 35 +++---
 include/hw/virtio/virtio.h | 25 ++--
 20 files changed, 90 insertions(+), 50 deletions(-)

-- 
2.20.1

[PATCH v2 1/3] virtio: turn VIRTQUEUE_MAX_SIZE into a variable

[Christian Schoenebeck]

Refactor VIRTQUEUE_MAX_SIZE to effectively become a runtime
variable per virtio user.

Reasons:

(1) VIRTQUEUE_MAX_SIZE should reflect the absolute theoretical
maximum queue size possible. Which is actually the maximum
queue size allowed by the virtio protocol. The appropriate
value for VIRTQUEUE_MAX_SIZE would therefore be 32768:


https://docs.oasis-open.org/virtio/virtio/v1.1/cs01/virtio-v1.1-cs01.html#x1-240006

Apparently VIRTQUEUE_MAX_SIZE was instead defined with a
more or less arbitrary value of 1024 in the past, which
limits the maximum transfer size with virtio to 4M
(more precise: 1024 * PAGE_SIZE, with the latter typically
being 4k).

(2) Additionally the current value of 1024 poses a hidden limit,
invisible to guest, which causes a system hang with the
following QEMU error if guest tries to exceed it:

virtio: too many write descriptors in indirect table

(3) Unfortunately not all virtio users in QEMU would currently
work correctly with the new value of 32768.

So let's turn this hard coded global value into a runtime
variable as a first step in this commit, configurable for each
virtio user by passing a corresponding value with virtio_init()
call.

Signed-off-by: Christian Schoenebeck 
---
 hw/9pfs/virtio-9p-device.c |  3 ++-
 hw/block/vhost-user-blk.c  |  2 +-
 hw/block/virtio-blk.c  |  3 ++-
 hw/char/virtio-serial-bus.c|  2 +-
 hw/display/virtio-gpu-base.c   |  2 +-
 hw/input/virtio-input.c|  2 +-
 hw/net/virtio-net.c| 15 ---
 hw/scsi/virtio-scsi.c  |  2 +-
 hw/virtio/vhost-user-fs.c  |  2 +-
 hw/virtio/vhost-user-i2c.c |  3 ++-
 hw/virtio/vhost-vsock-common.c |  2 +-
 hw/virtio/virtio-balloon.c |  4 ++--
 hw/virtio/virtio-crypto.c  |  3 ++-
 hw/virtio/virtio-iommu.c   |  2 +-
 hw/virtio/virtio-mem.c |  2 +-
 hw/virtio/virtio-pmem.c|  2 +-
 hw/virtio/virtio-rng.c |  2 +-
 hw/virtio/virtio.c | 35 +++---
 include/hw/virtio/virtio.h |  5 -
 19 files changed, 57 insertions(+), 36 deletions(-)

diff --git a/hw/9pfs/virtio-9p-device.c b/hw/9pfs/virtio-9p-device.c
index 54ee93b71f..cd5d95dd51 100644
--- a/hw/9pfs/virtio-9p-device.c
+++ b/hw/9pfs/virtio-9p-device.c
@@ -216,7 +216,8 @@ static void virtio_9p_device_realize(DeviceState *dev, 
Error **errp)
 }
 
 v->config_size = sizeof(struct virtio_9p_config) + strlen(s->fsconf.tag);
-virtio_init(vdev, "virtio-9p", VIRTIO_ID_9P, v->config_size);
+virtio_init(vdev, "virtio-9p", VIRTIO_ID_9P, v->config_size,
+VIRTQUEUE_MAX_SIZE);
 v->vq = virtio_add_queue(vdev, MAX_REQ, handle_9p_output);
 }
 
diff --git a/hw/block/vhost-user-blk.c b/hw/block/vhost-user-blk.c
index ba13cb87e5..336f56705c 100644
--- a/hw/block/vhost-user-blk.c
+++ b/hw/block/vhost-user-blk.c
@@ -491,7 +491,7 @@ static void vhost_user_blk_device_realize(DeviceState *dev, 
Error **errp)
 }
 
 virtio_init(vdev, "virtio-blk", VIRTIO_ID_BLOCK,
-sizeof(struct virtio_blk_config));
+sizeof(struct virtio_blk_config), VIRTQUEUE_MAX_SIZE);
 
 s->virtqs = g_new(VirtQueue *, s->num_queues);
 for (i = 0; i < s->num_queues; i++) {
diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c
index f139cd7cc9..9c0f46815c 100644
--- a/hw/block/virtio-blk.c
+++ b/hw/block/virtio-blk.c
@@ -1213,7 +1213,8 @@ static void virtio_blk_device_realize(DeviceState *dev, 
Error **errp)
 
 virtio_blk_set_config_size(s, s->host_features);
 
-virtio_init(vdev, "virtio-blk", VIRTIO_ID_BLOCK, s->config_size);
+virtio_init(vdev, "virtio-blk", VIRTIO_ID_BLOCK, s->config_size,
+VIRTQUEUE_MAX_SIZE);
 
 s->blk = conf->conf.blk;
 s->rq = NULL;
diff --git a/hw/char/virtio-serial-bus.c b/hw/char/virtio-serial-bus.c
index f01ec2137c..9ad915 100644
--- a/hw/char/virtio-serial-bus.c
+++ b/hw/char/virtio-serial-bus.c
@@ -1045,7 +1045,7 @@ static void virtio_serial_device_realize(DeviceState 
*dev, Error **errp)
 config_size = offsetof(struct virtio_console_config, emerg_wr);
 }
 virtio_init(vdev, "virtio-serial", VIRTIO_ID_CONSOLE,
-config_size);
+config_size, VIRTQUEUE_MAX_SIZE);
 
 /* Spawn a new virtio-serial bus on which the ports will ride as devices */
 qbus_init(>bus, sizeof(vser->bus), TYPE_VIRTIO_SERIAL_BUS,
diff --git a/hw/display/virtio-gpu-base.c b/hw/display/virtio-gpu-base.c
index c8da4806e0..20b06a7adf 100644
--- a/hw/display/virtio-gpu-base.c
+++ b/hw/display/virtio-gpu-base.c
@@ -171,7 +171,7 @@ virtio_gpu_base_device_realize(DeviceState *qdev,
 
 g->virtio_config.num_scanouts = cpu_to_le32(g->conf.max_outputs);
 virtio_init(VIRTIO_DEVICE(g), "virtio-gpu", VIRTIO_ID_GPU,
-sizeof(struct virtio_gpu_config));
+sizeof(struct virtio_gpu_config), VIRTQUEUE_MAX_SIZE);
 
 if 

Re: [PATCH 4/4] MAINTAINERS: Agree to maintain nanoMIPS TCG frontend

[Jiaxun Yang]

在 2021/10/4 10:25, Philippe Mathieu-Daudé 写道:

As of this commit, the nanoMIPS toolchains haven't been merged
in mainstream projects. However MediaTek provides a toolchain:
https://github.com/MediaTek-Labs/nanomips-gnu-toolchain/releases/tag/nanoMIPS-2021.02-01

Since I now have spent more time with the ISA, I agree to maintain
it along with the other MIPS ISA.

For historical notes, see commit a60442eb8 ("Deprecate nanoMIPS ISA").

Signed-off-by: Philippe Mathieu-Daudé 

Reviewed-by: Jiaxun Yang 

Probably it's worthy to ask MTK folks if they are willing to maintain QEMU?

Thanks.
- Jiaxun

---
  MAINTAINERS | 6 +-
  1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index f1d7279a0f2..8ce47417eff 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -237,14 +237,10 @@ R: Aleksandar Rikalo 
  S: Odd Fixes
  F: target/mips/
  F: disas/mips.c
+X: disas/nanomips.*
  F: docs/system/cpu-models-mips.rst.inc
  F: tests/tcg/mips/
  
-MIPS TCG CPUs (nanoMIPS ISA)

-S: Orphan
-F: disas/nanomips.*
-F: target/mips/tcg/*nanomips*
-
  NiosII TCG CPUs
  M: Chris Wulff 
  M: Marek Vasut 

[PATCH v2 3/3] virtio-9p-device: switch to 32k max. transfer size

[Christian Schoenebeck]

9pfs supports the new maximum virtio queue size of 32k, so let's
switch the 9pfs virtio transport from 1k to 32k.

This will allow a maximum 'msize' option (maximum message size)
by 9p client of approximately 128M (assuming 4k page size, in
practice slightly smaller, e.g. with Linux client minus 2 pages).

Signed-off-by: Christian Schoenebeck 
---
 hw/9pfs/virtio-9p-device.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/9pfs/virtio-9p-device.c b/hw/9pfs/virtio-9p-device.c
index 9013e7df6e..cd5d95dd51 100644
--- a/hw/9pfs/virtio-9p-device.c
+++ b/hw/9pfs/virtio-9p-device.c
@@ -217,7 +217,7 @@ static void virtio_9p_device_realize(DeviceState *dev, 
Error **errp)
 
 v->config_size = sizeof(struct virtio_9p_config) + strlen(s->fsconf.tag);
 virtio_init(vdev, "virtio-9p", VIRTIO_ID_9P, v->config_size,
-VIRTQUEUE_LEGACY_MAX_SIZE);
+VIRTQUEUE_MAX_SIZE);
 v->vq = virtio_add_queue(vdev, MAX_REQ, handle_9p_output);
 }
 
-- 
2.20.1

Re: [PATCH 2/4] MAINTAINERS: Add entries to cover MIPS CPS / GIC hardware

[Jiaxun Yang]

在 2021/10/4 10:25, Philippe Mathieu-Daudé 写道:

MIPS CPS and GIC models are unrelated to the TCG frontend.
Move them as new sections under the 'Devices' group.

Cc: Paul Burton 
Signed-off-by: Philippe Mathieu-Daudé 

Reviewed-by: Jiaxun Yang 

Thanks.
- Jiaxun

---
  MAINTAINERS | 22 --
  1 file changed, 16 insertions(+), 6 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index cfee52a3046..a5268ad0651 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -239,14 +239,8 @@ F: target/mips/
  F: configs/devices/mips*/*
  F: disas/mips.c
  F: docs/system/cpu-models-mips.rst.inc
-F: hw/intc/mips_gic.c
  F: hw/mips/
-F: hw/misc/mips_*
-F: hw/timer/mips_gictimer.c
-F: include/hw/intc/mips_gic.h
  F: include/hw/mips/
-F: include/hw/misc/mips_*
-F: include/hw/timer/mips_gictimer.h
  F: tests/tcg/mips/
  
  MIPS TCG CPUs (nanoMIPS ISA)

@@ -2271,6 +2265,22 @@ S: Odd Fixes
  F: hw/intc/openpic.c
  F: include/hw/ppc/openpic.h
  
+MIPS CPS

+M: Paul Burton 
+M: Philippe Mathieu-Daudé 
+S: Odd Fixes
+F: hw/misc/mips_*
+F: include/hw/misc/mips_*
+
+MIPS GIC
+M: Paul Burton 
+M: Philippe Mathieu-Daudé 
+S: Odd Fixes
+F: hw/intc/mips_gic.c
+F: hw/timer/mips_gictimer.c
+F: include/hw/intc/mips_gic.h
+F: include/hw/timer/mips_gictimer.h
+
  Subsystems
  --
  Overall Audio backends

Re: [PATCH 1/4] MAINTAINERS: Add MIPS general architecture support entry

[Jiaxun Yang]

在 2021/10/4 10:25, Philippe Mathieu-Daudé 写道:

The architecture is covered in TCG (frontend and backend)
and hardware models. Add a generic section matching the
'mips' word in patch subjects.

Cc: Jiaxun Yang 
Signed-off-by: Philippe Mathieu-Daudé 

Reviewed-by: Jiaxun Yang 

Thanks.
- Jiaxun

---
  MAINTAINERS | 7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 50435b8d2f5..cfee52a3046 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -109,6 +109,12 @@ K: ^Subject:.*(?i)s390x?
  T: git https://gitlab.com/cohuck/qemu.git s390-next
  L: qemu-s3...@nongnu.org
  
+MIPS general architecture support

+M: Philippe Mathieu-Daudé 
+R: Jiaxun Yang 
+S: Odd Fixes
+K: ^Subject:.*(?i)mips
+
  Guest CPU cores (TCG)
  -
  Overall TCG CPUs
@@ -242,7 +248,6 @@ F: include/hw/mips/
  F: include/hw/misc/mips_*
  F: include/hw/timer/mips_gictimer.h
  F: tests/tcg/mips/
-K: ^Subject:.*(?i)mips
  
  MIPS TCG CPUs (nanoMIPS ISA)

  S: Orphan

Re: virtio 4M limit

[Michael S. Tsirkin]

On Mon, Oct 04, 2021 at 12:44:21PM +0200, Christian Schoenebeck wrote:
> On Sonntag, 3. Oktober 2021 22:27:03 CEST Michael S. Tsirkin wrote:
> > On Sun, Oct 03, 2021 at 08:14:55PM +0200, Christian Schoenebeck wrote:
> > > On Freitag, 1. Oktober 2021 13:21:23 CEST Christian Schoenebeck wrote:
> > > > Hi Michael,
> > > > 
> > > > while testing the following kernel patches I realized there is currently
> > > > a
> > > > size limitation of 4 MB with virtio on QEMU side:
> > > > https://lore.kernel.org/netdev/cover.1632327421.git.linux_oss@crudebyte.
> > > > com/
> > > > 
> > > > So with those kernel patches applied I can mount 9pfs on Linux guest
> > > > with
> > > > the 9p 'msize' (maximum message size) option with a value of up to
> > > > 4186112
> > > > successfully. If I try to go higher with 'msize' then the system would
> > > > hang
> > > > 
> > > > with the following QEMU error:
> > > >   qemu-system-x86_64: virtio: too many write descriptors in indirect
> > > >   table
> > > > 
> > > > Which apparently is due to the amount of scatter gather lists on QEMU
> > > > virtio side currently being hard coded to 1024 (i.e. multiplied by 4k
> > > > page size =>> > 
> > > > 4 MB):
> > > >   ./include/hw/virtio/virtio.h:
> > > >   #define VIRTQUEUE_MAX_SIZE 1024
> > > > 
> > > > Is that hard coded limit carved into stone for some reason or would it
> > > > be OK if I change that into a runtime variable?
> > > 
> > > After reviewing the code and protocol specs, it seems that this value is
> > > simply too small. I will therefore send a patch suggsting to raise this
> > > value to 32768, as this is the maximum possible value according to the
> > > virtio specs.
> > > 
> > > https://docs.oasis-open.org/virtio/virtio/v1.1/cs01/virtio-v1.1-cs01.html#
> > > x1-240006
> > I think it's too aggressive to change it for all devices.
> > Pls find a way to only have it affect 9pfs.
> 
> So basically I should rather introduce a variable that would be used at most 
> places instead of using the macro VIRTQUEUE_MAX_SIZE?

I guess so.

> > > > If that would be Ok, maybe something similar that I did with those
> > > > kernel
> > > > patches, i.e. retaining 1024 as an initial default value and if
> > > > indicated
> > > > from guest side that more is needed, increasing the SG list amount
> > > > subsequently according to whatever is needed by guest?
> > > 
> > > Further changes are probably not necessary.
> > > 
> > > The only thing I have spotted that probably should be changed is that at
> > > some few locations, a local array is allocated on the stack with
> > > VIRTQUEUE_MAX_SIZE as array size, e.g.:
> > > 
> > > static void *virtqueue_split_pop(VirtQueue *vq, size_t sz)
> > > {
> > > 
> > > ...
> > > hwaddr addr[VIRTQUEUE_MAX_SIZE];
> > > struct iovec iov[VIRTQUEUE_MAX_SIZE];
> > > ...
> > > 
> > > }
> 
> What about these allocations on the stack? Is it Ok to disregard this as 
> theoretical issue for now and just retain them on the stack, just with the 
> runtime variable instead of macro as array size?

I think it's not a big deal ... why do you think it is? Are we running
out of stack?

> > > 
> > > > And as I am not too familiar with the virtio protocol, is that current
> > > > limit already visible to guest side? Because obviously it would make
> > > > sense if I change my kernel patches so that they automatically limit to
> > > > whatever QEMU supports instead of causing a hang.
> > > 
> > > Apparently the value of VIRTQUEUE_MAX_SIZE (the maximum amount of scatter
> > > gather lists or the maximum queue size ever possible) is not visible to
> > > guest.
> > > 
> > > I thought about making a hack to make the guest Linux kernel aware whether
> > > host side has the old limit of 1024 or rather the correct value 32768, but
> > > probably not worth it.
> > > 
> > > Best regards,
> > > Christian Schoenebeck
> 

Re: [PATCH 06/13] vhost-user-fs: Use helpers to create/cleanup virtqueue

[Vivek Goyal]

On Mon, Oct 04, 2021 at 02:54:17PM +0100, Stefan Hajnoczi wrote:
> On Thu, Sep 30, 2021 at 11:30:30AM -0400, Vivek Goyal wrote:
> > Add helpers to create/cleanup virtuqueues and use those helpers. I will
> 
> s/virtuqueues/virtqueues/
> 
> > need to reconfigure queues in later patches and using helpers will allow
> > reusing the code.
> > 
> > Signed-off-by: Vivek Goyal 
> > ---
> >  hw/virtio/vhost-user-fs.c | 87 +++
> >  1 file changed, 52 insertions(+), 35 deletions(-)
> > 
> > diff --git a/hw/virtio/vhost-user-fs.c b/hw/virtio/vhost-user-fs.c
> > index c595957983..d1efbc5b18 100644
> > --- a/hw/virtio/vhost-user-fs.c
> > +++ b/hw/virtio/vhost-user-fs.c
> > @@ -139,6 +139,55 @@ static void vuf_set_status(VirtIODevice *vdev, uint8_t 
> > status)
> >  }
> >  }
> >  
> > +static void vuf_handle_output(VirtIODevice *vdev, VirtQueue *vq)
> > +{
> > +/*
> > + * Not normally called; it's the daemon that handles the queue;
> > + * however virtio's cleanup path can call this.
> > + */
> > +}
> > +
> > +static void vuf_create_vqs(VirtIODevice *vdev)
> > +{
> > +VHostUserFS *fs = VHOST_USER_FS(vdev);
> > +unsigned int i;
> > +
> > +/* Hiprio queue */
> > +fs->hiprio_vq = virtio_add_queue(vdev, fs->conf.queue_size,
> > + vuf_handle_output);
> > +
> > +/* Request queues */
> > +fs->req_vqs = g_new(VirtQueue *, fs->conf.num_request_queues);
> > +for (i = 0; i < fs->conf.num_request_queues; i++) {
> > +fs->req_vqs[i] = virtio_add_queue(vdev, fs->conf.queue_size,
> > +  vuf_handle_output);
> > +}
> > +
> > +/* 1 high prio queue, plus the number configured */
> > +fs->vhost_dev.nvqs = 1 + fs->conf.num_request_queues;
> > +fs->vhost_dev.vqs = g_new0(struct vhost_virtqueue, fs->vhost_dev.nvqs);
> 
> These two lines prepare for vhost_dev_init(), so moving them here is
> debatable. If a caller is going to use this function again in the future
> then they need to be sure to also call vhost_dev_init(). For now it
> looks safe, so I guess it's okay.

Hmm..., I do call this function later from vuf_set_features() and
reconfigure the queues. I see that I don't call vhost_dev_init()
in that path. I am not even sure if I should be calling
vhost_dev_init() from inside vuf_set_features().

So core reuirement is that at the time of first creating device
I have no idea if driver supports notification queue or not. So
I do create device with notification queue. But later if driver
(and possibly vhost device) does not support notifiation queue,
then we need to reconfigure queues. What's the correct way to
do that?

Thanks
Vivek
> 
> Reviewed-by: Stefan Hajnoczi 

Re: Moving QEMU downloads to GitLab Releases?

[Michael Roth]

Quoting Stefan Hajnoczi (2021-10-04 04:01:22)
> On Fri, Oct 01, 2021 at 09:39:13AM +0200, Philippe Mathieu-Daudé wrote:
> > On 9/30/21 15:40, Stefan Hajnoczi wrote:
> > > Hi Mike,
> > > QEMU downloads are currently hosted on qemu.org's Apache web server.
> > > Paolo and I were discussing ways to reduce qemu.org network traffic to
> > > save money and eventually turn off the qemu.org server since there is no
> > > full-time sysadmin for it. I'd like to discuss moving QEMU downloads to
> > > GitLab Releases.
> > > 
> > > Since you create and sign QEMU releases I wanted to see what you think
> > > about the idea. GitLab Releases has two ways of creating release assets:
> > > archiving a git tree and attaching arbitrary binaries. The
> > > scripts/make-release script fetches submodules and generates version
> > > files, so it may be necessary to treat QEMU tarballs as arbitrary
> > > binaries instead of simply letting GitLab create git tree archives:
> > > https://docs.gitlab.com/ee/user/project/releases/#use-a-generic-package-for-attaching-binaries
> > > 
> > > Releases can be uploaded via the GitLab API from your local machine or
> > > deployed as a GitLab CI job. Uploading from your local machine would be
> > > the closest to the current workflow.
> > > 
> > > In the long term we could have a CI job that automatically publishes
> > > QEMU releases when a new qemu.git tag is pushed. The release process
> > > could be fully automated so that manual steps are no longer necessary,
> > > although we'd have to trust GitLab with QEMU GPG signing keys.
> > 
> > Before having to trust a SaaS for GPG signing, could this work?
> > 
> > - make-release script should produce a reproducible tarball in a
> >   gitlab job, along with a file containing the tarball hash.
> > 
> > - Mike (or whoever is responsible of releases) keeps doing a local
> >   manual build
> > 
> > - Mike checks the local hash matches the Gitlab artifact hash
> > 
> > - Mike signs its local build/hash and uses the GitLab API to upload
> >   that .sig to job artifacts
> > 
> > - we can have an extra manual job that checks the tarball.sig
> >   (hash and pubkey) and on success deploys updating the download
> >   page, adding the new release
> 
> I wonder what Mike sees as the way forward.

Hi Stefan, Philippe,

In general I like the idea, since we could also have the CI do the full
gamut of testing against the binaries built from said tarball, so the
Release Person can just regenerate the tarball and provide a sig to
attest that it came from the proper sources. Currently I do make check
and make check-acceptance and a few other sanity checks, which I guess
would no longer be needed then.

But I think the more immediate issue is where/how to host those
tarballs. Even moving all the ROMs/capstone out of the source tree still
results in an xz-compressed tarball size ~25MB, which is well above the
10MB limit mentioned earlier. We could break it out into target-specific
tarballs, maybe further into softmmu/user variants, but that sounds
painful for both users and maintainers who need to deal with the
resulting source tree differences.

What I'm wondering is whether we could just use the archive files
generated by gitlab when we tag our releases? E.g.:

  https://gitlab.com/qemu-project/qemu/-/archive/v6.1.0/qemu-v6.1.0.tar.bz2

If we paired that with an in-tree script similar to make-release for
users to download individual ROM sources/subprojects used for a particular
tagged release, would that be sufficient for GPL compliance and verifying
what sources the binaries were built from? Are there any other
considerations WRT ROMs/etc.?

With something like that in place, Release Person could just do a git
checkout, verify the Maintainer's sig/tag (in case we don't necessarily
trust the git host), generate the tarball, verify the hash matches what
gitlab published (or verify/diff individual files if the bz/gz hashes
require a specific environment), then sign the gitlab tarball and add
the sig to qemu.org download page along with a link the gitlab-generated
tarball.

We could also publish the Maintainer and Release Person public keys on
qemu.org download page so users can verify this as well using the same
process.

Users that want the additional sources can then do it locally via
above-mentioned script, which would be part of the now-signed tarball
and so could be 'trusted' assuming the individual project hosts weren't
compromised (which is still an assumption that's needed with the current
process anyway).

I guess the main question is who is using the ROM/BIOS sources in the
tarballs, and would this 2-step process work for those users? If there
are distros relying on them then maybe there are some more logistics to
consider since the make-release downloads are both time-consuming and
prone to network errors/stalls since it relies on the availability of a
good number of different hosts.

-Mike

> 
> Stefan

Re: [PATCH v3 11/16] iotests/297: return error code from run_linters()

[John Snow]

On Mon, Oct 4, 2021 at 3:45 AM Hanna Reitz  wrote:

> On 22.09.21 22:18, John Snow wrote:
> >
> >
> > On Fri, Sep 17, 2021 at 7:00 AM Hanna Reitz  > > wrote:
>
> [...]
>
> >
> > As you say, run_linters() to me seems very iotests-specific still: It
> > emits a specific output that is compared against a reference output.
> > Fine for 297, but not fine for a function provided by a
> > linters.py, I’d say.
> >
>
> I’d prefer run_linters() to return something like a Map[str,
> > Optional[str]], that would map a tool to its output in case of error,
> > i.e. ideally:
> >
> > `{'pylint': None, 'mypy': None}`
> >
>
>
> > Splitting the test apart into two sub-tests is completely reasonable.
> > Python CI right now has individual tests for pylint, mypy, etc.
> >
> > 297 could format it something like
> >
> > ```
> > for tool, output in run_linters().items():
> >  print(f'=== {tool} ===')
> >  if output is not None:
> >  print(output)
> > ```
> >
> > Or something.
> >
> > To check for error, you could put a Python script in python/tests
> > that
> > checks `any(output is not None for output in
> > run_linters().values())` or
> > something (and on error print the output).
> >
> >
> > Pulling out run_linters() into an external file and having it print
> > something to stdout just seems too iotests-centric to me.  I
> > suppose as
> > long as the return code is right (which this patch is for) it should
> > work for Avocado’s simple tests, too (which I don’t like very much
> > either, by the way, because they too seem archaic to me), but,
> > well.  It
> > almost seems like the Avocado test should just run ./check then.
> >
> >
> > Yeh. Ideally, we'd just have a mypy.ini and a pylintrc that configures
> > the tests adequately, and then 297 (or whomever else) would just call
> > the linters which would in turn read the same configuration. This
> > series is somewhat of a stop-gap to measure the temperature of the
> > room to see how important it was to leave 297 inside of iotests. So, I
> > did the conservative thing that's faster to review even if it now
> > looks *slightly* fishy.
> >
> > As for things being archaic or not ... possibly, but why involve extra
> > complexity if it isn't warranted?
>
> My opinion is that I find an interface of “prints something to stdout
> and returns an integer status code” to be non-intuitive and thus rather
> complex actually.  That’s why I’d prefer different complexity, namely
> one which has a more intuitive interface.
>
>
I'm not sure I follow, though, because ultimately what we're trying to do
is run terminal commands as part of a broader test suite. Returning status
codes and printing output is what they do. We can't escape that paradigm,
so is it really necessary to abstract away from it?


> I’m also not sure where the extra complexity would be for a
> `run_linters() -> Map[str, Optional[str]]`, because 297 just needs the
> loop suggested above over `run_linters().items()`, and as for the
> Avocado test...
>
> > a simple pass/fail works perfectly well.
>
> I don’t find `any(error_msg for error_msg in run_linters().values())`
> much more complex than pass/fail.
>
> (Note: Above, I called it `output`.  Probably should have called it
> `error_msg` like I did now to clarify that it’s `None` in case of
> success and a string otherwise.)
>
> > (And the human can read the output to understand WHY it failed.) If
> > you want more rigorous analytics for some reason, we can discuss the
> > use cases and figure out how to represent that information, but that's
> > definitely a bit beyond scope here.
>
> [...]
>
> > Like, can’t we have a Python script in python/tests that imports
> > linters.py, invokes run_linters() and sensibly checks the output? Or,
> > you know, at the very least not have run_linters() print anything to
> > stdout and not have it return an integer code. linters.py:main()
> > can do
> > that conversion.
> >
> >
> > Well, I certainly don't want to bother parsing output from python
> > tools and trying to make sure that it works sensibly cross-version and
> > cross-distro. The return code being 0/non-zero is vastly simpler. Let
> > the human read the output log on failure cases to get a sense of what
> > exactly went wrong. Is there some reason why parsing the output would
> > be beneficial to anyone?
>
> Perhaps there was a misunderstanding here, because there’s no need to
> parse the output in my suggestion.  `run_linters() -> Map[str,
> Optional[str]]` would map a tool name to its potential error output; if
> the tool exited successfully (exit code 0), then that `Optional[str]`
> error output would be `None`.  It would only be something if there was
> an error.
>
>
Misunderstood based on "checks the output." I might still be approaching
this from the standpoint of "I don't see a reason to 

Re: [RFC PATCH 1/1] virtio: write back features before verify

[Michael S. Tsirkin]

On Mon, Oct 04, 2021 at 05:50:44PM +0200, Cornelia Huck wrote:
> On Mon, Oct 04 2021, "Michael S. Tsirkin"  wrote:
> 
> > On Mon, Oct 04, 2021 at 04:33:21PM +0200, Cornelia Huck wrote:
> >> On Mon, Oct 04 2021, "Michael S. Tsirkin"  wrote:
> >> 
> >> > On Mon, Oct 04, 2021 at 02:19:55PM +0200, Cornelia Huck wrote:
> >> >> 
> >> >> [cc:qemu-devel]
> >> >> 
> >> >> On Sat, Oct 02 2021, "Michael S. Tsirkin"  wrote:
> >> >> 
> >> >> > On Fri, Oct 01, 2021 at 09:21:25AM +0200, Halil Pasic wrote:
> >> >> >> On Thu, 30 Sep 2021 07:12:21 -0400
> >> >> >> "Michael S. Tsirkin"  wrote:
> >> >> >> 
> >> >> >> > On Thu, Sep 30, 2021 at 03:20:49AM +0200, Halil Pasic wrote:
> >> >> >> > > This patch fixes a regression introduced by commit 82e89ea077b9
> >> >> >> > > ("virtio-blk: Add validation for block size in config space") and
> >> >> >> > > enables similar checks in verify() on big endian platforms.
> >> >> >> > > 
> >> >> >> > > The problem with checking multi-byte config fields in the verify
> >> >> >> > > callback, on big endian platforms, and with a possibly 
> >> >> >> > > transitional
> >> >> >> > > device is the following. The verify() callback is called between
> >> >> >> > > config->get_features() and virtio_finalize_features(). That we 
> >> >> >> > > have a
> >> >> >> > > device that offered F_VERSION_1 then we have the following 
> >> >> >> > > options
> >> >> >> > > either the device is transitional, and then it has to present 
> >> >> >> > > the legacy
> >> >> >> > > interface, i.e. a big endian config space until F_VERSION_1 is
> >> >> >> > > negotiated, or we have a non-transitional device, which makes
> >> >> >> > > F_VERSION_1 mandatory, and only implements the non-legacy 
> >> >> >> > > interface and
> >> >> >> > > thus presents a little endian config space. Because at this 
> >> >> >> > > point we
> >> >> >> > > can't know if the device is transitional or non-transitional, we 
> >> >> >> > > can't
> >> >> >> > > know do we need to byte swap or not.  
> >> >> >> > 
> >> >> >> > Hmm which transport does this refer to?
> >> >> >> 
> >> >> >> It is the same with virtio-ccw and virtio-pci. I see the same problem
> >> >> >> with both on s390x. I didn't try with virtio-blk-pci-non-transitional
> >> >> >> yet (have to figure out how to do that with libvirt) for pci I used
> >> >> >> virtio-blk-pci.
> >> >> >> 
> >> >> >> > Distinguishing between legacy and modern drivers is transport
> >> >> >> > specific.  PCI presents
> >> >> >> > legacy and modern at separate addresses so distinguishing
> >> >> >> > between these two should be no trouble.
> >> >> >> 
> >> >> >> You mean the device id? Yes that is bolted down in the spec, but
> >> >> >> currently we don't exploit that information. Furthermore there
> >> >> >> is a fat chance that with QEMU even the allegedly non-transitional
> >> >> >> devices only present a little endian config space after VERSION_1
> >> >> >> was negotiated. Namely get_config for virtio-blk is implemented in
> >> >> >> virtio_blk_update_config() which does virtio_stl_p(vdev,
> >> >> >> _size, blk_size) and in there we don't care
> >> >> >> about transitional or not:
> >> >> >> 
> >> >> >> static inline bool virtio_access_is_big_endian(VirtIODevice *vdev)
> >> >> >> {
> >> >> >> #if defined(LEGACY_VIRTIO_IS_BIENDIAN)
> >> >> >> return virtio_is_big_endian(vdev);
> >> >> >> #elif defined(TARGET_WORDS_BIGENDIAN)
> >> >> >> if (virtio_vdev_has_feature(vdev, VIRTIO_F_VERSION_1)) {
> >> >> >> /* Devices conforming to VIRTIO 1.0 or later are always LE. 
> >> >> >> */
> >> >> >> return false;
> >> >> >> }
> >> >> >> return true;
> >> >> >> #else
> >> >> >> return false;
> >> >> >> #endif
> >> >> >> }
> >> >> >> 
> >> >> >
> >> >> > ok so that's a QEMU bug. Any virtio 1.0 and up
> >> >> > compatible device must use LE.
> >> >> > It can also present a legacy config space where the
> >> >> > endian depends on the guest.
> >> >> 
> >> >> So, how is the virtio core supposed to determine this? A
> >> >> transport-specific callback?
> >> >
> >> > I'd say a field in VirtIODevice is easiest.
> >> 
> >> The transport needs to set this as soon as it has figured out whether
> >> we're using legacy or not.
> >
> > Basically on each device config access?
> 
> Prior to the first one, I think. It should not change again, should it?

Well yes but we never prohibited someone from poking at both ..
Doing it on each access means we don't have state to migrate.

> >
> >> I guess we also need to fence off any
> >> accesses respectively error out the device if the driver tries any
> >> read/write operations that would depend on that knowledge?
> >> 
> >> And using a field in VirtIODevice would probably need some care when
> >> migrating. Hm...
> >
> > It's just a shorthand to minimize changes. No need to migrate I think.
> 
> If we migrate in from an older QEMU, we don't know whether we are
> dealing with legacy or not, until feature negotiation is already
> done... don't we 

Re: [PATCH v3 07/16] iotests/297: Don't rely on distro-specific linter binaries

[John Snow]

On Mon, Oct 4, 2021 at 4:17 AM Hanna Reitz  wrote:

> On 22.09.21 21:53, John Snow wrote:
> > (This email just explains python packaging stuff. No action items in
> > here. Skim away.)
> >
> > On Fri, Sep 17, 2021 at 5:43 AM Hanna Reitz  > > wrote:
> >
> > On 16.09.21 06:09, John Snow wrote:
> > > 'pylint-3' is another Fedora-ism. Use "python3 -m pylint" or
> > "python3 -m
> > > mypy" to access these scripts instead. This style of invocation
> will
> > > prefer the "correct" tool when run in a virtual environment.
> > >
> > > Note that we still check for "pylint-3" before the test begins
> > -- this
> > > check is now "overly strict", but shouldn't cause anything that was
> > > already running correctly to start failing.
> > >
> > > Signed-off-by: John Snow  > >
> > > Reviewed-by: Vladimir Sementsov-Ogievskiy
> > mailto:vsement...@virtuozzo.com>>
> > > Reviewed-by: Philippe Mathieu-Daudé  > >
> > > ---
> > >   tests/qemu-iotests/297 | 45
> > --
> > >   1 file changed, 26 insertions(+), 19 deletions(-)
> >
> > I know it sounds silly, but to be honest I have no idea if replacing
> > `mypy` by `python3 -m mypy` is correct, because no mypy documentation
> > seems to suggest it.
> >
> >
> > Right, I don't think it's necessarily documented that you can do this.
> > It just happens to be a very convenient way to invoke the same script
> > without needing to know *where* mypy is. You let python figure out
> > where it's going to import mypy from, and it handles the rest.
> >
> > (This also makes it easier to use things like mypy, pylint etc with an
> > explicitly specified PYTHON interpreter. I don't happen to do that in
> > this patch, but ... we could.)
> >
> >  From what I understand, that’s generally how Python “binaries” work,
> > though (i.e., installed as a module invokable with `python -m`,
> > and then
> > providing some stub binary that, well, effectively does this, but
> > kind
> > of in a weird way, I just don’t understand it), and none of the
> > parameters seem to be hurt in this conversion, so:
> >
> >
> > Right. Technically, any python package can ask for any number of
> > executables to be installed, but the setuptools packaging ecosystem
> > provides a way to "generate" these based on package configuration. I
> > use a few in our own Python packages. If you look in python/setup.cfg,
> > you'll see stuff like this:
> >
> > [options.entry_points]
> > console_scripts =
> > qom = qemu.qmp.qom:main
> > qom-set = qemu.qmp.qom:QOMSet.entry_point
> > qom-get = qemu.qmp.qom:QOMGet.entry_point
> > qom-list = qemu.qmp.qom:QOMList.entry_point
> > qom-tree = qemu.qmp.qom:QOMTree.entry_point
> > qom-fuse = qemu.qmp.qom_fuse:QOMFuse.entry_point [fuse]
> > qemu-ga-client = qemu.qmp.qemu_ga_client:main
> > qmp-shell = qemu.qmp.qmp_shell:main
> >
> > These entries cause those weird little binary wrapper scripts to be
> > generated for you when the package is *installed*. So our packages
> > will put 'qmp-shell' and 'qom-tree' into your $PATH*.The stuff to the
> > right of the equals sign is just a pointer to a function that can be
> > executed that implements the CLI command. qemu.qmp.qmp_shell points to
> > the module to import, and ':main' points to the function to run.
> >
> > The last bit of this is that many, though not all (and there's zero
> > requirement this has to be true), python packages that implement CLI
> > commands will often have a stanza in their __init__.py module that
> > says something like this:
> >
> > if __name__ == '__main__':
> > do_the_command_line_stuff()
> >
> > Alternatively, a package can include a literal __main__.py file that
> > python knows to check for, and this module is the one that gets
> > executed for `python3 -m mypackage` invocations. This is what mypy does.
> >
> > Those are the magical blurbs that allow you to execute a module as if
> > it were a script by running "python3 -m mymodule" -- that hooks
> > directly into that little execution stanza. For python code
> > distributed as packages, that's the real reason to have that little
> > magic stanza -- it provides a convenient way to run stuff without
> > needing to write the incredibly more tedious:
> >
> > python3 -c "from mypy.__main__ import console_entry; console_entry();"
> >
> > ... which is quite a bit more porcelain too, depending on how they
> > re/factor the code inside of the package.
> >
> > Seeing as how mypy explicitly includes a __main__.py file:
> > https://github.com/python/mypy/blob/master/mypy/__main__.py
> > , I am
> > taking it as a given that they are fully aware of invoking mypy in
> > this fashion, and believe it safe to rely on.
>
> Wow, thanks a lot for this 

Re: [PATCH 11/12] macfb: add vertical blank interrupt

[Mark Cave-Ayland]

On 04/10/2021 17:32, Laurent Vivier wrote:


Le 02/10/2021 à 13:00, Mark Cave-Ayland a écrit :

The MacOS driver expects a 60.15Hz vertical blank interrupt to be generated by
the framebuffer which in turn schedules the mouse driver via the Vertical 
Retrace
Manager.

Signed-off-by: Mark Cave-Ayland 
---
  hw/display/macfb.c | 81 ++
  include/hw/display/macfb.h |  8 
  2 files changed, 89 insertions(+)

diff --git a/hw/display/macfb.c b/hw/display/macfb.c
index 29f6ad8eba..60a203e67b 100644
--- a/hw/display/macfb.c
+++ b/hw/display/macfb.c
@@ -33,9 +33,16 @@
  #define DAFB_MODE_CTRL1 0x8
  #define DAFB_MODE_CTRL2 0xc
  #define DAFB_MODE_SENSE 0x1c
+#define DAFB_INTR_MASK  0x104
+#define DAFB_INTR_STAT  0x108
+#define DAFB_INTR_CLEAR 0x10c
  #define DAFB_RESET  0x200
  #define DAFB_LUT0x213
  
+#define DAFB_INTR_VBL   0x4

+
+/* Vertical Blank period (60.15Hz) */
+#define DAFB_INTR_VBL_PERIOD_NS 16625800
  
  /*

   * Quadra sense codes taken from Apple Technical Note HW26:
@@ -449,6 +456,32 @@ static void macfb_update_display(void *opaque)
  macfb_draw_graphic(s);
  }
  
+static void macfb_update_irq(MacfbState *s)

+{
+uint32_t irq_state = s->irq_state & s->irq_mask;
+
+if (irq_state) {
+qemu_irq_raise(s->irq);
+} else {
+qemu_irq_lower(s->irq);
+}
+}
+
+static void macfb_vbl_timer(void *opaque)
+{
+MacfbState *s = opaque;
+int64_t next_vbl;
+
+s->irq_state |= DAFB_INTR_VBL;
+macfb_update_irq(s);
+
+/* 60 Hz irq */
+next_vbl = (qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) +
+DAFB_INTR_VBL_PERIOD_NS) /
+DAFB_INTR_VBL_PERIOD_NS * DAFB_INTR_VBL_PERIOD_NS;
+timer_mod(s->vbl_timer, next_vbl);


perhaps you can move this to a function and call it here and below?


I'd like to keep the timer_mod() outside of the function but I agree it is nicer to 
keep the next_vbl logci in a single place.



+}
+
  static void macfb_reset(MacfbState *s)
  {
  int i;
@@ -477,6 +510,9 @@ static uint64_t macfb_ctrl_read(void *opaque,
  case DAFB_MODE_CTRL2:
  val = s->regs[addr >> 2];
  break;
+case DAFB_INTR_STAT:
+val = s->irq_state;
+break;
  case DAFB_MODE_SENSE:
  val = macfb_sense_read(s);
  break;
@@ -492,6 +528,8 @@ static void macfb_ctrl_write(void *opaque,
   unsigned int size)
  {
  MacfbState *s = opaque;
+int64_t next_vbl;
+
  switch (addr) {
  case DAFB_MODE_VADDR1:
  case DAFB_MODE_VADDR2:
@@ -507,8 +545,25 @@ static void macfb_ctrl_write(void *opaque,
  case DAFB_MODE_SENSE:
  macfb_sense_write(s, val);
  break;
+case DAFB_INTR_MASK:
+s->irq_mask = val;
+if (val & DAFB_INTR_VBL) {
+next_vbl = (qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) +
+DAFB_INTR_VBL_PERIOD_NS) /
+DAFB_INTR_VBL_PERIOD_NS * DAFB_INTR_VBL_PERIOD_NS;
+timer_mod(s->vbl_timer, next_vbl);
+} else {
+timer_del(s->vbl_timer);
+}
+break;
+case DAFB_INTR_CLEAR:
+s->irq_state &= ~DAFB_INTR_VBL;
+macfb_update_irq(s);
+break;
  case DAFB_RESET:
  s->palette_current = 0;
+s->irq_state &= ~DAFB_INTR_VBL;
+macfb_update_irq(s);
  break;
  case DAFB_LUT:
  s->color_palette[s->palette_current++] = val;
@@ -586,6 +641,7 @@ static void macfb_common_realize(DeviceState *dev, 
MacfbState *s, Error **errp)
  s->vram_bit_mask = MACFB_VRAM_SIZE - 1;
  memory_region_set_coalescing(>mem_vram);
  
+s->vbl_timer = timer_new_ns(QEMU_CLOCK_VIRTUAL, macfb_vbl_timer, s);

  macfb_update_mode(s);
  }
  
@@ -601,6 +657,16 @@ static void macfb_sysbus_realize(DeviceState *dev, Error **errp)
  
  sysbus_init_mmio(SYS_BUS_DEVICE(s), >mem_ctrl);

  sysbus_init_mmio(SYS_BUS_DEVICE(s), >mem_vram);
+
+qdev_init_gpio_out(dev, >irq, 1);
+}
+
+static void macfb_nubus_set_irq(void *opaque, int n, int level)
+{
+MacfbNubusState *s = NUBUS_MACFB(opaque);
+NubusDevice *nd = NUBUS_DEVICE(s);
+
+nubus_set_irq(nd, level);
  }
  
  static void macfb_nubus_realize(DeviceState *dev, Error **errp)

@@ -622,6 +688,19 @@ static void macfb_nubus_realize(DeviceState *dev, Error 
**errp)
  
  memory_region_add_subregion(>slot_mem, DAFB_BASE, >mem_ctrl);

  memory_region_add_subregion(>slot_mem, VIDEO_BASE, >mem_vram);
+
+ms->irq = qemu_allocate_irq(macfb_nubus_set_irq, s, 0);
+}
+
+static void macfb_nubus_unrealize(DeviceState *dev)
+{
+MacfbNubusState *s = NUBUS_MACFB(dev);
+MacfbNubusDeviceClass *ndc = NUBUS_MACFB_GET_CLASS(dev);
+MacfbState *ms = >macfb;
+
+ndc->parent_unrealize(dev);
+
+qemu_free_irq(ms->irq);
  }
  
  static void macfb_sysbus_reset(DeviceState *d)

@@ -672,6 +751,8 @@ static void 

Re: [PATCH 03/12] macfb: fix overflow of color_palette array

[Mark Cave-Ayland]

On 04/10/2021 09:53, Laurent Vivier wrote:


Le 02/10/2021 à 12:59, Mark Cave-Ayland a écrit :

The palette_current index counter has a maximum size of 256 * 3 to cover a full
color palette of 256 RGB entries. Linux assumes that the palette_current index
wraps back around to zero after writing 256 RGB entries so ensure that
palette_current is reset at this point to prevent data corruption within
MacfbState.

Signed-off-by: Mark Cave-Ayland 
---
  hw/display/macfb.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/hw/display/macfb.c b/hw/display/macfb.c
index 815870f2fe..f4e789d0d7 100644
--- a/hw/display/macfb.c
+++ b/hw/display/macfb.c
@@ -307,6 +307,9 @@ static void macfb_ctrl_write(void *opaque,
  if (s->palette_current % 3) {
  macfb_invalidate_display(s);
  }
+if (s->palette_current >= sizeof(s->color_palette)) {
+s->palette_current = 0;
+}
  break;
  }
  }



What about "s->palette_current = (s->palette_current + 1) % 
sizeof(s->color_palette)"?

Thanks,
Laurent


Sure, I can update that for v2.


ATB,

Mark.

Re: [PATCH 07/12] macfb: add qdev property to specify display type

[Mark Cave-Ayland]

On 02/10/2021 15:04, Philippe Mathieu-Daudé wrote:


On 10/2/21 13:00, Mark Cave-Ayland wrote:

Since the available resolutions and colour depths are determined by the attached
display type, add a qdev property to allow the display type to be specified.

The main resolutions of interest are high resolution 1152x870 with 8-bit colour
and SVGA resolution up to 800x600 with 32-bit colour so update the q800 machine
to allow high resolution mode if specified and otherwise fall back to SVGA.

Signed-off-by: Mark Cave-Ayland 
---
  hw/display/macfb.c | 6 +-
  hw/m68k/q800.c | 5 +
  include/hw/display/macfb.h | 1 +
  3 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/hw/display/macfb.c b/hw/display/macfb.c
index 5c95aa4a11..023d1f0cd1 100644
--- a/hw/display/macfb.c
+++ b/hw/display/macfb.c
@@ -316,7 +316,7 @@ static uint32_t macfb_sense_read(MacfbState *s)
  MacFbSense *macfb_sense;
  uint8_t sense;
  


What about:

assert(s->type < ARRAY_SIZE(macfb_sense_table));


-macfb_sense = _sense_table[MACFB_DISPLAY_VGA];
+macfb_sense = _sense_table[s->type];


Otherwise:
Reviewed-by: Philippe Mathieu-Daudé 


Agreed, I will add this in for v2.


ATB,

Mark.

Re: [PULL 21/30] target/arm: use official org.gnu.gdb.aarch64.sve layout for registers

[Luis Machado]

Hi,

On 9/21/21 10:55 AM, Peter Maydell wrote:

On Tue, 19 Jan 2021 at 15:57, Alex Bennée  wrote:



Claudio Fontana  writes:


On 1/19/21 3:50 PM, Alex Bennée wrote:


Claudio Fontana  writes:

qemu-system-aarch64: -gdb 
unix:path=/tmp/tmp9ru5tgk8qemu-gdbstub/gdbstub.socket,server: info: QEMU 
waiting for connection on: 
disconnected:unix:/tmp/tmp9ru5tgk8qemu-gdbstub/gdbstub.socket,server
warning: while parsing target description (at line 47): Vector "svevhf" references 
undefined type "ieee_half"
warning: Could not load XML target description; ignoring
qemu-system-aarch64: QEMU: Terminated via GDBstub

Seems to indicate it is "ieee_half" -related?



So it looks like TDESC_TYPE_IEEE_HALF was only implemented in GDB 9.1
and there is no probing possible during the gdbstub connection. I guess
I can either go back to stubbing it out (which would break gdb's SVE
understanding) or up our minimum GDB version check for running tests.
That would mean less people test GDB (or at least until the distros
catch up) but considering it was zero people not too long ago maybe
that's acceptable?


I just ran into this trying to connect qemu-aarch64 to the
Ubuntu gdb-multiarch. I don't care about SVE at all in this
case, but the 'max' CPU includes SVE by default, so we report
it to gdb even if the guest program being run doesn't use SVE at all.
This effectively means that usecases that used to work no longer do :-(

Luis: do we really have to report to gdb all the possible
data types that might be in SVE vector registers? Won't
gdb autogenerate pseudoregisters the way it does with
Neon d0..d31 ?

thanks
-- PMM



I'll check what can be done here.

Re: [PATCH 01/12] macfb: handle errors that occur during realize

[Mark Cave-Ayland]

On 02/10/2021 14:47, Philippe Mathieu-Daudé wrote:


On 10/2/21 12:59, Mark Cave-Ayland wrote:

Make sure any errors that occur within the macfb realize chain are detected
and handled correctly to prevent crashes and to ensure that error messages are
reported back to the user.

Signed-off-by: Mark Cave-Ayland 
---
  hw/display/macfb.c | 11 +++
  1 file changed, 11 insertions(+)

diff --git a/hw/display/macfb.c b/hw/display/macfb.c
index 76808b69cc..2b747a8de8 100644
--- a/hw/display/macfb.c
+++ b/hw/display/macfb.c
@@ -379,6 +379,10 @@ static void macfb_sysbus_realize(DeviceState *dev, Error 
**errp)
  MacfbState *ms = >macfb;
  
  macfb_common_realize(dev, ms, errp);

+if (*errp) {
+return;
+}


See a related discussion:
https://lore.kernel.org/qemu-devel/87bl47ll9l@dusky.pond.sub.org/


Interesting, thanks for the link. I will update macfb_common_realize() to return a 
boolean for v2.



ATB,

Mark.

Re: [PATCH 01/12] macfb: handle errors that occur during realize

[Mark Cave-Ayland]

On 02/10/2021 12:36, BALATON Zoltan wrote:


On Sat, 2 Oct 2021, Mark Cave-Ayland wrote:

Make sure any errors that occur within the macfb realize chain are detected
and handled correctly to prevent crashes and to ensure that error messages are
reported back to the user.

Signed-off-by: Mark Cave-Ayland 
---
hw/display/macfb.c | 11 +++
1 file changed, 11 insertions(+)

diff --git a/hw/display/macfb.c b/hw/display/macfb.c
index 76808b69cc..2b747a8de8 100644
--- a/hw/display/macfb.c
+++ b/hw/display/macfb.c


There's one more in macfb_common_realize() after:

memory_region_init_ram_nomigrate(>mem_vram, OBJECT(s), "macfb-vram", 
MACFB_VRAM_SIZE, errp);


otherwise

Reviewed-by: BALATON Zoltan 


Ah yes, IIRC from the last patchset the outcome of the discussion with Markus was 
that these functions should use _abort. I'll make the same change here for v2.



ATB,

Mark.

Re: [PATCH v3 05/19] docs/devel: document expectations for HMP commands in the future

[Eric Blake]

On Thu, Sep 30, 2021 at 02:23:35PM +0100, Daniel P. Berrangé wrote:
> We no longer wish to have commands implemented in HMP only. All commands
> should start with a QMP implementation and the HMP merely be a shim
> around this. To reduce the burden of implementing QMP commands where
> there is low expectation of machine usage, requirements for QAPI
> modelling are relaxed provided the command is under the "x-" name
> prefix.
> 
> Signed-off-by: Daniel P. Berrangé 
> ---
>  docs/devel/writing-monitor-commands.rst | 8 
>  1 file changed, 8 insertions(+)
> 

Reviewed-by: Eric Blake 

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

Re: [PATCH 12/15] iotests: Disable AQMP logging under non-debug modes

[John Snow]

On Mon, Oct 4, 2021 at 6:12 AM Hanna Reitz  wrote:

> On 18.09.21 04:14, John Snow wrote:
> >
> >
> > On Fri, Sep 17, 2021 at 8:58 PM John Snow  > > wrote:
> >
> >
> >
> > On Fri, Sep 17, 2021 at 10:30 AM Hanna Reitz  > > wrote:
> >
> > On 17.09.21 07:40, John Snow wrote:
> > > Disable the aqmp logger, which likes to (at the moment)
> > print out
> > > intermediate warnings and errors that cause session
> > termination; disable
> > > them so they don't interfere with the job output.
> > >
> > > Leave any "CRITICAL" warnings enabled though, those are ones
> > that we
> > > should never see, no matter what.
> >
> > I mean, looks OK to me, but from what I understand (i.e. little),
> > qmp_client doesn’t log CRITICAL messages, at least I can’t see
> > any. Only
> > ERRORs.
> >
> >
> > There's *one* critical message in protocol.py, used for a
> > circumstance that I *think* should be impossible. I do not think I
> > currently use any WARNING level statements.
> >
> > I guess I’m missing some CRITICAL messages in external
> > functions called
> > from qmp_client.py, but shouldn’t we still keep ERRORs?
> >
> >
> > ...Mayybe?
> >
> > The errors logged by AQMP are *almost always* raised as Exceptions
> > somewhere else, eventually. Sometimes when we encounter them in
> > one context, we need to save them and then re-raise them in a
> > different execution context. There's one good exception to this:
> > My pal, EOFError.
> >
> > If the reader context encounters EOF, it raises EOFError and this
> > causes a disconnect to be scheduled asynchronously. *Any*
> > Exception that causes a disconnect to be scheduled asynchronously
> > is dutifully logged as an ERROR. At this point in the code, we
> > don't really know if the user of the library considers this an
> > "error" yet or not. I've waffled a lot on how exactly to treat
> > this circumstance. ...Hm, I guess that's really the only case
> > where I have an error that really ought to be suppressed. I
> > suppose what I will do here is: if the exception happens to be an
> > EOFError I will drop the severity of the log message down to INFO.
> > I don't know why it takes being challenged on this stuff to start
> > thinking clearly about it, but here we are. Thank you for your
> > feedback :~)
> >
> > --js
> >
> >
> > Oh, CI testing reminds me of why I am a liar here.
> >
> > the mirror-top-perms test intentionally expects not to be able to
> > connect, but we're treated to these two additional lines of output:
> >
> > +ERROR:qemu.aqmp.qmp_client.qemub-2536319:Negotiation failed: EOFError
> > +ERROR:qemu.aqmp.qmp_client.qemub-2536319:Failed to establish session:
> > EOFError
> >
> > Uh. I guess a temporary suppression in mirror-top-perms, then ...?
>
> Sounds right to me, if that’s simple enough.
>
> (By the way, I understand it right that you want to lower the severity
> of EOFErrors to INFO only on disconnect, right?  Which is why they’re
> still logged as ERRORs here, because they aren’t occurring on disconnects?)
>
>
More or less, yeah.

When an EOFError causes the reader coroutine to halt (because it can't read
the next message), I decided (in v2) to drop that one particular logging
message down to "INFO", because it might -- or might not be -- an expected
occurrence from the point of view of whoever is managing the QMP
connection. Maybe it was expected (The test used qemu-guest-agent or
something else to make the guest shutdown, taking QEMU down with it without
the knowledge of the QMP library layer) or maybe it was unexpected (the QMP
remote really just disappeared from us on a whim). There's no way to know,
so it probably isn't right to consider it an error.

In the connection case, I left it as an ERROR because the caller asked us
to connect to an endpoint and we were unable to, which feels unambiguous.
It will be ultimately reported via Exceptions as qemu.aqmp.ConnectError,
with additional information available in fields of that exception object.
Even though the exception is reported to the caller, I decided to log the
occurrence anyway, because I felt like it should be the job of the library
to make a good log and not the caller's responsibility to catch the
exception and then log it themselves.

That does leave us with this atypical case though: the caller is
intentionally causing problems :)

(Well, atypical for a user of the library who is using it to make a tool
they expect to work. Quite a typical case for tests in the abstract, though
we only seem to have precisely one usage of this pattern in iotests so far.)


> > In most other cases I rather imagine we do want to see this kind of
> > output to help give more information about how things have failed --
> > they ARE 

Re: [PATCH v3 04/19] docs/devel: add example of command returning unstructured text

[Eric Blake]

On Thu, Sep 30, 2021 at 02:23:34PM +0100, Daniel P. Berrangé wrote:
> This illustrates how to add a QMP command returning unstructured text,
> following the guidelines added in the previous patch. The example uses
> a simplified version of 'info roms'.
> 
> Signed-off-by: Daniel P. Berrangé 
> ---
>  docs/devel/writing-monitor-commands.rst | 87 -
>  1 file changed, 86 insertions(+), 1 deletion(-)

Reviewed-by: Eric Blake 

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

Re: [PULL 00/12] jobs: mirror: Handle errors after READY cancel

[Vladimir Sementsov-Ogievskiy]

10/4/21 19:47, Hanna Reitz wrote:

On 24.09.21 00:01, Vladimir Sementsov-Ogievskiy wrote:

22.09.2021 22:19, Vladimir Sementsov-Ogievskiy wrote:

22.09.2021 19:05, Richard Henderson wrote:

On 9/21/21 3:20 AM, Vladimir Sementsov-Ogievskiy wrote:

The following changes since commit 326ff8dd09556fc2e257196c49f35009700794ac:

   Merge remote-tracking branch 'remotes/jasowang/tags/net-pull-request' into 
staging (2021-09-20 16:17:05 +0100)

are available in the Git repository at:

   https://src.openvz.org/scm/~vsementsov/qemu.git tags/pull-jobs-2021-09-21

for you to fetch changes up to c9489c04319cac75c76af8fc27c254f46e10214c:

   iotests: Add mirror-ready-cancel-error test (2021-09-21 11:56:11 +0300)


mirror: Handle errors after READY cancel


Hanna Reitz (12):
   job: Context changes in job_completed_txn_abort()
   mirror: Keep s->synced on error
   mirror: Drop s->synced
   job: Force-cancel jobs in a failed transaction
   job: @force parameter for job_cancel_sync()
   jobs: Give Job.force_cancel more meaning
   job: Add job_cancel_requested()
   mirror: Use job_is_cancelled()
   mirror: Check job_is_cancelled() earlier
   mirror: Stop active mirroring after force-cancel
   mirror: Do not clear .cancelled
   iotests: Add mirror-ready-cancel-error test


This fails testing with errors like so:

Running test test-replication
test-replication: ../job.c:186: job_state_transition: Assertion 
`JobSTT[s0][s1]' failed.
ERROR test-replication - too few tests run (expected 13, got 8)
make: *** [Makefile.mtest:816: run-test-100] Error 1
Cleaning up project directory and file based variables
ERROR: Job failed: exit code 1

https://gitlab.com/qemu-project/qemu/-/pipelines/375324015/failures




Interesting :(

I've reproduced, starting test-replication in several parallel loops. (it 
doesn't reproduce for me if just start in one loop). So, that's some racy bug..

Hmm, and seems it doesn't reproduce so simple on master. I'll try to bisect the 
series tomorrow.



(gdb) bt
#0  0x7f034a3d09d5 in raise () from /lib64/libc.so.6
#1  0x7f034a3b9954 in abort () from /lib64/libc.so.6
#2  0x7f034a3b9789 in __assert_fail_base.cold () from /lib64/libc.so.6
#3  0x7f034a3c9026 in __assert_fail () from /lib64/libc.so.6
#4  0x55d3b503d670 in job_state_transition (job=0x55d3b5e67020, 
s1=JOB_STATUS_CONCLUDED) at ../job.c:186
#5  0x55d3b503e7c2 in job_conclude (job=0x55d3b5e67020) at ../job.c:652
#6  0x55d3b503eaa1 in job_finalize_single (job=0x55d3b5e67020) at 
../job.c:722
#7  0x55d3b503ecd1 in job_completed_txn_abort (job=0x55d3b5e67020) at 
../job.c:801
#8  0x55d3b503f2ea in job_cancel (job=0x55d3b5e67020, force=false) at 
../job.c:973
#9  0x55d3b503f360 in job_cancel_err (job=0x55d3b5e67020, 
errp=0x7fffcc997a80) at ../job.c:992
#10 0x55d3b503f576 in job_finish_sync (job=0x55d3b5e67020, finish=0x55d3b503f33f 
, errp=0x0) at ../job.c:1054
#11 0x55d3b503f3d0 in job_cancel_sync (job=0x55d3b5e67020, force=false) at 
../job.c:1008
#12 0x55d3b4ff14a3 in replication_close (bs=0x55d3b5e6ef80) at 
../block/replication.c:152
#13 0x55d3b50277fc in bdrv_close (bs=0x55d3b5e6ef80) at ../block.c:4677
#14 0x55d3b50286cf in bdrv_delete (bs=0x55d3b5e6ef80) at ../block.c:5100
#15 0x55d3b502ae3a in bdrv_unref (bs=0x55d3b5e6ef80) at ../block.c:6495
#16 0x55d3b5023a38 in bdrv_root_unref_child (child=0x55d3b5e4c690) at 
../block.c:3010
#17 0x55d3b5047998 in blk_remove_bs (blk=0x55d3b5e73b40) at 
../block/block-backend.c:845
#18 0x55d3b5046e38 in blk_delete (blk=0x55d3b5e73b40) at 
../block/block-backend.c:461
#19 0x55d3b50470dc in blk_unref (blk=0x55d3b5e73b40) at 
../block/block-backend.c:516
#20 0x55d3b4fdb20a in teardown_secondary () at 
../tests/unit/test-replication.c:367
#21 0x55d3b4fdb632 in test_secondary_continuous_replication () at 
../tests/unit/test-replication.c:504
#22 0x7f034b26979e in g_test_run_suite_internal () from 
/lib64/libglib-2.0.so.0
#23 0x7f034b26959b in g_test_run_suite_internal () from 
/lib64/libglib-2.0.so.0
#24 0x7f034b26959b in g_test_run_suite_internal () from 
/lib64/libglib-2.0.so.0
#25 0x7f034b269c8a in g_test_run_suite () from /lib64/libglib-2.0.so.0
#26 0x7f034b269ca5 in g_test_run () from /lib64/libglib-2.0.so.0
#27 0x55d3b4fdb9c0 in main (argc=1, argv=0x7fffcc998138) at 
../tests/unit/test-replication.c:613
(gdb) fr 4
#4  0x55d3b503d670 in job_state_transition (job=0x55d3b5e67020, 
s1=JOB_STATUS_CONCLUDED) at ../job.c:186
186 assert(JobSTT[s0][s1]);
(gdb) list
181 JobStatus s0 = job->status;
182 assert(s1 >= 0 && s1 < JOB_STATUS__MAX);
183 trace_job_state_transition(job, job->ret,
184    JobSTT[s0][s1] ? "allowed" : 
"disallowed",
185 

RE: [PATCH v3 0/9] hw/nvram: hw/arm: Introduce Xilinx eFUSE and BBRAM

[Tong Ho]

Hi Peter,

I will follow up with patches to fix the memory leaks.

Where can I get a copy of the Coverity reports that have the 10 issues you 
indicated?

Thanks,
Tong

-Original Message-
From: Peter Maydell  
Sent: Saturday, October 2, 2021 3:28 AM
To: Tong Ho 
Cc: qemu-arm ; QEMU Developers ; 
Alistair Francis ; Edgar E. Iglesias 

Subject: Re: [PATCH v3 0/9] hw/nvram: hw/arm: Introduce Xilinx eFUSE and BBRAM

On Fri, 17 Sept 2021 at 06:24, Tong Ho  wrote:
>
> This series implements the Xilinx eFUSE and BBRAM devices for the 
> Versal and ZynqMP product families.
>
> Furthermore, both new devices are connected to the xlnx-versal-virt 
> board and the xlnx-zcu102 board.
>
> See changes in docs/system/arm/xlnx-versal-virt.rst for detail.

Hi -- now this has landed upstream, Coverity points out a lot of memory leaks 
on error or logging paths, where the code does things like:

*** CID 1464071:  Resource leaks  (RESOURCE_LEAK)
/qemu/hw/nvram/xlnx-versal-efuse-ctrl.c: 628 in efuse_ctrl_reg_write()
622 dev = reg_array->mem.owner;
623 assert(dev);
624
625 s = XLNX_VERSAL_EFUSE_CTRL(dev);
626
627 if (addr != A_WR_LOCK && s->regs[R_WR_LOCK]) {
>>> CID 1464071:  Resource leaks  (RESOURCE_LEAK)
>>> Failing to save or free storage allocated by 
>>> "object_get_canonical_path((Object *)s)" leaks it.
628 qemu_log_mask(LOG_GUEST_ERROR,
629   "%s[reg_0x%02lx]: Attempt to write
locked register.\n",
630   object_get_canonical_path(OBJECT(s)), (long)addr);
631 } else {
632 register_write_memory(opaque, addr, data, size);
633 }

You need to free the memory here. A good pattern is how it's done in 
xlnx-zynqmp-can.c with g_autofree:

if (ARRAY_FIELD_EX32(s->regs, SOFTWARE_RESET_REGISTER, SRST)) {
g_autofree char *path = object_get_canonical_path(OBJECT(s));

qemu_log_mask(LOG_GUEST_ERROR, "%s: Attempting to transfer data while"
  " data while controller is in reset mode.\n",
  path);
return false;
}

Could somebody send some followup patches that fix all of these, please? (There 
are 10 coverity issues, covering probably all of the places where 
object_get_canonical_path() is used in this series.)

thanks
-- PMM

Re: [PATCH v4 0/2] x86/sev: Measured Linux SEV guest with kernel/initrd/cmdline

[Dov Murik]

On 04/10/2021 11:03, Paolo Bonzini wrote:
> Queued, thanks.  However, it would be nice to have a documentation of
> all our SEV firmware interfaces somewhere in docs/specs/.

Thanks Paolo.

I'll try to arrange a skeleton for such document.  So far I think we
have the following interfaces:

1. SEV_SECRET_GUID - Secret injection target page
2. SEV_INFO_BLOCK_GUID - Used (currently) for the SEV-ES AP reset vector
3. SEV_HASH_TABLE_RV_GUID - For hashes of kernel/initrd/cmdline


-Dov

Re: [PULL 00/12] jobs: mirror: Handle errors after READY cancel

[Hanna Reitz]

On 24.09.21 00:01, Vladimir Sementsov-Ogievskiy wrote:

22.09.2021 22:19, Vladimir Sementsov-Ogievskiy wrote:

22.09.2021 19:05, Richard Henderson wrote:

On 9/21/21 3:20 AM, Vladimir Sementsov-Ogievskiy wrote:
The following changes since commit 
326ff8dd09556fc2e257196c49f35009700794ac:


   Merge remote-tracking branch 
'remotes/jasowang/tags/net-pull-request' into staging (2021-09-20 
16:17:05 +0100)


are available in the Git repository at:

   https://src.openvz.org/scm/~vsementsov/qemu.git 
tags/pull-jobs-2021-09-21


for you to fetch changes up to 
c9489c04319cac75c76af8fc27c254f46e10214c:


   iotests: Add mirror-ready-cancel-error test (2021-09-21 11:56:11 
+0300)



mirror: Handle errors after READY cancel


Hanna Reitz (12):
   job: Context changes in job_completed_txn_abort()
   mirror: Keep s->synced on error
   mirror: Drop s->synced
   job: Force-cancel jobs in a failed transaction
   job: @force parameter for job_cancel_sync()
   jobs: Give Job.force_cancel more meaning
   job: Add job_cancel_requested()
   mirror: Use job_is_cancelled()
   mirror: Check job_is_cancelled() earlier
   mirror: Stop active mirroring after force-cancel
   mirror: Do not clear .cancelled
   iotests: Add mirror-ready-cancel-error test


This fails testing with errors like so:

Running test test-replication
test-replication: ../job.c:186: job_state_transition: Assertion 
`JobSTT[s0][s1]' failed.

ERROR test-replication - too few tests run (expected 13, got 8)
make: *** [Makefile.mtest:816: run-test-100] Error 1
Cleaning up project directory and file based variables
ERROR: Job failed: exit code 1

https://gitlab.com/qemu-project/qemu/-/pipelines/375324015/failures




Interesting :(

I've reproduced, starting test-replication in several parallel loops. 
(it doesn't reproduce for me if just start in one loop). So, that's 
some racy bug..


Hmm, and seems it doesn't reproduce so simple on master. I'll try to 
bisect the series tomorrow.




(gdb) bt
#0  0x7f034a3d09d5 in raise () from /lib64/libc.so.6
#1  0x7f034a3b9954 in abort () from /lib64/libc.so.6
#2  0x7f034a3b9789 in __assert_fail_base.cold () from 
/lib64/libc.so.6

#3  0x7f034a3c9026 in __assert_fail () from /lib64/libc.so.6
#4  0x55d3b503d670 in job_state_transition (job=0x55d3b5e67020, 
s1=JOB_STATUS_CONCLUDED) at ../job.c:186
#5  0x55d3b503e7c2 in job_conclude (job=0x55d3b5e67020) at 
../job.c:652
#6  0x55d3b503eaa1 in job_finalize_single (job=0x55d3b5e67020) at 
../job.c:722
#7  0x55d3b503ecd1 in job_completed_txn_abort 
(job=0x55d3b5e67020) at ../job.c:801
#8  0x55d3b503f2ea in job_cancel (job=0x55d3b5e67020, 
force=false) at ../job.c:973
#9  0x55d3b503f360 in job_cancel_err (job=0x55d3b5e67020, 
errp=0x7fffcc997a80) at ../job.c:992
#10 0x55d3b503f576 in job_finish_sync (job=0x55d3b5e67020, 
finish=0x55d3b503f33f , errp=0x0) at ../job.c:1054
#11 0x55d3b503f3d0 in job_cancel_sync (job=0x55d3b5e67020, 
force=false) at ../job.c:1008
#12 0x55d3b4ff14a3 in replication_close (bs=0x55d3b5e6ef80) at 
../block/replication.c:152
#13 0x55d3b50277fc in bdrv_close (bs=0x55d3b5e6ef80) at 
../block.c:4677
#14 0x55d3b50286cf in bdrv_delete (bs=0x55d3b5e6ef80) at 
../block.c:5100
#15 0x55d3b502ae3a in bdrv_unref (bs=0x55d3b5e6ef80) at 
../block.c:6495
#16 0x55d3b5023a38 in bdrv_root_unref_child 
(child=0x55d3b5e4c690) at ../block.c:3010
#17 0x55d3b5047998 in blk_remove_bs (blk=0x55d3b5e73b40) at 
../block/block-backend.c:845
#18 0x55d3b5046e38 in blk_delete (blk=0x55d3b5e73b40) at 
../block/block-backend.c:461
#19 0x55d3b50470dc in blk_unref (blk=0x55d3b5e73b40) at 
../block/block-backend.c:516
#20 0x55d3b4fdb20a in teardown_secondary () at 
../tests/unit/test-replication.c:367
#21 0x55d3b4fdb632 in test_secondary_continuous_replication () at 
../tests/unit/test-replication.c:504
#22 0x7f034b26979e in g_test_run_suite_internal () from 
/lib64/libglib-2.0.so.0
#23 0x7f034b26959b in g_test_run_suite_internal () from 
/lib64/libglib-2.0.so.0
#24 0x7f034b26959b in g_test_run_suite_internal () from 
/lib64/libglib-2.0.so.0
#25 0x7f034b269c8a in g_test_run_suite () from 
/lib64/libglib-2.0.so.0

#26 0x7f034b269ca5 in g_test_run () from /lib64/libglib-2.0.so.0
#27 0x55d3b4fdb9c0 in main (argc=1, argv=0x7fffcc998138) at 
../tests/unit/test-replication.c:613

(gdb) fr 4
#4  0x55d3b503d670 in job_state_transition (job=0x55d3b5e67020, 
s1=JOB_STATUS_CONCLUDED) at ../job.c:186

186 assert(JobSTT[s0][s1]);
(gdb) list
181 JobStatus s0 = job->status;
182 assert(s1 >= 0 && s1 < JOB_STATUS__MAX);
183 trace_job_state_transition(job, job->ret,
184    JobSTT[s0][s1] ? "allowed" : 
"disallowed",
185    

Re: [PATCH 11/12] macfb: add vertical blank interrupt

[Laurent Vivier]

Le 02/10/2021 à 13:00, Mark Cave-Ayland a écrit :
> The MacOS driver expects a 60.15Hz vertical blank interrupt to be generated by
> the framebuffer which in turn schedules the mouse driver via the Vertical 
> Retrace
> Manager.
> 
> Signed-off-by: Mark Cave-Ayland 
> ---
>  hw/display/macfb.c | 81 ++
>  include/hw/display/macfb.h |  8 
>  2 files changed, 89 insertions(+)
> 
> diff --git a/hw/display/macfb.c b/hw/display/macfb.c
> index 29f6ad8eba..60a203e67b 100644
> --- a/hw/display/macfb.c
> +++ b/hw/display/macfb.c
> @@ -33,9 +33,16 @@
>  #define DAFB_MODE_CTRL1 0x8
>  #define DAFB_MODE_CTRL2 0xc
>  #define DAFB_MODE_SENSE 0x1c
> +#define DAFB_INTR_MASK  0x104
> +#define DAFB_INTR_STAT  0x108
> +#define DAFB_INTR_CLEAR 0x10c
>  #define DAFB_RESET  0x200
>  #define DAFB_LUT0x213
>  
> +#define DAFB_INTR_VBL   0x4
> +
> +/* Vertical Blank period (60.15Hz) */
> +#define DAFB_INTR_VBL_PERIOD_NS 16625800
>  
>  /*
>   * Quadra sense codes taken from Apple Technical Note HW26:
> @@ -449,6 +456,32 @@ static void macfb_update_display(void *opaque)
>  macfb_draw_graphic(s);
>  }
>  
> +static void macfb_update_irq(MacfbState *s)
> +{
> +uint32_t irq_state = s->irq_state & s->irq_mask;
> +
> +if (irq_state) {
> +qemu_irq_raise(s->irq);
> +} else {
> +qemu_irq_lower(s->irq);
> +}
> +}
> +
> +static void macfb_vbl_timer(void *opaque)
> +{
> +MacfbState *s = opaque;
> +int64_t next_vbl;
> +
> +s->irq_state |= DAFB_INTR_VBL;
> +macfb_update_irq(s);
> +
> +/* 60 Hz irq */
> +next_vbl = (qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) +
> +DAFB_INTR_VBL_PERIOD_NS) /
> +DAFB_INTR_VBL_PERIOD_NS * DAFB_INTR_VBL_PERIOD_NS;
> +timer_mod(s->vbl_timer, next_vbl);

perhaps you can move this to a function and call it here and below?

> +}
> +
>  static void macfb_reset(MacfbState *s)
>  {
>  int i;
> @@ -477,6 +510,9 @@ static uint64_t macfb_ctrl_read(void *opaque,
>  case DAFB_MODE_CTRL2:
>  val = s->regs[addr >> 2];
>  break;
> +case DAFB_INTR_STAT:
> +val = s->irq_state;
> +break;
>  case DAFB_MODE_SENSE:
>  val = macfb_sense_read(s);
>  break;
> @@ -492,6 +528,8 @@ static void macfb_ctrl_write(void *opaque,
>   unsigned int size)
>  {
>  MacfbState *s = opaque;
> +int64_t next_vbl;
> +
>  switch (addr) {
>  case DAFB_MODE_VADDR1:
>  case DAFB_MODE_VADDR2:
> @@ -507,8 +545,25 @@ static void macfb_ctrl_write(void *opaque,
>  case DAFB_MODE_SENSE:
>  macfb_sense_write(s, val);
>  break;
> +case DAFB_INTR_MASK:
> +s->irq_mask = val;
> +if (val & DAFB_INTR_VBL) {
> +next_vbl = (qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) +
> +DAFB_INTR_VBL_PERIOD_NS) /
> +DAFB_INTR_VBL_PERIOD_NS * DAFB_INTR_VBL_PERIOD_NS;
> +timer_mod(s->vbl_timer, next_vbl);
> +} else {
> +timer_del(s->vbl_timer);
> +}
> +break;
> +case DAFB_INTR_CLEAR:
> +s->irq_state &= ~DAFB_INTR_VBL;
> +macfb_update_irq(s);
> +break;
>  case DAFB_RESET:
>  s->palette_current = 0;
> +s->irq_state &= ~DAFB_INTR_VBL;
> +macfb_update_irq(s);
>  break;
>  case DAFB_LUT:
>  s->color_palette[s->palette_current++] = val;
> @@ -586,6 +641,7 @@ static void macfb_common_realize(DeviceState *dev, 
> MacfbState *s, Error **errp)
>  s->vram_bit_mask = MACFB_VRAM_SIZE - 1;
>  memory_region_set_coalescing(>mem_vram);
>  
> +s->vbl_timer = timer_new_ns(QEMU_CLOCK_VIRTUAL, macfb_vbl_timer, s);
>  macfb_update_mode(s);
>  }
>  
> @@ -601,6 +657,16 @@ static void macfb_sysbus_realize(DeviceState *dev, Error 
> **errp)
>  
>  sysbus_init_mmio(SYS_BUS_DEVICE(s), >mem_ctrl);
>  sysbus_init_mmio(SYS_BUS_DEVICE(s), >mem_vram);
> +
> +qdev_init_gpio_out(dev, >irq, 1);
> +}
> +
> +static void macfb_nubus_set_irq(void *opaque, int n, int level)
> +{
> +MacfbNubusState *s = NUBUS_MACFB(opaque);
> +NubusDevice *nd = NUBUS_DEVICE(s);
> +
> +nubus_set_irq(nd, level);
>  }
>  
>  static void macfb_nubus_realize(DeviceState *dev, Error **errp)
> @@ -622,6 +688,19 @@ static void macfb_nubus_realize(DeviceState *dev, Error 
> **errp)
>  
>  memory_region_add_subregion(>slot_mem, DAFB_BASE, >mem_ctrl);
>  memory_region_add_subregion(>slot_mem, VIDEO_BASE, >mem_vram);
> +
> +ms->irq = qemu_allocate_irq(macfb_nubus_set_irq, s, 0);
> +}
> +
> +static void macfb_nubus_unrealize(DeviceState *dev)
> +{
> +MacfbNubusState *s = NUBUS_MACFB(dev);
> +MacfbNubusDeviceClass *ndc = NUBUS_MACFB_GET_CLASS(dev);
> +MacfbState *ms = >macfb;
> +
> +ndc->parent_unrealize(dev);
> +
> +qemu_free_irq(ms->irq);
>  }
>  
>  static void 

Re: [RFC] hw/arm/virt-acpi-build: Add IORT RMR regions to handle MSI nested binding

[Eric Auger]

Hi,

On 9/28/21 7:44 PM, Eric Auger wrote:
> To handle SMMUv3 nested stage support it is practical to
> expose the guest with reserved memory regions (RMRs)
> covering the IOVAs used by the host kernel to map
> physical MSI doorbells.
>
> Those IOVAs belong to [0x800, 0x810] matching
> MSI_IOVA_BASE and MSI_IOVA_LENGTH definitions in kernel
> arm-smmu-v3 driver. This is the window used to allocate
> IOVAs matching physical MSI doorbells.
>
> With those RMRs, the guest is forced to use a flat mapping
> for this range. Hence the assigned device is programmed
> with one IOVA from this range. Stage 1, owned by the guest
> has a flat mapping for this IOVA. Stage2, owned by the VMM
> then enforces a mapping from this IOVA to the physical
> MSI doorbell.
>
> At IORT table level, due to the single mapping flag being
> set on the ID mapping, 256 IORT RMR nodes need to be
> created per bus. This looks awkward from a specification
> and implementation point of view.
>
> This may also produce a warning at execution time:
> qemu-system-aarch64: warning: ACPI table size 114709 exceeds
> 65536 bytes, migration may not work
> (here with 5 pcie root ports, ie. 256 * 6 = 1536 RMR nodes!).
>
> The creation of those RMR nodes only is relevant if nested
> stage SMMU is in use, along with VFIO. As VFIO devices can be
> hotplugged, all RMRs need to be created in advance. Hence
> the patch introduces a new arm virt "nested-smmuv3" iommu type.
>
> Signed-off-by: Eric Auger 
> Suggested-by: Jean-Philippe Brucker 
>
> ---
>
> Instead of introducing a new IOMMU type, we could introduce
> an array of qdev_prop_reserved_region(s).
>
> Guest can parse the IORT RMR nodes with Shammer's series:
> [PATCH v7 0/9] ACPI/IORT: Support for IORT RMR node

While further testing the SMMUv3 nested stage use case I noticed we miss
a _DSM in the
the ACPI device object of the PCIe host bridge (function 5). This DSM
shall return 0 to indicate the OS must honour the PCI config the FW set
at boot time. Otherwise, the RMRs are not taken into account in

[PATCH v7 9/9] iommu/dma: Reserve any RMR regions associated with a dev
(https://www.spinics.net/lists/linux-acpi/msg102492.html)

if (!host->preserve_config)
+   return;

So this patch is not sufficient for enabling the whole use case

Thanks

Eric

>
> The patch applies on Igor's v4 series [1]+ IORT E.b upgrade [2]
> [1] [PATCH v4 00/35] acpi: refactor error prone build_header()
> and packed structures usage in ACPI tables
> [2] [PATCH 0/3] hw/arm/virt_acpi_build: Upgrate the IORT table
> up to revision E.b
> ---
>  include/hw/arm/virt.h|  7 
>  hw/arm/virt-acpi-build.c | 75 +---
>  hw/arm/virt.c|  7 +++-
>  3 files changed, 76 insertions(+), 13 deletions(-)
>
> diff --git a/include/hw/arm/virt.h b/include/hw/arm/virt.h
> index b461b8d261..f2f8aee219 100644
> --- a/include/hw/arm/virt.h
> +++ b/include/hw/arm/virt.h
> @@ -99,6 +99,7 @@ enum {
>  typedef enum VirtIOMMUType {
>  VIRT_IOMMU_NONE,
>  VIRT_IOMMU_SMMUV3,
> +VIRT_IOMMU_NESTED_SMMUV3,
>  VIRT_IOMMU_VIRTIO,
>  } VirtIOMMUType;
>  
> @@ -190,4 +191,10 @@ static inline int 
> virt_gicv3_redist_region_count(VirtMachineState *vms)
>  return MACHINE(vms)->smp.cpus > redist0_capacity ? 2 : 1;
>  }
>  
> +static inline bool virt_has_smmuv3(const VirtMachineState *vms)
> +{
> +return vms->iommu == VIRT_IOMMU_SMMUV3 ||
> +   vms->iommu == VIRT_IOMMU_NESTED_SMMUV3;
> +}
> +
>  #endif /* QEMU_ARM_VIRT_H */
> diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
> index ce9311ac19..79842dea4c 100644
> --- a/hw/arm/virt-acpi-build.c
> +++ b/hw/arm/virt-acpi-build.c
> @@ -245,16 +245,16 @@ static void acpi_dsdt_add_tpm(Aml *scope, 
> VirtMachineState *vms)
>  #define ROOT_COMPLEX_ENTRY_SIZE 36
>  #define IORT_NODE_OFFSET 48
>  
> -static void build_iort_id_mapping(GArray *table_data, uint32_t input_base,
> -  uint32_t id_count, uint32_t out_ref)
> +static void
> +build_iort_id_mapping(GArray *table_data, uint32_t input_base,
> +  uint32_t id_count, uint32_t out_ref, uint32_t flags)
>  {
>  /* Table 4 ID mapping format */
>  build_append_int_noprefix(table_data, input_base, 4); /* Input base */
>  build_append_int_noprefix(table_data, id_count, 4); /* Number of IDs */
>  build_append_int_noprefix(table_data, input_base, 4); /* Output base */
>  build_append_int_noprefix(table_data, out_ref, 4); /* Output Reference */
> -/* Flags */
> -build_append_int_noprefix(table_data, 0 /* Single mapping */, 4);
> +build_append_int_noprefix(table_data, flags, 4); /* Flags */
>  }
>  
>  struct AcpiIortIdMapping {
> @@ -296,6 +296,49 @@ static int iort_idmap_compare(gconstpointer a, 
> gconstpointer b)
>  return idmap_a->input_base - idmap_b->input_base;
>  }
>  
> +static void
> +build_iort_rmr_node(GArray *table_data, GArray *smmu_idmaps, int 
> 

Re: [RFC PATCH] .github: move repo lockdown to the v2 configuration

[Willian Rampazzo]

On Mon, Oct 4, 2021 at 12:45 PM Alex Bennée  wrote:
>
> I was getting prompted by GitHub for new permissions but it turns out
> per https://github.com/dessant/repo-lockdown/issues/6:
>
>   Repo Lockdown has been rewritten for GitHub Actions, offering new
>   features and better control over your automation presets. The legacy
>   GitHub App has been deprecated, and the public instance of the app
>   has been shut down.
>
> So this is what I've done.
>
> Signed-off-by: Alex Bennée 
> ---
>  .github/lockdown.yml   | 34 
>  .github/workflows/lockdown.yml | 47 ++
>  2 files changed, 47 insertions(+), 34 deletions(-)
>  delete mode 100644 .github/lockdown.yml
>  create mode 100644 .github/workflows/lockdown.yml
>
> diff --git a/.github/lockdown.yml b/.github/lockdown.yml
> deleted file mode 100644
> index d3546bd2bc..00
> --- a/.github/lockdown.yml
> +++ /dev/null
> @@ -1,34 +0,0 @@
> -# Configuration for Repo Lockdown - https://github.com/dessant/repo-lockdown
> -
> -# Close issues and pull requests
> -close: true
> -
> -# Lock issues and pull requests
> -lock: true
> -
> -issues:
> -  comment: |
> -Thank you for your interest in the QEMU project.
> -
> -This repository is a read-only mirror of the project's repostories hosted
> -at https://gitlab.com/qemu-project/qemu.git.
> -The project does not process issues filed on GitHub.
> -
> -The project issues are tracked on GitLab:
> -https://gitlab.com/qemu-project/qemu/-/issues
> -
> -QEMU welcomes bug report contributions. You can file new ones on:
> -https://gitlab.com/qemu-project/qemu/-/issues/new
> -
> -pulls:
> -  comment: |
> -Thank you for your interest in the QEMU project.
> -
> -This repository is a read-only mirror of the project's repostories hosted
> -on https://gitlab.com/qemu-project/qemu.git.
> -The project does not process merge requests filed on GitHub.
> -
> -QEMU welcomes contributions of code (either fixing bugs or adding new
> -functionality). However, we get a lot of patches, and so we have some
> -guidelines about contributing on the project website:
> -https://www.qemu.org/contribute/
> diff --git a/.github/workflows/lockdown.yml b/.github/workflows/lockdown.yml
> new file mode 100644
> index 00..20e6208487
> --- /dev/null
> +++ b/.github/workflows/lockdown.yml
> @@ -0,0 +1,47 @@
> +# Configuration for Repo Lockdown - https://github.com/dessant/repo-lockdown
> +
> +name: 'Repo Lockdown'
> +
> +on:
> +  issues:
> +types: opened

I see the "issues" tab is already disabled on the QEMU repository at
GitHub. Maybe we don't need an action for that.

> +  pull_request_target:
> +types: opened
> +
> +permissions:
> +  issues: write
> +  pull-requests: write
> +
> +jobs:
> +  action:
> +runs-on: ubuntu-latest
> +steps:
> +  - uses: dessant/repo-lockdown@v2
> +with:
> +  issue-comment: |
> +Thank you for your interest in the QEMU project.
> +
> +This repository is a read-only mirror of the project's 
> repostories hosted
> +at https://gitlab.com/qemu-project/qemu.git.
> +The project does not process issues filed on GitHub.
> +
> +The project issues are tracked on GitLab:
> +https://gitlab.com/qemu-project/qemu/-/issues
> +
> +QEMU welcomes bug report contributions. You can file new ones on:
> +https://gitlab.com/qemu-project/qemu/-/issues/new
> +  lock-issue: true
> +  close-issue: true
> +  pull-comment: |
> +Thank you for your interest in the QEMU project.
> +
> +This repository is a read-only mirror of the project's 
> repostories hosted
> +on https://gitlab.com/qemu-project/qemu.git.
> +The project does not process merge requests filed on GitHub.
> +
> +QEMU welcomes contributions of code (either fixing bugs or 
> adding new
> +functionality). However, we get a lot of patches, and so we have 
> some
> +guidelines about contributing on the project website:
> +https://www.qemu.org/contribute/
> +  lock-pull: true
> +  close-pull: true
> --
> 2.30.2
>
>

Besides the "issues" comment, it looks good to me.

Reviewed-by: Willian Rampazzo 

Re: [PATCH v3 01/19] docs/devel: rename file for writing monitor commands

[Eric Blake]

On Thu, Sep 30, 2021 at 02:23:31PM +0100, Daniel P. Berrangé wrote:
> The file already covers writing HMP commands, in addition to
> the QMP commands, so it deserves a more general name.
> 
> Signed-off-by: Daniel P. Berrangé 
> ---
>  docs/devel/index.rst| 2 +-
>  ...riting-qmp-commands.rst => writing-monitor-commands.rst} | 6 +++---
>  2 files changed, 4 insertions(+), 4 deletions(-)
>  rename docs/devel/{writing-qmp-commands.rst => writing-monitor-commands.rst} 
> (99%)

Reviewed-by: Eric Blake 

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

[PATCH 0/4] aspeed/smc: Improve support for the alternate boot function

[Cédric Le Goater]

Hello,

The Aspeed SoCs have a dual boot function for firmware fail-over
recovery. The system auto-reboots from the second flash if the main
flash does not boot successfully within a certain amount of time. This
function is called alternate boot (ABR) in the FMC controllers.

On the AST2600, the ABR registers controlling the 2nd watchdog timer
were moved from the watchdog register to the FMC controller. To
control WDT2 through the FMC model register set, this series creates a
local address space on top of WDT2 memory region.

To test on the fuji-bmc machine, run :

devmem 0x1e620064
devmem 0x1e78504C 

devmem 0x1e620064 32 0x
devmem 0x1e620064
devmem 0x1e78504C

Thanks

C.


Cédric Le Goater (4):
  aspeed/wdt: Add trace events
  aspeed/smc: Dump address offset in trace events
  aspeed/wdt: Add an alias for the MMIO region
  aspeed/smc: Improve support for the alternate boot function

 include/hw/ssi/aspeed_smc.h  |  3 ++
 include/hw/watchdog/wdt_aspeed.h |  1 +
 hw/arm/aspeed_ast2600.c  |  2 +
 hw/ssi/aspeed_smc.c  | 84 ++--
 hw/watchdog/wdt_aspeed.c | 20 ++--
 hw/ssi/trace-events  |  1 +
 hw/watchdog/trace-events |  4 ++
 7 files changed, 107 insertions(+), 8 deletions(-)

-- 
2.31.1

Re: [PATCH v3 07/19] qapi: introduce x-query-roms QMP command

[Daniel P . Berrangé]

On Mon, Oct 04, 2021 at 01:32:14PM +0100, Dr. David Alan Gilbert wrote:
> * Daniel P. Berrangé (berra...@redhat.com) wrote:
> > This is a counterpart to the HMP "info roms" command. It is being
> > added with an "x-" prefix because this QMP command is intended as an
> > adhoc debugging tool and will thus not be modelled in QAPI as fully
> > structured data, nor will it have long term guaranteed stability.
> > The existing HMP command is rewritten to call the QMP command.
> > 
> > Signed-off-by: Daniel P. Berrangé 
> > ---
> >  hw/core/loader.c| 53 +
> >  hw/core/machine-qmp-cmds.c  |  1 +
> >  include/qapi/type-helpers.h | 14 ++
> >  qapi/common.json| 11 
> >  qapi/machine.json   | 12 +
> >  qapi/meson.build|  3 +++
> >  qapi/qapi-type-helpers.c| 23 
> >  7 files changed, 100 insertions(+), 17 deletions(-)
> >  create mode 100644 include/qapi/type-helpers.h
> >  create mode 100644 qapi/qapi-type-helpers.c
> > 
> > diff --git a/hw/core/loader.c b/hw/core/loader.c
> > index c623318b73..5ebdca3087 100644
> > --- a/hw/core/loader.c
> > +++ b/hw/core/loader.c
> > @@ -46,6 +46,8 @@
> >  #include "qemu-common.h"
> >  #include "qemu/datadir.h"
> >  #include "qapi/error.h"
> > +#include "qapi/qapi-commands-machine.h"
> > +#include "qapi/type-helpers.h"
> >  #include "trace.h"
> >  #include "hw/hw.h"
> >  #include "disas/disas.h"
> > @@ -1472,32 +1474,49 @@ void *rom_ptr_for_as(AddressSpace *as, hwaddr addr, 
> > size_t size)
> >  return cbdata.rom;
> >  }
> >  
> > -void hmp_info_roms(Monitor *mon, const QDict *qdict)
> > +HumanReadableText *qmp_x_query_roms(Error **errp)
> >  {
> >  Rom *rom;
> > +g_autoptr(GString) buf = g_string_new("");
> >  
> >  QTAILQ_FOREACH(rom, , next) {
> >  if (rom->mr) {
> > -monitor_printf(mon, "%s"
> > -   " size=0x%06zx name=\"%s\"\n",
> > -   memory_region_name(rom->mr),
> > -   rom->romsize,
> > -   rom->name);
> > +g_string_append_printf(buf, "%s"
> > +   " size=0x%06zx name=\"%s\"\n",
> > +   memory_region_name(rom->mr),
> > +   rom->romsize,
> > +   rom->name);
> >  } else if (!rom->fw_file) {
> > -monitor_printf(mon, "addr=" TARGET_FMT_plx
> > -   " size=0x%06zx mem=%s name=\"%s\"\n",
> > -   rom->addr, rom->romsize,
> > -   rom->isrom ? "rom" : "ram",
> > -   rom->name);
> > +g_string_append_printf(buf, "addr=" TARGET_FMT_plx
> > +   " size=0x%06zx mem=%s name=\"%s\"\n",
> > +   rom->addr, rom->romsize,
> > +   rom->isrom ? "rom" : "ram",
> > +   rom->name);
> >  } else {
> > -monitor_printf(mon, "fw=%s/%s"
> > -   " size=0x%06zx name=\"%s\"\n",
> > -   rom->fw_dir,
> > -   rom->fw_file,
> > -   rom->romsize,
> > -   rom->name);
> > +g_string_append_printf(buf, "fw=%s/%s"
> > +   " size=0x%06zx name=\"%s\"\n",
> > +   rom->fw_dir,
> > +   rom->fw_file,
> > +   rom->romsize,
> > +   rom->name);
> >  }
> >  }
> > +
> > +return human_readable_text_from_str(buf);
> > +}
> > +
> > +
> > +void hmp_info_roms(Monitor *mon, const QDict *qdict)
> > +{
> > +Error *err = NULL;
> > +g_autoptr(HumanReadableText) info = qmp_x_query_roms();
> > +
> > +if (err) {
> > +error_report_err(err);
> > +return;
> > +}
> > +
> > +monitor_printf(mon, "%s", info->human_readable_text);
> 
> This is getting copied in each one of these; it looks like you need
> either:
>   a) A helper function like:
>void hmp_info_from_qmp(Monitor *mon, HumanReadableText *(void)func) 
>{
>...
>}
> 
>   b) Or teach the hmp parser to do the calls?


This pattern is repeated in many, but not all, or the handlers in
this series, because I started with the easy cases of no-arg 'info'
commands. There's a few exceptions such as commands which drive off
the currently selected CPU state.  I'm not convince it is worth
adding specials to the hmp parser, since it will only be used for
a subset of the commands lng term. A helper function though could
do the job, since I've already introduced a helper for the QMP
side converting GString to HumanReadableText


Regards,
Daniel
-- 
|: https://berrange.com   

[PATCH 4/4] aspeed/smc: Improve support for the alternate boot function

[Cédric Le Goater]

Map the WDT2 registers in the AST2600 FMC memory region by creating a
local address space on top of WDT2 memory region.

The model only implements the enable bit of the control register. The
reload register uses a 0.1s unit instead of a 1us. Values are
converted on the fly when doing the accesses. The restart register is
the same.

Cc: Peter Delevoryas 
Signed-off-by: Cédric Le Goater 
---
 include/hw/ssi/aspeed_smc.h |  3 ++
 hw/arm/aspeed_ast2600.c |  2 +
 hw/ssi/aspeed_smc.c | 78 -
 hw/ssi/trace-events |  1 +
 4 files changed, 82 insertions(+), 2 deletions(-)

diff --git a/include/hw/ssi/aspeed_smc.h b/include/hw/ssi/aspeed_smc.h
index 75bc793bd269..ad3c80f2d809 100644
--- a/include/hw/ssi/aspeed_smc.h
+++ b/include/hw/ssi/aspeed_smc.h
@@ -76,6 +76,9 @@ struct AspeedSMCState {
 MemoryRegion *dram_mr;
 AddressSpace dram_as;
 
+AddressSpace wdt2_as;
+MemoryRegion *wdt2_mr;
+
 AspeedSMCFlash flashes[ASPEED_SMC_CS_MAX];
 
 uint8_t snoop_index;
diff --git a/hw/arm/aspeed_ast2600.c b/hw/arm/aspeed_ast2600.c
index 0384357a9510..2c53d77899a8 100644
--- a/hw/arm/aspeed_ast2600.c
+++ b/hw/arm/aspeed_ast2600.c
@@ -353,6 +353,8 @@ static void aspeed_soc_ast2600_realize(DeviceState *dev, 
Error **errp)
 }
 
 /* FMC, The number of CS is set at the board level */
+object_property_set_link(OBJECT(>fmc), "wdt2", OBJECT(>wdt[2].iomem),
+ _abort);
 object_property_set_link(OBJECT(>fmc), "dram", OBJECT(s->dram_mr),
  _abort);
 if (!sysbus_realize(SYS_BUS_DEVICE(>fmc), errp)) {
diff --git a/hw/ssi/aspeed_smc.c b/hw/ssi/aspeed_smc.c
index 8a988c167604..1770985230b0 100644
--- a/hw/ssi/aspeed_smc.c
+++ b/hw/ssi/aspeed_smc.c
@@ -130,6 +130,8 @@
 #define   FMC_WDT2_CTRL_SINGLE_BOOT_MODE BIT(5)
 #define   FMC_WDT2_CTRL_BOOT_SOURCE  BIT(4) /* O: primary 1: alternate */
 #define   FMC_WDT2_CTRL_EN   BIT(0)
+#define R_FMC_WDT2_RELOAD   (0x68 / 4)
+#define R_FMC_WDT2_RESTART  (0x6C / 4)
 
 /* DMA Control/Status Register */
 #define R_DMA_CTRL(0x80 / 4)
@@ -704,6 +706,54 @@ static void aspeed_smc_reset(DeviceState *d)
 s->snoop_dummies = 0;
 }
 
+#define ASPEED_WDT_RELOAD  0x04
+#define ASPEED_WDT_RESTART 0x08
+#define ASPEED_WDT_CTRL0x0C
+
+static void aspeed_smc_wdt2_write(AspeedSMCState *s, uint32_t offset,
+  uint32_t value)
+{
+MemTxResult result;
+
+address_space_stl_le(>wdt2_as, offset, value, MEMTXATTRS_UNSPECIFIED,
+ );
+if (result != MEMTX_OK) {
+aspeed_smc_error("WDT2 write failed @%08x", offset);
+return;
+}
+}
+
+static uint64_t aspeed_smc_wdt2_read(AspeedSMCState *s, uint32_t offset)
+{
+MemTxResult result;
+uint32_t value;
+
+value = address_space_ldl_le(>wdt2_as, offset, MEMTXATTRS_UNSPECIFIED,
+);
+if (result != MEMTX_OK) {
+aspeed_smc_error("WDT2 read failed @%08x", offset);
+return -1;
+}
+return value;
+}
+
+static void aspeed_smc_wdt2_enable(AspeedSMCState *s, bool enable)
+{
+uint32_t value;
+
+value = aspeed_smc_wdt2_read(s, ASPEED_WDT_CTRL);
+if (value == -1) {
+return;
+}
+
+value &= ~BIT(0);
+value |= enable;
+
+aspeed_smc_wdt2_write(s, ASPEED_WDT_CTRL, value);
+
+trace_aspeed_smc_wdt2_enable(enable ? "en" : "dis");
+}
+
 static uint64_t aspeed_smc_read(void *opaque, hwaddr addr, unsigned int size)
 {
 AspeedSMCState *s = ASPEED_SMC(opaque);
@@ -718,7 +768,6 @@ static uint64_t aspeed_smc_read(void *opaque, hwaddr addr, 
unsigned int size)
 addr == R_CE_CMD_CTRL ||
 addr == R_INTR_CTRL ||
 addr == R_DUMMY_DATA ||
-(aspeed_smc_has_wdt_control(asc) && addr == R_FMC_WDT2_CTRL) ||
 (aspeed_smc_has_dma(asc) && addr == R_DMA_CTRL) ||
 (aspeed_smc_has_dma(asc) && addr == R_DMA_FLASH_ADDR) ||
 (aspeed_smc_has_dma(asc) && addr == R_DMA_DRAM_ADDR) ||
@@ -731,6 +780,10 @@ static uint64_t aspeed_smc_read(void *opaque, hwaddr addr, 
unsigned int size)
 trace_aspeed_smc_read(addr << 2, size, s->regs[addr]);
 
 return s->regs[addr];
+} else if (aspeed_smc_has_wdt_control(asc) && addr == R_FMC_WDT2_CTRL) {
+return aspeed_smc_wdt2_read(s, ASPEED_WDT_CTRL);
+} else if (aspeed_smc_has_wdt_control(asc) && addr == R_FMC_WDT2_RELOAD) {
+return aspeed_smc_wdt2_read(s, ASPEED_WDT_RELOAD) / 10;
 } else {
 qemu_log_mask(LOG_UNIMP, "%s: not implemented: 0x%" HWADDR_PRIx "\n",
   __func__, addr);
@@ -1053,7 +1106,11 @@ static void aspeed_smc_write(void *opaque, hwaddr addr, 
uint64_t data,
 } else if (addr == R_DUMMY_DATA) {
 s->regs[addr] = value & 0xff;
 } else if (aspeed_smc_has_wdt_control(asc) && addr == R_FMC_WDT2_CTRL) {
-s->regs[addr] = value & FMC_WDT2_CTRL_EN;
+

Re: [RFC PATCH v2 00/16] Initial support for machine creation via QMP

[Damien Hedde]

Hi,

This is both a ping and a small update. It would be great to have some 
feedback about patches 1 and 3.


Right now the device part of this series conflicts with Kevin 's work 
about replacing the QemuOpts by a QemuDict in device_add:

https://lists.gnu.org/archive/html/qemu-devel/2021-09/msg06136.html

So I'll have at least to rebase on top of his series, remove and rework 
some of the patches.


Maybe this series is too big and we should split it anyway ? We could 
for example target 3 smaller series:

 1. -> about stopping during the machine 'initialized' phase
 2. -> about enabling using device_add QMP commands during this phase
 3. -> about the sysbus device case (some of the patches are even 
independent)


Thanks,
Damien

On 9/22/21 18:13, Damien Hedde wrote:

Hi,

The goal of this work is to bring dynamic machine creation to QEMU:
we want to setup a machine without compiling a specific machine C
code. It would ease supporting highly configurable platforms (for
example resulting from an automated design flow). The requirements
for such configuration include begin able to specify the number of
cores, available peripherals, emmory mapping, IRQ mapping, etc.

This series focuses on the first step: populating a machine with
devices during its creation. We propose patches to support this
using QMP commands. This is a working set of patches and improves
over the earlier rfc (posted in May):
https://lists.gnu.org/archive/html/qemu-devel/2021-05/msg03706.html

Although it is working and could be merged, it is tag as an RFC:
we probably need to discuss the conditions for allowing a device to
be created at an early stage. Patches 6, 10 and 13, 15 and 16 depend
on such conditions and are subject to change. Other patches are
unrelated to this point.

We address several issues in this series. They are detailed below.

## 1. Stoping QEMU to populate the machine with devices

QEMU goes through several steps (called _machine phases_) when
creating the machine: 'no-machine', 'machine-created',
'accel-created', 'initialized', and finally 'ready'. At 'ready'
phase, QEMU is ready to start (see Paolo's page
https://wiki.qemu.org/User:Paolo_Bonzini/Machine_init_sequence for
more details).

Using the -preconfig CLI option, QEMU can be stopped today during
the 'accel-created' phase. Then the 'x-exit-preconfig' QMP command
triggers QEMU moving forwards to the completion of the machine
creation ('ready' phase).

The devices are created during the 'initialized' phase.
In this phase the machine init() method has been executed and thus
machine properties have been handled. Although the sysbus exists and
the machine may have been populated by the init(),
_machine_init_done_ notifiers have not been called yet. At this point
we can add more devices to a machine.

We propose to add 2 QMP commands:
+ The 'query-machine-phase' command would return the current machine
   phase.
+ The 'x-machine-init' command would advance the machine phase to
   'initialized'. 'x-exit-preconfig' could then still be used to
   advance to the last phase.

## 2. Adding devices

Right now, the user can create devices in 2 ways: using '-device' CLI
option or 'device_add' QMP command. Both are executed after the
machine is ready: such devices are hot-plugged. We propose to allow
'device_add' QMP command to be used during the 'initialized' phase.

In this series, we keep the constraint that the device must be
'user-creatable' (this is a device class flag). We do not see any
reason why a device the user can hot-plug could not be created at an
earlier stage.

This part is still RFC because, as Peter mentioned it (in this thread
https://lists.gnu.org/archive/html/qemu-devel/2021-08/msg01933.html),
we may want additional or distinct conditions for:
+ device we can hot-plug
+ device we can add in '-preconfig' (cold-plug)
We are open to suggestions. We could for example add a
'preconfig-creatable' or 'init-creatable' flag to device class, which
can identify a set of devices we can create this way.

The main addition is how we handle the case of sysbus devices. Sysbus
devices are particular because unlike, for example, pci devices, you
have to manually handle the memory mapping and interrupts wiring. So
right now, a sysbus device is dynamically creatable (using -device
CLI option or device_add QMP command) only if:
+ it is 'user_creatable' (like any other device),
+ and it is in the current machine sysbus device allow list.

In this series, we propose to relax the second constraint during the
earlier phases of machine creation so that when using -preconfig we
can create any 'user-creatable' sysbus device. When the machine
progresses to the 'ready' phase, sysbus devices creation will come
back to the legacy behavior: it will be possible only based on the
per-machine authorization basis.

For sysbus devices, wiring interrupts is not a problem as we can use
the 'qom-set' QMP command, but memory mapping is.

## 3. Memory mapping

There is no point allowing the 

[PATCH 3/4] aspeed/wdt: Add an alias for the MMIO region

[Cédric Le Goater]

Initialize the region in the instance_init handler because we will
want to link this region in the FMC object before the WDT object is
realized.

Cc: Peter Delevoryas 
Signed-off-by: Cédric Le Goater 
---
 include/hw/watchdog/wdt_aspeed.h |  1 +
 hw/watchdog/wdt_aspeed.c | 15 ---
 2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/include/hw/watchdog/wdt_aspeed.h b/include/hw/watchdog/wdt_aspeed.h
index f945cd6c5833..008e7d9b498c 100644
--- a/include/hw/watchdog/wdt_aspeed.h
+++ b/include/hw/watchdog/wdt_aspeed.h
@@ -29,6 +29,7 @@ struct AspeedWDTState {
 
 /*< public >*/
 MemoryRegion iomem;
+MemoryRegion iomem_alias;
 uint32_t regs[ASPEED_WDT_REGS_MAX];
 
 AspeedSCUState *scu;
diff --git a/hw/watchdog/wdt_aspeed.c b/hw/watchdog/wdt_aspeed.c
index 146ffcd71301..6426f3a77494 100644
--- a/hw/watchdog/wdt_aspeed.c
+++ b/hw/watchdog/wdt_aspeed.c
@@ -261,6 +261,16 @@ static void aspeed_wdt_timer_expired(void *dev)
 
 #define PCLK_HZ 2400
 
+static void aspeed_wdt_instance_init(Object *obj)
+{
+AspeedWDTState *s = ASPEED_WDT(obj);
+
+memory_region_init_io(>iomem, OBJECT(s), _wdt_ops, s,
+  TYPE_ASPEED_WDT, ASPEED_WDT_REGS_MAX * 4);
+memory_region_init_alias(>iomem_alias, OBJECT(s),
+ TYPE_ASPEED_WDT ".alias",
+ >iomem, 0, ASPEED_WDT_REGS_MAX * 4);
+}
 static void aspeed_wdt_realize(DeviceState *dev, Error **errp)
 {
 SysBusDevice *sbd = SYS_BUS_DEVICE(dev);
@@ -275,9 +285,7 @@ static void aspeed_wdt_realize(DeviceState *dev, Error 
**errp)
  */
 s->pclk_freq = PCLK_HZ;
 
-memory_region_init_io(>iomem, OBJECT(s), _wdt_ops, s,
-  TYPE_ASPEED_WDT, ASPEED_WDT_REGS_MAX * 4);
-sysbus_init_mmio(sbd, >iomem);
+sysbus_init_mmio(sbd, >iomem_alias);
 }
 
 static Property aspeed_wdt_properties[] = {
@@ -301,6 +309,7 @@ static void aspeed_wdt_class_init(ObjectClass *klass, void 
*data)
 static const TypeInfo aspeed_wdt_info = {
 .parent = TYPE_SYS_BUS_DEVICE,
 .name  = TYPE_ASPEED_WDT,
+.instance_init  = aspeed_wdt_instance_init,
 .instance_size  = sizeof(AspeedWDTState),
 .class_init = aspeed_wdt_class_init,
 .class_size= sizeof(AspeedWDTClass),
-- 
2.31.1

Re: [RFC PATCH 1/1] virtio: write back features before verify

[Cornelia Huck]

On Mon, Oct 04 2021, "Michael S. Tsirkin"  wrote:

> On Mon, Oct 04, 2021 at 04:33:21PM +0200, Cornelia Huck wrote:
>> On Mon, Oct 04 2021, "Michael S. Tsirkin"  wrote:
>> 
>> > On Mon, Oct 04, 2021 at 02:19:55PM +0200, Cornelia Huck wrote:
>> >> 
>> >> [cc:qemu-devel]
>> >> 
>> >> On Sat, Oct 02 2021, "Michael S. Tsirkin"  wrote:
>> >> 
>> >> > On Fri, Oct 01, 2021 at 09:21:25AM +0200, Halil Pasic wrote:
>> >> >> On Thu, 30 Sep 2021 07:12:21 -0400
>> >> >> "Michael S. Tsirkin"  wrote:
>> >> >> 
>> >> >> > On Thu, Sep 30, 2021 at 03:20:49AM +0200, Halil Pasic wrote:
>> >> >> > > This patch fixes a regression introduced by commit 82e89ea077b9
>> >> >> > > ("virtio-blk: Add validation for block size in config space") and
>> >> >> > > enables similar checks in verify() on big endian platforms.
>> >> >> > > 
>> >> >> > > The problem with checking multi-byte config fields in the verify
>> >> >> > > callback, on big endian platforms, and with a possibly transitional
>> >> >> > > device is the following. The verify() callback is called between
>> >> >> > > config->get_features() and virtio_finalize_features(). That we 
>> >> >> > > have a
>> >> >> > > device that offered F_VERSION_1 then we have the following options
>> >> >> > > either the device is transitional, and then it has to present the 
>> >> >> > > legacy
>> >> >> > > interface, i.e. a big endian config space until F_VERSION_1 is
>> >> >> > > negotiated, or we have a non-transitional device, which makes
>> >> >> > > F_VERSION_1 mandatory, and only implements the non-legacy 
>> >> >> > > interface and
>> >> >> > > thus presents a little endian config space. Because at this point 
>> >> >> > > we
>> >> >> > > can't know if the device is transitional or non-transitional, we 
>> >> >> > > can't
>> >> >> > > know do we need to byte swap or not.  
>> >> >> > 
>> >> >> > Hmm which transport does this refer to?
>> >> >> 
>> >> >> It is the same with virtio-ccw and virtio-pci. I see the same problem
>> >> >> with both on s390x. I didn't try with virtio-blk-pci-non-transitional
>> >> >> yet (have to figure out how to do that with libvirt) for pci I used
>> >> >> virtio-blk-pci.
>> >> >> 
>> >> >> > Distinguishing between legacy and modern drivers is transport
>> >> >> > specific.  PCI presents
>> >> >> > legacy and modern at separate addresses so distinguishing
>> >> >> > between these two should be no trouble.
>> >> >> 
>> >> >> You mean the device id? Yes that is bolted down in the spec, but
>> >> >> currently we don't exploit that information. Furthermore there
>> >> >> is a fat chance that with QEMU even the allegedly non-transitional
>> >> >> devices only present a little endian config space after VERSION_1
>> >> >> was negotiated. Namely get_config for virtio-blk is implemented in
>> >> >> virtio_blk_update_config() which does virtio_stl_p(vdev,
>> >> >> _size, blk_size) and in there we don't care
>> >> >> about transitional or not:
>> >> >> 
>> >> >> static inline bool virtio_access_is_big_endian(VirtIODevice *vdev)
>> >> >> {
>> >> >> #if defined(LEGACY_VIRTIO_IS_BIENDIAN)
>> >> >> return virtio_is_big_endian(vdev);
>> >> >> #elif defined(TARGET_WORDS_BIGENDIAN)
>> >> >> if (virtio_vdev_has_feature(vdev, VIRTIO_F_VERSION_1)) {
>> >> >> /* Devices conforming to VIRTIO 1.0 or later are always LE. */
>> >> >> return false;
>> >> >> }
>> >> >> return true;
>> >> >> #else
>> >> >> return false;
>> >> >> #endif
>> >> >> }
>> >> >> 
>> >> >
>> >> > ok so that's a QEMU bug. Any virtio 1.0 and up
>> >> > compatible device must use LE.
>> >> > It can also present a legacy config space where the
>> >> > endian depends on the guest.
>> >> 
>> >> So, how is the virtio core supposed to determine this? A
>> >> transport-specific callback?
>> >
>> > I'd say a field in VirtIODevice is easiest.
>> 
>> The transport needs to set this as soon as it has figured out whether
>> we're using legacy or not.
>
> Basically on each device config access?

Prior to the first one, I think. It should not change again, should it?

>
>> I guess we also need to fence off any
>> accesses respectively error out the device if the driver tries any
>> read/write operations that would depend on that knowledge?
>> 
>> And using a field in VirtIODevice would probably need some care when
>> migrating. Hm...
>
> It's just a shorthand to minimize changes. No need to migrate I think.

If we migrate in from an older QEMU, we don't know whether we are
dealing with legacy or not, until feature negotiation is already
done... don't we have to ask the transport?

Re: [PATCH v1 5/7] hw/arm/bcm2836: Add the BCM2711 which uses a GICv2

[Alex Bennée]

Alex Bennée  writes:

> From: Philippe Mathieu-Daudé 
>
> The BCM2711 is improvement of the BCM2837:
> - Cortex-A72 instead of the A53
> - peripheral block and local soc controller are mapped differently,
> - GICv2
> - PCIe block
> - exhanced MMU to address over 4GiB of SDRAM
>

> ---
> vAJB:

>   - move peri_base/ctrl to locations pointed to by DTB (0x7e00/0x4000)

> +
> +static void bcm2711_class_init(ObjectClass *oc, void *data)
> +{
> +DeviceClass *dc = DEVICE_CLASS(oc);
> +BCM283XClass *bc = BCM283X_CLASS(oc);
> +
> +bc->cpu_type = ARM_CPU_TYPE_NAME("cortex-a72");
> +bc->core_count = BCM283X_NCPUS;
> +bc->peri_base = 0x7e00;
> +bc->ctrl_base = 0x4000;
> +bc->clusterid = 0x0;
> +bc->gic_base = 0x4,
> +dc->realize = bcm2836_realize;
> +}

It turns out I was misreading the way you calculate addresses from DTS
files. Reverted to:

bc->peri_base = 0xfe00;
bc->ctrl_base = 0xff80;

-- 
Alex Bennée

[PATCH 2/4] aspeed/smc: Dump address offset in trace events

[Cédric Le Goater]

The register index is currently printed and this is confusing.

Signed-off-by: Cédric Le Goater 
---
 hw/ssi/aspeed_smc.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/hw/ssi/aspeed_smc.c b/hw/ssi/aspeed_smc.c
index 7129341c129e..8a988c167604 100644
--- a/hw/ssi/aspeed_smc.c
+++ b/hw/ssi/aspeed_smc.c
@@ -728,7 +728,7 @@ static uint64_t aspeed_smc_read(void *opaque, hwaddr addr, 
unsigned int size)
  addr < R_SEG_ADDR0 + asc->max_peripherals) ||
 (addr >= s->r_ctrl0 && addr < s->r_ctrl0 + asc->max_peripherals)) {
 
-trace_aspeed_smc_read(addr, size, s->regs[addr]);
+trace_aspeed_smc_read(addr << 2, size, s->regs[addr]);
 
 return s->regs[addr];
 } else {
@@ -1029,10 +1029,10 @@ static void aspeed_smc_write(void *opaque, hwaddr addr, 
uint64_t data,
 AspeedSMCClass *asc = ASPEED_SMC_GET_CLASS(s);
 uint32_t value = data;
 
-addr >>= 2;
-
 trace_aspeed_smc_write(addr, size, data);
 
+addr >>= 2;
+
 if (addr == s->r_conf ||
 (addr >= s->r_timings &&
  addr < s->r_timings + asc->nregs_timings) ||
-- 
2.31.1