Osier,<div><br></div><div>Thanks for including me in the review of this patch. I can tell right away that your implementation is better. It's more modular and well documented. When I submitted my patch about a month ago, it was basically just me submitting the changes that I made to get ivshmem working for my lab. We were on a tight deadline and so a lot of the code is rushed and poorly pieced together. However, I am glad that my submission has helped at least get the ball rolling on memory device support for Libvirt as it is very much needed.</div>
<div><br></div><div>Thanks for your help,</div><div>Shawn Furrow</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Nov 16, 2012 at 4:59 AM, Osier Yang <span dir="ltr"><<a href="mailto:jyang@redhat.com" target="_blank">jyang@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">v1 - v2:<br>
  * Change attribute "model" to be a sub-element instead.<br>
<br>
NOTE:<br>
  Since the invshmem server socket path is not created by<br>
QEMU, but by an external app called "ivshmem_server", It's<br>
not good to construct the socket path in libvirt with a solid<br>
rule, and force the user to figure out what the path is<br>
libvirt uses first and use that for "ivshmem_server". Thus it's<br>
the user's business to set the selinux context on the socket<br>
path so that the qemu process could be started successfully<br>
when selinux is enabled.<br>
<br>
Shawn Furrow proposed a patch more than a month ago:<br>
<a href="https://www.redhat.com/archives/libvir-list/2012-September/msg01612.html" target="_blank">https://www.redhat.com/archives/libvir-list/2012-September/msg01612.html</a><br>
<br>
But this is a complete different implementation. Considering<br>
there could be other memory related devices in futuer, this<br>
introduces a new device model, called "memory device", instead<br>
of a specific device like "ivshmem", though only "ivshmem"<br>
is supported currently. Please refer to PATCH 1/4 for more<br>
details.<br>
<br>
CC'ed to Cam and Shawn, to see if there is advise on the documents.<br>
<br>
Osier Yang (4):<br>
  docs: Add documents for memory device<br>
  conf: Parse and format memory device XML<br>
  qemu: Add cap flag QEMU_CAPS_IVSHMEM<br>
  qemu: Build command line for ivshmem device<br>
<br>
 docs/<a href="http://formatdomain.html.in" target="_blank">formatdomain.html.in</a>                        |   40 +++++<br>
 docs/schemas/domaincommon.rng                    |   40 +++++<br>
 src/conf/domain_conf.c                           |  195 +++++++++++++++++++++-<br>
 src/conf/domain_conf.h                           |   27 +++<br>
 src/libvirt_private.syms                         |    3 +<br>
 src/qemu/qemu_capabilities.c                     |    2 +<br>
 src/qemu/qemu_capabilities.h                     |    1 +<br>
 src/qemu/qemu_command.c                          |   85 ++++++++++<br>
 src/util/util.c                                  |    5 +<br>
 src/util/util.h                                  |    2 +<br>
 tests/qemuhelptest.c                             |   12 +-<br>
 tests/qemuxml2argvdata/qemuxml2argv-ivshmem.args |    7 +<br>
 tests/qemuxml2argvdata/qemuxml2argv-ivshmem.xml  |   34 ++++<br>
 tests/qemuxml2argvtest.c                         |    2 +<br>
 14 files changed, 450 insertions(+), 5 deletions(-)<br>
 create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-ivshmem.args<br>
 create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-ivshmem.xml<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
1.7.7.6<br>
<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Virginia Tech<br>Bradley Department of Electrical and Computer Engineering<br>B.S. Electrical Engineering</div><div>B.S. Computer Engineering</div>
<br>
</div>