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

[Boris Ostrovsky <boris.ostrovsky@oracle.com>]

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@lists.xen.org
> http://lists.xen.org/xen-devel