vhost-net todo list

vhost-net todo list

[Michael S. Tsirkin]

Some people asked about getting involved with vhost.

Here's a short list of projects.

vhost-net driver projects
- profiling would be very helpful, I have not done any yet
- tap support - working on it now
- merged buffers - working on it now
- scalability/fairness for large # of guests - working on it now
- logging support with dirty page tracking in kernel - working on it now
- indirect buffers - worth it?
- vm exit mitigation for TX (worth it?
  naive implementation does not seem to help)
- interrupt mitigation for RX
- level triggered interrupts - what's the best thing
  to do here?

qemu projects
- migration support
- level triggered interrupts - what's the best thing
  to do here?
- upstream support for injecting interrupts from kernel,
  from qemu-kvm.git to qemu.git
  (this is a vhost dependency, without it vhost
   can't be upstreamed, or it can, but without real benefit)
- general cleanup and upstreaming

projects involing networking stack
- export socket from tap so vhost can use it - working on it now
- extend raw sockets to support GSO/checksum offloading,
  and teach vhost to use that capability
  [one way to do this: virtio net header support]
  will allow working with e.g. macvlan

long term projects
- multiqueue (involves all of vhost, qemu, virtio,
  networking stack)

- More testing is always good

-- 
MST

Re: vhost-net todo list

[Arnd Bergmann]

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 list, we can use vhost-net as a generic offload
for the host networking in qemu.

> projects involing networking stack
> - export socket from tap so vhost can use it - working on it now
> - extend raw sockets to support GSO/checksum offloading,
>   and teach vhost to use that capability
>   [one way to do this: virtio net header support]
>   will allow working with e.g. macvlan

One thing I'm planning to work on is bridge support in macvlan,
together with VEPA compliant operation, i.e. not sending back
multicast frames to the origin.

I'll also keep looking into macvtap, though that will be less
important once you get the tap socket support running.

	Arnd <><

Re: vhost-net todo list

[Michael S. Tsirkin]

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 multicast socket support
> - TCP socket support

Switch to UDP unicast while we are at it?
tunneling raw packets over TCP looks wrong.

> - raw packet socket support for qemu (from Or Gerlitz)
> if we have those, plus the tap support that is already on
> your list, we can use vhost-net as a generic offload
> for the host networking in qemu.
> 
> > projects involing networking stack
> > - export socket from tap so vhost can use it - working on it now
> > - extend raw sockets to support GSO/checksum offloading,
> >   and teach vhost to use that capability
> >   [one way to do this: virtio net header support]
> >   will allow working with e.g. macvlan
> 
> One thing I'm planning to work on is bridge support in macvlan,
> together with VEPA compliant operation, i.e. not sending back
> multicast frames to the origin.

is multicast filtering already there (i.e. only getting
frames for groups you want)?

> I'll also keep looking into macvtap, though that will be less
> important once you get the tap socket support running.

Not sure I see the connection. to get an equivalent to macvtap,
what you need is tso etc support in packet sockets. No?

> 	Arnd <><

Re: vhost-net todo list

[Michael S. Tsirkin]

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 multicast socket support
> - TCP socket support

Switch to UDP unicast while we are at it?
tunneling raw packets over TCP looks wrong.

> - raw packet socket support for qemu (from Or Gerlitz)
> if we have those, plus the tap support that is already on
> your list, we can use vhost-net as a generic offload
> for the host networking in qemu.
> 
> > projects involing networking stack
> > - export socket from tap so vhost can use it - working on it now
> > - extend raw sockets to support GSO/checksum offloading,
> >   and teach vhost to use that capability
> >   [one way to do this: virtio net header support]
> >   will allow working with e.g. macvlan
> 
> One thing I'm planning to work on is bridge support in macvlan,
> together with VEPA compliant operation, i.e. not sending back
> multicast frames to the origin.

is multicast filtering already there (i.e. only getting
frames for groups you want)?

> I'll also keep looking into macvtap, though that will be less
> important once you get the tap socket support running.

Not sure I see the connection. to get an equivalent to macvtap,
what you need is tso etc support in packet sockets. No?

> 	Arnd <><

Re: vhost-net todo list

[Arnd Bergmann]

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 multicast socket support
> > - TCP socket support
> 
> Switch to UDP unicast while we are at it?
> tunneling raw packets over TCP looks wrong.

Well, TCP is what qemu supports right now, that's why
I added it to the list. We could add UDP unicast as
yet another protocol in both qemu and vhost_net if there
is demand for it. The implementation should be trivial
based on the existing code paths.

> > One thing I'm planning to work on is bridge support in macvlan,
> > together with VEPA compliant operation, i.e. not sending back
> > multicast frames to the origin.
> 
> is multicast filtering already there (i.e. only getting
> frames for groups you want)?

No, I think this is less important, because the bridge code
also doesn't do this.
 
> > I'll also keep looking into macvtap, though that will be less
> > important once you get the tap socket support running.
> 
> Not sure I see the connection. to get an equivalent to macvtap,
> what you need is tso etc support in packet sockets. No?

I'm not worried about tso support here.

One of the problems that raw packet sockets have is the requirement
for root permissions (e.g. through libvirt). Tap sockets and
macvtap both don't have this limitation, so you can use them as
a regular user without libvirt.

	Arnd <><

Re: vhost-net todo list

[Michael S. Tsirkin]

On Wed, Sep 16, 2009 at 05:08:46PM +0200, Arnd Bergmann wrote:
> 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 multicast socket support
> > > - TCP socket support
> > 
> > Switch to UDP unicast while we are at it?
> > tunneling raw packets over TCP looks wrong.
> 
> Well, TCP is what qemu supports right now, that's why
> I added it to the list. We could add UDP unicast as
> yet another protocol in both qemu and vhost_net if there
> is demand for it. The implementation should be trivial
> based on the existing code paths.
> 
> > > One thing I'm planning to work on is bridge support in macvlan,
> > > together with VEPA compliant operation, i.e. not sending back
> > > multicast frames to the origin.
> > 
> > is multicast filtering already there (i.e. only getting
> > frames for groups you want)?
> 
> 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 does each device want.

> > > I'll also keep looking into macvtap, though that will be less
> > > important once you get the tap socket support running.
> > 
> > Not sure I see the connection. to get an equivalent to macvtap,
> > what you need is tso etc support in packet sockets. No?
> 
> I'm not worried about tso support here.
> 
> One of the problems that raw packet sockets have is the requirement
> for root permissions (e.g. through libvirt). Tap sockets and
> macvtap both don't have this limitation, so you can use them as
> a regular user without libvirt.

I don't see a huge difference here.
If you are happy with the user being able to bypass filters in host,
just give her CAP_NET_RAW capability.  It does not have to be root.

> 	Arnd <><

Re: vhost-net todo list

[Michael S. Tsirkin]

On Wed, Sep 16, 2009 at 05:08:46PM +0200, Arnd Bergmann wrote:
> 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 multicast socket support
> > > - TCP socket support
> > 
> > Switch to UDP unicast while we are at it?
> > tunneling raw packets over TCP looks wrong.
> 
> Well, TCP is what qemu supports right now, that's why
> I added it to the list. We could add UDP unicast as
> yet another protocol in both qemu and vhost_net if there
> is demand for it. The implementation should be trivial
> based on the existing code paths.
> 
> > > One thing I'm planning to work on is bridge support in macvlan,
> > > together with VEPA compliant operation, i.e. not sending back
> > > multicast frames to the origin.
> > 
> > is multicast filtering already there (i.e. only getting
> > frames for groups you want)?
> 
> 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 does each device want.

> > > I'll also keep looking into macvtap, though that will be less
> > > important once you get the tap socket support running.
> > 
> > Not sure I see the connection. to get an equivalent to macvtap,
> > what you need is tso etc support in packet sockets. No?
> 
> I'm not worried about tso support here.
> 
> One of the problems that raw packet sockets have is the requirement
> for root permissions (e.g. through libvirt). Tap sockets and
> macvtap both don't have this limitation, so you can use them as
> a regular user without libvirt.

I don't see a huge difference here.
If you are happy with the user being able to bypass filters in host,
just give her CAP_NET_RAW capability.  It does not have to be root.

> 	Arnd <><

Re: vhost-net todo list

[Arnd Bergmann]

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 does each device want.

Right. It shouldn't be hard to do, and I'll probably get to
that after the other changes.

> > One of the problems that raw packet sockets have is the requirement
> > for root permissions (e.g. through libvirt). Tap sockets and
> > macvtap both don't have this limitation, so you can use them as
> > a regular user without libvirt.
> 
> I don't see a huge difference here.
> If you are happy with the user being able to bypass filters in host,
> just give her CAP_NET_RAW capability.  It does not have to be root.

Capabilities are nice in theory, but I've never seen them being used
effectively in practice, where it essentially comes down to some
SUID wrapper. Also, I might not want to allow the user to open a
random random raw socket, but only one on a specific downstream
port of a macvlan interface, so I can filter out the data from
that respective MAC address in an external switch.

That scenario is probably not so relevant for KVM, unless you
consider the guest taking over the qemu host process a valid
security threat.

	Arnd <><

GDB + KVM Debug

[Saksena, Abhishek]

Hi All,

I see Qemu support GDB server that allows debugging kernels, boot loaders and others. Is this kind of support is available when KVM is enabled. 

For some reason the single stepping of instructions doesn't seem to work when KVM is in use. So what debug capabilities (for Guest SW) KVM support at this point in time?


-Thanks
Abhishek

Re: GDB + KVM Debug

[Jan Kiszka]

Saksena, Abhishek wrote:
> Hi All,
> 
> I see Qemu support GDB server that allows debugging kernels, boot loaders and others. Is this kind of support is available when KVM is enabled. 

Yes.

> 
> For some reason the single stepping of instructions doesn't seem to work when KVM is in use. So what debug capabilities (for Guest SW) KVM support at this point in time?

Full capabilities.

What versions (kernel/kvm-kmod and qemu-kvm) are you using? What is your
host, what your target architecture/operating mode (real mode, 32 bit
prot. mode, 64 bit mode)?

Jan

PS: Please don't start new threads by replying to unrelated ones.

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

RE: GDB + KVM Debug

[Saksena, Abhishek]

Thanks for the quick reply.

>What versions (kernel/kvm-kmod and qemu-kvm) are you using? What is your
>host, what your target architecture/operating mode (real mode, 32 bit
>prot. mode, 64 bit mode)?

I am using KVM-74? Do I need to upgrade then? 

My target is x86 and we want to debug all real, prot. and 64 bit  mode.


Thanks
Abhishek



-----Original Message-----
From: Jan Kiszka [mailto:jan.kiszka@siemens.com] 
Sent: Wednesday, September 16, 2009 9:03 AM
To: Saksena, Abhishek
Cc: kvm@vger.kernel.org
Subject: Re: GDB + KVM Debug

Saksena, Abhishek wrote:
> Hi All,
> 
> I see Qemu support GDB server that allows debugging kernels, boot loaders and others. Is this kind of support is available when KVM is enabled. 

Yes.

> 
> For some reason the single stepping of instructions doesn't seem to work when KVM is in use. So what debug capabilities (for Guest SW) KVM support at this point in time?

Full capabilities.

What versions (kernel/kvm-kmod and qemu-kvm) are you using? What is your
host, what your target architecture/operating mode (real mode, 32 bit
prot. mode, 64 bit mode)?

Jan

PS: Please don't start new threads by replying to unrelated ones.

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Re: GDB + KVM Debug

[Jan Kiszka]

Saksena, Abhishek wrote:
> Thanks for the quick reply.
> 
>> What versions (kernel/kvm-kmod and qemu-kvm) are you using? What is your
>> host, what your target architecture/operating mode (real mode, 32 bit
>> prot. mode, 64 bit mode)?
> 
> I am using KVM-74? Do I need to upgrade then?

Yes, definitely.

> 
> My target is x86 and we want to debug all real, prot. and 64 bit  mode.

If your host is running 64 bit mode but your target uses less, you need
an extra patch [1] to deal with gdb limitations and a lacking workaround
in qemu(-kvm).

Jan

[1]http://git.kiszka.org/?p=qemu-kvm.git;a=shortlog;h=refs/heads/queues/gdb

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Re: GDB + KVM Debug

[Avi Kivity]

On 09/16/2009 07:37 PM, Jan Kiszka wrote:
>> My target is x86 and we want to debug all real, prot. and 64 bit  mode.
>>      
> If your host is running 64 bit mode but your target uses less, you need
> an extra patch [1] to deal with gdb limitations and a lacking workaround
> in qemu(-kvm).
>    

Can you post this against qemu-kvm, with a switch to disable it in case 
it interferes with a theoretical fixed gdb?

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

Re: GDB + KVM Debug

[Jan Kiszka]

Avi Kivity wrote:
> On 09/16/2009 07:37 PM, Jan Kiszka wrote:
>>> My target is x86 and we want to debug all real, prot. and 64 bit  mode.
>>>      
>> If your host is running 64 bit mode but your target uses less, you need
>> an extra patch [1] to deal with gdb limitations and a lacking workaround
>> in qemu(-kvm).
>>    
> 
> Can you post this against qemu-kvm, with a switch to disable it in case 
> it interferes with a theoretical fixed gdb?

Any fix for gdb will require some work on the qemu side as well to
actually use it (we will have to transfer additional system registers to
tell gdb what mode the target is in). So this kind of interference is
excluded.

However, if desired, I can try to find a smart way of adding a disable
switch to take care of theoretical interferences in today's use cases.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Re: GDB + KVM Debug

[Avi Kivity]

On 09/16/2009 08:56 PM, Jan Kiszka wrote:
>> Can you post this against qemu-kvm, with a switch to disable it in case
>> it interferes with a theoretical fixed gdb?
>>      
> Any fix for gdb will require some work on the qemu side as well to
> actually use it (we will have to transfer additional system registers to
> tell gdb what mode the target is in). So this kind of interference is
> excluded.
>
> However, if desired, I can try to find a smart way of adding a disable
> switch to take care of theoretical interferences in today's use cases.
>    

In that case I think a switch isn't necessary.  I'll leave it to you, 
you certainly have a lot more knowledge than me in this matter.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

RE: GDB + KVM Debug

[Saksena, Abhishek]

I am using KVM-88. However I can't get gdb still working. I stared qemu with -s -S option and when I try to connect gdb to it I get following error:-

(gdb) target remote lochost:1234
lochost: unknown host
lochost:1234: No such file or directory.
(gdb) target remote locahost:1234
locahost: unknown host
locahost:1234: No such file or directory.
(gdb) target remote localhost:1234
Remote debugging using localhost:1234
[New Thread 1]
Remote 'g' packet reply is too long: 0000000000000000000000000000000000000000000000002306000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000f0ff0000000000000230020000f00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007f030000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
(gdb)



Any help will be appreciated!

Thanks
Abhishek


-----Original Message-----
From: Jan Kiszka [mailto:jan.kiszka@siemens.com] 
Sent: Wednesday, September 16, 2009 9:37 AM
To: Saksena, Abhishek
Cc: kvm@vger.kernel.org
Subject: Re: GDB + KVM Debug

Saksena, Abhishek wrote:
> Thanks for the quick reply.
> 
>> What versions (kernel/kvm-kmod and qemu-kvm) are you using? What is your
>> host, what your target architecture/operating mode (real mode, 32 bit
>> prot. mode, 64 bit mode)?
> 
> I am using KVM-74? Do I need to upgrade then?

Yes, definitely.

> 
> My target is x86 and we want to debug all real, prot. and 64 bit  mode.

If your host is running 64 bit mode but your target uses less, you need
an extra patch [1] to deal with gdb limitations and a lacking workaround
in qemu(-kvm).

Jan

[1]http://git.kiszka.org/?p=qemu-kvm.git;a=shortlog;h=refs/heads/queues/gdb

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Re: GDB + KVM Debug

[Jan Kiszka]

Saksena, Abhishek wrote:
> I am using KVM-88. However I can't get gdb still working. I stared qemu with -s -S option and when I try to connect gdb to it I get following error:-
> 
> (gdb) target remote lochost:1234
> lochost: unknown host
> lochost:1234: No such file or directory.
> (gdb) target remote locahost:1234
> locahost: unknown host
> locahost:1234: No such file or directory.
> (gdb) target remote localhost:1234
> Remote debugging using localhost:1234
> [New Thread 1]
> Remote 'g' packet reply is too long: 0000000000000000000000000000000000000000000000002306000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000f0ff0000000000000230020000f00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007f0300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
> (gdb)
> 

Try 'set arch <target-architecture>' before connecting. This is required
if you didn't load the corresponding target image into gdb.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

GDB + KVM Debug

[Saksena, Abhishek]

I have now tried using both


Set arch i8086 and 
Set arch i386:x86-64:intel 

But still see the same issue. Do I need to apply any patch?


Abhishek

-----Original Message-----
From: Jan Kiszka [mailto:jan.kiszka@siemens.com] 
Sent: Thursday, September 17, 2009 1:36 AM
To: Saksena, Abhishek
Cc: kvm@vger.kernel.org
Subject: Re: GDB + KVM Debug

Saksena, Abhishek wrote:
> I am using KVM-88. However I can't get gdb still working. I stared qemu with -s -S option and when I try to connect gdb to it I get following error:-
> 
> (gdb) target remote lochost:1234
> lochost: unknown host
> lochost:1234: No such file or directory.
> (gdb) target remote locahost:1234
> locahost: unknown host
> locahost:1234: No such file or directory.
> (gdb) target remote localhost:1234
> Remote debugging using localhost:1234
> [New Thread 1]
> Remote 'g' packet reply is too long: 0000000000000000000000000000000000000000000000002306000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000f0ff0000000000000230020000f00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007f0300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
> (gdb)
> 

Try 'set arch <target-architecture>' before connecting. This is required
if you didn't load the corresponding target image into gdb.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Re: GDB + KVM Debug

[Jan Kiszka]

Saksena, Abhishek wrote:
> I have now tried using both
> 
> 
> Set arch i8086 and 
> Set arch i386:x86-64:intel 
> 
> But still see the same issue. Do I need to apply any patch?
> 

To have a clean base for further analysis, could you upgrade to
qemu-kvm.git head?

Jan

> -----Original Message-----
> From: Jan Kiszka [mailto:jan.kiszka@siemens.com] 
> Sent: Thursday, September 17, 2009 1:36 AM
> To: Saksena, Abhishek
> Cc: kvm@vger.kernel.org
> Subject: Re: GDB + KVM Debug
> 
> Saksena, Abhishek wrote:
>> I am using KVM-88. However I can't get gdb still working. I stared qemu with -s -S option and when I try to connect gdb to it I get following error:-
>>
>> (gdb) target remote lochost:1234
>> lochost: unknown host
>> lochost:1234: No such file or directory.
>> (gdb) target remote locahost:1234
>> locahost: unknown host
>> locahost:1234: No such file or directory.
>> (gdb) target remote localhost:1234
>> Remote debugging using localhost:1234
>> [New Thread 1]
>> Remote 'g' packet reply is too long: 0000000000000000000000000000000000000000000000002306000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000f0ff0000000000000230020000f00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007f030000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0
> 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
>> (gdb)
>>
> 
> Try 'set arch <target-architecture>' before connecting. This is required
> if you didn't load the corresponding target image into gdb.
> 
> Jan
> 

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

GDB Debugging

[Saksena, Abhishek]

Hi Guys,

Any help will be appreciated on following issue. I have been struggling on this for quite some time...


-Abhishek



-----Original Message-----
From: Saksena, Abhishek 
Sent: Tuesday, October 20, 2009 11:49 AM
To: 'Jan Kiszka'
Cc: kvm@vger.kernel.org
Subject: GDB + KVM Debug

I have now tried using both


Set arch i8086 and 
Set arch i386:x86-64:intel 

But still see the same issue. Do I need to apply any patch?


Abhishek

-----Original Message-----
From: Jan Kiszka [mailto:jan.kiszka@siemens.com] 
Sent: Thursday, September 17, 2009 1:36 AM
To: Saksena, Abhishek
Cc: kvm@vger.kernel.org
Subject: Re: GDB + KVM Debug

Saksena, Abhishek wrote:
> I am using KVM-88. However I can't get gdb still working. I stared qemu with -s -S option and when I try to connect gdb to it I get following error:-
> 
> (gdb) target remote lochost:1234
> lochost: unknown host
> lochost:1234: No such file or directory.
> (gdb) target remote locahost:1234
> locahost: unknown host
> locahost:1234: No such file or directory.
> (gdb) target remote localhost:1234
> Remote debugging using localhost:1234
> [New Thread 1]
> Remote 'g' packet reply is too long: 0000000000000000000000000000000000000000000000002306000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000f0ff0000000000000230020000f00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007f0300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
> (gdb)
> 

Try 'set arch <target-architecture>' before connecting. This is required
if you didn't load the corresponding target image into gdb.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Re: GDB Debugging

[Yolkfull Chow]

On Fri, Oct 23, 2009 at 09:19:40AM -0700, Saksena, Abhishek wrote:
> 
> Hi Guys,
> 
> Any help will be appreciated on following issue. I have been struggling on this for quite some time...
> 
> 
> -Abhishek
> 
> 
> 
> -----Original Message-----
> From: Saksena, Abhishek 
> Sent: Tuesday, October 20, 2009 11:49 AM
> To: 'Jan Kiszka'
> Cc: kvm@vger.kernel.org
> Subject: GDB + KVM Debug
> 
> I have now tried using both
> 
> 
> Set arch i8086 and 
> Set arch i386:x86-64:intel 

Try 'set architecture i386:x86-64'.

> 
> But still see the same issue. Do I need to apply any patch?
> 
> 
> Abhishek
> 
> -----Original Message-----
> From: Jan Kiszka [mailto:jan.kiszka@siemens.com] 
> Sent: Thursday, September 17, 2009 1:36 AM
> To: Saksena, Abhishek
> Cc: kvm@vger.kernel.org
> Subject: Re: GDB + KVM Debug
> 
> Saksena, Abhishek wrote:
> > I am using KVM-88. However I can't get gdb still working. I stared qemu with -s -S option and when I try to connect gdb to it I get following error:-
> > 
> > (gdb) target remote lochost:1234
> > lochost: unknown host
> > lochost:1234: No such file or directory.
> > (gdb) target remote locahost:1234
> > locahost: unknown host
> > locahost:1234: No such file or directory.
> > (gdb) target remote localhost:1234
> > Remote debugging using localhost:1234
> > [New Thread 1]
> > Remote 'g' packet reply is too long: 0000000000000000000000000000000000000000000000002306000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000f0ff0000000000000230020000f00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007f03000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
> 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
> > (gdb)
> > 
> 
> Try 'set arch <target-architecture>' before connecting. This is required
> if you didn't load the corresponding target image into gdb.
> 
> Jan
> 
> -- 
> Siemens AG, Corporate Technology, CT SE 2
> Corporate Competence Center Embedded Linux
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: vhost-net todo list

[Michael S. Tsirkin]

On Wed, Sep 16, 2009 at 05:27:25PM +0200, Arnd Bergmann wrote:
> 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 does each device want.
> 
> Right. It shouldn't be hard to do, and I'll probably get to
> that after the other changes.
> > > One of the problems that raw packet sockets have is the requirement
> > > for root permissions (e.g. through libvirt). Tap sockets and
> > > macvtap both don't have this limitation, so you can use them as
> > > a regular user without libvirt.
> > 
> > I don't see a huge difference here.
> > If you are happy with the user being able to bypass filters in host,
> > just give her CAP_NET_RAW capability.  It does not have to be root.
> 
> Capabilities are nice in theory, but I've never seen them being used
> effectively in practice, where it essentially comes down to some
> SUID wrapper.

Heh, for tap people seem to just give out write access to
it and that's all.  Not really different.

> Also, I might not want to allow the user to open a
> random random raw socket, but only one on a specific downstream
> port of a macvlan interface, so I can filter out the data from
> that respective MAC address in an external switch.

I agree. Maybe we can fix that for raw sockets, want me to
add it to the list? :)

> That scenario is probably not so relevant for KVM, unless you
> consider the guest taking over the qemu host process a valid
> security threat.

Defence in depth is a good thing, anyway.

> 	Arnd <><

Re: vhost-net todo list

[Michael S. Tsirkin]

On Wed, Sep 16, 2009 at 05:27:25PM +0200, Arnd Bergmann wrote:
> 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 does each device want.
> 
> Right. It shouldn't be hard to do, and I'll probably get to
> that after the other changes.
> > > One of the problems that raw packet sockets have is the requirement
> > > for root permissions (e.g. through libvirt). Tap sockets and
> > > macvtap both don't have this limitation, so you can use them as
> > > a regular user without libvirt.
> > 
> > I don't see a huge difference here.
> > If you are happy with the user being able to bypass filters in host,
> > just give her CAP_NET_RAW capability.  It does not have to be root.
> 
> Capabilities are nice in theory, but I've never seen them being used
> effectively in practice, where it essentially comes down to some
> SUID wrapper.

Heh, for tap people seem to just give out write access to
it and that's all.  Not really different.

> Also, I might not want to allow the user to open a
> random random raw socket, but only one on a specific downstream
> port of a macvlan interface, so I can filter out the data from
> that respective MAC address in an external switch.

I agree. Maybe we can fix that for raw sockets, want me to
add it to the list? :)

> That scenario is probably not so relevant for KVM, unless you
> consider the guest taking over the qemu host process a valid
> security threat.

Defence in depth is a good thing, anyway.

> 	Arnd <><

Re: vhost-net todo list

[Arnd Bergmann]

On Wednesday 16 September 2009, Michael S. Tsirkin wrote:
> > Also, I might not want to allow the user to open a
> > random random raw socket, but only one on a specific downstream
> > port of a macvlan interface, so I can filter out the data from
> > that respective MAC address in an external switch.
> 
> I agree. Maybe we can fix that for raw sockets, want me to
> add it to the list? :)

So far, I could not find any theoretical solution how to fix this,
but if you think it can be done, it would be good to have it on the
list somewhere.

	Arnd <><

Re: vhost-net todo list

[Michael S. Tsirkin]

On Thu, Sep 17, 2009 at 01:30:00PM +0200, Arnd Bergmann wrote:
> On Wednesday 16 September 2009, Michael S. Tsirkin wrote:
> > > Also, I might not want to allow the user to open a
> > > random random raw socket, but only one on a specific downstream
> > > port of a macvlan interface, so I can filter out the data from
> > > that respective MAC address in an external switch.
> > 
> > I agree. Maybe we can fix that for raw sockets, want me to
> > add it to the list? :)
> 
> So far, I could not find any theoretical solution how to fix this,

What if socket had a LOCKBIND ioctl after which you can not bind it to
any other device?  Then someone with RAW capability can open the socket,
bind to device and hand it to you. You can send packets but not
switch to another device.


> but if you think it can be done, it would be good to have it on the
> list somewhere.
> 
> 	Arnd <><

Re: vhost-net todo list

[Arnd Bergmann]

On Thursday 17 September 2009, Michael S. Tsirkin wrote:
> On Thu, Sep 17, 2009 at 01:30:00PM +0200, Arnd Bergmann wrote:
> > On Wednesday 16 September 2009, Michael S. Tsirkin wrote:
> > > > Also, I might not want to allow the user to open a
> > > > random random raw socket, but only one on a specific downstream
> > > > port of a macvlan interface, so I can filter out the data from
> > > > that respective MAC address in an external switch.
> > > 
> > > I agree. Maybe we can fix that for raw sockets, want me to
> > > add it to the list? :)
> > 
> > So far, I could not find any theoretical solution how to fix this,
> 
> What if socket had a LOCKBIND ioctl after which you can not bind it to
> any other device?  Then someone with RAW capability can open the socket,
> bind to device and hand it to you. You can send packets but not
> switch to another device.

Could work, though I was hoping for a solution that does not depend
on a priviledged task at run time to open the socket, as you have with
persistant tap devices or chardevs like macvtap that can have their
persissions set by udev.


	Arnd <><

Re: vhost-net todo list

[Arnd Bergmann]

On Thursday 17 September 2009, Michael S. Tsirkin wrote:
> On Thu, Sep 17, 2009 at 01:30:00PM +0200, Arnd Bergmann wrote:
> > On Wednesday 16 September 2009, Michael S. Tsirkin wrote:
> > > > Also, I might not want to allow the user to open a
> > > > random random raw socket, but only one on a specific downstream
> > > > port of a macvlan interface, so I can filter out the data from
> > > > that respective MAC address in an external switch.
> > > 
> > > I agree. Maybe we can fix that for raw sockets, want me to
> > > add it to the list? :)
> > 
> > So far, I could not find any theoretical solution how to fix this,
> 
> What if socket had a LOCKBIND ioctl after which you can not bind it to
> any other device?  Then someone with RAW capability can open the socket,
> bind to device and hand it to you. You can send packets but not
> switch to another device.

Could work, though I was hoping for a solution that does not depend
on a priviledged task at run time to open the socket, as you have with
persistant tap devices or chardevs like macvtap that can have their
persissions set by udev.


	Arnd <><

Re: vhost-net todo list

[Michael S. Tsirkin]

On Thu, Sep 17, 2009 at 02:14:06PM +0200, Arnd Bergmann wrote:
> On Thursday 17 September 2009, Michael S. Tsirkin wrote:
> > On Thu, Sep 17, 2009 at 01:30:00PM +0200, Arnd Bergmann wrote:
> > > On Wednesday 16 September 2009, Michael S. Tsirkin wrote:
> > > > > Also, I might not want to allow the user to open a
> > > > > random random raw socket, but only one on a specific downstream
> > > > > port of a macvlan interface, so I can filter out the data from
> > > > > that respective MAC address in an external switch.
> > > > 
> > > > I agree. Maybe we can fix that for raw sockets, want me to
> > > > add it to the list? :)
> > > 
> > > So far, I could not find any theoretical solution how to fix this,
> > 
> > What if socket had a LOCKBIND ioctl after which you can not bind it to
> > any other device?  Then someone with RAW capability can open the socket,
> > bind to device and hand it to you. You can send packets but not
> > switch to another device.
> 
> Could work, though I was hoping for a solution that does not depend
> on a priviledged task at run time to open the socket, as you have with
> persistant tap devices or chardevs like macvtap that can have their
> persissions set by udev.
> 
> 
> 	Arnd <><

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?

-- 
MST

Re: vhost-net todo list

[Arnd Bergmann]

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 patch
you're working on or my (still unfinished, I need to spend some time on it
again) macvtap driver. As I said, either one addresses the problem but is
unrelated to the raw socket interface.

	Arnd <><

Re: vhost-net todo list

[Arnd Bergmann]

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 patch
you're working on or my (still unfinished, I need to spend some time on it
again) macvtap driver. As I said, either one addresses the problem but is
unrelated to the raw socket interface.

	Arnd <><

Re: vhost-net todo list

[Michael S. Tsirkin]

On Thu, Sep 17, 2009 at 02:14:06PM +0200, Arnd Bergmann wrote:
> On Thursday 17 September 2009, Michael S. Tsirkin wrote:
> > On Thu, Sep 17, 2009 at 01:30:00PM +0200, Arnd Bergmann wrote:
> > > On Wednesday 16 September 2009, Michael S. Tsirkin wrote:
> > > > > Also, I might not want to allow the user to open a
> > > > > random random raw socket, but only one on a specific downstream
> > > > > port of a macvlan interface, so I can filter out the data from
> > > > > that respective MAC address in an external switch.
> > > > 
> > > > I agree. Maybe we can fix that for raw sockets, want me to
> > > > add it to the list? :)
> > > 
> > > So far, I could not find any theoretical solution how to fix this,
> > 
> > What if socket had a LOCKBIND ioctl after which you can not bind it to
> > any other device?  Then someone with RAW capability can open the socket,
> > bind to device and hand it to you. You can send packets but not
> > switch to another device.
> 
> Could work, though I was hoping for a solution that does not depend
> on a priviledged task at run time to open the socket, as you have with
> persistant tap devices or chardevs like macvtap that can have their
> persissions set by udev.
> 
> 
> 	Arnd <><

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?

-- 
MST

Re: vhost-net todo list

[Michael S. Tsirkin]

On Thu, Sep 17, 2009 at 01:30:00PM +0200, Arnd Bergmann wrote:
> On Wednesday 16 September 2009, Michael S. Tsirkin wrote:
> > > Also, I might not want to allow the user to open a
> > > random random raw socket, but only one on a specific downstream
> > > port of a macvlan interface, so I can filter out the data from
> > > that respective MAC address in an external switch.
> > 
> > I agree. Maybe we can fix that for raw sockets, want me to
> > add it to the list? :)
> 
> So far, I could not find any theoretical solution how to fix this,

What if socket had a LOCKBIND ioctl after which you can not bind it to
any other device?  Then someone with RAW capability can open the socket,
bind to device and hand it to you. You can send packets but not
switch to another device.


> but if you think it can be done, it would be good to have it on the
> list somewhere.
> 
> 	Arnd <><

Re: vhost-net todo list

[Arnd Bergmann]

On Wednesday 16 September 2009, Michael S. Tsirkin wrote:
> > Also, I might not want to allow the user to open a
> > random random raw socket, but only one on a specific downstream
> > port of a macvlan interface, so I can filter out the data from
> > that respective MAC address in an external switch.
> 
> I agree. Maybe we can fix that for raw sockets, want me to
> add it to the list? :)

So far, I could not find any theoretical solution how to fix this,
but if you think it can be done, it would be good to have it on the
list somewhere.

	Arnd <><

Re: vhost-net todo list

[Avi Kivity]

On 09/16/2009 06:27 PM, Arnd Bergmann wrote:
> That scenario is probably not so relevant for KVM, unless you
> consider the guest taking over the qemu host process a valid
> security threat.
>    

It is.  We address it by using SCM_RIGHTS for all sensitive operations 
and selinuxing qemu as tightly as possible.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

Re: vhost-net todo list

[Avi Kivity]

On 09/16/2009 06:27 PM, Arnd Bergmann wrote:
> That scenario is probably not so relevant for KVM, unless you
> consider the guest taking over the qemu host process a valid
> security threat.
>    

It is.  We address it by using SCM_RIGHTS for all sensitive operations 
and selinuxing qemu as tightly as possible.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

Re: vhost-net todo list

[Arnd Bergmann]

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 does each device want.

Right. It shouldn't be hard to do, and I'll probably get to
that after the other changes.

> > One of the problems that raw packet sockets have is the requirement
> > for root permissions (e.g. through libvirt). Tap sockets and
> > macvtap both don't have this limitation, so you can use them as
> > a regular user without libvirt.
> 
> I don't see a huge difference here.
> If you are happy with the user being able to bypass filters in host,
> just give her CAP_NET_RAW capability.  It does not have to be root.

Capabilities are nice in theory, but I've never seen them being used
effectively in practice, where it essentially comes down to some
SUID wrapper. Also, I might not want to allow the user to open a
random random raw socket, but only one on a specific downstream
port of a macvlan interface, so I can filter out the data from
that respective MAC address in an external switch.

That scenario is probably not so relevant for KVM, unless you
consider the guest taking over the qemu host process a valid
security threat.

	Arnd <><

Re: vhost-net todo list

[Arnd Bergmann]

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 multicast socket support
> > - TCP socket support
> 
> Switch to UDP unicast while we are at it?
> tunneling raw packets over TCP looks wrong.

Well, TCP is what qemu supports right now, that's why
I added it to the list. We could add UDP unicast as
yet another protocol in both qemu and vhost_net if there
is demand for it. The implementation should be trivial
based on the existing code paths.

> > One thing I'm planning to work on is bridge support in macvlan,
> > together with VEPA compliant operation, i.e. not sending back
> > multicast frames to the origin.
> 
> is multicast filtering already there (i.e. only getting
> frames for groups you want)?

No, I think this is less important, because the bridge code
also doesn't do this.
 
> > I'll also keep looking into macvtap, though that will be less
> > important once you get the tap socket support running.
> 
> Not sure I see the connection. to get an equivalent to macvtap,
> what you need is tso etc support in packet sockets. No?

I'm not worried about tso support here.

One of the problems that raw packet sockets have is the requirement
for root permissions (e.g. through libvirt). Tap sockets and
macvtap both don't have this limitation, so you can use them as
a regular user without libvirt.

	Arnd <><

Re: vhost-net todo list

[Michael S. Tsirkin]

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

Why not. But note that including things in a list will not magically
make them done :)

> - UDP multicast socket support
> - TCP socket support

Switch to UDP unicast while we are at it?
tunneling raw packets over TCP looks wrong.

> - raw packet socket support for qemu (from Or Gerlitz)
> if we have those, plus the tap support that is already on
> your list, we can use vhost-net as a generic offload
> for the host networking in qemu.
> 
> > projects involing networking stack
> > - export socket from tap so vhost can use it - working on it now
> > - extend raw sockets to support GSO/checksum offloading,
> >   and teach vhost to use that capability
> >   [one way to do this: virtio net header support]
> >   will allow working with e.g. macvlan
> 
> One thing I'm planning to work on is bridge support in macvlan,
> together with VEPA compliant operation, i.e. not sending back
> multicast frames to the origin.

is multicast filtering already there (i.e. only getting
frames for groups you want)?

> I'll also keep looking into macvtap, though that will be less
> important once you get the tap socket support running.

Not sure I see the connection. to get an equivalent to macvtap,
what you need is tso etc support in packet sockets. No?

> 	Arnd <><

Re: vhost-net todo list

[Michael S. Tsirkin]

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

Why not. But note that including things in a list will not magically
make them done :)

> - UDP multicast socket support
> - TCP socket support

Switch to UDP unicast while we are at it?
tunneling raw packets over TCP looks wrong.

> - raw packet socket support for qemu (from Or Gerlitz)
> if we have those, plus the tap support that is already on
> your list, we can use vhost-net as a generic offload
> for the host networking in qemu.
> 
> > projects involing networking stack
> > - export socket from tap so vhost can use it - working on it now
> > - extend raw sockets to support GSO/checksum offloading,
> >   and teach vhost to use that capability
> >   [one way to do this: virtio net header support]
> >   will allow working with e.g. macvlan
> 
> One thing I'm planning to work on is bridge support in macvlan,
> together with VEPA compliant operation, i.e. not sending back
> multicast frames to the origin.

is multicast filtering already there (i.e. only getting
frames for groups you want)?

> I'll also keep looking into macvtap, though that will be less
> important once you get the tap socket support running.

Not sure I see the connection. to get an equivalent to macvtap,
what you need is tso etc support in packet sockets. No?

> 	Arnd <><

Re: vhost-net todo list

[Arnd Bergmann]

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 list, we can use vhost-net as a generic offload
for the host networking in qemu.

> projects involing networking stack
> - export socket from tap so vhost can use it - working on it now
> - extend raw sockets to support GSO/checksum offloading,
>   and teach vhost to use that capability
>   [one way to do this: virtio net header support]
>   will allow working with e.g. macvlan

One thing I'm planning to work on is bridge support in macvlan,
together with VEPA compliant operation, i.e. not sending back
multicast frames to the origin.

I'll also keep looking into macvtap, though that will be less
important once you get the tap socket support running.

	Arnd <><