From mboxrd@z Thu Jan 1 00:00:00 1970 From: Don Slutz Subject: Re: [PATCH v2 3/3] Add limited support of VMware's hyper-call Date: Wed, 10 Sep 2014 13:25:04 -0400 Message-ID: <54108970.2020000@terremark.com> References: <1409585629-25840-1-git-send-email-dslutz@verizon.com> <1409585629-25840-4-git-send-email-dslutz@verizon.com> <1410183310.3680.28.camel@kazak.uk.xensource.com> <540DDFFB.2090504@terremark.com> <1410255363.8217.62.camel@kazak.uk.xensource.com> <540F3967.5060001@terremark.com> <1410341531.8217.262.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1410341531.8217.262.camel@kazak.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell , Don Slutz Cc: Kevin Tian , Keir Fraser , Jun Nakajima , Stefano Stabellini , Tim Deegan , Eddie Dong , xen-devel@lists.xen.org, Aravind Gopalakrishnan , Jan Beulich , Andrew Cooper , Suravee Suthikulpanit , Boris Ostrovsky , Ian Jackson List-Id: xen-devel@lists.xenproject.org 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 (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 >