Memory slots are required only for DIMM-like devices, but the maximum
memory address space is relevant also for other non-DIMM memory devices
such as virtio-mem. Allow configurations where no slots are added.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This is fairly trivial. Just set .memaddr attribute if a value
was set in the XML.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2180679
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
These are allegedly necessary to keep the output consistent,
but now that we're using a privileged config for the driver we
get the desired behavior out of the box, and as a bonus the
paths match what you would actually see on a regular host.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
QEMU deprecated the '-no-acpi' option, thus we should switch to the
modern way to use '-machine'.
Certain ARM machine types don't support ACPI. Given our historically
broken design of using '<acpi/>' without attribute to enable ACPI and
qemu's default of enabling it without '-no-acpi' such configurations
would not work.
Now when qemu reports whether given machine type supports ACPI we can do
a better decision and un-break those configs. Unfortunately not
retroactively.
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/297
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Currently, memory device (def->mems) part of cmd line is
generated before any controller. In majority of cases it doesn't
matter because neither of memory devices live on a bus that's
created by an exposed controller (e.g. there's no DIMM
controller, at least not exposed). Except for virtio-mem and
virtio-pmem, which do have a PCI address. And if it so happens
that the device goes onto non-default bus (pci.0) starting such
guest fails, because the controller that creates the desired bus
wasn't processed yet. QEMU processes arguments in order.
For instance, if virtio-mem has address with bus='0x01' QEMU
refuses to start with the following message:
Bus 'pci.1' not found
Similarly for virtio-pmem. I've successfully tested migration and
changing the order does not affect migration stream.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2047271
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Now that qemu fixed device unplug when JSON syntax is used with -device
we can re-enable the feature.
Since the old capability string representation is condemned by
suggesting filtering it as a workaround we must introduce a new string.
To achieve this the original capability position is renamed to
X_QEMU_CAPS_DEVICE_JSON_BROKEN_HOTPLUG and a new position with the
original name QEMU_CAPS_DEVICE_JSON is introduced to prevent us having
to change the rest of the code.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When -device is configured via JSON a bug [1] is triggered in qemu were
the DEVICE_DELETED event for the removal of the device frontend is no
longer delivered to libvirt. Without the DEVICE_DELETED event we don't
remove the corresponding entries in the VM XML.
Until qemu will be fixed we must stop using the JSON syntax for -device.
This patch removes the detection of the capability. The capability is
used only during startup of a fresh VM so we don't need to consider any
compaitibility steps for existing VMs.
For users who wish to use 'libvirt-7.9' and 'libvirt-7.10' with
'qemu-6.2' there are two possible workarounds:
- filter out the 'device.json' qemu capability '/etc/libvirt/qemu.conf':
capability_filters = [ "device.json" ]
- filter out the 'device.json' qemu capability via qemu namespace XML:
<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
[...]
<qemu:capabilities>
<qemu:del capability='device.json'/>
</qemu:capabilities>
</domain>
We must never again use the same capability name as we are now
instructing users to filter it as a workaround so once qemu is fixed
we'll need to pick a new capability value for it.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=2036669
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2035237
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ani Sinha <ani@anisinha.ca>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Upcoming patches will modify how we populate the capability cache in
tests to be more saner. This also means that the emulator binary and
architecture used in the test files using real capabilities must match
what the real capabilities have.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We currently use -machine accel=XXX which is just a syntax sugar
for -accel XXX. The former doesn't allow specifying arguments for
accelerator, because all arguments passed to -machine are
treated as arguments of machine itself.
The -accel argument was introduced in QEMU commit
v2.9.0-rc0~70^2~19 and since our minimum required version is
newer (2.11.0) we can safely assume its existence and use it
without any capability.
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/233
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Tested-by: Kashyap Chamarthy <kchamart@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
'-audiodev' as a modern implementation based on QAPI already takes JSON
as the argument. Convert our code to use it directly.
The declaration of the QAPI types can be found in
'qemu.git/qapi/audio.json'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Starting with QEMU-6.2 started accepting a JSON object as argument for
'-device' which will also become the only syntax considered stable by
qemu in the future.
Since libvirt was recently converted to generate the properties via JSON
to begin wit we can start using it on the commandline as well, by simply
enabling the QEMU_CAPS_DEVICE_JSON capability, which we do by probing
for the 'json-cli' feature flag of 'device_add'.
Normally a change which changes a commandline output should be happening
only after the impacted real-caps test files are forked in the version
preceding the change, but in this case it's not necessary as the logic
for generating the device properties stays identical and we just change
the output format (avoid conversion). Additionally we still have a lot
of tests validating the conversion to the old commandline options.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
virCommandToString has the possibility to return an already wrapped
string with better format than what we get from the test wrapper script.
The main advantage is that arguments for an option are always on the
same line which makes it more easy to see what changed in a diff and
prevents re-wrapping of the line if a wrapping point moves over the
threshold.
Additionally the used output is the same we have in the VM log file when
a VM is starting.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Base the detection on the presence of the 'secret' qom-type entry, which
isn't conditionally compiled in qemu.
All caps-based test now switch to using JSON for -object.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The -audiodev argument is replacing the QEMU_AUDIO_DRV env variable (and
its relations).
Sadly we still have to use the SDL_AUDIODRIVER env variable because that
wasn't mapped into QAPI schema.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
QEMU has long accepted many different values for boolean properties, but
set accepted has been different depending on which QEMU parser you hit.
The on|off values were supported by all QEMU parsers. The yes|no, y|n,
true|false values were only partially supported:
https://lists.gnu.org/archive/html/qemu-devel/2020-11/msg01012.html
Thus we should standardize on on|off everywhere since that is most
widely supported in QEMU.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The preferred syntax for boolean options is to set the value "on" or
"off". QEMU 7.1.0 will deprecate the short format we currently use.
The long format has been supported with -chardev since at least 1.5.3,
so we don't need to check for it.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Now we have everything prepared for generating the command line.
The device alias prefix was chosen to be 'virtiopmem'.
Since virtio-pmem-pci device goes onto PCI bus generating device
alias must have been changed slightly because
qemuAssignDeviceMemoryAlias() might have used DIMM slot number to
generate the alias. This obviously won't work and thus the "old"
way (which includes qemuDomainDeviceAliasIndex()) must be used.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1735375
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
