search for: queuepair

We added this for a special case that doesn't exist on Linux. Remove the non-blocking/pinned queuepair code and simplify the driver in preparation for adding virtual IOMMU support. Acked-by: Aditya Sarwade <asarwade at vmware.com> Signed-off-by: Andy King <acking at vmware.com> --- drivers/misc/vmw_vmci/vmci_queue_pair.c | 149 +++++-------------------------- drivers/misc/vmw_vmci/vmc...

This patchset adds support for virtual IOMMU to the VMCI module. We switch to DMA consistent mappings for queuepair and doorbell pages that are passed to the device, which allows the module to work in the presence of vIOMMU/VT-d. Andy King (2): VMCI: Remove non-blocking/pinned queuepair support VMCI: Add support for virtual IOMMU drivers/misc/vmw_vmci/vmci_driver.c | 2 +- drivers/misc/vmw_vmci/vmc...

This patchset adds support for virtual IOMMU to the VMCI module. We switch to DMA consistent mappings for queuepair and doorbell pages that are passed to the device, which allows the module to work in the presence of vIOMMU/VT-d. Andy King (2): VMCI: Remove non-blocking/pinned queuepair support VMCI: Add support for virtual IOMMU drivers/misc/vmw_vmci/vmci_driver.c | 2 +- drivers/misc/vmw_vmci/vmc...

...Q, + struct vmci_queue *consumeQ) +{ + int result; + + if (!produceQ->qHeader || !consumeQ->qHeader) { + struct page *headers[2]; + + if (produceQ->qHeader != consumeQ->qHeader) + return VMCI_ERROR_QUEUEPAIR_MISMATCH; + + if (produceQ->kernelIf->headerPage == NULL || + *produceQ->kernelIf->headerPage == NULL) + return VMCI_ERROR_UNAVAILABLE; + + ASSERT(*produceQ->kernelIf->headerPage && +...

...Q, + struct vmci_queue *consumeQ) +{ + int result; + + if (!produceQ->qHeader || !consumeQ->qHeader) { + struct page *headers[2]; + + if (produceQ->qHeader != consumeQ->qHeader) + return VMCI_ERROR_QUEUEPAIR_MISMATCH; + + if (produceQ->kernelIf->headerPage == NULL || + *produceQ->kernelIf->headerPage == NULL) + return VMCI_ERROR_UNAVAILABLE; + + ASSERT(*produceQ->kernelIf->headerPage && +...

...ATTACH to client > > What's the reason for a 4 stage setup? Most transports > make do with 3. I'm guessing that's also based on the original vSockets/VMCI implementation, where the NEGOTIATE/OFFER stages are used to negotiate the underlying transport buffer size (in VMCI, the queuepair that underlies a STREAM socket). The virtio transport can probably use 3. Thanks! - Andy

...ATTACH to client > > What's the reason for a 4 stage setup? Most transports > make do with 3. I'm guessing that's also based on the original vSockets/VMCI implementation, where the NEGOTIATE/OFFER stages are used to negotiate the underlying transport buffer size (in VMCI, the queuepair that underlies a STREAM socket). The virtio transport can probably use 3. Thanks! - Andy

This patchset adds support for virtual IOMMU to the VMCI module. We switch to DMA consistent mappings for queuepair and doorbell pages that are passed to the device, which allows the module to work in the presence of vIOMMU/VT-d. Andy King (2): VMCI: Remove non-blocking/pinned queuepair support VMCI: Add support for virtual IOMMU drivers/misc/vmw_vmci/vmci_driver.c | 2 +- drivers/misc/vmw_vmci/vmc...

This patchset adds support for virtual IOMMU to the VMCI module. We switch to DMA consistent mappings for queuepair and doorbell pages that are passed to the device, which allows the module to work in the presence of vIOMMU/VT-d. Andy King (2): VMCI: Remove non-blocking/pinned queuepair support VMCI: Add support for virtual IOMMU drivers/misc/vmw_vmci/vmci_driver.c | 2 +- drivers/misc/vmw_vmci/vmc...

...e has an upper limit of 128MB on the amount of + * memory that can be used for queue pairs. + */ +#define VMCI_MAX_GUEST_QP_MEMORY (128 * 1024 * 1024) + +/* + * Queues with pre-mapped data pages must be small, so that we don't pin + * too much kernel memory (especially on vmkernel). We limit a queuepair to + * 32 KB, or 16 KB per queue for symmetrical pairs. + */ +#define VMCI_MAX_PINNED_QP_MEMORY (32 * 1024) + +/* + * We have a fixed set of resource IDs available in the VMX. + * This allows us to have a very simple implementation since we statically + * know how many will create datagram handles....

...e has an upper limit of 128MB on the amount of + * memory that can be used for queue pairs. + */ +#define VMCI_MAX_GUEST_QP_MEMORY (128 * 1024 * 1024) + +/* + * Queues with pre-mapped data pages must be small, so that we don't pin + * too much kernel memory (especially on vmkernel). We limit a queuepair to + * 32 KB, or 16 KB per queue for symmetrical pairs. + */ +#define VMCI_MAX_PINNED_QP_MEMORY (32 * 1024) + +/* + * We have a fixed set of resource IDs available in the VMX. + * This allows us to have a very simple implementation since we statically + * know how many will create datagram handles....

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.

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 patch adds support for virtual IOMMU to the vmci module. We switch to DMA consistent mappings for guest queuepair and doorbell pages that are passed to the device. We still allocate each page individually, since there's no guarantee that we'll get a contiguous block of physical for an entire queuepair (especially since we allow up to 128 MiB!). Also made the split between guest and host in the kernel...

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.

...ct vmci_delayed_work_info { + struct work_struct work; + VMCIWorkFn *workFn; + void *data; +}; + +/* + * VMCI driver initialization. This block can also be used to + * pass initial group membership etc. + */ +struct vmci_init_blk { + u32 cid; + u32 flags; +}; + +/* VMCIQueuePairAllocInfo_VMToVM */ +struct vmci_qp_alloc_info_vmvm { + struct vmci_handle handle; + u32 peer; + u32 flags; + uint64_t produceSize; + uint64_t consumeSize; + uint64_t producePageFile; /* User VA. */ + uint64_t consumePageFile; /* User VA. */ +...

...ct vmci_delayed_work_info { + struct work_struct work; + VMCIWorkFn *workFn; + void *data; +}; + +/* + * VMCI driver initialization. This block can also be used to + * pass initial group membership etc. + */ +struct vmci_init_blk { + u32 cid; + u32 flags; +}; + +/* VMCIQueuePairAllocInfo_VMToVM */ +struct vmci_qp_alloc_info_vmvm { + struct vmci_handle handle; + u32 peer; + u32 flags; + uint64_t produceSize; + uint64_t consumeSize; + uint64_t producePageFile; /* User VA. */ + uint64_t consumePageFile; /* User VA. */ +...