[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 thing. 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 alsoIt'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 string) 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 Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |