Commit Graph

42534 Commits

Author SHA1 Message Date
Michal Privoznik
7d97d7af9e vircaps2xmltest: Introduce HMAT test case
This test was generated on a guest with the following NUMA
configuration:

    <numa>
      <cell id='0' cpus='0-23' memory='4194304' unit='KiB' discard='yes'>
        <cache level='1' associativity='direct' policy='writeback'>
          <size value='10' unit='KiB'/>
          <line value='8' unit='B'/>
        </cache>
        <cache level='2' associativity='full' policy='writethrough'>
          <size value='128' unit='KiB'/>
          <line value='16' unit='B'/>
        </cache>
      </cell>
      <cell id='1' memory='2097152' unit='KiB'>
        <cache level='1' associativity='direct' policy='writeback'>
          <size value='10' unit='KiB'/>
          <line value='8' unit='B'/>
        </cache>
      </cell>
      <interconnects>
        <latency initiator='0' target='0' type='access' value='5'/>
        <latency initiator='0' target='0' type='read' value='6'/>
        <latency initiator='0' target='0' type='write' value='7'/>
        <latency initiator='0' target='1' type='access' value='10'/>
        <latency initiator='0' target='1' type='read' value='11'/>
        <latency initiator='0' target='1' type='write' value='12'/>
        <bandwidth initiator='0' target='0' type='access' value='204800' unit='KiB'/>
        <bandwidth initiator='0' target='0' type='read' value='205824' unit='KiB'/>
        <bandwidth initiator='0' target='0' type='write' value='206848' unit='KiB'/>
        <bandwidth initiator='0' target='0' cache='1' type='access' value='208896' unit='KiB'/>
        <bandwidth initiator='0' target='0' cache='1' type='read' value='209920' unit='KiB'/>
        <bandwidth initiator='0' target='0' cache='1' type='write' value='210944' unit='KiB'/>
        <bandwidth initiator='0' target='1' type='access' value='102400' unit='KiB'/>
        <bandwidth initiator='0' target='1' type='read' value='103424' unit='KiB'/>
        <bandwidth initiator='0' target='1' type='write' value='104448' unit='KiB'/>
        <bandwidth initiator='0' target='1' cache='1' type='access' value='105472' unit='KiB'/>
        <bandwidth initiator='0' target='1' cache='1' type='read' value='106496' unit='KiB'/>
        <bandwidth initiator='0' target='1' cache='1' type='write' value='107520' unit='KiB'/>
      </interconnects>
    </numa>

The sysfs content was also copied over from the VM but only those
files which are accessed in the test are stored in the repo.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
2021-06-15 11:03:56 +02:00
Michal Privoznik
0cc6f8931f capabilities: Expose NUMA interconnects
Links between NUMA nodes can have different latencies and
bandwidths. This info is newly defined in ACPI 6.2 under
Heterogeneous Memory Attribute Table (HMAT) table. Linux kernel
learned how to report these values under sysfs and thus we can
expose them in our capabilities XML. The sysfs interface is
documented in kernel's Documentation/admin-guide/mm/numaperf.rst.

Long story short, two nodes can be in initiator-target
relationship. A node can be initiator if it has a CPU or a device
that's capable of initiating memory transfer. Therefore a node
that has just memory can only be target. An initiator-target link
can then have any combination of {bandwidth, latency} - {access,
read, write} attribute (6 in total). However, the standard says
access is applicable iff read and write values are the same.
Therefore, we really have just four combinations of attributes:
bandwidth-read, bandwidth-write, latency-read, latency-write.

This is the combination that kernel reports anyway.

Then, under /sys/system/devices/node/nodeX/acccessN/initiators we
find values for those 4 attributes and also symlinks named
"nodeN" which then represent initiators to nodeX. For instance:

  /sys/system/node/node1/access1/initiators/node0 -> ../../node0
  /sys/system/node/node1/access1/initiators/read_bandwidth
  /sys/system/node/node1/access1/initiators/read_latency
  /sys/system/node/node1/access1/initiators/write_bandwidth
  /sys/system/node/node1/access1/initiators/write_latency

This means that node0 is initiator and node1 is target and values
of the interconnect can be read.

In theory, there can be separate links to memory side caches too
(e.g. one link from node X to node Y's main memory, another from
node X to node Y's L1 cache, another one to L2 cache and so on).
But sysfs does not express this relationship just yet.

The "accessN" means either "access0" or "access1". The difference
is that while the former expresses the best interconnect between
two nodes including CPUS and I/O devices (such as GPUs and NICs),
the latter includes only CPUs and thus is what we need.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1786309
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
2021-06-15 11:03:25 +02:00
Michal Privoznik
0d7e62348e numa_conf: Expose virNumaInterconnect formatter
Expose virNumaInterconnect XML formatter so that it can be
re-used by other parts of the code.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
2021-06-15 10:41:22 +02:00
Michal Privoznik
6ad17e290e numa_conf: Rename virDomainNumaInterconnect* to virNumaInterconnect*
There's nothing domain specific about NUMA interconnects. Rename
the virDomainNumaInterconnect* structures and enums to
virNumaInterconnect*.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
2021-06-15 10:41:22 +02:00
Michal Privoznik
5c359377a0 capabilities: Expose NUMA memory side cache
Memory on a NUMA node can have a side caches. Configuring these
for a domain was implemented in v6.6.0-rc1~249 and friends.
However, up until now mgmt applications did not really know what
values to pass because we were not exposing caches of the host.
With recent enough kernel these are exposed under sysfs and with
a bit of parsing we can extend our capabilities XML. The sysfs
structure is documented in kernel's
Documentation/admin-guide/mm/numaperf.rst and basically maps in
1:1 fashion to our virNumaCache structure.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
2021-06-15 10:41:22 +02:00
Michal Privoznik
03ba98b259 numa_conf: Expose virNumaCache formatter
Expose virNumaCache XML formatter so that it can be re-used by
other parts of the code.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
2021-06-15 10:41:22 +02:00
Michal Privoznik
b0b7554229 numa_conf: Rename virDomainCache* to virNumaCache*
There's nothing domain specific about NUMA memory caches. Rename the
virDomainCache* structures and enums to virNumaCache*.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
2021-06-15 10:41:22 +02:00
Michal Privoznik
d6a6ed94f2 capabilities: Separate <cpu/> formatting into a function
The way we format <cpu/> element for capabilities is not ideal,
because if there are no CPUs, i.e. no child elements, we still
output opening and closing element. To solve this,
virXMLFormatElement() could be used but that would introduce more
variables into the loop. Therefore, move the formatter into a
separate function and use virXMLFormatElement().

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
2021-06-15 10:41:22 +02:00
Michal Privoznik
137e765891 schemas: Allow zero <cpu/> for capabilities
It may happen that a NUMA node has no CPUs associated with it. We
allow this for domains since v6.6.0-rc1~250. Let's update our
capabilities schema to match that.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
2021-06-15 10:41:22 +02:00
Michal Privoznik
5899bfd795 tests: glib-ify vircaps2xmltest
Ideally, turning pointers into g_auto* would be done in one step
and dropping cleanup label and unused @ret variable in second
step, but since this is a test we don't care that much, do we?

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
2021-06-15 10:41:22 +02:00
Lin Ma
3dab81cb21 virsh-pool: Add virshPoolTypeCompleter in macro VIRSH_COMMON_OPT_POOL_X_AS
Signed-off-by: Lin Ma <lma@suse.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-06-15 10:28:04 +02:00
Lin Ma
8cdbca6213 virsh: Add format completion to blockcopy command
Signed-off-by: Lin Ma <lma@suse.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-06-15 10:28:02 +02:00
Lin Ma
8de9a54b9e virsh: Add target completion to dompmsuspend command
Signed-off-by: Lin Ma <lma@suse.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-06-15 10:27:59 +02:00
Lin Ma
b41811b93d virsh: Use VIR_ENUM_* for --target argument in cmdDomPMSuspend
Signed-off-by: Lin Ma <lma@suse.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-06-15 10:27:57 +02:00
Lin Ma
0691d642ba virsh: Add target completion to nodesuspend command
Signed-off-by: Lin Ma <lma@suse.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-06-15 10:27:55 +02:00
Lin Ma
7d1028c3f6 virsh: Use VIR_ENUM_* for --target argument in cmdNodeSuspend
Signed-off-by: Lin Ma <lma@suse.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-06-15 10:27:53 +02:00
Lin Ma
a61a6978d3 virsh: Add comp-methods completion to migrate command
Signed-off-by: Lin Ma <lma@suse.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-06-15 10:27:47 +02:00
Pavel Hrdina
f14ca48ef4 qemu_firmware: select correct firmware for AMD SEV-ES
When using firmware auto-selection and user enables AMD SEV-ES we need
to pick correct firmware that actually supports it. This can be detected
by having `amd-sev-es` in the firmware JSON description.

Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-06-14 14:23:21 +02:00
Michal Privoznik
2b20f3e0fa src: Use 1U for bit shifting
In a few places we take 1 and shift it left repeatedly. So much
that it won't longer fit into signed integer. The problem is that
this is undefined behaviour. Switching to 1U makes us stay within
boundaries.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
2021-06-14 14:16:54 +02:00
Michal Privoznik
1ab5a37c4a Don't call qsort() over NULL
In a few places it may happen that the array we want to sort is
still NULL (e.g. because there were no leases found, no paths for
secdriver to lock or no cache banks). However, passing NULL to
qsort() is undefined and even though glibc plays nicely we
shouldn't rely on undefined behaviour.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
2021-06-14 14:16:44 +02:00
Tim Wiederhake
8f52136592 ci: Enable address and undefined behavior sanitizers
meson supports the following sanitizers: "address" (e.g. out-of-bounds
memory access, use-after-free, etc.), "thread" (data races), "undefined"
(e.g. signed integer overflow), and "memory" (use of uninitialized
memory). Note that not all sanitizers are supported by all compilers,
and that more sanitizers exist.

Not all sanitizers can be enabled at the same time, but "address" and
"undefined" can. Both thread and memory sanitizers require an instrumented
build of all dependencies, including libc.

gcc and clang use different implementations of these sanitizers and
have proven to find different issues. Create CI jobs for both.

Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-06-14 12:06:11 +02:00
Tim Wiederhake
6ac97ef8a3 virt-aa-helper: Remove duplicate linking with src/datatypes.o
"virt-aa-helper" links, amongst others, against "datatypes.o" and
"libvirt.so". The latter links against "libvirt_driver.a" which in turn
also links against "datatypes.o", leading to a One-Definition-Rule
violoation for "virConnectClass" et al. in "datatypes.c".

Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-06-14 12:06:06 +02:00
Tim Wiederhake
fcecdb7d06 tests: openvzutilstest: Remove duplicate linking with libvirt_openvz.a
"openvzutilstest" links, amongst others, against "libvirt_openvz.a" and
"libvirt.so". The latter also links against "libvirt_openvz.a", leading
to a One-Definition-Rule violation for "openvzLocateConfFile" in
"openvz_conf.c".

Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-06-14 12:06:01 +02:00
Tim Wiederhake
22d39e1af3 openvz: Add missing symbols to libvirt_openvz.syms
Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-06-14 12:05:54 +02:00
Tim Wiederhake
a86682c57e tests: virfilemock: realpath: Allow non-null second parameter
When other preloaded libraries wrap and / or make calls to `realpath`
(e.g. LLVM's AddessSanitizer), the second parameter is no longer
guaranteed to be NULL.

Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-06-14 12:05:50 +02:00
Tim Wiederhake
c9ced46673 meson: Allow undefined symbols when sanitizers are enabled
When enabling sanitizers, clang adds some function symbols when
instrumenting the code. The exact names of those functions are an
implementation detail and should therefore not be added to any
syms file. This patch prevents build failures due to those symbols
not present in the syms file when building with sanitizers enabled.

Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-06-14 12:05:41 +02:00
Tim Wiederhake
c46556c280 meson: Allow larger stack frames when instrumenting
When enabling sanitizers, gcc adds some instrumentation to the code
that may enlarge stack frames. Some function's stack frames are already
close to the limit of 4096 and are enlarged past that threshold,
e.g. virLXCProcessStart which reaches a frame size of 4624 bytes.

Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-06-14 12:05:10 +02:00
Michal Privoznik
55ea45acc9 qemuBuildDeviceVideoStr: Don't overwrite @model
Now we have everything prepared so that @model doesn't have to be
rewritten. The correct model can be chosen right from the
beginning.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
2021-06-11 21:53:48 +02:00
Michal Privoznik
96414611ef qemuBuildDeviceVideoStr: Move logic wrapping qemuBuildVirtioDevStr() into qemuDeviceVideoGetModel()
We want to call qemuBuildVirtioDevStr() from
qemuBuildDeviceVideoStr() but only for some models (currently
"virtio-gpu" and "vhost-user-gpu"), not all of them. Move this
logic into qemuDeviceVideoGetModel() because this logic will be
refined.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
2021-06-11 21:53:45 +02:00
Michal Privoznik
bdb0bfe8f8 qemu_command: Switch from VIR_ENUM_IMPL(qemuDeviceVideoSecondary) to explicit switch()
This may look like a step backwards, but it isn't. The point is
that in near future the chosen model will depend on more than
just video type.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
2021-06-11 21:53:44 +02:00
Michal Privoznik
104271c084 qemu_command: Switch from VIR_ENUM_IMPL(qemuDeviceVideo) to explicit switch()
This may look like a step backwards, but it isn't. The point is
that in near future the chosen model will depend on more than
just video type.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
2021-06-11 21:53:43 +02:00
Michal Privoznik
44d7a77c81 qemuDeviceVideoGetModel: Deduplicate a check
There is the same check written twice (whether given video card
is primary one and whether it supports VGA mode). Write it just
once and store it in a boolean variable.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
2021-06-11 21:53:42 +02:00
Michal Privoznik
614fb5546c qemuBuildDeviceVideoStr: Separate out video module selection
The code that decides video card model is going to be reworked
and expanded. Separate it out into a function.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
2021-06-11 21:53:42 +02:00
Michal Privoznik
b159ff83a5 qemuDomainSupportsVideoVga: Fix const correctness
This function doesn't modify passed video definition. Make the
argument const.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
2021-06-11 21:53:40 +02:00
Han Han
3f335a61e0 tests: Tests for virtio-vga-gl and virtio-gpu-gl-pci device
Signed-off-by: Han Han <hhan@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-06-11 13:06:58 +02:00
Han Han
0c67324648 qemu: Adapt to virtio-vga-gl device
QEMU 6.1 will replace the virgl property of virtio-vga device to
virtio-vga-gl device. Adapt to that update.

Resolves: https://gitlab.com/libvirt/libvirt/-/issues/167

Signed-off-by: Han Han <hhan@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-06-11 13:06:56 +02:00
Han Han
b99762b61e qemu: Adapt to virtio-gpu-gl-pci device
QEMU 6.1 will add virtio-gpu-gl-pci device to replace the virgl property
of virtio-gpu-pci device. Adapt to that change.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1967356

Signed-off-by: Han Han <hhan@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-06-11 13:06:53 +02:00
Han Han
38aed410ac qemu_validate: Validate virtio*gl* devices for 3d accerlation
The devices virtio-gpu-gl-pci and virtio-vga-gl, aimed to replace the
virgl property, are valid for 3d accerlation as well.

Signed-off-by: Han Han <hhan@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-06-11 13:06:50 +02:00
Han Han
456d6c142e qemu_capabilities: Add QEMU_CAPS_VIRTIO_VGA_GL
It will be used for virtio-vga-gl device later.

Signed-off-by: Han Han <hhan@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-06-11 13:06:47 +02:00
Han Han
0263d6a93d qemu_capabilities: Add QEMU_CAPS_VIRTIO_GPU_GL_PCI
This flag will be used for the device virtio-gpu-gl-pci which is introduced
since QEMU 6.1.

Signed-off-by: Han Han <hhan@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-06-11 13:06:44 +02:00
Tim Wiederhake
05306cab74 cpu_map: Add cpu feature avx-vnni
"avx-vvni" was introduced to qemu in commit
c1826ea6a052084f2e6a0bae9dd5932a727df039, adding it Cooperlake.

This feature is currently not used by any libvirt CPU models, but its
addition silences a warning from sync_qemu_i386.py:

```
warning: Unknown feature 'CPUID_7_1_EAX_AVX_VNNI'
warning: Feature unknown to libvirt: CPUID_7_1_EAX_AVX_VNNI
```

Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-06-11 09:41:16 +02:00
Laine Stump
2a51ff7b40 openvswitch: don't delete existing OVS port prior to recreating same port
Connecting a tap device to an Open vSwitch is done by adding a "port"
to the switch with the ovs-vsctl "add-port" command. The port will
have the same name as the tap device, but it is a separate entity, and
can survive beyond the destruction of the tap device (although under
normal circumstances the port will be deleted around the same time the
tap device is deleted).

This makes it possible for a port of a particular name to already
exist at the time libvirt calls ovs-vsctl to add that port. The
original commit of Open vSwitch support (commit df81004632, libvirt
0.9.10, Feb. 2012) used the "--may-exist" option to the add-port
command to indicate that a port of the desired name might already
exist, and that it was okay to simply re-use this port (rather than
failing with an error message).

Then in commit 33445ce844 (libvirt 1.2.7, April 2014) the command
was changed to use "--if-exists del-port blah" instead of
"--may-exist". The reason given was that there was a bug in OVS where
a stale port would be unusable even though it still existed; the
workaround was to forcibly delete any existing port prior to adding
the new port (of the same name). This is the ovs-vsctl command still
in use by libvirt today.

It recently came up in the discussion of a bug concerning guest packet
loss during OpenStack upgrades (https://bugzilla.redhat.com/1963164)
that the bug in OVS that necessitated the del-port workaround was
fixed quite a long time ago (August 2015):

  e21c6643a0

thus rendering the workaround in libvirt unnecessary. The assertion in
that discussion is that this workaround is now the cause of the packet
loss being experienced during OpenStack upgrades. I'm not convinced
this is the case, but it does appear that there is no reason to carry
this workaround in libvirt any longer, so this patch reverts the code
back to the original behavior (using "--may-exist" instead of
"--if-exists del-port").

Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-06-10 01:23:47 -04:00
Michal Privoznik
1808159f32 domain_conf: Use virXMLFormatElement() more
I've identified some places (mostly by looking for
virBufferUse()) that can use virXMLFormatElement() instead of
open coded version of it. I'm sure there are many more places
that could use the same treatment. Let's cure them some other
time.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2021-06-09 16:05:40 +02:00
Daniel P. Berrangé
9986e7379f docs: switch ci status page to use Go -module repos
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-06-09 14:48:40 +01:00
Tim Wiederhake
017279d9a8 cpu_map: sync_qemu_i386.py: Remove superfluous semicolon
The semicolon in question makes the pipeline fail over a style checker
complaint.

Introduced-in: 360b8eb2d2
Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-06-09 13:15:42 +02:00
Fabiano Fidêncio
93e9e92c1e virt-host-validate: Fix IOMMU output on aarch64
virt-host-validate should print "Checking for device assignment IOMMU
support" for all architectures, not only for Intel / AMD.

This is the output without the patch:
```
[fidencio@dentola libvirt]$ virt-host-validate
  QEMU: comprobando if device /dev/kvm exists                                   : PASA
  QEMU: comprobando if device /dev/kvm is accessible                            : PASA
  QEMU: comprobando if device /dev/vhost-net exists                             : PASA
  QEMU: comprobando if device /dev/net/tun exists                               : PASA
  QEMU: comprobando for cgroup 'cpu' controller support                         : PASA
  QEMU: comprobando for cgroup 'cpuacct' controller support                     : PASA
  QEMU: comprobando for cgroup 'cpuset' controller support                      : PASA
  QEMU: comprobando for cgroup 'memory' controller support                      : PASA
  QEMU: comprobando for cgroup 'devices' controller support                     : ADVERTENCIA (Enable 'devices' in kernel Kconfig file or mount/enable cgroup controller in your system)
  QEMU: comprobando for cgroup 'blkio' controller support                       : PASA
ADVERTENCIA (Unknown if this platform has IOMMU support)
  QEMU: comprobando for secure guest support                                    : ADVERTENCIA (Unknown if this platform has Secure Guest support)

```

This is the output with the patch:
```
[fidencio@dentola libvirt]$ ./build/tools/virt-host-validate
  QEMU: Checking if device /dev/kvm exists                                   : PASS
  QEMU: Checking if device /dev/kvm is accessible                            : PASS
  QEMU: Checking if device /dev/vhost-net exists                             : PASS
  QEMU: Checking if device /dev/net/tun exists                               : PASS
  QEMU: Checking for cgroup 'cpu' controller support                         : PASS
  QEMU: Checking for cgroup 'cpuacct' controller support                     : PASS
  QEMU: Checking for cgroup 'cpuset' controller support                      : PASS
  QEMU: Checking for cgroup 'memory' controller support                      : PASS
  QEMU: Checking for cgroup 'devices' controller support                     : WARN (Enable 'devices' in kernel Kconfig file or mount/enable cgroup controller in your system)
  QEMU: Checking for cgroup 'blkio' controller support                       : PASS
  QEMU: Checking for device assignment IOMMU support                         : WARN (Unknown if this platform has IOMMU support)
  QEMU: Checking for secure guest support                                    : WARN (Unknown if this platform has Secure Guest support)
```

Signed-off-by: Fabiano Fidêncio <fabiano@fidencio.org>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-06-09 12:51:36 +02:00
Tim Wiederhake
f1f30793b2 cpu_map: sync_qemu_i386.py: Allow begin mark to contain const
This was introduced in qemu commit
e11fd68996fb27c040552320f01a7d30a15a7cc1.

Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-06-09 11:57:00 +02:00
Tim Wiederhake
360b8eb2d2 cpu_map: sync_qemu_i386.py: Use regex to look for begin mark
Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-06-09 11:56:57 +02:00
Michal Privoznik
51ff124d9c virCHDriverConfig: Drop @uri member
This member is unused (apart from only being set in
virCHDriverConfigNew()), and never freed really (leading to a
memleak).

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2021-06-09 11:24:59 +02:00
Daniel P. Berrangé
b4701fe648 ch: set driver to NULL after freeing it
If the chStateInitialize method fails, we call chStateCleanup
which free's all global state. It fails to set the global
'ch_driver' to NULL, however, so a later attempt to open the
cloud hypervisor driver will succeed and then crash attempting
to access freed memory.

Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-06-09 10:18:04 +01:00