All of lore.kernel.org
 help / color / mirror / Atom feed
From: Don Slutz <dslutz@verizon.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, Don Slutz <dslutz@verizon.com>
Cc: Tim Deegan <tim@xen.org>, Kevin Tian <kevin.tian@intel.com>,
	Keir Fraser <keir@xen.org>, Jun Nakajima <jun.nakajima@intel.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Eddie Dong <eddie.dong@intel.com>,
	xen-devel@lists.xen.org,
	Aravind Gopalakrishnan <Aravind.Gopalakrishnan@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Subject: Re: [PATCH v2 3/3] Add limited support of VMware's hyper-call
Date: Mon, 08 Sep 2014 12:57:31 -0400	[thread overview]
Message-ID: <540DDFFB.2090504@terremark.com> (raw)
In-Reply-To: <1410183310.3680.28.camel@kazak.uk.xensource.com>


On 09/08/14 09:35, Ian Campbell wrote:
> On Mon, 2014-09-01 at 11:33 -0400, Don Slutz wrote:
>> This is both a more complete support then in currently provided by
>> QEMU and/or KVM and less.  The missing part requires QEMU changes
>> and has been left out until the QEMU patches are accepted upstream.
>>
>> VMware's hyper-call is also known as VMware Backdoor I/O Port.
>>
>> Note: this support does not depend on vmware_hw being non-zero.
>>
>> Summary is that VMware treats "IN EAX, DX" (or "OUT DX, EAX"; or
>> "inl %dx, %eax" in AT&T syntax ) to port 0x5658 specially.  Note:
>> since many operations return data in EAX, "OUT DX, EAX" does not
>> work for them on VMware, I did not support the "OUT DX, EAX", but it
>> would not be hard to add.
> Quite a bit of this changelog seems to concern itself with the
> differences between Intel and AT&T as syntax. Please can you just use
> the same AT&T syntax as are used in Xen's own .S files throughout (and
> without the need to comment on there being other syntaxes).
>

Ok, Will adjust to have only AT&T syntax.

>> 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.

>
>> 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.

>> If the domU is running VMware tools, then the "build version" of
>> the tools is also available via xc_get_HVM_param().  This also
> It's just xc_get_hvm_param(), isn't it?
>

Yes. looks like a typo.


>> +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.

>> +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.

Hope this helps.
     -Don Slutz


> Ian.
>

  reply	other threads:[~2014-09-08 16:57 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-01 15:33 [PATCH v2 0/3] Xen VMware tools support Don Slutz
2014-09-01 15:33 ` [PATCH v2 1/3] Add vmware_hw to xl.cfg Don Slutz
2014-09-02  7:28   ` Jan Beulich
2014-09-02 18:24     ` Don Slutz
2014-09-03  7:45       ` Jan Beulich
2014-09-03 10:59         ` Don Slutz
2014-09-03 12:33           ` Jan Beulich
2014-09-03 12:51             ` Don Slutz
2014-09-08 13:21           ` Ian Campbell
2014-09-08 13:47             ` Don Slutz
2014-09-08 13:55               ` Ian Campbell
2014-09-08 13:20         ` Ian Campbell
2014-09-08 13:56           ` Don Slutz
2014-09-08 14:07             ` Andrew Cooper
2014-09-08 18:39               ` Don Slutz
2014-09-08 22:11               ` Don Slutz
2014-09-08 23:34                 ` Andrew Cooper
2014-09-08 14:21             ` Jan Beulich
2014-09-08 15:16               ` Boris Ostrovsky
2014-09-08 15:27                 ` Jan Beulich
2014-09-08 22:41                   ` Don Slutz
2014-09-08 13:17   ` Ian Campbell
2014-09-08 13:27     ` Andrew Cooper
2014-09-08 13:41       ` Ian Campbell
2014-09-08 14:18         ` Don Slutz
2014-09-08 19:16     ` Don Slutz
2014-09-09  9:39       ` Ian Campbell
2014-09-09 17:02         ` Don Slutz
2014-09-10  9:30           ` Ian Campbell
2014-09-10 17:44             ` Don Slutz
2014-09-12 12:25             ` Slutz, Donald Christopher
2014-09-08 22:14     ` Don Slutz
2014-09-01 15:33 ` [PATCH v2 2/3] vmport: Add VMware provided include files Don Slutz
2014-09-02  7:34   ` Jan Beulich
2014-09-02 18:46     ` Don Slutz
2014-09-03  7:51       ` Jan Beulich
2014-09-03 12:38         ` Don Slutz
2014-09-01 15:33 ` [PATCH v2 3/3] Add limited support of VMware's hyper-call Don Slutz
2014-09-02  8:16   ` Jan Beulich
2014-09-03  0:55     ` Don Slutz
2014-09-03  8:25       ` Jan Beulich
2014-09-03 18:28         ` Don Slutz
2014-09-08 13:35   ` Ian Campbell
2014-09-08 16:57     ` Don Slutz [this message]
2014-09-09  9:36       ` Ian Campbell
2014-09-09 17:31         ` Don Slutz
2014-09-09 19:22           ` Boris Ostrovsky
2014-09-10  9:32           ` Ian Campbell
2014-09-10 17:25             ` Don Slutz
2014-09-01 16:10 ` [PATCH v2 0/3] Xen VMware tools support Jan Beulich
2014-09-01 18:14   ` Don Slutz
2014-09-08 13:03 ` Ian Campbell
2014-09-08 13:18   ` Don Slutz
2014-09-08 13:42     ` Ian Campbell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=540DDFFB.2090504@terremark.com \
    --to=dslutz@verizon.com \
    --cc=Aravind.Gopalakrishnan@amd.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=eddie.dong@intel.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=jbeulich@suse.com \
    --cc=jun.nakajima@intel.com \
    --cc=keir@xen.org \
    --cc=kevin.tian@intel.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=suravee.suthikulpanit@amd.com \
    --cc=tim@xen.org \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.