Re: [Qemu-devel] [PATCH v3 2/7] qapi: correctly parse uint64_t values from strings

2018-11-03 Thread David Gibson
On Wed, Oct 31, 2018 at 06:18:33PM +0100, David Hildenbrand wrote:
> On 31.10.18 15:32, Markus Armbruster wrote:
> > David Hildenbrand  writes:
> > 
> >> Right now, we parse uint64_t values just like int64_t values, resulting
> >> in negative values getting accepted and certain valid large numbers only
> >> being representable as negative numbers. Also, reported errors indicate
> >> that an int64_t is expected.
> >>
> >> Parse uin64_t separately. We don't have to worry about ranges.
> > 
> > The commit message should mention *why* we don't we have to worry about
> > ranges.
> 
> "Parse uin64_t separately. We don't have to worry about ranges as far as
> I can see. Ranges are parsed and processed via start_list()/next_list()
> and friends. parse_type_int64() only has to deal with ranges as it
> reuses the function parse_str(). E.g. parse_type_size() also does not
> have to handle ranges. (I assume that we could easily reimplement
> parse_type_int64() in a similar fashion, too).
> 
> The only thing that will change is that uint64_t properties that didn't
> expect a range will now actually bail out if a range is supplied."
> 
> I'll do some more testing.
> 
> > 
> >>
> >> E.g. we can now also specify
> >> -device nvdimm,memdev=mem1,id=nv1,addr=0xC000
> >> Instead of only going via negative values
> >> -device nvdimm,memdev=mem1,id=nv1,addr=-0x4000
> >>
> >> Resulting in the same values
> >>
> >> (qemu) info memory-devices
> >> Memory device [nvdimm]: "nv1"
> >>   addr: 0xc000
> >>   slot: 0
> >>   node: 0
> >>
> > 
> > Suggest to mention this makes the string-input-visitor catch up with the
> > qobject-input-visitor, which got changed similarly in commit
> > 5923f85fb82.
> 
> Yes, I will add that!
> 
> > 
> >> Signed-off-by: David Hildenbrand 
> >> ---
> >>  qapi/string-input-visitor.c | 17 +
> >>  1 file changed, 9 insertions(+), 8 deletions(-)
> >>
> >> diff --git a/qapi/string-input-visitor.c b/qapi/string-input-visitor.c
> >> index c1454f999f..f2df027325 100644
> >> --- a/qapi/string-input-visitor.c
> >> +++ b/qapi/string-input-visitor.c
> >> @@ -247,15 +247,16 @@ error:
> >>  static void parse_type_uint64(Visitor *v, const char *name, uint64_t *obj,
> >>Error **errp)
> >>  {
> >> -/* FIXME: parse_type_int64 mishandles values over INT64_MAX */
> >> -int64_t i;
> >> -Error *err = NULL;
> >> -parse_type_int64(v, name, , );
> >> -if (err) {
> >> -error_propagate(errp, err);
> >> -} else {
> >> -*obj = i;
> >> +StringInputVisitor *siv = to_siv(v);
> >> +uint64_t val;
> >> +
> >> +if (qemu_strtou64(siv->string, NULL, 0, )) {
> > 
> > Works because qemu_strtou64() accepts negative numbers and interprets
> > them modulo 2^64.
> 
> I will also add a comment to the description that negative numbers will
> continue to work.
> 
> > 
> >> +error_setg(errp, QERR_INVALID_PARAMETER_VALUE, name ? name : 
> >> "null",
> >> +   "an uint64 value");
> > 
> > I think this should be "a uint64 value".
> 
> As I am not a native speaker, I will stick to your suggestion unless
> somebody else speaks up.

I am a native speaker and "a uint64 value" sounds better to me.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature


Re: [Qemu-devel] [PATCH v2] ppc/pnv: check size before data buffer access

2018-11-03 Thread David Gibson
On Fri, Oct 26, 2018 at 06:03:58PM +0530, P J P wrote:
> From: Prasad J Pandit 
> 
> While performing PowerNV memory r/w operations, the access length
> 'sz' could exceed the data[4] buffer size. Add check to avoid OOB
> access.
> 
> Reported-by: Moguofang 
> Signed-off-by: Prasad J Pandit 

Applied to ppc-for-3.1, thanks.

> ---
>  hw/ppc/pnv_lpc.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> Update v2: add error log message
>   -> https://lists.gnu.org/archive/html/qemu-devel/2018-10/msg05750.html
> 
> diff --git a/hw/ppc/pnv_lpc.c b/hw/ppc/pnv_lpc.c
> index d7721320a2..172a915cfc 100644
> --- a/hw/ppc/pnv_lpc.c
> +++ b/hw/ppc/pnv_lpc.c
> @@ -155,9 +155,15 @@ static void pnv_lpc_do_eccb(PnvLpcController *lpc, 
> uint64_t cmd)
>  /* XXX Check for magic bits at the top, addr size etc... */
>  unsigned int sz = (cmd & ECCB_CTL_SZ_MASK) >> ECCB_CTL_SZ_LSH;
>  uint32_t opb_addr = cmd & ECCB_CTL_ADDR_MASK;
> -uint8_t data[4];
> +uint8_t data[8];
>  bool success;
>  
> +if (sz > sizeof(data)) {
> +qemu_log_mask(LOG_GUEST_ERROR,
> +"ECCB: invalid operation at @0x%08x size %d\n", opb_addr, sz);
> +return;
> +}
> +
>  if (cmd & ECCB_CTL_READ) {
>  success = opb_read(lpc, opb_addr, data, sz);
>  if (success) {

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature


Re: [Qemu-devel] [PATCH] softfloat: don't execute ppc64 ISA 3.0B instruction if it is not supported

2018-11-03 Thread David Gibson
On Thu, Nov 01, 2018 at 06:54:59PM +0100, Laurent Vivier wrote:
> On 01/11/2018 18:49, Peter Maydell wrote:
> > On 1 November 2018 at 17:38, Laurent Vivier  wrote:
> >> commit 27ae5109a2 has introduced an assembly instruction only supported
> >> by ISA 3.0B and it fails to execute on previous versions of the POWER
> >> CPU (like PowerPC G5).
> >>
> >> This patch fixes that by checking the ISA level, and falls back to
> >> the default C function if the instruction is not supported.
> >>
> >> Fixes: 27ae5109a2ba8b6b679cce3e03e16570a34390a0
> >>(softfloat: Specialize udiv_qrnnd for ppc64)
> >> Signed-off-by: Laurent Vivier 
> >> ---
> >>  include/fpu/softfloat-macros.h | 39 --
> >>  1 file changed, 23 insertions(+), 16 deletions(-)
> >>
> >> diff --git a/include/fpu/softfloat-macros.h 
> >> b/include/fpu/softfloat-macros.h
> >> index c86687fa5e..fe98b33df9 100644
> >> --- a/include/fpu/softfloat-macros.h
> >> +++ b/include/fpu/softfloat-macros.h
> >> @@ -78,6 +78,9 @@ this code that are retained.
> >>  /* Portions of this work are licensed under the terms of the GNU GPL,
> >>   * version 2 or later. See the COPYING file in the top-level directory.
> >>   */
> >> +#if defined(_ARCH_PPC64)
> >> +extern bool have_isa_3_00;
> >> +#endif
> > 
> > I was wondering where this bool came from. The answer is
> > that it's defined in tcg/ppc/tcg-target.inc.c. It's ok to
> > use it here because fpu/softfloat.c is only compiled if
> > CONFIG_TCG is true, so the tcg code will be present. The
> > other user of this include file is target/m68k/softfloat.c,
> > which also will only be compiled for a ppc host if CONFIG_TCG.
> > 
> > It's a little awkward to be borrowing this tcg/ppc internal
> > flag into the softfloat code, though.
> 
> I agree, I was hopping Richard can advice another way to do that.

We already have ISA version flags in insns_flags & insns_flags2, so
I'm hoping we can use those rather than introduce a new bool.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature


Re: [Qemu-devel] [PATCH] target/ppc: fix mtmsr instruction for icount

2018-11-03 Thread David Gibson
On Tue, Oct 30, 2018 at 12:30:31PM +0300, Pavel Dovgalyuk wrote:
> This patch fixes processing of mtmsr instructions in icount mode.
> In this mode writing to interrupt/peripheral state is controlled
> by can_do_io flag. This flag must be set explicitly before helper
> function invocation.
> 
> Signed-off-by: Maria Klimushenkova 
> Signed-off-by: Pavel Dovgalyuk 

Applied to ppc-for-3.1, thanks.

> ---
>  target/ppc/translate.c |   12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/target/ppc/translate.c b/target/ppc/translate.c
> index 4e59dd5..987ce6e 100644
> --- a/target/ppc/translate.c
> +++ b/target/ppc/translate.c
> @@ -4257,11 +4257,17 @@ static void gen_mtmsrd(DisasContext *ctx)
>   *  if we enter power saving mode, we will exit the loop
>   *  directly from ppc_store_msr
>   */
> +if (tb_cflags(ctx->base.tb) & CF_USE_ICOUNT) {
> +gen_io_start();
> +}
>  gen_update_nip(ctx, ctx->base.pc_next);
>  gen_helper_store_msr(cpu_env, cpu_gpr[rS(ctx->opcode)]);
>  /* Must stop the translation as machine state (may have) changed */
>  /* Note that mtmsr is not always defined as context-synchronizing */
>  gen_stop_exception(ctx);
> +if (tb_cflags(ctx->base.tb) & CF_USE_ICOUNT) {
> +gen_io_end();
> +}
>  }
>  #endif /* !defined(CONFIG_USER_ONLY) */
>  }
> @@ -4286,6 +4292,9 @@ static void gen_mtmsr(DisasContext *ctx)
>   *  if we enter power saving mode, we will exit the loop
>   *  directly from ppc_store_msr
>   */
> +if (tb_cflags(ctx->base.tb) & CF_USE_ICOUNT) {
> +gen_io_start();
> +}
>  gen_update_nip(ctx, ctx->base.pc_next);
>  #if defined(TARGET_PPC64)
>  tcg_gen_deposit_tl(msr, cpu_msr, cpu_gpr[rS(ctx->opcode)], 0, 32);
> @@ -4293,6 +4302,9 @@ static void gen_mtmsr(DisasContext *ctx)
>  tcg_gen_mov_tl(msr, cpu_gpr[rS(ctx->opcode)]);
>  #endif
>  gen_helper_store_msr(cpu_env, msr);
> +if (tb_cflags(ctx->base.tb) & CF_USE_ICOUNT) {
> +gen_io_end();
> +}
>  tcg_temp_free(msr);
>  /* Must stop the translation as machine state (may have) changed */
>  /* Note that mtmsr is not always defined as context-synchronizing */
> 

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature


Re: [Qemu-devel] [PATCH for-3.1] hw/ppc/mac_newworld: Free openpic_irqs array after use

2018-11-03 Thread David Gibson
On Thu, Nov 01, 2018 at 04:17:58PM +, Peter Maydell wrote:
> In ppc_core99_init(), we allocate an openpic_irqs array, which
> we then use to collect up the various qemu_irqs which we're
> going to connect to the interrupt controller. Once we've
> called sysbus_connect_irq() to connect them all up, the
> array is no longer required, but we forgot to free it.
> 
> Since board init is only run once at startup, the memory
> leak is not a significant one.
> 
> Spotted by Coverity: CID 1192916.
> 
> Signed-off-by: Peter Maydell 

Applied, thanks.

> ---
>  hw/ppc/mac_newworld.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c
> index a630cb81cd8..14273a123e5 100644
> --- a/hw/ppc/mac_newworld.c
> +++ b/hw/ppc/mac_newworld.c
> @@ -303,6 +303,7 @@ static void ppc_core99_init(MachineState *machine)
>  sysbus_connect_irq(s, k++, openpic_irqs[i][j]);
>  }
>  }
> +g_free(openpic_irqs);
>  
>  if (PPC_INPUT(env) == PPC_FLAGS_INPUT_970) {
>  /* 970 gets a U3 bus */

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature


Re: [Qemu-devel] [PATCH for 3.2 v2 0/7] hw/arm/bcm2835: Add basic support for cprman (clock subsystem)

2018-11-03 Thread no-reply
Hi,

This series failed docker-mingw@fedora build test. Please find the testing 
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.

Type: series
Message-id: 20181102001303.32640-1-f4...@amsat.org
Subject: [Qemu-devel] [PATCH for 3.2 v2 0/7] hw/arm/bcm2835: Add basic support 
for cprman (clock subsystem)

=== TEST SCRIPT BEGIN ===
#!/bin/bash
time make docker-test-mingw@fedora SHOW_ENV=1 J=8
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
1997ee7b3b MAINTAINERS: Volunteer to review Raspi patches
5bd4f0ff52 hw/arm/bcm2835: Add basic support for cprman (clock subsystem)
5bb2c51372 hw/arm/bcm2835: Add various unimplemented peripherals
57d232cc31 hw/arm/bcm2835: Rename some definitions
242c2f27ba hw/arm/bcm2835: Use 0x prefix for hex numbers
2316d66248 hw/misc/bcm2835_property: Handle the 'domain state' property
0b73d8ca51 MAINTAINERS: Add an entry for the Raspberry Pi machines

=== OUTPUT BEGIN ===
  BUILD   fedora
make[1]: Entering directory '/var/tmp/patchew-tester-tmp-ujg3tlbv/src'
  GEN 
/var/tmp/patchew-tester-tmp-ujg3tlbv/src/docker-src.2018-11-03-11.31.40.16898/qemu.tar
Cloning into 
'/var/tmp/patchew-tester-tmp-ujg3tlbv/src/docker-src.2018-11-03-11.31.40.16898/qemu.tar.vroot'...
done.
Checking out files:   9% (640/6448)   
Checking out files:  10% (645/6448)   
Checking out files:  11% (710/6448)   
Checking out files:  12% (774/6448)   
Checking out files:  13% (839/6448)   
Checking out files:  14% (903/6448)   
Checking out files:  14% (955/6448)   
Checking out files:  15% (968/6448)   
Checking out files:  16% (1032/6448)   
Checking out files:  17% (1097/6448)   
Checking out files:  18% (1161/6448)   
Checking out files:  19% (1226/6448)   
Checking out files:  19% (1278/6448)   
Checking out files:  20% (1290/6448)   
Checking out files:  21% (1355/6448)   
Checking out files:  22% (1419/6448)   
Checking out files:  23% (1484/6448)   
Checking out files:  24% (1548/6448)   
Checking out files:  25% (1612/6448)   
Checking out files:  26% (1677/6448)   
Checking out files:  27% (1741/6448)   
Checking out files:  28% (1806/6448)   
Checking out files:  29% (1870/6448)   
Checking out files:  30% (1935/6448)   
Checking out files:  31% (1999/6448)   
Checking out files:  32% (2064/6448)   
Checking out files:  33% (2128/6448)   
Checking out files:  34% (2193/6448)   
Checking out files:  35% (2257/6448)   
Checking out files:  36% (2322/6448)   
Checking out files:  37% (2386/6448)   
Checking out files:  38% (2451/6448)   
Checking out files:  39% (2515/6448)   
Checking out files:  39% (2555/6448)   
Checking out files:  40% (2580/6448)   
Checking out files:  41% (2644/6448)   
Checking out files:  42% (2709/6448)   
Checking out files:  43% (2773/6448)   
Checking out files:  44% (2838/6448)   
Checking out files:  45% (2902/6448)   
Checking out files:  46% (2967/6448)   
Checking out files:  47% (3031/6448)   
Checking out files:  48% (3096/6448)   
Checking out files:  49% (3160/6448)   
Checking out files:  50% (3224/6448)   
Checking out files:  51% (3289/6448)   
Checking out files:  52% (3353/6448)   
Checking out files:  53% (3418/6448)   
Checking out files:  54% (3482/6448)   
Checking out files:  55% (3547/6448)   
Checking out files:  56% (3611/6448)   
Checking out files:  57% (3676/6448)   
Checking out files:  58% (3740/6448)   
Checking out files:  59% (3805/6448)   
Checking out files:  60% (3869/6448)   
Checking out files:  61% (3934/6448)   
Checking out files:  62% (3998/6448)   
Checking out files:  63% (4063/6448)   
Checking out files:  64% (4127/6448)   
Checking out files:  65% (4192/6448)   
Checking out files:  66% (4256/6448)   
Checking out files:  67% (4321/6448)   
Checking out files:  68% (4385/6448)   
Checking out files:  69% (4450/6448)   
Checking out files:  70% (4514/6448)   
Checking out files:  71% (4579/6448)   
Checking out files:  72% (4643/6448)   
Checking out files:  73% (4708/6448)   
Checking out files:  74% (4772/6448)   
Checking out files:  75% (4836/6448)   
Checking out files:  76% (4901/6448)   
Checking out files:  77% (4965/6448)   
Checking out files:  78% (5030/6448)   
Checking out files:  79% (5094/6448)   
Checking out files:  80% (5159/6448)   
Checking out files:  81% (5223/6448)   
Checking out files:  82% (5288/6448)   
Checking out files:  83% (5352/6448)   
Checking out files:  84% (5417/6448)   
Checking out files:  85% (5481/6448)   
Checking out files:  86% (5546/6448)   
Checking out files:  87% (5610/6448)   
Checking out files:  88% (5675/6448)   
Checking out files:  89% (5739/6448)   
Checking out files:  90% (5804/6448)   
Checking out files:  91% (5868/6448)   
Checking out files:  92% (5933/6448)   
Checking out files:  93% (5997/6448)   
Checking out files:  94% (6062/6448)   
Checking out files:  95% (6126/6448)   
Checking out files:  96% (6191/6448)   
Checking out files:  97% (6255/6448)   

Re: [Qemu-devel] [PATCH 0/3] Performance improvements for xen_disk

2018-11-03 Thread no-reply
Hi,

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

Type: series
Message-id: 
154115098499.664.15585399091081300567.st...@dhcp-3-135.uk.xensource.com
Subject: [Qemu-devel] [PATCH 0/3] Performance improvements for xen_disk

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

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

git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram

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
Switched to a new branch 'test'
c6a893c90e Avoid repeated memory allocation in xen_disk
d6c377c588 Improve xen_disk response latency
d60360a117 Improve xen_disk batching behaviour

=== OUTPUT BEGIN ===
Checking PATCH 1/3: Improve xen_disk batching behaviour...
WARNING: line over 80 characters
#60: FILE: hw/block/xen_disk.c:607:
+if (inflight_atstart > IO_PLUG_THRESHOLD && batched >= 
inflight_atstart) {

ERROR: spaces required around that '=' (ctx:VxV)
#67: FILE: hw/block/xen_disk.c:614:
+batched=0;
^

total: 1 errors, 1 warnings, 54 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.

Checking PATCH 2/3: Improve xen_disk response latency...
Checking PATCH 3/3: Avoid repeated memory allocation in xen_disk...
WARNING: line over 80 characters
#36: FILE: hw/block/xen_disk.c:139:
+/* We cannot need more pages per ioreq than this, and we do re-use 
ioreqs,

ERROR: line over 90 characters
#39: FILE: hw/block/xen_disk.c:142:
+ioreq->buf = qemu_memalign(XC_PAGE_SIZE, 
BLKIF_MAX_SEGMENTS_PER_REQUEST * XC_PAGE_SIZE);

total: 1 errors, 1 warnings, 50 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...@redhat.com

Re: [Qemu-devel] [PATCH RFC v7 0/9] qemu_thread_create: propagate errors to callers to check

2018-11-03 Thread no-reply
Hi,

This series failed docker-quick@centos7 build test. Please find the testing 
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.

Type: series
Message-id: 20181101101715.9443-1-...@suse.com
Subject: [Qemu-devel] [PATCH RFC v7 0/9] qemu_thread_create: propagate errors 
to callers to check

=== TEST SCRIPT BEGIN ===
#!/bin/bash
time make docker-test-quick@centos7 SHOW_ENV=1 J=8
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
8239f692a6 qemu_thread_create: propagate the error to callers to handle
f73c91c32a migration: add more error handling for postcopy_ram_enable_notify
6b8c9d0a7b migration: remove unused _err parameter in migrate_set_error
adcb648e2e migration: fix the multifd code when receiving less channels
ce89d9baf9 migration: fix the multifd code when sending less channels
a06e512206 migration: fix some segmentation faults when using multifd
7f516dc786 qemu_thread_join: fix segmentation fault
a6f6f24ff3 qemu_init_vcpu: add a new Error parameter to propagate
b44013aa26 Fix segmentation fault when qemu_signal_init fails

=== OUTPUT BEGIN ===
  BUILD   centos7
make[1]: Entering directory '/var/tmp/patchew-tester-tmp-6f6bzbwa/src'
  GEN 
/var/tmp/patchew-tester-tmp-6f6bzbwa/src/docker-src.2018-11-03-14.07.14.17130/qemu.tar
Cloning into 
'/var/tmp/patchew-tester-tmp-6f6bzbwa/src/docker-src.2018-11-03-14.07.14.17130/qemu.tar.vroot'...
done.
Your branch is up-to-date with 'origin/test'.
Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc'
Cloning into 
'/var/tmp/patchew-tester-tmp-6f6bzbwa/src/docker-src.2018-11-03-14.07.14.17130/qemu.tar.vroot/dtc'...
Submodule path 'dtc': checked out '88f18909db731a627456f26d779445f84e449536'
Submodule 'ui/keycodemapdb' (git://git.qemu.org/keycodemapdb.git) registered 
for path 'ui/keycodemapdb'
Cloning into 
'/var/tmp/patchew-tester-tmp-6f6bzbwa/src/docker-src.2018-11-03-14.07.14.17130/qemu.tar.vroot/ui/keycodemapdb'...
Submodule path 'ui/keycodemapdb': checked out 
'6b3d716e2b6472eb7189d3220552280ef3d832ce'
  COPYRUNNER
RUN test-quick in qemu:centos7 
Packages installed:
SDL-devel-1.2.15-14.el7.x86_64
bison-3.0.4-1.el7.x86_64
bzip2-1.0.6-13.el7.x86_64
bzip2-devel-1.0.6-13.el7.x86_64
ccache-3.3.4-1.el7.x86_64
csnappy-devel-0-6.20150729gitd7bc683.el7.x86_64
flex-2.5.37-3.el7.x86_64
gcc-4.8.5-28.el7_5.1.x86_64
gettext-0.19.8.1-2.el7.x86_64
git-1.8.3.1-14.el7_5.x86_64
glib2-devel-2.54.2-2.el7.x86_64
libaio-devel-0.3.109-13.el7.x86_64
libepoxy-devel-1.3.1-2.el7_5.x86_64
libfdt-devel-1.4.6-1.el7.x86_64
lzo-devel-2.06-8.el7.x86_64
make-3.82-23.el7.x86_64
mesa-libEGL-devel-17.2.3-8.20171019.el7.x86_64
mesa-libgbm-devel-17.2.3-8.20171019.el7.x86_64
nettle-devel-2.7.1-8.el7.x86_64
package g++ is not installed
package librdmacm-devel is not installed
pixman-devel-0.34.0-1.el7.x86_64
spice-glib-devel-0.34-3.el7_5.1.x86_64
spice-server-devel-0.14.0-2.el7_5.4.x86_64
tar-1.26-34.el7.x86_64
vte-devel-0.28.2-10.el7.x86_64
xen-devel-4.6.6-12.el7.x86_64
zlib-devel-1.2.7-17.el7.x86_64

Environment variables:
PACKAGES=bison bzip2 bzip2-devel ccache csnappy-devel flex  
   g++ gcc gettext git glib2-devel libaio-devel 
libepoxy-devel libfdt-devel librdmacm-devel lzo-devel make 
mesa-libEGL-devel mesa-libgbm-devel nettle-devel pixman-devel 
SDL-devel spice-glib-devel spice-server-devel tar vte-devel 
xen-devel zlib-devel
HOSTNAME=ec6a074d2e2d
MAKEFLAGS= -j8
J=8
CCACHE_DIR=/var/tmp/ccache
EXTRA_CONFIGURE_OPTS=
V=
SHOW_ENV=1
PATH=/usr/lib/ccache:/usr/lib64/ccache:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PWD=/
TARGET_LIST=
SHLVL=1
HOME=/home/patchew
TEST_DIR=/tmp/qemu-test
FEATURES= dtc
DEBUG=
_=/usr/bin/env

Configure options:
--enable-werror --target-list=x86_64-softmmu,aarch64-softmmu 
--prefix=/tmp/qemu-test/install
No C++ compiler available; disabling C++ specific optional code
Install prefix/tmp/qemu-test/install
BIOS directory/tmp/qemu-test/install/share/qemu
firmware path /tmp/qemu-test/install/share/qemu-firmware
binary directory  /tmp/qemu-test/install/bin
library directory /tmp/qemu-test/install/lib
module directory  /tmp/qemu-test/install/lib/qemu
libexec directory /tmp/qemu-test/install/libexec
include directory /tmp/qemu-test/install/include
config directory  /tmp/qemu-test/install/etc
local state directory   /tmp/qemu-test/install/var
Manual directory  /tmp/qemu-test/install/share/man
ELF interp prefix /usr/gnemul/qemu-%M
Source path   /tmp/qemu-test/src
GIT binarygit
GIT submodules
C compilercc
Host C compiler   cc
C++ compiler  
Objective-C compiler cc
ARFLAGS   rv
CFLAGS-O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g 
QEMU_CFLAGS   -I/usr/include/pixman-1-Werror   -pthread 
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include   -fPIE -DPIE 

Re: [Qemu-devel] How to emulate block I/O timeout on qemu side?

2018-11-03 Thread Dongli Zhang
Hi all,

I tried with the patch at:

https://lists.gnu.org/archive/html/qemu-devel/2018-09/msg00394.html

The patch is applied to qemu-3.0.0.


Below configuration is used to test the feature for guest VM nvme.

# qemu-system-x86_64 \
-smp 4 -m 2000M -enable-kvm -vnc :0 -monitor stdio \
-net nic -net user,hostfwd=tcp::5022-:22 \
-drive file=virtio-disk.img,format=raw,if=none,id=disk0 \
-device virtio-blk-pci,drive=disk0,id=disk0-dev,num-queues=2,iothread=io1 \
-object iothread,id=io1 \
-device nvme,drive=nvme1,serial=deadbeaf1 \
-drive file=blkdebug:blkdebug.config:nvme.img,if=none,id=nvme1

# cat blkdebug.config
[delay]
event = "write_aio"
latency = "99"
sector = "40960"


The 'write' latency of sector=40960 is set to a very large value. When the I/O
is stalled in guest due to that sector=40960 is accessed, I do see below
messages in guest log:

[   80.807755] nvme nvme0: I/O 11 QID 2 timeout, aborting
[   80.808095] nvme nvme0: Abort status: 0x4001


However, then nothing happens further. nvme I/O hangs in guest. I am not able to
kill the qemu process with Ctrl+C. Both vnc and qemu user net do not work. I
need to kill qemu with "kill -9"


The same result for virtio-scsi and qemu is stuck as well.


About blkdebug, I can only trigger the error by the config file. Is there a way
to inject error or latency via qemu monior? For instance, I would like to inject
error not for a specific sector or state, but for the entire disk when I input
some command via qemu monitor.

Dongli Zhang


On 11/03/2018 02:17 AM, John Snow wrote:
> 
> 
> On 11/02/2018 01:55 PM, Marc Olson wrote:
>> On 11/2/18 10:49 AM, John Snow wrote:
>>> On 11/02/2018 04:11 AM, Dongli Zhang wrote:
 Hi,

 Is there any way to emulate I/O timeout on qemu side (not fault
 injection in VM
 kernel) without modifying qemu source code?

 For instance, I would like to observe/study/debug the I/O timeout
 handling of
 nvme, scsi, virtio-blk (not supported) of VM kernel.

 Is there a way to trigger this on purpose on qemu side?

 Thank you very much!

 Dongli Zhang

>>> I don't think the blkdebug driver supports arbitrary delays right now.
>>> Maybe we could augment it to do so?
>>>
>>> (I thought someone already had, but maybe it wasn't merged?)
>>>
>>> Aha, here:
>>>
>>> https://lists.gnu.org/archive/html/qemu-devel/2018-08/msg05297.html
>>> V2: https://lists.gnu.org/archive/html/qemu-devel/2018-09/msg00394.html
>>>
>>> Let's work from there.
>>
>> I've got updates to that patch series that fell on the floor due to
>> other competing things. I'll get some screen time this weekend to work
>> on them and submit v3.
>>
>> /marc
>>
> 
> Great! Please CC the usual maintainers, but also include me.
> 
> In the meantime, Dongli Zhang, why don't you try the v2 patch and see if
> that helps you out for your use case? Report back if it works for you or
> not.
> 
> --js
> 



[Qemu-devel] [PATCH] hw: virtio-pci: drop DO_UPCAST

2018-11-03 Thread Li Qiang
Use VIRTIO_PCI MACRO instead.

Signed-off-by: Li Qiang 
---
 hw/virtio/virtio-pci.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index a954799267..277dc20c81 100644
--- a/hw/virtio/virtio-pci.c
+++ b/hw/virtio/virtio-pci.c
@@ -597,7 +597,7 @@ virtio_address_space_read(VirtIOPCIProxy *proxy, hwaddr 
addr,
 static void virtio_write_config(PCIDevice *pci_dev, uint32_t address,
 uint32_t val, int len)
 {
-VirtIOPCIProxy *proxy = DO_UPCAST(VirtIOPCIProxy, pci_dev, pci_dev);
+VirtIOPCIProxy *proxy = VIRTIO_PCI(pci_dev);
 VirtIODevice *vdev = virtio_bus_get_device(>bus);
 struct virtio_pci_cfg_cap *cfg;
 
@@ -630,7 +630,7 @@ static void virtio_write_config(PCIDevice *pci_dev, 
uint32_t address,
 static uint32_t virtio_read_config(PCIDevice *pci_dev,
uint32_t address, int len)
 {
-VirtIOPCIProxy *proxy = DO_UPCAST(VirtIOPCIProxy, pci_dev, pci_dev);
+VirtIOPCIProxy *proxy = VIRTIO_PCI(pci_dev);
 struct virtio_pci_cfg_cap *cfg;
 
 if (proxy->config_cap &&
-- 
2.17.1





[Qemu-devel] [PATCH] qga-win: fix leaks of build_guest_disk_info()

2018-11-03 Thread Marc-André Lureau
Introduced in commit b1ba8890e63ce9432c41c5c3fc229f54c87c9c99, vol_h
handle should be closed, and "out" cleanup should be done after
DeviceIoControl() fails.

Signed-off-by: Marc-André Lureau 
---
 qga/commands-win32.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/qga/commands-win32.c b/qga/commands-win32.c
index ef1d7d48d2..62e1b51dfe 100644
--- a/qga/commands-win32.c
+++ b/qga/commands-win32.c
@@ -797,7 +797,7 @@ static GuestDiskAddressList *build_guest_disk_info(char 
*guid, Error **errp)
 0, extents, size, NULL, NULL)) {
 error_setg_win32(errp, GetLastError(),
 "failed to get disk extents");
-return NULL;
+goto out;
 }
 } else if (last_err == ERROR_INVALID_FUNCTION) {
 /* Possibly CD-ROM or a shared drive. Try to pass the volume */
@@ -855,6 +855,9 @@ static GuestDiskAddressList *build_guest_disk_info(char 
*guid, Error **errp)
 
 
 out:
+if (vol_h != INVALID_HANDLE_VALUE) {
+CloseHandle(vol_h);
+}
 qapi_free_GuestDiskAddress(disk);
 g_free(extents);
 g_free(name);
-- 
2.19.1.708.g4ede3d42df




Re: [Qemu-devel] [PATCH v2 0/5] target/arm: KVM vs ARMISARegisters

2018-11-03 Thread Marc Zyngier
On Sat, 3 Nov 2018 09:53:44 +
Richard Henderson  wrote:

Hi Richard,

> Although, while I have you, Christopher, is there a way to extract the Limited
> Ordering Region registers without modifying guest state?  Those are 
> multiplexed
> with LORN_EL1.

We actively hide the LORegion feature from the guest since
cc33c4e20185a391766ed5e78e2acc97e17ba511 (in the 4.17 time frame), so
you shouldn't be able to obtain these on a recent host.

I'm not sure this answers your question though...

Thanks,

M.
-- 
Without deviation from the norm, progress is not possible.



Re: [Qemu-devel] [PATCH v2 0/5] target/arm: KVM vs ARMISARegisters

2018-11-03 Thread Richard Henderson
On 11/2/18 7:35 PM, Christoffer Dall wrote:
>> It looks like the kernel can handle reads of ID_ISAR0_EL1
>> through ID_ISAR5_EL1, but not ID_ISAR6_EL1, any of the
>> MVFR*_EL1 or ID_AA64_ISAR* or ID_AA64PFR*.
>>
>> This is probably because the kernel is way too old to be
>> interestingly supportable for KVM, but we did previously
>> manage to boot on this setup.
> 
> I'm a little confused. v4.8 used to work (although it was perhaps not
> the most stable at that time).  What changed?

We are changing QEMU to depend on ID registers to define the set of features
that are supported, instead of re-defining those same features with the
ARM_FEATURE_* enumeration.

For KVM, there are only a few of those that are important in the end: those
that affect migration.  However, it seemed to me to be most future-proof if I
just read in all of the relevant ID registers so that should a code path shared
between TCG and KVM test a field, we get the right value.

Which appeared to work, since I was using a 4.15 kernel.  But I hadn't imagined
that such support had only just appeared.

> 93390c0a1b20 (arm64: KVM: Hide unsupported AArch64 CPU features from guests, 
> 2017-10-31)
> 
> Which Dave (cc'ed) wrote and which was introduced in v4.15.
> 
> As per my question above, I'm not exactly sure what (if anything) we
> need to fix on the kernel side?

It doesn't sound like there's anything in the kernel that needs fixing.  But it
does sound like we need a workaround in userspace to deal with old kernels.

Peter, what about filling in some defaults via MIDR and friends, using the
values we have from the TCG side.  Then overwriting that default with the
registers that we can read from the kernel.  Ignore ENOENT failures and just
leave the default.

There are currently only two features that affect migration, and so must not be
approximated: T2EE and SVE.  The former is in ID_ISAR3, which is in the set
that is supported by 4.8.  The latter you were never going to run on a kernel
that old anyway.

Although, while I have you, Christopher, is there a way to extract the Limited
Ordering Region registers without modifying guest state?  Those are multiplexed
with LORN_EL1.


r~



Re: [Qemu-devel] [PATCH v3] arm: exynos4: Add dma support for smdkc210

2018-11-03 Thread no-reply
Hi,

This series failed docker-quick@centos7 build test. Please find the testing 
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.

Type: series
Message-id: 20181030193044.25954-1-phi...@redhat.com
Subject: [Qemu-devel] [PATCH v3] arm: exynos4: Add dma support for smdkc210

=== TEST SCRIPT BEGIN ===
#!/bin/bash
time make docker-test-quick@centos7 SHOW_ENV=1 J=8
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
14ee4f7b29 arm: exynos4: Add dma support for smdkc210

=== OUTPUT BEGIN ===
  BUILD   centos7
make[1]: Entering directory '/var/tmp/patchew-tester-tmp-nkyzug17/src'
  GEN 
/var/tmp/patchew-tester-tmp-nkyzug17/src/docker-src.2018-11-03-05.30.16.12281/qemu.tar
Cloning into 
'/var/tmp/patchew-tester-tmp-nkyzug17/src/docker-src.2018-11-03-05.30.16.12281/qemu.tar.vroot'...
done.
Your branch is up-to-date with 'origin/test'.
Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc'
Cloning into 
'/var/tmp/patchew-tester-tmp-nkyzug17/src/docker-src.2018-11-03-05.30.16.12281/qemu.tar.vroot/dtc'...
Submodule path 'dtc': checked out '88f18909db731a627456f26d779445f84e449536'
Submodule 'ui/keycodemapdb' (git://git.qemu.org/keycodemapdb.git) registered 
for path 'ui/keycodemapdb'
Cloning into 
'/var/tmp/patchew-tester-tmp-nkyzug17/src/docker-src.2018-11-03-05.30.16.12281/qemu.tar.vroot/ui/keycodemapdb'...
Submodule path 'ui/keycodemapdb': checked out 
'6b3d716e2b6472eb7189d3220552280ef3d832ce'
  COPYRUNNER
RUN test-quick in qemu:centos7 
Packages installed:
SDL-devel-1.2.15-14.el7.x86_64
bison-3.0.4-1.el7.x86_64
bzip2-1.0.6-13.el7.x86_64
bzip2-devel-1.0.6-13.el7.x86_64
ccache-3.3.4-1.el7.x86_64
csnappy-devel-0-6.20150729gitd7bc683.el7.x86_64
flex-2.5.37-3.el7.x86_64
gcc-4.8.5-28.el7_5.1.x86_64
gettext-0.19.8.1-2.el7.x86_64
git-1.8.3.1-14.el7_5.x86_64
glib2-devel-2.54.2-2.el7.x86_64
libaio-devel-0.3.109-13.el7.x86_64
libepoxy-devel-1.3.1-2.el7_5.x86_64
libfdt-devel-1.4.6-1.el7.x86_64
lzo-devel-2.06-8.el7.x86_64
make-3.82-23.el7.x86_64
mesa-libEGL-devel-17.2.3-8.20171019.el7.x86_64
mesa-libgbm-devel-17.2.3-8.20171019.el7.x86_64
nettle-devel-2.7.1-8.el7.x86_64
package g++ is not installed
package librdmacm-devel is not installed
pixman-devel-0.34.0-1.el7.x86_64
spice-glib-devel-0.34-3.el7_5.1.x86_64
spice-server-devel-0.14.0-2.el7_5.4.x86_64
tar-1.26-34.el7.x86_64
vte-devel-0.28.2-10.el7.x86_64
xen-devel-4.6.6-12.el7.x86_64
zlib-devel-1.2.7-17.el7.x86_64

Environment variables:
PACKAGES=bison bzip2 bzip2-devel ccache csnappy-devel flex  
   g++ gcc gettext git glib2-devel libaio-devel 
libepoxy-devel libfdt-devel librdmacm-devel lzo-devel make 
mesa-libEGL-devel mesa-libgbm-devel nettle-devel pixman-devel 
SDL-devel spice-glib-devel spice-server-devel tar vte-devel 
xen-devel zlib-devel
HOSTNAME=5ef2a2d6f48a
MAKEFLAGS= -j8
J=8
CCACHE_DIR=/var/tmp/ccache
EXTRA_CONFIGURE_OPTS=
V=
SHOW_ENV=1
PATH=/usr/lib/ccache:/usr/lib64/ccache:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PWD=/
TARGET_LIST=
SHLVL=1
HOME=/home/patchew
TEST_DIR=/tmp/qemu-test
FEATURES= dtc
DEBUG=
_=/usr/bin/env

Configure options:
--enable-werror --target-list=x86_64-softmmu,aarch64-softmmu 
--prefix=/tmp/qemu-test/install
No C++ compiler available; disabling C++ specific optional code
Install prefix/tmp/qemu-test/install
BIOS directory/tmp/qemu-test/install/share/qemu
firmware path /tmp/qemu-test/install/share/qemu-firmware
binary directory  /tmp/qemu-test/install/bin
library directory /tmp/qemu-test/install/lib
module directory  /tmp/qemu-test/install/lib/qemu
libexec directory /tmp/qemu-test/install/libexec
include directory /tmp/qemu-test/install/include
config directory  /tmp/qemu-test/install/etc
local state directory   /tmp/qemu-test/install/var
Manual directory  /tmp/qemu-test/install/share/man
ELF interp prefix /usr/gnemul/qemu-%M
Source path   /tmp/qemu-test/src
GIT binarygit
GIT submodules
C compilercc
Host C compiler   cc
C++ compiler  
Objective-C compiler cc
ARFLAGS   rv
CFLAGS-O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g 
QEMU_CFLAGS   -I/usr/include/pixman-1-Werror   -pthread 
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include   -fPIE -DPIE -m64 -mcx16 
-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes 
-Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes 
-fno-strict-aliasing -fno-common -fwrapv  -Wendif-labels 
-Wno-missing-include-dirs -Wempty-body -Wnested-externs -Wformat-security 
-Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration 
-Wold-style-definition -Wtype-limits -fstack-protector-strong 
-Wno-missing-braces   -I/usr/include/libpng15 -pthread 
-I/usr/include/spice-server -I/usr/include/cacard -I/usr/include/glib-2.0 

Re: [Qemu-devel] [PULL 0/2] Misc next patches

2018-11-03 Thread no-reply
Hi,

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

Type: series
Message-id: 20181031113651.32430-1-berra...@redhat.com
Subject: [Qemu-devel] [PULL 0/2] Misc next patches

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

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

git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram

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
Switched to a new branch 'test'
4ba8b05f47 Merge remote-tracking branch 
'remotes/berrange/tags/misc-next-pull-request' into staging
79c328c135 scripts: report on author emails that are mangled by the mailing list
790a9af84d block: drop moderated sheepdog mailing list from MAINTAINERS file

=== OUTPUT BEGIN ===
Checking PATCH 1/3: block: drop moderated sheepdog mailing list from 
MAINTAINERS file...
Checking PATCH 2/3: scripts: report on author emails that are mangled by the 
mailing list...
WARNING: line over 80 characters
#36: FILE: scripts/checkpatch.pl:1405:
+   if ($line =~ /^Author: .*via 
Qemu-devel.*/) {

ERROR: line over 90 characters
#37: FILE: scripts/checkpatch.pl:1406:
+   ERROR("Author email address is mangled by the mailing 
list\n" . $herecurr);

total: 1 errors, 1 warnings, 10 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.

Checking PATCH 3/3: Merge remote-tracking branch 
'remotes/berrange/tags/misc-next-pull-request' into staging...
=== OUTPUT END ===

Test command exited with code: 1


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