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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

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.

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

> >> +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?

Ian.



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