- 28 3月, 2019 5 次提交
-
-
由 Peter Krempa 提交于
Avoid the extra parameter passing in the disk 'dst' parameter to be reported instead of the device alias. Using 'dst' instead of alias does not add much value. Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
-
由 Peter Krempa 提交于
qemuDomainRemoveDiskDevice calls qemuDomainReleaseDeviceAddress which already calls virDomainUSBAddressRelease so we don't need to call it again. Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
-
由 Michal Privoznik 提交于
Introduced in fdf6c89e, this dependency looks weird. It was needed because of the way that while() loop was written - it fetches next argument in every iteration. Therefore, our only option was for ARG_END to have the same value as QEMU_CAPS_LAST. This also meant that QEMU_CAPS_* could have been only at the end of the __VA_ARGS__. This commit reworks the while() loop and removes the dependency. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Michal Privoznik 提交于
There is one specific caller (testInfoSetArgs() in qemuxml2argvtest.c) which expect the va_list argument to change after returning from the virQEMUCapsSetVAList() function. However, since we are passing plain va_list this is not guaranteed. The man page of stdarg(3) says: If ap is passed to a function that uses va_arg(ap,type), then the value of ap is undefined after the return of that function. (ap is a variable of type va_list) I've seen this in action in fact: on i686 the qemuxml2argvtest fails on the second test case because testInfoSetArgs() sees ARG_QEMU_CAPS and calls virQEMUCapsSetVAList to process the capabilities (in this case there's just one QEMU_CAPS_SECCOMP_BLACKLIST). But since the changes are not reflected in the caller, in the next iteration testInfoSetArgs() sees the QEMU capability and not ARG_END. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
The mock fopen() function will abort if "/proc/mounts" is requested with "r" permissions and VIR_CGROUP_MOCK_FILENAME env var is not set. Unfortunately this is triggering by the libselinux library constructor when it tries to read /proc/mounts to find out if selinuxfs is mounted in an unusual place. This, however, only affects libselinux in Debian as that opens with "r", while in Fedora / RHEL it opens "re" and thus luckily never triggered the abort(), instead getting an EACCESS. Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 27 3月, 2019 15 次提交
-
-
由 Eric Blake 提交于
This reverts commit 6b90a847. It turns out gcc -O2 is not happy with it, complaining: /home/pipo/libvirt/src/qemu/qemu_driver.c: In function 'qemuDomainSnapshotCreateXML': /home/pipo/libvirt/src/qemu/qemu_driver.c:15389:26: error: potential null pointer dereference [-Werror=null-dereference] bool memory = snapdef->memory == VIR_DOMAIN_SNAPSHOT_LOCATION_EXTERNAL; ~~~~~~~^~~~~~~~ /home/pipo/libvirt/src/qemu/qemu_driver.c:15389:26: error: potential null pointer dereference [-Werror=null-dereference] In file included from /home/pipo/libvirt/src/util/virbuffer.h:27, from /home/pipo/libvirt/src/conf/capabilities.h:27, from /home/pipo/libvirt/src/conf/domain_conf.h:32, from /home/pipo/libvirt/src/qemu/qemu_agent.h:26, from /home/pipo/libvirt/src/qemu/qemu_driver.c:40: /home/pipo/libvirt/src/util/viralloc.h:125:34: error: potential null pointer dereference [-Werror=null-dereference] # define VIR_ALLOC_N(ptr, count) virAllocN(&(ptr), sizeof(*(ptr)), (count), true, \ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ VIR_FROM_THIS, __FILE__, __FUNCTION__, __LINE__) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/pipo/libvirt/src/qemu/qemu_driver.c:15103:9: note: in expansion of macro 'VIR_ALLOC_N' if (VIR_ALLOC_N(ret, snapdef->ndisks) < 0) ^~~~~~~~~~~ /home/pipo/libvirt/src/qemu/qemu_driver.c:15798:45: error: null pointer dereference [-Werror=null-dereference] virDomainSnapshotObjGetDef(snap)->memory == VIR_DOMAIN_SNAPSHOT_LOCATION_EXTERNAL) { ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~ As the patch simplified one or two callers at the risk of making many other callers now candidates to trigger aggressive compiler warnings, it isn't worth it. Signed-off-by: NEric Blake <eblake@redhat.com>
-
由 Eric Blake 提交于
Use the common base class virDomainMoment for iterator callbacks related to snapshots from the qemu code, so that when checkpoint operations are introduced, they can share the same callbacks. Simplify the code for qemuDomainSnapshotCurrent by better utilizing virDomainMoment helpers. Signed-off-by: NEric Blake <eblake@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Eric Blake 提交于
Doing so can simplify some callers. Signed-off-by: NEric Blake <eblake@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Eric Blake 提交于
The qemu driver already had a full-blown virDomainMomentObjPtr to check against, and the test driver ought to have one since we get better error checking that the user passed in a valid object. Removes the need for a helper function added in commit commit 4819f54b. Signed-off-by: NEric Blake <eblake@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
-
由 Andrea Bolognani 提交于
ldconfig needs to be called after installing or uninstalling shared libraries. For a very long time, libvirt didn't have a separate package containing just the shared libraries, and so it shipped them in the same one as the clients. Since commit 70b4f0e7, however, shared libraries have been moved from -client to their own -libs package; unfortunately, the corresponding ldconfig calls were not moved at the same time, which is what this commit takes care of. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Jiri Denemark 提交于
The VIR_MIGRATE_PARALLEL flag is implemented using QEMU's multifd migration capability and the corresponding multifd-channels migration parameter. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Jiri Denemark 提交于
This patch adds a new VIR_MIGRATE_PARALLEL flag for migration APIs which will ask the hypervisor to use multiple parallel connections for migrating a domain. The number of parallel connections can be set using VIR_MIGRATE_PARAM_PARALLEL_CONNECTIONS typed parameter. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Eric Blake 提交于
Prepare for introducing a bunch of new public APIs related to backup checkpoints by first introducing a new internal type and errors associated with that type. Checkpoints are modeled heavily after virDomainSnapshotPtr (both represent a point in time of the guest), although a snapshot exists with the intent of rolling back to that state, while a checkpoint exists to make it possible to create an incremental backup at a later time. Signed-off-by: NEric Blake <eblake@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Eric Blake 提交于
Since I was copying this text to form checkpoint XML and API documentation, I might as well make improvements along the way. Most of these changes are based on reviews of the checkpoint docs. Among other things: grammar tweaks, point to a single source of documentation rather than repeating verbosity, reword things for easier legibility. Signed-off-by: NEric Blake <eblake@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Eric Blake 提交于
This reverts commit 86c0ed6f, and subsequent refactorings of the function into new files. There are no callers of this function - I had originally proposed it for implementing a new bulk snapshot API, but that proved to be too invasive given RPC limits. I also tried using it for streamlining how the qemu driver stores snapshot state across libvirtd restarts internally, but in the end, the risks of a new internal format outweighed the benefits of one file per snapshot. Signed-off-by: NEric Blake <eblake@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Eric Blake 提交于
This reverts commit 1b57269c, and subsequent refactorings of the function into new files. There are no callers of this function - I had originally proposed it for implementing a new bulk snapshot API, but that proved to be too invasive given RPC limits. I also tried using it for streamlining how the qemu driver stores snapshot state across libvirtd restarts internally, but in the end, the risks of a new internal format outweighed the benefits of one file per snapshot. Signed-off-by: NEric Blake <eblake@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Andrea Bolognani 提交于
Running QEMU as root is a pretty bad idea, so try to make the user aware of that as part of the configure summary. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Andrea Bolognani 提交于
Our current defaults are root:wheel on FreeBSD and macOS, root:root everywhere else. Looking at what downstream distributions actually do, we can see that these defaults are overriden the vast majority of the time, with a number of variations showing up in the wild: * qemu:qemu -> Used by CentOS, Fedora, Gentoo, OpenSUSE, RHEL and... As it turns out, our very own spec file :) * libvirt-qemu:libvirt-qemu -> Used by Debian. * libvirt-qemu:kvm -> Used by Ubuntu. * nobody:nobody -> Used by Arch Linux. Based on this information, we can do a better job at integrating with downstream packages: if the distro-specific user and group already exist on the system then we use them, and if not (or we're building on an unknown OS) we just use root:root as we would have before. This change makes it less likely that people building from source will end up running their guests as root, which is a very desiderable outcome from the security point of view. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 26 3月, 2019 20 次提交
-
-
由 Michal Privoznik 提交于
If qemuFirmwareFetchConfigs() returned more or fewer paths than expected all that we see is the following error message: Expected 5 paths, got 7 While it is technically correct (the best kind of correct), we can do better: Unexpected path (i=0). Expected /some/path got /some/other/path Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
-
由 Laine Stump 提交于
For [some unknown reason, possibly/probably pure chance], Net devices have been taken offline and their bandwidth tc rules cleared as the very first operation when detaching the device. This is contrary to every other type of device, where all hostside teardown is delayed until we receive the DEVICE_DELETED event back from qemu, indicating that the guest has finished with the device. This patch delays these two operations until receipt of DEVICE_DELETED, which removes an ugly wart from qemuDomainDetachDeviceLive(), and also seems to be a more correct sequence of events. Signed-off-by: NLaine Stump <laine@laine.org> ACKed-by: NPeter Krempa <pkrempa@redhat.com>
-
由 Laine Stump 提交于
The VIR_DOMAIN_EVENT_ID_DEVICE_REMOVED event is sent after qemu has responded to a device_del command with a DEVICE_DELETED event. Before queuing the event, *some* of the final teardown of the device's trappings in libvirt is done, but not *all* of it. As a result, an application may receive and process the DEVICE_REMOVED event before libvirt has really finished with it. Usually this doesn't cause a problem, but it can - in the case of the bug report referenced below, vdsm is assigning a PCI device to a guest with managed='no', using livirt's virNodeDeviceDetachFlags() and virNodeDeviceReAttach() APIs. Immediately after receiving a DEVICE_REMOVED event from libvirt signalling that the device had been successfully unplugged, vdsm would cal virNodeDeviceReAttach() to unbind the device from vfio-pci and rebind it to the host driverm but because the event was received before libvirt had completely finished processing the removal, that device was still on the "activeDevs" list, and so virNodeDeviceReAttach() failed. Experimentation with additional debug logs proved that libvirt would always end up dispatching the DEVICE_REMOVED event before it had removed the device from activeDevs (with a *much* greater difference with managed='yes', since in that case the re-binding of the device occurred after queuing the device). Although the case of hostdev devices is the most extreme (since there is so much involved in tearing down the device), *all* device types suffer from the same problem - the DEVICE_REMOVED event is queued very early in the qemuDomainRemove*Device() function for all of them, resulting in a possibility of any application receiving the event before libvirt has really finished with the device. The solution is to save the device's alias (which is the only piece of info from the device object that is needed for the event) at the beginning of processing the device removal, and then queue the event as a final act before returning. Since all of the qemuDomainRemove*Device() functions (except qemuDomainRemoveChrDevice()) are now called exclusively from qemuDomainRemoveDevice() (which selects which of the subordinates to call in a switch statement based on the type of device), the shortest route to a solution is to doing the saving of alias, and later queueing of the event, in the higher level qemuDomainRemoveDevice(), and just completely remove the event-related code from all the subordinate functions. The single exception to this, as mentioned before, is qemuDomainRemoveChrDevice(), which is still called from somewhere other than qemuDomainRemoveDevice() (and has a separate arg used to trigger different behavior when the chr device has targetType == GUESTFWD), so it must keep its original behavior intact, and must be treated differently by qemuDomainRemoveDevice() (similar to the way that qemuDomainDetachDeviceLive() treats chr and lease devices differently from all the others). Resolves: https://bugzilla.redhat.com/1658198Signed-off-by: NLaine Stump <laine@laine.org> ACKed-by: NPeter Krempa <pkrempa@redhat.com>
-
由 Laine Stump 提交于
Now that all the qemuDomainDetachPrep*() functions look nearly identical at the end, we can put one copy of that identical code in qemuDomainDetachDeviceLive() at the point after the individual prep functions have been called, and remove the duplicated code from all the prep functions. The code to locate the target "detach" device based on the "match" device remains, as do all device-type-specific validations. Unfortunately there are a few things going on at once in this patch, which makes it a bit more difficult to follow than the others; it was just impossible to do the changes in stages and still have a buildable/testable tree at each step. The other changes of note: * The individual prep functions no longer need their driver or async args, so those are removed, as are the local "ret" variables, since in all cases the functions just directly return -1 or 0. * Some of the prep functions were checking for a valid alias and/or for attempts to detach a multifunction PCI device, but not all. In fact, both checks are valid (or at least harmless) for *all* device types, so they are removed from the prep functions, and done a single time in the common function. (any attempts to *create* an alias when there isn't one has been removed, since that is doomed to failure anyway; the only way the device wouldn't have an alias is if 1) the domain was created by calling virsh qemu-attach to attach an existing qemu process to libvirt, and 2) the qemu command that started said process used "old style" arguments for creating devices that didn't have any device ids. Even if we constructed a device id for one of these devices, qemu wouldn't recognize it in the device_del command anyway, so we may as well fail earlier with "device missing alias" rather than failing later with "couldn't delete device net0".) * Only one type of device has shutdown code that must not be called until after *all* validation of the device is done (including checking for multifunction PCI and valid alias, which is done in the toplevel common code). For this reason, the Net function has been split in two, with the 2nd half (qemuDomainDetachShutdownNet()) called from the common function, right before sending the delete command to qemu. Signed-off-by: NLaine Stump <laine@laine.org> ACKed-by: NPeter Krempa <pkrempa@redhat.com>
-
由 Laine Stump 提交于
Although all hotpluggable devices other than lease, controller, watchdof, and vsock can be audited, and *are* audited when an unplug is successful, only disk, net, and hostdev were actually being audited on failure. This patch corrects that omission. Signed-off-by: NLaine Stump <laine@laine.org> ACKed-by: NPeter Krempa <pkrempa@redhat.com>
-
由 Laine Stump 提交于
This function can be called with a virDomainDevicePtr and whether or not the removal was successful, and it will call the appropriate virDomainAudit*() function with the appropriate args for whatever type of device it's given (or do nothing, if that's appropriate). This permits generalizing some code that currently has a separate copy for each type of device. NB: Although the function initially will be called only with success=false, that has been made an argument so that in the future (when the qemuDomainRemove*Device() functions have had their common functionality consolidated into qemuDomainRemoveDevice()), this new common code can call qemuDomainRemoveAuditDevice() for all types. Signed-off-by: NLaine Stump <laine@laine.org> ACKed-by: NPeter Krempa <pkrempa@redhat.com>
-
由 Laine Stump 提交于
qemuDomainDetachDeviceChr and qemuDomainDetachDeviceLease are more consistent with each other. Signed-off-by: NLaine Stump <laine@laine.org> ACKed-by: NPeter Krempa <pkrempa@redhat.com>
-
由 Laine Stump 提交于
Most of these functions will soon contain only some setup for detaching the device, not the detach code proper (since that code is identical for these devices). Their device specific functions are all being renamed to qemuDomainDetachPrep*(), where * is the name of that device's data member in the virDomainDeviceDef object. Since there will be other code in qemuDomainDetachDeviceLive() after the calls to qemuDomainDetachPrep*() that could still fail, we no longer directly set "ret" with the return code from qemuDomainDetachPrep*() functions, but simply return -1 on failure, and wait until the end of qemuDomainDetachDeviceLive() to set ret = 0. Along with the rename, qemuDomainDetachPrep*() functions are also given similar arglists, including an arg called "match" that points to the proto-object of the device we want to delete, and another arg "detach" that is used to return a pointer to the actual object that will be (for now *has been*) detached. To make sure these new args aren't confused with existing local pointers that sometimes had the same name (detach), the local pointer to the device is now named after the device type ("controller", "disk", etc). These point to the same place as (*detach)->data.blah, it's just easier on the eyes to have, e.g., "disk->dst" rather than "(*detach)->data.disk-dst". Signed-off-by: NLaine Stump <laine@laine.org> ACKed-by: NPeter Krempa <pkrempa@redhat.com>
-
由 Laine Stump 提交于
The Chr and Lease devices have detach code that is too different from the other device types to handle with common functionality (which will soon be added at the end of qemuDomainDetachDeviceLive(). In order to make this difference obvious, move the cases for those two device types to the top of the switch statement in qemuDomainDetachDeviceLive(), have the cases return immediately so the future common code at the end of the function will be skipped, and also include some hopefully helpful comments to remind future maintainers why these two device types are treated differently. Any attempt to detach an unsupported device type should also skip the future common code at the end of the function, so the case for unsupported types is similarly changed from a simple break to a return -1. Signed-off-by: NLaine Stump <laine@laine.org> ACKed-by: NPeter Krempa <pkrempa@redhat.com>
-
由 Laine Stump 提交于
I'm about to add a second virDomainDeviceDef to this function that will point to the actual device in the domain object. while this is just a partially filled-in example of what to look for. Naming it match will make the code easier to follow. Signed-off-by: NLaine Stump <laine@laine.org> ACKed-by: NPeter Krempa <pkrempa@redhat.com>
-
由 Laine Stump 提交于
These are no longer called from qemu_driver.c, since the function that called them (qemuDomainDetachDeviceLive()) has been moved to qemu_hotplug.c, and they are no longer called from testqemuhotplug.c because it now just called qemuDomainDetachDeviceLive() instead of all the subordinate functions. Signed-off-by: NLaine Stump <laine@laine.org> ACKed-by: NPeter Krempa <pkrempa@redhat.com>
-
由 Laine Stump 提交于
The individual qemuDomainDetach*Device() functions will soon be "less functional", since some of the code that is duplicated in 10 of the 12 detach functions is going to be moved into the common qemuDomainDetachDeviceLive(), which calls them all. qemuhotplugtest.c is the only place any of these individual functions is called other than qemuDomainDetachDeviceLive() itself. Fortunately, qemuDomainDetachDeviceLive() provides exactly the functionality needed by the test driver (except that it supports detach of more device types than the test driver has tests for). This patch replaces the calls to qemuDomainDetach(Chr|Shmen|Watchdog|Disk)Device with a single call to the higher level function, allowing us to shift functionality between the lower level functions without breaking the tests. Signed-off-by: NLaine Stump <laine@laine.org> ACKed-by: NPeter Krempa <pkrempa@redhat.com>
-
由 Laine Stump 提交于
qemuDomainDetachDeviceLive() is called from two places in qemu_driver.c, and qemuDomainUpdateDeviceList() is called from the end of qemuDomainDetachDeviceLive(), which is now in qemu_hotplug.c This patch replaces the single call to qemuDomainUpdateDeviceList() with two calls to it immediately after return from qemuDomainDetachDeviceLive(). This is only done if the return from that function is exactly 0, in order to exactly preserve previous behavior. Removing that one call from qemuDomainDetachDeviceList() will permit us to call it from the test driver hotplug test, replacing the separate calls to qemuDomainDetachDeviceDiskLive(), qemuDomainDetachChrDevice(), qemuDomainDetachShmemDevice() and qemuDomainDetachWatchdog(). We want to do this so that part of the common functionality of those three functions (and the rest of the device-specific Detach functions) can be pulled up into qemuDomainDetachDeviceLive() without breaking the test. (This is done in the next patch). NB: Almost certainly this is "not the best place" to call qemuDomainUpdateDeviceList() (actually, it is provably the *wrong* place), since it's purpose is to retrieve an "up to date" list of aliases for all devices from qemu, and if the guest OS hasn't yet processed the detach request, the now-being-removed device may still be on that list. It would arguably be better to instead call qemuDomainUpdateDevicesList() later during the response to the DEVICE_DELETED event for the device. But removing the call from the current point in the detach could have some unforeseen ill effect due to changed timing, so the change to move it into qemuDomainRemove*Device() will be done in a separate patch (in order to make it easily revertible in case it causes a regression). Signed-off-by: NLaine Stump <laine@laine.org> ACKed-by: NPeter Krempa <pkrempa@redhat.com>
-
由 Laine Stump 提交于
qemuDomainDetachDeviceControllerLive() just checks if the controller type is SCSI, and then either returns failure, or calls qemuDomainDetachControllerDevice(). Instead, lets just check for type != SCSI at the top of the latter function, and call it directly. Signed-off-by: NLaine Stump <laine@laine.org> ACKed-by: NPeter Krempa <pkrempa@redhat.com>
-
由 Laine Stump 提交于
This function is going to take on some of the functionality of its subordinate functions, which all live in qemu_hotplug.c. qemuDomainDetachDeviceControllerLive() is only called from qemuDomainDetachDeviceLive() (and will soon be merged into qemuDomainDetachControllerDevice(), which is in qemu_hotplug.c), so it is also moved. Signed-off-by: NLaine Stump <laine@laine.org> ACKed-by: NPeter Krempa <pkrempa@redhat.com>
-
由 Peter Krempa 提交于
Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
They were added in qemu commit 7572150c189c6553c2448334116ab717680de66d released in v0.14.0. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Eric Blake 提交于
Rather than hard-coding the snapshot filter bit values into the generic code, add another layer of indirection: callers must map which of their public filter bits correspond to supported moment bits, then pass two separate flags (the ones translated for moment code to operate on, and the remaining ones for the filter callback to operate on). Signed-off-by: NEric Blake <eblake@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Laine Stump 提交于
The Attach and Detach Lease functions were together in the middle of the Detach functions. Put them at the end of their respective sections, since they behave differently from the other attach/detach functions (DetachLease doesn't use qemuDomainDeleteDevice(), and is always synchronous). Signed-off-by: NLaine Stump <laine@laine.org> ACKed-by: NPeter Krempa <pkrempa@redhat.com>
-
由 Laine Stump 提交于
There were two outliers at the end of the file beyond the Vcpu functions. Signed-off-by: NLaine Stump <laine@laine.org> ACKed-by: NPeter Krempa <pkrempa@redhat.com>
-