On 03/05/2014 10:53 AM, Daniel P. Berrange wrote:
Extracting capabilities from QEMU takes a notable amount of time
when all QEMU binaries are installed. Each system emulator
needs about 200-300ms multiplied by 26 binaries == ~5-8 seconds.
This change causes the QEMU driver to save an XML file containing
the content of the virQEMUCaps object instance in the cache
dir eg /var/cache/libvirt/qemu/capabilities/$SHA256(binarypath).xml
or $HOME/.cache/libvirt/qemu/cache/capabilities/$SHA256(binarypath).xml
We attempt to load this and only if it fails, do we fallback to
probing the QEMU binary. The timestamp of the file is compared to
the timestamp of the QEMU binary and discarded if the QEMU binary
is newer.
Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com>
---
src/qemu/qemu_capabilities.c | 412 ++++++++++++++++++++++++++++++++++++++++++-
src/qemu/qemu_capabilities.h | 2 +
src/qemu/qemu_driver.c | 1 +
3 files changed, 407 insertions(+), 8 deletions(-)
@@ -44,6 +45,7 @@
#include <unistd.h>
#include <sys/wait.h>
#include <stdarg.h>
+#include <utime.h>
<utime.h> (and the utime() function) is deprecated by POSIX and
therefore no longer portable because it corrupts sub-second timestamps.
Better is to use gnulib's utimensat (or futimens). But what timestamps
do we actually have to munge?
+
+ ut.actime = qemuCaps->mtime;
+ ut.modtime = qemuCaps->mtime;
+ if (utime(filename, &ut) < 0) {
+ virReportSystemError(errno,
+ _("Failed to set mtime on '%s' for
'%s'"),
+ filename, qemuCaps->binary);
Why not just store the qemu binary timestamp in the XML, rather than
playing games with the mtime of the xml file?
+
+ /* Discard if cache is older that QEMU binary */
+ /* XXX must also compare to libvirtd timestamp */
+ if (sb.st_mtime < qemuCaps->mtime) {
This ignores subsecond timestamps; you may want to use gnulib's
stat-time module to do a more accurate check.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org