migrate_rdma_pin_all() and qsb_clone() are completely unused and thus
can be deleted.
Signed-off-by: NThomas Huth <thuth@linux.vnet.ibm.com>
Cc: Juan Quintela <quintela@redhat.com>
Cc: Amit Shah <amit.shah@redhat.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>

Signed-off-by: NStefan Berger <stefanb@linux.vnet.ibm.com>
Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>

Only free qsb that qemu_bufopen allocated, and also allow
qemu_bufopen accept qsb as input for write operation. It
will make the API more logical:
1.If you create the QEMUSizedBuffer yourself, you need to
  free it by using qsb_free() but not depends on other API
  like qemu_fclose.
2.allow qemu_bufopen() accept QEMUSizedBuffer as input for
  write operation, otherwise, it will be a little strange
  for this API won't accept the second parameter.

This brings API change, since there are only 3
users of this API currently, this change only impact the
first one which will be fixed in patch 2 of this patchset,
so I think it is safe to do this change.

1     70  tests/test-vmstate.c <<open_mem_file_read>>
            return qemu_bufopen("r", qsb);
2    404  tests/test-vmstate.c <<test_save_noskip>>
            QEMUFile *fsave = qemu_bufopen("w", NULL);
3    424  tests/test-vmstate.c <<test_save_skip>>
            QEMUFile *fsave = qemu_bufopen("w", NULL);
Signed-off-by: NYang Hongyang <yanghy@cn.fujitsu.com>
Cc: Dr. David Alan Gilbert <dgilbert@redhat.com>
Cc: Juan Quintela <quintela@redhat.com>
Cc: Amit Shah <amit.shah@redhat.com>
Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: NAmit Shah <amit.shah@redhat.com>

The splitting of qemu-file and addition of the buffered file landed
at the same time; so now split the buffered file code out.
Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: NAmit Shah <amit.shah@redhat.com>

Now we've got multiple QEMUFile source files, some of them need
access to things that were defined in qemu-file.c, so create
a -internal header for them.
Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: NAmit Shah <amit.shah@redhat.com>

The migration code now occupies a fair chunk of the top level .c
files, it seems time to give it it's own directory.

I've not touched:
   arch_init.c - that's mostly RAM migration but has a few random other
                 bits
   savevm.c    - because it's built target specific

This is purely a code move; no code has changed.
   - it fails checkpatch because of old violations, it feels safer
     to keep this as purely a move and fix those at some mythical future
     date.

The xbzrle and vmstate tests are now only run for softmmu builds
since they require files in the migrate/ directory which is only built
for softmmu.
Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: NAmit Shah <amit.shah@redhat.com>

Separate the QEMUFile interface from the stdio-specific implementation,
to reduce dependencies from code using QEMUFile.

The code that is being moved is similar to the one that was on savevm.c before
it was moved in commit 093c455a, except for
some changes done by Markus, Juan, and myself. So, I am using the copyright and
license header from savevm.c, but CCing Juan and Markus so they can review the
copyright/license header.

Cc: Markus Armbruster <armbru@redhat.com>
Cc: Juan Quintela <quintela@redhat.com>
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>

Separate the QEMUFile interface from the implementation, to reduce
dependencies from code using QEMUFile.

All the code that is being moved to the new file is exactly the same
code that was on savevm.c (moved by commit
093c455a), so I am using the copyright
and license header from savevm.c for the new file.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>

Use the existing function which checks if writev_buffer() or
put_buffer() are set, instead of duplicating it.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>

The QEMUFileStdio code will use qemu_file_is_writable() and will be
moved to a separate file.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>

The person who created qemu-file.c (me, on commit
093c455a) didn't add a copyright/license
header to the file, even though the whole code was copied from savevm.c
(which had a copyright/license header).

To correct this, copy the copyright information and license from
savevm.c, that's where the original code came from.

Luckily, very few changes were made on qemu-file.c after it was created.
All the authors who touched the code are being CCed, so they can confirm
if they are OK with the copyright/license information being added.

Cc: Dr. David Alan Gilbert <dgilbert@redhat.com>
Cc: Alexey Kardashevskiy <aik@ozlabs.ru>
Cc: Markus Armbruster <armbru@redhat.com>
Cc: Juan Quintela <quintela@redhat.com>
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Acked-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: NJuan Quintela <quintela@redhat.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>

This is based on Stefan and Joel's patch that creates a QEMUFile that goes
to a memory buffer; from:

http://lists.gnu.org/archive/html/qemu-devel/2013-03/msg05036.html

Using the QEMUFile interface, this patch adds support functions for
operating on in-memory sized buffers that can be written to or read from.
Signed-off-by: NStefan Berger <stefanb@linux.vnet.ibm.com>
Signed-off-by: NJoel Schopp <jschopp@linux.vnet.ibm.com>

For fixes/tweeks I've done:
Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>

Make qemu_peek_buffer repeatedly call fill_buffer until it gets
all the data it requires, or until there is an error.

  At the moment, qemu_peek_buffer will try one qemu_fill_buffer if there
  isn't enough data waiting, however the kernel is entitled to return
  just a few bytes, and still leave qemu_peek_buffer with less bytes
  than it needed.  I've seen this fail in a dev world, and I think it
  could theoretically fail in the peeking of the subsection headers in
  the current world.

Comment qemu_peek_byte to point out it's not guaranteed to work for
  non-continuous peeks
Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: NChenLiang <chenliang0016@icloud.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>

This replaces DPRINTF macro with tracepoints.

This moves some messages from migration.c to savevm.c.

This adds tracepoint to signal about fileds failed to migrate.
Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: NJuan Quintela <quintela@redhat.com>
Signed-off-by: NAmit Shah <amit.shah@redhat.com>

Reviewers accepted v2 of the patch, but what got committed was v1,
with the R-bys for v2.  This is the v1->v2 followup fix.

[Amit:
 This fixes commit aded6539
]
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>

fwrite() returns the number of items written.  But when there is one
error, it can return a short write.

In the particular bug that I was tracking, I did a migration to a
read-only filesystem.  And it was able to finish the migration
correctly.  fwrite() never returned a negative error code, nor zero,
always 4096. (migration writes chunks of about 14000 bytes).  And it
was able to "complete" the migration with success (yes, reading the
file was a bit more difficult).

To add insult to injury, if your amount of memory was big enough (12GB
on my case), it overwrote some important structure, and from them,
malloc failed.  This check makes the problem go away.
Signed-off-by: NJuan Quintela <quintela@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>

Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Reviewed-by: NOrit Wasserman <owasserm@redhat.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>