[libvirt] ivshmem server
This mail is meant to get a discussion started. Please keep me on cc for the discussion, as I'm not subscribed to libvir-list. ivshmem is an implementation of an inter-VM communication channel. Support for this has been in qemu since v0.14.0 and libvirt patches have been recently posted[1]. What's still missing is the ivshmem server. The ivshmem server is needed when one would like to use interrupts with ivshmem. The server manages a set of eventfds to send/recv those interrupts. There is currently only one implementation of this server that I'm aware of, which is available from this git repo [2] in the ivshmem-server directory. My suggestion for libvirt is that this code be integrated into libvirt, rather than managed by libvirt, for the following reasons 1. libvirt should keep track of the socket path in order to build ivshmem's command line anyway. 2. the current ivshmem server code is ~300 lines, so it shouldn't be a large integration effort. 3. keeping ivhsmem server separate increases the package management that distributions need to do. afaik, it isn't currently packaged for any distribution. One concern I have with the git repo [2] is that I don't see any license for ivshmem-server. I've cc'ed Cam for his input. Drew [1] http://www.redhat.com/archives/libvir-list/2012-November/msg00731.html [2] git://gitorious.org/nahanni/guest-code.git
On Tue, Nov 20, 2012 at 01:16:56PM -0500, Andrew Jones wrote:
This mail is meant to get a discussion started. Please keep me on cc for the discussion, as I'm not subscribed to libvir-list.
ivshmem is an implementation of an inter-VM communication channel. Support for this has been in qemu since v0.14.0 and libvirt patches have been recently posted[1]. What's still missing is the ivshmem server. The ivshmem server is needed when one would like to use interrupts with ivshmem. The server manages a set of eventfds to send/recv those interrupts. There is currently only one implementation of this server that I'm aware of, which is available from this git repo [2] in the ivshmem-server directory. My suggestion for libvirt is that this code be integrated into libvirt, rather than managed by libvirt, for the following reasons
1. libvirt should keep track of the socket path in order to build ivshmem's command line anyway. 2. the current ivshmem server code is ~300 lines, so it shouldn't be a large integration effort. 3. keeping ivhsmem server separate increases the package management that distributions need to do. afaik, it isn't currently packaged for any distribution.
One concern I have with the git repo [2] is that I don't see any license for ivshmem-server. I've cc'ed Cam for his input.
I guess my main question would be how much more, if any, is the ivshmem-server expected to grow over time ? I wouldn't want to get into a fork-situation if people are planning to do much more dev work on the current ivshmem-server code. NB, if the code is integrated into libvirt, I think it would still have to run in a separate daemon. The reason is that we want to ensure that guests remain fully functional, even when libvirtd is stopped (whether for RPM upgrade, or due to crash) I've no particular strong opinion either way on your proposal. On the surface it seems reasonable to me. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
----- Original Message -----
On Tue, Nov 20, 2012 at 01:16:56PM -0500, Andrew Jones wrote:
This mail is meant to get a discussion started. Please keep me on cc for the discussion, as I'm not subscribed to libvir-list.
ivshmem is an implementation of an inter-VM communication channel. Support for this has been in qemu since v0.14.0 and libvirt patches have been recently posted[1]. What's still missing is the ivshmem server. The ivshmem server is needed when one would like to use interrupts with ivshmem. The server manages a set of eventfds to send/recv those interrupts. There is currently only one implementation of this server that I'm aware of, which is available from this git repo [2] in the ivshmem-server directory. My suggestion for libvirt is that this code be integrated into libvirt, rather than managed by libvirt, for the following reasons
1. libvirt should keep track of the socket path in order to build ivshmem's command line anyway. 2. the current ivshmem server code is ~300 lines, so it shouldn't be a large integration effort. 3. keeping ivhsmem server separate increases the package management that distributions need to do. afaik, it isn't currently packaged for any distribution.
One concern I have with the git repo [2] is that I don't see any license for ivshmem-server. I've cc'ed Cam for his input.
I guess my main question would be how much more, if any, is the ivshmem-server expected to grow over time ? I wouldn't want to get into a fork-situation if people are planning to do much more dev work on the current ivshmem-server code.
Here's the entire git log for ivshmem-server Date: Thu Sep 6 11:36:33 2012 -0600 Error clean-up Fixed a warning and cleaned up two error message Date: Tue Nov 16 11:11:16 2010 -0700 just a few fixups Date: Tue Jun 15 14:43:01 2010 -0600 Adding the ivshmem server here - Cam So there was an initial drop, then nothing for two years, and then some recent cleanups. I believe that it serves a simple enough purpose that there shouldn't be any more growth.
NB, if the code is integrated into libvirt, I think it would still have to run in a separate daemon. The reason is that we want to ensure that guests remain fully functional, even when libvirtd is stopped (whether for RPM upgrade, or due to crash)
I've no particular strong opinion either way on your proposal. On the surface it seems reasonable to me.
Daniel -- |: http://berrange.com -o- | http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- | http://virt-manager.org :| |: http://autobuild.org -o- | http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- | http://live.gnome.org/gtk-vnc :|
Cam, ping Please let us know your opinion on integrating ivshmem-server into libvirt. Also, please confirm the licensing would allow it. Thanks, Drew ----- Original Message -----
----- Original Message -----
On Tue, Nov 20, 2012 at 01:16:56PM -0500, Andrew Jones wrote:
This mail is meant to get a discussion started. Please keep me on cc for the discussion, as I'm not subscribed to libvir-list.
ivshmem is an implementation of an inter-VM communication channel. Support for this has been in qemu since v0.14.0 and libvirt patches have been recently posted[1]. What's still missing is the ivshmem server. The ivshmem server is needed when one would like to use interrupts with ivshmem. The server manages a set of eventfds to send/recv those interrupts. There is currently only one implementation of this server that I'm aware of, which is available from this git repo [2] in the ivshmem-server directory. My suggestion for libvirt is that this code be integrated into libvirt, rather than managed by libvirt, for the following reasons
1. libvirt should keep track of the socket path in order to build ivshmem's command line anyway. 2. the current ivshmem server code is ~300 lines, so it shouldn't be a large integration effort. 3. keeping ivhsmem server separate increases the package management that distributions need to do. afaik, it isn't currently packaged for any distribution.
One concern I have with the git repo [2] is that I don't see any license for ivshmem-server. I've cc'ed Cam for his input.
I guess my main question would be how much more, if any, is the ivshmem-server expected to grow over time ? I wouldn't want to get into a fork-situation if people are planning to do much more dev work on the current ivshmem-server code.
Here's the entire git log for ivshmem-server
Date: Thu Sep 6 11:36:33 2012 -0600 Error clean-up Fixed a warning and cleaned up two error message Date: Tue Nov 16 11:11:16 2010 -0700 just a few fixups Date: Tue Jun 15 14:43:01 2010 -0600 Adding the ivshmem server here - Cam
So there was an initial drop, then nothing for two years, and then some recent cleanups. I believe that it serves a simple enough purpose that there shouldn't be any more growth.
NB, if the code is integrated into libvirt, I think it would still have to run in a separate daemon. The reason is that we want to ensure that guests remain fully functional, even when libvirtd is stopped (whether for RPM upgrade, or due to crash)
I've no particular strong opinion either way on your proposal. On the surface it seems reasonable to me.
Daniel -- |: http://berrange.com -o- | http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- | http://virt-manager.org :| |: http://autobuild.org -o- | http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- | http://live.gnome.org/gtk-vnc :|
On Tue, Dec 4, 2012 at 3:57 AM, Andrew Jones <drjones@redhat.com> wrote:
Cam,
ping
Please let us know your opinion on integrating ivshmem-server into libvirt. Also, please confirm the licensing would allow it.
Thanks, Drew
Hi, Apologies for missing this until now, I'll make sure to keep an eye here more often. I'm happy to release it under the GPL and work towards integrating it into libvirt. Sincerely, Cam
----- Original Message -----
----- Original Message -----
On Tue, Nov 20, 2012 at 01:16:56PM -0500, Andrew Jones wrote:
This mail is meant to get a discussion started. Please keep me on cc for the discussion, as I'm not subscribed to libvir-list.
ivshmem is an implementation of an inter-VM communication channel. Support for this has been in qemu since v0.14.0 and libvirt patches have been recently posted[1]. What's still missing is the ivshmem server. The ivshmem server is needed when one would like to use interrupts with ivshmem. The server manages a set of eventfds to send/recv those interrupts. There is currently only one implementation of this server that I'm aware of, which is available from this git repo [2] in the ivshmem-server directory. My suggestion for libvirt is that this code be integrated into libvirt, rather than managed by libvirt, for the following reasons
1. libvirt should keep track of the socket path in order to build ivshmem's command line anyway. 2. the current ivshmem server code is ~300 lines, so it shouldn't be a large integration effort. 3. keeping ivhsmem server separate increases the package management that distributions need to do. afaik, it isn't currently packaged for any distribution.
One concern I have with the git repo [2] is that I don't see any license for ivshmem-server. I've cc'ed Cam for his input.
I guess my main question would be how much more, if any, is the ivshmem-server expected to grow over time ? I wouldn't want to get into a fork-situation if people are planning to do much more dev work on the current ivshmem-server code.
Here's the entire git log for ivshmem-server
Date: Thu Sep 6 11:36:33 2012 -0600 Error clean-up Fixed a warning and cleaned up two error message Date: Tue Nov 16 11:11:16 2010 -0700 just a few fixups Date: Tue Jun 15 14:43:01 2010 -0600 Adding the ivshmem server here - Cam
So there was an initial drop, then nothing for two years, and then some recent cleanups. I believe that it serves a simple enough purpose that there shouldn't be any more growth.
NB, if the code is integrated into libvirt, I think it would still have to run in a separate daemon. The reason is that we want to ensure that guests remain fully functional, even when libvirtd is stopped (whether for RPM upgrade, or due to crash)
I've no particular strong opinion either way on your proposal. On the surface it seems reasonable to me.
Daniel -- |: http://berrange.com -o- | http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- | http://virt-manager.org :| |: http://autobuild.org -o- | http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- | http://live.gnome.org/gtk-vnc :|
On 2012年11月21日 02:16, Andrew Jones wrote:
This mail is meant to get a discussion started. Please keep me on cc for the discussion, as I'm not subscribed to libvir-list.
ivshmem is an implementation of an inter-VM communication channel. Support for this has been in qemu since v0.14.0 and libvirt patches have been recently posted[1]. What's still missing is the ivshmem server. The ivshmem server is needed when one would like to use interrupts with ivshmem. The server manages a set of eventfds to send/recv those interrupts. There is currently only one implementation of this server that I'm aware of, which is available from this git repo [2] in the ivshmem-server directory. My suggestion for libvirt is that this code be integrated into libvirt, rather than managed by libvirt, for the following reasons
1. libvirt should keep track of the socket path in order to build ivshmem's command line anyway. 2. the current ivshmem server code is ~300 lines, so it shouldn't be a large integration effort. 3. keeping ivhsmem server separate increases the package management that distributions need to do. afaik, it isn't currently packaged for any distribution.
One concern I have with the git repo [2] is that I don't see any license for ivshmem-server. I've cc'ed Cam for his input.
Add the missed CC.
Drew
[1] http://www.redhat.com/archives/libvir-list/2012-November/msg00731.html [2] git://gitorious.org/nahanni/guest-code.git
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
participants (4)
-
Andrew Jones -
Cam Macdonell -
Daniel P. Berrange -
Osier Yang