Spoofing cpuid for backward compatibility

CN116340022BActive Publication Date: 2026-10-23SONY INTERACTIVE ENTERTAINMENT LLC
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202310197565.2
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Priority Date
2016-01-22
Filing Date
2017-01-20
Publication Date
2026-10-23
Estimated Expiration
2037-01-20

AI Technical Summary

Technical Problem

即使新的装置能够执行为遗留装置创建的遗留应用程序,新的装置在运行那些应用程序时仍可能会无法向后兼容

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN116340022B_ABST
    Figure CN116340022B_ABST
Patent Text Reader

Abstract

To facilitate backward compatibility, a computing device can respond to a call from an application for information about a processor on the computing device by returning information about a processor different from the processor on the computing device.
Need to check novelty before this filing date? Find Prior Art

Description

[0001] This divisional application is filed on January 20, 2017, with application number 201780007665.7 and invention title "Cheating CPUID for Backward Compatibility".

[0002] Priority Statement

[0003] This application claims the benefit of U.S. Provisional Patent Application No. 62 / 286,280, filed on January 22, 2016, prior to co-assignment, the entire contents of which are incorporated herein by reference. Background Technology

[0004] When a new version of a computer system (“new device”) is released, it is hoped that applications written for previous versions of the system (“legacy device”) will run perfectly on the new device. This capability is often referred to as “backward compatibility,” which is equivalent to “legacy applications.” Even if the new device can execute legacy applications created for the legacy device, the new device may still not be backward compatible when running those applications. Performance differences between the hardware components of the new and legacy devices can cause synchronization errors on the new device. This performance difference may stem from, for example, the difference in capabilities between the central processing unit (CPU) of the new device and the CPU of the legacy device. For instance, if the CPU on the new device is faster than the CPU on the legacy device, data still in use by another component of the new device may be prematurely overwritten by the CPU. Attached Figure Description

[0005] The doctrines disclosed herein can be readily understood by considering the following detailed description taken in conjunction with the accompanying drawings, wherein:

[0006] Figure 1 This is a flowchart illustrating a method for achieving backward compatibility according to aspects of this disclosure.

[0007] Figure 2 This is a block diagram showing the Central Processing Unit (CPU), which is used for execution. Figure 1 The executable software implementation of the method is located in read-only memory (ROM).

[0008] Figure 3 It includes Figure 2 A block diagram of a device with a CPU of the type shown. Summary of the Invention

[0009] The disadvantages associated with the prior art are overcome by aspects of this disclosure, which relates to a method in which a computing device responds to a call from an application for information about a processor on the computing device by returning information about a processor different from the processor on the computing device. Detailed Implementation

[0010] While the following detailed description contains many specific details for illustrative purposes, any person skilled in the art will understand that many variations and modifications to these details are within the scope of the invention. Therefore, the exemplary embodiments of the invention described below are set forth without losing their generality and without implying any limitation on the claimed invention.

[0011] introduction

[0012] To address issues arising from differences in CPU behavior relative to legacy devices, new devices can emulate certain functions of a legacy device's CPU when running legacy applications. A key feature of this ability is tricking legacy applications into behaving as if they were running on a legacy device. Because many applications are designed to run on different processors, modern processors typically implement opcodes or registers to allow software applications to discover processor details. For backward compatibility, the processor on a new device can execute opcodes or supply register values ​​in response to calls from legacy applications, returning different processor information. This different information is referred to herein as a "spoofed processor ID." The spoofed processor ID selectively identifies certain features of the new device as different from actually supported features or completely unsupported features that are actually supported.

[0013] method

[0014] Figure 1 The flowchart shown illustrates method 100, demonstrating an example of how this would work. Specifically, the requesting application 101 running on the device requests a processor ID from the processor running the application, as shown at 102. At 104, the processor determines whether the requesting application 101 is a legacy application, i.e., an application originally written for an earlier version of the device. The processor can determine whether an application is written for a new device or a legacy device in several ways. One way would be to identify the application as written for a new device if all applications written for a new device report this information to the processor upon loading. Reporting such information will identify the application as written for a new device, and failure to report such information will identify the application as a legacy application.

[0015] The information returned by the processor to the requesting application 101 will differ based on whether application 101 is a legacy application or a new application (i.e., an application written to run on the device). If the requesting application 101 is a new application, the processor returns genuine processor information, such as the correct processor ID 103 of the processor on the device running the application, as indicated at 106. If the requesting application 101 is a legacy application, the processor returns spoofed processor information, such as a spoofed processor ID 105, as indicated at 108. The returned information may identify certain features that the processor actually supports as unsupported, or indicate that the processor running the application is a legacy processor.

[0016] As an example, and not a limitation, a spoofed processor ID 105 might be returned by a modified CPUID instruction, which is an opcode supported by the x86 architecture. By using the CPUID opcode, software can determine the presence of processor type and characteristics such as the implementation of various SSE instruction set architectures. On the x86 architecture, the CPUID opcode consists of bytes 0Fh and A2h, and the values ​​in the EAX register, and in some cases the ECX register, specify the information to be returned.

[0017] In assembly language, the CPUID instruction takes no arguments; instead, it implicitly uses the EAX register to determine the primary category of the returned information, often referred to as the CPUID leaf. When EAX = 0, the application calling CPUID will receive the highest EAX call parameter (leaf) supported by the CPU at the time of return in the EAX register, and other registers contain the vendor ID identifying the CPU manufacturer. To obtain extended feature information, CPUID can be called with the most significant bit of EAX set. To determine the highest extended feature call parameter, CPUID can be called with EAX = 80000000h. Some leaves also have sub-leaves, which are selected via the ECX register before calling CPUID.

[0018] Calling CPUID with EAX=1 returns information about the CPU's stepping model, model, and series information (also known as the CPU's signature) in EAX, feature flags in EDX and ECX, and additional feature information in EBX. Calling CPUID with EAX=2 returns a list of descriptors indicating the functionality of the cache and Translation Lookaside Buffer (TLB) registers in EAX, EBX, ECX, and EDX. Other EAX values ​​return information such as the processor serial number, thread / core and cache topology, extended features, processor brand, L1 cache and TLB identifiers, extended L2 cache features, power management feature identifiers, and virtual and physical address sizes. Figure 1 The type of program shown can return values ​​that differ from the correct values ​​for any or all of these values ​​when a legacy application makes a query.

[0019] CPU

[0020] Figure 1 The processor ID spoofing functionality shown can be implemented on a new device in any of a variety of different ways. For example, the new device may include special microcode in ROM or RAM that returns spoofed processor ID information in response to queries from legacy applications. Figure 2 One possible implementation of CPU 200 is shown, in which the microcode is implemented in ROM as part of CPU core 202. The CPU may include one or more such cores. CPU cores 202 may share a common L2 cache 204 and bus interface 206. Each core 202 may contain logic units 208 for loading, storing, scheduling, decoding, and executing instructions, as well as registers 210, cache 212, and a translation lookahead buffer (TLB) 214 for instruction and data.

[0021] exist Figure 2 In the specific implementation shown, the CPUID instruction is implemented by microcode 216 stored in ROM 218. The microcode contains a processor ID program and two different processor ID datasets. One dataset (ID1) is used for new device applications, and the other dataset (ID2) is used for legacy device applications.

[0022] In alternative implementations, there may be two distinct processor ID programs, one for legacy applications and another for new device applications. In such implementations, CPU 200 can selectively run one program or the other when executing CPUID instructions, depending on whether the application it is running is a legacy application or a new device application. In other alternative implementations, the processor ID program can be implemented using special dedicated hardware; for example, certain aspects of returning processor ID information can be implemented using hardware logic instead of microcode stored in ROM 218. In other alternative implementations, the microcode can be stored in random access memory (RAM) instead of ROM.

[0023] system

[0024] Figure 2 The type of CPU shown can be incorporated into new devices. For example... Figure 3 As can be seen, the new device 300 may include a CPU 200 with multiple cores 202 and a GPU 302 with multiple compute units (CUs) 304. The CPU and GPU can communicate with each other and with the memory and I / O controller 310 via L2 caches 204, 304, bus interfaces 206, 306 and front-side bus 308. The memory and I / O controller 310 manages data transfers between the CPU 200 and GPU 302 and memory 312 (e.g., RAM), storage device 314 (e.g., disk drive or flash memory), video card 316, peripheral devices 318 and network 320 via a properly configured bus 322.

[0025] Device 300 runs application 101 by executing its instructions on CPU 200 and GPU 302. Parts of application 101 can be loaded into memory 312. In one particular implementation, CPUID instructions are implemented by microcode containing a processor ID program and two different processor ID datasets, for example, as described above regarding... Figure 2 The discussion.

[0026] As noted above, in alternative implementations, there may be two different processor ID programs, one for legacy applications and the other for new device applications. In such implementations, CPU 200 can selectively run one program or the other when executing CPUID instructions, depending on whether the application it is running is a legacy application or a new device application. In other alternative implementations, a single processor ID program can return processor ID data, which differs in some details depending on whether the query program is a legacy application or a new device application. In other alternative implementations, processor ID code 216 can be implemented using special dedicated hardware; for example, certain aspects of returning processor ID information can be implemented using hardware logic instead of microcode stored in ROM 218 of CPU core 202. In other alternative implementations, the microcode can be stored in random access memory (RAM) 312 (e.g., main memory) instead of ROM.

[0027] Returning spoofed processor characteristic information can help resolve backward compatibility issues by preventing applications from exploiting features that, even if supported, could cause timing problems (if legacy applications attempt to use them).

[0028] While the foregoing is a complete description of preferred embodiments of the invention, various substitutions, modifications, and equivalents are possible. Therefore, the scope of the invention should not be determined by reference to the foregoing description, but rather by reference instead to the appended claims and their entire scope of equivalents. Any feature (whether preferred or not) may be combined with any other feature (whether preferred or not). In the appended claims, unless otherwise expressly stated, [the following is unclear and requires further context]. The article "one" Or "a kind of" "Quantity" refers to one or more of the items following the article. The appended claims should not be construed as including a component with a functional limitation unless such limitation is explicitly stated in the given claim using the phrase "component for...". Any element in the claims that does not explicitly state "component for" performing the specified function should not be construed as a "component" or "step" clause as defined in 35 USC §112(f).

Claims

1. A method in a computing device, the method comprising: Execute the application's instructions; as well as Respond to calls from the application for information about the processor on the computing device, wherein When the application reports information to the processor upon loading, the application is identified as being written for the processor of the computing device, and information about the processor on the computing device is returned to the application. When the application does not report information to the processor during loading, the application is identified as being written for a legacy processor, and information about the legacy processor is returned to the application, wherein the information about the legacy processor identifies certain features of the processor on the computing device as different from features actually supported by the computing device.

2. The method of claim 1, wherein the information regarding the legacy processor identifies certain features of the processor on the computing device as completely unsupported by the processor on the computing device, when in fact those features are supported by the processor on the computing device.

3. The method of claim 1, wherein the application is a legacy application written for a legacy computing device, and wherein the information about the legacy processor identifies a processor on the legacy computing device.

4. The method of claim 1, wherein returning the information about the legacy processor includes using opcodes supported by the architecture of the processor on the computing device.

5. The method of claim 1, wherein returning the information about the legacy processor includes using opcodes supported by the x86 architecture.

6. The method of claim 1, wherein returning the information about the legacy processor includes using CPUID instructions.

7. The method of claim 1, wherein returning the information about the legacy processor includes using microcode stored in ROM or RAM associated with the processor on the computing device.

8. The method of claim 1, wherein returning the information about the legacy processor comprises using microcode stored in ROM or RAM associated with the processor on the computing device and two different processor ID datasets, one dataset being for new device applications and the other dataset being for legacy device applications.

9. The method of claim 1, wherein returning the information about the legacy processor comprises using microcode stored in ROM or RAM associated with the processor on the computing device, and the microcode returns processor ID data, which differs in some details depending on whether the querying program is a new device application or a legacy device application.

10. The method of claim 1, wherein returning the information about the legacy processor includes using one ID program for the legacy application and another ID program for the new device application.

11. The method of claim 1, wherein returning the information about the legacy processor includes using dedicated hardware.

12. The method of claim 1, wherein, The information about the processor on the computing device or about the legacy processor includes processor model, processor family, cache capacity, translation lookahead buffer capacity, processor serial number, processor brand, processor manufacturer, thread / core topology, cache topology, extended features, virtual address size or physical address size.

13. A computing device, the computing device comprising: A processor configured to execute instructions for an application; as well as The processor is configured to respond to calls from the application for information about the processor, wherein The processor is configured to, when the application reports information to the processor during loading, identify the application as being written for the processor of the computing device, and return information about the processor on the computing device to the application. The processor is configured to identify the application as written for a legacy processor when the application does not report information to the processor during loading, and to return information about the legacy processor to the application, wherein the information about the legacy processor identifies certain features of the processor on the computing device as different from features actually supported by the computing device.

14. The computing device of claim 13, wherein the information regarding the legacy processor identifies certain features of the processor on the computing device as completely unsupported by the processor on the computing device, when in fact the certain features are supported by the processor on the computing device.

15. The computing device of claim 13, wherein the application is a legacy application written for a legacy computing device, and wherein the information about the legacy processor identifies a processor on the legacy computing device.

16. The computing device of claim 13, wherein returning the information about the legacy processor includes using opcodes supported by the architecture of the processor on the computing device.

17. The computing device of claim 13, wherein returning the information about the legacy processor includes using opcodes supported by the x86 architecture.

18. The computing device of claim 13, wherein returning the information about the legacy processor includes using CPUID instructions.

19. The computing device of claim 13, further comprising a ROM or RAM associated with the processor on the computing device, wherein returning the information about the legacy processor includes using microcode stored in the ROM or RAM associated with the processor on the computing device.

20. The computing device of claim 13, further comprising a ROM or RAM associated with the processor on the computing device, wherein returning the information about the legacy processor includes using microcode stored in the ROM or RAM associated with the processor on the computing device and two different processor ID datasets, one dataset being for a new device application and the other dataset being for a legacy device application.

21. The computing device of claim 13, further comprising ROM or RAM associated with the processor on the computing device, wherein returning the information about the legacy processor includes using microcode stored in the ROM or RAM associated with the processor on the computing device, and the microcode returns processor ID data, the processor ID data differing in some details depending on whether the querying program is a new device application or a legacy device application.

22. The computing device of claim 13, wherein returning the information about the legacy processor includes using one ID program for the legacy application and another ID program for the new device application.

23. The computing device of claim 13, further comprising dedicated hardware configured to return the information about the legacy processor, the return including the use of the dedicated hardware.

24. The computing device of claim 13, wherein, The information about the processor on the computing device or about the legacy processor includes processor model, processor family, cache capacity, translation lookahead buffer capacity, processor serial number, processor brand, processor manufacturer, thread / core topology, cache topology, extension features, virtual address size or physical address size.

25. A non-transitory computer-readable medium having executable instructions embodied therein, the executable instructions being configured to cause a computing device to: Instructions to execute the application; and Respond to calls from the application for information about the processor on the computing device, wherein When the application reports information to the processor upon loading, the application is identified as being written for the processor of the computing device, and information about the processor on the computing device is returned to the application. When the application does not report information to the processor during loading, the application is identified as being written for a legacy processor, and information about the legacy processor is returned to the application, wherein... The information regarding the legacy processor identifies certain features of the processor on the computing device as different from those actually supported by the computing device.

26. The non-transitory computer-readable medium of claim 25, wherein the information regarding the legacy processor identifies certain features of the processor on the computing device as completely unsupported by the processor on the computing device, when in fact those features are supported by the processor on the computing device.

27. The non-transitory computer-readable medium of claim 25, wherein the application program is a legacy application program written for a legacy computing device, and wherein the information about the legacy processor identifies the processor on the legacy computing device.

28. The non-transitory computer-readable medium of claim 25, wherein returning the information about the legacy processor includes using opcodes supported by the architecture of the processor on the computing device.

29. The non-transitory computer-readable medium of claim 25, wherein returning the information about the legacy processor includes using opcodes supported by the x86 architecture.

30. The non-transitory computer-readable medium of claim 25, wherein returning the information about the legacy processor includes using CPUID instructions.

31. The non-transitory computer-readable medium of claim 25, wherein returning the information about the legacy processor includes using microcode stored in ROM or RAM associated with the processor on the computing device.

32. The non-transitory computer-readable medium of claim 25, wherein returning the information about the legacy processor includes using microcode stored in ROM or RAM associated with the processor on the computing device and two different processor ID datasets, one dataset being for a new device application and the other dataset being for a legacy device application.

33. The non-transitory computer-readable medium of claim 25, wherein returning the information about the legacy processor comprises using microcode stored in ROM or RAM associated with the processor on the computing device, and the microcode returns processor ID data, which differs in some detail depending on whether the querying program is a new device application or a legacy device application.

34. The non-transitory computer-readable medium of claim 25, wherein returning the information about the legacy processor includes using one ID program for the legacy application and another ID program for the new device application.

35. The non-transitory computer-readable medium of claim 25, wherein returning the information about the legacy processor includes using dedicated hardware.

36. The non-transitory computer-readable medium of claim 25, wherein, The information about the processor on the computing device or about the legacy processor includes processor model, processor family, cache capacity, translation lookahead buffer capacity, processor serial number, processor brand, processor manufacturer, thread / core topology, cache topology, extension features, virtual address size or physical address size.

Citation Information

Patent Citations

  • Method and Apparatus For Selecting the Architecture Level to Which a Processor Appears to Conform

    US20080168258A1

  • Virtual Machine (VM) Migration Between Processor Architectures

    US20090070760A1