similar to: [PATCH] VMCI: Fix two UVA mapping bugs

Ensure that the size filled in by userland in the datagram header matches the size of the buffer passed down in the IOCTL. Note that we account for the size of the header itself in the check. Acked-by: Jorgen Hansen <jhansen at vmware.com> Acked-by: Aditya Sarwade <asarwade at vmware.com> Signed-off-by: Andy King <acking at vmware.com> Reported-by: David Ramos <daramos at

Ensure that the size filled in by userland in the datagram header matches the size of the buffer passed down in the IOCTL. Note that we account for the size of the header itself in the check. Acked-by: Jorgen Hansen <jhansen at vmware.com> Acked-by: Aditya Sarwade <asarwade at vmware.com> Signed-off-by: Andy King <acking at vmware.com> Reported-by: David Ramos <daramos at

To allow other transports to be loaded with vmci_transport, we register the vmci_transport as G2H or H2G only when a VMCI guest or host is active. To do that, this patch adds a callback registered in the vmci driver that will be called when a new host or guest become active. This callback will register the vmci_transport in the VSOCK core. If the transport is already registered, we ignore the

Signed-off-by: George Zhang <georgezhang at vmware.com> --- drivers/misc/vmw_vmci/vmci_context.c | 1245 ++++++++++++++++++++++++++++++++++ drivers/misc/vmw_vmci/vmci_context.h | 174 +++++ 2 files changed, 1419 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

Signed-off-by: George Zhang <georgezhang at vmware.com> --- drivers/misc/vmw_vmci/vmci_context.c | 1245 ++++++++++++++++++++++++++++++++++ drivers/misc/vmw_vmci/vmci_context.h | 174 +++++ 2 files changed, 1419 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

This change consists of two changes: 1) If vmci_doorbell_create is called when neither guest nor host personality as been initialized, vmci_get_context_id will return VMCI_INVALID_ID. In that case, we should fail the create call. 2) In doorbell destroy, we assume that vmci_guest_code_active() has the same return value on create and destroy. That may not be the case, so we may end

This change consists of two changes: 1) If vmci_doorbell_create is called when neither guest nor host personality as been initialized, vmci_get_context_id will return VMCI_INVALID_ID. In that case, we should fail the create call. 2) In doorbell destroy, we assume that vmci_guest_code_active() has the same return value on create and destroy. That may not be the case, so we may end

From: Jorgen Hansen <jhansen at vmware.com> The current maximum size of a queue in a queue pair is 128 MB. If we increase that in the future, the queue pair allocation routines may run into overflow issues. This change adds additional checks to guard against this. Acked-by: Andy King <acking at vmware.com> Reported-by: Dan Carpenter <dan.carpenter at oracle.com> Signed-off-by:

From: Jorgen Hansen <jhansen at vmware.com> The current maximum size of a queue in a queue pair is 128 MB. If we increase that in the future, the queue pair allocation routines may run into overflow issues. This change adds additional checks to guard against this. Acked-by: Andy King <acking at vmware.com> Reported-by: Dan Carpenter <dan.carpenter at oracle.com> Signed-off-by:

On Fri, Sep 21, 2018 at 12:31:05AM -0700, Jorgen Hansen wrote: > When adding a VMCI resource, the check for an existing entry > would ignore that the new entry could be a wildcard. This could > result in multiple resource entries that would match a given > handle. One disastrous outcome of this is that the > refcounting used to ensure that delayed callbacks for VMCI > datagrams

On Fri, Sep 21, 2018 at 12:31:05AM -0700, Jorgen Hansen wrote: > When adding a VMCI resource, the check for an existing entry > would ignore that the new entry could be a wildcard. This could > result in multiple resource entries that would match a given > handle. One disastrous outcome of this is that the > refcounting used to ensure that delayed callbacks for VMCI > datagrams

On 3 Oct 2018, at 00:35, Greg KH <gregkh at linuxfoundation.org<mailto:gregkh at linuxfoundation.org>> wrote: On Fri, Sep 21, 2018 at 12:31:05AM -0700, Jorgen Hansen wrote: When adding a VMCI resource, the check for an existing entry would ignore that the new entry could be a wildcard. This could result in multiple resource entries that would match a given handle. One disastrous

The VMCI handle array has an integer overflow in vmci_handle_arr_append_entry when it tries to expand the array. This can be triggered from a guest, since the doorbell link hypercall doesn't impose a limit on the number of doorbell handles that a VM can create in the hypervisor, and these handles are stored in a handle array. In this change, we introduce a mandatory max capacity for handle

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

This change restricts the reading and setting of the head and tail pointers on 32bit X86 to 32bit for both correctness and performance reasons. On uniprocessor X86_32, the atomic64_read may be implemented as a non-locked cmpxchg8b. This may result in updates to the pointers done by the VMCI device being overwritten. On MP systems, there is no such correctness issue, but using 32bit atomics avoids

This change restricts the reading and setting of the head and tail pointers on 32bit X86 to 32bit for both correctness and performance reasons. On uniprocessor X86_32, the atomic64_read may be implemented as a non-locked cmpxchg8b. This may result in updates to the pointers done by the VMCI device being overwritten. On MP systems, there is no such correctness issue, but using 32bit atomics avoids

Signed-off-by: George Zhang <georgezhang at vmware.com> --- drivers/misc/vmw_vmci/vmci_driver.c | 2293 +++++++++++++++++++++++++++++++++++ drivers/misc/vmw_vmci/vmci_driver.h | 48 + 2 files changed, 2341 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

Signed-off-by: George Zhang <georgezhang at vmware.com> --- drivers/misc/vmw_vmci/vmci_driver.c | 2293 +++++++++++++++++++++++++++++++++++ drivers/misc/vmw_vmci/vmci_driver.h | 48 + 2 files changed, 2341 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

The following series implements VMware VMCI linux kernel driver. Changes includes VMCI driver public API naming conversion from upper case to lower case, some bug fixes. 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

The following series implements VMware VMCI linux kernel driver. Changes includes VMCI driver public API naming conversion from upper case to lower case, some bug fixes. 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