[Xen-devel] [Patch] Fix broken package config file xenlight.pc.in

2017-05-11 Thread Charles Arnold
The Requires line in this config file uses the wrong names for two dependencies.

The package config file for xenctrl is called 'xencontrol' and for blktapctl is
called 'xenblktapctl'. Running a command like 'pkg-config --exists xenlight' 
will
fail without this fix.

Signed-off-by: Charles Arnold <carn...@suse.com>

diff --git a/tools/libxl/xenlight.pc.in b/tools/libxl/xenlight.pc.in
index 71d093a0ae..86c38a5634 100644
--- a/tools/libxl/xenlight.pc.in
+++ b/tools/libxl/xenlight.pc.in
@@ -9,4 +9,4 @@ Description: The Xenlight library for Xen hypervisor
 Version: @@version@@
 Cflags: -I${includedir}
 Libs: @@libsflag@@${libdir} -lxenlight
-Requires.private: xentoollog,xenevtchn,xenctrl,xenguest,xenstore,blktapctl
+Requires.private: 
xentoollog,xenevtchn,xencontrol,xenguest,xenstore,xenblktapctl



___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel


[Xen-devel] Is there any limitation on the firmware size in Xen?

2017-05-10 Thread Charles Arnold
I was asked the following question which I am posting to the list.

"
My name is Gary Lin, and I am the maintainer of the OVMF package, a UEFI
implementation for the virtual machines.

Recently, I was testing an upstream patchset[*] and encountered some
problems in Xen. Maybe you can help me or give me some hints.

To be short, the edk2/ovmf upstream is going to increase the firmware
size from 2MB to 4MB to fulfill windows HCK, and we have to test
different types of VM to make sure the patchset really work. When I was
using the 2MB build, my Xen HVM worked as expected and showed the boot
menu. However, if I use the 4MB build, I got something like this from
"xl dmesg":

(d32)  - CPU0 ... 39-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... done.
(d32) Testing HVM environment:
(d32)  - REP INSB across page boundaries ... passed
(d32)  - GS base MSRs and SWAPGS ... passed
(d32) Passed 2 of 2 tests
(d32) Writing SMBIOS tables ...
(d32) Loading OVMF ...
(d32) no BIOS ROM image found
(d32) *** HVMLoader bug at hvmloader.c:389
(d32) *** HVMLoader crashed.

I tried to trace the code and found that in libxl__load_hvm_firmware_module()
in tools/libxl/libxl_dom.c actully loaded the file and add_module_to_list()
in tools/libxc/xc_dom_x86.c was loading a firmware "module" with 4194304
bytes. However, when hvmloader loaded "bios_module" with get_module_entry(),
modlist is NULL. It seems the firmware data was removed for some reason.

Here are my questions:

1. Is there any limitation on the firmware size in Xen?

2. How is hvm_start_info passed to hvmloader?

Thanks,

Gary Lin

[*] https://github.com/lersek/edk2.git branch emu4k
"

- Charles



___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel


[Xen-devel] [PATCH] tools: fix vif-route add|remove

2016-09-07 Thread Charles Arnold
From 2b4e942ad75f4a4546c417d8bd1116e3af368daf Mon Sep 17 00:00:00 2001
From: Charles Arnold <carn...@suse.com>
Date: Wed, 7 Sep 2016 09:48:18 -0600
Subject: [PATCH] tools: fix vif-route add|remove

vif-route is called twice. First for the vif interface and
second for the vif-emu interface. vif-route takes 4 parameters,

(add|remove|online|offline)

When called with 'online|offline' then 'ipcmd' is set. When called
with 'add|remove' then 'ipcmd' is empty ('') and the command,

${cmdprefix} ip route ${ipcmd} ${addr} dev ${dev} src ${main_ip}

will fail.

Signed-off-by: Charles Arnold <carn...@suse.com>
---
 tools/hotplug/Linux/vif-route | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/hotplug/Linux/vif-route b/tools/hotplug/Linux/vif-route
index c149ffc..d49eb20 100644
--- a/tools/hotplug/Linux/vif-route
+++ b/tools/hotplug/Linux/vif-route
@@ -35,7 +35,7 @@ case "${command}" in
 ;;
 esac
 
-if [ "${ip}" ] ; then
+if [ "${ip}" ] && [ "${ipcmd}" ] ; then
 # If we've been given a list of IP addresses, then add routes from dom0 to
 # the guest using those addresses.
 for addr in ${ip} ; do
-- 
1.8.5.6




___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel


[Xen-devel] [PATCH] libxl: 'valid_devs' may be used uninitialized

2015-05-15 Thread Charles Arnold
Using gcc 4.8 to compile with -Werror.

xl_cmdimpl.c:5493:8: error: 'valid_devs' may be used uninitialized in this 
function [-Werror=maybe-uninitialized]
  if (valid_devs == 0)
 ^
xl_cmdimpl.c:5455:9: note: 'valid_devs' was declared here
  int valid_devs;

Signed-off-by: Charles Arnold carn...@suse.com

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 373aa37..6d60ce4 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -5423,7 +5423,7 @@ static void output_topologyinfo(void)
 libxl_cputopology *cpuinfo;
 int i, nr;
 libxl_pcitopology *pciinfo;
-int valid_devs;
+int valid_devs = 0;
 
 
 cpuinfo = libxl_get_cpu_topology(ctx, nr);



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


Re: [Xen-devel] New Defects reported by Coverity Scan for XenProject

2015-04-02 Thread Charles Arnold
 On 4/2/2015 at 08:32 AM, Ian Campbell ian.campb...@citrix.com wrote: 
 Hi Charles,
 
 I'm not sure if this is a real issue in the qdisk support for xenstat,
 but I think it may relate to the first return 0 in qmp_read which may
 not free the accumulated array.

Yes. That is a leak on the failure case.

 
 Could you take a look please?

Patch sent, Thanks

- Charles

 
 Ian.
 
 On Wed, 2015-04-01 at 05:51 -0700, scan-ad...@coverity.com wrote:
 Hi,
 
 Please find the latest report on new defect(s) introduced to XenProject 
 found with Coverity Scan.
 
 1 new defect(s) introduced to XenProject found with Coverity Scan.
 2 defect(s), reported by Coverity Scan earlier, were marked fixed in the 
 recent build analyzed by Coverity Scan.
 
 New defect(s) Reported-by: Coverity Scan
 Showing 1 of 1 defect(s)
 
 
 ** CID 1292691:  Resource leaks  (RESOURCE_LEAK)
 /tools/xenstat/libxenstat/src/xenstat_qmp.c: 327 in qmp_query()
 
 
 
 _
 ___
 *** CID 1292691:  Resource leaks  (RESOURCE_LEAK)
 /tools/xenstat/libxenstat/src/xenstat_qmp.c: 327 in qmp_query()
 321  int n;
 322 
 323  n = strlen(cmd);
 324  if (qmp_write(qfd, cmd, n) != n)
 325  return NULL;
 326  if (!qmp_read(qfd, qstats))
  CID 1292691:  Resource leaks  (RESOURCE_LEAK)
  Variable qstats going out of scope leaks the storage it points to.
 327  return NULL;
 328  return qstats;
 329 }
 330 
 331 /* Returns a socket connected to the QMP socket. Returns -1 on 
 failure. */
 332 static int qmp_connect(char *path)
 
 
 
 _
 ___
 To view the defects in Coverity Scan visit, 
 https://scan.coverity.com/projects/606?tab=overview
 
 To manage Coverity Scan email notifications for ian.campb...@citrix.com, 
 click 
 https://scan.coverity.com/subscriptions/edit?email=ian.campbell%40citrix.comt
 oken=1ce0fc428b9f94f66fd8d1ecf6cbb76a .
 



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


[Xen-devel] [PATCH] xentop: fix potential memory leak

2015-04-02 Thread Charles Arnold
On a read failure the qstats buffer is not freed.

Signed-off-by: Charles Arnold carn...@suse.com

diff --git a/tools/xenstat/libxenstat/src/xenstat_qmp.c 
b/tools/xenstat/libxenstat/src/xenstat_qmp.c
index c217b8e..2cb99e9 100644
--- a/tools/xenstat/libxenstat/src/xenstat_qmp.c
+++ b/tools/xenstat/libxenstat/src/xenstat_qmp.c
@@ -298,6 +298,7 @@ static int qmp_read(int qfd, unsigned char **qstats)
while ((n = poll(pfd, POLLIN, 10))  0) {
if (pfd[0].revents  POLLIN) {
if ((n = read(qfd, buf, sizeof(buf)))  0) {
+   free(*qstats);
return 0;
}
ptr = realloc(*qstats, qsize+n+1);



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


Re: [Xen-devel] [PATCH v3] xentop: add support for qdisks

2015-03-24 Thread Charles Arnold
 On 3/24/2015 at 09:01 AM, Ian Campbell ian.campb...@citrix.com wrote: 
 On Mon, 2015-03-23 at 20:55 -0600, Charles Arnold wrote:
 
 +/* Get up to 1024 active domains */
 
 What I meant last time was, is this limitation a concern? What if there
 are 1025 domains?

This is actually a limit I picked up from libxl.  See libxl.c 
libxl_list_domain()
which is consumed in several places.  I guess I assumed this was some official
limit.  This version of the patch would simply ignore any VMs beyond 1024.

 
 If this is a concern then perhaps refactor such that the qdisk stats
 gathering collection can happen from the inner loop of xenstat_get_node,
 i.e. near the call to domain_get_tmem_stats, then you would be given the
 single domain of interest. Might simplify some other stuff too.

This would certainly eliminate the 1024 limit. This may become important
for running xentop in batch mode where the output can be captured. For
normal screen viewing, I doubt anyone has a screen with more that 1024
lines on which to view the output :)

I'll code up another version with your suggestion.

- Charles



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


Re: [Xen-devel] [PATCH v2] xentop: add support for qdisks

2015-03-19 Thread Charles Arnold
 On 3/19/2015 at 12:09 PM, Anthony PERARD anthony.per...@citrix.com wrote: 
 On Wed, Mar 18, 2015 at 04:12:26PM +, Ian Campbell wrote:
 My second concern here is with the use of /var/run/xen/qmp-libxl-%i from
 outside of libxl. I can't remember if qemu is safe against multiple
 users of the socket. ISTR asking Anthony this before, but I don't recall
 the answer, sorry :-(
 
 Last time I checked, only one client at a time can connect to the socket.
 If a second user want to connect to the socket, it will be blocked until
 the first one disconnect.

This seems correct based on some of my testing.  In rare cases (perhaps not so
rare for VMs under heavy I/O load), reading the socket to get the stats times 
out
and so xentop will report '0' for the read/write stats until the next read 
attempt
that succeeds.

It looks as if we do need a second socket to qemu.  I will include that in the 
next
patch version.

- Charles



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


[Xen-devel] [PATCH v2] xentop: add support for qdisks

2015-03-11 Thread Charles Arnold
Now that Xen uses qdisks by default and qemu does not write out
statistics to sysfs this patch queries the QMP for disk statistics.

This patch depends on libyajl for parsing statistics returned from
QMP. The runtime requires libyajl 2.0.3 or newer for required bug
fixes in yajl_tree_parse().

No interfaces have been changed. It works within the existing
framework of libxenstat.

Signed-off-by: Charles Arnold carn...@suse.com

diff --git a/tools/xenstat/libxenstat/Makefile 
b/tools/xenstat/libxenstat/Makefile
index 07d39b1..6a69f7e 100644
--- a/tools/xenstat/libxenstat/Makefile
+++ b/tools/xenstat/libxenstat/Makefile
@@ -24,7 +24,7 @@ MINOR=0
 LIB=src/libxenstat.a
 SHLIB=src/libxenstat.so.$(MAJOR).$(MINOR)
 SHLIB_LINKS=src/libxenstat.so.$(MAJOR) src/libxenstat.so
-OBJECTS-y=src/xenstat.o
+OBJECTS-y=src/xenstat.o src/xenstat_qmp.o
 OBJECTS-$(CONFIG_Linux) += src/xenstat_linux.o
 OBJECTS-$(CONFIG_SunOS) += src/xenstat_solaris.o
 OBJECTS-$(CONFIG_NetBSD) += src/xenstat_netbsd.o
diff --git a/tools/xenstat/libxenstat/src/xenstat.c 
b/tools/xenstat/libxenstat/src/xenstat.c
index 8072a90..f3847be 100644
--- a/tools/xenstat/libxenstat/src/xenstat.c
+++ b/tools/xenstat/libxenstat/src/xenstat.c
@@ -657,6 +657,24 @@ static void xenstat_uninit_xen_version(xenstat_handle * 
handle)
  * VBD functions
  */
 
+/* Save VBD information */
+xenstat_vbd *xenstat_save_vbd(xenstat_domain *domain, xenstat_vbd *vbd)
+{
+if (domain-vbds == NULL) {
+domain-num_vbds = 1;
+domain-vbds = malloc(sizeof(xenstat_vbd));
+} else {
+domain-num_vbds++;
+domain-vbds = realloc(domain-vbds,
+   domain-num_vbds *
+   sizeof(xenstat_vbd));
+}
+if (domain-vbds != NULL)
+domain-vbds[domain-num_vbds - 1] = *vbd;
+
+return domain-vbds;
+}
+
 /* Free VBD information */
 static void xenstat_free_vbds(xenstat_node * node)
 {
diff --git a/tools/xenstat/libxenstat/src/xenstat_linux.c 
b/tools/xenstat/libxenstat/src/xenstat_linux.c
index 7fdf70a..2cc9c7f 100644
--- a/tools/xenstat/libxenstat/src/xenstat_linux.c
+++ b/tools/xenstat/libxenstat/src/xenstat_linux.c
@@ -417,6 +417,9 @@ int xenstat_collect_vbds(xenstat_node * node)
}
}
 
+   /* Get qdisk statistics */
+   read_attributes_qdisk(node);
+
rewinddir(priv-sysfsvbd);
 
for(dp = readdir(priv-sysfsvbd); dp != NULL ;
@@ -477,18 +480,10 @@ int xenstat_collect_vbds(xenstat_node * node)
continue;
}
 
-   if (domain-vbds == NULL) {
-   domain-num_vbds = 1;
-   domain-vbds = malloc(sizeof(xenstat_vbd));
-   } else {
-   domain-num_vbds++;
-   domain-vbds = realloc(domain-vbds,
-  domain-num_vbds *
-  sizeof(xenstat_vbd));
-   }
-   if (domain-vbds == NULL)
+   if ((xenstat_save_vbd(domain, vbd)) == NULL) {
+   perror(Allocation error);
return 0;
-   domain-vbds[domain-num_vbds - 1] = vbd;
+   }
}
 
return 1;   
diff --git a/tools/xenstat/libxenstat/src/xenstat_priv.h 
b/tools/xenstat/libxenstat/src/xenstat_priv.h
index 8490e23..74e0774 100644
--- a/tools/xenstat/libxenstat/src/xenstat_priv.h
+++ b/tools/xenstat/libxenstat/src/xenstat_priv.h
@@ -109,5 +109,7 @@ extern int xenstat_collect_networks(xenstat_node * node);
 extern void xenstat_uninit_networks(xenstat_handle * handle);
 extern int xenstat_collect_vbds(xenstat_node * node);
 extern void xenstat_uninit_vbds(xenstat_handle * handle);
+extern void read_attributes_qdisk(xenstat_node * node);
+extern xenstat_vbd *xenstat_save_vbd(xenstat_domain * domain, xenstat_vbd * 
vbd);
 
 #endif /* XENSTAT_PRIV_H */
diff --git a/tools/xenstat/xentop/Makefile b/tools/xenstat/xentop/Makefile
index e2665aa..5376fdc 100644
--- a/tools/xenstat/xentop/Makefile
+++ b/tools/xenstat/xentop/Makefile
@@ -19,7 +19,7 @@ all install xentop:
 else
 
 CFLAGS += -DGCC_PRINTF -Werror $(CFLAGS_libxenstat)
-LDLIBS += $(LDLIBS_libxenstat) $(CURSES_LIBS) $(SOCKET_LIBS) -lm
+LDLIBS += $(LDLIBS_libxenstat) $(CURSES_LIBS) $(SOCKET_LIBS) -lm -lyajl
 CFLAGS += -DHOST_$(XEN_OS)
 
 # Include configure output (config.h) to headers search path
diff --git a/tools/xenstat/libxenstat/src/xenstat_qmp.c 
b/tools/xenstat/libxenstat/src/xenstat_qmp.c
new file mode 100644
index 000..aac4637
--- /dev/null
+++ b/tools/xenstat/libxenstat/src/xenstat_qmp.c
@@ -0,0 +1,387 @@
+/* libxenstat: statistics-collection library for Xen
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation

Re: [Xen-devel] [RFC PATCH] xentop: add support for qdisks

2015-02-20 Thread Charles Arnold
 On 2/20/2015 at 11:10 AM, Charles Arnold wrote: 
 Now that Xen uses qdisks by default and qemu does not write out
 statistics to sysfs this patch queries the QMP for disk statistics.

Forget this patch. I assumed the name of the xenstore backend device
(eg, xvda, hda, etc) would be the same name as used by qemu and it is
not.

- Charles



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


[Xen-devel] [RFC PATCH] xentop: add support for qdisks

2015-02-20 Thread Charles Arnold
Now that Xen uses qdisks by default and qemu does not write out
statistics to sysfs this patch queries the QMP for disk statistics.

Signed-off-by: Charles Arnold carn...@suse.com

diff --git a/tools/xenstat/libxenstat/src/xenstat_linux.c 
b/tools/xenstat/libxenstat/src/xenstat_linux.c
index 7fdf70a..885d089 100644
--- a/tools/xenstat/libxenstat/src/xenstat_linux.c
+++ b/tools/xenstat/libxenstat/src/xenstat_linux.c
@@ -24,11 +24,15 @@
 #include dirent.h
 #include sys/types.h
 #include sys/stat.h
+#include sys/socket.h
+#include sys/poll.h
+#include sys/un.h
 #include stdio.h
 #include stdlib.h
 #include string.h
 #include unistd.h
 #include regex.h
+#include errno.h
 
 #include xenstat_priv.h
 
@@ -398,6 +402,258 @@ static int read_attributes_vbd(const char *vbd_directory, 
const char *what, char
return num_read;
 }
 
+/* Given an object name look up its value in the buffer */
+static void qmp_lookup_object(unsigned char *buf, char *name, unsigned long 
long *value)
+{
+   unsigned char *ptr;
+   int len;
+
+   *value = 0;
+   len = strlen((char *)name);
+   for (ptr=buf; *ptr; ptr++) {
+   if ( !strncmp((char *)ptr, name, len) ) {
+   ptr += len;
+   while (*ptr == ' ')
+   ++ptr;
+   (void)sscanf((char *)ptr, %llu, value);
+   break;
+   }
+   }
+}
+
+/* Starting at the opening brace of an object, go until the closing is found */
+static unsigned char *qmp_skip_object(unsigned char *obj)
+{
+   unsigned char *end;
+   int brace = 0;
+
+   if ( *obj != '{' )
+   return obj;
+   for ( end=obj; *end; end++ ) {
+   if ( *end == '{' )
+   ++brace;
+   else if ( *end == '}' )
+   --brace;
+   if ( brace = 0 ) {
+   ++end;
+   break;
+   }
+   }
+   return end;
+}
+
+/*
+  Parse disk statistics from QMP
+  A single query-blockstats QMP call will get all disks belonging to the VM.
+  We need to parse that data and get the stats for the vbd we care about.
+*/
+static void qmp_parse(unsigned char *stats, unsigned int domid,
+   unsigned char *vbdname, unsigned int sector_size, xenstat_vbd *vbd)
+{
+   unsigned long long bytes;
+   unsigned char *ptr, *tmp;
+   int vbdlen, vbdfound, tmplen;
+   unsigned char buf[512];
+
+   vbdlen = (int)strlen((const char *)vbdname);
+   vbdfound = 0;
+   /* Example: {return: [{device: xvda, parent: {..., stats: 
{... */
+   for (ptr=stats; *ptr; ptr++) {
+   if ( *ptr == '{' ) {
+   if ( !vbdfound ) {
+   if ( !strncmp((const char *)ptr, 
{\device\:, 10) ) {
+   ptr += 10;
+   while (*ptr == ' ' || *ptr == '')
+   ++ptr;
+   if ( !strncmp((const char *)ptr, (const 
char *)vbdname, vbdlen) ) {
+   vbdfound = 1;
+   ptr += vbdlen;
+   }
+   }
+   }
+   else {
+   ptr = qmp_skip_object(ptr);
+   }
+   }
+   else if ( vbdfound  !strncmp((const char *)ptr,  
\stats\:, 9) ) {
+   ptr += 10;
+   tmp = ptr;
+   ptr = qmp_skip_object(ptr);
+   tmplen = (int)(ptr-tmp);
+   strncpy((char *)buf, (char *)tmp, tmplen);
+   buf[tmplen] = 0;
+   qmp_lookup_object(buf, \rd_bytes\:, bytes);
+   vbd-rd_sects = bytes / sector_size;
+   qmp_lookup_object(buf, \wr_bytes\:, bytes);
+   vbd-wr_sects = bytes / sector_size;
+   qmp_lookup_object(buf, \rd_operations\:, 
vbd-rd_reqs);
+   qmp_lookup_object(buf, \wr_operations\:, 
vbd-wr_reqs);
+   break;
+   }
+   }
+}
+
+/* Write a command via the QMP */
+static size_t qmp_write(int qfd, char *cmd, size_t cmd_len)
+{
+   size_t pos = 0;
+   ssize_t res;
+
+   while (cmd_len  pos) {
+   res = write(qfd, cmd + pos, cmd_len - pos);
+   switch (res) {
+   case -1:
+   if (errno == EINTR || errno == EAGAIN)
+   continue;
+   return 0;
+   case 0:
+   errno = EPIPE;
+   return pos;
+   default:
+   pos += (size_t)res;
+   }
+   }
+   return pos

Re: [Xen-devel] Backport request for tools/hotplug: set mtu from bridge for tap interface - for Xen 4.3

2015-01-12 Thread Charles Arnold
With changeset 22885 support was added for setting the MTU in the vif-bridge
script for when a vif interface was set to 'online'.  The was not done for the
'add' operation.  The 'add' operation was added to the script for when tap
devices were specified (c/s 21944). With the setting of the MTU for the
'online' case was there a reason for omitting the 'add'?

This patch sets the MTU for both 'online' and 'add' in the vif-bridge script.

Backport for Xen version 4.3

Signed-off-by: Charles Arnold carn...@suse.com

diff --git a/tools/hotplug/Linux/vif-bridge b/tools/hotplug/Linux/vif-bridge
index f489519..da8a0f8 100644
--- a/tools/hotplug/Linux/vif-bridge
+++ b/tools/hotplug/Linux/vif-bridge
@@ -82,11 +82,7 @@ fi
 case $command in
 online)
 setup_virtual_bridge_port $dev
-mtu=`ip link show $bridge | awk '/mtu/ { print $5 }'`
-if [ -n $mtu ]  [ $mtu -gt 0 ]
-then
-ip link set $dev mtu $mtu || :
-fi
+set_mtu $bridge $dev
 add_to_bridge $bridge $dev
 ;;
 
@@ -97,6 +93,7 @@ case $command in
 
 add)
 setup_virtual_bridge_port $dev
+set_mtu $bridge $dev
 add_to_bridge $bridge $dev
 ;;
 esac
diff --git a/tools/hotplug/Linux/xen-network-common.sh 
b/tools/hotplug/Linux/xen-network-common.sh
index 8cff156..9a9526b 100644
--- a/tools/hotplug/Linux/xen-network-common.sh
+++ b/tools/hotplug/Linux/xen-network-common.sh
@@ -132,3 +132,14 @@ add_to_bridge () {
 ip link set ${dev} up
 }
 
+# Usage: set_mtu bridge dev
+set_mtu () {
+local bridge=$1
+local dev=$2
+mtu=`ip link show ${bridge}| awk '/mtu/ { print $5 }'`
+if [ -n $mtu ]  [ $mtu -gt 0 ]
+then
+ip link set ${dev} mtu $mtu || :
+fi
+}
+



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


Re: [Xen-devel] Backport request for tools/hotplug: set mtu from bridge for tap interface - for Xen 4.4, 4.5, and unstable

2015-01-12 Thread Charles Arnold
Add quotes around $bridge and $dev to handle spaces in names.
This should go into 4.4, 4.5 and unstable.

Signed-off-by: Charles Arnold carn...@suse.com

diff --git a/tools/hotplug/Linux/vif-bridge b/tools/hotplug/Linux/vif-bridge
index 3d72ca4..8b67b0a 100644
--- a/tools/hotplug/Linux/vif-bridge
+++ b/tools/hotplug/Linux/vif-bridge
@@ -77,7 +77,7 @@ fi
 case $command in
 online)
 setup_virtual_bridge_port $dev
-set_mtu $bridge $dev
+set_mtu $bridge $dev
 add_to_bridge $bridge $dev
 ;;
 
@@ -88,7 +88,7 @@ case $command in
 
 add)
 setup_virtual_bridge_port $dev
-set_mtu $bridge $dev
+set_mtu $bridge $dev
 add_to_bridge $bridge $dev
 ;;
 esac



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


Re: [Xen-devel] Backport request for tools/hotplug: set mtu from bridge for tap interface

2015-01-12 Thread Charles Arnold
Forgot to put [Patch] in the subject line for the last two replies :(
- Charles



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


Re: [Xen-devel] Backport request for tools/hotplug: set mtu from bridge for tap interface - for Xen 4.4, 4.5, and unstable

2015-01-12 Thread Charles Arnold
 On 1/12/2015 at 10:03 AM, Ian Jackson ian.jack...@eu.citrix.com wrote: 
 Charles Arnold writes (Re: Backport request for tools/hotplug: set mtu from 
 bridge for tap interface - for Xen 4.4, 4.5, and unstable):
 Add quotes around $bridge and $dev to handle spaces in names.
 This should go into 4.4, 4.5 and unstable.
 
 Is this really necessary for backporting ?
 
 Frankly I think if you put spaces in your network device names an
 awful lot of things are going to break.

You are probably right.  The change was also for consistency in how the 
variables are used elsewhere in the script.

- Charles


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel