On Tue, Aug 05, 2014 at 06:48:01PM +0200, Maxime Leroy wrote:
This patch documents XML elements used for support of ivshmem devices.
At first, I'd like to thank you for the proposal. There were numerous requests for this, but since ivshmem is not known much, it's not easy to get it in. I'll get to the details later.
About ivshmem, please see the following documentation: http://git.qemu.org/?p=qemu.git;a=blob;f=docs/specs/ivshmem_device_spec.txt (Ivshmem documentation for qemu will be updated soon: https://lists.nongnu.org/archive/html/qemu-devel/2014-07/msg02974.html)
The documentation is partial and confusing. I hope that will change, but there might be more changes than that. The code should be re-factored, command-line options changed, etc.
In the devices section in the domain XML users may specify: - For ivshmem device using an ivshmem server: <ivshmem use_server='yes' role='master'/> <source file='/tmp/socket-ivshmem0'/> <size unit='M'>32</size> <msi vectors='32' ioeventfd='on'/> </ivshmem>
At first, we should be more generic about the name if we want other hypervisors to benefit from it. The idea is that ivshmem is not something new that nobody else than qemu can do. It's just a shared memory, every other hypervisor out there can come up with something similar to this, so we don't want this to be called ivshmem. One more reason for that is that it doesn't just share memory between VMs, but between host <-> guest too. Something like a 'shmem' should be fine, I guess. I prolonged the paragraph to stress out this is not qemu-only feature (or might not be in the future) and we should be prepared for that. Because of that, we should be more generic about more things than just the name. Another thing that bothers me (and bothered me with earlier ivshmem-related proposals as well) is that role='(master|peer)' thing. That thing does not mean squat for qemu and should be removed completely. Looking at the code the only thing that role=peer (non-default, by the way) does is that it disables migration... That's it. That's another sign of the ivshmem code maturity inside QEMU that we should keep in mind when designing the XML schema.
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).
- For ivshmem device not using an ivshmem server:
<ivshmem use_server='no' role='peer'/>
<source file='ivshmem1'/>
<size unit='M'>32</size>
</ivshmem>
Note: the ivshmem shm needs to be created before
creating the VM. It's not done by libvirt.
Isn't it done by qemu automatically? If it's not, the same as for the ivshmem server applies. I had one idea to deal with most of the problems (but adding a lot of code); let me outline that. From the global POV, we want something that will fully work remotely, we want to be able to start it, stop it, assign it to domains, etc. We might even migrate it in the future, but that's another storyline. It must be generic enough, as it can change a lot in the future. And so on. One way out of this mess is to have yet another driver, let's call it shmem driver. That driver would have APIs to define, undefine, ..., start and stop shared memory regions. Those would have their own XML, and domain XML would only have a device <shmem name='asdf_mem'/> or <shmem uuid='...'/> that would mean the domain will be started with a shared memory region defined in the shmem driver. That way it could be shared even between hypervisors. At first it seemed like an unreasonable solution, but the more I think about it the more I like it. It's not a requirement to get your patches it, though, I just wanted to share this in case you (or anyone else) find it compelling enough to try it. Martin
Attachment:
signature.asc
Description: Digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list