Re: [open-vm-tools-devel] VMTools for other OSes

[Anthony L. <an...@co...>]

Adar Dembo wrote:
> Most of the people behind this project are busy with VMworld this week, but
> I'll try to answer your questions as best I can.
>   

No worries, I'm not surprised ya'll are busy :-)

>> 2) The current thinking in the kernel community is that we'll converge
>> on virtio based paravirtual devices.  I haven't looked at the VMware
>> transports deeply enough to know yet whether they would fit 
>> nicely into
>> the virtio model but my suspicion is that they could.  Is 
>> there interest
>> in this?
>>     
>
> I think there's definitely interest in using virtio, though I'm not familiar
> enough with virtio (or with some of our virtual devices) to really judge
> whether it'll be easy or not. Here's a brief description of the VMware
> transports I am familiar with:
>
> The majority of the Tools currently rely on a single transport mechanism
> which is (somewhat inappropriately) called the 'Tools backdoor'. It uses
> 'out' (4 bytes) or 'rep out' (up to a page, I think) to send data to the VMM
> and is callable at any CPL.

It's inl/ins actually.

>  We've built 'GuestMsg' on top of the backdoor,
> which can exchange arbitrarily-long data with the VMM, and then 'GuestRpc' on
> top of GuestMsg, which provides a very primitive string-baed RPC mechanism.
> The backdoor itself isn't interrupt driven, so apps must poll for receipt of
> messages (GuestRpc provides some facilities to do that).
>
> The backdoor-based transport is quite old and inflexible, so we built VMCI
> (Virtual Machine Communication Interface) as a replacement. I'm not very
> familiar with it, but I do know that it's a PCI device that exports
> hypercalls to the host, guestcalls back to the guest, and higher level APIs
> (such as shared memory and datagrams). We haven't yet transitioned any of the
> Tools to run on VMCI, because the VMCI APIs (and the design, to an extent)
> are still under development, which is, incidentally, also why it was marked
> 'experimental' in Workstation 6 and why the guest driver isn't yet open
> sourced.
>   

The backdoor stuff is pretty gnarly since it relies on something that 
isn't available on other architectures (PIO in userspace).  One thing 
I'm interested in is how portable all this stuff is to non-x86 
architectures.  A PCI device with something exposed to userspace 
(preferably as a socket) would definitely be best.

> As I said above, all of the Tools components use the backdoor or one of its
> higher layers. The exception is vmxnet, which is also implemented as a
> paravirtualized PCI device but, once again, I don't know enough about it to
> be of much use. 
>
> I'll try and get you some more concrete information about integrating with
> virtio (or at least put you in touch with the appropriate developers).
>
>   
>> 3) The last time I checked, the EULA around the VMTools for other
>> platforms (namely, Windows), prevented the use of the drivers in other
>> VMMs.  That limits the utility of implementing these 
>> interfaces in other
>> VMMs.  Are there any plans to adjust the EULA for other platforms?
>>     
>
> I don't think this should be an issue, because we manage the EULAs on a
> per-product basis. So the EULA that applies to, say, Workstation 6, should
> not apply to this release (or the drivers therein) at all.
>
> I'll double check with our legal team and get back to you on this.
>   

What would be ideal is if VMware could provide a VM-Tools ISO for 
Windows that contained the various PV drivers with a non-restrictive 
EULA.  Namely, that it could be redistributed by anyone and could be 
used for anything.  Providing source code for Windows drivers is not 
easy as far as I've been told so I think it's understandable if it was 
binary-only.

Regards,

Anthony Liguori

> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> open-vm-tools-devel mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/open-vm-tools-devel
>
>