search for: vmci_call_vsock_callback

...ci. > > > */ > > > @@ -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. > > Yes, make sense. can I use the 'vmci_host_active_users' or...

...ve_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:

...ve_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:

...(!vmci_vsock_transport_cb) + goto out; + + if (vmci_guest_code_active()) + vmci_vsock_transport_cb(false); + + if (vmci_host_users() > 0) + vmci_vsock_transport_cb(true); + +out: + mutex_unlock(&vmci_vsock_mutex); + return err; +} +EXPORT_SYMBOL_GPL(vmci_register_vsock_callback); + +void vmci_call_vsock_callback(bool is_host) +{ + mutex_lock(&vmci_vsock_mutex); + + if (vmci_vsock_transport_cb) + vmci_vsock_transport_cb(is_host); + + mutex_unlock(&vmci_vsock_mutex); +} + static int __init vmci_drv_init(void) { int vmci_err; diff --git a/drivers/misc/vmw_vmci/vmci_driver.h b/drivers/misc/vmw_vmc...

...> * 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. Yes, make sense. can I use the 'vmci_host_active_users' or is better to add a new 'vmci_h...

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

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

Most of the patches are reviewed by Dexuan, Stefan, and Jorgen. The following patches need reviews: - [11/15] vsock: add multi-transports support - [12/15] vsock/vmci: register vmci_transport only when VMCI guest/host are active - [15/15] vhost/vsock: refuse CID assigned to the guest->host transport RFC: https://patchwork.ozlabs.org/cover/1168442/ v1: