[libvirt] [PATCH v1 0/6] ivshmem support

Maxime Leroy maxime.leroy at 6wind.com
Wed Sep 3 10:56:00 UTC 2014


Hello Martin,

Let me summarize the points we need for the next patchset version:

1) merge patches
  - doc: schema, conf: Parse and format and tests ( for xml2xml ) into
doc: schema: conf: Add shmem node
  - qemu: Build comand, qemu: Add cap flag CAPS_IVSHMEM, and tests
(for xml2argv) into qemu: add ivshmem support

2) parsing shmem
  - remove <shmem> 'model' attribute
  - use _uip instand of ui
  - check size >= 1M
  - remove loop to parse childreen nodes
  - path attribute is optional, default path is
/var/run/libvirt/ivshmem-server/<name>-sock

3) tests:
 - add pci addresses in the XML

4) xml format

- no ivshmem server:

  <shmem name='shmem0'> (name is a mandatory attribute)
    <size unit='M'>32</size> (optionnal, default value: 4MB, size >=
1M and power of 2)
  </shmem>

- ivshmem server with no path to the socket file

  <shmem name='shmem0'> (name is a mandatory attribute)
    <server>
       <msi vectors='32' ioeventfd='on'/> (optionnal)
    </server>
    <size unit='M'>32</size> (optionnal)
  </shmem>

  default path is : /var/run/libvirt/ivshmem-server/<name>-sock

- ivshmem server with path to a specific socket file

  <shmem name='shmem0'>
    <server path='/tmp/shmem0-sock'>
       <msi vectors='32' ioeventfd='on'/> (optionnal)
    </server>
    <size unit='M'>32</size> (optionnal)
  </shmem>

The name attribute is only needed if libvirt starts the ivshmem server.
In the case of the ivshmem-server is already running, the path
attribute is enough.
To simplify, I think the name attribute should be always mandatory ?

What do you think about this new xml format ?

5) ivshmem server

 - remame virStartIvshmemServer to virIvshmemServerStart
 - call virIvshmemServerStart in qemuProcessStart instead to
qemuBuild*CommandLine
 - rename IVSHMEMSERVER to IVSHMEM_SERVER
 - autostart/stop ivshmem server

I really like the idea to use the new option '-q' to stop
automatically the server and the new option to pass the fd to
ivshmem-server and qemu. It's an elegant solution. ;)

Anyway, I need to wait to see if theses options can be integrated in
qemu before to submit a new patchset for libvirt.

--
Maxime




More information about the libvir-list mailing list