Re: [PATCH 4/4] qemu: Build command line for ivshmem device

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2012年11月08日 22:18, Daniel P. Berrange wrote:
On Wed, Nov 07, 2012 at 05:40:44PM +0800, Osier Yang wrote:
Depends on whether "source path" is specified, the command line
is built like:

   * 'path' is specified, with interrupts (/tmp/nahanni is the
      ivshmem server socket path)
     -chardev socket,path=/tmp/nahanni,id=nahanni
     -device ivshmem,chardev=nahanni,size=512m,vectors=8,ioeventfd=on

   * 'path' is not specified, without interrupts
     -device ivshmem,shm=nahanni,size=512m,vectors=8,ioeventfd=on

* src/qemu/qemu_command.c (New helper qemuBuildMemoryDevStr to
                            to build args of '-device'; Assign
                            PCI address for the device; Build
                            args of '-chardev')
* tests/qemuxml2argvdata/qemuxml2argv-ivshmem.xml: (See below)
* tests/qemuxml2argvdata/qemuxml2argv-ivshmem.args: (See below)
* tests/qemuxml2argvtest.c: (Add tests)

---
  src/qemu/qemu_command.c                          |   85 ++++++++++++++++++++++
  tests/qemuxml2argvdata/qemuxml2argv-ivshmem.args |    7 ++
  tests/qemuxml2argvdata/qemuxml2argv-ivshmem.xml  |   33 +++++++++
  tests/qemuxml2argvtest.c                         |    2 +
  4 files changed, 127 insertions(+), 0 deletions(-)
  create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-ivshmem.args
  create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-ivshmem.xml

No changes to SELinux ?  I'm reasonably sure the policy should
forbid QEMU from creating the shared memory backing file. For
hugepages, we had to create a per-QEMU directory, label that and
then pass it to QEMU.

Ah, I didn't realize that, especially when the selinux is disabled,
thanks for pointing it out.


This perhaps implies that our XML should not contain the actual
path. Libvirt can just create a path based on the "name" of the
device and set a label of the dir as for hugepages.

The shared memory server socket path is not created by QEMU, but
by a external application (called "ivshmem_server [1]"), creating
it in libvirt implies a force for users. They have to known our
rule first, and start the shared memory server with the right
socket path, and then starts the domain, generally it should be
opposite with the workflow which users want. So IMO it's not
a good way to go.

[1]: http://gitorious.org/nahanni/guest-code/trees/master/ivshmem-server

Regards,
Osier

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]