(Imported thread from archives, hopefully I won't break threading. If I did, I apologize.) On Aug 08 2014, Martin Kletzander wrote: >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> Keep in mind that libvirt should not allow having both the attribute name and the server in the same shmem element. QEMU currently only issues a warning, but I plan to change that, since it makes no sense to continue when there are two possible sources for the SHMEM's file descriptor. > >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. I plan to make a few mostly internal modifications on how it accesses memory and how the registers are laid out in BAR1. I don't really plan on changing the command line for now, one of my minimal changes were changing 'use64=<int>' to 'use64=<bool>', however MST didn't really like it claiming that it will break existing scripts, so I postponed the patch until I finish off doing the more serious internal stuff. Watch out for patchdump with RFCs on qemu-devel in the next few days... Thanks! Levente Kurusa -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list