Remove the now unused boot-index related attributes and the code which
is assigning it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Fill in the effective boot index for network devices (or hostdev-backed
network devices via 'qemuProcessPrepareDeviceBootorder'. This patch
doesn't clean up the cruft to make it more obvious what's happening.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Rename it to 'qemuProcessPrepareDeviceBootorder' and call it from
'qemuProcessPrepareDomain' rather than
'qemuProcessPrepareDomainStorage'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
'effectiveBootIndex' is a copy of 'bootIndex' if '<boot order=' was
present and left unassigned if not. This allows hypervisor drivers to
reinterpret <os><boot> without being visible in the XML.
QEMU driver had a internal implementation for disks, which is now
replaced. Additionally this will simplify a refactor of network boot
assignment.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
'virtio-vga' is a virtio device but we didn't use the virtio formatter
for it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Merge the code from qemuBuildVirtioOptionsStr so that we don't have to
call two separate functions.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The code doesn't need the name as it determines it internally. Remove
the argument and fix all callers. In certain cases it led to
simplification of the logic.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Since we already have code for per-device behaviour we can also populate
the device name and extract virtioOptions in the switch statement so
that callers don't have to pass it in.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add the bus suffix in a separate call. This will make it more obvious
what's happening in the next commit.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The function is static and will be needed in the virtio device config
helper.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The 'virtio' argument was misleadingly implying that it's true for all
virtio devices, but that's not the case. 'virtio-vga(-gl)' is a virtio
device but doesn't accept the usual bus-dependant suffix.
Add a comment for 'qemuDeviceVideoGetModel' and another boolean
'virtioBusSuffix' which carries the above meaning so that the 'virtio'
argument can be fixed (it will be used later).
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Split out the function a bit more to separate the per-device code.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Extract the code into 'qemuBuildVirtioDevGetConfig' so that we can
later reuse it when converting individual device code into the more
modern JSON approach as the extracted code will be necessary either way.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
To simplify upcoming refactors change the logic such that we don't
return early for device types which can't be transitional.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Upcoming patches will start converting the formatting of arguments for
-device from a string to JSON so that we can keep proper types around
when using it via QMP.
This means we will need an equivalet for the device address builder
function. 'qemuBuildDeviceAddressProps' provides equal functionality,
but the output differs for fields where a number is expected, where
we've previously formatted a hex value but now end up with a decimal
value per JSON standard.
For given address types I've selected an example device and used
'-device $DEV,help' to obtain the current types recognized by qemu:
Note that 'bus' is not shown below, but it's already a string so we can
keep using it as a string.
VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI (virtio-balloon-pci)
acpi-index=<uint32> - (default: 0)
addr=<int32> - Slot and optional function number, example: 06.0 or 06 (default: -1)
multifunction=<bool> - on/off (default: false)
Note that 'addr' is here defined as 'int32' but in fact internally in
qemu is an alternate type between a number and a string so we can keep
using strings here.
VIR_DOMAIN_DEVICE_ADDRESS_TYPE_USB (usb-tablet)
port=<str>
VIR_DOMAIN_DEVICE_ADDRESS_TYPE_SPAPRVIO (spapr-vty)
reg=<uint32> - (default: 4294967295)
VIR_DOMAIN_DEVICE_ADDRESS_TYPE_CCW (virtio-blk-cww)
devno=<str> - Identifier of an I/O device in the channel subsystem, example: fe.1.23ab
VIR_DOMAIN_DEVICE_ADDRESS_TYPE_ISA (isa-serial)
iobase=<uint32> - (default: 4294967295)
irq=<uint32> - (default: 4294967295)
VIR_DOMAIN_DEVICE_ADDRESS_TYPE_DIMM (pc-dimm)
slot=<int32> - (default: -1)
addr=<uint64> - (default: 0)
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Split up the bus lookup into a function called
'qemuBuildDeviceAddressPCIGetBus'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Per coding guidelines error messages [1] should not be broken into
lines and variables should be separated by apostrophes.
[1] https://libvirt.org/coding-style.html#error-message-format
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The PCI address case grew massive over time. Split it out into a new
function qemuBuildDeviceAddressPCIStr.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Mention the QMP command 'device_add' rather than 'qemuMonitorAddDevice'
and remove the weird formatting.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use automatic memory freeing and remove 'ret' variable and 'cleanup'
label.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We commonly use 'props' for the JSON object describing something. Rename
the monitor device addition code.
Additionally the common approach is to clear the pointer if it was
consumed so the arguments are adjusted to do so.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use g_autoptr for 'vcpuprops' and remove the 'cleanup' label and 'ret'
varlaible which is no longer needed.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Report the error from 'qemuValidateDomainWatchdogDef' rather than
'qemuBuildWatchdogDevStr'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The flag will be used to switch use of JSON arguments for -device once
qemu will support it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The flag will be used to switch use of JSON arguments for -chardev once
qemu will support it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Optimize the number of string copies by using the virBuffers in the
callers directly. Simplest way to achieve this is to just open code the
one function call 'virQEMUBuildDriveCommandlineFromJSON' was wrapping
in the two callers.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The -netdev formatter code switched to a real virQEMUCaps flag so we can
remove the old flags which used to enable JSON for -netdev for
validation purposes.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Base the JSON output on a regular capability flag rather than purely
internal flag. This will prepare for the time when QEMU will accept JSON
argumets for -netdev.
For now the capability is not set (thus we for now don't have QMP
schema validation) but that will be addressed later.
To achieve this 'qemuBuildNetdevCommandlineFromJSON' is introduced
and all callers of 'virQEMUBuildNetdevCommandlineFromJSON' are
refactored to use the new helper.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We validate the generated props against the QMP schema which makes sure
that the objects are generated properly.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Introduce a capability that will be asserted once '-netdev' will accept
JSON. For now it will be dormant (only used by tests).
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Unify it with the upcoming capabilities for -netdev and -device.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
All callers basically end up dumping the buffer into a string and then
adding '-object' 'props' arguments to virCommand. Simplify all callers
by doing this in the function itself.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Input devices of VIR_DOMAIN_INPUT_TYPE_EVDEV type are instantiated via
an '-object' rather than a '-device'. Mixing them in one function is a
bad idea as the caller then needs to use the string correctly which is
not the case in 'qemuDomainAttachInputDevice'.
Generate a JSON object for '-object' explicitly.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Rename the function to 'qemuBuildMemoryCellBackendProps' and return the
properties before conversion to commandline arguments. This requires
changes in the caller.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Commit 58ba0f6a3d7342fba29edbbf2bb9cb5497c870e5 added a capability which
is supported by all qemu versions we support. Remove it and the
associated dead code. Since the capability isn't present in any upstream
release we can delete it completely.
Specifically the commit itself states that it was introduced "around
(qemu) 2.1". The rest of the code handles properly that the feature is
used only on x86 with the i440fx machine so the capability is pointless.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The error that "acpi-bridge-hotplug" is not supported would be triggered
only if both the ICH9 and PIIX don't support the capability and the
machine is q35. This makes no sense.
We want to check that the appropriate platform supports the appropriate
feature.
Fixes: 7300ccc9b3e
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This change adds backend qemu command line support for new libvirt
global feature 'acpi-bridge-hotplug'. This option can be used as
following:
<feature>
<pci>
<acpi-bridge-hotplug state='off|on'/>
</pci>
</feature>
The '<pci>' sub-element under '<feature>' is also newly introduced.
'acpi-bridge-hotplug' turns on the following command line option to
qemu for x86 guests:
(pc): -global PIIX4_PM.acpi-pci-hotplug-with-bridge-support=<off|on>
(q35): -global ICH9-LPC.acpi-pci-hotplug-with-bridge-support=<off|on>
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 as well as checks for using this
option with the right architecture.
Signed-off-by: Ani Sinha <ani@anisinha.ca>
Reviewed-by: Laine Stump <laine@redhat.com>
This change introduces a new libvirt sub-element <pci> under
<features> that can be used to configure all pci related features.
Currently the only sub-sub element supported by this sub-element is
'acpi-bridge-hotplug' as shown below:
<features>
<pci>
<acpi-bridge-hotplug state='on|off'/>
</pci>
</features>
The above option is only available for the QEMU driver, for x86 guests
only. It is a global option, affecting all PCI bridge controllers on
the guest.
The 'acpi-bridge-hotplug' option enables or disables ACPI hotplug
support for cold-plugged pci bridges. Examples of bridges include the
PCI-PCI bridge (pci-bridge controller) for pc (i440fx) machinetypes,
or PCIe-PCI bridges and pcie-root-port controllers for q35
machinetypes.
For pc machinetypes in x86, this option has been available in QEMU
since version 2.1. Please see the following changes in qemu repo:
9e047b982452c6 ("piix4: add acpi pci hotplug support")
133a2da488062e ("pc: acpi: generate AML only for PCI0 devices if PCI
bridge hotplug is disabled")
For q35 machinetypes, this was introduced in QEMU 6.1 with the
following changes in qemu repo:
(a) c0e427d6eb5fef ("hw/acpi/ich9: Enable ACPI PCI hot-plug")
(b) 17858a16950860 ("hw/acpi/ich9: Set ACPI PCI hot-plug as default on
Q35")
The reasons for enabling ACPI based hotplug for PCIe (q35) based
machines (as opposed to native hotplug) are outlined in (b). There are
use cases where users would still want to use native
hotplug. Therefore, this config option enables users to choose either
ACPI based hotplug or native hotplug for bridges (for example for pcie
root port controller in q35 machines).
Qemu capability validation checks have also been added along with
related unit tests to exercise the new conf option.
Signed-off-by: Ani Sinha <ani@anisinha.ca>
Reviewed-by: Laine Stump <laine@redhat.com>
qemu added support for i440fx specific global boolean flag
PIIX4_PM.acpi-pci-hotplug-with-bridge-support
around version 2.1. This flag is enabled by default. When disabled, it
turns off acpi pci hotplug for cold plugged pci bridges in i440fx
machine types.
Very recently, in qemu version 6.1, the same global option was also
added for q35 machine types as well.
ICH9-LPC.acpi-pci-hotplug-with-bridge-support
This option turns on or off acpi based hotplug for cold plugged pcie
bridges like pcie root ports. This flag is also enabled by
default. Please refer to the following qemu changes:
c0e427d6eb5fef ("hw/acpi/ich9: Enable ACPI PCI hot-plug")
17858a16950860 ("hw/acpi/ich9: Set ACPI PCI hot-plug as default on Q35")
This patch adds the corresponding qemu capabilities in libvirt. For
i440fx, the capability is detected as
QEMU_CAPS_PIIX_ACPI_HOTPLUG_BRIDGE. For q35, the capability is
detected as QEMU_CAPS_ICH9_ACPI_HOTPLUG_BRIDGE.
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>
Other devices (includes 9p-based fsdev) call this wrapper
before formatting the device.
Add it here too.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
This reverts commit 801e6da29c0202946d44b42136cc4ee229932a29
They are not needed anymore.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reconstruct the socket path from priv->libDir in every user.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Intended as a replacement for qemuVirtioFSCreateSocketFilename,
to be used outside of qemu_virtiofs.c
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The commit adding the vhost-user-fs device forgot to format
the device's alias on the command line.
Thankfully it was not needed yet because virtiofs migration
is not yet supported, but it will be needed in the future
to allow hot(un)plug.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
