Rather than an opencoded string. This should be a no-op

A destroy operation can take considerable time on large memory
domains due to scrubbing the domain's memory.  Unlock the
virDomainObj while libxl_domain_destroy is executing.

Implement libxlDomainDestroyInternal wrapper to handle unlocking,
calling destroy, and locking.  Change all callers of
libxl_domain_destroy to use the wrapper.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

A job should be acquired at the beginning of a domain destroy operation,
not at the end when cleaning up the domain.  Fix two occurrences of this
late job acquisition in the libxl driver.  Doing so renders
libxlDomainCleanupJob unused, so it is removed.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

Let callers of libxlDomainStart decide when it is appropriate to
acquire a job on the associated virDomainObj.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

Add support for HVM direct kernel boot in libxl.  Also add a
test to verify domXML <-> native conversions.
Signed-off-by: NChunyan Liu <cyliu@suse.com>
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

Recent testing on large memory systems revealed a bug in the Xen xl
tool's freemem() function.  When autoballooning is enabled, freemem()
is used to ensure enough memory is available to start a domain,
ballooning dom0 if necessary.  When ballooning large amounts of memory
from dom0, freemem() would exceed its self-imposed wait time and
return an error.  Meanwhile, dom0 continued to balloon.  Starting the
domain later, after sufficient memory was ballooned from dom0, would
succeed.  The libvirt implementation in libxlDomainFreeMem() suffers
the same bug since it is modeled after freemem().

In the end, the best place to fix the bug on the Xen side was to
slightly change the behavior of libxl_wait_for_memory_target().
Instead of failing after caller-provided wait_sec, the function now
blocks as long as dom0 memory ballooning is progressing.  It will return
failure only when more memory is needed to reach the target and wait_sec
have expired with no progress being made.  See xen.git commit fd3aa246.
There was a dicussion on how this would affect other libxl apps like
libvirt

http://lists.xen.org/archives/html/xen-devel/2015-03/msg00739.html

If libvirt containing this patch was build against a Xen containing
the old libxl_wait_for_memory_target() behavior, libxlDomainFreeMem()
will fail after 30 sec and domain creation will be terminated.
Without this patch and with old libxl_wait_for_memory_target() behavior,
libxlDomainFreeMem() does not succeed after 30 sec, but returns success
anyway.  Domain creation continues resulting in all sorts of fun stuff
like cpu soft lockups in the guest OS.  It was decided to properly fix
libxl_wait_for_memory_target(), and if anything improve the default
behavior of apps using the freemem reference impl in xl.

xl was patched to accommodate the change in libxl_wait_for_memory_target()
with xen.git commit 883b30a0.  This patch does the same in the libxl
driver.  While at it, I changed the logic to essentially match
freemem() in $xensrc/tools/libxl/xl_cmdimpl.c.  It was a bit cleaner
IMO and will make it easier to spot future, potentially interesting
divergences.

If we fail to create the thread we leak the shutdown_info
structure.
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Although needed in the Xen 4.1 libxl days, there is no longer any
benefit to having per-domain libxl_ctx.  On the contrary, their use
makes the code unecessarily complicated and prone to deadlocks under
load.  As suggested by the libxl maintainers, use a single libxl_ctx
as a handle to libxl instead of per-domain ctx's.

One downside to using a single libxl_ctx is there are no longer
per-domain log files for log messages emitted by libxl.  Messages
for all domains will be sent to /var/log/libvirt/libxl/libxl-driver.log.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

libxlDomainFreeMem() is only used in libxl_domain.c and thus should
be declared static.  While at it, change the signature to take a
libxl_ctx instead of libxlDomainObjPrivatePtr, since only the
libxl_ctx is needed.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

This function now only enables domain death events.  Simply call
libxl_evenable_domain_death() instead of an unnecessary wrapper.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

Change the domain event handler code to use the driver-wide
libxl_ctx instead of the domain-specific one.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

Register a domain event handler with the driver-wide libxl_ctx
during driver initialization.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

Informing libxl how to handle its child proceses should be done once
during driver initialization, not once for each domain-specific
libxl_ctx object.  The related libxl documentation in
$xen-src/tools/libxl/libxl_event.h even mentions that "it is best to
call this at initialisation".
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

Long ago I incorrectly associated libxl fd and timer registrations
with per-domain libxl_ctx objects.  When creating a libxlDomainObjPrivate,
a libxl_ctx is allocated, and libxl_osevent_register_hooks is called
passing a pointer to the libxlDomainObjPrivate.  When an fd or timer
registration occurred, the registration callback received the
libxlDomainObjPrivate, containing the per-domain libxl_ctx.  This
libxl_ctx was then used when informing libxl about fd events or
timer expirations.

The problem with this approach is that fd and timer registrations do not
share the same lifespan as libxlDomainObjPrivate, and hence the per-domain
libxl_ctx ojects.  The result is races between per-domain libxl_ctx's being
destoryed and events firing on associated fds/timers, typically manifesting
as an assert in libxl

libxl_internal.h:2788: libxl__ctx_unlock: Assertion `!r' failed

There is no need to associate libxlDomainObjPrivate objects with libxl's
desire to use libvirt's event loop.  Instead, the driver-wide libxl_ctx can
be used for the fd and timer registrations.

This patch moves the fd and timer handling code away from the
domain-specific code in libxl_domain.c into libxl_driver.c.  While at it,
function names were changed a bit to better describe their purpose.

The unnecessary locking was also removed since the code simply provides a
wrapper over the event loop interface.  Indeed the locks may have been
causing some deadlocks when repeatedly creating/destroying muliple domains.
There have also been rumors about such deadlocks during parallel OpenStack
Tempest runs.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

This patch adds code that parses and formats configuration for memory
devices.

A simple configuration would be:
<memory model='dimm'>
  <target>
    <size unit='KiB'>524287</size>
    <node>0</node>
  </target>
</memory>

A complete configuration of a memory device:
<memory model='dimm'>
  <source>
    <pagesize unit='KiB'>4096</pagesize>
    <nodemask>1-3</nodemask>
  </source>
  <target>
    <size unit='KiB'>524287</size>
    <node>1</node>
  </target>
</memory>

This patch preemptively forbids use of the <memory> device in individual
drivers so the users are warned right away that the device is not
supported.

Add a XML element that will allow to specify maximum supportable memory
and the count of memory slots to use with memory hotplug.

To avoid possible confusion and misuse of the new element this patch
also explicitly forbids the use of the maxMemory setting in individual
drivers's post parse callbacks. This limitation will be lifted when the
support is implemented.

With the current control flow the post parse callback returned success
right away for fully virtualized VMs. To allow adding additional checks
into the post parse callback tweak the conditions so that the function
doesn't return early except for error cases.

To clarify the original piece of code borrow the wording from the commit
message for the patch that introduced the code.

xen.git commit babeca32 added a pkgconfig file for libxenlight,
allowing libxl apps to determine the location of Xen binaries
such as firmware blobs, device emulator, etc.

This patch adds support for xenlight.pc in the libxl driver, falling
back to the previous configure logic if not found.  It introduces
LIBXL_FIRMWARE_DIR and LIBXL_EXECBIN_DIR to define the firmware and
libexec_bin locations.  If xenlight.pc does not exist, the defines
are set to the current hardcoded paths.  The capabilities'
<emulator> and <loader> elements are updated to use the paths.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

When converting domXML from native, the libxl driver was overwriting
useful errors from the xenconfig parsing code with a useless, generic
error.  E.g. "internal error: parsing xm config failed" vs
"internal error: config value usbdevice was malformed".  Remove the
redundant (and useless) error reporting in the libxl driver.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

Commit 4ab8cd77 added a check requiring input devices to have
a bus type of VIR_DOMAIN_INPUT_BUS_USB, failing to start the
domain otherwise.  But virDomainDefParseXML adds implicit mouse
and keyboard if a graphics device is configured.  See calls to
virDomainDefMaybeAddInput.

The regression is fixed by removing the check requiring USB input
devices, and skipping non-USB input devices when populating USB
'usbdevice' in libxl_domain_build_info struct.

Since both Vcpu and IOThreads code use the same API's, alter the naming
of the API's to remove the "Vcpu" specific reference

Since both Vcpu and IOThreads code use the same API's, alter the naming
of the API's to remove the "Vcpu" specific reference

Since we're not specifically a vcpu related structure anymore...

As pointed out by jtomko in his review of the IOThreads pinning code:

http://www.redhat.com/archives/libvir-list/2015-March/msg00495.html

there are some comments sprinkled in indicating IOThreads were using
the same structure as the VcpuPin code...

This is the first patch of a few that will change the virDomainVcpuPin*
structures and code to just virDomainPin* - starting with the data
structure naming...

As there are two possible approaches to define a domain's memory size -
one used with legacy, non-NUMA VMs configured in the <memory> element
and per-node based approach on NUMA machines - the user needs to make
sure that both are specified correctly in the NUMA case.

To avoid this burden on the user I'd like to replace the NUMA case with
automatic totaling of the memory size. To achieve this I need to replace
direct access to the virDomainMemtune's 'max_balloon' field with
two separate getters depending on the desired size.

The two sizes are needed as:
1) Startup memory size doesn't include memory modules in some
hypervisors.
2) After startup these count as the usable memory size.

Note that the comments for the functions are future aware and document
state that will be present after a few later patches.

It will not be possible to detach such device later. Also improve
logging in such cases.
Signed-off-by: NMarek Marczykowski-Górecki <marmarek@invisiblethingslab.com>

Signed-off-by: NMarek Marczykowski-Górecki <marmarek@invisiblethingslab.com>

A helper that never returns an error and treats bits out of bitmap range
as false.

Use it everywhere we use ignore_value on virBitmapGetBit, or loop over
the bitmap size.

In the old days of a global driver lock, it was necessary to unlock
the driver after a domain restore operation.  When the global lock
was removed from the driver, some remnants were left behind in
libxlDomainRestoreFlags.  Remove this unneeded (and incorrect) code.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

Instead of using the libxl_ctx in the libxlDomainObjPrivatePtr,
use the ctx passed to the callback.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

Domain death watch is already disabled in libxlDomainCleanup.  No
need to disable it a second and third time.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

This implement handling of <backenddomain name=''/>  parameter introduced
in previous patch.

Works on Xen >= 4.3, because only there libxl supports setting backend
domain by name.  Specifying backend domain by ID or UUID is currently not
supported.
Signed-off-by: NMarek Marczykowski-Górecki <marmarek@invisiblethingslab.com>

Periodically my Coverity scan will return a checked_return failure
for libxlDomainShutdownThread call to libxlDomainStart. Followed the
libxlAutostartDomain example in order to check the status, emit a
message, and continue on.

When initializing a libxl_domain_build_info struct with
libxl_domain_build_info_init(), VNC is enabled by default.  As a
result, VMs configured with no graphics still have VNC enabled.
This behavior is a regression wrt to the legacy Xen driver.
Signed-off-by: NMarek Marczykowski-Górecki <marmarek@invisiblethingslab.com>

Do not silently ignore its value. LibXL support only one address, so
refuse multiple IPs.
Signed-off-by: NMarek Marczykowski-Górecki <marmarek@invisiblethingslab.com>

Otherwise domainCreateWithFlags via remote returns -1 as domid.
Signed-off-by: NMarek Marczykowski-Górecki <marmarek@invisiblethingslab.com>

For stateless, client side drivers, it is never correct to
probe for secondary drivers. It is only ever appropriate to
use the secondary driver that is associated with the
hypervisor in question. As a result the ESX & HyperV drivers
have both been forced to do hacks where they register no-op
drivers for the ones they don't implement.

For stateful, server side drivers, we always just want to
use the same built-in shared driver. The exception is
virtualbox which is really a stateless driver and so wants
to use its own server side secondary drivers. To deal with
this virtualbox has to be built as 3 separate loadable
modules to allow registration to work in the right order.

This can all be simplified by introducing a new struct
recording the precise set of secondary drivers each
hypervisor driver wants

struct _virConnectDriver {
    virHypervisorDriverPtr hypervisorDriver;
    virInterfaceDriverPtr interfaceDriver;
    virNetworkDriverPtr networkDriver;
    virNodeDeviceDriverPtr nodeDeviceDriver;
    virNWFilterDriverPtr nwfilterDriver;
    virSecretDriverPtr secretDriver;
    virStorageDriverPtr storageDriver;
};

Instead of registering the hypervisor driver, we now
just register a virConnectDriver instead. This allows
us to remove all probing of secondary drivers. Once we
have chosen the primary driver, we immediately know the
correct secondary drivers to use.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The path to the pty of a Xen PV console is set only in
virDomainOpenConsole. But this is done too late. A call to
virDomainGetXMLDesc done before OpenConsole will not have the path to
the pty, but a call after OpenConsole will.

e.g. of the current issue.
Starting a domain with '<console type="pty"/>'
Then:
virDomainGetXMLDesc():
  <devices>
    <console type='pty'>
      <target type='xen' port='0'/>
    </console>
  </devices>
virDomainOpenConsole()
virDomainGetXMLDesc():
  <devices>
    <console type='pty' tty='/dev/pts/30'>
      <source path='/dev/pts/30'/>
      <target type='xen' port='0'/>
    </console>
  </devices>

The patch intend to have the TTY path on the first call of GetXMLDesc.
This is done by setting up the path at domain start up instead of in
OpenConsole.

https://bugzilla.redhat.com/show_bug.cgi?id=1170743Signed-off-by: NAnthony PERARD <anthony.perard@citrix.com>