From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boris Ostrovsky Subject: Re: [PATCH v2 3/3] Add limited support of VMware's hyper-call Date: Tue, 09 Sep 2014 15:22:30 -0400 Message-ID: <540F5376.6020803@oracle.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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <540F3967.5060001@terremark.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: Don Slutz , Ian Campbell 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 , Ian Jackson List-Id: xen-devel@lists.xenproject.org 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 (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