Postcopy detects accesses to pages that haven't been transferred yet
using userfaultfd, and it causes exceptions on pages that are 'not
present'.
Ballooning also causes pages to be marked as 'not present' when the
guest inflates the balloon.
Potentially a balloon could be inflated to discard pages that are
currently inflight during postcopy and that may be arriving at about
the same time.

To avoid this confusion, disable ballooning during postcopy.

When disabled we drop balloon requests from the guest.  Since ballooning
is generally initiated by the host, the management system should avoid
initiating any balloon instructions to the guest during migration,
although it's not possible to know how long it would take a guest to
process a request made prior to the start of migration.
Guest initiated ballooning will not know if it's really freed a page
of host memory or not.

Queueing the requests until after migration would be nice, but is
non-trivial, since the set of inflate/deflate requests have to
be compared with the state of the page to know what the final
outcome is allowed to be.
Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: NJuan Quintela <quintela@redhat.com>
Reviewed-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NJuan Quintela <quintela@redhat.com>

In particular, don't include it into headers.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NLuiz Capitulino <lcapitulino@redhat.com>

Signed-off-by: NWenchao Xia <wenchaoqemu@gmail.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>

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

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

After setting a balloon target value, applications have to
continually poll 'query-balloon' to determine whether the
guest has reacted to this request. The virtio-balloon backend
knows exactly when the guest has reacted though, and thus it
is possible to emit a JSON event to tell the mgmt application
whenever the guest balloon changes.

This introduces a new 'qemu_balloon_changed()' API which is
to be called by balloon driver backends, whenever they have
a change in balloon value. This takes the 'actual' balloon
value, as would be found in the BalloonInfo struct.

The qemu_balloon_change API emits a JSON monitor event which
looks like:

  {"timestamp": {"seconds": 1337162462, "microseconds": 814521},
   "event": "BALLOON_CHANGE", "data": {"actual": 944766976}}

* balloon.c, balloon.h: Introduce qemu_balloon_changed() for
  emitting balloon change events on the monitor
* hw/virtio-balloon.c: Invoke qemu_balloon_changed() whenever
  the guest changes the balloon actual value
* monitor.c, monitor.h: Define QEVENT_BALLOON_CHANGE
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
Acked-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>

Note that the command being dropped uses the deprecated MONITOR_CMD_ASYNC
API, but the new command is a regular synchronous command. There shouldn't
be visible differences though, as MONITOR_CMD_ASYNC is internal only.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>

Please, note that some of the code supporting memory statistics is
still around (eg. virtio_balloon_receive_stats() and reset_stats()).

Also, the qmp_query_balloon() function is synchronous and thus doesn't
make any use of the (not fully working) monitor's asynchronous command
support (the old non-qapi implementation did).
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>

When a balloon device gets unplugged, allow the balloon handlers to be
freed.
Reported-by: NShaolong Hu <shu@redhat.com>
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Multiple balloon devices don't make sense; disallow more than one
registration attempt to register handlers.
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Acked-by: NMichael S. Tsirkin <mst@redhat.com>

Passing on '0' as ballooning target to indicate retrieval of stats is
bad API.  It also makes 'balloon 0' in the monitor cause a segfault.
Have two different functions handle the different functionality instead.

Detailed explanation from Markus's review:

1. do_info_balloon() is an info_async() method.  It receives a callback
   with argument, to be called exactly once (callback frees the
   argument).  It passes the callback via qemu_balloon_status() and
   indirectly through qemu_balloon_event to virtio_balloon_to_target().

   virtio_balloon_to_target() executes its balloon stats half.  It
   stores the callback in the device state.

   If it can't send a stats request, it resets stats and calls the
   callback right away.

   Else, it sends a stats request.  The device model runs the callback
   when it receives the answer.

   Works.

2. do_balloon() is a cmd_async() method.  It receives a callback with
   argument, to be called when the command completes.  do_balloon()
   calls it right before it succeeds.  Odd, but should work.

   Nevertheless, it passes the callback on via qemu_ballon() and
   indirectly through qemu_balloon_event to virtio_balloon_to_target().

   a. If the argument is non-zero, virtio_balloon_to_target() executes
      its balloon half, which doesn't use the callback in any way.

      Odd, but works.

   b. If the argument is zero, virtio_balloon_to_target() executes its
      balloon stats half, just like in 1.  It either calls the callback
      right away, or arranges for it to be called later.

      Thus, the callback runs twice: use after free and double free.

Test case: start with -S -device virtio-balloon, execute "balloon 0" in
human monitor.  Runs the callback first from virtio_balloon_to_target(),
then again from do_balloon().
Reported-by: NMike Cao <bcao@redhat.com>
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>

balloon.h had function declarations for a couple of functions that are
local to balloon.c.  Make them static.

Drop the 'qemu_' prefix for balloon.c-local variables, and make them
static.
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>

Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>

Allow balloon.h, gdbstub.h and kvm.h to be included from
non-CPU code.
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

When using ballooning to manage overcommitted memory on a host, a system for
guests to communicate their memory usage to the host can provide information
that will minimize the impact of ballooning on the guests.  The current method
employs a daemon running in each guest that communicates memory statistics to a
host daemon at a specified time interval.  The host daemon aggregates this
information and inflates and/or deflates balloons according to the level of
host memory pressure.  This approach is effective but overly complex since a
daemon must be installed inside each guest and coordinated to communicate with
the host.  A simpler approach is to collect memory statistics in the virtio
balloon driver and communicate them directly to the hypervisor.
Signed-off-by: NAdam Litke <agl@us.ibm.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

In the very least, a change like this requires discussion on the list.

The naming convention is goofy and it causes a massive merge problem.  Something
like this _must_ be presented on the list first so people can provide input
and cope with it.

This reverts commit 99a0949b.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Some not so obvious bits, slirp and Xen were left alone for the time
being.
Signed-off-by: Nmalc <av1474@comtv.ru>

Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>



git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@5875 c046a42c-6fe2-441c-8c8c-71466251a162