System, method and apparatus for filtering configuration access to non-implemented devices

Abstract

In one embodiment, a device includes a filter to receive a first configuration read access request and direct the first configuration read access request to a first root port, and to receive a second configuration read access request and prevent the second configuration read access request from being sent to a second root port, wherein a target of the first configuration read access request is a deployed device of a system and a target of the second configuration read access request is a non-implemented device of the system. The device also includes a memory in which an identification of the deployed and non-implemented devices is stored. Other embodiments are described and claimed.

Description

BACKGROUND

[0001] Many computing systems interconnect components using industry-standard interconnects such as Peripheral Component Interconnect Express (PCIE) or Compute Express Limited (CXL). In such systems, bus enumeration is a common operation performed by system software, for example, while an operating system initializes a PCIE / CXL hierarchy or installs / uninstalls a device driver. The system software scans the PCIE / CXL bus to determine which devices are actually present. To do this, the system software reads a vendor ID from each possible PCIE / CXL ID. A host bridge returns a value of 1 when attempting to read configuration space registers of nonexistent devices, indicating no functionality.

[0002] However, read accesses to configuration space registers from nonexistent devices result in an unsupported request error. This error is propagated and eventually escalated to a system error, triggering an interrupt. In the case of many nonexistent devices, a large number of errors occur, resulting in an interrupt burst, which causes system performance degradation for correctable errors or a crash for uncorrectable errors. One solution is to disable this error message, but this may impair proper system operation. BRIEF DESCRIPTION OF THE DRAWINGS Fig. 1 is a block diagram of at least a portion of a system according to one embodiment. Fig. 2 is a flowchart of a method according to one embodiment. Fig. 3 is a flowchart of a method according to another embodiment. Fig. 4 is a block diagram of an existing device plan according to one embodiment. Fig. Figure 5 shows an embodiment of a fabric consisting of point-to-point connections that interconnect a number of components. Fig. 6 is a block diagram of a system according to one embodiment. Fig. 7 is a block diagram of a system according to another embodiment. Fig. 8 is a block diagram of another example system according to an embodiment. DETAILED DESCRIPTION

[0003] In various embodiments, a system is configured to prevent read accesses to configuration registers for nonexistent devices by preventing such read accesses from reaching their destinations. This prevents unsupported request errors attributable to nonexistent devices. With this arrangement, a system can keep system-wide unsupported request error reporting enabled and not be overwhelmed by errors that would otherwise be reported as a result of read operations to nonexistent devices.

[0004] In one or more embodiments, filter circuitry may be implemented in a fabric to identify incoming configuration read requests and prevent such read requests from being forwarded to absent devices. Furthermore, this filter circuitry may provide an appropriate response to these filtered read requests. With these embodiments, unsupported request errors can be avoided during PCIE / CXL bus polling. By avoiding these errors, there is no performance degradation during PCIE / CXL bus polling due to unsupported request errors. At the same time, unsupported request error reporting may remain enabled both during system initialization and during normal system operation to increase system availability.

[0005] In one embodiment, this filter circuitry can be implemented in a root complex. This filter circuitry is referred to herein as a fabric filter, which can be used in combination with a memory that manages an existing device map. In a particular embodiment, this memory can consist of one or more registers implemented in the root complex and connected to the fabric filter.

[0006] In this arrangement, firmware, e.g., the Basic Input Output System (BIOS), scans a PCIE fabric behind the root complex during system boot. This check occurs before system error reporting is enabled, so that an unsupported request error occurring at that time has no side effects. After scanning, the BIOS then creates the existing device map (e.g., as stored in one or more registers such as a capability register block of the root complex) and enables the fabric filter. In one embodiment, each device (more precisely, each bus, device, and function (BDF)) in the fabric can be assigned a special bit or other indicator in the existing device map to indicate whether it is present (and thus accessible) or not.

[0007] Once the fabric filter is enabled, the filter receives configuration read requests and, if it detects that a read request is directed to a non-existent device, prevents further processing or sending of the request and instead returns a successful completion to the requester with a data value of 0xFFFF.

[0008] In this way, unsupported request error reporting can be enabled throughout the system, and unsupported request errors can be completely avoided when scanning the PCIE / CXL bus. Unsupported request error reporting can be enabled in a specific system, for example, by appropriately controlling device control registers. In a PCIe example, an enable bit for unsupported error reporting can be set and a mask bit can be reset in a device control register (DevCtl.URRE=1 and Uncerrmsk.UREM=0). With the filter circuitry included here, even when performing a bus scan to a nonexistent device (or bus, or function), no unsupported request error is generated (Uncerrsts.URES=0).

[0009] By allowing a system to keep Unsupported Request Error reporting enabled during normal operation, various errors can be identified. This error reporting mechanism can be used to report, for example, unaligned access to a register block or access to an incorrectly sized register block; unsupported size of a request to a memory region; access to a memory / IO region before memory / IO decoding is enabled; violation of the device's programming model; and invalid request due to flit corruption, to name a few. This allows these normal errors to be addressed to either stop or correct the violation, allowing a system to predict such failures.In contrast, systems without embodiments and if such an error message is deactivated can be damaged unnoticed, which affects system availability.

[0010] In various embodiments, a root complex may be configured to detect when an incoming configuration read access is directed to a nonexistent device and prevent the read operation. Furthermore, the root complex may be configured to send a predetermined response value to a read access requestor to indicate the nonexistence (e.g., a value of FFFFh as described above).

[0011] In this way, existing and non-existent devices (also referred to herein as "implemented" and "unimplemented" devices) can be appropriately identified while preventing unsupported request errors from being reported and logged. Hereinafter, the terms "implemented device" and "unimplemented device" also refer to implemented / unimplemented buses or functions. Therefore, the terms "implemented device" and "unimplemented device" refer more generally to a bus, device, or function. As a result, error-handling techniques, including the generation and handling of interrupts, can be avoided, thus maintaining normal system operation.

[0012] Now referring to Fig. 1 shows a block diagram of at least a portion of a system according to one embodiment. As shown in Fig. 1, the system 100 may be any type of computing device, from a relatively small device such as a smartphone, tablet computer, laptop computer, etc., to larger devices such as desktop computers or other client devices and / or server systems. In the Fig. At the high level illustrated in Figure 1, system 100 is implemented as a PCIE-based system. However, the embodiments are not limited to being applicable to other communication fabrics, such as a CXL-based fabric.

[0013] As in Fig. 1, the system 100 includes a root complex 110. In one or more embodiments, the root complex 110 may be implemented as a semiconductor package with one or more individual dies. In the Fig. 1, the root complex 110 includes a central processing unit (CPU) 115, which may be implemented on one or more chips and may include a plurality of cores and / or other processing circuitry. As further illustrated, the CPU 115 is connected to an address decoder 120. The address decoder 120 may be configured to receive access requests from the CPU 115 and decode the corresponding addresses to identify appropriate targets. In one particular embodiment, the address decoder 120 receives a configuration read request as a memory-mapped input / output (MMIO) request, which it converts into a configuration read transaction layer (TLP) packet and forwards to a corresponding root port associated with a particular device.

[0014] With respect to configuration read requests, the address decoder 120 may, in turn, transmit a decoded address and the corresponding configuration read request to a fabric filter 125. In the present embodiments, the fabric filter 125 may be implemented as hardware circuitry, e.g., register transfer logic (RTL), or other control circuitry to receive and filter such configuration requests or otherwise prevent such requests directed to unimplemented devices from being forwarded, thereby preventing unsupported request errors from being generated.

[0015] To determine whether a particular device is present or not, filter 125 is connected to a register block 130. In one or more embodiments, register block 130 may include a root complex capability register block in accordance with a particular PCIe specification. In certain embodiments, register block 130 may also include a memory section 135 configured to store an existing device map. As described herein, memory section 135 may store a map encoding (with a particular encoding for BDF) to identify existing and non-existent devices.

[0016] As in Fig. 1, the filter 125 may filter out configuration read requests to non-implemented devices based on queries in the register block 130 and instead forward such configuration read requests to implemented devices. In particular, as shown, for a given device, a configuration read request may be directed to a corresponding one of a plurality of root ports 140. a-c be addressed.

[0017] If unsupported request errors or other errors are identified, they are forwarded to an error handler 145, as shown above. In one or more embodiments, the error handler 145 may be configured to signal errors, e.g., by triggering a system management interrupt (SMI) or other interrupt.

[0018] As in Fig. As shown in Figure 1, each root port is connected to a specific device. Specifically, the root port is 140. A connected to a device 150 that has the endpoints 152 A1, A2 contains. The root port 140 B in turn is connected to a switch 160, which has a plurality of point-to-point (P2P) bridges 162 A-C As shown, the endpoints are 165 B1 , B2 connected to switch 160. In addition, root port 140c couples to a hierarchy of switches 170, 180 and 199, each of which contains P2P bridges (172 A-C , 182 A-C , 192 A-C ) and coupled endpoints 185 C1, C2 and 195 C3 Although in the embodiment of Fig. 1 presented at this high level, many variations and alternatives are possible.

[0019] Fig. 2 shows a flowchart of a method in accordance with one embodiment. As in Fig. 2, the method 200 is a method for identifying existing and non-existent devices according to one embodiment, which may be performed during system boot, e.g., by the Basic Input / Output System (BIOS) or other firmware. As such, the method 200 may be performed by hardware circuitry such as a CPU executing the BIOS or other firmware. In other cases, the method 200 may be executed by the BIOS or other system software on the CPU. As illustrated, the method 200 begins by initiating a system boot (block 210), which may occur upon system power-on or other reset. During the boot process, a scan of a fabric connected to a root complex is performed in block 220. For example, the BIOS may perform a PCIe fabric scan. During this scan, a CPU may send configuration read requests to obtain values ​​such asTo read vendor IDs at any possible ID position (e.g., BDF positions). As mentioned earlier, existing devices can return their vendor ID in response to these configuration read requests, while for non-existent devices, a corresponding host bridge can send a completion with the Unsupported Request (UR) flag. The root complex circuit, in turn, can synthesize a completion message with a predefined value (e.g., 0xFFFF). Note that such an operation can also trigger the logging of Unsupported Request errors. However, in this pre-boot environment, such errors can be ignored.

[0020] As in Fig. 2, in the next block 230, the present and non-existent devices (as enumerated by BDF) are identified based on these responses. Based at least in part on this information, in block 240, an existing device map is written to the root complex (e.g., by the BIOS). More specifically, this existing device map may be written in coded form to registers of a capability register space of the root complex. Finally, in block 250, a fabric filter may be activated. As described above, this fabric filter may be used to prevent configuration read values ​​from being sent to absent devices, thereby avoiding unsupported request errors and corresponding error reporting. It should be understood that, although in the embodiment of Fig. 2 shown at this high level, many variations and alternatives are possible.

[0021] Fig. 3 shows a flowchart of a method according to another embodiment. More specifically, the method 300 of Fig. 3 is a filtering method designed to prevent configuration read accesses from being directed to absent devices. In one embodiment, method 300 may be performed by a hardware circuit, such as a fabric filter, which may be implemented in a particular root complex.

[0022] As shown, method 300 begins with the receipt of a configuration read access request (block 310). This configuration read request may be an MMIO configuration read request received from a CPU. At diamond 320, a determination is made as to whether the fabric filter is enabled. This is because, in typical implementations, this filter is disabled by default after a system reset and then enabled by the BIOS or other firmware after scanning the bus and creating the existing device image. If the filter is not enabled, control transfers to block 350, where the configuration read request may be forwarded to the intended destination according to an address decoding function (which may be performed by an address decoder coupled to the fabric filter).It should be understood that a particular device (if any) may respond to this configuration read request by sending a vendor ID and / or other information, such as the contents of any register in the device's configuration space. In the case of an unimplemented device, a bridge component may send a value of 0xFFFF (and additional circuitry may log and trigger an Unsupported Request error).

[0023] If it is determined that the fabric filter is enabled, control is passed to block 330 (see Fig. 3). In block 330, the fabric filter may access a location in an existing device map to determine whether the given device is present. In one embodiment, a set bit at a corresponding location in the existing device map indicates that the device is present, and a zero value indicates that it is not present.

[0024] Depending on the returned value, diamond 340 determines whether this bit is set or not, and control is passed to one of blocks 350 and 360. Thus, if the device is present, the configuration read request is forwarded to the device, while if the device is absent, control passes to block 360, where the fabric filter can send a predetermined value, e.g., 0xFFFF, to the requester. Although in the embodiment of Fig. 3 presented at this high level, many variations and alternatives are possible.

[0025] In Fig. 4 is a block diagram of an existing device plan according to one embodiment. As shown in Fig. 4, the device map 400 can be stored in a plurality of registers 4100-410 1023 In the embodiment shown, each register provides 64 bits of storage space. In one or more embodiments, the Fig. be a coded mapping in which each bit corresponds to a specific BDF identifier. When the bit is set, it indicates the presence of the BDF, and when reset, it indicates its absence.

[0026] In one embodiment, the bit position for a particular BDF may be determined according to the following equation: Bit position=x*32*8+y*8+z, where x represents the bus number, y represents the device number, and z represents the function number. Thus, each register corresponds to bit position / 64, and a specific bit in a register corresponds to bit position MOD 64. Of course, other encodings are also possible in other embodiments.

[0027] For a hot-pluggable root port that has no device connected during system boot, the BIOS can force the disabling of Unsupported Request Error Reporting (URRE) by, for example, setting a device control register to disable this feature and configuring the existing device mapping to assume all devices are present behind the root port. Later during operating system operation, when a hot-plug event occurs, the BIOS can correct the existing device mapping and re-enable URRE by attaching an ACPI hot-plug method.

[0028] The embodiments can be used in a variety of systems. Referring to Fig. Figure 5 illustrates one embodiment of a fabric consisting of point-to-point interconnects connecting a set of components. System 500 includes a processor 505 and system memory 510 coupled to controller hub 515. Processor 505 includes any processing element, such as a microprocessor, a host processor, an embedded processor, a coprocessor, or another processor. Processor 505 is coupled to controller hub 515 via interconnect 506, such as an Intel® UPI point-to-point serial interconnect.

[0029] System memory 510 includes any memory device, such as random access memory (RAM), non-volatile (NV) memory, or other memory accessible by the devices in system 500. System memory 510 is coupled to controller hub 515 through memory interface 516. Examples of a memory interface include a double data rate (DDR) memory interface, a dual-channel DDR memory interface, and a dynamic RAM (DRAM) memory interface.

[0030] In one embodiment, controller hub 515 is a root hub, root complex, or root controller in a PCIe interconnect hierarchy. Controller hub 515 may include filter circuitry and memory for an existing device map, as described herein.

[0031] Examples of a controller hub 515 include a chipset, a memory controller hub (MCH), a northbridge, an interconnect controller hub (ICH), a southbridge, and a root controller / hub. Often, the term chipset refers to two physically separate controller hubs, i.e., a memory controller hub (MCH) coupled to an interconnect controller hub (ICH). Note that current systems often include the MCH integrated into the processor 505, while the controller 515 must communicate with I / O devices in a manner similar to that described below. In some embodiments, peer-to-peer routing is optionally supported by a root complex 515.

[0032] Here, controller hub 515 is coupled to switch / bridge 520 via a serial connection 519. Input / output modules 517 and 521, which may also be referred to as interfaces / ports 517 and 521, contain / implement a layered protocol stack to provide communication between controller hub 515 and switch 520. In one embodiment, multiple devices may be coupled to switch 520. Switch / bridge 520 is connected to a device 525 via a connection 523 (e.g., a USB4 connection) through corresponding interfaces / ports 522 and 526.

[0033] The switch / bridge 520 routes packets / messages from the device 525 upstream, i.e., upward in a hierarchy toward a root complex, to the controller hub 515 and downstream, i.e., downward in a hierarchy away from a root controller, from the processor 505 or system memory 510 to the device 525. The device 525 may be any peripheral device, including an internal or external device or component, that can be connected to an electronic system, e.g., via a USB4 or other serial interface that enables communication of one or more tunneled protocols, according to one embodiment.The device 525 may be an I / O device, a network card, an audio processor, a network processor, a memory expansion, a hard drive, a storage device such as a solid-state drive, a CD / DVD-ROM, a monitor, a printer, a mouse, a keyboard, a router, a portable storage device, a Firewire device, a USB device, a scanner, and other input / output devices.

[0034] Graphics accelerator 530 is also coupled to controller hub 515 through a serial connection 532. In one embodiment, graphics accelerator 530 is coupled to an MCH, which is coupled to an ICH. Switch 520, and accordingly, I / O device 525, is then coupled to the ICH. I / O modules 531 and 518 are also intended to implement a layered protocol stack to communicate between graphics accelerator 530 and controller hub 515. A graphics controller or graphics accelerator 530 itself may be integrated into processor 505.

[0035] Fig. 6 is a block diagram of a system according to one embodiment. As shown in Fig. 6, a device 605 may be an accelerator or a processor device connected to a host processor 645 via an interconnect 689, which may be a link, a bus, a lane, etc. The device 605 and the host processor 645 may communicate via the interconnect 689 so that data and messages may be exchanged between them. In some embodiments, the interconnect 689 may be operable to support multiple protocols and the communication of data and messages over the various interconnect protocols, including a Compute Express Link (CXL) protocol according to one or more CXL specifications. For example, the interconnect 689 may support various interconnect protocols, including a non-coherent interconnect protocol, a coherent interconnect protocol, and a storage interconnect protocol.Non-limiting examples of supported connection protocols may include PCI, PCIe, USB, IDI, IOSF, SMI, SMI3, SATA, CXL.io, CXL.cache and CXL.mem and / or similar.

[0036] In certain embodiments, device 605 may include an accelerator 625 with circuitry 629. In some cases, accelerator 625 and circuitry 629 may provide processing and storage capabilities. Examples of devices 605 may include producer-consumer devices such as graphics or other specialized accelerators, producer-consumer-plus devices, software-assisted device storage devices, autonomous device storage devices, and giant cache devices. In some cases, accelerator 625 may be coupled with an optional accelerator memory 630. Accelerator 625 and circuitry 629 may provide the processing and storage capabilities based on the device.For example, the accelerator 625 and circuitry 629 may communicate with the host processor 645 via the interface logic 613 and circuitry 627 using a coherent interconnect protocol for various functions such as coherent requests and memory flows.

[0037] In some embodiments, protocol queue 612 may be protocol-specific, allowing each connection protocol to be associated with a specific protocol queue. Multiplexer 610 may also implement arbitration circuitry to arbitrate between communications of different protocols and deliver selected communications to a physical layer 615.

[0038] In various embodiments, host processor 645 may be a main processor, such as a CPU. Host processor 645 may be connected to host memory 640 via interface logic 663, which includes circuitry 661. In one or more embodiments, circuitry 661 may include filtering circuitry and existing device map storage, as described herein, to enable filtering of configuration read requests to absent BDFs. Host processor 645 may also include coherency and caching circuitry 655, which may include a cache hierarchy. Circuitry 655 may communicate with one or more cores 665a-n. In some embodiments, circuitry 655 may enable communication via one or more coherent interconnect protocols (e.g., CXL.cache) and a memory interconnect protocol (e.g., CXL.mem).

[0039] In various embodiments, host processor 640 may include a device 670 for communicating with PCIe circuitry 660 via an interconnect. In some embodiments, device 670 may be an I / O device, such as a PCIe I / O device. In other cases, one or more external devices, such as PCIe devices, may be connected to PCIe 670.

[0040] In some embodiments, the host processor 645 may enable multi-protocol communication between the components of the host processor 645 and the device 605. For this purpose, the circuits 655 and 660 (collectively), as shown in Fig. 6, one or all of the CXL.io / PCIe, CXL.cache, and / or CXL.memory traffic may communicate with a multiplexer 650 having one or more protocol queues 652 to send and receive messages and data with the device 605.

[0041] The protocol queue 652 may be protocol-specific, allowing each connection protocol to be assigned to a specific protocol queue. The multiplexer 650 may also implement arbitration circuitry to arbitrate between communications of different protocols and deliver selected communications to a physical layer 654.

[0042] Fig. 7 shows a block diagram of a system according to another embodiment. As in Fig. 7, a system 700 may be any type of computing device, and in one embodiment, it may be a server system such as an edge platform. In the embodiment of Fig. 7, the system 700 includes multiple CPUs 710a, b, which in turn are connected to respective system memories 720a, b, which in embodiments may be implemented as DDR (Double Data Rate) memory. The CPUs 710 may implement root complex circuitry including a filter and memory for an existing device map as described herein. Note that the CPUs 710 may be interconnected via an interconnect system 715 such as Intel® Ultra Path Interconnect or other processor interconnect technology.

[0043] To enable coherent accelerator devices and / or intelligent adapter devices to be coupled to CPUs 710 via potentially multiple communication protocols, a plurality of interconnect lines 730a1-b2 may be present. In one embodiment, each interconnect 730 may be a specific example of a CXL interconnect.

[0044] In the embodiment shown, the respective CPUs 710 are coupled to the corresponding field-programmable gate arrays (FPGAs) / accelerators 750a,b, in one embodiment. Furthermore, the CPUs 710 are also connected to the intelligent network interfaces (NICs) 760a,b. The intelligent NIC devices 760a,b are in turn connected to switches 780a,b, which in turn are connected to a pooled memory 790a,b, e.g., a persistent memory. As shown, the information may be stored in a pooled memory 790. The CPUs 710 or other devices may, in turn, access and further process this information from the pooled memory 790. Furthermore, the CPUs 710 may be coupled to an optional remote memory 795.

[0045] Fig. 8 shows a block diagram of another example system according to an embodiment. In Fig. 8, the system 800 may consist entirely or partially of a rack-based server with multiple hosts in the form of computing drawers that can be connected to pooled storage via one or more switches.

[0046] As shown, multiple hosts 830-1-n (also referred to herein as "hosts 830") are present. Each host can be implemented as a compute drawer containing one or more SoCs (which can be implemented as multi-die packages with root complexes containing filter circuitry and memory for an existing device map, as described herein), memory, storage, interface circuitry, etc. In one or more embodiments, each host 830 can contain one or more virtual hierarchies corresponding to different cache coherency domains. The hosts 830 can be coupled to a switch 820, which can be implemented as a CXL switch (e.g., a CXL 2.0 (or higher) switch). In one embodiment, each host 830 can be coupled to the switch 820 using a non-packet interconnect, e.g., a Universal Chiplet Interconnect Express (UCIe) interconnect using a CXL protocol.

[0047] The switch 820 can be coupled with multiple 810-1-x devices (also referred to herein as "device 810"), each of which can be a storage device (e.g., a Type 3 CXL storage expansion device) and / or an accelerator. In the figure of Fig.8, each device 810 is depicted as a Type 3 storage device with any number of memory regions (e.g., defined partitions, memory regions, etc.). Depending on the configuration and use case, certain devices 810 may include memory regions assigned to specific hosts, while others may include at least some memory regions referred to as shared memory. Although embodiments are not limited in this regard, the memory included in devices 810 may be implemented with any type of computer memory (e.g., dynamic random access memory (DRAM), static random access memory (SRAM), non-volatile memory (NVM), a combination of DRAM and NVM, etc.).

[0048] The following examples relate to further embodiments.

[0049] In one example, a device comprises: a filter to receive a first configuration read access request and direct the first configuration read access request to a first root port, and to receive a second configuration read access request and prevent the second configuration read access request from being sent to a second root port, wherein a target of the first configuration read access request is an implemented device of a system and a target of the second configuration read access request is an unimplemented device; and a memory coupled to the filter, wherein the memory is to store an identification of implemented devices and unimplemented devices.

[0050] In one example, the filter should access memory to determine whether a first device, which is the target of the first configuration read access request, is implemented in the system.

[0051] In one example, the memory comprises a plurality of registers, each register storing a plurality of presence values, each of the plurality of presence values ​​indicating whether a particular BDF identifier is implemented in the system.

[0052] In one example, the memory should store a map to identify the implemented and unimplemented devices.

[0053] In one example, the mapping is encoded according to 32x8y+z, where x corresponds to a bus identifier, y to a device identifier, and z to a function identifier.

[0054] In one example, the device comprises a root complex containing the filter and the memory, wherein the memory comprises at least one configuration register of the root complex.

[0055] In one example, in response to the second configuration read access request to the non-implemented device, the filter is to send a predetermined value to a requestor of the second configuration read access request.

[0056] In one example, the default value is 0xFFFF.

[0057] In one example, the device includes an error mask register, wherein an unsupported request error indicator of the error mask register is to remain enabled during a boot process and during normal operation.

[0058] In one example, an agent performs a bus scan during boot to identify the presence of deployed devices and the absence of unimplemented devices; and, in response to the identification, write an existing device map to memory.

[0059] In one example, if the device is deployed in a hot-plug system, the agent should write the existing device map to indicate that all deployed and undeployed devices are present.

[0060] In one example, the agent should receive a vendor ID from the deployed devices during the bus scan, obtain unsupported request indicators for the unimplemented devices, and write the existing device map based on this.

[0061] In another example, a computer-readable medium containing instructions is operable to perform the method of any of the above examples.

[0062] In another example, a computer-readable medium containing data is to be used by at least one machine for manufacturing at least one integrated circuit to perform the method of any of the above examples.

[0063] In a further example, an apparatus comprises a device for carrying out the method of one of the above examples.

[0064] In another example, a method comprises: receiving a configuration read for a first BDF in a root complex of a system; accessing a memory to identify whether the first BDF is present in the system; in response to identifying that the first BDF is present in the system, sending the configuration read to the first BDF; and in response to identifying that the first BDF is not present in the system, sending a predetermined value to a source of the configuration read.

[0065] In one example, the method further comprises accessing the memory comprising a mapping stored in a register memory of the root complex.

[0066] In one example, the method further comprises writing the map to the register memory based at least in part on a scan of a fabric connected to the root complex during a pre-boot environment.

[0067] In one example, the method further comprises enabling unsupported error reporting during system startup and maintaining unsupported error reporting during operation of the system.

[0068] In one example, the method further comprises, in response to determining that the second BDF is absent from the system, preventing the configuration read value from being sent to the second BDF at a root port connected to the second BDF.

[0069] In another example, a system comprises: a root complex comprising: at least one CPU; a plurality of root ports for coupling to one or more devices; an address decoder coupled to the at least one CPU and decoding an address of a configuration read request; a filter coupled to the address decoder, the filter receiving the configuration read request and the decoded address and preventing the configuration read request from being directed to a root port associated with the decoded address if a device is not present at the decoded address; and memory coupled to the root complex, wherein the memory is configurable to communicate with the root complex using a Compute Express Link (CXL) protocol.

[0070] In one example, the root complex further comprises a memory for storing an existing device map having a plurality of presence values, each of the plurality of presence values ​​indicating whether a particular bus device function (BDF) is present in the system.

[0071] In one example, the filter is further to send a predetermined value to the at least one CPU in response to the configuration read request if the device is not present at the decoded address.

[0072] In another example, an apparatus comprises: means for receiving a configuration read value for a first BDF device; means for accessing a storage device to identify whether the first BDF device is present in a system; means for sending the configuration read value to the first BDF device in response to identifying that the first BDF device is present in the system; and means for sending a predetermined value to a source of the configuration read value in response to identifying that the first BDF device is not present in the system.

[0073] In one example, the apparatus further comprises the storage device comprising a map stored in a register storage device of a root complex device.

[0074] In one example, the apparatus further comprises means for writing the map to the register storage means based at least in part on a scan of a fabric device coupled to the root complex device during a pre-boot environment.

[0075] In one example, the apparatus further comprises means for enabling unsupported error reporting during system startup and means for maintaining unsupported error reporting during operation of the system.

[0076] In one example, the apparatus further comprises means for preventing the configuration read into the second BDF device from being sent to the root port device associated with the second BDF device if it is determined that the second BDF device is not present in the system.

[0077] You should know that different combinations of the above examples are possible.

[0078] The terms "circuit" and "circuitry" are used interchangeably herein. As used herein, these terms and the term "logic," individually or in any combination, refer to analog circuits, digital circuits, hard-wired circuits, programmable circuits, processor circuits, microcontroller circuits, hardware logic circuits, state machine circuits, and / or any other type of physical hardware components. The embodiments may be used in many different types of systems. For example, in one embodiment, a communications device may be configured to perform the various methods and techniques described herein.Of course, the scope of the present invention is not limited to a communications device, and instead, other embodiments may be directed to other types of devices for processing instructions or to one or more machine-readable media containing instructions that, in response to execution on a computing device, cause the device to perform one or more of the methods and techniques described herein.

[0079] Embodiments may be implemented in code and stored on a non-transitory storage medium that stores instructions that can be used to program a system to execute the instructions. Embodiments may also be implemented in data and stored on a non-transitory storage medium that, when used by at least one machine, causes the at least one machine to fabricate at least one integrated circuit to perform one or more operations. Further embodiments may be implemented in a computer-readable storage medium that contains information that, when incorporated into a SOC or other processor, configures the SOC or other processor to perform one or more operations.The storage medium can be any type of disk, including floppy disks, optical discs, solid-state drives (SSDs), compact disc read-only memories (CD-ROMs), rewritable compact disc read-only memories (CD-RWs), and magneto-optical disks, semiconductor devices such as read-only memories (ROMs), random access memories (RAMs) such as DRAMs (Dynamic Random Access Memories), SRAMs (Static Random Access Memories), EPROMs (Erasable Programmable Read-Only Memories), flash memory, EEPROMs (Electrically Erasable Programmable Read-Only Memories), magnetic or optical cards, or any other type of media suitable for storing electronic instructions.

[0080] Although the present disclosure has been described with respect to a limited number of implementations, those skilled in the art, having the benefit of this disclosure, will appreciate numerous modifications and variations thereof. The appended claims are intended to cover all such modifications and variations.

Claims

[1] Device comprising: a filter to receive a first configuration read access request and direct the first configuration read access request to a first root port, and to receive a second configuration read access request and prevent the second configuration read access request from being sent to a second root port, wherein a target of the first configuration read access request is an implemented device of a system and a target of the second configuration read access request is an unimplemented device; and a memory coupled to the filter that stores an identification of implemented and unimplemented devices. [2] The apparatus of claim 1, wherein the filter is to access the memory to detect whether a first device comprising the target of the first configuration read access request is implemented in the system. [3] The apparatus of claim 3, wherein the memory comprises a plurality of registers, each register storing a plurality of presence values, each of the plurality of presence values ​​indicating whether a particular Bus Device Function (BDF) identifier is implemented in the system. [4] The apparatus of claim 2, wherein the memory is for storing a map to identify the implemented devices and the unimplemented devices. [5] The device of claim 4, wherein the mapping is encoded according to 32x8y+z, where x corresponds to a bus identifier, y to a device identifier, and z to a function identifier. [6] The apparatus of claim 1, wherein the apparatus comprises a root complex comprising the filter and the memory, the memory comprising at least one root complex configuration register. [7] The apparatus of claim 1, wherein in response to the second configuration read access request to the unimplemented device, the filter is to send a predetermined value to a requestor of the second configuration read access request. [8] The apparatus of claim 7, wherein the predetermined value comprises 0xFFFF. [9] The apparatus of claim 1, wherein the apparatus comprises an error mask register, wherein an unsupported request error indicator of the error mask register is to remain enabled during a boot process and during normal operation. [10] The apparatus of claim 1, wherein an agent performs a bus scan during startup to cause: Identifying the presence of implemented devices and the absence of non-implemented devices; and In response to the identification, writing an existing device image to memory. [11] The device of claim 10, wherein, when the device is implemented in a hot-plug system, the agent shall write the present device map to indicate that all implemented and unimplemented devices are present. [12] The apparatus of claim 10, wherein the agent receives a vendor ID from the deployed devices during the bus scan, receives unsupported request indicators for the unimplemented devices, and writes the existing device map based thereon. [13] Procedure comprising: Receiving, in a root complex of a system, a configuration read value for a first bus device function (BDF); Accessing a memory to determine whether the first BDF exists in the system; in response to identifying that the first BDF is present in the system, sending the configuration read value to the first BDF; and in response to determining that the first BDF is not present in the system, sending a predetermined value to a configuration read source. [14] The method of claim 13, further comprising accessing the memory comprising a map stored in a register memory of the root complex. [15] The method of claim 14, further comprising writing the map to the register memory based at least in part on a scan of a fabric connected to the root complex during a pre-boot environment. [16] The method of claim 13, further comprising enabling unsupported error reporting during system startup and maintaining unsupported error reporting during operation of the system. [17] The method of claim 13, further comprising, in response to determining that a second BDF is not present in the system, preventing a configuration read value relating to the second BDF from being sent to a root port connected to the second BDF. [18] System comprising: a root complex that includes: at least one central processing unit (CPU); a variety of root ports for connecting to one or more devices; an address decoder coupled to the at least one CPU to decode an address of a configuration read request; a filter coupled to the address decoder, the filter receiving the configuration read request and the decoded address and preventing the configuration read request from being directed to a root port associated with the decoded address if a device is not present at the decoded address; and a storage coupled to the root complex that can be configured to communicate with the root complex using a Compute Express Link (CXL) protocol. [19] The system of claim 18, wherein the root complex further comprises a memory to store an existing device map having a plurality of presence values, each of the plurality of presence values ​​indicating whether a particular bus device function (BDF) is present in the system. [20] The system of claim 18, wherein the filter further sends a predetermined value to the at least one CPU in response to the configuration read request if the device is not present at the decoded address. [21] Device comprising: Means for receiving a configuration read value for a first setup of the bus device function (BDF); Means for accessing a storage device to determine whether the first BDF device is present in a system; means for sending the read configuration to the first BDF device in response to determining that the first BDF device is present in the system; and Means for sending a predetermined value to a source of the configuration read value in response to identifying that the first BDF device is not present in the system. [22] The apparatus of claim 21, wherein the storage means comprises a map stored in a register storage means of a root complex means. [23] The apparatus of claim 22, further comprising means for writing the map to the register storage means based at least in part on a scan of the fabric device coupled to the root complex device during a pre-boot environment. [24] The apparatus of claim 21, further comprising: Facility to enable unsupported error reporting during system startup; and Facility to maintain unsupported error reporting during system operation. [25] The apparatus of claim 21, further comprising means for preventing a configuration read into a second BDF device from being sent to a root port device associated with the second BDF device if it is determined that the second BDF device is not present in the system.

Images