[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/09/2014 01:31 PM, Don Slutz wrote:
On 09/09/14 05:36, Ian Campbell wrote:
On Mon, 2014-09-08 at 12:57 -0400, Don Slutz wrote:
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.
Sounds from other subthreads like there might be other better ways? It's
hard to believe that vmware is really trapping every #GP.

I have not found a better way.  The simplest statement I have come
up with is that this is not a pass thru of the VMware device.  Or the
statement (in AMD land): Generate an IOIO #VMEXIT not a GP
#VMWEXIT for ioport <x> (or all ports).



When I asked about enabling #GP intercepts only when we know that the guest is VMware-aware I meant that you'd do it as soon as you detect that you are having such a guest (e.g. when you set HVM_PARAM_VMWARE_PORT from libxl). You set is_vmware=1, for example. And then you only add TRAP_gp_fault intercept in construct_vmcb() when is_vmware is true (and probably something similar for VMX). Or something along these lines.

I suspect you are trying to figure out how to decide this during guest execution, but that's not what I was referring to.


-boris


And yes this sounds bad, until you think about how many GP #VMEXIT
are done.  For both Linux and Windows this is a small number (< 10).

Any others would be application ones.

I am working on making the GP #VMEXIT optional.


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.
So is the libxc code as proposed today actually used for anything?

Yes.  2 main areas:

1) Clean shutdown of windows guests with VMware tools installed.
     (acpi poweroff does not work if logged off).
2) set root's password and hostname at 1st boot of a template
    (done by VMware guestinfo).  Note: this could have been done with
    xenstore (XenBus?) but was not since we also use the VMware
    mouse support (not for 4.5, planned for 4.6 needs QEMU support).


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

+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.
Perhaps get and either get_all or fetch_all would be clearer names?

I will go with fetch_all.

    -Don Slutz

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

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