Introduce nwfilter_tech_driver.c which holds shared non driver specific
methods.
The following logic can be reused by new nwfilter drivers, which are not
ebiptables specific:
- data type print logic, used for constructing ascii cli arguments out
of nwfilter data;
- chain jump proto type l3_proto_idx logic;
- virNWFilterRule sorting.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Dion Bosschieter <dionbosschieter@gmail.com>
[DB: moved virstring.h include to source file & added to POTFILES]
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
There are no calls to uname() in the ebiptables driver code.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Dion Bosschieter <dionbosschieter@gmail.com>
[DB: split from larger patch]
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Rename generic nwfilter data types and functions to virNWFilter prefix
and convert them to CamelCase. These data types and functions are quite
common to any nwfilter driver implementation. Prior to moving them out
of the nwfilter_ebiptables_driver.c file, we'll first rename them.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Dion Bosschieter <dionbosschieter@gmail.com>
This adds the physical USB port to the capabilities of a
USB device in nodedev XML.
example: <port>1.4</port>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Maximilian Martin <maximilian_martin@gmx.de>
USB bus/port addressing is translated into a bus/device addressing
at startup using the hostdev logic. This test covers XML parsing
and CLI formatting for bus/port addressing.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Maximilian Martin <maximilian_martin@gmx.de>
Adds USB bus/port addressing the domain XML file
schema. Optionally, the physical USB port can be
declared instead of the USB device address.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Maximilian Martin <maximilian_martin@gmx.de>
This patch implements USB bus/port matching in the XML schema.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Maximilian Martin <maximilian_martin@gmx.de>
[DB: split host USB search parts out into previous patches]
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Extend the API for finding host USB devices, to allow requesting
a search based on the port.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Maximilian Martin <maximilian_martin@gmx.de>
[DB: split out of bigger patch]
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Prepare for adding the ability to find host USB devices based
on their port, by generalizing the APIs for device searching
into one all-purpose API
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Maximilian Martin <maximilian_martin@gmx.de>
[DB: split out of bigger patch]
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This patch adds devpath files to the virusb test data.
These files are mockups for the USB sysfs files that
contain the port of a USB device in dotted notation.
They are used for testing of USB bus/port matching.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Maximilian Martin <maximilian_martin@gmx.de>
Since commit 99a637a8 in qemu 10.0, the way the cmp_legacy flag is
reported changed. The same way as happend with the 'ht' flag in commit
c6bd2dd634208, which was fixed in libvirt since commit ba16113c.
This causes migrations from a hypervisor running a qemu version before
that commit to a hypervisor running qemu after that commit fails
with the following error:
guest CPU doesn't match specification: extra features: cmp_legacy
We can just ignore this flag, just like we did with the 'ht' flag.
Signed-off-by: Jean-Louis Dupond <jean-louis@dupond.be>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
The aim of cmdDomIfAddr() is to obtain IP addresses for given
domain and then print (ifName, MAC, type, IP Address) tuple.
Preferably in an aligned table. This is hard to do with printf
style of spacing ("%-NNs") since the interface name (ifName) can
vary a lot in length. Fortunately, we have vshTable which is
designed to handle this case.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Just like with other features, check whether QEMU supports them
based on capabilities. Now, instead of inventing a new QEMU
capability, an existing one can be used:
QEMU_CAPS_VIRTIO_IOMMU_AW_BITS.
This is because the aw-bits and granule attributes were
introduced into QEMU in close succession (v9.0.0-rc0~9^2~7
v9.0.0-rc0~9^2~11), neither can be disabled at compile time and
backporting just one without the other makes almost no sense.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
In PCI assignment scenario the virtio-iommu needs to know the
guest page size also known as granule. Expose it as an attribute
to the <driver/> element of a virtio-iommu.
This is possibly interesting only for aarch64 since it supports
virtio-iommu and also supports running guests with different page
size than the host.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Introduced in QEMU commit of v9.0.0-rc0~9^2~7 the virtio-iommu
device is also capable of using different addres width. The
corresponding attribute is also called 'aw-bits', just like in
case of intel-iommu. Wire up the missing pieces.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
This capability tracks whether the virtio-iommu device has
aw-bits attribute.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
So far, virDomainParseMemory() returns either 0 or -1. While this
allows callers to distinguish a success case from an error it
doesn't allow them to differentiate the case when no value was
provided in the XML, thus nothing was parsed and nothing was
required. Therefore, make virDomainParseMemory() return 1 on
success, 0 in case nothing was parsed and nothing was required,
and -1 on failure.
Arguably, no caller needs this distinction currently, but that is
about to change.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
When parsing a physical disk, the @hostResouce is escaped once
with the retval being stored into @hostEscaped. Then, it's
escaped again, but the retval is stored into the very same
variable, leading to a leak where intermediate value is lost.
256 bytes in 1 blocks are definitely lost in loss record 469 of 483
at 0x49543A0: realloc (vg_replace_malloc.c:1804)
by 0x516C251: g_realloc (in /usr/lib64/libglib-2.0.so.0.8400.4)
by 0x518BB7E: g_string_expand (in /usr/lib64/libglib-2.0.so.0.8400.4)
by 0x518BFF9: g_string_insert_len (in /usr/lib64/libglib-2.0.so.0.8400.4)
by 0x4A58B5F: g_string_append_len_inline (gstring.h:247)
by 0x4A58B5F: virBufferAdd (virbuffer.c:164)
by 0x4AFDA71: virStringReplace (virstring.c:708)
by 0x4DA4381: hypervDomainDefParsePhysicalDisk (hyperv_driver.c:1375)
by 0x4DA4A18: hypervDomainDefParseStorage (hyperv_driver.c:1487)
by 0x4DA9E31: hypervDomainGetXMLDesc (hyperv_driver.c:2761)
by 0x4DFB3E5: virDomainGetXMLDesc (libvirt-domain.c:2898)
by 0x406D39B: cmdDumpXML (virsh-domain.c:10787)
by 0x40B13B1: vshCommandRun (vsh.c:1383)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Libvirt vpx:// and esx:// URIs are quite obscure. In particular it is
very difficult to construct a correct path to a VMware resource.
Basically you are iterating over VMware structures blindly with no way
to know what your choices are at each level in the path.
This commit doesn't directly address this. It's still difficult. But
at least let's add the true path choices to the debug output so
someone could in theory use 'LIBVIRT_DEBUG=1' to find out what
possible choices exist at a path level.
For example this command fails because the label (which looks like an
IPv6 address, but is really a label) should use "::" instead of ":0:":
LIBVIRT_DEBUG=1 virsh -c 'vpx://root@.../data/aaaa:52:0:49e0:2eea:7fff:fee6:eca0/?no_verify=1'
In the debugging output we now print:
2026-02-05 10:58:25.421+0000: 1528876: debug : esxVI_LookupManagedObjectHelper:4956 : comparing path element 'aaaa:52:0:49e0:2eea:7fff:fee6:eca0' with candidate name 'aaaa:52::49e0:2eea:7fff:fee6:eca0'
2026-02-05 10:58:25.421+0000: 1528876: error : esxVI_Context_LookupManagedObjectsByPath:1098 : internal error: Could not find compute resource specified in '/data/aaaa:52:0:49e0:2eea:7fff:fee6:eca0/'
In an ideal world we should improve the error message to show the
possible choices, but the way the code is structured makes that
prohibitive.
Related: https://issues.redhat.com/browse/RHEL-145080
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Richard W.M. Jones <rjones@redhat.com>
Driver capabilities are allocated at the beginning of mymain(),
but roughly in the middle the architecture is switched to aarch64
and capabilities are constructed again. Without freeing the old
ones.
704 (288 direct, 416 indirect) bytes in 1 blocks are definitely lost in loss record 328 of 332
at 0x4885098: calloc (vg_replace_malloc.c:1682)
by 0x4EE35CA: g_malloc0 (in /usr/local/lib/libglib-2.0.so.0.8400.4)
by 0x53314B8: g_type_create_instance (in /usr/local/lib/libgobject-2.0.so.0.8400.4)
by 0x531A263: ??? (in /usr/local/lib/libgobject-2.0.so.0.8400.4)
by 0x531975E: g_object_new (in /usr/local/lib/libgobject-2.0.so.0.8400.4)
by 0x4AA9AB6: virObjectNew (virobject.c:252)
by 0x4AF0BBA: virCapabilitiesNew (capabilities.c:87)
by 0x401797B: virBhyveCapsBuild (bhyve_capabilities.c:51)
by 0x4012F57: mymain (bhyvexml2xmltest.c:60)
by 0x4016872: virTestMain (testutils.c:913)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
The firmwareDir member of driver config is set at the beginning
of mymain(). But then, roughly in the middle of test cases it is
overwritten to fakefirmwareemptydir. But this means the old value
must be freed. Or reassigned back to its original variable which
is freed automatically.
16 bytes in 1 blocks are definitely lost in loss record 190 of 505
at 0x4883224: malloc (vg_replace_malloc.c:451)
by 0x4EE6562: g_malloc (in /usr/local/lib/libglib-2.0.so.0.8400.4)
by 0x4F0100F: g_strdup (in /usr/local/lib/libglib-2.0.so.0.8400.4)
by 0x4013E26: g_strdup_inline (gstrfuncs.h:321)
by 0x4013E26: mymain (bhyvexml2argvtest.c:151)
by 0x40189A2: virTestMain (testutils.c:913)
by 0x4013DE6: main (bhyvexml2argvtest.c:354)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
At the beginning of mymain() the virBhyveDriverConfigNew() is
called which inits driver config with some paths. These are
then overwritten to produce stable test output. Well, the old
ones should be freed first.
128 bytes in 1 blocks are definitely lost in loss record 453 of 508
at 0x4883224: malloc (vg_replace_malloc.c:451)
by 0x506BD16: vasprintf_l (in /lib/libc.so.7)
by 0x4F39073: g_vasprintf (in /usr/local/lib/libglib-2.0.so.0.8400.4)
by 0x4F01288: g_strdup_printf (in /usr/local/lib/libglib-2.0.so.0.8400.4)
by 0x401F75B: virBhyveDriverConfigNew (bhyve_conf.c:62)
by 0x4013FAA: mymain (bhyvexml2argvtest.c:164)
by 0x4018892: virTestMain (testutils.c:913)
by 0x4013DC6: main (bhyvexml2argvtest.c:352)
25 bytes in 1 blocks are definitely lost in loss record 206 of 508
at 0x4883224: malloc (vg_replace_malloc.c:451)
by 0x4EE6562: g_malloc (in /usr/local/lib/libglib-2.0.so.0.8400.4)
by 0x4F0100F: g_strdup (in /usr/local/lib/libglib-2.0.so.0.8400.4)
by 0x401F715: g_strdup_inline (gstrfuncs.h:321)
by 0x401F715: virBhyveDriverConfigNew (bhyve_conf.c:60)
by 0x4013FAA: mymain (bhyvexml2argvtest.c:164)
by 0x4018892: virTestMain (testutils.c:913)
by 0x4013DC6: main (bhyvexml2argvtest.c:352)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Driver capabilities are allocated at the beginning of mymain(),
but roughly in the middle the architecture is switched to aarch64
and capabilities are constructed again. Without freeing the old
ones.
1,583 (288 direct, 1,295 indirect) bytes in 1 blocks are definitely lost in loss record 520 of 536
at 0x4888098: calloc (vg_replace_malloc.c:1682)
by 0x4EE65CA: g_malloc0 (in /usr/local/lib/libglib-2.0.so.0.8400.4)
by 0x53344B8: g_type_create_instance (in /usr/local/lib/libgobject-2.0.so.0.8400.4)
by 0x531D263: ??? (in /usr/local/lib/libgobject-2.0.so.0.8400.4)
by 0x531C75E: g_object_new (in /usr/local/lib/libgobject-2.0.so.0.8400.4)
by 0x4AAC806: virObjectNew (virobject.c:252)
by 0x4AF366A: virCapabilitiesNew (capabilities.c:87)
by 0x401998B: virBhyveCapsBuild (bhyve_capabilities.c:51)
by 0x4013E93: mymain (bhyvexml2argvtest.c:155)
by 0x4018882: virTestMain (testutils.c:913)
by 0x4013DC6: main (bhyvexml2argvtest.c:351)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
The bhyvexml2argvmock is loaded by bhyvexml2argvtest which calls
virBhyveCapsBuild() which in turn calls virCPUProbeHost(). To
make our test environment stable, it shouldn't depend on actual
CPU and thus mocked implementation for virCPUProbeHost should be
offered. Surprisingly, this is done in bhyveargv2xmlmock but not
in bhyvexml2argvmock. Until now.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Inside of bhyveBuildNetArgStr() there is @nic_model which is
allocated, appended into cmd line and then freed under cleanup
label. Firstly, There are few cases where instead of jumping onto
the label there's a return statement (this alone can lead to a
memory leak), but more importantly - the variable doesn't need
dynamically allocated string. It's the same story with @brname.
After making them both const strings, the return statements can
be used more freely (up until first possible allocation).
6 bytes in 1 blocks are definitely lost in loss record 4 of 508
at 0x4883224: malloc (vg_replace_malloc.c:451)
by 0x4EE6562: g_malloc (in /usr/local/lib/libglib-2.0.so.0.8400.4)
by 0x4F0100F: g_strdup (in /usr/local/lib/libglib-2.0.so.0.8400.4)
by 0x401BC02: g_strdup_inline (gstrfuncs.h:321)
by 0x401BC02: bhyveBuildNetArgStr (bhyve_command.c:64)
by 0x401B362: virBhyveProcessBuildBhyveCmd (bhyve_command.c:1033)
by 0x4015F15: testCompareXMLToArgvFiles (bhyvexml2argvtest.c:72)
by 0x4015BB9: testCompareXMLToArgvHelper (bhyvexml2argvtest.c:144)
by 0x4016598: virTestRun (testutils.c:143)
by 0x4015121: mymain (bhyvexml2argvtest.c:275)
by 0x4018892: virTestMain (testutils.c:913)
by 0x4013DC6: main (bhyvexml2argvtest.c:352)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
When building OS loader part of bhyve command line, there's @buf
declared and it is even correctly annotated with g_auto() to be
freed automatically. But then, the buffer contents is appended
onto the command line using virBufferContentAndReset() which
leads to a memleak because the buffer is reset. It's
virBufferCurrentContent() that should have been used instead.
128 bytes in 1 blocks are definitely lost in loss record 476 of 536
at 0x48882B1: realloc (vg_replace_malloc.c:1810)
by 0x4EE6622: g_realloc (in /usr/local/lib/libglib-2.0.so.0.8400.4)
by 0x4F048BC: g_string_new (in /usr/local/lib/libglib-2.0.so.0.8400.4)
by 0x4A59E1E: virBufferInitialize (virbuffer.c:121)
by 0x4A5A63C: virBufferVasprintf (virbuffer.c:321)
by 0x4A5A5DE: virBufferAsprintf (virbuffer.c:303)
by 0x401B22F: virBhyveProcessBuildBhyveCmd (bhyve_command.c:1021)
by 0x4015F05: testCompareXMLToArgvFiles (bhyvexml2argvtest.c:72)
by 0x4015BA9: testCompareXMLToArgvHelper (bhyvexml2argvtest.c:144)
by 0x4016588: virTestRun (testutils.c:143)
by 0x4015919: mymain (bhyvexml2argvtest.c:341)
by 0x4018882: virTestMain (testutils.c:913)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Inside of bhyveDomainAssignPCIAddresses() the @addr variable is
allocated and in a few cases stolen into domain private data. But
in all other cases the associated memory is never freed.
12,800 (3,200 direct, 9,600 indirect) bytes in 100 blocks are definitely lost in loss record 533 of 538
at 0x4888098: calloc (vg_replace_malloc.c:1682)
by 0x4EE67D9: g_malloc0_n (in /usr/local/lib/libglib-2.0.so.0.8400.4)
by 0x4AFD4AC: virDomainPCIAddressSetAlloc (domain_addr.c:1011)
by 0x4020F68: bhyveDomainPCIAddressSetCreate (bhyve_device.c:65)
by 0x40210BD: bhyveDomainAssignPCIAddresses (bhyve_device.c:219)
by 0x402180C: bhyveDomainAssignAddresses (bhyve_device.c:241)
by 0x4020083: bhyveDomainDefAssignAddresses (bhyve_domain.c:230)
by 0x4B71820: virDomainDefPostParse (domain_postparse.c:1503)
by 0x4B28282: virDomainDefParseNode (domain_conf.c:20565)
by 0x4B2810B: virDomainDefParse (domain_conf.c:20502)
by 0x4B281DF: virDomainDefParseFile (domain_conf.c:20549)
by 0x4015D6B: testCompareXMLToArgvFiles (bhyvexml2argvtest.c:47)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
The aim of bhyveParsePassthru() is to parse PCI address from
bhyve command line. The PCI address might be of a form
bus:slot:function or bus/slot/function. If the former isn't found
the latter is parsed (both using g_strsplit()). But after the
first call, g_strsplit() just returns a string list containing
but the whole input duplicated. Therefore, calling plain g_free()
is not enough, the array must be freed too.
6 bytes in 1 blocks are definitely lost in loss record 1 of 325
at 0x4863224: malloc (vg_replace_malloc.c:451)
by 0x4EC6562: g_malloc (in /usr/local/lib/libglib-2.0.so.0.8400.4)
by 0x4EE28D9: g_strsplit (in /usr/local/lib/libglib-2.0.so.0.8400.4)
by 0x4011297: bhyveParsePassthru (bhyve_parse_command.c:699)
by 0x4010082: bhyveParseBhyvePCIArg (bhyve_parse_command.c:800)
by 0x400EE14: bhyveParseBhyveCommandLine (bhyve_parse_command.c:862)
by 0x400DF9C: bhyveParseCommandLineString (bhyve_parse_command.c:1058)
by 0x4008CA0: testCompareXMLToArgvFiles (bhyveargv2xmltest.c:39)
by 0x4008B29: testCompareXMLToArgvHelper (bhyveargv2xmltest.c:105)
by 0x4009288: virTestRun (testutils.c:143)
by 0x40085AC: mymain (bhyveargv2xmltest.c:164)
by 0x400B582: virTestMain (testutils.c:913)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Consider bitmaps for incoming migration regardless of non-shared storage
flag.
When bitmaps are offered from the source, consult the local image if the
bitmap is present and if not accept migration. Migration of bitmaps
which exist in the qcow2 metadata is skipped because qemu rejects such
setup (although handles it correctly in case of shared storage setup;
see below).
This allows bitmap propagation for cases when the qcow2 image is not
actually shared between destinations but the data is (using the
data_file feature).
At the same time this preserves existing bitmap handling semantics for
other cases. Specifically qemu, in case of shared storage properly
propagates the bitmap which was already recorded in the qcow2 metadata
on disk even if libvirt doesn't instruct migration, yet tolerates
migration instruction if the file is not yet recorded in the on-disk
metadata. In both cases the contents are preserved correctly.
When storage is not shared (which includes even cases when we migrate
it via NBD) it's expected that the bitmaps don't exist on the
destination and thus all will be picked for migration. We can also
infer that this wasn't ever a problem by the fact that the code skipping
migration of existing bitmaps was broken until recently, and qemu
would refuse such config.
I've tested all the above scenarios including verifying that the
resulting bitmaps capture dirtied regions before and after migration.
For testing this the following command is useful:
virsh qemu-monitor-command --domain DOMNAME --hmp 'qemu-io -d /machine/peripheral/virtio-disk0/virtio-backend "write -P 0xcc 4M 1M"'
Which simulates a write from the guest side without the need to interact
with the guest OS.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Until now block dirty bitmaps were offered to destination only if
non-shared storage migration was enabled.
Upcoming patches will want to support it also in cases when storage is
shared but the destination has a qcow2 overlay using the 'data_file'
feature where the qcow2 overlay is not actually shared.
To support that we'll now always offer bitmaps for migration. The
destination can then decide (using existing logic) to pick only the
ones that are not present in the image on destination, which is how
it was supposed to work even now.
The patch removes all the flag checks and simply offers bitmaps in any
case. The overhead incurred by this is one 'query-named-block-nodes'
call to qemu.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
On incoming migration qemu doesn't load bitmaps into memory (which makes
them available under the 'dirty-bitmaps' field which we parse as the
'bitmaps' array in 'qemuBlockNamedNodeData') until after actually
resuming CPUs, thus the check for existing bitmaps never actually
worked.
We need to check the 'qcow2bitmaps' field instead which is populated
from the qcow2 headers prior to activating the image.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We currently probe dirty block tracking bitmaps by looking at the loaded
ones ('dirty-bitmaps'). Unfortunately those may not yet be populated on
incoming migration when the image was not yet activated, but we need to
know which ones are stored in the image so that we don't migrate those
explicitly, which would fail.
Load the list of bitmaps in a qcow2 image from the format specific data,
which is already loaded at that point.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Rather than looking for 30 specific nodenames (via a loop) iterate
everything in the hash table (in a sorted order). This simplifies the
code and provides more test outputs on previously-ignored nodenames.
The listing of internal snapshots in the output was also missing a
newline, which would now cause problems with multiple images reproted.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In previous commit of v12.0.0-85-g2c66b6d72c we've tried to solve
a problem where xdrproc_t is a prototype of a function which
takes only two arguments instead of three. See original commit
for more info. The fix consists of a config time check and
setting XDRPROC_T_3ARGS accordingly (in meson-config.h). This
works for nearly all of our code, except rpcgen which is
intentionally independent of the rest of the code. Therefore, the
macro has to be set extra - by specifying it on the compiler cmd
line.
Fixes: 2c66b6d72c
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
According to 9fa3a8ab6f,
macOS insists on passing 3 arguments for xdrproc_t.
Passing 3 arguments was a good common ground, but since
recently[1] FreeBSD only accepts 2 arguments.
Add a meson.build check whether 3 arguments are accepted,
and add macros which passes either 2 or 3 arguments to
xdrproc_t based on the result of this check.
1: https://cgit.freebsd.org/src/commit/?id=ac5a19ec6989675c8ec6c3ca245dba243d1a6416
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Provide sample XML and CLI args for the iommufd XML schema
for pc, q35, and virt machine types.
Signed-off-by: Nathan Chen <nathanc@nvidia.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
When launching a qemu VM with the iommufd feature enabled for VFIO
hostdevs:
- Do not allow cgroup, namespace, and seclabel access to VFIO
paths (/dev/vfio/vfio and /dev/vfio/<iommugroup>)
- Allow access to iommufd paths (/dev/iommu and
/dev/vfio/devices/vfio*) for AppArmor, SELinux, and DAC
Signed-off-by: Nathan Chen <nathanc@nvidia.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Open iommufd FD from libvirt backend without exposing
these FDs to XML users, i.e. one per domain for
/dev/iommu, and pass the FD to qemu command line. Set
per-process memory accounting for iommufd instead of
the default per-user memory accounting.
Suggested-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Nathan Chen <nathanc@nvidia.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Open VFIO FDs from libvirt backend without exposing
these FDs to XML users, i.e. one per iommufd hostdev
for /dev/vfio/devices/vfioX, and pass the FD to qemu
command line.
Suggested-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Nathan Chen <nathanc@nvidia.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Implement the IOMMU_OPTION_RLIMIT_MODE
ioctl to set per-process memory accounting for
iommufd. This prevents ENOMEM errors from the
default per-user memory accounting when multiple
VMs under the libvirt-qemu user have their pinned
memory summed and checked against a per-process
RLIMIT_MEMLOCK limit.
Signed-off-by: Nathan Chen <nathanc@nvidia.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Introduce private data for hostdevs and allocate hostdev
private data by default.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Nathan Chen <nathanc@nvidia.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Implement a new iommufd attribute under hostdevs' PCI
subsystem driver that can be used to specify associated
iommufd object when launching a qemu VM.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Nathan Chen <nathanc@nvidia.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The "virt" board in QEMU has a "virtualization" option
that is documented like this:
virtualization
Set ``on``/``off`` to enable/disable emulating a guest CPU which implements the
Arm Virtualization Extensions. The default is ``off``.
(from system/arm/virt.rst)
According to the documentation, the "virtualiaztion" option
is related to the "gic-version" option. Specifically, gic version=4
requires virtualization to be enabled. And gic version=max will use
version=4 when virtualization is enabled, and 3 when not.
Libvirt does not currently model neither gic version "4" nor "max"
though.
It is also documented for the "vexpress-a(9|15)" boards, where it is
also disabled by default:
- QEMU defaults to providing a CPU which does not provide either
TrustZone or the Virtualization Extensions: if you want these you
must enable them with ``-machine secure=on`` and ``-machine
virtualization=on``
(system/arm/vexpress.rst).
On the command line it looks like:
qemu-system-aarch64 -machine type=virt,virtualization=on ..
Model it using the "virtualization" element in the "features" section:
<features>
<virtualization/>
</features>
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Our network has multiple means of forwarding the traffic and
'hostdev' is one of them. This mode means that the network is
configured to use a set of PCI devices which are then assigned to
individual domains to use (PCI device assignment). Now, as of
v12.0.0-61-gecb2e06bdf our test runners
(testCompareXMLToXMLFiles() and testCompareXMLToConfFiles()) call
networkValidateTests(). For aforementioned type of network this
means checking that the specified set of devices contains only
VFs (see v3.2.0-rc1~24 for more info). It is true that our
virpcimock is preloaded which mimics VFs, but our utils module
(virpci.c specifically) talks to sysfs to check various PCI
device attributes, including whether it's a VF.
This obviously works on Linux and doesn't work anywhere else.
Therefore, until our utils module is taught how to check PCI
attribs on other systems, make the "hostdev" test case expect
validation failure on non-Linux systems.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Now that networkxml2xmltest does both XML -> XML and XML -> conf
tests its name became misleading. Rename it to networkxmlconftest
and move its data into networkxmlconfdata/ dir.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Dion Bosschieter
Maximilian Martin
Jean-Louis Dupond
Michal Privoznik
Richard W.M. Jones
Peter Krempa
Roman Bogorodskiy
Nathan Chen
Pavel Borecki