- 19 9月, 2019 1 次提交
-
-
由 Michal Privoznik 提交于
This reverts commit 385543a5. I've mistakenly pushed wrong branch. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 18 9月, 2019 1 次提交
-
-
由 Michal Privoznik 提交于
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 16 9月, 2019 6 次提交
-
-
由 Daniel P. Berrangé 提交于
The virIdentity getters are unusual in that they return -1 to indicate "not found" and don't report any error. Change them to return -1 for real errors, 0 for not found, and 1 for success. Reviewed-by: NMichal Privoznik <mprivozn@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
It is simpler to remove this unused method than to rewrite it using typed parameters in the next patch. Reviewed-by: NMichal Privoznik <mprivozn@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
Only expose the type safe getters/setters to other code in preparation for changing the internal storage of data. Reviewed-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NAndrea Bolognani <abologna@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NAndrea Bolognani <abologna@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
Remove the "UNIX" tag from the names for user name, group name, process ID and process time, since these attributes are all usable for non-UNIX platforms like Windows. User ID and group ID are left with a "UNIX" tag, since there's no equivalent on Windows. The closest equivalent concept on Windows, SID, is a struct containing a number of integer fields, which is commonly represented in string format instead. This would require a separate attribute, and is left for a future exercise, since the daemons are not currently built on Windows anyway. Reviewed-by: NMichal Privoznik <mprivozn@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Peter Krempa 提交于
There were accidentally two disks with 'vdc' target with corresponding blockjobs which made libvirt leak some references as there are not supposed to be two blockjobs for a single disk. Fix this mess by renaming some of the disks. In addition the block job names also didn't correspond to the naming convetion which also includes the disk target. Fix it as well. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> ACKed-by: NEric Blake <eblake@redhat.com> Reviewed-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 13 9月, 2019 2 次提交
-
-
由 Daniel P. Berrangé 提交于
The virTestOOMActive method was deleted in commit 2c52ecd9 Author: Daniel P. Berrangé <berrange@redhat.com> Date: Thu Aug 29 13:04:07 2019 +0100 util: purge all code for testing OOM handling Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
The OOM handling requires special build time options which we never enable in our CI. Even once enabled the tests are incredibly slow and typically require manual inspection of the results to weed out false positives. Since there was previous agreement to switch to abort on OOM in libvirt code, there's no point continuing to keep the unused OOM testing code. Reviewed-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 12 9月, 2019 2 次提交
-
-
由 Michal Privoznik 提交于
There is one hack hidden here, but since this is in a test, it's okay. In order to get a list of expected firmwares in virFirmwarePtr form I'm using virFirmwareParseList(). But usually, in real life scenario, this function is used only to parse a list of UEFI images which have NVRAM split out. In other words, this function expects ${FW}:${NVRAM} pairs. But in this test, we also want to allow just a single path: ${FW} because some reported firmwares are just a BIOS image really. To avoid writing some parser function, let's just pass "NULL" as ${NVRAM} and fix the result later. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NCole Robinson <crobinso@redhat.com>
-
由 Michal Privoznik 提交于
The qemuFirmwareGetSupported() function is called from qemu driver to generate domain capabilities XML based on FW descriptor files. However, the function currently reports only some features from domcapabilities XML and not actual FW image paths. The paths reported in the domcapabilities XML are still from pre-FW descriptor era and therefore the XML might be a bit confusing. For instance, it may say that secure boot is supported but secboot enabled FW is not in the listed FW image paths. To resolve this problem, change qemuFirmwareGetSupported() so that it also returns a list of FW images (we have the list anyway). Luckily, we already have a structure to represent a FW image - virFirmware. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1733940Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NCole Robinson <crobinso@redhat.com>
-
- 10 9月, 2019 5 次提交
-
-
由 Daniel P. Berrangé 提交于
The Perl bindings for libvirt use the test driver for unit tests. This tries to load the cpu_map/index.xml file, and when run from an uninstalled build will fail. The problem is that virFileActivateDirOverride is called by our various binaries like libvirtd, virsh, but is not called when a 3rd party app uses libvirt.so To deal with this we allow the LIBVIRT_DIR_OVERRIDE=1 env variable to be set and make virInitialize look for this. The 'run' script will set it, so now build using this script to run against an uninstalled tree we will correctly resolve files to the source tree. Reviewed-by: NPavel Hrdina <phrdina@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Michal Privoznik 提交于
This reverts commit 39dded7b. This commit broke virpolkittest on Ubuntu 18 which has an old dbus (v1.12.2). Any other distro with the recent one works (v1.12.16) which hints its a bug in dbus somewhere. Revert the commit to stop tickling it. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
-
由 Michal Privoznik 提交于
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
-
由 Laine Stump 提交于
If managed='no', then the tap device must already exist, and setting of MAC address and online status (IFF_UP) is skipped. NB: we still set IFF_VNET_HDR and IFF_MULTI_QUEUE as appropriate, because those bits must be properly set in the TUNSETIFF we use to set the tap device name of the handle we've opened - if IFF_VNET_HDR has not been set and we set it the request will be honored even when running libvirtd unprivileged; if IFF_MULTI_QUEUE is requested to be different than how it was created, that will result in an error from the kernel. This means that you don't need to pay attention to IFF_VNET_HDR when creating the tap devices, but you *do* need to set IFF_MULTI_QUEUE if you're going to use multiple queues for your tap device. NB2: /dev/vhost-net normally has permissions 600, so it can't be opened by an unprivileged process. This would normally cause a warning message when using a virtio net device from an unprivileged libvirtd. I've found that setting the permissions for /dev/vhost-net permits unprivileged libvirtd to use vhost-net for virtio devices, but have no idea what sort of security implications that has. I haven't changed libvrit's code to avoid *attempting* to open /dev/vhost-net - if you are concerned about the security of opening up permissions of /dev/vhost-net (probably a good idea at least until we ask someone who knows about the code) then add <driver name='qemu'/> to the interface definition and you'll avoid the warning message. Note that virNetDevTapCreate() is the correct function to call in the case of an existing device, because the same ioctl() that creates a new tap device will also open an existing tap device. Resolves: https://bugzilla.redhat.com/1723367 (partially) Signed-off-by: NLaine Stump <laine@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Laine Stump 提交于
Although <interface type='ethernet'> has always been able to use an existing tap device, this is just a coincidence due to the fact that the same ioctl is used to create a new tap device or get a handle to an existing device. Even then, once we have the handle to the device, we still insist on doing extra setup to it (setting the MAC address and IFF_UP). That *might* be okay if libvirtd is running as a privileged process, but if libvirtd is running as an unprivileged user, those attempted modifications to the tap device will fail (yes, even if the tap is set to be owned by the user running libvirtd). We could avoid this if we knew that the device already existed, but as stated above, an existing device and new device are both accessed in the same manner, and anyway, we need to preserve existing behavior for those who are already using pre-existing devices with privileged libvirtd (and allowing/expecting libvirt to configure the pre-existing device). In order to cleanly support the idea of using a pre-existing and pre-configured tap device, this patch introduces a new optional attribute "managed" for the interface <target> element. This attribute is only valid for <interface type='ethernet'> (since all other interface types have mandatory config that doesn't apply in the case where we expect the tap device to be setup before we get it). The syntax would look something like this: <interface type='ethernet'> <target dev='mytap0' managed='no'/> ... </interface> This patch just adds managed to the grammar and parser for <target>, but has no functionality behind it. (NB: when managed='no' (the default when not specified is 'yes'), the target dev is always a name explicitly provided, so we don't auto-remove it from the config just because it starts with "vnet" (VIR_NET_GENERATED_TAP_PREFIX); this makes it possible to use the same pattern of names that libvirt itself uses when it automatically creates the tap devices.) Signed-off-by: NLaine Stump <laine@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 09 9月, 2019 5 次提交
-
-
由 Shivaprasad G Bhat 提交于
There are already good number of test cases with hostdevices, few have multifunction devices but none having more than one than one multifunction cards. This patch adds a case where there are two multifunction cards and two Virtual functions part of the same XML. 0001:01:00.X & 0005:09:00.X - are Multifunction PCI cards. 0000:06:12.[5|6] - are SRIOV Virtual functions Future commits will improve on automatically detecting the multifunction cards and auto-assinging the addresses appropriately. Reviewed-by: NMichal Privoznik <mprivozn@redhat.com> Signed-off-by: NShivaprasad G Bhat <sbhat@linux.vnet.ibm.com> Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
-
由 Daniel Henrique Barboza 提交于
Previous patch had to add '/sys/kernel/' prefix in opendir() because the path, which is being mocked, wasn't being considered due to an 'if SYSFS_PCI_PREFIX' guarding the call to getrealpath(). In fact, all current getrealpath() callers are guarding it with a conditional to ensure that the function will never be called with a non-mocked path. In this case, an extra non-NULL verification is needed for the 'newpath' string to use the variable - which is counterintuitive, given that getrealpath() will always write the 'newpath' string in any non-error conditon. However, simply removing the guard of all getrealpath() instances causes an abort in init_env(). This happens because tests will execute access() to non-mocked paths even before the LIBVIRT_FAKE_ROOT_DIR variable is declared in the test files. We don't need 'fakerootdir' to be created at this point though. This patch does the following changes to simplify getrealpath() usage: - getrealpath() will now guard the init_env() call by checking if both fakeroot isn't created and the required path is being mocked. This ensures that we're not failing inside init_env() because we're too early and LIBVIRT_FAKE_ROOT_DIR wasn't defined yet; - remove all conditional guards to call getrealpath() from access(), virMockStatRedirect(), open(), open_2(), opendir() and virFileCanonicalizePath(). As a bonus, remove all ternary conditionals with 'newpath'; - a new 'pathPrefixIsMocked()' helper to aggregate all the prefixes we're mocking, making it easier to add/remove them. If a prefix is added inside this function, we can be sure that all functions are mocking them. Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Shivaprasad G Bhat 提交于
This patch adds hostdev test cases in qemuhotplugtest.c. Note: the small tweak inside virpcimock.c was needed because the new tests added a code path in which virHostHasIOMMU() (virutil.c) started being called, and the mocked '/sys/kernel/' prefix that is mocked in virpcimock.c wasn't being considered in the opendir() mock. An alternative to avoid these situations in virpcimock.c is implemented in the next patch. Reviewed-by: NMichal Privoznik <mprivozn@redhat.com> Signed-off-by: NShivaprasad G Bhat <sbhat@linux.vnet.ibm.com> Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
-
由 Shivaprasad G Bhat 提交于
The softlink to physfn is the way to know if the device is VF or not. So, the patch softlinks 'physfn' to the parent function. The multifunction PCI devices dont have 'physfn' softlinks. The patch adds few Virtual functions to the mock environment and changes the existing VFIO test xmls using the VFs to use the newly added VFs for their use case. Signed-off-by: NShivaprasad G Bhat <sbhat@linux.vnet.ibm.com> Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Daniel Henrique Barboza 提交于
This patch adds mock of the /dev/vfio path, needed for proper implementation of the support for multifunction/multiple devices per iommu groups. To do that, the existing bind and unbind operations were adapted to operate with the mocked filesystem as well. Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 06 9月, 2019 6 次提交
-
-
由 Marc-André Lureau 提交于
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Marc-André Lureau 提交于
Datagram socket is available since qemu 4.0, commit fdec16e3c2a614e2861f3086b05d444b5d8c3406 ("net/socket: learn to talk with a unix dgram socket"). Required for slirp-helper communication. Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Marc-André Lureau 提交于
dbus_message_new() does not construct correct replies by itself, it is recommended to use dbus_message_new_method_return() instead. Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Marc-André Lureau 提交于
It is failing, because it ends up being parsed with version='default' and expects '1.2' instead. Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Jonathon Jongsma 提交于
After parsing a video device with a model type of VIR_DOMAIN_VIDEO_TYPE_NONE, all device info is cleared (see virDomainDefPostParseVideo()) in order to avoid formatting any auto-generated values for the XML. Subsequently, however, an alias is generated for the video device (e.g. 'video0'), which results in an alias property being formatted in the XML output anyway. This creates confusion if the user has explicitly provided an alias for the video device since the alias will change. To avoid this, don't clear the user-defined alias for video devices of type "none". https://bugzilla.redhat.com/show_bug.cgi?id=1720612Signed-off-by: NJonathon Jongsma <jjongsma@redhat.com> Reviewed-by: NErik Skultety <eskultet@redhat.com>
-
由 Peter Krempa 提交于
Pass in backing store explicitly to qemuBlockStorageSourceGetBlockdevProps and fix the callers. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
- 04 9月, 2019 1 次提交
-
-
由 Peter Krempa 提交于
Actually test that the full range is available. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
- 29 8月, 2019 2 次提交
-
-
由 Peter Krempa 提交于
As qemu documents we should use everything in the 'props' sub-object of the data returned by query-hotpluggable-cpus. Until now we only used everything we recognized, but that may break in cases when qemu introduces new fields. This change requires a fix to the test data as some fields were reordered. https://bugzilla.redhat.com/show_bug.cgi?id=1741658Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
-
由 Jonathon Jongsma 提交于
When we're collecting guest information, older agents may not support all agent commands. In the case where the user requested all info types (i.e. types == 0), ignore unsupported command errors and gather as much information as possible. If the agent command failed for some other reason, or if the user explciitly requested a specific info type (i.e. types != 0), abort on the first error. Signed-off-by: NJonathon Jongsma <jjongsma@redhat.com> Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 28 8月, 2019 4 次提交
-
-
由 Boris Fiuczynski 提交于
Add support to specify a boot order on vfio-ccw passthrough devices. Reviewed-by: NMarc Hartmayer <mhartmay@linux.ibm.com> Signed-off-by: NBjoern Walk <bwalk@linux.ibm.com> Signed-off-by: NBoris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
由 Boris Fiuczynski 提交于
Moving the hostdev boot support validation from the command line generator code into the domain validation code. Reviewed-by: NMarc Hartmayer <mhartmay@linux.ibm.com> Signed-off-by: NBjoern Walk <bwalk@linux.ibm.com> Signed-off-by: NBoris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
由 Boris Fiuczynski 提交于
Adding a failure test for booting from a vhost scsi hostdev device. Reviewed-by: NMarc Hartmayer <mhartmay@linux.ibm.com> Signed-off-by: NBjoern Walk <bwalk@linux.ibm.com> Signed-off-by: NBoris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
由 Boris Fiuczynski 提交于
Reviewed-by: NMarc Hartmayer <mhartmay@linux.ibm.com> Signed-off-by: NBjoern Walk <bwalk@linux.ibm.com> Signed-off-by: NBoris Fiuczynski <fiuczy@linux.ibm.com> Signed-off-by: NJán Tomko <jtomko@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
- 27 8月, 2019 5 次提交
-
-
由 Michal Privoznik 提交于
If a libvirt error occurred during a test, then virTestRun() reports it (regardless of test returning success or failure). For instance, in this specific case, a hostdev is detached twice and the second attempt is expected to fail. It does fail and libvirt error is reported which is then printed onto stderr. Insert virResetLastError() calls on appropriate places to avoid that. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Michal Privoznik 提交于
There's no need to have VIR_DEBUG() really. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Michal Privoznik 提交于
The virTestRun() already reports the same. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Michal Privoznik 提交于
In this test there is this macro CHECK_LIST_COUNT() which checks if a list of PCI devices contains expected count. If it doesn't an error is reported and 'goto cleanup' is invoked. There's no real reason for that as even since its introduction there is no cleanup done and all 'cleanup' labels contain nothing but 'return'. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Michal Privoznik 提交于
There are few functions called from the test which return an integer but their retval is compared as if it was a pointer. Now, there is nothing wrong with that from machine POV, but from readability perspective it's wrong. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-