Microsoft Technology Licensing, LLC

Jason Stewart Wohlgemuth

Minsang Kim

Shuvabrata Ganguly

Tristan Anthony Brown

James Anthony Schwartz, Jr

Allen Marshall

Youssef M Barakat

Cody D Hartwig

Thomas Philip Speier

Abolade Gbadegesin

Scott Chao-Chueh Lee

Bruce John Sherwin, Jr

Gagan Gupta

Gaurav Jagtiani

Andrew Raffman

Omid Fatemieh

Binit Ranjan Mishra

Steven Adrian West

Aacer Hatem Daken

Emma Sutherland Boyd

Emily Cara Clemens

Artur Klauser

Hari R Pulapaka

Karan Mehra

James George Cavalaris

Steve Pronovost

Emily Nicole Wilson

Shen Wang

Neeraj Ladkani

Peter W Wieland

Neeraj Kumar Singh

Baskar Sridharan

Derek Chiou

Aditya Bhandari

Michael Bishop Ebersol

Jin Lin

Yuri Dotsenko

Naga Govindaraju

Abdelsalam Heddaya

Kumar Rajeev

Kapil Vaswani

Attilio Mainetti

Abhay Sudhir Ketkar

Antoine Jean Denis Delignat-lavaud

Elsie Nallipogu

Alexander Daniel Grest

Shekhar Agrawal

Peter Hanpeng Jiang

Sarah Elizabeth Stephenson

Shailesh Padmakar Joshi

Raz Meir Aloni

Terence Kwok Tak Chan

Soheil Ebadian

Jennifer Marie Bourlier

Sharon Scarlet Tang

Drew Douglas Cross

Sri Harsha Kanukuntla

Mukhtar Ahmed

Jeremiah S Samli

David Wimmel

Christina Marianne Curlette

Vijaybalaji Madhanagopal

Dexuan Cui

Carolina Cecilia Perez-vargas

Michael Halstead Kelley

Youssef Maged Barakat

Bruce Sherwin

A computer system identifies an event from a management system log associated with a first container host. The presence of the event in the management system log is indicative that the first container host identified a fatal system error at the first container host. Based on the event, the computer system determines that a first instance of a container that is provisioned at the first container host has been isolated to the first container host. Based on the first instance of the container having been isolated to the first container host, the computer system instructs a second container host to provision a second instance of the container at the second container host.

Accelerated fatal system error recovery of container host

In-place recovery of fatal system errors at virtualization hosts. A device identifies an occurrence of a fatal system error in the first instance of a host operating system (OS) executing in a computer system. The device determines to perform an in-place recovery for the fatal system error. The device performs the in-place recovery, including pausing the execution of a virtual machine (VM) by the first instance of the host OS, preserving a state of the VM within system memory of the computer system, and resuming the execution of the VM by a second instance of the host OS executing in the computer system based on the state of the VM that is preserved within the system memory of the computer system.

In-place recovery of fatal system errors at virtualization hosts

Methods, systems, and computer program products for direct assignment of physical devices to confidential virtual machines (VMs). At a first guest privilege context of a guest partition, a direct assignment of a physical device associated with a host computer system to the guest partition is identified. The guest partition includes the first guest privilege context and a second guest privilege context, which is restricted from accessing memory associated with the first guest privilege context. The guest partition corresponds to a confidential VM, such that a memory region associated with the guest partition is inaccessible to a host operating system. It is determined, based on a policy, that the physical device is allowed to be directly assigned to the guest partition. Communication between the physical device and the second guest privilege context is permitted, such as by exposing the physical device on a virtual bus and/or forwarding an interrupt.

Direct assignment of physical devices to confidential virtual machines

Performing speculative address translation in processor-based devices is disclosed herein. In one exemplary embodiment, a processor-based device provides a processing element (PE) that defines a speculative translation instruction such as an enqueue instruction for offloading operations to a peripheral device. The speculative translation instruction references a plurality of bytes including one or more virtual memory addresses. After receiving the speculative translation instruction, an instruction decode stage of an execution pipeline circuit of the PE transmits a request for address translation of the virtual memory address to a memory management unit (MMU) of the PE. The MMU then performs speculative address translation of the virtual memory address into a corresponding translated memory address. In some embodiments, any address translation errors encountered are raised to an appropriate exception level, and may be raised synchronously or asynchronously with respect to an operation performed when the speculative translation instruction is executed.

Performing speculative address translation in processor-based devices

Implementing a firmware watchdog timer. A system presents a data structure over a bus which exposes, to software executing at a central processing unit (CPU), a hardware resource that is associated with a watchdog timer, attribute(s) of the watchdog timer, and (iii) commands available to the software executing at the CPU for managing the watchdog timer via one or more native CPU instructions that target the hardware resource. The system listens on the bus for a data value written to the hardware resource (i.e., by a native CPU operation issued by the software executing at the CPU), and identifies a particular command for managing the watchdog timer based on the data value written. Based on identifying the particular command, the system performs at least one of: initializing the watchdog timer, starting the watchdog timer, resetting the watchdog timer, or stopping the watchdog timer.

Firmware emulated watchdog timer controlled using native CPU operations

Enabling peripheral device messaging via application portals in processor-based devices is disclosed herein. In one embodiment, a processor-based device comprises a processing element (PE) including an application portal configured to logically operate as a message store, and that is exposed as an application portal address within an address space visible to a peripheral device that is communicatively coupled to the processor-based device. Upon receiving a message directed to the application portal address from the peripheral device, an application portal control circuit enqueues the message in the application portal. In some embodiments, the PE may further provide a dequeue instruction that may be executed as part of the application, and that results in a top element of the application portal being dequeued and transmitted to the application. Some embodiments may provide further mechanisms for sending success and/or failure notifications, and/or for informing the application that the message has been enqueued.

Enabling peripheral device messaging via application portals in processor-based devices

A system provides virtual per-processor timers based on a timer such as a platform timer. To virtualize a timer to be used by each processor independently, a data structure is maintained in memory for the timer. The data structure has an entry for each interrupt to be produced for each processor using the timer, specifying the processor and the due time, with the entries sorted by due time. If the virtualized timer is a platform timer that maintains context during power transitions, a processor can switch to the virtual per-processor timer upon a context-losing power transition.

Virtual per-processor timers for multiprocessor systems

Techniques described herein enable the implementation of a secure driver framework. In one example, a method includes managing an unsecure operating system execution environment comprising a first user mode and a first kernel mode. The method can also include managing a secure execution environment comprising a second user mode and a second kernel mode, and executing a secure driver within the second user mode of the secure execution environment in response to a system call from an unsecure driver in the first kernel mode or the first user mode, wherein the secure driver enables the unsecure driver to communicate with a secure device. Furthermore, the method can include providing one or more system services of the second kernel mode to the secure driver.

Secure driver platform

An operating system includes an interrupt router that dynamically steers each interrupt to one or more processors within set of processors based on overall load information from the set of processors. An interrupt source is assigned to a processor based on the load imposed by the interrupt source and the target overall load for the processor. For example, each processor can maintain information about each interrupt it processes over time. The operating system receives this historical load information to determine an expected load for interrupts of a given type from a given device, an overall load on the system, and a target load for each processor. Given a set of interrupt sources, their expected loads, and target load for each processor, each interrupt source can be assigned dynamically to a processor during runtime of the system. These assignments can be changed given current operating conditions of the system.

Operating system-managed interrupt steering in multiprocessor systems

A computing system in which a software component executing on a platform can reliably and efficiently obtain state information about a component supported by the platform through the use of a shared memory page. State information may be supplied by the platform, but any state translation information needed to map the state information as supplied to a format as used may be provided through the shared page. In a virtualized environment, the state translation information can be used to map the value of a virtual timer counter or other component from a value provided by a virtual processor to a normalized reference time that will yield the same result, regardless of whether the software component is migrated to or from another virtual processor. Use of a shared page avoids the inefficiency of an intercept into a virtualized environment or a system calls in native mode operation.

Timer access from user mode through a shared memory page

Heterogeneous thread scheduling techniques are described in which a processing workload is distributed to heterogeneous processing cores of a processing system. The heterogeneous thread scheduling may be implemented based upon a combination of periodic assessments of system-wide power management considerations used to control states of the processing cores and higher frequency thread-by-thread placement decisions that are made in accordance with thread specific policies. In one or more implementations, a system workload context is periodically analyzed for a processing system having heterogeneous cores including power efficient cores and performance oriented cores. Based on the periodic analysis, cores states are set for some of the heterogeneous cores to control activation of the power efficient cores and performance oriented cores for thread scheduling. Then, individual threads are scheduled in dependence upon the core states to allocate the individual threads between active cores of the heterogeneous cores on a per-thread basis.

Heterogeneous thread scheduling

An operating system is provided in which an interrupt router dynamically steers each interrupt to one or more processors within set of processors based on overall load information from the set of processors. An interrupt source is assigned to a processor based on the load imposed by the interrupt source and the target overall load for the processor. For example, each processor can maintain information about each interrupt it processes over time. The operating system receives this historical load information to determine an expected load for interrupts of a given type from a given device, an overall load on the system, and a target load for each processor. Given a set of interrupt sources, their expected loads, and target load for each processor, each interrupt source can be assigned dynamically to a processor during runtime of the system. On a regular basis, these assignments can be changed given current operating conditions of the system.

Enlightenment for low overhead hardware access

The resource leak detector attempts to identify the causes of resource leaks and fix the causes if possible. At a minimum, the located resource leaks are reported to an operating system manufacture for additional study and possible correction, either by the operating system manufacturer or the application manufacturer that is causing the resource leak. In an embodiment, in operation, a leak trigger for starting leak detection is started. If the leak trigger is activated, leak detection is started when an application begins. Resource allocations are tracked for the leaked resource and each leaked resource is matched to a corresponding allocation call stack. A type of the leaked resource may be identified. The leak detection and the leak trigger may be controlled according to at least one of a local policy and a global policy. The local and the global policy may be updated dynamically such as by using aggregated occurrences of applications that met the local policy or by matching a plurality of distinct types of leaked resources to the same call stack. A leak report may be generated of resource leak data where the leak report is stored locally or communicated to a local aggregation database or remote aggregation database. The leak report may include total leaked allocations, total size of leaked allocations, total outstanding allocations, total size of outstanding allocations and matched allocation call stacks. The leaked resource may be automatically reclaimed and a fix to the leaked resource may be created and applied automatically.

Automatically resource leak diagnosis and detecting process within the operating system

Growing community of inventors

Seattle, WA, United States of America

Jason Stewart Wohlgemuth