1. 18 2月, 2019 3 次提交
  2. 07 2月, 2019 1 次提交
  3. 15 1月, 2019 1 次提交
  4. 14 1月, 2019 1 次提交
  5. 07 1月, 2019 1 次提交
  6. 22 12月, 2018 2 次提交
    • Y
      qapi: Define new QMP message for pvrdma · 4a5c9903
      Yuval Shaia 提交于
      pvrdma requires that the same GID attached to it will be attached to the
      backend device in the host.
      
      A new QMP messages is defined so pvrdma device can broadcast any change
      made to its GID table. This event is captured by libvirt which in  turn
      will update the GID table in the backend device.
      Signed-off-by: NYuval Shaia <yuval.shaia@oracle.com>
      Reviewed-by: NMarcel Apfelbaum <marcel.apfelbaum@gmail.com>
      Acked-by: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NMarcel Apfelbaum <marcel.apfelbaum@gmail.com>
      4a5c9903
    • Y
      contrib/rdmacm-mux: Add implementation of RDMA User MAD multiplexer · a5d2f6f8
      Yuval Shaia 提交于
      RDMA MAD kernel module (ibcm) disallow more than one MAD-agent for a
      given MAD class.
      This does not go hand-by-hand with qemu pvrdma device's requirements
      where each VM is MAD agent.
      Fix it by adding implementation of RDMA MAD multiplexer service which on
      one hand register as a sole MAD agent with the kernel module and on the
      other hand gives service to more than one VM.
      
      Design Overview:
      Reviewed-by: NShamir Rabinovitch <shamir.rabinovitch@oracle.com>
      ----------------
      A server process is registered to UMAD framework (for this to work the
      rdma_cm kernel module needs to be unloaded) and creates a unix socket to
      listen to incoming request from clients.
      A client process (such as QEMU) connects to this unix socket and
      registers with its own GID.
      
      TX:
      ----
      When client needs to send rdma_cm MAD message it construct it the same
      way as without this multiplexer, i.e. creates a umad packet but this
      time it writes its content to the socket instead of calling umad_send().
      The server, upon receiving such a message fetch local_comm_id from it so
      a context for this session can be maintain and relay the message to UMAD
      layer by calling umad_send().
      
      RX:
      ----
      The server creates a worker thread to process incoming rdma_cm MAD
      messages. When an incoming message arrived (umad_recv()) the server,
      depending on the message type (attr_id) looks for target client by
      either searching in gid->fd table or in local_comm_id->fd table. With
      the extracted fd the server relays to incoming message to the client.
      Signed-off-by: NYuval Shaia <yuval.shaia@oracle.com>
      Reviewed-by: NShamir Rabinovitch <shamir.rabinovitch@oracle.com>
      Signed-off-by: NMarcel Apfelbaum <marcel.apfelbaum@gmail.com>
      a5d2f6f8
  7. 12 12月, 2018 1 次提交
  8. 03 10月, 2018 1 次提交
    • V
      contrib: add elf2dmp tool · 3fa2d384
      Viktor Prutyanov 提交于
      elf2dmp is a converter from ELF dump (produced by 'dump-guest-memory') to
      Windows MEMORY.DMP format (also know as 'Complete Memory Dump') which can be
      opened in WinDbg.
      
      This tool can help if VMCoreInfo device/driver is absent in Windows VM and
      'dump-guest-memory -w' is not available but dump can be created in ELF format.
      
      The tool works as follows:
      1. Determine the system paging root looking at GS_BASE or KERNEL_GS_BASE
      to locate the PRCB structure and finds the kernel CR3 nearby if QEMU CPU
      state CR3 is not suitable.
      2. Find an address within the kernel image by dereferencing the first
      IDT entry and scans virtual memory upwards until the start of the
      kernel.
      3. Download a PDB matching the kernel from the Microsoft symbol store,
      and figure out the layout of certain relevant structures necessary for
      the dump.
      4. Populate the corresponding structures in the memory image and create
      the appropriate dump header.
      Signed-off-by: NViktor Prutyanov <viktor.prutyanov@virtuozzo.com>
      Message-Id: <1535546488-30208-3-git-send-email-viktor.prutyanov@virtuozzo.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      3fa2d384
  9. 20 8月, 2018 1 次提交
  10. 08 6月, 2018 1 次提交
  11. 30 5月, 2018 1 次提交
  12. 23 5月, 2018 3 次提交
  13. 12 3月, 2018 1 次提交
  14. 07 3月, 2018 1 次提交
  15. 05 3月, 2018 1 次提交
  16. 03 3月, 2018 5 次提交
    • M
      qapi: Move qapi-schema.json to qapi/, rename generated files · eb815e24
      Markus Armbruster 提交于
      Move qapi-schema.json to qapi/, so it's next to its modules, and all
      files get generated to qapi/, not just the ones generated for modules.
      
      Consistently name the generated files qapi-MODULE.EXT:
      qmp-commands.[ch] become qapi-commands.[ch], qapi-event.[ch] become
      qapi-events.[ch], and qmp-introspect.[ch] become qapi-introspect.[ch].
      This gets rid of the temporary hacks in scripts/qapi/commands.py,
      scripts/qapi/events.py, and scripts/qapi/common.py.
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Message-Id: <20180211093607.27351-28-armbru@redhat.com>
      Reviewed-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
      Reviewed-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
      [eblake: Fix trailing dot in tpm.c, undo temporary hack for OSX toolchain]
      Signed-off-by: NEric Blake <eblake@redhat.com>
      eb815e24
    • M
      qapi: Empty out qapi-schema.json · 112ed241
      Markus Armbruster 提交于
      The previous commit improved compile time by including less of the
      generated QAPI headers.  This is impossible for stuff defined directly
      in qapi-schema.json, because that ends up in headers that that pull in
      everything.
      
      Move everything but include directives from qapi-schema.json to new
      sub-module qapi/misc.json, then include just the "misc" shard where
      possible.
      
      It's possible everywhere, except:
      
      * monitor.c needs qmp-command.h to get qmp_init_marshal()
      
      * monitor.c, ui/vnc.c and the generated qapi-event-FOO.c need
        qapi-event.h to get enum QAPIEvent
      
      Perhaps we'll get rid of those some other day.
      
      Adding a type to qapi/migration.json now recompiles some 120 instead
      of 2300 out of 5100 objects.
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Message-Id: <20180211093607.27351-25-armbru@redhat.com>
      [eblake: rebase to master]
      Signed-off-by: NEric Blake <eblake@redhat.com>
      112ed241
    • M
      qapi: Generate separate .h, .c for each module · 252dc310
      Markus Armbruster 提交于
      Our qapi-schema.json is composed of modules connected by include
      directives, but the generated code is monolithic all the same: one
      qapi-types.h with all the types, one qapi-visit.h with all the
      visitors, and so forth.  These monolithic headers get included all
      over the place.  In my "build everything" tree, adding a QAPI type
      recompiles about 4800 out of 5100 objects.
      
      We wouldn't write such monolithic headers by hand.  It stands to
      reason that we shouldn't generate them, either.
      
      Split up generated qapi-types.h to mirror the schema's modular
      structure: one header per module.  Name the main module's header
      qapi-types.h, and sub-module D/B.json's header D/qapi-types-B.h.
      
      Mirror the schema's includes in the headers, so that qapi-types.h gets
      you everything exactly as before.  If you need less, you can include
      one or more of the sub-module headers.  To be exploited shortly.
      
      Split up qapi-types.c, qapi-visit.h, qapi-visit.c, qmp-commands.h,
      qmp-commands.c, qapi-event.h, qapi-event.c the same way.
      qmp-introspect.h, qmp-introspect.c and qapi.texi remain monolithic.
      
      The split of qmp-commands.c duplicates static helper function
      qmp_marshal_output_str() in qapi-commands-char.c and
      qapi-commands-misc.c.  This happens when commands returning the same
      type occur in multiple modules.  Not worth avoiding.
      
      Since I'm going to rename qapi-event.[ch] to qapi-events.[ch], and
      qmp-commands.[ch] to qapi-commands.[ch], name the shards that way
      already, to reduce churn.  This requires temporary hacks in
      commands.py and events.py.  Similarly, c_name() must temporarily
      be taught to munge '/' in common.py.  They'll go away with the rename.
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Message-Id: <20180211093607.27351-23-armbru@redhat.com>
      Reviewed-by: NEric Blake <eblake@redhat.com>
      [eblake: declare a dummy variable in each .c file, to shut up OSX
      toolchain warnings about empty .o files, including hacking c_name()]
      Signed-off-by: NEric Blake <eblake@redhat.com>
      252dc310
    • M
      qapi/types qapi/visit: Generate built-in stuff into separate files · cdb6610a
      Markus Armbruster 提交于
      Linking code from multiple separate QAPI schemata into the same
      program is possible, but involves some weirdness around built-in
      types:
      
      * We generate code for built-in types into .c only with option
        --builtins.  The user is responsible for generating code for exactly
        one QAPI schema per program with --builtins.
      
      * We generate code for built-in types into .h regardless of
        --builtins, but guarded by #ifndef QAPI_VISIT_BUILTIN.  Because all
        copies of this code are exactly the same, including any combination
        of these headers works.
      
      Replace this contraption by something more conventional: generate code
      for built-in types into their very own files: qapi-builtin-types.c,
      qapi-builtin-visit.c, qapi-builtin-types.h, qapi-builtin-visit.h, but
      only with --builtins.  Obey --output-dir, but ignore --prefix for
      them.
      
      Make qapi-types.h include qapi-builtin-types.h.  With multiple
      schemata you now have multiple qapi-types.[ch], but only one
      qapi-builtin-types.[ch].  Same for qapi-visit.[ch] and
      qapi-builtin-visit.[ch].
      
      Bonus: if all you need is built-in stuff, you can include a much
      smaller header.  To be exploited shortly.
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Message-Id: <20180211093607.27351-21-armbru@redhat.com>
      Reviewed-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
      Reviewed-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
      [eblake: fix octal constant for python 3]
      Signed-off-by: NEric Blake <eblake@redhat.com>
      cdb6610a
    • M
      qapi: Rename generated qmp-marshal.c to qmp-commands.c · 834a3f34
      Markus Armbruster 提交于
      All generated .c are named like their .h, except for qmp-marshal.c and
      qmp-commands.h.  To add to the confusion, tests-qmp-commands.c falsely
      matches generated test-qmp-commands.h.
      
      Get rid of this unnecessary complication.
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Message-Id: <20180211093607.27351-19-armbru@redhat.com>
      Reviewed-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
      Reviewed-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
      Signed-off-by: NEric Blake <eblake@redhat.com>
      834a3f34
  17. 19 2月, 2018 2 次提交
  18. 16 2月, 2018 1 次提交
  19. 31 1月, 2018 1 次提交
  20. 25 1月, 2018 1 次提交
  21. 19 1月, 2018 1 次提交
  22. 10 1月, 2018 1 次提交
  23. 25 10月, 2017 1 次提交
  24. 11 10月, 2017 1 次提交
  25. 22 9月, 2017 1 次提交
    • P
      scsi, file-posix: add support for persistent reservation management · 7c9e5276
      Paolo Bonzini 提交于
      It is a common requirement for virtual machine to send persistent
      reservations, but this currently requires either running QEMU with
      CAP_SYS_RAWIO, or using out-of-tree patches that let an unprivileged
      QEMU bypass Linux's filter on SG_IO commands.
      
      As an alternative mechanism, the next patches will introduce a
      privileged helper to run persistent reservation commands without
      expanding QEMU's attack surface unnecessarily.
      
      The helper is invoked through a "pr-manager" QOM object, to which
      file-posix.c passes SG_IO requests for PERSISTENT RESERVE OUT and
      PERSISTENT RESERVE IN commands.  For example:
      
        $ qemu-system-x86_64
            -device virtio-scsi \
            -object pr-manager-helper,id=helper0,path=/var/run/qemu-pr-helper.sock
            -drive if=none,id=hd,driver=raw,file.filename=/dev/sdb,file.pr-manager=helper0
            -device scsi-block,drive=hd
      
      or:
      
        $ qemu-system-x86_64
            -device virtio-scsi \
            -object pr-manager-helper,id=helper0,path=/var/run/qemu-pr-helper.sock
            -blockdev node-name=hd,driver=raw,file.driver=host_device,file.filename=/dev/sdb,file.pr-manager=helper0
            -device scsi-block,drive=hd
      
      Multiple pr-manager implementations are conceivable and possible, though
      only one is implemented right now.  For example, a pr-manager could:
      
      - talk directly to the multipath daemon from a privileged QEMU
        (i.e. QEMU links to libmpathpersist); this makes reservation work
        properly with multipath, but still requires CAP_SYS_RAWIO
      
      - use the Linux IOC_PR_* ioctls (they require CAP_SYS_ADMIN though)
      
      - more interestingly, implement reservations directly in QEMU
        through file system locks or a shared database (e.g. sqlite)
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      7c9e5276
  26. 19 9月, 2017 2 次提交
  27. 15 9月, 2017 1 次提交
  28. 20 7月, 2017 1 次提交
  29. 11 7月, 2017 1 次提交