Re: [PATCH v2 0/3] testing: Build WHPX enabled binaries

[no-reply]

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



Hi,

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

Message-id: 20190920113329.16787-1-phi...@redhat.com
Subject: [PATCH v2 0/3] testing: Build WHPX enabled binaries
Type: series

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

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
87eaddb .shippable.yml: Build WHPX enabled binaries
e5d4b91 tests/docker: Add fedora-win10sdk-cross image
52ca140 target/i386: Fix broken build with WHPX enabled

=== OUTPUT BEGIN ===
1/3 Checking commit 52ca14097b01 (target/i386: Fix broken build with WHPX 
enabled)
2/3 Checking commit e5d4b91b58ca (tests/docker: Add fedora-win10sdk-cross image)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#38: 
new file mode 100644

ERROR: line over 90 characters
#83: FILE: tests/docker/dockerfiles/win10sdk-dl.sh:12:
+BASE_URL=$(curl --silent --include 
'http://go.microsoft.com/fwlink/?prd=11966&pver=1.0&plcid=0x409&clcid=0x409&ar=Windows10&sar=SDK&o1=10.0.18362.1'
 | sed -nE 's_Location: (.*)/\r_\1_p')/Installers

ERROR: line over 90 characters
#88: FILE: tests/docker/dockerfiles/win10sdk-dl.sh:17:
+CAB_NAME=$(msiextract Windows\ SDK\ Desktop\ Headers\ x86-x86_en-us.msi 
3>&1 2>&3 3>&-| sed -nE "s_.*Error opening file $PWD/(.*): No such file or 
directory_\1_p")

WARNING: line over 80 characters
#95: FILE: tests/docker/dockerfiles/win10sdk-dl.sh:24:
+for inc in "${WINDIR}/Program Files/Windows 
Kits/10/Include/10.0.18362.0/um"/WinHv*; do

total: 2 errors, 2 warnings, 58 lines checked

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

3/3 Checking commit 87eaddbdd398 (.shippable.yml: Build WHPX enabled binaries)
=== OUTPUT END ===

Test command exited with code: 1


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

[PATCH v2 2/2] riscv: sifive_u: Add ethernet0 to the aliases node

[Bin Meng]

U-Boot expects this alias to be in place in order to fix up the mac
address of the ethernet node.

This is to keep in sync with Linux kernel commit below:
https://patchwork.kernel.org/patch/11133033/

Signed-off-by: Bin Meng 
Reviewed-by: Alistair Francis 

---

Changes in v2: None

 hw/riscv/sifive_u.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/hw/riscv/sifive_u.c b/hw/riscv/sifive_u.c
index 02dd761..1ac51e3 100644
--- a/hw/riscv/sifive_u.c
+++ b/hw/riscv/sifive_u.c
@@ -270,6 +270,10 @@ static void create_fdt(SiFiveUState *s, const struct 
MemmapEntry *memmap,
 s->soc.gem.conf.macaddr.a, ETH_ALEN);
 qemu_fdt_setprop_cell(fdt, nodename, "#address-cells", 1);
 qemu_fdt_setprop_cell(fdt, nodename, "#size-cells", 0);
+
+qemu_fdt_add_subnode(fdt, "/aliases");
+qemu_fdt_setprop_string(fdt, "/aliases", "ethernet0", nodename);
+
 g_free(nodename);
 
 nodename = g_strdup_printf("/soc/ethernet@%lx/ethernet-phy@0",
@@ -297,7 +301,6 @@ static void create_fdt(SiFiveUState *s, const struct 
MemmapEntry *memmap,
 qemu_fdt_setprop_string(fdt, "/chosen", "bootargs", cmdline);
 }
 
-qemu_fdt_add_subnode(fdt, "/aliases");
 qemu_fdt_setprop_string(fdt, "/aliases", "serial0", nodename);
 
 g_free(nodename);
-- 
2.7.4

[PATCH v2 1/2] riscv: hw: Drop "clock-frequency" property of cpu nodes

[Bin Meng]

The "clock-frequency" property of cpu nodes isn't required. Drop it.

This is to keep in sync with Linux kernel commit below:
https://patchwork.kernel.org/patch/11133031/

Signed-off-by: Bin Meng 
Reviewed-by: Alistair Francis 

---

Changes in v2:
- drop the one in spike and virt machines too

 hw/riscv/sifive_u.c | 2 --
 hw/riscv/spike.c| 2 --
 hw/riscv/virt.c | 2 --
 include/hw/riscv/sifive_u.h | 1 -
 include/hw/riscv/spike.h| 4 
 include/hw/riscv/virt.h | 4 
 6 files changed, 15 deletions(-)

diff --git a/hw/riscv/sifive_u.c b/hw/riscv/sifive_u.c
index 9f8e84b..02dd761 100644
--- a/hw/riscv/sifive_u.c
+++ b/hw/riscv/sifive_u.c
@@ -151,8 +151,6 @@ static void create_fdt(SiFiveUState *s, const struct 
MemmapEntry *memmap,
 char *intc = g_strdup_printf("/cpus/cpu@%d/interrupt-controller", cpu);
 char *isa;
 qemu_fdt_add_subnode(fdt, nodename);
-qemu_fdt_setprop_cell(fdt, nodename, "clock-frequency",
-  SIFIVE_U_CLOCK_FREQ);
 /* cpu 0 is the management hart that does not have mmu */
 if (cpu != 0) {
 qemu_fdt_setprop_string(fdt, nodename, "mmu-type", "riscv,sv48");
diff --git a/hw/riscv/spike.c b/hw/riscv/spike.c
index d60415d..8bbffbc 100644
--- a/hw/riscv/spike.c
+++ b/hw/riscv/spike.c
@@ -102,8 +102,6 @@ static void create_fdt(SpikeState *s, const struct 
MemmapEntry *memmap,
 char *intc = g_strdup_printf("/cpus/cpu@%d/interrupt-controller", cpu);
 char *isa = riscv_isa_string(&s->soc.harts[cpu]);
 qemu_fdt_add_subnode(fdt, nodename);
-qemu_fdt_setprop_cell(fdt, nodename, "clock-frequency",
-  SPIKE_CLOCK_FREQ);
 qemu_fdt_setprop_string(fdt, nodename, "mmu-type", "riscv,sv48");
 qemu_fdt_setprop_string(fdt, nodename, "riscv,isa", isa);
 qemu_fdt_setprop_string(fdt, nodename, "compatible", "riscv");
diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
index d36f562..1303061 100644
--- a/hw/riscv/virt.c
+++ b/hw/riscv/virt.c
@@ -161,8 +161,6 @@ static void create_fdt(RISCVVirtState *s, const struct 
MemmapEntry *memmap,
 char *intc = g_strdup_printf("/cpus/cpu@%d/interrupt-controller", cpu);
 char *isa = riscv_isa_string(&s->soc.harts[cpu]);
 qemu_fdt_add_subnode(fdt, nodename);
-qemu_fdt_setprop_cell(fdt, nodename, "clock-frequency",
-  VIRT_CLOCK_FREQ);
 qemu_fdt_setprop_string(fdt, nodename, "mmu-type", "riscv,sv48");
 qemu_fdt_setprop_string(fdt, nodename, "riscv,isa", isa);
 qemu_fdt_setprop_string(fdt, nodename, "compatible", "riscv");
diff --git a/include/hw/riscv/sifive_u.h b/include/hw/riscv/sifive_u.h
index e4df298..4850805 100644
--- a/include/hw/riscv/sifive_u.h
+++ b/include/hw/riscv/sifive_u.h
@@ -75,7 +75,6 @@ enum {
 };
 
 enum {
-SIFIVE_U_CLOCK_FREQ = 10,
 SIFIVE_U_HFCLK_FREQ = ,
 SIFIVE_U_RTCCLK_FREQ = 100
 };
diff --git a/include/hw/riscv/spike.h b/include/hw/riscv/spike.h
index 03d8703..dc77042 100644
--- a/include/hw/riscv/spike.h
+++ b/include/hw/riscv/spike.h
@@ -38,10 +38,6 @@ enum {
 SPIKE_DRAM
 };
 
-enum {
-SPIKE_CLOCK_FREQ = 10
-};
-
 #if defined(TARGET_RISCV32)
 #define SPIKE_V1_09_1_CPU TYPE_RISCV_CPU_RV32GCSU_V1_09_1
 #define SPIKE_V1_10_0_CPU TYPE_RISCV_CPU_RV32GCSU_V1_10_0
diff --git a/include/hw/riscv/virt.h b/include/hw/riscv/virt.h
index 6e5fbe5..68978a1 100644
--- a/include/hw/riscv/virt.h
+++ b/include/hw/riscv/virt.h
@@ -55,10 +55,6 @@ enum {
 VIRTIO_NDEV = 0x35 /* Arbitrary maximum number of interrupts */
 };
 
-enum {
-VIRT_CLOCK_FREQ = 10
-};
-
 #define VIRT_PLIC_HART_CONFIG "MS"
 #define VIRT_PLIC_NUM_SOURCES 127
 #define VIRT_PLIC_NUM_PRIORITIES 7
-- 
2.7.4

Re: [PATCH 03/21] hw: aspeed_scu: Add AST2600 support

[Joel Stanley]

On Fri, 20 Sep 2019 at 15:15, Cédric Le Goater  wrote:
>
> On 20/09/2019 06:10, Andrew Jeffery wrote:
> >
> >
> > On Thu, 19 Sep 2019, at 15:19, Cédric Le Goater wrote:
> >> From: Joel Stanley 
> >>
> >> The SCU controller on the AST2600 SoC has extra registers. Increase
> >> the number of regs of the model and introduce a new field in the class
> >> to customize the MemoryRegion operations depending on the SoC model.
> >>
> >> +switch (reg) {
> >> +case AST2600_PROT_KEY:
> >> +s->regs[reg] = (data == ASPEED_SCU_PROT_KEY) ? 1 : 0;
> >> +return;
> >> +case AST2600_HW_STRAP1:
> >> +case AST2600_HW_STRAP2:
> >> +if (s->regs[reg + 2]) {
> >> +return;
> >> +}
> >> +/* fall through */
> >> +case AST2600_SYS_RST_CTRL:
> >> +case AST2600_SYS_RST_CTRL2:
> >> +/* W1S (Write 1 to set) registers */
> >> +s->regs[reg] |= data;
> >> +return;
> >> +case AST2600_SYS_RST_CTRL_CLR:
> >> +case AST2600_SYS_RST_CTRL2_CLR:
> >> +case AST2600_HW_STRAP1_CLR:
> >> +case AST2600_HW_STRAP2_CLR:
> >> +/* W1C (Write 1 to clear) registers */
> >> +s->regs[reg] &= ~data;
> >
> > This clear should respect the protection register for each strap case.
>
> Joel,
>
> You are the expert ! :)

Someone could implement this if they wanted to. In the future it might
be useful to create a detailed model for the OTP and secure boot
behavior, and that can affect the strapping.

However it is not critical for running guests under qemu. I think we
should defer it until there is some guest code that needs the detailed
behavior.

Cheers,

Joel

[PATCH 6/7] target/alpha: Mask IOV exception with INV for user-only

[Richard Henderson]

The kernel masks the integer overflow exception with the
software invalid exception mask.  Include IOV in the set
of exception bits masked by fpcr_exc_enable.

Fixes the new float_convs test.

Signed-off-by: Richard Henderson 
---
 target/alpha/helper.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/target/alpha/helper.c b/target/alpha/helper.c
index 1b3479738b..55d7274d94 100644
--- a/target/alpha/helper.c
+++ b/target/alpha/helper.c
@@ -58,6 +58,13 @@ void cpu_alpha_store_fpcr(CPUAlphaState *env, uint64_t val)
  */
 uint32_t soft_fpcr = alpha_ieee_swcr_to_fpcr(env->swcr) >> 32;
 fpcr |= soft_fpcr & (FPCR_STATUS_MASK | FPCR_DNZ);
+
+/*
+ * The IOV exception is disabled by the kernel with SWCR_TRAP_ENABLE_INV,
+ * which got mapped by alpha_ieee_swcr_to_fpcr to FPCR_INVD.
+ * Add FPCR_IOV to fpcr_exc_enable so that it is handled identically.
+ */
+t |= CONVERT_BIT(soft_fpcr, FPCR_INVD, FPCR_IOV);
 #endif
 
 t |= CONVERT_BIT(fpcr, FPCR_INED, FPCR_INE);
-- 
2.17.1

[PATCH 4/7] target/alpha: Handle SWCR_MAP_DMZ earlier

[Richard Henderson]

Since we're converting the swcr to fpcr format for exceptions,
it's trivial to add FPCR_DNZ to the set of fpcr bits overriden.
No functional change.

Signed-off-by: Richard Henderson 
---
 target/alpha/helper.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/target/alpha/helper.c b/target/alpha/helper.c
index e21c488aa3..2f959c65ef 100644
--- a/target/alpha/helper.c
+++ b/target/alpha/helper.c
@@ -57,7 +57,7 @@ void cpu_alpha_store_fpcr(CPUAlphaState *env, uint64_t val)
  * the software exception mask.
  */
 uint32_t soft_fpcr = alpha_ieee_swcr_to_fpcr(env->swcr) >> 32;
-fpcr |= soft_fpcr & FPCR_STATUS_MASK;
+fpcr |= soft_fpcr & (FPCR_STATUS_MASK | FPCR_DNZ);
 #endif
 
 t |= CONVERT_BIT(fpcr, FPCR_INED, FPCR_INE);
@@ -73,9 +73,6 @@ void cpu_alpha_store_fpcr(CPUAlphaState *env, uint64_t val)
 env->fpcr_flush_to_zero = (fpcr & FPCR_UNFD) && (fpcr & FPCR_UNDZ);
 env->fp_status.flush_inputs_to_zero = (fpcr & FPCR_DNZ) != 0;
 #ifdef CONFIG_USER_ONLY
-if (env->swcr & SWCR_MAP_DMZ) {
-env->fp_status.flush_inputs_to_zero = 1;
-}
 if (env->swcr & SWCR_MAP_UMZ) {
 env->fpcr_flush_to_zero = 1;
 }
-- 
2.17.1

[PATCH 2/7] target/alpha: Fix SWCR_MAP_UMZ

[Richard Henderson]

We were setting the wrong bit.  The fp_status.flush_to_zero
setting is overwritten by either the constant 1 or the value
of fpcr_flush_to_zero depending on bits within an fp insn.

Signed-off-by: Richard Henderson 
---
 target/alpha/helper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/alpha/helper.c b/target/alpha/helper.c
index 6c1703682e..10602fb339 100644
--- a/target/alpha/helper.c
+++ b/target/alpha/helper.c
@@ -71,7 +71,7 @@ void cpu_alpha_store_fpcr(CPUAlphaState *env, uint64_t val)
 env->fp_status.flush_inputs_to_zero = 1;
 }
 if (env->swcr & SWCR_MAP_UMZ) {
-env->fp_status.flush_to_zero = 1;
+env->fpcr_flush_to_zero = 1;
 }
 env->fpcr_exc_enable &= ~(alpha_ieee_swcr_to_fpcr(env->swcr) >> 32);
 #endif
-- 
2.17.1

[PATCH 7/7] target/alpha: Tidy helper_fp_exc_raise_s

[Richard Henderson]

Remove a redundant masking of ignore.  Once that's gone it is
obvious that the system-mode inner test is redundant with the
outer test.  Move the fpcr_exc_enable masking up and tidy.

No functional change.

Signed-off-by: Richard Henderson 
---
 target/alpha/fpu_helper.c | 15 ---
 1 file changed, 4 insertions(+), 11 deletions(-)

diff --git a/target/alpha/fpu_helper.c b/target/alpha/fpu_helper.c
index 62a066d902..df8b58963b 100644
--- a/target/alpha/fpu_helper.c
+++ b/target/alpha/fpu_helper.c
@@ -90,25 +90,18 @@ void helper_fp_exc_raise_s(CPUAlphaState *env, uint32_t 
ignore, uint32_t regno)
 uint32_t exc = env->error_code & ~ignore;
 if (exc) {
 env->fpcr |= exc;
-exc &= ~ignore;
-#ifdef CONFIG_USER_ONLY
-/*
- * In user mode, the kernel's software handler only
- * delivers a signal if the exception is enabled.
- */
-if (!(exc & env->fpcr_exc_enable)) {
-return;
-}
-#else
+exc &= env->fpcr_exc_enable;
 /*
  * In system mode, the software handler gets invoked
  * for any non-ignored exception.
+ * In user mode, the kernel's software handler only
+ * delivers a signal if the exception is enabled.
  */
+#ifdef CONFIG_USER_ONLY
 if (!exc) {
 return;
 }
 #endif
-exc &= env->fpcr_exc_enable;
 fp_exc_raise1(env, GETPC(), exc, regno, EXC_M_SWC);
 }
 }
-- 
2.17.1

[PATCH 5/7] target/alpha: Write to fpcr_flush_to_zero once

[Richard Henderson]

Tidy the computation of the value; no functional change.

Signed-off-by: Richard Henderson 
---
 target/alpha/helper.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/target/alpha/helper.c b/target/alpha/helper.c
index 2f959c65ef..1b3479738b 100644
--- a/target/alpha/helper.c
+++ b/target/alpha/helper.c
@@ -69,14 +69,13 @@ void cpu_alpha_store_fpcr(CPUAlphaState *env, uint64_t val)
 env->fpcr_exc_enable = ~t & FPCR_STATUS_MASK;
 
 env->fpcr_dyn_round = rm_map[(fpcr & FPCR_DYN_MASK) >> FPCR_DYN_SHIFT];
-
-env->fpcr_flush_to_zero = (fpcr & FPCR_UNFD) && (fpcr & FPCR_UNDZ);
 env->fp_status.flush_inputs_to_zero = (fpcr & FPCR_DNZ) != 0;
+
+t = (fpcr & FPCR_UNFD) && (fpcr & FPCR_UNDZ);
 #ifdef CONFIG_USER_ONLY
-if (env->swcr & SWCR_MAP_UMZ) {
-env->fpcr_flush_to_zero = 1;
-}
+t |= (env->swcr & SWCR_MAP_UMZ) != 0;
 #endif
+env->fpcr_flush_to_zero = t;
 }
 
 uint64_t helper_load_fpcr(CPUAlphaState *env)
-- 
2.17.1

[PATCH 3/7] target/alpha: Fix SWCR_TRAP_ENABLE_MASK

[Richard Henderson]

The CONFIG_USER_ONLY adjustment blindly mashed the swcr
exception enable bits into the fpcr exception disable bits.

However, fpcr_exc_enable has already converted the exception
disable bits into the exception status bits in order to make
it easier to mask status bits at runtime.

Instead, merge the swcr enable bits with the fpcr before we
convert to status bits.

Signed-off-by: Richard Henderson 
---
 target/alpha/helper.c | 31 ++-
 1 file changed, 18 insertions(+), 13 deletions(-)

diff --git a/target/alpha/helper.c b/target/alpha/helper.c
index 10602fb339..e21c488aa3 100644
--- a/target/alpha/helper.c
+++ b/target/alpha/helper.c
@@ -46,19 +46,8 @@ void cpu_alpha_store_fpcr(CPUAlphaState *env, uint64_t val)
 uint32_t fpcr = val >> 32;
 uint32_t t = 0;
 
-t |= CONVERT_BIT(fpcr, FPCR_INED, FPCR_INE);
-t |= CONVERT_BIT(fpcr, FPCR_UNFD, FPCR_UNF);
-t |= CONVERT_BIT(fpcr, FPCR_OVFD, FPCR_OVF);
-t |= CONVERT_BIT(fpcr, FPCR_DZED, FPCR_DZE);
-t |= CONVERT_BIT(fpcr, FPCR_INVD, FPCR_INV);
-
+/* Record the raw value before adjusting for linux-user.  */
 env->fpcr = fpcr;
-env->fpcr_exc_enable = ~t & FPCR_STATUS_MASK;
-
-env->fpcr_dyn_round = rm_map[(fpcr & FPCR_DYN_MASK) >> FPCR_DYN_SHIFT];
-
-env->fpcr_flush_to_zero = (fpcr & FPCR_UNFD) && (fpcr & FPCR_UNDZ);
-env->fp_status.flush_inputs_to_zero = (fpcr & FPCR_DNZ) != 0;
 
 #ifdef CONFIG_USER_ONLY
 /*
@@ -67,13 +56,29 @@ void cpu_alpha_store_fpcr(CPUAlphaState *env, uint64_t val)
  * which point the kernel's handler would emulate and apply
  * the software exception mask.
  */
+uint32_t soft_fpcr = alpha_ieee_swcr_to_fpcr(env->swcr) >> 32;
+fpcr |= soft_fpcr & FPCR_STATUS_MASK;
+#endif
+
+t |= CONVERT_BIT(fpcr, FPCR_INED, FPCR_INE);
+t |= CONVERT_BIT(fpcr, FPCR_UNFD, FPCR_UNF);
+t |= CONVERT_BIT(fpcr, FPCR_OVFD, FPCR_OVF);
+t |= CONVERT_BIT(fpcr, FPCR_DZED, FPCR_DZE);
+t |= CONVERT_BIT(fpcr, FPCR_INVD, FPCR_INV);
+
+env->fpcr_exc_enable = ~t & FPCR_STATUS_MASK;
+
+env->fpcr_dyn_round = rm_map[(fpcr & FPCR_DYN_MASK) >> FPCR_DYN_SHIFT];
+
+env->fpcr_flush_to_zero = (fpcr & FPCR_UNFD) && (fpcr & FPCR_UNDZ);
+env->fp_status.flush_inputs_to_zero = (fpcr & FPCR_DNZ) != 0;
+#ifdef CONFIG_USER_ONLY
 if (env->swcr & SWCR_MAP_DMZ) {
 env->fp_status.flush_inputs_to_zero = 1;
 }
 if (env->swcr & SWCR_MAP_UMZ) {
 env->fpcr_flush_to_zero = 1;
 }
-env->fpcr_exc_enable &= ~(alpha_ieee_swcr_to_fpcr(env->swcr) >> 32);
 #endif
 }
 
-- 
2.17.1

[PATCH 0/7] target/alpha: Fix linux-user exception for CVTTQ

[Richard Henderson]

Alex's new float_convs test dies with SIGFPE for alpha-linux-user.

This is fixed in patch 6, where I mask the exception similar to how
the kernel would, when passed through the software completion handler.

Patches 2 & 3 fix bugs that I noticed in the process; the rest are
simple cleanup, trying to make the code better or easier.


r~


Richard Henderson (7):
  target/alpha: Use array for FPCR_DYN conversion
  target/alpha: Fix SWCR_MAP_UMZ
  target/alpha: Fix SWCR_TRAP_ENABLE_MASK
  target/alpha: Handle SWCR_MAP_DMZ earlier
  target/alpha: Write to fpcr_flush_to_zero once
  target/alpha: Mask IOV exception with INV for user-only
  target/alpha: Tidy helper_fp_exc_raise_s

 target/alpha/fpu_helper.c | 15 +++--
 target/alpha/helper.c | 68 +++
 2 files changed, 38 insertions(+), 45 deletions(-)

-- 
2.17.1

[PATCH 1/7] target/alpha: Use array for FPCR_DYN conversion

[Richard Henderson]

This is a bit more straight-forward than using a switch statement.
No functional change.

Signed-off-by: Richard Henderson 
---
 target/alpha/helper.c | 24 
 1 file changed, 8 insertions(+), 16 deletions(-)

diff --git a/target/alpha/helper.c b/target/alpha/helper.c
index 19cda0a2db..6c1703682e 100644
--- a/target/alpha/helper.c
+++ b/target/alpha/helper.c
@@ -36,6 +36,13 @@ uint64_t cpu_alpha_load_fpcr(CPUAlphaState *env)
 
 void cpu_alpha_store_fpcr(CPUAlphaState *env, uint64_t val)
 {
+static const uint8_t rm_map[] = {
+[FPCR_DYN_NORMAL >> FPCR_DYN_SHIFT] = float_round_nearest_even,
+[FPCR_DYN_CHOPPED >> FPCR_DYN_SHIFT] = float_round_to_zero,
+[FPCR_DYN_MINUS >> FPCR_DYN_SHIFT] = float_round_down,
+[FPCR_DYN_PLUS >> FPCR_DYN_SHIFT] = float_round_up,
+};
+
 uint32_t fpcr = val >> 32;
 uint32_t t = 0;
 
@@ -48,22 +55,7 @@ void cpu_alpha_store_fpcr(CPUAlphaState *env, uint64_t val)
 env->fpcr = fpcr;
 env->fpcr_exc_enable = ~t & FPCR_STATUS_MASK;
 
-switch (fpcr & FPCR_DYN_MASK) {
-case FPCR_DYN_NORMAL:
-default:
-t = float_round_nearest_even;
-break;
-case FPCR_DYN_CHOPPED:
-t = float_round_to_zero;
-break;
-case FPCR_DYN_MINUS:
-t = float_round_down;
-break;
-case FPCR_DYN_PLUS:
-t = float_round_up;
-break;
-}
-env->fpcr_dyn_round = t;
+env->fpcr_dyn_round = rm_map[(fpcr & FPCR_DYN_MASK) >> FPCR_DYN_SHIFT];
 
 env->fpcr_flush_to_zero = (fpcr & FPCR_UNFD) && (fpcr & FPCR_UNDZ);
 env->fp_status.flush_inputs_to_zero = (fpcr & FPCR_DNZ) != 0;
-- 
2.17.1

Re: [PATCH v12 00/11] Build ACPI Heterogeneous Memory Attribute Table (HMAT)

[no-reply]

Patchew URL: https://patchew.org/QEMU/20190920074349.2616-1-tao3...@intel.com/



Hi,

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

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

PASS 1 fdc-test /x86_64/fdc/cmos
PASS 2 fdc-test /x86_64/fdc/no_media_on_start
PASS 3 fdc-test /x86_64/fdc/read_without_media
==12418==WARNING: ASan doesn't fully support makecontext/swapcontext functions 
and may produce false positives in some cases!
PASS 4 fdc-test /x86_64/fdc/media_change
PASS 5 fdc-test /x86_64/fdc/sense_interrupt
PASS 6 fdc-test /x86_64/fdc/relative_seek
---
PASS 33 test-opts-visitor /visitor/opts/dict/unvisited
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  
tests/test-coroutine -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl 
--test-name="test-coroutine" 
PASS 11 fdc-test /x86_64/fdc/read_no_dma_18
==12466==WARNING: ASan doesn't fully support makecontext/swapcontext functions 
and may produce false positives in some cases!
==12466==WARNING: ASan is ignoring requested __asan_handle_no_return: stack 
top: 0x7ffe003de000; bottom 0x7ff9e34f8000; size: 0x00041cee6000 (17665253376)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
PASS 1 test-coroutine /basic/no-dangling-access
---
PASS 13 test-aio /aio/event/wait/no-flush-cb
PASS 12 fdc-test /x86_64/fdc/read_no_dma_19
PASS 13 fdc-test /x86_64/fdc/fuzz-registers
==12485==WARNING: ASan doesn't fully support makecontext/swapcontext functions 
and may produce false positives in some cases!
PASS 14 test-aio /aio/timer/schedule
PASS 15 test-aio /aio/coroutine/queue-chaining
PASS 16 test-aio /aio-gsource/flush
---
PASS 26 test-aio /aio-gsource/event/flush
PASS 27 test-aio /aio-gsource/event/wait/no-flush-cb
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  
QTEST_QEMU_BINARY=x86_64-softmmu/qemu-system-x86_64 QTEST_QEMU_IMG=qemu-img 
tests/ide-test -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl 
--test-name="ide-test" 
==12494==WARNING: ASan doesn't fully support makecontext/swapcontext functions 
and may produce false positives in some cases!
PASS 1 ide-test /x86_64/ide/identify
PASS 28 test-aio /aio-gsource/timer/schedule
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  
tests/test-aio-multithread -m=quick -k --tap < /dev/null | 
./scripts/tap-driver.pl --test-name="test-aio-multithread" 
==12500==WARNING: ASan doesn't fully support makecontext/swapcontext functions 
and may produce false positives in some cases!
==12506==WARNING: ASan doesn't fully support makecontext/swapcontext functions 
and may produce false positives in some cases!
PASS 1 test-aio-multithread /aio/multi/lifecycle
PASS 2 ide-test /x86_64/ide/flush
==12521==WARNING: ASan doesn't fully support makecontext/swapcontext functions 
and may produce false positives in some cases!
PASS 2 test-aio-multithread /aio/multi/schedule
PASS 3 ide-test /x86_64/ide/bmdma/simple_rw
==12532==WARNING: ASan doesn't fully support makecontext/swapcontext functions 
and may produce false positives in some cases!
PASS 3 test-aio-multithread /aio/multi/mutex/contended
PASS 4 ide-test /x86_64/ide/bmdma/trim
==12543==WARNING: ASan doesn't fully support makecontext/swapcontext functions 
and may produce false positives in some cases!
PASS 5 ide-test /x86_64/ide/bmdma/short_prdt
==12549==WARNING: ASan doesn't fully support makecontext/swapcontext functions 
and may produce false positives in some cases!
PASS 6 ide-test /x86_64/ide/bmdma/one_sector_short_prdt
==12555==WARNING: ASan doesn't fully support makecontext/swapcontext functions 
and may produce false positives in some cases!
PASS 4 test-aio-multithread /aio/multi/mutex/handoff
PASS 7 ide-test /x86_64/ide/bmdma/long_prdt
==12566==WARNING: ASan doesn't fully support makecontext/swapcontext functions 
and may produce false positives in some cases!
==12566==WARNING: ASan is ignoring requested __asan_handle_no_return: stack 
top: 0x7fff10f6d000; bottom 0x7f54b57fe000; size: 0x00aa5b76f000 (731678961664)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
PASS 5 test-aio-multithread /aio/multi/mutex/mcs
---
PASS 6 test-aio-multithread /aio/multi/mutex/pthread
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}  
tests/test-throttle -m=quick -k --tap < /dev/null | ./scripts/tap-driver.pl 
--test-name="test-throttle" 
PASS 9 ide-test /x86_64/ide/flush/nodev
==12584==WARNING: ASan doesn't fully support makecontext/swapcontext functions 
and may produce false positives in some cases!
PASS 1 test-throttle /throttle/leak_bucket
PASS 2 test-throttle /throttle/compute_wait
PASS 3 test-throttle /throttle/init
---
PASS 14 test-throt

Re: [PATCH v12 00/11] Build ACPI Heterogeneous Memory Attribute Table (HMAT)

[no-reply]

Patchew URL: https://patchew.org/QEMU/20190920074349.2616-1-tao3...@intel.com/



Hi,

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

=== TEST SCRIPT BEGIN ===
#!/bin/bash
make docker-image-centos7 V=1 NETWORK=1
time make docker-test-quick@centos7 SHOW_ENV=1 J=14 NETWORK=1
=== TEST SCRIPT END ===

libudev   no
default devices   yes

warning: Python 2 support is deprecated
warning: Python 3 will be required for building future versions of QEMU
cross containers  no

NOTE: guest cross-compilers enabled: cc
---
Looking for expected file 'tests/data/acpi/pc/SRAT.acpihmat'
Looking for expected file 'tests/data/acpi/pc/SRAT'
**
ERROR:/tmp/qemu-test/src/tests/bios-tables-test.c:327:load_expected_aml: 
assertion failed: (exp_sdt.aml_file)
ERROR - Bail out! 
ERROR:/tmp/qemu-test/src/tests/bios-tables-test.c:327:load_expected_aml: 
assertion failed: (exp_sdt.aml_file)
make: *** [check-qtest-x86_64] Error 1
make: *** Waiting for unfinished jobs
  TESTiotest-qcow2: 038


The full log is available at
http://patchew.org/logs/20190920074349.2616-1-tao3...@intel.com/testing.docker-quick@centos7/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

Migration failure when running nested VMs

[Jintack Lim]

Hi,

I'm seeing VM live migration failure when a VM is running a nested VM.
I'm using latest Linux kernel (v5.3) and QEMU (v4.1.0). I also tried
v5.2, but the result was the same. Kernel versions in L1 and L2 VM are
v4.18, but I don't think that matters.

The symptom is that L2 VM kernel crashes in different places after
migration but the call stack is mostly related to memory management
like [1] and [2]. The kernel crash happens almost all the time. While
L2 VM gets kernel panic, L1 VM runs fine after the migration. Both L1
and L2 VM were doing nothing during migration.

I found a few clues about this issue.
1) It happens with a relatively large memory for L1 (24G), but it does
not with a smaller size (3G).

2) Dead migration worked; when I ran "stop" command in the qemu
monitor for L1 first and did migration, migration worked always. It
also worked when I only stopped L2 VM and kept L1 live during the
migration.

With those two clues, I guess maybe some dirty pages made by L2 are
not transferred to the destination correctly, but I'm not really sure.

3) It happens on Intel(R) Xeon(R) Silver 4114 CPU, but it does not on
Intel(R) Xeon(R) CPU E5-2630 v3 CPU.

This makes me confused because I thought migrating nested state
doesn't depend on the underlying hardware.. Anyways, L1-only migration
with the large memory size (24G) works on both CPUs without any
problem.

I would appreciate any comments/suggestions to fix this problem.

Thanks,
Jintack


[1]https://paste.ubuntu.com/p/XGDKH45yt4/
[2]https://paste.ubuntu.com/p/CpbVTXJCyc/

Re: [PATCH 0/7] exec: Improve code for TARGET_PAGE_BITS_VARY

[no-reply]

Patchew URL: 
https://patchew.org/QEMU/20190919232952.6382-1-richard.hender...@linaro.org/



Hi,

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

Message-id: 20190919232952.6382-1-richard.hender...@linaro.org
Subject: [PATCH 0/7] exec: Improve code for TARGET_PAGE_BITS_VARY
Type: series

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

From https://github.com/patchew-project/qemu
 * [new tag] patchew/20190919232952.6382-1-richard.hender...@linaro.org 
-> patchew/20190919232952.6382-1-richard.hender...@linaro.org
Switched to a new branch 'test'
02b5da1 exec: Cache TARGET_PAGE_MASK for TARGET_PAGE_BITS_VARY
a7aca78 exec: Tidy TARGET_PAGE_ALIGN
daeccb0 exec: Promote TARGET_PAGE_MASK to target_long
265eec7 exec: Restrict TARGET_PAGE_BITS_VARY assert to CONFIG_DEBUG_TCG
583a7ed exec: Use const alias for TARGET_PAGE_BITS_VARY
a2dd788 exec: Split out variable page size support to exec-vary.c
cc49c84 exec: Use TARGET_PAGE_BITS_MIN for TLB flags

=== OUTPUT BEGIN ===
1/7 Checking commit cc49c847ff45 (exec: Use TARGET_PAGE_BITS_MIN for TLB flags)
2/7 Checking commit a2dd788d074f (exec: Split out variable page size support to 
exec-vary.c)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#32: 
new file mode 100644

total: 0 errors, 1 warnings, 125 lines checked

Patch 2/7 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
3/7 Checking commit 583a7eda4f9e (exec: Use const alias for 
TARGET_PAGE_BITS_VARY)
ERROR: externs should be avoided in .c files
#58: FILE: exec-vary.c:53:
+extern const TargetPageBits target_page

total: 1 errors, 0 warnings, 82 lines checked

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

4/7 Checking commit 265eec7a4f93 (exec: Restrict TARGET_PAGE_BITS_VARY assert 
to CONFIG_DEBUG_TCG)
5/7 Checking commit daeccb050033 (exec: Promote TARGET_PAGE_MASK to target_long)
6/7 Checking commit a7aca78b21b7 (exec: Tidy TARGET_PAGE_ALIGN)
7/7 Checking commit 02b5da125937 (exec: Cache TARGET_PAGE_MASK for 
TARGET_PAGE_BITS_VARY)
=== OUTPUT END ===

Test command exited with code: 1


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

Re: [PATCH v1 0/2] RISC-V: Convert to do_transaction_failed hook

[Palmer Dabbelt]

On Tue, 17 Sep 2019 16:22:56 PDT (-0700), Alistair Francis wrote:

The do_unassigned_access hook has been deprecated and RISC-V is the last
user of it. Let's instead update the RISC-V implementation to use
do_transaction_failed instead.

After this series I used the 'git grep' regexes in
docs/devel/loads-stores.rst and these are the memory accesses inside
target/riscv:

monitor.c:102:cpu_physical_memory_read(pte_addr, &pte, ptesize);

cpu_helper.c:262:target_ulong pte = address_space_ldl(cs->as, pte_addr, 
attrs, &res);
cpu_helper.c:264:target_ulong pte = address_space_ldq(cs->as, pte_addr, 
attrs, &res);

translate.c:782:ctx->opcode = cpu_ldl_code(env, ctx->base.pc_next);

gdbstub.c:328:env->fpr[n] = ldq_p(mem_buf); /* always 64-bit */

All of these look safe to me.

Palmer Dabbelt (2):
  RISC-V: Handle bus errors in the page table walker
  RISC-V: Implement cpu_do_transaction_failed


Can you Reviewed-By these, as they've still got my Author on them?  That way I 
can pull them in :)




 target/riscv/cpu.c|  2 +-
 target/riscv/cpu.h|  7 +--
 target/riscv/cpu_helper.c | 23 ---
 3 files changed, 22 insertions(+), 10 deletions(-)

Re: [RFC 2 PATCH 00/16] APIC ID fixes for AMD EPYC CPU models

[Moger, Babu]

Eduardo and all,
 Waiting for the feedback on this to move forward. Appreciate your time.
Thanks Babu

On 9/6/19 2:11 PM, Moger, Babu wrote:
> These series fixes the problems encoding APIC ID for AMD EPYC cpu models.
> https://bugzilla.redhat.com/show_bug.cgi?id=1728166
> 
> This is the second pass to give an idea of the changes required to address
> the issue. First pass is availabe at 
> https://patchwork.kernel.org/cover/11069785/
> 
> Currently, apic id is decoded based on sockets/dies/cores/threads. This 
> appears
> to work for most standard configurations for AMD and other vendors. But this
> decoding does not follow AMD's APIC ID enumeration. In some cases this
> causes CPU topology inconstancy. While booting guest Kernel is trying to
> validate topology. It finds the topology not aligning to EPYC models.
> 
> To fix the problem we need to build the topology as per the
> Processor Programming Reference (PPR) for AMD Family 17h Model 01h, Revision 
> B1
> Processors. It is available at https://www.amd.com/en/support/tech-docs
> 
> Here is the text from the PPR.
> 2.1.10.2.1.3
> ApicId Enumeration Requirements
> Operating systems are expected to use
> Core::X86::Cpuid::SizeId[ApicIdCoreIdSize], the number of least
> significant bits in the Initial APIC ID that indicate core ID within a
> processor, in constructing per-core CPUID
> masks. Core::X86::Cpuid::SizeId[ApicIdCoreIdSize] determines the maximum 
> number
> of cores (MNC) that the
> processor could theoretically support, not the actual number of cores that are
> actually implemented or enabled on
> the processor, as indicated by Core::X86::Cpuid::SizeId[NC].
> Each Core::X86::Apic::ApicId[ApicId] register is preset as follows:
> • ApicId[6] = Socket ID.
> • ApicId[5:4] = Node ID.
> • ApicId[3] = Logical CCX L3 complex ID
> • ApicId[2:0]= (SMT) ? {LogicalCoreID[1:0],ThreadId} :
> {1'b0,LogicalCoreID[1:0]}.
> """
> 
> v2:
>   1. Introduced the new property epyc to enable new epyc mode.
>   2. Separated the epyc mode and non epyc mode function.
>   3. Introduced function pointers in PCMachineState to handle the
>  differences.
>   4. Mildly tested different combinations to make things are working as 
> expected.
>   5. TODO : Setting the epyc feature bit needs to be worked out. This feature 
> is
>  supported only on AMD EPYC models. I may need some guidance on that.
> 
> v1:
>   https://patchwork.kernel.org/cover/11069785/
> 
> ---
> 
> Babu Moger (16):
>   numa: Split the numa functionality
>   hw/i386: Rename X86CPUTopoInfo structure to X86CPUTopoIDs
>   hw/i386: Introduce X86CPUTopoInfo to contain topology info
>   machine: Add SMP Sockets in CpuTopology
>   hw/i386: Simplify topology Offset/width Calculation
>   hw/core: Add core complex id in X86CPU topology
>   hw/386: Add new epyc mode topology decoding functions
>   i386: Cleanup and use the new epyc mode topology functions
>   hw/i386: Introduce initialize_topo_info function
>   hw/i386: Introduce apicid_from_cpu_idx in PCMachineState
>   Introduce-topo_ids_from_apicid-handler
>   hw/i386: Introduce apic_id_from_topo_ids handler in PCMachineState
>   machine: Add new epyc property in PCMachineState
>   hw/i386: Introduce epyc mode function handlers
>   i386: Fix pkg_id offset for epyc mode
>   hw/core: Fix up the machine_set_cpu_numa_node for epyc
> 
> 
>  hw/core/machine-hmp-cmds.c |3 
>  hw/core/machine.c  |   38 ++
>  hw/core/numa.c |  110 
>  hw/i386/pc.c   |  143 +++--
>  include/hw/boards.h|8 +
>  include/hw/i386/pc.h   |9 +
>  include/hw/i386/topology.h |  294 
> +++-
>  include/sysemu/numa.h  |2 
>  qapi/machine.json  |4 -
>  target/i386/cpu.c  |  209 +++
>  target/i386/cpu.h  |1 
>  vl.c   |3 
>  12 files changed, 560 insertions(+), 264 deletions(-)
> 
> --
> Signature
> 

Re: [PATCH v1 0/6] RISC-V: Add more machine memory

[Palmer Dabbelt]

On Thu, 19 Sep 2019 15:24:51 PDT (-0700), Alistair Francis wrote:

This series aims to improve the use of QEMU for developing boot code. It
does a few things:

 - sifive_u machine:
   - Adds a chunk of memory in the Flash area. This allows boot loaders
   to use this memory. I can't find details on the QSPI flash used on
   the real board, so this is the best bet at the moment.


IIRC it's a is25wp256.


   - Adds a chunk of memory in the L2-LIM area. This is actualy the L2
   cache and should shrink as the L2 cache is enalbed. Unfortunatley I
   don't see a nice way to shrink this memory.
   - Adds a property that allows users to specify if QEMU should jump to
   flash or DRAM after the ROM code.

 - virt machine:
   - Add the pflash_cfi01 flash device. This is based on the ARM virt
   board implementation
   - Adjusts QEMU to jump to the flash if a user has speciefied any
   pflash.

Both machines have been tested with oreboot, but this should also help
the coreboot developers.

Alistair Francis (6):
  riscv/sifive_u: Add L2-LIM cache memory
  riscv/sifive_u: Add QSPI memory region
  riscv/sifive_u: Manually define the machine
  riscv/sifive_u: Add the start-in-flash property
  riscv/virt: Add the PFlash CFI01 device
  riscv/virt: Jump to pflash if specified

 hw/riscv/Kconfig|  1 +
 hw/riscv/sifive_u.c | 77 +--
 hw/riscv/virt.c | 91 -
 include/hw/riscv/sifive_u.h | 11 -
 include/hw/riscv/virt.h |  3 ++
 5 files changed, 177 insertions(+), 6 deletions(-)

Re: [Qemu-devel] [PULL 04/32] target/riscv: Implement riscv_cpu_unassigned_access

[Palmer Dabbelt]

On Tue, 17 Sep 2019 09:37:47 PDT (-0700), alistai...@gmail.com wrote:

On Tue, Sep 17, 2019 at 6:56 AM Peter Maydell  wrote:


On Fri, 16 Aug 2019 at 09:57, Peter Maydell  wrote:
>
> On Thu, 15 Aug 2019 at 23:17, Palmer Dabbelt  wrote:
> > You're more than welcome to take them over.  I've got something that boots
> > Linux on my unassigned_access branch (github.com/palmer-dabbelt/qemu), but I
> > haven't sanitized the whole port for physical accesses and I haven't 
convinced
> > myself that my hook implementation is correct.
>
> Rather than doing
>if (retaddr) {
>cpu_restore_state(cs, retaddr, true);
>}
>
> at the start of the hook I think you just want to pass 'retaddr'
> as the final argument to riscv_raise_exception() instead of
> using GETPC(). Other than that I think the hook itself is right.
>
> The 'git grep' regexes in docs/devel/loads-stores.rst are handy
> for finding the places where the target code is doing physical
> accesses. IIRC the only ones I found with a quick scan were the
> PTE loads in get_physical_address() via ldl_phys/ldq_phys, which will
> now return 0 and run into the 'invalid PTE' code path. I don't
> know whether your architecture requires some different behaviour
> for bus errors on page table walk than that (you might want to
> specifically code the error path anyway or comment it even if the
> behaviour is right, to be a bit more explicit that it can happen).

Gentle ping -- would somebody like to have a go at the riscv
do_transaction_failed hook conversion? I think it should be
straightforward, and riscv is now the only architecture still
using the old unassigned_access hook and preventing us from
getting rid of it entirely.


Thanks for the ping Peter, I forgot about this.

@Palmer I have taken your patches, made some changes based on Peter's
comments and rebased them on your PR branch.

I'll double check, but the hook implementation looks correct and I
can't see any other obvious unsanitised physical accesses so it should
be ok. I'll send them out today if I don't find any issues.


Thanks!



Alistair



thanks
-- PMM

[PATCH v2 1/5] docker: move tests from python2 to python3

[John Snow]

As part of the push to drop python2 support, replace any explicit python2
dependencies with python3 versions.

For centos, python2 still exists as an implicit dependency, but by adding
python3 we will be able to build even if the configure script begins to
require python 3.5+.

Tested with centos7, fedora, ubuntu, ubuntu1804, and debian 9 (amd64).
Tested under a custom configure script that requires Python 3.5+.

the travis dockerfile is also moved to using python3, which was tested
by running `make docker-test-build@travis`, which I hope is sufficient.

Signed-off-by: John Snow 
Message-id: 20190920200049.27216-1-js...@redhat.com
---
 tests/docker/dockerfiles/centos7.docker | 2 +-
 tests/docker/dockerfiles/debian-ports.docker| 2 +-
 tests/docker/dockerfiles/debian-sid.docker  | 2 +-
 tests/docker/dockerfiles/debian-xtensa-cross.docker | 2 +-
 tests/docker/dockerfiles/debian10.docker| 2 +-
 tests/docker/dockerfiles/debian8.docker | 3 +--
 tests/docker/dockerfiles/debian9.docker | 2 +-
 tests/docker/dockerfiles/travis.docker  | 2 +-
 tests/docker/dockerfiles/ubuntu.docker  | 2 +-
 tests/docker/dockerfiles/ubuntu1804.docker  | 2 +-
 10 files changed, 10 insertions(+), 11 deletions(-)

diff --git a/tests/docker/dockerfiles/centos7.docker 
b/tests/docker/dockerfiles/centos7.docker
index e0b9d7dbe9..953637065c 100644
--- a/tests/docker/dockerfiles/centos7.docker
+++ b/tests/docker/dockerfiles/centos7.docker
@@ -25,6 +25,7 @@ ENV PACKAGES \
 nettle-devel \
 perl-Test-Harness \
 pixman-devel \
+python3 \
 SDL-devel \
 spice-glib-devel \
 spice-server-devel \
@@ -34,4 +35,3 @@ ENV PACKAGES \
 zlib-devel
 RUN yum install -y $PACKAGES
 RUN rpm -q $PACKAGES | sort > /packages.txt
-
diff --git a/tests/docker/dockerfiles/debian-ports.docker 
b/tests/docker/dockerfiles/debian-ports.docker
index 61bc3f2993..f1ea8d3bd1 100644
--- a/tests/docker/dockerfiles/debian-ports.docker
+++ b/tests/docker/dockerfiles/debian-ports.docker
@@ -31,6 +31,6 @@ RUN apt-get update && \
 git \
 pkg-config \
 psmisc \
-python \
+python3 \
 texinfo \
 $(apt-get -s build-dep qemu | egrep ^Inst | fgrep '[all]' | cut -d\  
-f2)
diff --git a/tests/docker/dockerfiles/debian-sid.docker 
b/tests/docker/dockerfiles/debian-sid.docker
index 2a1bcc33b2..dcb8e83715 100644
--- a/tests/docker/dockerfiles/debian-sid.docker
+++ b/tests/docker/dockerfiles/debian-sid.docker
@@ -31,5 +31,5 @@ RUN apt update && \
 git \
 pkg-config \
 psmisc \
-python \
+python3 \
 texinfo || { echo "Failed to build - see debian-sid.docker notes"; 
exit 1; }
diff --git a/tests/docker/dockerfiles/debian-xtensa-cross.docker 
b/tests/docker/dockerfiles/debian-xtensa-cross.docker
index b9c2e2e531..e6f93f65ee 100644
--- a/tests/docker/dockerfiles/debian-xtensa-cross.docker
+++ b/tests/docker/dockerfiles/debian-xtensa-cross.docker
@@ -18,7 +18,7 @@ RUN apt-get update && \
 flex \
 gettext \
 git \
-python-minimal
+python3-minimal
 
 ENV CPU_LIST csp dc232b dc233c
 ENV TOOLCHAIN_RELEASE 2018.02
diff --git a/tests/docker/dockerfiles/debian10.docker 
b/tests/docker/dockerfiles/debian10.docker
index 30a78813f2..dad498b52e 100644
--- a/tests/docker/dockerfiles/debian10.docker
+++ b/tests/docker/dockerfiles/debian10.docker
@@ -26,7 +26,7 @@ RUN apt update && \
 git \
 pkg-config \
 psmisc \
-python \
+python3 \
 python3-sphinx \
 texinfo \
 $(apt-get -s build-dep qemu | egrep ^Inst | fgrep '[all]' | cut -d\  
-f2)
diff --git a/tests/docker/dockerfiles/debian8.docker 
b/tests/docker/dockerfiles/debian8.docker
index 1212a85c35..be67023826 100644
--- a/tests/docker/dockerfiles/debian8.docker
+++ b/tests/docker/dockerfiles/debian8.docker
@@ -30,5 +30,4 @@ RUN apt update && \
 git \
 gnupg \
 pkg-config \
-python-minimal
-
+python3-minimal
diff --git a/tests/docker/dockerfiles/debian9.docker 
b/tests/docker/dockerfiles/debian9.docker
index b36f1d4ed8..8cbd742bb5 100644
--- a/tests/docker/dockerfiles/debian9.docker
+++ b/tests/docker/dockerfiles/debian9.docker
@@ -26,7 +26,7 @@ RUN apt update && \
 git \
 pkg-config \
 psmisc \
-python \
+python3 \
 python3-sphinx \
 texinfo \
 $(apt-get -s build-dep qemu | egrep ^Inst | fgrep '[all]' | cut -d\  
-f2)
diff --git a/tests/docker/dockerfiles/travis.docker 
b/tests/docker/dockerfiles/travis.docker
index e72dc85ca7..ea14da29d9 100644
--- a/tests/docker/dockerfiles/travis.docker
+++ b/tests/docker/dockerfiles/travis.docker
@@ -5,7 +5,7 @@ ENV LC_ALL en_US.UTF-8
 RUN sed -i "s/# deb-src/deb-src/" /etc/apt/sources.list
 RUN apt-get update
 RUN apt-get -y build-dep qemu
-RUN apt-get -y install device-tree-compiler python2.7 

Re: [PATCH v1 5/6] riscv/virt: Add the PFlash CFI01 device

[Alistair Francis]

On Thu, Sep 19, 2019 at 10:15 PM Bin Meng  wrote:
>
> On Fri, Sep 20, 2019 at 6:36 AM Alistair Francis
>  wrote:
> >
> > Add the CFI01 PFlash to the RISC-V virt board. This is the same PFlash
> > from the ARM Virt board and the implementation is based on the ARM Virt
> > board. This allows users to specify flash files from the command line.
> >
> > Signed-off-by: Alistair Francis 
> > ---
> >  hw/riscv/Kconfig|  1 +
> >  hw/riscv/virt.c | 81 +
> >  include/hw/riscv/virt.h |  3 ++
> >  3 files changed, 85 insertions(+)
> >
> > diff --git a/hw/riscv/Kconfig b/hw/riscv/Kconfig
> > index fb19b2df3a..b12660b9f8 100644
> > --- a/hw/riscv/Kconfig
> > +++ b/hw/riscv/Kconfig
> > @@ -36,4 +36,5 @@ config RISCV_VIRT
> >  select SERIAL
> >  select VIRTIO_MMIO
> >  select PCI_EXPRESS_GENERIC_BRIDGE
> > +select PFLASH_CFI01
> >  select SIFIVE
> > diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
> > index d36f5625ec..ca002ecea7 100644
> > --- a/hw/riscv/virt.c
> > +++ b/hw/riscv/virt.c
> > @@ -26,6 +26,7 @@
> >  #include "hw/boards.h"
> >  #include "hw/loader.h"
> >  #include "hw/sysbus.h"
> > +#include "hw/qdev-properties.h"
> >  #include "hw/char/serial.h"
> >  #include "target/riscv/cpu.h"
> >  #include "hw/riscv/riscv_hart.h"
> > @@ -61,12 +62,72 @@ static const struct MemmapEntry {
> >  [VIRT_PLIC] ={  0xc00, 0x400 },
> >  [VIRT_UART0] =   { 0x1000, 0x100 },
> >  [VIRT_VIRTIO] =  { 0x10001000,0x1000 },
> > +[VIRT_FLASH] =   { 0x2000, 0x200 },
> >  [VIRT_DRAM] ={ 0x8000,   0x0 },
> >  [VIRT_PCIE_MMIO] =   { 0x4000,0x4000 },
> >  [VIRT_PCIE_PIO] ={ 0x0300,0x0001 },
> >  [VIRT_PCIE_ECAM] =   { 0x3000,0x1000 },
> >  };
> >
> > +#define VIRT_FLASH_SECTOR_SIZE (256 * KiB)
> > +
> > +static PFlashCFI01 *virt_flash_create1(RISCVVirtState *s,
> > +   const char *name,
> > +   const char *alias_prop_name)
> > +{
> > +/*
> > + * Create a single flash device.  We use the same parameters as
> > + * the flash devices on the ARM virt board.
> > + */
> > +DeviceState *dev = qdev_create(NULL, TYPE_PFLASH_CFI01);
> > +
> > +qdev_prop_set_uint64(dev, "sector-length", VIRT_FLASH_SECTOR_SIZE);
> > +qdev_prop_set_uint8(dev, "width", 4);
> > +qdev_prop_set_uint8(dev, "device-width", 2);
> > +qdev_prop_set_bit(dev, "big-endian", false);
> > +qdev_prop_set_uint16(dev, "id0", 0x89);
> > +qdev_prop_set_uint16(dev, "id1", 0x18);
> > +qdev_prop_set_uint16(dev, "id2", 0x00);
> > +qdev_prop_set_uint16(dev, "id3", 0x00);
> > +qdev_prop_set_string(dev, "name", name);
>
> alias_prop_name is unused? ARM virt has 2 more calls in the same function 
> here.

Yep, you are right. I have removed this.

>
> > +
> > +return PFLASH_CFI01(dev);
> > +}
> > +
> > +static void virt_flash_create(RISCVVirtState *s)
> > +{
> > +s->flash[0] = virt_flash_create1(s, "virt.flash0", "pflash0");
> > +s->flash[1] = virt_flash_create1(s, "virt.flash1", "pflash1");
>
> I don't think we should mirror what is used on ARM virt board to
> create 2 flash for sifive_u. For ARM virt, there are 2 flashes because
> they need distinguish secure and non-secure. For sifive_u, only one is
> enough.

I went back and forward about 1 or 2. Two seems more usable as maybe
someone wants to include two pflash files? The Xilinx machine also has
two so I'm kind of used to 2, but I'm not really fussed.

Unless anyone else wants two I will change it to 1.

Alistair

>
> > +}
> > +
> > +static void virt_flash_map1(PFlashCFI01 *flash,
> > +hwaddr base, hwaddr size,
> > +MemoryRegion *sysmem)
> > +{
> > +DeviceState *dev = DEVICE(flash);
> > +
> > +assert(size % VIRT_FLASH_SECTOR_SIZE == 0);
> > +assert(size / VIRT_FLASH_SECTOR_SIZE <= UINT32_MAX);
> > +qdev_prop_set_uint32(dev, "num-blocks", size / VIRT_FLASH_SECTOR_SIZE);
> > +qdev_init_nofail(dev);
> > +
> > +memory_region_add_subregion(sysmem, base,
> > +sysbus_mmio_get_region(SYS_BUS_DEVICE(dev),
> > +   0));
> > +}
> > +
> > +static void virt_flash_map(RISCVVirtState *s,
> > +   MemoryRegion *sysmem)
> > +{
> > +hwaddr flashsize = virt_memmap[VIRT_FLASH].size / 2;
> > +hwaddr flashbase = virt_memmap[VIRT_FLASH].base;
> > +
> > +virt_flash_map1(s->flash[0], flashbase, flashsize,
> > +sysmem);
> > +virt_flash_map1(s->flash[1], flashbase + flashsize, flashsize,
> > +sysmem);
> > +}
> > +
> >  static void create_pcie_irq_map(void *fdt, char *nodename,
> >  uint32_t plic_phandle)
> >  {
> > @@ -121,6 +182,8 @@ static

[PATCH v2 4/5] docker: remove unused debian-sid and debian-ports

[John Snow]

These are listed as "partial" images, but have no user.
Remove them.

Signed-off-by: John Snow 
Message-id: 20190920001413.22567-4-js...@redhat.com
---
 tests/docker/Makefile.include | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/docker/Makefile.include b/tests/docker/Makefile.include
index 0a7fc8bc79..cb41652885 100644
--- a/tests/docker/Makefile.include
+++ b/tests/docker/Makefile.include
@@ -5,8 +5,8 @@
 DOCKER_SUFFIX := .docker
 DOCKER_FILES_DIR := $(SRC_PATH)/tests/docker/dockerfiles
 # we don't run tests on intermediate images (used as base by another image)
-DOCKER_PARTIAL_IMAGES := debian8 debian9 debian10 debian-sid
-DOCKER_PARTIAL_IMAGES += debian9-mxe debian-ports debian-bootstrap
+DOCKER_PARTIAL_IMAGES := debian8 debian9 debian10
+DOCKER_PARTIAL_IMAGES += debian9-mxe debian-bootstrap
 DOCKER_IMAGES := $(sort $(notdir $(basename $(wildcard 
$(DOCKER_FILES_DIR)/*.docker
 DOCKER_TARGETS := $(patsubst %,docker-image-%,$(DOCKER_IMAGES))
 # Use a global constant ccache directory to speed up repetitive builds
-- 
2.21.0

Re: [Qemu-block] [PATCH v2] nbd/server: attach client channel to the export's AioContext

[Eric Blake]

On 9/20/19 2:11 PM, Eric Blake wrote:
> On 9/20/19 1:49 PM, John Snow wrote:
>>
> 
 To fix this, as soon we have the export corresponding to the client,
 we call qio_channel_attach_aio_context() to attach the QIOChannel
 context to the export's AioContext. This matches with the logic at
 blk_aio_attached().

> 
>>>
>>> I assume this patch has been superseded by Eric's later patches?
>>
>> Nevermind -- my filtering got messed up slightly and I missed the
>> followup. I see that Eric staged this.
> 
> I actually think both patches are needed: this one covers transactions,
> while my later patch was on top of this to protect shutdown.  But now
> you've made me curious; I'll see if my patch hoisted in front still
> solves everything, or if we really do need both.
> 

Nope, both patches are still needed.  Sergio's fixes the assertion:
(qemu) qemu-kvm: io/channel.c:411: qio_channel_restart_read:
Assertion `qemu_get_current_aio_context() ==
qemu_coroutine_get_aio_context(co)' failed.

while mine fixes:
+qemu: qemu_mutex_unlock_impl: Operation not permitted


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



signature.asc
Description: OpenPGP digital signature

[PATCH v2 3/5] docker: remove debian8-mxe definitions

[John Snow]

We don't have a debian8-mxe dockerfile anymore.

Signed-off-by: John Snow 
Message-id: 20190920001413.22567-3-js...@redhat.com
---
 tests/docker/Makefile.include | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/docker/Makefile.include b/tests/docker/Makefile.include
index 0d75260e46..0a7fc8bc79 100644
--- a/tests/docker/Makefile.include
+++ b/tests/docker/Makefile.include
@@ -6,7 +6,7 @@ DOCKER_SUFFIX := .docker
 DOCKER_FILES_DIR := $(SRC_PATH)/tests/docker/dockerfiles
 # we don't run tests on intermediate images (used as base by another image)
 DOCKER_PARTIAL_IMAGES := debian8 debian9 debian10 debian-sid
-DOCKER_PARTIAL_IMAGES += debian8-mxe debian9-mxe debian-ports debian-bootstrap
+DOCKER_PARTIAL_IMAGES += debian9-mxe debian-ports debian-bootstrap
 DOCKER_IMAGES := $(sort $(notdir $(basename $(wildcard 
$(DOCKER_FILES_DIR)/*.docker
 DOCKER_TARGETS := $(patsubst %,docker-image-%,$(DOCKER_IMAGES))
 # Use a global constant ccache directory to speed up repetitive builds
-- 
2.21.0

[PATCH v2 2/5] docker: remove 'deprecated' image definitions

[John Snow]

There isn't a debian.dockerfile anymore,
so perform some ghost-busting.

Signed-off-by: John Snow 
Message-id: 20190920001413.22567-2-js...@redhat.com
---
 tests/docker/Makefile.include | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/tests/docker/Makefile.include b/tests/docker/Makefile.include
index d796f71b63..0d75260e46 100644
--- a/tests/docker/Makefile.include
+++ b/tests/docker/Makefile.include
@@ -4,11 +4,10 @@
 
 DOCKER_SUFFIX := .docker
 DOCKER_FILES_DIR := $(SRC_PATH)/tests/docker/dockerfiles
-DOCKER_DEPRECATED_IMAGES := debian
 # we don't run tests on intermediate images (used as base by another image)
-DOCKER_PARTIAL_IMAGES := debian debian8 debian9 debian10 debian-sid
+DOCKER_PARTIAL_IMAGES := debian8 debian9 debian10 debian-sid
 DOCKER_PARTIAL_IMAGES += debian8-mxe debian9-mxe debian-ports debian-bootstrap
-DOCKER_IMAGES := $(filter-out $(DOCKER_DEPRECATED_IMAGES),$(sort $(notdir 
$(basename $(wildcard $(DOCKER_FILES_DIR)/*.docker)
+DOCKER_IMAGES := $(sort $(notdir $(basename $(wildcard 
$(DOCKER_FILES_DIR)/*.docker
 DOCKER_TARGETS := $(patsubst %,docker-image-%,$(DOCKER_IMAGES))
 # Use a global constant ccache directory to speed up repetitive builds
 DOCKER_CCACHE_DIR := $$HOME/.cache/qemu-docker-ccache
@@ -159,7 +158,7 @@ docker-image-debian-powerpc-user-cross: 
docker-binfmt-image-debian-powerpc-user
 DOCKER_USER_IMAGES += debian-powerpc-user
 
 # Expand all the pre-requistes for each docker image and test combination
-$(foreach i,$(filter-out $(DOCKER_PARTIAL_IMAGES),$(DOCKER_IMAGES) 
$(DOCKER_DEPRECATED_IMAGES)), \
+$(foreach i,$(filter-out $(DOCKER_PARTIAL_IMAGES),$(DOCKER_IMAGES)), \
$(foreach t,$(DOCKER_TESTS) $(DOCKER_TOOLS), \
$(eval .PHONY: docker-$t@$i) \
$(eval docker-$t@$i: docker-image-$i docker-run-$t@$i) \
-- 
2.21.0

[PATCH v2 0/5] docker: misc cleanups

[John Snow]

This should include anything I've sent so far (not including the RFC for
more exploratory changes) that hasn't already been included in a roundup
by Alex Bennée.

Mostly, it removes unused docker files and replaces python2 with python3
in all of the container environments.

V2:
- Rolled in python2 --> python3 conversion
- Added travis conversion to python patch
- Remove debian8 dockerfile, which is also now unused.

John Snow (5):
  docker: move tests from python2 to python3
  docker: remove 'deprecated' image definitions
  docker: remove debian8-mxe definitions
  docker: remove unused debian-sid and debian-ports
  docker: removed unused debian8 partial image

 tests/docker/Makefile.include |  8 ++---
 tests/docker/dockerfiles/centos7.docker   |  2 +-
 tests/docker/dockerfiles/debian-ports.docker  |  2 +-
 tests/docker/dockerfiles/debian-sid.docker|  2 +-
 .../dockerfiles/debian-xtensa-cross.docker|  2 +-
 tests/docker/dockerfiles/debian10.docker  |  2 +-
 tests/docker/dockerfiles/debian8.docker   | 34 ---
 tests/docker/dockerfiles/debian9.docker   |  2 +-
 tests/docker/dockerfiles/travis.docker|  2 +-
 tests/docker/dockerfiles/ubuntu.docker|  2 +-
 tests/docker/dockerfiles/ubuntu1804.docker|  2 +-
 11 files changed, 12 insertions(+), 48 deletions(-)
 delete mode 100644 tests/docker/dockerfiles/debian8.docker

-- 
2.21.0

[PATCH v2 5/5] docker: removed unused debian8 partial image

[John Snow]

debian8 partial base is also not consumed by any image, so remove it.

Signed-off-by: John Snow 
---
 tests/docker/Makefile.include   |  3 +--
 tests/docker/dockerfiles/debian8.docker | 33 -
 2 files changed, 1 insertion(+), 35 deletions(-)
 delete mode 100644 tests/docker/dockerfiles/debian8.docker

diff --git a/tests/docker/Makefile.include b/tests/docker/Makefile.include
index cb41652885..b9430822b8 100644
--- a/tests/docker/Makefile.include
+++ b/tests/docker/Makefile.include
@@ -5,8 +5,7 @@
 DOCKER_SUFFIX := .docker
 DOCKER_FILES_DIR := $(SRC_PATH)/tests/docker/dockerfiles
 # we don't run tests on intermediate images (used as base by another image)
-DOCKER_PARTIAL_IMAGES := debian8 debian9 debian10
-DOCKER_PARTIAL_IMAGES += debian9-mxe debian-bootstrap
+DOCKER_PARTIAL_IMAGES := debian9 debian9-mxe debian10 debian-bootstrap
 DOCKER_IMAGES := $(sort $(notdir $(basename $(wildcard 
$(DOCKER_FILES_DIR)/*.docker
 DOCKER_TARGETS := $(patsubst %,docker-image-%,$(DOCKER_IMAGES))
 # Use a global constant ccache directory to speed up repetitive builds
diff --git a/tests/docker/dockerfiles/debian8.docker 
b/tests/docker/dockerfiles/debian8.docker
deleted file mode 100644
index be67023826..00
--- a/tests/docker/dockerfiles/debian8.docker
+++ /dev/null
@@ -1,33 +0,0 @@
-#
-# Docker multiarch cross-compiler target
-#
-# This docker target is builds on Debian and Emdebian's cross compiler targets
-# to build distro with a selection of cross compilers for building test 
binaries.
-#
-# On its own you can't build much but the docker-foo-cross targets
-# build on top of the base debian image.
-#
-FROM debian:jessie-slim
-
-MAINTAINER Philippe Mathieu-Daudé 
-
-# Duplicate deb line as deb-src
-RUN cat /etc/apt/sources.list | sed "s/^deb\ /deb-src /" >> 
/etc/apt/sources.list
-
-# Setup some basic tools we need
-RUN apt update && \
-DEBIAN_FRONTEND=noninteractive apt-get install -yy eatmydata && \
-DEBIAN_FRONTEND=noninteractive eatmydata \
-apt-get install -y --no-install-recommends \
-bison \
-binutils-multiarch \
-build-essential \
-ca-certificates \
-clang \
-curl \
-flex \
-gettext \
-git \
-gnupg \
-pkg-config \
-python3-minimal
-- 
2.21.0

Re: [PATCH v1 4/6] riscv/sifive_u: Add the start-in-flash property

[Alistair Francis]

On Thu, Sep 19, 2019 at 10:15 PM Bin Meng  wrote:
>
> On Fri, Sep 20, 2019 at 6:32 AM Alistair Francis
>  wrote:
> >
> > Add a property that when set to true QEMU will jump from the ROM code to
> > the start of flash memory instead of DRAM which is the default
> > behaviour.
> >
> > Signed-off-by: Alistair Francis 
> > ---
> >  hw/riscv/sifive_u.c | 27 +++
> >  include/hw/riscv/sifive_u.h |  2 ++
> >  2 files changed, 29 insertions(+)
> >
> > diff --git a/hw/riscv/sifive_u.c b/hw/riscv/sifive_u.c
> > index c3949fb316..b7cd3631cd 100644
> > --- a/hw/riscv/sifive_u.c
> > +++ b/hw/riscv/sifive_u.c
> > @@ -373,6 +373,10 @@ static void riscv_sifive_u_init(MachineState *machine)
> > /* dtb: */
> >  };
> >
> > +if (s->start_in_flash) {
> > +reset_vec[6] = memmap[SIFIVE_U_FLASH0].base; /* start: .dword 
> > FLASH0_BASE */
> > +}
> > +
> >  /* copy in the reset vector in little_endian byte order */
> >  for (i = 0; i < sizeof(reset_vec) >> 2; i++) {
> >  reset_vec[i] = cpu_to_le32(reset_vec[i]);
> > @@ -544,8 +548,31 @@ static void riscv_sifive_u_soc_realize(DeviceState 
> > *dev, Error **errp)
> >  memmap[SIFIVE_U_GEM_MGMT].base, memmap[SIFIVE_U_GEM_MGMT].size);
> >  }
> >
> > +static bool virt_get_start_in_flash(Object *obj, Error **errp)
> > +{
> > +SiFiveUState *s = RISCV_U_MACHINE(obj);
> > +
> > +return s->start_in_flash;
> > +}
> > +
> > +static void virt_set_start_in_flash(Object *obj, bool value, Error **errp)
> > +{
> > +SiFiveUState *s = RISCV_U_MACHINE(obj);
> > +
> > +s->start_in_flash = value;
> > +}
> > +
> >  static void riscv_sifive_u_machine_instance_init(Object *obj)
> >  {
> > +SiFiveUState *s = RISCV_U_MACHINE(obj);
> > +
> > +s->start_in_flash = false;
> > +object_property_add_bool(obj, "start-in-flash", 
> > virt_get_start_in_flash,
> > + virt_set_start_in_flash, NULL);
> > +object_property_set_description(obj, "start-in-flash",
> > +"Set on to tell QEMU's ROM to jump to 
> > " \
> > +"flash. Otherwise QEMU will jump to 
> > DRAM",
> > +NULL);
> >
> >  }
> >
> > diff --git a/include/hw/riscv/sifive_u.h b/include/hw/riscv/sifive_u.h
> > index a921079fbe..2656b43c58 100644
> > --- a/include/hw/riscv/sifive_u.h
> > +++ b/include/hw/riscv/sifive_u.h
> > @@ -57,6 +57,8 @@ typedef struct SiFiveUState {
> >
> >  void *fdt;
> >  int fdt_size;
> > +
> > +bool start_in_flash;
> >  } SiFiveUState;
> >
> >  enum {
>
> This patch chose a different way from the one used in patch "[v1,6/6]
> riscv/virt: Jump to pflash if specified":
>
> - this patch uses reset_vec[6] while patch [6/6] defines a variable start_addr
> - this patch adds a "start-in-flash" property to the machine, while
> patch [6/6] tests against drive IF_PFLASH

Yes, we do it differently for the sifive_u board as the sifive_u board
doesn't use pflash so there is no way to know if the user has loaded
anything into the SPI memory.

>
> We should be consistent and I would prefer to use the patch [6/6] way.
> On Unleashed an SPI flash is mounted so we cannot add a PFlash to
> sifive_u machine like what was done on virt machine, so we should test
> IF_MTD instead. Thoughts?

How would we test that?

Right now I am loading the binary in SPI with the -device loader
option. The machine can't really know what is/isn't loaded there.

It's not ideal, but I don't see a nicer way.

Alistair

>
> Regards,
> Bin

Re: [PATCH v2 10/16] tests/tcg: add generic version of float_convs

[Richard Henderson]

On 9/20/19 3:15 AM, Alex Bennée wrote:
> I can't figure out what is meant to be going on with CONVERT_BITS. It
> seems to be implying there is a direct relationship between status flags
> and the exception disable bits. But that is confusing because integer
> overflow (IOV) and float overflow (OVF) are different flags bit I assume
> both suppressed by Overflow Disable (OVFD).

I had failed to notice that the kernel routine plays with INV and not IOV for
the emulation of CVTTQ, so it's the SWCR_TRAP_ENABLE_INV bit that controls
whether CVTTQ/S raises a signal.

Will fix.

> Why are we doing this magic 32 bit shuffling anyway? Is it purely to
> save 32 bits of a mostly empty lower half of the FPCR register?

Yes.  Which is not a great answer, but it was done years ago and there's little
point in changing it back now.


r~

[PATCH 2/1] tests: Use iothreads during iotest 223

[Eric Blake]

Doing so catches the bugs we just fixed with NBD not properly using
correct contexts.

Signed-off-by: Eric Blake 
---

This is https://bugzilla.redhat.com/show_bug.cgi?id=1741094,
distinct from Sergio's patch also related to aiocontext in NBD, which is
https://bugzilla.redhat.com/show_bug.cgi?id=1748253

I could not easily figure out how to tweak iotests to cover Sergio's
issue, but really want to get both fixes in a pull request soon.

 tests/qemu-iotests/223 | 6 --
 tests/qemu-iotests/223.out | 1 +
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/tests/qemu-iotests/223 b/tests/qemu-iotests/223
index cc48e78ea7dc..2ba3d8124b4f 100755
--- a/tests/qemu-iotests/223
+++ b/tests/qemu-iotests/223
@@ -2,7 +2,7 @@
 #
 # Test reading dirty bitmap over NBD
 #
-# Copyright (C) 2018 Red Hat, Inc.
+# Copyright (C) 2018-2019 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
@@ -109,7 +109,7 @@ echo
 echo "=== End dirty bitmaps, and start serving image over NBD ==="
 echo

-_launch_qemu 2> >(_filter_nbd)
+_launch_qemu -object iothread,id=io0 2> >(_filter_nbd)

 # Intentionally provoke some errors as well, to check error handling
 silent=
@@ -117,6 +117,8 @@ _send_qemu_cmd $QEMU_HANDLE 
'{"execute":"qmp_capabilities"}' "return"
 _send_qemu_cmd $QEMU_HANDLE '{"execute":"blockdev-add",
   "arguments":{"driver":"qcow2", "node-name":"n",
 "file":{"driver":"file", "filename":"'"$TEST_IMG"'"}}}' "return"
+_send_qemu_cmd $QEMU_HANDLE '{"execute":"x-blockdev-set-iothread",
+  "arguments":{"node-name":"n", "iothread":"io0"}}' "return"
 _send_qemu_cmd $QEMU_HANDLE '{"execute":"block-dirty-bitmap-disable",
   "arguments":{"node":"n", "name":"b"}}' "return"
 _send_qemu_cmd $QEMU_HANDLE '{"execute":"nbd-server-add",
diff --git a/tests/qemu-iotests/223.out b/tests/qemu-iotests/223.out
index 5d00398c11cb..23b34fcd202e 100644
--- a/tests/qemu-iotests/223.out
+++ b/tests/qemu-iotests/223.out
@@ -27,6 +27,7 @@ wrote 2097152/2097152 bytes at offset 2097152
 {"return": {}}
 {"return": {}}
 {"return": {}}
+{"return": {}}
 {"error": {"class": "GenericError", "desc": "NBD server not running"}}
 {"return": {}}
 {"error": {"class": "GenericError", "desc": "NBD server already running"}}
-- 
2.21.0

Re: [PATCH] hw/arm/boot.c: Set NSACR.{CP11,CP10} for NS kernel boots

[Richard Henderson]

On 9/20/19 10:40 AM, Peter Maydell wrote:
> If we're booting a Linux kernel directly into Non-Secure
> state on a CPU which has Secure state, then make sure we
> set the NSACR CP11 and CP10 bits, so that Non-Secure is allowed
> to access the FPU. Otherwise an AArch32 kernel will UNDEF as
> soon as it tries to use the FPU.
> 
> It used to not matter that we didn't do this until commit
> fc1120a7f5f2d4b6, where we implemented actually honouring
> these NSACR bits.
> 
> The problem only exists for CPUs where EL3 is AArch32; the
> equivalent AArch64 trap bits are in CPTR_EL3 and are "0 to
> not trap, 1 to trap", so the reset value of the register
> permits NS access, unlike NSACR.
> 
> Fixes: fc1120a7f5
> Fixes: https://bugs.launchpad.net/qemu/+bug/1844597
> Cc: qemu-sta...@nongnu.org
> Signed-off-by: Peter Maydell 
> ---

Reviewed-by: Richard Henderson 


r~

Re: [PATCH RFC] docker: automatic dependencies for dockerfiles

[no-reply]

Patchew URL: https://patchew.org/QEMU/20190920001823.23279-1-js...@redhat.com/



Hi,

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

=== TEST SCRIPT BEGIN ===
#!/bin/bash
make docker-image-centos7 V=1 NETWORK=1
time make docker-test-quick@centos7 SHOW_ENV=1 J=14 NETWORK=1
=== TEST SCRIPT END ===

libudev   no
default devices   yes

warning: Python 2 support is deprecated
warning: Python 3 will be required for building future versions of QEMU
cross containers  no

NOTE: guest cross-compilers enabled: cc


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

Re: [PATCH 3/3] docker: remove unused debian-sid and debian-ports

[John Snow]

On 9/20/19 5:19 PM, Alex Bennée wrote:
> 
> John Snow  writes:
> 
>> On 9/20/19 12:20 PM, Alex Bennée wrote:
>>>
>>> John Snow  writes:
>>>
 On 9/20/19 4:49 AM, Philippe Mathieu-Daudé wrote:
> On 9/20/19 2:14 AM, John Snow wrote:
>> These are listed as "partial" images, but have no user.
>> Remove them.
>
> Well, I have WiP users from them. I could restore this content when they
> are ready... Ports is the base of deprecated Debian archs. On the other
> side Sid is the base for edge development I use from time to time to
> test latest gcc/binutils.
> I'll try to find time to raise WiP branches to PoC.
>

 I think that's the right thing to do. Right now, the docker tests
 directory has a lot of stale entries and unusable tests. That might be
 fine for the people working on it, but it makes it hard to understand
 and use for those of us who only occasionally traipse into the directory.

 I'm removing all references to python2 -- but if there's no way for me
 to test debian-sid and debian-ports, I can't test changes I need to make
 to these "partial images", so they should be removed until they are
 consumable.

 While I am sympathetic to the idea of having a library of partial images
 to use for future tests, they're prone to rot if there's no way to
 exercise them in-tree.
>>>
>>> Don't forget some "partial" images are only used for building TCG tests
>>> - we want to keep them. But as git is forever I can drop the sid/ports
>>> stuff for now until Phillipe has something to use them again.
>>>
>>
>> Oh, where? Is that defined within the tests/docker/Makefile.include or
>> in the TCG tree where I have not gone spelunking before?
> 
> Now they are selected by tests/tcg/configure.sh but generally they
> DISTRO-ARCH-cross images.
> 

I see -- "container_image" in configure.sh chooses them and consumes
them there.

Looks like that feeds to Makefile.qemu which defines
docker-build-guest-tests.

We call docker.py (DOCKER_SCRIPT) as:
docker.py cc ... -i qemu:$(DOCKER_IMAGE) ...

okay, so this bypasses the Docker Makefile pretty directly; but it looks
like it's only using images that the Makefile there doesn't count as
"Partial" universally.

You *do* have a section that marks images as "PARTIAL" if they're the
wrong architecture -- maybe it would be a semantic improvement to list
these as simply "DISABLED" or "UNAVAILABLE" -- the implication being
that they're complete images, but will not work for the current host
architecture.

Thanks for the pointer!

--js

Re: [PATCH] docker: move tests from python2 to python3

[Eduardo Habkost]

On Fri, Sep 20, 2019 at 04:00:49PM -0400, John Snow wrote:
> As part of the push to drop python2 support, replace any explicit python2
> dependencies with python3 versions.
> 
> For centos, python2 still exists as an implicit dependency, but by adding
> python3 we will be able to build even if the configure script begins to
> require python 3.5+.
> 
> Tested with centos7, fedora, ubuntu, ubuntu1804, and debian 9 (amd64).
> Tested under a custom configure script that requires Python 3.5+.
> 
> Signed-off-by: John Snow 

Reviewed-by: Eduardo Habkost 

-- 
Eduardo

Re: [PATCH 3/3] docker: remove unused debian-sid and debian-ports

[Alex Bennée]

John Snow  writes:

> On 9/20/19 12:20 PM, Alex Bennée wrote:
>>
>> John Snow  writes:
>>
>>> On 9/20/19 4:49 AM, Philippe Mathieu-Daudé wrote:
 On 9/20/19 2:14 AM, John Snow wrote:
> These are listed as "partial" images, but have no user.
> Remove them.

 Well, I have WiP users from them. I could restore this content when they
 are ready... Ports is the base of deprecated Debian archs. On the other
 side Sid is the base for edge development I use from time to time to
 test latest gcc/binutils.
 I'll try to find time to raise WiP branches to PoC.

>>>
>>> I think that's the right thing to do. Right now, the docker tests
>>> directory has a lot of stale entries and unusable tests. That might be
>>> fine for the people working on it, but it makes it hard to understand
>>> and use for those of us who only occasionally traipse into the directory.
>>>
>>> I'm removing all references to python2 -- but if there's no way for me
>>> to test debian-sid and debian-ports, I can't test changes I need to make
>>> to these "partial images", so they should be removed until they are
>>> consumable.
>>>
>>> While I am sympathetic to the idea of having a library of partial images
>>> to use for future tests, they're prone to rot if there's no way to
>>> exercise them in-tree.
>>
>> Don't forget some "partial" images are only used for building TCG tests
>> - we want to keep them. But as git is forever I can drop the sid/ports
>> stuff for now until Phillipe has something to use them again.
>>
>
> Oh, where? Is that defined within the tests/docker/Makefile.include or
> in the TCG tree where I have not gone spelunking before?

Now they are selected by tests/tcg/configure.sh but generally they
DISTRO-ARCH-cross images.

>
> --js


--
Alex Bennée

Re: [Qemu-devel] [PATCH v2 00/11] RFC crypto/luks: encryption key managment using amend interface

[John Snow]

On 9/12/19 6:30 PM, Maxim Levitsky wrote:
> This patch series is continuation of my work to add encryption
> key managment to luks/qcow2 with luks.
> 
> This is second version of this patch set.
> The changes are mostly addressing the review feedback,
> plus I tested (and fixed sadly) the somewhat ugly code
> that allows to still write share a raw luks device,
> while preveting the key managment from happening in this case,
> as it is unsafe.
> I added a new iotest dedicated to that as well.
> 
> Best regards,
>   Maxim Levitsky
> 

What branch is this based on?
It doesn't seem to apply to origin/master.

--js

Re: [Qemu-block] [PATCH] xen-block: treat XenbusStateUnknown the same as XenbusStateClosed

[John Snow]

On 9/18/19 7:57 AM, Paul Durrant wrote:
> When a frontend gracefully disconnects from an offline backend, it will
> set its own state to XenbusStateClosed. The code in xen-block.c correctly
> deals with this and sets the backend into XenbusStateClosed. Unfortunately
> it is possible for toolstack to actually delete the frontend area
> before the state key has been read, leading to an apparent frontend state
> of XenbusStateUnknown. This prevents the backend state from transitioning
> to XenbusStateClosed and hence leaves it limbo.
> 

Does the 0 come from a read into de-allocated memory?

--js

> This patch simply treats a frontend state of XenbusStateUnknown the same
> as XenbusStateClosed, which will unblock the backend in these circumstances.
> 
> Reported-by: Mark Syms 
> Signed-off-by: Paul Durrant 
> ---
> Cc: Stefano Stabellini 
> Cc: Anthony Perard 
> Cc: Kevin Wolf 
> Cc: Max Reitz 
> ---
>  hw/block/xen-block.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/hw/block/xen-block.c b/hw/block/xen-block.c
> index f77343db60..879fc310a4 100644
> --- a/hw/block/xen-block.c
> +++ b/hw/block/xen-block.c
> @@ -313,6 +313,7 @@ static void xen_block_frontend_changed(XenDevice *xendev,
>  break;
>  
>  case XenbusStateClosed:
> +case XenbusStateUnknown:
>  xen_block_disconnect(xendev, &local_err);
>  if (local_err) {
>  error_propagate(errp, local_err);
> 

Re: [PATCH] Acceptance tests: use avocado.utils.ssh for SSH interaction

[Cleber Rosa]

On Fri, Sep 20, 2019 at 05:33:35PM -0300, Eduardo Habkost wrote:
> On Thu, Sep 19, 2019 at 06:59:05PM -0400, Cleber Rosa wrote:
> > This replaces paramiko with avocado.utils.ssh module, which is based
> > on a (open)ssh binary, supposedly more ubiquitous.
> > 
> > Signed-off-by: Cleber Rosa 
> 
> Reviewed-by: Eduardo Habkost 
> 
> -- 
> Eduardo
> 

With this being reviewed, we can carry out the substitution of
https://lore.kernel.org/qemu-devel/20190830184033.7630-1-phi...@redhat.com/
for this one IMO.

And, as you've suggested, I'll be picking up your pending patches
(but that one) and queueing them on my python-next branch.

Thanks a lot!

- Cleber.

Re: [PATCH] Acceptance tests: use avocado.utils.ssh for SSH interaction

[Eduardo Habkost]

On Thu, Sep 19, 2019 at 06:59:05PM -0400, Cleber Rosa wrote:
> This replaces paramiko with avocado.utils.ssh module, which is based
> on a (open)ssh binary, supposedly more ubiquitous.
> 
> Signed-off-by: Cleber Rosa 

Reviewed-by: Eduardo Habkost 

-- 
Eduardo

Re: [PATCH] Acceptance tests: use avocado.utils.ssh for SSH interaction

[Cleber Rosa]

On Fri, Sep 20, 2019 at 04:16:54PM -0300, Eduardo Habkost wrote:
> On Thu, Sep 19, 2019 at 06:59:05PM -0400, Cleber Rosa wrote:
> > This replaces paramiko with avocado.utils.ssh module, which is based
> > on a (open)ssh binary, supposedly more ubiquitous.
> > 
> > Signed-off-by: Cleber Rosa 
> 
> I just noticed that I have some patches on python-next that never
> went to a pull request (sorry for the oversight!).
> 
> I assume I should remove
> https://lore.kernel.org/qemu-devel/20190830184033.7630-1-phi...@redhat.com/
> from the queue?
>

Yep, I believe so (assuming this one gets reviewed before the next
pull request).

- Cleber.

> > ---
> >  tests/acceptance/linux_ssh_mips_malta.py | 74 
> >  tests/requirements.txt   |  3 +-
> >  2 files changed, 25 insertions(+), 52 deletions(-)
> > 
> > diff --git a/tests/acceptance/linux_ssh_mips_malta.py 
> > b/tests/acceptance/linux_ssh_mips_malta.py
> > index 134f10cac3..30c65568ce 100644
> > --- a/tests/acceptance/linux_ssh_mips_malta.py
> > +++ b/tests/acceptance/linux_ssh_mips_malta.py
> > @@ -9,13 +9,14 @@ import os
> >  import re
> >  import base64
> >  import logging
> > -import paramiko
> >  import time
> >  
> >  from avocado import skipIf
> > +from avocado import skipUnless
> >  from avocado_qemu import Test
> >  from avocado.utils import process
> >  from avocado.utils import archive
> > +from avocado.utils import ssh
> >  
> >  
> >  class LinuxSSH(Test):
> > @@ -26,35 +27,18 @@ class LinuxSSH(Test):
> >  VM_IP = '127.0.0.1'
> >  
> >  IMAGE_INFO = {
> > -'be': {
> > -'image_url': 'https://people.debian.org/~aurel32/qemu/mips/'
> > - 'debian_wheezy_mips_standard.qcow2',
> > -'image_hash': '8987a63270df67345b2135a6b7a4885a35e392d5',
> > -'rsa_hostkey': 
> > b'B3NzaC1yc2EDAQABAAABAQCca1VitiyLAdQOld'
> > -   
> > b'zT43IOEVJZ0wHD78GJi8wDAjMiYWUzNSSn0rXGQsINHuH5'
> > -   
> > b'IlF+kBZsHinb/FtKCAyS9a8uCHhQI4SuB4QhAb0+39MlUw'
> > -   
> > b'Mm0CLkctgM2eUUZ6MQMQvDlqnue6CCkxN62EZYbaxmby7j'
> > -   
> > b'CQa1125o1HRKBvdGm2zrJWxXAfA+f1v6jHLyE8Jnu83eQ+'
> > -   
> > b'BFY25G+Vzx1PVc3zQBwJ8r0NGTRqy2//oWQP0h+bMsgeFe'
> > -   
> > b'KH/J3RJM22vg6+I4JAdBFcxnK+l781h1FuRxOn4O/Xslbg'
> > -   
> > b'go6WtB4V4TOsw2E/KfxI5IZ/icxF+swVcnvF46Hf3uQc/0'
> > -   b'BBqb',
> > -},
> > -'le': {
> > -'image_url': 'https://people.debian.org/~aurel32/qemu/mipsel/'
> > - 'debian_wheezy_mipsel_standard.qcow2',
> > -'image_hash': '7866764d9de3ef536ffca24c9fb9f04ffdb45802',
> > -'rsa_hostkey': 
> > b'B3NzaC1yc2EDAQABAAABAQClXJlBT71HL5yKvv'
> > -   
> > b'gfC7jmxSWx5zSBCzET6CLZczwAafSIs7YKfNOy/dQTxhuk'
> > -   
> > b'yIGFUugZFoF3E9PzdhunuyvyTd56MPoNIqFbb5rGokwU5I'
> > -   
> > b'TOx3dBHZR0mClypL6MVrwe0bsiIb8GhF1zioNwcsaAZnAi'
> > -   
> > b'KfXStVDtXvn/kLLq+xLABYt48CC5KYWoFaCoICskLAY+qo'
> > -   
> > b'L+LWyAnQisj4jAH8VSaSKIImFpfkHWEXPhHcC4ZBlDKtnH'
> > -   
> > b'po9vhfCHgnfW3Pzrqmk8BI4HysqPFVmJWkJGlGUL+sGeg3'
> > -   
> > b'ZZolAYuDXGuBrw8ooPJq2v2dOH+z6dyD2q/ypmAbyPqj5C'
> > -   b'rc8H',
> > -},
> > -}
> > +'be': {'image_url': 
> > ('https://people.debian.org/~aurel32/qemu/mips/'
> > + 'debian_wheezy_mips_standard.qcow2'),
> > +   'image_hash': '8987a63270df67345b2135a6b7a4885a35e392d5'},
> > +'le': {'image_url': 
> > ('https://people.debian.org/~aurel32/qemu/mipsel/'
> > + 'debian_wheezy_mipsel_standard.qcow2'),
> > +   'image_hash': '7866764d9de3ef536ffca24c9fb9f04ffdb45802'}
> > +}
> > +
> > +
> > +@skipUnless(ssh.SSH_CLIENT_BINARY, 'No SSH client available')
> > +def setUp(self):
> > +super(LinuxSSH, self).setUp()
> >  
> >  def wait_for_console_pattern(self, success_message,
> >   failure_message='Oops'):
> > @@ -78,23 +62,14 @@ class LinuxSSH(Test):
> >  self.log.debug("sshd listening on port:" + port)
> >  return port
> >  
> > -def ssh_connect(self, username, password, rsa_hostkey_b64=None):
> > +def ssh_connect(self, username, password):
> >  self.ssh_logger = logging.getLogger('ssh')
> > -self.ssh_username = username
> > -self.ssh_ps1 = '# ' if username is 'root' else '$ '
> > -self.ssh_client = paramiko.SSHClient()
> >  port = self.get_portfwd()
> > -if rsa_hostkey_b64:
> > -rsa_hostkey_bin = base64.b64decode(rsa_hostkey_b64)
> > -rsa_h

[PATCH] docker: move tests from python2 to python3

[John Snow]

As part of the push to drop python2 support, replace any explicit python2
dependencies with python3 versions.

For centos, python2 still exists as an implicit dependency, but by adding
python3 we will be able to build even if the configure script begins to
require python 3.5+.

Tested with centos7, fedora, ubuntu, ubuntu1804, and debian 9 (amd64).
Tested under a custom configure script that requires Python 3.5+.

Signed-off-by: John Snow 
---
 tests/docker/dockerfiles/centos7.docker | 2 +-
 tests/docker/dockerfiles/debian-ports.docker| 2 +-
 tests/docker/dockerfiles/debian-sid.docker  | 2 +-
 tests/docker/dockerfiles/debian-xtensa-cross.docker | 2 +-
 tests/docker/dockerfiles/debian10.docker| 2 +-
 tests/docker/dockerfiles/debian8.docker | 3 +--
 tests/docker/dockerfiles/debian9.docker | 2 +-
 tests/docker/dockerfiles/ubuntu.docker  | 2 +-
 tests/docker/dockerfiles/ubuntu1804.docker  | 2 +-
 9 files changed, 9 insertions(+), 10 deletions(-)

diff --git a/tests/docker/dockerfiles/centos7.docker 
b/tests/docker/dockerfiles/centos7.docker
index e0b9d7dbe9..953637065c 100644
--- a/tests/docker/dockerfiles/centos7.docker
+++ b/tests/docker/dockerfiles/centos7.docker
@@ -25,6 +25,7 @@ ENV PACKAGES \
 nettle-devel \
 perl-Test-Harness \
 pixman-devel \
+python3 \
 SDL-devel \
 spice-glib-devel \
 spice-server-devel \
@@ -34,4 +35,3 @@ ENV PACKAGES \
 zlib-devel
 RUN yum install -y $PACKAGES
 RUN rpm -q $PACKAGES | sort > /packages.txt
-
diff --git a/tests/docker/dockerfiles/debian-ports.docker 
b/tests/docker/dockerfiles/debian-ports.docker
index 61bc3f2993..f1ea8d3bd1 100644
--- a/tests/docker/dockerfiles/debian-ports.docker
+++ b/tests/docker/dockerfiles/debian-ports.docker
@@ -31,6 +31,6 @@ RUN apt-get update && \
 git \
 pkg-config \
 psmisc \
-python \
+python3 \
 texinfo \
 $(apt-get -s build-dep qemu | egrep ^Inst | fgrep '[all]' | cut -d\  
-f2)
diff --git a/tests/docker/dockerfiles/debian-sid.docker 
b/tests/docker/dockerfiles/debian-sid.docker
index 2a1bcc33b2..dcb8e83715 100644
--- a/tests/docker/dockerfiles/debian-sid.docker
+++ b/tests/docker/dockerfiles/debian-sid.docker
@@ -31,5 +31,5 @@ RUN apt update && \
 git \
 pkg-config \
 psmisc \
-python \
+python3 \
 texinfo || { echo "Failed to build - see debian-sid.docker notes"; 
exit 1; }
diff --git a/tests/docker/dockerfiles/debian-xtensa-cross.docker 
b/tests/docker/dockerfiles/debian-xtensa-cross.docker
index b9c2e2e531..e6f93f65ee 100644
--- a/tests/docker/dockerfiles/debian-xtensa-cross.docker
+++ b/tests/docker/dockerfiles/debian-xtensa-cross.docker
@@ -18,7 +18,7 @@ RUN apt-get update && \
 flex \
 gettext \
 git \
-python-minimal
+python3-minimal
 
 ENV CPU_LIST csp dc232b dc233c
 ENV TOOLCHAIN_RELEASE 2018.02
diff --git a/tests/docker/dockerfiles/debian10.docker 
b/tests/docker/dockerfiles/debian10.docker
index 30a78813f2..dad498b52e 100644
--- a/tests/docker/dockerfiles/debian10.docker
+++ b/tests/docker/dockerfiles/debian10.docker
@@ -26,7 +26,7 @@ RUN apt update && \
 git \
 pkg-config \
 psmisc \
-python \
+python3 \
 python3-sphinx \
 texinfo \
 $(apt-get -s build-dep qemu | egrep ^Inst | fgrep '[all]' | cut -d\  
-f2)
diff --git a/tests/docker/dockerfiles/debian8.docker 
b/tests/docker/dockerfiles/debian8.docker
index 1212a85c35..be67023826 100644
--- a/tests/docker/dockerfiles/debian8.docker
+++ b/tests/docker/dockerfiles/debian8.docker
@@ -30,5 +30,4 @@ RUN apt update && \
 git \
 gnupg \
 pkg-config \
-python-minimal
-
+python3-minimal
diff --git a/tests/docker/dockerfiles/debian9.docker 
b/tests/docker/dockerfiles/debian9.docker
index b36f1d4ed8..8cbd742bb5 100644
--- a/tests/docker/dockerfiles/debian9.docker
+++ b/tests/docker/dockerfiles/debian9.docker
@@ -26,7 +26,7 @@ RUN apt update && \
 git \
 pkg-config \
 psmisc \
-python \
+python3 \
 python3-sphinx \
 texinfo \
 $(apt-get -s build-dep qemu | egrep ^Inst | fgrep '[all]' | cut -d\  
-f2)
diff --git a/tests/docker/dockerfiles/ubuntu.docker 
b/tests/docker/dockerfiles/ubuntu.docker
index a4f601395c..f486492224 100644
--- a/tests/docker/dockerfiles/ubuntu.docker
+++ b/tests/docker/dockerfiles/ubuntu.docker
@@ -60,7 +60,7 @@ ENV PACKAGES flex bison \
 libvte-2.91-dev \
 libxen-dev \
 make \
-python-yaml \
+python3-yaml \
 python3-sphinx \
 sparse \
 texinfo \
diff --git a/tests/docker/dockerfiles/ubuntu1804.docker 
b/tests/docker/dockerfiles/ubuntu1804.docker
index 883f9bcf31..3cc4f492c4 100644
--- a/tests/docker/dockerfiles/ubuntu1804.docker
+++ b/tests/docker/dockerfiles/ubuntu1804.docker
@@ -47,7 +47,7 @@ ENV PACKAGES flex b

[Bug 1811533] Re: Unstable Win10 guest with qemu 3.1 + huge pages + hv_stimer

[Damir]

Also attaching my libvirt log with a few errors at the end of the log.

Thank you for looking into this!


** Attachment added: "Libvirt_log_command_line"
   
https://bugs.launchpad.net/qemu/+bug/1811533/+attachment/5290071/+files/libvirt_log.txt

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

Title:
  Unstable Win10 guest with qemu 3.1 + huge pages + hv_stimer

Status in QEMU:
  Confirmed

Bug description:
  Host:
  Gentoo linux x86_64, kernel 4.20.1
  Qemu 3.1.0 
  CPU: Intel i7 6850K
  Chipset: X99

  Guest:
  Windows 10 Pro 64bit (1809)
  Machine type: pc-q35_3.1
  Hyper-V enlightenments: 
hv_stimer,hv_reenlightenment,hv_frequencies,hv_vapic,hv_reset,hv_synic,hv_runtime,hv_vpindex,hv_time,hv_relaxed,hv_spinlocks=0x1fff
  Memory: 16GB backed by 2MB huge pages

  Issue:
  Once guest is started, log gets flooded with:

  qemu-system-x86_64: vhost_region_add_section: Overlapping but not
  coherent sections at 103000

  or

  qemu-system-x86_64: vhost_region_add_section:Section rounded to 0
  prior to previous 1f000

  (line endings change)

  and as time goes guest loses network access (virtio-net-pci) and
  general performance diminishes to extent of freezing applications.

  Observations:
  1) problem disappears when hv_stimer is removed
  2) problem disappears when memory backing with huge pages is disabled
  3) problem disappears when machine type is downgraded to pc-q35_3.0

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

Re: [Qemu-devel] [PATCH 2/2] roms/Makefile.edk2: don't pull in submodules when building from tarball

[Philippe Mathieu-Daudé]

On 9/13/19 1:12 AM, Michael Roth wrote:
> Currently the `make efi` target pulls submodules nested under the
> roms/edk2 submodule as dependencies. However, when we attempt to build
> from a tarball this fails since we are no longer in a git tree.
> 
> A preceding patch will pre-populate these submodules in the tarball,
> so assume this build dependency is only needed when building from a
> git tree.
> 
> Reported-by: Bruce Rogers 
> Cc: Laszlo Ersek 
> Cc: Bruce Rogers 
> Cc: qemu-sta...@nongnu.org # v4.1.0
> Signed-off-by: Michael Roth 
> ---
>  roms/Makefile.edk2 | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/roms/Makefile.edk2 b/roms/Makefile.edk2
> index c2f2ff59d5..33a074d3a4 100644
> --- a/roms/Makefile.edk2
> +++ b/roms/Makefile.edk2
> @@ -46,8 +46,13 @@ all: $(foreach 
> flashdev,$(flashdevs),../pc-bios/edk2-$(flashdev).fd.bz2) \
>  # files.
>  .INTERMEDIATE: $(foreach 
> flashdev,$(flashdevs),../pc-bios/edk2-$(flashdev).fd)
>  
> +# Fetch edk2 submodule's submodules. If it is not in a git tree, assume
> +# we're building from a tarball and that they've already been fetched by
> +# make-release/tarball scripts.

Annoying, without using the make-release tool in a fresh clone, I get
qemu/roms/edk2/CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf(-1):
error 000E: File/directory not found in workspace

I vaguely remember there was a thread about not using 'git submodule
update --init --recursive' in the root directory but can't find it, any
idea?

>  submodules:
> - cd edk2 && git submodule update --init --force
> + if test -d edk2/.git; then \
> + cd edk2 && git submodule update --init --force; \
> + fi
>  
>  # See notes on the ".NOTPARALLEL" target and the "+" indicator in
>  # "tests/uefi-test-tools/Makefile".
> 

Re: [RFC 4/4] ahci media error reporting

[John Snow]

On 9/20/19 3:25 PM, Tony Asleson wrote:
> On 9/20/19 11:18 AM, John Snow wrote:
>> For sure -- I handle the normative cases, but I don't test what happens
>> if you issue an unsupported NCQ command. (I don't know what real
>> hardware does right now, either. I'm sure I could read the spec and find
>> out, but don't have a testing setup that lets me analyze real hardware
>> anymore.)
> 
> Regardless of what actual hardware does, it's always good to see what
> the spec says as hardware folks get it wrong too sometimes :-)
> 
> -Tony
> 

That depends. If we're emulating an "AHCI device", we should follow the
spec, but the one we instantiate in QEMU is the ICH9 version, so we try
to follow the hardware.

I do wind up looking at both, but because the relevant specs are split
across SATA, AHCI, ATA, ATAPI and into SCSI sometimes, (plus sub-specs)
it can be hard to piece together a holistic picture of what should
happen sometimes.

Looking at hardware is sometimes quicker and more definitive :)

Anyway, none of this helps you out much, but I will at least stay tuned
to review AHCI code and can try to help you make better incisions.

Enjoy your weekend!

--js

Re: [PATCH v2 06/16] target/ppc: fix signal delivery for ppc64abi32

[Laurent Vivier]

Le 19/09/2019 à 19:10, Alex Bennée a écrit :

We were incorrectly using the 64-bit AIX ABI instead of the 32-bit
SYSV ABI for setting NIP for the signal handler.

Signed-off-by: Alex Bennée 
Reviewed-by: Richard Henderson 

---
v2
   - change to wording
---
  linux-user/ppc/signal.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/linux-user/ppc/signal.c b/linux-user/ppc/signal.c
index 619a56950df..5b82af6cb62 100644
--- a/linux-user/ppc/signal.c
+++ b/linux-user/ppc/signal.c
@@ -501,7 +501,9 @@ void setup_rt_frame(int sig, struct target_sigaction *ka,
  int i, err = 0;
  #if defined(TARGET_PPC64)
  struct target_sigcontext *sc = 0;
+#if !defined(TARGET_ABI32)
  struct image_info *image = ((TaskState *)thread_cpu->opaque)->info;
+#endif
  #endif
  
  rt_sf_addr = get_sigframe(ka, env, sizeof(*rt_sf));

@@ -557,7 +559,7 @@ void setup_rt_frame(int sig, struct target_sigaction *ka,
  env->gpr[5] = (target_ulong) h2g(&rt_sf->uc);
  env->gpr[6] = (target_ulong) h2g(rt_sf);
  
-#if defined(TARGET_PPC64)

+#if defined(TARGET_PPC64) && !defined(TARGET_ABI32)
  if (get_ppc64_abi(image) < 2) {
  /* ELFv1 PPC64 function pointers are pointers to OPD entries. */
  struct target_func_ptr *handler =



Reviewed-by: Laurent Vivier 

Re: [RFC 4/4] ahci media error reporting

[Tony Asleson]

On 9/20/19 11:18 AM, John Snow wrote:
> For sure -- I handle the normative cases, but I don't test what happens
> if you issue an unsupported NCQ command. (I don't know what real
> hardware does right now, either. I'm sure I could read the spec and find
> out, but don't have a testing setup that lets me analyze real hardware
> anymore.)

Regardless of what actual hardware does, it's always good to see what
the spec says as hardware folks get it wrong too sometimes :-)

-Tony

Re: [PATCH] Acceptance tests: use avocado.utils.ssh for SSH interaction

[Eduardo Habkost]

On Thu, Sep 19, 2019 at 06:59:05PM -0400, Cleber Rosa wrote:
> This replaces paramiko with avocado.utils.ssh module, which is based
> on a (open)ssh binary, supposedly more ubiquitous.
> 
> Signed-off-by: Cleber Rosa 

I just noticed that I have some patches on python-next that never
went to a pull request (sorry for the oversight!).

I assume I should remove
https://lore.kernel.org/qemu-devel/20190830184033.7630-1-phi...@redhat.com/
from the queue?

> ---
>  tests/acceptance/linux_ssh_mips_malta.py | 74 
>  tests/requirements.txt   |  3 +-
>  2 files changed, 25 insertions(+), 52 deletions(-)
> 
> diff --git a/tests/acceptance/linux_ssh_mips_malta.py 
> b/tests/acceptance/linux_ssh_mips_malta.py
> index 134f10cac3..30c65568ce 100644
> --- a/tests/acceptance/linux_ssh_mips_malta.py
> +++ b/tests/acceptance/linux_ssh_mips_malta.py
> @@ -9,13 +9,14 @@ import os
>  import re
>  import base64
>  import logging
> -import paramiko
>  import time
>  
>  from avocado import skipIf
> +from avocado import skipUnless
>  from avocado_qemu import Test
>  from avocado.utils import process
>  from avocado.utils import archive
> +from avocado.utils import ssh
>  
>  
>  class LinuxSSH(Test):
> @@ -26,35 +27,18 @@ class LinuxSSH(Test):
>  VM_IP = '127.0.0.1'
>  
>  IMAGE_INFO = {
> -'be': {
> -'image_url': 'https://people.debian.org/~aurel32/qemu/mips/'
> - 'debian_wheezy_mips_standard.qcow2',
> -'image_hash': '8987a63270df67345b2135a6b7a4885a35e392d5',
> -'rsa_hostkey': b'B3NzaC1yc2EDAQABAAABAQCca1VitiyLAdQOld'
> -   b'zT43IOEVJZ0wHD78GJi8wDAjMiYWUzNSSn0rXGQsINHuH5'
> -   b'IlF+kBZsHinb/FtKCAyS9a8uCHhQI4SuB4QhAb0+39MlUw'
> -   b'Mm0CLkctgM2eUUZ6MQMQvDlqnue6CCkxN62EZYbaxmby7j'
> -   b'CQa1125o1HRKBvdGm2zrJWxXAfA+f1v6jHLyE8Jnu83eQ+'
> -   b'BFY25G+Vzx1PVc3zQBwJ8r0NGTRqy2//oWQP0h+bMsgeFe'
> -   b'KH/J3RJM22vg6+I4JAdBFcxnK+l781h1FuRxOn4O/Xslbg'
> -   b'go6WtB4V4TOsw2E/KfxI5IZ/icxF+swVcnvF46Hf3uQc/0'
> -   b'BBqb',
> -},
> -'le': {
> -'image_url': 'https://people.debian.org/~aurel32/qemu/mipsel/'
> - 'debian_wheezy_mipsel_standard.qcow2',
> -'image_hash': '7866764d9de3ef536ffca24c9fb9f04ffdb45802',
> -'rsa_hostkey': b'B3NzaC1yc2EDAQABAAABAQClXJlBT71HL5yKvv'
> -   b'gfC7jmxSWx5zSBCzET6CLZczwAafSIs7YKfNOy/dQTxhuk'
> -   b'yIGFUugZFoF3E9PzdhunuyvyTd56MPoNIqFbb5rGokwU5I'
> -   b'TOx3dBHZR0mClypL6MVrwe0bsiIb8GhF1zioNwcsaAZnAi'
> -   b'KfXStVDtXvn/kLLq+xLABYt48CC5KYWoFaCoICskLAY+qo'
> -   b'L+LWyAnQisj4jAH8VSaSKIImFpfkHWEXPhHcC4ZBlDKtnH'
> -   b'po9vhfCHgnfW3Pzrqmk8BI4HysqPFVmJWkJGlGUL+sGeg3'
> -   b'ZZolAYuDXGuBrw8ooPJq2v2dOH+z6dyD2q/ypmAbyPqj5C'
> -   b'rc8H',
> -},
> -}
> +'be': {'image_url': ('https://people.debian.org/~aurel32/qemu/mips/'
> + 'debian_wheezy_mips_standard.qcow2'),
> +   'image_hash': '8987a63270df67345b2135a6b7a4885a35e392d5'},
> +'le': {'image_url': 
> ('https://people.debian.org/~aurel32/qemu/mipsel/'
> + 'debian_wheezy_mipsel_standard.qcow2'),
> +   'image_hash': '7866764d9de3ef536ffca24c9fb9f04ffdb45802'}
> +}
> +
> +
> +@skipUnless(ssh.SSH_CLIENT_BINARY, 'No SSH client available')
> +def setUp(self):
> +super(LinuxSSH, self).setUp()
>  
>  def wait_for_console_pattern(self, success_message,
>   failure_message='Oops'):
> @@ -78,23 +62,14 @@ class LinuxSSH(Test):
>  self.log.debug("sshd listening on port:" + port)
>  return port
>  
> -def ssh_connect(self, username, password, rsa_hostkey_b64=None):
> +def ssh_connect(self, username, password):
>  self.ssh_logger = logging.getLogger('ssh')
> -self.ssh_username = username
> -self.ssh_ps1 = '# ' if username is 'root' else '$ '
> -self.ssh_client = paramiko.SSHClient()
>  port = self.get_portfwd()
> -if rsa_hostkey_b64:
> -rsa_hostkey_bin = base64.b64decode(rsa_hostkey_b64)
> -rsa_hostkey = paramiko.RSAKey(data = rsa_hostkey_bin)
> -ipport = '[%s]:%s' % (self.VM_IP, port)
> -self.ssh_logger.debug('ipport ' + ipport)
> -self.ssh_client.get_host_keys().add(ipport, 'ssh-rsa', 
> rsa_hostkey)
> +self.ssh_session = ssh.Session(self.VM_IP, port=int(port),
> +   user=username, password=password)
>  for i in range(10):
>  try:
> - 

[PULL] Request pull for IPMI changes

[Corey Minyard]

The following changes since commit a77d20bafcd4cb7684168a9b4c6dc2a321aaeb50:

  Merge remote-tracking branch 'remotes/kraxel/tags/ui-20190919-pull-request' 
into staging (2019-09-19 17:16:07 +0100)

are available in the Git repository at:

  https://github.com/cminyard/qemu.git tags/ipmi-for-release-2019-09-20

for you to fetch changes up to ebe15582cafeb944a1c6e99aa526e81a1551c567:

  pc: Add an SMB0 ACPI device to q35 (2019-09-20 14:09:24 -0500)


ipmi: Some bug fixes and new interfaces

Some bug fixes for the watchdog and hopefully the BT tests.

Change the IPMI UUID handling to give the user the ability to set it or
not have it.

Add a PCI interface.

Add an SMBus interfaces.

-corey


Corey Minyard (15):
  ipmi: Fix watchdog NMI handling
  ipmi: Fix the get watchdog command
  ipmi: Generate an interrupt on watchdog pretimeout expiry
  tests:ipmi: Fix IPMI BT tests
  qdev: Add a no default uuid property
  ipmi: Add a UUID device property
  ipmi: Split out KCS-specific code from ISA KCS code
  ipmi: Split out BT-specific code from ISA BT code
  ipmi: Allow a size value to be passed for I/O space
  smbios:ipmi: Ignore IPMI devices with no fwinfo function
  ipmi: Add PCI IPMI interfaces
  ipmi: Add an SMBus IPMI interface
  acpi: Add i2c serial bus CRS handling
  ipmi: Fix SSIF ACPI handling to use the right CRS
  pc: Add an SMB0 ACPI device to q35

 default-configs/i386-softmmu.mak |   3 +
 hw/acpi/aml-build.c  |  40 
 hw/acpi/ipmi-stub.c  |   2 +-
 hw/acpi/ipmi.c   |  13 +-
 hw/i386/Kconfig  |   3 +
 hw/i386/acpi-build.c |  17 +-
 hw/i386/pc_piix.c|  12 +-
 hw/i386/pc_q35.c |   9 +-
 hw/ipmi/Kconfig  |  15 ++
 hw/ipmi/Makefile.objs|   5 +-
 hw/ipmi/ipmi.c   |   6 +-
 hw/ipmi/ipmi_bmc_sim.c   |  30 ++-
 hw/ipmi/ipmi_bt.c| 437 ++
 hw/ipmi/ipmi_kcs.c   | 423 +
 hw/ipmi/isa_ipmi_bt.c| 443 ++-
 hw/ipmi/isa_ipmi_kcs.c   | 419 ++--
 hw/ipmi/pci_ipmi_bt.c| 146 +
 hw/ipmi/pci_ipmi_kcs.c   | 146 +
 hw/ipmi/smbus_ipmi.c | 384 +
 hw/smbios/smbios_type_38.c   |   3 +
 include/hw/acpi/aml-build.h  |  18 ++
 include/hw/acpi/ipmi.h   |   2 +-
 include/hw/i386/pc.h |   2 +
 include/hw/ipmi/ipmi.h   |   7 +-
 include/hw/ipmi/ipmi_bt.h|  73 +++
 include/hw/ipmi/ipmi_kcs.h   |  76 +++
 include/hw/pci/pci.h |   1 +
 include/hw/qdev-properties.h |   7 +
 qemu-options.hx  |  10 +-
 tests/Makefile.include   |   3 +-
 tests/data/acpi/q35/DSDT | Bin 7841 -> 7879 bytes
 tests/data/acpi/q35/DSDT.bridge  | Bin 7858 -> 7896 bytes
 tests/data/acpi/q35/DSDT.cphp| Bin 8304 -> 8342 bytes
 tests/data/acpi/q35/DSDT.dimmpxm | Bin 9494 -> 9532 bytes
 tests/data/acpi/q35/DSDT.ipmibt  | Bin 7916 -> 7954 bytes
 tests/data/acpi/q35/DSDT.memhp   | Bin 9200 -> 9238 bytes
 tests/data/acpi/q35/DSDT.mmio64  | Bin 8971 -> 9009 bytes
 tests/data/acpi/q35/DSDT.numamem | Bin 7847 -> 7885 bytes
 tests/ipmi-bt-test.c |   6 +-
 39 files changed, 1902 insertions(+), 859 deletions(-)
 create mode 100644 hw/ipmi/ipmi_bt.c
 create mode 100644 hw/ipmi/ipmi_kcs.c
 create mode 100644 hw/ipmi/pci_ipmi_bt.c
 create mode 100644 hw/ipmi/pci_ipmi_kcs.c
 create mode 100644 hw/ipmi/smbus_ipmi.c
 create mode 100644 include/hw/ipmi/ipmi_bt.h
 create mode 100644 include/hw/ipmi/ipmi_kcs.h

Re: [RFC 0/4] POC: Generating realistic block errors

[Tony Asleson]

On 9/20/19 12:08 PM, Eric Blake wrote:
> I am worried, however, that making data transactions have to go through
> QMP to get an answer on how to handle a specific guest request will slow
> things down; QMP is not built to be an efficient dataplane interface.

IMHO we only need to make the code path efficient up to the point we
know we have an IO operation that contains sector(s) that we want to do
something with.  Once that happens I don't think it will be an issue for
those to be slower.  A real spinning disk drive takes longer to handle a
request when it encounters an error too.

> If you truly want isolation (where another process receives all guest
> transactions, and makes decisions on how to handle them)

It would only handle specific sector(s) of interest, not all.

-Tony

[Bug 1811533] Re: Unstable Win10 guest with qemu 3.1 + huge pages + hv_stimer

[Žilvinas Žaltiena]

As asked by dgilbert-h, I am attaching my qemu command line. It is
ripped from libvirt log.

** Attachment added: "Bug reproducing Qemu command line from libvirt log."
   
https://bugs.launchpad.net/qemu/+bug/1811533/+attachment/5290067/+files/qemu_cmdln.txt

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

Title:
  Unstable Win10 guest with qemu 3.1 + huge pages + hv_stimer

Status in QEMU:
  Confirmed

Bug description:
  Host:
  Gentoo linux x86_64, kernel 4.20.1
  Qemu 3.1.0 
  CPU: Intel i7 6850K
  Chipset: X99

  Guest:
  Windows 10 Pro 64bit (1809)
  Machine type: pc-q35_3.1
  Hyper-V enlightenments: 
hv_stimer,hv_reenlightenment,hv_frequencies,hv_vapic,hv_reset,hv_synic,hv_runtime,hv_vpindex,hv_time,hv_relaxed,hv_spinlocks=0x1fff
  Memory: 16GB backed by 2MB huge pages

  Issue:
  Once guest is started, log gets flooded with:

  qemu-system-x86_64: vhost_region_add_section: Overlapping but not
  coherent sections at 103000

  or

  qemu-system-x86_64: vhost_region_add_section:Section rounded to 0
  prior to previous 1f000

  (line endings change)

  and as time goes guest loses network access (virtio-net-pci) and
  general performance diminishes to extent of freezing applications.

  Observations:
  1) problem disappears when hv_stimer is removed
  2) problem disappears when memory backing with huge pages is disabled
  3) problem disappears when machine type is downgraded to pc-q35_3.0

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

Re: [Qemu-block] [PATCH v2] nbd/server: attach client channel to the export's AioContext

[Eric Blake]

On 9/20/19 1:49 PM, John Snow wrote:
> 

>>> To fix this, as soon we have the export corresponding to the client,
>>> we call qio_channel_attach_aio_context() to attach the QIOChannel
>>> context to the export's AioContext. This matches with the logic at
>>> blk_aio_attached().
>>>

>>
>> I assume this patch has been superseded by Eric's later patches?
> 
> Nevermind -- my filtering got messed up slightly and I missed the
> followup. I see that Eric staged this.

I actually think both patches are needed: this one covers transactions,
while my later patch was on top of this to protect shutdown.  But now
you've made me curious; I'll see if my patch hoisted in front still
solves everything, or if we really do need both.

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



signature.asc
Description: OpenPGP digital signature

Re: [RFC 0/4] POC: Generating realistic block errors

[Tony Asleson]

On 9/20/19 1:11 PM, Kevin Wolf wrote:
> Emitting a QMP event when blkdebug injects an error makes sense to me.
> 
> I wouldn't use it for this case, though, because this would become racy.
> It could happen that the guest writes to the image, which sends a QMP
> event, and then reads before the external program has removed the error.

My POC had a single lock protecting it's shared state.  I'm kind of
surprised no one jumped on that because it's a big point of lock
contention.  One could argue that the state data and associated lock(s)
should be on each device which leads me to the next point.  I think with
careful locking and sequencing we could address this race condition so
that the error was removed before the write completed.  In fact it would
need to work that way to allow the external test code the ability to
perturb the data before it's written if that's what the test wanted to do.

-Tony

Re: [PATCH 0/3] migration/postcopy: unsentmap is not necessary

[Dr. David Alan Gilbert]

* Wei Yang (richardw.y...@linux.intel.com) wrote:
> Hi, Dave and Juan
> 
> Would you mind taking a look at this one?

Yes, I'll have a look, I'm just fighting through a bunch of other stuff.

Dave

> On Mon, Aug 19, 2019 at 02:18:40PM +0800, Wei Yang wrote:
> >Three patches to cleanup postcopy:
> >
> >[1]: split canonicalize bitmap and discard page
> >[2]: remove unsentmap since it is not necessary
> >[3]: cleanup the get_queued_page_not_dirty
> >
> >Wei Yang (3):
> >  migration/postcopy: not necessary to do discard when canonicalizing
> >bitmap
> >  migration/postcopy: unsentmap is not necessary for postcopy
> >  migration: remove sent parameter in get_queued_page_not_dirty
> >
> > include/exec/ram_addr.h |  6 ---
> > migration/ram.c | 94 +++--
> > migration/trace-events  |  2 +-
> > 3 files changed, 16 insertions(+), 86 deletions(-)
> >
> >-- 
> >2.17.1
> 
> -- 
> Wei Yang
> Help you, Help me
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

Re: [PATCH 1/2] riscv: sifive_u: Drop "clock-frequency" property of cpu nodes

[Alistair Francis]

On Fri, Sep 20, 2019 at 2:26 AM Bin Meng  wrote:
>
> The "clock-frequency" property of cpu nodes isn't required. Drop it.
>
> This is to keep in sync with Linux kernel commit below:
> https://patchwork.kernel.org/patch/11133031/
>
> Signed-off-by: Bin Meng 

Reviewed-by: Alistair Francis 

Alistair

> ---
>
>  hw/riscv/sifive_u.c | 2 --
>  include/hw/riscv/sifive_u.h | 1 -
>  2 files changed, 3 deletions(-)
>
> diff --git a/hw/riscv/sifive_u.c b/hw/riscv/sifive_u.c
> index 9f8e84b..02dd761 100644
> --- a/hw/riscv/sifive_u.c
> +++ b/hw/riscv/sifive_u.c
> @@ -151,8 +151,6 @@ static void create_fdt(SiFiveUState *s, const struct 
> MemmapEntry *memmap,
>  char *intc = g_strdup_printf("/cpus/cpu@%d/interrupt-controller", 
> cpu);
>  char *isa;
>  qemu_fdt_add_subnode(fdt, nodename);
> -qemu_fdt_setprop_cell(fdt, nodename, "clock-frequency",
> -  SIFIVE_U_CLOCK_FREQ);
>  /* cpu 0 is the management hart that does not have mmu */
>  if (cpu != 0) {
>  qemu_fdt_setprop_string(fdt, nodename, "mmu-type", "riscv,sv48");
> diff --git a/include/hw/riscv/sifive_u.h b/include/hw/riscv/sifive_u.h
> index e4df298..4850805 100644
> --- a/include/hw/riscv/sifive_u.h
> +++ b/include/hw/riscv/sifive_u.h
> @@ -75,7 +75,6 @@ enum {
>  };
>
>  enum {
> -SIFIVE_U_CLOCK_FREQ = 10,
>  SIFIVE_U_HFCLK_FREQ = ,
>  SIFIVE_U_RTCCLK_FREQ = 100
>  };
> --
> 2.7.4
>
>

Re: [PATCH 2/2] riscv: sifive_u: Add ethernet0 to the aliases node

[Alistair Francis]

On Fri, Sep 20, 2019 at 2:26 AM Bin Meng  wrote:
>
> U-Boot expects this alias to be in place in order to fix up the mac
> address of the ethernet node.
>
> This is to keep in sync with Linux kernel commit below:
> https://patchwork.kernel.org/patch/11133033/
>
> Signed-off-by: Bin Meng 

Reviewed-by: Alistair Francis 

Alistair

> ---
>
>  hw/riscv/sifive_u.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/hw/riscv/sifive_u.c b/hw/riscv/sifive_u.c
> index 02dd761..1ac51e3 100644
> --- a/hw/riscv/sifive_u.c
> +++ b/hw/riscv/sifive_u.c
> @@ -270,6 +270,10 @@ static void create_fdt(SiFiveUState *s, const struct 
> MemmapEntry *memmap,
>  s->soc.gem.conf.macaddr.a, ETH_ALEN);
>  qemu_fdt_setprop_cell(fdt, nodename, "#address-cells", 1);
>  qemu_fdt_setprop_cell(fdt, nodename, "#size-cells", 0);
> +
> +qemu_fdt_add_subnode(fdt, "/aliases");
> +qemu_fdt_setprop_string(fdt, "/aliases", "ethernet0", nodename);
> +
>  g_free(nodename);
>
>  nodename = g_strdup_printf("/soc/ethernet@%lx/ethernet-phy@0",
> @@ -297,7 +301,6 @@ static void create_fdt(SiFiveUState *s, const struct 
> MemmapEntry *memmap,
>  qemu_fdt_setprop_string(fdt, "/chosen", "bootargs", cmdline);
>  }
>
> -qemu_fdt_add_subnode(fdt, "/aliases");
>  qemu_fdt_setprop_string(fdt, "/aliases", "serial0", nodename);
>
>  g_free(nodename);
> --
> 2.7.4
>
>

Re: [PATCH] Remove unassigned_access CPU hook

[Alistair Francis]

On Fri, Sep 20, 2019 at 5:52 AM Peter Maydell  wrote:
>
> All targets have now migrated away from the old unassigned_access
> hook to the new do_transaction_failed hook. This means we can remove
> the core-code infrastructure for that hook and the code that calls it.
>
> Signed-off-by: Peter Maydell 

Reviewed-by: Alistair Francis 

Alistair

> ---
> Based-on: 
> ("[PATCH v1 0/2] RISC-V: Convert to do_transaction_failed hook")
>  -- the last of the conversions isn't in master yet, but I figured
> I might as well put the cleanup patch out for review.
>
>  include/hw/core/cpu.h | 24 
>  accel/tcg/cputlb.c|  1 -
>  memory.c  |  7 ---
>  3 files changed, 32 deletions(-)
>
> diff --git a/include/hw/core/cpu.h b/include/hw/core/cpu.h
> index c7cda65c66d..a5a13e26a20 100644
> --- a/include/hw/core/cpu.h
> +++ b/include/hw/core/cpu.h
> @@ -71,10 +71,6 @@ typedef enum MMUAccessType {
>
>  typedef struct CPUWatchpoint CPUWatchpoint;
>
> -typedef void (*CPUUnassignedAccess)(CPUState *cpu, hwaddr addr,
> -bool is_write, bool is_exec, int opaque,
> -unsigned size);
> -
>  struct TranslationBlock;
>
>  /**
> @@ -86,8 +82,6 @@ struct TranslationBlock;
>   * @reset_dump_flags: #CPUDumpFlags to use for reset logging.
>   * @has_work: Callback for checking if there is work to do.
>   * @do_interrupt: Callback for interrupt handling.
> - * @do_unassigned_access: Callback for unassigned access handling.
> - * (this is deprecated: new targets should use do_transaction_failed instead)
>   * @do_unaligned_access: Callback for unaligned access handling, if
>   * the target defines #TARGET_ALIGNED_ONLY.
>   * @do_transaction_failed: Callback for handling failed memory transactions
> @@ -174,7 +168,6 @@ typedef struct CPUClass {
>  int reset_dump_flags;
>  bool (*has_work)(CPUState *cpu);
>  void (*do_interrupt)(CPUState *cpu);
> -CPUUnassignedAccess do_unassigned_access;
>  void (*do_unaligned_access)(CPUState *cpu, vaddr addr,
>  MMUAccessType access_type,
>  int mmu_idx, uintptr_t retaddr);
> @@ -414,12 +407,6 @@ struct CPUState {
>   */
>  uintptr_t mem_io_pc;
>  vaddr mem_io_vaddr;
> -/*
> - * This is only needed for the legacy cpu_unassigned_access() hook;
> - * when all targets using it have been converted to use
> - * cpu_transaction_failed() instead it can be removed.
> - */
> -MMUAccessType mem_io_access_type;
>
>  int kvm_fd;
>  struct KVMState *kvm_state;
> @@ -879,17 +866,6 @@ void cpu_interrupt(CPUState *cpu, int mask);
>  #ifdef NEED_CPU_H
>
>  #ifdef CONFIG_SOFTMMU
> -static inline void cpu_unassigned_access(CPUState *cpu, hwaddr addr,
> - bool is_write, bool is_exec,
> - int opaque, unsigned size)
> -{
> -CPUClass *cc = CPU_GET_CLASS(cpu);
> -
> -if (cc->do_unassigned_access) {
> -cc->do_unassigned_access(cpu, addr, is_write, is_exec, opaque, size);
> -}
> -}
> -
>  static inline void cpu_unaligned_access(CPUState *cpu, vaddr addr,
>  MMUAccessType access_type,
>  int mmu_idx, uintptr_t retaddr)
> diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c
> index abae79650c0..9c21b320eb4 100644
> --- a/accel/tcg/cputlb.c
> +++ b/accel/tcg/cputlb.c
> @@ -914,7 +914,6 @@ static uint64_t io_readx(CPUArchState *env, CPUIOTLBEntry 
> *iotlbentry,
>  }
>
>  cpu->mem_io_vaddr = addr;
> -cpu->mem_io_access_type = access_type;
>
>  if (mr->global_locking && !qemu_mutex_iothread_locked()) {
>  qemu_mutex_lock_iothread();
> diff --git a/memory.c b/memory.c
> index b9dd6b94cac..93a05395cff 100644
> --- a/memory.c
> +++ b/memory.c
> @@ -1278,10 +1278,6 @@ static uint64_t unassigned_mem_read(void *opaque, 
> hwaddr addr,
>  #ifdef DEBUG_UNASSIGNED
>  printf("Unassigned mem read " TARGET_FMT_plx "\n", addr);
>  #endif
> -if (current_cpu != NULL) {
> -bool is_exec = current_cpu->mem_io_access_type == MMU_INST_FETCH;
> -cpu_unassigned_access(current_cpu, addr, false, is_exec, 0, size);
> -}
>  return 0;
>  }
>
> @@ -1291,9 +1287,6 @@ static void unassigned_mem_write(void *opaque, hwaddr 
> addr,
>  #ifdef DEBUG_UNASSIGNED
>  printf("Unassigned mem write " TARGET_FMT_plx " = 0x%"PRIx64"\n", addr, 
> val);
>  #endif
> -if (current_cpu != NULL) {
> -cpu_unassigned_access(current_cpu, addr, true, false, 0, size);
> -}
>  }
>
>  static bool unassigned_mem_accepts(void *opaque, hwaddr addr,
> --
> 2.20.1
>
>

Re: [Qemu-block] [PATCH v2] nbd/server: attach client channel to the export's AioContext

[John Snow]

On 9/20/19 2:12 PM, John Snow wrote:
> 
> 
> On 9/12/19 7:00 AM, Sergio Lopez wrote:
>> On creation, the export's AioContext is set to the same one as the
>> BlockBackend, while the AioContext in the client QIOChannel is left
>> untouched.
>>
>> As a result, when using data-plane, nbd_client_receive_next_request()
>> schedules coroutines in the IOThread AioContext, while the client's
>> QIOChannel is serviced from the main_loop, potentially triggering the
>> assertion at qio_channel_restart_[read|write].
>>
>> To fix this, as soon we have the export corresponding to the client,
>> we call qio_channel_attach_aio_context() to attach the QIOChannel
>> context to the export's AioContext. This matches with the logic at
>> blk_aio_attached().
>>
>> RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1748253
>> Signed-off-by: Sergio Lopez 
>> ---
>> Changelog
>>
>> v2:
>>  - Attach the channel once after negotiation completes, avoiding
>>duplication. (thanks Kevin Wolf).
>> ---
>>  nbd/server.c | 5 +
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/nbd/server.c b/nbd/server.c
>> index 28c3c8be85..31d624e146 100644
>> --- a/nbd/server.c
>> +++ b/nbd/server.c
>> @@ -1297,6 +1297,11 @@ static coroutine_fn int nbd_negotiate(NBDClient 
>> *client, Error **errp)
>>  return ret;
>>  }
>>  
>> +/* Attach the channel to the same AioContext as the export */
>> +if (client->exp && client->exp->ctx) {
>> +qio_channel_attach_aio_context(client->ioc, client->exp->ctx);
>> +}
>> +
>>  assert(!client->optlen);
>>  trace_nbd_negotiate_success();
>>  
>>
> 
> I assume this patch has been superseded by Eric's later patches?

Nevermind -- my filtering got messed up slightly and I missed the
followup. I see that Eric staged this.

--js

Re: [PATCH] riscv: Skip checking CSR privilege level in debugger mode

[Alistair Francis]

On Fri, Sep 20, 2019 at 7:48 AM Bin Meng  wrote:
>
> If we are in debugger mode, skip the CSR privilege level checking
> so that we can read/write all CSRs. Otherwise we get:
>
> (gdb) p/x $mtvec
> Could not fetch register "mtvec"; remote failure reply 'E14'
>
> when the hart is currently in S-mode.
>
> Reported-by: Zong Li 
> Signed-off-by: Bin Meng 

Reviewed-by: Alistair Francis 

Alistair

> ---
>
>  target/riscv/csr.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/target/riscv/csr.c b/target/riscv/csr.c
> index f767ad2..974c9c2 100644
> --- a/target/riscv/csr.c
> +++ b/target/riscv/csr.c
> @@ -801,7 +801,10 @@ int riscv_csrrw(CPURISCVState *env, int csrno, 
> target_ulong *ret_value,
>  #if !defined(CONFIG_USER_ONLY)
>  int csr_priv = get_field(csrno, 0x300);
>  int read_only = get_field(csrno, 0xC00) == 3;
> -if ((write_mask && read_only) || (env->priv < csr_priv)) {
> +if ((!env->debugger) && (env->priv < csr_priv)) {
> +return -1;
> +}
> +if (write_mask && read_only) {
>  return -1;
>  }
>  #endif
> --
> 2.7.4
>
>

Re: [PATCH v2] target/i386: clean up comments over 80 chars per line

[Eduardo Habkost]

On Fri, Sep 20, 2019 at 01:31:36PM +0800, Tao Xu wrote:
> Drop the duplicate definition of CPUID_7_0_ECX_VBMI. And add some
> comments, clean up comments over 80 chars per line.
> 
> There is an extra line in comment of CPUID_8000_0008_EBX_WBNOINVD,
> remove the extra enter and spaces.
> 
> Signed-off-by: Tao Xu 
> ---
[...]
> -#define CPUID_7_0_ECX_AVX512BMI (1U << 1)
> -#define CPUID_7_0_ECX_VBMI (1U << 1)  /* AVX-512 Vector Byte 
> Manipulation Instrs */
[...]
> +/* AVX-512 Vector Byte Manipulation Instruction */
> +#define CPUID_7_0_ECX_VBMI  (1U << 1)

I'd prefer to have the macro name matching the feature name that
is already in feature_word_info[[FEAT_7_0_ECX].feat_names
("avx512vbmi").  It's also more similar to the name used in Intel
SDM (AVX512_VBMI).


[...]
> diff --git a/target/i386/hvf/x86_cpuid.c b/target/i386/hvf/x86_cpuid.c
> index 4d957fe896..5041f48b8a 100644
> --- a/target/i386/hvf/x86_cpuid.c
> +++ b/target/i386/hvf/x86_cpuid.c
> @@ -89,7 +89,7 @@ uint32_t hvf_get_supported_cpuid(uint32_t func, uint32_t 
> idx,
>  ebx &= ~CPUID_7_0_EBX_INVPCID;
>  }
>  
> -ecx &= CPUID_7_0_ECX_AVX512BMI | CPUID_7_0_ECX_AVX512_VPOPCNTDQ;
> +ecx &= CPUID_7_0_ECX_VBMI | CPUID_7_0_ECX_AVX512_VPOPCNTDQ;
>  edx &= CPUID_7_0_EDX_AVX512_4VNNIW | CPUID_7_0_EDX_AVX512_4FMAPS;
>  } else {
>  ebx = 0;
> -- 
> 2.20.1
> 

-- 
Eduardo

Re: [PATCH v2] target/i386: clean up comments over 80 chars per line

[Eduardo Habkost]

On Fri, Sep 20, 2019 at 11:14:56AM +0200, Stefano Garzarella wrote:
> On Fri, Sep 20, 2019 at 01:31:36PM +0800, Tao Xu wrote:
> > Drop the duplicate definition of CPUID_7_0_ECX_VBMI. And add some
> > comments, clean up comments over 80 chars per line.
> > 
> > There is an extra line in comment of CPUID_8000_0008_EBX_WBNOINVD,
> > remove the extra enter and spaces.
> 
> Might it be better to split this patch into two?
> 
> One where you fix the comments over 80 chars rand one where you drop the
> CPUID_7_0_ECX_VBMI definition.

Yes, please.  The subject line implies the only changes are in
comment formatting, but the patch is replacing a macro.

-- 
Eduardo

Re: [Qemu-block] [PATCH v2] nbd/server: attach client channel to the export's AioContext

[John Snow]

On 9/12/19 7:00 AM, Sergio Lopez wrote:
> On creation, the export's AioContext is set to the same one as the
> BlockBackend, while the AioContext in the client QIOChannel is left
> untouched.
> 
> As a result, when using data-plane, nbd_client_receive_next_request()
> schedules coroutines in the IOThread AioContext, while the client's
> QIOChannel is serviced from the main_loop, potentially triggering the
> assertion at qio_channel_restart_[read|write].
> 
> To fix this, as soon we have the export corresponding to the client,
> we call qio_channel_attach_aio_context() to attach the QIOChannel
> context to the export's AioContext. This matches with the logic at
> blk_aio_attached().
> 
> RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1748253
> Signed-off-by: Sergio Lopez 
> ---
> Changelog
> 
> v2:
>  - Attach the channel once after negotiation completes, avoiding
>duplication. (thanks Kevin Wolf).
> ---
>  nbd/server.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/nbd/server.c b/nbd/server.c
> index 28c3c8be85..31d624e146 100644
> --- a/nbd/server.c
> +++ b/nbd/server.c
> @@ -1297,6 +1297,11 @@ static coroutine_fn int nbd_negotiate(NBDClient 
> *client, Error **errp)
>  return ret;
>  }
>  
> +/* Attach the channel to the same AioContext as the export */
> +if (client->exp && client->exp->ctx) {
> +qio_channel_attach_aio_context(client->ioc, client->exp->ctx);
> +}
> +
>  assert(!client->optlen);
>  trace_nbd_negotiate_success();
>  
> 

I assume this patch has been superseded by Eric's later patches?

--js

Re: [RFC 0/4] POC: Generating realistic block errors

[Kevin Wolf]

Am 20.09.2019 um 18:41 hat Tony Asleson geschrieben:
> On 9/20/19 3:36 AM, Kevin Wolf wrote:
> > I/O error inserted by blkdebug can be one-off or permanent, but since it
> > also supports using a small state machine, I think you should already be
> > able to configure your errors that are corrected by a rewrite, too, even
> > if there is no explicit support for this yet (I guess we could add it if
> > it turned out to be much easier to use).
> 
> One thing I thought about is the feasibility of having a callback for
> these errors across qapi.  For example you could register a sector for a
> read/write/both and when that operation occurs you would block IO, send
> the sector number and associated data across qapi for test code to do
> something with it and respond allowing the operation to continue
> successfully or by returning an error determined by the external test
> code to be propagated to guest.
> 
> This would allow the logic to be outside of QEMU.  So for example in the
> re-write case the test code could remove the error when it gets the
> write, instead of having that logic embedded in QEMU itself.
> 
> Thoughts?

Emitting a QMP event when blkdebug injects an error makes sense to me.

I wouldn't use it for this case, though, because this would become racy.
It could happen that the guest writes to the image, which sends a QMP
event, and then reads before the external program has removed the error.

> > The one thing I see in your series that we can't currently provide this
> > way is the exact sector number where the error happened. If you read
> > from sector 32 to 64 and there is an error configured for sector 50, you
> > just see that the whole request is failing.
> 
> Also depending on the device type the data behavior can be different
> too.  For SCSI devices I believe the specification states that the data
> leading up to the sector in error is transferred to the initiator.  For
> ATA I believe this is not true.  My code doesn't model this correctly.
> I generated the error before any data was transferred.
> 
> I'm thinking changes in blkdebug will need to be done to handle this too?

Hm... The SCSI case might get a bit tricky (if the spec does indeed say
that this is what must happen).

blkdebug can only return an I/O error for the whole request. Then the
device would ask for more information about the error and get the sector
number of the error. And then it would have to retry up to immediately
before the problematic sector.

By the way, this is an example where fixing this in the context of
blkdebug will also fix the behaviour for real I/O errors.

> > I also wonder why you had to write low-level error handling code instead
> > of calling the existing error functions. If the existing functions don't
> > give the right result in error cases, shouldn't they be fixed anyway?
> 
> I would think so too.  I'm using error constants that already exist, but
> apparently are not being used anywhere else.
> 
> 
> > And then, as John already hinted, adding code for debugging scenarios to
> > hot paths that are important for high-performance VMs that don't use any
> > debugging is less than optimal.
> 
> I agree, the POC code was experimental, but I should have done more
> effort in minimizing the run-time costs.
> 
> Additionally I think it would be good if QEMU could standardize the
> device wwn format to be consistent throughout all block device types,
> eg. uint64_t, but maybe not possible.  I also think it would be good to
> allow the wwn passed on the command line correlate with what the guest
> sees for /sys/block//device/wwid.
> 
> However, I'm assuming that QEMU has the same stance as the linux kernel
> with no visible user space breakage?

Changes that are visible to the guest break live migration, so they are
only allowed with a new option that defaults to off for existing machine
type. The default can change to on for new machine types.

> > So bringing everything together, what would you think of this plan:
> > 
> > 1. Extend blkdebug with whatever ways you need to trigger I/O errors
> >(only if the existing modes aren't sufficient at least for the start;
> >we can still always extend it later)
> > 
> > 2. Add a new BlockDriver callback that can return detailed information
> >about an error (such as the exact sector number), and wire it up
> >through BlockBackend (some blk_* function). Implement it in blkdebug.
> > 
> > 3. In the guest devices, only call the function to get detailed error
> >information in the existing error path. You can then update some
> >device state according to the details if the block driver returned
> >anything (probably only blkdebug will return something).
> > 
> > This way, we have no changes at all in the hot I/O path if you didn't
> > configure your VM with a blkdebug filter. And we avoid duplication of
> > code both in the error handler in devices and in the error injection
> > mechanisms.
> 
> This all sounds good to me.  Althou

[Bug 1844597] Re: fc1120a7f5f2d4b601003205c598077d3eb11ad2 causes a kernel panic in vfp_init on a clang built kernel

[Nathan Chancellor]

I pulled down the fix, built locally, and can confirm that this resolves
the issue. Thank you for the quick patch!

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

Title:
  fc1120a7f5f2d4b601003205c598077d3eb11ad2 causes a kernel panic in
  vfp_init on a clang built kernel

Status in QEMU:
  In Progress

Bug description:
  Commit 4cdabee7d6d2 ("ARM: configs: aspeed_g5: Enable AST2600") [1] in
  the Linux kernel enabled CONFIG_VFP. When building this config with
  Clang, the resulting kernel does not boot after commit fc1120a7f5
  ("target/arm: Implement NSACR gating of floating point") [2] (present
  since the 4.1.0 release).

  The QEMU command:

  qemu-system-arm -m 512m \
  -machine romulus-bmc \
  -no-reboot \
  -dtb out/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dtb \
  -initrd rootfs.cpio \
  -display none \
  -serial mon:stdio \
  -kernel ${KBF}/arch/arm/boot/zImage

  If it is needed, the rootfs we are using is provided at a link below
  [3].

  Debugging with QEMU reveals that the kernel panics in vfp_init,
  specifically at the line:

  vfpsid = fmrx(FPSID);

  in arch/arm/vfp/vfpmodule.c because of an illegal instruction:

  [0.058685] VFP support v0.3: 
  [0.059159] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
  [0.059525] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
5.3.0-next-20190918-dirty #1
  [0.059547] Hardware name: Generic DT based system
  [0.059702] PC is at vfp_init+0x50/0x1f4
  [0.059721] LR is at vfp_init+0x4c/0x1f4
  [0.059738] pc : [<80b0383c>]lr : [<80b03838>]psr: 6153
  [0.059756] sp : 9e497ec0  ip : 0020  fp : 9e497ed8
  [0.059773] r10:   r9 : e000  r8 : 80c06048
  [0.059792] r7 :   r6 : 80c0caac  r5 : 80c6c418  r4 : 80b037ec
  [0.059811] r3 :   r2 : 339aa372  r1 :   r0 : 0012
  [0.059859] Flags: nZCv  IRQs on  FIQs off  Mode SVC_32  ISA ARM  Segment 
none
  [0.059883] Control: 00c5387d  Table: 80004008  DAC: 0051
  [0.059997] Process swapper/0 (pid: 1, stack limit = 0x(ptrval))
  [0.060048] Stack: (0x9e497ec0 to 0x9e498000)
  [0.060205] 7ec0: 80b037ec 80b6bf0c 80b037ec    
9e497f48 80b01100
  [0.060310] 7ee0:  9eeff9e0 80a85734 809eb9be  8014b7f4 
9eeff9e0 80a85734
  [0.060408] 7f00: 9e497f48 8014b7f4 00a4 0001 0001  
80b0133c 9e497f38
  [0.060509] 7f20:  9eeff9d5 339aa372 80b6be80 80b6bf0c  
 
  [0.060606] 7f40:   9e497f70 80b01864 0001 0001 
 80b0133c
  [0.060703] 7f60: 0001 8085d268   9e497f80 80b01758 
 
  [0.060800] 7f80: 9e497f90 80b015e4  8085d268 9e497fa8 8085d27c 
 8085d268
  [0.060897] 7fa0:    801010e8   
 
  [0.060993] 7fc0:       
 
  [0.061090] 7fe0:     0013  
 
  [0.061625] [<80b0383c>] (vfp_init) from [<80b01100>] 
(do_one_initcall+0xa8/0x1e0)
  [0.061722] [<80b01100>] (do_one_initcall) from [<80b01864>] 
(do_initcall_level+0xfc/0x12c)
  [0.061742] [<80b01864>] (do_initcall_level) from [<80b01758>] 
(do_basic_setup+0x2c/0x3c)
  [0.061759] [<80b01758>] (do_basic_setup) from [<80b015e4>] 
(kernel_init_freeable+0x68/0x104)
  [0.061777] [<80b015e4>] (kernel_init_freeable) from [<8085d27c>] 
(kernel_init+0x14/0x26c)
  [0.061798] [<8085d27c>] (kernel_init) from [<801010e8>] 
(ret_from_fork+0x14/0x2c)
  [0.061835] Exception stack(0x9e497fb0 to 0x9e497ff8)
  [0.061896] 7fa0:   
 
  [0.061998] 7fc0:       
 
  [0.062080] 7fe0:     0013 
  [0.062263] Code: e586 e59f0174 ebd9d8fc e59f5170 (eef04a10) 
  [0.062679] ---[ end trace 2d338c91e4e74562 ]---

  Before fc1120a7f5:

  [0.069418] VFP support v0.3: implementor 41 architecture 1 part 20
  variant b rev 5

  Should you need to reproduce this locally:

  * clang 9.0.0 or later is needed to build this config. If you do not
  have easy access to such a build, we have a clang build script
  available [4] that can help with this:

  % ./build-llvm.py --branch llvmorg-9.0.0-rc6 \
--build-stage1-only \
--projects clang \
--targets ARM

  * Because of an unrelated build issue, linux-next needs to be used (or
  the singular patch that resolves it needs to be cherry-picked on top
  of 4cdabee7d6d2 [5]). The ker

[Bug 1844597] Re: fc1120a7f5f2d4b601003205c598077d3eb11ad2 causes a kernel panic in vfp_init on a clang built kernel

[Peter Maydell]

Should be fixed by:
https://patchew.org/QEMU/20190920174039.3916-1-peter.mayd...@linaro.org/
(which allows me to boot the kernel you attached at least as far as "didn't 
find a root filesystem").


** Changed in: qemu
   Status: New => In Progress

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

Title:
  fc1120a7f5f2d4b601003205c598077d3eb11ad2 causes a kernel panic in
  vfp_init on a clang built kernel

Status in QEMU:
  In Progress

Bug description:
  Commit 4cdabee7d6d2 ("ARM: configs: aspeed_g5: Enable AST2600") [1] in
  the Linux kernel enabled CONFIG_VFP. When building this config with
  Clang, the resulting kernel does not boot after commit fc1120a7f5
  ("target/arm: Implement NSACR gating of floating point") [2] (present
  since the 4.1.0 release).

  The QEMU command:

  qemu-system-arm -m 512m \
  -machine romulus-bmc \
  -no-reboot \
  -dtb out/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dtb \
  -initrd rootfs.cpio \
  -display none \
  -serial mon:stdio \
  -kernel ${KBF}/arch/arm/boot/zImage

  If it is needed, the rootfs we are using is provided at a link below
  [3].

  Debugging with QEMU reveals that the kernel panics in vfp_init,
  specifically at the line:

  vfpsid = fmrx(FPSID);

  in arch/arm/vfp/vfpmodule.c because of an illegal instruction:

  [0.058685] VFP support v0.3: 
  [0.059159] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
  [0.059525] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
5.3.0-next-20190918-dirty #1
  [0.059547] Hardware name: Generic DT based system
  [0.059702] PC is at vfp_init+0x50/0x1f4
  [0.059721] LR is at vfp_init+0x4c/0x1f4
  [0.059738] pc : [<80b0383c>]lr : [<80b03838>]psr: 6153
  [0.059756] sp : 9e497ec0  ip : 0020  fp : 9e497ed8
  [0.059773] r10:   r9 : e000  r8 : 80c06048
  [0.059792] r7 :   r6 : 80c0caac  r5 : 80c6c418  r4 : 80b037ec
  [0.059811] r3 :   r2 : 339aa372  r1 :   r0 : 0012
  [0.059859] Flags: nZCv  IRQs on  FIQs off  Mode SVC_32  ISA ARM  Segment 
none
  [0.059883] Control: 00c5387d  Table: 80004008  DAC: 0051
  [0.059997] Process swapper/0 (pid: 1, stack limit = 0x(ptrval))
  [0.060048] Stack: (0x9e497ec0 to 0x9e498000)
  [0.060205] 7ec0: 80b037ec 80b6bf0c 80b037ec    
9e497f48 80b01100
  [0.060310] 7ee0:  9eeff9e0 80a85734 809eb9be  8014b7f4 
9eeff9e0 80a85734
  [0.060408] 7f00: 9e497f48 8014b7f4 00a4 0001 0001  
80b0133c 9e497f38
  [0.060509] 7f20:  9eeff9d5 339aa372 80b6be80 80b6bf0c  
 
  [0.060606] 7f40:   9e497f70 80b01864 0001 0001 
 80b0133c
  [0.060703] 7f60: 0001 8085d268   9e497f80 80b01758 
 
  [0.060800] 7f80: 9e497f90 80b015e4  8085d268 9e497fa8 8085d27c 
 8085d268
  [0.060897] 7fa0:    801010e8   
 
  [0.060993] 7fc0:       
 
  [0.061090] 7fe0:     0013  
 
  [0.061625] [<80b0383c>] (vfp_init) from [<80b01100>] 
(do_one_initcall+0xa8/0x1e0)
  [0.061722] [<80b01100>] (do_one_initcall) from [<80b01864>] 
(do_initcall_level+0xfc/0x12c)
  [0.061742] [<80b01864>] (do_initcall_level) from [<80b01758>] 
(do_basic_setup+0x2c/0x3c)
  [0.061759] [<80b01758>] (do_basic_setup) from [<80b015e4>] 
(kernel_init_freeable+0x68/0x104)
  [0.061777] [<80b015e4>] (kernel_init_freeable) from [<8085d27c>] 
(kernel_init+0x14/0x26c)
  [0.061798] [<8085d27c>] (kernel_init) from [<801010e8>] 
(ret_from_fork+0x14/0x2c)
  [0.061835] Exception stack(0x9e497fb0 to 0x9e497ff8)
  [0.061896] 7fa0:   
 
  [0.061998] 7fc0:       
 
  [0.062080] 7fe0:     0013 
  [0.062263] Code: e586 e59f0174 ebd9d8fc e59f5170 (eef04a10) 
  [0.062679] ---[ end trace 2d338c91e4e74562 ]---

  Before fc1120a7f5:

  [0.069418] VFP support v0.3: implementor 41 architecture 1 part 20
  variant b rev 5

  Should you need to reproduce this locally:

  * clang 9.0.0 or later is needed to build this config. If you do not
  have easy access to such a build, we have a clang build script
  available [4] that can help with this:

  % ./build-llvm.py --branch llvmorg-9.0.0-rc6 \
--build-stage1-only \
--projects clang \
--targets ARM

  * Because of an unrelated build issu

Re: [Qemu-block] [Ping] [PATCH v6 0/3] qcow2: add zstd cluster compression

[John Snow]

On 9/18/19 12:29 PM, Denis Plotnikov wrote:
> On 12.09.2019 11:46, Denis Plotnikov wrote:
>> ping!
>>

https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg00943.html

I was under the impression you were addressing feedback from Vladimir.

--js

Re: [PULL 0/2] Python (acceptance tests) queue, 2019-09-19

[Peter Maydell]

On Thu, 19 Sep 2019 at 17:27, Cleber Rosa  wrote:
>
> The following changes since commit f8c3db33a5e863291182f8862ddf81618a7c6194:
>
>   target/sparc: Switch to do_transaction_failed() hook (2019-09-17 12:01:00 
> +0100)
>
> are available in the Git repository at:
>
>   git://github.com/clebergnu/qemu.git tags/python-next-pull-request
>
> for you to fetch changes up to 471c97a6938bda16f6e10e33437d96241482f580:
>
>   BootLinuxSshTest: Only run the tests when explicitly requested (2019-09-19 
> 09:53:39 -0400)
>
> 
>
> These are simple usability fixes for running acceptance tests on
> non-x86 hosts, and were tested primarily on ppc64le.
>
> 
>

Applied, thanks.

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

-- PMM

Re: [PATCH 00/15] ipmi: Bug fixes, add new interfaces

[Peter Maydell]

On Fri, 20 Sep 2019 at 18:36, Corey Minyard  wrote:
>
> On Fri, Sep 20, 2019 at 01:57:48PM +0100, Peter Maydell wrote:
> > Hi -- is this intended to be a pull request to be applied to
> > master? It's in the form of a pullreq but the subject header
> > says "PATCH" and you seem to be asking for more review, so I'm
> > not sure...
>
> Dang, it was meant to be a pull request for master.  I would like
> more review, and I didn't think I would get any, but it turns out
> I have gotten it for the most important parts, so pulling it
> should be good, I think.
>
> I can add the reviews and request a pull properly, if you like.

If you got some extra reviewed-by tags it would be nice to respin
with them added, I guess. You can just resend the cover letter,
no need to send all the patches again.

thanks
-- PMM

Re: [PATCH] .travis.yml: Test the release tarball

[Philippe Mathieu-Daudé]

On 9/20/19 7:42 PM, Philippe Mathieu-Daudé wrote:
> Add a job to generate the release tarball and build/install few
> QEMU targets from it.
> 
> Ideally we should build the 'efi' target from the 'roms' directory,
> but it is too time consuming.
> 
> This job is only triggered when a tag starting with 'v' is pushed,
> which is the case with release candidate tags.
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
> This job is quick enough: Ran for 15 min 32 sec
> https://travis-ci.org/philmd/qemu/jobs/587583631
> 
> Based-on: <20190912231202.12327-1-mdr...@linux.vnet.ibm.com>
> "Fix tarball builds of UEFI/EDK2 firmware"
> https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg02734.html
> ---
>  .travis.yml | 22 ++
>  1 file changed, 22 insertions(+)
> 
> diff --git a/.travis.yml b/.travis.yml
> index d0b9e099b9..a21f99d22d 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -339,3 +339,25 @@ matrix:
>  - 
> CONFIG="--target-list=xtensa-softmmu,arm-softmmu,aarch64-softmmu,alpha-softmmu"
>  - TEST_CMD="make -j3 check-tcg V=1"
>  - CACHE_NAME="${TRAVIS_BRANCH}-linux-gcc-default"
> +
> +
> +# Release builds
> +# The make-release script expect a QEMU version, so our tag must start 
> with a 'v'

*sigh* I forgot to commit my stash.

This is simply a change in the comment:

-- >8 --
@@ -342,7 +342,8 @@
 # Release builds
-# The make-release script expect a QEMU version, so our tag must
start with a 'v'
+# The make-release script expect a QEMU version, so our tag must
start with a 'v'.
+# This is the case when release candidate tags are created.
---

> +- if: tag IS present AND tag =~ ^v
> +  env:
> +# We want to build from the release tarball
> +- BUILD_DIR="release/build/dir" SRC_DIR="../../.."
> +- BASE_CONFIG="--prefix=$PWD/dist"
> +- 
> CONFIG="--target-list=x86_64-softmmu,aarch64-softmmu,armeb-linux-user,ppc-linux-user"
> +- TEST_CMD="make install -j3"
> +- QEMU_VERSION="${TRAVIS_TAG:1}"
> +- CACHE_NAME="${TRAVIS_BRANCH}-linux-gcc-default"
> +  before_script:
> +- command -v ccache && ccache --zero-stats
> +- mkdir -p ${BUILD_DIR} && cd ${BUILD_DIR}
> +  script:
> +- ${SRC_DIR}/scripts/make-release ${SRC_DIR} ${QEMU_VERSION}
> +- ls -l qemu-${QEMU_VERSION}.tar.bz2
> +- tar -xf qemu-${QEMU_VERSION}.tar.bz2 && cd qemu-${QEMU_VERSION}
> +- ./configure ${BASE_CONFIG} ${CONFIG} || { cat config.log && exit 
> 1; }
> +- make install
> 

[Bug 1844597] Re: fc1120a7f5f2d4b601003205c598077d3eb11ad2 causes a kernel panic in vfp_init on a clang built kernel

[Peter Maydell]

Thanks. I've diagnosed the problem -- when we boot a kernel directly
into non-secure state on an AArch32 CPU which implements EL3, we need to
set the NSACR.{CP11,CP10} bits so that Non-Secure is allowed to use the
FPU, but we weren't doing that. The omission didn't matter until commit
fc1120a7f5 because before that point we were ignoring the NSACR trap
bits entirely... Patch coming up shortly.

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

Title:
  fc1120a7f5f2d4b601003205c598077d3eb11ad2 causes a kernel panic in
  vfp_init on a clang built kernel

Status in QEMU:
  New

Bug description:
  Commit 4cdabee7d6d2 ("ARM: configs: aspeed_g5: Enable AST2600") [1] in
  the Linux kernel enabled CONFIG_VFP. When building this config with
  Clang, the resulting kernel does not boot after commit fc1120a7f5
  ("target/arm: Implement NSACR gating of floating point") [2] (present
  since the 4.1.0 release).

  The QEMU command:

  qemu-system-arm -m 512m \
  -machine romulus-bmc \
  -no-reboot \
  -dtb out/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dtb \
  -initrd rootfs.cpio \
  -display none \
  -serial mon:stdio \
  -kernel ${KBF}/arch/arm/boot/zImage

  If it is needed, the rootfs we are using is provided at a link below
  [3].

  Debugging with QEMU reveals that the kernel panics in vfp_init,
  specifically at the line:

  vfpsid = fmrx(FPSID);

  in arch/arm/vfp/vfpmodule.c because of an illegal instruction:

  [0.058685] VFP support v0.3: 
  [0.059159] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
  [0.059525] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
5.3.0-next-20190918-dirty #1
  [0.059547] Hardware name: Generic DT based system
  [0.059702] PC is at vfp_init+0x50/0x1f4
  [0.059721] LR is at vfp_init+0x4c/0x1f4
  [0.059738] pc : [<80b0383c>]lr : [<80b03838>]psr: 6153
  [0.059756] sp : 9e497ec0  ip : 0020  fp : 9e497ed8
  [0.059773] r10:   r9 : e000  r8 : 80c06048
  [0.059792] r7 :   r6 : 80c0caac  r5 : 80c6c418  r4 : 80b037ec
  [0.059811] r3 :   r2 : 339aa372  r1 :   r0 : 0012
  [0.059859] Flags: nZCv  IRQs on  FIQs off  Mode SVC_32  ISA ARM  Segment 
none
  [0.059883] Control: 00c5387d  Table: 80004008  DAC: 0051
  [0.059997] Process swapper/0 (pid: 1, stack limit = 0x(ptrval))
  [0.060048] Stack: (0x9e497ec0 to 0x9e498000)
  [0.060205] 7ec0: 80b037ec 80b6bf0c 80b037ec    
9e497f48 80b01100
  [0.060310] 7ee0:  9eeff9e0 80a85734 809eb9be  8014b7f4 
9eeff9e0 80a85734
  [0.060408] 7f00: 9e497f48 8014b7f4 00a4 0001 0001  
80b0133c 9e497f38
  [0.060509] 7f20:  9eeff9d5 339aa372 80b6be80 80b6bf0c  
 
  [0.060606] 7f40:   9e497f70 80b01864 0001 0001 
 80b0133c
  [0.060703] 7f60: 0001 8085d268   9e497f80 80b01758 
 
  [0.060800] 7f80: 9e497f90 80b015e4  8085d268 9e497fa8 8085d27c 
 8085d268
  [0.060897] 7fa0:    801010e8   
 
  [0.060993] 7fc0:       
 
  [0.061090] 7fe0:     0013  
 
  [0.061625] [<80b0383c>] (vfp_init) from [<80b01100>] 
(do_one_initcall+0xa8/0x1e0)
  [0.061722] [<80b01100>] (do_one_initcall) from [<80b01864>] 
(do_initcall_level+0xfc/0x12c)
  [0.061742] [<80b01864>] (do_initcall_level) from [<80b01758>] 
(do_basic_setup+0x2c/0x3c)
  [0.061759] [<80b01758>] (do_basic_setup) from [<80b015e4>] 
(kernel_init_freeable+0x68/0x104)
  [0.061777] [<80b015e4>] (kernel_init_freeable) from [<8085d27c>] 
(kernel_init+0x14/0x26c)
  [0.061798] [<8085d27c>] (kernel_init) from [<801010e8>] 
(ret_from_fork+0x14/0x2c)
  [0.061835] Exception stack(0x9e497fb0 to 0x9e497ff8)
  [0.061896] 7fa0:   
 
  [0.061998] 7fc0:       
 
  [0.062080] 7fe0:     0013 
  [0.062263] Code: e586 e59f0174 ebd9d8fc e59f5170 (eef04a10) 
  [0.062679] ---[ end trace 2d338c91e4e74562 ]---

  Before fc1120a7f5:

  [0.069418] VFP support v0.3: implementor 41 architecture 1 part 20
  variant b rev 5

  Should you need to reproduce this locally:

  * clang 9.0.0 or later is needed to build this config. If you do not
  have easy access to such a build, we have a clang build script
  available [4] that can help with this:

  % ./build-llvm.py --branch llvmorg-9.0.0-rc6 \
 

[PATCH] .travis.yml: Test the release tarball

[Philippe Mathieu-Daudé]

Add a job to generate the release tarball and build/install few
QEMU targets from it.

Ideally we should build the 'efi' target from the 'roms' directory,
but it is too time consuming.

This job is only triggered when a tag starting with 'v' is pushed,
which is the case with release candidate tags.

Signed-off-by: Philippe Mathieu-Daudé 
---
This job is quick enough: Ran for 15 min 32 sec
https://travis-ci.org/philmd/qemu/jobs/587583631

Based-on: <20190912231202.12327-1-mdr...@linux.vnet.ibm.com>
"Fix tarball builds of UEFI/EDK2 firmware"
https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg02734.html
---
 .travis.yml | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/.travis.yml b/.travis.yml
index d0b9e099b9..a21f99d22d 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -339,3 +339,25 @@ matrix:
 - 
CONFIG="--target-list=xtensa-softmmu,arm-softmmu,aarch64-softmmu,alpha-softmmu"
 - TEST_CMD="make -j3 check-tcg V=1"
 - CACHE_NAME="${TRAVIS_BRANCH}-linux-gcc-default"
+
+
+# Release builds
+# The make-release script expect a QEMU version, so our tag must start 
with a 'v'
+- if: tag IS present AND tag =~ ^v
+  env:
+# We want to build from the release tarball
+- BUILD_DIR="release/build/dir" SRC_DIR="../../.."
+- BASE_CONFIG="--prefix=$PWD/dist"
+- 
CONFIG="--target-list=x86_64-softmmu,aarch64-softmmu,armeb-linux-user,ppc-linux-user"
+- TEST_CMD="make install -j3"
+- QEMU_VERSION="${TRAVIS_TAG:1}"
+- CACHE_NAME="${TRAVIS_BRANCH}-linux-gcc-default"
+  before_script:
+- command -v ccache && ccache --zero-stats
+- mkdir -p ${BUILD_DIR} && cd ${BUILD_DIR}
+  script:
+- ${SRC_DIR}/scripts/make-release ${SRC_DIR} ${QEMU_VERSION}
+- ls -l qemu-${QEMU_VERSION}.tar.bz2
+- tar -xf qemu-${QEMU_VERSION}.tar.bz2 && cd qemu-${QEMU_VERSION}
+- ./configure ${BASE_CONFIG} ${CONFIG} || { cat config.log && exit 1; }
+- make install
-- 
2.20.1

[PATCH] hw/arm/boot.c: Set NSACR.{CP11,CP10} for NS kernel boots

[Peter Maydell]

If we're booting a Linux kernel directly into Non-Secure
state on a CPU which has Secure state, then make sure we
set the NSACR CP11 and CP10 bits, so that Non-Secure is allowed
to access the FPU. Otherwise an AArch32 kernel will UNDEF as
soon as it tries to use the FPU.

It used to not matter that we didn't do this until commit
fc1120a7f5f2d4b6, where we implemented actually honouring
these NSACR bits.

The problem only exists for CPUs where EL3 is AArch32; the
equivalent AArch64 trap bits are in CPTR_EL3 and are "0 to
not trap, 1 to trap", so the reset value of the register
permits NS access, unlike NSACR.

Fixes: fc1120a7f5
Fixes: https://bugs.launchpad.net/qemu/+bug/1844597
Cc: qemu-sta...@nongnu.org
Signed-off-by: Peter Maydell 
---
 hw/arm/boot.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/hw/arm/boot.c b/hw/arm/boot.c
index bf97ef3e339..25422660545 100644
--- a/hw/arm/boot.c
+++ b/hw/arm/boot.c
@@ -754,6 +754,8 @@ static void do_cpu_reset(void *opaque)
 (cs != first_cpu || !info->secure_board_setup)) {
 /* Linux expects non-secure state */
 env->cp15.scr_el3 |= SCR_NS;
+/* Set NSACR.{CP11,CP10} so NS can access the FPU */
+env->cp15.nsacr |= 3 << 10;
 }
 }
 
-- 
2.20.1

Re: [PATCH 00/15] ipmi: Bug fixes, add new interfaces

[Corey Minyard]

On Fri, Sep 20, 2019 at 01:57:48PM +0100, Peter Maydell wrote:
> On Thu, 19 Sep 2019 at 22:39,  wrote:
> >
> > I haven't gotten a lot of commentary on this, but I assume that means
> > that everything is ok.  It's been posted a few times and the last time
> > I received no issues, just a couple of reviews.  I would like more
> > review.  But I'm not quite sure what to do about that, I've been
> > hanging on to these changes far too long.
> >
> > The following changes since commit a77d20bafcd4cb7684168a9b4c6dc2a321aaeb50:
> >
> >   Merge remote-tracking branch 
> > 'remotes/kraxel/tags/ui-20190919-pull-request' into staging (2019-09-19 
> > 17:16:07 +0100)
> >
> > are available in the Git repository at:
> >
> >   https://github.com/cminyard/qemu.git tags/ipmi-for-release-2019-09-19
> >
> > for you to fetch changes up to d9b74295c6528fd68cebdea116b283e46543b2a2:
> >
> >   pc: Add an SMB0 ACPI device to q35 (2019-09-19 14:41:58 -0500)
> >
> > 
> > ipmi: Some bug fixes and new interfaces
> >
> > Some bug fixes for the watchdog and hopeful the BT tests.
> >
> > Change the IPMI UUID handling to give the user the ability to set it or
> > not have it.
> >
> > Add a PCI interface.
> >
> > Add an SMBus interfaces.
> 
> Hi -- is this intended to be a pull request to be applied to
> master? It's in the form of a pullreq but the subject header
> says "PATCH" and you seem to be asking for more review, so I'm
> not sure...

Dang, it was meant to be a pull request for master.  I would like
more review, and I didn't think I would get any, but it turns out
I have gotten it for the most important parts, so pulling it
should be good, I think.

I can add the reviews and request a pull properly, if you like.

Thanks,

-corey

> 
> thanks
> -- PMM

Re: [PATCH] roms: Add a 'make help' target alias

[John Snow]

On 9/20/19 1:11 PM, Philippe Mathieu-Daudé wrote:
> Various C projects provide a 'make help' target. Our root directory
> does so. The roms/ directory lacks a such rule, but already displays
> a help output when the default target is called.
> Add a 'help' target aliased to the default one, to avoid:
> 
>   $ make -C roms help
>   make: *** No rule to make target 'help'.  Stop.
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  roms/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/roms/Makefile b/roms/Makefile
> index 6cf07d3b44..3ffd13cc7e 100644
> --- a/roms/Makefile
> +++ b/roms/Makefile
> @@ -51,7 +51,7 @@ SEABIOS_EXTRAVERSION="-prebuilt.qemu.org"
>  #
>  EDK2_EFIROM = edk2/BaseTools/Source/C/bin/EfiRom
>  
> -default:
> +default help:
>   @echo "nothing is build by default"
>   @echo "available build targets:"
>   @echo "  bios   -- update bios.bin (seabios)"
> 

Reviewed-by: John Snow 

The typo can be fixed with a trivial patch or squashed into this fix,
the purity of such things doesn't matter to me.

--js

Re: [PATCH 3/3] docker: remove unused debian-sid and debian-ports

[John Snow]

On 9/20/19 12:28 PM, Philippe Mathieu-Daudé wrote:
> On 9/20/19 6:23 PM, Philippe Mathieu-Daudé wrote:
>> On 9/20/19 6:20 PM, Alex Bennée wrote:
>>> John Snow  writes:
 On 9/20/19 4:49 AM, Philippe Mathieu-Daudé wrote:
> On 9/20/19 2:14 AM, John Snow wrote:
>> These are listed as "partial" images, but have no user.
>> Remove them.
>
> Well, I have WiP users from them. I could restore this content when they
> are ready... Ports is the base of deprecated Debian archs. On the other
> side Sid is the base for edge development I use from time to time to
> test latest gcc/binutils.
> I'll try to find time to raise WiP branches to PoC.
>

 I think that's the right thing to do. Right now, the docker tests
 directory has a lot of stale entries and unusable tests. That might be
 fine for the people working on it, but it makes it hard to understand
 and use for those of us who only occasionally traipse into the directory.

 I'm removing all references to python2 -- but if there's no way for me
 to test debian-sid and debian-ports, I can't test changes I need to make
 to these "partial images", so they should be removed until they are
 consumable.

 While I am sympathetic to the idea of having a library of partial images
 to use for future tests, they're prone to rot if there's no way to
 exercise them in-tree.
>>>
>>> Don't forget some "partial" images are only used for building TCG tests
>>> - we want to keep them. But as git is forever I can drop the sid/ports
>>> stuff for now until Phillipe has something to use them again.
>>
>> For Sid I have this case:
>>
>> -- >8 --
>> #
>> # Docker Renesas RX cross-compiler target
>> #
>> # This docker target builds on the debian Sid base image.
>> #
>> # Copyright (c) 2019 Philippe Mathieu-Daudé
>> #
>> # SPDX-License-Identifier: GPL-2.0-or-later
>> #
>> FROM qemu:debian-sid
> 
> Oh well nevermind it is old, so it probably now works with debian-10.
> 
> I used the Ports base for sparc32 and x32, I don't have them on my
> workstation I'll check during the WE.
> 

If you want to keep docker-sid as a partial image for possible future
uses, you might consider adding a simple amd64 user -- debian-sid-amd64
would suffice.

It doesn't have to do anything interesting, but it exists to give
debian-sid a user.

I'd rather not waste your hard work, but I am making a plea that any
images defined in the tree can be tested by running tests that use them.

--js

Re: [RFC 0/4] POC: Generating realistic block errors

[Tony Asleson]

On 9/20/19 4:22 AM, Stefan Hajnoczi wrote:
> blkdebug is purely at the QEMU block layer level.  It is not aware of
> storage controller-specific error information or features.  If you want
> to inject NVMe- or SCSI-specific errors that make no sense in QEMU's
> block layer, then trying to do it in blkdebug becomes a layering
> violation.  This justifies adding a new error injection feature directly
> into AHCI, virtio-scsi, NVMe, etc devices.

Good discussion point...

In my opening use case for this POC I'm generically trying to create an
unrecoverable media error for a specific sector.  For each of the
different device types it's different on how that error is conveyed and
the associated data in transfer.

If we return EIO on a read_aio, that must be translated into transport
specific error right?  I really need to try out blkdebug and see what is
seen in the guest.  Maybe I'm upside down on the layering too :-)

> What I like about blkdebug is the state machine and relatively powerful
> tests that this enables.  It makes sense to reuse those for storage
> controller-specific error injection too.  In the future we may wish to
> reuse it for network cards and other emulated devices too!
> 
> Perhaps the error injection "engine" (the core blkdebug code) can be
> extracted and reused?

I think VMs are a great way to test all different error paths, just not
those specific to storage so if we could make this generic that would be
great.


I also elaborated about this a bit in one of my other responses, but
I'll reiterate here a bit too.  If we could design a suitable callback
interface utilizing qapi I think we could move the state machine/logic
out of QEMU all together.  So that the test code could contain this
logic which would allow all types of behavior that we haven't even
thought of to exist outside of QEMU and not require changes to QEMU to
exploit.

-Tony

Re: [PATCH 3/3] docker: remove unused debian-sid and debian-ports

[John Snow]

On 9/20/19 12:20 PM, Alex Bennée wrote:
> 
> John Snow  writes:
> 
>> On 9/20/19 4:49 AM, Philippe Mathieu-Daudé wrote:
>>> On 9/20/19 2:14 AM, John Snow wrote:
 These are listed as "partial" images, but have no user.
 Remove them.
>>>
>>> Well, I have WiP users from them. I could restore this content when they
>>> are ready... Ports is the base of deprecated Debian archs. On the other
>>> side Sid is the base for edge development I use from time to time to
>>> test latest gcc/binutils.
>>> I'll try to find time to raise WiP branches to PoC.
>>>
>>
>> I think that's the right thing to do. Right now, the docker tests
>> directory has a lot of stale entries and unusable tests. That might be
>> fine for the people working on it, but it makes it hard to understand
>> and use for those of us who only occasionally traipse into the directory.
>>
>> I'm removing all references to python2 -- but if there's no way for me
>> to test debian-sid and debian-ports, I can't test changes I need to make
>> to these "partial images", so they should be removed until they are
>> consumable.
>>
>> While I am sympathetic to the idea of having a library of partial images
>> to use for future tests, they're prone to rot if there's no way to
>> exercise them in-tree.
> 
> Don't forget some "partial" images are only used for building TCG tests
> - we want to keep them. But as git is forever I can drop the sid/ports
> stuff for now until Phillipe has something to use them again.
> 

Oh, where? Is that defined within the tests/docker/Makefile.include or
in the TCG tree where I have not gone spelunking before?

--js

Re: [RFC 4/4] ahci media error reporting

[John Snow]

On 9/19/19 5:49 PM, Tony Asleson wrote:
> On 9/19/19 3:43 PM, John Snow wrote:
>>
>>
>> On 9/19/19 3:48 PM, Tony Asleson wrote:
>>> Initial attempt at returning a media error for ahci.  This is certainly
>>> wrong and needs serious improvement.
>>>
>>
>> Hi; I have the unfortunate distinction of being the AHCI maintainer.
>> Please CC me on future revisions and discussion if you are interacting
>> with my problem child.
> 
> Will do and thank you for taking a look at this!
> 
>> Also remember to CC qemu-block.
>>
>>> Signed-off-by: Tony Asleson 
>>> ---
>>>  hw/ide/ahci.c | 27 +++
>>>  1 file changed, 27 insertions(+)
>>>
>>> diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c
>>> index d45393c019..f487764106 100644
>>> --- a/hw/ide/ahci.c
>>> +++ b/hw/ide/ahci.c
>>> @@ -36,6 +36,7 @@
>>>  #include "hw/ide/internal.h"
>>>  #include "hw/ide/pci.h"
>>>  #include "ahci_internal.h"
>>> +#include "block/error_inject.h"
>>>  
>>>  #include "trace.h"
>>>  
>>> @@ -999,6 +1000,22 @@ static void ncq_err(NCQTransferState *ncq_tfs)
>>>  ncq_tfs->used = 0;
>>>  }
>>>  
>>> +/*
>>> + * Figure out correct way to report media error, this is at best a guess
>>> + * and based on the output of linux kernel, not even remotely close.
>>> + */
>>
>> Depends on what kind of error, exactly, you're trying to report, and at
>> what level. (AHCI, NCQ, SATA, ATA?)
> 
> I was trying to return a media error, like a 3/1101 for SCSI device.  I
> think that is at the ATA level?
> 
> 
>> Keep in mind that you've inserted an error path for SATA drives using
>> NCQ, but seemingly haven't touched SATA drives not using NCQ, or ATAPI
>> devices using either PATA/SATA, or ATA drives on PATA.
> 
> Correct, but for trying out a simple read on a SATA drive for Linux I
> end up here first :-)  Well, until the kernel retries a number of times
> and finally gives up and returns an error while also disabling NCQ for
> the device.
> 
> 
>>> +static void ncq_media_err(NCQTransferState *ncq_tfs, uint64_t err_sector)
>>> +{
>>> +IDEState *ide_state = &ncq_tfs->drive->port.ifs[0];
>>> +
>>> +ide_state->error = ECC_ERR;
>>> +ide_state->status = READY_STAT | ERR_STAT;
>>> +ncq_tfs->drive->port_regs.scr_err |= (1 << ncq_tfs->tag);
>>> +ncq_tfs->lba = err_sector;
>>> +qemu_sglist_destroy(&ncq_tfs->sglist);
>>> +ncq_tfs->used = 0;
>>> +}
>>> +
>>
>> If you are definitely very sure you only want an ide_state error
>> difference, you could just as well call ncq_err and then patch
>> ide_state->error.
>>
>> (I am not sure that's what you want, but... maybe it is?)
> 
> As I mentioned above, return an unrecoverable media error.
> 
> SCSI sense data can report the first sector in error and I thought I
> could do the same for SATA too?
> 
>> I'd have to check -- because I can't say the AHCI emulator was designed
>> so much as congealed -- but you might need calls to ncq_finish.
>>
>> usually, ncq_cb handles the return from any NCQ command and will call
>> ncq_err and ncq_finish as appropriate to tidy up the command.
>>
>> It might be a mistake that execute_ncq_command issues ncq_err in the
>> `default` arm of the switch statement without a call to finish.
>>
>> If we do call ncq_finish from this context I'm not sure if we want
>> block_acct_done here unconditionally. We may not have started a block
>> accounting operation if we never started a backend operation. Everything
>> else looks about right to me.
>>
>>
>>>  static void ncq_finish(NCQTransferState *ncq_tfs)
>>>  {
>>>  /* If we didn't error out, set our finished bit. Errored commands
>>> @@ -1065,6 +1082,8 @@ static void execute_ncq_command(NCQTransferState 
>>> *ncq_tfs)
>>>  {
>>>  AHCIDevice *ad = ncq_tfs->drive;
>>>  IDEState *ide_state = &ad->port.ifs[0];
>>> +uint64_t error_sector = 0;
>>> +char device_id[32];
>>>  int port = ad->port_no;
>>>  
>>>  g_assert(is_ncq(ncq_tfs->cmd));
>>> @@ -1072,6 +1091,14 @@ static void execute_ncq_command(NCQTransferState 
>>> *ncq_tfs)
>>>  
>>>  switch (ncq_tfs->cmd) {
>>>  case READ_FPDMA_QUEUED:
>>> +sprintf(device_id, "%lu", ide_state->wwn);
>>
>> This seems suspicious for your design in general, but I'd like to not
>> run sprintf to a buffer in the hotpath for NCQ.
> 
> I totally agree.
> 
> I started out using integers in the call for error_in_read, as that is
> what SCSI uses internally for wwn.  Then I did NVMe and it's using a
> string that doesn't apparently need to be an integer for the wwn? so I
> changed it to being a string to accommodate.
> 
> I also find it interesting that when a SATA device wwid is dumped out
> within the guest it doesn't appear to have any correlation with the wwn
> that was passed in on the command line, eg.
> 
> -device ide-drive,drive=satadisk,bus=ahci.0,wwn=8675309
> 
> $cat /sys/block/sda/device/wwid
> t10.ATA QEMU HARDDISK   QM5
> 
> 
> This does correlate for SCSI
> 
> -device scsi-hd,drive=hd,wwn=12345

[Bug 1844597] Re: fc1120a7f5f2d4b601003205c598077d3eb11ad2 causes a kernel panic in vfp_init on a clang built kernel

[Nathan Chancellor]

** Attachment added: "aspeed-bmc-opp-romulus.dtb"
   
https://bugs.launchpad.net/qemu/+bug/1844597/+attachment/5290033/+files/aspeed-bmc-opp-romulus.dtb

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

Title:
  fc1120a7f5f2d4b601003205c598077d3eb11ad2 causes a kernel panic in
  vfp_init on a clang built kernel

Status in QEMU:
  New

Bug description:
  Commit 4cdabee7d6d2 ("ARM: configs: aspeed_g5: Enable AST2600") [1] in
  the Linux kernel enabled CONFIG_VFP. When building this config with
  Clang, the resulting kernel does not boot after commit fc1120a7f5
  ("target/arm: Implement NSACR gating of floating point") [2] (present
  since the 4.1.0 release).

  The QEMU command:

  qemu-system-arm -m 512m \
  -machine romulus-bmc \
  -no-reboot \
  -dtb out/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dtb \
  -initrd rootfs.cpio \
  -display none \
  -serial mon:stdio \
  -kernel ${KBF}/arch/arm/boot/zImage

  If it is needed, the rootfs we are using is provided at a link below
  [3].

  Debugging with QEMU reveals that the kernel panics in vfp_init,
  specifically at the line:

  vfpsid = fmrx(FPSID);

  in arch/arm/vfp/vfpmodule.c because of an illegal instruction:

  [0.058685] VFP support v0.3: 
  [0.059159] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
  [0.059525] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
5.3.0-next-20190918-dirty #1
  [0.059547] Hardware name: Generic DT based system
  [0.059702] PC is at vfp_init+0x50/0x1f4
  [0.059721] LR is at vfp_init+0x4c/0x1f4
  [0.059738] pc : [<80b0383c>]lr : [<80b03838>]psr: 6153
  [0.059756] sp : 9e497ec0  ip : 0020  fp : 9e497ed8
  [0.059773] r10:   r9 : e000  r8 : 80c06048
  [0.059792] r7 :   r6 : 80c0caac  r5 : 80c6c418  r4 : 80b037ec
  [0.059811] r3 :   r2 : 339aa372  r1 :   r0 : 0012
  [0.059859] Flags: nZCv  IRQs on  FIQs off  Mode SVC_32  ISA ARM  Segment 
none
  [0.059883] Control: 00c5387d  Table: 80004008  DAC: 0051
  [0.059997] Process swapper/0 (pid: 1, stack limit = 0x(ptrval))
  [0.060048] Stack: (0x9e497ec0 to 0x9e498000)
  [0.060205] 7ec0: 80b037ec 80b6bf0c 80b037ec    
9e497f48 80b01100
  [0.060310] 7ee0:  9eeff9e0 80a85734 809eb9be  8014b7f4 
9eeff9e0 80a85734
  [0.060408] 7f00: 9e497f48 8014b7f4 00a4 0001 0001  
80b0133c 9e497f38
  [0.060509] 7f20:  9eeff9d5 339aa372 80b6be80 80b6bf0c  
 
  [0.060606] 7f40:   9e497f70 80b01864 0001 0001 
 80b0133c
  [0.060703] 7f60: 0001 8085d268   9e497f80 80b01758 
 
  [0.060800] 7f80: 9e497f90 80b015e4  8085d268 9e497fa8 8085d27c 
 8085d268
  [0.060897] 7fa0:    801010e8   
 
  [0.060993] 7fc0:       
 
  [0.061090] 7fe0:     0013  
 
  [0.061625] [<80b0383c>] (vfp_init) from [<80b01100>] 
(do_one_initcall+0xa8/0x1e0)
  [0.061722] [<80b01100>] (do_one_initcall) from [<80b01864>] 
(do_initcall_level+0xfc/0x12c)
  [0.061742] [<80b01864>] (do_initcall_level) from [<80b01758>] 
(do_basic_setup+0x2c/0x3c)
  [0.061759] [<80b01758>] (do_basic_setup) from [<80b015e4>] 
(kernel_init_freeable+0x68/0x104)
  [0.061777] [<80b015e4>] (kernel_init_freeable) from [<8085d27c>] 
(kernel_init+0x14/0x26c)
  [0.061798] [<8085d27c>] (kernel_init) from [<801010e8>] 
(ret_from_fork+0x14/0x2c)
  [0.061835] Exception stack(0x9e497fb0 to 0x9e497ff8)
  [0.061896] 7fa0:   
 
  [0.061998] 7fc0:       
 
  [0.062080] 7fe0:     0013 
  [0.062263] Code: e586 e59f0174 ebd9d8fc e59f5170 (eef04a10) 
  [0.062679] ---[ end trace 2d338c91e4e74562 ]---

  Before fc1120a7f5:

  [0.069418] VFP support v0.3: implementor 41 architecture 1 part 20
  variant b rev 5

  Should you need to reproduce this locally:

  * clang 9.0.0 or later is needed to build this config. If you do not
  have easy access to such a build, we have a clang build script
  available [4] that can help with this:

  % ./build-llvm.py --branch llvmorg-9.0.0-rc6 \
--build-stage1-only \
--projects clang \
--targets ARM

  * Because of an unrelated build issue, linux-next needs to be used (or
  the singular patch that resolves it needs to be cherry-picked on top
 

[Bug 1844597] Re: fc1120a7f5f2d4b601003205c598077d3eb11ad2 causes a kernel panic in vfp_init on a clang built kernel

[Nathan Chancellor]

Ugh, sorry, I forget that I can actually upload files to these platforms
:(

Done, let me know if you need anything else!

** Attachment added: "zImage"
   
https://bugs.launchpad.net/qemu/+bug/1844597/+attachment/5290032/+files/zImage

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

Title:
  fc1120a7f5f2d4b601003205c598077d3eb11ad2 causes a kernel panic in
  vfp_init on a clang built kernel

Status in QEMU:
  New

Bug description:
  Commit 4cdabee7d6d2 ("ARM: configs: aspeed_g5: Enable AST2600") [1] in
  the Linux kernel enabled CONFIG_VFP. When building this config with
  Clang, the resulting kernel does not boot after commit fc1120a7f5
  ("target/arm: Implement NSACR gating of floating point") [2] (present
  since the 4.1.0 release).

  The QEMU command:

  qemu-system-arm -m 512m \
  -machine romulus-bmc \
  -no-reboot \
  -dtb out/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dtb \
  -initrd rootfs.cpio \
  -display none \
  -serial mon:stdio \
  -kernel ${KBF}/arch/arm/boot/zImage

  If it is needed, the rootfs we are using is provided at a link below
  [3].

  Debugging with QEMU reveals that the kernel panics in vfp_init,
  specifically at the line:

  vfpsid = fmrx(FPSID);

  in arch/arm/vfp/vfpmodule.c because of an illegal instruction:

  [0.058685] VFP support v0.3: 
  [0.059159] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
  [0.059525] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
5.3.0-next-20190918-dirty #1
  [0.059547] Hardware name: Generic DT based system
  [0.059702] PC is at vfp_init+0x50/0x1f4
  [0.059721] LR is at vfp_init+0x4c/0x1f4
  [0.059738] pc : [<80b0383c>]lr : [<80b03838>]psr: 6153
  [0.059756] sp : 9e497ec0  ip : 0020  fp : 9e497ed8
  [0.059773] r10:   r9 : e000  r8 : 80c06048
  [0.059792] r7 :   r6 : 80c0caac  r5 : 80c6c418  r4 : 80b037ec
  [0.059811] r3 :   r2 : 339aa372  r1 :   r0 : 0012
  [0.059859] Flags: nZCv  IRQs on  FIQs off  Mode SVC_32  ISA ARM  Segment 
none
  [0.059883] Control: 00c5387d  Table: 80004008  DAC: 0051
  [0.059997] Process swapper/0 (pid: 1, stack limit = 0x(ptrval))
  [0.060048] Stack: (0x9e497ec0 to 0x9e498000)
  [0.060205] 7ec0: 80b037ec 80b6bf0c 80b037ec    
9e497f48 80b01100
  [0.060310] 7ee0:  9eeff9e0 80a85734 809eb9be  8014b7f4 
9eeff9e0 80a85734
  [0.060408] 7f00: 9e497f48 8014b7f4 00a4 0001 0001  
80b0133c 9e497f38
  [0.060509] 7f20:  9eeff9d5 339aa372 80b6be80 80b6bf0c  
 
  [0.060606] 7f40:   9e497f70 80b01864 0001 0001 
 80b0133c
  [0.060703] 7f60: 0001 8085d268   9e497f80 80b01758 
 
  [0.060800] 7f80: 9e497f90 80b015e4  8085d268 9e497fa8 8085d27c 
 8085d268
  [0.060897] 7fa0:    801010e8   
 
  [0.060993] 7fc0:       
 
  [0.061090] 7fe0:     0013  
 
  [0.061625] [<80b0383c>] (vfp_init) from [<80b01100>] 
(do_one_initcall+0xa8/0x1e0)
  [0.061722] [<80b01100>] (do_one_initcall) from [<80b01864>] 
(do_initcall_level+0xfc/0x12c)
  [0.061742] [<80b01864>] (do_initcall_level) from [<80b01758>] 
(do_basic_setup+0x2c/0x3c)
  [0.061759] [<80b01758>] (do_basic_setup) from [<80b015e4>] 
(kernel_init_freeable+0x68/0x104)
  [0.061777] [<80b015e4>] (kernel_init_freeable) from [<8085d27c>] 
(kernel_init+0x14/0x26c)
  [0.061798] [<8085d27c>] (kernel_init) from [<801010e8>] 
(ret_from_fork+0x14/0x2c)
  [0.061835] Exception stack(0x9e497fb0 to 0x9e497ff8)
  [0.061896] 7fa0:   
 
  [0.061998] 7fc0:       
 
  [0.062080] 7fe0:     0013 
  [0.062263] Code: e586 e59f0174 ebd9d8fc e59f5170 (eef04a10) 
  [0.062679] ---[ end trace 2d338c91e4e74562 ]---

  Before fc1120a7f5:

  [0.069418] VFP support v0.3: implementor 41 architecture 1 part 20
  variant b rev 5

  Should you need to reproduce this locally:

  * clang 9.0.0 or later is needed to build this config. If you do not
  have easy access to such a build, we have a clang build script
  available [4] that can help with this:

  % ./build-llvm.py --branch llvmorg-9.0.0-rc6 \
--build-stage1-only \
--projects clang \
--targets ARM

  * Because of an unrelated build issue, linux-next needs to b

Re: [PATCH] roms: Add a 'make help' target alias

[Peter Maydell]

On Fri, 20 Sep 2019 at 18:12, Philippe Mathieu-Daudé  wrote:
>
> Various C projects provide a 'make help' target. Our root directory
> does so. The roms/ directory lacks a such rule, but already displays
> a help output when the default target is called.
> Add a 'help' target aliased to the default one, to avoid:
>
>   $ make -C roms help
>   make: *** No rule to make target 'help'.  Stop.
>
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  roms/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/roms/Makefile b/roms/Makefile
> index 6cf07d3b44..3ffd13cc7e 100644
> --- a/roms/Makefile
> +++ b/roms/Makefile
> @@ -51,7 +51,7 @@ SEABIOS_EXTRAVERSION="-prebuilt.qemu.org"
>  #
>  EDK2_EFIROM = edk2/BaseTools/Source/C/bin/EfiRom
>
> -default:
> +default help:
> @echo "nothing is build by default"

If you felt like fixing a typo, there's one here: should
be "is built"...

> @echo "available build targets:"
> @echo "  bios   -- update bios.bin (seabios)"
> --
> 2.20.1

thanks
-- PMM

[PATCH] roms: Add a 'make help' target alias

[Philippe Mathieu-Daudé]

Various C projects provide a 'make help' target. Our root directory
does so. The roms/ directory lacks a such rule, but already displays
a help output when the default target is called.
Add a 'help' target aliased to the default one, to avoid:

  $ make -C roms help
  make: *** No rule to make target 'help'.  Stop.

Signed-off-by: Philippe Mathieu-Daudé 
---
 roms/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/roms/Makefile b/roms/Makefile
index 6cf07d3b44..3ffd13cc7e 100644
--- a/roms/Makefile
+++ b/roms/Makefile
@@ -51,7 +51,7 @@ SEABIOS_EXTRAVERSION="-prebuilt.qemu.org"
 #
 EDK2_EFIROM = edk2/BaseTools/Source/C/bin/EfiRom
 
-default:
+default help:
@echo "nothing is build by default"
@echo "available build targets:"
@echo "  bios   -- update bios.bin (seabios)"
-- 
2.20.1

Re: [RFC 0/4] POC: Generating realistic block errors

[Eric Blake]

On 9/20/19 11:41 AM, Tony Asleson wrote:
> On 9/20/19 3:36 AM, Kevin Wolf wrote:
>> I/O error inserted by blkdebug can be one-off or permanent, but since it
>> also supports using a small state machine, I think you should already be
>> able to configure your errors that are corrected by a rewrite, too, even
>> if there is no explicit support for this yet (I guess we could add it if
>> it turned out to be much easier to use).
> 
> One thing I thought about is the feasibility of having a callback for
> these errors across qapi.  For example you could register a sector for a
> read/write/both and when that operation occurs you would block IO, send
> the sector number and associated data across qapi for test code to do
> something with it and respond allowing the operation to continue
> successfully or by returning an error determined by the external test
> code to be propagated to guest.
> 
> This would allow the logic to be outside of QEMU.  So for example in the
> re-write case the test code could remove the error when it gets the
> write, instead of having that logic embedded in QEMU itself.
> 
> Thoughts?

To some extent, this sounds similar to what you can accomplish with an
NBD disk.  You can write an nbdkit plugin which exposes whatever error
handling you want (such as "the first read to this sector fails with
EIO, but a second read succeeds"), but only insofar as it fits in the
bounds of what the NBD protocol exposes over the wire (so qemu would see
EIO errors, and could narrow in on which portion of the disk provides or
avoids those errors, but would not have any additional insights that
would resemble a hardware-specific query without extensions to the NBD
protocol).

I am worried, however, that making data transactions have to go through
QMP to get an answer on how to handle a specific guest request will slow
things down; QMP is not built to be an efficient dataplane interface.
If you truly want isolation (where another process receives all guest
transactions, and makes decisions on how to handle them), it seems like
writing up a remote server (as in 'nbdkit' for the NBD protocol, or a
custom provider for the iscsi protocol) is the way to go.

[I have no idea if there is an iscsi counterpart for nbdkit; the iscsi
protocol is notoriously more complex than the NBD protocol, so it's not
something I'm likely to write]


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



signature.asc
Description: OpenPGP digital signature

Invalid blob size on NVDIMM hot-add (was: RE: [RFC PATCH 0/4] ARM virt: ACPI memory hotplug support)

[Shameerali Kolothum Thodi]

Hi Laszlo/Igor,

I spend some time to debug this further as I was rebasing the nvdimm
hot-add support patches on top of the ongoing pc-dimm hot add ones.

Just to refresh the memory:

https://patchwork.kernel.org/cover/10783589/

" It is observed that hot adding nvdimm will results in guest reboot
failure. EDK2 fails to build the ACPI tables on reboot. Please find
below EDK2 log on Guest reboot after nvdimm hot-add,

ProcessCmdAddChecksum: invalid checksum range in "etc/acpi/tables"
OnRootBridgesConnected: InstallAcpiTables: Protocol Error
"

Please find below,

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: 05 March 2019 12:15
> To: Igor Mammedov 
> Cc: Shameerali Kolothum Thodi ;
> Auger Eric ; shannon.zha...@gmail.com;
> peter.mayd...@linaro.org; qemu-devel@nongnu.org; qemu-...@nongnu.org;
> xuwei (O) ; Linuxarm ; Ard
> Biesheuvel ; Leif Lindholm (Linaro address)
> 
> Subject: Re: [RFC PATCH 0/4] ARM virt: ACPI memory hotplug support
> 
> On 03/01/19 18:39, Igor Mammedov wrote:
> > On Fri, 1 Mar 2019 14:49:45 +0100
> > Laszlo Ersek  wrote:
> >
> >> On 02/28/19 15:02, Shameerali Kolothum Thodi wrote:
> >>
> >>> Ah..I missed the fact that, firmware indeed sees an update in the blob len
> here
> >>> (rounded or not) after reboot. So don’t think x86 has the same issue and
> padding
> >>> is not the right solution as Igor explained in his reply.
> >>>
> >>> I will try to debug this further. Any pointers welcome.
> >>
> >> How about this.
> >>
> >> (1) The firmware looks up the fw_cfg file called "etc/table-loader" in
> >> the fw_cfg file directory (identified by constant selector key 0x0019,
> >> FW_CFG_FILE_DIR).
> >>
> >> (2) The directory entry, once found, tells the firmware two things
> >> simultaneously. The selector key, and the size of the blob.
> >>
> >> (3) The firmware selects the selector key from step (2).
> >>
> >> (4) QEMU regenerates the ACPI payload (as a select callback).
> >>
> >> (5) The firmware reads the number of bytes from the fw_cfg blob that it
> >> learned in step (2).
> >>
> >> Here's the problem. As long as QEMU used to perform step (4) only for
> >> the purpose of refreshing PCI resources in the ACPI payload, step (4)
> >> wouldn't *resize* the blob.
> >>
> >> However, if step (4) enlarges the blob, then the byte count that step
> >> (5) uses -- from step (2) -- for reading, is obsolete.
> 
> > I've thought that was a problem with IO based fw_cfg, as reading
> size/content
> > were separates steps and that it was solved by DMA based fw_cfg file read.
> 
> The DMA backend is not relevant for this question, for two reasons:
> 
> (a) The question whether the fw_cfg transfer takes places with port IO
> vs. DMA is hidden from the fw_cfg client code; that code goes through an
> abstract library API.
> 
> (b) While the DMA method indeed lets the firmware specify the details of
> the transfer with one action, the issue is with the number of bytes that
> the firmware requests (that is, not with *how* the firmware requests the
> transfer). The firmware has to know the size of the transfer before it
> can initiate the transfer (regardless of port IO vs. DMA).
> 
> 
> My question is: assume the firmware item in question is selected, and
> the QEMU-side select callback runs (regenerating the ACPI payload). Does
> this action update the blob size in the fw_cfg file directory as well?

I think it doesn’t update the blob size on select callback which is the root
cause of this issue. And the reason looks like, qemu_ram_resize() function
returns without invoking the callback to update the blob size.
 
On boot up, Qemu builds the table and exposes it to guest,
  virt_acpi_setup()
acpi_add_rom_blob()
  rom_add_blob()
rom_set_mr()  --> mr is allocated here and ram_block used_length = 
HOST_PAGE_ALIGN(blob size);
fw_cfg_add_file_callback()
  fw_cfg_add_bytes_callback() --> This uses the blob size passed 
into it.

On select callback path,

virt_acpi_build_update()
   acpi_ram_update()
memory_region_ram_resize()
  qemu_ram_resize() -->. Here the newsize gets aligned to HOST_PAGE and 
callback is only called used_length != newsize.

https://github.com/qemu/qemu/blob/master/exec.c#L2180

Debug logs:
Initial boot:
##QEMU_DEBUG## rom_add_blob: file etc/acpi/tables size 0x64f7
##QEMU_DEBUG## fw_cfg_add_bytes_callback: key 0x21 len 0x64f7


###UEFI InstallQemuFwCfgTables: "etc/table-loader" has FwCfgItem 0x27 size 
0xD00
##QEMU_DEBUG## virt_acpi_build_update:
##QEMU_DEBUG## acpi_ram_update: size 0x64f7
##QEMU_DEBUG## qemu_ram_resize: idstr /rom@etc/acpi/tables used_length  0x7000 
newsize 0x7000 --> No callback.
.
##UEFI## ProcessCmdAllocate: QemuFwCfgFindFile("etc/acpi/tables"): size 
0x64F7 --> UEFI get the actual size, which is fine for now.

Hot-add nvdimms and reboot.

root@ubuntu:/# reboot
...

###UEFI InstallQemuFwCfgTables: "etc/table-loader" has FwCfg

RE: [PATCH v2 0/3] testing: Build WHPX enabled binaries

[Justin Terry (VM)]

Hey Phil,

I have contacted our legal department for guidance on this specific use case 
and will update you when I hear back. Thank you for your patience.

Justin Terry

> -Original Message-
> From: Philippe Mathieu-Daudé 
> Sent: Friday, September 20, 2019 8:18 AM
> To: qemu-devel@nongnu.org; Justin Terry (VM) 
> Cc: Daniel P . Berrangé ; Fam Zheng
> ; Thomas Huth ; Paolo Bonzini
> ; Alex Bennée ; Richard
> Henderson ; Eduardo Habkost ;
> Stefan Weil 
> Subject: Re: [PATCH v2 0/3] testing: Build WHPX enabled binaries
> 
> On 9/20/19 1:33 PM, Philippe Mathieu-Daudé wrote:
> > Add a job to cross-build QEMU with WHPX enabled.
> >
> > Since the WHPX is currently broken, include the patch required to have
> > successful Shippable build.
> >
> > I previously included the WHPX headers shared by the Android project,
> > and Daniel asked me to check the EULA. While trying to manually
> > install the Windows SDK, I noticed the installer fetches archives
> > directly, kindly asking where they are stored via the /fwlink API.
> > Do the same, fetch the required archives and extract them. No need to
> > accept EULA...
> >
> > Docker build the image first, then build QEMU in a instance of this
> > image. The image is internal to Shippable, the instances are not
> > reachable and are thrown once the build is finished. What we collect
> > from Shippable is the console output of QEMU build process, and if the
> > build process succeed or failed. So far we do not redistribute the
> > image or built binaries.
> >
> > Philippe Mathieu-Daudé (3):
> >   target/i386: Fix broken build with WHPX enabled
> >   tests/docker: Add fedora-win10sdk-cross image
> >   .shippable.yml: Build WHPX enabled binaries
> 
> FWIW here is the result of this series:
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapp.
> shippable.com%2Fgithub%2Fphilmd%2Fqemu%2Fruns%2F516%2F11%2Fcon
> sole&data=02%7C01%7Cjuterry%40microsoft.com%7C733a566f3233427
> 8ae6f08d73dddb39f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6
> 37045894733463150&sdata=55URgDII5r74QMUpLOD%2FWT5%2B5jbzyv
> nfCSdv%2FNaWDAw%3D&reserved=0
> Duration 17 minutes (1076 seconds)
> 
> 4m49s building the qemu:fedora-win10sdk-cross docker image, 11m10s
> building WHPX QEMU.

Re: [RFC 0/4] POC: Generating realistic block errors

[Tony Asleson]

On 9/20/19 3:36 AM, Kevin Wolf wrote:
> I/O error inserted by blkdebug can be one-off or permanent, but since it
> also supports using a small state machine, I think you should already be
> able to configure your errors that are corrected by a rewrite, too, even
> if there is no explicit support for this yet (I guess we could add it if
> it turned out to be much easier to use).

One thing I thought about is the feasibility of having a callback for
these errors across qapi.  For example you could register a sector for a
read/write/both and when that operation occurs you would block IO, send
the sector number and associated data across qapi for test code to do
something with it and respond allowing the operation to continue
successfully or by returning an error determined by the external test
code to be propagated to guest.

This would allow the logic to be outside of QEMU.  So for example in the
re-write case the test code could remove the error when it gets the
write, instead of having that logic embedded in QEMU itself.

Thoughts?

> The one thing I see in your series that we can't currently provide this
> way is the exact sector number where the error happened. If you read
> from sector 32 to 64 and there is an error configured for sector 50, you
> just see that the whole request is failing.

Also depending on the device type the data behavior can be different
too.  For SCSI devices I believe the specification states that the data
leading up to the sector in error is transferred to the initiator.  For
ATA I believe this is not true.  My code doesn't model this correctly.
I generated the error before any data was transferred.

I'm thinking changes in blkdebug will need to be done to handle this too?

> I also wonder why you had to write low-level error handling code instead
> of calling the existing error functions. If the existing functions don't
> give the right result in error cases, shouldn't they be fixed anyway?

I would think so too.  I'm using error constants that already exist, but
apparently are not being used anywhere else.


> And then, as John already hinted, adding code for debugging scenarios to
> hot paths that are important for high-performance VMs that don't use any
> debugging is less than optimal.

I agree, the POC code was experimental, but I should have done more
effort in minimizing the run-time costs.

Additionally I think it would be good if QEMU could standardize the
device wwn format to be consistent throughout all block device types,
eg. uint64_t, but maybe not possible.  I also think it would be good to
allow the wwn passed on the command line correlate with what the guest
sees for /sys/block//device/wwid.

However, I'm assuming that QEMU has the same stance as the linux kernel
with no visible user space breakage?

> 
> So bringing everything together, what would you think of this plan:
> 
> 1. Extend blkdebug with whatever ways you need to trigger I/O errors
>(only if the existing modes aren't sufficient at least for the start;
>we can still always extend it later)
> 
> 2. Add a new BlockDriver callback that can return detailed information
>about an error (such as the exact sector number), and wire it up
>through BlockBackend (some blk_* function). Implement it in blkdebug.
> 
> 3. In the guest devices, only call the function to get detailed error
>information in the existing error path. You can then update some
>device state according to the details if the block driver returned
>anything (probably only blkdebug will return something).
> 
> This way, we have no changes at all in the hot I/O path if you didn't
> configure your VM with a blkdebug filter. And we avoid duplication of
> code both in the error handler in devices and in the error injection
> mechanisms.

This all sounds good to me.  Although I'm not 100% sure of all the
specific details you are describing at the moment as I'm not that
familiar with the code base.

Thanks!

-Tony

Re: [PATCH 3/3] docker: remove unused debian-sid and debian-ports

[Philippe Mathieu-Daudé]

On 9/20/19 6:23 PM, Philippe Mathieu-Daudé wrote:
> On 9/20/19 6:20 PM, Alex Bennée wrote:
>> John Snow  writes:
>>> On 9/20/19 4:49 AM, Philippe Mathieu-Daudé wrote:
 On 9/20/19 2:14 AM, John Snow wrote:
> These are listed as "partial" images, but have no user.
> Remove them.

 Well, I have WiP users from them. I could restore this content when they
 are ready... Ports is the base of deprecated Debian archs. On the other
 side Sid is the base for edge development I use from time to time to
 test latest gcc/binutils.
 I'll try to find time to raise WiP branches to PoC.

>>>
>>> I think that's the right thing to do. Right now, the docker tests
>>> directory has a lot of stale entries and unusable tests. That might be
>>> fine for the people working on it, but it makes it hard to understand
>>> and use for those of us who only occasionally traipse into the directory.
>>>
>>> I'm removing all references to python2 -- but if there's no way for me
>>> to test debian-sid and debian-ports, I can't test changes I need to make
>>> to these "partial images", so they should be removed until they are
>>> consumable.
>>>
>>> While I am sympathetic to the idea of having a library of partial images
>>> to use for future tests, they're prone to rot if there's no way to
>>> exercise them in-tree.
>>
>> Don't forget some "partial" images are only used for building TCG tests
>> - we want to keep them. But as git is forever I can drop the sid/ports
>> stuff for now until Phillipe has something to use them again.
> 
> For Sid I have this case:
> 
> -- >8 --
> #
> # Docker Renesas RX cross-compiler target
> #
> # This docker target builds on the debian Sid base image.
> #
> # Copyright (c) 2019 Philippe Mathieu-Daudé
> #
> # SPDX-License-Identifier: GPL-2.0-or-later
> #
> FROM qemu:debian-sid

Oh well nevermind it is old, so it probably now works with debian-10.

I used the Ports base for sparc32 and x32, I don't have them on my
workstation I'll check during the WE.

> MAINTAINER Philippe Mathieu-Daudé 
> 
> RUN DEBIAN_FRONTEND=noninteractive eatmydata \
> apt install -y --no-install-recommends \
> wget
> RUN wget -qO - https://ftpmirror.gnu.org/binutils/binutils-2.32.tar.xz \
> | tar -C /usr/src -xJf - && \
> cd /usr/src/binutils-2.32 && \
> CFLAGS=-w \
> ./configure --prefix=/usr --disable-nls
> --target=rx-unknown-linux && \
> make && make install && \
> rm -rf /usr/src/binutils-2.32
> 
> RUN git clone -b rx-trunk http://pf.osdn.net/gitroot/y/ys/ysato/gcc.git \
> /usr/src/gcc
> 
> RUN DEBIAN_FRONTEND=noninteractive eatmydata \
> apt install -y --no-install-recommends \
> libgmp-dev libmpfr-dev libmpc-dev
> 
> RUN cd /usr/src/gcc && \
> CPPFLAGS=-w \
> ./configure --target=rx-unknown-linux \
> --prefix=/usr --disable-nls \
> --enable-languages=c --disable-shared \
> --disable-threads --with-uclibc \
> --disable-libssp --disable-libquadmath \
> --disable-libgomp --disable-libatomic && \
> make && make install && \
> rm -rf /usr/src/gcc
> 
> # This image isn't designed for building QEMU but building tests
> ENV QEMU_CONFIGURE_OPTS --disable-system --disable-user
> ---
> 

[PULL 2/4] iotests: Test internal snapshots with -blockdev

[Kevin Wolf]

Signed-off-by: Kevin Wolf 
Reviewed-by: Peter Krempa 
Tested-by: Peter Krempa 
---
 tests/qemu-iotests/267   | 168 
 tests/qemu-iotests/267.out   | 182 +++
 tests/qemu-iotests/common.filter |   5 +-
 tests/qemu-iotests/group |   1 +
 4 files changed, 352 insertions(+), 4 deletions(-)
 create mode 100755 tests/qemu-iotests/267
 create mode 100644 tests/qemu-iotests/267.out

diff --git a/tests/qemu-iotests/267 b/tests/qemu-iotests/267
new file mode 100755
index 00..95f885442f
--- /dev/null
+++ b/tests/qemu-iotests/267
@@ -0,0 +1,168 @@
+#!/usr/bin/env bash
+#
+# Test which nodes are involved in internal snapshots
+#
+# Copyright (C) 2019 Red Hat, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see .
+#
+
+# creator
+owner=kw...@redhat.com
+
+seq=`basename $0`
+echo "QA output created by $seq"
+
+status=1   # failure is the default!
+
+_cleanup()
+{
+_cleanup_test_img
+rm -f "$TEST_DIR/nbd"
+}
+trap "_cleanup; exit \$status" 0 1 2 3 15
+
+# get standard environment, filters and checks
+. ./common.rc
+. ./common.filter
+
+_supported_fmt qcow2
+_supported_proto file
+_supported_os Linux
+
+# Internal snapshots are (currently) impossible with refcount_bits=1
+_unsupported_imgopts 'refcount_bits=1[^0-9]'
+
+do_run_qemu()
+{
+echo Testing: "$@"
+(
+if ! test -t 0; then
+while read cmd; do
+echo $cmd
+done
+fi
+echo quit
+) | $QEMU -nographic -monitor stdio -nodefaults "$@"
+echo
+}
+
+run_qemu()
+{
+do_run_qemu "$@" 2>&1 | _filter_testdir | _filter_qemu | _filter_hmp |
+_filter_generated_node_ids | _filter_imgfmt
+}
+
+size=128M
+
+run_test()
+{
+_make_test_img $size
+printf "savevm snap0\ninfo snapshots\nloadvm snap0\n" | run_qemu "$@" | 
_filter_date
+}
+
+
+echo
+echo "=== No block devices at all ==="
+echo
+
+run_test
+
+echo
+echo "=== -drive if=none ==="
+echo
+
+run_test -drive driver=file,file="$TEST_IMG",if=none
+run_test -drive driver=$IMGFMT,file="$TEST_IMG",if=none
+run_test -drive driver=$IMGFMT,file="$TEST_IMG",if=none -device 
virtio-blk,drive=none0
+
+echo
+echo "=== -drive if=virtio ==="
+echo
+
+run_test -drive driver=file,file="$TEST_IMG",if=virtio
+run_test -drive driver=$IMGFMT,file="$TEST_IMG",if=virtio
+
+echo
+echo "=== Simple -blockdev ==="
+echo
+
+run_test -blockdev driver=file,filename="$TEST_IMG",node-name=file
+run_test -blockdev driver=file,filename="$TEST_IMG",node-name=file \
+ -blockdev driver=$IMGFMT,file=file,node-name=fmt
+run_test -blockdev driver=file,filename="$TEST_IMG",node-name=file \
+ -blockdev driver=raw,file=file,node-name=raw \
+ -blockdev driver=$IMGFMT,file=raw,node-name=fmt
+
+echo
+echo "=== -blockdev with a filter on top ==="
+echo
+
+run_test -blockdev driver=file,filename="$TEST_IMG",node-name=file \
+ -blockdev driver=$IMGFMT,file=file,node-name=fmt \
+ -blockdev driver=copy-on-read,file=fmt,node-name=filter
+
+echo
+echo "=== -blockdev with a backing file ==="
+echo
+
+TEST_IMG="$TEST_IMG.base" _make_test_img $size
+
+IMGOPTS="backing_file=$TEST_IMG.base" \
+run_test -blockdev 
driver=file,filename="$TEST_IMG.base",node-name=backing-file \
+ -blockdev driver=file,filename="$TEST_IMG",node-name=file \
+ -blockdev driver=$IMGFMT,file=file,backing=backing-file,node-name=fmt
+
+IMGOPTS="backing_file=$TEST_IMG.base" \
+run_test -blockdev 
driver=file,filename="$TEST_IMG.base",node-name=backing-file \
+ -blockdev driver=$IMGFMT,file=backing-file,node-name=backing-fmt \
+ -blockdev driver=file,filename="$TEST_IMG",node-name=file \
+ -blockdev driver=$IMGFMT,file=file,backing=backing-fmt,node-name=fmt
+
+# A snapshot should be present on the overlay, but not the backing file
+echo Internal snapshots on overlay:
+$QEMU_IMG snapshot -l "$TEST_IMG" | _filter_date
+
+echo Internal snapshots on backing file:
+$QEMU_IMG snapshot -l "$TEST_IMG.base" | _filter_date
+
+echo
+echo "=== -blockdev with NBD server on the backing file ==="
+echo
+
+IMGOPTS="backing_file=$TEST_IMG.base" _make_test_img $size
+cat <

[PULL 4/4] iotests: Remove Python 2 compatibility code

[Kevin Wolf]

Some scripts check the Python version number and have two code paths to
accomodate both Python 2 and 3. Remove the code specific to Python 2 and
assert the minimum version of 3.6 instead (check skips Python tests in
this case, so the assertion would only ever trigger if a Python script
is executed manually).

Signed-off-by: Kevin Wolf 
Reviewed-by: Eduardo Habkost 
Reviewed-by: Thomas Huth 
Reviewed-by: Philippe Mathieu-Daudé 
Reviewed-by: John Snow 
Reviewed-by: Vladimir Sementsov-Ogievskiy 
---
 tests/qemu-iotests/044   |  3 ---
 tests/qemu-iotests/163   |  3 ---
 tests/qemu-iotests/iotests.py| 13 +++--
 tests/qemu-iotests/nbd-fault-injector.py |  7 +++
 4 files changed, 6 insertions(+), 20 deletions(-)

diff --git a/tests/qemu-iotests/044 b/tests/qemu-iotests/044
index 05ea1f49c5..8b2afa2a11 100755
--- a/tests/qemu-iotests/044
+++ b/tests/qemu-iotests/044
@@ -28,9 +28,6 @@ import struct
 import subprocess
 import sys
 
-if sys.version_info.major == 2:
-range = xrange
-
 test_img = os.path.join(iotests.test_dir, 'test.img')
 
 class TestRefcountTableGrowth(iotests.QMPTestCase):
diff --git a/tests/qemu-iotests/163 b/tests/qemu-iotests/163
index 081ccc8ac1..d94728e080 100755
--- a/tests/qemu-iotests/163
+++ b/tests/qemu-iotests/163
@@ -21,9 +21,6 @@
 import os, random, iotests, struct, qcow2, sys
 from iotests import qemu_img, qemu_io, image_size
 
-if sys.version_info.major == 2:
-range = xrange
-
 test_img = os.path.join(iotests.test_dir, 'test.img')
 check_img = os.path.join(iotests.test_dir, 'check.img')
 
diff --git a/tests/qemu-iotests/iotests.py b/tests/qemu-iotests/iotests.py
index b26271187c..9fb5181c3d 100644
--- a/tests/qemu-iotests/iotests.py
+++ b/tests/qemu-iotests/iotests.py
@@ -35,6 +35,7 @@ from collections import OrderedDict
 sys.path.append(os.path.join(os.path.dirname(__file__), '..', '..', 'python'))
 from qemu import qtest
 
+assert sys.version_info >= (3,6)
 
 # This will not work if arguments contain spaces but is necessary if we
 # want to support the override options that ./check supports.
@@ -250,10 +251,7 @@ def image_size(img):
 return json.loads(r)['virtual-size']
 
 def is_str(val):
-if sys.version_info.major >= 3:
-return isinstance(val, str)
-else:
-return isinstance(val, str) or isinstance(val, unicode)
+return isinstance(val, str)
 
 test_dir_re = re.compile(r"%s" % test_dir)
 def filter_test_dir(msg):
@@ -935,12 +933,7 @@ def execute_test(test_function=None,
 else:
 # We need to filter out the time taken from the output so that
 # qemu-iotest can reliably diff the results against master output.
-if sys.version_info.major >= 3:
-output = io.StringIO()
-else:
-# io.StringIO is for unicode strings, which is not what
-# 2.x's test runner emits.
-output = io.BytesIO()
+output = io.StringIO()
 
 logging.basicConfig(level=(logging.DEBUG if debug else logging.WARN))
 
diff --git a/tests/qemu-iotests/nbd-fault-injector.py 
b/tests/qemu-iotests/nbd-fault-injector.py
index 6b2d659dee..43f095ceef 100755
--- a/tests/qemu-iotests/nbd-fault-injector.py
+++ b/tests/qemu-iotests/nbd-fault-injector.py
@@ -48,10 +48,9 @@ import sys
 import socket
 import struct
 import collections
-if sys.version_info.major >= 3:
-import configparser
-else:
-import ConfigParser as configparser
+import configparser
+
+assert sys.version_info >= (3,6)
 
 FAKE_DISK_SIZE = 8 * 1024 * 1024 * 1024 # 8 GB
 
-- 
2.20.1

Re: [RFC 4/4] ahci media error reporting

[John Snow]

On 9/20/19 4:43 AM, Kevin Wolf wrote:
> Am 19.09.2019 um 22:43 hat John Snow geschrieben:
>> I'd have to check -- because I can't say the AHCI emulator was designed
>> so much as congealed -- but you might need calls to ncq_finish.
>>
>> usually, ncq_cb handles the return from any NCQ command and will call
>> ncq_err and ncq_finish as appropriate to tidy up the command.
>>
>> It might be a mistake that execute_ncq_command issues ncq_err in the
>> `default` arm of the switch statement without a call to finish.
>>
>> If we do call ncq_finish from this context I'm not sure if we want
>> block_acct_done here unconditionally. We may not have started a block
>> accounting operation if we never started a backend operation. Everything
>> else looks about right to me.
> 
> With that much uncertainty, the one thing I'm pretty certain of is that
> someone (TM) should write some qtests - if only to figure out what
> really happens.
> 

For sure -- I handle the normative cases, but I don't test what happens
if you issue an unsupported NCQ command. (I don't know what real
hardware does right now, either. I'm sure I could read the spec and find
out, but don't have a testing setup that lets me analyze real hardware
anymore.)

I will have to defer this to someone (TM), but I suspect the code (that
I suspect was used as a basis for inserting a new error pathway in this
patch) is wrong and is missing a call to ncq_finish -- but that call
needs to not call the block accounting cleanup, because we didn't start
an operation in this case.

That's my Official Hunch.

--js

Re: [Qemu-devel] [PULL 0/8] Trivial branch patches

[Peter Maydell]

On Thu, 19 Sep 2019 at 15:02, Laurent Vivier  wrote:
>
> The following changes since commit f8c3db33a5e863291182f8862ddf81618a7c6194:
>
>   target/sparc: Switch to do_transaction_failed() hook (2019-09-17 12:01:00 
> +0100)
>
> are available in the Git repository at:
>
>   git://github.com/vivier/qemu.git tags/trivial-branch-pull-request
>
> for you to fetch changes up to 754119198de633683d7af79bc08e73c2de9df011:
>
>   configure: Add xkbcommon configure options (2019-09-19 14:42:31 +0200)
>
> 
> Trivial patches 20190919
>


Applied, thanks.

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

-- PMM

Re: [PATCH v13 00/15] backup-top filter driver for backup

[John Snow]

On 9/20/19 12:01 PM, Vladimir Sementsov-Ogievskiy wrote:
> 20.09.2019 18:55, Max Reitz wrote:
>> On 20.09.19 16:20, Vladimir Sementsov-Ogievskiy wrote:
>>> Hi all!
>>>
>>> These series introduce backup-top driver. It's a filter-node, which
>>> do copy-before-write operation. Mirror uses filter-node for handling
>>> guest writes, let's move to filter-node (from write-notifiers) for
>>> backup too.
>>>
>>> v11,v12 -> v13 changes:
>>>
>>> [v12 was two fixes in separate: [PATCH v12 0/2] backup: copy_range fixes]
>>>
>>> 01: new in v12, in v13 change comment
>>> 02: in v12: add "Fixes: " to commit msg, in v13 add John's r-b
>>> 05: rebase on 01
>>> 07: rebase on 01. It still a clean movement, keep r-b
>>
>> Thanks, applied to my block branch:
>>
>> https://git.xanclic.moe/XanClic/qemu/commits/branch/block
>>
> 
> You made my day!
> Thank you!!
> 

Guess that definitively settles the need for the creation time write
notifier, huh? :)

Congrats!

--js

[PULL 1/4] block/snapshot: Restrict set of snapshot nodes

[Kevin Wolf]

Nodes involved in internal snapshots were those that were returned by
bdrv_next(), inserted and not read-only. bdrv_next() in turn returns all
nodes that are either the root node of a BlockBackend or monitor-owned
nodes.

With the typical -drive use, this worked well enough. However, in the
typical -blockdev case, the user defines one node per option, making all
nodes monitor-owned nodes. This includes protocol nodes etc. which often
are not snapshottable, so "savevm" only returns an error.

Change the conditions so that internal snapshot still include all nodes
that have a BlockBackend attached (we definitely want to snapshot
anything attached to a guest device and probably also the built-in NBD
server; snapshotting block job BlockBackends is more of an accident, but
a preexisting one), but other monitor-owned nodes are only included if
they have no parents.

This makes internal snapshots usable again with typical -blockdev
configurations.

Cc: qemu-sta...@nongnu.org
Signed-off-by: Kevin Wolf 
Reviewed-by: Eric Blake 
Reviewed-by: Peter Krempa 
Tested-by: Peter Krempa 
---
 block/snapshot.c | 26 +++---
 1 file changed, 19 insertions(+), 7 deletions(-)

diff --git a/block/snapshot.c b/block/snapshot.c
index f2f48f926a..8081616ae9 100644
--- a/block/snapshot.c
+++ b/block/snapshot.c
@@ -31,6 +31,7 @@
 #include "qapi/qmp/qerror.h"
 #include "qapi/qmp/qstring.h"
 #include "qemu/option.h"
+#include "sysemu/block-backend.h"
 
 QemuOptsList internal_snapshot_opts = {
 .name = "snapshot",
@@ -384,6 +385,16 @@ int bdrv_snapshot_load_tmp_by_id_or_name(BlockDriverState 
*bs,
 return ret;
 }
 
+static bool bdrv_all_snapshots_includes_bs(BlockDriverState *bs)
+{
+if (!bdrv_is_inserted(bs) || bdrv_is_read_only(bs)) {
+return false;
+}
+
+/* Include all nodes that are either in use by a BlockBackend, or that
+ * aren't attached to any node, but owned by the monitor. */
+return bdrv_has_blk(bs) || QLIST_EMPTY(&bs->parents);
+}
 
 /* Group operations. All block drivers are involved.
  * These functions will properly handle dataplane (take aio_context_acquire
@@ -399,7 +410,7 @@ bool bdrv_all_can_snapshot(BlockDriverState **first_bad_bs)
 AioContext *ctx = bdrv_get_aio_context(bs);
 
 aio_context_acquire(ctx);
-if (bdrv_is_inserted(bs) && !bdrv_is_read_only(bs)) {
+if (bdrv_all_snapshots_includes_bs(bs)) {
 ok = bdrv_can_snapshot(bs);
 }
 aio_context_release(ctx);
@@ -426,8 +437,9 @@ int bdrv_all_delete_snapshot(const char *name, 
BlockDriverState **first_bad_bs,
 AioContext *ctx = bdrv_get_aio_context(bs);
 
 aio_context_acquire(ctx);
-if (bdrv_can_snapshot(bs) &&
-bdrv_snapshot_find(bs, snapshot, name) >= 0) {
+if (bdrv_all_snapshots_includes_bs(bs) &&
+bdrv_snapshot_find(bs, snapshot, name) >= 0)
+{
 ret = bdrv_snapshot_delete(bs, snapshot->id_str,
snapshot->name, err);
 }
@@ -455,7 +467,7 @@ int bdrv_all_goto_snapshot(const char *name, 
BlockDriverState **first_bad_bs,
 AioContext *ctx = bdrv_get_aio_context(bs);
 
 aio_context_acquire(ctx);
-if (bdrv_can_snapshot(bs)) {
+if (bdrv_all_snapshots_includes_bs(bs)) {
 ret = bdrv_snapshot_goto(bs, name, errp);
 }
 aio_context_release(ctx);
@@ -481,7 +493,7 @@ int bdrv_all_find_snapshot(const char *name, 
BlockDriverState **first_bad_bs)
 AioContext *ctx = bdrv_get_aio_context(bs);
 
 aio_context_acquire(ctx);
-if (bdrv_can_snapshot(bs)) {
+if (bdrv_all_snapshots_includes_bs(bs)) {
 err = bdrv_snapshot_find(bs, &sn, name);
 }
 aio_context_release(ctx);
@@ -512,7 +524,7 @@ int bdrv_all_create_snapshot(QEMUSnapshotInfo *sn,
 if (bs == vm_state_bs) {
 sn->vm_state_size = vm_state_size;
 err = bdrv_snapshot_create(bs, sn);
-} else if (bdrv_can_snapshot(bs)) {
+} else if (bdrv_all_snapshots_includes_bs(bs)) {
 sn->vm_state_size = 0;
 err = bdrv_snapshot_create(bs, sn);
 }
@@ -538,7 +550,7 @@ BlockDriverState *bdrv_all_find_vmstate_bs(void)
 bool found;
 
 aio_context_acquire(ctx);
-found = bdrv_can_snapshot(bs);
+found = bdrv_all_snapshots_includes_bs(bs) && bdrv_can_snapshot(bs);
 aio_context_release(ctx);
 
 if (found) {
-- 
2.20.1

Re: [PATCH 3/3] docker: remove unused debian-sid and debian-ports

[John Snow]

On 9/20/19 4:49 AM, Philippe Mathieu-Daudé wrote:
> On 9/20/19 2:14 AM, John Snow wrote:
>> These are listed as "partial" images, but have no user.
>> Remove them.
> 
> Well, I have WiP users from them. I could restore this content when they
> are ready... Ports is the base of deprecated Debian archs. On the other
> side Sid is the base for edge development I use from time to time to
> test latest gcc/binutils.
> I'll try to find time to raise WiP branches to PoC.
> 

I think that's the right thing to do. Right now, the docker tests
directory has a lot of stale entries and unusable tests. That might be
fine for the people working on it, but it makes it hard to understand
and use for those of us who only occasionally traipse into the directory.

I'm removing all references to python2 -- but if there's no way for me
to test debian-sid and debian-ports, I can't test changes I need to make
to these "partial images", so they should be removed until they are
consumable.

While I am sympathetic to the idea of having a library of partial images
to use for future tests, they're prone to rot if there's no way to
exercise them in-tree.

You can always re-add them when you have a user.

--js

>> Signed-off-by: John Snow 
>> ---
>>  tests/docker/Makefile.include|  4 +--
>>  tests/docker/dockerfiles/debian-ports.docker | 36 
>>  tests/docker/dockerfiles/debian-sid.docker   | 35 ---
>>  3 files changed, 2 insertions(+), 73 deletions(-)
>>  delete mode 100644 tests/docker/dockerfiles/debian-ports.docker
>>  delete mode 100644 tests/docker/dockerfiles/debian-sid.docker
>>
>> diff --git a/tests/docker/Makefile.include b/tests/docker/Makefile.include
>> index 7af476d957..c282b5c520 100644
>> --- a/tests/docker/Makefile.include
>> +++ b/tests/docker/Makefile.include
>> @@ -5,8 +5,8 @@
>>  DOCKER_SUFFIX := .docker
>>  DOCKER_FILES_DIR := $(SRC_PATH)/tests/docker/dockerfiles
>>  # we don't run tests on intermediate images (used as base by another image)
>> -DOCKER_PARTIAL_IMAGES := debian8 debian9 debian10 debian-sid
>> -DEBIAN_PARTIAL_IMAGES += debian-9-mxe debian-ports debian-bootstrap
>> +DOCKER_PARTIAL_IMAGES := debian8 debian9 debian10
>> +DEBIAN_PARTIAL_IMAGES += debian-9-mxe debian-bootstrap
>>  DOCKER_IMAGES := $(sort $(notdir $(basename $(wildcard 
>> $(DOCKER_FILES_DIR)/*.docker
>>  DOCKER_TARGETS := $(patsubst %,docker-image-%,$(DOCKER_IMAGES))
>>  # Use a global constant ccache directory to speed up repetitive builds
>> diff --git a/tests/docker/dockerfiles/debian-ports.docker 
>> b/tests/docker/dockerfiles/debian-ports.docker
>> deleted file mode 100644
>> index 61bc3f2993..00
>> --- a/tests/docker/dockerfiles/debian-ports.docker
>> +++ /dev/null
>> @@ -1,36 +0,0 @@
>> -#
>> -# Docker multiarch cross-compiler target
>> -#
>> -# This docker target is builds on Debian Ports cross compiler targets
>> -# to build distro with a selection of cross compilers for building test 
>> binaries.
>> -#
>> -# On its own you can't build much but the docker-foo-cross targets
>> -# build on top of the base debian image.
>> -#
>> -FROM debian:unstable
>> -
>> -MAINTAINER Philippe Mathieu-Daudé 
>> -
>> -RUN echo "deb [arch=amd64] http://deb.debian.org/debian unstable main" > 
>> /etc/apt/sources.list
>> -
>> -# Duplicate deb line as deb-src
>> -RUN cat /etc/apt/sources.list | sed -ne "s/^deb\ \(\[.*\]\ 
>> \)\?\(.*\)/deb-src \2/p" >> /etc/apt/sources.list
>> -
>> -# Setup some basic tools we need
>> -RUN apt-get update && \
>> -DEBIAN_FRONTEND=noninteractive apt install -yy eatmydata && \
>> -DEBIAN_FRONTEND=noninteractive eatmydata \
>> -apt-get install -y --no-install-recommends \
>> -bison \
>> -build-essential \
>> -ca-certificates \
>> -clang \
>> -debian-ports-archive-keyring \
>> -flex \
>> -gettext \
>> -git \
>> -pkg-config \
>> -psmisc \
>> -python \
>> -texinfo \
>> -$(apt-get -s build-dep qemu | egrep ^Inst | fgrep '[all]' | cut -d\ 
>>  -f2)
>> diff --git a/tests/docker/dockerfiles/debian-sid.docker 
>> b/tests/docker/dockerfiles/debian-sid.docker
>> deleted file mode 100644
>> index 2a1bcc33b2..00
>> --- a/tests/docker/dockerfiles/debian-sid.docker
>> +++ /dev/null
>> @@ -1,35 +0,0 @@
>> -#
>> -# Debian Sid Base
>> -#
>> -# Currently we can build all our guests with cross-compilers in the
>> -# latest Debian release (Buster). However new compilers will first
>> -# arrive in Sid. However Sid is a rolling distro which may be broken
>> -# at any particular time. To try and mitigate this we use Debian's
>> -# snapshot archive which provides a "stable" view of what state Sid
>> -# was in.
>> -#
>> -
>> -# This must be earlier than the snapshot date we are aiming for
>> -FROM debian:sid-20190812-slim
>> -
>> - # Use a snapshot known to work (see http://snapshot.debian.org/#Usage)
>> -ENV DEBIAN_SNAPSHOT_DATE "20190820"
>> -RUN sed -i "s%^

Re: [PATCH 3/3] docker: remove unused debian-sid and debian-ports

[Philippe Mathieu-Daudé]

On 9/20/19 6:20 PM, Alex Bennée wrote:
> John Snow  writes:
>> On 9/20/19 4:49 AM, Philippe Mathieu-Daudé wrote:
>>> On 9/20/19 2:14 AM, John Snow wrote:
 These are listed as "partial" images, but have no user.
 Remove them.
>>>
>>> Well, I have WiP users from them. I could restore this content when they
>>> are ready... Ports is the base of deprecated Debian archs. On the other
>>> side Sid is the base for edge development I use from time to time to
>>> test latest gcc/binutils.
>>> I'll try to find time to raise WiP branches to PoC.
>>>
>>
>> I think that's the right thing to do. Right now, the docker tests
>> directory has a lot of stale entries and unusable tests. That might be
>> fine for the people working on it, but it makes it hard to understand
>> and use for those of us who only occasionally traipse into the directory.
>>
>> I'm removing all references to python2 -- but if there's no way for me
>> to test debian-sid and debian-ports, I can't test changes I need to make
>> to these "partial images", so they should be removed until they are
>> consumable.
>>
>> While I am sympathetic to the idea of having a library of partial images
>> to use for future tests, they're prone to rot if there's no way to
>> exercise them in-tree.
> 
> Don't forget some "partial" images are only used for building TCG tests
> - we want to keep them. But as git is forever I can drop the sid/ports
> stuff for now until Phillipe has something to use them again.

For Sid I have this case:

-- >8 --
#
# Docker Renesas RX cross-compiler target
#
# This docker target builds on the debian Sid base image.
#
# Copyright (c) 2019 Philippe Mathieu-Daudé
#
# SPDX-License-Identifier: GPL-2.0-or-later
#
FROM qemu:debian-sid

MAINTAINER Philippe Mathieu-Daudé 

RUN DEBIAN_FRONTEND=noninteractive eatmydata \
apt install -y --no-install-recommends \
wget
RUN wget -qO - https://ftpmirror.gnu.org/binutils/binutils-2.32.tar.xz \
| tar -C /usr/src -xJf - && \
cd /usr/src/binutils-2.32 && \
CFLAGS=-w \
./configure --prefix=/usr --disable-nls
--target=rx-unknown-linux && \
make && make install && \
rm -rf /usr/src/binutils-2.32

RUN git clone -b rx-trunk http://pf.osdn.net/gitroot/y/ys/ysato/gcc.git \
/usr/src/gcc

RUN DEBIAN_FRONTEND=noninteractive eatmydata \
apt install -y --no-install-recommends \
libgmp-dev libmpfr-dev libmpc-dev

RUN cd /usr/src/gcc && \
CPPFLAGS=-w \
./configure --target=rx-unknown-linux \
--prefix=/usr --disable-nls \
--enable-languages=c --disable-shared \
--disable-threads --with-uclibc \
--disable-libssp --disable-libquadmath \
--disable-libgomp --disable-libatomic && \
make && make install && \
rm -rf /usr/src/gcc

# This image isn't designed for building QEMU but building tests
ENV QEMU_CONFIGURE_OPTS --disable-system --disable-user
---

Re: [PATCH 3/3] docker: remove unused debian-sid and debian-ports

[Alex Bennée]

Philippe Mathieu-Daudé  writes:

> On 9/20/19 6:20 PM, Alex Bennée wrote:
>> John Snow  writes:
>>> On 9/20/19 4:49 AM, Philippe Mathieu-Daudé wrote:
 On 9/20/19 2:14 AM, John Snow wrote:
> These are listed as "partial" images, but have no user.
> Remove them.

 Well, I have WiP users from them. I could restore this content when they
 are ready... Ports is the base of deprecated Debian archs. On the other
 side Sid is the base for edge development I use from time to time to
 test latest gcc/binutils.
 I'll try to find time to raise WiP branches to PoC.

>>>
>>> I think that's the right thing to do. Right now, the docker tests
>>> directory has a lot of stale entries and unusable tests. That might be
>>> fine for the people working on it, but it makes it hard to understand
>>> and use for those of us who only occasionally traipse into the directory.
>>>
>>> I'm removing all references to python2 -- but if there's no way for me
>>> to test debian-sid and debian-ports, I can't test changes I need to make
>>> to these "partial images", so they should be removed until they are
>>> consumable.
>>>
>>> While I am sympathetic to the idea of having a library of partial images
>>> to use for future tests, they're prone to rot if there's no way to
>>> exercise them in-tree.
>>
>> Don't forget some "partial" images are only used for building TCG tests
>> - we want to keep them. But as git is forever I can drop the sid/ports
>> stuff for now until Phillipe has something to use them again.
>
> For Sid I have this case:

Does it really need sid to build binutils/gcc?
>
> -- >8 --
> #
> # Docker Renesas RX cross-compiler target
> #
> # This docker target builds on the debian Sid base image.
> #
> # Copyright (c) 2019 Philippe Mathieu-Daudé
> #
> # SPDX-License-Identifier: GPL-2.0-or-later
> #
> FROM qemu:debian-sid
>
> MAINTAINER Philippe Mathieu-Daudé 
>
> RUN DEBIAN_FRONTEND=noninteractive eatmydata \
> apt install -y --no-install-recommends \
> wget
> RUN wget -qO - https://ftpmirror.gnu.org/binutils/binutils-2.32.tar.xz \
> | tar -C /usr/src -xJf - && \
> cd /usr/src/binutils-2.32 && \
> CFLAGS=-w \
> ./configure --prefix=/usr --disable-nls
> --target=rx-unknown-linux && \
> make && make install && \
> rm -rf /usr/src/binutils-2.32
>
> RUN git clone -b rx-trunk http://pf.osdn.net/gitroot/y/ys/ysato/gcc.git \
> /usr/src/gcc
>
> RUN DEBIAN_FRONTEND=noninteractive eatmydata \
> apt install -y --no-install-recommends \
> libgmp-dev libmpfr-dev libmpc-dev
>
> RUN cd /usr/src/gcc && \
> CPPFLAGS=-w \
> ./configure --target=rx-unknown-linux \
> --prefix=/usr --disable-nls \
> --enable-languages=c --disable-shared \
> --disable-threads --with-uclibc \
> --disable-libssp --disable-libquadmath \
> --disable-libgomp --disable-libatomic && \
> make && make install && \
> rm -rf /usr/src/gcc
>
> # This image isn't designed for building QEMU but building tests
> ENV QEMU_CONFIGURE_OPTS --disable-system --disable-user
> ---


--
Alex Bennée

Re: [PATCH v2 0/2] edk2 build scripts: eliminate python 2 dependency

[John Snow]

On 9/20/19 4:38 AM, Laszlo Ersek wrote:
> v1 URL:
> 20190918171141.15957-1-lersek@redhat.com">http://mid.mail-archive.com/20190918171141.15957-1-lersek@redhat.com
> 
> Updates are noted on each patch.
> 
> Cc: Eduardo Habkost 
> Cc: John Snow 
> Cc: Philippe Mathieu-Daudé 
> 
> Thanks
> Laszlo
> 
> Laszlo Ersek (2):
>   edk2 build scripts: honor external BaseTools flags with
> uefi-test-tools
>   edk2 build scripts: work around TianoCore#1607 without forcing Python
> 2
> 
>  roms/Makefile  |  1 +
>  roms/edk2-build.sh |  4 ++--
>  roms/edk2-funcs.sh | 17 +
>  tests/uefi-test-tools/Makefile |  5 -
>  tests/uefi-test-tools/build.sh |  6 --
>  5 files changed, 28 insertions(+), 5 deletions(-)
> 

Thank you again!

I'm sure we'll find all of the rough spots during the rc process, so I
am quite content for now.

Reviewed-by: John Snow 

[PULL 0/4] Block layer patches

[Kevin Wolf]

The following changes since commit 521db80318d6c749a6f6c5a65a68397af9e3ef16:

  Merge remote-tracking branch 'remotes/maxreitz/tags/pull-block-2019-09-16' 
into staging (2019-09-16 15:25:55 +0100)

are available in the Git repository at:

  git://repo.or.cz/qemu/kevin.git tags/for-upstream

for you to fetch changes up to d2c8c09fca9210d0f2399c8d570086a4a66bd22e:

  iotests: Remove Python 2 compatibility code (2019-09-20 17:58:51 +0200)


Block layer patches:

- Fix internal snapshots with typical -blockdev setups
- iotests: Require Python 3.6 or later


Kevin Wolf (4):
  block/snapshot: Restrict set of snapshot nodes
  iotests: Test internal snapshots with -blockdev
  iotests: Require Python 3.6 or later
  iotests: Remove Python 2 compatibility code

 block/snapshot.c |  26 +++--
 tests/qemu-iotests/044   |   3 -
 tests/qemu-iotests/163   |   3 -
 tests/qemu-iotests/267   | 168 
 tests/qemu-iotests/267.out   | 182 +++
 tests/qemu-iotests/check |  13 ++-
 tests/qemu-iotests/common.filter |   5 +-
 tests/qemu-iotests/group |   1 +
 tests/qemu-iotests/iotests.py|  13 +--
 tests/qemu-iotests/nbd-fault-injector.py |   7 +-
 10 files changed, 389 insertions(+), 32 deletions(-)
 create mode 100755 tests/qemu-iotests/267
 create mode 100644 tests/qemu-iotests/267.out

[PULL 3/4] iotests: Require Python 3.6 or later

[Kevin Wolf]

Running iotests is not required to build QEMU, so we can have stricter
version requirements for Python here and can make use of new features
and drop compatibility code earlier.

This makes qemu-iotests skip all Python tests if a Python version before
3.6 is used for the build.

Suggested-by: Eduardo Habkost 
Signed-off-by: Kevin Wolf 
Reviewed-by: Eduardo Habkost 
Reviewed-by: Thomas Huth 
Reviewed-by: Philippe Mathieu-Daudé 
Reviewed-by: Vladimir Sementsov-Ogievskiy 
---
 tests/qemu-iotests/check | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/tests/qemu-iotests/check b/tests/qemu-iotests/check
index 875399d79f..588c453a94 100755
--- a/tests/qemu-iotests/check
+++ b/tests/qemu-iotests/check
@@ -633,6 +633,12 @@ then
 export SOCKET_SCM_HELPER="$build_iotests/socket_scm_helper"
 fi
 
+python_usable=false
+if $PYTHON -c 'import sys; sys.exit(0 if sys.version_info >= (3,6) else 1)'
+then
+python_usable=true
+fi
+
 default_machine=$($QEMU_PROG -machine help | sed -n '/(default)/ s/ .*//p')
 default_alias_machine=$($QEMU_PROG -machine help | \
sed -n "/(alias of $default_machine)/ { s/ .*//p; q; }")
@@ -809,7 +815,12 @@ do
 start=$(_wallclock)
 
 if [ "$(head -n 1 "$source_iotests/$seq")" == "#!/usr/bin/env python" 
]; then
-run_command="$PYTHON $seq"
+if $python_usable; then
+run_command="$PYTHON $seq"
+else
+run_command="false"
+echo "Unsupported Python version" > $seq.notrun
+fi
 else
 run_command="./$seq"
 fi
-- 
2.20.1

Re: Initialize data memory in user space emulation

[Libo Zhou]

Thanks for your insightful input. I will come back to this thread after I tried 
all the options.

Cheers,
Libo Zhou




-- Original --
From:  "Peter Maydell";;
Send time: Saturday, Sep 21, 2019 0:08 AM
To: "Libo Zhou"; 
Cc: "qemu-devel"; 
Subject:  Re: Initialize data memory in user space emulation



On Fri, 20 Sep 2019 at 16:26, Libo Zhou  wrote:
>
> I actually thought about hacking it to mmap from file into guest memory 
> before running ELF. In include/exec/memory.h, the function 
> memory_region_init_ram_from_file sounds like what I need. But the entire 
> memory.h source file is wrapped by #ifndef CONFIG_USER_ONLY, I cannot use 
> that API in user space emulation, right?

Correct, you don't want to use that. You want
to put some code in linux-user/main.c, probably
just after the call to signal_init(), which opens
the host file and then calls target_mmap() to mmap
it into the host.

If you happen to have the source for the guest program,
you could also just make it do the open and mmap() itself
as the first thing it does in main() -- this is basically
equivalent. Or if the guest program is dynamically linked
then you can use QEMU's -E option to set the LD_PRELOAD
environment variable for the guest to make it load a guest
shared library that has a constructor function that does
the open/mmap before the guest main() gets control.

thanks
-- PMM