This patch introduces the
<maxphysaddr mode='passthrough'/>
<maxphysaddr mode='emulate' bits='42'/>
sub element of /domain/cpu, which allows specifying the guest virtual CPU
address size. This can be useful if the guest needs to have a large amount
of memory.
If mode='passthrough', the virtual CPU will have the same number of address
bits as the host. If mode='emulate', the mandatory bits attribute specifies
the number of address bits.
Signed-off-by: Dario Faggioli <dfaggioli@suse.com>
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Now that we have all the machinery needed, we can introduce two
simple test cases:
1) only TPM 1.2 is supported, but TPM 2.0 was requested in domain XML,
2) only TPM 2.0 is supported, but TPM 1.2 was requested in domain XML.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Kristina Hanicova <khanicov@redhat.com>
Supported TPM versions are reported in domain capabilities. These
are used already to validate TPM type and model, but not TPM
version. This is suboptimal, because otherwise we leave users to
meet the error when starting a guest and libvirt spawns swtpm
binary which in turn reports an error.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Kristina Hanicova <khanicov@redhat.com>
Because of v8.5.0-rc1~25 we are already faking TPM support for
domaincaps. Might as well fake supported TPM versions.
The swtpm binary supports both TPM versions since its first
release, but pretend it isn't the case. For QEMU-5.2 and older
pretend only TPM-1.2 is available, QEMU-6.* has both TPM-1.2 and
TPM-2.0 and QEMU-7.0 and newer has only TPM-2.0 available.
This way, domaincaps are more dispersed.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Kristina Hanicova <khanicov@redhat.com>
The virDomainTPMVersion enum is declared in domain_conf.h among
with its TypeFromString() and TypeToString() helpers (which are
then implemented in domain_conf.c). However, neither of these
helpers is exposed in libvirt_private.syms which makes it
impossible for other modules to use.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Kristina Hanicova <khanicov@redhat.com>
When we call qemuDomainSetMaxMemLock to reset memory locking limit back
to its original value the domain can already be stopped (for example
after the domain shuts down during migration) in which case it does not
make sense to set any limit. Doing so can even be harmful as we may end
up setting the limit for the daemon itself as the PID is 0.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
When resetting private data after stopping QEMU process we should also
reset the original memory locking limit (both normal and pre-migration)
as they are not relevant anymore.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
The qemuDomainDefCPUPostParse() does a bit more than filling in
missing info. It also validates CPU cache configuration. Move
that code into qemuValidateDomainDefCpu() where the code fits
better.
And since I need to fix indentation of existing code in
qemuValidateDomainDefCpu(), I'm taking this opportunity and move
error messages onto single line. Interestingly, this uncovers a
bug we have in sc_prohibit_diagnostic_without_format syntax-check
rule, because previously a virReportError() with a message
spawned over three lines was not caught but not it is. But
trying to understand that regex is a job for another time.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Directly check the return value of 'connect'. Unfortunately we can't
remove it as we have to undo auto-closing of the socket on success.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
All callers now pass false for 'retry' we are guaranteed to have a
monitor socket present. This means that the retry code can be removed.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
In 'qemuProcessQMPLaunch' qemu is very specifically launched using it's
internal '-daemonize' flag (see comment in the function) to ensure that
the monitor socket is ready and opened prior to attempting the monitor
connection.
This means we don't have to retry the connection to the monitor in
qemuMonitorOpen as the socket will be already there.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
The 'retry' argument makes the monitor connection opening re-try the
connection in case the monitor socket doesn't exist or isn't properly
listening. In case of the test code this can't happen because the socket
is created and made listening in 'qemuMonitorCommonTestNew' which is
called prior to calling 'qemuMonitorOpen'.
We can thus avoit the code which attempts retries in monitor connection.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
The 'timeout' argument is used by 'qemuMonitorOpenUnix' only when the
'retry' argument is true. The callers of 'qemuMonitorOpen' only pass '0'
for timeout when they call it with 'retry' true and use other values
when 'retry' is false and thus ignored.
This means we can remove the argument and simply have it set to the
default value of QEMU_DEFAULT_MONITOR_WAIT.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Both callers pass 'false' as the argument via a variable which is not
modified. Remove the argument and pass 'false' directly.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Since functions virQEMUCapsFillDomainFeatureSEVCaps() and
virQEMUCapsSEVInfoCopy() essentially do the same thing it does
not make sense to have the code duplicated. This patch replaces
the relevant code in the first function with the function call to
the second one.
Signed-off-by: Kristina Hanicova <khanicov@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
With glibc 2.36, sys/mount.h and linux/mount.h conflict:
https://sourceware.org/glibc/wiki/Release/2.36#Usage_of_.3Clinux.2Fmount.h.3E_and_.3Csys.2Fmount.h.3E
lxc_container.c imports sys/mount.h and linux/fs.h, which pulls in
linux/mount.h.
linux/fs.h isn't required here though. glibc sys/mount.h has had
MS_MOVE since 2.12 in 2010
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This patch removes and replaces virCHDomainObjResetJob() with
general virDomainObjResetJob().
Signed-off-by: Kristina Hanicova <khanicov@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
This patch removes and replaces virLXCDomainObjResetJob() with
general virDomainObjResetJob().
Signed-off-by: Kristina Hanicova <khanicov@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
This patch removes and replaces libxlDomainObjResetJob() with
general virDomainObjResetJob().
Signed-off-by: Kristina Hanicova <khanicov@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
This patch moves qemuDomainObjResetJob() as
virDomainObjResetJob() into hypervisor in order to be used by
other hypervisors as well.
Signed-off-by: Kristina Hanicova <khanicov@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
In a recent commit of v8.5.0-85-g430ab88ab1 I've made domaincaps
XML report supported TPM versions. This was done by calling
virTPMSwtpmSetupCapsGet(). But this function isn't mocked and
thus domaincapstest calls the real implementation, which tries to
execute swtpm_setup binary. This fails, because
virFindFileInPath() is mocked in such way that it returns NULL
for anything else than qemu-*.
Anyway, while the real binary is not executed after all, we
should mock the function which tries to execute it so that
predictable result is returned.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
In virtpm.h there are two functions exposed for querying swtpm
and swtpm_setup capabilities: virTPMSwtpmCapsGet() and
virTPMSwtpmSetupCapsGet(), respectively. The capabilities we are
interested in are defined in two separate enums
(virTPMSwtpmFeature and virTPMSwtpmSetupFeature), but these
functions accept capability as an unsigned int rather than their
respective enum. While this makes sense for
virTPMBinaryGetCaps(), which is a module internal helper that
both exposed functions call, there's no need for the functions
themselves to accept unsigned int.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
The %posttrans scriptlet checks if libvirtd is active within a
condition that is only executed if libvirtd is active. Remove the
duplicate check.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
When no TPM version is provided in the input XML we may default
to version 2.0 (see qemuDomainTPMDefPostParse()). However,
<active_pcr_banks/> are parsed iff a version 2.0 was specified.
This means that this piece of information might be lost.
It's better to parse everything we've been given and then
validate that the configuration is valid.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2084046
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
After previous cleanup, the qemuDomainDefTPMsPostParse() function
does nothing more than validates TPM devices. Therefore, it
should live in qemu_validate.c instead of qemu_domain.c. Move it
there and rename to reflect the fact that the function is doing
validation instead of PostParsing.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
In the qemuDomainDefPostParse() we aim to fill in top level
values, which require overall view of domain, or those parts of
configuration that are not a device in domain XML (e.g. vCPUs).
However, inside of qemuDomainDefTPMsPostParse(), which is called
from aforementioned function, we do two tings:
1) fill in missing info (TPM version), and
2) validate TPM definition.
Now, if 1) is moved into qemuDomainTPMDefPostParse() (the device
post parse callback), then 2) can be moved into validation step.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
When parsing a TPM device plenty of virXMLPropString() +
enum2int() combos are used. These can be replaced with
virXMLPropEnum().
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The _virDomainTPMDef structure has 'version' member, which is a
bit misplaced. It's only emulator type of TPM that can have a
version, even our documentation says so:
``version``
The ``version`` attribute indicates the version of the TPM. This attribute
only works with the ``emulator`` backend. The following versions are
supported:
Therefore, move the member into that part of union that's
covering emulated TPM devices.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
In previous commit the VIR_DOMAIN_TPM_VERSION_DEFAULT value was
made just an alias to value of 0. And since all newly allocated
memory is zeroed out (due to use of g_new0()), the def->version
inside of virDomainTPMDefParseXML() is also 0 and thus there is
no need to set it explicitly.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
When "default" version of TPM was provided, our parses accepts it
happily even though the value is forbidden by our RNG and not
documented as accepted value. This is because of < 0 vs <= 0
comparison of virDomainTPMModelTypeFromString() retval.
Make the parser error out explicitly in this case. Users can
always chose to not specify the attribute in which case we pick a
sane default (in qemuDomainDefTPMsPostParse()).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
When "default" model of a TPM was provided, our parses accepts it
happily even though the value is forbidden by our RNG and not
documented as accepted value. This is because of < 0 vs <= 0
comparison of virDomainTPMModelTypeFromString() retval.
Make the parser error out explicitly in this case. Users can
always chose to not specify the attribute in which case we pick a
sane default (in qemuDomainTPMDefPostParse()).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
There's no need to skip over ENOENT error in
qemuCgroupAllowDevicesPaths(). The path must exists when
qemuCgroupAllowDevicePath() is called because of virFileExists()
check done right above.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The qemuBuildMachineCommandLine() function is needlessly long.
Separate out parts that generate memory related arguments into
qemuAppendDomainMemoryMachineParams(). Unfortunately, expected
outputs for some qemuxml2argvdata cases needed to be updated
because the order in which arguments are generated is changed.
But there's no functional change.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The qemuBuildMachineCommandLine() function is needlessly long.
Separate out parts that generate arguments based on
domainDef->features[] into
qemuAppendDomainFeaturesMachineParam(). Unfortunately, expected
outputs for some qemuxml2argvdata cases needed to be updated
because the order in which features are generated is changed. But
there's no functional change.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Almost all of memory models we currently support allow setting
virDomainMemoryDef::targetNode so that the memory module is
associated with given guest NUMA node. And we do have a check
whether the requested node is within bounds, but it's executed
only when building QEMU's cmd line. Move it into validation
phase.
While this commit is moving the validation to a place that does
not validate all the possible code paths, it's okay, because only
the explicit memory device has user-configurable target node
which could break the assumption.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
After previous commit, when memory-hotplug-dimm-addr.xml file was
fixed, we can also introduce the test case to qemuxml2xmltest.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
So far, we are testing memory-hotplug-dimm-addr against a set of
explicitly listed capabilities. While this works, lets switch it
to DO_TEST_CAPS_LATEST() so that the latest capabilities are
used. This in turn means, we have to update the <emulator/>
because the latest capabilities don't contain caps for
qemu-system-i386.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Currently, virJSONValueObjectHasKey() can return one of three
values:
-1 if passed object type is not VIR_JSON_TYPE_OBJECT,
0 if the key is not present, and finally
1 if the key is present.
But, neither of callers is interested in the -1 case. In fact,
some callers call this function treating -1 and 1 cases the same.
Therefore, make the function return just true/false and fix few
callers that explicitly checked for == 1 case.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
In my recent comnmit v8.5.0-188-gc47f1abb81 I accidentally moved
qemuMigrationParamsResetTLS after qemuDomainObjEnterMonitorAsync not
noticing qemuMigrationParamsResetTLS will try to enter the monitor
again. The second call will time out and return with a domain object
locked. But we're still in monitor section and the object should be
unlocked which means qemuDomainObjExitMonitor will deadlock trying to
lock it again.
Fixes: c47f1abb81
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This call to qemuMigrationSrcIsAllowedHostdev() (which does a
hardcoded fail of the migration if there is any PCI or mdev hostdev
device in the domain) while doing the destination side of migration
prep was found once the call to that same function was removed from
the source side migration prep (commit 25883cd5).
According to jdenemar, for the V2 migration protocol, prep of the
destination is the first step, so this *was* the proper place to do
the check, but for V3 migration this is in a way redundant (since we
will have already done the check on the source side (updated by
25883cd5 to query QEMU rather than do a hardcoded fail)).
Of course it's possible that the source could support migration of a
particular VFIO device, but the destination doesn't. But the current
check on the destination side is worthless even in that case, since it
is just *always* failing rather than querying QEMU; and QEMU can't be
queried at the point where the destination check is happening, since
it isn't yet running.
Anyway QEMU should complain when it's started if it's going to fail,
so removing this check should just move the failure to happen a bit
later. So the best solution to this problem is to simply remove the
hardcoded check/fail from qemuMigrationDstPrepareFresh() and rely on
QEMU to fail if it needs to.
Fixes: 25883cd5f0
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Commit v8.4.0-287-gd4d3bb8130 tried to make sure the original
pre-migration memory locking limit is restored at the end of migration,
but it missed the case when libvirt daemon is restarted during
migration which needs to be aborted on reconnect.
And if this was not enough, I forgot to actually save the status XML
after setting the field in priv (in the commit mentioned above and also
in v8.4.0-291-gd375993ab3).
https://bugzilla.redhat.com/show_bug.cgi?id=2107424
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The function would fail to release the job in case
qemuMigrationSrcIsAllowed failed.
Fixes v8.5.0-157-g69e0e33873
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
When the <loader stateless='yes'/> attribute is set, the QEMU driver
needs to do three things
- Avoid looking for an NVRAM template
- Avoid auto-populating an <nvram/> path
- Find firmware descriptors with mode=stateless instead of mode=split
Note, the first thing happens automatically when we solve the second
thing.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
