VMware, Inc [Thu, 17 Jun 2010 21:20:34 +0000 (14:20 -0700)]
Consistent, unambiguous, non-colliding bit function names
We don't have complete set of find most/least significant bit
set functions available throughout the source base. Create them.
I created these functions by taking the monitor's complete set of
functions, moving them to vm_basic_asm.h and renaming them such that
they have consistent, unambiguous names that don't collide with ANSI,
Linux or MacOS functions or differ in data types. The immediately
problematic functions were ffs, fls, ffsl, flsl and fls64.
Here is a table to assist with reviewing the change:
NAME FUNCTION BITS ON ZERO MONITOR NAME
----- -------- ---- ------- ------------
lssb32 LSB set (uint32) 1..32 0 ffs
lssb32_0 LSB set (uint32) 0..31 -1 ffs0
lssb64 LSB set (uint64) 1..64 0 ffs64
lssb64_0 LSB set (uint64) 0..63 -1
lssbPtr LSB set (uintptr_t) 1..32|64 0 ffsl
lssbPtr_0 LSB set (uintptr_t) 0..31|63 -1 ffs0l
mssb32 MSB set (uint32) 1..32 0 fls
mssb32_0 MSB set (uint32) 0..31 -1 fls0
mssb64 MSB set (uint64) 1..64 0 fls64
mssb64_0 MSB set (uint64) 0..63 -1
mssbPtr MSB set (uintptr_t) 1..32|64 0 flsl
mssbPtr_0 MSB set (uintptr_t) 0..31|63 -1 fls0l
This change is the first of several. It establishes the functions and
make one use of them in an obvious, easy place.
I'll start converting the source base to use these functions in pieces.
The monitor will be the last piece touched and there I'll demonstrate
no size or performance changes - and correctness too.
In the end the entire source base will be using the one consistent set
of bit functions.
VMware, Inc [Thu, 17 Jun 2010 21:19:02 +0000 (14:19 -0700)]
Let hgfsServer use MXUser locks directly
hgfsServer avoided pulling in MXUser locks when VMTOOLS_USE_GLIB was set.
Mark Bellon put together a change to split MX and MXUser locks so MXUser
can be used in tools. This follow-on change lets hgfsServer use MXUser
locks directly.
VMware, Inc [Thu, 17 Jun 2010 21:18:23 +0000 (14:18 -0700)]
Upper-bound some gcc workarounds in public/vm_basic_*
Put an upper bound on a few gcc workarounds.
vm_basic_defs.h / GetFrameAddr()
See bug 554369 for details; this bug was fixed in gcc-4.2.0,
so apply that upper bound.
vm_basic_types.h / INLINE_SINGLE_CALLER
Verified that it occurs for gcc-4.4.3. This attribute is
now well-documented; it is no longer necessary to check
at each compiler bump.
VMware, Inc [Thu, 17 Jun 2010 21:16:33 +0000 (14:16 -0700)]
Try to alloc from lower 4GB rather than lower 16 MB
Could call pci_set[consistent_]_dma_mask but the defaults
already seem to fit what vmxnet supports and I have no
idea when these functions first appeared in the kernel.
VMware, Inc [Thu, 17 Jun 2010 21:14:27 +0000 (14:14 -0700)]
Use new print functions in remaining toolbox cli commands, add i18n.
. use ToolsCmd_Print / ToolsCmd_PrintErr everywhere they make sense, to
make the "quiet" flag consistent.
. i18n'ize all user-visible messages (except the ones coming from external
libraries).
. all commands that have boolean output can have the output suppressed, and
the status can be figured out from the exit value (EXIT_SUCCESS for TRUE,
EX_UNAVAILABLE for FALSE).
. fix stat command error messages which all printed the same thing.
. a few minor stylistic changes to messages.
VMware, Inc [Thu, 17 Jun 2010 21:14:06 +0000 (14:14 -0700)]
Don't crash when reconfiguring file log handler.
The log code has a log statement that prints info about the core dump
config; when using the file handler, and swithing between "no logging"
and "log enabled", the new log data would then open the log file; later,
when restoring the previous log config, that would cause an assert.
Fix is easy: just change the order in which those things are done.
VMware, Inc [Thu, 17 Jun 2010 21:13:15 +0000 (14:13 -0700)]
lib/lock: propogate rank inform when binding to MX
The binding MX to MXUser functions need to propogate the rank
information into the MXUser lock header since the MXUser
"get the rank" function takes the rank information from there.
Some code gets the rank (for asserts and other sundry things)
from the MX lock directly and some from the MXUser lock.
VMware, Inc [Thu, 17 Jun 2010 21:12:27 +0000 (14:12 -0700)]
Change Linux kernel version check to 2.6.32 to fix build error.
While creating PBMs for Ubuntu 10.04 RC, which is a 2.6.32-21.32
kernel, we were getting a compile-time error due to type mismatch
for the setsockopt prototype. An earlier change to this file assumed
that the error would occur on 2.6.34 or later, but in fact it is
a problem starting with 2.6.32-rc3.
VMware, Inc [Thu, 17 Jun 2010 21:11:54 +0000 (14:11 -0700)]
lib/lock: press for a harder MX/MXUser separation
Since there is a function for MX to register hook functions with
MXUser, enhance it to provide additional function that allow
removing even more MX references throughout MXUser.
This change makes it possible to expose the bind MX to MXUser
functionality to userland - we can use that functionality outside
the VMX now.
The mutex.h and userlock.h include files are tweaked so that things
work properly if either of them comes first and the userlock.h file
is able to stand on its own inside and outside the VMX.
VMware, Inc [Thu, 17 Jun 2010 21:10:57 +0000 (14:10 -0700)]
lib/lock: assertion failure
The new hook function implanting function caught a panic when it
was invocated a second time. Make the function tolerate multiple
invocations, only panicing if the later invocations attempt to
plant hook functions different than the first time.
VMware, Inc [Thu, 17 Jun 2010 21:05:56 +0000 (14:05 -0700)]
Add auto-upgrade command to toolbox CLI.
This change adds a new "upgrade" command to the toolbox CLI on Win32 and
Linux (non-open-vm-tools), which are the only platforms where we have
auto-upgrade.
Add a few utility functions to the common toolbox CLI code to do a few
useful things:
. print messages based on the status of the "quiet" flag.
. send RPCs to the host using the RpcChannel API.
On top of that, put some common definitions of commands and replies in a
shared header to avoid having duplicated strings in different parts of the
source code.
VMware, Inc [Thu, 17 Jun 2010 21:05:13 +0000 (14:05 -0700)]
lib/lock: make the userland portion available for tools
We're using MXUser (userland) locks all over bora/lib. Some of these
libraries are showing up in the open source tools build. Make only
the MXUser portion of lib/lock available to the tools. We're OK with
open sourcing this.
Once this change goes in bora/lib changes that depend on it will
start showing up almost immediately.
I've elected to a a minimumally invasive approach to ulRec.c, one
that optimized out the conditional for acquisition and release
(by far the largest usage) and leaving the farless used TryLock
and IsLocked routines using the same conditional as before this
change.
VMware, Inc [Thu, 17 Jun 2010 21:04:35 +0000 (14:04 -0700)]
OVT: detect presence of procps-3.2.8
3.2.8 is the latest version of the package and distributions are
switching to it. While it is impractical to have configure script
test for every version of the package, testing for 2 latest
versions should be OK.
VMware, Inc [Thu, 17 Jun 2010 21:04:21 +0000 (14:04 -0700)]
OVT: allow compiling against libpng 1.4
Direct usage of png_ptr->jmpbuf, which had been deprecated in
libpng 1.0.6, finally produces compile error when using libpng 1.4;
we need to use png_jmpbuf() instead.
This is import of a patch from Dominique Leuenberger
<Dominique.Leuenberger@tmf-group.com> who has a signed contribution
agreement with VMware.
VMware, Inc [Thu, 17 Jun 2010 21:01:22 +0000 (14:01 -0700)]
Fix packet header validation.
Validation assumes that all HGFS V4 requests must come with V4 header and
all HGFS V3 requests come with V3 headers.
At the moment it is not true for FAST_READ_V4/FAST_WRITE_V4. Besides V3 requests
may come with V4 headers.
Fixing validation function to remove assumption that header type depends on
operation and use explicit information about header version instead.
VMware, Inc [Thu, 17 Jun 2010 20:59:46 +0000 (13:59 -0700)]
Thread fixes for Hostinfo_MachineID
Hostinfo_MachineID caches its results. Make the cache atomic.
This uses atomic pointers because zero is a valid value for both
the name hash and hardware ID.
Unity,GHI/X11: Attempt better mapping of "window" paths to executables.
GHI/X11's unity.get.window.path handler was flawed w.r.t. its
intended purpose in that it may frequently return a path of no use
to the host. As an example, while a Firefox window belongs to the
executable installed at /usr/lib/firefox-3.6.3/firefox-bin, knowing
the latter does us no good, because the binary is meant to be started
from a wrapper script rather than executed directly.
This change introduces some fuzzing whereby vmware-user will try to
associate plain pathnames with their regular GHI menu item entries.
Put differently, when the host UI asks for the window path of a
random Firefox window, instead of returning
When the host UI then uses the latter path to launch Firefox (say,
from a docker [Fusion] or pinned start menu item [Workstation for
Windows]), it will provide enough information to vmware-user to use
the correct launcher.
This is mostly a mechanical change to have the sources better organized.
The change moves the command / help handlers to the command-specific
source files, so that there is a clear interface between the main()
function and the command handlers, and also so that it's less messy to
add new commands.
On top of that, a couple of minor issues (missing parameters to vararg
calls) were fixed, and the translations were updated to match the new
help messages (which have the command as a parameter, instead of hardocded
in the message).
Change lib/file to use Posix_Getmntent_r for I18n and thread-safety.
lib/file calls the thread-unsafe getmntent. It also ignores the
local I18N encoding. Change it to call Posix_Getmntent_r, which
takes care of both problems. On UTF-8 based systems, our Posix
variant is defined to the underlying getmntent_r call, so check
for cases where the supplied buffer is exhausted.
multi thread fix for evct and fcvt use in bsd printf
Can't use mxuser locks for this because they'll pull in lib/lock
all over the place. On Windows use the thread-safe functions _ecvt_s
and _fcvt_s instead of having to dynamically allocate a mutex.
There are thread-safe versions for Linux, too, ecvt_r and fcvt_r,
but they are not available on Mac. Since there was going to be a
mutex in this code for Mac, might as well use it for Linux, too.
Fail more gracefully on unrecognized I18N encodings
Unicode_Init has a check for unsupported local character encodings,
but the code that prints the unsupported encoding name calls
Unicode_EncodingEnumToName(), which assumes that the enum passed
into it is valid. Since the encoding name wasn't found, the enum
is STRING_ENCODING_UNKNOWN, which results in a not particularly
graceful or informative NOT_REACHED() down inside lib/unicode.
The fix is to use the string that codeset gave us instead of
trying to convert STRING_ENCODING_UNKNOWN back into an encoding
name. Also add an ASSERT to Unicode_EncodingEnumToName() to
check that STRING_ENCODING_UNKNOWN is not passed to it.
When user deletes a share on the host, nautilus (ubuntu file manager)
does not like us sending -EIO on a share. We detect this error and map
it to success and create minimal fake attributes.
In future we this client will this mask new error codes that we add to
the server as well, which is sad.
. tweak vmtoolsd so that it allows any container name when running in
debug mode (GuestRPC is still restricted to the two "blessed" names).
Also fix the hgfsServer plugin to handle the debug case without
crashing.
Instead of creating homegrown double-linked-list implementation use the
standard one provided by dbllnklst.h
Also throw in some formatting changes and remove the logic preventing
reinitialization - we are a kernel driver and should know better whether
we called init or not.
Fix renames across volumes for HGFS Windows guests
For non-Windows hosts, the HGFS server will not be able to
handle cross volume renames returning the error
HGFS_STATUS_GENERIC_ERROR. A new error should be returned and
mapped to the Windows system status STATUS_NOT_SAME_DEVICE
and EXDEV by the guest file system client. This will cause
the application (Windows Explorer, Posix mv) to break the move
file operation into a copy and delete file operations.
Windows HGFS server does not currently return this error at
all, and furthermore, handles the cross volume rename
operations internally. However, since non-Windows hosts and
guests both use the new HGFS_STATUS_NOT_SAME_VOLUME error
for this rename error, the Windows server could be later modified
to return this too for consistency and then all guest clients
can let the guest application handle it accordingly.
vmbackup: add null provider, do late initialization of sync provider.
This change adds a null provider so that systems that don't have
either VSS nor the sync driver (or have them disabled) can still execute
at least backup scripts when taking a quiesced snapshot. This should
bring feature parity to the previous quiesced snapshot approach, which
would use the VIX path if the vmbackup protocol wasn't supported by
the Tools.
Also initialize the sync provider late, only when starting a backup
operation. This allows the users to change the Tools configuration
and not have to restart the Tools service to get the new settings,
making it easier to switch between VSS / sync driver / null provider.
Ubuntu 9.10+'s Upstart may result in the services script and
vmware-user launching concurrently. When this happens, the services
script may deliver SIGUSR1 and/or SIGUSR2 to vmware-user while it's
still executing inside the suidWrapper or appLoader. Neither were
handling SIGUSR1/2, and so they'd terminate.
This change sets the handler to SIG_IGN for these signals.
Note that SIG_IGN persists across fork() and execve(), so we
don't need to block the handles again inside the appLoader driver
(toolbox/linux/vmwareuser/loader).
As a setuid application, classically we avoided pulling in other
libraries, but the vmsignal library is safe. It's tiny and doesn't
use bora/bora-vmsoft at all, so its use here is okay.
The Random_Quick context pointer is "void *" when it should be
"struct rqContext *". Use the not having to define the structure
trick so as to not expose the contents of the context.
Windows doesn't have a way of being deterministically correct
when handling files as some file operations may return a "busy"
even when not no thread/process is operating on the targetted
file. This is due to the parent directory being used by another
thread/process at the time of the file operation.
The only recourse is to retry. The good news is these problems
are rare. Unfortunately we're seeing more of this on Vista++ than
in the past.
The old code did a fixed number of retries while it slightly
wobbled the amount of time slept between retries to try to
fight its way through these kinds of problems. This proved
insufficient.
The new way is to fully wobble the retries, using a highly variable
sleep duration after a failed attempt and bounding the retries based
on the total time waited rather than a fixed retry count.
HGFS node cache from causing the VMX to go into an infinite loop
If the HGFS server node cache becomes full and all the nodes are
of the type that cannot be foreclosed and so cannot be removed
the removal goes into an infinite loop.
Fix it by only checking the number of entries in the list and then
exiting with failure.
KDE 4's kwin provides decoration windows by creating independent windows
of _NET_WM_WINDOW_TYPE_NORMAL and reparenting them to a top-level/frame
window. This window and the application's client window become siblings.
The problem is that Unity/X11 never had this case in mind. Whenever we
saw a new top-level window, we expected it to either (a) stay as a top-
level window / become an override-redirect window, or (b) be reparented
to a different window and receive the WM_STATE property (which identifies
*this* window as the client window).
Usually a window manager would create its decorations immediately as
children of the frame window, not graft the decorations into the frame's
tree. This caused Unity/X11 to treat these windows independently,
expecting them to eventually become a client window. This might not
normally be a problem, but as window coordinates are relative to one's
parent, Unity/X11 thought these windows' coordinates were relative to the
root window rather than some regular frame window.
A correct fix for this would be to associate this window and its frame,
such that once the frame is ever associated with a client window, any
remaining client window "candidates" would be ignored. (They are, after
all, unimportant children of the frame. The only child relevant to us
is the application's client window.) Unfortunately I don't have enough
time to work on that, so I'm instead sticking in a safe hack in order
to meet C&C RC stability requirements.
Linux Guest driver support for VMCI doorbell notifications
This change introduces three new functions to the VMCI guest
kernel API dealing with the HW v8 support for doorbell
notifications. The actual implementation of these doorbell
calls are embedded in a new notification module, that handles
allocating notification bitmap indexes,
registration/unregistration of callbacks for a given index,
and firing the handlers for a given index.
The Linux device initialization now opts in to use
notification, if the hardware supports it.
Unity/X11: Work area struts are [x1,x2) and [y1,y2).
The region code defines a 25x25 rectangle with its upper left corner
at the origin as (x1,x2,y1,y2) = (0,25,0,25); upper bounds are
exclusive. However, the strut code works with inclusive coordinates,
so we should instead use (0,24,0,24). Without doing this, we run
into problems.
Consider a multihead setup of 2 displays at 1600x1200 in a horizontal
configuration. There should be a single 25px top strut attached to the
left display. By adding a pixel, we have a strut that ranges from
[0,1600], occupying a single pixel on the right display. The guest will
now reserve the top 25px on the right display while the host does not.
Should someone maximize a window on that display, the guest places
the window's upper left corner at (0,25) while the host places it at
(0,0), and all hell breaks loose.
Vmware-user's signal handler was destroying RPC channels when it
shouldn't have. Rather than having a few cases where we decide to
call VMwareUserCleanupRpc before exiting the main loop, this change
simply places a call to VMwareUserCleanupRpc /after/ the main loop
has exited. (The X I/O error handler is a special case, as apps
are -not- supposed to return from that handler.)
In the case of bug 542135, vmware-user received SIGUSR2 while still
initializing, destroying gRpcIn, before control was returned to the
initialization and eventmanager routines which expected gRpcIn to
still exist.
Atomic_Write64 is not atomic for 64-bit immediate operand
There is no move instruction for 64-bit immediate to memory, so unless
the immediate value fits in 32-bit (i.e. can be sign-extended), GCC
generates two movl instructions. Use asm instruction to make GCC load
the immediate value into a register first.
CLN 1022282 introduced a regression whereby Unity/X11 began sending
spurious and sometimes incorrectly terminated updates. 1022282 was
correct, but it exposed a bug elsewhere in Unity/X11's update code.
1. The initial buffer update buffer should not start with a nul, so
trim it at init.
2. Don't append the terminating double nul unless we actually have
an update to send.
Update the PAM modules for vmguestd to include pam_unix.so
Ubuntu 10.04 does not include either the pam_unix2.so nor
the pam_unix_auth.so module for PAM. As a result, none
of our authentication is working. This CSet adds pam_unix.so
to our list of pam_modules to use for accounts and auth.
The Unity/X11 code to handle the "new" update channel code was broken,
but problems didn't surface until CLN 953276 in November. When single
"remove" updates were sent, the update buffer should've been purged but
wasn't. As a result, the update buffer might look something like this
(! = nul):
When the VMX parses the update, it stops at the first double nul,
discarding everything afterward. The result on QA's VM was that
windows created before entering Unity never appeared after entering
Unity, while all windows created afterward did.
projects / thirdparty / open-vm-tools.git / log
