- 17 8月, 2017 10 次提交
-
-
由 John Ferlan 提交于
In preparation for making the object private, create a couple of API's to get the obj->def & obj->newDef and set the obj->def. While altering networkxml2conftest.c to use the virNetworkObjSetDef API, fix the name of the variable from @dev to @def Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
In preparation for making the object private, create a couple of API's to get/set the obj->floor_sum. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
In preparation for privatizing virNetworkObj, create accessor function to fetch the @classIdMap. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Change the variable name to be a bit more descriptive and less confusing when used with the data.network.actual->class_id. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
In preparation for making the object private, create/use a couple of API's to get/set the obj->dnsmasqPid and obj->radvdPid. NB: Since the pid's can sometimes changed based on intervening functions, be sure to always fetch the latest value. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Since we can only ever have one reference to obj->macmap, rather than only clearing obj->macmap during virNetworkObjUnrefMacMap (e.g. virtual network from networkShutdownNetwork), let's just unconditionally clear the obj->macmap to ensure that some future change that created it's own reference to obj->macmap wouldn't have that reference disappear if virNetworkObjDispose got called. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
In preparation for having a private virNetworkObj - let's create/move some API's that handle the obj->macmap. The API's will be renamed to have a virNetworkObj prefix to follow conventions and the arguments slightly modified to accept what's necessary to complete their task. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Move networkMacMgrFileName into src/util/virmacmap.c and rename to virMacMapFileName. We're about to move some more MacMgr processing files into virnetworkobj and it doesn't make sense to have this helper in the driver or in virnetworkobj. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 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 2 次提交
-
-
由 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.
-