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>
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>
The mocked path in the test suite is not in sync with what libvirtd
generates.
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>
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>
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>
As with previous test replace the fake caps versions with a combination
of DO_TEST_CAPS_VER(..., "2.11.0") and DO_TEST_CAPS_LATEST().
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Now that the code is refactored add the DO_TEST_CAPS_LATEST versions as
promised in the commit adding the pinned versions.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
All supported qemu versions now use the new commandline parser
functions, thus we can remove the old-style commandline generator.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Replace the 3 unix socket tests with real caps versions to demonstrate
that supported qemus no longer use the old syntax.
DO_TEST_CAPS_LATEST versions will be added later.
This also removes duplicate invocation of 'graphics-vnc-socket'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The switch to QemuOpts parser which brought the long-form options
happened in qemu commit 4db14629c3 ("vnc: switch to QemuOpts, allow
multiple servers") released in v2.3.0.
We can always assume this capability and remove the old-style
generators.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Replace the fake caps invocation with invocation binding it to the
oldest supported qemu version.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The filesystem commandline doesn't differ in the '-latest' cases.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use real caps instead of fake caps for the legacy cases. This will also
show us when we can remove the old-style code.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Modern QEMUs don't support the machine type at all. Remove it from our
fake caps generator too and adjust test cases which depend on it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
An update to the machine type was necessary as 's390-ccw' is no longer
supported.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use real caps. The flooppy device still is forbidden for ppc64.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
For backend related tests we need to cover the pre-blockdev and
post-blockdev era, so the fake-capability test is converted to a
combination of DO_TEST_CAPS_VER(..., "4.1.0") and DO_TEST_CAPS_LATEST.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The test case fails in pre-blockdev scenarios as it would pass RBD
parameters behind our back but succeeds after as we pass it in JSON form
which doesn't have that defect.
Cover both cases instead of the fake-caps version.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use the iSCSI disk path in one of the disks of the 'disk-cache' test as
it's the only specialty of 'disk-iscsi' case and remove the now
pointless files.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Move the contents of 'disk-network-iscsi-modern' into 'disk-network-iscsi'
to reuse the name and also invocation with real capablities and remove
the leftovers.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Cases for covering disk frontend properties can be converted to
DO_TEST_CAPS_LATEST without any need for intermediate capabilities.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Convert all the disk-related negative cases to use 'latest'
capabilities. The checks are mostly related to validation so using
real capabilities doesn't influence the outcome.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In effor to convert all test cases to real capability testing, this
test doesn't make sense any more as even the oldest QEMU supported
supports USB storage.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Currently we no longer support qemus which would miss the necessary
capability, thus the test can't be converted to DO_TEST_CAPS_LATEST.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Many disk-related test case have both a fake capability version and one
tied to qemu-2.12. Remove all of those fake caps tests as we have
coverage.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
QEMU supports the 'password-secret' parameter to pass a QCryptoSecret
since 2.9. Remove the alternate plaintext logic.
Unfortunately this had a ripple effect of removing qemuCaps from a lot
of functions.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The secret object is supported since qemu-2.6 and can't be compiled out.
Assume the presence to simplify the code.
This enables the use of the secret key for most tests not using real
caps.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The feature is now always present. Remove the negative test case as the
upcomming commit will remove the checks.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
All supported qemu versions now support this feature so this test is
pointless.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Added by c8a6ae8bb9 in qemu-v1.5.0 and can't be compiled out. Assume
that it's present and fix all fake-caps tests.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The option "queue-size" in virtio-blk was added in qemu-2.12.0, and
default value increased from qemu-5.0.0.
However, increasing this value may lead to drop of random access
performance.
Signed-off-by: Hiroki Narukawa <hnarukaw@yahoo-corp.jp>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Currently disk-virtio-queues test is now using specifying a fake
capability.
By this commit this test will make use of DO_TEST_CAPS_LATEST.
Signed-off-by: Hiroki Narukawa <hnarukaw@yahoo-corp.jp>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
These are no longer referenced by any existing test as of:
os-firmware-invalid-type -> a9b1375d7d
tseg-explicit-size -> 604990a175
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
SeaBIOS >= 1.11 has built-in support for outputting to the serial
console when QEMU sets -M graphics=off. Our minimum QEMU version
is 2.11.0, which bundled SeaBIOS 1.11. Thus we have no need to
use '-device sga' anymore.
This change results in a slight layout difference for option ROMs
in memory, however, it does not affect the migration data stream
format on the wire and once migration is complete the target QEMU
memory layout for ROMs matches the source QEMU once again.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Cover the case of missing disk target to cover the case fixed by
previous commit.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The validation infrastructure doesn't modify the definition and
additionally it makes sense to run the global code first as it's
validating certain corner cases.
The changed error messages from qemuxml2argvtest show that this is
indeed the proper ordering as all changed messages are actually better
describing the error.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The '-no-shutdown' flag prevents qemu from terminating if a shutdown was
requested. Libvirt will handle the termination of the qemu process
anyways and using this consistently will allow greater flexibility for
the virDomainSetLifecycleAction API as well as will allow using
the 'system-reset' QMP command during startup to reinitiate devices
exported to the firmware.
This efectively partially reverts 0e034efaf9
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Upcoming patches will modify how '-no-reboot' is handled when qemu
supports the 'set-action' QMP command. Add a test for it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This one will be slightly unstable given that CPU features are being
modified frequently in qemu especially when used with a modern cpu.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The host model expansion depends on the capability data, so in this case
it makes sense to have specific invocations of the test for all qemu
versions we have.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Switch to q35 in anticipation of using DO_TEST_CAPS* in further patches.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use the larger number in the original test to avoid having two files.
Additionally this avoids use of 'host-model' with DO_TEST_CAPS_LATEST in
cases when it isn't necessary for the purpose of the test as the CPU
model tends to change.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The test case doesn't really test anything about the specific CPU. Using
a host-model cpu with DO_TEST_CAPS_LATEST results in commandline changes
every time qemu updates the cpu definiton.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
All supported QEMU versions have this option so there's no need for us
to base it on the capability.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
All QEMU versions we support have these and it's very unlikely that they
will be removed. Remove the capability checks.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
All modern qemus support sandboxing so this is covered by other tests.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The feature is supported by all supported qemu versions thus covered
thoroughly by other test cases.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The test is now pointless since we always assume that this option is
present.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Upcoming commit will always add the property so the negative tests would
stop working.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Starting with QEMU 6.0, this controller is enabled by default
on aarch64.
https://bugzilla.redhat.com/show_bug.cgi?id=1967187
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
We need to pass the 'trim' requests through the copy-on-read filter so
if a user configures a discard policy on the disk the requests get
through to the appropriate format layer in the blockdev tree.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1986509
Reported-by: Richard W.M. Jones <rjones@redhat.com>
Tested-by: Richard W.M. Jones <rjones@redhat.com>
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Richard W.M. Jones <rjones@redhat.com>
Add support for customizable grabToggle key combinations with
<input type='evdev'>.
Signed-off-by: Justin Gatzen <justin.gatzen@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Use the common id 'lsec0' for all launchSecurity types in the QEMU
command line construction.
Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Add launch security type 's390-pv' as well as some tests.
Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Turns out, when introducing HMAT support in v6.6.0-rc1~249
I've forgot to allow "cache" attribute for <bandwidth/> element
in RNG. It's parsed and formatted, but schema does not allow it.
Fixes: a89bbbac86
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1980162
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
If guest is configured to use memfd then the function that build
memory-backend-* part of command line will put
memory-backend-memfd, always. Even for NVDIMMs. This is not
correct, because NVDIMMs need a backing path (usually to a real
host NVDIMM device). Therefore, regardless of memfd being
requested, we have to stick with memory-backend-file.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
It is possible to define/edit(in shut off state) a domain XML with
same hostdev device repeated more than once, as shown below. This
behavior is not expected. So, this patch fixes it.
vser1:
<domain type='kvm'>
[...]
<devices>
[...]
<hostdev mode='subsystem' type='mdev' managed='no' model='vfio-ccw'>
<source>
<address uuid='8e782fea-e5f4-45fa-a0f9-024cf66e5009'/>
</source>
<address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0005'/>
</hostdev>
<hostdev mode='subsystem' type='mdev' managed='no' model='vfio-ccw'>
<source>
<address uuid='8e782fea-e5f4-45fa-a0f9-024cf66e5009'/>
</source>
<address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0006'/>
</hostdev>
[...]
</devices>
</domain>
$ virsh define vser1
Domain 'vser1' defined from vser1
Signed-off-by: Shalini Chellathurai Saroja <shalini@linux.ibm.com>
Reviewed-by: Bjoern Walk <bwalk@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
We already reject TPM 1.2 in a number of scenarios; let's add
ARM virt guests to the list.
https://bugzilla.redhat.com/show_bug.cgi?id=1970310
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Tested-by: Liu Yiding <liuyd.fnst@fujitsu.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Instead of providing the configuration explicitly, let libvirt
fill in the blanks. After the recent changes, this results in a
working configuration without the need for user input.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Tested-by: Liu Yiding <liuyd.fnst@fujitsu.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
When adding support for externally launched virtiofsd,
I was too liberal and did not require a target.
But the target is required, because it's passed to the
QEMU device, not to virtiofsd.
https://bugzilla.redhat.com/show_bug.cgi?id=1969232
Fixes: 12967c3e13
Fixes: 56dcdec1ac
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The 's390-virtio' machine was removed from qemu in the 2.6 release.
Use the more modern s390-ccw-virtio machine type and use
VIR_TEST_CAPS_ARCH_LATEST to invoke it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Don't use the 's390-virtio' machine which was removed in qemu 2.6 and
use real capabilities for the test.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The 's390-virtio' machine was removed from qemu in the 2.6 release.
Use the more modern s390-ccw-virtio machine type and use
VIR_TEST_CAPS_ARCH_LATEST to invoke it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Remove the console, disk, and network test for the legacy s390 machine
which was removed in qemu 2.6. All of these have 'ccw' equivalents.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The 's390-virtio' machine was removed from qemu in the 2.6 release.
Modernize the test for sclp console since there isn't any other test for
it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The 's390-virtio' machine was removed from qemu in the 2.6 release.
Modernize the test for diag288 since there isn't any other test for it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
QEMU 6.0.0 introduced `confidential-guest-support` -machine option as
a replacement for `memory-encryption`. In order to test it use 6.0.0
capabilities as well.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The pc-1.0 machine type was deprecated in QEMU 6.0.0. In our tests we
use 2.12.0 and 6.0.0 replies so switch to pc type.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Using slice to cut off the end of the image is a perfectly vaid
configuration. Use 'unsignedInt' instead of 'positiveInteger' for the
'offset' attribute in the XML schema and modify one test case to cover
this use case.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1960993
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Introduce replies and xml files for QEMU 6.0.0 on s390x.
Signed-off-by: Shalini Chellathurai Saroja <shalini@linux.ibm.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Add test data based on qemu commit v6.0.0-540-g6005ee07c3.
Notable changes are the removal of 'sheepdog' disk storage protocol.
Additionally the cpu model reported when probing seems to have changed
from:
"model-id": "AMD Ryzen 9 3900X 12-Core Processor "
to:
"model-id": "QEMU TCG CPU version 2.5+"
despite building on the same machine. This probably also results in the
2 test changes in the CPU definition which popped up in this update.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
