- Devel - libvirt List Archives

[libvirt] locking down struct size/layout in remote-protocol.x
by Jim Meyering 11 May '10

11 May '10

This week we noticed that a change to struct remote_error was causing trouble (new member addition changed the size of the object being decoded -- bad for the protocol). In order to ensure that no such changes sneak in again, I'm planning to do the following. First, count how many structs must not change size or layout: $ grep -E '^struct remote_' src/*/remote_protocol.x|wc -l 318 Obviously not appropriate to do it manually. Running this (pdwtags is part of the dwarves package): pdwtags src/libvirt_driver_remote_la-remote_protocol.o prints, among other things, detailed type info for every struct: /* 89 */ struct remote_nonnull_domain { remote_nonnull_string name; /* 0 8 */ remote_uuid uuid; /* 8 16 */ int id; /* 24 4 */ /* size: 32, cachelines: 1, members: 3 */ /* last cacheline: 32 bytes */ /* BRAIN FART ALERT! 32 != 28 + 0(holes), diff = 4 */ }; /* size: 32 */ /* 90 */ typedef struct remote_nonnull_domain remote_nonnull_domain; /* size: 32 */ /* 91 */ struct remote_nonnull_network { remote_nonnull_string name; /* 0 8 */ remote_uuid uuid; /* 8 16 */ /* size: 24, cachelines: 1, members: 2 */ /* last cacheline: 24 bytes */ }; /* size: 24 */ ----------------------------------------------------- A) For each of the above matching /^struct remote_/, print at the very least this sort of compile-time check: verify (sizeof (struct remote_nonnull_domain) == 32); verify (sizeof (struct remote_nonnull_network) == 24); B) Even better, verify member offsets, so that we'd detect reordered members (which often will not change struct size): verify (sizeof (struct remote_nonnull_domain) == 32); verify (offsetof (struct remote_nonnull_domain, name) == 0); verify (offsetof (struct remote_nonnull_domain, uuid) == 8); verify (offsetof (struct remote_nonnull_domain, id) == 24); verify (sizeof (struct remote_nonnull_network) == 24); verify (offsetof (struct remote_nonnull_network, name) == 0); verify (offsetof (struct remote_nonnull_network, uuid) == 16); C) Might as well verify member sizes as well. ----------------------------------------------------- Once we have a small script to generate that (RSN), include the generated, (and version-controlled) file from remote_protocol.c, and we're done. For reference, here's code to generate A): pdwtags src/libvirt_driver_remote_la-remote_protocol.o \ | perl -0777 -n \ -e 'foreach my $p (split m!\n\n/\* \d+ \*/\n!)' \ -e ' { $p =~ m!^struct (remote_\w+).*/\* size: (\d+) \*/!s' \ -e ' and print "verify (sizeof (struct $1) == $2);\n" }' And here's a sample of its output: verify (sizeof (struct remote_nonnull_domain) == 32); verify (sizeof (struct remote_nonnull_network) == 24); verify (sizeof (struct remote_nonnull_nwfilter) == 24); verify (sizeof (struct remote_nonnull_interface) == 16); verify (sizeof (struct remote_nonnull_storage_pool) == 24); verify (sizeof (struct remote_nonnull_storage_vol) == 24); verify (sizeof (struct remote_nonnull_node_device) == 8); ... verify (sizeof (struct remote_domain_has_current_snapshot_args) == 40); verify (sizeof (struct remote_domain_has_current_snapshot_ret) == 4); verify (sizeof (struct remote_domain_snapshot_current_args) == 40); verify (sizeof (struct remote_domain_snapshot_current_ret) == 40); verify (sizeof (struct remote_domain_revert_to_snapshot_args) == 48); verify (sizeof (struct remote_domain_snapshot_delete_args) == 48); verify (sizeof (struct remote_message_header) == 24);

3 15

[libvirt] [PATCH] delMacvtap: typo fix
by Eric Blake 11 May '10

11 May '10

* src/util/macvtap.c (delMacvtap): Fix documentation. --- Pushing as trivial. src/util/macvtap.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/util/macvtap.c b/src/util/macvtap.c index 5d129fd..1f8dd29 100644 --- a/src/util/macvtap.c +++ b/src/util/macvtap.c @@ -669,13 +669,13 @@ link_del_exit: return rc; } /** - * delMacvtapByName: + * delMacvtap: * @ifname : The name of the macvtap interface * * Delete an interface given its name. */ void delMacvtap(const char *ifname) -- 1.7.0.1

2 1

[libvirt] [PATCH] maint: allow VPATH use of remote_protocol-structs
by Eric Blake 10 May '10

10 May '10

* src/Makefile.am (remote_protocol-structs): Ensure file lives in srcdir. --- Jim's new check didn't quite work in a VPATH setup. I'm applying it as obvious, since it was a build-breaker: GEN remote_protocol-structs diff: remote_protocol-structs: No such file or directory make[3]: *** [remote_protocol-structs] Error 2 src/Makefile.am | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/Makefile.am b/src/Makefile.am index 1542ab1..15bc8fc 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -179,7 +179,7 @@ remote_protocol-structs: -e ' $$p =~ s!\s+$$!!;' \ -e ' print "$$p\n" } }' \ > $@-t; \ - diff -u $@-t $@; st=$$?; rm -f $@-t; exit $$st; \ + diff -u $@-t $(srcdir)/$@; st=$$?; rm -f $@-t; exit $$st; \ else \ echo 'WARNING: you lack pdwtags; skipping the $@ test'; \ echo 'WARNING: install the dwarves package to get pdwtags'; \ -- 1.7.0.1

1 0

[libvirt] [PATCH] build: fix autogen rule for VPATH build
by Eric Blake 10 May '10

10 May '10

* cfg.mk (gnulib_srcdir): Override maint.mk default. (_update_required): Run in correct directory. --- I noticed an error message about bootstrap.conf not found when trying to do a VPATH build for my new clang setup. This subsumes up my earlier patch to declare the correct gnulib_srcdir, as noticed by Jim, but does not advance to a newer .gnulib, as there are some other issues to fix on that front first. cfg.mk | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/cfg.mk b/cfg.mk index 105b625..a6e9204 100644 --- a/cfg.mk +++ b/cfg.mk @@ -24,6 +24,9 @@ gnu_rel_host = $(gnu_ftp_host-$(RELEASE_TYPE)) url_dir_list = \ ftp://$(gnu_rel_host)/gnu/coreutils +# We use .gnulib, not gnulib. +gnulib_srcdir = $(srcdir)/.gnulib + # Tests not to run as part of "make distcheck". local-checks-to-skip = \ changelog-check \ @@ -282,6 +285,7 @@ ifeq (0,$(MAKELEVEL)) # b653eda3ac4864de205419d9f41eec267cb89eeb _submodule_hash = sed 's/^[ +-]//;s/ .*//' _update_required := $(shell \ + cd '$(srcdir)'; \ actual=$$(git submodule status | $(_submodule_hash); \ git hash-object bootstrap.conf; \ git diff .gnulib); \ -- 1.6.6.1

4 18

[libvirt] question on network interface of LXC domain
by Osier Yang 10 May '10

10 May '10

Hello there with newest libvirt, when I connect to the container via console, then execute "ifconfig", there will be no output, though the network works fine. and "/proc/net/dev" of container seems good too. (has entries about "eth0" and "lo"). I traced the call procedure of "ifconfig", it reads the infomations of network interface from "/proc/net/dev" and vise visa. so I'm confused about what cause this problem. there is no problem with libvirt-0.8.0-4. Thanks and Regards Osier

2 1

[libvirt] [PATCH] more interface functions; some needed for VEPA
by Stefan Berger 07 May '10

07 May '10

In the attached patch I am refactoring the function that changes the flags on an interface to call a separate function to first read the flags on the interface. This function that reads the flags then becomes public. I am also adding a function that test whether an interface is currently up. This prevents other code to have to include interface related include files. Then there is a new function that reads the VLANid of a VLAN interface via an ioctl(). This one will be needed by upcoming VEPA related patches. On cygwin for example none of the newly added functions are available. The flags related function could not be exported due to missing PF_PACKET -- or maybe other type of protocol that needs to be used when opening the socket for running the ioctl() on. Signed-off-by: Stefan Berger <stefanb(a)us.ibm.com> --- src/libvirt_private.syms | 2 + src/util/interface.c | 76 ++++++++++++++++++++++++++++++++++++++++------- src/util/interface.h | 3 + 3 files changed, 70 insertions(+), 11 deletions(-) Index: libvirt-acl/src/util/interface.c =================================================================== --- libvirt-acl.orig/src/util/interface.c +++ libvirt-acl/src/util/interface.c @@ -30,6 +30,8 @@ #ifdef __linux__ # include <linux/if.h> +# include <linux/sockios.h> +# include <linux/if_vlan.h> #endif #include "internal.h" @@ -42,6 +44,85 @@ virReportErrorHelper(NULL, VIR_FROM_NET, code, __FILE__, \ __FUNCTION__, __LINE__, __VA_ARGS__) +#if __linux__ +static int +getFlags(int fd, const char *ifname, struct ifreq *ifr) { + + memset(ifr, 0, sizeof(*ifr)); + + if (virStrncpy(ifr->ifr_name, + ifname, strlen(ifname), sizeof(ifr->ifr_name)) == NULL) + return ENODEV; + + if (ioctl(fd, SIOCGIFFLAGS, ifr) < 0) + return errno; + + return 0; +} + + +/** + * ifaceGetFlags + * + * @ifname : name of the interface + * @flags : pointer to short holding the flags on success + * + * Get the flags of the interface. Returns 0 on success, error code on failure. + */ +int +ifaceGetFlags(const char *ifname, short *flags) { + struct ifreq ifr; + int rc; + int fd = socket(PF_PACKET, SOCK_DGRAM, 0); + + if (fd < 0) + return errno; + + rc = getFlags(fd, ifname, &ifr); + + *flags = ifr.ifr_flags; + + close(fd); + + return rc; +} + + +int +ifaceIsUp(const char *ifname, bool *up) { + short flags; + int rc = ifaceGetFlags(ifname, &flags); + + if (rc) + return rc; + + *up = ((flags & IFF_UP) == IFF_UP); + + return 0; +} +#else + +/* Note: Showstopper on cygwin is only missing PF_PACKET */ + +int +ifaceGetFlags(const char *ifname ATTRIBUTE_UNUSED, + short *flags ATTRIBUTE_UNUSED) { + ifaceError(VIR_ERR_INTERNAL_ERROR, "%s", + _("ifaceGetFlags is not supported on non-linux platforms")); + return ENOSYS; +} + +int +ifaceIsUp(const char *ifname ATTRIBUTE_UNUSED, + bool *up ATTRIBUTE_UNUSED) { + + ifaceError(VIR_ERR_INTERNAL_ERROR, "%s", + _("ifaceIsUp is not supported on non-linux platforms")); + return ENOSYS; +} + +#endif /* __linux__ */ + /* * chgIfaceFlags: Change flags on an interface * @@ -59,23 +140,16 @@ static int chgIfaceFlags(const char *ifname, short flagclear, short flagset) { struct ifreq ifr; int rc = 0; - int flags; + short flags; short flagmask = (~0 ^ flagclear); int fd = socket(PF_PACKET, SOCK_DGRAM, 0); if (fd < 0) return errno; - if (virStrncpy(ifr.ifr_name, - ifname, strlen(ifname), sizeof(ifr.ifr_name)) == NULL) { - rc = ENODEV; + rc = getFlags(fd, ifname, &ifr); + if (rc != 0) goto err_exit; - } - - if (ioctl(fd, SIOCGIFFLAGS, &ifr) < 0) { - rc = errno; - goto err_exit; - } flags = (ifr.ifr_flags & flagmask) | flagset; @@ -151,6 +225,8 @@ ifaceCheck(bool reportError, const char if (fd < 0) return errno; + memset(&ifr, 0, sizeof(ifr)); + if (virStrncpy(ifr.ifr_name, ifname, strlen(ifname), sizeof(ifr.ifr_name)) == NULL) { if (reportError) @@ -227,6 +303,8 @@ ifaceGetIndex(bool reportError, const ch if (fd < 0) return errno; + memset(&ifreq, 0, sizeof(ifreq)); + if (virStrncpy(ifreq.ifr_name, ifname, strlen(ifname), sizeof(ifreq.ifr_name)) == NULL) { if (reportError) @@ -269,3 +347,46 @@ ifaceGetIndex(bool reportError, } #endif /* __linux__ */ + +#ifdef __linux__ +int +ifaceGetVlanID(const char *vlanifname, int *vlanid) { + struct vlan_ioctl_args vlanargs = { + .cmd = GET_VLAN_VID_CMD, + }; + int rc = 0; + int fd = socket(PF_PACKET, SOCK_DGRAM, 0); + + if (fd < 0) + return errno; + + if (virStrcpyStatic(vlanargs.device1, vlanifname) == NULL) { + rc = EINVAL; + goto err_exit; + } + + if (ioctl(fd, SIOCGIFVLAN, &vlanargs) != 0) { + rc = errno; + goto err_exit; + } + + *vlanid = vlanargs.u.VID; + + err_exit: + close(fd); + + return rc; +} + +#else + +int +ifaceGetVlanID(const char *vlanifname ATTRIBUTE_UNUSED, + int *vlanid ATTRIBUTE_UNUSED) { + + ifaceError(VIR_ERR_INTERNAL_ERROR, "%s", + _("ifaceGetVlanID is not supported on non-linux platforms")); + + return ENOSYS; +} +#endif /* __linux__ */ Index: libvirt-acl/src/util/interface.h =================================================================== --- libvirt-acl.orig/src/util/interface.h +++ libvirt-acl/src/util/interface.h @@ -12,6 +12,9 @@ # include "datatypes.h" +int ifaceGetFlags(const char *name, short *flags); +int ifaceIsUp(const char *name, bool *up); + int ifaceCtrl(const char *name, bool up); static inline int ifaceUp(const char *name) { @@ -27,4 +30,6 @@ int ifaceCheck(bool reportError, const c int ifaceGetIndex(bool reportError, const char *ifname, int *ifindex); +int ifaceGetVlanID(const char *vlanifname, int *vlanid); + #endif /* __VIR_INTERFACE_H__ */ Index: libvirt-acl/src/libvirt_private.syms =================================================================== --- libvirt-acl.orig/src/libvirt_private.syms +++ libvirt-acl/src/libvirt_private.syms @@ -685,6 +685,9 @@ virArgvToString; ifaceCtrl; ifaceCheck; ifaceGetIndex; +ifaceGetFlags; +ifaceIsUp; +ifaceGetVlanID; # usb.h usbGetDevice;

2 3

[libvirt] [PATCH] mingw32-libvirt.spec: bring up to date
by Eric Blake 07 May '10

07 May '10

Right now, mingw32-portablexdr is not available in Fedora, but is present in fedora-mingw.git. With that package, plus redhat-rpm-config and this patch, it is once again possible to build mingw32-libvirt from a Fedora 12 host. * mingw32-libvirt.spec.in (__debug_install_post): Override. (%files): Mention recent additions. --- The __debug_install_post trick is something that Richard Jones taught me while figuring out how to get mingw32-portablexdr. Also, during that effort, we discovered this bug in rpm: https://bugzilla.redhat.com/show_bug.cgi?id=587818 you have to have redhat-rpm-config installed to work around it. mingw32-libvirt.spec.in | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/mingw32-libvirt.spec.in b/mingw32-libvirt.spec.in index 867a849..fc90203 100644 --- a/mingw32-libvirt.spec.in +++ b/mingw32-libvirt.spec.in @@ -3,6 +3,7 @@ %define _use_internal_dependency_generator 0 %define __find_requires %{_mingw32_findrequires} %define __find_provides %{_mingw32_findprovides} +%define __debug_install_post %{_mingw32_debug_install_post} Name: mingw32-libvirt Version: @VERSION@ @@ -30,6 +31,7 @@ BuildRequires: gettext BuildArch: noarch +%{?_mingw32_debug_package} %description MinGW Windows libvirt virtualization library. @@ -95,9 +97,12 @@ rm -rf $RPM_BUILD_ROOT %{_mingw32_datadir}/libvirt/schemas/nodedev.rng %{_mingw32_datadir}/libvirt/schemas/capability.rng %{_mingw32_datadir}/libvirt/schemas/interface.rng +%{_mingw32_datadir}/libvirt/schemas/nwfilter.rng %{_mingw32_datadir}/libvirt/schemas/secret.rng %{_mingw32_datadir}/libvirt/schemas/storageencryption.rng +%{_mingw32_datadir}/libvirt/cpu_map.xml + %{_mingw32_datadir}/locale/*/LC_MESSAGES/libvirt.mo %dir %{_mingw32_includedir}/libvirt -- 1.6.6.1

2 2

[libvirt] [PATCH] Fix pthread related link error for virt-aa-helper
by Matthias Bolte 07 May '10

07 May '10

Link virt-aa-helper explicitly with pthread. This is at least required on Ubuntu 10.04. --- I just pushed this one, as it qualifies as trivial compile fix. src/Makefile.am | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/Makefile.am b/src/Makefile.am index 2025208..0da30bb 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -1002,7 +1002,7 @@ libexec_PROGRAMS += virt-aa-helper virt_aa_helper_SOURCES = $(SECURITY_DRIVER_APPARMOR_HELPER_SOURCES) -virt_aa_helper_LDFLAGS = $(WARN_CFLAGS) +virt_aa_helper_LDFLAGS = $(WARN_CFLAGS) $(LIB_PTHREAD) virt_aa_helper_LDADD = \ $(WARN_CFLAGS) \ $(LIBXML_LIBS) \ -- 1.7.0.4

3 10

[libvirt] small typo in "Terminology and goals" page
by Ersek, Laszlo 07 May '10

07 May '10

Hi, there seems to be a typo in http://libvirt.org/goals.html "Multiple mode may be accessed with libvirt simultaneously but the APIs are limited to single node operations." I think that was intended as "Multiple *nodes*". If not: sorry :) Cheers, lacos

2 1

[libvirt] [Reminder] KVM Forum 2010: Call for Papers
by KVM Forum 2010 Program Committee 07 May '10

07 May '10

Just a reminder...The submission deadline is in one week. thanks, -KVM Forum 2010 Program Commitee -- ================================================================= CALL FOR PAPERS KVM Forum 2010 ================================================================= DESCRIPTION The KVM Forum is back! After a break last year we're proud to present this year's gathering around KVM again. The idea is to have everyone involved with KVM development come together to talk about the future and current state of KVM, teaching everyone some pieces of the puzzle they might be missing without. So if you're a KVM developer, mark the dates in your calendar! If possible, also submit a talk -- we're interested in a wide variety of KVM topics, so don't hesitate to propose a talk on your work. If you're not a KVM developer, please read on nevertheless (or jump to END USER COLLABORATION). DATES / LOCATION Conference: August 9 - 10, 2010 Location: Renaissance Boston Waterfront in Boston, MA Abstracts due: May 14th, 2010 Notification: May 28th, 2010 Yes, we're colocated with LinuxCon. Tickets for the KVM Forum also count for LinuxCon. http://events.linuxfoundation.org/component/registrationpro/?func=details&d… PROCESS At first check if it's before May 14th. If you're past that date, you're out of luck. Now try to think hard and come up with a great idea that you could talk about. Once you have that set, we need you to write up a short abstract (~150 words) on it. In your submission please note how long your talk will take. Slots vary in length up to one hour. Also include in your proposal the proposal type -- one of: technical talk, breakout session, or end-user talk. Add that information to the abstract and submit it at the following URL: http://events.linuxfoundation.org/cfp/cfp-add Now, wait until May 24th. You will receive a notification on whether your talk was accepted or not. SCOPE OF TALKS We have a list of suggested presentation topics below. These suggestions are just for guidance, please feel free to submit a proposal on any of these or related topics. In general, the more it's about backend infrastructure, the better. KVM - Scaling and performance - Nested virtualization - I/O improvements - Driver domains - Time keeping - Memory management (page sharing, swapping, huge pages, etc) - Fault tolerance - VEPA, vswitch Embedded KVM - KVM on ARM, PPC, MIPS, ...? - Real-time requirements host/guest - Device pass-through w/o iommu - Custom device/platform models QEMU - Device model improvements - New devices - Security model - Scaling and performance - Desktop virtualization - Increasing robustness - Management interfaces - QMP protocol and implementation - Live migration Virtio - Speeding up existing devices - Vhost - Alternatives - Using virtio in non-kvm environments - Virtio on non-Linux Management infrastructure - Libvirt - Kvm autotest - Easy networking - Qemud BREAKOUT SESSION We will reserve some time each day to break out for working sessions. These sessions will be less formal than a presentation and more focused on developing a solution to some real development issue. If you are interested in getting developers together to hack on some code, submit your proposal and just make it clear it's a breakout session proposal. END-USER COLLABORATION One of the big challenges as developers is to know what, where and how people actually use our software. To solve this issue at least a little, there will be a few slots reserved for end users talking about their deployments, problems and achievements. So if you have a KVM based deployment running in production or are about to roll out one, please also submit a talk (see PROCESS), and simply mark it asn an end-user collaboration proposal. We would love to have an open discussion of fields where KVM/Qemu can still improve and you would have the unique chance to steer that process! Keep in mind that most of the Forum will be focused on development though, so we suggest you also come with a good portion of technical interest :-). And of course, no product marketing please! The purpose is to engage with KVM developers. LIGHTNING TALKS In addition to submitted talks we will also have some room for lightning talks. So if you have something you think might be done until the KVM Forum, but you're not sure you could fill 15 minutes with it. Or if you don't know if you'll make it until there, just keep in mind that you will still get the chance to talk about it. Lightning talk submissions and scheduling will be handled on-site at KVM Forum. Thank you for your interest in KVM. We're looking forward to your submissions and seeing you at the KVM Forum 2010 in August! Now, start thinking about that talk you want to give. Thanks, your KVM Forum 2010 Program Commitee Alexander Graf, Novell Anthony Liguori, IBM Avi Kivity, Red Hat Chris Wright, Red Hat Dor Laor, Red Hat Jan Kiszka, Siemens Please contact us with any questions or comments. KVM-Forum-2010-PC(a)redhat.com

1 0