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.
> First, let me start by thanking you all for publishing these. We
> currently implement vmmouse and vmware vga emulation in QEMU and I'd
> love to do more now that more guest drivers are available.
That's awesome, we're definitely looking forward to porting the drivers =
(and
other components, if they'd prove useful) to other hypervisors.
> I have three questions:
>=20
> 1) A lot of the kernel code appears to not be written for upstream
> inclusion. Are there plans to work on getting the drivers more into
> shape so they could realistically be merged into Linux?
Yes, that's definitely the plan, but as you said, a lot of work needs to =
be
done. The fairly simple but tedious tasks:
1) The VMware coding style is much different than the Linux kernel =
coding
style. Maybe we can automatically convert this.
2) There's a ton of code in the drivers to handle older kernels that =
isn't
necessary upstream.
Then there may be some more difficult design issues (like the one you =
raised
about vmblock in a later e-mail) that need to be looked at.
If you feel like taking this on, we'd definitely apciate the =
patches...
> 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=20
> nicely into
> the virtio model but my suspicion is that they could. Is=20
> 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. 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.
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.=20
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), vented the use of the drivers in other
> VMMs. That limits the utility of implementing these=20
> 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.
|
