This improves commit 706b5b6277 in a way that we check qemu capabilities
instead of what architecture we are running on to detect whether we can
use *virtio-vga* model or not. This is not a case only for arm/aarch64.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Before this patch we've checked qemu capabilities for video devices
only while constructing qemu command line using "-device" option.
Since we support qemu only if "-device" option is present we can use
the same capabilities to check also video devices while using "-vga"
option to construct qemu command line.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
We generally uses QEMU_CAPS_DEVICE_$NAME to probe for existence of some
device and QEMU_CAPS_$NAME_$PROP to probe for existence of some property
of that device.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
If QEMU in question supports QMP, this capability is set if
QEMU_CAPS_DEVICE_QXL was set based on existence of "-device qxl". If
libvirt needs to parse *help*, because there is no QMP support, it
checks for existence of "-vga qxl", but it also parses output of
"-device ?" and sets QEMU_CAPS_DEVICE_QXL too.
Now that libvirt supports only QEMU that has "-device" implemented it's
safe to drop this capability and stop using it.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
This patch simplifies QEMU capabilities for QXL video device. QEMU
exposes this device as *qxl-vga* and *qxl* and they are both the same
device with the same set of parameters, the only difference is that
*qxl-vga* includes VGA compatibility.
Based on QEMU code they are tied together so it's safe to check only for
presence of only one of them.
This patch also removes an invalid test case "video-qxl-sec-nodevice"
where there is only *qxl-vga* device and *qxl* device is not present.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
If one of QEMU_CAPS_DEVICE_QXL_VGA or QEMU_CAPS_DEVICE_QXL is set the
other one will always be set as well because both devices are tied
together in QEMU.
The change of args files is caused by the presence of capability
QEMU_CAPS_DEVICE_VIDEO_PRIMARY which means it's safe to use
"-device qxl-vga" instead of "-vga qxl", see commit (e3f2686b) and
by the fact that if QEMU_CAPS_VGA_QXL is set QEMU_CAPS_DEVICE_QXL_VGA
and QEMU_CAPS_DEVICE_QXL would be set too (since we support only qemu
with "-device" option).
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
The intel-iommu device has existed since QEMU 2.2.0, but
it was only possible to create it with -device since
QEMU 2.7.0, thanks to:
commit 621d983a1f9051f4cfc3f402569b46b77d8449fc
Author: Marcel Apfelbaum <marcel@redhat.com>
Date: Mon Jun 27 18:38:34 2016 +0300
hw/iommu: enable iommu with -device
Use the standard '-device intel-iommu' to create the IOMMU device.
The legacy '-machine,iommu=on' can still be used.
The libvirt capability check & command line formatting code
is thus broken for all QEMU versions 2.2.0 -> 2.6.0 inclusive.
This fixes it to use iommu=on instead.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
The qemucapsprobe helper calls virQEMUCapsNewForBinaryInternal with
caps == NULL, causing the following crash:
Program received signal SIGSEGV, Segmentation fault.
#0 0x00007ffff788775f in virQEMUCapsInitHostCPUModel
(qemuCaps=qemuCaps@entry=0x649680, host=host@entry=0x10) at
src/qemu/qemu_capabilities.c:2969
#1 0x00007ffff7889dbf in virQEMUCapsNewForBinaryInternal
(caps=caps@entry=0x0, binary=<optimized out>,
libDir=libDir@entry=0x4033f6 "/tmp", cacheDir=cacheDir@entry=0x0,
runUid=runUid@entry=4294967295, runGid=runGid@entry=4294967295,
qmpOnly=true) at src/qemu/qemu_capabilities.c:4039
#2 0x0000000000401702 in main (argc=2, argv=0x7fffffffd968) at
tests/qemucapsprobe.c:73
Caused by v2.2.0-182-g68c7011.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
We want to pass the proper opaque pointer instead of NULL to
virDomainDefParse and subsequently virDomainDefParseNode too.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Host capabilities provide libvirt's view of the host CPU, but for a
useful support for host-model CPUs we really need a hypervisor's view of
the CPU. And since the view can be differ with emulator, qemu
capabilities is the best place to store the host CPU model.
This patch just copies the CPU model from host capabilities, but this
will change in the future.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Testing PPC64/AArch64 KVM domains on x86_64 host only works because we
have a lot of bugs in our code. Since this series is going to fix them,
we need to make sure the host architecture matches guest for KVM
domains.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Adding x86 CPU models into a list of supported CPUs for non-x86
architectures is not a very good idea. Each architecture we test needs
to maintain its own list of supported CPU models.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
qemu_command.c should deal with translating our domain definition into a
QEMU command line and nothing else.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Some parts of qemuCaps depend on guest architecture, machine type, and
possibly other things that we know only once the domain XML has been
parsed. Let's move all these updates into a dedicated function.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
testCompareXMLToArgv will soon need to call a few function which are
defined further in the code. Let's move them up a bit.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
The list of supported CPU models in domain capabilities is stored in
virDomainCapsCPUModels. Let's use the same object for storing CPU models
in QEMU capabilities.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Most of QEMU's PCI display device models, such as:
libvirt video/model/@type QEMU -device
------------------------- ------------
cirrus cirrus-vga
vga VGA
qxl qxl-vga
virtio virtio-vga
come with a linear framebuffer (sometimes called "VGA compatibility
framebuffer"). This linear framebuffer lives in one of the PCI device's
MMIO BARs, and allows guest code (primarily: firmware drivers, and
non-accelerated OS drivers) to display graphics with direct memory access.
Due to architectural reasons on aarch64/KVM hosts, this kind of
framebuffer doesn't / can't work in
qemu-system-(arm|aarch64) -M virt
machines. Cache coherency issues guarantee a corrupted / unusable display.
The problem has been researched by several people, including kvm-arm
maintainers, and it's been decided that the best way (practically the only
way) to have boot time graphics for such guests is to consolidate on
QEMU's "virtio-gpu-pci" device.
>From <https://bugzilla.redhat.com/show_bug.cgi?id=1195176>, libvirt
supports
<devices>
<video>
<model type='virtio'/>
</video>
</devices>
but libvirt unconditionally maps @type='virtio' to QEMU's "virtio-vga"
device model. (See the qemuBuildDeviceVideoStr() function and the
"qemuDeviceVideo" enum impl.)
According to the above, this is not right for the "virt" machine type; the
qemu-system-(arm|aarch64) binaries don't even recognize the "virtio-vga"
device model (justifiedly). Whereas "virtio-gpu-pci", which is a pure
virtio device without a compatibility framebuffer, is available, and works
fine.
(The ArmVirtQemu ("AAVMF") platform of edk2 -- that is, the UEFI firmware
for "virt" -- supports "virtio-gpu-pci", as of upstream commit
3ef3209d3028. See
<https://tianocore.acgmultimedia.com/show_bug.cgi?id=66>.)
Override the default mapping of "virtio", from "virtio-vga" to
"virtio-gpu-pci", if qemuDomainMachineIsVirt() evaluates to true.
Cc: Andrea Bolognani <abologna@redhat.com>
Cc: Drew Jones <drjones@redhat.com>
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Cc: Martin Kletzander <mkletzan@redhat.com>
Suggested-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1372901
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Martin Kletzander <mkletzan@redhat.com>
The test qemuxml2argv-serial-tcp-tlsx509-chardev.args
will fail if libvirt is built with a --sysconfdir
arg that is not /etc. Fix this by setting a hardcoded
path in the test code.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
When building a chardev device string for tcp, add the necessary pieces to
access provide the TLS X.509 path to qemu. This includes generating the
'tls-creds-x509' object and then adding the 'tls-creds' parameter to the
VIR_DOMAIN_CHR_TYPE_TCP command line.
Finally add the tests for the qemu command line. This test will make use
of the "new(ish)" /etc/pki/qemu setting for a TLS certificate environment
by *not* "resetting" the chardevTLSx509certdir prior to running the test.
Also use the default "verify" option (which is "no").
Signed-off-by: John Ferlan <jferlan@redhat.com>
We already have the ability to turn off dumping of guest
RAM via the domain XML. This is not particularly useful
though, as it is under control of the management application.
What is needed is a way for the sysadmin to turn off guest
RAM defaults globally, regardless of whether the mgmt app
provides its own way to set this in the domain XML.
So this adds a 'dump_guest_core' option in /etc/libvirt/qemu.conf
which defaults to false. ie guest RAM will never be included in
the QEMU core dumps by default. This default is different from
historical practice, but is considered to be more suitable as
a default because
a) guest RAM can be huge and so inflicts a DOS on the host
I/O subsystem when dumping core for QEMU crashes
b) guest RAM can contain alot of sensitive data belonging
to the VM owner. This should not generally be copied
around inside QEMU core dumps submitted to vendors for
debugging
c) guest RAM contents are rarely useful in diagnosing
QEMU crashes
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Add support for using the new approach to hotplug vcpus using device_add
during startup of qemu to allow sparse vcpu topologies.
There are a few limitations imposed by qemu on the supported
configuration:
- vcpu0 needs to be always present and not hotpluggable
- non-hotpluggable cpus need to be ordered at the beginning
- order of the vcpus needs to be unique for every single hotpluggable
entity
Qemu also doesn't really allow to query the information necessary to
start a VM with the vcpus directly on the commandline. Fortunately they
can be hotplugged during startup.
The new hotplug code uses the following approach:
- non-hotpluggable vcpus are counted and put to the -smp option
- qemu is started
- qemu is queried for the necessary information
- the configuration is checked
- the hotpluggable vcpus are hotplugged
- vcpus are started
This patch adds a lot of checking code and enables the support to
specify the individual vcpu element with qemu.
If any of the devices referenced a USB hub that does not exist,
defining the domain would either fail with:
error: An error occurred, but the cause is unknown
(if only the last hub in the path is missing)
or crash.
Return a proper error instead of crashing.
https://bugzilla.redhat.com/show_bug.cgi?id=1367130
More misunderstanding/mistaken assumptions on my part - I had thought
that a pci-expander-bus could be plugged into any legacy PCI slot, and
that pcie-expander-bus could be plugged into any PCIe slot. This isn't
correct - they can both be plugged ontly into their respective root
buses. This patch adds that restriction.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1358712
libvirt had allowed a dmi-to-pci-bridge to be plugged in anywhere a
normal PCIe endpoint can be connected, but this is wrong - it will
only work if it's plugged into pcie-root (the PCIe root complex) or a
pcie-expander-bus (the qemu device pxb-pcie). This patch adjusts the
connection flags accordingly.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1363648
The generated command line wouldn't work since QEMU doesn't know what
'cmt' is. The following patch will fix this issue.
https://bugzilla.redhat.com/show_bug.cgi?id=1355857
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
In qemu, enabling this feature boils down to adding the following
onto the command line:
-global driver=cfi.pflash01,property=secure,value=on
However, there are some constraints resulting from the
implementation. For instance, System Management Mode (SMM) is
required to be enabled, the machine type must be q35-2.4 or
later, and the guest should be x86_64. While technically it is
possible to have 32 bit guests with secure boot, some non-trivial
CPU flags tuning is required (for instance lm and nx flags must
be prohibited). Given complexity of our CPU driver, this is not
trivial. Therefore I've chosen to forbid 32 bit guests for now.
If there's ever need, we can refine the check later.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Since its release of 2.4.0 qemu is able to enable System
Management Module in the firmware, or disable it. We should
expose this capability in the XML. Unfortunately, there's no good
way to determine whether the binary we are talking to supports
it. I mean, if qemu's run with real machine type, the smm
attribute can be seen in 'qom-list /machine' output. But it's not
there when qemu's run with -M none. Therefore we're stuck with
version based check.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
When parsing a command line with USB devices that have
no address specified, QEMU automatically adds a USB hub
if the device would fill up all the available USB ports.
To help most of the users, add one hub if there are more
USB devices than available ports. For wilder configurations,
expect the user to provide us with more hubs and/or controllers.
Resolves a CI test integration failure with a RHEL6/Centos6 environment.
In order to use a LUKS encrypted device, the design decision was to
generate an encrypted secret based on the master key. However, commit
id 'da86c6c' missed checking for that specifically.
When qemuDomainSecretSetup was implemented, a design decision was made
to "fall back" to a plain text secret setup if the specific cipher was
not available (e.g. virCryptoHaveCipher(VIR_CRYPTO_CIPHER_AES256CBC))
as well as the QEMU_CAPS_OBJECT_SECRET. For the luks encryption setup
there is no fall back to the plaintext secret, thus if that gets set
up by qemuDomainSecretSetup, then we need to fail.
Also, while the qemuxml2argvtest has set the QEMU_CAPS_OBJECT_SECRET
bit, it didn't take into account the second requirement that the
ability to generate the encrypted secret is possible. So modify the
test to not attempt to run the luks-disk if we know we don't have
the encryption algorithm.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1301021
Generate the luks command line using the AES secret key to encrypt the
luks secret. A luks secret object will be in addition to a an AES secret.
For hotplug, check if the encinfo exists and if so, add the AES secret
for the passphrase for the secret object used to decrypt the device.
Modify/augment the fakeSecret* in qemuxml2argvtest in order to handle
find a uuid or a volume usage with a specific path prefix in the XML
(corresponds to the already generated XML tests). Add error message
when the 'usageID' is not 'mycluster_myname'. Commit id '1d632c39'
altered the error message generation to rely on the errors from the
secret_driver (or it's faked replacement).
Add the .args output for adding the LUKS disk to the domain
Signed-off-by: John Ferlan <jferlan@redhat.com>
We were requiring a USB port path in the schema, but not enforcing it.
Omitting the USB port would lead to libvirt formatting it as (null).
Such domain cannot be started and will disappear after libvirtd restart
(since it cannot parse back the XML).
Only format the port if it has been specified and mark it as optional
in the XML schema.
It's just test, but why leak it?
==26971== 20 bytes in 1 blocks are definitely lost in loss record 623 of 704
==26971== at 0x4C29F80: malloc (vg_replace_malloc.c:296)
==26971== by 0xE560447: vasprintf (vasprintf.c:76)
==26971== by 0xAE0DEE2: virVasprintfInternal (virstring.c:480)
==26971== by 0xAE0DFF7: virAsprintfInternal (virstring.c:501)
==26971== by 0x4751F3: qemuProcessPrepareMonitorChr (qemu_process.c:2651)
==26971== by 0x4334B1: testCompareXMLToArgvFiles (qemuxml2argvtest.c:297)
==26971== by 0x4339AC: testCompareXMLToArgvHelper (qemuxml2argvtest.c:413)
==26971== by 0x446E7A: virTestRun (testutils.c:179)
==26971== by 0x445D33: mymain (qemuxml2argvtest.c:2029)
==26971== by 0x44886F: virTestMain (testutils.c:969)
==26971== by 0x445D9B: main (qemuxml2argvtest.c:2036)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
This is preferrable to -nographic which (in addition to disabling
graphics output) redirects the serial port to stdio and on OpenBIOS
enables the firmware's serial console.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
For type='ethernet' interfaces only.
(This patch had been pushed earlier in
commit 0b4645a7e0, but was reverted in
commit 84d47a3cce because it had been
accidentally pushed during the freeze for release 2.0.0)
In order to use more common code and set up for a future type, modify the
encryption secret to allow the "usage" attribute or the "uuid" attribute
to define the secret. The "usage" in the case of a volume secret would be
the path to the volume as dictated by the backwards compatibility brought
on by virStorageGenerateQcowEncryption where it set up the usage field as
the vol->target.path and didn't allow someone to provide it. This carries
into virSecretObjListFindByUsageLocked which takes the secret usage attribute
value from from the domain disk definition and compares it against the
usage type from the secret definition. Since none of the code dealing
with qcow/qcow2 encryption secrets uses usage for lookup, it's a mostly
cosmetic change. The real usage comes in a future path where the encryption
is expanded to be a luks volume and the secret will allow definition of
the usage field.
This code will make use of the virSecretLookup{Parse|Format}Secret common code.
Signed-off-by: John Ferlan <jferlan@redhat.com>
I'm not sure why our code claimed "-boot menu=on" cannot be used in
combination with per-device bootindex, but it was proved wrong about
four years ago by commit 8c952908. Let's always use bootindex when QEMU
supports it.
https://bugzilla.redhat.com/show_bug.cgi?id=1323085
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
