Re: [PATCH RFC 09/12] userns: Convert ocfs2 to use kuid and kgid where appropriate
On Tue, Nov 20, 2012 at 04:43:37AM -0800, Eric W. Biederman wrote: --- a/fs/ocfs2/file.c +++ b/fs/ocfs2/file.c @@ -1116,7 +1116,8 @@ int ocfs2_setattr(struct dentry *dentry, struct iattr *attr) (unsigned long long)OCFS2_I(inode)-ip_blkno, dentry-d_name.len, dentry-d_name.name, attr-ia_valid, attr-ia_mode, - attr-ia_uid, attr-ia_gid); + from_kuid(init_user_ns, attr-ia_uid), + from_kgid(init_user_ns, attr-ia_gid)); Dear Eric, I have a similar question about init_user_ns to Dave. As far as I can tell, using init_user_ns here means we'll never get translations based on the current process namespace. It just so happens that include/linux/user_namespace.h doesn't allow new namespaces yet, but I can't see why we would propagate that knowledge elsewhere. Is there some magic about when init_user_ns should be used regardless? Joel -- Brain: I shall pollute the water supply with this DNAdefibuliser, turning everyone into mindless slaves. Pinky: What about the people who drink bottled water? Brain: Pinky, people who pay 5 dollars for a bottle of water are already mindless slaves. http://www.jlbec.org/ jl...@evilplan.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 10/12] userns: Convert xfs to use kuid/kgid/kprojid where appropriate
On Wed, Nov 21, 2012 at 10:55:24AM +1100, Dave Chinner wrote: diff --git a/fs/xfs/xfs_inode.c b/fs/xfs/xfs_inode.c index 2778258..3656b88 100644 --- a/fs/xfs/xfs_inode.c +++ b/fs/xfs/xfs_inode.c @@ -570,11 +570,12 @@ xfs_dinode_from_disk( to-di_version = from -di_version; to-di_format = from-di_format; to-di_onlink = be16_to_cpu(from-di_onlink); - to-di_uid = be32_to_cpu(from-di_uid); - to-di_gid = be32_to_cpu(from-di_gid); + to-di_uid = make_kuid(init_user_ns, be32_to_cpu(from-di_uid)); + to-di_gid = make_kgid(init_user_ns, be32_to_cpu(from-di_gid)); You can't do this, because the incore inode structure is written directly to the log. This is effectively an on-disk format change. Yeah, I don't get this either. Over in ocfs2, you do the correct thing, translating at the boundary from ocfs2_dinode to struct inode. Joel -- I always thought the hardest questions were those I could not answer. Now I know they are the ones I can never ask. - Charlie Watkins http://www.jlbec.org/ jl...@evilplan.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/27] Latest numa/core release, v16
On Wed, Nov 21, 2012 at 08:37:12PM +0100, Andrea Arcangeli wrote: Hi, On Wed, Nov 21, 2012 at 10:38:59AM +, Mel Gorman wrote: HACKBENCH PIPES 3.7.0 3.7.0 3.7.0 3.7.0 3.7.0 rc6-stats-v4r12 rc6-schednuma-v16r2rc6-autonuma-v28fastr3 rc6-moron-v4r38rc6-twostage-v4r38 Procs 1 0.0320 ( 0.00%) 0.0354 (-10.53%) 0.0410 (-28.28%) 0.0310 ( 3.00%) 0.0296 ( 7.55%) Procs 4 0.0560 ( 0.00%) 0.0699 (-24.87%) 0.0641 (-14.47%) 0.0556 ( 0.79%) 0.0562 ( -0.36%) Procs 8 0.0850 ( 0.00%) 0.1084 (-27.51%) 0.1397 (-64.30%) 0.0833 ( 1.96%) 0.0953 (-12.07%) Procs 12 0.1047 ( 0.00%) 0.1084 ( -3.54%) 0.1789 (-70.91%) 0.0990 ( 5.44%) 0.1127 ( -7.72%) Procs 16 0.1276 ( 0.00%) 0.1323 ( -3.67%) 0.1395 ( -9.34%) 0.1236 ( 3.16%) 0.1240 ( 2.83%) Procs 20 0.1405 ( 0.00%) 0.1578 (-12.29%) 0.2452 (-74.52%) 0.1471 ( -4.73%) 0.1454 ( -3.50%) Procs 24 0.1823 ( 0.00%) 0.1800 ( 1.24%) 0.3030 (-66.22%) 0.1776 ( 2.58%) 0.1574 ( 13.63%) Procs 28 0.2019 ( 0.00%) 0.2143 ( -6.13%) 0.3403 (-68.52%) 0.2000 ( 0.94%) 0.1983 ( 1.78%) Procs 32 0.2162 ( 0.00%) 0.2329 ( -7.71%) 0.6526 (-201.85%) 0.2235 ( -3.36%) 0.2158 ( 0.20%) Procs 36 0.2354 ( 0.00%) 0.2577 ( -9.47%) 0.4468 (-89.77%) 0.2619 (-11.24%) 0.2451 ( -4.11%) Procs 40 0.2600 ( 0.00%) 0.2850 ( -9.62%) 0.5247 (-101.79%) 0.2724 ( -4.77%) 0.2646 ( -1.75%) The number of procs hackbench is running is too low here for a 48-core machine. It should have been reconfigured but this is better than nothing. schednuma and autonuma both show large regressions in the performance here. I do not investigate why but as there are a number of scheduler changes it could be anything. Strange, last time I tested hackbench it was perfectly ok, I even had this test shown in some of the pdf. It's been rebased to 3.7-rc6 since so there may be an incompatible scheduler change somewhere. Lately (post my last hackbench run) I disabled the affine wakeups cross-node and pipes use sd_affine wakeups. That could matter for these heavy scheduling tests as it practically disables the _sync in wake_up_interruptible_sync_poll used by the pipe code, if the waker CPU is in a different node than the wakee prev_cpu. I discussed this with Mike and he liked this change IIRC but it's the first thing that should be checked at the light of above regression. Understood. I found in early profiles that the mutex_spin_on_owner logic was also relevant but did not pin down why. I expected it was contention on mmap_sem due to the PTE scanner but have not had the chance to verify. PAGE FAULT TEST This is a microbenchmark for page faults. The number of clients are badly ordered which again, I really should fix but anyway. 3.7.0 3.7.0 3.7.0 3.7.0 3.7.0 rc6-stats-v4r12 rc6-schednuma-v16r2rc6-autonuma-v28fastr3 rc6-moron-v4r38 rc6-twostage-v4r38 System 1 8.0710 ( 0.00%) 8.1085 ( -0.46%) 8.0925 ( -0.27%) 8.0170 ( 0.67%) 37.3075 (-362.24% System 10 9.4975 ( 0.00%) 9.5690 ( -0.75%) 12.0055 (-26.41%) 9.5915 ( -0.99%) 9.5835 ( -0.91%) System 11 9.7740 ( 0.00%) 9.7915 ( -0.18%) 13.4890 (-38.01%) 9.7275 ( 0.48%) 9.6810 ( 0.95%) No real clue on this one as I should look in what the test does. It's the PFT test in MMTests and it should run it by default out of the box. Running it will fetch the relevant source and it'll be in work/testsdisk/sources It might be related to THP splits though. I can't imagine anything else because there's nothing at all in autonuma that alters the page faults (except from arming NUMA hinting faults which should be lighter in autonuma than in the other implementation using task work). Chances are the faults are tested by touching bytes at different 4k offsets in the same 2m naturally aligned virtual range. Hugh THP native migration patch will clarify things on the above. The current sets of tests been run has Hugh's THP native migration patch on top. There was a trivial conflict but otherwise it applied. also hope that the concepts of autonuma would be reimplemented on top of this foundation so we can do a meaningful comparison between different placement policies. I'll try to help with this to see what could be added from autonuma on top to improve on top your balancenuma foundation. Your current foundation looks ideal for inclusion to me.
Re: [PATCH RFC 09/12] userns: Convert ocfs2 to use kuid and kgid where appropriate
On Tue, Nov 20, 2012 at 04:43:37AM -0800, Eric W. Biederman wrote:
diff --git a/fs/ocfs2/acl.c b/fs/ocfs2/acl.c
index 260b162..8a40457 100644
--- a/fs/ocfs2/acl.c
+++ b/fs/ocfs2/acl.c
@@ -65,7 +65,20 @@ static struct posix_acl *ocfs2_acl_from_xattr(const void
*value, size_t size)
acl-a_entries[n].e_tag = le16_to_cpu(entry-e_tag);
acl-a_entries[n].e_perm = le16_to_cpu(entry-e_perm);
- acl-a_entries[n].e_id = le32_to_cpu(entry-e_id);
+ switch(acl-a_entries[n].e_tag) {
+ case ACL_USER:
+ acl-a_entries[n].e_uid =
+ make_kuid(init_user_ns,
+ le32_to_cpu(entry-e_id));
+ break;
Stupid question: do you consider disjoint namespaces on multiple
machines to be a problem? Remember that ocfs2 is a cluster filesystem.
If I have uid 100 on machine A in the default namespace, and then I
mount the filesystem on machine B with uid 100 in a different namespace,
what happens? I presume that both can access as the same nominal uid,
and configuring this correctly is left as an exercise to the namespace
administrator?
diff --git a/fs/ocfs2/dlmglue.c b/fs/ocfs2/dlmglue.c
index 4f7795f..f99af1c 100644
--- a/fs/ocfs2/dlmglue.c
+++ b/fs/ocfs2/dlmglue.c
@@ -2045,8 +2045,8 @@ static void __ocfs2_stuff_meta_lvb(struct inode *inode)
lvb-lvb_version = OCFS2_LVB_VERSION;
lvb-lvb_isize = cpu_to_be64(i_size_read(inode));
lvb-lvb_iclusters = cpu_to_be32(oi-ip_clusters);
- lvb-lvb_iuid = cpu_to_be32(inode-i_uid);
- lvb-lvb_igid = cpu_to_be32(inode-i_gid);
+ lvb-lvb_iuid = cpu_to_be32(i_uid_read(inode));
+ lvb-lvb_igid = cpu_to_be32(i_gid_read(inode));
I have the reverse question here. Are we guaranteed that the
on-disk uid/gid will not change regardless of the namespace? That is,
if I create a file on machine A in init_user_ns as uid 100, then access
it over on machine B in some other namespace with a user-visible uid of
100, will the wire be passing 100 in both directions? This absolutely
must be true for the cluster communication to work.
Joel
--
Life's Little Instruction Book #80
Slow dance
http://www.jlbec.org/
jl...@evilplan.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] arm-soc: Xilinx zynq multiplatform changes for v3.8
Hi, On Wed, Nov 21, 2012 at 04:51:07PM +0100, Michal Simek wrote: Hi Olof and Arnd, based on my chat with Olof today I have created new branch with 4 patches which move zynq to multiplatform. This branch depends on arm-soc devel/debug_ll_init branch because we needed Rob's ARM: implement debug_ll_io_init() (sha1: afaee03511ba8002b26a9c6b1fe7d6baf33eac86) patch. This branch also depends on zynq/dt branch because of previous major zynq changes. zynq/cleanup branch is subset of zynq/dt. That's why I have merged devel/debug_ll_init branch with zynq/dt and add 4 patches on the top of it. Nice work. This looks quite reasonable, is small and self-contained and doesn't really affect anyone outside of zynq. So I've pulled into next/multiplatform for 3.8. As part of this, the next/* branches have been somewhat reordered, since multiplatform now includes next/dt contents I've moved it down below there. It shouldn't affect much since no other branch pulls in next/multiplatform contents. -Olof -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] TPM: Issue TPM_STARTUP at driver load if the TPM has not been started
Hi Jason,
Thanks for the updated patch!
Sorry, I have one really minor remark left:
+ if (rc) {
+ dev_err(chip-dev,
+ A TPM error (%d) occurred attempting to determine the
timeouts\n,
rc is a ssize_t here and when compiling with C=1 I get
drivers/char/tpm/tpm.c:582:4: warning: format '%d' expects argument of type
'int', but argument 3 has type 'ssize_t' [-Wformat]
Care to change to
+ A TPM error (%zd) occurred attempting to determine the
timeouts\n,
Sorry that I didn't spot it earlier.
Thanks,
Peter
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] TPM: Issue TPM_STARTUP at driver load if the TPM has not been started
On Wed, Nov 21, 2012 at 09:17:54PM +0100, Peter H?we wrote: Care to change to + A TPM error (%zd) occurred attempting to determine the timeouts\n, Sorry that I didn't spot it earlier. Right.. Probably like this in my tree because of: http://permalink.gmane.org/gmane.linux.kernel/1397887 I should really get sparse setup here... Never enough hours. Jason -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 01/12] x86, boot: move verify_cpu.S after 0x200
On Wed, Nov 21, 2012 at 11:50 AM, H. Peter Anvin h...@zytor.com wrote: The comment is just plain wrong. It assumes you're loading an ELF file, whereas in practice that is rarely true. This does explain why the poor ABI, though. A jump table at the beginning would have been a lot cleaner. Can you please have patch to update the comments and point to the API there ? Thanks Yinghai -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: vmscan: Check for fatal signals iff the process was throttled
On Wed, 21 Nov 2012 15:38:24 +
Mel Gorman mgor...@suse.de wrote:
commit 5515061d22f0 (mm: throttle direct reclaimers if PF_MEMALLOC reserves
are low and swap is backed by network storage) introduced a check for
fatal signals after a process gets throttled for network storage. The
intention was that if a process was throttled and got killed that it
should not trigger the OOM killer. As pointed out by Minchan Kim and
David Rientjes, this check is in the wrong place and too broad. If a
system is in am OOM situation and a process is exiting, it can loop in
__alloc_pages_slowpath() and calling direct reclaim in a loop. As the
fatal signal is pending it returns 1 as if it is making forward progress
and can effectively deadlock.
This patch moves the fatal_signal_pending() check after throttling to
throttle_direct_reclaim() where it belongs. If the process is killed
while throttled, it will return immediately without direct reclaim
except now it will have TIF_MEMDIE set and will use the PFMEMALLOC
reserves.
Minchan pointed out that it may be better to direct reclaim before returning
to avoid using the reserves because there may be pages that can easily
reclaim that would avoid using the reserves. However, we do no such targetted
reclaim and there is no guarantee that suitable pages are available. As it
is expected that this throttling happens when swap-over-NFS is used there
is a possibility that the process will instead swap which may allocate
network buffers from the PFMEMALLOC reserves. Hence, in the swap-over-nfs
case where a process can be throtted and be killed it can use the reserves
to exit or it can potentially use reserves to swap a few pages and then
exit. This patch takes the option of using the reserves if necessary to
allow the process exit quickly.
If this patch passes review it should be considered a -stable candidate
for 3.6.
...
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2207,9 +2207,12 @@ static bool pfmemalloc_watermark_ok(pg_data_t *pgdat)
* Throttle direct reclaimers if backing storage is backed by the network
* and the PFMEMALLOC reserve for the preferred node is getting dangerously
* depleted. kswapd will continue to make progress and wake the processes
- * when the low watermark is reached
+ * when the low watermark is reached.
+ *
+ * Returns true if a fatal signal was delivered during throttling. If this
s/delivered/received/imo
+ * happens, the page allocator should not consider triggering the OOM killer.
*/
-static void throttle_direct_reclaim(gfp_t gfp_mask, struct zonelist
*zonelist,
+static bool throttle_direct_reclaim(gfp_t gfp_mask, struct zonelist
*zonelist,
nodemask_t *nodemask)
{
struct zone *zone;
@@ -2224,13 +2227,20 @@ static void throttle_direct_reclaim(gfp_t gfp_mask,
struct zonelist *zonelist,
* processes to block on log_wait_commit().
*/
if (current-flags PF_KTHREAD)
- return;
+ goto out;
hm, well, back in the old days some kernel threads were killable via
signals. They had to opt-in to it by diddling their signal masks and a
few other things. Too lazy to check if there are still any such sites.
+ /*
+ * If a fatal signal is pending, this process should not throttle.
+ * It should return quickly so it can exit and free its memory
+ */
+ if (fatal_signal_pending(current))
+ goto out;
theresabug. It should return true here.
/* Check if the pfmemalloc reserves are ok */
first_zones_zonelist(zonelist, high_zoneidx, NULL, zone);
pgdat = zone-zone_pgdat;
if (pfmemalloc_watermark_ok(pgdat))
- return;
+ goto out;
/* Account for the throttling */
count_vm_event(PGSCAN_DIRECT_THROTTLE);
@@ -2246,12 +2256,20 @@ static void throttle_direct_reclaim(gfp_t gfp_mask,
struct zonelist *zonelist,
if (!(gfp_mask __GFP_FS)) {
wait_event_interruptible_timeout(pgdat-pfmemalloc_wait,
pfmemalloc_watermark_ok(pgdat), HZ);
- return;
+
+ goto check_pending;
And this can be just an else.
}
/* Throttle until kswapd wakes the process */
wait_event_killable(zone-zone_pgdat-pfmemalloc_wait,
pfmemalloc_watermark_ok(pgdat));
+
+check_pending:
+ if (fatal_signal_pending(current))
+ return true;
+
+out:
+ return false;
}
unsigned long try_to_free_pages(struct zonelist *zonelist, int order,
@@ -2273,13 +2291,12 @@ unsigned long try_to_free_pages(struct zonelist
*zonelist, int order,
.gfp_mask = sc.gfp_mask,
};
- throttle_direct_reclaim(gfp_mask, zonelist, nodemask);
-
/*
- * Do not enter reclaim if fatal signal is pending. 1 is returned so
- * that the page allocator does not consider triggering OOM
+ * Do not
[tip:core/locking] futex: Avoid wake_futex for a PI futex_q
Commit-ID: 0e8f7a5954be13d0c8dcbca3204a9e962498c46e
Gitweb: http://git.kernel.org/tip/0e8f7a5954be13d0c8dcbca3204a9e962498c46e
Author: Darren Hart dvh...@linux.intel.com
AuthorDate: Tue, 20 Nov 2012 23:36:45 -0800
Committer: Thomas Gleixner t...@linutronix.de
CommitDate: Wed, 21 Nov 2012 21:05:34 +0100
futex: Avoid wake_futex for a PI futex_q
Dave Jones reported a bug with futex_lock_pi() that his trinity test
exposed. Sometime between queue_me() and taking the q.lock_ptr, the
lock_ptr became NULL, resulting in a crash.
While futex_wake() is careful to not call wake_futex() on futex_q's with
a pi_state or an rt_waiter (which are either waiting for a
futex_unlock_pi() or a PI futex_requeue()), futex_wake_op() and
futex_requeue() do not perform the same test.
Update futex_wake_op() and futex_requeue() to test for q.pi_state and
q.rt_waiter and abort with -EINVAL if detected. To ensure any future
breakage is caught, add a WARN() to wake_futex() if the same condition
is true.
This fix has seen 3 hours of testing with trinity -c futex on an
x86_64 VM with 4 CPUS.
Reported-by: Dave Jones da...@redat.com
Signed-off-by: Darren Hart dvh...@linux.intel.com
Cc: Peter Zijlstra pet...@infradead.org
Cc: John Kacur jka...@redhat.com
Cc: sta...@vger.kernel.org
Link:
http://lkml.kernel.org/r/3b25c8ba053760892871713ff6e81660433f6734.1353483196.git.dvh...@linux.intel.com
Signed-off-by: Thomas Gleixner t...@linutronix.de
---
kernel/futex.c | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/kernel/futex.c b/kernel/futex.c
index 3717e7b..5699b21 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -840,6 +840,11 @@ static void wake_futex(struct futex_q *q)
{
struct task_struct *p = q-task;
+ if (q-pi_state || q-rt_waiter) {
+ WARN(1, %s: refusing to wake PI futex\n, __FUNCTION__);
+ return;
+ }
+
/*
* We set q-lock_ptr = NULL _before_ we wake up the task. If
* a non-futex wake up happens on another CPU then the task
@@ -1075,6 +1080,10 @@ retry_private:
plist_for_each_entry_safe(this, next, head, list) {
if (match_futex (this-key, key1)) {
+ if (this-pi_state || this-rt_waiter) {
+ ret = -EINVAL;
+ goto out_unlock;
+ }
wake_futex(this);
if (++ret = nr_wake)
break;
@@ -1087,6 +1096,10 @@ retry_private:
op_ret = 0;
plist_for_each_entry_safe(this, next, head, list) {
if (match_futex (this-key, key2)) {
+ if (this-pi_state || this-rt_waiter) {
+ ret = -EINVAL;
+ goto out_unlock;
+ }
wake_futex(this);
if (++op_ret = nr_wake2)
break;
@@ -1095,6 +1108,7 @@ retry_private:
ret += op_ret;
}
+out_unlock:
double_unlock_hb(hb1, hb2);
out_put_keys:
put_futex_key(key2);
@@ -1384,9 +1398,13 @@ retry_private:
/*
* FUTEX_WAIT_REQEUE_PI and FUTEX_CMP_REQUEUE_PI should always
* be paired with each other and no other futex ops.
+*
+* We should never be requeueing a futex_q with a pi_state,
+* which is awaiting a futex_unlock_pi().
*/
if ((requeue_pi !this-rt_waiter) ||
- (!requeue_pi this-rt_waiter)) {
+ (!requeue_pi this-rt_waiter) ||
+ this-pi_state) {
ret = -EINVAL;
break;
}
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Revert serial: omap: fix software flow control
On Wed, Nov 07, 2012 at 10:56:59AM +0100, Andreas Bießmann wrote: On 16.10.2012 16:09, Felipe Balbi wrote: This reverts commit 957ee7270d632245b43f6feb0e70d9a5e9ea6cf6 (serial: omap: fix software flow control). As Russell has pointed out, that commit isn't fixing Software Flow Control at all, and it actually makes it even more broken. It was agreed to revert this commit and use Russell's latest UART patches instead. Cc: Russell King li...@arm.linux.org.uk Signed-off-by: Felipe Balbi ba...@ti.com since 957ee7270d632245b43f6feb0e70d9a5e9ea6cf6 made it into stable (at least 3.4) I think it would be good decision to also apply this revert to stable until a working solution exists. Now queued up for the stable releases, thanks. greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 00/12] VMCI for Linux upstreaming
* * * This series of VMCI linux upstreaming patches include latest udpate from VMware. Summary of changes: - Sparse clean. - Checkpatch clean with one exception, a complex macro in which we can't add parentheses. - Remove all runtime assertions. - Fix device name, so that existing user clients work. - Fix VMCI handle lookup. * * * In an effort to improve the out-of-the-box experience with Linux kernels for VMware users, VMware is working on readying the Virtual Machine Communication Interface (vmw_vmci) and VMCI Sockets (vmw_vsock) kernel modules for inclusion in the Linux kernel. The purpose of this post is to acquire feedback on the vmw_vmci kernel module. The vmw_vsock kernel module will be presented in a later post. * * * VMCI allows virtual machines to communicate with host kernel modules and the VMware hypervisors. User level applications both in a virtual machine and on the host can use vmw_vmci through VMCI Sockets, a socket address family designed to be compatible with UDP and TCP at the interface level. Today, VMCI and VMCI Sockets are used by the VMware shared folders (HGFS) and various VMware Tools components inside the guest for zero-config, network-less access to VMware host services. In addition to this, VMware's users are using VMCI Sockets for various applications, where network access of the virtual machine is restricted or non-existent. Examples of this are VMs communicating with device proxies for proprietary hardware running as host applications and automated testing of applications running within virtual machines. In a virtual machine, VMCI is exposed as a regular PCI device. The primary communication mechanisms supported are a point-to-point bidirectional transport based on a pair of memory-mapped queues, and asynchronous notifications in the form of datagrams and doorbells. These features are available to kernel level components such as HGFS and VMCI Sockets through the VMCI kernel API. In addition to this, the VMCI kernel API provides support for receiving events related to the state of the VMCI communication channels, and the virtual machine itself. Outside the virtual machine, the host side support of the VMCI kernel module makes the same VMCI kernel API available to VMCI endpoints on the host. In addition to this, the host side manages each VMCI device in a virtual machine through a context object. This context object serves to identify the virtual machine for communication, and to track the resource consumption of the given VMCI device. Both operations related to communication between the virtual machine and the host kernel, and those related to the management of the VMCI device state in the host kernel, are invoked by the user level component of the hypervisor through a set of ioctls on the VMCI device node. To provide seamless support for nested virtualization, where a virtual machine may use both a VMCI PCI device to talk to its hypervisor, and the VMCI host side support to run nested virtual machines, the VMCI host and virtual machine support are combined in a single kernel module. For additional information about the use of VMCI and in particular VMCI Sockets, please refer to the VMCI Socket Programming Guide available at https://www.vmware.com/support/developer/vmci-sdk/. --- George Zhang (12): VMCI: context implementation. VMCI: datagram implementation. VMCI: doorbell implementation. VMCI: device driver implementaton. VMCI: event handling implementation. VMCI: handle array implementation. VMCI: queue pairs implementation. VMCI: resource object implementation. VMCI: routing implementation. VMCI: guest side driver implementation. VMCI: host side driver implementation. VMCI: Some header and config files. drivers/misc/Kconfig |1 drivers/misc/Makefile |2 drivers/misc/vmw_vmci/Kconfig | 16 drivers/misc/vmw_vmci/Makefile|4 drivers/misc/vmw_vmci/vmci_common_int.h | 32 drivers/misc/vmw_vmci/vmci_context.c | 1223 ++ drivers/misc/vmw_vmci/vmci_context.h | 183 ++ drivers/misc/vmw_vmci/vmci_datagram.c | 501 drivers/misc/vmw_vmci/vmci_datagram.h | 52 drivers/misc/vmw_vmci/vmci_doorbell.c | 605 + drivers/misc/vmw_vmci/vmci_doorbell.h | 51 drivers/misc/vmw_vmci/vmci_driver.c | 117 + drivers/misc/vmw_vmci/vmci_driver.h | 50 drivers/misc/vmw_vmci/vmci_event.c| 224 ++ drivers/misc/vmw_vmci/vmci_event.h| 25 drivers/misc/vmw_vmci/vmci_guest.c| 757 ++ drivers/misc/vmw_vmci/vmci_handle_array.c | 142 + drivers/misc/vmw_vmci/vmci_handle_array.h | 52 drivers/misc/vmw_vmci/vmci_host.c | 1036 + drivers/misc/vmw_vmci/vmci_queue_pair.c | 3439 + drivers/misc/vmw_vmci/vmci_queue_pair.h | 191 ++
[PATCH 01/12] VMCI: context implementation.
VMCI Context code maintains state for vmci and allows the driver to communicate
with multiple VMs.
Signed-off-by: George Zhang georgezh...@vmware.com
Signed-off-by: Dmitry Torokhov d...@vmware.com
Signed-off-by: Andy King ack...@vmware.com
---
drivers/misc/vmw_vmci/vmci_context.c | 1223 ++
drivers/misc/vmw_vmci/vmci_context.h | 183 +
2 files changed, 1406 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/vmw_vmci/vmci_context.c
create mode 100644 drivers/misc/vmw_vmci/vmci_context.h
diff --git a/drivers/misc/vmw_vmci/vmci_context.c
b/drivers/misc/vmw_vmci/vmci_context.c
new file mode 100644
index 000..6f5abb5
--- /dev/null
+++ b/drivers/misc/vmw_vmci/vmci_context.c
@@ -0,0 +1,1223 @@
+/*
+ * VMware VMCI Driver
+ *
+ * Copyright (C) 2012 VMware, Inc. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation version 2 and no later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+ * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ * for more details.
+ */
+
+#include linux/vmw_vmci_defs.h
+#include linux/vmw_vmci_api.h
+#include linux/highmem.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/sched.h
+#include linux/slab.h
+
+#include vmci_common_int.h
+#include vmci_queue_pair.h
+#include vmci_datagram.h
+#include vmci_doorbell.h
+#include vmci_context.h
+#include vmci_driver.h
+#include vmci_event.h
+
+/*
+ * List of current VMCI contexts. Contexts can be added by
+ * vmci_ctx_create() and removed via vmci_ctx_destroy().
+ * These, along with context lookup, are protected by the
+ * list structure's lock.
+ */
+static struct {
+ struct list_head head;
+ spinlock_t lock; /* Spinlock for context list operations */
+} ctx_list = {
+ .head = LIST_HEAD_INIT(ctx_list.head),
+ .lock = __SPIN_LOCK_UNLOCKED(ctx_list.lock),
+};
+
+/* Used by contexts that did not set up notify flag pointers */
+static bool ctx_dummy_notify;
+
+static void ctx_signal_notify(struct vmci_ctx *context)
+{
+ *context-notify = true;
+}
+
+static void ctx_clear_notify(struct vmci_ctx *context)
+{
+ *context-notify = false;
+}
+
+/*
+ * If nothing requires the attention of the guest, clears both
+ * notify flag and call.
+ */
+static void ctx_clear_notify_call(struct vmci_ctx *context)
+{
+ if (context-pending_datagrams == 0
+ vmci_handle_arr_get_size(context-pending_doorbell_array) == 0)
+ ctx_clear_notify(context);
+}
+
+/*
+ * Sets the context's notify flag iff datagrams are pending for this
+ * context. Called from vmci_setup_notify().
+ */
+void vmci_ctx_check_signal_notify(struct vmci_ctx *context)
+{
+ spin_lock(context-lock);
+ if (context-pending_datagrams)
+ ctx_signal_notify(context);
+ spin_unlock(context-lock);
+}
+
+/*
+ * Allocates and initializes a VMCI context.
+ */
+struct vmci_ctx *vmci_ctx_create(u32 cid, u32 priv_flags,
+uintptr_t event_hnd,
+int user_version,
+const struct cred *cred)
+{
+ struct vmci_ctx *context;
+ int error;
+
+ if (cid == VMCI_INVALID_ID) {
+ pr_devel(Invalid context ID for VMCI context.\n);
+ error = -EINVAL;
+ goto err_out;
+ }
+
+ if (priv_flags ~VMCI_PRIVILEGE_ALL_FLAGS) {
+ pr_devel(Invalid flag (flags=0x%x) for VMCI context.\n,
+priv_flags);
+ error = -EINVAL;
+ goto err_out;
+ }
+
+ if (user_version == 0) {
+ pr_devel(Invalid suer_version %d\n, user_version);
+ error = -EINVAL;
+ goto err_out;
+ }
+
+ context = kzalloc(sizeof(*context), GFP_KERNEL);
+ if (!context) {
+ pr_warn(Failed to allocate memory for VMCI context.\n);
+ error = -EINVAL;
+ goto err_out;
+ }
+
+ kref_init(context-kref);
+ spin_lock_init(context-lock);
+ INIT_LIST_HEAD(context-list_item);
+ INIT_LIST_HEAD(context-datagram_queue);
+ INIT_LIST_HEAD(context-notifier_list);
+
+ /* Initialize host-specific VMCI context. */
+ init_waitqueue_head(context-host_context.wait_queue);
+
+ context-queue_pair_array = vmci_handle_arr_create(0);
+ if (!context-queue_pair_array) {
+ error = -ENOMEM;
+ goto err_free_ctx;
+ }
+
+ context-doorbell_array = vmci_handle_arr_create(0);
+ if (!context-doorbell_array) {
+ error = -ENOMEM;
+ goto err_free_qp_array;
+ }
+
+ context-pending_doorbell_array
[PATCH 02/12] VMCI: datagram implementation.
VMCI datagram Implements datagrams to allow data to be sent between host and
guest.
Signed-off-by: George Zhang georgezh...@vmware.com
Signed-off-by: Dmitry Torokhov d...@vmware.com
Signed-off-by: Andy King ack...@vmware.com
---
drivers/misc/vmw_vmci/vmci_datagram.c | 501 +
drivers/misc/vmw_vmci/vmci_datagram.h | 52 +++
2 files changed, 553 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/vmw_vmci/vmci_datagram.c
create mode 100644 drivers/misc/vmw_vmci/vmci_datagram.h
diff --git a/drivers/misc/vmw_vmci/vmci_datagram.c
b/drivers/misc/vmw_vmci/vmci_datagram.c
new file mode 100644
index 000..a6513f4
--- /dev/null
+++ b/drivers/misc/vmw_vmci/vmci_datagram.c
@@ -0,0 +1,501 @@
+/*
+ * VMware VMCI Driver
+ *
+ * Copyright (C) 2012 VMware, Inc. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation version 2 and no later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+ * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ * for more details.
+ */
+
+#include linux/vmw_vmci_defs.h
+#include linux/vmw_vmci_api.h
+#include linux/module.h
+#include linux/sched.h
+#include linux/slab.h
+#include linux/bug.h
+
+#include vmci_common_int.h
+#include vmci_datagram.h
+#include vmci_resource.h
+#include vmci_context.h
+#include vmci_driver.h
+#include vmci_event.h
+#include vmci_route.h
+
+/*
+ * struct datagram_entry describes the datagram entity. It is used for datagram
+ * entities created only on the host.
+ */
+struct datagram_entry {
+ struct vmci_resource resource;
+ u32 flags;
+ bool run_delayed;
+ vmci_datagram_recv_cb recv_cb;
+ void *client_data;
+ u32 priv_flags;
+};
+
+struct delayed_datagram_info {
+ struct datagram_entry *entry;
+ struct vmci_datagram msg;
+ struct work_struct work;
+ bool in_dg_host_queue;
+};
+
+/* Number of in-flight host-host datagrams */
+static atomic_t delayed_dg_host_queue_size = ATOMIC_INIT(0);
+
+/*
+ * Create a datagram entry given a handle pointer.
+ */
+static int dg_create_handle(u32 resource_id,
+ u32 flags,
+ u32 priv_flags,
+ vmci_datagram_recv_cb recv_cb,
+ void *client_data, struct vmci_handle *out_handle)
+{
+ int result;
+ u32 context_id;
+ struct vmci_handle handle;
+ struct datagram_entry *entry;
+
+ if ((flags VMCI_FLAG_WELLKNOWN_DG_HND) != 0)
+ return VMCI_ERROR_INVALID_ARGS;
+
+ if ((flags VMCI_FLAG_ANYCID_DG_HND) != 0) {
+ context_id = VMCI_INVALID_ID;
+ } else {
+ context_id = vmci_get_context_id();
+ if (context_id == VMCI_INVALID_ID)
+ return VMCI_ERROR_NO_RESOURCES;
+ }
+
+ handle = vmci_make_handle(context_id, resource_id);
+
+ entry = kmalloc(sizeof(*entry), GFP_KERNEL);
+ if (!entry) {
+ pr_warn(Failed allocating memory for datagram entry.\n);
+ return VMCI_ERROR_NO_MEM;
+ }
+
+ entry-run_delayed = (flags VMCI_FLAG_DG_DELAYED_CB) ? true : false;
+ entry-flags = flags;
+ entry-recv_cb = recv_cb;
+ entry-client_data = client_data;
+ entry-priv_flags = priv_flags;
+
+ /* Make datagram resource live. */
+ result = vmci_resource_add(entry-resource,
+ VMCI_RESOURCE_TYPE_DATAGRAM,
+ handle);
+ if (result != VMCI_SUCCESS) {
+ pr_warn(Failed to add new resource (handle=0x%x:0x%x), error:
%d\n,
+ handle.context, handle.resource, result);
+ kfree(entry);
+ return result;
+ }
+
+ *out_handle = vmci_resource_handle(entry-resource);
+ return VMCI_SUCCESS;
+}
+
+/*
+ * Internal utility function with the same purpose as
+ * vmci_datagram_get_priv_flags that also takes a context_id.
+ */
+static int vmci_datagram_get_priv_flags(u32 context_id,
+ struct vmci_handle handle,
+ u32 *priv_flags)
+{
+ if (context_id == VMCI_INVALID_ID)
+ return VMCI_ERROR_INVALID_ARGS;
+
+ if (context_id == VMCI_HOST_CONTEXT_ID) {
+ struct datagram_entry *src_entry;
+ struct vmci_resource *resource;
+
+ resource = vmci_resource_by_handle(handle,
+ VMCI_RESOURCE_TYPE_DATAGRAM);
+ if (!resource)
+ return VMCI_ERROR_INVALID_ARGS;
+
+ src_entry = container_of(resource, struct
[PATCH 03/12] VMCI: doorbell implementation.
VMCI doorbell code allows for notifcations between host and guest.
Signed-off-by: George Zhang georgezh...@vmware.com
Signed-off-by: Dmitry Torokhov d...@vmware.com
Signed-off-by: Andy King ack...@vmware.com
---
drivers/misc/vmw_vmci/vmci_doorbell.c | 605 +
drivers/misc/vmw_vmci/vmci_doorbell.h | 51 +++
2 files changed, 656 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/vmw_vmci/vmci_doorbell.c
create mode 100644 drivers/misc/vmw_vmci/vmci_doorbell.h
diff --git a/drivers/misc/vmw_vmci/vmci_doorbell.c
b/drivers/misc/vmw_vmci/vmci_doorbell.c
new file mode 100644
index 000..bced12b
--- /dev/null
+++ b/drivers/misc/vmw_vmci/vmci_doorbell.c
@@ -0,0 +1,605 @@
+/*
+ * VMware VMCI Driver
+ *
+ * Copyright (C) 2012 VMware, Inc. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation version 2 and no later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+ * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ * for more details.
+ */
+
+#include linux/vmw_vmci_defs.h
+#include linux/vmw_vmci_api.h
+#include linux/completion.h
+#include linux/hash.h
+#include linux/kernel.h
+#include linux/list.h
+#include linux/module.h
+#include linux/sched.h
+#include linux/slab.h
+
+#include vmci_common_int.h
+#include vmci_datagram.h
+#include vmci_doorbell.h
+#include vmci_resource.h
+#include vmci_driver.h
+#include vmci_route.h
+
+
+#define VMCI_DOORBELL_INDEX_BITS 6
+#define VMCI_DOORBELL_INDEX_TABLE_SIZE (1 VMCI_DOORBELL_INDEX_BITS)
+#define VMCI_DOORBELL_HASH(_idx) hash_32(_idx, VMCI_DOORBELL_INDEX_BITS)
+
+/*
+ * DoorbellEntry describes the a doorbell notification handle allocated by the
+ * host.
+ */
+struct dbell_entry {
+ struct vmci_resource resource;
+ struct hlist_node node;
+ struct work_struct work;
+ vmci_callback notify_cb;
+ void *client_data;
+ u32 idx;
+ u32 priv_flags;
+ bool run_delayed;
+ atomic_t active;/* Only used by guest personality */
+};
+
+/* The VMCI index table keeps track of currently registered doorbells. */
+struct dbell_index_table {
+ spinlock_t lock;/* Index table lock */
+ struct hlist_head entries[VMCI_DOORBELL_INDEX_TABLE_SIZE];
+};
+
+static struct dbell_index_table vmci_doorbell_it = {
+ .lock = __SPIN_LOCK_UNLOCKED(vmci_doorbell_it.lock),
+};
+
+/*
+ * The max_notify_idx is one larger than the currently known bitmap index in
+ * use, and is used to determine how much of the bitmap needs to be scanned.
+ */
+static u32 max_notify_idx;
+
+/*
+ * The notify_idx_count is used for determining whether there are free entries
+ * within the bitmap (if notify_idx_count + 1 max_notify_idx).
+ */
+static u32 notify_idx_count;
+
+/*
+ * The last_notify_idx_reserved is used to track the last index handed out - in
+ * the case where multiple handles share a notification index, we hand out
+ * indexes round robin based on last_notify_idx_reserved.
+ */
+static u32 last_notify_idx_reserved;
+
+/* This is a one entry cache used to by the index allocation. */
+static u32 last_notify_idx_released = PAGE_SIZE;
+
+
+/*
+ * Utility function that retrieves the privilege flags associated
+ * with a given doorbell handle. For guest endpoints, the
+ * privileges are determined by the context ID, but for host
+ * endpoints privileges are associated with the complete
+ * handle. Hypervisor endpoints are not yet supported.
+ */
+int vmci_dbell_get_priv_flags(struct vmci_handle handle, u32 *priv_flags)
+{
+ if (priv_flags == NULL || handle.context == VMCI_INVALID_ID)
+ return VMCI_ERROR_INVALID_ARGS;
+
+ if (handle.context == VMCI_HOST_CONTEXT_ID) {
+ struct dbell_entry *entry;
+ struct vmci_resource *resource;
+
+ resource = vmci_resource_by_handle(handle,
+ VMCI_RESOURCE_TYPE_DOORBELL);
+ if (!resource)
+ return VMCI_ERROR_NOT_FOUND;
+
+ entry = container_of(resource, struct dbell_entry, resource);
+ *priv_flags = entry-priv_flags;
+ vmci_resource_put(resource);
+ } else if (handle.context == VMCI_HYPERVISOR_CONTEXT_ID) {
+ /*
+* Hypervisor endpoints for notifications are not
+* supported (yet).
+*/
+ return VMCI_ERROR_INVALID_ARGS;
+ } else {
+ *priv_flags = vmci_context_get_priv_flags(handle.context);
+ }
+
+ return VMCI_SUCCESS;
+}
+
+/*
+ * Find doorbell entry by bitmap index.
+ */
+static struct dbell_entry *dbell_index_table_find(u32 idx)
+{
+ u32
[PATCH 04/12] VMCI: device driver implementaton.
VMCI driver code implementes both the host and guest personalities of the VMCI
driver.
Signed-off-by: George Zhang georgezh...@vmware.com
Signed-off-by: Dmitry Torokhov d...@vmware.com
Signed-off-by: Andy King ack...@vmware.com
---
drivers/misc/vmw_vmci/vmci_driver.c | 117 +++
drivers/misc/vmw_vmci/vmci_driver.h | 50 +++
2 files changed, 167 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/vmw_vmci/vmci_driver.c
create mode 100644 drivers/misc/vmw_vmci/vmci_driver.h
diff --git a/drivers/misc/vmw_vmci/vmci_driver.c
b/drivers/misc/vmw_vmci/vmci_driver.c
new file mode 100644
index 000..c04c24c
--- /dev/null
+++ b/drivers/misc/vmw_vmci/vmci_driver.c
@@ -0,0 +1,117 @@
+/*
+ * VMware VMCI Driver
+ *
+ * Copyright (C) 2012 VMware, Inc. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation version 2 and no later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+ * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ * for more details.
+ */
+
+#include linux/vmw_vmci_defs.h
+#include linux/vmw_vmci_api.h
+#include linux/atomic.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+
+#include vmci_driver.h
+#include vmci_event.h
+
+static bool vmci_disable_host;
+module_param_named(disable_host, vmci_disable_host, bool, 0);
+MODULE_PARM_DESC(disable_host,
+Disable driver host personality (default=enabled));
+
+static bool vmci_disable_guest;
+module_param_named(disable_guest, vmci_disable_guest, bool, 0);
+MODULE_PARM_DESC(disable_guest,
+Disable driver guest personality (default=enabled));
+
+static bool vmci_guest_personality_initialized;
+static bool vmci_host_personality_initialized;
+
+/*
+ * vmci_get_context_id() - Gets the current context ID.
+ *
+ * Returns the current context ID. Note that since this is accessed only
+ * from code running in the host, this always returns the host context ID.
+ */
+u32 vmci_get_context_id(void)
+{
+ if (vmci_guest_code_active())
+ return vmci_get_vm_context_id();
+ else if (vmci_host_code_active())
+ return VMCI_HOST_CONTEXT_ID;
+
+ return VMCI_INVALID_ID;
+}
+EXPORT_SYMBOL_GPL(vmci_get_context_id);
+
+static int __init vmci_drv_init(void)
+{
+ int vmci_err;
+ int error;
+
+ vmci_err = vmci_event_init();
+ if (vmci_err VMCI_SUCCESS) {
+ pr_err(Failed to initialize VMCIEvent (result=%d).\n,
+ vmci_err);
+ return -EINVAL;
+ }
+
+ if (!vmci_disable_guest) {
+ error = vmci_guest_init();
+ if (error) {
+ pr_warn(Failed to initialize guest personality
(err=%d).\n,
+ error);
+ } else {
+ vmci_guest_personality_initialized = true;
+ pr_info(Guest personality initialized and is %s\n,
+ vmci_guest_code_active() ?
+ active : inactive);
+ }
+ }
+
+ if (!vmci_disable_host) {
+ error = vmci_host_init();
+ if (error) {
+ pr_warn(Unable to initialize host personality
(err=%d).\n,
+ error);
+ } else {
+ vmci_host_personality_initialized = true;
+ pr_info(Initialized host personality\n);
+ }
+ }
+
+ if (!vmci_guest_personality_initialized
+ !vmci_host_personality_initialized) {
+ vmci_event_exit();
+ return -ENODEV;
+ }
+
+ return 0;
+}
+module_init(vmci_drv_init);
+
+static void __exit vmci_drv_exit(void)
+{
+ if (vmci_guest_personality_initialized)
+ vmci_guest_exit();
+
+ if (vmci_host_personality_initialized)
+ vmci_host_exit();
+
+ vmci_event_exit();
+}
+module_exit(vmci_drv_exit);
+
+MODULE_AUTHOR(VMware, Inc.);
+MODULE_DESCRIPTION(VMware Virtual Machine Communication Interface.);
+MODULE_VERSION(VMCI_DRIVER_VERSION_STRING);
+MODULE_LICENSE(GPL v2);
diff --git a/drivers/misc/vmw_vmci/vmci_driver.h
b/drivers/misc/vmw_vmci/vmci_driver.h
new file mode 100644
index 000..f69156a
--- /dev/null
+++ b/drivers/misc/vmw_vmci/vmci_driver.h
@@ -0,0 +1,50 @@
+/*
+ * VMware VMCI Driver
+ *
+ * Copyright (C) 2012 VMware, Inc. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation version 2 and no later version.
+ *
+ * This program
[PATCH 05/12] VMCI: event handling implementation.
VMCI event code that manages event handlers and handles callbacks when
specific events fire.
Signed-off-by: George Zhang georgezh...@vmware.com
Signed-off-by: Dmitry Torokhov d...@vmware.com
Signed-off-by: Andy King ack...@vmware.com
---
drivers/misc/vmw_vmci/vmci_event.c | 224
drivers/misc/vmw_vmci/vmci_event.h | 25
2 files changed, 249 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/vmw_vmci/vmci_event.c
create mode 100644 drivers/misc/vmw_vmci/vmci_event.h
diff --git a/drivers/misc/vmw_vmci/vmci_event.c
b/drivers/misc/vmw_vmci/vmci_event.c
new file mode 100644
index 000..1fe40e5
--- /dev/null
+++ b/drivers/misc/vmw_vmci/vmci_event.c
@@ -0,0 +1,224 @@
+/*
+ * VMware VMCI Driver
+ *
+ * Copyright (C) 2012 VMware, Inc. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation version 2 and no later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+ * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ * for more details.
+ */
+
+#include linux/vmw_vmci_defs.h
+#include linux/vmw_vmci_api.h
+#include linux/list.h
+#include linux/module.h
+#include linux/sched.h
+#include linux/slab.h
+
+#include vmci_driver.h
+#include vmci_event.h
+
+#define EVENT_MAGIC 0xEABE
+#define VMCI_EVENT_MAX_ATTEMPTS 10
+
+struct vmci_subscription {
+ u32 id;
+ u32 event;
+ vmci_event_cb callback;
+ void *callback_data;
+ struct list_head node; /* on one of subscriber lists */
+};
+
+static struct list_head subscriber_array[VMCI_EVENT_MAX];
+static DEFINE_MUTEX(subscriber_mutex);
+
+int __init vmci_event_init(void)
+{
+ int i;
+
+ for (i = 0; i VMCI_EVENT_MAX; i++)
+ INIT_LIST_HEAD(subscriber_array[i]);
+
+ return VMCI_SUCCESS;
+}
+
+void vmci_event_exit(void)
+{
+ int e;
+
+ /* We free all memory at exit. */
+ for (e = 0; e VMCI_EVENT_MAX; e++) {
+ struct vmci_subscription *cur, *p2;
+ list_for_each_entry_safe(cur, p2, subscriber_array[e], node) {
+
+ /*
+* We should never get here because all events
+* should have been unregistered before we try
+* to unload the driver module.
+*/
+ pr_warn(Unexpected free events occurring.\n);
+ list_del(cur-node);
+ kfree(cur);
+ }
+ }
+}
+
+/*
+ * Find entry. Assumes subscriber_mutex is held.
+ */
+static struct vmci_subscription *event_find(u32 sub_id)
+{
+ int e;
+
+ for (e = 0; e VMCI_EVENT_MAX; e++) {
+ struct vmci_subscription *cur;
+ list_for_each_entry(cur, subscriber_array[e], node) {
+ if (cur-id == sub_id)
+ return cur;
+ }
+ }
+ return NULL;
+}
+
+/*
+ * Actually delivers the events to the subscribers.
+ * The callback function for each subscriber is invoked.
+ */
+static void event_deliver(struct vmci_event_msg *event_msg)
+{
+ struct vmci_subscription *cur;
+ struct list_head *subscriber_list;
+
+ rcu_read_lock();
+ subscriber_list = subscriber_array[event_msg-event_data.event];
+ list_for_each_entry_rcu(cur, subscriber_list, node) {
+ cur-callback(cur-id, event_msg-event_data,
+ cur-callback_data);
+ }
+ rcu_read_unlock();
+}
+
+/*
+ * Dispatcher for the VMCI_EVENT_RECEIVE datagrams. Calls all
+ * subscribers for given event.
+ */
+int vmci_event_dispatch(struct vmci_datagram *msg)
+{
+ struct vmci_event_msg *event_msg = (struct vmci_event_msg *)msg;
+
+ if (msg-payload_size sizeof(u32) ||
+ msg-payload_size sizeof(struct vmci_event_data_max))
+ return VMCI_ERROR_INVALID_ARGS;
+
+ if (!VMCI_EVENT_VALID(event_msg-event_data.event))
+ return VMCI_ERROR_EVENT_UNKNOWN;
+
+ event_deliver(event_msg);
+ return VMCI_SUCCESS;
+}
+
+/*
+ * vmci_event_subscribe() - Subscribe to a given event.
+ * @event: The event to subscribe to.
+ * @callback: The callback to invoke upon the event.
+ * @callback_data: Data to pass to the callback.
+ * @subscription_id:ID used to track subscription. Used with
+ * vmci_event_unsubscribe()
+ *
+ * Subscribes to the provided event. The callback specified will be
+ * fired from RCU critical section and therefore must not sleep.
+ */
+int vmci_event_subscribe(u32 event,
+vmci_event_cb callback,
+void *callback_data,
+u32
[PATCH 06/12] VMCI: handle array implementation.
VMCI handle code adds support for dynamic arrays that will grow if they need to.
Signed-off-by: George Zhang georgezh...@vmware.com
Signed-off-by: Dmitry Torokhov d...@vmware.com
Signed-off-by: Andy King ack...@vmware.com
---
drivers/misc/vmw_vmci/vmci_handle_array.c | 142 +
drivers/misc/vmw_vmci/vmci_handle_array.h | 52 +++
2 files changed, 194 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/vmw_vmci/vmci_handle_array.c
create mode 100644 drivers/misc/vmw_vmci/vmci_handle_array.h
diff --git a/drivers/misc/vmw_vmci/vmci_handle_array.c
b/drivers/misc/vmw_vmci/vmci_handle_array.c
new file mode 100644
index 000..9122373
--- /dev/null
+++ b/drivers/misc/vmw_vmci/vmci_handle_array.c
@@ -0,0 +1,142 @@
+/*
+ * VMware VMCI Driver
+ *
+ * Copyright (C) 2012 VMware, Inc. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation version 2 and no later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+ * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ * for more details.
+ */
+
+#include linux/slab.h
+#include vmci_handle_array.h
+
+static size_t handle_arr_calc_size(size_t capacity)
+{
+ return sizeof(struct vmci_handle_arr) +
+ capacity * sizeof(struct vmci_handle);
+}
+
+struct vmci_handle_arr *vmci_handle_arr_create(size_t capacity)
+{
+ struct vmci_handle_arr *array;
+
+ if (capacity == 0)
+ capacity = VMCI_HANDLE_ARRAY_DEFAULT_SIZE;
+
+ array = kmalloc(handle_arr_calc_size(capacity), GFP_ATOMIC);
+ if (!array)
+ return NULL;
+
+ array-capacity = capacity;
+ array-size = 0;
+
+ return array;
+}
+
+void vmci_handle_arr_destroy(struct vmci_handle_arr *array)
+{
+ kfree(array);
+}
+
+void vmci_handle_arr_append_entry(struct vmci_handle_arr **array_ptr,
+ struct vmci_handle handle)
+{
+ struct vmci_handle_arr *array = *array_ptr;
+
+ if (unlikely(array-size = array-capacity)) {
+ /* reallocate. */
+ struct vmci_handle_arr *new_array;
+ size_t new_capacity = array-capacity * VMCI_ARR_CAP_MULT;
+ size_t new_size = handle_arr_calc_size(new_capacity);
+
+ new_array = krealloc(array, new_size, GFP_ATOMIC);
+ if (!new_array)
+ return;
+
+ new_array-capacity = new_capacity;
+ *array_ptr = array = new_array;
+ }
+
+ array-entries[array-size] = handle;
+ array-size++;
+}
+
+/*
+ * Handle that was removed, VMCI_INVALID_HANDLE if entry not found.
+ */
+struct vmci_handle vmci_handle_arr_remove_entry(struct vmci_handle_arr *array,
+ struct vmci_handle entry_handle)
+{
+ struct vmci_handle handle = VMCI_INVALID_HANDLE;
+ size_t i;
+
+ for (i = 0; i array-size; i++) {
+ if (VMCI_HANDLE_EQUAL(array-entries[i], entry_handle)) {
+ handle = array-entries[i];
+ array-size--;
+ array-entries[i] = array-entries[array-size];
+ array-entries[array-size] = VMCI_INVALID_HANDLE;
+ break;
+ }
+ }
+
+ return handle;
+}
+
+/*
+ * Handle that was removed, VMCI_INVALID_HANDLE if array was empty.
+ */
+struct vmci_handle vmci_handle_arr_remove_tail(struct vmci_handle_arr *array)
+{
+ struct vmci_handle handle = VMCI_INVALID_HANDLE;
+
+ if (array-size) {
+ array-size--;
+ handle = array-entries[array-size];
+ array-entries[array-size] = VMCI_INVALID_HANDLE;
+ }
+
+ return handle;
+}
+
+/*
+ * Handle at given index, VMCI_INVALID_HANDLE if invalid index.
+ */
+struct vmci_handle
+vmci_handle_arr_get_entry(const struct vmci_handle_arr *array, size_t index)
+{
+ if (unlikely(index = array-size))
+ return VMCI_INVALID_HANDLE;
+
+ return array-entries[index];
+}
+
+bool vmci_handle_arr_has_entry(const struct vmci_handle_arr *array,
+ struct vmci_handle entry_handle)
+{
+ size_t i;
+
+ for (i = 0; i array-size; i++)
+ if (VMCI_HANDLE_EQUAL(array-entries[i], entry_handle))
+ return true;
+
+ return false;
+}
+
+/*
+ * NULL if the array is empty. Otherwise, a pointer to the array
+ * of VMCI handles in the handle array.
+ */
+struct vmci_handle *vmci_handle_arr_get_handles(struct vmci_handle_arr *array)
+{
+ if (array-size)
+ return array-entries;
+
+ return NULL;
+}
diff --git
[PATCH 08/12] VMCI: resource object implementation.
VMCI resource tracks all used resources within the vmci code.
Signed-off-by: George Zhang georgezh...@vmware.com
Signed-off-by: Dmitry Torokhov d...@vmware.com
Signed-off-by: Andy King ack...@vmware.com
---
drivers/misc/vmw_vmci/vmci_resource.c | 232 +
drivers/misc/vmw_vmci/vmci_resource.h | 59
2 files changed, 291 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/vmw_vmci/vmci_resource.c
create mode 100644 drivers/misc/vmw_vmci/vmci_resource.h
diff --git a/drivers/misc/vmw_vmci/vmci_resource.c
b/drivers/misc/vmw_vmci/vmci_resource.c
new file mode 100644
index 000..0d3a2bc
--- /dev/null
+++ b/drivers/misc/vmw_vmci/vmci_resource.c
@@ -0,0 +1,232 @@
+/*
+ * VMware VMCI Driver
+ *
+ * Copyright (C) 2012 VMware, Inc. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation version 2 and no later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+ * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ * for more details.
+ */
+
+#include linux/vmw_vmci_defs.h
+#include linux/hash.h
+#include linux/types.h
+#include linux/rculist.h
+
+#include vmci_common_int.h
+#include vmci_resource.h
+#include vmci_driver.h
+
+
+#define VMCI_RESOURCE_HASH_BITS 7
+#define VMCI_RESOURCE_HASH_BUCKETS (1 VMCI_RESOURCE_HASH_BITS)
+
+struct vmci_hash_table {
+ spinlock_t lock;
+ struct hlist_head entries[VMCI_RESOURCE_HASH_BUCKETS];
+};
+
+static struct vmci_hash_table vmci_resource_table = {
+ .lock = __SPIN_LOCK_UNLOCKED(vmci_resource_table.lock),
+};
+
+static unsigned int vmci_resource_hash(struct vmci_handle handle)
+{
+ return hash_32(VMCI_HANDLE_TO_RESOURCE_ID(handle),
+ VMCI_RESOURCE_HASH_BITS);
+}
+
+/*
+ * Gets a resource (if one exists) matching given handle from the hash table.
+ */
+static struct vmci_resource *vmci_resource_lookup(struct vmci_handle handle,
+ enum vmci_resource_type type)
+{
+ struct vmci_resource *r, *resource = NULL;
+ struct hlist_node *node;
+ unsigned int idx = vmci_resource_hash(handle);
+
+ rcu_read_lock();
+ hlist_for_each_entry_rcu(r, node,
+vmci_resource_table.entries[idx], node) {
+ u32 rid = VMCI_HANDLE_TO_RESOURCE_ID(r-handle);
+ u32 cid = VMCI_HANDLE_TO_CONTEXT_ID(r-handle);
+
+ if (r-type == type
+ rid == VMCI_HANDLE_TO_RESOURCE_ID(handle)
+ (cid == VMCI_HANDLE_TO_CONTEXT_ID(handle) ||
+cid == VMCI_INVALID_ID)) {
+ resource = r;
+ break;
+ }
+ }
+ rcu_read_unlock();
+
+ return resource;
+}
+
+/*
+ * Find an unused resource ID and return it. The first
+ * VMCI_RESERVED_RESOURCE_ID_MAX are reserved so we start from
+ * its value + 1.
+ * Returns VMCI resource id on success, VMCI_INVALID_ID on failure.
+ */
+static u32 vmci_resource_find_id(u32 context_id,
+enum vmci_resource_type resource_type)
+{
+ static u32 resource_id = VMCI_RESERVED_RESOURCE_ID_MAX + 1;
+ u32 old_rid = resource_id;
+ u32 current_rid;
+
+ /*
+* Generate a unique resource ID. Keep on trying until we wrap around
+* in the RID space.
+*/
+ do {
+ struct vmci_handle handle;
+
+ current_rid = resource_id;
+ resource_id++;
+ if (unlikely(resource_id == VMCI_INVALID_ID)) {
+ /* Skip the reserved rids. */
+ resource_id = VMCI_RESERVED_RESOURCE_ID_MAX + 1;
+ }
+
+ handle = vmci_make_handle(context_id, current_rid);
+ if (!vmci_resource_lookup(handle, resource_type))
+ return current_rid;
+ } while (resource_id != old_rid);
+
+ return VMCI_INVALID_ID;
+}
+
+
+int vmci_resource_add(struct vmci_resource *resource,
+ enum vmci_resource_type resource_type,
+ struct vmci_handle handle)
+
+{
+ unsigned int idx;
+ int result;
+
+ spin_lock(vmci_resource_table.lock);
+
+ if (handle.resource == VMCI_INVALID_ID) {
+ handle.resource = vmci_resource_find_id(handle.context,
+ resource_type);
+ if (handle.resource == VMCI_INVALID_ID) {
+ result = VMCI_ERROR_NO_HANDLE;
+ goto out;
+ }
+ } else if (vmci_resource_lookup(handle, resource_type)) {
+ result = VMCI_ERROR_ALREADY_EXISTS;
+ goto out;
+
[PATCH 09/12] VMCI: routing implementation.
VMCI routing code is responsible for routing between various hosts/guests as
well
as routing in nested scenarios.
Signed-off-by: George Zhang georgezh...@vmware.com
Signed-off-by: Dmitry Torokhov d...@vmware.com
Signed-off-by: Andy King ack...@vmware.com
---
drivers/misc/vmw_vmci/vmci_route.c | 227
drivers/misc/vmw_vmci/vmci_route.h | 30 +
2 files changed, 257 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/vmw_vmci/vmci_route.c
create mode 100644 drivers/misc/vmw_vmci/vmci_route.h
diff --git a/drivers/misc/vmw_vmci/vmci_route.c
b/drivers/misc/vmw_vmci/vmci_route.c
new file mode 100644
index 000..7cca156
--- /dev/null
+++ b/drivers/misc/vmw_vmci/vmci_route.c
@@ -0,0 +1,227 @@
+/*
+ * VMware VMCI Driver
+ *
+ * Copyright (C) 2012 VMware, Inc. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation version 2 and no later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+ * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ * for more details.
+ */
+
+#include linux/vmw_vmci_defs.h
+#include linux/vmw_vmci_api.h
+
+#include vmci_common_int.h
+#include vmci_context.h
+#include vmci_driver.h
+#include vmci_route.h
+
+/*
+ * Make a routing decision for the given source and destination handles.
+ * This will try to determine the route using the handles and the available
+ * devices. Will set the source context if it is invalid.
+ */
+int vmci_route(struct vmci_handle *src,
+ const struct vmci_handle *dst,
+ bool from_guest,
+ enum vmci_route *route)
+{
+ bool has_host_device = vmci_host_code_active();
+ bool has_guest_device = vmci_guest_code_active();
+
+ *route = VMCI_ROUTE_NONE;
+
+ /*
+* from_guest is only ever set to true by
+* IOCTL_VMCI_DATAGRAM_SEND (or by the vmkernel equivalent),
+* which comes from the VMX, so we know it is coming from a
+* guest.
+*
+* To avoid inconsistencies, test these once. We will test
+* them again when we do the actual send to ensure that we do
+* not touch a non-existent device.
+*/
+
+ /* Must have a valid destination context. */
+ if (VMCI_INVALID_ID == dst-context)
+ return VMCI_ERROR_INVALID_ARGS;
+
+ /* Anywhere to hypervisor. */
+ if (VMCI_HYPERVISOR_CONTEXT_ID == dst-context) {
+
+ /*
+* If this message already came from a guest then we
+* cannot send it to the hypervisor. It must come
+* from a local client.
+*/
+ if (from_guest)
+ return VMCI_ERROR_DST_UNREACHABLE;
+
+ /*
+* We must be acting as a guest in order to send to
+* the hypervisor.
+*/
+ if (!has_guest_device)
+ return VMCI_ERROR_DEVICE_NOT_FOUND;
+
+ /* And we cannot send if the source is the host context. */
+ if (VMCI_HOST_CONTEXT_ID == src-context)
+ return VMCI_ERROR_INVALID_ARGS;
+
+ /*
+* If the client passed the ANON source handle then
+* respect it (both context and resource are invalid).
+* However, if they passed only an invalid context,
+* then they probably mean ANY, in which case we
+* should set the real context here before passing it
+* down.
+*/
+ if (VMCI_INVALID_ID == src-context
+ VMCI_INVALID_ID != src-resource)
+ src-context = vmci_get_context_id();
+
+ /* Send from local client down to the hypervisor. */
+ *route = VMCI_ROUTE_AS_GUEST;
+ return VMCI_SUCCESS;
+ }
+
+ /* Anywhere to local client on host. */
+ if (VMCI_HOST_CONTEXT_ID == dst-context) {
+ /*
+* If it is not from a guest but we are acting as a
+* guest, then we need to send it down to the host.
+* Note that if we are also acting as a host then this
+* will prevent us from sending from local client to
+* local client, but we accept that restriction as a
+* way to remove any ambiguity from the host context.
+*/
+ if (src-context == VMCI_HYPERVISOR_CONTEXT_ID) {
+ /*
+* If the hypervisor is the source, this is
+* host local communication. The hypervisor
+* may send vmci event
[PATCH 10/12] VMCI: guest side driver implementation.
VMCI guest side driver code implementation.
Signed-off-by: Dmitry Torokhov d...@vmware.com
Signed-off-by: Andy King ack...@vmware.com
Signed-off-by: George Zhang georgezh...@vmware.com
---
drivers/misc/vmw_vmci/vmci_guest.c | 757
1 files changed, 757 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/vmw_vmci/vmci_guest.c
diff --git a/drivers/misc/vmw_vmci/vmci_guest.c
b/drivers/misc/vmw_vmci/vmci_guest.c
new file mode 100644
index 000..bcbe8ab
--- /dev/null
+++ b/drivers/misc/vmw_vmci/vmci_guest.c
@@ -0,0 +1,757 @@
+/*
+ * VMware VMCI Driver
+ *
+ * Copyright (C) 2012 VMware, Inc. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation version 2 and no later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+ * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ * for more details.
+ */
+
+#include linux/vmw_vmci_defs.h
+#include linux/vmw_vmci_api.h
+#include linux/moduleparam.h
+#include linux/interrupt.h
+#include linux/highmem.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/sched.h
+#include linux/init.h
+#include linux/pci.h
+#include linux/smp.h
+#include linux/io.h
+
+#include vmci_common_int.h
+#include vmci_datagram.h
+#include vmci_doorbell.h
+#include vmci_context.h
+#include vmci_driver.h
+#include vmci_event.h
+
+#define VMCI_UTIL_NUM_RESOURCES 1
+
+static bool vmci_disable_msi;
+module_param_named(disable_msi, vmci_disable_msi, bool, 0);
+MODULE_PARM_DESC(disable_msi, Disable MSI use in driver - (default=0));
+
+static bool vmci_disable_msix;
+module_param_named(disable_msix, vmci_disable_msix, bool, 0);
+MODULE_PARM_DESC(disable_msix, Disable MSI-X use in driver - (default=0));
+
+static u32 ctx_update_sub_id = VMCI_INVALID_ID;
+static u32 vm_context_id = VMCI_INVALID_ID;
+
+struct vmci_guest_device {
+ struct device *dev; /* PCI device we are attached to */
+ void __iomem *iobase;
+
+ unsigned int irq;
+ unsigned int intr_type;
+ bool exclusive_vectors;
+ struct msix_entry msix_entries[VMCI_MAX_INTRS];
+
+ struct tasklet_struct datagram_tasklet;
+ struct tasklet_struct bm_tasklet;
+
+ void *data_buffer;
+ void *notification_bitmap;
+};
+
+/* vmci_dev singleton device and supporting data*/
+static struct vmci_guest_device *vmci_dev_g;
+static DEFINE_SPINLOCK(vmci_dev_spinlock);
+
+static atomic_t vmci_num_guest_devices = ATOMIC_INIT(0);
+
+bool vmci_guest_code_active(void)
+{
+ return atomic_read(vmci_num_guest_devices) != 0;
+}
+
+u32 vmci_get_vm_context_id(void)
+{
+ if (vm_context_id == VMCI_INVALID_ID) {
+ u32 result;
+ struct vmci_datagram get_cid_msg;
+ get_cid_msg.dst =
+ vmci_make_handle(VMCI_HYPERVISOR_CONTEXT_ID,
+VMCI_GET_CONTEXT_ID);
+ get_cid_msg.src = VMCI_ANON_SRC_HANDLE;
+ get_cid_msg.payload_size = 0;
+ result = vmci_send_datagram(get_cid_msg);
+ if (result = 0)
+ vm_context_id = result;
+ }
+ return vm_context_id;
+}
+
+/*
+ * VM to hypervisor call mechanism. We use the standard VMware naming
+ * convention since shared code is calling this function as well.
+ */
+int vmci_send_datagram(struct vmci_datagram *dg)
+{
+ unsigned long flags;
+ int result;
+
+ /* Check args. */
+ if (dg == NULL)
+ return VMCI_ERROR_INVALID_ARGS;
+
+ /*
+* Need to acquire spinlock on the device because the datagram
+* data may be spread over multiple pages and the monitor may
+* interleave device user rpc calls from multiple
+* VCPUs. Acquiring the spinlock precludes that
+* possibility. Disabling interrupts to avoid incoming
+* datagrams during a rep out and possibly landing up in
+* this function.
+*/
+ spin_lock_irqsave(vmci_dev_spinlock, flags);
+
+ if (vmci_dev_g) {
+ iowrite8_rep(vmci_dev_g-iobase + VMCI_DATA_OUT_ADDR,
+dg, VMCI_DG_SIZE(dg));
+ result = ioread32(vmci_dev_g-iobase + VMCI_RESULT_LOW_ADDR);
+ } else {
+ result = VMCI_ERROR_UNAVAILABLE;
+ }
+
+ spin_unlock_irqrestore(vmci_dev_spinlock, flags);
+
+ return result;
+}
+EXPORT_SYMBOL_GPL(vmci_send_datagram);
+
+/*
+ * Gets called with the new context id if updated or resumed.
+ * Context id.
+ */
+static void vmci_guest_cid_update(u32 sub_id,
+ const struct vmci_event_data *event_data,
+ void *client_data)
+{
+ const struct
[PATCH 11/12] VMCI: host side driver implementation.
VMCI host side driver code implementation.
Signed-off-by: George Zhang georgezh...@vmware.com
Signed-off-by: Dmitry Torokhov d...@vmware.com
Signed-off-by: Andy King ack...@vmware.com
---
drivers/misc/vmw_vmci/vmci_host.c | 1036 +
1 files changed, 1036 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/vmw_vmci/vmci_host.c
diff --git a/drivers/misc/vmw_vmci/vmci_host.c
b/drivers/misc/vmw_vmci/vmci_host.c
new file mode 100644
index 000..4639e91
--- /dev/null
+++ b/drivers/misc/vmw_vmci/vmci_host.c
@@ -0,0 +1,1036 @@
+/*
+ * VMware VMCI Driver
+ *
+ * Copyright (C) 2012 VMware, Inc. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation version 2 and no later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+ * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ * for more details.
+ */
+
+#include linux/vmw_vmci_defs.h
+#include linux/vmw_vmci_api.h
+#include linux/moduleparam.h
+#include linux/miscdevice.h
+#include linux/interrupt.h
+#include linux/highmem.h
+#include linux/atomic.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/mutex.h
+#include linux/sched.h
+#include linux/file.h
+#include linux/init.h
+#include linux/poll.h
+#include linux/pci.h
+#include linux/smp.h
+#include linux/fs.h
+#include linux/io.h
+
+#include vmci_handle_array.h
+#include vmci_common_int.h
+#include vmci_queue_pair.h
+#include vmci_datagram.h
+#include vmci_doorbell.h
+#include vmci_resource.h
+#include vmci_context.h
+#include vmci_driver.h
+#include vmci_event.h
+
+#define VMCI_UTIL_NUM_RESOURCES 1
+
+enum {
+ VMCI_NOTIFY_RESOURCE_QUEUE_PAIR = 0,
+ VMCI_NOTIFY_RESOURCE_DOOR_BELL = 1,
+};
+
+enum {
+ VMCI_NOTIFY_RESOURCE_ACTION_NOTIFY = 0,
+ VMCI_NOTIFY_RESOURCE_ACTION_CREATE = 1,
+ VMCI_NOTIFY_RESOURCE_ACTION_DESTROY = 2,
+};
+
+/*
+ * VMCI driver initialization. This block can also be used to
+ * pass initial group membership etc.
+ */
+struct vmci_init_blk {
+ u32 cid;
+ u32 flags;
+};
+
+/* VMCIqueue_pairAllocInfo_VMToVM */
+struct vmci_qp_alloc_info_vmvm {
+ struct vmci_handle handle;
+ u32 peer;
+ u32 flags;
+ u64 produce_size;
+ u64 consume_size;
+ u64 produce_page_file;/* User VA. */
+ u64 consume_page_file;/* User VA. */
+ u64 produce_page_file_size; /* Size of the file name array. */
+ u64 consume_page_file_size; /* Size of the file name array. */
+ s32 result;
+ u32 _pad;
+};
+
+/* VMCISetNotifyInfo: Used to pass notify flag's address to the host driver. */
+struct vmci_set_notify_info {
+ u64 notify_uva;
+ s32 result;
+ u32 _pad;
+};
+
+/*
+ * Per-instance host state
+ */
+struct vmci_host_dev {
+ struct vmci_ctx *context;
+ int user_version;
+ enum vmci_obj_type ct_type;
+ struct mutex lock; /* Mutex lock for vmci context access */
+};
+
+static struct vmci_ctx *host_context;
+static bool vmci_host_device_initialized;
+static atomic_t vmci_host_active_users = ATOMIC_INIT(0);
+
+/*
+ * Determines whether the VMCI host personality is
+ * available. Since the core functionality of the host driver is
+ * always present, all guests could possibly use the host
+ * personality. However, to minimize the deviation from the
+ * pre-unified driver state of affairs, we only consider the host
+ * device active if there is no active guest device or if there
+ * are VMX'en with active VMCI contexts using the host device.
+ */
+bool vmci_host_code_active(void)
+{
+ return vmci_host_device_initialized
+ (!vmci_guest_code_active() ||
+atomic_read(vmci_host_active_users) 0);
+}
+
+/*
+ * Called on open of /dev/vmci.
+ */
+static int vmci_host_open(struct inode *inode, struct file *filp)
+{
+ struct vmci_host_dev *vmci_host_dev;
+
+ vmci_host_dev = kzalloc(sizeof(struct vmci_host_dev), GFP_KERNEL);
+ if (vmci_host_dev == NULL)
+ return -ENOMEM;
+
+ vmci_host_dev-ct_type = VMCIOBJ_NOT_SET;
+ mutex_init(vmci_host_dev-lock);
+ filp-private_data = vmci_host_dev;
+
+ return 0;
+}
+
+/*
+ * Called on close of /dev/vmci, most often when the process
+ * exits.
+ */
+static int vmci_host_close(struct inode *inode, struct file *filp)
+{
+ struct vmci_host_dev *vmci_host_dev = filp-private_data;
+
+ if (vmci_host_dev-ct_type == VMCIOBJ_CONTEXT) {
+ vmci_ctx_destroy(vmci_host_dev-context);
+ vmci_host_dev-context = NULL;
+
+ /*
+* The number of active contexts is used to track whether any
+* VMX'en are using the host personality. It is incremented when
+
[PATCH 12/12] VMCI: Some header and config files.
VMCI head config patch Adds all the necessary files to enable building of the VMCI module with the Linux Makefiles and Kconfig systems. Also adds the header files used for building modules against the driver. Signed-off-by: George Zhang georgezh...@vmware.com Signed-off-by: Dmitry Torokhov d...@vmware.com Signed-off-by: Andy King ack...@vmware.com --- drivers/misc/Kconfig|1 drivers/misc/Makefile |2 drivers/misc/vmw_vmci/Kconfig | 16 + drivers/misc/vmw_vmci/Makefile |4 drivers/misc/vmw_vmci/vmci_common_int.h | 32 + include/linux/vmw_vmci_api.h| 82 +++ include/linux/vmw_vmci_defs.h | 973 +++ 7 files changed, 1110 insertions(+), 0 deletions(-) create mode 100644 drivers/misc/vmw_vmci/Kconfig create mode 100644 drivers/misc/vmw_vmci/Makefile create mode 100644 drivers/misc/vmw_vmci/vmci_common_int.h create mode 100644 include/linux/vmw_vmci_api.h create mode 100644 include/linux/vmw_vmci_defs.h diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index 2661f6e..fe38c7a 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -517,4 +517,5 @@ source drivers/misc/lis3lv02d/Kconfig source drivers/misc/carma/Kconfig source drivers/misc/altera-stapl/Kconfig source drivers/misc/mei/Kconfig +source drivers/misc/vmw_vmci/Kconfig endmenu diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile index 456972f..21ed953 100644 --- a/drivers/misc/Makefile +++ b/drivers/misc/Makefile @@ -51,3 +51,5 @@ obj-y += carma/ obj-$(CONFIG_USB_SWITCH_FSA9480) += fsa9480.o obj-$(CONFIG_ALTERA_STAPL) +=altera-stapl/ obj-$(CONFIG_INTEL_MEI)+= mei/ +obj-$(CONFIG_MAX8997_MUIC) += max8997-muic.o +obj-$(CONFIG_VMWARE_VMCI) += vmw_vmci/ diff --git a/drivers/misc/vmw_vmci/Kconfig b/drivers/misc/vmw_vmci/Kconfig new file mode 100644 index 000..55015e7 --- /dev/null +++ b/drivers/misc/vmw_vmci/Kconfig @@ -0,0 +1,16 @@ +# +# VMware VMCI device +# + +config VMWARE_VMCI + tristate VMware VMCI Driver + depends on X86 + help + This is VMware's Virtual Machine Communication Interface. It enables + high-speed communication between host and guest in a virtual + environment via the VMCI virtual device. + + If unsure, say N. + + To compile this driver as a module, choose M here: the + module will be called vmw_vmci. diff --git a/drivers/misc/vmw_vmci/Makefile b/drivers/misc/vmw_vmci/Makefile new file mode 100644 index 000..4da9893 --- /dev/null +++ b/drivers/misc/vmw_vmci/Makefile @@ -0,0 +1,4 @@ +obj-$(CONFIG_VMWARE_VMCI) += vmw_vmci.o +vmw_vmci-y += vmci_context.o vmci_datagram.o vmci_doorbell.o \ + vmci_driver.o vmci_event.o vmci_guest.o vmci_handle_array.o \ + vmci_host.o vmci_queue_pair.o vmci_resource.o vmci_route.o diff --git a/drivers/misc/vmw_vmci/vmci_common_int.h b/drivers/misc/vmw_vmci/vmci_common_int.h new file mode 100644 index 000..81a268a --- /dev/null +++ b/drivers/misc/vmw_vmci/vmci_common_int.h @@ -0,0 +1,32 @@ +/* + * VMware VMCI Driver + * + * Copyright (C) 2012 VMware, Inc. All rights reserved. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation version 2 and no later version. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY + * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * for more details. + */ + +#ifndef _VMCI_COMMONINT_H_ +#define _VMCI_COMMONINT_H_ + +#include linux/printk.h + +#define PCI_VENDOR_ID_VMWARE 0x15AD +#define PCI_DEVICE_ID_VMWARE_VMCI 0x0740 +#define VMCI_DRIVER_VERSION_STRING 1.0.0.0-k +#define MODULE_NAME vmw_vmci + +/* Print magic... whee! */ +#ifdef pr_fmt +#undef pr_fmt +#define pr_fmt(fmt) MODULE_NAME : fmt +#endif + +#endif /* _VMCI_COMMONINT_H_ */ diff --git a/include/linux/vmw_vmci_api.h b/include/linux/vmw_vmci_api.h new file mode 100644 index 000..193129d --- /dev/null +++ b/include/linux/vmw_vmci_api.h @@ -0,0 +1,82 @@ +/* + * VMware VMCI Driver + * + * Copyright (C) 2012 VMware, Inc. All rights reserved. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation version 2 and no later version. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY + * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * for more details. + */ + +#ifndef __VMW_VMCI_API_H__ +#define __VMW_VMCI_API_H__ + +#include linux/uidgid.h +#include linux/vmw_vmci_defs.h + +#undef VMCI_KERNEL_API_VERSION
[PATCH 0/6] VSOCK for Linux upstreaming
* * * This series of VSOCK linux upstreaming patches include latest udpate from VMware. Summary of changes: - Sparse clean. - Checkpatch clean with one exception, a complex macro in which we can't add parentheses. - Remove all runtime assertions. - Fix device name, so that existing user clients work. - Fix VMCI handle lookup. * * * In an effort to improve the out-of-the-box experience with Linux kernels for VMware users, VMware is working on readying the Virtual Machine Communication Interface (vmw_vmci) and VMCI Sockets (VSOCK) (vmw_vsock) kernel modules for inclusion in the Linux kernel. The purpose of this post is to acquire feedback on the vmw_vsock kernel module. The vmw_vmci kernel module has been presented in an early post. * * * VMCI Sockets allows virtual machines to communicate with host kernel modules and the VMware hypervisors. VMCI Sockets kernel module has dependency on VMCI kernel module. User level applications both in a virtual machine and on the host can use vmw_vmci through VMCI Sockets API which facilitates fast and efficient communication between guest virtual machines and their host. A socket address family designed to be compatible with UDP and TCP at the interface level. Today, VMCI and VMCI Sockets are used by the VMware shared folders (HGFS) and various VMware Tools components inside the guest for zero-config, network-less access to VMware host services. In addition to this, VMware's users are using VMCI Sockets for various applications, where network access of the virtual machine is restricted or non-existent. Examples of this are VMs communicating with device proxies for proprietary hardware running as host applications and automated testing of applications running within virtual machines. The VMware VMCI Sockets are similar to other socket types, like Berkeley UNIX socket interface. The VMCI sockets module supports both connection-oriented stream sockets like TCP, and connectionless datagram sockets like UDP. The VSOCK protocol family is defined as AF_VSOCK and the socket operations split for SOCK_DGRAM and SOCK_STREAM. For additional information about the use of VMCI and in particular VMCI Sockets, please refer to the VMCI Socket Programming Guide available at https://www.vmware.com/support/developer/vmci-sdk/. --- George Zhang (6): VSOCK: vsock protocol implementation. VSOCK: vsock address implementaion. VSOCK: notification implementation. VSOCK: statistics implementation. VSOCK: utility functions. VSOCK: header and config files. include/linux/socket.h |4 net/Kconfig |1 net/Makefile|1 net/vmw_vsock/Kconfig | 14 net/vmw_vsock/Makefile |4 net/vmw_vsock/af_vsock.c| 4054 +++ net/vmw_vsock/af_vsock.h| 180 ++ net/vmw_vsock/notify.c | 983 net/vmw_vsock/notify.h | 130 + net/vmw_vsock/notify_qstate.c | 625 + net/vmw_vsock/stats.c | 37 net/vmw_vsock/stats.h | 217 ++ net/vmw_vsock/util.c| 620 + net/vmw_vsock/util.h| 314 +++ net/vmw_vsock/vmci_sockets.h| 517 net/vmw_vsock/vmci_sockets_packet.h | 90 + net/vmw_vsock/vsock_addr.c | 246 ++ net/vmw_vsock/vsock_addr.h | 40 net/vmw_vsock/vsock_common.h| 127 + net/vmw_vsock/vsock_packet.h| 124 + net/vmw_vsock/vsock_version.h | 28 21 files changed, 8355 insertions(+), 1 deletions(-) create mode 100644 net/vmw_vsock/Kconfig create mode 100644 net/vmw_vsock/Makefile create mode 100644 net/vmw_vsock/af_vsock.c create mode 100644 net/vmw_vsock/af_vsock.h create mode 100644 net/vmw_vsock/notify.c create mode 100644 net/vmw_vsock/notify.h create mode 100644 net/vmw_vsock/notify_qstate.c create mode 100644 net/vmw_vsock/stats.c create mode 100644 net/vmw_vsock/stats.h create mode 100644 net/vmw_vsock/util.c create mode 100644 net/vmw_vsock/util.h create mode 100644 net/vmw_vsock/vmci_sockets.h create mode 100644 net/vmw_vsock/vmci_sockets_packet.h create mode 100644 net/vmw_vsock/vsock_addr.c create mode 100644 net/vmw_vsock/vsock_addr.h create mode 100644 net/vmw_vsock/vsock_common.h create mode 100644 net/vmw_vsock/vsock_packet.h create mode 100644 net/vmw_vsock/vsock_version.h -- Signature -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/6] VSOCK: vsock address implementaion.
VSOCK linux address code implementation.
Signed-off-by: George Zhang georgezh...@vmware.com
Signed-off-by: Dmitry Torokhov d...@vmware.com
Signed-off-by: Andy King ack...@vmware.com
---
net/vmw_vsock/vsock_addr.c | 246
net/vmw_vsock/vsock_addr.h | 40 +++
2 files changed, 286 insertions(+), 0 deletions(-)
create mode 100644 net/vmw_vsock/vsock_addr.c
create mode 100644 net/vmw_vsock/vsock_addr.h
diff --git a/net/vmw_vsock/vsock_addr.c b/net/vmw_vsock/vsock_addr.c
new file mode 100644
index 000..35eeb14
--- /dev/null
+++ b/net/vmw_vsock/vsock_addr.c
@@ -0,0 +1,246 @@
+/*
+ * VMware vSockets Driver
+ *
+ * Copyright (C) 2007-2012 VMware, Inc. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation version 2 and no later version.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ */
+
+/*
+ * vsockAddr.c --
+ *
+ * VSockets address implementation.
+ */
+
+#include linux/types.h
+#include linux/socket.h
+#include linux/stddef.h /* for NULL */
+#include net/sock.h
+
+#include vsock_common.h
+
+/*
+ *
+ * vsock_addr_init --
+ *
+ * Initialize the given address with the given context id and port. This will
+ * clear the address, set the correct family, and add the given values.
+ *
+ * Results: None.
+ *
+ * Side effects: None.
+ */
+
+void vsock_addr_init(struct sockaddr_vm *addr, u32 cid, u32 port)
+{
+ memset(addr, 0, sizeof *addr);
+
+ addr-svm_family = AF_VSOCK;
+ addr-svm_cid = cid;
+ addr-svm_port = port;
+}
+
+/*
+ *
+ * vsock_addr_validate --
+ *
+ * Try to validate the given address. The address must not be null and must
+ * have the correct address family. Any reserved fields must be zero.
+ *
+ * Results: 0 on success, EFAULT if the address is null, EAFNOSUPPORT if the
+ * address is of the wrong family, and EINVAL if the reserved fields are not
+ * zero.
+ *
+ * Side effects: None.
+ */
+
+int vsock_addr_validate(const struct sockaddr_vm *addr)
+{
+ if (!addr)
+ return -EFAULT;
+
+ if (addr-svm_family != AF_VSOCK)
+ return -EAFNOSUPPORT;
+
+ if (addr-svm_zero[0] != 0)
+ return -EINVAL;
+
+ return 0;
+}
+
+/*
+ *
+ * vsock_addr_bound --
+ *
+ * Determines whether the provided address is bound.
+ *
+ * Results: TRUE if the address structure is bound, FALSE otherwise.
+ *
+ * Side effects: None.
+ */
+
+bool vsock_addr_bound(const struct sockaddr_vm *addr)
+{
+ return addr-svm_port != VMADDR_PORT_ANY;
+}
+
+/*
+ *
+ * vsock_addr_unbind --
+ *
+ * Unbind the given addresss.
+ *
+ * Results: None.
+ *
+ * Side effects: None.
+ */
+
+void vsock_addr_unbind(struct sockaddr_vm *addr)
+{
+ vsock_addr_init(addr, VMADDR_CID_ANY, VMADDR_PORT_ANY);
+}
+
+/*
+ *
+ * vsock_addr_equals_addr --
+ *
+ * Determine if the given addresses are equal.
+ *
+ * Results: TRUE if the addresses are equal, FALSE otherwise.
+ *
+ * Side effects: None.
+ */
+
+bool vsock_addr_equals_addr(const struct sockaddr_vm *addr,
+ const struct sockaddr_vm *other)
+{
+ return addr-svm_cid == other-svm_cid
+ addr-svm_port == other-svm_port;
+}
+
+/*
+ *
+ * vsock_addr_equals_addr_any --
+ *
+ * Determine if the given addresses are equal. Will accept either an exact
+ * match or one where the rids match and that either the cids match or are set
+ * to VMADDR_CID_ANY.
+ *
+ * Results: TRUE if the addresses are equal, FALSE otherwise.
+ *
+ * Side effects: None.
+ */
+
+bool vsock_addr_equals_addr_any(const struct sockaddr_vm *addr,
+ const struct sockaddr_vm *other)
+{
+ return (addr-svm_cid == VMADDR_CID_ANY ||
+ other-svm_cid == VMADDR_CID_ANY ||
+ addr-svm_cid == other-svm_cid)
+ addr-svm_port == other-svm_port;
+}
+
+/*
+ *
+ * vsock_addr_equals_handle_port --
+ *
+ * Determines if the given address matches the given handle and port.
+ *
+ * Results: TRUE if the address matches the handle and port, FALSE otherwise.
+ *
+ * Side effects: None.
+ */
+
+bool vsock_addr_equals_handle_port(const struct sockaddr_vm *addr,
+ struct vmci_handle handle, u32 port)
+{
+ return addr-svm_cid == VMCI_HANDLE_TO_CONTEXT_ID(handle)
+ addr-svm_port == port;
+}
+
+/*
+ *
+ * vsock_addr_cast --
+ *
+ * Try to cast the given generic address to a VM address. The given length
+ * must match that of a VM address and the address must be valid. The
+ * out_addr parameter contains the address if successful.
+ *
+ * Results: 0 on success, EFAULT if the length is too small.
[PATCH 3/6] VSOCK: notification implementation.
VSOCK control notifications for VMCI Stream Sockets protocol.
Signed-off-by: George Zhang georgezh...@vmware.com
Signed-off-by: Dmitry Torokhov d...@vmware.com
Signed-off-by: Andy King ack...@vmware.com
---
net/vmw_vsock/notify.c | 983
net/vmw_vsock/notify.h | 130 ++
2 files changed, 1113 insertions(+), 0 deletions(-)
create mode 100644 net/vmw_vsock/notify.c
create mode 100644 net/vmw_vsock/notify.h
diff --git a/net/vmw_vsock/notify.c b/net/vmw_vsock/notify.c
new file mode 100644
index 000..8504e28
--- /dev/null
+++ b/net/vmw_vsock/notify.c
@@ -0,0 +1,983 @@
+/*
+ * VMware vSockets Driver
+ *
+ * Copyright (C) 2009-2012 VMware, Inc. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation version 2 and no later version.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ */
+
+/*
+ * notify.c --
+ *
+ * Linux control notifications for the VMCI Stream Sockets protocol.
+ */
+
+#include linux/types.h
+
+#include linux/socket.h
+#include linux/stddef.h /* for NULL */
+#include net/sock.h
+
+#include notify.h
+#include af_vsock.h
+
+#define PKT_FIELD(vsk, field_name) ((vsk)-notify.pkt.field_name)
+
+#define VSOCK_MAX_DGRAM_RESENDS 10
+
+/*
+ *
+ * vsock_vmci_notify_waiting_write --
+ *
+ * Determines if the conditions have been met to notify a waiting writer.
+ *
+ * Results: true if a notification should be sent, false otherwise.
+ *
+ * Side effects: None.
+ */
+
+static bool vsock_vmci_notify_waiting_write(struct vsock_vmci_sock *vsk)
+{
+#if defined(VSOCK_OPTIMIZATION_WAITING_NOTIFY)
+ bool retval;
+ u64 notify_limit;
+
+ if (!PKT_FIELD(vsk, peer_waiting_write))
+ return false;
+
+#ifdef VSOCK_OPTIMIZATION_FLOW_CONTROL
+ /*
+* When the sender blocks, we take that as a sign that the sender is
+* faster than the receiver. To reduce the transmit rate of the sender,
+* we delay the sending of the read notification by decreasing the
+* write_notify_window. The notification is delayed until the number of
+* bytes used in the queue drops below the write_notify_window.
+*/
+
+ if (!PKT_FIELD(vsk, peer_waiting_write_detected)) {
+ PKT_FIELD(vsk, peer_waiting_write_detected) = true;
+ if (PKT_FIELD(vsk, write_notify_window) PAGE_SIZE) {
+ PKT_FIELD(vsk, write_notify_window) =
+ PKT_FIELD(vsk, write_notify_min_window);
+ } else {
+ PKT_FIELD(vsk, write_notify_window) -= PAGE_SIZE;
+ if (PKT_FIELD(vsk, write_notify_window)
+ PKT_FIELD(vsk, write_notify_min_window))
+ PKT_FIELD(vsk, write_notify_window) =
+ PKT_FIELD(vsk, write_notify_min_window);
+
+ }
+ }
+ notify_limit = vsk-consume_size - PKT_FIELD(vsk, write_notify_window);
+#else
+ notify_limit = 0;
+#endif
+
+ /*
+* For now we ignore the wait information and just see if the free
+* space exceeds the notify limit. Note that improving this function
+* to be more intelligent will not require a protocol change and will
+* retain compatibility between endpoints with mixed versions of this
+* function.
+*
+* The notify_limit is used to delay notifications in the case where
+* flow control is enabled. Below the test is expressed in terms of
+* free space in the queue: if free_space ConsumeSize -
+* write_notify_window then notify An alternate way of expressing this
+* is to rewrite the expression to use the data ready in the receive
+* queue: if write_notify_window bufferReady then notify as
+* free_space == ConsumeSize - bufferReady.
+*/
+ retval = vmci_qpair_consume_free_space(vsk-qpair) notify_limit;
+#ifdef VSOCK_OPTIMIZATION_FLOW_CONTROL
+ if (retval) {
+ /*
+* Once we notify the peer, we reset the detected flag so the
+* next wait will again cause a decrease in the window size.
+*/
+
+ PKT_FIELD(vsk, peer_waiting_write_detected) = false;
+ }
+#endif
+ return retval;
+#else
+ return true;
+#endif
+}
+
+/*
+ *
+ * vsock_vmci_notify_waiting_read --
+ *
+ * Determines if the conditions have been met to notify a waiting reader.
+ *
+ * Results: true if a notification should be sent, false otherwise.
+ *
+ * Side effects: None.
+ */
+
+static bool
[PATCH 4/6] VSOCK: statistics implementation.
VSOCK stats for VMCI Stream Sockets protocol.
Signed-off-by: George Zhang georgezh...@vmware.com
Signed-off-by: Dmitry Torokhov d...@vmware.com
Signed-off-by: Andy King ack...@vmware.com
---
net/vmw_vsock/stats.c | 37
net/vmw_vsock/stats.h | 217 +
2 files changed, 254 insertions(+), 0 deletions(-)
create mode 100644 net/vmw_vsock/stats.c
create mode 100644 net/vmw_vsock/stats.h
diff --git a/net/vmw_vsock/stats.c b/net/vmw_vsock/stats.c
new file mode 100644
index 000..2d172d5
--- /dev/null
+++ b/net/vmw_vsock/stats.c
@@ -0,0 +1,37 @@
+/*
+ * VMware vSockets Driver
+ *
+ * Copyright (C) 2009-2012 VMware, Inc. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation version 2 and no later version.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ */
+
+/*
+ * stats.c --
+ *
+ * Linux stats for the VMCI Stream Sockets protocol.
+ */
+
+#include linux/types.h
+
+#include linux/socket.h
+#include linux/stddef.h /* for NULL */
+#include net/sock.h
+
+#include af_vsock.h
+#include stats.h
+
+#ifdef VSOCK_GATHER_STATISTICS
+u64 vsock_stats_ctl_pkt_count[VSOCK_PACKET_TYPE_MAX];
+u64 vsock_stats_consume_queue_hist[VSOCK_NUM_QUEUE_LEVEL_BUCKETS];
+u64 vsock_stats_produce_queue_hist[VSOCK_NUM_QUEUE_LEVEL_BUCKETS];
+atomic64_t vsock_stats_consume_total;
+atomic64_t vsock_stats_produce_total;
+#endif
diff --git a/net/vmw_vsock/stats.h b/net/vmw_vsock/stats.h
new file mode 100644
index 000..9949b22
--- /dev/null
+++ b/net/vmw_vsock/stats.h
@@ -0,0 +1,217 @@
+/*
+ * VMware vSockets Driver
+ *
+ * Copyright (C) 2009-2012 VMware, Inc. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation version 2 and no later version.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ */
+
+/*
+ * stats.h --
+ *
+ * Stats functions for Linux vsock module.
+ */
+
+#ifndef __STATS_H__
+#define __STATS_H__
+
+#include linux/types.h
+
+#include vsock_common.h
+#include vsock_packet.h
+
+/*
+ * Define VSOCK_GATHER_STATISTICS to turn on statistics gathering. Currently
+ * this consists of 3 types of stats: 1. The number of control datagram
+ * messages sent. 2. The level of queuepair fullness (in 10% buckets) whenever
+ * data is about to be enqueued or dequeued from the queuepair. 3. The total
+ * number of bytes enqueued/dequeued.
+ */
+
+#ifdef VSOCK_GATHER_STATISTICS
+
+#define VSOCK_NUM_QUEUE_LEVEL_BUCKETS 10
+extern u64 vsock_stats_ctl_pkt_count[VSOCK_PACKET_TYPE_MAX];
+extern u64 vsock_stats_consume_queue_hist[VSOCK_NUM_QUEUE_LEVEL_BUCKETS];
+extern u64 vsock_stats_produce_queue_hist[VSOCK_NUM_QUEUE_LEVEL_BUCKETS];
+extern atomic64_t vsock_stats_consume_total;
+extern atomic64_t vsock_stats_produce_total;
+
+#define VSOCK_STATS_STREAM_CONSUME_HIST(vsk) \
+ vsock_vmci_stats_update_queue_bucket_count((vsk)-qpair,\
+ (vsk)-consume_size,\
+ vmci_qpair_consume_buf_ready((vsk)-qpair), \
+ vsock_stats_consume_queue_hist)
+#define VSOCK_STATS_STREAM_PRODUCE_HIST(vsk) \
+ vsock_vmci_stats_update_queue_bucket_count((vsk)-qpair,\
+ (vsk)-produce_size,\
+ vmci_qpair_produce_buf_ready((vsk)-qpair), \
+ vsock_stats_produce_queue_hist)
+#define VSOCK_STATS_CTLPKT_LOG(pkt_type) \
+ do {\
+ ++vsock_stats_ctl_pkt_count[pkt_type]; \
+ } while (0)
+#define VSOCK_STATS_STREAM_CONSUME(bytes) \
+ atomic64_add(vsock_stats_consume_total, bytes)
+#define VSOCK_STATS_STREAM_PRODUCE(bytes) \
+ atomic64_add(vsock_stats_produce_total, bytes)
+#define VSOCK_STATS_CTLPKT_DUMP_ALL() vsock_vmci_stats_ctl_pkt_dump_all()
+#define VSOCK_STATS_HIST_DUMP_ALL() vsock_vmci_stats_hist_dump_all()
+#define VSOCK_STATS_TOTALS_DUMP_ALL() vsock_vmci_stats_totals_dump_all()
+#define VSOCK_STATS_RESET() vsock_vmci_stats_reset()
+
+/*
+ *
+ * vsock_vmci_stats_update_queue_bucket_count --
+ *
+ * Given a queue, determine how much data is enqueued and add that to the
+ *
[PATCH 5/6] VSOCK: utility functions.
VSOCK utility functions for Linux VSocket module.
Signed-off-by: George Zhang georgezh...@vmware.com
Signed-off-by: Dmitry Torokhov d...@vmware.com
Signed-off-by: Andy King ack...@vmware.com
---
net/vmw_vsock/util.c | 620 ++
net/vmw_vsock/util.h | 314 +
2 files changed, 934 insertions(+), 0 deletions(-)
create mode 100644 net/vmw_vsock/util.c
create mode 100644 net/vmw_vsock/util.h
diff --git a/net/vmw_vsock/util.c b/net/vmw_vsock/util.c
new file mode 100644
index 000..cd86482
--- /dev/null
+++ b/net/vmw_vsock/util.c
@@ -0,0 +1,620 @@
+/*
+ * VMware vSockets Driver
+ *
+ * Copyright (C) 2007-2012 VMware, Inc. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation version 2 and no later version.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ */
+
+/*
+ * util.c --
+ *
+ * Utility functions for Linux VSocket module.
+ */
+
+#include linux/types.h
+#include linux/list.h
+#include linux/socket.h
+#include linux/stddef.h /* for NULL */
+#include net/sock.h
+
+#include af_vsock.h
+#include util.h
+
+struct list_head vsock_bind_table[VSOCK_HASH_SIZE + 1];
+struct list_head vsock_connected_table[VSOCK_HASH_SIZE];
+
+DEFINE_SPINLOCK(vsock_table_lock);
+
+/*
+ *
+ * vsock_vmci_log_pkt --
+ *
+ * Logs the provided packet.
+ *
+ * Results: None.
+ *
+ * Side effects: None.
+ */
+
+void vsock_vmci_log_pkt(char const *function, u32 line,
+ struct vsock_packet *pkt)
+{
+ char buf[256];
+ char *cur = buf;
+ int left = sizeof buf;
+ int written = 0;
+ char *type_strings[] = {
+ [VSOCK_PACKET_TYPE_INVALID] = INVALID,
+ [VSOCK_PACKET_TYPE_REQUEST] = REQUEST,
+ [VSOCK_PACKET_TYPE_NEGOTIATE] = NEGOTIATE,
+ [VSOCK_PACKET_TYPE_OFFER] = OFFER,
+ [VSOCK_PACKET_TYPE_ATTACH] = ATTACH,
+ [VSOCK_PACKET_TYPE_WROTE] = WROTE,
+ [VSOCK_PACKET_TYPE_READ] = READ,
+ [VSOCK_PACKET_TYPE_RST] = RST,
+ [VSOCK_PACKET_TYPE_SHUTDOWN] = SHUTDOWN,
+ [VSOCK_PACKET_TYPE_WAITING_WRITE] = WAITING_WRITE,
+ [VSOCK_PACKET_TYPE_WAITING_READ] = WAITING_READ,
+ [VSOCK_PACKET_TYPE_REQUEST2] = REQUEST2,
+ [VSOCK_PACKET_TYPE_NEGOTIATE2] = NEGOTIATE2,
+ };
+
+ written = snprintf(cur, left, PKT: %u:%u - %u:%u,
+ VMCI_HANDLE_TO_CONTEXT_ID(pkt-dg.src),
+ pkt-src_port,
+ VMCI_HANDLE_TO_CONTEXT_ID(pkt-dg.dst),
+ pkt-dst_port);
+ if (written = left)
+ goto error;
+
+ left -= written;
+ cur += written;
+
+ switch (pkt-type) {
+ case VSOCK_PACKET_TYPE_REQUEST:
+ case VSOCK_PACKET_TYPE_NEGOTIATE:
+ written = snprintf(cur, left, , %s, size = % FMT64 u,
+ type_strings[pkt-type], pkt-u.size);
+ break;
+
+ case VSOCK_PACKET_TYPE_OFFER:
+ case VSOCK_PACKET_TYPE_ATTACH:
+ written = snprintf(cur, left, , %s, handle = %u:%u,
+ type_strings[pkt-type],
+ VMCI_HANDLE_TO_CONTEXT_ID(pkt-u.handle),
+ VMCI_HANDLE_TO_RESOURCE_ID(pkt-u.handle));
+ break;
+
+ case VSOCK_PACKET_TYPE_WROTE:
+ case VSOCK_PACKET_TYPE_READ:
+ case VSOCK_PACKET_TYPE_RST:
+ written = snprintf(cur, left, , %s, type_strings[pkt-type]);
+ break;
+ case VSOCK_PACKET_TYPE_SHUTDOWN: {
+ bool recv;
+ bool send;
+
+ recv = pkt-u.mode RCV_SHUTDOWN;
+ send = pkt-u.mode SEND_SHUTDOWN;
+ written = snprintf(cur, left, , %s, mode = %c%c,
+ type_strings[pkt-type],
+ recv ? 'R' : ' ', send ? 'S' : ' ');
+ }
+ break;
+
+ case VSOCK_PACKET_TYPE_WAITING_WRITE:
+ case VSOCK_PACKET_TYPE_WAITING_READ:
+ written = snprintf(cur, left,
+ , %s, generation = % FMT64 u, offset = % FMT64 u,
+ type_strings[pkt-type],
+ pkt-u.wait.generation, pkt-u.wait.offset);
+
+ break;
+
+ case VSOCK_PACKET_TYPE_REQUEST2:
+ case VSOCK_PACKET_TYPE_NEGOTIATE2:
+ written = snprintf(cur, left,
+ , %s, size = % FMT64 u, proto = %u,
+
[PATCH 6/6] VSOCK: header and config files.
VSOCK header files, Makefiles and Kconfig systems for Linux VSocket module.
Signed-off-by: George Zhang georgezh...@vmware.com
Signed-off-by: Dmitry Torokhov d...@vmware.com
Signed-off-by: Andy King ack...@vmware.com
---
include/linux/socket.h |4
net/Kconfig |1
net/Makefile|1
net/vmw_vsock/Kconfig | 14 +
net/vmw_vsock/Makefile |4
net/vmw_vsock/notify_qstate.c | 625 +++
net/vmw_vsock/vmci_sockets.h| 517 +
net/vmw_vsock/vmci_sockets_packet.h | 90 +
net/vmw_vsock/vsock_common.h| 127 +++
net/vmw_vsock/vsock_packet.h| 124 +++
net/vmw_vsock/vsock_version.h | 28 ++
11 files changed, 1534 insertions(+), 1 deletions(-)
create mode 100644 net/vmw_vsock/Kconfig
create mode 100644 net/vmw_vsock/Makefile
create mode 100644 net/vmw_vsock/notify_qstate.c
create mode 100644 net/vmw_vsock/vmci_sockets.h
create mode 100644 net/vmw_vsock/vmci_sockets_packet.h
create mode 100644 net/vmw_vsock/vsock_common.h
create mode 100644 net/vmw_vsock/vsock_packet.h
create mode 100644 net/vmw_vsock/vsock_version.h
diff --git a/include/linux/socket.h b/include/linux/socket.h
index 25d6322..57bc85e 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -195,7 +195,8 @@ struct ucred {
#define AF_CAIF37 /* CAIF sockets */
#define AF_ALG 38 /* Algorithm sockets*/
#define AF_NFC 39 /* NFC sockets */
-#define AF_MAX 40 /* For now.. */
+#define AF_VSOCK 40 /* VMCI sockets */
+#define AF_MAX 41 /* For now.. */
/* Protocol families, same as address families. */
#define PF_UNSPEC AF_UNSPEC
@@ -238,6 +239,7 @@ struct ucred {
#define PF_CAIFAF_CAIF
#define PF_ALG AF_ALG
#define PF_NFC AF_NFC
+#define PF_VSOCK AF_VSOCK
#define PF_MAX AF_MAX
/* Maximum queue length specifiable by listen. */
diff --git a/net/Kconfig b/net/Kconfig
index 245831b..75b8d5e 100644
--- a/net/Kconfig
+++ b/net/Kconfig
@@ -216,6 +216,7 @@ source net/dcb/Kconfig
source net/dns_resolver/Kconfig
source net/batman-adv/Kconfig
source net/openvswitch/Kconfig
+source net/vmw_vsock/Kconfig
config RPS
boolean
diff --git a/net/Makefile b/net/Makefile
index 4f4ee08..cae59f4 100644
--- a/net/Makefile
+++ b/net/Makefile
@@ -70,3 +70,4 @@ obj-$(CONFIG_CEPH_LIB)+= ceph/
obj-$(CONFIG_BATMAN_ADV) += batman-adv/
obj-$(CONFIG_NFC) += nfc/
obj-$(CONFIG_OPENVSWITCH) += openvswitch/
+obj-$(CONFIG_VMWARE_VSOCK) += vmw_vsock/
diff --git a/net/vmw_vsock/Kconfig b/net/vmw_vsock/Kconfig
new file mode 100644
index 000..95e2568
--- /dev/null
+++ b/net/vmw_vsock/Kconfig
@@ -0,0 +1,14 @@
+#
+# Vsock protocol
+#
+
+config VMWARE_VSOCK
+ tristate Virtual Socket protocol
+ depends on VMWARE_VMCI
+ help
+ Virtual Socket Protocol is a socket protocol similar to TCP/IP
+ allowing comunication between Virtual Machines and VMware
+ hypervisor.
+
+ To compile this driver as a module, choose M here: the module
+ will be called vsock. If unsure, say N.
diff --git a/net/vmw_vsock/Makefile b/net/vmw_vsock/Makefile
new file mode 100644
index 000..4e940fe
--- /dev/null
+++ b/net/vmw_vsock/Makefile
@@ -0,0 +1,4 @@
+obj-$(CONFIG_VMWARE_VSOCK) += vmw_vsock.o
+
+vmw_vsock-y += af_vsock.o notify.o notify_qstate.o stats.o util.o \
+ vsock_addr.o
diff --git a/net/vmw_vsock/notify_qstate.c b/net/vmw_vsock/notify_qstate.c
new file mode 100644
index 000..5a2f066
--- /dev/null
+++ b/net/vmw_vsock/notify_qstate.c
@@ -0,0 +1,625 @@
+/*
+ * VMware vSockets Driver
+ *
+ * Copyright (C) 2009-2012 VMware, Inc. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation version 2 and no later version.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ */
+
+/*
+ * notifyQState.c --
+ *
+ * Linux control notifications based on Queuepair state for the VMCI Stream
+ * Sockets protocol.
+ */
+
+#include linux/types.h
+
+#include linux/socket.h
+
+#include linux/stddef.h /* for NULL */
+#include net/sock.h
+
+#include notify.h
+#include af_vsock.h
+
+#define PKT_FIELD(vsk, field_name) ((vsk)-notify.pkt_q_state.field_name)
+
+/*
+ *
+ * vsock_vmci_notify_waiting_write --
+ *
+ * Determines if the conditions have been met to notify a waiting writer.
+ *
+ * Results: true if a notification should be
Re: [PATCH 1/3] CLK: uninline clk_prepare() and clk_unprepare()
Quoting Viresh Kumar (2012-11-20 02:13:55)
On 20 November 2012 14:52, Dmitry Torokhov dmitry.torok...@gmail.com wrote:
We'll need to invoke clk_unprepare() via a pointer in our devm_*
conversion so let's uninline the pair.
Sorry, but you aren't doing this :(
This routine is already uninlined as it is in clk.c
Instead you are just moving clk_prepare(), etc calls within
#ifdef CONFIG_HAVE_CLK
#else
#endif
I doubt why they have been added under #ifdef CONFIG_HAVE_CLK_PREPARE
earlier. Can they exist without CONFIG_HAVE_CLK
@Mike: ?
HAVE_CLK logically wraps HAVE_CLK_PREPARE. There is no point in
selecting HAVE_CLK_PREPARE without HAVE_CLK.
Looking through the code I see that this used to be the case. Commit
93abe8e clk: add non CONFIG_HAVE_CLK routines moved the
clk_(un)prepare declarations outside of #ifdef CONFIG_HAVE_CLK. That
commit was authored by you. Can you elaborate on why that aspect of the
patch was needed?
Thanks,
Mike
Signed-off-by: Dmitry Torokhov dmitry.torok...@gmail.com
---
drivers/clk/clk.c | 4
include/linux/clk.h | 68
+
2 files changed, 36 insertions(+), 36 deletions(-)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 56e4495e..1b642f2 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -374,6 +374,7 @@ struct clk *__clk_lookup(const char *name)
void __clk_unprepare(struct clk *clk)
{
+#ifdef CONFIG_HAVE_CLK_PREPARE
clk.c is compiled if COMMON_CLK is selected. And COMMON_CLK has following:
select HAVE_CLK_PREPARE
So, these checks you added don't have a meaning.
if (!clk)
return;
@@ -389,6 +390,7 @@ void __clk_unprepare(struct clk *clk)
clk-ops-unprepare(clk-hw);
__clk_unprepare(clk-parent);
+#endif
}
/**
@@ -412,6 +414,7 @@ EXPORT_SYMBOL_GPL(clk_unprepare);
int __clk_prepare(struct clk *clk)
{
+#ifdef CONFIG_HAVE_CLK_PREPARE
ditto.
int ret = 0;
if (!clk)
@@ -432,6 +435,7 @@ int __clk_prepare(struct clk *clk)
}
clk-prepare_count++;
+#endif
return 0;
}
diff --git a/include/linux/clk.h b/include/linux/clk.h
index b3ac22d..f8204c3 100644
--- a/include/linux/clk.h
+++ b/include/linux/clk.h
@@ -84,42 +84,6 @@ int clk_notifier_unregister(struct clk *clk, struct
notifier_block *nb);
#endif
-/**
- * clk_prepare - prepare a clock source
- * @clk: clock source
- *
- * This prepares the clock source for use.
- *
- * Must not be called from within atomic context.
- */
-#ifdef CONFIG_HAVE_CLK_PREPARE
-int clk_prepare(struct clk *clk);
-#else
-static inline int clk_prepare(struct clk *clk)
-{
- might_sleep();
- return 0;
-}
-#endif
-
-/**
- * clk_unprepare - undo preparation of a clock source
- * @clk: clock source
- *
- * This undoes a previously prepared clock. The caller must balance
- * the number of prepare and unprepare calls.
- *
- * Must not be called from within atomic context.
- */
-#ifdef CONFIG_HAVE_CLK_PREPARE
-void clk_unprepare(struct clk *clk);
-#else
-static inline void clk_unprepare(struct clk *clk)
-{
- might_sleep();
-}
-#endif
-
#ifdef CONFIG_HAVE_CLK
/**
* clk_get - lookup and obtain a reference to a clock producer.
@@ -159,6 +123,27 @@ struct clk *clk_get(struct device *dev, const char
*id);
struct clk *devm_clk_get(struct device *dev, const char *id);
/**
+ * clk_prepare - prepare a clock source
+ * @clk: clock source
+ *
+ * This prepares the clock source for use.
+ *
+ * Must not be called from within atomic context.
+ */
+int clk_prepare(struct clk *clk);
+
+/**
+ * clk_unprepare - undo preparation of a clock source
+ * @clk: clock source
+ *
+ * This undoes a previously prepared clock. The caller must balance
+ * the number of prepare and unprepare calls.
+ *
+ * Must not be called from within atomic context.
+ */
+void clk_unprepare(struct clk *clk);
+
+/**
* clk_enable - inform the system when the clock source should be running.
* @clk: clock source
*
@@ -292,6 +277,17 @@ static inline void clk_put(struct clk *clk) {}
static inline void devm_clk_put(struct device *dev, struct clk *clk) {}
+static inline int clk_prepare(struct clk *clk)
+{
+ might_sleep();
+ return 0;
+}
+
+static inline void clk_unprepare(struct clk *clk)
+{
+ might_sleep();
+}
+
static inline int clk_enable(struct clk *clk)
{
return 0;
--
1.7.11.7
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2 00/15] NFSd state containerization
On Thu, Nov 15, 2012 at 01:34:08PM -0500, Jeff Layton wrote: On Wed, 14 Nov 2012 17:00:36 -0500 J. Bruce Fields bfie...@fieldses.org wrote: On Wed, Nov 14, 2012 at 06:20:59PM +0300, Stanislav Kinsbursky wrote: This patch set is my first attempt to containerize NFSv4 state - i.e. make it works in networks namespace context. I admit, that some of this new code could be partially rewritten during future NFSd containerization. But the overall idea look more or less correct to me. So, the main things here are: 1) making nfs4_client network namespace aware. 2) Allocating all hashes (except file_hashtbl and reclaim_str_hashtbl) per network namespace context on NFSd start (not init) and destroying on NFSd state shutdown. 3) Allocating of reclaim_str_hashtbl on legacy tracker start and destroying on legacy tracker stop. 4) Moving of client_lru and close_lru lists to per-net data. 5) Making lundromat network namespace aware. These look OK and pass my tests. Jeff, do the revised recovery bits look OK? Have you done any testing? It'd be interesting, for example, to know if there are any pynfs that fail against the server in a non-init network namespace, but pass normally. --b. I looked over the patches and they look sane to me. I move that they go into your -next branch to soak for a bit. Stanislav, actually, I'm unclear, since you labeled these RFC: do you consider these patches ready? --b. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND] acpi: Fix logging when no pci_irq is allocated
On Wednesday, November 21, 2012 05:46:04 AM Joe Perches wrote:
On Wed, 2012-11-21 at 16:43 +0800, Daniel J Blueman wrote:
Previously a new line is implicitly added in the no GSI case:
[7.185182] pci 0001:00:12.0: can't derive routing for PCI INT A
[7.191352] pci 0001:00:12.0: PCI INT A: no GSI
[7.195956] - using ISA IRQ 10
The code thus prints a blank line where no legacy IRQ is available:
[1.650124] pci :00:14.0: can't derive routing for PCI INT A
[1.650126] pci :00:14.0: PCI INT A: no GSI
[1.650126]
[1.650180] pci :00:14.0: can't derive routing for PCI INT A
Fix this by making the newline explicit and removing the superfluous
one.
This breaks the logging code below it when there is an ISA irq.
The below works, but is a workaround for a defect in the printk
subsystem introduced by a logging change that will be fixed in
a near future release.
What exactly do you mean by near future?
Rafael
Signed-off-by: Joe Perches j...@perches.com
---
drivers/acpi/pci_irq.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/acpi/pci_irq.c b/drivers/acpi/pci_irq.c
index f288e00..68a921d 100644
--- a/drivers/acpi/pci_irq.c
+++ b/drivers/acpi/pci_irq.c
@@ -458,19 +458,19 @@ int acpi_pci_irq_enable(struct pci_dev *dev)
*/
if (gsi 0) {
u32 dev_gsi;
- dev_warn(dev-dev, PCI INT %c: no GSI, pin_name(pin));
/* Interrupt Line values above 0xF are forbidden */
if (dev-irq 0 (dev-irq = 0xF)
(acpi_isa_irq_to_gsi(dev-irq, dev_gsi) == 0)) {
- printk( - using ISA IRQ %d\n, dev-irq);
+ dev_warn(dev-dev, PCI INT %c: no GSI - using ISA IRQ
%d\n,
+ pin_name(pin), dev-irq);
acpi_register_gsi(dev-dev, dev_gsi,
ACPI_LEVEL_SENSITIVE,
ACPI_ACTIVE_LOW);
- return 0;
} else {
- printk(\n);
- return 0;
+ dev_warn(dev-dev, PCI INT %c: no GSI\n,
+ pin_name(pin));
}
+ return 0;
}
rc = acpi_register_gsi(dev-dev, gsi, triggering, polarity);
--
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Device tree node to major/minor?
Hi Grant, On Wed, Nov 21, 2012 at 7:47 AM, Grant Likely grant.lik...@secretlab.ca wrote: On Tue, 20 Nov 2012 15:48:24 -0800, Simon Glass s...@chromium.org wrote: Hi Grant, On Tue, Nov 20, 2012 at 2:32 PM, Grant Likely grant.lik...@secretlab.ca wrote: On Tue, Nov 20, 2012 at 10:23 PM, Simon Glass s...@chromium.org wrote: Hi, I hope this is a stupid question with an easy answer, but I cannot find it. I have a device tree node for an mmc block device and I want to use that block device from another driver. I have a phandle which lets me get the node of the mmc device, but I am not sure how to convert that into a block_device. In order to do so, I think I need a major/minor number. Of course the phandle might in fact point to a SCSI driver and I want that to work correctly also. I imagine I might be able to search through the wonders of sysfs in user space, but is there a better way? Do you /want/ to do it from userspace? What is your use case? Mounting the rootfs? The use case is storing some raw data on a block device from within a driver in the kernel. It is used to keep track of the verified boot state. Regardless, userspace can monitor the uevents when devices are added (that's what udev does) and watch for the full path of the node you want in the uevent attribute. Then you can look for the child device with the block major/minor numbers in it. So is there a way to do this entirely in the kernel ex post? It might need to happen during kernel boot, before user space. Yes, it is certainly doable within the kernel. First, you'll need to use a notifier to get called back whenever a new device is created. Then you'll need to look at the dev-of_node(-full_name) to see if it is the node you actually want. You might need/want to resolve it from an alias or something, but I presume you already have a way to find the device_node before seaching for a struct device. OK thank you. Was hoping to find a simple way to find a block device from a device tree node (yes I know the right one) but I suppose in general this is impossible, since nodes may create more than one device, and each has its own data structures leading to the block device. So it seems like a notifier is the best way. Thanks for looking at this Grant. Regards, Simon g. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND] acpi: Fix logging when no pci_irq is allocated
On Wed, 2012-11-21 at 21:50 +0100, Rafael J. Wysocki wrote: On Wednesday, November 21, 2012 05:46:04 AM Joe Perches wrote: On Wed, 2012-11-21 at 16:43 +0800, Daniel J Blueman wrote: Previously a new line is implicitly added in the no GSI case: [7.185182] pci 0001:00:12.0: can't derive routing for PCI INT A [7.191352] pci 0001:00:12.0: PCI INT A: no GSI [7.195956] - using ISA IRQ 10 The code thus prints a blank line where no legacy IRQ is available: [1.650124] pci :00:14.0: can't derive routing for PCI INT A [1.650126] pci :00:14.0: PCI INT A: no GSI [1.650126] [1.650180] pci :00:14.0: can't derive routing for PCI INT A Fix this by making the newline explicit and removing the superfluous one. This breaks the logging code below it when there is an ISA irq. The below works, but is a workaround for a defect in the printk subsystem introduced by a logging change that will be fixed in a near future release. What exactly do you mean by near future? I mean Jan Schönherr's patches that should fix this are likely to be picked up one day. https://lkml.org/lkml/2012/11/13/678 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] CLK: uninline clk_prepare() and clk_unprepare()
On Wed, Nov 21, 2012 at 12:43:24PM -0800, Mike Turquette wrote: Quoting Viresh Kumar (2012-11-20 02:13:55) On 20 November 2012 14:52, Dmitry Torokhov dmitry.torok...@gmail.com wrote: We'll need to invoke clk_unprepare() via a pointer in our devm_* conversion so let's uninline the pair. Sorry, but you aren't doing this :( This routine is already uninlined as it is in clk.c Instead you are just moving clk_prepare(), etc calls within #ifdef CONFIG_HAVE_CLK #else #endif I doubt why they have been added under #ifdef CONFIG_HAVE_CLK_PREPARE earlier. Can they exist without CONFIG_HAVE_CLK @Mike: ? HAVE_CLK logically wraps HAVE_CLK_PREPARE. There is no point in selecting HAVE_CLK_PREPARE without HAVE_CLK. Looking through the code I see that this used to be the case. Commit 93abe8e clk: add non CONFIG_HAVE_CLK routines moved the clk_(un)prepare declarations outside of #ifdef CONFIG_HAVE_CLK. That commit was authored by you. Can you elaborate on why that aspect of the patch was needed? BTW, it looks like the only place where we select HAVE_CLK_PREPARE is IMX platform and it also selects COMMON_CLK so I think HAVE_CLK_PREPARE can be removed now. Thanks. -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5] TPM: Issue TPM_STARTUP at driver load if the TPM has not been started
The TPM will respond to TPM_GET_CAP with TPM_ERR_INVALID_POSTINIT if
TPM_STARTUP has not been issued. Detect this and automatically
issue TPM_STARTUP.
This is for embedded applications where the kernel is the first thing
to touch the TPM.
Signed-off-by: Jason Gunthorpe jguntho...@obsidianresearch.com
Tested-by: Peter Huewe peter.hu...@infineon.com
Reviewed-by: Peter Huewe peter.hu...@infineon.com
---
drivers/char/tpm/tpm.c | 44
drivers/char/tpm/tpm.h |6 ++
2 files changed, 46 insertions(+), 4 deletions(-)
v5 changes:
- Use %zd for printing ssize_t
diff --git a/drivers/char/tpm/tpm.c b/drivers/char/tpm/tpm.c
index 93211df..433ad6b 100644
--- a/drivers/char/tpm/tpm.c
+++ b/drivers/char/tpm/tpm.c
@@ -468,7 +468,7 @@ static ssize_t transmit_cmd(struct tpm_chip *chip, struct
tpm_cmd_t *cmd,
return -EFAULT;
err = be32_to_cpu(cmd-header.out.return_code);
- if (err != 0)
+ if (err != 0 desc)
dev_err(chip-dev, A TPM error (%d) occurred %s\n, err, desc);
return err;
@@ -528,6 +528,25 @@ void tpm_gen_interrupt(struct tpm_chip *chip)
}
EXPORT_SYMBOL_GPL(tpm_gen_interrupt);
+#define TPM_ORD_STARTUP cpu_to_be32(153)
+#define TPM_ST_CLEAR cpu_to_be16(1)
+#define TPM_ST_STATE cpu_to_be16(2)
+#define TPM_ST_DEACTIVATED cpu_to_be16(3)
+static const struct tpm_input_header tpm_startup_header = {
+ .tag = TPM_TAG_RQU_COMMAND,
+ .length = cpu_to_be32(12),
+ .ordinal = TPM_ORD_STARTUP
+};
+
+static int tpm_startup(struct tpm_chip *chip, __be16 startup_type)
+{
+ struct tpm_cmd_t start_cmd;
+ start_cmd.header.in = tpm_startup_header;
+ start_cmd.params.startup_in.startup_type = startup_type;
+ return transmit_cmd(chip, start_cmd, TPM_INTERNAL_RESULT_SIZE,
+ attempting to start the TPM);
+}
+
int tpm_get_timeouts(struct tpm_chip *chip)
{
struct tpm_cmd_t tpm_cmd;
@@ -541,11 +560,28 @@ int tpm_get_timeouts(struct tpm_chip *chip)
tpm_cmd.params.getcap_in.cap = TPM_CAP_PROP;
tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(4);
tpm_cmd.params.getcap_in.subcap = TPM_CAP_PROP_TIS_TIMEOUT;
+ rc = transmit_cmd(chip, tpm_cmd, TPM_INTERNAL_RESULT_SIZE, NULL);
- rc = transmit_cmd(chip, tpm_cmd, TPM_INTERNAL_RESULT_SIZE,
- attempting to determine the timeouts);
- if (rc)
+ if (rc == TPM_ERR_INVALID_POSTINIT) {
+ /* The TPM is not started, we are the first to talk to it.
+ Execute a startup command. */
+ dev_info(chip-dev, Issuing TPM_STARTUP);
+ if (tpm_startup(chip, TPM_ST_CLEAR))
+ return rc;
+
+ tpm_cmd.header.in = tpm_getcap_header;
+ tpm_cmd.params.getcap_in.cap = TPM_CAP_PROP;
+ tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(4);
+ tpm_cmd.params.getcap_in.subcap = TPM_CAP_PROP_TIS_TIMEOUT;
+ rc = transmit_cmd(chip, tpm_cmd, TPM_INTERNAL_RESULT_SIZE,
+ NULL);
+ }
+ if (rc) {
+ dev_err(chip-dev,
+ A TPM error (%zd) occurred attempting to determine the
timeouts\n,
+ rc);
goto duration;
+ }
if (be32_to_cpu(tpm_cmd.header.out.return_code) != 0 ||
be32_to_cpu(tpm_cmd.header.out.length)
diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index 8ef7649..8971b12 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -47,6 +47,7 @@ enum tpm_addr {
#define TPM_WARN_DOING_SELFTEST 0x802
#define TPM_ERR_DEACTIVATED 0x6
#define TPM_ERR_DISABLED0x7
+#define TPM_ERR_INVALID_POSTINIT 38
#define TPM_HEADER_SIZE10
extern ssize_t tpm_show_pubek(struct device *, struct device_attribute *attr,
@@ -291,6 +292,10 @@ struct tpm_getrandom_in {
__be32 num_bytes;
}__attribute__((packed));
+struct tpm_startup_in {
+ __be16 startup_type;
+} __packed;
+
typedef union {
struct tpm_getcap_params_out getcap_out;
struct tpm_readpubek_params_out readpubek_out;
@@ -301,6 +306,7 @@ typedef union {
struct tpm_pcrextend_in pcrextend_in;
struct tpm_getrandom_in getrandom_in;
struct tpm_getrandom_out getrandom_out;
+ struct tpm_startup_in startup_in;
} tpm_cmd_params;
struct tpm_cmd_t {
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] TPM: Switch to __packed instead of __attribute__((packed))
This seems to be preferred these days.
Signed-off-by: Jason Gunthorpe jguntho...@obsidianresearch.com
---
drivers/char/tpm/tpm.h | 34 +-
1 files changed, 17 insertions(+), 17 deletions(-)
As discussed with Peter.
diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index c20fa8d..7d05ced 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -157,13 +157,13 @@ struct tpm_input_header {
__be16 tag;
__be32 length;
__be32 ordinal;
-}__attribute__((packed));
+} __packed;
struct tpm_output_header {
__be16 tag;
__be32 length;
__be32 return_code;
-}__attribute__((packed));
+} __packed;
struct stclear_flags_t {
__be16 tag;
@@ -172,14 +172,14 @@ structstclear_flags_t {
u8 physicalPresence;
u8 physicalPresenceLock;
u8 bGlobalLock;
-}__attribute__((packed));
+} __packed;
struct tpm_version_t {
u8 Major;
u8 Minor;
u8 revMajor;
u8 revMinor;
-}__attribute__((packed));
+} __packed;
struct tpm_version_1_2_t {
__be16 tag;
@@ -187,20 +187,20 @@ structtpm_version_1_2_t {
u8 Minor;
u8 revMajor;
u8 revMinor;
-}__attribute__((packed));
+} __packed;
struct timeout_t {
__be32 a;
__be32 b;
__be32 c;
__be32 d;
-}__attribute__((packed));
+} __packed;
struct duration_t {
__be32 tpm_short;
__be32 tpm_medium;
__be32 tpm_long;
-}__attribute__((packed));
+} __packed;
struct permanent_flags_t {
__be16 tag;
@@ -224,7 +224,7 @@ struct permanent_flags_t {
u8 tpmEstablished;
u8 maintenanceDone;
u8 disableFullDALogicInfo;
-}__attribute__((packed));
+} __packed;
typedef union {
struct permanent_flags_t perm_flags;
@@ -242,12 +242,12 @@ structtpm_getcap_params_in {
__be32 cap;
__be32 subcap_size;
__be32 subcap;
-}__attribute__((packed));
+} __packed;
struct tpm_getcap_params_out {
__be32 cap_size;
cap_t cap;
-}__attribute__((packed));
+} __packed;
struct tpm_readpubek_params_out {
u8 algorithm[4];
@@ -258,7 +258,7 @@ struct tpm_readpubek_params_out {
__be32 keysize;
u8 modulus[256];
u8 checksum[20];
-}__attribute__((packed));
+} __packed;
typedef union {
struct tpm_input_header in;
@@ -268,16 +268,16 @@ typedef union {
#define TPM_DIGEST_SIZE 20
struct tpm_pcrread_out {
u8 pcr_result[TPM_DIGEST_SIZE];
-}__attribute__((packed));
+} __packed;
struct tpm_pcrread_in {
__be32 pcr_idx;
-}__attribute__((packed));
+} __packed;
struct tpm_pcrextend_in {
__be32 pcr_idx;
u8 hash[TPM_DIGEST_SIZE];
-}__attribute__((packed));
+} __packed;
/* 128 bytes is an arbitrary cap. This could be as large as TPM_BUFSIZE - 18
* bytes, but 128 is still a relatively large number of random bytes and
@@ -288,11 +288,11 @@ struct tpm_pcrextend_in {
struct tpm_getrandom_out {
__be32 rng_data_len;
u8 rng_data[TPM_MAX_RNG_DATA];
-}__attribute__((packed));
+} __packed;
struct tpm_getrandom_in {
__be32 num_bytes;
-}__attribute__((packed));
+} __packed;
struct tpm_startup_in {
__be16 startup_type;
@@ -314,7 +314,7 @@ typedef union {
struct tpm_cmd_t {
tpm_cmd_header header;
tpm_cmd_params params;
-}__attribute__((packed));
+} __packed;
ssize_ttpm_getcap(struct device *, __be32, cap_t *, const char *);
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/12] Media Controller capture driver for DM365
Hi Prabhakar, On Fri, Nov 16, 2012 at 08:15:02PM +0530, Prabhakar Lad wrote: From: Manjunath Hadli manjunath.ha...@ti.com This patch set adds media controller based capture driver for DM365. This driver bases its design on Laurent Pinchart's Media Controller Design whose patches for Media Controller and subdev enhancements form the base. The driver also takes copious elements taken from Laurent Pinchart and others' OMAP ISP driver based on Media Controller. So thank you all the people who are responsible for the Media Controller and the OMAP ISP driver. Also, the core functionality of the driver comes from the arago vpfe capture driver of which the isif capture was based on V4L2, with other drivers like ipipe, ipipeif and Resizer. Changes for v2: 1: Migrated the driver for videobuf2 usage pointed Hans. 2: Changed the design as pointed by Laurent, Exposed one more subdevs ipipeif and split the resizer subdev into three subdevs. 3: Rearrganed the patch sequence and changed the commit messages. 4: Changed the file architecture as pointed by Laurent. Manjunath Hadli (12): davinci: vpfe: add v4l2 capture driver with media interface davinci: vpfe: add v4l2 video driver support davinci: vpfe: dm365: add IPIPEIF driver based on media framework davinci: vpfe: dm365: add ISIF driver based on media framework davinci: vpfe: dm365: add IPIPE support for media controller driver davinci: vpfe: dm365: add IPIPE hardware layer support davinci: vpfe: dm365: resizer driver based on media framework davinci: vpss: dm365: enable ISP registers davinci: vpss: dm365: set vpss clk ctrl davinci: vpss: dm365: add vpss helper functions to be used in the main driver for setting hardware parameters davinci: vpfe: dm365: add build infrastructure for capture driver davinci: vpfe: Add documentation Many thanks for taking the driver this far! However, I feel that there's still some work to do, especially in the user space API. Some things could be implemented using the generic API but currently use davinci-specific API; private IOCTL is being used where controls would do, and resizing is enabled or disable explicitly in ipipeif configuration. Also, there are things such as internal clock frequencies visible in the API. I can go to more details soon after taking a closer look at the patches. If you wish to get this to mainline kernel fast, a viable option IMO would be the staging tree. What do you think? Cc Hans and Laurent. -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] of: When constructing the bus id consider assigned-addresses as well
'assigned-addresses' is used for certain PCI device type nodes in
lieu of 'reg', since this is enforced by of/address.c, have
of_device_make_bus_id look there as well.
Signed-off-by: Jason Gunthorpe jguntho...@obsidianresearch.com
---
drivers/of/platform.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
of_can_translate_address and of_translate_address already support
using assigned-addresses.
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index b80891b..4f0f701 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -105,6 +105,8 @@ void of_device_make_bus_id(struct device *dev)
* For MMIO, get the physical address
*/
reg = of_get_property(node, reg, NULL);
+ if (!reg)
+ reg = of_get_property(node, assigned-addresses, NULL);
if (reg) {
if (of_can_translate_address(node)) {
addr = of_translate_address(node, reg);
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/12] VMCI: context implementation.
On Wed, 2012-11-21 at 12:31 -0800, George Zhang wrote:
VMCI Context code maintains state for vmci and allows the driver to
communicate
with multiple VMs
Just some trivial notes.
diff --git a/drivers/misc/vmw_vmci/vmci_context.c
b/drivers/misc/vmw_vmci/vmci_context.c
[]
It'd be nicer if you added this #define before any #include
#define pr_fmt(fmt) KBUILD_MODNAME : fmt
so that pr_level messages are prefixed.
(never mind, found a similar macro in patch 12/12)
+#include linux/vmw_vmci_defs.h
+#include linux/vmw_vmci_api.h
[]
+ context = kzalloc(sizeof(*context), GFP_KERNEL);
+ if (!context) {
+ pr_warn(Failed to allocate memory for VMCI context.\n);
OOM logging messages aren't necessary as alloc failures
are already logged with a stack trace.
That goes for the entire patch series.
+ /* Fire event to all subscribers. */
+ array_size = vmci_handle_arr_get_size(subscriber_array);
+ for (i = 0; i array_size; i++) {
+ int result;
+ struct vmci_event_msg *e_msg;
+ struct vmci_event_payld_ctx *ev_payload;
+ char buf[sizeof(*e_msg) + sizeof(*ev_payload)];
Maybe just use
struct vmci_event_msg e_msg;
struct vmci_event_payld_ctx ev_payload;
and change the addressing or use a cast as appropriate?
+ /* Allocate guest call entry and add it to the target VM's queue. */
+ dq_entry = kmalloc(sizeof(*dq_entry), GFP_KERNEL);
+ if (dq_entry == NULL) {
+ pr_warn(Failed to allocate memory for datagram.\n);
Another unnecessary OOM message.
You also have some inconsistency in whether or not your
logging messages use a terminating period. I suggest
you just delete all the periods.
s/\.\\n/\\n/g
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: vmscan: Check for fatal signals iff the process was throttled
On Wed, Nov 21, 2012 at 12:15:59PM -0800, Andrew Morton wrote:
On Wed, 21 Nov 2012 15:38:24 +
Mel Gorman mgor...@suse.de wrote:
commit 5515061d22f0 (mm: throttle direct reclaimers if PF_MEMALLOC reserves
are low and swap is backed by network storage) introduced a check for
fatal signals after a process gets throttled for network storage. The
intention was that if a process was throttled and got killed that it
should not trigger the OOM killer. As pointed out by Minchan Kim and
David Rientjes, this check is in the wrong place and too broad. If a
system is in am OOM situation and a process is exiting, it can loop in
__alloc_pages_slowpath() and calling direct reclaim in a loop. As the
fatal signal is pending it returns 1 as if it is making forward progress
and can effectively deadlock.
This patch moves the fatal_signal_pending() check after throttling to
throttle_direct_reclaim() where it belongs. If the process is killed
while throttled, it will return immediately without direct reclaim
except now it will have TIF_MEMDIE set and will use the PFMEMALLOC
reserves.
Minchan pointed out that it may be better to direct reclaim before returning
to avoid using the reserves because there may be pages that can easily
reclaim that would avoid using the reserves. However, we do no such
targetted
reclaim and there is no guarantee that suitable pages are available. As it
is expected that this throttling happens when swap-over-NFS is used there
is a possibility that the process will instead swap which may allocate
network buffers from the PFMEMALLOC reserves. Hence, in the swap-over-nfs
case where a process can be throtted and be killed it can use the reserves
to exit or it can potentially use reserves to swap a few pages and then
exit. This patch takes the option of using the reserves if necessary to
allow the process exit quickly.
If this patch passes review it should be considered a -stable candidate
for 3.6.
...
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2207,9 +2207,12 @@ static bool pfmemalloc_watermark_ok(pg_data_t *pgdat)
* Throttle direct reclaimers if backing storage is backed by the network
* and the PFMEMALLOC reserve for the preferred node is getting dangerously
* depleted. kswapd will continue to make progress and wake the processes
- * when the low watermark is reached
+ * when the low watermark is reached.
+ *
+ * Returns true if a fatal signal was delivered during throttling. If this
s/delivered/received/imo
Ok.
+ * happens, the page allocator should not consider triggering the OOM
killer.
*/
-static void throttle_direct_reclaim(gfp_t gfp_mask, struct zonelist
*zonelist,
+static bool throttle_direct_reclaim(gfp_t gfp_mask, struct zonelist
*zonelist,
nodemask_t *nodemask)
{
struct zone *zone;
@@ -2224,13 +2227,20 @@ static void throttle_direct_reclaim(gfp_t gfp_mask,
struct zonelist *zonelist,
* processes to block on log_wait_commit().
*/
if (current-flags PF_KTHREAD)
- return;
+ goto out;
hm, well, back in the old days some kernel threads were killable via
signals. They had to opt-in to it by diddling their signal masks and a
few other things. Too lazy to check if there are still any such sites.
That check is against throttling rather than signal handling though. It
could have been just left as return.
+ /*
+* If a fatal signal is pending, this process should not throttle.
+* It should return quickly so it can exit and free its memory
+*/
+ if (fatal_signal_pending(current))
+ goto out;
theresabug. It should return true here.
The intention here is that a process would
1. allocate, fail, enter direct reclaim
2. no signal pending, gets throttled because of low pfmemalloc reserves
3. a user kills -9 the throttled process. returns true and goes back
to the page allocator
4. If that allocation fails again, it re-enters direct reclaim and tries
to throttle. This time the fatal signal is pending but we know
we must have already failed to make the allocation so this time false
is rurned by throttle_direct_reclaim and it tries direct reclaim.
5. direct reclaim frees something -- probably clean file-backed pages
if the last allocation attempt had failed.
so the fatal signal check should only prevent entering direct reclaim
once. Maybe the comment sucks
/*
* If a fatal signal is pending, this process should not throttle.
* It should return quickly so it can exit and free its memory. Note
* that returning false here allows a process to enter direct reclaim.
* Otherwise there is a risk that the process loops in the page
* allocator, checking signals and never making forward progress
*/
?
/* Check if the pfmemalloc reserves are ok */
first_zones_zonelist(zonelist, high_zoneidx, NULL, zone);
Re: [Pv-drivers] [PATCH 01/12] VMCI: context implementation.
Hi Joe, Just some trivial notes. Thanks for taking a look! + pr_warn(Failed to allocate memory for VMCI context.\n); OOM logging messages aren't necessary as alloc failures are already logged with a stack trace. Noted, we'll remove all such occurrences. Maybe just use struct vmci_event_msg e_msg; struct vmci_event_payld_ctx ev_payload; and change the addressing or use a cast as appropriate? It does seem inelegant, we'll take a look. You also have some inconsistency in whether or not your logging messages use a terminating period. I suggest you just delete all the periods. s/\.\\n/\\n/g Gah, that's ugly. We'll remove all of them as you suggest. Thanks! - Andy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] ext3: Warn if mounting rw on a disk requiring stable page writes
On Wed, Nov 21, 2012 at 03:15:43AM +0100, Jan Kara wrote:
On Tue 20-11-12 18:00:56, Darrick J. Wong wrote:
ext3 doesn't properly isolate pages from changes during writeback. Since
the
recommended fix is to use ext4, for now we'll just print a warning if the
user
tries to mount in write mode.
Signed-off-by: Darrick J. Wong darrick.w...@oracle.com
---
fs/ext3/super.c |8
1 file changed, 8 insertions(+)
diff --git a/fs/ext3/super.c b/fs/ext3/super.c
index 5366393..5b3725d 100644
--- a/fs/ext3/super.c
+++ b/fs/ext3/super.c
@@ -1325,6 +1325,14 @@ static int ext3_setup_super(struct super_block *sb,
struct ext3_super_block *es,
forcing read-only mode);
res = MS_RDONLY;
}
+ if (!read_only
+ queue_requires_stable_pages(bdev_get_queue(sb-s_bdev))) {
+ ext3_msg(sb, KERN_ERR,
+ error: ext3 cannot safely write data to a disk
+ requiring stable pages writes; forcing read-only
+ mode. Upgrading to ext4 is recommended.);
+ res = MS_RDONLY;
+ }
if (read_only)
return res;
if (!(sbi-s_mount_state EXT3_VALID_FS))
Why this? ext3 should be fixed by your change to
filemap_page_mkwrite()... Or does testing show otherwise?
Yes, it's still broken even with this new set of changes. Now that I think
about it a little more, I recall that writeback mode was actually fine, so this
is a little harsh.
Hm... looking at the ordered code a little more, it looks like
ext3_ordered_write_end is calling journal_dirty_data_fn, which (I guess?) tries
to write mapped buffers back through the journal? Taking it out seems to fix
ordered mode, though I have a suspicion that it might very well break ordered
mode too.
--D
Honza
--
Jan Kara j...@suse.cz
SUSE Labs, CR
--
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] TPM: Work around buggy TPMs that block during continue self test
We've been testing an alternative TPM for our embedded products and
found random kernel boot failures due to time outs after the continue
self test command.
This was happening randomly, and has been *very* hard to track down, but it
looks like with this chip there is some kind of race with the tpm_tis_status()
check of TPM_STS_COMMAND_READY. If things get there 'too fast' then
it sees the chip is ready, or tpm_tis_ready() works. Otherwise it takes
somewhere over 400ms before the chip will return TPM_STS_COMMAND_READY.
Adding some delay after tpm_continue_selftest() makes things reliably
hit the failure path, otherwise it is a crapshot.
The spec says it should be returning TPM_WARN_DOING_SELFTEST, not holding
off on ready..
Boot log during this event looks like this:
tpm_tis 7003.tpm_tis: 1.2 TPM (device-id 0x3204, rev-id 64)
tpm_tis 7003.tpm_tis: Issuing TPM_STARTUP
tpm_tis 7003.tpm_tis: tpm_transmit: tpm_send: error -62
tpm_tis 7003.tpm_tis: [Hardware Error]: TPM command timed out during
continue self test
tpm_tis 7003.tpm_tis: tpm_transmit: tpm_send: error -62
tpm_tis 7003.tpm_tis: [Hardware Error]: TPM command timed out during
continue self test
tpm_tis 7003.tpm_tis: tpm_transmit: tpm_send: error -62
tpm_tis 7003.tpm_tis: [Hardware Error]: TPM command timed out during
continue self test
tpm_tis 7003.tpm_tis: tpm_transmit: tpm_send: error -62
tpm_tis 7003.tpm_tis: [Hardware Error]: TPM command timed out during
continue self test
The other TPM vendor we use doesn't show this wonky behaviour:
tpm_tis 7003.tpm_tis: 1.2 TPM (device-id 0xFE, rev-id 70)
Signed-off-by: Jason Gunthorpe jguntho...@obsidianresearch.com
---
drivers/char/tpm/tpm.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/drivers/char/tpm/tpm.c b/drivers/char/tpm/tpm.c
index 454e032..61d62c2 100644
--- a/drivers/char/tpm/tpm.c
+++ b/drivers/char/tpm/tpm.c
@@ -857,7 +857,7 @@ int tpm_do_selftest(struct tpm_chip *chip)
{
int rc;
unsigned int loops;
- unsigned int delay_msec = 1000;
+ unsigned int delay_msec = 100;
unsigned long duration;
struct tpm_cmd_t cmd;
@@ -878,6 +878,14 @@ int tpm_do_selftest(struct tpm_chip *chip)
cmd.header.in = pcrread_header;
cmd.params.pcrread_in.pcr_idx = cpu_to_be32(0);
rc = tpm_transmit(chip, (u8 *) cmd, READ_PCR_RESULT_SIZE);
+ /* Some buggy TPMs will not respond to tpm_tis_ready() for
+* around 300ms while the self test is ongoing, keep trying
+* until the self test duration expires. */
+ if (rc == -ETIME) {
+ dev_info(chip-dev, HW_ERR TPM command timed out
during continue self test);
+ msleep(delay_msec);
+ continue;
+ }
if (rc TPM_HEADER_SIZE)
return -EFAULT;
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] tty: Add driver unthrottle in ioctl(...,TCFLSH,..).
Revert 'tty: fix IRQ45: nobody cared'
This revert commit 7b292b4bf9a9d6098440d85616d6ca4c608b8304
Function reset_buffer_flags() also invoked during the
ioctl(...,TCFLSH,..). At the time of request we can have full buffers
and throttled driver too. If we don't unthrottle driver, we can get
forever throttled driver, because after request, we will have
empty buffers and throttled driver and there is no place to unthrottle driver.
It simple reproduce with pty pair then one side sleep on tty-write_wait,
and other side do ioctl(...,TCFLSH,..). Then there is no place to do writers
wake up.
About 'tty: fix IRQ45: nobody cared':
We don't call tty_unthrottle() if release last filp - ('tty-count == 0')
In other case it must be safely. Maybe we have bug in other place.
Signed-off-by: Ilya Zykov i...@ilyx.ru
---
diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
index 26f0d0e..a783d0e 100644
--- a/drivers/tty/n_tty.c
+++ b/drivers/tty/n_tty.c
@@ -184,6 +184,7 @@ static void reset_buffer_flags(struct tty_struct *tty)
tty-canon_head = tty-canon_data = tty-erasing = 0;
memset(tty-read_flags, 0, sizeof tty-read_flags);
n_tty_set_room(tty);
+ check_unthrottle(tty);
}
/**
@@ -1585,7 +1586,6 @@ static int n_tty_open(struct tty_struct *tty)
return -ENOMEM;
}
reset_buffer_flags(tty);
- tty_unthrottle(tty);
tty-column = 0;
n_tty_set_termios(tty, NULL);
tty-minimum_to_wake = 1;
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND] acpi: Fix logging when no pci_irq is allocated
On Wednesday, November 21, 2012 12:53:55 PM Joe Perches wrote: On Wed, 2012-11-21 at 21:50 +0100, Rafael J. Wysocki wrote: On Wednesday, November 21, 2012 05:46:04 AM Joe Perches wrote: On Wed, 2012-11-21 at 16:43 +0800, Daniel J Blueman wrote: Previously a new line is implicitly added in the no GSI case: [7.185182] pci 0001:00:12.0: can't derive routing for PCI INT A [7.191352] pci 0001:00:12.0: PCI INT A: no GSI [7.195956] - using ISA IRQ 10 The code thus prints a blank line where no legacy IRQ is available: [1.650124] pci :00:14.0: can't derive routing for PCI INT A [1.650126] pci :00:14.0: PCI INT A: no GSI [1.650126] [1.650180] pci :00:14.0: can't derive routing for PCI INT A Fix this by making the newline explicit and removing the superfluous one. This breaks the logging code below it when there is an ISA irq. The below works, but is a workaround for a defect in the printk subsystem introduced by a logging change that will be fixed in a near future release. What exactly do you mean by near future? I mean Jan Schönherr's patches that should fix this are likely to be picked up one day. https://lkml.org/lkml/2012/11/13/678 Till then, we need the patch you sent, right? And it won't hurt to apply it anyway? Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
