Re: [Qemu-block] [Qemu-devel] [PATCH 0/2] qcow2: include LUKS payload overhead in qemu-img measure

2019-01-20 Thread no-reply
Patchew URL: 
https://patchew.org/QEMU/20190115111007.27159-1-stefa...@redhat.com/



Hi,

This series failed the 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.

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

  CC  crypto/pbkdf-nettle.o
  CC  crypto/ivgen.o
/tmp/qemu-test/src/block/sheepdog.c: In function 'find_vdi_name':
/tmp/qemu-test/src/block/sheepdog.c:1239:5: error: 'strncpy' specified bound 
256 equals destination size [-Werror=stringop-truncation]
 strncpy(buf + SD_MAX_VDI_LEN, tag, SD_MAX_VDI_TAG_LEN);
 ^~
cc1: all warnings being treated as errors


The full log is available at
http://patchew.org/logs/20190115111007.27159-1-stefa...@redhat.com/testing.docker-mingw@fedora/?type=message.
---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

Re: [Qemu-block] [PATCH 0/3] nvme small fix

2019-01-20 Thread Max Reitz
On 20.01.19 06:55, Li Qiang wrote:
> This patchset contains small fix.
> 
> Change since v2:
> For patch 2:
> 1. add nvme command
> 2. check num_queues first
> 
> Change since v1: 
> 
> 1. drop the patch of checking return value of msix_init_exclusive_bar
> 2. return when nvme's num_queues configuration is 0
> 
> Li Qiang (3):
>   nvme: use TYPE_NVME instead of constant string
>   nvme: ensure the num_queues is not zero
>   nvme: use pci_dev directly in nvme_realize
> 
>  hw/block/nvme.c | 15 ++-
>  1 file changed, 10 insertions(+), 5 deletions(-)

Thanks, applied to my block branch:

https://git.xanclic.moe/XanClic/qemu/commits/branch/block

Max



signature.asc
Description: OpenPGP digital signature


Re: [Qemu-block] [PATCH v4] qemu-io: Add generic function for reinitializing optind.

2019-01-20 Thread Max Reitz
On 18.01.19 11:11, Richard W.M. Jones wrote:
> On FreeBSD 11.2:
> 
>   $ nbdkit memory size=1M --run './qemu-io -f raw -c "aio_write 0 512" $nbd'
>   Parsing error: non-numeric argument, or extraneous/unrecognized suffix -- 
> aio_write
> 
> After main option parsing, we reinitialize optind so we can parse each
> command.  However reinitializing optind to 0 does not work on FreeBSD.
> What happens when you do this is optind remains 0 after the option
> parsing loop, and the result is we try to parse argv[optind] ==
> argv[0] == "aio_write" as if it was the first parameter.
> 
> The FreeBSD manual page says:
> 
>   In order to use getopt() to evaluate multiple sets of arguments, or to
>   evaluate a single set of arguments multiple times, the variable optreset
>   must be set to 1 before the second and each additional set of calls to
>   getopt(), and the variable optind must be reinitialized.
> 
> (From the rest of the man page it is clear that optind must be
> reinitialized to 1).
> 
> The glibc man page says:
> 
>   A program that scans multiple argument vectors,  or  rescans  the  same
>   vector  more than once, and wants to make use of GNU extensions such as
>   '+' and '-' at  the  start  of  optstring,  or  changes  the  value  of
>   POSIXLY_CORRECT  between scans, must reinitialize getopt() by resetting
>   optind to 0, rather than the traditional value of 1.  (Resetting  to  0
>   forces  the  invocation  of  an  internal  initialization  routine that
>   rechecks POSIXLY_CORRECT and checks for GNU extensions in optstring.)
> 
> This commit introduces an OS-portability function called
> qemu_reset_optind which provides a way of resetting optind that works
> on FreeBSD and platforms that use optreset, while keeping it the same
> as now on other platforms.
> 
> Note that the qemu codebase sets optind in many other places, but in
> those other places it's setting a local variable and not using getopt.
> This change is only needed in places where we are using getopt and the
> associated global variable optind.
> 
> Signed-off-by: Richard W.M. Jones 
> ---
>  configure| 14 ++
>  include/qemu/osdep.h | 16 
>  qemu-img.c   |  2 +-
>  qemu-io-cmds.c   |  2 +-
>  4 files changed, 32 insertions(+), 2 deletions(-)
> 
> diff --git a/configure b/configure
> index 3eee3fcf70..3d46df1517 100755

(I'm not quite sure where along the way just using a weak optreset was
discarded, but, oh well, this does make the code less ugly.)

[...]

> diff --git a/include/qemu/osdep.h b/include/qemu/osdep.h
> index 80df7253db..840af09cb0 100644
> --- a/include/qemu/osdep.h
> +++ b/include/qemu/osdep.h
> @@ -109,6 +109,7 @@ extern int daemon(int, int);
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -604,4 +605,19 @@ extern int qemu_icache_linesize_log;
>  extern int qemu_dcache_linesize;
>  extern int qemu_dcache_linesize_log;
>  
> +/*
> + * After using getopt or getopt_long, if you need to parse another set
> + * of options, then you must reset optind.  Unfortunately the way to
> + * do this varies between implementations of getopt.
> + */
> +static inline void qemu_reset_optind(void)
> +{
> +#ifdef HAVE_OPTRESET
> +optind = 1;
> +optreset = 1;
> +#else
> +optind = 0;

So I take it this is supposed to always do a hard reset -- because if it
isn't, it might have been better to just always set optind = 1 as Eric
suggested.  But googling suggests OpenBSD and NetBSD both have optreset
as well, and newlib accepts optind = 0 (and apparently did not accept
optind = 1 in the past?), so I think this is good for that purpose.


So thanks a lot (and sorry about me being so stupid about
everything...), I've applied the patch to my block branch:

https://git.xanclic.moe/XanClic/qemu/commits/branch/block

Max

> +#endif
> +}
> +
>  #endif



signature.asc
Description: OpenPGP digital signature


Re: [Qemu-block] qemu-img info ran at 100% CPU for 45 minutes without writing a byte (stopped it)

2019-01-20 Thread Max Reitz
On 18.01.19 16:25, Alberto Garcia wrote:
> On Wed 16 Jan 2019 02:15:24 AM CET, james harvey wrote:
> 
>> I ran:
>>
>> # qemu-img convert /var/lib/libvirt/images/win7.qcow2 -O raw
>> /mnt/tmpqcow/win7.raw
>>
>> 45 minutes later, qemu-img had been running with 100% CPU every time I
>> checked, and it had allocated the raw file, but still hadn't actually
>> written a single byte: (note the dd in the VM completed the 90GB in
>> about 8 minutes)
> 
> [...]
> 
>> After running this long, I ran strace for 15 seconds, here:
>> https://termbin.com/gg9k -- It's repeatedly running lseek with
>> SEEK_DATA and SEEK_HOLE.  The SEEK_HOLE always results in 96251936768,
>> and SEEK_DATA is different results.
> 
> It seems like the problem addressed by this patch:
> 
>https://lists.gnu.org/archive/html/qemu-block/2019-01/msg00246.html

But that patch is rather controversial.

I don't think we've found a definitive solution for this issue yet
(other than the fact that tmpfs is basically just buggy (is I think what
we've claimed), and I think this is not the first time it was reported
for btrfs either).  I had some patches specifically for qemu-img
convert, too, but the issue there was that conversion of preallocated
qcow2 images on non-buggy filesystems got slower.  So we somehow have to
resolve that tradeoff...

Max



signature.asc
Description: OpenPGP digital signature


Re: [Qemu-block] [PATCH v4 00/21] nbd: add qemu-nbd --list

2019-01-20 Thread Richard W.M. Jones
On Sat, Jan 19, 2019 at 11:39:41AM +, Richard W.M. Jones wrote:
> 
> Attached is a NON-working patch to nbdkit-partitioning-plugin which
> adds logical partition support.  I don't think I've fully understood
> how the EBR fields are supposed to be initialized (or else they don't
> work how is described in online documentation).  This actually causes
> parted to print an internal error, while fdisk gives a warning and the
> size of the logical partition is wrong.
> 
> Anyway I've run out of time to work on it this weekend, but I may be
> able to have another look next week.

Sheesh.  Apparently the type byte in the link field must
be the extended partition type byte (eg. 0x5 or 0xf), NOT
the type of the next partition.

This fixes it:

$ git diff
diff --git a/plugins/partitioning/partition-mbr.c 
b/plugins/partitioning/partition-mbr.c
index 6f76432..6b256d1 100644
--- a/plugins/partitioning/partition-mbr.c
+++ b/plugins/partitioning/partition-mbr.c
@@ -129,7 +129,7 @@ create_mbr_layout (void)
  */
 region.start = enext->start - eptr0->start;
 region.len = rnext->end - enext->start + 1;
-create_mbr_partition_table_entry (, false, files[i+1].mbr_id,
+create_mbr_partition_table_entry (, false, 0xf,
   [i-3][0x1ce]);
   }
 }


I'll try to come up with a better patch with tests etc.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org