Resizing the xbzrle cache during migration causes qemu-crash,
because the main-thread and migration-thread modify the xbzrle
cache size concurrently without lock-protection.
Signed-off-by: NChenLiang <chenliang88@huawei.com>
Signed-off-by: NGonglei <arei.gonglei@huawei.com>
Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>

Push zero'd pages into the XBZRLE cache
    A page that was cached by XBZRLE, zero'd and then XBZRLE'd again
    was being compared against a stale cache value

Don't use 'qemu_put_buffer_async' to put pages from the XBZRLE cache
    Since the cache might change before the data hits the wire
Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>

It is better to fail migration in case of failure to
allocate new cache item
Signed-off-by: NOrit Wasserman <owasserm@redhat.com>
Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>

Signed-off-by: NOrit Wasserman <owasserm@redhat.com>
Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>

When qemu do live migration with xbzrle, qemu malloc decoded_buf
at destination end but free it at source end. It will crash qemu
by double free error in some scenarios. Splitting the XBZRLE structure
for clear logic distinguishing src/dst side.
Signed-off-by: NChenLiang <chenliang88@huawei.com>
Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NOrit Wasserman <owasserm@redhat.com>
Signed-off-by: NGongLei <arei.gonglei@huawei.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>

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

Signed-off-by: NOrit Wasserman <owasserm@redhat.com>
Reviewed-by: NJuan Quintela <quintela@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>

We use the old code if the bitmaps are not aligned
Signed-off-by: NJuan Quintela <quintela@redhat.com>
Reviewed-by: NOrit Wasserman <owasserm@redhat.com>

This function is the only bit where we care about speed.
Signed-off-by: NJuan Quintela <quintela@redhat.com>
Reviewed-by: NOrit Wasserman <owasserm@redhat.com>

We are going to update the bitmap directly
Signed-off-by: NJuan Quintela <quintela@redhat.com>
Reviewed-by: NOrit Wasserman <owasserm@redhat.com>

The madvise for zeroed out pages was introduced when every transferred
zero page was memset to zero and thus allocated. Since commit
211ea740 we check for zeroness of a target page before we memset
it to zero. Additionally we memmap target memory so it is essentially
zero initialized (except for e.g. option roms and bios which are loaded
into target memory although they shouldn't).

It was reported recently that this madvise causes a performance degradation
in some situations. As the madvise should only be called rarely and if it's called
it is likely on a busy page (it was non-zero and changed to zero during migration)
drop it completely.
Reported-By: NZhang Haoyu <haoyu.zhang@huawei.com>
Acked-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NPeter Lieven <pl@kamp.de>
Signed-off-by: NJuan Quintela <quintela@redhat.com>

Currently, -smbios type=T,NAME=VAL,... adds one field (T,NAME) with
value VAL to fw_cfg for each unique NAME.  If NAME occurs multiple
times, the last one's VAL is used (before the QemuOpts conversion, the
first one was used).

Multiple -smbios can add multiple fields with the same (T, NAME).
SeaBIOS reads all of them from fw_cfg, but uses only the first field
(T, NAME).  The others are ignored.

"First one wins, subsequent ones get ignored silently" isn't nice.  We
commonly let the last option win.  Useful, because it lets you
-readconfig first, then selectively override with command line
options.

Clean up -smbios to work the common way.  Accumulate the settings,
with later ones overwriting earlier ones.  Put the result into fw_cfg
(no more useless duplicates).

Bonus cleanup: qemu_uuid_parse() no longer sets SMBIOS system uuid by
side effect.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

So that it can be set in config file for -readconfig.

This tightens parsing of -smbios, and makes it more consistent with
other options: unknown parameters are rejected, numbers with trailing
junk are rejected, when a parameter is given multiple times, last
rather than first wins, ...

MST: drop one chunk to fix build errors
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

It exits on all error conditions but one, where it returns -1.
Normalize, and return void.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

ram_handle_compressed() should be aware of size > TARGET_PAGE_SIZE.
migration-rdma can call it with larger size.
Signed-off-by: NIsaku Yamahata <yamahata@private.email.ne.jp>
Signed-off-by: NJuan Quintela <quintela@redhat.com>

Later is_zero_page will be used for non TARGET_PAGE_SIZE
range.
And rename it to is_zero_range as it isn't page size any more.
Signed-off-by: NIsaku Yamahata <yamahata@private.email.ne.jp>
Signed-off-by: NJuan Quintela <quintela@redhat.com>

qemu_file_rate_limit() never return negative value since the refactor
by Commit 1964a397, this patch gets rid of the negative check for it,
adjust bytes_transferred and return value correspondingly in
ram_save_iterate().
Signed-off-by: NLei Li <lilei@linux.vnet.ibm.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>

It was introduced to loop over CPUs from target-independent code, but
since commit 182735ef target-independent
CPUState is used.

A loop can be considered more efficient than function calls in a loop,
and CPU_FOREACH() hides implementation details just as well, so use that
instead.
Suggested-by: NMarkus Armbruster <armbru@redhat.com>
Acked-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

This is an autogenerated patch using scripts/switch-timer-api.

Switch the entire code base to using the new timer API.

Note this patch may introduce some line length issues.
Signed-off-by: NAlex Bligh <alex@alex.org.uk>
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>

Migration code assumes that each MR is a multiple of TARGET_PAGE_SIZE:
MR size is divided by TARGET_PAGE_SIZE, so if it isn't migration
never completes.
But this isn't really required for regions set up with
memory_region_init_ram, since that calls qemu_ram_alloc
which aligns size up using TARGET_PAGE_ALIGN.

Align MR size up to full target page sizes, this way
migration completes even if we create a RAM MR
which is not a full target page size.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NLaszlo Ersek <lersek@redhat.com>

Convert stderr messages calling error_get_pretty()
to error_report().

Timestamp is prepended by -msg timstamp option with it.

Per Markus's comment below, A conversion from fprintf() to
error_report() is always an improvement, regardless of
error_get_pretty().

http://marc.info/?l=qemu-devel&m=137513283408601&w=2

But, it is not reasonable to convert them at one time
because fprintf() is used everwhere in qemu.

So, it should be done step by step with avoiding regression.
Signed-off-by: NSeiji Aguchi <seiji.aguchi@hds.com>
Reviewed-by: NLaszlo Ersek <lersek@redhat.com>
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>

This takes advantages of the previous patches:

1. use the new QEMUFileOps hook 'save_page'

2. call out to the right accessor methods to invoke
   the iteration hooks defined in QEMUFileOps
Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
Reviewed-by: NChegu Vinod <chegu_vinod@hp.com>
Tested-by: NChegu Vinod <chegu_vinod@hp.com>
Tested-by: NMichael R. Hines <mrhines@us.ibm.com>
Signed-off-by: NMichael R. Hines <mrhines@us.ibm.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>

This gives RDMA shared access to madvise() on the destination side
when an entire chunk is found to be zero.
Reviewed-by: NJuan Quintela <quintela@redhat.com>
Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
Reviewed-by: NChegu Vinod <chegu_vinod@hp.com>
Tested-by: NChegu Vinod <chegu_vinod@hp.com>
Tested-by: NMichael R. Hines <mrhines@us.ibm.com>
Signed-off-by: NMichael R. Hines <mrhines@us.ibm.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>

If a user chooses to turn on the auto-converge migration capability
these changes detect the lack of convergence and throttle down the
guest. i.e. force the VCPUs out of the guest for some duration
and let the migration thread catchup and help converge.

Verified the convergence using the following :
 - Java Warehouse workload running on a 20VCPU/256G guest(~80% busy)
 - OLTP like workload running on a 80VCPU/512G guest (~80% busy)

Sample results with Java warehouse workload : (migrate speed set to 20Gb and
migrate downtime set to 4seconds).

 (qemu) info migrate
 capabilities: xbzrle: off auto-converge: off  <----
 Migration status: active
 total time: 1487503 milliseconds
 expected downtime: 519 milliseconds
 transferred ram: 383749347 kbytes
 remaining ram: 2753372 kbytes
 total ram: 268444224 kbytes
 duplicate: 65461532 pages
 skipped: 64901568 pages
 normal: 95750218 pages
 normal bytes: 383000872 kbytes
 dirty pages rate: 67551 pages

 ---

 (qemu) info migrate
 capabilities: xbzrle: off auto-converge: on   <----
 Migration status: completed
 total time: 241161 milliseconds
 downtime: 6373 milliseconds
 transferred ram: 28235307 kbytes
 remaining ram: 0 kbytes
 total ram: 268444224 kbytes
 duplicate: 64946416 pages
 skipped: 64903523 pages
 normal: 7044971 pages
 normal bytes: 28179884 kbytes
Signed-off-by: NChegu Vinod <chegu_vinod@hp.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>

We have stayed at 800x600x15 as default graphics mode for the last 9 years.
If there ever was a reason to be there, surely nobody remembers it.

However, recently non-Linux PPC guests started to show bad effects on 15 bit
color mode. They do work just fine with 32 bits however.

So let's switch to 32 bit color as the default graphic mode.
Reported-by: NMark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Signed-off-by: NAlexander Graf <agraf@suse.de>

length is a ram_addr_t, so RAM_ADDR_FMT must be used instead of %ld.
This fixes a recently introduced regression for w64 builds.

Using RAM_ADDR_FMT also changes decimal output to sedecimal.
This is good here because length and block->length should both
use the same base in the error message.
Signed-off-by: NStefan Weil <sw@weilnetz.de>
Message-id: 1372359606-2759-1-git-send-email-sw@weilnetz.de
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

RDMA writes happen asynchronously, and thus the performance accounting
also needs to be able to occur asynchronously. This allows anybody
to call into savevm.c to update both f->pos as well as into arch_init.c
to update the acct_info structure with up-to-date values when
the RDMA transfer actually completes.
Reviewed-by: NJuan Quintela <quintela@redhat.com>
Tested-by: NChegu Vinod <chegu_vinod@hp.com>
Tested-by: NMichael R. Hines <mrhines@us.ibm.com>
Signed-off-by: NMichael R. Hines <mrhines@us.ibm.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>

on incoming migration do not memset pages to zero if they already read as zero.
this will allocate a new zero page and consume memory unnecessarily. even
if we madvise a MADV_DONTNEED later this will only deallocate the memory
asynchronously.
Signed-off-by: NPeter Lieven <pl@kamp.de>
Signed-off-by: NJuan Quintela <quintela@redhat.com>

Not sending zero pages breaks migration if a page is zero
at the source but not at the destination. This can e.g. happen
if different BIOS versions are used at source and destination.
It has also been reported that migration on pseries is completely
broken with this patch.

This effectively reverts commit f1c72795.

Conflicts:

	arch_init.c
Signed-off-by: NPeter Lieven <pl@kamp.de>
Signed-off-by: NJuan Quintela <quintela@redhat.com>

Makes it easier to debug situations where the source and target have
different ram blocks in a device and migration fails due to that, for
instance a BAR size change on a PCI device.
Signed-off-by: NAlon Levy <alevy@redhat.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>

Just use the TARGET_NAME free string.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Message-id: 1370349928-20419-6-git-send-email-pbonzini@redhat.com
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

Everything else needs to match the executable name, which is
TARGET_NAME.

Before:
    $ sh4eb-linux-user/qemu-sh4eb --help
    usage: qemu-sh4 [options] program [arguments...]
    Linux CPU emulator (compiled for sh4 emulation)

After:
    $ sh4eb-linux-user/qemu-sh4eb --help
    usage: qemu-sh4eb [options] program [arguments...]
    Linux CPU emulator (compiled for sh4eb emulation)
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Message-id: 1370349928-20419-5-git-send-email-pbonzini@redhat.com
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

Having size precede the associated pointer is odd.  Swap them, and fix
up the types.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NLaszlo "ever the optimist" Ersek <lersek@redhat.com>
Message-id: 1370610036-10577-5-git-send-email-armbru@redhat.com
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Improves diagnistics from ad hoc messages like

    Invalid SMBIOS UUID string

to

    qemu-system-x86_64: -smbios type=1,uuid=gaga: Invalid UUID
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NLaszlo "ever the optimist" Ersek <lersek@redhat.com>
Message-id: 1370610036-10577-4-git-send-email-armbru@redhat.com
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Since this is a MemoryListener operation, it only makes sense
on an AddressSpace granularity.
Suggested-by: NPeter Maydell <peter.maydell@linaro.org>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Message-id: 1366303444-24620-8-git-send-email-pbonzini@redhat.com
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Several targets can have wavcapture/-soundhw support via PCI cards.
HAS_AUDIO is a useless limitation, remove it.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Message-id: 1366303444-24620-4-git-send-email-pbonzini@redhat.com
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Message-id: 1366303444-24620-3-git-send-email-pbonzini@redhat.com
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Headers in include/exec/ are for the deepest innards of QEMU,
they should almost never be included directly.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Functions defined in acpi/ should be declared in
acpi.h
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>