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

[Don Slutz <dslutz@verizon.com>]

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
>