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>
For conversion of '-device' we'll try to avoid usage of arrays if
possible, so for now if the array coversion function is not provided the
convertor will error out.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
With automatic memory freeing we can simplify the function to avoid two
almost-identical calls to virQEMUBuildCommandLineJSONRecurse.
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 same test in regards to the 'panic' device is the 'panic-double'
case, thus panic-isa can be removed.
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>
The returned argument list is a NULL-terminated string list and the only
caller doesn't use the count. Remove the argument.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Prevent duplication of code when extending the validator for new
commands. Add a struct describing a command to validate and make the
validation loop a bit more robust to corner cases.
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>
Now that everything was replaced by the new code we can remove this
function.
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>
Base the validation on presence of JSON as we do with other validated
commands. This will prepare the code for a refactor so that it's the
same for all validated commands.
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>
Enforce that the ':' separator between the key and value is always
present.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In many cases we use a signed value, but use the sign to note that it
was not assigned. For converting to JSON objects it will be handy to
have possibility to do this automatically.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Commit 58ba0f6a3d 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>
