vhost-net todo list
Subsystems (2)
Michael S. Tsirkin
maintainerSome 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
Signature · 1 line
MST
Quoted 1 line · Michael S. Tsirkin
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.
Quoted 6 lines
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 <><
Quoted 1 line · Michael S. Tsirkin
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.
Quoted 6 lines
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 <><
Michael S. Tsirkin
maintainerQuoted 4 lines · Arnd Bergmann
Quoted 1 line · Michael S. Tsirkin
vhost-net driver projects
I still think that list should include
Yea, why not. Go wild.
Quoted 2 lines
- UDP multicast socket support
- TCP socket support
Switch to UDP unicast while we are at it?
tunneling raw packets over TCP looks wrong.
Quoted 12 lines
- 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.
Quoted 6 lines
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
Quoted 3 lines
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)?
Quoted 2 lines
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?
Quoted 1 line
Arnd <><
Michael S. Tsirkin
maintainerQuoted 4 lines · Arnd Bergmann
Quoted 1 line · Michael S. Tsirkin
vhost-net driver projects
I still think that list should include
Yea, why not. Go wild.
Quoted 2 lines
- UDP multicast socket support
- TCP socket support
Switch to UDP unicast while we are at it?
tunneling raw packets over TCP looks wrong.
Quoted 12 lines
- 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.
Quoted 6 lines
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
Quoted 3 lines
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)?
Quoted 2 lines
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?
Quoted 1 line
Arnd <><
Quoted 6 lines · Michael S. Tsirkin
Quoted 4 lines · Arnd Bergmann
Quoted 1 line · Michael S. Tsirkin
vhost-net driver projects
I still think that list should include
Quoted 7 lines
Yea, why not. Go wild.
Quoted 2 lines
- UDP multicast socket support
- TCP socket supportSwitch 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.
Quoted 6 lines
Quoted 3 lines
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.
Quoted 5 lines
Quoted 2 lines
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 <><
Quoted 6 lines · Michael S. Tsirkin
Quoted 4 lines · Arnd Bergmann
Quoted 1 line · Michael S. Tsirkin
vhost-net driver projects
I still think that list should include
Quoted 7 lines
Yea, why not. Go wild.
Quoted 2 lines
- UDP multicast socket support
- TCP socket supportSwitch 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.
Quoted 6 lines
Quoted 3 lines
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.
Quoted 5 lines
Quoted 2 lines
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 <><
Michael S. Tsirkin
maintainerQuoted 25 lines · Arnd Bergmann
Quoted 6 lines · Michael S. Tsirkin
Quoted 4 lines · Arnd Bergmann
Quoted 1 line · Michael S. Tsirkin
vhost-net driver projects
I still think that list should include
Quoted 7 lines
Yea, why not. Go wild.
Quoted 2 lines
- UDP multicast socket support
- TCP socket supportSwitch 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_netif there is demand for it. The implementation should be trivial based on the existing code paths.Quoted 4 lines
Quoted 3 lines
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.
Quoted 5 lines
Quoted 2 lines
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.
Quoted 6 lines
Quoted 5 lines
Quoted 2 lines
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?
Quoted 6 lines
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.
Quoted 1 line
Arnd <><
Michael S. Tsirkin
maintainerQuoted 25 lines · Arnd Bergmann
Quoted 6 lines · Michael S. Tsirkin
Quoted 4 lines · Arnd Bergmann
Quoted 1 line · Michael S. Tsirkin
vhost-net driver projects
I still think that list should include
Quoted 7 lines
Yea, why not. Go wild.
Quoted 2 lines
- UDP multicast socket support
- TCP socket supportSwitch 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_netif there is demand for it. The implementation should be trivial based on the existing code paths.Quoted 4 lines
Quoted 3 lines
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.
Quoted 5 lines
Quoted 2 lines
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.
Quoted 6 lines
Quoted 5 lines
Quoted 2 lines
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?
Quoted 6 lines
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.
Quoted 1 line
Arnd <><
Quoted 7 lines · Michael S. Tsirkin
Quoted 3 lines
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.
Quoted 8 lines
Quoted 4 lines
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 herCAP_NET_RAWcapability. 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 <><
Quoted 7 lines · Michael S. Tsirkin
Quoted 3 lines
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.
Quoted 8 lines
Quoted 4 lines
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 herCAP_NET_RAWcapability. 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
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
Quoted 3 lines · 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.
Yes.
Quoted 2 lines
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.
Signature · 2 lines
Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux
RE: GDB + KVM Debug
Thanks for the quick reply.
Quoted 3 lines
What versions (
kernel/kvm-kmodand 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:[email protected]]
Sent: Wednesday, September 16, 2009 9:03 AM
To: Saksena, Abhishek
Cc: [email protected]
Subject: Re: GDB + KVM Debug
Quoted 3 lines · 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.
Yes.
Quoted 2 lines
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.
Signature · 2 lines
Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux
Re: GDB + KVM Debug
Quoted 7 lines · Abhishek
Thanks for the quick reply.
Quoted 3 lines
What versions (
kernel/kvm-kmodand 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.
Quoted 2 lines
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
Signature · 2 lines
Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux
Re: GDB + KVM Debug
Quoted 6 lines · Jan Kiszka
Quoted 2 lines
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?
Signature · 2 lines
I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.
Re: GDB + KVM Debug
Quoted 10 lines · Avi Kivity
Quoted 6 lines · Jan Kiszka
Quoted 2 lines
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
Signature · 2 lines
Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux
Re: GDB + KVM Debug
Quoted 11 lines · Jan Kiszka
Quoted 3 lines
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.
Signature · 2 lines
I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.
RE: GDB + KVM Debug
In reply to Jan KiszkaI 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:[email protected]]
Sent: Wednesday, September 16, 2009 9:37 AM
To: Saksena, Abhishek
Cc: [email protected]
Subject: Re: GDB + KVM Debug
Quoted 7 lines · Abhishek
Thanks for the quick reply.
Quoted 3 lines
What versions (
kernel/kvm-kmodand 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.
Quoted 2 lines
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
Signature · 2 lines
Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux
Re: GDB + KVM Debug
Quoted 12 lines · 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: 0000000000000000000000000000000000000000000000002306000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000f0ff0000000000000230020000f00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007f0300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Quoted 2 lines
(gdb)
Try 'set arch <target-architecture>' before connecting. This is required if you didn't load the corresponding target image into gdb.
Jan
Signature · 2 lines
Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux
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:[email protected]]
Sent: Thursday, September 17, 2009 1:36 AM
To: Saksena, Abhishek
Cc: [email protected]
Subject: Re: GDB + KVM Debug
Quoted 12 lines · 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: 0000000000000000000000000000000000000000000000002306000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000f0ff0000000000000230020000f00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007f0300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Quoted 2 lines
(gdb)
Try 'set arch <target-architecture>' before connecting. This is required if you didn't load the corresponding target image into gdb.
Jan
Signature · 2 lines
Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux
Re: GDB + KVM Debug
Quoted 8 lines · Abhishek
I have now tried using both
Set arch i8086 and
Set arch i386:x86-64:intelBut 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
Quoted 7 lines
-----Original Message-----
From: Jan Kiszka [mailto:[email protected]]
Sent: Thursday, September 17, 2009 1:36 AM
To: Saksena, Abhishek
Cc: [email protected]
Subject: Re: GDB + KVM Debug
Quoted 13 lines
Quoted 12 lines · 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: 0000000000000000000000000000000000000000000000002306000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000f0ff0000000000000230020000f00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007f030000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0
Quoted 9 lines
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Quoted 2 lines
(gdb)
Try 'set arch <target-architecture>' before connecting. This is required if you didn't load the corresponding target image into gdb.
Jan
Signature · 2 lines
Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux
GDB Debugging
In reply to Jan KiszkaHi 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: [email protected]
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:[email protected]]
Sent: Thursday, September 17, 2009 1:36 AM
To: Saksena, Abhishek
Cc: [email protected]
Subject: Re: GDB + KVM Debug
Quoted 12 lines · 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: 0000000000000000000000000000000000000000000000002306000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000f0ff0000000000000230020000f00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007f0300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Quoted 2 lines
(gdb)
Try 'set arch <target-architecture>' before connecting. This is required if you didn't load the corresponding target image into gdb.
Jan
Signature · 2 lines
Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux
Re: GDB Debugging
Quoted 17 lines · 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: [email protected]
Subject: GDB + KVM Debug
Quoted 5 lines
I have now tried using both
Set arch i8086 and
Set arch i386:x86-64:intel
Try 'set architecture i386:x86-64'.
Quoted 6 lines
But still see the same issue. Do I need to apply any patch?
Abhishek
Quoted 20 lines
-----Original Message-----
From: Jan Kiszka [mailto:[email protected]]
Sent: Thursday, September 17, 2009 1:36 AM
To: Saksena, Abhishek
Cc: [email protected]
Subject: Re: GDB + KVM DebugQuoted 12 lines · 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: 0000000000000000000000000000000000000000000000002306000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000f0ff0000000000000230020000f00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007f03000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Quoted 16 lines
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Quoted 2 lines
(gdb)
Try 'set arch <target-architecture>' before connecting. This is required if you didn't load the corresponding target image into gdb.
Jan
Signature · 6 lines
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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Michael S. Tsirkin
maintainerQuoted 16 lines · Arnd Bergmann
Quoted 7 lines · Michael S. Tsirkin
Quoted 3 lines
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.
Quoted 5 lines
Quoted 4 lines
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.
Quoted 7 lines
Quoted 3 lines
I don't see a huge difference here.
If you are happy with the user being able to bypass filters in host, just give herCAP_NET_RAWcapability. 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.
Quoted 4 lines
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? :)
Quoted 3 lines
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.
Quoted 1 line
Arnd <><
Michael S. Tsirkin
maintainerQuoted 16 lines · Arnd Bergmann
Quoted 7 lines · Michael S. Tsirkin
Quoted 3 lines
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.
Quoted 5 lines
Quoted 4 lines
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.
Quoted 7 lines
Quoted 3 lines
I don't see a huge difference here.
If you are happy with the user being able to bypass filters in host, just give herCAP_NET_RAWcapability. 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.
Quoted 4 lines
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? :)
Quoted 3 lines
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.
Quoted 1 line
Arnd <><
Quoted 7 lines · Michael S. Tsirkin
Quoted 4 lines
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 <><
Quoted 7 lines · Michael S. Tsirkin
Quoted 4 lines
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 <><
Michael S. Tsirkin
maintainerQuoted 10 lines · Arnd Bergmann
Quoted 7 lines · Michael S. Tsirkin
Quoted 4 lines
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.
Quoted 4 lines
but if you think it can be done, it would be good to have it on the list somewhere.
Arnd <><
Michael S. Tsirkin
maintainerQuoted 10 lines · Arnd Bergmann
Quoted 7 lines · Michael S. Tsirkin
Quoted 4 lines
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.
Quoted 4 lines
but if you think it can be done, it would be good to have it on the list somewhere.
Arnd <><
Quoted 10 lines · Michael S. Tsirkin
Quoted 9 lines · Arnd Bergmann
Quoted 7 lines · Michael S. Tsirkin
Quoted 4 lines
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? :)
Quoted 6 lines
Quoted 1 line
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 <><
Quoted 10 lines · Michael S. Tsirkin
Quoted 9 lines · Arnd Bergmann
Quoted 7 lines · Michael S. Tsirkin
Quoted 4 lines
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? :)
Quoted 6 lines
Quoted 1 line
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 <><
Michael S. Tsirkin
maintainerQuoted 18 lines · Arnd Bergmann
Quoted 10 lines · Michael S. Tsirkin
Quoted 9 lines · Arnd Bergmann
Quoted 7 lines · Michael S. Tsirkin
Quoted 4 lines
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? :)
Quoted 6 lines
Quoted 1 line
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.
Quoted 7 lines
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?
Signature · 1 line
MST
Michael S. Tsirkin
maintainerQuoted 18 lines · Arnd Bergmann
Quoted 10 lines · Michael S. Tsirkin
Quoted 9 lines · Arnd Bergmann
Quoted 7 lines · Michael S. Tsirkin
Quoted 4 lines
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? :)
Quoted 6 lines
Quoted 1 line
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.
Quoted 7 lines
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?
Signature · 1 line
MST
Quoted 3 lines · Michael S. Tsirkin
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 <><
Quoted 3 lines · Michael S. Tsirkin
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 <><
Quoted 4 lines · Arnd Bergmann
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.
Signature · 2 lines
I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.
Quoted 4 lines · Arnd Bergmann
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.
Signature · 2 lines
I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.
Michael S. Tsirkin
maintainerQuoted 4 lines · Arnd Bergmann
Quoted 1 line · Michael S. Tsirkin
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 :)
Quoted 2 lines
- UDP multicast socket support
- TCP socket support
Switch to UDP unicast while we are at it?
tunneling raw packets over TCP looks wrong.
Quoted 12 lines
- 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.
Quoted 6 lines
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
Quoted 3 lines
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)?
Quoted 2 lines
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?
Quoted 1 line
Arnd <><
Michael S. Tsirkin
maintainerQuoted 4 lines · Arnd Bergmann
Quoted 1 line · Michael S. Tsirkin
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 :)
Quoted 2 lines
- UDP multicast socket support
- TCP socket support
Switch to UDP unicast while we are at it?
tunneling raw packets over TCP looks wrong.
Quoted 12 lines
- 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.
Quoted 6 lines
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
Quoted 3 lines
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)?
Quoted 2 lines
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?
Quoted 1 line
Arnd <><