[Qemu-devel] [PATCH v6 01/13] target-mips-ase-dsp: Add internal functions

2012-08-21 Thread Jia Liu
Add internal functions using by MIPS ASE DSP instructions.

Signed-off-by: Jia Liu pro...@gmail.com
---
 target-mips/Makefile.objs |2 +-
 target-mips/dsp_helper.c  | 1277 +
 2 files changed, 1278 insertions(+), 1 deletion(-)
 create mode 100644 target-mips/dsp_helper.c

diff --git a/target-mips/Makefile.objs b/target-mips/Makefile.objs
index 2e0e093..55b252d 100644
--- a/target-mips/Makefile.objs
+++ b/target-mips/Makefile.objs
@@ -1,4 +1,4 @@
-obj-y += translate.o op_helper.o helper.o cpu.o
+obj-y += translate.o dsp_helper.o op_helper.o helper.o cpu.o
 obj-$(CONFIG_SOFTMMU) += machine.o
 
 $(obj)/op_helper.o: QEMU_CFLAGS += $(HELPER_CFLAGS)
diff --git a/target-mips/dsp_helper.c b/target-mips/dsp_helper.c
new file mode 100644
index 000..a7d6c7e
--- /dev/null
+++ b/target-mips/dsp_helper.c
@@ -0,0 +1,1277 @@
+/*
+ * MIPS ASE DSP Instruction emulation helpers for QEMU.
+ *
+ * Copyright (c) 2012  Jia Liu pro...@gmail.com
+ * Dongxue Zhang elat@gmail.com
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see http://www.gnu.org/licenses/.
+ */
+
+#include cpu.h
+#include helper.h
+
+/*** MIPS DSP internal functions begin ***/
+static inline int not_word_value(target_long value)
+{
+target_ulong temp;
+
+temp = (target_long)(int32_t)(value  0x);
+if (value == temp) {
+return 0;
+} else {
+return 1;
+}
+}
+
+static inline void set_DSPControl_overflow_flag(CPUMIPSState *env,
+uint32_t flag, int position)
+{
+env-active_tc.DSPControl |= (target_ulong)flag  position;
+}
+
+static inline void set_DSPControl_carryflag(CPUMIPSState *env, uint32_t flag)
+{
+env-active_tc.DSPControl |= (target_ulong)flag  13;
+}
+
+static inline uint32_t get_DSPControl_carryflag(CPUMIPSState *env)
+{
+uint32_t flag;
+
+flag = (env-active_tc.DSPControl  13)  0x01;
+
+return flag;
+}
+
+static inline void set_DSPControl_24(CPUMIPSState *env, uint32_t flag, int len)
+{
+  uint32_t filter;
+
+  filter = ((0x01  len) - 1)  24;
+  filter = ~filter;
+
+  env-active_tc.DSPControl = filter;
+  env-active_tc.DSPControl |= (target_ulong)flag  24;
+}
+
+static inline uint32_t get_DSPControl_24(CPUMIPSState *env, int len)
+{
+  uint32_t cond;
+  uint32_t filter;
+
+  filter = (0x01  len) - 1;
+
+  cond = (env-active_tc.DSPControl  24)  filter;
+
+  return cond;
+}
+
+static inline void set_DSPControl_pos(CPUMIPSState *env, uint32_t pos)
+{
+target_ulong dspc;
+
+dspc = env-active_tc.DSPControl;
+#ifndef TARGET_MIPS64
+dspc = dspc  0xFFC0;
+dspc |= pos;
+#else
+dspc = dspc  0xFF80;
+dspc |= pos;
+#endif
+env-active_tc.DSPControl = dspc;
+}
+
+static inline uint32_t get_DSPControl_pos(CPUMIPSState *env)
+{
+target_ulong dspc;
+uint32_t pos;
+
+dspc = env-active_tc.DSPControl;
+
+#ifndef TARGET_MIPS64
+pos = dspc  0x3F;
+#else
+pos = dspc  0x7F;
+#endif
+
+return pos;
+}
+
+static inline void set_DSPControl_efi(CPUMIPSState *env, uint32_t flag)
+{
+env-active_tc.DSPControl = 0xBFFF;
+env-active_tc.DSPControl |= (target_ulong)flag  14;
+}
+
+/* get abs value */
+static inline int8_t mipsdsp_sat_abs_u8(CPUMIPSState *env, uint8_t a)
+{
+int8_t temp;
+temp = a;
+
+if (a == 0x80) {
+set_DSPControl_overflow_flag(env, 1, 20);
+temp = 0x7f;
+} else {
+if ((a  0x80) == 0x80) {
+temp = -temp;
+}
+}
+
+return temp;
+}
+
+static inline int16_t mipsdsp_sat_abs_u16(CPUMIPSState *env, uint16_t a)
+{
+int16_t temp;
+temp = a;
+
+if (a == 0x8000) {
+set_DSPControl_overflow_flag(env, 1, 20);
+temp = 0x7fff;
+} else {
+if ((a  0x8000) == 0x8000) {
+temp = -temp;
+}
+}
+
+return temp;
+}
+
+static inline int32_t mipsdsp_sat_abs_u32(CPUMIPSState *env, uint32_t a)
+{
+int32_t temp;
+temp = a;
+
+if (a == 0x8000) {
+set_DSPControl_overflow_flag(env, 1, 20);
+temp = 0x7FFF;
+} else {
+if ((a  0x8000) == 0x8000) {
+temp = -temp;
+}
+}
+
+return temp;
+}
+
+/* get sum value */
+static inline int16_t mipsdsp_add_i16(CPUMIPSState *env, int16_t a, int16_t b)
+{
+int16_t tempS;
+int32_t tempI, temp15, temp16;
+
+tempS 

[Qemu-devel] [PATCH v6 03/13] target-mips-ase-dsp: Add branch instructions

2012-08-21 Thread Jia Liu
Add MIPS ASE DSP Branch instructions.

Signed-off-by: Jia Liu pro...@gmail.com
---
 target-mips/translate.c |   52 +++
 1 file changed, 48 insertions(+), 4 deletions(-)

diff --git a/target-mips/translate.c b/target-mips/translate.c
index 0793153..b049238 100644
--- a/target-mips/translate.c
+++ b/target-mips/translate.c
@@ -332,6 +332,14 @@ enum {
 OPC_DSHD = (0x05  6) | OPC_DBSHFL,
 };
 
+/* MIPS DSP REGIMM opcodes */
+enum {
+OPC_BPOSGE32 = (0x1C  16) | OPC_REGIMM,
+#if defined(TARGET_MIPS64)
+OPC_BPOSGE64 = (0x1D  16) | OPC_REGIMM,
+#endif
+};
+
 /* Coprocessor 0 (rs field) */
 #define MASK_CP0(op)   MASK_OP_MAJOR(op) | (op  (0x1F  21))
 
@@ -2798,6 +2806,24 @@ static void gen_compute_branch (DisasContext *ctx, 
uint32_t opc,
 }
 btgt = ctx-pc + insn_bytes + offset;
 break;
+case OPC_BPOSGE32:
+tcg_gen_mov_tl(t0, cpu_dspctrl);
+#if defined(TARGET_MIPS64)
+tcg_gen_andi_tl(t0, t0, 0x7F);
+#else
+tcg_gen_andi_tl(t0, t0, 0x3F);
+#endif
+bcond_compute = 1;
+btgt = ctx-pc + insn_bytes + offset;
+break;
+#if defined(TARGET_MIPS64)
+case OPC_BPOSGE64:
+tcg_gen_mov_tl(t0, cpu_dspctrl);
+tcg_gen_andi_tl(t0, t0, 0x7F);
+bcond_compute = 1;
+btgt = ctx-pc + insn_bytes + offset;
+break;
+#endif
 case OPC_J:
 case OPC_JAL:
 case OPC_JALX:
@@ -2986,6 +3012,16 @@ static void gen_compute_branch (DisasContext *ctx, 
uint32_t opc,
 tcg_gen_setcondi_tl(TCG_COND_LT, bcond, t0, 0);
 MIPS_DEBUG(bltzl %s,  TARGET_FMT_lx, regnames[rs], btgt);
 goto likely;
+case OPC_BPOSGE32:
+tcg_gen_setcondi_tl(TCG_COND_GE, bcond, t0, 32);
+MIPS_DEBUG(bposge32 %s,  TARGET_FMT_lx, t0, btgt);
+goto not_likely;
+#if defined(TARGET_MIPS64)
+case OPC_BPOSGE64:
+tcg_gen_setcondi_tl(TCG_COND_GE, bcond, t0, 64);
+MIPS_DEBUG(bposge64 %s,  TARGET_FMT_lx, t0, btgt);
+goto not_likely;
+#endif
 case OPC_BLTZALS:
 case OPC_BLTZAL:
 ctx-hflags |= (opc == OPC_BLTZALS
@@ -11222,10 +11258,6 @@ static void decode_micromips32_opc (CPUMIPSState *env, 
DisasContext *ctx,
 (ctx-opcode  18)  0x7, imm  1);
 *is_branch = 1;
 break;
-case BPOSGE64:
-case BPOSGE32:
-/* MIPS DSP: not implemented */
-/* Fall through */
 default:
 MIPS_INVAL(pool32i);
 generate_exception(ctx, EXCP_RI);
@@ -12134,6 +12166,18 @@ static void decode_opc (CPUMIPSState *env, 
DisasContext *ctx, int *is_branch)
 check_insn(env, ctx, ISA_MIPS32R2);
 /* Treat as NOP. */
 break;
+case OPC_BPOSGE32:/* MIPS DSP branch */
+check_insn(env, ctx, ASE_DSP);
+gen_compute_branch(ctx, op1, 4, -1, -2, (int32_t)imm  2);
+*is_branch = 1;
+break;
+#if defined(TARGET_MIPS64)
+case OPC_BPOSGE64:
+check_insn(env, ctx, ASE_DSP);
+gen_compute_branch(ctx, op1, 4, -1, -2, (int32_t)imm  2);
+*is_branch = 1;
+break;
+#endif
 default:/* Invalid */
 MIPS_INVAL(regimm);
 generate_exception(ctx, EXCP_RI);
-- 
1.7.9.5




[Qemu-devel] [PATCH v6 08/13] target-mips-ase-dsp: Add bit/manipulation instructions

2012-08-21 Thread Jia Liu
Add MIPS ASE DSP Bit/Manipulation instructions.

Signed-off-by: Jia Liu pro...@gmail.com
---
 target-mips/dsp_helper.c |   79 +
 target-mips/helper.h |7 ++
 target-mips/translate.c  |  289 +-
 3 files changed, 374 insertions(+), 1 deletion(-)

diff --git a/target-mips/dsp_helper.c b/target-mips/dsp_helper.c
index ff51d2f..4564d9c 100644
--- a/target-mips/dsp_helper.c
+++ b/target-mips/dsp_helper.c
@@ -6211,6 +6211,85 @@ void helper_dmsubu(CPUMIPSState *env,
 }
 #endif
 
+/** DSP Bit/Manipulation Sub-class insns **/
+target_ulong helper_bitrev(target_ulong rt)
+{
+int32_t temp;
+uint32_t rd;
+int i, last;
+
+temp = rt  MIPSDSP_LO;
+rd = 0;
+for (i = 0; i  16; i++) {
+last = temp % 2;
+temp = temp  1;
+rd = rd | (last  (15 - i));
+}
+
+return (target_ulong)rd;
+}
+
+target_ulong helper_insv(CPUMIPSState *env, target_ulong rs, target_ulong rt)
+{
+uint32_t pos, size, msb, lsb, rs_f, rt_f;
+uint32_t temp, temprs, temprt;
+uint32_t rs_notword, rt_notword;
+target_ulong dspc;
+
+dspc = env-active_tc.DSPControl;
+pos  = dspc  0x1F;
+size = (dspc  7)  0x1F;
+msb  = pos + size - 1;
+lsb  = pos;
+
+rs_notword = not_word_value(rs);
+rt_notword = not_word_value(rt);
+
+if ((lsb  msb) || (rs_notword == 1) || (rt_notword == 1)) {
+return rt;
+}
+
+rs_f = (((int32_t)0x01  (msb - lsb + 1 + 1)) - 1)  lsb;
+rt_f = rs_f ^ 0x;
+temprs = rs  rs_f;
+temprt = rt  rt_f;
+temp = temprs | temprt;
+
+return (target_long)(int32_t)temp;
+}
+
+#if defined(TARGET_MIPS64)
+target_ulong helper_dinsv(CPUMIPSState *env, target_ulong rs, target_ulong rt)
+{
+target_ulong dspctrl;
+target_ulong filter;
+uint8_t pos, size;
+uint8_t msb, lsb;
+uint64_t temp;
+
+temp = rt;
+dspctrl = env-active_tc.DSPControl;
+pos = dspctrl  0x7F;
+size = (dspctrl  7)  0x3F;
+
+msb = pos + size - 1;
+lsb = pos;
+
+if ((lsb  msb) || (msb  63)) {
+return temp;
+}
+
+temp = 0;
+filter = ((target_ulong)0x01  size) - 1;
+filter = filter  pos;
+
+temp |= rs  filter;
+temp |= rt  (~filter);
+
+return temp;
+}
+#endif
+
 #undef MIPSDSP_LHI
 #undef MIPSDSP_LLO
 #undef MIPSDSP_HI
diff --git a/target-mips/helper.h b/target-mips/helper.h
index 69bcb6c..df86ef9 100644
--- a/target-mips/helper.h
+++ b/target-mips/helper.h
@@ -582,4 +582,11 @@ DEF_HELPER_FLAGS_4(dmsub, 0, void, env, tl, tl, i32)
 DEF_HELPER_FLAGS_4(dmsubu, 0, void, env, tl, tl, i32)
 #endif
 
+/* DSP Bit/Manipulation Sub-class insns */
+DEF_HELPER_FLAGS_1(bitrev, TCG_CALL_CONST | TCG_CALL_PURE, tl, tl)
+DEF_HELPER_FLAGS_3(insv, 0, tl, env, tl, tl)
+#if defined(TARGET_MIPS64)
+DEF_HELPER_FLAGS_3(dinsv, 0, tl, env, tl, tl);
+#endif
+
 #include def-helper.h
diff --git a/target-mips/translate.c b/target-mips/translate.c
index d8f83e0..1a9df0f 100644
--- a/target-mips/translate.c
+++ b/target-mips/translate.c
@@ -343,6 +343,11 @@ enum {
 #if defined(TARGET_MIPS64)
 OPC_DPAQ_W_QH_DSP  = 0x34 | OPC_SPECIAL3,
 #endif
+/* DSP Bit/Manipulation Sub-class */
+OPC_INSV_DSP   = 0x0C | OPC_SPECIAL3,
+#if defined(TARGET_MIPS64)
+OPC_DINSV_DSP  = 0x0D | OPC_SPECIAL3,
+#endif
 };
 
 /* BSHFL opcodes */
@@ -450,6 +455,12 @@ enum {
 OPC_PRECEU_PH_QBR   = (0x1D  6) | OPC_ABSQ_S_PH_DSP,
 OPC_PRECEU_PH_QBLA  = (0x1E  6) | OPC_ABSQ_S_PH_DSP,
 OPC_PRECEU_PH_QBRA  = (0x1F  6) | OPC_ABSQ_S_PH_DSP,
+/* DSP Bit/Manipulation Sub-class */
+OPC_BITREV  = (0x1B  6) | OPC_ABSQ_S_PH_DSP,
+OPC_REPL_QB = (0x02  6) | OPC_ABSQ_S_PH_DSP,
+OPC_REPLV_QB= (0x03  6) | OPC_ABSQ_S_PH_DSP,
+OPC_REPL_PH = (0x0A  6) | OPC_ABSQ_S_PH_DSP,
+OPC_REPLV_PH= (0x0B  6) | OPC_ABSQ_S_PH_DSP,
 };
 
 #define MASK_CMPU_EQ_QB(op) (MASK_SPECIAL3(op) | (op  (0x1F  6)))
@@ -518,6 +529,12 @@ enum {
 OPC_MULSA_W_PH= (0x02  6) | OPC_DPA_W_PH_DSP,
 };
 
+#define MASK_INSV(op) (MASK_SPECIAL3(op) | (op  (0x1F  6)))
+enum {
+/* DSP Bit/Manipulation Sub-class */
+OPC_INSV = (0x00  6) | OPC_INSV_DSP,
+};
+
 #if defined(TARGET_MIPS64)
 #define MASK_ABSQ_S_QH(op) (MASK_SPECIAL3(op) | (op  (0x1F  6)))
 enum {
@@ -539,6 +556,13 @@ enum {
 OPC_ABSQ_S_OB   = (0x01  6) | OPC_ABSQ_S_QH_DSP,
 OPC_ABSQ_S_PW   = (0x11  6) | OPC_ABSQ_S_QH_DSP,
 OPC_ABSQ_S_QH   = (0x09  6) | OPC_ABSQ_S_QH_DSP,
+/* DSP Bit/Manipulation Sub-class */
+OPC_REPL_OB = (0x02  6) | OPC_ABSQ_S_QH_DSP,
+OPC_REPL_PW = (0x12  6) | OPC_ABSQ_S_QH_DSP,
+OPC_REPL_QH = (0x0A  6) | OPC_ABSQ_S_QH_DSP,
+OPC_REPLV_OB= (0x03  6) | OPC_ABSQ_S_QH_DSP,
+OPC_REPLV_PW= (0x13  6) | OPC_ABSQ_S_QH_DSP,
+OPC_REPLV_QH= (0x0B  6) | OPC_ABSQ_S_QH_DSP,
 };
 #endif
 
@@ -592,6 +616,14 @@ enum {
 #endif
 
 #if defined(TARGET_MIPS64)
+#define 

Re: [Qemu-devel] [PATCH] Drop redundant resume_all_vcpus from main

2012-08-21 Thread Paolo Bonzini
Il 20/08/2012 20:11, Jan Kiszka ha scritto:
 VCPUs are either resumed directly via vm_start, after the incoming
 migration is done, or when a continue command is issued. We don't need
 the explicit resume before entering main_loop.
 
 Signed-off-by: Jan Kiszka jan.kis...@siemens.com
 ---
 
 I was adding nesting support to pause/resume_all_vcpus, and that
 stumbled over the imbalance below.
 
  vl.c |1 -
  1 files changed, 0 insertions(+), 1 deletions(-)
 
 diff --git a/vl.c b/vl.c
 index ebee867..231d3ab 100644
 --- a/vl.c
 +++ b/vl.c
 @@ -3757,7 +3757,6 @@ int main(int argc, char **argv, char **envp)
  
  os_setup_post();
  
 -resume_all_vcpus();
  main_loop();
  bdrv_close_all();
  pause_all_vcpus();
 

Makes sense.  Do we need a main loop and similar tree, or can that
tree be just uq/master now that qemu-kvm.c is dying?

Paolo



Re: [Qemu-devel] commit da57febfed qdev: give all devices a canonical path broke usb_del

2012-08-21 Thread Paolo Bonzini
Il 20/08/2012 19:58, Anthony Liguori ha scritto:
 Michael Tokarev m...@tls.msk.ru writes:
 
 On 08.08.2012 17:09, Michael Tokarev wrote:
 []
 Something similar should be applied to 1.1-stable.  FWIW, some
 changes are not needed there.

 Cherry-pick to stable-1.1 removes the two unneeded hunks.
 This is what I plan to include into debian package.  It
 fixes the original usb_del issue, and I didn't find new
 regressions so far - tried a few device_del and similar.

 Should it go to qemu/stable-1.1 as well?

 Thank you!

 /mjtAuthor: Paolo Bonzini pbonz...@redhat.com
 Date:   Wed Aug 8 14:39:11 2012 +0200
 Bug-Debian: http://bugs.debian.org/684282
 Comment: cherry-picked from qemu/master to stable-1.1 (mjt)

 qom: object_delete should unparent the object first
 
 object_deinit is only called when the reference count goes to zero,
 and yet tries to do an object_unparent.  Now, object_unparent
 either does nothing or it will decrease the reference count.
 Because we know the reference count is zero, the object_unparent
 call in object_deinit is useless.
 
 Instead, we need to disconnect the object from its parent just
 before we remove the last reference apart from the parent's.  This
 happens in object_delete.  Once we do this, all calls to
 object_unparent peppered through QEMU can go away.
 
 Signed-off-by: Paolo Bonzini pbonz...@redhat.com
 Signed-off-by: Michael Tokarev m...@tls.msk.ru

 diff --git a/hw/acpi_piix4.c b/hw/acpi_piix4.c
 index 0345490..585da4e 100644
 --- a/hw/acpi_piix4.c
 +++ b/hw/acpi_piix4.c
 @@ -299,7 +299,6 @@ static void acpi_piix_eject_slot(PIIX4PMState *s, 
 unsigned slots)
  if (pc-no_hotplug) {
  slot_free = false;
  } else {
 -object_unparent(OBJECT(dev));
  qdev_free(qdev);
  }
  }
 diff --git a/hw/qdev.c b/hw/qdev.c
 index 6a8f6bd..9bb1c6b 100644
 --- a/hw/qdev.c
 +++ b/hw/qdev.c
 @@ -240,7 +240,6 @@ void qbus_reset_all_fn(void *opaque)
  int qdev_simple_unplug_cb(DeviceState *dev)
  {
  /* just zap it */
 -object_unparent(OBJECT(dev));
  qdev_free(dev);
  return 0;
  }
 diff --git a/hw/xen_platform.c b/hw/xen_platform.c
 index 0214f37..84221df 100644
 --- a/hw/xen_platform.c
 +++ b/hw/xen_platform.c
 @@ -87,9 +87,6 @@ static void unplug_nic(PCIBus *b, PCIDevice *d)
  {
  if (pci_get_word(d-config + PCI_CLASS_DEVICE) ==
  PCI_CLASS_NETWORK_ETHERNET) {
 -/* Until qdev_free includes a call to object_unparent, we call it 
 here
 - */
 -object_unparent(d-qdev.parent_obj);
  qdev_free(d-qdev);
  }
  }
 diff --git a/qom/object.c b/qom/object.c
 index 6f839ad..58dd886 100644
 --- a/qom/object.c
 +++ b/qom/object.c
 @@ -347,8 +347,6 @@ static void object_deinit(Object *obj, TypeImpl *type)
  if (type_has_parent(type)) {
  object_deinit(obj, type_get_parent(type));
  }
 -
 -object_unparent(obj);
  }
  
  void object_finalize(void *data)
 @@ -385,8 +383,9 @@ Object *object_new(const char *typename)
  
  void object_delete(Object *obj)
  {
 +object_unparent(obj);
 +g_assert(obj-ref == 1);
  object_unref(obj);
 -g_assert(obj-ref == 0);
  g_free(obj);
  }
 
 This won't work with composition.  object_delete() is never called for
 child objects.

For non-heap-allocated children, their last ref will go away when the
parent's child property is eliminated.  This will remove the last
reference and call object_finalize (which will take care of multiple
levels of compositions).

The same holds for heap-allocated children, but indeed you will leak the
memory for the object because object_delete is not called.  However this
is already the case, the patch is not introducing a regression.

Paolo



Re: [Qemu-devel] [PATCH v2 2/5] spice: notify on vm state change only via spice_server_vm_start/stop

2012-08-21 Thread Yonit Halperin

Hi,
On 08/21/2012 09:58 AM, Gerd Hoffmann wrote:

   Hi,


+#if SPICE_SERVER_VERSION= 0x000b02 /* 0.11.2 */
+static void display_start(void)
+{
+DisplayListItem *item;
+
+QLIST_FOREACH(item,display_list, link) {
+item-display-running = true;
+}
+}


I think we should simply use a global variable for 'running' here.  It's
global state anyway.  Having this in per-display state struct buys us
nothing and adds alot of code for updating and display list maintainance.


ok, good point.

  void qemu_spice_vm_change_state_handler(void *opaque, int running,
  RunState state)
  {
+#if SPICE_SERVER_VERSION  0x000b02 /* before 0.11.2 */
  SimpleSpiceDisplay *ssd = opaque;



+#if SPICE_SERVER_VERSION  0x000b02 /* before 0.11.2 */
  
qemu_add_vm_change_state_handler(qemu_spice_vm_change_state_handler,sdpy);
+#endif


If you don't register qemu_spice_vm_change_state_handler on new
spice-server you should #ifdef the whole function, not the body only.

qemu_spice_vm_change_state_handler is also called from qxl.c, as part of 
its own vm_change_state handler. I didn't want to add another ifdef there.



cheers,
   Gerd





[Qemu-devel] [PATCH v6 11/13] target-mips-ase-dsp: Add MIPS[32|64] ASE DSP[R1|R2] generic cpu model

2012-08-21 Thread Jia Liu
Add MIPS[32|64] ASE DSP[R1|R2] generic cpu model for test.

Signed-off-by: Jia Liu pro...@gmail.com
---
 target-mips/translate_init.c |   55 ++
 1 file changed, 55 insertions(+)

diff --git a/target-mips/translate_init.c b/target-mips/translate_init.c
index c39138f..547fa00 100644
--- a/target-mips/translate_init.c
+++ b/target-mips/translate_init.c
@@ -311,6 +311,32 @@ static const mips_def_t mips_defs[] =
 .insn_flags = CPU_MIPS32R2 | ASE_MIPS16 | ASE_DSP | ASE_MT,
 .mmu_type = MMU_TYPE_R4000,
 },
+{
+/* A generic CPU providing MIPS32 ASE DSP Release 2 features.
+   FIXME: Eventually this should be replaced by a real CPU model. */
+.name = mips32dspr2,
+.CP0_PRid = 0x00019300,
+.CP0_Config0 = MIPS_CONFIG0 | (0x1  CP0C0_AR) |
+(MMU_TYPE_R4000  CP0C0_MT),
+.CP0_Config1 = MIPS_CONFIG1 | (1  CP0C1_FP) | (15  CP0C1_MMU) |
+   (0  CP0C1_IS) | (3  CP0C1_IL) | (1  CP0C1_IA) |
+   (0  CP0C1_DS) | (3  CP0C1_DL) | (1  CP0C1_DA) |
+   (1  CP0C1_CA),
+.CP0_Config2 = MIPS_CONFIG2,
+.CP0_Config3 = MIPS_CONFIG3 | (0  CP0C3_VInt),
+.CP0_LLAddr_rw_bitmask = 0,
+.CP0_LLAddr_shift = 4,
+.SYNCI_Step = 32,
+.CCRes = 2,
+/* No DSP implemented. */
+.CP0_Status_rw_bitmask = 0x3678FF1F,
+.CP1_fcr0 = (1  FCR0_F64) | (1  FCR0_L) | (1  FCR0_W) |
+(1  FCR0_D) | (1  FCR0_S) | (0x93  FCR0_PRID),
+.SEGBITS = 32,
+.PABITS = 32,
+.insn_flags = CPU_MIPS32R2 | ASE_MIPS16 | ASE_DSP | ASE_DSPR2,
+.mmu_type = MMU_TYPE_R4000,
+},
 #if defined(TARGET_MIPS64)
 {
 .name = R4000,
@@ -484,6 +510,35 @@ static const mips_def_t mips_defs[] =
   .insn_flags = CPU_LOONGSON2F,
   .mmu_type = MMU_TYPE_R4000,
 },
+{
+/* A generic CPU providing MIPS64 ASE DSP Release 2 features.
+   FIXME: Eventually this should be replaced by a real CPU model. */
+.name = mips64dspr2,
+/* We emulate a later version of the 20Kc, earlier ones had a broken
+   WAIT instruction. */
+.CP0_PRid = 0x000182a0,
+.CP0_Config0 = MIPS_CONFIG0 | (0x2  CP0C0_AT) |
+(MMU_TYPE_R4000  CP0C0_MT) | (1  CP0C0_VI),
+.CP0_Config1 = MIPS_CONFIG1 | (1  CP0C1_FP) | (47  CP0C1_MMU) |
+   (2  CP0C1_IS) | (4  CP0C1_IL) | (3  CP0C1_IA) |
+   (2  CP0C1_DS) | (4  CP0C1_DL) | (3  CP0C1_DA) |
+   (1  CP0C1_PC) | (1  CP0C1_WR) | (1  CP0C1_EP),
+.CP0_Config2 = MIPS_CONFIG2,
+.CP0_Config3 = MIPS_CONFIG3,
+.CP0_LLAddr_rw_bitmask = 0,
+.CP0_LLAddr_shift = 0,
+.SYNCI_Step = 32,
+.CCRes = 1,
+.CP0_Status_rw_bitmask = 0x36FB,
+/* The 20Kc has F64 / L / W but doesn't use the fcr0 bits. */
+.CP1_fcr0 = (1  FCR0_3D) | (1  FCR0_PS) |
+(1  FCR0_D) | (1  FCR0_S) |
+(0x82  FCR0_PRID) | (0x0  FCR0_REV),
+.SEGBITS = 40,
+.PABITS = 36,
+.insn_flags = CPU_MIPS64R2 | ASE_DSP | ASE_DSPR2,
+.mmu_type = MMU_TYPE_R4000,
+},
 
 #endif
 };
-- 
1.7.9.5




[Qemu-devel] [PATCH v6 09/13] target-mips-ase-dsp: Add compare pick instructions

2012-08-21 Thread Jia Liu
Add MIPS ASE DSP Compare-Pick instructions.

Signed-off-by: Jia Liu pro...@gmail.com
---
 target-mips/dsp_helper.c |  917 ++
 target-mips/helper.h |   52 +++
 target-mips/translate.c  |  323 
 3 files changed, 1292 insertions(+)

diff --git a/target-mips/dsp_helper.c b/target-mips/dsp_helper.c
index 4564d9c..f41808e 100644
--- a/target-mips/dsp_helper.c
+++ b/target-mips/dsp_helper.c
@@ -6290,6 +6290,923 @@ target_ulong helper_dinsv(CPUMIPSState *env, 
target_ulong rs, target_ulong rt)
 }
 #endif
 
+/** DSP Compare-Pick Sub-class insns **/
+void helper_cmpu_eq_qb(CPUMIPSState *env, target_ulong rs, target_ulong rt)
+{
+uint8_t rs3, rs2, rs1, rs0;
+uint8_t rt3, rt2, rt1, rt0;
+uint32_t cc3 = 0, cc2 = 0, cc1 = 0, cc0 = 0;
+uint32_t flag;
+
+rs3 = (rs  MIPSDSP_Q3)  24;
+rs2 = (rs  MIPSDSP_Q2)  16;
+rs1 = (rs  MIPSDSP_Q1)   8;
+rs0 =  rs  MIPSDSP_Q0;
+
+rt3 = (rt  MIPSDSP_Q3)  24;
+rt2 = (rt  MIPSDSP_Q2)  16;
+rt1 = (rt  MIPSDSP_Q1)   8;
+rt0 =  rt  MIPSDSP_Q0;
+
+cc3 = (rs3 == rt3);
+cc2 = (rs2 == rt2);
+cc1 = (rs1 == rt1);
+cc0 = (rs0 == rt0);
+
+flag = (cc3  3) | (cc2  2) | (cc1  1) | cc0;
+set_DSPControl_24(env, flag, 4);
+}
+
+void helper_cmpu_lt_qb(CPUMIPSState *env, target_ulong rs, target_ulong rt)
+{
+uint8_t rs3, rs2, rs1, rs0;
+uint8_t rt3, rt2, rt1, rt0;
+uint32_t cc3 = 0, cc2 = 0, cc1 = 0, cc0 = 0;
+uint32_t flag;
+
+rs3 = (rs  MIPSDSP_Q3)  24;
+rs2 = (rs  MIPSDSP_Q2)  16;
+rs1 = (rs  MIPSDSP_Q1)   8;
+rs0 =  rs  MIPSDSP_Q0;
+
+rt3 = (rt  MIPSDSP_Q3)  24;
+rt2 = (rt  MIPSDSP_Q2)  16;
+rt1 = (rt  MIPSDSP_Q1)   8;
+rt0 =  rt  MIPSDSP_Q0;
+
+cc3 = (rs3  rt3);
+cc2 = (rs2  rt2);
+cc1 = (rs1  rt1);
+cc0 = (rs0  rt0);
+
+flag = (cc3  3) | (cc2  2) | (cc1  1) | cc0;
+set_DSPControl_24(env, flag, 4);
+}
+
+void helper_cmpu_le_qb(CPUMIPSState *env, target_ulong rs, target_ulong rt)
+{
+uint8_t rs3, rs2, rs1, rs0;
+uint8_t rt3, rt2, rt1, rt0;
+uint32_t cc3 = 0, cc2 = 0, cc1 = 0, cc0 = 0;
+uint32_t flag;
+
+rs3 = (rs  MIPSDSP_Q3)  24;
+rs2 = (rs  MIPSDSP_Q2)  16;
+rs1 = (rs  MIPSDSP_Q1)   8;
+rs0 =  rs  MIPSDSP_Q0;
+
+rt3 = (rt  MIPSDSP_Q3)  24;
+rt2 = (rt  MIPSDSP_Q2)  16;
+rt1 = (rt  MIPSDSP_Q1)   8;
+rt0 =  rt  MIPSDSP_Q0;
+
+cc3 = (rs3 = rt3);
+cc2 = (rs2 = rt2);
+cc1 = (rs1 = rt1);
+cc0 = (rs0 = rt0);
+
+flag = (cc3  3) | (cc2  2) | (cc1  1) | cc0;
+set_DSPControl_24(env, flag, 4);
+}
+
+
+target_ulong helper_cmpgu_eq_qb(target_ulong rs, target_ulong rt)
+{
+uint8_t rs3, rs2, rs1, rs0;
+uint8_t rt3, rt2, rt1, rt0;
+uint8_t cc3 = 0, cc2 = 0, cc1 = 0, cc0 = 0;
+uint32_t temp;
+uint32_t rd;
+
+rs3 = (rs  MIPSDSP_Q3)  24;
+rs2 = (rs  MIPSDSP_Q2)  16;
+rs1 = (rs  MIPSDSP_Q1)   8;
+rs0 =  rs  MIPSDSP_Q0;
+
+rt3 = (rt  MIPSDSP_Q3)  24;
+rt2 = (rt  MIPSDSP_Q2)  16;
+rt1 = (rt  MIPSDSP_Q1)   8;
+rt0 =  rt  MIPSDSP_Q0;
+
+cc3 = (rs3 == rt3);
+cc2 = (rs2 == rt2);
+cc1 = (rs1 == rt1);
+cc0 = (rs0 == rt0);
+
+temp = (cc3  3) | (cc2  2) | (cc1  1) | cc0;
+rd = temp;
+
+return (target_ulong)rd;
+}
+
+target_ulong helper_cmpgu_lt_qb(target_ulong rs, target_ulong rt)
+{
+uint8_t rs3, rs2, rs1, rs0;
+uint8_t rt3, rt2, rt1, rt0;
+uint32_t cc3 = 0, cc2 = 0, cc1 = 0, cc0 = 0;
+uint32_t temp;
+uint32_t rd;
+
+rs3 = (rs  MIPSDSP_Q3)  24;
+rs2 = (rs  MIPSDSP_Q2)  16;
+rs1 = (rs  MIPSDSP_Q1)   8;
+rs0 =  rs  MIPSDSP_Q0;
+
+rt3 = (rt  MIPSDSP_Q3)  24;
+rt2 = (rt  MIPSDSP_Q2)  16;
+rt1 = (rt  MIPSDSP_Q1)   8;
+rt0 =  rt  MIPSDSP_Q0;
+
+cc3 = (rs3  rt3);
+cc2 = (rs2  rt2);
+cc1 = (rs1  rt1);
+cc0 = (rs0  rt0);
+
+temp = (cc3  3) | (cc2  2) | (cc1  1) | cc0;
+rd = temp;
+
+return (target_ulong)rd;
+}
+
+target_ulong helper_cmpgu_le_qb(target_ulong rs, target_ulong rt)
+{
+uint8_t rs3, rs2, rs1, rs0;
+uint8_t rt3, rt2, rt1, rt0;
+uint32_t cc3 = 0, cc2 = 0, cc1 = 0, cc0 = 0;
+uint32_t temp;
+uint32_t rd;
+
+rs3 = (rs  MIPSDSP_Q3)  24;
+rs2 = (rs  MIPSDSP_Q2)  16;
+rs1 = (rs  MIPSDSP_Q1)   8;
+rs0 =  rs  MIPSDSP_Q0;
+
+rt3 = (rt  MIPSDSP_Q3)  24;
+rt2 = (rt  MIPSDSP_Q2)  16;
+rt1 = (rt  MIPSDSP_Q1)   8;
+rt0 =  rt  MIPSDSP_Q0;
+
+cc3 = (rs3 = rt3);
+cc2 = (rs2 = rt2);
+cc1 = (rs1 = rt1);
+cc0 = (rs0 = rt0);
+
+temp = (cc3  3) | (cc2  2) | (cc1  1) | cc0;
+rd = temp;
+
+return (target_ulong)rd;
+}
+
+void helper_cmp_eq_ph(CPUMIPSState *env, target_ulong rs, target_ulong rt)
+{
+int16_t rsh, rsl, rth, rtl;
+int32_t flag;
+int32_t ccA = 0, ccB = 0;
+
+rsh = (rs  MIPSDSP_HI)  16;
+rsl =  rs  MIPSDSP_LO;
+rth = (rt  MIPSDSP_HI)  16;
+rtl =  rt  MIPSDSP_LO;
+
+ccB = (rsh == rth);
+ccA = (rsl == 

[Qemu-devel] [PATCH v6 06/13] target-mips-ase-dsp: Add GPR Based shift instructions

2012-08-21 Thread Jia Liu
Add MIPS ASE DSP GPR-Based Shift instructions.

Signed-off-by: Jia Liu pro...@gmail.com
---
 target-mips/dsp_helper.c |  991 ++
 target-mips/helper.h |   62 +++
 target-mips/translate.c  |  359 +
 3 files changed, 1412 insertions(+)

diff --git a/target-mips/dsp_helper.c b/target-mips/dsp_helper.c
index 486b22f..8e7bccb 100644
--- a/target-mips/dsp_helper.c
+++ b/target-mips/dsp_helper.c
@@ -3196,6 +3196,997 @@ target_ulong helper_preceu_qh_obra(target_ulong rt)
 }
 #endif
 
+/** DSP GPR-Based Shift Sub-class insns **/
+target_ulong helper_shll_qb(CPUMIPSState *env, uint32_t sa, target_ulong rt)
+{
+uint8_t  rt3, rt2, rt1, rt0;
+uint8_t  tempD, tempC, tempB, tempA;
+uint32_t rd;
+
+rt3 = (rt  MIPSDSP_Q3)  24;
+rt2 = (rt  MIPSDSP_Q2)  16;
+rt1 = (rt  MIPSDSP_Q1)   8;
+rt0 =  rt  MIPSDSP_Q0;
+
+tempD = mipsdsp_lshift8(env, rt3, sa);
+tempC = mipsdsp_lshift8(env, rt2, sa);
+tempB = mipsdsp_lshift8(env, rt1, sa);
+tempA = mipsdsp_lshift8(env, rt0, sa);
+rd = ((uint32_t)tempD  24) | ((uint32_t)tempC  16) |
+ ((uint32_t)tempB   8) | ((uint32_t)tempA);
+
+return (target_long)(int32_t)rd;
+}
+
+target_ulong helper_shllv_qb(CPUMIPSState *env,
+ target_ulong rs, target_ulong rt)
+{
+uint8_t  rs2_0;
+uint8_t  rt3, rt2, rt1, rt0;
+uint8_t  tempD, tempC, tempB, tempA;
+uint32_t rd;
+
+rs2_0 = rs  0x07;
+rt3   = (rt  MIPSDSP_Q3)  24;
+rt2   = (rt  MIPSDSP_Q2)  16;
+rt1   = (rt  MIPSDSP_Q1)   8;
+rt0   =  rt  MIPSDSP_Q0;
+
+tempD = mipsdsp_lshift8(env, rt3, rs2_0);
+tempC = mipsdsp_lshift8(env, rt2, rs2_0);
+tempB = mipsdsp_lshift8(env, rt1, rs2_0);
+tempA = mipsdsp_lshift8(env, rt0, rs2_0);
+
+rd = ((uint32_t)tempD  24) | ((uint32_t)tempC  16) |
+ ((uint32_t)tempB   8) | (uint32_t)tempA;
+
+return (target_long)(int32_t)rd;
+}
+
+#if defined(TARGET_MIPS64)
+target_ulong helper_shll_ob(CPUMIPSState *env, target_ulong rt, uint32_t sa)
+{
+int i;
+uint8_t rt_t[8];
+uint8_t temp_t[8];
+uint64_t temp;
+
+sa = sa  0x07;
+temp = 0;
+
+for (i = 0; i  8; i++) {
+rt_t[i] = (rt  (8 * i))  MIPSDSP_Q0;
+temp_t[i] = mipsdsp_lshift8(env, rt_t[i], sa);
+
+temp |= (uint64_t)temp_t[i]  (8 * i);
+}
+
+return temp;
+}
+
+target_ulong helper_shllv_ob(CPUMIPSState *env,
+ target_ulong rt, target_ulong sa)
+{
+int i;
+uint8_t rt_t[8];
+uint8_t temp_t[8];
+uint64_t temp;
+
+sa = sa  0x07;
+temp = 0;
+
+for (i = 0; i  8; i++) {
+rt_t[i] = (rt  (8 * i))  MIPSDSP_Q0;
+temp_t[i] = mipsdsp_lshift8(env, rt_t[i], sa);
+
+temp |= (uint64_t)temp_t[i]  (8 * i);
+}
+
+return temp;
+}
+#endif
+
+target_ulong helper_shll_ph(CPUMIPSState *env, uint32_t sa, target_ulong rt)
+{
+uint16_t rth, rtl;
+uint16_t tempB, tempA;
+uint32_t rd;
+
+rth = (rt  MIPSDSP_HI)  16;
+rtl =  rt  MIPSDSP_LO;
+tempB = mipsdsp_lshift16(env, rth, sa);
+tempA = mipsdsp_lshift16(env, rtl, sa);
+rd = ((uint32_t)tempB  16) | (uint32_t)tempA;
+
+return (target_long)(int32_t)rd;
+}
+
+target_ulong helper_shllv_ph(CPUMIPSState *env,
+ target_ulong rs, target_ulong rt)
+{
+uint8_t  rs3_0;
+uint16_t rth, rtl, tempB, tempA;
+uint32_t rd;
+
+rth   = (rt  MIPSDSP_HI)  16;
+rtl   =  rt  MIPSDSP_LO;
+rs3_0 = rs  0x0F;
+
+tempB = mipsdsp_lshift16(env, rth, rs3_0);
+tempA = mipsdsp_lshift16(env, rtl, rs3_0);
+rd = ((uint32_t)tempB  16) | (uint32_t)tempA;
+
+return (target_long)(int32_t)rd;
+}
+
+target_ulong helper_shll_s_ph(CPUMIPSState *env, uint32_t sa, target_ulong rt)
+{
+uint16_t rth, rtl;
+uint16_t tempB, tempA;
+uint32_t rd;
+
+rth = (rt  MIPSDSP_HI)  16;
+rtl =  rt  MIPSDSP_LO;
+tempB = mipsdsp_sat16_lshift(env, rth, sa);
+tempA = mipsdsp_sat16_lshift(env, rtl, sa);
+rd = ((uint32_t)tempB  16) | (uint32_t)tempA;
+
+return (target_long)(int32_t)rd;
+}
+
+target_ulong helper_shllv_s_ph(CPUMIPSState *env,
+   target_ulong rs, target_ulong rt)
+{
+uint8_t  rs3_0;
+uint16_t rth, rtl, tempB, tempA;
+uint32_t rd;
+
+rth   = (rt  MIPSDSP_HI)  16;
+rtl   =  rt  MIPSDSP_LO;
+rs3_0 = rs  0x0F;
+
+tempB = mipsdsp_sat16_lshift(env, rth, rs3_0);
+tempA = mipsdsp_sat16_lshift(env, rtl, rs3_0);
+rd = ((uint32_t)tempB  16) | (uint32_t)tempA;
+
+return (target_long)(int32_t)rd;
+}
+
+#if defined(TARGET_MIPS64)
+target_ulong helper_shll_qh(CPUMIPSState *env, target_ulong rt, uint32_t sa)
+{
+uint16_t rt3, rt2, rt1, rt0;
+uint16_t tempD, tempC, tempB, tempA;
+uint64_t temp;
+
+sa = sa  0x0F;
+
+rt3 = (rt  48)  MIPSDSP_LO;
+rt2 = (rt  32)  MIPSDSP_LO;
+rt1 = (rt  16)  MIPSDSP_LO;
+rt0 = rt  MIPSDSP_LO;
+
+

[Qemu-devel] [PATCH v6 02/13] target-mips-ase-dsp: Use correct acc value to index cpu_HI/cpu_LO rather than using a fix number

2012-08-21 Thread Jia Liu
Use correct acc value to index cpu_HI/cpu_LO rather than using a fix number.

Signed-off-by: Jia Liu pro...@gmail.com
---
 target-mips/translate.c |  107 +++
 1 file changed, 81 insertions(+), 26 deletions(-)

diff --git a/target-mips/translate.c b/target-mips/translate.c
index 47daf85..0793153 100644
--- a/target-mips/translate.c
+++ b/target-mips/translate.c
@@ -5,6 +5,7 @@
  *  Copyright (c) 2006 Marius Groeger (FPU operations)
  *  Copyright (c) 2006 Thiemo Seufer (MIPS32R2 support)
  *  Copyright (c) 2009 CodeSourcery (MIPS16 and microMIPS support)
+ *  Copyright (c) 2012 Jia Liu  Dongxue Zhang (MIPS ASE DSP support)
  *
  * This library is free software; you can redistribute it and/or
  * modify it under the terms of the GNU Lesser General Public
@@ -1972,6 +1973,7 @@ static void gen_shift (CPUMIPSState *env, DisasContext 
*ctx, uint32_t opc,
 static void gen_HILO (DisasContext *ctx, uint32_t opc, int reg)
 {
 const char *opn = hilo;
+unsigned int acc;
 
 if (reg == 0  (opc == OPC_MFHI || opc == OPC_MFLO)) {
 /* Treat as NOP. */
@@ -1980,25 +1982,71 @@ static void gen_HILO (DisasContext *ctx, uint32_t opc, 
int reg)
 }
 switch (opc) {
 case OPC_MFHI:
-tcg_gen_mov_tl(cpu_gpr[reg], cpu_HI[0]);
+acc = ((ctx-opcode)  21)  0x03;
+#if defined(TARGET_MIPS64)
+if (acc == 0) {
+tcg_gen_mov_tl(cpu_gpr[reg], cpu_HI[acc]);
+} else {
+tcg_gen_ext32s_tl(cpu_gpr[reg], cpu_HI[acc]);
+}
+#else
+tcg_gen_mov_tl(cpu_gpr[reg], cpu_HI[acc]);
+#endif
 opn = mfhi;
 break;
 case OPC_MFLO:
-tcg_gen_mov_tl(cpu_gpr[reg], cpu_LO[0]);
+acc = ((ctx-opcode)  21)  0x03;
+#if defined(TARGET_MIPS64)
+if (acc == 0) {
+tcg_gen_mov_tl(cpu_gpr[reg], cpu_LO[acc]);
+} else {
+tcg_gen_ext32s_tl(cpu_gpr[reg], cpu_LO[acc]);
+}
+#else
+tcg_gen_mov_tl(cpu_gpr[reg], cpu_LO[acc]);
+#endif
 opn = mflo;
 break;
 case OPC_MTHI:
-if (reg != 0)
-tcg_gen_mov_tl(cpu_HI[0], cpu_gpr[reg]);
-else
-tcg_gen_movi_tl(cpu_HI[0], 0);
+acc = ((ctx-opcode)  11)  0x03;
+#if defined(TARGET_MIPS64)
+if (reg != 0) {
+if (acc == 0) {
+tcg_gen_mov_tl(cpu_HI[acc], cpu_gpr[reg]);
+} else {
+tcg_gen_ext32s_tl(cpu_HI[acc], cpu_gpr[reg]);
+}
+} else {
+tcg_gen_movi_tl(cpu_HI[acc], 0);
+}
+#else
+if (reg != 0) {
+tcg_gen_mov_tl(cpu_HI[acc], cpu_gpr[reg]);
+} else {
+tcg_gen_movi_tl(cpu_HI[acc], 0);
+}
+#endif
 opn = mthi;
 break;
 case OPC_MTLO:
-if (reg != 0)
-tcg_gen_mov_tl(cpu_LO[0], cpu_gpr[reg]);
-else
-tcg_gen_movi_tl(cpu_LO[0], 0);
+acc = ((ctx-opcode)  11)  0x03;
+#if defined(TARGET_MIPS64)
+if (reg != 0) {
+if (acc == 0) {
+tcg_gen_mov_tl(cpu_LO[acc], cpu_gpr[reg]);
+} else {
+tcg_gen_ext32s_tl(cpu_LO[acc], cpu_gpr[reg]);
+}
+} else {
+tcg_gen_movi_tl(cpu_LO[acc], 0);
+}
+#else
+if (reg != 0) {
+tcg_gen_mov_tl(cpu_LO[acc], cpu_gpr[reg]);
+} else {
+tcg_gen_movi_tl(cpu_LO[acc], 0);
+}
+#endif
 opn = mtlo;
 break;
 }
@@ -2011,6 +2059,7 @@ static void gen_muldiv (DisasContext *ctx, uint32_t opc,
 {
 const char *opn = mul/div;
 TCGv t0, t1;
+unsigned int acc;
 
 switch (opc) {
 case OPC_DIV:
@@ -2073,6 +2122,7 @@ static void gen_muldiv (DisasContext *ctx, uint32_t opc,
 {
 TCGv_i64 t2 = tcg_temp_new_i64();
 TCGv_i64 t3 = tcg_temp_new_i64();
+acc = ((ctx-opcode)  11)  0x03;
 
 tcg_gen_ext_tl_i64(t2, t0);
 tcg_gen_ext_tl_i64(t3, t1);
@@ -2082,8 +2132,8 @@ static void gen_muldiv (DisasContext *ctx, uint32_t opc,
 tcg_gen_shri_i64(t2, t2, 32);
 tcg_gen_trunc_i64_tl(t1, t2);
 tcg_temp_free_i64(t2);
-tcg_gen_ext32s_tl(cpu_LO[0], t0);
-tcg_gen_ext32s_tl(cpu_HI[0], t1);
+tcg_gen_ext32s_tl(cpu_LO[acc], t0);
+tcg_gen_ext32s_tl(cpu_HI[acc], t1);
 }
 opn = mult;
 break;
@@ -2091,6 +2141,7 @@ static void gen_muldiv (DisasContext *ctx, uint32_t opc,
 {
 TCGv_i64 t2 = tcg_temp_new_i64();
 TCGv_i64 t3 = tcg_temp_new_i64();
+acc = ((ctx-opcode)  11)  0x03;
 
 tcg_gen_ext32u_tl(t0, t0);
 tcg_gen_ext32u_tl(t1, t1);
@@ -2102,8 +2153,8 @@ static void gen_muldiv (DisasContext *ctx, uint32_t opc,
 tcg_gen_shri_i64(t2, t2, 32);
 tcg_gen_trunc_i64_tl(t1, t2);
 tcg_temp_free_i64(t2);
-

Re: [Qemu-devel] [PATCH v2 2/5] spice: notify on vm state change only via spice_server_vm_start/stop

2012-08-21 Thread Gerd Hoffmann
On 08/21/12 09:09, Yonit Halperin wrote:
 Hi,
 On 08/21/2012 09:58 AM, Gerd Hoffmann wrote:
Hi,

 +#if SPICE_SERVER_VERSION= 0x000b02 /* 0.11.2 */
 +static void display_start(void)
 +{
 +DisplayListItem *item;
 +
 +QLIST_FOREACH(item,display_list, link) {
 +item-display-running = true;
 +}
 +}

 I think we should simply use a global variable for 'running' here.  It's
 global state anyway.  Having this in per-display state struct buys us
 nothing and adds alot of code for updating and display list maintainance.

 ok, good point.
   void qemu_spice_vm_change_state_handler(void *opaque, int running,
   RunState state)
   {
 +#if SPICE_SERVER_VERSION  0x000b02 /* before 0.11.2 */
   SimpleSpiceDisplay *ssd = opaque;

 +#if SPICE_SERVER_VERSION  0x000b02 /* before 0.11.2 */
  
 qemu_add_vm_change_state_handler(qemu_spice_vm_change_state_handler,sdpy);

 +#endif

 If you don't register qemu_spice_vm_change_state_handler on new
 spice-server you should #ifdef the whole function, not the body only.

 qemu_spice_vm_change_state_handler is also called from qxl.c, as part of
 its own vm_change_state handler. I didn't want to add another ifdef there.

Fair point, but then you can drop the #ifdef for the
qemu_add_vm_change_state_handler call too.

cheers,
  Gerd




Re: [Qemu-devel] qemu log function to print out the registers of the guest

2012-08-21 Thread Max Filippov
On Tue, Aug 21, 2012 at 9:40 AM, Steven wangwangk...@gmail.com wrote:
 Hi, Max,
 I wrote a small program to verify your patch could catch all the load
 instructions from the guest. However, I found some problem from the
 results.

 The guest OS and the emulated machine are both 32bit x86. My simple
 program in the guest declares an 1048576-element integer array,
 initialize the elements, and load them in a loop. It looks like this
   int array[1048576];
   initialize the array;

   /*  region of interests */
   int temp;
   for (i=0; i  1048576; i++) {
   temp = array[i];
   }
 So ideally, the path should catch the guest virtual address of in the
 loop, right?
   In addition, the virtual address for the beginning and end
 of the array is 0xbf68b6e0 and 0xbfa8b6e0.
   What i got is as follows

   __ldl_mmu, vaddr=bf68b6e0
   __ldl_mmu, vaddr=bf68b6e4
   __ldl_mmu, vaddr=bf68b6e8
   .
   These should be the virtual address of the above loop. The
 results look good because the gap between each vaddr is 4 bypte, which
 is the length of each element.
   However, after certain address, I got

   __ldl_mmu, vaddr=bf68bffc
   __ldl_mmu, vaddr=bf68c000
   __ldl_mmu, vaddr=bf68d000
   __ldl_mmu, vaddr=bf68e000
   __ldl_mmu, vaddr=bf68f000
   __ldl_mmu, vaddr=bf69
   __ldl_mmu, vaddr=bf691000
   __ldl_mmu, vaddr=bf692000
   __ldl_mmu, vaddr=bf693000
   __ldl_mmu, vaddr=bf694000
   ...
   __ldl_mmu, vaddr=bf727000
   __ldl_mmu, vaddr=bf728000
   __ldl_mmu, vaddr=bfa89000
   __ldl_mmu, vaddr=bfa8a000
 So the rest of the vaddr I got has a different of 4096 bytes, instead
 of 4. I repeated the experiment for several times and got the same
 results. Is there anything wrong? or could you explain this? Thanks.

I see two possibilities here:
- maybe there are more fast path shortcuts in the QEMU code?
  in that case output of qemu -d op,out_asm would help.
- maybe your compiler had optimized that sample code?
  could you try to declare array in your sample as 'volatile int'?

-- 
Thanks.
-- Max



[Qemu-devel] [PATCH v6 10/13] target-mips-ase-dsp: Add MIPS ASE DSP Accumulator and DSPControl Access instructions

2012-08-21 Thread Jia Liu
Add MIPS ASE DSP Accumulator and DSPControl Access instructions.

Signed-off-by: Jia Liu pro...@gmail.com
---
 target-mips/dsp_helper.c | 1044 ++
 target-mips/helper.h |   52 +++
 target-mips/translate.c  |  461 
 3 files changed, 1557 insertions(+)

diff --git a/target-mips/dsp_helper.c b/target-mips/dsp_helper.c
index f41808e..332e7c2 100644
--- a/target-mips/dsp_helper.c
+++ b/target-mips/dsp_helper.c
@@ -7207,6 +7207,1050 @@ target_ulong helper_packrl_pw(target_ulong rs, 
target_ulong rt)
 }
 #endif
 
+/** DSP Accumulator and DSPControl Access Sub-class insns **/
+target_ulong helper_extr_w(CPUMIPSState *env, uint32_t ac, uint32_t shift)
+{
+int32_t tempI;
+int64_t tempDL[2];
+
+mipsdsp__rashift_short_acc(env, tempDL, ac, shift);
+if ((tempDL[1] != 0 || (tempDL[0]  MIPSDSP_LHI) != 0) 
+(tempDL[1] != 1 || (tempDL[0]  MIPSDSP_LHI) != MIPSDSP_LHI)) {
+set_DSPControl_overflow_flag(env, 1, 23);
+}
+
+tempI = (tempDL[0]  1)  MIPSDSP_LLO;
+
+tempDL[0] += 1;
+if (tempDL[0] == 0) {
+tempDL[1] += 1;
+}
+
+if ((!(tempDL[1] == 0  (tempDL[0]  MIPSDSP_LHI) == 0x00)) 
+(!(tempDL[1] == 1  (tempDL[0]  MIPSDSP_LHI) == MIPSDSP_LHI))) {
+set_DSPControl_overflow_flag(env, 1, 23);
+}
+
+return (target_long)tempI;
+}
+
+target_ulong helper_extr_r_w(CPUMIPSState *env, uint32_t ac, uint32_t shift)
+{
+int32_t tempI;
+int64_t tempDL[2];
+
+mipsdsp__rashift_short_acc(env, tempDL, ac, shift);
+if ((tempDL[1] != 0 || (tempDL[0]  MIPSDSP_LHI) != 0) 
+(tempDL[1] != 1 || (tempDL[0]  MIPSDSP_LHI) != MIPSDSP_LHI)) {
+set_DSPControl_overflow_flag(env, 1, 23);
+}
+
+tempDL[0] += 1;
+if (tempDL[0] == 0) {
+tempDL[1] += 1;
+}
+
+if ((tempDL[1] != 0 || (tempDL[0]  MIPSDSP_LHI) != 0) 
+(tempDL[1] != 1  (tempDL[0]  MIPSDSP_LHI) != MIPSDSP_LHI)) {
+set_DSPControl_overflow_flag(env, 1, 23);
+}
+tempI = tempDL[0]  1;
+
+return (target_long)tempI;
+}
+
+target_ulong helper_extr_rs_w(CPUMIPSState *env, uint32_t ac, uint32_t shift)
+{
+int32_t tempI, temp64;
+int64_t tempDL[2];
+
+mipsdsp__rashift_short_acc(env, tempDL, ac, shift);
+if ((tempDL[1] != 0 || (tempDL[0]  MIPSDSP_LHI) != 0) 
+(tempDL[1] != 1 || (tempDL[0]  MIPSDSP_LHI) != MIPSDSP_LHI)) {
+set_DSPControl_overflow_flag(env, 1, 23);
+}
+tempDL[0] += 1;
+if (tempDL[0] == 0) {
+tempDL[1] += 1;
+}
+tempI = tempDL[0]  1;
+
+if ((tempDL[1] != 0 || (tempDL[0]  MIPSDSP_LHI) != 0) 
+(tempDL[1] != 1 || (tempDL[0]  MIPSDSP_LHI) != MIPSDSP_LHI)) {
+temp64 = tempDL[1];
+if (temp64 == 0) {
+tempI = 0x7FFF;
+} else {
+tempI = 0x8000;
+}
+set_DSPControl_overflow_flag(env, 1, 23);
+}
+
+return (target_long)tempI;
+}
+
+#if defined(TARGET_MIPS64)
+target_ulong helper_dextr_w(CPUMIPSState *env, uint32_t ac, uint32_t shift)
+{
+uint64_t temp[3];
+uint64_t result;
+
+mipsdsp__rashift_acc(env, temp, ac, shift);
+
+result = (int64_t)(int32_t)(temp[0]  1);
+
+return result;
+}
+
+target_ulong helper_dextr_r_w(CPUMIPSState *env, uint32_t ac, uint32_t shift)
+{
+uint64_t temp[3];
+uint32_t temp128;
+uint64_t result;
+
+mipsdsp__rashift_acc(env, temp, ac, shift);
+
+temp[0] += 1;
+if (temp[0] == 0) {
+temp[1] += 1;
+if (temp[1] == 0) {
+temp[2] += 1;
+}
+}
+
+temp128 = temp[2]  0x01;
+
+if ((temp128 != 0 || temp[1] != 0) 
+   (temp128 != 1 || temp[1] != 0xfffFfffFfffFfffFull)) {
+set_DSPControl_overflow_flag(env, 1, 23);
+}
+
+result = (int64_t)(int32_t)(temp[0]  1);
+
+return result;
+}
+
+target_ulong helper_dextr_rs_w(CPUMIPSState *env, uint32_t ac, uint32_t shift)
+{
+uint64_t temp[3];
+uint32_t temp128;
+uint64_t result;
+
+mipsdsp__rashift_acc(env, temp, ac, shift);
+
+temp[0] += 1;
+if (temp[0] == 0) {
+temp[1] += 1;
+if (temp[1] == 0) {
+temp[2] += 1;
+}
+}
+
+temp128 = temp[2]  0x01;
+
+if ((temp128 != 0 || temp[1] != 0) 
+   (temp128 != 1 || temp[1] != 0xull)) {
+if (temp128 == 0) {
+temp[0] = 0x0;
+} else {
+temp[0] = 0x01;
+}
+set_DSPControl_overflow_flag(env, 1, 23);
+}
+
+result = (int64_t)(int32_t)(temp[0]  1);
+
+return result;
+}
+
+target_ulong helper_dextr_l(CPUMIPSState *env, uint32_t ac, uint32_t shift)
+{
+uint64_t temp[3];
+uint64_t result;
+
+mipsdsp__rashift_acc(env, temp, ac, shift);
+
+result = (temp[1]  63) | (temp[0]  1);
+
+return result;
+}
+
+target_ulong helper_dextr_r_l(CPUMIPSState *env, uint32_t ac, uint32_t shift)
+{
+uint64_t temp[3];
+uint32_t temp128;
+uint64_t result;

[Qemu-devel] Dump guest page table inside QEMU makes system hang

2012-08-21 Thread Wei-Ren Chen
Hi all,

  I want to dump guest page table when guest writes to cr3,
the code snipt below,

---
uint32_t pgd[1024][1024]; // guest page table
static void dump_guest_pgtable(target_ulong cr3)
{
int i, j;
uint32_t phyaddr = cr3;
uint32_t val;

for (i = 0; i  NUM_ENTRY; ++i)
{
phyaddr += i * 4;
for (j = 0; j  NUM_ENTRY; ++j)
{
cpu_physical_memory_read(phyaddr, val, 4);
pgd[i][j] = val;
}
}
}

void cpu_x86_update_cr3(CPUX86State *env, target_ulong new_cr3)
{
env-cr[3] = new_cr3; // guest cr3

if (env-cr[0]  CR0_PG_MASK) {
tlb_flush(env, 0);

// dump guest page table by using guest cr3
dump_guest_pgtable(new_cr3);
}
}
---

  The system will hang while booting. However, if I comment 
cpu_physical_memory_read in function dump_guest_pgtable, there
is no problem. What I am missing here? Thanks.

Regards,
chenwj

-- 
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Homepage: http://people.cs.nctu.edu.tw/~chenwj



Re: [Qemu-devel] qemu-kvm-1.0.1 - unable to exit if vcpu is in infinite loop

2012-08-21 Thread Jan Kiszka
On 2012-08-19 11:42, Avi Kivity wrote:
 On 08/17/2012 06:04 PM, Jan Kiszka wrote:
  
 Can anyone imagine that such a barrier may actually be required? If it
 is currently possible that env-stop is evaluated before we called into
 sigtimedwait in qemu_kvm_eat_signals, then we could actually eat the
 signal without properly processing its reason (stop).

 Should not be required (TM): Both signal eating / stop checking and stop
 setting / signal generation happens under the BQL, thus the ordering
 must not make a difference here.
 
 Agree.
 
 
 Don't see where we could lose a signal. Maybe due to a subtle memory
 corruption that sets thread_kicked to non-zero, preventing the kicking
 this way.
 
 Cannot be ruled out, yet too much of a coincidence.
 
 Could be a kernel bug (either in kvm or elsewhere), we've had several
 before in this area.
 
 Is this reproducible?

Not for me. Peter only hit it very rarely, Peter obviously more easily.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux



Re: [Qemu-devel] [PATCH] Drop redundant resume_all_vcpus from main

2012-08-21 Thread Jan Kiszka
On 2012-08-21 09:01, Paolo Bonzini wrote:
 Il 20/08/2012 20:11, Jan Kiszka ha scritto:
 VCPUs are either resumed directly via vm_start, after the incoming
 migration is done, or when a continue command is issued. We don't need
 the explicit resume before entering main_loop.

 Signed-off-by: Jan Kiszka jan.kis...@siemens.com
 ---

 I was adding nesting support to pause/resume_all_vcpus, and that
 stumbled over the imbalance below.

  vl.c |1 -
  1 files changed, 0 insertions(+), 1 deletions(-)

 diff --git a/vl.c b/vl.c
 index ebee867..231d3ab 100644
 --- a/vl.c
 +++ b/vl.c
 @@ -3757,7 +3757,6 @@ int main(int argc, char **argv, char **envp)
  
  os_setup_post();
  
 -resume_all_vcpus();
  main_loop();
  bdrv_close_all();
  pause_all_vcpus();

 
 Makes sense.  Do we need a main loop and similar tree, or can that
 tree be just uq/master now that qemu-kvm.c is dying?

I'm not sure if this qualifies for uq/master. On the other hand, all the
efforts to refactor locking and make QEMU more scalable would like be
happy to have a home. Can be uq/master, but they will not only affect
KVM in the end.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux



[Qemu-devel] [PATCH v6 04/13] target-mips-ase-dsp: Add load instructions

2012-08-21 Thread Jia Liu
Add MIPS ASE DSP Load instructions.

Signed-off-by: Jia Liu pro...@gmail.com
---
 target-mips/translate.c |   69 +++
 1 file changed, 69 insertions(+)

diff --git a/target-mips/translate.c b/target-mips/translate.c
index b049238..f154f09 100644
--- a/target-mips/translate.c
+++ b/target-mips/translate.c
@@ -313,6 +313,9 @@ enum {
 OPC_MODU_G_2E   = 0x23 | OPC_SPECIAL3,
 OPC_DMOD_G_2E   = 0x26 | OPC_SPECIAL3,
 OPC_DMODU_G_2E  = 0x27 | OPC_SPECIAL3,
+
+/* MIPS DSP Load */
+OPC_LX_DSP = 0x0A | OPC_SPECIAL3,
 };
 
 /* BSHFL opcodes */
@@ -340,6 +343,17 @@ enum {
 #endif
 };
 
+#define MASK_LX(op) (MASK_SPECIAL3(op) | (op  (0x1F  6)))
+/* MIPS DSP Load */
+enum {
+OPC_LBUX = (0x06  6) | OPC_LX_DSP,
+OPC_LHX  = (0x04  6) | OPC_LX_DSP,
+OPC_LWX  = (0x00  6) | OPC_LX_DSP,
+#if defined(TARGET_MIPS64)
+OPC_LDX = (0x08  6) | OPC_LX_DSP,
+#endif
+};
+
 /* Coprocessor 0 (rs field) */
 #define MASK_CP0(op)   MASK_OP_MAJOR(op) | (op  (0x1F  21))
 
@@ -12124,6 +12138,61 @@ static void decode_opc (CPUMIPSState *env, 
DisasContext *ctx, int *is_branch)
 check_insn(env, ctx, INSN_LOONGSON2E);
 gen_loongson_integer(ctx, op1, rd, rs, rt);
 break;
+case OPC_LX_DSP:
+op2 = MASK_LX(ctx-opcode);
+switch (op2) {
+case OPC_LBUX:
+check_insn(env, ctx, ASE_DSP);
+{
+TCGv addr = tcg_temp_new();
+
+save_cpu_state(ctx, 1);
+gen_op_addr_add(ctx, addr, cpu_gpr[rs], cpu_gpr[rt]);
+op_ld_lbu(cpu_gpr[rd], addr, ctx);
+tcg_temp_free(addr);
+break;
+}
+case OPC_LHX:
+check_insn(env, ctx, ASE_DSP);
+{
+TCGv addr = tcg_temp_new();
+
+save_cpu_state(ctx, 1);
+gen_op_addr_add(ctx, addr, cpu_gpr[rs], cpu_gpr[rt]);
+op_ld_lh(cpu_gpr[rd], addr, ctx);
+tcg_temp_free(addr);
+break;
+}
+case OPC_LWX:
+check_insn(env, ctx, ASE_DSP);
+{
+TCGv addr = tcg_temp_new();
+
+save_cpu_state(ctx, 1);
+gen_op_addr_add(ctx, addr, cpu_gpr[rs], cpu_gpr[rt]);
+op_ld_lw(cpu_gpr[rd], addr, ctx);
+tcg_temp_free(addr);
+break;
+}
+#if defined(TARGET_MIPS64)
+case OPC_LDX:
+check_insn(env, ctx, ASE_DSP);
+{
+TCGv addr = tcg_temp_new();
+
+save_cpu_state(ctx, 1);
+gen_op_addr_add(ctx, addr, cpu_gpr[rs], cpu_gpr[rt]);
+op_ld_ld(cpu_gpr[rd], addr, ctx);
+tcg_temp_free(addr);
+break;
+}
+#endif
+default:/* Invalid */
+MIPS_INVAL(MASK LX);
+generate_exception(ctx, EXCP_RI);
+break;
+}
+break;
 #if defined(TARGET_MIPS64)
 case OPC_DEXTM ... OPC_DEXT:
 case OPC_DINSM ... OPC_DINS:
-- 
1.7.9.5




Re: [Qemu-devel] [PATCH RFT 0/3] iscsi: fix NULL dereferences / races between task completion and abort

2012-08-21 Thread Stefan Priebe - Profihost AG

Am 21.08.2012 00:36, schrieb ronnie sahlberg:

On Mon, Aug 20, 2012 at 6:12 PM, Stefan Priebe - Profihost AG
s.pri...@profihost.ag wrote:

Hi Ronnie,

Am 20.08.2012 10:08, schrieb Paolo Bonzini:


That's because the big QEMU lock is held by the thread that called
qemu_aio_cancel.


and i also see
no cancellation message in kernel log.



And that's because the UNMAP actually ultimately succeeds.  You'll
probably see soft lockup messages though.

The solution here is to bump the timeout of the UNMAP command (either in
the kernel or in libiscsi, I didn't really understand who's at fault).



What's your suggestion / idea about that?



There are no timeouts in libiscsi itself.
But you can probably tweak it through the guest kernel :


$ cat /sys/bus/scsi/devices/0\:0\:0\:0/timeout
30

should be the default scsi timeout for this device, and

$ cat /sys/bus/scsi/devices/0\:0\:0\:0/queue_depth
31

would be how many concurrent i/o that the guest will drive to the device.


When performing the UNMAPS, maybe setting timeout to something really
big, and at the same time also dropping queue-depth to something
really small so that the guest kernel will not be able to send so many
UNMAPs concurrently.


How is this relevant to the fact, that i can't even work with SSH any 
longer with paolo's patch while UNMAPs are running? With my patchset you 
can still work on the machine.


Greets,
Stefan



Re: [Qemu-devel] [PATCH RFT 0/3] iscsi: fix NULL dereferences / races between task completion and abort

2012-08-21 Thread Paolo Bonzini
  When performing the UNMAPS, maybe setting timeout to something
  really big, and at the same time also dropping queue-depth to something
  really small so that the guest kernel will not be able to send so
  many UNMAPs concurrently.
 
 How is this relevant to the fact, that i can't even work with SSH any
 longer with paolo's patch while UNMAPs are running? With my patchset
 you can still work on the machine.

It is relevant because if you tweak the timeouts you will not hit the
cancel at all.

I would like to get a trace of the commands that are sent, so that we
can attack the problem in the guest kernel.  For example, if it's sending
UNMAPs that span 100GB or so, we could enforce a limit in the guest kernel
on the maximum number of discarded blocks per UNMAP.  But if the problem
is the _number_ of UNMAPs rather than the size, it would need a different
heuristic.

Paolo



Re: [Qemu-devel] x86, nops settings result in kernel crash

2012-08-21 Thread Michael Tokarev
On 20.08.2012 21:13, Tomas Racek wrote:
[]
Can we trim the old, large and now not-so-relevant discussion please? ;)

 I can provide you with more different traces if it can help. But I thought 
 that maybe it will be more useful for you to try it on your own. So I've 
 prepared some minimal debian installation which you could download here (apx 
 163M bzipped):
 
 http://fi.muni.cz/~xracek/debian.img.bz2
 
 Password:
 root/asdfgh
 
 Here is my config for guest kernel:
 
 http://fi.muni.cz/~xracek/config
 
 I use
 
 qemu-kvm -m 1500 -hda debian.img -kernel linux/arch/x86/boot/bzImage -append 
 root=/dev/sda1

Um.  I'd expect the image to be self-contained, no external kernel.
I wanted to do a quick test to see if it fails on my machine too,
d/loaded debian.img.bz2 but there's no kernel.  So.. no quick test
for you ;)

 After logging in just run sh runtest.sh. This leads to crash in my case 
 (host: Intel Core i5-2540M, kernel 3.5.2-1.fc17.x86_64, qemu 1.0.1).

With all the above, this runtest.sh is informationally equal to
your disk image.

/mjt



Re: [Qemu-devel] [PATCH v2 2/5] spice: notify on vm state change only via spice_server_vm_start/stop

2012-08-21 Thread Gerd Hoffmann
  Hi,

 +#if SPICE_SERVER_VERSION = 0x000b02 /* 0.11.2 */
 +static void display_start(void)
 +{
 +DisplayListItem *item;
 +
 +QLIST_FOREACH(item, display_list, link) {
 +item-display-running = true;
 +}
 +}

I think we should simply use a global variable for 'running' here.  It's
global state anyway.  Having this in per-display state struct buys us
nothing and adds alot of code for updating and display list maintainance.

  void qemu_spice_vm_change_state_handler(void *opaque, int running,
  RunState state)
  {
 +#if SPICE_SERVER_VERSION  0x000b02 /* before 0.11.2 */
  SimpleSpiceDisplay *ssd = opaque;

 +#if SPICE_SERVER_VERSION  0x000b02 /* before 0.11.2 */
  qemu_add_vm_change_state_handler(qemu_spice_vm_change_state_handler, 
 sdpy);
 +#endif

If you don't register qemu_spice_vm_change_state_handler on new
spice-server you should #ifdef the whole function, not the body only.

cheers,
  Gerd



Re: [Qemu-devel] [PATCH v2] kvm-all.c: Move init of irqchip_inject_ioctl out of kvm_irqchip_create()

2012-08-21 Thread Jan Kiszka
On 2012-08-15 13:08, Peter Maydell wrote:
 Move the init of the irqchip_inject_ioctl field of KVMState out of
 kvm_irqchip_create() and into kvm_init(), so that kvm_set_irq()
 can be used even when no irqchip is created (for architectures
 that support async interrupt notification even without an in
 kernel irqchip).
 
 Signed-off-by: Peter Maydell peter.mayd...@linaro.org
 ---
 Changes v1-v2: move whe whole chunk of init code, for both
 KVM_IRQ_LINE and KVM_IRQ_LINE_STATUS possibilities.
 
  kvm-all.c |9 +
  1 file changed, 5 insertions(+), 4 deletions(-)
 
 diff --git a/kvm-all.c b/kvm-all.c
 index 34b02c1..72d84a2 100644
 --- a/kvm-all.c
 +++ b/kvm-all.c
 @@ -1200,10 +1200,6 @@ static int kvm_irqchip_create(KVMState *s)
  return ret;
  }
  
 -s-irqchip_inject_ioctl = KVM_IRQ_LINE;
 -if (kvm_check_extension(s, KVM_CAP_IRQ_INJECT_STATUS)) {
 -s-irqchip_inject_ioctl = KVM_IRQ_LINE_STATUS;
 -}
  kvm_kernel_irqchip = true;
  /* If we have an in-kernel IRQ chip then we must have asynchronous
   * interrupt delivery (though the reverse is not necessarily true)
 @@ -1350,6 +1346,11 @@ int kvm_init(void)
  s-direct_msi = (kvm_check_extension(s, KVM_CAP_SIGNAL_MSI)  0);
  #endif
  
 +s-irqchip_inject_ioctl = KVM_IRQ_LINE;
 +if (kvm_check_extension(s, KVM_CAP_IRQ_INJECT_STATUS)) {
 +s-irqchip_inject_ioctl = KVM_IRQ_LINE_STATUS;
 +}
 +
  ret = kvm_arch_init(s);
  if (ret  0) {
  goto err;
 

As it's not yet merged, some late comment: irqchip_inject_ioctl should
be renamed as well. irq_inject_ioctl?

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux



Re: [Qemu-devel] qemu-kvm-1.0.1 - unable to exit if vcpu is in infinite loop

2012-08-21 Thread Stefan Hajnoczi
On Tue, Aug 21, 2012 at 8:21 AM, Jan Kiszka jan.kis...@siemens.com wrote:
 On 2012-08-19 11:42, Avi Kivity wrote:
 On 08/17/2012 06:04 PM, Jan Kiszka wrote:

 Can anyone imagine that such a barrier may actually be required? If it
 is currently possible that env-stop is evaluated before we called into
 sigtimedwait in qemu_kvm_eat_signals, then we could actually eat the
 signal without properly processing its reason (stop).

 Should not be required (TM): Both signal eating / stop checking and stop
 setting / signal generation happens under the BQL, thus the ordering
 must not make a difference here.

 Agree.


 Don't see where we could lose a signal. Maybe due to a subtle memory
 corruption that sets thread_kicked to non-zero, preventing the kicking
 this way.

 Cannot be ruled out, yet too much of a coincidence.

 Could be a kernel bug (either in kvm or elsewhere), we've had several
 before in this area.

 Is this reproducible?

 Not for me. Peter only hit it very rarely, Peter obviously more easily.

I have only hit this once and was not able to reproduce it.

Stefan



Re: [Qemu-devel] [PATCH v2] kvm-all.c: Move init of irqchip_inject_ioctl out of kvm_irqchip_create()

2012-08-21 Thread Peter Maydell
On 21 August 2012 09:19, Jan Kiszka jan.kis...@siemens.com wrote:
 On 2012-08-15 13:08, Peter Maydell wrote:
 Move the init of the irqchip_inject_ioctl field of KVMState out of
 kvm_irqchip_create() and into kvm_init(), so that kvm_set_irq()
 can be used even when no irqchip is created (for architectures
 that support async interrupt notification even without an in
 kernel irqchip).

 As it's not yet merged, some late comment: irqchip_inject_ioctl should
 be renamed as well. irq_inject_ioctl?

If we're changing it anyway, IIRC Avi didn't like the term inject
here?

-- PMM



[Qemu-devel] [PATCH 1/2 v1] blkdrv: Add queue limits parameters for sg block drive

2012-08-21 Thread Cong Meng
This patch adds some queue limit parameters into block drive. And inits them
for sg block drive. Some interfaces are also added for accessing them.

Signed-off-by: Cong Meng m...@linux.vnet.ibm.com
---
 block/raw-posix.c |   58 +
 block_int.h   |4 +++
 blockdev.c|   15 +
 hw/block-common.h |3 ++
 4 files changed, 80 insertions(+), 0 deletions(-)

diff --git a/block/raw-posix.c b/block/raw-posix.c
index 0dce089..a086f89 100644
--- a/block/raw-posix.c
+++ b/block/raw-posix.c
@@ -53,6 +53,7 @@
 #include linux/cdrom.h
 #include linux/fd.h
 #include linux/fs.h
+#include dirent.h
 #endif
 #ifdef CONFIG_FIEMAP
 #include linux/fiemap.h
@@ -829,6 +830,62 @@ static int hdev_probe_device(const char *filename)
 return 0;
 }
 
+static void read_queue_limit(char *path, const char *filename, unsigned int 
*val)
+{
+FILE *f;
+char *tail = path + strlen(path);
+
+pstrcat(path, MAXPATHLEN, filename);
+f = fopen(path, r);
+if (!f) {
+goto out;
+}
+
+fscanf(f, %u, val);
+fclose(f);
+
+out:
+*tail = 0;
+}
+
+static void sg_get_queue_limits(BlockDriverState *bs, const char *filename)
+{
+DIR *ffs;
+struct dirent *d;
+char path[MAXPATHLEN];
+
+snprintf(path, MAXPATHLEN,
+ /sys/class/scsi_generic/sg%s/device/block/,
+ filename + strlen(/dev/sg));
+
+ffs = opendir(path);
+if (!ffs) {
+return;
+}
+
+for (;;) {
+d = readdir(ffs);
+if (!d) {
+return;
+}
+
+if (strcmp(d-d_name, .) == 0 || strcmp(d-d_name, ..) == 0) {
+continue;
+}
+
+break;
+}
+
+closedir(ffs);
+
+pstrcat(path, MAXPATHLEN, d-d_name);
+pstrcat(path, MAXPATHLEN, /queue/);
+
+read_queue_limit(path, max_sectors_kb, bs-max_sectors);
+read_queue_limit(path, max_segments, bs-max_segments);
+read_queue_limit(path, max_segment_size, bs-max_segment_size);
+}
+
 static int hdev_open(BlockDriverState *bs, const char *filename, int flags)
 {
 BDRVRawState *s = bs-opaque;
@@ -868,6 +925,7 @@ static int hdev_open(BlockDriverState *bs, const char 
*filename, int flags)
 temp = realpath(filename, resolved_path);
 if (temp  strstart(temp, /dev/sg, NULL)) {
 bs-sg = 1;
+sg_get_queue_limits(bs, temp);
 }
 }
 #endif
diff --git a/block_int.h b/block_int.h
index d72317f..a9d07a2 100644
--- a/block_int.h
+++ b/block_int.h
@@ -333,6 +333,10 @@ struct BlockDriverState {
 
 /* long-running background operation */
 BlockJob *job;
+
+unsigned int max_sectors;
+unsigned int max_segments;
+unsigned int max_segment_size;
 };
 
 int get_tmp_filename(char *filename, int size);
diff --git a/blockdev.c b/blockdev.c
index 3d75015..e17edbf 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -1191,3 +1191,18 @@ BlockJobInfoList *qmp_query_block_jobs(Error **errp)
 bdrv_iterate(do_qmp_query_block_jobs_one, prev);
 return dummy.next;
 }
+
+unsigned int get_queue_max_sectors(BlockDriverState *bs)
+{
+return (bs-file  bs-file-sg) ? bs-file-max_sectors : 0;
+}
+
+unsigned int get_queue_max_segments(BlockDriverState *bs)
+{
+return (bs-file  bs-file-sg) ? bs-file-max_segments : 0;
+}
+
+unsigned int get_queue_max_segment_size(BlockDriverState *bs)
+{
+return (bs-file  bs-file-sg) ? bs-file-max_segment_size : 0;
+}
diff --git a/hw/block-common.h b/hw/block-common.h
index bb808f7..d47fcd7 100644
--- a/hw/block-common.h
+++ b/hw/block-common.h
@@ -76,4 +76,7 @@ void hd_geometry_guess(BlockDriverState *bs,
int *ptrans);
 int hd_bios_chs_auto_trans(uint32_t cyls, uint32_t heads, uint32_t secs);
 
+unsigned int get_queue_max_sectors(BlockDriverState *bs);
+unsigned int get_queue_max_segments(BlockDriverState *bs);
+unsigned int get_queue_max_segment_size(BlockDriverState *bs);
 #endif
-- 
1.7.7.6




[Qemu-devel] [PATCH 2/2 v1] virtio-scsi: set per-LUN queue limits for sg devices

2012-08-21 Thread Cong Meng
Each virtio scsi HBA has global request queue limits. But the passthrough
LUNs (scsi-generic) come from different host HBAs may have different request
queue limits. If the guest sends commands that exceed the host limits, the
commands will be rejected by host HAB. 

To address the issue, this patch responses the newly added virtio control
queue request by returning the per-LUN queue limits.

Signed-off-by: Cong Meng m...@linux.vnet.ibm.com
---
 hw/virtio-scsi.c |   65 ++
 1 files changed, 65 insertions(+), 0 deletions(-)

diff --git a/hw/virtio-scsi.c b/hw/virtio-scsi.c
index c4a5b22..3c0bd99 100644
--- a/hw/virtio-scsi.c
+++ b/hw/virtio-scsi.c
@@ -28,6 +28,7 @@
 #define VIRTIO_SCSI_F_INOUT0
 #define VIRTIO_SCSI_F_HOTPLUG  1
 #define VIRTIO_SCSI_F_CHANGE   2
+#define VIRTIO_SCSI_F_LUN_QUERY3
 
 /* Response codes */
 #define VIRTIO_SCSI_S_OK   0
@@ -48,6 +49,7 @@
 #define VIRTIO_SCSI_T_TMF  0
 #define VIRTIO_SCSI_T_AN_QUERY 1
 #define VIRTIO_SCSI_T_AN_SUBSCRIBE 2
+#define VIRTIO_SCSI_T_LUN_QUERY3
 
 /* Valid TMF subtypes.  */
 #define VIRTIO_SCSI_T_TMF_ABORT_TASK   0
@@ -66,6 +68,11 @@
 #define VIRTIO_SCSI_T_ASYNC_NOTIFY 2
 #define VIRTIO_SCSI_T_PARAM_CHANGE 3
 
+/* LUN Query */
+#define VIRTIO_SCSI_T_LQ_MAX_SECTORS   0
+#define VIRTIO_SCSI_T_LQ_MAX_SEGMENTS  1
+#define VIRTIO_SCSI_T_LQ_MAX_SEGMENT_SIZE  2
+
 /* Reasons for transport reset event */
 #define VIRTIO_SCSI_EVT_RESET_HARD 0
 #define VIRTIO_SCSI_EVT_RESET_RESCAN   1
@@ -115,6 +122,18 @@ typedef struct {
 uint8_t response;
 } QEMU_PACKED VirtIOSCSICtrlANResp;
 
+/* LUN qeury */
+typedef struct {
+uint32_t type;
+uint8_t lun[8];
+uint32_t subtype;
+} QEMU_PACKED VirtIOSCSICtrlLQReq;
+
+typedef struct {
+uint32_t response;
+uint32_t value;
+} QEMU_PACKED VirtIOSCSICtrlLQResp;
+
 typedef struct {
 uint32_t event;
 uint8_t lun[8];
@@ -160,6 +179,7 @@ typedef struct VirtIOSCSIReq {
 VirtIOSCSICmdReq  *cmd;
 VirtIOSCSICtrlTMFReq  *tmf;
 VirtIOSCSICtrlANReq   *an;
+VirtIOSCSICtrlLQReq   *lq;
 } req;
 union {
 char  *buf;
@@ -167,6 +187,7 @@ typedef struct VirtIOSCSIReq {
 VirtIOSCSICtrlTMFResp *tmf;
 VirtIOSCSICtrlANResp  *an;
 VirtIOSCSIEvent   *event;
+VirtIOSCSICtrlLQResp  *lq;
 } resp;
 } VirtIOSCSIReq;
 
@@ -285,6 +306,43 @@ static void *virtio_scsi_load_request(QEMUFile *f, 
SCSIRequest *sreq)
 return req;
 }
 
+static void virtio_scsi_do_lun_query(VirtIOSCSI *s, VirtIOSCSIReq *req)
+{
+SCSIDevice *d = virtio_scsi_device_find(s, req-req.lq-lun);
+
+if (!d) {
+goto fail;
+}
+
+switch (req-req.lq-subtype) {
+case VIRTIO_SCSI_T_LQ_MAX_SECTORS:
+req-resp.lq-value = get_queue_max_sectors(d-conf.bs);
+if (!req-resp.lq-value) {
+goto fail;
+}
+break;
+case VIRTIO_SCSI_T_LQ_MAX_SEGMENTS:
+req-resp.lq-value = get_queue_max_segments(d-conf.bs);
+if (!req-resp.lq-value) {
+goto fail;
+}
+break;
+case VIRTIO_SCSI_T_LQ_MAX_SEGMENT_SIZE:
+req-resp.lq-value = get_queue_max_segment_size(d-conf.bs);
+if (!req-resp.lq-value) {
+goto fail;
+}
+break;
+default:
+goto fail;
+}
+
+req-resp.lq-response = VIRTIO_SCSI_S_OK;
+return;
+fail:
+req-resp.lq-response = VIRTIO_SCSI_S_FAILURE;
+}
+
 static void virtio_scsi_do_tmf(VirtIOSCSI *s, VirtIOSCSIReq *req)
 {
 SCSIDevice *d = virtio_scsi_device_find(s, req-req.tmf-lun);
@@ -414,6 +472,12 @@ static void virtio_scsi_handle_ctrl(VirtIODevice *vdev, 
VirtQueue *vq)
 }
 req-resp.an-event_actual = 0;
 req-resp.an-response = VIRTIO_SCSI_S_OK;
+} else if (req-req.lq-type == VIRTIO_SCSI_T_LUN_QUERY) {
+if (out_size  sizeof(VirtIOSCSICtrlLQReq) ||
+in_size  sizeof(VirtIOSCSICtrlLQResp)) {
+virtio_scsi_bad_req();
+}
+virtio_scsi_do_lun_query(s, req);
 }
 virtio_scsi_complete_req(req);
 }
@@ -557,6 +621,7 @@ static uint32_t virtio_scsi_get_features(VirtIODevice *vdev,
 {
 requested_features |= (1UL  VIRTIO_SCSI_F_HOTPLUG);
 requested_features |= (1UL  VIRTIO_SCSI_F_CHANGE);
+requested_features |= (1UL  VIRTIO_SCSI_F_LUN_QUERY);
 return requested_features;
 }
 
-- 
1.7.7.6




[Qemu-devel] [PATCH v1] virtio-scsi: get and set the queue limits for sg device

2012-08-21 Thread Cong Meng
Each virtio scsi HBA has global request queue limits. But the passthrough
LUNs (scsi-generic) come from different host HBAs may have different request
queue limits. If the guest sends commands that exceed the host limits, the
commands will be rejected by host HAB. 

This patch addresses this issue by getting the per-LUN queue limits via the the
newly added virtio control request, then setting them properly.

Signed-off-by: Cong Meng m...@linux.vnet.ibm.com
---
 drivers/scsi/virtio_scsi.c  |  113 +--
 include/linux/virtio_scsi.h |   18 +++
 2 files changed, 116 insertions(+), 15 deletions(-)

diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
index 173cb39..ec5066f 100644
--- a/drivers/scsi/virtio_scsi.c
+++ b/drivers/scsi/virtio_scsi.c
@@ -35,12 +35,14 @@ struct virtio_scsi_cmd {
struct virtio_scsi_cmd_req   cmd;
struct virtio_scsi_ctrl_tmf_req  tmf;
struct virtio_scsi_ctrl_an_req   an;
+   struct virtio_scsi_ctrl_lq_req   lq;
} req;
union {
struct virtio_scsi_cmd_resp  cmd;
struct virtio_scsi_ctrl_tmf_resp tmf;
struct virtio_scsi_ctrl_an_resp  an;
struct virtio_scsi_event evt;
+   struct virtio_scsi_ctrl_lq_resp  lq;
} resp;
 } cacheline_aligned_in_smp;
 
@@ -469,6 +471,46 @@ out:
return ret;
 }
 
+static u32 virtscsi_lun_query(struct scsi_device *sdev, u32 *value, u32 
subtype)
+{
+   struct Scsi_Host *shost = sdev-host;
+   struct virtio_scsi *vscsi = shost_priv(shost);
+   DECLARE_COMPLETION_ONSTACK(comp);
+   struct virtio_scsi_cmd *cmd;
+   struct virtio_scsi_target_state *tgt = vscsi-tgt[sdev-id];
+   unsigned int ret = VIRTIO_SCSI_S_FAILURE;
+
+   cmd = mempool_alloc(virtscsi_cmd_pool, GFP_ATOMIC);
+   if (!cmd)
+   goto out;
+
+   memset(cmd, 0, sizeof(*cmd));
+   cmd-comp = comp;
+   cmd-req.lq = (struct virtio_scsi_ctrl_lq_req){
+   .type = VIRTIO_SCSI_T_LUN_QUERY,
+   .subtype = subtype,
+   .lun[0] = 1,
+   .lun[1] = sdev-id,
+   .lun[2] = (sdev-lun  8) | 0x40,
+   .lun[3] = sdev-lun  0xff,
+   };
+
+   if (virtscsi_kick_cmd(tgt, vscsi-ctrl_vq, cmd, sizeof cmd-req.lq,
+   sizeof cmd-resp.lq, GFP_NOIO)  0) {
+   goto out;
+   }
+
+   wait_for_completion(comp);
+
+   ret = cmd-resp.lq.response;
+   if (ret == VIRTIO_SCSI_S_OK) {
+   *value = cmd-resp.lq.value;
+   }
+out:
+   mempool_free(cmd, virtscsi_cmd_pool);
+   return ret;
+}
+
 static int virtscsi_device_reset(struct scsi_cmnd *sc)
 {
struct virtio_scsi *vscsi = shost_priv(sc-device-host);
@@ -516,20 +558,6 @@ static int virtscsi_abort(struct scsi_cmnd *sc)
return virtscsi_tmf(vscsi, cmd);
 }
 
-static struct scsi_host_template virtscsi_host_template = {
-   .module = THIS_MODULE,
-   .name = Virtio SCSI HBA,
-   .proc_name = virtio_scsi,
-   .queuecommand = virtscsi_queuecommand,
-   .this_id = -1,
-   .eh_abort_handler = virtscsi_abort,
-   .eh_device_reset_handler = virtscsi_device_reset,
-
-   .can_queue = 1024,
-   .dma_boundary = UINT_MAX,
-   .use_clustering = ENABLE_CLUSTERING,
-};
-
 #define virtscsi_config_get(vdev, fld) \
({ \
typeof(((struct virtio_scsi_config *)0)-fld) __val; \
@@ -547,6 +575,60 @@ static struct scsi_host_template virtscsi_host_template = {
  __val, sizeof(__val)); \
})
 
+static u32 virtscsi_max_sectors(struct scsi_device *sdev, u32 *value)
+{
+   return virtscsi_lun_query(sdev, value, VIRTIO_SCSI_T_LQ_MAX_SECTORS);
+}
+
+static u32 virtscsi_max_segments(struct scsi_device *sdev, u32 *value)
+{
+   return virtscsi_lun_query(sdev, value, VIRTIO_SCSI_T_LQ_MAX_SEGMENTS);
+}
+
+static u32 virtscsi_max_segment_size(struct scsi_device *sdev, u32 *value)
+{
+   return virtscsi_lun_query(sdev, value, 
VIRTIO_SCSI_T_LQ_MAX_SEGMENT_SIZE);
+}
+
+static int virtscsi_slave_alloc(struct scsi_device *sdev)
+{
+   struct Scsi_Host *shost = sdev-host;
+   struct virtio_scsi *vscsi = shost_priv(shost);
+   struct virtio_device *vdev = vscsi-vdev;
+   struct request_queue *q = sdev-request_queue;
+   unsigned int max_sectors, max_segments, max_segment_size;
+
+   if (!virtio_has_feature(vdev, VIRTIO_SCSI_F_LUN_QUERY))
+   goto out;
+
+   if (virtscsi_max_sectors(sdev, max_sectors) ||
+   virtscsi_max_segments(sdev, max_segments) ||
+   virtscsi_max_segment_size(sdev, max_segment_size)) {
+   goto out;
+   }
+
+   blk_queue_max_hw_sectors(q, max_sectors);
+   blk_queue_max_segments(q, max_segments - 2);
+   blk_queue_max_segment_size(q, max_segment_size);

Re: [Qemu-devel] [PATCH] usb-redir: Never return USB_RET_NAK for async handled packets

2012-08-21 Thread Gerd Hoffmann
On 08/17/12 17:27, Hans de Goede wrote:
 USB_RET_NAK is not a valid response for async handled packets (and will
 trigger an assert as such).
 
 Also drop the warning when receiving a status of cancelled for packets not
 cancelled by qemu itself, this can happen when a device gets unredirected
 by the usbredir-host while transfers are pending.

Patch added to usb patch queue (2+3 from v1 too).

thanks,
  Gerd



Re: [Qemu-devel] [PATCH] usb: Halt ep queue en cancel pending packets on a packet error

2012-08-21 Thread Gerd Hoffmann
On 08/17/12 15:24, Hans de Goede wrote:
 For controllers which queue up more then 1 packet at a time, we must halt the
 ep queue, and inside the controller code cancel all pending packets on an
 error.

Patch added to usb patch queue.

thanks,
  Gerd



[Qemu-devel] [PATCH] Properly use backing file argument to git-img convert

2012-08-21 Thread brad
From: Brad Campbell b...@fnarfbargle.com

 Converting to an image with an output backing file would write out the contents
 of the source image whether or not it was already contained in the new backing
 file. This commit ensures that the source file is checked against the new
 backing file and output is only allocated if it obsoletes or extends data
 already in the supplied backing file.


Signed-off-by: Brad Campbell b...@fnarfbargle.com
---
 qemu-img.c |   74 ++-
 1 files changed, 57 insertions(+), 17 deletions(-)

diff --git a/qemu-img.c b/qemu-img.c
index c8a70ff..3fb6cbf 100644
--- a/qemu-img.c
+++ b/qemu-img.c
@@ -629,11 +629,12 @@ static int img_convert(int argc, char **argv)
 int progress = 0, flags;
 const char *fmt, *out_fmt, *cache, *out_baseimg, *out_filename;
 BlockDriver *drv, *proto_drv;
-BlockDriverState **bs = NULL, *out_bs = NULL;
+BlockDriverState **bs = NULL, *out_bs = NULL, *out_bf = NULL;
 int64_t total_sectors, nb_sectors, sector_num, bs_offset;
-uint64_t bs_sectors;
+uint64_t bf_sectors, bs_sectors;
 uint8_t * buf = NULL;
 const uint8_t *buf1;
+uint8_t * bf_buf = NULL;
 BlockDriverInfo bdi;
 QEMUOptionParameter *param = NULL, *create_options = NULL;
 QEMUOptionParameter *out_baseimg_param;
@@ -797,6 +798,16 @@ static int img_convert(int argc, char **argv)
 out_baseimg_param = get_option_parameter(param, BLOCK_OPT_BACKING_FILE);
 if (out_baseimg_param) {
 out_baseimg = out_baseimg_param-value.s;
+
+/* out_baseimg_parm != NULL even if there is no base img specified! */
+if (out_baseimg) {
+out_bf = bdrv_new_open(out_baseimg, NULL, BDRV_O_FLAGS);
+if (!out_bf) {
+ret = -1;
+goto out;
+}
+bdrv_get_geometry(out_bf, bf_sectors);
+}
 }
 
 /* Check if compression is supported */
@@ -862,6 +873,9 @@ static int img_convert(int argc, char **argv)
 bs_offset = 0;
 bdrv_get_geometry(bs[0], bs_sectors);
 buf = qemu_blockalign(out_bs, IO_BUF_SIZE);
+if (out_baseimg) {
+bf_buf = qemu_blockalign(out_bs, IO_BUF_SIZE);
+}
 
 if (compress) {
 ret = bdrv_get_info(out_bs, bdi);
@@ -979,31 +993,52 @@ static int img_convert(int argc, char **argv)
 n = bs_offset + bs_sectors - sector_num;
 }
 
+ret = bdrv_read(bs[bs_i], sector_num - bs_offset, buf, n);
+if (ret  0) {
+error_report(error while reading sector % PRId64 : %s,
+ sector_num - bs_offset, strerror(-ret));
+goto out;
+}
+
 if (has_zero_init) {
 /* If the output image is being created as a copy on write 
image,
-   assume that sectors which are unallocated in the input image
-   are present in both the output's and input's base images (no
-   need to copy them). */
+   check that sectors which are unallocated in the input image
+   are present in both the output's and input's base images 
(or 
+   copy them). */
 if (out_baseimg) {
-if (!bdrv_is_allocated(bs[bs_i], sector_num - bs_offset,
-   n, n1)) {
-sector_num += n1;
-continue;
+if (sector_num  bf_sectors) {
+/* Check if source sectors match those in the new 
backing file and
+   skip the copy if true. */
+n = MIN(n, bf_sectors - sector_num);
+ret = bdrv_read(out_bf, sector_num - bs_offset, 
bf_buf, n);
+if (ret  0) {
+error_report(error while reading backing file);
+goto out;
+}
+if (!compare_sectors(buf, bf_buf, n, n1)) {
+sector_num += n1;
+continue;
+}
+ 
+} else {
+/* Source file(s) is larger than the backing file. 
Just check for
+   allocated sectors */
+if (!is_allocated_sectors_min(buf, n, n1, 
min_sparse)) {
+/* if we got zero, how many of the next ones are 
zero? */
+is_allocated_sectors(buf, n, n1);
+sector_num += n1;
+continue;
+}
 }
-/* The next 'n1' sectors are allocated in the input image. 
Copy
-   only those as they may be followed by unallocated 
sectors. */
+/* The next 'n1' sectors are allocated in the 

Re: [Qemu-devel] [PATCH v2] configure: properly check if -lrt and -lm is needed

2012-08-21 Thread Natanael Copa
On Mon, 20 Aug 2012 19:53:22 +
Blue Swirl blauwir...@gmail.com wrote:

   - Do not remove the explicit add of -lm unless Haiku. This was due
 to
  http://www.mail-archive.com/qemu-devel@nongnu.org/msg102965.html I
  am not sure if this is valid, though.
 
  Certainly building a linux-user target works for me even without
  that explicit 'LIBS+=-lm' in Makefile.target. Blue, can you remember
  what you had in mind when you wrote that email?
 
 Build failed since math library functions (sin() etc.) were not found.

The v2 and v3 patches I sent tests for sin() in addition to isnan (which
normally is a macro). It might explain why it works now.

Adding a second -lm does not hurt, but omitting it when needed breaks
build on uclibc for sure, so it would be nice if the v3 patch could be
applied.

Thanks!

-nc



Re: [Qemu-devel] [PATCH 1/2 v1] blkdrv: Add queue limits parameters for sg block drive

2012-08-21 Thread Paolo Bonzini
Il 21/08/2012 10:23, Cong Meng ha scritto:
 +static void sg_get_queue_limits(BlockDriverState *bs, const char *filename)
 +{
 +DIR *ffs;
 +struct dirent *d;
 +char path[MAXPATHLEN];
 +
 +snprintf(path, MAXPATHLEN,
 + /sys/class/scsi_generic/sg%s/device/block/,
 + filename + strlen(/dev/sg));
 +
 +ffs = opendir(path);
 +if (!ffs) {
 +return;
 +}
 +
 +for (;;) {
 +d = readdir(ffs);
 +if (!d) {
 +return;
 +}
 +
 +if (strcmp(d-d_name, .) == 0 || strcmp(d-d_name, ..) == 0) {
 +continue;
 +}
 +
 +break;
 +}
 +
 +closedir(ffs);
 +
 +pstrcat(path, MAXPATHLEN, d-d_name);
 +pstrcat(path, MAXPATHLEN, /queue/);
 +
 +read_queue_limit(path, max_sectors_kb, bs-max_sectors);
 +read_queue_limit(path, max_segments, bs-max_segments);
 +read_queue_limit(path, max_segment_size, bs-max_segment_size);
 +}

Using /sys/dev/block or /sys/dev/char seems easier, and lets you
retrieve the parameters for block devices too.

However, I'm worried of the consequences this has for migration.  You
could have the same physical disk accessed with two different HBAs, with
different limits.  So I don't know if this can really be solved at all.

Paolo



Re: [Qemu-devel] [PATCH v1] virtio-scsi: get and set the queue limits for sg device

2012-08-21 Thread Stefan Hajnoczi
On Tue, Aug 21, 2012 at 9:26 AM, Cong Meng m...@linux.vnet.ibm.com wrote:
 Each virtio scsi HBA has global request queue limits. But the passthrough
 LUNs (scsi-generic) come from different host HBAs may have different request
 queue limits. If the guest sends commands that exceed the host limits, the
 commands will be rejected by host HAB.

 This patch addresses this issue by getting the per-LUN queue limits via the 
 the
 newly added virtio control request, then setting them properly.

 Signed-off-by: Cong Meng m...@linux.vnet.ibm.com
 ---
  drivers/scsi/virtio_scsi.c  |  113 
 +--
  include/linux/virtio_scsi.h |   18 +++
  2 files changed, 116 insertions(+), 15 deletions(-)

 diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
 index 173cb39..ec5066f 100644
 --- a/drivers/scsi/virtio_scsi.c
 +++ b/drivers/scsi/virtio_scsi.c
 @@ -35,12 +35,14 @@ struct virtio_scsi_cmd {
 struct virtio_scsi_cmd_req   cmd;
 struct virtio_scsi_ctrl_tmf_req  tmf;
 struct virtio_scsi_ctrl_an_req   an;
 +   struct virtio_scsi_ctrl_lq_req   lq;
 } req;
 union {
 struct virtio_scsi_cmd_resp  cmd;
 struct virtio_scsi_ctrl_tmf_resp tmf;
 struct virtio_scsi_ctrl_an_resp  an;
 struct virtio_scsi_event evt;
 +   struct virtio_scsi_ctrl_lq_resp  lq;
 } resp;
  } cacheline_aligned_in_smp;

 @@ -469,6 +471,46 @@ out:
 return ret;
  }

 +static u32 virtscsi_lun_query(struct scsi_device *sdev, u32 *value, u32 
 subtype)
 +{
 +   struct Scsi_Host *shost = sdev-host;
 +   struct virtio_scsi *vscsi = shost_priv(shost);
 +   DECLARE_COMPLETION_ONSTACK(comp);
 +   struct virtio_scsi_cmd *cmd;
 +   struct virtio_scsi_target_state *tgt = vscsi-tgt[sdev-id];
 +   unsigned int ret = VIRTIO_SCSI_S_FAILURE;
 +
 +   cmd = mempool_alloc(virtscsi_cmd_pool, GFP_ATOMIC);
 +   if (!cmd)
 +   goto out;
 +
 +   memset(cmd, 0, sizeof(*cmd));
 +   cmd-comp = comp;
 +   cmd-req.lq = (struct virtio_scsi_ctrl_lq_req){
 +   .type = VIRTIO_SCSI_T_LUN_QUERY,
 +   .subtype = subtype,
 +   .lun[0] = 1,
 +   .lun[1] = sdev-id,
 +   .lun[2] = (sdev-lun  8) | 0x40,
 +   .lun[3] = sdev-lun  0xff,

The LUN addressing code has been duplicated several times now.  How
about replacing it with something like

static void virtio_scsi_set_lun(u8 *lun, struct scsi_device *sdev)
{
lun[0] = 1;
lun[1] = sdev-id;
lun[2] = (sdev-lun  8) | 0x40;
lun[3] = sdev-lun  0xff;
lun[4] = lun[5] = lun[6] = lun[7] = 0;
}



[Qemu-devel] [PATCH v3 4/5] spice: add 'migrated' flag to spice info

2012-08-21 Thread Yonit Halperin
The flag is 'true' when spice migration has completed on the src side.
It is needed for a case where libvirt dies before migration completes
and it misses the event QEVENT_SPICE_MIGRATE_COMPLETED.
When libvirt is restored and queries the migration status, it also needs
to query spice and check if its migration has completed.

Signed-off-by: Yonit Halperin yhalp...@redhat.com
---
 hmp.c|2 ++
 qapi-schema.json |5 -
 ui/spice-core.c  |4 
 3 files changed, 10 insertions(+), 1 deletions(-)

diff --git a/hmp.c b/hmp.c
index a9d5675..62f4dee 100644
--- a/hmp.c
+++ b/hmp.c
@@ -413,6 +413,8 @@ void hmp_info_spice(Monitor *mon)
 monitor_printf(mon,  address: %s:% PRId64  [tls]\n,
info-host, info-tls_port);
 }
+monitor_printf(mon, migrated: %s\n,
+   info-migrated ? true : false);
 monitor_printf(mon, auth: %s\n, info-auth);
 monitor_printf(mon, compiled: %s\n, info-compiled_version);
 monitor_printf(mon,   mouse-mode: %s\n,
diff --git a/qapi-schema.json b/qapi-schema.json
index 3d2b2d1..bf3f924 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -808,6 +808,9 @@
 #
 # @enabled: true if the SPICE server is enabled, false otherwise
 #
+# @migrated: true if the last guest migration completed and spice
+#migration had completed as well. false otherwise.
+#
 # @host: #optional The hostname the SPICE server is bound to.  This depends on
 #the name resolution on the host and may be an IP address.
 #
@@ -833,7 +836,7 @@
 # Since: 0.14.0
 ##
 { 'type': 'SpiceInfo',
-  'data': {'enabled': 'bool', '*host': 'str', '*port': 'int',
+  'data': {'enabled': 'bool', 'migrated': 'bool', '*host': 'str', '*port': 
'int',
'*tls-port': 'int', '*auth': 'str', '*compiled-version': 'str',
'mouse-mode': 'SpiceQueryMouseMode', '*channels': ['SpiceChannel']} 
}
 
diff --git a/ui/spice-core.c b/ui/spice-core.c
index 73f8a95..5d82c8d 100644
--- a/ui/spice-core.c
+++ b/ui/spice-core.c
@@ -46,6 +46,7 @@ static Notifier migration_state;
 static const char *auth = spice;
 static char *auth_passwd;
 static time_t auth_expires = TIME_MAX;
+static int spice_migration_completed;
 int using_spice = 0;
 
 static QemuThread me;
@@ -310,6 +311,7 @@ static void 
migrate_connect_complete_cb(SpiceMigrateInstance *sin)
 static void migrate_end_complete_cb(SpiceMigrateInstance *sin)
 {
 monitor_protocol_event(QEVENT_SPICE_MIGRATE_COMPLETED, NULL);
+spice_migration_completed = true;
 }
 #endif
 
@@ -442,6 +444,7 @@ SpiceInfo *qmp_query_spice(Error **errp)
 }
 
 info-enabled = true;
+info-migrated = spice_migration_completed;
 
 addr = qemu_opt_get(opts, addr);
 port = qemu_opt_get_number(opts, port, 0);
@@ -495,6 +498,7 @@ static void migration_state_notifier(Notifier *notifier, 
void *data)
 #ifndef SPICE_INTERFACE_MIGRATION
 spice_server_migrate_switch(spice_server);
 monitor_protocol_event(QEVENT_SPICE_MIGRATE_COMPLETED, NULL);
+spice_migration_completed = true;
 #else
 spice_server_migrate_end(spice_server, true);
 } else if (migration_has_failed(s)) {
-- 
1.7.7.6




[Qemu-devel] [PATCH v3 2/5] spice: notify on vm state change only via spice_server_vm_start/stop

2012-08-21 Thread Yonit Halperin
QXLWorker-start/stop are deprecated since spice-server 0.11.2

Signed-off-by: Yonit Halperin yhalp...@redhat.com
---
 hw/qxl.c   |7 ---
 ui/spice-core.c|4 
 ui/spice-display.c |   32 ++--
 ui/spice-display.h |9 +++--
 4 files changed, 45 insertions(+), 7 deletions(-)

diff --git a/hw/qxl.c b/hw/qxl.c
index c2dd3b4..95bbc03 100644
--- a/hw/qxl.c
+++ b/hw/qxl.c
@@ -958,9 +958,10 @@ static void qxl_update_irq(PCIQXLDevice *d)
 static void qxl_check_state(PCIQXLDevice *d)
 {
 QXLRam *ram = d-ram;
+int spice_display_running = qemu_spice_display_is_running(d-ssd);
 
-assert(!d-ssd.running || SPICE_RING_IS_EMPTY(ram-cmd_ring));
-assert(!d-ssd.running || SPICE_RING_IS_EMPTY(ram-cursor_ring));
+assert(!spice_display_running || SPICE_RING_IS_EMPTY(ram-cmd_ring));
+assert(!spice_display_running || SPICE_RING_IS_EMPTY(ram-cursor_ring));
 }
 
 static void qxl_reset_state(PCIQXLDevice *d)
@@ -1538,7 +1539,7 @@ static void qxl_send_events(PCIQXLDevice *d, uint32_t 
events)
 uint32_t old_pending;
 uint32_t le_events = cpu_to_le32(events);
 
-assert(d-ssd.running);
+assert(qemu_spice_display_is_running(d-ssd));
 old_pending = __sync_fetch_and_or(d-ram-int_pending, le_events);
 if ((old_pending  le_events) == le_events) {
 return;
diff --git a/ui/spice-core.c b/ui/spice-core.c
index 32de1f1..fa78cc3 100644
--- a/ui/spice-core.c
+++ b/ui/spice-core.c
@@ -37,6 +37,7 @@
 #include migration.h
 #include monitor.h
 #include hw/hw.h
+#include spice-display.h
 
 /* core bits */
 
@@ -550,9 +551,11 @@ static void vm_change_state_handler(void *opaque, int 
running,
 {
 #if SPICE_SERVER_VERSION = 0x000b02 /* 0.11.2 */
 if (running) {
+qemu_spice_display_start();
 spice_server_vm_start(spice_server);
 } else {
 spice_server_vm_stop(spice_server);
+qemu_spice_display_stop();
 }
 #endif
 }
@@ -754,6 +757,7 @@ int qemu_spice_add_interface(SpiceBaseInstance *sin)
 spice_server = spice_server_new();
 spice_server_init(spice_server, core_interface);
 }
+
 return spice_server_add_interface(spice_server, sin);
 }
 
diff --git a/ui/spice-display.c b/ui/spice-display.c
index 3e8f0b3..1c31418 100644
--- a/ui/spice-display.c
+++ b/ui/spice-display.c
@@ -126,18 +126,44 @@ void qemu_spice_wakeup(SimpleSpiceDisplay *ssd)
 ssd-worker-wakeup(ssd-worker);
 }
 
-void qemu_spice_start(SimpleSpiceDisplay *ssd)
+#if SPICE_SERVER_VERSION  0x000b02 /* before 0.11.2 */
+static void qemu_spice_start(SimpleSpiceDisplay *ssd)
 {
 trace_qemu_spice_start(ssd-qxl.id);
 ssd-worker-start(ssd-worker);
 }
 
-void qemu_spice_stop(SimpleSpiceDisplay *ssd)
+static void qemu_spice_stop(SimpleSpiceDisplay *ssd)
 {
 trace_qemu_spice_stop(ssd-qxl.id);
 ssd-worker-stop(ssd-worker);
 }
 
+#else
+
+static int spice_display_is_running;
+
+void qemu_spice_display_start(void)
+{
+spice_display_is_running = true;
+}
+
+void qemu_spice_display_stop(void)
+{
+spice_display_is_running = false;
+}
+
+#endif
+
+int qemu_spice_display_is_running(SimpleSpiceDisplay *ssd)
+{
+#if SPICE_SERVER_VERSION  0x000b02 /* before 0.11.2 */
+return ssd-running;
+#else
+return spice_display_is_running;
+#endif
+}
+
 static SimpleSpiceUpdate *qemu_spice_create_update(SimpleSpiceDisplay *ssd)
 {
 SimpleSpiceUpdate *update;
@@ -272,6 +298,7 @@ void qemu_spice_destroy_host_primary(SimpleSpiceDisplay 
*ssd)
 void qemu_spice_vm_change_state_handler(void *opaque, int running,
 RunState state)
 {
+#if SPICE_SERVER_VERSION  0x000b02 /* before 0.11.2 */
 SimpleSpiceDisplay *ssd = opaque;
 
 if (running) {
@@ -281,6 +308,7 @@ void qemu_spice_vm_change_state_handler(void *opaque, int 
running,
 qemu_spice_stop(ssd);
 ssd-running = false;
 }
+#endif
 }
 
 void qemu_spice_display_init_common(SimpleSpiceDisplay *ssd, DisplayState *ds)
diff --git a/ui/spice-display.h b/ui/spice-display.h
index 12e50b6..672d65e 100644
--- a/ui/spice-display.h
+++ b/ui/spice-display.h
@@ -82,7 +82,9 @@ struct SimpleSpiceDisplay {
 
 QXLRect dirty;
 int notify;
+#if SPICE_SERVER_VERSION  0x000b02 /* before 0.11.2 */
 int running;
+#endif
 
 /*
  * All struct members below this comment can be accessed from
@@ -129,5 +131,8 @@ void qemu_spice_create_primary_surface(SimpleSpiceDisplay 
*ssd, uint32_t id,
 void qemu_spice_destroy_primary_surface(SimpleSpiceDisplay *ssd,
 uint32_t id, qxl_async_io async);
 void qemu_spice_wakeup(SimpleSpiceDisplay *ssd);
-void qemu_spice_start(SimpleSpiceDisplay *ssd);
-void qemu_spice_stop(SimpleSpiceDisplay *ssd);
+#if SPICE_SERVER_VERSION = 0x000b02 /* before 0.11.2 */
+void qemu_spice_display_start(void);
+void qemu_spice_display_stop(void);
+#endif
+int qemu_spice_display_is_running(SimpleSpiceDisplay *ssd);
-- 
1.7.7.6




[Qemu-devel] [PATCH v3 1/5] spice: notify spice server on vm start/stop

2012-08-21 Thread Yonit Halperin
Spice server needs to know about the vm state in order to prevent
attempts to write to devices when they are stopped, mainly during
the non-live stage of migration.
Instead, spice will take care of restoring this writes, on the migration
target side, after migration completes.

Signed-off-by: Yonit Halperin yhalp...@redhat.com
---
 ui/spice-core.c |   14 ++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/ui/spice-core.c b/ui/spice-core.c
index 4fc48f8..32de1f1 100644
--- a/ui/spice-core.c
+++ b/ui/spice-core.c
@@ -545,6 +545,18 @@ static int add_channel(const char *name, const char 
*value, void *opaque)
 return 0;
 }
 
+static void vm_change_state_handler(void *opaque, int running,
+RunState state)
+{
+#if SPICE_SERVER_VERSION = 0x000b02 /* 0.11.2 */
+if (running) {
+spice_server_vm_start(spice_server);
+} else {
+spice_server_vm_stop(spice_server);
+}
+#endif
+}
+
 void qemu_spice_init(void)
 {
 QemuOpts *opts = QTAILQ_FIRST(qemu_spice_opts.head);
@@ -718,6 +730,8 @@ void qemu_spice_init(void)
 qemu_spice_input_init();
 qemu_spice_audio_init();
 
+qemu_add_vm_change_state_handler(vm_change_state_handler, spice_server);
+
 g_free(x509_key_file);
 g_free(x509_cert_file);
 g_free(x509_cacert_file);
-- 
1.7.7.6




Re: [Qemu-devel] memory: could we add extra input param for memory_region_init_io()?

2012-08-21 Thread Avi Kivity
On 08/21/2012 07:48 AM, liu ping fan wrote:
 On Sun, Aug 19, 2012 at 7:36 PM, Avi Kivity a...@redhat.com wrote:
 On 08/19/2012 02:23 PM, Peter Maydell wrote:
 On 19 August 2012 11:12, Avi Kivity a...@redhat.com wrote:
 On 08/17/2012 10:41 AM, liu ping fan wrote:
 And something like omap_mpu_timer_init() in file hw/omap1.c , the
 opaque(omap_mpu_timer_s) is got from g_malloc0, which makes things
 even harder to handle.  And the DO_CAST can not work for such issue.

 IMO omap_mpu_timer_s should be a DeviceState.  Peter?

 Ideally, yes, but qemu is full of devices that haven't yet made the leap
 to QOM.

 omap1 is particularly tricky because I don't actually have any test images
 for it, so refactoring it is a leap in the dark. [I've tried asking on this 
 list
 if anybody had test images a couple of times without success.]

 Okay.  Most of the options in this thread don't involve wholesale
 conversion of the opaque parameter in memory_region_init_io() to type
 Object *, so it's not necessary to convert everything.

 But I think if the mr belongs to mem address space, it can not avoid
 object_ref(Object *opaque) in mmio-dispatch code. ( If we use extra
 flag to indicate whether the opaque is Object or not, then we lose the
 meaning to transfer opaque to Object type, and maybe
 memory_region_set_object() is a better choice).  

I'm not sure I understand.  What do you mean by ability to transfer
opaque to Object type?

However, I think I agree that we have to object_ref() during mmio
dispatch.  At that point, there are no locks taken, so nothing gurantees
the opaque is valid.

We can't take the big qemu lock since we're holding the mem map lock,
which nests inside it.  One thing we can do is retry the walk with the
qemu lock held, but that's hardly nice.  Or we can use a trylock.

If we add memory_region_set_object() that is no help either, since we
have to convert every call site.  If we do that, I prefer that we change
opaque to an Object.


 And the only exempt
 is that mr belong to io address space.

Eventually, I'd like the io address space to be dispatched by the same
code, but for now we can ignore it.

 
 After carefully reading the code, I think
 1. we assume Object opaque have 1:1 relationship, if not, the Object
 can be  refactored,
which means children of Object (composite kid device or bus) will
 be introduced. This
may cause the modeling problem(but currently, can not find the example)

Agree.  The best example is device assignment, where BARs will need to
turn into Objects.  It means that an assigned device can disappear while
one of its BARs remain, so the code will have to handle this case.

 
 2. Some MemoryRegionOps are shared by different type of Device.
 For example, cirrus_vga_mem_ops will handle CirrusVGAState, and
 the related Object
 can be ISACirrusVGAState or PCICirrusVGAState. So we need to remodel the
 CirrusVGAState as composite device of its parent,  and introducing
 qdev_create_in_place() just like qbus_create_in_place().
 

Alternatively, VGACommonState can be made into an Object, as in option 3.

 3. For the case, where opaque has no Object to relate with, simply
 embeded Object at
 the head of them. (And there are lots of such issue in current code)
 
 4. For pio, currently, we can ignore them.

Yes.

Unfortunately, requiring a 1:1 opaque:Object relationship means huge
churn in the code.  But I don't think it can be avoided, even with
memory_region_set_object().

-- 
error compiling committee.c: too many arguments to function



[Qemu-devel] [PATCH v3 3/5] spice migration: add QEVENT_SPICE_MIGRATE_COMPLETED

2012-08-21 Thread Yonit Halperin
When migrating, libvirt queries the migration status, and upon migration
completions, it closes the migration src. On the other hand, when
migration is completed, spice transfers data from the src to destination
via the client. This data is required for keeping the spice session
after migration, without suffering from data loss and inconsistencies.
In order to allow this data transfer, we add QEVENT for signaling
libvirt that spice migration has completed, and libvirt needs to wait
for this event before quitting the src process.

Signed-off-by: Yonit Halperin yhalp...@redhat.com
---
 monitor.c   |1 +
 monitor.h   |1 +
 ui/spice-core.c |9 -
 3 files changed, 10 insertions(+), 1 deletions(-)

diff --git a/monitor.c b/monitor.c
index ce42466..584efe0 100644
--- a/monitor.c
+++ b/monitor.c
@@ -455,6 +455,7 @@ static const char *monitor_event_names[] = {
 [QEVENT_SUSPEND_DISK] = SUSPEND_DISK,
 [QEVENT_WAKEUP] = WAKEUP,
 [QEVENT_BALLOON_CHANGE] = BALLOON_CHANGE,
+[QEVENT_SPICE_MIGRATE_COMPLETED] = SPICE_MIGRATE_COMPLETED,
 };
 QEMU_BUILD_BUG_ON(ARRAY_SIZE(monitor_event_names) != QEVENT_MAX)
 
diff --git a/monitor.h b/monitor.h
index 47d556b..5fc2983 100644
--- a/monitor.h
+++ b/monitor.h
@@ -43,6 +43,7 @@ typedef enum MonitorEvent {
 QEVENT_SUSPEND_DISK,
 QEVENT_WAKEUP,
 QEVENT_BALLOON_CHANGE,
+QEVENT_SPICE_MIGRATE_COMPLETED,
 
 /* Add to 'monitor_event_names' array in monitor.c when
  * defining new events here */
diff --git a/ui/spice-core.c b/ui/spice-core.c
index fa78cc3..73f8a95 100644
--- a/ui/spice-core.c
+++ b/ui/spice-core.c
@@ -285,6 +285,7 @@ typedef struct SpiceMigration {
 } SpiceMigration;
 
 static void migrate_connect_complete_cb(SpiceMigrateInstance *sin);
+static void migrate_end_complete_cb(SpiceMigrateInstance *sin);
 
 static const SpiceMigrateInterface migrate_interface = {
 .base.type = SPICE_INTERFACE_MIGRATION,
@@ -292,7 +293,7 @@ static const SpiceMigrateInterface migrate_interface = {
 .base.major_version = SPICE_INTERFACE_MIGRATION_MAJOR,
 .base.minor_version = SPICE_INTERFACE_MIGRATION_MINOR,
 .migrate_connect_complete = migrate_connect_complete_cb,
-.migrate_end_complete = NULL,
+.migrate_end_complete = migrate_end_complete_cb,
 };
 
 static SpiceMigration spice_migrate;
@@ -305,6 +306,11 @@ static void 
migrate_connect_complete_cb(SpiceMigrateInstance *sin)
 }
 sm-connect_complete.cb = NULL;
 }
+
+static void migrate_end_complete_cb(SpiceMigrateInstance *sin)
+{
+monitor_protocol_event(QEVENT_SPICE_MIGRATE_COMPLETED, NULL);
+}
 #endif
 
 /* config string parsing */
@@ -488,6 +494,7 @@ static void migration_state_notifier(Notifier *notifier, 
void *data)
 } else if (migration_has_finished(s)) {
 #ifndef SPICE_INTERFACE_MIGRATION
 spice_server_migrate_switch(spice_server);
+monitor_protocol_event(QEVENT_SPICE_MIGRATE_COMPLETED, NULL);
 #else
 spice_server_migrate_end(spice_server, true);
 } else if (migration_has_failed(s)) {
-- 
1.7.7.6




[Qemu-devel] [PATCH v3 0/5] add support for spice migration v3

2012-08-21 Thread Yonit Halperin
v3:
patch 2: hold a global variable for the state of spice display, instead of one 
per
 device.

v2:
Notify spice about vm state changes only via spice_server_vm_start/stop
spice repo:  
http://cgit.freedesktop.org/~yhalperi/spice/log/?h=seamless-migration.v2
---
Hi,

The following series introduces support for keeping the spice session active 
after migration.
For more details about spice seamless migration, see
http://lists.freedesktop.org/archives/spice-devel/2012-August/010412.html

Spice branches with seamless migration support can be found at:
spice-protocol: 
http://cgit.freedesktop.org/~yhalperi/spice-protocol/log/?h=seamless-migration.v1
spice-common: http://cgit.freedesktop.org/~yhalperi/spice-common/log/
spice: http://cgit.freedesktop.org/~yhalperi/spice/log/?h=seamless-migration.v1
spicei-gtk: http://cgit.freedesktop.org/~yhalperi/spice-gtk/log/

Regards,
Yonit.

Yonit Halperin (5):
  spice: notify spice server on vm start/stop
  spice: notify on vm state change only via spice_server_vm_start/stop
  spice migration: add QEVENT_SPICE_MIGRATE_COMPLETED
  spice: add 'migrated' flag to spice info
  spice: adding seamless-migration option to the command line

 hmp.c  |2 ++
 hw/qxl.c   |7 ---
 monitor.c  |1 +
 monitor.h  |1 +
 qapi-schema.json   |5 -
 qemu-config.c  |3 +++
 qemu-options.hx|3 +++
 ui/spice-core.c|   38 +-
 ui/spice-display.c |   32 ++--
 ui/spice-display.h |9 +++--
 10 files changed, 92 insertions(+), 9 deletions(-)

-- 
1.7.7.6




[Qemu-devel] [PATCH v3 5/5] spice: adding seamless-migration option to the command line

2012-08-21 Thread Yonit Halperin
The seamless-migration flag is required in order to identify
whether libvirt supports the new QEVENT_SPICE_MIGRATE_COMPLETED or not
(by default the flag is off).
New libvirt versions that wait for QEVENT_SPICE_MIGRATE_COMPLETED should turn 
on this flag.
When this flag is off, spice fallbacks to its old migration method, which
can result in data loss.

Signed-off-by: Yonit Halperin yhalp...@redhat.com
---
 qemu-config.c   |3 +++
 qemu-options.hx |3 +++
 ui/spice-core.c |7 +++
 3 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/qemu-config.c b/qemu-config.c
index 5c3296b..b7bb28f 100644
--- a/qemu-config.c
+++ b/qemu-config.c
@@ -524,6 +524,9 @@ QemuOptsList qemu_spice_opts = {
 },{
 .name = playback-compression,
 .type = QEMU_OPT_BOOL,
+}, {
+.name = seamless-migration,
+.type = QEMU_OPT_BOOL,
 },
 { /* end of list */ }
 },
diff --git a/qemu-options.hx b/qemu-options.hx
index 47cb5bd..0727f4f 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -917,6 +917,9 @@ Enable/disable passing mouse events via vdagent.  Default 
is on.
 @item playback-compression=[on|off]
 Enable/disable audio stream compression (using celt 0.5.1).  Default is on.
 
+@item seamless-migration=[on|off]
+Enable/disable spice seamless migration. Default is off.
+
 @end table
 ETEXI
 
diff --git a/ui/spice-core.c b/ui/spice-core.c
index 5d82c8d..d447334 100644
--- a/ui/spice-core.c
+++ b/ui/spice-core.c
@@ -584,6 +584,9 @@ void qemu_spice_init(void)
 int port, tls_port, len, addr_flags;
 spice_image_compression_t compression;
 spice_wan_compression_t wan_compr;
+#if SPICE_SERVER_VERSION = 0x000b02 /* 0.11.2 */
+bool seamless_migration;
+#endif
 
 qemu_thread_get_self(me);
 
@@ -727,6 +730,10 @@ void qemu_spice_init(void)
 spice_server_set_uuid(spice_server, qemu_uuid);
 #endif
 
+#if SPICE_SERVER_VERSION = 0x000b02 /* 0.11.2 */
+seamless_migration = qemu_opt_get_bool(opts, seamless-migration, 0);
+spice_server_set_seamless_migration(spice_server, seamless_migration);
+#endif
 if (0 != spice_server_init(spice_server, core_interface)) {
 error_report(failed to initialize spice server);
 exit(1);
-- 
1.7.7.6




Re: [Qemu-devel] [RFC/PATCH] qemu: Use valgrind annotations to mark kvm guest memory as defined

2012-08-21 Thread Christian Borntraeger
On 10/08/12 15:11, Christian Borntraeger wrote:
 valgrind with kvm produces a big amount of false positives regarding
 Conditional jump or move depends on uninitialised value(s). This
 happens because the guest memory is allocated with qemu_vmalloc which
 boils down posix_memalign etc. This function is (correctly) considered
 by valgrind as returning undefined memory.
 
 Since valgrind is based on jitting code, it will not be able to see
 changes made by the guest to guest memory if this is done by KVM_RUN,
 thus keeping most of the guest memory undefined.
 
 Now lots of places in qemu will then use guest memory to change behaviour.
 To avoid the flood of these messages, lets declare the whole guest
 memory as defined. This will reduce the noise and allows us to see real
 problems.
 
 In the future we might want to make this conditional, since there
 is actually something that we can use those false positives for:
 These messages will point to code that depends on guest memory, so
 we can use these backtraces to actually make an audit that is focussed
 only at those code places. For normal development we dont want to
 see those messages, though.


Any opinion about this patch?


 
 Signed-off-by: Christian Borntraeger borntrae...@de.ibm.com
 ---
  configure |3 ++-
  kvm-all.c |7 +++
  2 files changed, 9 insertions(+), 1 deletions(-)
 
 diff --git a/configure b/configure
 index 280726c..90df0d8 100755
 --- a/configure
 +++ b/configure
 @@ -2900,11 +2900,12 @@ if compile_prog -Werror  ; then
  fi
 
  
 -# check if we have valgrind/valgrind.h
 +# check if we have valgrind/valgrind.h and valgrind/memcheck.h
 
  valgrind_h=no
  cat  $TMPC  EOF
  #include valgrind/valgrind.h
 +#include valgrind/memcheck.h
  int main(void) {
return 0;
  }
 diff --git a/kvm-all.c b/kvm-all.c
 index 2148b20..33d16cf 100644
 --- a/kvm-all.c
 +++ b/kvm-all.c
 @@ -39,6 +39,10 @@
  #include sys/eventfd.h
  #endif
 
 +#ifdef CONFIG_VALGRIND_H
 +#include valgrind/memcheck.h
 +#endif
 +
  /* KVM uses PAGE_SIZE in its definition of COALESCED_MMIO_MAX */
  #define PAGE_SIZE TARGET_PAGE_SIZE
 
 @@ -1687,6 +1691,9 @@ void *kvm_vmalloc(ram_addr_t size)
 
  void kvm_setup_guest_memory(void *start, size_t size)
  {
 +#ifdef CONFIG_VALGRIND_H
 +VALGRIND_MAKE_MEM_DEFINED(start, size);
 +#endif
  if (!kvm_has_sync_mmu()) {
  int ret = qemu_madvise(start, size, QEMU_MADV_DONTFORK);
 




Re: [Qemu-devel] [PATCH v3 0/5] add support for spice migration v3

2012-08-21 Thread Michal Privoznik
On 21.08.2012 10:51, Yonit Halperin wrote:
 v3:
 patch 2: hold a global variable for the state of spice display, instead of 
 one per
  device.
 
 v2:
 Notify spice about vm state changes only via spice_server_vm_start/stop
 spice repo:  
 http://cgit.freedesktop.org/~yhalperi/spice/log/?h=seamless-migration.v2
 ---
 Hi,
 
 The following series introduces support for keeping the spice session active 
 after migration.
 For more details about spice seamless migration, see
 http://lists.freedesktop.org/archives/spice-devel/2012-August/010412.html
 
 Spice branches with seamless migration support can be found at:
 spice-protocol: 
 http://cgit.freedesktop.org/~yhalperi/spice-protocol/log/?h=seamless-migration.v1
 spice-common: http://cgit.freedesktop.org/~yhalperi/spice-common/log/
 spice: 
 http://cgit.freedesktop.org/~yhalperi/spice/log/?h=seamless-migration.v1
 spicei-gtk: http://cgit.freedesktop.org/~yhalperi/spice-gtk/log/
 
 Regards,
 Yonit.
 
 Yonit Halperin (5):
   spice: notify spice server on vm start/stop
   spice: notify on vm state change only via spice_server_vm_start/stop
   spice migration: add QEVENT_SPICE_MIGRATE_COMPLETED
   spice: add 'migrated' flag to spice info
   spice: adding seamless-migration option to the command line
 
  hmp.c  |2 ++
  hw/qxl.c   |7 ---
  monitor.c  |1 +
  monitor.h  |1 +
  qapi-schema.json   |5 -
  qemu-config.c  |3 +++
  qemu-options.hx|3 +++
  ui/spice-core.c|   38 +-
  ui/spice-display.c |   32 ++--
  ui/spice-display.h |9 +++--
  10 files changed, 92 insertions(+), 9 deletions(-)
 

Okay, from libvirt POV this is easily doable.
One one hand, libvirt doesn't query for 'query-spice' yet. But on the
other hand, we can start to if libvirt would know qemu supports it.
And it will indeed - assuming qemu will report 'seamless-migration'
option in -help output.

Michal



Re: [Qemu-devel] memory: could we add extra input param for memory_region_init_io()?

2012-08-21 Thread liu ping fan
On Tue, Aug 21, 2012 at 4:57 PM, Avi Kivity a...@redhat.com wrote:
 On 08/21/2012 07:48 AM, liu ping fan wrote:
 On Sun, Aug 19, 2012 at 7:36 PM, Avi Kivity a...@redhat.com wrote:
 On 08/19/2012 02:23 PM, Peter Maydell wrote:
 On 19 August 2012 11:12, Avi Kivity a...@redhat.com wrote:
 On 08/17/2012 10:41 AM, liu ping fan wrote:
 And something like omap_mpu_timer_init() in file hw/omap1.c , the
 opaque(omap_mpu_timer_s) is got from g_malloc0, which makes things
 even harder to handle.  And the DO_CAST can not work for such issue.

 IMO omap_mpu_timer_s should be a DeviceState.  Peter?

 Ideally, yes, but qemu is full of devices that haven't yet made the leap
 to QOM.

 omap1 is particularly tricky because I don't actually have any test images
 for it, so refactoring it is a leap in the dark. [I've tried asking on 
 this list
 if anybody had test images a couple of times without success.]

 Okay.  Most of the options in this thread don't involve wholesale
 conversion of the opaque parameter in memory_region_init_io() to type
 Object *, so it's not necessary to convert everything.

 But I think if the mr belongs to mem address space, it can not avoid
 object_ref(Object *opaque) in mmio-dispatch code. ( If we use extra
 flag to indicate whether the opaque is Object or not, then we lose the
 meaning to transfer opaque to Object type, and maybe
 memory_region_set_object() is a better choice).

 I'm not sure I understand.  What do you mean by ability to transfer
 opaque to Object type?

Maybe I misunderstand your meaning of Okay.  Most of the options in
this thread don't involve wholesale ..., so it's not necessary to
convert everything
I think you mean that omap_mpu_timer_s need NOT to convert.  But as
it will also take the code path which has object_ref(Object*), so it
has to convert, otherwise the code will corrupt.
That is what I want to express.

 However, I think I agree that we have to object_ref() during mmio
 dispatch.  At that point, there are no locks taken, so nothing gurantees
 the opaque is valid.

 We can't take the big qemu lock since we're holding the mem map lock,
 which nests inside it.  One thing we can do is retry the walk with the
 qemu lock held, but that's hardly nice.  Or we can use a trylock.

 If we add memory_region_set_object() that is no help either, since we
 have to convert every call site.  If we do that, I prefer that we change
 opaque to an Object.


 And the only exempt
 is that mr belong to io address space.

 Eventually, I'd like the io address space to be dispatched by the same
 code, but for now we can ignore it.

OK

 After carefully reading the code, I think
 1. we assume Object opaque have 1:1 relationship, if not, the Object
 can be  refactored,
which means children of Object (composite kid device or bus) will
 be introduced. This
may cause the modeling problem(but currently, can not find the example)

 Agree.  The best example is device assignment, where BARs will need to
 turn into Objects.  It means that an assigned device can disappear while
 one of its BARs remain, so the code will have to handle this case.

How about the initialization of BAR inc ref of assigned device; and
finalization of BAR dec it?

 2. Some MemoryRegionOps are shared by different type of Device.
 For example, cirrus_vga_mem_ops will handle CirrusVGAState, and
 the related Object
 can be ISACirrusVGAState or PCICirrusVGAState. So we need to remodel the
 CirrusVGAState as composite device of its parent,  and introducing
 qdev_create_in_place() just like qbus_create_in_place().


 Alternatively, VGACommonState can be made into an Object, as in option 3.

NO, as for case 2, I think the composite device will hold ref of its
parent. Otherwise, we can not prevent  the PCICirrusVGAState from
disappearing when mmio-dispatch.  But as for case 3, it just work
around in current step. And usually, the Object is isolated. Maybe in
future, we can fix them.

 3. For the case, where opaque has no Object to relate with, simply
 embeded Object at
 the head of them. (And there are lots of such issue in current code)

 4. For pio, currently, we can ignore them.

 Yes.

 Unfortunately, requiring a 1:1 opaque:Object relationship means huge
 churn in the code.  But I don't think it can be avoided, even with
 memory_region_set_object().

Yeah, and I am studying the different case to see how to resolve and
make plans about the huge conversion.

Regards,
pingfan
 --
 error compiling committee.c: too many arguments to function



Re: [Qemu-devel] x86, nops settings result in kernel crash

2012-08-21 Thread Tomas Racek
 On 20.08.2012 21:13, Tomas Racek wrote:
 []
 Can we trim the old, large and now not-so-relevant discussion please?
 ;)
 
  I can provide you with more different traces if it can help. But I
  thought that maybe it will be more useful for you to try it on
  your own. So I've prepared some minimal debian installation which
  you could download here (apx 163M bzipped):
  
  http://fi.muni.cz/~xracek/debian.img.bz2
  
  Password:
  root/asdfgh
  
  Here is my config for guest kernel:
  
  http://fi.muni.cz/~xracek/config
  
  I use
  
  qemu-kvm -m 1500 -hda debian.img -kernel
  linux/arch/x86/boot/bzImage -append root=/dev/sda1
 
 Um.  I'd expect the image to be self-contained, no external kernel.
 I wanted to do a quick test to see if it fails on my machine too,
 d/loaded debian.img.bz2 but there's no kernel.  So.. no quick test
 for you ;)

Well, the point was to use the latest sources instead of some image which can 
be obsolete tomorrow. However I created a new image with today's kernel which 
you can use:

http://fi.muni.cz/~xracek/debian2.img.bz2

Other things are the same.

The runtest.sh sets environment for xfstests and runs test 285 which I wrote 
and and which should test if FS sends discard requests only on free sectors:
285:
1. Create loop device and FS on it.
2. Populate it with some garbage.
3. Get free sectors from FS.
4. Run fstrim and look for discard requests via blk tracer.
5. Compare free sectors to discard requests.

The test itself can have some issues but I'm pretty sure it shouldn't crash the 
system. ;-)

Regards,
Tom

 
  After logging in just run sh runtest.sh. This leads to crash in
  my case (host: Intel Core i5-2540M, kernel 3.5.2-1.fc17.x86_64,
  qemu 1.0.1).
 
 With all the above, this runtest.sh is informationally equal to
 your disk image.
 
 /mjt
 



[Qemu-devel] [PATCH v6 13/13] target-mips-ase-dsp: Change TODO

2012-08-21 Thread Jia Liu
Delete DSP r1  DSP r2 from TODO.

Signed-off-by: Jia Liu pro...@gmail.com
---
 target-mips/TODO |2 --
 1 file changed, 2 deletions(-)

diff --git a/target-mips/TODO b/target-mips/TODO
index 2a3546f..15d67cd 100644
--- a/target-mips/TODO
+++ b/target-mips/TODO
@@ -6,8 +6,6 @@ General
 - Unimplemented ASEs:
   - MDMX
   - SmartMIPS
-  - DSP r1
-  - DSP r2
 - MT ASE only partially implemented and not functional
 - Shadow register support only partially implemented,
   lacks set switching on interrupt/exception.
-- 
1.7.9.5




Re: [Qemu-devel] [PATCH 1/2 v1] blkdrv: Add queue limits parameters for sg block drive

2012-08-21 Thread Cong Meng



On Tue 21 Aug 2012 04:48:17 PM CST, Paolo Bonzini wrote:

Il 21/08/2012 10:23, Cong Meng ha scritto:

+static void sg_get_queue_limits(BlockDriverState *bs, const char *filename)
+{
+DIR *ffs;
+struct dirent *d;
+char path[MAXPATHLEN];
+
+snprintf(path, MAXPATHLEN,
+ /sys/class/scsi_generic/sg%s/device/block/,
+ filename + strlen(/dev/sg));
+
+ffs = opendir(path);
+if (!ffs) {
+return;
+}
+
+for (;;) {
+d = readdir(ffs);
+if (!d) {
+return;
+}
+
+if (strcmp(d-d_name, .) == 0 || strcmp(d-d_name, ..) == 0) {
+continue;
+}
+
+break;
+}
+
+closedir(ffs);
+
+pstrcat(path, MAXPATHLEN, d-d_name);
+pstrcat(path, MAXPATHLEN, /queue/);
+
+read_queue_limit(path, max_sectors_kb, bs-max_sectors);
+read_queue_limit(path, max_segments, bs-max_segments);
+read_queue_limit(path, max_segment_size, bs-max_segment_size);
+}


Using /sys/dev/block or /sys/dev/char seems easier, and lets you
retrieve the parameters for block devices too.

what do you mean with block devices?   Using /dev/sda instead of 
/dev/sg0?



However, I'm worried of the consequences this has for migration.  You
could have the same physical disk accessed with two different HBAs, with
different limits.  So I don't know if this can really be solved at all.

I know little about qemu migration now.  The pending scsi commands will 
be saved and

transfered to remote machine when starting migration?

Cong.


Paolo






Re: [Qemu-devel] [PATCH v1] virtio-scsi: get and set the queue limits for sg device

2012-08-21 Thread Cong Meng



On Tue 21 Aug 2012 04:53:59 PM CST, Stefan Hajnoczi wrote:

On Tue, Aug 21, 2012 at 9:26 AM, Cong Meng m...@linux.vnet.ibm.com wrote:

Each virtio scsi HBA has global request queue limits. But the passthrough
LUNs (scsi-generic) come from different host HBAs may have different request
queue limits. If the guest sends commands that exceed the host limits, the
commands will be rejected by host HAB.

This patch addresses this issue by getting the per-LUN queue limits via the the
newly added virtio control request, then setting them properly.

Signed-off-by: Cong Meng m...@linux.vnet.ibm.com
---
  drivers/scsi/virtio_scsi.c  |  113 +--
  include/linux/virtio_scsi.h |   18 +++
  2 files changed, 116 insertions(+), 15 deletions(-)

diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
index 173cb39..ec5066f 100644
--- a/drivers/scsi/virtio_scsi.c
+++ b/drivers/scsi/virtio_scsi.c
@@ -35,12 +35,14 @@ struct virtio_scsi_cmd {
 struct virtio_scsi_cmd_req   cmd;
 struct virtio_scsi_ctrl_tmf_req  tmf;
 struct virtio_scsi_ctrl_an_req   an;
+   struct virtio_scsi_ctrl_lq_req   lq;
 } req;
 union {
 struct virtio_scsi_cmd_resp  cmd;
 struct virtio_scsi_ctrl_tmf_resp tmf;
 struct virtio_scsi_ctrl_an_resp  an;
 struct virtio_scsi_event evt;
+   struct virtio_scsi_ctrl_lq_resp  lq;
 } resp;
  } cacheline_aligned_in_smp;

@@ -469,6 +471,46 @@ out:
 return ret;
  }

+static u32 virtscsi_lun_query(struct scsi_device *sdev, u32 *value, u32 
subtype)
+{
+   struct Scsi_Host *shost = sdev-host;
+   struct virtio_scsi *vscsi = shost_priv(shost);
+   DECLARE_COMPLETION_ONSTACK(comp);
+   struct virtio_scsi_cmd *cmd;
+   struct virtio_scsi_target_state *tgt = vscsi-tgt[sdev-id];
+   unsigned int ret = VIRTIO_SCSI_S_FAILURE;
+
+   cmd = mempool_alloc(virtscsi_cmd_pool, GFP_ATOMIC);
+   if (!cmd)
+   goto out;
+
+   memset(cmd, 0, sizeof(*cmd));
+   cmd-comp = comp;
+   cmd-req.lq = (struct virtio_scsi_ctrl_lq_req){
+   .type = VIRTIO_SCSI_T_LUN_QUERY,
+   .subtype = subtype,
+   .lun[0] = 1,
+   .lun[1] = sdev-id,
+   .lun[2] = (sdev-lun  8) | 0x40,
+   .lun[3] = sdev-lun  0xff,


The LUN addressing code has been duplicated several times now.  How
about replacing it with something like


sure. I will include it.

Thnaks.
Cong.



static void virtio_scsi_set_lun(u8 *lun, struct scsi_device *sdev)
{
 lun[0] = 1;
 lun[1] = sdev-id;
 lun[2] = (sdev-lun  8) | 0x40;
 lun[3] = sdev-lun  0xff;
 lun[4] = lun[5] = lun[6] = lun[7] = 0;
}






Re: [Qemu-devel] [PATCH v9 5/5] (temp) FORTIFY_SOURCES hack

2012-08-21 Thread Alon Levy
 On Mon, Aug 20, 2012 at 1:26 PM, Alon Levy al...@redhat.com wrote:
  ---
   .gitmodules| 3 +++
   compiler.h | 7 +++
   spice-protocol | 1 +
   3 files changed, 11 insertions(+)
   create mode 16 spice-protocol

I accidentally sent this patch, you can see the (temp) in the title.

 
  diff --git a/.gitmodules b/.gitmodules
  index eca876f..ba6844b 100644
  --- a/.gitmodules
  +++ b/.gitmodules
  @@ -19,3 +19,6 @@
   [submodule roms/sgabios]
  path = roms/sgabios
  url = git://git.qemu.org/sgabios.git
  +[submodule spice-protocol]
  +   path = spice-protocol
  +   url = git://git.freedesktop.org/git/spice/spice-protocol
  diff --git a/compiler.h b/compiler.h
  index 07ba1f8..622aeda 100644
  --- a/compiler.h
  +++ b/compiler.h
  @@ -57,4 +57,11 @@
   #define GCC_FMT_ATTR(n, m)
   #endif
 
  +/* Enable compile-time and run-time bounds-checking, and some
  warnings. */
  +#ifdef __OPTIMIZE__
  +#if __OPTIMIZE__
  +# define _FORTIFY_SOURCE 2
  +#endif
  +#endif
 
 _FORTIFY_SOURCE is already defined by configure:
 if test $debug = no ; then
   CFLAGS=-O2 -D_FORTIFY_SOURCE=2 $CFLAGS
 fi
 
  +
   #endif /* COMPILER_H */
  diff --git a/spice-protocol b/spice-protocol
  new file mode 16
  index 000..26cd194
  --- /dev/null
  +++ b/spice-protocol
  @@ -0,0 +1 @@
  +Subproject commit 26cd1946a5c959a53c78fa16f1b3e84a9682121b
  --
  1.7.11.2
 
 
 
 



Re: [Qemu-devel] Windows slow boot: contractor wanted

2012-08-21 Thread Avi Kivity
On 08/20/2012 04:56 PM, Richard Davies wrote:

 We're running host kernel 3.5.1 and qemu-kvm 1.1.1.
 
 I hadn't though about it, but I agree this is related to cpu overcommit. The
 slow boots are intermittent (and infrequent) with cpu overcommit whereas I
 don't think it occurs without cpu overcommit.
 
 In addition, if there is a slow boot ongoing, and you kill some other VMs to
 reduce cpu overcommit then this will sometimes speed it up.
 
 I guess the question is why even with overcommit most boots are fine, but
 some small fraction then go slow?

Could be a bug.  The scheduler and the spin-loop handling code fight
each other instead of working well.

Please provide snapshots of 'perf top' while a slow boot is in progress.

-- 
error compiling committee.c: too many arguments to function



Re: [Qemu-devel] [PATCH 1/2 v1] blkdrv: Add queue limits parameters for sg block drive

2012-08-21 Thread Stefan Hajnoczi
On Tue, Aug 21, 2012 at 9:23 AM, Cong Meng m...@linux.vnet.ibm.com wrote:
 This patch adds some queue limit parameters into block drive. And inits them
 for sg block drive. Some interfaces are also added for accessing them.

 Signed-off-by: Cong Meng m...@linux.vnet.ibm.com
 ---
  block/raw-posix.c |   58 
 +
  block_int.h   |4 +++
  blockdev.c|   15 +
  hw/block-common.h |3 ++
  4 files changed, 80 insertions(+), 0 deletions(-)

 diff --git a/block/raw-posix.c b/block/raw-posix.c
 index 0dce089..a086f89 100644
 --- a/block/raw-posix.c
 +++ b/block/raw-posix.c
 @@ -53,6 +53,7 @@
  #include linux/cdrom.h
  #include linux/fd.h
  #include linux/fs.h
 +#include dirent.h
  #endif
  #ifdef CONFIG_FIEMAP
  #include linux/fiemap.h
 @@ -829,6 +830,62 @@ static int hdev_probe_device(const char *filename)
  return 0;
  }

 +static void read_queue_limit(char *path, const char *filename, unsigned int 
 *val)
 +{
 +FILE *f;
 +char *tail = path + strlen(path);
 +
 +pstrcat(path, MAXPATHLEN, filename);
 +f = fopen(path, r);
 +if (!f) {
 +goto out;
 +}
 +
 +fscanf(f, %u, val);
 +fclose(f);
 +
 +out:
 +*tail = 0;
 +}
 +
 +static void sg_get_queue_limits(BlockDriverState *bs, const char *filename)
 +{
 +DIR *ffs;
 +struct dirent *d;
 +char path[MAXPATHLEN];
 +
 +snprintf(path, MAXPATHLEN,
 + /sys/class/scsi_generic/sg%s/device/block/,
 + filename + strlen(/dev/sg));
 +
 +ffs = opendir(path);
 +if (!ffs) {
 +return;
 +}
 +
 +for (;;) {
 +d = readdir(ffs);
 +if (!d) {
 +return;

Leaks ffs

 +}
 +
 +if (strcmp(d-d_name, .) == 0 || strcmp(d-d_name, ..) == 0) {
 +continue;
 +}
 +
 +break;
 +}

Not sure where in the kernel the block/ sysfs directory is created for
the device.  I wasn't able to check that there is only ever 1
directory entry for a SCSI device's block/.  Any ideas whether it's
safe to grab the first directory entry?

 +
 +closedir(ffs);
 +
 +pstrcat(path, MAXPATHLEN, d-d_name);
 +pstrcat(path, MAXPATHLEN, /queue/);
 +
 +read_queue_limit(path, max_sectors_kb, bs-max_sectors);
 +read_queue_limit(path, max_segments, bs-max_segments);
 +read_queue_limit(path, max_segment_size, bs-max_segment_size);
 +}
 +
  static int hdev_open(BlockDriverState *bs, const char *filename, int flags)
  {
  BDRVRawState *s = bs-opaque;
 @@ -868,6 +925,7 @@ static int hdev_open(BlockDriverState *bs, const char 
 *filename, int flags)
  temp = realpath(filename, resolved_path);
  if (temp  strstart(temp, /dev/sg, NULL)) {
  bs-sg = 1;
 +sg_get_queue_limits(bs, temp);
  }
  }
  #endif
 diff --git a/block_int.h b/block_int.h
 index d72317f..a9d07a2 100644
 --- a/block_int.h
 +++ b/block_int.h
 @@ -333,6 +333,10 @@ struct BlockDriverState {

  /* long-running background operation */
  BlockJob *job;
 +
 +unsigned int max_sectors;
 +unsigned int max_segments;
 +unsigned int max_segment_size;
  };

  int get_tmp_filename(char *filename, int size);
 diff --git a/blockdev.c b/blockdev.c
 index 3d75015..e17edbf 100644
 --- a/blockdev.c
 +++ b/blockdev.c
 @@ -1191,3 +1191,18 @@ BlockJobInfoList *qmp_query_block_jobs(Error **errp)
  bdrv_iterate(do_qmp_query_block_jobs_one, prev);
  return dummy.next;
  }
 +
 +unsigned int get_queue_max_sectors(BlockDriverState *bs)

These should be bdrv_get_queue_max_sectors(BlockDriverState *bs) and
should live in block.c.

 +{
 +return (bs-file  bs-file-sg) ? bs-file-max_sectors : 0;

The BlockDriver should be able to provide these values, we shouldn't
reach into bs-file.



Re: [Qemu-devel] [PATCH 1/2 v1] blkdrv: Add queue limits parameters for sg block drive

2012-08-21 Thread Stefan Hajnoczi
On Tue, Aug 21, 2012 at 10:41 AM, Cong Meng m...@linux.vnet.ibm.com wrote:


 On Tue 21 Aug 2012 04:48:17 PM CST, Paolo Bonzini wrote:

 Il 21/08/2012 10:23, Cong Meng ha scritto:

 +static void sg_get_queue_limits(BlockDriverState *bs, const char
 *filename)
 +{
 +DIR *ffs;
 +struct dirent *d;
 +char path[MAXPATHLEN];
 +
 +snprintf(path, MAXPATHLEN,
 + /sys/class/scsi_generic/sg%s/device/block/,
 + filename + strlen(/dev/sg));
 +
 +ffs = opendir(path);
 +if (!ffs) {
 +return;
 +}
 +
 +for (;;) {
 +d = readdir(ffs);
 +if (!d) {
 +return;
 +}
 +
 +if (strcmp(d-d_name, .) == 0 || strcmp(d-d_name, ..) == 0)
 {
 +continue;
 +}
 +
 +break;
 +}
 +
 +closedir(ffs);
 +
 +pstrcat(path, MAXPATHLEN, d-d_name);
 +pstrcat(path, MAXPATHLEN, /queue/);
 +
 +read_queue_limit(path, max_sectors_kb, bs-max_sectors);
 +read_queue_limit(path, max_segments, bs-max_segments);
 +read_queue_limit(path, max_segment_size, bs-max_segment_size);
 +}


 Using /sys/dev/block or /sys/dev/char seems easier, and lets you
 retrieve the parameters for block devices too.

 what do you mean with block devices?   Using /dev/sda instead of
 /dev/sg0?


 However, I'm worried of the consequences this has for migration.  You
 could have the same physical disk accessed with two different HBAs, with
 different limits.  So I don't know if this can really be solved at all.

 I know little about qemu migration now.  The pending scsi commands will be
 saved and
 transfered to remote machine when starting migration?

Passthrough is already a migration blocker if both hosts do not have
access to the same LUNs.

When both hosts do have access to the same LUNs it's possible to
extract the block queue limits (using sysfs) and compare them.

Today you can start QEMU with different image files on both hosts.
Migration will appear to work but the disk image on the destination
host could be junk.  This is a similar case, I don't see a problem
except that there should be a safety check (maybe at the libvirt
level) to make this safe.

Stefan



Re: [Qemu-devel] [PATCH 2/2 v1] virtio-scsi: set per-LUN queue limits for sg devices

2012-08-21 Thread Stefan Hajnoczi
On Tue, Aug 21, 2012 at 9:23 AM, Cong Meng m...@linux.vnet.ibm.com wrote:
 @@ -557,6 +621,7 @@ static uint32_t virtio_scsi_get_features(VirtIODevice 
 *vdev,
  {
  requested_features |= (1UL  VIRTIO_SCSI_F_HOTPLUG);
  requested_features |= (1UL  VIRTIO_SCSI_F_CHANGE);
 +requested_features |= (1UL  VIRTIO_SCSI_F_LUN_QUERY);

This should be a QEMU 1.3 and later feature bit.  VMs running with -m
pc-1.2 or earlier should not see it by default, this ensure the device
ABI is stable.  For more info, see:
http://patchwork.ozlabs.org/patch/177924/

Stefan



Re: [Qemu-devel] [RFC/PATCH] qemu: Use valgrind annotations to mark kvm guest memory as defined

2012-08-21 Thread Avi Kivity
On 08/21/2012 12:03 PM, Christian Borntraeger wrote:
 On 10/08/12 15:11, Christian Borntraeger wrote:
 valgrind with kvm produces a big amount of false positives regarding
 Conditional jump or move depends on uninitialised value(s). This
 happens because the guest memory is allocated with qemu_vmalloc which
 boils down posix_memalign etc. This function is (correctly) considered
 by valgrind as returning undefined memory.
 
 Since valgrind is based on jitting code, it will not be able to see
 changes made by the guest to guest memory if this is done by KVM_RUN,
 thus keeping most of the guest memory undefined.
 
 Now lots of places in qemu will then use guest memory to change behaviour.
 To avoid the flood of these messages, lets declare the whole guest
 memory as defined. This will reduce the noise and allows us to see real
 problems.
 
 In the future we might want to make this conditional, since there
 is actually something that we can use those false positives for:
 These messages will point to code that depends on guest memory, so
 we can use these backtraces to actually make an audit that is focussed
 only at those code places. For normal development we dont want to
 see those messages, though.
 
 
 Any opinion about this patch?

Missed it, sorry.  Now applied to uq/master, thanks.


-- 
error compiling committee.c: too many arguments to function



Re: [Qemu-devel] [PATCH] qapi: add 'query-target' command to return target arch/bit size

2012-08-21 Thread Daniel P. Berrange
On Mon, Aug 20, 2012 at 04:48:24PM -0500, Anthony Liguori wrote:
 Daniel P. Berrange berra...@redhat.com writes:
 
  From: Daniel P. Berrange berra...@redhat.com
 
  Add a 'query-target' QAPI command to allow management applications
  to determine what target architecture a QEMU binary is emulating
  without having to parse the binary name or -help output
 
$ qmp-shell -p /tmp/qemu
(QEMU) query-target
{   u'return': {   u'arch': u'x86_64', u'bits': 64}}
 
 bits is really ambiguous.  What it means in QEMU (specifically the
 value you are returning) is probably not what you expect it to mean.

My intent was to indicate the pointer word size for the architecture.
eg 64 for x86_64, ppc64, etc, and 32 and i686, ppc, etc. Probably
should have called it 'wordsize' or something like that

 We're going to most likely fix TARGET_PHYS_ADDR_BITS to 64 real soon.

Hmm, when I looked at the header in my checkout it already
*is* 64 or 32 as I'd expect for the architecture in question.

$ grep PHYS_ADDR_BITS */config-target.mak
alpha-softmmu/config-target.mak:TARGET_PHYS_ADDR_BITS=64
arm-softmmu/config-target.mak:TARGET_PHYS_ADDR_BITS=64
cris-softmmu/config-target.mak:TARGET_PHYS_ADDR_BITS=32
i386-softmmu/config-target.mak:TARGET_PHYS_ADDR_BITS=64
lm32-softmmu/config-target.mak:TARGET_PHYS_ADDR_BITS=32
m68k-softmmu/config-target.mak:TARGET_PHYS_ADDR_BITS=32
microblazeel-softmmu/config-target.mak:TARGET_PHYS_ADDR_BITS=32
microblaze-softmmu/config-target.mak:TARGET_PHYS_ADDR_BITS=32
mips64el-softmmu/config-target.mak:TARGET_PHYS_ADDR_BITS=64
mips64-softmmu/config-target.mak:TARGET_PHYS_ADDR_BITS=64
mipsel-softmmu/config-target.mak:TARGET_PHYS_ADDR_BITS=64
mips-softmmu/config-target.mak:TARGET_PHYS_ADDR_BITS=64
ppc64-softmmu/config-target.mak:TARGET_PHYS_ADDR_BITS=64
ppcemb-softmmu/config-target.mak:TARGET_PHYS_ADDR_BITS=64
ppc-softmmu/config-target.mak:TARGET_PHYS_ADDR_BITS=64
s390x-softmmu/config-target.mak:TARGET_PHYS_ADDR_BITS=64
sh4eb-softmmu/config-target.mak:TARGET_PHYS_ADDR_BITS=32
sh4-softmmu/config-target.mak:TARGET_PHYS_ADDR_BITS=32
sparc64-softmmu/config-target.mak:TARGET_PHYS_ADDR_BITS=64
sparc-softmmu/config-target.mak:TARGET_PHYS_ADDR_BITS=64
x86_64-softmmu/config-target.mak:TARGET_PHYS_ADDR_BITS=64
xtensaeb-softmmu/config-target.mak:TARGET_PHYS_ADDR_BITS=32
xtensa-softmmu/config-target.mak:TARGET_PHYS_ADDR_BITS=32

 Why did you include this field?  What information are you looking to get
 from QEMU and what decisions do you plan to make with it?

When libvirt reports the host capabilities it includes the
architecture name and wordsize, amongst other things:

  # virsh capabilities
  snip...
  guest
os_typehvm/os_type
arch name='arm'
  wordsize32/wordsize
  emulator/bin/qemu-system-arm/emulator
  ...

Currently we just have a table of arch name - wordsize mapping
data in libvirt. I figured if I was adding a 'query-target' command
to QEMU, we might as well include this info too. It is not critical
though if you'd rather we omitted it though.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|



Re: [Qemu-devel] [PATCH] qapi: add 'query-target' command to return target arch/bit size

2012-08-21 Thread Daniel P. Berrange
On Mon, Aug 20, 2012 at 04:02:39PM -0300, Luiz Capitulino wrote:
 On Mon, 20 Aug 2012 15:31:38 +0100
 Daniel P. Berrange berra...@redhat.com wrote:
 
  From: Daniel P. Berrange berra...@redhat.com
  
  Add a 'query-target' QAPI command to allow management applications
  to determine what target architecture a QEMU binary is emulating
  without having to parse the binary name or -help output
  
$ qmp-shell -p /tmp/qemu
(QEMU) query-target
{   u'return': {   u'arch': u'x86_64', u'bits': 64}}
  
  Signed-off-by: Daniel P. Berrange berra...@redhat.com
  ---
   arch_init.c  | 11 +++
   qapi-schema.json | 25 +
   qmp-commands.hx  |  5 +
   3 files changed, 41 insertions(+)
  
  diff --git a/arch_init.c b/arch_init.c
  index 9b46bfc..095672d 100644
  --- a/arch_init.c
  +++ b/arch_init.c
  @@ -1080,3 +1080,14 @@ int xen_available(void)
   return 0;
   #endif
   }
  +
  +
  +TargetInfo *qmp_query_target(Error **errp)
  +{
  +TargetInfo *info = g_malloc0(sizeof(*info));
  +
  +info-arch = g_strdup(TARGET_ARCH);
  +info-bits = TARGET_PHYS_ADDR_BITS;
  +
  +return info;
  +}
  diff --git a/qapi-schema.json b/qapi-schema.json
  index 3d2b2d1..f0e3fe0 100644
  --- a/qapi-schema.json
  +++ b/qapi-schema.json
  @@ -2454,3 +2454,28 @@
   #
   ##
   { 'command': 'query-fdsets', 'returns': ['FdsetInfo'] }
  +
  +##
  +# @TargetInfo:
  +#
  +# Information describing the QEMU target.
  +#
  +# @arch: the name of the target architecture (eg x86_64, i686, etc)
 
 Should be an enum, otherwise looks good.

Really ? It feels a little bit odd to make this an enum IMHO.

Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|



Re: [Qemu-devel] memory: could we add extra input param for memory_region_init_io()?

2012-08-21 Thread Avi Kivity
On 08/21/2012 12:25 PM, liu ping fan wrote:
 On Tue, Aug 21, 2012 at 4:57 PM, Avi Kivity a...@redhat.com wrote:
 On 08/21/2012 07:48 AM, liu ping fan wrote:
 On Sun, Aug 19, 2012 at 7:36 PM, Avi Kivity a...@redhat.com wrote:
 On 08/19/2012 02:23 PM, Peter Maydell wrote:
 On 19 August 2012 11:12, Avi Kivity a...@redhat.com wrote:
 On 08/17/2012 10:41 AM, liu ping fan wrote:
 And something like omap_mpu_timer_init() in file hw/omap1.c , the
 opaque(omap_mpu_timer_s) is got from g_malloc0, which makes things
 even harder to handle.  And the DO_CAST can not work for such issue.

 IMO omap_mpu_timer_s should be a DeviceState.  Peter?

 Ideally, yes, but qemu is full of devices that haven't yet made the leap
 to QOM.

 omap1 is particularly tricky because I don't actually have any test images
 for it, so refactoring it is a leap in the dark. [I've tried asking on 
 this list
 if anybody had test images a couple of times without success.]

 Okay.  Most of the options in this thread don't involve wholesale
 conversion of the opaque parameter in memory_region_init_io() to type
 Object *, so it's not necessary to convert everything.

 But I think if the mr belongs to mem address space, it can not avoid
 object_ref(Object *opaque) in mmio-dispatch code. ( If we use extra
 flag to indicate whether the opaque is Object or not, then we lose the
 meaning to transfer opaque to Object type, and maybe
 memory_region_set_object() is a better choice).

 I'm not sure I understand.  What do you mean by ability to transfer
 opaque to Object type?

 Maybe I misunderstand your meaning of Okay.  Most of the options in
 this thread don't involve wholesale ..., so it's not necessary to
 convert everything
 I think you mean that omap_mpu_timer_s need NOT to convert.  

That is what I meant.

 But as
 it will also take the code path which has object_ref(Object*), so it
 has to convert, otherwise the code will corrupt.
 That is what I want to express.

Option 2, for example, had MemoryRegionOps::object(MemoryRegion *) which
can be used to convert the opaque to an Object, or return NULL.  With
that option, there would be no corruption:

  qemu_mutex_lock(mem_map_lock);
  MemoryRegionSection mrs = walk(phys_map);
  Object *object = mrs.mr-ops-object(mrs.mr);
  if (object) {
  object_ref(object);
  }
  qemu_mutex_unlock(mem_map_unlock);

So there is no memory corruption.  However, as I point out below, we
also lack the reference count.  Maybe we could do something like:

  qemu_mutex_lock(mem_map_lock);
  MemoryRegionSection mrs = walk(phys_map);
  Object *object = mrs.mr-ops-object(mrs.mr);
  if (object) {
  object_ref(object);
  } else {
  goto retry_with_qemu_lock_held;
  }
  qemu_mutex_unlock(mem_map_unlock);

But that's very inelegant.


 Agree.  The best example is device assignment, where BARs will need to
 turn into Objects.  It means that an assigned device can disappear while
 one of its BARs remain, so the code will have to handle this case.

 How about the initialization of BAR inc ref of assigned device; and
 finalization of BAR dec it?

If we can avoid a cycle.  Won't the device need to hold refs to the BAR?
 Unfortunately, requiring a 1:1 opaque:Object relationship means huge
 churn in the code.  But I don't think it can be avoided, even with
 memory_region_set_object().

 Yeah, and I am studying the different case to see how to resolve and
 make plans about the huge conversion.

Ok.  One one hand, I think the conversion is unavoidable, and is also
beneficial: I never liked opaques.

On the other hand, those conversions are very tedious, introduce
regressions, and delay the result.

Anthony, any insight on this?

-- 
error compiling committee.c: too many arguments to function



Re: [Qemu-devel] [RFC V4 3/9] quorum: Add quorum_open() and quorum_close().

2012-08-21 Thread Benoît Canet
Le Monday 20 Aug 2012 à 14:37:08 (-0600), Eric Blake a écrit :
 On 08/20/2012 01:47 PM, Blue Swirl wrote:
  On Mon, Aug 20, 2012 at 11:47 AM, Benoît Canet benoit.ca...@gmail.com 
  wrote:
  Valid quorum resources look like:
  quorum:threshold/total:path/to/image_1: ... :path/to/image_total
 
  '\' can escape the ':' character.
 
 Also, \ escapes itself (although admittedly : is more likely than \ in a
 file name needing escaping).

After a few tests this escaping code seems broken.
Will fix it.

Benoît
 
 -- 
 Eric Blake   ebl...@redhat.com+1-919-301-3266
 Libvirt virtualization library http://libvirt.org
 





Re: [Qemu-devel] [PATCH] target-mips: Enable access to required RDHWR hardware registers

2012-08-21 Thread Andreas Färber
Am 21.08.2012 01:41, schrieb Meador Inge:
 While running in the usermode emulator all of the MIPS32r2 *required*
 RDHWR hardware registers should be accessible (the Linux kernel enables
 access to these same registers).
 
 Signed-off-by: Meador Inge mead...@codesourcery.com
 ---
  target-mips/translate.c |7 +--
  1 files changed, 5 insertions(+), 2 deletions(-)
 
 diff --git a/target-mips/translate.c b/target-mips/translate.c
 index 47daf85..849e75d 100644
 --- a/target-mips/translate.c
 +++ b/target-mips/translate.c
 @@ -12768,8 +12768,11 @@ void cpu_state_reset(CPUMIPSState *env)
  
  #if defined(CONFIG_USER_ONLY)
  env-hflags = MIPS_HFLAG_UM;
 -/* Enable access to the SYNCI_Step register.  */
 -env-CP0_HWREna |= (1  1);
 +if (env-insn_flags  ISA_MIPS32R2) {
 +/* Enable access to the CPUNum, SYNCI_Step, CC, and CCRes RDHWR
 +   hardware registers.  */
 +env-CP0_HWREna |= 0x000F;
 +}

So what about the non-MIPS32r2 case? IIUC then the SYNCI_Step register
would no longer be accessible, which your commit message does not
mention. Intentional?

If this is a bugfix for v1.2.0 don't forget to mark for-1.2.

Andreas

  if (env-CP0_Config1  (1  CP0C1_FP)) {
  env-hflags |= MIPS_HFLAG_FPU;
  }
 


-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



Re: [Qemu-devel] [PATCH 1/2 v1] blkdrv: Add queue limits parameters for sg block drive

2012-08-21 Thread Paolo Bonzini
Il 21/08/2012 11:52, Stefan Hajnoczi ha scritto:
  Using /sys/dev/block or /sys/dev/char seems easier, and lets you
  retrieve the parameters for block devices too.
 
  what do you mean with block devices?   Using /dev/sda instead of
  /dev/sg0?

Yes.

  However, I'm worried of the consequences this has for migration.  You
  could have the same physical disk accessed with two different HBAs, with
  different limits.  So I don't know if this can really be solved at all.
 
  I know little about qemu migration now.  The pending scsi commands will be
  saved and
  transfered to remote machine when starting migration?
 
 Passthrough is already a migration blocker if both hosts do not have
 access to the same LUNs.

Yes, but requiring the exact same hardware may be too much.  I'm trying
to understand the problem better before committing to a threefold
spec/qemu/kernel change.

Cong, what is the limit that the host HBA enforces (and what is the
HBA)?  What commands see a problem?  Is it fixed by using scsi-block
instead of scsi-generic (if you can use scsi-block at all, i.e. it's not
a tape or similar device)?

With scsi-generic, QEMU uses a bounce buffer for non-I/O commands to a
SCSI passthrough device, so the only problem in that case should be the
maximum segment size.  This could change in the future, but max_segments
and max_sectors should not yet be a problem.

With scsi-block, QEMU will use read/write on the block device and the
host kernel will then obey the host HBA's block limits.  QEMU will still
use a bounce buffer for non-I/O commands to a scsi-block device, but the
payload is usually small for non-I/O commands.

Paolo

 When both hosts do have access to the same LUNs it's possible to
 extract the block queue limits (using sysfs) and compare them.
 
 Today you can start QEMU with different image files on both hosts.
 Migration will appear to work but the disk image on the destination
 host could be junk.  This is a similar case, I don't see a problem
 except that there should be a safety check (maybe at the libvirt
 level) to make this safe.




[Qemu-devel] [PATCH v10 1/4] qxl/update_area_io: guest_bug on invalid parameters

2012-08-21 Thread Alon Levy
Signed-off-by: Alon Levy al...@redhat.com
---
v9-v10
 Use CONFIG_QXL_IO_MONITORS_CONFIG_ASYNC instead of -D directly, define is 
created in config-host.h
 so hw/qxl.[ch] is unchanged except for 
s/QXL_HAS_IO_MONITORS_CONFIG_ASYNC/CONFIG_QXL_IO_MONITORS_CONFIG_ASYNC
 (Blue Swirl)
 No other patches changed. Dropped the wrongly sent last patch.

 hw/qxl.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/hw/qxl.c b/hw/qxl.c
index c2dd3b4..6c48eb9 100644
--- a/hw/qxl.c
+++ b/hw/qxl.c
@@ -1385,6 +1385,18 @@ async_common:
 QXLCookie *cookie = NULL;
 QXLRect update = d-ram-update_area;
 
+if (d-ram-update_surface  NUM_SURFACES) {
+qxl_set_guest_bug(d, QXL_IO_UPDATE_AREA: invalid surface id %d\n,
+  d-ram-update_surface);
+return;
+}
+if (update.left = update.right || update.top = update.bottom) {
+qxl_set_guest_bug(d,
+QXL_IO_UPDATE_AREA: invalid area (%ux%u)x(%ux%u)\n,
+update.left, update.top, update.right, update.bottom);
+return;
+}
+
 if (async == QXL_ASYNC) {
 cookie = qxl_cookie_new(QXL_COOKIE_TYPE_IO,
 QXL_IO_UPDATE_AREA_ASYNC);
-- 
1.7.11.2




Re: [Qemu-devel] [PATCH] qapi: add 'query-target' command to return target arch/bit size

2012-08-21 Thread Peter Maydell
On 21 August 2012 11:05, Daniel P. Berrange berra...@redhat.com wrote:
 On Mon, Aug 20, 2012 at 04:48:24PM -0500, Anthony Liguori wrote:
 bits is really ambiguous.  What it means in QEMU (specifically the
 value you are returning) is probably not what you expect it to mean.

 My intent was to indicate the pointer word size for the architecture.
 eg 64 for x86_64, ppc64, etc, and 32 and i686, ppc, etc. Probably
 should have called it 'wordsize' or something like that

This is not the same as the physical address size...

 Hmm, when I looked at the header in my checkout it already
 *is* 64 or 32 as I'd expect for the architecture in question.

 $ grep PHYS_ADDR_BITS */config-target.mak
 alpha-softmmu/config-target.mak:TARGET_PHYS_ADDR_BITS=64
 arm-softmmu/config-target.mak:TARGET_PHYS_ADDR_BITS=64

...eg for ARM we have a 32 bit pointer size but 40 bit physical
addresses (on some cores) and we set TARGET_PHYS_ADDR_BITS
to 64 in all cases.

 i386-softmmu/config-target.mak:TARGET_PHYS_ADDR_BITS=64

i386 is the other obvious pointers are 32 bit but we
set TARGET_PHYS_ADDR_BITS wider, for about the same reasons.

-- PMM



Re: [Qemu-devel] [RFC] How should QEMU code handle include statements

2012-08-21 Thread Avi Kivity
On 08/20/2012 11:07 PM, Stefan Weil wrote:

 While I personally prefer (1) and used it for my first contributions,
 QEMU introduced qemu-common.h. I had the impression that from then on
 QEMU preferred strategy (2). Obviously not everybody shares that
 impression.
 
 Which strategy / rule do we want to use for QEMU code?

(1).


-- 
error compiling committee.c: too many arguments to function



[Qemu-devel] [PATCH v10 2/4] qxl: disallow unknown revisions

2012-08-21 Thread Alon Levy
Signed-off-by: Alon Levy al...@redhat.com
---
 hw/qxl.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/hw/qxl.c b/hw/qxl.c
index 6c48eb9..c978f5e 100644
--- a/hw/qxl.c
+++ b/hw/qxl.c
@@ -1797,10 +1797,13 @@ static int qxl_init_common(PCIQXLDevice *qxl)
 io_size = 16;
 break;
 case 3: /* qxl-3 */
-default:
 pci_device_rev = QXL_DEFAULT_REVISION;
 io_size = msb_mask(QXL_IO_RANGE_SIZE * 2 - 1);
 break;
+default:
+error_report(Invalid revision %d for qxl device (max %d),
+ qxl-revision, QXL_DEFAULT_REVISION);
+return -1;
 }
 
 pci_set_byte(config[PCI_REVISION_ID], pci_device_rev);
-- 
1.7.11.2




Re: [Qemu-devel] TPM does not seem to work under QEMU with TPM patches

2012-08-21 Thread Jordi Cucurull Juan

Hi Kent,

I have solved the issue. The problem was that in CentOS the tpm_dis 
driver is integrated into the kernel and it was not loaded by default. I 
have added the following keywords to the kernel load line in the bootloader:


tpm_tis.force=1

Now the /dev/tpm0 device appears in the virtual machine and the TSS 
library loads correctly.


Thanks!
Jordi.


On 08/20/2012 10:14 PM, Kent Yoder wrote:

Hi Jordi,

On Mon, Aug 20, 2012 at 06:12:44PM -0400, Jordi Cucurull Juan wrote:

Dear all,

I am testing the TPM patches of Stefan Berger to provide TPM support
to QEMU. Nevertheless I have not managed to run them successfully.
During the compilation of QEMU with his patches (V18 for revision
563987d) I have not had any issue. But, I have a virtual machine
based on CentOS 6.2 and the TPM does not seem to be present. I run
the machine with the following command line (as a root user):

# /usr/local/bin/qemu-system-x86_64 -hda qemu-disk-centos.img -m
1024 -boot d -enable-kvm -usbdevice tablet -k es -tpmdev
passthrough,id=tpm0,path=/dev/tpm0 -device tpm-tis,tpmdev=tpm0

My real machine has an Infineon TPM v1.2. When I try to load the TSS
library (Trousers) inside the client machine (the CentOS 6.2) it
throws the following error:

insmod: error inserting 
'/lib/modules/2.6.32-279.5.1.el6.x86_64/kernel/drivers/char/tpm/tpm_atmel.ko':
-1 no such device

   This should be fine - the tpm_tis driver should be driving the vtpm.


Apart from this, QEMU does not throw any error. Should I enable
something else to have access to the TPM? In addition, I do not see
any /dev/vtpm0 device in my real machine.

   As I understand them, the qemu patches allow direct writing from the
guest to the host's /dev/tpm0, so you wouldn't see a new device node.

Kent


Best regards,
Jordi.


--
Jordi Cucurull Juan
Researcher
Scytl Secure Electronic Voting
Plaça Gal·la Placidia, 1-3, 1st floor · 08006 Barcelona
Phone: + 34 934 230 324
Fax+ 34 933 251 028
jordi.cucur...@scytl.com
http://www.scytl.com

NOTICE: The information in this e-mail and in any of its attachments is 
confidential and intended solely for the attention and use of the named 
addressee(s). If you are not the intended recipient, any disclosure, copying, 
distribution or retaining of this message or any part of it, without the prior 
written consent of Scytl Secure Electronic Voting, SA is prohibited and may be 
unlawful. If you have received this in error, please contact the sender and 
delete the material from any computer.

Your data are in a file owned by Scytl Secure Electronic Voting, S.A. You can 
exercice your rights of access, rectification, cancellation and opposition by 
contacting Scytl Secure Electronic Voting, S.A. at the following address: 
Gal·la Placídia, 1-3. 1st, 08006 Barcelona (Spain), according to the Organic 
Law 15/1999, of 13th December of Protection of Personal Data.










Re: [Qemu-devel] [PATCH] qapi: add 'query-target' command to return target arch/bit size

2012-08-21 Thread Daniel P. Berrange
On Tue, Aug 21, 2012 at 11:17:40AM +0100, Peter Maydell wrote:
 On 21 August 2012 11:05, Daniel P. Berrange berra...@redhat.com wrote:
  On Mon, Aug 20, 2012 at 04:48:24PM -0500, Anthony Liguori wrote:
  bits is really ambiguous.  What it means in QEMU (specifically the
  value you are returning) is probably not what you expect it to mean.
 
  My intent was to indicate the pointer word size for the architecture.
  eg 64 for x86_64, ppc64, etc, and 32 and i686, ppc, etc. Probably
  should have called it 'wordsize' or something like that
 
 This is not the same as the physical address size...
 
  Hmm, when I looked at the header in my checkout it already
  *is* 64 or 32 as I'd expect for the architecture in question.
 
  $ grep PHYS_ADDR_BITS */config-target.mak
  alpha-softmmu/config-target.mak:TARGET_PHYS_ADDR_BITS=64
  arm-softmmu/config-target.mak:TARGET_PHYS_ADDR_BITS=64
 
 ...eg for ARM we have a 32 bit pointer size but 40 bit physical
 addresses (on some cores) and we set TARGET_PHYS_ADDR_BITS
 to 64 in all cases.
 
  i386-softmmu/config-target.mak:TARGET_PHYS_ADDR_BITS=64
 
 i386 is the other obvious pointers are 32 bit but we
 set TARGET_PHYS_ADDR_BITS wider, for about the same reasons.

Ok, so I'll just respin this patch  remove the 'bits' field entirely
so we avoid the confusion.

Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|



[Qemu-devel] [PATCH] qemu-ga: report success-response field in guest-info

2012-08-21 Thread Michal Privoznik
This is a useful hint for users (or libvirt) whether a command returns
anything success and hence wait for reply or not.
---
 qapi-schema-guest.json |6 +-
 qapi/qmp-core.h|1 +
 qapi/qmp-registry.c|   12 
 qga/commands.c |1 +
 4 files changed, 19 insertions(+), 1 deletions(-)

diff --git a/qapi-schema-guest.json b/qapi-schema-guest.json
index d955cf1..2cd5957 100644
--- a/qapi-schema-guest.json
+++ b/qapi-schema-guest.json
@@ -91,10 +91,14 @@
 #
 # @enabled: whether command is currently enabled by guest admin
 #
+# @success-response: whether command report success response or not.
+#See 'uest-shutdown' command for more detailed info.
+#
 # Since 1.1.0
 ##
 { 'type': 'GuestAgentCommandInfo',
-  'data': { 'name': 'str', 'enabled': 'bool' } }
+  'data': { 'name': 'str', 'enabled': 'bool',
+'success-response': 'bool'} }
 
 ##
 # @GuestAgentInfo
diff --git a/qapi/qmp-core.h b/qapi/qmp-core.h
index 00446cf..271c3f2 100644
--- a/qapi/qmp-core.h
+++ b/qapi/qmp-core.h
@@ -48,6 +48,7 @@ QObject *qmp_dispatch(QObject *request);
 void qmp_disable_command(const char *name);
 void qmp_enable_command(const char *name);
 bool qmp_command_is_enabled(const char *name);
+bool qmp_command_reports_success(const char *name);
 char **qmp_get_command_list(void);
 QObject *qmp_build_error_object(Error *errp);
 
diff --git a/qapi/qmp-registry.c b/qapi/qmp-registry.c
index 5414613..d706cb1 100644
--- a/qapi/qmp-registry.c
+++ b/qapi/qmp-registry.c
@@ -77,6 +77,18 @@ bool qmp_command_is_enabled(const char *name)
 return false;
 }
 
+bool qmp_command_reports_success(const char *name) {
+QmpCommand *cmd;
+
+QTAILQ_FOREACH(cmd, qmp_commands, node) {
+if (strcmp(cmd-name, name) == 0) {
+return cmd-options ^ QCO_NO_SUCCESS_RESP;
+}
+}
+
+return true;
+}
+
 char **qmp_get_command_list(void)
 {
 QmpCommand *cmd;
diff --git a/qga/commands.c b/qga/commands.c
index 46b0b08..9811221 100644
--- a/qga/commands.c
+++ b/qga/commands.c
@@ -63,6 +63,7 @@ struct GuestAgentInfo *qmp_guest_info(Error **err)
 cmd_info = g_malloc0(sizeof(GuestAgentCommandInfo));
 cmd_info-name = strdup(*cmd_list);
 cmd_info-enabled = qmp_command_is_enabled(cmd_info-name);
+cmd_info-success_response = 
qmp_command_reports_success(cmd_info-name);
 
 cmd_info_list = g_malloc0(sizeof(GuestAgentCommandInfoList));
 cmd_info_list-value = cmd_info;
-- 
1.7.8.6




Re: [Qemu-devel] [PATCH v2] kvm-all.c: Move init of irqchip_inject_ioctl out of kvm_irqchip_create()

2012-08-21 Thread Jan Kiszka
On 2012-08-21 10:25, Peter Maydell wrote:
 On 21 August 2012 09:19, Jan Kiszka jan.kis...@siemens.com wrote:
 On 2012-08-15 13:08, Peter Maydell wrote:
 Move the init of the irqchip_inject_ioctl field of KVMState out of
 kvm_irqchip_create() and into kvm_init(), so that kvm_set_irq()
 can be used even when no irqchip is created (for architectures
 that support async interrupt notification even without an in
 kernel irqchip).
 
 As it's not yet merged, some late comment: irqchip_inject_ioctl should
 be renamed as well. irq_inject_ioctl?
 
 If we're changing it anyway, IIRC Avi didn't like the term inject
 here?

Then irq_set_ioctl.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux



[Qemu-devel] Is is possible to virtualise or share the TPM?

2012-08-21 Thread Jordi Cucurull Juan

Dear all,

After applying the TPM patches to QEMU, I was wondering if it is 
possible to simultaneously use the TPM in more than one virtual machine, 
i.e. virtualisation of the TPM.


According to the paper Stefan Berger, Ramón Cáceres, Kenneth A. 
Goldman, Ronald Perez, Reiner Sailer, Leendert van Doorn. vTPM: 
Virtualizing the Trusted Platform Module this seems to be possible in 
Xen. Is not possible in QEMU?


Thanks!
Jordi.




Re: [Qemu-devel] [PATCH v10 3/4] qxl: add QXL_IO_MONITORS_CONFIG_ASYNC

2012-08-21 Thread Gerd Hoffmann
On 08/21/12 12:16, Alon Levy wrote:
 Revision bumped to 4 for new IO support, enabled for spice-server =
 0.11.1. New io enabled iff revision is 4. Revision can be set to 4, and
 defaults to 4, iff spice-server = 0.11.1  spice-protocol =
 0.12.0.
 
 This io calls the corresponding new spice api
 spice_qxl_monitors_config_async to let spice-server read a new guest set
 monitors config and notify the client.
 
 On migration reissue spice_qxl_monitors_config_async.

Applying: qxl: add QXL_IO_MONITORS_CONFIG_ASYNC
=== checkpatch complains ===
ERROR: space prohibited before open square bracket '['
#198: FILE: hw/qxl.c:2116:
+.fields = (VMStateField []) {

ERROR: space prohibited before open square bracket '['
#211: FILE: hw/qxl.c:2148:
+.subsections = (VMStateSubsection []) {

total: 2 errors, 0 warnings, 231 lines checked



Re: [Qemu-devel] [PATCH v3 0/5] add support for spice migration v3

2012-08-21 Thread Gerd Hoffmann
 Yonit Halperin (5):
   spice: notify spice server on vm start/stop
   spice: notify on vm state change only via spice_server_vm_start/stop
   spice migration: add QEVENT_SPICE_MIGRATE_COMPLETED
   spice: add 'migrated' flag to spice info
   spice: adding seamless-migration option to the command line

Patches added to spice patch queue.

thanks,
  Gerd



[Qemu-devel] [PATCH v10 4/4] configure: print spice-protocol and spice-server versions

2012-08-21 Thread Alon Levy
Signed-off-by: Alon Levy al...@redhat.com
---
 configure | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index 84fa2c6..02c06aa 100755
--- a/configure
+++ b/configure
@@ -2657,6 +2657,8 @@ EOF
 spice=yes
 libs_softmmu=$libs_softmmu $spice_libs
 QEMU_CFLAGS=$QEMU_CFLAGS $spice_cflags
+spice_protocol_version=$($pkg_config --modversion spice-protocol)
+spice_server_version=$($pkg_config --modversion spice-server)
 if $pkg_config --atleast-version=0.12.0 spice-protocol /dev/null 21; 
then
 spice_qxl_io_monitors_config_async=yes
 fi
@@ -3114,7 +3116,7 @@ echo libcap-ng support $cap_ng
 echo vhost-net support $vhost_net
 echo Trace backend $trace_backend
 echo Trace output file $trace_file-pid
-echo spice support $spice
+echo spice support $spice ($spice_protocol_version/$spice_server_version)
 echo rbd support   $rbd
 echo xfsctl support$xfs
 echo nss used  $smartcard_nss
-- 
1.7.11.2




Re: [Qemu-devel] [PATCH] PPC: Update openbios-bin

2012-08-21 Thread Andreas Färber
Am 21.08.2012 00:33, schrieb Alexander Graf:
 This updates the OpenBIOS binaries for PPC to svn revision 1063,
 fixing -M g3beige with large PCI memory users.
 
 Signed-off-by: Alexander Graf ag...@suse.de
 ---
  pc-bios/README   |3 ++-
  pc-bios/openbios-ppc |  Bin 729876 - 750392 bytes
  2 files changed, 2 insertions(+), 1 deletions(-)

The git submodule should also be updated,
http://git.qemu.org/?p=qemu.git;a=commit;h=682527c00409d676c0d3b9fac99ca3b2fdfd6d2c
forgot that, too. This leads to the wrong sources being packaged for the
tarball.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



Re: [Qemu-devel] [PATCH 1/8] buffered_file: g_realloc() can't fail

2012-08-21 Thread Orit Wasserman
On 08/18/2012 02:17 PM, Juan Quintela wrote:
 Signed-off-by: Juan Quintela quint...@redhat.com
 ---
  buffered_file.c | 10 +-
  1 file changed, 1 insertion(+), 9 deletions(-)
 
 diff --git a/buffered_file.c b/buffered_file.c
 index f170aa0..4148abb 100644
 --- a/buffered_file.c
 +++ b/buffered_file.c
 @@ -50,20 +50,12 @@ static void buffered_append(QEMUFileBuffered *s,
  const uint8_t *buf, size_t size)
  {
  if (size  (s-buffer_capacity - s-buffer_size)) {
 -void *tmp;
 -
  DPRINTF(increasing buffer capacity from %zu by %zu\n,
  s-buffer_capacity, size + 1024);
 
  s-buffer_capacity += size + 1024;
 
 -tmp = g_realloc(s-buffer, s-buffer_capacity);
 -if (tmp == NULL) {
 -fprintf(stderr, qemu file buffer expansion failed\n);
 -exit(1);
 -}
 -
 -s-buffer = tmp;
 +s-buffer = g_realloc(s-buffer, s-buffer_capacity);
  }
 
  memcpy(s-buffer + s-buffer_size, buf, size);
 

Reviewed-by: Orit Wasserman owass...@redhat.com



[Qemu-devel] [PATCH v10 3/4] qxl: add QXL_IO_MONITORS_CONFIG_ASYNC

2012-08-21 Thread Alon Levy
Revision bumped to 4 for new IO support, enabled for spice-server =
0.11.1. New io enabled iff revision is 4. Revision can be set to 4, and
defaults to 4, iff spice-server = 0.11.1  spice-protocol =
0.12.0.

This io calls the corresponding new spice api
spice_qxl_monitors_config_async to let spice-server read a new guest set
monitors config and notify the client.

On migration reissue spice_qxl_monitors_config_async.

RHBZ: 770842

Signed-off-by: Alon Levy al...@redhat.com
---
 configure  |  7 +
 hw/qxl.c   | 91 --
 hw/qxl.h   |  8 +
 trace-events   |  1 +
 ui/spice-display.h |  1 +
 5 files changed, 105 insertions(+), 3 deletions(-)

diff --git a/configure b/configure
index cc774b5..84fa2c6 100755
--- a/configure
+++ b/configure
@@ -2657,6 +2657,9 @@ EOF
 spice=yes
 libs_softmmu=$libs_softmmu $spice_libs
 QEMU_CFLAGS=$QEMU_CFLAGS $spice_cflags
+if $pkg_config --atleast-version=0.12.0 spice-protocol /dev/null 21; 
then
+spice_qxl_io_monitors_config_async=yes
+fi
   else
 if test $spice = yes ; then
   feature_not_found spice
@@ -3392,6 +3395,10 @@ if test $spice = yes ; then
   echo CONFIG_SPICE=y  $config_host_mak
 fi
 
+if test $spice_qxl_io_monitors_config_async = yes ; then
+  echo CONFIG_QXL_IO_MONITORS_CONFIG_ASYNC=y  $config_host_mak
+fi
+
 if test $smartcard = yes ; then
   echo CONFIG_SMARTCARD=y  $config_host_mak
 fi
diff --git a/hw/qxl.c b/hw/qxl.c
index c978f5e..d90f9d5 100644
--- a/hw/qxl.c
+++ b/hw/qxl.c
@@ -27,6 +27,11 @@
 
 #include qxl.h
 
+#ifndef CONFIG_QXL_IO_MONITORS_CONFIG_ASYNC
+/* spice-protocol is too old, add missing definitions */
+#define QXL_IO_MONITORS_CONFIG_ASYNC (QXL_IO_FLUSH_RELEASE + 1)
+#endif
+
 /*
  * NOTE: SPICE_RING_PROD_ITEM accesses memory on the pci bar and as
  * such can be changed by the guest, so to avoid a guest trigerrable
@@ -249,6 +254,24 @@ static void qxl_spice_destroy_surfaces(PCIQXLDevice *qxl, 
qxl_async_io async)
 }
 }
 
+static void qxl_spice_monitors_config_async(PCIQXLDevice *qxl)
+{
+trace_qxl_spice_monitors_config(qxl-id);
+/* 0x000b01 == 0.11.1 */
+#if SPICE_SERVER_VERSION = 0x000b01  \
+defined(CONFIG_QXL_IO_MONITORS_CONFIG_ASYNC)
+qxl-guest_monitors_config = qxl-ram-monitors_config;
+spice_qxl_monitors_config_async(qxl-ssd.qxl,
+qxl-ram-monitors_config,
+MEMSLOT_GROUP_GUEST,
+(uintptr_t)qxl_cookie_new(QXL_COOKIE_TYPE_IO,
+  QXL_IO_MONITORS_CONFIG_ASYNC));
+#else
+fprintf(stderr, qxl: too old spice-protocol/spice-server for 
+QXL_IO_MONITORS_CONFIG_ASYNC\n);
+#endif
+}
+
 void qxl_spice_reset_image_cache(PCIQXLDevice *qxl)
 {
 trace_qxl_spice_reset_image_cache(qxl-id);
@@ -538,6 +561,7 @@ static const char *io_port_to_string(uint32_t io_port)
 = QXL_IO_DESTROY_ALL_SURFACES_ASYNC,
 [QXL_IO_FLUSH_SURFACES_ASYNC]   = QXL_IO_FLUSH_SURFACES_ASYNC,
 [QXL_IO_FLUSH_RELEASE]  = QXL_IO_FLUSH_RELEASE,
+[QXL_IO_MONITORS_CONFIG_ASYNC]  = QXL_IO_MONITORS_CONFIG_ASYNC,
 };
 return io_port_to_string[io_port];
 }
@@ -819,6 +843,7 @@ static void interface_async_complete_io(PCIQXLDevice *qxl, 
QXLCookie *cookie)
 case QXL_IO_DESTROY_PRIMARY_ASYNC:
 case QXL_IO_UPDATE_AREA_ASYNC:
 case QXL_IO_FLUSH_SURFACES_ASYNC:
+case QXL_IO_MONITORS_CONFIG_ASYNC:
 break;
 case QXL_IO_CREATE_PRIMARY_ASYNC:
 qxl_create_guest_primary_complete(qxl);
@@ -894,6 +919,8 @@ static void interface_async_complete(QXLInstance *sin, 
uint64_t cookie_token)
 case QXL_COOKIE_TYPE_RENDER_UPDATE_AREA:
 qxl_render_update_area_done(qxl, cookie);
 break;
+case QXL_COOKIE_TYPE_POST_LOAD_MONITORS_CONFIG:
+break;
 default:
 fprintf(stderr, qxl: %s: unexpected cookie type %d\n,
 __func__, cookie-type);
@@ -1314,6 +1341,13 @@ static void ioport_write(void *opaque, 
target_phys_addr_t addr,
 return;
 }
 
+if (d-revision = QXL_REVISION_STABLE_V10 
+io_port = QXL_IO_FLUSH_SURFACES_ASYNC) {
+qxl_set_guest_bug(d, unsupported io %d for revision %d\n,
+io_port, d-revision);
+return;
+}
+
 switch (io_port) {
 case QXL_IO_RESET:
 case QXL_IO_SET_MODE:
@@ -1333,7 +1367,7 @@ static void ioport_write(void *opaque, target_phys_addr_t 
addr,
 io_port, io_port_to_string(io_port));
 /* be nice to buggy guest drivers */
 if (io_port = QXL_IO_UPDATE_AREA_ASYNC 
-io_port = QXL_IO_DESTROY_ALL_SURFACES_ASYNC) {
+io_port  QXL_IO_RANGE_SIZE) {
 qxl_send_events(d, QXL_INTERRUPT_IO_CMD);
 }
 return;
@@ -1361,6 +1395,7 @@ static void ioport_write(void *opaque, target_phys_addr_t 
addr,
 io_port = QXL_IO_DESTROY_ALL_SURFACES;
 goto async_common;
 case 

Re: [Qemu-devel] [PATCH 2/8] fix migration sync

2012-08-21 Thread Orit Wasserman
On 08/18/2012 02:17 PM, Juan Quintela wrote:
 Signed-off-by: Juan Quintela quint...@redhat.com
 ---
  arch_init.c | 1 +
  1 file changed, 1 insertion(+)
 
 diff --git a/arch_init.c b/arch_init.c
 index 9b46bfc..0a9ca85 100644
 --- a/arch_init.c
 +++ b/arch_init.c
 @@ -488,6 +488,7 @@ static int ram_save_setup(QEMUFile *f, void *opaque)
  ram_addr_t addr;
  RAMBlock *block;
 
 +memory_global_sync_dirty_bitmap(get_system_memory());
  bytes_transferred = 0;
  last_block = NULL;
  last_offset = 0;
 
Reviewed-by: Orit Wasserman owass...@redhat.com




[Qemu-devel] [PATCH v11 2/4] qxl: disallow unknown revisions

2012-08-21 Thread Alon Levy
Signed-off-by: Alon Levy al...@redhat.com
---
 hw/qxl.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/hw/qxl.c b/hw/qxl.c
index 6c48eb9..c978f5e 100644
--- a/hw/qxl.c
+++ b/hw/qxl.c
@@ -1797,10 +1797,13 @@ static int qxl_init_common(PCIQXLDevice *qxl)
 io_size = 16;
 break;
 case 3: /* qxl-3 */
-default:
 pci_device_rev = QXL_DEFAULT_REVISION;
 io_size = msb_mask(QXL_IO_RANGE_SIZE * 2 - 1);
 break;
+default:
+error_report(Invalid revision %d for qxl device (max %d),
+ qxl-revision, QXL_DEFAULT_REVISION);
+return -1;
 }
 
 pci_set_byte(config[PCI_REVISION_ID], pci_device_rev);
-- 
1.7.11.2




[Qemu-devel] [PATCH v11 1/4] qxl/update_area_io: guest_bug on invalid parameters

2012-08-21 Thread Alon Levy
Signed-off-by: Alon Levy al...@redhat.com
---
v10-v11
 fixed coding style: space before square bracket. fixed an old instance too. 
(Gerd)

 hw/qxl.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/hw/qxl.c b/hw/qxl.c
index c2dd3b4..6c48eb9 100644
--- a/hw/qxl.c
+++ b/hw/qxl.c
@@ -1385,6 +1385,18 @@ async_common:
 QXLCookie *cookie = NULL;
 QXLRect update = d-ram-update_area;
 
+if (d-ram-update_surface  NUM_SURFACES) {
+qxl_set_guest_bug(d, QXL_IO_UPDATE_AREA: invalid surface id %d\n,
+  d-ram-update_surface);
+return;
+}
+if (update.left = update.right || update.top = update.bottom) {
+qxl_set_guest_bug(d,
+QXL_IO_UPDATE_AREA: invalid area (%ux%u)x(%ux%u)\n,
+update.left, update.top, update.right, update.bottom);
+return;
+}
+
 if (async == QXL_ASYNC) {
 cookie = qxl_cookie_new(QXL_COOKIE_TYPE_IO,
 QXL_IO_UPDATE_AREA_ASYNC);
-- 
1.7.11.2




[Qemu-devel] [PATCH] spice: increase the verbosity of spice section in qemu --help

2012-08-21 Thread Yonit Halperin
Added all spice options to the help string. This can be used by libvirt
to determine which spice related features are supported by qemu.

Signed-off-by: Yonit Halperin yhalp...@redhat.com
---
 qemu-options.hx |   18 +-
 1 files changed, 17 insertions(+), 1 deletions(-)

diff --git a/qemu-options.hx b/qemu-options.hx
index 0727f4f..3872e70 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -835,7 +835,23 @@ Enable SDL.
 ETEXI
 
 DEF(spice, HAS_ARG, QEMU_OPTION_spice,
--spice args   enable spice\n, QEMU_ARCH_ALL)
+-spice [port=port][,tls-port=secured-port][,x509-dir=dir]\n
+   [,x509-key-file=file][,x509-key-password=file]\n
+   [,x509-cert-file=file][,x509-cacert-file=file]\n
+   [,x509-dh-key-file=file][,addr=addr][,ipv4|ipv6]\n
+   [,tls-ciphers=list]\n
+   [,tls-channel=[main|display|cursor|inputs|record|playback]]\n
+   
[,plaintext-channel=[main|display|cursor|inputs|record|playback]]\n
+   [,sasl][,password=secret][,disable-ticketing]\n
+   [,image-compression=[auto_glz|auto_lz|quic|glz|lz|off]]\n
+   [,jpeg-wan-compression=[auto|never|always]]\n
+   [,zlib-glz-wan-compression=[auto|never|always]]\n
+   [,streaming-video=[off|all|filter]][,disable-copy-paste]\n
+   [,agent-mouse=[on|off]][,playback-compression=[on|off]]\n
+   [,seamless-migration=[on|off]]\n
+   enable spice\n
+   at least one of {port, tls-port} is mandatory\n,
+QEMU_ARCH_ALL)
 STEXI
 @item -spice @var{option}[,@var{option}[,...]]
 @findex -spice
-- 
1.7.7.6




Re: [Qemu-devel] [PATCH 3/8] migration: move total_time from ram stats to migration info

2012-08-21 Thread Orit Wasserman
On 08/18/2012 02:17 PM, Juan Quintela wrote:
 Signed-off-by: Juan Quintela quint...@redhat.com
 ---
  hmp.c|  4 ++--
  migration.c  |  6 +++---
  qapi-schema.json | 14 +++---
  qmp-commands.hx  |  6 +++---
  4 files changed, 15 insertions(+), 15 deletions(-)
 
 diff --git a/hmp.c b/hmp.c
 index a9d5675..81c8acb 100644
 --- a/hmp.c
 +++ b/hmp.c
 @@ -149,6 +149,8 @@ void hmp_info_migrate(Monitor *mon)
 
  if (info-has_status) {
  monitor_printf(mon, Migration status: %s\n, info-status);
 +monitor_printf(mon, total time: % PRIu64  milliseconds\n,
 +   info-total_time);
  }
 
  if (info-has_ram) {
 @@ -158,8 +160,6 @@ void hmp_info_migrate(Monitor *mon)
 info-ram-remaining  10);
  monitor_printf(mon, total ram: % PRIu64  kbytes\n,
 info-ram-total  10);
 -monitor_printf(mon, total time: % PRIu64  milliseconds\n,
 -   info-ram-total_time);
  monitor_printf(mon, duplicate: % PRIu64  pages\n,
 info-ram-duplicate);
  monitor_printf(mon, normal: % PRIu64  pages\n,
 diff --git a/migration.c b/migration.c
 index 653a3c1..8e4c508 100644
 --- a/migration.c
 +++ b/migration.c
 @@ -166,14 +166,14 @@ MigrationInfo *qmp_query_migrate(Error **errp)
  case MIG_STATE_ACTIVE:
  info-has_status = true;
  info-status = g_strdup(active);
 +info-total_time = qemu_get_clock_ms(rt_clock)
 +- s-total_time;
 
  info-has_ram = true;
  info-ram = g_malloc0(sizeof(*info-ram));
  info-ram-transferred = ram_bytes_transferred();
  info-ram-remaining = ram_bytes_remaining();
  info-ram-total = ram_bytes_total();
 -info-ram-total_time = qemu_get_clock_ms(rt_clock)
 -- s-total_time;
  info-ram-duplicate = dup_mig_pages_transferred();
  info-ram-normal = norm_mig_pages_transferred();
  info-ram-normal_bytes = norm_mig_bytes_transferred();
 @@ -193,13 +193,13 @@ MigrationInfo *qmp_query_migrate(Error **errp)
 
  info-has_status = true;
  info-status = g_strdup(completed);
 +info-total_time = s-total_time;
 
  info-has_ram = true;
  info-ram = g_malloc0(sizeof(*info-ram));
  info-ram-transferred = ram_bytes_transferred();
  info-ram-remaining = 0;
  info-ram-total = ram_bytes_total();
 -info-ram-total_time = s-total_time;
  info-ram-duplicate = dup_mig_pages_transferred();
  info-ram-normal = norm_mig_pages_transferred();
  info-ram-normal_bytes = norm_mig_bytes_transferred();
 diff --git a/qapi-schema.json b/qapi-schema.json
 index 3d2b2d1..f83cf22 100644
 --- a/qapi-schema.json
 +++ b/qapi-schema.json
 @@ -290,10 +290,6 @@
  #
  # @total: total amount of bytes involved in the migration process
  #
 -# @total-time: total amount of ms since migration started.  If
 -#migration has ended, it returns the total migration
 -#time. (since 1.2)
 -#
  # @duplicate: number of duplicate pages (since 1.2)
  #
  # @normal : number of normal pages (since 1.2)
 @@ -304,8 +300,7 @@
  ##
  { 'type': 'MigrationStats',
'data': {'transferred': 'int', 'remaining': 'int', 'total': 'int' ,
 -   'total-time': 'int', 'duplicate': 'int', 'normal': 'int',
 -   'normal-bytes': 'int' } }
 +   'duplicate': 'int', 'normal': 'int', 'normal-bytes': 'int' } }
 
  ##
  # @XBZRLECacheStats
 @@ -350,12 +345,17 @@
  #migration statistics, only returned if XBZRLE feature is on 
 and
  #status is 'active' or 'completed' (since 1.2)
  #
 +# @total-time: total amount of milliseconds since migration started.
 +#If migration has ended, it returns the total migration
 +#time. (since 1.2)
 +#
  # Since: 0.14.0
  ##
  { 'type': 'MigrationInfo',
'data': {'*status': 'str', '*ram': 'MigrationStats',
 '*disk': 'MigrationStats',
 -   '*xbzrle-cache': 'XBZRLECacheStats'} }
 +   '*xbzrle-cache': 'XBZRLECacheStats',
 +   'total-time': 'int'} }
 
  ##
  # @query-migrate
 diff --git a/qmp-commands.hx b/qmp-commands.hx
 index 2ce4ce6..8671bf3 100644
 --- a/qmp-commands.hx
 +++ b/qmp-commands.hx
 @@ -2239,14 +2239,14 @@ The main json-object contains the following:
 
  - status: migration status (json-string)
   - Possible values: active, completed, failed, cancelled
 +- total-time: total amount of ms since migration started.  If
 +migration has ended, it returns the total migration
 +  time (json-int)
  - ram: only present if status is active, it is a json-object with the
following RAM information (in bytes):
   - transferred: amount transferred (json-int)
   - remaining: amount remaining (json-int)
   - total: total (json-int)
 - - total-time: total amount of ms since migration started.  If
 -  

Re: [Qemu-devel] [PATCH 5/8] migration: print total downtime for final phase of migration

2012-08-21 Thread Orit Wasserman
On 08/18/2012 02:17 PM, Juan Quintela wrote:
 Signed-off-by: Juan Quintela quint...@redhat.com
 ---
  hmp.c| 4 
  migration.c  | 6 +-
  migration.h  | 1 +
  qapi-schema.json | 7 ++-
  qmp-commands.hx  | 3 +++
  5 files changed, 19 insertions(+), 2 deletions(-)
 
 diff --git a/hmp.c b/hmp.c
 index 81c8acb..8f24d9d 100644
 --- a/hmp.c
 +++ b/hmp.c
 @@ -151,6 +151,10 @@ void hmp_info_migrate(Monitor *mon)
  monitor_printf(mon, Migration status: %s\n, info-status);
  monitor_printf(mon, total time: % PRIu64  milliseconds\n,
 info-total_time);
 +if (info-has_downtime) {
 +monitor_printf(mon, downtime: % PRIu64  milliseconds\n,
 +   info-downtime);
 +}
  }
 
  if (info-has_ram) {
 diff --git a/migration.c b/migration.c
 index 159728d..49cd336 100644
 --- a/migration.c
 +++ b/migration.c
 @@ -194,6 +194,8 @@ MigrationInfo *qmp_query_migrate(Error **errp)
  info-has_status = true;
  info-status = g_strdup(completed);
  info-total_time = s-total_time;
 +info-has_downtime = true;
 +info-downtime = s-downtime;
 
  info-has_ram = true;
  info-ram = g_malloc0(sizeof(*info-ram));
 @@ -326,9 +328,10 @@ static void migrate_fd_put_ready(void *opaque)
  migrate_fd_error(s);
  } else if (ret == 1) {
  int old_vm_running = runstate_is_running();
 -int64_t end_time;
 +int64_t start_time, end_time;
 
  DPRINTF(done iterating\n);
 +start_time = qemu_get_clock_ms(rt_clock);
  qemu_system_wakeup_request(QEMU_WAKEUP_REASON_OTHER);
  vm_stop_force_state(RUN_STATE_FINISH_MIGRATE);
 
 @@ -339,6 +342,7 @@ static void migrate_fd_put_ready(void *opaque)
  }
  end_time = qemu_get_clock_ms(rt_clock);
  s-total_time = end_time - s-total_time;
 +s-downtime = end_time - start_time;
  if (s-state != MIG_STATE_COMPLETED) {
  if (old_vm_running) {
  vm_start();
 diff --git a/migration.h b/migration.h
 index a9852fc..3462917 100644
 --- a/migration.h
 +++ b/migration.h
 @@ -40,6 +40,7 @@ struct MigrationState
  void *opaque;
  MigrationParams params;
  int64_t total_time;
 +int64_t downtime;
  bool enabled_capabilities[MIGRATION_CAPABILITY_MAX];
  int64_t xbzrle_cache_size;
  };
 diff --git a/qapi-schema.json b/qapi-schema.json
 index f83cf22..29f601a 100644
 --- a/qapi-schema.json
 +++ b/qapi-schema.json
 @@ -349,13 +349,18 @@
  #If migration has ended, it returns the total migration
  #time. (since 1.2)
  #
 +# @downtime: #optional only present when migration finishes correctly
 +#total downtime in milliseconds for the guest.
 +#(since 1.2)
will it make it to 1.2 ? if not than 1.3 
 +#
  # Since: 0.14.0
  ##
  { 'type': 'MigrationInfo',
'data': {'*status': 'str', '*ram': 'MigrationStats',
 '*disk': 'MigrationStats',
 '*xbzrle-cache': 'XBZRLECacheStats',
 -   'total-time': 'int'} }
 +   'total-time': 'int',
 +   '*downtime': 'int'} }
 
  ##
  # @query-migrate
 diff --git a/qmp-commands.hx b/qmp-commands.hx
 index 8671bf3..b5ca99f 100644
 --- a/qmp-commands.hx
 +++ b/qmp-commands.hx
 @@ -2242,6 +2242,8 @@ The main json-object contains the following:
  - total-time: total amount of ms since migration started.  If
  migration has ended, it returns the total migration
time (json-int)
 +- downtime: only present when migration has finished correctly
 +total amount in ms for downtime that happened (json-int)
  - ram: only present if status is active, it is a json-object with the
following RAM information (in bytes):
   - transferred: amount transferred (json-int)
 @@ -2279,6 +2281,7 @@ Examples:
remaining:123,
total:246,
total-time:12345,
 +  expected-downtime:12345,
duplicate:123,
normal:123,
normal-bytes:123456
 




Re: [Qemu-devel] [PATCH 6/8] migration: rename expected_time to expected_downtime

2012-08-21 Thread Orit Wasserman
On 08/18/2012 02:17 PM, Juan Quintela wrote:
 Signed-off-by: Juan Quintela quint...@redhat.com
 ---
  arch_init.c | 17 +
  1 file changed, 9 insertions(+), 8 deletions(-)
 
 diff --git a/arch_init.c b/arch_init.c
 index 0a9ca85..7eb6e86 100644
 --- a/arch_init.c
 +++ b/arch_init.c
 @@ -538,7 +538,7 @@ static int ram_save_iterate(QEMUFile *f, void *opaque)
  double bwidth = 0;
  int ret;
  int i;
 -uint64_t expected_time;
 +uint64_t expected_downtime;
 
  bytes_transferred_last = bytes_transferred;
  bwidth = qemu_get_clock_ns(rt_clock);
 @@ -577,24 +577,25 @@ static int ram_save_iterate(QEMUFile *f, void *opaque)
  bwidth = qemu_get_clock_ns(rt_clock) - bwidth;
  bwidth = (bytes_transferred - bytes_transferred_last) / bwidth;
 
 -/* if we haven't transferred anything this round, force expected_time to 
 a
 - * a very high value, but without crashing */
 +/* if we haven't transferred anything this round, force
 + * expected_downtime to a very high value, but without
 + * crashing */
  if (bwidth == 0) {
  bwidth = 0.01;
  }
 
  qemu_put_be64(f, RAM_SAVE_FLAG_EOS);
 
 -expected_time = ram_save_remaining() * TARGET_PAGE_SIZE / bwidth;
 +expected_downtime = ram_save_remaining() * TARGET_PAGE_SIZE / bwidth;
 
  DPRINTF(ram_save_live: expected( PRIu64 ) = max( PRIu64 )?\n,
 -expected_time, migrate_max_downtime());
 +expected_downtime, migrate_max_downtime());
 
 -if (expected_time = migrate_max_downtime()) {
 +if (expected_downtime = migrate_max_downtime()) {
  memory_global_sync_dirty_bitmap(get_system_memory());
 -expected_time = ram_save_remaining() * TARGET_PAGE_SIZE / bwidth;
 +expected_downtime = ram_save_remaining() * TARGET_PAGE_SIZE / bwidth;
 
 -return expected_time = migrate_max_downtime();
 +return expected_downtime = migrate_max_downtime();
  }
  return 0;
  }
 
Reviewed-by: Orit Wasserman owass...@redhat.com




Re: [Qemu-devel] [PATCH 7/8] migration: export migrate_get_current()

2012-08-21 Thread Orit Wasserman
On 08/18/2012 02:17 PM, Juan Quintela wrote:
 Signed-off-by: Juan Quintela quint...@redhat.com
 ---
  migration.c | 2 +-
  migration.h | 1 +
  2 files changed, 2 insertions(+), 1 deletion(-)
 
 diff --git a/migration.c b/migration.c
 index 49cd336..186bcf2 100644
 --- a/migration.c
 +++ b/migration.c
 @@ -53,7 +53,7 @@ static NotifierList migration_state_notifiers =
 migrations at once.  For now we don't need to add
 dynamic creation of migration */
 
 -static MigrationState *migrate_get_current(void)
 +MigrationState *migrate_get_current(void)
  {
  static MigrationState current_migration = {
  .state = MIG_STATE_SETUP,
 diff --git a/migration.h b/migration.h
 index 3462917..dabc333 100644
 --- a/migration.h
 +++ b/migration.h
 @@ -81,6 +81,7 @@ void remove_migration_state_change_notifier(Notifier 
 *notify);
  bool migration_is_active(MigrationState *);
  bool migration_has_finished(MigrationState *);
  bool migration_has_failed(MigrationState *);
 +MigrationState *migrate_get_current(void);
 
  uint64_t ram_bytes_remaining(void);
  uint64_t ram_bytes_transferred(void);
 
Reviewed-by: Orit Wasserman owass...@redhat.com




[Qemu-devel] [PATCH v11 3/4] qxl: add QXL_IO_MONITORS_CONFIG_ASYNC

2012-08-21 Thread Alon Levy
Revision bumped to 4 for new IO support, enabled for spice-server =
0.11.1. New io enabled iff revision is 4. Revision can be set to 4, and
defaults to 4, iff spice-server = 0.11.1  spice-protocol =
0.12.0.

This io calls the corresponding new spice api
spice_qxl_monitors_config_async to let spice-server read a new guest set
monitors config and notify the client.

On migration reissue spice_qxl_monitors_config_async.

RHBZ: 770842

Signed-off-by: Alon Levy al...@redhat.com
---
 configure  |  7 
 hw/qxl.c   | 93 +++---
 hw/qxl.h   |  8 +
 trace-events   |  1 +
 ui/spice-display.h |  1 +
 5 files changed, 106 insertions(+), 4 deletions(-)

diff --git a/configure b/configure
index cc774b5..84fa2c6 100755
--- a/configure
+++ b/configure
@@ -2657,6 +2657,9 @@ EOF
 spice=yes
 libs_softmmu=$libs_softmmu $spice_libs
 QEMU_CFLAGS=$QEMU_CFLAGS $spice_cflags
+if $pkg_config --atleast-version=0.12.0 spice-protocol /dev/null 21; 
then
+spice_qxl_io_monitors_config_async=yes
+fi
   else
 if test $spice = yes ; then
   feature_not_found spice
@@ -3392,6 +3395,10 @@ if test $spice = yes ; then
   echo CONFIG_SPICE=y  $config_host_mak
 fi
 
+if test $spice_qxl_io_monitors_config_async = yes ; then
+  echo CONFIG_QXL_IO_MONITORS_CONFIG_ASYNC=y  $config_host_mak
+fi
+
 if test $smartcard = yes ; then
   echo CONFIG_SMARTCARD=y  $config_host_mak
 fi
diff --git a/hw/qxl.c b/hw/qxl.c
index c978f5e..acf4c0e 100644
--- a/hw/qxl.c
+++ b/hw/qxl.c
@@ -27,6 +27,11 @@
 
 #include qxl.h
 
+#ifndef CONFIG_QXL_IO_MONITORS_CONFIG_ASYNC
+/* spice-protocol is too old, add missing definitions */
+#define QXL_IO_MONITORS_CONFIG_ASYNC (QXL_IO_FLUSH_RELEASE + 1)
+#endif
+
 /*
  * NOTE: SPICE_RING_PROD_ITEM accesses memory on the pci bar and as
  * such can be changed by the guest, so to avoid a guest trigerrable
@@ -249,6 +254,24 @@ static void qxl_spice_destroy_surfaces(PCIQXLDevice *qxl, 
qxl_async_io async)
 }
 }
 
+static void qxl_spice_monitors_config_async(PCIQXLDevice *qxl)
+{
+trace_qxl_spice_monitors_config(qxl-id);
+/* 0x000b01 == 0.11.1 */
+#if SPICE_SERVER_VERSION = 0x000b01  \
+defined(CONFIG_QXL_IO_MONITORS_CONFIG_ASYNC)
+qxl-guest_monitors_config = qxl-ram-monitors_config;
+spice_qxl_monitors_config_async(qxl-ssd.qxl,
+qxl-ram-monitors_config,
+MEMSLOT_GROUP_GUEST,
+(uintptr_t)qxl_cookie_new(QXL_COOKIE_TYPE_IO,
+  QXL_IO_MONITORS_CONFIG_ASYNC));
+#else
+fprintf(stderr, qxl: too old spice-protocol/spice-server for 
+QXL_IO_MONITORS_CONFIG_ASYNC\n);
+#endif
+}
+
 void qxl_spice_reset_image_cache(PCIQXLDevice *qxl)
 {
 trace_qxl_spice_reset_image_cache(qxl-id);
@@ -538,6 +561,7 @@ static const char *io_port_to_string(uint32_t io_port)
 = QXL_IO_DESTROY_ALL_SURFACES_ASYNC,
 [QXL_IO_FLUSH_SURFACES_ASYNC]   = QXL_IO_FLUSH_SURFACES_ASYNC,
 [QXL_IO_FLUSH_RELEASE]  = QXL_IO_FLUSH_RELEASE,
+[QXL_IO_MONITORS_CONFIG_ASYNC]  = QXL_IO_MONITORS_CONFIG_ASYNC,
 };
 return io_port_to_string[io_port];
 }
@@ -819,6 +843,7 @@ static void interface_async_complete_io(PCIQXLDevice *qxl, 
QXLCookie *cookie)
 case QXL_IO_DESTROY_PRIMARY_ASYNC:
 case QXL_IO_UPDATE_AREA_ASYNC:
 case QXL_IO_FLUSH_SURFACES_ASYNC:
+case QXL_IO_MONITORS_CONFIG_ASYNC:
 break;
 case QXL_IO_CREATE_PRIMARY_ASYNC:
 qxl_create_guest_primary_complete(qxl);
@@ -894,6 +919,8 @@ static void interface_async_complete(QXLInstance *sin, 
uint64_t cookie_token)
 case QXL_COOKIE_TYPE_RENDER_UPDATE_AREA:
 qxl_render_update_area_done(qxl, cookie);
 break;
+case QXL_COOKIE_TYPE_POST_LOAD_MONITORS_CONFIG:
+break;
 default:
 fprintf(stderr, qxl: %s: unexpected cookie type %d\n,
 __func__, cookie-type);
@@ -1314,6 +1341,13 @@ static void ioport_write(void *opaque, 
target_phys_addr_t addr,
 return;
 }
 
+if (d-revision = QXL_REVISION_STABLE_V10 
+io_port = QXL_IO_FLUSH_SURFACES_ASYNC) {
+qxl_set_guest_bug(d, unsupported io %d for revision %d\n,
+io_port, d-revision);
+return;
+}
+
 switch (io_port) {
 case QXL_IO_RESET:
 case QXL_IO_SET_MODE:
@@ -1333,7 +1367,7 @@ static void ioport_write(void *opaque, target_phys_addr_t 
addr,
 io_port, io_port_to_string(io_port));
 /* be nice to buggy guest drivers */
 if (io_port = QXL_IO_UPDATE_AREA_ASYNC 
-io_port = QXL_IO_DESTROY_ALL_SURFACES_ASYNC) {
+io_port  QXL_IO_RANGE_SIZE) {
 qxl_send_events(d, QXL_INTERRUPT_IO_CMD);
 }
 return;
@@ -1361,6 +1395,7 @@ static void ioport_write(void *opaque, target_phys_addr_t 
addr,
 io_port = QXL_IO_DESTROY_ALL_SURFACES;
 goto async_common;
 case 

Re: [Qemu-devel] [PATCH v11 3/4] qxl: add QXL_IO_MONITORS_CONFIG_ASYNC

2012-08-21 Thread Gerd Hoffmann
On 08/21/12 12:51, Alon Levy wrote:
 Revision bumped to 4 for new IO support, enabled for spice-server =
 0.11.1. New io enabled iff revision is 4. Revision can be set to 4, and
 defaults to 4, iff spice-server = 0.11.1  spice-protocol =
 0.12.0.

All four patches added to spice patch queue.

thanks,
  Gerd



[Qemu-devel] [PATCH v11 4/4] configure: print spice-protocol and spice-server versions

2012-08-21 Thread Alon Levy
Signed-off-by: Alon Levy al...@redhat.com
---
 configure | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index 84fa2c6..02c06aa 100755
--- a/configure
+++ b/configure
@@ -2657,6 +2657,8 @@ EOF
 spice=yes
 libs_softmmu=$libs_softmmu $spice_libs
 QEMU_CFLAGS=$QEMU_CFLAGS $spice_cflags
+spice_protocol_version=$($pkg_config --modversion spice-protocol)
+spice_server_version=$($pkg_config --modversion spice-server)
 if $pkg_config --atleast-version=0.12.0 spice-protocol /dev/null 21; 
then
 spice_qxl_io_monitors_config_async=yes
 fi
@@ -3114,7 +3116,7 @@ echo libcap-ng support $cap_ng
 echo vhost-net support $vhost_net
 echo Trace backend $trace_backend
 echo Trace output file $trace_file-pid
-echo spice support $spice
+echo spice support $spice ($spice_protocol_version/$spice_server_version)
 echo rbd support   $rbd
 echo xfsctl support$xfs
 echo nss used  $smartcard_nss
-- 
1.7.11.2




Re: [Qemu-devel] [PATCH] spice: increase the verbosity of spice section in qemu --help

2012-08-21 Thread Gerd Hoffmann
On 08/21/12 12:54, Yonit Halperin wrote:
 Added all spice options to the help string. This can be used by libvirt
 to determine which spice related features are supported by qemu.

Patch added to spice patch queue.

thanks,
  Gerd



Re: [Qemu-devel] memory: could we add extra input param for memory_region_init_io()?

2012-08-21 Thread liu ping fan
On Tue, Aug 21, 2012 at 6:13 PM, Avi Kivity a...@redhat.com wrote:
 On 08/21/2012 12:25 PM, liu ping fan wrote:
 On Tue, Aug 21, 2012 at 4:57 PM, Avi Kivity a...@redhat.com wrote:
 On 08/21/2012 07:48 AM, liu ping fan wrote:
 On Sun, Aug 19, 2012 at 7:36 PM, Avi Kivity a...@redhat.com wrote:
 On 08/19/2012 02:23 PM, Peter Maydell wrote:
 On 19 August 2012 11:12, Avi Kivity a...@redhat.com wrote:
 On 08/17/2012 10:41 AM, liu ping fan wrote:
 And something like omap_mpu_timer_init() in file hw/omap1.c , the
 opaque(omap_mpu_timer_s) is got from g_malloc0, which makes things
 even harder to handle.  And the DO_CAST can not work for such issue.

 IMO omap_mpu_timer_s should be a DeviceState.  Peter?

 Ideally, yes, but qemu is full of devices that haven't yet made the leap
 to QOM.

 omap1 is particularly tricky because I don't actually have any test 
 images
 for it, so refactoring it is a leap in the dark. [I've tried asking on 
 this list
 if anybody had test images a couple of times without success.]

 Okay.  Most of the options in this thread don't involve wholesale
 conversion of the opaque parameter in memory_region_init_io() to type
 Object *, so it's not necessary to convert everything.

 But I think if the mr belongs to mem address space, it can not avoid
 object_ref(Object *opaque) in mmio-dispatch code. ( If we use extra
 flag to indicate whether the opaque is Object or not, then we lose the
 meaning to transfer opaque to Object type, and maybe
 memory_region_set_object() is a better choice).

 I'm not sure I understand.  What do you mean by ability to transfer
 opaque to Object type?

 Maybe I misunderstand your meaning of Okay.  Most of the options in
 this thread don't involve wholesale ..., so it's not necessary to
 convert everything
 I think you mean that omap_mpu_timer_s need NOT to convert.

 That is what I meant.

 But as
 it will also take the code path which has object_ref(Object*), so it
 has to convert, otherwise the code will corrupt.
 That is what I want to express.

 Option 2, for example, had MemoryRegionOps::object(MemoryRegion *) which
 can be used to convert the opaque to an Object, or return NULL.  With
 that option, there would be no corruption:

If we did not pass extra flag to indicate whether opaque is Object or
not, we can not implement MemoryRegionOps::object().  Because we lack
of something like try,catch, and object_dynamic_cast() can not work.
So besides memory_region_init_io(), we need extra interface to pass that flag?

   qemu_mutex_lock(mem_map_lock);
   MemoryRegionSection mrs = walk(phys_map);
   Object *object = mrs.mr-ops-object(mrs.mr);
   if (object) {
   object_ref(object);
   }
   qemu_mutex_unlock(mem_map_unlock);

 So there is no memory corruption.  However, as I point out below, we
 also lack the reference count.  Maybe we could do something like:

I think the hotplug issue is only for limited type of bus. And
fortunately, for pci, they have already adopt Object.
So for other SoC, maybe we can ignore this issue at current step

   qemu_mutex_lock(mem_map_lock);
   MemoryRegionSection mrs = walk(phys_map);
   Object *object = mrs.mr-ops-object(mrs.mr);
   if (object) {
   object_ref(object);
   } else {
   goto retry_with_qemu_lock_held;
   }
   qemu_mutex_unlock(mem_map_unlock);

 But that's very inelegant.


 Agree.  The best example is device assignment, where BARs will need to
 turn into Objects.  It means that an assigned device can disappear while
 one of its BARs remain, so the code will have to handle this case.

 How about the initialization of BAR inc ref of assigned device; and
 finalization of BAR dec it?

 If we can avoid a cycle.  Won't the device need to hold refs to the BAR?

I will check the code, but I has thought BAR is implemented by
assigned device?  Will study closely.

Thanks and regards,
pingfan

 Unfortunately, requiring a 1:1 opaque:Object relationship means huge
 churn in the code.  But I don't think it can be avoided, even with
 memory_region_set_object().

 Yeah, and I am studying the different case to see how to resolve and
 make plans about the huge conversion.

 Ok.  One one hand, I think the conversion is unavoidable, and is also
 beneficial: I never liked opaques.

 On the other hand, those conversions are very tedious, introduce
 regressions, and delay the result.

 Anthony, any insight on this?

 --
 error compiling committee.c: too many arguments to function



Re: [Qemu-devel] [PATCH] qemu-ga: report success-response field in guest-info

2012-08-21 Thread Paolo Bonzini
Il 21/08/2012 12:25, Michal Privoznik ha scritto:
 +bool qmp_command_reports_success(const char *name) {
 +QmpCommand *cmd;
 +
 +QTAILQ_FOREACH(cmd, qmp_commands, node) {
 +if (strcmp(cmd-name, name) == 0) {
 +return cmd-options ^ QCO_NO_SUCCESS_RESP;

Clever... but please use (a  b) == 0 instead...

Paolo

 +}
 +}
 +
 +return true;
 +}
 +




[Qemu-devel] [PATCH v2] qemu-ga: report success-response field in guest-info

2012-08-21 Thread Michal Privoznik
This is a useful hint for users (or libvirt) whether a command returns
anything success and hence wait for reply or not.
---
diff to v1:
-changed condition in qmp_command_reports_success per Paolo's advice

 qapi-schema-guest.json |6 +-
 qapi/qmp-core.h|1 +
 qapi/qmp-registry.c|   12 
 qga/commands.c |1 +
 4 files changed, 19 insertions(+), 1 deletions(-)

diff --git a/qapi-schema-guest.json b/qapi-schema-guest.json
index d955cf1..2cd5957 100644
--- a/qapi-schema-guest.json
+++ b/qapi-schema-guest.json
@@ -91,10 +91,14 @@
 #
 # @enabled: whether command is currently enabled by guest admin
 #
+# @success-response: whether command report success response or not.
+#See 'uest-shutdown' command for more detailed info.
+#
 # Since 1.1.0
 ##
 { 'type': 'GuestAgentCommandInfo',
-  'data': { 'name': 'str', 'enabled': 'bool' } }
+  'data': { 'name': 'str', 'enabled': 'bool',
+'success-response': 'bool'} }
 
 ##
 # @GuestAgentInfo
diff --git a/qapi/qmp-core.h b/qapi/qmp-core.h
index 00446cf..271c3f2 100644
--- a/qapi/qmp-core.h
+++ b/qapi/qmp-core.h
@@ -48,6 +48,7 @@ QObject *qmp_dispatch(QObject *request);
 void qmp_disable_command(const char *name);
 void qmp_enable_command(const char *name);
 bool qmp_command_is_enabled(const char *name);
+bool qmp_command_reports_success(const char *name);
 char **qmp_get_command_list(void);
 QObject *qmp_build_error_object(Error *errp);
 
diff --git a/qapi/qmp-registry.c b/qapi/qmp-registry.c
index 5414613..3f7303c 100644
--- a/qapi/qmp-registry.c
+++ b/qapi/qmp-registry.c
@@ -77,6 +77,18 @@ bool qmp_command_is_enabled(const char *name)
 return false;
 }
 
+bool qmp_command_reports_success(const char *name) {
+QmpCommand *cmd;
+
+QTAILQ_FOREACH(cmd, qmp_commands, node) {
+if (strcmp(cmd-name, name) == 0) {
+return (cmd-options  QCO_NO_SUCCESS_RESP) == 0;
+}
+}
+
+return true;
+}
+
 char **qmp_get_command_list(void)
 {
 QmpCommand *cmd;
diff --git a/qga/commands.c b/qga/commands.c
index 46b0b08..9811221 100644
--- a/qga/commands.c
+++ b/qga/commands.c
@@ -63,6 +63,7 @@ struct GuestAgentInfo *qmp_guest_info(Error **err)
 cmd_info = g_malloc0(sizeof(GuestAgentCommandInfo));
 cmd_info-name = strdup(*cmd_list);
 cmd_info-enabled = qmp_command_is_enabled(cmd_info-name);
+cmd_info-success_response = 
qmp_command_reports_success(cmd_info-name);
 
 cmd_info_list = g_malloc0(sizeof(GuestAgentCommandInfoList));
 cmd_info_list-value = cmd_info;
-- 
1.7.8.6




Re: [Qemu-devel] [PATCH v4] linux-user: fix emulation of getdents

2012-08-21 Thread Peter Maydell
On 20 August 2012 23:13, Dmitry V. Levin l...@altlinux.org wrote:
 In case when TARGET_ABI_BITS == 32  HOST_LONG_BITS == 64, the last
 byte of the target dirent structure (aka d_type byte) was never copied
 from the host dirent structure, thus breaking everything that relies
 on valid d_type value, e.g. glob(3).

 Signed-off-by: Dmitry V. Levin l...@altlinux.org

Reviewed-by: Peter Maydell peter.mayd...@linaro.org

(though not tested, since the 32 bit target I care about (ARM) uses
getdents64 rather than getdents.)

-- PMM



[Qemu-devel] For 1.2: Re: [PATCH v2] qemu-ga: report success-response field in guest-info

2012-08-21 Thread Eric Blake
On 08/21/2012 06:03 AM, Michal Privoznik wrote:
 This is a useful hint for users (or libvirt) whether a command returns
 anything success and hence wait for reply or not.
 ---
 diff to v1:
 -changed condition in qmp_command_reports_success per Paolo's advice
 
  qapi-schema-guest.json |6 +-
  qapi/qmp-core.h|1 +
  qapi/qmp-registry.c|   12 
  qga/commands.c |1 +
  4 files changed, 19 insertions(+), 1 deletions(-)

Adding 'For 1.2', on the grounds that we changed semantics in 1.2 (1.1
didn't have any commands with success-response marking to begin with),
and therefore it is a usability bug if we don't fix it in time for this
release.

 
 diff --git a/qapi-schema-guest.json b/qapi-schema-guest.json
 index d955cf1..2cd5957 100644
 --- a/qapi-schema-guest.json
 +++ b/qapi-schema-guest.json
 @@ -91,10 +91,14 @@
  #
  # @enabled: whether command is currently enabled by guest admin
  #
 +# @success-response: whether command report success response or not.
 +#See 'uest-shutdown' command for more detailed info.

s/uest/guest/

-- 
Eric Blake   ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature


Re: [Qemu-devel] For 1.2: Re: [PATCH v2] qemu-ga: report success-response field in guest-info

2012-08-21 Thread Eric Blake
On 08/21/2012 06:17 AM, Eric Blake wrote:
 On 08/21/2012 06:03 AM, Michal Privoznik wrote:
 This is a useful hint for users (or libvirt) whether a command returns
 anything success and hence wait for reply or not.

 +++ b/qapi-schema-guest.json
 @@ -91,10 +91,14 @@
  #
  # @enabled: whether command is currently enabled by guest admin
  #
 +# @success-response: whether command report success response or not.

This sentence is also awkward.  I suggest something like:

true unless the command does not respond on success

 +#See 'uest-shutdown' command for more detailed info.
 
 s/uest/guest/
 

-- 
Eric Blake   ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature


Re: [Qemu-devel] [PATCH] spice: increase the verbosity of spice section in qemu --help

2012-08-21 Thread Eric Blake
On 08/21/2012 04:54 AM, Yonit Halperin wrote:
 Added all spice options to the help string. This can be used by libvirt
 to determine which spice related features are supported by qemu.

For older released, this is true; but for future versions of qemu,
libvirt would much rather learn this information from QMP commands than
from scraping -help output.  Can we get at all of this information from QMP?

-- 
Eric Blake   ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature


Re: [Qemu-devel] [PATCH V2 0/6] virtio-trace: Support virtio-trace

2012-08-21 Thread Masami Hiramatsu
(2012/08/21 14:16), Amit Shah wrote:
 On (Thu) 09 Aug 2012 [21:30:29], Yoshihiro YUNOMAE wrote:
 Hi All,

 The following patch set provides a low-overhead system for collecting kernel
 tracing data of guests by a host in a virtualization environment.
 
 ACK this series.

Thank you!

 I ran it through the virtio-serial test suite, and there's no
 regression in existing functionality.
 
 I encourage you to check out the virtio-serial test suite[1] as well
 as the virtio-serial unit tests in the autotest[2] code, and
 contribute to them to add tests for the new functionality you've
 added.

Ah, OK we'll look into them for adding some tests for
splice support :)

 
 [1]
 http://fedorapeople.org/cgit/amitshah/public_git/test-virtserial.git/
 
 [2]
 https://github.com/autotest/autotest/blob/e91cd67b845b291622c8d079a8289c4b0cb1e6ae/client/tests/kvm/tests/virtio_console.py
 
 

Thank you again,

-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com





[Qemu-devel] [PATCH for-1.2 v3] qemu-ga: report success-response field in guest-info

2012-08-21 Thread Michal Privoznik
This is a useful hint for users (or libvirt) whether a command returns
anything success and hence wait for reply or not.
---
diff to v2:
-fixed typo and field description

diff to v1:
-changed condition in qmp_command_reports_success per Paolo's advice

 qapi-schema-guest.json |6 +-
 qapi/qmp-core.h|1 +
 qapi/qmp-registry.c|   12 
 qga/commands.c |1 +
 4 files changed, 19 insertions(+), 1 deletions(-)

diff --git a/qapi-schema-guest.json b/qapi-schema-guest.json
index d955cf1..60872e5 100644
--- a/qapi-schema-guest.json
+++ b/qapi-schema-guest.json
@@ -91,10 +91,14 @@
 #
 # @enabled: whether command is currently enabled by guest admin
 #
+# @success-response: true unless the command does not respond on success
+#See 'guest-shutdown' command for more detailed info.
+#
 # Since 1.1.0
 ##
 { 'type': 'GuestAgentCommandInfo',
-  'data': { 'name': 'str', 'enabled': 'bool' } }
+  'data': { 'name': 'str', 'enabled': 'bool',
+'success-response': 'bool'} }
 
 ##
 # @GuestAgentInfo
diff --git a/qapi/qmp-core.h b/qapi/qmp-core.h
index 00446cf..271c3f2 100644
--- a/qapi/qmp-core.h
+++ b/qapi/qmp-core.h
@@ -48,6 +48,7 @@ QObject *qmp_dispatch(QObject *request);
 void qmp_disable_command(const char *name);
 void qmp_enable_command(const char *name);
 bool qmp_command_is_enabled(const char *name);
+bool qmp_command_reports_success(const char *name);
 char **qmp_get_command_list(void);
 QObject *qmp_build_error_object(Error *errp);
 
diff --git a/qapi/qmp-registry.c b/qapi/qmp-registry.c
index 5414613..3f7303c 100644
--- a/qapi/qmp-registry.c
+++ b/qapi/qmp-registry.c
@@ -77,6 +77,18 @@ bool qmp_command_is_enabled(const char *name)
 return false;
 }
 
+bool qmp_command_reports_success(const char *name) {
+QmpCommand *cmd;
+
+QTAILQ_FOREACH(cmd, qmp_commands, node) {
+if (strcmp(cmd-name, name) == 0) {
+return (cmd-options  QCO_NO_SUCCESS_RESP) == 0;
+}
+}
+
+return true;
+}
+
 char **qmp_get_command_list(void)
 {
 QmpCommand *cmd;
diff --git a/qga/commands.c b/qga/commands.c
index 46b0b08..9811221 100644
--- a/qga/commands.c
+++ b/qga/commands.c
@@ -63,6 +63,7 @@ struct GuestAgentInfo *qmp_guest_info(Error **err)
 cmd_info = g_malloc0(sizeof(GuestAgentCommandInfo));
 cmd_info-name = strdup(*cmd_list);
 cmd_info-enabled = qmp_command_is_enabled(cmd_info-name);
+cmd_info-success_response = 
qmp_command_reports_success(cmd_info-name);
 
 cmd_info_list = g_malloc0(sizeof(GuestAgentCommandInfoList));
 cmd_info_list-value = cmd_info;
-- 
1.7.8.6




Re: [Qemu-devel] memory: could we add extra input param for memory_region_init_io()?

2012-08-21 Thread Avi Kivity
On 08/21/2012 02:18 PM, liu ping fan wrote:

 But as
 it will also take the code path which has object_ref(Object*), so it
 has to convert, otherwise the code will corrupt.
 That is what I want to express.

 Option 2, for example, had MemoryRegionOps::object(MemoryRegion *) which
 can be used to convert the opaque to an Object, or return NULL.  With
 that option, there would be no corruption:

 If we did not pass extra flag to indicate whether opaque is Object or
 not, we can not implement MemoryRegionOps::object().  Because we lack
 of something like try,catch, and object_dynamic_cast() can not work.
 So besides memory_region_init_io(), we need extra interface to pass that flag?

The interface is MemoryRegionOps::object().

If the user does not implement it, then the opaque cannot be converted
into an object.  If the user did implement it, then the function
specifies how to convert it.

For example:


static Object *e1000_mmio_object(void *opaque)
{
E1000State *s = opaque;

return s-dev.qdev.parent_obj;
}

static const MemoryRegionOps e1000_mmio_ops = {
.read = e1000_mmio_read,
.write = e1000_mmio_write,
.endianness = DEVICE_LITTLE_ENDIAN,
.object = e1000_mmio_object,
.impl = {
.min_access_size = 4,
.max_access_size = 4,
},
};

   qemu_mutex_lock(mem_map_lock);
   MemoryRegionSection mrs = walk(phys_map);
   Object *object = mrs.mr-ops-object(mrs.mr);
   if (object) {
   object_ref(object);
   }
   qemu_mutex_unlock(mem_map_unlock);


This should read:


Object *object = NULL;
if (mrs.mr-ops-object) {
object = mrs.mr-ops-object(mrs.mr);
}


 So there is no memory corruption.  However, as I point out below, we
 also lack the reference count.  Maybe we could do something like:

 I think the hotplug issue is only for limited type of bus. And
 fortunately, for pci, they have already adopt Object.
 So for other SoC, maybe we can ignore this issue at current step

We still have to take the big qemu lock somehow.

 If we can avoid a cycle.  Won't the device need to hold refs to the BAR?
 
 I will check the code, but I has thought BAR is implemented by
 assigned device?  

Yes.


-- 
error compiling committee.c: too many arguments to function



Re: [Qemu-devel] [PATCH v11 3/4] qxl: add QXL_IO_MONITORS_CONFIG_ASYNC

2012-08-21 Thread Gerd Hoffmann
On 08/21/12 13:06, Gerd Hoffmann wrote:
 On 08/21/12 12:51, Alon Levy wrote:
 Revision bumped to 4 for new IO support, enabled for spice-server =
 0.11.1. New io enabled iff revision is 4. Revision can be set to 4, and
 defaults to 4, iff spice-server = 0.11.1  spice-protocol =
 0.12.0.
 
 All four patches added to spice patch queue.

Spoke too soon, it fails the build with old spice-server:

  CCi386-softmmu/hw/i386/../qxl.o
/var/lib/buildbot/slaves/spunk/ubuntu-default/build/hw/i386/../qxl.c: In
function ‘qxl_post_load’:
/var/lib/buildbot/slaves/spunk/ubuntu-default/build/hw/i386/../qxl.c:2055:13:
warning: implicit declaration of function
‘spice_qxl_monitors_config_async’ [-Wimplicit-function-declaration]
/var/lib/buildbot/slaves/spunk/ubuntu-default/build/hw/i386/../qxl.c:2055:13:
warning: nested extern declaration of ‘spice_qxl_monitors_config_async’
[-Wnested-externs]
  CCi386-softmmu/hw/i386/../qxl-logger.o
[ ... ]
  LINK  i386-softmmu/qemu-system-i386
hw/i386/../qxl.o: In function `qxl_post_load':
qxl.c:(.text+0x3505): undefined reference to
`spice_qxl_monitors_config_async'
collect2: ld returned 1 exit status
make[1]: *** [qemu-system-i386] Error 1

cheers,
  Gerd



[Qemu-devel] [PATCH 3/3] linux-user: fix statfs

2012-08-21 Thread Alexander Graf
The statfs syscall should always memset(0) its full struct extent before
writing to it. Newer versions of the syscall use one of the reserved fields
for flags, which would otherwise get stale values from uncleaned memory.

This fixes libarchive for me, which got confused about the return value of
pathconf(/, _PC_REC_XFER_ALIGN) otherwise, as it some times gave old pointers
as return value.

Signed-off-by: Alexander Graf ag...@suse.de
---
 linux-user/syscall.c |   12 
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index d19efb8..61f5718 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -6667,6 +6667,12 @@ abi_long do_syscall(void *cpu_env, int num, abi_long 
arg1,
 __put_user(stfs.f_fsid.__val[0], target_stfs-f_fsid.val[0]);
 __put_user(stfs.f_fsid.__val[1], target_stfs-f_fsid.val[1]);
 __put_user(stfs.f_namelen, target_stfs-f_namelen);
+__put_user(stfs.f_frsize, target_stfs-f_frsize);
+__put_user(0, target_stfs-f_spare[0]);
+__put_user(0, target_stfs-f_spare[1]);
+__put_user(0, target_stfs-f_spare[2]);
+__put_user(0, target_stfs-f_spare[3]);
+__put_user(0, target_stfs-f_spare[4]);
 unlock_user_struct(target_stfs, arg2, 1);
 }
 break;
@@ -6695,6 +6701,12 @@ abi_long do_syscall(void *cpu_env, int num, abi_long 
arg1,
 __put_user(stfs.f_fsid.__val[0], target_stfs-f_fsid.val[0]);
 __put_user(stfs.f_fsid.__val[1], target_stfs-f_fsid.val[1]);
 __put_user(stfs.f_namelen, target_stfs-f_namelen);
+__put_user(stfs.f_frsize, target_stfs-f_frsize);
+__put_user(0, target_stfs-f_spare[0]);
+__put_user(0, target_stfs-f_spare[1]);
+__put_user(0, target_stfs-f_spare[2]);
+__put_user(0, target_stfs-f_spare[3]);
+__put_user(0, target_stfs-f_spare[4]);
 unlock_user_struct(target_stfs, arg3, 1);
 }
 break;
-- 
1.6.0.2




[Qemu-devel] [PATCH 2/3] linux-user: implement FS_IOC_SETFLAGS ioctl

2012-08-21 Thread Alexander Graf
Signed-off-by: Alexander Graf ag...@suse.de
---
 linux-user/ioctls.h   |1 +
 linux-user/syscall_defs.h |1 +
 2 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/linux-user/ioctls.h b/linux-user/ioctls.h
index 1b798b3..5027c74 100644
--- a/linux-user/ioctls.h
+++ b/linux-user/ioctls.h
@@ -87,6 +87,7 @@
MK_PTR(MK_STRUCT(STRUCT_fiemap)))
 #endif
   IOCTL(FS_IOC_GETFLAGS, IOC_R, MK_PTR(TYPE_INT))
+  IOCTL(FS_IOC_SETFLAGS, IOC_W, MK_PTR(TYPE_INT))
 
   IOCTL(SIOCATMARK, 0, TYPE_NULL)
   IOCTL(SIOCADDRT, IOC_W, MK_PTR(MK_STRUCT(STRUCT_rtentry)))
diff --git a/linux-user/syscall_defs.h b/linux-user/syscall_defs.h
index 67fbcab..349229d 100644
--- a/linux-user/syscall_defs.h
+++ b/linux-user/syscall_defs.h
@@ -2345,6 +2345,7 @@ struct target_eabi_flock64 {
 #define TARGET_MTIOCPOSTARGET_IOR('m', 3, struct mtpos)
 
 #define TARGET_FS_IOC_GETFLAGS TARGET_IORU('f', 1)
+#define TARGET_FS_IOC_SETFLAGS TARGET_IOWU('f', 2)
 
 struct target_sysinfo {
 abi_long uptime;/* Seconds since boot */
-- 
1.6.0.2




[Qemu-devel] [PATCH 1/3] linux-user: implement FS_IOC_GETFLAGS ioctl

2012-08-21 Thread Alexander Graf
Signed-off-by: Alexander Graf ag...@suse.de
---
 linux-user/ioctls.h   |1 +
 linux-user/syscall_defs.h |2 ++
 2 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/linux-user/ioctls.h b/linux-user/ioctls.h
index bb76c56..1b798b3 100644
--- a/linux-user/ioctls.h
+++ b/linux-user/ioctls.h
@@ -86,6 +86,7 @@
  IOCTL_SPECIAL(FS_IOC_FIEMAP, IOC_W | IOC_R, do_ioctl_fs_ioc_fiemap,
MK_PTR(MK_STRUCT(STRUCT_fiemap)))
 #endif
+  IOCTL(FS_IOC_GETFLAGS, IOC_R, MK_PTR(TYPE_INT))
 
   IOCTL(SIOCATMARK, 0, TYPE_NULL)
   IOCTL(SIOCADDRT, IOC_W, MK_PTR(MK_STRUCT(STRUCT_rtentry)))
diff --git a/linux-user/syscall_defs.h b/linux-user/syscall_defs.h
index 3b7b1c3..67fbcab 100644
--- a/linux-user/syscall_defs.h
+++ b/linux-user/syscall_defs.h
@@ -2344,6 +2344,8 @@ struct target_eabi_flock64 {
 #define TARGET_MTIOCGETTARGET_IOR('m', 2, struct mtget)
 #define TARGET_MTIOCPOSTARGET_IOR('m', 3, struct mtpos)
 
+#define TARGET_FS_IOC_GETFLAGS TARGET_IORU('f', 1)
+
 struct target_sysinfo {
 abi_long uptime;/* Seconds since boot */
 abi_ulong loads[3]; /* 1, 5, and 15 minute load averages */
-- 
1.6.0.2




  1   2   3   >