- 25 2月, 2019 8 次提交
-
-
由 Andrea Bolognani 提交于
libvirt_iohelper is used internally by the virFileWrapperFd APIs; more specifically, in the QEMU driver we have the doCoreDump() and qemuDomainSaveMemory() helper functions as users, and those in turn end up being called by the implementation of several driver APIs. By calling virReportError() if libvirt_iohelper has failed, we overwrite whatever generic error message QEMU might have raised with the more useful one generated by the helper program. After this commit, the user will be able to see the error directly instead of having to dig in the journal or libvirtd log. https://bugzilla.redhat.com/show_bug.cgi?id=1578741Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Andrea Bolognani 提交于
virFileWrapperFdFree(), like all free functions, is supposed to only release allocated resources, so error reporting is better suited for virFileWrapperFdClose(). This reverts commit b0c3e931. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Andrea Bolognani 提交于
Right now we're reporting errors in virFileWrapperFdFree(), but that's hardly the appropriate place to do so, as free functions are supposed to do nothing more than release allocated resources. We want to move that code back into virFileWrapperFdClose(), but before we can do that we need to make sure the function is actually called every time we're done processing the wrapped file. The cleanup path is the obvious candidate. In a couple of cases we can just move the call, but for the remaining ones we need to duplicate it instead in order not to alter the existing behavior. We do, however, make sure that in all cases a failure to properly close the wrapper results in the overall operation being reported as failed. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Andrea Bolognani 提交于
We'll want to use this function in the cleanup path soon, and in order to be able to do that we need to make sure we can call it multiple times on the same virFileWrapperFd without side effects. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Marc Hartmayer 提交于
Replace virDomainChrSourceDefFree with virObjectUnref. Signed-off-by: NMarc Hartmayer <mhartmay@linux.ibm.com> Reviewed-by: NBoris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
由 Marc Hartmayer 提交于
Use refcounting for priv->monConfig instead of asymmetric freeing. Signed-off-by: NMarc Hartmayer <mhartmay@linux.ibm.com> Reviewed-by: NBoris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
由 Christian Ehrhardt 提交于
Change fb01e1a4 "virt-aa-helper: generate rules for gl enabled graphics devices" implemented the detection for gl enabled devices in virt-aa-helper. But further testing showed that it will need much more access for the full gl stack to work. Upstream apparmor just recently split those things out and now has two related abstractions at https://gitlab.com/apparmor/apparmor/blob/master: - dri-common at /profiles/apparmor.d/abstractions/dri-common - mesa: at /profiles/apparmor.d/abstractions/mesa If would be great to just include that for the majority of rules, but they are not yet in any distribution so we need to add rules inspired by them based on the testing that we can do. Furthermore qemu with opengl will also probe the backing device of the rendernode for attributes which should be safe as read-only wildcard rules. Fixes: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1815452Acked-by: NJamie Strandboge <jamie@canonical.com> Signed-off-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>
-
由 Christian Ehrhardt 提交于
Change fb01e1a4 "virt-aa-helper: generate rules for gl enabled graphics devices" implemented the detection for gl enabled devices in virt-aa-helper. But it will in certain cases e.g. if no rendernode was explicitly specified need to read /dev/dri which it currently isn't allowed. Add a rule to the apparmor profile of virt-aa-helper itself to be able to do that. Acked-by: NJamie Strandboge <jamie@canonical.com> Signed-off-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>
-
- 24 2月, 2019 4 次提交
-
-
由 Roman Bogorodskiy 提交于
Add a bhyveDomainDefNeedsISAController() helper function which by domain configuration determines whether LPC controller is required or not. Signed-off-by: NRoman Bogorodskiy <bogorodskiy@gmail.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Roman Bogorodskiy 提交于
Describe bhyve's ignoring unknown MSRs access feature introduced by commit e9528f41. Signed-off-by: NRoman Bogorodskiy <bogorodskiy@gmail.com> Reviewed-by: NCole Robinson <crobinso@redhat.com>
-
由 Roman Bogorodskiy 提交于
Implement the MSRs ignore unknown reads and writes feature that's specified using: <features> ... <msrs unknown='ignore'> ... </features> in the domain XML. In bhyve, it's just passing '-w' command line argument to the bhyve(8) executable. Signed-off-by: NRoman Bogorodskiy <bogorodskiy@gmail.com> Reviewed-by: NCole Robinson <crobinso@redhat.com>
-
由 Roman Bogorodskiy 提交于
Introduce the 'msrs' feature element that controls Model Specific Registers related behaviour. At this moment it allows only single tunable attribute "unknown": <msrs unknown='ignore|fault'/> Which tells hypervisor to ignore accesses to unimplemented Model Specific Registers. The only user of that for now is going to be the bhyve driver. Signed-off-by: NRoman Bogorodskiy <bogorodskiy@gmail.com> Reviewed-by: NCole Robinson <crobinso@redhat.com>
-
- 23 2月, 2019 2 次提交
-
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Jiri Denemark 提交于
The tests/cputestdata/cpu-parse.sh script has been broken since the cpu_map.xml file was split into several XMLs. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
- 22 2月, 2019 12 次提交
-
-
由 David Kiarie 提交于
Signed-off-by: NDavid Kiarie <davidkiarie4@gmail.com>
-
由 Ján Tomko 提交于
Commit a1dce962 added the allocated scsiVPDDeviceId without freeing it. Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
由 Peter Krempa 提交于
Replace all uses where virBuffer would need clearing on the cleanup path. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com>
-
由 Peter Krempa 提交于
virBuffer is almost always stack-allocated, but requires freeing of the internals on error. Introduce a VIR_AUTOCLEAN function to deal with this. Along with the addition add a test which would leak the buffer contents if it weren't autocleaned. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com>
-
由 Peter Krempa 提交于
The new utility macros are useful for variables we put on the stack but require some cleanup. The most prominent of those is virBuffer which is used almost exclusively in that way. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com>
-
由 Peter Krempa 提交于
The function was used only in the tests, remove it. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com>
-
由 Peter Krempa 提交于
The messages reference testBufEscapeN instead of testBufEscapeRegex. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com>
-
由 Peter Krempa 提交于
The conversion to VIR_AUTOFREE of 'escapeList' introduced memory leak of the copied item to be escaped: ==17517== 2 bytes in 1 blocks are definitely lost in loss record 1 of 32 ==17517== at 0x483880B: malloc (vg_replace_malloc.c:309) ==17517== by 0x54D666D: strdup (in /usr/lib64/libc-2.28.so) ==17517== by 0x497663E: virStrdup (virstring.c:956) ==17517== by 0x497663E: virStrdup (virstring.c:945) ==17517== by 0x48F8853: virBufferEscapeN (virbuffer.c:707) ==17517== by 0x403C9D: testBufEscapeN (virbuftest.c:383) ==17517== by 0x405FA8: virTestRun (testutils.c:174) ==17517== by 0x403A70: mymain (virbuftest.c:517) ==17517== by 0x406BC9: virTestMain (testutils.c:1097) ==17517== by 0x5470412: (below main) (in /usr/lib64/libc-2.28.so) [...] (all other have same backtrace as it happens in a loop) Fix it by reverting all the VIR_AUTO nonsense in this function as there is exactly one place where it's handled. This effectively reverts commits: d0a92a03 96fbf6df d261ed2fSigned-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com>
-
由 Peter Krempa 提交于
'virBufferFreeAndReset' does not free the top level structure itself. Additionally we almost exclusively use stack'd buffers rather than pointers. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com>
-
由 Laine Stump 提交于
dnsmasq documentation says that the *IPv4* prefix/network address/broadcast address sent to dhcp clients will be automatically determined by dnsmasq by looking at the interface it's listening on, so the original libvirt code did not add a netmask to the dnsmasq commandline (or later, the dnsmasq conf file). For *IPv6* however, dnsmasq apparently cannot automatically determine the prefix (functionally the same as a netmask), and it must be explicitly provided in the conf file (as a part of the dhcp-range option). So many years after IPv4 DHCP support had been added, when IPv6 dhcp support was added the prefix was included at the end of the dhcp-range setting, but only for IPv6. A user had reported a bug on a host where one of the interfaces was a superset of the libvirt network where dhcp is needed (e.g., the host's ethernet is 10.0.0.20/8, and the libvirt network is 10.10.0.1/24). For some reason dnsmasq was supplying the netmask for the /8 network to clients requesting an address on the /24 interface. This seems like a bug in dnsmasq, but even if/when it gets fixed there, it looks like there is no harm in just always adding the netmask to all IPv4 dhcp-range options similar to how prefix is added to all IPv6 dhcp-range options. Signed-off-by: NLaine Stump <laine@laine.org> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Laine Stump 提交于
This fixes a bug that has been present since the original version of the function was pushed in commit 1ab80f32 on Nov. 26 2010 (by me). The virSocketAddr::len was not being set. Apparently until now we were always calling virSocketAddrPrefixToNetmask with virSocketAddr object that was already (coincidentally) initialized for the proper address family, but the bug became apparent when trying to use it to fill in an otherwise uninitialized object. Signed-off-by: NLaine Stump <laine@laine.org> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Eric Blake 提交于
Most of the code base is fairly consistent about using the name 'uuidstr' when dealing with a formatted human-readable form, and 'uuid' when dealing with the smaller raw bytes form. Fix snapshot_conf to comply, as well as reducing the scope of a human string to only the error message that needs it. Signed-off-by: NEric Blake <eblake@redhat.com>
-
- 21 2月, 2019 3 次提交
-
-
由 Marc Hartmayer 提交于
Signal the udev thread the change of `priv->threadQuit` by using the thread condition. Signed-off-by: NMarc Hartmayer <mhartmay@linux.ibm.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Marc Hartmayer 提交于
If the udev thread is stopped, it must be ensured that the watch handle is also removed from the main loop. Signed-off-by: NMarc Hartmayer <mhartmay@linux.ibm.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
In preparation for some autofree mods. Signed-off-by: NJohn Ferlan <jferlan@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
- 20 2月, 2019 11 次提交
-
-
由 Michal Privoznik 提交于
Currently, some arguments are called strcontent and strsrc, or content and src or some other combination. This makes it impossible to see at the first glance what argument is supposed to represent 'expected' value and which one represents 'actual' value. Rename the arguments to make it obvious. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com> Reviewed-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Michal Privoznik 提交于
The current naming makes it hard for me to see which holds the expected value and which holds the actual value. Rename them to make it obvious. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Michal Privoznik 提交于
In order to save a few lines of code, and also since it's hype let's use VIR_AUTOFREE() for the two strings we allocate there. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Andrea Bolognani 提交于
The iohelper is an internal program that's only supposed to be called by libvirt, and whatever output it might produce will ultimately be passed to virReportError() or similar. Since we do not want strings passed to those functions to contain newlines, we can simply not output them in the first place. This is what happens in pretty much all cases already, but in a couple instances newlines have managed to slip in. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NLaine Stump <laine@laine.org>
-
由 Eric Blake 提交于
Commit f609cb85 (0.9.5) introduced virDomainSnapshotGetXMLDesc()'s use of @flags as a subset of virDomainXMLFlags, documenting that 2 of the 3 flags defined at the time would never be valid. Later, commit 28f8dfdc (1.0.0) introduced a new flag, VIR_DOMAIN_XML_MIGRATABLE, but did not adjust the snapshot documentation to declare it as invalid. However, since the flag is not accepted as valid by any of the drivers (remote is just passthrough; esx and vbox don't support flags; qemu, test, and vz only support VIR_DOMAIN_XML_SECURE), and it is unlikely that the domain state saved off during a snapshot creation needs to be migration-friendly (as the snapshot is not the source of a migration), it is easier to just define an explicit set of supported flags directly related to the snapshot API rather than trying to borrow from domain API, and risking confusion if even more domain flags are added later (in fact, I have an upcoming patch that plans to add a new flag to virDomainGetXMLDesc that makes no sense for snapshots). There is no API or ABI impact (since we purposefully used unsigned int rather than an enum type in public API, and since the new flag name carries the same value as the reused name). Signed-off-by: NEric Blake <eblake@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Eric Blake 提交于
Commit d2a929d4 (0.9.4) defined virDomainSaveImageGetXMLDesc()'s use of @flags as a subset of virDomainXMLFlags, documenting that 2 of the 3 flags defined at the time would never be valid. Later, commit 28f8dfdc (1.0.0) introduced a new flag, VIR_DOMAIN_XML_MIGRATABLE, but did not adjust the save image documentation to declare it as invalid. Later, commit a67e3872 (3.7.0) blindly copied and pasted the same text into virDomainManagedSaveGetXMLDesc. However, since the flag is not accepted as valid by any of the drivers (remote is just passthrough; and qemu is the only supporting driver for either API, with support for just VIR_DOMAIN_XML_SECURE), it is easier to just define an explicit set of supported flags directly related to the save image API rather than trying to borrow from live domain API, and risking confusion if even more domain flags are added later (in fact, I have an upcoming patch that plans to add a new flag to virDomainGetXMLDesc that makes no sense for saved images). We may someday decide that saved images need to support the _MIGRATABLE flag, as it is possible to load a saved image with a different version of libvirt than the one that created it, but that can be a separate patch if it is ever needed. Meanwhile, it DOES make sense to reuse the same flags for SaveImage and for ManagedSave (since ManagedSave is really just sugar for creating a normal SaveImage in a location controlled by libvirt instead of by the user). There is no API or ABI impact (since we purposefully used unsigned int rather than an enum type in public API, and since the new flag name carries the same value as the old reused name). Signed-off-by: NEric Blake <eblake@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Eric Blake 提交于
Although VIR_DOMAIN_DEF_FORMAT_INACTIVE and VIR_DOMAIN_XML_INACTIVE happen to have the same value (1<<1), they come from different enums; and it is nicer to reason about a 'flags' variable if all uses of that variable are compared against the same enum type. Messed up in commit 06f75ff2 (3.8.0). Signed-off-by: NEric Blake <eblake@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Eric Blake 提交于
Many drivers had a comment that they did not validate the incoming 'flags' to virDomainGetXMLDesc() because they were relying on virDomainDefFormat() to do it instead. This used to be the case (at least since 461e0f1a and friends in 0.9.4 added unknown flag checking in general), but regressed in commit 0ecd6851 (1.2.12), when all of the drivers were changed to pass 'flags' through the new helper virDomainDefFormatConvertXMLFlags(). Since this helper silently ignores unknown flags, we need to implement flag checking in each driver instead. Annoyingly, this means that any new flag values added will silently be ignored when targeting an older libvirt, rather than our usual practice of loudly diagnosing an unsupported flag. Add comments in domain_conf.[ch] to remind us to be extra vigilant about the impact when adding flags (a new flag to add data is safe if the older server omitting the requested data doesn't break things in the newer client; a new flag to suppress data rather than enhancing the existing VIR_DOMAIN_XML_SECURE may form a data leak or even a security hole). In the qemu driver, there are multiple callers all funnelling to qemuDomainDefFormatBufInternal(); many of them already validated flags (and often only a subset of the full set of possible flags), but for ease of maintenance, we can also check flags at the common helper function. Signed-off-by: NEric Blake <eblake@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Chris Venteicher 提交于
qemuProcessQMPStart starts a QEMU process and monitor connection that can be used by multiple functions possibly for multiple QMP commands. The QMP exchange to exit capabilities negotiation mode and enter command mode can only be performed once after the monitor connection is established. Move responsibility for entering QMP command mode into the qemuProcessQMP code so multiple functions can issue QMP commands in arbitrary orders. This also simplifies the functions using the connection provided by qemuProcessQMPStart to issue QMP commands. Test code now needs to call qemuMonitorSetCapabilities to send the message to switch to command mode because the test code does not use the qemuProcessQMP command that internally calls qemuMonitorSetCapabilities. Signed-off-by: NChris Venteicher <cventeic@redhat.com> Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Chris Venteicher 提交于
Multiple QEMU processes for QMP commands can operate concurrently. Use a unique directory under libDir for each QEMU process to avoid pidfile and unix socket collision between processes. The pid file name is changed from "capabilities.pidfile" to "qmp.pid" because we no longer need to avoid a possible clash with a qemu domain called "capabilities" now that the processes artifacts are stored in their own unique temporary directories. "Capabilities" was changed to "qmp" in the pid file name because these processes are no longer specific to the capabilities usecase and are more generic in terms of being used for any general purpose QMP message exchanges with a QEMU process that is not associated with a domain. Signed-off-by: NChris Venteicher <cventeic@redhat.com> Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Jiri Denemark 提交于
Users qemuProcessQMP struct were always forced to call both qemuProcessQMPStop and qemuProcessQMPFree when they are done with the process. We can just call qemuProcessQMPStop from qemuProcessQMPFree and let users call qemuProcessQMPFree only. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-