lib/file: retire the unsafe temp directory routines
Since all of the painful dependences have been clean remove there
is no longer a reason to have good and bad temp directory routines.
The unsafe versions go to the bit bucket.
We're hitting an ASSERT on shutdown. Code can
still have a socket open very late in the OS
shutdown sequence. VMCISockets forcibly closes
this socket so that it can safely unload. The
device I/O space is already gone at this point,
and with it the queuepairs. So we fail to
detach the queuepair, but we still ASSERT at
the VMCISocket level that we released it.
This occurs in both the common code (ESX,
Mac OS and Windows) and the Linux code.
At the VMCI level, we're actually leaking
when it fails, because we only release the
entry and qpair struct on success. There's
nothing a caller can do at that point, so we
should always release the entry and qpair
struct.
As of 2.6.39 merge window BKL and its header file (smp_lock.h)
have been removed from the kernel, so, to make out code
buildable we should remove the remaining traces of BKL in our
code.
lib/user, lib/file: move safe temp directory code to lib/file
Part of lib/file has been sitting, heavily entangled, in lib/user
for a long time. This prevents out code from always using safe
temporary directories.
These functions sat in lib/user but used lib/file functionality.
They are no more or less entangled living in lib/file and having
lib/file names than in lib/user - once the last lib/user entanglement
is removed.
It is now possible to untangle the functions and move them. This is
"heavy lifting" change. A follow on will remove the older, unsafe
versions from lib/file and our code base.
Stop using kmap for VMCI queue pair host side headers
The VMCI host driver for Linux does two kmaps for each active
queue pair. Since there is a limited number of kmap entries
for mapping high memory, convert the code to use vmap instead.
A while back, the VMCI hashtable code was made understand a
CID wildcard. However, the function verifying whether a handle
is already registered doesn't do wildcard matching on the
handles already in the database. This change rectifies that.
This doesn't really feel right, since the MNTINFO struct is not
unicode-ized. But other parts of the code already did it, and
it shuts up the symbol checker.
Also reorganize the code a little bit. ZFS doesn't really look like a
normal disk, so we'll just assume it's living in a VMDK (not that we
really check for that for other FSes). Users can probably shoot
themselves in the foot a lot easier with ZFS by attaching storage
to existing volumes and doing other crazy things ZFS allows, but
hey, if they want to do it...
Make commonly used rotuines free of complex dependencies.
I choose to name the new file "StandAlone" since, over time,
many routines, including those not specifically manipulating
path string, will move here.
VMware, Inc [Tue, 29 Mar 2011 20:28:35 +0000 (13:28 -0700)]
HGFS: handle the RCU-based path walk mode on 2.6.38
2.6.38 introduced a new, lock-less path walk mode called RCU walk.
It is used by default and file system code is supposed return
-ECHILD if permission check requires sleeping. Do that, otherwise
bad things may happen.
Also adapt to the new APIs of 2.6.39-rc0 (smp_lock.h is gone,
get_sb method in file_system_type structure replaced with
mount method, dentry->d_count is not an atomic anymore,
SPIN_LOCK_UNLOCKED is not there as well).
VMware, Inc [Tue, 29 Mar 2011 20:27:57 +0000 (13:27 -0700)]
Fix non-glib rpcin code.
For non-glib tools, set in->nextEvent to NULL as soon as we enter
RpcInLoop. This is important, since in->nextEvent and the next
pointer in EventManager_ProcessNext point to the same Event struct
when we enter the function, and EventManager_ProcessNext frees the
pointer after RpcInLoop exits, so freeing it in RpcInLoop results in
a double-free and corrupts the heap. This can happen if RpcInStop is
called at the end of the loop in response to a call to RpcIn_stop
from inside cb->callback.
Also, after re-reading the glib docs and consulting with others, fix
how we manage the lifetime of the GSource used to run the RpcInLoop
in the glib case. If we are stopping the loop from _inside_ the
loop, then we need to unref the source but _not_ destroy it; instead
we should return FALSE so that the g_main_loop with also unref it
(and hence destroy it). If we are stopping the loop from outside the
loop, then the source must be destroyed (to get the g_main_loop to
release its ref) and then unref'd (to release our ref). Finally if
we do not reschedule the timer while running the loop (because the
timeout hasn't changed) then we must return TRUE so that the source
will remain attached to the g_main_loop.
VMware, Inc [Tue, 29 Mar 2011 20:25:10 +0000 (13:25 -0700)]
This is part 17 (this is getting ridiculous) of a
change to support Nested VMs.
This change switches over the HasPeronality() and
DeviceEnabled() rules to match those of the Linux
driver. This allows it to handle *always* having
two devices in a guest, even if a hosted product
is not installed, which is now a restriction
imposed by the installer.
DeviceShutdown() and InUse() are redundant on
platforms that don't have retarded stop/removal
rules, so moved that functionality out of the
common code and into the Windows driver code.
VMware, Inc [Tue, 29 Mar 2011 20:23:40 +0000 (13:23 -0700)]
Linux host modules: use DEFINE_SPINLOCK()/DEFINE_RWLOCK()
SPIN_LOCK_UNLOCKED/RW_LOCK_UNLOCKED have been removed from
2.6.39-rc0 so we can't use them anymore. Let's switch to
DEFINE_SPINLOCK/DEFINE_RWLOCK instead. Even though they are
not present on kernels before 2.6.11 we can easily add them
to the compat code.
DEFINE_SPINLOCK() does not allow to decorate spinlocks with
attributes but as far as I can see we do not really need to
mark them as "unused" with the newer (or maybe 'not ancient')
spinlock code.
Also remove some old compat code from compat_spinlock.h
VMware, Inc [Tue, 29 Mar 2011 20:20:59 +0000 (13:20 -0700)]
Rename VMCI_Has*Device to VMCI_*PersonalityActive
Since the host device is more or less always there and since
it isn't really a device, the name VMCI_HasHostDevice is kind
of misleading. Rename the two functions to mean that the given
personality of the vmci driver is active.
VMware, Inc [Tue, 29 Mar 2011 20:20:49 +0000 (13:20 -0700)]
Check for other hypervisors before checking for the backdoor.
Some hypervisors don't seem to like when we try to access our backdoor.
To avoid issues, check for them before trying that, and fail the
"virtual world" check if they're detected.
VMware, Inc [Tue, 29 Mar 2011 20:20:39 +0000 (13:20 -0700)]
lib/misc: move hypervisor-related functions into a new file.
While working on bug 692831, the "checkvm" utility was changed to call some
Hostinfo functions. The compilation unit where those functions lived
referenced a whole bunch of other symbols that ended up pulling lib/unicode
into checkvm.
That made the binary size blow up from 5kB to 450kB, stripped.
Putting these functions into a separate compilation unit avoids that issue,
and makes the binary grow much less (it's now ~45kB).
VMware, Inc [Tue, 29 Mar 2011 20:19:20 +0000 (13:19 -0700)]
Make VMCI Linux driver support host and guest concurrently
This change makes the VMCI Linux driver enable both the guest
and host driver functionality as appropriate. The host driver
part will always be initialized, but to limit its exposure in
guests not used as a virtual host as well, we adopt the
following behaviour for VMCI_HasHostDevice:
- if there is no VMCI PCI device, VMCI_HasHostDevice()
returns TRUE if it has been initialized.
- if there is a VMCI PCI device, VMCI_HasHostDevice()
returns TRUE iff theere are active contexts.
This will make the default behaviour in non-nested cases the
same as prior to this change.
In the nested VM case, we may have VMCI clients, that use
resources as a host endpoint, before any contexts have been
created, e.g., allocating a doorbell before any VMs are
started. The VMCI_HasHostDevice() check has been removed from
the doorbell creation code to allow for this case.
VMware, Inc [Tue, 29 Mar 2011 20:18:50 +0000 (13:18 -0700)]
desktopEvents: Tell the session manager it should not start us when relaunching a session.
A session as defined by an X Session Manager is a collection of applications and
some state such that this collection may be recreated arbitrarily in the future.
For example, a developer may define a development session consisting of an
instance of Emacs and a web browser pointing to some documentation. Rather than
relaunch both apps upon each login, s/he could define a "happyfundev" session
and select that to launch that collection of apps at any time.
One requirement of being managed by a session manager is that one must provide
add'l metadata to the session manager to support this restart/restore case.
However, when the session manager relaunches applications as part of a recorded
session, it doesn't record anything about the environment -- instead, each
application must persist as much of the environment it needs by itself.
In our case, we rely on the environment set up by (ironically) the session
manager during its autostart phase in order to launch correctly. (E.g., we
rely on environment variables like KDE_FULL_SESSION to determine that we're
running under KDE.) Since vmusr gains nothing from being restartable via the
session manager, we'd rather inform the session manager NOT to restore vmusr
as part of any desktop session. Instead, it should continue to only launch
as part of the XDG autostart phase.
Without doing this, there is a race between two instances of vmusr launching:
one from the autostart phase and one from the session restore phase. If the
session restore instance wins, things break.
VMware, Inc [Tue, 29 Mar 2011 20:17:24 +0000 (13:17 -0700)]
unity/X11: Exit Unity upon notice of session termination.
During session termination, not exiting Unity until vmusr unloads the
plugin is racy. By the time the Unity shutdown routine executes, it's
possible that the X server has already terminated (or at least severed
our connection to it). Instead of waiting until then, we'll instead
exit Unity as soon as vmusr is alerted of a pending session termination,
_before_ vmusr returns its acknowledgement to the session manager.
VMware, Inc [Tue, 29 Mar 2011 20:17:07 +0000 (13:17 -0700)]
Unity/X11: Guess at menu-spec desktop ID prefixes when searching for apps.
Consider this:
- menu-spec <AppDir> root is /usr/share/applications.
- .desktop files found in that directory are assigned IDs of the form
basename($foo).desktop.
- .desktop files in subdirectories are assigned IDs of the form
{
$subdir =~ s|/|-|g;
return sprintf("%s-%s", $subdir, basename($foo));
}
The problem with the newish WindowPathFactory is that it didn't take
application prefixes into account. So, when trying to find a .desktop
file for (e.g.) kcalc, it incorrectly guessed at "kcalc.desktop" instead
of "kde4-kcalc.desktop".
This change hackily inserts a fixed set of prefixes (currently "" and
"kde4-") when searching for .desktop files. As a result, we do a much
better job of identifying KDE apps. (Ideally we would discover the
prefixes when trawling $XDG_DATA_DIRS/applications to compile menus,
but this will have to do for now.)
VMware, Inc [Tue, 29 Mar 2011 20:16:20 +0000 (13:16 -0700)]
desktopEvents: Reflect XSM callbacks as GLib signals.
This change defines 4 new signals, one for each of the XSM client
callbacks. Each callback now emits its corresponding signal. I
added it to allow the Unity plugin to terminate Unity upon notice
of session shutdown.
Additional context from review request:
When exiting Unity, we must restore misc desktop properties (ex:
screensaver, taskbar visiblity) to their pre-Unity state. This requires
communication with the X server.
As plugins are loaded and their shutdown signals connected in
alphabetical order by plugin name, desktopEvents's shutdown routine
executes before unity's. Once desktopEvents calls SmcCloseConnection,
the session manager considers vmusr's shutdown procedure complete,
and it may terminate, killing the X server. In our case, the X server
may have died while remaining vmusr plugins still execute shutdown code.
The change allows all X clients to clean up _before_ we signal the X
server that we're good to go.
VMware, Inc [Tue, 29 Mar 2011 20:14:54 +0000 (13:14 -0700)]
This is part 16 of a change to support Nested VMs.
This change fixes some small bugs in the unified
Windows driver (unitialized fields, wrong VMX path).
It also removes some more references to VMX86_TOOLS.
VMware, Inc [Tue, 29 Mar 2011 20:14:16 +0000 (13:14 -0700)]
Make VMCI_HasGuestDevice safe while atomic on Linux
VMCI_HasGuestDevice() would be called from interrupt context,
and could grab a mutex. This change rewrites the code to be
safe from interrupt context as well. At the same time,
VMCI_DeviceEnabled has been changed to cover both guest and
host devices.
VMware, Inc [Tue, 29 Mar 2011 20:13:01 +0000 (13:13 -0700)]
Make VMCI Stream Sockets use control packet destination for binding.
When creating a VMCI stream socket connection, the protocol
calls VMCI_GetContextID() to set the local CID of a
connection. However, in the nested VM case, this may no longer
be correct, since a given connection can either be a host CID
endpoint or a guest CID endpoint. Instead, we can use an
incoming control packet to determine what destination CID the
peer is using when sending to us, and use that as our local CID.
For server side sockets, the change is simple - instead of
calling VMCI_GetContextID() to set the local CID when
receiving a request packet, we use the dst cid of the
packet. For the client side, we delay the assignment of the
local CID until we receive the negotiate packet from the
server side. Until then, a connecting socket will continue to
have the local CID of any - just like a listening
socket. Since all sockets share the same port range regardless
of their CID, no additional port conflicts will arise from
this.
VMware, Inc [Tue, 29 Mar 2011 20:10:58 +0000 (13:10 -0700)]
Fix a crash when calling RpcIn_stop.
If an RpcInLoop callback calls RpcIn_stop, then the state of the RpcIn
struct becomes corrupt (we have a timer but no channel), leading to a
crash the next time the RpcInLoop runs. One way this can happen on
Windows VMs is if we pump the main thread's message queue from inside
an RPC handler, since we will call RpcIn_stop in response to a
WM_WTSSESSION_CHANGE message.
To fix this, we set an inLoop var in the RpcIn struct at the start of
the RpcInLoop function. RpcIn_stop checks the var, and if it is true,
it sets a shouldStop to TRUE instead of stopping the channel itself.
When we eventually exit the RpcInLoop function, we check shouldStop
and stop the RPC channel if it is true.
This obviously only works if RpcIn_stop and RpcInLoop are called on
the same thread, but RpcIn is not thread-safe to being with, so there
didn't seem to be any point in trying to fix this problem for that
case.
VMware, Inc [Tue, 29 Mar 2011 20:10:44 +0000 (13:10 -0700)]
Merge Linux VMCI guest and host driver code
This change merges the code for the Linux specific part of the
VMCI driver. The change has two parts: one is the merging of
the actual code of the drivers, and the other is changing the
host and guest makefiles to pick up the VMCI driver files from
the same place.
The actual merging of the Linux driver code is mainly a code
movement from the guest driver to the host driver. Currently,
the driver will still be either guest or host, based on the
flag isGuestDriver which gets controlled by whether
VMX86_TOOLS is defined. All code is now compiled regardless of
whether the driver is guest or host.
VMware, Inc [Tue, 29 Mar 2011 20:09:25 +0000 (13:09 -0700)]
Extend vmciRoute with hypervisor to host routing.
The vmci routing function was defaulting to
VMCI_ROUTE_AS_GUEST, when the hypervisor is the source and the
host is the destination. However, vmci events generated
locally on the host are sent from hypervisor to host, and
should be routed as host communication. Also, a guest would
never use the hypervisor context ID as the source, so there is
no ambiguity.
VMware, Inc [Tue, 29 Mar 2011 20:09:08 +0000 (13:09 -0700)]
Fixing deadlock that occurs when cancelling unarchiving.
When MacOS mutex is acquired recursively by the same thread a deadlock occurs.
Thus it is unsafe to hold a mutex that is maintained by HGFS while invoking a
system call that may result in recursively calling a vnode method which may
in turn try to acquire the same mutex.
Particulary vnode hash table mutex should be released before invoking a
HgfsFreeFile function that invokes vnode_rele which may in turn call
inavtivate or reclaim vnode methods.
Current implementation still calls vnode_get while holding the mutex. It is OK,
since vnode_get just increases reference count and it never result in
recursive call into HGFS.
VMware, Inc [Tue, 29 Mar 2011 20:08:12 +0000 (13:08 -0700)]
[unity win32] Fix UAC full screen window.
Connect the unity plugin to the TOOLS_CORE_SIG_DESKTOP_SWITCH
signal, and use it to add/remove the 'fake' full screen window
to the UnityWindowTracker when UAC prompt is visible.
VMware, Inc [Tue, 29 Mar 2011 20:07:51 +0000 (13:07 -0700)]
Un*x session management integration via desktopEvents
So we have this guest agent, vmusr, which runs in the context of graphical
desktop sessions. It's intended to run for the duration of the session,
which is normally fine, but it has a nasty habit of overstaying its
welcome. Our gracious host, the session manager, politely asks its guests
to leave, but vmusr just doesn't wanna listen.
Rather than stick around until the X server terminates, this change
introduces integration with XSM-compliant[1] session managers such
that, in response to a heads-up from the manager, we can exit cleanly.
libSM and libICE are used to get the job done.
libICE clients use their own connections, and they're managed via a
custom GSource. For now, this desktopEvents feature is the only libICE
client, so rather than go overboard and deal with ICE in a separate
provider plugin, all ICE-GLib connection management is handled here.
Additionally, I changed up the Desktop Events features' mini API to
keep a GHashTable as the plugin's private data. Each mini feature may
add its own private data to that hash using the feature's name as a
key.
VMware, Inc [Tue, 29 Mar 2011 20:07:22 +0000 (13:07 -0700)]
vmblock: fix problem with missing Panic symbol on FreeBSD
We need to make sure we compile and link stubs.c so that
out Panic() resolves. And since FreeBSD does not have panic
that takes va_list arguments we need to implement one.
VMware, Inc [Tue, 29 Mar 2011 20:05:29 +0000 (13:05 -0700)]
This is part 14 of a change to support Nested VMs.
This part adds more support for the host device in the
guest driver. You can now add a host device to a guest.
The VMX IOCTLs will still fail, but at least we do
the access checking now.
This also adds all the new device names, along with the
general interface, which allows things like getting the
CID, attaching to vsock etc.
One final change is to the wrapper for allocating
kernel memory. See the comment in vmci_kernel_if for
a full explanation.
VMware, Inc [Tue, 29 Mar 2011 20:01:30 +0000 (13:01 -0700)]
GHI/X11: Strip window IDs passed to GHI_GetBinaryInfo.
The query portion of these URIs confused GHI/X11 such that it didn't
recognize regular .desktop files. This led to many failures to
return application names and icons.
VMware, Inc [Tue, 29 Mar 2011 20:01:06 +0000 (13:01 -0700)]
Unity: Fix the set desktop work area parser.
The desktop work area parser code was touched when it was factored out
of lib/unity/unity.c to services/plugins/unity/unityTclo.cpp. This
introduced a bug where the same work area was processed repeatedly
rather than parsing subsequent work areas.
VMware, Inc [Tue, 29 Mar 2011 19:59:35 +0000 (12:59 -0700)]
GHI/X11: Scale icons to fit in GuestMsg transport.
GHI/X11 used to scale icons down to fit over the backdoor. The scaling
was stripped when alternate icon transport was introduced for Windows,
since transport details shouldn't be handled at this level.
In a perfect world, I'd leave it to GHI's TCLO layer to handle scaling
to fit within GuestMsg limits, but that's more of a PITA to add than
it's worth. So, instead, I'm taking the easy/lame way out and down-
scaling icons at the source, relying on GdkPixbuf's scaling routines
to do the heavy lifting. (NB: This is just bringing back our old
scaling code.)
VMware, Inc [Tue, 29 Mar 2011 19:58:14 +0000 (12:58 -0700)]
Translate EEXIST into ENOTEMPTY for Posix guests.
When the user executes DeleteDirectoryInGuest api with recursiveflag set to
FALSE, vix code calls File_DeleteEmptDirectory() and it internally calls
rmdir() function. If the specified directory is not empty, rmdir fails and
errno is set to different values on linux and solaris. To maintain
consistency, modified the code to translate EEXIST into ENOTEMPTY error
for Posix guests.
VMware, Inc [Tue, 29 Mar 2011 18:56:33 +0000 (11:56 -0700)]
Split VMCI_Init() into shared and host part.
The initialization routine for the VMCI components in
vmciDriver.c covers both components shared between guest and
host, and components only relevant to the host. This change
splits them into two routines, and updates the host drivers to
use the new two routines.
VMware, Inc [Tue, 29 Mar 2011 18:54:50 +0000 (11:54 -0700)]
Do not toggle vmblock from vmware-user-suid-wrapper
Utilize the new mount utility instead and perform all
manipulations from the system startup scripts, thus not
giving malicious users chance to exploit races between
performing ownership checks and changing permissons and
mounting.
VMware, Inc [Tue, 29 Mar 2011 18:54:30 +0000 (11:54 -0700)]
Remove vmciGuestKernelIf.c on Linux, Windows, Solaris
This change moves the functionality of vmciGuestKernelIf.c to
vmciKernelIf.c on all guest platforms except MacOS. On MacOS,
the functionality in vmciGuestKernelIf.cpp is more tightly
coupled with the methods exported by the driver object, so
that is left alone for now. Added compat_pci.h and
compat_ioport.h to host driver tarball.
VMware, Inc [Tue, 29 Mar 2011 18:54:21 +0000 (11:54 -0700)]
Unity/X11: Gracefully handle NULL desktop work area RPCs.
Should the host UI issue an RPC like
unity.desktop.work_area.set 0
Unity/X11 will explode with a NULL pointer dereference, because of
an incorrect assumption that there would be at least 1 parameter.