This patch rewrites conditions to make the code easier to read and less
nested.
Signed-off-by: Kristina Hanicova <khanicov@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
According to a9fe9569ab, the <acpi index='NNN'/> is only for PCI
devices. Remove the ref acpi from devices channel, smartcard, tpm,
redirdev, panic, hub because none of them has PCI address. And add the
ref acpi to iommu device.
Fixes: a9fe9569ab
Signed-off-by: Han Han <hhan@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This patch prevents nesting of if conditions and makes the code
cleaner.
Signed-off-by: Kristina Hanicova <khanicov@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This was not causing any problems because all cases below were empty,
but in order to avoid future misbehavior, add a break to this case.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
There's no need to use virBufferAddStr() for literal strings
without any newline character as it's more expensive than
virBufferAddLit().
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
These wrapper functions were used to adapt the virObjectUnref() function
signature for different callbacks. But in commit 0d184072, the
virObjectUnref() function was changed to return a void instead of a
bool, so these adapters are no longer necessary.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Some USB devices have a buggy firmware that either crashes on
device reset, or make the device unusable in some other way.
Fortunately, QEMU offers a way to skip device reset either
completely, or if device is not initialized yet. Expose this
ability to users under:
<hostdev mode='subsystem' type='usb'>
<source guestReset='off'/>
</hostdev>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When formatting IOThreads (in virDomainDefIOThreadsFormat()), we
may only output the number of IOThreads, or the full list of IOThreads too:
<iothreads>4</iothreads>
<iothreadids>
<iothread id='1' thread_pool_max='10'/>
<iothread id='2' thread_pool_min='2' thread_pool_max='10'/>
<iothread id='3'/>
<iothread id='4'/>
</iothreadids>
Now, the deciding factor here is whether those individual
IOThreads were so called 'autofill-ed' or user provided. Well, we
need to take another factor in: if an IOThread has pool size
limit set, then we ought to format the full list.
But how can we get into a situation when a thread is autofilled
(i.e. not provided by user in the XML) and yet it has pool size
limit set? virDomainSetIOThreadParams() is the answer.
Sure, we could also unset the autofill flag whenever a pool size
limit is being set. But this approach allows us to not format
anything if the limits are reset (we don't lose the autofill
information).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The <defaultiothread/> element is formatted inside
virDomainDefaultIOThreadDefFormat() which is called only from
virDomainDefIOThreadsFormat() (so that IOThread related stuff is
formatted calling one function). However, when there are no
<iothreadids/> defined (or only autoallocated ones are present),
then the outer formatting function exits early never calling the
<defaultiothread/> formatter.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We accept TPM version in the domain XML. However, supported
version depends on the host (swtpm_setup binary) and thus it may
be tricky for users (or mgmt applications) chose a version.
Introduce machinery for reporting supported version in domain
capabilities.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Our coding style suggests 80 chars per line with error messages
being exception (for easier git-grep). Apply this exception onto
the newly created domain_postparse.c file.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The domain post parse functions currently live in domain_conf.c
which thus grows always larger. Mimic what we've done for the
validation code and move the post parse code into a separate
file: domain_postparse.c.
I've started by moving every function with PostParse in its name
into the new file and then compile hunting for helper functions
only to move them as well.
In the end, I've moved virDomainDefPostParse symbol in
libvirt_private.syms into a new section. And while
virDomainDeviceDefPostParseOne() is made 'public' in
domain_postparse.h too, I'm not exporting it because it has no
caller outside src/conf/ and it's unlikely it ever will.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The virDomainDefPostParseDeviceIteratorData struct is exported in
domain_conf.h because it's used in both domain_conf.c and
domain_validate.c. However, the latter usage is not warranted,
it's just a shortcut so that we don't have to introduce a similar
struct just for domain_validate.c. Well, do the extra step and
introduce a separate structure for domain_validate.c. This allows
us to move post parse code later on.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
For a qcow2 storage volume with luks encryption created by qemu-img, its
dumped storage vol XML has no secret element in encryption:
<volume type='file'>
...
<encryption format='luks'>
</encryption>
...
</volume>
That will cause a failure in rng validation. Fix that validation failure.
Signed-off-by: Han Han <hhan@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
In my previous commit I've introduced virDomainIOMMUDefValidate()
function with a switch() statement. However, two cases in it,
though empty, were not terminated with a break statement which
made compiler complain.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Per v8.3.0-rc1~199 it's only a virtio IOMMU that can have
<address/>. The rest (Intel and SMMUv3) are system devices and
thus have no address associated with them. However, this
assumption is never checked for.
Fixes: b0eb1e193f5db033d0fbbf91ff71a121066ad77c
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Fix the copy-and-paste error by referring to the correct variable.
Fixes: 0df2e7df80452f81edbfeb0ee355235b533346a9
https://bugzilla.redhat.com/show_bug.cgi?id=2103132
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Treat the 'protocolVer' field as a string so that e.g. '4.1' can be
used. Forbid only ',' in the string as it's a separator of arguments for
mount options.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Regardless of whether firmware autoselection is in use, we
still want to parse the list of requested features. Doing this
will allow us to produce better error messages.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Generally speaking, when firmware autoselection is in use we
don't want any information to be provided manually. There are
two exceptions:
* we still want the path to the NVRAM file to be customizable;
* using <loader secure='yes'/> was how you would ask for a
firmware that implements the Secure Boot feature in the
original approach to firmware autoselection, so we want to
keep that working.
Anything else should result in a descriptive error.
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/327
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This makes it explicit that there are two possible scenarios
(whether or not firmware autoselection is in use) and will make
upcoming changes cleaner to implement.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Currently we're simply ignoring some elements and attributes,
such as the loader path, when firmware autoselection is enabled
because we know we're not going to use them.
This makes sense, but has the unfortunate consequence of
confusing users who experience part of their configuration
simply going away for no apparent reason.
A more user-friendly approach is to produce meaningful error
messages in those scenarios. As a first step towards that goal,
stop conditionally parsing information.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This combination doesn't make sense and so the firmware
autoselection logic will not be able to find a suitable firmware,
but it's more user-friendly to report a detailed error upfront.
Note that this check would ideally happen in the validate phase,
but if we moved it there we would no longer be able to
automatically enable secure-boot when enrolled-keys=yes. Since
the combination never resulted in a working configuration, the
chances of this causing real-world VMs to disappear are
extremely low.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
There are currently no failure scenarios for the function, but
we're about to add one.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The latter doesn't make sense without the former, so make that
visible in the XML.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Currently, the lack of a <loader> element results in the <nvram>
element being completely ignored, but this is unnecessarily
limiting: even when firmware autoselection is in use, it should
be possible for the user to specify a custom path for the NVRAM
file.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This makes the function more consistent with
virDomainLoaderDefParseXML() by preferring the virXMLProp
class of functions to XPath access.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
We're going to start passing multiple nodes to the function in
a moment, so we need a more specific name.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
All the data in the <nvram> element ends up in the same struct
as that coming from the <loader> element, so it makes sense to
have a single entry point for parsing an XML document into a
virDomainLoaderDef instance.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
It belongs to virDomainLoaderDefParseXMLNvram(), where the other
parts of the <nvram> element are handled.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
When the 'type' attribute is present we'd end up overwriting
this value via virDomainStorageSourceParse(). Moving this
assignment makes the current code clearer and will also help
with upcoming changes.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The previous name was identical, modulo the case, to the
completely unrelated virDomainNVRAMDefParseXML().
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Pure code movement, needed to prepare for upcoming changes.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
An explicit limit would be more user friendly. Add the limit to error message.
Before this commit:
```
error: requested size must be smaller than or equal to @size
```
Now:
```
error: requested size must be smaller than or equal to @size (8388608KiB)
```
Signed-off-by: Liu Yiding <liuyd.fnst@fujitsu.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Add <interleave> to allow the subproperties to be specified in any
order.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Evaluate the XPath as a boolean, instead of trying to get a node
out of it.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Internally we already collect x86 host family + model + stepping
numeric values. This exposed them in capabilities CPU output.
Example:
$ sudo virsh capabilities | grep -A1 -B1 signature
<microcode version='240'/>
<signature family='6' model='94' stepping='3'/>
<counter name='tsc' frequency='3408010000' scaling='no'/>
Users need to know these values to calculate an expected.
SEV-ES/SEV-SNP launch measurement.
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Even when the os.loader element is absent, we still have to
validate that the user is not attempting to use firmware
autoselection with a driver that doesn't implement the feature.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add an element to configure the thread pool size:
...
<binary>
<thread_pool size='16'/>
</binary>
...
https://bugzilla.redhat.com/show_bug.cgi?id=2072905
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The check was historically done only for _TYPE_VOLUME disks, but
refactors to allow _TYPE_VOLUME disks in the backing chain caused a
regression where we'd reject startupPolicy also for _TYPE_BLOCK disks
which historically worked well.
Fix it by using the 'virDomainDiskDefValidateStartupPolicy' helper and
use it only when the top level image is a _TYPE_VOLUME as in other cases
it was already validated. This also allows _TYPE_BLOCK volumes to use
startup policy.
Fixes: 37f01262eed9f37dd5eb7de8b83edd2fea741054
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2095758
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Our startup policy checkers work only for local paths, so disk sources
such as NVMe, or vhost-user can't be used with startup policy.
Unfortunately the validation did not catch these cases. Fix it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Move the code into 'virDomainDiskDefValidateStartupPolicy' which will be
later reused in the qemu driver.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
