Re: [PATCH] macvlan: Introduce 'passthru' mode to takeover the underlying device

2010-11-22 Thread David Miller
From: Sridhar Samudrala s...@us.ibm.com
Date: Thu, 28 Oct 2010 16:10:50 -0700

 With the current default 'vepa' mode, a KVM guest using virtio with 
 macvtap backend has the following limitations.
 - cannot change/add a mac address on the guest virtio-net
 - cannot create a vlan device on the guest virtio-net
 - cannot enable promiscuous mode on guest virtio-net
 
 To address these limitations, this patch introduces a new mode called
 'passthru' when creating a macvlan device which allows takeover of the
 underlying device and passing it to a guest using virtio with macvtap
 backend.
 
 Only one macvlan device is allowed in passthru mode and it inherits
 the mac address from the underlying device and sets it in promiscuous 
 mode to receive and forward all the packets.
 
 Signed-off-by: Sridhar Samudrala s...@us.ibm.com

Applied, thanks Sridhar.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] macvlan: Introduce 'passthru' mode to takeover the underlying device

2010-10-31 Thread Sridhar Samudrala

On 10/29/2010 6:45 AM, Arnd Bergmann wrote:

On Friday 29 October 2010, Sridhar Samudrala wrote:

With the current default 'vepa' mode, a KVM guest using virtio with
macvtap backend has the following limitations.
- cannot change/add a mac address on the guest virtio-net

I believe this could be changed if there is a neeed, but I actually
consider it one of the design points of macvlan that the guest
is not able to change the mac address. With 802.1Qbg you rely on
the switch being able to identify the guest by its MAC address,
which the host kernel must ensure.

Currently the host cannot prevent a guest user from trying to change/add 
a mac address
on the guest virtio-net. From guest point of view, the request succeeds, 
but the incoming packets

are dropped siliently by the host interface.


- cannot create a vlan device on the guest virtio-net

Why not? If this doesn't work, it's probably a bug!
Because the host is not aware of the guest vlan tag and the host 
external interface will filter out

incoming vlan tagged packets.


Why does the passthru mode enable it if it doesn't work
already?

passthru mode puts the host external interface in promiscuous mode which 
allows vlan tagged

packets to be received.

Even in tap/bridge mode, this works because adding an external interface 
to the bridge causes it to be

put in promiscuous mode.

Thanks
Sridhar

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] macvlan: Introduce 'passthru' mode to takeover the underlying device

2010-10-30 Thread Michael S. Tsirkin
On Fri, Oct 29, 2010 at 03:45:17PM +0200, Arnd Bergmann wrote:
 On Friday 29 October 2010, Sridhar Samudrala wrote:
  With the current default 'vepa' mode, a KVM guest using virtio with 
  macvtap backend has the following limitations.
  - cannot change/add a mac address on the guest virtio-net
 
 I believe this could be changed if there is a neeed, but I actually
 consider it one of the design points of macvlan that the guest
 is not able to change the mac address. With 802.1Qbg you rely on
 the switch being able to identify the guest by its MAC address,
 which the host kernel must ensure.
 
  - cannot create a vlan device on the guest virtio-net
 
 Why not? If this doesn't work, it's probably a bug!
 Why does the passthru mode enable it if it doesn't work
 already?
 
  - cannot enable promiscuous mode on guest virtio-net
 
 Could you elaborate why such a setup would be useful?
 
   Arnd

E.g. to support bridging in the guest.

-- 
MST
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] macvlan: Introduce 'passthru' mode to takeover the underlying device

2010-10-30 Thread Michael S. Tsirkin
On Fri, Oct 29, 2010 at 03:45:17PM +0200, Arnd Bergmann wrote:
 On Friday 29 October 2010, Sridhar Samudrala wrote:
  With the current default 'vepa' mode, a KVM guest using virtio with 
  macvtap backend has the following limitations.
  - cannot change/add a mac address on the guest virtio-net
 
 I believe this could be changed if there is a neeed, but I actually
 consider it one of the design points of macvlan that the guest
 is not able to change the mac address.

It's a policy question that we should not set at the kernel level.

 With 802.1Qbg you rely on
 the switch being able to identify the guest by its MAC address,
 which the host kernel must ensure.

This is required to be able to get feature parity with
both tun and device assignment. At the moment, changing
the mac when using macvtap silently breaks guest networking.

-- 
MST
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] macvlan: Introduce 'passthru' mode to takeover the underlying device

2010-10-29 Thread Arnd Bergmann
On Friday 29 October 2010, Sridhar Samudrala wrote:
 With the current default 'vepa' mode, a KVM guest using virtio with 
 macvtap backend has the following limitations.
 - cannot change/add a mac address on the guest virtio-net

I believe this could be changed if there is a neeed, but I actually
consider it one of the design points of macvlan that the guest
is not able to change the mac address. With 802.1Qbg you rely on
the switch being able to identify the guest by its MAC address,
which the host kernel must ensure.

 - cannot create a vlan device on the guest virtio-net

Why not? If this doesn't work, it's probably a bug!
Why does the passthru mode enable it if it doesn't work
already?

 - cannot enable promiscuous mode on guest virtio-net

Could you elaborate why such a setup would be useful?

Arnd

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html