qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] [PATCH v4 0/7] Add limited support of VMware's hyper-call r


From: Don Slutz
Subject: [Qemu-devel] [PATCH v4 0/7] Add limited support of VMware's hyper-call rpc
Date: Thu, 30 Apr 2015 09:32:22 -0400

Changes v4 to v4:

  Paolo Bonzini on "vmort_rpc: Add QMP access to vmport_rpc"
    Does this compile on non-x86 targets?
      Nope.  Fixed.

Changes v2 to v3:

  s/2.3/2.4

Changes v1 to v2:

   Added live migration code.
   Adjust data structures for migration.
   Switch to GHashTable.

  Eric Blake
    s/spawened/spawned/
      Done
    s/traceing/tracing/
      Done
    Change "error_set(errp, ERROR_CLASS_GENERIC_ERROR, " to
    "error_setg(errp, "
      Done
    Why two commands (inject-vmport-reboot, inject-vmport-halt)?
      Switched to inject-vmport-action.
    format=base64 "bug" statements.
      Dropped.

Much more on format=base64:

If there is a bug it is in GLIB.  However the Glib reference manual
refers to RFC 1421 and RFC 2045 and MIME encoding.  Based on all
that (which seems to match:

http://en.wikipedia.org/wiki/Base64

) MIME states that all characters outside the (base64) alphabet are
to be ignored.  Testing shows that g_base64_decode() does this.

The confusion is that most non-MIME uses reject a base64 string that
contain characters outside the alphabet.  I was just following the
other uses of base64 in this file.

DataFormat refers to RFC 3548, which has the info:

"
   Implementations MUST reject the encoding if it contains
   characters outside the base alphabet when interpreting base
   encoded data, unless the specification referring to this document
   explicitly states otherwise.  Such specifications may, as MIME
   does, instead state that characters outside the base encoding
   alphabet should simply be ignored when interpreting data ("be
   liberal in what you accept").
"

So with GLIB going the MIME way, I do not think this is a QEMU bug
(you could consider this a GLIB bug, but the document I found says
that GLIB goes the MIME way and so does not reject anything).

---


The support included is enough to allow VMware tools to install in a
guest and provide guestinfo support.  guestinfo support is provided
by what is known as VMware RPC support.

One of the better on-line references is:

https://sites.google.com/site/chitchatvmback/backdoor

As a place to get more accurate information by studying:

http://open-vm-tools.sourceforge.net/

With vmware tools installed, you can do:

-------------------------------------------------------------------------------
Last login: Fri Jan 30 16:03:08 2015
address@hidden ~]# vmtoolsd --cmd "info-get guestinfo.joejoel"
No value found
address@hidden ~]# vmtoolsd --cmd "info-set guestinfo.joejoel bar"

address@hidden ~]# vmtoolsd --cmd "info-get guestinfo.joejoel"
bar
address@hidden ~]# 
-------------------------------------------------------------------------------

to access guest info.  QMP access is also provided.

The live migration code is still in progress.

Don Slutz (7):
  vmport.c: Fix vmport_cmd_ram_size
  vmport_rpc: Add the object vmport_rpc
  vmport_rpc: Add limited support of VMware's hyper-call rpc
  vmport_rpc: Add QMP access to vmport_rpc object.
  vmport_rpc: Add migration
  vmport:  Add VMware all ring hack
  MAINTAINERS: add VMware port

 MAINTAINERS              |    7 +
 hw/i386/pc.c             |   34 +-
 hw/i386/pc_piix.c        |    2 +-
 hw/i386/pc_q35.c         |    2 +-
 hw/misc/Makefile.objs    |    1 +
 hw/misc/vmport.c         |    2 +-
 hw/misc/vmport_rpc.c     | 1442 ++++++++++++++++++++++++++++++++++++++++++++++
 include/hw/i386/pc.h     |    6 +-
 monitor.c                |   23 +
 qapi-schema.json         |   90 +++
 qmp-commands.hx          |  120 ++++
 target-i386/cpu.c        |    4 +
 target-i386/cpu.h        |    2 +
 target-i386/seg_helper.c |    6 +
 trace-events             |   24 +
 15 files changed, 1760 insertions(+), 5 deletions(-)
 create mode 100644 hw/misc/vmport_rpc.c

-- 
1.8.4




reply via email to

[Prev in Thread] Current Thread [Next in Thread]