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

[Don Slutz <dslutz@xxxxxxxxxxx>]

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

    -Don Slutz



> Ian

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