2014-02-05 14:18:46 +00:00
|
|
|
/*
|
2016-04-26 16:49:48 +00:00
|
|
|
* Copyright (C) 2014-2016 Red Hat, Inc.
|
2014-02-05 14:18:46 +00:00
|
|
|
*
|
|
|
|
* This library is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU Lesser General Public
|
|
|
|
* License as published by the Free Software Foundation; either
|
|
|
|
* version 2.1 of the License, or (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This library is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
* Lesser General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU Lesser General Public
|
|
|
|
* License along with this library. If not, see
|
|
|
|
* <http://www.gnu.org/licenses/>.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <config.h>
|
|
|
|
|
2014-02-06 12:54:53 +00:00
|
|
|
#include "internal.h"
|
qemu: Utilize qemu secret objects for RBD auth/secret
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.
2016-04-11 15:26:14 +00:00
|
|
|
#include "viralloc.h"
|
2016-03-23 15:19:26 +00:00
|
|
|
#include "vircommand.h"
|
qemu: Utilize qemu secret objects for RBD auth/secret
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.
2016-04-11 15:26:14 +00:00
|
|
|
#include "vircrypto.h"
|
2015-02-02 10:26:49 +00:00
|
|
|
#include "virmock.h"
|
2016-03-23 15:19:26 +00:00
|
|
|
#include "virnetdev.h"
|
2016-06-27 10:17:59 +00:00
|
|
|
#include "virnetdevip.h"
|
2016-03-23 15:19:26 +00:00
|
|
|
#include "virnetdevtap.h"
|
2016-12-22 09:33:28 +00:00
|
|
|
#include "virnetdevopenvswitch.h"
|
2016-03-23 15:19:26 +00:00
|
|
|
#include "virnuma.h"
|
qemu: Utilize qemu secret objects for RBD auth/secret
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.
2016-04-11 15:26:14 +00:00
|
|
|
#include "virrandom.h"
|
2016-03-23 15:19:26 +00:00
|
|
|
#include "virscsi.h"
|
2016-11-22 03:58:17 +00:00
|
|
|
#include "virscsivhost.h"
|
2015-11-18 00:44:13 +00:00
|
|
|
#include "virstring.h"
|
|
|
|
#include "virtpm.h"
|
2016-03-23 15:19:26 +00:00
|
|
|
#include "virutil.h"
|
2018-04-17 10:11:17 +00:00
|
|
|
#include "qemu/qemu_interface.h"
|
2018-03-14 12:16:11 +00:00
|
|
|
#include "qemu/qemu_command.h"
|
2014-02-06 12:54:53 +00:00
|
|
|
#include <time.h>
|
2015-02-02 10:26:49 +00:00
|
|
|
#include <unistd.h>
|
2018-03-14 12:16:11 +00:00
|
|
|
#include <fcntl.h>
|
2015-02-02 10:26:49 +00:00
|
|
|
|
2015-11-18 00:44:13 +00:00
|
|
|
#define VIR_FROM_THIS VIR_FROM_NONE
|
|
|
|
|
2015-02-02 10:26:49 +00:00
|
|
|
long virGetSystemPageSize(void)
|
|
|
|
{
|
|
|
|
return 4096;
|
|
|
|
}
|
2014-02-05 14:18:46 +00:00
|
|
|
|
|
|
|
time_t time(time_t *t)
|
|
|
|
{
|
|
|
|
const time_t ret = 1234567890;
|
|
|
|
if (t)
|
|
|
|
*t = ret;
|
|
|
|
return ret;
|
|
|
|
}
|
2014-11-04 02:44:40 +00:00
|
|
|
|
2018-05-02 15:35:21 +00:00
|
|
|
bool
|
|
|
|
virNumaIsAvailable(void)
|
|
|
|
{
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2014-11-04 02:44:40 +00:00
|
|
|
int
|
|
|
|
virNumaGetMaxNode(void)
|
|
|
|
{
|
2018-09-13 08:55:21 +00:00
|
|
|
return 7;
|
2014-11-04 02:44:40 +00:00
|
|
|
}
|
2014-11-06 11:16:54 +00:00
|
|
|
|
2018-05-02 15:35:21 +00:00
|
|
|
/* We shouldn't need to mock virNumaNodeIsAvailable() and *definitely* not
|
|
|
|
* virNumaNodesetIsAvailable(), but it seems to be the only way to get
|
|
|
|
* mocking to work with Clang on FreeBSD, so keep these duplicates around
|
|
|
|
* until we figure out a cleaner solution */
|
2014-11-06 11:16:54 +00:00
|
|
|
bool
|
|
|
|
virNumaNodeIsAvailable(int node)
|
|
|
|
{
|
|
|
|
return node >= 0 && node <= virNumaGetMaxNode();
|
|
|
|
}
|
2018-05-02 15:35:21 +00:00
|
|
|
|
|
|
|
bool
|
|
|
|
virNumaNodesetIsAvailable(virBitmapPtr nodeset)
|
|
|
|
{
|
|
|
|
ssize_t bit = -1;
|
|
|
|
|
|
|
|
if (!nodeset)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
while ((bit = virBitmapNextSetBit(nodeset, bit)) >= 0) {
|
|
|
|
if (virNumaNodeIsAvailable(bit))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
2015-11-18 00:44:13 +00:00
|
|
|
|
|
|
|
char *
|
|
|
|
virTPMCreateCancelPath(const char *devpath)
|
|
|
|
{
|
|
|
|
char *path;
|
|
|
|
(void)devpath;
|
|
|
|
|
|
|
|
ignore_value(VIR_STRDUP(path, "/sys/class/misc/tpm0/device/cancel"));
|
|
|
|
|
|
|
|
return path;
|
|
|
|
}
|
2015-12-10 13:36:51 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Large values for memory would fail on 32 bit systems, despite having
|
|
|
|
* variables that support it.
|
|
|
|
*/
|
|
|
|
unsigned long long
|
|
|
|
virMemoryMaxValue(bool capped ATTRIBUTE_UNUSED)
|
|
|
|
{
|
|
|
|
return LLONG_MAX;
|
|
|
|
}
|
2016-03-23 08:57:06 +00:00
|
|
|
|
|
|
|
char *
|
|
|
|
virSCSIDeviceGetSgName(const char *sysfs_prefix ATTRIBUTE_UNUSED,
|
|
|
|
const char *adapter ATTRIBUTE_UNUSED,
|
|
|
|
unsigned int bus ATTRIBUTE_UNUSED,
|
|
|
|
unsigned int target ATTRIBUTE_UNUSED,
|
|
|
|
unsigned long long unit ATTRIBUTE_UNUSED)
|
|
|
|
{
|
|
|
|
char *ret;
|
|
|
|
|
|
|
|
ignore_value(VIR_STRDUP(ret, "sg0"));
|
|
|
|
return ret;
|
|
|
|
}
|
2016-03-23 15:19:26 +00:00
|
|
|
|
2016-11-22 03:58:17 +00:00
|
|
|
int
|
|
|
|
virSCSIVHostOpenVhostSCSI(int *vhostfd)
|
|
|
|
{
|
|
|
|
*vhostfd = STDERR_FILENO + 1;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-03-23 15:19:26 +00:00
|
|
|
int
|
|
|
|
virNetDevTapCreate(char **ifname,
|
|
|
|
const char *tunpath ATTRIBUTE_UNUSED,
|
|
|
|
int *tapfd,
|
|
|
|
size_t tapfdSize,
|
|
|
|
unsigned int flags ATTRIBUTE_UNUSED)
|
|
|
|
{
|
|
|
|
size_t i;
|
|
|
|
|
|
|
|
for (i = 0; i < tapfdSize; i++)
|
|
|
|
tapfd[i] = STDERR_FILENO + 1 + i;
|
|
|
|
|
2016-07-09 06:57:46 +00:00
|
|
|
VIR_FREE(*ifname);
|
2016-03-23 15:19:26 +00:00
|
|
|
return VIR_STRDUP(*ifname, "vnet0");
|
|
|
|
}
|
|
|
|
|
|
|
|
int
|
|
|
|
virNetDevSetMAC(const char *ifname ATTRIBUTE_UNUSED,
|
|
|
|
const virMacAddr *macaddr ATTRIBUTE_UNUSED)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-06-27 10:17:59 +00:00
|
|
|
int virNetDevIPAddrAdd(const char *ifname ATTRIBUTE_UNUSED,
|
|
|
|
virSocketAddr *addr ATTRIBUTE_UNUSED,
|
|
|
|
virSocketAddr *peer ATTRIBUTE_UNUSED,
|
|
|
|
unsigned int prefix ATTRIBUTE_UNUSED)
|
2016-04-26 16:49:48 +00:00
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-04-04 21:00:06 +00:00
|
|
|
int
|
|
|
|
virNetDevSetOnline(const char *ifname ATTRIBUTE_UNUSED,
|
|
|
|
bool online ATTRIBUTE_UNUSED)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-03-23 15:19:26 +00:00
|
|
|
int
|
2016-04-13 08:36:00 +00:00
|
|
|
virNetDevRunEthernetScript(const char *ifname ATTRIBUTE_UNUSED,
|
|
|
|
const char *script ATTRIBUTE_UNUSED)
|
2016-03-23 15:19:26 +00:00
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-11-14 15:48:27 +00:00
|
|
|
char *
|
|
|
|
virHostGetDRMRenderNode(void)
|
|
|
|
{
|
|
|
|
char *dst = NULL;
|
|
|
|
|
|
|
|
ignore_value(VIR_STRDUP(dst, "/dev/dri/foo"));
|
|
|
|
return dst;
|
|
|
|
}
|
|
|
|
|
2018-08-14 13:02:56 +00:00
|
|
|
static void (*real_virCommandPassFD)(virCommandPtr cmd, int fd, unsigned int flags);
|
|
|
|
|
2018-08-14 11:50:01 +00:00
|
|
|
static const int testCommandPassSafeFDs[] = { 1730, 1731 };
|
2018-08-14 13:02:56 +00:00
|
|
|
|
2016-03-23 15:19:26 +00:00
|
|
|
void
|
2018-08-14 13:02:56 +00:00
|
|
|
virCommandPassFD(virCommandPtr cmd,
|
|
|
|
int fd,
|
|
|
|
unsigned int flags)
|
2016-03-23 15:19:26 +00:00
|
|
|
{
|
2018-08-14 13:02:56 +00:00
|
|
|
size_t i;
|
|
|
|
|
|
|
|
for (i = 0; i < ARRAY_CARDINALITY(testCommandPassSafeFDs); i++) {
|
|
|
|
if (testCommandPassSafeFDs[i] == fd) {
|
|
|
|
if (!real_virCommandPassFD)
|
|
|
|
VIR_MOCK_REAL_INIT(virCommandPassFD);
|
|
|
|
|
|
|
|
real_virCommandPassFD(cmd, fd, flags);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
2016-03-23 15:19:26 +00:00
|
|
|
}
|
qemu: Utilize qemu secret objects for RBD auth/secret
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.
2016-04-11 15:26:14 +00:00
|
|
|
|
2016-12-22 09:33:28 +00:00
|
|
|
int
|
|
|
|
virNetDevOpenvswitchGetVhostuserIfname(const char *path ATTRIBUTE_UNUSED,
|
|
|
|
char **ifname)
|
|
|
|
{
|
|
|
|
return VIR_STRDUP(*ifname, "vhost-user0");
|
|
|
|
}
|
2018-04-17 10:11:17 +00:00
|
|
|
|
|
|
|
int
|
|
|
|
qemuInterfaceOpenVhostNet(virDomainDefPtr def ATTRIBUTE_UNUSED,
|
|
|
|
virDomainNetDefPtr net,
|
|
|
|
int *vhostfd,
|
|
|
|
size_t *vhostfdSize)
|
|
|
|
{
|
|
|
|
size_t i;
|
|
|
|
|
2019-01-21 22:59:02 +00:00
|
|
|
if (!virDomainNetIsVirtioModel(net)) {
|
2018-04-17 10:11:17 +00:00
|
|
|
*vhostfdSize = 0;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (i = 0; i < *vhostfdSize; i++)
|
|
|
|
vhostfd[i] = STDERR_FILENO + 42 + i;
|
|
|
|
return 0;
|
|
|
|
}
|
2018-03-14 12:16:11 +00:00
|
|
|
|
|
|
|
|
|
|
|
int
|
|
|
|
qemuOpenChrChardevUNIXSocket(const virDomainChrSourceDef *dev ATTRIBUTE_UNUSED)
|
|
|
|
|
|
|
|
{
|
|
|
|
/* We need to return an FD number for a UNIX listener socket,
|
|
|
|
* which will be given to QEMU via a CLI arg. We need a fixed
|
|
|
|
* number to get stable tests. This is obviously not a real
|
|
|
|
* FD number, so when virCommand closes the FD in the parent
|
|
|
|
* it will get EINVAL, but that's (hopefully) not going to
|
|
|
|
* be a problem....
|
|
|
|
*/
|
|
|
|
if (fcntl(1729, F_GETFD) != -1)
|
|
|
|
abort();
|
|
|
|
return 1729;
|
|
|
|
}
|
2018-08-14 11:50:01 +00:00
|
|
|
|
|
|
|
|
|
|
|
int
|
|
|
|
qemuBuildTPMOpenBackendFDs(const char *tpmdev ATTRIBUTE_UNUSED,
|
|
|
|
const char *cancel_path ATTRIBUTE_UNUSED,
|
|
|
|
int *tpmfd,
|
|
|
|
int *cancelfd)
|
|
|
|
{
|
|
|
|
if (fcntl(1730, F_GETFD) != -1 ||
|
|
|
|
fcntl(1731, F_GETFD) != -1)
|
|
|
|
abort();
|
|
|
|
|
|
|
|
*tpmfd = 1730;
|
|
|
|
*cancelfd = 1731;
|
|
|
|
return 0;
|
|
|
|
}
|