The position of the struct parameter in the function signature
differs. Instead of hardcoding the handling for this add an annotation
to the .x file to define the position.

When an operation started by virDomainBlockPullAll completes (either with
success or with failure), raise an event to indicate the final status.  This
allows an API user to avoid polling on virDomainBlockPullInfo if they would
prefer to use the event mechanism.

* daemon/remote.c: Dispatch events to client
* include/libvirt/libvirt.h.in: Define event ID and callback signature
* src/conf/domain_event.c, src/conf/domain_event.h,
  src/libvirt_private.syms: Extend API to handle the new event
* src/qemu/qemu_driver.c: Connect to the QEMU monitor event
  for block_stream completion and emit a libvirt block pull event
* src/remote/remote_driver.c: Receive and dispatch events to application
* src/remote/remote_protocol.x: Wire protocol definition for the event
* src/qemu/qemu_monitor.c, src/qemu/qemu_monitor.h,
  src/qemu/qemu_monitor_json.c: Watch for BLOCK_STREAM_COMPLETED event
  from QEMU monitor
Signed-off-by: NAdam Litke <agl@us.ibm.com>

The generator can handle DomainBlockPullAll and DomainBlockPullAbort.
DomainBlockPull and DomainBlockPullInfo must be written by hand.

* src/remote/remote_protocol.x: provide defines for the new entry points
* src/remote/remote_driver.c daemon/remote.c: implement the client and
  server side
* src/remote_protocol-structs: structure definitions for protocol verification
Signed-off-by: NAdam Litke <agl@us.ibm.com>

Signed-off-by: NMinoru Usui <usui@mxm.nes.nec.co.jp>

Signed-off-by: NMinoru Usui <usui@mxm.nes.nec.co.jp>

Signed-off-by: NLai Jiangshan <laijs@cn.fujitsu.com>

This patch implements the remote protocol for the new API
(virDomainPinVcpuFlags).

This doesn't cover the getters that allow to query nparams yet.

This introduces a new domain

  VIR_DOMAIN_EVENT_ID_CONTROL_ERROR

Which uses the existing generic callback

typedef void (*virConnectDomainEventGenericCallback)(virConnectPtr conn,
                                                     virDomainPtr dom,
                                                     void *opaque);

This event is intended to be emitted when there is a failure in
some part of the domain virtualization system. Whether the domain
continues to run/exist after the failure is an implementation
detail specific to the hypervisor.

The idea is that with some types of failure, hypervisors may
prefer to leave the domain running in a "degraded" mode of
operation. For example, if something goes wrong with the QEMU
monitor, it is possible to leave the guest OS running quite
happily. The mgmt app will simply loose the ability todo various
tasks. The mgmt app can then choose how/when to deal with the
failure that occured.
* daemon/remote.c: Dispatch of new event
* examples/domain-events/events-c/event-test.c: Demo catch
  of event
* include/libvirt/libvirt.h.in: Define event ID and callback
* src/conf/domain_event.c, src/conf/domain_event.h: Internal
  event handling
* src/remote/remote_driver.c: Receipt of new event from daemon
* src/remote/remote_protocol.x: Wire protocol for new event
* src/remote_protocol-structs: add new event for checks

* daemon/remote.c (remoteDispatchDomainGetSchedulerParameters):
New function.
* src/remote/remote_driver.c (remoteDomainGetSchedulerParameters):
Likewise.
* src/remote/remote_protocol.x
(remote_domain_get_scheduler_parameters_flags_args)
(remote_domain_get_scheduler_parameters_flags_ret): New types.
(remote_procedure): New RPC.
* src/remote_protocol-structs: Likewise.

* src/remote/remote_protocol.x (remote_typed_param_value)
(remote_typed_param):  New types.
(remote_sched_param_value, remote_sched_param)
(remote_blkio_param_value, remote_blkio_param)
(remote_memory_param_value, remote_memory_param): Delete.
(remote_domain_get_scheduler_parameters_ret)
(remote_domain_set_scheduler_parameters_args)
(remote_domain_set_scheduler_parameters_flags_args)
(remote_domain_set_blkio_parameters_args)
(remote_domain_get_blkio_parameters_ret)
(remote_domain_set_memory_parameters_args)
(remote_domain_get_memory_parameters_ret): Update clients.
* src/remote_protocol-structs: Likewise.
* src/remote/remote_driver.c (remoteSerializeTypedParameters)
(remoteDeserializeTypedParameters): New functions.
(remoteDomainSetMemoryParameters)
(remoteDomainGetMemoryParameters, remoteDomainSetBlkioParameters)
(remoteDomainGetBlkioParameters)
(remoteDomainGetSchedulerParameters)
(remoteDomainSetSchedulerParameters)
(remoteDomainSetSchedulerParametersFlags): Update clients.
* daemon/remote.c (remoteSerializeTypedParameters)
(remoteDeserializeTypedParameters): New functions.
(remoteDispatchDomainGetSchedulerParameters)
(remoteDispatchDomainSetSchedulerParameters)
(remoteDispatchDomainSetSchedulerParametersFlags)
(remoteDispatchDomainSetMemoryParameters)
(remoteDispatchDomainGetMemoryParameters)
(remoteDispatchDomainSetBlkioParameters)
(remoteDispatchDomainGetBlkioParameters): Update clients.

In most cases this affects flags parameters that are unsigned in the
public and driver API but signed in the XDR protocol. Switch the
XDR protocol to unsigned for those.

A counterexample is virNWFilterGetXMLDesc. Its flags parameter is signed
in the public API and XDR protocol, but unsigned in the driver API.

virNodeGetFreeMemory used unsigned long long in the public API but
signed hyper in the XDR protocol. Convert the XDR protocol to use
unsigned hyper.

As explained by Eric before, this doesn't affect the on-the-wire protocol.

Extend procedure annotation in the .x file for stream handling.

Adds a missing remoteStreamRelease call to remoteDomainScreenshot
error path.

Several functions return values by reference parameters. This is realized
by passing the members of remote_CALL_ret by reference to the called
function.

The position of this parameters in the function signature follows some
patterns with some exceptions. This patterns and exceptions are hardcoded
in the generator.

Add an insert@<offset> annotation to the remote_CALL_ret struct members
for functions that return lists to remove some of the hardcoded patterns
and exceptions.

This allows to remove some special case code from the generator.

Add special case code for updating a given domain object instead of
returning a new one.

The current virDomainMigrateFinish3 method signature attempts to
distinguish two types of errors, by allowing return with ret== 0,
but ddomain == NULL, to indicate a failure to start the guest.
This is flawed, because when ret == 0, there is no way for the
virErrorPtr details to be sent back to the client.

Change the signature of virDomainMigrateFinish3 so it simply
returns a virDomainPtr, in the same way as virDomainMigrateFinish2
The disk locking code will protect against the only possible
failure mode this doesn't account for (loosing conenctivity to
libvirtd after Finish3 starts the CPUs, but before the client
sees the reply for Finish3).

* src/driver.h, src/libvirt.c, src/libvirt_internal.h: Change
  virDomainMigrateFinish3 to return a virDomainPtr instead of int
* src/remote/remote_driver.c, src/remote/remote_protocol.x,
  daemon/remote.c, src/qemu/qemu_driver.c, src/qemu/qemu_migration.c:
  Update for API change

The virDomainMigratePerform3 currently has a single URI parameter
whose meaning varies. It is either

 - A QEMU migration URI (normal migration)
 - A libvirtd connection URI (peer2peer migration)

Unfortunately when using peer2peer migration, without also
using tunnelled migration, it is possible that both URIs are
required.

This adds a second URI parameter to the virDomainMigratePerform3
method, to cope with this scenario. Each parameter how has a fixed
meaning.

NB, there is no way to actually take advantage of this yet,
since virDomainMigrate/virDomainMigrateToURI do not have any
way to provide the 2 separate URIs

* daemon/remote.c, src/remote/remote_driver.c,
  src/remote/remote_protocol.x, src/remote_protocol-structs: Add
  the second URI parameter to perform3 message
* src/driver.h, src/libvirt.c, src/libvirt_internal.h: Add
  the second URI parameter to Perform3 method
* src/libvirt_internal.h, src/qemu/qemu_migration.c,
  src/qemu/qemu_migration.h: Update to handle URIs correctly

This extends the v3 migration protocol such that the
virDomainMigrateBegin3 and virDomainMigratePerform3
methods accept an application supplied XML config for
the target VM.

If the 'xmlin' parameter is NULL, then Begin3 uses the
current guest XML as normal. A driver implementing the
Begin3 method should either reject all non-NULL 'xmlin'
parameters, or strictly validate that the app supplied
XML does not change guest ABI.

The Perform3 method also needed the xmlin parameter to
cope with the Peer2Peer migration sequence.

NB it is not yet possible to use this capability since
neither of the public virDomainMigrate/virDomainMigrateToURI
methods have a way to pass in XML.

* daemon/remote.c, src/remote/remote_driver.c,
  src/remote/remote_protocol.x, src/remote_protocol-structs:
  Add 'remote_string xmlin' parameter to begin3/perform3
  RPC messages
* src/libvirt.c, src/driver.h, src/libvirt_internal.h: Add
  'const char *xmlin' parameter to Begin3/Perform3 methods
* src/qemu/qemu_driver.c, src/qemu/qemu_migration.c,
  src/qemu/qemu_migration.h: Pass xmlin parameter around
  migration methods

The on-the-wire protocol is identical; XDR guarantees that
both 'hyper' and 'unsigned hyper' are transmitted as 8 bytes.

* src/remote/remote_protocol.x (remote_get_version_ret)
(remote_get_lib_version_ret): Match public API.
* daemon/remote_generator.pl: Drop special case.
* src/remote_protocol-structs: Reflect updated type.

support for virDomainSetSchedulerParametersFlags of remote driver.

For virDomainDestroy and virDrvSupportsFeature.

The migration protocol has support for a 'cookie' parameter which
is an opaque array of bytes as far as libvirt is concerned. Drivers
may use this for passing around arbitrary extra data they might
need during migration. The QEMU driver needs to do a few things:

 - Pass hostname/uuid to allow strict protection against localhost
   migration attempts
 - Pass SPICE/VNC server port from the target back to the source to
   allow seamless relocation of client sessions
 - Pass lock driver state from source to destination

This patch introduces the basic glue for handling cookies
but only includes the host/guest UUID & name.

* src/libvirt_private.syms: Export virXMLParseStrHelper
* src/qemu/qemu_migration.c, src/qemu/qemu_migration.h: Parsing
  and formatting of migration cookies
* src/qemu/qemu_driver.c: Pass in cookie parameters where possible
* src/remote/remote_protocol.h, src/remote/remote_protocol.x: Change
  cookie max length to 16384 bytes

* src/remote/remote_protocol.x: Define wire protocol for migration
  protocol v3
* daemon/remote.c: Server side dispatch
* src/remote/remote_driver.c: Client side serialization
* src/remote/remote_protocol.c, src/remote/remote_protocol.h,
  daemon/remote_dispatch_args.h, daemon/remote_dispatch_prototypes.h,
  daemon/remote_dispatch_ret.h, daemon/remote_dispatch_table.h:
  Re-generate files
* src/remote_protocol-structs: Declare new ABIs

* src/remote/remote_protocol.x: Wire protocol definition
* daemon/remote.c: Daemon part
* src/remote/remote_driver.c: Client part
* src/remote_protocol-structs: Add structures

Make procedure parsing more robust, by allowing arbitrary
amounts of whitespaces.

Also make some error messages more verbose.

Rename u_int and unsigned to unsigned int. This gets rid of some special
case code in the generator.

This matches the public API and helps to get rid of some special
case code in the remote generator.

Rename driver API functions and XDR protocol structs.

No functional change included outside of the remote generator.

Once again rename members in the XDR definitions to avoid special case
code in the generator.

Avoids special case handling in the remote generator.

This simplifies the remote protocol code generator.

Also rename 'ret' to 'result' to resolve a naming conflict in the
generator.

This patch just covers the simple functions without explicit return
values. There is more to be handled.

The generator collects the members of the XDR argument structs and uses
this information to generate the function bodies.

Exclude the generated files from offending syntax-checks.

Suggested by Richard W.M. Jones

No functional change included, just a whitespace change.