qemu-char: Rename opened to be_open

Rename the opened variable to be_open to reflect that it contains the
opened state of the backend.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Message-id: 1364292483-16564-2-git-send-email-hdegoede@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
qemu-char: Rename qemu_chr_generic_open to qemu_chr_be_generic_open

To better reflect that it is for handling a backend being opened.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Message-id: 1364292483-16564-3-git-send-email-hdegoede@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
qemu-char: Add fe_open tracking

Add tracking of the fe_open state to struct CharDriverState.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Message-id: 1364292483-16564-4-git-send-email-hdegoede@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
qemu-char: Automatically do fe_open / fe_close on qemu_chr_add_handlers

Most frontends can't really determine if the guest actually has the frontend
side open. So lets automatically generate fe_open / fe_close as soon as a
frontend becomes ready (as signalled by calling qemu_chr_add_handlers) /
becomes non ready (as signalled by setting all handlers to NULL).

And allow frontends which can actually determine if the guest is listening to
opt-out of this.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Message-id: 1364292483-16564-5-git-send-email-hdegoede@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
qemu-char: Cleanup: consolidate fe_open/fe_close into fe_set_open

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Message-id: 1364292483-16564-6-git-send-email-hdegoede@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
qemu-char: Consolidate guest_close/guest_open into a set_fe_open callback

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Message-id: 1364292483-16564-7-git-send-email-hdegoede@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
qemu-char: Move incrementing of avail_connections to qdev-properties-system

The decrement of avail_connections is done in qdev-properties-system move
the increment there too for proper balancing of the calls.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Message-id: 1364292483-16564-8-git-send-email-hdegoede@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
qemu-char: add_handlers: Don't re-send the be_open event on unregister

Resending the be_open event only is useful when a frontend is registering, not
when it is unregistering.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Message-id: 1364292483-16564-9-git-send-email-hdegoede@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
virtio-serial: Consolidate guest_open/guest_close into set_guest_connected

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Message-id: 1364292483-16564-10-git-send-email-hdegoede@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
virtio-serial: propagate guest_connected to the port on post_load

When migrating a host with with a spice agent running the mouse becomes
non operational after the migration due to the agent state being
inconsistent between the guest and the client.

After migration the spicevmc backend on the destination has never been notified
of the (non 0) guest_connected state. Virtio-serial holds this state
information and migrates it, this patch properly propagates this information
to virtio-console and through that to interested chardev backends.

rhbz #725965

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Message-id: 1364292483-16564-11-git-send-email-hdegoede@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
spice-qemu-char: Drop hackish vmc_register on spice_chr_write

Now that the core takes care of fe_open tracking we no longer need this hack.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Message-id: 1364292483-16564-12-git-send-email-hdegoede@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
configure: show debug-info option in --help output

"--enable-debug-info" and "--disable-debug-info" were not shown
in --help output.

Signed-off-by: Dunrong Huang <huangdr@cloud-times.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
hw/i386/pc: format load_linux function

Signed-off-by: liguang <lig.fnst@cn.fujitsu.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
hw/tcx: Remove unused 'addr' field and the property that sets it

Remove the 'addr' field from TCXState (since it is completely unused),
also the qdev property which sets it. This seems to be a relic from
many years past; devices don't need to know where they are mapped.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
vl.c: call bdrv_init_with_whitelist() before cmdline parsing

commit 4d454574 "qemu-option: move standard option definitions
out of qemu-config.c" broke support for commandline option
groups that where registered during bdrv_init(). In particular
support for -iscsi options was broken since that commit.

Fix by moving the bdrv_init_with_whitelist() before command
line argument parsing.

Signed-off-by: Peter Lieven <pl@kamp.de>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
qemu-iotests: More concurrent allocation scenarios

Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
qcow2: Fix "total clusters" number in bdrv_check

This should be based on the virtual disk size, not on the size of the
image.

Interesting observation: With some VM state stored in the image file,
percentages higher than 100% are possible, even though snapshots
themselves are ignored. This is a qcow2 bug to be fixed another day: The
VM state should be discarded in the active L2 tables after completing
the snapshot creation.

Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
qcow2: Remove bogus unlock of s->lock

The unlock wakes up the next coroutine, but the currently running
coroutine will lock it again before it yields, so this doesn't make a
lot of sense.

Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
qcow2: Handle dependencies earlier

Handling overlapping allocations isn't just a detail of cluster
allocation. It is rather one of three ways to get the host cluster
offset for a write request:

1. If a request overlaps an in-flight allocations, the cluster offset
   can be taken from there (this is what handle_dependencies will evolve
   into) or the request must just wait until the allocation has
   completed. Accessing the L2 is not valid in this case, it has
   outdated information.

2. Outside overlapping areas, check the clusters that can be written to
   as they are, with no COW involved.

3. If a COW is required, allocate new clusters

Changing the code to reflect this doesn't change the behaviour because
overlaps cannot exist for clusters that are kept in step 2. It does
however make it easier for later patches to work on clusters that belong
to an allocation that is still in flight.

Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
qcow2: Improve check for overlapping allocations

The old code detected an overlapping allocation even when the
allocations didn't actually overlap, but were only adjacent.

Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>