[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/10/14 05:32, Ian Campbell wrote:
On Tue, 2014-09-09 at 13:31 -0400, 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
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).

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).
Hrm, well this is mainly one for the hypervisor guys and I believe there
is already a subthread exploring option here so I'll leave it at that.

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).
Is that functionality in this series and I've just missed it?

The clean shutdown of windows can be done with the optional
code in v3 (not this patch set):

A tool to send a trigger to a domU via xc_domain_send_trigger

I know this is not the best and having something in shutdown_domain (or
libxl_domain_shutdown) and reboot_domain (or libxl_domain_reboot) whould
be much better.  I think this is too late in 4.5 since the code has not
been written yet (the tool stack I use all the time does have it).

And for #2, you also need a script in the guest, VMware tools installed in
the guest and use the optional tool in v3:

A tool to get and set VMware guestinfo

which I do have.  I might have mis-understood your question.  Hope this

    -Don Slutz


Xen-devel mailing list



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