On (Fri) Aug 07 2009 [09:14:43], Anthony Liguori wrote:
> Amit Shah wrote:
>> On (Thu) Aug 06 2009 [18:37:40], Jamie Lokier wrote:
>>
>>> Apart from dbus, hard-coded meanings of small N in /dev/vmchN are
>>> asking for trouble. It is bound to break when widely deployed and
>>>
>>
>> It's n
On 08/10/09 08:55, Amit Shah wrote:
>> Bad example. Quite a lot of modern devices drivers are using dynamic
>> major/minor numbers because they have proven to be such a pain in the
>> butt. That's why we have more sophisticated mechanisms like udev for
>> userspace to make use of.
>
> Let me expl
Gerd Hoffmann wrote:
>
>> There are some other problems with usb too: It's not transparent to
>> users. Any hotplug event could alert users and that's not desired. It's
>> a system-only thing and should also remain that way.
>
> I think virtio-serial is the better way to handle vmchannel. Unlike
> 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 another.
>
> There are patches to do that. I think
On 08/10/09 15:02, Anthony Liguori wrote:
> I think you're missing my fundamental point. Don't use the kernel as the
> guest interface.
>
> Introduce a userspace daemon that exposes a domain socket. Then we can
> have a proper protocol that uses reverse fqdns for identification.
We need nothing b
Gerd Hoffmann wrote:
> On 08/10/09 15:02, Anthony Liguori wrote:
>
>> I think you're missing my fundamental point. Don't use the kernel as the
>> guest interface.
>>
>> Introduce a userspace daemon that exposes a domain socket. Then we can
>> have a proper protocol that uses reverse fqdns for ident
Gerd Hoffmann wrote:
> On 08/10/09 15:02, Anthony Liguori wrote:
>
>> I think you're missing my fundamental point. Don't use the kernel as the
>> guest interface.
>>
>> Introduce a userspace daemon that exposes a domain socket. Then we can
>> have a proper protocol that uses reverse fqdns for ident
Amit Shah wrote:
> Let me explain how we came to this numbering: we first had support for
> 'naming' ports and the names were obtained by userspace programs by an
> ioctl. Rusty suggested to use some numbering scheme where some ports
> could exist at predefined locations so that we wouldn't need th
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 w
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 w
On Sun, 09 Aug 2009 14:19:08 +0300
Or Gerlitz wrote:
> Stephen Hemminger wrote:
> > I have a patch that forwards all multicast packets, and another that does
> > proper forwarding. It should have worked that way in original macvlan, the
> > current behavior is really a bug.
> >
> Looking in
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 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 to add macvlan_h
On 08/10/09 16:20, Anthony Liguori wrote:
> Gerd Hoffmann wrote:
>> Do we really want design a daemon and a protocol for such a simple thing?
>
> Yes, because we also need (c) the ability to write cross platform
> software that targets vmchannel.
>
> So having a library interface is going to be ext
On 08/10/09 16:27, Anthony Liguori wrote:
> I think my fundamental argument boils down to two points. 1) we should
> not require new guest drivers unless we absolutely have to
Allow guest drivers is fine though I guess?
> 2) we should
> always do things in userspace unless we absolutely have to
Paul,
I also think that bridge may not be the right place for VEPA, but rather a
simpler sw/hw mux
Although the VEPA support may reside in multiple places (I.e. also in the
bridge)
As Arnd pointed out Or already added an extension to qemu that allow direct
guest virtual NIC mapping to an inte
> Subject: Re: [PATCH][RFC] net/bridge: add basic VEPA support
>
> 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 eth
"Fischer, Anna" writes:
> If you do have a SRIOV NIC that supports VEPA, then I would think that
> you do not have QEMU or macvtap in the setup any more though. Simply
> because in that case the VM can directly access the VF on the physical
> device. That would be ideal.
I'm just trying to under
>
> After reading more about this, I am not convinced this should be part
> of the bridge code. The bridge code really consists of two parts:
> forwarding table and optional spanning tree. Well the VEPA code short
> circuits both of these; it can't imagine it working with STP turned
> on. The o
Arnd,
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.
Paul
That way you should be able to do something
like:
Host A Host B
/- nalvcam0 -\ /- macvlan0 - 192.168.1.1
Yaron,
The interface multiplexing can be achieved using macvlan driver or using an
SR-IOV capable NIC (the preferred option), macvlan may need to be extended to
support VEPA multicast handling, this looks like a rather simple task
Agreed that the hardware solution is preferred so the macvlan
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
> Subject: Re: [evb] RE: [PATCH][RFC] net/bridge: add basic VEPA support
>
> On Monday 10 August 2009, Stephen Hemminger wrote:
> > On Sun, 09 Aug 2009 14:19:08 +0300, Or Gerlitz
> wrote:
> > > Looking in macvlan_set_multicast_list() it acts in a similar manner
> to
> > > macvlan_set_mac_address(
On Mon, 10 Aug 2009 16:32:01 +
"Fischer, Anna" wrote:
> > Subject: Re: [evb] RE: [PATCH][RFC] net/bridge: add basic VEPA support
> >
> > On Monday 10 August 2009, Stephen Hemminger wrote:
> > > On Sun, 09 Aug 2009 14:19:08 +0300, Or Gerlitz
> > wrote:
> > > > Looking in macvlan_set_multicas
Gerd Hoffmann wrote:
> Ok, lets rip out the in-kernel ioapic code then. It can (and has
> been) done in userspace.
The justification is performance although that's not really true anymore
post TPR optimization.
But FWIW, I opposed both the in-kernel apic and the in-kernel pit when
they were i
Anthony Liguori wrote:
>
> There is nothing sane about vmchannel. It's just an attempt to bypass
> QEMU which is going to introduce all sorts of complexities wrt
> migration, guest compatibility, etc.
>
> However, as I've mentioned repeatedly, the reason I won't merge
> virtio-serial is that it
This implements vhost: a kernel-level backend for virtio,
The main motivation for this work is to reduce virtualization
overhead for virtio by removing system calls on data path,
without guest changes. For virtio-net, this removes up to
4 system calls per packet: vm exit for kick, reentry for kick,
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.
There's similarity with vringfd, with some differences and reduced scope
- uses eventfd for signallin
vhost net module wants to do copy to/from user from a kernel thread,
which needs switch_mm (like what fs/aio has).
export cpu_tlbstate to make this possible
Signed-off-by: Michael S. Tsirkin
---
arch/x86/mm/tlb.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/x86/m
This adds support for vhost-net virtio kernel backend.
This is RFC, but works without issues for me.
Still needs to be split up, tested and benchmarked properly,
but posting it here in case people want to test drive
the kernel bits I posted.
Michael S. Tsirkin (3):
qemu-kvm: move virtio-pci.o
On Monday 10 August 2009, Stephen Hemminger wrote:
> On Mon, 10 Aug 2009 16:32:01, "Fischer, Anna" 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 macvlan/macvtap in
virtio-pci depends, and will always depend, on pci.c
so it makes sense to keep it in the same makefile,
(unlike the rest of virtio files which should eventually
be moved out to Makefile.hw).
Signed-off-by: Michael S. Tsirkin
---
Makefile.hw |2 +-
Makefile.target |2 +-
2 files chan
devices should have the final say over which virtio features they
support. E.g. indirect entries may or may not make sense in the context
of virtio-console. Move the common bits from virtio-pci to an inline
function and let each device call it.
No functional changes.
Signed-off-by: Michael S. Ts
This adds support for vhost-net virtio kernel backend.
To enable (assuming device eth2):
1. enable promisc mode or program guest mac in device eth2
2. disable tso, gso, lro on the card
3. add vhost=eth0 to -net flag
4. run with CAP_NET_ADMIN priviledge (e.g. root)
This patch is RFC, but works with
devices should have the final say over which virtio features they
support. E.g. indirect entries may or may not make sense in the context
of virtio-console. Move the common bits from virtio-pci to an inline
function and let each device call it.
No functional changes.
Signed-off-by: Michael S. Ts
Michael S. Tsirkin wrote:
> devices should have the final say over which virtio features they
> support. E.g. indirect entries may or may not make sense in the context
> of virtio-console. Move the common bits from virtio-pci to an inline
> function and let each device call it.
>
What drove th
On Mon, Aug 10, 2009 at 02:37:20PM -0500, Anthony Liguori wrote:
> Michael S. Tsirkin wrote:
>> devices should have the final say over which virtio features they
>> support. E.g. indirect entries may or may not make sense in the context
>> of virtio-console. Move the common bits from virtio-pci to
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 Mon, Aug 10, 2009 at 09:51:18PM +0200, Arnd Bergmann wrote:
> 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 g
Michael S. Tsirkin wrote:
>> Normally, the common features are transport features and the devices
>> should have absolutely no knowledge of transport feature (since they're
>> transport dependent).
>>
>
> Good point. But
>
> 1. note that with my patch they don't. They call
> virtio_get_com
Michael S. Tsirkin wrote:
> This adds support for vhost-net virtio kernel backend.
>
> This is RFC, but works without issues for me.
>
> Still needs to be split up, tested and benchmarked properly,
> but posting it here in case people want to test drive
> the kernel bits I posted.
>
Any rough i
On 08/10/2009 11:53 AM, Michael S. Tsirkin wrote:
> vhost net module wants to do copy to/from user from a kernel thread,
> which needs switch_mm (like what fs/aio has).
> export cpu_tlbstate to make this possible
>
> Signed-off-by: Michael S. Tsirkin
> ---
> arch/x86/mm/tlb.c |1 +
> 1 files
On Mon, Aug 10, 2009 at 02:56:46PM -0700, H. Peter Anvin wrote:
> On 08/10/2009 11:53 AM, Michael S. Tsirkin wrote:
> > vhost net module wants to do copy to/from user from a kernel thread,
> > which needs switch_mm (like what fs/aio has).
> > export cpu_tlbstate to make this possible
> >
> > Signe
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 an
On Mon, Aug 10, 2009 at 03:33:59PM -0500, Anthony Liguori wrote:
> Michael S. Tsirkin wrote:
>>> Normally, the common features are transport features and the devices
>>> should have absolutely no knowledge of transport feature (since
>>> they're transport dependent).
>>>
>>
>> Good point.
On 08/10/2009 03:06 PM, Michael S. Tsirkin wrote:
>> Wouldn't it be a *lot* better to move use_mm() from fs/aio.c into common
>> code, and export that instead?
>
> That's easy too. What would a good place for it be?
Somewhere in mm/, presumably. When in doubt, make it a new file...
Michael S. Tsirkin wrote:
> On Mon, Aug 10, 2009 at 03:33:59PM -0500, Anthony Liguori wrote:
>
>> There ought to be a way to layer qdev properties that achieves this goal
>> so that when you create a virtio-pci-block device, you have the ability
>> to turn off indirect sg without virtio-bloc
On Mon, 10 Aug 2009 07:17:54 pm Gerd Hoffmann wrote:
> On 08/10/09 08:55, Amit Shah wrote:
> >> Bad example. Quite a lot of modern devices drivers are using dynamic
> >> major/minor numbers because they have proven to be such a pain in the
> >> butt. That's why we have more sophisticated mechanis
Rusty Russell wrote:
> On Mon, 10 Aug 2009 07:17:54 pm Gerd Hoffmann wrote:
>
>> On 08/10/09 08:55, Amit Shah wrote:
>>
Bad example. Quite a lot of modern devices drivers are using dynamic
major/minor numbers because they have proven to be such a pain in the
butt. That's wh
49 matches
Mail list logo
