VMware, Inc [Thu, 17 Jun 2010 22:14:11 +0000 (15:14 -0700)]
Unification of VMCI host and guest kernel API (4+5/5)
The VMCI kernel API should be the same for both host and
guest. Currently, that is not the case. The unification will
consist of the following five changes - this is steps 4 and 5
with some additional white space clean ups:
1) Make the functions supported by the host kernel API a
superset of the functions supported by the guest kernel
API. This consists of adding VMCI_DeviceGet,
VMCI_DeviceRelease, VMCI_GetContextID, VMCI_Version and
VMCI_DsLookup.
2) Make the functions available by the guest kernel API the
same as the functions available by the host kernel API. This
means adding VMCI_ContextID2HostVmID and defining doorbell API
on all platforms. These functions return
VMCI_ERROR_UNAVAILABLE either because they don't make sense
(the first one or because they aren't implemented yet). The
unified header file will make clear what is supported where.
3) Integrate vmciHostKernelAPI.h to vmciKernelAPI.h.
4) Edit vmciKernelAPI.h to not refer to vmciHostKernelAPI.h
and integrate the VMCIQPair.h definitions into the header
file.
5) Delete old vmci*KernelAPI.h and VMCIQPair.h files, and make
all host and guest references to a kernel API header file
refer to the new unified header file.
VMware, Inc [Thu, 17 Jun 2010 22:13:22 +0000 (15:13 -0700)]
VSOCK: fix compile error on Linux kernels past 2.6.34
Due to sock_def_readable() RCU conversion (git commit 43815482370c510c569fd18edb57afcb0fa8cab6) sk_sleep pointer
in "struct sock" was replaced with pointer to a new structure
socket_wq and users are forced to use sk_sleep() helper.
Implement the helper for older kernels and switch our code
to use it.
VMware, Inc [Thu, 17 Jun 2010 22:12:48 +0000 (15:12 -0700)]
Unification of VMCI host and guest kernel API (2/5)
The VMCI kernel API should be the same for both host and
guest. Currently, that is not the case. The unification will
consist of the following five changes - this is step 2:
1) Make the functions supported by the host kernel API a
superset of the functions supported by the guest kernel
API. This consists of adding VMCI_DeviceGet,
VMCI_DeviceRelease, VMCI_GetContextID, VMCI_Version and
VMCI_DsLookup.
2) Make the functions available by the guest kernel API the
same as the functions available by the host kernel API. This
means adding VMCI_ContextID2HostVmID and defining doorbell API
on all platforms. These functions return
VMCI_ERROR_UNAVAILABLE either because they don't make sense
(the first one or because they aren't implemented yet). The
unified header file will make clear what is supported where.
3) Integrate vmciHostKernelAPI.h to vmciKernelAPI.h.
4) Edit vmciKernelAPI.h to not refer to vmciHostKernelAPI.h
and integrate the VMCIQPair.h definitions into the header
file.
5) Delete old vmci*KernelAPI.h and VMCIQPair.h files, and make
all host and guest references to a kernel API header file
refer to the new unified header file.
VMware, Inc [Thu, 17 Jun 2010 22:12:29 +0000 (15:12 -0700)]
Unification of VMCI host and guest kernel API (1/5)
The VMCI kernel API should be the same for both host and
guest. Currently, that is not the case. The unification will
consist of the following five changes - this change is step 1:
1) Make the functions available by the host kernel API a
superset of the functions supported by the guest kernel
API. This consists of adding VMCI_DeviceGet,
VMCI_DeviceRelease, VMCI_GetContextID, VMCI_Version and
VMCI_DsLookup.
2) Make the functions available by the guest kernel API the
same as the functions available by the host kernel API. This
means adding VMCI_ContextID2HostVmID and defining doorbell API
on all platforms. These functions return
VMCI_ERROR_UNAVAILABLE either because they don't make sense
(the first one or because they aren't implemented yet). The
unified header file will make clear what is supported where.
3) Integrate vmciHostKernelAPI.h to vmciKernelAPI.h.
4) Edit vmciKernelAPI.h to not refer to vmciHostKernelAPI.h
and integrate the VMCIQPair.h definitions into the header
file.
5) Delete old vmci*KernelAPI.h and VMCIQPair.h files, and make
all host and guest references to a kernel API header file
refer to the new unified header file.
VMware, Inc [Thu, 17 Jun 2010 22:10:46 +0000 (15:10 -0700)]
Simplify and consolidate VThreadBase ID allocation
Now that VTHREAD_UI_ID has been removed, there is only
one caller of VThreadBase_InitThread. So inline the
behavior. Add a TLS destructor too, to ensure SimpleID-
allocated memory gets freed.
VMware, Inc [Thu, 17 Jun 2010 22:10:12 +0000 (15:10 -0700)]
Tweak Atomic_Init to better occur by default
Turns out vobd never called Atomic_Init, which tripped up
an ASSERT that verifies Atomic_Init isn't initialized racily.
Two fixes:
1) Atomic_Init really is idempotent. So let's remove the ASSERT
and deal with the race a different way.
2) Any code that uses Atomic_Init is Really Likely to be using
VThreadBase too, so let's stick an Atomic_Init in anytime
we see a new thread. This should cover 99% of self-
initialization.
Nominally this *slightly* weakens our Atomic_Init check - one
could end up with two threads (that don't use bora/lib but do
use atomics) running without correct atomic initialization. In
reality, forgetting Atomic_Init entirely is far more likely
than doing Atomic_Init racily, so this tweak ought to cover
more cases than the old ASSERT.
VMware, Inc [Thu, 17 Jun 2010 22:07:22 +0000 (15:07 -0700)]
Add MSI/MSI-X support to VMCI
This change adds MSI/MSI-X support to VMCI.
The device is now MSI/MSI-X capable, and supports up to 2
vectors in MSI-X mode, one for datagrams and another for
the notification bitmap.
The Windows and Linux drivers have been updated to use
MSI/MSI-X when running on the new device. The drivers only
support one vector for now, for datagrams.
Verified on Windows guests by checking the Device Resources.
MSI-X is selected on Win7, while on Win2K, it correctly
falls back to legacy mode. The old Windows driver runs
correctly on the new device.
Verified on Linux by checking lspci. MSI-X is selected on
newer kernels where CONFIG_PCI_MSI is defined, otherwise
it falls back to legacy mode. The old Linux driver runs
correctly on the new device.
Verified on v7 and v8 hardware. On v7, the new driver falls
back to legacy mode. Suspending on v7 and resuming on v8
works correctly, it will use legacy and continue to fire
interrupts as expected. On v8, it will use MSI/MSI-X
if possible.
VMware, Inc [Thu, 17 Jun 2010 22:06:36 +0000 (15:06 -0700)]
Don't call pthread_kill on exited pthread_t's
Nominally, man pages say that pthread_kill on an
exited thread return ESRCH. Unfortunately, man
pages lie; glibc bounds the space allowed for
dead thread stacks and munmaps memory once past
that bound, so pthread_kill's implementation
ends up hitting a SEGV.
The only way to avoid this is to know when threads
exit. The manual way (VThreadBase_ForgetSelf) is
pretty good, but not good enough: roll-your-own
threading code (VMHS, in this bug) exits without
telling anyone. So also do an automatic hook:
install a Posix TLS destructor. Doing so removes
the need to call pthread_kill at all, so remove
it.
The cleanup needed: remove the pthread_t from
the global list of active threads (used to
recycle VThreadIDs).
VMware, Inc [Thu, 17 Jun 2010 22:05:31 +0000 (15:05 -0700)]
least and most significant bit set functions: support !x86*
Since the chances of not using a GNU compiler for ARM or any
other architecture we'll use is very small (we know GNU well
and "like" it), code the least and most significant bit set
functions such that they should work "anywhere" via the GCC
intrinsic functions.
This is a cautious beginning to possibily using the instrinics
outside the monitor and vmkernel and possibly within. For now
the X86* support is left unmodified.
VMware, Inc [Thu, 17 Jun 2010 22:05:00 +0000 (15:05 -0700)]
Fix error on creating new files/folders in root share
When a user or inadvertently tries to create a new file or folder
or overwrite a folder in the root share fail with the correct
error. Previously the Windows hgfs client always failed with
name not found which is not the correct error and confuses some
applications which then mislead the user.
VMware, Inc [Thu, 17 Jun 2010 22:03:49 +0000 (15:03 -0700)]
Adding create/destroy session support.
1. Implementing handlers for creating and destroying sessions in server.
2. Implementing sending create/destroy session requests in the Windows client.
VMware, Inc [Thu, 17 Jun 2010 22:02:19 +0000 (15:02 -0700)]
vmmemctl: switch to using OS-specific methods to format stats
The common routine to output ballooning statistics does not work
for Solraris (which uses kstats) and is awkward on Linux/BSD,
where we need to allocate additional memory, introduce a wrappers
around snprintf and so on. Let's leave it to every OS to generate
stats in the most natural way for that particular OS.
VMware, Inc [Thu, 17 Jun 2010 21:57:49 +0000 (14:57 -0700)]
Make change notification pretty.
I am splitting the original change notification change because there are
just too many minor changes that needs to be done with the existing code.
This will make things easy to review. Hopefully.
VMware, Inc [Thu, 17 Jun 2010 21:55:40 +0000 (14:55 -0700)]
HGFS: Shared memory support for linux guest
Support for Async operations is now present. We use shared memory mechanism
to notify guest.
Shared memory support is very minimalistic. There is no flow control
here. Here is how it works --
1) Guest on startup allocates 16 pages and sends it to the hgfs Server.
Number of pages are fixed in the system. Guest always recycles between
those pages.
2) Host will use up those pages and send notifications. When host wants to send stuff
and it doesn't find memory, it sends datagram to the guest asking for more memory.
3) Guest happily obliges and sends number of free pages.
4) This process repeats.
Note that one page can contain many requests while one request can
span many pages. When request spans many pages we need to chain
pages together. Here is how page chaining looks -
First iov from which the chain starts sets chain (Bool) to true.
Last iov sets chain to false. First iov len contains total length
of the chain.
Minor -
While I was here - I did some minor cleanup to remove HgfsReceiveFlags that
nobody was using.
Note that currently all the requests are still processed sync. I have added
terminate session request so that host doesn't touch any guest pages after
the module is unloaded or it will end up corrupting guest.
VMware, Inc [Thu, 17 Jun 2010 21:42:07 +0000 (14:42 -0700)]
Thread fix for TimeUtil_DaysAdd
TimeUtil_DaysAdd was not thread safe because it kept the number
of days in each of the 12 months in a static array, and set the
value for February based on whether the function was operating
on a common year or a leap year. A simple fix is to keep two
arrays, one for common years and another for leap years.
VMware, Inc [Thu, 17 Jun 2010 21:37:51 +0000 (14:37 -0700)]
lib/thread and lib/lock: cleanup the cooperation
The watchdog routine needs to be used by both MX and MXUser
however planting the callback in only done in userland - move
ownership of the callback (and planting it) to MXUser.
VMware, Inc [Thu, 17 Jun 2010 21:37:22 +0000 (14:37 -0700)]
lib/misc: create a hostinfo time base with ns units
Provide nanosecond reporting routines; microseconds are getting a bit
"long in the tooth" for some timing applications. Refactor the
existing code to have the lowest overhead possible based on the
platform. Obtain the best we can from the existing clock sources.
The quest for better timer sources will come next...
VMware, Inc [Thu, 17 Jun 2010 21:35:14 +0000 (14:35 -0700)]
Add a "VMX logger" to Tools.
This logger using the "log" RPC to log to the host's vmware.log. It's
useful when enabling file logging in the guest is not possible (such as
for backup tests) or to make it easier to collect logs when debugging
some VMX -> Tools interaction.
VMware, Inc [Thu, 17 Jun 2010 21:32:28 +0000 (14:32 -0700)]
lib/lock: generalize MXUser condVar support
The MXUser condVar code dealt only with a lock count of 1,
something that is OK for exclusive locks and recursive locks with
that lock count but not correct for recursive locks in the general
case. Fix this by properly preserving the lock count.
VMware, Inc [Thu, 17 Jun 2010 21:29:23 +0000 (14:29 -0700)]
lib/lock: give each lock type a unique signature
The signature word in the MXUser header had the same value for all
of the lock types. Make the signature unique to each lock type. This
helps, a bit, when poking around memory.
VMware, Inc [Thu, 17 Jun 2010 21:28:13 +0000 (14:28 -0700)]
lib/lock: refactor condVar code before large change
Refactored the MXUser condVar code to make it much easier to
read and maintain. Doing this before a big change so as to make
the change and code read easy.
VMware, Inc [Thu, 17 Jun 2010 21:27:15 +0000 (14:27 -0700)]
lib/lock: assertion failure due to MXUser condVar
If an attempt was made to acquire the lock involved
with a condVar (on one thread) while the lock had been freed as part
of a condVar wait (on another thread), an assertion failure would
occur on the acquisition.
The problem is caused by the implicit unlocking and relocking of the
lock involved with the condVar. The MXUser lock reference count was
not in sync with the locked/unlocked state. Decrement and increment
the reference count before/after the native condVar wait.
VMware, Inc [Thu, 17 Jun 2010 21:26:17 +0000 (14:26 -0700)]
lib/lock: RW lock assertion failure
The MXUser RW lock release code has a bug in it... it asserts on
an unexpected reference count. The bug was caused by not decrementing
the reference count before the assertion.
projects / thirdparty / open-vm-tools.git / log
