summary refs log tree commit diff stats
path: root/migration/qemu-file.h (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* | migration: Add error_desc for file channel errorsYury Kotov2019-08-141-5/+10
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, there is no information about error if outgoing migration was failed because of file channel errors. Example (QMP session): -> { "execute": "migrate", "arguments": { "uri": "exec:head -c 1" }} <- { "return": {} } ... -> { "execute": "query-migrate" } <- { "return": { "status": "failed" }} // There is not error's description And even in the QEMU's output there is nothing. This patch 1) Adds errp for the most of QEMUFileOps 2) Adds qemu_file_get_error_obj/qemu_file_set_error_obj 3) And finally using of qemu_file_get_error_obj in migration.c And now, the status for the mentioned fail will be: -> { "execute": "query-migrate" } <- { "return": { "status": "failed", "error-desc": "Unable to write to command: Broken pipe" }} Signed-off-by: Yury Kotov <yury-kotov@yandex-team.ru> Message-Id: <20190422103420.15686-1-yury-kotov@yandex-team.ru> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
* slirp: use libslirp migration codeMarc-André Lureau2019-03-071-1/+0
| | | | | | | | | | | | | | | | | slirp migration code uses QEMU vmstate so far, when building WITH_QEMU. Introduce slirp_state_{load,save,version}() functions to move the state saving handling to libslirp side. So far, the bitstream compatibility should remain equal with current QEMU, as this is effectively using the same code, with the same format etc. When libslirp is made standalone, we will need some mechanism to ensure bitstream compatibility regardless of the libslirp version installed. See the FIXME note in the code. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20190212162524.31504-3-marcandre.lureau@redhat.com> Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
* migration: stop compression to allocate and free memory frequentlyXiao Guangrong2018-04-251-2/+4
| | | | | | | | | | | | | | | | | | | | Current code uses compress2() to compress memory which manages memory internally, that causes huge memory is allocated and freed very frequently More worse, frequently returning memory to kernel will flush TLBs and trigger invalidation callbacks on mmu-notification which interacts with KVM MMU, that dramatically reduce the performance of VM So, we maintain the memory by ourselves and reuse it for each compression Reviewed-by: Peter Xu <peterx@redhat.com> Reviewed-by: Jiang Biao <jiang.biao2@zte.com.cn> Signed-off-by: Xiao Guangrong <xiaoguangrong@tencent.com> Message-Id: <20180330075128.26919-3-xiaoguangrong@tencent.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
* migration/qemu-file: add qemu_put_counted_string()Vladimir Sementsov-Ogievskiy2018-03-131-0/+2
| | | | | | | | | | | | | Add function opposite to qemu_get_counted_string. qemu_put_counted_string puts one-byte length of the string (string should not be longer than 255 characters), and then it puts the string, without last zero byte. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: John Snow <jsnow@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Fam Zheng <famz@redhat.com> Message-id: 20180313180320.339796-9-vsementsov@virtuozzo.com
* migration: ram_control_* are implemented in qemu_fileJuan Quintela2017-06-131-0/+17
| | | | | | Signed-off-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Laurent Vivier <lvivier@redhat.com>
* migration: Split qemu-file.hJuan Quintela2017-06-011-0/+160
Split the file into public and internal interfaces. I have to rename the external one because we can't have two include files with the same name in the same directory. Build system gets confused. The only exported functions are the ones that handle basic types. Signed-off-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>