date:20150727



On 27/07/2015 13:26, Michael S. Tsirkin wrote:
   +if (s-conf.scsi) {
   +error_setg(errp, Virtio 1.0 does not support scsi 
   passthrough!);
  
  Unclear error message, as one would expect SCSI passthrough not to work
  anyway for e.g. a disk backed by a file.
 Right - so I suggested:
   Virtio modern does not support scsi passthrough - please set 
 disable-modern=on or switch to virtio-scsi.
 With that change - ACK?

scsi=on by default, so everyone is getting the message until they
disable virtio 1.0.  Suggesting a switch to virtio-scsi doesn't make sense.

Your proposal makes sense once scsi=off by default.  Until then, what
about please set scsi=off for virtio-blk devices in order to use virtio
1.0?

Paolo

Re: [Qemu-devel] [PATCH V4 3/3] virtio-blk: only clear VIRTIO_F_ANY_LAYOUT for legacy device



On 27/07/2015 13:22, Michael S. Tsirkin wrote:
  This patch is unnecessary, since the feature is added back below under
  if (__virtio_has_feature(features, VIRTIO_F_VERSION_1)).
 
 It's needed so we can apply
 virtio: set any_layout in virtio core

Ah, okay.

Paolo

Re: [Qemu-devel] [POC] colo-proxy in qemu

2015-07-27 Thread Samuel Thibault

Hello,

I'm just back from vacancy with no Internet access, so will answer
shortly :)

Samuel

Re: [Qemu-devel] [PATCH] fixup! virtio-blk: fail get_features when both scsi and 1.0 were set

2015-07-27 Thread Cornelia Huck

On Mon, 27 Jul 2015 13:41:32 +0200
Paolo Bonzini pbonz...@redhat.com wrote:

 Tweak the error message so that it does not mention SCSI passthrough.  That
 can be confusing because you can have scsi=on even for file-backed image,
 which obviously do not support SCSI passthrough at the block layer level.
 
 Signed-off-by: Paolo Bonzini pbonz...@redhat.com
 ---
  hw/block/virtio-blk.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c
 index 9acbc3a..7bed3f0 100644
 --- a/hw/block/virtio-blk.c
 +++ b/hw/block/virtio-blk.c
 @@ -734,7 +734,7 @@ static uint64_t virtio_blk_get_features(VirtIODevice 
 *vdev, uint64_t features,
  virtio_clear_feature(features, VIRTIO_F_ANY_LAYOUT);
  if (__virtio_has_feature(features, VIRTIO_F_VERSION_1)) {
  if (s-conf.scsi) {
 -error_setg(errp, Virtio 1.0 does not support scsi 
 passthrough!);
 +error_setg(errp, Please set scsi=off for virtio-blk devices in 
 order to use virtio 1.0);
  return 0;
  }
  virtio_add_feature(features, VIRTIO_F_ANY_LAYOUT);

I like that message much better.

Re: [Qemu-devel] [Qemu-stable] [PULL 0/3] Cve 2015 5154 patches



On 07/27/2015 08:10 AM, Stefan Priebe - Profihost AG wrote:
 
 Am 27.07.2015 um 14:01 schrieb John Snow:
 The following changes since commit f793d97e454a56d17e404004867985622ca1a63b:

   Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into 
 staging (2015-07-24 13:07:10 +0100)

 are available in the git repository at:

   https://github.com/jnsnow/qemu.git tags/cve-2015-5154-pull-request
 
 Any details on this CVE? Is RCE possible? Only if IDE is used?
 
 Stefan
 
 for you to fetch changes up to cb72cba83021fa42719e73a5249c12096a4d1cfc:

   ide: Clear DRQ after handling all expected accesses (2015-07-26 23:42:53 
 -0400)

 

 

 Kevin Wolf (3):
   ide: Check array bounds before writing to io_buffer (CVE-2015-5154)
   ide/atapi: Fix START STOP UNIT command completion
   ide: Clear DRQ after handling all expected accesses

  hw/ide/atapi.c |  1 +
  hw/ide/core.c  | 32 
  2 files changed, 29 insertions(+), 4 deletions(-)


See also http://seclists.org/oss-sec/2015/q3/212

[Qemu-devel] [PATCH] kvm_ppc: remove kvmppc_timer_hack

QEMU does have an I/O thread now, that can be interrupted at any time
because the VCPU thread runs outside the iothread mutex.

Therefore, the kvmppc_timer_hack is obsolete.  Remove it.

Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---

Notes:
Untested!

 hw/ppc/e500.c|  4 
 hw/ppc/ppc440_bamboo.c   |  3 ---
 target-ppc/Makefile.objs |  2 +-
 target-ppc/kvm_ppc.c | 41 -
 target-ppc/kvm_ppc.h |  2 --
 5 files changed, 1 insertion(+), 51 deletions(-)
 delete mode 100644 target-ppc/kvm_ppc.c

diff --git a/hw/ppc/e500.c b/hw/ppc/e500.c
index d300846..e968386 100644
--- a/hw/ppc/e500.c
+++ b/hw/ppc/e500.c
@@ -1048,10 +1048,6 @@ void ppce500_init(MachineState *machine, PPCE500Params 
*params)
 boot_info-entry = bios_entry;
 boot_info-dt_base = dt_base;
 boot_info-dt_size = dt_size;
-
-if (kvm_enabled()) {
-kvmppc_init();
-}
 }
 
 static int e500_ccsr_initfn(SysBusDevice *dev)
diff --git a/hw/ppc/ppc440_bamboo.c b/hw/ppc/ppc440_bamboo.c
index 032fa80..5745f03 100644
--- a/hw/ppc/ppc440_bamboo.c
+++ b/hw/ppc/ppc440_bamboo.c
@@ -288,9 +288,6 @@ static void bamboo_init(MachineState *machine)
 exit(1);
 }
 }
-
-if (kvm_enabled())
-kvmppc_init();
 }
 
 static QEMUMachine bamboo_machine = {
diff --git a/target-ppc/Makefile.objs b/target-ppc/Makefile.objs
index a7ae392..0a96ee2 100644
--- a/target-ppc/Makefile.objs
+++ b/target-ppc/Makefile.objs
@@ -4,7 +4,7 @@ ifeq ($(CONFIG_SOFTMMU),y)
 obj-y += machine.o mmu_helper.o mmu-hash32.o
 obj-$(TARGET_PPC64) += mmu-hash64.o arch_dump.o
 endif
-obj-$(CONFIG_KVM) += kvm.o kvm_ppc.o
+obj-$(CONFIG_KVM) += kvm.o
 obj-$(call lnot,$(CONFIG_KVM)) += kvm-stub.o
 obj-y += dfp_helper.o
 obj-y += excp_helper.o
diff --git a/target-ppc/kvm_ppc.c b/target-ppc/kvm_ppc.c
deleted file mode 100644
index f769acd..000
--- a/target-ppc/kvm_ppc.c
+++ /dev/null
@@ -1,41 +0,0 @@
-/*
- * PowerPC KVM support
- *
- * Copyright IBM Corp. 2008
- *
- * Authors:
- *  Hollis Blanchard holl...@us.ibm.com
- *
- * This work is licensed under the terms of the GNU GPL, version 2 or later.
- * See the COPYING file in the top-level directory.
- *
- */
-
-#include qemu-common.h
-#include qemu/timer.h
-#include kvm_ppc.h
-#include sysemu/device_tree.h
-#include qemu/main-loop.h
-
-#define PROC_DEVTREE_PATH /proc/device-tree
-
-static QEMUTimer *kvmppc_timer;
-static unsigned int kvmppc_timer_rate;
-
-static void kvmppc_timer_hack(void *opaque)
-{
-qemu_notify_event();
-timer_mod(kvmppc_timer, qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) + 
kvmppc_timer_rate);
-}
-
-void kvmppc_init(void)
-{
-/* XXX The only reason KVM yields control back to qemu is device IO. Since
- * an idle guest does no IO, qemu's device model will never get a chance to
- * run. So, until QEMU gains IO threads, we create this timer to ensure
- * that the device model gets a chance to run. */
-kvmppc_timer_rate = get_ticks_per_sec() / 10;
-kvmppc_timer = timer_new_ns(QEMU_CLOCK_VIRTUAL, kvmppc_timer_hack, NULL);
-timer_mod(kvmppc_timer, qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) + 
kvmppc_timer_rate);
-}
-
diff --git a/target-ppc/kvm_ppc.h b/target-ppc/kvm_ppc.h
index 4d30e27..5c1d334 100644
--- a/target-ppc/kvm_ppc.h
+++ b/target-ppc/kvm_ppc.h
@@ -11,8 +11,6 @@
 
 #define TYPE_HOST_POWERPC_CPU host- TYPE_POWERPC_CPU
 
-void kvmppc_init(void);
-
 #ifdef CONFIG_KVM
 
 uint32_t kvmppc_get_tbfreq(void);
-- 
2.4.3

Re: [Qemu-devel] [PATCH for-2.5] rcu: Allow calling rcu_(un)register_thread() during synchronize_rcu()

2015-07-27 Thread Wen Congyang

On 07/27/2015 06:17 PM, Paolo Bonzini wrote:
 
 
 On 27/07/2015 04:24, Wen Congyang wrote:
 +/* Wait for one thread to report a quiescent state and try again.
 + * Release rcu_registry_lock, so rcu_(un)register_thread() doesn't
 + * wait too much time. Note: rcu_unregister_thread() may remove
 + * the node from qsreaders. That's a bit tricky, but it should work.
 
 It should work is a bit optimistic. :D
 
 Does this description look okay?
 
 /* Wait for one thread to report a quiescent state and try again.
  * Release rcu_registry_lock, so rcu_(un)register_thread() doesn't
  * wait too much time.
  *
  * rcu_register_thread() may add nodes to registry; it will not
  * wake up synchronize_rcu, but that is okay because at least another
  * thread must exit its RCU read-side critical section before
  * synchronize_rcu is done.  The next iteration of the loop will
  * process the new thread or set -waiting for it.  Hence, this can
  * at worst cause synchronize_rcu() to wait for longer.

I don't understand this. The next iteration of the loop will move the new 
thread's
rcu_reader from registry to qsreaders even if we call rcu_read_lock() in the 
new thread.
Because rcu_gp_ongoing() will return false.

Thanks
Wen Congyang

  *
  * rcu_unregister_thread() may remove nodes from qsreaders instead
  * of registry if it runs during qemu_event_wait.  That's okay;
  * the node then will not be added back to registry by QLIST_SWAP
  * below.  The invariant is that the node is part of one list when
  * rcu_registry_lock is released.
  */
 
 Paolo
 .

[Qemu-devel] [PATCH v2 for-2.5 00/12] tcg: improve optimizer

This patchset improves the optimizer in 3 different ways:
 - by optimizing temp tracking using a bit array
 - by allowing constants to have copy
 - by differentiating 32 - 64 bits conversions from moves in the
   frontend by using specific instructions

The latter change introduces 2 new mandatory ext/extu_i32_i64 ops.
For the future we might want to allow each guest to only implement 2 of
the 3 size changing ops as I started to do in the following patchset:
http://lists.nongnu.org/archive/html/qemu-devel/2015-07/msg03369.html
That said we probably want to experiment with that first and see the
impact on the performances. If wrongly implemented, things might seem
to work but some bugs might appear in very rare cases, like the
truncation problem we recently got on aarch64 and x86-64 hosts.
Alternatively we might want to always implement the 3 ops on all
backends to avoid multiplying variants of the code and with that bugs.

This patchset has been fully tested on x86-64 host, but only lightly
tested on aarch64, ppc64 and s390x hosts.

Note that the two first patches have already been sent separately on the
mailing list and should make their way to the 2.4 release. I have
included them as they are fixing bugs triggered by patches from these
series.

Changes v1-v2
 - Added patches 1  2
 - patch 3: use bitmap_zero instead of memset
for the call op, only reset temps that are in use
 - patch 4: do not use a bool to detect copies

Aurelien Jarno (12):
  tcg: correctly mark dead inputs for mov with a constant
  tcg: mark temps as mem_coherent = 0 for mov with a constant
  tcg/optimize: optimize temps tracking
  tcg/optimize: add temp_is_const and temp_is_copy functions
  tcg/optimize: track const/copy status separately
  tcg/optimize: allow constant to have copies
  tcg: rename trunc_shr_i32 into trunc_shr_i64_i32
  tcg: don't abuse TCG type in tcg_gen_trunc_shr_i64_i32
  tcg: implement real ext_i32_i64 and extu_i32_i64 ops
  tcg/optimize: add optimizations for ext_i32_i64 and extu_i32_i64 ops
  tcg/optimize: do not remember garbage high bits for 32-bit ops
  tcg: update README about size changing ops

 tcg/README   |  20 +++-
 tcg/aarch64/tcg-target.c |   4 +
 tcg/aarch64/tcg-target.h |   2 +-
 tcg/i386/tcg-target.c|   5 +
 tcg/i386/tcg-target.h|   2 +-
 tcg/ia64/tcg-target.c|   4 +
 tcg/ia64/tcg-target.h|   2 +-
 tcg/optimize.c   | 259 +--
 tcg/ppc/tcg-target.c |   6 ++
 tcg/ppc/tcg-target.h |   2 +-
 tcg/s390/tcg-target.c|   5 +
 tcg/s390/tcg-target.h|   2 +-
 tcg/sparc/tcg-target.c   |  12 ++-
 tcg/sparc/tcg-target.h   |   2 +-
 tcg/tcg-op.c |  16 ++-
 tcg/tcg-opc.h|   7 +-
 tcg/tcg.c|   4 +
 tcg/tcg.h|   2 +-
 tcg/tci/tcg-target.c |   4 +
 tcg/tci/tcg-target.h |   2 +-
 tci.c|   6 +-
 21 files changed, 198 insertions(+), 170 deletions(-)

-- 
2.1.4

[Qemu-devel] [PATCH v2 for-2.5 10/12] tcg/optimize: add optimizations for ext_i32_i64 and extu_i32_i64 ops

They behave the same as ext32s_i64 and ext32u_i64 from the constant
folding and zero propagation point of view, except that they can't
be replaced by a mov, so we don't compute the affected value.

Cc: Richard Henderson r...@twiddle.net
Signed-off-by: Aurelien Jarno aurel...@aurel32.net
---
 tcg/optimize.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/tcg/optimize.c b/tcg/optimize.c
index 8bfe7ff..8f33755 100644
--- a/tcg/optimize.c
+++ b/tcg/optimize.c
@@ -343,9 +343,11 @@ static TCGArg do_constant_folding_2(TCGOpcode op, TCGArg 
x, TCGArg y)
 CASE_OP_32_64(ext16u):
 return (uint16_t)x;
 
+case INDEX_op_ext_i32_i64:
 case INDEX_op_ext32s_i64:
 return (int32_t)x;
 
+case INDEX_op_extu_i32_i64:
 case INDEX_op_ext32u_i64:
 return (uint32_t)x;
 
@@ -830,6 +832,15 @@ void tcg_optimize(TCGContext *s)
 mask = temps[args[1]].mask  mask;
 break;
 
+case INDEX_op_ext_i32_i64:
+if ((temps[args[1]].mask  0x8000) != 0) {
+break;
+}
+case INDEX_op_extu_i32_i64:
+/* We do not compute affected as it is a size changing op.  */
+mask = (uint32_t)temps[args[1]].mask;
+break;
+
 CASE_OP_32_64(andc):
 /* Known-zeros does not imply known-ones.  Therefore unless
args[2] is constant, we can't infer anything from it.  */
@@ -1008,6 +1019,8 @@ void tcg_optimize(TCGContext *s)
 CASE_OP_32_64(ext16u):
 case INDEX_op_ext32s_i64:
 case INDEX_op_ext32u_i64:
+case INDEX_op_ext_i32_i64:
+case INDEX_op_extu_i32_i64:
 if (temp_is_const(args[1])) {
 tmp = do_constant_folding(opc, temps[args[1]].val, 0);
 tcg_opt_gen_movi(s, op, args, args[0], tmp);
-- 
2.1.4

[Qemu-devel] [PATCH v2 for-2.5 07/12] tcg: rename trunc_shr_i32 into trunc_shr_i64_i32

The op is sometimes named trunc_shr_i32 and sometimes trunc_shr_i64_i32,
and the name in the README doesn't match the name offered to the
frontends.

Always use the long name to make it clear it is a size changing op.

Reviewed-by: Richard Henderson r...@twiddle.net
Signed-off-by: Aurelien Jarno aurel...@aurel32.net
---
 tcg/README   | 2 +-
 tcg/aarch64/tcg-target.h | 2 +-
 tcg/i386/tcg-target.h| 2 +-
 tcg/ia64/tcg-target.h| 2 +-
 tcg/optimize.c   | 6 +++---
 tcg/ppc/tcg-target.h | 2 +-
 tcg/s390/tcg-target.h| 2 +-
 tcg/sparc/tcg-target.c   | 4 ++--
 tcg/sparc/tcg-target.h   | 2 +-
 tcg/tcg-op.c | 4 ++--
 tcg/tcg-opc.h| 4 ++--
 tcg/tcg.h| 2 +-
 tcg/tci/tcg-target.h | 2 +-
 13 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/tcg/README b/tcg/README
index a550ff1..61b3899 100644
--- a/tcg/README
+++ b/tcg/README
@@ -314,7 +314,7 @@ This operation would be equivalent to
 
   dest = (t1  ~0x0f00) | ((t2  8)  0x0f00)
 
-* trunc_shr_i32 t0, t1, pos
+* trunc_shr_i64_i32 t0, t1, pos
 
 For 64-bit hosts only, right shift the 64-bit input T1 by POS and
 truncate to 32-bit output T0.  Depending on the host, this may be
diff --git a/tcg/aarch64/tcg-target.h b/tcg/aarch64/tcg-target.h
index 8aec04d..dfd8801 100644
--- a/tcg/aarch64/tcg-target.h
+++ b/tcg/aarch64/tcg-target.h
@@ -70,7 +70,7 @@ typedef enum {
 #define TCG_TARGET_HAS_muls2_i320
 #define TCG_TARGET_HAS_muluh_i320
 #define TCG_TARGET_HAS_mulsh_i320
-#define TCG_TARGET_HAS_trunc_shr_i320
+#define TCG_TARGET_HAS_trunc_shr_i64_i32 0
 
 #define TCG_TARGET_HAS_div_i64  1
 #define TCG_TARGET_HAS_rem_i64  1
diff --git a/tcg/i386/tcg-target.h b/tcg/i386/tcg-target.h
index 25b5133..dae50ba 100644
--- a/tcg/i386/tcg-target.h
+++ b/tcg/i386/tcg-target.h
@@ -102,7 +102,7 @@ extern bool have_bmi1;
 #define TCG_TARGET_HAS_mulsh_i320
 
 #if TCG_TARGET_REG_BITS == 64
-#define TCG_TARGET_HAS_trunc_shr_i320
+#define TCG_TARGET_HAS_trunc_shr_i64_i32 0
 #define TCG_TARGET_HAS_div2_i64 1
 #define TCG_TARGET_HAS_rot_i64  1
 #define TCG_TARGET_HAS_ext8s_i641
diff --git a/tcg/ia64/tcg-target.h b/tcg/ia64/tcg-target.h
index a04ed81..29902f9 100644
--- a/tcg/ia64/tcg-target.h
+++ b/tcg/ia64/tcg-target.h
@@ -160,7 +160,7 @@ typedef enum {
 #define TCG_TARGET_HAS_muluh_i640
 #define TCG_TARGET_HAS_mulsh_i320
 #define TCG_TARGET_HAS_mulsh_i640
-#define TCG_TARGET_HAS_trunc_shr_i320
+#define TCG_TARGET_HAS_trunc_shr_i64_i32 0
 
 #define TCG_TARGET_deposit_i32_valid(ofs, len) ((len) = 16)
 #define TCG_TARGET_deposit_i64_valid(ofs, len) ((len) = 16)
diff --git a/tcg/optimize.c b/tcg/optimize.c
index 2d3c72b..8bfe7ff 100644
--- a/tcg/optimize.c
+++ b/tcg/optimize.c
@@ -288,7 +288,7 @@ static TCGArg do_constant_folding_2(TCGOpcode op, TCGArg x, 
TCGArg y)
 case INDEX_op_shr_i32:
 return (uint32_t)x  (y  31);
 
-case INDEX_op_trunc_shr_i32:
+case INDEX_op_trunc_shr_i64_i32:
 case INDEX_op_shr_i64:
 return (uint64_t)x  (y  63);
 
@@ -867,7 +867,7 @@ void tcg_optimize(TCGContext *s)
 }
 break;
 
-case INDEX_op_trunc_shr_i32:
+case INDEX_op_trunc_shr_i64_i32:
 mask = (uint64_t)temps[args[1]].mask  args[2];
 break;
 
@@ -1015,7 +1015,7 @@ void tcg_optimize(TCGContext *s)
 }
 goto do_default;
 
-case INDEX_op_trunc_shr_i32:
+case INDEX_op_trunc_shr_i64_i32:
 if (temp_is_const(args[1])) {
 tmp = do_constant_folding(opc, temps[args[1]].val, args[2]);
 tcg_opt_gen_movi(s, op, args, args[0], tmp);
diff --git a/tcg/ppc/tcg-target.h b/tcg/ppc/tcg-target.h
index 7ce7048..b7e6861 100644
--- a/tcg/ppc/tcg-target.h
+++ b/tcg/ppc/tcg-target.h
@@ -77,7 +77,7 @@ typedef enum {
 #if TCG_TARGET_REG_BITS == 64
 #define TCG_TARGET_HAS_add2_i32 0
 #define TCG_TARGET_HAS_sub2_i32 0
-#define TCG_TARGET_HAS_trunc_shr_i320
+#define TCG_TARGET_HAS_trunc_shr_i64_i32 0
 #define TCG_TARGET_HAS_div_i64  1
 #define TCG_TARGET_HAS_rem_i64  0
 #define TCG_TARGET_HAS_rot_i64  1
diff --git a/tcg/s390/tcg-target.h b/tcg/s390/tcg-target.h
index 91576d5..50016a8 100644
--- a/tcg/s390/tcg-target.h
+++ b/tcg/s390/tcg-target.h
@@ -72,7 +72,7 @@ typedef enum TCGReg {
 #define TCG_TARGET_HAS_muls2_i320
 #define TCG_TARGET_HAS_muluh_i320
 #define TCG_TARGET_HAS_mulsh_i320
-#define TCG_TARGET_HAS_trunc_shr_i320
+#define TCG_TARGET_HAS_trunc_shr_i64_i32 0
 
 #define TCG_TARGET_HAS_div2_i64 1
 #define TCG_TARGET_HAS_rot_i64  1
diff --git a/tcg/sparc/tcg-target.c b/tcg/sparc/tcg-target.c
index 1a870a8..b23032b 100644
--- a/tcg/sparc/tcg-target.c
+++ b/tcg/sparc/tcg-target.c
@@ -1413,7 +1413,7 @@ static void tcg_out_op(TCGContext *s, TCGOpcode opc,
 case INDEX_op_ext32u_i64:

[Qemu-devel] [PATCH v2 for-2.5 03/12] tcg/optimize: optimize temps tracking

The tcg_temp_info structure uses 24 bytes per temp. Now that we emulate
vector registers on most guests, it's not uncommon to have more than 100
used temps. This means we have initialize more than 2kB at least twice
per TB, often more when there is a few goto_tb.

Instead used a TCGTempSet bit array to track which temps are in used in
the current basic block. This means there are only around 16 bytes to
initialize.

This improves the boot time of a MIPS guest on an x86-64 host by around
7% and moves out tcg_optimize from the the top of the profiler list.

Cc: Richard Henderson r...@twiddle.net
Signed-off-by: Aurelien Jarno aurel...@aurel32.net
---
 tcg/optimize.c | 36 +---
 1 file changed, 25 insertions(+), 11 deletions(-)

diff --git a/tcg/optimize.c b/tcg/optimize.c
index cd0e793..425c14b 100644
--- a/tcg/optimize.c
+++ b/tcg/optimize.c
@@ -50,6 +50,7 @@ struct tcg_temp_info {
 };
 
 static struct tcg_temp_info temps[TCG_MAX_TEMPS];
+static TCGTempSet temps_used;
 
 /* Reset TEMP's state to TCG_TEMP_UNDEF.  If TEMP only had one copy, remove
the copy flag from the left temp.  */
@@ -67,6 +68,22 @@ static void reset_temp(TCGArg temp)
 temps[temp].mask = -1;
 }
 
+/* Reset all temporaries, given that there are NB_TEMPS of them.  */
+static void reset_all_temps(int nb_temps)
+{
+bitmap_zero(temps_used.l, nb_temps);
+}
+
+/* Initialize and activate a temporary.  */
+static void init_temp_info(TCGArg temp)
+{
+if (!test_bit(temp, temps_used.l)) {
+temps[temp].state = TCG_TEMP_UNDEF;
+temps[temp].mask = -1;
+set_bit(temp, temps_used.l);
+}
+}
+
 static TCGOp *insert_op_before(TCGContext *s, TCGOp *old_op,
 TCGOpcode opc, int nargs)
 {
@@ -98,16 +115,6 @@ static TCGOp *insert_op_before(TCGContext *s, TCGOp *old_op,
 return new_op;
 }
 
-/* Reset all temporaries, given that there are NB_TEMPS of them.  */
-static void reset_all_temps(int nb_temps)
-{
-int i;
-for (i = 0; i  nb_temps; i++) {
-temps[i].state = TCG_TEMP_UNDEF;
-temps[i].mask = -1;
-}
-}
-
 static int op_bits(TCGOpcode op)
 {
 const TCGOpDef *def = tcg_op_defs[op];
@@ -606,6 +613,11 @@ void tcg_optimize(TCGContext *s)
 nb_iargs = def-nb_iargs;
 }
 
+/* Initialize the temps that are going to be used */
+for (i = 0; i  nb_oargs + nb_iargs; i++) {
+init_temp_info(args[i]);
+}
+
 /* Do copy propagation */
 for (i = nb_oargs; i  nb_oargs + nb_iargs; i++) {
 if (temps[args[i]].state == TCG_TEMP_COPY) {
@@ -1299,7 +1311,9 @@ void tcg_optimize(TCGContext *s)
 if (!(args[nb_oargs + nb_iargs + 1]
(TCG_CALL_NO_READ_GLOBALS | TCG_CALL_NO_WRITE_GLOBALS))) {
 for (i = 0; i  nb_globals; i++) {
-reset_temp(i);
+if (test_bit(i, temps_used.l)) {
+reset_temp(i);
+}
 }
 }
 goto do_reset_output;
-- 
2.1.4

Re: [Qemu-devel] [PATCH v4 2/2] QOM: object_property_add() performance improvement

2015-07-27 Thread Daniel P. Berrange

On Mon, Jul 27, 2015 at 03:03:26PM +0200, Markus Armbruster wrote:
 Pavel Fedin p.fe...@samsung.com writes:
 
  Avoid repetitive lookup of every property in array starting from 0 by adding
  one more property which caches last used index. Every time an array is
  expanded the index is picked up from this cache.
 
  The property is a uint32_t and its name is name of the array plus '#'
  ('name#'). It has getter function in order to allow to inspect it from
  within monitor.
 
 Do we really want '#' in property names?  Elsewhere, we require names to
 be id_wellformed().  I've long argued for doing that consistently[*],
 but QOM still doesn't.
 
 I've always hated automatic arrayification, not least because it
 encodes semantics in property names.  I tried to replace it[**], but
 Paolo opposed it.  Which makes him the go-to guy for reviewing anything
 that touches it ;-P

Yeah, I think the magic arrayification behaviour is pretty unpleasant.
It feels like a poor hack to deal with fact that we've not got support
for setting non-scalar properties. Since we're representing arrays
implicitly, we have in turned created the performance problem that
we're facing now because we don't explicitly track the size of the
array. Now we're going to add yet more magic properties to deal this :-(
Not to mention the fact that we've no type safety on the array elements
we're storing eg  propname[0] could be an int16, propname[1] could be
a string, and so on with no checking.

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 v2 for-2.5 05/12] tcg/optimize: track const/copy status separately



On 27/07/2015 15:40, Aurelien Jarno wrote:
   temps[dst].next_copy = temps[src].next_copy;
   temps[dst].prev_copy = src;
   temps[temps[dst].next_copy].prev_copy = dst;
   temps[src].next_copy = dst;

 Note that the patch doesn't change this part, it's already there in the
 original code.

Understood.

  This is:
  
  dst-next = src-next;
  dst-prev = src;
  dst-next-prev = dst;
  src-next = dst;
 
 Here we just want to insert one element, and thus before
 the insertion we have dst-next = dst-prev = dst.

Ah, you're right.

Paolo

[Qemu-devel] [PULL for-2.4 00/16] Net patches

The following changes since commit f793d97e454a56d17e404004867985622ca1a63b:

  Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into staging 
(2015-07-24 13:07:10 +0100)

are available in the git repository at:

  git://github.com/stefanha/qemu.git tags/net-pull-request

for you to fetch changes up to f9f7492ea4a9dda538fedeec31399fb940533a16:

  axienet: Flush queued packets when rx is done (2015-07-27 14:12:18 +0100)


Pull request

Here are NIC fixes from Fam Zheng that prevent rx hangs (caused by NIC models
where .can_receive() stops rx but qemu_flush_queued_packets() isn't called).



Fam Zheng (12):
  xgmac: Drop packets with eth_can_rx is false.
  pcnet: Drop pcnet_can_receive
  eepro100: Drop nic_can_receive
  usbnet: Drop usbnet_can_receive
  etsec: Move etsec_can_receive into etsec_receive
  etsec: Flush queue when rx buffer is consumed
  mcf_fec: Drop mcf_fec_can_receive
  milkymist-minimac2: Flush queued packets when link comes up
  mipsnet: Flush queued packets when receiving is enabled
  stellaris_enet: Flush queued packets when read done
  dp8393x: Flush packets when link comes up
  axienet: Flush queued packets when rx is done

Greg Ungerer (4):
  hw/net: create common collection of MII definitions
  hw/net: add ANLPAR bit definitions to generic mii
  hw/net: add simple phy support to mcf_fec driver
  hw/net: fix mcf_fec driver receiver

 hw/net/dp8393x.c|  8 +
 hw/net/eepro100.c   | 11 --
 hw/net/fsl_etsec/etsec.c| 20 +--
 hw/net/fsl_etsec/etsec.h|  4 ++-
 hw/net/fsl_etsec/rings.c| 17 +
 hw/net/lance.c  |  1 -
 hw/net/mcf_fec.c| 63 --
 hw/net/milkymist-minimac2.c | 33 +-
 hw/net/mipsnet.c|  9 +++--
 hw/net/pcnet-pci.c  |  1 -
 hw/net/pcnet.c  |  9 -
 hw/net/pcnet.h  |  1 -
 hw/net/stellaris_enet.c | 14 +++-
 hw/net/xgmac.c  |  8 ++---
 hw/net/xilinx_axienet.c | 17 ++---
 hw/usb/dev-network.c| 20 +++
 include/hw/net/allwinner_emac.h | 40 +-
 include/hw/net/mii.h| 76 +
 trace-events|  1 -
 19 files changed, 210 insertions(+), 143 deletions(-)
 create mode 100644 include/hw/net/mii.h

-- 
2.4.3

[Qemu-devel] [PULL for-2.4 13/16] mipsnet: Flush queued packets when receiving is enabled

From: Fam Zheng f...@redhat.com

Drop .can_receive and move the semantics to mipsnet_receive, by
returning 0.

After 0 is returned, we must flush the queue explicitly to restart it:
Call qemu_flush_queued_packets when s-busy or s-rx_count is being
updated.

Signed-off-by: Fam Zheng f...@redhat.com
Reviewed-by: Stefan Hajnoczi stefa...@redhat.com
Reviewed-by: Jason Wang jasow...@redhat.com
Message-id: 143693-22791-10-git-send-email-f...@redhat.com
Signed-off-by: Stefan Hajnoczi stefa...@redhat.com
---
 hw/net/mipsnet.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/hw/net/mipsnet.c b/hw/net/mipsnet.c
index c813e0c..f261011 100644
--- a/hw/net/mipsnet.c
+++ b/hw/net/mipsnet.c
@@ -80,7 +80,7 @@ static ssize_t mipsnet_receive(NetClientState *nc, const 
uint8_t *buf, size_t si
 
 trace_mipsnet_receive(size);
 if (!mipsnet_can_receive(nc))
-return -1;
+return 0;
 
 s-busy = 1;
 
@@ -134,6 +134,9 @@ static uint64_t mipsnet_ioport_read(void *opaque, hwaddr 
addr,
 if (s-rx_count) {
 s-rx_count--;
 ret = s-rx_buffer[s-rx_read++];
+if (mipsnet_can_receive(s-nic-ncs)) {
+qemu_flush_queued_packets(qemu_get_queue(s-nic));
+}
 }
 break;
 /* Reads as zero. */
@@ -170,6 +173,9 @@ static void mipsnet_ioport_write(void *opaque, hwaddr addr,
 }
 s-busy = !!s-intctl;
 mipsnet_update_irq(s);
+if (mipsnet_can_receive(s-nic-ncs)) {
+qemu_flush_queued_packets(qemu_get_queue(s-nic));
+}
 break;
 case MIPSNET_TX_DATA_BUFFER:
 s-tx_buffer[s-tx_written++] = val;
@@ -214,7 +220,6 @@ static const VMStateDescription vmstate_mipsnet = {
 static NetClientInfo net_mipsnet_info = {
 .type = NET_CLIENT_OPTIONS_KIND_NIC,
 .size = sizeof(NICState),
-.can_receive = mipsnet_can_receive,
 .receive = mipsnet_receive,
 };
 
-- 
2.4.3

Re: [Qemu-devel] [Qemu-stable] [PULL 0/3] Cve 2015 5154 patches

Am 27.07.2015 um 15:46 hat Peter Lieven geschrieben:
 Am 27.07.2015 um 15:38 schrieb Kevin Wolf:
 
 Am 27.07.2015 um 15:25 hat Stefan Priebe - Profihost AG geschrieben:
 
 Am 27.07.2015 um 14:28 schrieb John Snow:
 
 
 On 07/27/2015 08:10 AM, Stefan Priebe - Profihost AG wrote:
 
 Am 27.07.2015 um 14:01 schrieb John Snow:
 
 The following changes since commit 
 f793d97e454a56d17e404004867985622ca1a63b:
 
   Merge remote-tracking branch 
 'remotes/bonzini/tags/for-upstream' into staging (2015-07-24 13:07:10 +0100)
 
 are available in the git repository at:
 
   https://github.com/jnsnow/qemu.git 
 tags/cve-2015-5154-pull-request
 
 Any details on this CVE? Is RCE possible? Only if IDE is used?
 
 Stefan
 
 
 It's a heap overflow. The most likely outcome is a segfault, but 
 the
 guest is allowed to continue writing past the end of the PIO 
 buffer at
 its leisure. This makes it similar to CVE-2015-3456.
 
 This CVE can be mitigated unlike CVE-2015-3456 by just removing 
 the
 CD-ROM drive until the patch can be applied.
 
 Thanks. The seclist article explicitly references xen. So it does not
 apply to qemu/kvm? Sorry for asking may be stupid questions.
 
 The IDE emulation is shared between Xen and KVM, so both are affected.
 The reason why the seclist mail only mentions Xen is probably because
 the Xen security team posted it.
 
 Meanwhile there is also a Red Hat CVE page available, which mentions
 qemu-kvm: https://access.redhat.com/security/cve/CVE-2015-5154
 
 
 The redhat advisory says that some Redhat versions are not affected
 because they did not backport the upstream commit that introduced this issue
 .
 
 Can you point out which commit exactly introduced the issue?

That's the commit that introduced the code fixed in patch 2: Commit
ce560dcf ('ATAPI: STARTSTOPUNIT only eject/load media if powercondition
is 0').

Kevin

Re: [Qemu-devel] [PATCH for-2.5] rcu: Allow calling rcu_(un)register_thread() during synchronize_rcu()

2015-07-27 Thread Wen Congyang

On 07/27/2015 06:52 PM, Paolo Bonzini wrote:
 
 
 On 27/07/2015 12:44, Wen Congyang wrote:
  * rcu_register_thread() may add nodes to registry; it will not
  * wake up synchronize_rcu, but that is okay because at least 
 another
  * thread must exit its RCU read-side critical section before
  * synchronize_rcu is done.  The next iteration of the loop will
  * process the new thread or set -waiting for it.  Hence, this can
  * at worst cause synchronize_rcu() to wait for longer.
 I don't understand this. The next iteration of the loop will move the new 
 thread's
 rcu_reader from registry to qsreaders even if we call rcu_read_lock() in the 
 new thread.
 Because rcu_gp_ongoing() will return false.
 
 You're right.  This proves that a comment was necessary! :)

Yes, I agree with it.

 
 Second try:
 
  * rcu_register_thread() may add nodes to registry; it will not
  * wake up synchronize_rcu, but that is okay because at least another
  * thread must exit its RCU read-side critical section before
  * synchronize_rcu is done.  The next iteration of the loop will
  * move the new thread's rcu_reader from registry to qsreaders,
  * because rcu_gp_ongoing() will return false.

I will update the comment and send it again.

Thanks
Wen Congyang

 
 Paolo
 .

[Qemu-devel] [PATCH for-2.4 01/12] tcg: correctly mark dead inputs for mov with a constant

When tcg_reg_alloc_mov propagate a constant, we failed to correctly mark
a temp as dead if the liveness analysis hints so. This fixes the
following assert when configure with --enable-debug-tcg:

  qemu-x86_64: tcg/tcg.c:1827: tcg_reg_alloc_bb_end: Assertion `ts-val_type == 
TEMP_VAL_DEAD' failed.

Cc: Richard Henderson r...@twiddle.net
Reported-by: Richard Henderson r...@twiddle.net
Signed-off-by: Aurelien Jarno aurel...@aurel32.net
---
 tcg/tcg.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/tcg/tcg.c b/tcg/tcg.c
index 7e088b1..9a2508b 100644
--- a/tcg/tcg.c
+++ b/tcg/tcg.c
@@ -1920,6 +1920,9 @@ static void tcg_reg_alloc_mov(TCGContext *s, const 
TCGOpDef *def,
 }
 ots-val_type = TEMP_VAL_CONST;
 ots-val = ts-val;
+if (IS_DEAD_ARG(1)) {
+temp_dead(s, args[1]);
+}
 } else {
 /* The code in the first if block should have moved the
temp to a register. */
-- 
2.1.4

[Qemu-devel] [PATCH v2 for-2.5 06/12] tcg/optimize: allow constant to have copies

Now that copies and constants are tracked separately, we can allow
constant to have copies, deferring the choice to use a register or a
constant to the register allocation pass. This prevent this kind of
regular constant reloading:

-OUT: [size=338]
+OUT: [size=298]
   mov-0x4(%r14),%ebp
   test   %ebp,%ebp
   jne0x7ffbe9cb0ed6
   mov$0x40002219f8,%rbp
   mov%rbp,(%r14)
-  mov$0x40002219f8,%rbp
   mov$0x4000221a20,%rbx
   mov%rbp,(%rbx)
   mov$0x40,%rbp
   mov%rbp,(%r14)
-  mov$0x40,%rbp
   mov$0x4000221d38,%rbx
   mov%rbp,(%rbx)
   mov$0x40002221a8,%rbp
   mov%rbp,(%r14)
-  mov$0x40002221a8,%rbp
   mov$0x4000221d40,%rbx
   mov%rbp,(%rbx)
   mov$0x419170,%rbp
   mov%rbp,(%r14)
-  mov$0x419170,%rbp
   mov$0x4000221d48,%rbx
   mov%rbp,(%rbx)
   mov$0x4049ee,%rbp
   mov%rbp,0x80(%r14)
   mov%r14,%rdi
   callq  0x7ffbe99924d0
   mov$0x401680,%rbp
   mov%rbp,0x30(%r14)
   mov0x10(%r14),%rbp
   mov$0x401680,%rbp
   mov%rbp,0x30(%r14)
   mov0x10(%r14),%rbp
   shl$0x20,%rbp
   mov(%r14),%rbx
   mov%ebx,%ebx
   mov%rbx,(%r14)
   or %rbx,%rbp
   mov%rbp,0x10(%r14)
   mov%rbp,0x90(%r14)
   mov0x60(%r14),%rbx
   mov%rbx,0x38(%r14)
   mov0x28(%r14),%rbx
   mov$0x4000220e60,%r12
   mov%rbx,(%r12)
   mov$0x40002219c8,%rbx
   mov%rbp,(%rbx)
   mov0x20(%r14),%rbp
   sub$0x8,%rbp
   mov$0x404a16,%rbx
   mov%rbx,0x0(%rbp)
   mov%rbp,0x20(%r14)
   mov$0x19,%ebp
   mov%ebp,0xa8(%r14)
   mov$0x415110,%rbp
   mov%rbp,0x80(%r14)
   xor%eax,%eax
   jmpq   0x7ffbebcae426
   lea-0x5f6d72a(%rip),%rax# 0x7ffbe3d437b3
   jmpq   0x7ffbebcae426

Cc: Richard Henderson r...@twiddle.net
Signed-off-by: Aurelien Jarno aurel...@aurel32.net
---
 tcg/optimize.c | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/tcg/optimize.c b/tcg/optimize.c
index e69ab05..2d3c72b 100644
--- a/tcg/optimize.c
+++ b/tcg/optimize.c
@@ -230,11 +230,6 @@ static void tcg_opt_gen_mov(TCGContext *s, TCGOp *op, 
TCGArg *args,
 return;
 }
 
-if (temp_is_const(src)) {
-tcg_opt_gen_movi(s, op, args, dst, temps[src].val);
-return;
-}
-
 TCGOpcode new_op = op_to_mov(op-opc);
 tcg_target_ulong mask;
 
@@ -248,14 +243,13 @@ static void tcg_opt_gen_mov(TCGContext *s, TCGOp *op, 
TCGArg *args,
 }
 temps[dst].mask = mask;
 
-assert(!temp_is_const(src));
-
 if (s-temps[src].type == s-temps[dst].type) {
 temps[dst].next_copy = temps[src].next_copy;
 temps[dst].prev_copy = src;
 temps[temps[dst].next_copy].prev_copy = dst;
 temps[src].next_copy = dst;
-temps[dst].is_const = false;
+temps[dst].is_const = temps[src].is_const;
+temps[dst].val = temps[src].val;
 }
 
 args[0] = dst;
-- 
2.1.4

Re: [Qemu-devel] [PATCH V4 2/3] virtio-blk: fail get_features when both scsi and 1.0 were set

On Mon, Jul 27, 2015 at 12:28:23PM +0200, Paolo Bonzini wrote:
 
 
 On 27/07/2015 11:49, Jason Wang wrote:
  +if (__virtio_has_feature(features, VIRTIO_F_VERSION_1)) {
 
 No double underscores in userspace code.  Longstanding so it can be
 fixed after 2.4 is out---but please remember to do it.
 
  +if (s-conf.scsi) {
  +error_setg(errp, Virtio 1.0 does not support scsi 
  passthrough!);
 
 Unclear error message, as one would expect SCSI passthrough not to work
 anyway for e.g. a disk backed by a file.

Right - so I suggested:
Virtio modern does not support scsi passthrough - please set 
disable-modern=on or switch to virtio-scsi.
With that change - ACK?

 
 It's not a big deal as long as you will disable VIRTIO_BLK_F_SCSI by
 default in the same release that enables VIRTIO_F_VERSION_1 by default.
 
 Paolo
  +return 0;
  +}
  +virtio_add_feature(features, VIRTIO_F_ANY_LAYOUT);
  +} else {
  +virtio_add_feature(features, VIRTIO_BLK_F_SCSI);
  +}

Re: [Qemu-devel] [PATCH v2 for-2.5 05/12] tcg/optimize: track const/copy status separately



On 27/07/2015 12:56, Aurelien Jarno wrote:
  temps[dst].next_copy = temps[src].next_copy;
  temps[dst].prev_copy = src;
  temps[temps[dst].next_copy].prev_copy = dst;
  temps[src].next_copy = dst;

This is:

dst-next = src-next;
dst-prev = src;
dst-next-prev = dst;
src-next = dst;

which seems weird.  I think it should be one of

/* splice src after dst */
dst-next-prev = src-prev;
src-prev-next = dst-next;
dst-next = src;
src-prev = dst;

or

/* splice src before dst */
last = src-prev;
dst-prev-next = src;
src-prev = dst-prev;
last-next = dst;
dst-prev = last;

(written as pointer manipulations for clarity).

Maybe I'm missing the obvious, but if it's a problem it's better to fix
it before the links are used more pervasively.

Paolo

Re: [Qemu-devel] [PATCH] vhost-scsi: Fix mask index err in vhost_scsi_start



On 27/07/2015 13:11, Gonglei wrote:
 On 2015/7/27 18:20, Paolo Bonzini wrote:


 On 27/07/2015 08:25, arei.gong...@huawei.com wrote:
 +++ b/hw/scsi/vhost-scsi.c
 @@ -117,7 +117,7 @@ static int vhost_scsi_start(VHostSCSI *s)
   * enabling/disabling irqfd.
   */
  for (i = 0; i  s-dev.nvqs; i++) {
 -vhost_virtqueue_mask(s-dev, vdev, i, false);
 +vhost_virtqueue_mask(s-dev, vdev, s-dev.vq_index + i, false);
  }
  
  return ret;

 Is this fixing an actual bug, or just using the API correctly?
 s-dev.vq_index is always 0, right?

 Yes.  At present, we found that s-dev.vq_index is always 0.

Ok, then I've applied the patch with this commit message:

vhost_virtqueue_mask takes an absolute virtqueue index, while the
code looks like it's passing an index that is relative to
s-dev.vq_index.  In reality, s-dev.vq_index is always zero, so
this patch does not make any difference, but the code is clearer.

Paolo

Re: [Qemu-devel] [PATCH 0/4] hw/net: fix m68/ColdFire ethernet fec support

On Fri, Jun 26, 2015 at 03:27:12PM +1000, g...@uclinux.org wrote:
 
 The following set of patches fixes the emulated ColdFire ethernet fec
 driver. There is primarily two problems that need to be fixed.
 
 1. The emulated driver needs to support probing of an attached phy.
It is strait forward to emulate an attached phy, but to avoid using
magic numbers I have factored out the common MII register and value
definitions into their own mii.h file first.
 
 2. Fix the fec driver receiver to return the correct value.
 
 With these changes in place the qemu m5208evb board emulation can probe,
 identify and use the fec ethernet running a Linux guest.
 
 
  hw/net/mcf_fec.c|   54 ++--
  include/hw/net/allwinner_emac.h |   40 -
  include/hw/net/mii.h|   76 
 
  3 files changed, 128 insertions(+), 42 deletions(-)
 
 

Thanks, applied to my net tree:
https://github.com/stefanha/qemu/commits/net

Stefan


pgprln19uDKEY.pgp
Description: PGP signature

Re: [Qemu-devel] [PATCH 0/9] For QEMU 2.5: Add a net filter and a netbuffer plugin based on the filter

2015-07-27 Thread Yang Hongyang


Hi,

  Thank you for the comment!

On 07/27/2015 06:32 PM, Daniel P. Berrange wrote:

On Sun, Jul 26, 2015 at 10:13:55PM +0800, Yang Hongyang wrote:

[...]

Which is a little verbose for 'netdev' option.


It's just the name diffrence, using netfilter will be
-netfilter ... -netfilter ...

using plugin=xxx will make us hard to extend the plugin params under existing
netdev design thus will needs lots of extra effort to archive our goal, but we
already have a simple way, do we? and do note that Daniel's concern was based
on my initial RFC patch, which has a usage about plugin=xxx, this series
is totally different.


The current -netdev / netdev_add/netdev_del interfaces have a fairly
static view of the world. If you just want to setup filters at the
time you setup the guest NIC that's fine, but if you want to be able
to dynamically change the filters that are used, without altering
the guest device or the real host backend, I think you're going to
run into problems using -netdev. eg consider you have a pre-exisiting
guest running and you want to add in a 'dump' filter to temporarily
record traffic to a file, without having any impact on guest
connectivity. I'm not seeing how you could achieve that with the
proposed netdev approach, because you'd basically have to delete the
existing NIC and add a new one from scratch.


We will modify the NIC's peer when using netdev_add to add the filter.
The current netdev_add/netdev_del can be used while guest is running.
just to make sure netdev's init/cleanup can do the right thing.



Regards,
Daniel



--
Thanks,
Yang.

Re: [Qemu-devel] [Qemu-stable] [PULL 0/3] Cve 2015 5154 patches



On 07/27/2015 08:10 AM, Stefan Priebe - Profihost AG wrote:
 
 Am 27.07.2015 um 14:01 schrieb John Snow:
 The following changes since commit f793d97e454a56d17e404004867985622ca1a63b:

   Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into 
 staging (2015-07-24 13:07:10 +0100)

 are available in the git repository at:

   https://github.com/jnsnow/qemu.git tags/cve-2015-5154-pull-request
 
 Any details on this CVE? Is RCE possible? Only if IDE is used?
 
 Stefan
 

It's a heap overflow. The most likely outcome is a segfault, but the
guest is allowed to continue writing past the end of the PIO buffer at
its leisure. This makes it similar to CVE-2015-3456.

This CVE can be mitigated unlike CVE-2015-3456 by just removing the
CD-ROM drive until the patch can be applied.

 for you to fetch changes up to cb72cba83021fa42719e73a5249c12096a4d1cfc:

   ide: Clear DRQ after handling all expected accesses (2015-07-26 23:42:53 
 -0400)

 

 

 Kevin Wolf (3):
   ide: Check array bounds before writing to io_buffer (CVE-2015-5154)
   ide/atapi: Fix START STOP UNIT command completion
   ide: Clear DRQ after handling all expected accesses

  hw/ide/atapi.c |  1 +
  hw/ide/core.c  | 32 
  2 files changed, 29 insertions(+), 4 deletions(-)

[Qemu-devel] [PULL for-2.4 02/16] hw/net: add ANLPAR bit definitions to generic mii

From: Greg Ungerer g...@uclinux.org

Add a base set of bit definitions for the standard MII phy Auto-Negotiation
Link Partner Ability Register (ANLPAR).

The original definitions moved into mii.h from the allwinner_emac driver
did not define these.

Signed-off-by: Greg Ungerer g...@uclinux.org
Reviewed-by: Stefan Hajnoczi stefa...@redhat.com
Message-id: 1435296436-12152-3-git-send-email-g...@uclinux.org
Signed-off-by: Stefan Hajnoczi stefa...@redhat.com
---
 include/hw/net/mii.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/include/hw/net/mii.h b/include/hw/net/mii.h
index 4d93114..cd2a4e2 100644
--- a/include/hw/net/mii.h
+++ b/include/hw/net/mii.h
@@ -57,6 +57,13 @@
 #define MII_ANAR_10 (1  5)
 #define MII_ANAR_CSMACD (1  0)
 
+#define MII_ANLPAR_ACK  (1  14)
+#define MII_ANLPAR_TXFD (1  8)
+#define MII_ANLPAR_TX   (1  7)
+#define MII_ANLPAR_10FD (1  6)
+#define MII_ANLPAR_10   (1  5)
+#define MII_ANLPAR_CSMACD   (1  0)
+
 /* List of vendor identifiers */
 #define RTL8201CP_PHYID10x
 #define RTL8201CP_PHYID20x8201
-- 
2.4.3

Re: [Qemu-devel] [PATCH RFC v2 21/47] qapi: New QAPISchema intermediate reperesentation

On 07/27/2015 03:23 AM, Markus Armbruster wrote:


 Create a bunch of classes to represent QAPI schemata.

 Have the QAPISchema initializer call the parser, then walk the syntax
 tree to create the new internal representation, and finally perform
 semantic analysis.


 +class QAPISchemaObjectTypeVariant(QAPISchemaObjectTypeMember):
 +def __init__(self, name, typ, flat):
 +QAPISchemaObjectTypeMember.__init__(self, name, typ, False)
 +assert isinstance(flat, bool)
 +self.flat = flat
 +def check(self, schema, tag_type, seen):
 +QAPISchemaObjectTypeMember.check(self, schema, [], seen)
 +assert self.name in tag_type.values
 +if self.flat:
 +self.type.check(schema)
 +assert isinstance(self.type, QAPISchemaObjectType)

 Do we really want to be tracking self.flat for each variant?  After all,
 docs/qapi-code-gen.txt already describes the mapping from simple union
 into flat union (as if the flat union had a base class with single
 member 'kind' of the right type, then each branch of the union composed
 of an implicit object with a lone member 'data' of the correct type).
 In other words, is it any better to just normalize into that form now,
 such that each QAPISchemaObjectTypeVariant is merely a (often
 one-element) list of name:type members being added to the overall
 QAPISchemaObject?
 
 I tried to do exactly that, but got bogged down in special cases and
 copped out.  Then I went on vacation, and now I don't remember the exact
 problems anymore %-}
 
 I guess / hope it's just relatively pointless differences in the
 generated C code I didn't want to get rid of at this time.  The series
 is long and hairy enough as it is...
 
But I guess it remains to be seen how you use
 self.flat before knowing if it is worth normalizing away from it.
 
 At least introspect.json is oblivious of it.

Yeah, that was my conclusion by the end of the series - we still had
enough special cases where we generate different code for simple unions
than for flat unions. It would be possible to merge the generator and
simplify things further, but at this point, it is best done as a
follow-up series because it will touch lots of C code (anything that
uses a simple union would have to convert to the common representation).

And you actually did reference .flat in the patch that first added
qapi-introspect.py (good that it did not leak to the introspection
output, but it did have to be considered when figuring out what to
output); again, something you may want to rework before polishing this
into v3, or something you may end up just documenting as a possible
cleanup for a future series. But after having reviewed the whole series
now, I'm able to live with your use of .flat, if only because it makes
the initial conversion faster.

 +
 +def lookup_entity(self, name, typ=None):
 +ent = self.entity_dict.get(name)
 +if typ and not isinstance(ent, typ):
 +return None
 +return ent

 Ah, so you enforce a shared namespace between types, commands, and
 events (all three are in self.entity_dict), but can use the typ
 parameter to allow limiting a lookup to just types.
 
 Yes.  It's a convenience feature.

Documentation comments never hurt :) (You did mention in the cover
letter that part of the reason this was still RFC was that it was
lacking documentation)

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH for-2.5] rcu: Allow calling rcu_(un)register_thread() during synchronize_rcu()



On 27/07/2015 12:44, Wen Congyang wrote:
   * rcu_register_thread() may add nodes to registry; it will not
   * wake up synchronize_rcu, but that is okay because at least 
  another
   * thread must exit its RCU read-side critical section before
   * synchronize_rcu is done.  The next iteration of the loop will
   * process the new thread or set -waiting for it.  Hence, this can
   * at worst cause synchronize_rcu() to wait for longer.
 I don't understand this. The next iteration of the loop will move the new 
 thread's
 rcu_reader from registry to qsreaders even if we call rcu_read_lock() in the 
 new thread.
 Because rcu_gp_ongoing() will return false.

You're right.  This proves that a comment was necessary! :)

Second try:

 * rcu_register_thread() may add nodes to registry; it will not
 * wake up synchronize_rcu, but that is okay because at least another
 * thread must exit its RCU read-side critical section before
 * synchronize_rcu is done.  The next iteration of the loop will
 * move the new thread's rcu_reader from registry to qsreaders,
 * because rcu_gp_ongoing() will return false.

Paolo

Re: [Qemu-devel] [Qemu-stable] [PULL 0/3] Cve 2015 5154 patches

2015-07-27 Thread Stefan Priebe - Profihost AG


Am 27.07.2015 um 14:01 schrieb John Snow:
 The following changes since commit f793d97e454a56d17e404004867985622ca1a63b:
 
   Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into 
 staging (2015-07-24 13:07:10 +0100)
 
 are available in the git repository at:
 
   https://github.com/jnsnow/qemu.git tags/cve-2015-5154-pull-request

Any details on this CVE? Is RCE possible? Only if IDE is used?

Stefan

 for you to fetch changes up to cb72cba83021fa42719e73a5249c12096a4d1cfc:
 
   ide: Clear DRQ after handling all expected accesses (2015-07-26 23:42:53 
 -0400)
 
 
 
 
 
 Kevin Wolf (3):
   ide: Check array bounds before writing to io_buffer (CVE-2015-5154)
   ide/atapi: Fix START STOP UNIT command completion
   ide: Clear DRQ after handling all expected accesses
 
  hw/ide/atapi.c |  1 +
  hw/ide/core.c  | 32 
  2 files changed, 29 insertions(+), 4 deletions(-)

Re: [Qemu-devel] [PATCH RFC v2 14/47] qapi-tests: New tests for union, alternate command arguments

On 07/27/2015 01:50 AM, Markus Armbruster wrote:

 This, on the other hand, seems valid from the wire format (it will
 always be a dictionary).  I guess the problem is that we generate a C
 function signature based by calling out each member of the dictionary -
 but how do you do that for a union?
 
 Exactly: the problem is neither conceptual nor the wire API, it's the C
 API we generate.
 
  So I see what you are doing:
 marking that this test currently passes the parser, but then causes
 problems for generating C code, so we should either reject it up front,
 or fix the generator.  The FIXME documents what you will do later in the
 series (reject it up front)
 
 Yes, in PATCH 15.
 
 and the TODO documents what we can do down
 the road (fix the generator to allow it).
 
 I figure we'd change the C API not to explode the data type into
 multiple parameters.  We can consider that when we have a use for it.
 
 See also 32/47 - events have the same problem.
 
 I'm afraid I don't see the connection to PATCH 32.

Patch 32 was where I figured out that we have the same problem where the
C code we generate for an event will break if an event tries to use a
union type as its data dictionary; and therefore, this patch would be an
ideal time to add a test for that, and patch 15 would be an ideal time
to tweak events to not allow unions (as the simple fix, where someday
down the road we may relax things to allow unions in both commands and
events).

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH V4 3/3] virtio-blk: only clear VIRTIO_F_ANY_LAYOUT for legacy device

2015-07-27 Thread Cornelia Huck

On Mon, 27 Jul 2015 14:22:37 +0300
Michael S. Tsirkin m...@redhat.com wrote:

 On Mon, Jul 27, 2015 at 12:30:19PM +0200, Paolo Bonzini wrote:
  
  
  On 27/07/2015 11:49, Jason Wang wrote:
   So this patch only clear VIRTIO_F_LAYOUT for legacy device.
   
   Cc: Stefan Hajnoczi stefa...@redhat.com
   Cc: Kevin Wolf kw...@redhat.com
   Cc: qemu-bl...@nongnu.org
   Signed-off-by: Jason Wang jasow...@redhat.com
   ---
hw/block/virtio-blk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
   
   diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c
   index 9acbc3a..1d3f26c 100644
   --- a/hw/block/virtio-blk.c
   +++ b/hw/block/virtio-blk.c
   @@ -731,7 +731,6 @@ static uint64_t virtio_blk_get_features(VirtIODevice 
   *vdev, uint64_t features,
virtio_add_feature(features, VIRTIO_BLK_F_GEOMETRY);
virtio_add_feature(features, VIRTIO_BLK_F_TOPOLOGY);
virtio_add_feature(features, VIRTIO_BLK_F_BLK_SIZE);
   -virtio_clear_feature(features, VIRTIO_F_ANY_LAYOUT);
if (__virtio_has_feature(features, VIRTIO_F_VERSION_1)) {
if (s-conf.scsi) {
error_setg(errp, Virtio 1.0 does not support scsi 
   passthrough!);
   @@ -739,6 +738,7 @@ static uint64_t virtio_blk_get_features(VirtIODevice 
   *vdev, uint64_t features,
}
virtio_add_feature(features, VIRTIO_F_ANY_LAYOUT);
} else {
   +virtio_clear_feature(features, VIRTIO_F_ANY_LAYOUT);
virtio_add_feature(features, VIRTIO_BLK_F_SCSI);
}
  
  This patch is unnecessary, since the feature is added back below under
  if (__virtio_has_feature(features, VIRTIO_F_VERSION_1)).
  
  Paolo
 
 It's needed so we can apply
 virtio: set any_layout in virtio core

So what's the plan on all those virtio feature patches? It's hard to
keep track about what is based upon what, and what the end result looks
like. I don't have a good feeling about doing this that late in the 2.4
cycle.

[Qemu-devel] [PATCH] megasas: Add write function to handle write access to PCI BAR 3

2015-07-27 Thread Salva Peiró

This patch fixes a QEMU SEGFAULT when a write operation is performed on
the memory region of the PCI BAR 3 (base address space).
When a writeb(0xe000) is performed the .write function is invoked to
handle the write access, however, since the .write is not initialised,
the call to 0, causes QEMU to SEGFAULT.

Signed-off-by: Salva Peiró speir...@gmail.com
---
 hw/scsi/megasas.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/hw/scsi/megasas.c b/hw/scsi/megasas.c
index 51ba9e0..a04369c 100644
--- a/hw/scsi/megasas.c
+++ b/hw/scsi/megasas.c
@@ -2202,8 +2202,15 @@ static uint64_t megasas_queue_read(void *opaque, hwaddr 
addr,
 return 0;
 }
 
+static void megasas_queue_write(void *opaque, hwaddr addr,
+   uint64_t val, unsigned size)
+{
+return;
+}
+
 static const MemoryRegionOps megasas_queue_ops = {
 .read = megasas_queue_read,
+.write = megasas_queue_write,
 .endianness = DEVICE_LITTLE_ENDIAN,
 .impl = {
 .min_access_size = 8,
-- 
2.1.4

[Qemu-devel] [PULL for-2.4 09/16] etsec: Move etsec_can_receive into etsec_receive

From: Fam Zheng f...@redhat.com

When etsec_reset returns 0, peer would queue the packet as if
.can_receive returns false. Drop etsec_can_receive and let etsec_receive
carry the semantics.

Signed-off-by: Fam Zheng f...@redhat.com
Reviewed-by: Stefan Hajnoczi stefa...@redhat.com
Reviewed-by: Jason Wang jasow...@redhat.com
Message-id: 143693-22791-6-git-send-email-f...@redhat.com
Signed-off-by: Stefan Hajnoczi stefa...@redhat.com
---
 hw/net/fsl_etsec/etsec.c | 11 +--
 hw/net/fsl_etsec/etsec.h |  2 +-
 hw/net/fsl_etsec/rings.c | 14 --
 3 files changed, 10 insertions(+), 17 deletions(-)

diff --git a/hw/net/fsl_etsec/etsec.c b/hw/net/fsl_etsec/etsec.c
index c57365f..f5170ae 100644
--- a/hw/net/fsl_etsec/etsec.c
+++ b/hw/net/fsl_etsec/etsec.c
@@ -338,13 +338,6 @@ static void etsec_reset(DeviceState *d)
 MII_SR_100X_FD_CAPS | MII_SR_100T4_CAPS;
 }
 
-static int etsec_can_receive(NetClientState *nc)
-{
-eTSEC *etsec = qemu_get_nic_opaque(nc);
-
-return etsec-rx_buffer_len == 0;
-}
-
 static ssize_t etsec_receive(NetClientState *nc,
  const uint8_t  *buf,
  size_t  size)
@@ -355,8 +348,7 @@ static ssize_t etsec_receive(NetClientState *nc,
 fprintf(stderr, %s receive size:%d\n, etsec-nic-nc.name, size);
 qemu_hexdump(buf, stderr, , size);
 #endif
-etsec_rx_ring_write(etsec, buf, size);
-return size;
+return etsec_rx_ring_write(etsec, buf, size);
 }
 
 
@@ -370,7 +362,6 @@ static void etsec_set_link_status(NetClientState *nc)
 static NetClientInfo net_etsec_info = {
 .type = NET_CLIENT_OPTIONS_KIND_NIC,
 .size = sizeof(NICState),
-.can_receive = etsec_can_receive,
 .receive = etsec_receive,
 .link_status_changed = etsec_set_link_status,
 };
diff --git a/hw/net/fsl_etsec/etsec.h b/hw/net/fsl_etsec/etsec.h
index 78d2c57..fc41773 100644
--- a/hw/net/fsl_etsec/etsec.h
+++ b/hw/net/fsl_etsec/etsec.h
@@ -162,7 +162,7 @@ DeviceState *etsec_create(hwaddrbase,
 
 void etsec_walk_tx_ring(eTSEC *etsec, int ring_nbr);
 void etsec_walk_rx_ring(eTSEC *etsec, int ring_nbr);
-void etsec_rx_ring_write(eTSEC *etsec, const uint8_t *buf, size_t size);
+ssize_t etsec_rx_ring_write(eTSEC *etsec, const uint8_t *buf, size_t size);
 
 void etsec_write_miim(eTSEC  *etsec,
   eTSEC_Register *reg,
diff --git a/hw/net/fsl_etsec/rings.c b/hw/net/fsl_etsec/rings.c
index d4a494f..a11280b 100644
--- a/hw/net/fsl_etsec/rings.c
+++ b/hw/net/fsl_etsec/rings.c
@@ -481,40 +481,42 @@ static void rx_init_frame(eTSEC *etsec, const uint8_t 
*buf, size_t size)
etsec-rx_buffer_len, etsec-rx_padding);
 }
 
-void etsec_rx_ring_write(eTSEC *etsec, const uint8_t *buf, size_t size)
+ssize_t etsec_rx_ring_write(eTSEC *etsec, const uint8_t *buf, size_t size)
 {
 int ring_nbr = 0;   /* Always use ring0 (no filer) */
 
 if (etsec-rx_buffer_len != 0) {
 RING_DEBUG(%s: We can't receive now,
 a buffer is already in the pipe\n, __func__);
-return;
+return 0;
 }
 
 if (etsec-regs[RSTAT].value  1  (23 - ring_nbr)) {
 RING_DEBUG(%s: The ring is halted\n, __func__);
-return;
+return -1;
 }
 
 if (etsec-regs[DMACTRL].value  DMACTRL_GRS) {
 RING_DEBUG(%s: Graceful receive stop\n, __func__);
-return;
+return -1;
 }
 
 if (!(etsec-regs[MACCFG1].value  MACCFG1_RX_EN)) {
 RING_DEBUG(%s: MAC Receive not enabled\n, __func__);
-return;
+return -1;
 }
 
 if ((etsec-regs[RCTRL].value  RCTRL_RSF)  (size  60)) {
 /* CRC is not in the packet yet, so short frame is below 60 bytes */
 RING_DEBUG(%s: Drop short frame\n, __func__);
-return;
+return -1;
 }
 
 rx_init_frame(etsec, buf, size);
 
 etsec_walk_rx_ring(etsec, ring_nbr);
+
+return size;
 }
 
 void etsec_walk_rx_ring(eTSEC *etsec, int ring_nbr)
-- 
2.4.3

[Qemu-devel] [PULL for-2.4 12/16] milkymist-minimac2: Flush queued packets when link comes up

From: Fam Zheng f...@redhat.com

Drop .can_receive and move the semantics into minimac2_rx, by returning
0.

That is once minimac2_rx returns 0, incoming packets will be queued
until the queue is explicitly flushed. We do this when s-regs[R_STATE0]
or s-regs[R_STATE1] is changed in minimac2_write.

Also drop the unused trace point.

Signed-off-by: Fam Zheng f...@redhat.com
Reviewed-by: Jason Wang jasow...@redhat.com
Reviewed-by: Stefan Hajnoczi stefa...@redhat.com
Message-id: 143693-22791-9-git-send-email-f...@redhat.com
Signed-off-by: Stefan Hajnoczi stefa...@redhat.com
---
 hw/net/milkymist-minimac2.c | 33 -
 trace-events|  1 -
 2 files changed, 16 insertions(+), 18 deletions(-)

diff --git a/hw/net/milkymist-minimac2.c b/hw/net/milkymist-minimac2.c
index f06afaa..5d1cf08 100644
--- a/hw/net/milkymist-minimac2.c
+++ b/hw/net/milkymist-minimac2.c
@@ -303,8 +303,7 @@ static ssize_t minimac2_rx(NetClientState *nc, const 
uint8_t *buf, size_t size)
 r_state = R_STATE1;
 rx_buf = s-rx1_buf;
 } else {
-trace_milkymist_minimac2_drop_rx_frame(buf);
-return size;
+return 0;
 }
 
 /* assemble frame */
@@ -354,6 +353,18 @@ minimac2_read(void *opaque, hwaddr addr, unsigned size)
 return r;
 }
 
+static int minimac2_can_rx(MilkymistMinimac2State *s)
+{
+if (s-regs[R_STATE0] == STATE_LOADED) {
+return 1;
+}
+if (s-regs[R_STATE1] == STATE_LOADED) {
+return 1;
+}
+
+return 0;
+}
+
 static void
 minimac2_write(void *opaque, hwaddr addr, uint64_t value,
unsigned size)
@@ -387,6 +398,9 @@ minimac2_write(void *opaque, hwaddr addr, uint64_t value,
 case R_STATE1:
 s-regs[addr] = value;
 update_rx_interrupt(s);
+if (minimac2_can_rx(s)) {
+qemu_flush_queued_packets(qemu_get_queue(s-nic));
+}
 break;
 case R_SETUP:
 case R_COUNT0:
@@ -411,20 +425,6 @@ static const MemoryRegionOps minimac2_ops = {
 .endianness = DEVICE_NATIVE_ENDIAN,
 };
 
-static int minimac2_can_rx(NetClientState *nc)
-{
-MilkymistMinimac2State *s = qemu_get_nic_opaque(nc);
-
-if (s-regs[R_STATE0] == STATE_LOADED) {
-return 1;
-}
-if (s-regs[R_STATE1] == STATE_LOADED) {
-return 1;
-}
-
-return 0;
-}
-
 static void milkymist_minimac2_reset(DeviceState *d)
 {
 MilkymistMinimac2State *s = MILKYMIST_MINIMAC2(d);
@@ -445,7 +445,6 @@ static void milkymist_minimac2_reset(DeviceState *d)
 static NetClientInfo net_milkymist_minimac2_info = {
 .type = NET_CLIENT_OPTIONS_KIND_NIC,
 .size = sizeof(NICState),
-.can_receive = minimac2_can_rx,
 .receive = minimac2_rx,
 };
 
diff --git a/trace-events b/trace-events
index 2d395c5..94bf3bb 100644
--- a/trace-events
+++ b/trace-events
@@ -828,7 +828,6 @@ milkymist_minimac2_mdio_write(uint8_t phy_addr, uint8_t 
addr, uint16_t value) p
 milkymist_minimac2_mdio_read(uint8_t phy_addr, uint8_t addr, uint16_t value) 
phy_addr %02x addr %02x value %04x
 milkymist_minimac2_tx_frame(uint32_t length) length %u
 milkymist_minimac2_rx_frame(const void *buf, uint32_t length) buf %p length 
%u
-milkymist_minimac2_drop_rx_frame(const void *buf) buf %p
 milkymist_minimac2_rx_transfer(const void *buf, uint32_t length) buf %p 
length %d
 milkymist_minimac2_raise_irq_rx(void) Raise IRQ RX
 milkymist_minimac2_lower_irq_rx(void) Lower IRQ RX
-- 
2.4.3

[Qemu-devel] [PULL for-2.4 15/16] dp8393x: Flush packets when link comes up

From: Fam Zheng f...@redhat.com

.can_receive callback changes semantics that once return 0, backend will
try sending again until explicitly flushed, change the device to meet
that.

dp8393x_can_receive checks SONIC_CR_RXEN bit in SONIC_CR register and
SONIC_ISR_RBE bit in SONIC_ISR register, try flushing the queue when
either bit is being updated.

Signed-off-by: Fam Zheng f...@redhat.com
Reviewed-by: Stefan Hajnoczi stefa...@redhat.com
Reviewed-by: Jason Wang jasow...@redhat.com
Message-id: 143693-22791-12-git-send-email-f...@redhat.com
Signed-off-by: Stefan Hajnoczi stefa...@redhat.com
---
 hw/net/dp8393x.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/hw/net/dp8393x.c b/hw/net/dp8393x.c
index cd889bc..451ff72 100644
--- a/hw/net/dp8393x.c
+++ b/hw/net/dp8393x.c
@@ -327,9 +327,14 @@ static void dp8393x_do_stop_timer(dp8393xState *s)
 dp8393x_update_wt_regs(s);
 }
 
+static int dp8393x_can_receive(NetClientState *nc);
+
 static void dp8393x_do_receiver_enable(dp8393xState *s)
 {
 s-regs[SONIC_CR] = ~SONIC_CR_RXDIS;
+if (dp8393x_can_receive(s-nic-ncs)) {
+qemu_flush_queued_packets(qemu_get_queue(s-nic));
+}
 }
 
 static void dp8393x_do_receiver_disable(dp8393xState *s)
@@ -569,6 +574,9 @@ static void dp8393x_write(void *opaque, hwaddr addr, 
uint64_t data,
 dp8393x_do_read_rra(s);
 }
 dp8393x_update_irq(s);
+if (dp8393x_can_receive(s-nic-ncs)) {
+qemu_flush_queued_packets(qemu_get_queue(s-nic));
+}
 break;
 /* Ignore least significant bit */
 case SONIC_RSA:
-- 
2.4.3

[Qemu-devel] [PATCH v2 for-2.5 04/12] tcg/optimize: add temp_is_const and temp_is_copy functions

Add two accessor functions temp_is_const and temp_is_copy, to make the
code more readable and make code change easier.

Cc: Richard Henderson r...@twiddle.net
Signed-off-by: Aurelien Jarno aurel...@aurel32.net
---
 tcg/optimize.c | 131 ++---
 1 file changed, 60 insertions(+), 71 deletions(-)

diff --git a/tcg/optimize.c b/tcg/optimize.c
index 425c14b..719fee2 100644
--- a/tcg/optimize.c
+++ b/tcg/optimize.c
@@ -52,11 +52,21 @@ struct tcg_temp_info {
 static struct tcg_temp_info temps[TCG_MAX_TEMPS];
 static TCGTempSet temps_used;
 
+static inline bool temp_is_const(TCGArg arg)
+{
+return temps[arg].state == TCG_TEMP_CONST;
+}
+
+static inline bool temp_is_copy(TCGArg arg)
+{
+return temps[arg].state == TCG_TEMP_COPY;
+}
+
 /* Reset TEMP's state to TCG_TEMP_UNDEF.  If TEMP only had one copy, remove
the copy flag from the left temp.  */
 static void reset_temp(TCGArg temp)
 {
-if (temps[temp].state == TCG_TEMP_COPY) {
+if (temp_is_copy(temp)) {
 if (temps[temp].prev_copy == temps[temp].next_copy) {
 temps[temps[temp].next_copy].state = TCG_TEMP_UNDEF;
 } else {
@@ -186,8 +196,7 @@ static bool temps_are_copies(TCGArg arg1, TCGArg arg2)
 return true;
 }
 
-if (temps[arg1].state != TCG_TEMP_COPY
-|| temps[arg2].state != TCG_TEMP_COPY) {
+if (!temp_is_copy(arg1) || !temp_is_copy(arg2)) {
 return false;
 }
 
@@ -230,7 +239,7 @@ static void tcg_opt_gen_mov(TCGContext *s, TCGOp *op, 
TCGArg *args,
 return;
 }
 
-if (temps[src].state == TCG_TEMP_CONST) {
+if (temp_is_const(src)) {
 tcg_opt_gen_movi(s, op, args, dst, temps[src].val);
 return;
 }
@@ -248,10 +257,10 @@ static void tcg_opt_gen_mov(TCGContext *s, TCGOp *op, 
TCGArg *args,
 }
 temps[dst].mask = mask;
 
-assert(temps[src].state != TCG_TEMP_CONST);
+assert(!temp_is_const(src));
 
 if (s-temps[src].type == s-temps[dst].type) {
-if (temps[src].state != TCG_TEMP_COPY) {
+if (!temp_is_copy(src)) {
 temps[src].state = TCG_TEMP_COPY;
 temps[src].next_copy = src;
 temps[src].prev_copy = src;
@@ -488,7 +497,7 @@ static bool do_constant_folding_cond_eq(TCGCond c)
 static TCGArg do_constant_folding_cond(TCGOpcode op, TCGArg x,
TCGArg y, TCGCond c)
 {
-if (temps[x].state == TCG_TEMP_CONST  temps[y].state == TCG_TEMP_CONST) {
+if (temp_is_const(x)  temp_is_const(y)) {
 switch (op_bits(op)) {
 case 32:
 return do_constant_folding_cond_32(temps[x].val, temps[y].val, c);
@@ -499,7 +508,7 @@ static TCGArg do_constant_folding_cond(TCGOpcode op, TCGArg 
x,
 }
 } else if (temps_are_copies(x, y)) {
 return do_constant_folding_cond_eq(c);
-} else if (temps[y].state == TCG_TEMP_CONST  temps[y].val == 0) {
+} else if (temp_is_const(y)  temps[y].val == 0) {
 switch (c) {
 case TCG_COND_LTU:
 return 0;
@@ -520,12 +529,10 @@ static TCGArg do_constant_folding_cond2(TCGArg *p1, 
TCGArg *p2, TCGCond c)
 TCGArg al = p1[0], ah = p1[1];
 TCGArg bl = p2[0], bh = p2[1];
 
-if (temps[bl].state == TCG_TEMP_CONST
- temps[bh].state == TCG_TEMP_CONST) {
+if (temp_is_const(bl)  temp_is_const(bh)) {
 uint64_t b = ((uint64_t)temps[bh].val  32) | (uint32_t)temps[bl].val;
 
-if (temps[al].state == TCG_TEMP_CONST
- temps[ah].state == TCG_TEMP_CONST) {
+if (temp_is_const(al)  temp_is_const(ah)) {
 uint64_t a;
 a = ((uint64_t)temps[ah].val  32) | (uint32_t)temps[al].val;
 return do_constant_folding_cond_64(a, b, c);
@@ -551,8 +558,8 @@ static bool swap_commutative(TCGArg dest, TCGArg *p1, 
TCGArg *p2)
 {
 TCGArg a1 = *p1, a2 = *p2;
 int sum = 0;
-sum += temps[a1].state == TCG_TEMP_CONST;
-sum -= temps[a2].state == TCG_TEMP_CONST;
+sum += temp_is_const(a1);
+sum -= temp_is_const(a2);
 
 /* Prefer the constant in second argument, and then the form
op a, a, b, which is better handled on non-RISC hosts. */
@@ -567,10 +574,10 @@ static bool swap_commutative(TCGArg dest, TCGArg *p1, 
TCGArg *p2)
 static bool swap_commutative2(TCGArg *p1, TCGArg *p2)
 {
 int sum = 0;
-sum += temps[p1[0]].state == TCG_TEMP_CONST;
-sum += temps[p1[1]].state == TCG_TEMP_CONST;
-sum -= temps[p2[0]].state == TCG_TEMP_CONST;
-sum -= temps[p2[1]].state == TCG_TEMP_CONST;
+sum += temp_is_const(p1[0]);
+sum += temp_is_const(p1[1]);
+sum -= temp_is_const(p2[0]);
+sum -= temp_is_const(p2[1]);
 if (sum  0) {
 TCGArg t;
 t = p1[0], p1[0] = p2[0], p2[0] = t;
@@ -620,7 +627,7 @@ void tcg_optimize(TCGContext *s)
 
 /* Do copy propagation */
 for (i = nb_oargs; i  nb_oargs + nb_iargs; i++) {
-if (temps[args[i]].state == TCG_TEMP_COPY) {
+if

Re: [Qemu-devel] [PATCH V4 0/3] Set correct blk feature for virtio 1.0



On 27/07/2015 11:49, Jason Wang wrote:
 Hi all:
 
 This series tries to set feature correctly for virtio-blk when virtio
 1.0 is supported. Two isssues were addressed according to the spec:
 
 - scsi passthrough was not support in 1.0. This is done through: 1)
   let get_features() can fail 2) fail the get_features() when both
   scsi and virtio 1.0 is enabled.
 - any layout must be set for transitional device. This is done by set
   any layout when 1.0 is supported.
 
 Changes from V3:
 - rebase on top of Michael's any_layout fixes

With my fixup to the error message,

Acked-by: Paolo Bonzini pbonz...@redhat.com

Paolo

 Changes from V2:
 - Keep scsi=on by default since virtio 1.0 is disabled by default
 - Advertise VIRTIO_BLK_F_SCSI unconditionally if virtio 1.0 is
   disabled
 
 Changes from V1:
 - Split virtio-net changes out of the series
 - Enable VIRTIO_BLK_F_SCSI only when scsi is set
 - Disable scsi by default and compat it for legacy machine types
 - Let get_features() can fail and fail the initialization of
   virito-blk when both 1.0 and scsi were supported.
 
 Jason Wang (3):
   virtio: get_features() can fail
   virtio-blk: fail get_features when both scsi and 1.0 were set
   virtio-blk: only clear VIRTIO_F_ANY_LAYOUT for legacy device
 
  hw/9pfs/virtio-9p-device.c  |  3 ++-
  hw/block/virtio-blk.c   | 15 ---
  hw/char/virtio-serial-bus.c |  3 ++-
  hw/display/virtio-gpu.c |  3 ++-
  hw/input/virtio-input.c |  3 ++-
  hw/net/virtio-net.c |  3 ++-
  hw/scsi/vhost-scsi.c|  3 ++-
  hw/scsi/virtio-scsi.c   |  3 ++-
  hw/virtio/virtio-balloon.c  |  3 ++-
  hw/virtio/virtio-bus.c  |  3 ++-
  hw/virtio/virtio-rng.c  |  2 +-
  include/hw/virtio/virtio.h  |  4 +++-
  12 files changed, 34 insertions(+), 14 deletions(-)

Re: [Qemu-devel] [PATCH v2 for-2.5 05/12] tcg/optimize: track const/copy status separately

On 2015-07-27 13:26, Paolo Bonzini wrote:
 
 
 On 27/07/2015 12:56, Aurelien Jarno wrote:
   temps[dst].next_copy = temps[src].next_copy;
   temps[dst].prev_copy = src;
   temps[temps[dst].next_copy].prev_copy = dst;
   temps[src].next_copy = dst;

Note that the patch doesn't change this part, it's already there in the
original code.

 This is:
 
 dst-next = src-next;
 dst-prev = src;
 dst-next-prev = dst;
 src-next = dst;
 
 which seems weird.  I think it should be one of
 
 /* splice src after dst */
 dst-next-prev = src-prev;
 src-prev-next = dst-next;
 dst-next = src;
 src-prev = dst;
 
 or
 
 /* splice src before dst */
 last = src-prev;
 dst-prev-next = src;
 src-prev = dst-prev;
 last-next = dst;
 dst-prev = last;
 
 (written as pointer manipulations for clarity).
 
 Maybe I'm missing the obvious, but if it's a problem it's better to fix
 it before the links are used more pervasively.

I think your code is the generic for inserting a circular linked list
into another. Here we just want to insert one element, and thus before
the insertion we have dst-next = dst-prev = dst.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Re: [Qemu-devel] [POC] colo-proxy in qemu

2015-07-27 Thread Yang Hongyang

Hi Dave,

Thanks for the comments!

On 07/27/2015 06:40 PM, Dr. David Alan Gilbert wrote:

* Yang Hongyang (yan...@cn.fujitsu.com) wrote:

Hi Jason,

On 07/24/2015 10:12 AM, Jason Wang wrote:

On 07/24/2015 10:04 AM, Dong, Eddie wrote:

Hi Stefan:
Thanks for your comments!

On Mon, Jul 20, 2015 at 02:42:33PM +0800, Li Zhijian wrote:

We are planning to implement colo-proxy in qemu to cache and compare

packets.

I thought there is a kernel module to do that?

Yes, that is the previous solution the COLO sub-community choose to go,
but we realized it might be not the best choices, and thus we want to bring
discussion back here :) More comments are welcome.

Hi:

Could you pls describe more details on this decision? What's the reason
that you realize it was not the best choice?

Below is my opinion:

We realized that there're disadvantages do it in kernel spaces:
1. We need to recompile kernel: the colo-proxy kernel module is
implemented as a nf conntrack extension. Adding a extension need to
modify the extension struct in-kernel, so recompile kernel is needed.

That change is tiny though, so I don't think the change to the kernel
is a big issue (but I'm not a netfilter guy).

(For those following, the patch is:
https://github.com/coloft/colo-proxy/blob/master/patch4kernel/0001-colo-patch-for-kernel.patch
)
The comparison modules are bigger though, but still not massive.

2. We need to recompile iptables/nftables to use together with the colo-proxy
kernel module.

Again, the changes to iptables are small; so I don't think this should
influence it too much.

Yes, these changes are small, but even a small change needs to recompile
the component and reinstall it, for user, it is not friendly...

The bigger problem shown by 12 is that these changes are single-use - just for
COLO, which does make it a little harder to justify.

That's true.

3. Need to configure primary host to forward input packets to secondary as
well as configure secondary to forward output packets to primary host, the
network topology and configuration is too complex for a regular user.

Yes, and that bit is HARD - it took me quite a while to get it right; however,
we'll still need to forward packets between primary and secondary,

If we forward in qemu using a socket connection, a separate forward nic will not
be needed, and all tc stuff will not needed, will make configuration easier I
think.

and all that
hard setup should get rolled into something like libvirt, so perhaps it's not
really
that bad for the user in the end.

You can refer to http://wiki.qemu.org/Features/COLO
to see the network topology and the steps to setup an env.

Setup a test env is too complex. The usability is so important to a feature
like COLO which provide VM FT solution, if fewer people can/willing to
setup the env, the feature is useless. So we decide to develop user space
colo-proxy.

The advantage is obvious,
1. we do not need to recompile kernel.
2. No need to recompile iptables/nftables.
3. we do not need to deal with the network configuration, we just using a
socket connection between 2 QEMUs to forward packets.
4. A complete VM FT solution in one go, we have already developed the block
replication in QEMU, so with the network replication in QEMU, all
components we needed are within QEMU, this is very important, it greatly
improves the usability of COLO feature! We hope it will gain more testers,
users and developers.
5. QEMU will gain a complete VM FT solution and the most advantage FT solution
so far!

Overall, usability is the most important factor that impact our choice.

My biggest worry is your reliance on SLIRP for the TCP/IP stack; it
doesn't get much work done on it and I worry about it's reliability for
using it for the level of complexity you need.

Your current kernel implementation gets all the nf_conntrack stuff for free
which is very powerful.

However, I can see some advantages from doing it in user space; it would
be easier to debug, and possibly easier to configure, and might also be easier
to handle continuous FT (i.e. transferring the state of the proxy to a new COLO
connection).

I think at the moment I'd still prefer kernel space (especially since your
kernel
code now works pretty reliably!)

Another thought; if you're main worry is to do with the complexity of kernel
changes, had you considered looking at the bpf-jit - I'm not sure if it can
do what you need, but perhaps it's worth a look?

Will have a look, thank you!

Dave
P.S. I think 'proxy' is still the right word to describe it rather than
'agency'.

Thanks
.

--
Thanks,
Yang.

--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
.

--
Thanks,
Yang.

Re: [Qemu-devel] [Qemu-stable] [PULL 0/3] Cve 2015 5154 patches

Am 27.07.2015 um 15:25 hat Stefan Priebe - Profihost AG geschrieben:
 
 Am 27.07.2015 um 14:28 schrieb John Snow:
  
  
  On 07/27/2015 08:10 AM, Stefan Priebe - Profihost AG wrote:
 
  Am 27.07.2015 um 14:01 schrieb John Snow:
  The following changes since commit 
  f793d97e454a56d17e404004867985622ca1a63b:
 
Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into 
  staging (2015-07-24 13:07:10 +0100)
 
  are available in the git repository at:
 
https://github.com/jnsnow/qemu.git tags/cve-2015-5154-pull-request
 
  Any details on this CVE? Is RCE possible? Only if IDE is used?
 
  Stefan
 
  
  It's a heap overflow. The most likely outcome is a segfault, but the
  guest is allowed to continue writing past the end of the PIO buffer at
  its leisure. This makes it similar to CVE-2015-3456.
  
  This CVE can be mitigated unlike CVE-2015-3456 by just removing the
  CD-ROM drive until the patch can be applied.
 
 Thanks. The seclist article explicitly references xen. So it does not
 apply to qemu/kvm? Sorry for asking may be stupid questions.

The IDE emulation is shared between Xen and KVM, so both are affected.
The reason why the seclist mail only mentions Xen is probably because
the Xen security team posted it.

Meanwhile there is also a Red Hat CVE page available, which mentions
qemu-kvm: https://access.redhat.com/security/cve/CVE-2015-5154

Kevin

[Qemu-devel] [PULL for-2.4 07/16] eepro100: Drop nic_can_receive

From: Fam Zheng f...@redhat.com

nic_receive already checks the conditions and drop packets if false.
Due to the new semantics since 6e99c63 (net/socket: Drop
net_socket_can_send), having .can_receive returning 0 requires us to
explicitly flush the queued packets when the conditions are becoming
true, but queuing the packets when guest driver is not ready doesn't
make much sense.

Signed-off-by: Fam Zheng f...@redhat.com
Reviewed-by: Stefan Hajnoczi stefa...@redhat.com
Reviewed-by: Jason Wang jasow...@redhat.com
Message-id: 143693-22791-4-git-send-email-f...@redhat.com
Signed-off-by: Stefan Hajnoczi stefa...@redhat.com
---
 hw/net/eepro100.c | 11 ---
 1 file changed, 11 deletions(-)

diff --git a/hw/net/eepro100.c b/hw/net/eepro100.c
index c374c1a..60333b7 100644
--- a/hw/net/eepro100.c
+++ b/hw/net/eepro100.c
@@ -1617,16 +1617,6 @@ static const MemoryRegionOps eepro100_ops = {
 .endianness = DEVICE_LITTLE_ENDIAN,
 };
 
-static int nic_can_receive(NetClientState *nc)
-{
-EEPRO100State *s = qemu_get_nic_opaque(nc);
-TRACE(RXTX, logout(%p\n, s));
-return get_ru_state(s) == ru_ready;
-#if 0
-return !eepro100_buffer_full(s);
-#endif
-}
-
 static ssize_t nic_receive(NetClientState *nc, const uint8_t * buf, size_t 
size)
 {
 /* TODO:
@@ -1844,7 +1834,6 @@ static void pci_nic_uninit(PCIDevice *pci_dev)
 static NetClientInfo net_eepro100_info = {
 .type = NET_CLIENT_OPTIONS_KIND_NIC,
 .size = sizeof(NICState),
-.can_receive = nic_can_receive,
 .receive = nic_receive,
 };
 
-- 
2.4.3

[Qemu-devel] [PULL for-2.4 03/16] hw/net: add simple phy support to mcf_fec driver

From: Greg Ungerer g...@uclinux.org

The Linux fec driver needs at least basic phy support to probe and work.
The current qemu mcf_fec emulation has no support for the reading or
writing of the MDIO lines to access an attached phy.

This code adds a very simple set of register results for a fixed phy
setup - very similar to that used on an m5208evb board. This is enough
to probe and identify an emulated attached phy.

Signed-off-by: Greg Ungerer g...@uclinux.org
Reviewed-by: Stefan Hajnoczi stefa...@redhat.com
Message-id: 1435296436-12152-4-git-send-email-g...@uclinux.org
Signed-off-by: Stefan Hajnoczi stefa...@redhat.com
---
 hw/net/mcf_fec.c | 50 --
 include/hw/net/mii.h |  5 +
 2 files changed, 53 insertions(+), 2 deletions(-)

diff --git a/hw/net/mcf_fec.c b/hw/net/mcf_fec.c
index 0255612..ea59017 100644
--- a/hw/net/mcf_fec.c
+++ b/hw/net/mcf_fec.c
@@ -8,6 +8,7 @@
 #include hw/hw.h
 #include net/net.h
 #include hw/m68k/mcf.h
+#include hw/net/mii.h
 /* For crc32 */
 #include zlib.h
 #include exec/address-spaces.h
@@ -216,6 +217,51 @@ static void mcf_fec_reset(mcf_fec_state *s)
 s-rfsr = 0x500;
 }
 
+#define MMFR_WRITE_OP  (1  28)
+#define MMFR_READ_OP   (2  28)
+#define MMFR_PHYADDR(v)(((v)  23)  0x1f)
+#define MMFR_REGNUM(v) (((v)  18)  0x1f)
+
+static uint64_t mcf_fec_read_mdio(mcf_fec_state *s)
+{
+uint64_t v;
+
+if (s-mmfr  MMFR_WRITE_OP)
+return s-mmfr;
+if (MMFR_PHYADDR(s-mmfr) != 1)
+return s-mmfr |= 0x;
+
+switch (MMFR_REGNUM(s-mmfr)) {
+case MII_BMCR:
+v = MII_BMCR_SPEED | MII_BMCR_AUTOEN | MII_BMCR_FD;
+break;
+case MII_BMSR:
+v = MII_BMSR_100TX_FD | MII_BMSR_100TX_HD | MII_BMSR_10T_FD |
+MII_BMSR_10T_HD | MII_BMSR_MFPS | MII_BMSR_AN_COMP |
+MII_BMSR_AUTONEG | MII_BMSR_LINK_ST;
+break;
+case MII_PHYID1:
+v = DP83848_PHYID1;
+break;
+case MII_PHYID2:
+v = DP83848_PHYID2;
+break;
+case MII_ANAR:
+v = MII_ANAR_TXFD | MII_ANAR_TX | MII_ANAR_10FD |
+MII_ANAR_10 | MII_ANAR_CSMACD;
+break;
+case MII_ANLPAR:
+v = MII_ANLPAR_ACK | MII_ANLPAR_TXFD | MII_ANLPAR_TX |
+MII_ANLPAR_10FD | MII_ANLPAR_10 | MII_ANLPAR_CSMACD;
+break;
+default:
+v = 0x;
+break;
+}
+s-mmfr = (s-mmfr  ~0x) | v;
+return s-mmfr;
+}
+
 static uint64_t mcf_fec_read(void *opaque, hwaddr addr,
  unsigned size)
 {
@@ -226,7 +272,7 @@ static uint64_t mcf_fec_read(void *opaque, hwaddr addr,
 case 0x010: return s-rx_enabled ? (1  24) : 0; /* RDAR */
 case 0x014: return 0; /* TDAR */
 case 0x024: return s-ecr;
-case 0x040: return s-mmfr;
+case 0x040: return mcf_fec_read_mdio(s);
 case 0x044: return s-mscr;
 case 0x064: return 0; /* MIBC */
 case 0x084: return s-rcr;
@@ -287,8 +333,8 @@ static void mcf_fec_write(void *opaque, hwaddr addr,
 }
 break;
 case 0x040:
-/* TODO: Implement MII.  */
 s-mmfr = value;
+s-eir |= FEC_INT_MII;
 break;
 case 0x044:
 s-mscr = value  0xfe;
diff --git a/include/hw/net/mii.h b/include/hw/net/mii.h
index cd2a4e2..9fdd7bb 100644
--- a/include/hw/net/mii.h
+++ b/include/hw/net/mii.h
@@ -65,7 +65,12 @@
 #define MII_ANLPAR_CSMACD   (1  0)
 
 /* List of vendor identifiers */
+/* RealTek 8201 */
 #define RTL8201CP_PHYID10x
 #define RTL8201CP_PHYID20x8201
 
+/* National Semiconductor DP83848 */
+#define DP83848_PHYID1  0x2000
+#define DP83848_PHYID2  0x5c90
+
 #endif /* MII_H */
-- 
2.4.3

Re: [Qemu-devel] [PATCH v4 0/2] QOM: object_property_add() performance improvement

2015-07-27 Thread Daniel P. Berrange

On Tue, Jul 14, 2015 at 12:38:59PM +0300, Pavel Fedin wrote:
 The function originally behaves very badly when adding properties with [*]
 suffix. Normally these are used for numbering IRQ pins. In order to find the
 correct starting number the function started from zero and checked for
 duplicates. This takes incredibly long time with large number of CPUs because
 number of IRQ pins on some architectures (like ARM GICv3) gets multiplied by
 number of CPUs.
 
 The solution is to add one more property which caches last used index so that
 duplication check is not repeated thousands of times. Every time an array is
 expanded the index is picked up from this cache.
 
 The modification decreases qemu startup time with 32 CPUs by a factor of 2
 (~10 sec vs ~20 sec).

10 seconds to start a QEMU with a mere 32 cpus is still a totally
ridiculous amount of time. Do you know why it is still so slow even
after your suggested patch ? Is it still related to the method
object_property_add(), or are there other areas of code with bad
scalability affecting arm ?

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 V4 3/3] virtio-blk: only clear VIRTIO_F_ANY_LAYOUT for legacy device

On Mon, Jul 27, 2015 at 12:30:19PM +0200, Paolo Bonzini wrote:
 
 
 On 27/07/2015 11:49, Jason Wang wrote:
  So this patch only clear VIRTIO_F_LAYOUT for legacy device.
  
  Cc: Stefan Hajnoczi stefa...@redhat.com
  Cc: Kevin Wolf kw...@redhat.com
  Cc: qemu-bl...@nongnu.org
  Signed-off-by: Jason Wang jasow...@redhat.com
  ---
   hw/block/virtio-blk.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)
  
  diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c
  index 9acbc3a..1d3f26c 100644
  --- a/hw/block/virtio-blk.c
  +++ b/hw/block/virtio-blk.c
  @@ -731,7 +731,6 @@ static uint64_t virtio_blk_get_features(VirtIODevice 
  *vdev, uint64_t features,
   virtio_add_feature(features, VIRTIO_BLK_F_GEOMETRY);
   virtio_add_feature(features, VIRTIO_BLK_F_TOPOLOGY);
   virtio_add_feature(features, VIRTIO_BLK_F_BLK_SIZE);
  -virtio_clear_feature(features, VIRTIO_F_ANY_LAYOUT);
   if (__virtio_has_feature(features, VIRTIO_F_VERSION_1)) {
   if (s-conf.scsi) {
   error_setg(errp, Virtio 1.0 does not support scsi 
  passthrough!);
  @@ -739,6 +738,7 @@ static uint64_t virtio_blk_get_features(VirtIODevice 
  *vdev, uint64_t features,
   }
   virtio_add_feature(features, VIRTIO_F_ANY_LAYOUT);
   } else {
  +virtio_clear_feature(features, VIRTIO_F_ANY_LAYOUT);
   virtio_add_feature(features, VIRTIO_BLK_F_SCSI);
   }
 
 This patch is unnecessary, since the feature is added back below under
 if (__virtio_has_feature(features, VIRTIO_F_VERSION_1)).
 
 Paolo

It's needed so we can apply
virtio: set any_layout in virtio core

Re: [Qemu-devel] [PATCH V4 2/3] virtio-blk: fail get_features when both scsi and 1.0 were set

On Mon, Jul 27, 2015 at 12:39:44PM +0200, Cornelia Huck wrote:
 On Mon, 27 Jul 2015 12:28:23 +0200
 Paolo Bonzini pbonz...@redhat.com wrote:
 
  On 27/07/2015 11:49, Jason Wang wrote:
   +if (__virtio_has_feature(features, VIRTIO_F_VERSION_1)) {
  
  No double underscores in userspace code.  Longstanding so it can be
  fixed after 2.4 is out---but please remember to do it.
 
 There's https://marc.info/?l=qemu-develm=142599436726514w=2
 which seems to have been lost in all that virtio rebasing.

Right.
Pls repost after 2.4.

-- 
MST

Re: [Qemu-devel] [PATCH 1/9] netdev: Add a net filter

2015-07-27 Thread Yang Hongyang




On 07/27/2015 08:38 PM, Thomas Huth wrote:

On 24/07/15 12:55, Yang Hongyang wrote:

This patch add a net filter between network backend and NIC devices.
All packets will pass by this filter.
TODO:
   multiqueue support.

 +--+   +-+
   +--+  |filter|   |frontend(NIC)|
   |  peer+--  |   | |
   | network  --+backend   ---+ peer|
   | backend  |  | peer +--- |
   +--+  +--+   +-+

Usage:
   -netdev tap,id=bn0  # you can use whatever backend as needed
   -netdev filter,id=f0,backend=bn0
   -netdev filter-plugin,id=p0,filter=f0
   -device e1000,netdev=f0
NOTE:
   You can attach multiple plugins to the filter, dynamically add/remove
filter and filter-plugin.
   A filter without plugin supplied will do nothing except pass by all
packets, a plugin like dump for example, will dump all packets into a
file. Or other plugins like a netbuffer plugin, will simply buffer the
packets, release the packets when needed.
   You can also implement whatever plugin you needed based on this filter.

Signed-off-by: Yang Hongyang yan...@cn.fujitsu.com


  Hi,

just a quick comment: Please make sure to check your patches with
scripts/checkpatch.pl first before sending them for review - at least
for this patch, the script complains:

ERROR: do not use C99 // comments
#59: FILE: include/net/filter.h:12:
+//#include qapi-types.h

WARNING: braces {} are necessary for all arms of this statement
#424: FILE: net/filter.c:311:
+if (plug-plugin == plugin)
[...]

total: 1 errors, 1 warnings, 463 lines checked


Sorry for not done so this time, will check next time.
Thank you!



  Thomas


.



--
Thanks,
Yang.

Re: [Qemu-devel] [Qemu-stable] [PULL 0/3] Cve 2015 5154 patches

2015-07-27 Thread Peter Lieven


Am 27.07.2015 um 15:38 schrieb Kevin Wolf:

Am 27.07.2015 um 15:25 hat Stefan Priebe - Profihost AG geschrieben:

Am 27.07.2015 um 14:28 schrieb John Snow:


On 07/27/2015 08:10 AM, Stefan Priebe - Profihost AG wrote:

Am 27.07.2015 um 14:01 schrieb John Snow:

The following changes since commit f793d97e454a56d17e404004867985622ca1a63b:

   Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into 
staging (2015-07-24 13:07:10 +0100)

are available in the git repository at:

   https://github.com/jnsnow/qemu.git tags/cve-2015-5154-pull-request

Any details on this CVE? Is RCE possible? Only if IDE is used?

Stefan


It's a heap overflow. The most likely outcome is a segfault, but the
guest is allowed to continue writing past the end of the PIO buffer at
its leisure. This makes it similar to CVE-2015-3456.

This CVE can be mitigated unlike CVE-2015-3456 by just removing the
CD-ROM drive until the patch can be applied.

Thanks. The seclist article explicitly references xen. So it does not
apply to qemu/kvm? Sorry for asking may be stupid questions.

The IDE emulation is shared between Xen and KVM, so both are affected.
The reason why the seclist mail only mentions Xen is probably because
the Xen security team posted it.

Meanwhile there is also a Red Hat CVE page available, which mentions
qemu-kvm: https://access.redhat.com/security/cve/CVE-2015-5154


The redhat advisory says that some Redhat versions are not affected
because they did not backport the upstream commit that introduced this issue .

Can you point out which commit exactly introduced the issue?

Thanks,
Peter

Re: [Qemu-devel] [PATCH v4 2/2] QOM: object_property_add() performance improvement



On 27/07/2015 15:23, Daniel P. Berrange wrote:
 It feels like a poor hack to deal with fact that we've not got support
 for setting non-scalar properties. Since we're representing arrays
 implicitly,

See http://lists.gnu.org/archive/html/qemu-devel/2014-10/msg00623.html:

--
Automatic arrayification isn't about array-valued properties, it's a
convenience feature for creating a bunch of properties with a common
type, accessors and so forth, named in a peculiar way: foo[0],
foo[1], ...

The feature saves the caller the trouble of generating the names.
That's all there is to it.
--

Paolo

[Qemu-devel] [PULL for-2.4 04/16] hw/net: fix mcf_fec driver receiver

From: Greg Ungerer g...@uclinux.org

The network mcf_fec driver emulated receive side method is returning a
result of 0 causing the network layer to disable receive for this emulated
device. This results in the guest only ever receiving one packet.

Fix the recieve side processing to return the number of bytes that we
passed back through to the guest.

Signed-off-by: Greg Ungerer g...@uclinux.org
Reviewed-by: Stefan Hajnoczi stefa...@redhat.com
Message-id: 1435296436-12152-5-git-send-email-g...@uclinux.org
Signed-off-by: Stefan Hajnoczi stefa...@redhat.com
---
 hw/net/mcf_fec.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/hw/net/mcf_fec.c b/hw/net/mcf_fec.c
index ea59017..e63af1b 100644
--- a/hw/net/mcf_fec.c
+++ b/hw/net/mcf_fec.c
@@ -413,6 +413,7 @@ static ssize_t mcf_fec_receive(NetClientState *nc, const 
uint8_t *buf, size_t si
 uint32_t buf_addr;
 uint8_t *crc_ptr;
 unsigned int buf_len;
+size_t retsize;
 
 DPRINTF(do_rx len %d\n, size);
 if (!s-rx_enabled) {
@@ -432,6 +433,7 @@ static ssize_t mcf_fec_receive(NetClientState *nc, const 
uint8_t *buf, size_t si
 flags |= FEC_BD_LG;
 }
 addr = s-rx_descriptor;
+retsize = size;
 while (size  0) {
 mcf_fec_read_bd(bd, addr);
 if ((bd.flags  FEC_BD_E) == 0) {
@@ -476,7 +478,7 @@ static ssize_t mcf_fec_receive(NetClientState *nc, const 
uint8_t *buf, size_t si
 s-rx_descriptor = addr;
 mcf_fec_enable_rx(s);
 mcf_fec_update(s);
-return size;
+return retsize;
 }
 
 static const MemoryRegionOps mcf_fec_ops = {
-- 
2.4.3

[Qemu-devel] [PULL for-2.4 01/16] hw/net: create common collection of MII definitions

From: Greg Ungerer g...@uclinux.org

Create a common set of definitions of address and register values for
ethernet MII phys. A few of the current ethernet drivers have at least
a partial set of these definitions. Others just use hard coded raw
constant numbers.

This initial set is copied directly from the allwinner_emac code.

Signed-off-by: Greg Ungerer g...@uclinux.org
Reviewed-by: Stefan Hajnoczi stefa...@redhat.com
Message-id: 1435296436-12152-2-git-send-email-g...@uclinux.org
Signed-off-by: Stefan Hajnoczi stefa...@redhat.com
---
 include/hw/net/allwinner_emac.h | 40 +-
 include/hw/net/mii.h| 64 +
 2 files changed, 65 insertions(+), 39 deletions(-)
 create mode 100644 include/hw/net/mii.h

diff --git a/include/hw/net/allwinner_emac.h b/include/hw/net/allwinner_emac.h
index 5ae7717..9f21aa7 100644
--- a/include/hw/net/allwinner_emac.h
+++ b/include/hw/net/allwinner_emac.h
@@ -24,6 +24,7 @@
 
 #include net/net.h
 #include qemu/fifo8.h
+#include hw/net/mii.h
 
 #define TYPE_AW_EMAC allwinner-emac
 #define AW_EMAC(obj) OBJECT_CHECK(AwEmacState, (obj), TYPE_AW_EMAC)
@@ -118,45 +119,6 @@
 #define EMAC_RX_IO_DATA_STATUS_OK   (1  7)
 #define EMAC_UNDOCUMENTED_MAGIC 0x0143414d  /* header for RX frames */
 
-/* PHY registers */
-#define MII_BMCR0
-#define MII_BMSR1
-#define MII_PHYID1  2
-#define MII_PHYID2  3
-#define MII_ANAR4
-#define MII_ANLPAR  5
-#define MII_ANER6
-#define MII_NSR 16
-#define MII_LBREMR  17
-#define MII_REC 18
-#define MII_SNRDR   19
-#define MII_TEST25
-
-/* PHY registers fields */
-#define MII_BMCR_RESET  (1  15)
-#define MII_BMCR_LOOPBACK   (1  14)
-#define MII_BMCR_SPEED  (1  13)
-#define MII_BMCR_AUTOEN (1  12)
-#define MII_BMCR_FD (1  8)
-
-#define MII_BMSR_100TX_FD   (1  14)
-#define MII_BMSR_100TX_HD   (1  13)
-#define MII_BMSR_10T_FD (1  12)
-#define MII_BMSR_10T_HD (1  11)
-#define MII_BMSR_MFPS   (1  6)
-#define MII_BMSR_AN_COMP(1  5)
-#define MII_BMSR_AUTONEG(1  3)
-#define MII_BMSR_LINK_ST(1  2)
-
-#define MII_ANAR_TXFD   (1  8)
-#define MII_ANAR_TX (1  7)
-#define MII_ANAR_10FD   (1  6)
-#define MII_ANAR_10 (1  5)
-#define MII_ANAR_CSMACD (1  0)
-
-#define RTL8201CP_PHYID10x
-#define RTL8201CP_PHYID20x8201
-
 /* INT CTL and INT STA registers fields */
 #define EMAC_INT_TX_CHAN(x) (1  (x))
 #define EMAC_INT_RX (1  8)
diff --git a/include/hw/net/mii.h b/include/hw/net/mii.h
new file mode 100644
index 000..4d93114
--- /dev/null
+++ b/include/hw/net/mii.h
@@ -0,0 +1,64 @@
+/*
+ * Common network MII address and register definitions.
+ *
+ * Copyright (C) 2014 Beniamino Galvani b.galv...@gmail.com
+ *
+ * Allwinner EMAC register definitions from Linux kernel are:
+ *   Copyright 2012 Stefan Roese s...@denx.de
+ *   Copyright 2013 Maxime Ripard maxime.rip...@free-electrons.com
+ *   Copyright 1997 Sten Wang
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+#ifndef MII_H
+#define MII_H
+
+/* PHY registers */
+#define MII_BMCR0
+#define MII_BMSR1
+#define MII_PHYID1  2
+#define MII_PHYID2  3
+#define MII_ANAR4
+#define MII_ANLPAR  5
+#define MII_ANER6
+#define MII_NSR 16
+#define MII_LBREMR  17
+#define MII_REC 18
+#define MII_SNRDR   19
+#define MII_TEST25
+
+/* PHY registers fields */
+#define MII_BMCR_RESET  (1  15)
+#define MII_BMCR_LOOPBACK   (1  14)
+#define MII_BMCR_SPEED  (1  13)
+#define MII_BMCR_AUTOEN (1  12)
+#define MII_BMCR_FD (1  8)
+
+#define MII_BMSR_100TX_FD   (1  14)
+#define MII_BMSR_100TX_HD   (1  13)
+#define MII_BMSR_10T_FD (1  12)
+#define MII_BMSR_10T_HD (1  11)
+#define MII_BMSR_MFPS   (1  6)
+#define MII_BMSR_AN_COMP(1  5)
+#define MII_BMSR_AUTONEG(1  3)
+#define MII_BMSR_LINK_ST(1  2)
+
+#define MII_ANAR_TXFD   (1  8)
+#define MII_ANAR_TX (1  7)
+#define MII_ANAR_10FD   (1  6)
+#define MII_ANAR_10 (1  5)
+#define MII_ANAR_CSMACD (1  0)
+
+/* List of vendor identifiers */
+#define RTL8201CP_PHYID10x
+#define RTL8201CP_PHYID20x8201
+
+#endif /* MII_H */
-- 
2.4.3

[Qemu-devel] [PULL for-2.4 05/16] xgmac: Drop packets with eth_can_rx is false.

From: Fam Zheng f...@redhat.com

Signed-off-by: Fam Zheng f...@redhat.com
Reviewed-by: Stefan Hajnoczi stefa...@redhat.com
Reviewed-by: Jason Wang jasow...@redhat.com
Message-id: 143693-22791-2-git-send-email-f...@redhat.com
Signed-off-by: Stefan Hajnoczi stefa...@redhat.com
---
 hw/net/xgmac.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/hw/net/xgmac.c b/hw/net/xgmac.c
index b068f3a..15fb681 100644
--- a/hw/net/xgmac.c
+++ b/hw/net/xgmac.c
@@ -312,10 +312,8 @@ static const MemoryRegionOps enet_mem_ops = {
 .endianness = DEVICE_LITTLE_ENDIAN,
 };
 
-static int eth_can_rx(NetClientState *nc)
+static int eth_can_rx(XgmacState *s)
 {
-XgmacState *s = qemu_get_nic_opaque(nc);
-
 /* RX enabled?  */
 return s-regs[DMA_CONTROL]  DMA_CONTROL_SR;
 }
@@ -329,6 +327,9 @@ static ssize_t eth_rx(NetClientState *nc, const uint8_t 
*buf, size_t size)
 struct desc bd;
 ssize_t ret;
 
+if (!eth_can_rx(s)) {
+return -1;
+}
 unicast = ~buf[0]  0x1;
 broadcast = memcmp(buf, sa_bcast, 6) == 0;
 multicast = !unicast  !broadcast;
@@ -371,7 +372,6 @@ out:
 static NetClientInfo net_xgmac_enet_info = {
 .type = NET_CLIENT_OPTIONS_KIND_NIC,
 .size = sizeof(NICState),
-.can_receive = eth_can_rx,
 .receive = eth_rx,
 };
 
-- 
2.4.3

Re: [Qemu-devel] [PATCH] vhost-scsi: Fix mask index err in vhost_scsi_start

2015-07-27 Thread Gonglei

On 2015/7/27 18:20, Paolo Bonzini wrote:
 
 
 On 27/07/2015 08:25, arei.gong...@huawei.com wrote:
 +++ b/hw/scsi/vhost-scsi.c
 @@ -117,7 +117,7 @@ static int vhost_scsi_start(VHostSCSI *s)
   * enabling/disabling irqfd.
   */
  for (i = 0; i  s-dev.nvqs; i++) {
 -vhost_virtqueue_mask(s-dev, vdev, i, false);
 +vhost_virtqueue_mask(s-dev, vdev, s-dev.vq_index + i, false);
  }
  
  return ret;
 
 Is this fixing an actual bug, or just using the API correctly?
 s-dev.vq_index is always 0, right?
 
Yes.  At present, we found that s-dev.vq_index is always 0.

Regards,
-Gonglei

Re: [Qemu-devel] [PATCH] xen: Drop net_rx_ok

On Mon, Jul 20, 2015 at 06:12:09PM +0100, Stefan Hajnoczi wrote:
 On Thu, Jul 02, 2015 at 01:39:16PM +0100, Stefan Hajnoczi wrote:
  On Tue, Jun 30, 2015 at 10:42:37AM +0800, Fam Zheng wrote:
   This is necessary because once we return false from .can_receive, we
   need to flush the queue when the .can_receive conditions become true
   again, (for example when more buffer is available).
   
   We can rely on net_rx_packet (which checks the same conditions) to drop
   the packet if the device is not ready, so drop net_xen_info.can_receive.
  
  This patch changes behavior:
  
  Previously can_receive() false meant packets are queued.
  
  Now those same conditions result in net_rx_packet() returning -1, so
  packets are discarded.
  
  In order to keep the spirit of the queuing mechanism - where we tell a
  sender to hold off until more rx buffers become available - I think the
  following line in net_rx_packet() needs to be changed:
  
if (rc == rp || RING_REQUEST_CONS_OVERFLOW(netdev-rx_ring, rc)) {
xen_be_printf(netdev-xendev, 2, no buffer, drop packet\n);
return -1;  -- this should be changed to return 0
}
  
  That change assumes that net_event()'s flush is always called when the
  rx ring gets more free space.
  
  Any thoughts from Xen folks?
 
 Ping?

Need input from Xen developers.

Ping?


pgp1oD0mETHph.pgp
Description: PGP signature

Re: [Qemu-devel] [PATCH] virtio-pci: fix memory MR cleanup for modern



On 27/07/2015 15:24, Michael S. Tsirkin wrote:
 +static void virtio_pci_modern_region_unmap(VirtIOPCIProxy *proxy,
 +   VirtIOPCIRegion *region)
 +{
 +memory_region_del_subregion(proxy-modern_bar,
 +region-mr);
 +}
 +
  /* This is called by virtio-bus just after the device is plugged. */
  static void virtio_pci_device_plugged(DeviceState *d, Error **errp)
  {
 @@ -1520,8 +1527,16 @@ static void virtio_pci_device_plugged(DeviceState *d, 
 Error **errp)
  static void virtio_pci_device_unplugged(DeviceState *d)
  {
  VirtIOPCIProxy *proxy = VIRTIO_PCI(d);
 +bool modern = !(proxy-flags  VIRTIO_PCI_FLAG_DISABLE_MODERN);
  
  virtio_pci_stop_ioeventfd(proxy);
 +
 +if (modern) {
 +virtio_pci_modern_region_unmap(proxy, proxy-common);
 +virtio_pci_modern_region_unmap(proxy, proxy-isr);
 +virtio_pci_modern_region_unmap(proxy, proxy-device);
 +virtio_pci_modern_region_unmap(proxy, proxy-notify);
 +}
  }

Actually this is not necessary.  memory_region_del_subregion is only
needed inasmuch as it prevents further guest access to the region, so
it's enough that the toplevel region (the modern_bar itself) is
unmapped.  The PCI core does that automatically.

That said, it's polite to unmap everything, so if you want this patch:

Reviewed-by: Paolo Bonzini pbonz...@redhat.com

Paolo

Re: [Qemu-devel] [PULL 0/3] Cve 2015 5154 patches

2015-07-27 Thread Peter Maydell

On 27 July 2015 at 13:01, John Snow js...@redhat.com wrote:
 The following changes since commit f793d97e454a56d17e404004867985622ca1a63b:

   Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into 
 staging (2015-07-24 13:07:10 +0100)

 are available in the git repository at:

   https://github.com/jnsnow/qemu.git tags/cve-2015-5154-pull-request

 for you to fetch changes up to cb72cba83021fa42719e73a5249c12096a4d1cfc:

   ide: Clear DRQ after handling all expected accesses (2015-07-26 23:42:53 
 -0400)


Applied, thanks.

-- PMM

[Qemu-devel] [PULL for-2.4 08/16] usbnet: Drop usbnet_can_receive

From: Fam Zheng f...@redhat.com

usbnet_receive already drops packet if rndis_state is not
RNDIS_DATA_INITIALIZED, and queues packet if in buffer is not available.
The only difference is s-dev.config but that is similar to rndis_state.

Drop usbnet_can_receive and move these checks to usbnet_receive, so that
we don't need to explicitly flush the queue when s-dev.config changes
value.

Signed-off-by: Fam Zheng f...@redhat.com
Reviewed-by: Stefan Hajnoczi stefa...@redhat.com
Reviewed-by: Jason Wang jasow...@redhat.com
Message-id: 143693-22791-5-git-send-email-f...@redhat.com
Signed-off-by: Stefan Hajnoczi stefa...@redhat.com
---
 hw/usb/dev-network.c | 20 
 1 file changed, 4 insertions(+), 16 deletions(-)

diff --git a/hw/usb/dev-network.c b/hw/usb/dev-network.c
index 5eeb4c6..7800cee 100644
--- a/hw/usb/dev-network.c
+++ b/hw/usb/dev-network.c
@@ -1268,6 +1268,10 @@ static ssize_t usbnet_receive(NetClientState *nc, const 
uint8_t *buf, size_t siz
 uint8_t *in_buf = s-in_buf;
 size_t total_size = size;
 
+if (!s-dev.config) {
+return -1;
+}
+
 if (is_rndis(s)) {
 if (s-rndis_state != RNDIS_DATA_INITIALIZED) {
 return -1;
@@ -1309,21 +1313,6 @@ static ssize_t usbnet_receive(NetClientState *nc, const 
uint8_t *buf, size_t siz
 return size;
 }
 
-static int usbnet_can_receive(NetClientState *nc)
-{
-USBNetState *s = qemu_get_nic_opaque(nc);
-
-if (!s-dev.config) {
-return 0;
-}
-
-if (is_rndis(s)  s-rndis_state != RNDIS_DATA_INITIALIZED) {
-return 1;
-}
-
-return !s-in_len;
-}
-
 static void usbnet_cleanup(NetClientState *nc)
 {
 USBNetState *s = qemu_get_nic_opaque(nc);
@@ -1343,7 +1332,6 @@ static void usb_net_handle_destroy(USBDevice *dev)
 static NetClientInfo net_usbnet_info = {
 .type = NET_CLIENT_OPTIONS_KIND_NIC,
 .size = sizeof(NICState),
-.can_receive = usbnet_can_receive,
 .receive = usbnet_receive,
 .cleanup = usbnet_cleanup,
 };
-- 
2.4.3

[Qemu-devel] [PULL for-2.4 06/16] pcnet: Drop pcnet_can_receive

From: Fam Zheng f...@redhat.com

pcnet_receive already checks the conditions and drop packets if false.
Due to the new semantics since 6e99c63 (net/socket: Drop
net_socket_can_send), having .can_receive returning 0 requires us to
explicitly flush the queued packets when the conditions are becoming
true, but queuing the packets when guest driver is not ready doesn't
make much sense.

Signed-off-by: Fam Zheng f...@redhat.com
Reviewed-by: Stefan Hajnoczi stefa...@redhat.com
Reviewed-by: Jason Wang jasow...@redhat.com
Message-id: 143693-22791-3-git-send-email-f...@redhat.com
Signed-off-by: Stefan Hajnoczi stefa...@redhat.com
---
 hw/net/lance.c | 1 -
 hw/net/pcnet-pci.c | 1 -
 hw/net/pcnet.c | 9 -
 hw/net/pcnet.h | 1 -
 4 files changed, 12 deletions(-)

diff --git a/hw/net/lance.c b/hw/net/lance.c
index 4baa016..780b39d 100644
--- a/hw/net/lance.c
+++ b/hw/net/lance.c
@@ -94,7 +94,6 @@ static const MemoryRegionOps lance_mem_ops = {
 static NetClientInfo net_lance_info = {
 .type = NET_CLIENT_OPTIONS_KIND_NIC,
 .size = sizeof(NICState),
-.can_receive = pcnet_can_receive,
 .receive = pcnet_receive,
 .link_status_changed = pcnet_set_link_status,
 };
diff --git a/hw/net/pcnet-pci.c b/hw/net/pcnet-pci.c
index 8305d1b..b4d60b8 100644
--- a/hw/net/pcnet-pci.c
+++ b/hw/net/pcnet-pci.c
@@ -273,7 +273,6 @@ static void pci_pcnet_uninit(PCIDevice *dev)
 static NetClientInfo net_pci_pcnet_info = {
 .type = NET_CLIENT_OPTIONS_KIND_NIC,
 .size = sizeof(NICState),
-.can_receive = pcnet_can_receive,
 .receive = pcnet_receive,
 .link_status_changed = pcnet_set_link_status,
 };
diff --git a/hw/net/pcnet.c b/hw/net/pcnet.c
index 68b9981..3437376 100644
--- a/hw/net/pcnet.c
+++ b/hw/net/pcnet.c
@@ -995,15 +995,6 @@ static int pcnet_tdte_poll(PCNetState *s)
 return !!(CSR_CXST(s)  0x8000);
 }
 
-int pcnet_can_receive(NetClientState *nc)
-{
-PCNetState *s = qemu_get_nic_opaque(nc);
-if (CSR_STOP(s) || CSR_SPND(s))
-return 0;
-
-return sizeof(s-buffer)-16;
-}
-
 #define MIN_BUF_SIZE 60
 
 ssize_t pcnet_receive(NetClientState *nc, const uint8_t *buf, size_t size_)
diff --git a/hw/net/pcnet.h b/hw/net/pcnet.h
index 79c4c84..dec8de8 100644
--- a/hw/net/pcnet.h
+++ b/hw/net/pcnet.h
@@ -60,7 +60,6 @@ uint32_t pcnet_ioport_readw(void *opaque, uint32_t addr);
 void pcnet_ioport_writel(void *opaque, uint32_t addr, uint32_t val);
 uint32_t pcnet_ioport_readl(void *opaque, uint32_t addr);
 uint32_t pcnet_bcr_readw(PCNetState *s, uint32_t rap);
-int pcnet_can_receive(NetClientState *nc);
 ssize_t pcnet_receive(NetClientState *nc, const uint8_t *buf, size_t size_);
 void pcnet_set_link_status(NetClientState *nc);
 void pcnet_common_init(DeviceState *dev, PCNetState *s, NetClientInfo *info);
-- 
2.4.3

Re: [Qemu-devel] [PATCH RFC v2 24/47] tests/qapi-schema: Convert test harness to QAPISchemaVisitor

2015-07-27 Thread Markus Armbruster

Eric Blake ebl...@redhat.com writes:

 On 07/01/2015 02:22 PM, Markus Armbruster wrote:
 The old code prints the result of parsing (list of expression
 dictionaries), and partial results of semantic analysis (list of enum
 dictionaries, list of struct dictionaries).
 
 The new code prints a trace of a schema visit, i.e. what the back-ends
 are going to use.  Built-in and array types are omitted, because
 they're boring.
 
 Signed-off-by: Markus Armbruster arm...@redhat.com
 ---
  tests/qapi-schema/alternate-good.out|  15 +-
  tests/qapi-schema/comments.out  |   4 +-
  tests/qapi-schema/data-member-array.out |  13 +-
  tests/qapi-schema/empty.out |   3 -
  tests/qapi-schema/enum-empty.out|   4 +-
  tests/qapi-schema/event-case.out|   4 +-
  tests/qapi-schema/flat-union-reverse-define.out |  21 +--
  tests/qapi-schema/ident-with-escape.out |   7 +-
  tests/qapi-schema/include-relpath.out   |   4 +-
  tests/qapi-schema/include-repetition.out|   4 +-
  tests/qapi-schema/include-simple.out|   4 +-
  tests/qapi-schema/indented-expr.out |   7 +-
  tests/qapi-schema/qapi-schema-test.out | 186
 +---
  tests/qapi-schema/returns-int.out   |   5 +-
  tests/qapi-schema/test-qapi.py  |  37 -
  tests/qapi-schema/type-bypass.out   |   7 +-
  16 files changed, 210 insertions(+), 115 deletions(-)

 We have a lot more negative than positive tests of the parser (good
 thing, because that meant fewer .out files to update to the new format).

 No change to actual qemu code, and proves that the previous three
 patches have set up enough of a framework to accurately cover our testsuite.

 
 diff --git a/tests/qapi-schema/alternate-good.out
 b/tests/qapi-schema/alternate-good.out
 index 99848ee..0cbdfa1 100644
 --- a/tests/qapi-schema/alternate-good.out
 +++ b/tests/qapi-schema/alternate-good.out
 @@ -1,6 +1,9 @@
 -[OrderedDict([('struct', 'Data'), ('data', OrderedDict([('*number',
 'int'), ('*name', 'str')]))]),
 - OrderedDict([('enum', 'Enum'), ('data', ['hello', 'world'])]),
 - OrderedDict([('alternate', 'Alt'), ('data', OrderedDict([('value',
 'int'), ('string', 'Enum'), ('struct', 'Data')]))])]
 -[{'enum_name': 'Enum', 'enum_values': ['hello', 'world']},
 - {'enum_name': 'AltKind', 'enum_values': None}]
 -[OrderedDict([('struct', 'Data'), ('data', OrderedDict([('*number',
 'int'), ('*name', 'str')]))])]
 +alternate Alt
 +case value: int flat=False
 +case string: Enum flat=False
 +case struct: Data flat=False

 I'm still not convinced whether we need .flat exposed through this much
 detail, or if we should just normalize plain unions into flat unions
 with implicit structs for each branch.  Changing your design will have
 obvious ripple effects here.

Yes.  I think it's okay as long as we keep it out of external
interfaces.

 +++ b/tests/qapi-schema/data-member-array.out
 @@ -1,5 +1,8 @@
 -[OrderedDict([('enum', 'abc'), ('data', ['a', 'b', 'c'])]),
 - OrderedDict([('struct', 'def'), ('data', OrderedDict([('array',
 ['abc'])]))]),
 - OrderedDict([('command', 'okay'), ('data',
 OrderedDict([('member1', ['int']), ('member2', ['def'])]))])]
 -[{'enum_name': 'abc', 'enum_values': ['a', 'b', 'c']}]
 -[OrderedDict([('struct', 'def'), ('data', OrderedDict([('array',
 ['abc'])]))])]
 +object :obj-okay-args
 +member member1: intList optional=False

 Took me a moment to realize the object is an implicit one (named
 ':obj-okay-args') and not a typo for 'object: obj-okay-args' consistent
 with members being listed 'name: type'.  But not worth changing things,
 as it is sufficiently unambiguous to serve as a valid test.

Perhaps omitting the ':' after member names would be less confusing.

 +object UserDefFlatUnion
 +base UserDefUnionBase
 +tag enum1
 +case value1: UserDefA flat=True
 +case value2: UserDefB flat=True
 +case value3: UserDefB flat=True
 +object UserDefFlatUnion2
 +base UserDefUnionBase
 +tag enum1
 +case value1: UserDefC flat=True
 +case value2: UserDefB flat=True
 +case value3: UserDefA flat=True
 +object UserDefNativeListUnion
 +case integer: intList flat=False
 +case s8: int8List flat=False
 +case s16: int16List flat=False
 +case s32: int32List flat=False
 +case s64: int64List flat=False
 +case u8: uint8List flat=False
 +case u16: uint16List flat=False
 +case u32: uint32List flat=False
 +case u64: uint64List flat=False
 +case number: numberList flat=False
 +case boolean: boolList flat=False
 +case string: strList flat=False
 +case sizes: sizeList flat=False
 +enum UserDefNativeListUnionKind ['integer', 's8', 's16', 's32',
 's64', 'u8', 'u16', 'u32', 'u64', 'number', 'boolean', 'string',
 'sizes']

 Hmm. You are dumping the tag name and type of flat unions, but not of
 simple unions.  I would have expected:

 object

[Qemu-devel] [PATCH v2 for-2.5 11/12] tcg/optimize: do not remember garbage high bits for 32-bit ops

Now that we have real size changing ops, we don't need to mark high
bits of the destination as garbage. The goal of the optimizer is to
predict the value of the temps (and not of the registers) and do
simplifications when possible. The problem there is therefore not the
fact that those bits are not counted as garbage, but that a size
changing op is replaced by a move.

This patch is basically a revert of 24666baf, including the changes that
have been made since then.

Cc: Richard Henderson r...@twiddle.net
Signed-off-by: Aurelien Jarno aurel...@aurel32.net
---
 tcg/optimize.c | 41 +++--
 1 file changed, 11 insertions(+), 30 deletions(-)

diff --git a/tcg/optimize.c b/tcg/optimize.c
index 8f33755..166074e 100644
--- a/tcg/optimize.c
+++ b/tcg/optimize.c
@@ -203,20 +203,12 @@ static bool temps_are_copies(TCGArg arg1, TCGArg arg2)
 static void tcg_opt_gen_movi(TCGContext *s, TCGOp *op, TCGArg *args,
  TCGArg dst, TCGArg val)
 {
-TCGOpcode new_op = op_to_movi(op-opc);
-tcg_target_ulong mask;
-
-op-opc = new_op;
+op-opc = op_to_movi(op-opc);
 
 reset_temp(dst);
 temps[dst].is_const = true;
 temps[dst].val = val;
-mask = val;
-if (TCG_TARGET_REG_BITS  32  new_op == INDEX_op_movi_i32) {
-/* High bits of the destination are now garbage.  */
-mask |= ~0xull;
-}
-temps[dst].mask = mask;
+temps[dst].mask = val;
 
 args[0] = dst;
 args[1] = val;
@@ -230,28 +222,21 @@ static void tcg_opt_gen_mov(TCGContext *s, TCGOp *op, 
TCGArg *args,
 return;
 }
 
-TCGOpcode new_op = op_to_mov(op-opc);
-tcg_target_ulong mask;
-
-op-opc = new_op;
+op-opc = op_to_mov(op-opc);
 
 reset_temp(dst);
-mask = temps[src].mask;
-if (TCG_TARGET_REG_BITS  32  new_op == INDEX_op_mov_i32) {
-/* High bits of the destination are now garbage.  */
-mask |= ~0xull;
-}
-temps[dst].mask = mask;
 
 if (s-temps[src].type == s-temps[dst].type) {
 temps[dst].next_copy = temps[src].next_copy;
 temps[dst].prev_copy = src;
 temps[temps[dst].next_copy].prev_copy = dst;
 temps[src].next_copy = dst;
-temps[dst].is_const = temps[src].is_const;
-temps[dst].val = temps[src].val;
 }
 
+temps[dst].is_const = temps[src].is_const;
+temps[dst].val = temps[src].val;
+temps[dst].mask = temps[src].mask;
+
 args[0] = dst;
 args[1] = src;
 }
@@ -584,7 +569,7 @@ void tcg_optimize(TCGContext *s)
 reset_all_temps(nb_temps);
 
 for (oi = s-gen_first_op_idx; oi = 0; oi = oi_next) {
-tcg_target_ulong mask, partmask, affected;
+tcg_target_ulong mask, affected;
 int nb_oargs, nb_iargs, i;
 TCGArg tmp;
 
@@ -937,17 +922,13 @@ void tcg_optimize(TCGContext *s)
 break;
 }
 
-/* 32-bit ops generate 32-bit results.  For the result is zero test
-   below, we can ignore high bits, but for further optimizations we
-   need to record that the high bits contain garbage.  */
-partmask = mask;
+/* 32-bit ops generate 32-bit results.  */
 if (!(def-flags  TCG_OPF_64BIT)) {
-mask |= ~(tcg_target_ulong)0xu;
-partmask = 0xu;
+mask = 0xu;
 affected = 0xu;
 }
 
-if (partmask == 0) {
+if (mask == 0) {
 assert(nb_oargs == 1);
 tcg_opt_gen_movi(s, op, args, args[0], 0);
 continue;
-- 
2.1.4

[Qemu-devel] [PATCH v2 for-2.5 08/12] tcg: don't abuse TCG type in tcg_gen_trunc_shr_i64_i32

The tcg_gen_trunc_shr_i64_i32 function takes a 64-bit argument and
returns a 32-bit value. Directly call tcg_gen_op3 with the correct
types instead of calling tcg_gen_op3i_i32 and abusing the TCG types.

Reviewed-by: Richard Henderson r...@twiddle.net
Signed-off-by: Aurelien Jarno aurel...@aurel32.net
---
 tcg/tcg-op.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tcg/tcg-op.c b/tcg/tcg-op.c
index 61b64db..0e79fd1 100644
--- a/tcg/tcg-op.c
+++ b/tcg/tcg-op.c
@@ -1752,8 +1752,8 @@ void tcg_gen_trunc_shr_i64_i32(TCGv_i32 ret, TCGv_i64 
arg, unsigned count)
 tcg_temp_free_i64(t);
 }
 } else if (TCG_TARGET_HAS_trunc_shr_i64_i32) {
-tcg_gen_op3i_i32(INDEX_op_trunc_shr_i64_i32, ret,
- MAKE_TCGV_I32(GET_TCGV_I64(arg)), count);
+tcg_gen_op3(tcg_ctx, INDEX_op_trunc_shr_i64_i32,
+GET_TCGV_I32(ret), GET_TCGV_I64(arg), count);
 } else if (count == 0) {
 tcg_gen_mov_i32(ret, MAKE_TCGV_I32(GET_TCGV_I64(arg)));
 } else {
-- 
2.1.4

[Qemu-devel] [PATCH v2 for-2.5 12/12] tcg: update README about size changing ops

Cc: Richard Henderson r...@twiddle.net
Signed-off-by: Aurelien Jarno aurel...@aurel32.net
---
 tcg/README | 18 +++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/tcg/README b/tcg/README
index 61b3899..a22f251 100644
--- a/tcg/README
+++ b/tcg/README
@@ -466,13 +466,25 @@ On a 32 bit target, all 64 bit operations are converted 
to 32 bits. A
 few specific operations must be implemented to allow it (see add2_i32,
 sub2_i32, brcond2_i32).
 
+On a 64 bit target, the values are transfered between 32 and 64-bit
+registers using the following ops:
+- trunc_shr_i64_i32
+- ext_i32_i64
+- extu_i32_i64
+
+They ensure that the values are correctly truncated or extended when
+moved from a 32-bit to a 64-bit register or vice-versa. Note that the
+trunc_shr_i64_i32 is an optional op. It is not necessary to implement
+it if all the following conditions are met:
+- 64-bit registers can hold 32-bit values
+- 32-bit values in a 64-bit register do not need to stay zero or
+  sign extended
+- all 32-bit TCG ops ignore the high part of 64-bit registers
+
 Floating point operations are not supported in this version. A
 previous incarnation of the code generator had full support of them,
 but it is better to concentrate on integer operations first.
 
-On a 64 bit target, no assumption is made in TCG about the storage of
-the 32 bit values in 64 bit registers.
-
 4.2) Constraints
 
 GCC like constraints are used to define the constraints of every
-- 
2.1.4

[Qemu-devel] [PATCH v2 for-2.5 05/12] tcg/optimize: track const/copy status separately

Instead of using an enum which could be either a copy or a const, track
them separately. Constants are tracked through a bool. Copies are
tracked by initializing temp's next_copy and prev_copy to itself,
allowing to simplify the code a bit.

Cc: Richard Henderson r...@twiddle.net
Signed-off-by: Aurelien Jarno aurel...@aurel32.net
---
 tcg/optimize.c | 42 ++
 1 file changed, 14 insertions(+), 28 deletions(-)

diff --git a/tcg/optimize.c b/tcg/optimize.c
index 719fee2..e69ab05 100644
--- a/tcg/optimize.c
+++ b/tcg/optimize.c
@@ -35,14 +35,8 @@
 glue(glue(case INDEX_op_, x), _i32):\
 glue(glue(case INDEX_op_, x), _i64)
 
-typedef enum {
-TCG_TEMP_UNDEF = 0,
-TCG_TEMP_CONST,
-TCG_TEMP_COPY,
-} tcg_temp_state;
-
 struct tcg_temp_info {
-tcg_temp_state state;
+bool is_const;
 uint16_t prev_copy;
 uint16_t next_copy;
 tcg_target_ulong val;
@@ -54,27 +48,22 @@ static TCGTempSet temps_used;
 
 static inline bool temp_is_const(TCGArg arg)
 {
-return temps[arg].state == TCG_TEMP_CONST;
+return temps[arg].is_const;
 }
 
 static inline bool temp_is_copy(TCGArg arg)
 {
-return temps[arg].state == TCG_TEMP_COPY;
+return temps[arg].next_copy != arg;
 }
 
-/* Reset TEMP's state to TCG_TEMP_UNDEF.  If TEMP only had one copy, remove
-   the copy flag from the left temp.  */
+/* Reset TEMP's state, possibly removing the temp for the list of copies.  */
 static void reset_temp(TCGArg temp)
 {
-if (temp_is_copy(temp)) {
-if (temps[temp].prev_copy == temps[temp].next_copy) {
-temps[temps[temp].next_copy].state = TCG_TEMP_UNDEF;
-} else {
-temps[temps[temp].next_copy].prev_copy = temps[temp].prev_copy;
-temps[temps[temp].prev_copy].next_copy = temps[temp].next_copy;
-}
-}
-temps[temp].state = TCG_TEMP_UNDEF;
+temps[temps[temp].next_copy].prev_copy = temps[temp].prev_copy;
+temps[temps[temp].prev_copy].next_copy = temps[temp].next_copy;
+temps[temp].next_copy = temp;
+temps[temp].prev_copy = temp;
+temps[temp].is_const = false;
 temps[temp].mask = -1;
 }
 
@@ -88,7 +77,9 @@ static void reset_all_temps(int nb_temps)
 static void init_temp_info(TCGArg temp)
 {
 if (!test_bit(temp, temps_used.l)) {
-temps[temp].state = TCG_TEMP_UNDEF;
+temps[temp].next_copy = temp;
+temps[temp].prev_copy = temp;
+temps[temp].is_const = false;
 temps[temp].mask = -1;
 set_bit(temp, temps_used.l);
 }
@@ -218,7 +209,7 @@ static void tcg_opt_gen_movi(TCGContext *s, TCGOp *op, 
TCGArg *args,
 op-opc = new_op;
 
 reset_temp(dst);
-temps[dst].state = TCG_TEMP_CONST;
+temps[dst].is_const = true;
 temps[dst].val = val;
 mask = val;
 if (TCG_TARGET_REG_BITS  32  new_op == INDEX_op_movi_i32) {
@@ -260,16 +251,11 @@ static void tcg_opt_gen_mov(TCGContext *s, TCGOp *op, 
TCGArg *args,
 assert(!temp_is_const(src));
 
 if (s-temps[src].type == s-temps[dst].type) {
-if (!temp_is_copy(src)) {
-temps[src].state = TCG_TEMP_COPY;
-temps[src].next_copy = src;
-temps[src].prev_copy = src;
-}
-temps[dst].state = TCG_TEMP_COPY;
 temps[dst].next_copy = temps[src].next_copy;
 temps[dst].prev_copy = src;
 temps[temps[dst].next_copy].prev_copy = dst;
 temps[src].next_copy = dst;
+temps[dst].is_const = false;
 }
 
 args[0] = dst;
-- 
2.1.4

[Qemu-devel] PING: [PATCH v4 0/2] QOM: object_property_add() performance improvement

2015-07-27 Thread Pavel Fedin

 Ping!!!

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia


 -Original Message-
 From: qemu-devel-bounces+p.fedin=samsung@nongnu.org [mailto:qemu-devel-
 bounces+p.fedin=samsung@nongnu.org] On Behalf Of Pavel Fedin
 Sent: Tuesday, July 14, 2015 12:39 PM
 To: qemu-devel@nongnu.org
 Cc: Peter Crosthwaite; Andreas Färber
 Subject: [Qemu-devel] [PATCH v4 0/2] QOM: object_property_add() performance 
 improvement
 
 The function originally behaves very badly when adding properties with [*]
 suffix. Normally these are used for numbering IRQ pins. In order to find the
 correct starting number the function started from zero and checked for
 duplicates. This takes incredibly long time with large number of CPUs because
 number of IRQ pins on some architectures (like ARM GICv3) gets multiplied by
 number of CPUs.
 
 The solution is to add one more property which caches last used index so that
 duplication check is not repeated thousands of times. Every time an array is
 expanded the index is picked up from this cache.
 
 The modification decreases qemu startup time with 32 CPUs by a factor of 2
 (~10 sec vs ~20 sec).
 
 Pavel Fedin (2):
   QOM: Introduce object_property_add_single()
   QOM: object_property_add() performance improvement
 
  qom/object.c | 96 
 +++-
  1 file changed, 69 insertions(+), 27 deletions(-)
 
 --
 1.9.5.msysgit.0

Re: [Qemu-devel] [PATCH v4 2/2] QOM: object_property_add() performance improvement

2015-07-27 Thread Daniel P. Berrange

On Tue, Jul 14, 2015 at 12:39:01PM +0300, Pavel Fedin wrote:
 Avoid repetitive lookup of every property in array starting from 0 by adding
 one more property which caches last used index. Every time an array is
 expanded the index is picked up from this cache.
 
 The property is a uint32_t and its name is name of the array plus '#'
 ('name#'). It has getter function in order to allow to inspect it from
 within monitor.
 
 Another optimization includes avoiding reallocation of 'full_name' every
 iteration. Instead, name_no_array buffer is extended and reused.
 
 Signed-off-by: Pavel Fedin p.fe...@samsung.com
 Reviewed-by: Peter Crosthwaite peter.crosthwa...@xilinx.com

IIUC, the performance problem with object_property_add is caused by
the fact that every time we add a property we have to do a linear
search over every existing property running strcmp to see if the
new property already exists.


QTAILQ_FOREACH(prop, obj-properties, node) {
if (strcmp(prop-name, name) == 0) {
error_setg(errp, attempt to add duplicate property '%s'
to object (type '%s'), name,
   object_get_typename(obj));
return NULL;
}
}

This is compounded by the array expansion code which does a linear
search trying index 0, then index 1, etc, until it is able to add
the property without error. So this code becomes O(n^2) complexity.

Your change is avoiding the problemm in array expansion code by
storing the max index, but is still leaving the linear search in
check for duplicate property name. So the code is still O(n) on
the number of properties. Better, but still poor.

I seems that we should also look at changing the 'properties'
field to use a hash table instead of linked list, so that we
have O(1) access in all the methods which add/remove/lookup
properties.

 ---
  qom/object.c | 51 ---
  1 file changed, 40 insertions(+), 11 deletions(-)
 
 diff --git a/qom/object.c b/qom/object.c
 index ba63777..5820df2 100644
 --- a/qom/object.c
 +++ b/qom/object.c
 @@ -10,6 +10,8 @@
   * See the COPYING file in the top-level directory.
   */
  
 +#include glib/gprintf.h
 +
  #include qom/object.h
  #include qom/object_interfaces.h
  #include qemu-common.h
 @@ -862,6 +864,14 @@ object_property_add_single(Object *obj, const char 
 *name, const char *type,
  return prop;
  }
  
 +static void
 +property_get_uint32_opaque(Object *obj, Visitor *v, void *opaque,
 +   const char *name, Error **errp)
 +{
 +uint32_t value = (uintptr_t)opaque;
 +visit_type_uint32(v, value, name, errp);
 +}
 +
  ObjectProperty *
  object_property_add(Object *obj, const char *name, const char *type,
  ObjectPropertyAccessor *get,
 @@ -871,27 +881,46 @@ object_property_add(Object *obj, const char *name, 
 const char *type,
  {
  size_t name_len = strlen(name);
  char *name_no_array;
 -ObjectProperty *ret;
 -int i;
 +ObjectProperty *ret, *count;
 +uintptr_t i;
  
  if (name_len  3 || memcmp(name[name_len - 3], [*], 4)) {
  return object_property_add_single(obj, name, type,
get, set, release, opaque, errp);
  }
  
 -name_no_array = g_strdup(name);
 -
 -name_no_array[name_len - 3] = '\0';
 -for (i = 0; ; ++i) {
 -char *full_name = g_strdup_printf(%s[%d], name_no_array, i);
 -
 -ret = object_property_add(obj, full_name, type, get, set,
 -  release, opaque, NULL);
 -g_free(full_name);
 +/* 20 characters for maximum possible uintptr_t (64-bit) */
 +name_no_array = g_malloc(name_len + 20);
 +name_len -= 3;
 +memcpy(name_no_array, name, name_len);
 +
 +name_no_array[name_len] = '#';
 +name_no_array[name_len + 1] = '\0';

This code is really uneccessarily convoluted in trying to reuse
the same memory allocation for two different strings

You can rewrite this more clearly as:

  name_no_array = g_strndup_printf(%.s#, name_len - 3, name);


 +count = object_property_find(obj, name_no_array, NULL);
 +if (count == NULL) {
 +/* This is very similar to object_property_add_uint32_ptr(), but:
 + * - Returns pointer
 + * - Will not recurse here, avoiding one condition check
 + * - Allows us to use 'opaque' pointer itself as a storage, because
 + *   we want to store only a single integer which should never be
 + *   modified from outside.
 + */
 +count = object_property_add_single(obj, name_no_array, uint32,
 +   property_get_uint32_opaque, NULL,
 +   NULL, NULL, error_abort);
 +}
 +
 +for (i = (uintptr_t)count-opaque; ; ++i) {
 +g_sprintf(name_no_array[name_len], [%zu], i);

And here you could use

   g_strdup_printf(%.s[%zu], name_len - 3, name, i)

avoiding

[Qemu-devel] [PATCH] fixup! virtio-blk: fail get_features when both scsi and 1.0 were set

Tweak the error message so that it does not mention SCSI passthrough.  That
can be confusing because you can have scsi=on even for file-backed image,
which obviously do not support SCSI passthrough at the block layer level.

Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
 hw/block/virtio-blk.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c
index 9acbc3a..7bed3f0 100644
--- a/hw/block/virtio-blk.c
+++ b/hw/block/virtio-blk.c
@@ -734,7 +734,7 @@ static uint64_t virtio_blk_get_features(VirtIODevice *vdev, 
uint64_t features,
 virtio_clear_feature(features, VIRTIO_F_ANY_LAYOUT);
 if (__virtio_has_feature(features, VIRTIO_F_VERSION_1)) {
 if (s-conf.scsi) {
-error_setg(errp, Virtio 1.0 does not support scsi passthrough!);
+error_setg(errp, Please set scsi=off for virtio-blk devices in 
order to use virtio 1.0);
 return 0;
 }
 virtio_add_feature(features, VIRTIO_F_ANY_LAYOUT);
-- 
2.1.4

Re: [Qemu-devel] [PATCH] vhost-scsi: Fix mask index err in vhost_scsi_start

2015-07-27 Thread Gonglei

On 2015/7/27 19:35, Paolo Bonzini wrote:
 
 
 On 27/07/2015 13:11, Gonglei wrote:
 On 2015/7/27 18:20, Paolo Bonzini wrote:


 On 27/07/2015 08:25, arei.gong...@huawei.com wrote:
 +++ b/hw/scsi/vhost-scsi.c
 @@ -117,7 +117,7 @@ static int vhost_scsi_start(VHostSCSI *s)
   * enabling/disabling irqfd.
   */
  for (i = 0; i  s-dev.nvqs; i++) {
 -vhost_virtqueue_mask(s-dev, vdev, i, false);
 +vhost_virtqueue_mask(s-dev, vdev, s-dev.vq_index + i, false);
  }
  
  return ret;

 Is this fixing an actual bug, or just using the API correctly?
 s-dev.vq_index is always 0, right?

 Yes.  At present, we found that s-dev.vq_index is always 0.
 
 Ok, then I've applied the patch with this commit message:
 
 vhost_virtqueue_mask takes an absolute virtqueue index, while the
 code looks like it's passing an index that is relative to
 s-dev.vq_index.  In reality, s-dev.vq_index is always zero, so
 this patch does not make any difference, but the code is clearer.
 
It's better, thanks.

Regards,
-Gonglei

[Qemu-devel] [PATCH] qemu-nbd: remove unnecessary qemu_notify_event()

This was needed when qemu-nbd was using qemu_set_fd_handler2.  It is
not needed anymore now that nbd_update_server_fd_handler is called
whenever nbd_can_accept() can change from false to true.
nbd_update_server_fd_handler will call qemu_set_fd_handler(),
which will call qemu_notify_event().

Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
 qemu-nbd.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/qemu-nbd.c b/qemu-nbd.c
index 5106b80..d9644b2 100644
--- a/qemu-nbd.c
+++ b/qemu-nbd.c
@@ -362,7 +362,6 @@ static void nbd_client_closed(NBDClient *client)
 state = TERMINATE;
 }
 nbd_update_server_fd_handler(server_fd);
-qemu_notify_event();
 nbd_client_put(client);
 }
 
-- 
2.4.3

Re: [Qemu-devel] [PATCH v3] hw/arm/virt: Add high MMIO PCI region

2015-07-27 Thread Igor Mammedov

On Mon, 27 Jul 2015 14:09:28 +0300
Pavel Fedin p.fe...@samsung.com wrote:

 This large region is necessary for some devices like ivshmem and video cards
 
 Signed-off-by: Pavel Fedin p.fe...@samsung.com
 ---
 Changes since v2:
 - Region size increased to 512G
 - Added ACPI description
 Changes since v1:
 - Region address changed to 512G, leaving more space for RAM
 ---
  hw/arm/virt-acpi-build.c |  8 
  hw/arm/virt.c| 13 -
  include/hw/arm/virt.h|  1 +
  3 files changed, 21 insertions(+), 1 deletion(-)
 
 diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
 index f365140..020aad6 100644
 --- a/hw/arm/virt-acpi-build.c
 +++ b/hw/arm/virt-acpi-build.c
 @@ -169,6 +169,8 @@ static void acpi_dsdt_add_pci(Aml *scope, const 
 MemMapEntry *memmap, int irq)
  hwaddr size_pio = memmap[VIRT_PCIE_PIO].size;
  hwaddr base_ecam = memmap[VIRT_PCIE_ECAM].base;
  hwaddr size_ecam = memmap[VIRT_PCIE_ECAM].size;
 +hwaddr base_mmio_high = memmap[VIRT_PCIE_MMIO_HIGH].base;
 +hwaddr size_mmio_high = memmap[VIRT_PCIE_MMIO_HIGH].size;
  int nr_pcie_buses = size_ecam / PCIE_MMCFG_SIZE_MIN;
  
  Aml *dev = aml_device(%s, PCI0);
 @@ -234,6 +236,12 @@ static void acpi_dsdt_add_pci(Aml *scope, const 
 MemMapEntry *memmap, int irq)
   AML_ENTIRE_RANGE, 0x, 0x, size_pio - 1, 
 base_pio,
   size_pio));
  
 +aml_append(rbuf,
 +aml_dword_memory(AML_POS_DECODE, AML_MIN_FIXED, AML_MAX_FIXED,
 + AML_NON_CACHEABLE, AML_READ_WRITE, 0x,
 + base_mmio_high, base_mmio_high + size_mmio_high - 1,
 + 0x, size_mmio_high));
 +
  aml_append(method, aml_name_decl(RBUF, rbuf));
  aml_append(method, aml_return(rbuf));
  aml_append(dev, method);
 diff --git a/hw/arm/virt.c b/hw/arm/virt.c
 index e53ef4c..c20b3b8 100644
 --- a/hw/arm/virt.c
 +++ b/hw/arm/virt.c
 @@ -124,6 +124,7 @@ static const MemMapEntry a15memmap[] = {
  [VIRT_PCIE_PIO] =   { 0x3eff, 0x0001 },
  [VIRT_PCIE_ECAM] =  { 0x3f00, 0x0100 },
  [VIRT_MEM] ={ 0x4000, 30ULL * 1024 * 1024 * 1024 },
 +[VIRT_PCIE_MMIO_HIGH] =   { 0x80, 0x80 },
I'm not sure  but fixed hole start/size might be a problem later when adding 
memory hotplug wasting address space.

On x86 we do it a little different, see call chain:
 acpi_setup - build_ssdt -
   i440fx_pcihost_get_pci_hole64_start - pci_bus_get_w64_range
   ...  _end - ...

where acpi_setup() is called from pc_guest_info_machine_done() right before
guest starts and later after guest's BIOS(UEFI) initialized PCI devices.

Perhaps we should do the same for ARM as well, CCing Michael

  };
  
  static const int a15irqmap[] = {
 @@ -758,6 +759,8 @@ static void create_pcie(const VirtBoardInfo *vbi, 
 qemu_irq *pic)
  hwaddr size_pio = vbi-memmap[VIRT_PCIE_PIO].size;
  hwaddr base_ecam = vbi-memmap[VIRT_PCIE_ECAM].base;
  hwaddr size_ecam = vbi-memmap[VIRT_PCIE_ECAM].size;
 +hwaddr base_mmio_high = vbi-memmap[VIRT_PCIE_MMIO_HIGH].base;
 +hwaddr size_mmio_high = vbi-memmap[VIRT_PCIE_MMIO_HIGH].size;
  hwaddr base = base_mmio;
  int nr_pcie_buses = size_ecam / PCIE_MMCFG_SIZE_MIN;
  int irq = vbi-irqmap[VIRT_PCIE];
 @@ -793,6 +796,12 @@ static void create_pcie(const VirtBoardInfo *vbi, 
 qemu_irq *pic)
  /* Map IO port space */
  sysbus_mmio_map(SYS_BUS_DEVICE(dev), 2, base_pio);
  
 +/* High MMIO space */
 +mmio_alias = g_new0(MemoryRegion, 1);
 +memory_region_init_alias(mmio_alias, OBJECT(dev), pcie-mmio-high,
 + mmio_reg, base_mmio_high, size_mmio_high);
 +memory_region_add_subregion(get_system_memory(), base_mmio_high, 
 mmio_alias);
Is there any specific reason to have 2 separate regions vs using 1 like in
 pc_pci_as_mapping_init()
using region priority instead of splitting.

  for (i = 0; i  GPEX_NUM_IRQS; i++) {
  sysbus_connect_irq(SYS_BUS_DEVICE(dev), i, pic[irq + i]);
  }
 @@ -818,7 +827,9 @@ static void create_pcie(const VirtBoardInfo *vbi, 
 qemu_irq *pic)
   1, FDT_PCI_RANGE_IOPORT, 2, 0,
   2, base_pio, 2, size_pio,
   1, FDT_PCI_RANGE_MMIO, 2, base_mmio,
 - 2, base_mmio, 2, size_mmio);
 + 2, base_mmio, 2, size_mmio,
 + 1, FDT_PCI_RANGE_MMIO, 2, base_mmio_high,
 + 2, base_mmio_high, 2, size_mmio_high);
  
  qemu_fdt_setprop_cell(vbi-fdt, nodename, #interrupt-cells, 1);
  create_pcie_irq_map(vbi, vbi-gic_phandle, irq, nodename);
 diff --git a/include/hw/arm/virt.h b/include/hw/arm/virt.h
 index 852efb9..1d43598 100644
 --- a/include/hw/arm/virt.h
 +++ b/include/hw/arm/virt.h
 @@ -60,6 +60,7 @@

Re: [Qemu-devel] [POC] colo-proxy in qemu

2015-07-27 Thread Jan Kiszka

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2015-07-27 12:13, Stefan Hajnoczi wrote:
 On Tue, Jul 21, 2015 at 10:49:29AM +0100, Stefan Hajnoczi wrote:
 On Tue, Jul 21, 2015 at 08:13:42AM +0200, Jan Kiszka wrote:
 On 2015-07-20 17:01, Stefan Hajnoczi wrote:
 On Mon, Jul 20, 2015 at 2:12 PM, Vasiliy Tolstov
 v.tols...@selfip.ru wrote:
 2015-07-20 14:55 GMT+03:00 zhanghailiang
 zhang.zhanghaili...@huawei.com:
 Agreed, besides, it is seemed that slirp is not
 supporting ipv6, we also have to supplement it.
 
 
 patch for ipv6 slirp support some times ago sended to qemu
 list, but i don't know why in not accepted.
 
 I think no one reviewed it but there was no objection against
 IPv6 support in principle.
 
 Jan: Can we merge slirp IPv6 support for QEMU 2.5?
 
 Sorry, as I pointed out some time back, I don't have the
 bandwidth to look into slirp. Someone need to do a review, then
 send a pull request.
 
 Do you want to remove yourself from the slirp section of the
 MAINTAINERS file?
 
 Going forward we'll need to find someone familiar with the QEMU 
 development process and with enough time to review slirp
 patches.
 
 Ping?
 
 I hoped this would raise some discussion and that maybe we could
 find a new maintainer or co-maintainer to get slirp moving.
 
 Any thoughts?

Of course, I'm fine with handing this over to someone who'd like to
pick up. Do we have volunteers?

Samuel, would you like to do this? As a subsystem maintainer, you are
already familiar with QEMU processes. Well, this still wouldn't
resolve the independent review need for slirp-ipv6.

Jan

- -- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAlW2MycACgkQitSsb3rl5xSCaACePNubKPBkrdxQkcThUGD7w56B
Q6oAoIgCzT9qVRzDf5IhY2eKFXgTZ+Ul
=yk6R
-END PGP SIGNATURE-

[Qemu-devel] [PULL for-2.4 10/16] etsec: Flush queue when rx buffer is consumed

From: Fam Zheng f...@redhat.com

The BH will be scheduled when etsec-rx_buffer_len is becoming 0, which
is the condition of queuing.

Signed-off-by: Fam Zheng f...@redhat.com
Reviewed-by: Jason Wang jasow...@redhat.com
Reviewed-by: Stefan Hajnoczi stefa...@redhat.com
Message-id: 143693-22791-7-git-send-email-f...@redhat.com
Signed-off-by: Stefan Hajnoczi stefa...@redhat.com
---
 hw/net/fsl_etsec/etsec.c | 11 ++-
 hw/net/fsl_etsec/etsec.h |  2 ++
 hw/net/fsl_etsec/rings.c |  3 +++
 3 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/hw/net/fsl_etsec/etsec.c b/hw/net/fsl_etsec/etsec.c
index f5170ae..0f5cf44 100644
--- a/hw/net/fsl_etsec/etsec.c
+++ b/hw/net/fsl_etsec/etsec.c
@@ -342,13 +342,22 @@ static ssize_t etsec_receive(NetClientState *nc,
  const uint8_t  *buf,
  size_t  size)
 {
+ssize_t ret;
 eTSEC *etsec = qemu_get_nic_opaque(nc);
 
 #if defined(HEX_DUMP)
 fprintf(stderr, %s receive size:%d\n, etsec-nic-nc.name, size);
 qemu_hexdump(buf, stderr, , size);
 #endif
-return etsec_rx_ring_write(etsec, buf, size);
+/* Flush is unnecessary as are already in receiving path */
+etsec-need_flush = false;
+ret = etsec_rx_ring_write(etsec, buf, size);
+if (ret == 0) {
+/* The packet will be queued, let's flush it when buffer is avilable
+ * again. */
+etsec-need_flush = true;
+}
+return ret;
 }
 
 
diff --git a/hw/net/fsl_etsec/etsec.h b/hw/net/fsl_etsec/etsec.h
index fc41773..e7dc0a4 100644
--- a/hw/net/fsl_etsec/etsec.h
+++ b/hw/net/fsl_etsec/etsec.h
@@ -144,6 +144,8 @@ typedef struct eTSEC {
 QEMUBH *bh;
 struct ptimer_state *ptimer;
 
+/* Whether we should flush the rx queue when buffer becomes available. */
+bool need_flush;
 } eTSEC;
 
 #define TYPE_ETSEC_COMMON eTSEC
diff --git a/hw/net/fsl_etsec/rings.c b/hw/net/fsl_etsec/rings.c
index a11280b..68e7b6d 100644
--- a/hw/net/fsl_etsec/rings.c
+++ b/hw/net/fsl_etsec/rings.c
@@ -646,6 +646,9 @@ void etsec_walk_rx_ring(eTSEC *etsec, int ring_nbr)
 } else {
 etsec-rx_buffer_len = 0;
 etsec-rx_buffer = NULL;
+if (etsec-need_flush) {
+qemu_flush_queued_packets(qemu_get_queue(etsec-nic));
+}
 }
 
 RING_DEBUG(eTSEC End of ring_write: remaining_data:%zu\n, 
remaining_data);
-- 
2.4.3

[Qemu-devel] [PULL for-2.4 16/16] axienet: Flush queued packets when rx is done

From: Fam Zheng f...@redhat.com

eth_can_rx checks s-rxsize and returns false if it is non-zero. Because
of the .can_receive semantics change, this will make the incoming queue
disabled by peer, until it is explicitly flushed. So we should flush it
when s-rxsize is becoming zero.

Squash eth_can_rx semantics into etx_rx and drop .can_receive()
callback, also add flush when rx buffer becomes available again after a
packet gets queued.

The other conditions, !axienet_rx_resetting(s) 
axienet_rx_enabled(s) are OK because enet_write already calls
qemu_flush_queued_packets when the register bits are changed.

Signed-off-by: Fam Zheng f...@redhat.com
Reviewed-by: Jason Wang jasow...@redhat.com
Reviewed-by: Stefan Hajnoczi stefa...@redhat.com
Message-id: 143693-22791-13-git-send-email-f...@redhat.com
Signed-off-by: Stefan Hajnoczi stefa...@redhat.com
---
 hw/net/xilinx_axienet.c | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/hw/net/xilinx_axienet.c b/hw/net/xilinx_axienet.c
index 9205770..d63c423 100644
--- a/hw/net/xilinx_axienet.c
+++ b/hw/net/xilinx_axienet.c
@@ -401,6 +401,9 @@ struct XilinxAXIEnet {
 
 uint8_t rxapp[CONTROL_PAYLOAD_SIZE];
 uint32_t rxappsize;
+
+/* Whether axienet_eth_rx_notify should flush incoming queue. */
+bool need_flush;
 };
 
 static void axienet_rx_reset(XilinxAXIEnet *s)
@@ -658,10 +661,8 @@ static const MemoryRegionOps enet_ops = {
 .endianness = DEVICE_LITTLE_ENDIAN,
 };
 
-static int eth_can_rx(NetClientState *nc)
+static int eth_can_rx(XilinxAXIEnet *s)
 {
-XilinxAXIEnet *s = qemu_get_nic_opaque(nc);
-
 /* RX enabled?  */
 return !s-rxsize  !axienet_rx_resetting(s)  axienet_rx_enabled(s);
 }
@@ -701,6 +702,10 @@ static void axienet_eth_rx_notify(void *opaque)
 s-rxpos += ret;
 if (!s-rxsize) {
 s-regs[R_IS] |= IS_RX_COMPLETE;
+if (s-need_flush) {
+s-need_flush = false;
+qemu_flush_queued_packets(qemu_get_queue(s-nic));
+}
 }
 }
 enet_update_irq(s);
@@ -721,6 +726,11 @@ static ssize_t eth_rx(NetClientState *nc, const uint8_t 
*buf, size_t size)
 
 DENET(qemu_log(%s: %zd bytes\n, __func__, size));
 
+if (!eth_can_rx(s)) {
+s-need_flush = true;
+return 0;
+}
+
 unicast = ~buf[0]  0x1;
 broadcast = memcmp(buf, sa_bcast, 6) == 0;
 multicast = !unicast  !broadcast;
@@ -925,7 +935,6 @@ xilinx_axienet_data_stream_push(StreamSlave *obj, uint8_t 
*buf, size_t size)
 static NetClientInfo net_xilinx_enet_info = {
 .type = NET_CLIENT_OPTIONS_KIND_NIC,
 .size = sizeof(NICState),
-.can_receive = eth_can_rx,
 .receive = eth_rx,
 };
 
-- 
2.4.3

[Qemu-devel] [PULL for-2.4 14/16] stellaris_enet: Flush queued packets when read done

From: Fam Zheng f...@redhat.com

If s-np reaches 31, the queue will be disabled by peer when it sees
stellaris_enet_can_receive() returns false, until we explicitly flushes
it which notifies the peer. Do this when guest is done reading all
existing data.

Move the semantics to stellaris_enet_receive, by returning 0 when the
buffer is full, so that new packets will be queued.  In
stellaris_enet_read, flush and restart the queue when guest has done
reading.

Signed-off-by: Fam Zheng f...@redhat.com
Reviewed-by: Stefan Hajnoczi stefa...@redhat.com
Reviewed-by: Jason Wang jasow...@redhat.com
Message-id: 143693-22791-11-git-send-email-f...@redhat.com
Signed-off-by: Stefan Hajnoczi stefa...@redhat.com
---
 hw/net/stellaris_enet.c | 14 +-
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/hw/net/stellaris_enet.c b/hw/net/stellaris_enet.c
index 278a654..21a4773 100644
--- a/hw/net/stellaris_enet.c
+++ b/hw/net/stellaris_enet.c
@@ -228,8 +228,7 @@ static ssize_t stellaris_enet_receive(NetClientState *nc, 
const uint8_t *buf, si
 if ((s-rctl  SE_RCTL_RXEN) == 0)
 return -1;
 if (s-np = 31) {
-DPRINTF(Packet dropped\n);
-return -1;
+return 0;
 }
 
 DPRINTF(Received packet len=%zu\n, size);
@@ -260,13 +259,8 @@ static ssize_t stellaris_enet_receive(NetClientState *nc, 
const uint8_t *buf, si
 return size;
 }
 
-static int stellaris_enet_can_receive(NetClientState *nc)
+static int stellaris_enet_can_receive(stellaris_enet_state *s)
 {
-stellaris_enet_state *s = qemu_get_nic_opaque(nc);
-
-if ((s-rctl  SE_RCTL_RXEN) == 0)
-return 1;
-
 return (s-np  31);
 }
 
@@ -307,6 +301,9 @@ static uint64_t stellaris_enet_read(void *opaque, hwaddr 
offset,
 s-next_packet = 0;
 s-np--;
 DPRINTF(RX done np=%d\n, s-np);
+if (!s-np  stellaris_enet_can_receive(s)) {
+qemu_flush_queued_packets(qemu_get_queue(s-nic));
+}
 }
 return val;
 }
@@ -454,7 +451,6 @@ static void stellaris_enet_reset(stellaris_enet_state *s)
 static NetClientInfo net_stellaris_enet_info = {
 .type = NET_CLIENT_OPTIONS_KIND_NIC,
 .size = sizeof(NICState),
-.can_receive = stellaris_enet_can_receive,
 .receive = stellaris_enet_receive,
 };
 
-- 
2.4.3

[Qemu-devel] [PATCH for-2.4 02/12] tcg: mark temps as mem_coherent = 0 for mov with a constant

When a constant has to be loaded in a mov op, we fail to set
mem_coherent = 0. This patch fixes that.

Cc: Richard Henderson r...@twiddle.net
Signed-off-by: Aurelien Jarno aurel...@aurel32.net
---
 tcg/tcg.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tcg/tcg.c b/tcg/tcg.c
index 9a2508b..0892a9b 100644
--- a/tcg/tcg.c
+++ b/tcg/tcg.c
@@ -1894,6 +1894,7 @@ static void tcg_reg_alloc_mov(TCGContext *s, const 
TCGOpDef *def,
 ts-mem_coherent = 1;
 } else if (ts-val_type == TEMP_VAL_CONST) {
 tcg_out_movi(s, itype, ts-reg, ts-val);
+ts-mem_coherent = 0;
 }
 s-reg_to_temp[ts-reg] = args[1];
 ts-val_type = TEMP_VAL_REG;
-- 
2.1.4

[Qemu-devel] [PATCH v2 for-2.5 09/12] tcg: implement real ext_i32_i64 and extu_i32_i64 ops

Implement real ext_i32_i64 and extu_i32_i64 ops. They ensure that a
32-bit value is always converted to a 64-bit value and not propagated
through the register allocator or the optimizer.

Cc: Andrzej Zaborowski balr...@gmail.com
Cc: Alexander Graf ag...@suse.de
Cc: Blue Swirl blauwir...@gmail.com
Cc: Claudio Fontana claudio.font...@huawei.com
Cc: Claudio Fontana claudio.font...@gmail.com
Cc: Richard Henderson r...@twiddle.net
Cc: Stefan Weil s...@weilnetz.de
Signed-off-by: Aurelien Jarno aurel...@aurel32.net
---
 tcg/aarch64/tcg-target.c |  4 
 tcg/i386/tcg-target.c|  5 +
 tcg/ia64/tcg-target.c|  4 
 tcg/ppc/tcg-target.c |  6 ++
 tcg/s390/tcg-target.c|  5 +
 tcg/sparc/tcg-target.c   |  8 ++--
 tcg/tcg-op.c | 10 --
 tcg/tcg-opc.h|  3 +++
 tcg/tci/tcg-target.c |  4 
 tci.c|  6 --
 10 files changed, 45 insertions(+), 10 deletions(-)

diff --git a/tcg/aarch64/tcg-target.c b/tcg/aarch64/tcg-target.c
index 1fb67de..bc3a539 100644
--- a/tcg/aarch64/tcg-target.c
+++ b/tcg/aarch64/tcg-target.c
@@ -1567,6 +1567,7 @@ static void tcg_out_op(TCGContext *s, TCGOpcode opc,
 case INDEX_op_ext16s_i32:
 tcg_out_sxt(s, ext, MO_16, a0, a1);
 break;
+case INDEX_op_ext_i32_i64:
 case INDEX_op_ext32s_i64:
 tcg_out_sxt(s, TCG_TYPE_I64, MO_32, a0, a1);
 break;
@@ -1578,6 +1579,7 @@ static void tcg_out_op(TCGContext *s, TCGOpcode opc,
 case INDEX_op_ext16u_i32:
 tcg_out_uxt(s, MO_16, a0, a1);
 break;
+case INDEX_op_extu_i32_i64:
 case INDEX_op_ext32u_i64:
 tcg_out_movr(s, TCG_TYPE_I32, a0, a1);
 break;
@@ -1723,6 +1725,8 @@ static const TCGTargetOpDef aarch64_op_defs[] = {
 { INDEX_op_ext8u_i64, { r, r } },
 { INDEX_op_ext16u_i64, { r, r } },
 { INDEX_op_ext32u_i64, { r, r } },
+{ INDEX_op_ext_i32_i64, { r, r } },
+{ INDEX_op_extu_i32_i64, { r, r } },
 
 { INDEX_op_deposit_i32, { r, 0, rZ } },
 { INDEX_op_deposit_i64, { r, 0, rZ } },
diff --git a/tcg/i386/tcg-target.c b/tcg/i386/tcg-target.c
index 4f40468..ff55499 100644
--- a/tcg/i386/tcg-target.c
+++ b/tcg/i386/tcg-target.c
@@ -2068,9 +2068,11 @@ static inline void tcg_out_op(TCGContext *s, TCGOpcode 
opc,
 case INDEX_op_bswap64_i64:
 tcg_out_bswap64(s, args[0]);
 break;
+case INDEX_op_extu_i32_i64:
 case INDEX_op_ext32u_i64:
 tcg_out_ext32u(s, args[0], args[1]);
 break;
+case INDEX_op_ext_i32_i64:
 case INDEX_op_ext32s_i64:
 tcg_out_ext32s(s, args[0], args[1]);
 break;
@@ -2205,6 +2207,9 @@ static const TCGTargetOpDef x86_op_defs[] = {
 { INDEX_op_ext16u_i64, { r, r } },
 { INDEX_op_ext32u_i64, { r, r } },
 
+{ INDEX_op_ext_i32_i64, { r, r } },
+{ INDEX_op_extu_i32_i64, { r, r } },
+
 { INDEX_op_deposit_i64, { Q, 0, Q } },
 { INDEX_op_movcond_i64, { r, r, re, r, 0 } },
 
diff --git a/tcg/ia64/tcg-target.c b/tcg/ia64/tcg-target.c
index 81cb9f7..71e79cf 100644
--- a/tcg/ia64/tcg-target.c
+++ b/tcg/ia64/tcg-target.c
@@ -2148,9 +2148,11 @@ static inline void tcg_out_op(TCGContext *s, TCGOpcode 
opc,
 case INDEX_op_ext16u_i64:
 tcg_out_ext(s, OPC_ZXT2_I29, args[0], args[1]);
 break;
+case INDEX_op_ext_i32_i64:
 case INDEX_op_ext32s_i64:
 tcg_out_ext(s, OPC_SXT4_I29, args[0], args[1]);
 break;
+case INDEX_op_extu_i32_i64:
 case INDEX_op_ext32u_i64:
 tcg_out_ext(s, OPC_ZXT4_I29, args[0], args[1]);
 break;
@@ -2301,6 +2303,8 @@ static const TCGTargetOpDef ia64_op_defs[] = {
 { INDEX_op_ext16u_i64, { r, rZ} },
 { INDEX_op_ext32s_i64, { r, rZ} },
 { INDEX_op_ext32u_i64, { r, rZ} },
+{ INDEX_op_ext_i32_i64, { r, rZ } },
+{ INDEX_op_extu_i32_i64, { r, rZ } },
 
 { INDEX_op_bswap16_i64, { r, rZ } },
 { INDEX_op_bswap32_i64, { r, rZ } },
diff --git a/tcg/ppc/tcg-target.c b/tcg/ppc/tcg-target.c
index ce8d546..1672220 100644
--- a/tcg/ppc/tcg-target.c
+++ b/tcg/ppc/tcg-target.c
@@ -2221,12 +2221,16 @@ static void tcg_out_op(TCGContext *s, TCGOpcode opc, 
const TCGArg *args,
 case INDEX_op_ext16s_i64:
 c = EXTSH;
 goto gen_ext;
+case INDEX_op_ext_i32_i64:
 case INDEX_op_ext32s_i64:
 c = EXTSW;
 goto gen_ext;
 gen_ext:
 tcg_out32(s, c | RS(args[1]) | RA(args[0]));
 break;
+case INDEX_op_extu_i32_i64:
+tcg_out_ext32u(s, args[0], args[1]);
+break;
 
 case INDEX_op_setcond_i32:
 tcg_out_setcond(s, TCG_TYPE_I32, args[3], args[0], args[1], args[2],
@@ -2503,6 +2507,8 @@ static const TCGTargetOpDef ppc_op_defs[] = {
 { INDEX_op_ext8s_i64, { r, r } },
 { INDEX_op_ext16s_i64, { r, r } },
 { INDEX_op_ext32s_i64, { r, r } },
+{ INDEX_op_ext_i32_i64, { r, r } },
+{ INDEX_op_extu_i32_i64, { r, r } },
 { INDEX_op_bswap16_i64, { r, r } },
 { INDEX_op_bswap32_i64, { r, r } },
 {

Re: [Qemu-devel] [POC] colo-proxy in qemu

2015-07-27 Thread zhanghailiang


On 2015/7/27 18:13, Stefan Hajnoczi wrote:

On Tue, Jul 21, 2015 at 10:49:29AM +0100, Stefan Hajnoczi wrote:

On Tue, Jul 21, 2015 at 08:13:42AM +0200, Jan Kiszka wrote:

On 2015-07-20 17:01, Stefan Hajnoczi wrote:

On Mon, Jul 20, 2015 at 2:12 PM, Vasiliy Tolstov v.tols...@selfip.ru wrote:

2015-07-20 14:55 GMT+03:00 zhanghailiang zhang.zhanghaili...@huawei.com:

Agreed, besides, it is seemed that slirp is not supporting ipv6, we also
have to supplement it.



patch for ipv6 slirp support some times ago sended to qemu list, but i
don't know why in not accepted.


I think no one reviewed it but there was no objection against IPv6
support in principle.

Jan: Can we merge slirp IPv6 support for QEMU 2.5?


Sorry, as I pointed out some time back, I don't have the bandwidth to
look into slirp. Someone need to do a review, then send a pull request.


Do you want to remove yourself from the slirp section of the MAINTAINERS
file?

Going forward we'll need to find someone familiar with the QEMU
development process and with enough time to review slirp patches.


Ping?

I hoped this would raise some discussion and that maybe we could find a
new maintainer or co-maintainer to get slirp moving.



Yes, please, this is important, we need slirp's maintainer to help reviewing 
the COLO proxy
patches that will be implemented based on slirp. (If we finally come to an 
agreement on realizing it in qemu)

We also need to support ipv6 for slirp, i have emailed Samuel who have sent 
ipv6 patches for slirp before,
but got no response. (I would like to respin and test Samuel's ipv6 slirp patch 
if he don't have time to do this,
but firstly, i need to get his permission ：） ）

Cc: Samuel Thibault samuel.thiba...@ens-lyon.org samuel.thiba...@gnu.org.

Thanks,
zhanghailiang


Any thoughts?

Stefan

[Qemu-devel] [PULL 0/3] Cve 2015 5154 patches

The following changes since commit f793d97e454a56d17e404004867985622ca1a63b:

  Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into staging 
(2015-07-24 13:07:10 +0100)

are available in the git repository at:

  https://github.com/jnsnow/qemu.git tags/cve-2015-5154-pull-request

for you to fetch changes up to cb72cba83021fa42719e73a5249c12096a4d1cfc:

  ide: Clear DRQ after handling all expected accesses (2015-07-26 23:42:53 
-0400)





Kevin Wolf (3):
  ide: Check array bounds before writing to io_buffer (CVE-2015-5154)
  ide/atapi: Fix START STOP UNIT command completion
  ide: Clear DRQ after handling all expected accesses

 hw/ide/atapi.c |  1 +
 hw/ide/core.c  | 32 
 2 files changed, 29 insertions(+), 4 deletions(-)

-- 
2.1.0

[Qemu-devel] [PULL 2/3] ide/atapi: Fix START STOP UNIT command completion

From: Kevin Wolf kw...@redhat.com

The command must be completed on all code paths. START STOP UNIT with
pwrcnd set should succeed without doing anything.

Signed-off-by: Kevin Wolf kw...@redhat.com
Reviewed-by: John Snow js...@redhat.com
---
 hw/ide/atapi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/ide/atapi.c b/hw/ide/atapi.c
index 950e311..79dd167 100644
--- a/hw/ide/atapi.c
+++ b/hw/ide/atapi.c
@@ -983,6 +983,7 @@ static void cmd_start_stop_unit(IDEState *s, uint8_t* buf)
 
 if (pwrcnd) {
 /* eject/load only happens for power condition == 0 */
+ide_atapi_cmd_ok(s);
 return;
 }
 
-- 
2.1.0

[Qemu-devel] [PULL 1/3] ide: Check array bounds before writing to io_buffer (CVE-2015-5154)

From: Kevin Wolf kw...@redhat.com

If the end_transfer_func of a command is called because enough data has
been read or written for the current PIO transfer, and it fails to
correctly call the command completion functions, the DRQ bit in the
status register and s-end_transfer_func may remain set. This allows the
guest to access further bytes in s-io_buffer beyond s-data_end, and
eventually overflowing the io_buffer.

One case where this currently happens is emulation of the ATAPI command
START STOP UNIT.

This patch fixes the problem by adding explicit array bounds checks
before accessing the buffer instead of relying on end_transfer_func to
function correctly.

Cc: qemu-sta...@nongnu.org
Signed-off-by: Kevin Wolf kw...@redhat.com
Reviewed-by: John Snow js...@redhat.com
---
 hw/ide/core.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/hw/ide/core.c b/hw/ide/core.c
index 122e955..44fcc23 100644
--- a/hw/ide/core.c
+++ b/hw/ide/core.c
@@ -2021,6 +2021,10 @@ void ide_data_writew(void *opaque, uint32_t addr, 
uint32_t val)
 }
 
 p = s-data_ptr;
+if (p + 2  s-data_end) {
+return;
+}
+
 *(uint16_t *)p = le16_to_cpu(val);
 p += 2;
 s-data_ptr = p;
@@ -2042,6 +2046,10 @@ uint32_t ide_data_readw(void *opaque, uint32_t addr)
 }
 
 p = s-data_ptr;
+if (p + 2  s-data_end) {
+return 0;
+}
+
 ret = cpu_to_le16(*(uint16_t *)p);
 p += 2;
 s-data_ptr = p;
@@ -2063,6 +2071,10 @@ void ide_data_writel(void *opaque, uint32_t addr, 
uint32_t val)
 }
 
 p = s-data_ptr;
+if (p + 4  s-data_end) {
+return;
+}
+
 *(uint32_t *)p = le32_to_cpu(val);
 p += 4;
 s-data_ptr = p;
@@ -2084,6 +2096,10 @@ uint32_t ide_data_readl(void *opaque, uint32_t addr)
 }
 
 p = s-data_ptr;
+if (p + 4  s-data_end) {
+return 0;
+}
+
 ret = cpu_to_le32(*(uint32_t *)p);
 p += 4;
 s-data_ptr = p;
-- 
2.1.0

[Qemu-devel] [PULL 3/3] ide: Clear DRQ after handling all expected accesses

From: Kevin Wolf kw...@redhat.com

This is additional hardening against an end_transfer_func that fails to
clear the DRQ status bit. The bit must be unset as soon as the PIO
transfer has completed, so it's better to do this in a central place
instead of duplicating the code in all commands (and forgetting it in
some).

Signed-off-by: Kevin Wolf kw...@redhat.com
Reviewed-by: John Snow js...@redhat.com
---
 hw/ide/core.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/hw/ide/core.c b/hw/ide/core.c
index 44fcc23..50449ca 100644
--- a/hw/ide/core.c
+++ b/hw/ide/core.c
@@ -2028,8 +2028,10 @@ void ide_data_writew(void *opaque, uint32_t addr, 
uint32_t val)
 *(uint16_t *)p = le16_to_cpu(val);
 p += 2;
 s-data_ptr = p;
-if (p = s-data_end)
+if (p = s-data_end) {
+s-status = ~DRQ_STAT;
 s-end_transfer_func(s);
+}
 }
 
 uint32_t ide_data_readw(void *opaque, uint32_t addr)
@@ -2053,8 +2055,10 @@ uint32_t ide_data_readw(void *opaque, uint32_t addr)
 ret = cpu_to_le16(*(uint16_t *)p);
 p += 2;
 s-data_ptr = p;
-if (p = s-data_end)
+if (p = s-data_end) {
+s-status = ~DRQ_STAT;
 s-end_transfer_func(s);
+}
 return ret;
 }
 
@@ -2078,8 +2082,10 @@ void ide_data_writel(void *opaque, uint32_t addr, 
uint32_t val)
 *(uint32_t *)p = le32_to_cpu(val);
 p += 4;
 s-data_ptr = p;
-if (p = s-data_end)
+if (p = s-data_end) {
+s-status = ~DRQ_STAT;
 s-end_transfer_func(s);
+}
 }
 
 uint32_t ide_data_readl(void *opaque, uint32_t addr)
@@ -2103,8 +2109,10 @@ uint32_t ide_data_readl(void *opaque, uint32_t addr)
 ret = cpu_to_le32(*(uint32_t *)p);
 p += 4;
 s-data_ptr = p;
-if (p = s-data_end)
+if (p = s-data_end) {
+s-status = ~DRQ_STAT;
 s-end_transfer_func(s);
+}
 return ret;
 }
 
-- 
2.1.0

Re: [Qemu-devel] [PATCH 1/9] netdev: Add a net filter

2015-07-27 Thread Thomas Huth

On 24/07/15 12:55, Yang Hongyang wrote:
 This patch add a net filter between network backend and NIC devices.
 All packets will pass by this filter.
 TODO:
   multiqueue support.
 
 +--+   +-+
   +--+  |filter|   |frontend(NIC)|
   |  peer+--  |   | |
   | network  --+backend   ---+ peer|
   | backend  |  | peer +--- |
   +--+  +--+   +-+
 
 Usage:
   -netdev tap,id=bn0  # you can use whatever backend as needed
   -netdev filter,id=f0,backend=bn0
   -netdev filter-plugin,id=p0,filter=f0
   -device e1000,netdev=f0
 NOTE:
   You can attach multiple plugins to the filter, dynamically add/remove
 filter and filter-plugin.
   A filter without plugin supplied will do nothing except pass by all
 packets, a plugin like dump for example, will dump all packets into a
 file. Or other plugins like a netbuffer plugin, will simply buffer the
 packets, release the packets when needed.
   You can also implement whatever plugin you needed based on this filter.
 
 Signed-off-by: Yang Hongyang yan...@cn.fujitsu.com

 Hi,

just a quick comment: Please make sure to check your patches with
scripts/checkpatch.pl first before sending them for review - at least
for this patch, the script complains:

ERROR: do not use C99 // comments
#59: FILE: include/net/filter.h:12:
+//#include qapi-types.h

WARNING: braces {} are necessary for all arms of this statement
#424: FILE: net/filter.c:311:
+if (plug-plugin == plugin)
[...]

total: 1 errors, 1 warnings, 463 lines checked

 Thomas

Re: [Qemu-devel] [PATCH v4 2/2] QOM: object_property_add() performance improvement

2015-07-27 Thread Markus Armbruster

Pavel Fedin p.fe...@samsung.com writes:

 Avoid repetitive lookup of every property in array starting from 0 by adding
 one more property which caches last used index. Every time an array is
 expanded the index is picked up from this cache.

 The property is a uint32_t and its name is name of the array plus '#'
 ('name#'). It has getter function in order to allow to inspect it from
 within monitor.

Do we really want '#' in property names?  Elsewhere, we require names to
be id_wellformed().  I've long argued for doing that consistently[*],
but QOM still doesn't.

I've always hated automatic arrayification, not least because it
encodes semantics in property names.  I tried to replace it[**], but
Paolo opposed it.  Which makes him the go-to guy for reviewing anything
that touches it ;-P


[*] http://lists.gnu.org/archive/html/qemu-devel/2014-10/msg00030.html
[**] http://lists.gnu.org/archive/html/qemu-devel/2014-10/msg00030.html

Re: [Qemu-devel] [PATCH 0/4] hw/net: fix m68/ColdFire ethernet fec support

On Tue, Jun 30, 2015 at 03:38:11PM +1000, Greg Ungerer wrote:
 Hi Stefan,
 
 On 26/06/15 20:12, Stefan Hajnoczi wrote:
  On Fri, Jun 26, 2015 at 03:27:12PM +1000, g...@uclinux.org wrote:
 
  The following set of patches fixes the emulated ColdFire ethernet fec
  driver. There is primarily two problems that need to be fixed.
 
  1. The emulated driver needs to support probing of an attached phy.
 It is strait forward to emulate an attached phy, but to avoid using
 magic numbers I have factored out the common MII register and value
 definitions into their own mii.h file first.
 
  2. Fix the fec driver receiver to return the correct value.
 
  With these changes in place the qemu m5208evb board emulation can probe,
  identify and use the fec ethernet running a Linux guest.
 
 
   hw/net/mcf_fec.c|   54 ++--
   include/hw/net/allwinner_emac.h |   40 -
   include/hw/net/mii.h|   76 
  
   3 files changed, 128 insertions(+), 42 deletions(-)
  
  Reviewed-by: Stefan Hajnoczi stefa...@redhat.com
  
  If this series has no maintainer to go through I'll merge it via my net
  tree.  Please let me know if you'd like that.
  
  mcf_fec is not fully correct yet, it needs to call
  qemu_flush_queued_packets() when rx_enabled transitions from 0 to 1.
  This will restart rx by sending any queued packets from the net
  subsystem.
  
  In order to get flow control between NetClientState peers working the
  following is missing:
  
  1. mcf_fec_receive()'s !s-rx_enabled case should return -1 to drop
 unexpected packets.
  
  2. mcf_fec_receive() should return 0 in the (bd.flags  FEC_BD_E) == 0
 case where we've run out of rx buffers.  That way the net subsystem
 queues the packet and waits until the next RDAR write transitions
 rx_enabled from 0 to 1.
 
 Is the correct behavior in this case to check if we can write
 out the whole packet data, or too partially write out what we can?

It depends on the NIC you are emulation, but in all existing NICs we
either deliver the entire packet or we don't.

 For example it is possible that we hit bd.flags  FEC_BD_E) == 0
 having written some of the packet data but now we cannot fit the rest.
 So is it correct to simply return what count we have written or
 should we not write unless we can fit the whole packet and return 0.

Check the datasheet to see how the NIC handles that case.


pgpRjiuSt92yD.pgp
Description: PGP signature

Re: [Qemu-devel] [Qemu-stable] [PULL 0/3] Cve 2015 5154 patches

2015-07-27 Thread Stefan Priebe - Profihost AG


Am 27.07.2015 um 14:28 schrieb John Snow:
 
 
 On 07/27/2015 08:10 AM, Stefan Priebe - Profihost AG wrote:

 Am 27.07.2015 um 14:01 schrieb John Snow:
 The following changes since commit f793d97e454a56d17e404004867985622ca1a63b:

   Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into 
 staging (2015-07-24 13:07:10 +0100)

 are available in the git repository at:

   https://github.com/jnsnow/qemu.git tags/cve-2015-5154-pull-request

 Any details on this CVE? Is RCE possible? Only if IDE is used?

 Stefan

 
 It's a heap overflow. The most likely outcome is a segfault, but the
 guest is allowed to continue writing past the end of the PIO buffer at
 its leisure. This makes it similar to CVE-2015-3456.
 
 This CVE can be mitigated unlike CVE-2015-3456 by just removing the
 CD-ROM drive until the patch can be applied.

Thanks. The seclist article explicitly references xen. So it does not
apply to qemu/kvm? Sorry for asking may be stupid questions.

Stefan

 for you to fetch changes up to cb72cba83021fa42719e73a5249c12096a4d1cfc:

   ide: Clear DRQ after handling all expected accesses (2015-07-26 23:42:53 
 -0400)

 

 

 Kevin Wolf (3):
   ide: Check array bounds before writing to io_buffer (CVE-2015-5154)
   ide/atapi: Fix START STOP UNIT command completion
   ide: Clear DRQ after handling all expected accesses

  hw/ide/atapi.c |  1 +
  hw/ide/core.c  | 32 
  2 files changed, 29 insertions(+), 4 deletions(-)

Re: [Qemu-devel] [RFC PATCH 00/11] aio: Introduce handler type to fix nested aio_poll for dataplane



On 27/07/2015 08:55, Fam Zheng wrote:
 On Fri, 07/24 09:35, Paolo Bonzini wrote:
 That way, aio_context_acquire can be dropped by:

 /* @pause_owner_thread: a callback which will be called when _main 
 thread_
  * wants exclusively operate on the AioContext, for example with a 
 nested
  * aio_poll().
  * @resume_owner_thread: a callback which will be called when _main 
 thread_
  * has done the exclusive operation.
  */
 AioContext *aio_context_new(AioContextPauseResumeFn *pause_owner_thread,
 AioContextPauseResumeFn 
 *resume_owner_thread,
 void *opaque,
 Error **errp):

 /* Try to pause the owning thread */
 void aio_context_pause(AioContext *ctx, Error **errp);

 /* Try to resume the paused owning thread, cannot fail */
 void aio_context_resume(AioContext *ctx);

 Then, in iothread.c:

 iothread-ctx = aio_context_new(iothread_pause, iothread_resume,
 iothread, local_err);

 Where iothread_pause can block the thread with a QemuCond.

 Condition variables don't mix well with recursive mutexes...  Once we
 have bottom halves outside the AioContext lock, however, we could use a
 separate lock for this condition variable.  That would work.
 
 Yes, I thought so.
 
 I like it, but I still ask myself... what's the difference between
 aio_context_pause/resume and aio_disable/enable_clients? :)  There is
 still state, just in the iothread rather than in the AioContext.
 
 I don't know, maybe this will make aio_context_acquire no longer necessary so
 we get virtio-scsi dataplane fixed?

What you would have is:

1) the main thread calls aio_context_pause/resume, which wait for the
dataplane thread to pause

2) a paused I/O thread use a condition variable or something to wait for
the main thread to call aio_context_resume

In the end, this is still a lock.  For example in RFifoLock the critical
sections look like they are contained within rfifolock_lock and
rfifolock_unlock, but still RFifoLock is a lock and (as far as deadlocks
are concerned) behaves as if there is a single critical section between
rfifolock_lock and rfifolock_unlock.

So, the bdrv_aio_poll approach works great with the huge critical
sections that we have now.  We're effectively using the AioContext lock
_not_ to protect data, but just to shield iothread's usage of block
devices from the dataplane and vice versa.

That worked well as an initial step towards thread-safety (in fact, the
BQL itself is a single huge lock that protects code).  However, we will
however move towards fine-grained critical sections sooner or later;
besides virtio-scsi dataplane, they are also necessary in order to do
real multiqueue with multiple iothreads per BDS.

Once you make your locks protect data, things do become more complex
(more locks, more critical sections, etc.) but they can at the same time
be less scary.  You can reason in terms of invariants that hold at the
end of each critical section, and concurrency is not a big deal anymore
because your new tool (invariants) is both powerful and independent of
concurrency.

You don't have to worry about that now, however.
aio_disable_clients/aio_enable_clients for now can be protected by the
AioContext lock.  Later, it can be protected by whatever fine-grained
lock will protect the list of AioHandlers.

Paolo

[Qemu-devel] [PATCH] virtio-pci: fix memory MR cleanup for modern

Each memory_region_add_subregion must be paired with
memory_region_del_subregion.

Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
 hw/virtio/virtio-pci.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index db8f27c..c024161 100644
--- a/hw/virtio/virtio-pci.c
+++ b/hw/virtio/virtio-pci.c
@@ -1414,6 +1414,13 @@ static void virtio_pci_modern_region_map(VirtIOPCIProxy 
*proxy,
 virtio_pci_add_mem_cap(proxy, cap);
 }
 
+static void virtio_pci_modern_region_unmap(VirtIOPCIProxy *proxy,
+   VirtIOPCIRegion *region)
+{
+memory_region_del_subregion(proxy-modern_bar,
+region-mr);
+}
+
 /* This is called by virtio-bus just after the device is plugged. */
 static void virtio_pci_device_plugged(DeviceState *d, Error **errp)
 {
@@ -1520,8 +1527,16 @@ static void virtio_pci_device_plugged(DeviceState *d, 
Error **errp)
 static void virtio_pci_device_unplugged(DeviceState *d)
 {
 VirtIOPCIProxy *proxy = VIRTIO_PCI(d);
+bool modern = !(proxy-flags  VIRTIO_PCI_FLAG_DISABLE_MODERN);
 
 virtio_pci_stop_ioeventfd(proxy);
+
+if (modern) {
+virtio_pci_modern_region_unmap(proxy, proxy-common);
+virtio_pci_modern_region_unmap(proxy, proxy-isr);
+virtio_pci_modern_region_unmap(proxy, proxy-device);
+virtio_pci_modern_region_unmap(proxy, proxy-notify);
+}
 }
 
 static void virtio_pci_realize(PCIDevice *pci_dev, Error **errp)
-- 
MST

[Qemu-devel] [PULL for-2.4 11/16] mcf_fec: Drop mcf_fec_can_receive

From: Fam Zheng f...@redhat.com

The semantics of .can_receive requires us to flush the queue explicitly
when s-rx_enabled becomes true after it returns 0, but the packet being
queued is not meaningful since the guest hasn't activated the card.
Let's just drop the packet in this case.

Signed-off-by: Fam Zheng f...@redhat.com
Reviewed-by: Stefan Hajnoczi stefa...@redhat.com
Reviewed-by: Jason Wang jasow...@redhat.com
Message-id: 143693-22791-8-git-send-email-f...@redhat.com
Signed-off-by: Stefan Hajnoczi stefa...@redhat.com
---
 hw/net/mcf_fec.c | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/hw/net/mcf_fec.c b/hw/net/mcf_fec.c
index e63af1b..4e6939f 100644
--- a/hw/net/mcf_fec.c
+++ b/hw/net/mcf_fec.c
@@ -397,12 +397,6 @@ static void mcf_fec_write(void *opaque, hwaddr addr,
 mcf_fec_update(s);
 }
 
-static int mcf_fec_can_receive(NetClientState *nc)
-{
-mcf_fec_state *s = qemu_get_nic_opaque(nc);
-return s-rx_enabled;
-}
-
 static ssize_t mcf_fec_receive(NetClientState *nc, const uint8_t *buf, size_t 
size)
 {
 mcf_fec_state *s = qemu_get_nic_opaque(nc);
@@ -417,7 +411,7 @@ static ssize_t mcf_fec_receive(NetClientState *nc, const 
uint8_t *buf, size_t si
 
 DPRINTF(do_rx len %d\n, size);
 if (!s-rx_enabled) {
-fprintf(stderr, mcf_fec_receive: Unexpected packet\n);
+return -1;
 }
 /* 4 bytes for the CRC.  */
 size += 4;
@@ -490,7 +484,6 @@ static const MemoryRegionOps mcf_fec_ops = {
 static NetClientInfo net_mcf_fec_info = {
 .type = NET_CLIENT_OPTIONS_KIND_NIC,
 .size = sizeof(NICState),
-.can_receive = mcf_fec_can_receive,
 .receive = mcf_fec_receive,
 };
 
-- 
2.4.3

Re: [Qemu-devel] [PATCH RFC v2 22/47] qapi: QAPISchema code generation helper methods

On 07/27/2015 03:54 AM, Markus Armbruster wrote:
 Eric Blake ebl...@redhat.com writes:
 
 On 07/01/2015 02:22 PM, Markus Armbruster wrote:
 New methods c_name(), c_type(), c_null(), json_type(),
 alternate_qtype().

 Signed-off-by: Markus Armbruster arm...@redhat.com
 ---
  scripts/qapi.py | 72
 +++--
  1 file changed, 65 insertions(+), 7 deletions(-)


 I just noticed:

 @@ -779,6 +811,12 @@ class QAPISchemaEnumType(QAPISchemaType):
  for v in values:
  assert isinstance(v, str)
  self.values = values
 +def c_type(self, is_param=False):
 +return c_name(self.name)
 +def c_null(self):
 +return c_enum_const(self.name, self.values[0])

 What does this return for an empty enum, as in { 'enum':'Empty',
 'data':[] }?
 
 I suspect self.values will be [] then, and self.values[0] will bomb.
 
 Possible fixes:
 
 * Outlaw empty enums
 
 * Add the implicit MAX member to self.values[] (other code may have to
   skip it)
 
 * Catch the special case here, and return the implicit MAX member.

I'm leaning toward the third option here.

 
   Our testsuite proves we can do that, even if our normal
 .json code doesn't use it.
 
 tests/qapi-schema/enum-empty.json:{ 'enum': 'MyEnum', 'data': [ ] }

As I've mentioned elsewhere, most of our tests/qapi-schema/*.json merely
cover whether the parser is okay with the input, while
tests/qapi-schema/qapi-schema-test.json is the one that also tests that
the generated C code works; so sounds like that test should be enhanced
to cover some of these corner cases we have been considering in this
series (empty enum, command with no arguments and no returns, and so forth).

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [Qemu-stable] [PULL 0/3] Cve 2015 5154 patches

2015-07-27 Thread Peter Lieven


Am 27.07.2015 um 15:54 schrieb Kevin Wolf:

Am 27.07.2015 um 15:46 hat Peter Lieven geschrieben:

Am 27.07.2015 um 15:38 schrieb Kevin Wolf:

 Am 27.07.2015 um 15:25 hat Stefan Priebe - Profihost AG geschrieben:

 Am 27.07.2015 um 14:28 schrieb John Snow:


 On 07/27/2015 08:10 AM, Stefan Priebe - Profihost AG wrote:

 Am 27.07.2015 um 14:01 schrieb John Snow:

 The following changes since commit 
f793d97e454a56d17e404004867985622ca1a63b:

   Merge remote-tracking branch 
'remotes/bonzini/tags/for-upstream' into staging (2015-07-24 13:07:10 +0100)

 are available in the git repository at:

   https://github.com/jnsnow/qemu.git 
tags/cve-2015-5154-pull-request

 Any details on this CVE? Is RCE possible? Only if IDE is used?

 Stefan


 It's a heap overflow. The most likely outcome is a segfault, but 
the
 guest is allowed to continue writing past the end of the PIO 
buffer at
 its leisure. This makes it similar to CVE-2015-3456.

 This CVE can be mitigated unlike CVE-2015-3456 by just removing the
 CD-ROM drive until the patch can be applied.

 Thanks. The seclist article explicitly references xen. So it does not
 apply to qemu/kvm? Sorry for asking may be stupid questions.

 The IDE emulation is shared between Xen and KVM, so both are affected.
 The reason why the seclist mail only mentions Xen is probably because
 the Xen security team posted it.

 Meanwhile there is also a Red Hat CVE page available, which mentions
 qemu-kvm: https://access.redhat.com/security/cve/CVE-2015-5154


The redhat advisory says that some Redhat versions are not affected
because they did not backport the upstream commit that introduced this issue
.

Can you point out which commit exactly introduced the issue?

That's the commit that introduced the code fixed in patch 2: Commit
ce560dcf ('ATAPI: STARTSTOPUNIT only eject/load media if powercondition
is 0').


Okay, so as far as I can see this is in any Qemu = 1.3.0.

Peter

Re: [Qemu-devel] [PATCH RFC v2 25/47] qapi: Make generators work on sorted schema expressions

2015-07-27 Thread Markus Armbruster

Eric Blake ebl...@redhat.com writes:

 On 07/01/2015 02:22 PM, Markus Armbruster wrote:
 Order of expressions doesn't matter.  QAPISchema().get_exprs() returns
 expressions in the order they're parsed.
 
 I'm going to refactor this code.  To check refactorings, I want to
 diff the generated code, and for that I need to preserve its order.
 
 Since I don't feel like preserving parse order, I'm changing
 get_expr() to return the expressions sorted by name.  This order will
 be trivial to preserve.  It also makes the generated code slightly
 easier to navigate.

 Huge change to the generated files, but that's to be expected.  Diffstat
 shows it is not a straight 1:1 reshuffle:

  qapi-event.c  |  890 +--
  qapi-event.h  |  190
  qapi-types.c  | 1996 +++
  qapi-types.h  | 5420 ++--
  qapi-visit.c  | 9088 
 +-
  qapi-visit.h  |  746 +-
  qga/qapi-generated/qga-qapi-types.c   |  148
  qga/qapi-generated/qga-qapi-types.h   |  340 -
  qga/qapi-generated/qga-qapi-visit.c   |  446 -
  qga/qapi-generated/qga-qapi-visit.h   |   54
  qga/qapi-generated/qga-qmp-commands.h |   38
  qga/qapi-generated/qga-qmp-marshal.c  |  864 +--
  qmp-commands.h|  376 -
  13 files changed, 10308 insertions(+), 10288 deletions(-)

 but that's probably because you now emit forward declarations for things
 that occur alphabetically after their first use (since 8/47 in this
 series touched forward declarations), whereas before they happened to
 occurr in topological order from the parse.

Here's my cheap trick for sanity checking this commit: compare before
and after *sorted*.  Results:

* qapi-event.h
  - Members of enum QAPIEvent reordered, values changed accordingly (but
they shouldn't matter)

* qapi-visit.c
  - A bunch of new forward declarations

* test-qapi-visit.c
  - One forward declaration gone.

 Signed-off-by: Markus Armbruster arm...@redhat.com
 ---
  scripts/qapi.py | 9 -
  1 file changed, 8 insertions(+), 1 deletion(-)
 
 diff --git a/scripts/qapi.py b/scripts/qapi.py
 index cac7ab5..20ffdaf 100644
 --- a/scripts/qapi.py
 +++ b/scripts/qapi.py
 @@ -1017,7 +1017,14 @@ class QAPISchema(object):
  self.check()
  
  def get_exprs(self):
 -return [expr_elem['expr'] for expr_elem in self.exprs]
 +def expr_name(expr):
 +name = expr.get('enum') or expr.get('union') \
 +   or expr.get('alternate') or expr.get('struct') \
 +   or expr.get('command') or expr.get('event')
 +assert name
 +return name

 When I was working on this file earlier, I half toyed with the idea of
 adding expr_elem['name'] holding the entity name, and expr_elem['meta']
 holding what meta-type the entity represents; it might have made some of
 our later 6-way switches simpler.  But with your hierarchy of actual
 objects, I'm not sure my idea helps any more.

The more work we do with the new internal representation instead of the
syntax tree, the less it'll help.

 +return sorted([expr_elem['expr'] for expr_elem in self.exprs],
 +  key=expr_name)

 Python has some nice compact syntactical gems - I'd hate the amount of
 boilerplate required to write this same filter using straight C code :)

 Reviewed-by: Eric Blake ebl...@redhat.com

Thanks!

Re: [Qemu-devel] [PULL v2 for-2.4 v2 5/7] AioContext: fix broken ctx-dispatching optimization

On Fri, Jul 24, 2015 at 7:46 AM, Cornelia Huck cornelia.h...@de.ibm.com wrote:
 On Thu, 23 Jul 2015 21:29:05 +0200
 Christian Borntraeger borntrae...@de.ibm.com wrote:

 Am 23.07.2015 um 21:25 schrieb Paolo Bonzini:
 
 
  On 23/07/2015 21:19, Christian Borntraeger wrote:
  Am 23.07.2015 um 20:19 schrieb Paolo Bonzini:
 
 
  On 23/07/2015 19:20, Paolo Bonzini wrote:
 
 
  On 23/07/2015 16:14, Cornelia Huck wrote:
  (gdb) bt
  #0  0x03fffc5871b4 in pthread_cond_wait@@GLIBC_2.3.2 ()
 from /lib64/libpthread.so.0
  #1  0x8024cfca in qemu_cond_wait (cond=cond@entry=0x9717d950,
  mutex=mutex@entry=0x9717d920)
  at /data/git/yyy/qemu/util/qemu-thread-posix.c:132
  #2  0x8025e83a in rfifolock_lock (r=0x9717d920)
  at /data/git/yyy/qemu/util/rfifolock.c:59
  #3  0x801b78fa in aio_context_acquire (ctx=optimized out)
  at /data/git/yyy/qemu/async.c:331
  #4  0x8007ceb4 in virtio_blk_data_plane_start (s=0x9717d710)
  at /data/git/yyy/qemu/hw/block/dataplane/virtio-blk.c:285
  #5  0x8007c64a in virtio_blk_handle_output (vdev=optimized 
  out,
  vq=optimized out) at /data/git/yyy/qemu/hw/block/virtio-blk.c:599
  #6  0x801c56dc in qemu_iohandler_poll (pollfds=0x97142800,
  ret=ret@entry=1) at /data/git/yyy/qemu/iohandler.c:126
  #7  0x801c5178 in main_loop_wait (nonblocking=optimized out)
  at /data/git/yyy/qemu/main-loop.c:494
  #8  0x80013ee2 in main_loop () at /data/git/yyy/qemu/vl.c:1902
  #9  main (argc=optimized out, argv=optimized out, envp=optimized 
  out)
  at /data/git/yyy/qemu/vl.c:4653
 
  I've stripped down the setup to the following commandline:
 
  /data/git/yyy/qemu/build/s390x-softmmu/qemu-system-s390x  -machine
  s390-ccw-virtio-2.4,accel=kvm,usb=off -m 1024 -smp
  4,sockets=4,cores=1,threads=1 -nographic -drive
  file=/dev/sda,if=none,id=drive-virtio-disk0,format=raw,serial=ccwzfcp1,cache=none,aio=native
  -device
  virtio-blk-ccw,scsi=off,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,x-data-plane=on
 
  What's the backtrace like for the other threads?  This is almost
  definitely a latent bug somewhere else.
 
  BTW, I can reproduce this---I'm asking because I cannot even attach gdb
  to the hung process.
 
  The simplest workaround is to reintroduce commit a0710f7995 (iothread:
  release iothread around aio_poll, 2015-02-20), though it also comes with
  some risk.  It avoids the bug because it limits the contention on the
  RFifoLock.
 
  I can reproduce this with the following backtrace (with --enable-debug 
  info added qemu is the tag v2.4.0-rc2)
 
  Can you check that cherry-picking a0710f7995 works for you?
 

 Yes, this seems to help for me. Conny, can you verify?

 I can't reproduce the hang with this on top, so seems to help.

Thanks Christian and Cornelia.  I'm sending a fix.

Stefan

[Qemu-devel] [PULL 1/2] block: vpc - prevent overflow if max_table_entries = 0x40000000

From: Jeff Cody jc...@redhat.com

When we allocate the pagetable based on max_table_entries, we multiply
the max table entry value by 4 to accomodate a table of 32-bit integers.
However, max_table_entries is a uint32_t, and the VPC driver accepts
ranges for that entry over 0x4000.  So during this allocation:

s-pagetable = qemu_try_blockalign(bs-file, s-max_table_entries * 4);

The size arg overflows, allocating significantly less memory than
expected.

Since qemu_try_blockalign() size argument is size_t, cast the
multiplication correctly to prevent overflow.

The value of max_table_entries * 4 is used elsewhere in the code as
well, so store the correct value for use in all those cases.

We also check the Max Tables Entries value, to make sure that it is 
SIZE_MAX / 4, so we know the pagetable size will fit in size_t.

Cc: qemu-sta...@nongnu.org
Reported-by: Richard W.M. Jones rjo...@redhat.com
Signed-off-by: Jeff Cody jc...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
---
 block/vpc.c | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/block/vpc.c b/block/vpc.c
index 37572ba..3e385d9 100644
--- a/block/vpc.c
+++ b/block/vpc.c
@@ -168,6 +168,7 @@ static int vpc_open(BlockDriverState *bs, QDict *options, 
int flags,
 uint8_t buf[HEADER_SIZE];
 uint32_t checksum;
 uint64_t computed_size;
+uint64_t pagetable_size;
 int disk_type = VHD_DYNAMIC;
 int ret;
 
@@ -269,7 +270,17 @@ static int vpc_open(BlockDriverState *bs, QDict *options, 
int flags,
 goto fail;
 }
 
-s-pagetable = qemu_try_blockalign(bs-file, s-max_table_entries * 4);
+if (s-max_table_entries  SIZE_MAX / 4 ||
+s-max_table_entries  (int) INT_MAX / 4) {
+error_setg(errp, Max Table Entries too large (% PRId32 ),
+s-max_table_entries);
+ret = -EINVAL;
+goto fail;
+}
+
+pagetable_size = (uint64_t) s-max_table_entries * 4;
+
+s-pagetable = qemu_try_blockalign(bs-file, pagetable_size);
 if (s-pagetable == NULL) {
 ret = -ENOMEM;
 goto fail;
@@ -277,14 +288,13 @@ static int vpc_open(BlockDriverState *bs, QDict *options, 
int flags,
 
 s-bat_offset = be64_to_cpu(dyndisk_header-table_offset);
 
-ret = bdrv_pread(bs-file, s-bat_offset, s-pagetable,
- s-max_table_entries * 4);
+ret = bdrv_pread(bs-file, s-bat_offset, s-pagetable, 
pagetable_size);
 if (ret  0) {
 goto fail;
 }
 
 s-free_data_block_offset =
-(s-bat_offset + (s-max_table_entries * 4) + 511)  ~511;
+ROUND_UP(s-bat_offset + pagetable_size, 512);
 
 for (i = 0; i  s-max_table_entries; i++) {
 be32_to_cpus(s-pagetable[i]);
-- 
1.8.3.1

[Qemu-devel] [PULL 0/2] Block layer patches for 2.4.0-rc3

The following changes since commit 122e7dab8ac549c8c5a9e1e13aa2464190e888de:

  Merge remote-tracking branch 'remotes/stefanha/tags/net-pull-request' into 
staging (2015-07-27 14:53:42 +0100)

are available in the git repository at:


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

for you to fetch changes up to 77c102c26ead946fe7589d4bddcdfa5cb431ebfe:

  block: qemu-iotests - add check for multiplication overflow in vpc 
(2015-07-27 17:19:07 +0200)


Block layer patches for 2.4.0-rc3


Jeff Cody (2):
  block: vpc - prevent overflow if max_table_entries = 0x4000
  block: qemu-iotests - add check for multiplication overflow in vpc

 block/vpc.c   |  18 +++--
 tests/qemu-iotests/135|  54 ++
 tests/qemu-iotests/135.out|   5 +++
 tests/qemu-iotests/group  |   1 +
 tests/qemu-iotests/sample_images/afl5.img.bz2 | Bin 0 - 175 bytes
 5 files changed, 74 insertions(+), 4 deletions(-)
 create mode 100755 tests/qemu-iotests/135
 create mode 100644 tests/qemu-iotests/135.out
 create mode 100644 tests/qemu-iotests/sample_images/afl5.img.bz2

[Qemu-devel] [PATCH v9 00/10] qcow2: Support refcount order amendment

2015-07-27 Thread Max Reitz

(v1..v7 were named qcow2: Support refcount orders != 4)

This series contains the final 10 patches of my qcow2 refcount order
series, which add refcount order amendment functionality to qemu-img.


v9:
- Rebase on master
- Patch 8: s/qerror_report_err/error_report_err/


git backport-diff against v8:

Key:
[] : patches are identical
[] : number of functional differences between upstream/downstream patch
[down] : patch is downstream-only
The flags [FC] indicate (F)unctional and (C)ontextual differences, respectively

001/10:[] [--] 'progress: Allow regressing progress'
002/10:[] [--] 'block: Add opaque value to the amend CB'
003/10:[] [-C] 'qcow2: Use error_report() in qcow2_amend_options()'
004/10:[] [--] 'qcow2: Use abort() instead of assert(false)'
005/10:[] [--] 'qcow2: Split upgrade/downgrade paths for amend'
006/10:[] [--] 'qcow2: Use intermediate helper CB for amend'
007/10:[] [--] 'qcow2: Add function for refcount order amendment'
008/10:[0002] [FC] 'qcow2: Invoke refcount order amendment function'
009/10:[] [--] 'qcow2: Point to amend function in check'
010/10:[] [--] 'iotests: Extend test 112 for qemu-img amend'


Max Reitz (10):
  progress: Allow regressing progress
  block: Add opaque value to the amend CB
  qcow2: Use error_report() in qcow2_amend_options()
  qcow2: Use abort() instead of assert(false)
  qcow2: Split upgrade/downgrade paths for amend
  qcow2: Use intermediate helper CB for amend
  qcow2: Add function for refcount order amendment
  qcow2: Invoke refcount order amendment function
  qcow2: Point to amend function in check
  iotests: Extend test 112 for qemu-img amend

 block.c|   4 +-
 block/qcow2-cluster.c  |  14 +-
 block/qcow2-refcount.c | 450 +
 block/qcow2.c  | 178 ++
 block/qcow2.h  |   7 +-
 include/block/block.h  |   4 +-
 include/block/block_int.h  |   3 +-
 qemu-img.c |   5 +-
 tests/qemu-iotests/061.out |  14 +-
 tests/qemu-iotests/112 | 109 +++
 tests/qemu-iotests/112.out |  71 +++
 util/qemu-progress.c   |   3 +-
 12 files changed, 803 insertions(+), 59 deletions(-)

-- 
2.4.6

[Qemu-devel] [PATCH v9 04/10] qcow2: Use abort() instead of assert(false)

2015-07-27 Thread Max Reitz

Signed-off-by: Max Reitz mre...@redhat.com
Reviewed-by: Eric Blake ebl...@redhat.com
Reviewed-by: Stefan Hajnoczi stefa...@redhat.com
Reviewed-by: Alberto Garcia be...@igalia.com
---
 block/qcow2.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/block/qcow2.c b/block/qcow2.c
index 3bcb96e..a7f50db 100644
--- a/block/qcow2.c
+++ b/block/qcow2.c
@@ -2751,9 +2751,9 @@ static int qcow2_amend_options(BlockDriverState *bs, 
QemuOpts *opts,
 error_report(Cannot change refcount entry width);
 return -ENOTSUP;
 } else {
-/* if this assertion fails, this probably means a new option was
+/* if this point is reached, this probably means a new option was
  * added without having it covered here */
-assert(false);
+abort();
 }
 
 desc++;
-- 
2.4.6

Re: [Qemu-devel] [PATCH v3] hw/arm/virt: Add high MMIO PCI region

2015-07-27 Thread Peter Maydell

On 27 July 2015 at 16:18, Michael S. Tsirkin m...@redhat.com wrote:
 It's more a question of figuring out what does real hardware do.
 It's true, PIIX has this everything that isn't memory is PCI
 assumption. We do this for Q35 but I'm not even sure it's the
 right thing to do there.

 If as you say real ARM hardware doesn't work like this, then QEMU
 shouldn't do this for ARM.

Real ARM hardware might do a variety of things varying between
we just have some windows and we do things exactly like
how an x86 PC does. The architecture doesn't care.

I don't know what the restrictions of the kernel's generic
PCIe handling are, whether it insists on specific windows
or can handle the everything in the background is a window
configuration as well. The dt binding doc for it implies not.

thanks
-- PMM

Re: [Qemu-devel] [PATCH v9 08/10] qcow2: Invoke refcount order amendment function