- 10 9月, 2019 7 次提交
-
-
由 Laine Stump 提交于
Traditionally, macvtap devices are supported using <interface type='direct'>, but that type requires specifying a source device name and macvtap mode which can't be altered after the initial device creation (and may not even be available to the management software that's creating the XML config to feed to libvirt). But the attributes in the <source> are essentially describing how the device will be connected to the network, and if libvirt is to be supplied with the name of a macvtap device that has already been created, that device will also already be connected to the network (and the connection can't be changed). Thus it seems more appropriate to use type='ethernet', which was created explicitly for this purpose - for devices that have already been (or will be) connected to the external network by someone/something outside of libvirt. The fact that it is a *macv*tap rather than a contentional tap device is just a detail. This patch supports using an existing macvtap device with <interface type='ethernet'> by checking the supplied target dev name to see if it is a macvtap device and, when this is the case, calling virNetDevMacVLanTapOpen() instead of virNetDevTapCreate(). For consistency, this is only done when target managed='no'. 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 提交于
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>
-
由 Laine Stump 提交于
This will simplify addition of another attribute to the <target> element Signed-off-by: NLaine Stump <laine@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Laine Stump 提交于
This just moves around a few things in qemuInterfaceConnect() with no functional difference (except that a few failures that would have previously resulted in a "success" audit log will now properly produce a "fail" audit). The change is so that adding support for unmanaged tap/macvtap devices will be more easily reviewable. Signed-off-by: NLaine Stump <laine@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Laine Stump 提交于
In virNetDevMacVLanOpen(), The "retries" arg has been removed and the value hardcoded as 10, since previously the function was only called from one place, so it was always 10. Signed-off-by: NLaine Stump <laine@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Laine Stump 提交于
This function returns T if the given name is a macvtap device. This is determined by 1) getting the ifindex of the device with that name (if there is one), and 2) checking for existence of /dev/tapXX, where "XX" is the ifindex learned in (1). It's also possible to learn this by getting a netlink dump of the interface and parsing through it to look for some attributes, but that is complicated to figure out, takes longer to execute, and I'm lazy. Signed-off-by: NLaine Stump <laine@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 09 9月, 2019 15 次提交
-
-
由 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>
-
由 Eric Farman 提交于
When starting a domain, we use the presence of a vfio-pci or mdev hostdev to determine if the memlock maximum needs to be increased. But if we hotplug either of these devices, only the vfio-pci path gets that love. This means that attaching a, say, vfio-ccw device will appear to succeed but the device may be unusable as the guest may see I/O errors on long CCW chains. The host, meanwhile, would be flooded with these messages: vfio_pin_page_external: Task qemu-system-s39 (11584) RLIMIT_MEMLOCK (65536) exceeded Let's adjust the maximum memlock value in the mdev hotplug path, so that the domain has the same value as if it were started with one or more mdev devices in its configuration. Signed-off-by: NEric Farman <farman@linux.ibm.com> Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Eric Farman 提交于
If attaching a PCI hostdev fails, there are several things that need to be un-done as part of the cleanup. One thing that is not done is re-calculating/re-setting the maximum amount of locked memory for the domain, since we may have changed that. Let's fix that, just to ensure everything is back the way it was. Signed-off-by: NEric Farman <farman@linux.ibm.com> Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Eric Farman 提交于
Let's pull this hunk out into a function, so it can be reused in another codepath that needs to do the same thing. Signed-off-by: NEric Farman <farman@linux.ibm.com> Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Michal Privoznik 提交于
In f08e6883 I've made @pcidevs in virHostdevReAttachPCIDevices() to be automatically unrefed using VIR_AUTOUNREF() but I forgot to remove the line that explicitly unrefs the object at the end of the function. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Daniel P. Berrangé 提交于
We currently generate two completely separate API references for the libvirt public API. One at 'docs/html/' and one at 'docs/devhelp/'. Both are published on the website, but we only link to content in the 'docs/html/' pages. Both are installed in the libvirt-docs sub-RPM, with a full copy of the website including 'docs/html/' in /usr/share/docs/libvirt-docs, while the 'docs/devhelp/' content goes to /usr/share/gtk-doc/. The latter was broken for years until: commit ca6f6025 Author: Andrea Bolognani <abologna@redhat.com> Date: Fri May 10 14:54:52 2019 +0200 docs: Introduce $(devhelphtml_generated) Our XSLT magic generates one Devhelp-compatible HTML file per documentation module, but so far we have only shipped and installed documentation for virterror. Now that we have $(modules), however, we can generate the list of files the same way we do for regular documentation and make sure we always ship and install everything. That this bug went unnoticed for so long is a sign of how few people are using the devhelp docs. The only commits to the devhelp code since it was first introduced have been fixing various build problems that hit. The only obvious difference between the two sets of docs is the CSS styling in use. Overall devhelp does not look compelling enough to justify having two duplicated sets of API docs. Eliminating it will reduce the amount of XSL code we are carrying in the tree which is an attractive benefit. Reviewed-by: NPavel Hrdina <phrdina@redhat.com> Reviewed-by: NAndrea Bolognani <abologna@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel Henrique Barboza 提交于
After the previous commits, qemuAddSharedDevice() and qemuRemoveSharedDevice() are now the same code with a different flag to call the internal functions. This patch aggregates the common code into a new function called qemuAddRemoveSharedDeviceInternal() to further reduce code repetition. Both qemuAddSharedDevice() and qemuRemoveSharedDevice() are kept since they are public functions used elsewhere. No functional change was made. Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Daniel Henrique Barboza 提交于
Following the same idea of avoid code repetition from the previous patch, this commit introduces a new function that aggregates the functions of qemuAddSharedDisk() and qemuRemoveSharedDisk() into a single place, using a flag to switch between add/remove operations. Both qemuAddSharedDisk() and qemuRemoveSharedDisk() are public, so keep them around to avoid changing other files due to an internal qemu_conf.c refactory. No functional change was made. Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Daniel Henrique Barboza 提交于
qemuAddSharedHostdev() has a code similar to qemuRemoveSharedHostdev(), with exception of one line that defines the operation (add or remove). This patch introduces a new function that aggregates the common code, using a flag to switch between the operations, avoiding code repetition. No functional change was made. Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Jonathon Jongsma 提交于
Since commit fd9ef3b3, virDomainFindByUUIDRef() no longer exists and all virDomainObjListFindBy*() functions now increment the reference count. Signed-off-by: NJonathon Jongsma <jjongsma@redhat.com> Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
由 eater 提交于
As a result of changes in commit d5f0c1b6 Author: Daniel P. Berrangé <berrange@redhat.com> Date: Thu Jul 18 12:30:22 2019 +0100 remote: stop trying to print help as giant blocks of text The socket path built would be libvirt//var/run/libvirt-sock instead of /var/run/libvirt/libvirt-sock. Fortunately this only affects users who have set the 'unix_sock_dir' config parameter in /etc/libvirt/libvirtd.conf, which is pretty rare/unusual. Signed-off-by: Neater <=@eater.me> Exception made for the psuedonym above since patch is considered trivial & thus non-copyrightable material. Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 07 9月, 2019 3 次提交
-
-
由 Michal Privoznik 提交于
In some places where virDomainObjListForEach() is called the passed callback calls virDomainObjListRemoveLocked(). Well, this is unsafe, because the former only grabs a read lock but the latter modifies the list. I've identified the following unsafe calls: - qemuProcessReconnectAll() - libxlReconnectDomains() The rest seem to be safe. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Michal Privoznik 提交于
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Jonathon Jongsma 提交于
Apparently a copy/paste error. The net-port-delete help string was in fact from net-port-dumpxml. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1747826Signed-off-by: NJonathon Jongsma <jjongsma@redhat.com>
-
- 06 9月, 2019 15 次提交
-
-
由 Michal Privoznik 提交于
The @cmdstr variable is not used really. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
virDomainObjCheckActive() returns -1 if domain is not active, not 0. Fixes cb50436c "libxl: implement virDomainPM* functions" Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com> Signed-off-by: NMarek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
-
由 Julio Faracco 提交于
This is an issue for LXC loop devices when you are trying to get loop devices info using `ioctl`. Modern apps uses `/sys/dev/block` to grab information about devices, but if you use the method mention you won't be able to retrive the associated file with that loop device. See example below from cryptsetup sources: static char *_ioctl_backing_file(const char *loop) { struct loop_info64 lo64 = {0}; int loop_fd; loop_fd = open(loop, O_RDONLY); if (loop_fd < 0) return NULL; if (ioctl(loop_fd, LOOP_GET_STATUS64, &lo64) < 0) { close(loop_fd); return NULL; } lo64.lo_file_name[LO_NAME_SIZE-2] = '*'; lo64.lo_file_name[LO_NAME_SIZE-1] = 0; close(loop_fd); return strdup((char*)lo64.lo_file_name); } It will return an empty string because lo_file_name was not set. Function `virFileLoopDeviceOpenSearch()` is using `ioctl` to query data, but it is not checking `lo_file_name` field. Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com> Signed-off-by: NJulio Faracco <jcfaracco@gmail.com>
-
由 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 提交于
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 提交于
When the network interface is of "user" type, and QEMU has the "-net socket,fd=" datagram support, call qemuInterfacePrepareSlirp() to probe and associate a slirp-helper with the interface. The usage of automated slirp-helper can be prevented with disableSlirp (in particular when resuming a VM that didn't start with slirp-helper before). Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Marc-André Lureau 提交于
If a slirp-helper is associated with a network interface (after probing & preparing succesfully), pass the socket fd to QEMU and use "-net socket,fd=". 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 提交于
If a slirp-helper is associated with a network interface, prepare/start/stop the process via qemu-extdevice. 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 提交于
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Marc-André Lureau 提交于
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Marc-André Lureau 提交于
For VM started and migrated/saved without slirp-helpers, let's prevent the automatic setup (as it would fail to migrate otherwise). Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Marc-André Lureau 提交于
Save & restore the slirp helper PID associated with a network interface & the probed features. 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 提交于
The unit provides the functions associated with a slirp-helper: - probing / checking capabilities - opening the socketpair - starting / stoping the helper - registering for dbus-vmstate migration 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 提交于
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 提交于
A slirp helper is a process that provides user-mode networking through a unix domain socket. It is expected to follow the following specification: https://gitlab.freedesktop.org/slirp/libslirp-rs/blob/master/src/bin/README.rstSigned-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-