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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

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

Ian


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