- 14 10月, 2016 2 次提交
-
-
由 Michal Privoznik 提交于
The idea is to have function that does some checking of the arguments at its beginning and then have one big switch for all the interface types it supports. Each one of them generating the corresponding part of the command line. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
The idea is to have function that does some checking of the arguments at its beginning and then have one big switch for all the interface types it supports. Each one of them generating the corresponding part of the command line. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 12 10月, 2016 7 次提交
-
-
由 Pavel Hrdina 提交于
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1369633Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
This improves commit 706b5b62 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: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
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: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
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: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
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: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
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: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
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: NPavel Hrdina <phrdina@redhat.com>
-
- 07 10月, 2016 1 次提交
-
-
由 Daniel P. Berrange 提交于
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: NDaniel P. Berrange <berrange@redhat.com>
-
- 28 9月, 2016 1 次提交
-
-
由 Jiri Denemark 提交于
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-g68c70118. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 26 9月, 2016 1 次提交
-
-
由 Michal Privoznik 提交于
We want to pass the proper opaque pointer instead of NULL to virDomainDefParse and subsequently virDomainDefParseNode too. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 22 9月, 2016 11 次提交
-
-
由 Jiri Denemark 提交于
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: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
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: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
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: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
qemu_command.c should deal with translating our domain definition into a QEMU command line and nothing else. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
qemuCaps->arch should match the guest architecture from domain XML. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
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: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
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: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
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: NJiri Denemark <jdenemar@redhat.com>
-
- 16 9月, 2016 1 次提交
-
-
由 Laszlo Ersek 提交于
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: NMarc-André Lureau <marcandre.lureau@redhat.com> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1372901Signed-off-by: NLaszlo Ersek <lersek@redhat.com> Acked-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 14 9月, 2016 1 次提交
-
-
由 Daniel P. Berrange 提交于
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: NDaniel P. Berrange <berrange@redhat.com>
-
- 09 9月, 2016 3 次提交
-
-
由 Michal Privoznik 提交于
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1366989 QEMU added another virtio-net tunable [1]. It basically allows users to set the size of RX virtio ring. But because virtio-net uses two separate ring buffers to pass data from/to guest they named it explicitly rx_queue_size. We should expose it in our XML too. 1: http://lists.nongnu.org/archive/html/qemu-devel/2016-08/msg02029.htmlSigned-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 John Ferlan 提交于
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: NJohn Ferlan <jferlan@redhat.com>
-
- 06 9月, 2016 1 次提交
-
-
由 Daniel P. Berrange 提交于
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: NDaniel P. Berrange <berrange@redhat.com>
-
- 25 8月, 2016 1 次提交
-
-
由 Peter Krempa 提交于
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.
-
- 16 8月, 2016 1 次提交
-
-
由 Ján Tomko 提交于
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
-
- 10 8月, 2016 3 次提交
-
-
由 Laine Stump 提交于
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
-
由 Laine Stump 提交于
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
-
由 Jiri Denemark 提交于
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=1355857Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 04 8月, 2016 4 次提交
-
-
由 Michal Privoznik 提交于
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: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
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: NMichal Privoznik <mprivozn@redhat.com>
-
由 Andrea Bolognani 提交于
The test case uses DO_TEST_PARSE_FLAGS_ERROR(), but doesn't pass any parse flag. Use DO_TEST_PARSE_ERROR() instead.
-
由 Andrea Bolognani 提交于
DO_TEST_FAILURE() doesn't take a GIC version, but the GIC flag was passed anyway. Get rid of all such occurrences.
-
- 27 7月, 2016 1 次提交
-
-
由 Henning Schild 提交于
Purely cosmetic change to be consistent with the other names. Signed-off-by: NHenning Schild <henning.schild@siemens.com>
-
- 21 7月, 2016 1 次提交
-
-
由 Ján Tomko 提交于
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.
-