* [PATCH 1/3] net: maintain namespace isolation between vlan and real device
From: Arnd Bergmann @ 2010-01-30 22:23 UTC (permalink / raw)
To: David Miller
Cc: Herbert Xu, Michael S. Tsirkin, netdev, bridge, linux-kernel,
virtualization, Stephen Hemminger
In-Reply-To: <201001302322.15237.arnd@arndb.de>
In the vlan and macvlan drivers, the start_xmit function forwards
data to the dev_queue_xmit function for another device, which may
potentially belong to a different namespace.
To make sure that classification stays within a single namespace,
this resets the potentially critical fields.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/macvlan.c | 2 +-
include/linux/netdevice.h | 9 +++++++++
net/8021q/vlan_dev.c | 2 +-
net/core/dev.c | 35 +++++++++++++++++++++++++++++++----
4 files changed, 42 insertions(+), 6 deletions(-)
diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
index fa0dc51..d32e0bd 100644
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -269,7 +269,7 @@ static int macvlan_queue_xmit(struct sk_buff *skb, struct net_device *dev)
}
xmit_world:
- skb->dev = vlan->lowerdev;
+ skb_set_dev(skb, vlan->lowerdev);
return dev_queue_xmit(skb);
}
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 93a32a5..622ba5a 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1004,6 +1004,15 @@ static inline bool netdev_uses_dsa_tags(struct net_device *dev)
return 0;
}
+#ifndef CONFIG_NET_NS
+static inline void skb_set_dev(struct sk_buff *skb, struct net_device *dev)
+{
+ skb->dev = dev;
+}
+#else /* CONFIG_NET_NS */
+void skb_set_dev(struct sk_buff *skb, struct net_device *dev);
+#endif
+
static inline bool netdev_uses_trailer_tags(struct net_device *dev)
{
#ifdef CONFIG_NET_DSA_TAG_TRAILER
diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
index a9e1f17..9e83272 100644
--- a/net/8021q/vlan_dev.c
+++ b/net/8021q/vlan_dev.c
@@ -322,7 +322,7 @@ static netdev_tx_t vlan_dev_hard_start_xmit(struct sk_buff *skb,
}
- skb->dev = vlan_dev_info(dev)->real_dev;
+ skb_set_dev(skb, vlan_dev_info(dev)->real_dev);
len = skb->len;
ret = dev_queue_xmit(skb);
diff --git a/net/core/dev.c b/net/core/dev.c
index 2cba5c5..94c1eee 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1448,13 +1448,10 @@ int dev_forward_skb(struct net_device *dev, struct sk_buff *skb)
if (skb->len > (dev->mtu + dev->hard_header_len))
return NET_RX_DROP;
- skb_dst_drop(skb);
+ skb_set_dev(skb, dev);
skb->tstamp.tv64 = 0;
skb->pkt_type = PACKET_HOST;
skb->protocol = eth_type_trans(skb, dev);
- skb->mark = 0;
- secpath_reset(skb);
- nf_reset(skb);
return netif_rx(skb);
}
EXPORT_SYMBOL_GPL(dev_forward_skb);
@@ -1614,6 +1611,36 @@ static bool dev_can_checksum(struct net_device *dev, struct sk_buff *skb)
return false;
}
+/**
+ * skb_dev_set -- assign a new device to a buffer
+ * @skb: buffer for the new device
+ * @dev: network device
+ *
+ * If an skb is owned by a device already, we have to reset
+ * all data private to the namespace a device belongs to
+ * before assigning it a new device.
+ */
+#ifdef CONFIG_NET_NS
+void skb_set_dev(struct sk_buff *skb, struct net_device *dev)
+{
+ skb_dst_drop(skb);
+ if (skb->dev && !net_eq(dev_net(skb->dev), dev_net(dev))) {
+ secpath_reset(skb);
+ nf_reset(skb);
+ skb_init_secmark(skb);
+ skb->mark = 0;
+ skb->priority = 0;
+ skb->nf_trace = 0;
+ skb->ipvs_property = 0;
+#ifdef CONFIG_NET_SCHED
+ skb->tc_index = 0;
+#endif
+ }
+ skb->dev = dev;
+}
+EXPORT_SYMBOL(skb_set_dev);
+#endif /* CONFIG_NET_NS */
+
/*
* Invalidate hardware checksum when packet is to be mangled, and
* complete checksum manually on outgoing path.
--
1.6.3.3
^ permalink raw reply related
* [PATCH 2/3] macvlan: allow multiple driver backends
From: Arnd Bergmann @ 2010-01-30 22:23 UTC (permalink / raw)
To: David Miller
Cc: Herbert Xu, Michael S. Tsirkin, netdev, bridge, linux-kernel,
virtualization, Stephen Hemminger
In-Reply-To: <201001302322.15237.arnd@arndb.de>
This makes it possible to hook into the macvlan driver
from another kernel module. In particular, the goal is
to extend it with the macvtap backend that provides
a tun/tap compatible interface directly on the macvlan
device.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/macvlan.c | 113 +++++++++++++++++++-------------------------
include/linux/if_macvlan.h | 70 +++++++++++++++++++++++++++
2 files changed, 119 insertions(+), 64 deletions(-)
diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
index d32e0bd..40faa36 100644
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -39,31 +39,6 @@ struct macvlan_port {
struct list_head vlans;
};
-/**
- * struct macvlan_rx_stats - MACVLAN percpu rx stats
- * @rx_packets: number of received packets
- * @rx_bytes: number of received bytes
- * @multicast: number of received multicast packets
- * @rx_errors: number of errors
- */
-struct macvlan_rx_stats {
- unsigned long rx_packets;
- unsigned long rx_bytes;
- unsigned long multicast;
- unsigned long rx_errors;
-};
-
-struct macvlan_dev {
- struct net_device *dev;
- struct list_head list;
- struct hlist_node hlist;
- struct macvlan_port *port;
- struct net_device *lowerdev;
- struct macvlan_rx_stats *rx_stats;
- enum macvlan_mode mode;
-};
-
-
static struct macvlan_dev *macvlan_hash_lookup(const struct macvlan_port *port,
const unsigned char *addr)
{
@@ -118,31 +93,17 @@ static int macvlan_addr_busy(const struct macvlan_port *port,
return 0;
}
-static inline void macvlan_count_rx(const struct macvlan_dev *vlan,
- unsigned int len, bool success,
- bool multicast)
-{
- struct macvlan_rx_stats *rx_stats;
-
- rx_stats = per_cpu_ptr(vlan->rx_stats, smp_processor_id());
- if (likely(success)) {
- rx_stats->rx_packets++;;
- rx_stats->rx_bytes += len;
- if (multicast)
- rx_stats->multicast++;
- } else {
- rx_stats->rx_errors++;
- }
-}
-static int macvlan_broadcast_one(struct sk_buff *skb, struct net_device *dev,
+static int macvlan_broadcast_one(struct sk_buff *skb,
+ const struct macvlan_dev *vlan,
const struct ethhdr *eth, bool local)
{
+ struct net_device *dev = vlan->dev;
if (!skb)
return NET_RX_DROP;
if (local)
- return dev_forward_skb(dev, skb);
+ return vlan->forward(dev, skb);
skb->dev = dev;
if (!compare_ether_addr_64bits(eth->h_dest,
@@ -151,7 +112,7 @@ static int macvlan_broadcast_one(struct sk_buff *skb, struct net_device *dev,
else
skb->pkt_type = PACKET_MULTICAST;
- return netif_rx(skb);
+ return vlan->receive(skb);
}
static void macvlan_broadcast(struct sk_buff *skb,
@@ -175,7 +136,7 @@ static void macvlan_broadcast(struct sk_buff *skb,
continue;
nskb = skb_clone(skb, GFP_ATOMIC);
- err = macvlan_broadcast_one(nskb, vlan->dev, eth,
+ err = macvlan_broadcast_one(nskb, vlan, eth,
mode == MACVLAN_MODE_BRIDGE);
macvlan_count_rx(vlan, skb->len + ETH_HLEN,
err == NET_RX_SUCCESS, 1);
@@ -238,7 +199,7 @@ static struct sk_buff *macvlan_handle_frame(struct sk_buff *skb)
skb->dev = dev;
skb->pkt_type = PACKET_HOST;
- netif_rx(skb);
+ vlan->receive(skb);
return NULL;
}
@@ -260,7 +221,7 @@ static int macvlan_queue_xmit(struct sk_buff *skb, struct net_device *dev)
dest = macvlan_hash_lookup(port, eth->h_dest);
if (dest && dest->mode == MACVLAN_MODE_BRIDGE) {
unsigned int length = skb->len + ETH_HLEN;
- int ret = dev_forward_skb(dest->dev, skb);
+ int ret = dest->forward(dest->dev, skb);
macvlan_count_rx(dest, length,
ret == NET_RX_SUCCESS, 0);
@@ -273,8 +234,8 @@ xmit_world:
return dev_queue_xmit(skb);
}
-static netdev_tx_t macvlan_start_xmit(struct sk_buff *skb,
- struct net_device *dev)
+netdev_tx_t macvlan_start_xmit(struct sk_buff *skb,
+ struct net_device *dev)
{
int i = skb_get_queue_mapping(skb);
struct netdev_queue *txq = netdev_get_tx_queue(dev, i);
@@ -290,6 +251,7 @@ static netdev_tx_t macvlan_start_xmit(struct sk_buff *skb,
return ret;
}
+EXPORT_SYMBOL_GPL(macvlan_start_xmit);
static int macvlan_hard_header(struct sk_buff *skb, struct net_device *dev,
unsigned short type, const void *daddr,
@@ -623,8 +585,11 @@ static int macvlan_get_tx_queues(struct net *net,
return 0;
}
-static int macvlan_newlink(struct net *src_net, struct net_device *dev,
- struct nlattr *tb[], struct nlattr *data[])
+int macvlan_common_newlink(struct net *src_net, struct net_device *dev,
+ struct nlattr *tb[], struct nlattr *data[],
+ int (*receive)(struct sk_buff *skb),
+ int (*forward)(struct net_device *dev,
+ struct sk_buff *skb))
{
struct macvlan_dev *vlan = netdev_priv(dev);
struct macvlan_port *port;
@@ -664,6 +629,8 @@ static int macvlan_newlink(struct net *src_net, struct net_device *dev,
vlan->lowerdev = lowerdev;
vlan->dev = dev;
vlan->port = port;
+ vlan->receive = receive;
+ vlan->forward = forward;
vlan->mode = MACVLAN_MODE_VEPA;
if (data && data[IFLA_MACVLAN_MODE])
@@ -677,8 +644,17 @@ static int macvlan_newlink(struct net *src_net, struct net_device *dev,
netif_stacked_transfer_operstate(lowerdev, dev);
return 0;
}
+EXPORT_SYMBOL_GPL(macvlan_common_newlink);
-static void macvlan_dellink(struct net_device *dev, struct list_head *head)
+static int macvlan_newlink(struct net *src_net, struct net_device *dev,
+ struct nlattr *tb[], struct nlattr *data[])
+{
+ return macvlan_common_newlink(src_net, dev, tb, data,
+ netif_rx,
+ dev_forward_skb);
+}
+
+void macvlan_dellink(struct net_device *dev, struct list_head *head)
{
struct macvlan_dev *vlan = netdev_priv(dev);
struct macvlan_port *port = vlan->port;
@@ -689,6 +665,7 @@ static void macvlan_dellink(struct net_device *dev, struct list_head *head)
if (list_empty(&port->vlans))
macvlan_port_destroy(port->dev);
}
+EXPORT_SYMBOL_GPL(macvlan_dellink);
static int macvlan_changelink(struct net_device *dev,
struct nlattr *tb[], struct nlattr *data[])
@@ -720,19 +697,27 @@ static const struct nla_policy macvlan_policy[IFLA_MACVLAN_MAX + 1] = {
[IFLA_MACVLAN_MODE] = { .type = NLA_U32 },
};
-static struct rtnl_link_ops macvlan_link_ops __read_mostly = {
+int macvlan_link_register(struct rtnl_link_ops *ops)
+{
+ /* common fields */
+ ops->priv_size = sizeof(struct macvlan_dev);
+ ops->get_tx_queues = macvlan_get_tx_queues;
+ ops->setup = macvlan_setup;
+ ops->validate = macvlan_validate;
+ ops->maxtype = IFLA_MACVLAN_MAX;
+ ops->policy = macvlan_policy;
+ ops->changelink = macvlan_changelink;
+ ops->get_size = macvlan_get_size;
+ ops->fill_info = macvlan_fill_info;
+
+ return rtnl_link_register(ops);
+};
+EXPORT_SYMBOL_GPL(macvlan_link_register);
+
+static struct rtnl_link_ops macvlan_link_ops = {
.kind = "macvlan",
- .priv_size = sizeof(struct macvlan_dev),
- .get_tx_queues = macvlan_get_tx_queues,
- .setup = macvlan_setup,
- .validate = macvlan_validate,
.newlink = macvlan_newlink,
.dellink = macvlan_dellink,
- .maxtype = IFLA_MACVLAN_MAX,
- .policy = macvlan_policy,
- .changelink = macvlan_changelink,
- .get_size = macvlan_get_size,
- .fill_info = macvlan_fill_info,
};
static int macvlan_device_event(struct notifier_block *unused,
@@ -761,7 +746,7 @@ static int macvlan_device_event(struct notifier_block *unused,
break;
case NETDEV_UNREGISTER:
list_for_each_entry_safe(vlan, next, &port->vlans, list)
- macvlan_dellink(vlan->dev, NULL);
+ vlan->dev->rtnl_link_ops->dellink(vlan->dev, NULL);
break;
}
return NOTIFY_DONE;
@@ -778,7 +763,7 @@ static int __init macvlan_init_module(void)
register_netdevice_notifier(&macvlan_notifier_block);
macvlan_handle_frame_hook = macvlan_handle_frame;
- err = rtnl_link_register(&macvlan_link_ops);
+ err = macvlan_link_register(&macvlan_link_ops);
if (err < 0)
goto err1;
return 0;
diff --git a/include/linux/if_macvlan.h b/include/linux/if_macvlan.h
index 5f200ba..9a11544 100644
--- a/include/linux/if_macvlan.h
+++ b/include/linux/if_macvlan.h
@@ -1,6 +1,76 @@
#ifndef _LINUX_IF_MACVLAN_H
#define _LINUX_IF_MACVLAN_H
+#include <linux/if_link.h>
+#include <linux/list.h>
+#include <linux/netdevice.h>
+#include <linux/netlink.h>
+#include <net/netlink.h>
+
+struct macvlan_port;
+struct macvtap_queue;
+
+/**
+ * struct macvlan_rx_stats - MACVLAN percpu rx stats
+ * @rx_packets: number of received packets
+ * @rx_bytes: number of received bytes
+ * @multicast: number of received multicast packets
+ * @rx_errors: number of errors
+ */
+struct macvlan_rx_stats {
+ unsigned long rx_packets;
+ unsigned long rx_bytes;
+ unsigned long multicast;
+ unsigned long rx_errors;
+};
+
+struct macvlan_dev {
+ struct net_device *dev;
+ struct list_head list;
+ struct hlist_node hlist;
+ struct macvlan_port *port;
+ struct net_device *lowerdev;
+ struct macvlan_rx_stats *rx_stats;
+ enum macvlan_mode mode;
+ int (*receive)(struct sk_buff *skb);
+ int (*forward)(struct net_device *dev, struct sk_buff *skb);
+};
+
+static inline void macvlan_count_rx(const struct macvlan_dev *vlan,
+ unsigned int len, bool success,
+ bool multicast)
+{
+ struct macvlan_rx_stats *rx_stats;
+
+ rx_stats = per_cpu_ptr(vlan->rx_stats, smp_processor_id());
+ if (likely(success)) {
+ rx_stats->rx_packets++;;
+ rx_stats->rx_bytes += len;
+ if (multicast)
+ rx_stats->multicast++;
+ } else {
+ rx_stats->rx_errors++;
+ }
+}
+
+extern int macvlan_common_newlink(struct net *src_net, struct net_device *dev,
+ struct nlattr *tb[], struct nlattr *data[],
+ int (*receive)(struct sk_buff *skb),
+ int (*forward)(struct net_device *dev,
+ struct sk_buff *skb));
+
+extern void macvlan_count_rx(const struct macvlan_dev *vlan,
+ unsigned int len, bool success,
+ bool multicast);
+
+extern void macvlan_dellink(struct net_device *dev, struct list_head *head);
+
+extern int macvlan_link_register(struct rtnl_link_ops *ops);
+
+extern netdev_tx_t macvlan_start_xmit(struct sk_buff *skb,
+ struct net_device *dev);
+
+
extern struct sk_buff *(*macvlan_handle_frame_hook)(struct sk_buff *);
#endif /* _LINUX_IF_MACVLAN_H */
--
1.6.3.3
^ permalink raw reply related
* [PATCH 3/3] net: macvtap driver
From: Arnd Bergmann @ 2010-01-30 22:24 UTC (permalink / raw)
To: David Miller
Cc: Herbert Xu, Michael S. Tsirkin, netdev, bridge, linux-kernel,
virtualization, Stephen Hemminger
In-Reply-To: <201001302322.15237.arnd@arndb.de>
In order to use macvlan with qemu and other tools that require
a tap file descriptor, the macvtap driver adds a small backend
with a character device with the same interface as the tun
driver, with a minimum set of features.
Macvtap interfaces are created in the same way as macvlan
interfaces using ip link, but the netif is just used as a
handle for configuration and accounting, while the data
goes through the chardev. Each macvtap interface has its
own character device, simplifying permission management
significantly over the generic tun/tap driver.
Cc: Patrick McHardy <kaber@trash.net>
Cc: Stephen Hemminger <shemminger@linux-foundation.org>
Cc: David S. Miller" <davem@davemloft.net>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Or Gerlitz <ogerlitz@voltaire.com>
Cc: netdev@vger.kernel.org
Cc: bridge@lists.linux-foundation.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/Kconfig | 12 +
drivers/net/Makefile | 1 +
drivers/net/macvtap.c | 581 ++++++++++++++++++++++++++++++++++++++++++++
include/linux/if_macvlan.h | 1 +
4 files changed, 595 insertions(+), 0 deletions(-)
create mode 100644 drivers/net/macvtap.c
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index cb0e534..411e207 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -90,6 +90,18 @@ config MACVLAN
To compile this driver as a module, choose M here: the module
will be called macvlan.
+config MACVTAP
+ tristate "MAC-VLAN based tap driver (EXPERIMENTAL)"
+ depends on MACVLAN
+ help
+ This adds a specialized tap character device driver that is based
+ on the MAC-VLAN network interface, called macvtap. A macvtap device
+ can be added in the same way as a macvlan device, using 'type
+ macvlan', and then be accessed through the tap user space interface.
+
+ To compile this driver as a module, choose M here: the module
+ will be called macvtap.
+
config EQUALIZER
tristate "EQL (serial line load balancing) support"
---help---
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 0b763cb..9595803 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -169,6 +169,7 @@ obj-$(CONFIG_XEN_NETDEV_FRONTEND) += xen-netfront.o
obj-$(CONFIG_DUMMY) += dummy.o
obj-$(CONFIG_IFB) += ifb.o
obj-$(CONFIG_MACVLAN) += macvlan.o
+obj-$(CONFIG_MACVTAP) += macvtap.o
obj-$(CONFIG_DE600) += de600.o
obj-$(CONFIG_DE620) += de620.o
obj-$(CONFIG_LANCE) += lance.o
diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
new file mode 100644
index 0000000..ad1f6ef
--- /dev/null
+++ b/drivers/net/macvtap.c
@@ -0,0 +1,581 @@
+#include <linux/etherdevice.h>
+#include <linux/if_macvlan.h>
+#include <linux/interrupt.h>
+#include <linux/nsproxy.h>
+#include <linux/compat.h>
+#include <linux/if_tun.h>
+#include <linux/module.h>
+#include <linux/skbuff.h>
+#include <linux/cache.h>
+#include <linux/sched.h>
+#include <linux/types.h>
+#include <linux/init.h>
+#include <linux/wait.h>
+#include <linux/cdev.h>
+#include <linux/fs.h>
+
+#include <net/net_namespace.h>
+#include <net/rtnetlink.h>
+#include <net/sock.h>
+
+/*
+ * A macvtap queue is the central object of this driver, it connects
+ * an open character device to a macvlan interface. There can be
+ * multiple queues on one interface, which map back to queues
+ * implemented in hardware on the underlying device.
+ *
+ * macvtap_proto is used to allocate queues through the sock allocation
+ * mechanism.
+ *
+ * TODO: multiqueue support is currently not implemented, even though
+ * macvtap is basically prepared for that. We will need to add this
+ * here as well as in virtio-net and qemu to get line rate on 10gbit
+ * adapters from a guest.
+ */
+struct macvtap_queue {
+ struct sock sk;
+ struct socket sock;
+ struct macvlan_dev *vlan;
+ struct file *file;
+};
+
+static struct proto macvtap_proto = {
+ .name = "macvtap",
+ .owner = THIS_MODULE,
+ .obj_size = sizeof (struct macvtap_queue),
+};
+
+/*
+ * Minor number matches netdev->ifindex, so need a potentially
+ * large value. This also makes it possible to split the
+ * tap functionality out again in the future by offering it
+ * from other drivers besides macvtap. As long as every device
+ * only has one tap, the interface numbers assure that the
+ * device nodes are unique.
+ */
+static unsigned int macvtap_major;
+#define MACVTAP_NUM_DEVS 65536
+static struct class *macvtap_class;
+static struct cdev macvtap_cdev;
+
+/*
+ * RCU usage:
+ * The macvtap_queue is referenced both from the chardev struct file
+ * and from the struct macvlan_dev using rcu_read_lock.
+ *
+ * We never actually update the contents of a macvtap_queue atomically
+ * with RCU but it is used for race-free destruction of a queue when
+ * either the file or the macvlan_dev goes away. Pointers back to
+ * the dev and the file are implicitly valid as long as the queue
+ * exists.
+ *
+ * The callbacks from macvlan are always done with rcu_read_lock held
+ * already, while in the file_operations, we get it ourselves.
+ *
+ * When destroying a queue, we remove the pointers from the file and
+ * from the dev and then synchronize_rcu to make sure no thread is
+ * still using the queue. There may still be references to the struct
+ * sock inside of the queue from outbound SKBs, but these never
+ * reference back to the file or the dev. The data structure is freed
+ * through __sk_free when both our references and any pending SKBs
+ * are gone.
+ *
+ * macvtap_lock is only used to prevent multiple concurrent open()
+ * calls to assign a new vlan->tap pointer. It could be moved into
+ * the macvlan_dev itself but is extremely rarely used.
+ */
+static DEFINE_SPINLOCK(macvtap_lock);
+
+/*
+ * Choose the next free queue, for now there is only one
+ */
+static int macvtap_set_queue(struct net_device *dev, struct file *file,
+ struct macvtap_queue *q)
+{
+ struct macvlan_dev *vlan = netdev_priv(dev);
+ int err = -EBUSY;
+
+ spin_lock(&macvtap_lock);
+ if (rcu_dereference(vlan->tap))
+ goto out;
+
+ err = 0;
+ q->vlan = vlan;
+ rcu_assign_pointer(vlan->tap, q);
+
+ q->file = file;
+ rcu_assign_pointer(file->private_data, q);
+
+out:
+ spin_unlock(&macvtap_lock);
+ return err;
+}
+
+/*
+ * We must destroy each queue exactly once, when either
+ * the netdev or the file go away.
+ *
+ * Using the spinlock makes sure that we don't get
+ * to the queue again after destroying it.
+ *
+ * synchronize_rcu serializes with the packet flow
+ * that uses rcu_read_lock.
+ */
+static void macvtap_del_queue(struct macvtap_queue **qp)
+{
+ struct macvtap_queue *q;
+
+ spin_lock(&macvtap_lock);
+ q = rcu_dereference(*qp);
+ if (!q) {
+ spin_unlock(&macvtap_lock);
+ return;
+ }
+
+ rcu_assign_pointer(q->vlan->tap, NULL);
+ rcu_assign_pointer(q->file->private_data, NULL);
+ spin_unlock(&macvtap_lock);
+
+ synchronize_rcu();
+ sock_put(&q->sk);
+}
+
+/*
+ * Since we only support one queue, just dereference the pointer.
+ */
+static struct macvtap_queue *macvtap_get_queue(struct net_device *dev,
+ struct sk_buff *skb)
+{
+ struct macvlan_dev *vlan = netdev_priv(dev);
+
+ return rcu_dereference(vlan->tap);
+}
+
+static void macvtap_del_queues(struct net_device *dev)
+{
+ struct macvlan_dev *vlan = netdev_priv(dev);
+ macvtap_del_queue(&vlan->tap);
+}
+
+static inline struct macvtap_queue *macvtap_file_get_queue(struct file *file)
+{
+ rcu_read_lock_bh();
+ return rcu_dereference(file->private_data);
+}
+
+static inline void macvtap_file_put_queue(void)
+{
+ rcu_read_unlock_bh();
+}
+
+/*
+ * Forward happens for data that gets sent from one macvlan
+ * endpoint to another one in bridge mode. We just take
+ * the skb and put it into the receive queue.
+ */
+static int macvtap_forward(struct net_device *dev, struct sk_buff *skb)
+{
+ struct macvtap_queue *q = macvtap_get_queue(dev, skb);
+ if (!q)
+ return -ENOLINK;
+
+ skb_queue_tail(&q->sk.sk_receive_queue, skb);
+ wake_up(q->sk.sk_sleep);
+ return 0;
+}
+
+/*
+ * Receive is for data from the external interface (lowerdev),
+ * in case of macvtap, we can treat that the same way as
+ * forward, which macvlan cannot.
+ */
+static int macvtap_receive(struct sk_buff *skb)
+{
+ skb_push(skb, ETH_HLEN);
+ return macvtap_forward(skb->dev, skb);
+}
+
+static int macvtap_newlink(struct net *src_net,
+ struct net_device *dev,
+ struct nlattr *tb[],
+ struct nlattr *data[])
+{
+ struct device *classdev;
+ dev_t devt;
+ int err;
+
+ err = macvlan_common_newlink(src_net, dev, tb, data,
+ macvtap_receive, macvtap_forward);
+ if (err)
+ goto out;
+
+ devt = MKDEV(MAJOR(macvtap_major), dev->ifindex);
+
+ classdev = device_create(macvtap_class, &dev->dev, devt,
+ dev, "tap%d", dev->ifindex);
+ if (IS_ERR(classdev)) {
+ err = PTR_ERR(classdev);
+ macvtap_del_queues(dev);
+ }
+
+out:
+ return err;
+}
+
+static void macvtap_dellink(struct net_device *dev,
+ struct list_head *head)
+{
+ device_destroy(macvtap_class,
+ MKDEV(MAJOR(macvtap_major), dev->ifindex));
+
+ macvtap_del_queues(dev);
+ macvlan_dellink(dev, head);
+}
+
+static struct rtnl_link_ops macvtap_link_ops __read_mostly = {
+ .kind = "macvtap",
+ .newlink = macvtap_newlink,
+ .dellink = macvtap_dellink,
+};
+
+
+static void macvtap_sock_write_space(struct sock *sk)
+{
+ if (!sock_writeable(sk) ||
+ !test_and_clear_bit(SOCK_ASYNC_NOSPACE, &sk->sk_socket->flags))
+ return;
+
+ if (sk->sk_sleep && waitqueue_active(sk->sk_sleep))
+ wake_up_interruptible_sync(sk->sk_sleep);
+}
+
+static int macvtap_open(struct inode *inode, struct file *file)
+{
+ struct net *net = current->nsproxy->net_ns;
+ struct net_device *dev = dev_get_by_index(net, iminor(inode));
+ struct macvtap_queue *q;
+ int err;
+
+ err = -ENODEV;
+ if (!dev)
+ goto out;
+
+ /* check if this is a macvtap device */
+ err = -EINVAL;
+ if (dev->rtnl_link_ops != &macvtap_link_ops)
+ goto out;
+
+ err = -ENOMEM;
+ q = (struct macvtap_queue *)sk_alloc(net, AF_UNSPEC, GFP_KERNEL,
+ &macvtap_proto);
+ if (!q)
+ goto out;
+
+ init_waitqueue_head(&q->sock.wait);
+ q->sock.type = SOCK_RAW;
+ q->sock.state = SS_CONNECTED;
+ sock_init_data(&q->sock, &q->sk);
+ q->sk.sk_allocation = GFP_ATOMIC; /* for now */
+ q->sk.sk_write_space = macvtap_sock_write_space;
+
+ err = macvtap_set_queue(dev, file, q);
+ if (err)
+ sock_put(&q->sk);
+
+out:
+ if (dev)
+ dev_put(dev);
+
+ return err;
+}
+
+static int macvtap_release(struct inode *inode, struct file *file)
+{
+ macvtap_del_queue((struct macvtap_queue **)&file->private_data);
+ return 0;
+}
+
+static unsigned int macvtap_poll(struct file *file, poll_table * wait)
+{
+ struct macvtap_queue *q = macvtap_file_get_queue(file);
+ unsigned int mask = POLLERR;
+
+ if (!q)
+ goto out;
+
+ mask = 0;
+ poll_wait(file, &q->sock.wait, wait);
+
+ if (!skb_queue_empty(&q->sk.sk_receive_queue))
+ mask |= POLLIN | POLLRDNORM;
+
+ if (sock_writeable(&q->sk) ||
+ (!test_and_set_bit(SOCK_ASYNC_NOSPACE, &q->sock.flags) &&
+ sock_writeable(&q->sk)))
+ mask |= POLLOUT | POLLWRNORM;
+
+out:
+ macvtap_file_put_queue();
+ return mask;
+}
+
+/* Get packet from user space buffer */
+static ssize_t macvtap_get_user(struct macvtap_queue *q,
+ const struct iovec *iv, size_t count,
+ int noblock)
+{
+ struct sk_buff *skb;
+ size_t len = count;
+ int err;
+
+ if (unlikely(len < ETH_HLEN))
+ return -EINVAL;
+
+ skb = sock_alloc_send_skb(&q->sk, NET_IP_ALIGN + len, noblock, &err);
+
+ if (!skb) {
+ macvlan_count_rx(q->vlan, 0, false, false);
+ return err;
+ }
+
+ skb_reserve(skb, NET_IP_ALIGN);
+ skb_put(skb, count);
+
+ if (skb_copy_datagram_from_iovec(skb, 0, iv, 0, len)) {
+ macvlan_count_rx(q->vlan, 0, false, false);
+ kfree_skb(skb);
+ return -EFAULT;
+ }
+
+ skb_set_network_header(skb, ETH_HLEN);
+
+ macvlan_start_xmit(skb, q->vlan->dev);
+
+ return count;
+}
+
+static ssize_t macvtap_aio_write(struct kiocb *iocb, const struct iovec *iv,
+ unsigned long count, loff_t pos)
+{
+ struct file *file = iocb->ki_filp;
+ ssize_t result = -ENOLINK;
+ struct macvtap_queue *q = macvtap_file_get_queue(file);
+
+ if (!q)
+ goto out;
+
+ result = macvtap_get_user(q, iv, iov_length(iv, count),
+ file->f_flags & O_NONBLOCK);
+out:
+ macvtap_file_put_queue();
+ return result;
+}
+
+/* Put packet to the user space buffer */
+static ssize_t macvtap_put_user(struct macvtap_queue *q,
+ const struct sk_buff *skb,
+ const struct iovec *iv, int len)
+{
+ struct macvlan_dev *vlan = q->vlan;
+ int ret;
+
+ len = min_t(int, skb->len, len);
+
+ ret = skb_copy_datagram_const_iovec(skb, 0, iv, 0, len);
+
+ macvlan_count_rx(vlan, len, ret == 0, 0);
+
+ return ret ? ret : len;
+}
+
+static ssize_t macvtap_aio_read(struct kiocb *iocb, const struct iovec *iv,
+ unsigned long count, loff_t pos)
+{
+ struct file *file = iocb->ki_filp;
+ struct macvtap_queue *q = macvtap_file_get_queue(file);
+
+ DECLARE_WAITQUEUE(wait, current);
+ struct sk_buff *skb;
+ ssize_t len, ret = 0;
+
+ if (!q) {
+ ret = -ENOLINK;
+ goto out;
+ }
+
+ len = iov_length(iv, count);
+ if (len < 0) {
+ ret = -EINVAL;
+ goto out;
+ }
+
+ add_wait_queue(q->sk.sk_sleep, &wait);
+ while (len) {
+ current->state = TASK_INTERRUPTIBLE;
+
+ /* Read frames from the queue */
+ skb = skb_dequeue(&q->sk.sk_receive_queue);
+ if (!skb) {
+ if (file->f_flags & O_NONBLOCK) {
+ ret = -EAGAIN;
+ break;
+ }
+ if (signal_pending(current)) {
+ ret = -ERESTARTSYS;
+ break;
+ }
+ /* Nothing to read, let's sleep */
+ schedule();
+ continue;
+ }
+ ret = macvtap_put_user(q, skb, iv, len);
+ kfree_skb(skb);
+ break;
+ }
+
+ current->state = TASK_RUNNING;
+ remove_wait_queue(q->sk.sk_sleep, &wait);
+
+out:
+ macvtap_file_put_queue();
+ return ret;
+}
+
+/*
+ * provide compatibility with generic tun/tap interface
+ */
+static long macvtap_ioctl(struct file *file, unsigned int cmd,
+ unsigned long arg)
+{
+ struct macvtap_queue *q;
+ void __user *argp = (void __user *)arg;
+ struct ifreq __user *ifr = argp;
+ unsigned int __user *up = argp;
+ unsigned int u;
+ char devname[IFNAMSIZ];
+
+ switch (cmd) {
+ case TUNSETIFF:
+ /* ignore the name, just look at flags */
+ if (get_user(u, &ifr->ifr_flags))
+ return -EFAULT;
+ if (u != (IFF_TAP | IFF_NO_PI))
+ return -EINVAL;
+ return 0;
+
+ case TUNGETIFF:
+ q = macvtap_file_get_queue(file);
+ if (!q)
+ return -ENOLINK;
+ memcpy(devname, q->vlan->dev->name, sizeof(devname));
+ macvtap_file_put_queue();
+
+ if (copy_to_user(&ifr->ifr_name, q->vlan->dev->name, IFNAMSIZ) ||
+ put_user((TUN_TAP_DEV | TUN_NO_PI), &ifr->ifr_flags))
+ return -EFAULT;
+ return 0;
+
+ case TUNGETFEATURES:
+ if (put_user((IFF_TAP | IFF_NO_PI), up))
+ return -EFAULT;
+ return 0;
+
+ case TUNSETSNDBUF:
+ if (get_user(u, up))
+ return -EFAULT;
+
+ q = macvtap_file_get_queue(file);
+ q->sk.sk_sndbuf = u;
+ macvtap_file_put_queue();
+ return 0;
+
+ case TUNSETOFFLOAD:
+ /* let the user check for future flags */
+ if (arg & ~(TUN_F_CSUM | TUN_F_TSO4 | TUN_F_TSO6 |
+ TUN_F_TSO_ECN | TUN_F_UFO))
+ return -EINVAL;
+
+ /* TODO: add support for these, so far we don't
+ support any offload */
+ if (arg & (TUN_F_CSUM | TUN_F_TSO4 | TUN_F_TSO6 |
+ TUN_F_TSO_ECN | TUN_F_UFO))
+ return -EINVAL;
+
+ return 0;
+
+ default:
+ return -EINVAL;
+ }
+}
+
+#ifdef CONFIG_COMPAT
+static long macvtap_compat_ioctl(struct file *file, unsigned int cmd,
+ unsigned long arg)
+{
+ return macvtap_ioctl(file, cmd, (unsigned long)compat_ptr(arg));
+}
+#endif
+
+static const struct file_operations macvtap_fops = {
+ .owner = THIS_MODULE,
+ .open = macvtap_open,
+ .release = macvtap_release,
+ .aio_read = macvtap_aio_read,
+ .aio_write = macvtap_aio_write,
+ .poll = macvtap_poll,
+ .llseek = no_llseek,
+ .unlocked_ioctl = macvtap_ioctl,
+#ifdef CONFIG_COMPAT
+ .compat_ioctl = macvtap_compat_ioctl,
+#endif
+};
+
+static int macvtap_init(void)
+{
+ int err;
+
+ err = alloc_chrdev_region(&macvtap_major, 0,
+ MACVTAP_NUM_DEVS, "macvtap");
+ if (err)
+ goto out1;
+
+ cdev_init(&macvtap_cdev, &macvtap_fops);
+ err = cdev_add(&macvtap_cdev, macvtap_major, MACVTAP_NUM_DEVS);
+ if (err)
+ goto out2;
+
+ macvtap_class = class_create(THIS_MODULE, "macvtap");
+ if (IS_ERR(macvtap_class)) {
+ err = PTR_ERR(macvtap_class);
+ goto out3;
+ }
+
+ err = macvlan_link_register(&macvtap_link_ops);
+ if (err)
+ goto out4;
+
+ return 0;
+
+out4:
+ class_unregister(macvtap_class);
+out3:
+ cdev_del(&macvtap_cdev);
+out2:
+ unregister_chrdev_region(macvtap_major, MACVTAP_NUM_DEVS);
+out1:
+ return err;
+}
+module_init(macvtap_init);
+
+static void macvtap_exit(void)
+{
+ rtnl_link_unregister(&macvtap_link_ops);
+ class_unregister(macvtap_class);
+ cdev_del(&macvtap_cdev);
+ unregister_chrdev_region(macvtap_major, MACVTAP_NUM_DEVS);
+}
+module_exit(macvtap_exit);
+
+MODULE_ALIAS_RTNL_LINK("macvtap");
+MODULE_AUTHOR("Arnd Bergmann <arnd@arndb.de>");
+MODULE_LICENSE("GPL");
diff --git a/include/linux/if_macvlan.h b/include/linux/if_macvlan.h
index 9a11544..51f1512 100644
--- a/include/linux/if_macvlan.h
+++ b/include/linux/if_macvlan.h
@@ -34,6 +34,7 @@ struct macvlan_dev {
enum macvlan_mode mode;
int (*receive)(struct sk_buff *skb);
int (*forward)(struct net_device *dev, struct sk_buff *skb);
+ struct macvtap_queue *tap;
};
static inline void macvlan_count_rx(const struct macvlan_dev *vlan,
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH 21/31] virtio: console: Prepare for writing to userspace buffers
From: Rusty Russell @ 2010-02-01 0:19 UTC (permalink / raw)
To: Amit Shah; +Cc: virtualization
In-Reply-To: <1264772563-25517-4-git-send-email-amit.shah@redhat.com>
On Sat, 30 Jan 2010 12:12:40 am Amit Shah wrote:
> When ports get advertised as char devices, the buffers will come from
> userspace. Equip the fill_readbuf function with the ability to write
> to userspace buffers.
>
> Signed-off-by: Amit Shah <amit.shah@redhat.com>
> ---
> drivers/char/virtio_console.c | 20 ++++++++++++++------
> 1 files changed, 14 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
> index 9d33239..5f61021 100644
> --- a/drivers/char/virtio_console.c
> +++ b/drivers/char/virtio_console.c
> @@ -365,7 +365,8 @@ fail:
> * Give out the data that's requested from the buffer that we have
> * queued up.
> */
> -static ssize_t fill_readbuf(struct port *port, char *out_buf, size_t out_count)
> +static ssize_t fill_readbuf(struct port *port, char *out_buf, size_t out_count,
> + bool to_user)
This patch does not apply: your previous 19/31 "Introduce a send_buf function
for a common path for sending data to host" made this "void *out_buf". The
rest I can't even sort out.
I have dropped 19/31 onwards, as listed below. Please re-xmit privately,
tarball is fine.
Thanks,
Rusty.
Subject: virtio: console: Introduce a send_buf function for a common path for sending data to host
Subject: virtio: console: Add a new MULTIPORT feature, support for generic ports
Subject: virtio: console: Prepare for writing to / reading from userspace buffers
Subject: virtio: console: Associate each port with a char device
Subject: virtio: console: Add file operations to ports for open/read/write/poll
Subject: virtio: console: Ensure only one process can have a port open at a time
Subject: virtio: console: Register with sysfs and create a 'name' attribute for ports
Subject: virtio: console: Remove cached data on port close
Subject: virtio: console: Handle port hot-plug
Subject: virtio: console: Add ability to hot-unplug ports
Subject: virtio: console: Add debugfs files for each port to expose debug info
Subject: virtio: console: show error message if hvc_alloc fails for console ports
^ permalink raw reply
* Re: [PATCH 21/31] virtio: console: Prepare for writing to userspace buffers
From: Amit Shah @ 2010-02-01 5:08 UTC (permalink / raw)
To: Rusty Russell; +Cc: virtualization
In-Reply-To: <201002011049.52053.rusty@rustcorp.com.au>
On (Mon) Feb 01 2010 [10:49:51], Rusty Russell wrote:
> On Sat, 30 Jan 2010 12:12:40 am Amit Shah wrote:
> > When ports get advertised as char devices, the buffers will come from
> > userspace. Equip the fill_readbuf function with the ability to write
> > to userspace buffers.
> >
> > Signed-off-by: Amit Shah <amit.shah@redhat.com>
> > ---
> > drivers/char/virtio_console.c | 20 ++++++++++++++------
> > 1 files changed, 14 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
> > index 9d33239..5f61021 100644
> > --- a/drivers/char/virtio_console.c
> > +++ b/drivers/char/virtio_console.c
> > @@ -365,7 +365,8 @@ fail:
> > * Give out the data that's requested from the buffer that we have
> > * queued up.
> > */
> > -static ssize_t fill_readbuf(struct port *port, char *out_buf, size_t out_count)
> > +static ssize_t fill_readbuf(struct port *port, char *out_buf, size_t out_count,
> > + bool to_user)
>
> This patch does not apply: your previous 19/31 "Introduce a send_buf function
> for a common path for sending data to host" made this "void *out_buf". The
> rest I can't even sort out.
Sorry for that, Rusty.
I've sent you a tarball privately.
The tarball contains an additional patch (contained in the series
itself), that drops the use of outbuf for sending control messages
as well:
(The 'outbuf' was used earlier when we had multiple buffers that could
be queued up for the host to consume. We now only queue up one buffer at
a time and wait for the host to ack the buffer before we move along.
When we revisit the design to allow multiple out-buffers, we can go this
path again.)
drivers/char/virtio_console.c | 21 ++++-----------------
1 files changed, 4 insertions(+), 17 deletions(-)
diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
index 2c2de35..793285d 100644
--- a/drivers/char/virtio_console.c
+++ b/drivers/char/virtio_console.c
@@ -134,9 +134,6 @@ struct ports_device {
/* Array of per-port IO virtqueues */
struct virtqueue **in_vqs, **out_vqs;
- /* The control messages to the Host are sent via this buffer */
- struct port_buffer *outbuf;
-
/* Used for numbering devices for sysfs and debugfs */
unsigned int drv_index;
@@ -372,8 +369,7 @@ static ssize_t send_control_msg(struct port *port, unsigned int event,
struct scatterlist sg[1];
struct virtio_console_control cpkt;
struct virtqueue *vq;
- struct port_buffer *outbuf;
- int tmplen;
+ int len;
if (!use_multiport(port->portdev))
return 0;
@@ -383,14 +379,11 @@ static ssize_t send_control_msg(struct port *port, unsigned int event,
cpkt.value = value;
vq = port->portdev->c_ovq;
- outbuf = port->portdev->outbuf;
-
- memcpy(outbuf->buf, (void *)&cpkt, sizeof(cpkt));
- sg_init_one(sg, outbuf->buf, sizeof(cpkt));
- if (vq->vq_ops->add_buf(vq, sg, 1, 0, outbuf) >= 0) {
+ sg_init_one(sg, &cpkt, sizeof(cpkt));
+ if (vq->vq_ops->add_buf(vq, sg, 1, 0, &cpkt) >= 0) {
vq->vq_ops->kick(vq);
- while (!vq->vq_ops->get_buf(vq, &tmplen))
+ while (!vq->vq_ops->get_buf(vq, &len))
cpu_relax();
}
return 0;
@@ -1432,12 +1425,6 @@ static int __devinit virtcons_probe(struct virtio_device *vdev)
INIT_WORK(&portdev->control_work, &control_work_handler);
INIT_WORK(&portdev->config_work, &config_work_handler);
- portdev->outbuf = alloc_buf(PAGE_SIZE);
- if (!portdev->outbuf) {
- err = -ENOMEM;
- dev_err(&vdev->dev, "OOM for control outbuf\n");
- goto free_vqs;
- }
fill_queue(portdev->c_ivq, &portdev->cvq_lock);
}
Amit
^ permalink raw reply related
* [PATCH] vhost-net: switch to smp barriers
From: Michael S. Tsirkin @ 2010-02-01 17:21 UTC (permalink / raw)
To: Michael S. Tsirkin, Rusty Russell, kvm, virtualization, netdev,
linux-kernel
vhost-net only uses memory barriers to control SMP effects
(communication with userspace potentially running on a different CPU),
so it should use SMP barriers and not mandatory barriers for memory
access ordering, as suggested by Documentation/memory-barriers.txt
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
drivers/vhost/vhost.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
The above applies on top of net-next-2.6. Does not seem to give any
measureable performance gain, but seems to generate less code
and I think it's better to use correct APIs.
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index c8c25db..6eb1525 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -685,7 +685,7 @@ int vhost_log_write(struct vhost_virtqueue *vq, struct vhost_log *log,
int i, r;
/* Make sure data written is seen before log. */
- wmb();
+ smp_wmb();
for (i = 0; i < log_num; ++i) {
u64 l = min(log[i].len, len);
r = log_write(vq->log_base, log[i].addr, l);
@@ -884,7 +884,7 @@ unsigned vhost_get_vq_desc(struct vhost_dev *dev, struct vhost_virtqueue *vq,
return vq->num;
/* Only get avail ring entries after they have been exposed by guest. */
- rmb();
+ smp_rmb();
/* Grab the next descriptor number they're advertising, and increment
* the index we've seen. */
@@ -996,14 +996,14 @@ int vhost_add_used(struct vhost_virtqueue *vq, unsigned int head, int len)
return -EFAULT;
}
/* Make sure buffer is written before we update index. */
- wmb();
+ smp_wmb();
if (put_user(vq->last_used_idx + 1, &vq->used->idx)) {
vq_err(vq, "Failed to increment used idx");
return -EFAULT;
}
if (unlikely(vq->log_used)) {
/* Make sure data is seen before log. */
- wmb();
+ smp_wmb();
log_write(vq->log_base, vq->log_addr + sizeof *vq->used->ring *
(vq->last_used_idx % vq->num),
sizeof *vq->used->ring);
@@ -1060,7 +1060,7 @@ bool vhost_enable_notify(struct vhost_virtqueue *vq)
}
/* They could have slipped one in as we were doing that: make
* sure it's written, then check again. */
- mb();
+ smp_mb();
r = get_user(avail_idx, &vq->avail->idx);
if (r) {
vq_err(vq, "Failed to check avail idx at %p: %d\n",
--
1.6.6.144.g5c3af
^ permalink raw reply related
* Workgroup Meetings at Collaboration Summit
From: C. Craig Ross @ 2010-02-01 17:55 UTC (permalink / raw)
To: C. Craig Ross
[-- Attachment #1.1: Type: text/plain, Size: 1079 bytes --]
Hello,
We are reaching out to all of our workgroups to remind you about the
upcoming Linux Foundation Collaboration Summit being held at the Hotel
Kabuki in San Francisco on April 14 - 16, 2010. This is a great opportunity
for workgroups to meet face-to-face and interact with other Linux community
members and we strongly encourage your workgroup to participate. If your
workgroup would like to reserve meeting space at the venue for meetings
please let us know as soon as possible. Please include the length of your
meeting (1/2 day, 1 day, 1.5 days, or 2 days), the number of people you are
expecting and any technical requirements that you may have. To request your
invitation or to learn more about the 4th Annual Collaboration Summit please
visit http://events.linuxfoundation.org/events/collaboration-summit
We look forward to your participation and hope to see you in April. If you
have any questions please don't hesitate to contact us. Thank you.
Regards,
C.
--
C. Craig Ross
Community Relations Manager
The Linux Foundation
http://www.linuxfoundation.org/
[-- Attachment #1.2: Type: text/html, Size: 1381 bytes --]
[-- Attachment #2: Type: text/plain, Size: 184 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* VPACT 2010: Deadline Extended to Feb 8 (Third International Workshop on Virtualization Performance: Analysis, Characterization and Tools)
From: Ming Zhao @ 2010-02-02 4:40 UTC (permalink / raw)
To: tcpp-announce, performance, infodir_sigarch, vsigplan-l,
publicity, micro_publicity, hpc-announ
In-Reply-To: <4B5B23F7.2040102@cis.fiu.edu>
[Apologies if you receive this announcement multiple times]
Update:
-------
* Paper submission deadline is extended to Feb 8
========================================================================
VPACT 2010 CALL FOR PAPERS
Third International Workshop on
Virtualization Performance: Analysis, Characterization and Tools
March 28, 2010
White Plains, New York
(co-located with IEEE ISPASS 2010)
========================================================================
The International Workshop on Virtualization Performance: Analysis,
Characterization and Tools (VPACT) is a selective venue for reporting
and discussing new initial results in the measurement,
characterization, analysis, and modeling of the performance of
virtualized computer systems, including the tools to support such
work. VPACT is interested in results at all scales, including
multicore/manycore processors, mobile devices, desktops, servers, data
centers, clusters, parallel supercomputers, and distributed
virtualized computing environments.
VPACT 2010 seeks papers from researchers and practitioners in both
academia and industry. Topics of interest include, but are not
limited to the following, in the context of virtualized computer
systems:
- Performance measurement, characterization, analysis, and modeling
- Power measurement characterization, analysis, and modeling
- Workload measurement characterization, analysis, and modeling
- Benchmarks and benchmarking
- Evaluation of hardware virtualization features
- Evaluation of virtualization software (VMMs, etc)
- Evaluation of virtualization services (Clouds, etc)
- Evaluation of scalability in virtualized environments
- Evaluation of innovative uses of virtualization
- Interaction of virtualization and multicore/manycore architectures
- Interaction of virtualization and parallel computing
- Interaction of language and OS virtual machines
- Tools and techniques
Papers should be no more than 10 pages in length, should be
formatted according to the ACM SIG Proceedings style
(http://www.acm.org/sigs/publications/proceedings-templates), and must
be in PDF format. Reviewing is single-blind. Submission instructions
are available on the workshop web site, http://vpact.org.
DATES
Submission deadline: February 8, 2010
Notification: March 1, 2010
Final form: March 8, 2010
Workshop: March 28, 2010
ORGANIZATION
General Chair
Mazin Yousif, IBM
Program Chair
Peter Dinda, Northwestern University
Publicity Chair
Ming Zhao, Florida International University
Program Committee
Patrick Bridges, University of New Mexico
Ron Brightwell, Sandia National Labs
Kshitij Doshi, Intel
Renato Figueiredo, University of Florida
Russ Joseph, Northwestern University
John Lange, Northwestern University
Arthur Maccabe, Oak Ridge National Labs
Elmoustapha Ould-ahmed-vall, Intel
Dhabaleswar Panda, Ohio State University
Kevin Pedretti, Sandia National Labs
Stephen Scott, Oak Ridge National Labs
Benjamin Serebrin, AMD
Tim Sherwood, UC Santa Barbara
Seetharami Seelam, IBM Research
Karsten Schwan, Georgia Tech
Richard Uhlig, Intel
Bhuvan Urgaonkar, Penn State
Peter Varman, Rice University
Dongyan Xu, Purdue
Ming Zhao, Florida International University
--
Ming Zhao, Assistant Professor
School of Computing and Information Sciences
Florida International University
Tel: (305) 348-2034, Fax: (305) 348-3549
Web: http://www.cis.fiu.edu/~zhaom
^ permalink raw reply
* Re: [PATCH 0/2] virtio net improvements
From: Rusty Russell @ 2010-02-02 23:27 UTC (permalink / raw)
To: netdev; +Cc: Shirley Ma, Michael S. Tsirkin, David Miller, virtualization
In-Reply-To: <201001292346.43675.rusty@rustcorp.com.au>
On Fri, 29 Jan 2010 11:46:43 pm Rusty Russell wrote:
> Hi Dave,
>
> Nice driver optimization from Shirley, but requires a new virtio hook.
> Do you want to take both? I have nothing else overlapping it.
Dave, any news on this? Shirley, I note that your final commit message did
not contain this information from your original version:
Tests have been done for small packets, big packets and
mergeable buffers.
The single netperf TCP_STREAM performance improved for host to guest.
It also reduces UDP packets drop rate.
The netperf laptop results were:
mtu=1500
netperf -H xxx -l 120
w/o patch w/i patch (two runs)
guest to host: 3336.84Mb/s 3730.14Mb/s ~ 3582.88Mb/s
host to guest: 3165.10Mb/s 3370.39Mb/s ~ 3407.96Mb/s
Thanks,
Rusty.
^ permalink raw reply
* Re: [PATCH 0/2] virtio net improvements
From: David Miller @ 2010-02-02 23:29 UTC (permalink / raw)
To: rusty; +Cc: netdev, mashirle, mst, virtualization
In-Reply-To: <201002030957.06307.rusty@rustcorp.com.au>
From: Rusty Russell <rusty@rustcorp.com.au>
Date: Wed, 3 Feb 2010 09:57:06 +1030
> On Fri, 29 Jan 2010 11:46:43 pm Rusty Russell wrote:
>> Hi Dave,
>>
>> Nice driver optimization from Shirley, but requires a new virtio hook.
>> Do you want to take both? I have nothing else overlapping it.
>
> Dave, any news on this?
Just slowly creeping up the backlog :-)
^ permalink raw reply
* Re: [PATCH 1/2] virtio: Add ability to detach unused buffers from vrings
From: David Miller @ 2010-02-02 23:59 UTC (permalink / raw)
To: rusty; +Cc: netdev, mashirle, mst, virtualization
In-Reply-To: <201001292349.05360.rusty@rustcorp.com.au>
From: Rusty Russell <rusty@rustcorp.com.au>
Date: Fri, 29 Jan 2010 23:49:05 +1030
> From: Shirley Ma <mashirle@us.ibm.com>
>
> There's currently no way for a virtio driver to ask for unused
> buffers, so it has to keep a list itself to reclaim them at shutdown.
> This is redundant, since virtio_ring stores that information. So
> add a new hook to do this.
>
> Signed-off-by: Shirley Ma <xma@us.ibm.com>
> Signed-off-by: Amit Shah <amit.shah@redhat.com>
> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] virtio_net: Defer skb allocation in receive path Date: Wed, 13 Jan 2010 12:53:38 -0800
From: David Miller @ 2010-02-02 23:59 UTC (permalink / raw)
To: rusty; +Cc: netdev, mashirle, mst, virtualization
In-Reply-To: <201001292350.04544.rusty@rustcorp.com.au>
From: Rusty Russell <rusty@rustcorp.com.au>
Date: Fri, 29 Jan 2010 23:50:04 +1030
> From: Shirley Ma <mashirle@us.ibm.com>
>
> virtio_net receives packets from its pre-allocated vring buffers, then it
> delivers these packets to upper layer protocols as skb buffs. So it's not
> necessary to pre-allocate skb for each mergable buffer, then frees extra
> skbs when buffers are merged into a large packet. This patch has deferred
> skb allocation in receiving packets for both big packets and mergeable buffers
> to reduce skb pre-allocations and skb frees. It frees unused buffers by calling
> detach_unused_buf in vring, so recv skb queue is not needed.
>
> Signed-off-by: Shirley Ma <xma@us.ibm.com>
> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Applied.
^ permalink raw reply
* Re: [PATCH 0/3 v4] macvtap driver
From: David Miller @ 2010-02-04 4:21 UTC (permalink / raw)
To: arnd; +Cc: herbert, mst, netdev, bridge, linux-kernel, virtualization,
shemminger
In-Reply-To: <201001302322.15237.arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Sat, 30 Jan 2010 23:22:15 +0100
> This is the fourth version of the macvtap driver,
> based on the comments I got for the last version
> I got a few days ago. Very few changes:
>
> * release netdev in chardev open function so
> we can destroy it properly.
> * Implement TUNSETSNDBUF
> * fix sleeping call in rcu_read_lock
> * Fix comment in namespace isolation patch
> * Fix small context difference to make it apply
> to net-next
>
> I can't really test here while travelling, so please
> give it a go if you're interested in this driver.
All applied to net-next-2.6, thanks!
^ permalink raw reply
* Re: [PATCH] vhost-net: switch to smp barriers
From: Michael S. Tsirkin @ 2010-02-07 9:07 UTC (permalink / raw)
To: Rusty Russell, kvm, virtualization, netdev, linux-kernel,
David Miller
In-Reply-To: <20100201172101.GA10900@redhat.com>
On Mon, Feb 01, 2010 at 07:21:02PM +0200, Michael S. Tsirkin wrote:
> vhost-net only uses memory barriers to control SMP effects
> (communication with userspace potentially running on a different CPU),
> so it should use SMP barriers and not mandatory barriers for memory
> access ordering, as suggested by Documentation/memory-barriers.txt
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Rusty, any feedback on this one?
Thanks!
> ---
> drivers/vhost/vhost.c | 10 +++++-----
> 1 files changed, 5 insertions(+), 5 deletions(-)
>
> The above applies on top of net-next-2.6. Does not seem to give any
> measureable performance gain, but seems to generate less code
> and I think it's better to use correct APIs.
>
> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> index c8c25db..6eb1525 100644
> --- a/drivers/vhost/vhost.c
> +++ b/drivers/vhost/vhost.c
> @@ -685,7 +685,7 @@ int vhost_log_write(struct vhost_virtqueue *vq, struct vhost_log *log,
> int i, r;
>
> /* Make sure data written is seen before log. */
> - wmb();
> + smp_wmb();
> for (i = 0; i < log_num; ++i) {
> u64 l = min(log[i].len, len);
> r = log_write(vq->log_base, log[i].addr, l);
> @@ -884,7 +884,7 @@ unsigned vhost_get_vq_desc(struct vhost_dev *dev, struct vhost_virtqueue *vq,
> return vq->num;
>
> /* Only get avail ring entries after they have been exposed by guest. */
> - rmb();
> + smp_rmb();
>
> /* Grab the next descriptor number they're advertising, and increment
> * the index we've seen. */
> @@ -996,14 +996,14 @@ int vhost_add_used(struct vhost_virtqueue *vq, unsigned int head, int len)
> return -EFAULT;
> }
> /* Make sure buffer is written before we update index. */
> - wmb();
> + smp_wmb();
> if (put_user(vq->last_used_idx + 1, &vq->used->idx)) {
> vq_err(vq, "Failed to increment used idx");
> return -EFAULT;
> }
> if (unlikely(vq->log_used)) {
> /* Make sure data is seen before log. */
> - wmb();
> + smp_wmb();
> log_write(vq->log_base, vq->log_addr + sizeof *vq->used->ring *
> (vq->last_used_idx % vq->num),
> sizeof *vq->used->ring);
> @@ -1060,7 +1060,7 @@ bool vhost_enable_notify(struct vhost_virtqueue *vq)
> }
> /* They could have slipped one in as we were doing that: make
> * sure it's written, then check again. */
> - mb();
> + smp_mb();
> r = get_user(avail_idx, &vq->avail->idx);
> if (r) {
> vq_err(vq, "Failed to check avail idx at %p: %d\n",
> --
> 1.6.6.144.g5c3af
^ permalink raw reply
* Re: [PATCH] vhost-net: switch to smp barriers
From: Avi Kivity @ 2010-02-07 9:42 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Rusty Russell, kvm, virtualization, netdev, linux-kernel,
David Miller
In-Reply-To: <20100201172101.GA10900@redhat.com>
On 02/01/2010 07:21 PM, Michael S. Tsirkin wrote:
> vhost-net only uses memory barriers to control SMP effects
> (communication with userspace potentially running on a different CPU),
> so it should use SMP barriers and not mandatory barriers for memory
> access ordering, as suggested by Documentation/memory-barriers.txt
>
>
A UP guest running on an SMP host still needs those barriers.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [PATCH] vhost-net: switch to smp barriers
From: Michael S. Tsirkin @ 2010-02-07 9:44 UTC (permalink / raw)
To: Avi Kivity
Cc: Rusty Russell, kvm, virtualization, netdev, linux-kernel,
David Miller
In-Reply-To: <4B6E8B05.8070607@redhat.com>
On Sun, Feb 07, 2010 at 11:42:29AM +0200, Avi Kivity wrote:
> On 02/01/2010 07:21 PM, Michael S. Tsirkin wrote:
>> vhost-net only uses memory barriers to control SMP effects
>> (communication with userspace potentially running on a different CPU),
>> so it should use SMP barriers and not mandatory barriers for memory
>> access ordering, as suggested by Documentation/memory-barriers.txt
>>
>>
>
> A UP guest running on an SMP host still needs those barriers.
Correct. And since vhost net is running host-side, smp_XX
barriers will do exactly the right thing, right?
> --
> error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [PATCH] vhost-net: switch to smp barriers
From: Avi Kivity @ 2010-02-07 9:56 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Rusty Russell, kvm, virtualization, netdev, linux-kernel,
David Miller
In-Reply-To: <20100207094441.GA20271@redhat.com>
On 02/07/2010 11:44 AM, Michael S. Tsirkin wrote:
> On Sun, Feb 07, 2010 at 11:42:29AM +0200, Avi Kivity wrote:
>
>> On 02/01/2010 07:21 PM, Michael S. Tsirkin wrote:
>>
>>> vhost-net only uses memory barriers to control SMP effects
>>> (communication with userspace potentially running on a different CPU),
>>> so it should use SMP barriers and not mandatory barriers for memory
>>> access ordering, as suggested by Documentation/memory-barriers.txt
>>>
>>>
>>>
>> A UP guest running on an SMP host still needs those barriers.
>>
> Correct. And since vhost net is running host-side, smp_XX
> barriers will do exactly the right thing, right?
>
Right, of course. Mixed up virtio and vhost.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [PATCH] vhost-net: switch to smp barriers
From: Rusty Russell @ 2010-02-08 8:19 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: kvm, virtualization, netdev, linux-kernel, David Miller
In-Reply-To: <20100207090749.GA12968@redhat.com>
On Sun, 7 Feb 2010 07:37:49 pm Michael S. Tsirkin wrote:
> On Mon, Feb 01, 2010 at 07:21:02PM +0200, Michael S. Tsirkin wrote:
> > vhost-net only uses memory barriers to control SMP effects
> > (communication with userspace potentially running on a different CPU),
> > so it should use SMP barriers and not mandatory barriers for memory
> > access ordering, as suggested by Documentation/memory-barriers.txt
> >
> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>
>
> Rusty, any feedback on this one?
> Thanks!
Yep. barrier() is correct on UP to guard against preemption.
Acked-by: Rusty Russell <rusty@rustcorp.com.au>
Thanks,
Rusty.
^ permalink raw reply
* [PATCH] virtio: fix balloon without VIRTIO_BALLOON_F_STATS_VQ
From: Rusty Russell @ 2010-02-08 10:32 UTC (permalink / raw)
To: virtualization
When running under qemu-kvm-0.11.0:
BUG: unable to handle kernel paging request at 56e58955
...
Process vballoon (pid: 1297, ti=c7976000 task=c70a6ca0 task.ti=c7
...
Call Trace:
[<c88253a3>] ? balloon+0x1b3/0x440 [virtio_balloon]
[<c041c2d7>] ? schedule+0x327/0x9d0
[<c88251f0>] ? balloon+0x0/0x440 [virtio_balloon]
[<c014a2d4>] ? kthread+0x74/0x80
[<c014a260>] ? kthread+0x0/0x80
[<c0103b36>] ? kernel_thread_helper+0x6/0x30
need_stats_update should be zero-initialized.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Cc: Adam Litke <agl@us.ibm.com>
diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -292,6 +292,7 @@ static int virtballoon_probe(struct virt
vb->num_pages = 0;
init_waitqueue_head(&vb->config_change);
vb->vdev = vdev;
+ vb->need_stats_update = 0;
/* We expect two virtqueues: inflate and deflate,
* and optionally stat. */
^ permalink raw reply
* Re: [PATCH] virtio: fix balloon without VIRTIO_BALLOON_F_STATS_VQ
From: Adam Litke @ 2010-02-08 13:33 UTC (permalink / raw)
To: Rusty Russell; +Cc: virtualization
In-Reply-To: <201002082102.42331.rusty@rustcorp.com.au>
On Mon, 2010-02-08 at 21:02 +1030, Rusty Russell wrote:
> need_stats_update should be zero-initialized.
Yes indeed.
Acked-by: Adam Litke <agl@us.ibm.com>
> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
> Cc: Adam Litke <agl@us.ibm.com>
>
> diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
> --- a/drivers/virtio/virtio_balloon.c
> +++ b/drivers/virtio/virtio_balloon.c
> @@ -292,6 +292,7 @@ static int virtballoon_probe(struct virt
> vb->num_pages = 0;
> init_waitqueue_head(&vb->config_change);
> vb->vdev = vdev;
> + vb->need_stats_update = 0;
>
> /* We expect two virtqueues: inflate and deflate,
> * and optionally stat. */
--
Thanks,
Adam
^ permalink raw reply
* [PATCH] virtio-spec: document indirect descriptors
From: Michael S. Tsirkin @ 2010-02-10 13:00 UTC (permalink / raw)
To: rusty, virtualization; +Cc: markmc, qemu-devel, Anthony Liguori, kvm
Add documentation for indirect descriptors
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
virtio-spec.lyx | 118 +++++++++++++++++++++++++++++++++++++++++++++++++++++--
1 files changed, 114 insertions(+), 4 deletions(-)
diff --git a/virtio-spec.lyx b/virtio-spec.lyx
index 8062e11..b5a8fbd 100644
--- a/virtio-spec.lyx
+++ b/virtio-spec.lyx
@@ -1,4 +1,4 @@
-#LyX 1.6.4 created this file. For more info see http://www.lyx.org/
+#LyX 1.6.5 created this file. For more info see http://www.lyx.org/
\lyxformat 345
\begin_document
\begin_header
@@ -36,8 +36,7 @@
\paperpagestyle default
\tracking_changes true
\output_changes true
-\author ""
-\author ""
+\author "Michael S. Tsirkin"
\author ""
\end_header
@@ -1441,7 +1440,28 @@ struct vring_desc {
\begin_layout Plain Layout
-#define VRING_DESC_F_WRITE 2
+#define VRING_DESC_F_WRITE 2
+\change_deleted 0 1265802057
+
+\change_inserted 0 1265802048
+
+\end_layout
+
+\begin_layout Plain Layout
+
+\change_inserted 0 1265802054
+
+/* This means the buffer contains a list of buffer descriptors.
+ */
+\end_layout
+
+\begin_layout Plain Layout
+
+\change_inserted 0 1265802049
+
+#define VRING_DESC_F_INDIRECT 4
+\change_unchanged
+
\end_layout
\begin_layout Plain Layout
@@ -1478,6 +1498,96 @@ struct vring_desc {
\begin_layout Standard
The number of descriptors in the table is specified by the Queue Size field
for this virtqueue.
+\change_deleted 0 1265801065
+
+\end_layout
+
+\begin_layout Subsubsection
+
+\change_inserted 0 1265801341
+Indirect Descriptors
+\end_layout
+
+\begin_layout Standard
+
+\change_inserted 0 1265805736
+Some devices benefit by concurrently dispatching a large number of large
+ requests.
+ To increase ring capacity it is possible to store a table of
+\emph on
+indirect descriptors
+\emph default
+ anywhere in memory, and insert a descriptor in main virtqueue (with flags&INDIRECT on) that refers to memory buffer containing this
+\emph on
+indirect descriptor table
+\emph default
+; fields
+\emph on
+addr
+\emph default
+ and
+\emph on
+len
+\emph default
+ refer to the indirect table address and length in bytes, respectively.
+ The indirect table layout structure looks like this (len is the length
+ of the descriptor that refers to this table, which is a variable, so this
+ code won't compile):
+\end_layout
+
+\begin_layout Standard
+
+\change_inserted 0 1265804397
+\begin_inset listings
+inline false
+status open
+
+\begin_layout Plain Layout
+
+\change_inserted 0 1265804526
+
+struct indirect_descriptor_table {
+\end_layout
+
+\begin_layout Plain Layout
+
+\change_inserted 0 1265804397
+
+ /* The actual descriptors (16 bytes each) */
+\end_layout
+
+\begin_layout Plain Layout
+
+\change_inserted 0 1265804473
+
+ struct vring_desc desc[len / 16];
+\end_layout
+
+\begin_layout Plain Layout
+
+\change_inserted 0 1265804397
+
+};
+\end_layout
+
+\end_inset
+
+
+\end_layout
+
+\begin_layout Standard
+
+\change_inserted 0 1265805219
+The first indirect descriptor is located at start of the indirect descriptor
+ table (index 0), additional indirect descriptors are chained by next field.
+ An indirect descriptor without next field (with flags&NEXT off) signals
+ the end of the indirect descriptor table, and transfers control back to
+ the main virtqueue.
+ An indirect descriptor can not refer to another indirect descriptor table
+ (flags&INDIRECT must be off).
+ A single indirect descriptor table can include both read-only and write-only
+ descriptors; write-only flag (flags&WRITE) in the descriptor that refers
+ to it is ignored.
\end_layout
\begin_layout Subsection
--
1.6.6.144.g5c3af
^ permalink raw reply related
* Paravirt compile failure with gcc33
From: Jan Engelhardt @ 2010-02-10 18:13 UTC (permalink / raw)
To: Jeremy Fitzhardinge; +Cc: Linux Kernel Mailing List, virtualization
Hi,
As I was compile-testing 2.6.33-rc with gcc-3.3,
binutils-2.19.51-10.26.4.x86_64, I observed a failure when
CONFIG_PARAVIRT is turned on:
[any file]
/home/jengelh/code/linux/arch/x86/include/asm/paravirt.h: In function
`rif_seq_stop':
/home/jengelh/code/linux/arch/x86/include/asm/paravirt.h:763: warning:
asm operand 5 probably doesn't match constraints
/home/jengelh/code/linux/arch/x86/include/asm/paravirt.h:858: warning:
asm operand 2 probably doesn't match constraints
/home/jengelh/code/linux/arch/x86/include/asm/paravirt.h:763: error:
impossible constraint in `asm'
/home/jengelh/code/linux/arch/x86/include/asm/paravirt.h:858: error:
impossible constraint in `asm'
Disabling either PARAVIRT or using GCC4.x works around this.
^ permalink raw reply
* Re: Paravirt compile failure with gcc33
From: Jeremy Fitzhardinge @ 2010-02-10 18:38 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: virtualization, H. Peter Anvin, Linux Kernel Mailing List
In-Reply-To: <alpine.LSU.2.01.1002101909560.29808@obet.zrqbmnf.qr>
On 02/10/2010 10:13 AM, Jan Engelhardt wrote:
> As I was compile-testing 2.6.33-rc with gcc-3.3,
> binutils-2.19.51-10.26.4.x86_64, I observed a failure when
> CONFIG_PARAVIRT is turned on:
>
Yeah, there's a gcc bug of some kind there, and its very hard to see how
to work around it. When we last discussed this, I think we were close
to deciding to obsolete gcc 3.3.
HPA, do you remember?
J
>
> [any file]
> /home/jengelh/code/linux/arch/x86/include/asm/paravirt.h: In function
> `rif_seq_stop':
> /home/jengelh/code/linux/arch/x86/include/asm/paravirt.h:763: warning:
> asm operand 5 probably doesn't match constraints
> /home/jengelh/code/linux/arch/x86/include/asm/paravirt.h:858: warning:
> asm operand 2 probably doesn't match constraints
> /home/jengelh/code/linux/arch/x86/include/asm/paravirt.h:763: error:
> impossible constraint in `asm'
> /home/jengelh/code/linux/arch/x86/include/asm/paravirt.h:858: error:
> impossible constraint in `asm'
>
> Disabling either PARAVIRT or using GCC4.x works around this.
> _______________________________________________
> Virtualization mailing list
> Virtualization@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/virtualization
>
>
^ permalink raw reply
* Re: Paravirt compile failure with gcc33
From: H. Peter Anvin @ 2010-02-10 18:41 UTC (permalink / raw)
To: Jeremy Fitzhardinge
Cc: Jan Engelhardt, Jeremy Fitzhardinge, virtualization,
Linux Kernel Mailing List
In-Reply-To: <4B72FD09.1020202@goop.org>
On 02/10/2010 10:38 AM, Jeremy Fitzhardinge wrote:
> On 02/10/2010 10:13 AM, Jan Engelhardt wrote:
>> As I was compile-testing 2.6.33-rc with gcc-3.3,
>> binutils-2.19.51-10.26.4.x86_64, I observed a failure when
>> CONFIG_PARAVIRT is turned on:
>>
>
> Yeah, there's a gcc bug of some kind there, and its very hard to see how
> to work around it. When we last discussed this, I think we were close
> to deciding to obsolete gcc 3.3.
>
> HPA, do you remember?
>
I don't, and the macros are tangled enough that I'm not actually sure
what the failure really is.
-hpa
^ permalink raw reply
* Re: Paravirt compile failure with gcc33
From: Jan Engelhardt @ 2010-02-10 19:20 UTC (permalink / raw)
To: Jeremy Fitzhardinge
Cc: Jeremy Fitzhardinge, virtualization, Linux Kernel Mailing List,
H. Peter Anvin
In-Reply-To: <4B72FD09.1020202@goop.org>
On Wednesday 2010-02-10 19:38, Jeremy Fitzhardinge wrote:
> On 02/10/2010 10:13 AM, Jan Engelhardt wrote:
>> As I was compile-testing 2.6.33-rc with gcc-3.3,
>> binutils-2.19.51-10.26.4.x86_64, I observed a failure when
>> CONFIG_PARAVIRT is turned on:
>>
>
> Yeah, there's a gcc bug of some kind there, and its very hard to see how to
> work around it. When we last discussed this, I think we were close to deciding
> to obsolete gcc 3.3.
>
> HPA, do you remember?
In fact, there's such a big bug in there that I'll get a runaway
allocation later on when kvm.o is to be compiled. This is getting fun,
but I am absolutely fine with obsoleting 3.x :)
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox