)]}'
{
  "log": [
    {
      "commit": "3a4d5c94e959359ece6d6b55045c3f046677f55c",
      "tree": "113cfe31540e3d77925837f6990c3284d425bfd1",
      "parents": [
        "5da779c34ccff5e1e617892b6c8bd8260fb1f04c"
      ],
      "author": {
        "name": "Michael S. Tsirkin",
        "email": "mst@redhat.com",
        "time": "Thu Jan 14 06:17:27 2010 +0000"
      },
      "committer": {
        "name": "David S. Miller",
        "email": "davem@davemloft.net",
        "time": "Fri Jan 15 01:43:29 2010 -0800"
      },
      "message": "vhost_net: a kernel-level virtio server\n\nWhat it is: vhost net is a character device that can be used to reduce\nthe number of system calls involved in virtio networking.\nExisting virtio net code is used in the guest without modification.\n\nThere\u0027s similarity with vringfd, with some differences and reduced scope\n- uses eventfd for signalling\n- structures can be moved around in memory at any time (good for\n  migration, bug work-arounds in userspace)\n- write logging is supported (good for migration)\n- support memory table and not just an offset (needed for kvm)\n\ncommon virtio related code has been put in a separate file vhost.c and\ncan be made into a separate module if/when more backends appear.  I used\nRusty\u0027s lguest.c as the source for developing this part : this supplied\nme with witty comments I wouldn\u0027t be able to write myself.\n\nWhat it is not: vhost net is not a bus, and not a generic new system\ncall. No assumptions are made on how guest performs hypercalls.\nUserspace hypervisors are supported as well as kvm.\n\nHow it works: Basically, we connect virtio frontend (configured by\nuserspace) to a backend. The backend could be a network device, or a tap\ndevice.  Backend is also configured by userspace, including vlan/mac\netc.\n\nStatus: This works for me, and I haven\u0027t see any crashes.\nCompared to userspace, people reported improved latency (as I save up to\n4 system calls per packet), as well as better bandwidth and CPU\nutilization.\n\nFeatures that I plan to look at in the future:\n- mergeable buffers\n- zero copy\n- scalability tuning: figure out the best threading model to use\n\nNote on RCU usage (this is also documented in vhost.h, near\nprivate_pointer which is the value protected by this variant of RCU):\nwhat is happening is that the rcu_dereference() is being used in a\nworkqueue item.  The role of rcu_read_lock() is taken on by the start of\nexecution of the workqueue item, of rcu_read_unlock() by the end of\nexecution of the workqueue item, and of synchronize_rcu() by\nflush_workqueue()/flush_work(). In the future we might need to apply\nsome gcc attribute or sparse annotation to the function passed to\nINIT_WORK(). Paul\u0027s ack below is for this RCU usage.\n\n(Includes fixes by Alan Cox \u003calan@linux.intel.com\u003e,\nDavid L Stevens \u003cdlstevens@us.ibm.com\u003e,\nChris Wright \u003cchrisw@redhat.com\u003e)\n\nAcked-by: Rusty Russell \u003crusty@rustcorp.com.au\u003e\nAcked-by: Arnd Bergmann \u003carnd@arndb.de\u003e\nAcked-by: \"Paul E. McKenney\" \u003cpaulmck@linux.vnet.ibm.com\u003e\nSigned-off-by: Michael S. Tsirkin \u003cmst@redhat.com\u003e\nSigned-off-by: David S. Miller \u003cdavem@davemloft.net\u003e\n"
    }
  ]
}