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

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

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