On Tuesday 03 April 2007, H. Peter Anvin wrote:
However, one probably wants to think about what the heck one actually
means with virtualization in the absence of a lot of this stuff. PCI
is probably the closest thing we have to a lowest common denominator for
device detection.
I think
On Tuesday 03 April 2007, Cornelia Huck wrote:
I think that's true outside of s390, but a standardized virtual device
interface should be able to work there as well. Interestingly, the
s390 channel I/O also uses two 16 bit numbers to identify a device
(type and model), just like PCI or
On Tuesday 03 April 2007, Cornelia Huck wrote:
On Tue, 3 Apr 2007 14:15:37 +0200, Arnd Bergmann [EMAIL PROTECTED] wrote:
That's OK for a virtualized architecture where the base architecture
already supports PCI. But a traditional s390 OS would be as unhappy
with a PCI device as with a device
On Tuesday 03 April 2007, Jeremy Fitzhardinge wrote:
That said, something like USB is probably the best bet for this kind of
low-performance device. I think. Not that I really know anything about
USB.
USB has the disadvantage that it is more complex than PCI and requires
significantly more
On Wednesday 04 April 2007, H. Peter Anvin wrote:
Configuration space access is platform-dependent. It's only defined to
work in a specific way on x86 platforms.
Interrupt swizzling is really totally independent of PCI. ALL PCI
really provides is up to four interrupts per device (not
On Sunday 10 June 2007, Avi Kivity wrote:
There are probably more. Any ideas?
* watchdog timer
* tty ports (not just console) to attach to via host socket
* alsa
* hostfs (UML like)
Arnd
___
Virtualization mailing list
On Sunday 10 June 2007, Avi Kivity wrote:
- PCI (or your favorite HW bus) passthrough, for your favorite oddball
device (e.g., crypto-accelerators).
Won't all high-bandwidth traffic be through dma, bypassing virtio?
It can be done, but you'd also need a passthrough for the IOMMU
in
On Wednesday 13 June 2007, Caitlin Bestler wrote:
It can be done, but you'd also need a passthrough for the
IOMMU in that case, and you get a potential security hole: if
a malicious guest is smart enough to figure out IOMMU
mappings from the device to memory owned by the host.
If it
On Thursday 14 June 2007, Caitlin Bestler wrote:
Why not simply adopt the policy that if the IOMMU does not meet
the security requirements of the Hypervisor then it is not an
IOMMU as far as the Hypervisor is concerned?
More specificially, the Hypervisor should enable direct access
by a
On Saturday 16 June 2007, Rusty Russell wrote:
This is a bonus patch for those wondering how a virtio implementation
can look.
Thanks, I assumed it was something like this, but having the code
in front of me makes it a lot easier to comment on it.
+static struct lguest_driver
On Monday 09 July 2007, Avi Kivity wrote:
Suppose there is one message queued. The host reconfigures and sends
the message. A new reconfiguration event now cannot be propagated.
If there are two messages queued, the host can post the updates in the
second message. The guest would then
On Monday 09 July 2007, Avi Kivity wrote:
Arnd Bergmann wrote:
But you can always have one more event than you have space in the queue,
so the host _still_ needs to do its own queuing of these events.
It's probably enough to keep a flag that the guest is not up-to-date,
and have
On Tuesday 21 August 2007, Rusty Russell wrote:
One solution would be to use the xmit_done interrupt. Unfortunately this
would
require additional locking as multiple interrupts can happen at two or more
cpus. Do you have any better ideas?
The only reason that we don't do it in
On Thursday 20 September 2007, Rusty Russell wrote:
+ * virtio_driver - operations for a virtio I/O driver
+ * @name: the name of the driver (KBUILD_MODNAME).
+ * @owner: the module which contains these routines (ie. THIS_MODULE).
+ * @id_table: the ids (we re-use PCI ids) serviced by this
On Friday 21 September 2007, Rusty Russell wrote:
Hmm, I guess we could have a PCI driver which claims all VIRTIO vendor
devices.
yes, that was the idea.
Then it can call virtio_find_driver() (?) at the top of its
probe function to find if there's a matching virtio driver.
This PCI
On Saturday 22 September 2007, Rusty Russell wrote:
But now each virtio device has two struct devices, not one. And
you've made up a fictional bus to do it.
Yet for PCI systems, it really is a PCI device; exposing a second bus to
userspace just because we put a layer in our implementation
On Monday 24 September 2007, Rusty Russell wrote:
This attempts to implement a virtual I/O layer which should allow
common drivers to be efficiently used across most virtual I/O
mechanisms. It will no-doubt need further enhancement.
Hi Rusty,
Thanks for your update, as you can imagine, I'm
On Thursday 08 November 2007, Anthony Liguori wrote:
+/* A PCI device has it's own struct device and so does a virtio device so
+ * we create a place for the virtio devices to show up in sysfs. I think it
+ * would make more sense for virtio to not insist on having it's own device.
*/
On Thursday 08 November 2007, Anthony Liguori wrote:
They already show up underneath of the PCI bus. The issue is that there
are two separate 'struct device's for each virtio device. There's the
PCI device (that's part of the pci_dev structure) and then there's the
virtio_device one. I
On Tuesday 27 November 2007, Avi Kivity wrote:
:-) Do you know if there is a hard limit on the number of devices on
a PCI bus? My concern was that it was limited by something stupid
like an 8-bit identifier.
IIRC pci slots are 8-bit, but you can have multiple buses, so
effectively
On Tuesday 25 March 2008, Carsten Otte wrote:
+
+static inline void __user *__guestaddr_to_user(struct kvm_vcpu *vcpu,
+u64 guestaddr)
+{
+ u64 prefix = vcpu-arch.sie_block-prefix;
+ u64 origin = vcpu-kvm-arch.guest_origin;
+ u64
On Tuesday 25 March 2008, Carsten Otte wrote:
+ case KVM_S390_SIGP_SET_PREFIX:
+ VCPU_EVENT(vcpu, 4, interrupt: set prefix to %x,
+inti-prefix.address);
+ vcpu-stat.deliver_prefix_signal++;
+ vcpu-arch.sie_block-prefix =
On Saturday 05 April 2008, Rusty Russell wrote:
+asmlinkage long sys_vringfd(void __user *addr,
+ unsigned num_descs,
+ u16 __user *last_used)
+{
+ int fd, err;
+ struct file *filp;
+ struct vring_info *vr;
+
+ /*
On Saturday 05 April 2008, Rusty Russell wrote:
static const struct file_operations vring_fops = {
.release= vring_release,
.write = vring_write,
.poll = vring_poll,
+ .ioctl = vring_ioctl,
};
This should also set the
On Tuesday 03 June 2008, Christian Borntraeger wrote:
+/* The hvc device */
+struct hvc_struct *hvc;
+
I guess this should be static, a three letter identifier for a global variable
is not really unique.
Arnd
___
Virtualization mailing
On Tuesday 03 June 2008, Christian Borntraeger wrote:
@@ -42,22 +42,48 @@
*/
#define HVC_ALLOC_TTY_ADAPTERS 8
+struct hvc_struct {
+ spinlock_t lock;
+ int index;
+ struct tty_struct *tty;
+ unsigned int count;
+ int do_wakeup;
+ char *outbuf;
+
On Wednesday 26 November 2008, Gleb Natapov wrote:
The interfaces that are being considered are netlink socket (only datagram
semantics, linux specific), new socket family or character device with
different minor number for each channel. Which one better suits for
the purpose? Is there other
On Friday 17 July 2009, Greg Kroah-Hartman wrote:
I don't think we really want to be doing a irqsave for this code, but I
left it alone to preserve the original codepath. It should be reviewed
later.
This patch does not preserve the original code path if any of the
callers has a different irq
On Friday 17 July 2009, Greg Kroah-Hartman wrote:
@@ -43,7 +43,7 @@ typedef struct _RING_BUFFER {
// volatile u32 InterruptMask;
// Ring data starts here + RingDataStartOffset !!! DO NOT place any
fields below this !!!
u8 Buffer[0];
-} STRUCT_PACKED RING_BUFFER;
On Friday 17 July 2009, Greg Kroah-Hartman wrote:
From: Greg Kroah-Hartman gre...@suse.de
The ULONG and LONG typedefs are now removed from the Hyper-V driver
code
This conversion is not equivalent:
//
-// unsigned types
-//
-typedef unsigned int ULONG;
-
-//
-// signed
On Monday 20 July 2009, Greg KH wrote:
Anyway, I agree, for a proper review, I will show the final, cleaned
up version, like normal. But we aren't there just yet, that is why this
code is going to live in the staging tree for a while. Give us some
time to get it fixed up.
I would find it
On Friday 07 August 2009, Stephen Hemminger wrote:
So instead of adding more stuff to existing bridge code, why not
have a new driver for just VEPA. You could
do it with a simple version of macvlan type driver.
The current macvlan driver already does the downstream side of
VEPA and only needs
On Saturday 08 August 2009, Benny Amorsen wrote:
Would a SRIOV NIC with VEPA support show up as multiple devices? I.e.
would I get e.g. eth0-eth7 for a NIC with support for 8 virtual
interfaces? Would they have different MAC addresses?
It could, but the idea of SR-IOV is that it shows up as 8
On Friday 07 August 2009, Paul Congdon (UC Davis) wrote:
As I understand the macvlan code, it currently doesn't allow two VMs on the
same machine to communicate with one another.
There are patches to do that. I think if we add that, there should be
a way to choose the behavior between either
On Monday 10 August 2009, Fischer, Anna wrote:
Subject: Re: [PATCH][RFC] net/bridge: add basic VEPA support
On Friday 07 August 2009, Paul Congdon (UC Davis) wrote:
As I understand the macvlan code, it currently doesn't allow two VMs
on the
same machine to communicate with one
On Friday 07 August 2009, Paul Congdon (UC Davis) wrote:
I don't think your scheme works too well because broadcast packet coming
from other interfaces on br0 would get replicated and sent across the wire
to ethB multiple times.
Right, that won't work. So the bridge patch for the hairpin
On Monday 10 August 2009, Stephen Hemminger wrote:
On Sun, 09 Aug 2009 14:19:08 +0300, Or Gerlitz ogerl...@voltaire.com wrote:
Looking in macvlan_set_multicast_list() it acts in a similar manner to
macvlan_set_mac_address() in the sense that it calls dev_mc_sync(). I
assume what's left is
On Monday 10 August 2009, Fischer, Anna wrote:
On the VEPA filtering service side, the only change we have implemented
in the bridging code is that in VEPA mode all frames are passed to the
uplink on TX. However, frames are still passed through the netfilter
hooks before they go out on the
On Monday 10 August 2009, Stephen Hemminger wrote:
On Mon, 10 Aug 2009 16:32:01, Fischer, Anna anna.fisc...@hp.com wrote:
How would this work though, if the OS inside the guest wants to register
to a particular multicast address? Is this propagated through the backend
drivers to the
On Monday 10 August 2009, Michael S. Tsirkin wrote:
What it is: vhost net is a character device that can be used to reduce
the number of system calls involved in virtio networking.
Existing virtio net code is used in the guest without modification.
Very nice, I loved reading it. It's getting
On Monday 10 August 2009 20:10:44 Michael S. Tsirkin wrote:
On Mon, Aug 10, 2009 at 09:51:18PM +0200, Arnd Bergmann wrote:
what is the difference between vhost_net_reset_owner(n)
and vhost_net_set_socket(n, -1)?
set socket to -1 will only stop the device.
reset owner will let another
On Wednesday 12 August 2009, Gregory Haskins wrote:
Are you saying SRIOV is a requirement, and I can either program the
SRIOV adapter with a mac or use promis? Or are you saying I can use
SRIOV+programmed mac OR a regular nic + promisc (with a perf penalty).
SRIOV is not a requirement.
On Tuesday 11 August 2009, Paul Congdon (UC Davis) wrote:
The patch from Eric Biederman to allow macvlan to bridge between
its slave ports is at
http://kerneltrap.org/mailarchive/linux-netdev/2009/3/9/5125774
Looking through the discussions here, it does not seem as if a
On Wednesday 12 August 2009, Michael S. Tsirkin wrote:
If I understand it correctly, you can at least connect a veth pair
to a bridge, right? Something like
veth0 - veth1 - vhost - guest 1
eth0 - br0-|
veth2 - veth3 - vhost - guest 2
Heh, you
On Monday 10 August 2009, Michael S. Tsirkin wrote:
+struct workqueue_struct *vhost_workqueue;
[nitpicking] This could be static.
+/* The virtqueue structure describes a queue attached to a device. */
+struct vhost_virtqueue {
+ struct vhost_dev *dev;
+
+ /* The actual ring of
On Wednesday 12 August 2009, Michael S. Tsirkin wrote:
On Wed, Aug 12, 2009 at 07:03:22PM +0200, Arnd Bergmann wrote:
We discussed this before, and I still think this could be directly derived
from struct virtqueue, in the same way that vring_virtqueue is derived from
struct virtqueue.
I
On Wednesday 12 August 2009, Anthony Liguori wrote:
At any rate, I'd like to see performance results before we consider
trying to reuse virtio code.
Yes, I agree. I'd also like to do more work on the macvlan extensions
to see if it works out without involving a socket. Passing the socket
into
On Thursday 13 August 2009, Michael S. Tsirkin wrote:
On Wed, Aug 12, 2009 at 07:59:47PM +0200, Arnd Bergmann wrote:
The trick is to swap the virtqueues instead. virtio-net is actually
mostly symmetric in just the same way that the physical wires on a
twisted pair ethernet are symmetric (I
On Thursday 13 August 2009, Michael S. Tsirkin wrote:
The best way to do this IMO would be to add zero copy support to raw
sockets, vhost will then get it basically for free.
Yes, that would be nice. I wonder if that could lead to security
problems on TX though. I guess It will only bring
On Thursday 13 August 2009, Michael S. Tsirkin wrote:
Right now, the number of copy operations in your code is the same.
You are doing the copy a little bit later in skb_copy_datagram_iovec(),
which is indeed a very nice hack. Changing to a virtqueue based method
would imply that the host
-by: Arnd Bergmann a...@arndb.de
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization
, mostly by convincing me
that you got it right anyway ;-).
I hope this gets into 2.6.32, good work!
Signed-off-by: Michael S. Tsirkin m...@redhat.com
Acked-by: Arnd Bergmann a...@arndb.de
One idea though:
+ /* Parameter checking */
+ if (sock-sk-sk_type != SOCK_RAW
On Sunday 16 August 2009, Michael S. Tsirkin wrote:
On Fri, Aug 14, 2009 at 01:40:36PM +0200, Arnd Bergmann wrote:
* most of the transports are sockets, tap uses a character device.
This could be dealt with by having both a struct socket * in
struct vhost_net *and* a struct file
On Wednesday 19 August 2009, Michael S. Tsirkin wrote:
Maybe we could instead extend the 'splice' system call to work on a
vhost_net file descriptor. If we do that, we can put the access back
into a user thread (or two) that stays in splice indefinetely
An issue with exposing internal
On Wednesday 19 August 2009, Michael S. Tsirkin wrote:
On Wed, Aug 19, 2009 at 03:46:44PM +0200, Arnd Bergmann wrote:
On Wednesday 19 August 2009, Michael S. Tsirkin wrote:
Leaving that aside for now, you could replace VHOST_NET_SET_SOCKET,
VHOST_SET_OWNER, VHOST_RESET_OWNER
SET/RESET
On Thursday 20 August 2009, Michael S. Tsirkin wrote:
On Wed, Aug 19, 2009 at 05:27:07PM +0200, Arnd Bergmann wrote:
On Wednesday 19 August 2009, Michael S. Tsirkin wrote:
On Wed, Aug 19, 2009 at 03:46:44PM +0200, Arnd Bergmann wrote:
On Wednesday 19 August 2009, Michael S. Tsirkin wrote
On Thursday 20 August 2009, Michael S. Tsirkin wrote:
On Thu, Aug 20, 2009 at 03:10:54PM +0200, Arnd Bergmann wrote:
On Thursday 20 August 2009, Michael S. Tsirkin wrote:
It doesn't matter that I don't want this: allowing 1 process corrupt
another's memory is a security issue. Once you get
On Thursday 20 August 2009, Michael S. Tsirkin wrote:
The errors from the socket (or chardev, as that was the
start of the argument) should still fit into the categories
that I mentioned, either they can be handled by the host
kernel, or they are fatal.
Hmm, are you sure? Imagine a
On Thursday 20 August 2009, Mark McLoughlin wrote:
- I had expected this to be available as:
-net raw,ifname=eth2 -net nic,model=virtio
I'd prefer it this way, because it means you can use this mode even
without vhost and it's ties in better with the way all other qemu
On Tuesday 25 August 2009, Avi Kivity wrote:
On 08/25/2009 05:22 AM, Anthony Liguori wrote:
I think 2.6.32 is pushing it.
2.6.32 is pushing it, but we need to push it.
Agreed.
I think some time is needed to flush out the userspace interface. In
particular, I don't think Mark's
On Tuesday 25 August 2009, Michael S. Tsirkin wrote:
I'd like to avoid that here,
though it's kind of ugly. We'd need VHOST_GET_FEATURES (and ACK) to take a
struct like:
u32 feature_size;
u32 features[];
Hmm, variable length ioctl arguments, I'd rather not go there.
The
On Monday 31 August 2009, Xin, Xiaohui wrote:
Hi, Michael
That's a great job. We are now working on support VMDq on KVM, and since the
VMDq hardware presents L2 sorting
based on MAC addresses and VLAN tags, our target is to implement a zero copy
solution using VMDq.
I'm also interested
On Wednesday 16 September 2009, Michael S. Tsirkin wrote:
vhost-net driver projects
I still think that list should include
- UDP multicast socket support
- TCP socket support
- raw packet socket support for qemu (from Or Gerlitz)
if we have those, plus the tap support that is already on
your
On Tuesday 15 September 2009, Michael S. Tsirkin wrote:
Userspace in x86 maps a PCI region, uses it for communication with ppc?
This might have portability issues. On x86 it should work, but if the
host is powerpc or similar, you cannot reliably access PCI I/O memory
through copy_tofrom_user but
On Wednesday 16 September 2009, Michael S. Tsirkin wrote:
On Wed, Sep 16, 2009 at 04:52:40PM +0200, Arnd Bergmann wrote:
On Wednesday 16 September 2009, Michael S. Tsirkin wrote:
vhost-net driver projects
I still think that list should include
Yea, why not. Go wild.
- UDP
On Wednesday 16 September 2009, Michael S. Tsirkin wrote:
On Wed, Sep 16, 2009 at 04:57:42PM +0200, Arnd Bergmann wrote:
On Tuesday 15 September 2009, Michael S. Tsirkin wrote:
Userspace in x86 maps a PCI region, uses it for communication with ppc?
This might have portability issues
On Wednesday 16 September 2009, Michael S. Tsirkin wrote:
No, I think this is less important, because the bridge code
also doesn't do this.
True, but the reason might be that it is much harder in bridge (you have
to snoop multicast registrations). With macvlan you know which
multicasts
On Thursday 17 September 2009, Michael S. Tsirkin wrote:
Well, we could have a char device with an ioctl that gives you back a socket,
or maybe even have it give you back a socket when you open it.
Will that make you happy?
Well, that would put is in the exact same spot as the tun/tap driver
On Tuesday 22 September 2009, Michael S. Tsirkin wrote:
More importantly, when virtualizations is used with multi-queue
NIC's the virtio-net NIC is a single CPU bottleneck. The virtio-net
NIC should preserve the parallelism (lock free) using multiple
receive/transmit queues. The number
On Tuesday 22 September 2009, Stephen Hemminger wrote:
My idea for that was to open multiple file descriptors to the same
macvtap device and let the kernel figure out the right thing to
do with that. You can do the same with raw packed sockets in case
of vhost_net, but I wouldn't want to
On Tuesday 29 September 2009, David Miller wrote:
These header files are indeed shared with the host implementation,
as you've guessed. If it's not a big deal, we would like to keep
the names the same, just for our own sanity's sake?
No. This isn't your source tree, it's everyone's.
On Monday 02 November 2009, Michael S. Tsirkin wrote:
Tun device looks similar to a packet socket
in that both pass complete frames from/to userspace.
This patch fills in enough fields in the socket underlying tun driver
to support sendmsg/recvmsg operations, and message flags
MSG_TRUNC and
On Tuesday 03 November 2009, Michael S. Tsirkin wrote:
What was your reason for changing?
It turns out socket structure is really bound to specific a file, so we
can not have 2 files referencing the same socket. Instead, as I say
above, it's possible to make sendmsg/recvmsg work on tap
On Tuesday 03 November 2009, Arnd Bergmann wrote:
index 3f5fd52..404abe0 100644
--- a/include/linux/if_tun.h
+++ b/include/linux/if_tun.h
@@ -86,4 +86,18 @@ struct tun_filter {
__u8 addr[0][ETH_ALEN];
};
+#ifdef __KERNEL__
+#if defined(CONFIG_TUN) || defined
On Wednesday 18 November 2009, Eric Dumazet wrote:
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -33,12 +33,6 @@
#define MACVLAN_HASH_SIZE(1 BITS_PER_BYTE)
-enum macvlan_type {
- MACVLAN_PRIVATE = 1,
- MACVLAN_VEPA= 2,
-
On Wednesday 18 November 2009, Eric W. Biederman wrote:
Please copy and ideally share code with the veth driver for recycling a skb.
There are bunch of little things you have to do to get it right. As I recally
I was missing a few details in my original patch.
Ok, thanks for the hint!
On Thursday 19 November 2009, Patrick McHardy wrote:
+enum ifla_macvlan_mode {
+ MACVLAN_MODE_PRIVATE = 1, /* don't talk to other macvlans */
+ MACVLAN_MODE_VEPA= 2, /* talk to other ports through ext bridge */
+ MACVLAN_MODE_BRIDGE = 4, /* talk to bridge ports directly */
We have very similar code for rx statistics in
two places in the macvlan driver, with a third
one being added in the next patch.
Consolidate them into one function to improve
overall readability of the driver.
Signed-off-by: Arnd Bergmann a...@arndb.de
---
drivers/net/macvlan.c | 63
does.
Based on an earlier patch macvlan: Reflect macvlan packets
meant for other macvlan devices by Eric Biederman.
Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: Eric Biederman ebied...@xmission.com
---
drivers/net/macvlan.c | 75 +++-
1 files
-off-by: Arnd Bergmann a...@arndb.de
---
drivers/net/veth.c| 17 +++--
include/linux/netdevice.h |2 ++
net/core/dev.c| 36
3 files changed, 41 insertions(+), 14 deletions(-)
diff --git a/drivers/net/veth.c b/drivers/net
In order to support all three modes of macvlan at
runtime, extend the existing netlink protocol
to allow choosing the mode per macvlan slave
interface.
This depends on a matching patch to iproute2
in order to become accessible in user land.
Signed-off-by: Arnd Bergmann a...@arndb.de
---
drivers
.
Arnd
Arnd Bergmann (4):
veth: move loopback logic to common location
macvlan: cleanup rx statistics
macvlan: implement bridge, VEPA and private mode
macvlan: export macvlan mode through netlink
drivers/net/macvlan.c | 183
On Tuesday 24 November 2009 08:15:53 Eric Dumazet wrote:
Arnd Bergmann a écrit :
+static inline void macvlan_count_rx(const struct macvlan_dev *vlan, int
length,
+int success, int multicast)
success and multicast should be declared as bool
ok
namespaces
communicating with each other, so I'd assume that we should always
clear skb-mark and skb-dst in this function. Maybe I should make
the documentation clearer?
---
net: clarify documentation of dev_forward_skb
Signed-off-by: Arnd Bergmann a...@arndb.de
--- a/net/core/dev.c
+++ b/net/core
On Tuesday 24 November 2009 10:17:11 Patrick McHardy wrote:
Arnd Bergmann wrote:
On Tuesday 24 November 2009 09:51:19 Patrick McHardy wrote:
+ skb_dst_drop(skb);
+ skb-tstamp.tv64 = 0;
+ skb-pkt_type = PACKET_HOST;
+ skb-protocol = eth_type_trans(skb, dev);
+ skb
On Tuesday 24 November 2009, Patrick McHardy wrote:
Arnd Bergmann wrote:
@@ -29,9 +29,16 @@
#include linux/if_link.h
#include linux/if_macvlan.h
#include net/rtnetlink.h
+#include net/xfrm.h
Do we really need this?
Not any more. I originally did secpath_reset here
On Tuesday 24 November 2009, Patrick McHardy wrote:
Arnd Bergmann wrote:
@@ -600,6 +594,18 @@ static int macvlan_validate(struct nlattr *tb[],
struct nlattr *data[])
if (!is_valid_ether_addr(nla_data(tb[IFLA_ADDRESS])))
return -EADDRNOTAVAIL
On Tuesday 24 November 2009, Patrick McHardy wrote:
I don't think its necessary, we bypass outgoing queuing anyways.
But if you'd want to add it, just keeping the skb-mark clearing
in veth should work from what I can tell.
Ok, I won't bother with it for now then.
Arnd
On Tuesday 24 November 2009, Eric W. Biederman wrote:
I don't quite follow what you intend with dev_queue_xmit when the macvlan
is in one namespace and the real physical device is in another. Are
you mentioning that the packet classifier runs in the namespace where
the primary device lives
be extremely useful but as others have found out before me
requires significant changes not only to macvlan but also
to the common transmit path.
I've tested VEPA operation with the hairpin support
added to the bridge driver by Anna Fischer.
---
Arnd Bergmann (4):
veth: move loopback logic to common
does.
Based on an earlier patch macvlan: Reflect macvlan packets
meant for other macvlan devices by Eric Biederman.
Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: Eric Biederman ebied...@xmission.com
---
drivers/net/macvlan.c | 80 -
1 files
In order to support all three modes of macvlan at
runtime, extend the existing netlink protocol
to allow choosing the mode per macvlan slave
interface.
This depends on a matching patch to iproute2
in order to become accessible in user land.
Signed-off-by: Arnd Bergmann a...@arndb.de
---
drivers
-off-by: Arnd Bergmann a...@arndb.de
---
drivers/net/veth.c| 17 +++--
include/linux/netdevice.h |2 ++
net/core/dev.c| 40
3 files changed, 45 insertions(+), 14 deletions(-)
diff --git a/drivers/net/veth.c b/drivers/net
We have very similar code for rx statistics in
two places in the macvlan driver, with a third
one being added in the next patch.
Consolidate them into one function to improve
overall readability of the driver.
Signed-off-by: Arnd Bergmann a...@arndb.de
---
drivers/net/macvlan.c | 70
needs testing, don't apply
Signed-off-by: Arnd Bergmann a...@arndb.de
---
drivers/net/macvlan.c |2 +-
include/linux/netdevice.h |9 +
net/8021q/vlan_dev.c |2 +-
net/core/dev.c| 37 +
4 files changed, 44 insertions(+), 6
...@yahoogroups.com
Signed-off-by: Arnd Bergmann a...@arndb.de
---
drivers/net/Kconfig | 12 +
drivers/net/Makefile |1 +
drivers/net/macvtap.c | 561 +
3 files changed, 574 insertions(+), 0 deletions(-)
create mode 100644 drivers/net/macvtap.c
As promised, here is my small writeup on which setups I feel
are important in the long run for server-type guests. This
does not cover -net user, which is really for desktop kinds
of applications where you do not want to connect into the
guest from another IP address.
I can see four separate
On Wednesday 09 December 2009, Anthony Liguori wrote:
While we go over all of these things one thing is becoming clear to me.
We need to get qemu out of the network configuration business. There's
too much going on here.
Agreed.
What I'd like to see is the following interfaces supported:
On Thursday 10 December 2009, Fischer, Anna wrote:
3. Doing the bridging in the NIC using macvlan in passthrough
mode. This lowers the CPU utilization further compared to 2,
at the expense of limiting throughput by the performance of
the PCIe interconnect to the adapter. Whether or not
On Thursday 10 December 2009 19:14:28 Alexander Graf wrote:
This is something I also have been thinking about, but it is not what
I was referring to above. I think it would be good to keep the three
cases (macvlan, VMDq, SR-IOV) as similar as possible from the user
perspective, so using
1 - 100 of 237 matches
Mail list logo
