open-vm-tools-devel — List for open-vm-tools developer discussions.

Time keeps on slippin slippin slippin slippin... into the future...

[John L. <jo...@jo...>]

Just like the song says, the time on my SLES 11 server "keeps on
slippin slippin slippin... into the future..."

The vmware-guestd are started at boot and are running.

The following modules are loaded:

# lsmod |grep vm
vmsync                  5440  0
vmmemctl               10188  0
vmblock                15124  1

Yet clocks keeps skewing forward at a rapid pace.

This VM is used for monitoring so the usual trick of putting ntpdate
in a cron is not a good solution since it throws all the graphs off
and causes false alerts and regular ntp is frustratingly stubborn
about refusing to correct large clock skew.

I can't seem to find any documentation on how these tools work or how
to configure them to keep time synced with the host.

Any help would be appreciated.

-- 
John Lange
www.johnlange.ca

[ open-vm-tools-Tracker-3110351 ] Doesn't work on openfiler

[SourceForge.net <no...@so...>]

Tracker item #3110351, was opened at 2010-11-16 23:11
Message generated for change (Tracker Item Submitted) made by tobiasholst
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3110351&group_id=204462

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: vmware-user
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Tobias Holst (tobiasholst)
Assigned to: Nobody/Anonymous (nobody)
Summary: Doesn't work on openfiler

Initial Comment:
Hi
I try to use Open VM Tools on Openfiler 2.3.
Kernel version is 2.6.29.6-0.29.smp.gcc3.4.x86_64.
The last working version was open-vm-tools-2010.01.19-226760.
Since then I get errors during "make install".
Configuration is "./configure --without-pam --without-x --without-icu"
open-vm-tools-2010.10.18-313025 can be configured but during "make install" I get the following:

fileLogger.c: In function 'VMFileLoggerOpen':
fileLogger.c:170: warning: implicit declaration of function 'g_atomic_int_set'
make[1]: *** [libvmtools_la-fileLoger.lo] Error 1
make[1]: Leaving directory '/root/open-vm-tools-2010.10.18-313025/libvmtools'
make: *** [install-recursive] Error 1

Greets from Germany
Tobias

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3110351&group_id=204462

[ open-vm-tools-Tracker-3107225 ] Quiescing not Working on Ubuntu

[SourceForge.net <no...@so...>]

Tracker item #3107225, was opened at 2010-11-11 11:06
Message generated for change (Tracker Item Submitted) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3107225&group_id=204462

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: https://www.google.com/accounts ()
Assigned to: Nobody/Anonymous (nobody)
Summary: Quiescing not Working on Ubuntu

Initial Comment:
Quiescing not Working on Ubuntu 10.04.
pre-freeze-scripts are not triggered.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3107225&group_id=204462

[ open-vm-tools-Tracker-2983141 ] Build against libpng 1.4 fails

[SourceForge.net <no...@so...>]

Tracker item #2983141, was opened at 2010-04-07 12:41
Message generated for change (Comment added) made by dimstar
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2983141&group_id=204462

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Dominique Leuenberger (dimstar)
Assigned to: Nobody/Anonymous (nobody)
Summary: Build against libpng 1.4 fails

Initial Comment:
open-vm-tools (tested up to release 2010-03-24) fails to build against libpng 1.4, due to the direct usage of jmpbuf, which had been deprecated in libpng 1.0.6

The attached patch fixes this issue by using the documented replacement (see http://www.libpng.org/pub/png/src/libpng-1.2.x-to-1.4.x-summary.txt / section 5d)

----------------------------------------------------------------------

>Comment By: Dominique Leuenberger (dimstar)
Date: 2010-10-22 19:42

Message:
This has been solved in later snapshots (tested 2010.10.19)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2983141&group_id=204462

Re: FreeBSD 8.1 VMHGFS patch

[Dmitry T. <dt...@vm...>]

Hi Ivan,

If you send the agreement to me I will make sure it gets to our legal.

Thanks!

--
Dmitry

On Monday, October 18, 2010 02:42:27 am Mr Ivan Lovric wrote:
> Hi Jain,
> 
> I've already sent the agreement to oss-queries a little over a week ago! I
> was notified by oss-queries-bounces that as my message body is too big it
> will have to be reviewed for approval. I sent the agreement as a pdf which
> was rather large I suppose. Perhaps I should have scanned a lesser-quality
> pdf or is this the usual procedure (Though I don't see how I could send a
> smaller one since the limit apparently is 1K as stated in the reply which
> is pretty small)? ________________________________________
> From: Shaileshkumar Jain [sa...@vm...]
> Sent: Monday, October 18, 2010 4:59 PM
> To: open-vm-tools development
> Cc: Mr Ivan Lovric
> Subject: RE: FreeBSD 8.1 VMHGFS patch
> 
> Ivan,
>    Thanks for your contribution. Could you follow the steps outlined here ?
> http://open-vm-tools.sourceforge.net/contribute.php. thanks.
> 
> 
> 
> Shailesh Jain
> ---------------------------------------------------------------------------
> --- Download new Adobe(R) Flash(R) Builder(TM) 4
> The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly
> Flex(R) Builder(TM)) enable the development of rich applications that run
> across multiple browsers and platforms. Download your free trials today!
> http://p.sf.net/sfu/adobe-dev2dev
> _______________________________________________
> open-vm-tools-devel mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/open-vm-tools-devel

RE: FreeBSD 8.1 VMHGFS patch

[Mr I. L. <iva...@uq...>]

Hi Jain,

I've already sent the agreement to oss-queries a little over a week ago! I was notified by oss-queries-bounces that as my message body is too big it will have to be reviewed for approval. I sent the agreement as a pdf which was rather large I suppose. Perhaps I should have scanned a lesser-quality pdf or is this the usual procedure (Though I don't see how I could send a smaller one since the limit apparently is 1K as stated in the reply which is pretty small)?
________________________________________
From: Shaileshkumar Jain [sa...@vm...]
Sent: Monday, October 18, 2010 4:59 PM
To: open-vm-tools development
Cc: Mr Ivan Lovric
Subject: RE: FreeBSD 8.1 VMHGFS patch

Ivan,
   Thanks for your contribution. Could you follow the steps outlined here ? http://open-vm-tools.sourceforge.net/contribute.php. thanks.



Shailesh Jain

RE: FreeBSD 8.1 VMHGFS patch

[Shaileshkumar J. <sa...@vm...>]

Ivan,
   Thanks for your contribution. Could you follow the steps outlined here ? http://open-vm-tools.sourceforge.net/contribute.php. thanks.



Shailesh Jain
________________________________________
From: Mr Ivan Lovric [iva...@uq...]
Sent: Sunday, October 17, 2010 9:07 PM
To: open-vm-tools development
Subject: RE: FreeBSD 8.1 VMHGFS patch

I've been working on an experimental patch for mmap() support. It's experimental since I haven't done rigorous
tests on it yet, only some basic checks. But, at least, cp works now! Taking a look at truss on a before/after:

stat("file",{ mode=-rwx------ ,inode=2884760722,size=5,blksize=4096 }) = 0 (0x0)
stat("file2",{ mode=-rwx------ ,inode=749578205,size=5,blksize=4096 }) = 0 (0x0)
open("file",O_RDONLY,00)                         = 2 (0x2)
open("file2",O_WRONLY|O_TRUNC,00)                = 3 (0x3)
mmap(0x0,5,PROT_READ,MAP_SHARED,2,0x0)           ERR#22 'Invalid argument'             [1]
read(2,"asdf\n",1048576)                         = 5 (0x5)                      [2] - defaults to read()
write(3,"asdf\n",5)                              = 5 (0x5)
read(2,0x800a1e000,1048576)                      = 0 (0x0)
close(3)                                         = 0 (0x0)
close(2)                                         = 0 (0x0)


[1] - This is where mmap failed before even without a VOP_GETPAGES/VOP_PUTPAGES implementation. It occurrs in
vm_mmap_vnode(). We have to create a vnode object if we  want to mmap, and so we do so in HgfsOpenFile().

Secondly, after a VOP_GETPAGES/VOP_PUTPAGES is implemented, MAP_SHARED would still fail with EPERM!
The reason is simple but it took me a while to realize it! Again we fail in vm_mmap_vnode() but at:

if ((flags & MAP_SHARED) != 0) {
        if ((va.va_flags & (SF_SNAPSHOT|IMMUTABLE|APPEND)) != 0) {
                if (prot & PROT_WRITE) {
                        error = EPERM;
                        goto done;

I must admit I didn't understand why such flags would be set in the first place, so after a bit of digging I came
to HgfsAttrToBSD() in fsutil.c:

  /*
   * Initialize all fields to zero. We don't need to do this for Mac OS
   * because the VATTR_RETURN macros take care of it for us.
   */
#if defined __FreeBSD__
   VATTR_NULL(vap);
#endif

Interestingly enough, VATTR_NULL doesn't quite zero everything:

vattr_null(struct vattr *vap)
{
        vap->va_type = VNON;
        vap->va_size = VNOVAL;
        ...
        vap->va_flags = VNOVAL;
        ...
}

In fact, most fields are set to VNOVAL which is defined in vnode.h as (-1)!. So, our va_flags field is set to 0xffffffff
and so vm_mmap_vnode()'s check succeeds and gives us EPERM. I've set va_flags to 0 in HgfsAttrToBSD() since it isn't used
anywhere else in vmhgfs code. That being solved, we may use cp! Here's the after shot:


stat("file",{ mode=-rwx------ ,inode=2884760722,size=5,blksize=4096 }) = 0 (0x0)
stat("file2",{ mode=-rwx------ ,inode=749578205,size=5,blksize=4096 }) = 0 (0x0)
open("file",O_RDONLY,00)                         = 2 (0x2)
open("file2",O_WRONLY|O_TRUNC,00)                = 3 (0x3)
mmap(0x0,5,PROT_READ,MAP_SHARED,2,0x0)           = 34365227008 (0x80053c000)        <- works happy!
write(3,"asdf\n",5)                              = 5 (0x5)
munmap(0x80053c000,5)                            = 0 (0x0)
close(3)                                         = 0 (0x0)
close(2)                                         = 0 (0x0)

I've also commented out the call to flush and setSize in HgfsRemoveInt() since I don't see it being used as such
in any filesystems I've checked for reference. SMBFS, NWFS don't make a call to vm_object_page_clean() (which leads to
VOP_PUTPAGES() eventually). NFSCLIENT however does make a call to invalidate its buffers but from what I see, it only flushes
the buffer cache when a VOP_REMOVE is called upon so I've left it out. It also panics the system when I leave it in :-D

So, I'll do a lot more tests with mmap but I post it here in case anyone else would also like to do some tests and figure
out any bugs so we can solve them quicker that way. A few final thoughts on GETPAGES/PUTPAGES however: Since FreeBSD-CURRENT
(900012) some differences were made with the locking of the page queues. In the version I'm testing this on (RELENG_8_1), all
systems are still using vm_page_lock_queues() ie smbfs/nwfs/nfsclient/etc in their implementations. Since 900012, this is no
longer being done. Individual pages are locked with vm_page_lock which is new. I haven't a clue how vmhgfs will work in this
case on current. SMBFS/NWFS/NFSCLIENT/etc have been updated but some systems are still using the older method. I can't find any
reference to the change in cvs log so I'm not sure. I'll have to test it out and if it's being a bother, some ugly macros would
have to be placed in.

One final problem, none of this would compile on xnu. I do not have osx so I unfortunately cannot test this :( But from what I've
looked at (very briefly) at how xnu does it, it's quite different so none of this would compile. Actually I don't quite understand
how it compiles anyway even without the mmap patch since I do not have osx to try it! Has anybody tried to run hgfs on an apple recently?

Moving away from mmap, there appear to be two final big problems to solve. The EIO problem as referred to in HgfsCreateInt() and
a vnode referencing issue. The latter one is a really big problem. If one were to stick around in a directory under /mnt/hgfs/somedir
and do a forceful unmount and a subsequent 'ls' a panic would occurr. I believe it may be related with the fact that some vnodes stay
referenced even after an unmount + kldunload with a reference count of two. Particularly for instance "somedir" in the above example
will stay with a ref of 2. This happens every time but I havn't had a chance to do a proper test since I've been busy with the mmap
thing. I'll check that out later and after that I can finally begin what I intended to do in the first place and port open-vm-tools to NetBSD!

Here's the patch that works against the previous ones. Yes I know, all these patches...
I've got a bit of a patch managment issue!

diff -uNr open-vm-tools-2010.09.19-301124/modules/freebsd/vmhgfs/fsutil.c open-vm-tools/modules/freebsd/vmhgfs/fsutil.c
--- open-vm-tools-2010.09.19-301124/modules/freebsd/vmhgfs/fsutil.c     2010-09-20 18:30:55.000000000 +0000
+++ open-vm-tools/modules/freebsd/vmhgfs/fsutil.c       2010-10-18 02:40:39.000000000 +0000
@@ -669,6 +669,8 @@

    HGFS_VATTR_NLINK_RETURN(vap, 1);               /* fake */

+   vap->va_flags = 0;
+
    if (sip->uidSet || (hgfsAttrV2->mask & HGFS_ATTR_VALID_USERID) == 0) {
       HGFS_VATTR_UID_RETURN(vap, sip->uid);
} else {
diff -uNr open-vm-tools-2010.09.19-301124/modules/freebsd/vmhgfs/hgfs_kernel.h open-vm-tools/modules/freebsd/vmhgfs/hgfs_kernel.h
--- open-vm-tools-2010.09.19-301124/modules/freebsd/vmhgfs/hgfs_kernel.h        2010-09-20 18:30:55.000000000 +0000
+++ open-vm-tools/modules/freebsd/vmhgfs/hgfs_kernel.h  2010-10-18 02:42:15.000000000 +0000
@@ -151,6 +151,8 @@
  * Global variables
                                                                                                   */

+extern int hgfs_pbuf_freecnt;
+
 /*
  * The vnode attributes between Mac OS and FreeBSD are very similar but not exactly the
  * same. Fields have names have changed. However, only HgfsAttrToBSD and
diff -uNr open-vm-tools-2010.09.19-301124/modules/freebsd/vmhgfs/os.c open-vm-tools/modules/freebsd/vmhgfs/os.c
--- open-vm-tools-2010.09.19-301124/modules/freebsd/vmhgfs/os.c 2010-09-20 18:30:55.000000000 +0000
+++ open-vm-tools/modules/freebsd/vmhgfs/os.c   2010-10-18 02:40:39.000000000 +0000
@@ -32,10 +32,13 @@
#include <sys/malloc.h>
#include <sys/lock.h>         // for struct mtx
#include <sys/kernel.h>
+#include <sys/systm.h>
+#include <sys/buf.h>          // for nswbuf
#include <vm/uma.h>           // for uma_zone_t
#include <sys/kthread.h>      // for kthread_create()
#include <vm/vm.h>
#include <vm/vm_extern.h>     // for vnode_pager_setsize
+#include <vm/vm_object.h>

#include "vm_basic_types.h"
#include "os.h"
@@ -55,6 +58,8 @@
    struct uma_zone *umaZone;
} os_zone_struct;

+int hgfs_pbuf_freecnt = -1;
+
 /*
  *----------------------------------------------------------------------------
  *
@@ -76,7 +81,8 @@
 int
 os_init(void)
{
-   /* NOP */
+   /* Initialize physical buffer free counter */
+   hgfs_pbuf_freecnt = (nswbuf / 2);
    return 0;
}

@@ -897,7 +903,7 @@
  *      Flushes dirty pages associated with the file.
  *
  * Results:
- *      Always retun 0 (success) for now since it is NOOP.
+ *      Cleans pages associated with vnode object.
  *
  * Side effects:
  *      None.
@@ -909,11 +915,8 @@
               off_t start,         // IN: starting offset in the file to flush
               uint32_t length)     // IN: length of data to flush
{
-   /*
-    * XXX: NOOP for now. This routine is needed to maintain coherence
-    *      between memory mapped data and data for read/write operations.
-    *      Will need to implement when adding support for memory mapped files to HGFS
-    *      for FreeBsd.
-    */
+   VM_OBJECT_LOCK(vp->v_object);
+   vm_object_page_clean(vp->v_object, 0, 0, OBJPC_SYNC);
+   VM_OBJECT_UNLOCK(vp->v_object);
    return 0;
}
diff -uNr open-vm-tools-2010.09.19-301124/modules/freebsd/vmhgfs/vnops.c open-vm-tools/modules/freebsd/vmhgfs/vnops.c
--- open-vm-tools-2010.09.19-301124/modules/freebsd/vmhgfs/vnops.c      2010-10-18 02:44:28.000000000 +0000
+++ open-vm-tools/modules/freebsd/vmhgfs/vnops.c        2010-10-18 02:40:39.000000000 +0000
@@ -23,8 +23,10 @@
        */

#include <sys/param.h>          // for everything
+#include <sys/systm.h>          // for KASSERT
#include <sys/vnode.h>          // for struct vnode
#include <sys/mount.h>          // for struct mount
+#include <sys/buf.h>            // for struct buf
#include <sys/namei.h>          // for name lookup goodness
#include <sys/libkern.h>        // for string & other functions
#include <sys/fcntl.h>          // for in-kernel file access flags (FREAD, etc)
@@ -32,6 +34,12 @@
#include <sys/uio.h>            // for uiomove
#include <sys/dirent.h>         // for struct dirent

+#include <vm/vm.h>
+#include <vm/vm_page.h>
+#include <vm/vm_extern.h>
+#include <vm/vm_object.h>
+#include <vm/vm_pager.h>
+
#include "cpName.h"

#include "hgfsUtil.h"
@@ -68,6 +76,8 @@
 static vop_print_t     HgfsVopPrint;
 static vop_readlink_t   HgfsVopReadlink;
 static vop_symlink_t    HgfsVopSymlink;
+static vop_getpages_t   HgfsVopGetPages;
+static vop_putpages_t   HgfsVopPutPages;

 /*
  * Global data
@@ -97,6 +107,8 @@
    .vop_print           = HgfsVopPrint,
    .vop_readlink        = HgfsVopReadlink,
    .vop_symlink         = HgfsVopSymlink,
+   .vop_getpages        = HgfsVopGetPages,
+   .vop_putpages        = HgfsVopPutPages,
};


@@ -863,3 +875,42 @@
    return HgfsSymlinkInt(dvp, vp, cnp, target);
}

+int
+HgfsVopGetPages(struct vop_getpages_args *ap)
+/*
+struct vop_getpages_args {
+   struct vnode *a_vp;
+   vm_page_t *a_m;
+   int a_count;
+   int a_reqpage;
+   vm_ooffset_t a_offset;
+};
+*/
+{
+   struct vnode *vp = ap->a_vp;
+   vm_page_t *pages = ap->a_m;
+   int count = ap->a_count;
+   int reqpage = ap->a_reqpage;
+
+   return HgfsGetPagesInt(vp, pages, count, reqpage);
+}
+
+int HgfsVopPutPages(struct vop_putpages_args *ap)
+/*
+struct vop_getpages_args {
+   struct vnode *a_vp;
+   vm_page_t *a_m;
+   int a_count;
+   int a_sync;
+   int *a_rtvals;
+   vm_ooffset_t a_offset;
+}
+*/
+{
+   struct vnode *vp = ap->a_vp;
+   struct vm_page **pages = ap->a_m;
+   int count = ap->a_count;
+   int *rtvals = ap->a_rtvals;
+
+   return HgfsPutPagesInt(vp, pages, count, rtvals);
+}
diff -uNr open-vm-tools-2010.09.19-301124/modules/freebsd/vmhgfs/vnopscommon.c open-vm-tools/modules/freebsd/vmhgfs/vnopscommon.c
--- open-vm-tools-2010.09.19-301124/modules/freebsd/vmhgfs/vnopscommon.c        2010-09-20 18:30:55.000000000 +0000
+++ open-vm-tools/modules/freebsd/vmhgfs/vnopscommon.c  2010-10-18 03:00:30.000000000 +0000
@@ -23,8 +23,16 @@
 */

#include <sys/param.h>          // for everything
+#include <sys/systm.h>
#include <sys/vnode.h>          // for struct vnode
#include <sys/dirent.h>         // for struct dirent
+#include <sys/buf.h>
+#include <vm/vm.h>
+#include <vm/vm_page.h>
+#include <vm/vm_extern.h>
+#include <vm/vm_object.h>
+#include <vm/vm_pager.h>
+

#include "fsutil.h"
#include "debug.h"
@@ -694,12 +702,14 @@
       goto out;
}

-    os_FlushRange(vp, 0, HGFS_VP_TO_FILESIZE(vp));
-    os_SetSize(vp, 0);
+//  os_FlushRange(vp, 0, HGFS_VP_TO_FILESIZE(vp));
+//  os_SetSize(vp, 0);

    /* We can now send the delete request. */
    ret = HgfsDelete(sip, HGFS_VP_TO_FILENAME(vp), HGFS_OP_DELETE_FILE_V3);

+   cache_purge(vp);
+
 out:
    DEBUG(VM_DEBUG_LOG, "Exit %s.\n",  HGFS_VP_TO_FILENAME(vp));
    return ret;
@@ -1712,6 +1722,9 @@
}
}

+   /* Create backing object for this vnode.  */
+   vnode_create_vobject(vp, fp->fileSize, curthread);
+
    os_rw_lock_unlock_exclusive(fp->handleLock);

 out:
@@ -3056,3 +3069,215 @@
}
    return error;
}
+
+/*
+ *----------------------------------------------------------------------------
+ *
+ * HgfsGetPagesInt --
+ *
+ *      HgfsGetPagesInt is invoked to read in pages from the backing store.
+ *      Generally one page need only be loaded but VOP_GETPAGES is requested to
+ *      read in adjacent pages as well, although it is not required to do so.
+ *
+ * Results:
+ *      VM_PAGER_OK on success or VM_PAGER_ERROR otherwise.
+ *
+ * Side effects:
+ *
+ *----------------------------------------------------------------------------
+ */
+
+int HgfsGetPagesInt(struct vnode *vp,
+                    vm_page_t    *pages,
+                    int           count,
+                    int           reqpage)
+{
+   int            npages, size, toff, nextoff, i, error;
+   struct uio     uio;
+   struct iovec   iov;
+   struct buf    *bp;
+   vm_page_t      m;
+   vm_object_t    object;
+   vm_offset_t    kva;
+
+   npages  = btoc(count);
+
+   printf("************* HgfsVopGetPages ***************\n");
+   printf("count:      %d\n", count);
+   printf("npages:     %d\n", npages);
+
+   m = pages[reqpage];
+
+   if ((object = vp->v_object) == NULL) {
+      return VM_PAGER_ERROR;
+   }
+
+   VM_OBJECT_LOCK(object);
+   if (m->valid != 0) {
+      vm_page_lock_queues();
+      for (i = 0; i < npages; ++i) {
+         if (i != reqpage) {
+            vm_page_free(pages[i]);
+         }
+         vm_page_unlock_queues();
+         VM_OBJECT_UNLOCK(object);
+         return VM_PAGER_OK;
+      }
+   }
+   VM_OBJECT_UNLOCK(object);
+
+   /* Obtain a buffer and a temporary mapping */
+   bp = getpbuf(&hgfs_pbuf_freecnt);
+   kva = (vm_offset_t) bp->b_data;
+   pmap_qenter(kva, pages, npages);
+
+   iov.iov_base   = (caddr_t) kva;
+   iov.iov_len    = count;
+   uio.uio_iov    = &iov;
+   uio.uio_iovcnt = 1;
+   uio.uio_offset = IDX_TO_OFF(pages[0]->pindex);
+   uio.uio_resid  = count;
+   uio.uio_segflg = UIO_SYSSPACE;
+   uio.uio_rw     = UIO_READ;
+   uio.uio_td     = curthread;
+
+   error = HgfsReadInt(vp, &uio, TRUE);
+
+   /* Remove temporary mappings and release physical buffer */
+   pmap_qremove(kva, npages);
+   relpbuf(bp, &hgfs_pbuf_freecnt);
+
+   VM_OBJECT_LOCK(object);
+   if (error && (uio.uio_resid == count)) {
+      printf("HgfsVopGetPages error: %d\n", error);
+      vm_page_lock_queues();
+      for (i = 0; i < npages; i++) {
+         if (reqpage != i) {
+            vm_page_free(pages[i]);
+         }
+         vm_page_unlock_queues();
+         VM_OBJECT_UNLOCK(object);
+         return VM_PAGER_ERROR;
+      }
+   }
+
+   size = count - uio.uio_resid;
+
+   vm_page_lock_queues();
+   for (i = 0, toff = 0; i < npages; i++, toff = nextoff) {
+      struct vm_page *mt;
+
+      mt = pages[i];
+      nextoff = toff + PAGE_SIZE;
+      if (nextoff <= size) {
+         /* Read filled an entire page */
+         mt->valid = VM_PAGE_BITS_ALL;
+         KASSERT(mt->dirty == 0, ("HgfsGetPages: page %p is dirty\n", mt));
+      }
+      else if (size > toff) {
+         /* Read filled a partial page */
+         mt->valid = 0;
+         vm_page_set_valid(mt, 0, size - toff);
+         KASSERT(mt->dirty == 0, ("HgfsGetPages: page %p is dirty\n", mt));
+      }
+      else {
+         /*
+          * Read operation was short. If no error occurred, leave m->valid
+          * as zero and the pager will call vm_page_zero_invalid() to zero
+          * fill the non-valid portions of the page. This often denots that
+          * an end of file has been mapped into memory and the file's size
+          * is not page aligned (vm_pager.c:vm_page_zero_invalid()).
+          */
+         ;
+      }
+
+      if (i != reqpage) {
+         if (!error) {
+            if (mt->oflags & VPO_WANTED)
+               vm_page_activate(mt);
+            else
+               vm_page_deactivate(mt);
+            vm_page_wakeup(mt);
+         }
+         else {
+            vm_page_free(mt);
+         }
+      }
+   }
+   vm_page_unlock_queues();
+   VM_OBJECT_UNLOCK(object);
+   if (error) {
+      printf("HgfsGetPages: Read I/O error: %d\n", error);
+   }
+   return (error ? VM_PAGER_ERROR : VM_PAGER_OK);
+}
+
+/*
+ *----------------------------------------------------------------------------
+ *
+ * HgfsPutPagesInt --
+ *
+ *      HgfsPutPagesInt is invoked to write dirty pages to the backing store.
+ *
+ * Results:
+ *      VM_PAGER_OK on success or VM_PAGER_ERROR otherwise.
+ *
+ * Side effects:
+ *
+ *----------------------------------------------------------------------------
+ */
+
+int
+HgfsPutPagesInt(struct vnode *vp,
+                vm_page_t *pages,
+                int count,
+                int *rtvals)
+{
+   int            i, npages, error;
+   struct uio     uio;
+   struct iovec   iov;
+   struct buf    *bp;
+   vm_offset_t    kva;
+
+   npages = btoc(count);
+
+   printf("********** HgfsVopPutPages *************\n");
+   printf("count:     %d\n", count);
+
+   for (i = 0; i < npages; i++) {
+      rtvals[i] = VM_PAGER_AGAIN;
+   }
+
+   /* Obtain a buffer and a temporary mapping */
+   bp  = getpbuf(&hgfs_pbuf_freecnt);
+   kva = (vm_offset_t) bp->b_data;
+   pmap_qenter(kva, pages, npages);
+
+   iov.iov_base   = (caddr_t) kva;
+   iov.iov_len    = count;
+   uio.uio_iov    = &iov;
+   uio.uio_iovcnt = 1;
+   uio.uio_offset = IDX_TO_OFF(pages[0]->pindex);
+   uio.uio_resid  = count;
+   uio.uio_segflg = UIO_SYSSPACE;
+   uio.uio_rw     = UIO_WRITE;
+   uio.uio_td     = curthread;
+
+   error = HgfsWriteInt(vp, &uio, 0, TRUE);
+
+   /* Remove temporary mappings and release physical buffer */
+   pmap_qremove(kva, npages);
+   relpbuf(bp, &hgfs_pbuf_freecnt);
+
+   /* Tell the pager how many pages were written and undirty the pages */
+   if (!error) {
+      int nwritten = round_page(count - uio.uio_resid) / PAGE_SIZE;
+      vm_page_lock_queues();
+      for (i = 0; i < nwritten; i++) {
+         rtvals[i] = VM_PAGER_OK;
+         vm_page_undirty(pages[i]);
+      }
+      vm_page_unlock_queues();
+   }
+   return rtvals[0];
+}
diff -uNr open-vm-tools-2010.09.19-301124/modules/freebsd/vmhgfs/vnopscommon.h open-vm-tools/modules/freebsd/vmhgfs/vnopscommon.h
--- open-vm-tools-2010.09.19-301124/modules/freebsd/vmhgfs/vnopscommon.h        2010-09-20 18:30:55.000000000 +0000
+++ open-vm-tools/modules/freebsd/vmhgfs/vnopscommon.h  2010-10-18 02:42:15.000000000 +0000
@@ -90,5 +90,8 @@
                    char *targetName);
 int HgfsMmapInt(struct vnode *vp, int accessMode);
 int HgfsMnomapInt(struct vnode *vp);
+int HgfsGetPagesInt(struct vnode *vp, vm_page_t *pages, int count, int reqpage);
+int HgfsPutPagesInt(struct vnode *vp, vm_page_t *pages, int count, int *rtvals);
+

#endif // _HGFS_VNOPS_COMMON_H_


------------------------------------------------------------------------------
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
_______________________________________________
open-vm-tools-devel mailing list
ope...@li...
https://lists.sourceforge.net/lists/listinfo/open-vm-tools-devel

RE: FreeBSD 8.1 VMHGFS patch

[Mr I. L. <iva...@uq...>]

I've been working on an experimental patch for mmap() support. It's experimental since I haven't done rigorous
tests on it yet, only some basic checks. But, at least, cp works now! Taking a look at truss on a before/after:

stat("file",{ mode=-rwx------ ,inode=2884760722,size=5,blksize=4096 }) = 0 (0x0)
stat("file2",{ mode=-rwx------ ,inode=749578205,size=5,blksize=4096 }) = 0 (0x0)
open("file",O_RDONLY,00)                         = 2 (0x2)
open("file2",O_WRONLY|O_TRUNC,00)                = 3 (0x3)
mmap(0x0,5,PROT_READ,MAP_SHARED,2,0x0)           ERR#22 'Invalid argument'             [1]
read(2,"asdf\n",1048576)                         = 5 (0x5)                      [2] - defaults to read()
write(3,"asdf\n",5)                              = 5 (0x5)
read(2,0x800a1e000,1048576)                      = 0 (0x0)
close(3)                                         = 0 (0x0)
close(2)                                         = 0 (0x0)


[1] - This is where mmap failed before even without a VOP_GETPAGES/VOP_PUTPAGES implementation. It occurrs in
vm_mmap_vnode(). We have to create a vnode object if we  want to mmap, and so we do so in HgfsOpenFile().

Secondly, after a VOP_GETPAGES/VOP_PUTPAGES is implemented, MAP_SHARED would still fail with EPERM!
The reason is simple but it took me a while to realize it! Again we fail in vm_mmap_vnode() but at:

if ((flags & MAP_SHARED) != 0) {
        if ((va.va_flags & (SF_SNAPSHOT|IMMUTABLE|APPEND)) != 0) {
                if (prot & PROT_WRITE) {
                        error = EPERM;
                        goto done;

I must admit I didn't understand why such flags would be set in the first place, so after a bit of digging I came
to HgfsAttrToBSD() in fsutil.c:

  /*
   * Initialize all fields to zero. We don't need to do this for Mac OS
   * because the VATTR_RETURN macros take care of it for us.
   */
#if defined __FreeBSD__
   VATTR_NULL(vap);
#endif

Interestingly enough, VATTR_NULL doesn't quite zero everything:

vattr_null(struct vattr *vap)
{
        vap->va_type = VNON;
        vap->va_size = VNOVAL;
        ...
        vap->va_flags = VNOVAL;
        ...
}

In fact, most fields are set to VNOVAL which is defined in vnode.h as (-1)!. So, our va_flags field is set to 0xffffffff
and so vm_mmap_vnode()'s check succeeds and gives us EPERM. I've set va_flags to 0 in HgfsAttrToBSD() since it isn't used
anywhere else in vmhgfs code. That being solved, we may use cp! Here's the after shot:


stat("file",{ mode=-rwx------ ,inode=2884760722,size=5,blksize=4096 }) = 0 (0x0)
stat("file2",{ mode=-rwx------ ,inode=749578205,size=5,blksize=4096 }) = 0 (0x0)
open("file",O_RDONLY,00)                         = 2 (0x2)
open("file2",O_WRONLY|O_TRUNC,00)                = 3 (0x3)
mmap(0x0,5,PROT_READ,MAP_SHARED,2,0x0)           = 34365227008 (0x80053c000)        <- works happy!
write(3,"asdf\n",5)                              = 5 (0x5)
munmap(0x80053c000,5)                            = 0 (0x0)
close(3)                                         = 0 (0x0)
close(2)                                         = 0 (0x0)

I've also commented out the call to flush and setSize in HgfsRemoveInt() since I don't see it being used as such
in any filesystems I've checked for reference. SMBFS, NWFS don't make a call to vm_object_page_clean() (which leads to
VOP_PUTPAGES() eventually). NFSCLIENT however does make a call to invalidate its buffers but from what I see, it only flushes
the buffer cache when a VOP_REMOVE is called upon so I've left it out. It also panics the system when I leave it in :-D

So, I'll do a lot more tests with mmap but I post it here in case anyone else would also like to do some tests and figure
out any bugs so we can solve them quicker that way. A few final thoughts on GETPAGES/PUTPAGES however: Since FreeBSD-CURRENT
(900012) some differences were made with the locking of the page queues. In the version I'm testing this on (RELENG_8_1), all
systems are still using vm_page_lock_queues() ie smbfs/nwfs/nfsclient/etc in their implementations. Since 900012, this is no
longer being done. Individual pages are locked with vm_page_lock which is new. I haven't a clue how vmhgfs will work in this
case on current. SMBFS/NWFS/NFSCLIENT/etc have been updated but some systems are still using the older method. I can't find any
reference to the change in cvs log so I'm not sure. I'll have to test it out and if it's being a bother, some ugly macros would
have to be placed in.

One final problem, none of this would compile on xnu. I do not have osx so I unfortunately cannot test this :( But from what I've
looked at (very briefly) at how xnu does it, it's quite different so none of this would compile. Actually I don't quite understand
how it compiles anyway even without the mmap patch since I do not have osx to try it! Has anybody tried to run hgfs on an apple recently?

Moving away from mmap, there appear to be two final big problems to solve. The EIO problem as referred to in HgfsCreateInt() and
a vnode referencing issue. The latter one is a really big problem. If one were to stick around in a directory under /mnt/hgfs/somedir
and do a forceful unmount and a subsequent 'ls' a panic would occurr. I believe it may be related with the fact that some vnodes stay
referenced even after an unmount + kldunload with a reference count of two. Particularly for instance "somedir" in the above example
will stay with a ref of 2. This happens every time but I havn't had a chance to do a proper test since I've been busy with the mmap
thing. I'll check that out later and after that I can finally begin what I intended to do in the first place and port open-vm-tools to NetBSD!

Here's the patch that works against the previous ones. Yes I know, all these patches...
I've got a bit of a patch managment issue!

diff -uNr open-vm-tools-2010.09.19-301124/modules/freebsd/vmhgfs/fsutil.c open-vm-tools/modules/freebsd/vmhgfs/fsutil.c
--- open-vm-tools-2010.09.19-301124/modules/freebsd/vmhgfs/fsutil.c     2010-09-20 18:30:55.000000000 +0000
+++ open-vm-tools/modules/freebsd/vmhgfs/fsutil.c       2010-10-18 02:40:39.000000000 +0000
@@ -669,6 +669,8 @@

    HGFS_VATTR_NLINK_RETURN(vap, 1);               /* fake */

+   vap->va_flags = 0;
+
    if (sip->uidSet || (hgfsAttrV2->mask & HGFS_ATTR_VALID_USERID) == 0) {
       HGFS_VATTR_UID_RETURN(vap, sip->uid);
} else {
diff -uNr open-vm-tools-2010.09.19-301124/modules/freebsd/vmhgfs/hgfs_kernel.h open-vm-tools/modules/freebsd/vmhgfs/hgfs_kernel.h
--- open-vm-tools-2010.09.19-301124/modules/freebsd/vmhgfs/hgfs_kernel.h        2010-09-20 18:30:55.000000000 +0000
+++ open-vm-tools/modules/freebsd/vmhgfs/hgfs_kernel.h  2010-10-18 02:42:15.000000000 +0000
@@ -151,6 +151,8 @@
  * Global variables
                                                                                                   */

+extern int hgfs_pbuf_freecnt;
+
 /*
  * The vnode attributes between Mac OS and FreeBSD are very similar but not exactly the
  * same. Fields have names have changed. However, only HgfsAttrToBSD and
diff -uNr open-vm-tools-2010.09.19-301124/modules/freebsd/vmhgfs/os.c open-vm-tools/modules/freebsd/vmhgfs/os.c
--- open-vm-tools-2010.09.19-301124/modules/freebsd/vmhgfs/os.c 2010-09-20 18:30:55.000000000 +0000
+++ open-vm-tools/modules/freebsd/vmhgfs/os.c   2010-10-18 02:40:39.000000000 +0000
@@ -32,10 +32,13 @@
#include <sys/malloc.h>
#include <sys/lock.h>         // for struct mtx
#include <sys/kernel.h>
+#include <sys/systm.h>
+#include <sys/buf.h>          // for nswbuf
#include <vm/uma.h>           // for uma_zone_t
#include <sys/kthread.h>      // for kthread_create()
#include <vm/vm.h>
#include <vm/vm_extern.h>     // for vnode_pager_setsize
+#include <vm/vm_object.h>

#include "vm_basic_types.h"
#include "os.h"
@@ -55,6 +58,8 @@
    struct uma_zone *umaZone;
} os_zone_struct;

+int hgfs_pbuf_freecnt = -1;
+
 /*
  *----------------------------------------------------------------------------
  *
@@ -76,7 +81,8 @@
 int
 os_init(void)
{
-   /* NOP */
+   /* Initialize physical buffer free counter */
+   hgfs_pbuf_freecnt = (nswbuf / 2);
    return 0;
}

@@ -897,7 +903,7 @@
  *      Flushes dirty pages associated with the file.
  *
  * Results:
- *      Always retun 0 (success) for now since it is NOOP.
+ *      Cleans pages associated with vnode object.
  *
  * Side effects:
  *      None.
@@ -909,11 +915,8 @@
               off_t start,         // IN: starting offset in the file to flush
               uint32_t length)     // IN: length of data to flush
{
-   /*
-    * XXX: NOOP for now. This routine is needed to maintain coherence
-    *      between memory mapped data and data for read/write operations.
-    *      Will need to implement when adding support for memory mapped files to HGFS
-    *      for FreeBsd.
-    */
+   VM_OBJECT_LOCK(vp->v_object);
+   vm_object_page_clean(vp->v_object, 0, 0, OBJPC_SYNC);
+   VM_OBJECT_UNLOCK(vp->v_object);
    return 0;
}
diff -uNr open-vm-tools-2010.09.19-301124/modules/freebsd/vmhgfs/vnops.c open-vm-tools/modules/freebsd/vmhgfs/vnops.c
--- open-vm-tools-2010.09.19-301124/modules/freebsd/vmhgfs/vnops.c      2010-10-18 02:44:28.000000000 +0000
+++ open-vm-tools/modules/freebsd/vmhgfs/vnops.c        2010-10-18 02:40:39.000000000 +0000
@@ -23,8 +23,10 @@
        */

#include <sys/param.h>          // for everything
+#include <sys/systm.h>          // for KASSERT
#include <sys/vnode.h>          // for struct vnode
#include <sys/mount.h>          // for struct mount
+#include <sys/buf.h>            // for struct buf
#include <sys/namei.h>          // for name lookup goodness
#include <sys/libkern.h>        // for string & other functions
#include <sys/fcntl.h>          // for in-kernel file access flags (FREAD, etc)
@@ -32,6 +34,12 @@
#include <sys/uio.h>            // for uiomove
#include <sys/dirent.h>         // for struct dirent

+#include <vm/vm.h>
+#include <vm/vm_page.h>
+#include <vm/vm_extern.h>
+#include <vm/vm_object.h>
+#include <vm/vm_pager.h>
+
#include "cpName.h"

#include "hgfsUtil.h"
@@ -68,6 +76,8 @@
 static vop_print_t     HgfsVopPrint;
 static vop_readlink_t   HgfsVopReadlink;
 static vop_symlink_t    HgfsVopSymlink;
+static vop_getpages_t   HgfsVopGetPages;
+static vop_putpages_t   HgfsVopPutPages;

 /*
  * Global data
@@ -97,6 +107,8 @@
    .vop_print           = HgfsVopPrint,
    .vop_readlink        = HgfsVopReadlink,
    .vop_symlink         = HgfsVopSymlink,
+   .vop_getpages        = HgfsVopGetPages,
+   .vop_putpages        = HgfsVopPutPages,
};


@@ -863,3 +875,42 @@
    return HgfsSymlinkInt(dvp, vp, cnp, target);
}

+int
+HgfsVopGetPages(struct vop_getpages_args *ap)
+/*
+struct vop_getpages_args {
+   struct vnode *a_vp;
+   vm_page_t *a_m;
+   int a_count;
+   int a_reqpage;
+   vm_ooffset_t a_offset;
+};
+*/
+{
+   struct vnode *vp = ap->a_vp;
+   vm_page_t *pages = ap->a_m;
+   int count = ap->a_count;
+   int reqpage = ap->a_reqpage;
+
+   return HgfsGetPagesInt(vp, pages, count, reqpage);
+}
+
+int HgfsVopPutPages(struct vop_putpages_args *ap)
+/*
+struct vop_getpages_args {
+   struct vnode *a_vp;
+   vm_page_t *a_m;
+   int a_count;
+   int a_sync;
+   int *a_rtvals;
+   vm_ooffset_t a_offset;
+}
+*/
+{
+   struct vnode *vp = ap->a_vp;
+   struct vm_page **pages = ap->a_m;
+   int count = ap->a_count;
+   int *rtvals = ap->a_rtvals;
+
+   return HgfsPutPagesInt(vp, pages, count, rtvals);
+}
diff -uNr open-vm-tools-2010.09.19-301124/modules/freebsd/vmhgfs/vnopscommon.c open-vm-tools/modules/freebsd/vmhgfs/vnopscommon.c
--- open-vm-tools-2010.09.19-301124/modules/freebsd/vmhgfs/vnopscommon.c        2010-09-20 18:30:55.000000000 +0000
+++ open-vm-tools/modules/freebsd/vmhgfs/vnopscommon.c  2010-10-18 03:00:30.000000000 +0000
@@ -23,8 +23,16 @@
 */

#include <sys/param.h>          // for everything
+#include <sys/systm.h>
#include <sys/vnode.h>          // for struct vnode
#include <sys/dirent.h>         // for struct dirent
+#include <sys/buf.h>
+#include <vm/vm.h>
+#include <vm/vm_page.h>
+#include <vm/vm_extern.h>
+#include <vm/vm_object.h>
+#include <vm/vm_pager.h>
+

#include "fsutil.h"
#include "debug.h"
@@ -694,12 +702,14 @@
       goto out;
}

-    os_FlushRange(vp, 0, HGFS_VP_TO_FILESIZE(vp));
-    os_SetSize(vp, 0);
+//  os_FlushRange(vp, 0, HGFS_VP_TO_FILESIZE(vp));
+//  os_SetSize(vp, 0);

    /* We can now send the delete request. */
    ret = HgfsDelete(sip, HGFS_VP_TO_FILENAME(vp), HGFS_OP_DELETE_FILE_V3);

+   cache_purge(vp);
+
 out:
    DEBUG(VM_DEBUG_LOG, "Exit %s.\n",  HGFS_VP_TO_FILENAME(vp));
    return ret;
@@ -1712,6 +1722,9 @@
}
}

+   /* Create backing object for this vnode.  */
+   vnode_create_vobject(vp, fp->fileSize, curthread);
+
    os_rw_lock_unlock_exclusive(fp->handleLock);

 out:
@@ -3056,3 +3069,215 @@
}
    return error;
}
+
+/*
+ *----------------------------------------------------------------------------
+ *
+ * HgfsGetPagesInt --
+ *
+ *      HgfsGetPagesInt is invoked to read in pages from the backing store.
+ *      Generally one page need only be loaded but VOP_GETPAGES is requested to
+ *      read in adjacent pages as well, although it is not required to do so.
+ *
+ * Results:
+ *      VM_PAGER_OK on success or VM_PAGER_ERROR otherwise.
+ *
+ * Side effects:
+ *
+ *----------------------------------------------------------------------------
+ */
+
+int HgfsGetPagesInt(struct vnode *vp,
+                    vm_page_t    *pages,
+                    int           count,
+                    int           reqpage)
+{
+   int            npages, size, toff, nextoff, i, error;
+   struct uio     uio;
+   struct iovec   iov;
+   struct buf    *bp;
+   vm_page_t      m;
+   vm_object_t    object;
+   vm_offset_t    kva;
+
+   npages  = btoc(count);
+
+   printf("************* HgfsVopGetPages ***************\n");
+   printf("count:      %d\n", count);
+   printf("npages:     %d\n", npages);
+
+   m = pages[reqpage];
+
+   if ((object = vp->v_object) == NULL) {
+      return VM_PAGER_ERROR;
+   }
+
+   VM_OBJECT_LOCK(object);
+   if (m->valid != 0) {
+      vm_page_lock_queues();
+      for (i = 0; i < npages; ++i) {
+         if (i != reqpage) {
+            vm_page_free(pages[i]);
+         }
+         vm_page_unlock_queues();
+         VM_OBJECT_UNLOCK(object);
+         return VM_PAGER_OK;
+      }
+   }
+   VM_OBJECT_UNLOCK(object);
+
+   /* Obtain a buffer and a temporary mapping */
+   bp = getpbuf(&hgfs_pbuf_freecnt);
+   kva = (vm_offset_t) bp->b_data;
+   pmap_qenter(kva, pages, npages);
+
+   iov.iov_base   = (caddr_t) kva;
+   iov.iov_len    = count;
+   uio.uio_iov    = &iov;
+   uio.uio_iovcnt = 1;
+   uio.uio_offset = IDX_TO_OFF(pages[0]->pindex);
+   uio.uio_resid  = count;
+   uio.uio_segflg = UIO_SYSSPACE;
+   uio.uio_rw     = UIO_READ;
+   uio.uio_td     = curthread;
+
+   error = HgfsReadInt(vp, &uio, TRUE);
+
+   /* Remove temporary mappings and release physical buffer */
+   pmap_qremove(kva, npages);
+   relpbuf(bp, &hgfs_pbuf_freecnt);
+
+   VM_OBJECT_LOCK(object);
+   if (error && (uio.uio_resid == count)) {
+      printf("HgfsVopGetPages error: %d\n", error);
+      vm_page_lock_queues();
+      for (i = 0; i < npages; i++) {
+         if (reqpage != i) {
+            vm_page_free(pages[i]);
+         }
+         vm_page_unlock_queues();
+         VM_OBJECT_UNLOCK(object);
+         return VM_PAGER_ERROR;
+      }
+   }
+
+   size = count - uio.uio_resid;
+
+   vm_page_lock_queues();
+   for (i = 0, toff = 0; i < npages; i++, toff = nextoff) {
+      struct vm_page *mt;
+
+      mt = pages[i];
+      nextoff = toff + PAGE_SIZE;
+      if (nextoff <= size) {
+         /* Read filled an entire page */
+         mt->valid = VM_PAGE_BITS_ALL;
+         KASSERT(mt->dirty == 0, ("HgfsGetPages: page %p is dirty\n", mt));
+      }
+      else if (size > toff) {
+         /* Read filled a partial page */
+         mt->valid = 0;
+         vm_page_set_valid(mt, 0, size - toff);
+         KASSERT(mt->dirty == 0, ("HgfsGetPages: page %p is dirty\n", mt));
+      }
+      else {
+         /*
+          * Read operation was short. If no error occurred, leave m->valid
+          * as zero and the pager will call vm_page_zero_invalid() to zero
+          * fill the non-valid portions of the page. This often denots that
+          * an end of file has been mapped into memory and the file's size
+          * is not page aligned (vm_pager.c:vm_page_zero_invalid()).
+          */
+         ;
+      }
+
+      if (i != reqpage) {
+         if (!error) {
+            if (mt->oflags & VPO_WANTED)
+               vm_page_activate(mt);
+            else
+               vm_page_deactivate(mt);
+            vm_page_wakeup(mt);
+         }
+         else {
+            vm_page_free(mt);
+         }
+      }
+   }
+   vm_page_unlock_queues();
+   VM_OBJECT_UNLOCK(object);
+   if (error) {
+      printf("HgfsGetPages: Read I/O error: %d\n", error);
+   }
+   return (error ? VM_PAGER_ERROR : VM_PAGER_OK);
+}
+
+/*
+ *----------------------------------------------------------------------------
+ *
+ * HgfsPutPagesInt --
+ *
+ *      HgfsPutPagesInt is invoked to write dirty pages to the backing store.
+ *
+ * Results:
+ *      VM_PAGER_OK on success or VM_PAGER_ERROR otherwise.
+ *
+ * Side effects:
+ *
+ *----------------------------------------------------------------------------
+ */
+
+int
+HgfsPutPagesInt(struct vnode *vp,
+                vm_page_t *pages,
+                int count,
+                int *rtvals)
+{
+   int            i, npages, error;
+   struct uio     uio;
+   struct iovec   iov;
+   struct buf    *bp;
+   vm_offset_t    kva;
+
+   npages = btoc(count);
+
+   printf("********** HgfsVopPutPages *************\n");
+   printf("count:     %d\n", count);
+
+   for (i = 0; i < npages; i++) {
+      rtvals[i] = VM_PAGER_AGAIN;
+   }
+
+   /* Obtain a buffer and a temporary mapping */
+   bp  = getpbuf(&hgfs_pbuf_freecnt);
+   kva = (vm_offset_t) bp->b_data;
+   pmap_qenter(kva, pages, npages);
+
+   iov.iov_base   = (caddr_t) kva;
+   iov.iov_len    = count;
+   uio.uio_iov    = &iov;
+   uio.uio_iovcnt = 1;
+   uio.uio_offset = IDX_TO_OFF(pages[0]->pindex);
+   uio.uio_resid  = count;
+   uio.uio_segflg = UIO_SYSSPACE;
+   uio.uio_rw     = UIO_WRITE;
+   uio.uio_td     = curthread;
+
+   error = HgfsWriteInt(vp, &uio, 0, TRUE);
+
+   /* Remove temporary mappings and release physical buffer */
+   pmap_qremove(kva, npages);
+   relpbuf(bp, &hgfs_pbuf_freecnt);
+
+   /* Tell the pager how many pages were written and undirty the pages */
+   if (!error) {
+      int nwritten = round_page(count - uio.uio_resid) / PAGE_SIZE;
+      vm_page_lock_queues();
+      for (i = 0; i < nwritten; i++) {
+         rtvals[i] = VM_PAGER_OK;
+         vm_page_undirty(pages[i]);
+      }
+      vm_page_unlock_queues();
+   }
+   return rtvals[0];
+}
diff -uNr open-vm-tools-2010.09.19-301124/modules/freebsd/vmhgfs/vnopscommon.h open-vm-tools/modules/freebsd/vmhgfs/vnopscommon.h
--- open-vm-tools-2010.09.19-301124/modules/freebsd/vmhgfs/vnopscommon.h        2010-09-20 18:30:55.000000000 +0000
+++ open-vm-tools/modules/freebsd/vmhgfs/vnopscommon.h  2010-10-18 02:42:15.000000000 +0000
@@ -90,5 +90,8 @@
                    char *targetName);
 int HgfsMmapInt(struct vnode *vp, int accessMode);
 int HgfsMnomapInt(struct vnode *vp);
+int HgfsGetPagesInt(struct vnode *vp, vm_page_t *pages, int count, int reqpage);
+int HgfsPutPagesInt(struct vnode *vp, vm_page_t *pages, int count, int *rtvals);
+

#endif // _HGFS_VNOPS_COMMON_H_

RE: FreeBSD 8.1 VMHGFS patch

[Mr I. L. <iva...@uq...>]

Hi there Jain!

No problem, I've sent in the agreement and I'm waiting on the approval. I've also got 
a small update on the VMHGFS memory leaks. I've written up  a small patch files that work 
against the previous one. It just frees up all the resources allocated for the HgfsFile's along 
with the files themselves. Right now there appear to be no memory leaks left with no warning 
messages reported.  I'm also checking out some interesting bugs which I haven't quite tracked 
down the cause of yet. Back to the memory leak patch, I'm looking for some request-for-comments 
as it's still a work in progress so I'm still doing a lot of tests to make sure it's all fine, but here's an overview 
of the changes/additions:

state.h    - added two macros from state.c for code reuse as they're used in vfsops.c
state.c    - removed macros mentioned above
vfsops.c - just a simple loop through the hash table with calls to HgfsReleaseVnodeContext() to free up resources

Here's the patch, so until next time!

--- open-vm-tools-2010.09.19-301124/modules/freebsd/vmhgfs/vfsops.c	2010-10-13 00:04:57.000000000 +0000
+++ open-vm-tools/modules/freebsd/vmhgfs/vfsops.c	2010-10-12 23:49:46.000000000 +0000
@@ -291,20 +291,24 @@
 #endif
 {
    HgfsSuperInfo *sip;
+   HgfsFileHashTable *htp;
    int ret = 0;
    int flags = 0;
+   int i;
 
    sip = (HgfsSuperInfo *)mp->mnt_data;
 
    ASSERT(sip);
 
+   htp = &sip->fileHashTable;
+    
    /*
     * If there are pending requests & we're not being forced out, tell the user
     * that we're still busy.
     */
    if (((mntflags & MNT_FORCE) == 0) &&
        ((HgfsKReq_ContainerIsEmpty(sip->reqs) == FALSE) ||
-        (HgfsFileHashTableIsEmpty(sip, &sip->fileHashTable) == FALSE))) {
+        (HgfsFileHashTableIsEmpty(sip, htp) == FALSE))) {
       return EBUSY;
    }
 
@@ -325,10 +329,21 @@
       return ret;
    }
 
-   /* Release the root file's data structures */
-   HgfsReleaseVnodeContext(sip->rootVnode, &sip->fileHashTable);
-
-   HgfsDestroyFileHashTable(&sip->fileHashTable);
+   /* 
+    * Release all the data structures associate with the allocated files 
+    * that have been placed into the hash table during the module's lifetime
+    */
+   for (i = 0; i < ARRAYSIZE(htp->hashTable); i++) {
+      DblLnkLst_Links *currNode = HGFS_FILE_HT_HEAD(htp, i);
+ 
+   while (currNode != HGFS_FILE_HT_BUCKET(htp, i)) {
+         HgfsFile *currFile = DblLnkLst_Container(currNode, HgfsFile, listNode);
+	 currNode = currNode->next;
+         HgfsReleaseVnodeContext(currFile->vnodep, htp);        
+      } 
+   }
+   
+   HgfsDestroyFileHashTable(htp);
 
    /*
     * Now we can throw away our superinfo.  Let's reclaim everything allocated

--- open-vm-tools-2010.09.19-301124/modules/freebsd/vmhgfs/state.c	2010-10-13 00:04:57.000000000 +0000
+++ open-vm-tools/modules/freebsd/vmhgfs/state.c	2010-10-12 10:25:59.000000000 +0000
@@ -53,9 +53,6 @@
  * Macros
  */
 
-#define HGFS_FILE_HT_HEAD(ht, index)    (ht->hashTable[index]).next
-#define HGFS_FILE_HT_BUCKET(ht, index)  (&ht->hashTable[index])
-
 #define HGFS_IS_ROOT_FILE(sip, file)    (HGFS_VP_TO_FP(sip->rootVnode) == file)
 #define LCK_MTX_ASSERT(mutex)

--- open-vm-tools-2010.09.19-301124/modules/freebsd/vmhgfs/state.h	2010-09-20 18:30:55.000000000 +0000
+++ open-vm-tools/modules/freebsd/vmhgfs/state.h	2010-10-12 10:25:42.000000000 +0000
@@ -80,6 +80,8 @@
 #define HGFS_VP_TO_FILESIZE(vp)                          \
          HGFS_VP_TO_FP(vp)->fileSize
 
+#define HGFS_FILE_HT_HEAD(ht, index)    (ht->hashTable[index]).next
+#define HGFS_FILE_HT_BUCKET(ht, index)  (&ht->hashTable[index])
 
 /*
  * Types


________________________________________
From: Shaileshkumar Jain [sa...@vm...]
Sent: Saturday, October 09, 2010 6:16 AM
To: open-vm-tools development
Subject: RE: FreeBSD 8.1 VMHGFS patch

Thanks Ivan for the patch! Before we can do anything could you follow this step ?  http://open-vm-tools.sourceforge.net/contribute.php



Shailesh Jain
________________________________________

RE: FreeBSD 8.1 VMHGFS patch

[Shaileshkumar J. <sa...@vm...>]

Thanks Ivan for the patch! Before we can do anything could you follow this step ?  http://open-vm-tools.sourceforge.net/contribute.php



Shailesh Jain
________________________________________
From: Mr Ivan Lovric [iva...@uq...]
Sent: Monday, October 04, 2010 8:57 PM
To: ope...@li...
Subject: FreeBSD 8.1 VMHGFS patch

 Hi there!

I've been trying to get shared folders working on FreeBSD 8.1 and came to a couple of problems. The following
patch attempts to remedy some of the issues when compiling with regards to the VMHGFS module. It fixes a couple
of compatability issues and also some memory leaks.

With respect to the meomry leaks however, a couple of memory leaks have been solved
(but only for the root vnode as allocated in HgfsMount() The problem remains however as
all the files allocated as the shared folders are used and several allocations are not freed.
For instance, after creating a couple of directories and files, a couple of listings and rm's,
a following warning is given upon unloading the vmhgfs module:

    "Warning: memory type vmhgfs leacking memory on destroy (21 allocations, 14784 bytes leaked)"

These leaks correspond mostly with the file allocations (HgfsFile, in HgfsAllocFile()), and their corresponding synch objects ((modeMutex) and rwlocks (handleLock/rwFileLock(apple)) in  HgfsInitFile(for the mutexes & rwlocks)).
There appear to have been also a couple of small allocations (two of 32 bytes) that have gone missing but these did not occur everytime (I think!) so I seem to have lost track of those, I'll have to do some more testing. A good thing to do I think, in
my opinion, would be to iterate through all the files allocated and free the data structures associated with those files including the file pointers themselves. Any thoughts?

The addition in state.c is necessary otherwise HGFS_VP_TO_SIP(vp) would page fault since vp->_mnt_data would always be NULL.
There are also a few other issues with random crashes that I haven't been able to track down yet such as a freeze on a mkdir on a shared
folder and also in some other seemingly random situations.

I've only tested on FreeBSD 8.1-RELEASE but I will test on 8.2, CURRENT and some older releases shortly.

diff -uNr open-vm-tools-2010.09.19-301124/modules/freebsd/vmhgfs/state.c open-vm-tools/modules/freebsd/vmhgfs/state.c
--- open-vm-tools-2010.09.19-301124/modules/freebsd/vmhgfs/state.c      2010-09-20 18:30:55.000000000 +0000
+++ open-vm-tools/modules/freebsd/vmhgfs/state.c        2010-10-05 00:52:47.000000000 +0000
@@ -761,6 +761,9 @@
       return ret;
    }

+   /* Store pointer to mount point */
+   vp->v_mount = vfsp;
+
    /*
     * Return a locked vnode to the caller.
     */
diff -uNr open-vm-tools-2010.09.19-301124/modules/freebsd/vmhgfs/vfsops.c open-vm-tools/modules/freebsd/vmhgfs/vfsops.c
--- open-vm-tools-2010.09.19-301124/modules/freebsd/vmhgfs/vfsops.c     2010-09-20 18:30:55.000000000 +0000
+++ open-vm-tools/modules/freebsd/vmhgfs/vfsops.c       2010-10-05 00:52:47.000000000 +0000
@@ -32,6 +32,9 @@
 #if __FreeBSD_version >= 700000
 #include <sys/priv.h>
 #endif
+#include <sys/fcntl.h>
+#include <sys/uio.h>
+#include <sys/types.h>

 #include "hgfs_kernel.h"
 #include "request.h"
@@ -109,8 +112,12 @@
  */

 static int
+#if __FreeBSD_version >= 800011
+HgfsVfsMount(struct mount *mp)  // IN: structure representing the file systems
+#else
 HgfsVfsMount(struct mount *mp,  // IN: structure representing the file system
              struct thread *td) // IN: thread which is mounting the file system
+#endif
 {
    HgfsSuperInfo *sip;
    struct vnode *vp;
@@ -145,7 +152,7 @@
     * Since Hgfs requires the caller to be root, only allow mount attempts made
     * by the superuser.
     */
-   if ((ret = suser(td)) != 0) {
+   if ((ret = compat_priv_check(compat_td, PRIV_DRIVER)) != 0) {
       return ret;
    }

@@ -176,7 +183,7 @@
    sip->rootVnode = vp;

    /* We're finished with the root vnode, so unlock it. */
-   COMPAT_VOP_UNLOCK(vp, 0, td);
+   COMPAT_VOP_UNLOCK(vp, 0, compat_td);

    /*
     * Initialize this file system's Hgfs requests container.
@@ -277,7 +284,11 @@
  */

 static int
+#if __FreeBSD_version >= 800011
+HgfsVfsUnmount(struct mount *mp, int mntflags)
+#else
 HgfsVfsUnmount(struct mount *mp, int mntflags, struct thread *td)
+#endif
 {
    HgfsSuperInfo *sip;
    int ret = 0;
@@ -309,11 +320,14 @@
    /*
     * Vflush will wait until all pending vnode operations are complete.
     */
-   ret = vflush(mp, 1, flags, td);
+   ret = vflush(mp, 1, flags, compat_td);
    if (ret != 0) {
       return ret;
    }

+   /* Release the root file's data structures */
+   HgfsReleaseVnodeContext(sip->rootVnode, &sip->fileHashTable);
+
    HgfsDestroyFileHashTable(&sip->fileHashTable);

    /*
@@ -348,7 +362,11 @@
  */

 static int
+#if __FreeBSD_version >= 800011
+HgfsVfsStatfs(struct mount *mp, struct statfs *sbp)
+#else
 HgfsVfsStatfs(struct mount *mp, struct statfs *sbp, struct thread *td)
+#endif
 {
    int ret = 0;
    struct vnode *vp;
@@ -361,8 +379,11 @@
     * we got from a call to vfs_getnewfsid() in HgfsVfsMount()
     */
    bcopy(&mp->mnt_stat, sbp, sizeof mp->mnt_stat);
-
-   ret = HgfsVfsRoot(mp, LK_SHARED, &vp, td);
+#if __FreeBSD_version >= 800011
+   ret = HgfsVfsRoot(mp, LK_SHARED, &vp);
+#else
+   ret = HgfsVfsRoot(mp, LK_SHARED, &vp, compat_td);
+#endif
    if (ret) {
       DEBUG(VM_DEBUG_FAIL, "HgfsVfsRoot failed\n");
       return ret;
@@ -397,17 +418,23 @@
  */

 static int
-HgfsVfsRoot(struct mount *mp,   // IN: Filesystem structure
-            int flags,          // IN: Flags to vget
+#if __FreeBSD_version >= 800011
+HgfsVfsRoot(struct mount *mp,   // IN:  Filesystem structure
+                int flags,                  // IN:  Flags to vget
+                struct vnode **vpp) // OUT: Address of root vnode
+#else
+HgfsVfsRoot(struct mount *mp,   // IN:  Filesystem structure
+            int flags,          // IN:  Flags to vget
             struct vnode **vpp, // OUT: Address of root vnode
-            struct thread *td)  // IN: Thread structure
+            struct thread *td)  // IN:  Thread structure
+#endif
 {
    HgfsSuperInfo *sip = (HgfsSuperInfo *)mp->mnt_data;
    int ret = 0;

    *vpp = NULL;

-   ret = vget(sip->rootVnode, flags, td);
+   ret = vget(sip->rootVnode, flags, compat_td);
    if (ret == 0) {
       *vpp = sip->rootVnode;
    }
diff -uNr open-vm-tools-2010.09.19-301124/modules/freebsd/vmhgfs/vnops.c open-vm-tools/modules/freebsd/vmhgfs/vnops.c
--- open-vm-tools-2010.09.19-301124/modules/freebsd/vmhgfs/vnops.c      2010-09-20 18:30:55.000000000 +0000
+++ open-vm-tools/modules/freebsd/vmhgfs/vnops.c        2010-10-05 00:52:47.000000000 +0000
@@ -42,6 +42,7 @@
 #include "debug.h"
 #include "fsutil.h"
 #include "vnopscommon.h"
+#include "compat_vop.h"


 /*
@@ -325,7 +326,7 @@
 */
 {
    struct vnode *vp = ap->a_vp;
-   int mode = ap->a_mode;
+   compat_accmode_t mode = ap->compat_a_accmode;
    HgfsAccessMode accessMode = 0;
    Bool isDir = vp->v_type == VDIR;
    if (mode & VREAD) {

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
_______________________________________________
open-vm-tools-devel mailing list
ope...@li...
https://lists.sourceforge.net/lists/listinfo/open-vm-tools-devel

FreeBSD 8.1 VMHGFS patch

[Mr I. L. <iva...@uq...>]

 Hi there!

I've been trying to get shared folders working on FreeBSD 8.1 and came to a couple of problems. The following
patch attempts to remedy some of the issues when compiling with regards to the VMHGFS module. It fixes a couple
of compatability issues and also some memory leaks.

With respect to the meomry leaks however, a couple of memory leaks have been solved
(but only for the root vnode as allocated in HgfsMount() The problem remains however as
all the files allocated as the shared folders are used and several allocations are not freed.
For instance, after creating a couple of directories and files, a couple of listings and rm's,
a following warning is given upon unloading the vmhgfs module:

    "Warning: memory type vmhgfs leacking memory on destroy (21 allocations, 14784 bytes leaked)"

These leaks correspond mostly with the file allocations (HgfsFile, in HgfsAllocFile()), and their corresponding synch objects ((modeMutex) and rwlocks (handleLock/rwFileLock(apple)) in  HgfsInitFile(for the mutexes & rwlocks)). 
There appear to have been also a couple of small allocations (two of 32 bytes) that have gone missing but these did not occur everytime (I think!) so I seem to have lost track of those, I'll have to do some more testing. A good thing to do I think, in
my opinion, would be to iterate through all the files allocated and free the data structures associated with those files including the file pointers themselves. Any thoughts?

The addition in state.c is necessary otherwise HGFS_VP_TO_SIP(vp) would page fault since vp->_mnt_data would always be NULL.
There are also a few other issues with random crashes that I haven't been able to track down yet such as a freeze on a mkdir on a shared
folder and also in some other seemingly random situations.

I've only tested on FreeBSD 8.1-RELEASE but I will test on 8.2, CURRENT and some older releases shortly.

diff -uNr open-vm-tools-2010.09.19-301124/modules/freebsd/vmhgfs/state.c open-vm-tools/modules/freebsd/vmhgfs/state.c
--- open-vm-tools-2010.09.19-301124/modules/freebsd/vmhgfs/state.c      2010-09-20 18:30:55.000000000 +0000
+++ open-vm-tools/modules/freebsd/vmhgfs/state.c        2010-10-05 00:52:47.000000000 +0000
@@ -761,6 +761,9 @@
       return ret;
    }

+   /* Store pointer to mount point */
+   vp->v_mount = vfsp;
+
    /*
     * Return a locked vnode to the caller.
     */
diff -uNr open-vm-tools-2010.09.19-301124/modules/freebsd/vmhgfs/vfsops.c open-vm-tools/modules/freebsd/vmhgfs/vfsops.c
--- open-vm-tools-2010.09.19-301124/modules/freebsd/vmhgfs/vfsops.c     2010-09-20 18:30:55.000000000 +0000
+++ open-vm-tools/modules/freebsd/vmhgfs/vfsops.c       2010-10-05 00:52:47.000000000 +0000
@@ -32,6 +32,9 @@
 #if __FreeBSD_version >= 700000
 #include <sys/priv.h>
 #endif
+#include <sys/fcntl.h>
+#include <sys/uio.h>
+#include <sys/types.h>

 #include "hgfs_kernel.h"
 #include "request.h"
@@ -109,8 +112,12 @@
  */

 static int
+#if __FreeBSD_version >= 800011
+HgfsVfsMount(struct mount *mp)  // IN: structure representing the file systems
+#else
 HgfsVfsMount(struct mount *mp,  // IN: structure representing the file system
              struct thread *td) // IN: thread which is mounting the file system
+#endif
 {
    HgfsSuperInfo *sip;
    struct vnode *vp;
@@ -145,7 +152,7 @@
     * Since Hgfs requires the caller to be root, only allow mount attempts made
     * by the superuser.
     */
-   if ((ret = suser(td)) != 0) {
+   if ((ret = compat_priv_check(compat_td, PRIV_DRIVER)) != 0) {
       return ret;
    }

@@ -176,7 +183,7 @@
    sip->rootVnode = vp;

    /* We're finished with the root vnode, so unlock it. */
-   COMPAT_VOP_UNLOCK(vp, 0, td);
+   COMPAT_VOP_UNLOCK(vp, 0, compat_td);

    /*
     * Initialize this file system's Hgfs requests container.
@@ -277,7 +284,11 @@
  */

 static int
+#if __FreeBSD_version >= 800011
+HgfsVfsUnmount(struct mount *mp, int mntflags)
+#else
 HgfsVfsUnmount(struct mount *mp, int mntflags, struct thread *td)
+#endif
 {
    HgfsSuperInfo *sip;
    int ret = 0;
@@ -309,11 +320,14 @@
    /*
     * Vflush will wait until all pending vnode operations are complete.
     */
-   ret = vflush(mp, 1, flags, td);
+   ret = vflush(mp, 1, flags, compat_td);
    if (ret != 0) {
       return ret;
    }

+   /* Release the root file's data structures */
+   HgfsReleaseVnodeContext(sip->rootVnode, &sip->fileHashTable);
+
    HgfsDestroyFileHashTable(&sip->fileHashTable);

    /*
@@ -348,7 +362,11 @@
  */

 static int
+#if __FreeBSD_version >= 800011
+HgfsVfsStatfs(struct mount *mp, struct statfs *sbp)
+#else
 HgfsVfsStatfs(struct mount *mp, struct statfs *sbp, struct thread *td)
+#endif
 {
    int ret = 0;
    struct vnode *vp;
@@ -361,8 +379,11 @@
     * we got from a call to vfs_getnewfsid() in HgfsVfsMount()
     */
    bcopy(&mp->mnt_stat, sbp, sizeof mp->mnt_stat);
-
-   ret = HgfsVfsRoot(mp, LK_SHARED, &vp, td);
+#if __FreeBSD_version >= 800011
+   ret = HgfsVfsRoot(mp, LK_SHARED, &vp);
+#else
+   ret = HgfsVfsRoot(mp, LK_SHARED, &vp, compat_td);
+#endif
    if (ret) {
       DEBUG(VM_DEBUG_FAIL, "HgfsVfsRoot failed\n");
       return ret;
@@ -397,17 +418,23 @@
  */

 static int
-HgfsVfsRoot(struct mount *mp,   // IN: Filesystem structure
-            int flags,          // IN: Flags to vget
+#if __FreeBSD_version >= 800011
+HgfsVfsRoot(struct mount *mp,   // IN:  Filesystem structure
+                int flags,                  // IN:  Flags to vget
+                struct vnode **vpp) // OUT: Address of root vnode
+#else
+HgfsVfsRoot(struct mount *mp,   // IN:  Filesystem structure
+            int flags,          // IN:  Flags to vget
             struct vnode **vpp, // OUT: Address of root vnode
-            struct thread *td)  // IN: Thread structure
+            struct thread *td)  // IN:  Thread structure
+#endif
 {
    HgfsSuperInfo *sip = (HgfsSuperInfo *)mp->mnt_data;
    int ret = 0;

    *vpp = NULL;

-   ret = vget(sip->rootVnode, flags, td);
+   ret = vget(sip->rootVnode, flags, compat_td);
    if (ret == 0) {
       *vpp = sip->rootVnode;
    }
diff -uNr open-vm-tools-2010.09.19-301124/modules/freebsd/vmhgfs/vnops.c open-vm-tools/modules/freebsd/vmhgfs/vnops.c
--- open-vm-tools-2010.09.19-301124/modules/freebsd/vmhgfs/vnops.c      2010-09-20 18:30:55.000000000 +0000
+++ open-vm-tools/modules/freebsd/vmhgfs/vnops.c        2010-10-05 00:52:47.000000000 +0000
@@ -42,6 +42,7 @@
 #include "debug.h"
 #include "fsutil.h"
 #include "vnopscommon.h"
+#include "compat_vop.h"


 /*
@@ -325,7 +326,7 @@
 */
 {
    struct vnode *vp = ap->a_vp;
-   int mode = ap->a_mode;
+   compat_accmode_t mode = ap->compat_a_accmode;
    HgfsAccessMode accessMode = 0;
    Bool isDir = vp->v_type == VDIR;
    if (mode & VREAD) {

[ open-vm-tools-Tracker-3073585 ] Out of memory and high cpu usage

[SourceForge.net <no...@so...>]

Tracker item #3073585, was opened at 2010-09-22 12:40
Message generated for change (Comment added) made by mvanzin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3073585&group_id=204462

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: guestd
Group: v1.0 (example)
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Kleber  Rocha (kleberrocha)
Assigned to: Nobody/Anonymous (nobody)
Summary: Out of memory and high cpu usage

Initial Comment:
On Fedora 13 32bits open-vm-tools get all cpu and memory and freeze.

----------------------------------------------------------------------

>Comment By: Marcelo Vanzin (mvanzin)
Date: 2010-09-22 14:36

Message:
To try to fix whatever problem you're running into, we'd at least need logs
to know what's going on, since nobody in our internal QA has reported
similar issues. It might be a problem with some patch Fedora may have
applied, but again, without logs it will be really hard to figure out.

I don't generally follow updates for older releases of ESX, so I don't
know how the distro support for ESX 3.5 is looking these days.

----------------------------------------------------------------------

Comment By: Kleber  Rocha (kleberrocha)
Date: 2010-09-22 13:51

Message:
I agree, but the vmware-tools shipped with exx3.5 don't work with fedora, I
turn off the open-vm-tools and the system work fine, what do you recommend?
change fedora or exist other way to work with fedora?

Thanks

----------------------------------------------------------------------

Comment By: Marcelo Vanzin (mvanzin)
Date: 2010-09-22 13:47

Message:
You really shouldn't be using open-vm-tools in a production environment,
since they're not officially supported by VMware. We always recommend you
use the VMware Tools shipped with your VMware product.

Without any logs it's gonna be hard to know what's going on.

----------------------------------------------------------------------

Comment By: Kleber  Rocha (kleberrocha)
Date: 2010-09-22 13:44

Message:
I use packages from rpmfusion. 
open-vm-tools-libs-0.0.0.243334-1.fc13.i686
open-vm-tools-0.0.0.243334-1.fc13.i686
akmod-open-vm-tools-0.0.0.243334-1.fc13.5.i686
kmod-open-vm-tools-2.6.34.7-56.fc13.i686-0.0.0.243334-1.fc13.17.i686

The version is: 8.4.1.1212 (build-243334)
We use ESX 3.5
The system freeze with kernel panic - Out of memory
The process that get all cpu: is vmtoolsd
No, this machine is production, and I can't stop this system to test with
log.

Thanks

----------------------------------------------------------------------

Comment By: Marcelo Vanzin (mvanzin)
Date: 2010-09-22 13:33

Message:
There's not enough information here to do anything.

. which version of open-vm-tools are you running?
. which VMware product are you running?
. what does "freeze" mean?
. what's the process that's using all the CPU?
. have you tried to enable logging and see if any useful information shows
up?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3073585&group_id=204462

[ open-vm-tools-Tracker-3073585 ] Out of memory and high cpu usage

[SourceForge.net <no...@so...>]

Tracker item #3073585, was opened at 2010-09-22 16:40
Message generated for change (Comment added) made by kleberrocha
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3073585&group_id=204462

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: guestd
Group: v1.0 (example)
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Kleber  Rocha (kleberrocha)
Assigned to: Nobody/Anonymous (nobody)
Summary: Out of memory and high cpu usage

Initial Comment:
On Fedora 13 32bits open-vm-tools get all cpu and memory and freeze.

----------------------------------------------------------------------

>Comment By: Kleber  Rocha (kleberrocha)
Date: 2010-09-22 17:51

Message:
I agree, but the vmware-tools shipped with exx3.5 don't work with fedora, I
turn off the open-vm-tools and the system work fine, what do you recommend?
change fedora or exist other way to work with fedora?

Thanks

----------------------------------------------------------------------

Comment By: Marcelo Vanzin (mvanzin)
Date: 2010-09-22 17:47

Message:
You really shouldn't be using open-vm-tools in a production environment,
since they're not officially supported by VMware. We always recommend you
use the VMware Tools shipped with your VMware product.

Without any logs it's gonna be hard to know what's going on.

----------------------------------------------------------------------

Comment By: Kleber  Rocha (kleberrocha)
Date: 2010-09-22 17:44

Message:
I use packages from rpmfusion. 
open-vm-tools-libs-0.0.0.243334-1.fc13.i686
open-vm-tools-0.0.0.243334-1.fc13.i686
akmod-open-vm-tools-0.0.0.243334-1.fc13.5.i686
kmod-open-vm-tools-2.6.34.7-56.fc13.i686-0.0.0.243334-1.fc13.17.i686

The version is: 8.4.1.1212 (build-243334)
We use ESX 3.5
The system freeze with kernel panic - Out of memory
The process that get all cpu: is vmtoolsd
No, this machine is production, and I can't stop this system to test with
log.

Thanks

----------------------------------------------------------------------

Comment By: Marcelo Vanzin (mvanzin)
Date: 2010-09-22 17:33

Message:
There's not enough information here to do anything.

. which version of open-vm-tools are you running?
. which VMware product are you running?
. what does "freeze" mean?
. what's the process that's using all the CPU?
. have you tried to enable logging and see if any useful information shows
up?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3073585&group_id=204462

[ open-vm-tools-Tracker-3073585 ] Out of memory and high cpu usage

[SourceForge.net <no...@so...>]

Tracker item #3073585, was opened at 2010-09-22 12:40
Message generated for change (Comment added) made by mvanzin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3073585&group_id=204462

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: guestd
Group: v1.0 (example)
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Kleber  Rocha (kleberrocha)
Assigned to: Nobody/Anonymous (nobody)
Summary: Out of memory and high cpu usage

Initial Comment:
On Fedora 13 32bits open-vm-tools get all cpu and memory and freeze.

----------------------------------------------------------------------

>Comment By: Marcelo Vanzin (mvanzin)
Date: 2010-09-22 13:47

Message:
You really shouldn't be using open-vm-tools in a production environment,
since they're not officially supported by VMware. We always recommend you
use the VMware Tools shipped with your VMware product.

Without any logs it's gonna be hard to know what's going on.

----------------------------------------------------------------------

Comment By: Kleber  Rocha (kleberrocha)
Date: 2010-09-22 13:44

Message:
I use packages from rpmfusion. 
open-vm-tools-libs-0.0.0.243334-1.fc13.i686
open-vm-tools-0.0.0.243334-1.fc13.i686
akmod-open-vm-tools-0.0.0.243334-1.fc13.5.i686
kmod-open-vm-tools-2.6.34.7-56.fc13.i686-0.0.0.243334-1.fc13.17.i686

The version is: 8.4.1.1212 (build-243334)
We use ESX 3.5
The system freeze with kernel panic - Out of memory
The process that get all cpu: is vmtoolsd
No, this machine is production, and I can't stop this system to test with
log.

Thanks

----------------------------------------------------------------------

Comment By: Marcelo Vanzin (mvanzin)
Date: 2010-09-22 13:33

Message:
There's not enough information here to do anything.

. which version of open-vm-tools are you running?
. which VMware product are you running?
. what does "freeze" mean?
. what's the process that's using all the CPU?
. have you tried to enable logging and see if any useful information shows
up?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3073585&group_id=204462

[ open-vm-tools-Tracker-3073585 ] Out of memory and high cpu usage

[SourceForge.net <no...@so...>]

Tracker item #3073585, was opened at 2010-09-22 16:40
Message generated for change (Comment added) made by kleberrocha
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3073585&group_id=204462

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: guestd
Group: v1.0 (example)
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Kleber  Rocha (kleberrocha)
Assigned to: Nobody/Anonymous (nobody)
Summary: Out of memory and high cpu usage

Initial Comment:
On Fedora 13 32bits open-vm-tools get all cpu and memory and freeze.

----------------------------------------------------------------------

>Comment By: Kleber  Rocha (kleberrocha)
Date: 2010-09-22 17:44

Message:
I use packages from rpmfusion. 
open-vm-tools-libs-0.0.0.243334-1.fc13.i686
open-vm-tools-0.0.0.243334-1.fc13.i686
akmod-open-vm-tools-0.0.0.243334-1.fc13.5.i686
kmod-open-vm-tools-2.6.34.7-56.fc13.i686-0.0.0.243334-1.fc13.17.i686

The version is: 8.4.1.1212 (build-243334)
We use ESX 3.5
The system freeze with kernel panic - Out of memory
The process that get all cpu: is vmtoolsd
No, this machine is production, and I can't stop this system to test with
log.

Thanks

----------------------------------------------------------------------

Comment By: Marcelo Vanzin (mvanzin)
Date: 2010-09-22 17:33

Message:
There's not enough information here to do anything.

. which version of open-vm-tools are you running?
. which VMware product are you running?
. what does "freeze" mean?
. what's the process that's using all the CPU?
. have you tried to enable logging and see if any useful information shows
up?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3073585&group_id=204462

[ open-vm-tools-Tracker-3073627 ] Out of memory and high cpu usage

[SourceForge.net <no...@so...>]

Tracker item #3073627, was opened at 2010-09-22 13:32
Message generated for change (Settings changed) made by mvanzin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3073627&group_id=204462

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: guestd
Group: v1.0 (example)
>Status: Closed
>Resolution: Duplicate
Priority: 5
Private: No
Submitted By: Kleber  Rocha (kleberrocha)
Assigned to: Nobody/Anonymous (nobody)
Summary: Out of memory and high cpu usage

Initial Comment:
On Fedora 13 32bits open-vm-tools get all cpu and memory and freeze.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3073627&group_id=204462

[ open-vm-tools-Tracker-3073585 ] Out of memory and high cpu usage

[SourceForge.net <no...@so...>]

Tracker item #3073585, was opened at 2010-09-22 12:40
Message generated for change (Comment added) made by mvanzin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3073585&group_id=204462

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: guestd
Group: v1.0 (example)
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Kleber  Rocha (kleberrocha)
Assigned to: Nobody/Anonymous (nobody)
Summary: Out of memory and high cpu usage

Initial Comment:
On Fedora 13 32bits open-vm-tools get all cpu and memory and freeze.

----------------------------------------------------------------------

>Comment By: Marcelo Vanzin (mvanzin)
Date: 2010-09-22 13:33

Message:
There's not enough information here to do anything.

. which version of open-vm-tools are you running?
. which VMware product are you running?
. what does "freeze" mean?
. what's the process that's using all the CPU?
. have you tried to enable logging and see if any useful information shows
up?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3073585&group_id=204462

[ open-vm-tools-Tracker-3073627 ] Out of memory and high cpu usage

[SourceForge.net <no...@so...>]

Tracker item #3073627, was opened at 2010-09-22 17:32
Message generated for change (Tracker Item Submitted) made by kleberrocha
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3073627&group_id=204462

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: guestd
Group: v1.0 (example)
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Kleber  Rocha (kleberrocha)
Assigned to: Nobody/Anonymous (nobody)
Summary: Out of memory and high cpu usage

Initial Comment:
On Fedora 13 32bits open-vm-tools get all cpu and memory and freeze.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3073627&group_id=204462

[ open-vm-tools-Tracker-3073585 ] Out of memory and high cpu usage

[SourceForge.net <no...@so...>]

Tracker item #3073585, was opened at 2010-09-22 16:40
Message generated for change (Tracker Item Submitted) made by kleberrocha
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3073585&group_id=204462

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: guestd
Group: v1.0 (example)
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Kleber  Rocha (kleberrocha)
Assigned to: Nobody/Anonymous (nobody)
Summary: Out of memory and high cpu usage

Initial Comment:
On Fedora 13 32bits open-vm-tools get all cpu and memory and freeze.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3073585&group_id=204462

Re: Soft Power Down via vmtools

[Marcelo V. <mv...@vm...>]

On 09/08/2010 03:07 PM, Bill Rees wrote:
> Is there a description of how vmtools power control works?  For instance, how
> does the power button signal trigger the poweroff-vm-default script?

There isn't a formal spec that I know of, but from the tools side, all action
regarding power scripts happens in the powerOps plugin (source in
open-vm-tools/services/plugins/powerOps).

The host has to explicitly send a "power op request" to tools for the scripts to
run. On Workstation, that would be the "Shut Down Guest" command (while "Power
Off" is like pulling the power cord).

-- 
- Marcelo

Soft Power Down via vmtools

[Bill R. <br...@ov...>]

   Is there a description of how vmtools power control works?  For instance, how does the power button signal trigger the poweroff-vm-default script?

WH

Re: Xorg 'vmware' driver && Skype local view

[Matthias A. <gu...@un...>]

El día Tuesday, September 07, 2010 a las 06:23:53PM +0200, Thomas Hellstrom escribió:

> Please file a bugreport in bugzilla.freedesktop.org!
> Looking briefly at the problem, it appears like skype is requesting an 
> overlay format that the vmware driver doesn't provide, so I don't think 
> it's a bug. But if this is a common use-case we could perhaps look into 
> what format skype is requesting and see if we could eventually support it.
> 
> /Thomas

done.

https://bugs.freedesktop.org/show_bug.cgi?id=30079

Thanks

	matthias

-- 
Matthias Apitz
t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211
e <gu...@un...> - w http://www.unixarea.de/
Solidarity with the zionistic pirates of Israel?   Not in my  name!
¿Solidaridad con los piratas sionistas de Israel? ¡No en mi nombre!

Re: Xorg 'vmware' driver && Skype local view

[Dmitry T. <dt...@vm...>]

Hi Matthias,

On Tuesday, September 07, 2010 03:56:22 am Matthias Apitz wrote:
> Hello,
> 
> I've the following environment:
> 
> host: Win7, VMWare-player
> guest: FreeBSD 8-CURRENT, Xorg-7.4.1, open-vm-tools-253958 (from FreeBSD'
> ports collection)
> 
> The attached USB video cam Philips product 0x0329 works fine in Skype in
> the above environment, with one small exception: the local view is not
> presented in Skype and probing for it says on stdout:
> 
> $ skype
> Starting the process...
> Skype Xv: Xv ports available: 1
> Skype XShm: XShm support enabled
> Skype Xv: Using Xv port 56
> Skype Xv: No suitable overlay format found
> 
> An xvinfo gives the following output about the vmware driver:
> 
> $ xvinfo
> X-Video Extension version 2.2
> screen #0
>   Adaptor #0: "VMware Video Engine"
>     number of ports: 1
>     port base: 56
>     operations supported: PutImage
>     supported visuals:
>       depth 24, visualID 0x21
>     number of attributes: 2
>       "XV_COLORKEY" (range 0 to 16777215)
>               client settable attribute
>               client gettable attribute
>       "XV_AUTOPAINT_COLORKEY" (range 0 to 1)
>               client settable attribute
>               client gettable attribute
>     maximum XvImage size: 2048 x 2048
>     Number of image formats: 3
>       id: 0x32315659 (YV12)
>         guid: 59563132-0000-0010-8000-00aa00389b71
>         bits per pixel: 12
>         number of planes: 3
>         type: YUV (planar)
>       id: 0x32595559 (YUY2)
>         guid: 59555932-0000-0010-8000-00aa00389b71
>         bits per pixel: 16
>         number of planes: 1
>         type: YUV (packed)
>       id: 0x59565955 (UYVY)
>         guid: 55595659-0000-0010-8000-00aa00389b71
>         bits per pixel: 16
>         number of planes: 1
>         type: YUV (packed)
> 
> Additional note: without virtualization I'm using in an binary identical
> system the NVidia driver and this does not show this problem.
> 
> Any ideas? Should I file a bug report?

VMware X video driver is a part of Xorg proper so I believe bug report should 
be filed there.

Thomas, is there a separate bugzilla/mailing list for the driver or should 
Matthias use bugzilla.freedsktop.org?

Thanks.

-- 
Dmitry

Xorg 'vmware' driver && Skype local view

[Matthias A. <gu...@un...>]

Hello,

I've the following environment:

host: Win7, VMWare-player
guest: FreeBSD 8-CURRENT, Xorg-7.4.1, open-vm-tools-253958 (from FreeBSD' ports collection)

The attached USB video cam Philips product 0x0329 works fine in Skype in
the above environment, with one small exception: the local view is not
presented in Skype and probing for it says on stdout:

$ skype
Starting the process...
Skype Xv: Xv ports available: 1
Skype XShm: XShm support enabled
Skype Xv: Using Xv port 56
Skype Xv: No suitable overlay format found

An xvinfo gives the following output about the vmware driver:

$ xvinfo
X-Video Extension version 2.2
screen #0
  Adaptor #0: "VMware Video Engine"
    number of ports: 1
    port base: 56
    operations supported: PutImage 
    supported visuals:
      depth 24, visualID 0x21
    number of attributes: 2
      "XV_COLORKEY" (range 0 to 16777215)
              client settable attribute
              client gettable attribute
      "XV_AUTOPAINT_COLORKEY" (range 0 to 1)
              client settable attribute
              client gettable attribute
    maximum XvImage size: 2048 x 2048
    Number of image formats: 3
      id: 0x32315659 (YV12)
        guid: 59563132-0000-0010-8000-00aa00389b71
        bits per pixel: 12
        number of planes: 3
        type: YUV (planar)
      id: 0x32595559 (YUY2)
        guid: 59555932-0000-0010-8000-00aa00389b71
        bits per pixel: 16
        number of planes: 1
        type: YUV (packed)
      id: 0x59565955 (UYVY)
        guid: 55595659-0000-0010-8000-00aa00389b71
        bits per pixel: 16
        number of planes: 1
        type: YUV (packed)

Additional note: without virtualization I'm using in an binary identical
system the NVidia driver and this does not show this problem.

Any ideas? Should I file a bug report?

Thanks in advance

	matthias
-- 
Matthias Apitz
t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211
e <gu...@un...> - w http://www.unixarea.de/
Solidarity with the zionistic pirates of Israel?   Not in my  name!
¿Solidaridad con los piratas sionistas de Israel? ¡No en mi nombre!

[ open-vm-tools-Tracker-3026491 ] build on uclibc fails due to missing ecvt()

[SourceForge.net <no...@so...>]

Tracker item #3026491, was opened at 2010-07-07 20:31
Message generated for change (Tracker Item Submitted) made by ncopa
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3026491&group_id=204462

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: libraries
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Natanael Copa (ncopa)
Assigned to: Nobody/Anonymous (nobody)
Summary: build on uclibc fails due to missing ecvt()

Initial Comment:
When building on linux/uclibc (and after some minor patching) i finally got stuck with this message:
cc1: warnings being treated as errors
bsd_output_shared.c: In function 'dtoa':
bsd_output_shared.c:111: error: implicit declaration of function 'ecvt'

The problem seems to be that uclibc does not provide the ecvt(3) function which the lib/string seens to depend on for the dtoa() implementation.

Would be nice if configure script could check for ecvt() and provide one if the system does not.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3026491&group_id=204462