|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v10 16/19] libxl: call hotplug scripts for nic devices from libxl
> + switch (nictype) {
> + case LIBXL_NIC_TYPE_VIF_IOEMU:
> + env[nr++] = "INTERFACE";
> + env[nr++] = libxl__strdup(gc, libxl__device_nic_devname(gc,
> + dev->domid, dev->devid,
> +
> LIBXL_NIC_TYPE_VIF_IOEMU));
Is this fall-through of the case deliberate? If so then a comment would
be good.
However I'm not sure about this. It seems like the hotplug scripts are
only called once in the VIF_IOEMU case? I would expect one call for the
PV VIF device and one for the TAP device? Perhaps I'm just missing the
location of the other one? Is this "num_exec" variable involved in some
way? But you don't propagate that to get_hotplug_env() and therefore
include *both* sets of env vars?
In any case something related seems to be broken for guests which use a
stub domain and use vifname=foo. What I see in that case is the script
called three times...
1. For the PV interface of the stub domain (LIBXL_NIC_TYPE_VIF),
renames vifX+1.0 -> foo-emu (*)
2. For the PV interface of the real domain
(LIBXL_NIC_TYPE_VIF_IOEMU part 1), renames vifX.0 -> foo
3. For the emu interface of the real domain
(LIBXL_NIC_TYPE_VIF_IOEMU part 2) renames vifX.0 -> foo-emu
The rename in #3 fails, because foo-emu already exists. But in fact this
call to the script should never happen for a domain with a stub domain
since the emulated device in this case is within the stub domain, not
the driver domain.
(*) This is with the patch I posted earlier to rename the stub domain's
vif with a -emu suffix. Without that then the clash is at #2 instead.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |