test-visitor-serialization: Fix some memory leaks

This patch fixes some of the memory leaks in test-visitor-serialization but not all of them.

Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
linux-user: Don't omit comma for strace of rt_sigaction()

Pass the 'last' parameter of print_signal() through to
print_raw_param(); this fixes a problem where we weren't printing
the comma separator for strace of rt_sigaction() when the signal
was an unnamed (ie realtime) one:
  6856 rt_sigaction(230xf6fff870,0xf6fff8fc) = 0

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
qstring: add qstring_get_length()

Long overdue.

Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Monitor: Make output buffer dynamic

Commit f628926bb423fa8a7e0b114511400ea9df38b76a changed monitor_flush()
to retry on qemu_chr_fe_write() errors. However, the Monitor's output
buffer can keep growing while the retry is not issued and this can
cause the buffer to overflow.

To reproduce this issue, just start qemu and type on the Monitor:

(qemu) ?

This will cause an assertion to trig.

To fix this problem this commit makes the Monitor buffer dynamic,
which means that it can grow as much as needed.

Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
hmp: human-monitor-command: stop using the Memory chardev driver

The Memory chardev driver was added because, as the Monitor's output
buffer was static, we needed a way to accumulate the output of an
HMP commmand when ran by human-monitor-command.

However, the Monitor's output buffer is now dynamic, so it's possible
for the human-monitor-command to use it instead of the Memory chardev
driver.

This commit does that change, but there are two important
observations about it:

 1. We need a way to signal to the Monitor that it shouldn't call
    chardev functions when flushing its output. This is done
    by adding a new flag to the Monitor object called skip_flush
	(which is set to true by qmp_human_monitor_command())

 2. The current code has buffered semantics: QMP clients will
    only see a command's output if it flushes its output with
	a new-line character. This commit changes this to unbuffered,
	which means that QMP clients will see a command's output
	whenever the command prints anything.

	I don't think this will matter in practice though, as I believe
	all HMP commands print the new-line character anyway.

Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
chardev: drop the Memory chardev driver

It's not used anymore since the last commit.

Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
target-s390: Fix SRNMT

Fallthough into abort = oops.

Cc: qemu-trivial@nongnu.org
Cc: Alexander Graf <agraf@suse.de>
Signed-off-by: Richard Henderson <rth@twiddle.net>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
petalogix_ml605_mmu: Cleanup ssi_create_slave()

With the recent m25p80 cleanup there is no need to use
ssi_create_slave_no_init() anymore. Just use ssi_create_slave().

Signed-off-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
xilinx_zynq: Cleanup ssi_create_slave

With the recent m25p80 cleanup there is no need to use
ssi_create_slave_no_init() anymore. Just use ssi_create_slave().

Signed-off-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Merge remote-tracking branch 'luiz/queue/qmp' into staging

# By Luiz Capitulino
# Via Luiz Capitulino
* luiz/queue/qmp:
  chardev: drop the Memory chardev driver
  hmp: human-monitor-command: stop using the Memory chardev driver
  Monitor: Make output buffer dynamic
  qstring: add qstring_get_length()
Xen PV backend: Move call to bdrv_new from blk_init to blk_connect

This commit delays the point at which bdrv_new (and hence blk_open
on the underlying device) is called from blk_init to blk_connect.
This ensures that in an inbound live migrate, the block device is
not opened until it has been closed at the other end. This is in
preparation for supporting devices with open/close consistency
without using O_DIRECT. This commit does NOT itself change O_DIRECT
semantics.

Signed-off-by: Alex Bligh <alex@alex.org.uk>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Xen PV backend: Disable use of O_DIRECT by default as it results in crashes.

Due to what is almost certainly a kernel bug, writes with O_DIRECT may
continue to reference the page after the write has been marked as
completed, particularly in the case of TCP retransmit. In other
scenarios, this "merely" risks data corruption on the write, but with
Xen pages from domU are only transiently mapped into dom0's memory,
resulting in kernel panics when they are subsequently accessed.

This brings PV devices in line with emulated devices.  Removing
O_DIRECT is safe as barrier operations are now correctly passed
through.

See:
   http://lists.xen.org/archives/html/xen-devel/2012-12/msg01154.html
for more details.

Signed-off-by: Alex Bligh <alex@alex.org.uk>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Introduce 64 bit integer write interface to xenstore

The current implementation of xen_backend only provides 32 bit integer
functions to write to xenstore. This patch adds two functions that
allow writing 64 bit integers (one generic function and another for
the backend only).

This patch also fixes the size of the char arrays used to represent
these integers as strings (originally 32 bytes, however no more than
12 bytes are needed for 32 bit integers and no more than 21 bytes are
needed for 64 bit integers).

Signed-off-by: Felipe Franciosi <felipe@paradoxo.org>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Allow xen guests to plug disks of 1 TiB or more

The current xen backend driver implementation uses int64_t variables
to store the size of the corresponding backend disk/file. It also uses
an int64_t variable to store the block size of that image. When writing
the number of sectors (file_size/block_size) to xenstore, however, it
passes these values as 32 bit signed integers. This will cause an
overflow for any disk of 1 TiB or more.

This patch changes the xen backend driver to use a 64 bit integer write
xenstore function.

Signed-off-by: Felipe Franciosi <felipe@paradoxo.org>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
usb-storage: Forward serial number to scsi-disk

usb-storage takes care to fetch the USB serial number from -drive
options, but it neglected to pass its own 'serial' property to the
scsi-disk it creates. With this patch, the 'serial' qdev property and
the 'serial' option in -drive behave the same and correctly apply the
serial number on both USB and SCSI level.

Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
block: fix I/O throttling accounting blind spot

I/O throttling relies on bdrv_acct_done() which is called when a request
completes.  This leaves a blind spot since we only charge for completed
requests, not submitted requests.

For example, if there is 1 operation remaining in this time slice the
guest could submit 3 operations and they will all be submitted
successfully since they don't actually get accounted for until they
complete.

Originally we probably thought this is okay since the requests will be
accounted when the time slice is extended.  In practice it causes
fluctuations since the guest can exceed its I/O limit and it will be
punished for this later on.

Account for I/O upon submission so that I/O limits are enforced
properly.

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Tested-By: Benoit Canet <benoit@irqsave.net>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
block: keep I/O throttling slice time constant

It is not necessary to adjust the slice time at runtime.  We already
extend the current slice in order to carry over accounting into the next
slice.  Changing the actual slice time value introduces oscillations.

The guest may experience large changes in throughput or IOPS from one
moment to the next when slice times are adjusted.

Reported-by: Benoît Canet <benoit@irqsave.net>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Tested-By: Benoit Canet <benoit@irqsave.net>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
block: drop duplicated slice extension code

The current slice is extended when an I/O request exceeds the limit.
There is no need to extend the slice every time we check a request.

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Tested-By: Benoit Canet <benoit@irqsave.net>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
block: clean up I/O throttling wait_time code

The wait_time variable is in seconds.  Reflect this in a comment and use
NANOSECONDS_PER_SECOND instead of BLOCK_IO_SLICE_TIME * 10 (which
happens to have the right value).

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Tested-By: Benoit Canet <benoit@irqsave.net>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
qcow2: Return real error in qcow2_update_snapshot_refcount

This fixes the error message triggered by the following script:

    cat > /tmp/blkdebug.cfg <<EOF
    [inject-error]
    event = "cluster_free"
    errno = "28"
    immediately = "off"
    EOF

    $qemu_img create -f qcow2 test.qcow2 10G
    $qemu_img snapshot -c snap test.qcow2
    $qemu_img snapshot -d snap blkdebug:/tmp/blkdebug.cfg:test.qcow2

Signed-off-by: Kevin Wolf <kwolf@redhat.com>