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

[Don Slutz <dslutz@verizon.com>]

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

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