Also moves all the subordinate structs. This is necessary due to a new
inline function that will be defined in device_conf.h, and also makes
sense, because it is the *device* info that's in the struct. (Actually
a lot more stuff from domain_conf.h could move to this newer file, but
I didn't want to disturb any more than necessary).

I've encountered this error while trying out this feature on some
systems:

  $ VIR_TEST_FILE_ACCESS=1 ./virhashtest \
 libvirt.git/tests/.libs/lt-virhashtest: \
symbol lookup error: libvirt.git/tests/.libs/virtestmock.so: \
undefined symbol: libvirt_event_poll_purge_timeout_semaphore

Problem is, linking just libvirt_utils to virmock.la is not
enough. We might need to link libvirt_probes.lo too.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

There is a lot to explain, but I try to make it as short as
possible. I'd start by pasting some parts of sys/stat.h:

extern int stat (const char *__restrict __file,
		 struct stat *__restrict __buf) __THROW __nonnull ((1, 2));

extern int __REDIRECT_NTH (stat, (const char *__restrict __file,
				  struct stat *__restrict __buf), stat64)
     __nonnull ((1, 2));

__extern_inline int
__NTH (stat (const char *__path, struct stat *__statbuf))
{
  return __xstat (_STAT_VER, __path, __statbuf);
}

Only one of these is effective at once, due to some usage of
the mess we are dealing with in here. So, basically, while
compiling or linking stat() in our code can be transformed into
some other func. Or a dragon.
Now, if you read stat(2) manpage, esp. "C library/kernel
differences" section, you'll learn that glibc uses some tricks
for older applications to work. I haven't gotten around actual
code that does this, but based on my observations, if 'stat'
symbol is found, glibc assumes it's dealing with ancient
application. Unfortunately, it can be just ours stat coming from
our mock. Therefore, calling stat() from a test will end up in
our mock. But since glibc is not exposing the symbol anymore, our
call of real_stat() will SIGSEGV immediately as the pointer to
function is NULL. Therefore, we should expose only those symbols
we know glibc has.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

It wasn't as great idea as I thought. Thing around stat() are
more complicated than that. Therefore we need to revert
86d1705a plus drop use of the macro as introduced in
later patches.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

https://bugzilla.redhat.com/show_bug.cgi?id=1182074

If they're available and we need to pass secrets to qemu, then use the
qemu domain secret object in order to pass the secrets for RBD volumes
instead of passing the base64 encoded secret on the command line.

The goal is to make AES secrets the default and have no user interaction
required in order to allow using the AES mechanism. If the mechanism
is not available, then fall back to the current plain mechanism using
a base64 encoded secret.

New APIs:

qemu_domain.c:
  qemuDomainGetSecretAESAlias:
    Generate/return the secret object alias for an AES Secret Info type.
    This will be called from qemuDomainSecretAESSetup.

  qemuDomainSecretAESSetup: (private)
    This API handles the details of the generation of the AES secret
    and saves the pieces that need to be passed to qemu in order for
    the secret to be decrypted. The encrypted secret based upon the
    domain master key, an initialization vector (16 byte random value),
    and the stored secret. Finally, the requirement from qemu is the IV
    and encrypted secret are to be base64 encoded.

qemu_command.c:
  qemuBuildSecretInfoProps: (private)
    Generate/return a JSON properties object for the AES secret to
    be used by both the command building and eventually the hotplug
    code in order to add the secret object. Code was designed so that
    in the future perhaps hotplug could use it if it made sense.

  qemuBuildObjectSecretCommandLine (private)
    Generate and add to the command line the -object secret for the
    secret. This will be required for the subsequent RBD reference
    to the object.

  qemuBuildDiskSecinfoCommandLine (private)
    Handle adding the AES secret object.

Adjustments:

qemu_domain.c:
  The qemuDomainSecretSetup was altered to call either the AES or Plain
  Setup functions based upon whether AES secrets are possible (we have
  the encryption API) or not, we have secrets, and of course if the
  protocol source is RBD.

qemu_command.c:
  Adjust the qemuBuildRBDSecinfoURI API's in order to generate the
  specific command options for an AES secret, such as:

    -object secret,id=$alias,keyid=$masterKey,data=$base64encodedencrypted,
            format=base64
    -drive file=rbd:pool/image:id=myname:auth_supported=cephx\;none:\
           mon_host=mon1.example.org\:6321,password-secret=$alias,...

  where the 'id=' value is the secret object alias generated by
  concatenating the disk alias and "-aesKey0". The 'keyid= $masterKey'
  is the master key shared with qemu, and the -drive syntax will
  reference that alias as the 'password-secret'. For the -drive
  syntax, the 'id=myname' is kept to define the username, while the
  'key=$base64 encoded secret' is removed.

  While according to the syntax described for qemu commit '60390a21'
  or as seen in the email archive:

    https://lists.gnu.org/archive/html/qemu-devel/2016-01/msg04083.html

  it is possible to pass a plaintext password via a file, the qemu
  commit 'ac1d8878' describes the more feature rich 'keyid=' option
  based upon the shared masterKey.

Add tests for checking/comparing output.

NB: For hotplug, since the hotplug code doesn't add command line
    arguments, passing the encoded secret directly to the monitor
    will suffice.

Make virtTestMain take variable number of libraries to mock.

Currently just a shim to call qemuDomainSecretPlainSetup, but soon to be more

Move the logic from qemuDomainGenerateRandomKey into this new
function, altering the comments, variable names, and error messages
to keep things more generic.

NB: Although perhaps more reasonable to add soemthing to virrandom.c.
    The virrandom.c was included in the setuid_rpc_client, so I chose
    placement in vircrypto.

Introduce virCryptoHaveCipher and virCryptoEncryptData to handle
performing encryption.

 virCryptoHaveCipher:
   Boolean function to determine whether the requested cipher algorithm
   is available. It's expected this API will be called prior to
   virCryptoEncryptdata. It will return true/false.

 virCryptoEncryptData:
   Based on the requested cipher type, call the specific encryption
   API to encrypt the data.

Currently the only algorithm support is the AES 256 CBC encryption.

Adjust tests for the API's

Create a mock for virRandomBytes to generate a not so random value.
This should be usable by other tests that need a not so random number
to be generated by including the virrandommock at preload.

The "random number" generated is based upon the size of the expected
stream of bytes being returned where each byte in the result gets
the index of the array - hence a 4 byte array returns 0x00010203.

According to QEMU docs, the '-m' option for specifying RAM is by default
in MiB, and a suffix of "M" or "G" may be passed for values in MiB and
GiB respectively. This commit adds support and a test for the same.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=812295Signed-off-by: NNishith Shah <nishithshah.2211@gmail.com>

Move the parsing of -m memory to a new function, qemuParseCommandLineMem
Signed-off-by: NNishith Shah <nishithshah.2211@gmail.com>

This prepares the code for other listen types.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Both VNC and SPICE requires the same code to resolve address for listen
type network.  Remove code duplication and create a new function that
will be used in qemuProcessSetupGraphics().
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

This is required for following patches where new listen types will be
introduced.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Move code that decide whether we print the 'listen' attribute or not
into virDomainGraphicsListenDefFormatAddr() function.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

We have both in the code.  Let's use only one format.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Commit 55320c23 introduced a new test for VNC to test if
vnc_auto_unix_socket is set in qemu.conf, but forget to enable it in
qemuxml2argvtest.c.

This patch also moves the code in qemuxml2xmltest.c next to other VNC
tests and refactor the test so we also check the case for parsing active
XML.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

All callers of cpuGetModels expect @models to be NULL-terminated. Once
both x86GetModels and ppc64GetModels were fixed to meet this
expectation, we can explicitly document it.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The architecture specific loaders are now called with a list of all
elements of a given type (rather than a single element at a time). This
avoids the need to reallocate the arrays in CPU maps for each element.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

There's no reason for keeping the models in a linked list. Especially
when we know upfront the total number of models we are loading.

As a nice side effect, this fixes ppc64GetModels to always return a
NULL-terminated list of models.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

There's no reason for keeping the vendors in a linked list. Especially
when we know upfront the total number of models we are loading.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

There's no reason for keeping the features in a linked list. Especially
when we know upfront the total number of features we are loading.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

There's no reason for keeping the vendors in a linked list. Especially
when we know upfront the total number of models we are loading.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

There's no reason for keeping the models in a linked list. Especially
when we know upfront the total number of models we are loading.

As a nice side effect, this fixes x86GetModels to always return a
NULL-terminated list of models.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The support was added by commit 937ebba0 which was released in
1.3.3.

For some disk types (SD), we want to emit the syntax
we used for disks before -device was available even
if QEMU supports -device.

Use the qemuDiskBusNeedsDeviceArg helper to figure out
whether to use the old or new syntax.

Replace the two uses of the withDeviceArg bool in
qemuBuildDiskDriveCommandLine and allow this function to be reused in
qemuBuildDriveStr.

We no longer need to handle -usbdevice and the withDeviceArg
logic becomes clearer.

We have stopped supporting Xenner some time ago.

Since we always asumme support of QEMU_CAPS_DEVICE.

Nowadays we only support qemu 0.12.0+ which provides QEMU_CAPS_DEVICE,
so this is all dead code.

It was only called for QEMUs without QEMU_CAPS_DEVICE,
which we no longer support.

Name the validation function distinctively since it's called in the
parser. Later patches will add function that will validate disk
definitions that are invalid but need to be parsed to avoid losing
domains.

Seems recent versions of Coverity have (mostly) resolved the issue using
ternary operations in VIR_FREE (and now VIR_DISPOSE*) macros.  So let's
just remove it and if necessary handle one off issues as the arise.

Rather than return 0/-1 and/or a pointer to some memory, adjust the
helper to just return the allocated structure or NULL on failure.

Adjust the callers in order to handle that
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Since the callers only ever expect 0 or -1, let's just return that directly
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>