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: Tue, 09 Sep 2014 13:31:19 -0400 Message-ID: <540F3967.5060001@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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1410255363.8217.62.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 , Eddie Dong , Stefano Stabellini , Ian Jackson , Tim Deegan , xen-devel@lists.xen.org, Jan Beulich , Aravind Gopalakrishnan , Jun Nakajima , Andrew Cooper , Boris Ostrovsky , Suravee Suthikulpanit List-Id: xen-devel@lists.xenproject.org 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). 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. > >