search for: vmci_host_active_users

...uldn't vhost behave similar, so that any module that registers a h2g transport only does so if it is in active use? > --- a/drivers/misc/vmw_vmci/vmci_host.c > +++ b/drivers/misc/vmw_vmci/vmci_host.c > @@ -108,6 +108,11 @@ bool vmci_host_code_active(void) > atomic_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, &gt...

...uldn't vhost behave similar, so that any module that registers a h2g transport only does so if it is in active use? > --- a/drivers/misc/vmw_vmci/vmci_host.c > +++ b/drivers/misc/vmw_vmci/vmci_host.c > @@ -108,6 +108,11 @@ bool vmci_host_code_active(void) > atomic_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, &gt...

...en there's at least one active user. Ok, sounds good then. > > > > > > --- a/drivers/misc/vmw_vmci/vmci_host.c > > > +++ b/drivers/misc/vmw_vmci/vmci_host.c > > > @@ -108,6 +108,11 @@ bool vmci_host_code_active(void) > > > atomic_read(&vmci_host_active_users) > 0); > > > } > > > > > > +int vmci_host_users(void) > > > +{ > > > + return atomic_read(&vmci_host_active_users); > > > +} > > > + > > > /* > > > * Called on open of /dev/vmci. > > > */ > &gt...

...rst hypervisor open /dev/vhost-vsock, so in theory, when there's at least one active user. > > > --- a/drivers/misc/vmw_vmci/vmci_host.c > > +++ b/drivers/misc/vmw_vmci/vmci_host.c > > @@ -108,6 +108,11 @@ bool vmci_host_code_active(void) > > atomic_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_ini...

...; err_free_irq: diff --git a/drivers/misc/vmw_vmci/vmci_host.c b/drivers/misc/vmw_vmci/vmci_host.c index 833e2bd248a5..ff3c396146ff 100644 --- a/drivers/misc/vmw_vmci/vmci_host.c +++ b/drivers/misc/vmw_vmci/vmci_host.c @@ -108,6 +108,11 @@ bool vmci_host_code_active(void) atomic_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(&a...

...e h2g feature is always set. > This prevents to load other h2g transports while we are in a > VMware guest. In the vhost_vsock.ko case we only register the h2g transport when userspace has loaded the module (by opening /dev/vhost-vsock). VMCI has something kind of similar: /dev/vmci and the vmci_host_active_users counter. Maybe we can use this instead of introducing the transport_hg concept? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: <http://lists.linuxfoundation.org/pipermail/...

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:

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

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

Hi all, 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

Hi all, 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