]> git.ipfire.org Git - thirdparty/open-vm-tools.git/commitdiff
VMCI device needs a limit on the datagram queue
authorVMware, Inc <>
Sat, 28 May 2011 19:30:48 +0000 (12:30 -0700)
committerMarcelo Vanzin <mvanzin@vmware.com>
Sat, 28 May 2011 19:30:48 +0000 (12:30 -0700)
It turns out that we've never put a limit on the number of
datagrams that can be queued in the device.  The perf test
keeps pushing datagrams, and with nobody reading them, the
queue in the VMX just keeps growing until we exhaust the
pagefile.

Added a limit in VMCI_QueueDatagram().  We use the same
limit we use elsewhere, which is 2 x DG_MAX, or ~128K, for
normal datagrams, and a higher limit for events (datagrams
sent from the VMX/event resource ID).

Signed-off-by: Marcelo Vanzin <mvanzin@vmware.com>
open-vm-tools/modules/linux/shared/vmci_call_defs.h
open-vm-tools/modules/linux/vmci/common/vmciContext.c

index 6a5b9342f3144e86b17696bb573e9fb97ccbc665..e85807c59b68da901e4c45d6cf31487ab9a04f09 100644 (file)
@@ -76,9 +76,28 @@ typedef struct VMCIDatagram {
 #define VMCI_DG_HEADERSIZE sizeof(VMCIDatagram)
 #define VMCI_DG_SIZE(_dg) (VMCI_DG_HEADERSIZE + (size_t)(_dg)->payloadSize)
 #define VMCI_DG_SIZE_ALIGNED(_dg) ((VMCI_DG_SIZE(_dg) + 7) & (size_t)CONST64U(0xfffffffffffffff8))
-#define VMCI_MAX_DATAGRAM_QUEUE_SIZE  (VMCI_MAX_DG_SIZE * 2)
+#define VMCI_MAX_DATAGRAM_QUEUE_SIZE (VMCI_MAX_DG_SIZE * 2)
 
-/* 
+/*
+ * We allow at least 1024 more event datagrams from the hypervisor past the
+ * normally allowed datagrams pending for a given context.  We define this
+ * limit on event datagrams from the hypervisor to guard against DoS attack
+ * from a malicious VM which could repeatedly attach to and detach from a queue
+ * pair, causing events to be queued at the destination VM.  However, the rate
+ * at which such events can be generated is small since it requires a VM exit
+ * and handling of queue pair attach/detach call at the hypervisor.  Event
+ * datagrams may be queued up at the destination VM if it has interrupts
+ * disabled or if it is not draining events for some other reason.  1024
+ * datagrams is a grossly conservative estimate of the time for which
+ * interrupts may be disabled in the destination VM, but at the same time does
+ * not exacerbate the memory pressure problem on the host by much (size of each
+ * event datagram is small).
+ */
+#define VMCI_MAX_DATAGRAM_AND_EVENT_QUEUE_SIZE \
+   (VMCI_MAX_DATAGRAM_QUEUE_SIZE + \
+    1024 * (sizeof(VMCIDatagram) + sizeof(VMCIEventData_Max)))
+
+/*
  * Struct for sending VMCI_DATAGRAM_REQUEST_MAP and VMCI_DATAGRAM_REMOVE_MAP
  * datagrams. Struct size is 32 bytes. All fields in struct are aligned to
  * their natural alignment.
index 74aa293218ed259776aad4e8411d097b961d91e4..309b5a8440d41b90be14021ed8ee3aab641d783f 100644 (file)
@@ -598,27 +598,6 @@ VMCIContext_PendingDatagrams(VMCIId cid,      // IN
 }
 
 
-/*
- * We allow at least 1024 more event datagrams from the hypervisor past the
- * normally allowed datagrams pending for a given context.  We define this
- * limit on event datagrams from the hypervisor to guard against DoS attack
- * from a malicious VM which could repeatedly attach to and detach from a queue
- * pair, causing events to be queued at the destination VM.  However, the rate
- * at which such events can be generated is small since it requires a VM exit
- * and handling of queue pair attach/detach call at the hypervisor.  Event
- * datagrams may be queued up at the destination VM if it has interrupts
- * disabled or if it is not draining events for some other reason.  1024
- * datagrams is a grossly conservative estimate of the time for which
- * interrupts may be disabled in the destination VM, but at the same time does
- * not exacerbate the memory pressure problem on the host by much (size of each
- * event datagram is small).
- */
-
-#define VMCI_MAX_DATAGRAM_AND_EVENT_QUEUE_SIZE \
-   (VMCI_MAX_DATAGRAM_QUEUE_SIZE + \
-    1024 * (sizeof(VMCIDatagram) + sizeof(VMCIEventData_Max)))
-
-
 /*
  *----------------------------------------------------------------------
  *