Re: [Qemu-devel] [PATCH v4 3/4] migration: disallow migrate_add_blocker during migration
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
> 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
** 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
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
* 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
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
** 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
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
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
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
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
"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
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
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
* 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
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
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
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
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
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
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
* 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
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
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
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
* 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
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
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
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
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
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
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
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
* 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
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
> 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
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
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
* 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
> > > > > > > > > > > > > > > > > > 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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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(); }