We already depend on working __thread support for coroutines, so this
complication here is no longer needed.
Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

This fixes a subtle bug. A bug that probably won't cause trouble for any
existing OS, but a bug anyway:

Intel SDM Volume 2, CPUID Instruction states:

> Two types of information are returned: basic and extended function
> information. If a value entered for CPUID.EAX is higher than the maximum
> input value for basic or extended function for that processor then the
> data for the highest basic information leaf is returned. For example,
> using the Intel Core i7 processor, the following is true:
>
>   CPUID.EAX = 05H (* Returns MONITOR/MWAIT leaf. *)
>   CPUID.EAX = 0AH (* Returns Architectural Performance Monitoring leaf. *)
>   CPUID.EAX = 0BH (* Returns Extended Topology Enumeration leaf. *)
>   CPUID.EAX = 0CH (* INVALID: Returns the same information as CPUID.EAX = 0BH. *)
>   CPUID.EAX = 80000008H (* Returns linear/physical address size data. *)
>   CPUID.EAX = 8000000AH (* INVALID: Returns same information as CPUID.EAX = 0BH. *)

AMD's CPUID Specification, on the other hand, is less specific:

> The CPUID instruction supports two sets or ranges of functions,
> standard and extended.
>
> • The smallest function number of the standard function range is
>   Fn0000_0000. The largest function num- ber of the standard function
>   range, for a particular implementation, is returned in CPUID
>   Fn0000_0000_EAX.
>
> • The smallest function number of the extended function range is
>   Fn8000_0000. The largest function num- ber of the extended function
>   range, for a particular implementation, is returned in CPUID
>   Fn8000_0000_EAX.
>
> Functions that are neither standard nor extended are undefined and
> should not be relied upon.

QEMU's behavior matched Intel's specification before, but this was
changed by commit b3baa152. This patch
restores the behavior documented by Intel when cpuid_xlevel2 is 0.

The existing behavior when cpuid_xlevel2 is set (falling back to
level=cpuid_xlevel) is being kept, as I couldn't find any public
documentation on the CPUID 0xC0000000 function range on Centaur CPUs.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Changes since V1:
  - Avoid crashing since qemu_opts_id() may return null on some
    systems according to Markus's suggestion.

When controlling a qemu instance from another program, it's
hard to know which serial port or monitor device is redirected
to which pty. With more than one device using "pty" a lot of
guesswork is involved.

$ ./x86_64-softmmu/qemu-system-x86_64 -serial pty -serial pty -monitor pty
char device redirected to /dev/pts/5
char device redirected to /dev/pts/6
char device redirected to /dev/pts/7

Although we can find out what everything else is connected to
by the "info chardev" with "-monitor stdio" in the command line,
It'd be very useful to be able to have qemu inherit pseudo-tty
file descriptors so they could just be specified on the command
line like:

$ ./x86_64-softmmu/qemu-system-x86_64 -serial pty -serial pty -monitor pty
char device compat_monitor0 redirected to /dev/pts/5
char device serial0 redirected to /dev/pts/6
char device serial1 redirected to /dev/pts/7

Referred link: https://bugs.launchpad.net/qemu/+bug/938552Signed-off-by: NLei Li <lilei@linux.vnet.ibm.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Zero out tcg_ctx.gen_opc_instr_start for instructions representing the
last guest opcode in the TB.

Cc: qemu-stable@nongnu.org
Signed-off-by: NMax Filippov <jcmvbkbc@gmail.com>
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

To fix building error:

CC    net/vde.o
net/vde.c: In function ‘vde_cleanup’:
net/vde.c:65:5: error: implicit declaration of function ‘qemu_set_fd_handler’ [-Werror=implicit-function-declaration]
net/vde.c:65:5: error: nested extern declaration of ‘qemu_set_fd_handler’ [-Werror=nested-externs]
cc1: all warnings being treated as errors
Signed-off-by: NLiming Wang <walimisdev@gmail.com>
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

  When tb_remove was first commited at fd6ce8f6, there were three different
calls pass different names to offsetof. In current codebase, the other two
calls are replaced with tb_page_remove. There is no need to have a general
tb_remove. Omit passing the third parameter and using tb1->phys_hash_next
directly.
Signed-off-by: NChen Wei-Ren <chenwj@iis.sinica.edu.tw>
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

These and some more compiler warnings were caused by a recent commit:

net/tap-win32.c:724: warning: no previous prototype for ‘tap_has_ufo’
net/tap-win32.c:729: warning: no previous prototype for ‘tap_has_vnet_hdr’
...
Signed-off-by: NStefan Weil <sw@weilnetz.de>
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

xen-all needs to access CharDeviceState's filename field, so
it needs to include char/char.h.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Tested-by: NAndreas Färber <afaerber@suse.de>
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

vnc-tls.h is included by vnc.h, and it includes gnutls/gnutls.h.
Hence, GnuTLS header files are needed by all files that include
vnc.h, most notably qmp.c.  Move these flags to QEMU_CFLAGS for
simplicity.
Reported-by: NPeter Maydell <peter.maydell@linaro.org>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

* quintela/thread-20121220.next: (79 commits)
  migration: merge QEMUFileBuffered into MigrationState
  migration: fix qemu_get_fd for BufferedFile
  ram: refactor ram_save_block() return value
  ram: account the amount of transferred ram better
  ram: optimize migration bitmap walking
  ram: Use memory_region_test_and_clear_dirty
  memory: introduce memory_region_test_and_clear_dirty
  ram: Add last_sent_block
  ram: rename last_block to last_seen_block
  migration: move migration notifier
  migration: Inline qemu_fopen_ops_buffered into migrate_fd_connect
  migration: move migration_fd_put_ready()
  migration: add XFER_LIMIT_RATIO
  migration: move buffered_file.c code into migration.c
  savevm: New save live migration method: pending
  buffered_file: unfold buffered_append in buffered_put_buffer
  buffered_file: don't flush on put buffer
  buffered_file: Unfold the trick to restart generating migration data
  migration: just lock migrate_fd_put_ready
  migration: remove unfreeze logic
  ...
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Avoid splitting the state of outgoing migration, more or less arbitrarily,
between two data structures.  QEMUFileBuffered anyway is used only during
migration.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>

Not really used, but nice to have it correct. :)
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>

It could only return 0 if we only found dirty xbzrle pages that hadn't
changed (i.e. they were written with the same content).  We don't care
about that case, it is the same than nothing dirty.

So now the return of the function is how much have it written, nothing
else. Adjust callers.

And we also made ram_save_iterate() return the number of transferred
bytes, not the number of transferred pages.
Signed-off-by: NJuan Quintela <quintela@redhat.com>

Signed-off-by: NJuan Quintela <quintela@redhat.com>

Instead of testing each page individually, we search what is the next
dirty page with a bitmap operation.  We have to reorganize the code to
move from a "for" loop, to a while(dirty) loop.
Signed-off-by: NJuan Quintela <quintela@redhat.com>

This avoids having to do two walks over the dirty bitmap, once reading
the dirty bits, and anthoer cleaning them.
Signed-off-by: NJuan Quintela <quintela@redhat.com>

This function avoids having to do two calls, one to test the dirty bit, and
other to reset it.
Signed-off-by: NJuan Quintela <quintela@redhat.com>

This is the last block from where we have sent data.
Signed-off-by: NOrit Wasserman <owasserm@redhat.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>

Signed-off-by: NJuan Quintela <quintela@redhat.com>

At this point, it is waranteed that state is ACTIVE.  Old position
didn't assured hat.
Signed-off-by: NJuan Quintela <quintela@redhat.com>

Signed-off-by: NJuan Quintela <quintela@redhat.com>

Put it near its use and un-export it.
Signed-off-by: NJuan Quintela <quintela@redhat.com>

The "magic" divisions by 10 are there because of the value of BUFFER_DELAY.
Introduce a constant to explain them better.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>

This only moves the code (also from buffered_file.h to migration.h).
Fix whitespace until checkpatch is happy.
Signed-off-by: NJuan Quintela <quintela@redhat.com>

Code just now does (simplified for clarity)

    if (qemu_savevm_state_iterate(s->file) == 1) {
       vm_stop_force_state(RUN_STATE_FINISH_MIGRATE);
       qemu_savevm_state_complete(s->file);
    }

Problem here is that qemu_savevm_state_iterate() returns 1 when it
knows that remaining memory to sent takes less than max downtime.

But this means that we could end spending 2x max_downtime, one
downtime in qemu_savevm_iterate, and the other in
qemu_savevm_state_complete.

Changed code to:

    pending_size = qemu_savevm_state_pending(s->file, max_size);
    DPRINTF("pending size %lu max %lu\n", pending_size, max_size);
    if (pending_size >= max_size) {
        ret = qemu_savevm_state_iterate(s->file);
     } else {
        vm_stop_force_state(RUN_STATE_FINISH_MIGRATE);
        qemu_savevm_state_complete(s->file);
     }

So what we do is: at current network speed, we calculate the maximum
number of bytes we can sent: max_size.

Then we ask every save_live section how much they have pending.  If
they are less than max_size, we move to complete phase, otherwise we
do an iterate one.

This makes things much simpler, because now individual sections don't
have to caluclate the bandwidth (it was implossible to do right from
there).
Signed-off-by: NJuan Quintela <quintela@redhat.com>
Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>

It was the only user, and now buffered_put_buffer just do the append
Signed-off-by: NJuan Quintela <quintela@redhat.com>
Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>

We call buffered_put_buffer with iothread held, and buffered_flush() does
synchronous writes.  We only want to do the synchronous writes outside.
Signed-off-by: NJuan Quintela <quintela@redhat.com>
Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>

This was needed before due to the way that the callbacks worked.
Signed-off-by: NJuan Quintela <quintela@redhat.com>
Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>

Signed-off-by: NJuan Quintela <quintela@redhat.com>

Now that we have a thread, and blocking writes, we don't need it.
Signed-off-by: NJuan Quintela <quintela@redhat.com>
Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>

Move all the writes to the migration_thread, and make writings
blocking.  Notice that are still using the iothread for everything
that we do.
Signed-off-by: NJuan Quintela <quintela@redhat.com>

This way everything related with migration is run on the migration
thread and no locking is needed.
Signed-off-by: NJuan Quintela <quintela@redhat.com>

We want the file assignment to happen before the thread is created to
avoid locking, so we just do it before creating the thread.
Signed-off-by: NJuan Quintela <quintela@redhat.com>
Reviewed-by: NOrit Wasserman <owasserm@redhat.com>

We still protect everything except the wait with the iothread lock.
But we moved from a timer to a thread.  Steps one by one.

We also need to detect when we have finished with a variable "complete".
Signed-off-by: NJuan Quintela <quintela@redhat.com>

Add the new mutex that protects shared state between ram_save_live
and the iothread.  If the iothread mutex has to be taken together
with the ramlist mutex, the iothread shall always be _outside_.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NUmesh Deshpande <udeshpan@redhat.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>
Reviewed-by: NOrit Wasserman <owasserm@redhat.com>

This will be used to detect if last_block might have become invalid
across different calls to ram_save_live.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NUmesh Deshpande <udeshpan@redhat.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>
Reviewed-by: NOrit Wasserman <owasserm@redhat.com>

Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>

Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>

Most of the time, only 2 items will be active (from/to for a string operation,
or code/data).  But TCG guests likely won't have gigabytes of memory, so
this actually goes down to 1 item.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>

Signed-off-by: NJuan Quintela <quintela@redhat.com>