From e076a342b1083b33ede4e816ba080f6efbf58f2a Mon Sep 17 00:00:00 2001 From: Ved Shanbhogue Date: Sat, 9 Dec 2023 17:01:10 -0600 Subject: [PATCH 1/9] rename sqoscfg to srmcfg --- qos_identifiers.adoc | 6 +++--- qos_sw_guidelines.adoc | 22 +++++++++++----------- 2 files changed, 14 insertions(+), 14 deletions(-) diff --git a/qos_identifiers.adoc b/qos_identifiers.adoc index a685b0c..da60ec5 100644 --- a/qos_identifiers.adoc +++ b/qos_identifiers.adoc @@ -46,10 +46,10 @@ register of the controller. Software should use the effective `MCID` as the ==== RISC-V hart initiated requests (Ssqosid) 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 +(`srmcfg`) to configure QoS Identifiers to be used with requests made by the hart to shared resources. If extension Smstateen cite:[STATEEN] is implemented -then bit (TBA) of `mstateen0` controls access to `sqoscfg` from privilege modes -less than M. +then bit 55 of `mstateen0` controls access to `srmcfg` from privilege modes less +than M. ==== Device initiated requests diff --git a/qos_sw_guidelines.adoc b/qos_sw_guidelines.adoc index cca08af..57b7d34 100644 --- a/qos_sw_guidelines.adoc +++ b/qos_sw_guidelines.adoc @@ -16,7 +16,7 @@ reported using these methods: === Context switching QoS Identifiers -Typically, the contents of the `sqoscfg` CSR are updated with a new `RCID` +Typically, the contents of the `srmcfg` CSR are updated with a new `RCID` and/or `MCID` by the HS/S-mode scheduler if the `RCID` and/or `MCID` of the new workload (a process or a VM) is not same as that of the old workload. @@ -25,15 +25,15 @@ workload being switched away from and restoring the context of the workload 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 +scheduler may want to execute with the `srmcfg` configuration of the workload being switched away from such that this execution is attributed to the workload being switched away from and then prior to restoring the new workloads -context, first switch to the `sqoscfg` configuration appropriate for the +context, first switch to the `srmcfg` configuration appropriate for the workload being switched to such that all of that execution is attributed to the new workload. Further in this context switch process, if the scheduler intends some of its execution to be attributed to neither the outgoing workload nor the incoming workload, then the scheduler may switch to a new -`sqoscfg` configuration that is different from that of either of the workloads +`srmcfg` configuration that is different from that of either of the workloads for the duration of such execution. === QoS configurations for virtual machines @@ -45,12 +45,12 @@ platform or the resource allocations for other virtual machines in the system. If a use case requires it, a hypervisor may virtualize the QoS capability to a VM by virtualizing the memory-mapped CBQRI register interface and virtualizing -the virtual-instruction exception on access to `sqoscfg` CSR by the Guest OS. +the virtual-instruction exception on access to `srmcfg` CSR by the Guest OS. [NOTE] ==== If the use of directly selecting among a set of `RCID` and/or `MCID` by a VM -becomes more prevalent and the overhead of virtualizing the `sqoscfg` CSR using +becomes more prevalent and the overhead of virtualizing the `srmcfg` CSR using the virtual instruction exception is not acceptable then a future extension may be introduced where the `RCID`/`MCID` attempted to be written by VS mode are used as a selector for a set of `RCID`/`MCID` that the hypervisor configures in @@ -59,22 +59,22 @@ a set of HS mode CSRs. === QoS Identifiers for supervisor and machine mode -The `RCID` and `MCID` configured in `sqoscfg` also apply to execution in +The `RCID` and `MCID` configured in `srmcfg` 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 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 opt not to modify the -`sqoscfg` CSR. +`srmcfg` CSR. -Similarly, The `RCID` and `MCID` configured in `sqoscfg` also apply to execution +Similarly, The `RCID` and `MCID` configured in `srmcfg` 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 opt not to modify -the `sqoscfg` CSR. +the `srmcfg` 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 +M/S/HS-mode, then the M/S/HS-mode software may update the `srmcfg` CSR and restore it before returning to lower privilege mode execution. The statistical nature of QoS capabilities means that the brief duration, such as the few instructions in the M/S/HS-mode trap handler entry point, during which the trap From 1b26baf84d8642a9c825d795735ece91a7e1e972 Mon Sep 17 00:00:00 2001 From: Ved Shanbhogue Date: Sat, 9 Dec 2023 17:29:43 -0600 Subject: [PATCH 2/9] editorial updates --- qos_bandwidth.adoc | 36 +++++++++++++++++++----------------- qos_capacity.adoc | 34 +++++++++++++++++++--------------- qos_hw_guidelines.adoc | 2 +- qos_identifiers.adoc | 20 ++++++++++++-------- qos_intro.adoc | 4 ++-- qos_iommu.adoc | 20 +++++++++++--------- qos_sw_guidelines.adoc | 10 ++++++---- 7 files changed, 70 insertions(+), 56 deletions(-) diff --git a/qos_bandwidth.adoc b/qos_bandwidth.adoc index db037fe..3107a45 100644 --- a/qos_bandwidth.adoc +++ b/qos_bandwidth.adoc @@ -5,7 +5,7 @@ Controllers, such as memory controllers, that support bandwidth allocation and bandwidth usage monitoring provide a memory-mapped bandwidth-controller QoS register interface. -.Bandwidth-controller QoS register layout +.Bandwidth-controller QoS Register Layout (size and offset are in bytes) [width=100%] [%header, cols="^3,10,^3, 18, 5"] |=== @@ -38,12 +38,12 @@ handling a request with a non-zero `RCID` value before configuring the bandwidth controller with bandwidth allocation for that `RCID` is also `UNSPECIFIED`. [[BC_CAP]] -=== Capabilities (`bc_capabilities`) +=== Bandwidth-controller Capabilities (`bc_capabilities`) The `bc_capabilities` register is a read-only register that holds the bandwidth-controller capabilities. -.Capabilities register fields +.Bandwidth-controller Capabilities Register [wavedrom, , ] .... {reg: [ @@ -92,13 +92,13 @@ from 0 to 12. If `RPFX` is 0, `P` is set to 0, and the effective `MCID` is the same as the `MCID` in the request. [[BC_MCTL]] -=== Bandwidth usage monitoring control (`bc_mon_ctl`) +=== Bandwidth Usage Monitoring Control (`bc_mon_ctl`) 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 zero. -.Bandwidth usage monitoring control (`bc_mon_ctl`) +.Bandwidth Usage Monitoring Control Register (`bc_mon_ctl`) [wavedrom, , ] .... {reg: [ @@ -127,8 +127,10 @@ 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 <>. +<<< + [[BC_MON_OP]] -.Usage monitoring operations (`OP`) +.Bandwidth Usage Monitoring Operations (`OP`) [width=100%] [%header, cols="16,^12,70"] |=== @@ -152,9 +154,9 @@ 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`) +.Bandwidth Monitoring Event ID (`EVT_ID`) [width=100%] -[%header, cols="15,^10,40"] +[%header, cols="30,^10,40"] |=== |Event ID | Encoding ^| Description |`None` | 0 | Counter does not count and retains its value. @@ -197,7 +199,7 @@ the register. The `STATUS` field remains valid until a subsequent write to the `bc_mon_ctl` register. [[BC_MON_STS]] -.`bc_mon_ctl.STATUS` field encodings +.`bc_mon_ctl.STATUS` Field Encodings [width=100%] [%header, cols="12,70"] |=== @@ -219,14 +221,14 @@ operation, software must first verify that the `BUSY` bit is 0 before writing the `bc_mon_ctl` register. [[BC_MCTR]] -=== Bandwidth monitoring counter value (`bc_mon_ctr_val`) +=== Bandwidth Monitoring Counter Value (`bc_mon_ctr_val`) The `bc_mon_ctr_val` is a read-only register that holds a snapshot of the counter selected by a `READ_COUNTER` operation. When the controller does not support bandwidth usage monitoring, the `bc_mon_ctr_val` register always reads as zero. -.Bandwidth monitoring counter value (`bc_mon_ctr_val`) +.Bandwidth Monitoring Counter Value Register (`bc_mon_ctr_val`) [wavedrom, , ] .... {reg: [ @@ -276,14 +278,14 @@ operation. ==== [[BC_ALLOC]] -=== Bandwidth allocation control (`bc_alloc_ctl`) +=== Bandwidth Allocation Control (`bc_alloc_ctl`) 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 read-only zero. -.Bandwidth allocation control (`bc_alloc_ctl`) +.Bandwidth Allocation Control Register (`bc_alloc_ctl`) [wavedrom, , ] .... {reg: [ @@ -305,7 +307,7 @@ first program the `bc_bw_alloc` register with the operands for the operation before requesting the operation. [[BC_ALLOC_OP]] -.Bandwidth allocation operations (`OP`) +.Bandwidth Allocation Operations (`OP`) [width=100%] [%header, cols="16,^12,70"] |=== @@ -345,7 +347,7 @@ the register. The `STATUS` field remains valid until a subsequent write to the [[BC_ALLOC_STS]] -.`bc_alloc_ctl.STATUS` field encodings +.`bc_alloc_ctl.STATUS` Field Encodings [width=100%] [%header, cols="12,70"] |=== @@ -361,7 +363,7 @@ the register. The `STATUS` field remains valid until a subsequent write to the |=== [[BC_BMASK]] -=== Bandwidth allocation configuration (`bc_bw_alloc`) +=== Bandwidth Allocation Configuration (`bc_bw_alloc`) The `bc_bw_alloc` is used to program reserved bandwidth blocks (`Rbwb`) for an `RCID` for requests of access-type `AT` using the `CONFIG_LIMIT` operation. If a @@ -377,7 +379,7 @@ operation fails with `STATUS=5`. Additionally, the sum of `Rbwb` allocated across all `RCIDs` must not exceed `MRBWB`, or the `CONFIG_LIMIT` operation fails with `STATUS=5`. -.Bandwidth allocation configuration (`bc_bw_alloc`) +.Bandwidth Allocation Configuration Register (`bc_bw_alloc`) [wavedrom, , ] .... {reg: [ diff --git a/qos_capacity.adoc b/qos_capacity.adoc index 547dc1f..deb7f33 100644 --- a/qos_capacity.adoc +++ b/qos_capacity.adoc @@ -45,7 +45,7 @@ workloads. ==== [[CC_REG]] -.Capacity-controller QoS register layout +.Capacity-controller QoS Register Layout (size and offset are in bytes) [width=100%] [%header, cols="^3,10,^4, 18, 5"] |=== @@ -63,8 +63,6 @@ workloads. count>> | Yes |=== -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 formula for determination of `BMW` is defined in <>. The offset `N` is @@ -86,12 +84,12 @@ value before configuring the capacity controller with capacity allocation for that `RCID` is `UNSPECIFIED`. [[CC_CAP]] -=== Capacity-controller capabilities (`cc_capabilities`) +=== Capacity-controller Capabilities (`cc_capabilities`) The `cc_capabilities` register is a read-only register that holds the capacity-controller capabilities. -.Capacity-controller capabilities register fields +.Capacity-controller Capabilities Register [wavedrom, , ] .... {reg: [ @@ -136,13 +134,13 @@ from 0 to 12. If `RPFX` is 0, `P` is set to 0, and the effective `MCID` is the same as the `MCID` in the request. [[CC_MCTL]] -=== Capacity usage monitoring control (`cc_mon_ctl`) +=== Capacity Usage Monitoring Control (`cc_mon_ctl`) The `cc_mon_ctl` register is used to control monitoring of capacity usage by a `MCID`. When the controller does not support capacity usage monitoring the `cc_mon_ctl` register is read-only zero. -.Capacity usage monitoring control (`cc_mon_ctl`) +.Capacity Usage Monitoring Control Register (`cc_mon_ctl`) [wavedrom, , ] .... {reg: [ @@ -170,6 +168,8 @@ fields. The `OP` field is used to instruct the controller to perform an operation listed in <>. +<<< + [[CC_MON_OP]] .Capacity usage monitoring operations (`OP`) [width=100%] @@ -254,14 +254,14 @@ operation, software must first verify that the `BUSY` bit is 0 before writing the `cc_mon_ctl` register. [[CC_MCTR]] -=== Capacity usage monitoring counter value (`cc_mon_ctr_val`) +=== Capacity Usage Monitoring Counter Value (`cc_mon_ctr_val`) The `cc_mon_ctr_val` is a read-only register that holds a snapshot of the counter selected by the `READ_COUNTER` operation. When the controller does not support capacity usage monitoring, the `cc_mon_ctr_val` register always reads as zero. -.Capacity usage monitoring counter value (`cc_mon_ctr_val`) +.Capacity Usage Monitoring Counter Value Register (`cc_mon_ctr_val`) [wavedrom, , ] .... {reg: [ @@ -318,7 +318,7 @@ processes. ==== [[CC_ALLOC]] -=== Capacity allocation control (`cc_alloc_ctl`) +=== 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 `OP`, `RCID` and `AT` fields in this register @@ -326,7 +326,7 @@ 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`) +.Capacity Allocation Control Register (`cc_alloc_ctl`) [wavedrom, , ] .... {reg: [ @@ -350,8 +350,10 @@ require a capacity block mask and/or a capacity unit limit, software must first program the `cc_block_mask` and/or the `cc_cunits` register, followed by initiating the operation via the `cc_alloc_ctl` register. +<<< + [[CC_ALLOC_OP]] -.Capacity allocation operations (`OP`) +.Capacity Allocation Operations (`OP`) [width=100%] [%header, cols="16,^12,70"] |=== @@ -403,6 +405,8 @@ two or more access-types if different capacity allocation per access-type is not required. If capacity is not allocated for each access-type supported by the controller, the behavior is `UNSPECIFIED`. +<<< + [NOTE] ==== A cache controller that supports capacity allocation indicates the number of @@ -473,7 +477,7 @@ to a write to the register. The `STATUS` field remains valid until a subsequent write to the `cc_alloc_ctl` register. [[CC_ALLOC_STS]] -.`cc_alloc_ctl.STATUS` field encodings +.`cc_alloc_ctl.STATUS` Field Encodings [width=100%] [%header, cols="12,70"] |=== @@ -495,7 +499,7 @@ perform the operation determined by the second write. To ensure proper operation software must verify that `BUSY` bit is 0 before writing any of these registers. [[CC_BMASK]] -=== Capacity block mask (`cc_block_mask`) +=== 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. @@ -543,7 +547,7 @@ provides the `READ_LIMIT` operation which can be requested by writing to the `cc_block_mask` register holds the configured _capacity block_ allocation. [[CC_CUNITS]] -=== Capacity units (`cc_cunits`) +=== Capacity Units (`cc_cunits`) 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 diff --git a/qos_hw_guidelines.adoc b/qos_hw_guidelines.adoc index 0894657..e857ea5 100644 --- a/qos_hw_guidelines.adoc +++ b/qos_hw_guidelines.adoc @@ -30,7 +30,7 @@ support when requests are processed by multiple controllers, such as caches, fabrics, and memory controllers. ==== -=== Sizing monitoring counters +=== Sizing Monitoring Counters Typically software samples the monitoring counters periodically to monitor capacity and bandwidth usage. The width of the monitoring counters is diff --git a/qos_identifiers.adoc b/qos_identifiers.adoc index da60ec5..5317181 100644 --- a/qos_identifiers.adoc +++ b/qos_identifiers.adoc @@ -17,8 +17,8 @@ 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. -Guidelines for sizing the QoS IDs and need for differentiated IDs for monitoring -is discussed in <>. +<> discusses guidelines for sizing the QoS IDs and the need for +differentiated IDs for monitoring. [[EMCID]] === Associating `RCID` and `MCID` with requests @@ -35,9 +35,12 @@ the counter and is the effective `MCID`. In the RCID-prefixed mode, the controller identifies the counter for monitoring using an effective `MCID` computed as: ----- - Effective MCID = (RCID << P) | (MCID & ((1 << P) - 1)) ----- +[latexmath#eq-2,reftext="equation ({counter:eqs})"] +++++ +\begin{equation} +Effective-MCID = (RCID << P) | (MCID & ((1 << P) - 1)) +\end{equation} +++++ Legal values of `P` range from 0 to 12 and are enumerated in the capability register of the controller. Software should use the effective `MCID` as the @@ -47,9 +50,10 @@ register of the controller. Software should use the effective `MCID` as the The Ssqosid extension cite:[SSQOSID] introduces a read/write S/HS-mode register (`srmcfg`) to configure QoS Identifiers to be used with requests made by the -hart to shared resources. If extension Smstateen cite:[STATEEN] is implemented -then bit 55 of `mstateen0` controls access to `srmcfg` from privilege modes less -than M. +hart to shared resources. If Smstateen cite:[STATEEN] is implemented then bit 55 +of `mstateen0` controls access to `srmcfg` from privilege modes less than M. + +<<< ==== Device initiated requests diff --git a/qos_intro.adoc b/qos_intro.adoc index 4025455..cf4f271 100644 --- a/qos_intro.adoc +++ b/qos_intro.adoc @@ -104,8 +104,8 @@ respected between the two software accesses, or two hardware transactions, respectively. ==== -The controller registers have little-endian byte order (even for systems where -all harts are big-endian-only). +The controller registers have little-endian byte order (even if all harts are +big-endian-only). [NOTE] ==== diff --git a/qos_iommu.adoc b/qos_iommu.adoc index 304ef59..35d5d20 100644 --- a/qos_iommu.adoc +++ b/qos_iommu.adoc @@ -1,5 +1,5 @@ [[QOS_IOMMU]] -== IOMMU extension for QoS ID +== IOMMU Extension for QoS ID A method to associate QoS IDs with requests to access resources by the IOMMU, as well as with devices governed by it, is required for effective monitoring and @@ -12,7 +12,7 @@ The size (or width) of `RCID` and `MCID`, as fields in registers or in data structures, supported by the IOMMU must be at least as large as that supported by any RISC-V application processor hart in the system. -=== IOMMU registers +=== IOMMU Registers The specified memory-mapped register layout defines a new IOMMU register named `iommu_qosid`. This register is used to configure the Quality of Service (QoS) @@ -20,7 +20,7 @@ IDs associated with IOMMU-originated requests. The register has a size of 4 bytes and is located at an offset of 624 from the beginning of the memory-mapped region. -.IOMMU Memory-mapped register layout +.IOMMU Memory-mapped Register Layout [width=100%] [%header, cols="^3,6,^3, 12, 10"] |=== @@ -29,7 +29,7 @@ region. |628 |Reserved |60 |Reserved for future use (`WPRI`)| |=== -==== Reset behavior +==== Reset Behavior If the reset value for `ddtp.iommu_mode` field is `Bare`, then the `iommu_qosid.RCID` field must have a reset value of 0. @@ -44,13 +44,15 @@ the `iommu_qosid` register should be initialized by software prior to changing the mode to allow DMA. ==== -==== IOMMU capabilities (`capabilities`) +<<< + +==== IOMMU Capabilities (`capabilities`) The IOMMU capabilities register has been extended with a new field, `QOSID`, which enumerates support for associating QoS IDs with requests made through the IOMMU. -.IOMMU capabilities register fields +.IOMMU Capabilities Register [wavedrom, , ] .... {reg: [ @@ -131,13 +133,13 @@ value programmed in the `RCID` and `MCID` fields of the `iommu_qosid` register. When `ddtp.iommu_mode == Bare`, all device-originated requests are associated with the QoS IDs configured in the `iommu_qosid` register. -=== Device-context fields +=== Device-context Fields The `ta` field of the device context is extended with two new fields, `RCID` and `MCID`, to configure the QoS IDs to associate with requests originated by the devices. -.Translation attributes (`ta`) field +.Translation Attributes (`ta`) Field [wavedrom, , ] .... {reg: [ @@ -167,7 +169,7 @@ supported by the IOMMU, a `DC` with `DC.tc.V=1` is considered misconfigured. In this case, the IOMMU should stop and report "DDT entry misconfigured" (cause = 259). -=== IOMMU ATC capacity allocation and monitoring +=== IOMMU ATC Capacity Allocation and Monitoring Some IOMMUs may support capacity allocation and usage monitoring in the IOMMU address translation cache (IOATC) by implementing the capacity controller diff --git a/qos_sw_guidelines.adoc b/qos_sw_guidelines.adoc index 57b7d34..125bb30 100644 --- a/qos_sw_guidelines.adoc +++ b/qos_sw_guidelines.adoc @@ -1,7 +1,7 @@ [[QOS_SW_GUIDE]] == Software Guidelines -=== Reporting capacity and bandwidth controllers +=== Reporting Capacity and Bandwidth Controllers The capability and bandwidth controllers that are present in the system should be reported to operating systems using methods such as ACPI and/or device tree. @@ -14,7 +14,7 @@ reported using these methods: resources controlled by the controller * The number of QoS identifiers supported by the controller -=== Context switching QoS Identifiers +=== Context Switching QoS Identifiers Typically, the contents of the `srmcfg` CSR are updated with a new `RCID` and/or `MCID` by the HS/S-mode scheduler if the `RCID` and/or `MCID` of the @@ -36,7 +36,7 @@ workload nor the incoming workload, then the scheduler may switch to a new `srmcfg` configuration that is different from that of either of the workloads for the duration of such execution. -=== QoS configurations for virtual machines +=== QoS Configurations for Virtual Machines Usually for virtual machines the resource allocations are configured by the hypervisor. Usually the Guest OS in a virtual machine does not participate in @@ -47,6 +47,8 @@ If a use case requires it, a hypervisor may virtualize the QoS capability to a VM by virtualizing the memory-mapped CBQRI register interface and virtualizing the virtual-instruction exception on access to `srmcfg` CSR by the Guest OS. +<<< + [NOTE] ==== If the use of directly selecting among a set of `RCID` and/or `MCID` by a VM @@ -57,7 +59,7 @@ used as a selector for a set of `RCID`/`MCID` that the hypervisor configures in a set of HS mode CSRs. ==== -=== QoS Identifiers for supervisor and machine mode +=== QoS Identifiers for Supervisor and Machine Mode The `RCID` and `MCID` configured in `srmcfg` also apply to execution in S/HS-mode, but this is typically not an issue. Usually, S/HS-mode execution From e8068a2dff328418ccb7a5bc6ffc88981c22996c Mon Sep 17 00:00:00 2001 From: Ved Shanbhogue Date: Sat, 9 Dec 2023 17:37:10 -0600 Subject: [PATCH 3/9] editorial updates --- qos_bandwidth.adoc | 4 ++-- qos_capacity.adoc | 6 +++--- qos_identifiers.adoc | 2 +- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/qos_bandwidth.adoc b/qos_bandwidth.adoc index 3107a45..b404862 100644 --- a/qos_bandwidth.adoc +++ b/qos_bandwidth.adoc @@ -256,7 +256,7 @@ determined by reading the byte count value at two instances of time `T1` and time `T2` is `B2`, then the bandwidth can be calculated as follows. The frequency of the time source is represented by latexmath:[T_{freq}]. -[latexmath#eq-2,reftext="equation ({counter:eqs})"] +[latexmath#eq-3,reftext="equation ({counter:eqs})"] ++++ \begin{equation} Bandwidth = T_{freq} \times \frac{ B2 - B1 }{T2 - T1} @@ -426,7 +426,7 @@ permitted to use unused bandwidth is determined by dividing the `Mweight` of `RCID=x` by the sum of the `Mweight` of all other contending `RCIDs`. This ratio `P` is determined by <>. -[latexmath#eq-3,reftext="equation ({counter:eqs})"] +[latexmath#eq-4,reftext="equation ({counter:eqs})"] ++++ \begin{equation} P = \frac{Mweight_{x}}{\sum_{r=1}^{r=n} Mweight_{r}} diff --git a/qos_capacity.adoc b/qos_capacity.adoc index deb7f33..0fb89a7 100644 --- a/qos_capacity.adoc +++ b/qos_capacity.adoc @@ -127,6 +127,8 @@ units_ that can be occupied by an `RCID` in _capacity blocks_ allocated to it. If `FRCID` is 1, the controller supports an operation to flush and deallocate the _capacity blocks_ occupied by an `RCID`. +<<< + If `RPFX` is 1, the controller uses `RCID` in the requests along with `P` least significant bits of the `MCID` carried in the request to compute an effective `MCID` (<>) to identify the monitoring counter. Legal values of `P` range @@ -168,8 +170,6 @@ fields. The `OP` field is used to instruct the controller to perform an operation listed in <>. -<<< - [[CC_MON_OP]] .Capacity usage monitoring operations (`OP`) [width=100%] @@ -510,7 +510,7 @@ always a multiple of 64 bits. The bitmap width in bits (`BMW`) is determined by the equation below. The division operation in this equation is an integer division. -[latexmath#eq-1,reftext="equation ({counter:eqs})"] +[latexmath#eq-2,reftext="equation ({counter:eqs})"] ++++ \begin{equation} BMW = \lfloor{\frac{NCBLKS + 63}{64}}\rfloor \times 64 diff --git a/qos_identifiers.adoc b/qos_identifiers.adoc index 5317181..2073725 100644 --- a/qos_identifiers.adoc +++ b/qos_identifiers.adoc @@ -35,7 +35,7 @@ the counter and is the effective `MCID`. In the RCID-prefixed mode, the controller identifies the counter for monitoring using an effective `MCID` computed as: -[latexmath#eq-2,reftext="equation ({counter:eqs})"] +[latexmath#eq-1,reftext="equation ({counter:eqs})"] ++++ \begin{equation} Effective-MCID = (RCID << P) | (MCID & ((1 << P) - 1)) From 667ab6d1f58b08eb902a352675dc63b4ecd38a9e Mon Sep 17 00:00:00 2001 From: Ved Shanbhogue Date: Sat, 9 Dec 2023 17:42:23 -0600 Subject: [PATCH 4/9] editorial updates --- qos_bandwidth.adoc | 10 +++++----- qos_capacity.adoc | 15 ++++++++++----- qos_iommu.adoc | 9 ++++----- 3 files changed, 19 insertions(+), 15 deletions(-) diff --git a/qos_bandwidth.adoc b/qos_bandwidth.adoc index b404862..89aae51 100644 --- a/qos_bandwidth.adoc +++ b/qos_bandwidth.adoc @@ -38,7 +38,7 @@ handling a request with a non-zero `RCID` value before configuring the bandwidth controller with bandwidth allocation for that `RCID` is also `UNSPECIFIED`. [[BC_CAP]] -=== Bandwidth-controller Capabilities (`bc_capabilities`) +=== Bandwidth-controller Capabilities The `bc_capabilities` register is a read-only register that holds the bandwidth-controller capabilities. @@ -92,7 +92,7 @@ from 0 to 12. If `RPFX` is 0, `P` is set to 0, and the effective `MCID` is the same as the `MCID` in the request. [[BC_MCTL]] -=== Bandwidth Usage Monitoring Control (`bc_mon_ctl`) +=== Bandwidth Usage Monitoring Control 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 @@ -221,7 +221,7 @@ operation, software must first verify that the `BUSY` bit is 0 before writing the `bc_mon_ctl` register. [[BC_MCTR]] -=== Bandwidth Monitoring Counter Value (`bc_mon_ctr_val`) +=== Bandwidth Monitoring Counter Value The `bc_mon_ctr_val` is a read-only register that holds a snapshot of the counter selected by a `READ_COUNTER` operation. When the controller does not @@ -278,7 +278,7 @@ operation. ==== [[BC_ALLOC]] -=== Bandwidth Allocation Control (`bc_alloc_ctl`) +=== Bandwidth Allocation Control 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 @@ -363,7 +363,7 @@ the register. The `STATUS` field remains valid until a subsequent write to the |=== [[BC_BMASK]] -=== Bandwidth Allocation Configuration (`bc_bw_alloc`) +=== Bandwidth Allocation Configuration The `bc_bw_alloc` is used to program reserved bandwidth blocks (`Rbwb`) for an `RCID` for requests of access-type `AT` using the `CONFIG_LIMIT` operation. If a diff --git a/qos_capacity.adoc b/qos_capacity.adoc index 0fb89a7..8b5fe72 100644 --- a/qos_capacity.adoc +++ b/qos_capacity.adoc @@ -84,7 +84,7 @@ value before configuring the capacity controller with capacity allocation for that `RCID` is `UNSPECIFIED`. [[CC_CAP]] -=== Capacity-controller Capabilities (`cc_capabilities`) +=== Capacity-controller Capabilities The `cc_capabilities` register is a read-only register that holds the capacity-controller capabilities. @@ -136,7 +136,7 @@ from 0 to 12. If `RPFX` is 0, `P` is set to 0, and the effective `MCID` is the same as the `MCID` in the request. [[CC_MCTL]] -=== Capacity Usage Monitoring Control (`cc_mon_ctl`) +=== Capacity Usage Monitoring Control The `cc_mon_ctl` register is used to control monitoring of capacity usage by a `MCID`. When the controller does not support capacity usage monitoring the @@ -254,7 +254,7 @@ operation, software must first verify that the `BUSY` bit is 0 before writing the `cc_mon_ctl` register. [[CC_MCTR]] -=== Capacity Usage Monitoring Counter Value (`cc_mon_ctr_val`) +=== Capacity Usage Monitoring Counter Value The `cc_mon_ctr_val` is a read-only register that holds a snapshot of the counter selected by the `READ_COUNTER` operation. When the controller does not @@ -318,7 +318,7 @@ processes. ==== [[CC_ALLOC]] -=== Capacity Allocation Control (`cc_alloc_ctl`) +=== Capacity Allocation Control The `cc_alloc_ctl` register is used to configure allocation of capacity to an `RCID` per access-type (`AT`). The `OP`, `RCID` and `AT` fields in this register @@ -547,7 +547,7 @@ provides the `READ_LIMIT` operation which can be requested by writing to the `cc_block_mask` register holds the configured _capacity block_ allocation. [[CC_CUNITS]] -=== Capacity Units (`cc_cunits`) +=== Capacity Units 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 @@ -580,7 +580,12 @@ For instance, consider a group of four `RCID` instances configured to share a set of _capacity blocks_, representing a total of 100 capacity units. Each `RCID` could be configured with a limit of 30 capacity units, ensuring that no individual `RCID` exceeds 30% of the total shared _capacity units_. +==== + +<<< +[NOTE] +==== The capacity controller may enforce these limits through various techniques. Examples include: diff --git a/qos_iommu.adoc b/qos_iommu.adoc index 35d5d20..62e3fc0 100644 --- a/qos_iommu.adoc +++ b/qos_iommu.adoc @@ -46,11 +46,10 @@ the mode to allow DMA. <<< -==== IOMMU Capabilities (`capabilities`) +==== IOMMU Capabilities -The IOMMU capabilities register has been extended with a new field, `QOSID`, -which enumerates support for associating QoS IDs with requests made through the -IOMMU. +The IOMMU `capabilities` register is extended with a new field, `QOSID`, which +enumerates support for associating QoS IDs with requests made through the IOMMU. .IOMMU Capabilities Register [wavedrom, , ] @@ -95,7 +94,7 @@ IOMMU. |41 |`QOSID` |RO | Associating QoS IDs with requests is supported. |=== -==== IOMMU QoS ID (`iommu_qosid`) +==== IOMMU QoS ID The `iommu_qosid` register fields are defined as follows: From 0615415c6f3c44ac49f4aa94f7b28dff9c29e6bb Mon Sep 17 00:00:00 2001 From: Ved Shanbhogue Date: Sat, 9 Dec 2023 17:48:26 -0600 Subject: [PATCH 5/9] editorial updates --- qos_bandwidth.adoc | 2 ++ qos_capacity.adoc | 16 +++++++--------- 2 files changed, 9 insertions(+), 9 deletions(-) diff --git a/qos_bandwidth.adoc b/qos_bandwidth.adoc index 89aae51..f2d6176 100644 --- a/qos_bandwidth.adoc +++ b/qos_bandwidth.adoc @@ -326,6 +326,8 @@ before requesting the operation. | -- | 24-31 | Designated for custom use. |=== +<<< + A bandwidth allocation must be configured for each access-type supported by the controller. When differentiated bandwidth allocation based on access-type is not required, one of the access-types may be designated to hold a default diff --git a/qos_capacity.adoc b/qos_capacity.adoc index 8b5fe72..e35e19c 100644 --- a/qos_capacity.adoc +++ b/qos_capacity.adoc @@ -170,8 +170,10 @@ fields. The `OP` field is used to instruct the controller to perform an operation listed in <>. +<<< + [[CC_MON_OP]] -.Capacity usage monitoring operations (`OP`) +.Capacity Usage Monitoring Operations (`OP`) [width=100%] [%header, cols="16,^12,70"] |=== @@ -195,7 +197,7 @@ used to program the access-type to count, and its validity is indicated by the and the `AT` value is ignored. [[CC_EVT_ID]] -.Capacity usage monitoring event ID (`EVT_ID`) +.Capacity Usage Monitoring Event ID (`EVT_ID`) [width=100%] [%header, cols="12,^12,70"] |=== @@ -232,7 +234,7 @@ the register. The `STATUS` field remains valid until a subsequent write to the `cc_mon_ctl` register. [[CC_MON_STS]] -.`cc_mon_ctl.STATUS` field encodings +.`cc_mon_ctl.STATUS` Field Encodings [width=100%] [%header, cols="12,70"] |=== @@ -253,6 +255,8 @@ may perform the operation determined by the second write. To ensure proper operation, software must first verify that the `BUSY` bit is 0 before writing the `cc_mon_ctl` register. +<<< + [[CC_MCTR]] === Capacity Usage Monitoring Counter Value @@ -287,11 +291,7 @@ 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 optimize on the storage overheads. Such controllers may in turn rely on @@ -350,8 +350,6 @@ require a capacity block mask and/or a capacity unit limit, software must first program the `cc_block_mask` and/or the `cc_cunits` register, followed by initiating the operation via the `cc_alloc_ctl` register. -<<< - [[CC_ALLOC_OP]] .Capacity Allocation Operations (`OP`) [width=100%] From 324b4280fda2dc3c226ae07d3179b018af320913 Mon Sep 17 00:00:00 2001 From: Ved Shanbhogue Date: Sat, 9 Dec 2023 17:55:53 -0600 Subject: [PATCH 6/9] editorial updates --- qos_bandwidth.adoc | 2 ++ qos_capacity.adoc | 6 ------ 2 files changed, 2 insertions(+), 6 deletions(-) diff --git a/qos_bandwidth.adoc b/qos_bandwidth.adoc index f2d6176..f65e14e 100644 --- a/qos_bandwidth.adoc +++ b/qos_bandwidth.adoc @@ -57,6 +57,8 @@ bandwidth-controller capabilities. ], config:{lanes: 4, hspace:1024}} .... +<<< + The `VER` field holds the version of the specification implemented by the bandwidth controller. The low nibble is used to hold the minor version of the specification and the upper nibble is used to hold the major version of the diff --git a/qos_capacity.adoc b/qos_capacity.adoc index e35e19c..60099b6 100644 --- a/qos_capacity.adoc +++ b/qos_capacity.adoc @@ -170,8 +170,6 @@ fields. The `OP` field is used to instruct the controller to perform an operation listed in <>. -<<< - [[CC_MON_OP]] .Capacity Usage Monitoring Operations (`OP`) [width=100%] @@ -255,8 +253,6 @@ may perform the operation determined by the second write. To ensure proper operation, software must first verify that the `BUSY` bit is 0 before writing the `cc_mon_ctl` register. -<<< - [[CC_MCTR]] === Capacity Usage Monitoring Counter Value @@ -403,8 +399,6 @@ two or more access-types if different capacity allocation per access-type is not required. If capacity is not allocated for each access-type supported by the controller, the behavior is `UNSPECIFIED`. -<<< - [NOTE] ==== A cache controller that supports capacity allocation indicates the number of From 620843a6144b2bbfd068dfc125c6cae6a93c6e80 Mon Sep 17 00:00:00 2001 From: Ved Shanbhogue Date: Sat, 9 Dec 2023 17:59:28 -0600 Subject: [PATCH 7/9] editorial updates --- qos_capacity.adoc | 2 ++ 1 file changed, 2 insertions(+) diff --git a/qos_capacity.adoc b/qos_capacity.adoc index 60099b6..84f347a 100644 --- a/qos_capacity.adoc +++ b/qos_capacity.adoc @@ -194,6 +194,8 @@ 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`) [width=100%] From c1b331635c5eed5896b80bb86361108dc3cafb34 Mon Sep 17 00:00:00 2001 From: Ved Shanbhogue Date: Sat, 9 Dec 2023 18:03:38 -0600 Subject: [PATCH 8/9] editorial updates --- qos_capacity.adoc | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/qos_capacity.adoc b/qos_capacity.adoc index 84f347a..3d52e56 100644 --- a/qos_capacity.adoc +++ b/qos_capacity.adoc @@ -381,6 +381,8 @@ initiating the operation via the `cc_alloc_ctl` register. | -- | 24-31 | Designated for custom use. |=== +<<< + Capacity controllers enumerate the allocatable _capacity blocks_ in the `NCBLKS` field of the `cc_capabilities` register. The `cc_block_mask` register is programmed with a bit-mask where each bit represents a _capacity block_ for the @@ -437,6 +439,8 @@ capacity blocks represent 100 units and `RCID=3` has a 30-unit limit while blocks, respectively. ==== +<<< + The `FLUSH_RCID` operation may incur a long latency to complete. New requests to the controller by the `RCID` being flushed are allowed. Additionally, the controller is allowed to deallocate capacity that was allocated after the @@ -576,8 +580,6 @@ set of _capacity blocks_, representing a total of 100 capacity units. Each individual `RCID` exceeds 30% of the total shared _capacity units_. ==== -<<< - [NOTE] ==== The capacity controller may enforce these limits through various techniques. From 11faf2cca88334506e4aa936c3bf05aa8ea4e8a3 Mon Sep 17 00:00:00 2001 From: Ved Shanbhogue Date: Sat, 9 Dec 2023 18:06:51 -0600 Subject: [PATCH 9/9] editorial updates --- qos_capacity.adoc | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/qos_capacity.adoc b/qos_capacity.adoc index 3d52e56..7228130 100644 --- a/qos_capacity.adoc +++ b/qos_capacity.adoc @@ -557,6 +557,8 @@ may be occupied in the allocated _capacity blocks_ (i.e., 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`) then this register sets an upper limit on the number of _capacity units_ that @@ -578,10 +580,7 @@ For instance, consider a group of four `RCID` instances configured to share a set of _capacity blocks_, representing a total of 100 capacity units. Each `RCID` could be configured with a limit of 30 capacity units, ensuring that no individual `RCID` exceeds 30% of the total shared _capacity units_. -==== -[NOTE] -==== The capacity controller may enforce these limits through various techniques. Examples include: