- 12 7月, 2016 24 次提交
-
-
由 Ján Tomko 提交于
Check whether QEMU supports -device intel-iommu Note that the presence of this option does not mean that it's usable because of a bug in earlier QEMU versions, but it's better than nothing. https://bugzilla.redhat.com/show_bug.cgi?id=1235580
-
由 Ján Tomko 提交于
A device with an attribute 'model', with just one model so far: <devices> ... <iommu model='intel'/> </devices> https://bugzilla.redhat.com/show_bug.cgi?id=1235580
-
由 Ján Tomko 提交于
For every but the last argument, we also need space for a space and a backslash. Rewrap everything longer than 78 characters.
-
由 Ján Tomko 提交于
Commit c9c03ea2 stopped creating an intermediate file during syntax-check to save on execution time. It also switched to outputting the whole incorrectly wrapped file instead of a diff needed to fix it. Feed the newly wrapped file to diff via a pipe. Note that fixing it by running test-wrap-argv.pl --in-place or the unit test with VIR_TEST_REGENERATE_OUTPUT is easier.
-
由 Ján Tomko 提交于
test-wrap-argv.pl does not know how to rewrap other files.
-
由 Ján Tomko 提交于
Commit 843a70a8 changed test-wrap-argv.pl to use /usr/bin/env perl instead of /usr/bin/perl However when called from qemuxml2argvtest with VIR_TEST_REGENERATE_OUTPUT, PATH is set to '/bin'. Find the path to perl early in virTestMain, in case we are going to need it later after we've overridden PATH.
-
由 Luyao Huang 提交于
In commit ec5dcf2a and b0b4a35c we have moved qemuhotplugtest's XMLs to new directories but forgot to fix the Makefile. Add 2 directories in EXTRA_DIST to fix broken VPATH build. Also remove now unused qemuhotplugtestdata directory from the Makefile as well as from the tree. Signed-off-by: NLuyao Huang <lhuang@redhat.com> Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Daniel P. Berrange 提交于
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
The libvirtdconftest was previously used to test data type handling of the libvirtd config file. Now we're using the typedef APIs, this test case has little value, and is pretty hard to fixup with deal with the new APIs. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
Currently many users of virConf APIs are defining the same macros for calling virConfValue() and then doing type checking. To remove this repeated code, add a set of typesafe accessor methods. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
If the config file does not end with a \n, the parser will append one. When re-allocating the array though, it is mistakenly assuming that 'len' is the length including the trailing NUL, but it does not. So we must add 2 to len, when reallocating, not 1. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
The virconftest is different from all our other tests in that the C program only tests a single in/out config file pair. It relies on a shell wrapper to invoke it once for each test file. This gets rid of the shell wrapper and makes the C program actually run over each test file using the normal test pattern. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 11 7月, 2016 16 次提交
-
-
由 Tomasz Flendrich 提交于
This way we can safely differentiate what XMLs contain whole domain definitions and which contain just devices. Thanks to that we can test the domain XMLs in virschematest again. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Tomasz Flendrich 提交于
This makes the search for related XMLs easier, plus they are not used in the xml2argv tests anyway. This also makes future patches cleaner. While on that remove unnecessary '-hotplug' from the filenames. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Michal Privoznik 提交于
In the mock, we have a stub for virNetDevTapCreate(). However, the mocked version does not exactly as it's native counterpart. The function receives a string, which is an interface name that caller would like to have, but it's not guaranteed that they will get just that one. If they don't, the function free()-s the one passed and returns the new one. Just like the mocked version. But what is the mocked version missing is the free(). ==1068== 6 bytes in 1 blocks are definitely lost in loss record 9 of 132 ==1068== at 0x4C29F80: malloc (vg_replace_malloc.c:296) ==1068== by 0xDE13356: xmlStrndup (in /usr/lib64/libxml2.so.2.9.4) ==1068== by 0xAE2333E: virXMLPropString (virxml.c:479) ==1068== by 0xAE45975: virDomainNetDefParseXML (domain_conf.c:9038) ==1068== by 0xAE5C0BB: virDomainDefParseXML (domain_conf.c:16734) ==1068== by 0xAE5EB96: virDomainDefParseNode (domain_conf.c:17444) ==1068== by 0xAE5EA05: virDomainDefParse (domain_conf.c:17391) ==1068== by 0xAE5EA93: virDomainDefParseFile (domain_conf.c:17415) ==1068== by 0x433430: testCompareXMLToArgvFiles (qemuxml2argvtest.c:278) ==1068== by 0x433A18: testCompareXMLToArgvHelper (qemuxml2argvtest.c:414) ==1068== by 0x446ED4: virTestRun (testutils.c:179) ==1068== by 0x43A099: mymain (qemuxml2argvtest.c:1016) Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
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: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
This one's a bit more complicated. In qemuProcessPrepareDomain() a master key for encrypting secret for ciphered disks is created. This object lives within qemuDomainObjPrivate object. It is freed in qemuProcessStop(), but if nobody calls it (for instance like our qemuxml2argvtest does), the key object leaks. ==17078== 32 bytes in 1 blocks are definitely lost in loss record 633 of 707 ==17078== at 0x4C2C070: calloc (vg_replace_malloc.c:623) ==17078== by 0xAD924DF: virAllocN (viralloc.c:191) ==17078== by 0x5050BA6: virCryptoGenerateRandom (qemuxml2argvmock.c:166) ==17078== by 0x453DC8: qemuDomainMasterKeyCreate (qemu_domain.c:678) ==17078== by 0x47A36B: qemuProcessPrepareDomain (qemu_process.c:4913) ==17078== by 0x47C728: qemuProcessCreatePretendCmd (qemu_process.c:5542) ==17078== by 0x433698: testCompareXMLToArgvFiles (qemuxml2argvtest.c:332) ==17078== by 0x4339AC: testCompareXMLToArgvHelper (qemuxml2argvtest.c:413) ==17078== by 0x446E7A: virTestRun (testutils.c:179) ==17078== by 0x445BD9: mymain (qemuxml2argvtest.c:2022) ==17078== by 0x44886F: virTestMain (testutils.c:969) ==17078== by 0x445D9B: main (qemuxml2argvtest.c:2036) Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Just like every other qemuBuild*CommandLine() function, this uses a buffer to hold partial cmd line strings too. However, if there's an error, the control jumps to 'cleanup' label leaving the buffer behind and thus leaking it. ==2013== 1,006 bytes in 1 blocks are definitely lost in loss record 701 of 711 ==2013== at 0x4C29F80: malloc (vg_replace_malloc.c:296) ==2013== by 0x4C2C32F: realloc (vg_replace_malloc.c:692) ==2013== by 0xAD925A8: virReallocN (viralloc.c:245) ==2013== by 0xAD95EA8: virBufferGrow (virbuffer.c:130) ==2013== by 0xAD95F78: virBufferAdd (virbuffer.c:165) ==2013== by 0x5097F5: qemuBuildCpuModelArgStr (qemu_command.c:6339) ==2013== by 0x509CC3: qemuBuildCpuCommandLine (qemu_command.c:6437) ==2013== by 0x51142C: qemuBuildCommandLine (qemu_command.c:9174) ==2013== by 0x47CA3A: qemuProcessCreatePretendCmd (qemu_process.c:5546) ==2013== by 0x433698: testCompareXMLToArgvFiles (qemuxml2argvtest.c:332) ==2013== by 0x4339AC: testCompareXMLToArgvHelper (qemuxml2argvtest.c:413) ==2013== by 0x446E7A: virTestRun (testutils.c:179) Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
When storage secret is parsed in virStorageEncryptionSecretParse(), virSecretLookupParseSecret() which allocates some memory. This is however never freed. ==21711== 134 bytes in 6 blocks are definitely lost in loss record 70 of 85 ==21711== at 0x4C29F80: malloc (vg_replace_malloc.c:296) ==21711== by 0xBCA0356: xmlStrndup (in /usr/lib64/libxml2.so.2.9.4) ==21711== by 0xA9F432E: virXMLPropString (virxml.c:479) ==21711== by 0xA9D25B0: virSecretLookupParseSecret (virsecret.c:70) ==21711== by 0xA9D616E: virStorageEncryptionSecretParse (virstorageencryption.c:172) ==21711== by 0xA9D66B2: virStorageEncryptionParseXML (virstorageencryption.c:281) ==21711== by 0xA9D68DF: virStorageEncryptionParseNode (virstorageencryption.c:338) ==21711== by 0xAA12575: virDomainDiskDefParseXML (domain_conf.c:7606) ==21711== by 0xAA2CAC6: virDomainDefParseXML (domain_conf.c:16658) ==21711== by 0xAA2FC75: virDomainDefParseNode (domain_conf.c:17472) ==21711== by 0xAA2FAE4: virDomainDefParse (domain_conf.c:17419) ==21711== by 0xAA2FB72: virDomainDefParseFile (domain_conf.c:17443) Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Chen Hanxiao 提交于
#virsh list --uuid --name 49c765a0-25e7-40d0-964f-dac99724b32c c7 918f1dd6-b19f-412b-ba17-d113bad89af8 f23 Signed-off-by: NChen Hanxiao <chenhanxiao@gmail.com>
-
由 Martin Kletzander 提交于
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Martin Kletzander 提交于
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Martin Kletzander 提交于
Setting up cgroups and other things for all kinds of threads (the emulator thread, vCPU threads, I/O threads) was copy-pasted every time new thing was added. Over time each one of those functions changed a bit differently. So create one function that does all that setup and start using it, starting with I/O thread setup. That will shave some duplicated code and maybe fix some bugs as well. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Daniel P. Berrange 提交于
The code in qemuDomainObjPrivateXMLParseVcpu for parsing the 'idstr' string was comparing the overall boolean result against 0 which was always true qemu/qemu_domain.c: In function 'qemuDomainObjPrivateXMLParseVcpu': qemu/qemu_domain.c:1482:59: error: comparison of constant '0' with boolean expression is always false [-Werror=bool-compare] if ((idstr && virStrToLong_uip(idstr, NULL, 10, &idx)) < 0 || ^ It was further performing two distinct error checks in the same conditional and reporting a single error message, which was misleading in one of the two cases. This splits the conditional check into two parts with distinct error messages and fixes the logic error. Fixes the bug in commit 5184f398 Author: Peter Krempa <pkrempa@redhat.com> Date: Fri Jul 1 14:56:14 2016 +0200 qemu: Store vCPU thread ids in vcpu private data objects Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Andrea Bolognani 提交于
An error in virHostCPUGetKVMMaxVCPUs() means we've been unable to access /dev/kvm, or we're running on a platform that doesn't support KVM in the first place. If that's the case, we shouldn't ignore the error and report domcapabilities even though we know the user won't be able to start any KVM guest.
-
由 Andrea Bolognani 提交于
All Linux releases we support (RHEL6 era) include these definitions.
-
由 Andrea Bolognani 提交于
If we don't HAVE_LINUX_KVM_H, we can't query /dev/kvm to discover the limits on the number of vCPUs, so we report an error and return a negative value instead.
-
由 Peter Krempa 提交于
Rather than storing them in an external array store them directly.
-