If we ever fail to properly set jobinfo->statsType,
qemuDomainJobInfoToParams would return -1 without setting an error.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1585108
When updating a live device users might pass different alias than
the one the device has. Currently, this is silently ignored which
goes against our behaviour for other parts of the device where we
explicitly allow only certain changes and error out loudly on
anything else.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
This was lost in c57f3fd2f8. But now we are going to
need it again (except the DETACH action where checking for device
compatibility does not make much sense anyway).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
When updating device it's worth parsing live info too as users
might want to update it as well.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Mediated devices of model 'vfio-ccw' are using CCW addresses, so make
sure to call the correct address preparation code for the model.
Reviewed-by: Shalini Chellathurai Saroja <shalini@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Signed-off-by: Bjoern Walk <bwalk@linux.ibm.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Remove the callbacks that the nwfilter driver registers with the domain
object config layer. Instead make the current helper methods call into
the public API for creating/deleting nwfilter bindings.
Reviewed-by: John Ferlan <jferlan@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Now that the nwfilter driver keeps a list of bindings that it has
created, there is no need for the complex virt driver callbacks. It is
possible to simply iterate of the list of recorded filter bindings.
This means that rebuilding filters no longer has to acquire any locks on
the virDomainObj objects, as they're never touched.
Reviewed-by: John Ferlan <jferlan@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Add comma escaping for netsource. This is done here because
qemuBuildNetworkDriveStr has other external callers which
may not expect an escaped comma; however, this particular
command building path needs to perform the escaping for the
hostdev command line, so we do it now to ensure src->path
and src->host->name are covered.
Signed-off-by: Anya Harter <aharter@redhat.com>
If a thread is unable to acquire a job (e.g. because of timeout)
an error is reported and the error message contains reference to
the other thread holding the job. Well, the error message should
report agent job too as it is yet another source of possible
failure.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
This doesn't seem very useful at the moment, but it will make
sense once we introduce another HPT-related setting.
The output XML is decoupled from the input XML in preparation
of future changes as well; while doing so, we can shave a few
lines off the latter.
This commit is best viewed with 'git show -w'.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
We're going to introduce a second HPT-related setting soon,
at which point using a single location to store everything is
no longer going to cut it.
This mostly, but not completely, reverts 3dd1eb3b26.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
The UNIX socket FDs were we passing to QEMU inherited a label based on
libvirtd's context. QEMU is thus denied ability to access the UNIX
socket. We need to use the security manager to change our current
context temporarily when creating the UNIX socket FD.
Reviewed-by: Laine Stump <laine@laine.org>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
If a thread is unable to start a job (e.g. because of timeout)
a warning is printed into the logs. So far, the message does not
contain agent job info. Add it as it might help future debugging.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
As qemuMonitorJSONIOProcess will call qemuMonitorJSONIOProcessEvent
which unlocks the monitor mutex, there is some extreme situation,
eg qemu send message to monitor twice in a short time, where the
local viriable 'msg' of qemuMonitorIOProcess could be a wild point:
1. qemuMonitorSend() assign mon->msg to parameter 'msg', which is alse a
local variable of its caller qemuMonitorJSONCommandWithFd(), cause
eventloop to send message to monitor, then wait condition.
2. qemu send message to monitor for the first time immediately.
3. qemuMonitorIOProcess() is called, then wake up the qemuMonitorSend()
thread, but the qemuMonitorSend() thread stuck for a while as cpu pressure
or some other reasons, which means the qemu monitor is still unlocked.
4. qemu send event message to monitor for the second time,
such as RTC_CHANGE event
5. qemuMonitorIOProcess() is called again, the local viriable 'msg' is
assigned to mon->msg.
6. qemuMonitorIOProcess() call qemuMonitorJSONIOProcess() to deal with
the qemu event.
7. qemuMonitorJSONIOProcess() unlock the qemu monitor in the macro
'QEMU_MONITOR_CALLBACK', then qemuMonitorSend() thread get the mutex
and free the mon->msg, assign mon->msg to NULL.
Signed-off-by: Weilun Zhu <zhuweilun@huawei.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1591628
Attempting to use the FORCE flag for snapshot-revert was resulting
in failures because qemuProcessStart and qemuProcessStartCPUs were
using QEMU_ASYNC_JOB_START after a qemuProcessStop resulting in an
error when entering the monitor:
error: internal error: unexpected async job 6 type expected 0
So create a local @jobType, initialize to QEMU_ASYNC_JOB_START, and
change to QEMU_ASYNC_JOB_NONE if we end up in the --force path
where the qemuProcessStop is run before a Start and StartCPUs.
Signed-off-by: John Ferlan <jferlan@redhat.com>
ACKed-by: Michal Privoznik <mprivozn@redhat.com>
If the the snapshot revert involves a forced revert option, then
let's not cause startup to change the genid flag in order to signify
that we're still running the same/previous guest and not some
snapshot reversion.
Related to:
https://bugzilla.redhat.com/show_bug.cgi?id=1149445
Signed-off-by: John Ferlan <jferlan@redhat.com>
ACKed-by: Michal Privoznik <mprivozn@redhat.com>
Use and set the @start_flags at the top of the RUNNING and PAUSED
transitions to GEN_VMID | PAUSED.
Signed-off-by: John Ferlan <jferlan@redhat.com>
ACKed-by: Michal Privoznik <mprivozn@redhat.com>
Promote the @start_flags to the top of the function, a
subsequent patch needs to use it.
Signed-off-by: John Ferlan <jferlan@redhat.com>
ACKed-by: Michal Privoznik <mprivozn@redhat.com>
Make it clearer what asyncJob type was passed and what was expected.
Signed-off-by: John Ferlan <jferlan@redhat.com>
ACKed-by: Michal Privoznik <mprivozn@redhat.com>
VMs with hardcoded platform network devices are forced to use old
style '-net nic' command line config. Current we use qemu's vlan
option to hook this with the '-netdev' host side of things.
However since qemu 1.2 there is '-net nic,netdev=X' option for
explicitly referencing a netdev ID, which is more inline with
typical VM commandlines, so let's switch to that
Signed-off-by: Cole Robinson <crobinso@redhat.com>
There are two sets of functions here:
1) some functions talk on both monitor and agent monitor,
2) some functions only talk on agent monitor.
For functions from set 1) we need to use
qemuDomainObjBeginJobWithAgent() and for functions from set 2) we
need to use qemuDomainObjBeginAgentJob() only.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Now that we have agent job we can grab it while freezing/thawing
guest file system before/after doing snapshot.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
The point is to break QEMU_JOB_* into smaller pieces which
enables us to achieve higher throughput. For instance, if there
are two threads, one is trying to query something on qemu
monitor while the other is trying to query something on agent
monitor these two threads would serialize. There is not much
reason for that.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Introduce guest agent specific job categories to allow threads to
run agent monitor specific jobs while normal monitor jobs can
also be running.
Alter _qemuDomainJobObj in order to duplicate certain fields that
will be used for guest agent specific tasks to increase
concurrency and throughput and reduce serialization.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Be more consistent and use 'preparing' instead of 'prepare' here.
Signed-off-by: Luyao Huang <lhuang@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
When commit 6718132d enforced usage of the cleanup label, it forgot to
set the @ret variable to 0 on "success" exit path.
Signed-off-by: Luyao Huang <lhuang@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
If measurement retrieval fails we'd forget to call ExitMonitor to unlock
the monitor.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reported-by: Luyao Huang <lhuang@redhat.com>
Reviewed-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Since it's being called with QEMU_ASYNC_JOB_NONE which is what
qemuDomainObjEnterMonitor is going to use with the internal helper,
let's use that one instead.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Marc Hartmayer <mhartmay@linux.ibm.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1552092
If there's a long running job it might cause us to wait 30
seconds before we give up acquiring the job. This is problematic
to interactive applications that fetch stats repeatedly every few
seconds.
The solution is to introduce
VIR_CONNECT_GET_ALL_DOMAINS_STATS_NOWAIT flag which tries to
acquire job but does not wait if acquiring failed.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
The aim of this API is to allow the caller to do best effort.
Some functions can work even when acquiring the job fails (e.g.
qemuConnectGetAllDomainStats()). But what they can't bear is
delay if they have to wait up to 30 seconds for each domain that
is processing some other job.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
The variable is initialized to -1 already. There's no way it can
be overwritten by the time control gets to the line I'm removing.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Provide a small comment on the function and its parameters.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Add comma escaping for cfg->spiceTLSx509certdir and
graphics->data.spice.rendernode.
Signed-off-by: Anya Harter <aharter@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Add comma escaping for smartcard->data.cert.file[i] and
smartcard->data.cert.database.
Signed-off-by: Anya Harter <aharter@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Add comma escaping for dev->data.file.path in cases
VIR_DOMAIN_CHR_TYPE_DEV and VIR_DOMAIN_CHR_TYPE_PIPE.
Signed-off-by: Anya Harter <aharter@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Fix the return value status comparison checking for call to
virJSONValueObjectCreateVArgs introduced by commit id f0a23c0c3.
If a NULL arglist is passed, then a 0 is returned which is a
valid status and we only should fail when the return is < 0.
This resolves an issue seen for "virsh iothreadadd $dom $iothread"
where a "error: An error occurred, but the cause is unknown" error
was generated when trying to hotplug an IOThread to a domain since
qemuDomainHotplugAddIOThread passes a NULL arglist.
Signed-off-by: John Ferlan <jferlan@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1591561
For reasons I don't understand my original patch of 75f0fd5112
freed not only the chardev from domain but also the one from
passed virDomainDeviceDefPtr. This caused no troubles until now,
because those two pointers were separate, but after I've
introduced virDomainDetachDeviceAlias() they became the same
resulting in double free on detach.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The query-sev-capabilities command fails if SEV is not compiled in,
even though both the command and -object sev-guest are present
in that case :/
Ignore the errors to avoid spamming the logs:
internal error: unable to execute QEMU command 'query-sev-capabilities': SEV feature is not available
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Some identifiers use Sev, some SEV. Prefer the latter.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
A common cleanup path for both the success and the error case.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Make the function prefix match the file it's in.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Free tmp even on failure.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
It is only used in one place.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The buffer is not freed anywhere. Nor in the error paths. Also
the usage virCommand with respect to buffer is very odd.
==2504== 1,100 bytes in 1 blocks are definitely lost in loss record 167 of 175
==2504== at 0x4C2CE3F: malloc (vg_replace_malloc.c:298)
==2504== by 0x4C2F1BF: realloc (vg_replace_malloc.c:785)
==2504== by 0x5D32EE2: virReallocN (viralloc.c:245)
==2504== by 0x5D37278: virBufferGrow (virbuffer.c:150)
==2504== by 0x5D3783E: virBufferVasprintf (virbuffer.c:408)
==2504== by 0x5D377A9: virBufferAsprintf (virbuffer.c:381)
==2504== by 0x57017C1: qemuBuildSevCommandLine (qemu_command.c:9707)
==2504== by 0x57030F7: qemuBuildCommandLine (qemu_command.c:10324)
==2504== by 0x575FA48: qemuProcessCreatePretendCmd (qemu_process.c:6644)
==2504== by 0x11351A: testCompareXMLToArgv (qemuxml2argvtest.c:564)
==2504== by 0x1392F7: virTestRun (testutils.c:180)
==2504== by 0x137895: mymain (qemuxml2argvtest.c:2900)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The variable points to a buffer not a domain object therefore its
current name is misleading.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
And replace all calls with virObjectEventStateQueue such that:
qemuDomainEventQueue(driver, event);
becomes:
virObjectEventStateQueue(driver->domainEventState, event);
And remove NULL checking from all callers.
Signed-off-by: Anya Harter <aharter@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
qemucapabilitiestest for simplicity uses one test monitor object for
simulating work of two separate inquiries of the qemu process. To allow
better testing in the future it will be required to reset the counter
so that it accurately simulates how qemu would behave.
This patch adds a private monitor API which allows to reset the counter
which will be usable only in tests.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Since virConfGetValueBool() can return earlier, the parameter 'value'
might be not initialised properly inside this method. Another proof:
Valgrind is returning this error during the libvirtd daemon startup:
==16199== Conditional jump or move depends on uninitialised value(s)
==16199== at 0x27FFFEF4: virQEMUDriverConfigLoadFile (qemu_conf.c:809)
==16199== by 0x2807665C: qemuStateInitialize (qemu_driver.c:654)
==16199== by 0x5535428: virStateInitialize (libvirt.c:662)
==16199== by 0x12AED8: daemonRunStateInit (remote_daemon.c:802)
==16199== by 0x536DE18: virThreadHelper (virthread.c:206)
==16199== by 0x6CB36DA: start_thread (pthread_create.c:463)
==16199== by 0x6FEC88E: clone (clone.S:95)
Signed-off-by: Julio Faracco <jcfaracco@gmail.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
This patch implements the internal driver API for launch event into
qemu driver. When SEV is enabled, execute 'query-sev-launch-measurement'
to get the measurement of memory encrypted through launch sequence.
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
QEMU >= 2.12 provides 'sev-guest' object which is used to launch encrypted
VMs on AMD platform using SEV feature. The various inputs required to
launch SEV guest is provided through the <launch-security> tag. A typical
SEV guest launch command line looks like this:
-object sev-guest,id=sev0,cbitpos=47,reduced-phys-bits=5 ...\
-machine memory-encryption=sev0 \
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
QEMU uses /dev/sev device while creating the SEV guest, lets add /dev/sev
in the list of devices allowed to be accessed by the QEMU.
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Extend hypervisor capabilities to include sev feature. When available,
hypervisor supports launching an encrypted VM on AMD platform. The
sev feature tag provides additional details like Platform Diffie-Hellman
(PDH) key and certificate chain which can be used by the guest owner to
establish a cryptographic session with the SEV firmware to negotiate
keys used for attestation or to provide secret during launch.
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
QEMU version >= 2.12 provides support for launching an encrypted VMs on
AMD x86 platform using Secure Encrypted Virtualization (SEV) feature.
This patch adds support to query the SEV capability from the qemu.
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1583623
When attaching a virtio-scsi with IOThreads for the config of a
live domain, allow the <address> to not be defined thus allowing
post parse processing to fill in the address. This allows parsing
of an individual device to succeed for attach config.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Make the error a bit clearer that virtio-scsi IOThreads require
virtio pci or ccw controller address types.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Fix the error message to indicate what exactly is failing - that
the controller index provided matches an existing controller.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Commit id '7ef0471bf' added a new parameter to qemuMonitorOpen,
but didn't update the ATTTRIBUTE_NONNULL for the @cb (param 5).
Signed-off-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Katerina Koukiou <kkoukiou@redhat.com>
On start up of libvirtd the worker pool of the QEMU driver must be
initialized before trying to reconnect to all the running QEMU
instances. Otherwise segmentation faults can occur if there are QEMU
monitor events emitted.
#0 __GI___pthread_mutex_lock
#1 0x000003fffdba9e62 in virMutexLock
#2 0x000003fffdbab2dc in virThreadPoolSendJob
#3 0x000003ffd8343b70 in qemuProcessHandleSerialChanged
#4 0x000003ffd836a776 in qemuMonitorEmitSerialChange
#5 0x000003ffd8378e52 in qemuMonitorJSONHandleSerialChange
#6 0x000003ffd8378930 in qemuMonitorJSONIOProcessEvent
#7 0x000003ffd837edee in qemuMonitorJSONIOProcessLine
#8 0x000003ffd837ef86 in qemuMonitorJSONIOProcess
#9 0x000003ffd836757a in qemuMonitorIOProcess
#10 0x000003ffd836863e in qemuMonitorIO
#11 0x000003fffdb4033a in virEventPollDispatchHandles
#12 0x000003fffdb4055e in virEventPollRunOnce
#13 0x000003fffdb3e782 in virEventRunDefaultImpl
#14 0x000003fffdc89400 in virNetDaemonRun
#15 0x000000010002a816 in main
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: Bjoern Walk <bwalk@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
The default is stable per machine type so there should be no need to keep that.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1469338
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
For getting the reply I queried the newest and oldest QEMU using
test/qemucapsprobe. From the differences I only extracted the reply to the new
QMP command and discarded the rest. For all the versions below the one which
added support for the new option I used the output from the oldest QEMU release
and for those that support it I used the output from the newest one.
In order to make doubly sure the reply is where it is supposed to be (the
replies files are very forgiving) I added the property to all the replies files,
reran the tests again and fixed the order in replies files so that all the
versions are reporting the new capability. Then removed that one property.
After that I used test/qemucapsfixreplies to fix the reply IDs.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
One of the things that this is improving is the fact that instead of error
message (that was wrong) you get when starting a domain with SMM and i440fx we
allow the setting to go through. SMM option exists and makes sense on i440fx as
well (basically whenever that _SMM_OPT capability is set).
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We are still hoping all of such checks will be moved there and this is one small
step in that direction.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
To avoid problems with test cases specifying an alias machine type which
would change once capabilities for a newer version are added strip all
alias machine types for the DO_TEST_CAPS_LATEST based tests.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Previous patch naively removed all code relevant to disk format
checking. The semantics now dictate that the format check when creating
external snapshots is now impossible as we always fill in the format for
disks in domain definition in the post-parse callback.
Remove the impossible code path.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The option is insecure and it has been long enough for users to migrate
their disk files to use explicit format. Drop the option and related
code.
The config parser still parses it and rejects statup if it's still
present in the config in enabled state.
The augeas lens is also kept so that users can disable it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
qemu_tpm.c is not calling any capng_* functions. Let's drop this
include then. This also fixes a build failure without capng.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
swtpm_setup can be run for a TPM 2 in unprivileged mode assuming
XDG_CONFIG_HOME has been set and the necessary configuration files
have been put into that directory.
For current reference also see this link:
https://github.com/stefanberger/swtpm/pull/63
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add the external swtpm to the emulator cgroup so that upper limits of CPU
usage can be enforced on the emulated TPM.
To enable this we need to have the swtpm write its process id (pid) into a
file. We then read it from the file to configure the emulator cgroup.
The PID file is created in /var/run/libvirt/qemu/swtpm:
[root@localhost swtpm]# ls -lZ /var/run/libvirt/qemu/swtpm/
total 4
-rw-r--r--. 1 tss tss system_u:object_r:qemu_var_run_t:s0 5 Apr 10 12:26 1-testvm-swtpm.pid
srw-rw----. 1 qemu qemu system_u:object_r:svirt_image_t:s0:c597,c632 0 Apr 10 12:26 1-testvm-swtpm.sock
The swtpm command line now looks as follows:
root@localhost testvm]# ps auxZ | grep swtpm | grep socket | grep -v grep
system_u:system_r:virtd_t:s0:c597,c632 tss 18697 0.0 0.0 28172 3892 ? Ss 16:46 0:00 /usr/bin/swtpm socket --daemon --ctrl type=unixio,path=/var/run/libvirt/qemu/swtpm/1-testvm-swtpm.sock,mode=0600 --tpmstate dir=/var/lib/libvirt/swtpm/485d0004-a48f-436a-8457-8a3b73e28568/tpm1.2/ --log file=/var/log/swtpm/libvirt/qemu/testvm-swtpm.log --pid file=/var/run/libvirt/qemu/swtpm/1-testvm-swtpm.pid
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This patch extends the TPM's device XML with TPM 2.0 support. This only works
for the emulator type backend and looks as follows:
<tpm model='tpm-tis'>
<backend type='emulator' version='2.0'/>
</tpm>
The swtpm process now has --tpm2 as an additional parameter:
system_u:system_r:svirt_t:s0:c597,c632 tss 18477 11.8 0.0 28364 3868 ? Rs 11:13 13:50 /usr/bin/swtpm socket --daemon --ctrl type=unixio,path=/var/run/libvirt/qemu/swtpm/testvm-swtpm.sock,mode=0660 --tpmstate dir=/var/lib/libvirt/swtpm/testvm/tpm2,mode=0640 --log file=/var/log/swtpm/libvirt/qemu/testvm-swtpm.log --tpm2 --pid file=/var/run/libvirt/qemu/swtpm/testvm-swtpm.pid
The version of the TPM can be changed and the state of the TPM is preserved.
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In this patch we label the swtpm process with SELinux labels. We give it the
same label as the QEMU process has. We label its state directory and files
as well. We restore the old security labels once the swtpm has terminated.
The file and process labels now look as follows:
Directory: /var/lib/libvirt/swtpm
[root@localhost swtpm]# ls -lZ
total 4
rwx------. 2 tss tss system_u:object_r:svirt_image_t:s0:c254,c932 4096 Apr 5 16:46 testvm
[root@localhost testvm]# ls -lZ
total 8
-rw-r--r--. 1 tss tss system_u:object_r:svirt_image_t:s0:c254,c932 3648 Apr 5 16:46 tpm-00.permall
The log in /var/log/swtpm/libvirt/qemu is labeled as follows:
-rw-r--r--. 1 tss tss system_u:object_r:svirt_image_t:s0:c254,c932 2237 Apr 5 16:46 vtpm.log
[root@localhost 485d0004-a48f-436a-8457-8a3b73e28567]# ps auxZ | grep swtpm | grep ctrl | grep -v grep
system_u:system_r:svirt_t:s0:c254,c932 tss 25664 0.0 0.0 28172 3892 ? Ss 16:57 0:00 /usr/bin/swtpm socket --daemon --ctrl type=unixio,path=/var/run/libvirt/qemu/swtpm/testvm-swtpm.sock,mode=0660 --tpmstate dir=/var/lib/libvirt/swtpm/testvm/tpm1.2 --log file=/var/log/swtpm/libvirt/qemu/testvm-swtpm.log
[root@localhost 485d0004-a48f-436a-8457-8a3b73e28567]# ps auxZ | grep qemu | grep tpm | grep -v grep
system_u:system_r:svirt_t:s0:c254,c932 qemu 25669 99.0 0.0 3096704 48500 ? Sl 16:57 3:28 /bin/qemu-system-x86_64 [..]
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This patch adds support for an external swtpm TPM emulator. The XML for
this type of TPM looks as follows:
<tpm model='tpm-tis'>
<backend type='emulator'/>
</tpm>
The XML will currently only start a TPM 1.2.
Upon first start, libvirt will run `swtpm_setup`, which will simulate the
manufacturing of a TPM and create certificates for it and write them into
NVRAM locations of the emulated TPM.
After that libvirt starts the swtpm TPM emulator using the `swtpm` executable.
Once the VM terminates, libvirt uses the swtpm_ioctl executable to gracefully
shut down the `swtpm` in case it is still running (QEMU did not send shutdown)
or clean up the socket file.
The above mentioned executables must be found in the PATH.
The executables can either be run as root or started as root and switch to
the tss user. The requirement for the tss user comes through 'tcsd', which
is used for the simulation of the manufacturing. Which user is used can be
configured through qemu.conf. By default 'tss' is used.
The swtpm writes out state into files. The state is kept in /var/lib/libvirt/swtpm:
[root@localhost libvirt]# ls -lZ | grep swtpm
drwx--x--x. 7 root root unconfined_u:object_r:virt_var_lib_t:s0 4096 Apr 5 16:22 swtpm
The directory /var/lib/libvirt/swtpm maintains per-TPM state directories.
(Using the uuid of the VM for that since the name can change per VM renaming but
we need a stable directory name.)
[root@localhost swtpm]# ls -lZ
total 4
drwx------. 2 tss tss system_u:object_r:virt_var_lib_t:s0 4096 Apr 5 16:46 485d0004-a48f-436a-8457-8a3b73e28568
[root@localhost 485d0004-a48f-436a-8457-8a3b73e28568]# ls -lZ
total 4
drwx------. 2 tss tss system_u:object_r:virt_var_lib_t:s0 4096 Apr 10 21:34 tpm1.2
[root@localhost tpm1.2]# ls -lZ
total 8
-rw-r--r--. 1 tss tss system_u:object_r:virt_var_lib_t:s0 3648 Apr 5 16:46 tpm-00.permall
The directory /var/run/libvirt/qemu/swtpm/ hosts the swtpm.sock that
QEMU uses to communicate with the swtpm:
root@localhost domain-1-testvm]# ls -lZ
total 0
srw-------. 1 qemu qemu system_u:object_r:svirt_image_t:s0:c597,c632 0 Apr 6 10:24 1-testvm-swtpm.sock
The logfile for the swtpm is in /var/log/swtpm/libvirt/qemu:
[root@localhost-3 qemu]# ls -lZ
total 4
-rw-------. 1 tss tss unconfined_u:object_r:var_log_t:s0 2199 Apr 6 14:01 testvm-swtpm.log
The processes are labeled as follows:
[root@localhost 485d0004-a48f-436a-8457-8a3b73e28567]# ps auxZ | grep swtpm | grep socket | grep -v grep
system_u:system_r:virtd_t:s0-s0:c0.c1023 tss 18697 0.0 0.0 28172 3892 ? Ss 16:46 0:00 /usr/bin/swtpm socket --daemon --ctrl type=unixio,path=/var/run/libvirt/qemu/swtpm/1-testvm-swtpm.sock,mode=0600 --tpmstate dir=/var/lib/libvirt/swtpm/485d0004-a48f-436a-8457-8a3b73e28568/tpm1.2 --log file=/var/log/swtpm/libvirt/qemu/testvm-swtpm.log
[root@localhost 485d0004-a48f-436a-8457-8a3b73e28567]# ps auxZ | grep qemu | grep tpm | grep -v grep
system_u:system_r:svirt_t:s0:c413,c430 qemu 18702 2.5 0.0 3036052 48676 ? Sl 16:46 0:08 /bin/qemu-system-x86_64 [...]
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Implement functions for managing the storage of the external swtpm as well
as starting and stopping it. Also implement functions to use swtpm_setup,
which simulates the manufacturing of a TPM, which includes creation of
certificates for the device.
Further, the external TPM needs storage on the host that we need to set
up before it can be run. We can clean up the host once the domain is
undefined.
This patch also implements a small layer for external device support that
calls into the TPM device layer if a domain has an attached TPM. This is
the layer we will wire up later on.
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Extend qemu_conf with user and group for running the tpm-emulator
and add directories to the configuration for the locations of the
log, state, and socket of the tpm-emulator.
Also add these new directories to the QEMU Makefile.inc.am and
the RPM spec file libvirt.spec.in.
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Extend the QEMU capabilities with tpm-emulator support.
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This patch adds support for an external swtpm TPM emulator. The XML for
this type of TPM looks as follows:
<tpm model='tpm-tis'>
<backend type='emulator'/>
</tpm>
The XML will currently only define a TPM 1.2.
Extend the documentation.
Add a test case testing the XML parser and formatter.
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Commit id 02b031a4 added a secondary path from which the
incoming @secinfo would not be free'd until the private
data was freed in qemuDomainStorageSourcePrivateDispose.
However, by doing this the original intention to free
@*secinfo afterwards is lost and thus the pass by value
of the secinfo->s.aes (or secinfo->s.plain for its method)
results in not keeping the NULL setting in the various
secret.{username|iv|ciphertext} fields upon return to
qemuDomainSecretInfoClear and eventually will result in
a double free at domain destroy:
raise ()
abort ()
__libc_message ()
malloc_printerr ()
_int_free ()
virFree
qemuDomainSecretAESClear
qemuDomainSecretInfoClear
qemuDomainSecretInfoFree
qemuDomainStorageSourcePrivateDispose
virObjectUnref
virStorageSourceClear
virStorageSourceFree
virDomainDiskDefFree
virDomainDefFree
virDomainObjRemoveTransientDef
qemuProcessStop
qemuDomainDestroyFlags
virDomainDestroy
Signed-off-by: John Ferlan <jferlan@redhat.com>
ACKed-by: Peter Krempa <pkrempa@redhat.com>
Instead of array of pointers to individual buffers it can be
array of buffers directly. This also fixes the following memleak:
==22516== 96 bytes in 4 blocks are definitely lost in loss record 166 of 195
==22516== at 0x4C2EF26: calloc (vg_replace_malloc.c:711)
==22516== by 0x5D2C7D5: virAlloc (viralloc.c:144)
==22516== by 0x56FAABD: qemuBuildNumaArgStr (qemu_command.c:7543)
==22516== by 0x5701835: qemuBuildCommandLine (qemu_command.c:10112)
==22516== by 0x575D794: qemuProcessCreatePretendCmd (qemu_process.c:6568)
==22516== by 0x113338: testCompareXMLToArgv (qemuxml2argvtest.c:549)
==22516== by 0x138CA3: virTestRun (testutils.c:180)
==22516== by 0x136CD1: mymain (qemuxml2argvtest.c:2825)
==22516== by 0x13AD58: virTestMain (testutils.c:1118)
==22516== by 0x137351: main (qemuxml2argvtest.c:2874)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
This function exists because of 5276ec712a. But it is
missing initial check just like virQEMUCapsInitHostCPUModel()
has.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Replace instances where we previously called virGetLastError just to
either get the code or to check if an error exists with
virGetLastErrorCode to avoid a validity pre-check.
Signed-off-by: Ramy Elkest <ramyelkest@gmail.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
When the agent code was first introduced back in
commit c160ce3316
Author: Daniel P. Berrange <berrange@redhat.com>
Date: Wed Oct 5 18:31:54 2011 +0100
QEMU guest agent support
there was code that would loop and retry the connection when opening
the agent socket. At this time, the only thing done in between the
opening of the monitor socket & opening of the agent socket was a
call to set the monitor capabilities. This was a no-op on non-QMP
versions, so in theory there could be a race which let us connect
to the monitor while the agent socket was still not created by QEMU.
In the modern world, however, we long ago mandated the use of QMP
for managing QEMU, so we're guaranteed to have a set capabilities
QMP call. Once we've seen a reply to this, we're guaranteed that
QEMU has fully initialized all backends and is in its event loop.
We can thus be sure the QEMU agent socket is present and don't need
to retry connections to it, even without having the chardev FD passing
feature.
Reviewed-by: John Ferlan <jferlan@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Since libvirt called bind() and listen() on the UNIX socket, it is
guaranteed that connect() will immediately succeed, if QEMU is running
normally. It will only fail if QEMU has closed the monitor socket by
mistake or if QEMU has exited, letting the kernel close it.
With this in mind we can remove the retry loop and timeout when
connecting to the QEMU monitor if we are doing FD passing. Libvirt can
go straight to sending the QMP greeting and will simply block waiting
for a reply until QEMU is ready.
Reviewed-by: John Ferlan <jferlan@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
There is a race condition when spawning QEMU where libvirt has spawned
QEMU but the monitor socket is not yet open. Libvirt has to repeatedly
try to connect() to QEMU's monitor until eventually it succeeds, or
times out. We use kill() to check if QEMU is still alive so we avoid
waiting a long time if QEMU exited, but having a timeout at all is still
unpleasant.
With QEMU 2.12 we can pass in a pre-opened FD for UNIX domain or TCP
sockets. If libvirt has called bind() and listen() on this FD, then we
have a guarantee that libvirt can immediately call connect() and
succeed without any race.
Although we only really care about this for the monitor socket and agent
socket, this patch does FD passing for all UNIX socket based character
devices since there appears to be no downside to it.
We don't do FD passing for TCP sockets, however, because it is only
possible to pass a single FD, while some hostnames may require listening
on multiple FDs to cover IPv4 and IPv6 concurrently.
Reviewed-by: John Ferlan <jferlan@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
QEMU >= 2.12 will support passing of pre-opened file descriptors for
socket based character devices.
Reviewed-by: John Ferlan <jferlan@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The code that detaches the device from persistent definition copies the
persistent definition first so that it can easily be rolled back. The
actual detaching is then made in the copy which is assigned back on
success (if the live operation succeeded as well).
This is not the case in qemuDomainDetachDeviceAliasLiveAndConfig where
the definition was copied and put back, but the detaching happened from
the other object which was overwritten.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
