VMware, Inc [Tue, 29 Mar 2011 18:51:10 +0000 (11:51 -0700)]
Unity/X11: Handle window titles encoded with COMPOUND_TEXT encoding.
COMPOUND_TEXT is a string type used to encode characters outside the
ASCII range, and it may be used to encode window titles. Unity/X11
ignored all such titles, so the host UI assumed there was no title.
Whoops.
This change employs GDK to do the heavy lifting for us.
VMware, Inc [Tue, 29 Mar 2011 18:51:00 +0000 (11:51 -0700)]
Unity/X11: Look up KDE applications with kde4- prefix.
Under OpenSUSE 11.2 (and possibly others), KDE applications' .desktop
files may be installed under /usr/share/applications/kde4, so in order
to find kcalc with Gio::DesktopAppInfo, we have to search for
"kde4-kcalc".
See http://standards.freedesktop.org/menu-spec/latest/ar01s04.html#menu-file-elements
for details.
VMware, Inc [Tue, 29 Mar 2011 18:50:34 +0000 (11:50 -0700)]
Fix disagreement on buffer sizes in guest info plugin.
The info cache only allowed 100 bytes (MAX_VALUE_LEN), while the buffer
that held the host name allowed 255 (to follow what the man page says).
Make both agree.
VMware, Inc [Tue, 29 Mar 2011 18:49:42 +0000 (11:49 -0700)]
This is part 12 of a change to support Nested VMs.
This part removes vmciUtil.* and vmciInt.h from the
guest driver and uses vmciDriver.* instead. I'm
cheating here, by copying some of the old vmciUtil
code into vmciDriver. The change after this will
unify more of the code.
Everything under common/guest is gone with this change.
VMware, Inc [Tue, 29 Mar 2011 18:49:01 +0000 (11:49 -0700)]
Introduce a connection timeout for VMCI stream sockets
When attempting to connect a VMCI Stream socket to a context,
where VMCI Sockets isn't loaded, the connecting process will
hang (or time out if the process itself has specified a
timeout on the connect). This change makes all connection
attempts default to time out after 2 seconds (on ESX, we
should be able to do about a thousand connection attempts in
that time period). For asynchronous connects, we schedule a
timeout function, that changes the socket state on failed
connection attempts and signals the error to the owner.
The connect timeout can be changed through a new VMCI Socket
specific socket option SO_VMCI_CONNECT_TIMEOUT. Testing of
this socket option and the timeout in general has added to the
sockoptVmciTest in the vsock test suite.
This change also makes VMCI Sockets on vmkernel report socket
errors in the read set on select to make UWs compatible with
Linux.
VMware, Inc [Tue, 29 Mar 2011 18:48:16 +0000 (11:48 -0700)]
Unify VMCI guest and host queue pair code.
This change unifies the two VMCI queue pair implementations
for guest and host. The main part of the change is moving the
guest functions to the host module, and add the use of the
VMCI routing function in the vmciQPair module to correctly
select either guest or host routes. For vmkernel, we still
disable most of the guest functionality, since the vmkernel
has its own implementation of much of the queue pair code
anyway. To reduce the vmkernel only part of the queue pair
code is left as a future clean up task.
Other notable changes were that for both Linux and Mac, the
host and guest tracked queue pairs differently
(VMCIQueueKernelIf). For Linux, it was straight forward to
combine the two at the cost of adding a pointer to the
VMCIQueueKernelIf structure in the guest. For Mac OS, the host
and the guest take completely different approaches, so the
unified VMCIQueueKernelIf is now a union of the host and guest
versions.
VMware, Inc [Tue, 29 Mar 2011 18:46:25 +0000 (11:46 -0700)]
Register new HgfsSeek function in file_operations structure.
Please check bug 667029 for more details. On Ubuntu 2.6.37, seek()
functions for any file residing in HGFS share fail with an error.
We are not registering any explicit function for llseek operation in
file_operations structure. This could be an issue with Ubuntu latest
release. Modified the code to design a new HgfsSeek function [ a
thin wrapper over generic_file_llseek()] and register that for
llseek operation in file_operations.
VMware, Inc [Tue, 29 Mar 2011 18:45:42 +0000 (11:45 -0700)]
This is part 11 of a change to support Nested VMs.
This unifies the doorbell code. We use the host doorbell
code, with resources and contexts, for both drivers. The
decision about where to deliver a doorbell is made using
the routing code that was added with the datagram
unification.
The majority of the changes are in vmciDoorbell.c.
VMware, Inc [Tue, 29 Mar 2011 18:44:49 +0000 (11:44 -0700)]
Do not install mount.vmhgfs as suid binary
There is no reason for mount.vmhgfs to be a uid binary, since it is
being called:
- by system startup scripts (so naturally we have enough privileges);
- by the system instance of vmtoolsd on behalf of vix api, and
vmtoolsd is running as root so does have enough privileges as well.
VMware, Inc [Tue, 29 Mar 2011 18:44:07 +0000 (11:44 -0700)]
Make Linux reference count vsock module on file ops.
Bug 681873 reports that the linux vsock module can be removed
while the vsock device is opened. The vsock file operations
registered with the device do not specify the module itself as
the owner, and therefore the kernel file operation code cannot
correctly reference count the module on open/close. This
change adds the vsock module as owner, which fixes the
issue. All other function tables registered, e.g., the socket
operations, do set the owner field (as does the VMCI kernel
module).
VMware, Inc [Tue, 29 Mar 2011 18:43:36 +0000 (11:43 -0700)]
Release VMCI context when determining route.
Forgot to release the context when we try to route
to a VM (which has a context) on a host. Release
the context so we do not leak it. Otherwise VMK
will panic when we destroy the heap.
VMware, Inc [Thu, 24 Feb 2011 23:01:12 +0000 (15:01 -0800)]
Unify the VMCI datagram code.
We now use the host datagram code, with resources and
contexts, for both drivers, with only a few tweaks.
We have a new component that performs routing, and using
the decision from that, we dispatch to host or guest as
appropriate.
There are obviously still some TODOs. We don't yet
create a context for the guest itself when acting as
a guest, and this is necessary to get the privs flags
right; for now, we steal the original guest code for
that. And getting the context ID is still determined
by which driver we build.
Most of this change is in vmciDatagram.c and vmciRoute.c;
the rest was necessary to get the files to compile for
both drivers, on all platforms. Bleh.
VMware, Inc [Thu, 24 Feb 2011 22:59:27 +0000 (14:59 -0800)]
Allow VMCI Socket connections between VM and host app of same user
VSockets created by a host process should be trusted to talk
to a VM started by the same user. This change implements this
by:
1) Storing a user identification of the user that created the
socket (the owner).
2) Making child socket inheret the owner.
3) Modify the notion of trusted in the VMCI Socket world to
include sockets created by the same user as the owner of
the VM.
Concerning step 3: Since the VMCI Socket modules notion of
trusted is now more inclusive than that of the VMCI kernel
module, all datagram handlers on the host are now registered
as trusted by the VMCI Socket module. The datagram handlers
themselves now perform the trusted check, and discards
datagrams accordingly. This was already the case for the
control datagrams for VMCI sockets, but now regular VMCI
Datagram sockets do the same. Since the check is not free (the
VMCI kernel module is likely to access hash tables and grab
locks to determine the owner of a context) - a one entry
"trust" cache has been created for each socket.
VMware, Inc [Thu, 24 Feb 2011 22:58:32 +0000 (14:58 -0800)]
Prepare guest VMCI queue pair code for unification
This change has no functional change but prepares the merging
of the guest and host queue pair code by:
1) renaming guest queue pair functions.
2) make the queue pair list functions take an argument, so
they can be used for both host and guest lists.
VMware, Inc [Thu, 24 Feb 2011 22:57:13 +0000 (14:57 -0800)]
Fix KDE file copy and paste.
There were a couple of bugs in how we respond to paste requests.
First, we can be called multiple times. So we needed a guard to
check if we are already in the process of transferring files.
Second, we should never clear the selection data unless we see an
error or fail case of some kind. While it does not affect GNOME
environment, looks like KDE can get really confused by this (the
symptom is a prompt for path name which has been reported often
in bugs over the past year I have been involved with DnD.)
VMware, Inc [Thu, 24 Feb 2011 22:55:09 +0000 (14:55 -0800)]
Fix closing of open handles for searches on "Shared Folders".
Our HGFS server callback from the vmdb for UI updates always
force closes any open handles that are not on any shares.
This was done even if no shares had been added or removed.
This had the side-effect of alwasy closing the handles of
searches for the base of the name space i.e. "Shared Folders"
folder. This meant a race where those clients could end up
getting invalid handle returned for a directory read of the
virtual folder. It is better to return possibly stale (unlikely)
shares for that directory read than always fail even if
no shares changed.
VMware, Inc [Thu, 24 Feb 2011 22:48:09 +0000 (14:48 -0800)]
Retire VMCIQueuePair_AllocPriv
Nothing uses VMCIQueuePair_Alloc anymore, since we got rid of
the non-privilege public version (VMCIQPair_Alloc always takes
privilege flags). This change deletes the old version of
VMCIQueuePair_Alloc and renames VMCIQueuePair_AllocPriv to
VMCIQueuePair_Alloc.
VMware, Inc [Thu, 24 Feb 2011 22:42:29 +0000 (14:42 -0800)]
GHI/X11: Don't pass NULL to strcmp.
Xdg_DetectDesktopEnv may return NULL, so its return value shouldn't be
passed to strcmp unchecked. Rather than checking ourselves, we'll
just g_strcmp0 do it for us.
VMware, Inc [Thu, 24 Feb 2011 22:39:23 +0000 (14:39 -0800)]
Implement capabilities for DnD/CP.
Implement capabilities exchange and add support for new isolation
settings in VMX. The general idea is that each side (host, guest)
transmits to the controller its capabilities (DnD/CP support,
ability to provide certain clipboard types) in a PING request. VMX
file settings can be used to disable a variety of clipboard content,
direction combinations. For example, RTF DnD in the guest to host
direction can be disabled. In the PING response, controller will
provide a requisition to the request, telling the host or guest
what types of DnD/CP content are allowed on the clipboard. When
preparing the clipboard for transmission, the host or guest checks
this requisition and will not supply formats that are not allowed.
The controller will enforce this by removing any clipboard contents
that do not match the published requisition, so in case the guest
or host does not do the right thing, or ignores the requisition in
the ping reply, the controller will catch it. If any of this
processing causes the clipboard received by the controller to be
empty, the DnD or CP operation does not continue.
VMware, Inc [Thu, 24 Feb 2011 22:04:22 +0000 (14:04 -0800)]
Hang in VMCISockets caused by uninitialized notification state.
It turns out that a recent unload/shutdown fix broke the
notification code.
We don't call the notification functions when the qpair
is invalid, to guard against touching the qpair after
the device has shutdown, but some of those functions
need to be called *before* a qpair is actually attached.
There are actually a few of them, so rather than introduce
a new macro for notifications that don't need qpairs,
I've removed the qpair check from the macros and embedded
it as necessary in the notification code.
We also uncovered a problem where if the notification
write window is less than a page we can underflow.
Fixed on all platforms.
VMware, Inc [Thu, 24 Feb 2011 21:59:47 +0000 (13:59 -0800)]
Reference count the VMCI device.
We must reference the device when we have clients
attached, for example HGFS or vsock. Changed
VMCI_DeviceGet() and VMCI_DeviceRelease() so that
they reference count, and added new function
VMCI_DeviceInUse() so that we can tell when the
device is referenced during a query-for-stop IRP
and fail if necessary.
VMware, Inc [Thu, 24 Feb 2011 21:49:12 +0000 (13:49 -0800)]
Always register VMCI Socket control message handlers on Linux
The VMCI Socket code on Linux only registers an address family
with the kernel as long as there are active sockets. As part
of registering/unregistrering the address family, the VMCI
Socket module also registers/unregisters the stream protocol
control message handlers. This results in no control message
processing being done, when there are no active sockets. For
peers attempting to connect this results in control messages
being silently dropped, and in the case of a connect, the
connect will just hang. This change moves the registration of
the control messages to the vsock module initialization, such
that control messages will always be handled even if there are
no active sockets.
Note that this change also makes the VMCI Socket module
loading fail, if the VMCI device isn't available. This isn't
strictly necessary, but the vsock module isn't all that useful
without the VMCI device.
VMware, Inc [Thu, 24 Feb 2011 21:47:15 +0000 (13:47 -0800)]
Wrap VMCI list operations
Both the guest and the host VMCI drivers use list operations,
that clash with other header files, e.g, circList.h. This
change wraps all list operations in the common modules, such
that we can decide on which list implementation to use on a
per platform basis.
VMware, Inc [Thu, 24 Feb 2011 21:41:32 +0000 (13:41 -0800)]
Panic_Panic needs to set mxInPanic flag
The userlock module relies on this flag to not get into a panic loop
from lock rank violation when we are trying to dump core. This is
the default Panic() implementation used by UI and other apps. For
other apps that stub out Panic(), they are not likely to use MXUser
locks.
VMware, Inc [Thu, 24 Feb 2011 21:36:27 +0000 (13:36 -0800)]
lib/lock: simplify rank checking while panicing
If we detect a rank violation in the locking code and we're not
already panicing, making a list of the locks held is quite
appropriate; the locking code will then explcitly panic.
If we panic due to a non-locking cause, rank violation checking and
list printing (but not panicing) can get pretty noisy - we have
ranks screwed up as we try to panic and/or coredump.
If the locking code is the source of a panic due to a rank violation
only print the first list; other things are highly likely to be
noise.
projects / thirdparty / open-vm-tools.git / log
