diff --git a/qos.bib b/qos.bib index d1ca400..30437bb 100644 --- a/qos.bib +++ b/qos.bib @@ -7,6 +7,10 @@ @electronic{IOMMU title = {RISC-V IOMMU Architecture Specification}, url = {https://github.com/riscv-non-isa/riscv-iommu} } +@electronic{SSQOSID, + title = {RISC-V Quality-of-Service (QoS) Identifiers}, + url = {https://github.com/riscv/riscv-ssqosid} +} @INPROCEEDINGS{SSAMPLE, author={Thornock, N.C. and Flanagan, J.K.}, booktitle={2000 Winter Simulation Conference Proceedings (Cat. No.00CH37165)}, diff --git a/qos_bandwidth.adoc b/qos_bandwidth.adoc index db2797f..e6c1068 100644 --- a/qos_bandwidth.adoc +++ b/qos_bandwidth.adoc @@ -21,12 +21,12 @@ register interface. allocation>> | Yes |=== -The reset value is 0 for the following registers fields. +The reset value is 0 for the following register fields. * `bc_mon_ctl.BUSY` field * `bc_alloc_ctl.BUSY` field -The reset value is `UNSPECIFIED` for all other registers and/or fields. +The reset value is `UNSPECIFIED` for all other register fields. The bandwidth controllers at reset must allocate all available bandwidth to `RCID` value of 0. When the bandwidth controller supports bandwidth allocation @@ -88,7 +88,7 @@ bandwidth controller can handle such transient inaccuracies. The `bc_mon_ctl` register is used to control monitoring of bandwidth usage by a `MCID`. When the controller does not support bandwidth usage monitoring, the -`bc_mon_ctl` register is read-only and hardwired to zero. +`bc_mon_ctl` register is read-only zero. .Bandwidth usage monitoring control (`bc_mon_ctl`) [wavedrom, , ] @@ -117,24 +117,7 @@ matching the monitoring event as the requests go past the monitoring point. The `OP`, `AT`, `MCID`, and `EVT_ID` fields of the register are WARL fields. The `OP` field is used to instruct the controller to perform an operation -listed in <>. The supported operations of the `OP` field include -configuring an event to count in the monitoring counter and obtaining a -snapshot of the counter value. - -The `EVT_ID` field is used to program the identifier of the event to count in -the monitoring counter selected by `MCID`. The `AT` field is used to program the -access-type to count, and its validity is indicated by the `ATV` field. When -`ATV` is 0, the counter counts requests with all access-types, and the `AT` -value is ignored. - -When the `EVT_ID` for a `MCID` is programmed with a non-zero and legal value, -the counter is reset to 0 and starts counting matching events for requests with -the matching `MCID` and `AT` (if `ATV` is 1). However, if the `EVT_ID` is -configured as 0, the counter retains its current value but stops counting. - -A controller that does not support monitoring by access-type can hardwire the -`ATV` and the `AT` fields to 0, indicating that the counter counts requests with -all access-types. +listed in <>. [[BC_MON_OP]] .Usage monitoring operations (`OP`) @@ -154,6 +137,11 @@ all access-types. | -- | 24-31 | Designated for custom use. |=== +The `EVT_ID` field is used to program, using the `CONFIG_EVENT` operation, the +identifier of the event to count in the monitoring counter selected by `MCID`. +The `AT` field is used to program the access-type to count, and its validity is +indicated by the `ATV` field. When `ATV` is 0, the counter counts requests with +all access-types, and the `AT` value is ignored. [[BC_EVT_ID]] .Bandwidth monitoring event ID (`EVT_ID`) @@ -179,6 +167,15 @@ all access-types. | -- | 128-256 | Designated for custom use. |=== +When the `EVT_ID` for a `MCID` is programmed with a non-zero and legal value, +the counter is reset to 0 and starts counting matching events for requests with +the matching `MCID` and `AT` (if `ATV` is 1). However, if the `EVT_ID` is +configured as 0, the counter retains its current value but stops counting. + +A controller that does not support monitoring by access-type can hardwire the +`ATV` and the `AT` fields to 0, indicating that the counter counts requests with +all access-types. + When the `bc_mon_ctl` register is written, the controller may need to perform several actions that may not complete synchronously with the write. A write to the `bc_mon_ctl` sets the read-only `BUSY` bit to 1 indicating the controller @@ -232,7 +229,7 @@ as zero. .... The counter is valid if the `INV` field is 0. The counter may be marked -`INV` if, for `UNSPECIFIED` reasons, the controllerdetermine the count to be +`INV` if, for `UNSPECIFIED` reasons, the controller determines the count to be not valid. Such counters may become valid in the future. Additionally, if an unsigned integer overflow of the counter occurs, then the `OVF` bit is set to 1. @@ -256,7 +253,8 @@ Bandwidth = T_{freq} \times \frac{ B2 - B1 }{T2 - T1} \end{equation} ++++ -The width of the counter is `UNSPECIFIED`. +The width of the counter is `UNSPECIFIED` but the unimplemented bits must be +read-only zero. [NOTE] ==== @@ -275,7 +273,7 @@ operation. The `bc_alloc_ctl` register is used to control the allocation of bandwidth to an `RCID` per `AT`. If a controller does not support bandwidth allocation, then the register is read-only zero. If the controller does not support bandwidth -allocation per access-type, then the `AT` field is also read-only zero. +allocation per access-type, then the `AT` field is read-only zero. .Bandwidth allocation control (`bc_alloc_ctl`) [wavedrom, , ] @@ -446,8 +444,8 @@ access-type specified by `sharedAT` does not have unique bandwidth allocation, meaning that it has not been configured with `useShared=0`, then the behavior is `UNSPECIFIED`. -The `useShared` and `sharedAT` fields are reserved if the bandwidth controller -does not support bandwidth allocation per access-type. +The `useShared` and `sharedAT` fields are read-only zero if the bandwidth +controller does not support bandwidth allocation per access-type. [NOTE] ==== @@ -459,7 +457,7 @@ and the access-type 2 is configured to share bandwidth allocation with access-type 1. The example configuration is illustrated as follows: [width=100%] -[%header, cols="4,^1,^1,^1,^1"] +[%header, cols="4,^2,^2,^2,^2"] |=== | | `Rbwb` | `Mweight` | `useShared` | `sharedAT` | `RCID=3`, `AT=0` | `100` | `16` | `0` | `N/A` diff --git a/qos_capacity.adoc b/qos_capacity.adoc index 43c8da5..cca264b 100644 --- a/qos_capacity.adoc +++ b/qos_capacity.adoc @@ -48,12 +48,12 @@ The size and offset in <> are specified in bytes. The size of the `cc_block_mask` register is determined by the `NCBLKS` field of the `cc_capabilities` register but is always a multiple of 8 bytes. -The reset value is 0 for the following registers fields. +The reset value is 0 for the following register fields. * `cc_mon_ctl.BUSY` field * `cc_alloc_ctl.BUSY` field -The reset value is `UNSPECIFIED` for all other registers and/or fields. +The reset value is `UNSPECIFIED` for all other registers fields. The capacity controllers at reset must allocate all available capacity to `RCID` value of 0. When the capacity controller supports capacity allocation per @@ -138,24 +138,7 @@ The `OP`, `AT`, `ATV`, `MCID`, and `EVT_ID` fields of the register are WARL fields. The `OP` field is used to instruct the controller to perform an operation listed -in <>. The supported operations of the `OP` field include configuring -an event to count in the monitoring counter and obtaining a snapshot of the -counter value. - -The `EVT_ID` field is used to program the identifier of the event to count in -the monitoring counter selected by `MCID`. The `AT` field is used to program the -access-type to count, and its validity is indicated by the `ATV` field. When -`ATV` is 0, the counter counts requests with all access-types, and the `AT` -value is ignored. - -When the `EVT_ID` for a `MCID` is programmed with a non-zero and legal value, -the counter is reset to 0 and starts counting matching events for requests with -the matching `MCID` and `AT` (if `ATV` is 1). However, if the `EVT_ID` is -configured as 0, the counter retains its current value but stops counting. - -A controller that does not support monitoring by access-type can hardwire the -`ATV` and the `AT` fields to 0, indicating that the counter counts requests with -all access-types. +in <>. [[CC_MON_OP]] .Capacity usage monitoring operations (`OP`) @@ -175,6 +158,11 @@ all access-types. | -- | 24-31 | Designated for custom use. |=== +The `EVT_ID` field is used to program the identifier of the event to count in +the monitoring counter selected by `MCID`. The `AT` field (See <>) is +used to program the access-type to count, and its validity is indicated by the +`ATV` field. When `ATV` is 0, the counter counts requests with all access-types, +and the `AT` value is ignored. [[CC_EVT_ID]] .Capacity usage monitoring event ID (`EVT_ID`) @@ -191,6 +179,16 @@ all access-types. | -- | 128-256 | Designated for custom use. |=== +When the `EVT_ID` for a `MCID` is programmed with a non-zero and legal value +using the `CONFIG_EVENT` operation, the counter is reset to 0 and starts counting +matching events for requests with the matching `MCID` and `AT` (if `ATV` is 1). +However, if the `EVT_ID` is programmed to 0, the counter retains its current value +but stops counting. + +A controller that does not support monitoring by access-type can hardwire the +`ATV` and the `AT` fields to 0, indicating that the counter counts requests with +all access-types. + When the `cc_mon_ctl` register is written, the controller may need to perform several actions that may not complete synchronously with the write. A write to the `cc_mon_ctl` sets the read-only `BUSY` bit to 1 indicating the controller @@ -242,22 +240,27 @@ zero. ], config:{lanes: 2, hspace:1024}} .... -The counter is valid if the `INV` field is 0. The counter may be marked -`INV` if it underflows or the controller, for `UNSPECIFIED` reasons determine -the count to be not valid. The counters marked `INV` may become valid in future. +The counter is valid if the `INV` field is 0. The counter may be marked `INV` if +the controller, for `UNSPECIFIED` reasons determine the count to be not valid. +The counters marked `INV` may become valid in future. + +The counter shall not decrement below zero. If an event should occur that would +otherwise result in a negative value, the counter will continue to hold a value +of 0. [NOTE] ==== -A counter may underflow when capacity is de-allocated following a reset -of the counter to 0. This may be due to the `MCID` being reallocated to a new -workload while the capacity controller still holds capacity allocated by -the workload to which the `MCID` was previously allocated. The counter value -should typically stabilize to reflect the capacity usage of the new workload -after the workload has executed for a short duration following the counter -reset. +Following a reset of the counter to zero, a capacity de-allocation may attempt +to drive its value below zero. This scenario may occur when the `MCID` is +reassigned to a new workload, yet the capacity controller continues to hold +capacity initially allocated by the previous workload. In such cases, the +counter shall not decrement below zero and shall remain at zero. After a brief +period of execution for the new workload post-counter reset, the counter value is +expected to stabilize to reflect the capacity usage of this new workload. ==== [NOTE] +[%unbreakable] ==== Some implementations may not store the `MCID` of the request that caused the capacity to be allocated with every unit of capacity in the controller to @@ -288,10 +291,10 @@ processes. === Capacity allocation control (`cc_alloc_ctl`) The `cc_alloc_ctl` register is used to configure allocation of capacity to an -`RCID` per access-type (`AT`). The `RCID` and `AT` fields in this register are -WARL. If a controller does not support capacity allocation then this register is -read-only zero. If the controller does not support capacity allocation per -access-type then the `AT` field is read-only zero. +`RCID` per access-type (`AT`). The `OP`, `RCID` and `AT` fields in this register +are WARL. If a controller does not support capacity allocation then this +register is read-only zero. If the controller does not support capacity +allocation per access-type then the `AT` field is read-only zero. .Capacity allocation control (`cc_alloc_ctl`) [wavedrom, , ] @@ -307,8 +310,6 @@ access-type then the `AT` field is read-only zero. ], config:{lanes: 2, hspace:1024}} .... -The `OP`, `AT`, and `RCID` are WARL fields. - The `OP` field is used to instruct the capacity controller to perform an operation listed in <>. Some operations necessitate the specification of the _capacity blocks_ to act upon. For such operations, the @@ -338,14 +339,14 @@ initiating the operation via the `cc_alloc_ctl` register. `cc_block_mask` register, and the configured limit on _capacity units_ is available in the `cc_cunits` register on successful completion of the operation. -|`FLUSH_RCID` | 3 | Deallocate the capacity used by the specified +|`FLUSH_RCID` | 3 | Flushes the _capacity units_ used by the specified `RCID` and access-type `AT`. This operation is supported if the `capabilities.FRCID` bit is 1. + + The `cc_block_mask` and `cc_cunits` registers are not used for this operation. + + - The configured _capacity_ block allocation or the + The configured _capacity block_ allocation or the _capacity unit_ limit is not changed by this operation. | -- | 4-23 | Reserved for future standard use. @@ -467,12 +468,13 @@ software must verify that `BUSY` bit is 0 before writing any of these registers === Capacity block mask (`cc_block_mask`) The `cc_block_mask` is a WARL register. If the controller does not support -capacity allocation i.e. `NCBLKS` is 0, then this register is read-only 0. +capacity allocation, i.e., `NCBLKS` is 0, then this register is read-only 0. The register has `NCBLKS` bits each corresponding to one allocatable _capacity block_ in the controller. The width of this register is variable but always a multiple of 64 bits. The bitmap width in bits (`BMW`) is determined by -<>. The division operation in this equation is an integer division. +the equation below. The division operation in this equation is an integer +division. [latexmath#eq-1,reftext="equation ({counter:eqs})"] ++++ @@ -481,21 +483,20 @@ BMW = \lfloor{\frac{NCBLKS + 63}{64}}\rfloor \times 64 \end{equation} ++++ -Bits `NCBLKS-1:0` are read-write, and the bits `BMW-1:NCBLKS` are read-only and -have a value of 0. +Bits `NCBLKS-1:0` are read-write, and the bits `BMW-1:NCBLKS` are read-only zero. The process of configuring capacity allocation for an `RCID` and `AT` begins by programming the `cc_block_mask` register with a bit-mask that identifies the -_capacity blocks_ to be allocated and, if supported, the `cc_cunits` register with -a limit on the capacity units that may be occupied in those capacity blocks. -Next, the `cc_alloc_ctl register` is written to request a `CONFIG_LIMIT` -operation for the `RCID` and `AT`. Once a capacity allocation limit has been -established, a request may be allocated capacity in the capacity blocks -allocated to the `RCID` and `AT` associated with the request. It is important to -note that at least one capacity block must be allocated using `cc_block_mask` -when allocating capacity, or else the operation will fail with `STATUS=5`. -Overlapping _capacity block_ masks among `RCID` and/or `AT` are allowed to be -configured. +_capacity blocks_ to be allocated and, if supported, by programming the +`cc_cunits` register with a limit on the capacity units that may be occupied in +those capacity blocks. Next, the `cc_alloc_ctl register` is written to request a +`CONFIG_LIMIT` operation for the `RCID` and `AT`. Once a capacity allocation +limit has been established, a request may be allocated capacity in the _capacity +blocks_ allocated to the `RCID` and `AT` associated with the request. It is +important to note that at least one _capacity block_ must be allocated using +`cc_block_mask` when allocating capacity, or else the operation will fail with +`STATUS=5`. Overlapping _capacity block_ masks among `RCID` and/or `AT` are +allowed to be configured. [NOTE] ==== @@ -516,13 +517,13 @@ provides the `READ_LIMIT` operation which can be requested by writing to the The `cc_cunits` register is a read-write WARL register. If the controller does not support capacity allocation (i.e., `NCBLKS` is set to 0), this register -shall be read-only and return a value of 0. +shall be read-only zero. If the controller does not support configuring limits on _capacity units_ that may be occupied in the allocated _capacity blocks_ (i.e., -`cc_capabilities.CUNITS=0`) then this register shall be read-only and return a -value of 0. In such cases the controller will allow utilization of all available -_capacity units_ by an `RCID` within the _capacity blocks_ allocated to it. +`cc_capabilities.CUNITS=0`) then this register shall be read-only zero. In such +cases the controller will allow utilization of all available _capacity units_ by +an `RCID` within the _capacity blocks_ allocated to it. If the controller supports configuring limits on _capacity units_ that may be occupied in the allocated _capacity blocks_ (i.e., `cc_capabilities.CUNITS=1`) diff --git a/qos_header.adoc b/qos_header.adoc index caa6c18..a91673f 100644 --- a/qos_header.adoc +++ b/qos_header.adoc @@ -41,7 +41,7 @@ RISC-V CMQRI Task Group // Preamble [WARNING] -.This document is in the link:http://riscv.org/spec-state[Development state] +.This document is in the link:http://riscv.org/spec-state[Stable state] ==== Assume everything can change. This draft specification will change before being accepted as standard, so implementations made to this draft diff --git a/qos_hw_guidelines.adoc b/qos_hw_guidelines.adoc index ce07192..8b0d23c 100644 --- a/qos_hw_guidelines.adoc +++ b/qos_hw_guidelines.adoc @@ -1,6 +1,7 @@ [[QOS_HW_GUIDE]] == Hardware Guidelines +[[QOS_SIZING]] === Sizing QoS Identifiers In a typical implementation the number of `RCID` bits implemented (e.g., to @@ -20,9 +21,12 @@ large pool of `MCID` speeds up this analysis. [NOTE] ==== -To support maximal flexibility in allocation of QoS IDs to workloads it is -recommended for all resource controllers in the system to support an identical -number of `RCID` and `MCID`. +To achieve maximum flexibility in the allocation of QoS IDs to workloads, it is +recommended that all resource controllers in the system support an identical +number of `RCID` and `MCID`. Requests typically need to be processed by multiple +controllers, such as caches, fabrics, and memory controllers. In such cases, if +not all controllers accessed by a request support an identical number of IDs, +software will be constrained, using only the IDs supported by all controllers. ==== diff --git a/qos_identifiers.adoc b/qos_identifiers.adoc index fb4363d..4be6e68 100644 --- a/qos_identifiers.adoc +++ b/qos_identifiers.adoc @@ -13,43 +13,14 @@ configure resource usage limits, in the form of capacity or bandwidth, per supported access type, for an `RCID` in the resource controllers that control accesses to such shared resources. -To monitor the resource utilization by a workload CBQRI defines a mechanism to +To monitor the resource utilization by a workload, CBQRI defines a mechanism to configure counters identified by the `MCID` to count events in the resource controllers that control accesses to such shared resources. -=== Associating `RCID` and `MCID` with requests - -==== RISC-V hart initiated requests (Ssqosid) +Guidelines for sizing the QoS IDs and need for differentiated IDs for monitoring +is discussed in <>. -The Ssqosid extension, introduces a read/write S/HS-mode register (`sqoscfg`) to -configure QoS Identifiers to be used with requests made by the hart to shared -resources. - -The `sqoscfg` CSR is a 32-bit S/HS-mode read/write WARL register to configure a -resource control ID (`RCID`) and a monitoring counter ID (`MCID`). The `RCID` -and `MCID` accompany each request made by the hart to shared resources such -as interconnects, caches, memory, etc. - -.`sqoscfg` register for RV32 and RV64 - -[wavedrom, , ] -.... -{reg: [ - {bits: 12, name: 'RCID'}, - {bits: 4, name: 'WPRI'}, - {bits: 12, name: 'MCID'}, - {bits: 4, name: 'WPRI'}, -], config:{lanes: 1, hspace:1024}} -.... - -[NOTE] -==== -The type of request made to the shared resource controller depends on the type -of shared resource. In case of resources such as caches or memory these may be -a memory access request. In case of resources such as CPU dispatch slots and -retirement bandwidth the request may be to allocate such resources for -execution. -==== +=== Associating `RCID` and `MCID` with requests The `RCID` in the request is used by the resource controllers to determine the resource allocations (e.g., cache occupancy limits, memory bandwidth limits, @@ -57,26 +28,11 @@ etc.) to enforce. The `MCID` in the request is used by the resource controllers to identify the ID of a counter to monitor resource usage (e.g., cache occupancy, memory bandwidth, etc.). -Access to `sqoscfg` when `V=1` causes a virtual-instruction exception. - -[NOTE] -==== -At reset it is suggested that the `RCID` field of `sqoscfg` be set to 0 as -typically the resource controllers in the SoC default to a reset behavior -of associating all capacity or bandwidth to the `RCID` value of 0. - -The value of `MCID` at reset, unlike the `RCID`, does not affect functional -behavior. Implementations may choose a convenient legal value for the `MCID` -reset value. -==== - -The `RCID` and `MCID` configured in the `sqoscfg` CSR apply to all privilege -modes of software execution on that hart. +==== RISC-V hart initiated requests (Ssqosid) -The `QOSE` (bit 58) field of the `menvcfg` (and `menvcfgh`) machine-level CSR -controls if the `sqoscfg` CSR is accessible in modes less privileged than M. -When `QOSE` is 0, attempts to access `sqoscfg` CSR at privilege modes less -privileged than M cause an illegal instruction exception. +The Ssqosid extension cite:[SSQOSID] introduces a read/write S/HS-mode register +(`sqoscfg`) to configure QoS Identifiers to be used with requests made by the +hart to shared resources. ==== Device initiated requests diff --git a/qos_intro.adoc b/qos_intro.adoc index 936accd..8eddbe5 100644 --- a/qos_intro.adoc +++ b/qos_intro.adoc @@ -3,7 +3,7 @@ Quality of Service (QoS) is defined as the minimal end-to-end performance that is guaranteed in advance by a service level agreement (SLA) to a workload. A -workload may be a single application, a group of application, a virtual machine, +workload may be a single application, a group of applications, a virtual machine, a group of virtual machines, or a combination of those. The performance may be measured in the form of metrics such as instructions per cycle (IPC), latency of servicing work, etc. @@ -12,7 +12,7 @@ Various factors such as the available cache capacity, memory bandwidth, interconnect bandwidth, CPU cycles, system memory, etc. affect the performance in a computing system that runs multiple workloads concurrently. Furthermore, when there is arbitration for shared resources, the prioritization of the -workloads requests against other competing requests may also affect the +workloads' requests against other competing requests may also affect the performance of the workload. Such interference due to resource sharing may lead to unpredictable workload performance cite:[PTCAMP]. @@ -20,8 +20,8 @@ When multiple workloads are running concurrently on modern processors with large core counts, multiple cache hierarchies, and multiple memory controllers, the performance of a workload becomes less deterministic or even non-deterministic. This is because the performance depends on the behavior of all the other -workloads in the machine that contend for the shared resources leading to -interference. In many deployment scenarios such as public cloud servers the +workloads in the machine that contend for the shared resources, leading to +interference. In many deployment scenarios, such as public cloud servers, the workload owner may not be in control of the type and placement of other workloads in the platform. @@ -32,9 +32,9 @@ for execution, etc. System software needs additional tools to control interference to a workload and thereby reduce the variability in performance experienced by one workload -due to other workload’s cache capacity usage, memory bandwidth usage, -interconnect bandwidth usage, etc. through a resource allocation capability. The -resource allocation capability enables system software to reserve capacity +due to other workloads' cache capacity usage, memory bandwidth usage, +interconnect bandwidth usage, etc. through a resource allocation capability. +The resource allocation capability enables system software to reserve capacity and/or bandwidth to meet the performance goals of the workload. Such controls enable improving the utilization of the system by collocating workloads while minimizing the interference caused by one workload to another cite:[HERACLES]. @@ -46,9 +46,9 @@ typical use model involves profiling the resource usage of the workload using the resource monitoring capability and to establish resource allocations for the workload using the resource allocation capability. -The allocation may be in the form of capacity or bandwidth depending on the type +The allocation may be in the form of capacity or bandwidth, depending on the type of resource. For caches, TLBs, and directories, the resource allocation is in -the form of storage capacity. For interconnects and memory controllers the +the form of storage capacity. For interconnects and memory controllers, the resource allocation is in the form of bandwidth. Workloads generate different types of accesses to shared resources. For example, @@ -88,11 +88,11 @@ range of physical address space that is a multiple of 4-KiB and the lowest address of the range is aligned to 4-KiB. The memory-mapped registers may be accessed using naturally aligned 4-byte or 8-byte memory accesses. The controller behavior for register accesses where the address is not aligned to -the size of the access, or if the access spans multiple registers, of if the -size of the access is not 4-bytes or 8-bytes, is `UNSPECIFIED`. A 4-byte access -to a register must be single-copy atomic. Whether an 8 byte access to an CBQRI +the size of the access, or if the access spans multiple registers, or if the +size of the access is not 4 bytes or 8 bytes, is `UNSPECIFIED`. A 4-byte access +to a register must be single-copy atomic. Whether an 8-byte access to a CBQRI register is single-copy atomic is `UNSPECIFIED`, and such an access may appear, -internally to the CBQRI implementation, as if two separate 4 byte accesses were +internally to the CBQRI implementation, as if two separate 4-byte accesses were performed. [NOTE] diff --git a/qos_iommu.adoc b/qos_iommu.adoc index c9a2dae..a0109b3 100644 --- a/qos_iommu.adoc +++ b/qos_iommu.adoc @@ -32,7 +32,7 @@ If the reset value for `ddtp.iommu_mode` field is `Bare`, then the [NOTE] ==== -At reset, it is suggested that the `RCID` field of `iommu_qosid` be set to 0 if +At reset, it is required that the `RCID` field of `iommu_qosid` be set to 0 if the IOMMU is in `Bare` mode, as typically the resource controllers in the SoC default to a reset behavior of associating all capacity or bandwidth to the `RCID` value of 0. @@ -41,7 +41,7 @@ SoC default to a reset behavior of associating all capacity or bandwidth to the ==== IOMMU capabilities (`capabilities`) The IOMMU capabilities register has been extended with a new field, `QOSID`, -which enumerate support for associating QoS IDs with requests made through the +which enumerates support for associating QoS IDs with requests made through the IOMMU. .IOMMU capabilities register fields @@ -113,8 +113,8 @@ The `iommu_qosid` register fields are defined as follows: |31:28 |reserved |WPRI | Reserved for standard use. |=== -The `RCID` and `MCID` in `iommu_qosid` register are associated with following -IOMMU-initiated requests for access the following data structures: +IOMMU-initiated requests for accessing the following data structures use the +value programmed in the `RCID` and `MCID` fields of the `iommu_qosid` register. * Device directory table (`DDT`) * Fault queue (`FQ`) @@ -143,8 +143,8 @@ devices. ], config:{lanes: 2, hspace: 1024, fontsize: 16}} .... -The `RCID` and `MCID` configured in `DC.ta` are associated with IOMMU-initiated -requests to access the following data structures: +IOMMU-initiated requests for accessing the following data structures use the +value configured in the `RCID` and `MCID` fields of `DC.ta`. * Process directory table (`PDT`) * Second-stage page table @@ -168,7 +168,7 @@ address translation cache (IOATC) by implementing a capacity controller register interface. Some IOMMU may support multiple IOATC where the capacity of each such IOATC may -not be the same (e.g., corresponding each page sizes supported). When multiple -IOATC are implemented, the IOMMU may implement a capacity controller register -interface for each IOATC to enable capacity allocation in each IOATC. +not be the same. When multiple IOATC are implemented, (e.g., corresponding to +each page sizes supported), the IOMMU may implement a capacity controller +register interface for each IOATC to enable capacity allocation in each IOATC. diff --git a/qos_sw_guidelines.adoc b/qos_sw_guidelines.adoc index a049748..cca08af 100644 --- a/qos_sw_guidelines.adoc +++ b/qos_sw_guidelines.adoc @@ -22,7 +22,7 @@ new workload (a process or a VM) is not same as that of the old workload. A context switch usually involves saving the context associated with the workload being switched away from and restoring the context of the workload -being switched to. Such context switch may be invoked in response to an explicit +being switched to. Such a context switch may be invoked in response to an explicit call from the workload (i.e, as a function of an `ECALL` invocation) or may be done asynchronously (e.g., in response to a timer interrupt). In such cases the scheduler may want to execute with the `sqoscfg` configuration of the @@ -61,17 +61,17 @@ a set of HS mode CSRs. The `RCID` and `MCID` configured in `sqoscfg` also apply to execution in S/HS-mode, but this is typically not an issue. Usually, S/HS-mode execution -occurs to provide services, such as through the SBI, to software executing at +occurs to provide services, such as through an ABI, to software executing at lower privilege. Since the S/HS-mode invocation was to provide a service for -the lower privilege mode, the S/HS-mode software may not modify the `sqoscfg` -CSR. +the lower privilege mode, the S/HS-mode software may opt not to modify the +`sqoscfg` CSR. Similarly, The `RCID` and `MCID` configured in `sqoscfg` also apply to execution in M-mode, but this is typically not an issue either. Usually, M-mode execution occurs to provide services, such as through the SBI interface, to software executing at lower privilege. Since the M-mode invocation was to provide a -service for the lower privilege mode, the M-mode software may not modify the -`sqoscfg` CSR. +service for the lower privilege mode, the M-mode software may opt not to modify +the `sqoscfg` CSR. If separate `RCID` and/or `MCID` are needed during software execution in M/S/HS-mode, then the M/S/HS-mode software may update the `sqoscfg` CSR and