From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olaf Hering Subject: calling vif hotplug scripts more than once Date: Tue, 8 Jul 2014 17:13:29 +0200 Message-ID: <20140708151329.GA5637@aepfle.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Roger Pau =?utf-8?B?TW9ubsOp?= , Ian Jackson , Ian Campbell Cc: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org There is a regression in libxl in its handling of hotplug scripts. Its not clear to me how to solve it. If in a Windows VM the network interface is disabled and reenabled in the "Network and Sharing Center", the backend remains in state 2 and the vif is not reconnected to the bridge. With xend all that was done via udev. If run_hotplug_scripts in /etc/xen/xl.conf is set to 0 it works as well. Looking through libxl it appears that libxl__device_nic_add -> libxl__wait_device_connection -> device_backend_callback -> device_hotplug does all the work. Unfortunately, device_backend_callback unregisters the watch, so no further events will be received. It seems device_backend_callback should call device_hotplug, and then register yet another watch to wait for state changes so that it eventually catches such a disable/enable event from the guest. Since all that is generic code, it seems this use case was not considered. It looks like a one-shot approach to me. I'm not sure how to fix this. Should device_backend_callback call into libxl__wait_device_connection again to wait (forever) for the next 'state==2'? Olaf