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

[Martin Kletzander]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20140807/991aae1b/attachment-0001.sig>