- 17 8月, 2017 2 次提交
-
-
由 John Ferlan 提交于
Use @obj for a virNetworkObjPtr Use @net for a virNetworkPtr Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Alter prototypes to utilize some more recent guidelines. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
- 16 8月, 2017 2 次提交
-
-
由 Michal Privoznik 提交于
Since its introduction in f6134117 it was never implemented nor there are plans to implement it. Drop it. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 John Ferlan 提交于
If an environment specific _tls_x509_cert_dir is provided, then do not VIR_STRDUP the defaultTLSx509secretUUID as that would be for the "default" environment and not the vnc, spice, chardev, or migrate environments. If the environment needs a secret to decode it's certificate, then it must provide the secret. If the secrets happen to be the same, then configuration would use the same UUID as the default (but we cannot assume that nor can we assume that the secret would be necessary).
-
- 15 8月, 2017 10 次提交
-
-
由 John Ferlan 提交于
Rather than assuming that what's passed to virObject{Ref|Unref} would be a virObjectPtr as long as it's not NULL, let's do the similar checks virObjectIsClass in order to prevent a possible increment or decrement to some field at the obj->u.s.refs offset. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
The virObjectIsClass API has only ever checked object validity based on if the @obj is not NULL and it was derived from some class. While this has worked well in general, there is one additional check that could be made prior to calling virClassIsDerivedFrom which loops through the classes checking the magic number against the klass expected magic number. If by chance a non virObject is passed, rather than assuming the void * @obj is a _virObject and thus offsetting to obj->klass, obj->magic, and obj->parent, let's check that the void * @obj has at least the "base part" of the magic number in the right place and generate a more specific VIR_WARN message if not. There are many consumers to virObjectIsClass, include the locking primitives virObject{Lock|Unlock}, virObjectRWLock{Read|Write}, and virObjectRWUnlock. For those callers, the locking call will not fail, but it also will not attempt a virMutex* call which will "most likely" fail since the &obj->lock is used. In order to avoid some possible future wrap on the 0xCAFExxxx value, add a check during initialization that some new class won't cause the wrap. Should be good for a few years at least! It is still left up to the caller to handle the failed API calls just as it would be if it passed a NULL opaque pointer anyobj.
-
由 John Ferlan 提交于
If virObjectIsClass fails "internally" to virobject.c, create a macro to generate the VIR_WARN describing what the problem is. Also improve the checks and message a bit to indicate which was the failure - whether the obj was NULL or just not the right class Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Rather than overload virObjectUnlock as commit id '77f4593b' has done, create a separate virObjectRWUnlock API that will force the consumers to make the proper decision regarding unlocking the RWLock's. Similar to the RWLockRead and RWLockWrite, use the virObjectGetRWLockableObj helper. This restores the virObjectUnlock code to using the virObjectGetLockableObj. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Introduce a helper to handle the error path more cleanly. The same as virObjectGetLockableObj in order to essentially follow the original logic of commit 'b545f65d' to ensure that the input argument at least has some validity before using. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Now that virObjectRWLockWrite exists to handle the virObjectRWLockable objects, let's restore virObjectLock to only handle virObjectLockable class locks. There still exists the possibility that the input @anyobj isn't a valid object and the resource isn't truly locked, but that also exists before commit id '77f4593b'. This also restores some logic that commit id '77f4593b' removed with respect to a common code path that commit id '10c2bb2b' had introduced as virObjectGetLockableObj. This code path merely does the same checks as the original virObjectLock commit 'b545f65d', but in callable/reusable helper to ensure the @obj at least has some validity before using. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Instead of making virObjectLock be the entry point for two different types of locks, let's create a virObjectRWLockWrite API which will only handle the virObjectRWLockableClass objects. Use the new virObjectRWLockWrite for the virdomainobjlist code in order to handle the Add, Remove, Rename, and Load operations that need to be very synchronous. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Since the class it represents is based on virObjectRWLockableClass and in order to make sure we differentiate just in case anyone somehow believes they could use virObjectLockRead for a virObjectLockableClass, let's rename the API to use the RW in the name. Besides the RW locks refer to pthread_rwlock_{init|rdlock|wrlock|unlock|destroy} while the other locks refer to pthread_mutex_{init|lock|unlock|destroy}. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Pavel Hrdina 提交于
The correct lock order is: nwfilter driver lock (not used in this code path) nwfilter update lock virt driver lock (not used in this code path) domain object lock but the current code have this order: domain object lock nwfilter update lock Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Introduced by commit <41127244>. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
- 14 8月, 2017 16 次提交
-
-
由 Pavel Hrdina 提交于
XPath is good for random search of elements, not for accessing attributes of one node. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
XPath is good for random search of elements, not for accessing attributes of one node. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
XPath is good for random search of elements, not for accessing attributes of one node. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
XPath is good for random search of elements, not for accessing attributes of one node. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
XPath is good for random search of elements, not for accessing attributes of one node. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
The @remaining variable is leftover from old code and it's not used anymore. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Martin Kletzander 提交于
This way later patches can add another structures with virResctrl prefix without the meaning being even more confusing than it needs to be. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Martin Kletzander 提交于
That means that returning negative values means error and non-negative values differ in meaning, but are all successful. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Martin Kletzander 提交于
It doesn't access anything from conf/ and ti will be needed to use from other util/ places. This split makes the separation clearer. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Martin Kletzander 提交于
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Martin Kletzander 提交于
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Laine Stump 提交于
Commit 81fb440b further qualified an if statement by adding the boolean saveVlan to the condition. Coverity pointed out that this change in the logic eliminated the need to check saveVlan in an argument to virAsprintf().
-
由 Laine Stump 提交于
Commit 9a94af6d restructured virHostdevReadNetConfig() so that it would manually set ret = 0 after successfully reading the device's config, but Coverity pointed out that "ret = 0" was erroneously placed outside of an "else" clause, meaning that the the value of ret set in the "if" clause was unnecessarily and incorrectly overwritten. This patch moves ret = 0 into the else clause, which should silence Coverity.
-
由 Guido Günther 提交于
Acked-by: NLaine Stump <laine@laine.org>
-
- 12 8月, 2017 9 次提交
-
-
由 Laine Stump 提交于
When using a VF from an SRIOV-capable network card in a guest (either in macvtap passthrough mode, or via VFIO PCI device assignment), The associated PF netdev must be online in order for the VF to be usable by the guest. The guest, however, is not able to change the state of the PF. And libvirt *could* set the PF online as needed, but that could lead to the host receiving unexpected IPv6 traffic (since the default for an unconfigured interface is to participate in IPv6 autoconf). For this reason, before assigning a VF to a guest, libvirt verifies that the related PF netdev is online - if it isn't, then we log an error and don't allow the guest startup to continue. Until now, this check was done during virNetDevSetNetConfig(). This works nicely because the same function is called both for macvtap passthrough and for VFIO device assignment. But in the case of VFIO, the VF has already been unbound from its netdev driver by the time we get to virNetDevSetNetConfig(), and in the case of dual port Mellanox NICs that have their VFs setup in single port mode, the *only* way to determine the proper PF netdev to query for online status is via the "phys_port_id" file that is in the VF netdev's sysfs directory. *BUT* if we've unbound the VF from the netdev driver, then it doesn't *have* a netdev sysfs directory. So, in order to check the correct PF netdev for online status, this patch moved the check earlier in the setup, into virNetDevSaveNetConfig(), which is called *before* unbinding the VF from its netdev driver. (Note that this implies that if you are using VFIO device assignment for the VFs of a Mellanox NIC that has the VFs programmed in single port mode, you must let the VFs be bound to their net driver and use "managed='yes'" in the device definition. To be more specific, this is only true if the VFs in single port mode are using port *2* of the PF - if the VFs are using only port 1, then the correct PF netdev will be arrived at by default/chance)) This resolves: https://bugzilla.redhat.com/267191
-
由 Laine Stump 提交于
virHostdevRestoreNetConfig() calls virNetDevReadNetConfig() to try and read the "original config" of a netdev, and if that fails, it tries again with a different directory/netdev name. This achieves the desired effect (we end up finding the config wherever it may be), but for each failure, virNetDevReadNetConfig() places a nice error message in the system logs. Experience has shown that false-positive error logs like this lead to erroneous bug reports, and can often mislead those searching for *real* bugs. This patch changes virNetDevReadNetConfig() to explicitly check if the file exists before calling virFileReadAll(); if it doesn't exist, virNetDevReadNetConfig() returns a success, but leaves all the variables holding the results as NULL. (This makes sense if you define the purpose of the function as "read a netdev's config from its config file *if that file exists*). To take advantage of that change, the caller, virHostdevRestoreNetConfig() is modified to fail immediately if virNetDevReadNetConfig() returns an error, and otherwise to try the different directory/netdev name if adminMAC & vlan & MAC are all NULL after the preceding attempt.
-
由 Laine Stump 提交于
Mellanox ConnectX-3 dual port SRIOV NICs present a bit of a challenge when assigning one of their VFs to a guest using VFIO device assignment. These NICs have only a single PCI PF device, and that single PF has two netdevs sharing the single PCI address - one for port 1 and one for port 2. When a VF is created it can also have 2 netdevs, or it can be setup in "single port" mode, where the VF has only a single netdev, and that netdev is connected either to port 1 or to port 2. When the VF is created in dual port mode, you get/set the MAC address/vlan tag for the port 1 VF by sending a netlink message to the PF's port1 netdev, and you get/set the MAC address/vlan tag for the port 2 VF by sending a netlink message to the PF's port 2 netdev. (Of course libvirt doesn't have any way to describe MAC/vlan info for 2 ports in a single hostdev interface, so that's a bit of a moot point) When the VF is created in single port mode, you can *set* the MAC/vlan info by sending a netlink message to *either* PF netdev - the driver is smart enough to understand that there's only a single netdev, and set the MAC/vlan for that netdev. When you want to *get* it, however, the driver is more accurate - it will return 00:00:00:00:00:00 for the MAC if you request it from the port 1 PF netdev when the VF was configured to be single port on port 2, or if you request if from the port 2 PF netdev when the VF was configured to be single port on port 1. Based on this information, when *getting* the MAC/vlan info (to save the original setting prior to assignment), we determine the correct PF netdev by matching phys_port_id between VF and PF. (IMPORTANT NOTE: this implies that to do PCI device assignment of the VFs on dual port Mellanox cards using <interface type='hostdev'> (i.e. if you want the MAC address/vlan tag to be set), not only must the VFs be configured in single port mode, but also the VFs *must* be bound to the host VF net driver, and libvirt must use managed='yes') By the time libvirt is ready to set the new MAC/vlan tag, the VF has already been unbound from the host net driver and bound to vfio-pci. This isn't problematic though because, as stated earlier, when a VF is created in single port mode, commands to configure it can be sent to either the port 1 PF netdev or the port 2 PF netdev. When it is time to restore the original MAC/vlan tag, again the VF will *not* be bound to a host net driver, so it won't be possible to learn from sysfs whether to use the port 1 or port 2 PF netdev for the netlink commands. And again, it doesn't matter which netdev you use. However, we must keep in mind that we saved the original settings to a file called "${PF}_${VFNUM}". To solve this problem, we just check for the existence of ${PF1}_${VFNUM} and ${PF2}_${VFNUM}, and use whichever one we find (since we know that only one can be there)
-
由 Laine Stump 提交于
This patch updates functions in netdev.c to pay attention to phys_port_id. It uses the new function virNetDevGetPhysPortID() to learn the phys_port_id of a VF or PF, then sends that info to virPCIGetNetName(), which has newly been modified to take an optional phys_port_id.
-
由 Laine Stump 提交于
A single PCI device may have multiple netdevs associated with it. Each of those netdevs will have a different phys_port_id entry in sysfs. This patch modifies virPCIGetNetName() to allow selecting one of the potential many netdevs in two different ways: 1) by setting the "idx" argument, the caller can select the 1st (0), 2nd (1), etc. netdev from the PCI device's net subdirectory. 2) If the physPortID arg is set (to a null-terminated string) then virPCIGetNetName() returns the netdev that has that phys_port_id in the sysfs file of the same name in the netdev's directory.
-
由 Laine Stump 提交于
The first arg isn't modified in the function, so it should be const.
-
由 Laine Stump 提交于
On Linux each network device *can* (but not necessarily *does*) have an attribute called phys_port_id which can be read from the file of that name in the netdev's sysfs directory. The examples I've seen have been a many-digit hexadecimal number (as an ASCII string). This value can be useful when a single PCI device is associated with multiple netdevs (e.g a dual port Mellanox SR-IOV NIC - this card has a single PCI Physical Function (PF), and that PF has two netdevs associated with it (the "net" subdirectory of the PF in sysfs has two links rather than the usual single link to a netdev directory). Each of the PF netdevs has a different phys_port_id. The Virtual Functions (VF) are similar - the PF (a PCI device) has "n" VFs (also each of these is a PCI device), each VF has two netdevs, and each of the VF netdevs points back to the VF PCI device (with the "device" entry in its sysfs directory) as well as having a phys_port_id matching the PF netdev it is associated with. virNetDevGetPhysPortID() simply attempts to read the phys_port_id for the given netdev and return it to the caller. If this particular netdev driver doesn't support phys_port_id, it returns NULL (*not* a NULL-terminated string, but a NULL pointer) but still counts it as a success.
-
由 intrigeri 提交于
-
由 Daniel P. Berrange 提交于
When building libvirt with clang we get bogus warnings about 'double' being promoted to 'long double' when calling isnan(). https://bugzilla.redhat.com/show_bug.cgi?id=1472437 Detect this broken isnan() / compiler combination and disable the -Wdouble-promotion flag. Reviewed-by: NPavel Hrdina <phrdina@redhat.com> Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 10 8月, 2017 1 次提交
-
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1458638 This code is so complicated because we allow enabling the same bits at many places. Just like in this case: huge pages can be enabled by global <hugepages/> element under <memoryBacking> or on per <memory/> basis. To complicate things a bit more, users are allowed to omit the page size which case the default page size is used. And this is what is causing this bug. If no page size is specified, @pagesize is keeping value of zero throughout whole function. Therefore we need yet another boolean to hold [use, don't use] information as we can't sue @pagesize for that. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NMartin Kletzander <mkletzan@redhat.com>
-