- 22 9月, 2016 17 次提交
-
-
由 Jiri Denemark 提交于
In case a hypervisor is able to tell us a list of supported CPU models and whether each CPU models can be used on the current host, we can propagate this to domain capabilities. This is a better alternative to calling virConnectCompareCPU for each supported CPU model. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Listing all CPU models supported by QEMU in domain capabilities makes little sense when libvirt will refuse any model it doesn't know about. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
The x86 CPU driver translated each CPU definition from domain XML into CPUID data and then back to CPU definition. This effectively sorted the list of CPU features according to their CPUID values. Since this is going to change, we need to reorder CPU features in a few test files to make sure the generated QEMU command lines will not change. 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 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Changing a host architecture or a CPU is not as easy as assigning a new value to the appropriate element in virCaps since there is a relation between the CPU and host architecture (we don't really want to test anything on an AArch64 host with core2duo CPU). This patch introduces qemuTestSetHostArch and qemuTestSetHostCPU helpers which will make sure the host architecture matches the host CPU. 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>
-
由 Jiri Denemark 提交于
The patch adds <cpu> element to domain capabilities XML: <cpu> <mode name='host-passthrough' supported='yes'/> <mode name='host-model' supported='yes'/> <mode name='custom' supported='yes'> <model>Broadwell</model> <model>Broadwell-noTSX</model> ... </mode> </cpu> Applications can use it to inspect what CPU configuration modes are supported for a specific combination of domain type, emulator binary, guest architecture and machine type. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 20 9月, 2016 3 次提交
-
-
由 Martin Kletzander 提交于
Always format id first so that we don't need to do that twice in different code paths. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Pavel Hrdina 提交于
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Laine Stump 提交于
Commit 85635600 switched from hardcoded use of strcontent to hardcoded use of fixedcontent (fixedcontent is *sometimes* a copy of strcontent with a \n appended). This was a problem because sometimes fixedcontent is *not* a copy of strcontent, but is instead NULL, leading to the regenerated test case output being a 0 length file. This patch creates a new const char *cmpcontent initialized to strcontent, but changed to fixedcontent if/when fixedcontent is created, then always uses cmpcontent instead of (str|fixed)content.
-
- 16 9月, 2016 2 次提交
-
-
由 Martin Kletzander 提交于
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 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>
-
- 15 9月, 2016 1 次提交
-
-
由 Martin Kletzander 提交于
Commit ca329299 added function virTestCompareToFile(), but forgot to use a fixedcontent value for the actual comparison. That lead to VIR_TEST_DEBUG=1 showing (for some tests) all the actual output from the first error to the end of the string due to the difference being an endline in the end. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 14 9月, 2016 3 次提交
-
-
由 Michal Privoznik 提交于
Just like we are running 'virsh self-test' from within our test suite, we should run 'virt-admin self-test' too. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Peter Krempa 提交于
Return whether a vcpu entry is hotpluggable or online so that upper layers don't have to infer the information from other data. Advantage is that this code can be tested by unit tests.
-
由 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>
-
- 13 9月, 2016 1 次提交
-
-
由 Erik Skultety 提交于
The virsh-self-test script compared the test's return code with 1 and only if the return code matched this value then the test was marked as failed. Problem is that SIGSEGV returns 139 (or 11 to be precise, since shell reserves the MSB for abnormal exit signaling) which passes the check just fine and test then appears as successful which it most certainly wasn't. Therefore, flip the logic to compare against 0 instead and every other result will be treated as a failed test case. Signed-off-by: NErik Skultety <eskultet@redhat.com>
-
- 09 9月, 2016 5 次提交
-
-
由 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 提交于
Add a new secret usage type known as "tls" - it will handle adding the secret objects for various TLS objects that need to provide some sort of passphrase in order to access the credentials. The format is: <secret ephemeral='no' private='no'> <description>Sample TLS secret</description> <usage type='tls'> <name>mumblyfratz</name> </usage> </secret> Once defined and a passphrase set, future patches will allow the UUID to be set in the qemu.conf file and thus used as a secret for various TLS options such as a chardev serial TCP connection, a NBD client/server connection, and migration. Signed-off-by: NJohn Ferlan <jferlan@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>
-
由 John Ferlan 提交于
Add a new TLS X.509 certificate type - "chardev". This will handle the creation of a TLS certificate capability (and possibly repository) for properly configured character device TCP backends. Unlike the vnc and spice there is no "listen" or "passwd" associated. The credentials eventually will be handled via a libvirt secret provided to a specific backend. Make use of the default verify option as well. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
- 06 9月, 2016 4 次提交
-
-
由 Daniel P. Berrange 提交于
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 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>
-
由 Peter Krempa 提交于
RBD in qemu still uses only the legacy 'filename' syntax. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1371758
-
由 Peter Krempa 提交于
Commit 2ed772cd forgot to set proper protocol. This was also present in the test data. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1372251
-
- 03 9月, 2016 3 次提交
-
-
由 Qiaowei Ren 提交于
With current perf framework, this patch adds support and documentation for more perf events, including cache misses, cache references, cpu cycles, and instructions. Signed-off-by: NQiaowei Ren <qiaowei.ren@intel.com>
-
由 Bob Liu 提交于
xen-xm doesn't support mult serial devices at all, so these tests are meaningless. Signed-off-by: NBob Liu <bob.liu@oracle.com>
-
由 Bob Liu 提交于
Adding tests for domXML <-> xl.cfg conversions containing multiple serial devices. Signed-off-by: NBob Liu <bob.liu@oracle.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.
-