CN113220238A

CN113220238A - Method for realizing universal SAS controller interface

Info

Publication number: CN113220238A
Application number: CN202110549757.6A
Authority: CN
Inventors: 宫晓渊; 刁永翔; 张辅云
Original assignee: Wuxi Zhongxing Microsystem Technology Co ltd
Current assignee: Wuxi Zhongxing Microsystem Technology Co ltd
Priority date: 2021-05-19
Filing date: 2021-05-19
Publication date: 2021-08-06
Anticipated expiration: 2041-05-19
Also published as: CN113220238B

Abstract

The invention provides a method for realizing a universal SAS controller interface, which comprises the following steps: defining a programming interface register set in an SAS controller, wherein the programming interface register set comprises a target equipment list base address register, a target equipment list length register, an I/O request submitting register and an I/O request completing register; defining a programming interface list in a system memory, wherein the programming interface list comprises a target device list, an I/O request list and an I/O data description list; and providing a programming interface for operating the SAS controller for system software based on the programming interface register set and the programming interface list. The invention supports data communication of various protocol types in an SAS application scene, unifies system programming interfaces and simplifies the software use mode.

Description

Method for realizing universal SAS controller interface

Technical Field

The invention belongs to the field of disk reading and writing, and particularly relates to a method for realizing a universal SAS controller interface.

Background

Sas (serial Attached SCSI), i.e., serial Attached SCSI interface, is a new generation of SCSI technology, and adopts a point-to-point transmission mode, a data/command verification unit is built in, the error correction capability is strong, hot plug is supported, and the serial Attached SCSI interface has the characteristics of a small number of pins, a high data transmission rate, high reliability, good compatibility, and the like, and is widely used in the industry for a main I/O interface between a storage device and a host at present.

In order to complete high-speed transmission of end-to-end data, the SAS standard protocol defines different protocol stack layers, and implements data encapsulation, encoding, and conversion of high-speed interface physical signals. FIG. 1 illustrates a typical controller implementation supporting SAS standard protocols, with the main components illustrated as follows:

the physical layer L1 includes functional modules such as 8b-10b codec, BMC codec, OOB signal generation and detection, and data boundary synchronization, and implements the establishment of an end-to-end physical link and negotiation of a transmission rate. The link layer L2 is used to create various primitives and address frames to enable end-to-end device identification, connection management, rate matching, clock compensation, transport layer data CRC generation and verification, and data scrambling. Port layer L3 is used to process transport layer data requests and is responsible for physical port selection, connection management, and scheduling of SAS frame transceiving. The transport layer L4 encapsulates the application layer data into an SAS frame of a specific format according to a protocol in the transmitting direction, and parses the received remote SAS frame in the receiving direction. The frame buffer L5 is used to buffer data sent by the application layer and data parsed by the transport layer. The DMA L6 is responsible for data movement between host system storage and the frame buffer storage unit of the SAS controller. Controller interface L7, the interactive interface between the SAS controller and the host system, defines the programming method by which system software operates the SAS controller.

However, the SAS standard protocol does not define the implementation method of the controller interface, and lacks a uniform system software programming interface definition. As such, different controller designers often customize the usage of SAS controllers in a private manner, and different interface definitions are very different, which results in a complex system software development process, poor portability, and incompatibility of controller system software between manufacturers.

Disclosure of Invention

The invention aims to provide a method for realizing a universal SAS controller interface, which supports data communication of three protocol types of SSP, SMP and STP under an SAS application scene, unifies a system programming interface, simplifies a software use mode and improves the SAS transmission efficiency. The method for realizing the universal SAS controller interface comprises the following steps:

defining a programming interface register set in the SAS controller, wherein the programming interface register set comprises a target equipment list base address register, a target equipment list length register, an I/O request submitting register and an I/O request completing register;

defining a programming interface list in a system memory, wherein the programming interface list comprises a target device list, an I/O request list and an I/O data description list;

providing the system software with a programming interface to operate a SAS controller based on the set of programming interface registers and the list of programming interfaces.

Preferably, the target device list base address register is configured to identify a base address of the target device list, and the SAS controller obtains address information of a SAS target device description block according to the base address.

Preferably, the SAS target device description block includes a device type, a connection rate, a target device index number, and a SAS Address field, and provides construction information of an opaf (open Address frame) Address frame.

Preferably, the target device list length register is used to define the number of SAS target device description blocks.

Preferably, the I/O request submission register is configured to receive an SAS I/O request submitted by the system software, and send the request to an SAS controller.

Preferably, the I/O request completion register is used to receive a message from the SAS controller to notify the system software of a completed SAS I/O request.

Preferably, the SAS target device description block further comprises a SAS I/O request list base address field and a SAS I/O request list length field, the SAS I/O request list base address field indicating where the SAS I/O request list is stored in system physical memory; the SAS I/O request list length field indicates the number of I/O request description blocks in the SAS I/O request list.

Preferably, the I/O request description block includes fields of a protocol type, an IO request type, and a request index number, and construction information of various types of I/O frames.

Preferably, the plurality of types of I/O frames include at least one of: an SSP command frame, an SSP task frame, an SMP request frame, a SATA PIO command frame, a SATA DMA command frame, and an SATA FPDMA command frame.

Preferably, the I/O request description block further includes an I/O data description table physical base address field and an SGL list length field, where the I/O data description table physical base address field indicates a physical location where the current I/O data description table is stored in the system memory, the SGL list length field indicates the number of entries in the SGL list, and the SGL list is a linked list DMA descriptor list.

Compared with the prior art, the invention has the following advantages:

through a group of registers and a memory data structure, the method realizes the universal interaction between system software and hardware logic of the SAS controller, supports data communication of various protocol types in an SAS application scene, unifies a programming interface of the system software, enhances the universality of the SAS controller, reduces the integration complexity and saves the development cost of the system software.

Additional features and advantages of the invention will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by the practice of the invention. The objectives and other advantages of the invention will be realized and attained by the structure particularly pointed out in the written description and claims hereof as well as the appended drawings.

Drawings

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, and it is obvious that the drawings in the following description are some embodiments of the present invention, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without creative efforts.

FIG. 1 illustrates a block diagram of an exemplary controller implementation supporting SAS standard protocols in accordance with the prior art.

FIG. 2 illustrates a general SAS controller interface and memory data architecture in accordance with the present invention.

Fig. 3 is a diagram illustrating field information of a SAS target device description block stored in a SAS target device list according to the present invention.

FIG. 4 is a diagram illustrating field information of a SAS I/O request description block stored in a SAS I/O request list in accordance with the present invention.

FIG. 5 is a diagram illustrating field information of an I/O request command frame stored by a SAS I/O data description table in accordance with the present invention.

Fig. 6 is a diagram illustrating a PRD descriptor structure of a command frame information field in an I/O data description table according to the present invention.

FIG. 7 illustrates a schematic diagram of a typical SAS storage topology according to the prior art.

FIG. 8 illustrates a flow chart of a process by which system software builds a SAS target device list and a SAS I/O request list in memory in accordance with the present invention.

FIG. 9 is a flowchart illustrating a process for system software to issue an I/O request to a particular SAS target device in accordance with the present invention.

FIG. 10 illustrates a process flow diagram for a SAS controller processing an I/O request in accordance with the present invention.

Detailed Description

In order to make the objects, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are some, but not all, embodiments of the present invention. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.

As shown in fig. 2, the method for implementing a universal SAS controller interface according to the present invention defines an interaction method between system software and SAS controller hardware logic through a set of registers and a memory data structure, and unifies a programming interface of the system software, so as to enhance the versatility of the SAS controller.

Firstly, the definition of the following registers is added in the general SAS controller interface, and the definition comprises the following steps:

stdlba (SAS Target Description List Base address), that is, a SAS Target device List Base address register, where the address is a 64-bit physical address used to identify a physical Base address of the SAS Target device List. The SAS controller acquires address information of the SAS target equipment description block according to the base address;

stdll (SAS Target Description List length), that is, a SAS Target device List length register, configured to define the number of device Description blocks in a SAS Target device List;

SIORS (SAS I/O Request Submission), namely an SAS I/O Request Submission register, through which system software submits a new SAS I/O Request to the SAS controller;

SIORC (SAS I/O Request Completion), a SAS I/O Request Completion register through which SAS controller hardware logic notifies system software that a completed SAS I/O Request has been executed;

secondly, the following key data structures are defined in the system memory at the same time, including:

stdl (SAS Target Description list), that is, SAS Target device list, the SAS controller allocates one device Description block for each SMP, SSP, or STP device under management. The length of the equipment list is dynamically changed according to the number of target equipment in the current equipment connection topological structure;

SIORL (SAS I/O Request List), i.e., SAS IO Request List, where each active device in the SAS target device List STDL corresponds to an I/O Request List SIORL, indicating the I/O Request for the interaction between the SAS controller and the current target device. The length of the I/O request list SIORL is determined according to the maximum I/O request concurrency number which can be supported by the current target equipment;

a SAS I/O Data Description Table (SAS I/O Data Description Table), which represents the content of the related command frame, the reception of the response frame, and the source or storage location of the Data segment information in the SAS IO request interaction;

the SAS target device list STDL occupies a continuous physical address space in a system memory, and stores SAS target device description blocks, which maximally supports 65536 devices. The format and size of each description block are fixed, 8 dwords are occupied, and the specific field information is shown in fig. 3, wherein:

v (valid) is a 1-bit valid bit field (hereinafter referred to as V bit) for identifying whether the current target device description block is valid;

dt (device type) is a target device type field, has a length of 4 bits, and indicates the SAS end device type indicated by the current device description block, i.e., SMP, SSP, or STP end device;

MCR (Max Connection rate) is a field of the maximum Connection rate supported by the current equipment, and the length of the field is 4 bits;

an ICT (initiator Connection tag) is a field of a target device index number, has a length of 16 bits, and represents the position of a current device description block in a target device list STDL;

SIORLL (SAS I/O Request List Length) is a Length field of an SAS I/O Request List SIORL of the target device, the Length is 16 bits, and the number of I/O Request description blocks in the SAS IO Request List SIORL is represented;

the SAS Address is an SAS physical Address field of the target equipment, and the length of the SAS Address is 64 bits;

SIORLBA (SAS I/O Request List Base Address) is an SAS I/O Request List Base Address field of the target device, has the length of 64 bits and represents the storage position of the SAS I/O Request List in a system physical memory;

rsvd is a reserved field;

the SAS target equipment list supports three equipment types of Expander, SATA disk and SAS disk; and dynamic hot plug of subordinate SAS target equipment is supported.

The SAS I/O request list SIORL occupies a continuous physical address space in a system memory, and a SAS I/O request description block of a current target device is stored in the list. According to the SAS protocol, a maximum of 65536I/O request concurrencies are supported per target device. I/O request data access supports 64-bit addressing; compatible with the NCQ mode in the SATA protocol. The format and size of each description block are fixed, 8 Dwords are occupied, and the specific field information is shown in FIG. 4, wherein:

v (valid) is a 1-bit valid bit for identifying whether the current I/O request description block is valid;

pt (protocol type) is a protocol type field, length 4 is a bit, and indicates a protocol to which the current I/O request belongs, and the specific meanings are as follows:

a)0 h: SMP (Serial Management Protocol, sub-Protocol of SAS standard)

b)1 h: SSP (Serial SCSI Protocol, sub-Protocol of SAS standard)

c)2 h: STP (SATA Tunnel Protocol, sub-Protocol of SAS standard)

d) And others: retention

RT (request type) is a type field of the current I/O request, the length is 4 bits, and the specific meanings are as follows:

a)0 h: SSP Command Command frame

b)1 h: SSP Task frame

c)2 h: SMP Request frame

d)3 h: STP PIO command frame

e)4 h: STP DMA command frame

f)5h：STP Non-Data

g)6 h: STP FPDMA command frame

h) And others: retention

C (command Store mode) is an I/O request command storage mode field, is 1 bit long (hereinafter referred to as C bit), is valid for the SSP and SMP protocols, and represents a storage mode of a current I/O request command frame IU (Information Unit, Payload of SSP frame), and is specifically as follows:

a)0b 0: content information indicating a CFIU section of the I/O data description table stores a command frame IU;

b)0b 1: a PRD (Physical Region Description) descriptor representing that a CFIU segment of an I/O data Description table stores a command frame IU, a storage location of contents of the command frame IU being described by the PRD;

r (response Store mode) is an I/O request response storage mode field, has a length of 1 bit (hereinafter referred to as R bit), is valid for the SSP and SMP protocols, and represents a storage mode of a response frame IU of a current I/O request, which is specifically as follows:

a)0b 0: indicating that the received Response information is directly stored in an RB section of the I/O data description table;

b)0b 1: an RB segment storage PRD descriptor representing an I/O data description table, and describing the storage position of the received Response information;

the IORT (I/O Request Tag) is an I/O Request transmission mark field, has the length of 16 bits, identifies the index number of the current I/O Command, namely IPTT (initiator Port Transfer Tag) in the SSP protocol or NCQ Tag (Native Command Queue Tag) in the STP protocol, and represents the offset position of the current I/O Request description block in the I/O Request list;

CFIUL (Command Frame IU Length) is a length field of the I/O request command Frame IU, has the length of 16 bits, represents the effective data length of the current I/O request command Frame IU section, and takes bytes as units;

SGEL (scatter Gather Entry Length) is a length field of an SGL list in an I/O data description table, the length is 16 bits, and the number of entries in the SGL list is represented;

IOBC (I/OByte Count) is an I/O request data total length field, and the length is 32 bits;

IODTBA (I/O Data Base Address) is a physical Base Address field of the I/O Data description Table, has the length of 64 bits and represents the position of the current SAS I/O Data description Table stored in a system physical memory;

rsvd is a reserved field;

the SAS I/O data description table SIODDT occupies continuous physical address space in a system memory, content information of an I/O request command frame is stored in the SAS I/O data description table SIODDT, a space is reserved for storing a response frame, a linked list DMA description list is used for representing the storage position of data in I/O request interaction, and 65535 table entries are supported to the maximum extent. The format of the I/O data description table is fixed, and the specific field information is as shown in fig. 5, where:

cfiu (command Frame Information unit) is a command Frame Information field, has a length of 8 dwords, stores content Information or PRD descriptors of a current I/O request command Frame, and stores corresponding content according to different protocols, specifically as follows:

a) for the SSP protocol: when the C bit of the SAS I/O request description block is "0", the CFIU field stores the IU contents of the SSP Command frame or the SSP Task frame; and when the C bit is "1", as shown in fig. 6, the CFIU field stores 4 Dword PRD descriptors, indicating the physical address and length of the frame IU;

b) for the SMP protocol: when the C bit of the SAS I/O Request description block is 0, the CFIU field stores the content information of the SMP Request frame; when the C bit is "1", 4 Dword PRD descriptors are stored, which indicate the physical address and length of the frame content storage, as shown in fig. 6;

c) for the STP protocol: the CFIU field stores the H2D Register FIS of the STP command; RB (response buffer) is a response frame buffer: the length of the memory is 24 Dwords, and the memory is used for storing response frame content information or PRD descriptors of the current I/O request and storing corresponding content according to different protocols, and the specific content is as follows:

a) for SSP or SMP protocols: when the R bit of the SAS I/O request description block is 0, the Response frame buffer stores the first 96 bytes of the Response frame IU; when the R bit is "1", as shown in fig. 6, it stores PRD descriptors of 4 dwords, indicating the physical address and length of the Response frame storage;

b) for the STP protocol: the response frame buffer stores non-Data type FISs received in the current I/O interaction process, and the storage positions of the types of FISs are as shown in FIG. 5:

1) offset address 20 h: D2H Register FIS, 5 Dword;

2) offset address 38 h: PIO Setup FIS, 5 dwords;

3) offset address 50 h: DMA Setup FIS, 7 dwords;

4) offset address 70 h: set Devices Bits FIS, 2 Dword;

SGC (Scatter Gather context) is an SGL context field, the length of the SGC is 4 Dword, and in an SSP application scene, the maximum Data length of a single SSP Data frame is 1 Kbyte. In the STP application scenario, the maximum Data length of a single Data FIS is 8 kbytes. The Data requested by the I/O typically requires multiple SSP Data frames or Data FIS transfers to complete. Typically, SAS physical links are often time division multiplexed with multiple I/O requests at the same time, with data frames of different I/O requests being interleaved for transmission. At the time of I/O request switching, context information of the current SGL needs to be saved, ensuring sustainability after current I/O data transmission is interrupted. The SGC field further includes the following fields:

a) dxa (data Transfer address): the length is 64 bits, which represents the physical address of interrupted data transmission, and after the I/O data transmission is recovered, the data reading and writing are continued from the address;

b) rbc (remaining Byte count): the length is 32 bits, which represents the residual byte number of the data segment of the interrupted linked list DMA descriptor table;

c) offs (offset): length 16 bits, representing the interrupted linked list DMA descriptor table entry location index;

d) i: length 1 bit, which represents whether to report interrupt to system processor after finishing transmission defined by current DXA and RBC;

e) l: length 1 bit, which represents whether the transmission defined by the current DXA and RBC is the last data of I/O request;

SGL (Scatter Gather List) is a linked list DMA descriptor list field, maximum length 65536 entries. The single descriptor table entry is 4 dwords in size, see fig. 5, and the specific format further includes:

a) DBA: the length is 64 bits, and the physical base address of the data segment pointed by the current descriptor table item is represented;

b) DBC: length 32 bits, representing the length of the data segment byte pointed to by the current descriptor table entry;

c) i: the length is 1 bit, which represents whether the system interrupt is triggered after the data transmission of the current descriptor table item is finished;

d) l: the length is 1 bit, and the value is '1' to indicate that the current descriptor table entry is the last entry in the SGL list.

Those skilled in the art will appreciate that the field format and the number of bits described in the above embodiments are only examples. Those skilled in the art can add, adjust or delete the specific packaging format of the fields as needed.

In the exemplary SAS storage topology shown in fig. 7, the SAS controller supports large-scale disk management via one or more levels of Expander expansion. Based on the above general SAS controller interface technology provided by the present invention, in another aspect of the present invention, an example workflow of system software and an example workflow of an SAS controller are described in combination with a scenario of first-level Expander connection expansion from the perspective of system software application and the SAS controller, respectively.

Referring to fig. 8, an exemplary flow chart illustrates the process of system software building a SAS target device list and a SAS I/O request list in memory, including the steps of:

step S1.1: and releasing the SAS controller reset signal by the system software to enable the Expander device. The controller and the Expander link layer and the physical layer complete link identification, rate negotiation and exchange of IDAF (identify Address frame) Address frames;

step S1.2: the system software determines that the type of the physical port connection equipment is Expander equipment according to the IDAF Address frame received by the SAS controller, 8 Dword spaces are distributed in a system memory, an Expander equipment description block 0 is established, an ICT equipment number 0 is distributed, and information such as the SAS Address, the type DT of the target equipment, the maximum connection rate MCR and the like is recorded. Setting a physical base address of a SAS target equipment list base address register STDLBA pointing to a current Expander equipment description block 0, setting 1 in an SAS target equipment list length register STDLL, and indicating that the length of a target equipment list is 1;

step S1.3: because SMP I/O requests do not support multi-command concurrency, only one I/O interaction is allowed between the SAS controller and the Expander device at the same time, system software allocates 8 Dword spaces in a memory, establishes an I/O request description block 0 of the Expander device, sets fields such as a protocol type field PT, a type field RT of the I/O request, an I/O request transmission mark field IORT and the like, and updates an SAS I/O request list base address field SIORLBA of target equipment of the Expander device description block 0 to point to a physical base address of the current I/O request description block 0;

step S1.4: the SAS controller queries the state of the downstream port of the Expander by sending an SMP Discover request to the Expander device. Because the I/O request of the SMP protocol type has no data frame transmission, the length of an SGL list segment in an I/O data description table is 0, system software allocates 0xA0 byte space in an internal memory, establishes an I/O data description table of a Discover command, and constructs and executes the SMP Discover I/O request.

Step S1.5: the system software determines the number of SAS target devices connected with the Expander downlink port according to the response information of the SMP Discover command; if no SAS target equipment is connected, the method is ended, otherwise, the step S1.6 is carried out;

step S1.6: and expanding the SAS target equipment list to N +1 description blocks by the system software according to the number of the SAS target equipment reported by the Expander. The description block 0 of the SAS target equipment is Expander equipment, and the description blocks 1-N +1 correspond to the SAS target equipment 0-N;

step S1.7: because a typical SATA disk supports 32-maximum command concurrence, system software establishes an I/O request list for each SAS target device, wherein the length of the list is 32, and the total size is 32 multiplied by 8 Dwords, and updates the SAS I/O request list base address field SIORLBA of a corresponding target device description block to point to the currently allocated I/O request list physical base address;

step S1.8: repeating the step S1.7 until all SAS target devices are traversed and sequentially establishing an I/O request list;

step S1.9: and completing the construction of the system memory structure.

Referring to fig. 9, an exemplary flow chart shows the process of system software issuing an I/O request to a particular SAS target device, including the steps of:

step S2.1: the application has a new I/O request and waits for issuing;

step S2.2: the system software traverses an I/O request list of the target equipment and applies for an idle available I/O request description block, namely an I/O request description block with a valid bit V bit of 0;

step S2.3: judging whether an idle I/O request description block is available in the I/O request list, if not, returning to the step S2.2 to continue inquiring, and if so, entering the step S2.4;

step S2.4: system software builds an I/O data description table, fills command frame information, builds a DMA description list of an SGL linked list according to the distribution of I/O data in a memory, and records SGL length information in an SGEL field of an I/O request description block;

step S2.5: the I/O request index information is written to the SAS I/O request commit register SIORS. Wherein SIORS [ 31: 16] represents the I/O target device number, i.e., the offset index number in the I/O target device list, SIORS [ 15: 0] represents the I/O request number, i.e., the offset index number in the I/O request list;

step S2.6: the SAS I/O request completion register SIORC is queried, waiting for I/O request execution to complete.

Referring to FIG. 10, an exemplary flow chart illustrates a process for a SAS controller processing an I/O request, including the steps of:

step S3.1: the SAS controller completes initialization, and system software completes construction of an I/O target device list and an I/O request list in a memory. The SAS controller waits to execute the I/O request;

step S3.2: judging whether the SAS I/O request submission register SIORS receives a new I/O request, if so, entering a step S3.3, otherwise, continuing to judge;

step S3.3: the SAS controller obtains the physical base address of the target device description block, namely STDLBA + (SIORS [ 31: 16] × 8 × 4), according to the information of the SAS I/O request list base address field STDLBA and the SAS I/O request submission register SIORS. The SAS controller reads the content information of the target description block and constructs a connection request Address frame OPAF (open Address frame);

step S3.4: the I/O request description block physical base address, namely SIORLBA + (SIORS [ 15: 0] × 8 × 4), is obtained from the SIORLBA field and the SIORS register information in the target device description block. And reading content information of the I/O request description block, and acquiring information such as a protocol type, a command frame type, a storage position and the like.

Step S3.5: and the SAS controller acquires the physical base address of the I/O data description table according to the IODTBA information of the I/O data description table physical base address field in the I/O request description block, reads the CFIU field information of the I/O data description table, and constructs and issues a command frame. In the I/O interaction process, the DMA unit of the controller reads or stores the data frame content according to the system memory pointed by the linked list DMA description list SGL. Storing the received response frame information in an RB field;

step S3.6: the SAS controller informs system software of the completion of the I/O request processing through an SAS I/O request completion register SIORC. Wherein SIORC [ 31: 16] denotes the I/O destination device number, SIORC [ 15: 0 represents the I/O request number.

The method for realizing the interface of the universal SAS controller is suitable for SAS storage systems with various topological structures. It can be seen that the technical solution of the present invention uniformly defines the interface implementation of the SAS controller, and uniformly encapsulates the work flow of the interface on both sides of the system software and the SAS controller, so that the use mode of the general SAS controller can be directly applied to other upper application software, the application layer does not need to redefine the system software development flow, and the transportability of different application software is also realized. Compared with the prior art, the method and the system can unify the programming interface of the system software, enhance the universality of the SAS controller, reduce the integration complexity and save the development cost of the system software.

Although the present invention has been described in detail with reference to the foregoing embodiments, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention; and such modifications or substitutions do not depart from the spirit and scope of the corresponding technical solutions of the embodiments of the present invention.

Claims

1. A method for realizing a universal SAS controller interface is used for realizing information interaction between system software and an SAS controller, and is characterized by comprising the following steps:

2. The method of claim 1, wherein the target device list base address register is configured to identify a physical base address of the target device list in a system memory, and the SAS controller obtains address information of a SAS target device description block according to the base address.

3. The method of claim 1, wherein the SAS target device description block contains device type, connection rate, target device index number, and SAS Address fields, and provides information for constructing an opaf (open Address frame) Address frame.

4. The universal SAS controller interface implementation method of claim 1 wherein said target device list length register is used to define the number of said SAS target device description blocks.

5. The method of claim 1 wherein the I/O request submission register is configured to receive an SAS I/O request submitted by the system software and to send the request to an SAS controller.

6. The universal SAS controller interface implementing method of claim 1 wherein said I/O request completion register is adapted to receive a message from said SAS controller to notify said system software of an executed SAS I/O request completion.

7. The method of claim 3 wherein the SAS target device description block further comprises a SAS I/O request list base address field indicating where the SAS I/O request list is stored in system physical memory and a SAS I/O request list length field; the SAS I/O request list length field indicates the number of I/O request description blocks in the SAS I/O request list.

8. The universal SAS controller interface implementation method of claim 7 wherein said I/O request description block contains protocol type, I/O request type and request index number fields, and building information for multiple types of I/O frames.

9. The universal SAS controller interface implementation method of claim 8 wherein said multiple types of I/O frames comprise at least one of: an SSP command frame, an SSP task frame, an SMP request frame, a SATA PIO command frame, a SATA DMA command frame, and an SATA FPDMA command frame.

10. The method of claim 8, wherein the I/O request description block further comprises an I/O data description table physical base address field indicating a physical location where the current I/O data description table is stored in system memory, and an SGL list length field indicating a number of entries in the SGL list, wherein the SGL list is a linked list DMA descriptor list.