Vmware, Inc.

Nicira, Inc.

Michael Wei

Nadav Amit

Dahlia Malkhi

Maithem Munshed

Medhavi Dhawan

Amy Tai

Anny Martinez Manzanilla

Eric Schkufza

Dan Tsafrir

Zeeshan Altaf Lokhandwala

Frederick Joseph Jacobs

Roger Michoud

Saeed A Behnam

Pratap Subrahmanyam

Rajesh Venkatasubramanian

Andreas Georg Nowatzyk

Marcos Kawazoe Aguilera

Kiran Tati

Irina Calciu

Xavier Deguillard

Xin Liang Li

Jayneel Gandhi

Wenbin Zhu

Lalith Suresh

Ragnar Edholm

Ali Najafi

Stanko Novakovic

Igor Smolyar

Ke Wang

Cheng Chun Tu

Described herein are systems, methods, and software to manage time calibration associated with an oscillator of a computing system. In one example, a computing system monitors clock cycles for an oscillator on the computing system, receives timing messages from a server, and calculates the frequency of the oscillator at intervals based on the monitored clock cycles and timing messages. The computing system further identifies a temperature from a temperature sensor at each of the intervals and generates a function to demonstrate frequency of the oscillator versus temperatures from the temperature sensor based on the identified temperatures and frequencies at the intervals.

Clock calibration in a computing system using temperature sensors

A hypervisor communicates with a guest operating system running in a virtual machine supported by the hypervisor using a hyper-callback whose functions are based on the particular guest operating system running the virtual machine and are triggered by one or more events in the guest operating system. The functions are modified to make sure they are safe to execute and to allow only limited access to the guest operating system. Additionally, the functions are converted to byte code corresponding to a simplified CPU and memory model and are safety checked by the hypervisor when registered with the hypervisor. The functions are executed by the hypervisor without any context switch between the hypervisor and guest operating system, and when executed, provide information about the particular guest operating system, allowing the hypervisor to improve operations such as page reclamation, virtual CPU scheduling, I/O operations, and tracing of the guest operating system.

Safe execution of virtual machine callbacks in a hypervisor

Garbage collection processing in a distributed shared log system includes a client identifying obsoleted log entries for a shared data object. The client sends information associated with the identified obsoleted log entries to a shared log server. The shared log server receives information associated with obsoleted log entries from all clients in the distributed shared log system and uses the information to delete the obsoleted log entries. The shared log server can update a snapshot mark to indicate the earliest time that a snapshot of the shared log can be taken. The snapshot mark can be updated based on the information associated with obsoleted log entries.

In-place garbage collection for state machine replication

One or more kernel-modifying procedures are stored in a trusted computing base (TCB) when bringing up a guest operating system (OS) on a virtual machine (VM) on a virtualization platform. When the guest OS invokes an OS-level kernel-modifying procedure, a call is made to the hypervisor. If the hypervisor determines the TCB to be valid, the kernel-modifying procedure in the TCB that corresponds to the OS-level kernel-modifying procedure is invoked so that the kernel code can be modified.

Enforcing code integrity using a trusted computing base

Methods, systems, and apparatus, including computer programs encoded on computer storage media, for enforcing a decay policy for a data object. One of the methods includes receiving a request to store a data object in a storage device; obtaining a user policy identifying a lifetime of the data object; determining, using the lifetime of the data object, a voltage policy for a plurality of memory cells of the storage device, wherein: each of the plurality of memory cells will store one or more bits of the data object; the voltage policy identifies a voltage to provide each memory cell; and an expected time at which raw bit errors of the data object will cause the data object to decay is equal to a time point identified by the lifetime of the data object; and storing the data object in the storage device according to the determined voltage policy.

Managing data lifecycles through decay

A shared log system can provide a key-index structure (main map) that allows clients (users) to access the state of objects stored in the shared log system. The client can define secondary indices on the main map to provide access to the data that are tailored to the client's data needs. Each client can generate their own customized set of secondary indices different from other clients.

Just-in-time multi-indexed tables in a shared log

Techniques for consolidating shared state for translation lookaside buffer (TLB) shootdowns are provided. In one set of embodiments, an operating system (OS) kernel of a computer system can co-locate, in a system memory of the computer system, a plurality of shared data accessed by first and second processing cores of the computer system for performing a translation lookaside buffer (TLB) shootdown of the first processing core by the second processing core, where the co-locating allows the plurality of shared data to occupy a single cache line when brought from the system memory into a CPU (central processing unit) cache of the first or second processing core. This can include, e.g., (1) co-locating a lazy mode indicator and a call function queue (CFQ) head element of the first processing core, such that these two data components occupy the same cache line, and (2) co-locating a TLB flush info entry and a call function data (CFD) entry created by the second processing core at the time of initiating the TLB shootdown, such that these two data components occupy the same cache line.

Consolidating shared state for translation lookaside buffer shootdowns

Techniques for implementing early acknowledgement for translation lookaside buffer (TLB) shootdowns are provided. In one set of embodiments, a first (i.e., remote) processing core of a computer system can receive an inter-processor interrupt (IPI) from a second (i.e., initiator) processing core of the computer system for performing a TLB shootdown of the first processing core. Upon receiving the IPI, an interrupt handler of the first processing core can communicate an acknowledgement to the second processing core that the TLB of the first processing core has been flushed, prior to actually flushing the TLB.

Early acknowledgement of translation lookaside buffer shootdowns

Described herein are embodiments that adaptively reduce the number of interrupts that occur between a device controller and a computer system. Device commands are submitted to the controller by an operating system on behalf of an application. The device performs the received commands and indicates command completions to the controller. A counter counts completions, and if the count exceeds a threshold number, the controller generates an interrupt to the computer system. If the count is greater than zero and the timeout interval has expired, then the controller generates an interrupt to the computer system. In some embodiments, the application attaches flags to one of the commands indicating that an interrupt relating to completion of the flagged command should be generated as soon as possible or that an interrupt relating to completion of all commands prior to and including the flagged command should be generated as soon as possible.

Software-controlled interrupts for I/O devices

A log unit provides a shared log for recording updates on data objects. Garbage collection is performed locally and in-place by the log unit. In a marking portion of the garbage collection process, the log unit identifies and marks log entries that record supersedable updates. In a deallocation portion of the process, the log unit deallocates at least portions of the marked log entries that contain supersedable updates.

In-place garbage collection of a sharded, replicated distributed state machine based on supersedable operations

A method for redirecting indirect calls to direct calls on a per-process basis includes accessing a memory code region of an operating system kernel that has a different mapping for each of one or more user processes running on the operating system kernel. The memory code region stores a first trampoline that refers directly to a second trampoline, which is an inline or outline trampoline that is correlated with a particular user process. Executing the first trampoline invokes the second trampoline, as a result of which the indirect calls are redirected to direct calls.

Target injection safe method for inlining instance-dependent calls

A system and method are disclosed for executing a hardware component of a design in a hardware engine, where the component includes a pre-compiled library component. The hardware component is compiled to include an interface that supports a 'forward( )' function which, when invoked, requests that the hardware engine running the hardware component run such that interactions between the library component and the hardware component occur without communicating with the runtime system because interactions between the library component and the hardware component are handled locally by the hardware engine and not the runtime system. Handling the library component without the runtime system intervening allows the library component to run at a speed that is close to the native speed of the target re-programmable hardware fabric. In addition, library components targeted to the specific reprogrammable hardware fabric are available to the design without compilation.

Just-in-time hardware for field programmable gate arrays

A system and method are disclosed for executing a component of a design in a hardware engine. The component is compiled to include an interface that supports an 'open_loop(n)' function which, when invoked, requests that the hardware engine run for a specified number of steps before communicating with other hardware or software engines via a runtime system. After the compiled hardware component is transferred to the hardware engine, the hardware engine runs for the specified number of steps unless and until it encounters a system function, such as a 'display(s)' function, in the code of the component that requires the runtime system to intervene. The hardware engine pauses awaiting the completion of the system function and continues its execution. The &#x2018;open_loop(n)&#x2019; operation of the hardware engine permits components in hardware engines to run at a speed close to the native speed of the target programmable hardware fabric.

A system and method for executing a hardware component of a design are disclosed. The system and method execute hardware components that are constructed with a 'display(s)' function that permits the hardware component to display values 's' internal to the hardware component while the component is executing on a hardware engine. The values are displayed on a user output interface, such as a user terminal, supported by a runtime system controlling the execution of the hardware engine and thus allows the user to debug the component while it is executing on the hardware engine.

A method for implementing a distributed hardware system includes retrieving a hardware design described in a hardware description language, where the hardware design includes a plurality of modules. The method includes sending modules of the design to software engines, where the runtime software maintains for each module being simulated an update queue and evaluate queue. The update queue contains events that update stateful objects in the module and cause evaluation events to be enqueued onto the evaluate queue, while the evaluate queue contains evaluate events that update stateless objects and cause update events to be enqueued onto the update queue. Having a update and evaluate queues for each module permits the runtime to manage module simulations so that the executions of each module run concurrently with each other.

Growing community of inventors

Palo Alto, CA, United States of America

Michael Wei