Computing platform with interface based error injection

• US 10,732,986 B2
• Filed: 01/10/2017
• Issued: 08/04/2020
• Est. Priority Date: 11/22/2011
• Status: Active Grant

• Current Assignee: Tahoe Research Limited (f/k/a Learndale Limited) (Vector Capital Corporation)
• Original Assignee: Intel Corporation
• Inventors: Kumar, Mohan, Jayakumar, Sarathy, Vargas, Jose Andy
• Primary Examiner(s): Mehrmanesh, Elmira
• Application Number:
  US15/403,006
• Publication Number:
  US 20170147484A1
• Time in Patent Office: 1,302 Days
• CPC Class Codes: G06F 1/206 comprising thermal management
• CPC Class Codes: G06F 1/26 Power supply means, e.g. regulation thereof for memories G11C
• CPC Class Codes: G06F 1/28 Supervision thereof, e.g. detecting power-supply failure by out of limits supervision
• CPC Class Codes: G06F 1/32 Means for saving power
• CPC Class Codes: G06F 1/3203 Power management, i.e. event-based initiation of a power-saving mode
• CPC Class Codes: G06F 1/3234 Power saving characterised by the action undertaken
• CPC Class Codes: G06F 1/324 by lowering clock frequency
• CPC Class Codes: G06F 1/3275 Power saving in memory, e.g. RAM, cache
• CPC Class Codes: G06F 1/3296 by lowering the supply or operating voltage
• CPC Class Codes: G06F 11/3024 where the computing system component is a central processing unit [CPU]
• CPC Class Codes: G06F 11/3409 for performance assessment
• CPC Class Codes: G06F 11/3447 Performance evaluation by modeling
• CPC Class Codes: G06F 11/3466 Performance evaluation by tracing or monitoring
• CPC Class Codes: G06F 11/3664 Environments for testing or debugging software
• CPC Class Codes: G06F 11/3672 Test management
• CPC Class Codes: G06F 11/3688 for test execution, e.g. scheduling of test suites
• CPC Class Codes: G06F 15/7871 Reconfiguration support, e.g. configuration loading, configuration switching, or hardware OS
• CPC Class Codes: G06F 16/2282 Tablespace storage structures; Management thereof
• CPC Class Codes: G06F 2119/06 Power analysis or power optimisation
• CPC Class Codes: G06F 2209/501 Performance criteria
• CPC Class Codes: G06F 9/22 : Microcontrol or microprogram arrangements
• CPC Class Codes: G06F 9/30098 : Register arrangements
• CPC Class Codes: G06F 9/3012 : Organisation of register space, e.g. banked or distributed register file
• CPC Class Codes: G06F 9/384 : Register renaming
• CPC Class Codes: G06F 9/44 : Arrangements for executing specific programs
• CPC Class Codes: G06F 9/4401 : Bootstrapping security arrangements therefor G06F21/57
• CPC Class Codes: G06F 9/4403 : Processor initialisation
• CPC Class Codes: G06F 9/4418 : Suspend and resume; Hibernate and awake
• CPC Class Codes: G06F 9/445 : Program loading or initiating bootstrapping G06F9/4401; security arrangements for program loading or initiating G06F21/57
• CPC Class Codes: Y02D 10/00 : Energy efficient computing, e.g. low power processors, power management or thermal management

Abstract

Described is a computing platform, which comprises: a non-volatile memory having a firmware boot program; and a CPU to execute the firmware boot program when the CPU is reset, the firmware boot program including instructions to create Power and Performance Measurement (PPM) interface data structures including an error injection table structure to provide error injection services to an OS.

Claims

1. A system comprising:

a platform hardware component; and

a processor to execute an operating system (OS), wherein the OS is to;

execute a first action to determine error injection capabilities of the platform hardware component;

receive a response that is to indicate that the platform hardware component supports a plurality of standard error types and a vendor defined error type;

select, for injection, a first error type from among the plurality of standard error types and the vendor defined error type; and

execute a second action to instruct the platform hardware component to begin an error injection operation using the first error type.

2. The system of claim 1, wherein the OS is to:

in response to the first error type selected by the OS being the vendor defined error type, access a Vendor Error Type Extension Structure.

3. The system of claim 2, wherein the OS is to:

in response to the Vendor Error Type Extension Structure being accessed, read a Vendor ID, a Device ID, and a Rev ID.

4. The system of claim 3, wherein the OS is to:

in response to the Vendor ID, the Device ID, and the Rev ID being read, identify the platform hardware component.

5. The system of claim 3, wherein the OS is to:

in response to the Vendor ID, the Device ID, and the Rev ID being read, identify the vendor defined error type.

6. The system of claim 1, wherein the OS is to:

in response to the second action being executed to instruct the platform hardware component to begin the error injection operation, continually execute a third action until the platform hardware component is to clear a busy bit in a flag to indicate that the error injection operation is complete.

7. The system of claim 6, wherein the third action comprises a CHECK_BUSY_STATUS action.

8. The system of claim 1, wherein the OS is to:

execute a fourth action to determine a status of the error injection operation; and

in response to an indication that the platform hardware component is unable to inject error, stop the error injection operation.

9. The system of claim 8, wherein the fourth action comprises a GET_COMMAND_STATUS action.

10. The system of claim 1, wherein the OS is to:

execute a fifth action to get a physical pointer to an action table;

access the action table; and

execute one or more actions specified in the action table.

11. The system of claim 10, wherein the fifth action comprises a GET_TRIGGER_ERROR_ACTION_TABLE action.

12. The system of claim 1, wherein the OS is to:

in response to a selection of the first error type, select a target for the injection.

13. The system of claim 12, wherein the OS is to:

select the target for the injection from among a memory range, a Peripheral Component Interconnect Express (PCIe) segment, a device, a function, or a processor.

14. The system of claim 1, wherein the OS is to:

execute a sixth action to notify the platform hardware component that the error injection operation is complete.

15. The system of claim 14, wherein the sixth action comprises END_OPERATION action.

16. The system of claim 1, wherein:

the first action comprises a GET_ERROR_TYPE action;

the second action comprises an EXECUTE_OPERATION action; and

the response comprises a DWORD response.

17. An apparatus comprising:

a processor; and

a platform component configured to communicate with an operating system (OS), wherein the platform component is to;

receive a GET_ERROR_TYPE action from the OS that requests error injection capabilities of the platform component;

transmit a DWORD response to the OS, the DWORD response including a bit map that identifies (i) a plurality of standard error types supported by the platform component and (ii) a vendor defined error type supported by the platform component, wherein the OS selects, for injection, a first error type from among the plurality of standard error types and the vendor defined error type; and

receive an EXECUTE_OPERATION action from the OS that instructs the platform component to begin an error injection operation using the first error type.

18. The apparatus of claim 17, wherein the platform component is to:

clear an abstracted busy bit to indicate that the error injection operation is complete.

19. The apparatus of claim 17, wherein the platform component is to:

receive, from the OS, a GET_COMMAND_STATUS that requests a status of the error injection operation.

20. The apparatus of claim 17, wherein the platform component is to:

in response to the platform component being unable to inject errors, transmit, to the OS, a status report that is to indicate that the platform component is unable to inject errors.

21. An apparatus comprising:

a memory; and

a processor to execute an operating system (OS), wherein the OS is to;

execute a GET_ERROR_TYPE action to determine error injection capabilities of a platform component,

receive a DWORD response from the platform component, wherein a first bit of the DWORD is set to indicate that the platform component supports (i) a plurality of standard error types and (ii) a vendor defined error type,

select, for injection, a first error type from among the plurality of standard error types and the vendor defined error type, and

execute a EXECUTE_OPERATION action to instruct the platform component to begin an error injection operation using the first error type.

22. The apparatus of claim 21, wherein the OS is further configured to:

in response to the first error type selected by the OS being the vendor defined error type, access a Vendor Error Type Extension Structure to read a Vendor ID, a Device ID and a Rev ID; and

in response to the Vendor ID, the Device ID and the Rev ID being read, identify the platform component and the vendor defined error type.

23. The apparatus of claim 21, wherein the OS is further configured to:

in response to the EXECUTE_OPERATION action being executed, continually execute a CHECK_BUSY_STATUS action until the platform component indicates that the error injection operation is complete by clearing a busy bit in a flag.

24. The apparatus of claim 21, wherein the OS is further configured to:

execute a GET_COMMAND_STATUS action to determine a status of the error injection operation; and

in response to an indication that the platform component is unable to inject error, stop the error injection operation.

25. The apparatus of claim 21, wherein the OS is to:

execute a GET_TRIGGER_ERROR_ACTION_TABLE operation to get a physical pointer to a TRIGGER_ERROR action table;

access the TRIGGER_ERROR action table; and

execute one or more actions specified in the TRIGGER_ERROR action table.