There are few places where we can replace explicit
VIR_FORCE_CLOSE() with VIR_AUTOCLOSE annotation.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Similarly to virshDomainFree add a wrapper for the snapshot object
freeing function.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Similarly to virshDomainFree add a wrapper for the snapshot object
freeing function.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Similarly to virshDomainFree add a wrapper for the snapshot object
freeing function.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Similarly to virshDomainFree add a wrapper for the snapshot object
freeing function.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Similarly to virshDomainFree add a wrapper for the snapshot object
freeing function.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Similarly to virshDomainFree add a wrapper for the snapshot object
freeing function.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Similarly to virshDomainFree add a wrapper for the snapshot object
freeing function.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Currently the order of virshXXXFree functions in the header file
does not correspond to the order in the corresponding .c file.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
In case when libvirt runs inside a restricted container it may
not have enough permissions to modify unpriv_sgio. However, it
may have been set beforehand by sysadmin or an orchestration
tool. Therefore, let's check whether the currently set value is
the one we want and if it is refrain from writing to the file.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2010306
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The --nvram and --keep-nvram options of the undefine command can
be used regardless of the domain status (the only consumer so far
- qemuDomainUndefineFlags() doesn't care about the domain
status). Yet, their corresponding help strings say something
about inactive domains while manpage says nothing. Remove the
reference to domain state.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2007659
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
The capability name piix4-acpi-root-hotplug-en is not conventional and
appreared to be confusing to some. "en" suffix is also incorrect as the
capability in qemu is used to both enable and disable hotplug on the pci root
bus on the i440fx. Hence, rename it to piix4.acpi-root-pci-hotplug so that it
is clearer, less confusing and more accurate.
Signed-off-by: Ani Sinha <ani@anisinha.ca>
Reviewed-by: Laine Stump <laine@redhat.com>
Also introduces a G_DEFINE_AUTOPTR_CLEANUP_FUNC for virCHMonitor.
Signed-off-by: William Douglas <william.douglas@intel.com>
Reviewed-by: Laine Stump <laine@redhat.com>
It is already being unrefed in virCHMonitorDispose().
Signed-off-by: William Douglas <william.douglas@intel.com>
Reviewed-by: Laine Stump <laine@redhat.com>
In virCHMontiorNew the monitor object was referenced an additional
time incorrectly preventing it from being disposed of, and wasn't
always closed properly on failure.
Signed-off-by: William Douglas <william.douglas@intel.com>
Reviewed-by: Laine Stump <laine@redhat.com>
In virCHMonitorBuildKernelRelatedJson there are two cases of json
value objects being lost after the pointer being redefined. This
change removes the needless redefinition.
Signed-off-by: William Douglas <william.douglas@intel.com>
Reviewed-by: Laine Stump <laine@redhat.com>
The indentation of the first item under the categoty "new features" for the
future release v7.9.0 is not right. Fix it.
Signed-off-by: Ani Sinha <ani@anisinha.ca>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
This patch makes the descriptions of virStoragePoolCreateFlags annotate to the
correct flag in the generated HTML file.
Signed-off-by: Robin Lee <cheeselee@fedoraproject.org>
Currently translated at 23.0% (2387 of 10374 strings)
Translation: libvirt/libvirt
Translate-URL: https://translate.fedoraproject.org/projects/libvirt/libvirt/fi/
Co-authored-by: Jan Kuparinen <copper_fin@hotmail.com>
Signed-off-by: Jan Kuparinen <copper_fin@hotmail.com>
A new 'target' subelement of the pci-root controller has been
introduced having a 'hotplug' property. This property can be used to
turn off or turn on the ability to hotplug/unplug devices to the slots
of the pci-root.
The new element can be used like this:
<controller type='pci' model='pci-root'>
<target hotplug='off'/>
</controller>
This will turn off hotplug capability on the pci-root ports. To turn
the capability on, we set hotplug='on' above (which is also the
default).
Signed-off-by: Ani Sinha <ani@anisinha.ca>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Laine Stump <laine@redhat.com>
This change adds qemu backend command line support for enabling or disabling
hotplug on the pci-root controller using the 'target' sub-element of the
pci-root controller as shown below:
<controller type='pci' model='pci-root'>
<target hotplug='off'/>
</controller>
'<target hotplug='off/on'/>' is only valid for pc (i440fx-based x86)
machinetypes and turns on the following command line option that is passed
to qemu for x86 guests:
-global PIIX4_PM.acpi-root-pci-hotplug=<off/on>
Before introduction of this attribute, hotplug was always enabled for
pci-root of an i440fx-based machinetype, and since its introduction
the default setting has always been "on" for those machinetypes.
This change also adds the required qemuxml2argv unit tests in order to test
correct qemu arguments. Unit tests have also been added to test qemu capability
validation checks.
Signed-off-by: Ani Sinha <ani@anisinha.ca>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Laine Stump <laine@redhat.com>
This change introduces libvirt xml support to enable/disable hotplug on the
pci-root controller. It adds a 'target' subelement for the pci-root controller
with a 'hotplug' property. This property can be used to enable or disable
hotplug for the pci-root controller. For example, in order to disable hotplug
on the pci-root controller, one has to use set '<target hotplug='off'>' as
shown below:
<controller type='pci' model='pci-root'>
<target hotplug='off'/>
</controller>
'<target hotplug='on'>' option would enable hotplug for pci-root controller.
This is also the default value. This option is only available for pc machine
types and is applicable for qemu/kvm accelerator only.This feature was
introduced from qemu version 5.2 with the following change in qemu repository:
3d7e78aa7777f ("Introduce a new flag for i440fx to disable PCI hotplug on the root bus")
The above qemu commit describes some reasons why users might to disable hotplug
on PCI root buses.
Related unit tests to exercise the new conf option has also been added.
Signed-off-by: Ani Sinha <ani@anisinha.ca>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Laine Stump <laine@redhat.com>
The following change in qemu added support for a global boolean flag specific
to i440fx machines that would turn off or on acpi based hotplug for pci root
bus:
3d7e78aa7777f ("Introduce a new flag for i440fx to disable PCI hotplug on the root bus")
The option is passed as "-global PIIX4_PM.acpi-root-pci-hotplug=on" etc in qemu
commandline. It is enabled by default. This patch adds the corresponding qemu
capabilities in libvirt as QEMU_CAPS_PIIX_ACPI_ROOT_PCI_HOTPLUG.
Please note that the test specific qemu capabilities .replies files has already
been updated as a part of regular refreshing them when a new qemu version is
released. Hence, no updates to those files are required.
Signed-off-by: Ani Sinha <ani@anisinha.ca>
Reviewed-by: Laine Stump <laine@redhat.com>
This commit adds new memorydevices.rst page which should serve
all models of memory devices. Yet, I'm documenting virtio-mem
quirks only.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
New 'update-memory-device' command is introduced which aims on
making it user friendly to change <memory/> device. So far I just
need to change <requested/> so I'm introducing --requested-size
only; but the idea is that this is extensible for other cases
too. For instance, want to change <myElement/>? A new
--my-element argument can be easily introduced.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The qemuDomainSetMemoryFlags() allows for memballoon
(<currentMemory/>) changes for both active and inactive guests.
And just before doing any change, we have to make sure that the
new size is not greater than the total memory (<memory/>).
However, the total memory includes not only the regular guest
memory, but also sum of maximum sizes of all virtio-mems (in fact
all memory devices for that matter). But virtio-mem devices are
modified differently (via virDomainUpdateDevice()) and thus the
upper limit for new balloon size has to be lowered.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reporting how much memory is exposed to the guest happens under
<currentMemory/> which is taken from def->mem.cur_balloon. The
reported amount should account for both balloon size and the sum
of @currentsize of all virtio-mems. For instance, if domain has
4GiB via balloon and additional 2GiB via virtio-mem, then the
domain XML should report 6GiB. The same applies for domain
statistics.
The way to achieve this is to account for either balloon or
virtio-mem when the size of the other is changed, e.g. on balloon
change we have to add all @currentsize (for non virtio-mem these
will be zero, so the check for memory model is needless, but
makes it more obvious what's happening), and vice versa.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
If the QEMU driver restarts it loses the track of the current size
of virtio-mem (because it's runtime type of information and thus
not stored in XML) and therefore, we have to refresh it when
reconnecting to the domain monitor.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
As advertised in previous commit, this event is delivered to us
when virtio-mem module changes the allocation inside the guest.
It comes with one attribute - size - which holds the new size of
the virtio-mem (well, allocated size), in bytes.
Mind you, this is not necessarily the same number as 'requested
size'. It almost certainly will be when sizing the memory up, but
it might not be when sizing the memory down - the guest kernel
might be unable to free some blocks.
This current size is reported in the domain XML as an output
element only.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This function will be needed in the next commit where we will
want to find virtio-mem given its alias by QEMU on the monitor.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The virtio-mem has another property that isn't exposed yet:
current size exposed to the guest. Please note, that this is
different to <requested/> because esp. on sizing the memory
down guest may refuse to release some blocks. Therefore, let's
have another size to report in the XML. But because of its
nature, the <current/> won't be parsed and is report only (for
live XMLs).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Updating offline XML of <memory/> devices might come handy when
dealing with virtio-mem devices. But it's implemented to just
replace one virDomainMemoryDef with another so it can be used to
change almost anything.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
As advertised in one of previous commits, we want to be able to
change 'requested-size' attribute of virtio-mem on the fly. This
commit does exactly that. Changing anything else is checked for
and forbidden.
Once guest has changed the allocation, QEMU emits an event which
we will use to track the allocation. In the next commit.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Nothing special is happening here. All important changes were
done when for 'virtio-pmem' (adjusting the code to put virtio
memory on PCI bus, generating alias using
qemuDomainDeviceAliasIndex(). The only bit that might look
suspicious is no prealloc for virtio-mem. But if you think about
it, the whole purpose of this device is to change amount of
memory exposed to guest on the fly. There is no point in locking
the whole backend in memory.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The virtio-mem is paravirtualized mechanism of adding/removing
memory to/from a VM. A virtio-mem-pci device is split into blocks
of equal size which are then exposed (all or only a requested
portion of them) to the guest kernel to use as regular memory.
Therefore, the device has two important attributes:
1) block-size, which defines the size of a block
2) requested-size, which defines how much memory (in bytes)
is the device requested to expose to the guest.
The 'block-size' is configured on command line and immutable
throughout device's lifetime. The 'requested-size' can be set on
the command line too, but also is adjustable via monitor. In
fact, that is how management software places its requests to
change the memory allocation. If it wants to give more memory to
the guest it changes 'requested-size' to a bigger value, and if it
wants to shrink guest memory it changes the 'requested-size' to a
smaller value. Note, value of zero means that guest should
release all memory offered by the device. Of course, guest has to
cooperate. Therefore, there is a third attribute 'size' which is
read only and reflects how much memory the guest still has. This
can be different to 'requested-size', obviously. Because of name
clash, I've named it 'current' and it is dealt with in future
commits (it is a runtime information anyway).
In the backend, memory for virtio-mem is backed by usual objects:
memory-backend-{ram,file,memfd} and their size puts the cap on
the amount of memory that a virtio-mem device can offer to a
guest. But we are already able to express this info using <size/>
under <target/>.
Therefore, we need only two more elements to cover 'block-size'
and 'requested-size' attributes. This is the XML I've came up
with:
<memory model='virtio-mem'>
<source>
<nodemask>1-3</nodemask>
<pagesize unit='KiB'>2048</pagesize>
</source>
<target>
<size unit='KiB'>2097152</size>
<node>0</node>
<block unit='KiB'>2048</block>
<requested unit='KiB'>1048576</requested>
</target>
<address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
</memory>
I hope by now it is obvious that:
1) 'requested-size' must be an integer multiple of
'block-size', and
2) virtio-mem-pci device goes onto PCI bus and thus needs PCI
address.
Then there is a limitation that the minimal 'block-size' is
transparent huge page size (I'll leave this without explanation).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This capability tracks whether memory-backend-* supports .reserve
attribute which is going to be important for backends associated
with virtio-mem devices.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This commit introduces a new capability that reflects virtio-mem-pci
device support in QEMU:
QEMU_CAPS_DEVICE_VIRTIO_MEM_PCI, /* -device virtio-mem-pci */
The virtio-mem-pci device was introduced in QEMU 5.1.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
New virHostMemGetTHPSize() is introduced which allows caller to
obtain THP PMD (Page Middle Directory) size, which is equal to
the minimal size that THP can use, taken from kernel doc
(Documentation/admin-guide/mm/transhuge.rst):
Some userspace (such as a test program, or an optimized memory allocation
library) may want to know the size (in bytes) of a transparent hugepage::
cat /sys/kernel/mm/transparent_hugepage/hpage_pmd_size
Since this size depends on the host architecture and the kernel
it won't change whilst libvirtd is running. Therefore, we can use
virOnce() and cache the value. Of course, we can be running under
kernel that has THP disabled or has no notion of THP at all. In
that case a negative value is returned to signal error.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
There are two variables that are used only in a single
loop. Move their definitions into their respective blocks.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
When parsing CPU topology, which is described in <topology/>
attributes we can use virXMLPropUInt() instead of virXPathUInt()
as the former results in shorter code.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
There is no need to use virXPathULong() and a temporary UL
variable if we can use virXPathUInt() directly.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
