Re: [Qemu-devel] [PATCH v4 3/4] migration: disallow migrate_add_blocker during migration

[Greg Kurz]

On Mon,  9 Jan 2017 22:32:47 +0530
Ashijeet Acharya  wrote:
> [...]
> diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
> index faebd91..c823a44 100644
> --- a/hw/9pfs/9p.c
> +++ b/hw/9pfs/9p.c
> @@ -1013,20 +1013,28 @@ static void coroutine_fn v9fs_attach(void *opaque)
>  goto out;
>  }
>  err += offset;
> -memcpy(&s->root_qid, &qid, sizeof(qid));
> -trace_v9fs_attach_return(pdu->tag, pdu->id,
> - qid.type, qid.version, qid.path);
> +
>  /*
>   * disable migration if we haven't done already.
>   * attach could get called multiple times for the same export.
>   */
>  if (!s->migration_blocker) {
> -s->root_fid = fid;
>  error_setg(&s->migration_blocker,
> "Migration is disabled when VirtFS export path '%s' is 
> mounted in the guest using mount_tag '%s'",
> s->ctx.fs_root ? s->ctx.fs_root : "NULL", s->tag);
> -migrate_add_blocker(s->migration_blocker);
> +err = migrate_add_blocker(s->migration_blocker, NULL);
> +if (err < 0) {
> +error_free(s->migration_blocker);
> +s->migration_blocker = NULL;
> +clunk_fid(s, fid);
> +goto out;
> +}
> +s->root_fid = fid;
>  }

Hmm... my suggestion was to deal with the migration blocker before the call
to pdu_marshal() since there's no point in copying the qid if we're about
to return an error back to the guest.

> +
> +memcpy(&s->root_qid, &qid, sizeof(qid));
> +trace_v9fs_attach_return(pdu->tag, pdu->id,
> + qid.type, qid.version, qid.path);
>  out:
>  put_fid(pdu, fidp);
>  out_nofid:

Re: [Qemu-devel] implementing architectural timers using QEMU timers

[Pavel Dovgalyuk]

> From: Max Filippov [mailto:jcmvb...@gmail.com]

> I'm trying to reimplement xtensa CCOUNT (cycle counter) and
> CCOMPARE (CCOUNT-based timer interrupts) using QEMU
> timers. That is CCOUNT value is derived from the
> QEMU_CLOCK_VIRTUAL clock and CCOMPARE interrupts are
> generated from the QEMU_CLOCK_VIRTUAL timer callbacks.
> The code is here:
>   https://github.com/OSLL/qemu-xtensa/commits/xtensa-ccount
> 
> I've got the following issues doing that:
> 
> - I thought that could be improved in -icount mode, so I tried that.
>   It is better with -icount, but it's still not 100% accurate. That is
>   I was able to observe guest reading QEMU clock value that is
>   past QEMU timer deadline before that timer callback was
>   invoked.

icount is meant to be 100% accurate.
tcg_get_icount_limit function calculates the deadline before the soonest
virtual timer and executes number of instructions that will fit this
timeout.

Maybe you need the accuracy that is higher than the precision of the virtual 
clock?
Every executed instruction in icount mode takes fixed period of virtual time.

Pavel Dovgalyuk

Re: [Qemu-devel] [PATCH] pcie: remove duplicate assertion

[Cao jin]

On 01/10/2017 06:37 AM, Michael S. Tsirkin wrote:
> On Fri, Dec 23, 2016 at 10:16:30AM +0800, Cao jin wrote:
>> "size >= 8" connote "size > 0"
>>
>> Signed-off-by: Cao jin 
> 
> Isn't the point to check for overflows?
> 

Make sense. If it is intended to check overflows, the following sequence
would make more sense:

assert(offset >= PCI_CONFIG_SPACE_SIZE);
assert(size >= 8);
assert(offset < offset + size);
assert(offset + size <= PCIE_CONFIG_SPACE_SIZE);

or else, size 0 will pass the assert(offset < offset + size) first and
hit assert(size >= 8)
-- 
Sincerely,
Cao jin

>> ---
>>  hw/pci/pcie.c | 1 -
>>  1 file changed, 1 deletion(-)
>>
>> diff --git a/hw/pci/pcie.c b/hw/pci/pcie.c
>> index 39b10b852d91..f864c5cd5458 100644
>> --- a/hw/pci/pcie.c
>> +++ b/hw/pci/pcie.c
>> @@ -668,7 +668,6 @@ void pcie_add_capability(PCIDevice *dev,
>>  uint16_t next;
>>  
>>  assert(offset >= PCI_CONFIG_SPACE_SIZE);
>> -assert(offset < offset + size);
>>  assert(offset + size <= PCIE_CONFIG_SPACE_SIZE);
>>  assert(size >= 8);
>>  assert(pci_is_express(dev));
>> -- 
>> 2.1.0
>>
>>
> 
> 
> 

Re: [Qemu-devel] [PATCH v7 01/21] qapi: replace 'o' for list items

[Markus Armbruster]

Marc-André Lureau  writes:

> Replace with '*', the common form for list items.
>
> Signed-off-by: Marc-André Lureau 

Reviewed-by: Markus Armbruster 

[Qemu-devel] [PATCH 01/11] target-ppc: xscvqpdp zero VSR

[Nikunj A Dadhania]

Signed-off-by: Nikunj A Dadhania 
---
 target/ppc/fpu_helper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/ppc/fpu_helper.c b/target/ppc/fpu_helper.c
index 8c8e3c5..77f68e9 100644
--- a/target/ppc/fpu_helper.c
+++ b/target/ppc/fpu_helper.c
@@ -2787,7 +2787,7 @@ void helper_xscvqpdp(CPUPPCState *env, uint32_t opcode)
 ppc_vsr_t xt, xb;
 
 getVSR(rB(opcode) + 32, &xb, env);
-getVSR(rD(opcode) + 32, &xt, env);
+memset(&xt, 0, sizeof(xt));
 
 if (unlikely(Rc(opcode) != 0)) {
 /* TODO: Support xscvqpdpo after round-to-odd is implemented */
-- 
2.7.4

[Qemu-devel] [PATCH 00/11] POWER9 TCG enablements - part11

[Nikunj A Dadhania]

This series contains 10 new instructions for POWER9 ISA3.0
VSX Scalar Insert Exponent
VSX Vector Insert Exponent
VSX Vector Extract Exponent/Significand
VSX Scalar Truncate & Convert Quad-Precision
Couple of fixes

Bharata B Rao (2):
  softfloat: Fix the default qNAN for target-ppc
  target-ppc: Add xscvqps[d,w]z instructions

Nikunj A Dadhania (9):
  target-ppc: xscvqpdp zero VSR
  target-ppc: Add xsiexpdp instruction
  target-ppc: Add xsiexpqp instruction
  target-ppc: Add xviexpsp instruction
  target-ppc: Add xviexpdp instruction
  target-ppc: Add xvxexpsp instruction
  target-ppc: Add xvxexpdp instruction
  target-ppc: Add xvxsigsp instruction
  target-ppc: Add xvxsigdp instruction

 fpu/softfloat-specialize.h  |   2 +-
 target/ppc/fpu_helper.c |  62 -
 target/ppc/helper.h |   3 +
 target/ppc/translate/vsx-impl.inc.c | 172 
 target/ppc/translate/vsx-ops.inc.c  |  11 +++
 5 files changed, 248 insertions(+), 2 deletions(-)

-- 
2.7.4

[Qemu-devel] [PATCH 07/11] target-ppc: Add xvxexpsp instruction

[Nikunj A Dadhania]

xvxexpsp: VSX Vector Extract Exponent Single Precision

Signed-off-by: Nikunj A Dadhania 
---
 target/ppc/translate/vsx-impl.inc.c | 17 +
 target/ppc/translate/vsx-ops.inc.c  |  1 +
 2 files changed, 18 insertions(+)

diff --git a/target/ppc/translate/vsx-impl.inc.c 
b/target/ppc/translate/vsx-impl.inc.c
index b66272e..160a80c 100644
--- a/target/ppc/translate/vsx-impl.inc.c
+++ b/target/ppc/translate/vsx-impl.inc.c
@@ -1396,6 +1396,23 @@ static void gen_xviexpdp(DisasContext *ctx)
 tcg_temp_free_i64(t0);
 }
 
+static void gen_xvxexpsp(DisasContext *ctx)
+{
+TCGv_i64 xth = cpu_vsrh(xT(ctx->opcode));
+TCGv_i64 xtl = cpu_vsrl(xT(ctx->opcode));
+TCGv_i64 xbh = cpu_vsrh(xB(ctx->opcode));
+TCGv_i64 xbl = cpu_vsrl(xB(ctx->opcode));
+
+if (unlikely(!ctx->vsx_enabled)) {
+gen_exception(ctx, POWERPC_EXCP_VSXU);
+return;
+}
+tcg_gen_shri_i64(xth, xbh, 23);
+tcg_gen_andi_i64(xth, xth, 0xFF00FF);
+tcg_gen_shri_i64(xtl, xbl, 23);
+tcg_gen_andi_i64(xtl, xtl, 0xFF00FF);
+}
+
 #undef GEN_XX2FORM
 #undef GEN_XX3FORM
 #undef GEN_XX2IFORM
diff --git a/target/ppc/translate/vsx-ops.inc.c 
b/target/ppc/translate/vsx-ops.inc.c
index 253a5c4..eb7334a 100644
--- a/target/ppc/translate/vsx-ops.inc.c
+++ b/target/ppc/translate/vsx-ops.inc.c
@@ -126,6 +126,7 @@ GEN_VSX_XFORM_300(xsiexpqp, 0x4, 0x1B, 0x0001),
 
 GEN_XX3FORM(xviexpsp, 0x00, 0x1B, PPC2_ISA300),
 GEN_XX3FORM(xviexpdp, 0x00, 0x1F, PPC2_ISA300),
+GEN_XX2FORM_EO(xvxexpsp, 0x16, 0x1D, 0x08, PPC2_ISA300),
 
 GEN_XX2FORM(xvabsdp, 0x12, 0x1D, PPC2_VSX),
 GEN_XX2FORM(xvnabsdp, 0x12, 0x1E, PPC2_VSX),
-- 
2.7.4

Re: [Qemu-devel] [PATCH v7 02/21] qapi: move QKeyCode doc body at the top

[Markus Armbruster]

Marc-André Lureau  writes:

> Following documentation guidelines.
>
> Signed-off-by: Marc-André Lureau 

Reviewed-by: Markus Armbruster 

[Qemu-devel] [PATCH 05/11] target-ppc: Add xviexpsp instruction

[Nikunj A Dadhania]

xviexpsp: VSX Vector Insert Exponent Single Precision

Signed-off-by: Nikunj A Dadhania 
---
 target/ppc/translate/vsx-impl.inc.c | 26 ++
 target/ppc/translate/vsx-ops.inc.c  |  2 ++
 2 files changed, 28 insertions(+)

diff --git a/target/ppc/translate/vsx-impl.inc.c 
b/target/ppc/translate/vsx-impl.inc.c
index ed392aa..c86f1b5 100644
--- a/target/ppc/translate/vsx-impl.inc.c
+++ b/target/ppc/translate/vsx-impl.inc.c
@@ -1344,6 +1344,32 @@ static void gen_xsxsigqp(DisasContext *ctx)
 }
 #endif
 
+static void gen_xviexpsp(DisasContext *ctx)
+{
+TCGv_i64 xth = cpu_vsrh(xT(ctx->opcode));
+TCGv_i64 xtl = cpu_vsrl(xT(ctx->opcode));
+TCGv_i64 xah = cpu_vsrh(xA(ctx->opcode));
+TCGv_i64 xal = cpu_vsrl(xA(ctx->opcode));
+TCGv_i64 xbh = cpu_vsrh(xB(ctx->opcode));
+TCGv_i64 xbl = cpu_vsrl(xB(ctx->opcode));
+TCGv_i64 t0;
+
+if (unlikely(!ctx->vsx_enabled)) {
+gen_exception(ctx, POWERPC_EXCP_VSXU);
+return;
+}
+t0 = tcg_temp_new_i64();
+tcg_gen_andi_i64(xth, xah, 0x807F807F);
+tcg_gen_andi_i64(t0, xbh, 0xFF00FF);
+tcg_gen_shli_i64(t0, t0, 23);
+tcg_gen_or_i64(xth, xth, t0);
+tcg_gen_andi_i64(xtl, xal, 0x807F807F);
+tcg_gen_andi_i64(t0, xbl, 0xFF00FF);
+tcg_gen_shli_i64(t0, t0, 23);
+tcg_gen_or_i64(xtl, xtl, t0);
+tcg_temp_free_i64(t0);
+}
+
 #undef GEN_XX2FORM
 #undef GEN_XX3FORM
 #undef GEN_XX2IFORM
diff --git a/target/ppc/translate/vsx-ops.inc.c 
b/target/ppc/translate/vsx-ops.inc.c
index 09b91c3..93752f0 100644
--- a/target/ppc/translate/vsx-ops.inc.c
+++ b/target/ppc/translate/vsx-ops.inc.c
@@ -124,6 +124,8 @@ GEN_HANDLER_E(xsiexpdp, 0x3C, 0x16, 0x1C, 0, PPC_NONE, 
PPC2_ISA300),
 GEN_VSX_XFORM_300(xsiexpqp, 0x4, 0x1B, 0x0001),
 #endif
 
+GEN_XX3FORM(xviexpsp, 0x00, 0x1B, PPC2_ISA300),
+
 GEN_XX2FORM(xvabsdp, 0x12, 0x1D, PPC2_VSX),
 GEN_XX2FORM(xvnabsdp, 0x12, 0x1E, PPC2_VSX),
 GEN_XX2FORM(xvnegdp, 0x12, 0x1F, PPC2_VSX),
-- 
2.7.4

[Qemu-devel] [PATCH 09/11] target-ppc: Add xvxsigsp instruction

[Nikunj A Dadhania]

xvxsigsp: VSX Vector Extract Significand Single Precision

Signed-off-by: Nikunj A Dadhania 
---
 target/ppc/fpu_helper.c | 20 
 target/ppc/helper.h |  1 +
 target/ppc/translate/vsx-impl.inc.c |  2 ++
 target/ppc/translate/vsx-ops.inc.c  |  1 +
 4 files changed, 24 insertions(+)

diff --git a/target/ppc/fpu_helper.c b/target/ppc/fpu_helper.c
index 77f68e9..4da83d9 100644
--- a/target/ppc/fpu_helper.c
+++ b/target/ppc/fpu_helper.c
@@ -3026,3 +3026,23 @@ void helper_##op(CPUPPCState *env, uint32_t opcode)  
 \
 
 VSX_XXPERM(xxperm, 0)
 VSX_XXPERM(xxpermr, 1)
+
+void helper_xvxsigsp(CPUPPCState *env, uint32_t opcode)
+{
+ppc_vsr_t xt, xb;
+uint32_t exp, i, fraction;
+
+getVSR(xB(opcode), &xb, env);
+memset(&xt, 0, sizeof(xt));
+
+for (i = 0; i < 4; i++) {
+exp = (xb.VsrW(i) >> 23) & 0xFF;
+fraction = xb.VsrW(i) & 0x7F;
+if (exp != 0 && exp != 255) {
+xt.VsrW(i) = fraction | 0x0080;
+} else {
+xt.VsrW(i) = fraction;
+}
+}
+putVSR(xT(opcode), &xt, env);
+}
diff --git a/target/ppc/helper.h b/target/ppc/helper.h
index f28bf62..27607bf 100644
--- a/target/ppc/helper.h
+++ b/target/ppc/helper.h
@@ -547,6 +547,7 @@ DEF_HELPER_2(xxperm, void, env, i32)
 DEF_HELPER_2(xxpermr, void, env, i32)
 DEF_HELPER_4(xxextractuw, void, env, tl, tl, i32)
 DEF_HELPER_4(xxinsertw, void, env, tl, tl, i32)
+DEF_HELPER_2(xvxsigsp, void, env, i32)
 
 DEF_HELPER_2(efscfsi, i32, env, i32)
 DEF_HELPER_2(efscfui, i32, env, i32)
diff --git a/target/ppc/translate/vsx-impl.inc.c 
b/target/ppc/translate/vsx-impl.inc.c
index 7b26f75..4e57af7 100644
--- a/target/ppc/translate/vsx-impl.inc.c
+++ b/target/ppc/translate/vsx-impl.inc.c
@@ -1430,6 +1430,8 @@ static void gen_xvxexpdp(DisasContext *ctx)
 tcg_gen_andi_i64(xtl, xtl, 0x7FF);
 }
 
+GEN_VSX_HELPER_2(xvxsigsp, 0x00, 0x04, 0, PPC2_ISA300)
+
 #undef GEN_XX2FORM
 #undef GEN_XX3FORM
 #undef GEN_XX2IFORM
diff --git a/target/ppc/translate/vsx-ops.inc.c 
b/target/ppc/translate/vsx-ops.inc.c
index a3061ce..2c4f641 100644
--- a/target/ppc/translate/vsx-ops.inc.c
+++ b/target/ppc/translate/vsx-ops.inc.c
@@ -128,6 +128,7 @@ GEN_XX3FORM(xviexpsp, 0x00, 0x1B, PPC2_ISA300),
 GEN_XX3FORM(xviexpdp, 0x00, 0x1F, PPC2_ISA300),
 GEN_XX2FORM_EO(xvxexpdp, 0x16, 0x1D, 0x00, PPC2_ISA300),
 GEN_XX2FORM_EO(xvxexpsp, 0x16, 0x1D, 0x08, PPC2_ISA300),
+GEN_XX2FORM_EO(xvxsigsp, 0x16, 0x1D, 0x09, PPC2_ISA300),
 
 GEN_XX2FORM(xvabsdp, 0x12, 0x1D, PPC2_VSX),
 GEN_XX2FORM(xvnabsdp, 0x12, 0x1E, PPC2_VSX),
-- 
2.7.4

[Qemu-devel] [PATCH 02/11] softfloat: Fix the default qNAN for target-ppc

[Nikunj A Dadhania]

From: Bharata B Rao 

Currently float128_default_nan() returns 0x8000 in the
higher double word, but it should return 0x7FFF8000 which
is the correct higher double word for default qNAN on PowerPC.

Signed-off-by: Bharata B Rao 
Signed-off-by: Nikunj A Dadhania 
---
 fpu/softfloat-specialize.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fpu/softfloat-specialize.h b/fpu/softfloat-specialize.h
index f5aed72..7228b30 100644
--- a/fpu/softfloat-specialize.h
+++ b/fpu/softfloat-specialize.h
@@ -181,7 +181,7 @@ float128 float128_default_nan(float_status *status)
 r.high = LIT64(0x7FFF7FFF);
 } else {
 r.low = LIT64(0x);
-#if defined(TARGET_S390X)
+#if defined(TARGET_S390X) || defined(TARGET_PPC)
 r.high = LIT64(0x7FFF8000);
 #else
 r.high = LIT64(0x8000);
-- 
2.7.4

[Qemu-devel] [Bug 775604] Re: Could not open SDL display when running XP as guest

[Daniel Phillips]

Thanks for following up. I am no longer using QEMU.

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

Title:
  Could not open SDL display when running XP as guest

Status in QEMU:
  Incomplete

Bug description:
  When running XP as guest on Linux 2.6.38 x86_64 (Arch Linux) in full
  screen qemu will crash. Dropping to 1400x900 or below does not have a
  problem nor does windowed mode.

  1. Running:
  qemu-system-x86_64 -vga std -full-screen 
Virtual_Machines/Windows_XP/Windows_XP.img

  Produces error:
  Could not open SDL display (1920x1200x0): No video mode large enough for 
1920x1200

  qemu-kvm version 0.14.0-1

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

[Qemu-devel] [PATCH 03/11] target-ppc: Add xsiexpdp instruction

[Nikunj A Dadhania]

xsiexpdp: VSX Scalar Insert Exponent Double Precision

Signed-off-by: Nikunj A Dadhania 
---
 target/ppc/translate/vsx-impl.inc.c | 20 
 target/ppc/translate/vsx-ops.inc.c  |  1 +
 2 files changed, 21 insertions(+)

diff --git a/target/ppc/translate/vsx-impl.inc.c 
b/target/ppc/translate/vsx-impl.inc.c
index 2d9fe50..2d09225 100644
--- a/target/ppc/translate/vsx-impl.inc.c
+++ b/target/ppc/translate/vsx-impl.inc.c
@@ -1243,6 +1243,26 @@ static void gen_xsxexpqp(DisasContext *ctx)
 tcg_gen_movi_i64(xtl, 0);
 }
 
+static void gen_xsiexpdp(DisasContext *ctx)
+{
+TCGv_i64 xth = cpu_vsrh(xT(ctx->opcode));
+TCGv ra = cpu_gpr[rA(ctx->opcode)];
+TCGv rb = cpu_gpr[rB(ctx->opcode)];
+TCGv_i64 t0;
+
+if (unlikely(!ctx->vsx_enabled)) {
+gen_exception(ctx, POWERPC_EXCP_VSXU);
+return;
+}
+t0 = tcg_temp_new_i64();
+tcg_gen_andi_i64(xth, ra, 0x800F);
+tcg_gen_andi_i64(t0, rb, 0x7FF);
+tcg_gen_shli_i64(t0, t0, 52);
+tcg_gen_or_i64(xth, xth, t0);
+/* dword[1] is undefined */
+tcg_temp_free_i64(t0);
+}
+
 static void gen_xsxsigdp(DisasContext *ctx)
 {
 TCGv rt = cpu_gpr[rD(ctx->opcode)];
diff --git a/target/ppc/translate/vsx-ops.inc.c 
b/target/ppc/translate/vsx-ops.inc.c
index aeeaff2..5980ac6 100644
--- a/target/ppc/translate/vsx-ops.inc.c
+++ b/target/ppc/translate/vsx-ops.inc.c
@@ -120,6 +120,7 @@ GEN_XX2FORM_EO(xsxexpdp, 0x16, 0x15, 0x00, PPC2_ISA300),
 GEN_VSX_XFORM_300_EO(xsxexpqp, 0x04, 0x19, 0x02, 0x0001),
 GEN_XX2FORM_EO(xsxsigdp, 0x16, 0x15, 0x01, PPC2_ISA300),
 GEN_VSX_XFORM_300_EO(xsxsigqp, 0x04, 0x19, 0x12, 0x0001),
+GEN_HANDLER_E(xsiexpdp, 0x3C, 0x16, 0x1C, 0, PPC_NONE, PPC2_ISA300),
 #endif
 
 GEN_XX2FORM(xvabsdp, 0x12, 0x1D, PPC2_VSX),
-- 
2.7.4

[Qemu-devel] [PATCH 04/11] target-ppc: Add xsiexpqp instruction

[Nikunj A Dadhania]

xsiexpqp: VSX Scalar Insert Exponent Quad Precision

Signed-off-by: Nikunj A Dadhania 
---
 target/ppc/translate/vsx-impl.inc.c | 22 ++
 target/ppc/translate/vsx-ops.inc.c  |  1 +
 2 files changed, 23 insertions(+)

diff --git a/target/ppc/translate/vsx-impl.inc.c 
b/target/ppc/translate/vsx-impl.inc.c
index 2d09225..ed392aa 100644
--- a/target/ppc/translate/vsx-impl.inc.c
+++ b/target/ppc/translate/vsx-impl.inc.c
@@ -1263,6 +1263,28 @@ static void gen_xsiexpdp(DisasContext *ctx)
 tcg_temp_free_i64(t0);
 }
 
+static void gen_xsiexpqp(DisasContext *ctx)
+{
+TCGv_i64 xth = cpu_vsrh(rD(ctx->opcode) + 32);
+TCGv_i64 xtl = cpu_vsrl(rD(ctx->opcode) + 32);
+TCGv_i64 xah = cpu_vsrh(rA(ctx->opcode) + 32);
+TCGv_i64 xal = cpu_vsrl(rA(ctx->opcode) + 32);
+TCGv_i64 xbh = cpu_vsrh(rB(ctx->opcode) + 32);
+TCGv_i64 t0;
+
+if (unlikely(!ctx->vsx_enabled)) {
+gen_exception(ctx, POWERPC_EXCP_VSXU);
+return;
+}
+t0 = tcg_temp_new_i64();
+tcg_gen_andi_i64(xth, xah, 0x8000);
+tcg_gen_andi_i64(t0, xbh, 0x7FFF);
+tcg_gen_shli_i64(t0, t0, 48);
+tcg_gen_or_i64(xth, xth, t0);
+tcg_gen_mov_i64(xtl, xal);
+tcg_temp_free_i64(t0);
+}
+
 static void gen_xsxsigdp(DisasContext *ctx)
 {
 TCGv rt = cpu_gpr[rD(ctx->opcode)];
diff --git a/target/ppc/translate/vsx-ops.inc.c 
b/target/ppc/translate/vsx-ops.inc.c
index 5980ac6..09b91c3 100644
--- a/target/ppc/translate/vsx-ops.inc.c
+++ b/target/ppc/translate/vsx-ops.inc.c
@@ -121,6 +121,7 @@ GEN_VSX_XFORM_300_EO(xsxexpqp, 0x04, 0x19, 0x02, 
0x0001),
 GEN_XX2FORM_EO(xsxsigdp, 0x16, 0x15, 0x01, PPC2_ISA300),
 GEN_VSX_XFORM_300_EO(xsxsigqp, 0x04, 0x19, 0x12, 0x0001),
 GEN_HANDLER_E(xsiexpdp, 0x3C, 0x16, 0x1C, 0, PPC_NONE, PPC2_ISA300),
+GEN_VSX_XFORM_300(xsiexpqp, 0x4, 0x1B, 0x0001),
 #endif
 
 GEN_XX2FORM(xvabsdp, 0x12, 0x1D, PPC2_VSX),
-- 
2.7.4

Re: [Qemu-devel] Question about add AF_ALG backend for virtio-crypto

[Gonglei (Arei)]

Hi,

> 
> On Mon, Jan 09, 2017 at 01:43:10PM +, Stefan Hajnoczi wrote:
> > On Mon, Jan 09, 2017 at 03:04:55PM +0800, Longpeng (Mike) wrote:
> > > I'm one of Gonglei's virtio-crypto project members, and we plan to add a
> AF_ALG
> > > backend for virtio-crypto(there's only builtin-backend currently).
> > >
> > > I found that Catalin, Paolo and Stefan had discussed about this in 2015
> > > (http://www.spinics.net/lists/kvm/msg115457.html), but it seems that
> Catalin
> > > didn't do it, so I'm confuse about wether it is need to add a AF_ALG
> backend.
> > >
> > > Do you have any suggestion? Thanks :)
> >
> > I have no objections to an AF_ALG backend in QEMU.
> 
> Rather than do another backend for virtio-crypto, IMHO, we should have
> an AF_ALG impl of the crypto/ APIs. That way any potential performance
> benefits will enhance our LUKS encryption code too.
> 
According to the currently schemas of crypto/ APIs, we can't choose the
specific backend dynamically. This is a limitation for virtio-crypto device I 
think.

If an AF_ALG backend is supported, we can directly use the hardware
accelerators based on LKCF, which makes many sense.

Regards,
-Gonglei

Re: [Qemu-devel] [PATCH 3/3] fix qmp/hmp query-memdev not repporting IDs of memory backends

[Igor Mammedov]

On Mon, 9 Jan 2017 14:26:28 -0600
Eric Blake  wrote:

> On 01/09/2017 08:17 AM, Igor Mammedov wrote:
> 
> >> Wait. Isn't this going to inject an 'id' dict member to every use of
> >> user_creatable_add_type()?  But not all QAPI structs contain an id
> >> member.  Which means that you are now explicitly relying on the visitor
> >> to silently ignore garbage in the dictionary, rather than our desired
> >> goal of only validating if the dictionary exactly matches what the QAPI
> >> says it will match.
> >>
> >> I'm not sure if I like this hack, or if there is a better way to do
> >> things when using a strict (rather than relaxed) input visitor.  
> > a bit less ugly variant but with the same basic idea would look like:
> > --
> > Subject: [PATCH] fix qmp/hmp query-memdev not reporting IDs of memory 
> > backends   
> > 
> >  
> > Considering 'id' is mandatory for user_creatable objects/backends   
> >  
> > and user_creatable_add_type() always has it as an argument  
> >  
> > regardless of where from it is called CLI/monitor or QMP,   
> >  
> > Fix issue by adding 'id' property to hostmem backends and   
> >  
> > set it in user_creatable_add_type() for every object that   
> >  
> > implements 'id' property. Then later at query-memdev time   
> >  
> > get 'id' from object directly.   
> 
> Yes, that seems like an improved message.
> 
> > 
> >  
> > Signed-off-by: Igor Mammedov  
> > 
> > [...]
> > 
> > diff --git a/qom/object_interfaces.c b/qom/object_interfaces.c
> > index 9b4155a..03a95c3 100644
> > --- a/qom/object_interfaces.c
> > +++ b/qom/object_interfaces.c
> > @@ -62,6 +62,12 @@ Object *user_creatable_add_type(const char *type, const 
> > char *id,
> >  
> >  assert(qdict);
> >  obj = object_new(type);
> > +if (object_property_find(obj, "id", NULL)) {
> > +object_property_set_str(obj, id, "id", &local_err);
> > +if (local_err) {
> > +goto out;
> > +}
> > +}  
> 
> Works for me.
> 

Thanks,
Then, I'll respin v2 with noted fixups in commit messages
this amended patch.

[Qemu-devel] [PATCH 06/11] target-ppc: Add xviexpdp instruction

[Nikunj A Dadhania]

xviexpdp: VSX Vector Insert Exponent Dual Precision

Signed-off-by: Nikunj A Dadhania 
---
 target/ppc/translate/vsx-impl.inc.c | 26 ++
 target/ppc/translate/vsx-ops.inc.c  |  1 +
 2 files changed, 27 insertions(+)

diff --git a/target/ppc/translate/vsx-impl.inc.c 
b/target/ppc/translate/vsx-impl.inc.c
index c86f1b5..b66272e 100644
--- a/target/ppc/translate/vsx-impl.inc.c
+++ b/target/ppc/translate/vsx-impl.inc.c
@@ -1370,6 +1370,32 @@ static void gen_xviexpsp(DisasContext *ctx)
 tcg_temp_free_i64(t0);
 }
 
+static void gen_xviexpdp(DisasContext *ctx)
+{
+TCGv_i64 xth = cpu_vsrh(xT(ctx->opcode));
+TCGv_i64 xtl = cpu_vsrl(xT(ctx->opcode));
+TCGv_i64 xah = cpu_vsrh(xA(ctx->opcode));
+TCGv_i64 xal = cpu_vsrl(xA(ctx->opcode));
+TCGv_i64 xbh = cpu_vsrh(xB(ctx->opcode));
+TCGv_i64 xbl = cpu_vsrl(xB(ctx->opcode));
+TCGv_i64 t0;
+
+if (unlikely(!ctx->vsx_enabled)) {
+gen_exception(ctx, POWERPC_EXCP_VSXU);
+return;
+}
+t0 = tcg_temp_new_i64();
+tcg_gen_andi_i64(xth, xah, 0x800F);
+tcg_gen_andi_i64(t0, xbh, 0x7FF);
+tcg_gen_shli_i64(t0, t0, 52);
+tcg_gen_or_i64(xth, xth, t0);
+tcg_gen_andi_i64(xtl, xal, 0x800F);
+tcg_gen_andi_i64(t0, xbl, 0x7FF);
+tcg_gen_shli_i64(t0, t0, 52);
+tcg_gen_or_i64(xtl, xtl, t0);
+tcg_temp_free_i64(t0);
+}
+
 #undef GEN_XX2FORM
 #undef GEN_XX3FORM
 #undef GEN_XX2IFORM
diff --git a/target/ppc/translate/vsx-ops.inc.c 
b/target/ppc/translate/vsx-ops.inc.c
index 93752f0..253a5c4 100644
--- a/target/ppc/translate/vsx-ops.inc.c
+++ b/target/ppc/translate/vsx-ops.inc.c
@@ -125,6 +125,7 @@ GEN_VSX_XFORM_300(xsiexpqp, 0x4, 0x1B, 0x0001),
 #endif
 
 GEN_XX3FORM(xviexpsp, 0x00, 0x1B, PPC2_ISA300),
+GEN_XX3FORM(xviexpdp, 0x00, 0x1F, PPC2_ISA300),
 
 GEN_XX2FORM(xvabsdp, 0x12, 0x1D, PPC2_VSX),
 GEN_XX2FORM(xvnabsdp, 0x12, 0x1E, PPC2_VSX),
-- 
2.7.4

Re: [Qemu-devel] implementing architectural timers using QEMU timers

[Frederic Konrad]

On 01/09/2017 04:18 PM, Max Filippov wrote:
> Hello,
> 
> I'm trying to reimplement xtensa CCOUNT (cycle counter) and
> CCOMPARE (CCOUNT-based timer interrupts) using QEMU
> timers. That is CCOUNT value is derived from the
> QEMU_CLOCK_VIRTUAL clock and CCOMPARE interrupts are
> generated from the QEMU_CLOCK_VIRTUAL timer callbacks.
> The code is here:
>   https://github.com/OSLL/qemu-xtensa/commits/xtensa-ccount
> 
> I've got the following issues doing that:
> 
> - in non-icount mode I can often read CCOUNT and get a value
>   that is greater than programmed CCOMPARE value, which
>   means that QEMU timer must have been fired at that point, but
>   no sign of timer callback being called. That is timer callback
>   invocation lags behind due time.
> 
>   Is my understanding correct that there's no hard expectations
>   that firing of QEMU timers will be correctly sequenced with
>   readings of QEMU clock?
> 
> - I thought that could be improved in -icount mode, so I tried that.
>   It is better with -icount, but it's still not 100% accurate. That is
>   I was able to observe guest reading QEMU clock value that is
>   past QEMU timer deadline before that timer callback was
>   invoked.
> 
>   That sounds like a bug to me, is it?

Did you try "sleep" icount option?

eg:
-icount 1,sleep=off

Fred

> 
> - when guest sets a timer and halts itself waiting for timer
>   interrupt with waiti opcode QEMU behaviour is very strange with
>   -icount: regardless of the programmed timeout QEMU waits for
>   about a second before it delivers interrupt, and, AFAICT,
>   interrupt delivery it is not caused by the corresponding CCOUNT
>   timer. I was able to track this issue down to the
>   qemu_clock_use_for_deadline function, i.e. always returning true
>   'fixes' that unwanted delay, but looking around the timer code
>   I've got the impression that that's not the correct fix.
> 
>   Any suggestions on how to fix that?
> 

Re: [Qemu-devel] Live migration + cpu/mem hotplug

[Igor Mammedov]

On Tue, 10 Jan 2017 14:28:19 +0800
Bob Chen  wrote:

> Answer my own question:
> 
> The corresponding cmd-line parameter for memory hot-add by QEMU monitor is,
> -object memory-backend-ram,id=mem0,size=1024M -device
> pc-dimm,id=dimm0,memdev=mem0
pc-dimm should have additional property
  -device pc-dimm,id=dimm0,memdev=mem0,hotplugged=on

> 
> 2017-01-05 18:12 GMT+08:00 Daniel P. Berrange :
> 
> > On Thu, Jan 05, 2017 at 04:27:26PM +0800, Bob Chen wrote:  
> > > Hi,
> > >
> > > According to the docs, the destination Qemu must have the exactly same
> > > parameters as the source one. So if the source has just finished cpu or
> > > memory hotplug, what would the dest's parameters be like?
> > >
> > > Does DIMM device, or logically QOM object, have to be reflected on the  
> > new  
> > > command-line parameters?  
> >
> > Yes, if you have hotplugged any type of device since the VM was started,
> > the QEMU command line args on the target host must include all the original
> > args from the source QEMU, and also any args reflect to reflect the
> > hotplugged devices too.
> >
> > A further complication is that on the target, you must also make sure you
> > fully specify *all* device address information (PCI slots, SCSI luns, etc
> > etc), because the addresses QEMU assigns to a device after hotplug may
> > not be the same as the addresses QEMU assigns to a device whne coldplug.
> >
> > eg if you boot a guest with 1 NIC + 1 disk, and then hotplug a 2nd NIC
> > you might get
> >
> >1st NIC  == PCI slot 2
> >1st disk == PCI slot 3
> >2nd NIC  == PCI slot 4
> >
> > if however, you started QEMU with 2 NICs and 1 disk straight away QEMU
> > might assign addresses in the order
> >
> >1st NIC  == PCI slot 2
> >2nd NIC  == PCI slot 3
> >1st disk == PCI slot 4
> >
> > this would totally kill a guest OS during live migration as the slots
> > for devices its using would change.
> >
> > So as a general rule when launching QEMU on a target host for migrating,
> > you must be explicit about all device addresses and not rely on QEMU to
> > auto-assign addresses. This is quite alot of work to get right, but if
> > you're using libvirt it'll do pretty much all this automatically for
> > you.
> >
> > Regards,
> > Daniel
> > --
> > |: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/
> > :|
> > |: http://libvirt.org  -o- http://virt-manager.org
> > :|
> > |: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/
> > :|
> >  

[Qemu-devel] [PATCH 08/11] target-ppc: Add xvxexpdp instruction

[Nikunj A Dadhania]

xvxexpdp: VSX Vector Extract Exponent Dual Precision

Signed-off-by: Nikunj A Dadhania 
---
 target/ppc/translate/vsx-impl.inc.c | 17 +
 target/ppc/translate/vsx-ops.inc.c  |  1 +
 2 files changed, 18 insertions(+)

diff --git a/target/ppc/translate/vsx-impl.inc.c 
b/target/ppc/translate/vsx-impl.inc.c
index 160a80c..7b26f75 100644
--- a/target/ppc/translate/vsx-impl.inc.c
+++ b/target/ppc/translate/vsx-impl.inc.c
@@ -1413,6 +1413,23 @@ static void gen_xvxexpsp(DisasContext *ctx)
 tcg_gen_andi_i64(xtl, xtl, 0xFF00FF);
 }
 
+static void gen_xvxexpdp(DisasContext *ctx)
+{
+TCGv_i64 xth = cpu_vsrh(xT(ctx->opcode));
+TCGv_i64 xtl = cpu_vsrl(xT(ctx->opcode));
+TCGv_i64 xbh = cpu_vsrh(xB(ctx->opcode));
+TCGv_i64 xbl = cpu_vsrl(xB(ctx->opcode));
+
+if (unlikely(!ctx->vsx_enabled)) {
+gen_exception(ctx, POWERPC_EXCP_VSXU);
+return;
+}
+tcg_gen_shri_i64(xth, xbh, 52);
+tcg_gen_andi_i64(xth, xth, 0x7FF);
+tcg_gen_shri_i64(xtl, xbl, 52);
+tcg_gen_andi_i64(xtl, xtl, 0x7FF);
+}
+
 #undef GEN_XX2FORM
 #undef GEN_XX3FORM
 #undef GEN_XX2IFORM
diff --git a/target/ppc/translate/vsx-ops.inc.c 
b/target/ppc/translate/vsx-ops.inc.c
index eb7334a..a3061ce 100644
--- a/target/ppc/translate/vsx-ops.inc.c
+++ b/target/ppc/translate/vsx-ops.inc.c
@@ -126,6 +126,7 @@ GEN_VSX_XFORM_300(xsiexpqp, 0x4, 0x1B, 0x0001),
 
 GEN_XX3FORM(xviexpsp, 0x00, 0x1B, PPC2_ISA300),
 GEN_XX3FORM(xviexpdp, 0x00, 0x1F, PPC2_ISA300),
+GEN_XX2FORM_EO(xvxexpdp, 0x16, 0x1D, 0x00, PPC2_ISA300),
 GEN_XX2FORM_EO(xvxexpsp, 0x16, 0x1D, 0x08, PPC2_ISA300),
 
 GEN_XX2FORM(xvabsdp, 0x12, 0x1D, PPC2_VSX),
-- 
2.7.4

[Qemu-devel] [PATCH 10/11] target-ppc: Add xvxsigdp instruction

[Nikunj A Dadhania]

xvxsigdp: VSX Vector Extract Significand Dual Precision

Signed-off-by: Nikunj A Dadhania 
---
 target/ppc/translate/vsx-impl.inc.c | 40 +
 target/ppc/translate/vsx-ops.inc.c  |  1 +
 2 files changed, 41 insertions(+)

diff --git a/target/ppc/translate/vsx-impl.inc.c 
b/target/ppc/translate/vsx-impl.inc.c
index 4e57af7..7e068a4 100644
--- a/target/ppc/translate/vsx-impl.inc.c
+++ b/target/ppc/translate/vsx-impl.inc.c
@@ -1432,6 +1432,46 @@ static void gen_xvxexpdp(DisasContext *ctx)
 
 GEN_VSX_HELPER_2(xvxsigsp, 0x00, 0x04, 0, PPC2_ISA300)
 
+static void gen_xvxsigdp(DisasContext *ctx)
+{
+TCGv_i64 xth = cpu_vsrh(xT(ctx->opcode));
+TCGv_i64 xtl = cpu_vsrl(xT(ctx->opcode));
+TCGv_i64 xbh = cpu_vsrh(xB(ctx->opcode));
+TCGv_i64 xbl = cpu_vsrl(xB(ctx->opcode));
+
+TCGv_i64 t0, zr, nan, exp;
+
+if (unlikely(!ctx->vsx_enabled)) {
+gen_exception(ctx, POWERPC_EXCP_VSXU);
+return;
+}
+exp = tcg_temp_new_i64();
+t0 = tcg_temp_new_i64();
+zr = tcg_const_i64(0);
+nan = tcg_const_i64(2047);
+
+tcg_gen_shri_i64(exp, xbh, 52);
+tcg_gen_andi_i64(exp, exp, 0x7FF);
+tcg_gen_movi_i64(t0, 0x0010);
+tcg_gen_movcond_i64(TCG_COND_EQ, t0, exp, zr, zr, t0);
+tcg_gen_movcond_i64(TCG_COND_EQ, t0, exp, nan, zr, t0);
+tcg_gen_andi_i64(xth, xbh, 0x000F);
+tcg_gen_or_i64(xth, xth, t0);
+
+tcg_gen_shri_i64(exp, xbl, 52);
+tcg_gen_andi_i64(exp, exp, 0x7FF);
+tcg_gen_movi_i64(t0, 0x0010);
+tcg_gen_movcond_i64(TCG_COND_EQ, t0, exp, zr, zr, t0);
+tcg_gen_movcond_i64(TCG_COND_EQ, t0, exp, nan, zr, t0);
+tcg_gen_andi_i64(xtl, xbl, 0x000F);
+tcg_gen_or_i64(xtl, xtl, t0);
+
+tcg_temp_free_i64(t0);
+tcg_temp_free_i64(exp);
+tcg_temp_free_i64(zr);
+tcg_temp_free_i64(nan);
+}
+
 #undef GEN_XX2FORM
 #undef GEN_XX3FORM
 #undef GEN_XX2IFORM
diff --git a/target/ppc/translate/vsx-ops.inc.c 
b/target/ppc/translate/vsx-ops.inc.c
index 2c4f641..367fd38 100644
--- a/target/ppc/translate/vsx-ops.inc.c
+++ b/target/ppc/translate/vsx-ops.inc.c
@@ -127,6 +127,7 @@ GEN_VSX_XFORM_300(xsiexpqp, 0x4, 0x1B, 0x0001),
 GEN_XX3FORM(xviexpsp, 0x00, 0x1B, PPC2_ISA300),
 GEN_XX3FORM(xviexpdp, 0x00, 0x1F, PPC2_ISA300),
 GEN_XX2FORM_EO(xvxexpdp, 0x16, 0x1D, 0x00, PPC2_ISA300),
+GEN_XX2FORM_EO(xvxsigdp, 0x16, 0x1D, 0x01, PPC2_ISA300),
 GEN_XX2FORM_EO(xvxexpsp, 0x16, 0x1D, 0x08, PPC2_ISA300),
 GEN_XX2FORM_EO(xvxsigsp, 0x16, 0x1D, 0x09, PPC2_ISA300),
 
-- 
2.7.4

[Qemu-devel] [PATCH 11/11] target-ppc: Add xscvqps[d, w]z instructions

[Nikunj A Dadhania]

From: Bharata B Rao 

xscvqpsdz: VSX Scalar truncate & Convert Quad-Precision format to
   Signed Doubleword format
xscvqpswz: VSX Scalar truncate & Convert Quad-Precision format to
   Signed Word format

Signed-off-by: Bharata B Rao 
Signed-off-by: Nikunj A Dadhania 
---
 target/ppc/fpu_helper.c | 40 +
 target/ppc/helper.h |  2 ++
 target/ppc/translate/vsx-impl.inc.c |  2 ++
 target/ppc/translate/vsx-ops.inc.c  |  2 ++
 4 files changed, 46 insertions(+)

diff --git a/target/ppc/fpu_helper.c b/target/ppc/fpu_helper.c
index 4da83d9..ae57272 100644
--- a/target/ppc/fpu_helper.c
+++ b/target/ppc/fpu_helper.c
@@ -2878,6 +2878,46 @@ VSX_CVT_FP_TO_INT(xvcvspsxws, 4, float32, int32, 
VsrW(i), VsrW(i), 0x8000U)
 VSX_CVT_FP_TO_INT(xvcvspuxds, 2, float32, uint64, VsrW(2*i), VsrD(i), 0ULL)
 VSX_CVT_FP_TO_INT(xvcvspuxws, 4, float32, uint32, VsrW(i), VsrW(i), 0U)
 
+/* VSX_CVT_FP_TO_INT_VECTOR - VSX floating point to integer conversion
+ *   op- instruction mnemonic
+ *   stp   - source type (float32 or float64)
+ *   ttp   - target type (int32, uint32, int64 or uint64)
+ *   sfld  - source vsr_t field
+ *   tfld  - target vsr_t field
+ *   rnan  - resulting NaN
+ */
+#define VSX_CVT_FP_TO_INT_VECTOR(op, stp, ttp, sfld, tfld, rnan) \
+void helper_##op(CPUPPCState *env, uint32_t opcode)  \
+{\
+ppc_vsr_t xt, xb;\
+ \
+getVSR(rB(opcode) + 32, &xb, env);   \
+memset(&xt, 0, sizeof(xt));  \
+ \
+if (unlikely(stp##_is_any_nan(xb.sfld))) {   \
+if (stp##_is_signaling_nan(xb.sfld, &env->fp_status)) {  \
+float_invalid_op_excp(env, POWERPC_EXCP_FP_VXSNAN, 0);   \
+}\
+float_invalid_op_excp(env, POWERPC_EXCP_FP_VXCVI, 0);\
+xt.tfld = rnan;  \
+} else { \
+xt.tfld = stp##_to_##ttp##_round_to_zero(xb.sfld,\
+  &env->fp_status);  \
+if (env->fp_status.float_exception_flags & float_flag_invalid) { \
+float_invalid_op_excp(env, POWERPC_EXCP_FP_VXCVI, 0);\
+}\
+}\
+ \
+putVSR(rD(opcode) + 32, &xt, env);   \
+float_check_status(env); \
+}
+
+VSX_CVT_FP_TO_INT_VECTOR(xscvqpsdz, float128, int64, f128, VsrD(0),  \
+  0x8000ULL)
+
+VSX_CVT_FP_TO_INT_VECTOR(xscvqpswz, float128, int32, f128, VsrD(0),  \
+  0x8000ULL)
+
 /* VSX_CVT_INT_TO_FP - VSX integer to floating point conversion
  *   op- instruction mnemonic
  *   nels  - number of elements (1, 2 or 4)
diff --git a/target/ppc/helper.h b/target/ppc/helper.h
index 27607bf..54853b8 100644
--- a/target/ppc/helper.h
+++ b/target/ppc/helper.h
@@ -434,6 +434,8 @@ DEF_HELPER_2(xscvdpqp, void, env, i32)
 DEF_HELPER_2(xscvdpsp, void, env, i32)
 DEF_HELPER_2(xscvdpspn, i64, env, i64)
 DEF_HELPER_2(xscvqpdp, void, env, i32)
+DEF_HELPER_2(xscvqpsdz, void, env, i32)
+DEF_HELPER_2(xscvqpswz, void, env, i32)
 DEF_HELPER_2(xscvhpdp, void, env, i32)
 DEF_HELPER_2(xscvspdp, void, env, i32)
 DEF_HELPER_2(xscvspdpn, i64, env, i64)
diff --git a/target/ppc/translate/vsx-impl.inc.c 
b/target/ppc/translate/vsx-impl.inc.c
index 7e068a4..3c924ba 100644
--- a/target/ppc/translate/vsx-impl.inc.c
+++ b/target/ppc/translate/vsx-impl.inc.c
@@ -811,6 +811,8 @@ GEN_VSX_HELPER_2(xscvdpsp, 0x12, 0x10, 0, PPC2_VSX)
 GEN_VSX_HELPER_2(xscvdpqp, 0x04, 0x1A, 0x16, PPC2_ISA300)
 GEN_VSX_HELPER_XT_XB_ENV(xscvdpspn, 0x16, 0x10, 0, PPC2_VSX207)
 GEN_VSX_HELPER_2(xscvqpdp, 0x04, 0x1A, 0x14, PPC2_ISA300)
+GEN_VSX_HELPER_2(xscvqpsdz, 0x04, 0x1A, 0x19, PPC2_ISA300)
+GEN_VSX_HELPER_2(xscvqpswz, 0x04, 0x1A, 0x09, PPC2_ISA300)
 GEN_VSX_HELPER_2(xscvhpdp, 0x16, 0x15, 0x10, PPC2_ISA300)
 GEN_VSX_HELPER_2(xscvspdp, 0x12, 0x14, 0, PPC2_VSX)
 GEN_VSX_HELPER_XT_XB_ENV(xscvspdpn, 0x16, 0x14, 0, PPC2_VSX207)
diff --git a/target/ppc/translate/vsx-ops.inc.c 
b/target/ppc/translate/vsx-ops.inc.c
index 367fd38..297c317 100644
--- a/target/ppc/translate/vsx-o

[Qemu-devel] [Bug 597362] Re: qemu-system-sparc singlestep not work in gdbstub

[Thomas Huth]

Triaging old bug reports ... Can you still reproduce this problem with
the latest version of QEMU?

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

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

Title:
  qemu-system-sparc singlestep not work in gdbstub

Status in QEMU:
  Incomplete

Bug description:
  Debugging with gdb-stub does not work with qemu-system-sparc target

  Qemu compiled from current git tree.

  execution string: qemu-system-sparc.exe -s -S -m 256 -L Bios -hda
  sparc.img -boot c
  connect with telnet localhost 1234
  enter '$s#73' (without quotes, this is single step command to gdb stub)
  gdb stub reply '+' (without quotes, as it accept command)
  After this qemu continuously execute instructions in single step mode
  and does not exit to gdb stub after each executed instruction with
  interrupt signal
  ("T%02xthread:%02x;" /gdb_vm_state_change in gdbstub.c/ );

  If we look at target-sparc/translate.c, we can see that
  gen_helper_debug() is not called in single step mode:

  
  if ((pc & TARGET_PAGE_MASK) == (tb->pc & TARGET_PAGE_MASK) &&
  (npc & TARGET_PAGE_MASK) == (tb->pc & TARGET_PAGE_MASK) &&
  !s->singlestep)  {
  /* jump to same page: we can use a direct jump */
  tcg_gen_goto_tb(tb_num);
  tcg_gen_movi_tl(cpu_pc, pc);
  tcg_gen_movi_tl(cpu_npc, npc);
  tcg_gen_exit_tb((long)tb + tb_num);
  } else {
  /* jump to another page: currently not optimized */
  tcg_gen_movi_tl(cpu_pc, pc);
  tcg_gen_movi_tl(cpu_npc, npc);
  tcg_gen_exit_tb(0);
  }
  =

  
  /* if single step mode, we generate only one instruction and
 generate an exception */
  if (dc->singlestep) {
  break;
  }
  

  If we look similar code at target-sh4/translate.c we can see that is
  called in this cases:

  
  if ((tb->pc & TARGET_PAGE_MASK) == (dest & TARGET_PAGE_MASK) &&
!ctx->singlestep_enabled) {
/* Use a direct jump if in same page and singlestep not enabled */
  tcg_gen_goto_tb(n);
  tcg_gen_movi_i32(cpu_pc, dest);
  tcg_gen_exit_tb((long) tb + n);
  } else {
  tcg_gen_movi_i32(cpu_pc, dest);
  if (ctx->singlestep_enabled)
  gen_helper_debug();
  tcg_gen_exit_tb(0);
  }
  

  
  if (tb->cflags & CF_LAST_IO)
  gen_io_end();
  if (env->singlestep_enabled) {
  tcg_gen_movi_i32(cpu_pc, ctx.pc);
  gen_helper_debug();
  } else {
  ==

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

[Qemu-devel] [Bug 589827] Re: QEMU netdev tap type id name is not used on linux host

[Thomas Huth]

The "id=..." is only the QEMU-internal name of the netdev, not the name
of the tap device. So this is not a bug --> closing this ticket.

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

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

Title:
  QEMU netdev tap type id name is not used on linux host

Status in QEMU:
  Invalid

Bug description:
  Tested with 0.12.3, 0.12.4, and latest git as of 4 jun 2010.
  The new -netdev type seems to ignore manual specifications of tap ifname.

  qemu-system-x86_64 -hda disk.img -netdev tap,id=ids_e0 -device 
e1000,netdev=ids_e0
   **creates tap0 instead of ids_e0.  tap0 passes traffic, ids_e0 doesn't exist
  (I tried -netdev type=tap as well for brevity)

  QEMU creates a tap0 (or appropriate) interface and does not name this
  "ids_e0" as would be expected.  I also tried 'pre' creating the tap
  interface.

  Previous alterantive was
  qemu-system-x86_64 -hda disk.img -net nic,model=e1000,vlan=99 -net 
tap,ifname=ids_e0,vlan=99 
**creates ids_e0 as expected, and passes traffic as expected.

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

Re: [Qemu-devel] [PATCH v7 03/21] qapi: make TODOs named-sections

[Markus Armbruster]

Marc-André Lureau  writes:

> Have the TODO in the TAG: format, so they will stand out in the
> generated documentation.

I expect TODO without colon to creep back.  Right now, we have three
with and three without colon.  Whack-a-mole is a stupid game, but since
these moles are fairly harmless, I don't care.

The commit message is sub-optimal, though.  At this point, there is no
generated documentation, and we have no concept of "named-sections".
Let's instead say

  qapi: Format TODO comments more consistently

  Consistently put a colon after TODO.  This will make the TODOs stand
  out in the documentation we're going to generate.

With that
Reviewed-by: Markus Armbruster 

Alternatively, delay the patch until after we generate documentation.

[Qemu-devel] [PATCH v2] ui: fix format specfier in vnc to avoid break in build.

[Rami Rosen]

When building qemu after setting _VNC_DEBUG to 1 (see ui/vnc.h),
we get the following error and the build breaks:
...
ui/vnc.c: In function ‘vnc_client_io_error’:
ui/vnc.c:1262:13: error: format ‘%d’ expects argument of type ‘int’, but
 VNC_DEBUG("Closing down client sock: ret %d (%s)\n",
 ^
cc1: all warnings being treated as errors
make: *** [ui/vnc.o] Error 1
...

This patch solves this issue by fixing the print format specifier
in vnc_client_io_error() to be %zd, which corresponds to the type
of the "ret" variable.

Signed-off-by: Rami Rosen 
---
changes v2:
- use %zd instead of %ld for the format sepcifier.

 ui/vnc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ui/vnc.c b/ui/vnc.c
index 2c28a59..6b0672b 100644
--- a/ui/vnc.c
+++ b/ui/vnc.c
@@ -1259,7 +1259,7 @@ ssize_t vnc_client_io_error(VncState *vs, ssize_t ret, 
Error **errp)
 if (ret == 0) {
 VNC_DEBUG("Closing down client sock: EOF\n");
 } else if (ret != QIO_CHANNEL_ERR_BLOCK) {
-VNC_DEBUG("Closing down client sock: ret %d (%s)\n",
+VNC_DEBUG("Closing down client sock: ret %zd (%s)\n",
   ret, errp ? error_get_pretty(*errp) : "Unknown");
 }
 
-- 
1.9.1

Re: [Qemu-devel] [PATCH] hw/net/dp8393x: Avoid unintentional sign extensions on addresses

[Laurent Vivier]

Le 09/01/2017 à 19:43, Peter Maydell a écrit :
> The dp8393x has several 32-bit values which are formed by concatenating
> two 16 bit device register values. Attempting to do these inline
> with ((s->reg[HI] << 16) | s->reg[LO]) can result in an unintended
> sign extension because "x << 16" is of type 'int' even though s->reg
> is unsigned, and so if the expression is used in a context where
> it is cast to uint64_t the value is incorrectly sign-extended.
> Fix this by using accessor functions with a uint32_t return type;
> this also makes the code a bit easier to read.
> 
> This should fix Coverity issues 1307765, 1307766, 1307767, 1307768.
> 
> (To avoid having a ctda read function only used in a DPRINTF,
> we move the DPRINTF down slightly so it can use the ttda function.)
> 
> Signed-off-by: Peter Maydell 

Reviewed-by: Laurent Vivier 

FWIW, I've tested a port of this patch with Quadra 800 emulation, and it
works:

Tested-by: Laurent Vivier 

Laurent

[Qemu-devel] [Bug 775604] Re: Could not open SDL display when running XP as guest

[Thomas Huth]

** Changed in: qemu
   Status: Incomplete => Won't Fix

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

Title:
  Could not open SDL display when running XP as guest

Status in QEMU:
  Won't Fix

Bug description:
  When running XP as guest on Linux 2.6.38 x86_64 (Arch Linux) in full
  screen qemu will crash. Dropping to 1400x900 or below does not have a
  problem nor does windowed mode.

  1. Running:
  qemu-system-x86_64 -vga std -full-screen 
Virtual_Machines/Windows_XP/Windows_XP.img

  Produces error:
  Could not open SDL display (1920x1200x0): No video mode large enough for 
1920x1200

  qemu-kvm version 0.14.0-1

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

[Qemu-devel] [Bug 696834] Re: FP exception reporting not working on NetBSD host

[Thomas Huth]

QEMU 0.13 is completely outdated nowadays - can you still reproduce this
problem with the latest version of QEMU (currently version 2.8) ?

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

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

Title:
  FP exception reporting not working on NetBSD host

Status in QEMU:
  Incomplete

Bug description:
  I recognize that NetBSD is not one of the officially supported host
  OS.  However, qemu 0.13.0 is available in the NetBSD pkgsrc
  collection, and works quite well.  Well, with one exception (pun
  intended): It seems that Floating Point exceptions don't get reported
  properly.

  The following code-snippet demonstrates the problem:

  
  volatile int flt_signal = 0;

  static sigjmp_buf sigfpe_flt_env;
  static void
  sigfpe_flt_action(int signo, siginfo_t *info, void *ptr)
  {
  flt_signal++;
  }

  void trigger(void)
  {   
  struct sigaction sa;
  double d = strtod("0", NULL);
  
  if (sigsetjmp(sigfpe_flt_env, 0) == 0) {
  sa.sa_flags = SA_SIGINFO;
  sa.sa_sigaction = sigfpe_flt_action;
  sigemptyset(&sa.sa_mask);
  sigaction(SIGFPE, &sa, NULL);
  fpsetmask(FP_X_INV|FP_X_DZ|FP_X_OFL|FP_X_UFL|FP_X_IMP);
  printf("%g\n", 1 / d);
  }
  printf("FPE signal handler invoked %d times.\n");
  }

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

Re: [Qemu-devel] [PATCH 3/3] vmstate registration: check return values

[Dr. David Alan Gilbert]

* Peter Maydell (peter.mayd...@linaro.org) wrote:
> On 9 January 2017 at 20:13, Dr. David Alan Gilbert (git)
>  wrote:
> > From: "Dr. David Alan Gilbert" 
> >
> > Check qdev's call to vmstate_register_with_alias_id; that gets
> > most of the common uses; there's hundreds of calls via vmstate_register
> > which could get fixed over time.
> 
> Not quite that bad, I think -- I make it just over 50 calls.

Well kind of; it seems to be a bit more complicated than that.
I'd grep'd for vmstate_register and that gives me ~180 (including
stuff in headers).
Only 56 of those are vmstate_register() calls though, 117 are
vmstate_register_ram calls which I'd not previously looked at,
those call qemu_ram_set_idstr which looks like it suffers from
the same problem though.

Dave


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

[Qemu-devel] Question about io mode & cache mode

[morgenlette madeBy]

Hello.

I sent mail for question about io mode and cache mode.

When I set VM to I/O mode = native and cache mode = none,

Vm cannot boot and vm is turn off automatically.

Why cannot VM boot?

[Qemu-devel] [Bug 676934] Re: Ability to use -net socket with unix sockets

[Thomas Huth]

** Changed in: qemu
   Importance: Undecided => Wishlist

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

Title:
  Ability to use -net socket with unix sockets

Status in QEMU:
  New

Bug description:
  It would be a nice feature (simplifying access control for example) to
  be able to do something like:

  qemu -net socket,listen=unix:/tmp/qemunet
  qemu -net socket,connect=unix:/tmp/qemunet

  For now one has to use TCP connections even for guests running on the
  same host, which involves setting up iptables to restrict access.

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

Re: [Qemu-devel] [PULL 21/25] scsi-disk: fix VERIFY for scsi-block

[Paolo Bonzini]

On 09/01/2017 20:42, Peter Maydell wrote:
>> +case VERIFY_10:
>> +case VERIFY_12:
>> +case VERIFY_16:
>> +/* We get here only for BYTCHK == 0x01 and only for scsi-block.
>> + * As far as DMA is concerned, we can treat it the same as a write;
>> + * scsi_block_do_sgio will send VERIFY commands.
>> + */
>>  if (r->req.cmd.buf[1] & 0xe0) {
>>  goto illegal_request;
>>  }
> Coverity now complains about the fallthrough into the case statements
> added here. I assume from the patch that the fallthrough is deliberate,
> in which case a /* fall through */ comment would assist future
> readers...

Indeed---I thought I had waived that already in the scan dashboard.

Paolo

[Qemu-devel] about post copy recovery

[Li, Liang Z]

Hi David,

I remembered some guys wanted to solve the issue of post copy recovery when 
network broken down, do you know latest status?

Thanks!
Liang

Re: [Qemu-devel] [PATCH v3 1/3] arm_generic_timer: Add the ARM Generic Timer

[Peter Maydell]

On 10 January 2017 at 01:41, Alistair Francis
 wrote:
> On Fri, Jan 6, 2017 at 3:57 AM, Peter Maydell  
> wrote:
>> On 20 December 2016 at 22:42, Alistair Francis
>>  wrote:

>>> +},{ .name = "CNTCV_LOWER",
>>> +.addr = A_CNTCV_LOWER,
>>> +.post_read = counter_low_value_postr,
>>> +},{ .name = "CNTCV_UPPER",
>>> +.addr = A_CNTCV_UPPER,
>>> +.post_read = counter_high_value_postr,
>>
>> Spec says that you should also be able to access the whole
>> 64-bit counter value with a 64-bit access -- is this reginfo
>> sufficient to make that work?
>
> How do you know, all I see if that it is a 64-bit register. All the
> documentation about accesses specifies only 32-bit accesses.

v8 ARM ARM DDI0487A.k, I3.5.3 (CNTCV register description):
"In an implementation that supports 64-bit atomic memory accesses,
this register must be accessible using a 64-bit atomic access."


>> This means you can't use this device in a system which
>> doesn't implement TrustZone. I think this would be better
>> handled by just having the board map the memory region
>> in to only the Secure address space if it is a TZ-aware board.
>
> How can I map something into the secure address space? Is there an
> example of this? The only think I can find is in the arm/virt.c
> machine with the secure_sysmem MemoryRegion.

Yeah, virt.c is the place to look -- for instance we put one
of the UARTs in the secure address space only.
Basically to support separate address spaces:
 * create a MemoryRegion to be the secure view of the world
 * add the NS MemoryRegion to it as a subregion with low
   priority (so S sees all the NS devices -- this isn't
   required but that's usually how h/w is set up)
 * use object_property_set_link() to connect the S memory
   region to each CPU's secure-memory property
 * add any S-only devices to the S MemoryRegion

>>> +REG32(CNTCR, 0x00)
>>> +FIELD(CNTCR, EN, 0, 1)
>>> +FIELD(CNTCR, HDBG, 1, 1)
>>> +REG32(CNTSR, 0x04)
>>> +FIELD(CNTSR, DBGH, 1, 1)
>>> +REG32(CNTCV_LOWER, 0x08)
>>> +REG32(CNTCV_UPPER, 0x0C)
>>> +REG32(CNTFID0, 0x20)
>>> +/* We don't model CNTFIDn */
>>> +/* We don't model the CounterID registers either */
>>
>> Does the Xilinx h/w not implement them at all?
>> (ie do we need a property for "device has the ID regs" if we add them
>> later?)
>
> There is nothing in the register spec describing registers being here.
>
> The last register I see is called: (IOU_SCNTRS)
> base_frequency_ID_register at address 0xFF260020.

I suspect there's an implicit reads-as-zero after that.
(The frequency table has to have at least one real entry
plus the zero terminator -- see I3.5.5 (CNTFID0).)

QEMU's implementation will only support one frequency so
we only need one table entry too (for the moment, anyway).

>> The spec says it's mandatory to have at least the entry for
>> the counter base frequency plus end-of-table marker.
>> I would expect EL3 firmware to want to read this table in order
>> to write the correct values to CNTFRQ_EL0 for each CPU.
>
> I don't see anything like that in section I3.5.21 in the ARM ARM,
> where are you looking?

There's no I3.5.21 in my copy of the spec (rev A.k), I suspect
you have an older rev. I think the generic timer docs got
revamped at some point, so you might want to grab the latest rev.

Anyway, it looks like you have got CNTFIDn (that's CNTFID0)
and an implicit undocumented zero-terminator.

The spec says CounterIDn are IMPDEF, which I guess is why
your implementation doesn't bother to implement them.

thanks
-- PMM

Re: [Qemu-devel] Question about add AF_ALG backend for virtio-crypto

[Daniel P. Berrange]

On Tue, Jan 10, 2017 at 09:03:45AM +, Gonglei (Arei) wrote:
> Hi,
> 
> > 
> > On Mon, Jan 09, 2017 at 01:43:10PM +, Stefan Hajnoczi wrote:
> > > On Mon, Jan 09, 2017 at 03:04:55PM +0800, Longpeng (Mike) wrote:
> > > > I'm one of Gonglei's virtio-crypto project members, and we plan to add a
> > AF_ALG
> > > > backend for virtio-crypto(there's only builtin-backend currently).
> > > >
> > > > I found that Catalin, Paolo and Stefan had discussed about this in 2015
> > > > (http://www.spinics.net/lists/kvm/msg115457.html), but it seems that
> > Catalin
> > > > didn't do it, so I'm confuse about wether it is need to add a AF_ALG
> > backend.
> > > >
> > > > Do you have any suggestion? Thanks :)
> > >
> > > I have no objections to an AF_ALG backend in QEMU.
> > 
> > Rather than do another backend for virtio-crypto, IMHO, we should have
> > an AF_ALG impl of the crypto/ APIs. That way any potential performance
> > benefits will enhance our LUKS encryption code too.
> > 
> According to the currently schemas of crypto/ APIs, we can't choose the
> specific backend dynamically. This is a limitation for virtio-crypto
> device I think.

Do we really need to be able to choose the backend explicitly. If the AF_ALG
backend is faster, why would you simply not use that automatically if it is
available. I'm not seeing an obvious need for dynamically choosing between
backends.

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

Re: [Qemu-devel] [PATCH v7 00/10] Convert msix_init() to error

[Markus Armbruster]

"Michael S. Tsirkin"  writes:

> On Mon, Nov 14, 2016 at 03:25:30PM +0800, Cao jin wrote:
>> v7 changelog:
>> 1. fix the segfaut bug in patch 2. So drop the all the R-b of it,
>>please take a look, there is detailed description in the patch.
>> 2. add the R-b from Hannes Reinecke
>> 
>> Test:
>> 1. make check: pass
>> 2. After applied all the patch, command line test for all the
>>affected devices, just make sure device realize process is ok,
>>no crash, but no further use of device.
>
> Consider the megasas device for example, don't you
> need to test that the change actually does what
> it's intended to do?

For better or worse, that's a higher bar than we commonly require for
refactorings.

[...]

Re: [Qemu-devel] [PATCH 3/3] vmstate registration: check return values

[Peter Maydell]

On 10 January 2017 at 09:26, Dr. David Alan Gilbert  wrote:
> * Peter Maydell (peter.mayd...@linaro.org) wrote:
>> On 9 January 2017 at 20:13, Dr. David Alan Gilbert (git)
>>  wrote:
>> > From: "Dr. David Alan Gilbert" 
>> >
>> > Check qdev's call to vmstate_register_with_alias_id; that gets
>> > most of the common uses; there's hundreds of calls via vmstate_register
>> > which could get fixed over time.
>>
>> Not quite that bad, I think -- I make it just over 50 calls.
>
> Well kind of; it seems to be a bit more complicated than that.
> I'd grep'd for vmstate_register and that gives me ~180 (including
> stuff in headers).

Yes, I was specifically looking at the vmstate_register and
vmstate_register_with_alias_id ones.

> Only 56 of those are vmstate_register() calls though, 117 are
> vmstate_register_ram calls which I'd not previously looked at,
> those call qemu_ram_set_idstr which looks like it suffers from
> the same problem though.

They call qemu_ram_set_idstr with the memory region name string,
though, which is "used for debugging; not visible to the user
or ABI", so we can just say it's a bug to use a silly name
and assert if it's too big, right?

thanks
-- PMM

Re: [Qemu-devel] [PATCH v7 07/21] qapi: avoid interleaving sections and parameters

[Markus Armbruster]

Marc-André Lureau  writes:

> Follow documentation guideline, body, parameters then additional
> sections.

Commit message wording nit: we don't have a concept of "sections", yet.

I don't think the guidelines demand such an order at this point.  Here's
the applicable paragraph from docs/qapi-code-gen.txt:

Comments are allowed; anything between an unquoted # and the following
newline is ignored.  Although there is not yet a documentation
generator, a form of stylized comments has developed for consistently
documenting details about an expression and when it was added to the
schema.  The documentation is delimited between two lines of ##, then
the first line names the expression, an optional overview is provided,
then individual documentation about each member of 'data' is provided,
and finally, a 'Since: x.y.z' tag lists the release that introduced
the expression.  Optional members are tagged with the phrase
'#optional', often with their default value; and extensions added
after the expression was first released are also given a '(since
x.y.z)' comment.  For example:

A pedantical reader would conclude only "Since" can follow the "members
of 'data'".

I'm feeling less pedantical, and conclude that additional information
not mentioned in this paragraph can be stuck wherever it reads well.
Matches existing practice.

That said, I don't mind moving stuff around if it helps the doc
generator later on, and doesn't make things less readable.

> Signed-off-by: Marc-André Lureau 
> ---
>  qapi-schema.json | 10 +-
>  qapi/event.json  |  4 ++--
>  qapi/introspect.json |  3 +--
>  3 files changed, 8 insertions(+), 9 deletions(-)
>
> diff --git a/qapi-schema.json b/qapi-schema.json
> index ac6352fcf9..10a3506528 100644
> --- a/qapi-schema.json
> +++ b/qapi-schema.json
> @@ -4729,17 +4729,17 @@
>  # it should be passed by management with device_add command when
>  # a CPU is being hotplugged.
>  #
> +# @node-id: #optional NUMA node ID the CPU belongs to
> +# @socket-id: #optional socket number within node/board the CPU belongs to
> +# @core-id: #optional core number within socket the CPU belongs to
> +# @thread-id: #optional thread number within core the CPU belongs to
> +#
>  # Note: currently there are 4 properties that could be present
>  # but management should be prepared to pass through other
>  # properties with device_add command to allow for future
>  # interface extension. This also requires the filed names to be kept in
>  # sync with the properties passed to -device/device_add.
>  #
> -# @node-id: #optional NUMA node ID the CPU belongs to
> -# @socket-id: #optional socket number within node/board the CPU belongs to
> -# @core-id: #optional core number within socket the CPU belongs to
> -# @thread-id: #optional thread number within core the CPU belongs to
> -#
>  # Since: 2.7
>  ##
>  { 'struct': 'CpuInstanceProperties',

No objection.

> diff --git a/qapi/event.json b/qapi/event.json
> index 37bf34ed6d..c7689b211d 100644
> --- a/qapi/event.json
> +++ b/qapi/event.json
> @@ -272,9 +272,9 @@
>  #
>  # Emitted when guest executes ACPI _OST method.
>  #
> -# Since: 2.1
> -#
>  # @info: ACPIOSTInfo type as described in qapi-schema.json
> +#
> +# Since: 2.1
>  ##
>  { 'event': 'ACPI_DEVICE_OST',
>   'data': { 'info': 'ACPIOSTInfo' } }

Consistency improvement.

> diff --git a/qapi/introspect.json b/qapi/introspect.json
> index 464097a235..f6adc439bb 100644
> --- a/qapi/introspect.json
> +++ b/qapi/introspect.json
> @@ -78,14 +78,13 @@
>  # @SchemaInfo:
>  #
>  # @name: the entity's name, inherited from @base.
> +#The SchemaInfo is always referenced by this name.
>  #Commands and events have the name defined in the QAPI schema.
>  #Unlike command and event names, type names are not part of
>  #the wire ABI.  Consequently, type names are meaningless
>  #strings here, although they are still guaranteed unique
>  #regardless of @meta-type.
>  #
> -# All references to other SchemaInfo are by name.
> -#
>  # @meta-type: the entity's meta type, inherited from @base.
>  #
>  # Additional members depend on the value of @meta-type.

Okay.

PATCH 02 "qapi: move QKeyCode doc body at the top" could be squashed
into this one, I think.

Overall, no objections, except the commit message's first line
forward-references the "sections" concept, and its rationale is a bit
weak.

What about this:

qapi: Reorder doc comments for future doc generator

The doc generator we're going to add expects a fairly rigid doc
comment structure.  Reorder / rephrase some to please it.

To be clear: I still doubt this rigid order is a good idea.  But as long
as I can't point to actual harm, I'm willing to accept it, in the
interest of getting stuff done.

Re: [Qemu-devel] [PATCH 3/3] vmstate registration: check return values

[Dr. David Alan Gilbert]

* Peter Maydell (peter.mayd...@linaro.org) wrote:
> On 10 January 2017 at 09:26, Dr. David Alan Gilbert  
> wrote:
> > * Peter Maydell (peter.mayd...@linaro.org) wrote:
> >> On 9 January 2017 at 20:13, Dr. David Alan Gilbert (git)
> >>  wrote:
> >> > From: "Dr. David Alan Gilbert" 
> >> >
> >> > Check qdev's call to vmstate_register_with_alias_id; that gets
> >> > most of the common uses; there's hundreds of calls via vmstate_register
> >> > which could get fixed over time.
> >>
> >> Not quite that bad, I think -- I make it just over 50 calls.
> >
> > Well kind of; it seems to be a bit more complicated than that.
> > I'd grep'd for vmstate_register and that gives me ~180 (including
> > stuff in headers).
> 
> Yes, I was specifically looking at the vmstate_register and
> vmstate_register_with_alias_id ones.
> 
> > Only 56 of those are vmstate_register() calls though, 117 are
> > vmstate_register_ram calls which I'd not previously looked at,
> > those call qemu_ram_set_idstr which looks like it suffers from
> > the same problem though.
> 
> They call qemu_ram_set_idstr with the memory region name string,
> though, which is "used for debugging; not visible to the user
> or ABI", so we can just say it's a bug to use a silly name
> and assert if it's too big, right?

qemu_ram_set_idstr already abort's if it hits a dupe (which after
making sure it doesn't overflow the buffer is what we end up with
if we have long names); so yes we already abort in that case.

However, it's a bit optimistic of the memory region to claim the name
is just for debug; Migration/ram.c transmits the RAMBlock's idstr on
the wire (as does postcopy) - so I think the memory.h comment
is wrong.

I don't think it's a big problem since you're unlikely to hit these
big names in practice; but it would be better to return an error
rather than assert/abort since then you wouldn't abort as part
of a hot-add.

So it's worth taking the common cases as this patch does; I don't
think it's worth the hastle of changing 100+ calls though.

Dave

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

Re: [Qemu-devel] [PATCH 3/3] vmstate registration: check return values

[Peter Maydell]

On 10 January 2017 at 10:34, Dr. David Alan Gilbert  wrote:
> However, it's a bit optimistic of the memory region to claim the name
> is just for debug; Migration/ram.c transmits the RAMBlock's idstr on
> the wire (as does postcopy) - so I think the memory.h comment
> is wrong.

We'd better fix that, then, or we'll find ourselves breaking
migration compat by accident...

> I don't think it's a big problem since you're unlikely to hit these
> big names in practice; but it would be better to return an error
> rather than assert/abort since then you wouldn't abort as part
> of a hot-add.

Almost all of the calls aren't going to be hot-add, though.

> So it's worth taking the common cases as this patch does; I don't
> think it's worth the hastle of changing 100+ calls though.

You also have the code paths via memory_region_allocate_system_memory
which end up calling vmstate_register_ram_global which then calls
qemu_ram_set_idstr -- none of that has support for returning an
error.

(Aside: at some point I want to introduce a
memory_region_allocate_aux_memory() which wraps the common
pattern
memory_region_init_ram(mr, NULL, name, size, &error_fatal);
vmstate_register_ram_global(mr);
so we have a simple way to create RAM blocks which aren't
the main system ram, by analogy with memory_region_allocate_system_memory().)

thanks
-- PMM

Re: [Qemu-devel] [PULL v2 00/11] tcg host mips64 support

[Peter Maydell]

On 9 January 2017 at 19:08, Peter Maydell  wrote:
> On 9 January 2017 at 19:02, Richard Henderson  wrote:
>> [Bah.  This time with actual request-pull info.]
>>
>> This is v6 of Jin Guojie's patch set, as tested by Aurelien Jarno,
>> James Hogan, and Yun Qiang Su.  Plus one more patch from me to fix
>> a trival Werror in mips specific code with gcc 5.3.
>>
>>
>> r~
>>
>>
>> The following changes since commit f0d703314ecb0415d51425727ed73ad2c6e3238a:
>>
>>   tcg-mips: Adjust qemu_ld/st for mips64 (2017-01-06 10:09:10 -0800)
>>
>> are available in the git repository at:
>>
>>   git://github.com/rth7680/qemu.git tags/pull-tcg-20170108
>>
>> for you to fetch changes up to f68808c7494b38764e1895a9852b994638b86536:
>>
>>   translate-all: Avoid -Werror=switch-bool (2017-01-08 09:48:34 -0800)
>>
>> 
>> TCG host support for mips64
>>
>> 
>> Richard Henderson (1):
>>   translate-all: Avoid -Werror=switch-bool
>>
>>  translate-all.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> Your pullreq has more stuff in it than the above diffstat and
> patchlist say :-)
>
> tcg/mips/tcg-target.h | 60 ++-
> tcg/mips/tcg-target.inc.c | 1170
> ---
> translate-all.c   | 2 +-
>  3 files changed, 978 insertions(+), 254 deletions(-)
>
> I'm processing it anyway.

Applied, thanks.

-- PMM

[Qemu-devel] [PATCH v6 3/4] Plumb the HAXM-based hardware acceleration support

[Vincent Palatin]

Use the Intel HAX is kernel-based hardware acceleration module for
Windows (similar to KVM on Linux).

Based on the "target/i386: Add Intel HAX to android emulator" patch
from David Chou 

Signed-off-by: Vincent Palatin 
---
 Makefile.target   |  1 +
 configure | 18 +++
 cpus.c| 78 ++-
 hw/intc/apic_common.c |  3 +-
 include/qom/cpu.h |  5 +++
 include/sysemu/hw_accel.h |  9 ++
 qemu-options.hx   | 11 +++
 target/i386/Makefile.objs |  4 +++
 util/qemu-thread-win32.c  |  4 +--
 vl.c  | 15 +++--
 10 files changed, 141 insertions(+), 7 deletions(-)

diff --git a/Makefile.target b/Makefile.target
index 8ae82cb311..c62e2acee3 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -97,6 +97,7 @@ obj-y += target/$(TARGET_BASE_ARCH)/
 obj-y += disas.o
 obj-y += tcg-runtime.o
 obj-$(call notempty,$(TARGET_XML_FILES)) += gdbstub-xml.o
+obj-$(call lnot,$(CONFIG_HAX)) += hax-stub.o
 obj-$(call lnot,$(CONFIG_KVM)) += kvm-stub.o
 
 obj-$(CONFIG_LIBDECNUMBER) += libdecnumber/decContext.o
diff --git a/configure b/configure
index 86f5214dd0..249faa164d 100755
--- a/configure
+++ b/configure
@@ -228,6 +228,7 @@ vhost_net="no"
 vhost_scsi="no"
 vhost_vsock="no"
 kvm="no"
+hax="no"
 colo="yes"
 rdma=""
 gprof="no"
@@ -562,6 +563,7 @@ CYGWIN*)
 ;;
 MINGW32*)
   mingw32="yes"
+  hax="yes"
   audio_possible_drivers="dsound sdl"
   if check_include dsound.h; then
 audio_drv_list="dsound"
@@ -611,6 +613,7 @@ OpenBSD)
 Darwin)
   bsd="yes"
   darwin="yes"
+  hax="yes"
   LDFLAGS_SHARED="-bundle -undefined dynamic_lookup"
   if [ "$cpu" = "x86_64" ] ; then
 QEMU_CFLAGS="-arch x86_64 $QEMU_CFLAGS"
@@ -920,6 +923,10 @@ for opt do
   ;;
   --enable-kvm) kvm="yes"
   ;;
+  --disable-hax) hax="no"
+  ;;
+  --enable-hax) hax="yes"
+  ;;
   --disable-colo) colo="no"
   ;;
   --enable-colo) colo="yes"
@@ -1372,6 +1379,7 @@ disabled with --disable-FEATURE, default is enabled if 
available:
   fdt fdt device tree
   bluez   bluez stack connectivity
   kvm KVM acceleration support
+  hax HAX acceleration support
   coloCOarse-grain LOck-stepping VM for Non-stop Service
   rdmaRDMA-based migration support
   vde support for vde network
@@ -5063,6 +5071,7 @@ echo "ATTR/XATTR support $attr"
 echo "Install blobs $blobs"
 echo "KVM support   $kvm"
 echo "COLO support  $colo"
+echo "HAX support   $hax"
 echo "RDMA support  $rdma"
 echo "TCG interpreter   $tcg_interpreter"
 echo "fdt support   $fdt"
@@ -6050,6 +6059,15 @@ case "$target_name" in
   fi
 fi
 esac
+if test "$hax" = "yes" ; then
+  if test "$target_softmmu" = "yes" ; then
+case "$target_name" in
+i386|x86_64)
+  echo "CONFIG_HAX=y" >> $config_target_mak
+;;
+esac
+  fi
+fi
 if test "$target_bigendian" = "yes" ; then
   echo "TARGET_WORDS_BIGENDIAN=y" >> $config_target_mak
 fi
diff --git a/cpus.c b/cpus.c
index fc78502ce5..71a82e5004 100644
--- a/cpus.c
+++ b/cpus.c
@@ -35,6 +35,7 @@
 #include "sysemu/dma.h"
 #include "sysemu/hw_accel.h"
 #include "sysemu/kvm.h"
+#include "sysemu/hax.h"
 #include "qmp-commands.h"
 #include "exec/exec-all.h"
 
@@ -1221,6 +1222,46 @@ static void *qemu_tcg_cpu_thread_fn(void *arg)
 return NULL;
 }
 
+static void *qemu_hax_cpu_thread_fn(void *arg)
+{
+CPUState *cpu = arg;
+int r;
+qemu_thread_get_self(cpu->thread);
+qemu_mutex_lock(&qemu_global_mutex);
+
+cpu->thread_id = qemu_get_thread_id();
+cpu->created = true;
+cpu->halted = 0;
+current_cpu = cpu;
+
+hax_init_vcpu(cpu);
+qemu_cond_signal(&qemu_cpu_cond);
+
+while (1) {
+if (cpu_can_run(cpu)) {
+r = hax_smp_cpu_exec(cpu);
+if (r == EXCP_DEBUG) {
+cpu_handle_guest_debug(cpu);
+}
+}
+
+while (cpu_thread_is_idle(cpu)) {
+qemu_cond_wait(cpu->halt_cond, &qemu_global_mutex);
+}
+#ifdef _WIN32
+SleepEx(0, TRUE);
+#endif
+qemu_wait_io_event_common(cpu);
+}
+return NULL;
+}
+
+#ifdef _WIN32
+static void CALLBACK dummy_apc_func(ULONG_PTR unused)
+{
+}
+#endif
+
 static void qemu_cpu_kick_thread(CPUState *cpu)
 {
 #ifndef _WIN32
@@ -1236,7 +1277,13 @@ static void qemu_cpu_kick_thread(CPUState *cpu)
 exit(1);
 }
 #else /* _WIN32 */
-abort();
+if (!qemu_cpu_is_self(cpu)) {
+if (!QueueUserAPC(dummy_apc_func, cpu->hThread, 0)) {
+fprintf(stderr, "%s: QueueUserAPC failed with error %lu\n",
+__func__, GetLastError());
+exit(1);
+}
+}
 #endif
 }
 
@@ -1259,6 +1306,13 @@ void qemu_cpu_kick(CPUState *cpu)
 if (tcg_enabled()) {
 qemu_cpu_kick_no_halt();
 } else {
+if (hax_enabled()) {
+/*
+ * FIXME: race condition with the exit_request check in
+ 

[Qemu-devel] [PATCH v6 0/4] Add HAX support

[Vincent Palatin]

I took a stab at trying to rebase/upstream the support for Intel HAXM.
(Hardware Accelerated Execution Manager).
Intel HAX is kernel-based hardware acceleration module for Windows and MacOSX.

Another copy of this patchset is available at:
I have made another public copy there:
git://github.com/vpalatin/qemu.git tags/hax-v6-pull-request

https://github.com/vpalatin/qemu/tree/hax-v6-pull-request

I have based my work on the last version of the source code I found:
the emu-2.2-release branch in the external/qemu-android repository as used by
the Android emulator.
In patch 2/4, I have forward-ported the core HAX code from there.
It has been modified to build and run along with the current code base.
It has been simplifying by removing non-UG hardware support / Darwin support /
Android-specific leftovers.

This code depends on the new unmapping mechanism and fixes in Intel HAX kernel
module. They will publish soon a new version 6.1.0 of the HAX kernel module
including the fixes once their QA cycle is completed.
Thanks Yu Ning for making this happen.

In patch 3/4, I have put the plumbing into the QEMU code base, I did some clean
up there and it is reasonably intrusive: i.e.
 Makefile.target   |  1 +
 configure | 18 
 cpus.c| 74 ++-
 hw/intc/apic_common.c |  3 +-
 include/qom/cpu.h |  5 
 include/sysemu/hw_accel.h |  9 ++
 qemu-options.hx   | 11 +++
 target/i386/Makefile.objs |  4 +++
 util/qemu-thread-win32.c  |  4 +--
 vl.c  | 15 --
 10 files changed, 137 insertions(+), 7 deletions(-)

The patch 1/4 just extracts from KVM specific header the cpu_synchronize_
functions that HAX is also using.

The patch 4/4 is the Darwin support. This part is only lightly tested for now,
so it can be considered as 'experimental'.

I have tested the end result on a Windows 10 Pro machine (with UG support)
with the Intel HAXM module dev version and a large ChromiumOS x86_64 image to
exercise various code paths. It looks stable.
I also did a quick regression testing of the integration by running a Linux
build with KVM enabled.

Changes from v5 to v6:
- rebase against new upstream target directories changes
- rebase on top of Paolo's ramblock-notifier patch and use the new API.
- adjust qemu_cpu_kick according to Paolo's suggestions / use QueueUserApc.

Changes from v4 to v5:
- update HAX fastmmio API with the new MMIO to MMIO transfer.

Changes from v3 to v4:
- add RAM unmapping in the MemoryListener thanks to new API in HAX module 6.1.0
  and re-wrote the memory mappings management to deal with this.
- marked no longer used MMIO emulation as unsupported.
- clean-up a few left-overs from removed code.
- re-add an experimental version of the Darwin support.

Changes from v2 to v3:
- fix saving/restoring FPU registers as suggested by Paolo.
- fix Windows build on all targets as contributed by Stefan Weil.
- clean-up IO / MMIO emulation.
- more clean-up of emulation leftovers.

Changes from v1 to v2:
- fix all style issues in the original code to get it through checkpatch.pl.
- remove Darwin support, it was barely tested and not fully functional.
- remove the support for CPU without UG mode.
- fix most review comments

Vincent Palatin (4):
  kvm: move cpu synchronization code
  target/i386: Add Intel HAX files
  Plumb the HAXM-based hardware acceleration support
  hax: add Darwin support

 Makefile.target |1 +
 configure   |   18 +
 cpus.c  |   79 ++-
 gdbstub.c   |1 +
 hax-stub.c  |   39 ++
 hw/i386/kvm/apic.c  |1 +
 hw/i386/kvmvapic.c  |1 +
 hw/intc/apic_common.c   |3 +-
 hw/misc/vmport.c|2 +-
 hw/ppc/pnv_xscom.c  |2 +-
 hw/ppc/ppce500_spin.c   |4 +-
 hw/ppc/spapr.c  |2 +-
 hw/ppc/spapr_hcall.c|2 +-
 hw/s390x/s390-pci-inst.c|1 +
 include/qom/cpu.h   |5 +
 include/sysemu/hax.h|   56 +++
 include/sysemu/hw_accel.h   |   48 ++
 include/sysemu/kvm.h|   23 -
 monitor.c   |2 +-
 qemu-options.hx |   11 +
 qom/cpu.c   |2 +-
 target/arm/cpu.c|2 +-
 target/i386/Makefile.objs   |7 +
 target/i386/hax-all.c   | 1155 +++
 target/i386/hax-darwin.c|  316 
 target/i386/hax-darwin.h|   63 +++
 target/i386/hax-i386.h  |   94 
 target/i386/hax-interface.h |  361 ++
 target/i386/hax-mem.c   |  289 +++
 target/i386/hax-windows.c   |  479 ++
 target/i386/hax-windows.h   |   89 
 target/i386/helper.c|1 +
 target/i386/kvm.c   |1 +
 target/ppc/mmu-hash64.c |2 +-
 target/ppc/translate_init.c |2 +-
 target/s390x/gdbstub.c  |1 +
 util/qemu-thread-win32.c|

[Qemu-devel] [PATCH v6 4/4] hax: add Darwin support

[Vincent Palatin]

Re-add the MacOSX/Darwin support:
Use the Intel HAX is kernel-based hardware acceleration module
(similar to KVM on Linux).

Based on the original "target/i386: Add Intel HAX to android emulator" patch
from David Chou  from  emu-2.2-release branch in
the external/qemu-android repository.

Signed-off-by: Vincent Palatin 
---
 target/i386/Makefile.objs |   3 +
 target/i386/hax-darwin.c  | 316 ++
 target/i386/hax-darwin.h  |  63 +
 target/i386/hax-i386.h|   8 ++
 4 files changed, 390 insertions(+)
 create mode 100644 target/i386/hax-darwin.c
 create mode 100644 target/i386/hax-darwin.h

diff --git a/target/i386/Makefile.objs b/target/i386/Makefile.objs
index acbe7b0752..4fcb7f3df0 100644
--- a/target/i386/Makefile.objs
+++ b/target/i386/Makefile.objs
@@ -9,3 +9,6 @@ obj-$(call lnot,$(CONFIG_KVM)) += kvm-stub.o
 ifdef CONFIG_WIN32
 obj-$(CONFIG_HAX) += hax-all.o hax-mem.o hax-windows.o
 endif
+ifdef CONFIG_DARWIN
+obj-$(CONFIG_HAX) += hax-all.o hax-mem.o hax-darwin.o
+endif
diff --git a/target/i386/hax-darwin.c b/target/i386/hax-darwin.c
new file mode 100644
index 00..1c5bbd0a2d
--- /dev/null
+++ b/target/i386/hax-darwin.c
@@ -0,0 +1,316 @@
+/*
+ * QEMU HAXM support
+ *
+ * Copyright (c) 2011 Intel Corporation
+ *  Written by:
+ *  Jiang Yunhong
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+/* HAX module interface - darwin version */
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "qemu/osdep.h"
+#include "target/i386/hax-i386.h"
+
+hax_fd hax_mod_open(void)
+{
+int fd = open("/dev/HAX", O_RDWR);
+if (fd == -1) {
+fprintf(stderr, "Failed to open the hax module\n");
+}
+
+fcntl(fd, F_SETFD, FD_CLOEXEC);
+
+return fd;
+}
+
+int hax_populate_ram(uint64_t va, uint32_t size)
+{
+int ret;
+struct hax_alloc_ram_info info;
+
+if (!hax_global.vm || !hax_global.vm->fd) {
+fprintf(stderr, "Allocate memory before vm create?\n");
+return -EINVAL;
+}
+
+info.size = size;
+info.va = va;
+ret = ioctl(hax_global.vm->fd, HAX_VM_IOCTL_ALLOC_RAM, &info);
+if (ret < 0) {
+fprintf(stderr, "Failed to allocate %x memory\n", size);
+return ret;
+}
+return 0;
+}
+
+int hax_set_ram(uint64_t start_pa, uint32_t size, uint64_t host_va, int flags)
+{
+struct hax_set_ram_info info;
+int ret;
+
+info.pa_start = start_pa;
+info.size = size;
+info.va = host_va;
+info.flags = (uint8_t) flags;
+
+ret = ioctl(hax_global.vm->fd, HAX_VM_IOCTL_SET_RAM, &info);
+if (ret < 0) {
+return -errno;
+}
+return 0;
+}
+
+int hax_capability(struct hax_state *hax, struct hax_capabilityinfo *cap)
+{
+int ret;
+
+ret = ioctl(hax->fd, HAX_IOCTL_CAPABILITY, cap);
+if (ret == -1) {
+fprintf(stderr, "Failed to get HAX capability\n");
+return -errno;
+}
+
+return 0;
+}
+
+int hax_mod_version(struct hax_state *hax, struct hax_module_version *version)
+{
+int ret;
+
+ret = ioctl(hax->fd, HAX_IOCTL_VERSION, version);
+if (ret == -1) {
+fprintf(stderr, "Failed to get HAX version\n");
+return -errno;
+}
+
+return 0;
+}
+
+static char *hax_vm_devfs_string(int vm_id)
+{
+char *name;
+
+if (vm_id > MAX_VM_ID) {
+fprintf(stderr, "Too big VM id\n");
+return NULL;
+}
+
+#define HAX_VM_DEVFS "/dev/hax_vm/vmxx"
+name = g_strdup(HAX_VM_DEVFS);
+if (!name) {
+return NULL;
+}
+
+snprintf(name, sizeof HAX_VM_DEVFS, "/dev/hax_vm/vm%02d", vm_id);
+return name;
+}
+
+static char *hax_vcpu_devfs_string(int vm_id, int vcpu_id)
+{
+char *name;
+
+if (vm_id > MAX_VM_ID || vcpu_id > MAX_VCPU_ID) {
+fprintf(stderr, "Too big vm id %x or vcpu id %x\n", vm_id, vcpu_id);
+return NULL;
+}
+
+#define HAX_VCPU_DEVFS "/dev/hax_vmxx/vcpuxx"
+name = g_strdup(HAX_VCPU_DEVFS);
+if (!name) {
+return NULL;
+}
+
+snprintf(name, sizeof HAX_VCPU_DEVFS, "/dev/hax_vm%02d/vcpu%02d",
+ vm_id, vcpu_id);
+return name;
+}
+
+int hax_host_create_vm(struct hax_state *hax, int *vmid)
+{
+int ret;
+int vm_id = 0;
+
+if (hax_invalid_fd(hax->fd)) {
+return -EINVAL;
+}
+
+if (hax->vm) {
+return 0;
+}
+
+ret = ioctl(hax->fd, HAX_IOCTL_CREATE_VM, &vm_id);
+*vmid = vm_id;
+return ret;
+}
+
+hax_fd hax_host_open_vm(struct hax_state *hax, int vm_id)
+{
+hax_fd fd;
+char *vm_name = NULL;
+
+vm_name = hax_vm_devfs_string(vm_id);
+if (!vm_name) {
+return -1;
+}
+
+fd = open(vm_name, O_RDWR);
+g_free(vm_name);
+
+fcntl(fd, F_SETFD, FD_CLOEXEC);
+
+return fd;
+}
+
+int hax_notify_qemu_version(hax_fd vm_fd, struct hax_qemu_version *qversion)
+{
+int ret;
+
+if (hax_invalid_fd(vm_fd)) {
+return -EINVAL;
+

[Qemu-devel] [PATCH v6 1/4] kvm: move cpu synchronization code

[Vincent Palatin]

Move the generic cpu_synchronize_ functions to the common hw_accel.h header,
in order to prepare for the addition of a second hardware accelerator.

Signed-off-by: Stefan Weil 
Signed-off-by: Vincent Palatin 
---
 cpus.c  |  1 +
 gdbstub.c   |  1 +
 hw/i386/kvm/apic.c  |  1 +
 hw/i386/kvmvapic.c  |  1 +
 hw/misc/vmport.c|  2 +-
 hw/ppc/pnv_xscom.c  |  2 +-
 hw/ppc/ppce500_spin.c   |  4 ++--
 hw/ppc/spapr.c  |  2 +-
 hw/ppc/spapr_hcall.c|  2 +-
 hw/s390x/s390-pci-inst.c|  1 +
 include/sysemu/hw_accel.h   | 39 +++
 include/sysemu/kvm.h| 23 ---
 monitor.c   |  2 +-
 qom/cpu.c   |  2 +-
 target/arm/cpu.c|  2 +-
 target/i386/helper.c|  1 +
 target/i386/kvm.c   |  1 +
 target/ppc/mmu-hash64.c |  2 +-
 target/ppc/translate_init.c |  2 +-
 target/s390x/gdbstub.c  |  1 +
 20 files changed, 58 insertions(+), 34 deletions(-)
 create mode 100644 include/sysemu/hw_accel.h

diff --git a/cpus.c b/cpus.c
index 5213351c6d..fc78502ce5 100644
--- a/cpus.c
+++ b/cpus.c
@@ -33,6 +33,7 @@
 #include "sysemu/block-backend.h"
 #include "exec/gdbstub.h"
 #include "sysemu/dma.h"
+#include "sysemu/hw_accel.h"
 #include "sysemu/kvm.h"
 #include "qmp-commands.h"
 #include "exec/exec-all.h"
diff --git a/gdbstub.c b/gdbstub.c
index de62d26096..de9b62b8f8 100644
--- a/gdbstub.c
+++ b/gdbstub.c
@@ -32,6 +32,7 @@
 #define MAX_PACKET_LENGTH 4096
 
 #include "qemu/sockets.h"
+#include "sysemu/hw_accel.h"
 #include "sysemu/kvm.h"
 #include "exec/semihost.h"
 #include "exec/exec-all.h"
diff --git a/hw/i386/kvm/apic.c b/hw/i386/kvm/apic.c
index df5180b1e0..1df6d26816 100644
--- a/hw/i386/kvm/apic.c
+++ b/hw/i386/kvm/apic.c
@@ -14,6 +14,7 @@
 #include "cpu.h"
 #include "hw/i386/apic_internal.h"
 #include "hw/pci/msi.h"
+#include "sysemu/hw_accel.h"
 #include "sysemu/kvm.h"
 #include "target/i386/kvm_i386.h"
 
diff --git a/hw/i386/kvmvapic.c b/hw/i386/kvmvapic.c
index b30d1b90c6..2f767b620e 100644
--- a/hw/i386/kvmvapic.c
+++ b/hw/i386/kvmvapic.c
@@ -14,6 +14,7 @@
 #include "exec/exec-all.h"
 #include "sysemu/sysemu.h"
 #include "sysemu/cpus.h"
+#include "sysemu/hw_accel.h"
 #include "sysemu/kvm.h"
 #include "hw/i386/apic_internal.h"
 #include "hw/sysbus.h"
diff --git a/hw/misc/vmport.c b/hw/misc/vmport.c
index c763811a9f..be40930b8b 100644
--- a/hw/misc/vmport.c
+++ b/hw/misc/vmport.c
@@ -25,7 +25,7 @@
 #include "hw/hw.h"
 #include "hw/isa/isa.h"
 #include "hw/i386/pc.h"
-#include "sysemu/kvm.h"
+#include "sysemu/hw_accel.h"
 #include "hw/qdev.h"
 
 //#define VMPORT_DEBUG
diff --git a/hw/ppc/pnv_xscom.c b/hw/ppc/pnv_xscom.c
index b82af4f086..38bc85f117 100644
--- a/hw/ppc/pnv_xscom.c
+++ b/hw/ppc/pnv_xscom.c
@@ -20,7 +20,7 @@
 #include "qapi/error.h"
 #include "hw/hw.h"
 #include "qemu/log.h"
-#include "sysemu/kvm.h"
+#include "sysemu/hw_accel.h"
 #include "target/ppc/cpu.h"
 #include "hw/sysbus.h"
 
diff --git a/hw/ppc/ppce500_spin.c b/hw/ppc/ppce500_spin.c
index cf958a9e00..eb219abdff 100644
--- a/hw/ppc/ppce500_spin.c
+++ b/hw/ppc/ppce500_spin.c
@@ -29,9 +29,9 @@
 
 #include "qemu/osdep.h"
 #include "hw/hw.h"
-#include "sysemu/sysemu.h"
 #include "hw/sysbus.h"
-#include "sysemu/kvm.h"
+#include "sysemu/hw_accel.h"
+#include "sysemu/sysemu.h"
 #include "e500.h"
 
 #define MAX_CPUS 32
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 208ef7b110..a642e663d4 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -36,7 +36,7 @@
 #include "sysemu/device_tree.h"
 #include "sysemu/block-backend.h"
 #include "sysemu/cpus.h"
-#include "sysemu/kvm.h"
+#include "sysemu/hw_accel.h"
 #include "kvm_ppc.h"
 #include "migration/migration.h"
 #include "mmu-hash64.h"
diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
index 9a9bedf1bd..b2a8e48569 100644
--- a/hw/ppc/spapr_hcall.c
+++ b/hw/ppc/spapr_hcall.c
@@ -1,5 +1,6 @@
 #include "qemu/osdep.h"
 #include "qapi/error.h"
+#include "sysemu/hw_accel.h"
 #include "sysemu/sysemu.h"
 #include "qemu/log.h"
 #include "cpu.h"
@@ -9,7 +10,6 @@
 #include "mmu-hash64.h"
 #include "cpu-models.h"
 #include "trace.h"
-#include "sysemu/kvm.h"
 #include "kvm_ppc.h"
 #include "hw/ppc/spapr_ovec.h"
 
diff --git a/hw/s390x/s390-pci-inst.c b/hw/s390x/s390-pci-inst.c
index 0864d9be12..4d0775c83f 100644
--- a/hw/s390x/s390-pci-inst.c
+++ b/hw/s390x/s390-pci-inst.c
@@ -18,6 +18,7 @@
 #include "s390-pci-bus.h"
 #include "exec/memory-internal.h"
 #include "qemu/error-report.h"
+#include "sysemu/hw_accel.h"
 
 /* #define DEBUG_S390PCI_INST */
 #ifdef DEBUG_S390PCI_INST
diff --git a/include/sysemu/hw_accel.h b/include/sysemu/hw_accel.h
new file mode 100644
index 00..03812cfeb3
--- /dev/null
+++ b/include/sysemu/hw_accel.h
@@ -0,0 +1,39 @@
+/*
+ * QEMU Hardware accelertors support
+ *
+ * Copyright 2016 Google, Inc.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * 

Re: [Qemu-devel] [PATCH v4 1/4] migration: Add a new option to enable only-migratable

[Dr. David Alan Gilbert]

* Ashijeet Acharya (ashijeetacha...@gmail.com) wrote:
> Add a new option "--only-migratable" in qemu which will allow to add
> only those devices which will not fail qemu after migration. Devices
> set with the flag 'unmigratable' cannot be added when this option will
> be used.
> 
> Signed-off-by: Ashijeet Acharya 
> ---
>  include/migration/migration.h | 3 +++
>  qemu-options.hx   | 9 +
>  vl.c  | 4 
>  3 files changed, 16 insertions(+)
> 
> diff --git a/include/migration/migration.h b/include/migration/migration.h
> index c309d23..40b3697 100644
> --- a/include/migration/migration.h
> +++ b/include/migration/migration.h
> @@ -38,6 +38,9 @@
>  #define QEMU_VM_COMMAND  0x08
>  #define QEMU_VM_SECTION_FOOTER   0x7e
>  
> +/* for vl.c */
> +extern int only_migratable;
> +
>  struct MigrationParams {
>  bool blk;
>  bool shared;
> diff --git a/qemu-options.hx b/qemu-options.hx
> index c534a2f..1e16ae8 100644
> --- a/qemu-options.hx
> +++ b/qemu-options.hx
> @@ -3574,6 +3574,15 @@ be used to change settings (such as migration 
> parameters) prior to issuing
>  the migrate_incoming to allow the migration to begin.
>  ETEXI
>  
> +DEF("only-migratable", 0, QEMU_OPTION_only_migratable, \
> +"-only-migratable allow only migratable devices\n", QEMU_ARCH_ALL)
> +STEXI
> +@item -only-migratable
> +@findex -only-migratable
> +Only allow migratable devices. Devices will not be allowed to enter an
> +unmigratable state.
> +ETEXI
> +
>  DEF("nodefaults", 0, QEMU_OPTION_nodefaults, \
>  "-nodefaults don't create default devices\n", QEMU_ARCH_ALL)
>  STEXI
> diff --git a/vl.c b/vl.c
> index d77dd86..82bffb9 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -180,6 +180,7 @@ bool boot_strict;
>  uint8_t *boot_splash_filedata;
>  size_t boot_splash_filedata_size;
>  uint8_t qemu_extra_params_fw[2];
> +int only_migratable = 0; /* turn it off unless user states otherwise */

QEMU coding style is to omit the =0 for globals.

Other than that,

Reviewed-by: Dr. David Alan Gilbert 

Dave

>  int icount_align_option;
>  
> @@ -3914,6 +3915,9 @@ int main(int argc, char **argv, char **envp)
>  }
>  incoming = optarg;
>  break;
> +case QEMU_OPTION_only_migratable:
> +only_migratable = 1;
> +break;
>  case QEMU_OPTION_nodefaults:
>  has_defaults = 0;
>  break;
> -- 
> 2.6.2
> 
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

[Qemu-devel] [PATCH] char: fix ctrl-a b not working

[Marc-André Lureau]

CharDriverState.be should be updated to point to the current
associated backend.

Fix the regression introduced in the "mux" chardev from commit
a4afa548fc6dd9842ed86639b4d37d4d1c4ad480.

https://bugs.launchpad.net/bugs/1654137

Signed-off-by: Marc-André Lureau 
---
 qemu-char.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/qemu-char.c b/qemu-char.c
index 2c9940cea4..676944a765 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -499,7 +499,7 @@ void qemu_chr_fe_printf(CharBackend *be, const char *fmt, 
...)
 
 static void remove_fd_in_watch(CharDriverState *chr);
 static void mux_chr_set_handlers(CharDriverState *chr, GMainContext *context);
-static void mux_set_focus(MuxDriver *d, int focus);
+static void mux_set_focus(CharDriverState *chr, int focus);
 
 static int null_chr_write(CharDriverState *chr, const uint8_t *buf, int len)
 {
@@ -666,7 +666,7 @@ static int mux_proc_byte(CharDriverState *chr, MuxDriver 
*d, int ch)
 case 'c':
 assert(d->mux_cnt > 0); /* handler registered with first fe */
 /* Switch to the next registered device */
-mux_set_focus(d, (d->focus + 1) % d->mux_cnt);
+mux_set_focus(chr, (d->focus + 1) % d->mux_cnt);
 break;
 case 't':
 d->timestamps = !d->timestamps;
@@ -826,8 +826,10 @@ static void mux_chr_set_handlers(CharDriverState *chr, 
GMainContext *context)
  context, true);
 }
 
-static void mux_set_focus(MuxDriver *d, int focus)
+static void mux_set_focus(CharDriverState *chr, int focus)
 {
+MuxDriver *d = chr->opaque;
+
 assert(focus >= 0);
 assert(focus < d->mux_cnt);
 
@@ -836,6 +838,7 @@ static void mux_set_focus(MuxDriver *d, int focus)
 }
 
 d->focus = focus;
+chr->be = d->backends[focus];
 mux_chr_send_event(d, d->focus, CHR_EVENT_MUX_IN);
 }
 
@@ -935,7 +938,9 @@ void qemu_chr_fe_deinit(CharBackend *b)
 
 if (b->chr) {
 qemu_chr_fe_set_handlers(b, NULL, NULL, NULL, NULL, NULL, true);
-b->chr->be = NULL;
+if (b->chr->be == b) {
+b->chr->be = NULL;
+}
 if (b->chr->is_mux) {
 MuxDriver *d = b->chr->opaque;
 d->backends[b->tag] = NULL;
@@ -999,7 +1004,7 @@ void qemu_chr_fe_take_focus(CharBackend *b)
 }
 
 if (b->chr->is_mux) {
-mux_set_focus(b->chr->opaque, b->tag);
+mux_set_focus(b->chr, b->tag);
 }
 }
 
-- 
2.11.0

[Qemu-devel] [PATCH v6 2/4] target/i386: Add Intel HAX files

[Vincent Palatin]

That's a forward port of the core HAX interface code from the
emu-2.2-release branch in the external/qemu-android repository as used by
the Android emulator.

The original commit was "target/i386: Add Intel HAX to android emulator"
saying:
"""
  Backport of 2b3098ff27bab079caab9b46b58546b5036f5c0c
  from studio-1.4-dev into emu-master-dev

Intel HAX (harware acceleration) will enhance android emulator performance
in Windows and Mac OS X in the systems powered by Intel processors with
"Intel Hardware Accelerated Execution Manager" package installed when
user runs android emulator with Intel target.

Signed-off-by: David Chou 
"""

It has been modified to build and run along with the current code base.
The formatting has been fixed to go through scripts/checkpatch.pl,
and the DPRINTF macros have been updated to get the instanciations checked by
the compiler.

The FPU registers saving/restoring has been updated to match the current
QEMU registers layout.

The implementation has been simplified by doing the following modifications:
- removing the code for supporting the hardware without Unrestricted Guest (UG)
  mode (including all the code to fallback on TCG emulation).
- not including the Darwin support (which is not yet debugged/tested).
- simplifying the initialization by removing the leftovers from the Android
  specific code, then trimming down the remaining logic.
- removing the unused MemoryListener callbacks.

Signed-off-by: Vincent Palatin 
---
 hax-stub.c  |   39 ++
 include/sysemu/hax.h|   56 +++
 target/i386/hax-all.c   | 1155 +++
 target/i386/hax-i386.h  |   86 
 target/i386/hax-interface.h |  361 ++
 target/i386/hax-mem.c   |  289 +++
 target/i386/hax-windows.c   |  479 ++
 target/i386/hax-windows.h   |   89 
 8 files changed, 2554 insertions(+)
 create mode 100644 hax-stub.c
 create mode 100644 include/sysemu/hax.h
 create mode 100644 target/i386/hax-all.c
 create mode 100644 target/i386/hax-i386.h
 create mode 100644 target/i386/hax-interface.h
 create mode 100644 target/i386/hax-mem.c
 create mode 100644 target/i386/hax-windows.c
 create mode 100644 target/i386/hax-windows.h

diff --git a/hax-stub.c b/hax-stub.c
new file mode 100644
index 00..a532dbae81
--- /dev/null
+++ b/hax-stub.c
@@ -0,0 +1,39 @@
+/*
+ * QEMU HAXM support
+ *
+ * Copyright (c) 2015, Intel Corporation
+ *
+ * Copyright 2016 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#include "qemu/osdep.h"
+#include "qemu-common.h"
+#include "cpu.h"
+#include "sysemu/hax.h"
+
+int hax_sync_vcpus(void)
+{
+return 0;
+}
+
+int hax_populate_ram(uint64_t va, uint32_t size)
+{
+return -ENOSYS;
+}
+
+int hax_init_vcpu(CPUState *cpu)
+{
+return -ENOSYS;
+}
+
+int hax_smp_cpu_exec(CPUState *cpu)
+{
+return -ENOSYS;
+}
diff --git a/include/sysemu/hax.h b/include/sysemu/hax.h
new file mode 100644
index 00..d9f023918e
--- /dev/null
+++ b/include/sysemu/hax.h
@@ -0,0 +1,56 @@
+/*
+ * QEMU HAXM support
+ *
+ * Copyright IBM, Corp. 2008
+ *
+ * Authors:
+ *  Anthony Liguori   
+ *
+ * Copyright (c) 2011 Intel Corporation
+ *  Written by:
+ *  Jiang Yunhong
+ *  Xin Xiaohui
+ *  Zhang Xiantao
+ *
+ * Copyright 2016 Google, Inc.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#ifndef QEMU_HAX_H
+#define QEMU_HAX_H
+
+#include "config-host.h"
+#include "qemu-common.h"
+
+int hax_sync_vcpus(void);
+int hax_init_vcpu(CPUState *cpu);
+int hax_smp_cpu_exec(CPUState *cpu);
+int hax_populate_ram(uint64_t va, uint32_t size);
+
+void hax_cpu_synchronize_state(CPUState *cpu);
+void hax_cpu_synchronize_post_reset(CPUState *cpu);
+void hax_cpu_synchronize_post_init(CPUState *cpu);
+
+#ifdef CONFIG_HAX
+
+int hax_enabled(void);
+
+#include "hw/hw.h"
+#include "qemu/bitops.h"
+#include "exec/memory.h"
+int hax_vcpu_destroy(CPUState *cpu);
+void hax_raise_event(CPUState *cpu);
+void hax_reset_vcpu_state(void *opaque);
+#include "target/i386/hax-interface.h"
+#include "target/i386/hax-i386.h"
+
+#else /* CONFIG_HAX */
+
+#define hax_enabled() (0)
+
+#endif /* CONFIG_HAX */
+
+#endif /* QEMU_HAX_H */
diff --git a/target/i386/hax-all.c b/target/i386/hax-all.c
new file mode 100644
index 00..ef13015215
--- /dev/null
+++ b/target/i386/hax-all.c
@@ -0,0 +1,1155 @@
+/*
+ * QEMU HAX support
+ *
+ * Copyright IBM, Corp. 2008
+ *   Red Hat, Inc. 2008
+ *
+ * Authors:
+ *  Anthony Liguori   
+ *  Glauber Costa 
+ *
+ * Copyright (c) 2011 Intel Corporation
+ *  Written by:
+ *  Jiang Yunhong
+ *  Xin Xiaohui
+ *  Zhang Xiantao
+ *
+ * This work is li

Re: [Qemu-devel] [PATCH] char: fix ctrl-a b not working

[Paolo Bonzini]

On 10/01/2017 12:06, Marc-André Lureau wrote:
> CharDriverState.be should be updated to point to the current
> associated backend.
> 
> Fix the regression introduced in the "mux" chardev from commit
> a4afa548fc6dd9842ed86639b4d37d4d1c4ad480.
> 
> https://bugs.launchpad.net/bugs/1654137

Queued.

However, can you also simplify mux_chr_accept_input, mux_chr_can_read
and mux_chr_read to use d->be directly, with this change?

Thanks,

Paolo

> Signed-off-by: Marc-André Lureau 
> ---
>  qemu-char.c | 15 ++-
>  1 file changed, 10 insertions(+), 5 deletions(-)
> 
> diff --git a/qemu-char.c b/qemu-char.c
> index 2c9940cea4..676944a765 100644
> --- a/qemu-char.c
> +++ b/qemu-char.c
> @@ -499,7 +499,7 @@ void qemu_chr_fe_printf(CharBackend *be, const char *fmt, 
> ...)
>  
>  static void remove_fd_in_watch(CharDriverState *chr);
>  static void mux_chr_set_handlers(CharDriverState *chr, GMainContext 
> *context);
> -static void mux_set_focus(MuxDriver *d, int focus);
> +static void mux_set_focus(CharDriverState *chr, int focus);
>  
>  static int null_chr_write(CharDriverState *chr, const uint8_t *buf, int len)
>  {
> @@ -666,7 +666,7 @@ static int mux_proc_byte(CharDriverState *chr, MuxDriver 
> *d, int ch)
>  case 'c':
>  assert(d->mux_cnt > 0); /* handler registered with first fe */
>  /* Switch to the next registered device */
> -mux_set_focus(d, (d->focus + 1) % d->mux_cnt);
> +mux_set_focus(chr, (d->focus + 1) % d->mux_cnt);
>  break;
>  case 't':
>  d->timestamps = !d->timestamps;
> @@ -826,8 +826,10 @@ static void mux_chr_set_handlers(CharDriverState *chr, 
> GMainContext *context)
>   context, true);
>  }
>  
> -static void mux_set_focus(MuxDriver *d, int focus)
> +static void mux_set_focus(CharDriverState *chr, int focus)
>  {
> +MuxDriver *d = chr->opaque;
> +
>  assert(focus >= 0);
>  assert(focus < d->mux_cnt);
>  
> @@ -836,6 +838,7 @@ static void mux_set_focus(MuxDriver *d, int focus)
>  }
>  
>  d->focus = focus;
> +chr->be = d->backends[focus];
>  mux_chr_send_event(d, d->focus, CHR_EVENT_MUX_IN);
>  }
>  
> @@ -935,7 +938,9 @@ void qemu_chr_fe_deinit(CharBackend *b)
>  
>  if (b->chr) {
>  qemu_chr_fe_set_handlers(b, NULL, NULL, NULL, NULL, NULL, true);
> -b->chr->be = NULL;
> +if (b->chr->be == b) {
> +b->chr->be = NULL;
> +}
>  if (b->chr->is_mux) {
>  MuxDriver *d = b->chr->opaque;
>  d->backends[b->tag] = NULL;
> @@ -999,7 +1004,7 @@ void qemu_chr_fe_take_focus(CharBackend *b)
>  }
>  
>  if (b->chr->is_mux) {
> -mux_set_focus(b->chr->opaque, b->tag);
> +mux_set_focus(b->chr, b->tag);
>  }
>  }
>  
> 

Re: [Qemu-devel] [PATCH v4 2/4] migration: Allow "device add" options to only add migratable devices

[Dr. David Alan Gilbert]

* Ashijeet Acharya (ashijeetacha...@gmail.com) wrote:
> Introduce checks for the unmigratable flag in the VMStateDescription
> structs of respective devices when user attempts to add them. If the
> "--only-migratable" was specified, all unmigratable devices will
> rightly fail to add. This feature is made compatible for both "-device"
> and "-usbdevice" command line options and covers their hmp and qmp
> counterparts as well.
> 
> Signed-off-by: Ashijeet Acharya 
> ---
>  hw/usb/bus.c   | 18 ++
>  qdev-monitor.c |  9 +
>  2 files changed, 27 insertions(+)
> 
> diff --git a/hw/usb/bus.c b/hw/usb/bus.c
> index 25913ad..3d26103 100644
> --- a/hw/usb/bus.c
> +++ b/hw/usb/bus.c
> @@ -8,6 +8,7 @@
>  #include "monitor/monitor.h"
>  #include "trace.h"
>  #include "qemu/cutils.h"
> +#include "migration/migration.h"
>  
>  static void usb_bus_dev_print(Monitor *mon, DeviceState *qdev, int indent);
>  
> @@ -686,6 +687,8 @@ USBDevice *usbdevice_create(const char *cmdline)
>  const char *params;
>  int len;
>  USBDevice *dev;
> +ObjectClass *klass;
> +DeviceClass *dc;
>  
>  params = strchr(cmdline,':');
>  if (params) {
> @@ -720,6 +723,21 @@ USBDevice *usbdevice_create(const char *cmdline)
>  return NULL;
>  }
>  
> +klass = object_class_by_name(f->name);
> +if (klass == NULL) {
> +return NULL;

All error paths should print something, even if it shouldn't happen.

Dave

> +}
> +
> +dc = DEVICE_CLASS(klass);
> +
> +if (only_migratable) {
> +if (dc->vmsd->unmigratable) {
> +error_report("Device %s is not migratable, but --only-migratable 
> "
> + "was specified", f->name);
> +return NULL;
> +}
> +}
> +
>  if (f->usbdevice_init) {
>  dev = f->usbdevice_init(bus, params);
>  } else {
> diff --git a/qdev-monitor.c b/qdev-monitor.c
> index c73410c..81d01df 100644
> --- a/qdev-monitor.c
> +++ b/qdev-monitor.c
> @@ -29,6 +29,7 @@
>  #include "qemu/error-report.h"
>  #include "qemu/help_option.h"
>  #include "sysemu/block-backend.h"
> +#include "migration/migration.h"
>  
>  /*
>   * Aliases were a bad idea from the start.  Let's keep them
> @@ -577,6 +578,14 @@ DeviceState *qdev_device_add(QemuOpts *opts, Error 
> **errp)
>  return NULL;
>  }
>  
> +if (only_migratable) {
> +if (dc->vmsd->unmigratable) {
> +error_setg(errp, "Device %s is not migratable, but "
> +   "--only-migratable was specified", driver);
> +return NULL;
> +}
> +}
> +
>  /* find bus */
>  path = qemu_opt_get(opts, "bus");
>  if (path != NULL) {
> -- 
> 2.6.2
> 
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

Re: [Qemu-devel] [PATCH v6 0/4] Add HAX support

[Vincent Palatin]

On Tue, Jan 10, 2017 at 12:20 PM,   wrote:
> Hi,
>
> Your series failed automatic build test. Please find the testing commands and
> their output below. If you have docker installed, you can probably reproduce 
> it
> locally.
[...]
> /tmp/qemu-test/src/target/i386/hax-mem.c:268:33: error: unknown type name 
> 'RAMBlockNotifier'
>  static void hax_ram_block_added(RAMBlockNotifier *n, void *host, size_t size)
>  ^~~~
> /tmp/qemu-test/src/target/i386/hax-mem.c:281:15: error: variable 
> 'hax_ram_notifier' has initializer but incomplete type
>  static struct RAMBlockNotifier hax_ram_notifier = {
>^~~~
> /tmp/qemu-test/src/target/i386/hax-mem.c:282:5: error: unknown field 
> 'ram_block_added' specified in initializer
>  .ram_block_added = hax_ram_block_added,
>  ^
> /tmp/qemu-test/src/target/i386/hax-mem.c:282:24: error: 'hax_ram_block_added' 
> undeclared here (not in a function)
>  .ram_block_added = hax_ram_block_added,
> ^~~
> /tmp/qemu-test/src/target/i386/hax-mem.c:282:24: error: excess elements in 
> struct initializer [-Werror]
> /tmp/qemu-test/src/target/i386/hax-mem.c:282:24: note: (near initialization 
> for 'hax_ram_notifier')
> /tmp/qemu-test/src/target/i386/hax-mem.c: In function 'hax_memory_init':
> /tmp/qemu-test/src/target/i386/hax-mem.c:287:5: error: implicit declaration 
> of function 'ram_block_notifier_add' [-Werror=implicit-function-declaration]
>  ram_block_notifier_add(&hax_ram_notifier);
>  ^~
> /tmp/qemu-test/src/target/i386/hax-mem.c:287:5: error: nested extern 
> declaration of 'ram_block_notifier_add' [-Werror=nested-externs]
> /tmp/qemu-test/src/target/i386/hax-mem.c: At top level:
> /tmp/qemu-test/src/target/i386/hax-mem.c:281:32: error: storage size of 
> 'hax_ram_notifier' isn't known
>  static struct RAMBlockNotifier hax_ram_notifier = {
> ^~~~
> cc1: all warnings being treated as errors
> /tmp/qemu-test/src/rules.mak:64: recipe for target 'target/i386/hax-mem.o' 
> failed

it failed on the dependency to the unsubmitted Paolo's ramblock-notifier patch.

-- 
Vincent

Re: [Qemu-devel] [PATCH v3 0/3] add support for mice with extra/side buttons

[Gerd Hoffmann]

On Di, 2017-01-10 at 00:47 +0100, Fabian Lesniak wrote:
> Ping.
> 
> I forgot to CC Gerd.
> 
> http://patchwork.ozlabs.org/patch/703302/
> 
> http://patchwork.ozlabs.org/patch/703304/
> 
> http://patchwork.ozlabs.org/patch/703303/

Added to ui queue now.

thanks,
  Gerd

Re: [Qemu-devel] Question about add AF_ALG backend for virtio-crypto

[Gonglei (Arei)]

Hi Daniel,

>
> >
> > >
> > > On Mon, Jan 09, 2017 at 01:43:10PM +, Stefan Hajnoczi wrote:
> > > > On Mon, Jan 09, 2017 at 03:04:55PM +0800, Longpeng (Mike) wrote:
> > > > > I'm one of Gonglei's virtio-crypto project members, and we plan to 
> > > > > add a
> > > AF_ALG
> > > > > backend for virtio-crypto(there's only builtin-backend currently).
> > > > >
> > > > > I found that Catalin, Paolo and Stefan had discussed about this in 
> > > > > 2015
> > > > > (http://www.spinics.net/lists/kvm/msg115457.html), but it seems that
> > > Catalin
> > > > > didn't do it, so I'm confuse about wether it is need to add a AF_ALG
> > > backend.
> > > > >
> > > > > Do you have any suggestion? Thanks :)
> > > >
> > > > I have no objections to an AF_ALG backend in QEMU.
> > >
> > > Rather than do another backend for virtio-crypto, IMHO, we should have
> > > an AF_ALG impl of the crypto/ APIs. That way any potential performance
> > > benefits will enhance our LUKS encryption code too.
> > >
> > According to the currently schemas of crypto/ APIs, we can't choose the
> > specific backend dynamically. This is a limitation for virtio-crypto
> > device I think.
> 
> Do we really need to be able to choose the backend explicitly. If the AF_ALG
> backend is faster, why would you simply not use that automatically if it is
> available.

Can we realize the purpose based on the crypto/ APIs? IIUC the crypto
subsystem chooses a backend during the building according to the specific 
priority,
nettle > gcrypt > cipher-builtin.

If we add an AF_ALG implementation for crypto subsystem, shall we set it
as the highest priority? If so, other backends won't be used since AF_ALG
is always available. If not, how can we use AF_ALG backend for crypto/ API?

Please correct me if I'm missing something. 

> I'm not seeing an obvious need for dynamically choosing between
> backends.
> 

Thanks,
-Gonglei

Re: [Qemu-devel] [PATCH v2] vfio/pci: Support error recovery

[Cao jin]

On 01/10/2017 07:04 AM, Michael S. Tsirkin wrote:
> On Sat, Dec 31, 2016 at 05:15:36PM +0800, Cao jin wrote:
>> Support serious device error recovery
> 
> serious?
>

Sorry for my poor vocabulary if it confuses people. I wanted to express
the meaning that: vfio-pci actually cannot do a real recovery for device
even if it provides the callbacks, it relies on the user to do a
effective(or word "serious"?) recovery.

Welcome the amendment on the commit log.

-- 
Sincerely,
Cao jin

>>
>> Signed-off-by: Cao jin 
>> ---
>>  drivers/vfio/pci/vfio_pci.c | 70 
>> +++--
>>  drivers/vfio/pci/vfio_pci_private.h |  2 ++
>>  2 files changed, 70 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
>> index 712a849..752af20 100644
>> --- a/drivers/vfio/pci/vfio_pci.c
>> +++ b/drivers/vfio/pci/vfio_pci.c
>> @@ -534,6 +534,15 @@ static long vfio_pci_ioctl(void *device_data,
>>  {
>>  struct vfio_pci_device *vdev = device_data;
>>  unsigned long minsz;
>> +int ret;
>> +
>> +if (vdev->aer_recovering && (cmd == VFIO_DEVICE_SET_IRQS ||
>> +cmd == VFIO_DEVICE_RESET || cmd == VFIO_DEVICE_PCI_HOT_RESET)) {
>> +ret = wait_for_completion_interruptible(
>> +&vdev->aer_completion);
> 
> don't split it like that.
> 
>> +if (ret)
>> +return ret;
>> +}
>>  
>>  if (cmd == VFIO_DEVICE_GET_INFO) {
>>  struct vfio_device_info info;
>> @@ -953,6 +962,15 @@ static ssize_t vfio_pci_rw(void *device_data, char 
>> __user *buf,
>>  {
>>  unsigned int index = VFIO_PCI_OFFSET_TO_INDEX(*ppos);
>>  struct vfio_pci_device *vdev = device_data;
>> +int ret;
>> +
>> +/* block all kinds of access during host recovery */
>> +if (vdev->aer_recovering) {
>> +ret = wait_for_completion_interruptible(
>> +&vdev->aer_completion);
>> +if (ret)
>> +return ret;
>> +}
>>  
>>  if (index >= VFIO_PCI_NUM_REGIONS + vdev->num_regions)
>>  return -EINVAL;
>> @@ -1117,6 +1135,7 @@ static int vfio_pci_probe(struct pci_dev *pdev, const 
>> struct pci_device_id *id)
>>  vdev->irq_type = VFIO_PCI_NUM_IRQS;
>>  mutex_init(&vdev->igate);
>>  spin_lock_init(&vdev->irqlock);
>> +init_completion(&vdev->aer_completion);
>>  
>>  ret = vfio_add_group_dev(&pdev->dev, &vfio_pci_ops, vdev);
>>  if (ret) {
>> @@ -1176,6 +1195,9 @@ static pci_ers_result_t 
>> vfio_pci_aer_err_detected(struct pci_dev *pdev,
>>  {
>>  struct vfio_pci_device *vdev;
>>  struct vfio_device *device;
>> +u32 uncor_status;
>> +unsigned int aer_cap_offset;
>> +int ret;
>>  
>>  device = vfio_device_get_from_dev(&pdev->dev);
>>  if (device == NULL)
>> @@ -1187,10 +1209,29 @@ static pci_ers_result_t 
>> vfio_pci_aer_err_detected(struct pci_dev *pdev,
>>  return PCI_ERS_RESULT_DISCONNECT;
>>  }
>>  
>> +/*
>> + * get device's uncorrectable error status as soon as possible,
> 
> should be "Get".
> 
>> + * and signal it to user space. The later we read it, the possibility
>> + * the register value is mangled grows.
>> + */
>> +aer_cap_offset = pci_find_ext_capability(vdev->pdev, 
>> PCI_EXT_CAP_ID_ERR);
>> +ret = pci_read_config_dword(vdev->pdev, aer_cap_offset +
>> +PCI_ERR_UNCOR_STATUS, &uncor_status);
>> +if (ret)
>> +return PCI_ERS_RESULT_DISCONNECT;
>> +
>> +pr_info("device %d got AER detect notification. uncorrectable error 
>> status = 0x%x\n", pdev->devfn, uncor_status);//to be removed
> 
> Pls drop this.
> 
>>  mutex_lock(&vdev->igate);
>>  
>> -if (vdev->err_trigger)
>> -eventfd_signal(vdev->err_trigger, 1);
>> +vdev->aer_recovering = true;
>> +reinit_completion(&vdev->aer_completion);
>> +
>> +if (vdev->err_trigger && uncor_status) {
>> +pr_info("device %d signal uncor status 0x%x to user",
>> +pdev->devfn, uncor_status);
>> +/* signal uncorrectable error status to user space */
>> +eventfd_signal(vdev->err_trigger, uncor_status);
>> +}
>>  
>>  mutex_unlock(&vdev->igate);
>>  
>> @@ -1199,8 +1240,33 @@ static pci_ers_result_t 
>> vfio_pci_aer_err_detected(struct pci_dev *pdev,
>>  return PCI_ERS_RESULT_CAN_RECOVER;
>>  }
>>  
>> +static void vfio_pci_aer_resume(struct pci_dev *pdev)
>> +{
>> +struct vfio_pci_device *vdev;
>> +struct vfio_device *device;
>> +
>> +device = vfio_device_get_from_dev(&pdev->dev);
>> +if (device == NULL)
>> +return;
>> +
>> +vdev = vfio_device_data(device);
>> +if (vdev == NULL) {
>> +vfio_device_put(device);
>> +return;
>> +}
>> +
>> +mutex_lock(&vdev->igate);
>> +vdev->aer_recovering = false;
>> +mutex_unlock(&vdev->igate);
>> +
>> +com

Re: [Qemu-devel] [PATCH] vnc: track LED state separately

[Gerd Hoffmann]

On Mo, 2017-01-09 at 17:14 +0100, Pierre Ossman wrote:
> Piggy-backing on the modifier state array made it difficult to send
> out updates at the proper times.
> 
> Signed-off-by: Pierre Ossman 

Added to ui queue.

thanks,
  Gerd

Re: [Qemu-devel] [PATCH 0/2] virtio-gpu: fix issues with VM load code

[Gerd Hoffmann]

On Mo, 2017-01-09 at 13:38 +, Peter Maydell wrote:
> These patches fix a couple of issues with the VM load code
> which I noticed while investigating a coverity warning.
> 
> The first patch fixes a problem with the accounting for
> host pixmap memory usage -- we didn't recalculate the
> current usage following a VM migration, but instead
> started again at zero, which means that if you keep
> bumping the VM from host to host you can sidestep the
> host_maxmem limit.
> 
> The second patch fixes the coverity warning (that if we
> fail in the "creating resources" loop in the load function
> we will leak memory and so on). The leak isn't very
> serious, because if we fail the inbound migration then
> the whole QEMU process is pretty useless for anything,
> but it's easy enough to fix "correctly", ie so that a
> subsequent system reset will put the device back into
> a sane state.
> 
> Peter Maydell (2):
>   virtio-gpu: Recalculate VirtIOGPU::hostmem on VM load
>   virtio-gpu: Fix memory leak in virtio_gpu_load()
> 
>  hw/display/virtio-gpu.c | 17 +
>  1 file changed, 17 insertions(+)
> 
Added to vga queue.

thanks,
  Gerd

Re: [Qemu-devel] [PATCH v2] ui/gtk: Fix mouse wheel on 3.4.0 or later

[Gerd Hoffmann]

On Do, 2017-01-05 at 05:41 +0900, OGAWA Hirofumi wrote:
> On 3.4.0 or later, send GDK_SCROLL_SMOOTH event, instead of
> GDK_SCROLL_UP/DOWN.
> 
> This fixes it by converting any smooth scroll to up/down.
> (I.e. without smooth support)
> 
> Signed-off-by: OGAWA Hirofumi 

Added to ui queue.

thanks,
  Gerd

Re: [Qemu-devel] [PATCH v4 3/4] migration: disallow migrate_add_blocker during migration

[Dr. David Alan Gilbert]

* Ashijeet Acharya (ashijeetacha...@gmail.com) wrote:
> If a migration is already in progress and somebody attempts
> to add a migration blocker, this should rightly fail.
> 
> Add an errp parameter and a retcode return value to migrate_add_blocker.
> 
> Signed-off-by: John Snow 
> Signed-off-by: Ashijeet Acharya 
> ---
>  block/qcow.c  |  6 +-
>  block/vdi.c   |  6 +-
>  block/vhdx.c  | 16 ++--
>  block/vmdk.c  |  7 ++-
>  block/vpc.c   | 10 +++---
>  block/vvfat.c | 20 
>  hw/9pfs/9p.c  | 18 +-
>  hw/display/virtio-gpu.c   | 29 -
>  hw/intc/arm_gic_kvm.c | 16 ++--
>  hw/intc/arm_gicv3_its_kvm.c   | 18 +++---
>  hw/intc/arm_gicv3_kvm.c   | 19 ---
>  hw/misc/ivshmem.c | 11 +++
>  hw/scsi/vhost-scsi.c  | 25 +++--
>  hw/virtio/vhost.c |  8 +++-
>  include/migration/migration.h |  6 +-
>  migration/migration.c | 35 +--
>  stubs/migr-blocker.c  |  3 ++-
>  target-i386/kvm.c | 16 +---
>  18 files changed, 193 insertions(+), 76 deletions(-)
> 
> diff --git a/block/qcow.c b/block/qcow.c
> index 7540f43..11526a1 100644
> --- a/block/qcow.c
> +++ b/block/qcow.c
> @@ -252,7 +252,11 @@ static int qcow_open(BlockDriverState *bs, QDict 
> *options, int flags,
>  error_setg(&s->migration_blocker, "The qcow format used by node '%s' "
> "does not support live migration",
> bdrv_get_device_or_node_name(bs));
> -migrate_add_blocker(s->migration_blocker);
> +ret = migrate_add_blocker(s->migration_blocker, errp);
> +if (ret < 0) {
> +error_free(s->migration_blocker);
> +goto fail;
> +}
>  
>  qemu_co_mutex_init(&s->lock);
>  return 0;
> diff --git a/block/vdi.c b/block/vdi.c
> index 96b78d5..2b56f52 100644
> --- a/block/vdi.c
> +++ b/block/vdi.c
> @@ -471,7 +471,11 @@ static int vdi_open(BlockDriverState *bs, QDict 
> *options, int flags,
>  error_setg(&s->migration_blocker, "The vdi format used by node '%s' "
> "does not support live migration",
> bdrv_get_device_or_node_name(bs));
> -migrate_add_blocker(s->migration_blocker);
> +ret = migrate_add_blocker(s->migration_blocker, errp);
> +if (ret < 0) {
> +error_free(s->migration_blocker);
> +goto fail_free_bmap;
> +}
>  
>  qemu_co_mutex_init(&s->write_lock);
>  
> diff --git a/block/vhdx.c b/block/vhdx.c
> index 0ba2f0a..d81941b 100644
> --- a/block/vhdx.c
> +++ b/block/vhdx.c
> @@ -991,6 +991,16 @@ static int vhdx_open(BlockDriverState *bs, QDict 
> *options, int flags,
>  }
>  }
>  
> +/* Disable migration when VHDX images are used */
> +error_setg(&s->migration_blocker, "The vhdx format used by node '%s' "
> +   "does not support live migration",
> +   bdrv_get_device_or_node_name(bs));
> +ret = migrate_add_blocker(s->migration_blocker, errp);
> +if (ret < 0) {
> +error_free(s->migration_blocker);
> +goto fail;
> +}
> +
>  if (flags & BDRV_O_RDWR) {
>  ret = vhdx_update_headers(bs, s, false, NULL);
>  if (ret < 0) {
> @@ -1000,12 +1010,6 @@ static int vhdx_open(BlockDriverState *bs, QDict 
> *options, int flags,
>  
>  /* TODO: differencing files */
>  
> -/* Disable migration when VHDX images are used */
> -error_setg(&s->migration_blocker, "The vhdx format used by node '%s' "
> -   "does not support live migration",
> -   bdrv_get_device_or_node_name(bs));
> -migrate_add_blocker(s->migration_blocker);
> -
>  return 0;
>  fail:
>  vhdx_close(bs);
> diff --git a/block/vmdk.c b/block/vmdk.c
> index a11c27a..4a45a83 100644
> --- a/block/vmdk.c
> +++ b/block/vmdk.c
> @@ -976,7 +976,12 @@ static int vmdk_open(BlockDriverState *bs, QDict 
> *options, int flags,
>  error_setg(&s->migration_blocker, "The vmdk format used by node '%s' "
> "does not support live migration",
> bdrv_get_device_or_node_name(bs));
> -migrate_add_blocker(s->migration_blocker);
> +ret = migrate_add_blocker(s->migration_blocker, errp);
> +if (ret < 0) {
> +error_free(s->migration_blocker);
> +goto fail;
> +}
> +
>  g_free(buf);
>  return 0;
>  
> diff --git a/block/vpc.c b/block/vpc.c
> index 8d5886f..299a8c8 100644
> --- a/block/vpc.c
> +++ b/block/vpc.c
> @@ -422,13 +422,17 @@ static int vpc_open(BlockDriverState *bs, QDict 
> *options, int flags,
>  #endif
>  }
>  
> -qemu_co_mutex_init(&s->lock);
> -
>  /* Disable migration when VHD images are used */
>  error_setg(&s->migration_blocker, "The vpc format used by node '%s' "
>   

Re: [Qemu-devel] Question about add AF_ALG backend for virtio-crypto

[Daniel P. Berrange]

On Tue, Jan 10, 2017 at 11:36:19AM +, Gonglei (Arei) wrote:
> Hi Daniel,
> 
> >
> > >
> > > >
> > > > On Mon, Jan 09, 2017 at 01:43:10PM +, Stefan Hajnoczi wrote:
> > > > > On Mon, Jan 09, 2017 at 03:04:55PM +0800, Longpeng (Mike) wrote:
> > > > > > I'm one of Gonglei's virtio-crypto project members, and we plan to 
> > > > > > add a
> > > > AF_ALG
> > > > > > backend for virtio-crypto(there's only builtin-backend currently).
> > > > > >
> > > > > > I found that Catalin, Paolo and Stefan had discussed about this in 
> > > > > > 2015
> > > > > > (http://www.spinics.net/lists/kvm/msg115457.html), but it seems that
> > > > Catalin
> > > > > > didn't do it, so I'm confuse about wether it is need to add a AF_ALG
> > > > backend.
> > > > > >
> > > > > > Do you have any suggestion? Thanks :)
> > > > >
> > > > > I have no objections to an AF_ALG backend in QEMU.
> > > >
> > > > Rather than do another backend for virtio-crypto, IMHO, we should have
> > > > an AF_ALG impl of the crypto/ APIs. That way any potential performance
> > > > benefits will enhance our LUKS encryption code too.
> > > >
> > > According to the currently schemas of crypto/ APIs, we can't choose the
> > > specific backend dynamically. This is a limitation for virtio-crypto
> > > device I think.
> > 
> > Do we really need to be able to choose the backend explicitly. If the AF_ALG
> > backend is faster, why would you simply not use that automatically if it is
> > available.
> 
> Can we realize the purpose based on the crypto/ APIs? IIUC the crypto
> subsystem chooses a backend during the building according to the specific 
> priority,
> nettle > gcrypt > cipher-builtin.
> 
> If we add an AF_ALG implementation for crypto subsystem, shall we set it
> as the highest priority? If so, other backends won't be used since AF_ALG
> is always available. If not, how can we use AF_ALG backend for crypto/ API?
> 
> Please correct me if I'm missing something.

While AF_ALG has been available for a while, not all features have. For
example AEAD support was only added in kernel 4.1

So if we had AF_ALG in QEMU, we would have to have a stacked impl, where
we try AF_ALG and then fallback to the current code when QEMU runs on a
kernel lacking the feature needed.

We could potentially also have a global arg to switch backends e.g.

 -crypto-backend [afalg|builtin]


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

Re: [Qemu-devel] [PATCH v6 0/4] Add HAX support

[Paolo Bonzini]

> it failed on the dependency to the unsubmitted Paolo's ramblock-notifier
> patch.

No big deal, I'll include that.

Paolo

Re: [Qemu-devel] [PATCH v7 08/21] qapi: move experimental note down

[Markus Armbruster]

Marc-André Lureau  writes:

> Use a better 'Note:' section, move it below parameters following
> guidelines.
>
> Signed-off-by: Marc-André Lureau 

Again, I don't mind moving stuff around if it helps getting this series
wrapped, and doesn't make things less readable.  My only nit is the
commit message's claim about the guidelines.  Let's sidestep it:

Move these notes down and prefix with "Note:", to please the doc
generator we're going to add.

Okay?

Re: [Qemu-devel] [PATCH v6 0/4] Add HAX support

[Paolo Bonzini]

On 10/01/2017 11:59, Vincent Palatin wrote:
> I took a stab at trying to rebase/upstream the support for Intel HAXM.
> (Hardware Accelerated Execution Manager).
> Intel HAX is kernel-based hardware acceleration module for Windows and MacOSX.
> 
> Another copy of this patchset is available at:
> I have made another public copy there:
> git://github.com/vpalatin/qemu.git tags/hax-v6-pull-request
> 
> https://github.com/vpalatin/qemu/tree/hax-v6-pull-request
> 
> I have based my work on the last version of the source code I found:
> the emu-2.2-release branch in the external/qemu-android repository as used by
> the Android emulator.
> In patch 2/4, I have forward-ported the core HAX code from there.
> It has been modified to build and run along with the current code base.
> It has been simplifying by removing non-UG hardware support / Darwin support /
> Android-specific leftovers.
> 
> This code depends on the new unmapping mechanism and fixes in Intel HAX kernel
> module. They will publish soon a new version 6.1.0 of the HAX kernel module
> including the fixes once their QA cycle is completed.
> Thanks Yu Ning for making this happen.

Queued for 2.9, thanks!  Please keep an eye on the release notes at
http://wiki.qemu-project.org/ChangeLog/2.9 (nothing there yet).

Paolo

> In patch 3/4, I have put the plumbing into the QEMU code base, I did some 
> clean
> up there and it is reasonably intrusive: i.e.
>  Makefile.target   |  1 +
>  configure | 18 
>  cpus.c| 74 
> ++-
>  hw/intc/apic_common.c |  3 +-
>  include/qom/cpu.h |  5 
>  include/sysemu/hw_accel.h |  9 ++
>  qemu-options.hx   | 11 +++
>  target/i386/Makefile.objs |  4 +++
>  util/qemu-thread-win32.c  |  4 +--
>  vl.c  | 15 --
>  10 files changed, 137 insertions(+), 7 deletions(-)
> 
> The patch 1/4 just extracts from KVM specific header the cpu_synchronize_
> functions that HAX is also using.
> 
> The patch 4/4 is the Darwin support. This part is only lightly tested for now,
> so it can be considered as 'experimental'.
> 
> I have tested the end result on a Windows 10 Pro machine (with UG support)
> with the Intel HAXM module dev version and a large ChromiumOS x86_64 image to
> exercise various code paths. It looks stable.
> I also did a quick regression testing of the integration by running a Linux
> build with KVM enabled.
> 
> Changes from v5 to v6:
> - rebase against new upstream target directories changes
> - rebase on top of Paolo's ramblock-notifier patch and use the new API.
> - adjust qemu_cpu_kick according to Paolo's suggestions / use QueueUserApc.
> 
> Changes from v4 to v5:
> - update HAX fastmmio API with the new MMIO to MMIO transfer.
> 
> Changes from v3 to v4:
> - add RAM unmapping in the MemoryListener thanks to new API in HAX module 
> 6.1.0
>   and re-wrote the memory mappings management to deal with this.
> - marked no longer used MMIO emulation as unsupported.
> - clean-up a few left-overs from removed code.
> - re-add an experimental version of the Darwin support.
> 
> Changes from v2 to v3:
> - fix saving/restoring FPU registers as suggested by Paolo.
> - fix Windows build on all targets as contributed by Stefan Weil.
> - clean-up IO / MMIO emulation.
> - more clean-up of emulation leftovers.
> 
> Changes from v1 to v2:
> - fix all style issues in the original code to get it through checkpatch.pl.
> - remove Darwin support, it was barely tested and not fully functional.
> - remove the support for CPU without UG mode.
> - fix most review comments
> 
> Vincent Palatin (4):
>   kvm: move cpu synchronization code
>   target/i386: Add Intel HAX files
>   Plumb the HAXM-based hardware acceleration support
>   hax: add Darwin support
> 
>  Makefile.target |1 +
>  configure   |   18 +
>  cpus.c  |   79 ++-
>  gdbstub.c   |1 +
>  hax-stub.c  |   39 ++
>  hw/i386/kvm/apic.c  |1 +
>  hw/i386/kvmvapic.c  |1 +
>  hw/intc/apic_common.c   |3 +-
>  hw/misc/vmport.c|2 +-
>  hw/ppc/pnv_xscom.c  |2 +-
>  hw/ppc/ppce500_spin.c   |4 +-
>  hw/ppc/spapr.c  |2 +-
>  hw/ppc/spapr_hcall.c|2 +-
>  hw/s390x/s390-pci-inst.c|1 +
>  include/qom/cpu.h   |5 +
>  include/sysemu/hax.h|   56 +++
>  include/sysemu/hw_accel.h   |   48 ++
>  include/sysemu/kvm.h|   23 -
>  monitor.c   |2 +-
>  qemu-options.hx |   11 +
>  qom/cpu.c   |2 +-
>  target/arm/cpu.c|2 +-
>  target/i386/Makefile.objs   |7 +
>  target/i386/hax-all.c   | 1155 
> +++
>  target/i386/hax-darwin.c|  316 
>  target/i386/hax-darwin.h|   63 +++
>  target/i386/hax-i386.h  |   94 
>  ta

Re: [Qemu-devel] [PATCH v4 4/4] migration: Fail migration blocker for --only-migratble

[Dr. David Alan Gilbert]

* Ashijeet Acharya (ashijeetacha...@gmail.com) wrote:
> migrate_add_blocker should rightly fail if the '--only-migratable'
> option was specified and the device in use should not be able to
> perform the action which results in an unmigratable VM.
> 
> Make migrate_add_blocker return -EACCES in this case.
> 
> Signed-off-by: Ashijeet Acharya 
> ---
>  block/qcow.c|  5 -
>  block/vdi.c |  5 -
>  block/vhdx.c|  6 --
>  block/vmdk.c|  5 -
>  block/vpc.c |  5 -
>  block/vvfat.c   |  6 --
>  hw/display/virtio-gpu.c |  9 +++--
>  hw/intc/arm_gic_kvm.c   |  7 +--
>  hw/intc/arm_gicv3_its_kvm.c |  5 -
>  hw/intc/arm_gicv3_kvm.c |  5 -
>  hw/misc/ivshmem.c   | 10 --
>  hw/scsi/vhost-scsi.c|  8 +---
>  hw/virtio/vhost.c   |  6 --
>  migration/migration.c   |  7 +++
>  target-i386/kvm.c   |  5 -
>  15 files changed, 72 insertions(+), 22 deletions(-)
> 
> diff --git a/block/qcow.c b/block/qcow.c
> index 11526a1..bdc6446 100644
> --- a/block/qcow.c
> +++ b/block/qcow.c
> @@ -254,7 +254,10 @@ static int qcow_open(BlockDriverState *bs, QDict 
> *options, int flags,
> bdrv_get_device_or_node_name(bs));
>  ret = migrate_add_blocker(s->migration_blocker, errp);
>  if (ret < 0) {
> -error_free(s->migration_blocker);
> +if (ret == -EACCES) {
> +error_append_hint(errp, "Cannot use a node with qcow format as "
> +  "it does not support live migration");
> +}
>  goto fail;
>  }
>  
> diff --git a/block/vdi.c b/block/vdi.c
> index 2b56f52..0b011ea 100644
> --- a/block/vdi.c
> +++ b/block/vdi.c
> @@ -473,7 +473,10 @@ static int vdi_open(BlockDriverState *bs, QDict 
> *options, int flags,
> bdrv_get_device_or_node_name(bs));
>  ret = migrate_add_blocker(s->migration_blocker, errp);
>  if (ret < 0) {
> -error_free(s->migration_blocker);
> +if (ret == -EACCES) {
> +error_append_hint(errp, "Cannot use a node with vdi format as "
> +  "it does not support live migration");
> +}
>  goto fail_free_bmap;
>  }
>  
> diff --git a/block/vhdx.c b/block/vhdx.c
> index d81941b..b8d53ec 100644
> --- a/block/vhdx.c
> +++ b/block/vhdx.c
> @@ -997,10 +997,12 @@ static int vhdx_open(BlockDriverState *bs, QDict 
> *options, int flags,
> bdrv_get_device_or_node_name(bs));
>  ret = migrate_add_blocker(s->migration_blocker, errp);
>  if (ret < 0) {
> -error_free(s->migration_blocker);
> +if (ret == -EACCES) {
> +error_append_hint(errp, "Cannot use a node with vhdx format as "
> +  "it does not support live migration");
> +}
>  goto fail;
>  }
> -
>  if (flags & BDRV_O_RDWR) {
>  ret = vhdx_update_headers(bs, s, false, NULL);
>  if (ret < 0) {
> diff --git a/block/vmdk.c b/block/vmdk.c
> index 4a45a83..defe400 100644
> --- a/block/vmdk.c
> +++ b/block/vmdk.c
> @@ -978,7 +978,10 @@ static int vmdk_open(BlockDriverState *bs, QDict 
> *options, int flags,
> bdrv_get_device_or_node_name(bs));
>  ret = migrate_add_blocker(s->migration_blocker, errp);
>  if (ret < 0) {
> -error_free(s->migration_blocker);
> +if (ret == -EACCES) {
> +error_append_hint(errp, "Cannot use a node with vmdk format as "
> +  "it does not support live migration");
> +}
>  goto fail;
>  }
>  
> diff --git a/block/vpc.c b/block/vpc.c
> index 299a8c8..5e58d77 100644
> --- a/block/vpc.c
> +++ b/block/vpc.c
> @@ -428,7 +428,10 @@ static int vpc_open(BlockDriverState *bs, QDict 
> *options, int flags,
> bdrv_get_device_or_node_name(bs));
>  ret = migrate_add_blocker(s->migration_blocker, errp);
>  if (ret < 0) {
> -error_free(s->migration_blocker);
> +if (ret == -EACCES) {
> +error_append_hint(errp, "Cannot use a node with vpc format as "
> +  "it does not support live migration");
> +}
>  goto fail;
>  }
>  
> diff --git a/block/vvfat.c b/block/vvfat.c
> index 3de3320..5a6e038 100644
> --- a/block/vvfat.c
> +++ b/block/vvfat.c
> @@ -1193,7 +1193,10 @@ static int vvfat_open(BlockDriverState *bs, QDict 
> *options, int flags,
> bdrv_get_device_or_node_name(bs));
>  ret = migrate_add_blocker(s->migration_blocker, errp);
>  if (ret < 0) {
> -error_free(s->migration_blocker);
> +if (ret == -EACCES) {
> +error_append_hint(errp, "Cannot use a node with vvfat format 
> "
> +  "as it does not support live migration");
> +}
>  goto fail;
>  }
>  }

Re: [Qemu-devel] Question about add AF_ALG backend for virtio-crypto

[Gonglei (Arei)]

>
> > >
> > > >
> > > > >
> > > > > On Mon, Jan 09, 2017 at 01:43:10PM +, Stefan Hajnoczi wrote:
> > > > > > On Mon, Jan 09, 2017 at 03:04:55PM +0800, Longpeng (Mike) wrote:
> > > > > > > I'm one of Gonglei's virtio-crypto project members, and we plan to
> add a
> > > > > AF_ALG
> > > > > > > backend for virtio-crypto(there's only builtin-backend currently).
> > > > > > >
> > > > > > > I found that Catalin, Paolo and Stefan had discussed about this in
> 2015
> > > > > > > (http://www.spinics.net/lists/kvm/msg115457.html), but it seems
> that
> > > > > Catalin
> > > > > > > didn't do it, so I'm confuse about wether it is need to add a 
> > > > > > > AF_ALG
> > > > > backend.
> > > > > > >
> > > > > > > Do you have any suggestion? Thanks :)
> > > > > >
> > > > > > I have no objections to an AF_ALG backend in QEMU.
> > > > >
> > > > > Rather than do another backend for virtio-crypto, IMHO, we should have
> > > > > an AF_ALG impl of the crypto/ APIs. That way any potential performance
> > > > > benefits will enhance our LUKS encryption code too.
> > > > >
> > > > According to the currently schemas of crypto/ APIs, we can't choose the
> > > > specific backend dynamically. This is a limitation for virtio-crypto
> > > > device I think.
> > >
> > > Do we really need to be able to choose the backend explicitly. If the 
> > > AF_ALG
> > > backend is faster, why would you simply not use that automatically if it 
> > > is
> > > available.
> >
> > Can we realize the purpose based on the crypto/ APIs? IIUC the crypto
> > subsystem chooses a backend during the building according to the specific
> priority,
> > nettle > gcrypt > cipher-builtin.
> >
> > If we add an AF_ALG implementation for crypto subsystem, shall we set it
> > as the highest priority? If so, other backends won't be used since AF_ALG
> > is always available. If not, how can we use AF_ALG backend for crypto/ API?
> >
> > Please correct me if I'm missing something.
> 
> While AF_ALG has been available for a while, not all features have. For
> example AEAD support was only added in kernel 4.1
> 
OK.

> So if we had AF_ALG in QEMU, we would have to have a stacked impl, where
> we try AF_ALG and then fallback to the current code when QEMU runs on a
> kernel lacking the feature needed.
> 
It makes sense though the implementation will be more complicate
since the code should identify the different error codes are returned
by AF_ALG APIs.

> We could potentially also have a global arg to switch backends e.g.
> 
>  -crypto-backend [afalg|builtin]
> 
So the backend here is not the cryptodev backend?

Thanks,
-Gonglei

Re: [Qemu-devel] [PATCH v7 12/21] qapi.py: fix line break before binary operator pep8

[Markus Armbruster]

Marc-André Lureau  writes:

> Python code style accepts both form, but pep8 complains. Better to clean
> up the single warning for now, so new errors stand out more easily.
>
> Fix scripts/qapi.py:1539:21: W503 line break before binary operator

PEP 8 permits both, but prefers line break before binary operator.
Thus, this warning is clearly bogus.  What version of pep8 do you use?
Mine doesn't warn.

Re: [Qemu-devel] [PATCH v8 1/1] crypto: add virtio-crypto driver

[Christian Borntraeger]

On 12/15/2016 03:03 AM, Gonglei wrote:
[...]
> +
> +static struct crypto_alg virtio_crypto_algs[] = { {
> + .cra_name = "cbc(aes)",
> + .cra_driver_name = "virtio_crypto_aes_cbc",
> + .cra_priority = 501,


This is still higher than the hardware-accelerators (like intel aesni or the
s390 cpacf functions or the arm hw). aesni and s390/cpacf are supported by the
hardware virtualization and available to the guests. I do not see a way how 
virtio
crypto can be faster than that (in the end it might be cpacf/aesni + overhead)
instead it will very likely be slower.
So we should use a number that is higher than software implementations but
lower than the hw ones.

Just grepping around, the software ones seem be be around 100 and the hardware 
ones around 200-400. So why was 150 not enough?

Christian

Re: [Qemu-devel] [PATCH for-2.9 00/10] pc: acpi: memory hotplug cleanup/consolidation

[Igor Mammedov]

On Tue, 10 Jan 2017 07:08:57 +0200
"Michael S. Tsirkin"  wrote:

> On Mon, Jan 09, 2017 at 03:22:01PM +0100, Igor Mammedov wrote:
> > On Tue,  6 Dec 2016 00:32:19 +0100
> > Igor Mammedov  wrote:
> >   
> > > Series cleanups and consolidates scattered memory hotplug
> > > code so it could be easily reused by ARM target later.
> > > 
> > > As result:
> > >  * added memory hotplug variant to bios tables test
> > >  * all ACPI related parts of memory hotplug are consolidated
> > >within memory_hotplug.c
> > >  * DSDT table size is reduced ~900 bytes when memory hotplug
> > >is not enabled (by not generating not used AML)
> > >  * DSDT table size is reduced on 12 bytes per slot
> > >(i.e. up to ~3000 bytes savings for 256 DIMMs) with memory hotplug
> > >enabled due AML reorganization that makes calls to common functions
> > >smaller as devices and common functions are now within the same scope.
> > > 
> > > Tested with following guests:
> > >   - RHEL7.3, WS2008DC, WS2008R2DC, WS2012R2DC, WS2016TP5 - no regressions 
> > > found
> > >   - XP3 and WS2003 - boots fine even if memhotplug is enabled (but 
> > > otherwise
> > > it never worked as memhp is not supported there)  
> > 
> > Michael,
> > 
> > Marcel's already reviewed this series a while ago could you
> > pull it in your tree if there aren't any questions?  
> 
> I merged this and updated expected files accordingly.
> 
> Could you please check expected files in my tree
> to make sure it looks good?
Merge looks good to me.
I've gave your pci branch a quick memhp testing,
hot-add/remove works as expected with RHEL7/WS2012r2.

Thanks!

> 
> Thanks!
> 
> >   
> > > Git tree for testing:
> > >   https://github.com/imammedo/qemu.git memhp_consolidate_v1
> > > viewing:
> > >   https://github.com/imammedo/qemu/commits/memhp_consolidate_v1
> > > 
> > > Note to maintaner:
> > >   * blobs patch 2/10 should be merged to patch 1/10
> > >   * ACPI tables should be regenarated and applied after series is merged
> > > as DSDT will cange for all tests cases due removal of inactive
> > > memory hotplug code.
> > > 
> > > CC: "Michael S. Tsirkin" 
> > > CC: Eduardo Habkost 
> > > CC: Marcel Apfelbaum 
> > > 
> > > 
> > > Igor Mammedov (10):
> > >   tests: pc: add memory hotplug acpi tables tests
> > >   tests: pc: acpi: add SRAT and DSDT blobs for memory hotplug variant
> > >   memhp: move build_memory_hotplug_aml() into memory_hotplug.c
> > >   memhp: move build_memory_devices() into memory_hotplug.c
> > >   memhp: consolidate scattered MHPD device declaration
> > >   memhp: merge build_memory_devices() into build_memory_hotplug_aml()
> > >   memhp: move GPE handler_E03 into build_memory_hotplug_aml()
> > >   memhp: move memory hotplug only defines to memory_hotplug.c
> > >   memhp: don't generate memory hotplug AML if it's not enabled/supported
> > >   memhp: move DIMM devices into dedicated scope with related common
> > > methods
> > > 
> > >  include/hw/acpi/memory_hotplug.h|  12 +-
> > >  include/hw/acpi/pc-hotplug.h|  23 --
> > >  hw/acpi/Makefile.objs   |   2 +-
> > >  hw/acpi/ich9.c  |   3 +-
> > >  hw/acpi/memory_hotplug.c| 420 
> > > +++-
> > >  hw/acpi/memory_hotplug_acpi_table.c | 262 --
> > >  hw/acpi/piix4.c |   3 +-
> > >  hw/i386/acpi-build.c| 197 +++--
> > >  tests/acpi-test-data/pc/DSDT.memhp  | Bin 0 -> 6613 bytes
> > >  tests/acpi-test-data/pc/SRAT.memhp  | Bin 0 -> 224 bytes
> > >  tests/acpi-test-data/q35/DSDT.memhp | Bin 0 -> 9375 bytes
> > >  tests/acpi-test-data/q35/SRAT.memhp | Bin 0 -> 224 bytes
> > >  tests/bios-tables-test.c|  24 +++
> > >  13 files changed, 479 insertions(+), 467 deletions(-)
> > >  delete mode 100644 hw/acpi/memory_hotplug_acpi_table.c
> > >  create mode 100644 tests/acpi-test-data/pc/DSDT.memhp
> > >  create mode 100644 tests/acpi-test-data/pc/SRAT.memhp
> > >  create mode 100644 tests/acpi-test-data/q35/DSDT.memhp
> > >  create mode 100644 tests/acpi-test-data/q35/SRAT.memhp
> > >   
> 

Re: [Qemu-devel] [PATCH v2] ui: fix format specfier in vnc to avoid break in build.

[Gerd Hoffmann]

On Di, 2017-01-10 at 11:19 +0200, Rami Rosen wrote:
> When building qemu after setting _VNC_DEBUG to 1 (see ui/vnc.h),
> we get the following error and the build breaks:
> ...
> ui/vnc.c: In function ‘vnc_client_io_error’:
> ui/vnc.c:1262:13: error: format ‘%d’ expects argument of type ‘int’,
> but
>  VNC_DEBUG("Closing down client sock: ret %d (%s)\n",
>  ^
> cc1: all warnings being treated as errors
> make: *** [ui/vnc.o] Error 1

added to ui patch queue.

thanks,
  Gerd

[Qemu-devel] [Bug 601946] Re: [Feature request] qemu-img multi-threaded compressed image conversion

[Quentin Casasnovas]

It looks like qcow2_write_compressed() has been removed and turned into
a qemu co-routine in qemu 2.8.0 (released in December 2017) to support
live compressed back-ups.  Any pointers to start working on this?  We
have servers with 128 CPUs and it's very sad to see them compress on a
single CPU and take tens of minutes instead of a few seconds.. :)

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

Title:
  [Feature request] qemu-img multi-threaded compressed image conversion

Status in QEMU:
  New

Bug description:
  Feature request:
  qemu-img multi-threaded compressed image conversion

  Suppose I want to convert raw image to compressed qcow2. Multi-
  threaded conversion will be much faster, because bottleneck is
  compressing data.

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

[Qemu-devel] [RFC PATCH v3 1/1] virtio crypto device specification: asymmetric crypto service

[Xin Zeng]

This patch introduces asymmetric crypto service into virtio crypto
device spec. The asymmetric crypto service can be referred as signature,
verification, encryption, decryption, key generation and key exchange.
This patch depends on virtio crypto device spec patch:
http://lists.gnu.org/archive/html/qemu-devel/2017-01/msg00291.html

Please help to review, thanks!

Changes since v2:
- Update some sections according to the update of virtio crypto device
spec v15.
- Fix minor spelling mistakes
- Remove trail spaces in the spec

Changes since v1:
- Remove virtio_crypto_buf  to be consistent with other  virtio devices'
buf representation. [Lei]
- Use "MUST" instead of "SHOULD" in some places. [Lei]

Changes since v0:
- Use devicenormative/drivernormative instead of self-defined
  device/driver label.  [Lei]
- Change the error code of verification to general virtio_crypto
  error code. [Lei]
- Use macro instead of enum in verification result. [Lei]
- Fix the incorrect label value for paragraph and section. [Lei]

Signed-off-by: Xin Zeng 
---
 virtio-crypto.tex | 1109 -
 1 file changed, 1107 insertions(+), 2 deletions(-)

diff --git a/virtio-crypto.tex b/virtio-crypto.tex
index 44819f9..d3236df 100644
--- a/virtio-crypto.tex
+++ b/virtio-crypto.tex
@@ -6,7 +6,7 @@ decryption requests are placed in any of teh data active queues 
and are ultimate
 backend crypto accelerators. The second kind of queue is the control queue 
used to create 
 or destroy sessions for symmetric algorithms and will control some advanced
 features in the future. The virtio crypto device provides the following crypto
-services: CIPHER, MAC, HASH, and AEAD.
+services: CIPHER, MAC, HASH, AEAD and ASYM.
 
 
 \subsection{Device ID}\label{sec:Device Types / Crypto Device / Device ID}
@@ -47,6 +47,9 @@ struct virtio_crypto_config {
 le32 mac_algo_l;
 le32 mac_algo_h;
 le32 aead_algo;
+le32 asym_algo;
+/*Rsa padding capabilities*/
+le32 rsa_padding;
 /* Maximum length of cipher key */
 le32 max_cipher_key_len;
 /* Maximum length of authenticated key */
@@ -80,6 +83,8 @@ The following services are defined:
 #define VIRTIO_CRYPTO_SERVICE_MAC2
 /* AEAD (Authenticated Encryption with Associated Data) service */
 #define VIRTIO_CRYPTO_SERVICE_AEAD   3
+/* ASYM (Asymmetric crypto algorithms) service */
+#define VIRTIO_CRYPTO_SERVICE_ASYM   4
 \end{lstlisting}
 
 The last driver-read-only fields specify detailed algorithms masks 
@@ -153,6 +158,28 @@ The following AEAD algorithms are defined:
 #define VIRTIO_CRYPTO_AEAD_CHACHA20_POLY1305  3
 \end{lstlisting}
 
+The following asymmetric algorithms are defined:
+
+\begin{lstlisting}
+#define VIRTIO_CRYPTO_ASYM_NONE   0
+#define VIRTIO_CRYPTO_ASYM_RSA1
+#define VIRTIO_CRYPTO_ASYM_DSA2
+#define VIRTIO_CRYPTO_ASYM_DH 3
+#define VIRTIO_CRYPTO_ASYM_ECDSA  4
+#define VIRTIO_CRYPTO_ASYM_ECDH   5
+\end{lstlisting}
+
+The following rsa padding capabilities are defined:
+
+\begin{lstlisting}
+#define VIRTIO_CRYPTO_RSA_NO_PADDING  0
+#define VIRTIO_CRYPTO_RSA_PKCS1_PADDING   1
+#define VIRTIO_CRYPTO_RSA_SSLV23_PADDING  2
+#define VIRTIO_CRYPTO_RSA_PKCS1_OAEP_PADDING  3
+#define VIRTIO_CRYPTO_RSA_X931_PADDING4
+#define VIRTIO_CRYPTO_RSA_PKCS1_PSS_PADDING   5
+\end{lstlisting}
+
 \begin{note}
 Any other value is reserved for future use.
 \end{note}
@@ -168,6 +195,7 @@ Any other value is reserved for future use.
 \item The device MUST set \field{max_size} to show the maximum size of crypto 
request the device supports.
 \item The device MUST set \field{max_cipher_key_len} to show the maximum 
length of cipher key if the device supports CIPHER service.
 \item The device MUST set \field{max_auth_key_len} to show the maximum length 
of authenticated key if the device supports MAC service.
+\item The device MUST set \field{rsa_padding} to show the padding capabilities 
offered by the device.
 \end{itemize*}
 
 \drivernormative{\subsubsection}{Device configuration layout}{Device Types / 
Crypto Device / Device configuration layout}
@@ -182,6 +210,7 @@ Any other value is reserved for future use.
 \item The driver SHOULD read \field{max_size} to discover the maximum size of 
crypto request the device supports.
 \item The driver SHOULD read \field{max_cipher_key_len} to discover the 
maximum length of cipher key the device supports.
 \item The driver SHOULD read \field{max_auth_key_len} to discover the maximum 
length of authenticated key the device supports.
+\item The driver MAY read \field{rsa_padding} to discover the padding 
capabilities offered by the device.
 \end{itemize*}
 
 \subsection{Device Initialization}\label{sec:Device Types / Crypto Device / 
Device Initialization}
@@ -264,6 +293,18 @@ struct virtio_crypto_op_header {
 VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AEAD, 0x00)
 #define VIRTIO_CRYPTO_AEAD_DECRYPT \
 VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AEAD, 0x01)
+#define VIRT

Re: [Qemu-devel] [PATCH v8 1/1] crypto: add virtio-crypto driver

[Gonglei (Arei)]

Hi,

> 
> On 12/15/2016 03:03 AM, Gonglei wrote:
> [...]
> > +
> > +static struct crypto_alg virtio_crypto_algs[] = { {
> > +   .cra_name = "cbc(aes)",
> > +   .cra_driver_name = "virtio_crypto_aes_cbc",
> > +   .cra_priority = 501,
> 
> 
> This is still higher than the hardware-accelerators (like intel aesni or the
> s390 cpacf functions or the arm hw). aesni and s390/cpacf are supported by the
> hardware virtualization and available to the guests. I do not see a way how
> virtio
> crypto can be faster than that (in the end it might be cpacf/aesni + overhead)
> instead it will very likely be slower.
> So we should use a number that is higher than software implementations but
> lower than the hw ones.
> 
> Just grepping around, the software ones seem be be around 100 and the
> hardware
> ones around 200-400. So why was 150 not enough?
> 
I didn't find a documentation about how we use the priority, and I assumed
people use virtio-crypto will configure hardware accelerators in the
host. So I choosed the number which bigger than aesni's priority.

Regards,
-Gonglei

[Qemu-devel] [PATCH] hw/net: implement MIB counters in mcf_fec driver

[Greg Ungerer]

The FEC ethernet hardware module used on ColdFire SoC parts contains a
block of RAM used to maintain hardware counters. This block is accessible
via the usual FEC register address space. There is currently no support
for this in the QEMU mcf_fec driver.

Add support for storing a MIB RAM block, and provide register level
access to it. Also implement a basic set of stats collection functions
to populate MIB data fields.

This support tested running a Linux target and using the net-tools
"ethtool -S" option. As of linux-4.9 the kernels FEC driver makes
accesses to the MIB counters during its initialization (which it never
did before), and so this version of Linux will now fail with the QEMU
error:

qemu: hardware error: mcf_fec_read: Bad address 0x200

This MIB counter support fixes this problem.

Singed-off-by: Greg Ungerer 
---
 hw/net/mcf_fec.c | 113 +++
 1 file changed, 113 insertions(+)

diff --git a/hw/net/mcf_fec.c b/hw/net/mcf_fec.c
index 4025eb3..7a9e4f1 100644
--- a/hw/net/mcf_fec.c
+++ b/hw/net/mcf_fec.c
@@ -25,6 +25,7 @@ do { printf("mcf_fec: " fmt , ## __VA_ARGS__); } while (0)
 
 #define FEC_MAX_DESC 1024
 #define FEC_MAX_FRAME_SIZE 2032
+#define FEC_MIB_SIZE 64
 
 typedef struct {
 MemoryRegion *sysmem;
@@ -48,6 +49,7 @@ typedef struct {
 uint32_t erdsr;
 uint32_t etdsr;
 uint32_t emrbr;
+uint32_t mib[FEC_MIB_SIZE];
 } mcf_fec_state;
 
 #define FEC_INT_HB   0x8000
@@ -109,6 +111,63 @@ typedef struct {
 #define FEC_BD_OV   0x0002
 #define FEC_BD_TR   0x0001
 
+#define MIB_RMON_T_DROP 0
+#define MIB_RMON_T_PACKETS  1
+#define MIB_RMON_T_BC_PKT   2
+#define MIB_RMON_T_MC_PKT   3
+#define MIB_RMON_T_CRC_ALIGN4
+#define MIB_RMON_T_UNDERSIZE5
+#define MIB_RMON_T_OVERSIZE 6
+#define MIB_RMON_T_FRAG 7
+#define MIB_RMON_T_JAB  8
+#define MIB_RMON_T_COL  9
+#define MIB_RMON_T_P64  10
+#define MIB_RMON_T_P65TO127 11
+#define MIB_RMON_T_P128TO25512
+#define MIB_RMON_T_P256TO51113
+#define MIB_RMON_T_P512TO1023   14
+#define MIB_RMON_T_P1024TO2047  15
+#define MIB_RMON_T_P_GTE204816
+#define MIB_RMON_T_OCTETS   17
+#define MIB_IEEE_T_DROP 18
+#define MIB_IEEE_T_FRAME_OK 19
+#define MIB_IEEE_T_1COL 20
+#define MIB_IEEE_T_MCOL 21
+#define MIB_IEEE_T_DEF  22
+#define MIB_IEEE_T_LCOL 23
+#define MIB_IEEE_T_EXCOL24
+#define MIB_IEEE_T_MACERR   25
+#define MIB_IEEE_T_CSERR26
+#define MIB_IEEE_T_SQE  27
+#define MIB_IEEE_T_FDXFC28
+#define MIB_IEEE_T_OCTETS_OK29
+
+#define MIB_RMON_R_DROP 32
+#define MIB_RMON_R_PACKETS  33
+#define MIB_RMON_R_BC_PKT   34
+#define MIB_RMON_R_MC_PKT   35
+#define MIB_RMON_R_CRC_ALIGN36
+#define MIB_RMON_R_UNDERSIZE37
+#define MIB_RMON_R_OVERSIZE 38
+#define MIB_RMON_R_FRAG 39
+#define MIB_RMON_R_JAB  40
+#define MIB_RMON_R_RESVD_0  41
+#define MIB_RMON_R_P64  42
+#define MIB_RMON_R_P65TO127 43
+#define MIB_RMON_R_P128TO25544
+#define MIB_RMON_R_P256TO51145
+#define MIB_RMON_R_P512TO1023   46
+#define MIB_RMON_R_P1024TO2047  47
+#define MIB_RMON_R_P_GTE204848
+#define MIB_RMON_R_OCTETS   49
+#define MIB_IEEE_R_DROP 50
+#define MIB_IEEE_R_FRAME_OK 51
+#define MIB_IEEE_R_CRC  52
+#define MIB_IEEE_R_ALIGN53
+#define MIB_IEEE_R_MACERR   54
+#define MIB_IEEE_R_FDXFC55
+#define MIB_IEEE_R_OCTETS_OK56
+
 static void mcf_fec_read_bd(mcf_fec_bd *bd, uint32_t addr)
 {
 cpu_physical_memory_read(addr, bd, sizeof(*bd));
@@ -145,6 +204,30 @@ static void mcf_fec_update(mcf_fec_state *s)
 s->irq_state = active;
 }
 
+static void mcf_fec_tx_stats(mcf_fec_state *s, int size)
+{
+s->mib[MIB_RMON_T_PACKETS]++;
+s->mib[MIB_RMON_T_OCTETS] += size;
+if (size < 64)
+s->mib[MIB_RMON_T_FRAG]++;
+else if (size == 64)
+s->mib[MIB_RMON_T_P64]++;
+else if (size < 128)
+s->mib[MIB_RMON_T_P65TO127]++;
+else if (size < 256)
+s->mib[MIB_RMON_T_P128TO255]++;
+else if (size < 512)
+s->mib[MIB_RMON_T_P256TO511]++;
+else if (size < 1024)
+s->mib[MIB_RMON_T_P512TO1023]++;
+else if (size < 2048)
+s->mib[MIB_RMON_T_P1024TO2047]++;
+else
+s->mib[MIB_RMON_T_P_GTE2048]++;
+s->mib[MIB_IEEE_T_FRAME_OK]++;
+s->mib[MIB_IEEE_T_OCTETS_OK] += size;
+}
+
 static void mcf_fec_do_tx(mcf_fec_state *s)
 {
 uint32_t addr;
@@ -178,6 +261,7 @@ static void mcf_fec_do_tx(mcf_fec_state *s)
 /* Last buffer in frame.  */
 DPRINTF("Sending packet\n");
 qemu_send_packet(qemu_get_queue(s->nic), frame, frame_size);
+mcf_fec_tx_stats(s, frame_size);
 ptr = frame;
 frame_size = 0;
 s->eir |= FEC_INT_TXF;
@@ -298,6 +382,7 @@ static uint64_t mcf_fec_read(void *opaque, hwaddr addr,
   

Re: [Qemu-devel] [PATCH] hw/net: implement MIB counters in mcf_fec driver

[no-reply]

Hi,

Your series seems to have some coding style problems. See output below for
more information:

Type: series
Message-id: 1484052273-23815-1-git-send-email-g...@uclinux.org
Subject: [Qemu-devel] [PATCH] hw/net: implement MIB counters in mcf_fec driver

=== TEST SCRIPT BEGIN ===
#!/bin/bash

BASE=base
n=1
total=$(git log --oneline $BASE.. | wc -l)
failed=0

# Useful git options
git config --local diff.renamelimit 0
git config --local diff.renames True

commits="$(git log --format=%H --reverse $BASE..)"
for c in $commits; do
echo "Checking PATCH $n/$total: $(git log -n 1 --format=%s $c)..."
if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; then
failed=1
echo
fi
n=$((n+1))
done

exit $failed
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 * [new tag] patchew/1484052273-23815-1-git-send-email-g...@uclinux.org 
-> patchew/1484052273-23815-1-git-send-email-g...@uclinux.org
Switched to a new branch 'test'
8b594c1 hw/net: implement MIB counters in mcf_fec driver

=== OUTPUT BEGIN ===
Checking PATCH 1/1: hw/net: implement MIB counters in mcf_fec driver...
ERROR: braces {} are necessary for all arms of this statement
#120: FILE: hw/net/mcf_fec.c:211:
+if (size < 64)
[...]
+else if (size == 64)
[...]
+else if (size < 128)
[...]
+else if (size < 256)
[...]
+else if (size < 512)
[...]
+else if (size < 1024)
[...]
+else if (size < 2048)
[...]
+else
[...]

ERROR: braces {} are necessary for all arms of this statement
#122: FILE: hw/net/mcf_fec.c:213:
+else if (size == 64)
[...]
+else if (size < 128)
[...]
+else if (size < 256)
[...]
+else if (size < 512)
[...]
+else if (size < 1024)
[...]
+else if (size < 2048)
[...]
+else
[...]

ERROR: braces {} are necessary for all arms of this statement
#124: FILE: hw/net/mcf_fec.c:215:
+else if (size < 128)
[...]
+else if (size < 256)
[...]
+else if (size < 512)
[...]
+else if (size < 1024)
[...]
+else if (size < 2048)
[...]
+else
[...]

ERROR: braces {} are necessary for all arms of this statement
#126: FILE: hw/net/mcf_fec.c:217:
+else if (size < 256)
[...]
+else if (size < 512)
[...]
+else if (size < 1024)
[...]
+else if (size < 2048)
[...]
+else
[...]

ERROR: braces {} are necessary for all arms of this statement
#128: FILE: hw/net/mcf_fec.c:219:
+else if (size < 512)
[...]
+else if (size < 1024)
[...]
+else if (size < 2048)
[...]
+else
[...]

ERROR: braces {} are necessary for all arms of this statement
#130: FILE: hw/net/mcf_fec.c:221:
+else if (size < 1024)
[...]
+else if (size < 2048)
[...]
+else
[...]

ERROR: braces {} are necessary for all arms of this statement
#132: FILE: hw/net/mcf_fec.c:223:
+else if (size < 2048)
[...]
+else
[...]

ERROR: braces {} are necessary for all arms of this statement
#176: FILE: hw/net/mcf_fec.c:496:
+if (size < 64)
[...]
+else if (size == 64)
[...]
+else if (size < 128)
[...]
+else if (size < 256)
[...]
+else if (size < 512)
[...]
+else if (size < 1024)
[...]
+else if (size < 2048)
[...]
+else
[...]

ERROR: braces {} are necessary for all arms of this statement
#178: FILE: hw/net/mcf_fec.c:498:
+else if (size == 64)
[...]
+else if (size < 128)
[...]
+else if (size < 256)
[...]
+else if (size < 512)
[...]
+else if (size < 1024)
[...]
+else if (size < 2048)
[...]
+else
[...]

ERROR: braces {} are necessary for all arms of this statement
#180: FILE: hw/net/mcf_fec.c:500:
+else if (size < 128)
[...]
+else if (size < 256)
[...]
+else if (size < 512)
[...]
+else if (size < 1024)
[...]
+else if (size < 2048)
[...]
+else
[...]

ERROR: braces {} are necessary for all arms of this statement
#182: FILE: hw/net/mcf_fec.c:502:
+else if (size < 256)
[...]
+else if (size < 512)
[...]
+else if (size < 1024)
[...]
+else if (size < 2048)
[...]
+else
[...]

ERROR: braces {} are necessary for all arms of this statement
#184: FILE: hw/net/mcf_fec.c:504:
+else if (size < 512)
[...]
+else if (size < 1024)
[...]
+else if (size < 2048)
[...]
+else
[...]

ERROR: braces {} are necessary for all arms of this statement
#186: FILE: hw/net/mcf_fec.c:506:
+else if (size < 1024)
[...]
+else if (size < 2048)
[...]
+else
[...]

ERROR: braces {} are necessary for all arms of this statement
#188: FILE: hw/net/mcf_fec.c:508:
+else if (size < 2048)
[...]
+else
[...]

ERROR: Missing Signed-off-by: line(s)

total: 15 errors, 0 warnings, 167 lines checked

Your patch has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

=== OUTPUT END ===

Test command exited with code: 1


---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to patchew-de...@free

[Qemu-devel] [PATCH v2 3/3] fix qmp/hmp query-memdev not reporting IDs of memory backends

[Igor Mammedov]

Considering 'id' is mandatory for user_creatable objects/backends
and user_creatable_add_type() always has it as an argument
regardless of where from it is called CLI/monitor or QMP,
Fix issue by adding 'id' property to hostmem backends and
set it in user_creatable_add_type() for every object that
implements 'id' property. Then later at query-memdev time
get 'id' from object directly.

Signed-off-by: Igor Mammedov 
---
 include/sysemu/hostmem.h |  1 +
 backends/hostmem.c   | 26 ++
 docs/qmp-commands.txt|  1 +
 hmp.c|  5 +
 numa.c   |  3 +++
 qapi-schema.json |  3 +++
 qom/object_interfaces.c  |  6 ++
 7 files changed, 41 insertions(+), 4 deletions(-)

diff --git a/include/sysemu/hostmem.h b/include/sysemu/hostmem.h
index 678232a..ecae0cf 100644
--- a/include/sysemu/hostmem.h
+++ b/include/sysemu/hostmem.h
@@ -52,6 +52,7 @@ struct HostMemoryBackend {
 Object parent;
 
 /* protected */
+char *id;
 uint64_t size;
 bool merge, dump;
 bool prealloc, force_prealloc, is_mapped;
diff --git a/backends/hostmem.c b/backends/hostmem.c
index 4256d24..7f5de70 100644
--- a/backends/hostmem.c
+++ b/backends/hostmem.c
@@ -348,6 +348,24 @@ host_memory_backend_can_be_deleted(UserCreatable *uc, 
Error **errp)
 }
 }
 
+static char *get_id(Object *o, Error **errp)
+{
+HostMemoryBackend *backend = MEMORY_BACKEND(o);
+
+return g_strdup(backend->id);
+}
+
+static void set_id(Object *o, const char *str, Error **errp)
+{
+HostMemoryBackend *backend = MEMORY_BACKEND(o);
+
+if (backend->id) {
+error_setg(errp, "cannot change property value");
+return;
+}
+backend->id = g_strdup(str);
+}
+
 static void
 host_memory_backend_class_init(ObjectClass *oc, void *data)
 {
@@ -377,6 +395,13 @@ host_memory_backend_class_init(ObjectClass *oc, void *data)
 HostMemPolicy_lookup,
 host_memory_backend_get_policy,
 host_memory_backend_set_policy, &error_abort);
+object_class_property_add_str(oc, "id", get_id, set_id, &error_abort);
+}
+
+static void host_memory_backend_finalize(Object *o)
+{
+HostMemoryBackend *backend = MEMORY_BACKEND(o);
+g_free(backend->id);
 }
 
 static const TypeInfo host_memory_backend_info = {
@@ -387,6 +412,7 @@ static const TypeInfo host_memory_backend_info = {
 .class_init = host_memory_backend_class_init,
 .instance_size = sizeof(HostMemoryBackend),
 .instance_init = host_memory_backend_init,
+.instance_finalize = host_memory_backend_finalize,
 .interfaces = (InterfaceInfo[]) {
 { TYPE_USER_CREATABLE },
 { }
diff --git a/docs/qmp-commands.txt b/docs/qmp-commands.txt
index abf210a..18db4cd 100644
--- a/docs/qmp-commands.txt
+++ b/docs/qmp-commands.txt
@@ -3529,6 +3529,7 @@ Example (1):
  "policy": "bind"
},
{
+ "id": "mem1",
  "size": 536870912,
  "merge": false,
  "dump": true,
diff --git a/hmp.c b/hmp.c
index e7bead5..8522efe 100644
--- a/hmp.c
+++ b/hmp.c
@@ -2078,13 +2078,11 @@ void hmp_info_memdev(Monitor *mon, const QDict *qdict)
 MemdevList *m = memdev_list;
 Visitor *v;
 char *str;
-int i = 0;
-
 
 while (m) {
 v = string_output_visitor_new(false, &str);
 visit_type_uint16List(v, NULL, &m->value->host_nodes, NULL);
-monitor_printf(mon, "memory backend: %d\n", i);
+monitor_printf(mon, "memory backend: %s\n", m->value->id);
 monitor_printf(mon, "  size:  %" PRId64 "\n", m->value->size);
 monitor_printf(mon, "  merge: %s\n",
m->value->merge ? "true" : "false");
@@ -2100,7 +2098,6 @@ void hmp_info_memdev(Monitor *mon, const QDict *qdict)
 g_free(str);
 visit_free(v);
 m = m->next;
-i++;
 }
 
 monitor_printf(mon, "\n");
diff --git a/numa.c b/numa.c
index 9c09e45..f5fc7da 100644
--- a/numa.c
+++ b/numa.c
@@ -518,6 +518,9 @@ static int query_memdev(Object *obj, void *opaque)
 
 m->value = g_malloc0(sizeof(*m->value));
 
+m->value->id = object_property_get_str(obj, "id", NULL);
+m->value->has_id = !!m->value->id;
+
 m->value->size = object_property_get_int(obj, "size",
  &error_abort);
 m->value->merge = object_property_get_bool(obj, "merge",
diff --git a/qapi-schema.json b/qapi-schema.json
index a0d3b5d..88eb2b9 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -4453,6 +4453,8 @@
 #
 # Information about memory backend
 #
+# @id: #optional backend's ID if backend has 'id' property (since 2.9)
+#
 # @size: memory backend size
 #
 # @merge: enables or disables memory merge support
@@ -4469,6 +4471,7 @@
 ##
 { 'struct': 'Memdev',
   'data': {
+'*id':'str',
 'size':   'size',
 'merge':  'bool',
 'dump':   'bool',
diff --git a/qom/object_interfaces.c b/qom/object_interfaces.c
index 9b4155a..03a95c

[Qemu-devel] [PATCH v2 0/3] fix query-memdev not repporting IDs of memory backends

[Igor Mammedov]

Changelog:
since v1:
* fix mistakes in commit messages/change them as suggested
* extend 3/3 commit message to explain why it's ok to use 'id'
* 3/3 set 'id' property directly instead of injecting it back
  into qdict.


Series is a couple of preparratory cleanups which simplify fix
and a fix itself.

Before fix HMP 'info memdevs' for CLI:
qemu-system-x86_64 -object memory-backend-ram,id=mem0,size=1G
outputs:

  memory backend: 0
size:  1073741824
merge: true
dump: true
prealloc: false
policy: default
host nodes: 128

after fix:

  memory backend: mem0
size:  1073741824
merge: true
dump: true
prealloc: false
policy: default
host nodes: 128

it should help to avoid remembering hotplugged IDs as they
could be queried back via HMP/QMP interface.

CC: ehabk...@redhat.com
CC: arm...@redhat.com
CC: dgilb...@redhat.com
CC: ebl...@redhat.com
CC: afaer...@suse.de
CC: pbonz...@redhat.com

Igor Mammedov (3):
  qom: remove unused header
  reuse user_creatable_add_opts() instead of user_creatable_add() in
monitor
  fix qmp/hmp query-memdev not reporting IDs of memory backends

 include/qom/object_interfaces.h | 17 -
 include/sysemu/hostmem.h|  1 +
 backends/hostmem.c  | 26 ++
 docs/qmp-commands.txt   |  1 +
 hmp.c   | 10 ++
 numa.c  |  3 ++
 qapi-schema.json|  3 ++
 qom/object_interfaces.c | 78 -
 8 files changed, 59 insertions(+), 80 deletions(-)

-- 
2.7.4

[Qemu-devel] [PATCH v2 2/3] reuse user_creatable_add_opts() instead of user_creatable_add() in monitor

[Igor Mammedov]

Simplify code by dropping ~57LOC by merging user_creatable_add()
into user_creatable_add_opts() and using the later from monitor.
Along with it allocate opts_visitor_new() once in user_creatable_add_opts().

As result we have one less API func and a more readable/simple
user_creatable_add_opts() vs user_creatable_add().

Signed-off-by: Igor Mammedov 
Reviewed-by: Eric Blake 
---
 include/qom/object_interfaces.h | 17 --
 hmp.c   |  5 +--
 qom/object_interfaces.c | 71 ++---
 3 files changed, 18 insertions(+), 75 deletions(-)

diff --git a/include/qom/object_interfaces.h b/include/qom/object_interfaces.h
index 8b17f4d..fdd7603 100644
--- a/include/qom/object_interfaces.h
+++ b/include/qom/object_interfaces.h
@@ -76,23 +76,6 @@ void user_creatable_complete(Object *obj, Error **errp);
 bool user_creatable_can_be_deleted(UserCreatable *uc, Error **errp);
 
 /**
- * user_creatable_add:
- * @qdict: the object definition
- * @v: the visitor
- * @errp: if an error occurs, a pointer to an area to store the error
- *
- * Create an instance of the user creatable object whose type
- * is defined in @qdict by the 'qom-type' field, placing it
- * in the object composition tree with name provided by the
- * 'id' field. The remaining fields in @qdict are used to
- * initialize the object properties.
- *
- * Returns: the newly created object or NULL on error
- */
-Object *user_creatable_add(const QDict *qdict,
-   Visitor *v, Error **errp);
-
-/**
  * user_creatable_add_type:
  * @type: the object type name
  * @id: the unique ID for the object
diff --git a/hmp.c b/hmp.c
index b869617..e7bead5 100644
--- a/hmp.c
+++ b/hmp.c
@@ -1808,7 +1808,6 @@ void hmp_object_add(Monitor *mon, const QDict *qdict)
 {
 Error *err = NULL;
 QemuOpts *opts;
-Visitor *v;
 Object *obj = NULL;
 
 opts = qemu_opts_from_qdict(qemu_find_opts("object"), qdict, &err);
@@ -1817,9 +1816,7 @@ void hmp_object_add(Monitor *mon, const QDict *qdict)
 return;
 }
 
-v = opts_visitor_new(opts);
-obj = user_creatable_add(qdict, v, &err);
-visit_free(v);
+obj = user_creatable_add_opts(opts, &err);
 qemu_opts_del(opts);
 
 if (err) {
diff --git a/qom/object_interfaces.c b/qom/object_interfaces.c
index 4b880d0..9b4155a 100644
--- a/qom/object_interfaces.c
+++ b/qom/object_interfaces.c
@@ -34,57 +34,6 @@ bool user_creatable_can_be_deleted(UserCreatable *uc, Error 
**errp)
 }
 }
 
-
-Object *user_creatable_add(const QDict *qdict,
-   Visitor *v, Error **errp)
-{
-char *type = NULL;
-char *id = NULL;
-Object *obj = NULL;
-Error *local_err = NULL;
-QDict *pdict;
-
-pdict = qdict_clone_shallow(qdict);
-
-visit_start_struct(v, NULL, NULL, 0, &local_err);
-if (local_err) {
-goto out;
-}
-
-qdict_del(pdict, "qom-type");
-visit_type_str(v, "qom-type", &type, &local_err);
-if (local_err) {
-goto out_visit;
-}
-
-qdict_del(pdict, "id");
-visit_type_str(v, "id", &id, &local_err);
-if (local_err) {
-goto out_visit;
-}
-visit_check_struct(v, &local_err);
-if (local_err) {
-goto out_visit;
-}
-
-obj = user_creatable_add_type(type, id, pdict, v, &local_err);
-
-out_visit:
-visit_end_struct(v, NULL);
-
-out:
-QDECREF(pdict);
-g_free(id);
-g_free(type);
-if (local_err) {
-error_propagate(errp, local_err);
-object_unref(obj);
-return NULL;
-}
-return obj;
-}
-
-
 Object *user_creatable_add_type(const char *type, const char *id,
 const QDict *qdict,
 Visitor *v, Error **errp)
@@ -157,13 +106,27 @@ Object *user_creatable_add_opts(QemuOpts *opts, Error 
**errp)
 {
 Visitor *v;
 QDict *pdict;
-Object *obj = NULL;
+Object *obj;
+const char *id = qemu_opts_id(opts);
+const char *type = qemu_opt_get(opts, "qom-type");
+
+if (!type) {
+error_setg(errp, QERR_MISSING_PARAMETER, "qom-type");
+return NULL;
+}
+if (!id) {
+error_setg(errp, QERR_MISSING_PARAMETER, "id");
+return NULL;
+}
 
-v = opts_visitor_new(opts);
 pdict = qemu_opts_to_qdict(opts, NULL);
+qdict_del(pdict, "qom-type");
+qdict_del(pdict, "id");
 
-obj = user_creatable_add(pdict, v, errp);
+v = opts_visitor_new(opts);
+obj = user_creatable_add_type(type, id, pdict, v, errp);
 visit_free(v);
+
 QDECREF(pdict);
 return obj;
 }
-- 
2.7.4

Re: [Qemu-devel] [PATCH v7 12/21] qapi.py: fix line break before binary operator pep8

[Marc-André Lureau]

Hi

- Original Message -
> Marc-André Lureau  writes:
> 
> > Python code style accepts both form, but pep8 complains. Better to clean
> > up the single warning for now, so new errors stand out more easily.
> >
> > Fix scripts/qapi.py:1539:21: W503 line break before binary operator
> 
> PEP 8 permits both, but prefers line break before binary operator.
> Thus, this warning is clearly bogus.  What version of pep8 do you use?
> Mine doesn't warn.

I tried both 1.6.2 and 1.7.0

[Qemu-devel] [PATCH v2 1/3] qom: remove unused header

[Igor Mammedov]

Signed-off-by: Igor Mammedov 
Reviewed-by: Eric Blake 
---
 qom/object_interfaces.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/qom/object_interfaces.c b/qom/object_interfaces.c
index ded4d84..4b880d0 100644
--- a/qom/object_interfaces.c
+++ b/qom/object_interfaces.c
@@ -3,7 +3,6 @@
 #include "qom/object_interfaces.h"
 #include "qemu/module.h"
 #include "qapi-visit.h"
-#include "qapi/qobject-output-visitor.h"
 #include "qapi/opts-visitor.h"
 
 void user_creatable_complete(Object *obj, Error **errp)
-- 
2.7.4

Re: [Qemu-devel] [PATCH v7 08/21] qapi: move experimental note down

[Marc-André Lureau]

Hi

- Original Message -
> Marc-André Lureau  writes:
> 
> > Use a better 'Note:' section, move it below parameters following
> > guidelines.
> >
> > Signed-off-by: Marc-André Lureau 
> 
> Again, I don't mind moving stuff around if it helps getting this series
> wrapped, and doesn't make things less readable.  My only nit is the
> commit message's claim about the guidelines.  Let's sidestep it:
> 
> Move these notes down and prefix with "Note:", to please the doc
> generator we're going to add.
> 
> Okay?
> 

ok, thanks

Re: [Qemu-devel] [PATCH v8 1/1] crypto: add virtio-crypto driver

[Christian Borntraeger]

On 01/10/2017 01:36 PM, Gonglei (Arei) wrote:
> Hi,
> 
>>
>> On 12/15/2016 03:03 AM, Gonglei wrote:
>> [...]
>>> +
>>> +static struct crypto_alg virtio_crypto_algs[] = { {
>>> +   .cra_name = "cbc(aes)",
>>> +   .cra_driver_name = "virtio_crypto_aes_cbc",
>>> +   .cra_priority = 501,
>>
>>
>> This is still higher than the hardware-accelerators (like intel aesni or the
>> s390 cpacf functions or the arm hw). aesni and s390/cpacf are supported by 
>> the
>> hardware virtualization and available to the guests. I do not see a way how
>> virtio
>> crypto can be faster than that (in the end it might be cpacf/aesni + 
>> overhead)
>> instead it will very likely be slower.
>> So we should use a number that is higher than software implementations but
>> lower than the hw ones.
>>
>> Just grepping around, the software ones seem be be around 100 and the
>> hardware
>> ones around 200-400. So why was 150 not enough?
>>
> I didn't find a documentation about how we use the priority, and I assumed
> people use virtio-crypto will configure hardware accelerators in the
> host. So I choosed the number which bigger than aesni's priority.

Yes, but the aesni driver will only bind if there is HW support in the guest.
And if aesni is available in the guest (or the s390 aes function from cpacf)
it will always be faster than the same in the host via virtio.So your priority
should be smaller.

[Qemu-devel] [PATCH] es1370: wire up reset via DeviceClass

[Gerd Hoffmann]

Instead of using qemu_register_reset().
That way we get proper cleanup for free.

Signed-off-by: Gerd Hoffmann 
---
 hw/audio/es1370.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/hw/audio/es1370.c b/hw/audio/es1370.c
index 883ec69..fe64c1a 100644
--- a/hw/audio/es1370.c
+++ b/hw/audio/es1370.c
@@ -1010,9 +1010,9 @@ static const VMStateDescription vmstate_es1370 = {
 }
 };
 
-static void es1370_on_reset (void *opaque)
+static void es1370_on_reset(DeviceState *dev)
 {
-ES1370State *s = opaque;
+ES1370State *s = container_of(dev, ES1370State, dev.qdev);
 es1370_reset (s);
 }
 
@@ -1035,7 +1035,6 @@ static void es1370_realize(PCIDevice *dev, Error **errp)
 
 memory_region_init_io (&s->io, OBJECT(s), &es1370_io_ops, s, "es1370", 
256);
 pci_register_bar (&s->dev, 0, PCI_BASE_ADDRESS_SPACE_IO, &s->io);
-qemu_register_reset (es1370_on_reset, s);
 
 AUD_register_card ("es1370", &s->card);
 es1370_reset (s);
@@ -1075,6 +1074,7 @@ static void es1370_class_init (ObjectClass *klass, void 
*data)
 set_bit(DEVICE_CATEGORY_SOUND, dc->categories);
 dc->desc = "ENSONIQ AudioPCI ES1370";
 dc->vmsd = &vmstate_es1370;
+dc->reset = es1370_on_reset;
 }
 
 static const TypeInfo es1370_info = {
-- 
1.8.3.1

Re: [Qemu-devel] Question about add AF_ALG backend for virtio-crypto

[Daniel P. Berrange]

On Tue, Jan 10, 2017 at 12:17:48PM +, Gonglei (Arei) wrote:
> >
> > > >
> > > > >
> > > > > >
> > > > > > On Mon, Jan 09, 2017 at 01:43:10PM +, Stefan Hajnoczi wrote:
> > > > > > > On Mon, Jan 09, 2017 at 03:04:55PM +0800, Longpeng (Mike) wrote:
> > > > > > > > I'm one of Gonglei's virtio-crypto project members, and we plan 
> > > > > > > > to
> > add a
> > > > > > AF_ALG
> > > > > > > > backend for virtio-crypto(there's only builtin-backend 
> > > > > > > > currently).
> > > > > > > >
> > > > > > > > I found that Catalin, Paolo and Stefan had discussed about this 
> > > > > > > > in
> > 2015
> > > > > > > > (http://www.spinics.net/lists/kvm/msg115457.html), but it seems
> > that
> > > > > > Catalin
> > > > > > > > didn't do it, so I'm confuse about wether it is need to add a 
> > > > > > > > AF_ALG
> > > > > > backend.
> > > > > > > >
> > > > > > > > Do you have any suggestion? Thanks :)
> > > > > > >
> > > > > > > I have no objections to an AF_ALG backend in QEMU.
> > > > > >
> > > > > > Rather than do another backend for virtio-crypto, IMHO, we should 
> > > > > > have
> > > > > > an AF_ALG impl of the crypto/ APIs. That way any potential 
> > > > > > performance
> > > > > > benefits will enhance our LUKS encryption code too.
> > > > > >
> > > > > According to the currently schemas of crypto/ APIs, we can't choose 
> > > > > the
> > > > > specific backend dynamically. This is a limitation for virtio-crypto
> > > > > device I think.
> > > >
> > > > Do we really need to be able to choose the backend explicitly. If the 
> > > > AF_ALG
> > > > backend is faster, why would you simply not use that automatically if 
> > > > it is
> > > > available.
> > >
> > > Can we realize the purpose based on the crypto/ APIs? IIUC the crypto
> > > subsystem chooses a backend during the building according to the specific
> > priority,
> > > nettle > gcrypt > cipher-builtin.
> > >
> > > If we add an AF_ALG implementation for crypto subsystem, shall we set it
> > > as the highest priority? If so, other backends won't be used since AF_ALG
> > > is always available. If not, how can we use AF_ALG backend for crypto/ 
> > > API?
> > >
> > > Please correct me if I'm missing something.
> > 
> > While AF_ALG has been available for a while, not all features have. For
> > example AEAD support was only added in kernel 4.1
> > 
> OK.
> 
> > So if we had AF_ALG in QEMU, we would have to have a stacked impl, where
> > we try AF_ALG and then fallback to the current code when QEMU runs on a
> > kernel lacking the feature needed.
> > 
> It makes sense though the implementation will be more complicate
> since the code should identify the different error codes are returned
> by AF_ALG APIs.
> 
> > We could potentially also have a global arg to switch backends e.g.
> > 
> >  -crypto-backend [afalg|builtin]
> > 
> So the backend here is not the cryptodev backend?

No, it would apply to the crypto/ APIs, so it affects all users of those
APIs not just cryptodev


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

Re: [Qemu-devel] [PATCH v4 1/7] fw-cfg: support writeable blobs

[Laszlo Ersek]

On 12/20/16 16:58, Marcel Apfelbaum wrote:
> On 12/01/2016 07:06 PM, Laszlo Ersek wrote:
>> From: "Michael S. Tsirkin" 
>>
>> Useful to send guest data back to QEMU.
>>
>> Changes from Laszlo Ersek :
>> - rebase the patch from Michael Tsirkin's original postings at [1] and
>> [2]
>>   to the following patches:
>>   - loader: Allow a custom AddressSpace when loading ROMs
>>   - loader: Add AddressSpace loading support to uImages
>>   - loader: fix handling of custom address spaces when adding ROM blobs
>> - reject such writes immediately that would exceed the end of the array,
>>   rather than performing a partial write before setting the error bit:
>> see
>>   the (len != dma.length) condition
>> - document the write interface
>>
>> [1] http://lists.nongnu.org/archive/html/qemu-devel/2016-02/msg04968.html
>> [2] http://lists.nongnu.org/archive/html/qemu-devel/2016-03/msg02735.html
>>
>> Cc: "Gabriel L. Somlo" 
>> Cc: "Michael S. Tsirkin" 
>> Cc: Gerd Hoffmann 
>> Cc: Igor Mammedov 
>> Cc: Michael Walle 
>> Cc: Paolo Bonzini 
>> Cc: Peter Maydell 
>> Cc: Shannon Zhao 
>> Cc: qemu-...@nongnu.org
>> Signed-off-by: Michael S. Tsirkin 
>> Signed-off-by: Laszlo Ersek 
>> ---
>>  docs/specs/fw_cfg.txt | 32 +---
>>  hw/lm32/lm32_hwsetup.h|  2 +-
>>  include/hw/loader.h   |  7 ---
>>  include/hw/nvram/fw_cfg.h |  3 ++-
>>  hw/arm/virt-acpi-build.c  |  2 +-
>>  hw/core/loader.c  | 18 +++---
>>  hw/i386/acpi-build.c  |  4 ++--
>>  hw/nvram/fw_cfg.c | 37 +
>>  8 files changed, 75 insertions(+), 30 deletions(-)
>>
>> diff --git a/docs/specs/fw_cfg.txt b/docs/specs/fw_cfg.txt
>> index 7a5f8c7824ce..a19e2adbe1c6 100644
>> --- a/docs/specs/fw_cfg.txt
>> +++ b/docs/specs/fw_cfg.txt
>> @@ -31,21 +31,25 @@ register. In other words, configuration write mode
>> is enabled when
>>  the selector value is between 0x4000-0x7fff or 0xc000-0x.
>>
>>  NOTE: As of QEMU v2.4, writes to the fw_cfg data register are no
>>longer supported, and will be ignored (treated as no-ops)!
>>
>> +NOTE: As of QEMU v2.9, writes are reinstated, but only through the DMA
>> +  interface (see below). Furthermore, writeability of any
>> specific item is
>> +  governed independently of Bit14 in the selector key value.
>> +
>>  Bit15 of the selector register indicates whether the configuration
>>  setting is architecture specific. A value of 0 means the item is a
>>  generic configuration item. A value of 1 means the item is specific
>>  to a particular architecture. In other words, generic configuration
>>  items are accessed with a selector value between 0x-0x7fff, and
>>  architecture specific configuration items are accessed with a selector
>>  value between 0x8000-0x.
>>
>>  == Data Register ==
>>
>> -* Read/Write (writes ignored as of QEMU v2.4)
>> +* Read/Write (writes ignored as of QEMU v2.4, but see the DMA interface)
>>  * Location: platform dependent (IOport [*] or MMIO)
>>  * Width: 8-bit (if IOport), 8/16/32/64-bit (if MMIO)
>>  * Endianness: string-preserving
>>
>>  [*] On platforms where the data register is exposed as an IOport, its
>> @@ -132,23 +136,25 @@ struct FWCfgFile {/* an individual file
>> entry, 64 bytes total */
>>  char name[56];/* fw_cfg item name, NUL-terminated ascii */
>>  };
>>
>>  === All Other Data Items ===
>>
>> -Please consult the QEMU source for the most up-to-date and authoritative
>> -list of selector keys and their respective items' purpose and format.
>> +Please consult the QEMU source for the most up-to-date and
>> authoritative list
>> +of selector keys and their respective items' purpose, format and
>> writeability.
>>
>>  === Ranges ===
>>
>>  Theoretically, there may be up to 0x4000 generic firmware configuration
>>  items, and up to 0x4000 architecturally specific ones.
>>
>>  Selector Reg.Range Usage
>>  ---  ---
>> -0x - 0x3fff  Generic (0x - 0x3fff, RO)
>> +0x - 0x3fff  Generic (0x - 0x3fff, generally RO, possibly RW
>> through
>> +  the DMA interface in QEMU v2.9+)
>>  0x4000 - 0x7fff  Generic (0x - 0x3fff, RW, ignored in QEMU v2.4+)
>> -0x8000 - 0xbfff  Arch. Specific (0x - 0x3fff, RO)
>> +0x8000 - 0xbfff  Arch. Specific (0x - 0x3fff, generally RO,
>> possibly RW
>> + through the DMA interface in QEMU
>> v2.9+)
>>  0xc000 - 0x  Arch. Specific (0x - 0x3fff, RW, ignored in v2.4+)
>>
>>  In practice, the number of allowed firmware configuration items is given
>>  by the value of FW_CFG_MAX_ENTRY (see fw_cfg.h).
>>
>> @@ -180,21 +186,31 @@ address is the "control" field.
>>  The "control" field has the following bits:
>>   - Bit 0: Error
>>   - Bit 1: Read
>>   - Bit 2: Skip
>>   - Bit 3: Select. The upper 16 bits are the selected index.
>> + - Bit 4: Write
>>
>>  When an operation is triggered, if the "control" field has bit 3 set,
>> 

Re: [Qemu-devel] [PATCH 0/1] Change default CFLAGS to -O3

[Jin Guojie]

Thanks all for your review comments.
To measure the actual performance difference between O2 and O3,
I did the following tests:

Environments:
* Hardware: AMD Athlon II X2 270 Processor, 3.4 GHz
* Host OS: Fedora25 X86_64
* qemu: 2.8.0
* gcc: 6.2.1
* Guest OS: linux-0.2.img
  (downloaded from http://wiki.qemu.org/Testing/System_Images)
* Benchmark: nbench within linux-0.2.img

Results:
  Each test has been run at least 3 times to minimize the deviation.
  Higher score is better.

||   O2   |   O3   |

| qemu-system-i386(stripped) | 8.1 MB | 8.9 MB | 
| nbench(NUMERIC SORT)   | 254.72 | 260.48 |
|| 259.2  | 259.52 |
|| 261.04,| 259.68 |

Conclusion:
  Compared with O2, O3 brings no obvious performance advantage.
  It's highly possible that the benchmark score is mainly determined
  by the quality of tcg, not the host compiler.

Related work:
(1) The same test is done on a Loongson 3A2000.
  It's a mips64el-compatible CPU, with 4 cores running at 1.5 GHz.
  The result and conclusion are almost the same with X86.
(2) Another scene of OS booting is taken into consideration.
  I compare the booting time of linux-0.2.img under O2 and O3.
  Once again, I cannot see an observable difference.

Based on these data I admit my patch has no benifit for performance.

Jin Guojie

 -- Original --
From:  "Peter Maydell";;
Send time: Monday, Jan 9, 2017 6:33 PM
To: "Jin Guojie"; 
Cc: "QEMU Developers"; "Paolo 
Bonzini"; 
Subject:  Re: [Qemu-devel] [PATCH 0/1] Change default CFLAGS to -O3



On 9 January 2017 at 10:01, Jin Guojie  wrote:
> * in configure, the default optimization level is changed to O3.
> * Tested successfully on following machines:
>
>   | Host machine | Host OS  | qemu-system | Debian ISO  |
>   |-|
>   |   x86 64 | Fedora25 |i386 |i386 |
>   | mips 64 le   | Fedora25 |i386 |i386 |
>
> Signed-off-by: Jin Guojie 
>
> Jin Guojie (1):
>   Change default CFLAGS to -O3
>
>  configure | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

...so what are the measured performance improvements from
this change? As I understand it -O3 is where the "trade off
code size for speed" optimisations kick in, so we need
to benchmark to be sure that the increased icache usage
doesn't outweigh any speed gains. -O3 is not guaranteed
to be strictly better than -O2 (which is why for instance
Debian and Gentoo recommend -O2 as their default).

thanks
-- PMM

Re: [Qemu-devel] [PATCH v2 1/8] sockets: add ability to disable DNS resolution for InetSocketAddress

[Eric Blake]

On 01/09/2017 09:39 AM, Daniel P. Berrange wrote:
> Add a 'numeric' flag to the InetSocketAddress struct to allow the
> caller to indicate that DNS should be skipped for the host/port
> fields. This is useful if the caller knows the address is already
> numeric and wants to guarantee no (potentially blocking) DNS
> lookups are attempted.
> 
> Signed-off-by: Daniel P. Berrange 
> ---
>  qapi-schema.json| 5 +
>  util/qemu-sockets.c | 3 +++
>  2 files changed, 8 insertions(+)
> 

Reviewed-by: Eric Blake 

-- 
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 v5 1/7] host-utils: Move 128-bit guard macro to .c file

[Eric Blake]

On 01/09/2017 08:10 PM, Jose Ricardo Ziviani wrote:
> It is not possible to implement functions in host-utils.c for
> architectures with quadwords because the guard is implemented in the
> Makefile. This patch move the guard out of the Makefile to the

s/move/moves/

> implementation file.
> 
> Signed-off-by: Jose Ricardo Ziviani 
> ---
>  util/Makefile.objs | 2 +-
>  util/host-utils.c  | 2 ++
>  2 files changed, 3 insertions(+), 1 deletion(-)
> 

Reviewed-by: Eric Blake 

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



signature.asc
Description: OpenPGP digital signature

[Qemu-devel] [Bug 601946] Re: [Feature request] qemu-img multi-threaded compressed image conversion

[Paolo Bonzini]

The fact that it's now a coroutine_fn doesn't change much, if anything
it makes it simpler to handle multiple writes in parallel.

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

Title:
  [Feature request] qemu-img multi-threaded compressed image conversion

Status in QEMU:
  New

Bug description:
  Feature request:
  qemu-img multi-threaded compressed image conversion

  Suppose I want to convert raw image to compressed qcow2. Multi-
  threaded conversion will be much faster, because bottleneck is
  compressing data.

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

[Qemu-devel] [PATCH 0/7] fix potential hangs in 9pfs

[Greg Kurz]

The 9P open and create operations cause QEMU to call the open(2) syscall on
the backend. Unfortunately, it doesn't check if the given pathname already
exists and points to something that could cause open(2) to hang (like a named
pipe for example).

This series fixes the issues for open (only allow directories and regular
files) and create (enforce O_EXCL). It also adds the corresponding tests in
virtio-9p-test.

---

Greg Kurz (7):
  9pfs: restrict open to regular files and directories
  tests: virtio-9p: improve error reporting
  tests: virtio-9p: add LOPEN operation test
  tests: virtio-9p: TLOPEN should fail to open a FIFO
  9pfs: don't create files if pathname already exists
  tests: virtio-9p: add LCREATE operation test
  tests: virtio-9p: TLCREATE should fail if pathname exists


 hw/9pfs/9p.c   |   10 ++
 tests/virtio-9p-test.c |  197 +++-
 2 files changed, 199 insertions(+), 8 deletions(-)

--
Greg

[Qemu-devel] [PATCH 1/7] 9pfs: restrict open to regular files and directories

[Greg Kurz]

It really does not make sense for the 9P server to open anything else but
a regular file or a directory.

Malicious code in a guest could for example create a named pipe, associate
it to a valid fid and pass it to the server in a RLOPEN message. This would
cause QEMU to hang in open(), waiting for someone to open the other end of
the pipe.

Signed-off-by: Greg Kurz 
---
 hw/9pfs/9p.c |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
index fa58877570f6..edd7b97270e3 100644
--- a/hw/9pfs/9p.c
+++ b/hw/9pfs/9p.c
@@ -1462,7 +1462,7 @@ static void coroutine_fn v9fs_open(void *opaque)
 goto out;
 }
 err += offset;
-} else {
+} else if (S_ISREG(stbuf.st_mode)) {
 if (s->proto_version == V9FS_PROTO_2000L) {
 flags = get_dotl_openflags(s, mode);
 } else {
@@ -1494,6 +1494,9 @@ static void coroutine_fn v9fs_open(void *opaque)
 goto out;
 }
 err += offset;
+} else {
+err = -EINVAL;
+goto out;
 }
 trace_v9fs_open_return(pdu->tag, pdu->id,
qid.type, qid.version, qid.path, iounit);

[Qemu-devel] [PATCH 3/7] tests: virtio-9p: add LOPEN operation test

[Greg Kurz]

The "fs_lopen" test creates a file on the backend, walks to it with
the walk operation and issues a LOPEN operation, which is expected to
succeed. Note that LOPEN is the OPEN operation implemented by the
9P2000.L version of the 9P protocol, which is used by the linux kernel
client.

References:

https://github.com/chaos/diod/blob/master/protocol.md#lopenopen-a-file
http://man.cat-v.org/plan_9/5/open

Signed-off-by: Greg Kurz 
---
 tests/virtio-9p-test.c |   55 
 1 file changed, 55 insertions(+)

diff --git a/tests/virtio-9p-test.c b/tests/virtio-9p-test.c
index 9556291567a4..14b4787930ae 100644
--- a/tests/virtio-9p-test.c
+++ b/tests/virtio-9p-test.c
@@ -243,6 +243,7 @@ static const char *rmessage_name(uint8_t id)
 id == P9_RVERSION ? "RVERSION" :
 id == P9_RATTACH ? "RATTACH" :
 id == P9_RWALK ? "RWALK" :
+id == P9_RLOPEN ? "RLOPEN" :
 "";
 }
 
@@ -395,6 +396,33 @@ static void v9fs_rwalk(P9Req *req, uint16_t *nwqid, 
v9fs_qid **wqid)
 v9fs_req_free(req);
 }
 
+/* size[4] Tlopen tag[2] fid[4] flags[4] */
+static P9Req *v9fs_tlopen(QVirtIO9P *v9p, uint32_t fid, uint32_t flags)
+{
+P9Req *req;
+
+req = v9fs_req_init(v9p,  4 + 4, P9_TLOPEN, ++(v9p->p9_req_tag));
+v9fs_uint32_write(req, fid);
+v9fs_uint32_write(req, flags);
+v9fs_req_send(req);
+return req;
+}
+
+/* size[4] Rlopen tag[2] qid[13] iounit[4] */
+static void v9fs_rlopen(P9Req *req, v9fs_qid *qid, uint32_t *iounit)
+{
+v9fs_req_recv(req, P9_RLOPEN);
+if (qid) {
+v9fs_memread(req, qid, 13);
+} else {
+v9fs_memskip(req, 13);
+}
+if (iounit) {
+v9fs_uint32_read(req, iounit);
+}
+v9fs_req_free(req);
+}
+
 static void fs_version(QVirtIO9P *v9p)
 {
 const char *version = "9P2000.L";
@@ -483,6 +511,32 @@ static void fs_walk_dotdot(QVirtIO9P *v9p)
 g_free(wnames[0]);
 }
 
+static void fs_lopen(QVirtIO9P *v9p)
+{
+char *const wnames[] = { g_strdup(__func__) };
+char *path = g_strdup_printf("%s/%s", v9p->test_share, wnames[0]);
+uint32_t iounit;
+int fd;
+P9Req *req;
+
+fd = creat(path, 0600);
+g_assert(fd >= 0);
+close(fd);
+
+fs_attach(v9p);
+req = v9fs_twalk(v9p, 0, 1, 1, wnames);
+v9fs_rwalk(req, NULL, NULL);
+
+req = v9fs_tlopen(v9p, 1, O_RDONLY);
+v9fs_rlopen(req, NULL, &iounit);
+
+g_assert_cmpint(iounit, <=, P9_MAX_SIZE - P9_IOHDRSZ);
+
+unlink(path);
+g_free(path);
+g_free(wnames[0]);
+}
+
 typedef void (*v9fs_test_fn)(QVirtIO9P *v9p);
 
 static void v9fs_run_pci_test(gconstpointer data)
@@ -512,6 +566,7 @@ int main(int argc, char **argv)
 v9fs_qtest_pci_add("/virtio/9p/pci/fs/walk/no_slash", fs_walk_no_slash);
 v9fs_qtest_pci_add("/virtio/9p/pci/fs/walk/dotdot_from_root",
fs_walk_dotdot);
+v9fs_qtest_pci_add("/virtio/9p/pci/fs/lopen/basic", fs_lopen);
 
 return g_test_run();
 }

[Qemu-devel] [PATCH 5/7] 9pfs: don't create files if pathname already exists

[Greg Kurz]

As specified in the http://man.cat-v.org/plan_9/5/open :

"An attempt to create a file in a directory where the given
name already exists will be rejected"

Malicious code in a guest could for example create a named pipe and
then pass its name to the server in a RLCREATE message. This would
cause QEMU to hang in open(), waiting for someone to open the other
end of the pipe.

Let's fix this by simply using O_EXCL.

Signed-off-by: Greg Kurz 
---
 hw/9pfs/9p.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
index edd7b97270e3..d9686601deda 100644
--- a/hw/9pfs/9p.c
+++ b/hw/9pfs/9p.c
@@ -1545,7 +1545,7 @@ static void coroutine_fn v9fs_lcreate(void *opaque)
 
 flags = get_dotl_openflags(pdu->s, flags);
 err = v9fs_co_open2(pdu, fidp, &name, gid,
-flags | O_CREAT, mode, &stbuf);
+flags | O_CREAT | O_EXCL, mode, &stbuf);
 if (err < 0) {
 goto out;
 }
@@ -2252,7 +2252,8 @@ static void coroutine_fn v9fs_create(void *opaque)
 v9fs_path_copy(&fidp->path, &path);
 } else {
 err = v9fs_co_open2(pdu, fidp, &name, -1,
-omode_to_uflags(mode)|O_CREAT, perm, &stbuf);
+omode_to_uflags(mode) | O_CREAT | O_EXCL, perm,
+&stbuf);
 if (err < 0) {
 goto out;
 }

[Qemu-devel] [PATCH 2/7] tests: virtio-9p: improve error reporting

[Greg Kurz]

Signed-off-by: Greg Kurz 
---
 tests/virtio-9p-test.c |   24 +++-
 1 file changed, 19 insertions(+), 5 deletions(-)

diff --git a/tests/virtio-9p-test.c b/tests/virtio-9p-test.c
index 060407b20e39..9556291567a4 100644
--- a/tests/virtio-9p-test.c
+++ b/tests/virtio-9p-test.c
@@ -236,6 +236,16 @@ static void v9fs_req_send(P9Req *req)
 req->t_off = 0;
 }
 
+static const char *rmessage_name(uint8_t id)
+{
+return
+id == P9_RLERROR ? "RLERROR" :
+id == P9_RVERSION ? "RVERSION" :
+id == P9_RATTACH ? "RATTACH" :
+id == P9_RWALK ? "RWALK" :
+"";
+}
+
 static void v9fs_req_recv(P9Req *req, uint8_t id)
 {
 QVirtIO9P *v9p = req->v9p;
@@ -258,11 +268,15 @@ static void v9fs_req_recv(P9Req *req, uint8_t id)
 g_assert_cmpint(hdr.size, <=, P9_MAX_SIZE);
 g_assert_cmpint(hdr.tag, ==, req->tag);
 
-if (hdr.id != id && hdr.id == P9_RLERROR) {
-uint32_t err;
-v9fs_uint32_read(req, &err);
-g_printerr("Received Rlerror (%d) instead of Response %d\n", err, id);
-g_assert_not_reached();
+if (hdr.id != id) {
+g_printerr("Received response %d (%s) instead of %d (%s)\n",
+   hdr.id, rmessage_name(hdr.id), id, rmessage_name(id));
+
+if (hdr.id == P9_RLERROR) {
+uint32_t err;
+v9fs_uint32_read(req, &err);
+g_printerr("Rlerror has errno %d (%s)\n", err, strerror(err));
+}
 }
 g_assert_cmpint(hdr.id, ==, id);
 }

[Qemu-devel] [PATCH 4/7] tests: virtio-9p: TLOPEN should fail to open a FIFO

[Greg Kurz]

A 9P server should only try to open regular files and directories.

Signed-off-by: Greg Kurz 
---
 tests/virtio-9p-test.c |   25 +
 1 file changed, 25 insertions(+)

diff --git a/tests/virtio-9p-test.c b/tests/virtio-9p-test.c
index 14b4787930ae..334833f88a6e 100644
--- a/tests/virtio-9p-test.c
+++ b/tests/virtio-9p-test.c
@@ -537,6 +537,29 @@ static void fs_lopen(QVirtIO9P *v9p)
 g_free(wnames[0]);
 }
 
+static void fs_lopen_fifo_not_allowed(QVirtIO9P *v9p)
+{
+char *const wnames[] = { g_strdup(__func__) };
+char *test_fifo;
+P9Req *req;
+uint32_t err;
+
+test_fifo = g_strdup_printf("%s/%s", v9p->test_share, wnames[0]);
+g_assert(mkfifo(test_fifo, 0600) == 0);
+
+fs_attach(v9p);
+req = v9fs_twalk(v9p, 0, 1, 1, wnames);
+v9fs_rwalk(req, NULL, NULL);
+req = v9fs_tlopen(v9p, 1, O_RDONLY);
+v9fs_rlerror(req, &err);
+
+g_assert_cmpint(err, ==, EINVAL);
+
+unlink(test_fifo);
+g_free(test_fifo);
+g_free(wnames[0]);
+}
+
 typedef void (*v9fs_test_fn)(QVirtIO9P *v9p);
 
 static void v9fs_run_pci_test(gconstpointer data)
@@ -567,6 +590,8 @@ int main(int argc, char **argv)
 v9fs_qtest_pci_add("/virtio/9p/pci/fs/walk/dotdot_from_root",
fs_walk_dotdot);
 v9fs_qtest_pci_add("/virtio/9p/pci/fs/lopen/basic", fs_lopen);
+v9fs_qtest_pci_add("/virtio/9p/pci/fs/lopen/fifo_not_allowed",
+   fs_lopen_fifo_not_allowed);
 
 return g_test_run();
 }

Re: [Qemu-devel] [PATCH 1/7] 9pfs: restrict open to regular files and directories

[Eric Blake]

On 01/10/2017 08:32 AM, Greg Kurz wrote:
> It really does not make sense for the 9P server to open anything else but
> a regular file or a directory.
> 
> Malicious code in a guest could for example create a named pipe, associate
> it to a valid fid and pass it to the server in a RLOPEN message. This would
> cause QEMU to hang in open(), waiting for someone to open the other end of
> the pipe.
> 
> Signed-off-by: Greg Kurz 
> ---
>  hw/9pfs/9p.c |5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
> index fa58877570f6..edd7b97270e3 100644
> --- a/hw/9pfs/9p.c
> +++ b/hw/9pfs/9p.c
> @@ -1462,7 +1462,7 @@ static void coroutine_fn v9fs_open(void *opaque)
>  goto out;
>  }
>  err += offset;
> -} else {
> +} else if (S_ISREG(stbuf.st_mode)) {
>  if (s->proto_version == V9FS_PROTO_2000L) {

TOCTTOU race.  You are checking the stat() results and only then calling
open(), rather than calling open() first and validating fstat().  That
means the guest can STILL cause you to open() a pipe by changing the
file type in between the stat and the open.

I think you need to rework this patch to open() first, then validate
(closing the fd if necessary); the open can be done with O_NONBLOCK to
avoid hanging on a pipe.  Yes, that's more annoying, but that's life
with TOCTTOU races.

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



signature.asc
Description: OpenPGP digital signature

[Qemu-devel] [PATCH 6/7] tests: virtio-9p: add LCREATE operation test

[Greg Kurz]

The "fs_lcreate" test clones the root directory fid, walks to it and
issues a LCREATE operation, which is expected to succeed. It then
ensures a file was indeed created in the underlying filesystem.
Note that LCREATE is the CREATE operation implemented by the 9P2000.L
version of the 9P protocol, which is used by the linux kernel client.

References:

https://github.com/chaos/diod/blob/master/protocol.md#lcreatecreate-regular-file
http://man.cat-v.org/plan_9/5/open

Signed-off-by: Greg Kurz 
---
 tests/virtio-9p-test.c |   62 
 1 file changed, 62 insertions(+)

diff --git a/tests/virtio-9p-test.c b/tests/virtio-9p-test.c
index 334833f88a6e..7f2ee41ca0f0 100644
--- a/tests/virtio-9p-test.c
+++ b/tests/virtio-9p-test.c
@@ -244,6 +244,7 @@ static const char *rmessage_name(uint8_t id)
 id == P9_RATTACH ? "RATTACH" :
 id == P9_RWALK ? "RWALK" :
 id == P9_RLOPEN ? "RLOPEN" :
+id == P9_RLCREATE ? "RLCREATE" :
 "";
 }
 
@@ -423,6 +424,38 @@ static void v9fs_rlopen(P9Req *req, v9fs_qid *qid, 
uint32_t *iounit)
 v9fs_req_free(req);
 }
 
+/* size[4] Tlcreate tag[2] fid[4] name[s] flags[4] mode[4] gid[4] */
+static P9Req *v9fs_tlcreate(QVirtIO9P *v9p, uint32_t fid, const char *name,
+uint32_t flags, uint32_t mode, uint32_t gid)
+{
+P9Req *req;
+
+req = v9fs_req_init(v9p,  4 + 4 + v9fs_string_size(name) + 4 + 4 + 4,
+P9_TLCREATE, ++(v9p->p9_req_tag));
+v9fs_uint32_write(req, fid);
+v9fs_string_write(req, name);
+v9fs_uint32_write(req, flags);
+v9fs_uint32_write(req, mode);
+v9fs_uint32_write(req, gid);
+v9fs_req_send(req);
+return req;
+}
+
+/* size[4] Rlcreate tag[2] qid[13] iounit[4] */
+static void v9fs_rlcreate(P9Req *req, v9fs_qid *qid, uint32_t *iounit)
+{
+v9fs_req_recv(req, P9_RLCREATE);
+if (qid) {
+v9fs_memread(req, qid, 13);
+} else {
+v9fs_memskip(req, 13);
+}
+if (iounit) {
+v9fs_uint32_read(req, iounit);
+}
+v9fs_req_free(req);
+}
+
 static void fs_version(QVirtIO9P *v9p)
 {
 const char *version = "9P2000.L";
@@ -560,6 +593,34 @@ static void fs_lopen_fifo_not_allowed(QVirtIO9P *v9p)
 g_free(wnames[0]);
 }
 
+static void fs_lcreate(QVirtIO9P *v9p)
+{
+char *const wnames[] = { g_strdup(__func__) };
+char *path = g_strdup_printf("%s/%s", v9p->test_share, wnames[0]);
+uint32_t iounit;
+P9Req *req;
+
+fs_attach(v9p);
+/* Clone the root directory fid and open it */
+req = v9fs_twalk(v9p, 0, 1, 0, NULL);
+v9fs_rwalk(req, NULL, NULL);
+req = v9fs_tlopen(v9p, 1, O_RDWR);
+v9fs_rlopen(req, NULL, NULL);
+
+req = v9fs_tlcreate(v9p, 1, wnames[0], O_RDONLY, 0600, getgid());
+v9fs_rlcreate(req, NULL, &iounit);
+
+g_assert_cmpint(iounit, <=, P9_MAX_SIZE - P9_IOHDRSZ);
+
+/* Was the file created ? */
+req = v9fs_twalk(v9p, 0, 2, 1, wnames);
+v9fs_rwalk(req, NULL, NULL);
+
+unlink(path);
+g_free(path);
+g_free(wnames[0]);
+}
+
 typedef void (*v9fs_test_fn)(QVirtIO9P *v9p);
 
 static void v9fs_run_pci_test(gconstpointer data)
@@ -592,6 +653,7 @@ int main(int argc, char **argv)
 v9fs_qtest_pci_add("/virtio/9p/pci/fs/lopen/basic", fs_lopen);
 v9fs_qtest_pci_add("/virtio/9p/pci/fs/lopen/fifo_not_allowed",
fs_lopen_fifo_not_allowed);
+v9fs_qtest_pci_add("/virtio/9p/pci/fs/lcreate/basic", fs_lcreate);
 
 return g_test_run();
 }

Re: [Qemu-devel] [PATCH v7 00/10] Convert msix_init() to error

[Michael S. Tsirkin]

On Tue, Jan 10, 2017 at 11:06:08AM +0100, Markus Armbruster wrote:
> "Michael S. Tsirkin"  writes:
> 
> > On Mon, Nov 14, 2016 at 03:25:30PM +0800, Cao jin wrote:
> >> v7 changelog:
> >> 1. fix the segfaut bug in patch 2. So drop the all the R-b of it,
> >>please take a look, there is detailed description in the patch.
> >> 2. add the R-b from Hannes Reinecke
> >> 
> >> Test:
> >> 1. make check: pass
> >> 2. After applied all the patch, command line test for all the
> >>affected devices, just make sure device realize process is ok,
> >>no crash, but no further use of device.
> >
> > Consider the megasas device for example, don't you
> > need to test that the change actually does what
> > it's intended to do?
> 
> For better or worse, that's a higher bar than we commonly require for
> refactorings.
> 
> [...]

Well the patch says that it's addressing a TODO. If no one can
be bothered to test the functionality, maybe we shouldn't bother
with the change.

Generally this patchset is at v7.  It brings a very limited benefit to
the project.  It better be perfect otherwise I don't see why bother.

-- 
MST

Re: [Qemu-devel] [PATCH 0/3] trace: Fix event tracing during vCPU hot-unplug

[Stefan Hajnoczi]

On Mon, Dec 26, 2016 at 10:24:29PM +0100, Lluís Vilanova wrote:
> The vCPU list needs to be locked to avoid memory corruption with concurrent
> hot-(un)plugs, and per-vCPU events need to be disabled during vCPU hot-unplug.
> 
> Also adds event "guest_cpu_exit" to track vCPU hot-unplugging.
> 
> Signed-off-by: Lluís Vilanova 
> ---
> 
> 
> Lluís Vilanova (3):
>   trace: Lock vCPU list when initializing dynamic tracing state
>   trace: Fix dynamic event state on vCPU hot-unplug
>   trace: Add event "guest_cpu_exit"
> 
> 
>  qom/cpu.c  |2 ++
>  trace-events   |6 ++
>  trace/control-target.c |   11 ++-
>  trace/control.c|   19 +++
>  trace/control.h|8 
>  5 files changed, 45 insertions(+), 1 deletion(-)
> 
> 
> To: qemu-devel@nongnu.org
> Cc: Stefan Hajnoczi 

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

Stefan


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH v6 3/7] trace: [tcg] Delay changes to dynamic state when translating

[Stefan Hajnoczi]

On Wed, Dec 28, 2016 at 07:41:10PM +0100, Lluís Vilanova wrote:
> This keeps consistency across all decisions taken during translation
> when the dynamic state of a vCPU is changed in the middle of translating
> some guest code.
> 
> Signed-off-by: Lluís Vilanova 
> ---
>  cpu-exec.c |   26 ++
>  include/qom/cpu.h  |7 +++
>  qom/cpu.c  |4 
>  trace/control-target.c |   11 +--
>  4 files changed, 46 insertions(+), 2 deletions(-)
> 
> diff --git a/cpu-exec.c b/cpu-exec.c
> index 4188fed3c6..1b7366efb0 100644
> --- a/cpu-exec.c
> +++ b/cpu-exec.c
> @@ -33,6 +33,7 @@
>  #include "hw/i386/apic.h"
>  #endif
>  #include "sysemu/replay.h"
> +#include "trace/control.h"
>  
>  /* -icount align implementation. */
>  
> @@ -451,9 +452,21 @@ static inline bool cpu_handle_exception(CPUState *cpu, 
> int *ret)
>  #ifndef CONFIG_USER_ONLY
>  } else if (replay_has_exception()
> && cpu->icount_decr.u16.low + cpu->icount_extra == 0) {
> +/* delay changes to this vCPU's dstate during translation */
> +atomic_set(&cpu->trace_dstate_delayed_req, false);
> +atomic_set(&cpu->trace_dstate_must_delay, true);
> +
>  /* try to cause an exception pending in the log */
>  cpu_exec_nocache(cpu, 1, tb_find(cpu, NULL, 0), true);
>  *ret = -1;
> +
> +/* apply and disable delayed dstate changes */
> +atomic_set(&cpu->trace_dstate_must_delay, false);
> +if (unlikely(atomic_read(&cpu->trace_dstate_delayed_req))) {
> +bitmap_copy(cpu->trace_dstate, cpu->trace_dstate_delayed,
> +trace_get_vcpu_event_count());
> +}
> +
>  return true;
>  #endif
>  }
> @@ -634,8 +647,21 @@ int cpu_exec(CPUState *cpu)
>  
>  for(;;) {
>  cpu_handle_interrupt(cpu, &last_tb);
> +
> +/* delay changes to this vCPU's dstate during translation */
> +atomic_set(&cpu->trace_dstate_delayed_req, false);
> +atomic_set(&cpu->trace_dstate_must_delay, true);
> +
>  tb = tb_find(cpu, last_tb, tb_exit);
>  cpu_loop_exec_tb(cpu, tb, &last_tb, &tb_exit, &sc);
> +
> +/* apply and disable delayed dstate changes */
> +atomic_set(&cpu->trace_dstate_must_delay, false);
> +if (unlikely(atomic_read(&cpu->trace_dstate_delayed_req))) {
> +bitmap_copy(cpu->trace_dstate, cpu->trace_dstate_delayed,
> +trace_get_vcpu_event_count());
> +}
> +
>  /* Try to align the host and virtual clocks
> if the guest is in advance */
>  align_clocks(&sc, cpu);
> diff --git a/include/qom/cpu.h b/include/qom/cpu.h
> index 3f79a8e955..58255d06fa 100644
> --- a/include/qom/cpu.h
> +++ b/include/qom/cpu.h
> @@ -295,6 +295,10 @@ struct qemu_work_item;
>   * @kvm_fd: vCPU file descriptor for KVM.
>   * @work_mutex: Lock to prevent multiple access to queued_work_*.
>   * @queued_work_first: First asynchronous work pending.
> + * @trace_dstate_must_delay: Whether a change to trace_dstate must be 
> delayed.
> + * @trace_dstate_delayed_req: Whether a change to trace_dstate was delayed.
> + * @trace_dstate_delayed: Delayed changes to trace_dstate (includes all 
> changes
> + *to @trace_dstate).
>   * @trace_dstate: Dynamic tracing state of events for this vCPU (bitmask).
>   *
>   * State of one CPU core or thread.
> @@ -370,6 +374,9 @@ struct CPUState {
>   * Dynamically allocated based on bitmap requried to hold up to
>   * trace_get_vcpu_event_count() entries.
>   */
> +bool trace_dstate_must_delay;
> +bool trace_dstate_delayed_req;
> +unsigned long *trace_dstate_delayed;
>  unsigned long *trace_dstate;
>  
>  /* TODO Move common fields from CPUArchState here. */
> diff --git a/qom/cpu.c b/qom/cpu.c
> index 03d9190f8c..d56496d28d 100644
> --- a/qom/cpu.c
> +++ b/qom/cpu.c
> @@ -367,6 +367,9 @@ static void cpu_common_initfn(Object *obj)
>  QTAILQ_INIT(&cpu->breakpoints);
>  QTAILQ_INIT(&cpu->watchpoints);
>  
> +cpu->trace_dstate_must_delay = false;
> +cpu->trace_dstate_delayed_req = false;
> +cpu->trace_dstate_delayed = bitmap_new(trace_get_vcpu_event_count());
>  cpu->trace_dstate = bitmap_new(trace_get_vcpu_event_count());
>  
>  cpu_exec_initfn(cpu);
> @@ -375,6 +378,7 @@ static void cpu_common_initfn(Object *obj)
>  static void cpu_common_finalize(Object *obj)
>  {
>  CPUState *cpu = CPU(obj);
> +g_free(cpu->trace_dstate_delayed);
>  g_free(cpu->trace_dstate);
>  }
>  
> diff --git a/trace/control-target.c b/trace/control-target.c
> index 7ebf6e0bcb..aba8db55de 100644
> --- a/trace/control-target.c
> +++ b/trace/control-target.c
> @@ -69,13 +69,20 @@ void trace_event_set_vcpu_state_dynamic(CPUState *vcpu,
>  if (state_pre !=

[Qemu-devel] [PATCH 7/7] tests: virtio-9p: TLCREATE should fail if pathname exists

[Greg Kurz]

As specified in the http://man.cat-v.org/plan_9/5/open :

"An attempt to create a file in a directory where the given
name already exists will be rejected"

Signed-off-by: Greg Kurz 
---
 tests/virtio-9p-test.c |   31 +++
 1 file changed, 31 insertions(+)

diff --git a/tests/virtio-9p-test.c b/tests/virtio-9p-test.c
index 7f2ee41ca0f0..2ba321b990d3 100644
--- a/tests/virtio-9p-test.c
+++ b/tests/virtio-9p-test.c
@@ -621,6 +621,35 @@ static void fs_lcreate(QVirtIO9P *v9p)
 g_free(wnames[0]);
 }
 
+static void fs_lcreate_exclusive(QVirtIO9P *v9p)
+{
+char *const wnames[] = { g_strdup(__func__) };
+char *path = g_strdup_printf("%s/%s", v9p->test_share, wnames[0]);
+int fd;
+uint32_t err;
+P9Req *req;
+
+fd = creat(path, 0600);
+g_assert(fd >= 0);
+close(fd);
+
+fs_attach(v9p);
+/* Clone the root directory fid and open it */
+req = v9fs_twalk(v9p, 0, 1, 0, NULL);
+v9fs_rwalk(req, NULL, NULL);
+req = v9fs_tlopen(v9p, 1, O_RDWR);
+v9fs_rlopen(req, NULL, NULL);
+
+req = v9fs_tlcreate(v9p, 1, wnames[0], O_RDONLY, 0600, getgid());
+v9fs_rlerror(req, &err);
+
+g_assert_cmpint(err, ==, EEXIST);
+
+unlink(path);
+g_free(path);
+g_free(wnames[0]);
+}
+
 typedef void (*v9fs_test_fn)(QVirtIO9P *v9p);
 
 static void v9fs_run_pci_test(gconstpointer data)
@@ -654,6 +683,8 @@ int main(int argc, char **argv)
 v9fs_qtest_pci_add("/virtio/9p/pci/fs/lopen/fifo_not_allowed",
fs_lopen_fifo_not_allowed);
 v9fs_qtest_pci_add("/virtio/9p/pci/fs/lcreate/basic", fs_lcreate);
+v9fs_qtest_pci_add("/virtio/9p/pci/fs/lcreate/exclusive",
+   fs_lcreate_exclusive);
 
 return g_test_run();
 }