I first noticed a problem when I added a <memoryBacking> element at an
unusual (but still correct) place in the domain XML, and validation
failed. Then I tried adding that element in several different places
and it failed in many, but not all of them.
(NB: from here on, I will use '' for the names of attributes in the
domain XML, <> for elements in the domain XML, and "" for the names of
grammar rule definitions in the RNG file, and "<>" for the names of
elements in the RNG file's own XML. Confused yet? If so, please tell
me a better way - everything I know about RNG I've picked up
informally by looking at examples in already existing RNG files)
Starting from the top level of the grammar for <domain>
("domaincontents" in domaincommon.rng), I noticed that
1) the "<attribute>" for the 'id' attribute of <domain> is defined
inside an "<interleave>" down in the definition of "ids" (which is
referenced from "domaincontents") (I'm not familiar with the
nomenclature - does that make it a "sub-grammer", "child-grammar",
???)
2) although the definition of "ids", had all of its
"<attribute>"s/"<element>"s inside an "<interleave>",
"domaincontents" already had the reference to "ids" inside an
"<interleave>", so there were nested "<interleave>"s.
It's not clear to me how an "<attribute>" or "<interleave>" inside
another "<interleave>" is supposed to behave, but they both seemed a
bit suspicious.
I tried all of the below modifications:
1) moving the grammar for the 'id' attribute out of the "<interleave>"
but still inside "ids"
2) moving the grammer for the 'id' attribute directly into
"domaincontents" (and outside of its "interleave"
3) removing the "<interleave>" that was inside "ids"
4) (2) + (3)
5) move the entire grammar rule "ids" up directly in place of <ref
name="ids"> in "domaincontents".
6) (5), but with the grammar for the 'id' attribute moved outside of
the "<interleave>"
(6) was the only change that allowed all of the following (using
modifications to the subelements of <domain> in
net-vhostuser-passt.xml as example):
a) a <memoryBacking> element in between *any* two existing elements
b) moving <name> in between any two elements
c) oddly, in addition to the problem with putting <memoryBacking> in
odd places, I also found that the original RNG did not allow the
<clock> element to be placed in between <on_poweroff> and
<on_reboot>, but once I'd made the change in (6), this was no
longer problematic. Why should this have any effect? No idea, but
it works :-/
(NB: there are many other cases of referencing "sub-grammar" from
inside an "<interleave>", and they all seem to work just fine;
possibly in this case it was problematic because the sub-grammar a)
also contained an "<interleave>", b) had an "<attribute>" at its
toplevel, or c) had multiple "<element>"s.)
(inexplicably (to me) at one point during my experimentation, I tried
reordering the references to "clock", "resources", "features", and
"events", and that *also* made it legal to put a <clock> element in
between the <on_*> elements:-O)
Since I was no longer able to reproduce the error described in (c)
once I had made mod (6) (move all of "ids" directly into
"domaincontent", I decided it was pointless for me to spend any more
time randomly poking and just add that to the new test case for that
in case some other random change to the RNG causes it to start failing
again.
(I thought of writing a test program that would try all possible
orderings of the subelements of <domain>, but since doing that for
even 10 subelements would mean testing > 3.2 million different XML
documents, I decided we could continue in this adhoc manner, just
adding a single new test case if/when a new validation failure is
found.)
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
As is often the case with macros (especially those that resolve to
multiple statements), it isn't technically necessary to end any of the
invocations of the DO_TEST_*() macros with a semicolon (as evidenced
by the lines changed in this path). Having does make some
auto-indenters (e.g. cc-mode in emacs) more likely to do the right
thing, though, and it also looks nicer if all the lines are similar.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The documentation states:
``iothread``
Supported for controller type ``scsi`` using model ``virtio-scsi`` for
``address`` types ``pci`` and ``ccw`` :since:`since 1.3.5 (QEMU 2.4)`. The
The code itself didn't validate if iothread is specified for any other
controller type.
Add test case showing the issue on one example.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This can/should also be done for a traditional vhost-user interface
(ie not backend type='passt') but that will be a separate change.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
<interface type='vhostuser'><backend type='passt'/> needs to run the
passt command just as is done for interface type='user', but then add
vhostuser bits to the qemu commandline/monitor command.
There are some changes to the parsing/validation along with changes to
the vhostuser codepath do do the extra stuff for passt. I tried
keeping them separated into different patches, but then the unit test
failed in a strange way deep down in the bowels of the commandline
generation, so this patch both 1) makes the final changes to
parsing/formatting and 2) adds passt stuff at appropriate places for
vhostuser (as well as making a couple of things *not* happen when the
passt backend is chosen). The result is that you can now have:
<interface type='vhostuser'>
<backend type='passt'/>
...
</interface>
Then as long as you also have the following as a subelement of
<domain>:
<memoryBacking>
<access mode='shared'/>
</memoryBacking>
your passt interfaces will benefit from the greatly improved
efficiency of a vhost-user data path, and all without requiring
special privileges or capabilities *anywhere* (i.e. it works for
unprivileged libvirt (qemu:///session) as well as privileged libvirt).
Resolves: https://issues.redhat.com/browse/RHEL-69455
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The command will be used to re-activate block nodes after migration when
we're leaving the VM paused so that blockjobs can be used.
As the 'node-name' field is optional the 'qemumonitorjsontest' case
tests both variants.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
The flag signals presence of the 'blockdev-set-active' QMP command.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Notable changes:
- 'blockdev-set-active' QMP command and the corresponding 'active'
flag for instantiating blockdev backends added
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
The call to 'qemuBlockStorageSourceNeedsFormatLayer()' bases the
decision also on the state of the passed FD, so we must initialize the
passthrough data via 'qemuDomainPrepareStorageSourceFDs()' before the
aforementioned call.
In the test change it's visible that we didn't add the necessary 'raw'
driver which allows the 'protocol' blockdev to be opened in 'rw' mode so
that qemu picks the proper file descriptior while keeping the device
read-only.
Resolves: https://issues.redhat.com/browse/RHEL-37519
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Add few examples of fd groups with the 'writable' flag set, when passing
a single FD. Notably as a top level image of a readonly disk (even when
that doesn't make much sense) and also as a base image of a chain.
Note that this documents a status quo of a bug fixed in upcoming patch.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Pass also the 'writable' state to the fake passed FDs so that we can
test it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Recently, I was part of a discussion where it was suspected that
libvirt does not pick up correct FW for SEV-SNP guests. Update
our test to demonstrate it does.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Add data based on 'v9.2.0-1537-gd922088eb4'
Notable changes:
- '10.0' machine types added
- 'hub' chardev backend added
- 'cpr' migrate channel added
- 'nsamples' field for 'dbus' audio backend now reported
- 'ClearwaterForest-v1' cpu model added
- 'SierraForest-v2' cpu model added
- 'ivshmem-flat' device added
- new qom objects:
- 'virtio-mem-system-reset'
- 'vmclock'
- default value of 'rombar' changed from 1 to -1 for all devices
- 'intel-iommu' device:
- default value of 'aw-bit' changed from '39' to '48'
- 'fs1gp' boolean added
- 'x-flts' boolean added
- 'virtio-balloon-pci'/'virtio-mem-pci':
- 'ioeventfd' added
- 'vectors' added
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Update the data after the release.
Notable changes:
- the 6.2 machine types became deprecated
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Add the group membership information to a CCW device. Allow to filter
CCW devices based on a group membership.
Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Replace cssid, ssid and devno elements with virCCWDeviceAddress.
Reviewed-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This is similar to emuxmlconfdata/memory-hotplug-virtio-mem-pci-s390x.xml
except the explicit placement of virtio-mem onto a PCI bus is removed.
This results in virtio-mem being placed onto CCW "bus" this demonstrating
previous commits working as expected.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
This capability tracks whether QEMU supports virtio-mem-ccw
device. Introduced in QEMU commit v9.2.0-492-gaa910c20ec only
upcoming release of QEMU supports the device.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
As of v9.2.0-1413-gd77ae821e8 QEMU supports virtio-mem-pci on
s390 too. Let's add a test case for that.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Since we supported 'product' parameter for SCSI, just expanded existing
solution makes IDE/SATA parameter works too. QEMU requires parameter 'model'
in case of IDE/SATA (instead of 'product'), so the process of making JSON
object is slightly modified. Length of the 'product' parameter is
different in SCSI (16 chars) and ATA/SATA (40 chars).
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/697
Signed-off-by: Adam Julis <ajulis@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The 'aia' feature is added as a machine type option for the 'virt'
RISC-V machine, e.g. "-machine virt,aia=<val>".
Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
AIA (Advanced Interrupt Architecture) support was introduced in QEMU 7.0
for the 'virt' machine type. It allows the guest to choose from a more
modern interrupt model than the default (CLINT - Core Logical Interrupt
Controller).
Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Let us introduce the xml and reply files for QEMU 10.0.0 on s390x.
Notable changes:
- new s390-ccw-virtio-10.0 machine type
- old machine types (2.4 - 2.8) dropped
- new CPU models
- New devices:
- virtio-mem-ccw
- chardev now supports qemu-vdagent
Signed-off-by: Shalini Chellathurai Saroja <shalini@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Suggested-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
In its upstream commit [1], qemu dropped s390-2.7 machine type,
then in commit [2] the s390-2.8 machine type was dropped. But as
Thomas Huth pointed out, any machine type that's older than 6
years is subject to removal [3]. This means, any machine type
older than 4.1 is going to be removed eventually.
We have two test cases that assumes existence of 2.7 machine type.
While they could be switched to 4.1 machine type, we also have
another test case that already check 4.2 machine type.
Therefore, just drop the 2.7 ones.
1: 3199c7ee76
2: 66924fe369
3: ce80c4fa6f
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Add an example image formatted by:
qemu-img create -f qcow2 -o data_file=nbd+unix:///datafile?socket=/tmp/nbd,data_file_raw=true /tmp/nbddatastore.qcow2 10M -u
serving as an example when qemu records an empty string as the
'data_file' field.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Commit 247357cc292a added support for direct and extended modes for
tlbflush, but forgot to do the formatting as well.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Resolves: https://issues.redhat.com/browse/RHEL-72192
Signed-off-by: Adam Julis <ajulis@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This reverts commit bb5e26749fe5b5856a3541be2cbe147701e6e121.
swtpm-setup doesn't have "tpmstate-lock", only swtpm.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
They require special handling since they are dependent on the basic
tlbflush feature itself and therefore are not handled automatically as
part of virDomainHyperv enum, just like the stimer-direct feature.
Resolves: https://issues.redhat.com/browse/RHEL-7122
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Libxml2 has awful error reporting behaviour when reading files. When
we fail to load a file from the test driver we see:
$ virsh -c test:///wibble.xml
I/O warning : failed to load external entity "/wibble.xml"
error: failed to connect to the hypervisor
error: XML error: failed to parse xml document '/wibble.xml'
where the I/O warning line is something printed by libxml2 itself,
which also lacks any useful detail.
Switching to our own file reading code we can massively improve
things:
$ ./build/tools/virsh -c test:///wibble.xml
error: failed to connect to the hypervisor
error: Failed to open file '/wibble.xml': No such file or directory
Using 10 MB as an upper limit on XML file size ought to be sufficient
for any XML files libvirt is reading.
Reviewed-by: Richard W.M. Jones <rjones@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Currently given an input of '<dom\n' we emit an error:
error: Failed to define domain from tests/qemuxmlconfdata/broken-xml-invalid.xml
error: at line 2: Couldn't find end of Start Tag dom line 1
(null)
^
With this fix we emit:
error: Failed to define domain from tests/qemuxmlconfdata/broken-xml-invalid.xml
error: at line 2: Couldn't find end of Start Tag dom line 1
<dom
----^
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Richard W.M. Jones <rjones@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The exit-on-error argument (added in QEMU 9.1.0) can be used to tell
QEMU not to exit when incoming migration fails so that the error can be
retrieved via QMP. This patch adds a new capability bit indicating
support for the new argument.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
In my previous commit v10.10.0-48-g2d222ecf6e I've made us enable
I/O APIC when there is an IOMMU with EIM. This works well. What
does not work is case when there's just an IOMMU without EIM but
with 256+ vCPUS. Problem is that post parsing happens in two
stages: general domain post parse (where
qemuDomainDefEnableDefaultFeatures() is called) and then per
device post parse (where qemuDomainIOMMUDefPostParse() is
called). Now, in aforementioned case it is the device post parse
phase where EIM is enabled but the code that would enable
VIR_DOMAIN_FEATURE_IOAPIC has already run.
To resolve this, make the domain post parse callback "foresee"
the future enabling of EIM so that it can turn on I/O APIC
beforehand.
Resolves: https://issues.redhat.com/browse/RHEL-65844
Fixes: 2d222ecf6e73614a400b830ac56e9aaa1bc55ecc
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Add a new a attribute, deprecated_features='on|off' to the <cpu>
element. This is used to toggle features flagged as deprecated on the
CPU model on or off. When this attribute is paired with 'on',
deprecated features will not be filtered. When paired with 'off', any
CPU features that are flagged as deprecated will be listed under the
CPU model with the 'disable' policy.
Example:
<cpu mode='host-model' check='partial' deprecated_features='off'/>
The absence of this attribute is equivalent to the 'on' option.
The deprecated features that will populate the domain XML are the same
features that result in the virsh domcapabilities command with the
--disable-deprecated-features argument present.
It is recommended to define a domain XML with this attribute set to
'off' to ensure migration to machines that may outright drop these
features in the future.
Signed-off-by: Collin Walling <walling@linux.ibm.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Add QEMU_CAPS_QUERY_CPU_MODEL_EXPANSION_DEPRECATED_PROPS for detecting
if query-cpu-model-expansion can report deprecated CPU model properties.
QEMU introduced this capability in 9.1 release. Add flag and deprecated
features to the capabilities test data for QEMU 9.1 and 9.2 replies/XML
since it can now be accounted for.
When probing for the host CPU, perform a full CPU model expansion to
retrieve the list of features deprecated across the entire architecture.
The list and count are stored in the host's CPU model info within the
QEMU capabilities. Other info resulting from this query (e.g. model
name, etc) is ignored.
The new capabilities flag is used to fence off the extra query for
architectures/QEMU binaries that do not report deprecated CPU model
features.
Signed-off-by: Collin Walling <walling@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
query-cpu-model-expansion may report an array of deprecated properties.
This array is optional, and may not be supported for a particular
architecture or reported for a particular CPU model. If the output is
present, then capture it and store in a qemuMonitorCPUModelInfo struct
for later use.
The deprecated features will be retained in qemuCaps->kvm->hostCPU.info
and will be stored in the capabilities cache file under the <hostCPU>
element using the following format:
<deprecatedFeatures>
<property name='bpb'/>
<property name='csske'/>
<property name='cte'/>
<property name='te'/>
</deprecatedFeatures>
At this time the data is only queried, parsed, and cached. The data
will be utilized in a subsequent patch.
Signed-off-by: Collin Walling <walling@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
This is a follow up of my previous commits. If the number of
vCPUs exceeds some arbitrary value (255) then QEMU requires IOMMU
with EIM and intremap enabled. But in turn, intremap IOMMU
requires split I/O APIC (per virDomainDefIOMMUValidate()). Since
after my previous commits (e.g. v10.10.0-rc1~183) IOMMU is added
automagically, the I/O APIC can be also enabled automagically.
Relates to: https://issues.redhat.com/browse/RHEL-65844
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This function return value is invariant since 18f3771, so change
its type and remove all dependent checks.
Found by Linux Verification Center (linuxtesting.org) with Svace.
Reported-by: Pavel Nekrasov <p.nekrasov@fobos-nt.ru>
Signed-off-by: Alexander Kuznetsov <kuznetsovam@altlinux.org>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
