Peter Krempa [Thu, 1 Dec 2022 16:19:50 +0000 (17:19 +0100)]
qemu: monitor: Use qemuMonitorJSONGetReply in conjunction with virJSONValueArrayToStringList
In two instances (qemuMonitorJSONGetStringListProperty,
qemuMonitorJSONGetStringArray) the return value is checked by
qemuMonitorJSONCheckReply and extracted by
virJSONValueObjectGetStringArray.
We can use qemuMonitorJSONGetReply which returns it directly and then
virJSONValueArrayToStringList to convert it without the additional
lookup.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Thu, 1 Dec 2022 15:13:05 +0000 (16:13 +0100)]
qemuMonitorJSONGetCPUDefinitions: Rework lookup of 'unavailable-features'
Rather than checking that the object has the correct key and then
fetching it again use fetch the array first and then use
virJSONValueArrayToStringList to directly convert it.
Additionally we can avoid the conversion if there are no members
simplifying the surrounding logic.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Thu, 1 Dec 2022 16:02:42 +0000 (17:02 +0100)]
qemuAgentGetDisks: Don't use virJSONValueObjectGetStringArray for optional data
The 'dependencies' field in the return data may be missing in some
cases. Historically 'virJSONValueObjectGetStringArray' didn't report
error in such case, but later refactor (commit 043b50b948ef3c2 ) added
an error in order to use it in other places too.
Unfortunately this results in the error log being spammed with an
irrelevant error in case when qemuAgentGetDisks is invoked on a VM
running windows.
Replace the use of virJSONValueObjectGetStringArray by fetching the
array first and calling virJSONValueArrayToStringList only when we have
an array.
Fixes: 043b50b948ef3c2a4adf5fa32a93ec2589851ac6
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2149752 Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Thu, 1 Dec 2022 12:32:07 +0000 (13:32 +0100)]
util: json: Split out array->strinlist conversion from virJSONValueObjectGetStringArray
Introduce virJSONValueArrayToStringList which does only the conversion
from an array to a stringlist.
This will allow refactoring the callers to be more careful in case when
they want to handle the existance of the member in the parent object
differently.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Thu, 1 Dec 2022 15:18:52 +0000 (16:18 +0100)]
qemu: monitor: Introduce qemuMonitorJSONGetReply, a better qemuMonitorJSONCheckReply
Rather than simply checking that the 'return' field is of the expected
type we can directly return it as the caller is very likely going to use
it. Extract the code into the new function and add a wrapper to preserve
old functionality.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Tue, 22 Nov 2022 10:44:50 +0000 (11:44 +0100)]
internal: Refuse values exceeding range of 'unsigned int' in virCheckFlags
Historically our migration APIs declare 'unsigned long flags'. Since
it's baked into our API we can't change that but we can avoid
compatibility problems by preemptively refusing the extra range on
certain arches to prevent future surprise.
Modify the macro to verify that value passed inside 'flags' doesn't
exceed the range of 'unsigned int'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Jim Fehlig [Fri, 2 Dec 2022 00:08:38 +0000 (17:08 -0700)]
spec: Remove use of %{name} macro
The spec file uses both "libvirt" and "%{name}", but in reality the
expanded value of %{name} will never change. Drop the macro in favor
of the explicit and more readable "libvirt".
Signed-off-by: Jim Fehlig <jfehlig@suse.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
In one of recent commits I've introduced a new test case to
commandtest. In the test case I'm using poll() to wait for data
on a pipe (the write end is passed to commandhelper). However, on
FreeBSD the POLLIN semantic is a bit different:
POLLIN Data other than high priority data may be read
without blocking.
Well, the pipe is non-blocking, so even if there's no data to be
read the flag is set (and subsequent read() returns 0). On the
other hand, POLLHUP is set too, BUT, if the commandhelper manages
to write everything into the pipe and die right after we'd get
both POLLIN and POLLHUP after the very first time poll() returns.
That's very unfortunate, but okay - we can just check whether
read() returned zero and break from the reading loop.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Michal Privoznik [Wed, 30 Nov 2022 08:57:49 +0000 (09:57 +0100)]
tests: Use virTestCompareToString() more
Instead of using:
if (STRNEQ(a, b)) {
virTestDifference(stderr, a, b);
...
}
we can use:
if (virTestCompareToString(a, b) < ) {
...
}
Generated by the following spatch:
@@
expression a, b;
@@
- if (STRNEQ(a, b)) {
+ if (virTestCompareToString(a, b) < 0) {
...
- virTestDifference(stderr, a, b);
...
}
and its variations (STRNEQ_NULLABLE() instead of STRNEQ(), then
in some cases variables passed to STRNEQ() are in reversed order
when compared to virTestCompareToString()).
However, coccinelle failed to recognize the pattern in
testNWFilterEBIPTablesAllTeardown() so I had to fix it manually.
Also, I manually fixed testFormat() in tests/sockettest.c as I
didn't bother writing another spatch rule just for that.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Michal Privoznik [Wed, 30 Nov 2022 08:39:46 +0000 (09:39 +0100)]
virbuftest: Cleanup code around virTestDifference()
Two things are happening here:
1) Call to virTestDifference() is guarded by '!result ||
STRNEQ(result, _)' check. This is suboptimal since we have
STRNEQ_NULLABLE().
2) There are couple of VIR_TEST_DEBUG() printings, which are
useless. If debug is off they don't print anything, and if it
is on, then much more information is printed by subsequent
virTestDifference().
This makes the STRNEQ() + virTestDifference() combo look similar
to the rest of tests and thus can be picked up by spatch later.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Michal Privoznik [Tue, 22 Mar 2022 12:36:38 +0000 (13:36 +0100)]
commandtest: Use virTestCompareToFile() in checkoutput()
In the commandtest there is checkoutput() function which checks
the latest log of commandhelper (containing things like cmd line
arguments, env vars, FDs, CWD, etc.) and compares that against
expected output. Well, the way this function implements that is
effectively by open coding virTestCompareToFile() except for the
nice feature that the virTestCompareToFile() has:
VIR_TEST_OUTPUT_REGENERATE.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Michal Privoznik [Tue, 22 Mar 2022 11:12:02 +0000 (12:12 +0100)]
virCommandSetSendBuffer: Take double pointer of @buffer
The virCommandSetSendBuffer() function consumes passed @buffer,
but takes it only as plain pointer. Switch to a double pointer to
make this obvious. This allows us then to drop all
g_steal_pointer() in callers.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Michal Privoznik [Tue, 29 Nov 2022 15:55:16 +0000 (16:55 +0100)]
virCommandDoAsyncIO: Drop misleading statement about main event loop
Back in v1.0.3-rc1~235 when I was adding virCommandDoAsyncIO(),
the main event loop was used to poll() on the pipe to the child
process. But this was promptly changed to a separate thread
handling I/O in v1.0.3-rc1~127. However, the corresponding
comment to virCommandDoAsyncIO() still documents the original
state.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
When virCommandSetSendBuffer() is used over a virCommand that is
(or will be) daemonized, then the command must have
VIR_EXEC_ASYNC_IO flag set no later than at virCommandRunAsync()
phase so that the thread that's doing IO is spawned and thus
buffers can be sent to the process.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
conf: report no NUMA nodes when attaching memory device
Error message reports that the guest has '0' NUMA nodes
configured when trying to attach a memory device to a guest with
no NUMA nodes. This may be a little misleading because '0' can
also be node's id. A more friendly way is to directly report
that the guest has no NUMA nodes.
Jiri Denemark [Wed, 30 Nov 2022 13:29:55 +0000 (14:29 +0100)]
qemu: Pass vm to qemuMigrationCookieParse if it exists
The vm object is used inside qemuMigrationCookieParse based on the flags
passed to qemuMigrationCookieParse and the content of the cookie. The
callers should not just blindly guess and pass NULL if they
(incorrectly) think the vm object is not needed. We should always pass
the vm object unless it does not exist yet.
This fixes a bug when statistics of a completed migration reported
"Unknown" operation instead of "Incoming migration" on the destination
host.
Michal Privoznik [Wed, 30 Nov 2022 13:53:21 +0000 (14:53 +0100)]
node_device_conf: Avoid memleak in virNodeDeviceGetPCIVPDDynamicCap()
The virNodeDeviceGetPCIVPDDynamicCap() function is called from
virNodeDeviceGetPCIDynamicCaps() and therefore has to be a wee
bit more clever about adding VPD capability. Namely, it has to
remove the old one before adding a new one. This is how other
functions called from virNodeDeviceGetPCIDynamicCaps() behave
as well.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2143235 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Michal Privoznik [Tue, 22 Nov 2022 11:18:35 +0000 (12:18 +0100)]
qemu_tpm: Check for qemuTPMSetupEncryption() errors
Inside of qemuTPMEmulatorBuildCommand() there are two calls to
qemuTPMSetupEncryption() which simply ignore returned error. This
is suboptimal because then we rely on swtpm binary reporting a
generic error (something among invalid command line arguments)
while an error reported by qemuTPMSetupEncryption() is more
specific.
However, since virCommandSetSendBuffer() only sets an error
inside of virCommand structure (the error is then reported in
virCommandRun()), we need to exempt its retval from error
checking. Thus, the signature of qemuTPMSetupEncryption() is
changed a bit so that -1/0 can be returned to indicate error.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Peter Krempa [Mon, 28 Nov 2022 16:09:23 +0000 (17:09 +0100)]
Document caveats of hypervisor-specific stats in 'VIR_DOMAIN_STATS_VCPU' group
In commit c43718ef67944 I've added a disclaimer that the new stats which
are fetched from qemu and passed directly to the user are not guaranteed
by libvirt. I didn't notice that per-vcpu hypervisor specific stats are
also snuck into the VIR_DOMAIN_STATS_VCPU group along with other
pre-existing stats we do guarantee.
Extend the disclaimer for VIR_DOMAIN_STATS_VCPU too.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Michal Privoznik [Thu, 24 Nov 2022 11:34:56 +0000 (12:34 +0100)]
virnetdevbandwidth: Unbreak tc filter update on Linux-4.20+
Guests are allowed to change their MAC addresses. Subsequently,
we may respond to that with tweaking that part of host side
configuration that depends on it. In this particular case: QoS.
Some parts of QoS are in fact set on corresponding bridge, where
overall view on traffic can be seen. Here, TC filters are used to
place incoming packets into qdiscs. These filters match source
MAC address. Therefore, upon guest changing its MAC address, the
corresponding TC filter needs to be updated too. This is done by
simply removing the old one and instantiating a new one, with new
MAC address.
Now, u32 filters (which we use) use a hash table for matching,
internally. And when deleting the old filter, we used to remove
the hash table (ID = 800::) and let the new filter instantiate
new hash table. This used to work, until kernel release 4.20
(specifically commit v4.20-rc1~27^2~131^2~11 and its friends)
where this practice was turned into error.
But that's okay - we can delete the specific filter we are after
and not touch the hash table at all.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Michal Privoznik [Thu, 24 Nov 2022 09:28:59 +0000 (10:28 +0100)]
conf: Make VIR_DOMAIN_NET_TYPE_ETHERNET not share 'host view'
When setting up QoS for a domain <interface/>, or when reporting
its statistics we may need to swap TX/RX values. This is all
explained in comment to virDomainNetTypeSharesHostView().
However, this function claims that VIR_DOMAIN_NET_TYPE_ETHERNET
also shares the 'host view', meaning the TX/RX values must be
swapped. But that's not true.
An easy reproducer is to start a domain with two <interface/>-s:
one type of network, the other of type ethernet and configure the
same <bandwidth/> for both. Reversed setting can then be observed
(e.g. via tc).
Michal Privoznik [Wed, 23 Nov 2022 08:50:29 +0000 (09:50 +0100)]
rpc: Mark close callback (un-)register as high priority
Our RPC calls can be divided into two groups: regular and high
priority. The latter can be then processed by so called high
priority worker threads. This is our way of defeating a
'deadlock' and allowing some RPCs to be processed even when all
(regular) worker threads are stuck. For instance: if all regular
worker threads get stuck when talking to QEMU on monitor, the
virDomainDestroy() can be processed by a high priority worker
thread(s) and thus unstuck those threads.
Now, this is all fine, except if users want to use virsh
non interactively:
virsh destroy $dom
This does a bit more - it needs to open a connection. And that
consists of multiple RPC calls: AUTH_LIST,
CONNECT_SUPPORTS_FEATURE, CONNECT_OPEN, and finally
CONNECT_REGISTER_CLOSE_CALLBACK. All of them are marked as high
priority except the last one. Therefore, virsh just sits there
with a partially open connection.
There's one requirement for high priority calls though: they can
not get stuck. Hopefully, the reason is obvious by now. And
looking into the server side implementation the
CONNECT_REGISTER_CLOSE_CALLBACK processing can't ever get stuck.
The only driver that implements the callback for public API is
Parallels (vz). And that can't block really.
And for virConnectUnregisterCloseCallback() it's the same story.
Therefore, both can be marked as high priority.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2143840 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Lu Ke [Mon, 14 Nov 2022 15:00:09 +0000 (15:00 +0000)]
kbase: virtiofs: Add 'queue' setting to example
The setting is needed for the windows driver to work properly and doesn't have negative effects on other usage. Signed-off-by: Lukas Ke nicelukas@hotmail.com
For the handling of usb we already allow plenty of read access,
but so far /sys/bus/usb/devices only needed read access to the directory
to enumerate the symlinks in there that point to the actual entries via
relative links to ../../../devices/.
But in more recent systemd with updated libraries a program might do
getattr calls on those symlinks. And while symlinks in apparmor usually
do not matter, as it is the effective target of an access that has to be
allowed, here the getattr calls are on the links themselves.
On USB hostdev usage that causes a set of denials like:
apparmor="DENIED" operation="getattr" class="file"
name="/sys/bus/usb/devices/usb1" comm="qemu-system-x86"
requested_mask="r" denied_mask="r" ...
It is safe to read the links, therefore add a rule to allow it to
the block of rules that covers the usb related access.
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com> Reviewed-by: Michal Privoznik <mprivozn at redhat.com>
Jonathon Jongsma [Thu, 17 Nov 2022 18:15:23 +0000 (12:15 -0600)]
qemu: fix memlock without vIOMMU
When there is no vIOMMU, vfio devices don't need to lock the entire guest
memory per-device, but they still need to lock the entire guest memory to
share between all vfio devices. This memory accounting is not shared
with vDPA devices, so it should be added to the memlock limit separately.
Commit 8d5704e2 added support for multiple vfio/vdpa devices but
calculated the limits incorrectly when there were both vdpa and vfio
devices and no vIOMMU. In this case, the memory lock limit was not
increased separately for the vfio devices.
Jiri Denemark [Fri, 18 Nov 2022 15:19:33 +0000 (16:19 +0100)]
qemu: Ignore failure in post-copy migration when QEMU says completed
When post-copy migration is running in Finish phase we already did
everything needed and we're just waiting for all the memory to transfer
to the destination. The domain is already running on there at this
point. Once all data is transferred (QEMU sends a MIGRATION completed
event) we're done. So in this specific post-copy case the source does
not need to care about the result of the Finish call as long as QEMU
says migration completed. The Finish call to the destination daemon may
fail for reasons that do not affect QEMU, e.g., libvirt daemon was
restarted there or the libvirt connection broke.
Currently we just mark the post-copy migration as failed on the source
and keep the domain paused there. But when libvirt daemon is restarted
at this point, it will detect migration finished successfully and kill
the domain as migrated. It make sense to do this even without having to
restart the daemon.
Closes: https://gitlab.com/libvirt/libvirt/-/issues/338 Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Jiri Denemark [Fri, 18 Nov 2022 15:19:16 +0000 (16:19 +0100)]
qemu: Always restore post-copy migration job on reconnect
We need the restored job even in case the migration already finished
even though we will stop it just a few lines below as the functions we
call in between require an existing migration job.
This fixes a crash on reconnect when post-copy migration finished while
the daemon was not running.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Michal Privoznik [Fri, 18 Nov 2022 16:13:22 +0000 (17:13 +0100)]
virmockstathelpers: Load aliases for 64-bit time
On 32-bit arches, it's possible not only to request
-D_FILE_OFFSET_BITS=64 (which is always done with meson) but also
-D_TIME_BITS=64. With glibc, both of these affect what variant of
stat() or lstat() is called. With 64 bit time it's:
__stat64_time64() or __lstat64_time64(), respectively.
Fortunately, no other variant (__xstat(), __xstat64()) has
_time64 alternative and thus does not need similar treatment.
Similarly, musl is not affected by this.
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/404 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Michal Privoznik [Mon, 21 Nov 2022 11:40:21 +0000 (12:40 +0100)]
tests: Drop needless virrandom mock from two tests
Nothing in virnettlscontexttest nor virnettlssessiontest calls
any of random number generator functions overridden
virrandommock. GnuTLS handles RNG within itself.
Therefore, there's no need to preload the mock.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
If the running firewalld doesn't support getPolicies() then we fallback
to the "libvirt" zone. Throwing an error log is excessive since we
gracefully fallback.
Avoids these logs:
error : virGDBusCallMethod:242 : error from service: \
GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod
Fixes: ab56f84976e0 ("util: add virFirewallDGetPolicies()") Signed-off-by: Eric Garver <eric@garver.life> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The idea here is that virVMXConfigScanResultsCollector() sets the
networks_max_index to the highest ethernet index seen. Well, the
struct member is signed int, we parse just seen index into uint
and then typecast to compare the two. This is not necessary,
because the maximum number of NICs a vSphere domain can have is
(<drumrolll/>): ten [1]. This will fit into signed int easily
anywhere.
Michal Privoznik [Thu, 10 Nov 2022 11:52:56 +0000 (12:52 +0100)]
internal: Introduce STRCASESKIP()
There is so far one case where STRCASEPREFIX(a, b) && a +
strlen(b) combo is used (in virVMXConfigScanResultsCollector()),
but there will be more. Do what we do usually: introduce a macro.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
Michal Privoznik [Thu, 10 Nov 2022 12:00:16 +0000 (13:00 +0100)]
coding-style: Follow our own recommendation wrt spacing around commas
We require a space after a comma and even document this in our
coding style document. However, our own rule is broken in the
very same document when listing string comparison macros.
Separate macro arguments properly.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
Erik Skultety [Tue, 15 Nov 2022 16:27:41 +0000 (17:27 +0100)]
ci: integration: Lock the Avocado version to 98.0 for now
Avocado 99.0 causes the TCK test suite to fail with the nwfilter tests
(which is another Bash framework underneath). Until the culprit is
identified and fixed in Avocado, let's lock the version to 98.0 which
worked with the test suite just fine.
Signed-off-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
docs/manpages: add checklist of problems for SEV attestation
Despite efforts to make the virt-qemu-sev-validate tool friendly, it is
a certainty that almost everyone who tries it will hit false negative
results, getting a failure despite the VM being trustworthy.
Diagnosing these problems is no easy matter, especially for those not
familiar with SEV/SEV-ES in general. This extra docs text attempts to
set out a checklist of items to look at to identify what went wrong.
Reviewed-by: Cole Robinson <crobinso@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
scripts: add systemtap script for capturing SEV-ES VMSA
In general we expect to be able to construct a SEV-ES VMSA
blob from knowledge about the AMD achitectural CPU register
defaults, KVM setup and QEMU setup. If any of this unexpectedly
changes, figuring out what's wrong could be horrible. This
systemtap script demonstrates how to capture the real VMSA
that is used for a SEV-ES as it is booted. The captured data
can be fed into the 'sevctl vmsa show' command in order to
produce formatted info with named registers, allowing a
'diff' to be performed.
This script will need updating for any kernel version that is
not 6.0, to set the correct line numbers.
Reviewed-by: Cole Robinson <crobinso@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Expand the SEV guest kbase guide with information about how to configure
a SEV/SEV-ES guest when attestation is required, and mention the use of
virt-qemu-sev-validate as a way to confirm it.
Reviewed-by: Cole Robinson <crobinso@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
tools: support generating SEV secret injection tables
It is possible to build OVMF for SEV with an embedded Grub that can
fetch LUKS disk secrets. This adds support for injecting secrets in
the required format.
Reviewed-by: Cole Robinson <crobinso@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
When validating a SEV-ES guest, we need to know the CPU count and VMSA
state. We can get the CPU count directly from libvirt's guest info. The
VMSA state can be constructed automatically if we query the CPU SKU from
host capabilities XML. Neither of these is secure, however, so this
behaviour is restricted.
Reviewed-by: Cole Robinson <crobinso@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
tools: support automatically constructing SEV-ES vCPU state
The VMSA files contain the expected CPU register state for the VM. Their
content varies based on a few pieces of the stack
- AMD CPU architectural initial state
- KVM hypervisor VM CPU initialization
- QEMU userspace VM CPU initialization
- AMD CPU SKU (family/model/stepping)
The first three pieces of information we can obtain through code
inspection. The last piece of information we can take on the command
line. This allows a user to validate a SEV-ES guest merely by providing
the CPU SKU information, using --cpu-family, --cpu-model,
--cpu-stepping. This avoids the need to obtain or construct VMSA files
directly.
Reviewed-by: Cole Robinson <crobinso@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
tools: support validating SEV-ES initial vCPU state measurements
With the SEV-ES policy the VMSA state of each vCPU must be included in
the measured data. The VMSA state can be generated using the 'sevctl'
tool, by telling it a QEMU VMSA is required, and passing the hypevisor's
CPU SKU (family, model, stepping).
Reviewed-by: Cole Robinson <crobinso@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
When connected to libvirt we can validate that the guest configuration
has the kernel hashes property enabled, otherwise including the kernel
GUID table in our expected measurements is not likely to match the
actual measurement.
When running locally we can also automatically detect the kernel/initrd
paths, along with the cmdline string from the XML.
Reviewed-by: Cole Robinson <crobinso@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Accept information about a connection to libvirt and a guest on the
command line. Talk to libvirt to obtain the running guest state and
automatically detect as much configuration as possible.
It will refuse to use a libvirt connection that is thought to be local
to the current machine, as running this tool on the hypervisor itself is
not considered secure. This can be overridden using the --insecure flag.
When querying the guest, it will also analyse the XML configuration in
an attempt to detect any options that are liable to be mistakes. For
example the NVRAM being measured should not have a persistent varstore.
Reviewed-by: Cole Robinson <crobinso@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
tools: support validating SEV firmware boot measurements
The virt-qemu-sev-validate program will compare a reported SEV/SEV-ES
domain launch measurement, to a computed launch measurement. This
determines whether the domain has been tampered with during launch.
This initial implementation requires all inputs to be provided
explicitly, and as such can run completely offline, without any
connection to libvirt.
The tool is placed in the libvirt-client-qemu sub-RPM since it is
specific to the QEMU driver.
Reviewed-by: Cole Robinson <crobinso@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
qemu: Delete thread-context objects at domain startup
While technically thread-context objects can be reused, we only
use them (well, will use them) to pin memory allocation threads.
Therefore, once we connect to QEMU monitor, all memory (with
prealloc=yes) was allocated and thus these objects are no longer
needed and can be removed. For on demand allocation the TC object
is left behind.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
allocates 14GiB worth of memory, backed by 2MiB hugepages from
host NUMA node 3, using 8 threads. If it weren't for
thread-context these threads wouldn't have any affinity and thus
theoretically could be scheduled to run on CPUs of different NUMA
node (which is what I saw occasionally).
Therefore, whenever we are pinning memory (IOW setting host-nodes
attribute), we can generate thread-context object with the same
affinity.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
In its commit v7.1.0-1429-g7208429223 QEMU gained new object
thread-context, which allows running specialized tasks with
affinity set to a given subset of host CPUs/NUMA nodes. Even
though only memory allocation task accepts this new object, it's
exactly what we aim to implement in libvirt. Therefore, introduce
a new capability to track whether QEMU is capable of this object.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
conf: skip resource cache init if sysfs files are missing
On aarch64 the 'id' file is not present for CPU cache information in
sysfs. This causes the local stateful hypervisor drivers to fail to
initialize capabilities:
virStateInitialize:657 : Initialisation of cloud-hypervisor state driver failed: no error
The 'no error' is because the 'virFileReadValueNNN' methods return
ret==-2, with no error raised, when the requeted file does not exist.
None of the callers were checking for this scenario when populating
capabilities. The most graceful way to handle this is to skip the
cache bank in question. This fixes failure to launch libvirt drivers
on certain aarch64 hardware.
Fixes: https://gitlab.com/libvirt/libvirt/-/issues/389 Tested-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
virGetConnectGeneric: Only delegate existing identities
Inside virt-qemu-run, just like in virsh for example, there is no
identity set in the current thread, so we should not try to set it,
otherwise things like connecting to other drivers might fail and on
top of that there is no error set so the user can't even see what's
wrong.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=2000075 Signed-off-by: Martin Kletzander <mkletzan@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
* the macOS platform has switched from x86_64 to aarch64
* if a new pipeline starts before a previous one finishes,
jobs marked 'interruptible: true' will be auto-cancelled
Reviewed-by: Pavel Hrdina <phrdina@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
projects / libvirt.git / log