[Qemu-devel] [PULL 02/41] MAINTAINERS: target/mips: Add filter for mips in email subjects

[Aleksandar Markovic]

From: Aleksandar Markovic 

Add ability to redirect mails (sent to qemu-devel) containing
"mips" in the subject line to MIPS maintainers and reviewers.

Reviewed-by: Philippe Mathieu-Daudé 
Signed-off-by: Aleksandar Markovic 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 374e4c2..bf82eb3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -221,6 +221,7 @@ F: tests/tcg/mips/
 F: disas/mips.c
 F: disas/nanomips.h
 F: disas/nanomips.cpp
+K: ^Subject:.*(?i)mips
 
 Moxie
 M: Anthony Green 
-- 
2.7.4

[Qemu-devel] [PULL 11/41] disas: nanoMIPS: Fix types and format strings

[Aleksandar Markovic]

From: Stefan Weil 

Use POSIX types and format strings.

Reviewed-by: Aleksandar Markovic 
Signed-off-by: Aleksandar Markovic 
Signed-off-by: Stefan Weil 
---
 disas/nanomips.cpp | 20 
 disas/nanomips.h   | 10 +-
 2 files changed, 17 insertions(+), 13 deletions(-)

diff --git a/disas/nanomips.cpp b/disas/nanomips.cpp
index 1238c2f..28d78d6 100644
--- a/disas/nanomips.cpp
+++ b/disas/nanomips.cpp
@@ -258,7 +258,7 @@ namespace img
 std::string to_string(img::address a)
 {
 char buffer[256];
-sprintf(buffer, "0x%08llx", a);
+sprintf(buffer, "0x%" PRIx64, a);
 return buffer;
 }
 
@@ -284,7 +284,8 @@ uint64 NMD::renumber_registers(uint64 index, uint64 
*register_list,
 }
 
 throw std::runtime_error(img::format(
-   "Invalid register mapping index %d, size of list = %d",
+   "Invalid register mapping index %" PRIu64
+   ", size of list = %zu",
index, register_list_size));
 }
 
@@ -501,7 +502,8 @@ std::string NMD::GPR(uint64 reg)
 return gpr_reg[reg];
 }
 
-throw std::runtime_error(img::format("Invalid GPR register index %d", 
reg));
+throw std::runtime_error(img::format("Invalid GPR register index %" PRIu64,
+ reg));
 }
 
 
@@ -518,7 +520,8 @@ std::string NMD::FPR(uint64 reg)
 return fpr_reg[reg];
 }
 
-throw std::runtime_error(img::format("Invalid FPR register index %d", 
reg));
+throw std::runtime_error(img::format("Invalid FPR register index %" PRIu64,
+ reg));
 }
 
 
@@ -532,26 +535,27 @@ std::string NMD::AC(uint64 reg)
 return ac_reg[reg];
 }
 
-throw std::runtime_error(img::format("Invalid AC register index %d", reg));
+throw std::runtime_error(img::format("Invalid AC register index %" PRIu64,
+ reg));
 }
 
 
 std::string NMD::IMMEDIATE(uint64 value)
 {
-return img::format("0x%x", value);
+return img::format("0x%" PRIx64, value);
 }
 
 
 std::string NMD::IMMEDIATE(int64 value)
 {
-return img::format("%d", value);
+return img::format("%" PRId64, value);
 }
 
 
 std::string NMD::CPR(uint64 reg)
 {
 /* needs more work */
-return img::format("CP%d", reg);
+return img::format("CP%" PRIu64, reg);
 }
 
 
diff --git a/disas/nanomips.h b/disas/nanomips.h
index 84cc9a6..71428b3 100644
--- a/disas/nanomips.h
+++ b/disas/nanomips.h
@@ -24,14 +24,14 @@
 
 #include 
 
-typedef unsigned short uint16;
-typedef unsigned int uint32;
-typedef long long int64;
-typedef unsigned long long uint64;
+typedef int64_t int64;
+typedef uint64_t uint64;
+typedef uint32_t uint32;
+typedef uint16_t uint16;
 
 namespace img
 {
-typedef unsigned long long address;
+typedef uint64_t address;
 }
 
 
-- 
2.7.4

[Qemu-devel] [PULL 10/41] target/mips: Support R5900 three-operand MADD1 and MADDU1 instructions

[Aleksandar Markovic]

From: Fredrik Noring 

The three-operand MADD and MADDU are specific to R5900 cores.

Reviewed-by: Aleksandar Markovic 
Signed-off-by: Aleksandar Markovic 
Signed-off-by: Fredrik Noring 
---
 target/mips/translate.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/target/mips/translate.c b/target/mips/translate.c
index 3ad3b31..7bf0ee8 100644
--- a/target/mips/translate.c
+++ b/target/mips/translate.c
@@ -5039,7 +5039,7 @@ static void gen_muldiv(DisasContext *ctx, uint32_t opc,
  *
  * and
  *
- * MADD[U]rd, rs, rt
+ * MADD[U][1] rd, rs, rt
  *
  * such that
  *
@@ -5101,6 +5101,9 @@ static void gen_mul_txx9(DisasContext *ctx, uint32_t opc,
 tcg_temp_free_i32(t3);
 }
 break;
+case MMI_OPC_MADD1:
+acc = 1;
+/* Fall through */
 case MMI_OPC_MADD:
 {
 TCGv_i64 t2 = tcg_temp_new_i64();
@@ -5120,6 +5123,9 @@ static void gen_mul_txx9(DisasContext *ctx, uint32_t opc,
 tcg_temp_free_i64(t2);
 }
 break;
+case MMI_OPC_MADDU1:
+acc = 1;
+/* Fall through */
 case MMI_OPC_MADDU:
 {
 TCGv_i64 t2 = tcg_temp_new_i64();
@@ -26753,6 +26759,8 @@ static void decode_mmi(CPUMIPSState *env, DisasContext 
*ctx)
 case MMI_OPC_MULTU1:
 case MMI_OPC_MADD:
 case MMI_OPC_MADDU:
+case MMI_OPC_MADD1:
+case MMI_OPC_MADDU1:
 gen_mul_txx9(ctx, opc, rd, rs, rt);
 break;
 case MMI_OPC_DIV1:
@@ -26768,8 +26776,6 @@ static void decode_mmi(CPUMIPSState *env, DisasContext 
*ctx)
 gen_HILO1_tx79(ctx, opc, rd);
 break;
 case MMI_OPC_PLZCW: /* TODO: MMI_OPC_PLZCW */
-case MMI_OPC_MADD1: /* TODO: MMI_OPC_MADD1 */
-case MMI_OPC_MADDU1:/* TODO: MMI_OPC_MADDU1 */
 case MMI_OPC_PMFHL: /* TODO: MMI_OPC_PMFHL */
 case MMI_OPC_PMTHL: /* TODO: MMI_OPC_PMTHL */
 case MMI_OPC_PSLLH: /* TODO: MMI_OPC_PSLLH */
-- 
2.7.4

[Qemu-devel] [PULL 03/41] MAINTAINERS: target/mips: Reorder items alphabetically

[Aleksandar Markovic]

From: Aleksandar Markovic 

Reorder items alphabetically for better visibility.

Reviewed-by: Philippe Mathieu-Daudé 
Signed-off-by: Aleksandar Markovic 
---
 MAINTAINERS | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index bf82eb3..39fb1ae 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -209,18 +209,18 @@ R: Stefan Markovic 
 S: Maintained
 F: target/mips/
 F: default-configs/*mips*
+F: disas/mips.c
+F: disas/nanomips.cpp
+F: disas/nanomips.h
+F: hw/intc/mips_gic.c
 F: hw/mips/
 F: hw/misc/mips_*
-F: hw/intc/mips_gic.c
 F: hw/timer/mips_gictimer.c
+F: include/hw/intc/mips_gic.h
 F: include/hw/mips/
 F: include/hw/misc/mips_*
-F: include/hw/intc/mips_gic.h
 F: include/hw/timer/mips_gictimer.h
 F: tests/tcg/mips/
-F: disas/mips.c
-F: disas/nanomips.h
-F: disas/nanomips.cpp
 K: ^Subject:.*(?i)mips
 
 Moxie
-- 
2.7.4

[Qemu-devel] [PULL 05/41] atomics: Set ATOMIC_REG_SIZE=8 for MIPS n32

[Aleksandar Markovic]

From: Paul Burton 

ATOMIC_REG_SIZE is currently defined as the default sizeof(void *) for
all MIPS host builds, including those using the n32 ABI. n32 is the
MIPS64 ILP32 ABI and as such tcg/mips/tcg-target.h defines
TCG_TARGET_REG_BITS as 64 for n32 builds. If we attempt to build QEMU
for an n32 host with support for a 64b target architecture then
TCG_OVERSIZED_GUEST is 0 and accel/tcg/cputlb.c attempts to use
atomic_* functions. This fails because ATOMIC_REG_SIZE is 4, causing
the calls to QEMU_BUILD_BUG_ON(sizeof(*ptr) > ATOMIC_REG_SIZE) in the
various atomic_* functions to generate errors.

Fix this by defining ATOMIC_REG_SIZE as 8 for all MIPS64 builds, which
will cover both n32 (ILP32) & n64 (LP64) ABIs in much the same was as
we already do for x86_64/x32.

Reviewed-by: Philippe Mathieu-Daudé 
Reviewed-by: Richard Henderson 
Signed-off-by: Aleksandar Markovic 
Signed-off-by: Paul Burton 
---
 include/qemu/atomic.h | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/include/qemu/atomic.h b/include/qemu/atomic.h
index f6993a8..a6ac188 100644
--- a/include/qemu/atomic.h
+++ b/include/qemu/atomic.h
@@ -99,9 +99,10 @@
  * those few cases by hand.
  *
  * Note that x32 is fully detected with __x86_64__ + _ILP32, and that for
- * Sparc we always force the use of sparcv9 in configure.
+ * Sparc we always force the use of sparcv9 in configure. MIPS n32 (ILP32) &
+ * n64 (LP64) ABIs are both detected using __mips64.
  */
-#if defined(__x86_64__) || defined(__sparc__)
+#if defined(__x86_64__) || defined(__sparc__) || defined(__mips64)
 # define ATOMIC_REG_SIZE  8
 #else
 # define ATOMIC_REG_SIZE  sizeof(void *)
-- 
2.7.4

[Qemu-devel] [PULL 08/41] target/mips: MXU: Improve the comment containing MXU overview

[Aleksandar Markovic]

From: Aleksandar Markovic 

Improve textual description of MXU extension. These are mostly
comment formatting changes.

Reviewed-by: Stefan Markovic 
Signed-off-by: Aleksandar Markovic 
---
 target/mips/translate.c | 74 +
 1 file changed, 44 insertions(+), 30 deletions(-)

diff --git a/target/mips/translate.c b/target/mips/translate.c
index 74d16ce..e3a5a73 100644
--- a/target/mips/translate.c
+++ b/target/mips/translate.c
@@ -1399,10 +1399,12 @@ enum {
 
 
 /*
- *AN OVERVIEW OF MXU EXTENSION INSTRUCTION SET
- *
  *
- * MXU (full name: MIPS eXtension/enhanced Unit) is an SIMD extension of MIPS32
+ *   AN OVERVIEW OF MXU EXTENSION INSTRUCTION SET
+ *   
+ *
+ *
+ * MXU (full name: MIPS eXtension/enhanced Unit) is a SIMD extension of MIPS32
  * instructions set. It is designed to fit the needs of signal, graphical and
  * video processing applications. MXU instruction set is used in Xburst family
  * of microprocessors by Ingenic.
@@ -1410,39 +1412,31 @@ enum {
  * MXU unit contains 17 registers called X0-X16. X0 is always zero, and X16 is
  * the control register.
  *
- * The notation used in MXU assembler mnemonics
- * 
  *
- *  Registers:
+ * The notation used in MXU assembler mnemonics
+ * 
+ *
+ *  Register operands:
  *
  *   XRa, XRb, XRc, XRd - MXU registers
  *   Rb, Rc, Rd, Rs, Rt - general purpose MIPS registers
  *
- *  Subfields:
+ *  Non-register operands:
  *
- *   aptn1  - 1-bit accumulate add/subtract pattern
- *   aptn2  - 2-bit accumulate add/subtract pattern
- *   eptn2  - 2-bit execute add/subtract pattern
- *   optn2  - 2-bit operand pattern
- *   optn3  - 3-bit operand pattern
- *   sft4   - 4-bit shift amount
- *   strd2  - 2-bit stride amount
+ *   aptn1 - 1-bit accumulate add/subtract pattern
+ *   aptn2 - 2-bit accumulate add/subtract pattern
+ *   eptn2 - 2-bit execute add/subtract pattern
+ *   optn2 - 2-bit operand pattern
+ *   optn3 - 3-bit operand pattern
+ *   sft4  - 4-bit shift amount
+ *   strd2 - 2-bit stride amount
  *
  *  Prefixes:
  *
- *   
- * S 32
- * D 16
- * Q  8
- *
- *  Suffixes:
- *
- *   E - Expand results
- *   F - Fixed point multiplication
- *   L - Low part result
- *   R - Doing rounding
- *   V - Variable instead of immediate
- *   W - Combine above L and V
+ *   Level of parallelism:Operand size:
+ *S - single operation at a time   32 - word
+ *D - two operations in parallel   16 - half word
+ *Q - four operations in parallel   8 - byte
  *
  *  Operations:
  *
@@ -1486,6 +1480,19 @@ enum {
  *   SCOP  - Calculate x’s scope (-1, means x<0; 0, means x==0; 1, means x>0)
  *   XOR   - Logical bitwise 'exclusive or' operation
  *
+ *  Suffixes:
+ *
+ *   E - Expand results
+ *   F - Fixed point multiplication
+ *   L - Low part result
+ *   R - Doing rounding
+ *   V - Variable instead of immediate
+ *   W - Combine above L and V
+ *
+ *
+ * The list of MXU instructions grouped by functionality
+ * ~
+ *
  * Load/Store instructions   Multiplication instructions
  * ---   ---
  *
@@ -1563,6 +1570,13 @@ enum {
  *  Q16SAT XRa, XRb, XRc  S32I2M XRa, Rb
  *
  *
+ * The opcode organization of MXU instructions
+ * ~~~
+ *
+ * The bits 31..26 of all MXU instructions are equal to 0x1C (also referred
+ * as opcode SPECIAL2 in the base MIPS ISA). The organization and meaning of
+ * other bits up to the instruction level is as follows:
+ *
  *  bits
  * 05..00
  *
@@ -1700,7 +1714,7 @@ enum {
  *  │├─ 010 ─ OPC_MXU_D16MOVZ
  *  │├─ 011 ─ OPC_MXU_D16MOVN
  *  │├─ 100 ─ OPC_MXU_S32MOVZ
- *  │└─ 101 ─ OPC_MXU_S32MOV
+ *  │└─ 101 ─ OPC_MXU_S32MOVN
  *  │
  *  │   23..22
  *  ├─ 111010 ─ OPC_MXU__POOL21 ─┬─ 00 ─ OPC_MXU_Q8MAC
@@ -1712,10 +1726,10 @@ enum {
  *  └─ 11 ─(overlaps with SDBBP)
  *
  *
- *   Compiled after:
+ * Compiled after:
  *
  *   "XBurst® Instruction Set Architecture MIPS eXtension/enhanced Unit
- *   Programming Manual", Ingenic Semiconductor Co, Ltd., 2017
+ *   Programming Manual", Ingenic Semiconductor Co, Ltd., revision June 2, 2017
  */
 
 enum {
-- 
2.7.4

[Qemu-devel] [PULL 09/41] target/mips: Support R5900 three-operand MADD and MADDU instructions

[Aleksandar Markovic]

From: Philippe Mathieu-Daudé 

The three-operand MADD and MADDU are specific to Sony R5900 core,
and Toshiba TX19/TX39/TX79 cores as well.

The "32-Bit TX System RISC TX39 Family Architecture manual"
is available at https://wiki.qemu.org/File:DSAE0022432.pdf

Reviewed-by: Aleksandar Markovic 
Signed-off-by: Aleksandar Markovic 
Signed-off-by: Philippe Mathieu-Daudé
Signed-off-by: Fredrik Noring 
Tested-by: Fredrik Noring 
---
 target/mips/translate.c | 58 -
 1 file changed, 53 insertions(+), 5 deletions(-)

diff --git a/target/mips/translate.c b/target/mips/translate.c
index e3a5a73..3ad3b31 100644
--- a/target/mips/translate.c
+++ b/target/mips/translate.c
@@ -5027,8 +5027,8 @@ static void gen_muldiv(DisasContext *ctx, uint32_t opc,
 }
 
 /*
- * These MULT and MULTU instructions implemented in for example the
- * Toshiba/Sony R5900 and the Toshiba TX19, TX39 and TX79 core
+ * These MULT[U] and MADD[U] instructions implemented in for example
+ * the Toshiba/Sony R5900 and the Toshiba TX19, TX39 and TX79 core
  * architectures are special three-operand variants with the syntax
  *
  * MULT[U][1] rd, rs, rt
@@ -5037,6 +5037,14 @@ static void gen_muldiv(DisasContext *ctx, uint32_t opc,
  *
  * (rd, LO, HI) <- rs * rt
  *
+ * and
+ *
+ * MADD[U]rd, rs, rt
+ *
+ * such that
+ *
+ * (rd, LO, HI) <- (LO, HI) + rs * rt
+ *
  * where the low-order 32-bits of the result is placed into both the
  * GPR rd and the special register LO. The high-order 32-bits of the
  * result is placed into the special register HI.
@@ -5093,8 +5101,48 @@ static void gen_mul_txx9(DisasContext *ctx, uint32_t opc,
 tcg_temp_free_i32(t3);
 }
 break;
+case MMI_OPC_MADD:
+{
+TCGv_i64 t2 = tcg_temp_new_i64();
+TCGv_i64 t3 = tcg_temp_new_i64();
+
+tcg_gen_ext_tl_i64(t2, t0);
+tcg_gen_ext_tl_i64(t3, t1);
+tcg_gen_mul_i64(t2, t2, t3);
+tcg_gen_concat_tl_i64(t3, cpu_LO[acc], cpu_HI[acc]);
+tcg_gen_add_i64(t2, t2, t3);
+tcg_temp_free_i64(t3);
+gen_move_low32(cpu_LO[acc], t2);
+gen_move_high32(cpu_HI[acc], t2);
+if (rd) {
+gen_move_low32(cpu_gpr[rd], t2);
+}
+tcg_temp_free_i64(t2);
+}
+break;
+case MMI_OPC_MADDU:
+{
+TCGv_i64 t2 = tcg_temp_new_i64();
+TCGv_i64 t3 = tcg_temp_new_i64();
+
+tcg_gen_ext32u_tl(t0, t0);
+tcg_gen_ext32u_tl(t1, t1);
+tcg_gen_extu_tl_i64(t2, t0);
+tcg_gen_extu_tl_i64(t3, t1);
+tcg_gen_mul_i64(t2, t2, t3);
+tcg_gen_concat_tl_i64(t3, cpu_LO[acc], cpu_HI[acc]);
+tcg_gen_add_i64(t2, t2, t3);
+tcg_temp_free_i64(t3);
+gen_move_low32(cpu_LO[acc], t2);
+gen_move_high32(cpu_HI[acc], t2);
+if (rd) {
+gen_move_low32(cpu_gpr[rd], t2);
+}
+tcg_temp_free_i64(t2);
+}
+break;
 default:
-MIPS_INVAL("mul TXx9");
+MIPS_INVAL("mul/madd TXx9");
 generate_exception_end(ctx, EXCP_RI);
 goto out;
 }
@@ -26703,6 +26751,8 @@ static void decode_mmi(CPUMIPSState *env, DisasContext 
*ctx)
 break;
 case MMI_OPC_MULT1:
 case MMI_OPC_MULTU1:
+case MMI_OPC_MADD:
+case MMI_OPC_MADDU:
 gen_mul_txx9(ctx, opc, rd, rs, rt);
 break;
 case MMI_OPC_DIV1:
@@ -26717,8 +26767,6 @@ static void decode_mmi(CPUMIPSState *env, DisasContext 
*ctx)
 case MMI_OPC_MFHI1:
 gen_HILO1_tx79(ctx, opc, rd);
 break;
-case MMI_OPC_MADD:  /* TODO: MMI_OPC_MADD */
-case MMI_OPC_MADDU: /* TODO: MMI_OPC_MADDU */
 case MMI_OPC_PLZCW: /* TODO: MMI_OPC_PLZCW */
 case MMI_OPC_MADD1: /* TODO: MMI_OPC_MADD1 */
 case MMI_OPC_MADDU1:/* TODO: MMI_OPC_MADDU1 */
-- 
2.7.4

[Qemu-devel] [PULL 07/41] target/mips: MXU: Add generic naming for optn2 constants

[Aleksandar Markovic]

From: Aleksandar Markovic 

Add generic naming involving generig suffixes OPTN0, OPTN1, OPTN2,
OPTN3 for four optn2 constants. Existing suffixes WW, LW, HW, XW
are not quite appropriate for some instructions using optn2.

Reviewed-by: Stefan Markovic 
Signed-off-by: Aleksandar Markovic 
---
 target/mips/translate.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/target/mips/translate.c b/target/mips/translate.c
index e0c8d8c..74d16ce 100644
--- a/target/mips/translate.c
+++ b/target/mips/translate.c
@@ -24238,6 +24238,11 @@ static void decode_opc_special(CPUMIPSState *env, 
DisasContext *ctx)
 #define MXU_EPTN2_SS3
 
 /* MXU operand getting pattern 'optn2' */
+#define MXU_OPTN2_PTN0  0
+#define MXU_OPTN2_PTN1  1
+#define MXU_OPTN2_PTN2  2
+#define MXU_OPTN2_PTN3  3
+/* alternative naming scheme for 'optn2' */
 #define MXU_OPTN2_WW0
 #define MXU_OPTN2_LW1
 #define MXU_OPTN2_HW2
-- 
2.7.4

[Qemu-devel] [PULL 06/41] target/mips: MXU: Add missing opcodes/decoding for LX* instructions

[Aleksandar Markovic]

From: Aleksandar Markovic 

Add missing opcodes and decoding engine for LXB, LXH, LXW, LXBU,
and LXHU instructions. They were for some reason forgotten in
previous commits. The MXU opcode list and decoding engine should
be now complete.

Reviewed-by: Stefan Markovic 
Signed-off-by: Aleksandar Markovic 
---
 target/mips/translate.c | 140 +++-
 1 file changed, 102 insertions(+), 38 deletions(-)

diff --git a/target/mips/translate.c b/target/mips/translate.c
index e9c23a5..e0c8d8c 100644
--- a/target/mips/translate.c
+++ b/target/mips/translate.c
@@ -1663,12 +1663,21 @@ enum {
  *  │   20..18
  *  ├─ 100111 ─ OPC_MXU__POOL16 ─┬─ 000 ─ OPC_MXU_D32SARW
  *  │├─ 001 ─ OPC_MXU_S32ALN
- *  ├─ 101000 ─ OPC_MXU_LXB  ├─ 010 ─ OPC_MXU_S32ALNI
- *  ├─ 101001 ─├─ 011 ─ OPC_MXU_S32NOR
- *  ├─ 101010 ─ OPC_MXU_S16LDD   ├─ 100 ─ OPC_MXU_S32AND
- *  ├─ 101011 ─ OPC_MXU_S16STD   ├─ 101 ─ OPC_MXU_S32OR
- *  ├─ 101100 ─ OPC_MXU_S16LDI   ├─ 110 ─ OPC_MXU_S32XOR
- *  ├─ 101101 ─ OPC_MXU_S16SDI   └─ 111 ─ OPC_MXU_S32LUI
+ *  │├─ 010 ─ OPC_MXU_S32ALNI
+ *  │├─ 011 ─ OPC_MXU_S32NOR
+ *  │├─ 100 ─ OPC_MXU_S32AND
+ *  │├─ 101 ─ OPC_MXU_S32OR
+ *  │├─ 110 ─ OPC_MXU_S32XOR
+ *  │└─ 111 ─ OPC_MXU_S32LUI
+ *  │
+ *  │   7..5
+ *  ├─ 101000 ─ OPC_MXU__POOL17 ─┬─ 000 ─ OPC_MXU_LXB
+ *  │├─ 001 ─ OPC_MXU_LXH
+ *  ├─ 101001 ─├─ 011 ─ OPC_MXU_LXW
+ *  ├─ 101010 ─ OPC_MXU_S16LDD   ├─ 100 ─ OPC_MXU_LXBU
+ *  ├─ 101011 ─ OPC_MXU_S16STD   └─ 101 ─ OPC_MXU_LXHU
+ *  ├─ 101100 ─ OPC_MXU_S16LDI
+ *  ├─ 101101 ─ OPC_MXU_S16SDI
  *  ├─ 101110 ─ OPC_MXU_S32M2I
  *  ├─ 10 ─ OPC_MXU_S32I2M
  *  ├─ 11 ─ OPC_MXU_D32SLL
@@ -1678,15 +1687,15 @@ enum {
  *  ├─ 110100 ─ OPC_MXU_Q16SLL   ├─ 010 ─ OPC_MXU_D32SARV
  *  ├─ 110101 ─ OPC_MXU_Q16SLR   ├─ 011 ─ OPC_MXU_Q16SLLV
  *  │├─ 100 ─ OPC_MXU_Q16SLRV
- *  ├─ 110110 ─ OPC_MXU__POOL17 ─┴─ 101 ─ OPC_MXU_Q16SARV
+ *  ├─ 110110 ─ OPC_MXU__POOL18 ─┴─ 101 ─ OPC_MXU_Q16SARV
  *  │
  *  ├─ 110111 ─ OPC_MXU_Q16SAR
  *  │   23..22
- *  ├─ 111000 ─ OPC_MXU__POOL18 ─┬─ 00 ─ OPC_MXU_Q8MUL
+ *  ├─ 111000 ─ OPC_MXU__POOL19 ─┬─ 00 ─ OPC_MXU_Q8MUL
  *  │└─ 01 ─ OPC_MXU_Q8MULSU
  *  │
  *  │   20..18
- *  ├─ 111001 ─ OPC_MXU__POOL19 ─┬─ 000 ─ OPC_MXU_Q8MOVZ
+ *  ├─ 111001 ─ OPC_MXU__POOL20 ─┬─ 000 ─ OPC_MXU_Q8MOVZ
  *  │├─ 001 ─ OPC_MXU_Q8MOVN
  *  │├─ 010 ─ OPC_MXU_D16MOVZ
  *  │├─ 011 ─ OPC_MXU_D16MOVN
@@ -1694,7 +1703,7 @@ enum {
  *  │└─ 101 ─ OPC_MXU_S32MOV
  *  │
  *  │   23..22
- *  ├─ 111010 ─ OPC_MXU__POOL20 ─┬─ 00 ─ OPC_MXU_Q8MAC
+ *  ├─ 111010 ─ OPC_MXU__POOL21 ─┬─ 00 ─ OPC_MXU_Q8MAC
  *  │└─ 10 ─ OPC_MXU_Q8MACSU
  *  ├─ 111011 ─ OPC_MXU_Q16SCOP
  *  ├─ 00 ─ OPC_MXU_Q8MADL
@@ -1750,7 +1759,7 @@ enum {
 OPC_MXU_S8SDI= 0x25,
 OPC_MXU__POOL15  = 0x26,
 OPC_MXU__POOL16  = 0x27,
-OPC_MXU_LXB  = 0x28,
+OPC_MXU__POOL17  = 0x28,
 /* not assigned 0x29 */
 OPC_MXU_S16LDD   = 0x2A,
 OPC_MXU_S16STD   = 0x2B,
@@ -1764,11 +1773,11 @@ enum {
 OPC_MXU_D32SAR   = 0x33,
 OPC_MXU_Q16SLL   = 0x34,
 OPC_MXU_Q16SLR   = 0x35,
-OPC_MXU__POOL17  = 0x36,
+OPC_MXU__POOL18  = 0x36,
 OPC_MXU_Q16SAR   = 0x37,
-OPC_MXU__POOL18  = 0x38,
-OPC_MXU__POOL19  = 0x39,
-OPC_MXU__POOL20  = 0x3A,
+OPC_MXU__POOL19  = 0x38,
+OPC_MXU__POOL20  = 0x39,
+OPC_MXU__POOL21  = 0x3A,
 OPC_MXU_Q16SCOP  = 0x3B,
 OPC_MXU_Q8MADL   = 0x3C,
 OPC_MXU_S32SFL   = 0x3D,
@@ -1941,6 +1950,17 @@ enum {
  * MXU pool 17
  */
 enum {
+OPC_MXU_LXB  = 0x00,
+OPC_MXU_LXH  = 0x01,
+OPC_MXU_LXW  = 0x03,
+OPC_MXU_LXBU = 0x04,
+OPC_MXU_LXHU = 0x05,
+};
+
+/*
+ * MXU pool 18
+ */
+enum {
 OPC_MXU_D32SLLV  = 0x00,
 OPC_MXU_D32SLRV  = 0x01,
 OPC_MXU_D32SARV  = 0x03,
@@ -1950,7 +1970,7 @@ enum {
 };
 
 /*
- * MXU pool 18
+ * MXU pool 19
  */
 enum {
 OPC_MXU_Q8MUL= 0x00,
@@ -1958,7 +1978,7 @@ enum {
 };
 
 /*
- * MXU pool 19
+ * MXU pool 20
  */
 enum {
 OPC_MXU_Q8MOVZ   = 0x00,
@@ -1970,7 +1990,7 @@ enu

[Qemu-devel] [PULL 13/41] disas: nanoMIPS: Remove functions that are not used

[Aleksandar Markovic]

From: Aleksandar Markovic 

Some functions were not used at all. Compiler doesn't complain
since they are class memebers. Remove them - no future usage is
planned.

Reviewed-by: Aleksandar Rikalo 
Reviewed-by: Stefan Markovic 
Signed-off-by: Aleksandar Markovic 
---
 disas/nanomips.cpp | 208 -
 disas/nanomips.h   |  25 ---
 2 files changed, 233 deletions(-)

diff --git a/disas/nanomips.cpp b/disas/nanomips.cpp
index e082a3f..4784530 100644
--- a/disas/nanomips.cpp
+++ b/disas/nanomips.cpp
@@ -856,23 +856,6 @@ uint64 NMD::extract_stripe_6(uint64 instruction)
 }
 
 
-uint64 NMD::extr_xil17il0bs1Fmsb0(uint64 instruction)
-{
-uint64 value = 0;
-value |= extract_bits(instruction, 17, 1);
-return value;
-}
-
-
-uint64 NMD::extr_xil2il0bs1_il15il0bs1Fmsb0(uint64 instruction)
-{
-uint64 value = 0;
-value |= extract_bits(instruction, 2, 1);
-value |= extract_bits(instruction, 15, 1);
-return value;
-}
-
-
 uint64 NMD::extract_ac_13_12(uint64 instruction)
 {
 uint64 value = 0;
@@ -923,14 +906,6 @@ uint64 NMD::extract_shift_5_4_3_2_1_0(uint64 instruction)
 }
 
 
-uint64 NMD::extr_xil10il0bs6Fmsb5(uint64 instruction)
-{
-uint64 value = 0;
-value |= extract_bits(instruction, 10, 6);
-return value;
-}
-
-
 uint64 NMD::extract_count_19_18_17_16(uint64 instruction)
 {
 uint64 value = 0;
@@ -947,15 +922,6 @@ uint64 NMD::extract_code_2_1_0(uint64 instruction)
 }
 
 
-uint64 NMD::extr_xil10il0bs4_il22il0bs4Fmsb3(uint64 instruction)
-{
-uint64 value = 0;
-value |= extract_bits(instruction, 10, 4);
-value |= extract_bits(instruction, 22, 4);
-return value;
-}
-
-
 uint64 NMD::extract_u_11_10_9_8_7_6_5_4_3_2_1_0(uint64 instruction)
 {
 uint64 value = 0;
@@ -980,14 +946,6 @@ uint64 NMD::extr_uil3il3bs18Fmsb20(uint64 instruction)
 }
 
 
-uint64 NMD::extr_xil12il0bs1Fmsb0(uint64 instruction)
-{
-uint64 value = 0;
-value |= extract_bits(instruction, 12, 1);
-return value;
-}
-
-
 uint64 NMD::extr_uil0il2bs4Fmsb5(uint64 instruction)
 {
 uint64 value = 0;
@@ -1012,14 +970,6 @@ uint64 NMD::extr_uil0il2bs3Fmsb4(uint64 instruction)
 }
 
 
-uint64 NMD::extr_xil10il0bs1Fmsb0(uint64 instruction)
-{
-uint64 value = 0;
-value |= extract_bits(instruction, 10, 1);
-return value;
-}
-
-
 uint64 NMD::extract_rd3_3_2_1(uint64 instruction)
 {
 uint64 value = 0;
@@ -1052,22 +1002,6 @@ uint64 NMD::extract_ru_7_6_5_4_3(uint64 instruction)
 }
 
 
-uint64 NMD::extr_xil21il0bs5Fmsb4(uint64 instruction)
-{
-uint64 value = 0;
-value |= extract_bits(instruction, 21, 5);
-return value;
-}
-
-
-uint64 NMD::extr_xil9il0bs3Fmsb2(uint64 instruction)
-{
-uint64 value = 0;
-value |= extract_bits(instruction, 9, 3);
-return value;
-}
-
-
 uint64 NMD::extract_u_17_to_0(uint64 instruction)
 {
 uint64 value = 0;
@@ -1076,15 +1010,6 @@ uint64 NMD::extract_u_17_to_0(uint64 instruction)
 }
 
 
-uint64 NMD::extr_xil14il0bs1_il15il0bs1Fmsb0(uint64 instruction)
-{
-uint64 value = 0;
-value |= extract_bits(instruction, 14, 1);
-value |= extract_bits(instruction, 15, 1);
-return value;
-}
-
-
 uint64 NMD::extract_rsz4_4_2_1_0(uint64 instruction)
 {
 uint64 value = 0;
@@ -1094,14 +1019,6 @@ uint64 NMD::extract_rsz4_4_2_1_0(uint64 instruction)
 }
 
 
-uint64 NMD::extr_xil24il0bs1Fmsb0(uint64 instruction)
-{
-uint64 value = 0;
-value |= extract_bits(instruction, 24, 1);
-return value;
-}
-
-
 int64 NMD::extr_sil0il21bs1_il1il1bs20Tmsb21(uint64 instruction)
 {
 int64 value = 0;
@@ -1154,15 +1071,6 @@ int64 NMD::extract_shift_21_20_19_18_17_16(uint64 
instruction)
 }
 
 
-uint64 NMD::extr_xil6il0bs3_il10il0bs1Fmsb2(uint64 instruction)
-{
-uint64 value = 0;
-value |= extract_bits(instruction, 6, 3);
-value |= extract_bits(instruction, 10, 1);
-return value;
-}
-
-
 uint64 NMD::extract_rd2_3_8(uint64 instruction)
 {
 uint64 value = 0;
@@ -1172,14 +1080,6 @@ uint64 NMD::extract_rd2_3_8(uint64 instruction)
 }
 
 
-uint64 NMD::extr_xil16il0bs5Fmsb4(uint64 instruction)
-{
-uint64 value = 0;
-value |= extract_bits(instruction, 16, 5);
-return value;
-}
-
-
 uint64 NMD::extract_code_17_to_0(uint64 instruction)
 {
 uint64 value = 0;
@@ -1188,14 +1088,6 @@ uint64 NMD::extract_code_17_to_0(uint64 instruction)
 }
 
 
-uint64 NMD::extr_xil0il0bs12Fmsb11(uint64 instruction)
-{
-uint64 value = 0;
-value |= extract_bits(instruction, 0, 12);
-return value;
-}
-
-
 uint64 NMD::extract_size_20_19_18_17_16(uint64 instruction)
 {
 uint64 value = 0;
@@ -1264,15 +1156,6 @@ uint64 NMD::extract_hs_20_19_18_17_16(uint64 instruction)
 }
 
 
-uint64 NMD::extr_xil10il0bs1_il14il0bs2Fmsb1(uint64 instruction)
-{
-uint64 value = 0;
-value |= extract_bits(instruction, 10, 1);
-value |= extract_bits(instruction, 14, 2);
-return value;
-}
-
-
 uint64 NMD::extract_sel_13_12_11(uint64 instruction)
 {
 uint64 value = 0;
@@ -1289,1

[Qemu-devel] [PULL 01/41] MAINTAINERS: target/mips: Add MIPS files under default-configs directory

[Aleksandar Markovic]

From: Aleksandar Markovic 

Add following files as maintained within the main MIPS target
section in MAINTAINERS:

default-configs/mips64el-linux-user.mak
default-configs/mips64-linux-user.mak
default-configs/mipsn32el-linux-user.mak
default-configs/mipsn32-linux-user.mak
default-configs/mipsel-linux-user.mak
default-configs/mips-linux-user.mak
default-configs/mips64el-softmmu.mak
default-configs/mips64-softmmu.mak
default-configs/mipsel-softmmu.mak
default-configs/mips-softmmu.mak
default-configs/mips-softmmu-common.mak

Future nanoMIPS user mode will also have its .mak file, and
because of that "*mips*" was used instead of "mips*" as a
shorthand in the new item in MAINTAINERS.

Reviewed-by: Philippe Mathieu-Daudé 
Signed-off-by: Aleksandar Markovic 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 180695f..374e4c2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -208,6 +208,7 @@ M: Aleksandar Markovic 
 R: Stefan Markovic 
 S: Maintained
 F: target/mips/
+F: default-configs/*mips*
 F: hw/mips/
 F: hw/misc/mips_*
 F: hw/intc/mips_gic.c
-- 
2.7.4

[Qemu-devel] [PULL 25/41] disas: nanoMIPS: Comment the decoder of 'gpr3.src.store' gpr encoding type

[Aleksandar Markovic]

From: Aleksandar Markovic 

Comment the decoder of 'gpr3.src.store' gpr encoding type in nanoMIPS
disassembler.

Reviewed-by: Aleksandar Rikalo 
Signed-off-by: Aleksandar Markovic 
---
 disas/nanomips.cpp | 32 
 1 file changed, 32 insertions(+)

diff --git a/disas/nanomips.cpp b/disas/nanomips.cpp
index 7c56162..1c313f3 100644
--- a/disas/nanomips.cpp
+++ b/disas/nanomips.cpp
@@ -349,6 +349,38 @@ uint64 NMD::decode_gpr_gpr3(uint64 d)
 }
 
 
+/*
+ * NMD::decode_gpr_gpr3_src_store() - decoder for 'gpr3.src.store' gpr encoding
+ * type
+ *
+ *   Map a 3-bit code to the 5-bit register space according to this pattern:
+ *
+ *7 6 5 4 3 2 1 0
+ *| | | | | | | |
+ *| | | | | | | └---┐
+ *| | | └---┐   |
+ *| | └---┐ |   |
+ *| └---┐ | |   |
+ *└---┐ | | |   |
+ *| | |   | | | |   |
+ *┌---┘ | |   | | | |   |
+ *| ┌---┘ |   | | | |   |
+ *| | ┌---┘   | | | |   |
+ *| | |   | | | |   |
+ *| | |   | | | |   |
+ *1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+ *  3   2   1   0
+ *
+ *   This pattern is the same one used for 'gpr3' gpr encoding type, except for
+ * the input value 0, that is mapped to the output value 0 instead of 16.
+ *
+ *   Used in handling following instructions:
+ *
+ * - SB[16]
+ * - SH[16]
+ * - SW[16]
+ * - SW[GP16]
+ */
 uint64 NMD::decode_gpr_gpr3_src_store(uint64 d)
 {
 static uint64 register_list[] = {  0, 17, 18, 19,  4,  5,  6,  7 };
-- 
2.7.4

[Qemu-devel] [PULL 04/41] MAINTAINERS: Add Aleksandar Rikalo as a reviewer for MIPS content

[Aleksandar Markovic]

From: Aleksandar Markovic 

Add Aleksandar Rikalo as a reviewer for MIPS content. Aleksandar
brings to us more than six years of experience in working on a variety
of development tools for MIPS architectures, and will greatly help
QEMU community understand and support intricacies of MIPS better.

Acked-by: Aleksandar Rikalo 
Reviewed-by: Aleksandar Rikalo 
Signed-off-by: Aleksandar Markovic 
---
 MAINTAINERS | 9 +
 1 file changed, 9 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 39fb1ae..b06f534 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -205,6 +205,7 @@ F: disas/microblaze.c
 MIPS
 M: Aurelien Jarno 
 M: Aleksandar Markovic 
+R: Aleksandar Rikalo 
 R: Stefan Markovic 
 S: Maintained
 F: target/mips/
@@ -362,6 +363,7 @@ F: target/arm/kvm.c
 
 MIPS
 M: James Hogan 
+R: Aleksandar Rikalo 
 R: Stefan Markovic 
 S: Maintained
 F: target/mips/kvm.c
@@ -871,6 +873,7 @@ MIPS Machines
 -
 Jazz
 M: Hervé Poussineau 
+R: Aleksandar Rikalo 
 R: Stefan Markovic 
 S: Maintained
 F: hw/mips/mips_jazz.c
@@ -879,12 +882,14 @@ F: hw/dma/rc4030.c
 
 Malta
 M: Aurelien Jarno 
+R: Aleksandar Rikalo 
 R: Stefan Markovic 
 S: Maintained
 F: hw/mips/mips_malta.c
 
 Mipssim
 M: Aleksandar Markovic 
+R: Aleksandar Rikalo 
 R: Stefan Markovic 
 S: Odd Fixes
 F: hw/mips/mips_mipssim.c
@@ -892,12 +897,14 @@ F: hw/net/mipsnet.c
 
 R4000
 M: Aurelien Jarno 
+R: Aleksandar Rikalo 
 R: Stefan Markovic 
 S: Maintained
 F: hw/mips/mips_r4k.c
 
 Fulong 2E
 M: Aleksandar Markovic 
+R: Aleksandar Rikalo 
 R: Stefan Markovic 
 S: Odd Fixes
 F: hw/mips/mips_fulong2e.c
@@ -907,6 +914,7 @@ F: include/hw/isa/vt82c686.h
 
 Boston
 M: Paul Burton 
+R: Aleksandar Rikalo 
 R: Stefan Markovic 
 S: Maintained
 F: hw/core/loader-fit.c
@@ -2163,6 +2171,7 @@ F: disas/i386.c
 
 MIPS target
 M: Aurelien Jarno 
+R: Aleksandar Rikalo 
 R: Stefan Markovic 
 S: Maintained
 F: tcg/mips/
-- 
2.7.4

[Qemu-devel] [PULL 23/41] disas: nanoMIPS: Comment the decoder of 'gpr3' gpr encoding type

[Aleksandar Markovic]

From: Aleksandar Markovic 

Comment the decoder of 'gpr3' gpr encoding type in nanoMIPS
disassembler.

Reviewed-by: Aleksandar Rikalo 
Signed-off-by: Aleksandar Markovic 
---
 disas/nanomips.cpp | 51 ---
 1 file changed, 48 insertions(+), 3 deletions(-)

diff --git a/disas/nanomips.cpp b/disas/nanomips.cpp
index 2856645..30988f8 100644
--- a/disas/nanomips.cpp
+++ b/disas/nanomips.cpp
@@ -292,9 +292,54 @@ uint64 NMD::renumber_registers(uint64 index, uint64 
*register_list,
 
 
 /*
- * these functions should be decode functions but the json does not have
- * decode sections so they are based on the encode, the equivalent decode
- * functions need writing eventually.
+ * NMD::decode_gpr_gpr3() - decoder for 'gpr3' gpr encoding type
+ *
+ *   Map a 3-bit code to the 5-bit register space according to this pattern:
+ *
+ *7 6 5 4 3 2 1 0
+ *| | | | | | | |
+ *| | | | | | | |
+ *| | | └---┐
+ *| | └---┐ |
+ *| └---┐ | |
+ *└---┐ | | |
+ *| | | | | | | |
+ *┌---┘ | | | | | | |
+ *| ┌---┘ | | | | | |
+ *| | ┌---┘ | | | | |
+ *| | | ┌---┘ | | | |
+ *| | | | | | | |
+ *1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+ *  3   2   1   0
+ *
+ *   Used in handling following instructions:
+ *
+ * - ADDIU[R1.SP]
+ * - ADDIU[R2]
+ * - ADDU[16]
+ * - AND[16]
+ * - ANDI[16]
+ * - BEQC[16]
+ * - BEQZC[16]
+ * - BNEC[16]
+ * - BNEZC[16]
+ * - LB[16]
+ * - LBU[16]
+ * - LH[16]
+ * - LHU[16]
+ * - LI[16]
+ * - LW[16]
+ * - LW[GP16]
+ * - LWXS[16]
+ * - NOT[16]
+ * - OR[16]
+ * - SB[16]
+ * - SH[16]
+ * - SLL[16]
+ * - SRL[16]
+ * - SUBU[16]
+ * - SW[16]
+ * - XOR[16]
  */
 uint64 NMD::decode_gpr_gpr3(uint64 d)
 {
-- 
2.7.4

[Qemu-devel] [PULL 00/41] MIPS pull request for December 2018

[Aleksandar Markovic]

From: Aleksandar Markovic 

The following changes since commit 9b2e891ec5ccdb4a7d583b77988848282606fdea:

  Merge remote-tracking branch 'remotes/marcel/tags/rdma-pull-request' into 
staging (2018-12-22 11:25:31 +)

are available in the git repository at:

  https://github.com/AMarkovic/qemu tags/mips-queue-december-2018

for you to fetch changes up to fc10cf1fa2ade8f314f6b3600844d2f3c41830bf:

  tests/tcg: mips: Test R5900 three-operand MADDU1 (2018-12-27 21:31:44 +0100)


MIPS queue for December 2018

  - this queue contains various amendments to MIPS code
  - there are three checkpatch warnings that should be ingnored
in given circumstances
  - most of the patches are not yet visible/noticeable to the end
user, just a single note related to Paul's patch will be added
to ChangeLog



Aleksandar Markovic (33):
  MAINTAINERS: target/mips: Add MIPS files under default-configs
directory
  MAINTAINERS: target/mips: Add filter for mips in email subjects
  MAINTAINERS: target/mips: Reorder items alphabetically
  MAINTAINERS: Add Aleksandar Rikalo as a reviewer for MIPS content
  target/mips: MXU: Add missing opcodes/decoding for LX* instructions
  target/mips: MXU: Add generic naming for optn2 constants
  target/mips: MXU: Improve the comment containing MXU overview
  disas: nanoMIPS: Fix preamble text in nanomips.* files
  disas: nanoMIPS: Remove functions that are not used
  disas: nanoMIPS: Fix a function misnomer
  disas: nanoMIPS: Fix order of some invocations
  disas: nanoMIPS: Name some functions in a more descriptive way
  disas: nanoMIPS: Fix an FP-related misnomer 1
  disas: nanoMIPS: Fix an FP-related misnomer 2
  disas: nanoMIPS: Fix an FP-related misnomer 3
  disas: nanoMIPS: Name more functions in a more descriptive way
  disas: nanoMIPS: Fix order of more invocations
  disas: nanoMIPS: Rename the decoder of 'gpr3' gpr encoding type
  disas: nanoMIPS: Comment the decoder of 'gpr3' gpr encoding type
  disas: nanoMIPS: Rename the decoder of 'gpr3.src.store' gpr encoding
type
  disas: nanoMIPS: Comment the decoder of 'gpr3.src.store' gpr encoding
type
  disas: nanoMIPS: Rename the decoder of 'gpr4' gpr encoding type
  disas: nanoMIPS: Comment the decoder of 'gpr4' gpr encoding type
  disas: nanoMIPS: Rename the decoder of 'gpr4.zero' gpr encoding type
  disas: nanoMIPS: Comment the decoder of 'gpr4.zero' gpr encoding type
  disas: nanoMIPS: Rename the decoder of 'gpr2.reg1' gpr encoding type
  disas: nanoMIPS: Comment the decoder of 'gpr2.reg1' gpr encoding type
  disas: nanoMIPS: Rename the decoder of 'gpr2.reg2' gpr encoding type
  disas: nanoMIPS: Comment the decoder of 'gpr2.reg2' gpr encoding type
  disas: nanoMIPS: Rename the decoder of 'gpr1' gpr encoding type
  disas: nanoMIPS: Comment the decoder of 'gpr1' gpr encoding type
  disas: nanoMIPS: Reorder declarations and definitions of gpr decoders
  disas: nanoMIPS: Add a note on documentation

Fredrik Noring (5):
  target/mips: Support R5900 three-operand MADD1 and MADDU1 instructions
  tests/tcg: mips: Test R5900 three-operand MADD
  tests/tcg: mips: Test R5900 three-operand MADD1
  tests/tcg: mips: Test R5900 three-operand MADDU
  tests/tcg: mips: Test R5900 three-operand MADDU1

Paul Burton (1):
  atomics: Set ATOMIC_REG_SIZE=8 for MIPS n32

Philippe Mathieu-Daudé (1):
  target/mips: Support R5900 three-operand MADD and MADDU instructions

Stefan Weil (1):
  disas: nanoMIPS: Fix types and format strings

 MAINTAINERS   |   21 +-
 disas/nanomips.cpp| 2155 ++---
 disas/nanomips.h  |  125 +--
 include/qemu/atomic.h |5 +-
 target/mips/translate.c   |  287 +++--
 tests/tcg/mips/mipsr5900/Makefile |2 +
 tests/tcg/mips/mipsr5900/madd.c   |   78 ++
 tests/tcg/mips/mipsr5900/maddu.c  |   70 ++
 8 files changed, 1509 insertions(+), 1234 deletions(-)
 create mode 100644 tests/tcg/mips/mipsr5900/madd.c
 create mode 100644 tests/tcg/mips/mipsr5900/maddu.c

-- 
2.7.4

[Qemu-devel] [PULL 12/41] disas: nanoMIPS: Fix preamble text in nanomips.* files

[Aleksandar Markovic]

From: Aleksandar Markovic 

Fix several mistakes in preambles of nanomips disassembler source
files.

Reviewed-by: Aleksandar Rikalo 
Reviewed-by: Stefan Markovic 
Signed-off-by: Aleksandar Markovic 
---
 disas/nanomips.cpp | 7 ---
 disas/nanomips.h   | 7 ---
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/disas/nanomips.cpp b/disas/nanomips.cpp
index 28d78d6..e082a3f 100644
--- a/disas/nanomips.cpp
+++ b/disas/nanomips.cpp
@@ -1,13 +1,13 @@
 /*
  *  Source file for nanoMIPS disassembler component of QEMU
  *
- *  Copyright (C) 2018  Wave Computing
+ *  Copyright (C) 2018  Wave Computing, Inc.
  *  Copyright (C) 2018  Matthew Fortune 
- *  Copyright (C) 2018  Aleksandar Markovic 
+ *  Copyright (C) 2018  Aleksandar Markovic 
  *
  *  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 3 of the License, or
+ *  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,
@@ -17,6 +17,7 @@
  *
  *  You should have received a copy of the GNU General Public License
  *  along with this program.  If not, see .
+ *
  */
 
 extern "C" {
diff --git a/disas/nanomips.h b/disas/nanomips.h
index 71428b3..c7477c2 100644
--- a/disas/nanomips.h
+++ b/disas/nanomips.h
@@ -1,13 +1,13 @@
 /*
  *  Header file for nanoMIPS disassembler component of QEMU
  *
- *  Copyright (C) 2018  Wave Computing
+ *  Copyright (C) 2018  Wave Computing, Inc.
  *  Copyright (C) 2018  Matthew Fortune 
- *  Copyright (C) 2018  Aleksandar Markovic 
+ *  Copyright (C) 2018  Aleksandar Markovic 
  *
  *  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 3 of the License, or
+ *  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,
@@ -17,6 +17,7 @@
  *
  *  You should have received a copy of the GNU General Public License
  *  along with this program.  If not, see .
+ *
  */
 
 #ifndef NANOMIPS_DISASSEMBLER_H
-- 
2.7.4

[Qemu-devel] [PULL 26/41] disas: nanoMIPS: Rename the decoder of 'gpr4' gpr encoding type

[Aleksandar Markovic]

From: Aleksandar Markovic 

Rename the decoder of 'gpr4' gpr encoding type in nanoMIPS
disassembler.

Reviewed-by: Aleksandar Rikalo 
Signed-off-by: Aleksandar Markovic 
---
 disas/nanomips.cpp | 20 ++--
 disas/nanomips.h   |  2 +-
 2 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/disas/nanomips.cpp b/disas/nanomips.cpp
index 1c313f3..5f6c93c 100644
--- a/disas/nanomips.cpp
+++ b/disas/nanomips.cpp
@@ -406,7 +406,7 @@ uint64 NMD::encode_gpr4_zero(uint64 d)
 }
 
 
-uint64 NMD::encode_gpr4(uint64 d)
+uint64 NMD::decode_gpr_gpr4(uint64 d)
 {
 static uint64 register_list[] = {  8,  9, 10, 11,  4,  5,  6,  7,
   16, 17, 18, 19, 20, 21, 22, 23 };
@@ -2363,8 +2363,8 @@ std::string NMD::ADDU_4X4_(uint64 instruction)
 uint64 rt4_value = extract_rt4_9_7_6_5(instruction);
 uint64 rs4_value = extract_rs4_4_2_1_0(instruction);
 
-std::string rs4 = GPR(encode_gpr4(rs4_value));
-std::string rt4 = GPR(encode_gpr4(rt4_value));
+std::string rs4 = GPR(decode_gpr_gpr4(rs4_value));
+std::string rt4 = GPR(decode_gpr_gpr4(rt4_value));
 
 return img::format("ADDU %s, %s", rs4, rt4);
 }
@@ -9046,9 +9046,9 @@ std::string NMD::LW_4X4_(uint64 instruction)
 uint64 rs4_value = extract_rs4_4_2_1_0(instruction);
 uint64 u_value = extract_u_3_8__s2(instruction);
 
-std::string rt4 = GPR(encode_gpr4(rt4_value));
+std::string rt4 = GPR(decode_gpr_gpr4(rt4_value));
 std::string u = IMMEDIATE(copy(u_value));
-std::string rs4 = GPR(encode_gpr4(rs4_value));
+std::string rs4 = GPR(decode_gpr_gpr4(rs4_value));
 
 return img::format("LW %s, %s(%s)", rt4, u, rs4);
 }
@@ -10419,8 +10419,8 @@ std::string NMD::MOVEP_REV_(uint64 instruction)
 uint64 rd2_value = extract_rd2_3_8(instruction);
 uint64 rs4_value = extract_rs4_4_2_1_0(instruction);
 
-std::string rs4 = GPR(encode_gpr4(rs4_value));
-std::string rt4 = GPR(encode_gpr4(rt4_value));
+std::string rs4 = GPR(decode_gpr_gpr4(rs4_value));
+std::string rt4 = GPR(decode_gpr_gpr4(rt4_value));
 std::string rd2 = GPR(encode_rd2_reg1(rd2_value));
 std::string rs2 = GPR(encode_rd2_reg2(rd2_value));
 /* !! - no conversion function */
@@ -10985,8 +10985,8 @@ std::string NMD::MUL_4X4_(uint64 instruction)
 uint64 rt4_value = extract_rt4_9_7_6_5(instruction);
 uint64 rs4_value = extract_rs4_4_2_1_0(instruction);
 
-std::string rs4 = GPR(encode_gpr4(rs4_value));
-std::string rt4 = GPR(encode_gpr4(rt4_value));
+std::string rs4 = GPR(decode_gpr_gpr4(rs4_value));
+std::string rt4 = GPR(decode_gpr_gpr4(rt4_value));
 
 return img::format("MUL %s, %s", rs4, rt4);
 }
@@ -15264,7 +15264,7 @@ std::string NMD::SW_4X4_(uint64 instruction)
 
 std::string rtz4 = GPR(encode_gpr4_zero(rtz4_value));
 std::string u = IMMEDIATE(copy(u_value));
-std::string rs4 = GPR(encode_gpr4(rs4_value));
+std::string rs4 = GPR(decode_gpr_gpr4(rs4_value));
 
 return img::format("SW %s, %s(%s)", rtz4, u, rs4);
 }
diff --git a/disas/nanomips.h b/disas/nanomips.h
index 757915c..109b131 100644
--- a/disas/nanomips.h
+++ b/disas/nanomips.h
@@ -109,7 +109,7 @@ private:
 uint64 decode_gpr_gpr3_src_store(uint64 d);
 uint64 encode_rd1_from_rd(uint64 d);
 uint64 encode_gpr4_zero(uint64 d);
-uint64 encode_gpr4(uint64 d);
+uint64 decode_gpr_gpr4(uint64 d);
 uint64 encode_rd2_reg1(uint64 d);
 uint64 encode_rd2_reg2(uint64 d);
 
-- 
2.7.4

[Qemu-devel] [PULL 38/41] tests/tcg: mips: Test R5900 three-operand MADD

[Aleksandar Markovic]

From: Fredrik Noring 

Test R5900 three-operand MADD.

Reviewed-by: Aleksandar Markovic 
Signed-off-by: Aleksandar Markovic 
Signed-off-by: Fredrik Noring 
---
 tests/tcg/mips/mipsr5900/Makefile |  1 +
 tests/tcg/mips/mipsr5900/madd.c   | 45 +++
 2 files changed, 46 insertions(+)
 create mode 100644 tests/tcg/mips/mipsr5900/madd.c

diff --git a/tests/tcg/mips/mipsr5900/Makefile 
b/tests/tcg/mips/mipsr5900/Makefile
index a1c388b..97ca2a6 100644
--- a/tests/tcg/mips/mipsr5900/Makefile
+++ b/tests/tcg/mips/mipsr5900/Makefile
@@ -10,6 +10,7 @@ CFLAGS  = -Wall -mabi=32 -march=r5900 -static
 
 TESTCASES = div1.tst
 TESTCASES += divu1.tst
+TESTCASES += madd.tst
 TESTCASES += mflohi1.tst
 TESTCASES += mtlohi1.tst
 TESTCASES += mult.tst
diff --git a/tests/tcg/mips/mipsr5900/madd.c b/tests/tcg/mips/mipsr5900/madd.c
new file mode 100644
index 000..9ad2ea6
--- /dev/null
+++ b/tests/tcg/mips/mipsr5900/madd.c
@@ -0,0 +1,45 @@
+/*
+ * Test R5900-specific three-operand MADD.
+ */
+
+#include 
+#include 
+#include 
+
+int64_t madd(int64_t a, int32_t rs, int32_t rt)
+{
+int32_t lo = a;
+int32_t hi = a >> 32;
+int32_t rd;
+int64_t r;
+
+__asm__ __volatile__ (
+"mtlo %5\n"
+"mthi %6\n"
+"madd %0, %3, %4\n"
+"mflo %1\n"
+"mfhi %2\n"
+: "=r" (rd), "=r" (lo), "=r" (hi)
+: "r" (rs), "r" (rt), "r" (lo), "r" (hi));
+r = ((int64_t)hi << 32) | (uint32_t)lo;
+
+assert(a + (int64_t)rs * rt == r);
+assert(rd == lo);
+
+return r;
+}
+
+static void verify_madd(int64_t a, int32_t rs, int32_t rt, int64_t expected)
+{
+assert(madd(a, rs, rt) == expected);
+assert(madd(a, -rs, rt) == a + a - expected);
+assert(madd(a, rs, -rt) == a + a - expected);
+assert(madd(a, -rs, -rt) == expected);
+}
+
+int main()
+{
+verify_madd(13, 17, 19, 336);
+
+return 0;
+}
-- 
2.7.4

[Qemu-devel] [PULL 14/41] disas: nanoMIPS: Fix a function misnomer

[Aleksandar Markovic]

From: Aleksandar Markovic 

Fix wrong function name. The convention in these files is that names of
extraction functions should reflect bit patterns they are extracting.

Reviewed-by: Aleksandar Rikalo 
Reviewed-by: Stefan Markovic 
Signed-off-by: Aleksandar Markovic 
---
 disas/nanomips.cpp | 264 ++---
 disas/nanomips.h   |   2 +-
 2 files changed, 133 insertions(+), 133 deletions(-)

diff --git a/disas/nanomips.cpp b/disas/nanomips.cpp
index 4784530..2abf18d 100644
--- a/disas/nanomips.cpp
+++ b/disas/nanomips.cpp
@@ -1395,7 +1395,7 @@ uint64 NMD::extr_uil2il2bs16Fmsb17(uint64 instruction)
 }
 
 
-uint64 NMD::extract_rd_20_19_18_17_16(uint64 instruction)
+uint64 NMD::extract_rd_15_14_13_12_11(uint64 instruction)
 {
 uint64 value = 0;
 value |= extract_bits(instruction, 11, 5);
@@ -1583,7 +1583,7 @@ bool NMD::PREFE_cond(uint64 instruction)
 
 bool NMD::SLTU_cond(uint64 instruction)
 {
-uint64 rd = extract_rd_20_19_18_17_16(instruction);
+uint64 rd = extract_rd_15_14_13_12_11(instruction);
 return rd != 0;
 }
 
@@ -1731,7 +1731,7 @@ std::string NMD::ACLR(uint64 instruction)
 std::string NMD::ADD(uint64 instruction)
 {
 uint64 rt_value = extract_rt_25_24_23_22_21(instruction);
-uint64 rd_value = extract_rd_20_19_18_17_16(instruction);
+uint64 rd_value = extract_rd_15_14_13_12_11(instruction);
 uint64 rs_value = extract_rs_20_19_18_17_16(instruction);
 
 std::string rd = GPR(copy(rd_value));
@@ -2043,7 +2043,7 @@ std::string NMD::ADDIUPC_48_(uint64 instruction)
 std::string NMD::ADDQ_PH(uint64 instruction)
 {
 uint64 rt_value = extract_rt_25_24_23_22_21(instruction);
-uint64 rd_value = extract_rd_20_19_18_17_16(instruction);
+uint64 rd_value = extract_rd_15_14_13_12_11(instruction);
 uint64 rs_value = extract_rs_20_19_18_17_16(instruction);
 
 std::string rd = GPR(copy(rd_value));
@@ -2067,7 +2067,7 @@ std::string NMD::ADDQ_PH(uint64 instruction)
 std::string NMD::ADDQ_S_PH(uint64 instruction)
 {
 uint64 rt_value = extract_rt_25_24_23_22_21(instruction);
-uint64 rd_value = extract_rd_20_19_18_17_16(instruction);
+uint64 rd_value = extract_rd_15_14_13_12_11(instruction);
 uint64 rs_value = extract_rs_20_19_18_17_16(instruction);
 
 std::string rd = GPR(copy(rd_value));
@@ -2091,7 +2091,7 @@ std::string NMD::ADDQ_S_PH(uint64 instruction)
 std::string NMD::ADDQ_S_W(uint64 instruction)
 {
 uint64 rt_value = extract_rt_25_24_23_22_21(instruction);
-uint64 rd_value = extract_rd_20_19_18_17_16(instruction);
+uint64 rd_value = extract_rd_15_14_13_12_11(instruction);
 uint64 rs_value = extract_rs_20_19_18_17_16(instruction);
 
 std::string rd = GPR(copy(rd_value));
@@ -2116,7 +2116,7 @@ std::string NMD::ADDQ_S_W(uint64 instruction)
 std::string NMD::ADDQH_PH(uint64 instruction)
 {
 uint64 rt_value = extract_rt_25_24_23_22_21(instruction);
-uint64 rd_value = extract_rd_20_19_18_17_16(instruction);
+uint64 rd_value = extract_rd_15_14_13_12_11(instruction);
 uint64 rs_value = extract_rs_20_19_18_17_16(instruction);
 
 std::string rd = GPR(copy(rd_value));
@@ -2141,7 +2141,7 @@ std::string NMD::ADDQH_PH(uint64 instruction)
 std::string NMD::ADDQH_R_PH(uint64 instruction)
 {
 uint64 rt_value = extract_rt_25_24_23_22_21(instruction);
-uint64 rd_value = extract_rd_20_19_18_17_16(instruction);
+uint64 rd_value = extract_rd_15_14_13_12_11(instruction);
 uint64 rs_value = extract_rs_20_19_18_17_16(instruction);
 
 std::string rd = GPR(copy(rd_value));
@@ -2165,7 +2165,7 @@ std::string NMD::ADDQH_R_PH(uint64 instruction)
 std::string NMD::ADDQH_R_W(uint64 instruction)
 {
 uint64 rt_value = extract_rt_25_24_23_22_21(instruction);
-uint64 rd_value = extract_rd_20_19_18_17_16(instruction);
+uint64 rd_value = extract_rd_15_14_13_12_11(instruction);
 uint64 rs_value = extract_rs_20_19_18_17_16(instruction);
 
 std::string rd = GPR(copy(rd_value));
@@ -2189,7 +2189,7 @@ std::string NMD::ADDQH_R_W(uint64 instruction)
 std::string NMD::ADDQH_W(uint64 instruction)
 {
 uint64 rt_value = extract_rt_25_24_23_22_21(instruction);
-uint64 rd_value = extract_rd_20_19_18_17_16(instruction);
+uint64 rd_value = extract_rd_15_14_13_12_11(instruction);
 uint64 rs_value = extract_rs_20_19_18_17_16(instruction);
 
 std::string rd = GPR(copy(rd_value));
@@ -2213,7 +2213,7 @@ std::string NMD::ADDQH_W(uint64 instruction)
 std::string NMD::ADDSC(uint64 instruction)
 {
 uint64 rt_value = extract_rt_25_24_23_22_21(instruction);
-uint64 rd_value = extract_rd_20_19_18_17_16(instruction);
+uint64 rd_value = extract_rd_15_14_13_12_11(instruction);
 uint64 rs_value = extract_rs_20_19_18_17_16(instruction);
 
 std::string rd = GPR(copy(rd_value));
@@ -2260,7 +2260,7 @@ std::string NMD::ADDU_16_(uint64 instruction)
 std::string NMD::ADDU_32_(uint64 instruction)
 {
 uint64 rt_value = extract_rt_25_24_23_22_21(instruc

[Qemu-devel] [PULL 28/41] disas: nanoMIPS: Rename the decoder of 'gpr4.zero' gpr encoding type

[Aleksandar Markovic]

From: Aleksandar Markovic 

Rename the decoder of 'gpr4.zero' gpr encoding type in nanoMIPS
disassembler.

Reviewed-by: Aleksandar Rikalo 
Signed-off-by: Aleksandar Markovic 
---
 disas/nanomips.cpp | 10 +-
 disas/nanomips.h   |  2 +-
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/disas/nanomips.cpp b/disas/nanomips.cpp
index a086f65..66b1223 100644
--- a/disas/nanomips.cpp
+++ b/disas/nanomips.cpp
@@ -397,7 +397,7 @@ uint64 NMD::encode_rd1_from_rd(uint64 d)
 }
 
 
-uint64 NMD::encode_gpr4_zero(uint64 d)
+uint64 NMD::decode_gpr_gpr4_zero(uint64 d)
 {
 static uint64 register_list[] = {  8,  9, 10,  0,  4,  5,  6,  7,
   16, 17, 18, 19, 20, 21, 22, 23 };
@@ -10395,7 +10395,7 @@ std::string NMD::MOVE_BALC(uint64 instruction)
 int64 s_value = extract_s__se21_0_20_to_1_s1(instruction);
 
 std::string rd1 = GPR(encode_rd1_from_rd(rd1_value));
-std::string rtz4 = GPR(encode_gpr4_zero(rtz4_value));
+std::string rtz4 = GPR(decode_gpr_gpr4_zero(rtz4_value));
 std::string s = ADDRESS(encode_s_from_address(s_value), 4);
 
 return img::format("MOVE.BALC %s, %s, %s", rd1, rtz4, s);
@@ -10421,8 +10421,8 @@ std::string NMD::MOVEP(uint64 instruction)
 std::string rd2 = GPR(encode_rd2_reg1(rd2_value));
 std::string re2 = GPR(encode_rd2_reg2(rd2_value));
 /* !! - no conversion function */
-std::string rsz4 = GPR(encode_gpr4_zero(rsz4_value));
-std::string rtz4 = GPR(encode_gpr4_zero(rtz4_value));
+std::string rsz4 = GPR(decode_gpr_gpr4_zero(rsz4_value));
+std::string rtz4 = GPR(decode_gpr_gpr4_zero(rtz4_value));
 
 return img::format("MOVEP %s, %s, %s, %s", rd2, re2, rsz4, rtz4);
 /* hand edited */
@@ -15288,7 +15288,7 @@ std::string NMD::SW_4X4_(uint64 instruction)
 uint64 rs4_value = extract_rs4_4_2_1_0(instruction);
 uint64 u_value = extract_u_3_8__s2(instruction);
 
-std::string rtz4 = GPR(encode_gpr4_zero(rtz4_value));
+std::string rtz4 = GPR(decode_gpr_gpr4_zero(rtz4_value));
 std::string u = IMMEDIATE(copy(u_value));
 std::string rs4 = GPR(decode_gpr_gpr4(rs4_value));
 
diff --git a/disas/nanomips.h b/disas/nanomips.h
index 109b131..c1d3a3b 100644
--- a/disas/nanomips.h
+++ b/disas/nanomips.h
@@ -108,7 +108,7 @@ private:
 uint64 decode_gpr_gpr3(uint64 d);
 uint64 decode_gpr_gpr3_src_store(uint64 d);
 uint64 encode_rd1_from_rd(uint64 d);
-uint64 encode_gpr4_zero(uint64 d);
+uint64 decode_gpr_gpr4_zero(uint64 d);
 uint64 decode_gpr_gpr4(uint64 d);
 uint64 encode_rd2_reg1(uint64 d);
 uint64 encode_rd2_reg2(uint64 d);
-- 
2.7.4

[Qemu-devel] [PULL 24/41] disas: nanoMIPS: Rename the decoder of 'gpr3.src.store' gpr encoding type

[Aleksandar Markovic]

From: Aleksandar Markovic 

Rename the decoder of 'gpr3.src.store' gpr encoding type in nanoMIPS
disassembler.

Reviewed-by: Aleksandar Rikalo 
Signed-off-by: Aleksandar Markovic 
---
 disas/nanomips.cpp | 10 +-
 disas/nanomips.h   |  2 +-
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/disas/nanomips.cpp b/disas/nanomips.cpp
index 30988f8..7c56162 100644
--- a/disas/nanomips.cpp
+++ b/disas/nanomips.cpp
@@ -349,7 +349,7 @@ uint64 NMD::decode_gpr_gpr3(uint64 d)
 }
 
 
-uint64 NMD::encode_gpr3_store(uint64 d)
+uint64 NMD::decode_gpr_gpr3_src_store(uint64 d)
 {
 static uint64 register_list[] = {  0, 17, 18, 19,  4,  5,  6,  7 };
 return renumber_registers(d, register_list,
@@ -12786,7 +12786,7 @@ std::string NMD::SB_16_(uint64 instruction)
 uint64 rs3_value = extract_rs3_6_5_4(instruction);
 uint64 u_value = extract_u_1_0(instruction);
 
-std::string rtz3 = GPR(encode_gpr3_store(rtz3_value));
+std::string rtz3 = GPR(decode_gpr_gpr3_src_store(rtz3_value));
 std::string u = IMMEDIATE(copy(u_value));
 std::string rs3 = GPR(decode_gpr_gpr3(rs3_value));
 
@@ -13632,7 +13632,7 @@ std::string NMD::SH_16_(uint64 instruction)
 uint64 rs3_value = extract_rs3_6_5_4(instruction);
 uint64 u_value = extract_u_2_1__s1(instruction);
 
-std::string rtz3 = GPR(encode_gpr3_store(rtz3_value));
+std::string rtz3 = GPR(decode_gpr_gpr3_src_store(rtz3_value));
 std::string u = IMMEDIATE(copy(u_value));
 std::string rs3 = GPR(decode_gpr_gpr3(rs3_value));
 
@@ -15206,7 +15206,7 @@ std::string NMD::SW_16_(uint64 instruction)
 uint64 rs3_value = extract_rs3_6_5_4(instruction);
 uint64 u_value = extract_u_3_2_1_0__s2(instruction);
 
-std::string rtz3 = GPR(encode_gpr3_store(rtz3_value));
+std::string rtz3 = GPR(decode_gpr_gpr3_src_store(rtz3_value));
 std::string u = IMMEDIATE(copy(u_value));
 std::string rs3 = GPR(decode_gpr_gpr3(rs3_value));
 
@@ -15253,7 +15253,7 @@ std::string NMD::SW_GP16_(uint64 instruction)
 uint64 u_value = extract_u_6_5_4_3_2_1_0__s2(instruction);
 uint64 rtz3_value = extract_rtz3_9_8_7(instruction);
 
-std::string rtz3 = GPR(encode_gpr3_store(rtz3_value));
+std::string rtz3 = GPR(decode_gpr_gpr3_src_store(rtz3_value));
 std::string u = IMMEDIATE(copy(u_value));
 
 return img::format("SW %s, %s($%d)", rtz3, u, 28);
diff --git a/disas/nanomips.h b/disas/nanomips.h
index 78f8f9b..757915c 100644
--- a/disas/nanomips.h
+++ b/disas/nanomips.h
@@ -106,7 +106,7 @@ private:
 uint64 renumber_registers(uint64 index, uint64 *register_list,
   size_t register_list_size);
 uint64 decode_gpr_gpr3(uint64 d);
-uint64 encode_gpr3_store(uint64 d);
+uint64 decode_gpr_gpr3_src_store(uint64 d);
 uint64 encode_rd1_from_rd(uint64 d);
 uint64 encode_gpr4_zero(uint64 d);
 uint64 encode_gpr4(uint64 d);
-- 
2.7.4

[Qemu-devel] [PULL 21/41] disas: nanoMIPS: Fix order of more invocations

[Aleksandar Markovic]

From: Aleksandar Markovic 

Fix order of extraction function invocations so that extraction
goes from MSB side to LSB side of the given instruction coding
content. This is desireable because of consistency and easier
visual spotting of errors.

After this patch, all such invocations should be in the desired
order.

Reviewed-by: Aleksandar Rikalo 
Signed-off-by: Aleksandar Markovic 
---
 disas/nanomips.cpp | 260 ++---
 1 file changed, 130 insertions(+), 130 deletions(-)

diff --git a/disas/nanomips.cpp b/disas/nanomips.cpp
index aa33434..e9018ea 100644
--- a/disas/nanomips.cpp
+++ b/disas/nanomips.cpp
@@ -1708,8 +1708,8 @@ std::string NMD::ABSQ_S_W(uint64 instruction)
 std::string NMD::ACLR(uint64 instruction)
 {
 uint64 bit_value = extract_bit_23_22_21(instruction);
-int64 s_value = extract_s__se8_15_7_6_5_4_3_2_1_0(instruction);
 uint64 rs_value = extract_rs_20_19_18_17_16(instruction);
+int64 s_value = extract_s__se8_15_7_6_5_4_3_2_1_0(instruction);
 
 std::string bit = IMMEDIATE(copy(bit_value));
 std::string s = IMMEDIATE(copy(s_value));
@@ -1954,9 +1954,9 @@ std::string NMD::ADDIU_R1_SP_(uint64 instruction)
  */
 std::string NMD::ADDIU_R2_(uint64 instruction)
 {
-uint64 u_value = extract_u_2_1_0__s2(instruction);
 uint64 rt3_value = extract_rt3_9_8_7(instruction);
 uint64 rs3_value = extract_rs3_6_5_4(instruction);
+uint64 u_value = extract_u_2_1_0__s2(instruction);
 
 std::string rt3 = GPR(encode_gpr3(rt3_value));
 std::string rs3 = GPR(encode_gpr3(rs3_value));
@@ -2613,8 +2613,8 @@ std::string NMD::APPEND(uint64 instruction)
 std::string NMD::ASET(uint64 instruction)
 {
 uint64 bit_value = extract_bit_23_22_21(instruction);
-int64 s_value = extract_s__se8_15_7_6_5_4_3_2_1_0(instruction);
 uint64 rs_value = extract_rs_20_19_18_17_16(instruction);
+int64 s_value = extract_s__se8_15_7_6_5_4_3_2_1_0(instruction);
 
 std::string bit = IMMEDIATE(copy(bit_value));
 std::string s = IMMEDIATE(copy(s_value));
@@ -2786,8 +2786,8 @@ std::string NMD::BC_32_(uint64 instruction)
  */
 std::string NMD::BC1EQZC(uint64 instruction)
 {
-int64 s_value = extract_s__se14_0_13_to_1_s1(instruction);
 uint64 ft_value = extract_ft_25_24_23_22_21(instruction);
+int64 s_value = extract_s__se14_0_13_to_1_s1(instruction);
 
 std::string ft = FPR(copy(ft_value));
 std::string s = ADDRESS(encode_s_from_address(s_value), 4);
@@ -2808,8 +2808,8 @@ std::string NMD::BC1EQZC(uint64 instruction)
  */
 std::string NMD::BC1NEZC(uint64 instruction)
 {
-int64 s_value = extract_s__se14_0_13_to_1_s1(instruction);
 uint64 ft_value = extract_ft_25_24_23_22_21(instruction);
+int64 s_value = extract_s__se14_0_13_to_1_s1(instruction);
 
 std::string ft = FPR(copy(ft_value));
 std::string s = ADDRESS(encode_s_from_address(s_value), 4);
@@ -2830,8 +2830,8 @@ std::string NMD::BC1NEZC(uint64 instruction)
  */
 std::string NMD::BC2EQZC(uint64 instruction)
 {
-int64 s_value = extract_s__se14_0_13_to_1_s1(instruction);
 uint64 ct_value = extract_ct_25_24_23_22_21(instruction);
+int64 s_value = extract_s__se14_0_13_to_1_s1(instruction);
 
 std::string ct = CPR(copy(ct_value));
 std::string s = ADDRESS(encode_s_from_address(s_value), 4);
@@ -2852,8 +2852,8 @@ std::string NMD::BC2EQZC(uint64 instruction)
  */
 std::string NMD::BC2NEZC(uint64 instruction)
 {
-int64 s_value = extract_s__se14_0_13_to_1_s1(instruction);
 uint64 ct_value = extract_ct_25_24_23_22_21(instruction);
+int64 s_value = extract_s__se14_0_13_to_1_s1(instruction);
 
 std::string ct = CPR(copy(ct_value));
 std::string s = ADDRESS(encode_s_from_address(s_value), 4);
@@ -2874,9 +2874,9 @@ std::string NMD::BC2NEZC(uint64 instruction)
  */
 std::string NMD::BEQC_16_(uint64 instruction)
 {
-uint64 u_value = extract_u_3_2_1_0__s1(instruction);
 uint64 rt3_value = extract_rt3_9_8_7(instruction);
 uint64 rs3_value = extract_rs3_6_5_4(instruction);
+uint64 u_value = extract_u_3_2_1_0__s1(instruction);
 
 std::string rs3 = GPR(encode_rs3_and_check_rs3_lt_rt3(rs3_value));
 std::string rt3 = GPR(encode_gpr3(rt3_value));
@@ -2899,8 +2899,8 @@ std::string NMD::BEQC_16_(uint64 instruction)
 std::string NMD::BEQC_32_(uint64 instruction)
 {
 uint64 rt_value = extract_rt_25_24_23_22_21(instruction);
-int64 s_value = extract_s__se14_0_13_to_1_s1(instruction);
 uint64 rs_value = extract_rs_20_19_18_17_16(instruction);
+int64 s_value = extract_s__se14_0_13_to_1_s1(instruction);
 
 std::string rs = GPR(copy(rs_value));
 std::string rt = GPR(copy(rt_value));
@@ -2923,8 +2923,8 @@ std::string NMD::BEQC_32_(uint64 instruction)
 std::string NMD::BEQIC(uint64 instruction)
 {
 uint64 rt_value = extract_rt_25_24_23_22_21(instruction);
-int64 s_value = extract_s__se11_0_10_9_8_7_6_5_4_3_2_1_0_s1(instruction);
 uint64 u_value = extract_u_17_16_15_14_13_12_11(instru

[Qemu-devel] [PULL 27/41] disas: nanoMIPS: Comment the decoder of 'gpr4' gpr encoding type

[Aleksandar Markovic]

From: Aleksandar Markovic 

Comment the decoder of 'gpr4' gpr encoding type in nanoMIPS
disassembler.

Reviewed-by: Aleksandar Rikalo 
Signed-off-by: Aleksandar Markovic 
---
 disas/nanomips.cpp | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/disas/nanomips.cpp b/disas/nanomips.cpp
index 5f6c93c..a086f65 100644
--- a/disas/nanomips.cpp
+++ b/disas/nanomips.cpp
@@ -406,6 +406,32 @@ uint64 NMD::encode_gpr4_zero(uint64 d)
 }
 
 
+/*
+ * NMD::decode_gpr_gpr4() - decoder for 'gpr4' gpr encoding type
+ *
+ *   Map a 4-bit code to the 5-bit register space according to this pattern:
+ *
+ *  1   0
+ *5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+ *| | | | | | | | | | | | | | | |
+ *| | | | | | | | | | | | | | | |
+ *| | | | | | | | | | | └---┐
+ *| | | | | | | | | | └---┐ |
+ *| | | | | | | | | └---┐ | |
+ *| | | | | | | | └---┐ | | |
+ *| | | | | | | | | | | | | | | |
+ *| | | | | | | | | | | | | | | |
+ *1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+ *  3   2   1   0
+ *
+ *   Used in handling following instructions:
+ *
+ * - ADDU[4X4]
+ * - LW[4X4]
+ * - MOVEP[REV]
+ * - MUL[4X4]
+ * - SW[4X4]
+ */
 uint64 NMD::decode_gpr_gpr4(uint64 d)
 {
 static uint64 register_list[] = {  8,  9, 10, 11,  4,  5,  6,  7,
-- 
2.7.4

[Qemu-devel] [PULL 17/41] disas: nanoMIPS: Fix an FP-related misnomer 1

[Aleksandar Markovic]

From: Aleksandar Markovic 

Rename NMD::extract_fd_10_9_8_7_6(uint64 instruction) to
NMD::extract_fd_15_14_13_12_11(uint64 instruction).

Reviewed-by: Aleksandar Rikalo 
Signed-off-by: Aleksandar Markovic 
---
 disas/nanomips.cpp | 142 ++---
 disas/nanomips.h   |   2 +-
 2 files changed, 72 insertions(+), 72 deletions(-)

diff --git a/disas/nanomips.cpp b/disas/nanomips.cpp
index 281d8d9..bff1900 100644
--- a/disas/nanomips.cpp
+++ b/disas/nanomips.cpp
@@ -1446,7 +1446,7 @@ uint64 NMD::extract_u_3_8__s2(uint64 instruction)
 }
 
 
-uint64 NMD::extract_fd_10_9_8_7_6(uint64 instruction)
+uint64 NMD::extract_fd_15_14_13_12_11(uint64 instruction)
 {
 uint64 value = 0;
 value |= extract_bits(instruction, 11, 5);
@@ -1757,7 +1757,7 @@ std::string NMD::ADD_D(uint64 instruction)
 {
 uint64 ft_value = extract_ft_20_19_18_17_16(instruction);
 uint64 fs_value = extract_fs_15_14_13_12_11(instruction);
-uint64 fd_value = extract_fd_10_9_8_7_6(instruction);
+uint64 fd_value = extract_fd_15_14_13_12_11(instruction);
 
 std::string ft = FPR(copy(ft_value));
 std::string fs = FPR(copy(fs_value));
@@ -1782,7 +1782,7 @@ std::string NMD::ADD_S(uint64 instruction)
 {
 uint64 ft_value = extract_ft_20_19_18_17_16(instruction);
 uint64 fs_value = extract_fs_15_14_13_12_11(instruction);
-uint64 fd_value = extract_fd_10_9_8_7_6(instruction);
+uint64 fd_value = extract_fd_15_14_13_12_11(instruction);
 
 std::string ft = FPR(copy(ft_value));
 std::string fs = FPR(copy(fs_value));
@@ -3604,7 +3604,7 @@ std::string NMD::CMP_AF_D(uint64 instruction)
 {
 uint64 ft_value = extract_ft_20_19_18_17_16(instruction);
 uint64 fs_value = extract_fs_15_14_13_12_11(instruction);
-uint64 fd_value = extract_fd_10_9_8_7_6(instruction);
+uint64 fd_value = extract_fd_15_14_13_12_11(instruction);
 
 std::string fd = FPR(copy(fd_value));
 std::string fs = FPR(copy(fs_value));
@@ -3628,7 +3628,7 @@ std::string NMD::CMP_AF_S(uint64 instruction)
 {
 uint64 ft_value = extract_ft_20_19_18_17_16(instruction);
 uint64 fs_value = extract_fs_15_14_13_12_11(instruction);
-uint64 fd_value = extract_fd_10_9_8_7_6(instruction);
+uint64 fd_value = extract_fd_15_14_13_12_11(instruction);
 
 std::string fd = FPR(copy(fd_value));
 std::string fs = FPR(copy(fs_value));
@@ -3652,7 +3652,7 @@ std::string NMD::CMP_EQ_D(uint64 instruction)
 {
 uint64 ft_value = extract_ft_20_19_18_17_16(instruction);
 uint64 fs_value = extract_fs_15_14_13_12_11(instruction);
-uint64 fd_value = extract_fd_10_9_8_7_6(instruction);
+uint64 fd_value = extract_fd_15_14_13_12_11(instruction);
 
 std::string fd = FPR(copy(fd_value));
 std::string fs = FPR(copy(fs_value));
@@ -3698,7 +3698,7 @@ std::string NMD::CMP_EQ_S(uint64 instruction)
 {
 uint64 ft_value = extract_ft_20_19_18_17_16(instruction);
 uint64 fs_value = extract_fs_15_14_13_12_11(instruction);
-uint64 fd_value = extract_fd_10_9_8_7_6(instruction);
+uint64 fd_value = extract_fd_15_14_13_12_11(instruction);
 
 std::string fd = FPR(copy(fd_value));
 std::string fs = FPR(copy(fs_value));
@@ -3722,7 +3722,7 @@ std::string NMD::CMP_LE_D(uint64 instruction)
 {
 uint64 ft_value = extract_ft_20_19_18_17_16(instruction);
 uint64 fs_value = extract_fs_15_14_13_12_11(instruction);
-uint64 fd_value = extract_fd_10_9_8_7_6(instruction);
+uint64 fd_value = extract_fd_15_14_13_12_11(instruction);
 
 std::string fd = FPR(copy(fd_value));
 std::string fs = FPR(copy(fs_value));
@@ -3768,7 +3768,7 @@ std::string NMD::CMP_LE_S(uint64 instruction)
 {
 uint64 ft_value = extract_ft_20_19_18_17_16(instruction);
 uint64 fs_value = extract_fs_15_14_13_12_11(instruction);
-uint64 fd_value = extract_fd_10_9_8_7_6(instruction);
+uint64 fd_value = extract_fd_15_14_13_12_11(instruction);
 
 std::string fd = FPR(copy(fd_value));
 std::string fs = FPR(copy(fs_value));
@@ -3792,7 +3792,7 @@ std::string NMD::CMP_LT_D(uint64 instruction)
 {
 uint64 ft_value = extract_ft_20_19_18_17_16(instruction);
 uint64 fs_value = extract_fs_15_14_13_12_11(instruction);
-uint64 fd_value = extract_fd_10_9_8_7_6(instruction);
+uint64 fd_value = extract_fd_15_14_13_12_11(instruction);
 
 std::string fd = FPR(copy(fd_value));
 std::string fs = FPR(copy(fs_value));
@@ -3838,7 +3838,7 @@ std::string NMD::CMP_LT_S(uint64 instruction)
 {
 uint64 ft_value = extract_ft_20_19_18_17_16(instruction);
 uint64 fs_value = extract_fs_15_14_13_12_11(instruction);
-uint64 fd_value = extract_fd_10_9_8_7_6(instruction);
+uint64 fd_value = extract_fd_15_14_13_12_11(instruction);
 
 std::string fd = FPR(copy(fd_value));
 std::string fs = FPR(copy(fs_value));
@@ -3862,7 +3862,7 @@ std::string NMD::CMP_NE_D(uint64 instruction)
 {
 uint64 ft_value = extract_ft_20_19_18_17_16(instruction);
 uint64 fs_value = extrac

[Qemu-devel] [PULL 20/41] disas: nanoMIPS: Name more functions in a more descriptive way

[Aleksandar Markovic]

From: Aleksandar Markovic 

Rename more functions that have names that are hard to understand.

Reviewed-by: Aleksandar Rikalo 
Signed-off-by: Aleksandar Markovic 
---
 disas/nanomips.cpp | 212 ++---
 disas/nanomips.h   |  28 +++
 2 files changed, 120 insertions(+), 120 deletions(-)

diff --git a/disas/nanomips.cpp b/disas/nanomips.cpp
index 69b6e99..aa33434 100644
--- a/disas/nanomips.cpp
+++ b/disas/nanomips.cpp
@@ -719,7 +719,7 @@ uint64 NMD::extract_u_17_to_1__s1(uint64 instruction)
 }
 
 
-int64 NMD::extr_sil11il0bs10Tmsb9(uint64 instruction)
+int64 NMD::extract_s__se9_20_19_18_17_16_15_14_13_12_11(uint64 instruction)
 {
 int64 value = 0;
 value |= extract_bits(instruction, 11, 10);
@@ -728,7 +728,7 @@ int64 NMD::extr_sil11il0bs10Tmsb9(uint64 instruction)
 }
 
 
-int64 NMD::extr_sil0il11bs1_il1il1bs10Tmsb11(uint64 instruction)
+int64 NMD::extract_s__se11_0_10_9_8_7_6_5_4_3_2_1_0_s1(uint64 instruction)
 {
 int64 value = 0;
 value |= extract_bits(instruction, 0, 1) << 11;
@@ -795,7 +795,7 @@ uint64 NMD::extract_count3_14_13_12(uint64 instruction)
 }
 
 
-int64 NMD::extr_sil0il31bs1_il2il21bs10_il12il12bs9Tmsb31(uint64 instruction)
+int64 NMD::extract_s__se31_0_11_to_2_20_to_12_s12(uint64 instruction)
 {
 int64 value = 0;
 value |= extract_bits(instruction, 0, 1) << 31;
@@ -806,7 +806,7 @@ int64 
NMD::extr_sil0il31bs1_il2il21bs10_il12il12bs9Tmsb31(uint64 instruction)
 }
 
 
-int64 NMD::extr_sil0il7bs1_il1il1bs6Tmsb7(uint64 instruction)
+int64 NMD::extract_s__se7_0_6_5_4_3_2_1_s1(uint64 instruction)
 {
 int64 value = 0;
 value |= extract_bits(instruction, 0, 1) << 7;
@@ -880,7 +880,7 @@ uint64 NMD::extract_rdl_25_24(uint64 instruction)
 }
 
 
-int64 NMD::extr_sil0il10bs1_il1il1bs9Tmsb10(uint64 instruction)
+int64 NMD::extract_s__se10_0_9_8_7_6_5_4_3_2_1_s1(uint64 instruction)
 {
 int64 value = 0;
 value |= extract_bits(instruction, 0, 1) << 10;
@@ -1019,7 +1019,7 @@ uint64 NMD::extract_rsz4_4_2_1_0(uint64 instruction)
 }
 
 
-int64 NMD::extr_sil0il21bs1_il1il1bs20Tmsb21(uint64 instruction)
+int64 NMD::extract_s__se21_0_20_to_1_s1(uint64 instruction)
 {
 int64 value = 0;
 value |= extract_bits(instruction, 0, 1) << 21;
@@ -1062,7 +1062,7 @@ uint64 NMD::extract_rt_41_40_39_38_37(uint64 instruction)
 }
 
 
-int64 NMD::extract_shift_21_20_19_18_17_16(uint64 instruction)
+int64 NMD::extract_shift__se5_21_20_19_18_17_16(uint64 instruction)
 {
 int64 value = 0;
 value |= extract_bits(instruction, 16, 6);
@@ -1096,7 +1096,7 @@ uint64 NMD::extract_size_20_19_18_17_16(uint64 
instruction)
 }
 
 
-int64 NMD::extr_sil2il2bs6_il15il8bs1Tmsb8(uint64 instruction)
+int64 NMD::extract_s__se8_15_7_6_5_4_3_2_s2(uint64 instruction)
 {
 int64 value = 0;
 value |= extract_bits(instruction, 2, 6) << 2;
@@ -1122,7 +1122,7 @@ uint64 NMD::extract_fs_20_19_18_17_16(uint64 instruction)
 }
 
 
-int64 NMD::extr_sil0il0bs8_il15il8bs1Tmsb8(uint64 instruction)
+int64 NMD::extract_s__se8_15_7_6_5_4_3_2_1_0(uint64 instruction)
 {
 int64 value = 0;
 value |= extract_bits(instruction, 0, 8);
@@ -1245,7 +1245,7 @@ uint64 NMD::extract_sa_15_14_13(uint64 instruction)
 }
 
 
-int64 NMD::extr_sil0il14bs1_il1il1bs13Tmsb14(uint64 instruction)
+int64 NMD::extract_s__se14_0_13_to_1_s1(uint64 instruction)
 {
 int64 value = 0;
 value |= extract_bits(instruction, 0, 1) << 14;
@@ -1351,7 +1351,7 @@ uint64 NMD::extract_u_7_6_5_4__s4(uint64 instruction)
 }
 
 
-int64 NMD::extr_sil3il3bs5_il15il8bs1Tmsb8(uint64 instruction)
+int64 NMD::extract_s__se8_15_7_6_5_4_3_s3(uint64 instruction)
 {
 int64 value = 0;
 value |= extract_bits(instruction, 3, 5) << 3;
@@ -1369,7 +1369,7 @@ uint64 NMD::extract_ft_15_14_13_12_11(uint64 instruction)
 }
 
 
-int64 NMD::extr_sil0il16bs16_il16il0bs16Tmsb31(uint64 instruction)
+int64 NMD::extract_s__se31_15_to_0_31_to_16(uint64 instruction)
 {
 int64 value = 0;
 value |= extract_bits(instruction, 0, 16) << 16;
@@ -1419,7 +1419,7 @@ uint64 NMD::extract_code_1_0(uint64 instruction)
 }
 
 
-int64 NMD::extr_sil0il25bs1_il1il1bs24Tmsb25(uint64 instruction)
+int64 NMD::extract_s__se25_0_24_to_1_s1(uint64 instruction)
 {
 int64 value = 0;
 value |= extract_bits(instruction, 0, 1) << 25;
@@ -1495,7 +1495,7 @@ uint64 NMD::extract_u_20_to_2__s2(uint64 instruction)
 }
 
 
-int64 NMD::extract_s_4_2_1_0(uint64 instruction)
+int64 NMD::extract_s__se3_4_2_1_0(uint64 instruction)
 {
 int64 value = 0;
 value |= extract_bits(instruction, 0, 3);
@@ -1708,7 +1708,7 @@ std::string NMD::ABSQ_S_W(uint64 instruction)
 std::string NMD::ACLR(uint64 instruction)
 {
 uint64 bit_value = extract_bit_23_22_21(instruction);
-int64 s_value = extr_sil0il0bs8_il15il8bs1Tmsb8(instruction);
+int64 s_value = extract_s__se8_15_7_6_5_4_3_2_1_0(instruction);
 uint64 rs_value = extract_rs_20_19_18_17_16(instruction);
 
 std::string bit = IMMEDIATE(copy(bit_value));
@@ -1827,7 +1827,7 @@ st

[Qemu-devel] [PULL 19/41] disas: nanoMIPS: Fix an FP-related misnomer 3

[Aleksandar Markovic]

From: Aleksandar Markovic 

Rename NMD::extract_ft_20_19_18_17_16(uint64 instruction) to
NMD::extract_ft_25_24_23_22_21(uint64 instruction).

Reviewed-by: Aleksandar Rikalo 
Signed-off-by: Aleksandar Markovic 
---
 disas/nanomips.cpp | 258 ++---
 disas/nanomips.h   |   2 +-
 2 files changed, 130 insertions(+), 130 deletions(-)

diff --git a/disas/nanomips.cpp b/disas/nanomips.cpp
index b9ad0f7..69b6e99 100644
--- a/disas/nanomips.cpp
+++ b/disas/nanomips.cpp
@@ -1188,7 +1188,7 @@ uint64 NMD::extract_rt3_9_8_7(uint64 instruction)
 }
 
 
-uint64 NMD::extract_ft_20_19_18_17_16(uint64 instruction)
+uint64 NMD::extract_ft_25_24_23_22_21(uint64 instruction)
 {
 uint64 value = 0;
 value |= extract_bits(instruction, 21, 5);
@@ -1601,7 +1601,7 @@ bool NMD::SLTU_cond(uint64 instruction)
  */
 std::string NMD::ABS_D(uint64 instruction)
 {
-uint64 fd_value = extract_ft_20_19_18_17_16(instruction);
+uint64 fd_value = extract_ft_25_24_23_22_21(instruction);
 uint64 fs_value = extract_fs_20_19_18_17_16(instruction);
 
 std::string fs = FPR(copy(fs_value));
@@ -1623,7 +1623,7 @@ std::string NMD::ABS_D(uint64 instruction)
  */
 std::string NMD::ABS_S(uint64 instruction)
 {
-uint64 fd_value = extract_ft_20_19_18_17_16(instruction);
+uint64 fd_value = extract_ft_25_24_23_22_21(instruction);
 uint64 fs_value = extract_fs_20_19_18_17_16(instruction);
 
 std::string fs = FPR(copy(fs_value));
@@ -1755,7 +1755,7 @@ std::string NMD::ADD(uint64 instruction)
  */
 std::string NMD::ADD_D(uint64 instruction)
 {
-uint64 ft_value = extract_ft_20_19_18_17_16(instruction);
+uint64 ft_value = extract_ft_25_24_23_22_21(instruction);
 uint64 fs_value = extract_fs_20_19_18_17_16(instruction);
 uint64 fd_value = extract_fd_15_14_13_12_11(instruction);
 
@@ -1780,7 +1780,7 @@ std::string NMD::ADD_D(uint64 instruction)
  */
 std::string NMD::ADD_S(uint64 instruction)
 {
-uint64 ft_value = extract_ft_20_19_18_17_16(instruction);
+uint64 ft_value = extract_ft_25_24_23_22_21(instruction);
 uint64 fs_value = extract_fs_20_19_18_17_16(instruction);
 uint64 fd_value = extract_fd_15_14_13_12_11(instruction);
 
@@ -2787,7 +2787,7 @@ std::string NMD::BC_32_(uint64 instruction)
 std::string NMD::BC1EQZC(uint64 instruction)
 {
 int64 s_value = extr_sil0il14bs1_il1il1bs13Tmsb14(instruction);
-uint64 ft_value = extract_ft_20_19_18_17_16(instruction);
+uint64 ft_value = extract_ft_25_24_23_22_21(instruction);
 
 std::string ft = FPR(copy(ft_value));
 std::string s = ADDRESS(encode_s_from_address(s_value), 4);
@@ -2809,7 +2809,7 @@ std::string NMD::BC1EQZC(uint64 instruction)
 std::string NMD::BC1NEZC(uint64 instruction)
 {
 int64 s_value = extr_sil0il14bs1_il1il1bs13Tmsb14(instruction);
-uint64 ft_value = extract_ft_20_19_18_17_16(instruction);
+uint64 ft_value = extract_ft_25_24_23_22_21(instruction);
 
 std::string ft = FPR(copy(ft_value));
 std::string s = ADDRESS(encode_s_from_address(s_value), 4);
@@ -3382,7 +3382,7 @@ std::string NMD::CACHEE(uint64 instruction)
  */
 std::string NMD::CEIL_L_D(uint64 instruction)
 {
-uint64 ft_value = extract_ft_20_19_18_17_16(instruction);
+uint64 ft_value = extract_ft_25_24_23_22_21(instruction);
 uint64 fs_value = extract_fs_20_19_18_17_16(instruction);
 
 std::string ft = FPR(copy(ft_value));
@@ -3404,7 +3404,7 @@ std::string NMD::CEIL_L_D(uint64 instruction)
  */
 std::string NMD::CEIL_L_S(uint64 instruction)
 {
-uint64 ft_value = extract_ft_20_19_18_17_16(instruction);
+uint64 ft_value = extract_ft_25_24_23_22_21(instruction);
 uint64 fs_value = extract_fs_20_19_18_17_16(instruction);
 
 std::string ft = FPR(copy(ft_value));
@@ -3426,7 +3426,7 @@ std::string NMD::CEIL_L_S(uint64 instruction)
  */
 std::string NMD::CEIL_W_D(uint64 instruction)
 {
-uint64 ft_value = extract_ft_20_19_18_17_16(instruction);
+uint64 ft_value = extract_ft_25_24_23_22_21(instruction);
 uint64 fs_value = extract_fs_20_19_18_17_16(instruction);
 
 std::string ft = FPR(copy(ft_value));
@@ -3448,7 +3448,7 @@ std::string NMD::CEIL_W_D(uint64 instruction)
  */
 std::string NMD::CEIL_W_S(uint64 instruction)
 {
-uint64 ft_value = extract_ft_20_19_18_17_16(instruction);
+uint64 ft_value = extract_ft_25_24_23_22_21(instruction);
 uint64 fs_value = extract_fs_20_19_18_17_16(instruction);
 
 std::string ft = FPR(copy(ft_value));
@@ -3514,7 +3514,7 @@ std::string NMD::CFC2(uint64 instruction)
  */
 std::string NMD::CLASS_D(uint64 instruction)
 {
-uint64 ft_value = extract_ft_20_19_18_17_16(instruction);
+uint64 ft_value = extract_ft_25_24_23_22_21(instruction);
 uint64 fs_value = extract_fs_20_19_18_17_16(instruction);
 
 std::string ft = FPR(copy(ft_value));
@@ -3536,7 +3536,7 @@ std::string NMD::CLASS_D(uint64 instruction)
  */
 std::string NMD::CLASS_S(uint64 instruction)
 {
-uint64 ft_value = extract_ft_20_1

[Qemu-devel] [PULL 22/41] disas: nanoMIPS: Rename the decoder of 'gpr3' gpr encoding type

[Aleksandar Markovic]

From: Aleksandar Markovic 

Rename the decoder of 'gpr3' gpr encoding type in nanoMIPS
disassembler.

Reviewed-by: Aleksandar Rikalo 
Signed-off-by: Aleksandar Markovic 
---
 disas/nanomips.cpp | 96 +++---
 disas/nanomips.h   |  2 +-
 2 files changed, 49 insertions(+), 49 deletions(-)

diff --git a/disas/nanomips.cpp b/disas/nanomips.cpp
index e9018ea..2856645 100644
--- a/disas/nanomips.cpp
+++ b/disas/nanomips.cpp
@@ -296,7 +296,7 @@ uint64 NMD::renumber_registers(uint64 index, uint64 
*register_list,
  * decode sections so they are based on the encode, the equivalent decode
  * functions need writing eventually.
  */
-uint64 NMD::encode_gpr3(uint64 d)
+uint64 NMD::decode_gpr_gpr3(uint64 d)
 {
 static uint64 register_list[] = { 16, 17, 18, 19,  4,  5,  6,  7 };
 return renumber_registers(d, register_list,
@@ -381,14 +381,14 @@ int64 NMD::neg_copy(int64 d)
 /* strange wrapper around  gpr3 */
 uint64 NMD::encode_rs3_and_check_rs3_ge_rt3(uint64 d)
 {
-return encode_gpr3(d);
+return decode_gpr_gpr3(d);
 }
 
 
 /* strange wrapper around  gpr3 */
 uint64 NMD::encode_rs3_and_check_rs3_lt_rt3(uint64 d)
 {
-return encode_gpr3(d);
+return decode_gpr_gpr3(d);
 }
 
 
@@ -1936,7 +1936,7 @@ std::string NMD::ADDIU_R1_SP_(uint64 instruction)
 uint64 u_value = extract_u_5_4_3_2_1_0__s2(instruction);
 uint64 rt3_value = extract_rt3_9_8_7(instruction);
 
-std::string rt3 = GPR(encode_gpr3(rt3_value));
+std::string rt3 = GPR(decode_gpr_gpr3(rt3_value));
 std::string u = IMMEDIATE(copy(u_value));
 
 return img::format("ADDIU %s, $%d, %s", rt3, 29, u);
@@ -1958,8 +1958,8 @@ std::string NMD::ADDIU_R2_(uint64 instruction)
 uint64 rs3_value = extract_rs3_6_5_4(instruction);
 uint64 u_value = extract_u_2_1_0__s2(instruction);
 
-std::string rt3 = GPR(encode_gpr3(rt3_value));
-std::string rs3 = GPR(encode_gpr3(rs3_value));
+std::string rt3 = GPR(decode_gpr_gpr3(rt3_value));
+std::string rs3 = GPR(decode_gpr_gpr3(rs3_value));
 std::string u = IMMEDIATE(copy(u_value));
 
 return img::format("ADDIU %s, %s, %s", rt3, rs3, u);
@@ -2239,9 +2239,9 @@ std::string NMD::ADDU_16_(uint64 instruction)
 uint64 rs3_value = extract_rs3_6_5_4(instruction);
 uint64 rd3_value = extract_rd3_3_2_1(instruction);
 
-std::string rt3 = GPR(encode_gpr3(rt3_value));
-std::string rs3 = GPR(encode_gpr3(rs3_value));
-std::string rd3 = GPR(encode_gpr3(rd3_value));
+std::string rt3 = GPR(decode_gpr_gpr3(rt3_value));
+std::string rs3 = GPR(decode_gpr_gpr3(rs3_value));
+std::string rd3 = GPR(decode_gpr_gpr3(rd3_value));
 
 return img::format("ADDU %s, %s, %s", rd3, rs3, rt3);
 }
@@ -2498,8 +2498,8 @@ std::string NMD::AND_16_(uint64 instruction)
 uint64 rt3_value = extract_rt3_9_8_7(instruction);
 uint64 rs3_value = extract_rs3_6_5_4(instruction);
 
-std::string rt3 = GPR(encode_gpr3(rt3_value));
-std::string rs3 = GPR(encode_gpr3(rs3_value));
+std::string rt3 = GPR(decode_gpr_gpr3(rt3_value));
+std::string rs3 = GPR(decode_gpr_gpr3(rs3_value));
 
 return img::format("AND %s, %s", rs3, rt3);
 }
@@ -2544,8 +2544,8 @@ std::string NMD::ANDI_16_(uint64 instruction)
 uint64 rs3_value = extract_rs3_6_5_4(instruction);
 uint64 eu_value = extract_eu_3_2_1_0(instruction);
 
-std::string rt3 = GPR(encode_gpr3(rt3_value));
-std::string rs3 = GPR(encode_gpr3(rs3_value));
+std::string rt3 = GPR(decode_gpr_gpr3(rt3_value));
+std::string rs3 = GPR(decode_gpr_gpr3(rs3_value));
 std::string eu = IMMEDIATE(encode_eu_from_u_andi16(eu_value));
 
 return img::format("ANDI %s, %s, %s", rt3, rs3, eu);
@@ -2879,7 +2879,7 @@ std::string NMD::BEQC_16_(uint64 instruction)
 uint64 u_value = extract_u_3_2_1_0__s1(instruction);
 
 std::string rs3 = GPR(encode_rs3_and_check_rs3_lt_rt3(rs3_value));
-std::string rt3 = GPR(encode_gpr3(rt3_value));
+std::string rt3 = GPR(decode_gpr_gpr3(rt3_value));
 std::string u = ADDRESS(encode_u_from_address(u_value), 2);
 
 return img::format("BEQC %s, %s, %s", rs3, rt3, u);
@@ -2949,7 +2949,7 @@ std::string NMD::BEQZC_16_(uint64 instruction)
 uint64 rt3_value = extract_rt3_9_8_7(instruction);
 int64 s_value = extract_s__se7_0_6_5_4_3_2_1_s1(instruction);
 
-std::string rt3 = GPR(encode_gpr3(rt3_value));
+std::string rt3 = GPR(decode_gpr_gpr3(rt3_value));
 std::string s = ADDRESS(encode_s_from_address(s_value), 2);
 
 return img::format("BEQZC %s, %s", rt3, s);
@@ -3165,7 +3165,7 @@ std::string NMD::BNEC_16_(uint64 instruction)
 uint64 u_value = extract_u_3_2_1_0__s1(instruction);
 
 std::string rs3 = GPR(encode_rs3_and_check_rs3_ge_rt3(rs3_value));
-std::string rt3 = GPR(encode_gpr3(rt3_value));
+std::string rt3 = GPR(decode_gpr_gpr3(rt3_value));
 std::string u = ADDRESS(encode_u_from_address(u_value), 2);
 
 return img::format("BNEC %s, %s, %s", rs3, rt3, u);
@@ -3235,7 +3235,

[Qemu-devel] [PULL 16/41] disas: nanoMIPS: Name some functions in a more descriptive way

[Aleksandar Markovic]

From: Aleksandar Markovic 

Rename some functions that have names that are hard to understand.

Reviewed-by: Aleksandar Rikalo 
Reviewed-by: Stefan Markovic 
Signed-off-by: Aleksandar Markovic 
---
 disas/nanomips.cpp | 112 ++---
 disas/nanomips.h   |  32 +++
 2 files changed, 72 insertions(+), 72 deletions(-)

diff --git a/disas/nanomips.cpp b/disas/nanomips.cpp
index d8829f5..281d8d9 100644
--- a/disas/nanomips.cpp
+++ b/disas/nanomips.cpp
@@ -687,7 +687,7 @@ uint64 NMD::extract_shift3_2_1_0(uint64 instruction)
 }
 
 
-uint64 NMD::extr_uil3il3bs9Fmsb11(uint64 instruction)
+uint64 NMD::extract_u_11_10_9_8_7_6_5_4_3__s3(uint64 instruction)
 {
 uint64 value = 0;
 value |= extract_bits(instruction, 3, 9) << 3;
@@ -711,7 +711,7 @@ uint64 NMD::extract_rtz3_9_8_7(uint64 instruction)
 }
 
 
-uint64 NMD::extr_uil1il1bs17Fmsb17(uint64 instruction)
+uint64 NMD::extract_u_17_to_1__s1(uint64 instruction)
 {
 uint64 value = 0;
 value |= extract_bits(instruction, 1, 17) << 1;
@@ -771,7 +771,7 @@ uint64 NMD::extract_shift_4_3_2_1_0(uint64 instruction)
 }
 
 
-uint64 NMD::extr_shiftxil7il1bs4Fmsb4(uint64 instruction)
+uint64 NMD::extract_shiftx_10_9_8_7__s1(uint64 instruction)
 {
 uint64 value = 0;
 value |= extract_bits(instruction, 7, 4) << 1;
@@ -840,7 +840,7 @@ uint64 NMD::extract_rs_20_19_18_17_16(uint64 instruction)
 }
 
 
-uint64 NMD::extr_uil1il1bs2Fmsb2(uint64 instruction)
+uint64 NMD::extract_u_2_1__s1(uint64 instruction)
 {
 uint64 value = 0;
 value |= extract_bits(instruction, 1, 2) << 1;
@@ -938,7 +938,7 @@ uint64 NMD::extract_rs_4_3_2_1_0(uint64 instruction)
 }
 
 
-uint64 NMD::extr_uil3il3bs18Fmsb20(uint64 instruction)
+uint64 NMD::extract_u_20_to_3__s3(uint64 instruction)
 {
 uint64 value = 0;
 value |= extract_bits(instruction, 3, 18) << 3;
@@ -946,7 +946,7 @@ uint64 NMD::extr_uil3il3bs18Fmsb20(uint64 instruction)
 }
 
 
-uint64 NMD::extr_uil0il2bs4Fmsb5(uint64 instruction)
+uint64 NMD::extract_u_3_2_1_0__s2(uint64 instruction)
 {
 uint64 value = 0;
 value |= extract_bits(instruction, 0, 4) << 2;
@@ -962,7 +962,7 @@ uint64 NMD::extract_cofun_25_24_23(uint64 instruction)
 }
 
 
-uint64 NMD::extr_uil0il2bs3Fmsb4(uint64 instruction)
+uint64 NMD::extract_u_2_1_0__s2(uint64 instruction)
 {
 uint64 value = 0;
 value |= extract_bits(instruction, 0, 3) << 2;
@@ -1229,7 +1229,7 @@ uint64 NMD::extract_msbt_10_9_8_7_6(uint64 instruction)
 }
 
 
-uint64 NMD::extr_uil0il2bs6Fmsb7(uint64 instruction)
+uint64 NMD::extract_u_5_4_3_2_1_0__s2(uint64 instruction)
 {
 uint64 value = 0;
 value |= extract_bits(instruction, 0, 6) << 2;
@@ -1263,7 +1263,7 @@ uint64 NMD::extract_rs3_6_5_4(uint64 instruction)
 }
 
 
-uint64 NMD::extr_uil0il32bs32Fmsb63(uint64 instruction)
+uint64 NMD::extract_u_31_to_0__s32(uint64 instruction)
 {
 uint64 value = 0;
 value |= extract_bits(instruction, 0, 32) << 32;
@@ -1311,7 +1311,7 @@ uint64 NMD::extract_op_25_24_23_22_21(uint64 instruction)
 }
 
 
-uint64 NMD::extr_uil0il2bs7Fmsb8(uint64 instruction)
+uint64 NMD::extract_u_6_5_4_3_2_1_0__s2(uint64 instruction)
 {
 uint64 value = 0;
 value |= extract_bits(instruction, 0, 7) << 2;
@@ -1343,7 +1343,7 @@ uint64 NMD::extract_eu_3_2_1_0(uint64 instruction)
 }
 
 
-uint64 NMD::extr_uil4il4bs4Fmsb7(uint64 instruction)
+uint64 NMD::extract_u_7_6_5_4__s4(uint64 instruction)
 {
 uint64 value = 0;
 value |= extract_bits(instruction, 4, 4) << 4;
@@ -1387,7 +1387,7 @@ uint64 NMD::extract_u_20_19_18_17_16_15_14_13(uint64 
instruction)
 }
 
 
-uint64 NMD::extr_uil2il2bs16Fmsb17(uint64 instruction)
+uint64 NMD::extract_u_17_to_2__s2(uint64 instruction)
 {
 uint64 value = 0;
 value |= extract_bits(instruction, 2, 16) << 2;
@@ -1437,7 +1437,7 @@ uint64 NMD::extract_u_1_0(uint64 instruction)
 }
 
 
-uint64 NMD::extr_uil3il3bs1_il8il2bs1Fmsb3(uint64 instruction)
+uint64 NMD::extract_u_3_8__s2(uint64 instruction)
 {
 uint64 value = 0;
 value |= extract_bits(instruction, 3, 1) << 3;
@@ -1454,7 +1454,7 @@ uint64 NMD::extract_fd_10_9_8_7_6(uint64 instruction)
 }
 
 
-uint64 NMD::extr_uil0il2bs5Fmsb6(uint64 instruction)
+uint64 NMD::extract_u_4_3_2_1_0__s2(uint64 instruction)
 {
 uint64 value = 0;
 value |= extract_bits(instruction, 0, 5) << 2;
@@ -1487,7 +1487,7 @@ uint64 NMD::extract_ct_25_24_23_22_21(uint64 instruction)
 }
 
 
-uint64 NMD::extr_uil2il2bs19Fmsb20(uint64 instruction)
+uint64 NMD::extract_u_20_to_2__s2(uint64 instruction)
 {
 uint64 value = 0;
 value |= extract_bits(instruction, 2, 19) << 2;
@@ -1505,7 +1505,7 @@ int64 NMD::extract_s_4_2_1_0(uint64 instruction)
 }
 
 
-uint64 NMD::extr_uil0il1bs4Fmsb4(uint64 instruction)
+uint64 NMD::extract_u_3_2_1_0__s1(uint64 instruction)
 {
 uint64 value = 0;
 value |= extract_bits(instruction, 0, 4) << 1;
@@ -1539,7 +1539,7 @@ bool NMD::BEQC_16__cond(uint64 instruction)
 {
 uint64 rs3 = extract_rs3_6_5_4(instruction);
 uin

[Qemu-devel] [PULL 18/41] disas: nanoMIPS: Fix an FP-related misnomer 2

[Aleksandar Markovic]

From: Aleksandar Markovic 

Rename NMD::extract_fs_15_14_13_12_11(uint64 instruction) to
NMD::extract_fs_20_19_18_17_16(uint64 instruction).

Reviewed-by: Aleksandar Rikalo 
Signed-off-by: Aleksandar Markovic 
---
 disas/nanomips.cpp | 242 ++---
 disas/nanomips.h   |   2 +-
 2 files changed, 122 insertions(+), 122 deletions(-)

diff --git a/disas/nanomips.cpp b/disas/nanomips.cpp
index bff1900..b9ad0f7 100644
--- a/disas/nanomips.cpp
+++ b/disas/nanomips.cpp
@@ -1114,7 +1114,7 @@ uint64 NMD::extract_u_15_to_0(uint64 instruction)
 }
 
 
-uint64 NMD::extract_fs_15_14_13_12_11(uint64 instruction)
+uint64 NMD::extract_fs_20_19_18_17_16(uint64 instruction)
 {
 uint64 value = 0;
 value |= extract_bits(instruction, 16, 5);
@@ -1602,7 +1602,7 @@ bool NMD::SLTU_cond(uint64 instruction)
 std::string NMD::ABS_D(uint64 instruction)
 {
 uint64 fd_value = extract_ft_20_19_18_17_16(instruction);
-uint64 fs_value = extract_fs_15_14_13_12_11(instruction);
+uint64 fs_value = extract_fs_20_19_18_17_16(instruction);
 
 std::string fs = FPR(copy(fs_value));
 std::string fd = FPR(copy(fd_value));
@@ -1624,7 +1624,7 @@ std::string NMD::ABS_D(uint64 instruction)
 std::string NMD::ABS_S(uint64 instruction)
 {
 uint64 fd_value = extract_ft_20_19_18_17_16(instruction);
-uint64 fs_value = extract_fs_15_14_13_12_11(instruction);
+uint64 fs_value = extract_fs_20_19_18_17_16(instruction);
 
 std::string fs = FPR(copy(fs_value));
 std::string fd = FPR(copy(fd_value));
@@ -1756,7 +1756,7 @@ std::string NMD::ADD(uint64 instruction)
 std::string NMD::ADD_D(uint64 instruction)
 {
 uint64 ft_value = extract_ft_20_19_18_17_16(instruction);
-uint64 fs_value = extract_fs_15_14_13_12_11(instruction);
+uint64 fs_value = extract_fs_20_19_18_17_16(instruction);
 uint64 fd_value = extract_fd_15_14_13_12_11(instruction);
 
 std::string ft = FPR(copy(ft_value));
@@ -1781,7 +1781,7 @@ std::string NMD::ADD_D(uint64 instruction)
 std::string NMD::ADD_S(uint64 instruction)
 {
 uint64 ft_value = extract_ft_20_19_18_17_16(instruction);
-uint64 fs_value = extract_fs_15_14_13_12_11(instruction);
+uint64 fs_value = extract_fs_20_19_18_17_16(instruction);
 uint64 fd_value = extract_fd_15_14_13_12_11(instruction);
 
 std::string ft = FPR(copy(ft_value));
@@ -3383,7 +3383,7 @@ std::string NMD::CACHEE(uint64 instruction)
 std::string NMD::CEIL_L_D(uint64 instruction)
 {
 uint64 ft_value = extract_ft_20_19_18_17_16(instruction);
-uint64 fs_value = extract_fs_15_14_13_12_11(instruction);
+uint64 fs_value = extract_fs_20_19_18_17_16(instruction);
 
 std::string ft = FPR(copy(ft_value));
 std::string fs = FPR(copy(fs_value));
@@ -3405,7 +3405,7 @@ std::string NMD::CEIL_L_D(uint64 instruction)
 std::string NMD::CEIL_L_S(uint64 instruction)
 {
 uint64 ft_value = extract_ft_20_19_18_17_16(instruction);
-uint64 fs_value = extract_fs_15_14_13_12_11(instruction);
+uint64 fs_value = extract_fs_20_19_18_17_16(instruction);
 
 std::string ft = FPR(copy(ft_value));
 std::string fs = FPR(copy(fs_value));
@@ -3427,7 +3427,7 @@ std::string NMD::CEIL_L_S(uint64 instruction)
 std::string NMD::CEIL_W_D(uint64 instruction)
 {
 uint64 ft_value = extract_ft_20_19_18_17_16(instruction);
-uint64 fs_value = extract_fs_15_14_13_12_11(instruction);
+uint64 fs_value = extract_fs_20_19_18_17_16(instruction);
 
 std::string ft = FPR(copy(ft_value));
 std::string fs = FPR(copy(fs_value));
@@ -3449,7 +3449,7 @@ std::string NMD::CEIL_W_D(uint64 instruction)
 std::string NMD::CEIL_W_S(uint64 instruction)
 {
 uint64 ft_value = extract_ft_20_19_18_17_16(instruction);
-uint64 fs_value = extract_fs_15_14_13_12_11(instruction);
+uint64 fs_value = extract_fs_20_19_18_17_16(instruction);
 
 std::string ft = FPR(copy(ft_value));
 std::string fs = FPR(copy(fs_value));
@@ -3515,7 +3515,7 @@ std::string NMD::CFC2(uint64 instruction)
 std::string NMD::CLASS_D(uint64 instruction)
 {
 uint64 ft_value = extract_ft_20_19_18_17_16(instruction);
-uint64 fs_value = extract_fs_15_14_13_12_11(instruction);
+uint64 fs_value = extract_fs_20_19_18_17_16(instruction);
 
 std::string ft = FPR(copy(ft_value));
 std::string fs = FPR(copy(fs_value));
@@ -3537,7 +3537,7 @@ std::string NMD::CLASS_D(uint64 instruction)
 std::string NMD::CLASS_S(uint64 instruction)
 {
 uint64 ft_value = extract_ft_20_19_18_17_16(instruction);
-uint64 fs_value = extract_fs_15_14_13_12_11(instruction);
+uint64 fs_value = extract_fs_20_19_18_17_16(instruction);
 
 std::string ft = FPR(copy(ft_value));
 std::string fs = FPR(copy(fs_value));
@@ -3603,7 +3603,7 @@ std::string NMD::CLZ(uint64 instruction)
 std::string NMD::CMP_AF_D(uint64 instruction)
 {
 uint64 ft_value = extract_ft_20_19_18_17_16(instruction);
-uint64 fs_value = extract_fs_15_14_13_12_11(instruction);
+uint64 fs_value = ext

[Qemu-devel] [PULL 35/41] disas: nanoMIPS: Comment the decoder of 'gpr1' gpr encoding type

[Aleksandar Markovic]

From: Aleksandar Markovic 

Comment the decoder of 'gpr1' gpr encoding type in nanoMIPS
disassembler.

Reviewed-by: Aleksandar Rikalo 
Signed-off-by: Aleksandar Markovic 
---
 disas/nanomips.cpp | 21 +
 1 file changed, 21 insertions(+)

diff --git a/disas/nanomips.cpp b/disas/nanomips.cpp
index 6f15821..23556b4 100644
--- a/disas/nanomips.cpp
+++ b/disas/nanomips.cpp
@@ -389,6 +389,27 @@ uint64 NMD::decode_gpr_gpr3_src_store(uint64 d)
 }
 
 
+/*
+ * NMD::decode_gpr_gpr1() - decoder for 'gpr1' gpr encoding type
+ *
+ *   Map a 1-bit code to the 5-bit register space according to this pattern:
+ *
+ *  1 0
+ *  | |
+ *  | |
+ *  | └-┐
+ *  └-┐ |
+ *| |
+ *| |
+ *| |
+ *| |
+ *1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+ *  3   2   1   0
+ *
+ *   Used in handling following instruction:
+ *
+ * - MOVE.BALC
+ */
 uint64 NMD::decode_gpr_gpr1(uint64 d)
 {
 static uint64 register_list[] = {  4,  5 };
-- 
2.7.4

[Qemu-devel] [PULL 29/41] disas: nanoMIPS: Comment the decoder of 'gpr4.zero' gpr encoding type

[Aleksandar Markovic]

From: Aleksandar Markovic 

Comment the decoder of 'gpr4.zero' gpr encoding type in nanoMIPS
disassembler.

Reviewed-by: Aleksandar Rikalo 
Signed-off-by: Aleksandar Markovic 
---
 disas/nanomips.cpp | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/disas/nanomips.cpp b/disas/nanomips.cpp
index 66b1223..de96125 100644
--- a/disas/nanomips.cpp
+++ b/disas/nanomips.cpp
@@ -397,6 +397,33 @@ uint64 NMD::encode_rd1_from_rd(uint64 d)
 }
 
 
+/*
+ * NMD::decode_gpr_gpr4_zero() - decoder for 'gpr4.zero' gpr encoding type
+ *
+ *   Map a 4-bit code to the 5-bit register space according to this pattern:
+ *
+ *  1   0
+ *5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+ *| | | | | | | | | | | | | | | |
+ *| | | | | | | | | | | | └-┐
+ *| | | | | | | | | | | └---┐   |
+ *| | | | | | | | | | └---┐ |   |
+ *| | | | | | | | | └---┐ | |   |
+ *| | | | | | | | └---┐ | | |   |
+ *| | | | | | | |   | | | | | | |   |
+ *| | | | | | | |   | | | | | | |   |
+ *1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+ *  3   2   1   0
+ *
+ *   This pattern is the same one used for 'gpr4' gpr encoding type, except for
+ * the input value 3, that is mapped to the output value 0 instead of 11.
+ *
+ *   Used in handling following instructions:
+ *
+ * - MOVE.BALC
+ * - MOVEP
+ * - SW[4X4]
+ */
 uint64 NMD::decode_gpr_gpr4_zero(uint64 d)
 {
 static uint64 register_list[] = {  8,  9, 10,  0,  4,  5,  6,  7,
-- 
2.7.4

[Qemu-devel] [PULL 31/41] disas: nanoMIPS: Comment the decoder of 'gpr2.reg1' gpr encoding type

[Aleksandar Markovic]

From: Aleksandar Markovic 

Comment the decoder of 'gpr2.reg1' gpr encoding type in nanoMIPS
disassembler.

Reviewed-by: Aleksandar Rikalo 
Signed-off-by: Aleksandar Markovic 
---
 disas/nanomips.cpp | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/disas/nanomips.cpp b/disas/nanomips.cpp
index b0d0cf8..c3b2bec 100644
--- a/disas/nanomips.cpp
+++ b/disas/nanomips.cpp
@@ -468,6 +468,28 @@ uint64 NMD::decode_gpr_gpr4(uint64 d)
 }
 
 
+/*
+ * NMD::decode_gpr_gpr2_reg1() - decoder for 'gpr2.reg1' gpr encoding type
+ *
+ *   Map a 2-bit code to the 5-bit register space according to this pattern:
+ *
+ *3 2 1 0
+ *| | | |
+ *| | | |
+ *| | | └---┐
+ *| | └---┐ |
+ *| └---┐ | |
+ *└---┐ | | |
+ *| | | |
+ *| | | |
+ *1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+ *  3   2   1   0
+ *
+ *   Used in handling following instructions:
+ *
+ * - MOVEP
+ * - MOVEP[REV]
+ */
 uint64 NMD::decode_gpr_gpr2_reg1(uint64 d)
 {
 static uint64 register_list[] = {  4,  5,  6,  7 };
-- 
2.7.4

[Qemu-devel] [PULL 39/41] tests/tcg: mips: Test R5900 three-operand MADD1

[Aleksandar Markovic]

From: Fredrik Noring 

Test R5900 three-operand MADD1.

Reviewed-by: Aleksandar Markovic 
Signed-off-by: Aleksandar Markovic 
Signed-off-by: Fredrik Noring 
---
 tests/tcg/mips/mipsr5900/madd.c | 43 -
 1 file changed, 38 insertions(+), 5 deletions(-)

diff --git a/tests/tcg/mips/mipsr5900/madd.c b/tests/tcg/mips/mipsr5900/madd.c
index 9ad2ea6..f6f215e 100644
--- a/tests/tcg/mips/mipsr5900/madd.c
+++ b/tests/tcg/mips/mipsr5900/madd.c
@@ -1,5 +1,5 @@
 /*
- * Test R5900-specific three-operand MADD.
+ * Test R5900-specific three-operand MADD and MADD1.
  */
 
 #include 
@@ -29,12 +29,45 @@ int64_t madd(int64_t a, int32_t rs, int32_t rt)
 return r;
 }
 
+int64_t madd1(int64_t a, int32_t rs, int32_t rt)
+{
+int32_t lo = a;
+int32_t hi = a >> 32;
+int32_t rd;
+int64_t r;
+
+__asm__ __volatile__ (
+"mtlo1 %5\n"
+"mthi1 %6\n"
+"madd1 %0, %3, %4\n"
+"mflo1 %1\n"
+"mfhi1 %2\n"
+: "=r" (rd), "=r" (lo), "=r" (hi)
+: "r" (rs), "r" (rt), "r" (lo), "r" (hi));
+r = ((int64_t)hi << 32) | (uint32_t)lo;
+
+assert(a + (int64_t)rs * rt == r);
+assert(rd == lo);
+
+return r;
+}
+
+static int64_t madd_variants(int64_t a, int32_t rs, int32_t rt)
+{
+int64_t rd  = madd(a, rs, rt);
+int64_t rd1 = madd1(a, rs, rt);
+
+assert(rd == rd1);
+
+return rd;
+}
+
 static void verify_madd(int64_t a, int32_t rs, int32_t rt, int64_t expected)
 {
-assert(madd(a, rs, rt) == expected);
-assert(madd(a, -rs, rt) == a + a - expected);
-assert(madd(a, rs, -rt) == a + a - expected);
-assert(madd(a, -rs, -rt) == expected);
+assert(madd_variants(a, rs, rt) == expected);
+assert(madd_variants(a, -rs, rt) == a + a - expected);
+assert(madd_variants(a, rs, -rt) == a + a - expected);
+assert(madd_variants(a, -rs, -rt) == expected);
 }
 
 int main()
-- 
2.7.4

Re: [Qemu-devel] [PATCH 0/2] tests: Reorganize MIPS TCG directories and files

[Aleksandar Markovic]

> From: Philippe Mathieu-Daudé  on behalf of 
> Philippe Mathieu-Daudé 
> Subject: Re: [Qemu-devel] [PATCH 0/2] tests: Reorganize MIPS TCG directories 
> and files
> 
> Hi Aleksandar,
>
> It seems the list ate your patch 1/2...

Thanks for bringing this to my attention, but not a big deal, I will anyway 
send better v2 after New Year.

Aleksandar

[Qemu-devel] [PULL 36/41] disas: nanoMIPS: Reorder declarations and definitions of gpr decoders

[Aleksandar Markovic]

From: Aleksandar Markovic 

Reorder declarations and definitions of gpr decoders by number of
input bits of corresponding encoding type.

Reviewed-by: Aleksandar Rikalo 
Signed-off-by: Aleksandar Markovic 
---
 disas/nanomips.cpp | 200 ++---
 disas/nanomips.h   |   7 +-
 2 files changed, 104 insertions(+), 103 deletions(-)

diff --git a/disas/nanomips.cpp b/disas/nanomips.cpp
index 23556b4..d6632bb 100644
--- a/disas/nanomips.cpp
+++ b/disas/nanomips.cpp
@@ -292,6 +292,77 @@ uint64 NMD::renumber_registers(uint64 index, uint64 
*register_list,
 
 
 /*
+ * NMD::decode_gpr_gpr4() - decoder for 'gpr4' gpr encoding type
+ *
+ *   Map a 4-bit code to the 5-bit register space according to this pattern:
+ *
+ *  1   0
+ *5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+ *| | | | | | | | | | | | | | | |
+ *| | | | | | | | | | | | | | | |
+ *| | | | | | | | | | | └---┐
+ *| | | | | | | | | | └---┐ |
+ *| | | | | | | | | └---┐ | |
+ *| | | | | | | | └---┐ | | |
+ *| | | | | | | | | | | | | | | |
+ *| | | | | | | | | | | | | | | |
+ *1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+ *  3   2   1   0
+ *
+ *   Used in handling following instructions:
+ *
+ * - ADDU[4X4]
+ * - LW[4X4]
+ * - MOVEP[REV]
+ * - MUL[4X4]
+ * - SW[4X4]
+ */
+uint64 NMD::decode_gpr_gpr4(uint64 d)
+{
+static uint64 register_list[] = {  8,  9, 10, 11,  4,  5,  6,  7,
+  16, 17, 18, 19, 20, 21, 22, 23 };
+return renumber_registers(d, register_list,
+   sizeof(register_list) / sizeof(register_list[0]));
+}
+
+
+/*
+ * NMD::decode_gpr_gpr4_zero() - decoder for 'gpr4.zero' gpr encoding type
+ *
+ *   Map a 4-bit code to the 5-bit register space according to this pattern:
+ *
+ *  1   0
+ *5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+ *| | | | | | | | | | | | | | | |
+ *| | | | | | | | | | | | └-┐
+ *| | | | | | | | | | | └---┐   |
+ *| | | | | | | | | | └---┐ |   |
+ *| | | | | | | | | └---┐ | |   |
+ *| | | | | | | | └---┐ | | |   |
+ *| | | | | | | |   | | | | | | |   |
+ *| | | | | | | |   | | | | | | |   |
+ *1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+ *  3   2   1   0
+ *
+ *   This pattern is the same one used for 'gpr4' gpr encoding type, except for
+ * the input value 3, that is mapped to the output value 0 instead of 11.
+ *
+ *   Used in handling following instructions:
+ *
+ * - MOVE.BALC
+ * - MOVEP
+ * - SW[4X4]
+ */
+uint64 NMD::decode_gpr_gpr4_zero(uint64 d)
+{
+static uint64 register_list[] = {  8,  9, 10,  0,  4,  5,  6,  7,
+  16, 17, 18, 19, 20, 21, 22, 23 };
+return renumber_registers(d, register_list,
+   sizeof(register_list) / sizeof(register_list[0]));
+}
+
+
+/*
  * NMD::decode_gpr_gpr3() - decoder for 'gpr3' gpr encoding type
  *
  *   Map a 3-bit code to the 5-bit register space according to this pattern:
@@ -390,106 +461,6 @@ uint64 NMD::decode_gpr_gpr3_src_store(uint64 d)
 
 
 /*
- * NMD::decode_gpr_gpr1() - decoder for 'gpr1' gpr encoding type
- *
- *   Map a 1-bit code to the 5-bit register space according to this pattern:
- *
- *  1 0
- *  | |
- *  | |
- *  | └-┐
- *  └-┐ |
- *| |
- *| |
- *| |
- *| |
- *1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
- *  3   2   1   0
- *
- *   Used in handling following instruction:
- *
- * - MOVE.BALC
- */
-uint64 NMD::decode_gpr_gpr1(uint64 d)
-{
-static uint64 register_list[] = {  4,  5 };
-return renumber_registers(d, register_list,
-   sizeof(register_list) / sizeof(register_list[0]));
-}
-
-
-/*
- * NMD::decode_gpr_gpr4_zero() - decoder for 'gpr4.zero' gpr encoding type
- *
- *   Map a 4-bit code to the 5-bit register space according to this pattern:

[Qemu-devel] [PULL 33/41] disas: nanoMIPS: Comment the decoder of 'gpr2.reg2' gpr encoding type

[Aleksandar Markovic]

From: Aleksandar Markovic 

Comment the decoder of 'gpr2.reg2' gpr encoding type in nanoMIPS
disassembler.

Reviewed-by: Aleksandar Rikalo 
Signed-off-by: Aleksandar Markovic 
---
 disas/nanomips.cpp | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/disas/nanomips.cpp b/disas/nanomips.cpp
index 06d2400..fe0c4af 100644
--- a/disas/nanomips.cpp
+++ b/disas/nanomips.cpp
@@ -498,6 +498,28 @@ uint64 NMD::decode_gpr_gpr2_reg1(uint64 d)
 }
 
 
+/*
+ * NMD::decode_gpr_gpr2_reg2() - decoder for 'gpr2.reg2' gpr encoding type
+ *
+ *   Map a 2-bit code to the 5-bit register space according to this pattern:
+ *
+ *3 2 1 0
+ *| | | |
+ *| | | |
+ *| | | └-┐
+ *| | └-┐ |
+ *| └-┐ | |
+ *└-┐ | | |
+ *  | | | |
+ *  | | | |
+ *1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+ *  3   2   1   0
+ *
+ *   Used in handling following instructions:
+ *
+ * - MOVEP
+ * - MOVEP[REV]
+ */
 uint64 NMD::decode_gpr_gpr2_reg2(uint64 d)
 {
 static uint64 register_list[] = {  5,  6,  7,  8 };
-- 
2.7.4

[Qemu-devel] [PULL 30/41] disas: nanoMIPS: Rename the decoder of 'gpr2.reg1' gpr encoding type

[Aleksandar Markovic]

From: Aleksandar Markovic 

Rename the decoder of 'gpr2.reg1' gpr encoding type in nanoMIPS
disassembler.

Reviewed-by: Aleksandar Rikalo 
Signed-off-by: Aleksandar Markovic 
---
 disas/nanomips.cpp | 6 +++---
 disas/nanomips.h   | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/disas/nanomips.cpp b/disas/nanomips.cpp
index de96125..b0d0cf8 100644
--- a/disas/nanomips.cpp
+++ b/disas/nanomips.cpp
@@ -468,7 +468,7 @@ uint64 NMD::decode_gpr_gpr4(uint64 d)
 }
 
 
-uint64 NMD::encode_rd2_reg1(uint64 d)
+uint64 NMD::decode_gpr_gpr2_reg1(uint64 d)
 {
 static uint64 register_list[] = {  4,  5,  6,  7 };
 return renumber_registers(d, register_list,
@@ -10445,7 +10445,7 @@ std::string NMD::MOVEP(uint64 instruction)
 uint64 rd2_value = extract_rd2_3_8(instruction);
 uint64 rsz4_value = extract_rsz4_4_2_1_0(instruction);
 
-std::string rd2 = GPR(encode_rd2_reg1(rd2_value));
+std::string rd2 = GPR(decode_gpr_gpr2_reg1(rd2_value));
 std::string re2 = GPR(encode_rd2_reg2(rd2_value));
 /* !! - no conversion function */
 std::string rsz4 = GPR(decode_gpr_gpr4_zero(rsz4_value));
@@ -10474,7 +10474,7 @@ std::string NMD::MOVEP_REV_(uint64 instruction)
 
 std::string rs4 = GPR(decode_gpr_gpr4(rs4_value));
 std::string rt4 = GPR(decode_gpr_gpr4(rt4_value));
-std::string rd2 = GPR(encode_rd2_reg1(rd2_value));
+std::string rd2 = GPR(decode_gpr_gpr2_reg1(rd2_value));
 std::string rs2 = GPR(encode_rd2_reg2(rd2_value));
 /* !! - no conversion function */
 
diff --git a/disas/nanomips.h b/disas/nanomips.h
index c1d3a3b..d928757 100644
--- a/disas/nanomips.h
+++ b/disas/nanomips.h
@@ -110,7 +110,7 @@ private:
 uint64 encode_rd1_from_rd(uint64 d);
 uint64 decode_gpr_gpr4_zero(uint64 d);
 uint64 decode_gpr_gpr4(uint64 d);
-uint64 encode_rd2_reg1(uint64 d);
+uint64 decode_gpr_gpr2_reg1(uint64 d);
 uint64 encode_rd2_reg2(uint64 d);
 
 uint64 copy(uint64 d);
-- 
2.7.4

[Qemu-devel] [PULL 40/41] tests/tcg: mips: Test R5900 three-operand MADDU

[Aleksandar Markovic]

From: Fredrik Noring 

Test R5900 three-operand MADDU.

Reviewed-by: Aleksandar Markovic 
Signed-off-by: Aleksandar Markovic 
Signed-off-by: Fredrik Noring 
---
 tests/tcg/mips/mipsr5900/Makefile |  1 +
 tests/tcg/mips/mipsr5900/maddu.c  | 37 +
 2 files changed, 38 insertions(+)
 create mode 100644 tests/tcg/mips/mipsr5900/maddu.c

diff --git a/tests/tcg/mips/mipsr5900/Makefile 
b/tests/tcg/mips/mipsr5900/Makefile
index 97ca2a6..27ee5d5 100644
--- a/tests/tcg/mips/mipsr5900/Makefile
+++ b/tests/tcg/mips/mipsr5900/Makefile
@@ -11,6 +11,7 @@ CFLAGS  = -Wall -mabi=32 -march=r5900 -static
 TESTCASES = div1.tst
 TESTCASES += divu1.tst
 TESTCASES += madd.tst
+TESTCASES += maddu.tst
 TESTCASES += mflohi1.tst
 TESTCASES += mtlohi1.tst
 TESTCASES += mult.tst
diff --git a/tests/tcg/mips/mipsr5900/maddu.c b/tests/tcg/mips/mipsr5900/maddu.c
new file mode 100644
index 000..e4e5521
--- /dev/null
+++ b/tests/tcg/mips/mipsr5900/maddu.c
@@ -0,0 +1,37 @@
+/*
+ * Test R5900-specific three-operand MADDU.
+ */
+
+#include 
+#include 
+#include 
+
+uint64_t maddu(uint64_t a, uint32_t rs, uint32_t rt)
+{
+uint32_t lo = a;
+uint32_t hi = a >> 32;
+uint32_t rd;
+uint64_t r;
+
+__asm__ __volatile__ (
+"mtlo  %5\n"
+"mthi  %6\n"
+"maddu %0, %3, %4\n"
+"mflo  %1\n"
+"mfhi  %2\n"
+: "=r" (rd), "=r" (lo), "=r" (hi)
+: "r" (rs), "r" (rt), "r" (lo), "r" (hi));
+r = ((uint64_t)hi << 32) | (uint32_t)lo;
+
+assert(a + (uint64_t)rs * rt == r);
+assert(rd == lo);
+
+return r;
+}
+
+int main()
+{
+assert(maddu(13, 17, 19) == 336);
+
+return 0;
+}
-- 
2.7.4

[Qemu-devel] [PULL 41/41] tests/tcg: mips: Test R5900 three-operand MADDU1

[Aleksandar Markovic]

From: Fredrik Noring 

Test R5900 three-operand MADDU1.

Reviewed-by: Aleksandar Markovic 
Signed-off-by: Aleksandar Markovic 
Signed-off-by: Fredrik Noring 
---
 tests/tcg/mips/mipsr5900/maddu.c | 37 +++--
 1 file changed, 35 insertions(+), 2 deletions(-)

diff --git a/tests/tcg/mips/mipsr5900/maddu.c b/tests/tcg/mips/mipsr5900/maddu.c
index e4e5521..30936fb 100644
--- a/tests/tcg/mips/mipsr5900/maddu.c
+++ b/tests/tcg/mips/mipsr5900/maddu.c
@@ -1,5 +1,5 @@
 /*
- * Test R5900-specific three-operand MADDU.
+ * Test R5900-specific three-operand MADDU and MADDU1.
  */
 
 #include 
@@ -29,9 +29,42 @@ uint64_t maddu(uint64_t a, uint32_t rs, uint32_t rt)
 return r;
 }
 
+uint64_t maddu1(uint64_t a, uint32_t rs, uint32_t rt)
+{
+uint32_t lo = a;
+uint32_t hi = a >> 32;
+uint32_t rd;
+uint64_t r;
+
+__asm__ __volatile__ (
+"mtlo1  %5\n"
+"mthi1  %6\n"
+"maddu1 %0, %3, %4\n"
+"mflo1  %1\n"
+"mfhi1  %2\n"
+: "=r" (rd), "=r" (lo), "=r" (hi)
+: "r" (rs), "r" (rt), "r" (lo), "r" (hi));
+r = ((uint64_t)hi << 32) | (uint32_t)lo;
+
+assert(a + (uint64_t)rs * rt == r);
+assert(rd == lo);
+
+return r;
+}
+
+static int64_t maddu_variants(int64_t a, int32_t rs, int32_t rt)
+{
+int64_t rd  = maddu(a, rs, rt);
+int64_t rd1 = maddu1(a, rs, rt);
+
+assert(rd == rd1);
+
+return rd;
+}
+
 int main()
 {
-assert(maddu(13, 17, 19) == 336);
+assert(maddu_variants(13, 17, 19) == 336);
 
 return 0;
 }
-- 
2.7.4

[Qemu-devel] [PULL 37/41] disas: nanoMIPS: Add a note on documentation

[Aleksandar Markovic]

From: Aleksandar Markovic 

Add "nanoMIPS32 Instruction Set Technical Reference Manual" as
a reference.

Reviewed-by: Aleksandar Rikalo 
Signed-off-by: Aleksandar Markovic 
---
 disas/nanomips.cpp | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/disas/nanomips.cpp b/disas/nanomips.cpp
index d6632bb..17f4c22 100644
--- a/disas/nanomips.cpp
+++ b/disas/nanomips.cpp
@@ -20,6 +20,13 @@
  *
  */
 
+/*
+ *  Documentation used while implementing this component:
+ *
+ *  [1] "MIPS® Architecture Base: nanoMIPS32(tm) Instruction Set Technical
+ *  Reference Manual", Revision 01.01, April 27, 2018
+ */
+
 extern "C" {
 #include "qemu/osdep.h"
 #include "disas/bfd.h"
-- 
2.7.4

[Qemu-devel] [PULL 34/41] disas: nanoMIPS: Rename the decoder of 'gpr1' gpr encoding type

[Aleksandar Markovic]

From: Aleksandar Markovic 

Rename the decoder of 'gpr1' gpr encoding type in nanoMIPS
disassembler.

Reviewed-by: Aleksandar Rikalo 
Signed-off-by: Aleksandar Markovic 
---
 disas/nanomips.cpp | 4 ++--
 disas/nanomips.h   | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/disas/nanomips.cpp b/disas/nanomips.cpp
index fe0c4af..6f15821 100644
--- a/disas/nanomips.cpp
+++ b/disas/nanomips.cpp
@@ -389,7 +389,7 @@ uint64 NMD::decode_gpr_gpr3_src_store(uint64 d)
 }
 
 
-uint64 NMD::encode_rd1_from_rd(uint64 d)
+uint64 NMD::decode_gpr_gpr1(uint64 d)
 {
 static uint64 register_list[] = {  4,  5 };
 return renumber_registers(d, register_list,
@@ -10465,7 +10465,7 @@ std::string NMD::MOVE_BALC(uint64 instruction)
 uint64 rd1_value = extract_rdl_25_24(instruction);
 int64 s_value = extract_s__se21_0_20_to_1_s1(instruction);
 
-std::string rd1 = GPR(encode_rd1_from_rd(rd1_value));
+std::string rd1 = GPR(decode_gpr_gpr1(rd1_value));
 std::string rtz4 = GPR(decode_gpr_gpr4_zero(rtz4_value));
 std::string s = ADDRESS(encode_s_from_address(s_value), 4);
 
diff --git a/disas/nanomips.h b/disas/nanomips.h
index 9df1ab2..d6a6e3f 100644
--- a/disas/nanomips.h
+++ b/disas/nanomips.h
@@ -107,7 +107,7 @@ private:
   size_t register_list_size);
 uint64 decode_gpr_gpr3(uint64 d);
 uint64 decode_gpr_gpr3_src_store(uint64 d);
-uint64 encode_rd1_from_rd(uint64 d);
+uint64 decode_gpr_gpr1(uint64 d);
 uint64 decode_gpr_gpr4_zero(uint64 d);
 uint64 decode_gpr_gpr4(uint64 d);
 uint64 decode_gpr_gpr2_reg1(uint64 d);
-- 
2.7.4

[Qemu-devel] [PULL 32/41] disas: nanoMIPS: Rename the decoder of 'gpr2.reg2' gpr encoding type

[Aleksandar Markovic]

From: Aleksandar Markovic 

Rename the decoder of 'gpr2.reg2' gpr encoding type in nanoMIPS
disassembler.

Reviewed-by: Aleksandar Rikalo 
Signed-off-by: Aleksandar Markovic 
---
 disas/nanomips.cpp | 6 +++---
 disas/nanomips.h   | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/disas/nanomips.cpp b/disas/nanomips.cpp
index c3b2bec..06d2400 100644
--- a/disas/nanomips.cpp
+++ b/disas/nanomips.cpp
@@ -498,7 +498,7 @@ uint64 NMD::decode_gpr_gpr2_reg1(uint64 d)
 }
 
 
-uint64 NMD::encode_rd2_reg2(uint64 d)
+uint64 NMD::decode_gpr_gpr2_reg2(uint64 d)
 {
 static uint64 register_list[] = {  5,  6,  7,  8 };
 return renumber_registers(d, register_list,
@@ -10468,7 +10468,7 @@ std::string NMD::MOVEP(uint64 instruction)
 uint64 rsz4_value = extract_rsz4_4_2_1_0(instruction);
 
 std::string rd2 = GPR(decode_gpr_gpr2_reg1(rd2_value));
-std::string re2 = GPR(encode_rd2_reg2(rd2_value));
+std::string re2 = GPR(decode_gpr_gpr2_reg2(rd2_value));
 /* !! - no conversion function */
 std::string rsz4 = GPR(decode_gpr_gpr4_zero(rsz4_value));
 std::string rtz4 = GPR(decode_gpr_gpr4_zero(rtz4_value));
@@ -10497,7 +10497,7 @@ std::string NMD::MOVEP_REV_(uint64 instruction)
 std::string rs4 = GPR(decode_gpr_gpr4(rs4_value));
 std::string rt4 = GPR(decode_gpr_gpr4(rt4_value));
 std::string rd2 = GPR(decode_gpr_gpr2_reg1(rd2_value));
-std::string rs2 = GPR(encode_rd2_reg2(rd2_value));
+std::string rs2 = GPR(decode_gpr_gpr2_reg2(rd2_value));
 /* !! - no conversion function */
 
 return img::format("MOVEP %s, %s, %s, %s", rs4, rt4, rd2, rs2);
diff --git a/disas/nanomips.h b/disas/nanomips.h
index d928757..9df1ab2 100644
--- a/disas/nanomips.h
+++ b/disas/nanomips.h
@@ -111,7 +111,7 @@ private:
 uint64 decode_gpr_gpr4_zero(uint64 d);
 uint64 decode_gpr_gpr4(uint64 d);
 uint64 decode_gpr_gpr2_reg1(uint64 d);
-uint64 encode_rd2_reg2(uint64 d);
+uint64 decode_gpr_gpr2_reg2(uint64 d);
 
 uint64 copy(uint64 d);
 int64 copy(int64 d);
-- 
2.7.4

Re: [Qemu-devel] [RFC PATCH 04/13] tests/tcg/mips: enable mips32-dsp/mips32-dspr2/mipsr5900 linux-user (WIP)

[Alex Bennée]

Aleksandar Markovic  writes:

> HI, Alex, just a heads up that I plan to submit directory and file
> reorganization of tests/tcg/mips mini patch series today or tomorrow.
> Aleksandar

My current tree state is:

  https://github.com/stsquad/qemu/tree/testing/enable-system-tcg-tests-v2

But I'm still having trouble generating nicely linked no-pic code. But
I'll happily re-base after you've re-organised the tree. Will you be
testing the build as is with the current Makefiles?

>
> On Wednesday, December 19, 2018, Alex Bennée  wrote:
>
>>
>> Aleksandar Markovic  writes:
>>
>> > On Dec 10, 2018 4:29 PM, "Alex Bennée"  wrote:
>> >>
>> >> Convert the existing tests to use our common cross build
>> >> infrastructure.
>> >>
>> >> [WIP: mips32r2 disabled to avoid name clash]
>> >> [WIP: mipsr5900 disabled due to clashing build flags]
>> >>
>> >> Signed-off-by: Alex Bennée 
>> >> ---
>> >>  tests/tcg/mips/Makefile.target   |  15 ++-
>> >>  tests/tcg/mips/mips32-dsp/Makefile   | 166 +--
>> >>  tests/tcg/mips/mips32-dspr2/Makefile |  83 +++---
>> >>  tests/tcg/mips/mipsr5900/Makefile|  40 +++
>> >>  4 files changed, 75 insertions(+), 229 deletions(-)
>> >>
>> >
>> > Alex,
>> >
>> > How about reorganizing directories in tests/tcg/mips altogether, and make
>> > it less confusing, and easier for future developers to approach an work
>> on?
>> >
>> > Let's say like this:
>> >
>> > tests/tcg/mips
>> > user
>> > isa
>> > r5900
>> > ase
>> > dsp
>> > dsp_r2
>> > system
>> > isa   《for now empty》
>> > ase
>> > dsp
>> > dsp_r2
>>
>> Yeah sounds like a plan. I'm going to do the same with cris (bare and
>> libc).
>>
>> >
>> > Thanks,
>> > Aleksandar
>>
>>
>> --
>> Alex Bennée
>>


--
Alex Bennée

Re: [Qemu-devel] d_off field in struct dirent and 32-on-64 emulation

[Peter Maydell]

On Fri, 28 Dec 2018 at 00:23, Andreas Dilger  wrote:
> On Dec 27, 2018, at 10:41 AM, Peter Maydell  wrote:
> > As you note, this causes breakage for userspace programs which
> > need to implement an API/ABI with 32-bit offset but which only
> > have access to the kernel's 64-bit offset API/ABI.
>
> This is (IMHO) a bit of an oxymoron, isn't it?  Applications using
> the 64-bit API, but storing the value in a 32-bit field?

I didn't say "which choose to store the value in a 32-bit field",
I said "which have to implement an API/ABI which has 32-bit fields".
In QEMU's case, we use the host kernel's ABI, which has 64-bit
offset fields. We implement a syscall ABI for the guest binary
we are running under emulation, which may have 32-bit offset fields
(for instance if we are running a 32-bit Arm binary.) Both of
these ABIs are fixed -- QEMU doesn't have a choice here, it
just has to make the best effort it can with what the host kernel
provides it, to provide the semantics the guest binary needs.
My suggestion in this thread is that the host kernel provides
a wider range of facilities so that QEMU can do the job it's
trying to do.

>  The same
> problem would exist for filesystems with 64-bit inodes or 64-bit
> file offsets trying to store these values in 32-bit variables.
> It might work most of the time, but it can also break randomly.

In general inodes and offsets start from 0 and work up --
so almost all of the time they don't actually overflow.
The problem with ext4 directory hash "offsets" is that they
overflow all the time and immediately, so instead of "works
unless you have a weird edge case" like all the other filesystems,
it's "never works".

> > I think the best fix for this would be for the kernel to either
> > (a) consistently use a 32-bit hash or (b) to provide an API
> > so that userspace can use the FMODE_32BITHASH flag the way
> > that kernel-internal users already can.
>
> It would be relatively straight forward to add a "32bitapi" mount
> option to return a 32-bit directory hash to userspace for operations
> on that mountpoint (ext4 doesn't have 64-bit inode numbers yet).
> However, I can't think of an easy way to do this on a per-process
> basis without just having it call the 32-bit API directly.

The problem is that there is no 32-bit API in some cases
(unless I have misunderstood the kernel code) -- not all
host architectures implement compat syscalls or allow them
to be called from 64-bit processes or implement all the older
syscall variants that had smaller offets. If there was a guaranteed
"this syscall always exists and always gives me 32-bit offsets"
we could use it.

> For ext4 at least, you could just shift the high 32-bit part of
> the 64-bit hash down into a 32-bit value in telldir(), and
> shift it back up when seekdir() is called.

Yes, that has been suggested, but it seemed a bit dubious
to bake in knowledge of ext4's internal implementation details.
Can we rely on this as an ABI promise that will always work
for all versions of all file systems going forwards?

thanks
-- PMM

Re: [Qemu-devel] [PATCH v3 1/2] intel-iommu: differentiate host address width from IOVA address width.

[Igor Mammedov]

On Thu, 27 Dec 2018 12:54:02 -0200
Eduardo Habkost  wrote:

> On Fri, Dec 21, 2018 at 03:13:25PM +0100, Igor Mammedov wrote:
> > On Thu, 20 Dec 2018 19:18:01 -0200
> > Eduardo Habkost  wrote:
> > 
> > > On Wed, Dec 19, 2018 at 11:40:37AM +0100, Igor Mammedov wrote:
> > > > On Wed, 19 Dec 2018 10:57:17 +0800
> > > > Yu Zhang  wrote:
> > > >   
> > > > > On Tue, Dec 18, 2018 at 03:55:36PM +0100, Igor Mammedov wrote:  
> > > > > > On Tue, 18 Dec 2018 17:27:23 +0800
> > > > > > Yu Zhang  wrote:
> > > > > > 
> > > > > > > On Mon, Dec 17, 2018 at 02:17:40PM +0100, Igor Mammedov wrote:
> > > > > > > > On Wed, 12 Dec 2018 21:05:38 +0800
> > > > > > > > Yu Zhang  wrote:
> > > > > > > > 
> > > > > > > > > Currently, vIOMMU is using the value of IOVA address width, 
> > > > > > > > > instead of
> > > > > > > > > the host address width(HAW) to calculate the number of 
> > > > > > > > > reserved bits in
> > > > > > > > > data structures such as root entries, context entries, and 
> > > > > > > > > entries of
> > > > > > > > > DMA paging structures etc.
> > > > > > > > > 
> > > > > > > > > However values of IOVA address width and of the HAW may not 
> > > > > > > > > equal. For
> > > > > > > > > example, a 48-bit IOVA can only be mapped to host addresses 
> > > > > > > > > no wider than
> > > > > > > > > 46 bits. Using 48, instead of 46 to calculate the reserved 
> > > > > > > > > bit may result
> > > > > > > > > in an invalid IOVA being accepted.
> > > > > > > > > 
> > > > > > > > > To fix this, a new field - haw_bits is introduced in struct 
> > > > > > > > > IntelIOMMUState,
> > > > > > > > > whose value is initialized based on the maximum physical 
> > > > > > > > > address set to
> > > > > > > > > guest CPU.
> > > > > > > > 
> > > > > > > > > Also, definitions such as VTD_HOST_AW_39/48BIT etc. are 
> > > > > > > > > renamed
> > > > > > > > > to clarify.
> > > > > > > > > 
> > > > > > > > > Signed-off-by: Yu Zhang 
> > > > > > > > > Reviewed-by: Peter Xu 
> > > > > > > > > ---
> > > > > > > > [...]
> > > > > > > > 
> > > > > > > > > @@ -3100,6 +3104,8 @@ static void 
> > > > > > > > > vtd_iommu_replay(IOMMUMemoryRegion *iommu_mr, IOMMUNotifier 
> > > > > > > > > *n)
> > > > > > > > >  static void vtd_init(IntelIOMMUState *s)
> > > > > > > > >  {
> > > > > > > > >  X86IOMMUState *x86_iommu = X86_IOMMU_DEVICE(s);
> > > > > > > > > +CPUState *cs = first_cpu;
> > > > > > > > > +X86CPU *cpu = X86_CPU(cs);
> > > > > > > > >  
> > > > > > > > >  memset(s->csr, 0, DMAR_REG_SIZE);
> > > > > > > > >  memset(s->wmask, 0, DMAR_REG_SIZE);
> > > > > > > > > @@ -3119,23 +3125,24 @@ static void vtd_init(IntelIOMMUState 
> > > > > > > > > *s)
> > > > > > > > >  s->cap = VTD_CAP_FRO | VTD_CAP_NFR | VTD_CAP_ND |
> > > > > > > > >   VTD_CAP_MAMV | VTD_CAP_PSI | VTD_CAP_SLLPS |
> > > > > > > > >   VTD_CAP_SAGAW_39bit | VTD_CAP_MGAW(s->aw_bits);
> > > > > > > > > -if (s->aw_bits == VTD_HOST_AW_48BIT) {
> > > > > > > > > +if (s->aw_bits == VTD_AW_48BIT) {
> > > > > > > > >  s->cap |= VTD_CAP_SAGAW_48bit;
> > > > > > > > >  }
> > > > > > > > >  s->ecap = VTD_ECAP_QI | VTD_ECAP_IRO;
> > > > > > > > > +s->haw_bits = cpu->phys_bits;
> > > > > > > > Is it possible to avoid accessing CPU fields directly or cpu 
> > > > > > > > altogether
> > > > > > > > and set phys_bits when iommu is created?
> > > > > > > 
> > > > > > > Thanks for your comments, Igor.
> > > > > > > 
> > > > > > > Well, I guess you prefer not to query the CPU capabilities while 
> > > > > > > deciding
> > > > > > > the vIOMMU features. But to me, they are not that irrelevant.:)
> > > > > > > 
> > > > > > > Here the hardware address width in vt-d, and the one in 
> > > > > > > cpuid.MAXPHYSADDR
> > > > > > > are referring to the same concept. In VM, both are the maximum 
> > > > > > > guest physical
> > > > > > > address width. If we do not check the CPU field here, we will 
> > > > > > > still have to
> > > > > > > check the CPU field in other places such as build_dmar_q35(), and 
> > > > > > > reset the
> > > > > > > s->haw_bits again.
> > > > > > > 
> > > > > > > Is this explanation convincing enough? :)
> > > > > > current build_dmar_q35() doesn't do it, it's all new code in this 
> > > > > > series that
> > > > > > contains not acceptable direct access from one device (iommu) to 
> > > > > > another (cpu).   
> > > > > > Proper way would be for the owner of iommu to fish limits from 
> > > > > > somewhere and set
> > > > > > values during iommu creation.
> > > > > 
> > > > > Well, current build_dmar_q35() doesn't do it, because it is using the 
> > > > > incorrect value. :)
> > > > > According to the spec, the host address width is the maximum physical 
> > > > > address width,
> > > > > yet current implementation is using the DMA address width. For me, 
> > > > > this is not only
> > > > > wrong, but also unsecure. For this point, I think we all agree th

Re: [Qemu-devel] d_off field in struct dirent and 32-on-64 emulation

[Florian Weimer]

* Florian Weimer:

> * Adhemerval Zanella:
>
>> On 27/12/2018 16:09, Florian Weimer wrote:
>>> * Adhemerval Zanella:
>>> 
 Also for glibc standpoint, although reverting it back to use getdents 
 syscall for non-LFS mode might fix this issue for architectures that
 provides non-LFS getdents syscall it won't be a fix for architectures 
 that still provides off_t different than off64_t *and* only provides 
 getdents64 syscall.

 Currently we only have nios2 and csky (unfortunately).  But since generic 
 definition for off_t and off64_t still assumes non-LFS support, all new
 32-bits ports potentially might carry the issue.
>>> 
>>> For csky, we could still change the type of the non-standard d_off
>>> field to long long int.  This way, only telldir would have to fail
>>> when truncation is necessary, as mentioned below:
>>
>> I think it makes no sense to continue making non-LFS as default for
>> newer 32 bits ports, the support will be emulated with LFS syscalls.
>
> Sorry, I don't see how this matters.  seekdir and telldir are NOT
> affected by LFS.

Ah, right.  If struct dirent is 64-bit only, then the d_off member
will be 64 bits as well.  But it is unclear whether you can use that
with lseek (probably yes, in its 64-bit variant), and it's unlikely
it's going to work with seekdir because of the POSIX-required long int
type.

Re: [Qemu-devel] d_off field in struct dirent and 32-on-64 emulation

[Florian Weimer]

* Adhemerval Zanella:

> On 27/12/2018 16:09, Florian Weimer wrote:
>> * Adhemerval Zanella:
>> 
>>> Also for glibc standpoint, although reverting it back to use getdents 
>>> syscall for non-LFS mode might fix this issue for architectures that
>>> provides non-LFS getdents syscall it won't be a fix for architectures 
>>> that still provides off_t different than off64_t *and* only provides 
>>> getdents64 syscall.
>>>
>>> Currently we only have nios2 and csky (unfortunately).  But since generic 
>>> definition for off_t and off64_t still assumes non-LFS support, all new
>>> 32-bits ports potentially might carry the issue.
>> 
>> For csky, we could still change the type of the non-standard d_off
>> field to long long int.  This way, only telldir would have to fail
>> when truncation is necessary, as mentioned below:
>
> I think it makes no sense to continue making non-LFS as default for
> newer 32 bits ports, the support will be emulated with LFS syscalls.

Sorry, I don't see how this matters.  seekdir and telldir are NOT
affected by LFS.

Re: [Qemu-devel] d_off field in struct dirent and 32-on-64 emulation

[Adhemerval Zanella]

On 27/12/2018 16:09, Florian Weimer wrote:
> * Adhemerval Zanella:
> 
>> Also for glibc standpoint, although reverting it back to use getdents 
>> syscall for non-LFS mode might fix this issue for architectures that
>> provides non-LFS getdents syscall it won't be a fix for architectures 
>> that still provides off_t different than off64_t *and* only provides 
>> getdents64 syscall.
>>
>> Currently we only have nios2 and csky (unfortunately).  But since generic 
>> definition for off_t and off64_t still assumes non-LFS support, all new
>> 32-bits ports potentially might carry the issue.
> 
> For csky, we could still change the type of the non-standard d_off
> field to long long int.  This way, only telldir would have to fail
> when truncation is necessary, as mentioned below:

I think it makes no sense to continue making non-LFS as default for
newer 32 bits ports, the support will be emulated with LFS syscalls.

Re: [Qemu-devel] d_off field in struct dirent and 32-on-64 emulation

[Adhemerval Zanella]

On 28/12/2018 10:01, Florian Weimer wrote:
> * Florian Weimer:
> 
>> * Adhemerval Zanella:
>>
>>> On 27/12/2018 16:09, Florian Weimer wrote:
 * Adhemerval Zanella:

> Also for glibc standpoint, although reverting it back to use getdents 
> syscall for non-LFS mode might fix this issue for architectures that
> provides non-LFS getdents syscall it won't be a fix for architectures 
> that still provides off_t different than off64_t *and* only provides 
> getdents64 syscall.
>
> Currently we only have nios2 and csky (unfortunately).  But since generic 
> definition for off_t and off64_t still assumes non-LFS support, all new
> 32-bits ports potentially might carry the issue.

 For csky, we could still change the type of the non-standard d_off
 field to long long int.  This way, only telldir would have to fail
 when truncation is necessary, as mentioned below:
>>>
>>> I think it makes no sense to continue making non-LFS as default for
>>> newer 32 bits ports, the support will be emulated with LFS syscalls.
>>
>> Sorry, I don't see how this matters.  seekdir and telldir are NOT
>> affected by LFS.
> 
> Ah, right.  If struct dirent is 64-bit only, then the d_off member
> will be 64 bits as well.  But it is unclear whether you can use that
> with lseek (probably yes, in its 64-bit variant), and it's unlikely
> it's going to work with seekdir because of the POSIX-required long int
> type.
> 

I was referring to all other API that uses off_t as well (pread for
instance), where new ports will have non-LFS variants that will call
only LFS variants.

Re: [Qemu-devel] AVX support for TCG

[Nick Renieris]

>> Do you think this could work as a GSoC project? I'm potentially
>> interested in working on it this summer.

>Could be.  My first guess is something like 4 months work for this.

Four months full-time? If so I would say it's not viable for a GSoC
project (it's 3 months), I've done the 12-hours-a-day-crunch thing for
a week or so in GSoC 2017 and it was _not_ fun.
Also, I hope you meant four months for me, not for you - I'm
completely new to the QEMU codebase. I expect it will take me weeks
just to understand x86's 'translate.c' (who thought it'd be a good
idea to put all this stuff in _one_ file?).

Another question, are there existing discussions about this
refactoring effort or specifically AVX? I asked a similar question on
IRC a few days ago and got no answers.

Στις Τετ, 26 Δεκ 2018 στις 4:12 π.μ., ο/η Richard Henderson
 έγραψε:
>
> On 12/26/18 12:28 PM, Nick Renieris wrote:
> > Hi Richard,
> >
> > I did know about https://github.com/andikleen/qemu-avx but didn't
> > mention it as it seems abandoned and quite old (also it doesn't use
> > `TCGv_vec`).
>
> Yep.  Mine pre-dates tcg-op-gvec.h as well.
>
> > Do you think this could work as a GSoC project? I'm potentially
> > interested in working on it this summer.
>
> Could be.  My first guess is something like 4 months work for this.
>
>
> r~

[Qemu-devel] [PATCH v2 1/8] target/ppc: implement complete set of Vsr* macros

[Mark Cave-Ayland]

This prepares us for eliminating the use of direct array access within the VMX
instruction implementations.

Signed-off-by: Mark Cave-Ayland 
Reviewed-by: Richard Henderson 
---
 target/ppc/internal.h | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/target/ppc/internal.h b/target/ppc/internal.h
index c7c0f77dd6..f26a71ffcf 100644
--- a/target/ppc/internal.h
+++ b/target/ppc/internal.h
@@ -206,16 +206,23 @@ EXTRACT_HELPER_SPLIT_3(DCMX_XV, 5, 16, 0, 1, 2, 5, 1, 6, 
6);
 
 #if defined(HOST_WORDS_BIGENDIAN)
 #define VsrB(i) u8[i]
+#define VsrSB(i) s8[i]
 #define VsrH(i) u16[i]
+#define VsrSH(i) s16[i]
 #define VsrW(i) u32[i]
+#define VsrSW(i) s32[i]
 #define VsrD(i) u64[i]
+#define VsrSD(i) s64[i]
 #else
 #define VsrB(i) u8[15 - (i)]
+#define VsrSB(i) s8[15 - (i)]
 #define VsrH(i) u16[7 - (i)]
+#define VsrSH(i) s16[7 - (i)]
 #define VsrW(i) u32[3 - (i)]
+#define VsrSW(i) s32[3 - (i)]
 #define VsrD(i) u64[1 - (i)]
+#define VsrSD(i) s64[1 - (i)]
 #endif
-
 static inline void getVSR(int n, ppc_vsr_t *vsr, CPUPPCState *env)
 {
 vsr->VsrD(0) = env->vsr[n].u64[0];
-- 
2.11.0

Re: [Qemu-devel] [Qemu-block] do not lseek in qcow2 block_status

[Paolo Bonzini]

On 25/12/18 10:45, Vladimir Sementsov-Ogievskiy wrote:
>>
>> What are the cases, when we really need digging for zeros in bs->file?

It's needed for preallocation=metadata.

Paolo

[Qemu-devel] [PATCH v2 0/8] target/ppc: remove various endian hacks from int_helper.c

[Mark Cave-Ayland]

>From working on the TCG vector operations patchset, it is apparent that there
are a large number of endian-based hacks in int_helper.c which can be removed by
making use of the various Vsr* macros.

Patch 1 is simple enough, and implements the complete set of Vsr* macros for
both big endian and little endian hosts.

Patches 2 and 3 rework the vector merge and multiply algorithms so that they
no longer require the endian-dependent HI_IDX and LO_IDX macros.

Patches 4 and 5 then completely remove the HI_IDX/LO_IDX and EL_IDX macros by
replacing the element accesses with their equivalent Vsr* macro instead.

Patches 6 and 7 tidy up the VEXT_SIGNED macro and fix a potential shift bug
in the ROTRu32 and ROTRu64 macros pointed out by Richard during the review of
v1.

Finally patch 8 is an inspection-based removal of other HOST_WORDS_BIGENDIAN
hacks in int_helper.c, again replacing accesses with the relevant Vsr* macro
instead.

Note that there are still some endian hacks left in int_helper.c after this
patchset: in particular the delightfully evil VECTOR_FOR_INORDER_I macro still
remains in places where the index variable was used for purposes other than
accessing elements within the vector.

There were also some parts where additional conversion could be done, but I
wasn't confident enough to make the change without access to PPC64 test images
or real big-endian host hardware.

Signed-off-by: Mark Cave-Ayland 
Based-on: <20181223111525.581-1-mark.cave-ayl...@ilande.co.uk> "target/ppc: 
prepare for conversion to TCG vector operations"


v2:
- Add R-B tags from Richard
- Add patches 6 and 7 to simplify the VEXT_SIGNED macro and fix a potential
  shift bug in the ROTRu32 and ROTRu64 macros
- Don't require ordered access for VNEG and VGENERIC_DO macros as pointed out
  by Richard


Mark Cave-Ayland (8):
  target/ppc: implement complete set of Vsr* macros
  target/ppc: rework vmrg{l,h}{b,h,w} instructions to use Vsr* macros
  target/ppc: rework vmul{e,o}{s,u}{b,h,w} instructions to use Vsr*
macros
  target/ppc: eliminate use of HI_IDX and LO_IDX macros from
int_helper.c
  target/ppc: eliminate use of EL_IDX macros from int_helper.c
  target/ppc: simplify VEXT_SIGNED macro in int_helper.c
  target/ppc: remove ROTRu32 and ROTRu64 macros from int_helper.c
  target/ppc: remove various HOST_WORDS_BIGENDIAN hacks in int_helper.c

 target/ppc/int_helper.c | 521 
 target/ppc/internal.h   |   9 +-
 2 files changed, 223 insertions(+), 307 deletions(-)

-- 
2.11.0

[Qemu-devel] [PATCH v2 7/8] target/ppc: remove ROTRu32 and ROTRu64 macros from int_helper.c

[Mark Cave-Ayland]

Richard points out that these macros suffer from a -fsanitize=shift bug in that
they improperly handle n == 0 turning it into a shift by 32/64 respectively.
Replace them with QEMU's existing ror32() and ror64() functions instead.

Signed-off-by: Mark Cave-Ayland 
---
 target/ppc/int_helper.c | 48 
 1 file changed, 20 insertions(+), 28 deletions(-)

diff --git a/target/ppc/int_helper.c b/target/ppc/int_helper.c
index 39f6c96543..c3eba9ed41 100644
--- a/target/ppc/int_helper.c
+++ b/target/ppc/int_helper.c
@@ -3320,8 +3320,6 @@ void helper_vncipherlast(ppc_avr_t *r, ppc_avr_t *a, 
ppc_avr_t *b)
 *r = result;
 }
 
-#define ROTRu32(v, n) (((v) >> (n)) | ((v) << (32 - n)))
-
 void helper_vshasigmaw(ppc_avr_t *r,  ppc_avr_t *a, uint32_t st_six)
 {
 int st = (st_six & 0x10) != 0;
@@ -3331,32 +3329,28 @@ void helper_vshasigmaw(ppc_avr_t *r,  ppc_avr_t *a, 
uint32_t st_six)
 for (i = 0; i < ARRAY_SIZE(r->u32); i++) {
 if (st == 0) {
 if ((six & (0x8 >> i)) == 0) {
-r->VsrW(i) = ROTRu32(a->VsrW(i), 7) ^
- ROTRu32(a->VsrW(i), 18) ^
+r->VsrW(i) = ror32(a->VsrW(i), 7) ^
+ ror32(a->VsrW(i), 18) ^
  (a->VsrW(i) >> 3);
 } else { /* six.bit[i] == 1 */
-r->VsrW(i) = ROTRu32(a->VsrW(i), 17) ^
- ROTRu32(a->VsrW(i), 19) ^
+r->VsrW(i) = ror32(a->VsrW(i), 17) ^
+ ror32(a->VsrW(i), 19) ^
  (a->VsrW(i) >> 10);
 }
 } else { /* st == 1 */
 if ((six & (0x8 >> i)) == 0) {
-r->VsrW(i) = ROTRu32(a->VsrW(i), 2) ^
- ROTRu32(a->VsrW(i), 13) ^
- ROTRu32(a->VsrW(i), 22);
+r->VsrW(i) = ror32(a->VsrW(i), 2) ^
+ ror32(a->VsrW(i), 13) ^
+ ror32(a->VsrW(i), 22);
 } else { /* six.bit[i] == 1 */
-r->VsrW(i) = ROTRu32(a->VsrW(i), 6) ^
- ROTRu32(a->VsrW(i), 11) ^
- ROTRu32(a->VsrW(i), 25);
+r->VsrW(i) = ror32(a->VsrW(i), 6) ^
+ ror32(a->VsrW(i), 11) ^
+ ror32(a->VsrW(i), 25);
 }
 }
 }
 }
 
-#undef ROTRu32
-
-#define ROTRu64(v, n) (((v) >> (n)) | ((v) << (64-n)))
-
 void helper_vshasigmad(ppc_avr_t *r,  ppc_avr_t *a, uint32_t st_six)
 {
 int st = (st_six & 0x10) != 0;
@@ -3366,30 +3360,28 @@ void helper_vshasigmad(ppc_avr_t *r,  ppc_avr_t *a, 
uint32_t st_six)
 for (i = 0; i < ARRAY_SIZE(r->u64); i++) {
 if (st == 0) {
 if ((six & (0x8 >> (2*i))) == 0) {
-r->VsrD(i) = ROTRu64(a->VsrD(i), 1) ^
- ROTRu64(a->VsrD(i), 8) ^
+r->VsrD(i) = ror64(a->VsrD(i), 1) ^
+ ror64(a->VsrD(i), 8) ^
  (a->VsrD(i) >> 7);
 } else { /* six.bit[2*i] == 1 */
-r->VsrD(i) = ROTRu64(a->VsrD(i), 19) ^
- ROTRu64(a->VsrD(i), 61) ^
+r->VsrD(i) = ror64(a->VsrD(i), 19) ^
+ ror64(a->VsrD(i), 61) ^
  (a->VsrD(i) >> 6);
 }
 } else { /* st == 1 */
 if ((six & (0x8 >> (2*i))) == 0) {
-r->VsrD(i) = ROTRu64(a->VsrD(i), 28) ^
- ROTRu64(a->VsrD(i), 34) ^
- ROTRu64(a->VsrD(i), 39);
+r->VsrD(i) = ror64(a->VsrD(i), 28) ^
+ ror64(a->VsrD(i), 34) ^
+ ror64(a->VsrD(i), 39);
 } else { /* six.bit[2*i] == 1 */
-r->VsrD(i) = ROTRu64(a->VsrD(i), 14) ^
- ROTRu64(a->VsrD(i), 18) ^
- ROTRu64(a->VsrD(i), 41);
+r->VsrD(i) = ror64(a->VsrD(i), 14) ^
+ ror64(a->VsrD(i), 18) ^
+ ror64(a->VsrD(i), 41);
 }
 }
 }
 }
 
-#undef ROTRu64
-
 void helper_vpermxor(ppc_avr_t *r,  ppc_avr_t *a, ppc_avr_t *b, ppc_avr_t *c)
 {
 ppc_avr_t result;
-- 
2.11.0

Re: [Qemu-devel] [PATCH] i386: mark the 'INTEL_PT' CPUID bit as unmigratable

[Paolo Bonzini]

On 25/12/18 09:23, Kang, Luwei wrote:
>> From: Qemu-devel [mailto:qemu-devel-bounces+luwei.kang=intel@nongnu.org] 
>> On Behalf Of Paolo Bonzini
>> Sent: Friday, December 21, 2018 8:44 PM
>> To: qemu-devel@nongnu.org
>> Cc: ehabk...@redhat.com; qemu-sta...@nongnu.org
>> Subject: [Qemu-devel] [PATCH] i386: mark the 'INTEL_PT' CPUID bit as 
>> unmigratable
>>
>> Marshaling of processor tracing MSRs is not yet implemented in QEMU, mark 
>> the feature as unmigratable.
> 
> Hi Paolo,
> I think Intel PT has supported live migration. I don't understand what 
> you mean.
> 
> commit b77146e9a129bcdb60edc23639211679ae846a92
> Author: Chao Peng 
> Date:   Mon Mar 5 00:48:36 2018 +0800
> i386: Add support to get/set/migrate Intel Processor Trace feature

Indeed.  I had forgotten this patch because it was committed so long
before the kernel parts (which really should not happen, but Eduardo and
I miscommunicated on it).  Can you check that it still works?

Paolo

[Qemu-devel] [PATCH v2 6/8] target/ppc: simplify VEXT_SIGNED macro in int_helper.c

[Mark Cave-Ayland]

As pointed out by Richard: it does not need the mask argument, nor does it need
the recast argument. The masking is implied by the cast argument, and the
recast is implied by the assignment.

Signed-off-by: Mark Cave-Ayland 
---
 target/ppc/int_helper.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/target/ppc/int_helper.c b/target/ppc/int_helper.c
index 4cc7fdfd25..39f6c96543 100644
--- a/target/ppc/int_helper.c
+++ b/target/ppc/int_helper.c
@@ -2038,19 +2038,19 @@ void helper_xxinsertw(CPUPPCState *env, target_ulong 
xtn,
 putVSR(xtn, &xt, env);
 }
 
-#define VEXT_SIGNED(name, element, mask, cast, recast)  \
+#define VEXT_SIGNED(name, element, cast)\
 void helper_##name(ppc_avr_t *r, ppc_avr_t *b)  \
 {   \
 int i;  \
 VECTOR_FOR_INORDER_I(i, element) {  \
-r->element[i] = (recast)((cast)(b->element[i] & mask)); \
+r->element[i] = (cast)b->element[i];\
 }   \
 }
-VEXT_SIGNED(vextsb2w, s32, UINT8_MAX, int8_t, int32_t)
-VEXT_SIGNED(vextsb2d, s64, UINT8_MAX, int8_t, int64_t)
-VEXT_SIGNED(vextsh2w, s32, UINT16_MAX, int16_t, int32_t)
-VEXT_SIGNED(vextsh2d, s64, UINT16_MAX, int16_t, int64_t)
-VEXT_SIGNED(vextsw2d, s64, UINT32_MAX, int32_t, int64_t)
+VEXT_SIGNED(vextsb2w, s32, int8_t)
+VEXT_SIGNED(vextsb2d, s64, int8_t)
+VEXT_SIGNED(vextsh2w, s32, int16_t)
+VEXT_SIGNED(vextsh2d, s64, int16_t)
+VEXT_SIGNED(vextsw2d, s64, int32_t)
 #undef VEXT_SIGNED
 
 #define VNEG(name, element) \
-- 
2.11.0

[Qemu-devel] [PATCH v2 5/8] target/ppc: eliminate use of EL_IDX macros from int_helper.c

[Mark Cave-Ayland]

These macros can be eliminated by instead using the relavant Vsr* macros in
the few locations where they appear.

Signed-off-by: Mark Cave-Ayland 
Reviewed-by: Richard Henderson 
---
 target/ppc/int_helper.c | 66 -
 1 file changed, 27 insertions(+), 39 deletions(-)

diff --git a/target/ppc/int_helper.c b/target/ppc/int_helper.c
index addbe54c21..4cc7fdfd25 100644
--- a/target/ppc/int_helper.c
+++ b/target/ppc/int_helper.c
@@ -3320,12 +3320,7 @@ void helper_vncipherlast(ppc_avr_t *r, ppc_avr_t *a, 
ppc_avr_t *b)
 *r = result;
 }
 
-#define ROTRu32(v, n) (((v) >> (n)) | ((v) << (32-n)))
-#if defined(HOST_WORDS_BIGENDIAN)
-#define EL_IDX(i) (i)
-#else
-#define EL_IDX(i) (3 - (i))
-#endif
+#define ROTRu32(v, n) (((v) >> (n)) | ((v) << (32 - n)))
 
 void helper_vshasigmaw(ppc_avr_t *r,  ppc_avr_t *a, uint32_t st_six)
 {
@@ -,40 +3328,34 @@ void helper_vshasigmaw(ppc_avr_t *r,  ppc_avr_t *a, 
uint32_t st_six)
 int six = st_six & 0xF;
 int i;
 
-VECTOR_FOR_INORDER_I(i, u32) {
+for (i = 0; i < ARRAY_SIZE(r->u32); i++) {
 if (st == 0) {
 if ((six & (0x8 >> i)) == 0) {
-r->u32[EL_IDX(i)] = ROTRu32(a->u32[EL_IDX(i)], 7) ^
-ROTRu32(a->u32[EL_IDX(i)], 18) ^
-(a->u32[EL_IDX(i)] >> 3);
+r->VsrW(i) = ROTRu32(a->VsrW(i), 7) ^
+ ROTRu32(a->VsrW(i), 18) ^
+ (a->VsrW(i) >> 3);
 } else { /* six.bit[i] == 1 */
-r->u32[EL_IDX(i)] = ROTRu32(a->u32[EL_IDX(i)], 17) ^
-ROTRu32(a->u32[EL_IDX(i)], 19) ^
-(a->u32[EL_IDX(i)] >> 10);
+r->VsrW(i) = ROTRu32(a->VsrW(i), 17) ^
+ ROTRu32(a->VsrW(i), 19) ^
+ (a->VsrW(i) >> 10);
 }
 } else { /* st == 1 */
 if ((six & (0x8 >> i)) == 0) {
-r->u32[EL_IDX(i)] = ROTRu32(a->u32[EL_IDX(i)], 2) ^
-ROTRu32(a->u32[EL_IDX(i)], 13) ^
-ROTRu32(a->u32[EL_IDX(i)], 22);
+r->VsrW(i) = ROTRu32(a->VsrW(i), 2) ^
+ ROTRu32(a->VsrW(i), 13) ^
+ ROTRu32(a->VsrW(i), 22);
 } else { /* six.bit[i] == 1 */
-r->u32[EL_IDX(i)] = ROTRu32(a->u32[EL_IDX(i)], 6) ^
-ROTRu32(a->u32[EL_IDX(i)], 11) ^
-ROTRu32(a->u32[EL_IDX(i)], 25);
+r->VsrW(i) = ROTRu32(a->VsrW(i), 6) ^
+ ROTRu32(a->VsrW(i), 11) ^
+ ROTRu32(a->VsrW(i), 25);
 }
 }
 }
 }
 
 #undef ROTRu32
-#undef EL_IDX
 
 #define ROTRu64(v, n) (((v) >> (n)) | ((v) << (64-n)))
-#if defined(HOST_WORDS_BIGENDIAN)
-#define EL_IDX(i) (i)
-#else
-#define EL_IDX(i) (1 - (i))
-#endif
 
 void helper_vshasigmad(ppc_avr_t *r,  ppc_avr_t *a, uint32_t st_six)
 {
@@ -3374,33 +3363,32 @@ void helper_vshasigmad(ppc_avr_t *r,  ppc_avr_t *a, 
uint32_t st_six)
 int six = st_six & 0xF;
 int i;
 
-VECTOR_FOR_INORDER_I(i, u64) {
+for (i = 0; i < ARRAY_SIZE(r->u64); i++) {
 if (st == 0) {
 if ((six & (0x8 >> (2*i))) == 0) {
-r->u64[EL_IDX(i)] = ROTRu64(a->u64[EL_IDX(i)], 1) ^
-ROTRu64(a->u64[EL_IDX(i)], 8) ^
-(a->u64[EL_IDX(i)] >> 7);
+r->VsrD(i) = ROTRu64(a->VsrD(i), 1) ^
+ ROTRu64(a->VsrD(i), 8) ^
+ (a->VsrD(i) >> 7);
 } else { /* six.bit[2*i] == 1 */
-r->u64[EL_IDX(i)] = ROTRu64(a->u64[EL_IDX(i)], 19) ^
-ROTRu64(a->u64[EL_IDX(i)], 61) ^
-(a->u64[EL_IDX(i)] >> 6);
+r->VsrD(i) = ROTRu64(a->VsrD(i), 19) ^
+ ROTRu64(a->VsrD(i), 61) ^
+ (a->VsrD(i) >> 6);
 }
 } else { /* st == 1 */
 if ((six & (0x8 >> (2*i))) == 0) {
-r->u64[EL_IDX(i)] = ROTRu64(a->u64[EL_IDX(i)], 28) ^
-ROTRu64(a->u64[EL_IDX(i)], 34) ^
-ROTRu64(a->u64[EL_IDX(i)], 39);
+r->VsrD(i) = ROTRu64(a->VsrD(i), 28) ^
+ ROTRu64(a->VsrD(i), 34) ^
+ ROTRu64(a->VsrD(i), 39);
 } else { /* six.bit[2*i] == 1 */
-r->u64[EL_IDX(i)] = ROTRu64(a->u64[EL_IDX(i)], 14) ^
-ROTRu64(a->u64[EL_IDX(i)], 18) ^
-ROTRu64(a->u64[EL_IDX(i)], 41);
+r->VsrD(i) = ROTRu64(a->VsrD(i), 14) ^
+  

[Qemu-devel] [PATCH v2 8/8] target/ppc: remove various HOST_WORDS_BIGENDIAN hacks in int_helper.c

[Mark Cave-Ayland]

Following on from the previous work, there are numerous endian-related hacks
in int_helper.c that can now be replaced with Vsr* macros.

There are also a few places where the VECTOR_FOR_INORDER_I macro can be
replaced with a normal iterator since the processing order is irrelevant.

Signed-off-by: Mark Cave-Ayland 
---
 target/ppc/int_helper.c | 155 ++--
 1 file changed, 45 insertions(+), 110 deletions(-)

diff --git a/target/ppc/int_helper.c b/target/ppc/int_helper.c
index c3eba9ed41..3b4cf248e9 100644
--- a/target/ppc/int_helper.c
+++ b/target/ppc/int_helper.c
@@ -443,8 +443,8 @@ void helper_lvsl(ppc_avr_t *r, target_ulong sh)
 {
 int i, j = (sh & 0xf);
 
-VECTOR_FOR_INORDER_I(i, u8) {
-r->u8[i] = j++;
+for (i = 0; i < ARRAY_SIZE(r->u8); i++) {
+r->VsrB(i) = j++;
 }
 }
 
@@ -452,18 +452,14 @@ void helper_lvsr(ppc_avr_t *r, target_ulong sh)
 {
 int i, j = 0x10 - (sh & 0xf);
 
-VECTOR_FOR_INORDER_I(i, u8) {
-r->u8[i] = j++;
+for (i = 0; i < ARRAY_SIZE(r->u8); i++) {
+r->VsrB(i) = j++;
 }
 }
 
 void helper_mtvscr(CPUPPCState *env, ppc_avr_t *r)
 {
-#if defined(HOST_WORDS_BIGENDIAN)
-env->vscr = r->u32[3];
-#else
-env->vscr = r->u32[0];
-#endif
+env->vscr = r->VsrW(3);
 set_flush_to_zero(vscr_nj, &env->vec_status);
 }
 
@@ -870,8 +866,8 @@ target_ulong helper_vclzlsbb(ppc_avr_t *r)
 {
 target_ulong count = 0;
 int i;
-VECTOR_FOR_INORDER_I(i, u8) {
-if (r->u8[i] & 0x01) {
+for (i = 0; i < ARRAY_SIZE(r->u8); i++) {
+if (r->VsrB(i) & 0x01) {
 break;
 }
 count++;
@@ -883,12 +879,8 @@ target_ulong helper_vctzlsbb(ppc_avr_t *r)
 {
 target_ulong count = 0;
 int i;
-#if defined(HOST_WORDS_BIGENDIAN)
 for (i = ARRAY_SIZE(r->u8) - 1; i >= 0; i--) {
-#else
-for (i = 0; i < ARRAY_SIZE(r->u8); i++) {
-#endif
-if (r->u8[i] & 0x01) {
+if (r->VsrB(i) & 0x01) {
 break;
 }
 count++;
@@ -1151,18 +1143,14 @@ void helper_vperm(CPUPPCState *env, ppc_avr_t *r, 
ppc_avr_t *a, ppc_avr_t *b,
 ppc_avr_t result;
 int i;
 
-VECTOR_FOR_INORDER_I(i, u8) {
-int s = c->u8[i] & 0x1f;
-#if defined(HOST_WORDS_BIGENDIAN)
+for (i = 0; i < ARRAY_SIZE(r->u8); i++) {
+int s = c->VsrB(i) & 0x1f;
 int index = s & 0xf;
-#else
-int index = 15 - (s & 0xf);
-#endif
 
 if (s & 0x10) {
-result.u8[i] = b->u8[index];
+result.VsrB(i) = b->VsrB(index);
 } else {
-result.u8[i] = a->u8[index];
+result.VsrB(i) = a->VsrB(index);
 }
 }
 *r = result;
@@ -1174,18 +1162,14 @@ void helper_vpermr(CPUPPCState *env, ppc_avr_t *r, 
ppc_avr_t *a, ppc_avr_t *b,
 ppc_avr_t result;
 int i;
 
-VECTOR_FOR_INORDER_I(i, u8) {
-int s = c->u8[i] & 0x1f;
-#if defined(HOST_WORDS_BIGENDIAN)
+for (i = 0; i < ARRAY_SIZE(r->u8); i++) {
+int s = c->VsrB(i) & 0x1f;
 int index = 15 - (s & 0xf);
-#else
-int index = s & 0xf;
-#endif
 
 if (s & 0x10) {
-result.u8[i] = a->u8[index];
+result.VsrB(i) = a->VsrB(index);
 } else {
-result.u8[i] = b->u8[index];
+result.VsrB(i) = b->VsrB(index);
 }
 }
 *r = result;
@@ -1882,25 +1866,14 @@ void helper_vsldoi(ppc_avr_t *r, ppc_avr_t *a, 
ppc_avr_t *b, uint32_t shift)
 int i;
 ppc_avr_t result;
 
-#if defined(HOST_WORDS_BIGENDIAN)
 for (i = 0; i < ARRAY_SIZE(r->u8); i++) {
 int index = sh + i;
 if (index > 0xf) {
-result.u8[i] = b->u8[index - 0x10];
-} else {
-result.u8[i] = a->u8[index];
-}
-}
-#else
-for (i = 0; i < ARRAY_SIZE(r->u8); i++) {
-int index = (16 - sh) + i;
-if (index > 0xf) {
-result.u8[i] = a->u8[index - 0x10];
+result.VsrB(i) = b->VsrB(index - 0x10);
 } else {
-result.u8[i] = b->u8[index];
+result.VsrB(i) = a->VsrB(index);
 }
 }
-#endif
 *r = result;
 }
 
@@ -1919,25 +1892,20 @@ void helper_vslo(ppc_avr_t *r, ppc_avr_t *a, ppc_avr_t 
*b)
 
 /* Experimental testing shows that hardware masks the immediate.  */
 #define _SPLAT_MASKED(element) (splat & (ARRAY_SIZE(r->element) - 1))
-#if defined(HOST_WORDS_BIGENDIAN)
 #define SPLAT_ELEMENT(element) _SPLAT_MASKED(element)
-#else
-#define SPLAT_ELEMENT(element)  \
-(ARRAY_SIZE(r->element) - 1 - _SPLAT_MASKED(element))
-#endif
-#define VSPLT(suffix, element)  \
+#define VSPLT(suffix, element, access)  \
 void helper_vsplt##suffix(ppc_avr_t *r, ppc_avr_t *b, uint32_t splat) \
 {   \
-uint32_t s = b->element[SPLAT_ELEMENT(element)];\
+uint

[Qemu-devel] [PATCH v2 4/8] target/ppc: eliminate use of HI_IDX and LO_IDX macros from int_helper.c

[Mark Cave-Ayland]

The original purpose of these macros was to correctly reference the high and low
parts of the VSRs regardless of the host endianness.

Replace these direct references to high and low parts with the relevant VsrD
macro instead, and completely remove the now-unused HI_IDX and LO_IDX macros.

Signed-off-by: Mark Cave-Ayland 
---
 target/ppc/int_helper.c | 180 +++-
 1 file changed, 85 insertions(+), 95 deletions(-)

diff --git a/target/ppc/int_helper.c b/target/ppc/int_helper.c
index dc5c9fb8d8..addbe54c21 100644
--- a/target/ppc/int_helper.c
+++ b/target/ppc/int_helper.c
@@ -389,14 +389,6 @@ target_ulong helper_602_mfrom(target_ulong arg)
 /*/
 /* Altivec extension helpers */
 #if defined(HOST_WORDS_BIGENDIAN)
-#define HI_IDX 0
-#define LO_IDX 1
-#else
-#define HI_IDX 1
-#define LO_IDX 0
-#endif
-
-#if defined(HOST_WORDS_BIGENDIAN)
 #define VECTOR_FOR_INORDER_I(index, element)\
 for (index = 0; index < ARRAY_SIZE(r->element); index++)
 #else
@@ -514,8 +506,8 @@ void helper_vprtybq(ppc_avr_t *r, ppc_avr_t *b)
 res ^= res >> 32;
 res ^= res >> 16;
 res ^= res >> 8;
-r->u64[LO_IDX] = res & 1;
-r->u64[HI_IDX] = 0;
+r->VsrD(1) = res & 1;
+r->VsrD(0) = 0;
 }
 
 #define VARITH_DO(name, op, element)\
@@ -1243,8 +1235,8 @@ void helper_vbpermq(ppc_avr_t *r, ppc_avr_t *a, ppc_avr_t 
*b)
 }
 }
 
-r->u64[HI_IDX] = perm;
-r->u64[LO_IDX] = 0;
+r->VsrD(0) = perm;
+r->VsrD(1) = 0;
 }
 
 #undef VBPERMQ_INDEX
@@ -1573,25 +1565,25 @@ void helper_vpmsumd(ppc_avr_t *r, ppc_avr_t *a, 
ppc_avr_t *b)
 ppc_avr_t prod[2];
 
 VECTOR_FOR_INORDER_I(i, u64) {
-prod[i].u64[LO_IDX] = prod[i].u64[HI_IDX] = 0;
+prod[i].VsrD(1) = prod[i].VsrD(0) = 0;
 for (j = 0; j < 64; j++) {
 if (a->u64[i] & (1ullu64[i];
 } else {
-bshift.u64[HI_IDX] = b->u64[i] >> (64-j);
-bshift.u64[LO_IDX] = b->u64[i] << j;
+bshift.VsrD(0) = b->u64[i] >> (64 - j);
+bshift.VsrD(1) = b->u64[i] << j;
 }
-prod[i].u64[LO_IDX] ^= bshift.u64[LO_IDX];
-prod[i].u64[HI_IDX] ^= bshift.u64[HI_IDX];
+prod[i].VsrD(1) ^= bshift.VsrD(1);
+prod[i].VsrD(0) ^= bshift.VsrD(0);
 }
 }
 }
 
-r->u64[LO_IDX] = prod[0].u64[LO_IDX] ^ prod[1].u64[LO_IDX];
-r->u64[HI_IDX] = prod[0].u64[HI_IDX] ^ prod[1].u64[HI_IDX];
+r->VsrD(1) = prod[0].VsrD(1) ^ prod[1].VsrD(1);
+r->VsrD(0) = prod[0].VsrD(0) ^ prod[1].VsrD(0);
 #endif
 }
 
@@ -1809,7 +1801,7 @@ VEXTU_X_DO(vextuwrx, 32, 0)
 #define VSHIFT(suffix, leftp)   \
 void helper_vs##suffix(ppc_avr_t *r, ppc_avr_t *a, ppc_avr_t *b)\
 {   \
-int shift = b->u8[LO_IDX*15] & 0x7; \
+int shift = b->VsrB(15) & 0x7;  \
 int doit = 1;   \
 int i;  \
 \
@@ -1820,15 +1812,15 @@ VEXTU_X_DO(vextuwrx, 32, 0)
 if (shift == 0) {   \
 *r = *a;\
 } else if (leftp) { \
-uint64_t carry = a->u64[LO_IDX] >> (64 - shift);\
+uint64_t carry = a->VsrD(1) >> (64 - shift);\
 \
-r->u64[HI_IDX] = (a->u64[HI_IDX] << shift) | carry; \
-r->u64[LO_IDX] = a->u64[LO_IDX] << shift;   \
+r->VsrD(0) = (a->VsrD(0) << shift) | carry; \
+r->VsrD(1) = a->VsrD(1) << shift;   \
 } else {\
-uint64_t carry = a->u64[HI_IDX] << (64 - shift);\
+uint64_t carry = a->VsrD(0) << (64 - shift);\
 \
-r->u64[LO_IDX] = (a->u64[LO_IDX] >> shift) | carry; \
-r->u64[HI_IDX] = a->u64[HI_IDX] >> shift;   \
+r->VsrD(1) = (a->VsrD(1) >> shift) | carry; \
+r->VsrD(0) = a->VsrD(0) >> shift;   \
 }   \
 }

Re: [Qemu-devel] [PATCH] smbus_eeprom: Limit data writes to 255 bytes

[Paolo Bonzini]

On 27/12/18 12:51, Michael Hanselmann wrote:
> The "eeprom_write_data" function in "smbus_eeprom.c" had no provisions
> to limit the length of data written. If a caller were able to manipulate
> the "len" parameter they could potentially write before or after the
> target buffer.
> ---
>  hw/i2c/smbus_eeprom.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/hw/i2c/smbus_eeprom.c b/hw/i2c/smbus_eeprom.c
> index f18aa3de35..74fa1c328c 100644
> --- a/hw/i2c/smbus_eeprom.c
> +++ b/hw/i2c/smbus_eeprom.c
> @@ -76,6 +76,7 @@ static void eeprom_write_data(SMBusDevice *dev, uint8_t 
> cmd, uint8_t *buf, int l
> It is a block write without a length byte.  Fortunately we
> get the full block anyway.  */
>  /* TODO: Should this set the current location?  */
> +len &= 0xff;
>  if (cmd + len > 256)
>  n = 256 - cmd;
>  else
> 

Note that len is limited to 33 bytes (smbus_do_write and smbus_i2c_send).

Paolo

Re: [Qemu-devel] [PATCH 3/6] target/ppc: rework vmul{e, o}{s, u}{b, h, w} instructions to use Vsr* macros

[Mark Cave-Ayland]

On 25/12/2018 20:11, Richard Henderson wrote:

> On 12/23/18 10:38 PM, Mark Cave-Ayland wrote:
>> -#define VMUL_DO(name, mul_element, prod_element, cast, evenp)   \
>> +#define VMUL_DO_EVN(name, mul_element, mul_access, prod_access, cast)   \
>>  void helper_v##name(ppc_avr_t *r, ppc_avr_t *a, ppc_avr_t *b)   \
>>  {   \
>>  int i;  \
>>  \
>> +for (i = 0; i < ARRAY_SIZE(r->mul_element); i += 2) {   \
>> +r->prod_access(i >> 1) = (cast)a->mul_access(i) *   \
>> + (cast)b->mul_access(i);\
>> +}   \
>> +}
>> +
>> +#define VMUL_DO_ODD(name, mul_element, mul_access, prod_access, cast)   \
>> +void helper_v##name(ppc_avr_t *r, ppc_avr_t *a, ppc_avr_t *b)   \
>> +{   \
>> +int i;  \
>> +\
>> +for (i = 0; i < ARRAY_SIZE(r->mul_element); i += 2) {   \
>> +r->prod_access(i >> 1) = (cast)a->mul_access(i + 1) *   \
>> + (cast)b->mul_access(i + 1);\
>>  }   \
>>  }
> 
> FWIW,
> 
>   for (i = odd; i < ARRAY_SIZE; i += 2) {
> r->pacc(i >> 1) = (cast)a->macc(i) * b->macc(i);
>   }
> 
> is sufficient to unify these two.  But what you have isn't wrong.
> 
> Reviewed-by: Richard Henderson 

Ah indeed that's quite neat! Thinking about it for a few days, I've decided to 
leave
it as-is for now, since it was useful to be able to test the odd/even variants
separately (as they were often used together in testing) and it's just that 
tiny bit
easier to relate to the ISA documentation.


ATB,

Mark.

[Qemu-devel] [PATCH v2 3/8] target/ppc: rework vmul{e, o}{s, u}{b, h, w} instructions to use Vsr* macros

[Mark Cave-Ayland]

The current implementations make use of the endian-specific macros HI_IDX and
LO_IDX directly to calculate array offsets.

Rework the implementation to use the Vsr* macros so that these per-endian
references can be removed.

Signed-off-by: Mark Cave-Ayland 
Reviewed-by: Richard Henderson 
---
 target/ppc/int_helper.c | 48 +++-
 1 file changed, 27 insertions(+), 21 deletions(-)

diff --git a/target/ppc/int_helper.c b/target/ppc/int_helper.c
index f084a706ee..dc5c9fb8d8 100644
--- a/target/ppc/int_helper.c
+++ b/target/ppc/int_helper.c
@@ -1118,33 +1118,39 @@ void helper_vmsumuhs(CPUPPCState *env, ppc_avr_t *r, 
ppc_avr_t *a,
 }
 }
 
-#define VMUL_DO(name, mul_element, prod_element, cast, evenp)   \
+#define VMUL_DO_EVN(name, mul_element, mul_access, prod_access, cast)   \
 void helper_v##name(ppc_avr_t *r, ppc_avr_t *a, ppc_avr_t *b)   \
 {   \
 int i;  \
 \
-VECTOR_FOR_INORDER_I(i, prod_element) { \
-if (evenp) {\
-r->prod_element[i] =\
-(cast)a->mul_element[i * 2 + HI_IDX] *  \
-(cast)b->mul_element[i * 2 + HI_IDX];   \
-} else {\
-r->prod_element[i] =\
-(cast)a->mul_element[i * 2 + LO_IDX] *  \
-(cast)b->mul_element[i * 2 + LO_IDX];   \
-}   \
+for (i = 0; i < ARRAY_SIZE(r->mul_element); i += 2) {   \
+r->prod_access(i >> 1) = (cast)a->mul_access(i) *   \
+ (cast)b->mul_access(i);\
+}   \
+}
+
+#define VMUL_DO_ODD(name, mul_element, mul_access, prod_access, cast)   \
+void helper_v##name(ppc_avr_t *r, ppc_avr_t *a, ppc_avr_t *b)   \
+{   \
+int i;  \
+\
+for (i = 0; i < ARRAY_SIZE(r->mul_element); i += 2) {   \
+r->prod_access(i >> 1) = (cast)a->mul_access(i + 1) *   \
+ (cast)b->mul_access(i + 1);\
 }   \
 }
-#define VMUL(suffix, mul_element, prod_element, cast)\
-VMUL_DO(mule##suffix, mul_element, prod_element, cast, 1)\
-VMUL_DO(mulo##suffix, mul_element, prod_element, cast, 0)
-VMUL(sb, s8, s16, int16_t)
-VMUL(sh, s16, s32, int32_t)
-VMUL(sw, s32, s64, int64_t)
-VMUL(ub, u8, u16, uint16_t)
-VMUL(uh, u16, u32, uint32_t)
-VMUL(uw, u32, u64, uint64_t)
-#undef VMUL_DO
+
+#define VMUL(suffix, mul_element, mul_access, prod_access, cast)   \
+VMUL_DO_EVN(mule##suffix, mul_element, mul_access, prod_access, cast)  \
+VMUL_DO_ODD(mulo##suffix, mul_element, mul_access, prod_access, cast)
+VMUL(sb, s8, VsrSB, VsrSH, int16_t)
+VMUL(sh, s16, VsrSH, VsrSW, int32_t)
+VMUL(sw, s32, VsrSW, VsrSD, int64_t)
+VMUL(ub, u8, VsrB, VsrH, uint16_t)
+VMUL(uh, u16, VsrH, VsrW, uint32_t)
+VMUL(uw, u32, VsrW, VsrD, uint64_t)
+#undef VMUL_DO_EVN
+#undef VMUL_DO_ODD
 #undef VMUL
 
 void helper_vperm(CPUPPCState *env, ppc_avr_t *r, ppc_avr_t *a, ppc_avr_t *b,
-- 
2.11.0

[Qemu-devel] [PATCH v2 2/8] target/ppc: rework vmrg{l, h}{b, h, w} instructions to use Vsr* macros

[Mark Cave-Ayland]

The current implementations make use of the endian-specific macros MRGLO/MRGHI
and also reference HI_IDX and LO_IDX directly to calculate array offsets.

Rework the implementation to use the Vsr* macros so that these per-endian
references can be removed.

Signed-off-by: Mark Cave-Ayland 
---
 target/ppc/int_helper.c | 52 -
 1 file changed, 25 insertions(+), 27 deletions(-)

diff --git a/target/ppc/int_helper.c b/target/ppc/int_helper.c
index 598731d47a..f084a706ee 100644
--- a/target/ppc/int_helper.c
+++ b/target/ppc/int_helper.c
@@ -976,43 +976,41 @@ void helper_vmladduhm(ppc_avr_t *r, ppc_avr_t *a, 
ppc_avr_t *b, ppc_avr_t *c)
 }
 }
 
-#define VMRG_DO(name, element, highp)   \
+#define VMRG_DOLO(name, element, access)\
 void helper_v##name(ppc_avr_t *r, ppc_avr_t *a, ppc_avr_t *b)   \
 {   \
 ppc_avr_t result;   \
 int i;  \
-size_t n_elems = ARRAY_SIZE(r->element);\
+int m = ARRAY_SIZE(r->element) - 1; \
 \
-for (i = 0; i < n_elems / 2; i++) { \
-if (highp) {\
-result.element[i*2+HI_IDX] = a->element[i]; \
-result.element[i*2+LO_IDX] = b->element[i]; \
-} else {\
-result.element[n_elems - i * 2 - (1 + HI_IDX)] =\
-b->element[n_elems - i - 1];\
-result.element[n_elems - i * 2 - (1 + LO_IDX)] =\
-a->element[n_elems - i - 1];\
-}   \
+for (i = 0; i < ARRAY_SIZE(r->element); i++) {  \
+result.access(m - i) = (i & 1) ? a->access(m - (i >> 1))\
+   : b->access(m - (i >> 1));   \
 }   \
 *r = result;\
 }
-#if defined(HOST_WORDS_BIGENDIAN)
-#define MRGHI 0
-#define MRGLO 1
-#else
-#define MRGHI 1
-#define MRGLO 0
-#endif
-#define VMRG(suffix, element)   \
-VMRG_DO(mrgl##suffix, element, MRGHI)   \
-VMRG_DO(mrgh##suffix, element, MRGLO)
-VMRG(b, u8)
-VMRG(h, u16)
-VMRG(w, u32)
+
+#define VMRG_DOHI(name, element, access)\
+void helper_v##name(ppc_avr_t *r, ppc_avr_t *a, ppc_avr_t *b)   \
+{   \
+ppc_avr_t result;   \
+int i;  \
+\
+for (i = 0; i < ARRAY_SIZE(r->element); i++) {  \
+result.access(i) = (i & 1) ? b->access(i >> 1)  \
+   : a->access(i >> 1); \
+}   \
+*r = result;\
+}
+
+#define VMRG(suffix, element, access)  \
+VMRG_DOLO(mrgl##suffix, element, access)   \
+VMRG_DOHI(mrgh##suffix, element, access)
+VMRG(b, u8, VsrB)
+VMRG(h, u16, VsrH)
+VMRG(w, u32, VsrW)
 #undef VMRG_DO
 #undef VMRG
-#undef MRGHI
-#undef MRGLO
 
 void helper_vmsummbm(CPUPPCState *env, ppc_avr_t *r, ppc_avr_t *a,
  ppc_avr_t *b, ppc_avr_t *c)
-- 
2.11.0

Re: [Qemu-devel] AVX support for TCG

[Peter Maydell]

On Fri, 28 Dec 2018 at 13:45, Nick Renieris  wrote:
> Also, I hope you meant four months for me, not for you - I'm
> completely new to the QEMU codebase. I expect it will take me weeks
> just to understand x86's 'translate.c' (who thought it'd be a good
> idea to put all this stuff in _one_ file?).

x86 suffers from being one of the first and oldest frontends,
and on top of that from not having had a great deal of active
attention. So it has a lot of remnants from older styles of
implementation, as well as the kind of "one big function in
one huge file" that organic growth of a codebase tends to give you.
It doesn't make that much difference whether you have one file
or several, though -- target/arm/translate-a64.c is pretty
well structured and easy (IMHO) to comprehend, but it's
5000 lines longer than target/i386/translate.c. The comprehensibility
improvements come from better breakdown into separate functions
and much clearer commenting of the extent of the decode at any
particular point (plus not having any legacy baggage to deal with).

thanks
-- PMM

Re: [Qemu-devel] [PATCH 2/4] Add CET SHSTK and IBT CPUID feature-word definitions.

[Paolo Bonzini]

On 26/12/18 09:25, Yang Weijiang wrote:
> @@ -1233,6 +1252,14 @@ static const ExtSaveArea x86_ext_save_areas[] = {
>{ .feature = FEAT_7_0_ECX, .bits = CPUID_7_0_ECX_PKU,
>  .offset = offsetof(X86XSaveArea, pkru_state),
>  .size = sizeof(XSavePKRU) },
> +[XSTATE_CET_U_BIT] = {
> +.feature = FEAT_7_0_ECX, .bits = CPUID_7_0_ECX_CET_SHSTK,
> +.offset = offsetof(X86XSaveArea, cet_u),

These offsets are incorrect, since supervisor states are only stored in
the compacted format.  In fact, in patch 4, supervisor states should
return 0 in CPUID(EAX=0Dh,ECX=n).EBX.

You can use offset == 0 to distinguish supervisor and user states, so
that supervisor states are skipped in xsave_area_size and x86_cpu_reset.

Thanks,

Paolo

> +.size = sizeof(XSaveCETU) },
> +[XSTATE_CET_S_BIT] = {
> +.feature = FEAT_7_0_ECX, .bits = CPUID_7_0_ECX_CET_SHSTK,
> +.offset = offsetof(X86XSaveArea, cet_s),
> +.size = sizeof(XSaveCETS) },
>  };
>  
>  static uint32_t xsave_area_size(uint64_t mask)

Re: [Qemu-devel] AVX support for TCG

[Nick Renieris]

Right, thanks, that file looks better, though I still think splitting
to multiple files would absolutely be of value, if only for the
practicality of being able to have several parts of it open at the
same in a code editor (instead of having to jump back and forth or
find workarounds to open the same file multiple times). Of course
there are more important, code structure related reasons beyond that,
but let's not digress. I'm guessing current devs are so used to this
that they wouldn't accept splitting-up changes anyway.

Στις Παρ, 28 Δεκ 2018 στις 4:13 μ.μ., ο/η Peter Maydell
 έγραψε:
>
> On Fri, 28 Dec 2018 at 13:45, Nick Renieris  wrote:
> > Also, I hope you meant four months for me, not for you - I'm
> > completely new to the QEMU codebase. I expect it will take me weeks
> > just to understand x86's 'translate.c' (who thought it'd be a good
> > idea to put all this stuff in _one_ file?).
>
> x86 suffers from being one of the first and oldest frontends,
> and on top of that from not having had a great deal of active
> attention. So it has a lot of remnants from older styles of
> implementation, as well as the kind of "one big function in
> one huge file" that organic growth of a codebase tends to give you.
> It doesn't make that much difference whether you have one file
> or several, though -- target/arm/translate-a64.c is pretty
> well structured and easy (IMHO) to comprehend, but it's
> 5000 lines longer than target/i386/translate.c. The comprehensibility
> improvements come from better breakdown into separate functions
> and much clearer commenting of the extent of the decode at any
> particular point (plus not having any legacy baggage to deal with).
>
> thanks
> -- PMM

[Qemu-devel] [PATCH] dmg: Fixing wrong dmg block type value for block terminator.

[Julio Faracco]

This is a trivial patch to fix a wrong value for block terminator.
The old value was 0x7fff which is wrong. It was not affecting the
code because QEMU dmg block is not handling block terminator right now.
Neverthless, it should be fixed.

Signed-off-by: Julio Faracco 
---
 block/dmg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/block/dmg.c b/block/dmg.c
index 50e91aef6d..2c806e3389 100644
--- a/block/dmg.c
+++ b/block/dmg.c
@@ -54,7 +54,7 @@ enum {
 UDBZ,
 ULFO,
 UDCM = 0x7ffe, /* Comments */
-UDLE   /* Last Entry */
+UDLE = 0x  /* Last Entry */
 };
 
 static int dmg_probe(const uint8_t *buf, int buf_size, const char *filename)
-- 
2.19.1

Re: [Qemu-devel] AVX support for TCG

[Peter Maydell]

On Fri, 28 Dec 2018 at 14:28, Nick Renieris  wrote:
> Right, thanks, that file looks better, though I still think splitting
> to multiple files would absolutely be of value, if only for the
> practicality of being able to have several parts of it open at the
> same in a code editor (instead of having to jump back and forth or
> find workarounds to open the same file multiple times).

If your editor can't show multiple views onto one file with
the same simplicity and UI as it has for multiple different
files then I would suggest getting a better editor :-)
Unless you want to restrict all your files to 100 lines or
shorter then you need to be able to see multiple parts of them
at once -- one 10,000 line file is no worse than 4 2500 line
files for this.

> Of course
> there are more important, code structure related reasons beyond that,
> but let's not digress. I'm guessing current devs are so used to this
> that they wouldn't accept splitting-up changes anyway.

There are definitely improvements that could be made to
the x86 code, and where splitting of files makes conceptual
sense it's certainly worthwhile. The trick is finding the
right logical splitting points.

thanks
-- PMM

[Qemu-devel] [Bug 1795100] Re: unix-domain socket unlink()ed prematurely

[LukeShu]

This is still a problem with 3.1.0.

** Summary changed:

- unix-domain socket unlink()ed prematurely
+ VNC unix-domain socket unlink()ed prematurely

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

Title:
  VNC unix-domain socket unlink()ed prematurely

Status in QEMU:
  New

Bug description:
  With qemu 3.0.0 (I don't believe this happened with previous
  versions), if I tell it `-vnc unix:/path/to/vnc.sock`, qemu will
  unlink() that file when the first client disconnects, meaning that
  once I disconnect, I can't ever reconnect without restarting the VM.

  A stupid testcase demonstrating the issue:

  In terminal A:

  $ qemu-system-x86_64 -vnc unix:$PWD/vnc.sock

  In terminal B:

  $ ls vnc.sock
  vnc.sock
  $ socat STDIO UNIX-CONNECT:vnc.sock <<<''
  RFB 003.008
  $ ls vnc.sock
  ls: cannot access 'vnc.sock': No such file or directory

  I have determined that the offending unlink() call is the one in
  io/channel-socket.c:qio_channel_socket_close().  That call was first
  introduced in commit d66f78e1eaa832f73c771d9df1b606fe75d52a50, which
  first appeared in version 3.0.0.

  This type of premature unlink() does not happen on monitor.sock with
  `-monitor unix:/path/to/monitor.sock,server,nowait`.

  I am not familiar enough with the QIO subsystem to suggest a fix that
  fixes VNC, but preserves the QMP fix targeted in the offending commit.

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

Re: [Qemu-devel] [PATCH v3 16/16] virtio: virtio 9p really requires CONFIG_VIRTFS to work

[Greg Kurz]

On Thu, 13 Dec 2018 22:00:57 +0100
Juan Quintela  wrote:

> Signed-off-by: Juan Quintela 
> ---

Reviewed-by: Greg Kurz 

>  default-configs/virtio.mak | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/default-configs/virtio.mak b/default-configs/virtio.mak
> index 5ae4a61018..ecb4420e74 100644
> --- a/default-configs/virtio.mak
> +++ b/default-configs/virtio.mak
> @@ -1,7 +1,7 @@
>  CONFIG_VHOST_USER_SCSI=$(call land,$(CONFIG_VHOST_USER),$(CONFIG_LINUX))
>  CONFIG_VHOST_USER_BLK=$(call land,$(CONFIG_VHOST_USER),$(CONFIG_LINUX))
>  CONFIG_VIRTIO=y
> -CONFIG_VIRTIO_9P=y
> +CONFIG_VIRTIO_9P=$(CONFIG_VIRTFS)
>  CONFIG_VIRTIO_BALLOON=y
>  CONFIG_VIRTIO_BLK=y
>  CONFIG_VIRTIO_CRYPTO=y

Re: [Qemu-devel] [PATCH v3 06/16] virtio: split virtio 9p bits from virtio-pci

[Greg Kurz]

On Thu, 13 Dec 2018 22:00:47 +0100
Juan Quintela  wrote:

> Reviewed-by: Laurent Vivier 
> Signed-off-by: Juan Quintela 
> 
> ---
> 

Acked-by: Greg Kurz 

> Also disable virtio9p test (lvivier)
> ---
>  hw/virtio/Makefile.objs   |  1 +
>  hw/virtio/virtio-9p-pci.c | 86 +++
>  hw/virtio/virtio-pci.c| 52 ---
>  hw/virtio/virtio-pci.h| 20 -
>  tests/Makefile.include|  2 +-
>  5 files changed, 88 insertions(+), 73 deletions(-)
>  create mode 100644 hw/virtio/virtio-9p-pci.c
> 
> diff --git a/hw/virtio/Makefile.objs b/hw/virtio/Makefile.objs
> index 9e33104ce6..3e655fdce6 100644
> --- a/hw/virtio/Makefile.objs
> +++ b/hw/virtio/Makefile.objs
> @@ -17,6 +17,7 @@ obj-$(CONFIG_VIRTIO_INPUT_HOST) += virtio-input-host-pci.o
>  obj-$(CONFIG_VIRTIO_INPUT) += virtio-input-pci.o
>  obj-$(CONFIG_VIRTIO_RNG) += virtio-rng-pci.o
>  obj-$(CONFIG_VIRTIO_BALLOON) += virtio-balloon-pci.o
> +obj-$(CONFIG_VIRTIO_9P) += virtio-9p-pci.o
>  endif
>  endif
>  
> diff --git a/hw/virtio/virtio-9p-pci.c b/hw/virtio/virtio-9p-pci.c
> new file mode 100644
> index 00..74c6ca2ddb
> --- /dev/null
> +++ b/hw/virtio/virtio-9p-pci.c
> @@ -0,0 +1,86 @@
> +/*
> + * Virtio 9p PCI Bindings
> + *
> + * Copyright IBM, Corp. 2010
> + *
> + * Authors:
> + *  Anthony Liguori   
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2.  See
> + * the COPYING file in the top-level directory.
> + *
> + * Contributions after 2012-01-13 are licensed under the terms of the
> + * GNU GPL, version 2 or (at your option) any later version.
> + */
> +
> +#include "qemu/osdep.h"
> +
> +#include "virtio-pci.h"
> +#include "hw/9pfs/virtio-9p.h"
> +
> +/*
> + * virtio-9p-pci: This extends VirtioPCIProxy.
> + */
> +
> +#define TYPE_VIRTIO_9P_PCI "virtio-9p-pci"
> +#define VIRTIO_9P_PCI(obj) \
> +OBJECT_CHECK(V9fsPCIState, (obj), TYPE_VIRTIO_9P_PCI)
> +
> +typedef struct V9fsPCIState {
> +VirtIOPCIProxy parent_obj;
> +V9fsVirtioState vdev;
> +} V9fsPCIState;
> +
> +static void virtio_9p_pci_realize(VirtIOPCIProxy *vpci_dev, Error **errp)
> +{
> +V9fsPCIState *dev = VIRTIO_9P_PCI(vpci_dev);
> +DeviceState *vdev = DEVICE(&dev->vdev);
> +
> +qdev_set_parent_bus(vdev, BUS(&vpci_dev->bus));
> +object_property_set_bool(OBJECT(vdev), true, "realized", errp);
> +}
> +
> +static Property virtio_9p_pci_properties[] = {
> +DEFINE_PROP_BIT("ioeventfd", VirtIOPCIProxy, flags,
> +VIRTIO_PCI_FLAG_USE_IOEVENTFD_BIT, true),
> +DEFINE_PROP_UINT32("vectors", VirtIOPCIProxy, nvectors, 2),
> +DEFINE_PROP_END_OF_LIST(),
> +};
> +
> +static void virtio_9p_pci_class_init(ObjectClass *klass, void *data)
> +{
> +DeviceClass *dc = DEVICE_CLASS(klass);
> +PCIDeviceClass *pcidev_k = PCI_DEVICE_CLASS(klass);
> +VirtioPCIClass *k = VIRTIO_PCI_CLASS(klass);
> +
> +k->realize = virtio_9p_pci_realize;
> +pcidev_k->vendor_id = PCI_VENDOR_ID_REDHAT_QUMRANET;
> +pcidev_k->device_id = PCI_DEVICE_ID_VIRTIO_9P;
> +pcidev_k->revision = VIRTIO_PCI_ABI_VERSION;
> +pcidev_k->class_id = 0x2;
> +set_bit(DEVICE_CATEGORY_STORAGE, dc->categories);
> +dc->props = virtio_9p_pci_properties;
> +}
> +
> +static void virtio_9p_pci_instance_init(Object *obj)
> +{
> +V9fsPCIState *dev = VIRTIO_9P_PCI(obj);
> +
> +virtio_instance_init_common(obj, &dev->vdev, sizeof(dev->vdev),
> +TYPE_VIRTIO_9P);
> +}
> +
> +static const TypeInfo virtio_9p_pci_info = {
> +.name  = TYPE_VIRTIO_9P_PCI,
> +.parent= TYPE_VIRTIO_PCI,
> +.instance_size = sizeof(V9fsPCIState),
> +.instance_init = virtio_9p_pci_instance_init,
> +.class_init= virtio_9p_pci_class_init,
> +};
> +
> +static void virtio_9p_pci_register(void)
> +{
> +type_register_static(&virtio_9p_pci_info);
> +}
> +
> +type_init(virtio_9p_pci_register)
> diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
> index 855a7fdd40..bad9279f19 100644
> --- a/hw/virtio/virtio-pci.c
> +++ b/hw/virtio/virtio-pci.c
> @@ -1077,55 +1077,6 @@ static void virtio_pci_vmstate_change(DeviceState *d, 
> bool running)
>  }
>  }
>  
> -#ifdef CONFIG_VIRTFS
> -static void virtio_9p_pci_realize(VirtIOPCIProxy *vpci_dev, Error **errp)
> -{
> -V9fsPCIState *dev = VIRTIO_9P_PCI(vpci_dev);
> -DeviceState *vdev = DEVICE(&dev->vdev);
> -
> -qdev_set_parent_bus(vdev, BUS(&vpci_dev->bus));
> -object_property_set_bool(OBJECT(vdev), true, "realized", errp);
> -}
> -
> -static Property virtio_9p_pci_properties[] = {
> -DEFINE_PROP_BIT("ioeventfd", VirtIOPCIProxy, flags,
> -VIRTIO_PCI_FLAG_USE_IOEVENTFD_BIT, true),
> -DEFINE_PROP_UINT32("vectors", VirtIOPCIProxy, nvectors, 2),
> -DEFINE_PROP_END_OF_LIST(),
> -};
> -
> -static void virtio_9p_pci_class_init(ObjectClass *klass, void *data)
> -{
> -DeviceClass *dc = DEVICE_CLASS(klass);
> -PCIDeviceClass *pcidev_k = PCI_DE

Re: [Qemu-devel] [PATCH] smbus_eeprom: Limit data writes to 255 bytes

[Michael Hanselmann]

Hi Philippe

On 27.12.18 20:03, Philippe Mathieu-Daudé wrote:
> On Thu, Dec 27, 2018 at 12:53 PM Michael Hanselmann  wrote:
> > The "eeprom_write_data" function in "smbus_eeprom.c" had no provisions
> > to limit the length of data written. If a caller were able to manipulate
> > the "len" parameter they could potentially write before or after the
> > target buffer.
> 
> You forgot to sign your commit:
> "Signed-off-by: Michael Hanselmann "

Indeed I did and I'm sorry.

Signed-off-by: Michael Hanselmann 

>> diff --git a/hw/i2c/smbus_eeprom.c b/hw/i2c/smbus_eeprom.c
>> index f18aa3de35..74fa1c328c 100644
>> --- a/hw/i2c/smbus_eeprom.c
>> +++ b/hw/i2c/smbus_eeprom.c
>> @@ -76,6 +76,7 @@ static void eeprom_write_data(SMBusDevice *dev, uint8_t 
>> cmd, uint8_t *buf, int l
>> It is a block write without a length byte.  Fortunately we
>> get the full block anyway.  */
>>  /* TODO: Should this set the current location?  */
>> +len &= 0xff;
>>  if (cmd + len > 256)
> 
> Corey Minyard sent a cleanup series [1] because this device model is
> known to be unsafe and need rewrite.
> There is a particular patch [2] which add the SMBUS_EEPROM_SIZE definition.
> He also provided a intent at cleaning this problem here [3] where
> Peter suggested to split it in fewer patches.

I agree with the assessment that the code as-is has room for
improvement, especially when it comes to the hardcoded sizes. My patch
is purely on top of the master branch (ca. QEMU 3.1.0).

Best regards,
Michael



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH] smbus_eeprom: Limit data writes to 255 bytes

[Michael Hanselmann]

Hi Paolo

On 28.12.18 14:52, Paolo Bonzini wrote:
> On 27/12/18 12:51, Michael Hanselmann wrote:
>> The "eeprom_write_data" function in "smbus_eeprom.c" had no provisions
>> to limit the length of data written. If a caller were able to manipulate
>> the "len" parameter they could potentially write before or after the
>> target buffer.
>> ---
>>  hw/i2c/smbus_eeprom.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/hw/i2c/smbus_eeprom.c b/hw/i2c/smbus_eeprom.c
>> index f18aa3de35..74fa1c328c 100644
>> --- a/hw/i2c/smbus_eeprom.c
>> +++ b/hw/i2c/smbus_eeprom.c
>> @@ -76,6 +76,7 @@ static void eeprom_write_data(SMBusDevice *dev, uint8_t 
>> cmd, uint8_t *buf, int l
>> It is a block write without a length byte.  Fortunately we
>> get the full block anyway.  */
>>  /* TODO: Should this set the current location?  */
>> +len &= 0xff;
>>  if (cmd + len > 256)
>>  n = 256 - cmd;
>>  else
>>
> 
> Note that len is limited to 33 bytes (smbus_do_write and smbus_i2c_send).

In practice it turns out to be the case. I thought I had discovered an
out-of-bounds write because hw/i2c/smbus.c:smbus_i2c_recv increases
dev->data_len unconditionally. The I2C controller implemented in
hw/i2c/aspeed_i2c.c and used by certain ARM board emulations allows
fine-grained control of the communication which allowed me to increase
data_len easily (up to and beyond an overflow if intended). It was only
the state machine in smbus.c which made it impossible to actually get to
a usable point in my experiment (increasing data_len requires
SMBUS_WRITE_DATA->SMBUS_READ_DATA, then the communication must be
stopped via NACK to avoid resetting data_len in I2C_FINISH, but there's
no way from SMBUS_DONE to SMBUS_WRITE_DATA).

Adding bitwise-and for 0xff defuses this particular situation regardless
of what state an attacker can bring the emulated devices into.

Best regards,
Michael



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [RFC PATCH 04/13] tests/tcg/mips: enable mips32-dsp/mips32-dspr2/mipsr5900 linux-user (WIP)

[Aleksandar Markovic]

> Will you be testing the build as is with the current Makefiles?

I will, but they should be replaced with your versions - in new directories.

v1 of my reorganization series seems to be broken on the list for some reason, 
but I will send v2 (hopefully more complete and improved) after New Year.

Thanks!!
Happy holidays!

Aleksandar

Re: [Qemu-devel] AVX support for TCG

[Nick Renieris]

Στις Παρ, 28 Δεκ 2018 στις 4:39 μ.μ., ο/η Peter Maydell
 έγραψε:
> If your editor can't show multiple views onto one file with
> the same simplicity and UI as it has for multiple different
> files then I would suggest getting a better editor :-)

Apparently I just didn't know how to use my editor :) In my defense,
I've never had to do this before.

> Unless you want to restrict all your files to 100 lines or
> shorter then you need to be able to see multiple parts of them
> at once -- one 10,000 line file is no worse than 4 2500 line
> files for this.

As you mention below, logical separation is key here, I definitely
didn't mean that there should be arbitrary LoC limits for each file.

> There are definitely improvements that could be made to
> the x86 code, and where splitting of files makes conceptual
> sense it's certainly worthwhile. The trick is finding the
> right logical splitting points.

Agreed, though it's not something I can personally help on, unless I
spend quite a long time getting acquainted with _this_ code first.

I'd like to get some answers to my previous question about estimates
of the total amount of work required before considering diving into
it.

Re: [Qemu-devel] [PATCH v2 6/8] tests: smbios: fetch whole table in one step instead of reading it step by step

[Philippe Mathieu-Daudé]

On 12/27/18 3:13 PM, Igor Mammedov wrote:
> replace a bunch of ACPI_READ_ARRAY/ACPI_READ_FIELD macro, that read
> SMBIOS table field by field with one memread() to fetch whole table
> at once and drop no longer used ACPI_READ_ARRAY/ACPI_READ_FIELD macro.
> 
> Signed-off-by: Igor Mammedov 

Reviewed-by: Philippe Mathieu-Daudé 

> ---
> V2:
>   rebase: s/memread/qtest_memread/
> ---
>  tests/acpi-utils.h   | 17 -
>  tests/bios-tables-test.c | 15 +--
>  2 files changed, 1 insertion(+), 31 deletions(-)
> 
> diff --git a/tests/acpi-utils.h b/tests/acpi-utils.h
> index 1aa00db..cb7183e 100644
> --- a/tests/acpi-utils.h
> +++ b/tests/acpi-utils.h
> @@ -30,23 +30,6 @@ typedef struct {
>  bool tmp_files_retain;   /* do not delete the temp asl/aml */
>  } AcpiSdtTable;
>  
> -#define ACPI_READ_FIELD(qts, field, addr)\
> -do { \
> -qtest_memread(qts, addr, &field, sizeof(field)); \
> -addr += sizeof(field);   \
> -} while (0)
> -
> -#define ACPI_READ_ARRAY_PTR(qts, arr, length, addr)  \
> -do { \
> -int idx; \
> -for (idx = 0; idx < length; ++idx) { \
> -ACPI_READ_FIELD(qts, arr[idx], addr);\
> -}\
> -} while (0)
> -
> -#define ACPI_READ_ARRAY(qts, arr, addr) \
> -ACPI_READ_ARRAY_PTR(qts, arr, sizeof(arr) / sizeof(arr[0]), addr)
> -
>  #define ACPI_ASSERT_CMP(actual, expected) do { \
>  char ACPI_ASSERT_CMP_str[5] = {}; \
>  memcpy(ACPI_ASSERT_CMP_str, &actual, 4); \
> diff --git a/tests/bios-tables-test.c b/tests/bios-tables-test.c
> index 8fdd1c1..dcd6be8 100644
> --- a/tests/bios-tables-test.c
> +++ b/tests/bios-tables-test.c
> @@ -406,32 +406,19 @@ static bool smbios_ep_table_ok(test_data *data)
>  struct smbios_21_entry_point *ep_table = &data->smbios_ep_table;
>  uint32_t addr = data->smbios_ep_addr;
>  
> -ACPI_READ_ARRAY(data->qts, ep_table->anchor_string, addr);
> +qtest_memread(data->qts, addr, ep_table, sizeof(*ep_table));
>  if (memcmp(ep_table->anchor_string, "_SM_", 4)) {
>  return false;
>  }
> -ACPI_READ_FIELD(data->qts, ep_table->checksum, addr);
> -ACPI_READ_FIELD(data->qts, ep_table->length, addr);
> -ACPI_READ_FIELD(data->qts, ep_table->smbios_major_version, addr);
> -ACPI_READ_FIELD(data->qts, ep_table->smbios_minor_version, addr);
> -ACPI_READ_FIELD(data->qts, ep_table->max_structure_size, addr);
> -ACPI_READ_FIELD(data->qts, ep_table->entry_point_revision, addr);
> -ACPI_READ_ARRAY(data->qts, ep_table->formatted_area, addr);
> -ACPI_READ_ARRAY(data->qts, ep_table->intermediate_anchor_string, addr);
>  if (memcmp(ep_table->intermediate_anchor_string, "_DMI_", 5)) {
>  return false;
>  }
> -ACPI_READ_FIELD(data->qts, ep_table->intermediate_checksum, addr);
> -ACPI_READ_FIELD(data->qts, ep_table->structure_table_length, addr);
>  if (ep_table->structure_table_length == 0) {
>  return false;
>  }
> -ACPI_READ_FIELD(data->qts, ep_table->structure_table_address, addr);
> -ACPI_READ_FIELD(data->qts, ep_table->number_of_structures, addr);
>  if (ep_table->number_of_structures == 0) {
>  return false;
>  }
> -ACPI_READ_FIELD(data->qts, ep_table->smbios_bcd_revision, addr);
>  if (acpi_calc_checksum((uint8_t *)ep_table, sizeof *ep_table) ||
>  acpi_calc_checksum((uint8_t *)ep_table + 0x10,
> sizeof *ep_table - 0x10)) {
> 

Re: [Qemu-devel] d_off field in struct dirent and 32-on-64 emulation

[Andy Lutomirski]

[sending again, slightly edited, due to email client issues]

On Thu, Dec 27, 2018 at 9:25 AM Florian Weimer  wrote:
>
> We have a bit of an interesting problem with respect to the d_off
> field in struct dirent.
>
> When running a 64-bit kernel on certain file systems, notably ext4,
> this field uses the full 63 bits even for small directories (strace -v
> output, wrapped here for readability):
>
> getdents(3, [
>   {d_ino=1494304, d_off=3901177228673045825, d_reclen=40, 
> d_name="authorized_keys", d_type=DT_REG},
>   {d_ino=1494277, d_off=7491915799041650922, d_reclen=24, d_name=".", 
> d_type=DT_DIR},
>   {d_ino=1314655, d_off=9223372036854775807, d_reclen=24, d_name="..", 
> d_type=DT_DIR}
> ], 32768) = 88
>
> When running in 32-bit compat mode, this value is somehow truncated to
> 31 bits, for both the getdents and the getdents64 (!) system call (at
> least on i386).
>

...

>
> However, both qemu-user and the 9p file system can run in such a way
> that the kernel is entered from a 64-bit process, but the actual usage
> is from a 32-bit process:


I imagine that at least some of the problems you're seeing are due to this bug:

https://lkml.org/lkml/2018/10/18/859

Presumably the right fix involves modifying the relevant VFS file
operations to indicate the relevant ABI to the implementations.  I
would guess that 9p is triggering the “not really in the syscall you
think you’re in” issue.

[Qemu-devel] [PATCH v4 5/5] migration: Use strnlen() for fixed-size string

[Philippe Mathieu-Daudé]

GCC 8 introduced the -Wstringop-overflow, which detect buffer overflow
by string-modifying functions declared in , such strncpy(),
used in global_state_store_running().

GCC indeed found an incorrect use of strlen(), because this array
is loaded by VMSTATE_BUFFER(runstate, GlobalState) then parsed
using qapi_enum_parse which does not get the buffer length.

Use strnlen() which returns sizeof(s->runstate) if the array is not
NUL-terminated, assert the size is within range, and enforce the array
to be NUL-terminated to avoid an overflow in qapi_enum_parse().

This fixes:

CC  migration/global_state.o
  qemu/migration/global_state.c: In function 'global_state_pre_save':
  qemu/migration/global_state.c:109:15: error: 'strlen' argument 1 declared 
attribute 'nonstring' [-Werror=stringop-overflow=]
   s->size = strlen((char *)s->runstate) + 1;
 ^~~
  qemu/migration/global_state.c:24:13: note: argument 'runstate' declared here
   uint8_t runstate[100] QEMU_NONSTRING;
   ^~~~
  cc1: all warnings being treated as errors
  make: *** [qemu/rules.mak:69: migration/global_state.o] Error 1

Suggested-by: Michael S. Tsirkin 
Signed-off-by: Philippe Mathieu-Daudé 
---
 migration/global_state.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/migration/global_state.c b/migration/global_state.c
index 01805c567a..4f060a6dbd 100644
--- a/migration/global_state.c
+++ b/migration/global_state.c
@@ -89,6 +89,16 @@ static int global_state_post_load(void *opaque, int 
version_id)
 s->received = true;
 trace_migrate_global_state_post_load(runstate);
 
+if (strnlen((char *)s->runstate,
+sizeof(s->runstate)) == sizeof(s->runstate)) {
+/* This condition should never happen during migration, because
+ * all runstate names are shorter than 100 bytes (the size of
+ * s->runstate). However, a malicious stream could overflow
+ * the qapi_enum_parse() call, so we force the last character
+ * to a NUL byte.
+ */
+s->runstate[sizeof(s->runstate) - 1] = '\0';
+}
 r = qapi_enum_parse(&RunState_lookup, runstate, -1, &local_err);
 
 if (r == -1) {
@@ -107,7 +117,8 @@ static int global_state_pre_save(void *opaque)
 GlobalState *s = opaque;
 
 trace_migrate_global_state_pre_save((char *)s->runstate);
-s->size = strlen((char *)s->runstate) + 1;
+s->size = strnlen((char *)s->runstate, sizeof(s->runstate)) + 1;
+assert(s->size <= sizeof(s->runstate));
 
 return 0;
 }
-- 
2.17.2

[Qemu-devel] [PATCH v4 2/5] block/sheepdog: Use QEMU_NONSTRING for non NUL-terminated arrays

[Philippe Mathieu-Daudé]

GCC 8 added a -Wstringop-truncation warning:

  The -Wstringop-truncation warning added in GCC 8.0 via r254630 for
  bug 81117 is specifically intended to highlight likely unintended
  uses of the strncpy function that truncate the terminating NUL
  character from the source string.

This new warning leads to compilation failures:

CC  block/sheepdog.o
  qemu/block/sheepdog.c: In function 'find_vdi_name':
  qemu/block/sheepdog.c:1239:5: error: 'strncpy' specified bound 256 equals 
destination size [-Werror=stringop-truncation]
   strncpy(buf + SD_MAX_VDI_LEN, tag, SD_MAX_VDI_TAG_LEN);
   ^~
  make: *** [qemu/rules.mak:69: block/sheepdog.o] Error 1

As described previous to the strncpy() calls, the use of strncpy() is
correct here:

/* This pair of strncpy calls ensures that the buffer is zero-filled,
 * which is desirable since we'll soon be sending those bytes, and
 * don't want the send_req to read uninitialized data.
 */
strncpy(buf, filename, SD_MAX_VDI_LEN);
strncpy(buf + SD_MAX_VDI_LEN, tag, SD_MAX_VDI_TAG_LEN);

Use the QEMU_NONSTRING attribute, since this array is intended to store
character arrays that do not necessarily contain a terminating NUL.

Suggested-by: Michael S. Tsirkin 
Reviewed-by: Eric Blake 
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Philippe Mathieu-Daudé 
---
 block/sheepdog.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/block/sheepdog.c b/block/sheepdog.c
index 0125df9d49..5cd9618432 100644
--- a/block/sheepdog.c
+++ b/block/sheepdog.c
@@ -1224,7 +1224,7 @@ static int find_vdi_name(BDRVSheepdogState *s, const char 
*filename,
 SheepdogVdiReq hdr;
 SheepdogVdiRsp *rsp = (SheepdogVdiRsp *)&hdr;
 unsigned int wlen, rlen = 0;
-char buf[SD_MAX_VDI_LEN + SD_MAX_VDI_TAG_LEN];
+char buf[SD_MAX_VDI_LEN + SD_MAX_VDI_TAG_LEN] QEMU_NONSTRING;
 
 fd = connect_to_sdog(s, errp);
 if (fd < 0) {
-- 
2.17.2

[Qemu-devel] [PATCH v4 0/5] Fix strncpy() warnings for GCC8 new -Wstringop-truncation

[Philippe Mathieu-Daudé]

GCC 8 new warning prevents builds to success since quite some time.
First report on the mailing list is in July 2018:
https://lists.gnu.org/archive/html/qemu-devel/2018-07/msg03723.html

Since v3:
- patch 1: make sens of description (eblake)
- patch 2: append QEMU_NONSTRING instead of prepending it (mst)
- patch 3: rebased (imammedo), intented
- patch 4: replaced by Marc-André first attempt, improved doc
- patch 5: add assert() and NUL-terminate the buffer (mst)

Various intents has been sent to fix this:
- Incorrectly using g_strlcpy()
  https://lists.gnu.org/archive/html/qemu-devel/2018-08/msg03705.html
  https://lists.gnu.org/archive/html/qemu-devel/2018-08/msg03706.html
- Using assert() and strpadcpy()
  https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg03938.html
  This was the approch taken by the previous v2:
  https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg04405.html
- Use #pragma GCC diagnostic ignored "-Wstringop-truncation"
  https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg04261.html
- adding an inline wrapper with said pragma in there
  https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg04261.html
- -Wno-stringop-truncation is the makefile
  https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg04261.html
- Use the 'nonstring' attribute
  https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg04493.html

This series add the QEMU_NONSTRING definition and use it.

Regards,

Phil.

Marc-André Lureau (1):
  migration: Fix stringop-truncation warning

Philippe Mathieu-Daudé (4):
  qemu/compiler: Define QEMU_NONSTRING
  block/sheepdog: Use QEMU_NONSTRING for non NUL-terminated arrays
  hw/acpi: Use QEMU_NONSTRING for non NUL-terminated arrays
  migration: Use strnlen() for fixed-size string

 block/sheepdog.c|  2 +-
 hw/acpi/core.c  | 12 
 include/hw/acpi/acpi-defs.h | 13 -
 include/qemu/compiler.h | 15 +++
 migration/global_state.c| 14 +-
 5 files changed, 45 insertions(+), 11 deletions(-)

-- 
2.17.2

[Qemu-devel] [PATCH v4 1/5] qemu/compiler: Define QEMU_NONSTRING

[Philippe Mathieu-Daudé]

GCC 8 introduced the -Wstringop-truncation checker to detect truncation by
the strncat and strncpy functions (closely related to -Wstringop-overflow,
which detect buffer overflow by string-modifying functions declared in
).

In tandem of -Wstringop-truncation, the "nonstring" attribute was added:

  The nonstring variable attribute specifies that an object or member
  declaration with type array of char, signed char, or unsigned char,
  or pointer to such a type is intended to store character arrays that
  do not necessarily contain a terminating NUL. This is useful in detecting
  uses of such arrays or pointers with functions that expect NUL-terminated
  strings, and to avoid warnings when such an array or pointer is used as
  an argument to a bounded string manipulation function such as strncpy.

  From the GCC manual: 
https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html#index-nonstring-variable-attribute

Add the QEMU_NONSTRING macro which checks if the compiler supports this
attribute.

Suggested-by: Michael S. Tsirkin 
Reviewed-by: Eric Blake 
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Philippe Mathieu-Daudé 
---
v4: reordered the commit description to make sens (eblake)

Note this trigger the following checkpatch warning (patchew):

  WARNING: architecture specific defines should be avoided
  #50: FILE: include/qemu/compiler.h:163:
  +#if __has_attribute(nonstring)
---
 include/qemu/compiler.h | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/include/qemu/compiler.h b/include/qemu/compiler.h
index 261842beae..2d8f507c73 100644
--- a/include/qemu/compiler.h
+++ b/include/qemu/compiler.h
@@ -151,6 +151,21 @@
 # define QEMU_ERROR(X)
 #endif
 
+/*
+ * The nonstring variable attribute specifies that an object or member
+ * declaration with type array of char or pointer to char is intended
+ * to store character arrays that do not necessarily contain a terminating
+ * NUL character. This is useful in detecting uses of such arrays or pointers
+ * with functions that expect NUL-terminated strings, and to avoid warnings
+ * when such an array or pointer is used as an argument to a bounded string
+ * manipulation function such as strncpy.
+ */
+#if __has_attribute(nonstring)
+# define QEMU_NONSTRING __attribute__((nonstring))
+#else
+# define QEMU_NONSTRING
+#endif
+
 /* Implement C11 _Generic via GCC builtins.  Example:
  *
  *QEMU_GENERIC(x, (float, sinf), (long double, sinl), sin) (x)
-- 
2.17.2

[Qemu-devel] [PATCH v4 4/5] migration: Fix stringop-truncation warning

[Philippe Mathieu-Daudé]

From: Marc-André Lureau 

GCC 8 added a -Wstringop-truncation warning:

  The -Wstringop-truncation warning added in GCC 8.0 via r254630 for
  bug 81117 is specifically intended to highlight likely unintended
  uses of the strncpy function that truncate the terminating NUL
  character from the source string.

This new warning leads to compilation failures:

CC  migration/global_state.o
  qemu/migration/global_state.c: In function 'global_state_store_running':
  qemu/migration/global_state.c:45:5: error: 'strncpy' specified bound 100 
equals destination size [-Werror=stringop-truncation]
   strncpy((char *)global_state.runstate, state, 
sizeof(global_state.runstate));
   
^~~~
  make: *** [qemu/rules.mak:69: migration/global_state.o] Error 1

Adding an assert is enough to silence GCC.

(alternatively, we could hard-code "running")

Signed-off-by: Marc-André Lureau 
Reviewed-by: Eric Blake 
Reviewed-by: Dr. David Alan Gilbert 
Reviewed-by: Philippe Mathieu-Daudé 
[PMD: More verbose commit message]
Signed-off-by: Philippe Mathieu-Daudé 
---
 migration/global_state.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/migration/global_state.c b/migration/global_state.c
index 8e8ab5c51e..01805c567a 100644
--- a/migration/global_state.c
+++ b/migration/global_state.c
@@ -42,6 +42,7 @@ int global_state_store(void)
 void global_state_store_running(void)
 {
 const char *state = RunState_str(RUN_STATE_RUNNING);
+assert(strlen(state) < sizeof(global_state.runstate));
 strncpy((char *)global_state.runstate,
state, sizeof(global_state.runstate));
 }
-- 
2.17.2

[Qemu-devel] [PATCH v4 3/5] hw/acpi: Use QEMU_NONSTRING for non NUL-terminated arrays

[Philippe Mathieu-Daudé]

GCC 8 added a -Wstringop-truncation warning:

  The -Wstringop-truncation warning added in GCC 8.0 via r254630 for
  bug 81117 is specifically intended to highlight likely unintended
  uses of the strncpy function that truncate the terminating NUL
  character from the source string.

This new warning leads to compilation failures:

CC  hw/acpi/core.o
  In function 'acpi_table_install', inlined from 'acpi_table_add' at 
qemu/hw/acpi/core.c:296:5:
  qemu/hw/acpi/core.c:184:9: error: 'strncpy' specified bound 4 equals 
destination size [-Werror=stringop-truncation]
   strncpy(ext_hdr->sig, hdrs->sig, sizeof ext_hdr->sig);
   ^
  make: *** [qemu/rules.mak:69: hw/acpi/core.o] Error 1

Use the QEMU_NONSTRING attribute, since ACPI tables don't require the
strings to be NUL-terminated.

Suggested-by: Michael S. Tsirkin 
Reviewed-by: Michael S. Tsirkin 
Reviewed-by: Igor Mammedov 
Signed-off-by: Philippe Mathieu-Daudé 
---
v4: rebased

Note this triggers the following checkpatch error (patchew):

  ERROR: space prohibited before open square bracket '['
  #64: FILE: include/hw/acpi/acpi-defs.h:43:
  +uint8_t  oem_id [6] QEMU_NONSTRING; /* OEM identification */
---
 hw/acpi/core.c  | 12 
 include/hw/acpi/acpi-defs.h | 13 -
 2 files changed, 16 insertions(+), 9 deletions(-)

diff --git a/hw/acpi/core.c b/hw/acpi/core.c
index d6f0709691..47877c0ec1 100644
--- a/hw/acpi/core.c
+++ b/hw/acpi/core.c
@@ -35,14 +35,18 @@
 struct acpi_table_header {
 uint16_t _length; /* our length, not actual part of the hdr */
   /* allows easier parsing for fw_cfg clients */
-char sig[4];  /* ACPI signature (4 ASCII characters) */
+char sig[4]
+ QEMU_NONSTRING;  /* ACPI signature (4 ASCII characters) */
 uint32_t length;  /* Length of table, in bytes, including header */
 uint8_t revision; /* ACPI Specification minor version # */
 uint8_t checksum; /* To make sum of entire table == 0 */
-char oem_id[6];   /* OEM identification */
-char oem_table_id[8]; /* OEM table identification */
+char oem_id[6]
+ QEMU_NONSTRING;  /* OEM identification */
+char oem_table_id[8]
+ QEMU_NONSTRING;  /* OEM table identification */
 uint32_t oem_revision;/* OEM revision number */
-char asl_compiler_id[4];  /* ASL compiler vendor ID */
+char asl_compiler_id[4]
+ QEMU_NONSTRING;  /* ASL compiler vendor ID */
 uint32_t asl_compiler_revision; /* ASL compiler revision number */
 } QEMU_PACKED;
 
diff --git a/include/hw/acpi/acpi-defs.h b/include/hw/acpi/acpi-defs.h
index 5021cb9e79..17f72e9553 100644
--- a/include/hw/acpi/acpi-defs.h
+++ b/include/hw/acpi/acpi-defs.h
@@ -41,8 +41,8 @@ enum {
 };
 
 typedef struct AcpiRsdpData {
-uint8_t oem_id[6]; /* OEM identification */
-uint8_t revision;  /* Must be 0 for 1.0, 2 for 2.0 */
+uint8_t oem_id[6] QEMU_NONSTRING; /* OEM identification */
+uint8_t revision; /* Must be 0 for 1.0, 2 for 2.0 */
 
 unsigned *rsdt_tbl_offset;
 unsigned *xsdt_tbl_offset;
@@ -57,10 +57,13 @@ typedef struct AcpiRsdpData {
 uint32_t length; /* Length of table, in bytes, including 
header */ \
 uint8_t  revision;   /* ACPI Specification minor version # */ \
 uint8_t  checksum;   /* To make sum of entire table == 0 */ \
-uint8_t  oem_id [6]; /* OEM identification */ \
-uint8_t  oem_table_id [8];   /* OEM table identification */ \
+uint8_t  oem_id [6] \
+ QEMU_NONSTRING; /* OEM identification */ \
+uint8_t  oem_table_id [8] \
+ QEMU_NONSTRING; /* OEM table identification */ \
 uint32_t oem_revision;   /* OEM revision number */ \
-uint8_t  asl_compiler_id [4];/* ASL compiler vendor ID */ \
+uint8_t  asl_compiler_id [4] \
+ QEMU_NONSTRING; /* ASL compiler vendor ID */ \
 uint32_t asl_compiler_revision;  /* ASL compiler revision number */
 
 
-- 
2.17.2

[Qemu-devel] [PATCH] qmp: Add examples to qom list, get, and set commands

[Wainer dos Santos Moschetta]

Added examples for the qom-list, qom-get, and qom-set
commands in qapi misc JSON file.

Signed-off-by: Wainer dos Santos Moschetta 
---
 qapi/misc.json | 36 
 1 file changed, 36 insertions(+)

diff --git a/qapi/misc.json b/qapi/misc.json
index 24d20a880a..426274ecf8 100644
--- a/qapi/misc.json
+++ b/qapi/misc.json
@@ -1380,6 +1380,16 @@
 #  object.
 #
 # Since: 1.2
+#
+# Example:
+#
+# -> { "execute": "qom-list",
+#  "arguments": { "path": "/chardevs" } }
+# <- { "return": [ { "name": "type", "type": "string" },
+#  { "name": "parallel0", "type": "child" },
+#  { "name": "serial0", "type": "child" },
+#  { "name": "mon0", "type": "child" } ] }
+#
 ##
 { 'command': 'qom-list',
   'data': { 'path': 'str' },
@@ -1417,6 +1427,23 @@
 #  returned as #int.
 #
 # Since: 1.2
+#
+# Example:
+#
+# 1. Use absolute path
+#
+# -> { "execute": "qom-get",
+#  "arguments": { "path": "/machine/unattached/device[0]",
+# "property": "hotplugged" } }
+# <- { "return": false }
+#
+# 2. Use partial path
+#
+# -> { "execute": "qom-get",
+#  "arguments": { "path": "unattached/sysbus",
+# "property": "type" } }
+# <- { "return": "System" }
+#
 ##
 { 'command': 'qom-get',
   'data': { 'path': 'str', 'property': 'str' },
@@ -1436,6 +1463,15 @@
 # for a description of type mapping.
 #
 # Since: 1.2
+#
+# Example:
+#
+# -> { "execute": "qom-set",
+#  "arguments": { "path": "/machine",
+# "property": "graphics",
+# "value": false } }
+# <- { "return": {} }
+#
 ##
 { 'command': 'qom-set',
   'data': { 'path': 'str', 'property': 'str', 'value': 'any' },
-- 
2.19.2

Re: [Qemu-devel] [PATCH v2 00/52] Audio 5.1 patches

[Kővágó Zoltán]

On 2018-12-28 01:46, Programmingkid wrote:
> 
>> On Dec 27, 2018, at 8:33 AM, Kővágó Zoltán  wrote:
>>
>> Hi,
>>
>> I've pushed it to my github (modulo some random fixes not yet on the
>> mailing list):
>> https://github.com/DirtYiCE/qemu/tree/audio-51-2018
>>
>> I don't have a mac so I have no idea whether it works or not.
>>
>> Regards,
>> Zoltan
>>
>> On 2018-12-26 12:24, Programmingkid wrote:
>>>
 On Dec 23, 2018, at 3:52 PM, qemu-devel-requ...@nongnu.org wrote:

 Message: 4
 Date: Sun, 23 Dec 2018 21:51:36 +0100
 From: "=?UTF-8?q?K=C5=91v=C3=A1g=C3=B3=2C=20Zolt=C3=A1n?="

 To: qemu-devel@nongnu.org
 Cc: Gerd Hoffmann 
 Subject: [Qemu-devel] [PATCH v2 00/52] Audio 5.1 patches
 Message-ID: 
 Content-Type: text/plain; charset=UTF-8

 Hi,

 I've updated my audio patchset to the current git master. Other than that 
 not
 much happened since my last update [1], fixed a few small problems that I
 noticed while rebasing my patches.

 Please review.
>>>
>>> 
>>>
>>> Hi I would like to run your patches. Do you have a repository that I may 
>>> clone? 
>>>
>>> Also have you been able to test these patches using a Mac OS X guest yet? 
>>>
>>> Thank you.
>>>
>>
> 
> Hi, thanks for the link. This is what I did:
> 
>  - git clone https://github.com/DirtYiCE/qemu.git
>  - git checkout audio-51-2018
>  - ./configure --target-list=ppc-softmmu
>  - make -j 4
> 
> The result was unfortunately some errors:
> 
>   CC  audio/coreaudio.o
> audio/coreaudio.c:413:49: error: unknown type name 'HWVocieOut'; did you mean
>   'HWVoiceOut'?
> COREAUDIO_WRAPPER_FUNC(get_buffer_out, void *, (HWVocieOut *hw, size_t *size),
> ^~
> HWVoiceOut
> 
> 
> audio/coreaudio.c:578:29: error: passing 'struct audio_pcm_info' to parameter 
> of
>   incompatible type 'struct audio_pcm_info *'; take the address with &
> coreaudio_get_flags(hw->info, as);
> ^~~~
> &
> 
> 

Hi,

I pushed an updated version, it should fix the compile errors (hopefully).

Regards,
Zoltan

Re: [Qemu-devel] AVX support for TCG

[Alex Bennée]

On Fri, 28 Dec 2018, 13:46 Nick Renieris 
> Another question, are there existing discussions about this
> refactoring effort or specifically AVX? I asked a similar question on
> IRC a few days ago and got no answers.
>

You might want to try again next week. Most QEMU hackers are away for the
holidays and also tend to be on IRC during working hours.

>

[Qemu-devel] [PATCH 3/5 v2] RISC-V: Map gdb CSR reg numbers to hw reg numbers.

[Jim Wilson]

The gdb CSR xml file has registers in documentation order, not numerical
order, so we need a table to map the register numbers.  This also adds
some missing CSR_* register macros.

Signed-off-by: Jim Wilson 
---
 target/riscv/cpu_bits.h |  35 ++-
 target/riscv/csr-map.h  | 248 
 target/riscv/gdbstub.c  |   1 +
 3 files changed, 282 insertions(+), 2 deletions(-)
 create mode 100644 target/riscv/csr-map.h

diff --git a/target/riscv/cpu_bits.h b/target/riscv/cpu_bits.h
index 5439f47..316d500 100644
--- a/target/riscv/cpu_bits.h
+++ b/target/riscv/cpu_bits.h
@@ -135,16 +135,22 @@
 /* Legacy Counter Setup (priv v1.9.1) */
 #define CSR_MUCOUNTEREN 0x320
 #define CSR_MSCOUNTEREN 0x321
+#define CSR_MHCOUNTEREN 0x322
 
 /* Machine Trap Handling */
 #define CSR_MSCRATCH0x340
 #define CSR_MEPC0x341
 #define CSR_MCAUSE  0x342
-#define CSR_MBADADDR0x343
+#define CSR_MTVAL   0x343
 #define CSR_MIP 0x344
 
+/* Legacy Machine Trap Handling (priv v1.9.1) */
+#define CSR_MBADADDR0x343
+
 /* Supervisor Trap Setup */
 #define CSR_SSTATUS 0x100
+#define CSR_SEDELEG 0x102
+#define CSR_SIDELEG 0x103
 #define CSR_SIE 0x104
 #define CSR_STVEC   0x105
 #define CSR_SCOUNTEREN  0x106
@@ -153,9 +159,12 @@
 #define CSR_SSCRATCH0x140
 #define CSR_SEPC0x141
 #define CSR_SCAUSE  0x142
-#define CSR_SBADADDR0x143
+#define CSR_STVAL   0x143
 #define CSR_SIP 0x144
 
+/* Legacy Supervisor Trap Handling (priv v1.9.1) */
+#define CSR_SBADADDR0x143
+
 /* Supervisor Protection and Translation */
 #define CSR_SPTBR   0x180
 #define CSR_SATP0x180
@@ -282,6 +291,28 @@
 #define CSR_MHPMCOUNTER30H  0xb9e
 #define CSR_MHPMCOUNTER31H  0xb9f
 
+/* Legacy Hypervisor Trap Setup (priv v1.9.1) */
+#define CSR_HSTATUS 0x200
+#define CSR_HEDELEG 0x202
+#define CSR_HIDELEG 0x203
+#define CSR_HIE 0x204
+#define CSR_HTVEC   0x205
+
+/* Legacy Hypervisor Trap Handling (priv v1.9.1) */
+#define CSR_HSCRATCH0x240
+#define CSR_HEPC0x241
+#define CSR_HCAUSE  0x242
+#define CSR_HBADADDR0x243
+#define CSR_HIP 0x244
+
+/* Legacy Machine Protection and Translation (priv v1.9.1) */
+#define CSR_MBASE   0x380
+#define CSR_MBOUND  0x381
+#define CSR_MIBASE  0x382
+#define CSR_MIBOUND 0x383
+#define CSR_MDBASE  0x384
+#define CSR_MDBOUND 0x385
+
 /* mstatus CSR bits */
 #define MSTATUS_UIE 0x0001
 #define MSTATUS_SIE 0x0002
diff --git a/target/riscv/csr-map.h b/target/riscv/csr-map.h
new file mode 100644
index 000..cce32fd
--- /dev/null
+++ b/target/riscv/csr-map.h
@@ -0,0 +1,248 @@
+/*
+ * The GDB CSR xml files list them in documentation order, not numerical order,
+ * and are missing entries for unnamed CSRs.  So we need to map the gdb numbers
+ * to the hardware numbers.
+ */
+
+int csr_register_map[] = {
+CSR_USTATUS,
+CSR_UIE,
+CSR_UTVEC,
+CSR_USCRATCH,
+CSR_UEPC,
+CSR_UCAUSE,
+CSR_UTVAL,
+CSR_UIP,
+CSR_FFLAGS,
+CSR_FRM,
+CSR_FCSR,
+CSR_CYCLE,
+CSR_TIME,
+CSR_INSTRET,
+CSR_HPMCOUNTER3,
+CSR_HPMCOUNTER4,
+CSR_HPMCOUNTER5,
+CSR_HPMCOUNTER6,
+CSR_HPMCOUNTER7,
+CSR_HPMCOUNTER8,
+CSR_HPMCOUNTER9,
+CSR_HPMCOUNTER10,
+CSR_HPMCOUNTER11,
+CSR_HPMCOUNTER12,
+CSR_HPMCOUNTER13,
+CSR_HPMCOUNTER14,
+CSR_HPMCOUNTER15,
+CSR_HPMCOUNTER16,
+CSR_HPMCOUNTER17,
+CSR_HPMCOUNTER18,
+CSR_HPMCOUNTER19,
+CSR_HPMCOUNTER20,
+CSR_HPMCOUNTER21,
+CSR_HPMCOUNTER22,
+CSR_HPMCOUNTER23,
+CSR_HPMCOUNTER24,
+CSR_HPMCOUNTER25,
+CSR_HPMCOUNTER26,
+CSR_HPMCOUNTER27,
+CSR_HPMCOUNTER28,
+CSR_HPMCOUNTER29,
+CSR_HPMCOUNTER30,
+CSR_HPMCOUNTER31,
+CSR_CYCLEH,
+CSR_TIMEH,
+CSR_INSTRETH,
+CSR_HPMCOUNTER3H,
+CSR_HPMCOUNTER4H,
+CSR_HPMCOUNTER5H,
+CSR_HPMCOUNTER6H,
+CSR_HPMCOUNTER7H,
+CSR_HPMCOUNTER8H,
+CSR_HPMCOUNTER9H,
+CSR_HPMCOUNTER10H,
+CSR_HPMCOUNTER11H,
+CSR_HPMCOUNTER12H,
+CSR_HPMCOUNTER13H,
+CSR_HPMCOUNTER14H,
+CSR_HPMCOUNTER15H,
+CSR_HPMCOUNTER16H,
+CSR_HPMCOUNTER17H,
+CSR_HPMCOUNTER18H,
+CSR_HPMCOUNTER19H,
+CSR_HPMCOUNTER20H,
+CSR_HPMCOUNTER21H,
+CSR_HPMCOUNTER22H,
+CSR_HPMCOUNTER23H,
+CSR_HPMCOUNTER24H,
+CSR_HPMCOUNTER25H,
+CSR_HPMCOUNTER26H,
+CSR_HPMCOUNTER27H,
+CSR_HPMCOUNTER28H,
+CSR_HPMCOUNTER29H,
+CSR_HPMCOUNTER30H,
+CSR_HPMCOUNTER31H,
+CSR_SSTATUS,
+CSR_SEDELEG,
+CSR_SIDELEG,
+CSR_SIE,
+CSR_STVEC,
+CSR_SCOUNTEREN,
+CSR_SSCRATCH,
+CSR_SEPC,
+CSR_SCAUSE,
+CSR_STVAL,
+CSR_SIP,
+CSR_SATP,
+CSR_MVENDORID,
+CSR_MARCHID,
+CSR_MIMPID,
+   

[Qemu-devel] [PATCH 5/5 v2] RISC-V: Add hooks to use the gdb xml files.

[Jim Wilson]

Signed-off-by: Jim Wilson 
---
 target/riscv/cpu.c |  9 ++-
 target/riscv/gdbstub.c | 73 --
 2 files changed, 73 insertions(+), 9 deletions(-)

diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index a025a0a..b248e3e 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -305,6 +305,8 @@ static void riscv_cpu_realize(DeviceState *dev, Error 
**errp)
 return;
 }
 
+riscv_cpu_register_gdb_regs_for_features(cs);
+
 qemu_init_vcpu(cs);
 cpu_reset(cs);
 
@@ -345,7 +347,12 @@ static void riscv_cpu_class_init(ObjectClass *c, void 
*data)
 cc->synchronize_from_tb = riscv_cpu_synchronize_from_tb;
 cc->gdb_read_register = riscv_cpu_gdb_read_register;
 cc->gdb_write_register = riscv_cpu_gdb_write_register;
-cc->gdb_num_core_regs = 65;
+cc->gdb_num_core_regs = 33;
+#if defined(TARGET_RISCV32)
+cc->gdb_core_xml_file = "riscv-32bit-cpu.xml";
+#elif defined(TARGET_RISCV64)
+cc->gdb_core_xml_file = "riscv-64bit-cpu.xml";
+#endif
 cc->gdb_stop_before_watchpoint = true;
 cc->disas_set_info = riscv_cpu_disas_set_info;
 #ifdef CONFIG_USER_ONLY
diff --git a/target/riscv/gdbstub.c b/target/riscv/gdbstub.c
index b06f0fa..9558d80 100644
--- a/target/riscv/gdbstub.c
+++ b/target/riscv/gdbstub.c
@@ -31,10 +31,6 @@ int riscv_cpu_gdb_read_register(CPUState *cs, uint8_t 
*mem_buf, int n)
 return gdb_get_regl(mem_buf, env->gpr[n]);
 } else if (n == 32) {
 return gdb_get_regl(mem_buf, env->pc);
-} else if (n < 65) {
-return gdb_get_reg64(mem_buf, env->fpr[n - 33]);
-} else if (n < 4096 + 65) {
-return gdb_get_regl(mem_buf, csr_read_helper(env, n - 65, true));
 }
 return 0;
 }
@@ -53,11 +49,72 @@ int riscv_cpu_gdb_write_register(CPUState *cs, uint8_t 
*mem_buf, int n)
 } else if (n == 32) {
 env->pc = ldtul_p(mem_buf);
 return sizeof(target_ulong);
-} else if (n < 65) {
-env->fpr[n - 33] = ldq_p(mem_buf); /* always 64-bit */
+}
+return 0;
+}
+
+static int riscv_gdb_get_fpu(CPURISCVState *env, uint8_t *mem_buf, int n)
+{
+if (n < 32) {
+return gdb_get_reg64(mem_buf, env->fpr[n]);
+} else if (n < 35) {
+/*
+ * CSR_FFLAGS is 0x001, and gdb says it is FP register 32, so we
+ * subtract 31 to map the gdb FP register number to the CSR number.
+ * This also works for CSR_FRM and CSR_FCSR.
+ */
+return gdb_get_regl(mem_buf, csr_read_helper(env, n - 31, true));
+}
+return 0;
+}
+
+static int riscv_gdb_set_fpu(CPURISCVState *env, uint8_t *mem_buf, int n)
+{
+if (n < 32) {
+env->fpr[n] = ldq_p(mem_buf); /* always 64-bit */
 return sizeof(uint64_t);
-} else if (n < 4096 + 65) {
-csr_write_helper(env, ldtul_p(mem_buf), n - 65, true);
+} else if (n < 35) {
+/*
+ * CSR_FFLAGS is 0x001, and gdb says it is FP register 32, so we
+ * subtract 31 to map the gdb FP register number to the CSR number.
+ * This also works for CSR_FRM and CSR_FCSR.
+ */
+csr_write_helper(env, ldtul_p(mem_buf), n - 31, true);
 }
 return 0;
 }
+
+static int riscv_gdb_get_csr(CPURISCVState *env, uint8_t *mem_buf, int n)
+{
+if (n < ARRAY_SIZE(csr_register_map)) {
+return gdb_get_regl(mem_buf, csr_read_helper(env, csr_register_map[n],
+ true));
+}
+return 0;
+}
+
+static int riscv_gdb_set_csr(CPURISCVState *env, uint8_t *mem_buf, int n)
+{
+if (n < ARRAY_SIZE(csr_register_map)) {
+csr_write_helper(env, ldtul_p(mem_buf), csr_register_map[n], true);
+}
+return 0;
+}
+
+void riscv_cpu_register_gdb_regs_for_features(CPUState *cs)
+{
+/* ??? Assume all targets have FPU regs for now.  */
+#if defined(TARGET_RISCV32)
+gdb_register_coprocessor(cs, riscv_gdb_get_fpu, riscv_gdb_set_fpu,
+ 35, "riscv-32bit-fpu.xml", 0);
+
+gdb_register_coprocessor(cs, riscv_gdb_get_csr, riscv_gdb_set_csr,
+ 4096, "riscv-32bit-csr.xml", 0);
+#elif defined(TARGET_RISCV64)
+gdb_register_coprocessor(cs, riscv_gdb_get_fpu, riscv_gdb_set_fpu,
+ 35, "riscv-64bit-fpu.xml", 0);
+
+gdb_register_coprocessor(cs, riscv_gdb_get_csr, riscv_gdb_set_csr,
+ 4096, "riscv-64bit-csr.xml", 0);
+#endif
+}
-- 
2.7.4

[Qemu-devel] [PATCH 2/5 v2] RISC-V: Add 64-bit gdb xml files.

[Jim Wilson]

Signed-off-by: Jim Wilson 
---
 configure   |   1 +
 gdb-xml/riscv-64bit-cpu.xml |  43 
 gdb-xml/riscv-64bit-csr.xml | 250 
 gdb-xml/riscv-64bit-fpu.xml |  52 +
 4 files changed, 346 insertions(+)
 create mode 100644 gdb-xml/riscv-64bit-cpu.xml
 create mode 100644 gdb-xml/riscv-64bit-csr.xml
 create mode 100644 gdb-xml/riscv-64bit-fpu.xml

diff --git a/configure b/configure
index 4e05eed..00b7495 100755
--- a/configure
+++ b/configure
@@ -7215,6 +7215,7 @@ case "$target_name" in
 TARGET_BASE_ARCH=riscv
 TARGET_ABI_DIR=riscv
 mttcg=yes
+gdb_xml_files="riscv-64bit-cpu.xml riscv-64bit-fpu.xml riscv-64bit-csr.xml"
 target_compiler=$cross_cc_riscv64
   ;;
   sh4|sh4eb)
diff --git a/gdb-xml/riscv-64bit-cpu.xml b/gdb-xml/riscv-64bit-cpu.xml
new file mode 100644
index 000..f37d7f3
--- /dev/null
+++ b/gdb-xml/riscv-64bit-cpu.xml
@@ -0,0 +1,43 @@
+
+
+
+
+
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+
diff --git a/gdb-xml/riscv-64bit-csr.xml b/gdb-xml/riscv-64bit-csr.xml
new file mode 100644
index 000..a3de834
--- /dev/null
+++ b/gdb-xml/riscv-64bit-csr.xml
@@ -0,0 +1,250 @@
+
+
+
+
+
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+
diff --git a/gdb-xml/riscv-64bit-fpu.xml b/gdb-xml/riscv-64bit-fpu.xml
new file mode 100644
index 000..fb24b72
--- /dev/null
+++ b/gdb-xml/riscv-64bit-fpu.xml
@@ -0,0 +1,52 @@
+
+
+
+
+
+
+  
+
+
+  
+
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+
+  
+  
+  
+
-- 
2.7.4

[Qemu-devel] [PATCH 4/5 v2] RISC-V: Add debug support for accessing CSRs.

[Jim Wilson]

Adds a debugger parameter to csr_read_helper and csr_write_helper.  When
this is true, we disable illegal instruction checks.

Signed-off-by: Jim Wilson 
---
 linux-user/riscv/signal.c |  5 ++-
 target/riscv/cpu.h|  7 +++-
 target/riscv/cpu_helper.c |  4 +-
 target/riscv/gdbstub.c|  4 +-
 target/riscv/op_helper.c  | 93 ---
 5 files changed, 76 insertions(+), 37 deletions(-)

diff --git a/linux-user/riscv/signal.c b/linux-user/riscv/signal.c
index f598d41..ed76f23 100644
--- a/linux-user/riscv/signal.c
+++ b/linux-user/riscv/signal.c
@@ -83,7 +83,8 @@ static void setup_sigcontext(struct target_sigcontext *sc, 
CPURISCVState *env)
 __put_user(env->fpr[i], &sc->fpr[i]);
 }
 
-uint32_t fcsr = csr_read_helper(env, CSR_FCSR); /*riscv_get_fcsr(env);*/
+/*riscv_get_fcsr(env);*/
+uint32_t fcsr = csr_read_helper(env, CSR_FCSR, false);
 __put_user(fcsr, &sc->fcsr);
 }
 
@@ -159,7 +160,7 @@ static void restore_sigcontext(CPURISCVState *env, struct 
target_sigcontext *sc)
 
 uint32_t fcsr;
 __get_user(fcsr, &sc->fcsr);
-csr_write_helper(env, fcsr, CSR_FCSR);
+csr_write_helper(env, fcsr, CSR_FCSR, false);
 }
 
 static void restore_ucontext(CPURISCVState *env, struct target_ucontext *uc)
diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
index 4ee09b9..29361ca 100644
--- a/target/riscv/cpu.h
+++ b/target/riscv/cpu.h
@@ -290,8 +290,11 @@ static inline void cpu_get_tb_cpu_state(CPURISCVState 
*env, target_ulong *pc,
 }
 
 void csr_write_helper(CPURISCVState *env, target_ulong val_to_write,
-target_ulong csrno);
-target_ulong csr_read_helper(CPURISCVState *env, target_ulong csrno);
+  target_ulong csrno, bool debugger);
+target_ulong csr_read_helper(CPURISCVState *env, target_ulong csrno,
+ bool debugger);
+
+void riscv_cpu_register_gdb_regs_for_features(CPUState *cs);
 
 #include "exec/cpu-all.h"
 
diff --git a/target/riscv/cpu_helper.c b/target/riscv/cpu_helper.c
index 86f9f47..1abad94 100644
--- a/target/riscv/cpu_helper.c
+++ b/target/riscv/cpu_helper.c
@@ -526,7 +526,7 @@ void riscv_cpu_do_interrupt(CPUState *cs)
 get_field(s, MSTATUS_SIE) : get_field(s, MSTATUS_UIE << 
env->priv));
 s = set_field(s, MSTATUS_SPP, env->priv);
 s = set_field(s, MSTATUS_SIE, 0);
-csr_write_helper(env, s, CSR_MSTATUS);
+csr_write_helper(env, s, CSR_MSTATUS, false);
 riscv_set_mode(env, PRV_S);
 } else {
 /* No need to check MTVEC for misaligned - lower 2 bits cannot be set 
*/
@@ -551,7 +551,7 @@ void riscv_cpu_do_interrupt(CPUState *cs)
 get_field(s, MSTATUS_MIE) : get_field(s, MSTATUS_UIE << 
env->priv));
 s = set_field(s, MSTATUS_MPP, env->priv);
 s = set_field(s, MSTATUS_MIE, 0);
-csr_write_helper(env, s, CSR_MSTATUS);
+csr_write_helper(env, s, CSR_MSTATUS, false);
 riscv_set_mode(env, PRV_M);
 }
 /* TODO yield load reservation  */
diff --git a/target/riscv/gdbstub.c b/target/riscv/gdbstub.c
index 71c3eb1..b06f0fa 100644
--- a/target/riscv/gdbstub.c
+++ b/target/riscv/gdbstub.c
@@ -34,7 +34,7 @@ int riscv_cpu_gdb_read_register(CPUState *cs, uint8_t 
*mem_buf, int n)
 } else if (n < 65) {
 return gdb_get_reg64(mem_buf, env->fpr[n - 33]);
 } else if (n < 4096 + 65) {
-return gdb_get_regl(mem_buf, csr_read_helper(env, n - 65));
+return gdb_get_regl(mem_buf, csr_read_helper(env, n - 65, true));
 }
 return 0;
 }
@@ -57,7 +57,7 @@ int riscv_cpu_gdb_write_register(CPUState *cs, uint8_t 
*mem_buf, int n)
 env->fpr[n - 33] = ldq_p(mem_buf); /* always 64-bit */
 return sizeof(uint64_t);
 } else if (n < 4096 + 65) {
-csr_write_helper(env, ldtul_p(mem_buf), n - 65);
+csr_write_helper(env, ldtul_p(mem_buf), n - 65, true);
 }
 return 0;
 }
diff --git a/target/riscv/op_helper.c b/target/riscv/op_helper.c
index 3726299..3c5641e 100644
--- a/target/riscv/op_helper.c
+++ b/target/riscv/op_helper.c
@@ -87,7 +87,7 @@ static void validate_mstatus_fs(CPURISCVState *env, uintptr_t 
ra)
  * Adapted from Spike's processor_t::set_csr
  */
 void csr_write_helper(CPURISCVState *env, target_ulong val_to_write,
-target_ulong csrno)
+  target_ulong csrno, bool debugger)
 {
 #ifndef CONFIG_USER_ONLY
 uint64_t delegable_ints = MIP_SSIP | MIP_STIP | MIP_SEIP;
@@ -96,15 +96,21 @@ void csr_write_helper(CPURISCVState *env, target_ulong 
val_to_write,
 
 switch (csrno) {
 case CSR_FFLAGS:
-validate_mstatus_fs(env, GETPC());
+if (!debugger) {
+validate_mstatus_fs(env, GETPC());
+}
 cpu_riscv_set_fflags(env, val_to_write & (FSR_AEXC >> FSR_AEXC_SHIFT));
 break;
 case CSR_FRM:
-validate_mstatus_fs(env, GETPC());
+if (!debugger) {
+validate_mstatus_fs(env, GETPC());
+}
 env->frm =

[Qemu-devel] [PATCH 1/5 v2] RISC-V: Add 32-bit gdb xml files.

[Jim Wilson]

Signed-off-by: Jim Wilson 
---
 configure   |   1 +
 gdb-xml/riscv-32bit-cpu.xml |  43 
 gdb-xml/riscv-32bit-csr.xml | 250 
 gdb-xml/riscv-32bit-fpu.xml |  46 
 4 files changed, 340 insertions(+)
 create mode 100644 gdb-xml/riscv-32bit-cpu.xml
 create mode 100644 gdb-xml/riscv-32bit-csr.xml
 create mode 100644 gdb-xml/riscv-32bit-fpu.xml

diff --git a/configure b/configure
index 224d307..4e05eed 100755
--- a/configure
+++ b/configure
@@ -7208,6 +7208,7 @@ case "$target_name" in
 TARGET_BASE_ARCH=riscv
 TARGET_ABI_DIR=riscv
 mttcg=yes
+gdb_xml_files="riscv-32bit-cpu.xml riscv-32bit-fpu.xml riscv-32bit-csr.xml"
 target_compiler=$cross_cc_riscv32
   ;;
   riscv64)
diff --git a/gdb-xml/riscv-32bit-cpu.xml b/gdb-xml/riscv-32bit-cpu.xml
new file mode 100644
index 000..c02f86c
--- /dev/null
+++ b/gdb-xml/riscv-32bit-cpu.xml
@@ -0,0 +1,43 @@
+
+
+
+
+
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+
diff --git a/gdb-xml/riscv-32bit-csr.xml b/gdb-xml/riscv-32bit-csr.xml
new file mode 100644
index 000..4aea9e6
--- /dev/null
+++ b/gdb-xml/riscv-32bit-csr.xml
@@ -0,0 +1,250 @@
+
+
+
+
+
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+
diff --git a/gdb-xml/riscv-32bit-fpu.xml b/gdb-xml/riscv-32bit-fpu.xml
new file mode 100644
index 000..783287d
--- /dev/null
+++ b/gdb-xml/riscv-32bit-fpu.xml
@@ -0,0 +1,46 @@
+
+
+
+
+
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+
+  
+  
+  
+
-- 
2.7.4

[Qemu-devel] [PATCH 0/5 v2] RISC-V: Add gdb xml files and gdbstub support.

[Jim Wilson]

This is the second version of the patch set.  I haven't gotten any bug
reports for the patches in the several weeks that they have been
available, and no review yet, so the only significant difference from
the first version is that I ran them through checkpatch to fix style
issues, and I sent them to the right mailing list this time.

With these patches, I can run system qemu with -s -S, connect to it
with gdb, and then print any integer, FP, or CSR register.  This
support is currently broken.

The first two patches in the series are just dropping in xml files
from gdb unchanged, with configure support to point at them.  The next
two patches are the inconvenient stuff.  The gdb CSR files are in
documentation order not numerical order, so I need an array to map the
gdb numbers to the actual hardware numbers.  The gdb files should
probably be improved, but I don't know when that will happen.  That is
the third patch.  The fourth patch is to disable all of the illegal
instruction checks when accessing CSRs from the debugger, as it needs
to be able to access them without traps.  The last patch adds the
gdbstub support to use the new xml files which is pretty simple,
though there is an unanswered question in there about what to do with
the FP registers.  Should we try to configure them based on the
target?  Right now I just always enable them which is the simple
solution.  I'm not sure if enabling them based on the target will even
work with gdb or not.

Jim

[Qemu-devel] [Bug 1810000] [NEW] qemu system emulator crashed with the attachment of usb-bt-dongle device

[PH]

Public bug reported:

I am testing usb-bt-dongle device on xchi host controller, and found
that the qemu crashed directly with an assertion failer.

Here is the information to reproduce the crash:

Qemu git revision: 9b2e891ec5ccdb4a7d583b77988848282606fdea
System emulator: qemu-x86_64
VM image: 
https://people.debian.org/~aurel32/qemu/amd64/debian_squeeze_amd64_desktop.qcow2
CommandLine: qemu-system-x86_64 -M q35 -device qemu-xhci,id=xhci -enable-kvm 
-device usb-bt-dongle  -hda ./debian_wheezy_amd64_standard.qcow2

Error message:

qemu-system-x86_64: /build/qemu-Eap4uc/qemu-2.11+dfsg/hw/usb/core.c:592:
usb_packet_copy: Assertion `p->actual_length + bytes <= iov->size'
failed.

** Affects: qemu
 Importance: Undecided
 Status: New

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

Title:
  qemu system emulator crashed with the attachment of usb-bt-dongle
  device

Status in QEMU:
  New

Bug description:
  I am testing usb-bt-dongle device on xchi host controller, and found
  that the qemu crashed directly with an assertion failer.

  Here is the information to reproduce the crash:

  Qemu git revision: 9b2e891ec5ccdb4a7d583b77988848282606fdea
  System emulator: qemu-x86_64
  VM image: 
https://people.debian.org/~aurel32/qemu/amd64/debian_squeeze_amd64_desktop.qcow2
  CommandLine: qemu-system-x86_64 -M q35 -device qemu-xhci,id=xhci -enable-kvm 
-device usb-bt-dongle  -hda ./debian_wheezy_amd64_standard.qcow2

  Error message:

  qemu-system-x86_64: /build/qemu-
  Eap4uc/qemu-2.11+dfsg/hw/usb/core.c:592: usb_packet_copy: Assertion
  `p->actual_length + bytes <= iov->size' failed.

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

Re: [Qemu-devel] d_off field in struct dirent and 32-on-64 emulation

[Andreas Dilger]

On Dec 28, 2018, at 4:18 AM, Peter Maydell  wrote:
> 
> On Fri, 28 Dec 2018 at 00:23, Andreas Dilger  wrote:
>> On Dec 27, 2018, at 10:41 AM, Peter Maydell  wrote:
>>> As you note, this causes breakage for userspace programs which
>>> need to implement an API/ABI with 32-bit offset but which only
>>> have access to the kernel's 64-bit offset API/ABI.
>> 
>> This is (IMHO) a bit of an oxymoron, isn't it?  Applications using
>> the 64-bit API, but storing the value in a 32-bit field?
> 
> I didn't say "which choose to store the value in a 32-bit field",
> I said "which have to implement an API/ABI which has 32-bit fields".
> In QEMU's case, we use the host kernel's ABI, which has 64-bit
> offset fields. We implement a syscall ABI for the guest binary
> we are running under emulation, which may have 32-bit offset fields
> (for instance if we are running a 32-bit Arm binary.) Both of
> these ABIs are fixed -- QEMU doesn't have a choice here, it
> just has to make the best effort it can with what the host kernel
> provides it, to provide the semantics the guest binary needs.
> My suggestion in this thread is that the host kernel provides
> a wider range of facilities so that QEMU can do the job it's
> trying to do.
> 
>> The same
>> problem would exist for filesystems with 64-bit inodes or 64-bit
>> file offsets trying to store these values in 32-bit variables.
>> It might work most of the time, but it can also break randomly.
> 
> In general inodes and offsets start from 0 and work up --
> so almost all of the time they don't actually overflow.
> The problem with ext4 directory hash "offsets" is that they
> overflow all the time and immediately, so instead of "works
> unless you have a weird edge case" like all the other filesystems,
> it's "never works".
> 
>>> I think the best fix for this would be for the kernel to either
>>> (a) consistently use a 32-bit hash or (b) to provide an API
>>> so that userspace can use the FMODE_32BITHASH flag the way
>>> that kernel-internal users already can.
>> 
>> It would be relatively straight forward to add a "32bitapi" mount
>> option to return a 32-bit directory hash to userspace for operations
>> on that mountpoint (ext4 doesn't have 64-bit inode numbers yet).
>> However, I can't think of an easy way to do this on a per-process
>> basis without just having it call the 32-bit API directly.
> 
> The problem is that there is no 32-bit API in some cases
> (unless I have misunderstood the kernel code) -- not all
> host architectures implement compat syscalls or allow them
> to be called from 64-bit processes or implement all the older
> syscall variants that had smaller offets. If there was a guaranteed
> "this syscall always exists and always gives me 32-bit offsets"
> we could use it.

The "32bitapi" mount option would use 32-bit hash for seekdir
and telldir, regardless of what kernel API was used.  That would
just set the FMODE_32BITHASH flag in the file->f_mode for all files.

Using 32-bit directory hash values is not necessarily harmful, but
it returns the possibility to hit the problem with hash collisions
that previously existed before the move to 64-bit hash values.
This becomes more of a problem as directory sizes increase.

>> For ext4 at least, you could just shift the high 32-bit part of
>> the 64-bit hash down into a 32-bit value in telldir(), and
>> shift it back up when seekdir() is called.
> 
> Yes, that has been suggested, but it seemed a bit dubious
> to bake in knowledge of ext4's internal implementation details.
> Can we rely on this as an ABI promise that will always work
> for all versions of all file systems going forwards?

Well, the directory cookies need to be relatively stable over
time because they are exported to applications and possibly
remote nodes via NFS, so it can't be changed very much.

Cheers, Andreas







signature.asc
Description: Message signed with OpenPGP

Re: [Qemu-devel] [PATCH v2 00/52] Audio 5.1 patches

[Zoltán Kővágó]

On 2018-12-29 01:12, Programmingkid wrote:
> 
>> On Dec 28, 2018, at 3:05 PM, Kővágó Zoltán  wrote:
>>
>> On 2018-12-28 01:46, Programmingkid wrote:
>>>
 On Dec 27, 2018, at 8:33 AM, Kővágó Zoltán  wrote:

 Hi,

 I've pushed it to my github (modulo some random fixes not yet on the
 mailing list):
 https://github.com/DirtYiCE/qemu/tree/audio-51-2018

 I don't have a mac so I have no idea whether it works or not.

 Regards,
 Zoltan

 On 2018-12-26 12:24, Programmingkid wrote:
>
>> On Dec 23, 2018, at 3:52 PM, qemu-devel-requ...@nongnu.org wrote:
>>
>> Message: 4
>> Date: Sun, 23 Dec 2018 21:51:36 +0100
>> From: "=?UTF-8?q?K=C5=91v=C3=A1g=C3=B3=2C=20Zolt=C3=A1n?="
>>  
>> To: qemu-devel@nongnu.org
>> Cc: Gerd Hoffmann 
>> Subject: [Qemu-devel] [PATCH v2 00/52] Audio 5.1 patches
>> Message-ID: 
>> Content-Type: text/plain; charset=UTF-8
>>
>> Hi,
>>
>> I've updated my audio patchset to the current git master. Other than 
>> that not
>> much happened since my last update [1], fixed a few small problems that I
>> noticed while rebasing my patches.
>>
>> Please review.
>
> 
>
> Hi I would like to run your patches. Do you have a repository that I may 
> clone? 
>
> Also have you been able to test these patches using a Mac OS X guest yet? 
>
> Thank you.
>

>>>
>>> Hi, thanks for the link. This is what I did:
>>>
>>> - git clone https://github.com/DirtYiCE/qemu.git
>>> - git checkout audio-51-2018
>>> - ./configure --target-list=ppc-softmmu
>>> - make -j 4
>>>
>>> The result was unfortunately some errors:
>>>
>>>  CC  audio/coreaudio.o
>>> audio/coreaudio.c:413:49: error: unknown type name 'HWVocieOut'; did you 
>>> mean
>>>  'HWVoiceOut'?
>>> COREAUDIO_WRAPPER_FUNC(get_buffer_out, void *, (HWVocieOut *hw, size_t 
>>> *size),
>>>^~
>>>HWVoiceOut
>>>
>>>
>>> audio/coreaudio.c:578:29: error: passing 'struct audio_pcm_info' to 
>>> parameter of
>>>  incompatible type 'struct audio_pcm_info *'; take the address with &
>>>coreaudio_get_flags(hw->info, as);
>>>^~~~
>>>&
>>>
>>>
>>
>> Hi,
>>
>> I pushed an updated version, it should fix the compile errors (hopefully).
>>
>> Regards,
>> Zoltan
> 
> Thank you for the update. I tested this series using a Mac OS 10.4 and 
> Windows 2000 guest. Both were using a USB sound card. The sound that comes 
> out of my speakers is demonic! It is the loudest, scariest sound I have ever 
> heard. I'm sorry but this patch series ruins the USB sound card.
> 
> I am happy to test out any future updates that you make this patch series. 
> 
> Thank you.
> 

I'm sorry to hear that. Could you please test it with some other card,
like the hda? Even though usb works fine for me on Linux with alsa so
the problem is probably with the coreaudio backend.

Regards,
Zoltan

Re: [Qemu-devel] d_off field in struct dirent and 32-on-64 emulation

[Peter Maydell]

On Fri, 28 Dec 2018 at 23:16, Andreas Dilger  wrot
> On Dec 28, 2018, at 4:18 AM, Peter Maydell  wrote:
> > The problem is that there is no 32-bit API in some cases
> > (unless I have misunderstood the kernel code) -- not all
> > host architectures implement compat syscalls or allow them
> > to be called from 64-bit processes or implement all the older
> > syscall variants that had smaller offets. If there was a guaranteed
> > "this syscall always exists and always gives me 32-bit offsets"
> > we could use it.
>
> The "32bitapi" mount option would use 32-bit hash for seekdir
> and telldir, regardless of what kernel API was used.  That would
> just set the FMODE_32BITHASH flag in the file->f_mode for all files.

A mount option wouldn't be much use to QEMU -- we can't tell
our users how to mount their filesystems, which they're
often doing lots of other things with besides running QEMU.
(Otherwise we could just tell them "don't use ext4", which
would also solve the problem :-)) We need something we can
use at the individual-syscall level.

thanks
-- PMM

Re: [Qemu-devel] [PATCH v2 00/52] Audio 5.1 patches

[Programmingkid]

> On Dec 28, 2018, at 3:05 PM, Kővágó Zoltán  wrote:
> 
> On 2018-12-28 01:46, Programmingkid wrote:
>> 
>>> On Dec 27, 2018, at 8:33 AM, Kővágó Zoltán  wrote:
>>> 
>>> Hi,
>>> 
>>> I've pushed it to my github (modulo some random fixes not yet on the
>>> mailing list):
>>> https://github.com/DirtYiCE/qemu/tree/audio-51-2018
>>> 
>>> I don't have a mac so I have no idea whether it works or not.
>>> 
>>> Regards,
>>> Zoltan
>>> 
>>> On 2018-12-26 12:24, Programmingkid wrote:
 
> On Dec 23, 2018, at 3:52 PM, qemu-devel-requ...@nongnu.org wrote:
> 
> Message: 4
> Date: Sun, 23 Dec 2018 21:51:36 +0100
> From: "=?UTF-8?q?K=C5=91v=C3=A1g=C3=B3=2C=20Zolt=C3=A1n?="
>   
> To: qemu-devel@nongnu.org
> Cc: Gerd Hoffmann 
> Subject: [Qemu-devel] [PATCH v2 00/52] Audio 5.1 patches
> Message-ID: 
> Content-Type: text/plain; charset=UTF-8
> 
> Hi,
> 
> I've updated my audio patchset to the current git master. Other than that 
> not
> much happened since my last update [1], fixed a few small problems that I
> noticed while rebasing my patches.
> 
> Please review.
 
 
 
 Hi I would like to run your patches. Do you have a repository that I may 
 clone? 
 
 Also have you been able to test these patches using a Mac OS X guest yet? 
 
 Thank you.
 
>>> 
>> 
>> Hi, thanks for the link. This is what I did:
>> 
>> - git clone https://github.com/DirtYiCE/qemu.git
>> - git checkout audio-51-2018
>> - ./configure --target-list=ppc-softmmu
>> - make -j 4
>> 
>> The result was unfortunately some errors:
>> 
>>  CC  audio/coreaudio.o
>> audio/coreaudio.c:413:49: error: unknown type name 'HWVocieOut'; did you mean
>>  'HWVoiceOut'?
>> COREAUDIO_WRAPPER_FUNC(get_buffer_out, void *, (HWVocieOut *hw, size_t 
>> *size),
>>^~
>>HWVoiceOut
>> 
>> 
>> audio/coreaudio.c:578:29: error: passing 'struct audio_pcm_info' to 
>> parameter of
>>  incompatible type 'struct audio_pcm_info *'; take the address with &
>>coreaudio_get_flags(hw->info, as);
>>^~~~
>>&
>> 
>> 
> 
> Hi,
> 
> I pushed an updated version, it should fix the compile errors (hopefully).
> 
> Regards,
> Zoltan

Thank you for the update. I tested this series using a Mac OS 10.4 and Windows 
2000 guest. Both were using a USB sound card. The sound that comes out of my 
speakers is demonic! It is the loudest, scariest sound I have ever heard. I'm 
sorry but this patch series ruins the USB sound card.

I am happy to test out any future updates that you make this patch series. 

Thank you.

Re: [Qemu-devel] [PATCH v2 00/52] Audio 5.1 patches

[Programmingkid]

> On Dec 28, 2018, at 7:19 PM, Zoltán Kővágó  wrote:
> 
> On 2018-12-29 01:12, Programmingkid wrote:
>> 
>>> On Dec 28, 2018, at 3:05 PM, Kővágó Zoltán  wrote:
>>> 
>>> On 2018-12-28 01:46, Programmingkid wrote:
 
> On Dec 27, 2018, at 8:33 AM, Kővágó Zoltán  wrote:
> 
> Hi,
> 
> I've pushed it to my github (modulo some random fixes not yet on the
> mailing list):
> https://github.com/DirtYiCE/qemu/tree/audio-51-2018
> 
> I don't have a mac so I have no idea whether it works or not.
> 
> Regards,
> Zoltan
> 
> On 2018-12-26 12:24, Programmingkid wrote:
>> 
>>> On Dec 23, 2018, at 3:52 PM, qemu-devel-requ...@nongnu.org wrote:
>>> 
>>> Message: 4
>>> Date: Sun, 23 Dec 2018 21:51:36 +0100
>>> From: "=?UTF-8?q?K=C5=91v=C3=A1g=C3=B3=2C=20Zolt=C3=A1n?="
>>> 
>>> To: qemu-devel@nongnu.org
>>> Cc: Gerd Hoffmann 
>>> Subject: [Qemu-devel] [PATCH v2 00/52] Audio 5.1 patches
>>> Message-ID: 
>>> Content-Type: text/plain; charset=UTF-8
>>> 
>>> Hi,
>>> 
>>> I've updated my audio patchset to the current git master. Other than 
>>> that not
>>> much happened since my last update [1], fixed a few small problems that 
>>> I
>>> noticed while rebasing my patches.
>>> 
>>> Please review.
>> 
>> 
>> 
>> Hi I would like to run your patches. Do you have a repository that I may 
>> clone? 
>> 
>> Also have you been able to test these patches using a Mac OS X guest 
>> yet? 
>> 
>> Thank you.
>> 
> 
 
 Hi, thanks for the link. This is what I did:
 
 - git clone https://github.com/DirtYiCE/qemu.git
 - git checkout audio-51-2018
 - ./configure --target-list=ppc-softmmu
 - make -j 4
 
 The result was unfortunately some errors:
 
 CC  audio/coreaudio.o
 audio/coreaudio.c:413:49: error: unknown type name 'HWVocieOut'; did you 
 mean
 'HWVoiceOut'?
 COREAUDIO_WRAPPER_FUNC(get_buffer_out, void *, (HWVocieOut *hw, size_t 
 *size),
   ^~
   HWVoiceOut
 
 
 audio/coreaudio.c:578:29: error: passing 'struct audio_pcm_info' to 
 parameter of
 incompatible type 'struct audio_pcm_info *'; take the address with &
   coreaudio_get_flags(hw->info, as);
   ^~~~
   &
 
 
>>> 
>>> Hi,
>>> 
>>> I pushed an updated version, it should fix the compile errors (hopefully).
>>> 
>>> Regards,
>>> Zoltan
>> 
>> Thank you for the update. I tested this series using a Mac OS 10.4 and 
>> Windows 2000 guest. Both were using a USB sound card. The sound that comes 
>> out of my speakers is demonic! It is the loudest, scariest sound I have ever 
>> heard. I'm sorry but this patch series ruins the USB sound card.
>> 
>> I am happy to test out any future updates that you make this patch series. 
>> 
>> Thank you.
>> 
> 
> I'm sorry to hear that. Could you please test it with some other card,
> like the hda? Even though usb works fine for me on Linux with alsa so
> the problem is probably with the coreaudio backend.
> 
> Regards,
> Zoltan

I tried ac97 with a Windows 2000 guest in qemu-system-i386 - same demonic sound.
With the above configuration but with an es1370 sound card I heard the same 
sound. I kept seeing "es1370: warning: non looping mode" being printed in the 
terminal. This problem might need its own patch.
Using the sb16 sound card I heard the same unsettling sound.

I could not test the HDA driver due to problems with my Windows 7 VM.  

Re: [Qemu-devel] [PATCH v3 1/2] intel-iommu: differentiate host address width from IOVA address width.

[Eduardo Habkost]

On Fri, Dec 28, 2018 at 10:32:59AM +0800, Yu Zhang wrote:
> On Thu, Dec 27, 2018 at 01:14:11PM -0200, Eduardo Habkost wrote:
> > On Wed, Dec 26, 2018 at 01:30:00PM +0800, Yu Zhang wrote:
> > > On Tue, Dec 25, 2018 at 11:56:19AM -0500, Michael S. Tsirkin wrote:
> > > > On Sat, Dec 22, 2018 at 09:11:26AM +0800, Yu Zhang wrote:
> > > > > On Fri, Dec 21, 2018 at 02:02:28PM -0500, Michael S. Tsirkin wrote:
> > > > > > On Sat, Dec 22, 2018 at 01:37:58AM +0800, Yu Zhang wrote:
> > > > > > > On Fri, Dec 21, 2018 at 12:04:49PM -0500, Michael S. Tsirkin 
> > > > > > > wrote:
> > > > > > > > On Sat, Dec 22, 2018 at 12:09:44AM +0800, Yu Zhang wrote:
> > > > > > > > > Well, my understanding of the vt-d spec is that the address 
> > > > > > > > > limitation in
> > > > > > > > > DMAR are referring to the same concept of CPUID.MAXPHYSADDR. 
> > > > > > > > > I do not think
> > > > > > > > > there's any different in the native scenario. :)
> > > > > > > > 
> > > > > > > > I think native machines exist on which the two values are 
> > > > > > > > different.
> > > > > > > > Is that true?
> > > > > > > 
> > > > > > > I think the answer is not. My understanding is that HAW(host 
> > > > > > > address wdith) is
> > > > > > > the maximum physical address width a CPU can detects(by 
> > > > > > > cpuid.0x8008).
> > > > > > > 
> > > > > > > I agree there are some addresses the CPU does not touch, but they 
> > > > > > > are still in
> > > > > > > the physical address space, and there's only one physical address 
> > > > > > > space...
> > > > > > > 
> > > > > > > B.R.
> > > > > > > Yu
> > > > > > 
> > > > > > Ouch I thought we are talking about the virtual address size.
> > > > > > I think I did have a box where VTD's virtual address size was
> > > > > > smaller than CPU's.
> > > > > > For physical one - we just need to make it as big as max supported
> > > > > > memory right?
> > > > > 
> > > > > Well, my understanding of the physical one is the maximum physical 
> > > > > address
> > > > > width. Sorry, this explain seems nonsense... I mean, it's not just 
> > > > > about
> > > > > the max supported memory, but also covers MMIO. It shall be detectable
> > > > > from cpuid, or ACPI's DMAR table, instead of calculated by the max 
> > > > > memory
> > > > > size. One common usage of this value is to tell the paging structure 
> > > > > entries(
> > > > > CPU's or IOMMU's) which bits shall be reserved. There are also some 
> > > > > registers
> > > > > e.g. apic base reg etc, whose contents are physical addresses, 
> > > > > therefore also
> > > > > need to follow the similar requirement for the reserved bits.
> > > > > 
> > > > > So I think the correct direction might be to define this property in 
> > > > > the
> > > > > machine status level, instead of the CPU level. Is this reasonable to 
> > > > > you?
> > > > 
> > > > At that level yes. But isn't this already specified by "pci-hole64-end"?
> > > 
> > > But this value is set by guest firmware? Will PCI hotplug change this 
> > > address?
> > > 
> > > @Eduardo, do you have any plan to calculate the phys-bits by 
> > > "pci-hole64-end"?
> > > Or introduce another property, say "max-phys-bits" in machine status?
> > 
> > I agree it may make sense to make the machine code control
> > phys-bits instead of the CPU object.  A machine property sounds
> > like the simplest solution.
> > 
> > But I don't think we can have a meaningful discussion about
> > implementation if we don't agree about the command-line
> > interface.  We must decide what will happen to the CPU and iommu
> > physical address width in cases like:
> 
> Thanks, Eduardo.
> 
> What about we just use "-machine phys-bits=52", and remove the
> "phys-bits" from CPU parameter?

Maybe we can deprecate it, but we can't remove it immediately.
We still need to decide what to do on the cases below, while the
option is still available.

> 
> > 
> >   $QEMU -device intel-iommu
> >   $QEMU -cpu ...,phys-bits=50 -device intel-iommu
> >   $QEMU -cpu ...,host-phys-bits=on -device intel-iommu
> >   $QEMU -machine phys-bits=50 -device intel-iommu
> >   $QEMU -machine phys-bits=50 -cpu ...,phys-bits=48 -device intel-iommu
> > 
> > -- 
> > Eduardo
> > 
> 
> B.R.
> Yu

-- 
Eduardo

Re: [Qemu-devel] [PATCH] i386: mark the 'INTEL_PT' CPUID bit as unmigratable

[Eduardo Habkost]

On Fri, Dec 28, 2018 at 02:53:22PM +0100, Paolo Bonzini wrote:
> On 25/12/18 09:23, Kang, Luwei wrote:
> >> From: Qemu-devel 
> >> [mailto:qemu-devel-bounces+luwei.kang=intel@nongnu.org] On Behalf Of 
> >> Paolo Bonzini
> >> Sent: Friday, December 21, 2018 8:44 PM
> >> To: qemu-devel@nongnu.org
> >> Cc: ehabk...@redhat.com; qemu-sta...@nongnu.org
> >> Subject: [Qemu-devel] [PATCH] i386: mark the 'INTEL_PT' CPUID bit as 
> >> unmigratable
> >>
> >> Marshaling of processor tracing MSRs is not yet implemented in QEMU, mark 
> >> the feature as unmigratable.
> > 
> > Hi Paolo,
> > I think Intel PT has supported live migration. I don't understand what 
> > you mean.
> > 
> > commit b77146e9a129bcdb60edc23639211679ae846a92
> > Author: Chao Peng 
> > Date:   Mon Mar 5 00:48:36 2018 +0800
> > i386: Add support to get/set/migrate Intel Processor Trace feature
> 
> Indeed.  I had forgotten this patch because it was committed so long
> before the kernel parts (which really should not happen, but Eduardo and
> I miscommunicated on it).  Can you check that it still works?

My mistake, sorry.  I should have checked the status of the
kernel code before merging the original series, or waited for
your review.

I'm re-reading the code now and I'm worried about two things:

The code will break if GET_SUPPORTED_CPUID returns INTEL_PT, but
the MSR emulation code is not present yet.  Maybe it won't be an
issue in practice because it happens only between the two Linux
commits (commit 86f5201df0d3 "KVM: x86: Add Intel Processor Trace
cpuid emulation" and commit bf8c55d8dc09 "KVM: x86: Implement
Intel PT MSRs read/write emulation") and shipping a kernel with
the CPUID code without the MSR commit seems pointless.

The kvm_arch_get_supported_cpuid() call inside kvm_get_msrs()
looks suspicious.  What should happen if we try to migrate to a
host that returns a smaller number on
kvm_arch_get_supported_cpuid(0x14, 1, R_EAX)?

-- 
Eduardo