On Fri, Aug 08, 2014 at 02:07:56PM +0200, Maxime Leroy wrote:
On Fri, Aug 8, 2014 at 11:21 AM, Martin Kletzander <mkletzan@xxxxxxxxxx> wrote:On Thu, Aug 07, 2014 at 05:34:35PM +0200, Maxime Leroy wrote:On Thu, Aug 7, 2014 at 12:33 PM, Martin Kletzander <mkletzan@xxxxxxxxxx> wrote:On Tue, Aug 05, 2014 at 06:48:01PM +0200, Maxime Leroy wrote:[...]Note: the ivshmem server needs to be launched before creating the VM. It's not done by libvirt.This is a good temporary workaround, but keep in mind that libvirt works remotely as well and for remote machines libvirt should be able to do everything for you to be able to run the machine if necessary. So even if it might not start the server now, it should in the future. That should be at least differentiable by some parameter (maybe you do it somewhere in the code somehow, I haven't got into that).The new version of ivshmem server has not been accepted yet in QEMU. I think it's too early to have an option to launch an ivshmem server or not. I will prefer to focus on integrating these patches in libvirt first, before adding a new feature to launch an ivhsmem server. Are you ok with that ?There was a suggestion of implementing the non-server variant first and expand it to the variant with server afterwards. That might be the best solution because we'll have bit more time to see the re-factoring differences in QEMU as well. And we can concentrate on other details.I would prefer to have ivshmen server and non-server mode supported in libvirt with these patches; because the XML format need to be designed with both at the same time. The new XML format supporting a start or not of ivshmem server could be: <shmem type='ivshmem'> <shm file='ivshmem0'> <server socket='/tmp/socket-ivshmem0' start='yes'> <size unit='M'>32</size> <msi vectors='32' ioeventfd='on'/> </shmem> Note: This new XML format can support different types of shmem. After my holiday, I am going to check how to implement this feature. What do you think about this XML format?
It's better, but I would like this: <shmem name='my_ivshmem_001'> <server socket='/tmp/ivsh-server' start='yes'/> ... </shmem> That could be simplified into (in case of no server): <shmem name='my_ivshmem_001'/> Of course this will have a PCI address afterwards. This design is generic enough that it doesn't mention "ivshmem" (so it can be implemented differently in any hypervisor). What's your opinion on that?
Any hints to develop this feature (i.e. starting ivshmen server in libvirt) is welcomed.
With starting the server in libvirt we'll have to wait until it's in qemu *and* we have to deal with how and when to stop the server (if we are running it).
I assume I need to add a new file: src/util/virivshmemserver.c to add a new function virIvshmemServerRun() and to use it in qemu_command.c. How can I check whether an ivshmem-server application is installed or not on the host ? Are there other equivalent behaviors into libvirt?
That should be checked by virFileIsExecutable() on a IVSHMEM_SERVER_PATH that would be set by configure.ac (take a look at EBTABLES_PATH in src/util/virfirewall.c for example). I'll also see if I'll be able to get any info from the QEMU side about what can we expect to happen with ivshmem in near future. Martin
Attachment:
signature.asc
Description: Digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list