search for: vmciobj_context

...en the process + * exits. + */ +static int drv_driver_close(struct inode *inode, + struct file *filp) +{ + struct vmci_linux *vmciLinux; + + vmciLinux = (struct vmci_linux *)filp->private_data; + ASSERT(vmciLinux); + + if (vmciLinux->ctType == VMCIOBJ_CONTEXT) { + ASSERT(vmciLinux->context); + + vmci_ctx_release_ctx(vmciLinux->context); + vmciLinux->context = NULL; + + /* + * The number of active contexts is used to track whether any + * VMX'en are using t...

...en the process + * exits. + */ +static int drv_driver_close(struct inode *inode, + struct file *filp) +{ + struct vmci_linux *vmciLinux; + + vmciLinux = (struct vmci_linux *)filp->private_data; + ASSERT(vmciLinux); + + if (vmciLinux->ctType == VMCIOBJ_CONTEXT) { + ASSERT(vmciLinux->context); + + vmci_ctx_release_ctx(vmciLinux->context); + vmciLinux->context = NULL; + + /* + * The number of active contexts is used to track whether any + * VMX'en are using t...

...nt vmci_host_users(void) > +{ > + return atomic_read(&vmci_host_active_users); > +} > + > /* > * Called on open of /dev/vmci. > */ > @@ -338,6 +343,8 @@ static int vmci_host_do_init_context(struct > vmci_host_dev *vmci_host_dev, > vmci_host_dev->ct_type = VMCIOBJ_CONTEXT; > atomic_inc(&vmci_host_active_users); > > + vmci_call_vsock_callback(true); > + Since we don't unregister the transport if user count drops back to 0, we could just call this the first time, a VM is powered on after the module is loaded. > retval = 0; > > out...

...nt vmci_host_users(void) > +{ > + return atomic_read(&vmci_host_active_users); > +} > + > /* > * Called on open of /dev/vmci. > */ > @@ -338,6 +343,8 @@ static int vmci_host_do_init_context(struct > vmci_host_dev *vmci_host_dev, > vmci_host_dev->ct_type = VMCIOBJ_CONTEXT; > atomic_inc(&vmci_host_active_users); > > + vmci_call_vsock_callback(true); > + Since we don't unregister the transport if user count drops back to 0, we could just call this the first time, a VM is powered on after the module is loaded. > retval = 0; > > out...

..._users); > > > +} > > > + > > > /* > > > * Called on open of /dev/vmci. > > > */ > > > @@ -338,6 +343,8 @@ static int vmci_host_do_init_context(struct > > > vmci_host_dev *vmci_host_dev, > > > vmci_host_dev->ct_type = VMCIOBJ_CONTEXT; > > > atomic_inc(&vmci_host_active_users); > > > > > > + vmci_call_vsock_callback(true); > > > + > > > > Since we don't unregister the transport if user count drops back to 0, we > could > > just call this the first time, a VM is p...

...return atomic_read(&vmci_host_active_users); > > +} > > + > > /* > > * Called on open of /dev/vmci. > > */ > > @@ -338,6 +343,8 @@ static int vmci_host_do_init_context(struct > > vmci_host_dev *vmci_host_dev, > > vmci_host_dev->ct_type = VMCIOBJ_CONTEXT; > > atomic_inc(&vmci_host_active_users); > > > > + vmci_call_vsock_callback(true); > > + > > Since we don't unregister the transport if user count drops back to 0, we could > just call this the first time, a VM is powered on after the module is loaded....

...read(&vmci_host_active_users) > 0); } +int vmci_host_users(void) +{ + return atomic_read(&vmci_host_active_users); +} + /* * Called on open of /dev/vmci. */ @@ -338,6 +343,8 @@ static int vmci_host_do_init_context(struct vmci_host_dev *vmci_host_dev, vmci_host_dev->ct_type = VMCIOBJ_CONTEXT; atomic_inc(&vmci_host_active_users); + vmci_call_vsock_callback(true); + retval = 0; out: diff --git a/include/linux/vmw_vmci_api.h b/include/linux/vmw_vmci_api.h index acd9fafe4fc6..f28907345c80 100644 --- a/include/linux/vmw_vmci_api.h +++ b/include/linux/vmw_vmci_api.h @@ -19,6 +19...

* * * 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

* * * 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

* * * This series of VMCI linux upstreaming patches include latest udpate from VMware to address Greg's and all other's code review comments. Summary of changes: - Rebase our linux kernel tree from v3.5 to v3.7. - Fix all checkpatch warnings and errors. Fix some checkpatch with -strict errors. This addresses Greg's comment: On 15 Nov 2012

* * * This series of VMCI linux upstreaming patches include latest udpate from VMware to address Greg's and all other's code review comments. Summary of changes: - Rebase our linux kernel tree from v3.5 to v3.7. - Fix all checkpatch warnings and errors. Fix some checkpatch with -strict errors. This addresses Greg's comment: On 15 Nov 2012

Second revision of the VMware VMCI RFC patchset. It incorperates fixes for all the feedback about the comment blocks and style and now passes checkpatch with 0 errors and 0 warnings. Thanks to all who have reviewed the code thus far. * * * 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

Second revision of the VMware VMCI RFC patchset. It incorperates fixes for all the feedback about the comment blocks and style and now passes checkpatch with 0 errors and 0 warnings. Thanks to all who have reviewed the code thus far. * * * 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

* * * This series of VMCI linux upstreaming patches include latest udpate from VMware. -split guest, host and core driver code into different files -use EXPORT_SYMBOLS_GPL -remove vmci_device_get and vmci_device_release APIs -simplify the event deliver mechanism -driver ioctl code cleanup -sparse clean * * * In an effort to improve the out-of-the-box experience with

* * * This series of VMCI linux upstreaming patches include latest udpate from VMware. -split guest, host and core driver code into different files -use EXPORT_SYMBOLS_GPL -remove vmci_device_get and vmci_device_release APIs -simplify the event deliver mechanism -driver ioctl code cleanup -sparse clean * * * In an effort to improve the out-of-the-box experience with

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.

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.

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.

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.

This series adds the multi-transports support to vsock, following this proposal: https://www.spinics.net/lists/netdev/msg575792.html With the multi-transports support, we can use VSOCK with nested VMs (using also different hypervisors) loading both guest->host and host->guest transports at the same time. Before this series, vmci-transport supported this behavior but only using VMware