Re: [libvirt] [RFC PATCH 1/5] doc: schema: Add basic documentation for the ivshmem support

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(a)redhat.com&gt; 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(a)redhat.com&gt; >>>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.