QEMU switched from using underscores in x86 CPU features to hyphens
in the 2.8.0 series with two commits
commit fc7dfd205f3287893c436d932a167bffa30579c8 (HEAD, refs/bisect/bad)
Author: Eduardo Habkost <ehabkost@redhat.com>
Date: Fri Sep 30 15:49:40 2016 -0300
target-i386: Remove underscores from feat_names arrays
commit 54b8dc7c19cd781e96f1e9b001ca6001d804eb19
Author: Eduardo Habkost <ehabkost@redhat.com>
Date: Fri Sep 30 15:49:38 2016 -0300
target-i386: Register aliases for feature names with underscores
Libvirt names use underscores so we conditionally tranlate the
names when talking to new QEMU. Since the min QEMU was raised to
version 2.11.0, all QEMU versions we talk to expect hypens, so
the translation can be done unconditionally.
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
QEMU switched from using underscores in x86 CPU features to hyphens
in the 2.8.0 series with two commits
commit fc7dfd205f3287893c436d932a167bffa30579c8 (HEAD, refs/bisect/bad)
Author: Eduardo Habkost <ehabkost@redhat.com>
Date: Fri Sep 30 15:49:40 2016 -0300
target-i386: Remove underscores from feat_names arrays
commit 54b8dc7c19cd781e96f1e9b001ca6001d804eb19
Author: Eduardo Habkost <ehabkost@redhat.com>
Date: Fri Sep 30 15:49:38 2016 -0300
target-i386: Register aliases for feature names with underscores
Libvirt names use underscores so we conditionally tranlate the
names when talking to new QEMU. Since the min QEMU was raised to
version 2.11.0, all QEMU versions we talk to expect hypens, so
the translation can be done unconditionally.
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
All (proper) callers pass true so we can remove the argument.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Now that we use JSON with -device we can validate it at least partially
(since the schema for 'device_add' is for now incomplete) against the
QMP schema.
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>
Use the 'allowIncomplete' argument of testQEMUSchemaValidateCommand to
validate at least properties which are already described by the schema.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The QMP schema for 'device_add' is not complete yet. Allow validation of
incomplete schema so that we can enable at least some validation. Once
there's more schema in the future all present members are still
validated.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Update to v6.1.0-1510-gc148a05721 which most notably adds the 'json-cli'
feature for 'device_add' QMP command meaning that -device accepts JSON.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Our general pattern is to initialize @ret to -1 and set it to 0
only at the end of a function. Some functions in
objecteventtest.c do not follow this pattern.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
The sole purpose of the lifecycleEventCounter_reset() function is
to zero out given lifecycleEventCounter struct. Well, we can let
the compiler zero it out when declaring a variable and just
remove the function.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
query-dirty-rate command is used for virsh domstats by default, but this
is available only on qemu >=5.2.0.
In this commit, add capability flag for query-dirty-rate first.
Signed-off-by: Hiroki Narukawa <hnarukaw@yahoo-corp.jp>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The aim of virNetSocketNewConnectCommand() is to execute passed
command and attach socket pair/pipe to it so that client socket
can be opened (this is used for connections with alternative
transports, e.g. ssh). The virCommand is created in a caller and
then passed to virNetSocketNewConnectCommand() where it is freed
using virCommandFree(). This approach is wrong on two levels:
1) The deallocation happens on a different level than allocation,
2) There's a WIN32 stub that just reports an error and doesn't
free the command.
However, with g_autoptr() trickery the command can be freed in
caller.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The capability reflects whether QEMU is capable of -device
virtio-*,ats=. Since the property was introduced in QEMU commit
v2.9.0-rc0~162^2~32 we can safely assume the property is always
present as the minimal version required is 2.11.0.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
There are some tests cases in qemuxml2argvtest that aim to check
whether our validator rejects <driver ats=''/> when
QEMU_CAPS_VIRTIO_PCI_ATS capability is not present. Well, such
scenario can't happen really because the capability will always
be present.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The capability reflects whether QEMU is capable of -device
virtio-*,iommu_platform=. Since the property was introduced in
QEMU commit v2.9.0-rc0~162^2~37 we can safely assume the property
is always present as the minimal version required is 2.11.0.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
There are some tests cases in qemuxml2argvtest that aim to check
whether our validator rejects <driver iommu=''/> when
QEMU_CAPS_VIRTIO_PCI_IOMMU_PLATFORM capability is not present.
Well, such scenario can't happen really because the capability
will always be present.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
There are a few files containing expected output for test cases
that no longer exist. Remove them.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The data is based on commit v6.1.0-1313-gc09124dcb8
Notable changes:
- New machine types for the 6.2 cycle were added
- MEM_UNPLUG_ERROR event was deprecated and replaced by
DEVICE_UNPLUG_GUEST_ERROR
- Intel SGX related commands and devices added
- 'copy-before-write' blockdev filter was added
- 'memory-backend-epc' was added
- new cpu flags
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
We control only the 'tpmdev' property of TPM devices which is a string.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We control the following properties of the devices in question:
'virtio-gpu'
virgl=<bool> - on/off (default: true)
'qxl'
ram_size=<uint32> - (default: 67108864)
vram_size=<uint64> - (default: 67108864)
vram64_size_mb=<uint32> - (default: 4294967295)
vgamem_mb=<uint32> - (default: 16)
max_outputs=<uint16> - (default: 0)
'vhost-user-gpu'
max_outputs=<uint32> - (default: 1)
chardev=<string>
'VGA'
vgamem_mb=<uint32> - (default: 16)
'bochs-display'
vgamem=<size> - (default: 16777216)
common for all devices:
xres=<uint32> - (default: 0)
yres=<uint32> - (default: 0)
The only noticable change is using memory size in bytes for
'bochs-display' instead of kibibytes.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Remove the old-style 'device_add' helpers which parse the commandline
arguments to JSON since we now coverted all usage to use JSON directly.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Build commandlines for character devices via JSON.
For devices using 'VIR_DOMAIN_DEVICE_ADDRESS_TYPE_VIRTIO_SERIAL' address
type 'qemuBuildDeviceAddressProps' will now generate the address. The
only special property is 'nr'. QEMU declares it as:
nr=<uint32> - (default: 4294967295)
The test fallout is caused by formatting addresses as decimal numbers
instead of hex as described in the commit which added
'qemuBuildDeviceAddressProps'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Move the validation code into a separate function. For now the
validation is still kept in the commandline format step as simply just
moving it to the validator causes failures in the test suite, which will
need to be investigated deeper.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Internally format the PCI controller properties into JSON, but convert
it back to a string so that we for now change just the SCSI controller.
The change in tests is expected as the 'port' field for various PCI
controllers is expected to be a number and thus can't be represented as
a hexadecimal value in JSON.
QEMU expects the following types:
'pci-bridge'
chassis_nr=<uint8> - (default: 0)
'pxb-pcie':
bus_nr=<uint8> - (default: 0)
'pcie-root-port'
port=<uint8> - (default: 0)
chassis=<uint8> - (default: 0)
hotplug=<bool> - (default: true)
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Internally format the SCSI controller properties into JSON, but convert
it back to a string so that we for now change just the SCSI controller.
The change in tests is expected as the 'reg' field for a spapr-vio
address is expected to be a number:
$ qemu-system-ppc64 -device spapr-vscsi,help
spapr-vscsi options:
reg=<uint32> - (default: 4294967295)
The hand-rolled generator used hex representation but that will not be
possible on the monitor via JSON.
The properties of 'virtio-scsi' have following types according to QEMU:
iothread=<link<iothread>>
num_queues=<uint32> - (default: 4294967295)
cmd_per_lun=<uint32> - (default: 128)
max_sectors=<uint32> - (default: 65535)
ioeventfd=<bool> - on/off (default: true)
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Move the bootindex before the address so that the code is simpler.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The types for the special fields of the 'virtio-blk-pci' according to
QEMU are:
iothread=<link<iothread>>
ioeventfd=<bool> - on/off (default: true)
event_idx=<bool> - on/off (default: true)
scsi=<bool> - on/off (default: false)
num-queues=<uint16> - (default: 65535)
queue-size=<uint16> - (default: 256)
For all disks we also use the following properties (based on 'scsi-hd'):
device_id=<str>
share-rw=<bool> - (default: false)
drive=<str> - Node name or ID of a block device to use as a backend
chardev=<str> - ID of a chardev to use as a backend <- vhost-user-blk-pci
bootindex=<int32>
logical_block_size=<size> - A power of two between 512 B and 2 MiB (default: 0)
physical_block_size=<size> - A power of two between 512 B and 2 MiB (default: 0)
wwn=<uint64> - (default: 0)
rotation_rate=<uint16> - (default: 0)
vendor=<str>
product=<str>
removable=<bool> - on/off (default: false)
write-cache=<OnOffAuto> - on/off/auto (default: "auto")
cyls=<uint32> - (default: 0)
heads=<uint32> - (default: 0)
secs=<uint32> - (default: 0)
bios-chs-trans=<BiosAtaTranslation> - Logical CHS translation algorithm, auto/none/lba/large/rechs (default: "auto") <- ide-hd
serial=<str>
werror=<BlockdevOnError> - Error handling policy, report/ignore/enospc/stop/auto (default: "auto")
rerror=<BlockdevOnError> - Error handling policy, report/ignore/enospc/stop/auto (default: "auto")
The 'wwn' field is changed from a hex string to a number since qemu
actually treats it as a number.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Move the 'deflate-on-oom' and 'free-page-reporting' before the address
to simplify the genrator code.
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 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 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>
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 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>
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>
We have input files for those, provide also xml2argv testing since we
have them.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We can use real example configs to prove the support without the
need for using fake capabilities. Fix the recently added test cases.
The negative case for 'pc-i440fx-acpi-hotplug-bridge-disable' is removed
completely as there is no real qemu libvirt supports which wouldn't
have the capability.
The input file for the negative test on aarch64 is modified so that it's
actually a reasonably valid VM config.
Fixes: bef0f0d8be
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We can use two real example configs to prove the support without the
need for using fake capabilities. Fix the recently added test cases.
Fixes: 133d7983d6
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>
