On Wed, 2013-12-18 at 14:12 +0100, Stefan Bader wrote:
On 18.12.2013 13:27, Ian Campbell wrote:
On Tue, 2013-12-17 at 18:32 +0100, Stefan Bader wrote:
Might this libxl fix be relevant: commit 5420f26507fc5c9853eb1076401a8658d72669da Author: Jim Fehlig <jfehlig@suse.com> Date: Fri Jan 11 12:22:26 2013 +0000
libxl: Set vfb and vkb devid if not done so by the caller
Other devices set a sensible devid if the caller has not done so. Do the same for vfb and vkb. While at it, factor out the common code used to determine a sensible devid, so it can be used by other libxl__device_*_add functions.
Signed-off-by: Jim Fehlig <jfehlig@suse.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> Committed-by: Ian Campbell <ian.campbell@citrix.com>
and a follow up in dfeccbeaa. Although the comment implies that nic's were already correctly assigning a devid if the caller specified -1, so I don't know why it doesn't work for you :-(
Ok, yes, the commit above indeed changes libxl__device_nic_add to call libxl__device_nextid for the devid... Just how is this actually called. Maybe not sufficient but "git grep libxl__device_nic_add" in the xen code only shows the definition and a declaration in libxl_internal.h to me...
I have a feeling a macro might be involved...
Here we go, look for DEFINE_DEVICE_REMOVE in libxl.c. We should really add the eventual function names in comments to provide grep fodder....
Oh duh, yeah. So in DEFINE_DEVICE_ADD a libxl_device_nic_add is created which calls to libxl__device_nic_add. When I look for the single _ version I find a call from xl_cmdimpl.c and its public declaration in libxl.h. So I guess the bug is that libvirt in the libxl driver never seems to do so
The macro creates libxl__add_nics which adds the nics from the libxl_domain_config->nics array. I don't think libvirt needs to call libxl_device_nic_add manually unless it is hotplugging a new nic at runtime.
. Ok, thanks a lot for digging the out the DEFINE. As nice those are to create similar functions from template, grep and tags fail to be helpful with them.
-Stefan
Ian.
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list