Re: [Qemu-devel] [RFC v3 PATCH 14/14] target-i386: Generate fences for x86

2016-06-17 Thread Richard Henderson

On 06/17/2016 09:03 PM, Pranith Kumar wrote:

 case 0xe8 ... 0xef: /* lfence */
+tcg_gen_mb(TCG_MO_LD_LD | TCG_BAR_SC);
+break;
 case 0xf0 ... 0xf7: /* mfence */
 if (!(s->cpuid_features & CPUID_SSE2)
 || (prefixes & PREFIX_LOCK)) {
 goto illegal_op;
 }
+tcg_gen_mb(TCG_MO_ALL | TCG_BAR_SC);


You need to duplicate the sse2 check if you split lfence from mfence.


r~



Re: [Qemu-devel] [PATCH] target-ppc: Correct ppc3500_spin initial TLB size

2016-06-17 Thread Scott Wood
On 06/17/2016 05:13 PM, Aaron Larson wrote:
> When e500 PPC is booted multi-core, the non-boot cores are started via
> the spin table.  ppce500_spin.c:spin_kick() calls
> mmubooke_create_initial_mapping() to allocate a 64MB TLB entry, but
> the created TLB entry is only 256KB.
> 
> The root cause is that the function computing the size of the TLB
> entry, namely booke206_page_size_to_tlb assumes MAS1.TSIZE as defined
> by latter PPC cores, specifically (n**4)KB. The result is then used by
> mmubooke_create_initial_mapping using MAS1_TSIZE_SHIFT, but
> MAS1_TSIZE_SHIFT is defined assuming TLB entries are (n**2)KB. I.e., a
> difference of shift=7 or shift=8.
> 
> Simply changing MAS1_TSIZE_SHIFT from 7 to 8 is not appropriate since
> the macro is used elsewhere.
> 
> Signed-off-by: Aaron Larson 
> ---
>  hw/ppc/ppce500_spin.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/ppc/ppce500_spin.c b/hw/ppc/ppce500_spin.c
> index 76bd78b..7e38f0c 100644
> --- a/hw/ppc/ppce500_spin.c
> +++ b/hw/ppc/ppce500_spin.c
> @@ -75,7 +75,11 @@ static void spin_reset(void *opaque)
>  /* Create -kernel TLB entries for BookE, linearly spanning 256MB.  */
>  static inline hwaddr booke206_page_size_to_tlb(uint64_t size)
>  {
> -return ctz32(size >> 10) >> 1;
> +/* The EREF indicates that TLB pages are (4 to the power of 2)KB, which
> + * corresponds to MAS1_TSIZE_SHIFT=8, but to support legacy processors 
> that
> + * assume TLB pages are (2 to the power of 2)KB MAS1_TSIZE_SHIFT is
> + * currently 7. */

This is backwards. It's the old processors that can only handle
power-of-4 sizes.

> +return ctz32(size >> 10) >> (MAS1_TSIZE_SHIFT - 7);

The patch that changed MAS1_TSIZE_SHIFT from 8 to 7 was around the same
time as the patch that added this code, which is probably why adjusting
it got missed.  Commit 2bd9543cd3 did update the equivalent code in
ppce500_mpc8544ds.c, which now resides in hw/ppc/e500.c and has been
changed to not assume a power-of-2 size.  The ppce500_spin version
should be eliminated.

-Scott




[Qemu-devel] [PATCH] rbd: reload ceph config for block device

2016-06-17 Thread Vaibhav Bhembre
This patch adds ability to reload ceph configuration for an attached RBD
block device. This is necessary for the cases where rebooting a VM and/or
detaching-reattaching a RBD drive is not an easy option.

The reload mechanism relies on the bdrv_reopen_* calls to provide a 
transactional
guarantee (using 2PC) for pulling in new configuration parameters. In the 
_prepare
phase we do the grunt-work of creating and establishing new connection and open
another instance of the same RBD image. If any issues are observed while 
creating a
connection using the new parameters we _abort the reload. The original 
connection to
the cluster is kept available and all ongoing I/O on it should be fine.

Once the _prepare phase completes successfully we enter the _commit phase. In 
this phase
we simple move the I/O over to the new fd for the corresponding image we have 
already
created in the _prepare phase and reclaim the old rados I/O context and 
connection.

It is important to note that because we want to use this feature when a QEMU VM 
is already
running, we need to switch the logic to have values in ceph.conf override the 
ones present
in the -drive file=* string in order for new changes to take place, for same 
keys present
in both places.

Signed-off-by: Vaibhav Bhembre 
---
 block/rbd.c  | 122 +++
 hmp-commands.hx  |  14 +++
 hmp.c|  13 ++
 hmp.h|   1 +
 qapi-schema.json |  13 ++
 qmp-commands.hx  |  21 ++
 qmp.c|  31 ++
 7 files changed, 215 insertions(+)

diff --git a/block/rbd.c b/block/rbd.c
index 5226b6f..605f531 100644
--- a/block/rbd.c
+++ b/block/rbd.c
@@ -932,6 +932,125 @@ static int qemu_rbd_snap_list(BlockDriverState *bs,
 return snap_count;
 }
 
+static int qemu_rbd_reopen_prepare(BDRVReopenState *reopen_state,
+   BlockReopenQueue *queue, Error **errp)
+{
+BDRVRBDState *new_s;
+rados_t c;
+rados_ioctx_t io_ctx;
+char pool[RBD_MAX_POOL_NAME_SIZE];
+char snap_buf[RBD_MAX_SNAP_NAME_SIZE];
+char conf[RBD_MAX_CONF_SIZE];
+char clientname_buf[RBD_MAX_CONF_VAL_SIZE];
+char *clientname;
+int r;
+
+new_s = reopen_state->opaque = g_new0(BDRVRBDState, 1);
+
+r = qemu_rbd_parsename(reopen_state->bs->filename,
+   pool, sizeof pool,
+   snap_buf, sizeof snap_buf,
+   new_s->name, sizeof new_s->name,
+   conf, sizeof conf,
+   errp);
+if (r < 0) {
+return r;
+}
+
+if (snap_buf[0] != '\0') {
+new_s->snap = g_strdup(snap_buf);
+}
+
+clientname = qemu_rbd_parse_clientname(conf, clientname_buf);
+r = rados_create(, clientname);
+if (r < 0) {
+error_setg_errno(errp, -r, "error creating cluster from config");
+return r;
+}
+new_s->cluster = c;
+
+if (conf[0] != '\0') {
+r = qemu_rbd_set_conf(c, conf, false, errp);
+if (r < 0) {
+error_setg_errno(errp, -r, "error setting config");
+return r;
+}
+}
+
+if (strstr(conf, "conf=") == NULL) {
+r = rados_conf_read_file(c, NULL);
+} else if (conf[0] != '\0') {
+r = qemu_rbd_set_conf(c, conf, true, errp);
+}
+
+if (r < 0) {
+error_setg_errno(errp, -r, "error parsing config");
+return r;
+}
+
+r = rados_connect(c);
+if (r < 0) {
+error_setg_errno(errp, -r, "error connecting");
+return r;
+}
+
+r = rados_ioctx_create(c, pool, _ctx);
+if (r < 0) {
+error_setg_errno(errp, -r, "error creating ioctx");
+return r;
+}
+new_s->io_ctx = io_ctx;
+
+r = rbd_open(io_ctx, new_s->name, _s->image, new_s->snap);
+if (r < 0) {
+error_setg_errno(errp, -r, "error opening rbd");
+return r;
+}
+
+return 0;
+}
+
+static void qemu_rbd_reopen_abort(BDRVReopenState *reopen_state)
+{
+BDRVRBDState *new_s = reopen_state->opaque;
+
+if (new_s->io_ctx) {
+rados_ioctx_destroy(new_s->io_ctx);
+}
+
+if (new_s->cluster) {
+rados_shutdown(new_s->cluster);
+}
+
+g_free(new_s->snap);
+g_free(reopen_state->opaque);
+reopen_state->opaque = NULL;
+}
+
+static void qemu_rbd_reopen_commit(BDRVReopenState *reopen_state)
+{
+BDRVRBDState *s, *new_s;
+
+s = reopen_state->bs->opaque;
+new_s = reopen_state->opaque;
+
+rados_aio_flush(s->io_ctx);
+
+rbd_close(s->image);
+rados_ioctx_destroy(s->io_ctx);
+g_free(s->snap);
+rados_shutdown(s->cluster);
+
+s->io_ctx = new_s->io_ctx;
+s->cluster = new_s->cluster;
+s->image = new_s->image;
+s->snap = new_s->snap;
+reopen_state->bs->read_only = (s->snap != NULL);
+
+g_free(reopen_state->opaque);
+reopen_state->opaque = NULL;
+}
+
 #ifdef LIBRBD_SUPPORTS_DISCARD
 static 

[Qemu-devel] [PATCH] target-ppc: Correct ppc3500_spin initial TLB size

2016-06-17 Thread Aaron Larson
When e500 PPC is booted multi-core, the non-boot cores are started via
the spin table.  ppce500_spin.c:spin_kick() calls
mmubooke_create_initial_mapping() to allocate a 64MB TLB entry, but
the created TLB entry is only 256KB.

The root cause is that the function computing the size of the TLB
entry, namely booke206_page_size_to_tlb assumes MAS1.TSIZE as defined
by latter PPC cores, specifically (n**4)KB. The result is then used by
mmubooke_create_initial_mapping using MAS1_TSIZE_SHIFT, but
MAS1_TSIZE_SHIFT is defined assuming TLB entries are (n**2)KB. I.e., a
difference of shift=7 or shift=8.

Simply changing MAS1_TSIZE_SHIFT from 7 to 8 is not appropriate since
the macro is used elsewhere.

Signed-off-by: Aaron Larson 
---
 hw/ppc/ppce500_spin.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/hw/ppc/ppce500_spin.c b/hw/ppc/ppce500_spin.c
index 76bd78b..7e38f0c 100644
--- a/hw/ppc/ppce500_spin.c
+++ b/hw/ppc/ppce500_spin.c
@@ -75,7 +75,11 @@ static void spin_reset(void *opaque)
 /* Create -kernel TLB entries for BookE, linearly spanning 256MB.  */
 static inline hwaddr booke206_page_size_to_tlb(uint64_t size)
 {
-return ctz32(size >> 10) >> 1;
+/* The EREF indicates that TLB pages are (4 to the power of 2)KB, which
+ * corresponds to MAS1_TSIZE_SHIFT=8, but to support legacy processors that
+ * assume TLB pages are (2 to the power of 2)KB MAS1_TSIZE_SHIFT is
+ * currently 7. */
+return ctz32(size >> 10) >> (MAS1_TSIZE_SHIFT - 7);
 }
 
 static void mmubooke_create_initial_mapping(CPUPPCState *env,
-- 
2.7.4




[Qemu-devel] [PATCH v2] target-ppc: Fix rlwimi, rlwinm, rlwnm

2016-06-17 Thread Richard Henderson
In 63ae0915f8ec, I arranged to use a 32-bit rotate, without
considering the effect of a mask value that wraps around to
the high bits of the word.

Signed-off-by: Richard Henderson 
---
 target-ppc/translate.c | 73 +++---
 1 file changed, 51 insertions(+), 22 deletions(-)

diff --git a/target-ppc/translate.c b/target-ppc/translate.c
index b689475..23bc054 100644
--- a/target-ppc/translate.c
+++ b/target-ppc/translate.c
@@ -1636,7 +1636,6 @@ static void gen_rlwimi(DisasContext *ctx)
 tcg_gen_deposit_tl(t_ra, t_ra, t_rs, sh, me - mb + 1);
 } else {
 target_ulong mask;
-TCGv_i32 t0;
 TCGv t1;
 
 #if defined(TARGET_PPC64)
@@ -1645,12 +1644,21 @@ static void gen_rlwimi(DisasContext *ctx)
 #endif
 mask = MASK(mb, me);
 
-t0 = tcg_temp_new_i32();
 t1 = tcg_temp_new();
-tcg_gen_trunc_tl_i32(t0, t_rs);
-tcg_gen_rotli_i32(t0, t0, sh);
-tcg_gen_extu_i32_tl(t1, t0);
-tcg_temp_free_i32(t0);
+if (mask <= 0xu) {
+TCGv_i32 t0 = tcg_temp_new_i32();
+tcg_gen_trunc_tl_i32(t0, t_rs);
+tcg_gen_rotli_i32(t0, t0, sh);
+tcg_gen_extu_i32_tl(t1, t0);
+tcg_temp_free_i32(t0);
+} else {
+#if defined(TARGET_PPC64)
+tcg_gen_deposit_i64(t1, t_rs, t_rs, 32, 32);
+tcg_gen_rotli_i64(t1, t1, sh);
+#else
+g_assert_not_reached();
+#endif
+}
 
 tcg_gen_andi_tl(t1, t1, mask);
 tcg_gen_andi_tl(t_ra, t_ra, ~mask);
@@ -1678,20 +1686,28 @@ static void gen_rlwinm(DisasContext *ctx)
 tcg_gen_ext32u_tl(t_ra, t_rs);
 tcg_gen_shri_tl(t_ra, t_ra, mb);
 } else {
+target_ulong mask;
 #if defined(TARGET_PPC64)
 mb += 32;
 me += 32;
 #endif
-if (sh == 0) {
-tcg_gen_andi_tl(t_ra, t_rs, MASK(mb, me));
-} else {
-TCGv_i32 t0 = tcg_temp_new_i32();
+mask = MASK(mb, me);
 
+if (mask <= 0xu) {
+TCGv_i32 t0 = tcg_temp_new_i32();
 tcg_gen_trunc_tl_i32(t0, t_rs);
 tcg_gen_rotli_i32(t0, t0, sh);
-tcg_gen_andi_i32(t0, t0, MASK(mb, me));
+tcg_gen_andi_i32(t0, t0, mask);
 tcg_gen_extu_i32_tl(t_ra, t0);
 tcg_temp_free_i32(t0);
+} else {
+#if defined(TARGET_PPC64)
+tcg_gen_deposit_i64(t_ra, t_rs, t_rs, 32, 32);
+tcg_gen_rotli_i64(t_ra, t_ra, sh);
+tcg_gen_andi_i64(t_ra, t_ra, mask);
+#else
+g_assert_not_reached();
+#endif
 }
 }
 if (unlikely(Rc(ctx->opcode) != 0)) {
@@ -1707,24 +1723,37 @@ static void gen_rlwnm(DisasContext *ctx)
 TCGv t_rb = cpu_gpr[rB(ctx->opcode)];
 uint32_t mb = MB(ctx->opcode);
 uint32_t me = ME(ctx->opcode);
-TCGv_i32 t0, t1;
+target_ulong mask;
 
 #if defined(TARGET_PPC64)
 mb += 32;
 me += 32;
 #endif
+mask = MASK(mb, me);
 
-t0 = tcg_temp_new_i32();
-t1 = tcg_temp_new_i32();
-tcg_gen_trunc_tl_i32(t0, t_rb);
-tcg_gen_trunc_tl_i32(t1, t_rs);
-tcg_gen_andi_i32(t0, t0, 0x1f);
-tcg_gen_rotl_i32(t1, t1, t0);
-tcg_temp_free_i32(t0);
+if (mask <= 0xu) {
+TCGv_i32 t0 = tcg_temp_new_i32();
+TCGv_i32 t1 = tcg_temp_new_i32();
+tcg_gen_trunc_tl_i32(t0, t_rb);
+tcg_gen_trunc_tl_i32(t1, t_rs);
+tcg_gen_andi_i32(t0, t0, 0x1f);
+tcg_gen_rotl_i32(t1, t1, t0);
+tcg_gen_extu_i32_tl(t_ra, t1);
+tcg_temp_free_i32(t0);
+tcg_temp_free_i32(t1);
+} else {
+#if defined(TARGET_PPC64)
+TCGv_i64 t0 = tcg_temp_new_i64();
+tcg_gen_andi_i64(t0, t_rb, 0x1f);
+tcg_gen_deposit_i64(t_ra, t_rs, t_rs, 32, 32);
+tcg_gen_rotl_i64(t_ra, t_ra, t0);
+tcg_temp_free_i64(t0);
+#else
+g_assert_not_reached();
+#endif
+}
 
-tcg_gen_andi_i32(t1, t1, MASK(mb, me));
-tcg_gen_extu_i32_tl(t_ra, t1);
-tcg_temp_free_i32(t1);
+tcg_gen_andi_tl(t_ra, t_ra, mask);
 
 if (unlikely(Rc(ctx->opcode) != 0)) {
 gen_set_Rc0(ctx, t_ra);
-- 
2.5.5




Re: [Qemu-devel] [PULL 03/13] target-ppc: Use 32-bit rotate instead of deposit + 64-bit rotate

2016-06-17 Thread Richard Henderson

On 06/17/2016 09:02 PM, Anton Blanchard wrote:

lis r4,0x7fff@h
ori r4,r4,0x7fff@l
rlwinm  r3,r4,0,25,1


Ah, with zero rotate.  I see.  New patch coming up.


r~



[Qemu-devel] [PATCH 2/2] tcg: Fix allocation of indirect_base registers

2016-06-17 Thread Richard Henderson
When the number of available registers is low, we need to be
prepared for TS to overlap MEM_BASE.

This fixes the Sparc64 OpenBIOS boot on i686.

Signed-off-by: Richard Henderson 
---
 tcg/tcg.c | 68 +++
 1 file changed, 47 insertions(+), 21 deletions(-)

diff --git a/tcg/tcg.c b/tcg/tcg.c
index 154ffe8..6c26ee4 100644
--- a/tcg/tcg.c
+++ b/tcg/tcg.c
@@ -1743,32 +1743,71 @@ static TCGReg tcg_reg_alloc(TCGContext *s, TCGRegSet 
desired_regs,
 tcg_abort();
 }
 
+/* Mark a temporary as dead.  */
+static void temp_dead(TCGContext *s, TCGTemp *ts)
+{
+if (ts->fixed_reg) {
+return;
+}
+if (ts->val_type == TEMP_VAL_REG) {
+s->reg_to_temp[ts->reg] = NULL;
+}
+ts->val_type = (temp_idx(s, ts) < s->nb_globals || ts->temp_local
+? TEMP_VAL_MEM : TEMP_VAL_DEAD);
+}
+
 /* Make sure the temporary is in a register.  If needed, allocate the register
from DESIRED while avoiding ALLOCATED.  */
 static void temp_load(TCGContext *s, TCGTemp *ts, TCGRegSet desired_regs,
   TCGRegSet allocated_regs)
 {
-TCGReg reg;
+TCGReg reg, base_reg;
+TCGTemp *base;
 
 switch (ts->val_type) {
 case TEMP_VAL_REG:
 return;
+
 case TEMP_VAL_CONST:
 reg = tcg_reg_alloc(s, desired_regs, allocated_regs, 
ts->indirect_base);
 tcg_out_movi(s, ts->type, reg, ts->val);
 ts->mem_coherent = 0;
 break;
+
 case TEMP_VAL_MEM:
-reg = tcg_reg_alloc(s, desired_regs, allocated_regs, 
ts->indirect_base);
-if (ts->indirect_reg) {
-tcg_regset_set_reg(allocated_regs, reg);
-temp_load(s, ts->mem_base,
-  tcg_target_available_regs[TCG_TYPE_PTR],
-  allocated_regs);
+base = ts->mem_base;
+base_reg = base->reg;
+if (ts->indirect_reg && base->val_type != TEMP_VAL_REG) {
+TCGRegSet reg_avail = desired_regs & ~allocated_regs;
+TCGRegSet base_avail = (tcg_target_available_regs[TCG_TYPE_PTR]
+& ~allocated_regs);
+if (is_power_of_2(reg_avail)) {
+/* There is only one register available for TS.  If there are
+   other available registers for BASE, make sure we pick one
+   of them.  Otherwise BASE and TS will share a reg.  */
+TCGRegSet avail = base_avail & ~reg_avail;
+if (avail) {
+base_avail = avail;
+}
+temp_load(s, base, base_avail, allocated_regs);
+base_reg = base->reg;
+} else {
+temp_load(s, base, base_avail, allocated_regs);
+base_reg = base->reg;
+tcg_regset_reset_reg(allocated_regs, base_reg);
+}
 }
-tcg_out_ld(s, ts->type, reg, ts->mem_base->reg, ts->mem_offset);
+
+reg = tcg_reg_alloc(s, desired_regs, allocated_regs, 
ts->indirect_base);
+tcg_out_ld(s, ts->type, reg, base_reg, ts->mem_offset);
 ts->mem_coherent = 1;
+
+/* If the registers overlap, zap the info from BASE.  */
+if (reg == base_reg) {
+temp_dead(s, base);
+}
 break;
+
 case TEMP_VAL_DEAD:
 default:
 tcg_abort();
@@ -1778,19 +1817,6 @@ static void temp_load(TCGContext *s, TCGTemp *ts, 
TCGRegSet desired_regs,
 s->reg_to_temp[reg] = ts;
 }
 
-/* mark a temporary as dead. */
-static inline void temp_dead(TCGContext *s, TCGTemp *ts)
-{
-if (ts->fixed_reg) {
-return;
-}
-if (ts->val_type == TEMP_VAL_REG) {
-s->reg_to_temp[ts->reg] = NULL;
-}
-ts->val_type = (temp_idx(s, ts) < s->nb_globals || ts->temp_local
-? TEMP_VAL_MEM : TEMP_VAL_DEAD);
-}
-
 /* sync a temporary to memory. 'allocated_regs' is used in case a
temporary registers needs to be allocated to store a constant. */
 static void temp_sync(TCGContext *s, TCGTemp *ts, TCGRegSet allocated_regs)
-- 
2.5.5




[Qemu-devel] [PATCH 0/2] tcg: Fix i686 booting sparc64 openbios

2016-06-17 Thread Richard Henderson
There's a minor typo here that affects dumping of 64-bit
registers on 32-bit hosts.  Kind of embarrasing that this
hasn't been seen previously.

The main change takes care of cases wherein there's overlap
between the indirect base register and the main global, which
can happen in conditions of very high register pressure.

The bug report is at

http://lists.nongnu.org/archive/html/qemu-devel/2016-06/msg04947.html


r~


Richard Henderson (2):
  tcg: Fix name for high-half register
  tcg: Fix allocation of indirect_base registers

 tcg/tcg.c | 70 +++
 1 file changed, 48 insertions(+), 22 deletions(-)

-- 
2.5.5




[Qemu-devel] [PATCH 1/2] tcg: Fix name for high-half register

2016-06-17 Thread Richard Henderson
Signed-off-by: Richard Henderson 
---
 tcg/tcg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tcg/tcg.c b/tcg/tcg.c
index 254427b..154ffe8 100644
--- a/tcg/tcg.c
+++ b/tcg/tcg.c
@@ -557,7 +557,7 @@ int tcg_global_mem_new_internal(TCGType type, TCGv_ptr base,
 ts2->mem_offset = offset + (1 - bigendian) * 4;
 pstrcpy(buf, sizeof(buf), name);
 pstrcat(buf, sizeof(buf), "_1");
-ts->name = strdup(buf);
+ts2->name = strdup(buf);
 } else {
 ts->base_type = type;
 ts->type = type;
-- 
2.5.5




[Qemu-devel] [RFC v3 PATCH 14/14] target-i386: Generate fences for x86

2016-06-17 Thread Pranith Kumar
Signed-off-by: Pranith Kumar 
---
 target-i386/translate.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/target-i386/translate.c b/target-i386/translate.c
index bf33e6b..32b0f5c 100644
--- a/target-i386/translate.c
+++ b/target-i386/translate.c
@@ -8012,13 +8012,17 @@ static target_ulong disas_insn(CPUX86State *env, 
DisasContext *s,
 || (prefixes & PREFIX_LOCK)) {
 goto illegal_op;
 }
+tcg_gen_mb(TCG_MO_ST_ST | TCG_BAR_SC);
 break;
 case 0xe8 ... 0xef: /* lfence */
+tcg_gen_mb(TCG_MO_LD_LD | TCG_BAR_SC);
+break;
 case 0xf0 ... 0xf7: /* mfence */
 if (!(s->cpuid_features & CPUID_SSE2)
 || (prefixes & PREFIX_LOCK)) {
 goto illegal_op;
 }
+tcg_gen_mb(TCG_MO_ALL | TCG_BAR_SC);
 break;
 
 default:
-- 
2.9.0




[Qemu-devel] [RFC v3 PATCH 13/14] aarch64: Generate fences for aarch64

2016-06-17 Thread Pranith Kumar
Signed-off-by: Pranith Kumar 
---
 target-arm/translate-a64.c | 18 +-
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/target-arm/translate-a64.c b/target-arm/translate-a64.c
index ce8141a..fa24bf2 100644
--- a/target-arm/translate-a64.c
+++ b/target-arm/translate-a64.c
@@ -1250,7 +1250,7 @@ static void handle_sync(DisasContext *s, uint32_t insn,
 return;
 case 4: /* DSB */
 case 5: /* DMB */
-/* We don't emulate caches so barriers are no-ops */
+tcg_gen_mb(TCG_MO_ALL | TCG_BAR_SC);
 return;
 case 6: /* ISB */
 /* We need to break the TB after this insn to execute
@@ -1855,23 +1855,31 @@ static void disas_ldst_excl(DisasContext *s, uint32_t 
insn)
 }
 tcg_addr = read_cpu_reg_sp(s, rn, 1);
 
-/* Note that since TCG is single threaded load-acquire/store-release
- * semantics require no extra if (is_lasr) { ... } handling.
- */
-
 if (is_excl) {
 if (!is_store) {
 s->is_ldex = true;
 gen_load_exclusive(s, rt, rt2, tcg_addr, size, is_pair);
+if (is_lasr) {
+tcg_gen_mb(TCG_MO_ALL | TCG_BAR_ACQ);
+}
 } else {
+if (is_lasr) {
+tcg_gen_mb(TCG_MO_ALL | TCG_BAR_REL);
+}
 gen_store_exclusive(s, rs, rt, rt2, tcg_addr, size, is_pair);
 }
 } else {
 TCGv_i64 tcg_rt = cpu_reg(s, rt);
 if (is_store) {
+if (is_lasr) {
+tcg_gen_mb(TCG_MO_ALL | TCG_BAR_REL);
+}
 do_gpr_st(s, tcg_rt, tcg_addr, size);
 } else {
 do_gpr_ld(s, tcg_rt, tcg_addr, size, false, false);
+if (is_lasr) {
+tcg_gen_mb(TCG_MO_ALL | TCG_BAR_ACQ);
+}
 }
 }
 }
-- 
2.9.0




[Qemu-devel] [RFC v3 PATCH 00/14] tcg: Add fence gen support

2016-06-17 Thread Pranith Kumar
Hello,

The following series adds fence instruction generation support to
TCG. Based on feedback to the last series, I added the four
combinations of orderings modeled after Sparc membar.

This has been tested and confirmed to fix ordering issues on
x86/armv7/aarch64 hosts with MTTCG enabled for an ARMv7 guest using
KVM unit tests.

TODO:

* The acquire/release order is not utilized yet. Currently we generate
  SC barriers even for acquire/release barriers. The idea is to write
  a pass which combines acquire/release barrier with its corresponding
  load/store operation to generate the load acquire/store release
  instruction on hosts which have such instruction(aarch64 for
  now). Also the pass should try to optimize some trivial scenarios
  like removing unnecessary barrier instructions.

* Complete support for fence generation in other architectures.

v3:

- Create different types of barriers. The barrier tcg opcode now takes
  an argument to generate the appropriate barrier instruction.
- Also add acquire/release/sc ordering flag to argument.

v2:

- Rebase on Richard's patches generating fences for other
  architectures.

v1:

- Initial version: Introduce memory barrier tcg opcode.

Pranith Kumar (14):
  Introduce TCGOpcode for memory barrier
  tcg/i386: Add support for fence
  tcg/aarch64: Add support for fence
  tcg/arm: Add support for fence
  tcg/ia64: Add support for fence
  tcg/mips: Add support for fence
  tcg/ppc: Add support for fence
  tcg/s390: Add support for fence
  tcg/sparc: Add support for fence
  tcg/tci: Add support for fence
  target-arm: Generate fences in ARMv7 frontend
  target-alpha: Generate fence op
  aarch64: Generate fences for aarch64
  target-i386: Generate fences for x86

 target-alpha/translate.c |  4 ++--
 target-arm/translate-a64.c   | 18 -
 target-arm/translate.c   |  4 ++--
 target-i386/translate.c  |  4 
 tcg/README   | 17 
 tcg/aarch64/tcg-target.inc.c | 25 +++
 tcg/arm/tcg-target.inc.c | 18 +
 tcg/i386/tcg-target.inc.c| 47 
 tcg/ia64/tcg-target.inc.c|  5 +
 tcg/mips/tcg-target.inc.c|  6 ++
 tcg/ppc/tcg-target.inc.c | 24 ++
 tcg/s390/tcg-target.inc.c|  9 +
 tcg/sparc/tcg-target.inc.c   | 25 +++
 tcg/tcg-op.c | 11 +++
 tcg/tcg-op.h |  2 ++
 tcg/tcg-opc.h|  2 ++
 tcg/tcg.h| 14 +
 tcg/tci/tcg-target.inc.c |  3 +++
 tci.c|  3 +++
 19 files changed, 232 insertions(+), 9 deletions(-)

-- 
2.9.0




[Qemu-devel] [RFC v3 PATCH 11/14] target-arm: Generate fences in ARMv7 frontend

2016-06-17 Thread Pranith Kumar
Signed-off-by: Pranith Kumar 
Signed-off-by: Richard Henderson 
---
 target-arm/translate.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/target-arm/translate.c b/target-arm/translate.c
index e525f1e..012e450 100644
--- a/target-arm/translate.c
+++ b/target-arm/translate.c
@@ -8054,7 +8054,7 @@ static void disas_arm_insn(DisasContext *s, unsigned int 
insn)
 case 4: /* dsb */
 case 5: /* dmb */
 ARCH(7);
-/* We don't emulate caches so these are a no-op.  */
+tcg_gen_mb(TCG_MO_ALL | TCG_BAR_SC);
 return;
 case 6: /* isb */
 /* We need to break the TB after this insn to execute
@@ -10403,7 +10403,7 @@ static int disas_thumb2_insn(CPUARMState *env, 
DisasContext *s, uint16_t insn_hw
 break;
 case 4: /* dsb */
 case 5: /* dmb */
-/* These execute as NOPs.  */
+tcg_gen_mb(TCG_MO_ALL | TCG_BAR_SC);
 break;
 case 6: /* isb */
 /* We need to break the TB after this insn
-- 
2.9.0




[Qemu-devel] [RFC v3 PATCH 10/14] tcg/tci: Add support for fence

2016-06-17 Thread Pranith Kumar
Cc: Stefan Weil 
Signed-off-by: Richard Henderson 
Signed-off-by: Pranith Kumar 
---
 tcg/tci/tcg-target.inc.c | 3 +++
 tci.c| 3 +++
 2 files changed, 6 insertions(+)

diff --git a/tcg/tci/tcg-target.inc.c b/tcg/tci/tcg-target.inc.c
index fa74d52..8e950df 100644
--- a/tcg/tci/tcg-target.inc.c
+++ b/tcg/tci/tcg-target.inc.c
@@ -255,6 +255,7 @@ static const TCGTargetOpDef tcg_target_op_defs[] = {
 { INDEX_op_bswap32_i32, { R, R } },
 #endif
 
+{ INDEX_op_mb, { } },
 { -1 },
 };
 
@@ -800,6 +801,8 @@ static void tcg_out_op(TCGContext *s, TCGOpcode opc, const 
TCGArg *args,
 }
 tcg_out_i(s, *args++);
 break;
+case INDEX_op_mb:
+break;
 case INDEX_op_mov_i32:  /* Always emitted via tcg_out_mov.  */
 case INDEX_op_mov_i64:
 case INDEX_op_movi_i32: /* Always emitted via tcg_out_movi.  */
diff --git a/tci.c b/tci.c
index b488c0d..4081e61 100644
--- a/tci.c
+++ b/tci.c
@@ -1236,6 +1236,9 @@ uintptr_t tcg_qemu_tb_exec(CPUArchState *env, uint8_t 
*tb_ptr)
 tcg_abort();
 }
 break;
+case INDEX_op_mb:
+smp_mb();
+break;
 default:
 TODO();
 break;
-- 
2.9.0




[Qemu-devel] [RFC v3 PATCH 12/14] target-alpha: Generate fence op

2016-06-17 Thread Pranith Kumar
Signed-off-by: Richard Henderson 
Signed-off-by: Pranith Kumar 
---
 target-alpha/translate.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/target-alpha/translate.c b/target-alpha/translate.c
index 76dab15..f0bba40 100644
--- a/target-alpha/translate.c
+++ b/target-alpha/translate.c
@@ -2334,11 +2334,11 @@ static ExitStatus translate_one(DisasContext *ctx, 
uint32_t insn)
 break;
 case 0x4000:
 /* MB */
-/* No-op */
+tcg_gen_mb(TCG_MO_ALL | TCG_BAR_SC);
 break;
 case 0x4400:
 /* WMB */
-/* No-op */
+tcg_gen_mb(TCG_MO_ST_ST | TCG_BAR_SC);
 break;
 case 0x8000:
 /* FETCH */
-- 
2.9.0




[Qemu-devel] [RFC v3 PATCH 03/14] tcg/aarch64: Add support for fence

2016-06-17 Thread Pranith Kumar
Cc: Claudio Fontana 
Signed-off-by: Richard Henderson 
Signed-off-by: Pranith Kumar 
---
 tcg/aarch64/tcg-target.inc.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/tcg/aarch64/tcg-target.inc.c b/tcg/aarch64/tcg-target.inc.c
index 1447f7c..bc8ac9c 100644
--- a/tcg/aarch64/tcg-target.inc.c
+++ b/tcg/aarch64/tcg-target.inc.c
@@ -372,6 +372,11 @@ typedef enum {
 I3510_EOR   = 0x4a00,
 I3510_EON   = 0x4a20,
 I3510_ANDS  = 0x6a00,
+
+/* System instructions.  */
+DMB_ISH = 0xd50338bf,
+DMB_LD  = 0x0100,
+DMB_ST  = 0x0200,
 } AArch64Insn;
 
 static inline uint32_t tcg_in32(TCGContext *s)
@@ -971,6 +976,21 @@ static inline void tcg_out_addsub2(TCGContext *s, int ext, 
TCGReg rl,
 tcg_out_mov(s, ext, orig_rl, rl);
 }
 
+static inline void tcg_out_mb(TCGContext *s, TCGArg a0)
+{
+switch (a0 & TCG_MO_ALL) {
+case TCG_MO_LD_LD:
+tcg_out32(s, DMB_ISH | DMB_LD);
+break;
+case TCG_MO_ST_ST:
+tcg_out32(s, DMB_ISH | DMB_ST);
+break;
+default:
+tcg_out32(s, DMB_ISH | DMB_LD | DMB_ST);
+break;
+}
+}
+
 #ifdef CONFIG_SOFTMMU
 /* helper signature: helper_ret_ld_mmu(CPUState *env, target_ulong addr,
  * TCGMemOpIdx oi, uintptr_t ra)
@@ -1637,6 +1657,10 @@ static void tcg_out_op(TCGContext *s, TCGOpcode opc,
 tcg_out_insn(s, 3508, SMULH, TCG_TYPE_I64, a0, a1, a2);
 break;
 
+case INDEX_op_mb:
+tcg_out_mb(s, a0);
+break;
+
 case INDEX_op_mov_i32:  /* Always emitted via tcg_out_mov.  */
 case INDEX_op_mov_i64:
 case INDEX_op_movi_i32: /* Always emitted via tcg_out_movi.  */
@@ -1761,6 +1785,7 @@ static const TCGTargetOpDef aarch64_op_defs[] = {
 { INDEX_op_muluh_i64, { "r", "r", "r" } },
 { INDEX_op_mulsh_i64, { "r", "r", "r" } },
 
+{ INDEX_op_mb, { } },
 { -1 },
 };
 
-- 
2.9.0




[Qemu-devel] [RFC v3 PATCH 04/14] tcg/arm: Add support for fence

2016-06-17 Thread Pranith Kumar
Cc: Andrzej Zaborowski 
Cc: Peter Maydell 
Signed-off-by: Pranith Kumar 
Signed-off-by: Richard Henderson 
---
 tcg/arm/tcg-target.inc.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/tcg/arm/tcg-target.inc.c b/tcg/arm/tcg-target.inc.c
index f9f54c6..1447aa8 100644
--- a/tcg/arm/tcg-target.inc.c
+++ b/tcg/arm/tcg-target.inc.c
@@ -313,6 +313,10 @@ typedef enum {
 INSN_LDRD_REG  = 0x00d0,
 INSN_STRD_IMM  = 0x004000f0,
 INSN_STRD_REG  = 0x00f0,
+
+INSN_DMB_ISH   = 0x5bf07ff5,
+INSN_DMB_MCR   = 0xba0f07ee,
+
 } ARMInsn;
 
 #define SHIFT_IMM_LSL(im)  (((im) << 7) | 0x00)
@@ -1066,6 +1070,15 @@ static inline void tcg_out_goto_label(TCGContext *s, int 
cond, TCGLabel *l)
 }
 }
 
+static inline void tcg_out_mb(TCGContext *s, TCGArg a0)
+{
+if (use_armv7_instructions) {
+tcg_out32(s, INSN_DMB_ISH);
+} else if (use_armv6_instructions) {
+tcg_out32(s, INSN_DMB_MCR);
+}
+}
+
 #ifdef CONFIG_SOFTMMU
 /* helper signature: helper_ret_ld_mmu(CPUState *env, target_ulong addr,
  * int mmu_idx, uintptr_t ra)
@@ -1923,6 +1936,10 @@ static inline void tcg_out_op(TCGContext *s, TCGOpcode 
opc,
 tcg_out_udiv(s, COND_AL, args[0], args[1], args[2]);
 break;
 
+case INDEX_op_mb:
+tcg_out_mb(s, args[0]);
+break;
+
 case INDEX_op_mov_i32:  /* Always emitted via tcg_out_mov.  */
 case INDEX_op_movi_i32: /* Always emitted via tcg_out_movi.  */
 case INDEX_op_call: /* Always emitted via tcg_out_call.  */
@@ -1997,6 +2014,7 @@ static const TCGTargetOpDef arm_op_defs[] = {
 { INDEX_op_div_i32, { "r", "r", "r" } },
 { INDEX_op_divu_i32, { "r", "r", "r" } },
 
+{ INDEX_op_mb, { } },
 { -1 },
 };
 
-- 
2.9.0




[Qemu-devel] [RFC v3 PATCH 05/14] tcg/ia64: Add support for fence

2016-06-17 Thread Pranith Kumar
Cc: Aurelien Jarno 
Signed-off-by: Richard Henderson 
Signed-off-by: Pranith Kumar 
---
 tcg/ia64/tcg-target.inc.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/tcg/ia64/tcg-target.inc.c b/tcg/ia64/tcg-target.inc.c
index 395223e..7b220a7 100644
--- a/tcg/ia64/tcg-target.inc.c
+++ b/tcg/ia64/tcg-target.inc.c
@@ -247,6 +247,7 @@ enum {
 OPC_LD4_M3= 0x0a08000ull,
 OPC_LD8_M1= 0x080c000ull,
 OPC_LD8_M3= 0x0a0c000ull,
+OPC_MF_M24= 0x0011000ull,
 OPC_MUX1_I3   = 0x0eca000ull,
 OPC_NOP_B9= 0x0400800ull,
 OPC_NOP_F16   = 0x800ull,
@@ -2213,6 +2214,9 @@ static inline void tcg_out_op(TCGContext *s, TCGOpcode 
opc,
 tcg_out_qemu_st(s, args);
 break;
 
+case INDEX_op_mb:
+tcg_out_bundle(s, mmI, OPC_MF_M24, INSN_NOP_M, INSN_NOP_I);
+break;
 case INDEX_op_mov_i32:  /* Always emitted via tcg_out_mov.  */
 case INDEX_op_mov_i64:
 case INDEX_op_movi_i32: /* Always emitted via tcg_out_movi.  */
@@ -2326,6 +2330,7 @@ static const TCGTargetOpDef ia64_op_defs[] = {
 { INDEX_op_qemu_st_i32, { "SZ", "r" } },
 { INDEX_op_qemu_st_i64, { "SZ", "r" } },
 
+{ INDEX_op_mb, { } },
 { -1 },
 };
 
-- 
2.9.0




[Qemu-devel] [RFC v3 PATCH 08/14] tcg/s390: Add support for fence

2016-06-17 Thread Pranith Kumar
Cc: Alexander Graf 
Signed-off-by: Richard Henderson 
Signed-off-by: Pranith Kumar 
---
 tcg/s390/tcg-target.inc.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/tcg/s390/tcg-target.inc.c b/tcg/s390/tcg-target.inc.c
index e0a60e6..b83b65b 100644
--- a/tcg/s390/tcg-target.inc.c
+++ b/tcg/s390/tcg-target.inc.c
@@ -343,6 +343,7 @@ static tcg_insn_unit *tb_ret_addr;
 #define FACILITY_EXT_IMM   (1ULL << (63 - 21))
 #define FACILITY_GEN_INST_EXT  (1ULL << (63 - 34))
 #define FACILITY_LOAD_ON_COND   (1ULL << (63 - 45))
+#define FACILITY_FAST_BCR_SER   FACILITY_LOAD_ON_COND
 
 static uint64_t facilities;
 
@@ -2165,6 +2166,13 @@ static inline void tcg_out_op(TCGContext *s, TCGOpcode 
opc,
 tgen_deposit(s, args[0], args[2], args[3], args[4]);
 break;
 
+case INDEX_op_mb:
+/* The host memory model is quite strong, we simply need to
+   serialize the instruction stream.  */
+tcg_out_insn(s, RR, BCR,
+facilities & FACILITY_FAST_BCR_SER ? 14 : 15, 0);
+break;
+
 case INDEX_op_mov_i32:  /* Always emitted via tcg_out_mov.  */
 case INDEX_op_mov_i64:
 case INDEX_op_movi_i32: /* Always emitted via tcg_out_movi.  */
@@ -2286,6 +2294,7 @@ static const TCGTargetOpDef s390_op_defs[] = {
 { INDEX_op_movcond_i64, { "r", "r", "rC", "r", "0" } },
 { INDEX_op_deposit_i64, { "r", "0", "r" } },
 
+{ INDEX_op_mb, { } },
 { -1 },
 };
 
-- 
2.9.0




[Qemu-devel] [RFC v3 PATCH 09/14] tcg/sparc: Add support for fence

2016-06-17 Thread Pranith Kumar
Cc: Blue Swirl 
Signed-off-by: Richard Henderson 
Signed-off-by: Pranith Kumar 
---
 tcg/sparc/tcg-target.inc.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/tcg/sparc/tcg-target.inc.c b/tcg/sparc/tcg-target.inc.c
index 9938a50..af8a300 100644
--- a/tcg/sparc/tcg-target.inc.c
+++ b/tcg/sparc/tcg-target.inc.c
@@ -249,6 +249,8 @@ static const int tcg_target_call_oarg_regs[] = {
 #define STWA   (INSN_OP(3) | INSN_OP3(0x14))
 #define STXA   (INSN_OP(3) | INSN_OP3(0x1e))
 
+#define MEMBAR (INSN_OP(2) | INSN_OP3(0x28) | INSN_RS1(15) | (1 << 13))
+
 #ifndef ASI_PRIMARY_LITTLE
 #define ASI_PRIMARY_LITTLE 0x88
 #endif
@@ -825,6 +827,24 @@ static void tcg_out_call(TCGContext *s, tcg_insn_unit 
*dest)
 tcg_out_nop(s);
 }
 
+static void tcg_out_mb(TCGContext *s, TCGArg a0)
+{
+uint8_t bar_opcode;
+switch (a0 & TCG_MO_ALL) {
+case TCG_MO_LD_LD:
+bar_opcode = 0x5; 
+break;
+case TCG_MO_ST_ST:
+bar_opcode = 0xa;
+break;
+default:
+/* #StoreLoad | #LoadStore */
+bar_opcode = 0xf;
+break;
+}
+tcg_out32(s, MEMBAR | bar_opcode);
+}
+
 #ifdef CONFIG_SOFTMMU
 static tcg_insn_unit *qemu_ld_trampoline[16];
 static tcg_insn_unit *qemu_st_trampoline[16];
@@ -1450,6 +1470,10 @@ static void tcg_out_op(TCGContext *s, TCGOpcode opc,
tcg_out_arithc(s, a0, TCG_REG_G0, a1, const_args[1], c);
break;
 
+case INDEX_op_mb:
+tcg_out_mb(s, a0);
+break;
+
 case INDEX_op_mov_i32:  /* Always emitted via tcg_out_mov.  */
 case INDEX_op_mov_i64:
 case INDEX_op_movi_i32: /* Always emitted via tcg_out_movi.  */
@@ -1551,6 +1575,7 @@ static const TCGTargetOpDef sparc_op_defs[] = {
 { INDEX_op_qemu_st_i32, { "sZ", "A" } },
 { INDEX_op_qemu_st_i64, { "SZ", "A" } },
 
+{ INDEX_op_mb, { } },
 { -1 },
 };
 
-- 
2.9.0




[Qemu-devel] [RFC v3 PATCH 07/14] tcg/ppc: Add support for fence

2016-06-17 Thread Pranith Kumar
Signed-off-by: Richard Henderson 
Signed-off-by: Pranith Kumar 
---
 tcg/ppc/tcg-target.inc.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/tcg/ppc/tcg-target.inc.c b/tcg/ppc/tcg-target.inc.c
index da10052..766848e 100644
--- a/tcg/ppc/tcg-target.inc.c
+++ b/tcg/ppc/tcg-target.inc.c
@@ -469,6 +469,10 @@ static int tcg_target_const_match(tcg_target_long val, 
TCGType type,
 #define STHX   XO31(407)
 #define STWX   XO31(151)
 
+#define EIEIO  XO31(854)
+#define HWSYNC XO31(598)
+#define LWSYNC (HWSYNC | (1u << 21))
+
 #define SPR(a, b) a)<<5)|(b))<<11)
 #define LR SPR(8, 0)
 #define CTRSPR(9, 0)
@@ -1237,6 +1241,21 @@ static void tcg_out_brcond2 (TCGContext *s, const TCGArg 
*args,
 tcg_out_bc(s, BC | BI(7, CR_EQ) | BO_COND_TRUE, arg_label(args[5]));
 }
 
+static void tcg_out_mb(TCGContext *s, TCGArg a0)
+{
+switch (a0 & TCG_MO_ALL) {
+case TCG_MO_LD_LD:
+tcg_out32(s, LWSYNC);
+break;
+case TCG_MO_ST_ST:
+tcg_out32(s, EIEIO);
+break;
+default:
+tcg_out32(s, HWSYNC);
+break;
+}
+}
+
 #ifdef __powerpc64__
 void ppc_tb_set_jmp_target(uintptr_t jmp_addr, uintptr_t addr)
 {
@@ -2439,6 +2458,10 @@ static void tcg_out_op(TCGContext *s, TCGOpcode opc, 
const TCGArg *args,
 tcg_out32(s, MULHD | TAB(args[0], args[1], args[2]));
 break;
 
+case INDEX_op_mb:
+tcg_out_mb(s, args[0]);
+break;
+
 case INDEX_op_mov_i32:   /* Always emitted via tcg_out_mov.  */
 case INDEX_op_mov_i64:
 case INDEX_op_movi_i32:  /* Always emitted via tcg_out_movi.  */
@@ -2586,6 +2609,7 @@ static const TCGTargetOpDef ppc_op_defs[] = {
 { INDEX_op_qemu_st_i64, { "S", "S", "S", "S" } },
 #endif
 
+{ INDEX_op_mb, { } },
 { -1 },
 };
 
-- 
2.9.0




[Qemu-devel] [RFC v3 PATCH 06/14] tcg/mips: Add support for fence

2016-06-17 Thread Pranith Kumar
Signed-off-by: Richard Henderson 
Signed-off-by: Pranith Kumar 
---
 tcg/mips/tcg-target.inc.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/tcg/mips/tcg-target.inc.c b/tcg/mips/tcg-target.inc.c
index 50e98ea..fb6cb3e 100644
--- a/tcg/mips/tcg-target.inc.c
+++ b/tcg/mips/tcg-target.inc.c
@@ -292,6 +292,7 @@ typedef enum {
 OPC_JALR = OPC_SPECIAL | 0x09,
 OPC_MOVZ = OPC_SPECIAL | 0x0A,
 OPC_MOVN = OPC_SPECIAL | 0x0B,
+OPC_SYNC = OPC_SPECIAL | 0x0F,
 OPC_MFHI = OPC_SPECIAL | 0x10,
 OPC_MFLO = OPC_SPECIAL | 0x12,
 OPC_MULT = OPC_SPECIAL | 0x18,
@@ -1636,6 +1637,9 @@ static inline void tcg_out_op(TCGContext *s, TCGOpcode 
opc,
 const_args[4], const_args[5], true);
 break;
 
+case INDEX_op_mb:
+tcg_out32(s, OPC_SYNC);
+break;
 case INDEX_op_mov_i32:  /* Always emitted via tcg_out_mov.  */
 case INDEX_op_movi_i32: /* Always emitted via tcg_out_movi.  */
 case INDEX_op_call: /* Always emitted via tcg_out_call.  */
@@ -1716,6 +1720,8 @@ static const TCGTargetOpDef mips_op_defs[] = {
 { INDEX_op_qemu_ld_i64, { "L", "L", "lZ", "lZ" } },
 { INDEX_op_qemu_st_i64, { "SZ", "SZ", "SZ", "SZ" } },
 #endif
+
+{ INDEX_op_mb, { } },
 { -1 },
 };
 
-- 
2.9.0




[Qemu-devel] [RFC v3 PATCH 02/14] tcg/i386: Add support for fence

2016-06-17 Thread Pranith Kumar
Generate mfence/sfence/lfence instruction on SSE2 enabled
processors. For older processors, generate a 'lock orl $0,0(%esp)'
instruction which has full ordering semantics.

Signed-off-by: Pranith Kumar 
[rth: Check for sse2, fallback to locked memory op otherwise.]
Signed-off-by: Richard Henderson 
---
 tcg/i386/tcg-target.inc.c | 47 +++
 1 file changed, 47 insertions(+)

diff --git a/tcg/i386/tcg-target.inc.c b/tcg/i386/tcg-target.inc.c
index 317484c..0748652 100644
--- a/tcg/i386/tcg-target.inc.c
+++ b/tcg/i386/tcg-target.inc.c
@@ -121,6 +121,16 @@ static bool have_cmov;
 # define have_cmov 0
 #endif
 
+/* For 32-bit, we are going to attempt to determine at runtime whether
+   sse2 support is available.  */
+#if TCG_TARGET_REG_BITS == 64 || defined(__SSE2__)
+# define have_sse2 1
+#elif defined(CONFIG_CPUID_H) && defined(bit_SSE2)
+static bool have_sse2;
+#else
+# define have_sse2 0
+#endif
+
 /* If bit_MOVBE is defined in cpuid.h (added in GCC version 4.6), we are
going to attempt to determine at runtime whether movbe is available.  */
 #if defined(CONFIG_CPUID_H) && defined(bit_MOVBE)
@@ -686,6 +696,32 @@ static inline void tcg_out_pushi(TCGContext *s, 
tcg_target_long val)
 }
 }
 
+static inline void tcg_out_mb(TCGContext *s, TCGArg a0)
+{
+if (have_sse2) {
+tcg_out16(s, 0xae0f);
+switch (a0 & TCG_MO_ALL) {
+case TCG_MO_LD_LD:
+/* lfence */
+tcg_out8(s, 0xe8);
+break;
+case TCG_MO_ST_ST:
+/* sfence */
+tcg_out8(s, 0xf8);
+break;
+default:
+/* mfence */
+tcg_out8(s, 0xf0);
+break;
+}
+} else {
+/* lock orl $0,0(%esp) */
+tcg_out8(s, 0xf0);
+tcg_out_modrm_offset(s, OPC_ARITH_EvIb, ARITH_OR, TCG_REG_ESP, 0);
+tcg_out8(s, 0);
+}
+}
+
 static inline void tcg_out_push(TCGContext *s, int reg)
 {
 tcg_out_opc(s, OPC_PUSH_r32 + LOWREGMASK(reg), 0, reg, 0);
@@ -2120,6 +2156,10 @@ static inline void tcg_out_op(TCGContext *s, TCGOpcode 
opc,
 }
 break;
 
+case INDEX_op_mb:
+assert(args[0] != 0);
+tcg_out_mb(s, args[0]);
+break;
 case INDEX_op_mov_i32:  /* Always emitted via tcg_out_mov.  */
 case INDEX_op_mov_i64:
 case INDEX_op_movi_i32: /* Always emitted via tcg_out_movi.  */
@@ -2185,6 +2225,8 @@ static const TCGTargetOpDef x86_op_defs[] = {
 { INDEX_op_add2_i32, { "r", "r", "0", "1", "ri", "ri" } },
 { INDEX_op_sub2_i32, { "r", "r", "0", "1", "ri", "ri" } },
 
+{ INDEX_op_mb, { } },
+
 #if TCG_TARGET_REG_BITS == 32
 { INDEX_op_brcond2_i32, { "r", "r", "ri", "ri" } },
 { INDEX_op_setcond2_i32, { "r", "r", "r", "ri", "ri" } },
@@ -2362,6 +2404,11 @@ static void tcg_target_init(TCGContext *s)
available, we'll use a small forward branch.  */
 have_cmov = (d & bit_CMOV) != 0;
 #endif
+#ifndef have_sse2
+/* Likewise, almost all hardware supports SSE2, but we do
+   have a locked memory operation to use as a substitute.  */
+have_sse2 = (d & bit_SSE2) != 0;
+#endif
 #ifndef have_movbe
 /* MOVBE is only available on Intel Atom and Haswell CPUs, so we
need to probe for it.  */
-- 
2.9.0




[Qemu-devel] [RFC v3 PATCH 01/14] Introduce TCGOpcode for memory barrier

2016-06-17 Thread Pranith Kumar
This commit introduces the TCGOpcode for memory barrier instruction.

This opcode takes an argument which is the type of memory barrier
which should be generated.

Signed-off-by: Pranith Kumar 
Signed-off-by: Richard Henderson 
---
 tcg/README| 17 +
 tcg/tcg-op.c  | 11 +++
 tcg/tcg-op.h  |  2 ++
 tcg/tcg-opc.h |  2 ++
 tcg/tcg.h | 14 ++
 5 files changed, 46 insertions(+)

diff --git a/tcg/README b/tcg/README
index ce8beba..1d48aa9 100644
--- a/tcg/README
+++ b/tcg/README
@@ -402,6 +402,23 @@ double-word product T0.  The later is returned in two 
single-word outputs.
 
 Similar to mulu2, except the two inputs T1 and T2 are signed.
 
+* Memory Barrier support
+
+* mb <$arg>
+
+Generate a target memory barrier instruction to ensure memory ordering as being
+enforced by a corresponding guest memory barrier instruction. The ordering
+enforced by the backend may be stricter than the ordering required by the 
guest.
+It cannot be weaker. This opcode takes a constant argument which is required to
+generate the appropriate barrier instruction. The backend should take care to
+emit the target barrier instruction only when necessary i.e., for SMP guests 
and
+when MTTCG is enabled.
+
+The guest translators should generate this opcode for all guest instructions
+which have ordering side effects.
+
+Please see docs/atomics.txt for more information on memory barriers.
+
 * 64-bit guest on 32-bit host support
 
 The following opcodes are internal to TCG.  Thus they are to be implemented by
diff --git a/tcg/tcg-op.c b/tcg/tcg-op.c
index 54c0277..08f7858 100644
--- a/tcg/tcg-op.c
+++ b/tcg/tcg-op.c
@@ -39,6 +39,8 @@ extern TCGv_i32 TCGV_HIGH_link_error(TCGv_i64);
 #define TCGV_HIGH TCGV_HIGH_link_error
 #endif
 
+extern int smp_cpus;
+
 /* Note that this is optimized for sequential allocation during translate.
Up to and including filling in the forward link immediately.  We'll do
proper termination of the end of the list after we finish translation.  */
@@ -146,6 +148,15 @@ void tcg_gen_op6(TCGContext *ctx, TCGOpcode opc, TCGArg 
a1, TCGArg a2,
 tcg_emit_op(ctx, opc, pi);
 }
 
+void tcg_gen_mb(TCGArg mb_type)
+{
+#ifndef CONFIG_USER_ONLY
+if (qemu_tcg_mttcg_enabled() && smp_cpus > 1) {
+tcg_gen_op1(_ctx, INDEX_op_mb, mb_type);
+}
+#endif
+}
+
 /* 32 bit ops */
 
 void tcg_gen_addi_i32(TCGv_i32 ret, TCGv_i32 arg1, int32_t arg2)
diff --git a/tcg/tcg-op.h b/tcg/tcg-op.h
index f217e80..41890cc 100644
--- a/tcg/tcg-op.h
+++ b/tcg/tcg-op.h
@@ -261,6 +261,8 @@ static inline void tcg_gen_br(TCGLabel *l)
 tcg_gen_op1(_ctx, INDEX_op_br, label_arg(l));
 }
 
+void tcg_gen_mb(TCGArg a);
+
 /* Helper calls. */
 
 /* 32 bit ops */
diff --git a/tcg/tcg-opc.h b/tcg/tcg-opc.h
index 6d0410c..45528d2 100644
--- a/tcg/tcg-opc.h
+++ b/tcg/tcg-opc.h
@@ -42,6 +42,8 @@ DEF(br, 0, 0, 1, TCG_OPF_BB_END)
 # define IMPL64  TCG_OPF_64BIT
 #endif
 
+DEF(mb, 0, 0, 1, 0)
+
 DEF(mov_i32, 1, 1, 0, TCG_OPF_NOT_PRESENT)
 DEF(movi_i32, 1, 0, 1, TCG_OPF_NOT_PRESENT)
 DEF(setcond_i32, 1, 2, 1, 0)
diff --git a/tcg/tcg.h b/tcg/tcg.h
index db6a062..36feca9 100644
--- a/tcg/tcg.h
+++ b/tcg/tcg.h
@@ -408,6 +408,20 @@ static inline intptr_t QEMU_ARTIFICIAL 
GET_TCGV_PTR(TCGv_ptr t)
 #define TCG_CALL_DUMMY_TCGV MAKE_TCGV_I32(-1)
 #define TCG_CALL_DUMMY_ARG  ((TCGArg)(-1))
 
+typedef enum {
+TCG_MO_LD_LD= 1,
+TCG_MO_ST_LD= 2,
+TCG_MO_LD_ST= 4,
+TCG_MO_ST_ST= 8,
+TCG_MO_ALL  = 0xF, // OR of all above
+} TCGOrder;
+
+typedef enum {
+TCG_BAR_ACQ = 32,
+TCG_BAR_REL = 64,
+TCG_BAR_SC  = 128,
+} TCGBar;
+
 /* Conditions.  Note that these are laid out for easy manipulation by
the functions below:
  bit 0 is used for inverting;
-- 
2.9.0




Re: [Qemu-devel] [PULL 03/13] target-ppc: Use 32-bit rotate instead of deposit + 64-bit rotate

2016-06-17 Thread Anton Blanchard
Hi,

> > > Bother.  I've tentatively put a revert into ppc-for-2.7.  Richard,
> > > do you have a better idea how to fix it?
> > 
> > Please try the following.  
> 
> Thanks! This passes my tests. Feel free to add:
> 
> Tested-by: Anton Blanchard 

Actually I think I've found a problem:

lis r4,0x7fff@h
ori r4,r4,0x7fff@l
rlwinm  r3,r4,0,25,1

32 bit rotate is defined as a 64 bit rotate of 2 copies of the 32 bit
value, so we expect 0x7fff407f, but get 0x407f.

Not sure if anything out there depends on it though.

Anton




[Qemu-devel] [Bug 1593605] Re: windows2008r2 boot failed with uefi

2016-06-17 Thread Richard Zhang
When I change qemu version from 2.1.2 to 2.6.0. The vcpu0 will return 0 qemu.
I got strace like this:
strace -p 1180
Process 1180 attached - interrupt to quit
rt_sigtimedwait([BUS USR1], 0x7f719b5fa960, {0, 0}, 8) = -1 EAGAIN (Resource 
temporarily unavailable)
rt_sigpending([])   = 0
futex(0x55669f356d60, FUTEX_WAKE_PRIVATE, 1) = 1
ioctl(26, KVM_RUN

The kvm tracing like this:
 kvm-1180  [018] d... 63148.545821: kvm_entry: vcpu 0
 kvm-1180  [018] d... 63148.545944: kvm_exit: reason 
EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 80fd
 kvm-1180  [018] d... 63148.545948: kvm_entry: vcpu 0
 kvm-1180  [018] d... 63148.546083: kvm_exit: reason 
EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 80fd
 kvm-1180  [018] d... 63148.546085: kvm_entry: vcpu 0
 kvm-1180  [018] d... 63148.546200: kvm_exit: reason 
EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 80fd
 kvm-1180  [018] d... 63148.546202: kvm_entry: vcpu 0
 kvm-1180  [018] d... 63148.546317: kvm_exit: reason 
EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 80fd
 kvm-1180  [018] d... 63148.546320: kvm_entry: vcpu 0
 kvm-1180  [018] d... 63148.546436: kvm_exit: reason 
EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 80fd
 kvm-1180  [018] d... 63148.546439: kvm_entry: vcpu 0
 kvm-1180  [018] d... 63148.546553: kvm_exit: reason 
EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 80fd
 kvm-1180  [018] d... 63148.546556: kvm_entry: vcpu 0
 kvm-1180  [018] d... 63148.546689: kvm_exit: reason 
EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 80fd
 kvm-1180  [018] d... 63148.546691: kvm_entry: vcpu 0
 kvm-1180  [018] d... 63148.546807: kvm_exit: reason 
EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 80fd
 kvm-1180  [018] d... 63148.546810: kvm_entry: vcpu 0
 kvm-1180  [018] d... 63148.546927: kvm_exit: reason 
EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 80fd
 kvm-1180  [018] d... 63148.546930: kvm_entry: vcpu 0
 kvm-1180  [018] d... 63148.547067: kvm_exit: reason 
EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 80fd
 kvm-1180  [018] d... 63148.547070: kvm_entry: vcpu 0
 kvm-1180  [018] d... 63148.547186: kvm_exit: reason 
EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 80fd
 kvm-1180  [018] d... 63148.547189: kvm_entry: vcpu 0
 kvm-1180  [018] d... 63148.547304: kvm_exit: reason 
EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 80fd
 kvm-1180  [018] d... 63148.547307: kvm_entry: vcpu 0
 kvm-1180  [018] d... 63148.547384: kvm_exit: reason 
EXTERNAL_INTERRUPT rip 0xbf68f16f info 0 80ef
 kvm-1180  [018] d... 63148.547391: kvm_entry: vcpu 0

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

Title:
  windows2008r2 boot failed with uefi

Status in QEMU:
  Incomplete

Bug description:
  I want to run my win2008r2 with uefi. Hypervisor is ubuntu16.04 and my
  qemu command line show below:

  qemu-system-x86_64 -enable-kvm -name win2008r2 -S -machine pc-
  i440fx-2.5,accel=kvm,usb=off -cpu
  host,hv_time,hv_relaxed,hv_spinlocks=0x2000 -drive
  file=/usr/share/qemu/OVMF.fd,if=pflash,format=raw,unit=0,readonly=on
  -drive
  file=/var/lib/libvirt/qemu/nvram/win2008r2_VARS.fd,if=pflash,format=raw,unit=1
  -m size=8388608k,slots=10,maxmem=1073741824k -realtime mlock=off -smp
  8,maxcpus=96,sockets=24,cores=4,threads=1 -numa
  node,nodeid=0,cpus=0-7,mem=8192 -uuid 030638c5-c6aa-
  4f06-82f8-dd2d04fd5705 -no-user-config -nodefaults -chardev
  socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-
  win2008r2/monitor.sock,server,nowait -mon
  chardev=charmonitor,id=monitor,mode=control -rtc
  base=localtime,clock=vm,driftfix=slew -no-hpet -no-shutdown -boot
  strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device
  usb-ehci,id=usb1,bus=pci.0,addr=0x4 -device nec-usb-
  xhci,id=usb2,bus=pci.0,addr=0x5 -device
  lsi,id=scsi0,bus=pci.0,addr=0x6 -device virtio-scsi-
  pci,id=scsi1,bus=pci.0,addr=0x7 -device virtio-serial-pci,id=virtio-
  serial0,bus=pci.0,addr=0x8 -drive
  file=/vms/images/win2008r2,format=qcow2,if=none,id=drive-
  ide0-0-0,cache=directsync -device ide-hd,bus=ide.0,unit=0,drive=drive-
  ide0-0-0,id=ide0-0-0,bootindex=1 -drive
  
file=/vms/isos/cn_windows_server_2008_r2_standard_enterprise_datacenter_and_web_with_sp1_x64_dvd_617598.iso,format=raw,if=none,id
  =drive-ide0-1-1,readonly=on -device ide-cd,bus=ide.1,unit=1,drive
  =drive-ide0-1-1,id=ide0-1-1,bootindex=2 -chardev pty,id=charserial0
  -device isa-serial,chardev=charserial0,id=serial0 -chardev
  
socket,id=charchannel0,path=/var/lib/libvirt/qemu/win2008r2.agent,server,nowait
  -device virtserialport,bus=virtio-
  serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0

[Qemu-devel] [Bug 1593605] Re: windows2008r2 boot failed with uefi

2016-06-17 Thread Richard Zhang
Thanks for your advice. I got newer version of OVMF from 
https://www.kraxel.org/repos/. And compile from source 
code(git://github.com/tianocore/edk2.git). 
With these OVMF, it really works well on only 1 vcpu domain. But still failed 
with multi-vcpus. 
The vcpu0 runnig in an endless loop, and other vcpus is halted. The stack of 
vcpu0 show below:
#0  0x5571f4b10959 in address_space_update_topology_pass 
(as=0x5571f6b76de8, old_view=0x7f6884020690, new_view=0x7f6884022ab0, 
adding=true)
at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/memory.c:753
#1  0x5571f4b10a18 in address_space_update_topology (as=0x5571f6b76de8) at 
/vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/memory.c:768
#2  0x5571f4b10bba in memory_region_transaction_commit () at 
/vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/memory.c:809
#3  0x5571f4b13d8b in memory_region_update_container_subregions 
(subregion=0x5571f6cc5140)
at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/memory.c:1658
#4  0x5571f4b13e14 in memory_region_add_subregion_common 
(mr=0x5571f6a22530, offset=655360, subregion=0x5571f6cc5140)
at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/memory.c:1668
#5  0x5571f4b13ee8 in memory_region_add_subregion_overlap 
(mr=0x5571f6a22530, offset=655360, subregion=0x5571f6cc5140, priority=2)
at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/memory.c:1687
#6  0x5571f4b2c27a in vga_update_memory_access (s=0x5571f6cc4f38) at 
/vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/hw/display/vga.c:210
#7  0x5571f4b2cddb in vga_ioport_write (opaque=0x5571f6cc4f38, addr=975, 
val=8)
at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/hw/display/vga.c:538
#8  0x5571f4cf7072 in qxl_vga_ioport_write (opaque=0x5571f6cc4f38, 
addr=975, val=8) at hw/display/qxl.c:1197
#9  0x5571f4b03316 in portio_write (opaque=0x5571f6c72890, addr=14, 
data=2056, size=2)
at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/ioport.c:201
#10 0x5571f4b0ea9c in memory_region_write_accessor (mr=0x5571f6c72890, 
addr=14, value=0x7f688b73ab28, size=2, shift=0, mask=65535)
at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/memory.c:444
#11 0x5571f4b0ebe4 in access_with_adjusted_size (addr=14, 
value=0x7f688b73ab28, size=2, access_size_min=1, access_size_max=4, 
access=0x5571f4b0ea00 , mr=0x5571f6c72890) at 
/vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/memory.c:481
#12 0x5571f4b11b28 in memory_region_dispatch_write (mr=0x5571f6c72890, 
addr=14, data=2056, size=2)
at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/memory.c:1138
#13 0x5571f4b152ce in io_mem_write (mr=0x5571f6c72890, addr=14, val=2056, 
size=2) at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/memory.c:1971
#14 0x5571f4abd56b in address_space_rw (as=0x5571f5333b80, addr=974, 
buf=0x7f689a39 "\b", , len=2, is_write=true)
at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/exec.c:2123
#15 0x5571f4b0b028 in kvm_handle_io (port=974, data=0x7f689a39, 
direction=1, size=2, count=1)
at /vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/kvm-all.c:1616
#16 0x5571f4b0b5d1 in kvm_cpu_exec (cpu=0x5571f6a5d5e0) at 
/vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/kvm-all.c:1758
#17 0x5571f4af0bf0 in qemu_kvm_cpu_thread_fn (arg=0x5571f6a5d5e0) at 
/vms/V1R3B01D001_newFeature/daemon/qemu/qemu-2.1.2/cpus.c:898
#18 0x7f6899c18e9a in start_thread () from 
/lib/x86_64-linux-gnu/libpthread.so.0
#19 0x7f68963f938d in clone () from /lib/x86_64-linux-gnu/libc.so.6
#20 0x in ?? ()


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

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

Title:
  windows2008r2 boot failed with uefi

Status in QEMU:
  Incomplete

Bug description:
  I want to run my win2008r2 with uefi. Hypervisor is ubuntu16.04 and my
  qemu command line show below:

  qemu-system-x86_64 -enable-kvm -name win2008r2 -S -machine pc-
  i440fx-2.5,accel=kvm,usb=off -cpu
  host,hv_time,hv_relaxed,hv_spinlocks=0x2000 -drive
  file=/usr/share/qemu/OVMF.fd,if=pflash,format=raw,unit=0,readonly=on
  -drive
  file=/var/lib/libvirt/qemu/nvram/win2008r2_VARS.fd,if=pflash,format=raw,unit=1
  -m size=8388608k,slots=10,maxmem=1073741824k -realtime mlock=off -smp
  8,maxcpus=96,sockets=24,cores=4,threads=1 -numa
  node,nodeid=0,cpus=0-7,mem=8192 -uuid 030638c5-c6aa-
  4f06-82f8-dd2d04fd5705 -no-user-config -nodefaults -chardev
  socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-
  win2008r2/monitor.sock,server,nowait -mon
  chardev=charmonitor,id=monitor,mode=control -rtc
  base=localtime,clock=vm,driftfix=slew -no-hpet -no-shutdown -boot
  strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device
  usb-ehci,id=usb1,bus=pci.0,addr=0x4 -device nec-usb-
  xhci,id=usb2,bus=pci.0,addr=0x5 -device
  

[Qemu-devel] [Bug 1593605] Re: windows2008r2 boot failed with uefi

2016-06-17 Thread Laszlo Ersek (Red Hat)
The OVMF build you use (SVN r15214) is from Feb 2014 -- it is completely
obsolete. I suggest you use the packages from
https://www.kraxel.org/repos/ .

I'm marking this as "invalid" because supporting 2+ year old OVMF builds
is unthinkable.

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

Title:
  windows2008r2 boot failed with uefi

Status in QEMU:
  Invalid

Bug description:
  I want to run my win2008r2 with uefi. Hypervisor is ubuntu16.04 and my
  qemu command line show below:

  qemu-system-x86_64 -enable-kvm -name win2008r2 -S -machine pc-
  i440fx-2.5,accel=kvm,usb=off -cpu
  host,hv_time,hv_relaxed,hv_spinlocks=0x2000 -drive
  file=/usr/share/qemu/OVMF.fd,if=pflash,format=raw,unit=0,readonly=on
  -drive
  file=/var/lib/libvirt/qemu/nvram/win2008r2_VARS.fd,if=pflash,format=raw,unit=1
  -m size=8388608k,slots=10,maxmem=1073741824k -realtime mlock=off -smp
  8,maxcpus=96,sockets=24,cores=4,threads=1 -numa
  node,nodeid=0,cpus=0-7,mem=8192 -uuid 030638c5-c6aa-
  4f06-82f8-dd2d04fd5705 -no-user-config -nodefaults -chardev
  socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-
  win2008r2/monitor.sock,server,nowait -mon
  chardev=charmonitor,id=monitor,mode=control -rtc
  base=localtime,clock=vm,driftfix=slew -no-hpet -no-shutdown -boot
  strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device
  usb-ehci,id=usb1,bus=pci.0,addr=0x4 -device nec-usb-
  xhci,id=usb2,bus=pci.0,addr=0x5 -device
  lsi,id=scsi0,bus=pci.0,addr=0x6 -device virtio-scsi-
  pci,id=scsi1,bus=pci.0,addr=0x7 -device virtio-serial-pci,id=virtio-
  serial0,bus=pci.0,addr=0x8 -drive
  file=/vms/images/win2008r2,format=qcow2,if=none,id=drive-
  ide0-0-0,cache=directsync -device ide-hd,bus=ide.0,unit=0,drive=drive-
  ide0-0-0,id=ide0-0-0,bootindex=1 -drive
  
file=/vms/isos/cn_windows_server_2008_r2_standard_enterprise_datacenter_and_web_with_sp1_x64_dvd_617598.iso,format=raw,if=none,id
  =drive-ide0-1-1,readonly=on -device ide-cd,bus=ide.1,unit=1,drive
  =drive-ide0-1-1,id=ide0-1-1,bootindex=2 -chardev pty,id=charserial0
  -device isa-serial,chardev=charserial0,id=serial0 -chardev
  
socket,id=charchannel0,path=/var/lib/libvirt/qemu/win2008r2.agent,server,nowait
  -device virtserialport,bus=virtio-
  serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0
  -device usb-tablet,id=input0 -vnc 0.0.0.0:0 -device
  VGA,id=video0,vgamem_mb=16,bus=pci.0,addr=0x2 -device virtio-balloon-
  pci,id=balloon0,bus=pci.0,addr=0xa -msg timestamp=on

  
  OVMF.fd is download from http://sourceforge.net/projects/edk2/files/OVMF/ 
OVMF-X64-r15214.zip.

  When I boot my domain with windows2008 iso, the kvm was caught in
  endless interrupt. I enable trace on my host and I got this.


  1. echo 1 > /sys/kernel/debug/tracing/events/kvm/enable
  2. cat /sys/kernel/debug/tracing/trace_pipe 
  qemu-system-x86-1969  [006]   2093.019588: kvm_exit: reason 
EXTERNAL_INTERRUPT rip 0xf8001080ae8e info 0 80fd
   qemu-system-x86-1969  [006] d...  2093.019590: kvm_entry: vcpu 0
   qemu-system-x86-1966  [017]   2093.021424: kvm_set_irq: gsi 8 level 1 
source 0
   qemu-system-x86-1966  [017]   2093.021429: kvm_pic_set_irq: chip 1 pin 0 
(edge|masked)
   qemu-system-x86-1966  [017]   2093.021430: kvm_ioapic_set_irq: pin 8 dst 
1 vec=209 (Fixed|logical|edge) (coalesced)
   qemu-system-x86-1969  [006]   2093.021683: kvm_exit: reason 
EXTERNAL_INTERRUPT rip 0xf8001080ae78 info 0 80fd
   qemu-system-x86-1969  [006] d...  2093.021686: kvm_entry: vcpu 0
   qemu-system-x86-1969  [006]   2093.022592: kvm_exit: reason 
EXTERNAL_INTERRUPT rip 0xf8001080ae8e info 0 80ef
   qemu-system-x86-1969  [006] d...  2093.022595: kvm_entry: vcpu 0
   qemu-system-x86-1969  [006]   2093.022746: kvm_exit: reason 
EXTERNAL_INTERRUPT rip 0xf8001080ae8e info 0 80fd
   qemu-system-x86-1969  [006] d...  2093.022749: kvm_entry: vcpu 0
   qemu-system-x86-1966  [017]   2093.023434: kvm_set_irq: gsi 8 level 1 
source 0
   qemu-system-x86-1966  [017]   2093.023444: kvm_pic_set_irq: chip 1 pin 0 
(edge|masked)
   qemu-system-x86-1966  [017]   2093.023446: kvm_ioapic_set_irq: pin 8 dst 
1 vec=209 (Fixed|logical|edge) (coalesced)
   qemu-system-x86-1969  [006]   2093.023610: kvm_exit: reason 
EXTERNAL_INTERRUPT rip 0xf8001080ae78 info 0 80fd
   qemu-system-x86-1969  [006] d...  2093.023612: kvm_entry: vcpu 0
   qemu-system-x86-1966  [017]   2093.025430: kvm_set_irq: gsi 8 level 1 
source 0
   qemu-system-x86-1966  [017]   2093.025435: kvm_pic_set_irq: chip 1 pin 0 
(edge|masked)
   qemu-system-x86-1966  [017]   2093.025436: kvm_ioapic_set_irq: pin 8 dst 
1 vec=209 (Fixed|logical|edge) (coalesced)
   qemu-system-x86-1969  [006]   2093.025599: kvm_exit: reason 
EXTERNAL_INTERRUPT rip 0xf8001080ae78 info 0 80fd
   

[Qemu-devel] [PATCH] target-ppc: Correct ppc3500_spin initial TLB size

2016-06-17 Thread alarson
When e500 PPC is booted multi-core, the non-boot cores are started via
the spin table.  ppce500_spin.c:spin_kick() calls
mmubooke_create_initial_mapping() to allocate a 64MB TLB entry, but
the created TLB entry is only 256KB.

The root cause is that the function computing the size of the TLB
entry, namely booke206_page_size_to_tlb assumes MAS1.TSIZE as defined
by latter PPC cores, specifically (n**4)KB. The result is then used by
mmubooke_create_initial_mapping using MAS1_TSIZE_SHIFT, but
MAS1_TSIZE_SHIFT is defined assuming TLB entries are (n**2)KB. I.e., a
difference of shift=7 or shift=8.

Simply changing MAS1_TSIZE_SHIFT from 7 to 8 is not appropriate since
the macro is used elsewhere.

Signed-off-by: Aaron Larson 
---
 hw/ppc/ppce500_spin.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/hw/ppc/ppce500_spin.c b/hw/ppc/ppce500_spin.c
index 76bd78b..7e38f0c 100644
--- a/hw/ppc/ppce500_spin.c
+++ b/hw/ppc/ppce500_spin.c
@@ -75,7 +75,11 @@ static void spin_reset(void *opaque)
 /* Create -kernel TLB entries for BookE, linearly spanning 256MB.  */
 static inline hwaddr booke206_page_size_to_tlb(uint64_t size)
 {
-return ctz32(size >> 10) >> 1;
+/* The EREF indicates that TLB pages are (4 to the power of 2)KB, which
+ * corresponds to MAS1_TSIZE_SHIFT=8, but to support legacy processors that
+ * assume TLB pages are (2 to the power of 2)KB MAS1_TSIZE_SHIFT is
+ * currently 7. */
+return ctz32(size >> 10) >> (MAS1_TSIZE_SHIFT - 7);
 }
 
 static void mmubooke_create_initial_mapping(CPUPPCState *env,
-- 
2.7.4




[Qemu-devel] [Bug 1529226] Re: qemu-i386-user on 32-bit Linux: uncaught target signal 11

2016-06-17 Thread PeteVine
My recollection is fuzzy but it would probably amount to something like
this on any platform currently:

- download rust-1.10 beta source https://static.rust-lang.org/dist
/rustc-beta-src.tar.gz

- download this stage0 snapshot
https://www.dropbox.com/s/01ywl9mwwo6xojw/rust-stage0-2016-04-18-b324fa7
-linux-armv7.tar.xz?dl=0

- unpack the stage0 rustc binary to ~/somewhere/bin, renaming it to
rustc.bin, and create a wrapper script named rustc in that directory
containing:

`/usr/bin/qemu-arm ~/somewhere/rustc.bin "$@"`

In the rustc source directory, start the rust bootstrap process (with LLVM 3.7 
or higher installed) issuing the following command:
`./configure --enable-optimize --enable-local-rust 
--local-rust-root=~/somewhere --llvm-root=/usr`

Followed by `make`.

At the time of the original report, QEMU wasn't able to complete all
crates' build commands naturally. (the stamp file had to be created
manually to continue)

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

Title:
  qemu-i386-user on 32-bit Linux: uncaught target signal 11

Status in QEMU:
  New

Bug description:
  Even though the command I'm trying to run (a wrapper script for
  qemu-i386-user running rustc, the rust compiler)  produces the
  expected  compiled output, the build process is interrupted:

  qemu: uncaught target signal 11 (Segmentation fault) - core dumped
  i686-unknown-linux-gnu/stage0/bin/rustc: line 1:  7474 Segmentation fault 
 /usr/local/bin/qemu-i386 -cpu qemu32 /home/petevine/stage0/rustc.bin -C 
target-cpu=pentium2 -L 
/home/petevine/unpacked/rust-master/i686-unknown-linux-gnu/stage0/lib/rustlib/i686-unknown-linux-gnu/lib/
 "$@"
  make: *** 
[i686-unknown-linux-gnu/stage0/lib/rustlib/i686-unknown-linux-gnu/lib/stamp.rustc_back]
 Error 139

  The stamp file is not being created so this could be about forking
  bash after finishing the wrapper script.

  Qemu was compiled from the latest git source.

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



[Qemu-devel] [PATCH] target-ppc: Correct ppc3500_spin initial TLB size

2016-06-17 Thread alarson



[Qemu-devel] [PATCH] target-ppc: Correct ppc3500_spin initial TLB size

2016-06-17 Thread alarson



[Qemu-devel] PPC e500spin pir improperly initialized

2016-06-17 Thread alarson
Note change of subject from "Determining interest in PPC e500spin,
yield".

Thomas Huth  wrote on 06/16/2016 01:47:05 AM:
Aaron Larson  wrote on 15.06.2016 22:12

in ppce500_spin.c

AL> @@ -104,6 +108,16 @@
AL> 
AL>  cpu_synchronize_state(cpu);
AL>  stl_p(>pir, env->spr[SPR_PIR]);
AL> +/* The stl_p() above seems wrong to me.  First of all, it seems more 
appropriate
AL> + * in a guest ROM/BOOT code than in qemu emulation.  However, SPR_PIR 
is never
AL> + * initialized, so the effect of the stl_p() is to overwrite the 
curspin->pir
AL> + * with 0. It makes more sense to load the SPR_PIR with the 
curspin->pir, which
AL> + * is what the following does.
AL> + *env->spr[SPR_PIR]=ldl_p(>pir);
AL> + * Alternately SPR_PIR could be initialized from SPR_BOOKE_PIR which 
is properly
AL> + * initialized, so this could also work:
AL> + *env->spr[SPR_PIR] = env->spr[SPR_BOOKE_PIR]
AL> +*/
AL>  env->nip = ldq_p(>addr) & (map_size - 1);
AL>  env->gpr[3] = ldq_p(>r3);
AL>  env->gpr[4] = 0;

TH> I'm not very familiar with the e500 code, but as far as I understand 
the
TH> ppce500_spin.c code, it provides the spin table facility from ePAPR 
for the
TH> guests that is normally provided by the boot firmware instead. Some 
more
TH> information why this has been done can be found in the original commit
TH> message here:
TH>   http://git.qemu.org/?p=qemu.git;a=commitdiff;h=5c145dacacad04f751c
TH> 
TH> So it's right to set up curspin->pir here (not the other way round), 
but
TH> I think SPR_PIR was just a typo and should be SPR_BOOKE_PIR instead,
TH> since the PIR register for BookE CPUs has the number 286 and not 1023.
TH> So does it work for you if you simply replace the line with:
TH> 
TH> stl_p(>pir, env->spr[SPR_BOOKE_PIR]);

I verified that the spin table is properly initialized if
SPR_BOOKE_PIR is used.  However this is superfluous since spin_reset()
has already initialized the PV spin table pir.  I wasn't sure if there
was a desire to set the SPR_PIR as well for some reason.

I think any of the following would be acceptable:

1. If the SPR_PIR needs to be set for some reason (why I'm not sure),
   then set SPR_PIR to SPR_BOOKE_PIR.
2. Change SPR_PIR to SPR_BOOKE_PIR.
3. Delete the line that sets curspin->pir to SPR_PIR.

I'm fine submitting a patch for whatever solution folks deem
appropriate.



Re: [Qemu-devel] [RFC] target-arm: fix semihosting ram base issue

2016-06-17 Thread Tsung-Han Lin
2016-06-18 1:22 GMT+09:00 Liviu Ionescu :

>
> > On 17 Jun 2016, at 05:37, Tsung-Han Lin  wrote:
> >
> > Hi, I made some changes to TRY TO fix the ARM semihosting issue ...
> > This problem has been bothering me for quite a while.
>
> semihosting was the first thing I fixed in GNU ARM Eclipse QEMU, and since
> then I use it constantly.
>
> I don't know if this addresses your problem, but perhaps you could also
> take a look there.
>

Hi, Liviu,

Thanks for the suggestion.

It seems like to me that the issue is the default address assumed by qemu,
which is 0x0.
(since Eclipse QEMU uses the same code, I believe they have the same
problem.)
But it's not always the case.
For example, zynqmp's ram base address is 0x8000,
and I have to tweak that address in HEAPINFO handling code every time I
change to a new HW config.

Regards,

>
>
> regards,
>
> Liviu
>
>


-- 
Tsung-Han "*Johnny*" Lin

Page: http://tsunghanlin.github.com/
Email: tsunghan...@gmail.com


[Qemu-devel] [Bug 1591611] Re: chroot using qemu-x86_64-static fails on ppc64el

2016-06-17 Thread Timothy Pearson
So after some further debugging effort it turns out while the page
allocator is unaware of the mapping (looks like the x86_64 NPTL
implementation never maps the thread ID memory?), g2h() does work on the
address, and in this case they map to the same value.  I'll probably
submit a patch using g2h in case anyone else might have a better idea on
how to handle this.

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

Title:
  chroot using qemu-x86_64-static fails on ppc64el

Status in QEMU:
  New

Bug description:
  When attempting to use qemu-x86_64-static from qemu 2.5.0 on a ppc64el
  host to chroot into an amd64 environment, all commands fail with an
  assertion error.  /usr/bin/qemu-x86_64-static from the host was copied
  into the chroot /usr/bin, and the host has multiformat support in the
  kernel.

  Sample output illustrating the problem, as well as bash builtins
  working:

  # chroot /virtualbox/scratchdisks_local_001/amd64_chroot qemu-x86_64-static 
/bin/bash
  # ls
  bash: ../sysdeps/nptl/fork.c:136: __libc_fork: Assertion `({ __typeof 
(self->tid) __value; if (sizeof (__value) == 1) asm volatile ("movb 
%%fs:%P2,%b0" : "=q" (__value) : "0" (0), "i" (__builtin_offsetof (struct 
pthread, tid))); else if (sizeof (__value) == 4) asm volatile ("movl 
%%fs:%P1,%0" : "=r" (__value) : "i" (__builtin_offsetof (struct pthread, 
tid))); else { if (sizeof (__value) != 8) abort (); asm volatile ("movq 
%%fs:%P1,%q0" : "=r" (__value) : "i" (__builtin_offsetof (struct pthread, 
tid))); } __value; }) != ppid' failed.
  setup_frame: not implemented
  setup_frame: not implemented
  qemu: uncaught target signal 11 (Segmentation fault) - core dumped
  Segmentation fault
  setup_frame: not implemented
  setup_frame: not implemented
  # echo TEST
  TEST
  # cat test
  bash: ../sysdeps/nptl/fork.c:136: __libc_fork: Assertion `({ __typeof 
(self->tid) __value; if (sizeof (__value) == 1) asm volatile ("movb 
%%fs:%P2,%b0" : "=q" (__value) : "0" (0), "i" (__builtin_offsetof (struct 
pthread, tid))); else if (sizeof (__value) == 4) asm volatile ("movl 
%%fs:%P1,%0" : "=r" (__value) : "i" (__builtin_offsetof (struct pthread, 
tid))); else { if (sizeof (__value) != 8) abort (); asm volatile ("movq 
%%fs:%P1,%q0" : "=r" (__value) : "i" (__builtin_offsetof (struct pthread, 
tid))); } __value; }) != ppid' failed.
  qemu: uncaught target signal 11 (Segmentation fault) - core dumped
  Segmentation fault

  It is currently unknown if other host architectures (e.g. aarch64) are
  also affected.

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



Re: [Qemu-devel] [Qemu-ppc] Determining interest in PPC e500spin, yield, and openpic patches

2016-06-17 Thread alarson
Thomas Huth  wrote on 06/16/2016 01:25:45 AM:

> Thanks for your patch! However, patches have to follow certain rules
> before they can be included in QEMU. Please read through

Sorry for the broken patch, and the long delay.  I'm not a git user
so its taken a while to climb the curve.  I didn't get 'git send-email'
working, but hopefully the next patch will be ok.




Re: [Qemu-devel] [PATCH v4 3/3] i386: publish advised value of MSR_IA32_FEATURE_CONTROL via fw_cfg

2016-06-17 Thread Laszlo Ersek
On 06/17/16 22:55, Raj, Ashok wrote:
> On Fri, Jun 17, 2016 at 10:48:17PM +0200, Laszlo Ersek wrote:
>> On 06/17/16 22:21, Raj, Ashok wrote:
>>> On Fri, Jun 17, 2016 at 07:31:08PM +0200, Laszlo Ersek wrote:
>>
>> On 16/06/2016 08:06, Haozhong Zhang wrote:
>>> It's a prerequisite that certain bits of MSR_IA32_FEATURE_CONTROL should
>>> be set before some features (e.g. VMX and LMCE) can be used, which is
>>> usually done by the firmware. This patch adds a fw_cfg file
>>> "etc/msr_feature_control" which contains the advised value of
>>> MSR_IA32_FEATURE_CONTROL and can be used by guest firmware (e.g. 
>>> SeaBIOS).
>>>
>>>
>>> I'm sorry i'm joining this discussion a bit late returning from vacation. 
>>> In a real platform supporting LMCE, BIOS is responsible for setting the 
>>> bits 
>>> for IA32_FEATURE_CONTROL correctly. There are good reasons why we want the 
>>> BIOS to play this role.
>>>
>>> in a virtualized environment, do we really have to push the same requirement
>>> or would it suffice to just emulate it as we did in the early patches.
>>>
>>> Not sure what exact problem is created by just simply supporting it within
>>> kvm/qemu and not needing the bios for the guest to also adapt these changes.
>>
>> At the moment, my understanding of this feature is superficial, but the
>> mechanisms involved in it don't seem complex. I don't expect
>> difficulties implementing it, I just need the details that I asked for
>> spelled out for me.
>>
>> As to why we should be doing this in the guest firmware(s) -- "because
>> that's what happens on physical machines too" :) Following the phys
>> world to the letter in virt is not always a goal, but it's never wrong.
> 
> But the guest bios does nothing like the BIOS in the real platform.

That's overstated. The guest firmwares do a lot of things they also do
on physical hardware. PCI enumeration / resource assignment, for example.

> for e.g. a real bios would have SMM handlers to work for implementing firmware
> first mechanisms before notifying the OS. None of these exist in the 
> virtalized world.

Both SeaBIOS and OVMF utilize SMM, for various purposes.

OVMF's goals with SMM are briefly documented here:
.

For SMM support, all of KVM, QEMU, and OVMF needed (many) patches.


Anyway, I'm neutral on this. If the consensus is that the MSR at hand is
none of the guest firmware's business, I won't object -- hey, it's only
less work for me. OTOH, if the consensus is that SeaBIOS should be aware
of the MSR, then it follows that so should OVMF.

Thanks
Laszlo



Re: [Qemu-devel] [PATCH v4 3/3] i386: publish advised value of MSR_IA32_FEATURE_CONTROL via fw_cfg

2016-06-17 Thread Raj, Ashok
On Fri, Jun 17, 2016 at 10:48:17PM +0200, Laszlo Ersek wrote:
> On 06/17/16 22:21, Raj, Ashok wrote:
> > On Fri, Jun 17, 2016 at 07:31:08PM +0200, Laszlo Ersek wrote:
> 
>  On 16/06/2016 08:06, Haozhong Zhang wrote:
> > It's a prerequisite that certain bits of MSR_IA32_FEATURE_CONTROL should
> > be set before some features (e.g. VMX and LMCE) can be used, which is
> > usually done by the firmware. This patch adds a fw_cfg file
> > "etc/msr_feature_control" which contains the advised value of
> > MSR_IA32_FEATURE_CONTROL and can be used by guest firmware (e.g. 
> > SeaBIOS).
> >
> > 
> > I'm sorry i'm joining this discussion a bit late returning from vacation. 
> > In a real platform supporting LMCE, BIOS is responsible for setting the 
> > bits 
> > for IA32_FEATURE_CONTROL correctly. There are good reasons why we want the 
> > BIOS to play this role.
> > 
> > in a virtualized environment, do we really have to push the same requirement
> > or would it suffice to just emulate it as we did in the early patches.
> > 
> > Not sure what exact problem is created by just simply supporting it within
> > kvm/qemu and not needing the bios for the guest to also adapt these changes.
> 
> At the moment, my understanding of this feature is superficial, but the
> mechanisms involved in it don't seem complex. I don't expect
> difficulties implementing it, I just need the details that I asked for
> spelled out for me.
> 
> As to why we should be doing this in the guest firmware(s) -- "because
> that's what happens on physical machines too" :) Following the phys
> world to the letter in virt is not always a goal, but it's never wrong.

But the guest bios does nothing like the BIOS in the real platform.

for e.g. a real bios would have SMM handlers to work for implementing firmware
first mechanisms before notifying the OS. None of these exist in the 
virtalized world.





Re: [Qemu-devel] [PATCH v4 3/3] i386: publish advised value of MSR_IA32_FEATURE_CONTROL via fw_cfg

2016-06-17 Thread Laszlo Ersek
On 06/17/16 22:21, Raj, Ashok wrote:
> On Fri, Jun 17, 2016 at 07:31:08PM +0200, Laszlo Ersek wrote:

 On 16/06/2016 08:06, Haozhong Zhang wrote:
> It's a prerequisite that certain bits of MSR_IA32_FEATURE_CONTROL should
> be set before some features (e.g. VMX and LMCE) can be used, which is
> usually done by the firmware. This patch adds a fw_cfg file
> "etc/msr_feature_control" which contains the advised value of
> MSR_IA32_FEATURE_CONTROL and can be used by guest firmware (e.g. SeaBIOS).
>
> 
> I'm sorry i'm joining this discussion a bit late returning from vacation. 
> In a real platform supporting LMCE, BIOS is responsible for setting the bits 
> for IA32_FEATURE_CONTROL correctly. There are good reasons why we want the 
> BIOS to play this role.
> 
> in a virtualized environment, do we really have to push the same requirement
> or would it suffice to just emulate it as we did in the early patches.
> 
> Not sure what exact problem is created by just simply supporting it within
> kvm/qemu and not needing the bios for the guest to also adapt these changes.

At the moment, my understanding of this feature is superficial, but the
mechanisms involved in it don't seem complex. I don't expect
difficulties implementing it, I just need the details that I asked for
spelled out for me.

As to why we should be doing this in the guest firmware(s) -- "because
that's what happens on physical machines too" :) Following the phys
world to the letter in virt is not always a goal, but it's never wrong.

Thanks
Laszlo



Re: [Qemu-devel] [PATCH v4 3/3] i386: publish advised value of MSR_IA32_FEATURE_CONTROL via fw_cfg

2016-06-17 Thread Raj, Ashok
On Fri, Jun 17, 2016 at 07:31:08PM +0200, Laszlo Ersek wrote:
> >>
> >> On 16/06/2016 08:06, Haozhong Zhang wrote:
> >>> It's a prerequisite that certain bits of MSR_IA32_FEATURE_CONTROL should
> >>> be set before some features (e.g. VMX and LMCE) can be used, which is
> >>> usually done by the firmware. This patch adds a fw_cfg file
> >>> "etc/msr_feature_control" which contains the advised value of
> >>> MSR_IA32_FEATURE_CONTROL and can be used by guest firmware (e.g. SeaBIOS).
> >>>

I'm sorry i'm joining this discussion a bit late returning from vacation. 
In a real platform supporting LMCE, BIOS is responsible for setting the bits 
for IA32_FEATURE_CONTROL correctly. There are good reasons why we want the 
BIOS to play this role.

in a virtualized environment, do we really have to push the same requirement
or would it suffice to just emulate it as we did in the early patches.

Not sure what exact problem is created by just simply supporting it within
kvm/qemu and not needing the bios for the guest to also adapt these changes.

Cheers,
Ashok




Re: [Qemu-devel] [PATCH v4 4/6] trace: Add per-vCPU tracing states for events with the 'vcpu' property

2016-06-17 Thread Lluís Vilanova
Stefan Hajnoczi writes:

> On Tue, Jun 14, 2016 at 03:11:12PM +0200, Lluís Vilanova wrote:
>> @@ -1116,6 +1117,7 @@ int main(int argc, char **argv)
>> gdbserver_start (gdbstub_port);
>> gdb_handlesig(cpu, 0);
>> }
>> +trace_init_vcpu_events();

> Do vcpu events make sense in *-user builds?  I thought this feature is
> only available in *-softmmu.

It's here for completeness, although it's currently useless. AFAIK, QEMU has
multiple vCPUs when the user application is multi-threaded, but user QEMU has no
interface to interactively control event states.

I can remove it if you want.


>> +##
>> +# Avoid rule overrides when included from multiple top-level variables
>> +ifndef MAKEFILE_GUARD_TRACE
>> +MAKEFILE_GUARD_TRACE = 1
>> +endif

> Are you including this makefile multiple times?  We need to find a
> cleaner solution.  If this is related to "stubs", then could
> control-stub.o could go in stubs/?

The stubs are the reason, yes. I'll refactor these into the stubs directory.


Thanks,
  Lluis



[Qemu-devel] [PATCH] target-alpha: Avoid gcc 6.1 werror for linux-user

2016-06-17 Thread Richard Henderson
Using gcc 6.1 for alpha-linux-user target we see the following build error:

.../target-alpha/translate.c: In function ‘in_superpage’:
.../target-alpha/translate.c:454:52: error: self-comparison always evaluates to 
true [-Werror=tautological-compare]
 && addr >> TARGET_VIRT_ADDR_SPACE_BITS == addr >> 63);

Reported-by: Pranith Kumar 
Signed-off-by: Richard Henderson 
---
 target-alpha/translate.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/target-alpha/translate.c b/target-alpha/translate.c
index f9b2426..051b4b7 100644
--- a/target-alpha/translate.c
+++ b/target-alpha/translate.c
@@ -448,10 +448,13 @@ static ExitStatus gen_store_conditional(DisasContext 
*ctx, int ra, int rb,
 
 static bool in_superpage(DisasContext *ctx, int64_t addr)
 {
+#ifndef CONFIG_USER_ONLY
 return ((ctx->tb->flags & TB_FLAGS_USER_MODE) == 0
-&& addr < 0
-&& ((addr >> 41) & 3) == 2
-&& addr >> TARGET_VIRT_ADDR_SPACE_BITS == addr >> 63);
+&& addr >> TARGET_VIRT_ADDR_SPACE_BITS == -1
+&& ((addr >> 41) & 3) == 2);
+#else
+return false;
+#endif
 }
 
 static bool use_goto_tb(DisasContext *ctx, uint64_t dest)
-- 
2.5.5




Re: [Qemu-devel] git master build failure

2016-06-17 Thread Laszlo Ersek
On 06/17/16 14:55, Peter Maydell wrote:
> On 17 June 2016 at 13:41, Mark Cave-Ayland
>  wrote:
>> Thank you looking into this. I know that some workarounds have been
>> applied for similar bugs in Peter's setup, but in general should I
>> assume that out-of-the-box Debian oldstable is now no longer supported
>> to build QEMU?

(I have no stake in this, just took an interest in it for some reason.)

> I would kind of prefer us to work around the compiler issue if
> it's not too difficult to do so. Otherwise, just configure
> with --disable-werror.

I agree working it around is preferable, if we can find a deterministic
way to do that. I'm afraid it will require someone to look into, and
understand, the internal AST representation of gcc (with -fdump-tree-*),
and then perturb it through the QEMU source sufficiently.

Also, how about filing that backport bug for Debian? If they backport
the gcc fix, then the issue is solved -- people can be expected to
update their Debian systems fully, before they do any heavy-lifting with
them (like building QEMU).

Thanks
Laszlo



Re: [Qemu-devel] [PATCH] alpha: Fix build error for linux-user

2016-06-17 Thread Pranith Kumar
On Fri, Jun 17, 2016 at 2:04 PM, Paolo Bonzini  wrote:
>
>
> On 16/06/2016 21:07, Richard Henderson wrote:
>>>  && ((addr >> 41) & 3) == 2
>>> -&& addr >> TARGET_VIRT_ADDR_SPACE_BITS == addr >> 63);
>>> +&& addr >> TARGET_VIRT_ADDR_SPACE_BITS == 1);
>
> What you want here is
>
> +   addr >> TARGET_VIRT_ADDR_SPACE_BITS == -1
>
> since that's what addr >> 63 is.  With this change the patch should be fine.

Isn't (addr >> 63) supposed to be 1? How can it be -1?

-- 
Pranith



Re: [Qemu-devel] [PATCH] alpha: Fix build error for linux-user

2016-06-17 Thread Paolo Bonzini


On 16/06/2016 21:07, Richard Henderson wrote:
>>  && ((addr >> 41) & 3) == 2
>> -&& addr >> TARGET_VIRT_ADDR_SPACE_BITS == addr >> 63);
>> +&& addr >> TARGET_VIRT_ADDR_SPACE_BITS == 1);

What you want here is

+   addr >> TARGET_VIRT_ADDR_SPACE_BITS == -1

since that's what addr >> 63 is.  With this change the patch should be fine.

Alternatively, combining this condition with addr < 0 should be

(uint64_t)addr >= (-1ull << TARGET_VIRT_ADDR_SPACE_BITS)

I think (I might have an off by one here, sorry).  If you go this way,
it's of course nicer to change the argument type to uint64_t.

Paolo



Re: [Qemu-devel] [PATCH v17 2/4] block/gluster: code cleanup

2016-06-17 Thread Jeff Cody
On Wed, Jun 15, 2016 at 01:55:45PM +0530, Prasanna Kumar Kalever wrote:
> unified coding styles of multiline function arguments and other error 
> functions
> moved random declarations of structures and other list variables
> 
> Signed-off-by: Prasanna Kumar Kalever 
> Reviewed-by: Eric Blake 

Reviewed-by: Jeff Cody 

> ---
>  block/gluster.c | 113 
> ++--
>  1 file changed, 60 insertions(+), 53 deletions(-)
> 
> diff --git a/block/gluster.c b/block/gluster.c
> index 0c711a3..45072b1 100644
> --- a/block/gluster.c
> +++ b/block/gluster.c
> @@ -26,6 +26,11 @@ typedef struct BDRVGlusterState {
>  struct glfs_fd *fd;
>  } BDRVGlusterState;
>  
> +typedef struct BDRVGlusterReopenState {
> +struct glfs *glfs;
> +struct glfs_fd *fd;
> +} BDRVGlusterReopenState;
> +
>  typedef struct GlusterConf {
>  char *host;
>  int port;
> @@ -34,6 +39,39 @@ typedef struct GlusterConf {
>  char *transport;
>  } GlusterConf;
>  
> +
> +static QemuOptsList qemu_gluster_create_opts = {
> +.name = "qemu-gluster-create-opts",
> +.head = QTAILQ_HEAD_INITIALIZER(qemu_gluster_create_opts.head),
> +.desc = {
> +{
> +.name = BLOCK_OPT_SIZE,
> +.type = QEMU_OPT_SIZE,
> +.help = "Virtual disk size"
> +},
> +{
> +.name = BLOCK_OPT_PREALLOC,
> +.type = QEMU_OPT_STRING,
> +.help = "Preallocation mode (allowed values: off, full)"
> +},
> +{ /* end of list */ }
> +}
> +};
> +
> +static QemuOptsList runtime_opts = {
> +.name = "gluster",
> +.head = QTAILQ_HEAD_INITIALIZER(runtime_opts.head),
> +.desc = {
> +{
> +.name = "filename",
> +.type = QEMU_OPT_STRING,
> +.help = "URL to the gluster image",
> +},
> +{ /* end of list */ }
> +},
> +};
> +
> +
>  static void qemu_gluster_gconf_free(GlusterConf *gconf)
>  {
>  if (gconf) {
> @@ -178,7 +216,7 @@ static struct glfs *qemu_gluster_init(GlusterConf *gconf, 
> const char *filename,
>  ret = qemu_gluster_parseuri(gconf, filename);
>  if (ret < 0) {
>  error_setg(errp, "Usage: file=gluster[+transport]://[host[:port]]/"
> -   "volume/path[?socket=...]");
> + "volume/path[?socket=...]");
>  errno = -ret;
>  goto out;
>  }
> @@ -256,20 +294,6 @@ static void gluster_finish_aiocb(struct glfs_fd *fd, 
> ssize_t ret, void *arg)
>  qemu_bh_schedule(acb->bh);
>  }
>  
> -/* TODO Convert to fine grained options */
> -static QemuOptsList runtime_opts = {
> -.name = "gluster",
> -.head = QTAILQ_HEAD_INITIALIZER(runtime_opts.head),
> -.desc = {
> -{
> -.name = "filename",
> -.type = QEMU_OPT_STRING,
> -.help = "URL to the gluster image",
> -},
> -{ /* end of list */ }
> -},
> -};
> -
>  static void qemu_gluster_parse_flags(int bdrv_flags, int *open_flags)
>  {
>  assert(open_flags != NULL);
> @@ -287,7 +311,7 @@ static void qemu_gluster_parse_flags(int bdrv_flags, int 
> *open_flags)
>  }
>  }
>  
> -static int qemu_gluster_open(BlockDriverState *bs,  QDict *options,
> +static int qemu_gluster_open(BlockDriverState *bs, QDict *options,
>   int bdrv_flags, Error **errp)
>  {
>  BDRVGlusterState *s = bs->opaque;
> @@ -353,12 +377,6 @@ out:
>  return ret;
>  }
>  
> -typedef struct BDRVGlusterReopenState {
> -struct glfs *glfs;
> -struct glfs_fd *fd;
> -} BDRVGlusterReopenState;
> -
> -
>  static int qemu_gluster_reopen_prepare(BDRVReopenState *state,
> BlockReopenQueue *queue, Error **errp)
>  {
> @@ -455,7 +473,9 @@ static void qemu_gluster_reopen_abort(BDRVReopenState 
> *state)
>  
>  #ifdef CONFIG_GLUSTERFS_ZEROFILL
>  static coroutine_fn int qemu_gluster_co_pwrite_zeroes(BlockDriverState *bs,
> -int64_t offset, int size, BdrvRequestFlags flags)
> +  int64_t offset,
> +  int size,
> +  BdrvRequestFlags flags)
>  {
>  int ret;
>  GlusterAIOCB acb;
> @@ -481,7 +501,7 @@ static inline bool gluster_supports_zerofill(void)
>  }
>  
>  static inline int qemu_gluster_zerofill(struct glfs_fd *fd, int64_t offset,
> -int64_t size)
> +int64_t size)
>  {
>  return glfs_zerofill(fd, offset, size);
>  }
> @@ -493,7 +513,7 @@ static inline bool gluster_supports_zerofill(void)
>  }
>  
>  static inline int qemu_gluster_zerofill(struct glfs_fd *fd, int64_t offset,
> -int64_t size)
> +int64_t size)
>  {
>  return 0;
>  }
> @@ -522,19 +542,17 @@ static int 

Re: [Qemu-devel] [PATCH v4 2/3] target-i386: add migration support for Intel LMCE

2016-06-17 Thread Paolo Bonzini


On 17/06/2016 19:20, Eduardo Habkost wrote:
>> > 
>> > What will be the conclusion? Do we still need this check?
>> > 
>> > I'm fine to remove this check if we normally didn't make such kind of
>> > checks and require users to avoid configuration mismatch.
> 
> I don't know yet if Paolo is convinced that the check is still
> useful. :)

I'm not. :)

> > Does that mean we can automatically enable LMCE for "-cpu host"?
>
> We can automatically enable LMCE for "-cpu host" if and only if
> the host kernel supports LMCE.

Yes, I agree here.  It's a start.

Paolo



Re: [Qemu-devel] [PATCH] alpha: Fix build error for linux-user

2016-06-17 Thread Pranith Kumar
On Fri, Jun 17, 2016 at 2:09 PM, Richard Henderson  wrote:
> On 06/17/2016 11:07 AM, Pranith Kumar wrote:
>> On Fri, Jun 17, 2016 at 2:04 PM, Paolo Bonzini  wrote:
>>>
>>>
>>> On 16/06/2016 21:07, Richard Henderson wrote:
>  && ((addr >> 41) & 3) == 2
> -&& addr >> TARGET_VIRT_ADDR_SPACE_BITS == addr >> 63);
> +&& addr >> TARGET_VIRT_ADDR_SPACE_BITS == 1);
>>>
>>> What you want here is
>>>
>>> +   addr >> TARGET_VIRT_ADDR_SPACE_BITS == -1
>>>
>>> since that's what addr >> 63 is.  With this change the patch should be fine.
>>
>> Isn't (addr >> 63) supposed to be 1? How can it be -1?
>
> Signed right shift.

Ah, got it. :)

>
> I'll prepare a patch for all of this.

Thanks!
-- 
Pranith



Re: [Qemu-devel] [PATCH v4 2/3] target-i386: add migration support for Intel LMCE

2016-06-17 Thread Eduardo Habkost
On Fri, Jun 17, 2016 at 10:01:05AM +0800, Haozhong Zhang wrote:
> On 06/16/16 14:58, Eduardo Habkost wrote:
> > On Thu, Jun 16, 2016 at 07:40:20PM +0200, Paolo Bonzini wrote:
> > > 
> > > 
> > > On 16/06/2016 19:36, Eduardo Habkost wrote:
> > > >> > 
> > > >> > Eduardo said nice for this part in previous version [1], so we may 
> > > >> > wait
> > > >> > for his comments?
> > > >> > 
> > > >> > [1] 
> > > >> > http://lists.nongnu.org/archive/html/qemu-devel/2016-06/msg01992.html
> > > > I agree we don't need this check, but I still believe it is a
> > > > nice thing to have.
> > > > 
> > > > In addition to detecting user errors, they don't hurt and are
> > > > useful for things like "-cpu host", that don't guarantee
> > > > live-migration compatibility but still allow migration if you
> > > > ensure host capabilities are the same on both sides.
> > > 
> > > On the other hand we don't check for this on any other property, either
> > > CPU or device, do we?  Considering "lmce=on" always breaks on an old
> > > kernel (i.e. there's no need for an explicit ",enforce" on the -cpu
> > > flag), I think it's unnecessary and makes things inconsistent.
> > 
> > We don't check that because we normally can't: we usually don't
> > send any configuration data (or anything that could be used to
> > detect configuration mismatches) to the destination. When we do,
> > it's often by accident.
> > 
> > In this case, it looks like we never needed to send mcg_cap in
> > the migration stream. But we already send it, so let's use it for
> > something useful.
> > 
> > I believe we should have more checks like these, when possible. I
> > have been planning for a while to send CPUID data in the
> > migration stream, to detect migration compatibility errors
> > (either user errors or QEMU bugs).
> > 
> > In theory, those checks should never be necessary. In practice I
> > believe they would be very useful.
> >
> 
> Hi Eduardo and Paolo,
> 
> What will be the conclusion? Do we still need this check?
> 
> I'm fine to remove this check if we normally didn't make such kind of
> checks and require users to avoid configuration mismatch.

I don't know yet if Paolo is convinced that the check is still
useful. :)

I suggest doing it as a separate patch, so we can apply the rest
of the series now and discuss/apply the check later.

> 
> > > 
> > > > (I was going to suggest enabling lmce automatically on "-cpu
> > > > host" as a follow-up patch, BTW.)
> > > 
> > > Interesting.  Technically it comes from the host kernel, not from the
> > > host CPU.  But it does sounds like a good idea; -cpu host pretty much
> > > implies the same kernel (in addition to the same processor) on both
> > > sides of the migration.
> > 
> > "-cpu host" already means "whatever is allowed by the host [CPU
> > and/or kernel]", not just "host CPU". It enables x2apic on all
> > hosts, for example.
> >
> 
> Does that mean we can automatically enable LMCE for "-cpu host"?

We can automatically enable LMCE for "-cpu host" if and only if
the host kernel supports LMCE.

-- 
Eduardo



Re: [Qemu-devel] [RFC 2/7] exec: keep CPUWatchpoint references internal

2016-06-17 Thread Paolo Bonzini


On 17/06/2016 18:33, Alex Bennée wrote:
> +wp = g_array_index(cpu->watchpoints, CPUWatchpoint *, index);

Worth adding macros or inline functions cpu_breakpoint_at(cpu, index)
and cpu_watchpoint_at(cpu, index)?  This will also be less churn in
patch 4, because the macros will always return CPU{Break,Watch}point *.

(I'm making the suggestion as I skim the patches, but they often apply
earlier in the series.  Sorry).

Paolo



Re: [Qemu-devel] [PATCH] oslib-posix: New qemu_alloc_stack() to allocate stack with correct perms

2016-06-17 Thread Peter Maydell
On 17 June 2016 at 18:27, Richard Henderson  wrote:
> On 06/17/2016 09:36 AM, Peter Maydell wrote:
>> And
>> most architectures except x86-64 won't honour PT_GNU_STACK=non-exec
>> unless the parent process also had nonexec stack (because they
>> let the READ_IMPLIES_EXEC personality flag be inherited; see
>> https://insights.sei.cmu.edu/cert/2014/02/feeling-insecure-blame-your-parent.html
>> ). So the PT_GNU_STACK flag doesn't necessarily match up with
>> either the actual executability of the standard stack or with
>> what the kernel actually requires.
>
> How bizarre.
>
> Glibc will most definitely honour PT_GNU_STACK when allocating thread stacks,
> so it's a weird thing for the kernel to want to inherit for the initial thread
> stack.

I agree. I think it's a bug in the non-x86-64 architectures
(and particularly annoying if /sbin/init happens to not be
marked as being ok for non-exec stack).

>>> But really this is a place that I'd much rather fall back to an ifdef ladder
>>> than assume executable permission is required.
>>
>> The trouble with this is that it means that as and when the MIPS
>> folks fix their kernel and libc and compiler to support non-exec
>> stacks we won't automatically pick this up, and our stacks will
>> remain executable. Also it requires us to audit every architecture
>> to find out which ones require exec-stack. But maybe it is just
>> MIPS? (Maybe we could just say "this is a MIPS kernel bug" ? :-))
>
> I am inclined to hope that this is just a mips thing.
> It's a pretty strange situation.
>
> But I did really mean fall back.  Yes, try the other methods, but
> if we don't detect anything about the stack, only enable it via
> ifdef ladder.

Oh, I see.

thanks
-- PMM



Re: [Qemu-devel] [RFC 4/7] break/watchpoints: store inside array

2016-06-17 Thread Paolo Bonzini


On 17/06/2016 18:33, Alex Bennée wrote:
> @@ -807,18 +807,17 @@ int cpu_watchpoint_insert_with_ref(CPUState *cpu, vaddr 
> addr, vaddr len,
>  wp->flags = flags;
>  wp->ref = ref;
>  } else {
> -wp = g_malloc(sizeof(*wp));
> -
> -wp->vaddr = addr;
> -wp->len = len;
> -wp->flags = flags;
> -wp->ref = ref;
> +CPUWatchpoint watch;
> +watch.vaddr = addr;
> +watch.len = len;
> +watch.flags = flags;
> +watch.ref = ref;
>  
>  /* keep all GDB-injected watchpoints in front */
>  if (flags & BP_GDB) {
> -g_array_prepend_val(cpu->watchpoints, wp);
> +g_array_prepend_val(cpu->watchpoints, watch);
>  } else {
> -g_array_append_val(cpu->watchpoints, wp);
> +g_array_append_val(cpu->watchpoints, watch);
>  }

Please define "watch" outside the "if", so that the "then" side can do just

*wp = watch;

and there is less duplication.

Paolo



Re: [Qemu-devel] [PATCH v17 1/4] block/gluster: rename [server, volname, image] -> [host, volume, path]

2016-06-17 Thread Jeff Cody
On Wed, Jun 15, 2016 at 01:55:44PM +0530, Prasanna Kumar Kalever wrote:
> A future patch will add support for multiple gluster servers. Existing
> terminology is a bit unusual in relation to what names are used by
> other networked devices, and doesn't map very well to the terminology
> we expect to use for multiple servers.  Therefore, rename the following
> options:
> 'server'  -> 'host'
> 'image'   -> 'path'
> 'volname' -> 'volume'
> 
> Signed-off-by: Prasanna Kumar Kalever 
> Reviewed-by: Eric Blake 

Reviewed-by: Jeff Cody 

> ---
>  block/gluster.c | 54 +++---
>  1 file changed, 27 insertions(+), 27 deletions(-)
> 
> diff --git a/block/gluster.c b/block/gluster.c
> index d361d8e..0c711a3 100644
> --- a/block/gluster.c
> +++ b/block/gluster.c
> @@ -27,19 +27,19 @@ typedef struct BDRVGlusterState {
>  } BDRVGlusterState;
>  
>  typedef struct GlusterConf {
> -char *server;
> +char *host;
>  int port;
> -char *volname;
> -char *image;
> +char *volume;
> +char *path;
>  char *transport;
>  } GlusterConf;
>  
>  static void qemu_gluster_gconf_free(GlusterConf *gconf)
>  {
>  if (gconf) {
> -g_free(gconf->server);
> -g_free(gconf->volname);
> -g_free(gconf->image);
> +g_free(gconf->host);
> +g_free(gconf->volume);
> +g_free(gconf->path);
>  g_free(gconf->transport);
>  g_free(gconf);
>  }
> @@ -59,19 +59,19 @@ static int parse_volume_options(GlusterConf *gconf, char 
> *path)
>  if (*p == '\0') {
>  return -EINVAL;
>  }
> -gconf->volname = g_strndup(q, p - q);
> +gconf->volume = g_strndup(q, p - q);
>  
> -/* image */
> +/* path */
>  p += strspn(p, "/");
>  if (*p == '\0') {
>  return -EINVAL;
>  }
> -gconf->image = g_strdup(p);
> +gconf->path = g_strdup(p);
>  return 0;
>  }
>  
>  /*
> - * file=gluster[+transport]://[server[:port]]/volname/image[?socket=...]
> + * file=gluster[+transport]://[host[:port]]/volume/path[?socket=...]
>   *
>   * 'gluster' is the protocol.
>   *
> @@ -80,10 +80,10 @@ static int parse_volume_options(GlusterConf *gconf, char 
> *path)
>   * tcp, unix and rdma. If a transport type isn't specified, then tcp
>   * type is assumed.
>   *
> - * 'server' specifies the server where the volume file specification for
> + * 'host' specifies the host where the volume file specification for
>   * the given volume resides. This can be either hostname, ipv4 address
>   * or ipv6 address. ipv6 address needs to be within square brackets [ ].
> - * If transport type is 'unix', then 'server' field should not be specified.
> + * If transport type is 'unix', then 'host' field should not be specified.
>   * The 'socket' field needs to be populated with the path to unix domain
>   * socket.
>   *
> @@ -92,9 +92,9 @@ static int parse_volume_options(GlusterConf *gconf, char 
> *path)
>   * default port. If the transport type is unix, then 'port' should not be
>   * specified.
>   *
> - * 'volname' is the name of the gluster volume which contains the VM image.
> + * 'volume' is the name of the gluster volume which contains the VM image.
>   *
> - * 'image' is the path to the actual VM image that resides on gluster volume.
> + * 'path' is the path to the actual VM image that resides on gluster volume.
>   *
>   * Examples:
>   *
> @@ -103,7 +103,7 @@ static int parse_volume_options(GlusterConf *gconf, char 
> *path)
>   * file=gluster+tcp://1.2.3.4:24007/testvol/dir/a.img
>   * file=gluster+tcp://[1:2:3:4:5:6:7:8]/testvol/dir/a.img
>   * file=gluster+tcp://[1:2:3:4:5:6:7:8]:24007/testvol/dir/a.img
> - * file=gluster+tcp://server.domain.com:24007/testvol/dir/a.img
> + * file=gluster+tcp://host.domain.com:24007/testvol/dir/a.img
>   * file=gluster+unix:///testvol/dir/a.img?socket=/tmp/glusterd.socket
>   * file=gluster+rdma://1.2.3.4:24007/testvol/a.img
>   */
> @@ -154,9 +154,9 @@ static int qemu_gluster_parseuri(GlusterConf *gconf, 
> const char *filename)
>  ret = -EINVAL;
>  goto out;
>  }
> -gconf->server = g_strdup(qp->p[0].value);
> +gconf->host = g_strdup(qp->p[0].value);
>  } else {
> -gconf->server = g_strdup(uri->server ? uri->server : "localhost");
> +gconf->host = g_strdup(uri->server ? uri->server : "localhost");
>  gconf->port = uri->port;
>  }
>  
> @@ -177,18 +177,18 @@ static struct glfs *qemu_gluster_init(GlusterConf 
> *gconf, const char *filename,
>  
>  ret = qemu_gluster_parseuri(gconf, filename);
>  if (ret < 0) {
> -error_setg(errp, "Usage: file=gluster[+transport]://[server[:port]]/"
> -   "volname/image[?socket=...]");
> +error_setg(errp, "Usage: file=gluster[+transport]://[host[:port]]/"
> +   "volume/path[?socket=...]");
>  errno = -ret;
>  goto out;

Re: [Qemu-devel] [PATCH] alpha: Fix build error for linux-user

2016-06-17 Thread Richard Henderson
On 06/17/2016 11:07 AM, Pranith Kumar wrote:
> On Fri, Jun 17, 2016 at 2:04 PM, Paolo Bonzini  wrote:
>>
>>
>> On 16/06/2016 21:07, Richard Henderson wrote:
  && ((addr >> 41) & 3) == 2
 -&& addr >> TARGET_VIRT_ADDR_SPACE_BITS == addr >> 63);
 +&& addr >> TARGET_VIRT_ADDR_SPACE_BITS == 1);
>>
>> What you want here is
>>
>> +   addr >> TARGET_VIRT_ADDR_SPACE_BITS == -1
>>
>> since that's what addr >> 63 is.  With this change the patch should be fine.
> 
> Isn't (addr >> 63) supposed to be 1? How can it be -1?

Signed right shift.

I'll prepare a patch for all of this.


r~



Re: [Qemu-devel] [PATCH 0/5] hw/net: Don't use cpu_to_*w() and *_to_cpup()

2016-06-17 Thread Richard Henderson
On 06/16/2016 10:17 AM, Peter Maydell wrote:
> This patchset converts a handful of network devices to use
> ld*_p() and st*_p() instead of cpu_to_*w() and *_to_cpup().
> 
> This is the last lot of conversion patches; I have the "delete
> the implementations from bswap.h" patch, and will send that out
> once all of the in-flight patches have hit master.
> 
> thanks
> -- PMM
> 
> Peter Maydell (5):
>   hw/net/eepro100.c: Don't use cpu_to_*w() and *_to_cpup()
>   hw/net/rtl8139.c: Don't use *_to_cpup()
>   hw/net/rocker: Don't use *_to_cpup()
>   hw/net/virtio-net.c: Don't use *_to_cpup()
>   hw/net/e1000: Don't use *_to_cpup()
> 

Reviewed-by: Richard Henderson 


r~




Re: [Qemu-devel] [RFC 6/7] linux-user: don't clone watchpoints

2016-06-17 Thread Paolo Bonzini


On 17/06/2016 18:33, Alex Bennée wrote:
> The watchpoint code is stubbed out for CONFIG_USER_ONLY so there is no
> point attempting to copy the data here. Lets remove the code before the
> RCU protection goes in.
> 
> Signed-off-by: Alex Bennée 
> ---
>  linux-user/main.c | 8 
>  1 file changed, 8 deletions(-)
> 
> diff --git a/linux-user/main.c b/linux-user/main.c
> index 2901626..9a5d017 100644
> --- a/linux-user/main.c
> +++ b/linux-user/main.c
> @@ -3812,14 +3812,6 @@ CPUArchState *cpu_copy(CPUArchState *env)
> Note: Once we support ptrace with hw-debug register access, make sure
> BP_CPU break/watchpoints are handled correctly on clone. */
>  cpu_breakpoints_clone(cpu, new_cpu);
> -if (unlikely(cpu->watchpoints) && unlikely(cpu->watchpoints->len)) {
> -CPUWatchpoint *wp;
> -int i;
> -for (i = 0; i < cpu->watchpoints->len; i++) {
> -wp = _array_index(cpu->watchpoints, CPUWatchpoint, i);
> -cpu_watchpoint_insert(new_cpu, wp->vaddr, wp->len, wp->flags);
> -}
> -}
>  
>  return new_env;
>  }
> 

Hmm, I am not sure.  It's still the correct thing to do.

Paolo



[Qemu-devel] [Bug 1285363] Re: qemu-aarch64-static segfaults

2016-06-17 Thread Peter Maydell
We've now overhauled the signal handling code in upstream QEMU, and it
has its own implementation of the basic idea in the patch from comment 1
(which is "don't let the guest block SIGSEGV").


** Changed in: qemu
   Status: New => Fix Committed

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

Title:
  qemu-aarch64-static segfaults

Status in QEMU:
  Fix Committed
Status in qemu package in Ubuntu:
  Fix Released

Bug description:
  I've found a couple conditions that causes qemu-user-static to core
  dump fairly reliably - same with upstream git - while a binary built
  from suse's aarch64-1.6 branch seems to consistently work fine.

  Testing suggests they are resolved by the sigprocmask wrapper patches
  included in suse's tree.

   1) dh_fixperms is a script that commonly runs at the end of a package build.
   Its basically doing a `find | xargs chmod`.
   2) debootstrap --second-stage
   This is used to configure an arm64 chroot that was built using
   debootstrap on a non-native host. It is basically invoking a bunch of
   shell scripts (postinst, etc). When it blows up, the stack consistently
   looks like this:

  Core was generated by `/usr/bin/qemu-aarch64-static /bin/sh -e
  /debootstrap/debootstrap --second-stage'.
  Program terminated with signal SIGSEGV, Segmentation fault.
  #0  0x60058e55 in memcpy (__len=8, __src=0x7fff62ae34e0,
  __dest=0x400082c330) at
  /usr/include/x86_64-linux-gnu/bits/string3.h:51
  51  return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest));
  (gdb) bt
  #0  0x60058e55 in memcpy (__len=8, __src=0x7fff62ae34e0,
  __dest=0x400082c330) at
  /usr/include/x86_64-linux-gnu/bits/string3.h:51
  #1  stq_p (v=274886476624, ptr=0x400082c330) at
  /mnt/qemu.upstream/include/qemu/bswap.h:280
  #2  stq_le_p (v=274886476624, ptr=0x400082c330) at
  /mnt/qemu.upstream/include/qemu/bswap.h:315
  #3  target_setup_sigframe (set=0x7fff62ae3530, env=0x62d9c678,
  sf=0x400082b0d0) at /mnt/qemu.upstream/linux-user/signal.c:1167
  #4  target_setup_frame (usig=usig@entry=17, ka=ka@entry=0x604ec1e0
  , info=info@entry=0x0, set=set@entry=0x7fff62ae3530,
  env=env@entry=0x62d9c678)
  at /mnt/qemu.upstream/linux-user/signal.c:1286
  #5  0x60059f46 in setup_frame (env=0x62d9c678,
  set=0x7fff62ae3530, ka=0x604ec1e0 , sig=17) at
  /mnt/qemu.upstream/linux-user/signal.c:1322
  #6  process_pending_signals (cpu_env=cpu_env@entry=0x62d9c678) at
  /mnt/qemu.upstream/linux-user/signal.c:5747
  #7  0x60056e60 in cpu_loop (env=env@entry=0x62d9c678) at
  /mnt/qemu.upstream/linux-user/main.c:1082
  #8  0x60005079 in main (argc=, argv=, envp=) at
  /mnt/qemu.upstream/linux-user/main.c:4374

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



[Qemu-devel] [Bug 1457275] Re: qemu-user hangs in m{,un}map loop

2016-06-17 Thread Peter Maydell
This works for me so I think we must have fixed this problem at some
point between 2.3 and current master. If you still have this problem
with a QEMU build from head of git please reopen with instructions for
how to reproduce.


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

Title:
  qemu-user hangs in m{,un}map loop

Status in QEMU:
  Fix Released

Bug description:
  Gentoo amd64 there, tried both 2.3.0 and
  eba05e922e8e7f307bc5d4104a78797e55124e97 versions of qemu. Reproduces
  with qemu-x86_64 as well.

  ∞ strace qemu-arm bin/true 2>&1| head -n 100
  execve("/usr/bin/qemu-arm", ["qemu-arm", "bin/true"], [/* 49 vars */]) = 0
  uname({sysname="Linux", nodename="l29ah-home", ...}) = 0
  brk(0)  = 0x62a4d070
  brk(0x62a4e2b0) = 0x62a4e2b0
  arch_prctl(ARCH_SET_FS, 0x62a4d980) = 0
  set_tid_address(0x62a4dc50) = 7841
  set_robust_list(0x62a4dc60, 24) = 0
  rt_sigaction(SIGRTMIN, {0x6011bd10, [], SA_RESTORER|SA_SIGINFO, 0x60122710}, 
NULL, 8) = 0
  rt_sigaction(SIGRT_1, {0x6011bda0, [], SA_RESTORER|SA_RESTART|SA_SIGINFO, 
0x60122710}, NULL, 8) = 0
  rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
  getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0
  readlink("/proc/self/exe", "/usr/bin/qemu-arm", 4096) = 17
  brk(0x62a6f2b0) = 0x62a6f2b0
  brk(0x62a7) = 0x62a7
  rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], [], 8) = 0
  mmap(NULL, 8392704, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x2c951ff9000
  mprotect(0x2c951ff9000, 4096, PROT_NONE) = 0
  clone(child_stack=0x2c9527f8df0, 
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
 parent_tidptr=0x2c9527f99d0, tls=0x2c9527f9700, child_tidptr=0x2c9527f99d0) = 
7842
  rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
  gettimeofday({1432174351, 569148}, NULL) = 0
  getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0
  time(NULL)  = 1432174351
  openat(AT_FDCWD, "/usr/gnemul/qemu-arm", 
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or 
directory)
  uname({sysname="Linux", nodename="l29ah-home", ...}) = 0
  mprotect(0x60519000, 33558528, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
  madvise(0x605190b0, 33554432, MADV_HUGEPAGE) = -1 EINVAL (Invalid argument)
  mmap(NULL, 50331648, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) 
= 0x2c94eff9000
  brk(0x62a91000) = 0x62a91000
  mmap(NULL, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, 
-1, 0) = 0x2c857ff9000
  mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 
-1, 0) = 0x2c857ff8000
  munmap(0x2c857ff8000, 4096) = 0
  munmap(0x2c857ff9000, 4143972352)   = 0
  mmap(0x1000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, 
-1, 0) = 0x2c857ff9000
  mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 
-1, 0) = 0x2c857ff8000
  munmap(0x2c857ff8000, 4096) = 0
  munmap(0x2c857ff9000, 4143972352)   = 0
  mmap(0x2000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, 
-1, 0) = 0x2c857ff9000
  mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 
-1, 0) = 0x2c857ff8000
  munmap(0x2c857ff8000, 4096) = 0
  munmap(0x2c857ff9000, 4143972352)   = 0
  mmap(0x3000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, 
-1, 0) = 0x2c857ff9000
  mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 
-1, 0) = 0x2c857ff8000
  munmap(0x2c857ff8000, 4096) = 0
  munmap(0x2c857ff9000, 4143972352)   = 0
  mmap(0x4000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, 
-1, 0) = 0x2c857ff9000
  mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 
-1, 0) = 0x2c857ff8000
  munmap(0x2c857ff8000, 4096) = 0
  munmap(0x2c857ff9000, 4143972352)   = 0
  mmap(0x5000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, 
-1, 0) = 0x2c857ff9000
  mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 
-1, 0) = 0x2c857ff8000
  munmap(0x2c857ff8000, 4096) = 0
  munmap(0x2c857ff9000, 4143972352)   = 0
  mmap(0x6000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, 
-1, 0) = 0x2c857ff9000
  mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 
-1, 0) = 0x2c857ff8000
  munmap(0x2c857ff8000, 4096) = 0
  munmap(0x2c857ff9000, 4143972352)   = 0
  mmap(0x7000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, 
-1, 0) = 0x2c857ff9000
  mmap(0x2c957fe9000, 4096, 

[Qemu-devel] [RFC 5/7] breakpoints: put breakpoints under RCU control

2016-06-17 Thread Alex Bennée
Each time breakpoints are added/removed from the array it's done using
an read-copy-update cycle. Simultaneous writes are protected by the
debug_update_lock.

Signed-off-by: Alex Bennée 
---
 cpus.c|   3 +
 exec.c| 167 --
 include/qom/cpu.h |  42 ++
 linux-user/main.c |  11 +---
 4 files changed, 175 insertions(+), 48 deletions(-)

diff --git a/cpus.c b/cpus.c
index 84c3520..b76300b 100644
--- a/cpus.c
+++ b/cpus.c
@@ -1441,6 +1441,9 @@ void qemu_init_vcpu(CPUState *cpu)
 cpu_address_space_init(cpu, as, 0);
 }
 
+/* protects updates to debug info */
+qemu_mutex_init(>update_debug_lock);
+
 if (kvm_enabled()) {
 qemu_kvm_start_vcpu(cpu);
 } else if (tcg_enabled()) {
diff --git a/exec.c b/exec.c
index c8e8823..d1d14c1 100644
--- a/exec.c
+++ b/exec.c
@@ -919,31 +919,94 @@ static inline bool 
cpu_watchpoint_address_matches(CPUWatchpoint *wp,
 }
 
 #endif
-/* Find watchpoint with external reference */
-CPUBreakpoint *cpu_breakpoint_get_by_ref(CPUState *cpu, int ref)
+
+/* Create a working copy of the breakpoints.
+ *
+ * The rcu_read_lock() may already be held depending on where this
+ * update has been triggered from. However it is safe to nest
+ * rcu_read_locks() so we do the copy under the lock here.
+ */
+
+static GArray *rcu_copy_breakpoints(CPUState *cpu)
 {
-CPUBreakpoint *bp = NULL;
+GArray *old, *new;
+
+rcu_read_lock();
+old = atomic_rcu_read(>breakpoints);
+if (old) {
+new = g_array_sized_new(false, false, sizeof(CPUBreakpoint), old->len);
+memcpy(new->data, old->data, old->len * sizeof(CPUBreakpoint));
+new->len = old->len;
+} else {
+new = g_array_new(false, false, sizeof(CPUBreakpoint));
+}
+rcu_read_unlock();
+
+return new;
+}
+
+struct BreakRCU {
+struct rcu_head rcu;
+GArray *bkpts;
+};
+
+/* RCU reclaim step */
+static void rcu_free_breakpoints(struct BreakRCU *rcu_free)
+{
+g_array_free(rcu_free->bkpts, false);
+g_free(rcu_free);
+}
+
+/* Called with update lock held */
+static void rcu_update_breakpoints(CPUState *cpu, GArray *new_bkpts)
+{
+GArray *bpts = atomic_rcu_read(>breakpoints);
+atomic_rcu_set(>breakpoints, new_bkpts);
+
+if (bpts) {
+struct BreakRCU *rcu_free = g_malloc(sizeof(*rcu_free));
+rcu_free->bkpts = bpts;
+call_rcu(rcu_free, rcu_free_breakpoints, rcu);
+}
+}
+
+/* Find watchpoint with external reference, only valid for duration of
+ * rcu_read_lock */
+static CPUBreakpoint *find_bkpt_with_ref(GArray *bkpts, int ref)
+{
+CPUBreakpoint *bp;
 int i = 0;
+
 do {
-bp = _array_index(cpu->breakpoints, CPUBreakpoint, i++);
-} while (i < cpu->breakpoints->len && bp && bp->ref != ref);
+bp = _array_index(bkpts, CPUBreakpoint, i);
+if (bp->ref == ref) {
+return bp;
+}
+} while (i++ < bkpts->len);
 
-return bp;
+return NULL;
+}
+
+CPUBreakpoint *cpu_breakpoint_get_by_ref(CPUState *cpu, int ref)
+{
+GArray *bkpts = atomic_rcu_read(>breakpoints);
+return find_bkpt_with_ref(bkpts, ref);
 }
 
 /* Add a breakpoint.  */
 int cpu_breakpoint_insert_with_ref(CPUState *cpu, vaddr pc, int flags, int ref)
 {
+GArray *bkpts;
 CPUBreakpoint *bp = NULL;
 
-/* Allocate if no previous breakpoints */
-if (!cpu->breakpoints) {
-cpu->breakpoints = g_array_new(false, true, sizeof(CPUBreakpoint));
-}
+qemu_mutex_lock(>update_debug_lock);
+
+/* This will allocate if no previous breakpoints */
+bkpts = rcu_copy_breakpoints(cpu);
 
 /* Find old watchpoint */
 if (ref != BPWP_NOREF) {
-bp = cpu_breakpoint_get_by_ref(cpu, ref);
+bp = find_bkpt_with_ref(bkpts, ref);
 }
 
 if (bp) {
@@ -958,14 +1021,17 @@ int cpu_breakpoint_insert_with_ref(CPUState *cpu, vaddr 
pc, int flags, int ref)
 
 /* keep all GDB-injected breakpoints in front */
 if (flags & BP_GDB) {
-g_array_prepend_val(cpu->breakpoints, brk);
+g_array_prepend_val(bkpts, brk);
 } else {
-g_array_append_val(cpu->breakpoints, brk);
+g_array_append_val(bkpts, brk);
 }
 }
 
 breakpoint_invalidate(cpu, pc);
 
+rcu_update_breakpoints(cpu, bkpts);
+qemu_mutex_unlock(>update_debug_lock);
+
 return 0;
 }
 
@@ -974,67 +1040,110 @@ int cpu_breakpoint_insert(CPUState *cpu, vaddr pc, int 
flags)
 return cpu_breakpoint_insert_with_ref(cpu, pc, flags, BPWP_NOREF);
 }
 
-static void cpu_breakpoint_delete(CPUState *cpu, int index)
+/* Called with update_debug_lock held */
+static void cpu_breakpoint_delete(CPUState *cpu, GArray *bkpts, int index)
 {
 CPUBreakpoint *bp;
-bp = _array_index(cpu->breakpoints, CPUBreakpoint, index);
+bp = _array_index(bkpts, CPUBreakpoint, index);
 breakpoint_invalidate(cpu, bp->pc);
-

[Qemu-devel] [Bug 1591611] Re: chroot using qemu-x86_64-static fails on ppc64el

2016-06-17 Thread Timothy Pearson
qemu can locate the guest page with that address but it has a flags
field of all zero (no access, invalid).  Any ideas?

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

Title:
  chroot using qemu-x86_64-static fails on ppc64el

Status in QEMU:
  New

Bug description:
  When attempting to use qemu-x86_64-static from qemu 2.5.0 on a ppc64el
  host to chroot into an amd64 environment, all commands fail with an
  assertion error.  /usr/bin/qemu-x86_64-static from the host was copied
  into the chroot /usr/bin, and the host has multiformat support in the
  kernel.

  Sample output illustrating the problem, as well as bash builtins
  working:

  # chroot /virtualbox/scratchdisks_local_001/amd64_chroot qemu-x86_64-static 
/bin/bash
  # ls
  bash: ../sysdeps/nptl/fork.c:136: __libc_fork: Assertion `({ __typeof 
(self->tid) __value; if (sizeof (__value) == 1) asm volatile ("movb 
%%fs:%P2,%b0" : "=q" (__value) : "0" (0), "i" (__builtin_offsetof (struct 
pthread, tid))); else if (sizeof (__value) == 4) asm volatile ("movl 
%%fs:%P1,%0" : "=r" (__value) : "i" (__builtin_offsetof (struct pthread, 
tid))); else { if (sizeof (__value) != 8) abort (); asm volatile ("movq 
%%fs:%P1,%q0" : "=r" (__value) : "i" (__builtin_offsetof (struct pthread, 
tid))); } __value; }) != ppid' failed.
  setup_frame: not implemented
  setup_frame: not implemented
  qemu: uncaught target signal 11 (Segmentation fault) - core dumped
  Segmentation fault
  setup_frame: not implemented
  setup_frame: not implemented
  # echo TEST
  TEST
  # cat test
  bash: ../sysdeps/nptl/fork.c:136: __libc_fork: Assertion `({ __typeof 
(self->tid) __value; if (sizeof (__value) == 1) asm volatile ("movb 
%%fs:%P2,%b0" : "=q" (__value) : "0" (0), "i" (__builtin_offsetof (struct 
pthread, tid))); else if (sizeof (__value) == 4) asm volatile ("movl 
%%fs:%P1,%0" : "=r" (__value) : "i" (__builtin_offsetof (struct pthread, 
tid))); else { if (sizeof (__value) != 8) abort (); asm volatile ("movq 
%%fs:%P1,%q0" : "=r" (__value) : "i" (__builtin_offsetof (struct pthread, 
tid))); } __value; }) != ppid' failed.
  qemu: uncaught target signal 11 (Segmentation fault) - core dumped
  Segmentation fault

  It is currently unknown if other host architectures (e.g. aarch64) are
  also affected.

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



Re: [Qemu-devel] [PATCH v4 3/3] i386: publish advised value of MSR_IA32_FEATURE_CONTROL via fw_cfg

2016-06-17 Thread Laszlo Ersek
Hi Haozhong,

On 06/16/16 13:19, Haozhong Zhang wrote:
> On 06/16/16 11:52, Paolo Bonzini wrote:
>>
>>
>> On 16/06/2016 08:06, Haozhong Zhang wrote:
>>> It's a prerequisite that certain bits of MSR_IA32_FEATURE_CONTROL should
>>> be set before some features (e.g. VMX and LMCE) can be used, which is
>>> usually done by the firmware. This patch adds a fw_cfg file
>>> "etc/msr_feature_control" which contains the advised value of
>>> MSR_IA32_FEATURE_CONTROL and can be used by guest firmware (e.g. SeaBIOS).
>>>
>>> Suggested-by: Paolo Bonzini 
>>> Signed-off-by: Haozhong Zhang 
>>> ---
>>>  hw/i386/pc.c  | 28 
>>>  target-i386/cpu.h |  4 
>>>  2 files changed, 32 insertions(+)
>>>
>>> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
>>> index 7198ed5..d8178a5 100644
>>> --- a/hw/i386/pc.c
>>> +++ b/hw/i386/pc.c
>>> @@ -1147,6 +1147,33 @@ void pc_cpus_init(PCMachineState *pcms)
>>>  smbios_set_cpuid(cpu->env.cpuid_version, 
>>> cpu->env.features[FEAT_1_EDX]);
>>>  }
>>>  
>>> +static void pc_build_feature_control_file(PCMachineState *pcms)
>>> +{
>>> +X86CPU *cpu = X86_CPU(pcms->possible_cpus->cpus[0].cpu);
>>> +CPUX86State *env = >env;
>>> +uint32_t unused, ecx, edx, feature_control_bits = 0;
>>> +uint32_t *val;
>>> +
>>> +cpu_x86_cpuid(env, 1, 0, , , , );
>>> +if (ecx & CPUID_EXT_VMX) {
>>> +feature_control_bits |= FEATURE_CONTROL_VMXON_ENABLED_OUTSIDE_SMX;
>>> +}
>>> +
>>> +if ((edx & (CPUID_EXT2_MCE | CPUID_EXT2_MCA)) ==
>>> +(CPUID_EXT2_MCE | CPUID_EXT2_MCA) &&
>>> +(env->mcg_cap & MCG_LMCE_P)) {
>>> +feature_control_bits |= FEATURE_CONTROL_LMCE;
>>> +}
>>> +
>>> +if (!feature_control_bits) {
>>> +return;
>>> +}
>>> +
>>> +val = g_malloc(sizeof(*val));
>>> +*val = feature_control_bits | FEATURE_CONTROL_LOCKED;
>>> +fw_cfg_add_file(pcms->fw_cfg, "etc/msr_feature_control", val, 
>>> sizeof(*val));
>>> +}
>>> +
>>>  static
>>>  void pc_machine_done(Notifier *notifier, void *data)
>>>  {
>>> @@ -1174,6 +1201,7 @@ void pc_machine_done(Notifier *notifier, void *data)
>>>  acpi_setup();
>>>  if (pcms->fw_cfg) {
>>>  pc_build_smbios(pcms->fw_cfg);
>>> +pc_build_feature_control_file(pcms);
>>>  }
>>>  }
>>>  
>>> diff --git a/target-i386/cpu.h b/target-i386/cpu.h
>>> index f0cb04f..5e07c7a 100644
>>> --- a/target-i386/cpu.h
>>> +++ b/target-i386/cpu.h
>>> @@ -332,6 +332,10 @@
>>>  #define MSR_TSC_ADJUST  0x003b
>>>  #define MSR_IA32_TSCDEADLINE0x6e0
>>>  
>>> +#define FEATURE_CONTROL_LOCKED(1<<0)
>>> +#define FEATURE_CONTROL_VMXON_ENABLED_OUTSIDE_SMX (1<<2)
>>> +#define FEATURE_CONTROL_LMCE  (1<<20)
>>> +
>>>  #define MSR_P6_PERFCTR0 0xc1
>>>  
>>>  #define MSR_IA32_SMBASE 0x9e
>>>
>>
>> Reviewed-by: Paolo Bonzini 
>>
>> Have you prepared a patch for SeaBIOS already?
> 
> Yes, I'll send it after I fix the type error (uint32_t => uint64_t) in
> next version.

This should be supported by OVMF as well (thanks Paolo for the heads-up).

I'm glad to code that up, but I'd like to ask you to file an RFE
(Request For Enhancement) in the upstream edk2 tracker for OVMF:

https://github.com/tianocore/edk2/issues/new

In the RFE,
- the subject line should include "OvmfPkg",
- please describe what the feature is good for (going into the details
  of a specific use case is welcome),
- please specify the pathname and the internal format of the fw_cfg
  file,
- please clarify if this MSR is considered part of the "chipset state"
  that the firmware is responsible for at *every* boot. In particular
  whether you expect that the firmware program this MSR at S3 resume as
  well.

Thanks!
Laszlo




[Qemu-devel] [RFC 3/7] exec: keep CPUBreakpoint references internal

2016-06-17 Thread Alex Bennée
In preparation for the conversion to an RCU controlled list of
breakpoints I've removed all $ARCH local references to breakpoint
structures. They can be accessed with cpu_breakpoint_get_by_ref() which
will eventually offer them for the lifetime of the rcu_read_lock().

Instead of using pointers as handles to architecture specific registers
they now use plain integer references.

Signed-off-by: Alex Bennée 
---
 exec.c   | 116 +++
 gdbstub.c|   2 +-
 include/qom/cpu.h|  59 +---
 linux-user/main.c|   2 +-
 target-arm/cpu.h |   2 -
 target-arm/helper.c  |  12 ++---
 target-arm/op_helper.c   |   6 +--
 target-i386/bpt_helper.c |  25 --
 target-i386/cpu.h|   3 --
 target-lm32/cpu.h|   2 -
 target-lm32/helper.c |  10 +---
 11 files changed, 148 insertions(+), 91 deletions(-)

diff --git a/exec.c b/exec.c
index 3dc3332..e80c9fe 100644
--- a/exec.c
+++ b/exec.c
@@ -797,7 +797,7 @@ int cpu_watchpoint_insert_with_ref(CPUState *cpu, vaddr 
addr, vaddr len,
 }
 
 /* Find old watchpoint */
-if (ref != WP_NOREF) {
+if (ref != BPWP_NOREF) {
 wp = cpu_watchpoint_get_by_ref(cpu, ref);
 }
 
@@ -830,7 +830,7 @@ int cpu_watchpoint_insert_with_ref(CPUState *cpu, vaddr 
addr, vaddr len,
 
 int cpu_watchpoint_insert(CPUState *cpu, vaddr addr, vaddr len, int flags)
 {
-return cpu_watchpoint_insert_with_ref(cpu, addr, len, flags, WP_NOREF);
+return cpu_watchpoint_insert_with_ref(cpu, addr, len, flags, BPWP_NOREF);
 }
 
 static void cpu_watchpoint_delete(CPUState *cpu, int index)
@@ -921,10 +921,20 @@ static inline bool 
cpu_watchpoint_address_matches(CPUWatchpoint *wp,
 }
 
 #endif
+/* Find watchpoint with external reference */
+CPUBreakpoint *cpu_breakpoint_get_by_ref(CPUState *cpu, int ref)
+{
+CPUBreakpoint *bp = NULL;
+int i = 0;
+do {
+bp = g_array_index(cpu->breakpoints, CPUBreakpoint *, i++);
+} while (bp && bp->ref != ref);
+
+return bp;
+}
 
 /* Add a breakpoint.  */
-int cpu_breakpoint_insert(CPUState *cpu, vaddr pc, int flags,
-  CPUBreakpoint **breakpoint)
+int cpu_breakpoint_insert_with_ref(CPUState *cpu, vaddr pc, int flags, int ref)
 {
 CPUBreakpoint *bp;
 
@@ -933,76 +943,102 @@ int cpu_breakpoint_insert(CPUState *cpu, vaddr pc, int 
flags,
 cpu->breakpoints = g_array_new(false, false, sizeof(CPUBreakpoint *));
 }
 
-bp = g_malloc(sizeof(*bp));
-
-bp->pc = pc;
-bp->flags = flags;
+/* Find old watchpoint */
+if (ref != BPWP_NOREF) {
+bp = cpu_breakpoint_get_by_ref(cpu, ref);
+}
 
-/* keep all GDB-injected breakpoints in front */
-if (flags & BP_GDB) {
-g_array_prepend_val(cpu->breakpoints, bp);
+if (bp) {
+bp->pc = pc;
+bp->flags = flags;
+bp->ref = ref;
 } else {
-g_array_append_val(cpu->breakpoints, bp);
+bp = g_malloc(sizeof(*bp));
+
+bp->pc = pc;
+bp->flags = flags;
+bp->ref = ref;
+
+/* keep all GDB-injected breakpoints in front */
+if (flags & BP_GDB) {
+g_array_prepend_val(cpu->breakpoints, bp);
+} else {
+g_array_append_val(cpu->breakpoints, bp);
+}
 }
 
 breakpoint_invalidate(cpu, pc);
 
-if (breakpoint) {
-*breakpoint = bp;
-}
 return 0;
 }
 
+int cpu_breakpoint_insert(CPUState *cpu, vaddr pc, int flags)
+{
+return cpu_breakpoint_insert_with_ref(cpu, pc, flags, BPWP_NOREF);
+}
+
+static void cpu_breakpoint_delete(CPUState *cpu, int index)
+{
+CPUBreakpoint *bp;
+bp = g_array_index(cpu->breakpoints, CPUBreakpoint *, index);
+g_array_remove_index(cpu->breakpoints, index);
+breakpoint_invalidate(cpu, bp->pc);
+g_free(bp);
+}
+
 /* Remove a specific breakpoint.  */
 int cpu_breakpoint_remove(CPUState *cpu, vaddr pc, int flags)
 {
 CPUBreakpoint *bp;
-int i;
 
-g_assert(cpu->breakpoints);
-
-for (i = 0; i < cpu->breakpoints->len; i++) {
-bp = g_array_index(cpu->breakpoints, CPUBreakpoint *, i);
-if (bp->pc == pc && bp->flags == flags) {
-cpu_breakpoint_remove_by_ref(cpu, bp);
-return 0;
-}
+if (unlikely(cpu->breakpoints) && unlikely(cpu->breakpoints->len)) {
+int i = 0;
+do {
+bp = g_array_index(cpu->breakpoints, CPUBreakpoint *, i);
+if (bp && bp->pc == pc && bp->flags == flags) {
+cpu_breakpoint_delete(cpu, i);
+} else {
+i++;
+}
+} while (i < cpu->breakpoints->len);
 }
+
 return -ENOENT;
 }
 
 /* Remove a specific breakpoint by reference.  */
-void cpu_breakpoint_remove_by_ref(CPUState *cpu, CPUBreakpoint *breakpoint)
+void cpu_breakpoint_remove_by_ref(CPUState *cpu, int ref)
 {
 CPUBreakpoint *bp;
-int i;
 
-for (i = 0; 

[Qemu-devel] [RFC 7/7] watchpoints: put watchpoints under RCU control

2016-06-17 Thread Alex Bennée
Each time watchpoints are added/removed from the array it's done using
an read-copy-update cycle. Simultaneous writes are protected by the
debug_update_lock.

Signed-off-by: Alex Bennée 
---
 cpu-exec.c |   7 ++-
 exec.c | 193 -
 2 files changed, 144 insertions(+), 56 deletions(-)

diff --git a/cpu-exec.c b/cpu-exec.c
index 2736a27..7fcb500 100644
--- a/cpu-exec.c
+++ b/cpu-exec.c
@@ -387,12 +387,13 @@ static inline bool cpu_handle_halt(CPUState *cpu)
 static inline void cpu_handle_debug_exception(CPUState *cpu)
 {
 CPUClass *cc = CPU_GET_CLASS(cpu);
+GArray *wpts = atomic_rcu_read(>watchpoints);
 CPUWatchpoint *wp;
 int i;
 
-if (!cpu->watchpoint_hit && cpu->watchpoints) {
-for (i = 0; i < cpu->watchpoints->len; i++) {
-wp = _array_index(cpu->watchpoints, CPUWatchpoint, i);
+if (!cpu->watchpoint_hit && wpts) {
+for (i = 0; i < wpts->len; i++) {
+wp = _array_index(wpts, CPUWatchpoint, i);
 wp->flags &= ~BP_WATCHPOINT_HIT;
 }
 }
diff --git a/exec.c b/exec.c
index d1d14c1..b9167ec 100644
--- a/exec.c
+++ b/exec.c
@@ -735,6 +735,18 @@ static void breakpoint_invalidate(CPUState *cpu, 
target_ulong pc)
 }
 #endif
 
+struct FreeDebugRCU {
+struct rcu_head rcu;
+GArray *debug;
+};
+
+/* RCU reclaim step */
+static void rcu_debug_free(struct FreeDebugRCU *rcu_free)
+{
+g_array_free(rcu_free->debug, false);
+g_free(rcu_free);
+}
+
 #if defined(CONFIG_USER_ONLY)
 void cpu_watchpoint_remove_all(CPUState *cpu, int mask)
 
@@ -766,22 +778,72 @@ CPUWatchpoint *cpu_watchpoint_get_by_ref(CPUState *cpu, 
int ref)
 return NULL;
 }
 #else
-/* Find watchpoint with external reference */
-CPUWatchpoint *cpu_watchpoint_get_by_ref(CPUState *cpu, int ref)
+/* Create a working copy of the watchpoints.
+ *
+ * The rcu_read_lock() may already be held depending on where this
+ * update has been triggered from. However it is safe to nest
+ * rcu_read_locks() so we do the copy under the lock here.
+ */
+
+static GArray *rcu_copy_watchpoints(CPUState *cpu)
 {
-CPUWatchpoint *wp = NULL;
+GArray *old, *new;
+
+rcu_read_lock();
+old = atomic_rcu_read(>watchpoints);
+if (old) {
+new = g_array_sized_new(false, false, sizeof(CPUWatchpoint), old->len);
+memcpy(new->data, old->data, old->len * sizeof(CPUWatchpoint));
+new->len = old->len;
+} else {
+new = g_array_new(false, false, sizeof(CPUWatchpoint));
+}
+rcu_read_unlock();
+
+return new;
+}
+
+/* Called with update lock held */
+static void rcu_update_watchpoints(CPUState *cpu, GArray *new_watchpts)
+{
+GArray *wpts = atomic_rcu_read(>watchpoints);
+atomic_rcu_set(>watchpoints, new_watchpts);
+if (wpts) {
+struct FreeDebugRCU *rcu_free = g_malloc(sizeof(*rcu_free));
+rcu_free->debug = wpts;
+call_rcu(rcu_free, rcu_debug_free, rcu);
+}
+}
+
+/* Find watchpoint with external reference, only valid for duration of
+ * rcu_read_lock */
+static CPUWatchpoint *find_watch_with_ref(GArray *wpts, int ref)
+{
+CPUWatchpoint *wp;
 int i = 0;
+
 do {
-wp = _array_index(cpu->watchpoints, CPUWatchpoint, i++);
-} while (i < cpu->watchpoints->len && wp && wp->ref != ref);
+wp = _array_index(wpts, CPUWatchpoint, i);
+if (wp->ref == ref) {
+return wp;
+}
+} while (i++ < wpts->len);
+
+return NULL;
+}
 
-return wp;
+/* Find watchpoint with external reference */
+CPUWatchpoint *cpu_watchpoint_get_by_ref(CPUState *cpu, int ref)
+{
+GArray *wpts = atomic_rcu_read(>watchpoints);
+return find_watch_with_ref(wpts, ref);
 }
 
 /* Add a watchpoint.  */
 int cpu_watchpoint_insert_with_ref(CPUState *cpu, vaddr addr, vaddr len,
int flags, int ref)
 {
+GArray *wpts;
 CPUWatchpoint *wp = NULL;
 
 /* forbid ranges which are empty or run off the end of the address space */
@@ -791,14 +853,14 @@ int cpu_watchpoint_insert_with_ref(CPUState *cpu, vaddr 
addr, vaddr len,
 return -EINVAL;
 }
 
-/* Allocate if no previous watchpoints */
-if (!cpu->watchpoints) {
-cpu->watchpoints = g_array_new(false, true, sizeof(CPUWatchpoint));
-}
+qemu_mutex_lock(>update_debug_lock);
+
+/* This will allocate if no previous breakpoints */
+wpts = rcu_copy_watchpoints(cpu);
 
 /* Find old watchpoint */
 if (ref != BPWP_NOREF) {
-wp = cpu_watchpoint_get_by_ref(cpu, ref);
+wp = find_watch_with_ref(wpts, ref);
 }
 
 if (wp) {
@@ -815,15 +877,18 @@ int cpu_watchpoint_insert_with_ref(CPUState *cpu, vaddr 
addr, vaddr len,
 
 /* keep all GDB-injected watchpoints in front */
 if (flags & BP_GDB) {
-g_array_prepend_val(cpu->watchpoints, watch);
+g_array_prepend_val(wpts, watch);
 } else {
-

Re: [Qemu-devel] [PATCH] oslib-posix: New qemu_alloc_stack() to allocate stack with correct perms

2016-06-17 Thread Richard Henderson
On 06/17/2016 09:36 AM, Peter Maydell wrote:
> On 17 June 2016 at 17:12, Richard Henderson  wrote:
>> What about using dl_iterate_phdr, looking for PT_GNU_STACK?
>> That interface is present on a few other hosts besides Linux.
> 
> We could do that. I note that the MIPS kernel is buggy in that
> it will assume the stack is executable even if the binary
> has PT_GNU_STACK saying "please don't be executable". And
> most architectures except x86-64 won't honour PT_GNU_STACK=non-exec
> unless the parent process also had nonexec stack (because they
> let the READ_IMPLIES_EXEC personality flag be inherited; see
> https://insights.sei.cmu.edu/cert/2014/02/feeling-insecure-blame-your-parent.html
> ). So the PT_GNU_STACK flag doesn't necessarily match up with
> either the actual executability of the standard stack or with
> what the kernel actually requires.

How bizarre.

Glibc will most definitely honour PT_GNU_STACK when allocating thread stacks,
so it's a weird thing for the kernel to want to inherit for the initial thread
stack.

>> But really this is a place that I'd much rather fall back to an ifdef ladder
>> than assume executable permission is required.
> 
> The trouble with this is that it means that as and when the MIPS
> folks fix their kernel and libc and compiler to support non-exec
> stacks we won't automatically pick this up, and our stacks will
> remain executable. Also it requires us to audit every architecture
> to find out which ones require exec-stack. But maybe it is just
> MIPS? (Maybe we could just say "this is a MIPS kernel bug" ? :-))

I am inclined to hope that this is just a mips thing.
It's a pretty strange situation.

But I did really mean fall back.  Yes, try the other methods, but if we don't
detect anything about the stack, only enable it via ifdef ladder.


r~



[Qemu-devel] [PATCHv1] rtl8139: save/load RxMulOk counter (again)

2016-06-17 Thread David Vrabel
Commit 9d29cdeaaca3a0383af764000b71492c4fc67c6e (rtl8139: port
TallyCounters to vmstate) introduced in incompatibility in the v4
format as it omitted the RxOkMul counter.

There are presumably no users that were impacted by the v4 to v4'
breakage, so increase the save version to 5 and re-add the field,
keeping backward compatibility with v4'.

Signed-off-by: David Vrabel 
---
 hw/net/rtl8139.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/hw/net/rtl8139.c b/hw/net/rtl8139.c
index 562c1fd..243dcd4 100644
--- a/hw/net/rtl8139.c
+++ b/hw/net/rtl8139.c
@@ -1369,6 +1369,7 @@ static const VMStateDescription vmstate_tally_counters = {
 VMSTATE_UINT32(TxMCol, RTL8139TallyCounters),
 VMSTATE_UINT64(RxOkPhy, RTL8139TallyCounters),
 VMSTATE_UINT64(RxOkBrd, RTL8139TallyCounters),
+VMSTATE_UINT32_V(RxOkMul, RTL8139TallyCounters, 5),
 VMSTATE_UINT16(TxAbt, RTL8139TallyCounters),
 VMSTATE_UINT16(TxUndrn, RTL8139TallyCounters),
 VMSTATE_END_OF_LIST()
@@ -3222,7 +3223,7 @@ static void rtl8139_pre_save(void *opaque)
 
 static const VMStateDescription vmstate_rtl8139 = {
 .name = "rtl8139",
-.version_id = 4,
+.version_id = 5,
 .minimum_version_id = 3,
 .post_load = rtl8139_post_load,
 .pre_save  = rtl8139_pre_save,
-- 
2.1.4




Re: [Qemu-devel] [PATCH] hw/arm/virt: Reject gic-version=host for non-KVM

2016-06-17 Thread Richard W.M. Jones
On Fri, Jun 17, 2016 at 05:31:20PM +0100, Peter Maydell wrote:
> On 17 June 2016 at 17:10, Richard W.M. Jones  wrote:
> > On Fri, Jun 17, 2016 at 03:49:38PM +0100, Peter Maydell wrote:
> >> > I agree that we really need to do better here (thinking about
> >> > the problem is on my todo list but generally other more pressing
> >> > issues intervene). I'd welcome suggestions for semantics which
> >> > (a) do what you want (b) are reasonably in line with what we do
> >> > on other host architectures (c) don't break existing command lines.
> >> > (I think those are the main requirements.)
> >>
> >> ...so does anybody have any concrete suggestions? We could fix
> >> this for 2.7 but we're starting to run low on time for that.
> >
> > I have changed libguestfs so it tries to guess if KVM will be used or
> > not.  We have to do this for the -cpu option too, but the guess is not
> > too reliable.  Only QEMU has the actual knowledge we need.
> >
> > https://github.com/libguestfs/libguestfs/commit/7023f20830a681ef36f8f99415fe41791555a3db
> >
> > Can we not have a "give me a GIC which will work" option, eg.
> >
> >   -M virt,gic-version=besteffort,accel=kvm:tcg
> >
> > I don't care if it's not the fastest or most featureful.
> 
> Do we also not care if the result is not consistent
> between versions of QEMU? (eg if you go from 2.6 to
> 2.7 does it have to stay doing the same thing it
> always did?)

For libguestfs, no, since we don't do any migration or saving the
state of the VM.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW



Re: [Qemu-devel] [PATCH] hw/arm/virt: Reject gic-version=host for non-KVM

2016-06-17 Thread Peter Maydell
On 17 June 2016 at 17:10, Richard W.M. Jones  wrote:
> On Fri, Jun 17, 2016 at 03:49:38PM +0100, Peter Maydell wrote:
>> > I agree that we really need to do better here (thinking about
>> > the problem is on my todo list but generally other more pressing
>> > issues intervene). I'd welcome suggestions for semantics which
>> > (a) do what you want (b) are reasonably in line with what we do
>> > on other host architectures (c) don't break existing command lines.
>> > (I think those are the main requirements.)
>>
>> ...so does anybody have any concrete suggestions? We could fix
>> this for 2.7 but we're starting to run low on time for that.
>
> I have changed libguestfs so it tries to guess if KVM will be used or
> not.  We have to do this for the -cpu option too, but the guess is not
> too reliable.  Only QEMU has the actual knowledge we need.
>
> https://github.com/libguestfs/libguestfs/commit/7023f20830a681ef36f8f99415fe41791555a3db
>
> Can we not have a "give me a GIC which will work" option, eg.
>
>   -M virt,gic-version=besteffort,accel=kvm:tcg
>
> I don't care if it's not the fastest or most featureful.

Do we also not care if the result is not consistent
between versions of QEMU? (eg if you go from 2.6 to
2.7 does it have to stay doing the same thing it
always did?)

thanks
-- PMM



Re: [Qemu-devel] [RFC] target-arm: fix semihosting ram base issue

2016-06-17 Thread Liviu Ionescu

> On 17 Jun 2016, at 05:37, Tsung-Han Lin  wrote:
> 
> Hi, I made some changes to TRY TO fix the ARM semihosting issue ...
> This problem has been bothering me for quite a while.

semihosting was the first thing I fixed in GNU ARM Eclipse QEMU, and since then 
I use it constantly.

I don't know if this addresses your problem, but perhaps you could also take a 
look there.


regards,

Liviu




Re: [Qemu-devel] [RFC 0/7] Safe watch and breakpoint manipulation

2016-06-17 Thread Paolo Bonzini


On 17/06/2016 18:33, Alex Bennée wrote:
> First we move the break/watchpoints into an array which is more
> amenable to RCU control that the QLIST. We then control the life time
> of references to break/watchpoint data by removing long held
> references in the target code and getting information when needed from
> the core. Then we stop dynamically allocation the watch/breakpoint
> data and store it directly in the array which makes iteration across
> the list a bit more cache friendly than referenced pointers. Finally
> addition and removal of elements of the array is put under RCU
> control. This ensures there is always a safe array of data to check
> in the run-loop.

I'm not sure why you say that arrays are more amenable than QTAILQ
(though indeed include/qemu/rcu_queue.h only includes QLIST for now),
but I feel bad asking you to redo all the work...

Paolo



Re: [Qemu-devel] [PATCH] alpha: Fix build error for linux-user

2016-06-17 Thread Pranith Kumar
On Thu, Jun 16, 2016 at 8:43 PM, Laurent Vivier  wrote:
>
>
> Le 16/06/2016 à 21:15, Pranith Kumar a écrit :
>> On Thu, Jun 16, 2016 at 3:07 PM, Richard Henderson  wrote:
>>> On 06/16/2016 11:56 AM, Pranith Kumar wrote:
 Using gcc 6.1 for alpha-linux-user target we see the following build
 error:

 /mnt/devops/code/qemu/target-alpha/translate.c: In function ‘in_superpage’:
 /mnt/devops/code/qemu/target-alpha/translate.c:454:52: error: 
 self-comparison always evaluates to true [-Werror=tautological-compare]
  && addr >> TARGET_VIRT_ADDR_SPACE_BITS == addr >> 63);

 Fix it by replacing (addr >> 63) by '1' which is what it evaluates to
 since addr is negative.

 Signed-off-by: Pranith Kumar 
 ---
  target-alpha/translate.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/target-alpha/translate.c b/target-alpha/translate.c
 index f9b2426..31da6ea 100644
 --- a/target-alpha/translate.c
 +++ b/target-alpha/translate.c
 @@ -451,7 +451,7 @@ static bool in_superpage(DisasContext *ctx, int64_t 
 addr)
  return ((ctx->tb->flags & TB_FLAGS_USER_MODE) == 0
  && addr < 0
  && ((addr >> 41) & 3) == 2
 -&& addr >> TARGET_VIRT_ADDR_SPACE_BITS == addr >> 63);
 +&& addr >> TARGET_VIRT_ADDR_SPACE_BITS == 1);
  }
>>>
>>> This fix is incorrect.
>>>
>>>   (1) addr is not always negative.
>>>   (2) in_superpage is only relevant for alpha-softmmu, where
>>>   TARGET_VIRT_ADDR_SPACE_BITS is not 63.
>>
>> If you see line 2 of the condition you check for (addr < 0). Only if
>> this evaluates to true do you check the right shift value of addr.
>>
>> Reg. (2), I think that is what gcc is erroring out for.
>> TARGET_VIRT_ADDR_SPACE_BITS is 63 for linux-user and we are comparing
>> (addr >> 63) with itself. GCC rightly says that it is a tautological
>> compare and errors out. May be we can have a better work around.
>
> Perhaps something like:
>
> #ifndef CONFIG_USER_ONLY
> static bool in_superpage(DisasContext *ctx, int64_t addr)
> {
> ...
> }
> #endif
> ...
>
> #ifdef CONFIG_USER_ONLY
> pc_mask = ~TARGET_PAGE_MASK;
> #else
> if (in_superpage(, pc_start)) {
> pc_mask = (1ULL << 41) - 1;
> } else {
>pc_mask = ~TARGET_PAGE_MASK;
> }
> #endif
>

OK, I will use this.

Thanks!
-- 
Pranith



Re: [Qemu-devel] [PATCH 4/5] x86: Allow physical address bits to be set

2016-06-17 Thread Laszlo Ersek
On 06/17/16 13:20, Gerd Hoffmann wrote:
>   Hi,
> 
>>> Not sure whenever qemu adds some extra space for hotplug to the 64bit
>>> hole and if so how it calculates the size then.  But the guest os should
>>> stick to those ranges when configuring hotplugged devices.
> 
>> currently firmware would assign 64-bit BARs after reserved-memory-end
>> (not sure about ovmf though)
> 
> Ah, right, reserved-memory-end is checked too if present.  Both seabios
> and ovmf should do that.

OVMF does that, yes.

> 
>> but QEMU on ACPI side will add 64-bit _CRS only
>> for firmware mapped devices (i.e. no space reserved for hotplug).
> 
> Yes.  Tested meanwhile, looks like this (seabios):
> 
> 1-17fff : System RAM
> 18000-1c1ff : PCI Bus :00
>   18000-1bfff : :00:0f.0
>   1c000-1c07f : PCI Bus :04
> 1c000-1c07f : :04:00.0
>   1c000-1c07f : virtio-pci
>   1c080-1c0ff : PCI Bus :03
> 1c080-1c0ff : :03:00.0
>   1c080-1c0ff : virtio-pci
>   1c100-1c17f : PCI Bus :02
> 1c100-1c17f : :02:00.0
>   1c100-1c17f : virtio-pci
>   1c180-1c19f : PCI Bus :08
>   1c1a0-1c1bf : PCI Bus :07
>   1c1c0-1c1df : PCI Bus :06
>   1c1e0-1c1ff : PCI Bus :05

(This is from /proc/iomem in the guest, right? A note about this later.)

> seabios assigns a 2M memory window to pci bridges (which support
> hotplug) even in case no device is connected, so there is some space for
> hotplug because of that.
> 
> /me should try the same with ovmf ...

The generic PCI bus driver in edk2 (PciBusDxe), which is built into
OVMF, does not allocate IO and/or MMIO for a bridge if there are zero
devices behind the bridge that consume that kind of resource. I actually
consider this a feature, not a bug, because it helps avoid the
exhaustion of the limited IO port space.

In any case, /proc/iomem is not a good tool for investigating resources
assigned by the firmware. Linux is stubborn and will *itself* allocate
IO port ranges for bridges, for example, when OVMF -- justifiedly, see
above -- did no such thing. Marcel suggested to prevent this with
various bridge registers, and Paolo suggested to modify Linux's
behavior. Either way, what you see in /proc/iomem is not the
unadulterated effect of the firmware.

In OVMF's case, the resource map for every bridge / device can be seen
in the OVMF debug log, searching for the string "resource map"
(case-insensitively).

Regarding PCIe hotplug, it seemed to work under OVMF, after we fixed
 with Marcel's crucial help.

OVMF inherits the PcdPciBusHotplugDeviceSupport=TRUE build-time feature
flag from "MdeModulePkg/MdeModulePkg.dec":

  ## Indicates if PciBus driver supports the hot plug device.
  #   TRUE  - PciBus driver supports the hot plug device.
  #   FALSE - PciBus driver doesn't support the hot plug device.
  # @Prompt Enable PciBus hot plug device support.

gEfiMdeModulePkgTokenSpaceGuid.PcdPciBusHotplugDeviceSupport|TRUE|BOOLEAN|0x0001003d

I've never checked how exactly that knob affects PciBusDxe, but it's
TRUE in OVMF.

Thanks
Laszlo



Re: [Qemu-devel] [Xen-devel] [PATCH v2] xen: fix qdisk BLKIF_OP_DISCARD for 32/64 word size mix

2016-06-17 Thread Stefano Stabellini
On Fri, 17 Jun 2016, Paul Durrant wrote:
> > -Original Message-
> > From: Juergen Gross [mailto:jgr...@suse.com]
> > Sent: 17 June 2016 11:40
> > To: Paul Durrant; Jan Beulich
> > Cc: Anthony Perard; xen-devel; sstabell...@kernel.org; qemu-
> > de...@nongnu.org; kra...@redhat.com
> > Subject: Re: [Xen-devel] [PATCH v2] xen: fix qdisk BLKIF_OP_DISCARD for
> > 32/64 word size mix
> > 
> > On 17/06/16 12:15, Paul Durrant wrote:
> > >> -Original Message-
> > >> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of
> > >> Juergen Gross
> > >> Sent: 17 June 2016 11:08
> > >> To: Paul Durrant; Jan Beulich
> > >> Cc: Anthony Perard; xen-devel; sstabell...@kernel.org; qemu-
> > >> de...@nongnu.org; kra...@redhat.com
> > >> Subject: Re: [Xen-devel] [PATCH v2] xen: fix qdisk BLKIF_OP_DISCARD for
> > >> 32/64 word size mix
> > >>
> > >> On 17/06/16 11:50, Paul Durrant wrote:
> >  -Original Message-
> >  From: Juergen Gross [mailto:jgr...@suse.com]
> >  Sent: 17 June 2016 10:46
> >  To: Paul Durrant; Jan Beulich
> >  Cc: Anthony Perard; xen-devel; sstabell...@kernel.org; qemu-
> >  de...@nongnu.org; kra...@redhat.com
> >  Subject: Re: [Xen-devel] [PATCH v2] xen: fix qdisk BLKIF_OP_DISCARD
> > for
> >  32/64 word size mix
> > 
> >  On 17/06/16 11:37, Paul Durrant wrote:
> > >> -Original Message-
> > >> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On
> > Behalf
> > >> Of
> >  Jan
> > >> Beulich
> > >> Sent: 17 June 2016 10:26
> > >> To: Juergen Gross
> > >> Cc: Anthony Perard; xen-devel; sstabell...@kernel.org; qemu-
> > >> de...@nongnu.org; kra...@redhat.com
> > >> Subject: Re: [Xen-devel] [PATCH v2] xen: fix qdisk
> > BLKIF_OP_DISCARD
> > >> for
> > >> 32/64 word size mix
> > >>
> > > On 17.06.16 at 11:14,  wrote:
> > >>> In case the word size of the domU and qemu running the qdisk
> > >> backend
> > >>> differ BLKIF_OP_DISCARD will not work reliably, as the request
> > >>> structure in the ring have different layouts for different word 
> > >>> size.
> > >>>
> > >>> Correct this by copying the request structure in case of different
> > >>> word size element by element in the BLKIF_OP_DISCARD case, too.
> > >>>
> > >>> The easiest way to achieve this is to resync hw/block/xen_blkif.h
> > with
> > >>> its original source from the Linux kernel.
> > >>>
> > >>> Signed-off-by: Juergen Gross 
> > >>> ---
> > >>> V2: resync with Linux kernel version of hw/block/xen_blkif.h as
> > >>> suggested by Paul Durrant
> > >>
> > >> Oh, I didn't realize he suggested syncing with the Linux variant.
> > >> Why not with the canonical one? I have to admit that I particularly
> > >> dislike Linux'es strange union-izng, mainly because of it requiring
> > >> this myriad of __attribute__((__packed__)).
> > >>
> > >
> > > Yes, it's truly grotesque and such things should be blown away with
> >  extreme prejudice.
> > 
> >  Sorry, I'm confused now.
> > 
> >  Do you still mandate for the resync or not?
> > 
> >  Resyncing with elimination of all the __packed__ stuff seems not to be
> >  a proper alternative as this would require a major rework.
> > >>>
> > >>> Why? Replacing the existing horribleness with the canonical header
> > (fixed
> > >> for style) might mean a large diff but it should be functionally the 
> > >> same or
> > >> something has gone very seriously wrong. If the extra part you need is
> > not in
> > >> the canonical header then adding this as a second patch seems like a
> > >> reasonable plan.
> > >>
> > >> I think you don't realize that qemu is built using the public headers
> > >> from the Xen build environment. So there is no way to resync with the
> > >> canonical header as this isn't part of the qemu tree.
> > >>
> > >
> > > Now I'm confused... you're posting a patch to hw/block/xen_blkif.h. That's
> > in the QEMU source, right? That's not a Xen public header but is a Linux
> > mangled variant of a Xen public header. So, actually, I guess the question 
> > is
> > why can't this header just go away and QEMU use the canonical header
> > directly from Xen?
> > 
> > No, hw/block/xen_blkif.h is based on the Linux header
> > drivers/block/xen-blkback/common.h which is an add-on header to the
> > canonical-based Linux header include/xen/interface/io/blkif.h
> >
> > >> The header in question is originating from the Linux one which is an
> > >> add-on of the canonical header containing the explicit 32- and 64-bit
> > >> variants of the xenbus protocol and the conversion routines between
> > >> those.
> > >>
> > >> It would be possible to add these parts to the canonical header, but
> > >> do we really want that?
> > >>
> > >
> > > No, we shouldn't be taking Linux brokenness into the canonical header.
> > 
> > Okay, so then 

[Qemu-devel] [Bug 1429313] Re: qemu-user doesn't block target signals on entry to signal hanlder.

2016-06-17 Thread Peter Maydell
The patches to block signals on entry to the signal handler have now
been applied to master.


** Changed in: qemu
   Status: In Progress => Fix Committed

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

Title:
  qemu-user doesn't block target signals on entry to signal hanlder.

Status in QEMU:
  Fix Committed

Bug description:
  Upon entry to a target signal handler the function
  process_pending_signals in linux-user/signal.c block the appropriate
  host signals, but signals already received and queued by Qemu are not
  blocked. If multiple signals arrive in quick succession this results
  incorrect recursion in the target signal handler.

  The attached test case my be run as:

  $ (sleep 2 ; echo) | qemu-i386 ./a.out
  .. Recursion in signal handler!
  qemu: uncaught target signal 6 (Aborted) - core dumped

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



Re: [Qemu-devel] [PATCH v4 1/3] target-i386: KVM: add basic Intel LMCE support

2016-06-17 Thread Eduardo Habkost
On Fri, Jun 17, 2016 at 09:26:57AM +0800, Haozhong Zhang wrote:
[...]
> > >  static void mce_init(X86CPU *cpu)
> > >  {
> > >  CPUX86State *cenv = >env;
> > >  unsigned int bank;
> > > +Error *local_err = NULL;
> > >  
> > >  if (((cenv->cpuid_version >> 8) & 0xf) >= 6
> > >  && (cenv->features[FEAT_1_EDX] & (CPUID_MCE | CPUID_MCA)) ==
> > >  (CPUID_MCE | CPUID_MCA)) {
> > >  cenv->mcg_cap = MCE_CAP_DEF | MCE_BANKS_DEF;
> > > +
> > > +if (cpu->enable_lmce) {
> > > +if (!lmce_supported()) {
> > > +error_setg(_err, "KVM unavailable or LMCE not 
> > > supported");
> > > +error_propagate(_abort, local_err);
> > > +}
> > > +cenv->mcg_cap |= MCG_LMCE_P;
> > > +}
> > > +
> > 
> > This duplicates the existing check in kvm_arch_init_vcpu(). The
> > difference is that the existing code is KVM-specific and doesn't
> > stop initialization when capabilities are missing. We can unify
> > them into a single mcg_cap-checking function as a follow-up.
> >
> 
> If I reuse the existing MCE capability check in kvm_arch_init_vcpu(),
> is it reasonable to make change to stop initialization if missing
> capabilities? Or should we stop only for missing newly added capabilities
> (e.g. LMCE) in order to keep backwards compatibility?

Ideally, yes. But in practice we need to check if we won't break
existing setups that were working. If all kernel versions we care
about always MCG_CTL_P|MCG_SER_P + 10 banks as supported, we can
make all bits mandatory.

I need to re-read the thread were kvm_get_mce_cap_supported() was
discussed, to refresh my memory.

-- 
Eduardo



Re: [Qemu-devel] [RFC 7/7] watchpoints: put watchpoints under RCU control

2016-06-17 Thread Paolo Bonzini


On 17/06/2016 18:33, Alex Bennée wrote:
> Each time watchpoints are added/removed from the array it's done using
> an read-copy-update cycle. Simultaneous writes are protected by the
> debug_update_lock.
> 
> Signed-off-by: Alex Bennée 
> ---
>  cpu-exec.c |   7 ++-
>  exec.c | 193 
> -
>  2 files changed, 144 insertions(+), 56 deletions(-)
> 
> diff --git a/cpu-exec.c b/cpu-exec.c
> index 2736a27..7fcb500 100644
> --- a/cpu-exec.c
> +++ b/cpu-exec.c
> @@ -387,12 +387,13 @@ static inline bool cpu_handle_halt(CPUState *cpu)
>  static inline void cpu_handle_debug_exception(CPUState *cpu)
>  {
>  CPUClass *cc = CPU_GET_CLASS(cpu);
> +GArray *wpts = atomic_rcu_read(>watchpoints);
>  CPUWatchpoint *wp;
>  int i;
>  
> -if (!cpu->watchpoint_hit && cpu->watchpoints) {
> -for (i = 0; i < cpu->watchpoints->len; i++) {
> -wp = _array_index(cpu->watchpoints, CPUWatchpoint, i);
> +if (!cpu->watchpoint_hit && wpts) {
> +for (i = 0; i < wpts->len; i++) {
> +wp = _array_index(wpts, CPUWatchpoint, i);
>  wp->flags &= ~BP_WATCHPOINT_HIT;
>  }
>  }
> diff --git a/exec.c b/exec.c
> index d1d14c1..b9167ec 100644
> --- a/exec.c
> +++ b/exec.c
> @@ -735,6 +735,18 @@ static void breakpoint_invalidate(CPUState *cpu, 
> target_ulong pc)
>  }
>  #endif
>  
> +struct FreeDebugRCU {
> +struct rcu_head rcu;
> +GArray *debug;
> +};

Deja vu? ;)

> +/* RCU reclaim step */
> +static void rcu_debug_free(struct FreeDebugRCU *rcu_free)
> +{
> +g_array_free(rcu_free->debug, false);
> +g_free(rcu_free);
> +}
> +
>  #if defined(CONFIG_USER_ONLY)
>  void cpu_watchpoint_remove_all(CPUState *cpu, int mask)
>  
> @@ -766,22 +778,72 @@ CPUWatchpoint *cpu_watchpoint_get_by_ref(CPUState *cpu, 
> int ref)
>  return NULL;
>  }
>  #else
> -/* Find watchpoint with external reference */
> -CPUWatchpoint *cpu_watchpoint_get_by_ref(CPUState *cpu, int ref)
> +/* Create a working copy of the watchpoints.
> + *
> + * The rcu_read_lock() may already be held depending on where this
> + * update has been triggered from. However it is safe to nest
> + * rcu_read_locks() so we do the copy under the lock here.

Same as patch 5.

> + */
> +
> +static GArray *rcu_copy_watchpoints(CPUState *cpu)
>  {
> -CPUWatchpoint *wp = NULL;
> +GArray *old, *new;
> +
> +rcu_read_lock();
> +old = atomic_rcu_read(>watchpoints);
> +if (old) {
> +new = g_array_sized_new(false, false, sizeof(CPUWatchpoint), 
> old->len);
> +memcpy(new->data, old->data, old->len * sizeof(CPUWatchpoint));
> +new->len = old->len;
> +} else {
> +new = g_array_new(false, false, sizeof(CPUWatchpoint));
> +}
> +rcu_read_unlock();
> +
> +return new;
> +}
> +
> +/* Called with update lock held */
> +static void rcu_update_watchpoints(CPUState *cpu, GArray *new_watchpts)
> +{
> +GArray *wpts = atomic_rcu_read(>watchpoints);
> +atomic_rcu_set(>watchpoints, new_watchpts);
> +if (wpts) {
> +struct FreeDebugRCU *rcu_free = g_malloc(sizeof(*rcu_free));
> +rcu_free->debug = wpts;
> +call_rcu(rcu_free, rcu_debug_free, rcu);
> +}
> +}
> +
> +/* Find watchpoint with external reference, only valid for duration of
> + * rcu_read_lock */
> +static CPUWatchpoint *find_watch_with_ref(GArray *wpts, int ref)

watchpoint_get_by_ref.

BTW, should the "ref" be unsigned?

> +{
> +CPUWatchpoint *wp;
>  int i = 0;
> +
>  do {
> -wp = _array_index(cpu->watchpoints, CPUWatchpoint, i++);
> -} while (i < cpu->watchpoints->len && wp && wp->ref != ref);
> +wp = _array_index(wpts, CPUWatchpoint, i);
> +if (wp->ref == ref) {
> +return wp;
> +}
> +} while (i++ < wpts->len);
> +
> +return NULL;
> +}
>  
> -return wp;
> +/* Find watchpoint with external reference */
> +CPUWatchpoint *cpu_watchpoint_get_by_ref(CPUState *cpu, int ref)
> +{
> +GArray *wpts = atomic_rcu_read(>watchpoints);
> +return find_watch_with_ref(wpts, ref);
>  }
>  
>  /* Add a watchpoint.  */
>  int cpu_watchpoint_insert_with_ref(CPUState *cpu, vaddr addr, vaddr len,
> int flags, int ref)
>  {
> +GArray *wpts;
>  CPUWatchpoint *wp = NULL;
>  
>  /* forbid ranges which are empty or run off the end of the address space 
> */
> @@ -791,14 +853,14 @@ int cpu_watchpoint_insert_with_ref(CPUState *cpu, vaddr 
> addr, vaddr len,
>  return -EINVAL;
>  }
>  
> -/* Allocate if no previous watchpoints */
> -if (!cpu->watchpoints) {
> -cpu->watchpoints = g_array_new(false, true, sizeof(CPUWatchpoint));
> -}
> +qemu_mutex_lock(>update_debug_lock);
> +
> +/* This will allocate if no previous breakpoints */
^^^

watchpoints

> +wpts = rcu_copy_watchpoints(cpu);

In 

Re: [Qemu-devel] [Xen-devel] [PATCH] xen: fix qdisk BLKIF_OP_DISCARD for 32/64 word size mix

2016-06-17 Thread Stefano Stabellini
On Thu, 16 Jun 2016, Juergen Gross wrote:
> On 16/06/16 15:07, Stefano Stabellini wrote:
> > On Thu, 16 Jun 2016, Juergen Gross wrote:
> >> On 16/06/16 12:54, Jan Beulich wrote:
> >> On 16.06.16 at 12:02,  wrote:
>  In case the word size of the domU and qemu running the qdisk backend
>  differ BLKIF_OP_DISCARD will not work reliably, as the request
>  structure in the ring have different layouts for different word size.
> 
>  Correct this by copying the request structure in case of different
>  word size element by element in the BLKIF_OP_DISCARD case, too.
> 
>  Signed-off-by: Juergen Gross 
> >>>
> >>> With the indentation (tabs vs blanks) fixed
> >>
> >> Hmm, qemu coding style is to use blanks. I could:
> >> a) leave the patch as is (changed lines indented with blanks)
> >> b) use tabs to indent (style of the modified file up to now)
> >> c) change the style of the file in this patch
> >> d) change the style of the file in a separate patch
> >>
> >> Any preferences?
> > 
> > I would go with d), fixing it to conform with QEMU coding style.
> 
> As I'm about to resync the header with the Linux one as Paul suggested
> it will be more like c). :-)
 
That's not a good idea, as you probably have noticed by now on the other
thread. This patch is OK, you just need to fix the intendation
separately.



[Qemu-devel] [RFC 6/7] linux-user: don't clone watchpoints

2016-06-17 Thread Alex Bennée
The watchpoint code is stubbed out for CONFIG_USER_ONLY so there is no
point attempting to copy the data here. Lets remove the code before the
RCU protection goes in.

Signed-off-by: Alex Bennée 
---
 linux-user/main.c | 8 
 1 file changed, 8 deletions(-)

diff --git a/linux-user/main.c b/linux-user/main.c
index 2901626..9a5d017 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -3812,14 +3812,6 @@ CPUArchState *cpu_copy(CPUArchState *env)
Note: Once we support ptrace with hw-debug register access, make sure
BP_CPU break/watchpoints are handled correctly on clone. */
 cpu_breakpoints_clone(cpu, new_cpu);
-if (unlikely(cpu->watchpoints) && unlikely(cpu->watchpoints->len)) {
-CPUWatchpoint *wp;
-int i;
-for (i = 0; i < cpu->watchpoints->len; i++) {
-wp = _array_index(cpu->watchpoints, CPUWatchpoint, i);
-cpu_watchpoint_insert(new_cpu, wp->vaddr, wp->len, wp->flags);
-}
-}
 
 return new_env;
 }
-- 
2.7.4




Re: [Qemu-devel] [PATCH] oslib-posix: New qemu_alloc_stack() to allocate stack with correct perms

2016-06-17 Thread Richard Henderson
On 06/17/2016 07:11 AM, Peter Maydell wrote:
> Some architectures require the stack to be executable; notably
> this includes MIPS, because the kernel's floating point emulator
> may try to put trampoline code on the stack to handle some cases.
> (See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815409
> for an example of this causing QEMU to crash.)
> 
> Create a utility function qemu_alloc_stack() which allocates a
> block of memory for use as a stack with the correct permissions.
> Since we would prefer to make the stack non-executable if we can
> as a defence against code execution exploits, we detect whether
> the existing stack is mapped executable. Unfortunately this
> requires us to grovel through /proc/self/maps to determine the
> permissions on it.
> 
> Signed-off-by: Peter Maydell 
> ---
> This method of figuring out the correct perms for the stack is
> not exactly pretty; better suggestions welcome.
> 
> NB that this utility function also gives us a handy place to put
> code for allocating a guard page at the bottom of the stack, or
> mapping it as MAP_GROWSDOWN, or whatever.
...
> +/* Some architectures (notably MIPS) require an executable stack, but
> + * we would prefer to avoid making the stack executable unnecessarily,
> + * to defend against code execution exploits.
> + * Check whether the current stack is executable, and follow its lead.
> + * Unfortunately to do this we have to wade through /proc/self/maps
> + * looking for the stack memory. We default to assuming we need an
> + * executable stack and remove the permission only if we can successfully
> + * confirm that non-executable is OK.
> + */
> +
> +prot = PROT_READ | PROT_WRITE | PROT_EXEC;
...
> +#else
> +static int stack_prot(void)
> +{
> +/* Assume an executable stack is needed, since we can't detect it. */
> +return PROT_READ | PROT_WRITE | PROT_EXEC;
> +}
> +#endif


What about using dl_iterate_phdr, looking for PT_GNU_STACK?
That interface is present on a few other hosts besides Linux.

But really this is a place that I'd much rather fall back to an ifdef ladder
than assume executable permission is required.


r~



Re: [Qemu-devel] [RFC 1/7] cpu: move break/watchpoints into arrays.

2016-06-17 Thread Paolo Bonzini


On 17/06/2016 18:33, Alex Bennée wrote:
> Before we can protect the lists we need a structure a little more
> amenable to RCU protection. This moves all the lists into a re-sizeable
> array. The array still only points to allocated structures because a
> number of the architectures still need to look at the results of a hit
> by examining the field.
> 
> Signed-off-by: Alex Bennée 
> ---
>  cpu-exec.c |   6 +-
>  exec.c | 167 
> ++---

Can you look into moving this to cpu-exec.c? (or cpu-exec-common.c
perhaps?)  It's TCG only, so it doesn't really belong in exec.c if we
can help it.

Paolo

>  include/qom/cpu.h  |  22 +++---
>  linux-user/main.c  |  22 +++---
>  qom/cpu.c  |   2 -
>  target-arm/translate-a64.c |   6 +-
>  target-arm/translate.c |   6 +-
>  target-i386/bpt_helper.c   |   6 +-
>  target-lm32/helper.c   |   6 +-
>  9 files changed, 157 insertions(+), 86 deletions(-)



[Qemu-devel] [virtio-dev][RFC 2/2] virtio-sdm: new device specification

2016-06-17 Thread Christian Pinto
This patch adds the specification of the Signal Dristribution Module virtio
device to the current virtio specification document.

Signed-off-by: Christian Pinto 
---
 virtio-sdm.tex | 126 +
 1 file changed, 126 insertions(+)
 create mode 100644 virtio-sdm.tex

diff --git a/virtio-sdm.tex b/virtio-sdm.tex
new file mode 100644
index 000..abbdb80
--- /dev/null
+++ b/virtio-sdm.tex
@@ -0,0 +1,126 @@
+\section{Signal Distribution Module}\label{sec:Device Types / SDM Device}
+
+The virtio Signal Distribution Module is meant to enable Inter Processor
+interrupts in QEMU/KVM environment. The SDM enables different processors in the
+same or different QEMU instances to send mutual signals. An example are Inter
+Processor Interrupts used in AMP systems, for the processors involved to notify
+the presence of new data in the communication queues.
+
+\subsection{Device ID}\label{sec:Device Types / SDM Device / Device ID}
+
+19
+
+\subsection{Virtqueues}\label{sec:Device Types / SDM Device / Virtqueues}
+
+\begin{description}
+\item[0] hg_vq
+\item[1] gh_vq
+\end{description}
+
+Queue 0 is used for host-guest communication (i.e., notification of a signal),
+while queue 1 for guest-host communication.
+
+\subsection{Feature bits}\label{sec:Device Types / SDM Device / Feature bits}
+
+None.
+
+\subsection{Device configuration layout}\label{sec:Device Types / SDM Device / 
+Device configuration layout}
+
+The device configuration is composed by three fields: \texttt{master},
+\texttt{max_slaves} and \texttt{current_slaves}.
+
+\begin{lstlisting}
+struct virtio_sdm_config {
+   u8master;
+   u16   max_slaves;
+   u16   current_slaves;
+};
+\end{lstlisting}
+
+The SDM device can be instantiated either as a master or as a slave. The master
+slave behavior is meant on purpose to reflect the AMP like type of 
communication
+where a master processor controls one or more slave processors.
+A master SDM instance can send a signal to any of the slaves instances,
+while slaves can only signal the master. 
+
+The \texttt{master} field of the configuration space is meant to be read by the
+Linux driver to figure out whether a specific instance is a master or a slave.
+The \texttt{max_slaves} field contains the maximum number of slaves supported 
by
+the SDM device. 
+The value of \texttt{max_slaves} is initially set from the command line of 
QEMU,
+but can be changed during operations through the configuration space.
+Finally the \texttt{current_slaves} field contains the actual number of slaves
+registered to the master SDM. This field is a read only field. 
+
+\subsection{Device Initialization}\label{sec:Device Types / SDM Device /
+evice Initialization}
+
+During initialization the \texttt{hg_vq} and \texttt{gh_vq} are identified and
+the device is immediately operational. A master instance can access the number
+of slaves registered at any time by reading the configuration space of the
+device.
+
+During the initialization phase the device connects also to the communication
+channel that is specificied as a parameter when configuring the device. At the
+current state there are two types of communication channels: local and
+socket(TCP or UNIX).
+The local channel is meant for SDM devices attached to the same QEMU instance,
+while the network channel makes it possible to exchange signals between
+SDMs in different instances of QEMU. 
+The type of communication channel is chosen at QEMU boot time and cannot be
+changed during operations. It has to be noted that the behavior of the device 
is
+independent from the communication channel used.
+
+\subsection{Device Operation}\label{sec:Device Types / SDM Device / Device
+peration}
+
+The SDM device  handles signal coming from the two following sources:
+
+\begin{enumerate}
+\item The local processor to which the devics is attached to.
+\item The communication channel connecting to other slaves/master. 
+\end{enumerate}
+
+The first case is verified when the processor attached to the SDM device wants
+to send a signal to SDM device instance (being it the same QEMU instance or a
+separate one).
+The second case is instead when an SDM device instance receives a signal from
+another SDM device, to be forwarded to the local processor.
+It is important to note that due to the master/slave behavior, slaves cannot
+signal among themsleves but only with the master SDM instance.
+
+In both cases, before sending over the communication channel, the signal is
+packed in the \texttt{SDMSignalData} data structure.
+
+\begin{lstlisting}
+enum sdm_signal_type {
+SDM_IRQ,
+SDM_BOOT,
+};
+
+struct SDMSignalData {
+uint32_t type;
+uint32_t slave;
+uint32_t payload[2];
+};
+\end{lstlisting}
+
+The \texttt{type} field indicates the type of signal to be sent to the
+destination SDM. The current implementation supports two signal types.
+The \texttt{SDM_IRQ} signal is used to send an 

[Qemu-devel] [Bug 1318281] Re: linux-user: x86_64 target fails to call sys_futex()

2016-06-17 Thread Peter Maydell
The test program works fine with current git master, so I think we have
fixed this bug at some point in the last two years.


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

Title:
  linux-user: x86_64 target fails to call sys_futex()

Status in QEMU:
  Fix Released

Bug description:
  I'm building the latest QEMU
  (06b4f00d53637f2c16a62c2cbaa30bffb045cf88) on ARM to run some x86_64
  executables in user mode. This is my configuration:

  ./configure \
--prefix=/root/qemu-x86_64 \
--target-list=x86_64-linux-user \
--disable-system \
--disable-tools

  The following program is used for testing:

  https://gist.github.com/hujiajie/e8cff43b574b399c8f59#file-test-c

  I compile the test program in Debian-7.5-amd64 like this:

  gcc -o test `pkg-config --cflags glib-2.0` test.c `pkg-config --static
  --libs glib-2.0` -static

  and launch the program on ARM with

  qemu-x86_64 test

  The test crashes with the following message:

  qemu: uncaught target signal 11 (Segmentation fault) - core dumped
  Segmentation fault

  The output of `strace qemu-x86_64 test` is here:

  https://gist.github.com/hujiajie/88d1d5e580d432d11b2d#file-test-
  strace-log

  It seems that the error is caused by the failure of the futex syscall.

  qemu-i386 could launch the 32-bit test perfectly, the problem only
  happens on a x86_64 target.

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



Re: [Qemu-devel] [RFC 5/7] breakpoints: put breakpoints under RCU control

2016-06-17 Thread Paolo Bonzini


On 17/06/2016 18:33, Alex Bennée wrote:
> Each time breakpoints are added/removed from the array it's done using
> an read-copy-update cycle. Simultaneous writes are protected by the
> debug_update_lock.
> 
> Signed-off-by: Alex Bennée 
> ---
>  cpus.c|   3 +
>  exec.c| 167 
> --
>  include/qom/cpu.h |  42 ++
>  linux-user/main.c |  11 +---
>  4 files changed, 175 insertions(+), 48 deletions(-)
> 
> diff --git a/cpus.c b/cpus.c
> index 84c3520..b76300b 100644
> --- a/cpus.c
> +++ b/cpus.c
> @@ -1441,6 +1441,9 @@ void qemu_init_vcpu(CPUState *cpu)
>  cpu_address_space_init(cpu, as, 0);
>  }
>  
> +/* protects updates to debug info */

No need to comment here.

> +qemu_mutex_init(>update_debug_lock);

Missing qemu_mutex_destroy.

>  if (kvm_enabled()) {
>  qemu_kvm_start_vcpu(cpu);
>  } else if (tcg_enabled()) {
> diff --git a/exec.c b/exec.c
> index c8e8823..d1d14c1 100644
> --- a/exec.c
> +++ b/exec.c
> @@ -919,31 +919,94 @@ static inline bool 
> cpu_watchpoint_address_matches(CPUWatchpoint *wp,
>  }
>  
>  #endif
> -/* Find watchpoint with external reference */
> -CPUBreakpoint *cpu_breakpoint_get_by_ref(CPUState *cpu, int ref)
> +
> +/* Create a working copy of the breakpoints.
> + *
> + * The rcu_read_lock() may already be held depending on where this
> + * update has been triggered from. However it is safe to nest
> + * rcu_read_locks() so we do the copy under the lock here.

More precisely, the rcu_read_lock() and atomic_rcu_read() are
unnecessary in update paths because these already take the update lock.
However it is safe to nest rcu_read_lock() within itself or within the
update lock, so your code is fine.

> + */
> +
> +static GArray *rcu_copy_breakpoints(CPUState *cpu)
>  {
> -CPUBreakpoint *bp = NULL;
> +GArray *old, *new;
> +
> +rcu_read_lock();
> +old = atomic_rcu_read(>breakpoints);
> +if (old) {
> +new = g_array_sized_new(false, false, sizeof(CPUBreakpoint), 
> old->len);
> +memcpy(new->data, old->data, old->len * sizeof(CPUBreakpoint));
> +new->len = old->len;
> +} else {
> +new = g_array_new(false, false, sizeof(CPUBreakpoint));
> +}
> +rcu_read_unlock();
> +
> +return new;
> +}
> +
> +struct BreakRCU {

What about creating a generic g_array_free_rcu(GArray *array, gboolean
free_segment)?  Or better g_array_unref_rcu(GArray *array) since we
require glib 2.22.

> +struct rcu_head rcu;
> +GArray *bkpts;
> +};
> +
> +/* RCU reclaim step */
> +static void rcu_free_breakpoints(struct BreakRCU *rcu_free)
> +{
> +g_array_free(rcu_free->bkpts, false);

Why false?  Doesn't this leak?  (g_array_unref is another valid
replacement, as mentioned above).

> +g_free(rcu_free);
> +}
> +
> +/* Called with update lock held */
> +static void rcu_update_breakpoints(CPUState *cpu, GArray *new_bkpts)
> +{
> +GArray *bpts = atomic_rcu_read(>breakpoints);
> +atomic_rcu_set(>breakpoints, new_bkpts);
> +
> +if (bpts) {
> +struct BreakRCU *rcu_free = g_malloc(sizeof(*rcu_free));
> +rcu_free->bkpts = bpts;
> +call_rcu(rcu_free, rcu_free_breakpoints, rcu);
> +}
> +}
> +
> +/* Find watchpoint with external reference, only valid for duration of
> + * rcu_read_lock */
> +static CPUBreakpoint *find_bkpt_with_ref(GArray *bkpts, int ref)

breakpoint_get_by_ref, please.

> +{
> +CPUBreakpoint *bp;
>  int i = 0;
> +
>  do {
> -bp = _array_index(cpu->breakpoints, CPUBreakpoint, i++);
> -} while (i < cpu->breakpoints->len && bp && bp->ref != ref);
> +bp = _array_index(bkpts, CPUBreakpoint, i);
> +if (bp->ref == ref) {
> +return bp;
> +}
> +} while (i++ < bkpts->len);
>  
> -return bp;
> +return NULL;
> +}
> +
> +CPUBreakpoint *cpu_breakpoint_get_by_ref(CPUState *cpu, int ref)
> +{
> +GArray *bkpts = atomic_rcu_read(>breakpoints);
> +return find_bkpt_with_ref(bkpts, ref);
>  }
>  
>  /* Add a breakpoint.  */
>  int cpu_breakpoint_insert_with_ref(CPUState *cpu, vaddr pc, int flags, int 
> ref)
>  {
> +GArray *bkpts;
>  CPUBreakpoint *bp = NULL;
>  
> -/* Allocate if no previous breakpoints */
> -if (!cpu->breakpoints) {
> -cpu->breakpoints = g_array_new(false, true, sizeof(CPUBreakpoint));
> -}
> +qemu_mutex_lock(>update_debug_lock);
> +
> +/* This will allocate if no previous breakpoints */
> +bkpts = rcu_copy_breakpoints(cpu);
>  
>  /* Find old watchpoint */
>  if (ref != BPWP_NOREF) {
> -bp = cpu_breakpoint_get_by_ref(cpu, ref);
> +bp = find_bkpt_with_ref(bkpts, ref);
>  }
>  
>  if (bp) {
> @@ -958,14 +1021,17 @@ int cpu_breakpoint_insert_with_ref(CPUState *cpu, 
> vaddr pc, int flags, int ref)
>  
>  /* keep all GDB-injected breakpoints in front */
>  if (flags & BP_GDB) {
> -

[Qemu-devel] [RFC 2/7] exec: keep CPUWatchpoint references internal

2016-06-17 Thread Alex Bennée
In preparation for the conversion to an RCU controlled list of
watchpoints I've removed all $ARCH local copies of the watchpoint
structures. They can be accessed with cpu_watchpoint_get_by_ref() which
will eventually offer them for the lifetime of the rcu_read_lock().

Instead of using pointers as handles to architecture specific registers
they now use plain integer references.

Signed-off-by: Alex Bennée 
---
 exec.c| 121 --
 gdbstub.c |   2 +-
 include/qom/cpu.h |  63 ++--
 linux-user/main.c |   2 +-
 target-arm/cpu.h  |   1 -
 target-arm/helper.c   |  12 ++---
 target-arm/op_helper.c|   4 +-
 target-i386/bpt_helper.c  |  25 +-
 target-i386/cpu.h |   3 +-
 target-lm32/cpu.h |   1 -
 target-lm32/helper.c  |  15 ++
 target-s390x/helper.c |  10 ++--
 target-xtensa/cpu.h   |   3 --
 target-xtensa/helper.c|   4 +-
 target-xtensa/op_helper.c |  16 ++
 15 files changed, 177 insertions(+), 105 deletions(-)

diff --git a/exec.c b/exec.c
index e73c909..3dc3332 100644
--- a/exec.c
+++ b/exec.c
@@ -747,21 +747,42 @@ int cpu_watchpoint_remove(CPUState *cpu, vaddr addr, 
vaddr len,
 return -ENOSYS;
 }
 
-void cpu_watchpoint_remove_by_ref(CPUState *cpu, CPUWatchpoint *watchpoint)
+int cpu_watchpoint_remove_by_ref(CPUState *cpu, int ref)
 {
+return -ENOENT;
 }
 
-int cpu_watchpoint_insert(CPUState *cpu, vaddr addr, vaddr len,
-  int flags, CPUWatchpoint **watchpoint)
+int cpu_watchpoint_insert_with_ref(CPUState *cpu, vaddr addr, vaddr len,
+   int flags, int ref)
+{
+return -ENOSYS;
+}
+int cpu_watchpoint_insert(CPUState *cpu, vaddr addr, vaddr len, int flags)
 {
 return -ENOSYS;
 }
+CPUWatchpoint *cpu_watchpoint_get_by_ref(CPUState *cpu, int ref)
+{
+return NULL;
+}
 #else
+/* Find watchpoint with external reference */
+CPUWatchpoint *cpu_watchpoint_get_by_ref(CPUState *cpu, int ref)
+{
+CPUWatchpoint *wp = NULL;
+int i = 0;
+do {
+wp = g_array_index(cpu->watchpoints, CPUWatchpoint *, i++);
+} while (wp && wp->ref != ref);
+
+return wp;
+}
+
 /* Add a watchpoint.  */
-int cpu_watchpoint_insert(CPUState *cpu, vaddr addr, vaddr len,
-  int flags, CPUWatchpoint **watchpoint)
+int cpu_watchpoint_insert_with_ref(CPUState *cpu, vaddr addr, vaddr len,
+   int flags, int ref)
 {
-CPUWatchpoint *wp;
+CPUWatchpoint *wp = NULL;
 
 /* forbid ranges which are empty or run off the end of the address space */
 if (len == 0 || (addr + len - 1) < addr) {
@@ -772,28 +793,55 @@ int cpu_watchpoint_insert(CPUState *cpu, vaddr addr, 
vaddr len,
 
 /* Allocate if no previous watchpoints */
 if (!cpu->watchpoints) {
-cpu->watchpoints = g_array_new(false, false, sizeof(CPUWatchpoint *));
+cpu->watchpoints = g_array_new(true, false, sizeof(CPUWatchpoint *));
 }
 
-wp = g_malloc(sizeof(*wp));
-wp->vaddr = addr;
-wp->len = len;
-wp->flags = flags;
+/* Find old watchpoint */
+if (ref != WP_NOREF) {
+wp = cpu_watchpoint_get_by_ref(cpu, ref);
+}
 
-/* keep all GDB-injected watchpoints in front */
-if (flags & BP_GDB) {
-g_array_prepend_val(cpu->watchpoints, wp);
+if (wp) {
+wp->vaddr = addr;
+wp->len = len;
+wp->flags = flags;
+wp->ref = ref;
 } else {
-g_array_append_val(cpu->watchpoints, wp);
+wp = g_malloc(sizeof(*wp));
+
+wp->vaddr = addr;
+wp->len = len;
+wp->flags = flags;
+wp->ref = ref;
+
+/* keep all GDB-injected watchpoints in front */
+if (flags & BP_GDB) {
+g_array_prepend_val(cpu->watchpoints, wp);
+} else {
+g_array_append_val(cpu->watchpoints, wp);
+}
 }
 
+
 tlb_flush_page(cpu, addr);
 
-if (watchpoint)
-*watchpoint = wp;
 return 0;
 }
 
+int cpu_watchpoint_insert(CPUState *cpu, vaddr addr, vaddr len, int flags)
+{
+return cpu_watchpoint_insert_with_ref(cpu, addr, len, flags, WP_NOREF);
+}
+
+static void cpu_watchpoint_delete(CPUState *cpu, int index)
+{
+CPUWatchpoint *wp;
+wp = g_array_index(cpu->watchpoints, CPUWatchpoint *, index);
+g_array_remove_index(cpu->watchpoints, index);
+tlb_flush_page(cpu, wp->vaddr);
+g_free(wp);
+}
+
 /* Remove a specific watchpoint.  */
 int cpu_watchpoint_remove(CPUState *cpu, vaddr addr, vaddr len,
   int flags)
@@ -806,48 +854,49 @@ int cpu_watchpoint_remove(CPUState *cpu, vaddr addr, 
vaddr len,
 wp = g_array_index(cpu->watchpoints, CPUWatchpoint *, i);
 if (wp && addr == wp->vaddr && len == wp->len
 && flags == (wp->flags & ~BP_WATCHPOINT_HIT)) {
-

[Qemu-devel] [virtio-dev][RFC 0/2] Signal Distribution Module virtio device specification

2016-06-17 Thread Christian Pinto
Hi all,

This patch series proposes the specification of a new virtio device on which we
are working on, namely the Signal Distribution Module (SDM). 
The SDM routes inter-processor signals intra and inter QEMU
instances, using a user-defined communication channel. At the current state the 
SDM provides a local channel, for intra-QEMU signals, and a channel based on
sockets (UNIX or TCP) to exchange signals between processors in different
instances of QEMU. Each communication channel exports a common interface for 
the sake of ease of extension and integration of new channels.

In addition to the virtio version, a platform device version is available as
well to be used for cases where a processor is not running Linux but another
OS/firmware that does not support virtio.

This patch is related to :

[Qemu-devel][RFC v3 0/6] SDM Interface

where you can find the latest RFC patch set for the QEMU code of the virtio SDM 
device.

Kernel code is publicly accessible from:

https://git.virtualopensystems.com/dev/qemu-het-tools

branch sdm_test_virtio_mod_v2.


QEMU code is accessible from:

https://git.virtualopensystems.com/dev/qemu-het-tools

branch sdm-dev-v3

Thanks,

Christian

Christian Pinto (2):
  content: reserve virtio device ID
  virtio-sdm: new device specification

 content.tex|   4 ++
 virtio-sdm.tex | 126 +
 2 files changed, 130 insertions(+)
 create mode 100644 virtio-sdm.tex

-- 
1.9.1




Re: [Qemu-devel] [PATCH] hw/arm/virt: Reject gic-version=host for non-KVM

2016-06-17 Thread Richard W.M. Jones
On Fri, Jun 17, 2016 at 03:49:38PM +0100, Peter Maydell wrote:
> On 26 May 2016 at 15:53, Peter Maydell  wrote:
> > On 26 May 2016 at 15:46, Richard W.M. Jones  wrote:
> >> The problem with this is if I'm using TCG fallback mode, how
> >> can I specify the right gic-version?  ie:
> >>
> >>   -M virt,gic-version=host,accel=kvm:tcg
> >>
> >> Only qemu knows if KVM is going to be enabled.
> >>
> >> The same problem happens with '-cpu host' BTW.  I really want a "make
> >> it work" option, as I've said on several previous occasions on this
> >> list eg:
> >> https://lists.nongnu.org/archive/html/qemu-devel/2014-08/msg04173.html
> >
> > I agree that we really need to do better here (thinking about
> > the problem is on my todo list but generally other more pressing
> > issues intervene). I'd welcome suggestions for semantics which
> > (a) do what you want (b) are reasonably in line with what we do
> > on other host architectures (c) don't break existing command lines.
> > (I think those are the main requirements.)
> 
> ...so does anybody have any concrete suggestions? We could fix
> this for 2.7 but we're starting to run low on time for that.

I have changed libguestfs so it tries to guess if KVM will be used or
not.  We have to do this for the -cpu option too, but the guess is not
too reliable.  Only QEMU has the actual knowledge we need.

https://github.com/libguestfs/libguestfs/commit/7023f20830a681ef36f8f99415fe41791555a3db

Can we not have a "give me a GIC which will work" option, eg.

  -M virt,gic-version=besteffort,accel=kvm:tcg

I don't care if it's not the fastest or most featureful.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top



[Qemu-devel] [RFC 1/7] cpu: move break/watchpoints into arrays.

2016-06-17 Thread Alex Bennée
Before we can protect the lists we need a structure a little more
amenable to RCU protection. This moves all the lists into a re-sizeable
array. The array still only points to allocated structures because a
number of the architectures still need to look at the results of a hit
by examining the field.

Signed-off-by: Alex Bennée 
---
 cpu-exec.c |   6 +-
 exec.c | 167 ++---
 include/qom/cpu.h  |  22 +++---
 linux-user/main.c  |  22 +++---
 qom/cpu.c  |   2 -
 target-arm/translate-a64.c |   6 +-
 target-arm/translate.c |   6 +-
 target-i386/bpt_helper.c   |   6 +-
 target-lm32/helper.c   |   6 +-
 9 files changed, 157 insertions(+), 86 deletions(-)

diff --git a/cpu-exec.c b/cpu-exec.c
index b840e1d..2b49337 100644
--- a/cpu-exec.c
+++ b/cpu-exec.c
@@ -388,9 +388,11 @@ static inline void cpu_handle_debug_exception(CPUState 
*cpu)
 {
 CPUClass *cc = CPU_GET_CLASS(cpu);
 CPUWatchpoint *wp;
+int i;
 
-if (!cpu->watchpoint_hit) {
-QTAILQ_FOREACH(wp, >watchpoints, entry) {
+if (!cpu->watchpoint_hit && cpu->watchpoints) {
+for (i = 0; i < cpu->watchpoints->len; i++) {
+wp = g_array_index(cpu->watchpoints, CPUWatchpoint *, i);
 wp->flags &= ~BP_WATCHPOINT_HIT;
 }
 }
diff --git a/exec.c b/exec.c
index 0122ef7..e73c909 100644
--- a/exec.c
+++ b/exec.c
@@ -769,17 +769,22 @@ int cpu_watchpoint_insert(CPUState *cpu, vaddr addr, 
vaddr len,
  VADDR_PRIx ", len=%" VADDR_PRIu, addr, len);
 return -EINVAL;
 }
-wp = g_malloc(sizeof(*wp));
 
+/* Allocate if no previous watchpoints */
+if (!cpu->watchpoints) {
+cpu->watchpoints = g_array_new(false, false, sizeof(CPUWatchpoint *));
+}
+
+wp = g_malloc(sizeof(*wp));
 wp->vaddr = addr;
 wp->len = len;
 wp->flags = flags;
 
 /* keep all GDB-injected watchpoints in front */
 if (flags & BP_GDB) {
-QTAILQ_INSERT_HEAD(>watchpoints, wp, entry);
+g_array_prepend_val(cpu->watchpoints, wp);
 } else {
-QTAILQ_INSERT_TAIL(>watchpoints, wp, entry);
+g_array_append_val(cpu->watchpoints, wp);
 }
 
 tlb_flush_page(cpu, addr);
@@ -794,13 +799,17 @@ int cpu_watchpoint_remove(CPUState *cpu, vaddr addr, 
vaddr len,
   int flags)
 {
 CPUWatchpoint *wp;
+int i = 0;
 
-QTAILQ_FOREACH(wp, >watchpoints, entry) {
-if (addr == wp->vaddr && len == wp->len
+if (unlikely(cpu->watchpoints) && unlikely(cpu->watchpoints->len)) {
+do {
+wp = g_array_index(cpu->watchpoints, CPUWatchpoint *, i);
+if (wp && addr == wp->vaddr && len == wp->len
 && flags == (wp->flags & ~BP_WATCHPOINT_HIT)) {
-cpu_watchpoint_remove_by_ref(cpu, wp);
-return 0;
-}
+cpu_watchpoint_remove_by_ref(cpu, wp);
+return 0;
+}
+} while (i++ < cpu->watchpoints->len);
 }
 return -ENOENT;
 }
@@ -808,7 +817,18 @@ int cpu_watchpoint_remove(CPUState *cpu, vaddr addr, vaddr 
len,
 /* Remove a specific watchpoint by reference.  */
 void cpu_watchpoint_remove_by_ref(CPUState *cpu, CPUWatchpoint *watchpoint)
 {
-QTAILQ_REMOVE(>watchpoints, watchpoint, entry);
+CPUWatchpoint *wp;
+int i;
+
+g_assert(cpu->watchpoints);
+
+for (i = 0; i < cpu->watchpoints->len; i++) {
+wp = g_array_index(cpu->watchpoints, CPUWatchpoint *, i);
+if (wp == watchpoint) {
+g_array_remove_index_fast(cpu->watchpoints, i);
+break;
+}
+}
 
 tlb_flush_page(cpu, watchpoint->vaddr);
 
@@ -818,11 +838,15 @@ void cpu_watchpoint_remove_by_ref(CPUState *cpu, 
CPUWatchpoint *watchpoint)
 /* Remove all matching watchpoints.  */
 void cpu_watchpoint_remove_all(CPUState *cpu, int mask)
 {
-CPUWatchpoint *wp, *next;
+CPUWatchpoint *wp;
+int i;
 
-QTAILQ_FOREACH_SAFE(wp, >watchpoints, entry, next) {
-if (wp->flags & mask) {
-cpu_watchpoint_remove_by_ref(cpu, wp);
+if (unlikely(cpu->watchpoints) && unlikely(cpu->watchpoints->len)) {
+for (i = cpu->watchpoints->len; i == 0; i--) {
+wp = g_array_index(cpu->watchpoints, CPUWatchpoint *, i);
+if (wp->flags & mask) {
+cpu_watchpoint_remove_by_ref(cpu, wp);
+}
 }
 }
 }
@@ -855,6 +879,11 @@ int cpu_breakpoint_insert(CPUState *cpu, vaddr pc, int 
flags,
 {
 CPUBreakpoint *bp;
 
+/* Allocate if no previous breakpoints */
+if (!cpu->breakpoints) {
+cpu->breakpoints = g_array_new(false, false, sizeof(CPUBreakpoint *));
+}
+
 bp = g_malloc(sizeof(*bp));
 
 bp->pc = pc;
@@ -862,9 +891,9 @@ int cpu_breakpoint_insert(CPUState *cpu, vaddr pc, int 
flags,
 
 /* keep all GDB-injected breakpoints in front */
 if (flags & 

[Qemu-devel] [Bug 1357206] Re: QEMU user mode still crashes in multi-thread code.

2016-06-17 Thread Peter Maydell
This test case now works for me, so I think we have resolved the bug
that was showing up here.


** Changed in: qemu
   Status: New => Fix Committed

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

Title:
  QEMU user mode still crashes in multi-thread code.

Status in QEMU:
  Fix Committed

Bug description:
  I compiled the qemu 2.0 release source and find out qemu crashing when
  emulating multi-thread code in user mode.

  I did a little search and found LP:668799 but it is far from now and
  it is probably not the problem here.

  I used program below as the test program:

  #include 
  #include 
  #include 

  void *print_message_function( void *ptr );

  main()
  {
   pthread_t thread1, thread2;
   const char *message1 = "Thread 1";
   const char *message2 = "Thread 2";
   int  iret1, iret2;

  /* Create independent threads each of which will execute function
  */

   iret1 = pthread_create( , NULL, print_message_function, (void*) 
message1);
   if(iret1)
   {
   fprintf(stderr,"Error - pthread_create() return code: %d\n",iret1);
   exit(EXIT_FAILURE);
   }

   iret2 = pthread_create( , NULL, print_message_function, (void*) 
message2);
   if(iret2)
   {
   fprintf(stderr,"Error - pthread_create() return code: %d\n",iret2);
   exit(EXIT_FAILURE);
   }

   printf("pthread_create() for thread 1 returns: %d\n",iret1);
   printf("pthread_create() for thread 2 returns: %d\n",iret2);

   /* Wait till threads are complete before main continues. Unless we  */
   /* wait we run the risk of executing an exit which will terminate   */
   /* the process and all threads before the threads have completed.   */

   pthread_join( thread1, NULL);
   pthread_join( thread2, NULL); 

   exit(EXIT_SUCCESS);
  }

  void *print_message_function( void *ptr )
  {
   char *message;
   message = (char *) ptr;
   printf("%s \n", message);
  }

  Compiled to i386 and aarch64 object, 
  and both qemu-i386 and qemu-aarch64 had segmentation faults.

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



[Qemu-devel] [PULL 41/42] trace: split out trace events for qom/ directory

2016-06-17 Thread Stefan Hajnoczi
From: "Daniel P. Berrange" 

Move all trace-events for files in the qom/ directory to
their own file.

Signed-off-by: Daniel P. Berrange 
Message-id: 1466066426-16657-40-git-send-email-berra...@redhat.com
Signed-off-by: Stefan Hajnoczi 
---
 Makefile.objs| 1 +
 qom/trace-events | 5 +
 trace-events | 4 
 3 files changed, 6 insertions(+), 4 deletions(-)
 create mode 100644 qom/trace-events

diff --git a/Makefile.objs b/Makefile.objs
index ad7419b..9f2c260 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -156,3 +156,4 @@ trace-events-y += net/trace-events
 trace-events-y += target-sparc/trace-events
 trace-events-y += target-s390x/trace-events
 trace-events-y += target-ppc/trace-events
+trace-events-y += qom/trace-events
diff --git a/qom/trace-events b/qom/trace-events
new file mode 100644
index 000..350fc1f
--- /dev/null
+++ b/qom/trace-events
@@ -0,0 +1,5 @@
+# See docs/trace-events.txt for syntax documentation.
+
+# qom/object.c
+object_dynamic_cast_assert(const char *type, const char *target, const char 
*file, int line, const char *func) "%s->%s (%s:%d:%s)"
+object_class_dynamic_cast_assert(const char *type, const char *target, const 
char *file, int line, const char *func) "%s->%s (%s:%d:%s)"
diff --git a/trace-events b/trace-events
index 932fd40..e6632df 100644
--- a/trace-events
+++ b/trace-events
@@ -136,10 +136,6 @@ memory_region_subpage_write(int cpu_index, void *mr, 
uint64_t offset, uint64_t v
 memory_region_tb_read(int cpu_index, uint64_t addr, uint64_t value, unsigned 
size) "cpu %d addr %#"PRIx64" value %#"PRIx64" size %u"
 memory_region_tb_write(int cpu_index, uint64_t addr, uint64_t value, unsigned 
size) "cpu %d addr %#"PRIx64" value %#"PRIx64" size %u"
 
-# qom/object.c
-object_dynamic_cast_assert(const char *type, const char *target, const char 
*file, int line, const char *func) "%s->%s (%s:%d:%s)"
-object_class_dynamic_cast_assert(const char *type, const char *target, const 
char *file, int line, const char *func) "%s->%s (%s:%d:%s)"
-
 # linux-user/signal.c
 user_setup_frame(void *env, uint64_t frame_addr) "env=%p frame_addr=%"PRIx64
 user_setup_rt_frame(void *env, uint64_t frame_addr) "env=%p frame_addr=%"PRIx64
-- 
2.5.5




Re: [Qemu-devel] [PATCH] oslib-posix: New qemu_alloc_stack() to allocate stack with correct perms

2016-06-17 Thread Peter Maydell
On 17 June 2016 at 17:12, Richard Henderson  wrote:
> What about using dl_iterate_phdr, looking for PT_GNU_STACK?
> That interface is present on a few other hosts besides Linux.

We could do that. I note that the MIPS kernel is buggy in that
it will assume the stack is executable even if the binary
has PT_GNU_STACK saying "please don't be executable". And
most architectures except x86-64 won't honour PT_GNU_STACK=non-exec
unless the parent process also had nonexec stack (because they
let the READ_IMPLIES_EXEC personality flag be inherited; see
https://insights.sei.cmu.edu/cert/2014/02/feeling-insecure-blame-your-parent.html
). So the PT_GNU_STACK flag doesn't necessarily match up with
either the actual executability of the standard stack or with
what the kernel actually requires.

> But really this is a place that I'd much rather fall back to an ifdef ladder
> than assume executable permission is required.

The trouble with this is that it means that as and when the MIPS
folks fix their kernel and libc and compiler to support non-exec
stacks we won't automatically pick this up, and our stacks will
remain executable. Also it requires us to audit every architecture
to find out which ones require exec-stack. But maybe it is just
MIPS? (Maybe we could just say "this is a MIPS kernel bug" ? :-))

thanks
-- PMM



[Qemu-devel] [RFC 0/7] Safe watch and breakpoint manipulation

2016-06-17 Thread Alex Bennée
Hi,

Last time I went through the MTTCG code the access to the
break/watchpoint code was annotated with "RCU?". The code currently
gets away with avoiding locks for the gdbstub as the guest execution
state is usually halted. However when used for modelling architectural
debug registers there is no such protection.

The patch series changes things in stages.

First we move the break/watchpoints into an array which is more
amenable to RCU control that the QLIST. We then control the life time
of references to break/watchpoint data by removing long held
references in the target code and getting information when needed from
the core. Then we stop dynamically allocation the watch/breakpoint
data and store it directly in the array which makes iteration across
the list a bit more cache friendly than referenced pointers. Finally
addition and removal of elements of the array is put under RCU
control. This ensures there is always a safe array of data to check
in the run-loop.

I've taken the decision not to use the RCU like mechanism for setting
the hit flags because I can't construct a potential race between a WP
being hit and it being removed or updated.

I've tested with the gdbstub on ARMv7 using
./tests/guest-debug/test-gdbstub.py and done some manual testing with
arm-linux/qemu-arm -g 1234 and everything seems to work fine. I could
really do with adding some unit tests for exercising this code but I'm
unsure of the best approach of doing this.

Cheers,

Alex Bennée (7):
  cpu: move break/watchpoints into arrays.
  exec: keep CPUWatchpoint references internal
  exec: keep CPUBreakpoint references internal
  break/watchpoints: store inside array
  breakpoints: put breakpoints under RCU control
  linux-user: don't clone watchpoints
  watchpoints: put watchpoints under RCU control

 cpu-exec.c |   7 +-
 cpus.c |   3 +
 exec.c | 522 -
 gdbstub.c  |   4 +-
 include/qom/cpu.h  | 160 --
 linux-user/main.c  |  13 +-
 qom/cpu.c  |   2 -
 target-arm/cpu.h   |   3 -
 target-arm/helper.c|  24 +--
 target-arm/op_helper.c |  10 +-
 target-arm/translate-a64.c |   6 +-
 target-arm/translate.c |   6 +-
 target-i386/bpt_helper.c   |  44 ++--
 target-i386/cpu.h  |   4 -
 target-lm32/cpu.h  |   3 -
 target-lm32/helper.c   |  31 +--
 target-s390x/helper.c  |  10 +-
 target-xtensa/cpu.h|   3 -
 target-xtensa/helper.c |   4 +-
 target-xtensa/op_helper.c  |  16 +-
 20 files changed, 639 insertions(+), 236 deletions(-)

-- 
2.7.4




Re: [Qemu-devel] [PATCH 4/5] x86: Allow physical address bits to be set

2016-06-17 Thread Laszlo Ersek
On 06/17/16 11:52, Igor Mammedov wrote:
> On Fri, 17 Jun 2016 11:17:54 +0200
> Gerd Hoffmann  wrote:
> 
>> On Fr, 2016-06-17 at 10:43 +0200, Paolo Bonzini wrote:
>>>
>>> On 17/06/2016 10:15, Dr. David Alan Gilbert wrote:  
 Larger is a problem if the guest tries to map something to a high
 address that's not addressable.  
>>>
>>> Right.  It's not a problem for most emulated PCI devices (it would be a
>>> problem for those that have large RAM BARs, but even our emulated video
>>> cards do not have 64-bit RAM BARs, I think;  
>>
>> qxl can be configured to have one, try "-device
>> qxl-vga,vram64_size_mb=1024"
>>
2) While we have maxmem settings to tell us the top of VM RAM, do
   we have anything that tells us the top of IO space? What happens
   when we hotplug a PCI card?  
>>
>>> (arch/x86/kernel/setup.c) but I agree that (2) is a blocker.  
>>
>> seabios maps stuff right above ram (possibly with a hole due to
>> alignment requirements).
>>
>> ovmf maps stuff into a 32G-aligned 32G hole.  Which lands at 32G and
>> therefore is addressable with 36 bits, unless you have tons of ram (>
>> 30G) assigned to your guest.  A physical host machine where you can plug
>> in enough ram for such a configuration likely has more than 36 physical
>> address lines too ...
>>
>> qemu checks where the firmware mapped 64bit bars, then adds those ranges
>> to the root bus pci resources in the acpi tables (see /proc/iomem).
>>
>>> You don't know how the guest will assign PCI BAR addresses, and as you
>>> said there's hotplug too.  
>>
>> Not sure whenever qemu adds some extra space for hotplug to the 64bit
>> hole and if so how it calculates the size then.  But the guest os should
>> stick to those ranges when configuring hotplugged devices.
> currently firmware would assign 64-bit BARs after reserved-memory-end
> (not sure about ovmf though)

OVMF does the same as well. It makes sure that the 64-bit PCI MMIO
aperture is located above "etc/reserved-memory-end", if the latter exists.

> but QEMU on ACPI side will add 64-bit _CRS only
> for firmware mapped devices (i.e. no space reserved for hotplug).
> And is I recall correctly ovmf won't map BARs if it doesn't have
> a driver for it

Yes, that's correct, generally for all UEFI firmware.

More precisely, BARs will be allocated and programmed, but the MMIO
space decoding bit will not be set (permanently) in the device's command
register, if there is no matching driver in the firmware (or in the
device's own oprom).

> so ACPI tables won't even have a space for not mapped
> 64-bit BARs.

This used to be true, but that's not the case since
.

Namely, specifically for conforming to QEMU's ACPI generator, OVMF
*temporarily* enables, as a platform quirk, all PCI devices present in
the system, before triggering QEMU to generate the ACPI payload.

Thus, nowadays 64-bit BARs work fine with OVMF, both for virtio-modern
devices, and assigned physical devices. (This is very easy to test,
because, unlike SeaBIOS, the edk2 stuff built into OVMF prefers to
allocate 64-bit BARs outside of the 32-bit address space.)

Devices behind PXBs are a different story, but Marcel's been looking
into that, see .

> There was another attempt to reserve more space in _CRS
>   https://lists.nongnu.org/archive/html/qemu-devel/2016-05/msg00090.html

That's actually Marcel's first own patch set for addressing RHBZ#1323976
that I mentioned above (see it linked in
).

It might have wider effects, but it is entirely motivated, to my
knowledge, by PXB. If you don't have extra root bridges, and/or you plug
all your devices with 64-bit MMIO BARs into the "main" (default) root
bridge, then (I believe) that patch set is not supposed to make any
difference. (I could be wrong, it's been a while since I looked at
Marcel's work!)

Thanks
Laszlo



[Qemu-devel] [PULL 32/42] trace: split out trace events for hw/acpi/ directory

2016-06-17 Thread Stefan Hajnoczi
From: "Daniel P. Berrange" 

Move all trace-events for files in the hw/acpi/ directory to
their own file.

Signed-off-by: Daniel P. Berrange 
Message-id: 1466066426-16657-31-git-send-email-berra...@redhat.com
Signed-off-by: Stefan Hajnoczi 
---
 Makefile.objs|  1 +
 hw/acpi/trace-events | 18 ++
 trace-events | 17 -
 3 files changed, 19 insertions(+), 17 deletions(-)
 create mode 100644 hw/acpi/trace-events

diff --git a/Makefile.objs b/Makefile.objs
index f2753bf..767ffa3 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -147,3 +147,4 @@ trace-events-y += hw/ppc/trace-events
 trace-events-y += hw/pci/trace-events
 trace-events-y += hw/s390x/trace-events
 trace-events-y += hw/vfio/trace-events
+trace-events-y += hw/acpi/trace-events
diff --git a/hw/acpi/trace-events b/hw/acpi/trace-events
new file mode 100644
index 000..e95b218
--- /dev/null
+++ b/hw/acpi/trace-events
@@ -0,0 +1,18 @@
+# See docs/trace-events.txt for syntax documentation.
+
+# hw/acpi/memory_hotplug.c
+mhp_acpi_invalid_slot_selected(uint32_t slot) "0x%"PRIx32
+mhp_acpi_ejecting_invalid_slot(uint32_t slot) "0x%"PRIx32
+mhp_acpi_read_addr_lo(uint32_t slot, uint32_t addr) "slot[0x%"PRIx32"] addr 
lo: 0x%"PRIx32
+mhp_acpi_read_addr_hi(uint32_t slot, uint32_t addr) "slot[0x%"PRIx32"] addr 
hi: 0x%"PRIx32
+mhp_acpi_read_size_lo(uint32_t slot, uint32_t size) "slot[0x%"PRIx32"] size 
lo: 0x%"PRIx32
+mhp_acpi_read_size_hi(uint32_t slot, uint32_t size) "slot[0x%"PRIx32"] size 
hi: 0x%"PRIx32
+mhp_acpi_read_pxm(uint32_t slot, uint32_t pxm) "slot[0x%"PRIx32"] proximity: 
0x%"PRIx32
+mhp_acpi_read_flags(uint32_t slot, uint32_t flags) "slot[0x%"PRIx32"] flags: 
0x%"PRIx32
+mhp_acpi_write_slot(uint32_t slot) "set active slot: 0x%"PRIx32
+mhp_acpi_write_ost_ev(uint32_t slot, uint32_t ev) "slot[0x%"PRIx32"] OST 
EVENT: 0x%"PRIx32
+mhp_acpi_write_ost_status(uint32_t slot, uint32_t st) "slot[0x%"PRIx32"] OST 
STATUS: 0x%"PRIx32
+mhp_acpi_clear_insert_evt(uint32_t slot) "slot[0x%"PRIx32"] clear insert event"
+mhp_acpi_clear_remove_evt(uint32_t slot) "slot[0x%"PRIx32"] clear remove event"
+mhp_acpi_pc_dimm_deleted(uint32_t slot) "slot[0x%"PRIx32"] pc-dimm deleted"
+mhp_acpi_pc_dimm_delete_failed(uint32_t slot) "slot[0x%"PRIx32"] pc-dimm 
delete failed"
diff --git a/trace-events b/trace-events
index a9bff8a..8b7ffa7 100644
--- a/trace-events
+++ b/trace-events
@@ -228,23 +228,6 @@ memory_region_tb_write(int cpu_index, uint64_t addr, 
uint64_t value, unsigned si
 object_dynamic_cast_assert(const char *type, const char *target, const char 
*file, int line, const char *func) "%s->%s (%s:%d:%s)"
 object_class_dynamic_cast_assert(const char *type, const char *target, const 
char *file, int line, const char *func) "%s->%s (%s:%d:%s)"
 
-#hw/acpi/memory_hotplug.c
-mhp_acpi_invalid_slot_selected(uint32_t slot) "0x%"PRIx32
-mhp_acpi_ejecting_invalid_slot(uint32_t slot) "0x%"PRIx32
-mhp_acpi_read_addr_lo(uint32_t slot, uint32_t addr) "slot[0x%"PRIx32"] addr 
lo: 0x%"PRIx32
-mhp_acpi_read_addr_hi(uint32_t slot, uint32_t addr) "slot[0x%"PRIx32"] addr 
hi: 0x%"PRIx32
-mhp_acpi_read_size_lo(uint32_t slot, uint32_t size) "slot[0x%"PRIx32"] size 
lo: 0x%"PRIx32
-mhp_acpi_read_size_hi(uint32_t slot, uint32_t size) "slot[0x%"PRIx32"] size 
hi: 0x%"PRIx32
-mhp_acpi_read_pxm(uint32_t slot, uint32_t pxm) "slot[0x%"PRIx32"] proximity: 
0x%"PRIx32
-mhp_acpi_read_flags(uint32_t slot, uint32_t flags) "slot[0x%"PRIx32"] flags: 
0x%"PRIx32
-mhp_acpi_write_slot(uint32_t slot) "set active slot: 0x%"PRIx32
-mhp_acpi_write_ost_ev(uint32_t slot, uint32_t ev) "slot[0x%"PRIx32"] OST 
EVENT: 0x%"PRIx32
-mhp_acpi_write_ost_status(uint32_t slot, uint32_t st) "slot[0x%"PRIx32"] OST 
STATUS: 0x%"PRIx32
-mhp_acpi_clear_insert_evt(uint32_t slot) "slot[0x%"PRIx32"] clear insert event"
-mhp_acpi_clear_remove_evt(uint32_t slot) "slot[0x%"PRIx32"] clear remove event"
-mhp_acpi_pc_dimm_deleted(uint32_t slot) "slot[0x%"PRIx32"] pc-dimm deleted"
-mhp_acpi_pc_dimm_delete_failed(uint32_t slot) "slot[0x%"PRIx32"] pc-dimm 
delete failed"
-
 # target-s390x/kvm.c
 kvm_enable_cmma(int rc) "CMMA: enabling with result code %d"
 kvm_clear_cmma(int rc) "CMMA: clearing with result code %d"
-- 
2.5.5




[Qemu-devel] [Bug 1299190] Re: Access to /proc/self/exe in linux-user mode

2016-06-17 Thread Peter Maydell
This bug was fixed by commit aa07f5ecf9828 in 2014 and has been released
in QEMU.


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

Title:
  Access to /proc/self/exe in linux-user mode

Status in QEMU:
  Fix Released

Bug description:
  This is based on a recent bug in GCC Bugzilla:
  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60681

  It looks like libbacktrace (GCC runtime library used for obtaining
  stack traces) uses /proc/self/exe for error reporting. Currently this
  is mapped to qemu-arm which effectively disables libbacktrace on
  linux-user.

  It seems that QEMU already supports /proc/self/{maps,stat,auxv} so
  addition of /proc/self/exe may be trivial.

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



[Qemu-devel] [Bug 1319100] Re: qemu-arm-static bug in signal handling causes mono and java to hang

2016-06-17 Thread Peter Maydell
Recent changes to QEMU's handling of signals fix this hang trying to run
mono under QEMU; they should be out in QEMU 2.7.


** Changed in: qemu
   Status: New => Fix Committed

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

Title:
  qemu-arm-static bug in signal handling causes mono and java to hang

Status in QEMU:
  Fix Committed
Status in qemu-kvm package in Ubuntu:
  Confirmed
Status in qemu-kvm package in Debian:
  Confirmed

Bug description:
  Note, this bug is already reported to debian, but it seems to also affect the 
upstream code.
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748043

  running mono in a chroot environment with qemu-user-static is not posible
  because at least one signal used during termination of mono is routed to the
  host.

  This can be reproduced by:
  debootstrap --include=mono-runtime --foreign --arch=armel "wheezy" 
"mono-test" "http://ftp.de.debian.org//debian;
  cp /usr/bin/qemu-arm-static mono-test/usr/bin
  mount -t proc none mono-test/proc
  mount -o bind /dev mono-test/dev
  mount -o bind /sys mono-test/sys
  chroot mono-test
  ../debootstrap/debootstrap --second-stage
  exit
  mount -t proc none mono-test/proc
  mount -o bind /sys mono-test/sys
  chroot mono-test
  QEMU_STRACE=1 /usr/bin/mono /usr/lib/mono/4.0/gacutil.exe

  This will block on a futex:

  --8<--
  18663 sched_yield(0,0,2582980,0,0,2582928) = 0
  18663 clock_gettime(1,-150996384,2,1,2585016,2585600) = 0
  18663 tgkill(18663,18664,30,18664,30,-161951744) = 0
  18663 futex(0x00293774,FUTEX_PRIVATE_FLAG|FUTEX_WAIT,0,NULL,NULL,0)
  --8<--

  If you use mono within strace on a native x86 box you can see, that signals
  between threads are used during termination:

  strace -f -o log.txt /usr/bin/mono /usr/lib/mono/4.0/gacutil.exe

  --8<--
  14075 sched_yield() = 0   
  
  14075 tgkill(14075, 14083, SIGPWR)  = 0   
  
  14075 futex(0x983f00, FUTEX_WAIT_PRIVATE, 0, NULL 
  
  14083 <... futex resumed> ) = ? ERESTARTSYS (To be restarted) 
  
  14083 --- SIGPWR (Power failure) @ 0 (0) ---  
  
  14083 futex(0x983f00, FUTEX_WAKE_PRIVATE, 1) = 1  
  
  14075 <... futex resumed> ) = 0   
  
  14083 rt_sigsuspend(~[INT QUIT ABRT TERM XCPU RTMIN RT_1] 
  
  14075 futex(0x94d9a4, FUTEX_CMP_REQUEUE_PRIVATE, 1, 2147483647, 0x94da20, 24) 
= 3
  14078 <... futex resumed> ) = 0   
  
  14078 futex(0x94da20, FUTEX_WAKE_PRIVATE, 1) = 1  
  
  14077 <... futex resumed> ) = 0   
  
  14075 futex(0x94d9a4, FUTEX_CMP_REQUEUE_PRIVATE, 1, 2147483647, 0x94da20, 26 

  --8<--

  This also blocks the installation of libnunit2.6-cil within a armel chroot,
  because it uses mono in its postinst script.
  E.g. (/usr/bin/mono /usr/share/mono/MonoGetAssemblyName.exe 
/usr/lib/cli/nunit.core-2.6/nunit.core.dll)

  Obviously the same as described in:
  http://lists.opensuse.org/opensuse-arm/2011-12/msg0.html
  is happening here.

  There is an openSuSE patch against qemu:
  
https://build.opensuse.org/package/view_file/Virtualization:Qemu/qemu/0002-XXX-work-around-SA_RESTART-race-wit.patch?expand=1

  This patch also applies against qemu from backports-wheezy and resolves this
  issue.

  As it seems, that this issue is not Debian specific i will also report it to
  the qemu project and reference this bug report.

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



[Qemu-devel] [RFC 4/7] break/watchpoints: store inside array

2016-06-17 Thread Alex Bennée
Instead of dynamically allocating each break/watchpoint just include in
the array. This will make it easier to use RCU to update the array as
well as make the scanning of the current list more cache-line friendly.

Signed-off-by: Alex Bennée 
---
 cpu-exec.c |  2 +-
 exec.c | 68 ++
 include/qom/cpu.h  |  2 +-
 linux-user/main.c  |  4 +--
 target-arm/translate-a64.c |  2 +-
 target-arm/translate.c |  2 +-
 target-i386/bpt_helper.c   |  2 +-
 target-lm32/helper.c   |  2 +-
 8 files changed, 40 insertions(+), 44 deletions(-)

diff --git a/cpu-exec.c b/cpu-exec.c
index 2b49337..2736a27 100644
--- a/cpu-exec.c
+++ b/cpu-exec.c
@@ -392,7 +392,7 @@ static inline void cpu_handle_debug_exception(CPUState *cpu)
 
 if (!cpu->watchpoint_hit && cpu->watchpoints) {
 for (i = 0; i < cpu->watchpoints->len; i++) {
-wp = g_array_index(cpu->watchpoints, CPUWatchpoint *, i);
+wp = _array_index(cpu->watchpoints, CPUWatchpoint, i);
 wp->flags &= ~BP_WATCHPOINT_HIT;
 }
 }
diff --git a/exec.c b/exec.c
index e80c9fe..c8e8823 100644
--- a/exec.c
+++ b/exec.c
@@ -772,8 +772,8 @@ CPUWatchpoint *cpu_watchpoint_get_by_ref(CPUState *cpu, int 
ref)
 CPUWatchpoint *wp = NULL;
 int i = 0;
 do {
-wp = g_array_index(cpu->watchpoints, CPUWatchpoint *, i++);
-} while (wp && wp->ref != ref);
+wp = _array_index(cpu->watchpoints, CPUWatchpoint, i++);
+} while (i < cpu->watchpoints->len && wp && wp->ref != ref);
 
 return wp;
 }
@@ -793,7 +793,7 @@ int cpu_watchpoint_insert_with_ref(CPUState *cpu, vaddr 
addr, vaddr len,
 
 /* Allocate if no previous watchpoints */
 if (!cpu->watchpoints) {
-cpu->watchpoints = g_array_new(true, false, sizeof(CPUWatchpoint *));
+cpu->watchpoints = g_array_new(false, true, sizeof(CPUWatchpoint));
 }
 
 /* Find old watchpoint */
@@ -807,18 +807,17 @@ int cpu_watchpoint_insert_with_ref(CPUState *cpu, vaddr 
addr, vaddr len,
 wp->flags = flags;
 wp->ref = ref;
 } else {
-wp = g_malloc(sizeof(*wp));
-
-wp->vaddr = addr;
-wp->len = len;
-wp->flags = flags;
-wp->ref = ref;
+CPUWatchpoint watch;
+watch.vaddr = addr;
+watch.len = len;
+watch.flags = flags;
+watch.ref = ref;
 
 /* keep all GDB-injected watchpoints in front */
 if (flags & BP_GDB) {
-g_array_prepend_val(cpu->watchpoints, wp);
+g_array_prepend_val(cpu->watchpoints, watch);
 } else {
-g_array_append_val(cpu->watchpoints, wp);
+g_array_append_val(cpu->watchpoints, watch);
 }
 }
 
@@ -836,10 +835,9 @@ int cpu_watchpoint_insert(CPUState *cpu, vaddr addr, vaddr 
len, int flags)
 static void cpu_watchpoint_delete(CPUState *cpu, int index)
 {
 CPUWatchpoint *wp;
-wp = g_array_index(cpu->watchpoints, CPUWatchpoint *, index);
-g_array_remove_index(cpu->watchpoints, index);
+wp = _array_index(cpu->watchpoints, CPUWatchpoint, index);
 tlb_flush_page(cpu, wp->vaddr);
-g_free(wp);
+g_array_remove_index(cpu->watchpoints, index);
 }
 
 /* Remove a specific watchpoint.  */
@@ -851,7 +849,7 @@ int cpu_watchpoint_remove(CPUState *cpu, vaddr addr, vaddr 
len,
 
 if (unlikely(cpu->watchpoints) && unlikely(cpu->watchpoints->len)) {
 do {
-wp = g_array_index(cpu->watchpoints, CPUWatchpoint *, i);
+wp = _array_index(cpu->watchpoints, CPUWatchpoint, i);
 if (wp && addr == wp->vaddr && len == wp->len
 && flags == (wp->flags & ~BP_WATCHPOINT_HIT)) {
 cpu_watchpoint_delete(cpu, i);
@@ -871,7 +869,7 @@ int cpu_watchpoint_remove_by_ref(CPUState *cpu, int ref)
 
 if (unlikely(cpu->watchpoints) && unlikely(cpu->watchpoints->len)) {
 do {
-wp = g_array_index(cpu->watchpoints, CPUWatchpoint *, i);
+wp = _array_index(cpu->watchpoints, CPUWatchpoint, i);
 if (wp && wp->ref == ref) {
 cpu_watchpoint_delete(cpu, i);
 return 0;
@@ -890,7 +888,7 @@ void cpu_watchpoint_remove_all(CPUState *cpu, int mask)
 if (unlikely(cpu->watchpoints) && unlikely(cpu->watchpoints->len)) {
 int i = cpu->watchpoints->len;
 do {
-wp = g_array_index(cpu->watchpoints, CPUWatchpoint *, i);
+wp = _array_index(cpu->watchpoints, CPUWatchpoint, i);
 if (wp->flags & mask) {
 cpu_watchpoint_delete(cpu, i);
 } else {
@@ -927,8 +925,8 @@ CPUBreakpoint *cpu_breakpoint_get_by_ref(CPUState *cpu, int 
ref)
 CPUBreakpoint *bp = NULL;
 int i = 0;
 do {
-bp = g_array_index(cpu->breakpoints, CPUBreakpoint *, i++);
-} while (bp && bp->ref != ref);
+bp = _array_index(cpu->breakpoints, CPUBreakpoint, 

[Qemu-devel] [PULL 27/42] trace: split out trace events for hw/9pfs/ directory

2016-06-17 Thread Stefan Hajnoczi
From: "Daniel P. Berrange" 

Move all trace-events for files in the hw/9pfs/ directory to
their own file.

Signed-off-by: Daniel P. Berrange 
Message-id: 1466066426-16657-26-git-send-email-berra...@redhat.com
Signed-off-by: Stefan Hajnoczi 
---
 Makefile.objs|  1 +
 hw/9pfs/trace-events | 47 +++
 trace-events | 46 --
 3 files changed, 48 insertions(+), 46 deletions(-)
 create mode 100644 hw/9pfs/trace-events

diff --git a/Makefile.objs b/Makefile.objs
index e1f5cc6..82bef4d 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -142,3 +142,4 @@ trace-events-y += hw/sparc/trace-events
 trace-events-y += hw/sd/trace-events
 trace-events-y += hw/isa/trace-events
 trace-events-y += hw/i386/trace-events
+trace-events-y += hw/9pfs/trace-events
diff --git a/hw/9pfs/trace-events b/hw/9pfs/trace-events
new file mode 100644
index 000..63efa27
--- /dev/null
+++ b/hw/9pfs/trace-events
@@ -0,0 +1,47 @@
+# See docs/trace-events.txt for syntax documentation.
+
+# hw/9pfs/virtio-9p.c
+v9fs_rerror(uint16_t tag, uint8_t id, int err) "tag %d id %d err %d"
+v9fs_version(uint16_t tag, uint8_t id, int32_t msize, char* version) "tag %d 
id %d msize %d version %s"
+v9fs_version_return(uint16_t tag, uint8_t id, int32_t msize, char* version) 
"tag %d id %d msize %d version %s"
+v9fs_attach(uint16_t tag, uint8_t id, int32_t fid, int32_t afid, char* uname, 
char* aname) "tag %u id %u fid %d afid %d uname %s aname %s"
+v9fs_attach_return(uint16_t tag, uint8_t id, int8_t type, int32_t version, 
int64_t path) "tag %d id %d type %d version %d path %"PRId64
+v9fs_stat(uint16_t tag, uint8_t id, int32_t fid) "tag %d id %d fid %d"
+v9fs_stat_return(uint16_t tag, uint8_t id, int32_t mode, int32_t atime, 
int32_t mtime, int64_t length) "tag %d id %d stat={mode %d atime %d mtime %d 
length %"PRId64"}"
+v9fs_getattr(uint16_t tag, uint8_t id, int32_t fid, uint64_t request_mask) 
"tag %d id %d fid %d request_mask %"PRIu64
+v9fs_getattr_return(uint16_t tag, uint8_t id, uint64_t result_mask, uint32_t 
mode, uint32_t uid, uint32_t gid) "tag %d id %d getattr={result_mask %"PRId64" 
mode %u uid %u gid %u}"
+v9fs_walk(uint16_t tag, uint8_t id, int32_t fid, int32_t newfid, uint16_t 
nwnames) "tag %d id %d fid %d newfid %d nwnames %d"
+v9fs_walk_return(uint16_t tag, uint8_t id, uint16_t nwnames, void* qids) "tag 
%d id %d nwnames %d qids %p"
+v9fs_open(uint16_t tag, uint8_t id, int32_t fid, int32_t mode) "tag %d id %d 
fid %d mode %d"
+v9fs_open_return(uint16_t tag, uint8_t id, int8_t type, int32_t version, 
int64_t path, int iounit) "tag %d id %d qid={type %d version %d path %"PRId64"} 
iounit %d"
+v9fs_lcreate(uint16_t tag, uint8_t id, int32_t dfid, int32_t flags, int32_t 
mode, uint32_t gid) "tag %d id %d dfid %d flags %d mode %d gid %u"
+v9fs_lcreate_return(uint16_t tag, uint8_t id, int8_t type, int32_t version, 
int64_t path, int32_t iounit) "tag %d id %d qid={type %d version %d path 
%"PRId64"} iounit %d"
+v9fs_fsync(uint16_t tag, uint8_t id, int32_t fid, int datasync) "tag %d id %d 
fid %d datasync %d"
+v9fs_clunk(uint16_t tag, uint8_t id, int32_t fid) "tag %d id %d fid %d"
+v9fs_read(uint16_t tag, uint8_t id, int32_t fid, uint64_t off, uint32_t 
max_count) "tag %d id %d fid %d off %"PRIu64" max_count %u"
+v9fs_read_return(uint16_t tag, uint8_t id, int32_t count, ssize_t err) "tag %d 
id %d count %d err %zd"
+v9fs_readdir(uint16_t tag, uint8_t id, int32_t fid, uint64_t offset, uint32_t 
max_count) "tag %d id %d fid %d offset %"PRIu64" max_count %u"
+v9fs_readdir_return(uint16_t tag, uint8_t id, uint32_t count, ssize_t retval) 
"tag %d id %d count %u retval %zd"
+v9fs_write(uint16_t tag, uint8_t id, int32_t fid, uint64_t off, uint32_t 
count, int cnt) "tag %d id %d fid %d off %"PRIu64" count %u cnt %d"
+v9fs_write_return(uint16_t tag, uint8_t id, int32_t total, ssize_t err) "tag 
%d id %d total %d err %zd"
+v9fs_create(uint16_t tag, uint8_t id, int32_t fid, char* name, int32_t perm, 
int8_t mode) "tag %d id %d fid %d name %s perm %d mode %d"
+v9fs_create_return(uint16_t tag, uint8_t id, int8_t type, int32_t version, 
int64_t path, int iounit) "tag %d id %d qid={type %d version %d path %"PRId64"} 
iounit %d"
+v9fs_symlink(uint16_t tag, uint8_t id, int32_t fid,  char* name, char* 
symname, uint32_t gid) "tag %d id %d fid %d name %s symname %s gid %u"
+v9fs_symlink_return(uint16_t tag, uint8_t id, int8_t type, int32_t version, 
int64_t path) "tag %d id %d qid={type %d version %d path %"PRId64"}"
+v9fs_flush(uint16_t tag, uint8_t id, int16_t flush_tag) "tag %d id %d 
flush_tag %d"
+v9fs_link(uint16_t tag, uint8_t id, int32_t dfid, int32_t oldfid, char* name) 
"tag %d id %d dfid %d oldfid %d name %s"
+v9fs_remove(uint16_t tag, uint8_t id, int32_t fid) "tag %d id %d fid %d"
+v9fs_wstat(uint16_t tag, uint8_t id, int32_t fid, int32_t mode, int32_t atime, 
int32_t mtime) "tag %u id %u fid %d 

[Qemu-devel] [PULL 42/42] trace: split out trace events for linux-user/ directory

2016-06-17 Thread Stefan Hajnoczi
From: "Daniel P. Berrange" 

Move all trace-events for files in the linux-user/ directory to
their own file.

Signed-off-by: Daniel P. Berrange 
Reviewed-by: Laurent Vivier 
Message-id: 1466066426-16657-41-git-send-email-berra...@redhat.com
Signed-off-by: Stefan Hajnoczi 
---
 Makefile.objs   |  1 +
 linux-user/trace-events | 12 
 trace-events| 11 ---
 3 files changed, 13 insertions(+), 11 deletions(-)
 create mode 100644 linux-user/trace-events

diff --git a/Makefile.objs b/Makefile.objs
index 9f2c260..7f1f0a3 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -157,3 +157,4 @@ trace-events-y += target-sparc/trace-events
 trace-events-y += target-s390x/trace-events
 trace-events-y += target-ppc/trace-events
 trace-events-y += qom/trace-events
+trace-events-y += linux-user/trace-events
diff --git a/linux-user/trace-events b/linux-user/trace-events
new file mode 100644
index 000..80a2e07
--- /dev/null
+++ b/linux-user/trace-events
@@ -0,0 +1,12 @@
+# See docs/trace-events.txt for syntax documentation.
+
+# linux-user/signal.c
+user_setup_frame(void *env, uint64_t frame_addr) "env=%p frame_addr=%"PRIx64
+user_setup_rt_frame(void *env, uint64_t frame_addr) "env=%p frame_addr=%"PRIx64
+user_do_rt_sigreturn(void *env, uint64_t frame_addr) "env=%p 
frame_addr=%"PRIx64
+user_do_sigreturn(void *env, uint64_t frame_addr) "env=%p frame_addr=%"PRIx64
+user_force_sig(void *env, int target_sig, int host_sig) "env=%p signal %d 
(host %d)"
+user_handle_signal(void *env, int target_sig) "env=%p signal %d"
+user_host_signal(void *env, int host_sig, int target_sig) "env=%p signal %d 
(target %d("
+user_queue_signal(void *env, int target_sig) "env=%p signal %d"
+user_s390x_restore_sigregs(void *env, uint64_t sc_psw_addr, uint64_t 
env_psw_addr) "env=%p frame psw.addr %"PRIx64 " current psw.addr %"PRIx64
diff --git a/trace-events b/trace-events
index e6632df..9d76de8 100644
--- a/trace-events
+++ b/trace-events
@@ -136,17 +136,6 @@ memory_region_subpage_write(int cpu_index, void *mr, 
uint64_t offset, uint64_t v
 memory_region_tb_read(int cpu_index, uint64_t addr, uint64_t value, unsigned 
size) "cpu %d addr %#"PRIx64" value %#"PRIx64" size %u"
 memory_region_tb_write(int cpu_index, uint64_t addr, uint64_t value, unsigned 
size) "cpu %d addr %#"PRIx64" value %#"PRIx64" size %u"
 
-# linux-user/signal.c
-user_setup_frame(void *env, uint64_t frame_addr) "env=%p frame_addr=%"PRIx64
-user_setup_rt_frame(void *env, uint64_t frame_addr) "env=%p frame_addr=%"PRIx64
-user_do_rt_sigreturn(void *env, uint64_t frame_addr) "env=%p 
frame_addr=%"PRIx64
-user_do_sigreturn(void *env, uint64_t frame_addr) "env=%p frame_addr=%"PRIx64
-user_force_sig(void *env, int target_sig, int host_sig) "env=%p signal %d 
(host %d)"
-user_handle_signal(void *env, int target_sig) "env=%p signal %d"
-user_host_signal(void *env, int host_sig, int target_sig) "env=%p signal %d 
(target %d("
-user_queue_signal(void *env, int target_sig) "env=%p signal %d"
-user_s390x_restore_sigregs(void *env, uint64_t sc_psw_addr, uint64_t 
env_psw_addr) "env=%p frame psw.addr %"PRIx64 " current psw.addr %"PRIx64
-
 ### Guest events, keep at bottom
 
 # @vaddr: Access' virtual address.
-- 
2.5.5




Re: [Qemu-devel] [PULL 00/22] target-arm queue

2016-06-17 Thread Peter Maydell
On 17 June 2016 at 15:25, Peter Maydell <peter.mayd...@linaro.org> wrote:
> Nothing here except the GICv3 emulation, but I wanted to get it into
> master this week, and nothing else has made it into target-arm.next.
>
> thanks
> -- PMM
>
>
> The following changes since commit 98b5b7422fe1813040b499a4be415a9f514f1c10:
>
>   Merge remote-tracking branch 
> 'remotes/amit-migration/tags/migration-for-2.7-5' into staging (2016-06-17 
> 14:09:46 +0100)
>
> are available in the git repository at:
>
>
>   git://git.linaro.org/people/pmaydell/qemu-arm.git 
> tags/pull-target-arm-20160617
>
> for you to fetch changes up to f06765a94a31bdd8b65fc83fd91a6c3f8e8a1195:
>
>   ACPI: ARM: Present GIC version in MADT table (2016-06-17 15:23:51 +0100)
>
> 
> target-arm queue:
>  * GICv3 emulation

Applied, thanks.

-- PMM



[Qemu-devel] [PULL 24/42] trace: split out trace events for hw/sd/ directory

2016-06-17 Thread Stefan Hajnoczi
From: "Daniel P. Berrange" 

Move all trace-events for files in the hw/sd/ directory to
their own file.

Signed-off-by: Daniel P. Berrange 
Message-id: 1466066426-16657-23-git-send-email-berra...@redhat.com
Signed-off-by: Stefan Hajnoczi 
---
 Makefile.objs  | 1 +
 hw/sd/trace-events | 5 +
 trace-events   | 4 
 3 files changed, 6 insertions(+), 4 deletions(-)
 create mode 100644 hw/sd/trace-events

diff --git a/Makefile.objs b/Makefile.objs
index e435e84..175af1c 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -139,3 +139,4 @@ trace-events-y += hw/input/trace-events
 trace-events-y += hw/timer/trace-events
 trace-events-y += hw/dma/trace-events
 trace-events-y += hw/sparc/trace-events
+trace-events-y += hw/sd/trace-events
diff --git a/hw/sd/trace-events b/hw/sd/trace-events
new file mode 100644
index 000..b580a0f
--- /dev/null
+++ b/hw/sd/trace-events
@@ -0,0 +1,5 @@
+# See docs/trace-events.txt for syntax documentation.
+
+# hw/sd/milkymist-memcard.c
+milkymist_memcard_memory_read(uint32_t addr, uint32_t value) "addr %08x value 
%08x"
+milkymist_memcard_memory_write(uint32_t addr, uint32_t value) "addr %08x value 
%08x"
diff --git a/trace-events b/trace-events
index 7c927b9..5fa6d54 100644
--- a/trace-events
+++ b/trace-events
@@ -57,10 +57,6 @@ spice_vmc_register_interface(void *scd) "spice vmc 
registered interface %p"
 spice_vmc_unregister_interface(void *scd) "spice vmc unregistered interface %p"
 spice_vmc_event(int event) "spice vmc event %d"
 
-# hw/sd/milkymist-memcard.c
-milkymist_memcard_memory_read(uint32_t addr, uint32_t value) "addr %08x value 
%08x"
-milkymist_memcard_memory_write(uint32_t addr, uint32_t value) "addr %08x value 
%08x"
-
 # hw/isa/pc87312.c
 pc87312_io_read(uint32_t addr, uint32_t val) "read addr=%x val=%x"
 pc87312_io_write(uint32_t addr, uint32_t val) "write addr=%x val=%x"
-- 
2.5.5




[Qemu-devel] [Bug 1075339] Re: linux-user emulation of setsockopt ignores optlen

2016-06-17 Thread Peter Maydell
We fixed our setsockopt emulation to correctly convert timeval
parameters for SO_RCVTIMEO and SO_SNDTIMEO back in 2013.


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

Title:
  linux-user emulation of setsockopt ignores optlen

Status in QEMU:
  Fix Released

Bug description:
  setsockopt always treats the argument as a 4-byte int. This breaks
  timeout options (for which it's an 8- or 16-byte timeval structure,
  depending on word size) and possibly other socket options. int is
  probably a safe default, but options whose values are other types need
  special-case conversion code.

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



  1   2   3   4   5   >