1
0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2025-01-13 00:01:55 +00:00

35444 Commits

Author SHA1 Message Date
Jiri Denemark
cbee851581 Add vmx-* features to Cooperlake
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
2024-03-14 16:15:06 +01:00
Jiri Denemark
9cb8c372cd Add vmx-* features to Conroe
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
2024-03-14 16:15:06 +01:00
Jiri Denemark
5db6195225 Add vmx-* features to Cascadelake*
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
2024-03-14 16:15:06 +01:00
Jiri Denemark
ce330dd7e5 Add vmx-* features to Broadwell*
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
2024-03-14 16:15:06 +01:00
Jiri Denemark
f9d2531516 cpu_map: Do not ignore VMX features in sync_qemu_models script
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
2024-03-14 16:15:06 +01:00
Jiri Denemark
14d3517410 qemu: domain: Drop added features from migratable CPU
Features marked with added='yes' in CPU model definitions have to be
removed before migration, otherwise older libvirt would complain about
unknown CPU features. We only do this for features that were enabled for
a given CPU model even with older libvirt, which just ignored the
features. And only for features we added ourselves when updating CPU
definition during domain startup, that is we do not remove features
which were explicitly mentioned by a user.

That said, this is not the safest thing we could do, but it's
effectively the same thing we did before the affected features were
added: we ignored them completely on both sides of migration.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
2024-03-14 16:15:06 +01:00
Jiri Denemark
577c4ca414 conf: cpu: Introduce virCPUDefListFeatures
The function returns a list of explicitly mentioned features in the CPU
definition.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
2024-03-14 16:15:06 +01:00
Jiri Denemark
909564c365 qemu: domain: Check arch in qemuDomainMakeCPUMigratable
The content is arch specific and checking for Icelake-Server CPU model
on non-x86 architectures does not make sense.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
2024-03-14 16:15:06 +01:00
Jiri Denemark
5fbfa5ab8a cpu: x86: Add support for adding features to existing CPU models
This is not a good idea in general, but we can (and have to) do it in
specific cases when a feature has always been part of a CPU model in
hypervisor's definition, but we ignored it and did not include the
feature in our definition.

Blindly adding the features to the CPU map and not adding them to
existing CPU models breaks migration between old and new libvirt in both
directions. New libvirt would complain the features got unexpectedly
enabled (as they were not mentioned in the incoming domain XML) even
though they were also enabled on the source and the old libvirt just
didn't know about them. On the other hand, old libvirt would refuse to
accept incoming migration of a domain started by new libvirt because the
domain XML would contain CPU features unknown to the old libvirt.

This is exactly what happened when several vmx-* features were added a
few releases back. Migration between libvirt releases before and after
the addition is now broken.

This patch adds support for added these features to existing CPU models
by marking them with added='yes'. The features will not be considered
part of the CPU model and will be described explicitly via additional
<feature/> elements, but the compatibility check will not complain if
they are enabled by the hypervisor even though they were not explicitly
mentioned in the CPU definition and incoming migration from old libvirt
will succeed.

To fix outgoing migration to old libvirt, we also need to drop all those
features from domain XML unless they were explicitly requested by the
user. This will be handled by a later patch.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
2024-03-14 16:15:06 +01:00
Michal Privoznik
6abc1273cf capabilities: Allow suppressing error message from virCapabilitiesDomainSupported()
In a few cases (CH driver) we want
virCapabilitiesDomainSupported() just to check whether given
virtType is supported and report a different error message (that
suggests how to solve the problem). Introduce reportError
argument which makes the function report an error iff set.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
2024-03-12 17:39:21 +01:00
Michal Privoznik
36c6d40943 capabilities: Allow suppressing error message from virCapabilitiesDomainDataLookup()
In near future we will want to check whether capabilities for
given virtType exist, but report an error on our own. Introduce
reportError argument which makes the function report an error iff
set.

In one specific case (virQEMUCapsGetDefaultVersion()) we were
even overwriting (more specific) error message reportd by
virCapabilitiesDomainDataLookup(). Drop that too.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
2024-03-12 17:39:09 +01:00
Michal Privoznik
1cc5d7df9a ch: Demote error when CH driver fails to init
If the host doesn't have /dev/kvm nor /dev/mshv, i.e. CH driver
is unable to run any guests, then an error is reported. But the
usual thing to do here is print an info message into the logs and
return VIR_DRV_STATE_INIT_SKIPPED. It is a recoverable error
after all.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
2024-03-12 17:38:10 +01:00
Abhiram Tilak
f432114d9c storage: Upgrade default qcow2 verion to 1.1
Change the default to modern qcow2 as it's supported by all qemu
versions supported by libvirt and in fact 'qemu-img' already defaults to
the new format for a long time.

Some Unittests require changes to pass, now that version 1.1 is default.
Unittests like `qcow2-1.1.argv` may not be relevant anymore, but this
patch doesn't affect them.

Closes: https://gitlab.com/libvirt/libvirt/-/issues/602
Signed-off-by: Abhiram Tilak <atp.exp@gmail.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
2024-03-12 10:34:43 +01:00
Ján Tomko
2f22d2a1ef remote: add VIR_ERR_NO_NETWORK_METADATA to daemonErrorLogFilter
Similar to other VIR_ERR_NO_* errors, we don't want to spam the daemon
log with these messages.

Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2024-03-11 16:06:46 +01:00
Zheng Yan
a74897efe6 qemu: implement qemuDomainGraphicsReload
The 'display-reload' QMP command had been introduced from QEMU 6.0.0:

9cc0765165

Currently it only supports reloading TLS certificates for VNC.

Resloves: https://issues.redhat.com/browse/RHEL-16333

Signed-off-by: Zheng Yan <yanzheng759@huawei.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2024-03-08 17:00:15 +01:00
Ján Tomko
21e68a9ce7 remote: implement virDomainGraphicsReload
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2024-03-08 17:00:15 +01:00
Zheng Yan
b25b071c75 libvirt: Introduce virDomainGraphicsReload API
The new virDomainGraphicsReload API is used to make the domain reload
its certificates without restart, and avoid service interruption.

Currently, only QEMU VNC TLS certificates are supported, but
flags are also reserved for subsequent scenarios.

To reload QEMU VNC TLS certificates as an example, we can call:

  virDomainGraphicsReload(domain, 0, 0);

Then the specified QMP message would be send to QEMU:
{"execute": "display-reload", "arguments":{"type": "vnc", "tls-certs": true}}

Signed-off-by: Zheng Yan <yanzheng759@huawei.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2024-03-08 17:00:15 +01:00
Zheng Yan
bec963f878 qemu_capabilities: Add QEMU_CAPS_DISPLAY_RELOAD
The 'display-reload' QMP command was introduced in QEMU 6.0.0, so we
add a compatible capability to check if target QEMU binary supports it.

{"execute":"display-reload", "arguments":{"type": "vnc", "tls-certs": true}}

The new QMP refer to:
9cc0765165

Signed-off-by: Zheng Yan <yanzheng759@huawei.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2024-03-08 17:00:15 +01:00
Praveen K Paladugu
51c14df967 ch: Enable hyperv hypervisor
Cloud-Hypervisor is capable of running VMs with kvm or mshv as the
hypervisor on Linux Host. Guest to hypevisor ABI with mshv hypervisor is
the same as in the case of VIR_DOMAIN_VIRT_HYPERV. So, VIR_DOMAIN_VIRT_HYPERV
type will be reused to represent the config with Linux Host and mshv as the
hypervisor.

While initializing ch driver, check if either of /dev/kvm or /dev/mshv
device is present on the host. Before starting ch domains, check if the
requested hypervisor device is present on the host.

Users can specify hypervisor in ch guests's domain definitions like
below:

<domain type='kvm'>

_or_

<domain type='hyperv'>

Signed-off-by: Praveen K Paladugu <prapal@linux.microsoft.com>
Signed-off-by: Praveen K Paladugu <praveenkpaladugu@gmail.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2024-03-08 13:01:00 +01:00
Praveen K Paladugu
b51b06eceb ch: Add support for Unix mode to serial port dev
With Unix mode, pass a socket path to cloud-hypervisor.
Cloud-Hypervisor will attach guest's serial port to this socket path.
Users can connect to the serial port using one of the following commands:

`socat -,crnl UNIX-CONNECT:<path/to/socket>`

OR

`minicom --device unix#<path/to/socket>`

Signed-off-by: Praveen K Paladugu <prapal@linux.microsoft.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2024-03-07 15:27:16 +01:00
Praveen K Paladugu
b2e43609fd ch: Add Cap checks for unix backend of serial port
Unix Socket backend is only supported for serial port in
cloud-hypervisor. Add relevant checks in chValidateDomainDeviceDef.

Signed-off-by: Praveen K Paladugu <prapal@linux.microsoft.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2024-03-07 15:27:12 +01:00
Peter Krempa
317ac911f6 qemu: command: Remove fallback '-usb' handling
Currently all machine types which do honour '-usb' are already covered
by code which will either select a proper controller model or would
select the same one which '-usb' would use.

Thus all of the legacy -usb controller code can be removed.

Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2024-03-06 16:30:37 +01:00
Peter Krempa
a07544c0d7 qemu: command: Don't downgrade to '-usb' for arm based machines
- 'virt*' machines already don't allow downgrade
 - 'versatilepb' and 'realview' machines use 'pci-ohci' controller with '-usb'
 - all other machines ignore '-usb' (some have sysbus-based USB
   controller which we don't even consider)

For the 'versatilepb' and 'realview' machines libvirt would already
resort to picking either an existing controller model or trying to pick
the one which '-usb' would select and thus fail either way.

All other machine types ignore it.

We can thus remove the fallback for all arm-based machines.

Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2024-03-06 16:30:37 +01:00
Peter Krempa
5b136eba6d qemu: command: Don't downgrade to '-usb' for ppc based machines
- 'pseries' machines already don't allow downgrade
 - 'g3beige' and 'mac99' machines use 'pci-ohci' controller with '-usb'
 - all other machines ignore '-usb'

For 'g3beige' and 'mac99' libvirt already has 'pci-ohci' as contoller it
would select as one of the options when picking a model, thus it's
impossible to reach situation when '-usb' would be honoured.

All other machine types ignore it.

We can thus remove the fallback for all ppc-based machines.

Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2024-03-06 16:30:36 +01:00
Peter Krempa
5e84c6c1ce qemu: command: Don't downgrade to '-usb' with 'pseries' machines
The default USB device auto-selection code for 'pseries' machines picks
controller models which are also selected when '-usb' is used thus it's
impossible to end up in the case when using '-usb' would be possible:

 $ qemu-system-ppc64 --machine pseries,usb=on
 qemu-system-ppc64: could not find a module for type 'nec-usb-xhci'
 $ qemu-system-ppc64 --machine pseries-2.5,usb=on
 qemu-system-ppc64: could not find a module for type 'pci-ohci'

Remove the impossible downgrade and adjust tests.

Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2024-03-06 16:30:36 +01:00
Peter Krempa
ae642084ce qemu: command: Don't downgrade to '-usb' for x86 based machines
- 'q35' machine type already explicitly forbids fallback
- 'isapc' never supported USB and '-usb' is ignored
- 'i440fx' does support '-usb' and translates it into 'piix3-uhci' which
  is identical to what libvirt selects
- we currently don't care about 'microvm'

Attempting to start an 'pc' (i440fx) machine with -usb when 'piix3-uhci'
is compiled out will fail and in any other case libvirt will use the
proper explicitly selected controller.

Drop the '-usb' downgrade for x86 arch.

Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2024-03-06 16:30:36 +01:00
Peter Krempa
b37096778b qemuDomainControllerDefPostParse: Use 'pci-ohci' as last-resort fallback USB controller
This controller is used as the default/implicit USB controller by
multiple machine types which honour the '-usb' flag of qemu. Add it as
fallback in libvirt too.

Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2024-03-06 16:30:36 +01:00
Peter Krempa
c6d71bf813 qemuDomainDefAddDefaultDevices: Populate default USB for 'versatilepb' and 'realview' ARM machines
The machine types historically have a default USB controller populated
via '-usb' which libvirt assumed implicitly. Qemu will use 'pci-ohci'
for both if '-usb' is used.

Unfortunately an USB controller instantiated via '-usb' is unusable as
the bus name libvirt generates doesn't reflect the real name qemu uses,
and thus no libvirt-defined USB devices can be put on the controller.

This patch will populate the default USB controller into the XML and
select it's model to 'pci-ohci' unconditionally as the machine would
fail to start with '-usb' if that controller model is not available.

This patch doesn't try to make any other assumptions about
auto-populated model of USB controllers, which means that for an
explicit USB controller without model a different model will be picked.

Note that this will likely cause ABI differences and break migration for
the two machine types, in the corner case when the default USB
controller would be populated, but given that both are obsolete board
types and USB was unusable it doesn't make sense to keep supporting this
specific case when '-usb' was formatted.

Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2024-03-06 16:30:36 +01:00
Peter Krempa
d885d39f10 qemuDomainControllerDefPostParse: Use proper enum value for default USB controller model
Assign VIR_DOMAIN_CONTROLLER_MODEL_USB_DEFAULT rather than -1.

Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2024-03-06 16:30:36 +01:00
Peter Krempa
1dd0744b29 qemuDomainDefAddDefaultDevices: Handle defaults for all ARM arches together
Most machine types are avaliable in all arches by qemu. This is also
true for the 'versatilepb' machine type example in the tests.

Move all the ARM architectures together so that they are handled in
sync.

Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2024-03-06 16:30:36 +01:00
Jiri Denemark
2ba73ca83b qemu: Optimize CPU check='partial' for usable CPUs
Ideally check='partial' would check exactly the features QEMU would want
to enable when asked for a specific CPU model (and features). But there
is no way we could ask QEMU how a specific CPU would look like. So we
use our definition from CPU map, which may slightly differ as QEMU adds
or removes features from CPU models, and thus we may end up checking
features which QEMU would not enable while missing some required ones.

We can do better in specific cases, though. If a CPU definition uses
only a model and disabled features (or none at all), we already know
whether QEMU can enable all features required by the CPU model as that's
what we use to set usable='yes' attribute in the list of available CPU
models in domain capbilities XML. So when a usable CPU model is
requested without asking for additional features (disabling features is
fine) we can avoid our possible inaccurate check using our CPU map.

For backward compatibility we only consider usable models. If a
specified model is not usable, we still check it the old way and even
let QEMU start it (and disable some features) in case our definition
lacks some features compared to QEMU.

Fixes: https://gitlab.com/libvirt/libvirt/-/issues/608
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
2024-03-05 16:04:28 +01:00
Jiri Denemark
ac120f1855 cpu: x86: Check for invalid CPU data from hypervisor
Recently a kernel bug caused QEMU to report a CPU feature as enabled
while listing it in the "unavailable-features" list of features that
were requested, but could not be enabled. The feature was actually
enabled, but we marked it as disabled when starting a domain. Later when
the domain is migrated, the destination requests the feature to be
disabled, which breaks the guest ABI or if we are lucky QEMU just fails
to load the migration stream.

Let's make similar bugs more visible in the future by refusing to even
start the domain.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
2024-03-05 16:00:19 +01:00
Andrea Bolognani
e4abb5f0fd qemu: Make firmware parsing failures non-fatal
At the moment, any kind of issue being detected in any of the
firmware descriptor files will result in the entire process
being aborted.

In particular, installing a build of edk2 for an architecture
that libvirt doesn't yet know about, for example loongarch64,
will break most firmware-related functionality: it will no
longer be possible to define new EFI VMs, start existing ones,
or even just obtain the domcapabilities for any architecture.

This is obviously unnecessarily harsh. Adopt a more relaxed
approach and simply ignore the firmware descriptors that we
are unable to parse correctly.

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

Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2024-03-04 14:36:39 +01:00
Andrea Bolognani
e0438b2e80 qemu: Rewrite qemuFirmwareFetchParsedConfigs()
Instead of returning the list of paths exactly as obtained
from qemuFirmwareFetchConfigs(), and allocating the list of
firmwares to be exactly that size right away, start with two
empty lists and add elements to them one by one.

At the moment this only makes things more verbose, but later
we're going to change things so that it's possible that some
of the paths/firmwares are not included in the lists returned
to the caller, and at that point the changes will pay off.

Note that we can't use g_auto() for the new list of paths,
because until the very last moment it's not null-terminated,
so g_strfreev() wouldn't be able to handle it correctly.

Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2024-03-04 14:36:37 +01:00
Andrea Bolognani
dcad670212 qemu: Add missing early returns
In a couple of cases, we were reporting an error without
actually terminating the parse process.

Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2024-03-04 14:36:26 +01:00
Martin Kletzander
c664015fe3 Fix off-by-one error in udevListInterfacesByStatus
Ever since this function was introduced in 2012 it could've tried
filling in an extra interface name.  That was made worse in 2019 when
the caller functions started accepting NULL arrays of size 0.

This is assigned CVE-2024-1441.

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reported-by: Alexander Kuznetsov <kuznetsovam@altlinux.org>
Fixes: 5a33366f5c0b18c93d161bd144f9f079de4ac8ca
Fixes: d6064e2759a24e0802f363e3a810dc5a7d7ebb15
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2024-03-01 11:52:27 +01:00
Boris Fiuczynski
6e36f26651 remote_protocol: Fix ACL on REMOTE_PROC_NODE_DEVICE_DEFINE_XML
Adding 'save' ACL to REMOTE_PROC_NODE_DEVICE_DEFINE_XML to make
REMOTE_PROC_NODE_DEVICE_UPDATE ACLs meaningful.

Fixes: 69f9e7dbc24657e85761f03574779540d0f18315
Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2024-02-29 12:09:08 +01:00
Boris Fiuczynski
d36ce2f252 nodedev: allow modify on define of a persistent node device
Allow to modify a node device by using virNodeDeviceDefineXML() to align
its behavior with other drivers define methods.

Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2024-02-26 11:15:27 +01:00
Boris Fiuczynski
582f27ff15 nodedev: Implement virNodeDeviceUpdate
Implement the API functions in the node device driver by using mdevctl
modify with the options defined and live.
Instead of increasing the minimum mdevctl version to 1.3.0 in the spec
file to ensure support exists in mdevctl the support is dynamically
checked before using mdevctl.

Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2024-02-26 11:09:57 +01:00
Boris Fiuczynski
69f9e7dbc2 api: add virNodeDeviceUpdate()
A public API method which allows to update or modify objects is
implemented for almost all other objects that have a concept of
persistent definition and activatability. Currently node devices of type
mdev can be persistent and active. This new method allows to update
defined and active node devices as well.

Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2024-02-26 11:03:51 +01:00
Boris Fiuczynski
e2c5c47439 nodedev: add persistent and transient filter on list
Allow to filter node devices based on their persistent or transient
states.

Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2024-02-26 11:00:47 +01:00
Boris Fiuczynski
e67bca23e4 nodedev: add an active config to mdev
The configuration of a defined mdev can be modified after the mdev is
started. The defined configuration and the active configuration can
therefore run out of sync. Handle this by storing the modifiable data
which is the mdev type and attributes in two separate active and
defined configurations. mdevctl supports with callout scripts to do an
attribute retrieval of started mdevs which is already implemented in
libvirt.

Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2024-02-26 10:59:47 +01:00
Boris Fiuczynski
c65c078655 node_device: remove unnecessary checks in virNodeDeviceDefFormat
virBufferEscapeString already contains the null check.

Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2024-02-26 10:55:55 +01:00
Boris Fiuczynski
c877908e14 node_device: refactor mdev attributes handling
Refactor attribute handling code into methods for easier reuse.

Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2024-02-26 10:55:17 +01:00
Boris Fiuczynski
47e57159b3 virmdev: prepare type and attributes for dual state
Create a new structure holding type and attributes as these are
modifiable in a persistent mdev configuration and run out of sync with
the active mdev configuration.

Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2024-02-26 10:50:43 +01:00
Vincent Vanlaer
93d67c58c2 daemon: fix wrong request count for sparse stream
Similar to when actual data is being written to the stream, it is
necessary to acknowledge handling of the client request when a hole is
encountered. This is done later in daemonStreamHandleWrite by sending a
fake zero-length reply if the status variable is set to
VIR_STREAM_CONTINUE. It seems that setting status from the message
header was missed for holes in the introduction of the sparse stream
feature.

Signed-off-by: Vincent Vanlaer <libvirt-e6954efa@volkihar.be>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2024-02-26 10:03:34 +01:00
Michal Privoznik
4545f313c2 domain_validate: Account for NVDIMM label size properly when checking for memory conflicts
As of v9.8.0-rc1~7 we check whether two <memory/> devices don't
overlap (since we allow setting where a <memory/> device should
be mapped to). We do this pretty straightforward, by comparing
start and end address of each <memory/> device combination.
But since only the start address is given (an exposed in the
XML), the end address is computed trivially as:

  start + mem->size * 1024

And for majority of memory device types this works. Except for
NVDIMMs. For them the <memory/> device consists of two separate
regions: 1) actual memory device, and 2) label.

Label is where NVDIMM stores some additional information like
namespaces partition and so on. But it's not mapped into the
guest the same way as actual memory device. In fact, mem->size is
a sum of both actual memory device and label sizes. And to make
things a bit worse, both sizes are subject to alignment (either
the alignsize value specified in XML, or system page size if not
specified in XML).

Therefore, to get the size of actual memory device we need to
take mem->size and substract label size rounded up to alignment.

If we don't do this we report there's an overlap between two
NVDIMMs even when in reality there's none.

Fixes: 3fd64fb0e236fc80ffa2cc977c0d471f11fc39bf
Fixes: 91f9a9fb4fc0d34ed8d7a869de3d9f87687c3618
Resolves: https://issues.redhat.com/browse/RHEL-4452?focusedId=23805174#comment-23805174
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
2024-02-22 10:53:56 +01:00
Adam Julis
969353f978 virfile: Switch to virReportSystemError after failed VIR_CLOSE()
VIR_CLOSE() sets errno on failure so it's better to use
virReportSystemError() than plain virReportError() as the former
reports errno value too.

Signed-off-by: Adam Julis <ajulis@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2024-02-22 10:23:20 +01:00
ray
04397de2a1 qemu: Fix guest-sync response time in qga command
The current implementation sets the guest-sync timeout to the
smaller value between the default value (QEMU_AGENT_WAIT_TIME)
and agent->timeout, without considering the timeout passed
via the qga command.

This patch enhances the guest-sync timeout logic to use the
minimum value among the default value, agent->timeout, and
the timeout passed via the qga command.

Resolves: https://gitlab.com/libvirt/libvirt/-/issues/590
Signed-off-by: ray <honglei.wang@smartx.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2024-02-22 09:51:23 +01:00
Peter Krempa
737e3daf5a qemuMigrationDstPrepareStorage: Annotate that existance of 'volume' disks is checked elswhere
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2024-02-21 14:15:49 +01:00