gwj / at91sam9263 · Commits

  • kill drives_table ...
    751c6a17 
    First step cleaning up the drives handling.  This one does nothing but
removing drives_table[], still it became seriously big.

drive_get_index() is gone and is replaced by drives_get() which hands
out DriveInfo pointers instead of a table index.  This needs adaption in
*tons* of places all over.

The drives are now maintained as linked list.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
    Gerd Hoffmann authored
     
    Browse Code »
  • fix segfault in setting migration speed ...
    0bb05eaf 
    Hi,

Whoever wrote this migrate_set_speed function is totally stupid.

Any failed or completed migration keeps its state to allow probing of
migration data, but has no associated file anymore. It is, thus,
possible to crash qemu by calling migrate_set_speed after a migration
is finished (or failed, or cancelled), but before another one starts.

This patch fixes it.

Signed-off-by: Glauber Costa <glommer@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
    Glauber Costa authored
     
    Browse Code »
  • replace bdrv_{get, put}_buffer with bdrv_{load, save}_vmstate ...
    45566e9c 
    The VM state offset is a concept internal to the image format.  Replace
the old bdrv_{get,put}_buffer method that require an index into the
image file that is constructed from the VM state offset and an offset
into the vmstate with the bdrv_{load,save}_vmstate that just take an
offset into the VM state.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
    Christoph Hellwig authored
     
    Browse Code »
  • Allow monitor interaction when using migrate -exec ...
    8a43b1ea 
    All,
     I've recently been playing around with migration via exec.  Unfortunately,
when starting the incoming qemu process with "-incoming exec:cmd", it suffers
the same problem that -incoming tcp used to suffer; namely, that you can't
interact with the monitor until after the migration has happened.  This causes
problems for libvirt usage of -incoming exec, since libvirt expects to be able
to access the monitor ahead of time.  This fairly simple patch allows you to
access the monitor both before and after the migration has completed using exec.

(note: developed/tested with qemu-kvm, but applies perfectly fine to qemu)

Signed-off-by: Chris Lalancette <clalance@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
    Chris Lalancette authored
     
    Browse File »
  • monitor: Rework API (Jan Kiszka) ...
    376253ec 
    Refactor the monitor API and prepare it for decoupled terminals:
term_print functions are renamed to monitor_* and all monitor services
gain a new parameter (mon) that will once refer to the monitor instance
the output is supposed to appear on. However, the argument remains
unused for now. All monitor command callbacks are also extended by a mon
parameter so that command handlers are able to pass an appropriate
reference to monitor output services.

For the case that monitor outputs so far happen without clearly
identifiable context, the global variable cur_mon is introduced that
shall once provide a pointer either to the current active monitor (while
processing commands) or to the default one. On the mid or long term,
those use case will be obsoleted so that this variable can be removed
again.

Due to the broad usage of the monitor interface, this patch mostly deals
with converting users of the monitor API. A few of them are already
extended to pass 'mon' from the command handler further down to internal
functions that invoke monitor_printf.

At this chance, monitor-related prototypes are moved from console.h to
a new monitor.h. The same is done for the readline API.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>


git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6711 c046a42c-6fe2-441c-8c8c-71466251a162
    aliguori authored
     
    Browse Code »
  • Fix handling of disk-only snapshots (Kevin Wolf) ...
    2d22b18f 
    When creating a snapshot with multiple qcow2 disks attached, the current
behaviour is that qemu creates a disk snapshot on all of them and
chooses one to write the VM state to.

Despite having the state only in one image, loadvm tries to restore the
VM state from the middle of nowhere if you run qemu a second time with
only one of the other images attached. In the lucky case it will fail
because there simply is no state, but it also can happen that it loads
the state of a different snapshot (the one this new one is based upon).

The fix is to write a zero VM state size to the images which don't
contain the state, and check this in loadvm.

I agree that you probably have to provoke such things intentionally to
get in a state like this with qemu itself. However, with my second patch
that adds snapshot support to qemu-img it could become a reasonable use
case to have snapshots with and without VM states on the same image.

Signed-off-by: Kevin Wolf <kwolf@suse.de>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>



git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@5985 c046a42c-6fe2-441c-8c8c-71466251a162
    aliguori authored
     
    Browse Code »