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

Re: [Xen-devel] [PATCH v2 3/3] Add limited support of VMware's hyper-call

On 09/08/14 09:35, Ian Campbell wrote:
On Mon, 2014-09-01 at 11:33 -0400, Don Slutz wrote:
This is both a more complete support then in currently provided by
QEMU and/or KVM and less.  The missing part requires QEMU changes
and has been left out until the QEMU patches are accepted upstream.

VMware's hyper-call is also known as VMware Backdoor I/O Port.

Note: this support does not depend on vmware_hw being non-zero.

Summary is that VMware treats "IN EAX, DX" (or "OUT DX, EAX"; or
"inl %dx, %eax" in AT&T syntax ) to port 0x5658 specially.  Note:
since many operations return data in EAX, "OUT DX, EAX" does not
work for them on VMware, I did not support the "OUT DX, EAX", but it
would not be hard to add.
Quite a bit of this changelog seems to concern itself with the
differences between Intel and AT&T as syntax. Please can you just use
the same AT&T syntax as are used in Xen's own .S files throughout (and
without the need to comment on there being other syntaxes).

Ok, Will adjust to have only AT&T syntax.

Also this instruction is allowed to be used from ring 3.  To
support this the vmexit for GP needs to be enabled.
Isn't that quite costly?

Yes.  But since that is how VMware does it, I need to do the same slow

The support included is enough to allow VMware tools to install in a
HVM domU and provide guestinfo support.  guestinfo support is
provide by what is known as VMware RPC support.  This guestinfo
support is provided via libxc.  libxl support has not be written.
I suppose this isn't a true RPC, since there isn't any actual running
code on the remote side? (alternatively if you have added some sort of
daemon backend to libxc then we need to talk ;-))

Nope, it is not a true RPC.  However that is the way VMware's
documentation talks about it.  However it is a very slow speed
way of passing data into or out of a domU.  At some point it
does make sense to consider how libxl might change to take
advantage of this, but I am sure that this is not happening for 4.5.

This was why I provided the optional unit test code as an example
of the use of the libxc changes.

If the domU is running VMware tools, then the "build version" of
the tools is also available via xc_get_HVM_param().  This also
It's just xc_get_hvm_param(), isn't it?

Yes. looks like a typo.

+int xc_set_vmport_guest_info(xc_interface *handle,
+                             domid_t dom,
+                             unsigned int key_len,
+                             char *key,
+                             unsigned int val_len,
+                             char *val)
Can key and val have embedded NULs?

(another way of asking if we can treat one or both as a null terminated

I have not seen any embedded NULs for guest info, but the way they
are tansfered do include embedded NULs.  And so it is all coded to
handle strings with embedded NULs.

+int xc_get_vmport_guest_info(xc_interface *handle,
+                             domid_t dom,
+                             unsigned int key_len,
+                             char *key,
+                             unsigned int val_max,
+                             unsigned int *val_len,
+                             char *val)
+int xc_fetch_vmport_guest_info(xc_interface *handle,
+                               domid_t dom,
+                               unsigned int idx,
+                               unsigned int key_max,
+                               unsigned int *key_len,
+                               char *key,
+                               unsigned int val_max,
+                               unsigned int *val_len,
+                               char *val)
How do get and fetch differ? I can see how they differ in code terms,
but I'm not sure why and what the differences imply.

get does just the specified key.  fetch is used to get all key value pairs.
It might helpp to look at v3 #15 which uses fetch vs v3 #14 which uses
get in the unit test code.

Hope this helps.
    -Don Slutz


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.