[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 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).

> 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?

> 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 ;-))

> 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?

> +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

> +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.


Xen-devel mailing list



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