The new virDomainGraphicsReload API is used to make the domain reload
its certificates without restart, and avoid service interruption.
Currently, only QEMU VNC TLS certificates are supported, but
flags are also reserved for subsequent scenarios.
To reload QEMU VNC TLS certificates as an example, we can call:
virDomainGraphicsReload(domain, 0, 0);
Then the specified QMP message would be send to QEMU:
{"execute": "display-reload", "arguments":{"type": "vnc", "tls-certs": true}}
Signed-off-by: Zheng Yan <yanzheng759@huawei.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The 'display-reload' QMP command was introduced in QEMU 6.0.0, so we
add a compatible capability to check if target QEMU binary supports it.
{"execute":"display-reload", "arguments":{"type": "vnc", "tls-certs": true}}
The new QMP refer to:
9cc0765165
Signed-off-by: Zheng Yan <yanzheng759@huawei.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Cloud-Hypervisor is capable of running VMs with kvm or mshv as the
hypervisor on Linux Host. Guest to hypevisor ABI with mshv hypervisor is
the same as in the case of VIR_DOMAIN_VIRT_HYPERV. So, VIR_DOMAIN_VIRT_HYPERV
type will be reused to represent the config with Linux Host and mshv as the
hypervisor.
While initializing ch driver, check if either of /dev/kvm or /dev/mshv
device is present on the host. Before starting ch domains, check if the
requested hypervisor device is present on the host.
Users can specify hypervisor in ch guests's domain definitions like
below:
<domain type='kvm'>
_or_
<domain type='hyperv'>
Signed-off-by: Praveen K Paladugu <prapal@linux.microsoft.com>
Signed-off-by: Praveen K Paladugu <praveenkpaladugu@gmail.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
With Unix mode, pass a socket path to cloud-hypervisor.
Cloud-Hypervisor will attach guest's serial port to this socket path.
Users can connect to the serial port using one of the following commands:
`socat -,crnl UNIX-CONNECT:<path/to/socket>`
OR
`minicom --device unix#<path/to/socket>`
Signed-off-by: Praveen K Paladugu <prapal@linux.microsoft.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Unix Socket backend is only supported for serial port in
cloud-hypervisor. Add relevant checks in chValidateDomainDeviceDef.
Signed-off-by: Praveen K Paladugu <prapal@linux.microsoft.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Using check='none' when starting a domain with a CPU model marked as
usable is no longer needed as libvirt will do the right thing even with
check='partial'.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Currently all machine types which do honour '-usb' are already covered
by code which will either select a proper controller model or would
select the same one which '-usb' would use.
Thus all of the legacy -usb controller code can be removed.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
- 'virt*' machines already don't allow downgrade
- 'versatilepb' and 'realview' machines use 'pci-ohci' controller with '-usb'
- all other machines ignore '-usb' (some have sysbus-based USB
controller which we don't even consider)
For the 'versatilepb' and 'realview' machines libvirt would already
resort to picking either an existing controller model or trying to pick
the one which '-usb' would select and thus fail either way.
All other machine types ignore it.
We can thus remove the fallback for all arm-based machines.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
- 'pseries' machines already don't allow downgrade
- 'g3beige' and 'mac99' machines use 'pci-ohci' controller with '-usb'
- all other machines ignore '-usb'
For 'g3beige' and 'mac99' libvirt already has 'pci-ohci' as contoller it
would select as one of the options when picking a model, thus it's
impossible to reach situation when '-usb' would be honoured.
All other machine types ignore it.
We can thus remove the fallback for all ppc-based machines.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
The default USB device auto-selection code for 'pseries' machines picks
controller models which are also selected when '-usb' is used thus it's
impossible to end up in the case when using '-usb' would be possible:
$ qemu-system-ppc64 --machine pseries,usb=on
qemu-system-ppc64: could not find a module for type 'nec-usb-xhci'
$ qemu-system-ppc64 --machine pseries-2.5,usb=on
qemu-system-ppc64: could not find a module for type 'pci-ohci'
Remove the impossible downgrade and adjust tests.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
- 'q35' machine type already explicitly forbids fallback
- 'isapc' never supported USB and '-usb' is ignored
- 'i440fx' does support '-usb' and translates it into 'piix3-uhci' which
is identical to what libvirt selects
- we currently don't care about 'microvm'
Attempting to start an 'pc' (i440fx) machine with -usb when 'piix3-uhci'
is compiled out will fail and in any other case libvirt will use the
proper explicitly selected controller.
Drop the '-usb' downgrade for x86 arch.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
This controller is used as the default/implicit USB controller by
multiple machine types which honour the '-usb' flag of qemu. Add it as
fallback in libvirt too.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
The machine types historically have a default USB controller populated
via '-usb' which libvirt assumed implicitly. Qemu will use 'pci-ohci'
for both if '-usb' is used.
Unfortunately an USB controller instantiated via '-usb' is unusable as
the bus name libvirt generates doesn't reflect the real name qemu uses,
and thus no libvirt-defined USB devices can be put on the controller.
This patch will populate the default USB controller into the XML and
select it's model to 'pci-ohci' unconditionally as the machine would
fail to start with '-usb' if that controller model is not available.
This patch doesn't try to make any other assumptions about
auto-populated model of USB controllers, which means that for an
explicit USB controller without model a different model will be picked.
Note that this will likely cause ABI differences and break migration for
the two machine types, in the corner case when the default USB
controller would be populated, but given that both are obsolete board
types and USB was unusable it doesn't make sense to keep supporting this
specific case when '-usb' was formatted.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Assign VIR_DOMAIN_CONTROLLER_MODEL_USB_DEFAULT rather than -1.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Most machine types are avaliable in all arches by qemu. This is also
true for the 'versatilepb' machine type example in the tests.
Move all the ARM architectures together so that they are handled in
sync.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Add an example using the old binary/machine type to also see how legacy
cases are handled.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Move the test invocation and rename the test files according to the
pattern.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
The 'borzoi' machine doesn't honour '-usb' in qemu so use it as an
example for the upcoming patch for removing '-usb' support.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Add test data for a 'realview' machine example to validate default USB
controller selection.
Note that it's unlikely that anyone would run 'realview' machines with
'aarch64' architecture, but qemu allows it and it's simpler test-wise in
libvirt.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Add capabilities based on a dump from x86_64 host running Fedora for the
qemu-system-arm binary.
The test dump will be used for illustration of USB controller model
selection.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Allow using armv7l arch in a capability dump.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Document the reality that some dumps were faked for purpose of testing
corner cases.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Mention the new 'scripts/qemu-replies-tool.py'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Ideally check='partial' would check exactly the features QEMU would want
to enable when asked for a specific CPU model (and features). But there
is no way we could ask QEMU how a specific CPU would look like. So we
use our definition from CPU map, which may slightly differ as QEMU adds
or removes features from CPU models, and thus we may end up checking
features which QEMU would not enable while missing some required ones.
We can do better in specific cases, though. If a CPU definition uses
only a model and disabled features (or none at all), we already know
whether QEMU can enable all features required by the CPU model as that's
what we use to set usable='yes' attribute in the list of available CPU
models in domain capbilities XML. So when a usable CPU model is
requested without asking for additional features (disabling features is
fine) we can avoid our possible inaccurate check using our CPU map.
For backward compatibility we only consider usable models. If a
specified model is not usable, we still check it the old way and even
let QEMU start it (and disable some features) in case our definition
lacks some features compared to QEMU.
Fixes: https://gitlab.com/libvirt/libvirt/-/issues/608
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Recently a kernel bug caused QEMU to report a CPU feature as enabled
while listing it in the "unavailable-features" list of features that
were requested, but could not be enabled. The feature was actually
enabled, but we marked it as disabled when starting a domain. Later when
the domain is migrated, the destination requests the feature to be
disabled, which breaks the guest ABI or if we are lucky QEMU just fails
to load the migration stream.
Let's make similar bugs more visible in the future by refusing to even
start the domain.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Trying to print pages of a size larger than the UINT_MAX of the
given platform (for example, 4G on 64-bit ARM), results in a
system error even though this is a legitimate request.
The vshCommandOptScaledInt() used for parsing the pagesize is
given UINT_MAX as the upper limit. The parsed value is then
divided by 1024 and fed to virNodeGetFreePages() which expects an
unsigned int. We can't change the public API but the upper limit
can be raised by the factor of 1024.
Resolves: https://issues.redhat.com/browse/RHEL-23608
Signed-off-by: Adam Julis <ajulis@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Picks up the switch from FreeBSD 13.2 to 13.3
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This is guaranteed to keep failing even after loongarch64
support is introduced.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This fails to be parsed because libvirt doesn't yet know about
the architecture, but thanks to the recent improvements this
is a merely a local failure rather than bringing everything
else down with it.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
At the moment, any kind of issue being detected in any of the
firmware descriptor files will result in the entire process
being aborted.
In particular, installing a build of edk2 for an architecture
that libvirt doesn't yet know about, for example loongarch64,
will break most firmware-related functionality: it will no
longer be possible to define new EFI VMs, start existing ones,
or even just obtain the domcapabilities for any architecture.
This is obviously unnecessarily harsh. Adopt a more relaxed
approach and simply ignore the firmware descriptors that we
are unable to parse correctly.
https://bugzilla.redhat.com/show_bug.cgi?id=2258946
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Instead of returning the list of paths exactly as obtained
from qemuFirmwareFetchConfigs(), and allocating the list of
firmwares to be exactly that size right away, start with two
empty lists and add elements to them one by one.
At the moment this only makes things more verbose, but later
we're going to change things so that it's possible that some
of the paths/firmwares are not included in the lists returned
to the caller, and at that point the changes will pay off.
Note that we can't use g_auto() for the new list of paths,
because until the very last moment it's not null-terminated,
so g_strfreev() wouldn't be able to handle it correctly.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
In a couple of cases, we were reporting an error without
actually terminating the parse process.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Ensure that all rows have 3 columns and avoid generation of emtpy
elements which would be turned by the XML formatter into non-pair td/tr
tags which don't work properly with HTML5 parsers.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The source document can contain an empty '@flags' attribute which passes
the test but generates an empty element. Check that flags is non-empty
to trigger the fallback.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The HTML standard requires that a table column must include at least one
row which defines it exclusively, thus having a table where all rows
unite it via 'colspan' is illegal.
Modify the enum value generator to always output the description field
even when it's empty rather than uniting it, as in case when each value
doesn't have a description the generated document would violate the
standard.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The various objects we generate API for may have empty description in
which case an empty div would be generated when processing the API
description. As we're using XML output mode the generator would shorten
such divs to the non-pair empty element version, which doesn't work well
with HTML5 parsers requiring a pair tag for <div>
Avoid empty description <div> elements altogether by skipping it if the
description is empty.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
If an API has no ACLs an empty <div class='acl'/> would be generated
which is mis-interpreted by browsers when creating DOM to nest any
subsequent elements under it.
Don't generate the ACL section div unless it will be filled.
Best viewed with 'git show -w'
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Similarly to previous commit drop the 'type' attribute which is frowned
upon by the HTML standard.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Per the w3 html validator a HTML/XML comment is not allowed inside the
<script> tag, use a space instead as it must be a pair tag.
Additionally drop the 'type' attribute as it's not needed (validator
warns about it).
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Per the w3 HTML validator the 'lang' attribute is suggested.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Skip the XML header as it's invalid with <!DOCTYPE HTML> both for the
RST-generated pages and for the API docs generated from the API XML.
Additionally remove the spurious xsl:output directive from newapi.xsl
which is ignored and thus misleading.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Zheng Yan